No Replication to second Fog server, after updating to latest Rev. 5157

[John L Clark]

I have updated to Rev 5157 on both servers and I have checked the config.class.php to ensure the username and password but still am unable to see any replication to the second server. Any suggestions?

[Wayne Workman]

Try to manually FTP into the remote storage node from the main server, and see what happens. There are example connection statements in here:
https://wiki.fogproject.org/wiki/index.php?title=Troubleshoot_FTP

Use the credentials inside of the storage node’s Storage Management area in the web interface.

You might get a variety of errors, or maybe no errors. But what happens matters. Then we can go from there.

[John L Clark]

Finally got FTP to work after finding in the config.class.php the correct password for the user fog. I changed the username and password in the Storage Management to match and then restarted the Replication service.

[John L Clark]

Still no replication but was able to connect with FTP

[John L Clark]

@Wayne-Workman
/etc/init.d/vsftpd restart this command to restart the service does not work. It says no such file or direstory. Yet i can follow the article testing instructions and connect and copy files and delete files with no issues.

[Sebastian Roth]

@John-L-Clark Newer linux versions usually use the commands: service vsftpd restart or systemctl restart vsftpd.service

[Wayne Workman]

@Sebastian-Roth said in [No Replication to second Fog server:

@John-L-Clark Newer linux versions usually use the commands: service vsftpd restart or systemctl 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.

[Wayne Workman]

@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.

[John L Clark]

@Sebastian-Roth said in [No Replication to second Fog server:

service vsftpd restart

Thanks that restarted the service, but still not getting replication

[Wayne Workman]

Bumping this thread.

I remoted in and tried to figure this out, but everything I checked was fine. I’m stumped. Any ideas?

[John L Clark]

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?

[Mentaloid]

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 itself

journalctl -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.

[Wayne Workman]

@John-L-Clark In light of @Mentaloid 's post, can you check your other logs and other service statuses to see what they say?

[Tom Elliott]

@Mentaloid is this an individual node?

[Mentaloid]

@Tom-Elliott

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+deb8u1

Log 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.

[John L Clark]

This has been resolved with latest revisions and some other work by Tom