Bug 187130

Summary:	regression in serving kickstart installs
Product:	[Fedora] Fedora	Reporter:	Alexandre Oliva <aoliva>
Component:	dhcp	Assignee:	Jason Vas Dias <jvdias>
Status:	CLOSED NOTABUG	QA Contact:
Severity:	medium	Docs Contact:
Priority:	medium
Version:	5
Target Milestone:	---
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2006-03-29 05:08:11 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Alexandre Oliva 2006-03-28 18:22:42 UTC

Description of problem:
dhcpd running on FC4 with a relatively simple configuration, that offers
per-client kickstart files, works just fine.  On FC5, the very same
configuration fails, and the client reports errors trying to reach
0.0.0.0:/path/file.ks, such that the kickstart install fails.

If I specify ks=nfs:<dhcpserver>:/path/file.ks on the client's boot prompt,
instead of just ks, then the install succeeds.

I don't have a next-server declaration in the server's dhcpd.conf, but the docs
say that implies the server's IP address is used instead.  I think I actually
tried to add next-server explicitly the other day, to no avail.

Version-Release number of selected component (if applicable):
dhcp-3.0.3-26

How reproducible:
Every time

Steps to Reproduce:
1.Set up a dhcp server such that it tells a client to use a certain file from
itself as the kickstart file
2.Boot up the installer on the client with `ks ksdevice=eth0Â´
  
Actual results:
No luck getting the kickstart file from host 0.0.0.0

Expected results:
Same as on FC4, where it worked just fine with the same configuration

Additional info:

Comment 1 Jason Vas Dias 2006-03-28 18:56:10 UTC

With the upstream ISC DHCP 3.0.3 release, they removed support for providing a
default siaddr setting of the dhcp server's address, as this contravenes the 
RFC, and prevents the use of explicit next-server or tftp-boot-server options 
on many clients.

To set the tftp-boot-server address, place this setting in /etc/dhcpd.conf in
the same scope as your boot clients:
    next-server = config-option dhcp-server-identifier;
or
    next-server XXX.XXX.XXX.XXX;
where XXX.XXX.XXX.XXX is the address of the dhcpd server.

If a valid next-server IP address is in scope, I've never seen a boot client
fail to get the "filename" with tftp - note also that for PXE tftp download of 
the boot file to work, these dhcpd.conf statements must be in scope:
   allow booting;
   allow bootp;
   next-server = config-option dhcp-server-identifier;
   filename "/linux-install/pxelinux.0";
and the /etc/xinetd.d/tftp service on the next-server must have 'disabled=no'
and 'server_args = -s /tftpboot' . Under these conditions, I've never seen
the tftp boot to fail - if it fails for you, please gather a tcpdump of dhcp
traffic on the server while a failed client session is in progress:
   # tcpdump -nl -vvv -i any -s 8192 port bootps or port bootpc \
     >/tmp/tcpdump.bootp.log 2>&1 &
and send me the /tmp/tcpdump.bootp.log file.

I guess I'll be updating a future version of dhcpd to set the siaddr field 
to its IP address by default, retaining legacy behavior, IFF:
  o no next-server option is specified in scope
  o no server-name option is specified in scope
  o no tftp-server-name option is specified in scope
  o no new 'no-default-next-server on;' option is specified in scope.
it is because setting the siaddr overrides ALL the other ways of specifying
the tftp server in many clients, which contravenes the RFC, that the ISC
stopped making the server set the siaddr by default.

Comment 2 Alexandre Oliva 2006-03-29 05:08:11 UTC

Aha!  When I re-read the docs, I thought I'd tried next-server and it didn't fix
it, but your explanation I recalled I'd actually tried server-name.  I've just
tried next-server and that restored the kickstart functionality I liked.  Thanks!