SysAdmin Adventures

I have a new page up detailing my adventures in putting together a brand new storage system here at work with the primary purpose of increasing redundancy, reducing cost and increasing efficiency.

The page itself doesn’t look very good because I am still fighting with wordpress. I finally pick a theme I like, but the header css is god-awful. I’m no graphic designer and I thought WordPress was supposed to take care of that, well it doesn’t.

The link:

http://blog.tpa.me.uk/high-availability-storage-with-slackware-drbd-pacemaker/

I finally found a basic fdisk-like utility for dealing with GUID Partition Tables (GPT). And not a moment too soon because I can’t stand GNU Parted which seems to be the only other tool available for handling them. I really wish I understood why because GPT is hardly brand-new. fdisk, cfdisk and sfdisk are WELL overdue for an upgrade.

It’s called (unsurprisingly) gdisk:

http://www.rodsbooks.com/gdisk/

http://sourceforge.net/projects/gptfdisk/

I haven’t bothered making a SlackBuild for it right now, because it’s too simple to bother. Download the source, extract it, type make and there’s your binary. Move it to /sbin if you want.

A lot of people have been coming a cropper on the new Xorg in Slackware 13.0. Because Xorg now loads hardware information automatically via hal  by default, people are confused about how to set things up that they’re used to setting up in the xorg.conf.

Now, a lot of people have been choosing to shy away from the hal-based auto-detection and simply turn it off. That was my initial reaction too, but the bottom line is that this was brought in as an improvement and if you can get your head around it it may prove to save you effort in the long run.

The two things that affect me in a normal set-up are graphics and keyboard layout.


Graphics

If you’re going to use the open source driver shipped with the kernel for your graphics card you almost certainly don’t have to do a thing. Hal will pick up your card, and your driver will be loaded into Xorg. If you need a different driver like the proprietary nVidia driver, then it’s business as usual: run the installer, let it create an xorg.conf for you and that information will be used by Xorg.

You might want to check the xorg.conf that gets created as the installer may not be ready for hal yet and may try to insert useless keyboard/mouse information because the installer thinks it’s required.


Keyboard Layout

Being in the UK, I use UK keyboards. They are different ot US keyboards in that they have £ above 3 instead of # and ” above 2 instead of @ as well as couple of other subtle differences. I also use the GB Dvorak layout for my IRC box and again, this needs a modification.

You’re probably used to loading up your xorg.conf and modifying:

Option     "XkbLayout"     "us"

to:

Option     "XkbLayout"     "gb"

or whatever is relevant to your locale. Well, it’s different now, but practically just as simple. Instead of telling Xorg about your layout, you now tell hal instead. To do this, you need to change the hal config, but you don’t modify the configuration ‘in-place’, you copy the config to a secondary location, and then make the changes you need. In Slackware 13.0:

Modify:

To:

Or for uk-dvorak:

Restart hal. Restart X.


Job done.

Post followed-up by:
Slackware 13.37 – Xorg + Hal

I understand that there are rare situations in which an initrd can be useful. For example, when hardware is constantly being swapped out, or when you absolutely must have an identical kernel image, or if you are using LUKS for your / partition. However, in general an initrd is, in my opinion, a completely pointless level of complexity that you are better off without.

I’m currently managing in excess of 15 completely different Slackware installs across lots of different hardware and not one of them is running a “huge” kernel, or an initrd. If a module is absolutely essential to your system’s ability to boot, why in hell haven’t you compiled it into your kernel? It’s like having a your starter-motor in your car disconnected from the battery, but having a relay on its own mini-battery connect it up when you turn the ignition.. why would you do it? What’s the point? The car will not start without it, why is it not hard wired into the system? It’s the same for the kernel. If the system won’t start without it, compile it into the kernel. Don’t play about with an injection system you don’t even need.

Ok, so your root device is inside RAID & LVM on a GPT partition. So, compile in mdadm support for your RAID level, LVM support and GPT partition support; job done.

For the less experienced, it’s also a good way to learn the basics of kernel compilation without needing to do much more than follow a standard process. All you need to do is use the config from the generic kernel you were going to boot anyway, and knowledge of what filesystem your root device is installed with and what storage controller your disk uses. Go into the kernel config, add them in [*], make, make modules_install, move and symlink the new kernel, update lilo, reboot. Once you’ve done it twice, it becomes so routine and easy you’ll wonder why you haven’t been doing it forever.

Then, once you’re more familiar with the process, you can start removing other parts of the kernel you don’t need, especially hardware controllers for hardware you don’t have, with each step making your kernel smaller and your system leaner and faster.

Have kernel, will compile.

Post followed-up by:
Compiling your own Slackware kernel