-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Jeremy Katz wrote:
Unfortunately, this would not be the desired behavior of other people. So as it stands, we're going to stick to requiring the kickstart config to be specified.
This typical RH response hightlights the fundamental flaw in Fedora and needs to change if this platform is going to have any relevance as the Linux user community's expectations evolve upward.
Community users are clearly indicating that they'd like a generalised installer as we all have many and varied uses for Linux - quite often outside the norm - RH's norm at least.
Why can't we consider adding another input parameter to the anaconda-runtime suite to package a default kickstart into an image. Most people won't use this and they will still enjoy the status quo.
Those of who would like this feature would love to contribute the code even - if only we could ...
Alan
P.S. I too very strongly support URLGrabber into anaconda!!!
On Wed, 2005-09-21 at 14:45 +1000, Alan Milligan wrote:
Jeremy Katz wrote:
Unfortunately, this would not be the desired behavior of other people. So as it stands, we're going to stick to requiring the kickstart config to be specified.
This typical RH response hightlights the fundamental flaw in Fedora and needs to change if this platform is going to have any relevance as the Linux user community's expectations evolve upward.
Huh? I think plenty of things are changing, but you can't just always change everything. Maybe it's just that it's 3 am and I really shouldn't reply to mail this late.
Community users are clearly indicating that they'd like a generalised installer as we all have many and varied uses for Linux - quite often outside the norm - RH's norm at least.
And I think anaconda goes a long way here. At the same time, some constraints have to be made around things. Otherwise, you end up with tons of options that are confusing, untested and fragile. So there's the ever-present trade-offs which must be made between flexibility and usability. One of the ways that we approach this is by making some things only available via kickstart. Another is by trying to improve the default user's install path so they don't have to deal as much with the things which are confusing (eg, partitioning).
Why can't we consider adding another input parameter to the anaconda-runtime suite to package a default kickstart into an image. Most people won't use this and they will still enjoy the status quo.
This is something entirely different, and I would be all for having a script available to embed a ks.cfg into a boot image. Those are the sorts of things that do provide benefit for the user who has a better idea of what they're doing. One downside, though, is discoverability. Hopefully, starting to have a more concrete location for people to start looking for information as well as adding their own tips and tricks will help[1]
Those of who would like this feature would love to contribute the code even - if only we could ...
Patches accepted[2] and I'd love to get more of them.
P.S. I too very strongly support URLGrabber into anaconda!!!
urlgrabber being used for the second stage only helps with a subset of things. Mostly it makes things easier for us as we get to deal with a consistent API instead of the inconsistency of urllib2. To be able to really take advantage of some of the nicer things like proxy support, some code will also need to be written for the loader.
Jeremy
[1] So I haven't really said much about http://fedoraproject.org/wiki/Anaconda here. At the moment, it includes a migration from the wiki which Alexander Rau set up as well as the start of some structure for more information. If you're interested in adding content, create a wiki user and ask for edit access and that should be able to be arranged [2] Just because they're welcomed doesn't mean that I'm going to just take anything -- I do tend to have comments on non-trivial patches just for style or to fit in better with future changes[3] [3] eg, the changes I suggested for the nfs mount options patch
Jeremy Katz wrote:
Why can't we consider adding another input parameter to the anaconda-runtime suite to package a default kickstart into an image. Most people won't use this and they will still enjoy the status quo.
This is something entirely different, and I would be all for having a script available to embed a ks.cfg into a boot image. Those are the sorts of things that do provide benefit for the user who has a better idea of what they're doing. One downside, though, is discoverability.
and that is precisely the question my suggestion addresses.
Another way is by use of zeroconf: mDNSclient code in Anaconda could seek out information about the environment.
I've been thinking some time about ways to reduce the configuration sysadmins must do in order to install. kickstart is good, way better than I thought when it was first introduced. Using PXE is good (though my experience until recently was with faulty boot roms).
Network installs of CD is good; a slight improvement would be for Anaconda to spit out the CD when it's not required (maybe optionally, %post could require it). Booting off a CD has the advantage that, once the CD is removed, the next boot will be off the installed system.
However, using kickstart off a CD requires a customised CD, a point I think can be overcome if my susggestion is adopted.
I've not yet tried installing off a USB device, but I expect it's pretty like using a boot CD.
Hopefully, starting to have a more concrete location for people to start looking for information as well as adding their own tips and tricks will help[1]
Those of who would like this feature would love to contribute the code even - if only we could ...
Patches accepted[2] and I'd love to get more of them.
P.S. I too very strongly support URLGrabber into anaconda!!!
urlgrabber being used for the second stage only helps with a subset of things. Mostly it makes things easier for us as we get to deal with a consistent API instead of the inconsistency of urllib2. To be able to really take advantage of some of the nicer things like proxy support, some code will also need to be written for the loader.
There are two ways one can use a proxy right now. You may recall I had problems with Taroon beta because Aanconda was inserting a broken host: header. I overcame it (after reporting the problem) by using an iptables rule to force relevant traffic into another box, and using Apache configured as a proxy. Transparent proxy worked fine, using Apache and not Squid.
Since then, I've had a better idea (I've had more time to think on it) and I did a network install of Fedora Core 2 using fedora.test.lan as my install server, and again, configured Apache as a proxy, getting stuff from a site Over East.
On Wed, Sep 21, 2005 at 04:19:08PM +0800, John Summerfied wrote:
Another way is by use of zeroconf: mDNSclient code in Anaconda could seek out information about the environment.
I don't like the idea of having to add more client code in the loader.
I've been thinking some time about ways to reduce the configuration sysadmins must do in order to install. kickstart is good, way better than I thought when it was first introduced. Using PXE is good (though my experience until recently was with faulty boot roms).
A natural extension of using DHCP and PXE to get to a kickstart install is to follow RFC2489 to get a DHCP option number assigned. This would give anaconda a reserved place to get the ks.cfg location from the DHCP server without overloading option 67 or the bootfile;
Cheers,
Matt
Please, _not_ off-list. Most offlist email to this address gets deleted unread.
Matt Wilson wrote:
On Wed, Sep 21, 2005 at 04:19:08PM +0800, John Summerfied wrote:
Another way is by use of zeroconf: mDNSclient code in Anaconda could seek out information about the environment.
I don't like the idea of having to add more client code in the loader.
One reason I didn't suggest it. I've been thinking about the problem and possible solutions of which Zeroconf is one, but I don't think it's the best.
I've been thinking some time about ways to reduce the configuration sysadmins must do in order to install. kickstart is good, way better than I thought when it was first introduced. Using PXE is good (though my experience until recently was with faulty boot roms).
A natural extension of using DHCP and PXE to get to a kickstart install is to follow RFC2489 to get a DHCP option number assigned. This would give anaconda a reserved place to get the ks.cfg location from the DHCP server without overloading option 67 or the bootfile;
That avoids possible confusion. Maybe better is this: option vendor-encapsulated-options string;
The vendor-encapsulated-options option can contain either a sin- gle vendor-specific value or one or more vendor-specific subop- tions.
which does not require special registration.
This could be useful too: option www-server. It "says" IP address, but ip-address can be expressed as a domain name.
On Thu, 2005-09-22 at 11:05 +0800, John Summerfied wrote:
A natural extension of using DHCP and PXE to get to a kickstart install is to follow RFC2489 to get a DHCP option number assigned. This would give anaconda a reserved place to get the ks.cfg location from the DHCP server without overloading option 67 or the bootfile;
That avoids possible confusion. Maybe better is this: option vendor-encapsulated-options string;
The vendor-encapsulated-options option can contain either a sin- gle vendor-specific value or one or more vendor-specific subop- tions.which does not require special registration.
That's fine, until somebody else decides they want to use the same string without knowing that anaconda will do something with it.
(I know it seems unlikely, but stranger things happen all the time.)
I wouldn't want to see this committed to the tree until it's been properly assigned. That's not to say I wouldn't be happy to review any patches to handle it.
Peter Jones wrote:
On Thu, 2005-09-22 at 11:05 +0800, John Summerfied wrote:
A natural extension of using DHCP and PXE to get to a kickstart install is to follow RFC2489 to get a DHCP option number assigned. This would give anaconda a reserved place to get the ks.cfg location from the DHCP server without overloading option 67 or the bootfile;
That avoids possible confusion. Maybe better is this: option vendor-encapsulated-options string;
The vendor-encapsulated-options option can contain either a sin- gle vendor-specific value or one or more vendor-specific subop- tions.which does not require special registration.
That's fine, until somebody else decides they want to use the same string without knowing that anaconda will do something with it.
(I know it seems unlikely, but stranger things happen all the time.)
If someone else claims to be anaconda, then all bets are off. Anaconda's interpretation _only_ applies in the particular circumstance that vendor-class-identifier is equal to (or contains if we want to differentiate between versions of anaconda) the string "anaconda."
It might be prudent to change that to "redhat-anaconda" to distinguish it from Progeny's version, Point Clark Network's version etc.
I wouldn't want to see this committed to the tree until it's been properly assigned. That's not to say I wouldn't be happy to review any patches to handle it.
The vendor-class-identifier field is provided for vendors to say "my rules apply." I don't see that this is a real problem.
On Fri, 2005-09-23 at 18:22 +0800, John Summerfied wrote:
The vendor-class-identifier field is provided for vendors to say "my rules apply." I don't see that this is a real problem.
You have no way of knowing that the DHCP server is actually using the VCI, though. It's perfectly valid to just ignore it and do nothing based on it
Jeremy
Jeremy Katz wrote:
On Fri, 2005-09-23 at 18:22 +0800, John Summerfied wrote:
The vendor-class-identifier field is provided for vendors to say "my rules apply." I don't see that this is a real problem.
You have no way of knowing that the DHCP server is actually using the VCI, though. It's perfectly valid to just ignore it and do nothing based on it
In the examples I have seen 1. Client writes VCI=<example-text> 2. Server writes VCI=<example-text> 3. Client ignores replies without VCI=<example-text>
What's the problem?
On Wed, 2005-09-21 at 16:20 -0400, Matt Wilson wrote:
On Wed, Sep 21, 2005 at 04:19:08PM +0800, John Summerfied wrote:
Another way is by use of zeroconf: mDNSclient code in Anaconda could seek out information about the environment.
I don't like the idea of having to add more client code in the loader.
I don't especially like it either, but eventually, mDNS (or something like it) is probably going to be wanted for things like finding local install servers. That's down the road a bit, though.
I've been thinking some time about ways to reduce the configuration sysadmins must do in order to install. kickstart is good, way better than I thought when it was first introduced. Using PXE is good (though my experience until recently was with faulty boot roms).
A natural extension of using DHCP and PXE to get to a kickstart install is to follow RFC2489 to get a DHCP option number assigned. This would give anaconda a reserved place to get the ks.cfg location from the DHCP server without overloading option 67 or the bootfile;
Yeah, this is probably the sanest approach for something like this. But given the lack of available ones, I'm not sure that "anaconda kickstart configs" will pass muster. We could go the hacky route of using one of the reserved/private fields[1] and then allow a way of overriding the # that's used for people that need a different one. That would also let us get something usable faster
Jeremy
[1] Sadly, it looks like this is what OF on Macs already do :-/
Jeremy Katz wrote:
Yeah, this is probably the sanest approach for something like this. But given the lack of available ones, I'm not sure that "anaconda kickstart configs" will pass muster. We could go the hacky route of using one of the reserved/private fields[1] and then allow a way of overriding the # that's used for people that need a different one. That would also let us get something usable faster
Jeremy
[1] Sadly, it looks like this is what OF on Macs already do :-/
I've not done an audit to see what Apple is actually using, but it does have some validly assigned.
However, since the OF boxes I have here now all set VCI= some Apple value, I don't see any problem. Apple's usage is valid only when VCI is set to Apple's values, whether sent by client or by server.
See my previous reply.
Jeremy Katz wrote:
On Wed, 2005-09-21 at 16:20 -0400, Matt Wilson wrote:
On Wed, Sep 21, 2005 at 04:19:08PM +0800, John Summerfied wrote:
Another way is by use of zeroconf: mDNSclient code in Anaconda could seek out information about the environment.
I don't like the idea of having to add more client code in the loader.
I don't especially like it either, but eventually, mDNS (or something like it) is probably going to be wanted for things like finding local install servers. That's down the road a bit, though.
I've just acquired a new laptop which is in need of a conversion. Fedora doesn't look a likely candidate (it has Atheros wireless, and I think RH doesn't ship its HAL), so I'm reading SuSE docs.
SuSE uses slp for discovery right now. If you specify a VNC install, the target announces itself by SLP and one can browse for or (eg in Konqueror). If the server announces itself, the client will find it.
I suggest a some Red Hatters install it just to filch some ideas.
anaconda-devel@lists.fedoraproject.org
-
Alan Milligan -
Jeremy Katz -
John Summerfied -
Matt Wilson -
Peter Jones