Hi Jan,
>> 2. nodename
>>
>> How is this supposed to work? It doesn't seem practical to have an
>> individual SMF profile per client, differing from the (say)
>> site-global one only by nodename,
>> especially since the information can
>> usually be obtained either from a name service or per DHCP.
>
> I agree. It is generic problem with scalability of SC manifest.
> We have discussed it a bit, but haven't fully solved it yet.
> For instance, we could allow applying more than one profile -
> then we could separate common settings from client specific
> configuration.
this seems like a useful approach in general: you will always have
settings that are (say) site-wide, while others are specific to a group
of machines or an individual one.
> Or (in case of nodename) identity:node coudl be taught to
> dynamically fill in nodename at the first boot - e.g. the
> parameter could be obtained by querying the appropriate database.
Right: in cases where this can easily be done dynamically, it would be a
shame to hardcode the value for every single client instead.
In the case of root passwords, it occured to me that one could e.g. set
a site-wide initial password, but pre-expire the account so the password
has to be changed on first login (I think it was you who mentioned this
at some point).
> There is definitely more investigation to be done and we are
> open to ideas.
> We would also appreciate sharing experiences with how that
> problem is handled in existing infrastructures.
There's certainly the problem of assembling the manifests from pieces.
It doesn't only apply to the SC manifest/SMF profile, but also to the AI
manifest, where the target part most likely cannot be site-wide (some
system disks are mirrored when this becomes supported, others are not;
some machines get a minimal set of packages, others are used as Sun Ray
servers and need much more; the list goes on).
I can imagine two solutions:
* Assemble the fragments on the client. The problem here is that
whenever I change one single fragment, all dependent manifests have to
be regenerted and re-added. Right now, this is even worse: you cannot
replace an existing manifest by an updated one, but first have to
delete and then re-add it.
* On the other hand, you could have the AI server do the assembling,
maybe via XML's include facilities. While this has some charme, I
wonder how manageable such a solution would be.
Some experimentation is clearly called for in this space. I'd
appreciate input from the JET maintainers in particular.
Thanks.
Rainer
--
-----------------------------------------------------------------------------
Rainer Orth, Center for Biotechnology, Bielefeld University
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
