I have checked source code and opened a Github issue:
https://github.com/FOGProject/fos/issues/38

@Sebastian-Roth said in LDAP Plugin install:

Did you see Tom’s post? There seemed to be an issue in the version check script on our webserver which led to it saying you are “up to date” eventhough you are running the years old 1.5.5 version. Tom fixed it. You can always be sure the version number in the bottom right corner is the one you have.

Hey sorry about the confusion I did see his comment, but clearly did not understand. It’s a huge relief that we aren’t dealing with a failed upgrade.

Thanks for all your help with this everyone, I have finally got the plugin working. As @Kiweegie suggested early on the password complexity seemed to be the issue. I had made sure there was no special characters in it, but I had made the password obscenely long. Changing it < 24 characters seems to have done the trick.

Apologies for all the confusion and thanks again for all the help.

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.