Remote Starter

Configuring Dnsmasq

The Dnsmasq service in the setup I describe here handles all DNS by DHCP and TFTP functions. It can be configured by editing two files: /etc/dnsmasq.conf and /etc/hosts. (See also the "Integrating the Domain Controller" box.) The /etc/hosts file has the names of the local systems for the DNS service, for example:

192.168.2.100 server1.domain.ip server1 ads

srv-host =_kerberos._udp.domain.ip, adc.domain.ip,88
srv-host =_kerberos._tcp.domain.ip, adc.domain.ip,88
srv-host =_kerberos-master._tcp.domain.ip, adc.domain.ip,88
srv-host =_kerberos-master._udp.domain.ip, adc.domain.ip,88
srv-host =_kpasswd._tcp.domain.ip, adc.domain.ip,88
srv-host =_kpasswd._udp.domain.ip, adc.domain.ip,88
srv-host =_ldap._tcp.domain.ip, adc.domain.ip,389
txt-record=_kerberos.domain.ip,"DOMAIN.IP"

The format starts with the IP address, followed by one or more hostnames, and one entry is the fully qualified domain name (FQDN). Moreover, you need to add an /etc/nameservers.conf file on the server, where you list Internet name servers to which the Dnsmasq service forwards external name requests. You need to enter your provider's DNS server addresses here – or those of free DNS providers such as Google. The dnsmasq.conf file then looks something like:

resolv-file=/etc/nameservers.conf
interface=eno1
dhcp-range=192.168.2.201, 192.168.2.250,72h

The interface line must contain the DHCP server NIC. The dhcp-range line specifies an address pool from which the DHCP clients obtain their IP addresses. The lease time of 72 hours here specifies how long DHCP clients can keep their addresses. If your provider has assigned you an IPv6 subnet, your DHCP server can pass on addresses from this segment to your LAN systems, which is sometimes referred to as "router advertisement":

enable-ra
dhcp-range=tag:eno1,::1, constructor:eno1, ra-names, 12h

If needed, you can specify additional DHCP options (according to RFC2132) that you want to pass to your clients, such as a NetBios name server:

dhcp-option=44,192.168.2.100

Dnsmasq also supports the more readable form:

dhcp-option=option:netbios-ns,192.168.2.100

The PXE configuration for the BIOS PXE module initially only comprises three lines:

enable-tftp
tftp-root=/var/lib/tftpboot
dhcp-boot=pxelinux.0

The pxelinux.0 file is the bootloader from the Syslinux package, which is then executed on the starting client. You could use the GRUB bootloader instead. In this article, I use it later for the UEFI boot example.

The PXE server gives the Syslinux bootloader a configuration file. To do this, create a pxelinux.cfg directory in /var/lib/tftpboot. In the directory, create a text file named default with the content:

MENU TITLE PXE Boot
TIMEOUT 200
TOTALTIMEOUT 6000
ONTIMEOUT local
LABEL local
      MENU LABEL (local)
      MENU DEFAULT
      LOCALBOOT 0

The entries are not case sensitive. The standard menu only gives users one option, starting from the system's local disk. A number of options make the PXE menu a bit more colorful and load a PNG image as background, but I will not go into them in detail here. The documentation for the syntax of a Syslinux menu can be found on the Syslinux wiki [1].

Starting Fedora with PXE

To boot a Fedora 34 Live system by PXE, first unpack the content of a Fedora 34 Live ISO image into a subdirectory of your web server:

mount -o loop Fedora-Workstation-Live-x86_64-34-<x.x>.iso /mnt
mkdir /var/www/html/f34
rsync -avx /mnt/ /var/www/html/f34/

Next, create the appropriate entry in /var/lib/tftpboot/pxelinux.cfg/default (Listing 1). After booting a client by PXE, you will see a selection menu for local (i.e., starting from the local hard drive or fedora34-live). You can boot other Live distributions such as Debian or Ubuntu in a similar way, and you can create kickstart files that automate the installation of a Linux system to enable a fully automatic install from the PXE menu.

label fedora34-live
   menu label Fedora 34 Workstation LiveBoot
   kernel http://<IP address of the DHCP server>/f34/images/pxeboot/vmlinuz
   append initrd=http://<IP address of DHCP server>/f34/images/pxeboot/initrd.img root=live:http://<IP address of DHCP server>/f34/LiveOS/squashfs.img ro rd.live.image rd.luks=0 rd.md=0 rd.dm=0

The menu does require the use of a modern PXE client that supports the HTTP protocol. Some older PXE implementations cannot handle the kernel http://… line. In a test setup, for example, this was the case with the PXE implementation in VirtualBox. To work around this, you need to copy the referenced files vmlinuz and initrd.img to a subdirectory in /var/lib/tftpboot and load them from there over TFTP instead of by HTTP. Assuming you create copies of the files in /var/lib/tftpboot/f34, the entry would be:

label fedora34-live via TFTP
  menu label Fedora 34 Workstation LiveBoot
  kernel f34/vmlinuz
  append initrd=f34/initrd.img root=live:http://<IP address of DHCP server>/f34/LiveOS/squashfs.img ro rd.live.image rd.luks=0 rd.md=0 rd.dm=0

By the way, the reference to squashfs.img by HTTP can be kept because it is evaluated by the booted kernel and not by the PXE loader.

Starting Windows by PXE

To start Windows with a Linux PXE server, you first need a Windows preinstallation environment (PE) ISO image. You will find instructions for setting up the image online [2]. It is important that you add all network drivers that are used on your systems to the PE image. Store the finished Windows PE image in the /var/lib/tftpboot directory of your TFTP server. For this example, I'll just dub the image winpe.iso. Next, add the following entry to your PXE start menu:

label windows
      kernel memdisk
      initrd winpe.iso
      append iso raw

Alternatively, extract the content of the Windows PE CD to a subdirectory on the TFTP server (e.g., /var/lib/tftpboot/pe) and get the bootloader wimboot from the iPXE package [3]. The entry now looks like this:

label wimboot
  kernel wimboot
  com32 linux.c32
  append wimboot initrdfile=pe/bootmgr,pe/boot/bcd,pe/boot/boot.sdi,pe/sources/boot.wim

The Windows PE instance can now be launched directly over the network, and you can run diagnostic tools or a Windows setup over the LAN. To do so, simply unpack a Windows installation DVD on a Windows or Samba file share. On the PE instance, open the Windows command line and enter the command:

net use w: \\<samba-server>\<share> /user:<username>

Next, change to the w: drive and to the subdirectory where you unpacked the DVD. From there, start the Windows installation with the setup.exe file. Again, you can automate the process with a suitable response file.