starting Fedora Server SIG

[Les Mikesell]

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 at gmail.com