SOLVED Changing IP address post fog install is problematic
Wayne Workman last edited by Wayne Workman
@sudburr now that is sweet! This is great work. It would have taken me several long hours to get to the point where you’ve come to. From here, it’s a hop, skip, and a jump to mix this with dnsmasq.
sudburr last edited by sudburr
In its simplest form that we run, some of our FOG servers are stationary, others move around. For us to have a single solution build that works for any location, all of our FOG servers are configured to grab an IP via external DHCP reservation.
I copy and paste the following to the CLI to edit rc.local:
cp -f /etc/rc.local /etc/rc.local.old if [ -f /etc/centos-release ]; then echo ' ' >> /etc/rc.local echo 'make_fog_portable' >> /etc/rc.local echo ' ' >> /etc/rc.local else sed -i "s|exit 0|make_fog_portable &|g" /etc/rc.local echo ' ' >> /etc/rc.local echo 'exit 0' >> /etc/rc.local fi chmod 755 /etc/rc.local echo '#!/bin/bash' > /bin/make_fog_portable echo '#' >> /bin/make_fog_portable echo '# make_fog_portable &' >> /bin/make_fog_portable echo '#' >> /bin/make_fog_portable echo '# This script is expected to be run as a job from /etc/rc.local' >> /bin/make_fog_portable echo '# It will wait until an IP address is found, then use that IP' >> /bin/make_fog_portable echo '# address to configure the FOG Server for that site.' >> /bin/make_fog_portable echo '#' >> /bin/make_fog_portable echo ' ' >> /bin/make_fog_portable echo 'exit 0' >> /bin/make_fog_portable chmod 755 /bin/make_fog_portable vim /bin/make_fog_portable
At the now open file ‘make_fog_portable’ Insert the following, before “exit 0” ; [ESC]:wq to write/quit
# Wait for an IP address IP=`ip addr list eth0 | grep "inet " |cut -d" " -f6|cut -d/ -f1` while [ -z $IP ] do echo "Waiting :05 for an IP Address" > /dev/kmsg sleep 5 IP=`ip addr list eth0 | grep "inet " |cut -d" " -f6|cut -d/ -f1` done # Make FOG Server Portable sleep 6 echo "Updating IP address for FOG_TFTP_HOST to be $IP [`date`]" > /dev/kmsg mysql --user=root -e "UPDATE \`globalSettings\` SET \`settingValue\` = '$IP' WHERE \`settingKey\` ='FOG_TFTP_HOST';" fog echo "Updating IP address for FOG_WEB_HOST to be $IP [`date`]" > /dev/kmsg mysql --user=root -e "UPDATE \`globalSettings\` SET \`settingValue\` = '$IP' WHERE \`settingKey\` ='FOG_WEB_HOST';" fog echo "Updating IP address for FOG_WOL_HOST to be $IP [`date`]" > /dev/kmsg mysql --user=root -e "UPDATE \`globalSettings\` SET \`settingValue\` = '$IP' WHERE \`settingKey\` ='FOG_WOL_HOST';" fog echo "Updating IP address for Storage Node DefaultMember to be $IP [`date`]" > /dev/kmsg mysql --user=root -e "UPDATE \`nfsGroupMembers\` SET \`ngmHostname\` = '$IP' WHERE \`ngmMemberName\` ='DefaultMember';" fog echo "Updating IP address in file .fogsettings to be $IP [`date`]" > /dev/kmsg sed -i "s|ipaddress=\".*\"|ipaddress=\"$IP\"|" /opt/fog/.fogsettings echo "Updating IP address in file default.ipxe to be $IP [`date`]" > /dev/kmsg sed -i "s|http://\([^/]\+\)/|http://$IP/|" /tftpboot/default.ipxe sed -i "s|http:///|http://$IP/|" /tftpboot/default.ipxe echo "Sleeping 10 seconds before releasing script [`date`]" > /dev/kmsg sleep 10 echo "releasing script [`date`]" > /dev/kmsg
Complete the generalization with this; you will also need to run this after any FOG trunk update:
if [ -f /etc/debian_version ]; then cd /var/www/fog/lib/fog fi if [ -f /etc/centos-release ]; then cd /var/www/html/fog/lib/fog fi cp -f config.class.php config.class.php.old sed -i "s|\".*\..*\..*\..*\"|\$_SERVER['SERVER_ADDR']|" config.class.php reboot
Why a job at startup? In the case of a power failure, the FOG server itself whether it be physical or virtual will almost invariably be available long before the site’s switches finish their POSTs and the network is available again. The loop to check for an IP prevents the FOG server coming up without an IP or in the case of a mobile server, forces the new IP into FOG’s configuration before it has a chance to start.
This solution even allows us to change the subnet entirely and the server will always, automatically reconfigure itself according to the new DHCP reservation.
Works like a charm.
This works on Ubuntu 14-, 15+, Debian 8+ and CentOS 7.
It is into this make_fog_portable job that I would also add any code for restarting critical services:
# Ubuntu 14- sleep 6 echo "Restarting tftpd-hpa [`date`]" > /dev/kmsg service tftpd-hpa restart sleep 6 echo "Restarting mysql [`date`]" > /dev/kmsg service mysql restart sleep 6 echo "Restarting FOGMulticastManager [`date`]" > /dev/kmsg service FOGMulticastManager restart # Debian 8+, Ubuntu 15+ if [ -f /etc/debian_version ]; then echo "Restarting Critical FOG Services [`date`]" > /dev/kmsg systemctl restart tftp* mysql* FOG* apache* fi
Wayne Workman last edited by Wayne Workman
However this could be also addressed with a wiki page.
I’m actually working on this. Here’s links for future readers:
I’m going to work on that and a few other articles over my 2 week x-mas vacation.
@Tom-Elliott The probably the easiest solution is to create a procedure (wiki page) that if you need to update your fog server you need to do:
- Update the settings in the /opt/fog/.fogsettings
- Rerun the installer
- Update the IP address for the storage node on the FOG system where you changed the IP address
- Update the IP address on a any master storage node that may reference this FOG server
- Update the FOG_WEB_HOST value
- update the FOG_TFTP_HOST value
I can I’ll marked this as addressed (Solved), since its not a technical solution but a procedural one that resolves the issue.
[Edit] I would, but it appears I can no longer mark topics as solved[/Edit]
Tom Elliott last edited by
@george1421 The impact would be more that if you have multiple storage nodes (multiple ip address and what not) how will we know which one to update?
I also understand what you are saying, but what would the impact be if the installer just blindly updated the current values (what ever they are) to the settings found in the .fogsettings file?
However this could be also addressed with a wiki page. Once the settings were found the fog server did work as intended at the new IP address. In the end this was my own fault for being lazy and letting dhcp setup the OS and not remembering to put it at the final IP address before fog was installed.
Tom Elliott last edited by
While I do understand the issues it’s not exactly that simple to make those adjustments. This, you should remember, is because storage nodes do the same type of file. While I do understand what you’re saying, if the ip/hostname changes how does the installer know what the original values were? In the case of of a setup with multiple nodes and potentially a separate server, how would you propose this be done? How can fog be told the original from the new? Especially if you migrate the original db to the new server?