[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: starting Fedora Server SIG



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


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]