On Tue, 2008-11-18 at 16:27 -0600, Les Mikesell wrote:
> Doug Ledford wrote:
> > On Sun, 2008-11-16 at 00:13 -0600, Les Mikesell wrote:
> >> Jeremy Katz wrote:
> >>> Lots of things in a modern system are far removed from the stuff a unix
> >>> sysadmin has traditionally dealt with. That doesn't make it necessarily
> >>> "bad". And as Seth pointed out, this "all new is bad" or "all new is
> >>> good" dichotomy is a part of the problem
> >>>
> >>>
> >> 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 the hardware mac address that matters. 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. 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 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 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, 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.
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.
--
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
