My company has been bought. While this means a lot of good and bad all over the place, it means one thing that’s very sad; I am about to commence work on tearing down the network I have so lovingly crafted over the last four years. Within a year I don’t expect there to be more than one or two Slackware boxes still running, if any. Black armbands please.
I have a right pain of a problem in this network in that individual machines are slow to get network access at boot. I haven’t had the opportunity to properly find out why, but my instinct says the blame lies with the Allied Telesyn switches.
The big problem this causes is that any machines with a remote filesystem, such as an NFS share, in their fstab fail to mount the shares at boot; which means I have to manually ssh in and issue a mount command as root.
The solution is to ask rc.inet2 if it would kindly consider waiting just a little longer for the network to come up and not mount remote filesystems if it doesn’t.
The following patch attempts to ping an always-on host, preferably the host that serves the filesystem(s) you are going to mount.
rc.inet2.diff (download rc.inet2.diff.gz):
In order to apply the above patch, do the following as root:
Do not forget to manually edit your newly patched file to replace “<known up host, or remote filesystem server>” with a valid hostname or IP address.
By default, USB support does not work when installing VirtualBox PUEL on a Slackware host. Essentially it is a permissions issue. There are a number of ways around it, but the simplest is this ridiculously small change to rc.S.
rc.S (downloadable rc.S.diff.gz):
This patch effectively changes the automatic permissions on USB devices so that the group owner is the plugdev group and so the group owner has write permissions. Make sure any users in the vboxusers group are also in the plugdev group… but you knew that.
In order to apply the above patch, do the following as root:
Or just make the change by hand, given how small it is.
As per the release announcement Slackware 13.1 has been released. Unfortunately I have to report I am less than happy with the 2.6.33.4 kernel with which it comes. I have come across too many bugs over too short a period of time to be able to trust this kernel with production servers; and this is a huge shame. Usually the only OS I’m truly happy to trust for my production servers is Slackware. It has always been simple, stable and secure. Unfortunately stable is just not the right word for 13.1. It feels rushed. It’s just not quite ready. If anything it feels like 13.1 is a running snapshot of -current rather than an end result. Pat has been tracking KDE SC and other software pretty closely putting the latest releases into -current as soon as possible and the current selection doesn’t feel like a well-tested stable collection, but just an arbitrary snapshot in time.
To be fair, most of the software in 13.1 is working pretty well without fault. Certainly I’m not aware of any specific complaints with the latest KDE SC, but the kernel is another matter. The 2.6.33.4 kernel has some major problems. There’s a bug between the versions of LVM and DRBD that causes massive data corruption. There’s a bug in LVM startup scanning that stops some LVM devices from being properly configured. There’s new ACPI bugs. All of these being major problems for production systems.
In practice this means that all my production stuff is halted at Slackware 13.0 which is pretty rock-solid. I really truly hope that Pat is planning to run a 13.2 in a few months and more than that I hope he doesn’t bow to any pressure to release anything prematurely. To give an indication of what I mean, it took just two weeks for Slackware 13.1 beta1 to go through rc1 and rc2 all the way to full release and in the melee it appears Pat forgot to update the README files in usb-and-pxe-installers.
Also, to clarify my concerns about the kernel, there are a number of features in 2.6.33 that people have been asking for but it is brand-spanking new and will only be supported for 6 months or so. Pat missed a golden opportunity to release 13.1 with the 2.6.32 kernel which is very stable and well tested and will be supported for between 2 and 3 years because it has been designated for long term support.
Could the people who really wanted a 2.6.33 kernel not have upgraded to it on their own without taking the whole stable Slackware release with them?
I can only hope for my own sake that 2.6.34 (or at least 35 or 36) proves itself rock solid so that I will be able to upgrade the servers that matter but still have a kernel I can trust.
Basic, but not obvious if you haven’t done it before.
Firstly, there are two options, the open source driver and the proprietary driver. Many people use the open source driver, I prefer to not. NVidia made the GPU, why not use their driver as it’s most likely to be the best performing option (and allows for VDPAU too). So that’s what these instructions are for.
Now that you’ve picked the proprietary driver, there are two more options; you can either use the installer provided by NVidia, or use the nvidia-driver and nvidia-kernel SlackBuilds provided by Heinz Wiesinger. Personally I use the NVidia-provided installer for a few reasons:
That said I have the utmost respect for Heinz’s SlackBuild and recommend you consider it as an option depending on your needs, especially if you are playing with different setups rather than just doing a one-time install on a box for which you know exactly what you need.
So, off we go..
Firstly, read my post about the nouveau kernel module: slackware-current and nvidia
Option 1: NVidia Installer
Then go to http://www.nvidia.co.uk/Download/index.aspx and get the latest driver for your architecture. Right now, for me, this would be:
Then head to tty6 (Ctrl-Alt-F6), login as root, drop to runlevel 3, make the installer executable and then run it:
Go through the installer with all defaults. If you are on Slackware64 with multilb (as so many are) say yes when it asks if you want the 32bit compatibility bits.
Once it’s done, you should find yourself with a new xorg config in /etc/X11/xorg.conf; but don’t start X back up just yet, you need to strip some lines out of the xorg.conf so as not to confuse X. In Slackware 13.0+, xorg takes its information about your input devices from HAL (see Slackware 13.0 – Xorg + Hal). NVidia doesn’t acknowledge this and adds default entries in the xorg.conf it creates for a mouse and a keyboard.
Here is a default xorg.conf created by the NVidia installer (this is an example, don’t just copy and paste.. do what I tell you to with YOUR copy):
And here’s what you need to make it look like by stripping out the input parts:
Of all of that the absolute minimum you need is:
But I recommend keeping the other bits that NVidia provide because if you use nvidia-settings later to specifically adjust your config, there may be a number of options it sets and the xorg.conf it will generate will include these anyway. So just take what NVidia give you and strip out the input devices as above.
Option 2: SlackBuilds
Install nvidia-driver and nvidia-kernel. I recommend doing so with sbopkg.
Then create yourself a valid xorg.conf. If you’re not sure how, then you won’t go far wrong with using the default NVidia-created xorg.conf from above.
Finally…
Once you’re done, you can start X back up, either by issuing “startx” at the command line, or re-entering runlevel 4 with “init 4″.
Now that you are back in X you should have fully functional DRI and compositing.
If you have a non-standard setup such as multiple-monitors or you need to boost the gamma on a bad monitor or something like that, then you need to configure the driver to do what you want. This is done very simply with the NVidia configuration tool:
Play with the settings however you need, but remember that this is not Windows. Clicking “Apply” will apply the settings for this session only. If you want the changes to be permanent you must save the settings to a new xorg.conf. Since you’re not running X as root because you’re not an idiot, you will likely not have permissions to overwrite the xorg.conf. There are ways around this, but the simple way is to just save the new xorg.conf in your home directory and move it to /etc/X11 manually (remembering to back up your working copy first).
And that’s it. Go enjoy your new graphics driver and, if your GPU supports VPDAU, go get the VDPAU-enabled MPlayer too.
Have fun!
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.
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:
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:
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/
Recent Comments