Hi Mike,
From a meeting on Derived Profiles, the question of security
compartmentalization came up. It would be useful to have your input -- and
any other folks too. We were discussing the snippet from your e-mail
below:
> - I can trust that the just-hired-last-week junior sysadmin armed with
> a simple procedure can install Solaris per standards without risk of
> breaking the jumpstart environment for everyone else. That is, since
> there is no customization to perform on the jumpstart server there is
> no chance that someone that is not tasked with maintaining jumpstart
> will break jumpstart.
First, we discussed how in AI current, adding any new system in AI will
change the install matrix, since AI follows an "always install" mentality
(we have the default manifest and will always try to give the client
something). Perhaps this is an undesirable feature moving into some
enterprise realms?
Regardless, a junior sys. admin. might be tasked with changing something
in three separate ways: the criteria, the AI manifest or the SC manifest.
It seems some security here could prove useful, as the criteria may affect
which machines are installed, the AI manifest is what's installed and SC
manifest (root passwd, etc.) are how the machine is later configured and
accessed. Would there be value in allowing compartmentalization so that
an admin could only change say one of the three?
Lastly, moving AI to an "only install what's defined" system would allow
one to lock down the AI server so that an admin may only add a machine to
the server -- if it does not impede on the current install state space --
e.g. it's a new machine not covered by a pre-existing manifest. Is this
what you meant from your e-mail? Or would this kind of control provide
benefit?
If these didn't cover your intention, could you help me understand better
how AI could be modified to reach your goal?
Thank you,
Clay
