@sascha735 If you installed FOG using the git method, switch to the dev branch and reinstall fog. That will put you on a prerelease version of 1.5.8 that does support Centos 8 and Debian 10.2 (I think).

cd /root/fogproject git checkout dev-branch git pull cd bin ./installfog.sh

That should put you on version 1.5.7.85 (or later)

When FOG 1.5.8 is released (should be some time later this month) you will then need to do the following to switch back to the master branch.

cd /root/fogproject git checkout master git pull cd bin ./installfog.sh

@Tom-Elliott ok, no worries

Finally merged all the work into dev-branch. Done.

@Sebastian-Roth if my memory serves correctly, GUI watcher was a part of the now very old client

@Quazz Not sure from the top of my head. Thanks for finding this!! I will take a look later on.

@ismith-hpu Don’t feel like you have to but you are welcome to post here as well: https://forums.fogproject.org/topic/4382/organizations-using-fog

Thanks for your post, appreciate that!

@ismith-hpu said in Mac OSX renaming of Hostname & ComputerName post imaging:

FOG Server CA NOT found in keystore

You need to make sure you install and run the fog-client in the root context.

@maikBat said in API updated?:

I have updates from 2017

What do you mean by that??? Which version of FOG do you use?

@fry_p Maybe too late, but in addition to complete a few:

You can configure the fog client to delayed-auto and to reboot the service on each error with the commands below recommended before start it:

sc.exe config FOGService start=delayed-auto sc.exe failure FOGService actions= restart/60000/restart/60000/restart/ reset= 120.

@antonionardella You are right this is not good that it prints the full credentials in the logs. But the error you have is caused by the php-ldap module not being installed I guess. That shouldn’t happen at all if you don’t mess with the FOG setup. I am not sure we can prevent if from showing this in the logs…

Today I learned that when adding a new item to PXE menu “Menu Item” cannot have spaces. Instead type “New Item” you should type “NewItem”. When I checked the PXE config file using the link was kind of evident that this was the problem and in effect it was.

Thanks for the help

@Wayne-Workman said in FOG install overwrites /etc/exports with no warning:

In what scenarios do you see having two?

If you were to install fog side by side with another product that supports nfs. What is the likelihood of two installs creating an entry with fsid of 0 or 1? We see that issue today when someone wants to create a second nfs share on the fog server and clones what is currently there but updates the paths only.

@tutu10 i think you posted this to the wrong forum…

Did some more testing and will merge this into dev-branch now before the new release. Have tested on CentOS (existing installation and fresh) as well as Debian (fresh installation). Should be good to go.

@tejen While @ckasdf is totally right about saying that it sounds like you might be using FOG as a backup tool and it’s not a great idea, I can still tell you that you can create scheduled jobs. Just do as if you’d manually create a capture task but on the last step instead of do an “instant task” click schedule as cron task.

@klaus-jauk In FOG groups are not like you might be used from other software. It’s more like a tool to push out settings to a group of hosts but it’s mostly not a persistent settings thing where you store information for the whole group. For AD settings, if you set those through the group you’ll see that the values will be shown in the group AD settings as long as you don’t change a value for any of the single hosts. When you do this the value from the group AD settings will disappear.

This is the concept of FOG groups. Search the forums for “persistent group” and you’ll find a lot of information on this.

I see that it’s a bit unfortunate in the case you describe where you register a new host and join that to the group. But on the other hand you’ll still have all the values set for all the other group members. You just don’t see it in the group AD settings view anymore.

@Sebastian-Roth Okay, I will give it a try. Thanks for the response.

@vervoordeldonk What we are finding is the mainstream hardware vendors (dell, hp, lenovo, intel nuc so far) do an excellent job of making each system unique so coming up with an alternate method of identification isn’t a problem.

The issue is like the system below

System Manufacturer xxxxr System Product TMB-3010 System Version R0M0 System Serial Number To be filled by O.E.M. System Type Type: Notebook BIOS Vendor American Megatrends Inc. BIOS Version 1.00/636G00WPC76508 BIOS Date 05/06/2016 Motherboard Manufacturer xxxxr Motherboard Product Name WEB-889A/WEB-889AA Motherboard Version R0M0 Motherboard Serial Number To be filled by O.E.M. Motherboard Asset Tag To be filled by O.E.M. CPU Manufacturer Intel® Corporation CPU Version Intel® Core™ i5-3210M CPU @ 2.50GHz CPU Normal Speed Current Speed: 2500 MHz CPU Max Speed Max Speed: 3800 MHz Memory 3.74 GiB Hard Disk Model 2.5" SATA SSD 3ME3 Hard Disk Firmware S15A19 Hard Disk Serial Number xxxxxxxxxx000025 Chassis Manufacturer xxxr Chassis Version Chassis Serial To Be Filled By O.E.M. Chassis Asset

I put the lower case “x” in just to mask a few values, but as you can see there is nothing unique on this system from the next system from the same manufacturer other than the disk serial number. I have a few examples of other systems that are very similar. One solution is to go ahead and use the mac address as part of the mix for system identification. In that case we would be no worse off than we are today by only using just the mac address.

We also want to bring in the asset tag value so at the very least if FOG can’t identify the system the IT tech will need to populate that field to create a unique ID for that system. (sorry I’m a bit thinking out loud here)