starting Fedora Server SIG

[Les Mikesell]

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