Task 0

[Tom Elliott]

@kratkale http://forums.fogproject.org/post/158665

[kratkale]

@Tom-Elliott
The web server IS serving FOG at:
https://fog.mm.htlwien10.at/fog/management/index.php?node=schema
but this host cannot verify the certificate it presents.

TLS verification failed (curl 60). The page rendered when verification was skipped,
so this is a trust problem and not a broken site – the
install continues.

Likely causes:
- the certificate is managed outside FOG (acme.sh, certbot)
and FOG has not been pointed at it: make
/opt/fog/pki/web/leaf/.webLeaf.pem resolve to your
certificate (a symlink is enough)
- the served chain does not terminate in the anchor FOG
resolved (/opt/fog/snapins/ssl//CA/.fogCA.pem)

Note the schema deploy verifies strictly and will NOT
continue past this – it carries an install token.

• Backing up database…Failed

  We were not able to backup the current database!
  Reason: curl exited 60 requesting https://fog.mm.htlwien10.at/fog/maintenance/backup_db.php: curl: (60) SSL certificate problem: unable to get local issuer certificate
  More details here: https://curl.se/docs/sslcerts.html

curl failed to verify the legitimacy of the server and therefore could

Proceeding means this upgrade has no pre-upgrade dump to
restore from. Press [Enter] to proceed anyway, or Ctrl+C
to stop the installer.

[kratkale]

@Tom-Elliott
multicast is not working …

Please note the installation errors …

[Tom Elliott]

@kratkale That’s not a bug and it’s not stopping you — press Enter and the upgrade will finish.

What it’s telling you: your server presents a certificate that FOG didn’t issue (a real one for fog.mm.htlwien10.at, from acme.sh/certbot or your school’s CA). During an upgrade the installer makes a few HTTPS calls to itself, and it verifies those against FOG’s own CA. Your certificate doesn’t chain to FOG’s CA, so those calls fail. The only thing you actually lose is the automatic pre-upgrade database dump.

So take a dump of the fog database yourself first, with mysqldump or from phpMyAdmin — whichever you normally use. Then press Enter and let the installer run.

To stop this happening on every upgrade, point FOG at the certificate you are actually serving. Symlink both halves of your ACME pair into FOG’s leaf directory:

/opt/fog/pki/web/leaf/.webLeaf.pem  ->  your fullchain file
/opt/fog/pki/web/leaf/.webLeaf.key  ->  its matching private file

FOG checks whether those resolve outside its own PKI directory. Once they do, it treats the certificate as externally managed: it stops regenerating it, and it stops replacing your system trust store when it calls itself — so verification just works. Running the installer with --public-web-cert declares the same thing up front.

Once you are through you will be on 1.6.0-beta.5332 or newer, which carries the multicast, snapin-labeling and State column fixes. Let me know whether multicast starts for you.

[kratkale]

@Tom-Elliott

multicast ist not working …

[kratkale]

@Tom-Elliott said in Task 0:
Running the installer with --public-web-cert declares the same thing up front.

Feature does not work:

[kratkale]

@Tom-Elliott
Scheduled Power Management Task is not working

Maybe it’s a Windows bug; I’ve often had to shut down not just once, but two or three times with 24H2 LTS.

But none of the 36 + 25 student computers are shutting down.

[kratkale]

@Tom-Elliott Manually deploying a Snapin after cloning does not work—you must first manually restart the system. There is no Fog log even before the restart. The Fog Client was run using C:\Windows\Setup\Scripts\SetupComplete.cmd

[kratkale]

@Tom-Elliott

Here, too, I’m just launching a simple snap-in—it would be cool if it also showed which snap-in it is. As I mentioned before, due to timing issues, I stopped automatically deploying snap-ins—they often didn’t work properly, even though they worked in the Command Prompt. From this, I concluded that there’s a timing issue between Windows Update… and the snap-ins. That’s why I’ve always preferred to do this manually.

[Tom Elliott]

@kratkale

Multicast. The version number does not show what fails. Queue a multicast task, start the clients, then post:

• the output of tail -n 40 /opt/fog/log/multicast.log
• a photo of one client screen

–public-web-cert. Correction to my last reply: this flag helps only when your web server sends a complete, publicly trusted chain. The flag removes FOG’s own CA from the check, and curl then uses the system trust store. That check also failed. So the system store cannot verify the chain your web server sends. Run this on the FOG server and post the output:

openssl s_client -connect fog.mm.htlwien10.at:443 -servername fog.mm.htlwien10.at </dev/null 2>/dev/null | grep -E '^ *[0-9]+ s:|^ +i:'

It shows who issued the certificate and which certificates the server sends.

Power management. The server sends the schedule in the same format as 1.5. The FOG Client runs it on the PC, at 18:55 PC time. Check that Power Management is enabled in FOG Configuration > Service Configuration and on the host. Then post C:\fog.log from one PC. The lines that start with PowerManagement show whether the client got the schedule.

Snapin after cloning. No C:\fog.log means the FOG Client service has not run yet. The server only queues the snapin. The client starts it. Add net start FOGService after the client install line in SetupComplete.cmd.

All Snapins. FOG shows All Snapins when a host has more than one snapin queued. The Active Snapin Tasks tab lists each snapin by name. The “/ of (/min)” text in the Progress column is a display bug. It is fixed in 1.6.0-beta.5346.