> 2) Related to that, have installadm list -m have some option to show
> what criteria is used for each manifest - I'm getting around this
right
> now by using the ip address in the manifest name. It seems like
> installadm knows this, as if I try to add a new manifest for a system
> that already has one set up, it will generate an error about the
conflict.
As Clay mentioned, you can see the criteria for each manifest in a given
service
by using the command:
installadm list -m -n <svcname>
Yes - I see that. I would note that the padding of the IP addresses
with 0 is probably broken:
ai_10.5.233.117.xml ipv4 = 010.005.233.117
It's broken in the sense that most all utilities will treat such padded
addresses as octal (ping, telnet, probably everything that uses standard
library routines). So if I do that installadm list and decide to
cut/paste the address to see if it is up, I end up pinging the wrong host.
I can understand the desire to make it look nice and be formatted, but
that padding also makes processing a little harder, as now the script
would have to take the non padded IP address and pad it.
Would you mind filing a bug on bugster under solaris/install/installadm?
> 3) Have an option to add-manifest for it to use that as the manifest
> name instead of pulling it either out of the file name or using the
file
> itself.
Actually, one of the things that has always bothered me about installadm
is how
add-manifest uses the -m option one way (manifest file) and how
delete-manifest
(and now set-criteria) use -m another way (manifest name). We could make
things
more consistent by adding a new flag and by changing the usage slightly
as follows:
Current usage:
add-manifest -m <manifest> -n <svcname>
[-c <criteria=value|range> ... | -C <criteria.xml>]
Proposed usage:
add-manifest -f <manifest_file> -n <svcname> [-m <manifest_name>]
[-c <criteria=value|range> ... | -C <criteria.xml>]
The manifest file would now be specified with -f. The -m would be
optional and
could be used to specify the manifest name on the command line, if
desired. The
precedence order for the name would be:
1) -m option, if present
2) internal name attribute, if present
3) filename
Let me know what you think of this approach.
That looks pretty good to me. Consistency is always nice, and -f is
used for many utilities to denote input/output file, so that helps it be
consistent with other utilities also.
Thanks - I appreciate your input,
Sue
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
