Snapins not replicating - Ubuntu 16.04 / Fog 1.3.0 RC10

[mtanigawa]

I am unable to figure out why snapins are not replicating from main server to storage node.

• Images do replicate
• checked, rechecked all passwords
• stopped, started, restarted snapin replicator service (and image replicator server)
• removed all snapins and re-created one for re-test
• snapin replicator log shows ‘* Started sync for Snapin …’
• snapin never copies
• snapin is tiny (ps1 script)
• has replicated previously with RC 8? (didn’t add new snapins for RC9)

I am unsure if it might be a permissions thing? Snapins folder permissions and Owner for both master and node are the same.

Saw a previous post about the permissions being fog:apache?

I appreciate any fresh eyes on this as I have started to go in circles… Also hoping it’s something simple.

• I have re-installed RC10 on both the master and node to no success.

Is there a way to test the snapin replication connection manually? Maybe I missed that post…

Have some other issues… but one at a time.

Thank you for your time.

[Wayne Workman]

I had a similar issue recently. The permissons on the log file itself need to be root:apache for both the image replicator log and snapin replicator log, if they aren’t right it won’t work. I don’t know what is causing the permissions to change, I think there’s something fishy about that in the installer. You will want to restart the image replicator after modifying permissions @Tom-Elliott you might want to look into that.

Let us know if changing permissions on the logs work.

Also just for future reference, we could give you a whole lot better and more precise help if you posted a log file. Without that we’re just guessing, spinning our wheels, and hoping to get lucky.

Web Interface -> FOG Configuration -> Log Viewer -> Snapin replicator log

[mtanigawa]

@Wayne-Workman
Thank you for your reply. My apologies for not putting the logs.

I have changed the permissions for the log files on the main FOG to root:www-data. for both the main and the node transfer. After restarting the service for both image and snaps replicaotr, I noticed that the main log ownership has changed back to root:root.

(before)

-rw-r--r-- 1 root www-data    37 Sep 16 16:18 fogreplicator.log
-rw-r--r-- 1 root www-data  2527 Sep 16 12:51 fogreplicator.log.transfer.SHI-FOG-N1.log
-rw-r--r-- 1 root www-data    63 Sep 16 16:18 fogsnapinrep.log
-rw-r--r-- 1 root www-data   828 Aug 17 15:18 fogsnapinrep.log.transfer.SHI-FOG-N1.log

(after)

-rw-r--r-- 1 root root        37 Sep 16 16:23 fogreplicator.log
-rw-r--r-- 1 root www-data  2527 Sep 16 12:51 fogreplicator.log.transfer.SHI-FOG-N1.log
-rw-r--r-- 1 root root        63 Sep 16 16:23 fogsnapinrep.log
-rw-r--r-- 1 root www-data   828 Aug 17 15:18 fogsnapinrep.log.transfer.SHI-FOG-N1.log

The service master logs show that the services were killed and started.

[09-16-16 4:23:12 pm] FOGImageReplicator child process (24979) is running.
[09-16-16 4:23:12 pm] FOGImageReplicator forked child process (24979).
[09-16-16 4:23:12 pm] FOGImageReplicator Start
[09-16-16 4:23:12 pm] Service_Signal_handler (23323) exiting.
[09-16-16 4:23:12 pm] Service_Signal_handler (23323) killing child (23339).
[09-16-16 4:23:12 pm] Service_Signal_handler (23323) received signal 2.
[09-16-16 4:22:59 pm] FOGImageReplicator child process (24498) is running.
[09-16-16 4:22:59 pm] FOGImageReplicator forked child process (24498).
[09-16-16 4:22:59 pm] FOGImageReplicator Start
[09-16-16 4:22:59 pm] Service_Signal_handler (25667) exiting.
[09-16-16 4:22:59 pm] Service_Signal_handler (25667) killing child (25670).
[09-16-16 4:22:59 pm] Service_Signal_handler (25667) received signal 2.

(snapin replicator log)

[09-16-16 4:33:13 pm] * Started sync for Snapin shi_SEP

Unfortunately, that’s all it does and doesn’t change from that. The Snapin Transfer Log also does not show the snapin “Tranferring file” record. It shows the record of the last time snapins were transferred, which was two RC’s back.

Finished transfer `reg_uk.bat' (577 B/s)
Transferring file `reg_uk.bat'

Thank you for your time.

[mtanigawa]

@Wayne-Workman
Not sure if this is related - thinking it might be… I have also come across an issue where none of my snapins would deploy. I am looking into this independently from the replication issue.

The task manager would update it’s status to show that the host has ‘checked in’, but in the Active Snapin Tasks view, the state would only be listed as ‘Queud’ and never change.

• I have Reset Encryption Data as mentioned in other posts to no luck.
• Removed, re-added the snapin (also removing the file from the server)
• Both the master and the node do not deploy.
• tested prior and post to re-install of RC-10 - same inactivity
• tried on several of machines - image is fine, snapins stall

The SnapinClient section shows the ‘Unable to get subsection’ error.

I have attached the fog.log for reference. As mentioned previously, I was treating this as a separate issue and is mentioned here for reference in the event it may help this current issue. While I would like to resolve this, it does not have be discussed in this thread unless there is relevance.

Thank you for your time.

 16/09/2016 17:04 Middleware::Communication URL: http://172.24.0.60/fog/management/index.php?sub=requestClientInfo&mac=A4:1F:72:5E:75:A2||00:00:00:00:00:00:00:E0&newService&json
 16/09/2016 17:04 Middleware::Response Success
 16/09/2016 17:04 Middleware::Communication URL: http://172.24.0.60/fog/service/getversion.php?clientver&newService&json
 16/09/2016 17:04 Middleware::Communication URL: http://172.24.0.60/fog/service/getversion.php?newService&json

 16/09/2016 17:04 Service Creating user agent cache
 16/09/2016 17:04 Middleware::Response Invalid time
 16/09/2016 17:04 Middleware::Response No Printers
 16/09/2016 17:04 Middleware::Response Module is disabled globally on the FOG server

------------------------------------------------------------------------------
---------------------------------ClientUpdater--------------------------------
------------------------------------------------------------------------------
 16/09/2016 16:55 Client-Info Client Version: 0.11.5
 16/09/2016 16:55 Client-Info Client OS:      Windows
 16/09/2016 16:55 Client-Info Server Version: 1.3.0-RC-10
 16/09/2016 16:55 Middleware::Response Success
------------------------------------------------------------------------------


------------------------------------------------------------------------------
----------------------------------TaskReboot----------------------------------
------------------------------------------------------------------------------
 16/09/2016 16:55 Client-Info Client Version: 0.11.5
 16/09/2016 16:55 Client-Info Client OS:      Windows
 16/09/2016 16:55 Client-Info Server Version: 1.3.0-RC-10
 16/09/2016 16:55 Middleware::Response Success
------------------------------------------------------------------------------


------------------------------------------------------------------------------
--------------------------------HostnameChanger-------------------------------
------------------------------------------------------------------------------
 16/09/2016 16:55 Client-Info Client Version: 0.11.5
 16/09/2016 16:55 Client-Info Client OS:      Windows
 16/09/2016 16:55 Client-Info Server Version: 1.3.0-RC-10
 16/09/2016 16:55 Middleware::Response Success
 16/09/2016 16:55 HostnameChanger Users still logged in and enforce is disabled, delaying any further actions
------------------------------------------------------------------------------


------------------------------------------------------------------------------
---------------------------------SnapinClient---------------------------------
------------------------------------------------------------------------------
 16/09/2016 16:55 Client-Info Client Version: 0.11.5
 16/09/2016 16:55 Client-Info Client OS:      Windows
 16/09/2016 16:55 Client-Info Server Version: 1.3.0-RC-10
 16/09/2016 16:55 Middleware::Response ERROR: Unable to get subsection
 16/09/2016 16:55 Middleware::Response ERROR: Object reference not set to an instance of an object.

------------------------------------------------------------------------------
--------------------------------PrinterManager--------------------------------
------------------------------------------------------------------------------
 16/09/2016 16:55 Client-Info Client Version: 0.11.5
 16/09/2016 16:55 Client-Info Client OS:      Windows
 16/09/2016 16:55 Client-Info Server Version: 1.3.0-RC-10
 16/09/2016 16:55 Middleware::Response No Printers
 16/09/2016 16:55 PrinterManager Getting installed printers
------------------------------------------------------------------------------


------------------------------------------------------------------------------
--------------------------------PowerManagement-------------------------------
------------------------------------------------------------------------------
 16/09/2016 16:55 Client-Info Client Version: 0.11.5
 16/09/2016 16:55 Client-Info Client OS:      Windows
 16/09/2016 16:55 Client-Info Server Version: 1.3.0-RC-10
 16/09/2016 16:55 Middleware::Response Success
 16/09/2016 16:55 PowerManagement Calculating tasks to unschedule
 16/09/2016 16:55 PowerManagement Calculating tasks to schedule
------------------------------------------------------------------------------


------------------------------------------------------------------------------
----------------------------------UserTracker---------------------------------
------------------------------------------------------------------------------
 16/09/2016 16:55 Client-Info Client Version: 0.11.5
 16/09/2016 16:55 Client-Info Client OS:      Windows
 16/09/2016 16:55 Client-Info Server Version: 1.3.0-RC-10
 16/09/2016 16:55 Middleware::Response Success
------------------------------------------------------------------------------

 16/09/2016 16:55 Middleware::Communication URL: http://172.24.0.60/fog/management/index.php?sub=requestClientInfo&configure&newService&json
 16/09/2016 16:55 Middleware::Response Success
 16/09/2016 16:55 Service Sleeping for 151 seconds

[Wayne Workman]

@mtanigawa said in Snapins not replicating - Ubuntu 16.04 / Fog 1.3.0 RC10:

After restarting the service for both image and snaps replicaotr, I noticed that the main log ownership has changed back to root:root.

Are you sure that restarting the service did it? I really don’t think that the service changes ownership of files. However the installer does change onwership of the logs and if you had ran that, it’s possible that it changed it. Either way - things shouldn’t be root:root @Tom-Elliott. I think they should be root:apache or root:www-data

While we’re looking at this, check the ownership of the snapins too. They are in /opt/fog/snapins

[Tom Elliott]

@Wayne-Workman Logs are created by whomever creates the logs. I know that doesn’t sound like it makes any sense.

FOGSnapinReplicator is started as a daemon service from the user “root”. So when the service is restarted, it gets unlinked and re-created. Who ever started the service becomes the owner of the file.

This goes for ANY service for that matter.

[mtanigawa]

@Wayne-Workman
Thank you for your feedback.

For the master (snapin folder permission)

drwxrwxr-x 3 fog  www-data 4096 Sep 16 16:42 snapins

(snapin permission)

-rwxr-xr-x 1 fog  fog      1809 Sep 16 16:26 Sho_SEP.ps1

For the node (snapin folder permission)

drwxrwxr-x 3 fog  www-data 4096 Sep 15 23:08 snapins

Unfortunately, snap-ins are still not replicating, so I do not have permissions for the snapin file.

For kicks, I have removed the Location Plugin from FOG and turned off the plugins option and restarted both the image and snapin replicator services. So far still no luck.

I will test to see if snap-ins will deploy a little later in the day and will update if there is a different. Reading other posts for hints on try…

Thank you for your time.

[Tom Elliott]

@mtanigawa Replication was known about for RC-10 and has been fixed for RC-11 already.

[mtanigawa]

@Tom-Elliott
@Wayne-Workman

Great to hear! Thank you for the update! Thank you also for the quick replies and hard work. It is enormously appreciated. Will await RC-11 and give it a go.

Thank you again.