I’ve removed Arch Linux from the automated tests due to complications within Terraform. These issues were sort of the final straw in my Arch testing efforts.

The Arch community doesn’t supply an official AWS AMI. I had been relying on a privately built AMI that isn’t 1:1 with a manual Arch installation. For perhaps the last half year, my Arch tests were failing but the installer worked if you tested it against a manually setup Arch installation. This can only be due to differences between the AMI I was using and a manual installation.

The Arch community is vehement about only providing help if you follow their installation instructions on their wiki exactly. Because of this, when I asked for some help sorting out the issues, they were not willing to help.

Until someone with some Arch prowess can put some time into helping with this, Arch Linux will not be included in the automated tests.

@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.