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@xxxxxxxxx
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
