'Module is disabled on the host' can't install snapins
-
Environment Details:
Ubuntu Linux 14.04.2
FOG Trunk version 6207 (just upgraded from 1.2.0, upgrade went perfectly and everything works)
Client: 0.9.11 running on Windows 7 Pro SP1Problem:
I can’t seem to install snapins. I was getting the exact same problem on 1.2.0 and the legacy client, and I was hoping that upgrading to the trunk version would help (and I needed to upgrade anyway for better Win10 support, so no harm done anyway!).
In fog.log on the client machine, I get the message for the snapin module: “Module is disabled on the host”. I was getting the same message on the host when I was running 1.2.0 and the legacy Fog client (although the message was worded slightly differently- “snapinclient module is disable on this host”
What I tried (on Fog 1.2.0 and legacy client)
Before upgrading to the trunk version, I tried uninstalling and reinstalling the legacy Fog client. I double checked that I was enabling the Snapin module on the host. No change. I also tried turning off the Snapin module globally on the server, and then back on. The client detects this change (and reports it in fog.log) but when it is re-enabled globally on the server I go back to getting the “snapinclient module is disable on this host” message.
What I tried (on Fog trunk 6207 and client 0.9.11)
As mentioned, I did the upgrade to the latest trunk (via SVN method) as I needed to do this anyway for Win 10 support. Upgrade went perfectly, and after upgrade I uninstalled the legacy client on the host, and installed the 0.9.11 one. Unlike the legacy client I didn’t seem to get any options during install to enable / disable certain services though?
I should mention- I previously had no issues with snapins on this exact setup with 1.2.0 and the legacy client. Obviously something changed to cause it to stop working but I’ve got no idea what. On this server I only ever do security updates.
Any help / suggestions are appreciated, thanks. Please advise if there is any extra info you need.
-
@mr626 said:
I also tried turning off the Snapin module globally on the server, and then back on. The client detects this change (and reports it in fog.log)
Can you explain that line more? How does the client detect the change? I thought the problem is the client saying the snapins module is disabled. How does it report differently if you disable it on the server?
Are you aware that individual hosts can have their services enabled/disabled individually (at least in fog trunk)? If you go to the host management area and click on the problematic host, on the left, there should be something called services where you can enable/disable things. If the snapins one is not checked, it’s disabled.
-
Hi Wayne,
Many thanks for the reply.
To clarify, as part of my troubleshooting process I thought I would try globally disabling and re-enabling the snapin service on the server, via the web interface.
The difference as reported by the client (in fog.log) when I did this was that rather than saying “service disabled for this host” the client correctly reported that the service was globally disabled. And when I then globablly re-enabled snapins on the server, the client went back to reporting that the snapins service was disabled on the host. Hope that makes sense?
Regarding your second suggestion…THANKS! That was exactly the problem! For the problem host, no services had been ticked under service configuration. Almost as soon as I ticked the snapins service, the snapins I had queued started installing.
Follow up question- most of my hosts are still running the legacy client. Does the legacy client ‘know about’ these service configuration settings that are available per host in the trunk version’s web interface? Or do I need to update all of my hosts to the new client (which I will do eventually anyway of course)
-
@mr626 said:
Does the legacy client ‘know about’ these service configuration settings that are available per host in the trunk version’s web interface?
Yes.
Or do I need to update all of my hosts to the new client (which I will do eventually anyway of course)
You don’t have to upgrade to the new one, but I’d really strongly suggest that you do.
For enabling all services on all hosts, throw all your hosts into a group, and then use the group to enable all services on all hosts.
