>And the key reason for not using this approach is because it doesn't
>do proper locking of the files. If you are using the same code for
>alternate root and non-alternate (?) root installs this could be more
>of a concern. In any case, if you need to set the password, you are
>stuck writing scripts.
But you really have very little choice in the matter; if you want proper
locking, you can use something like:
- if we're updating "/"
useradd/usermod etc
else
do it by hand
>The most trivial script that can do proper locking will be written in
>Perl. One must peruse the code of tools like passwd, useradd,
>usermod, etc. to understand the locking mechanism(s) they use. I'm
>somewhat sure that they all work by calling lckpwdf(), which takes out
>an exclusive lock on /etc/.pwd.lock. When I cared enough to look in
>the past, it seems as though this protected both /etc/passwd and
>/etc/shadow. As you go further down this path, you may become
>concerned about user_attr(4), project(4), and potentially others.
If you're updating an alternate root through pkgadd, I would not worry
about locking at all; there cannot be concurrent tools updating it
except if someone is doing package at and at the same time doing
maintenance by hand (unlikely with proper locking also)
>> > Better still, though, is to pick up that bug and solve it. Things
>> > always get done faster when the person doing the work has a strong
>> > motivation to make it happen.
>>
>> Option #2. Like I wrote before, this is a nontrivial problem. I have a
>> small, trivial fix waiting for months on end to get integrated. If I have to
>> wait that long for a trivial fix to get integrated, just imagine how much
>> time it'll take to get *three* major revisions on three commands integrated
>> into OpenSolaris! `useradd` and `userdel` might be easier to solve. But
>> `passwd`, now that's going to be hard. There are simply too many things to
>> consider, and I might not stand a chance.
>
>I'm not so sure that getting changes into passwd will be any easier or
>harder than useradd and userdel. On the surface, I think that
>changing passwd is less involved than changing useradd or userdel.
>
>I've generally had very good response from those sponsoring my
>changes. Straight-forward and non-controversial changes have been
>integrated within a couple weeks. However one of my changes (6471646)
>got stalled waiting on another fix (6356629). Now that I look back on
>it, I see that the person that I was waiting on left Sun and is no
>longer working on it.
But changes to useradd will not help in the short term; those changes
should be made, but they cannot be used in postinstall scripts.
Casper
