Reindl Harald wrote on Fri, 20 Sep 2013 14:32:46 +0200:
/etc/rc.d/rc.local
Thanks for all the answers.
First, I omitted to explicitely state that these are web servers. There is no dhcp, only one or, in a few cases, a few IP static IP addresses. Mostly Centos 5. Changing the data is *not* the problem. As already said this will mostly be done by replacing config files (cp -a, not mv, this assures it can be done even more than once without a problem, replacement operations in files always ask for trouble if something non-standard happens, not to mention one has to code this - it's easier just to provide the correct new files), and by reading in a sql command that replaces an IP address in some tables.
The big question is when and how to do this.
rc.local seems to be a good place for reading in the sql command. But it doesn't seem to be a good place for all the other commands, especially the initial network setup. It's executed *after* all ini stuff is done, e.g. all daemons and network are started. Problem is that some network services may hang the whole machine for a minute or longer if they cannot establish networking (which would be the case with wrong data either for the ifcfg files or the config file of the daemon). At the moment I know of only one daemon which behaves this way (bigsister), but I may have forgotten about others. I don't want to wait until the timeout kicks in, the init continues and rc.local eventually issues a service network restart.
So, I would rather do all the "replace file" operations before any of that init stuff gets done. Is this possible without much ado? Or should I rather do the "replace file" operations at shutdown (how, when?) and execute only the sql command from rc.local? Google suggests a file /etc/rc.shutdown (or rc.local.shutdown?) which, if I understand correctly, would be carried out after the init stuff for the shutdown (rc0) has been done.
Kai
Kai Schaetzl wrote on Wed, 25 Sep 2013 10:58:51 +0200:
Google suggests a file /etc/rc.shutdown (or rc.local.shutdown?) which, if I understand correctly, would be carried out after the init stuff for the shutdown (rc0) has been done.
rc.local.shutdown or rc.halt don't work. Seems I have to use an init script in rc0.d?
Kai
Kai Schaetzl wrote on Wed, 25 Sep 2013 13:00:19 +0200:
Seems I have to use an init script in rc0.d?
I tested the following: /etc/rc.d/rc0.d/K000halt /etc/rc.d/rc0.d/K99zhalt /etc/rc.d/rc0.d/S000halt /etc/rc.d/rc0.d/S999halt
Only /etc/rc.d/rc0.d/S000halt gets executed, e.g. the file that gets executed before killall and halt. Why don't the K* links get executed? There are lots of other K* files, obviously for a reason. When are they executed? (I mean I don't see that I could leave a level 0 state to enter another runlevel.)
It's not quite clear to me when S000halt gets executed. As I understand it's run when entering this runlevel and this runlevel is entered exactly when? At the very end of the shutdown after all daemons have been stopped? Basically the "state" of being shutdown or is it entered immediately after entering the shutdown command?
Kai
On Wed, Sep 25, 2013 at 3:58 AM, Kai Schaetzl maillists@conactive.com wrote:
First, I omitted to explicitely state that these are web servers. There is no dhcp, only one or, in a few cases, a few IP static IP addresses. Mostly Centos 5. Changing the data is *not* the problem. As already said this will mostly be done by replacing config files (cp -a, not mv, this assures it can be done even more than once without a problem, replacement operations in files always ask for trouble if something non-standard happens, not to mention one has to code this - it's easier just to provide the correct new files), and by reading in a sql command that replaces an IP address in some tables.
The big question is when and how to do this.
Why don't you just do it (except maybe the sql thing) before the shutdown? That is, instead of putting a script in place and changing something else to schedule a later run, just run it and be done. You probably already have a way to control them via ssh from a single location anyway - just run a script there that does them all at once close to shutdown time. The config file changes won't take effect until a reboot anyway. The sql change is more of a special case though. Unless you know all of the code involved, it's likely that some other components are going to read and cache the old values and not update after your change. I'd try to shut that box down last and make the change at the very end. Or make sure it starts first and has the new values before anything else can connect - otherwise you may have to restart the other components. If your sql command sets a field value where the old value matches your old addresses and there is no overlap in new/old ranges then it wouldn't hurt to run multiple times so you shouldn't have to be careful about that part..
-
Kai Schaetzl -
Les Mikesell