Invalid StorageNode with Multiple IPs



  • [FONT=sans-serif]I started out a few days ago troubleshooting multicast deployments. The deployments would hang up at the start of the ‘partclone’ or the ‘partimage’ screen. So I went through the multicast troubleshooting steps from the wiki. All of the multicast tests worked perfectly from the command line. I then noticed that the FOGMulticastManager was not running. So I started that up. I still had the same hangup. The log revealed a message of “StorageNode Not found on this system.” every 10 seconds. I went through my storage node settings (which were all default) in Fog and could not locate any issues. I dug through the sql database to ensure that everything looked as it should as far as images and storage goes. That was all normal. So I started backtracing the error message inside the PHP source code. After many frustrating hours, I finally found the issue and made a quick patch for my system.

    The issue turned out to be in the getIPAddress() function in the FOGCore.class.php file. My server has 3 different IP addresses. There is a management interface (eth0) for myself (SSH, etc) with an IP of 172.20.3.31. There is the main interface (eth1) for my techs with an IP of 192.168.168.20. This is the interface that my techs access the FOG web interface on, as well as the imaging data traffic, etc. The third interface is on the data storage network. It is eth2 and has an IP address of 10.10.50.134. This is the interface that is used to connect to our SAN where the images are stored. The LUN is mounted at /images and that is why the default storage node is used.

    So getting on to the issue, getIPAddress() pulls all IPs and trims all the fat while skipping over 127.0.0.1. After the foreach loop, it returns $output, which at that point would be set to the last address in the array. Which in my case would be 10.10.50.134. Which is incorrect and would fail imaging in my environment. I made a quick patch to the PHP file on my system from “ifconfig” to “ifconfig eth1”. That way after all the fat-trimming is done, only 192.168.168.20 is returned as $output. I then tested and everything worked normally.

    The fix to this should be a check of the IP against the IP that is in the settings and break the foreach loop and thus returning the proper IP.

    I am attaching a quick screenshot of my terminal, just to help out on visualization. Keep in mind that eth1 is the interface used for imaging data traffic in my environment. The second command typed is copied and pasted directly from the stock getIPAddress() function inside FOGCore.class.php. As you can see, the storage address is outputted after the data address and would be used since the fourth (loopback) address is completely ignored by getIPAddress().

    I was told by sysadmin922 in IRC to post what I found on the forums for mastacontrola. Please let me know if I can be of any further assistance.

    sirEgghead[/FONT]

    [url="/_imported_xf_attachments/0/855_Selection_003.png?:"]Selection_003.png[/url]


  • Senior Developer

    Cool,

    I also, hopefully, fixed the image replicator as well to have, basically the same information.



  • I will be glad to test. Tomorrow is our last day before deployment. I know my patch (only for my environment) works. So I always have that to fall back on. But in the mean time, I will be glad to test any patch.


  • Senior Developer

    [quote=“Scott Gusler, post: 28553, member: 24231”]Proper patch attached.[/quote]

    I’m going to go with a different approach. Doing it without getting the proper ip could be an error of ways. This I say because you can have a master node without it being the real FOG Server. Thanks for pointing out and getting all the info though. I’ll post and hopefully you all can test tomorrow?



  • Proper patch attached. (retracted)


Log in to reply
 

408
Online

38951
Users

10701
Topics

101532
Posts

Looks like your connection to FOG Project was lost, please wait while we try to reconnect.