Going from 1.5.9.98 to 1.5.9.111.
The fog server gets weekly updates via Landscape so unless entirely new packages get installed somewhere between those two version I doubt that is it. I’m going to snapshot, pull the config from .98 and run the upgrade and compare the two configs to see if anything stands out
I also upgraded rather recently from 1.5.8 to 1.5.9.98 without issue.
But if I roll back to the snapshot I take before the update it responds to the dns name. nslookup resolves fog.domain.org to 10.10.70.4 as it should. The record is a static A record in our local DNS server (active directory domain).
I am running the latest dev version on Ubuntu 18.04 and it is no longer responding to the alias in the apache config. I can access the page via the IP address, but we have the hostname entered into all of our clients so this is pretty key to keeping things communicating with the server.
Is that separate from the cert that is used for HTTPS? Do I need to generate a new cert or does that come from the install as long as it is recent?
HA!
You actually put me on the right path! The computers in question were imaged so long ago that they predated our domain rename. So the info in the Active Directory section of FOG still listed our old domain, so even if they tried to fix themselves they would fail. This matches up as the machines that fixed themselves were all imaged or re-imaged AFTER the domain rename!
Now I’m not so sure the client IS working properly. I see this when I pulled the log from one of the machines.
8/17/2021 1:53:08 PM Client-Info Client Version: 0.11.19
8/17/2021 1:53:08 PM Client-Info Client OS: Windows
8/17/2021 1:53:08 PM Client-Info Server Version: 1.5.9.98
8/17/2021 1:53:08 PM Middleware::Response Success
8/17/2021 1:53:08 PM Middleware::Communication Download: https://fog.CONTOSO.org/fog/client/SmartInstaller.exe
8/17/2021 1:53:09 PM Data::RSA FOG Project cert found
8/17/2021 1:53:09 PM ClientUpdater ERROR: Update file is not authentic
This isn’t a FOG specific question per-se but with having everyone out of the office for an extended period many devices have non-functioning AD binding. Despite being back in the office on the network they no longer check in to group policy etc.
They still check into FOG with the client properly so I wanted to see if anyone had a good script the check if the binding is working correctly and correct it/rebind if it isn’t.
This is not currently possible to do through the client. To get complete inventory the machine would need to be run through PXE and inventory collected through registration.
Going through the same process I usually do to make a base image. Do a clean install in virtualbox with EFI turned on. Turn off EFI and PXE boot.
Getting the following error:
The long and short is to mount the QNAP on your FOG server and map your /images folder to to that mount point.
The real answer for Mac is DEP & MDM. There are free MDMs like https://manager.mosyle.com this is missing a few key features that could be rounded out with open source tools like https://github.com/munki/munki
The key to all of this is that you have an Apple Business manager or Apple School Manager account and the devices enrolled there so they get enrollment packages at first startup.
If you have more questions reddit.com/r/macsysadmin is an OK resource, as well as https://www.macadmins.org slack channel. Then there is always JAMF Nation which is another apple MDM but the forum has broad apple questions and answers that apply not only to JAMF
What services are you making available over the internet? Just the web UI? Or are you imaging over the internet?
If its just the web interface are you putting it behind a proxy?
I’ve long since moved away from the third party cert idea especially since I use the client heavily. I only responded because @gn_ro bumped this. The main issue with their request is that the main feature of lets encrypt is the automatic renewal which only happens in one of 2 ways. either a DNS update which you would use if you were generating a wildcard cert or through an http challenge. The http challenge is ONLY accessible over port 80 direct to the internet, which would mean exposing the fog web UI to the internet. As I’ve understood it this has been discouraged by the Dev team for security reasons.
You would need to face your FOG Web UI to the internet to do that (Lets encrypt requires access to port 80). And doing that is not recommended by the FOG team.
Been out of the loop for a while. Which branch is currently considered the best to be on? Master or Dev? I am currently on master 1.5.8 and getting ready for our summer imaging so I want to make sure I upgrade to the latest recommended version before I hit the ground running.
Thanks
I understand that as it currently stands that isn’t possible. My recommendation was to see if it was possible to modify the FOG Project’s revenue stream in order to support the project long term.
Other open source projects don’t charge for the product itself, but rather for support, or in the case of something like Zammad for feature requests. Between customers who want to pay for support and customers who want to pay for additional features it might be possible to increase the revenue stream enough to support 1 or 2 full time developers and hopefully additional support person/people.
I don’t really have anything to contribute, but has the team thought about a paid support model? Being able to pay something to developers may entice some to work on the project.
This is really just a starting point. You should adjust the instructions based on the mount point for your NetApp storage.
@george1421 has a write up here:
https://forums.fogproject.org/topic/10450/adding-additional-image-storage-space-to-fog-server
Not sure how up-to-date it is, but it should give you a starting point.
@wayne-workman
Just checking to see if you’ve moved on this at all or if there is anything I can do to lend a hand. I have a decent sized lab with both Xen and ESXi if anything needs testing.