SysAdmin Adventures

So you broke lilo. Well done.

Insert your Slackware install DVD or CD1 and boot with defaults.
Once booted:

where /dev/sda1 is your installed / partition. Adjust as necessary.

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/

Although I like to get people to read through the documentation properly so that they understand what they’re doing properly before they do it, basic package management is one of those things you really need to be able to pick up and run with even if you’re just playing about with a new OS, or perhaps especially if you’re just playing about. This page has a very good quick and screenshotted summary of the basics for Slackware:

http://beginlinux.com/desktop_training/168-slackware/1427-slackware-package-management

At least once a week I see someone with this issue.

With reference to my earlier post about Xorg + Hal, by default, Xorg in Slackware 13 gets its hardware information from hald instead of an xorg.conf file. If you have no xorg.conf file and hald is not running, your keyboard and mouse will not work when you start X.

• The Cause: You disabled or broke hal.
• The Solution: Darwinist Determinism.

Failing the first solution:

Then restart X or reboot (probably easier to just reboot and it clears any anomalies).

If it still doesn’t work, check that your /etc/rc.d/rc.hald script is not empty (I don’t know how he did it, but I did see someone who’d zeroed his script during an upgrade).

If it still doesn’t work, then you probably actually have a problem rather than just a failure on your part and it’s time to go searching for likely causes. Best place to start would be to google your specific hardware in relation to hal.

I have been using XBMC for about two weeks now on Slackware-13.0 using an Asus infra-red remote control that presents itself to the machine as a keyboard & mouse. My opinion is thus: it is fantastic!! The interface is beautifully crafted and easy to use. With the remote control I have it’s easier to use than an iPod Touch. It all just works. Installation is a breeze as there is a SlackBuild script for it. The script hasn’t quite made it to the SlackBuilds.Org repository yet, however thanks to a patch from Pat for Slackware-13.0, I expect the XBMC SlackBuild to be accepted at SBo any day now.

The obvious drawback is that it doesn’t have TV tuner functionality but then it doesn’t need one. It’s not what it’s designed for. If you want TV, go give the MythTV developers a hand to see if we can’t get that shocking piece of floppyware to be usable again.

I haven’t even started looking into all the plugins and other bits that are available for XBMC, but the reason is simple: I haven’t needed to. More often than not, I start going looking through customisations because I’ve needed at least one to add functionality or fix something in an application. In this case I’ve yet to discover anything I needed changing.

XBMC is AWESOME

End of discussion.

I’ve been trying to build a media centre pc based on Slackware 13.0 and done pretty well using XBMC which I think is pretty damn good. At the moment, it lacks any TV support, which leaves me with MythTV. In order to play with MythTV, you have to get it installed. There is no SlackBuild for it at SlackBuilds.org because it’s a righteous pain in the arse. Nevertheless, I have modified the SlackBuild for 12.2 by David Somero and successfully compiled and installed MythTV. I haven’t yet fully tested it, so I can’t tell you if or how well it works, but it definitely compiled ok.

In order to get it to build against a recent kernel, I’ve had to move away from the official 0.21 release to subversion, however I don’t mean /trunk. In the MythTV subversion repository, as well as the tagged 0.21 release and the current /trunk, there is also a branch called 0-21-fixes. Now, any other software project would be releasing snapshots of this branch as 0.21.<minor-rev>, but MythTV choose not to, so you effectively have to consider this branch as an unstable stable, which means it works where the official 0.21 release doesn’t, but because it’s subject to commits it might not be properly stable.

You will also need to install qt3-compat from the Slackware 13.0 “/extra/kde3-compat” directory, and it’s probably worth making sure you have lame installed too.

The SlackBuild tarball is here:

MythTV SlackBuild

• I RECOMMEND YOU READ THROUGH THE SCRIPT BEFORE YOU USE IT.
• I ACCEPT NO LIABILITY IF THE SCRIPT DESTROYS YOUR MACHINE.
• THIS SCRIPT IS ONLY VALID FOR 32-BIT SLACKWARE 13.0.

The script checks out the head of the 0-21-fixes branch into /tmp/mythtv-build/mythtv and installs into /tmp/mythtv-build/package-mythtv before outputting a package into /tmp.

It ought to be simple enough to modify the script for 64-bit slack with a configure flag here or there, but I don’t have a 64-bit Slackware machine available that I am prepared to test it on.

20091207 Update: Superceded by http://slackbuilds.org/repository/13.0/multimedia/mythtv/

This is a simple one.

Pidgin uses GStreamer for producing sound (don’t ask me why.. I think it’s a bit daft too). GStreamer relies on plugins for pretty much all sound formats.

GStreamer plugins come in three categories:

• gst-plugins-good (high-quality LGPL plugins)
• gst-plugins-bad (reasonable-quality plugins with free distribution licences)
• gst-plugins-ugly (good-quality plugins that have licence/distribution issues)

Pidgin’s default sound scheme uses WAV files and therefore needs the GStreamer WAV plugin which is available in gst-plugins-good. I have absolutely no idea whatsoever why Slackware 13.0 ships with GStreamer but without gst-plugins-good, however this is not a problem because SlackBuilds.org solves everything:

(you do use sbopkg don’t you?)

Ok, so I’ve made clear how I feel about using an initrd to boot your generic kernel. I also think that running the huge kernel on a permanent basis is equally insane. So I guess I’d better tell you about the alternative: compiling your own kernel.

I should make it clear straight away that by no means do I consider the kernel an easy topic for most people to deal with, nor do I think I have a full grasp on every nuance myself; but I do think that the best thing you can ever do for your system is to build your own. Needless to say there are already a million billion kernel compilation guides out there, but they all make such a big deal out of what is an unbelievably simple process, especially in Slackware.

So.. give me five minutes of your time and I will show you the process I follow for each and every Slackware box I administer that gives me a generic kernel, no initrd, and endless options for customisation should I choose to take them. It’s simple, trust me.


Compiling your own kernel in Slackware Linux in 10 easy steps…

I can happily confirm that Veritas NetBackup’s RedHat2.6 client installer works absolutely perfectly for Slackware. So all of you who are stuck with Veritas NetBackup can rest easy.

Simply:

1. Run the installer
2. Delete the symlinks it creates in /etc/rc.d/rc{x}.d
3. Move /etc/init.d/nbclient to /etc/rc.d/rc.nbclient
4. chmod 755 /etc/rc.d/rc.nbclient
5. Add “/etc/rc.d/rc.nbclient start” to /etc/rc.d/rc.local
6. Add “/etc/rc.d/rc.nbclient stop” to /etc/rc.d/rc.local_shutdown
7. Configure client & server policies on the server.

Worth noting that I use this config for the Slackware clients at the moment:
/usr/openv/netbackup/bp.conf:

SERVER = [server-name]
CLIENT_NAME = [client-name]
USEMAIL = [e-mail address]
MEGABYTES_OF_MEMORY = 512
SERVER_SENDS_MAIL = YES
BUSY_FILE_PROCESSING
BUSY_FILE_DIRECTORY = /tmp
BUSY_FILE_ACTION = /* mail
BUSY_FILE_ACTION = /* repeat 2

Update: In Slackware64-13.0 you need the multilib stuff to get this working because it’s only released as x86 and IA64, not x86_64 – but there’s a gotcha. The installer provides its own copy of x86 tar which depends on x86 libacl.so.1 which even the multilib packages don’t provide. Initially I set about trying to put an x86 libacl.so.1 into the Slack64 box until I realised I was going about it the wrong way:

UPDATE 20100222:
NetBackup 7 has been released and I have it running as a server on Slackware64-13.1:
http://blog.tpa.me.uk/2010/02/22/netbackup-7-server-on-slackware64-13-1/

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