Dnsmasq proxy booting with UEFI
-
@Killklli @Moderators @Developers
It’s really easy to set it up for just UEFI. You just change the filename in the ltsp.conf file, and then make sure you have the appropriate symbolic link for the file you want to use.
As far as legacy & UEFI co-existence using dnsmasq - we don’t have an answer for that yet. If you figure it out, I will add it to this wiki article: https://wiki.fogproject.org/wiki/index.php/BIOS_and_UEFI_Co-Existence
However - since I have been looking into this lately, give this a shot… if it blows up I’m sorry, it’s not been tested - but maybe you can figure it out. I’ve been intending on testing this for a while but just haven’t gotten around to it. Let me know any errors that you encounter with the dnsmasq service status and any weird behavior.
port=0 log-dhcp tftp-root=/tftpboot # I commented this line out because we don't want to blast out one file for everything. #dhcp-boot=undionly.0,x.x.x.x,x.x.x.x dhcp-option=17,/images dhcp-option=vendor:PXEClient,6,2b dhcp-no-override #Here, I define netboot types dhcp-vendorclass=BIOS,PXEClient:Arch:00006 dhcp-vendorclass=UEFI,PXEClient:Arch:00007 #Set bootfile names depending on the client vendor identifier dhcp-boot=BIOS,undionly.0 dhcp-boot=UEFI,ipxe.0 pxe-prompt="Press F8 for boot menu", 3 pxe-service=X86PC, “Boot from network”, undionly pxe-service=X86PC, "Boot from local hard disk", 0 dhcp-range=x.x.x.x,proxy
Resource used:
http://ltsp.fi/howto/LTSP-PNP/LTSP-PNP1.pdfAnd to make sure the resource doesn’t go away, here’s a copy of what’s in that PDF:
LTSP-PNP #1 (KVM) LTSP-PNP server with one network interface, dnsmasq with other dhcpd server. DHCP SERVER = 192.168.100.77 LTSP-PNP SERVER = 192.168.100.120 GATEWAY = 192.168.100.10 DNS SERVER = 192.168.43.1 A. INTERFACES/NETWORK A1. /etc/netwrok/interfaces # This file describes the network interfaces available on your system # and how to activate them. For more information, see interfaces(5). # The loopback network interface auto lo iface lo inet loopback # The primary network interface auto eth0 iface eth0 inet static address 192.168.100.120 netmask 255.255.255.0 gateway 192.168.100.10 A2. /etc/resolvconf/resolv.conf.d/tail nameserver 192.168.43.1 nameserver 8.8.4.4 nameserver 8.8.8.8 B. DNSMASQD B1. /etc/dnsmasq.d/ltsp-server-dnsmasq.conf # Configures dnsmasq for PXE client booting. # All the files in /etc/dnsmasq.d/ override the main dnsmasq configuration in # /etc/dnsmasq.conf. # You may modify this file to suit your needs, or create new ones in dnsmasq.d/. # Log lots of extra information about DHCP transactions. #log-dhcp # IP ranges to hand out. #dhcp-range=192.168.67.20,192.168.67.250,8h # If another DHCP server is present on the network, you may use a proxy range # instead. This makes dnsmasq provide boot information but not IP leases. # (needs dnsmasq 2.48+) dhcp-range=192.168.100.0,proxy # The rootpath option is used by both NFS and NBD. dhcp-option=17,/opt/ltsp/i386 # Define common netboot types. dhcp-vendorclass=etherboot,Etherboot dhcp-vendorclass=pxe,PXEClient dhcp-vendorclass=ltsp,"Linux ipconfig" # Set the boot filename depending on the client vendor identifier. # The boot filename is relative to tftp-root. dhcp-boot=net:pxe,/ltsp/i386/pxelinux.0 dhcp-boot=net:etherboot,/ltsp/i386/nbi.img dhcp-boot=net:ltsp,/ltsp/i386/lts.conf # Kill multicast. dhcp-option=vendor:pxe,6,2b # 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 # We don't want a PXE menu since we're using a graphical PXELinux menu. #pxe-prompt="Press F8 for boot menu", 3 # The known types are x86PC, PC98, IA64_EFI, Alpha, Arc_x86, # Intel_Lean_Client, IA32_EFI, BC_EFI, Xscale_EFI and X86-64_EFI pxe-service=X86PC, "Boot from network", /ltsp/i386/pxelinux # A boot service type of 0 is special, and will abort the # net boot procedure and continue booting from local media. #pxe-service=X86PC, "Boot from local hard disk", 0 # Comment the following to disable the TFTP server functionality of dnsmasq. enable-tftp # The TFTP directory. Sometimes /srv/tftp is used instead. tftp-root=/var/lib/tftpboot/ # Disable the DNS server functionality of dnsmasq by setting port=0 port=0 # Don't listen on lo, to prevent conflicts with Ubuntu's local resolver hack (LP: #959037). #except-interface=lo #bind-interfaces C. DHCP C1. /etc/dhcp/dhcpd.conf # # Default LTSP dhcpd.conf config file. # authoritative; subnet 192.168.100.0 netmask 255.255.255.0 { range 192.168.100.200 192.168.100.250; option domain-name "ltsp-pnp"; option domain-name-servers 192.168.43.1; option broadcast-address 192.168.100.255; option routers 192.168.100.10; option subnet-mask 255.255.255.0; option root-path "/opt/ltsp/i386"; if substring( option vendor-class-identifier, 0, 9 ) = "PXEClient" { filename "/ltsp/i386/pxelinux.0"; } else { filename "/ltsp/i386/nbi.img"; } } D. LTS.CONF D1. /var/lib/tftpboot/ltsp/i386/lts.conf [Default] SCREEN_02=shell SCREEN_07=ldm # RM_SYSTEM_SERVICES="dnsmasq nbd-server" RM_THIN_SYSTEM_SERVICES="qemu-kvm virtualbox" # LDM_DIRECTX=True USE_LOCAL_SWAP=True SSH_FOLLOW_SYMLINKS=False NFS_HOME=/home # LDM_FORCE_SESSION=/usr/bin/startlubuntu LDM_FORCE_LANGUAGE="fi_FI.UTF-8" LDM_LIMIT_ONE_SESSION=True LDM_LIMIT_ONE_SESSION_PROMPT=True XKBLAYOUT="fi" X_BLANKING=0 X_NUMLOCK=False # [52:54:00:00:57:B2] HOSTNAME=ltsp001 LDM_AUTOLOGIN=True LDM_USERNAME=ltsp001 LDM_PASSWORD=ltsp001 E. NFS E1. /etc/exports # /etc/exports: the access control list for filesystems which may be exported # to NFS clients. See exports(5). # # Example for NFSv2 and NFSv3: # /srv/homes hostname1(rw,sync,no_subtree_check) hostname2(ro,sync,no_subtree_check) # # Example for NFSv4: # /srv/nfs4 gss/krb5i(rw,sync,fsid=0,crossmnt,no_subtree_check) # /srv/nfs4/homes gss/krb5i(rw,sync,no_subtree_check) # /home *(rw,sync,no_subtree_check)
-
@Developers I wonder if we even need that little menu that dnsmasq gives? it’s always been a PITA to me.
-
Its strange, even though that first block should just work out of the box because its a proxy for a DHCP server its still not grabbing the right info for it. I think it might be an issue with my DHCP server because its just giving me a PXE-E18: Server response timeout. Its just a pain because I have no access to the DHCP server itself.
-
@Killklli said:
Its just a pain because I have no access to the DHCP server itself.
I feel you. But at the same time - I know people who are CompTIA Net+ certified who have no clue how DHCP works… Absolutely no clue other than “it gives IPs out”.
Well - knowing that isn’t good enough. You have to be omni-aware of your environment. For instance, you CANNOT just “forget” that DHCP is running on your MAC server and then fire up DHCP on a windows server like one of my not-to-be-named co-workers did… Managing network services like this requires a person who is detail oriented and a person who is very knowledgeable about such services… I’m not saying your not that person, but odds are, whoever controls it in your environment aren’t as knowledgeable as I’m describing either - most network admins simply freeze up and don’t change anything for fear of causing an outage - and that’s a no good network admin. See, thats why most of those guys get paid salary - so they can setup a small environment at home to test with, or they should setup a mini environment at work just for testing - this way they greatly reduce the chances of making a mistake on the production network.
-
@Killklli Try this. And you are filling in your IP where it has x.x.x.x right?
port=0 log-dhcp tftp-root=/tftpboot # I commented this line out because we don't want to blast out one file for everything. #dhcp-boot=undionly.0,x.x.x.x,x.x.x.x dhcp-option=17,/images dhcp-no-override #Commented this line out #dhcp-option=vendor:PXEClient,6,2b #Here, I define netboot types dhcp-vendorclass=BIOS,PXEClient:Arch:00006 dhcp-vendorclass=UEFI,PXEClient:Arch:00007 #Set bootfile names depending on the client vendor identifier dhcp-boot=BIOS,undionly.0 dhcp-boot=UEFI,ipxe.0 pxe-prompt="Press F8 for boot menu", 3 pxe-service=X86PC, “Boot from network”, undionly pxe-service=X86PC, "Boot from local hard disk", 0 dhcp-range=x.x.x.x,proxy
-
I’ll try to revisit the BIOS & UEFI co-existence topic in the following days.
This is just something that I have to sit down and work on for a good while.
-
@Wayne-Workman I was working with a non production server at first but I hit a point where I needed to take it out of that and try to get it to work with the pre existing one. Its for the Comp Sci departments computer lab on my campus. They actually set us up in such a way where if we screw up with DHCP it doesn’t mess up the rest of campus. Its been broken too man times. I’ll give that new one a shot, and yep I’ve been filling in the static IP.
-
@Wayne-Workman Hmm, I’m still having an issue with PXE-E18. There’s a good chance its on their end. When I can physically get to the machine in the morning I’ll hook it back up to my network and see if having the UEFI DHCP running. If it works at least then I know for a fact its on their end and not mine.
—Edit—
Turns out that config is working with the Legacy version as well. As of writing this UEFI still is not working but its working for legacy. -
@Killklli @Wayne-Workman Sadly its still not working. I tried on a non production DHCP server and its still not pushing it out with the code you gave me. The DHCP server I have even has factors set for a UEFI gateway and dns. I’m using a Server 2012 DHCP/DNS server and Ubuntu 12.04 running fog 1.20 for it by the way. Is there anything else I can try?
-
@Killklli I’m not sure the code I gave you even works - it was just a guess. I was hoping you’d play around with it. I’ll have to find time to sit down and work with it.
-
@Wayne-Workman I’ve been trying multiple things in the meantime but have still yet to be successful with it. It was a good jumping off point but I’ve still yet to hit the right point. Thanks for your help.
-
@Wayne-Workman Turns out it was an issue with having both the Legacy vendor and the UEFI vendor listed. Its at least seeing the server now but now I dive into the hole of “Failed Secure Boot Verification”
-EDIT-
Scratch that. Still hates me. It was an issue with a VM. It is downloading now though.–Edit Edit–
I had an extra DHCP option still on. Still not downloading. But If I go back to legacy mode those options work. -
@Killklli In the mean time, the link I gave you about BIOS UEFI coexistence gives step-by-step instructions for Server 2012 and later.
You could pass that link off to your network guys and just respectfully ask that they look at this.
NOTE: that the method described there won’t work for server 2008 and lower.
-
@Killklli Wait… what does the ltsp.conf file look like right now?
can you add comments so we know what you’ve done?
-
@Wayne-Workman Sorry about the delay right now it looks like. I’ve tried multiple configs so this one is more or less a start over of where I was originally. So not much has changed currently.
port=0 log-dhcp tftp-root=/tftpboot dhcp-option=17,/images #Removed dhcp-option=vendor:PXEClient,6,2b dhcp-no-override #removed dhcp-vendorclass=BIOS,PXEClient:Arch:00006 dhcp-vendorclass=UEFI,PXEClient:Arch:00007 dhcp-boot-UEFI,ipxe.0 pxe-prompt="Press F8 for boot menu", 3 pxe-service=X86PC, "Boot from network", undionly #removed local boot its un-needed dhcp-range=192.168.1.2,proxy
-
@Killklli and the contents of your tftpboot directory?
ls -lahRt /tftpboot
-
@Wayne-Workman Here’s a screenshot.
-
@Killklli you don’t have a copy or a symbolic link of ipxe.efi for ipxe.0
so lets fix that first:
ln -s /tftpboot/ipxe.efi /tftpboot/ipxe.0 or cd /tftpboot ln -s ipxe.efi ipxe.0
Then try the scripts I gave you - and play around with them a little.
-
@Killklli I’m not 100% sure you need to specify the file as ipxe.0. With Proxy dhcp the .0 extension is automatically appended, and I can’t keep it from appending it. So If my suspicions are correct, it may actually be looking for a file called: ipxe.0.0 as well. I don’t know for sure though.
-
@Tom-Elliott It does. At least it did in my environment when I was fighting with it. Getting close to being able to revisit this subject myself. Expect to be migrating our DHCP servers to WinSrv 2012R2 in the next 30 days.