[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Where oh where has my 'anaconda --reconfig' gone?



Oh where oh where can it be?  It was so nice.  Pardon for the long post,

but it's rather detailed.  I'll endeavor to be as brief as possible.

To summarize; we are installing our software under RedHat 9 via a PXE 
server and kickstart files.  After the updated OS tree has been laid 
down, the %post section of kickstart then installs our software under 
user 'vericept', group 'vericept' (via useradd in one of the RPMs).  We 
then set the machine to an initial boot state, so our customers will be 
presented with the off-the-shelf initial RedHat configuration
environment.

When we were doing the same thing under RedHat 7.3, we were able to run 
'anaconda --reconfig' in a script fired from /etc/rc.local.  Using 
anaconda in this way would give a user of a minimally installed, 
non-graphical, text only system the same initial configuration 
capabilities as a user with a default X based environment.  Very nice 
indeed.  However, under RedHat 9, things seem to be much different. 
 I've tried several things. Here's a synopsis of what I've discovered so

far:

grepping through /etc, I discovered in /etc/rc.sysinit the 'touch 
/.unconfigured' method:

    - runs the text only based system configuration tools, as compared 
to 'anaconda --reconfig' which operates under both character and 
graphical environments equally.
    - configures root password (using /usr/bin/passwd)
    - configures networking for the first ethernet device only (uses 
/usr/sbin/netconfig)
    - configures User Configuration Information (cache, NIS, LDAP, 
Hesiod) (uses /usr/sbin/authconfig)
    - configures Authentication (Shadow, MD5, LDAP, Kerberos, SMB auth.)

(also part of authconig)
    - configures system services, however neither did 'anaconda 
--reconfig' (uses /usr/sbin/ntsysv)
    - does NOT configure firewall
    - does NOT configure date/time
    - does NOT configure timezone, although the script should be calling

it (a bug?)


Continuing to peruse /etc for more solutions, I ran into firstboot.  I 
consulted (for the Nth time) the RedHat reference, and determined the 
sequence of commands to set the machine to run firstboot are:

    rm -f /etc/sysconfig/firstboot
    touch /etc/reconfigSys
    chkconfig --level 5 firstboot on

This environment has its own peculiarities (only key items we're 
interested in are mentioned):

    - it ONLY runs under a graphical environment, compared to 'anaconda 
--reconfig' which runs under both
    - configures the root password (redundant if also used with 'touch 
/.unconfigured')
    - configures 'User Account', but changes the UID and GID of the 
vericept user (GID 500) if the password is changed at this level, but 
leaves the vericept owned files still belonging to the old group (which 
affects some of our services).
    - configures the security level, but does not have a typein box to 
add additional services / protocols (which we need)
    - configures date and time, and as a bonus, ntp
    - does NOT configure timezone
    - does NOT configure network
    - does NOT configure system services

Researching further, I found out the following regarding the 
redhat-config-<blah> scripts:

    - redhat-config-date does everything that the similar section in 
firstboot does, and also has the timezone configuration in it, but only 
runs graphically .
    - redhat-config-network configures all ethernet devices on the 
system, but only runs graphically.
    - redhat-config-securitylevel still does not have a text box for 
entering in additional services / protocols, and only runs graphically
    - lokkit does have the text entry box for additional rules, however 
it is only character based.

Finally, I also looked at /bin/setup:

    - looks largely like a curses based front-end to the same utilities 
run from /etc/rc.sysinit when one does 'touch /.unconfigured', and has 
the same deficiencies.


Ultimately, for our graphics users, it looks like we have to roll our 
own mechanism for firing off the appropriate redhat-configure-<blah> 
scripts in the order we wish them presented to the user, and possibly 
rewrite (or fix) the ones that do not provide all the capability we 
require, whereas our customers that prefer a trimmed down installation 
to put on a rackmount server will have to suffice with a text editor and

know the ropes of the configuration files, or we write a utility to 
front-end them (or add all the '-tui' interfaces to the redhat-config 
scripts)


Where oh where has my 'anaconda --reconfig' gone, oh where oh where can 
it be........


David H. Goodlette
Senior Software Engineer
Vericept Corporation
dave goodlette vericept com





[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]