@Greg-Plamondon Try these queries:

Get a list of (unique) host IDs where username logged in to:

SELECT DISTINCT utHostID FROM userTracking WHERE utUserName LIKE '%username%';

Now combine this query to get the list of hostnames as well:

SELECT hostID,hostName FROM hosts WHERE hostID IN (SELECT DISTINCT utHostID FROM userTracking WHERE utUserName LIKE '%username%');

Be aware that the first query might return more results than the later one because older user tracking entries will still exist even if you delete a host from your database. In that case the later query won’t return this host.

it does not work when I unicast to it either

@manuel-guerrero question - why are you trying to image AWS instances with fog? Are you aware AWS has built-in image capture as well as built-in snapshots you can utilize?

@george1421, ok, agradeço pela resposta.
É que na verdade eu queria colocar a imagem em uma partição de um pendrive bootável em que na outra partição contém um VENTOY com o Clonezilla, e pelo pendrive instalar esta imagem do pendrive em um computador diretamente.
Já realizei uma cópia (via RSync) para um pendrive com o Ventoy em uma partição e o espaço para imagem em outra (NTFS). Desta forma consigo consigo tudo via clonezilla para a máquina, porém quando inicio a máquina apóa a formatação na tela só é exibido as letras VT e não carrega o sistema. Poderia me ajudar neste sentido?

@gjo on the host itself, you can look in the fog client log. You can also look at the “PC properties” and see it’s domain status. in Active Directory Users and Computers, you should see the new computer object. A note on this you might not be aware of, FOG will rename the system to whatever name you have set in the FOG Server for that host, it does this just before domain joining.

When I was doing a lot of imaging, we would set the hostname during Host Registration.

@george1421

This is helpful, thanks.

Maybe I am doing something wrong.

Where do I take the access token from the webhook.

I tried with the bot access token and It gives me that:

e82be1b4-26d8-462b-8d90-2722c71cfb70-image.png

Is there any guide or someone who has it working that could help me?

Thank you in advance

@ocomas I am not exactly sure but sounds you run into the same issue described here: https://forums.fogproject.org/topic/14389/no-configuration-methods-succeeded-dhcp-failed

Simply changing the DHCP config helps in this case.

@dgux Will be interesing to see if you can get this to work. Though iPXE is just the starting point. You will need to set Linux kernel parameters for serial console as well. That’s pretty easy within the specific host settings. But I am not exactly sure if we have serial console driver compiled into the official kernel yet. Not a big deal though. See how far you get and keep us posted.

@sebastian-roth Thank you, I’ll do that 👍

@sebastian-roth I will search another solution. Thanks for your reply 🙂

@sebastian-roth Also, when we changed the subnet of the FOG server we didn’t create a new Server. I changed the IP values inside our original FOG server and reran the FOG Installer for the IP addresses to be changed throughout. After I ran the installer, I didn’t do anything with the certs inside the FOG server.

He’s probably looking at master branch.
Screenshot from 2022-03-16 22-35-28.png

For the record, dev-branch is kept more updated, but it’s not an official release. Though a lot of people use it (see usage report in my signature).

Screenshot from 2022-03-16 22-36-34.png

At least he didn’t say 5 years 😂 sourceforge hasn’t been updated in 5 years. Interestingly the traffic graph says it gets 50 weekly downloads. 🙄
https://sourceforge.net/projects/freeghost/files/FOG/stats/timeline

@george1421 Honestly, a better solution might be to use grub-reboot on startup in ubuntu. A bit hacky, but it’ll do

@p4cm4n There is a master imaging script that gets called when FOS Linux starts up its called simply fog https://github.com/FOGProject/fos/blob/fda59eca648af1a38ed57c94f65558221e77534f/Buildroot/board/FOG/FOS/rootfs_overlay/bin/fog#L1

At the beginning of that script on line 4 I added a long time ago the code for usb booting, in that the target computer would call back to the FOG server to get the kernel parameters. Normally iPXE would load the kernel parameters when fog imaging was requested. But with USB booting into FOS Linux there are no kernel parameters per se. So this code was added to the beginning of the master bash script.

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 specifically the curl calls back to the fog server to run a php file that loads the kernel parameters into /tmp/hinfo.txt then we stat or run that hinfo.txt file to load the kernel parameters into the bash variables. That was the trick to “rebooting” without actually restarting FOS Linux or the computer. Then after the variables were loaded I think I called fog.download directly.

If you look down that fog script a bit you will see the variables $mode and $type. After you load the kernel parameters you may need to unset $mode and set $type to “down” then call fog.download. That is what the script is checking for to know what fog module to call on each boot.

The trick is to call fog.download and not let the fog.man.reg exit, because when it does control will be returned to the main fog script and the target system will reboot.

@petec said in Hiren 1.0.2 PXE Boot:

initrd tftp://${fog-ip}/fog/hbcd/HBCD.iso
chain memdisk iso raw ||
boot || goto start

You have 2 problems here.

memdisk only works with BIOS computers. your iso has to fit inside a 32 bit address space. So the iso can’t be larger than 2GB in size (this also includes enough ram to run your OS too).

I have a tutorial here for hiren 1.0.1 here that might get you started: https://forums.fogproject.org/post/140212

@george1421 You helped a bunch my friend

i did some tweaking and now is works, here is the menu parameters for latest gparted:

kernel tftp://${fog-ip}/fog/gparted/live/vmlinuz
initrd tftp://${fog-ip}/fog/gparted/live/initrd.img
imgargs vmlinuz initrd=initrd.img boot=live config components union=overlay username=user noswap noeject vga=788 fetch=http://10.0.0.2/fog/filesystem.squashfs
boot || goto MENU

@anisgh Ok so lets follow that sysprep concept. The easiest solution is to not create the user when you build the golden image. I don’t use ubuntu so I don’t know if that’s an option. But lets say its not. So lets create a script called sysprep, and you would run that on your ubuntu golden image. Within that sysprep script you could execute a series of commands and then call a system shutdown (just like sysprep does). Now you need to decide what this sysprep script will do before shutting down ubuntu.

You might have it reset the hostname back to some generic name, and then remove the default added user with something like deluser --remove-home username The last thing you will need to setup is a first run script (akin to windows setupcomplete.cmd batch file) https://askubuntu.com/questions/156771/run-a-script-only-at-the-very-first-boot This will let you do some customization on first boot of the computer (like creating new use and such). You would do this with the unattend.xml file or the setupcomplete.cmd in windows anyway.

Now that you have the ubuntu image cleaned up shutdown the computer.

To extend this a bit more, in your post install script that renames the computer. You could access FOG fields like other1, other2, and (assigned user, don’t remember the actual field name). You use one of those fields to hold the name of the user account to create on the computer. You will write that user name to a text file that your first run script will find and create the user. When you create the user account with a generic password (like Password-1) use this to expire the account so they would be forced to reset the password on first login passwd --expire <username>

The point is to use FOG to leave bread crumbs in the target system based on deployment time values, then use a first run script in the target OS to pickup the crumbs and do something with them. This is the same for windows as well as linux. While FOS is linux, its not the target system linux so it can’t do much more than leave bread crumbs behind for the target OS to find.

SOLVED!

Solved it by adding the line RewriteCond %{REQUEST_URI} !^/utils to the VirtualHost block at /etc/httpd/conf.d/fog.conf so it looks like this now:

<VirtualHost *:80> <FilesMatch "\.php$"> SetHandler "proxy:fcgi://127.0.0.1:9000/" </FilesMatch> ServerName 10.0.0.1 ServerAlias fog.servers.domain.io DocumentRoot /var/www/html/ RewriteEngine On RewriteCond %{REQUEST_METHOD} ^(TRACE|TRACK) RewriteRule .* - [F] RewriteRule /management/other/ca.cert.der$ - [L] RewriteCond %{HTTPS} off RewriteCond %{REQUEST_URI} !^/utils RewriteRule (.*) https://%{HTTP_HOST}/$1 [R,L] </VirtualHost>

@george1421 hi and once again let me thank you for your time.
I just managed to get over the problem and disabled the HTTPS redirect for the /utils path.
SystemRescue loaded just fine.

I would suggest, maybe, adding this rule by default when we enable SSL on the fog server, and having therefor a specific path to put boot files that could be blocked by curl’s certificate check.