starting Fedora Server SIG
Les Mikesell
lesmikesell at gmail.com
Fri Nov 21 19:14:01 UTC 2008
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 at gmail.com
More information about the fedora-devel-list
mailing list