Ethan,
On 06/16/10 08:19 PM, Ethan Quach wrote:
On 06/13/10 08:31, William Schumann wrote:
Responses to questions are inline. Other points will be addressed in
a revision of the proposal.
On 06/ 4/10 09:29 PM, Dave Miner wrote:
On 06/ 2/10 03:02 PM, William Schumann wrote:
This proposal addresses specific deficiencies in customizing SC
manifests, and proposes enhancements to increase usability and
security.
...
Section I: Has consideration been given to just overloading the
existing manifest management commands and making them capable of
auto-detecting the type of manifest being expressed and adjusting
their behavior automatically?
AI vs. SC manifest? This was not considered. It would save adding
another option, although it is potentially confusing for the user not
expecting this convenience.
AI manifests are added into install services, and also regulated by
the criteria as the selection mechanism for clients. SC manifests, per
this proposal, will be usable by multiple services/clients across the
whole install server. Also, as an intentional result of separating the
SC manifest from the AI manifest, it is no longer regulated by the
criteria set, but associated directly with services or client-specific
setups.
I think these differences make it difficult to re-use the command
set used for AI manifests, since there are at least a couple of options
(for example the specification of the install service) that don't apply
to SC manifests, but do apply to AI manfiests.
Having said that though, one way it could be done, would be to make
the install service specification optional, and make its presence or
absence imply the type of manifest.
I still don't think it adds enough value. Also, Sarah's suggestion
about having the SC manifests pointed to by the AI manifest would take
care of this one.
Section Ib: What would the contents of a default SC manifest be?
The current default.xml has such entries:
root password: opensolaris, user: jack, password: jack
These are useful for configuring a system with a minimum of user
intervention.
Do we in fact actually require one?
No. Enhanced SMF profiles project will result in prompting on first
boot if required properties are missing.
AI requires a manifest in order to know what to install, but why
wouldn't we expect that services would be able to prompt for
configuration if required?
Again, we are aiming at automation. The Automated Installer should
offer ease-of-use defaults that can be customized or eliminated by
the user.
While I agree in principle with this point, it doesn't seem that loading
up a default configuration with hardcoded values for hostname, root
password, user and user password make things any easier for the main
targeted use case for AI.
The original justification for these defaults was to make AI more
accessible for the community at large, particularly for first-time
users, and it worked.
Having a bunch of systems end up with the same hostname at least, has
been a pain for some.
Documentation, including documentation within the default SC manifest,
might be sufficient to alert users to this hazard.
A simple alternative would be to simply leave hostname out of the
shipped default SC manifest. I presume that this could be prompted for
upon first boot.
If there were a replacement tag for DHCP option Hostname
(dhcp_inittab(4)), it could be substituted during installation. If
there is no DHCP Hostname, the SC manifest would have to have it's
hostname SMF property cleaned up so it works properly on first boot.
Among these choices, I would opt for simply leaving out the hostname
from the default SC manifest.
There are issues with other properties as well. Having a hard-coded
default root password would make life easier for some, but open others
into unwittingly having a known root password.
Some properties might have more obvious and safe defaults that would
save the user from being prompted upon first boot.
It is possible that the user is swamped with a long list of prompts for
SMF properties upon first boot. Maintaining the notion of a default SC
manifest to help with some of the more innocuous options.
So, I would propose to keep the default SC manifest, but eliminate the
more problematic defaults.
William
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
