starting Fedora Server SIG

[Les Mikesell]

Doug Ledford wrote:
> 
>> Errr, doesn't having to build server to run cobbler before you can 
>> install your real server make this a circular argument too?  Assuming I 
>> wanted a cobbler server at every remote location instead of shipping a 
>> pre-configured disk, how would I build it when it needs a cobbler server 
>> first?
> 
> No, this goes to the statement I made about some amount of setup cost
> that then is made up for in time savings in the future.

That's assuming that (a) the same  OS is reused in the future and (b) 
that the configuration technique doesn't change in the next rev.  I'm 
not making any commitments about (a) and you aren't giving me a warm 
fuzzy feeling about (b).

> And you only
> need one cobbler server.

Per location?

> You can install the image on a local machine
> and then ship the disc off (or if you can't, the concept of a local
> install box used to create disc images destined for a remote box that
> has a different mac address than the local install box wouldn't be a
> hard thing to add to cobbler, but since you haven't tried it and haven't
> brought up this need, it might not be in there yet).

Yes, I swap disks around, both locally and shipped elsewhere.  It is 
very inconvenient if the OS doesn't handle this gracefully.  And 
everyone needs to be able to restore a backup into a similar machine and 
come up working, something that presents approximately the same issues.


>> What tools don't involve the bootstrap problem - or are suitable for 
>> isolated remote servers?  Or maintaining a diverse set of OS's?
> 
> See above.  And cobbler has experimental support for SuSE and debian
> systems.  I'm sure the authors would correct any bugs you might run
> across in trying to use cobbler with those.  As for non-linux OSes,
> especially windows, cloning is probably the right call.

The larger set is currently windows but things are juggled around 
regularly to match the need for services.

>>   And it misses the point that I want to be able 
>> to shove a disk into chassis slots in a certain order and know what to 
>> call a partition on a particular physical disk regardless of where it 
>> was used before.
> 
> The unique filesystem labels I mentioned previously would achieve this
> result too.

With a lot of extra work to track the labels or discover them after the 
disk is moved.

>>   Plus,  the concepts are wildly different when you use 
>> md devices (and probably LVM's too but I've avoided those completely).
> 
> md devices are 100% discover by label, not by disk partition.  It scans
> the partitions and assembles based upon the labels therein.

Yes, the assembly portion is OK, assuming the disk wasn't cloned (i.e. 
the auto-created identifiers are unique when created), but at least 
older versions would get confused if you put disks that used to have the 
same md device name together in the same box.  I haven't tried that 
lately, but it is another inconvenience to have to avoid it.

>>> 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.
>> It is the minimal amount of work to get a correct setup.  The 
>> information needed to set the hostname and IP addresses has to be known 
>> and entered somewhere.
> 
> Yes, and it has to be redone every time you reimage a disk for that
> machine. 

As it must, because the information will probably be different for the 
new machine usage.  Or the new load on the disk may be a different OS.

 > On the other hand, when you enter the same information in
> cobbler, it can (optionally) enter the information in your dhcpd.conf or
> dnsmasq.conf, enter the information into your named zone file, and the
> machine is now permanently in the database so any time you reimage that
> same machine, it's all there ready to go.

How does that work in a mixed environment?  Some zones have windows DNS 
servers.  And does it understand split views of DNS?  Is the dns/dhcp 
config-writer a separate piece that can be used where cobbler doesn't 
build the machines?

>> Yes, I choose not to use them because they aren't appropriate for my 
>> usage.  They require a large amount of infrastructure work and only 
>> serve a specific OS - and probably only one or a few versions before you 
>> have to rebuild your infrastructure again.
> 
> Not true.

How many years/OS revs have you spanned with a single cobbler install?

>>> 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.
>> What can possibly be easier than typing 'dd'? 
> 
> Not having to type dd and then edit the results to get the right image?

Black magic hasn't worked out that well for me.

>>  I like unix-like systems 
>> because everything is a file or a stream of bytes and those don't take 
>> specialized tools to manage.
> 
> Nor do they fill in the right information for you.

Nothing is going to fill in the right information for me. Nothing can 
possibly already know the right information - or even the OS type I will 
want on the next disk.

>>>> 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,
>> Ummm, OK - so are you implying that having a label on a partition on sda 
>> is useful in that circumstance?  Things that break just have to be 
>> replaced before they work again.
> 
> Except that this isn't the only situation.  You brought up the other one
> yourself in that putting more than one disk in a machine is a valid use
> case too.  As I pointed out, unique device labels eliminates the need to
> know for certain if the two disks you added went in as sdb and sdc or
> sdc and sdb.

But now you have to know every unique label instead.


>>   The way md devices work is sort-of ok, 
>> if you've handled the special case for booting, but they worked that way 
>> all along.   I'll agree that linux got most of the things it didn't copy 
>> from sysvr4 wrong in the first place including scsi drive naming, but 
>> changing 'detection order' naming to 'labels likely to be duplicates' 
>> isn't a good fix.
> 
> Unique labels is though.

Maybe - but it isn't a real solution.  You still have to deal with 
identifying the device before and during the labeling process.  If you 
can do that, you didn't really need the label.

>>> 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.
>> I have very little interest in converting to procedures that only work 
>> with one or a few versions of one distribution of one OS.
> 
> As I mentioned before, this isn't an accurate assessment of the support
> cobbler provides.

It's close enough in a mostly-windows environment.

>> Which tool besides clonezilla is good for cross platform work?  Are 
>> there even tools for a specific purpose like replacing a set of RHEL3 
>> servers with RHEL5 equivalents, maintaining the existing IP addresses on 
>> several interfaces each?  I eventually came up with something to scarf 
>> all the old ones from the running systems along with the corresponding 
>> mac addresses and included them in the clonezilla image with a script to 
>> patch things up but it wasn't pretty.
> 
> Yes.  Cobbler allows you to retarget a machine.  If a specific system
> was registered as a rhel3 system you can simply change it's parent
> profile to rhel5 and it will preserve all the ethernet information, etc.

But can it pick up the info from a machine it didn't create?  I didn't 
know about cobbler when rolling out the initial set of machines and 
probably wouldn't have trusted it even if it existed back then.


>> When something has been working for decades why would anyone want to 
>> change it?  And if it hasn't been working, why even look at a unix-like 
>> system in the first place?
> 
> Seriously?  It has to be 100% right the first time or move on?  Don't
> try to fix anything that's not right?

What a unix-like OS is supposed to do has been pretty well understood 
for decades.  Changing it isn't likely to be a fix.  Drivers and 
schedulers can probably always be improved, but those changes are mostly 
invisible.

>>  > 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.
>> The way to do it is to have the kernel and the hardware use predictable 
>> but unfriendly conventions for the 'real' names that connect drivers to 
>> hardware
> 
> Done.  For eth0 on my machine lspci reports:
> 04:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd.
> RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 01)
> 
> I can use that to go to /sys/bus/pci/devices/0000:04:00.0 and in there I
> find a directory call net and in that directory is a directory named to
> match the system name of the device (in my case eth0).  So no matter
> what device name this would have gotten, if I want the ethernet device
> in the particular pci slot this device occupies, going into the net
> directory gives me that name.  A similar convention can be used to get
> to any scsi device by pci device, then scsi controller, then host
> number, channel number, target number, lun.

OK, but is that documented to the point that scripts can be easily 
written to set up known hardware predictably without arbitrary 
naming/ordering done by the kernel or other places (like something 
renaming the eth?s later).

>> Will any of the changes involving friendly identifiers for partitions 
>> help me when I connect a new unformatted drive?  Will any help with 
>> mounts that are done over nfs or cifs?  What about iscsi?  If I have to 
>> identify a new raw disk myself to make the partitions and filesystems 
>> when adding it, why do you think I need different terminology to 
>> identify the partitions  after that step is done?
> 
> See above about putting two disks in a machine to do whatever to them,
> one of your use case scenarios.

What do you do for the cases where there is no hardware associated in 
the first place?  Iscsi disk connections would be an example. I don't 
see how having the kernel make up friendly names and guess at which name 
goes where will help you in this case.

>> Likewise with network interfaces: when what I want is some particular 
>> vlan from a trunk, will the changes help with that?
> 
> Going by mac address helps, certainly.  The eth names can flip flop all
> day long, but in the end you know that cable X  with vlan Z is plugged
> into the eth port with mac Y and you can set things up that way.

Vlan trunks have one associated NIC and hardware address but may carry 
many logically separate subnets.  I believe the kernel is capable of 
dealing with them, but I've never seen any detailed documentation on how 
to configure them so I've only used windows where they were needed.  I'd 
consider changes to be worthwhile if they make it easy to manage 
technology like vlan trunking and iscsi connections. Can cobbler set 
these up for you?

-- 
   Les Mikesell
    lesmikesell at gmail.com