SysAdmin Adventures

Let me start by clarifying that I’m actually talking about slackware64-current as of Tue Mar 2 19:07:31 UTC 2010, but for longevity I have titled the post 13.1 because I believe -current to be pretty close to a 13.1 release and I will be updating this server to 13.1 at release and halting updates there.

That said, Symantec have released (Veritas) NetBackup 7. Woo. As insane as it sounds, NetBackup 6.5’s Linux server component was only available for x86 and IA64, but NetBackup 7’s Linux server component is only available for x86_64. Way to screw everybody over, Symantec(!)

Thankfully, this just happens to be beneficial for me as I am at the point of being able to move our NetBackup server from Solaris10-SPARC to Slackware Linux and it means that I get to deploy it on Slackware64. In this case, the server I am using has had alienBOB’s Multilib Conversion; but this is not necessary to support NetBackup 7.

Perversely, the new “OpsCenter” (x86_64) that Symantec won’t shut up about does require 32-bit libs, however it’s also much more tightly bound to RHEL/SLES. NetBackup Server works well out of the box in Slackware, but OpsCenter won’t install on anything but RHEL or SLES and manually extracting the RPMs and forcing it in is much more work that I can be bothered with for a component I probably won’t even need. As far as I can tell, the main reason they are giving away OpsCenter is because they want managers to see it so that they can persuade them to buy OpsCenter Analytics which I’m certain will not be cheap.

That’s the ranting out of the way. Onto the details…

Installation really is a breeze. I used the RHEL version of the installer (NetBackup_7.0_LinuxR_x86_64_GA.tar.gz) not the SLES version (NetBackup_7.0_LinuxS_x86_64_GA.tar.gz) because I am more familiar with RHEL than SLES and I have always been successful in the past using Veritas’ RHEL releases on Slackware. Feel free to play with the SLES version and report back.

Extract the tarball and run the installer. I used the defaults for pretty much every option. Feel free to change the install path from /usr/openv to /opt/openv for correctness, but I am personally very familiar with /usr/openv (as is the software, obviously) and the software lives almost entirely in that subdirectory without polluting the rest of the machine; so it’s a safe choice.

The installer will modify the inetd configuration and add entires to your /etc/services file and put two startup scripts (netbackup and vxpbx_exchanged) in /etc/rc.d/init.d. It will also put symlinks to these in the run-level numbered /etc/rc.d/rc*.d directories. Worth remembering that under Slackware /etc/init.d is a symlink to /etc/rc.d/init.d. In my previous post about running NetBackup client software on Slackware (http://blog.tpa.me.uk/2009/08/30/veritas-netbackup-slackware/) I suggested that you should remove the symlinks and move the netbackup startup script to /etc/rc.d/rc.netbackup. Technically I still believe that advice as I am somewhat of a purist, but I can also be pragmatic when necessary. Slackware has a startup script deisgned to deal with SysV-style scripts called /etc/rc.d/rc.sysvinit and there’s no real reason you shouldn’t just let it do its job and leave the NetBackup scripts where they are. It will certainly help out when it comes to upgrade time; you just have to remember to use /etc/init.d/netbackup (shortest option) rather than /etc/rc.d/rc.netbackup.

Now it’s time for…
The bit that will catch you out:

As is widely known, Slackware still does not contain PAM. There are reasons this is good and there are reasons this is bad. Pat is well aware of all of these reasons and continues to consider his options. In the meantime, we have to be aware of the lack of PAM and work around it where necessary (assuming you don’t choose to install PAM yourself, I know I don’t).

Awkwardly, there is one component of NetBackup server that requires PAM: /usr/openv/netbackup/bin/bpjava-msvc. Unfortunately it’s a critical component. In order to administer a NetBackup server, you use the Java NetBackup Administration Console. When you connect to the NetBackup server with the console, the server authenticates the request by launching the authentication service from inetd; which is bpjava-msvc. Unfortunately for us, and for anyone else that doesn’t have PAM installed (even if they are running RHEL) bpjava-msvc is linked against the main PAM library libpam.so.0 and cannot launch without it:

I have spoken with Symantec about this and they clearly state that NetBackup is not dependant upon PAM, in its absence the Java client authentication service will happily authenticate against shadow, it just happens that the binary is linked to the pam library so needs it to be present to run. While there’s not much they are prepared to do about it right now, there is an “Idea” in the Symantec Connect portal’s Ideas section that requests the development team deal with this issue, and it is the right channel for communicating with product development. If you would like to see the issue dealt with, I heavily recommend you “Vote Up” the idea to bring it to their attention:
https://www-secure.symantec.com/connect/idea/bpjava-msvc-linked-against-pam-unnecessarily-making-it-dependency-entire-application

In the meantime, there is a really ugly workaround. It wants libpam.so.0? Well give it one; just not the rest of the PAM package. If you get the latest PAM source and compile it, you can copy the libpam.so.0 file into the NetBackup lib directory and voilá; everything works perfectly. While you could put it in /usr/lib64 or put it in /opt/pamlib and add /opt/pamlib to /etc/ld.so.conf, I recommend putting it in the NetBackup installation to save from unnecessary modification or pollution of your system. KISS. So put it in /usr/openv/netbackup/lib.

And that’s all there is to it. Now to add your tape/disk/removable devices and setup your backup policies.

Thanks to Symantec, migrating from my Solaris10-SPARC system is not an option. Even changing the hostname of the NetBackup server is not a supported operation and will break everything unless handled very delicately. Symantec say the only way they will help you is if you pay them a bucketload for Symantec Consultation Services. Well I can tell you now that just isn’t going to happen. In practice this means I am going to have to import all historic tapes into the new system (http://seer.entsupport.symantec.com/docs/327873.htm), but thankfully I have a Sun StorageTek C4 Robotic Tape Library that will hold 32 tapes at a time and I only need to import 60 or so tapes. It will probably take the best part of a week, but it’s acceptable.

YMMV

Some days are just better than others.

I’ve just finished completely eviscerating a powerful server that was running Windows 2003 R2.

It’s now running Slackware64-current and very very beautifully so:

Kernel: 2.6.32.7
Kernel Image Size: 2299 KB
Module Tree Size: 33936 KB

CPU: Intel(R) Xeon(R) CPU E5345 @ 2.33GHz

Total RAM Available: 4054384KB
Total RAM Used (+/- b/c): 42240 KB

/dev/sda: 6x SAS disks
MegaRAID hardware controller
4 disk in RAID10.
2 global hot spares.

hdparm -tT /dev/sda:
/dev/sda:
Timing cached reads: 8206 MB in 2.00 seconds = 4106.44 MB/sec
Timing buffered disk reads: 552 MB in 3.01 seconds = 183.66 MB/sec

It’s name according to the Simpsons naming scheme?

Wolfcastle

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.

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?)