@george1421 These are the commands that I run on my secondary to pull from the primary:
mysqldump --defaults-file=/root/.my.cnf -h fogserver -u fogstorage fog hosts hostMAC moduleStatusByHost --single-transaction > /root/fog_hosts.sql
mysqldump --defaults-file=/root/.my.cnf -h fogserver -u fogstorage fog images --single-transaction > /root/fog_images.sql
@george1421 We dont have Storage Nodes (yet). But I do run a cronjob on my secondary FOG server that pulls mysql db from the primary, basic backup job. Will locking down the mysql port prevent this function?
Doing some routine security checkups on our FOG server. Noticed the mysql TCP 3306 is open. Does this need to be open for FOG to function properly?
@george1421 If I do everything manually as I’ve been doing, it works fine. Just looking to save some keystrokes. The boot.wim I’m building using MS Endpoint Config Manager Console does not have any task sequences but instead contacts the MG/DP for available task sequences and goes from there. Its easier this way. If we start to make stand-alone TS ISOs the wim files will become too large for ipxe.
Actually did it this way, sloppy but it works:
#!/bin/bash
wimlib-imagex mountrw sccmfiles/sources/boot.wim 1 mntpnt && cp -drn sccmfiles/SMS/* mntpnt/sms/ && rm -f mntpnt/Windows/System32/winpeshl.ini && cp winpeshl.ini mntpnt/Windows/System32/ && cp bootstrap.vbs mntpnt/sms/bin/x64/ && wimlib-imagex unmount mntpnt --commit && scp sources/boot.wim administrator@<fog_server_IP>:/home/administrator
And this script on the FOG server:
#!/bin/bash
rm /home/administrator/sccm_test/boot.wim && mv /home/administrator/boot.wim /home/administrator/sccm_test/boot.wim rm /var/www/sccm_test/boot.wim && cp sccm_test/boot.wim /var/www/sccm_test/ && chown fogproject:www-data /var/www/sccm_test/boot.wim
@george1421 Microsoft doesn’t like to play nice with other products and services unless they can buy them outright 
This part is what I tried making into a script and it threw errors (update imagex to wimlib-imagex as the package binary name has changed):
wimlib-imagex mountrw sccmfiles/sources/boot.wim 1 mntpnt
cp -drn sccmfiles/sms/* mntpnt/sms/
rm -f mntpnt/Windows/System32/winpeshl.ini
cp winpeshl.ini mntpnt/Windows/System32/
cp bootstrap.vbs mntpnt/sms/bin/x64/
wimlib-imagex unmount mntpnt --commit
This is what I tried as a script:
#!/bin/bash
wimlib-imagex mountrw sccmfiles/sources/boot.wim 1 mntpnt &&
cp -drn sccmfiles/SMS/* mntpnt/sms/ << captial SMS from the ISO
rm -f mntpnt/Windows/System32/winpeshl.ini
cp winpeshl.ini mntpnt/Windows/System32/
cp bootstrap.vbs mntpnt/sms/bin/x64/
wimlib-imagex unmount mntpnt --commit
Found the solution. I had to Create Task Sequence Media, Bootable ISO. Then took the files from the ISO put them in a folder. Followed the instructions https://ipxe.org/howto/sccm. It seems that when I did this, the boot image actually matches the one associated to the task sequence. I don’t see another way to make this work.
@george1421 I had to disable tftpd and add that line to get it to serve ipxe.efi properly.
@rogerbrowntdl Ok so it seems that tftpd might still be running.
First stop and disable the tftpd service
sudo systemctl stop tftpd.service && sudo systemctl disable tftpd.service
Make sure dnsmasq isn’t running
sudo systemctl stop dnsmasq.service
Edit/Create a file called ltsp.conf in the /etc/dnsmasq.d directory
sudo nano /etc/dnsmasq.d/ltsp.conf
Paste the following code and replace <fog_server_IP> with your FOG server’s IP address
# Don't function as a DNS server:
port=0
# Log lots of extra information about DHCP transactions.
log-dhcp
# Enable TFTP
enable-tftp
# Set the root directory for files available via FTP.
tftp-root=/tftpboot
# The boot filename, Server name, Server Ip Address
dhcp-boot=undionly.kpxe,,<fog_server_IP>
# Disable re-use of the DHCP servername and filename fields as extra
# option space. That's to avoid confusing some old or broken DHCP clients.
dhcp-no-override
# inspect the vendor class string and match the text to set the tag
dhcp-vendorclass=BIOS,PXEClient:Arch:00000
Then start dnsmasq
sudo systemctl start dnsmasq.service
Let me know how that works out for you.
@rogerbrowntdl Yes they are two different services. tftpd is what FOG uses by default. The TFTP protocol listens on TCP port 69, so two services cannot listen on the same port at the same time.
@rogerbrowntdl dnsmasq runs on the FOG server to detect architecture and boot type then serve the boot files over tftp. This is my understanding of how it all works:
PC sends DHCP server a request for an IP address with a pxe packet.
DHCP assigns an IP address then directs (relays) the PC to the FOG server.
FOG Server handles this request by sending either undionly.kpxe or ipxe.efi depending on the architecture of the PC (dnsmasq tftp service).
PC downloads and executes the correct file.
After that FOG loads the boot menus.
@rogerbrowntdl We have the Fortigate DHCP relay set up with the FOG server IP. I did however have to install dnsmasq on my FOG server and disable tftpd.service. Here is where I found the instructions: https://forums.fogproject.org/topic/12133/fog-on-existing-dhcp-server
The code posted by @george1421 needed one line added which is marked below. Just remove the asterisks:
# Don't function as a DNS server:
port=0
# Log lots of extra information about DHCP transactions.
log-dhcp
**# Enable TFTP
enable-tftp**
# Set the root directory for files available via FTP.
tftp-root=/tftpboot
# The boot filename, Server name, Server Ip Address
dhcp-boot=undionly.kpxe,,<fog_server_IP>
# Disable re-use of the DHCP servername and filename fields as extra
# option space. That's to avoid confusing some old or broken DHCP clients.
dhcp-no-override
# inspect the vendor class string and match the text to set the tag
dhcp-vendorclass=BIOS,PXEClient:Arch:00000
@rogerbrowntdl Yes very similar to Fortigate. So I have a Fortigate 70D in my offline lab, and have it set up same as you, but for ipxe (UEFI only) boot. DHCP option 67 can only specify one file name. My suggestion is to see if your DHCP server supports DHCP relay. If it does, specify your FOG server IP address. Since your FOG server is already set up to not hand out IP addresses, you should be good to go after that. We have DHCP relay set up on our prod network and both UEFI and Legacy pxe boot work just fine.
Oh and unfortunately you cannot add UEFI to a legacy device as far as I know. Not sure if it is a hardware or firmware limitation.
Any SCCM wizards out there using FOG and SCCM WDS together? Could use some help with something. I have FOG as the primary pxe boot server, and on the FOG ipxe menu, SCCM Boot is one of the options. The boot image wim file that gets downloaded is the same exact wim that is deployed to distribution points and is assigned to a task sequence that I am running. The issue is that once I run the task sequence it starts to download the wim from the DP and then asks to remove CD and restart. I’ve read that the package ID and version have to match between your boot media wim and the boot image wim assigned to the TS. In my case they do and are the same exact file. The ONLY difference, is that I had to modify the wim to be able to boot from a non-WDS pxe server, as per these instructions.
https://ipxe.org/howto/sccm
@rogerbrowntdl How is your DHCP server currently configured for PXE boot?
@george1421 Right. I won’t mess with it since we have it set up and working.
@george1421 said in Modify the ipxe Advanced login menu:
clear username
clear password
prompt --key y --timeout 5000 For IT Only, press ‘y’ to enter the secret IT cave && login || goto fog.local
params
param username ${username}
param password ${password}
chain ${boot-url}/service/ipxe/advanced.php##params
This ipxe menu entry worked, but only after I logged in via that blue advanced login page. Its alright, there is also a timeout on that blue login, so if an end-user accidentally goes there, they’ll just call our helpdesk, and we handle it from there moving forward.
@george1421 No dice. Didn’t see the echo’d text. This suggestion might complicate things, but what if before loading that login menu, we load another custom menu, that warns the user that “This menu is for IT only, if you are not authorized, please wait 5 seconds until Windows boots…” then from there chain the login page. That’s a stretch I know, but we are beginning to explore making FOG accessible from other VLANs and departments to make our lives easier. Better than bringing a drive or a whole PC back to the shop to reimage it. I may be overthinking this, because even some of my collegues miss the “press ESC to load FOG” prompt during the initial PXE boot, so this might not even be necessary as most people will overlook it.
@junkhacker Ah okay. So the text on that screen are baked into a file somewhere right? The ipxe.efi image?