FOG 1.0.1 Snapin Client disabled
-
I’m having issues with my snapins that worked correctly in .32 NOT working in 1.0.1 since upgrading. They “appear” to be deployed but do not actually execute on the client either from a fresh image download or deploying them separately. I even removed them from FOG and reuploaded them with the same settings.
-
[quote=“Luke4231, post: 27201, member: 24207”]Hello,
I have a problem with the FOG Service Snapin Client on windows 7 x64 machines. The fog.log states:
5/15/2014 9:19 AM FOG::SnapinClient Attempting to connect to fog server…
5/15/2014 9:19 AM FOG::SnapinClient Module is disabled on this host.
A little background, I performed a clean install of FOG 1.0.0. Everything seemed to work except the client snapin, same message as above. I reinstalled the client serveral times on several pc’s, same message. I saw that Fog 1.0.1 just came out, so I upgraded by rerunning the .sh file. Everything went without a hitch. Reinstalled client again to win7 and rebooted fog server. I can’t figure out why the snapin’s are still disabled. I’ve made sure I checked the snapins on the client install and checked the server snapin options in fog settings and host table for the host. Any ideas?[/quote]
Hello Luke4321,In my case, I have Ubuntu 14.04 + FOG 1.0.1. In FOG WebGUI, go to Service Management (the icon between printer and tasks management) and check the snapins service is enabled. You must also enable the service in the host services.
I don’t understand very well this behaviour, because in previous versions it was supposed that the the Service Management configuration overrides the hosts services configuration. In this new version, it seems that you must enable both to get it working. Once you disable one of them, it disables the service.
I have checked my fog.log and, when I disable the snapin service in the host side but it is globally enabled, I get the message “SnapinClient Module is disabled on this host”. On the other hand, when I globally disable the snapin service but enable it in the host side, I get the message “SnapinClient Module is disabled globally in the FOG Server”.
Having reached this point, if you have to enable it in several hosts, I suggest you make a group with all the machines you want and enable it in the group. This enables it per machine.
This makes me think that, if you have to manually configure each host/group services no matter what the global settings are, these global settings aren’t useful.
If so, this should be in the Features Request forum.Hope to have helped!
-
[quote=“Smog, post: 27359, member: 572”]Hello Luke4321,
In my case, I have Ubuntu 14.04 + FOG 1.0.1. In FOG WebGUI, go to Service Management (the icon between printer and tasks management) and check the snapins service is enabled. You must also enable the service in the host services.
I don’t understand very well this behaviour, because in previous versions it was supposed that the the Service Management configuration overrides the hosts services configuration. In this new version, it seems that you must enable both to get it working. Once you disable one of them, it disables the service.
I have checked my fog.log and, when I disable the snapin service in the host side but it is globally enabled, I get the message “SnapinClient Module is disabled on this host”. On the other hand, when I globally disable the snapin service but enable it in the host side, I get the message “SnapinClient Module is disabled globally in the FOG Server”.
Having reached this point, if you have to enable it in several hosts, I suggest you make a group with all the machines you want and enable it in the group. This enables it per machine.
This makes me think that, if you have to manually configure each host/group services no matter what the global settings are, these global settings aren’t useful.
If so, this should be in the Features Request forum.Hope to have helped![/quote]
Thank you for assisting with this.
I don’t recall past versions of FOG working on the host side even if the Service was globally active.
Yes, it’s a two part process, but it allows very granular control of the services.
While it can be troublesome for some setups, it’s also designed to work in this pattern.
Is the service Globally Enabled?
If Yes, is the service enabled for the host? If No, stop action.
If Yes, pass the parameters for success. If No, stop-action.
Why would it be useful like this?
Because you may, at times, need to just keep actions from happening from a singular host. Kind of like Active directory joining can be enabled and disabled per host. There may be a system you don’t want to install any snapin’s on. If you have it set so it only cares if one OR the other is on, you’d have to disable globally which would stop all actions on all hosts no matter what their individual service status says.
I hope this brings clarity to it all.
-
I tested Snapins on my VirtualBox test client and got always the message that the snapin module is disabled on this host.
Checked the checkbox in the host and its checked, unchecking and checking it again didn’t helped.Have now taked a look into the file servicemodule-active.php and added debug messages. The method
[CODE]$modState->isValid()[/CODE]
returns nothing on my side, I expected a value of 0 or 1.
Checking ths method
[CODE]$modState->get(‘state’)[/CODE]
returns the value of 1.Is here missing the override of the method isValid in the file ModuleAssociation.class.php?
-
[quote=“Albatros, post: 27405, member: 16710”]I tested Snapins on my VirtualBox test client and got always the message that the snapin module is disabled on this host.
Checked the checkbox in the host and its checked, unchecking and checking it again didn’t helped.Have now taked a look into the file servicemodule-active.php and added debug messages. The method
[CODE]$modState->isValid()[/CODE]
returns nothing on my side, I expected a value of 0 or 1.[/quote]
The $modState->isValid() simply returns true or false. If you are comfortable with mysql statements from the console could you give some output to the following statement:
[code]SELECT hostID FROM hosts WHERE hostName = ‘<hostname>’ \G;
SELECT * FROM moduleStatusByHost WHERE msHostID = ‘<hostID>’ \G;[/code]You should see all your modules, but msState should be 1. Also make sure the msID is not 0 for the related Module ID. If it is zero, this is likely why you’re seeing the problem. An MSID of 0 is not valid, so it doesn’t pass the isValid() check. Also, verify that the msHostID is set to the correct hostID. My guess, though is the MSID has an ID of 0 and this is why it’s not getting the service properly.
[quote=“Albatros, post: 27405, member: 16710”]Checking ths method
[CODE]$modState->get(‘state’)[/CODE]
returns the value of 1.Is here missing the override of the method isValid in the file ModuleAssociation.class.php?[/quote]
There should not be an isValid override in ModuleAssociation.class.php. Unless I need to specify required fields, which may come into play in this file. Required fields would be module id that is a valid module and host id that is a valid host.
-
[CODE]SELECT hostID FROM hosts WHERE hostName = ‘ITFOGWinxp’ \G;[/CODE]
Result
[CODE]hostID: 14
1 row in set (0.00 sec)[/CODE][CODE]SELECT * FROM moduleStatusByHost WHERE msHostID = ‘<hostID>’ \G;[/CODE]
Result
[CODE]msID: 111
msHostID: 14
msModuleID: 6
msState: 1
1 row in set (0.00 sec)[/CODE]How I see the msState has teh value of 1.
-
Albatros, do me a favor and uncheck all the service modules on this particular host.
Click update and perform the 2nd sql statement from above.
There should be no output at all for that host.
The only module that appears to be active on that particular system is the snapin client, but is it enabled on the server/globally enabled?
-
Albatros, if you’re daring, can you try from the latest svn?
I found an easier, and probably, more accurate way to find the state of a module.
Before I was just looping through everything and having it print out the status as it looped through. It turns out, we don’t even need to verify the state or validity of the module. When you uncheck the service modules within the host services settings, it actually removes the reference from the database. This makes the state part of the database not really needed and makes it simpler to find out if the modules are active on a host or not.
I’ve made these corrections in SVN 1706 and tested. All seems correct on my side and hopefully will correct this on your side:
[code]wget -O /var/www/fog/service/servicemodule-active.php https://svn.code.sf.net/p/freeghost/code/trunk/packages/web/service/servicemodule-active.php[/code] -
Update to revision 1706 and if the services are enabled, then it works.
If I disable the services I get an internal server error. This is in the apache log file
[CODE][Mon May 19 13:16:12 2014] [error] [client 192.168.9.14] PHP Warning: mysqli_close(): Couldn’t fetch mysqli in /var/www/fog/lib/db/MySQL.class.php on line 45, referer: http://192.168.9.13/fog/management/index.php?node=host&sub=edit&id=14[/CODE] -
Try upgrading to SVN 1708 and see if it still occurs. I moved to mysqli functions and was finally able to get them class based as well.
-
Updated to rev 1708 tested it and if no services selected this error appears.
[CODE]PHP Fatal error: Call to a member function get() on a non-object in /var/www/fog/service/servicemodule-active.php on line 37[/CODE] -
Will push fix for that shortly. Sorry.
-
svn 1709 should address that error as well as remove mysql_ functions and use the $this->DB calls for database purely where needed.
-
The error is gone and now FOG Services works fine
Ty very much
-
How can I get the svn versions you mentioned? I cannot get snapins to deploy at all.
-
Here is a nice tutorial on the wiki
[url]http://fogproject.org/wiki/index.php/SVN[/url] -
[quote=“Tom Elliott, post: 27440, member: 7271”]svn 1709 should address that error as well as remove mysql_ functions and use the $this->DB calls for database purely where needed.[/quote]
Nice, upgraded to revision 1710 and everything works now. So far.
Thx.
