@sebastian-roth said in How to disable "password viewing" in the web UI:

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

Could we do something like this? https://www.csestack.org/hide-show-password-eye-icon-html-javascript/ where the field would always be protected but the FOG admin could click on the eye to display the password?

FOG already uses font awesome library. But I might have a simplistic view of the problem because I don’t know the code.

@rotoi I just thought of something else to try to totally remove ipxe from the picture (just in case its leaving something behind causing issues. I don’t think so, but we never really know).

I have this tutorial on how to usb boot into iPXE: https://forums.fogproject.org/topic/6350/usb-boot-uefi-client-into-fog-menu-easy-way

The idea is if we exchange ipxe.efi in this tutorial with the refind_x64.efi file (renamed according to the tutorial) then you should be able to boot into refind from the usb stick. You might get a warning because the config file is missing, but lets see if it get past initialization bit.

@rotoi Actually that is the easiest way.

When you get the hit s for command prompt, do that.

At the command prompt key in exit 1 and press enter. If that doesn’t work then try exit 2. This is just an experiment to see if what I read is accurate.

exit is a built in command into iPXE, where refind, ipxe chainloads refind.efi and lets refind boot the system. Exit and SANBOOT are built into to iPXE.

@elogan Ok that was the link I was going to give you. You can not connect through the fog server, but you can setup a synolgy nas as a “fake” fog storage node.

@zaboxmaster Just a bit of clarity that tutorial creates a usb bootable flash drive that uses grub as the menu manager not iPXE. We might use that if ipxe has a hardware compatibility issue with the target system. Or the system doesn’t have a network adapter that supports ipxe.

This tutorial here uses iPXE on a usb drive to jump into iPXE. https://forums.fogproject.org/topic/6350/usb-boot-uefi-client-into-fog-menu-easy-way In this case it uses ipxe.efi file that is renamed to bootx64.efi . You could use this process with snponly.efi or snp.efi. Just rename the file accordingly. In your case you probably want to use snp.efi. Consider where ipxe.efi contains all known drivers for most network adapters, snp and snponly only contains the snp network driver that uses the network adapters built in firmware. But that should work.

Reading between the lines here, you might want to update ipxe to the latest version to support newer hardware than FOG 1.5.9 when it was release: https://forums.fogproject.org/topic/15826/updating-compiling-the-latest-version-of-ipxe

@tyrel-sonohara said in Max clientes Storage Node:

By default, the defaultmember node’s max clients have a value of 10. Can I simply increase this value if I want to deploy to more than 10 computers at the same time?

The quick answer is yes to increase the number to deploy to more clients.

A bit longer answer is that if you are deploying to more than 3 unicast images at the same time you will saturate (fill up) a 1GbE network connection. Depending on how fast your storage disk is in your server you will saturate your disk subsystem at 6 unicast image deployments at the same time.

So to your question if you need to deploy to more than 10 computers at a time you should use a different FOG imaging technology called multicast image deployment. In this case the fog server only sends out one image and that same image is deployed to all computers that are signed up to listen to that image deployment. Multicasting requires more cooperation with your network infrastructure than simple unicast imaging (sending the image to one computer at a time)

@mgoh said in Reinstating Images to the Web UI:

I tried that, and the size of the image is 0 GB. Is that expected?

This is expected if you manually create the image definition. If you were to upload an image then that field gets populated. Its only used for display and not for any imaging activity. So it can stay at 0B forever.

@ljh What I’m asking is that actively how many computers with FOG Client is installed, is currently hitting this fog server. Is 4,000 the right number? If yes then when you look at the top command and sort by Processor do you see mysql at the top and many php-fpm processes under it?

If you set the fog client check in from 5 minutes (300 seconds) to 15 minutes (900) seconds does that fix some of the performance issues with the FOG web ui?

If yes then we may need to make an adjustment to the FOG server db.

@celsoares said in ACPI BiOS Error:

I accept a way to fix it or a way to ignore the error.

Again I understand the messages that are being displayed. If we ignore the messages for now, what is else not working?

@tatanas I know I hacked a solution years ago to do just this. For the life of me I can’t seem to find that post. If you are willing to work with me I think I can give you guidance on what needs to be done, then I can create a tutorial for others.

At the end of fog.man.reg there is this section as you have found.

dots "Attempting to register host"
res=""
while [[ -z $res ]]; do
    res=$(curl -Lks --data "sysuuid=${sysuuid}&mac=$mac&advanced=$(echo -n 1 | base64)&host=$host&imageid=$imageid&primaryuser=$primaryuser&other1=$other1&other2=$other2&doimage=$realdoimage&doad=$blDoAD&location=$location64&username=$user64&groupid=$group64&snapinid=$snapin64&productKey=$productKey" ${web}service/auto.register.php 2>/dev/null)
    echo "$res"
    usleep 2000000
done
. /bin/fog.inventory
usleep 2000000

The curl call registers the system with FOG and also posts an imaging deploy task, because this variable is set doimage=$realdoimage

So this sets the stage for imaging.

After the call to fog.inventory what you need to do is make a call to import the new environment (from the action of registering this computer with FOG) so it can pick up the imaging task.

I wrote a hack many years ago that go incorporate into the base image for USB imaging since iPXE was not being used.

That is in the master fog script: https://github.com/FOGProject/fos/blob/master/Buildroot/board/FOG/FOS/rootfs_overlay/bin/fog

#!/bin/bash
. /usr/share/fog/lib/funcs.sh
### If USB Boot device we need a way to get the kernel args properly
if [[ $boottype == usb && ! -z $web ]]; then
    sysuuid=$(dmidecode -s system-uuid)
    sysuuid=${sysuuid,,}
    mac=$(getMACAddresses)
    curl -Lks -o /tmp/hinfo.txt --data "sysuuid=${sysuuid}&mac=$mac" "${web}service/hostinfo.php" -A ''
    [[ -f /tmp/hinfo.txt ]] && . /tmp/hinfo.txt
fi

So what I would do is incorporate that section (minus the if statement) and once you stat the hinfo.txt file the environment should be properly setup to then jump to the /bin/fog.download command.

Will it work? It should. The fix I created at the time worked. Does it need a bit of debugging, yes it does. I think if you have made it this far with tweaking the fog.man.reg file you have the needed skills to take this next step.

@tyrel-sonohara The first choice if your router supports it is to use your router to supply pxe boot. If you have a router that is not playing nice, or a soho router, dnsmasq is the quickest way to a working solution. It takes about 10 minutes to setup: https://forums.fogproject.org/topic/12796/installing-dnsmasq-on-your-fog-server

@artemz Ok the thing that jumps out at me is that in the path just before the failed to open stream there is a preceding t that shouldn’t be there. I’m not sure if it is an artifact of the error message or someone accidentally put a t at the beginning of the storage node path in the default definition. t/images is surely an incorrect answer.

The step where it is failing is that the image has been uploaded to the FOG server in /images/dev/<mac address> The FOS Engine connects to the FOG server using FTP and issues a move command from /images/dev/<mac_address> to the protected /images/<image_name> directory. The error is saying its unable to find the /images/dev/<mac_address> directory to move it.

Once you find where that extra t is coming from then you should delete that /images/dev/<mac_address> or just manually move the directory to where FOG would have stored it and named correctly. The upload was complete just the FOS Engine could complete all of the steps. There should be no directories in /images/dev that look like mac address unless you are actively uploading an image. If they exist with no active uploads going on, you can delete just those directories because they are botched uploads and are just taking up space.

@ouédraogo Please update your FOS Linux kernel to version 5.15.x series for both x64 and x32. FOG UI -> FOG Configuration -> Kernel update.

That should address this issue.

@geekyjm said in PXE client not seeing new Fogserver:

How do I tell if the PXE server is running on the Fog server?

If you want to get literal, there is no such thing as a PXE server. PXE is a protocol not a thing.

DHCP tells the client where to look for the boot file. Then the client downloads what its told from a tftp server. That is the pxe process in 20 words or less.

The pcap is important to ensure the client computer is being told to load the right file from the proper computer. If you look in the OFFER packet (that comes from the dhcp server). In the header there will be a {next-server} field. That should be the IP address of the fog server. There should also be a {boot-file} field, that should be ipxe.efi or a uefi system and undionly.kpxe for bios system. That should match dhcp options 66 and 67 respectivly.

@trev-lchs What changed between 1.5.4 and 1.5.8 is that FOG switched from use a blank mysql root password to requiring the fog installer to set a password for the mysql root user because of security concerns. So when you transition from a version earlier than 1.5.8 it asks you to give the mysql root user a password, then it creates a new user ID and grants that user ID full access to the sql server database only. From then on the fog installer uses the fogstorage admin account for db access as well as upgrades leaving the root user and new secure password alone.

You can see the password set for fogstorage in the fog configuration -> fog settings page under STORAGENODE MYSQLUSER I’m going to recommend that you don’t change this password, leave it to the fog installer to do so. This password should match the password set in the .fogsettings file.

If one wanted to update this password. I would start by updating the password in the fog ui (understand this should break FOG right after saving the value), next using the mysql commands to update the fogstorage password in mysql. Then test to make sure you can log into the mysql cli using the new fogstorage password. Then update the .fogsettings file and then finally reboot. If the web ui fails then run the fog installer once more and reboot. If it still fails then we will need to manually update the web ui config file with the proper password. Understand while its possible to update the fogstorage account, there are also some risks in doing so.

@trev-lchs This is an interesting one. Lets try at the first question answering No to that. The error in the install log was saying that php-fpm could not be stopped, that is possible that the installer removed it. Lets try No there and see if it will run through to the end.

@trev-lchs said in Network Boot Error:

The result of all this is the screen shot above.

Do you have more than one dhcp server? Make sure the backup dhcp server has the options set too.

Is your pxe booting computer (that’s not currently working) on the same IP subnet as the fog server, or are they on a different IP subnet? If they are on the same IP subnet we can use the fog server to listen in on the dhcp process to find out what the client computer is being told to do. I think the problem right now is your network infrastructure and not fog, but the network pcap will tell us who is being told what.

Not sure I understand your follow up question, so I’m going to guess what you meant. For FOG you don’t need to change any settings between bios based computers and uefi based computers. The only difference is the iPXE boot loader that is needed to get to the FOG iPXE menu.

@wt_101 This is really a question for the developers, but…

Looking into the code it looks like you can update the database schema to 50 and then change the web ui from 15 to 50 characters in here fog/lib/pages/hostmanagementpage.class.php search for maxlength=“15”

I don’t see any other restrictions. There may be some qualifications when importing hosts via the web ui, but it looks like most of the code just takes hostname as it was entered.

As you are debugging this keep an eye on the php-fpm error log in /var/logs directory. If something unexpected happens in the UI, look there for the details on what happened.

@sourceminer So this gives us about 200GB of real data to move…

This is an interesting (hint: annoying) issue. So I take it there wasn’t any error on the blue partclone screen before it threw this error?

I can’t remember if I asked this, in this thread, but when you were at the command prompt where you check the partclone log file in /var/logs to see if it gives and clues??

With 200GB of data, that is typically larger than fog normally handles. So I wonder if we are running out memory to clone this big disk.

Under FOG WebUI -> FOG Configuration ->FOG Settings hit the expand all button.

Now search for CAPTURERESIZEPCT increase the value from 5 to 10.

Search for KERNEL RAMDISK SIZE set it to 275000 from 256000 (if its less than 256000, let me know). Lets see if this makes any difference.

@jape said in FOG unable to PXE boot beyond the VLAN/subnet that the server is on:

The Fog server is a Ubuntu 18 system it is also the DHCPD server .I have not changed the option 66 or 67.

OK now we have a direction. So can you tell me why you are using the FOG server as a dhcp server? Do you have a campus dhcp server or is FOG on a dedicated imaging network.

The question is not as cheeky as it sounds. There are valid use cases for having FOG be the dhcp server, I just want to make sure you have one of those cases.