Posts made by Joe Schmitt

https://news.fogproject.org/fog-1-5-0-officially-released-and-fog-client-0-11-15-officially-released/

@msi said in Snapin not running:

I checked the port 445. its open.

Then it’s likely just a DNS configuration issue: if the FOG server can’t resolve hostnames, then it can’t ping them. If you’d like help with that please open a new thread, though this is ultimately not a FOG issue, so it may be best to search other resources on how to configure DNS (assuming this is the issue).

@Scott-Adams with 560 clients you will definitely want to increase the client checkin time. Right now it seems to be around 1 minute (the default).

It’d also be worth while switching to php-fpm instead of Apache’s mod_php, as its better suited for more heavy PHP usage:

The main issue with mod_php and Mpm Prefork is that every time Apache forks
into a new process (every new request) the entire PHP module and all its sub
modules have to be loaded into memory along with all your other data which
means you’re wasting a lot of memory on multiple copies of the same thing.

To get around the memory usage caused by loading php into every Apache
process is to use PHP as an external resource (PHP-FPM instead of mod_php) this
then also allows you to run Apache with MPM Worker which mean Apache has
a master process (now smaller as it doesn’t include all the bloat that comes with
PHP) that spawns a small number of child processes to deal with http requests,
CSS, Images, file downloads etc allowing for faster parallel processing.

Src and a good guide for scaling PHP and Apache: https://www.wirehive.com/wp-content/uploads/2016/09/Configuring-Apache-and-PHP-for-stability-an-performance.pdf

(Tom and I both use php-fpm in our development environments, so we know it’ll work fine)

@loosus456 Deploying works fine, and the client issues that were present, should be all (or mostly) fixed with v0.11.14.

@adrien17 you need to install “xprintidle” from the package manager, exactly. The devel and python packages won’t work.

It’s in the Debian based repos by default, but you can still install it on REHL based systems (Fedora, CentOS,…). See https://ask.fedoraproject.org/en/question/96605/how-to-install-xprintidle-on-fedora-24/?answer=96623#post-id-96623 for a basic idea on how to do that.

@x23piracy file shares can be difficult with the client, because of SYSTEM privileges, and self extracting files have their own limitations. SnapinPacks were created to address this exact scenario due to a lack of a good alternative.

@Joe-Gill glad you found a quick fix. I’ll keep this ticket open though, as it points to a deeper issue in the client: PrinterManager has a thread safety issue.

@Joe-Gill definitely a client bug, luckily it should be a quick fix.

One question: how many printers are assigned to the host? Just the two listed in the log?

I’ll post back when I have a test build for you to try.

@pberberian I believe so, @Tom-Elliott would be able to tell you more.

For the docker image, you should just need to add cross-compiling support (see https://www.linuxquestions.org/questions/slackware-14/cross-compiling-for-arm-with-buildroot-859107/ for a general idea). Optionally, you can also use a Debian system to build it as well, if you prefer to skip docker. Just make sure it has all the dependencies installed that the Dockerfile has: https://github.com/FOGProject/fos/blob/master/docker/Dockerfile#L4

@UWPVIOLATOR I’m not really sure to be honest, it could also be that the client is performing the first restart before admin can even log-in.

@george1421 they are removed in the working/dev branch. Once v1.5.0 is stable, the changes will be merged to master.

@george1421 we have actually moved FOS out of the fogproject repo.

@pberberian see our fos repository, which contains build scripts for the kernels, filesystem, and x86/x64 architectures:
https://github.com/FOGProject/fos . It also contains example usage of our fos-builder docker image, which has all of the needed dependencies built in. Ultimately if we can get arm support going, we’d love to have a pull request for it, and we can add it to our automated building system.

@tesparza snapins are just a way of executing a file. I’d recommend developing the script locally, and then deploying it as a snapin once it works.

In your case, a batch or powershell script would work great. If you need to deploy the two files with the snapin (e.g. the files arent already on the computers), then a SnapinPack would work great. Using a SnapinPack would let you bundle all the files you need together, so your script has the files-to-copy right next to it.

@adrien17 the autologout module is contained in a different, user-specific, log ~/.fog_user.log

However, my gut reaction is that you’re missing the needed dependency for Linux autologout: xprintidle. Try installing that via your package manager (or even use a snapin to automate it!) (src: https://github.com/fogproject/fog-client#autologout).

@TrialAndError could you perform a few debugging steps for me? It’d help narrow down why the shutdown is failing:

• Check the Windows log for any reported issues around 17.02.2018 23:46
• Set the client to Automatic (Delayed) startup, and see if that solves the issue
• If both of those fail, try running this build instead: https://build.jbob.io/Client/nightly/02-18-2018-powerdebug-01/SmartInstaller.exe . It will hopefully log a more specific error message, but you’d need to first uninstall any existing client on the machine, and reset encryption data on it before installing

@UWPVIOLATOR I don’t really see a need for it with the client, unless you have some special steps your image takes during that period.

@UWPVIOLATOR - @x23piracy is correct, fog version v1.4.0 shipped with the client domain improvements. The fact that admin is staying logged in points to a simple unattend.xml configuration issue. I would assume that if you manually restarted, OR even just examine the computer while admin is logged in, you’d see the computer is domain joined.

I can’t speak to why its happening, but this is definitly outside the scope of the client’s responsibility.

@UWPVIOLATOR it does:

 2/20/2018 10:24 AM Power --> API call returned 1, will re-attempt in 5 minutes
 2/20/2018 10:26 AM Main Overriding exception handling

This reboot (which you said was successful) corresponds to these changes:

 2/20/2018 10:23 AM HostnameChanger Renaming host to MMSD-LPT-119719
 2/20/2018 10:23 AM HostnameChanger Joining domain
 2/20/2018 10:23 AM HostnameChanger Success, code =  0

The 0.11.X series performs all domain changes in a single reboot, whereas old versions required multiple reboots.

When the client starts back up after the single reboot, we can see that the name is correct, and the domain is joined:

 2/20/2018 10:26 AM HostnameChanger Checking Hostname
 2/20/2018 10:26 AM HostnameChanger Hostname is correct
 2/20/2018 10:26 AM HostnameChanger Attempting to join domain
 2/20/2018 10:26 AM HostnameChanger Host already joined to target domain

If there is an issue here, its not with reboots. Is there some extra information I’m unaware of? For example is the client reporting that its joined to the domain, but in reality its not?

@UWPVIOLATOR I see no indication of a second reboot even being scheduled or attempted in the logs. There is only the single reboot done to rename and join AD:

------------------------------------------------------------------------------
--------------------------------HostnameChanger-------------------------------
------------------------------------------------------------------------------
 2/20/2018 10:23 AM Client-Info Client Version: 0.11.14
 2/20/2018 10:23 AM Client-Info Client OS:      Windows
 2/20/2018 10:23 AM Client-Info Server Version: 1.4.4
 2/20/2018 10:23 AM Middleware::Response Success
 2/20/2018 10:23 AM HostnameChanger Checking Hostname
 2/20/2018 10:23 AM HostnameChanger Renaming host to MMSD-LPT-119719
 2/20/2018 10:23 AM HostnameChanger Joining domain
 2/20/2018 10:23 AM HostnameChanger Success, code =  0
 2/20/2018 10:23 AM Power Creating shutdown command in 60 seconds
 2/20/2018 10:23 AM Bus Emmiting message on channel: Power
------------------------------------------------------------------------------

Did not reboot after Joining Domain

I am not seeing any place where the client even should have done a reboot besides the one instance it did (which is the exact same as in the other logs you posted), and so by all accounts 0.11.14 seems to be operating exactly as expected.

If there is some shutdown the snapin you run should do, then that is a problem with the snapin, not the client. (As a note, the snapin you run seems to be exiting early, while spawning some kind of new process that retains a file lock on the installer, so something is definitely strange with your snapin file)

@Tom-Elliott can you take a look at this?