CentOS 7/RHEL 7/Fedora 20 Support
-
I think for centos 7 mysql needs to be mariadb instead.
-
Bump!
I followed the steps here to install Mariadb and secure it (leaving blank password of course):
…but the fog installer still complains about mysql not starting… file not found… so I was able to get a little farther on the install process…
-
Ok
I was able to install FOG 1.2.0 on CentOS 7…
[LIST=1]
[]Install CentOS 7 Desktop using Gnome Desktop
[LIST=1]
[]Added most options except backup client and one other one… (can’t remember which one)
[/LIST]
[]Installed MariaDB by:
[LIST=1]
[]sudo yum install mariadb-server mariadb
[]sudo systemctl start mariadb
[]sudo mysql_secure_installation
[LIST=1]
[]Left root password blank, but did remove annonymous access (not sure this is completely OK…)
[]Removed remote root access
[/LIST]
[]sudo systemctl enable mariadb.service
[/LIST]
[]Edited the script for the FOG Install in …/fog_1.2.0/lib/redhat/functions.sh
[][INDENT][LIST]
[]section for configureMySql()
[]commented out exit 1; by adding a “#” in front so it looks like this:
[LIST]
[]#exit 1;
[/LIST]
[/LIST][/INDENT]
[*]Ran the FOG install script
[/LIST]
Tada!!!Note 1: I just finished this install a couple of minutes ago before making this post… I still have to test it…
Note 2: I am rather new to this, so use at your own risk…Good luck.
-
I had to also disable SELINUX:
[COLOR=#000000][FONT=monospace]sed -i ‘s/SELINUX=enforcing/SELINUX=disabled/’ /etc/sysconfig/selinux
sed -i ‘s/SELINUX=enforcing/SELINUX=disabled/’ /etc/selinux/config[/FONT][/COLOR]And clients were able to PXE boot after that.
I can register hosts… but, on Upload task the client can’t mount NFS:
[CODE]mounting x.x.x.x:/images/dev/ on /images failed: Operation not supported
Fatal Error: Failed to mount NFS Volume[/CODE]
Then I chown the /images forlder:
[CODE]chown -R fog /images[/CODE]
And rebooted and tried again, same error…
-
[quote=“PatrickG, post: 34779, member: 24811”]I think for centos 7 mysql needs to be mariadb instead.[/quote]
I just got back from vacation. Fog installer takes care of this already for these distros.
-
[quote=“Jose Antonio Sanchez, post: 35283, member: 25349”]I had to also disable SELINUX:
[COLOR=#000000][FONT=monospace]sed -i ‘s/SELINUX=enforcing/SELINUX=disabled/’ /etc/sysconfig/selinux[/FONT][/COLOR]
[COLOR=#000000][FONT=monospace]sed -i ‘s/SELINUX=enforcing/SELINUX=disabled/’ /etc/selinux/config[/FONT][/COLOR]And clients were able to PXE boot after that.
I can register hosts… but, on Upload task the client can’t mount NFS:
[CODE]mounting x.x.x.x:/images/dev/ on /images failed: Operation not supported
Fatal Error: Failed to mount NFS Volume[/CODE]
Then I chown the /images forlder:
[CODE]chown -R fog /images[/CODE]
And rebooted and tried again, same error…[/quote]
Have to disable SElinux on all distros. Rip off your firewall as well quick to test the NFS mount. systemctl stop firewalld.service && systemctl disable firewalld.service
-
Has anyone been able to get a succesful upload working? Mine is failing on FOGFTP_login() have tried a few quick fixes, will look into it some more this afternoon.
-
[quote=“madskillz23, post: 35285, member: 8206”]Have to disable SElinux on all distros. Rip off your firewall as well quick to test the NFS mount. systemctl stop firewalld.service && systemctl disable firewalld.service[/quote]
Yup… I forgot to add that I did have to stop and disable the firewall service…
The problem I was having with mounting the NFS share for /images/dev in /images was due to the NFS service not running…
I did, I think, systemctl restart nfs-server.service and also systemctl enable nfs-server.service just to be sure…
-
[quote=“Jose Antonio Sanchez, post: 35287, member: 25349”]Yup… I forgot to add that I did have to stop and disable the firewall service…
The problem I was having with mounting the NFS share for /images/dev in /images was due to the NFS service not running…
I did, I think, systemctl restart nfs-server.service and also systemctl enable nfs-server.service just to be sure…[/quote]
Is it working now? I don’t think your error is centOS 7 specific. I am almost positive I had nfs mounting out of box in centOS 7.
-
I got upload working on my CentOS 7 machine. Might have been due to setting seccomp=No in /etc/vsftpd/vsftpd.conf or more likely due to stupid vlan issues being resolved. Testing Multicast now, it seems to hang on “starting to restore image”
-
Multicast still not working
Output of Multicast.log:
[08-15-14 1:16:20 pm] | StorageNode Not found on this system.
[08-15-14 1:16:30 pm] | StorageNode Not found on this system.
…
This is a stand alone fog server, it is the master storage node. I’m kind of out ideas.Also I can use udp-sender and receiver to transmit the multicast log simultaneously between two clients as per these instructions. The third step is out of date. [url]http://fogproject.org/wiki/index.php?title=Troubleshooting_a_multicast[/url]
-
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=“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…