Bug 107946 - make anaconda use new pump dhcp vendor client stuff
make anaconda use new pump dhcp vendor client stuff
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: anaconda (Show other bugs)
rawhide
All Linux
low Severity medium
: ---
: ---
Assigned To: Jeremy Katz
Mike McLean
FC2
: FutureFeature
Depends On:
Blocks: 78843
  Show dependency treegraph
 
Reported: 2003-10-24 15:59 EDT by Jeremy Katz
Modified: 2007-11-30 17:10 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-08-15 13:03:05 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


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

  None (edit)
Description Jeremy Katz 2003-10-24 15:59:21 EDT
anaconda should use the dhcp vendor client stuff as detailed (with
patches) in bu 78843.
Comment 1 Jeremy Katz 2003-10-24 16:00:51 EDT
Created attachment 95469 [details]
the patch
Comment 2 Chris Ricker 2003-10-24 16:12:37 EDT
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 16:35:53 EDT
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 16:36:56 EDT
Go ahead and allow ksclass to override the default however.
Comment 5 rudi 2003-10-24 20:45:09 EDT
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 18:34:40 EST
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-06 19:23:40 EST
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 12:51:00 EDT

Seems a sane enhancement to me. Jeremy?
Comment 9 Jeremy Katz 2005-08-15 13:03:05 EDT
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.