@george1421 This is correct. It works fine. Thanks,

This worked for me :

Domain name: subdomain.domain.tld
OU: OU=Computers,DC=SUBDOMAIN,DC=DOMAIN,DC=TLD
AD DEFAULT USER: adminuser
Domain Password: supersecret
Name Change/AD Join Forced reboot?: cheked

Not sure if I was doing anything wrong, I tried too many things, but this now works. Thanks.

Is your machine trying to boot bzimage32 ? send a picture if you can.

OK, looks like Disable Fast Startup in Windows solved the issue. Sorry for the noise.

Hello everyone,

First of all, thank you for FOG. We run it in a school (about 320 hosts, FOG 1.5.x on Debian 12) and it is a core part of how we deploy and maintain our PCs.

I would like to propose a feature: a “Troubleshooting” (or “Host health”) menu in the web UI that lets an administrator find, in a few clicks, which hosts are failing to authenticate and what to do about it. Today this requires digging through server logs and the database, which is complicated and not realistic for most FOG admins. We had to write a script to do it, and I am sharing what it does as a starting point for the design.

The problem

FOG does not tell you when a host fails to authenticate. Nothing appears in the web UI or in any error log, because the server answers these requests with HTTP 200 even when it rejects the login. We only found out when somebody stood in front of the machine. Two cases kept hitting us:

1. Rejected login in the iPXE menu. The user picks Deploy Image, types the credentials, the screen flickers and the menu comes back with no message. Server side, the only trace is the menu (boot.php) being requested again a few seconds later, and the kernel (bzImage / init.xz) never being downloaded. Our working theory (not fully confirmed yet) is the keyboard layout: iPXE uses a US layout, so passwords with symbols typed on another layout would arrive differently.
2. Windows FOG client that cannot authorize. The host retries forever. The database shows no security token, or one that has not been renewed for days (hostSecToken / hostSecTime), and the client’s fog.log shows token or certificate errors. The usual fix is Reset Encryption Data, but nobody knows which hosts need it.

What the menu should show

Each item is something we currently detect by hand:

• Hosts whose FOG client cannot authorize: missing or stale security token, or an abnormal number of authorization requests (a retry loop). Suggested action: Reset Encryption Data, then check fog.log on the client.
• Hosts that fail the PXE login: repeated rejected logins without the kernel ever being downloaded. Suggested action: check the keyboard layout and the credentials.
• Hosts with no contact for N days (configurable): so that machines that no longer exist can be removed and machines in use whose client silently stopped can be fixed.
• For each one: host name, IP, since when, and the suggested action next to it.
• Optionally, an e-mail digest through the existing notification mechanism.

How our script detects it (for reference)

A read-only shell/awk script that runs weekly from cron on the FOG server and e-mails a report. It never writes to FOG. It uses:

• Apache access log (other_vhosts_access.log plus the rotated .gz files):
  • Rejected PXE logins: two POSTs to boot.php from the same IP within 120 s, with no kernel download in between. A host is listed after 3 rejections in the period.
  • Client not authorizing: we take the most frequent response size of /management/index.php?sub=requestClientInfo and of the authorize POSTs as “normal”, and flag IPs with several abnormal responses, or with too many authorizations in a single day (a normal host does about 47 a day; we flag above 100, which means a retry loop).
  • Mapping IP to host: the mac= parameter of requestClientInfo links an IP to the host MACs in the database.
• FOG database (hosts, hostMAC) : the host token and its last renewal time. A host is flagged when its token is missing or older than its last failed request. It also gives the hosts with no sign of life for more than 15 days.

Example of the summary it produces (host names removed):

OVERALL STATUS: NEEDS ATTENTION

SUMMARY
  Hosts whose FOG client cannot authorize....... 4
  Hosts that could not log in on PXE............ 4
  Hosts with no contact (over 15 days).......... 64
  Hosts active this week........................ 189

1) HOSTS THAT CANNOT CONNECT TO FOG (Windows client)
   The client cannot authorize against the server.
   -> In the FOG web UI, open the host and click "Reset Encryption Data";
      then check the FOG log on the client.
   - HOST-A, since 03 Nov
   ...

In a few weeks it found hosts with broken tokens that nobody had reported, a laptop that repeatedly failed the PXE login, and several machines in daily use whose FOG client had silently stopped working.

Why it belongs inside FOG

Parsing Apache logs is fragile and only works because we know the response sizes by heart. FOG already has the information: the hosts table, the token times and the requests it serves. The simplest native design would be to record an event (or a counter on the host) whenever a PXE login or a client authorization is rejected, with the reason, and build the menu on top of that.

You are very welcome to take our script and keep it, use it, change it or build on it however you like, with no conditions. We do not have a public code repository, so if any developer wants it, reply here or send me a private message and I will share it. I can also explain the heuristics and thresholds in more detail, share anonymised log samples, or test a patch or plugin on our server if that helps.

Thank you again for your work.

@Tom-Elliott Success. I switched to single-user with init 1, and installing systemd-sysv worked fine.

As this is a machine upgraded from debian 11, maybe it wasn’t using systemd. Installation of 1.6 worked no problem Thanks,

@JJ-Fullmer

mariadb -V
mariadb Ver 15.1 Distrib 10.11.6-MariaDB, for debian-linux-gnu (x86_64) using EditLine wrapper

@bwilli78 my dell machine was wrongly identified as 32bit and sent bzimage32. You can: 1) update to dev-branch 1629 I should help. Or 2) send bzimage to 32bit machines. (Because they are wrongly identified).

This could be your issue. I don’t see FOG sending bzimage32 anyway. Just a gut feeling. May be wrong.

Is your machine trying to boot bzimage32 ? send a picture if you can.

This worked for me :

Domain name: subdomain.domain.tld
OU: OU=Computers,DC=SUBDOMAIN,DC=DOMAIN,DC=TLD
AD DEFAULT USER: adminuser
Domain Password: supersecret
Name Change/AD Join Forced reboot?: cheked

Not sure if I was doing anything wrong, I tried too many things, but this now works. Thanks.

I have the impression this issue has something to do with DHCP server in the gateway competing with proxydhcp in the fog server.

I have updated DHCP settings in Unifi to allow / block DHCP traffic (DHCP Guarding). I have included FOG’s dhcppxory address and seems to be working ok now.

I have created links in /etc/init.d for mysql and mysqld -> mariadb.

Installation seems to progress now a little better, I’ve updated the schema, but still get these errors:

* Setting up and starting MySQL..........................System has not been booted with systemd as init system (PID 1). Can't operate.
Failed to connect to bus: Host is down
mysql.service points to "mariadb" which is not a valid unit name: Invalid cross-device link
mysqld.service points to "mariadb" which is not a valid unit name: Invalid cross-device link
OK
* Testing connection to database..........................OK
* Setting up MySQL user and database......................Skipped
* Backing up user reports................................Done
* Stopping web service...................................OK
* Setting up Apache and PHP files.........................OK
* Testing and removing symbolic links if found............OK
* Backing up old data.....................................OK
* Copying new files to web folder.........................OK
* Creating config file....................................OK
* Creating redirection index file........................Skipped
* Downloading kernel, init and fog-client binaries.......Done
* Copying binaries to destination paths....................OK
* Enabling apache2 and php services on boot...............OK
* Creating SSL Certificate................................OK
* Creating auth pub key and cert..........................OK
* Resetting SSL Permissions...............................OK
* Setting up Apache virtual host (normal).................OK
* Configuring PHP FPM.....................................Done
* Starting and checking status of web services............OK
* Changing permissions on apache log files................OK
* Backing up database.....................................Done

* You still need to install/update your database schema.
  This can be done by opening a web browser and going to:

    http://192.168.0.21/fog/management

* Press [Enter] key when database is updated/installed.

* Update fogstorage database password.....................OK
* Granting access to fogstorage database user.............Skipped
* Setting up storage......................................OK
* Setting up and starting DHCP Server.....................Skipped
* Configuring default PXE file............................OK
* Setting up and starting TFTP Server.....................OK
* Setting up and starting VSFTP Server....................OK
* Setting up FOG Snapins..................................OK
* Setting up FOG Snapins..................................OK
* Setting up FOG Services.................................OK
* Setting up and starting NFS Server......................OK
* Configuring UDPCast.....................................OK
* Building UDPCast binaries...............................OK
* Installing UDPCast......................................OK
* Installing FOG System Scripts...........................Failed!

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!! The installer was not able to run all the way to the end as something has caused it to fail. The following few lines are from the error log file which might help us figure out what’s wrong. Please add this information when reporting an error. !!
!! As well you might want to take a look at the full error log in /root/fogproject/bin/error_logs/fog_error_1.6.0-beta.2141.log !!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

install -m 644 udp-receiver.1 udp-receiver.1 /usr/local/share/man/man1
install -m 644 rateGovernor.h /usr/local/include/udpcast
System has not been booted with systemd as init system (PID 1). Can't operate.
Failed to connect to bus: Host is down
root@fogserver:/root/fogproject#

FOG seems to run ok for the moment, despite install errors. Is it OK to use ?

Update to working-1.6 fails with mysql: unrecognized service

System: Debian 12, upgrading from 1.5.10.1629.

See: fog_error_1.6.0-beta.2141.log

* Setting up and starting MySQL..........................System has not been booted with systemd as init system (PID 1). Can't operate.
Failed to connect to bus: Host is down
mysql.service points to "mariadb" which is not a valid unit name: Invalid cross-device link
mysqld.service points to "mariadb" which is not a valid unit name: Invalid cross-device link
Failed!

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!! The installer was not able to run all the way to the end as something has caused it to fail. The following few lines are from the error log file which might help us figure out what’s wrong. Please add this information when reporting an error. !!
!! As well you might want to take a look at the full error log in /root/fogproject/bin/error_logs/fog_error_1.6.0-beta.2141.log !!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

ii  vsftpd        3.0.3-13+tb2    amd64       lightweight, efficient FTP server written for security
ii  wget          1.21.3-1tb2     amd64       retrieves files from the web
ii  zlib1g:amd64  1:1.2.13.dfsg-1 amd64       compression library - runtime
New password: Retype new password: passwd: password updated successfully
mysql: unrecognized service

I suspect a mariadb / mysql naming issue. I really do not know where to start so going back to 1.5.10.1629 backup.

Any ideas ?

Mornign all.

I am running out of ideas here, this was working back in version 1.5.10.10 I believe I had, while on 1622 & 1629 isn’t.

I have populated the fields as best I know:

AD DEFAULT DOMAINNAME : MYSUBDOMAIN, and also tried MYCOMPANYSUBDOMAIN.MYCOMPANYDOMAIN.COM

AD DEFAULT OU: empty, and also tried OU=Computers,DC=MYCOMPANYSUBDOMAIN,DC=MYCOMPANYDOMAIN,DC=COM

AD DEFAULT USER: user , also tried MYCOMPANYSUBDOMAIN\user

AD DEFAULT PASSWORD: thesecretpassword

AD DEFAULT PASSWORD LEGACY: empty , also tried thesecretpassword

ENFORCE HOST CHANGES : checked.

I am pretty sure this user can join the domain, because as this was not working, I created a PS script as a snapin, that just works and joins domain.

What am I doing wrong ?

--------------------------------------------------------
----------------------HostnameChanger--------------------
--------------------------------------------------------
27/10/2024 10:53:27 Client-Info Client Version: 0.13.0
27/10/2024 10:53:27 Client-Info Client OS: Windows
27/10/2024 10:53:27 Client-Info Server Version: 1.5.10.1629
27/10/2024 10:53:27 Middleware::Response Success
27/10/2024 10:53:27 HostnameChanger Checking Hostname
27/10/2024 10:53:27 HostnameChanger Hostname is correct
27/10/2024 10:53:27 HostnameChanger Attempting to join domain
27/10/2024 10:53:29 HostnameChanger The parameter is incorrect, code = 87
--------------------------------------------------------