Host Registration Service deactivation has no effect
-
Server
- FOG Version: 1.3.0
- OS: Debian 8
Client
- Service Version: 0.11.7
- OS: Win 7
Description
Hi
We have a Problem, that FOG is somehow registering wrong MAC addresses on our Notebooks. Because we don’t need the Host Registration service anyways, I have disabled it systemwide. But there are still new MAC addresses reported.
-
I don’t know if this was a “client” issue or a “php” issue. I believe the client, in regards to host register, just get’s a code that tells it to run. (@Joe-Schmitt forgive me if I’m wrong on thinking here).
What I’ve done should help prevent this issue even if the client slips it through.
This is currently on the working-RC-7 branch. Essentially, no client module should run if they are called independently of the client checks. (If you were to call it in the browser with a host object, if the module is globally disabled or disabled for that host it should inform you of this instead of trying to bypass this action).
See the magic:
https://github.com/FOGProject/fogproject/commit/4eec40b609b91db8606ee95ea925e03816264c84 -
What MAC addresses is it recording? Wifi, Ethernet, Bluetooth, 3G ??
-
It’s the WiFi MAC
The problem is that after the image process the client service is registering the MAC and saves it before the hostname is changed. So the MAC is stored to the wrong client.
For example the hostname of the image client ist LWA-Master, now after the computer is imaged, not with fog, the service is registering the MAC to the LWA-Master. But the real name of the client is LWA-whatever.
This problem only occurs with the notebooks we’re cloning with clonezilla USB-Sticks and use FOG only for hostname change and AD joining.
-
I don’t know if this was a “client” issue or a “php” issue. I believe the client, in regards to host register, just get’s a code that tells it to run. (@Joe-Schmitt forgive me if I’m wrong on thinking here).
What I’ve done should help prevent this issue even if the client slips it through.
This is currently on the working-RC-7 branch. Essentially, no client module should run if they are called independently of the client checks. (If you were to call it in the browser with a host object, if the module is globally disabled or disabled for that host it should inform you of this instead of trying to bypass this action).
See the magic:
https://github.com/FOGProject/fogproject/commit/4eec40b609b91db8606ee95ea925e03816264c84 -
@Tom-Elliott
Is this now fixed on one of the new releases? -
Yes. The Host registration service was fixed for 1.3.1 I believe, it brought in a different bug which caused the release of 1.3.2, but yes it was fixed.
-
I just updated to 1.3.4, and know the problem came back. I have tons of pending macs…
-
@Polii123 The code didn’t change for host registration. The checks that I was discussing are still present. Is host registration globally disabled or per host?
-
Just tested to ensure my sanity, and I am, in fact, SANE!
-
It’s globally disabled…
-
@Polii123 Then I’m not seeing any issues with it. I tested by setting a host only disabled. Running a few tests against it. Nothing occurred.
I then set globally disabled. Nothing occurred.
Do you have multiple nodes? Do all your clients look at the same point for getting information?
-
A very simple question, I suppose, but do the hosts that are registering have the new or legacy client?
Can you provide the client log of one of the “adding” systems? (If you are using legacy client please post one for each of the clients – one legacy client fog.log and one new client)