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.
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. 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?
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_.
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.
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.
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. Some tools to deal
with the changes being made could help with this but so far I haven't
seen any.
--
Les Mikesell
lesmikesell@xxxxxxxxx
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
