Best posts made by Sebastian Roth

@rogalskij We started to take care of this back in late 2019 (relevant github commit). So for AD password: It can’t be seen because it’s replaced by a row of * characters in the web UI.

I am not sure why we did not extend this to all the other password fields. I am open to discuss adding this to all the other password fields as well. Not sure if other users like it the way it is.

Hosts >pick a host > Active Directory > Domain Password

This one is fixed, just checked on a test installation. Please let us know if it’s not the case for you! Then I am pretty sure you’re not using FOG 1.5.9.

The ability to toggle this feature on or off would be great. Probably requiring an admin password to change the toggle.

There is no real concept of roles in FOG. So any FOG web UI is more or less an admin.

@dashwell Well you said you updated from an older version and you think the update is causing this problem. While I still don’t think the update caused this I still was wondering what version you used before.

Back to the problem: The error is pretty clear. The image was taken from a larger size disk. Probably using an older version of FOG which did only shrink but not rearange partitions (to fill the empty gaps). The version you currently use (20220203) is capable of rearanging partitions but you need to re-capture the image with that version to make use of it. So I suggest you grab a machine with a disk large enough, deploy that old image to it. Then create a new image definition within the FOG web UI (to keep the old one as backup), set this new image for the machine you just deployed the old image to, schedule a capture to the fresh image definition and then try to deploy this new image to smaller size drives.

@hummela I just reverted one of the changes I made when adding the PHP 8 support. Would you mind updating to 1.5.9.148 and trying again?

@tristanc2ip said in Deploy Image Issue HP EliteBook 850 G8:

Now I cant deploy my image, when I select “Deploy Image” I enter my username and password twice and after et go in a menu with 1) Reboot, 2) Network Information …

This is a known issue with this particular device and currently being worked on. You can either register the host and just schedule a task or find information on a workaround here: https://forums.fogproject.org/topic/16188/fog-quick-image-password-not-working

@rogalskij The issue where you could grab the AD password by clicking Join Domain after deploy is fixed in the latest dev-branch and will be in the next release.

I am not sure about all the other password fields. Don’t want to mess with this to easily as people might be used to it. Would be interesting to hear what others think about this.

@BSZAdmin @george1421 Doesn’t look like partition file 3 is missing. I guess it’s the decompression (done on the fly) dying - for reasons I cannot see yet. This would cause this kind of error message.

You can manually try to extract a copy of that file in the server and see if it failes as well. Be aware you need enough disk space on the server to test.

If this works well then I am wondering if it’s faulty RAM in the host machine you want to deploy to. Have you deployed to different machines?

@david-burgess @Wayne-Workman Using the latest dev-branch version you should be able to use disk size or WWN or disk identifier to force disk order. It’s a known issue that NVMe drives get enumerated in different order by the Linux kernel.

Search the forums for “nvme wwn” and you should find a topic with helpful information on this.

@Eric-Johnson Take a look at FOG Configuration -> FOG Settings -> FOG Client - Host Register -> QUICKREG PENDING MAC FILTER. Just set to 0A:00:27 and it should ignore any MAC matching this pattern.

@thequicken Just create new mage definitions in the web UI manually and make sure name and even more important path match exactly what you have with the existing images. Be aware that case is important as well - Image123 is not image123!

@Trev-lchs said:

But if anyone knows what the fix is for the “Cannot install a CA Cert” that i have with client ver 0.12.0, that would be really very useful.

Possibly fixed in 0.12.1: https://github.com/FOGProject/fog-client/releases

@Trev-lchs Ok, I just pushed a change to dev-branch that should take care of this for you. Please run:

sudo -i
cd /root/fogproject/
git checkout dev-branch
git pull
cd bin
./installfog.sh

@ariederer26 You can try copying the whole directory /var/lib/mysql/ from that mounted external drive to your new 20.04 system and just hope it will come up fine.

1. Stop database service in the new 20.04 system.
2. Rename /var/lib/mysql/, e.g. to /var/lib/mysql_empty/.
3. Copy old database directory from external disk to /var/lib/mysql/ as mentioned above.
4. Match ownership/access rights of copied folders and files.
5. Start database service.
6. Pray and check log files and/or journalctl

@llamapie said in 1.5.9 Failing to install on Ubuntu:

I would still like to know why I was having issues on the Ubuntu install, however.

FOG 1.5.9 is a bit dated and won’t properly install on Ubuntu 22.04 - though it does work on Ubuntu 20.04 and 18.04.

If you want to use FOG on Ubuntu 22.04 you need to use the dev-branch version for now.

@george1421 said in Removing MACs from multicast task without starting over:

For the kernel parameter to FOS, should we use MCASTMAXWAIT as the variable? If its not set then set the default timeout to 15 minutes?

I had a quick look at the kernel parameters used so far. Looks like they are mostly in camel case, so you might spell it as mcastMaxWait.

I am not sure about the default yet. People are used to the behavior of clients waiting forever. While I do see this as a huge improvement to shut those down instead I am still wondering if changing the default could cause consequences in some circumstances?

And if we add the default I wonder if 10 minutes is better just so it’s the same default we use for --max-wait on the server side. But I am fine with 15 minutes too.

@Fog_Newb Thanks for the full log file!

We can ignore the error on install of php-mysql. While installing several php packages the system restarts php-fpm over and over again and it complains about that when done too often.

We should take care of this at some point within the installer: https://serverfault.com/a/930057

@dante From the PXE messages posted it looks pretty much like the VM boots in legacy BIOS mode. That’s fine. Though you need to point to a different iPXE file for this, e.g. ipxe.pxe or undionly.kpxe.

Most DHCP services can handle serving different filenames to UEFI and legacy BIOS systems. Not sure if pfSense is able to.

@alexamore90 Maybe there is a simpler way than the one @george1421 pointed out using a plain postinit script to print out the information you need and wait for someone to press a key to proceed.

@robertkwild I am not sure memtest is working on UEFI systems: https://forums.fogproject.org/topic/8153/memtest-fails-from-uefi-menu

@Londonium I finally found the time to look into this myself and do some testing. Sorry for the delay. Your debugging and posts helped a lot to nail this issue down, so thanks again!

Your VPN tunnel down scenario is kind of special. I triggers when port 21 (FTP) can be reached (socket connection fine and so online status true) but an FTP connection fails. What I mean is that the TCP connection opens but it doesn’t receive the FTP banner information as expected when connecting to a FTP server. I was able to replicate this behavior using netcat (listens on port 21 but does not respond to a full FTP connection try). It’s interesting you can trigger this issue by closing a VPN tunnel because to me it seems a TCP connection to port 21 is still being answered despite the VPN tunnel being down - maybe by the VPN router?

[11-09-22 8:36:47 pm] * Type: 2, File: /var/www/fog/lib/fog/fogurlrequests.class.php, Line: 611, Message: fsockopen(): unable to connect to 192.168.1.134:21 (Connection timed out), Host: 10.81.2.117, Username: fogproject

I was also able to replicate this scenario and found why it shows two different IPs (when “trigger_error” is commented). On FTP errors the PHP function error_get_last() is used to retrieve information from the last error happening and combines it with current host/username information. But when a FTP connect fails this is not a general PHP error and therefore the “trigger_error” is used to simulate this being a real PHP error. If “trigger_error” is not in place the last PHP error can be anything really and in your case it was the failed fsockopen connect to the prior storage node.

Anyhow, thanks to your topic I was able to improve the replication code (dev-branch 1.5.9.222) and make it skip to the next task/node in case of FTP connect errors.

@omar_medhat said in No Configuration methods succeeded !:

The switch is cisco C3750G and as soon as I configured the port as port-fast … Problem solved !

Well done.

OS is Ubuntu live server 16.04

Please make sure you switch to a more up to date OS before you go productive with this.