forked from server/user-documentation
Compare commits
8 commits
main
...
pxe_netwin
| Author | SHA1 | Date | |
|---|---|---|---|
| 4eb37faa05 | |||
| a120278c8b | |||
| f03a12fc56 | |||
| 802a575272 | |||
| 028e35067c | |||
| 2634243ad3 | |||
|
f2ad6403be | ||
|
|
e29598c185 |
4 changed files with 753 additions and 131 deletions
116
modules/ROOT/pages/administration/dnsmasq-pxeboot.adoc
Normal file
116
modules/ROOT/pages/administration/dnsmasq-pxeboot.adoc
Normal file
|
|
@ -0,0 +1,116 @@
|
|||
= Configuring dnsmasq for PXE boot and tftp support
|
||||
Peter Boy; Jan Kuparinen; Emmanuel Seyman
|
||||
:page-authors: {author}, {author_2}, {author_3}
|
||||
:revnumber: F35-F37
|
||||
:revdate: 2000-00-00
|
||||
|
||||
|
||||
[abstract]
|
||||
The dnsmasq program supports configuration for PXE boot and even includes a tftp server to provide the download of operating and installation systems. This article describes it's configuration.
|
||||
|
||||
|
||||
[IMPORTANT]
|
||||
====
|
||||
**Status** Work in progress
|
||||
====
|
||||
|
||||
Install dnsmasq as described in xref:administration/dnsmasq.adoc[_Setting up dnsmasq - a lightweight DHCP and DNS server_]
|
||||
|
||||
|
||||
== Configuring special services
|
||||
|
||||
=== PXE service
|
||||
see: https://apuntesderootblog.wordpress.com/2020/09/04/pxe-server-in-fedora-with-dnsmasq/[PXE server in Fedora with dnsmasq]
|
||||
|
||||
|
||||
|
||||
# yum install dnsmasq
|
||||
|
||||
Edit /etc/dnsmasq.conf and configure entries for PXE clients and other systems on the network, for example:
|
||||
|
||||
interface=eth1
|
||||
dhcp-range=10.0.0.101,10.0.0.200,6h
|
||||
dhcp-host=80:00:27:c6:a1:16,10.0.0.253,svr1,infinite
|
||||
dhcp-boot=pxelinux/pxelinux.0
|
||||
enable-tftp
|
||||
tftp-root=/var/lib/tftpboot
|
||||
|
||||
The lines in the sample configuration file do the following:
|
||||
|
||||
interface=eth1
|
||||
|
||||
Listen for incoming client requests on interface eth1 only.
|
||||
dhcp-range=10.0.0.101,10.0.0.200,6h
|
||||
|
||||
Reserve a pool of generally available IP addresses in the range 10.0.0.101 through 10.0.0.200 on the 10.0.0/24 subnet with a six-hour lease.
|
||||
Note
|
||||
|
||||
A dhcp-range setting is required to enable the DHCP service provided by dnsmasq. If you want to configure static addresses but not an address pool, specify a static network address and the keywords static and infinite, for example:
|
||||
|
||||
dhcp-range=10.0.0.253,static,infinite
|
||||
|
||||
dhcp-host=80:00:27:c6:a1:16,10.0.0.253,svr1,infinite
|
||||
|
||||
Reserve the IP address 10.0.0.253 with infinite lease time for svr1, which is identified by the MAC address 08:00:27:c6:a1:16.
|
||||
dhcp-boot=pxelinux/pxelinux.0
|
||||
|
||||
Specify the location of the boot-loader file required by PXE clients. This example supports BIOS-based PXE clients. An entry that supports UEFI-based clients might take the following form:
|
||||
|
||||
dhcp-boot=efi/BOOTX64.efi
|
||||
|
||||
If you want to use a separate TFTP server instead of dnsmasq, specify its IP address after the boot-loader path, for example:
|
||||
|
||||
dhcp-boot=pxelinux/pxelinux.0,10.0.0.11
|
||||
|
||||
enable-tftp
|
||||
|
||||
Enable the TFTP service provided by dnsmasq.
|
||||
tftp-root=/var/lib/tftpboot
|
||||
|
||||
Specify the root directory for files served by TFTP. To prevent clients from accessing any file on the host, dnsmasq rejects requests that specify .. as a path element.
|
||||
|
||||
If you configure dnsmasq to provide the TFTP service:
|
||||
|
||||
Create the TFTP server directories, for example:
|
||||
|
||||
# mkdir -p /var/lib/tftpboot/pxelinux/pxelinux.cfg
|
||||
|
||||
Copy the installation kernel and ram-disk image files to the TFTP server directory hierarchy, for example:
|
||||
|
||||
# wget http://10.0.0.11/OSimage/OL6.6/isolinux/vmlinuz \
|
||||
-O /var/lib/tftpboot/pxelinux/vmlinuz
|
||||
# wget http://10.0.0.11/OSimage/OL6.6/isolinux/initrd.img \
|
||||
-O /var/lib/tftpboot/pxelinux/initrd.img
|
||||
|
||||
This example uses HTTP to obtain the files from an installation server.
|
||||
|
||||
If you want to support BIOS-based PXE clients, install the syslinux package and copy the pxelinux.0 boot loader to the TFTP server directory hierarchy.
|
||||
|
||||
# yum install syslinux
|
||||
# cp /usr/share/syslinux/pxelinux.0 /var/lib/tftpboot/pxelinux/pxelinux.0
|
||||
|
||||
If you want to support UEFI-based PXE clients, copy the BOOTX64.efi boot loader and splash image files to the TFTP server directory hierarchy, for example:
|
||||
|
||||
# wget http://10.0.0.11/OSimage/OL6.6/EFI/BOOT/BOOTX64.efi \
|
||||
-O /var/lib/tftpboot/efi/BOOTX64.efi
|
||||
# wget http://10.0.0.11/OSimage/OL6.6/EFI/BOOT/splash.xpm.gz \
|
||||
-O /var/lib/tftpboot/efi/splash.xpm.gz
|
||||
|
||||
Create the default boot loader configuration file, for example efi/efidefault or pxelinux/pxelinux.cfg/default.
|
||||
|
||||
For more information, see Section 1.4.9, “About Boot-Loader Configuration Files”.
|
||||
|
||||
[line-through]#If SELinux is enabled in enforcing mode on your system, use the semanage command to define the default file type of the TFTP server directory hierarchy as tftpdir_t and then use the restorecon command to apply the file type to the entire directory hierarchy, for example:#
|
||||
|
||||
[line-through]#/usr/sbin/semanage fcontext -a -t tftpdir_t "/var/lib/tftpboot(/.*)?"
|
||||
#/sbin/restorecon -R -v /var/lib/tftpboot#
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
If you make any changes to /etc/dnsmasq.conf, restart the dnsmasq service. You do not need to restart the service if you change the content of boot loader configuration files.
|
||||
|
||||
|
||||
|
||||
For information about configuring and using kickstart to perform automated installation, see Chapter 3, Installing Oracle Linux by Using Kickstart. (https://docs.oracle.com/cd/E37670_01/E41137/html/ol_kickstart.html)
|
||||
|
|
@ -1,8 +1,8 @@
|
|||
= Setting up dnsmasq - a lightweight DHCP and DNS server
|
||||
Peter Boy; Emmmanuel Seyman
|
||||
= Setting up dnsmasq - a lightweight DHCP, DNS, and TFTP server
|
||||
Peter Boy; Emmmanuel Seyman, Jan Kuparinen; Rowan Puttergill
|
||||
:page-authors: {author}, {author_2}
|
||||
:revnumber: F35-F44
|
||||
:revdate: 2026-05-11
|
||||
:revdate: 2026-07-01
|
||||
// :revremark: a new beginning
|
||||
:page-aliases: sysadmin-dnsmasq.adoc
|
||||
|
||||
|
|
@ -20,6 +20,8 @@ By default, Fedora Server uses dnsmasq to provide local DNS and DHCP services fo
|
|||
|
||||
The DHCP component provides dynamic DNS for a DHCP-assigned IP address, offering a temporary DNS entry for the device's hostname. It also supports static hostnames. Another common use case is to provide DHCP for a public subdomain, while an official public DNS server provides name resolution for the subdomain. Devices with such an address cannot, of course, be found via DNS. These addresses are primarily used for initial system installation, network-supported booting (PXE), and for dynamically assigning a specific IP address to machines identified by their MAC address. Another capability is providing a DNS caching service. However, since release 33, Fedora has used systemd-resolved as the DNS client, which includes versatile caching. Therefore, dnsmasq is no longer required for this purpose.
|
||||
|
||||
Dnsmasq can also provide a TFTP service that can be used to support PXE boot environments, most often used for remote system installation across a network.
|
||||
|
||||
Each dnsmasq component is optional. A system can use the DHCP component alone, the DNS component alone, the DHCP caching component alone, or any combination of these. Each component is configured separately.
|
||||
|
||||
The target is a small to medium-sized subnet. Typically, a server performs this task as an additional responsibility, alongside its main duties. It is practically impossible to determine the upper limit with any degree of accuracy. However, as a rule of thumb, dnsmasq can handle over 100 machines with ease. Significantly larger networks require better management and structuring capabilities. In this case, Kea, the ISC DHCP Server would be a more suitable choice.
|
||||
|
|
@ -37,7 +39,7 @@ You should get something like
|
|||
+
|
||||
[source,console]
|
||||
----
|
||||
# firewall-cmd --get-active-zones
|
||||
$ firewall-cmd --get-active-zones
|
||||
FedoraServer (default)
|
||||
interfaces: <IF01> ...
|
||||
<MY_ZONE>
|
||||
|
|
@ -48,8 +50,8 @@ Fix the zone assignments if necessary
|
|||
+
|
||||
[source,console]
|
||||
----
|
||||
# firewall-cmd --permanent --zone=<zone_name> --change-interface=<interface_name>
|
||||
# firewall-cmd --reload
|
||||
$ sudo firewall-cmd --permanent --zone=<zone_name> --change-interface=<interface_name>
|
||||
$ sudo firewall-cmd --reload
|
||||
----
|
||||
|
||||
* **Check auto forwarding**
|
||||
|
|
@ -58,8 +60,8 @@ The system should automatically forward between the interfaces. Check the forwar
|
|||
+
|
||||
[source,console]
|
||||
----
|
||||
# cat /proc/sys/net/ipv4/ip_forward
|
||||
# cat /proc/sys/net/ipv6/conf/default/forwarding
|
||||
$ cat /proc/sys/net/ipv4/ip_forward
|
||||
$ cat /proc/sys/net/ipv6/conf/default/forwarding
|
||||
----
|
||||
+
|
||||
In both cases a value of 1 indicates an active forwarding.
|
||||
|
|
@ -68,25 +70,26 @@ Otherwise, enable it immediately and configure it permanently.
|
|||
+
|
||||
[source,console]
|
||||
----
|
||||
# echo 1 > /proc/sys/net/ipv4/ip_forward
|
||||
# echo 1 > /proc/sys/net/ipv6/conf/all/forwarding
|
||||
$ echo 1 | sudo tee /proc/sys/net/ipv4/ip_forward
|
||||
$ echo 1 | sudo tee /proc/sys/net/ipv6/conf/all/forwarding
|
||||
|
||||
# vim /etc/sysctl.d/50-enable-forwarding.conf
|
||||
$ sudo tee /etc/sysctl.d/50-enable-forwarding.conf << 'EOF'
|
||||
# local customizations
|
||||
#
|
||||
# enable forwarding for dual stack
|
||||
net.ipv4.ip_forward=1
|
||||
net.ipv6.conf.all.forwarding=1
|
||||
EOF
|
||||
----
|
||||
|
||||
|
||||
== Installation
|
||||
The NetworkManager dnsmasq plugin included by default provides a basic configuration skeleton, but does not install the dnsmasq package. Thus, it avoids to uselessly occupy space and to introduce a superfluous and unused binary in case dnsmasq is not going to be in use on the particular server.
|
||||
The NetworkManager dnsmasq plugin included by default provides a basic configuration skeleton, but does not install the dnsmasq package. Thus, it avoids to uselessly occupy space and to introduce a superfluous and unused binary in case dnsmasq is not going to be in use on the particular server.
|
||||
|
||||
In case dnsmasq is not already installed
|
||||
[source,console]
|
||||
----
|
||||
# dnf install dnsmasq
|
||||
$ sudo dnf install dnsmasq
|
||||
----
|
||||
|
||||
[IMPORTANT]
|
||||
|
|
@ -113,119 +116,125 @@ The example here uses 2 interfaces, an external public interface enp1s0 (public.
|
|||
+
|
||||
[source,console]
|
||||
----
|
||||
# vim /etc/NetworkManager/conf.d/00-use-dnsmasq.conf
|
||||
|
||||
# /etc/NetworkManager/conf.d/00-use-dnsmasq.conf
|
||||
# This enables the dnsmasq plugin.
|
||||
[main]
|
||||
dns=dnsmasq
|
||||
$ sudo tee /etc/NetworkManager/conf.d/00-use-dnsmasq.conf << 'EOF'
|
||||
# /etc/NetworkManager/conf.d/00-use-dnsmasq.conf
|
||||
# This enables the dnsmasq plugin.
|
||||
[main]
|
||||
dns=dnsmasq
|
||||
EOF
|
||||
----
|
||||
|
||||
2. **Configuration of the name resolution (DNS) for the internal private network (internal.lan)**
|
||||
+
|
||||
[source,console]
|
||||
----
|
||||
# vim /etc/NetworkManager/dnsmasq.d/01-DNS-<INTERNAL>.conf
|
||||
|
||||
$ sudo tee /etc/NetworkManager/dnsmasq.d/01-DNS-<INTERNAL>.conf << 'EOF'
|
||||
# /etc/NetworkManager/dnsmasq.d/01-DNS-<INTERNAL>.conf
|
||||
# This file sets up DNS for the private local net domain '<INTERNAL>.lan'
|
||||
local=/<INTERNAL>.lan/
|
||||
# file where to find the list of IP - hostname mapping
|
||||
addn-hosts=/etc/dnsmasq-<INTERNAL>.hosts
|
||||
|
||||
domain-needed
|
||||
bogus-priv
|
||||
domain-needed
|
||||
bogus-priv
|
||||
|
||||
# Automatically add <domain> to simple names in a hosts-file.
|
||||
expand-hosts
|
||||
# Automatically add <domain> to simple names in a hosts-file.
|
||||
expand-hosts
|
||||
|
||||
# interfaces to listen on
|
||||
interface=lo
|
||||
interface=<ENPxyz>
|
||||
# in case of a bridge don't use the attached server virtual ethernet interface here!
|
||||
# interfaces to listen on
|
||||
interface=lo
|
||||
interface=<ENPxyz>
|
||||
# in case of a bridge don't use the attached server virtual ethernet interface here!
|
||||
|
||||
# Upstream public net DNS server (max.three)
|
||||
no-poll
|
||||
server=<uuu.vv.xx.yy>
|
||||
server=<www.vv.xx.zz>
|
||||
server=<2001:www:xxx:yyy::zz>
|
||||
# Upstream public net DNS server (max.three)
|
||||
no-poll
|
||||
server=<uuu.vv.xx.yy>
|
||||
server=<www.vv.xx.zz>
|
||||
server=<2001:www:xxx:yyy::zz>
|
||||
EOF
|
||||
----
|
||||
+
|
||||
Provide an empty host file
|
||||
+
|
||||
[source,console]
|
||||
----
|
||||
# touch /etc/dnsmasq-<INTERNAL>.hosts
|
||||
$ sudo touch /etc/dnsmasq-<INTERNAL>.hosts
|
||||
----
|
||||
|
||||
3. **Configuration of the DHCP service for the internal private network (<INTERNAL>.lan)**
|
||||
+
|
||||
[source,console]
|
||||
[source, console]
|
||||
----
|
||||
# vim /etc/NetworkManager/dnsmasq.d/02-DHCP-<INTERNAL>.conf
|
||||
# etc/NetworkManager/dnsmasq.d/02-DHCP-<INTERNAL>.conf
|
||||
# This file sets up DHCP for the private local net domain '<INTERNAL>.lan'
|
||||
$ sudo tee /etc/NetworkManager/dnsmasq.d/02-DHCP-<INTERNAL>.conf << 'EOF'
|
||||
# etc/NetworkManager/dnsmasq.d/02-DHCP-<INTERNAL>.conf
|
||||
# This file sets up DHCP for the private local net domain '<INTERNAL>.lan'
|
||||
|
||||
# The domain the DHCP part of dnsmasq is responsible for:
|
||||
domain=<INTERNAL>.lan,<uuu.vv.xx.y/24>,local
|
||||
# The domain the DHCP part of dnsmasq is responsible for:
|
||||
domain=<INTERNAL>.lan,<uuu.vv.xx.y/24>,local
|
||||
|
||||
# interfaces to listen on (redundant, same as for DNS)
|
||||
interface=<ENPxyz>
|
||||
# interfaces to listen on (redundant, same as for DNS)
|
||||
interface=<ENPxyz>
|
||||
|
||||
# general DHCP stuff (options, see RFC 2132)
|
||||
# 1: subnet masq
|
||||
# 3: default router
|
||||
# 6: DNS server
|
||||
# 12: hostname
|
||||
# 15: DNS domain (unneeded with option 'domain')
|
||||
# 28: broadcast address
|
||||
# general DHCP stuff (options, see RFC 2132)
|
||||
# 1: subnet masq
|
||||
# 3: default router
|
||||
# 6: DNS server
|
||||
# 12: hostname
|
||||
# 15: DNS domain (unneeded with option 'domain')
|
||||
# 28: broadcast address
|
||||
|
||||
dhcp-authoritative
|
||||
dhcp-option=1,<255.255.255.24>
|
||||
dhcp-option=3,<www.xxx.yy.zz>
|
||||
dhcp-option=6,<www.xx.yy.z>
|
||||
dhcp-authoritative
|
||||
dhcp-option=1,<255.255.255.24>
|
||||
dhcp-option=3,<www.xxx.yy.zz>
|
||||
dhcp-option=6,<www.xx.yy.z>
|
||||
|
||||
# Assign fixed IP addresses based on MAC address
|
||||
# dhcp-host=00:1a:64:ce:89:4a,NAME01,www.xx.yy.zz,infinite
|
||||
# dhcp-host=52:54:00:42:6a:43,NAME02,www.xx.yy.zz,infinite
|
||||
# Assign fixed IP addresses based on MAC address
|
||||
# dhcp-host=00:1a:64:ce:89:4a,NAME01,www.xx.yy.zz,infinite
|
||||
# dhcp-host=52:54:00:42:6a:43,NAME02,www.xx.yy.zz,infinite
|
||||
|
||||
# Assign dynamically IP addresses to interface to listen on
|
||||
# Range for distributed addresses, tagged <int> for further references
|
||||
dhcp-range=tag:<ENPxyz>,<vvv.ww.xx.y,vvv.ww.xx.z>,24h
|
||||
# Assign dynamically IP addresses to interface to listen on
|
||||
# Range for distributed addresses, tagged <int> for further references
|
||||
dhcp-range=tag:<ENPxyz>,<vvv.ww.xx.y,vvv.ww.xx.z>,24h
|
||||
EOF
|
||||
----
|
||||
+ The example shows the binding of the network interface and then sets the different DHCP responses for various client request options.
|
||||
+ The subnet mask (dhcp-option=1) is set to <255.255.255.24>, the default router or gateway (dhcp-option=3) is set to <www.xxx.yy.zz>, and the DNS server (dhcp-option=6) is set to <www.xx.yy.z>. Substitute values appropriate to your network.
|
||||
+ In this example, no permanent or fixed IP addresses are assigned, but examples are provided as commented lines, so that you can see how to add an entry to assign a particular IP address to a host based on it's MAC address.
|
||||
+ The example enables a DHCP range within the network and assigns hosts IP addresses from <vvv.ww.xx.y> to <vvv.ww.xx.z> with leases lasting for 24 hours.
|
||||
|
||||
4. **Configuration of the DHCP service for the public network (<PUBLIC.TLD>)**
|
||||
+
|
||||
[source,console]
|
||||
----
|
||||
# vim /etc/NetworkManager/dnsmasq.d/03-DHCP-<PUBLIC>.conf
|
||||
# etc/NetworkManager/dnsmasq.d/03-DHCP-<PUBLIC>.conf
|
||||
# This file sets up DNCP for the public '<PUBLIC.TLD>' domain interface
|
||||
$ sudo tee /etc/NetworkManager/dnsmasq.d/03-DHCP-<PUBLIC>.conf << 'EOF'
|
||||
# etc/NetworkManager/dnsmasq.d/03-DHCP-<PUBLIC>.conf
|
||||
# This file sets up DHCP for the public '<PUBLIC.TLD>' domain interface
|
||||
|
||||
# The domain the DHCP part of dnsmasq is responsible for:
|
||||
domain=<PUBLIC.TLD>,<uuu.vv.ww.xx/24>
|
||||
# The domain the DHCP part of dnsmasq is responsible for:
|
||||
domain=<PUBLIC.TLD>,<uuu.vv.ww.xx/24>
|
||||
|
||||
# the public interfaces to listen on
|
||||
interface=<ENPuvw>
|
||||
# the public interfaces to listen on
|
||||
interface=<ENPuvw>
|
||||
|
||||
# general DHCP stuff (options, see RFC 2132)
|
||||
# 1: subnet masq
|
||||
# 3: default router
|
||||
# 6: DNS server
|
||||
# 12: hostname
|
||||
# 15: DNS domain (unneeded with option 'domain')
|
||||
# 28: broadcast address
|
||||
# general DHCP stuff (options, see RFC 2132)
|
||||
# 1: subnet masq
|
||||
# 3: default router
|
||||
# 6: DNS server
|
||||
# 12: hostname
|
||||
# 15: DNS domain (unneeded with option 'domain')
|
||||
# 28: broadcast address
|
||||
|
||||
##dhcp-authoritative
|
||||
## we just send the bare minimum, e.g. no DNS server
|
||||
##dhcp-option=1,<255.255.255.0>
|
||||
dhcp-option=tag:<ENPuvw>,option=router,<uuu.vv.ww.zz>
|
||||
##dhcp-authoritative
|
||||
## we just send the bare minimum, e.g. no DNS server
|
||||
##dhcp-option=1,<255.255.255.0>
|
||||
dhcp-option=tag:<ENPuvw>,option=router,<uuu.vv.ww.zz>
|
||||
|
||||
# Assign fixed IP addresses based on MAC address
|
||||
# dhcp-host=00:1a:64:ce:89:4a,thootes,10.10.10.50,infinite
|
||||
# dhcp-host=52:54:00:42:6a:43,apollon,10.10.10.51,infinite
|
||||
# Assign dynamically IP addresses to interface to listen on
|
||||
# Range for distributed addresses, tagged <int> for further references dhcp-range=tag:<ENPuvw>,<uuu.vvv.w.x,uuu.vvv.w.y6,1h
|
||||
# Assign fixed IP addresses based on MAC address
|
||||
# dhcp-host=00:1a:64:ce:89:4a,thootes,10.10.10.50,infinite
|
||||
# dhcp-host=52:54:00:42:6a:43,apollon,10.10.10.51,infinite
|
||||
# Assign dynamically IP addresses to interface to listen on
|
||||
# Range for distributed addresses, tagged <int> for further references dhcp-range=tag:<ENPuvw>,<uuu.vvv.w.x,uuu.vvv.w.y6,1h
|
||||
EOF
|
||||
----
|
||||
+
|
||||
There is no DNS configuration for the external interface following, assuming that a official public DNS server is used to resolve all public facing interfaces of the domain public.tld.
|
||||
|
|
@ -234,28 +243,28 @@ There is no DNS configuration for the external interface following, assuming tha
|
|||
+
|
||||
[source,console]
|
||||
----
|
||||
# dnsmasq --test
|
||||
$ dnsmasq --test
|
||||
----
|
||||
|
||||
6. **Adjusting the firewall**
|
||||
+
|
||||
Allow ports for DHCP and DNS (53) service on the public interface.
|
||||
Allow ports for DHCP (UDP port 67) and DNS (TCP port 53) service on the public interface. If the system is running firewalld, you can configure these services as follows:
|
||||
+
|
||||
[source,console]
|
||||
----
|
||||
# firewall-cmd --get-services
|
||||
# firewall-cmd --zone=<YOUR_ZONE> --permanent --add-service=dhcp
|
||||
# firewall-cmd --zone=<YOUR_ZONE> --permanent --add-service=dns
|
||||
# firewall-cmd --reload
|
||||
# firewall-cmd --list-all --zone=<YOUR_ZONE>
|
||||
$ firewall-cmd --get-services
|
||||
$ sudo firewall-cmd --zone=<YOUR_ZONE> --permanent --add-service=dhcp
|
||||
$ sudo firewall-cmd --zone=<YOUR_ZONE> --permanent --add-service=dns
|
||||
$ sudo firewall-cmd --reload
|
||||
$ firewall-cmd --list-all --zone=<YOUR_ZONE>
|
||||
----
|
||||
|
||||
7. **Restart NetworkManager to start dnsmasq**
|
||||
+
|
||||
[source,console]
|
||||
----
|
||||
# systemctl restart NetworkManager
|
||||
# ps -ef | grep dnsmasq
|
||||
$ sudo systemctl restart NetworkManager
|
||||
$ ps -ef | grep dnsmasq
|
||||
dnsmasq 2114 2072 0 08:33 ? 00:00:00 /usr/sbin/dnsmasq --no-resolv ...
|
||||
----
|
||||
+
|
||||
|
|
@ -266,8 +275,8 @@ command above.
|
|||
+
|
||||
[source,console]
|
||||
----
|
||||
# systemctl restart systemd-resolved
|
||||
# resolvectl status
|
||||
$ sudo systemctl restart systemd-resolved
|
||||
$ resolvectl status
|
||||
----
|
||||
+
|
||||
The systemd-resolved should recognize the dnsmasq nameserver attached to interfaces as configured.
|
||||
|
|
@ -278,22 +287,21 @@ a. Test DHCP in the public using a machine without IP address
|
|||
+
|
||||
[source,console]
|
||||
----
|
||||
# ip a # no IPv4 address associated with interface
|
||||
# dhclient -4 -1 -v eth0
|
||||
# ip a # expect new IPv4 address associated with interface
|
||||
# dhclient -4 -1 -r -v eth0 # expected: no IPv4 again
|
||||
# ip a # expect no IPv4 address associated with interface again
|
||||
$ ip a # no IPv4 address associated with interface
|
||||
$ sudo dhclient -4 -1 -v eth0
|
||||
$ ip a # expect new IPv4 address associated with interface
|
||||
$ sudo dhclient -4 -1 -r -v eth0 # expected: no IPv4 again
|
||||
$ ip a # expect no IPv4 address associated with interface again
|
||||
----
|
||||
b. Try on an other server
|
||||
b. Validate that a DNS lookup for the system works correctly on another server, by running any of the following:
|
||||
+
|
||||
[source,console]
|
||||
----
|
||||
# dig app1 @10.10.10.1
|
||||
# nslookup app1 10.10.10.1
|
||||
# dhclient -v -d -s 10.10.10.1 enp6s0
|
||||
$ dig app1 @10.10.10.1
|
||||
$ nslookup app1 10.10.10.1
|
||||
$ dhclient -v -d -s 10.10.10.1 enp6s0
|
||||
----
|
||||
|
||||
|
||||
== Masquerading / NAT
|
||||
|
||||
If machines in the private network need access to the public network, add masquerading / NAT to the firewall.
|
||||
|
|
@ -302,15 +310,15 @@ If machines in the private network need access to the public network, add masque
|
|||
+
|
||||
[source,console]
|
||||
----
|
||||
# firewall-cmd --zone=FedoraServer --add-masquerade --permanent
|
||||
$ sudo firewall-cmd --zone=FedoraServer --add-masquerade --permanent
|
||||
success
|
||||
# firewall-cmd --zone=trusted --add-masquerade --permanent
|
||||
$ sudo firewall-cmd --zone=trusted --add-masquerade --permanent
|
||||
success
|
||||
# firewall-cmd --reload
|
||||
$ sudo firewall-cmd --reload
|
||||
|
||||
# firewall-cmd --zone=FedoraServer --query-masquerade
|
||||
$ firewall-cmd --zone=FedoraServer --query-masquerade
|
||||
yes
|
||||
# firewall-cmd --zone=trusted --query-masquerade
|
||||
$ firewall-cmd --zone=trusted --query-masquerade
|
||||
yes
|
||||
----
|
||||
|
||||
|
|
@ -321,16 +329,16 @@ a. A commonly used way to accomplish this is to set 'rules' in the firewall conf
|
|||
+
|
||||
[source,console]
|
||||
----
|
||||
# firewall-cmd --get-active-zones
|
||||
$ firewall-cmd --get-active-zones
|
||||
FedoraServer
|
||||
interfaces: enp1s0
|
||||
trusted
|
||||
interfaces: vbr2s0 enp2s0
|
||||
# firewall-cmd --direct --add-rule ipv4 nat POSTROUTING 0 -o enp1s0 -j MASQUERADE
|
||||
$ sudo firewall-cmd --direct --add-rule ipv4 nat POSTROUTING 0 -o enp1s0 -j MASQUERADE
|
||||
success
|
||||
# firewall-cmd --direct --add-rule ipv4 filter FORWARD 0 -i vbr2s0 -o enp2s0 -j ACCEPT
|
||||
$ sudo firewall-cmd --direct --add-rule ipv4 filter FORWARD 0 -i vbr2s0 -o enp2s0 -j ACCEPT
|
||||
success
|
||||
# firewall-cmd --direct --add-rule ipv4 filter FORWARD 0 -i enp1s0 -o vbr2s0 -m state --state RELATED,ESTABLISHED -j ACCEPT
|
||||
$ sudo firewall-cmd --direct --add-rule ipv4 filter FORWARD 0 -i enp1s0 -o vbr2s0 -m state --state RELATED,ESTABLISHED -j ACCEPT
|
||||
success
|
||||
----
|
||||
|
||||
|
|
@ -338,20 +346,20 @@ b. Fedora's firewall daemon, however, offers with release 35 and beyond a more e
|
|||
+
|
||||
[source,console]
|
||||
----
|
||||
# firewall-cmd --get-active-zones
|
||||
$ firewall-cmd --get-active-zones
|
||||
FedoraServer
|
||||
interfaces: enp1s0
|
||||
trusted
|
||||
interfaces: vbr2s0 enp2s0
|
||||
# firewall-cmd --permanent --new-policy trustedToExt
|
||||
$ sudo firewall-cmd --permanent --new-policy trustedToExt
|
||||
success
|
||||
# firewall-cmd --permanent --policy trustedToExt --add-ingress-zone trusted
|
||||
$ sudo firewall-cmd --permanent --policy trustedToExt --add-ingress-zone trusted
|
||||
success
|
||||
# firewall-cmd --permanent --policy trustedToExt --add-egress-zone FedoraServer
|
||||
$ sudo firewall-cmd --permanent --policy trustedToExt --add-egress-zone FedoraServer
|
||||
success
|
||||
# firewall-cmd --permanent --policy trustedToExt --set-target ACCEPT
|
||||
$ sudo firewall-cmd --permanent --policy trustedToExt --set-target ACCEPT
|
||||
success
|
||||
# firewall-cmd --reload
|
||||
$ sudo firewall-cmd --reload
|
||||
success
|
||||
----
|
||||
+
|
||||
|
|
@ -367,14 +375,14 @@ We just add the name resolution (DNS) for the libvirt virtual network (libvirt.l
|
|||
|
||||
[source,console]
|
||||
----
|
||||
# vim /etc/NetworkManager/dnsmasq.d/30-DNS-libvirt.conf
|
||||
$ sudo tee /etc/NetworkManager/dnsmasq.d/30-DNS-libvirt.conf << 'EOF'
|
||||
# /etc/NetworkManager/dnsmasq.d/30-DNS-libvirt.conf
|
||||
|
||||
# /etc/NetworkManager/dnsmasq.d/30-DNS-libvirt.conf
|
||||
|
||||
# This file directs dnsmasq to forward any request to resolve
|
||||
# names under the .libvirt.lan domain to 192.168.122.1, the
|
||||
# local libvirt DNS server default address.
|
||||
server=/libvirt.lan/192.168.122.1
|
||||
# This file directs dnsmasq to forward any request to resolve
|
||||
# names under the .libvirt.lan domain to 192.168.122.1, the
|
||||
# local libvirt DNS server default address.
|
||||
server=/libvirt.lan/192.168.122.1
|
||||
EOF
|
||||
----
|
||||
|
||||
== Managing static DNS Entries
|
||||
|
|
@ -385,21 +393,153 @@ The format is the same as /etc/hosts .
|
|||
+
|
||||
[source,console]
|
||||
----
|
||||
# vim /etc/dnsmasq.hosts
|
||||
$ sudo vim /etc/dnsmasq.hosts
|
||||
----
|
||||
|
||||
2. Restart NetworkManager to read the modified file.
|
||||
+
|
||||
[source,console]
|
||||
----
|
||||
# systemctl restart NetworkManager
|
||||
$ sudo systemctl restart NetworkManager
|
||||
----
|
||||
|
||||
3. Test the modification
|
||||
+
|
||||
[source,console]
|
||||
----
|
||||
# nslookup {NAME}
|
||||
# nslookup {NAME}.example.lan
|
||||
$ sudo nslookup {NAME}
|
||||
$ sudo nslookup {NAME}.example.lan
|
||||
----
|
||||
|
||||
|
||||
== Configuring dnsmasq as a PXE service
|
||||
|
||||
Dnsmasq can be configured to act as a PXE service, by enabling the TFTP server and setting some dhcp-boot directives. In this example, the configuration is extended to provide a PXE service to enable network boot and to configure a Fedora installation over the network.
|
||||
|
||||
See: https://apuntesderootblog.wordpress.com/2020/09/04/pxe-server-in-fedora-with-dnsmasq/[PXE server in Fedora with dnsmasq]
|
||||
|
||||
1. Add a configuration entry to enable the TFTP service in within dnsmasq and to direct DHCP clients to the correct boot loader on the TFTP server:
|
||||
+
|
||||
[source, console]
|
||||
----
|
||||
$ sudo tee /etc/NetworkManager/dnsmasq.d/10-TFTP-example-lan.conf << 'EOF'
|
||||
# Enable TFTP server
|
||||
enable-tftp
|
||||
# dnsmasq serves files from this directory
|
||||
tftp-root=/var/lib/tftpboot
|
||||
|
||||
# Tell DHCP clients where to find the TFTP server and which file to load
|
||||
# Note that legacy BIOS clients use the syslinux boot files, while UEFI clients use
|
||||
# a TFTP Grub EFI binary instead.
|
||||
# We use a dhcp match directive to identify the client-arch in the DHCP request. See RFC 4578 2.1.
|
||||
# BIOS clients have a client-arch=0.
|
||||
# UEFI x86_64 clients have a client-arch=7|9.
|
||||
|
||||
# BIOS clients
|
||||
dhcp-match=set:bios,option:client-arch,0
|
||||
# dhcp-boot=<tag>,<filename>[,<server-name>,<server-ip>]
|
||||
dhcp-boot=tag:bios,pxelinux.0,,10.10.10.1
|
||||
|
||||
# UEFI x86_64 clients
|
||||
dhcp-match=set:efi-x86_64,option:client-arch,7
|
||||
dhcp-match=set:efi-x86_64,option:client-arch,9
|
||||
# dhcp-boot=<tag>,<filename>[,<server-name>,<server-ip>]
|
||||
dhcp-boot=tag:efi-x86_64,grub/grubx64.efi,,10.10.10.1
|
||||
|
||||
EOF
|
||||
----
|
||||
+Since systems using legacy BIOS firmware behave differently to systems using UEFI to handle PXE boot, we use DHCP matching to tag the request for the appropriate client architecture and then provide different DHCP boot instructions depending on the tag. The DHCP boot instructions describe the filename to serve for the given tag, and the server IP where the file can be found. The server IP should be changed to match the IP address of the interface connected to the local network on the dnsmasq host.
|
||||
|
||||
2. Enable access to the TFTP service (UDP port 69) in your firewall. If you're running firewalld, you can do this by running the following commands:
|
||||
+
|
||||
[source, console]
|
||||
----
|
||||
$ sudo firewall-cmd --zone=FedoraServer --permanent --add-service=tftp
|
||||
$ sudo firewall-cmd --reload
|
||||
----
|
||||
|
||||
|
||||
Edit /etc/dnsmasq.conf and configure entries for PXE clients and other systems on the network, for example:
|
||||
|
||||
interface=eth1
|
||||
dhcp-range=10.0.0.101,10.0.0.200,6h
|
||||
dhcp-host=80:00:27:c6:a1:16,10.0.0.253,svr1,infinite
|
||||
dhcp-boot=pxelinux/pxelinux.0
|
||||
enable-tftp
|
||||
tftp-root=/var/lib/tftpboot
|
||||
|
||||
The lines in the sample configuration file do the following:
|
||||
|
||||
interface=eth1
|
||||
|
||||
Listen for incoming client requests on interface eth1 only.
|
||||
dhcp-range=10.0.0.101,10.0.0.200,6h
|
||||
|
||||
Reserve a pool of generally available IP addresses in the range 10.0.0.101 through 10.0.0.200 on the 10.0.0/24 subnet with a six-hour lease.
|
||||
Note
|
||||
|
||||
A dhcp-range setting is required to enable the DHCP service provided by dnsmasq. If you want to configure static addresses but not an address pool, specify a static network address and the keywords static and infinite, for example:
|
||||
|
||||
dhcp-range=10.0.0.253,static,infinite
|
||||
|
||||
dhcp-host=80:00:27:c6:a1:16,10.0.0.253,svr1,infinite
|
||||
|
||||
Reserve the IP address 10.0.0.253 with infinite lease time for svr1, which is identified by the MAC address 08:00:27:c6:a1:16.
|
||||
dhcp-boot=pxelinux/pxelinux.0
|
||||
|
||||
Specify the location of the boot-loader file required by PXE clients. This example supports BIOS-based PXE clients. An entry that supports UEFI-based clients might take the following form:
|
||||
|
||||
dhcp-boot=efi/BOOTX64.efi
|
||||
|
||||
If you want to use a separate TFTP server instead of dnsmasq, specify its IP address after the boot-loader path, for example:
|
||||
|
||||
dhcp-boot=pxelinux/pxelinux.0,10.0.0.11
|
||||
|
||||
enable-tftp
|
||||
|
||||
Enable the TFTP service provided by dnsmasq.
|
||||
tftp-root=/var/lib/tftpboot
|
||||
|
||||
Specify the root directory for files served by TFTP. To prevent clients from accessing any file on the host, dnsmasq rejects requests that specify .. as a path element.
|
||||
|
||||
If you configure dnsmasq to provide the TFTP service:
|
||||
|
||||
Create the TFTP server directories, for example:
|
||||
|
||||
# mkdir -p /var/lib/tftpboot/pxelinux/pxelinux.cfg
|
||||
|
||||
Copy the installation kernel and ram-disk image files to the TFTP server directory hierarchy, for example:
|
||||
|
||||
# wget http://10.0.0.11/OSimage/OL6.6/isolinux/vmlinuz \
|
||||
-O /var/lib/tftpboot/pxelinux/vmlinuz
|
||||
# wget http://10.0.0.11/OSimage/OL6.6/isolinux/initrd.img \
|
||||
-O /var/lib/tftpboot/pxelinux/initrd.img
|
||||
|
||||
This example uses HTTP to obtain the files from an installation server.
|
||||
|
||||
If you want to support BIOS-based PXE clients, install the syslinux package and copy the pxelinux.0 boot loader to the TFTP server directory hierarchy.
|
||||
|
||||
# yum install syslinux
|
||||
# cp /usr/share/syslinux/pxelinux.0 /var/lib/tftpboot/pxelinux/pxelinux.0
|
||||
|
||||
If you want to support UEFI-based PXE clients, copy the BOOTX64.efi boot loader and splash image files to the TFTP server directory hierarchy, for example:
|
||||
|
||||
# wget http://10.0.0.11/OSimage/OL6.6/EFI/BOOT/BOOTX64.efi \
|
||||
-O /var/lib/tftpboot/efi/BOOTX64.efi
|
||||
# wget http://10.0.0.11/OSimage/OL6.6/EFI/BOOT/splash.xpm.gz \
|
||||
-O /var/lib/tftpboot/efi/splash.xpm.gz
|
||||
|
||||
Create the default boot loader configuration file, for example efi/efidefault or pxelinux/pxelinux.cfg/default.
|
||||
|
||||
For more information, see Section 1.4.9, “About Boot-Loader Configuration Files”.
|
||||
|
||||
[line-through]#If SELinux is enabled in enforcing mode on your system, use the semanage command to define the default file type of the TFTP server directory hierarchy as tftpdir_t and then use the restorecon command to apply the file type to the entire directory hierarchy, for example:#
|
||||
|
||||
[line-through]#/usr/sbin/semanage fcontext -a -t tftpdir_t "/var/lib/tftpboot(/.*)?"
|
||||
#/sbin/restorecon -R -v /var/lib/tftpboot#
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
If you make any changes to /etc/dnsmasq.conf, restart the dnsmasq service. You do not need to restart the service if you change the content of boot loader configuration files.
|
||||
|
|
|
|||
84
modules/ROOT/pages/installation/kickstart-anatomy.adoc
Normal file
84
modules/ROOT/pages/installation/kickstart-anatomy.adoc
Normal file
|
|
@ -0,0 +1,84 @@
|
|||
= The anatomy of Fedora Server kickstart files
|
||||
Peter Boy
|
||||
:page-authors: {author}
|
||||
:revnumber: F36-F37
|
||||
:revdate: n/a
|
||||
|
||||
|
||||
[abstract]
|
||||
We provide basic information about creating and using Kickstart files in Fedora Server. It includes dedicated links for detailed information about various specific topics.
|
||||
|
||||
|
||||
|
||||
[IMPORTANT]
|
||||
====
|
||||
**Status:** work in progress! Text is still raw and basically unedited yet.
|
||||
====
|
||||
|
||||
|
||||
|
||||
== Creating a Kickstart File
|
||||
|
||||
The Kickstart file itself is a plain text file, containing keywords listed
|
||||
//xref:appendixes/Kickstart_Syntax_Reference.adoc#appe-kickstart-syntax-reference
|
||||
[Kickstart Syntax Reference],
|
||||
the Kickstart Appendix of Anaconda reference guide, which serve as directions for the installation. Any text editor able to save files as ASCII text (such as [application]*Gedit* or [application]*vim* on Linux systems or [application]*Notepad* on Windows systems) can be used to create and edit Kickstart files.
|
||||
|
||||
The recommended approach to creating Kickstart files is to perform a manual installation on one system first. After the installation completes, all choices made during the installation are saved into a file named `anaconda-ks.cfg`, located in the `/root/` directory on the installed system. You can then copy this file, make any changes you need, and use the resulting configuration file in further installations.
|
||||
|
||||
When creating a Kickstart file, keep in mind the following:
|
||||
|
||||
* Lines starting with a pound sign (`#`) are treated as comments and are ignored.
|
||||
|
||||
* Sections must be specified *in order*. Items within the sections do not have to be in a specific order unless otherwise specified. The correct section order is:
|
||||
+
|
||||
** The command section which contains actual Kickstart commands and options as listed in the refernce guide.
|
||||
|
||||
// xref:appendixes/Kickstart_Syntax_Reference.adoc#appe-kickstart-syntax-reference[Kickstart Syntax Reference].
|
||||
Note that some commands, such as [command]#install#, are mandatory, but most commands are optional.
|
||||
+
|
||||
** The [command]#%packages# section which contains a list of packages and package groups to be installed. See Reference Guide for details.
|
||||
|
||||
// xref:appendixes/Kickstart_Syntax_Reference.adoc#sect-kickstart-packages[%packages (required) - Package Selection]
|
||||
|
||||
+
|
||||
** The [command]#%pre# and [command]#%post# sections, containing a pre-installation and post-installation scripts. These two sections can be in any order and are not mandatory. See
|
||||
//xref:appendixes/Kickstart_Syntax_Reference.adoc#sect-kickstart-preinstall[%pre (optional) - Pre-installation Script] and
|
||||
//xref:appendixes/Kickstart_Syntax_Reference.adoc#sect-kickstart-postinstall[%post (optional) - Post-installation Script]
|
||||
Refernce Guide for details.
|
||||
+
|
||||
[IMPORTANT]
|
||||
====
|
||||
The [command]#%packages#, [command]#%pre# and [command]#%post# sections must end with [command]#%end#, otherwise the installation program will refuse the Kickstart file. The main command section has no special ending statement.
|
||||
|
||||
====
|
||||
|
||||
* Omitting any required item results in the installation program prompting the user for an answer to the related item, just as the user would be prompted during a typical installation. Once the answer is given, the installation will continue. Note that if the system you are installing has no display, you will not be able to see the prompt, and the installation will appear to have failed.
|
||||
|
||||
|
||||
=== Verifying the Kickstart File
|
||||
|
||||
When creating or customizing your kickstart file, it is useful to verify that it is valid before attempting to use it in an installation. Fedora includes the [application]*ksvalidator* command line utility which can be used to do this. This tool is a part of the [package]*pykickstart* package. To install this package, execute the following command:
|
||||
|
||||
[subs="macros"]
|
||||
----
|
||||
# dnf install pykickstart
|
||||
----
|
||||
|
||||
After installing the package, you can validate a Kickstart file using the following command:
|
||||
|
||||
[subs="quotes, macros"]
|
||||
----
|
||||
$ [command]#ksvalidator _/path/to/kickstart.ks_#
|
||||
----
|
||||
|
||||
Replace _/path/to/kickstart.ks_ with the path to the Kickstart file you want to verify.
|
||||
|
||||
For more information about this tool, see the `ksvalidator(1)` man page.
|
||||
|
||||
[IMPORTANT]
|
||||
====
|
||||
|
||||
Keep in mind that the validation tool has its limitations. The Kickstart file can be very complicated; [application]*ksvalidator* can make sure the syntax is correct and that the file does not include removed options, but it cannot guarantee the installation will be successful. It also does not attempt to validate the [command]#%pre#, [command]#%post# and [command]#%packages# sections of the Kickstart file.
|
||||
|
||||
====
|
||||
282
modules/ROOT/pages/installation/pxe-network-installation.adoc
Normal file
282
modules/ROOT/pages/installation/pxe-network-installation.adoc
Normal file
|
|
@ -0,0 +1,282 @@
|
|||
= PXE Network Installation
|
||||
Peter Boy, Rowan Puttergill
|
||||
:page-authors: {author}
|
||||
:revnumber: F36-F44
|
||||
:revdate: 0000-00-00
|
||||
|
||||
|
||||
[abstract]
|
||||
Use the the _Preboot Execution Environment_ (PXE) to install Fedora across a network without the requirement to attach physical installation media to the target server. As the name indicates, the environment runs independent of any operating system, using the server's firmware, providing a facility to configure and control the entire boot process of a system by using resources available on the network.
|
||||
|
||||
|
||||
[IMPORTANT]
|
||||
====
|
||||
**Status:** work in progress. Text is still raw and unedited yet. No valid information to find here!
|
||||
====
|
||||
|
||||
|
||||
Preboot Execution Environment, or PXE, is a technology that allows computers to boot directly from resources provided over the network. There is no need to physically interact with the computer at all, and no physical installation media is required to perform an installation. PXE can be used in environments where you might need to control installation across a large number of machines, particularly where you don't have physical access to the machines or where you frequently perform fresh installations and don't want to keep creating new installation media as new releases become available. This method of controlling how systems boot can be used with both physical and virtual machines.
|
||||
|
||||
For PXE to work, target machines must be configured to perform a network boot as the first boot option. This is usually configured in the UEFI firmware when the machine is commissioned, but can be done at any point during the machine's life cycle. Once configured, at boot, the machine connects to a PXE server on the network and uses these resources to control how the system boots. If no PXE server responds, the boot process usually selects a local medium, such as the system hard disk.
|
||||
|
||||
Most ofen, the PXE server is configured to provide access to an installation ISO file, that the system can boot to begin an installation of the operating system. In close association with PXE boot, the Fedora Server installation boot process ends with Anaconda, the installation program. Anaconda can be configured to perform an unattended installation by using a kickstart configuration file, or can be configured to start a VNC service to allow for an interactive remote installation.
|
||||
|
||||
PXE boot configuration can be configured with global defaults, or can be configured to target specific systems on a network, by MAC address. This makes it possible to completely reinstall the operating system on any machine on the network by updating the PXE configuration and then rebooting the target machine.
|
||||
|
||||
PXE can also be used to change boot menu options, so you can control how a system boots remotely. So using PXE isn't only about controlling installation, but is an important component in network based systems administration.
|
||||
|
||||
While this documentation provides detail on configuring individual components for network based installation, we recommend using https://cobbler.github.io/[Cobbler] if you intend to scale this up to handle a large number of different network-based installation requirements. Cobbler can help to simplify configuration and makes it easier to manage installation ISOs and to configure boot options for machines on the network.
|
||||
|
||||
== How it works – a PXE installation overview
|
||||
|
||||
A PXE network installation relies on two server roles working together. Both can run on the same machine or on separate machines.
|
||||
|
||||
Network boot server::
|
||||
Provides DHCP (Dynamic Host Control Protocol) and TFTP (Trivial File Transfer Protocol) services. When a client powers on and requests a network boot, the DHCP service assigns it an IP address and tells it where to find its boot files. The TFTP service then delivers the bootloader and its configuration files to the client. The https://thekelleys.org.uk/dnsmasq/doc.html[Dnsmasq] server provides both services in a single lightweight daemon, that can be used in small to medium sized networks of up to a few hundred computers at maximum. Alternatively for large network deployments, use the https://www.isc.org/kea/[KEA DHCP] server, which manages host configuration within a backend database. In this case, a separate dedicated TFTP is also required, and can be installed using the [package]*tftp* package.
|
||||
|
||||
File server::
|
||||
Hosts the installation files: the kernel, initial RAM disk, package repository, and optionally a kickstart configuration file. These are served over NFS or HTTP after the bootloader has handed control to the Anaconda installer.
|
||||
|
||||
The sequence of events during a PXE installation is:
|
||||
|
||||
. The target machine powers on and its firmware (BIOS or UEFI) initiates a network boot.
|
||||
. The target machine client broadcasts a DHCP request. The DHCP server responds with an IP address and the location of the bootloader file on the TFTP server.
|
||||
. The client downloads the bootloader from the TFTP server and runs it. The bootloader presents a boot menu, or times out to a default entry.
|
||||
. The bootloader fetches the kernel (`vmlinuz`) and initial RAM disk (`initrd.img`) from the TFTP server and boots them. Kernel parameters in the boot menu entry tell Anaconda where to find the installation source and, optionally, a Kickstart file (usually hosted on the file server, and available over NFS or HTTP).
|
||||
. Anaconda starts, fetches packages from the configured repository (NFS, HTTP, or a public mirror), and performs the installation.
|
||||
. The target machine reboots into the newly installed operating system.
|
||||
|
||||
Whether a client uses BIOS or UEFI firmware affects which bootloader is used and how the TFTP server directs the client, but the overall sequence is the same. BIOS clients use `pxelinux` from the syslinux family; UEFI clients use GRUB2 with `shim` to support Secure Boot.
|
||||
|
||||
== Prerequisites
|
||||
|
||||
PXE-capable target machine::
|
||||
Most modern computers support network boot. Verify that target machines can network boot, and for unattended environments, configure their firmware to attempt a network boot before falling back to local storage.
|
||||
|
||||
DHCP and TFTP server::
|
||||
A network should have only one DHCP server. If your network already has one, coordinate with its administrator to add PXE boot and TFTP support, rather than deploying a second DHCP server.
|
||||
+
|
||||
* For small to medium-sized networks, https://thekelleys.org.uk/dnsmasq/doc.html[dnsmasq] provides DHCP and TFTP in a single daemon. See xref:administration/dnsmasq-pxeboot.adoc[Configuring dnsmasq for PXE boot and TFTP support].
|
||||
* For large networks, the https://www.isc.org/kea/[KEA DHCP] server manages leases in a database and scales better than dnsmasq. A separate dedicated TFTP is also required, and can be installed using the [package]*tftp* package.
|
||||
//See xref:services/kea-dhcp-server.adoc[KEA DHCP Server]. A separate xref:administration/tftp.adoc[dedicated TFTP server] will also be required.
|
||||
|
||||
File server::
|
||||
An NFS or HTTP server must be available to serve the installation kernel, initial RAM disk, package repository, and optionally a Kickstart file.
|
||||
|
||||
[NOTE]
|
||||
====
|
||||
Rather than configuring each component individually, Cobbler can automate DHCP, DNS, repository management, and Kickstart configuration from a single tool. This guide focuses on the lightweight dnsmasq approach.
|
||||
====
|
||||
|
||||
== Preparations
|
||||
|
||||
Bootloader::
|
||||
Because the job of booting an operating system is too complex for the pre-boot environment, a bootloader is used to load the kernel and related files. It also provides configuration information to the installer, and can offer a menu to select from different configurations.
|
||||
|
||||
Kernel and Initramfs::
|
||||
The kernel is the core of any Linux operating system, and the initramfs provides the kernel with required tools and resources. These files are also provided by tftp.
|
||||
|
||||
Package repository::
|
||||
A Fedora repository must be available for the installation. The example in this section uses the public Fedora mirrors as the repository source, but you can also use a repo on the local network provided by NFS, FTP, or HTTP. Repositories can be configured using the [option]#inst.repo=# boot option; see [Specifying the Installation Source] for details.
|
||||
//xref:advanced/Boot_Options.adoc#sect-boot-options-sources[Specifying the Installation Source] for details.
|
||||
|
||||
//A link to mirrormanager and some instructions to other guides too. All the elaboration on installation methods might be going to far, but we can ref. --Pete
|
||||
|
||||
== Configuring the PXE boot environment
|
||||
|
||||
[[pxe-uefi]]
|
||||
=== UEFI clients
|
||||
|
||||
[[pxe-uefi-bootloader]]
|
||||
==== Bootloader setup
|
||||
|
||||
. Install the [package]*shim-x64* and [package]*grub2-efi-x64* packages. If your server runs BIOS firmware, you *must install these packages to a temporary install root*. Installing them directly on a BIOS machine will attempt to configure the system for UEFI booting and cause problems.
|
||||
+
|
||||
[source, console]
|
||||
----
|
||||
$ sudo dnf install shim-x64 grub2-efi-x64 --installroot=/tmp/fedora --releasever 44
|
||||
----
|
||||
|
||||
. Create a directory for the bootloader files and copy the required files into it.
|
||||
+
|
||||
[source,console]
|
||||
----
|
||||
$ sudo mkdir -p /var/lib/tftpboot/uefi
|
||||
$ sudo cp /tmp/fedora/boot/efi/EFI/fedora/{shimx64.efi,grubx64.efi,MokManager.efi} /var/lib/tftpboot/uefi/
|
||||
----
|
||||
|
||||
[[pxe-uefi-menu]]
|
||||
==== Boot menu
|
||||
|
||||
Create a boot menu for UEFI clients at `/var/lib/tftpboot/uefi/grub.cfg`.
|
||||
|
||||
[source,]
|
||||
----
|
||||
function load_video {
|
||||
insmod efi_gop
|
||||
insmod efi_uga
|
||||
insmod video_bochs
|
||||
insmod video_cirrus
|
||||
insmod all_video
|
||||
}
|
||||
|
||||
load_video
|
||||
set gfxpayload=keep
|
||||
insmod gzio
|
||||
|
||||
menuentry 'Exit this grub' {
|
||||
exit
|
||||
}
|
||||
|
||||
menuentry 'Install Fedora 44 64-bit' --class fedora --class gnu-linux --class gnu --class os {
|
||||
linuxefi $fw_path/f44/vmlinuz ip=dhcp inst.repo=https://download.fedoraproject.org/pub/fedora/linux/releases/44/Server/x86_64/os/
|
||||
initrdefi $fw_path/f44/initrd.img
|
||||
}
|
||||
|
||||
menuentry 'Install Fedora 44 Server (Kickstart)' --class fedora --class gnu-linux --class gnu --class os {
|
||||
linuxefi $fw_path/f44/vmlinuz ip=dhcp inst.repo=https://download.fedoraproject.org/pub/fedora/linux/releases/44/Server/x86_64/os/ inst.ks=https://example.com/fedora/kickstarts/server.ks
|
||||
initrdefi $fw_path/f44/initrd.img
|
||||
}
|
||||
|
||||
----
|
||||
|
||||
[[pxe-uefi-kernel]]
|
||||
==== Kernel and initrd
|
||||
|
||||
. Create a directory for the kernel and initrd files.
|
||||
+
|
||||
[source, console]
|
||||
----
|
||||
$ sudo mkdir -p /var/lib/tftpboot/f44
|
||||
----
|
||||
|
||||
. Download the kernel and initrd.
|
||||
+
|
||||
[source, console]
|
||||
----
|
||||
$ sudo wget https://download.fedoraproject.org/pub/fedora/linux/releases/44/Server/x86_64/os/images/pxeboot/vmlinuz -O /var/lib/tftpboot/f44/vmlinuz
|
||||
$ sudo wget https://download.fedoraproject.org/pub/fedora/linux/releases/44/Server/x86_64/os/images/pxeboot/initrd.img -O /var/lib/tftpboot/f44/initrd.img
|
||||
----
|
||||
|
||||
[[pxe-bios]]
|
||||
=== Legacy BIOS clients
|
||||
|
||||
[NOTE]
|
||||
====
|
||||
BIOS-based network boot is supported for older hardware but is considered legacy on modern Fedora systems, which target UEFI firmware. This section may be removed in a future version of this documentation.
|
||||
====
|
||||
|
||||
[[pxe-bios-bootloader]]
|
||||
==== Bootloader setup
|
||||
|
||||
. Install the [package]*syslinux* package.
|
||||
+
|
||||
[source, console]
|
||||
----
|
||||
$ sudo dnf install syslinux
|
||||
----
|
||||
|
||||
. Create a directory for the bootloader files and make them available there.
|
||||
+
|
||||
[source, console]
|
||||
----
|
||||
$ sudo mkdir -p /var/lib/tftpboot/pxelinux.cfg
|
||||
$ sudo cp /usr/share/syslinux/{pxelinux.0,menu.c32,vesamenu.c32,ldlinux.c32,libcom32.c32,libutil.c32} /var/lib/tftpboot/
|
||||
----
|
||||
|
||||
[[pxe-bios-menu]]
|
||||
==== Boot menu
|
||||
|
||||
Create a boot menu for BIOS clients at `/var/lib/tftpboot/pxelinux.cfg/default`.
|
||||
|
||||
[source,]
|
||||
----
|
||||
default vesamenu.c32
|
||||
prompt 0
|
||||
timeout 600
|
||||
|
||||
label local
|
||||
menu label Boot from ^local drive
|
||||
menu default
|
||||
localboot 0xffff
|
||||
|
||||
label linux
|
||||
menu label ^Install Fedora 44 64-bit
|
||||
kernel f44/vmlinuz
|
||||
append initrd=f44/initrd.img inst.repo=https://download.fedoraproject.org/pub/fedora/linux/releases/44/Server/x86_64/os/ ip=dhcp
|
||||
|
||||
label server
|
||||
menu label ^Install Fedora 44 Server (Kickstart)
|
||||
kernel f44/vmlinuz
|
||||
append initrd=f44/initrd.img inst.repo=https://download.fedoraproject.org/pub/fedora/linux/releases/44/Server/x86_64/os/ ip=dhcp inst.ks=https://example.com/fedora/kickstarts/server.ks
|
||||
----
|
||||
|
||||
[[pxe-bios-kernel]]
|
||||
==== Kernel and initrd
|
||||
|
||||
. Create a directory for the kernel and initrd files.
|
||||
+
|
||||
[source, console]
|
||||
----
|
||||
$ sudo mkdir -p /var/lib/tftpboot/f44
|
||||
----
|
||||
|
||||
. Download the kernel and initrd for the release that you intend to install.
|
||||
+
|
||||
[source, console]
|
||||
----
|
||||
$ sudo wget https://download.fedoraproject.org/pub/fedora/linux/releases/44/Server/x86_64/os/images/pxeboot/vmlinuz -O /var/lib/tftpboot/f44/vmlinuz
|
||||
$ sudo wget https://download.fedoraproject.org/pub/fedora/linux/releases/44/Server/x86_64/os/images/pxeboot/initrd.img -O /var/lib/tftpboot/f44/initrd.img
|
||||
----
|
||||
|
||||
[[pxe-repositories]]
|
||||
== Providing repositories
|
||||
|
||||
The examples in this section use the public Fedora mirrors as the package source. For faster installations, installing to many systems, or more isolated environments, you may wish to maintain a local repository.
|
||||
|
||||
Fedora Infrastructure maintains instructions for configuring a local mirror at link:++https://fedoraproject.org/wiki/Infrastructure/Mirroring++[]. The preferred method for providing repositories is via HTTP, and you can refer to the _Fedora System Administrator's Guide_ to configure `httpd`.
|
||||
|
||||
//[citetitle]_xref:fedora:system-administrators-guide:index.adoc[Fedora System Administrator's Guide]_ to configure `httpd`.
|
||||
|
||||
[[http-overview]]
|
||||
== HTTP Installation Overview
|
||||
|
||||
HTTP/HTTPS boot is a technology that allows computers to boot directly from resources provided over the network. When used in conjunction with HTTPS the authenticity of the server is validated, and the use of HTTP offers a more reliable transport mechanism than PXE's TFTP. Installing Fedora this way avoids creating install media and allows multiple computers to install simultaneously. Many current UEFI implementations, including the EDK2 based firmware shipping with fedora's virtualization solutions, can directly boot from HTTP sources. A UEFI boot entry may be manually added that specifies a HTTP source via firmware menus. Alternatively, a DHCP server may automatically provide the required HTTP path.
|
||||
|
||||
.Enrolling Certificates
|
||||
While many machines are capable of HTTPS boot as well as HTTP, they will frequently need to have a certificate authority (CA) enrolled first. The CA is used to validate the certificates presented by the HTTPS server. This may be accomplished by enrolling the appropriate files from the fedora provided ca-certificates for public mirrors or the local HTTPS boot server's certificate.
|
||||
|
||||
|
||||
[[https-dhcpd]]
|
||||
== DHCP Server Configuration for HTTP
|
||||
The installation and configuration of a DHCP server for HTTP boot is identical to its configuration for <<pxe-dhcpd,PXE>> except that we need to amend the option arch conditions for HTTP clients
|
||||
[source,]
|
||||
----
|
||||
...
|
||||
|
||||
if option arch = 00:07 {
|
||||
# x64 UEFI
|
||||
filename "uefi/shim64.efi";
|
||||
next-server 192.168.1.2;
|
||||
} else if option arch = 00:0b {
|
||||
# aarch64 UEFI
|
||||
filename "uefi/shimaa64.efi";
|
||||
server-name "192.168.1.2";
|
||||
} else if option arch = 00:13 {
|
||||
# aarch64 UEFI HTTP
|
||||
option vendor-class-identifier "HTTPClient";
|
||||
filename "http://download.fedoraproject.org/pub/fedora/linux/releases/44/Server/aarch64/os/images/boot.iso";
|
||||
} else if option arch = 00:10 {
|
||||
# x64 UEFI HTTP
|
||||
option vendor-class-identifier "HTTPClient";
|
||||
filename "http://download.fedoraproject.org/pub/fedora/linux/releases/44/Server/x86_64/os/images/boot.iso";
|
||||
} else {
|
||||
filename "pxelinux.0";
|
||||
next-server 192.168.1.2;
|
||||
}
|
||||
|
||||
...
|
||||
----
|
||||
|
||||
|
||||
|
||||
Loading…
Add table
Add a link
Reference in a new issue