CentOS 7/RHEL 7/Fedora 20 Support
-
[quote=“Jose Antonio Sanchez, post: 35345, member: 25349”]madskillz23,
Same here… can’t multicast even on a flat (unmanaged) switch…
now… on a VM Server (different than the one with the problem for multicast) MariaDB fails to start on boot and I have to restart it every time with:
[INDENT=1]systemctl restart mariadb.service[/INDENT]
I tried adding the following two lines to the my.cnf
[INDENT=1][mysql.service][/INDENT]
[INDENT=1]–service-startup-timeout=9000[/INDENT]but it did not help…
Again… I’m semi-new to linux… any help appreciated…[/quote]
Not sure on multicast yet. Try systemctl enable mariadb.service. and on an unrelated note, I also had to start the nfs service on a new server I threw up, like you had happen to you earlier in the thread
-
madskillz23,
I fixed the mariadb problem by:
[INDENT=1]su[/INDENT]
[INDENT=1]gedit /etc/rc.d/rc.local[/INDENT]Adding this line to the end of file “rc.local”
[INDENT=1]systemctl restart mariadb.service[/INDENT]then as the comments at the beginning of “rc.local” indicated to make sure the file is executable, ran:
[INDENT=1]chmod +x /etc/rc.d/rc.local[/INDENT]
[INDENT=1] [/INDENT]
Now, on to figuring out about the multicast…EDIT: I did run the command to enable the mariadb.service and it kept on crashing on boot…
-
On CentOS 7 across multiple servers I repeatedly keep getting this same problem:
On original fresh fog install, does not ask to update database schema. But after a while (few hours to a weekend) it prompts for a database schema update which consistently fails. Have to rerun fog installer to bypass the issue so I can get to the web interface. Is there a way to manually reset that bit in the database without rerunning the fog installer?
Have not seen this issue on CentOS 6.
-
doesn’t the fog installer re-launch the database??? if so, would a cron job to restart it nightly or every other night be an OK workaround??
systemctl restart mariadb.service
-
The correct command for nfs starting after a reboot is: [CODE]systemctl enable nfs-server.service[/CODE] Apparently just nfs instead of nfs-server didn’t work.
-
[quote=“Jose Antonio Sanchez, post: 35418, member: 25349”]doesn’t the fog installer re-launch the database??? if so, would a cron job to restart it nightly or every other night be an OK workaround??
systemctl restart mariadb.service[/quote]
Nope restarting the system has no effect. Its a bit in the database or somewhere that is persistently set to upgrade.
-
Can FOG issue an error on the page that the database is NOT running rather than to say the schema is out of whack?? That would make troubleshooting a bit easier…
Something like, Can’t connect to database, please restart it or check on it?
-
[quote=“madskillz23, post: 35420, member: 8206”]Nope restarting the system has no effect. Its a bit in the database or somewhere that is persistently set to upgrade.[/quote]
The system??? Nope, the database only, I was restarting the PC where fog is and the problem persisted on every reboot, but whenever I restarted only the database, the problem would go away…
-
Yeah it was caused by MySQL not starting correctly. Same issue you had. Dumb error on my part.
-
due to time limits for projects, I am also running another FOG Server but with Ubuntu 14.04 LTS and I am having the same issue of the Multicast not working even on a flat/unmanaged switch…
So the problem with multicast does not seem to be isolated to CentOS 7… What is the name of the service that handles the multicast?? I need to see if it is running to try to restart it to see if that does it…
-
Fount the answer on another thread…
[FONT=Consolas]sudo service FOGMulticastManager stop
sudo killall udp-sender
sudo killall udp-sender
sudo killall udp-sender
sudo service FOGMulticastManager start[/FONT] -
[quote=“Jose Antonio Sanchez, post: 35438, member: 25349”]Fount the answer on another thread…
[FONT=Consolas]sudo service FOGMulticastManager stop[/FONT]
[FONT=Consolas]sudo killall udp-sender[/FONT]
[FONT=Consolas]sudo killall udp-sender[/FONT]
[FONT=Consolas]sudo killall udp-sender[/FONT]
[FONT=Consolas]sudo service FOGMulticastManager start[/FONT][/quote]Did that work on CentOS 7 too? Didn’t think it would work for me because it seems to be an issue of MulticastManager not thinking the node is a storage node.
-
[quote=“madskillz23, post: 35439, member: 8206”]Did that work on CentOS 7 too? Didn’t think it would work for me because it seems to be an issue of MulticastManager not thinking the node is a storage node.[/quote]
I have to report that stopping the FOGMulticastManager server and starting it again does not solve the multicast problem on CentOS 7…
Any ideas??
P.S. On my Ubuntu 14.04 LTS install of fog 1.2.0 the FOGMulticastManager.service along with the other two FOG services are not listed…
-
[quote=“Jose Antonio Sanchez, post: 35449, member: 25349”]I have to report that stopping the FOGMulticastManager server and starting it again does not solve the multicast problem on CentOS 7…
Any ideas??
P.S. On my Ubuntu 14.04 LTS install of fog 1.2.0 the FOGMulticastManager.service along with the other two FOG services are not listed…[/quote]
Syntax is different on non-systemd based systems. “service FOGMulticastManager status” will work just fine. The “.service” is systemd specific. Centos7 uses systemd, Ubuntu does not yet.
I might have some ideas on multicast in a bit, I’m digging through source code.
-
[quote=“madskillz23, post: 35450, member: 8206”]Syntax is different on non-systemd based systems. “service FOGMulticastManager status” will work just fine. The “.service” is systemd specific. Centos7 uses systemd, Ubuntu does not yet.
I might have some ideas on multicast in a bit, I’m digging through source code.[/quote]
Correct… on Ubuntu I did:
[INDENT=1]initctl list[/INDENT]
[INDENT=1] [/INDENT]
and found no FOG services at all… Which is weird (or the services should be listed elsewhere???), but I have already imaged a few labs with Ubuntu 14.04 with Multicast no problem… well, tftpd had to be restarted and on another standalone Ubuntu 14.04 box dhcp had to be started manually…Seems like CentOS and Ubuntu keep having service startup problems…
-
[quote=“Jose Antonio Sanchez, post: 35452, member: 25349”]Correct… on Ubuntu I did:
[INDENT=1]initctl list[/INDENT]
[INDENT=1] [/INDENT]
and found no FOG services at all… Which is weird (or the services should be listed elsewhere???), but I have already imaged a few labs with Ubuntu 14.04 with Multicast no problem… well, tftpd had to be restarted and on another standalone Ubuntu 14.04 box dhcp had to be started manually…Seems like CentOS and Ubuntu keep having service startup problems…[/quote]
Ubuntu 14.04 and CentOS 7 are both not recommended for production fog systems at this point. initctl seems like a systemd thingy, which shouldn’t work on Ubuntu. Could be wrong on that, I’ve personally never used it.
On a fun note, here’s the logic behind the exception on my multicast.log printout. Working on figuring out what’s going wrong with that.
[CODE]$StorageNode = current($this->FOGCore->getClass(‘StorageNodeManager’)->find(array(‘isMaster’ => 1,‘isEnabled’ => 1,‘ip’ => $this->FOGCore->getIPAddress())));
if (!$StorageNode || !$StorageNode->isValid())
throw new Exception(sprintf(" | StorageNode Not found on this system."));[/CODE] -
[CODE] * Setting up and starting MySQL…Note: Forwarding request to ‘systemctl enable mysqld.service’.
Failed to issue method call: No such file or directory
OK[/CODE]
Note to developers, this is an issue in all systemd systems. Link to various solutions pasted below, it involves a simple systemd init script. I will try and roll my own, and post the results here, but you may choose to go in a different direction. Also possibly just changing it to “systemctl enable mariadb.service” would work as well.[url]http://superuser.com/questions/384365/systemctl-enable-differs-from-systemctl-start-how[/url]
-
Any developers have an idea why the $StorageNode in the following command isn’t valid here? Php is not my forte. I believe this is the first step into finding out why multicast doesn’t work on CentOS 7.
This is in 1.2.0/packages/web/lib/fog/MulticastManager.class.php
[CODE]$StorageNode = current($this->FOGCore->getClass(‘StorageNodeManager’)->find(array(‘isMaster’ => 1,‘isEnabled’ => 1,‘ip’ => $this->FOGCore->getIPAddress())));[/CODE] -
It attempts to find the storage node that is enabled, is the master, and is set to the localized FOG system. This is especially true for multi-node sites where the “main” fog server is not the one containing all of the images. That master/enabled system would be what’s handing out the Multicast, Image replication, and Scheduled task service information. In the case of nodes, there’s currently no way for us to get the logs off of those off scope nodes as it’s looking for the /opt/fog/log/{multicast.log,fogscheduler.log,fogreplicator.log} files off of the system you’re looking at the logs from. This is most likely why you’re seeing the “StorageNode not found on this system” message as the StorageNode is not being found for that system. Hopefully that helps clarify it?
-
Hi Tom, thank you for the response. The issue I have is that while my site has many FOG servers, they are now all independent and on separate subnets protected by firewalls. All of my CentOS 7 nodes I am testing are the ONLY fog servers on those subnets. They all are completely independent of one another, each one being responsible for PXE, httpd, imaging, and WOL etc. They are all master/enabled, and unicast works just fine from those servers. Also, doing manual multicast by manually sending the udp-cast command and a client debug task, I am able to multicast just fine.
I just took down the CentOS 7 server on one of the lab vlans, replaced it with a CentOS 6 FOG server, and now multicast works. The multicast log reports “*No Tasks found” by default. I seriously doubt any parts of the configuration in FOG have changed besides the OS’s in this new setup. I believe that $StorageNode should be returning the info of the current machine, and on CentOS 7 it is not, even though that server is master, enabled, and stores images.
I now believe this is a database issue, as on CentOS 7, the database/schema updater is never promted for on the web interface during the install process, because the installer script doesn’t properly handle systemd init scripts for mySQL. I will work on fixing and testing that part this afternoon, and see if that helps things.
