Note: I always use my Red Hat email address, but in this case, I
specifically note that I'm speaking for myself as a Fedora community
member, and not on behalf of Red Hat.
On Tue, 2008-11-18 at 21:09 -0600, Les Mikesell wrote:
> Doug Ledford wrote:
> > >>>
> >>>> But if a system claiming to be new/better can't provide more or less
> >>>> exact emulation of the system it wants to replace, it probably really
> >>>> isn't better.
> >>> That statement is based on the incorrect assumption that the way things
> >>> used to be is/will be sane for the way things are going. Sometimes you
> >>> just need to do things differently because what we grew up doing just
> >>> doesn't work any more.
> >> Maybe - when tcp is replaced with some other protocol - or name and
> >> number assignment are no longer parceled out through a hierarchical
> >> process. Until then, servers need a way to assign the addresses
> >> manually in ways that are easy to relate to the physical wires that you
> >> plug into them,
> >
> > That's not true. The relating of numbers/names to wires is an arbitrary
> > abstraction, and one that need not be the *only* possible abstraction.
> > I admit it's handy and common, especially with servers. And certainly
> > you want a server to get the same address from boot to boot, especially
> > if it's a live server on the internet with people coming to it (or live
> > server on an intranet). But, the eth0 naming is really
> > irrelevant...
>
> It's not irrelevant in the context of a unix-like system where devices
> are identified by name and you want to clone a bazillion copies of a
> machine.
This is a circular argument. I argued that the eth0 naming is arbitrary
and could be done differently, you say it can't be done differently
because you do it that way now.
> > it's the hardware mac address that matters.
>
> It is now. In the 2.4 kernel days I could copy a system disk from an
> identical machine, change the hostname and IP address for eth0, eth1,
> etc.
At the point you clone a disk and then manually edit the eth0, eth1,
etc. addresses, you are no longer strictly cloning. You are
customizing. The choice of customization is arbitrary. Whether you
customize the disk by cloning and editing, or by using something like
cobbler to clone the install via a profile and then have cobbler
customize the addresses based upon its database is merely
implementation. And that's my point, there are better implementations
to be had.
> and ship a box of them to remote locations where anyone could
> insert them into a chassis and have them come up working. Now it
> doesn't work and I either have to know every target mac address and
> match up the disks or talk some 'hands-on' operator through the setup
> with a console on a crash cart to get the address assignment done. Is
> that an improvement?
Failure to use tools that automate this sort of thing is not a valid
indictment of the infrastructure that's been put in place.
> > Being able to
> > go from wire to mac address matters, and going from mac address to
> > configuration matters. Whether that configuration is called eth0 or
> > pr0n_serv0 doesn't really matter. To use a similar situation that we've
> > already changed, back in the day, the only way to mount your root
> > filesystem was by device major:minor. Eventually, we figured out that
> > since file systems have unique identifiers, we could screw the
> > major:minor pair and mount by label instead.
>
> That sucked too, if you recall what happened when you tried to re-use a
> disk, putting one you had used before into the same chassis as a current
> one. For the first year or so after this change was made, this scenario
> would result in a machine that _would not even boot_.
Anaconda uses default labels for devices. You could have done a small
post script during a kickstart install to rectify this. One loop to
modify all the device labels of filesystems to a unique label based
upon, say, hostname + mount point, eg. firewall-10.0.1-root as a
filesystem label combined with modifying the entries in fstab, then a
final line to rebuild the initrd image. This sort of thing can be
automated easily in cobbler such that the default kickstart template
need not know about each machines name/purpose, you can use variable
substitution to do what you want.
> > Now, that switch required
> > changes to mount, changes to fstab symantics, changes to initrd, etc.
> > But, it happened, and I doubt many people would say we are the worse off
> > for it.
>
> I do. My machines often have disks cloned from elsewhere, or that have
> been previously used and have duplicate labels but are not exact copies.
> I find it hard to believe that this doesn't happen to anyone with a
> reasonable number of machines or who re-uses parts. I always undo any
> labels the installer puts in fstab so I know what partitions will
> actually be mounted.
>
> > I think there's definitely more to be done before we are ready
> > to make the same sort of switch in regards to networking, but I prophesy
> > that eventually we will get there and the old days of static ifcfg-eth0
> > files may go the way of the dinosaur.
>
> And I think you are entirely off-base in terms of making it harder for
> someone who knows which device is which to actually identify it to the
> OS. I won't say it would be impossible to make things better but so far
> it has just created more work.
Actually, it has created less work for those people that utilized the
tools that have been created to automate these things. In your case,
you already mention having to go in and hand edit network settings any
time you clone a disk for a new machine. That's not 0 work. Yet, with
things like cobbler, there is a certain amount of work to get things set
up initially, but once that's done, the amount of work goes down. Your
real complaint is that your work has gone up *because* you choose not to
make use of these tools or better methods of doing things. I don't know
what to say to that. If your going to do things the 1980s way and no
other, then I'm not sure there's anything that anyone can do to make
your life easier.
> >> and it needs to be done by a person with authorization
> >> passed down the appropriate hierarchy. It's not something a daemon can
> >> guess at. If you want to make things easier for people who haven't
> >> already automated their processes, you could build a gui that deals with
> >> with configuring the separate programs that need to be tied together for
> >> related concepts. That is, you could have a gui form where you fill in
> >> a name, ip, and mac address and have the tool build the forward and
> >> reverse DNS zone entries and either the local interface configuration
> >> tied to that nic or the dhcp entry to assign it to a different machine.
> >>
> >> For people who have already automated these processes, try not to screw
> >> it up too badly. If the way it is done now didn't work, we wouldn't
> >> have an internet.
> >
> > I'm sure it won't screw existing setups unless there is an overwhelming
> > compelling reason.
>
> But the changes you mentioned already have.
Not for those of us doing things in any way other than the old way.
> > But, sometimes it's worth letting go of the old way
> > of doing things. And I'm not saying this is even one of those cases,
> > just that your statement that it can't be better if it doesn't exactly
> > emulate the current way of doing things is a patently false straw man
> > and that each case needs to be evaluated individually and objectively.
>
> Please think through the way you would clone a large number of servers,
> particularly when you swap disks around and ship to remote locations
> before you consider some change to be for the better. Or what happens
> when you take several previously used disks and put them together in the
> same box for one purpose or another.
>
> > For my own purposes, what would make dealing with udev/hal/etc. on a
> > server system much easier would be some concise guides in terms of how
> > these layers dealt with dynamic devices and how to achieve what you used
> > to do with modprobe.conf in udev land for example. One of the things
> > the server SIG can do is come up with exactly that sort of
> > documentation.
>
> I don't want dynamic devices on my servers. I want to know exactly what
> they are and how they are named by the OS. And I want a hundred of them
> with image-copied disks to all work the same way.
But that's the fallacy of your argument, things *didn't* work that way,
ever. At least not under linux. A device failure could cause sdb to
become sda, or a BIOS or kernel update could cause eth0 and eth1 to flip
flop. The changes that were made were to deal with real world
situations that you get to ignore because you tightly control your
setups. If you embraced some of these changes and worked *with* them
instead of disabling them, then you might be able to loosen up some of
that control and find that things still work like they are supposed to.
> Some tools to deal
> with the changes being made could help with this but so far I haven't
> seen any.
I'm sorry, but you must not have looked very hard. The tools are there,
and they do a damn fine job.
I really think this all boils down to one simple fact: Fedora is
supposed to bleeding edge, and that includes improving upon old, tired
ways of doing things for better ways, and that seems to be anathema to
you. I hate to say it, but it sounds like what you really want is not
Fedora, but OpenSolaris. I'm afraid that as long as you want to
maintain your setup the same as it has been for decades, that Fedora and
the direction Fedora is heading in is going to continue to frustrate
you. And I really hate to say that, because I *want* Fedora to be all
things to all people, but realistically it can't. And in this
particular conflict, it's a case of "we have real world problems from
some users so we fix those problems with a better way of doing things"
versus your case of "in my particular world, these problems don't exist,
so don't change things around" and I just don't know how to rectify
those two positions. In the end, Fedora is going to be true to its
goals, including being bleeding edge and fixing things that are broken,
and I don't think it's even possible to stop the march of that progress
for the sake of your particular setup and working habits. We can
attempt to, but sometimes things simply must be changed in order to deal
with other people's reality.
--
Doug Ledford <dledford@xxxxxxxxxx>
GPG KeyID: CFBFF194
http://people.redhat.com/dledford
Infiniband specific RPMs available at
http://people.redhat.com/dledford/Infiniband
Attachment:
signature.asc
Description: This is a digitally signed message part
-- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
