I'm setting some servers that basically need to manage themselves after I leave the company, as I'm just the contract IT guy. Whoever manages this should basically be able to clone a VM image in ESXi, and when it starts up, it needs to configure itself.

I know, you're probably saying "Use Puppet or Chef" or "Use Docker", well thats what I thought too, but thats apparently too complicated for this setup, they're going with the "less is more" approach.

These servers need to have a static IP address, so what I was thinking is when it starts up the very first time, I could have it pull an IP via DHCP, then re-configure the /etc/sysconfig/network-scripts/ifcfg-enp0s3 file, using the current IP address as DHCP, and maybe even get super fancy, like test if it works, if not, revert the ifcfg-en0s3 file, get it on the network, then email someone that the server needs some manual attention, whatever works.

The above might be more information than you need, because all I need to know how to do is have a script run on the very first startup. Adding it to any runlevel will have it execute every time it starts up at that runlevel.

I was thinking I could have it in runlevel 3, then once it configures itself, just remove the symlink in the rc3.d folder to the script... But thats kinda my backup option, if I can't find a way to just have it execute on the "next startup".

I also thought about just using @reboot with a cron job, but again, that have to remove itself from the crontab.

If someone helps me find a different solution for the static IP configuration thing, thats fine, but I still need to know the best way to have a script start on the next boot (at specified runlevels), because it's needed for other tasks as well.


P.S. I realize that having the script do things like removing itself from the crontab or rc.d directories isn't necessarily a big deal, I just kinda thought it was jimmy-rigging it, and thought there may already be an alternative way, something thats meant to execute once, on the next reboot. But if not, then either of the two previous approaches would suffice

P.S.S. I found a similar topic here, which has a script execute @reboot, and checks for any files/scripts within a specified directory that need to be executed, then moves them to disable them. I suppose that would work, I may do something like symlink them to the directory instead of moving the files themselves around, but if thats the best solution, then it'll suffice. (whatever gets the job done :-) )

2 Answers 2


fairly simply - add it as a startup script - last line of script after checking all ok etc:

rm $0

  • 1
    Is this the way its typically done? I just figured there would be something like crontab or init.d, only would execute for the next boot. But if not, then id just remove the execution of it, not the script itself. (Incase it needs to be set to execute again...)
    – Justin
    Apr 8, 2016 at 15:20

I've written the 'firstboot' script for multiple physical and virtual storage appliances over the past fifteen years, and always used the 'rm' of the symlink upon successful completion of the first boot to make sure it doesn't run on future boots.

The other possibility is setting a sentinel file like '/FIRSTBOOT' upon finishing the first boot, then add a line 'if [ -f /FIRSTBOOT ] ; then ; exit 0 ; fi' to the top of the script. That would give the option of removing the sentinel file and rebooting if you ever need to reconfigure the virtual machine again, which is easier for most people than symlinking an obscure file to an obscure directory somewhere in the system.

You're on Centos 7 so you have systemd rather than the SysV init. So the sentinel file might be easier for you.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .