On Sat, 21 Apr 2007, Troy Dawson wrote:

> Please test the following release.  There should only be minor changes before 
> the release.  We plan on testing this for at least a week.

I just spotted an oddity which may have been present in earlier alpha/beta 
versions, and is almost certainly an upstream issue but maybe someone can 
enlighten me...

While testing kickstart installs I used something loosely based on the cfg 
we had been using for SL4, which contains (roughly) the following bits:

...
rootpw --iscrypted $1<a-real-passwd>
...
authconfig --enablemd5 --enablenis --nisdomain nis.damtp.cam.ac.uk --enablecache
...
selinux --enforcing
...

with this setup the installed machine does not get the crypted password 
inserted into /etc/passwd instead we get a root line like:

root:*:0:0:root:/root:/bin/bash

ie with * not the crypted password we provide.  If I change the authconfig 
line to include --enableshadow, then the password is inserted into 
/etc/shadow as expected.

Historically we didn't enable shadow because it used to cause problems for 
us with other things, but we may be able to leave it on now...  Anyway it 
might possibly affect others, or maybe we have something else wrong...

A quick scan of the anaconda sources doesn't show any code which attempts 
to actually update the passwd/shadow files and while in users.py there is 
a setRootPassword definition, it simply calls code that I can't find the 
definition of (self.admin.setpassUser and self.admin.modifyUser).

I'm sure that the code for setpassUser/modifyUser must be somewhere, but 
I'm starting to wonder if selinux is at least in part to blame...

Because of other problems it seems I can't run with selinux enabled, or at 
least not right away.  Our %post fragment edits /etc/passwd (which works) 
and a few other trivial things, and drops in a script 'postinstall' to be 
run fairly late on in the boot.

The postinstall script attemts to update several files in /etc (and other 
places) using rsync -- and script fails because selinux won't let us copy 
files to there using rsync.  If I log in as root (when I can!) after the 
script has failed and run the bits by hand they all appear to work, it 
also seems to (mostly) work from a later reboot, so there seems to be some 
state getting set but I can't spot what it is...

Maybe if I get a little more time I'll try to find out if we can do better 
than using 'selinux --permissive' but I'm using a fairly blunt instrument 
for now...

  -- Jon