I know I’ve been out of this for a little bit. I check in here or there, but just been extremely busy.

I don’t want to stop contributing, I just am taking time for myself after my workly duties.

I have to give a big gratitude and thanks for everyone here trying to help out whether by code, by helping the rest of the community, or documentation.

@Sebastian-Roth I know you’re busy but you’ve kept the project rolling even with the minimal availability you have. Thank you.
@george1421 I’m sure you’re busy, but I still see you posting and helping where possible and amenible. Thank you.
@Wayne-Workman I know you’re helping where you can as well. (Of course I can’t exactly post everybody because I’ve been busy and honestly not keeping up with the forums as much as I probably should.)

@everyone Thank you. Thank you for still believing in this project. We’re doing the best with what we have. Please understand in we’re lacking, it’s most likely unintentional. I know I’m just busy.

https://news.fogproject.org/fog-1-3-5-and-client-0-11-11-officially-released/

https://news.fogproject.org/fog-1-5-0-rc-11/

TLDR; Rerun the fog installer if you have lost “Database Connectivity” to your fog server, or run the ALTER USER syntax shown below.

So Ubuntu 16, among others I suppose, enable a “security updates” to be applied automatically as a “default” to things. Why, well it makes it simpler to ensure your Ubuntu systems are in compliance and patched for any potential exploits. This causes unknown and unexpected issues.

I figured it’d be a safe thing to express that there could be problems (as many of you have already experienced) that when these updates go up (with or without your knowledge) it can break functionality in unexpected and inopportune ways.

The quickest fix is to simply rerun the fog installer which should correct the problem.

As a note, it seems this problem is specific only when the mysql account is the 'root' user AND the password is blank.

The “fix” if you must do it manually is to open a terminal and obtain root:
Super (Windows Key) + T then sudo -i (in most cases).

From there, open mysql with mysql -u root

NOTE: MySQL MUST be run with ROOT.

Run:

ALTER USER 'root'@'127.0.0.1' IDENTIFIED WITH mysql_native_password BY ''; AND
ALTER USER 'root'@'localhost' IDENTIFIED WITH mysql_native_password BY '';

It’s okay if one of them fails. This is going to fix Most people’s issues.

I would highly recommend removing the unattended-upgrades as many of these “sudden” issues came as a security patch ubuntu pushed out. By default Ubuntu typically set’s this for you as enabled and it can cause havoc on you as you (the admin) may not have “done” anything.

To prevent this problem from happening in the future you could run:

apt-get -y remove unattended-upgrades (AS Root again).

FOG is still actively being developed. It’s not necessarily readily apparent, but we can assure you things are still being worked on. These updates may not be communicated in a way that everybody just knows, but can easily be seen if one were to look at our repository site.

Between our own schedules and lives, we can get very busy. We try to keep things updated and help out on the forums even during lull periods. This might mean we aren’t pushing an RC or release as frequently. It may mean we’re working on other things for the project, such as can be seen if looking at our github site.

Our forums are heavily active, and this should point as an indicator to our “status” as well.

If anybody would like to see an increase in developers donating their time to making this free software, consider donating either with monetary support or by spending personal time to help with development.

FOG is an open source project - it’s even in the name. It is driven by people donating their time and resources. The releases of FOG revolve around when developers can spare a few hours throughout the week. Sometimes that will mean releases will be further, sometimes that will mean releases will be faster. That’s just the nature of our project, and many other open source projects.

Hey everybody,

I know you see me here on occasion from time to time. Life decisions have made it more difficult for me to do things I would normally be doing. Rest assured, I am still around, and while I’m not quite as active as I was in the past, it’s not because I don’t want to be.

I had to move, and as part of that I have none of my normal development stuff readily available. Part of the move made me not have a laptop, until today.

I need to setup my dev environment again, so it may take a little bit, but I will be back up.

https://news.fogproject.org/fog-1-5-10-41-officially-released/

While this maybe spur of the moment, it should officially release 1.5.10 with all relevant bug/security fixes encapsulated (among a few other features.)

This has brought a new methodology of releases in that bug/security releases should be done much more regularly.

dev-branch, historically, was a place where new development occurred (hence its name) but over the last couple of years or so it’s mainly been a bug/security thing, not really a true development approach.

This is OKAY, in my head. Why:

Well we have the master branch which is the ‘baseline’ of a verions. We have the dev-branch, which allows us to work on bugs/security issues. We have the working branches for what will eventually become master. Working is our “dev branch” but keeps proper seperation of things in my opinion.

Basically:
master -> basis for dev-branch (which merges into stable on a regular cadence - still being worked out)
working -> basis of forward development

So we effectively have:
production
staging
development well seperated.

THis may mean on the regular automated releases, no announcement or news article will be created, and I think that’s okay.

Hopefully exciting we have a release after 1.25 years

Thank you!

That’s correct. The main reason fog is constantly moving forward is because the codebase is improved upon. Major bugs tend to be addressed for the next release. We don’t do an LTS because there’s really two main people working on fog in a consistent manor. Those two are @Joe-Schmitt and myself. Debian and Libreoffice have the team too be able to perform such a feat. Their product is Opensource but they have an employment team which can afford them that luxury. FOG has a team but we make no money and as such are required to work full time jobs. We work on FOG in our free time. I’ve had the ability to even work on it from work because we used the software.

Maintaining many different versions is difficult. And we don’t have a support team. WYSIWYG and I think we’ve done pretty well on support, even if we don’t have the ability to do dedicated support for our product. 1.5 was a major step toward modernizing the GUI. 1.6 will vastly improve on this. It was only recently we kind of came up with a road map on how best to proceed. Of note, 1.5 will be maintained until 1.6 is released. 1.6 is focused on making he GUI much more modern. 1.7 will be focused mostly toward fixing and refactoring the FOG client. 1.8 will focus on making the FOS system more modular and usable. I don’t know yet for 1.9. 2.0 will bridge the gap for our rewrite based on the work from 1.5 and up. While we do plan to try to do backports where possible, it’s much easier to ask people to update to the latest version than it is to try to maintain many different versions with backports in mind. At least for what FOG does.

I doubt this will appease anybody, but it’s what I think needs to be said. We are working hard and provide support for our product as best we can. The community makes fogs support system, I think, one of the best around. Add to that and you can almost always have a developer working side by side to help and fix issues as they come up, I don’t think it’s unfair to ask users to update to a specific version. Even if there are bugs, we will always try to correct what we can, when we can. (And normally it’s a pretty quick turn around).

I’m not perfect and I’ll give you that. We don’t even have a test suite to know if things are working as intended. We have to rely on the community and suggestions are great, just understand our answers won’t always be what people want to hear.

https://news.fogproject.org/fog-1-4-0-officially-released/

https://news.fogproject.org/fog-1-4-4-officially-released/

@Shuttleu Thank you for testing on the HP. That confirms the fix on real firmware.

The task error after a menu enrollment. This is a FOS bug, not the agent. The menu item runs the enrollment with no task scheduled. When the enrollment finishes, FOS tries to close the task. The server answers “No Active Task found”, and FOS shows an error. The enrollment itself succeeded. The fix is in FOS release 20261106-134043. After a menu run, FOS now says that no task is scheduled and ends normally. The server records the enrollment on the host only when you schedule the task from the web UI.

FOG Agent. You found the cause. Uninstall keeps C:\ProgramData\FOG on purpose. It holds the machine’s key, its certificate and the trusted CA, so a reinstall keeps the same identity. The reinstall kept the CA of your earlier server, so every connection failed and the token was never used. Agent v0.1.21 fixes this. Setup now checks the stored trust against the server. If it no longer verifies, setup settles trust again like a first install, and the host enrolls again with the token. Until you install v0.1.21, deleting C:\ProgramData\FOG before the reinstall is the right workaround.

Your server certificate comes from your company CA, which Windows already trusts. So no fingerprint is needed, as the probe said. Leave CAFINGERPRINT out on these machines.

@Shuttleu Signing. Yes, you can keep signing with your DB key. FOG signs only its own boot files. The installer signs the files it installs. Kernel Update in the web UI signs each kernel it downloads. Both use the key you gave with --secure-boot-key. FOG has no function to sign a file you give it. You hold DB.key, so sign other EFI files yourself:

sbsign --key DB.key --cert DB.crt --output signed.efi unsigned.efi

Your DB.crt is in db, so anything signed with DB.key boots.

Updating db. Yes, use the FOG server’s KEK. By default the PK and KEK pairs are in /etc/fog/pki/secureboot/ (PK.key, PK.pem, KEK.key, KEK.pem), readable only by root. To add a certificate to db without removing the existing entries:

cert-to-efi-sig-list -g <your-owner-guid> new.crt new.esl
sign-efi-sig-list -a -k KEK.key -c KEK.pem db new.esl db-append.auth

-a makes the update an append. Apply db-append.auth with efi-updatevar on Linux, or Set-SecureBootUEFI -AppendWrite on Windows. Back up these four files. Your machines now trust this PK, so without these keys you can change the keys only from the firmware setup screen.

HP ProBook 450 G10, 01.13.01. Thank you. The FOS fix is in today’s FOS release, 20261105-164908. On a machine in Setup Mode, the enrollment should now end with “Done”. If the firmware still reports Setup Mode, the task prints a note that says so. If you enroll another machine with the new kernel and init, please tell us what it shows.

FOG Agent. The log is at C:\ProgramData\FOG\fog-agent.log, not under Program Files. An unused token means the first enrollment did not reach the server, or the server refused it. Please check two things:

• SERVER must use the name in the server’s certificate. You installed with --internal-domain fogserver.local, and the command uses https://fogserver/fog.
• CAFINGERPRINT must be the SHA-256 of the CA certificate the server publishes at https://<server>/fog/management/other/ca.cert.pem. Compare it with openssl x509 -in ca.cert.pem -noout -fingerprint -sha256.

If neither one is the cause, please post the last lines of fog-agent.log. Also post the lines near “fog-agent setup” in C:\fog-agent-install.log.

@thesmj248 Right, and here is why FOGUefi needed no visit. It boots Ubuntu’s kernel, shim, and GRUB, which Microsoft and Canonical already sign. FOG 1.6 boots its own FOS kernel, signed with your server’s key. So each client must trust that key once. That is the trade-off.

For headless machines, Setup Mode is the path to try. In Setup Mode, the “Enroll Secure Boot” task runs with nobody at the keyboard. It enrolls FOG’s key plus Microsoft’s certificates, so Windows still boots. Note that it also makes FOG’s key the machine’s Platform Key, in place of HP’s.

If HP’s utility can put a machine into Setup Mode without a keyboard confirmation, the whole process is remote: switch to Setup Mode, then schedule the task. When the task finishes, the machine leaves Setup Mode and trusts FOG’s kernels. Please post what HP’s utility does when you test it.

@Shuttleu Your machine is enrolled correctly. The “failed” message is wrong for your case, and the missing PIN screen is expected.

Why “Automatic Secure Boot enrollment failed” appears. The task writes db, then KEK, then PK. A PK write in Setup Mode takes the machine out of Setup Mode. The task then reads the SetupMode variable to confirm this. On your firmware, that check did not see the change before the reboot. Your evidence shows all three writes landed: the firmware is now in Custom Mode, and the second run found the certificate already in db. The text “still in Setup Mode” in that message is also wrong when the PK write already happened. We will fix the check and the message in FOS.

Why there is no PIN screen. The attended item opens MokManager directly. “Enroll key from disk” enrolls MOK.der at the Yes/No prompt. It does not stage a request, so no PIN screen comes after the reboot. The PIN screen is for a request that the FOS task stages on a machine with a vendor PK. Also, MOK only matters when the client boots through shim. You boot snponly.efi, which is signed with your DB key, so db trust is the trust that counts. You do not need the MOK step on these machines.

One thing to know before you roll this out. The unattended task enrolls this FOG server’s own PK and KEK, with Microsoft’s KEK and db entries kept beside them. Your machine’s platform key is now the FOG server’s key, not a vendor key or one of your own. To change db or KEK later from the OS, you need an update signed by the FOG server’s KEK or PK.

Could you tell us the make, model and firmware version of this machine? That lets us confirm the firmware behavior and test the fix against it.

On #2064: the fix (#2065) is on dev-branch. With it, a FOG-managed DHCP config hands out snponly.efi when the installer rebuilds iPXE with your CA. You already did this by hand, so nothing changes for you.

@thesmj248 One addition. FOG can shorten the visit to each machine, but it cannot remove it.

Schedule the “Enroll Secure Boot” task for a host or a group. On the next boot, the task stages the MOK request. Someone at the machine then confirms it once in MOK Manager. The one-time password shows on the client screen, or you can set one password for the whole fleet with the sbmokpw kernel argument.

If the machine’s firmware is in Setup Mode (its Secure Boot keys cleared), the task enrolls the key by itself, with nobody at the keyboard.

Either way, the task needs Secure Boot off when it runs. A client that already enforces Secure Boot cannot boot FOS, because it does not trust the kernel yet. So turn Secure Boot off, run the task, confirm the key, then turn Secure Boot back on.

@thesmj248 No, while that sounds like it’d be a reasonable request, the nature of “Secure Boot” would be moot if you could just arbitrarily and remotely define these.

@thesmj248 Good, the redirect was the problem, and boot.php now loads.

The new failure is expected on a Secure Boot client that has not enrolled this server’s key yet. FOG 1.6 signs bzImage and init.xz with the server’s own Secure Boot key. Shim accepts them only when that key is in the client’s MOK list. The key FOGUefi enrolled under 1.5 is a different key, so shim refuses the kernel with “Security Policy Violation”.

Enroll the key once per machine, with Secure Boot still on:

1. PXE boot the client to the FOG menu and choose “Enroll Secure Boot Key”.
2. Be ready at the keyboard. MokManager gives up after about 10 seconds with no keypress.
3. Choose “Enroll key from disk”, select MOK.der, and confirm the enrollment.
4. Reboot.

If MOK.der is not in the list, put it on a FAT-formatted USB stick and select it from there. You can download it from http://10.115.53.33/fog/service/secureboot/MOK.der.

@thesmj248 That output shows the cause. Your live sites-enabled/001-fog.conf is still the 1.5 vhost with the FOGUefi edits. Lines 37–38 redirect every HTTP request to HTTPS. The 1.6 installer writes its vhost to sites-available/001-fog.conf. I think FOGUefi turned the sites-enabled symlink into a regular file, so Apache never saw the new vhost.

Please check:

ls -l /etc/apache2/sites-enabled/

If 001-fog.conf is a regular file and not a link to ../sites-available/001-fog.conf, run:

sudo mv /etc/apache2/sites-enabled/001-fog.conf /root/001-fog.conf.foguefi
sudo mv /etc/apache2/sites-enabled/001-fog.conf.bak_foguefi /root/
sudo a2ensite 001-fog
sudo apachectl configtest && sudo systemctl reload apache2

Then repeat the curl -sI command. It should return 200 OK, and the client should boot.

@thesmj248 Your Secure Boot chain works. The shim, the signed snponly.efi, and autoexec.ipxe all load. The failure comes after that.

Error 0216eb8f is iPXE’s “No usable certificates”. It is a TLS certificate check. Your boot.php request goes out over http://, so something on the server redirects it to https://. The signed iPXE binary cannot trust the FOG server’s own CA, so the HTTPS connection fails.

A stock FOG 1.6 install with HTTP netboot does not redirect /fog/service/ipxe/. The redirect probably comes from a config left over from 1.5 or the FOGUefi changes.

Please run this from another machine and post the output:

curl -sI http://10.115.53.33/fog/service/ipxe/boot.php

Then, on the FOG server, post the output of:

grep -rniE "rewrite|redirect|return 30" /etc/apache2/sites-enabled/ /etc/httpd/conf.d/ /etc/nginx/conf.d/ 2>/dev/null

@fgaudin Good to hear it works.

UEFI alone does not need secureboot=1. The setting is only for computers that have Secure Boot turned on in the firmware. With secureboot=0, FOG does not sign its boot files, and a computer with Secure Boot on refuses to boot them.

• If Secure Boot is off on your computers, keep secureboot='0'.
• If Secure Boot is on, set secureboot='1' and run ./installfog.sh -y. Do not use -C or -K. Each computer then enrolls the FOG key one time at its first PXE boot.

Install sudo before you set it to 1. The Secure Boot signing helper needs /etc/sudoers.d.