@sega Have you used FOG in the past, and if so, did you encounter this problem back then? It would be helpful to know if this problem is something that has only occurred recently or if it has always been this was since using FOG. If something did change, we need to narrow down what it could be.

When a computer gets “stuck,” does the data block percentage change at all? Have you tried leaving a computer to see if it finishes the imaging process even if it’s slow?

Have you tried plugging in the computers to the same network switch that the FOG server is connected to? The would eliminate any other bottlenecks in network speed on your network.

@FCCL-Vandoeuvre This sounds identical to the issue I had. Basically during the imaging process, it would stop and show Starting sshd: touch: cannot touch ‘/var/lock/sshd’ : No such file or directory along with starting deployment scripts. I knew it was firewall related because when I disabled the firewall rules, it would work.

It turned out the solution was to configure NFS mountd to use the static port of 20048. You mentioned doing something similar, but I modified a different file than the one you mentioned (nfs.conf). Below is a link to the forum post I made and the solution.

https://forums.fogproject.org/topic/17604/what-ports-does-fog-use/2?_=1724085771324

@Tom-Elliott @AUTH-IT-Center
Thank you both very much for the fast and detailed responses! NFS mountd was indeed the culprit. Port 20048 was allowed, but I wasn’t aware that this needed to be configured in the nfs.conf file. Confirmed that imaging is working now.

I’ve used the info from the FOG wiki security page to make firewall rules on the server. So far this has worked well except for one thing. During the imaging process when it gets to the deployment script, it stops. I checked the server logs and a TCP port around 46500 was being blocked. I added it the rules and all was fine until the FOG server needed to be restarted. The port number then changed to a different TCP port around 55000. I conducted another test and sure enough the port number changed again after the server was restarted. The logs mentioned something about RPC.

My best guess based on my online searches and the FOG wiki article is that this has to due with NFS and dynamic ports. The article doesn’t elaborate more on what range of ports are required or the possibility to configure NFS to use static ports.

Does anyone have any insight or knowledge about this? Is it NFS? If so, what options do I have?

Yup, I’m experiencing the same issue. New FOG install 1.5.10.74. Any attempt to export hosts or images to a CSV file results in a blank page with the word “Unauthorized”. Importing host and image CSV files does work though. Only exporting doesn’t work.

Thank you! My question has been answered. The server is connected to a KVM and is only a few steps away from where I work. I’m just following the general rule of only allowing what is necessary and since SSH isn’t necessary (yet), I’ll keep it blocked.

I noticed that FOG is installing openssh-server. I might be wrong, but from what I tested this is also allowing remote SSH connections to the server. I was able to successfully log in as root/super user via SSH. Since I don’t really plan to remotely administer the server, I was wondering if it’s ok to block this port? I don’t know what FOG uses it for though.

Looking at https://wiki.fogproject.org/wiki/index.php/FOG_security, SSH and port 22 are not shown as needing to be open.

@Tom-Elliott Thank you for the response. That answers the question. I’ll consider the proposed workaround. I’m going to look into other options, such as keeping FOG on an isolated network, and the practicality of those options.

@JJ-Fullmer I’ll try to give an example. Let’s say I have a network with a computer lab, my computer, and the FOG server. I want to FOG server to be able to image the computer lab, but the computer lab computers should not be able to access the FOG web UI. Even if they don’t have any credentials, you don’t want unauthorized people attempting to brute force the login or attempting to exploit security vulnerabilities in the web UI.

Thus, I was hoping that I could configure the firewall on the FOG server to limit access to the web UI to only my computer while still allowing it to image the lab computers.

@sweeperdave Over the years of using FOG, I have encountered situations that are similar to this. You can image several computers that are the same model but one or maybe a few will image slower than other machines.

When this happens I usually start by inspecting the ethernet port on the computer. Several times I’ve found the pins to be bent or damaged. The next thing I check is if the fan is running during the imaging process. If it’s suspiciously quiet, I then run tests to see if the fan is working at all. In a few cases, replacing the fan resolved the issue. If the fan seems fine, I usually just give up. I image another device of the same model, then swap the imaged drive into the computer that won’t image. Inconvenient, but it allows you to still use the device and move on. It’s very rare that I ever have to resort to doing this. I’ve always chalked it up to hardware issues on the computer.