Is the domain information you put at the top a copy and paste from your config? Because I see a comma misplaced.
AD DEFAULT OU - OU=Imaged,DC=haw,DC=k,12DC=nj,DC=us
should read
AD DEFAULT OU - OU=Imaged,DC=haw,DC=k12,DC=nj,DC=us
Is the domain information you put at the top a copy and paste from your config? Because I see a comma misplaced.
AD DEFAULT OU - OU=Imaged,DC=haw,DC=k,12DC=nj,DC=us
should read
AD DEFAULT OU - OU=Imaged,DC=haw,DC=k12,DC=nj,DC=us
@Sebastian-Roth I make all my EFI images in virtual box. My workflow has me enable efi. Do the base install and when I go to pxe I switch off efi and do my capture. The os is still an efi os and won’t boot in vbox until you reenable efi. Has worked fine for me with images going back to windows 7 all the way up to our current testing of 1903
It would be helpful for the client to be able to pull and report inventory information on machines without needing them to reboot.
I am deploying the client to machines that are already out in the field to get them into my host list for later. Forcing a reboot is disruptive to the current users, and right now I can’t even use the PXE inventory task as they aren’t set for PXE to be their primary boot device. adding this feature to the client would be really helpful.
One option for limiting support to reduce workload would be to limit to LTS branches only. So only 18.04 and 20.04 for Ubuntu and skipping the intermediary releases and dropping those that go out of support by their vendor (eg ubuntu 14.04, 16.04).
I know this thread is old but I am following the guide now and have a question.
I am in the process of building a new host. On my old host I have SSL setup (./installfog.sh -S). Do I set up the new machine with SSL and replace the certs with the one from the old machine? following the se instructions: https://wiki.fogproject.org/wiki/index.php?title=FOG_Client#Maintain_Control_Of_Hosts_When_Building_New_Server
Thanks
Nevermind I got it all sorted. Just wanted to make a note that the wiki needs to be update to reflect that the user that needs to be added and given permissions is now fogproject rather than fog
In K12 its pretty common to treat many of your internal users as hostile (right or wrong) since students seem to always try to mess with things whether with malice or just screwing around.
Also with some of the other changes in security on FOG (DB and HTTPS etc) pointing toward the outside to manage devices via the client doesn’t sound impossible for small deployments. Again, it’s not what I’m doing or planning to do, but it would be possible if measures like these were in place.
I’m calling it spam. Especially with that oddly spaced URL at the bottom. Flagged for your consideration.
@Sebastian-Roth
Works fine for me on all the flavors of 10 we use. LTSB LTSC and 1703 1803
@Sebastian-Roth
Good to know. I’m using FOG with HTTP so it hasn’t been an issue (I’ve moved it several times as virtual environments shifted). It might be worth looking into adding a feature in the installer to ask for the DNS name of the machine so it can generate the cert with that as the CN rather than the machine’s IP.
Might be useful for FOS login too. Shouldn’t be impossible to implement. Add Fail2Ban to list of apps to get from the repo and point it to the login logs. I’m sure I’m way over simplifying it (not a dev obviously). As FOG moves to a more secure standard install (SQL password, HTTPS etc) this would be another great feature to have.
I’ve only ever used 636 and running into this is the first time i’ve ever seen 686. It more sparked my interest considering its different on the pane to create the LDAP connection than it is to edit the ldap making me think it was a typo on one or the other.
@Sebastian-Roth said in HTTPS FOG GUI webpage:
You’d need to either manually edit the apache config to not make it force redirect to HTTPS or edit C:\Program File (x86)\FOG\settings.json on the clients and set parameter HTTPS to 1. The later method is preferred from my point of view.
Updating the settings.json on my hosts is what I did for existing clients when I made the move to HTTPS, and creating a new image with an updated install to be used with future clients. The easiest way I found with existing clients was to create a group policy that would move a corrected settings.json into place from a file share.
To be clear I’m mostly speaking about the web UI right now. But the client would be important too. The way JAMF handles the migration is that it continues to use its internal CA and distributes the new cert to the machines on check in. It keeps track of those that have received the cert and compares that to its list of enrolled machines. When all machines have received the cert there is a UI element that goes from red to green letting you know that the server can now be switched to communicate via the external CA.
This is the expected behavior. What you want is persistent groups.
https://forums.fogproject.org/topic/8836/basic-persistent-groups-and-1-3-0rc16
That number makes sense given the number of commits since the GA release and how many are bug fixes.
I can safely assume my devices are all running the latest version so I created a group policy to replace the settings.json with a fixed copy on a network share. Which is fine for what I need and I will just update my base images to reflect the correct setting.
Thanks for the help
Just as a question what installer did you use for 18.04.3
When installing Ubuntu Server make sure to use the ISO that ends in “18.04.3-server-amd64” NOT the ISO that they automatically offer up which ends in “18.04.3-live-server-amd64” That ISO doesn’t contain some of the standard repos.
Here’s the link if anyone needs it:
http://cdimage.ubuntu.com/releases/18.04.3/release/ubuntu-18.04.3-server-amd64.iso
You CAN use the live iso but then you need to make sure to add universe & multiverse
@wayne-workman said in Fedora 35 & FOG:
Knowing our limited developer resources, and to keep cost low, I suggest we cease testing Fedora as well as cease supporting Fedora - in the sense of fixing installation code to make new versions work.
Considering fedora is generally the bleeding edge version or REHL I would classify it under NOT LTS and pull it from the supported OS list.
The way I do it, is that the script goes into FOG but the install files live on a different share that I can call from a UNC path. so the guts to my script are:
\\installersshare\office\setup.exe /configure \\installersshare\office\config.xml