Re: diskless system's limited dhcp support
Ross Boylan wrote: > On Sun, Sep 6, 2020 at 3:37 PM Dan Ritter wrote: > > > The usual way is: > > > > 1. DNS record tied to a static IP address > > 2. IP address handed out by DHCP server based on MAC address of > >the interface > > > > This is especially normal when the root is served by NFS, so PXE > > needs to figure out the right root to hand out -- PXE is > > governed by MAC address, and then you really want the kernel's > > conception of its IP address to remain the same. > > > I don't follow that last part. I thought PXE was irrelevant once the > system was up. And the IP address of the root fs is distinct from the IP > address of the client. You made me double-check my belief here. I thought that the kernel inherited the IP address from the PXE booter, but I was wrong; there's no mechanism for that. It's an artifact of my own setup, where individual MAC addresses are used to return specific IP addreses. I would still argue that this is a good practice, because it makes debugging easier, but it's not necessary. > > > bit of a hack. Also, I'd like the DNS entry for the system to appear > > only > > > while it is up, and without the client sending a host name that's harder. > > > > That requires a server that listens to a dynamic DNS protocol, > > and a dynamic DNS client on the client system. > > > My server is set for dynamic updates. Since ipconfig sets up the > interface, the usual dhcp client that manages such stuff doesn't come up. > > > Why would you care about the DNS name not being available when > > the machine isn't up? > > > Mostly because the machine might be up, but running a different OS > instance. This applies to non-diskless, non-PXE clients as well. So the > MAC address does not determine a unique system. PXE booting (and grub for > regular systems) provides a menu of possible systems from which to boot, so > I may not know which of them is running until someone makes a selection > from the menu. > > I've been shooting for using the same IP regardless of the OS, but maybe > that's inadvisable. OTOH, for PXE the machine gets an IP before the > selection is made. It depends on the semantics that you're assigning to names and IPs and MACs. IMHO, the physical hardware is important because if there's a problem, I need to know what piece of equipment I will have to walk over to and debug. -dsr-
Re: diskless system's limited dhcp support
On Sun, Sep 6, 2020 at 3:37 PM Dan Ritter wrote: > Ross Boylan wrote: > > I have a buster system with no disk, started by PXE boot and using NFS > root. > > It appears (details below) that dhcp setup is via ipconfig in one of the > > initrd scripts (configure_networking() in the "functions" script), with > > ipconfig coming from klibc. So fiddling with the settings in > dhclient.conf > > on the client has no effect, and ipconfig both sends and handles a > narrower > > range of information than dhclient. In particular, it doesn't send the > > host name (it actually can according to the docs, but the initrd scripts > > don't invoke it that way) and it seems to ignore (or at least not pass > on) > > some of the info, like the domain, that gets sent back. > > > > I would like, in particular, to have the client send the host name and > > respond to the usual parameters the server sends it, as well as to > > ntp-servers which I'd like to send. > > > > Any thoughts on whether my analysis is correct? On solutions? > > The usual way is: > > 1. DNS record tied to a static IP address > 2. IP address handed out by DHCP server based on MAC address of >the interface > This is especially normal when the root is served by NFS, so PXE > needs to figure out the right root to hand out -- PXE is > governed by MAC address, and then you really want the kernel's > conception of its IP address to remain the same. > I don't follow that last part. I thought PXE was irrelevant once the system was up. And the IP address of the root fs is distinct from the IP address of the client. > > bit of a hack. Also, I'd like the DNS entry for the system to appear > only > > while it is up, and without the client sending a host name that's harder. > > That requires a server that listens to a dynamic DNS protocol, > and a dynamic DNS client on the client system. > My server is set for dynamic updates. Since ipconfig sets up the interface, the usual dhcp client that manages such stuff doesn't come up. > > Why would you care about the DNS name not being available when > the machine isn't up? > Mostly because the machine might be up, but running a different OS instance. This applies to non-diskless, non-PXE clients as well. So the MAC address does not determine a unique system. PXE booting (and grub for regular systems) provides a menu of possible systems from which to boot, so I may not know which of them is running until someone makes a selection from the menu. I've been shooting for using the same IP regardless of the OS, but maybe that's inadvisable. OTOH, for PXE the machine gets an IP before the selection is made. Ross
Re: diskless system's limited dhcp support
Ross Boylan wrote: > I have a buster system with no disk, started by PXE boot and using NFS root. > It appears (details below) that dhcp setup is via ipconfig in one of the > initrd scripts (configure_networking() in the "functions" script), with > ipconfig coming from klibc. So fiddling with the settings in dhclient.conf > on the client has no effect, and ipconfig both sends and handles a narrower > range of information than dhclient. In particular, it doesn't send the > host name (it actually can according to the docs, but the initrd scripts > don't invoke it that way) and it seems to ignore (or at least not pass on) > some of the info, like the domain, that gets sent back. > > I would like, in particular, to have the client send the host name and > respond to the usual parameters the server sends it, as well as to > ntp-servers which I'd like to send. > > Any thoughts on whether my analysis is correct? On solutions? The usual way is: 1. DNS record tied to a static IP address 2. IP address handed out by DHCP server based on MAC address of the interface This is especially normal when the root is served by NFS, so PXE needs to figure out the right root to hand out -- PXE is governed by MAC address, and then you really want the kernel's conception of its IP address to remain the same. > bit of a hack. Also, I'd like the DNS entry for the system to appear only > while it is up, and without the client sending a host name that's harder. That requires a server that listens to a dynamic DNS protocol, and a dynamic DNS client on the client system. Why would you care about the DNS name not being available when the machine isn't up? -dsr-
diskless system's limited dhcp support
I have a buster system with no disk, started by PXE boot and using NFS root. It appears (details below) that dhcp setup is via ipconfig in one of the initrd scripts (configure_networking() in the "functions" script), with ipconfig coming from klibc. So fiddling with the settings in dhclient.conf on the client has no effect, and ipconfig both sends and handles a narrower range of information than dhclient. In particular, it doesn't send the host name (it actually can according to the docs, but the initrd scripts don't invoke it that way) and it seems to ignore (or at least not pass on) some of the info, like the domain, that gets sent back. I would like, in particular, to have the client send the host name and respond to the usual parameters the server sends it, as well as to ntp-servers which I'd like to send. Any thoughts on whether my analysis is correct? On solutions? I suppose since it's at a fixed IP and controlled by the server I could just set the parameters I want in the client image, but that seems like a bit of a hack. Also, I'd like the DNS entry for the system to appear only while it is up, and without the client sending a host name that's harder. BTW, I tried forcing dhclient to run by telling /etc/network/interfaces to run it for that interface unconditionally. The result was 2 distinct IP addresses for the same card (may have done that before I switched to a fixed IP). I realize there may be good reasons to disable dhclient with nfs root; I have no idea what would happen if the client IP were changed while the system was running. The client is assigned a fixed IP (outside of the pool) in the dhcpd.conf configuration. DETAILS Using wireshark on the server shows 2 sets of calls to DHCP from the client. I'll give times as minutes and seconds past the hour: 28:22 initial DHCP discover. The Vendor class identifier is "PXEClient:Arch"; I assume this is the BIOS of the client machine initiating netboot. This gets the IP and then pulls in the files that are part of the netboot via tftp. 28:41 second DHCP discover. Vendor class "Linux ipconfig". This asks for and gets the same IP as previously. The ipconfig docs say "Linux ipconfig" is its standard identifier, and the scripts do not override it. So I presume this is after control has been handed over to the initrd and it is running its scripts. The script's invocation of ipconfig is buried in a lot of conditional logic, but it seems that it is called. 28:45 first entry in kernel log for that boot. I expect the client and server clocks are pretty close, but I don't know that's true, especially this early in the boot. The client CMOS battery is pretty low, and is not great at preserving the time; however, this boot was immediately after I did a system restart (shutdown -r now) on the client. I believe 28:45 is immediately after the pivot from the initrd to the real system.
