Snapin problem on fog 1.5.9-RC1 and 1.5.9-RC2

[borg]

Hi there,
I am admittingly new to this forum, I have used FOG for years without any problems, and I am thankfull.

Now I have encountered a problem I simply can’t figure out.

We have deployed a few new servers in the organisation within the last few months, and have now encountered problems deploying snapins to windows images.

The problem only resides on the 1.5.9-RC1 and RC2 versions.
The “old” servers we have in “production” works fine.

Snapins are not being deployed, apparently it is an issue of access to a file. (snapins.file.php) or so I think.

running Centos 7 as a virtual client on an ESXI 7 server, deploying windows 10 1909.
deploying are not a problem everything works fine and as intended, only snapins are a problem.

searching for similar problems on the forum as not produced a working solution.

logs captured are as follows:

FOG client log:
fogClient.log

Service master log:
servicemasterLog.txt

Apache error log:
apache errorlog.txt

php-fpm-error log:
php-fpm-errorlog.txt

php-fpm-www log:
php-fpm-www-log.txt

sorry about all the data, please let me know if you need further data.
Also please ignore any weird snapin names, I am Danish…

The servers are in a closed no internet network, separate sites no cloud, no replication. only stand alone servers, there are a routed network connection between sites. we have however used base images deployed from one server to capture on the next, only difference between servers is a reinstallation of the fogclient to pair with the “next” FOG server.

Again I am Danish so I hereby beg your pardon for spelling and grammar.
Any guidance will be highly appreciated.

[george1421]

Your php-fpm error log looks interesting to me. How many computer do you have on your campus that has the fog client installed? It looks like php-fpm is running out of worker threads. I don’t know if this is related to your snapin issue, but it will cause some strange actions with FOG.

[borg]

we have 5 sites with 20 - 30 clients on each site.
no replication between servers, they are independent but the network is routed, for administrative purposes. the reason for this is that the sites need to be able to run independently if core network fails.

[george1421]

@borg said in Snapin problem on fog 1.5.9-RC1 and 1.5.9-RC2:

we have 5 sites with 20 - 30 clients on each site.

ok 30 clients would not cause that php-fpm error. This is strange though I would have expected 100s of workstations hitting this server with that error.

When you say “older” servers are OK, what version is older?

[george1421]

This apache error is directly linked to php-fpm error

[proxy_fcgi:error] [pid 6282] (70007)The timeout specified has expired: [client 10.100.72.81:49792] AH01075: Error dispatching request to :

In that php-fpm did not return an answer in the expected time allowed.

Have you made any adjustments to the php-fpm config file www.conf ?

[borg]

thank you for your support,
We are running 1.5.8 with no problems.
on a note, this is also the server we “copied” the original Image from.
the clients were running FOG client 0.11.X if I remember correctly, not online with my servers at the moment.
that is why I updated our image with fog client 0.12.0 to work with 1.5.9-RCx.

[borg]

No we did not change anything, we run a vanilla CENTOS 7 and a vanilla FOG 1.5.9-RC-1 and RC2 fresh install, no changes, only thing in that matter I can think of is that we run it as an ESXI client.

[borg]

on your note I did change the /etc/httpd/conf.d/fog.conf to include a proxy timeout, saw this on an older post. but not working solution.

[george1421]

@borg ok lets test something. Make sure you have at least 4GB of ram in your FOG server before doing this.

1. Search the /etc directory for a file www.conf depending on the version of PHP installed on your fog server that file’s location will change. But you should only have one in the /etc path.
2. Edit that file and search for pm = dynamic Change it to pm = static
3. Search for pm.max_children = 50 change it to pm.max_children = 75
4. Restart php-fpm sudo systemctl restart php-fpm

Lets see if we can clear those php-fpm error messages. Setting pm to static will save time on building up and taking down of the php-fpm worker services on demand. It will require a bit more ram to have these workers just hanging around waiting for something to do. But the error was there wasn’t enough workers to respond to the requests from apache.

[Sebastian Roth]

@george1421 @borg Checking the php-fpm-www log I see this:

[29-Jun-2020 14:14:27 UTC] PHP Warning: fopen(ftp://...@10.100.72.18/opt/fog/snapins/BMS_Genveje.ps1): failed to open stream: operation failed in /var/www/html/fog/lib/client/snapinclient.class.php on line 623

To me it seems like this is the root cause of this issue. I have to admit that I haven’t seen this error before and I would need to dig into this.

[george1421]

@Sebastian-Roth said in Snapin problem on fog 1.5.9-RC1 and 1.5.9-RC2:

fopen(ftp://

This is what confused me, does the client access the snapins over ftp protocol? I still think its on the php-fpm side though. Lets see if bumping up the number of clients fixes the error. I do have some doubt that the max number of clients is the issue because there are only 30 systems at each site. At 100 systems I might see an issue.

I guess the OP should check to ensure this file /opt/fog/snapins/BMS_Genveje.ps1 exists and has the right permissions so that the fogproject user can read it.

[borg]

@george1421 will try that when I get back to the mines tomorrow, an let you know.
@Sebastian-Roth the “/opt/fog/snapins/BMS_genveje.ps1” do exist I checked, did not check permissions though, Will do tomorrow.
on a weird note the FOG server was very slow on accepting new snapins? when I deployed a new snapin it lasted up till 60s before the GUI told me it was updated I thought it strange, but put it down to bad links, sorry for not including this in the original post.

[borg]

UPDATE:
Checked permissions fogproject:apache user has full rights to all snapins, why it is the apache group I don’t really know.
also changed the www.conf file.
No change unfortunately.