No Replication to second Fog server, after updating to latest Rev. 5157
-
@Sebastian-Roth said in [No Replication to second Fog server:
@John-L-Clark Newer linux versions usually use the commands:
service vsftpd restart
orsystemctl restart vsftpd.service
Wiki updated. When it comes to the Ubuntu stuff, I take what credible people say and just stick it into the wiki.
-
@John-L-Clark said in [No Replication to second Fog server:
Finally got FTP to work after finding in the config.class.php the correct password for the user fog.
You shouldn’t need to ever manually modify that file in FOG. The installer builds it for you based on what’s inside of
/opt/fog/.fogsettings
. Please set the password that you want to use for FTP inside of that .fogsettings file and then re-run the installer. Then try to manually connect via FTP to the remote node using those new credentials and see if it works. -
@Sebastian-Roth said in [No Replication to second Fog server:
service vsftpd restart
Thanks that restarted the service, but still not getting replication
-
Bumping this thread.
I remoted in and tried to figure this out, but everything I checked was fine. I’m stumped. Any ideas?
-
I have created an all new storage node on another server from scratch. I verified FTP from both machines and verified the settings in .fogsettings
I am still not getting any kind of replication. The fogreplicator.log shows nothing but the FOG logo and created by and then Image between groups.
Any suggestions?
-
I’m not sure if this is related or not - I’m using Debian 8.4, with fog trunk (git 7190).
The service master logs aren’t showing any issues, however if you check the output from the daemon itselfjournalctl -u FOGImageReplicator.service
this shows up
Apr 16 13:50:56 FOG13 FOGImageReplicator[38336]: PHP Warning: Error while sending QUERY packet. PID=11398 in /var/www/fog/lib/db/mysql.class.php on line 49 Apr 16 13:50:56 FOG13 FOGImageReplicator[38336]: PHP Fatal error: Using $this when not in object context in /var/www/fog/lib/service/fogservice.class.php on line 77
This repeats every service loop (approx 3 minutes) . This isn’t restricted to ImageReplicator either, all FOGservices are affected
journalctl -u FOGMulticastManager.service journalctl -u FOGPingHosts.service journalctl -u FOGScheduler.service journalctl -u FOGSnapinReplicator.service
My imagereplication, snapin replication, multicast, etc aren’t working either. I haven’t had time to delve into the why’s as this isn’t mission critical yet for me.
-
@John-L-Clark In light of @Mentaloid 's post, can you check your other logs and other service statuses to see what they say?
-
@Mentaloid is this an individual node?
-
FOG13.domain.local = FOG + storage node (Default, only member, replication enabled (to nowhere))
FOGStorage02.domain.local = storage only node (ID#2, only member, replication enabled (to nowhere))
Running Debian 8.4, PHP Version 5.6.19-0+deb8u1Log is from main fog server (FOG13) running 7242 (updated now), FOGStorage02 also 7242.
I updated to 7196 yesterday to reconfirm another issue, and at that time journalctl entries changed to
Apr 19 19:45:17 FOG13 FOGImageReplicator[63794]: PHP Strict Standards: Non-static method FOGBase::getSetting() should not be called statically in /opt/fog/service/lib/service_lib.php on line 3 Apr 19 19:45:17 FOG13 FOGImageReplicator[63794]: PHP Strict Standards: Non-static method FOGBase::getSetting() should not be called statically in /opt/fog/service/lib/service_lib.php on line 3 Apr 19 19:45:17 FOG13 FOGImageReplicator[63794]: PHP Strict Standards: Non-static method FOGBase::getSetting() should not be called statically in /opt/fog/service/lib/service_lib.php on line 4 Apr 19 19:45:17 FOG13 FOGImageReplicator[63794]: PHP Strict Standards: Non-static method FOGService::getDateTime() should not be called statically in /var/www/fog/lib/service/fogservice.class.php on line 92 Apr 19 19:45:17 FOG13 FOGImageReplicator[63794]: PHP Strict Standards: Non-static method FOGBase::getSetting() should not be called statically in /var/www/fog/lib/service/fogservice.class.php on line 90
every 3 minutes. These entries persist to today, after updating to 7242.
I haven’t confirmed if the services are functional at this time.
-
This has been resolved with latest revisions and some other work by Tom