@Sebastian-Roth I pm’d you a pcap
Ran these tests on my hyper-v and xcp vms:
wget --no-check-certificate https://fogserverip/fog/service/ipxe/bzImage
wget: not an http or ftp url: https://fogserverip/fog/service/ipxe/bzImage
bzImage...ok
I just want to reiterate that when I say slow/fast, I’m referring to the time it takes to initiate a download (get) of a file via HTTPS. Once the download starts, then the speed is fine.
@Sebastian-Roth physical PCs are still slower on HTTPS than HTTP. I was saying that the delay is exacerbated on VMs, especially slow (the slowest in fact) on XCP-NG guests. VirtualBox is better, physical is fastest. All three environments are still slower using HTTPS vs HTTP. I remember how instant HTTP was on any platform.
@Sebastian-Roth I tried intel.efi, still slow.
Booting from snponly.efi doesn’t recognize the network adapter. I tried using Intel and ParaVirt in VirtualBox.
Now that you’ve mentioned ipxe driver issue, it seems more likely. The delay is longer on my xencenter VMs vs VirtualBox VMs and physical PCs.
@Sebastian-Roth I haven’t tried different binaries yet. Wouldn’t I have to recompile them to use HTTPS? Did the -s switch during setup automatically compile all those efi binaries and place them into /tftproot?
@Sebastian-Roth Ran from a console, instant. Still working on getting an accurate pcap.
root@mypc:~/scripts# curl https://fogserverip/fog/service/ipxe/boot.php -k
#!ipxe
set fog-ip fogserverip
set fog-webroot fog
set boot-url https://${fog-ip}/${fog-webroot}
set storage-ip fogserverip
set keymap us
cpuid --ext 29 && set arch x86_64 || set arch i386
iseq ${platform} efi && set key 0x1b || set key 0x1b
iseq ${platform} efi && set keyName ESC || set keyName Escape
prompt --key ${key} --timeout 3000 Booting... (Press ${keyName} to access the menu) && goto menuAccess || exit
:menuAccess
login
params
param mac0 ${net0/mac}
param arch ${arch}
param platform ${platform}
param username ${username}
param password ${password}
param menuaccess 1
param debug 1
param sysuuid ${uuid}
isset ${net1/mac} && param mac1 ${net1/mac} || goto bootme
isset ${net2/mac} && param mac2 ${net2/mac} || goto bootme
:bootme
chain -ar https://fogserverip/fog/service/ipxe/boot.php##params
root@mypc:~/scripts# wget https://fogserverip/fog/service/ipxe/boot.php --no-check-certificate
--2023-02-22 11:54:54-- https://fogserverip/fog/service/ipxe/boot.php
Connecting to fogserverip:443... connected.
WARNING: cannot verify fogserverip's certificate, issued by ‘CN=FOG Server CA’:
Self-signed certificate encountered.
HTTP request sent, awaiting response... 200 OK
Length: unspecified [text/plain]
Saving to: ‘boot.php.1’
boot.php.1 [ <=> ] 813 --.-KB/s in 0s
2023-02-22 11:54:55 (180 MB/s) - ‘boot.php.1’ saved [813]
@Sebastian-Roth I just did some testing on my desktop, which is on a different vlan than the fog server, but shouldn’t matter:
On my Windows console:
curl and wget https://10.240.160.59/fog/service/ipxe/boot.php both show this message:
The underlying connection was closed: Could not establish trust relationship for the SSL/TLS secure channel.
I also have Linux sub-system on my Windows box:
curl https://10.240.160.59/fog/service/ipxe/boot.php
curl: (60) SSL certificate problem: self signed certificate in certificate chain
wget https://10.240.160.59/fog/service/ipxe/boot.php
–2023-02-21 13:26:44-- https://10.240.160.59/fog/service/ipxe/boot.php
Connecting to 10.240.160.59:443… connected.
ERROR: cannot verify 10.240.160.59’s certificate, issued by ‘CN=FOG Server CA’:
Self-signed certificate encountered.
To connect to 10.240.160.59 insecurely, use `–no-check-certificate’.
Obviously, I don’t have FOGs cert installed on my Windows PC, which I don’t need since I’m not doing any pxe ops from it.
I’m going to see if I can set up a VM to pxe boot while running wireshark in the bg.
EDIT: I have a Hyper-V vm booting to FOG via USB Boot method. I have a vm storage volume that has the bootx64.efi and I boot from that to start the iPXE boot process.
@Sebastian-Roth I confirmed with our network team that we scan traffic by protocol, so even if an app that isn’t a browser makes an HTTP/S connection, it will get scanned.
Ok so I browsed these links on my desktop using Firefox, and they loaded instantly:
https://<fog-ip>/fog/service/ipxe/boot.php - 96ms
https://<fog-ip>/fog/service/ipxe/boot.php##params - 96ms
We do in fact scan all traffic, but I noticed that the delay is only during ipxe ops.
I’ll run wireshark next.
@Sebastian-Roth That was my next guess but wanted to confirm that it wasn’t normal. Thanks!
@Sebastian-Roth Update: Yes the bzImage and init.xz also take longer to load now. Assuming because they are served via HTTP?
@Sebastian-Roth Once I start the PXE boot process, the boot kernel loads quick over TFTP, then the next part that loads boot.php takes longer. After I hit ESC to load the authentication screen, I enter my creds, then the next part where it loads the boot.php twice, then bg.png. After I get to the actual FOG ipxe menu, then load a custom ipxe entry such as WinPE, anything that loads via HTTP has a delay before starting the download. For my example of WinPE, the BCD, boot.sdi, bootmgr.efi, then finally the wim file which downloads normally, but there is a delay now before the download actually starts.
Does this make sense? My description of the issue I mean.
Running v1.5.9.231. I had to enable HTTPS since we use LDAP to authenticate when logging into FOG via web UI and the ipxe menu. Since then, anything pulled from either HTTP/HTTPS takes significantly more time to load. TFTP transfers are still fast and unaffected. The only transfers from HTTP that seem to be fine are those final WIM downloads (from the ipxe menu), but the files before that all take about 5 seconds to start fetching. It seems more like a delay than actual transfer speed.
Is this normal behavior for HTTPS?
@george1421 I tried entering a hostname after the prefix was appended, for example I entered “TestVM” thinking the full registered hostname would be “NCIT-TestVM”, but the device was registered as “TestVM”.
If I leave the hostname field blank during full reg, where it shows that the prefix is appended and the host name is autopopped, the MAC address becomes the registered hostname. Please note the “t Specified” hostname comes from the firmware of my Virtualbox VM.
@george1421 You sir, are the man. I added those two lines
read -p " * Enter destination department for this computer: " dname
host_default_name="${dname}-${host_default_name}";
to fog.man.reg and was prompted for a department code, entered the dept code, then the hostname autopopped with the dept code prefix appended. However, after the device is registered, the prefix is not appended to the registered name.
@george1421 I say method#2 works best. Which script should I modify and where? At the beginning or end? Would it work like “read bios serial# prompt for dept code” or “prompt for dept code read bios sn append prefix”?
I’m trying to figure out how to expand on the computer naming task while imaging.
I have a group called TestGroup. Let’s say this group is a department in my organization, and the department code is TG. The way we name our computers is DeptCode-serialnumber. So TG-1A2B3CD would be how we name a computer. In FOG, I create the group and see the option to join a domain. Great! However, I want to be able to add the prefix to the computer name BEFORE joining the domain. I already have a script in place during Full Reg that reads the system’s serial number from the BIOS and auto-populates it.
How can I tie that Full Reg script into Groups so that it will either automatically append the prefix or prompt me during Full Reg to specify a department code that is referenced in the Group?