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

Re: starting Fedora Server SIG

Chuck Anderson wrote:
On Fri, Nov 21, 2008 at 08:20:14AM -0600, Les Mikesell wrote:
Les Mikesell wrote:
Matej Cepl wrote:
On 2008-11-20, 07:00 GMT, Les Mikesell wrote:
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.
Sorry, maybe I don't understand, but what's so difficult on the following?

tune2fs -l /dev/sda1 |awk '/UUID/ {print $3}'

The disk may be unformatted at this point and not have a UUID.
I know it is bad form to follow up to my own posting, but I think I've been making my argument in the wrong way so far. I'm not really against changes in the way things are done or even the details of those changes as long as they are exposed somehow. What I am against is hiding those changes in anaconda or other parts of the installer process so that the only reasonable way to build several machines is to automate the way you interact with anaconda with another tool like cobbler, and after it is built you can't change anything.

We need a way to do the things that only anaconda knows how to do at times other than the initial install. For example, you want to move a working system disk to another machine, or replace the booting disk controller, or restore your backups onto a similar system. Or clone a bunch of copies of the same boot/system disk and expect them to run in different machines. It doesn't really matter how this is accomplished, just that there is a plan for it and hopefully it doesn't involve a human needing to know every possible thing that anaconda knows about hardware. Could there be a way to re-run anaconda after moving a system to new hardware and do an automatic fix-up?

I thought good disks had built-in UUIDs in the firmware (perhaps this is only for Fibre Channel). Or you could use the serial number which shows up under "smartctl -a" to identify physical disks. And some fancy disk shelves have "identify disk" commands which blinks some LED on the front of the disk.

Once you know which physical disk is the one you want, you can clone to that disk and then reset the UUIDs or LABELs to unique values.

There are several different layers to this problem - and it isn't really restricted to servers. Everyone needs to know that if their machine dies they can move the system disk to a similar box or restore their backups and keep working. So, consider the simple where you move a scsi boot drive to a new machine that has a different scsi controller and different ethernet adapters. You can boot in rescue mode from the install CD and have your old partitions automatically mounted, so obviously it is possible to figure the driver issues out - but the thing that can figure it out won't fix things for you. So first you have to get the right drivers to be included and get rid of the old ones by twiddling modprobe.conf in some magic ways, build a new initrd, and perhaps re-configure grub to use it. And if you restored from a backup, add in making sure the partition identifiers (whatever they might be this week) match the identifiers in /etc/fstab or you won't even get to the point where the rescue boot will mount the system to fix it. You also have much the same problem when adding new hardware after the initial install or if you swap NIC or disk controller cards. Everyone needs this basic capability. Server admins just need to be able to repeat it predictably across a lot of machines.

Once you have the machine in bootable condition with the right drivers connected to the available hardware, you need a way to interactively explore the new hardware without a gui, sort of like running 'fdisk -l' will enumerate the drives and current partitioning, but this tool has to be adapted to any new ways of describing mountable objects. Similarly a tool like mii-tool should enumerate your NICs and show which have link established - and any other useful information they can detect. Then, once you understand the setup for any hardware type you need to be able to script it repeatably for any number of instances with a way to supply whatever variables it might need (i.e. mac addresses, UUID's, etc.).

My objections to the changes in fedora are not so much related to any details of a change but that they aren't encompassed by scriptable text based tools that list and set the options or if those exist they are fragmented into a bunch of choices that have to match whatever anaconda did that you may not know about.

  Les Mikesell
   lesmikesell gmail com

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