@george1421 Thank you so much … I updated the to the latest ipxe and it sorted out the issue .

@alexamore90 Updating FOG is a normal process of fog administration. I agree its been quite a while since the last update but the process is the same. FOG 1.5.10 should be released soon, but until then the FOG developers are suggesting that people upgrade to a pre release but stable version of the development release.

When you installed fog if you use the git method to download the installer files then upgrading is easy and you will not lose any configuration settings. To do the upgrade its pretty easy, to perform a dev-branch upgrade there is one more step.

In your case if you are on FOG version 1.5.9 and you use the git method you would simply change to the base of the install directory (typically in /root/fogproject) and issue these commands on the fog server.

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

The git checkout dev-branch command is what changes the installer to use the 1.5.9.115 (or later code base). When 1.5.10 is released you would simply replace that line with to go to the master code base with git checkout master and issue the same commands.

The installer installfog.sh will look at all of the answers you provided when fog was installed and use them during the reinstall.

After you update to the 1.5.9.115 dev release you will need to once again update the FOS Linux kernel to 5.15.x series (FOG WebUI->FOG Configuraiton->Kernel update, as well as recompile the latest version of iPXE using this tutorial https://forums.fogproject.org/topic/15826/updating-compiling-the-latest-version-of-ipxe when you complete these after steps you will be at a level that FOG 1.5.10 will be when its released. The above install process will make sure your FOG install will support the newest hardware released by the hardware manufacturers.

You say that you have 3 FOG servers you really should update them all to be on the same release or you won’t have the fix for the non-movable recovery partition that Microsoft created.

@george1421 Right. I won’t mess with it since we have it set up and working.

Vamos la, o IP esta 192.168.0.100, não estou usando roteador, as port 66 r 67 ja esta configuradas .

A versão que esta sendo usado e 1.5.9.

Estou usando direto em um cabo de rede, porem não inicia o pxe.

@sebastian-roth said in Image menu not showing recently created images:

@Jim-Holcomb How many images do you have? I am not aware of a limit of images that can be seen in the menu but I can’t tell you for sure.

So would you be able to delete an older one and see if one of the new one pops up in the menu?

Hello Sebastian - I tried that - deleting older images. No joy. You know that the image menu just keeps going to the next number in order. I am currently at 160, but of course I do not have anywhere near that many images. Then menu goes to 158 then ends. Yet if I go to “List all Images” of course the image resides there with all of it’s available information, size, date, etc…

I am stumped here.

@londonfog You only get this screen when you do a deploy image from the iPXE menu? Where a traditional unicast (by registering the target computer and then picking deploy) works correctly?

OK lets see if we can get the target computer into debug mode another way. FOG WebUI->FOG Configuration->FOG Sertings Hit the expand all button, then search for KERNEL DEBUG and enable the check box and hit save. Now pxe boot the computer and go through deploy image. Does that put you to the linux command prompt?

If not go back into the same area and uncheck that option and then search for KERNEL ARGS and paste in isdebug=yes and try it again.

Hopefully one of the methods will get us into debug mode.

@george1421 said in Host status is unknow 2:

@eliaspereira So does it work now that you fixed name resolution on the FOG server?

At first, yes.

Thanks again for the great help!!!

Nice, working!
Thanks a lot for the tutorial and all the work!

@londonfog This is just a guess but the api token should be in the WebUI -> FOG Configuration -> FOG Settings page. Just hit the expand all button then search the page for API. This is where I might expect to find FOG (itself) related settings.

@george1421 Thanks work like i want !

@eliaspereira said in wake on lan not working:

fogserver is in a different vlan from the vlans

This is going to be your first problem. The wol magic packet is not a proper IP packet so it typically can’t traverse a router. There is a way to send WOL packet but you need to send as a directed broadcasts. On most routers this “feature” is disabled because it could be used to abuse your networks.

Are you using (or wanting to use) WOL to wake up computers for imaging or just to wake up computers at a specific time?

Understand this subnet issue is a limitation of the WOL protocol and not FOG.

@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.

@cwentwo Ok great on the single subnet.

I have a tutorial here on using the FOG server to capture the pxe boot information. On this system that fails to pxe boot follow this tutorial on how to setup the packet capture. Upload the captured file to a file share site with public read with the link and then either post the link here or DM me the link using FOG chat. I’ll take a look at the pcap to see what the client isn’t being told correctly.

https://forums.fogproject.org/topic/9673/when-dhcp-pxe-booting-process-goes-bad-and-you-have-no-clue

The filter used will specifically only collect the pxe booting process and nothing else. The total packet count of a healthy PXE boot is about 8 packets captured.

@florent 0.13.3.1 is the version I already tested previously.

@sebastian-roth Thanks for your answer. I wait then 🙂

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

Would be interesting to hear what others think about this.

Couple thoughts…

You can create an Active Directory service account with pretty limited permissions, only allowing it to join systems to the domain, and use this for FOG. This is something everyone can begin doing right now. This reduces the blast-radius should the credentials that FOG uses became exposed or compromised.

In the great majority of enterprise I.T. systems I work in, you can retrieve a credential “ID” (like username or access key) but cannot retrieve the credential “secret” (like a password or secret key). FOG is unique in this area, because the FOG Client needs the complete credential. Though, users should be entirely prevented from retrieving this credential… more on this in points below.

Merely concealing the password with the UI, someone who already has access to the FOG server could still potentially use the API to get the password. So, concealing via the UI is just obfuscation and not real security. Concealing via the UI is likely fairly easy to do and would result in less bugs to work out, but this isn’t real security.

Best solution in my view is to store the password within the database using reversible encryption. The encryption key should be generated by the FOG Installer, and put into /opt/fog/.fogsettings. The API / web components would then use one of several ways to handle encrypting and decrypting using this key. A quick internet search reveals lots of options:

https://stackoverflow.com/questions/9262109/simplest-two-way-encryption-using-php https://www.educba.com/php-encryption/ https://www.tonymarston.net/php-mysql/encryption.html

After implementing, the ability to retrieve the password in any form/nature should be secured… which leads into point 5 below.

The transport layer between the FOG Client and FOG Server is already encrypted, but should someone call the server endpoint to get the credentials, we don’t want the password to appear plain-text within the server response. I’ve not looked into how this currently works so I’m unsure in this area. But, I’d think the FOG Client would first prove it’s identity with client-based authentication, and after this the FOG Server would provide the password to the FOG Client. Maybe it already works this way? No idea. I’m remembering @Joe-Schmitt talking about this, and how he worked with @Tom-Elliott to solve it… This was a long long time ago though, and my memory of it is super fuzzy.

@cwentwo You are amazing! That did it! Thank you!

@dima1002
use Debian 10 instead of debian 11
it’s php-gettext for Debian 10 , but it’s php-php-gettext for Debian 11