SOLVED Changing IP address post fog install is problematic

  • @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.

  • 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
    sed -i "s|exit 0|make_fog_portable &|g" /etc/rc.local
    echo ' ' >> /etc/rc.local
    echo 'exit 0' >> /etc/rc.local
    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 ]
    	echo "Waiting :05 for an IP Address" > /dev/kmsg
    	sleep 5
    	IP=`ip addr list eth0 | grep "inet " |cut -d" " -f6|cut -d/ -f1`
    # 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
    if [ -f /etc/centos-release ]; then
    cd /var/www/html/fog/lib/fog
    cp -f config.class.php config.class.php.old
    sed -i "s|\".*\..*\..*\..*\"|\$_SERVER['SERVER_ADDR']|" config.class.php

    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*

  • @george1421 said:

    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. 🙂


  • Moderator

    @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:

    1. Update the settings in the /opt/fog/.fogsettings
    2. Rerun the installer
    3. Update the IP address for the storage node on the FOG system where you changed the IP address
    4. Update the IP address on a any master storage node that may reference this FOG server
    5. Update the FOG_WEB_HOST value
    6. 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]

  • @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?

  • Moderator

    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.

  • 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?