I'm building kickstart files for use in doing automated installs of various systems. I would prefer to do fairly minimal amounts of work in the "%post" and postpone further installation and configuration until after the first reboot (or even later). It should be easy enough to add something to rc.local that will download scripts and run them, but I'm wondering if there is a preferred technique. I haven't found anything in the Red Hat documentation I've read so far.
This isn't about figuring out a way to do the update, it's about trying to follow the "Law Of Least Astonishment". I've dealt with too many really screwed up systems that had customised stuff everywhere and nothing worked as expected.
Suggestions?
-- Matt
Matt Lawrence a400hz@gmail.com wrote:
I'm building kickstart files for use in doing automated installs of various systems. I would prefer to do fairly minimal amounts of work in the "%post" and postpone further installation and configuration until after the first reboot (or even later). It should be easy enough to add something to rc.local that will download scripts and run them, but
I'm
wondering if there is a preferred technique. I haven't found anything in the Red Hat documentation I've read so far.
Read up on the Red Hat "Setup Agent" aka "firstboot".
There is a "firstboot" init script (e.g., /etc/init.d/firstboot) that looks for select files (e.g., /etc/sysconfig/firstboot). Depending whether it exists or doesn't exist, the firstboot init script -- if set to start for the run-level -- does or doesn't do something. It will then create/delete the file at the end of the run, as appropriate, to prevent it from running next time.
This is a good practice -- create an initscript that looking for the existance of a file, and acts accordingly -- creating/deleting at the end to prevent it from running the next time. The initscript itself can also be disabled so there is no chance of it running, regardless of the file.
This isn't about figuring out a way to do the update, it's about trying to follow the "Law Of Least Astonishment". I've dealt with too many really screwed up systems that had customised stuff everywhere and nothing worked as expected. Suggestions?
I'm not saying that's what you should do, you could put some similar logic in /etc/rc.d/rc.local. You could just put the commands in /etc/rc.d/rc.local and delete them or disable them (maybe with a "sed -e" command).
Or you could put a conditional in /etc/rc.d/rc.local, look for the existance of a file, and run/not run the commands based on its existance.
But in either case it means you have to run an "echo >>" or "sed -e" command to modify /etc/rc.d/rc.local.
It's much easier just to plunk down 2 files -- one in /etc/init.d/ and one in /etc/sysconfig/ (or wherever you want to put it). You can do put those commands to copy those files in the "%post" section. Or you can put them in their own RPM too, including running "chkconfig --level" to enable/disable it's execution at start-up as part of the RPM.
There are a lot of options. I just find (and this is just my experience/preference), that the little extra time in creating an /etc/init.d/ script (with a simple start|stop|status parameter) and associated config/flag file, is a lot easier and less ambiguous than running "echo >>" or, better yet, "sed -e" on /etc/rc.d/rc.local.
On 12/9/05, Bryan J. Smith thebs413@earthlink.net wrote:
Read up on the Red Hat "Setup Agent" aka "firstboot".
There is a "firstboot" init script (e.g., /etc/init.d/firstboot) that looks for select files (e.g., /etc/sysconfig/firstboot). Depending whether it exists or doesn't exist, the firstboot init script -- if set to start for the run-level -- does or doesn't do something. It will then create/delete the file at the end of the run, as appropriate, to prevent it from running next time.
The firstboot package has various dependencies that I don't really want. But it could be a good model.
It's much easier just to plunk down 2 files -- one in /etc/init.d/ and one in /etc/sysconfig/ (or wherever you want to put it). You can do put those commands to copy those files in the "%post" section. Or you can put them in their own RPM too, including running "chkconfig --level" to enable/disable it's execution at start-up as part of the RPM.
Given the limitations of what can actually be run during the %post phase, I'm not sure if it is easier. There are warnings about lack of name resolution if the system is configured for DHCP.
While it is possible for me to install a custom package before the first reboot, mixing it in with all the CentOS packages in the install server seems to be a really bad idea. With the potential lack of name resolution, the other option would be to install via FTP, but that requires hardcoding the IP address. Not a great idea either.
There are a lot of options. I just find (and this is just my experience/preference), that the little extra time in creating an /etc/init.d/ script (with a simple start|stop|status parameter) and associated config/flag file, is a lot easier and less ambiguous than running "echo >>" or, better yet, "sed -e" on /etc/rc.d/rc.local.
Good point, but how do you suggest I bootstrap it in?
-- Matt
On Fri, 9 Dec 2005, Matt Lawrence wrote:
Given the limitations of what can actually be run during the %post phase, I'm not sure if it is easier. There are warnings about lack of name resolution if the system is configured for DHCP.
fwiw, I've historically (Red Hat 7 -> Fedora Core 3) had no trouble getting name resolution in %post scripts, e.g., I'd frequently use wget to retrieve config/bootstrap files from a remote web server.
Hi Matt,
The issue you are talking about here is classic kickstart %post material. If your network is not setup, activate the network in %post as well - it would work fine.
Once anaconda has setup the system, %post commands are run inside a chroot to the the newly installed system. have you tried running dhclient in %post ?
Something completely off the top of my head : why not use a %post --nochroot and copy the running environments resolv.conf into the /mnt/sysimage/etc/ directory :) might work, might not. please try and let us know how you get along!
Matt Lawrence wrote:
There is a "firstboot" init script (e.g., /etc/init.d/firstboot) that looks for select files (e.g., /etc/sysconfig/firstboot). Depending whether it exists or doesn't exist, the firstboot init script -- if set to start for the run-level -- does or doesn't do something. It will then create/delete the file at the end of the run, as appropriate, to prevent it from running next time.
The firstboot package has various dependencies that I don't really want. But it could be a good model.
If you do decide to go down this route look at : /usr/share/firstboot a lot of the dep's for firstboot itself come from its requests on X, looking through the code - you should be able to easily work around that. Specific files you prolly want to look at are
firstboot.py and textWindow.py
Add hooks at an appropriate place.
Given the limitations of what can actually be run during the %post phase, I'm not sure if it is easier. There are warnings about lack of name resolution if the system is configured for DHCP.
I havent seen this...
While it is possible for me to install a custom package before the first reboot, mixing it in with all the CentOS packages in the install server seems to be a really bad idea.
yeah :) avoideable. You are otherwise looking at rebuilding installer components.
There are a lot of options. I just find (and this is just my experience/preference), that the little extra time in creating an /etc/init.d/ script (with a simple start|stop|status parameter) and associated config/flag file, is a lot easier and less ambiguous than running "echo >>" or, better yet, "sed -e" on /etc/rc.d/rc.local.
Good point, but how do you suggest I bootstrap it in?
perhaps, rpm install into the sysimage chroot ?
Karanbir Singh Mail-Lists@karan.org wrote:
Something completely off the top of my head : why not use a %post --nochroot and copy the running environments
resolv.conf
into the /mnt/sysimage/etc/ directory :) might work, might
not.
please try and let us know how you get along!
That's _exactly_ what I do when I haven't pre-packaged it into a RPM.
If you do decide to go down this route look at : /usr/share/firstboot a lot of the dep's for firstboot itself come from its requests on X, looking through the code - you should be able to easily work around that. Specific files you prolly want to look at are firstboot.py and textWindow.py Add hooks at an appropriate place.
Oh, I just meant the firstboot bash initscript, not the GUI "Setup Agent" it runs. There is enough in the firstboot bash script to show you how it does its simple conditionals.
Matt Lawrence wrote:
There is a "firstboot" init script (e.g., /etc/init.d/firstboot) that looks for select files (e.g., /etc/sysconfig/firstboot). Depending whether it exists or doesn't exist, the firstboot init script -- if set to start for the run-level -- does or doesn't do something. It will then create/delete the file at the end of the run, as appropriate, to prevent it from running next time.
The firstboot package has various dependencies that I don't really want. But it could be a good model.
You might also want to keep in mind that firstboot is run only when the /etc/reconfigSys file exists. The /etc/sysconfig/firstboot file is only checked by firstboot itself....
and you need something like :
firstboot --reconfig
in the ks.cfg to get that setup properly.
On 12/9/05, Bryan J. Smith thebs413@earthlink.net wrote:
Matt Lawrence a400hz@gmail.com wrote:
I'm building kickstart files for use in doing automated installs of various systems. I would prefer to do fairly minimal amounts of work in the "%post" and postpone further installation and configuration until after the first reboot (or even later). It should be easy enough to add something to rc.local that will download scripts and run them, but
I'm
wondering if there is a preferred technique. I haven't found anything in the Red Hat documentation I've read so far.
Read up on the Red Hat "Setup Agent" aka "firstboot".
An interesting topic. I'm currently building a kickstart procedure for installing new workstations. We have quite a bit of needed customization to put a workstation on our network and provide additional products (updated versions of OpenOffice and Firefox, for example). This is an RHEL3 level system, so some of the standard offerings are just too old. My preference is to put everything possible into %post, and I've packaged the modifications in a repository which can be NFS mounted at the start of post. All of this could be easily tweaked when we move to RHEL4. Two functions, however, have to run at first boot. 1) setting up directories and keys for system administrators (we use LDAP, so their uid/gid is not known at %post time, and I don't want to hard code this) 2) installing the latest ATI video driver for those units with a video not supported by RHEL3.
What I've done is modelled after the firstboot procedure. I just put a simple script in rc.local that checks for a script by name, invokes it, and moves the script to a backup name. Works pretty well for me.
HTH.
-- Collins Richey Debugging is twice as hard as writing the code ... If you write the code as cleverly as possible, you are, by definition, not smart enough to debug it. -Brian Kernighan
On Fri, 2005-12-09 at 19:46 -0700, Collins Richey wrote:
An interesting topic ...
I'm going to move my response to the new "Practices" list in the interest of not bogging down the list with Anaconda and other details that aren't specific to CentOS.
If you want to join, here's the link again: http://www.paxconsultoria.com/mailman/listinfo/linux-practices
I'll CC all the participants that were involved with this thread. Please don't slam me for doing so (as others have in the past), as this extra effort I make is with the list in-mind.
-
Bryan J. Smith -
Collins Richey -
Karanbir Singh -
Matt Lawrence -
Paul Heinlein