Jan,
On 03/17/11 09:51, Jan Damborsky wrote:
Looks good to me. I skimmed b and c as well. Also
a couple comments.
useradd in the current gate should be able to create
zfs home directories and auto_mount maps by default.
Yep, I have noticed that when playing with useradd for
purposes of this project.
Currently, start method system/config smf service takes care
of that, but I think it might make sense to delegate that task
to useradd now when it provides for that features.
Though we will have to give it some thoughts, as looking at
useradd(1m) man page, unlike system/config, it does not provide
for customizing those parameters (e.g. name of ZFS dataset,
entry in /etc/auto_home).
Which might or might not be an issue.
I'm not sure about that. I don't know when the latest
man page will show up. You can look at the ARC case
PSARC/2009/652 final.materials/man/useradd.1m
And http://onnv.us.oracle.com/flagdays/pages/20110125111758.html
to see if that helps. [email protected] should be able
to answer any detailed questions.
b, 10.2 exposes password values and contains primary
administrator. I presume this is out of date.
Assigning values to listed smf properties was intended as an example
of how smf properties could be configured, I will clarify that.
When recently updating the doc, I have overlooked that this still uses
'Primary Administrator'. Thank you for catching this. I will change that
to something else (e.g. System Administrator).
I'm not sure if System Administrator is the right profile, but
it looks good right now. It's likely that the root role
may also have to be used to get the system users/roles fully
configured in some cases.
We've talked about how to use pam_chauthtok() to do
password qualification and hashing. I've convinced
myself that this should be straight forward if the
installer can take the hash from a file written to
a specified path.
I believe that this should be fine for interactive installers.
That's all we can really do isn't it. Isn't AI like jumpstart
and needs to be preconfigured by the site admin?
In case of Automated Installer, user is responsible for constructing
password hash and supply it via System Configuration profile.
I assume that today people just use passwd(1) and then copy paste
hashes from shadow(4) to System Configuration profile.
I presume that's how jumpstart is done if passwords are
configured.
The hard part is to present the
user with a conversation if this is a GUI rather than
a tty based interaction.
Yep, I agree. That's more challenging part :-)
Not being a GUI guy, I'd really be challenged.
A tty based interaction is just a few line of simple
C. It's well documented in the PAM developer guide
and the SAC Policy:
http://psarc.us.oracle.com/BestPractices/pam_tty_conv.c
In c, page 7 groupings:users I believe the same applies
unless passwd(1) can be used.
I am not quite sure what you mean. Could you please elaborate
more on that ?
It appeared that when groupings:users was unconfigured,
something on "reconfigure" would need to set the passwords
for the initial user and root accounts. If that was the
password command for the initial user, then a copy of the
hash to root shadow field (or user/rolemod -P ;-) and a
passwd -r files -f root
Or the same things as done for an initial install as above,
calling pam_chauthtok with a "magic" repository.
And I thought that the initial
user and root passwords were to be the same, root a role,
and the initial user granted the root role. The root password
would be expired (passwd -r files -f root).
This is definitely the intent in case of interactive installers,
we plan to consolidate that for GUI and text installer by S11FCS.
As far as AI is concerned, admin is currently provided with full control
over how post-install configuration of user and root account is going to
look like.
Is this something which should be reconsidered ?
I don't believe so. My understanding of AI is that the CU can
install whatever they want and preconfigure any way they want.
As long as the "initial" install defaults meet the "safe" and
"secure" specs, all should be fine.
Thank you for those suggestions, I was neither aware of 'passwd -r files
-d'
nor about 'userattr type root'. That indeed helps.
Glad I could suggest it. I'm not sure anyone can keep up with
the rate of change in Nevada, though passwd -d has been around
for possible as long as 5.0.
Cheers,
Gary..
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
