Bug 107946 - make anaconda use new pump dhcp vendor client stuff
Summary: make anaconda use new pump dhcp vendor client stuff
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: anaconda
Version: rawhide
Hardware: All
OS: Linux
low
medium
Target Milestone: ---
Assignee: Jeremy Katz
QA Contact: Mike McLean
URL:
Whiteboard: FC2
Depends On:
Blocks: 78843
TreeView+ depends on / blocked
 
Reported: 2003-10-24 19:59 UTC by Jeremy Katz
Modified: 2007-11-30 22:10 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Clone Of:
Environment:
Last Closed: 2005-08-15 17:03:05 UTC


Attachments (Terms of Use)
the patch (8.22 KB, patch)
2003-10-24 20:00 UTC, Jeremy Katz
no flags Details | Diff

Description Jeremy Katz 2003-10-24 19:59:21 UTC
anaconda should use the dhcp vendor client stuff as detailed (with
patches) in bu 78843.

Comment 1 Jeremy Katz 2003-10-24 20:00:51 UTC
Created attachment 95469 [details]
the patch

Comment 2 Chris Ricker 2003-10-24 20:12:37 UTC
One change I'd propose to the attached patch. Rather than defaulting to not
sending a VCI, I'd propose that a default VCI be sent (say, 'anaconda')

It'd be nice to only need to add ksclass in the cases when I'm doing something
unusual, but always to be able to match anaconda's requests in dhcpd (for
example, so that I don't have a default next-server specifying the location of
ks.cfg, since that blue-screens older Windows). It's a fairly minor nit, though,
and I can remember to always add ksclass if necessary

Comment 3 Dax Kelson 2003-10-24 20:35:53 UTC
I strongly second that. As an instructor I've done literally, 2000+, kickstart
installs. And a major failing is that there is no clean/work-free way to
kickstart multiple versions or RHL/FC/RHEL simulatenously from the same
kickstart server when there are kickstart syntax differences.

The default VCI should be:

Anaconda-X.Y(FC|EL)

Where X.Y should represent the version of Fedora/RHEL it is installing. This
should be sent by default.

The ISC dhcp server allows you to then act on that. For example:

if substring (option vendor-class-identifier , 0, 14 ) = "Anaconda-3.0EL" {
   filename "kickstart-RHELv3.ks";
} elsif substring (option vendor-class-identifier , 0, 14 ) = "Anaconda-1.0FC" {
   filename "kickstart-FedoraCore-v1.0.ks";
} elsif substring (option vendor-class-identifier , 0, 10 ) = "PXEClient:" {
   filename "eepro100.pxe" ;
} elsif substring (option vendor-class-identifier , 0, 4 ) = "MSFT" {
   option netbios-name-servers     10.100.0.254;
} else {
   stuff;
}


Comment 4 Dax Kelson 2003-10-24 20:36:56 UTC
Go ahead and allow ksclass to override the default however.

Comment 5 rudi 2003-10-25 00:45:09 UTC
I agree with the change proposed. Actually, I had already thought of doing it in
the next version of my patches, but this week I have been too busy with hardware
that doesn't want to work. I'll try during the weekend.

Another change that I had considered is letting the ID be overridden through the
GUI as well. 99.99% of users won't need it, though. I do not know if it's really
worth doing.

Comment 6 Jeremy Katz 2004-01-06 23:34:40 UTC
Added in CVS.  The default if not specified for use during the install
is just "anaconda" for simplicity's sake.

Comment 7 Dax Kelson 2004-01-07 00:23:40 UTC
Thanks for having there be a default. Excellent!

However, without the version in the default name, there is no
clean/work-free way to kickstart multiple versions or FC/RHEL
simulatenously from the same kickstart server when there are kickstart
syntax differences.

Can you make the default be something like:

anaconda-FC|RHEL-X.Y-ARCH

Examples:

anaconda-RHEL-4.0-ia64
anaconda-FC-2.0-amd64
anaconda-RHEL-4.0-i386

This way you can have one kickstart server handle stock clients "linux
ks" painlessly independent of version or architecture.

I'm not sure there is virture here in making the default simple for
simplicity's sake, since it doesn't effect those who don't use this
feature either way, and those who will use the feature are not
"simple" sys admins.

Comment 8 Rahul Sundaram 2005-08-15 16:51:00 UTC

Seems a sane enhancement to me. Jeremy?

Comment 9 Jeremy Katz 2005-08-15 17:03:05 UTC
There's nothing in the image to let us grab what the default would be now;
that's all controlled entirely by stage2, which is after we've done dhcp.


Note You need to log in before you can comment on or make changes to this bug.