SysAdmin Adventures

Sometimes it is necessary to retain a Slackware installation, but change the hardware it runs on:

• Migrating to or from virtual hardware (VirtualBox, VMware etc)
• Duplicating an installation across multiple new servers
• Using temporary hardware to set up a new OS for a server to minimise downtime
• Plain old hardware failure
• etc.

Under many other Operating Systems, especially Windows, this can be painful and perhaps not even worth doing. As usual it is easy with Slackware.

In the simplest case (default install, default kernel, desktop environment) there’s literally nothing you need to do. Just put the disk or image in the new hardware and boot.

If you are using a custom kernel (as you should be) then you will need to create a new kernel and update lilo either before or after you do the migration. If you have any sense of self-preservation, your lilo config will include the default “huge” kernel and so the minimum you need to do is just boot the huge kernel on the new hardware, then you can go about making a new custom kernel later.

The bit that will catch you out:
There is one thing that might make you stumble: you moved the installation, booted up and all is well.. but the network isn’t working. You run `ifconfig -a` and find your two network interfaces are now called eth2 and eth3 and neither is configured.. “What’s going on?”, you ask. The answer is udev.

udev knows that your two new network interfaces are different to your old ones because they have different MAC addresses and decides you might not want to have them configured the same; perhaps you are going to swap in the old cards later and have four, so it reserves the previously used “ethX” labels in case it sees those cards again.

Since you are migrating to new hardware, you want it to forget about your previous network interfaces and re-use the labels with your new hardware. Head to /etc/udev/rules.d and find the file called 70-persistent-net.rules. Take a look at it.. it should look something like this:

See how it has an entry for both the old interfaces and the new ones? That’s what’s meant by persistent net rules. If you moved to a new machine again, it would add the two new interfaces as eth4 and eth5.

You have two choices for fixing the situation:

1. Delete the file. It will be re-created on next boot and start again from eth0.
2. Manually modify the file to reflect the configuration you want.

Note: There is also a 70-persistent-cd.rules file that it’s worth keeping an eye on during hardware migration, but usually it’s only the net rules that actually cause people problems.

Finally got around to making a SlackBuild for DRBD. Made a little easier by the introduction of a configure script into the DRBD source.

The script is available below and has also been submitted to SlackBuilds.Org.

Have fun.

DRBD SlackBuild (v8.3.6)

• SlackBuild updated on 12/11/2009 for better handling of kernel source dir.

OpenLDAP Software is an open source implementation of the Lightweight Directory Access Protocol.
The suite includes:

* slapd – stand-alone LDAP daemon (server)
* libraries implementing the LDAP protocol, and
* utilities, tools, and sample clients.

There are a few things I’d like to mention about OpenLDAP in Slackware-13.0 and so I might as well deal with them all in one post.

Running an OpenLDAP Server

I can’t remember why, but Pat made the decision not to provide slapd, the OpenLDAP server daemon in Slackware by default. This has been the case for some time. Instead, what you get is openldap-client which is just the client libraries enabling you to use OpenLDAP code in LDAP client applications and LDAP-dependant software.

If you want to run an OpenLDAP server you are going to need slapd. Thankfully this is incredibly easy to do because all Pat did to remove slapd was to configure the OpenLDAP source with:

If you want slapd (and perhaps slurpd) then you just need to rebuild the openldap sources using the SlackBuild Pat provides in the Slackware source, but with the word disable replaced with enable. However, there is a catch. In Slackware-13.0 OpenLDAP will not build with the source and SlackBuild Pat shipped because the OpenLDAP package has not been rebuilt since 24/07/2008 and since then a change has been made to the C compiler that prevents OpenLDAP from building correctly unless you append the flag -D_GNU_SOURCE. This wasn’t detected early enough for it to be fixed for the 13.0 release. Normally this isn’t an issue because the package still works perfectly, but if you want to rebuild it you have to modify the source or the SlackBuild to do so.

Assuming your Slackware source is located at /mirror/slackware/slackware{64}-13.0:

Working in vim so you can see what you’re doing.. (you could replace however you wanted, e.g. with sed, or manually, or whatever):

Then go and have a sleep for half an hour as it builds and then tests just about every conceivable LDAP operation.
Once it’s done:

Job done.

Using OpenLDAP for User Authentication

In other distributions, setting up LDAP user authentication for the OS is done with Linux-PAM. While, mercifully, Slackware does not have Linux-PAM (and probably never will) it does mean that LDAP user authentication is harder or more impractical.

Note: I do not recommend doing LDAP user authentication for your Operating System. It’s not necessary in most cases. LDAP authentication should be done at the application level for specific services provided to users. The Operating System should only be authenticating users that actually log in to the system and in most cases LDAP is not needed for this. (Don’t argue if it is truly necessary in your case – you’re an exception).

If you are absolutely sure you definitely need LDAP user auth for Slackware, your options are:

Install PAM

This is an epic challenge and few succeed. Since PAM is evil anyway, do not bother. If you choose to take this route and succeed, then document your adventures and link to them.

Use nss_ldap

The resolution of the entities defined in RFC 2307 is generally performed by a set of UNIX C library calls (such as getpwnam() to return the attributes of a user). The nss_ldap module provides the means for Solaris and Linux workstations to this information (such as users, hosts, and groups) from LDAP directories. The module is the reference implementation of RFC 2307, and has been studied by vendors such as Sun (who developed the original Name Service Switch interface).

This basically allows you to use nsswitch.conf to redirect user entry queries to an LDAP server and seems the natural way to do LDAP auth in Slackware, but there is drawback. In normal circumstances LDAP authentication is done with a bind. The user supplies a username and password and the application submits a login request (a bind operation) to the LDAP server and the LDAP server returns success or failure depending on whether the credentials are valid. This is not possible with nss_ldap because nss_ldap doesn’t replace the authentication method, it just redirects it to a different storage back-end. The effect of this is that to use nss_ldap you have to store the users’ passwords in the LDAP server using the same hashing algorithm you would use in the passwd file (crypt()).

I’m not going to go into any further detail on this, you are going to have to do the research yourself, but suffice it to say nss_ldap is not ideal, but it is the cleanest method and probably the one I would use if I had to.

Use NIS and a ypldapd

The NIS/LDAP Gateway, or ypldapd, is a Network Information Service (NIS) server which uses LDAP as its information source. It permits existing NIS clients to transparently use LDAP to resolve user, group and host information. Enterprises can thus realize the benefits of LDAP, such as its distribution and being scalable, without upgrading clients.

I personally haven’t tried this and can give no reasoned opinion on it, but if you are migrating from NIS to LDAP it seems like a reasonable way to get going with it and may also cover the drawbacks of the nss_ldap solution – but it has it’s own drawbacks.

1. You must have or implement a NIS network.
2. It’s not free.

I’ve had a number of requests for the SlackBuild I used for XBMC on Slackware 13.0.

Personally I used Larry Hajali’s SlackBuild for v9.04.1 (with patches). His post to the Slackbuilds-users Mailing list is here:
http://www.mail-archive.com/slackbuilds-users@slackbuilds.org/msg02041.html

Just in case, I’m hosting the SlackBuild here too:
XBMC v9.04.1 SlackBuild

Hopefully Larry’s will eventually make it onto SlackBuilds.Org so you can install it from there or with sbopkg but until then, this will have to do.

If you want the subversion head, then you can either modify Larry’s or head over to http://xbmc.strangled.net/source/xbmc-svn/ where there’s a SlackBuild script written specifically for the purpose.

DISCLAIMERS:

• I have only personally used Larry’s SlackBuild exactly as provided by Larry.
• Your Mileage May Vary.
• I provide absolutely no guarantee that anything will work as described.
• I take no responsibility if the above information breaks your computer, ends your marriage or otherwise destroys your life.
• Read the README before doing ANYTHING.

UPDATE:
Larry has updated the SlackBuild a little:

I’ve made a couple of changes to the slackbuild. Fixed some
hard coded “lib/python2.5″ paths in the EventClients Makefile. The
Nvidia hack in no longer an option and is now done by default. Now
the the xbmc slackbuild will compile on Slackware64. XBMC is 64 bit
compatible but by default is not completely lib64 compatible. Mesa
7.5.1 is now needed from a slackware mirror as it has the required
glxinfo for direct rendering detection.

Thanks to fire|bird from ##slackware for helping me troubleshoot
Slackware64 compilation and to pprkut for additional script cleanup
and testing on Slackware64.

The updated version (that I have personally not used or tested) is here:
Updated XBMC SlackBuild

Want to tar up only the dotfiles (hidden files/dirs) in your home directory?

or (thanks to mosk0bit)

The astute will notice the “J” and the “xz”. J tells tar to compress with xz compression (formerly lzma) which is significantly better than gzip especially with the type of files you will expect to have in your hidden directories. If J is not available in your version of tar, use z instead.

Neither of these solutions are absolutely perfect, but they are at least simple. For the perfect score, see slava_dp’s comment:
http://blog.tpa.me.uk/2009/09/29/tarring-up-just-the-dotfiles/#comment-478

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.