Thank you for the reply.
I will check on this when I return to the office in the morning.
Thank you again.
Thank you for the reply.
I will check on this when I return to the office in the morning.
Thank you again.
@Wayne-Workman
Thank you for the quick reply.
From the node, I have entered mysql -h x.x.x.x -pMyAwesomePassword -D fog and received the following error message:
mysql: [Warning] Using a password on the command line interface can be insecure.
ERROR 1045 (28000): Access denied for user 'user'@'x.x.x.x' (using password: YES)
I have proceeded to enter mysql to enter the command set as the connection was denied.
mysql> SET PASSWORD FOR 'fogstorage'@'%' = PASSWORD('MyAwesomePassword');
Query OK, 0 rows affected, 1 warning (0.00 sec)
mysql> GRANT ALL PRIVILEGES ON fog.* TO 'fogstorage'@'%' IDENTIFIED BY 'MyAwesomePassword' WITH GRANT OPTION;
Query OK, 0 rows affected, 1 warning (0.00 sec)
mysql> quit
I have again tried to connect from the node back to main fog and have received the same error message.
user@SHO-FOG-N1:~$ mysql -h x.x.x.x -pMyAwesomePassword -D fog
mysql: [Warning] Using a password on the command line interface can be insecure.
ERROR 1045 (28000): Access denied for user 'user'@'x.x.x.x' (using password: YES)
I have also double checked the three listings for .fogsettings and confirm that the password info listed there is correct.
After the double checks, I have checked back into the GUI and found that all nodes are now registering and providing information as I am accustomed to.
Fingers are crossed that it continues to behave nicely. I would assume that this message is now able to be marked as solved?
I am unsure if I am not able to connect from the node to the main by default, but it seems to have corrected the issue… Will know more as I do more.
Please let me know if there are any logs or other I am able to provide to assist with anything on your end.
Thank you again for your time and quick response. It is immensely appreciated.
I have recently upgraded to RC15 from RC11.
I have three storage nodes with within two groups / locations.
All fogs have been updated to RC15 and running the same SVN.
After the update, I have noticed that my nodes are reporting “A valid database connection could not be made”.
When removing and re-adding the storage node, I see the message “Storage ID 0 is not valid”. The node is added to the list and looks as it should aside from the messages.
• the dashboard shows each node with a listing of “(undefined)” below the name in the grid
• storage group activity does show and register the nodes
The TFTP boot from our node is working - I have not yet tried to image or perform other tasks from the node as of yet.
• I have re-installed the RC on the main fog with no success.
• I have re-installed the RC on one of the nodes with no success.
I have also triple checked and confirmed that the node username and password is correct.
As a note, when updating the main fog, when asked to update the DB scheme, I logged in and it went straight to the home page and not the database update page. I understand that not all updates will require a DB update, but am just curious if one was needed.
I am unsure of which logs you would like to see. Please let me know and I will get them posted to assist with figuring out this issue.
Thank you for your time.
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.
@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.
@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
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.
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.