lightdm user detected, wont change hostname

[pilipp_edv]

@Tom-Elliott thanks for the reply, but there is no “FOG_ENFORCE_HOST_CHANGES” in FOG Configuration -> FOG Settings, only “ENFORCE HOST CHANGES” under FOG Configuration -> FOG Settings -> Active Directory Defaults and that one is already ticked.
Either that or I’m just blind.

[Tom Elliott]

@pilipp_edv That’s the same thing.

In the DB the actual name is FOG_ENFORCE_HOST_CHANGES, and for 1.5.x we tried to do some fancy things by replacing _ with and removed the first FOG

[pilipp_edv]

@Tom-Elliott but why is it not enforced despite that setting being enabled?

[Tom Elliott]

@pilipp_edv I don’t know. The hosts don’t have that thing checked. Maybe there’s a bug, but I don’t know.

What I do know is that the individual host is supposed to have it checked. I thought the value there effectively worked as a global toggle.

[AUTH IT Center]

@pilipp_edv

can you check the services tab on your dashboard? Is the hostname changer ticked?

also how is the host created in the first place (manually, autoregister, api?)

[pilipp_edv]

@AUTH-IT-Center the hostname changer is enabled, yes. The hosts are created via full registration and inventory. Using the group-based workaround provided by @Tom-Elliott works so far.

I think there are two problems here, the fog client detects the lightdm linux user and stops and the settings don’t get applied to clients from FOG Configuration -> FOG Settings -> Active Directory defaults.

Note that we don’t join the clients to our domain, we only change their hostname.

[AUTH IT Center]

@pilipp_edv

for the record the Active Directory is working only for the Windows clients as described in the FOG client repo but as you said you don’t want them to join only rename. Since we are discussing for linux clients maybe that is the clue for not being enabled by default.

The database cells hostUseAD and hostEnforce are the ones that enable the procedure to occur. Another test would be to add a host and check what value it has on the dB for hosts.hostUseAD and hosts.hostEnforce without adding the host to the group or changing anything from the dashboard.

[Tom Elliott]

@AUTH-IT-Center hostEnforce falls under the UI for AD stuff because initially this was thought to only be required for Domain Joins (as hostname, restart, domain join, restart) would generally be the order of things. Then we extended the client to work on Mac OS and Linux. However, we just never moved the “enforce” changes.

Why? Domain joins for all systems also require reboots, so this “checkbox” is needed for both AD stuff and just baseline Hostname changes.

[AUTH IT Center]

@Tom-Elliott

today I had to add some hosts (manually) and the force reboot was indeed checked when I added the hostname and mac address.

Is it possible that the registration from the FOS client doesn’t apply it on host creation?

[Tom Elliott]

@AUTH-IT-Center That is correct. That’s what that FOG Settings item is meant to do. If that is checked, on registration it should set that flag on future registrations, but it doesn’t on existing hosts that were registered before it was checked. If after this is checked and a new host registers and this isn’t working, I would believe there to be a bug.

Though a workaround exists, so while, it would be a bug, it may not be the biggest concern to get fixed immediately over say actual imaging issues.