FOG Trunk 5161 AutoNumbering
-
Nevermind what I said.
I found the autonumber bug and fixed it as well as a rather disastrous bug and a couple other minor bugs. I even added some partial functionality that the auto number system will auto populate itself and increase until it finds a host that does not have that number automatically.
-
@StahnAileron Look at the pictures below, these pictures were taken from my home FOG server. On it, if I wanted, I could have many nodes; even though it’s only just one “self contained” server. To multicast, I think you have to have a Master Node set, and the interface for that node must be correct.
-
@Tom-Elliott @Wayne-Workman Oh my… Thank you both!
I thought I already checked the interface. I was having minor issues with that when we switched from 1.2 to Trunk. Guess I didn’t check hard enough (though I never would’ve thought to check the interface name in relation to UDP Multicasting.) I’ll be double-checking once I’m in to look at the server.
@Tom-Elliott Thanks for the quick fixes to that (those) bug(s)! I’ll be heading in to my school in a few hours. I’m guessing I’ll just have to update the trunk copy I have (via SVN) and “re-install”/update FOG, correct?
Again, thank you for the help and support. I’ll follow up with a progress report once I get to work on the server once more.
-
@StahnAileron said:
I’m guessing I’ll just have to update the trunk copy I have (via SVN) and “re-install”/update FOG, correct?
Yup.
-
For future readers, I’ve further updated the troubleshooting multicast article based on things I’ve posted in here.
https://wiki.fogproject.org/wiki/index.php/Troubleshoot_Downloading_-_Multicast
-
Well, the auto-naming/-numbering now works. Registering hosts for imaging is now far easier. Thanks for the quick fix!
As for multicasting: still having problems. I did check the interface name for the relevant settings (for the master node and one under FOG Settings). Still stalls at the Partclone screen. However, the FOG log still states that the various multicasting services are perpetually crashing and restarting. I’m guessing this is the current issue I need to resolve to get multicasting to work. They each stop working with the log stating they exit with error 255. If the services keep crashing, I assume that would screw over the multicasting jobs I set, no? What can I look at and/or try to stabilize the services?
-
@StahnAileron Try to start the fog services 30 seconds after boot. There is an example in this article: https://wiki.fogproject.org/wiki/index.php/Fedora_21_Server
Also, try to clear out the two relevant tables in MySQL, there are steps for that here: https://wiki.fogproject.org/wiki/index.php/Troubleshoot_Downloading_-_Multicast
Also, to further simplify the problem, you might try to use a basic non-managed Layer 2 switch to multicast with till you get it working.
-
@Wayne-Workman I’ll try the procedures you posted. We do have a managed switch in the mix out of 3 total. The others are dumb switches. I’ll look into getting it arranged (physically) so the managed switch is out of the loop. It didn’t give us problems with the FOG 0.32 server we had originally, but shrug never know, right?
-
Final Progress Report
So I actually got Multicasting to work. Apparently the switch from 1.2 to Trunk left some files behind and/or wasn’t truly complete. Some stuff I had tinkered with in 1.2 was held over in Trunk. So I essentially screwed myself over on that one.
In any event, trimming down the install (i.e. deleting almost everything from FOG), pulling a fresh copy of the trunk via SVN, and MAKING SURE the installation truly completed all the way fixed my problems. I hate self-induced problems like this, but live and learn.
Thanks for all the help! I now have a better feel for mucking around in FOG.
Some thoughts:
I noticed that if I had DHCP already running the script would abort because setting up DHCP failed. This apparently was part of my problem. (I wasn’t paying enough attention until my attempts at re-installing the system pointed me to an incomplete re-installation process.) I had to comment out that line in the script to make it easier to re-install FOG. DCHP was always running. (I’d just restart manually it afterwards, just in case.) It seems that the script interprets DHCP already running as a failure. (It doesn’t seem to have this problem with any other running service.)
Also, would it be too much to ask for an option in the installation script to purge the current settings and start fresh? I had to delete the hidden .fogsettings file a couple of times during my endeavor.
-
@StahnAileron the script for the installer already has a switch to disable update and perform a full/fresh install. It can be done with:
./installfog.sh -Uor./installfog.sh --no-upgrade -
@Tom-Elliott Oh, did not know that. I was using the Wiki as a reference and it never mentioned that switch. The Wiki simply states to delete the .fogsettings file. Nice to know that now. I’ll have to take note of that for our documentation.
-
@StahnAileron I’ve added a ton of functionality (I think) to the installer.
If even works with typical switches and output to assist in knowing more.
For example:
./installfog.sh -?will print potential usage options.
