SysAdmin Adventures

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:

1. The latest driver is always available (if not necessarily stable) whereas the SlackBuild can be behind due to workload or because it’s been held back intentionally for stability/compatibility.
2. As with kernels, I never find the need to uninstall NVidia drivers, except with the installer when upgrading to a new one, so the usefulness of having a package is lessened.
3. I started with the NVidia installer many moons ago and never found enough reason to change my habits.
4. I’m too lazy to keep a copy of the xorg.conf handy and the NVidia installer creates one for me.

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!

For those hoping to update to slackware-current (2.6.33.1) and make use of alienBOB’s KDE SC 4.4.2 with PolicyKit packages, you need to be aware of one caveat. If you use the proprietary NVidia driver, you will need to blacklist the nouveau driver in order for it to work.

/etc/modprobe.d/nouveau.conf

UPDATE: 20100428
A package has been added to slackware-current to do this for you:
x/xf86-video-nouveau-blacklist-noarch-1.txz

Very simple problem:
When connecting to an SSH server outside your localnet when you are behind NAT, no matter what you try the session always times out after about 5 minutes of inactivity.

Very simple solution:
/etc/ssh/ssh_config or ~/.ssh/config :

Alternatively you can specify it on the command line:

I don’t know why it took me so long to stumble upon this one. I had tried everything I could think of including TCP keepalives and ClientAliveInterval settings on the server and it just wouldn’t prevent the session timing out even though they really ought to. The solution that definitely works is to set ServerAliveInterval in the client config.

This is a the text of a support case I have just raised with Symantec regarding administration of NetBackup Server 7.0:

Support has been dropped for 32-bit Linux clients. I appreciate that NetBackup Server will still work with v6.5 on 32-bit Linux hosts.

However, the java client for administering the NetBackup Server installation is not a 64-bit application, it works regardless of the environment so long as a valid JRE is available. However, the way it is distributed is such that it cannot be installed on a 32-bit Linux machine and I do not see why.

I do my daily work from a 32-bit Linux machine. This machine is not a backup client nor does it need to be. All I need is to be able to administer the NetBackup server. Up to now I have been having to remotely access the NetBackup server and send the display back to the X server on my 32-bit machine in order to administer the server. This isn’t really an acceptable solution.

Obviously, the first thing I did was to try the java administration client that comes with NetBackup v6.5, however much to my amusement, the 6.5 client refuses to speak to the 7.0 server.

This leaves me only with the option to use the 7.0 Java client on a 32-bit Linux machine.

I cannot use the cp_to_client script as it detects the lack of an x86_64 environment and dies. I cannot use the extract_java script because it lacks a client environment to install into. I could screw around with these scripts to bypass the checks but it’s a waste of time considering how little the java client actually is and would leave me with 64-bit client software I neither want nor need and a 64-bit JRE.

Bottom line:

I installed the 6.5 client software, removed /usr/openv/java and manually extracted NB-Java.tar.gz over the top. To provide a JRE I successfully tested both the JRE that comes with 6.5 (1.4.2_13) and my own installed JRE (1.6.0_18) and both work flawlessly.

HOWEVER.. I first had to modify jnbSA (and jbpSA not that I use it) to remove the setting of the PLAT64FLAG=”-d64″ variable.

Having done so, the client works absolutley perfectly on my 32-Bit Linux machine just as I would expect it to, being a java application.

So, the question is.. why have you done this? I can understand, if not condone, your wish to kill multiple architecture support for the Server and Client software, but regardless of the platform the backups run on, the System Administrator needs to be able to administer the system from wherever he/she works.

Since you already have a working java admin client that works perfectly on pretty much anything with a JVM installed, why are you going to such lengths to prevent it from running on a 32-bit Linux machine?

In order to provide this ability all you need to do is ship a 32-bit JRE as well as the 64-bit JRE (or even just allow a user to specify the location of his own JRE if he has a 32-bit client) and provide an installer that will install it regardless of the platform or whether the backup client software is also installed.

I could personally knock such a thing up in about 10 minutes, would you be prepared to?

The response from Symantec support:

As you know, the Java GUI is provided as a bundle for Linux and is not separated out into its own install. Because of the limitation of x86_64 Linux servers only that they decided to place on the product, the install script includes a check for x64.

At this time, Symantec does not plan to release an x86 installer version of the Java GUI for Linux. As you know, this isn’t due to any limitation, but it’s due to a decision made by the developers. At this time, I do not believe any plans are in place to create an x86 installer package for the Java GUI on Linux, however we can help speed up the process. We have a community enhancement request page http://seer.entsupport.symantec.com/docs/318008.htm where enhancements can be voted on and pushed into the product faster. This site is monitored by the Product Managers. The more votes an enhancement gets, the faster it gets implemented.

Since the only way this little mess can get sorted out is to have customer support for it demonstrated through the Ideas portal, I have again created an Idea on the portal and would appreciate any interested parties voting up the idea to bring it to the attention of the product managers.

https://www-secure.symantec.com/connect/idea/provide-separate-java-gui-installer-linux-include-x86-support

My DRBD SlackBuild has been updated for 8.3.7 and split into two: drbd-tools and drbd-kernel.

They have been submitted to SlackBuilds.Org and are available there. They have been updated for proper Slackware64 compatibility and include notes regarding DRBD entering the Linux Kernel as of kernel 2.6.33.

TAKE NOTE:
Slackware{,64}-current has moved to kernel 2.6.33. DRBD’s kernel code is now part of the Linux kernel. You should not attempt to install drbd-kernel on a system with a 2.6.33 or later kernel. While it is technically possible, version 8.3.7 will not compile externally against 2.6.33. A fix is pending for the next release of DRBD but is nonetheless not required.

Users of Slackware{,64}-13.0 and earlier should use both packages.

DRBD v8.3.7 Kernel Module SlackBuild
DRBD v8.3.7 Userland Tools SlackBuild

Have you just updated your WordPress.com Stats plugin? Does your stats page no longer show the graph? Would you like to know why?

The reason is because the plugin now includes a .htaccess file (/plugins/stats/.htaccess) and the .htaccess file contains:

By default, in a reasonably secure setup, the .htaccess file does not have permission to specify an Allow directive. This really shouldn’t be a problem as it should just be ignored, but it seems that for some reason, the fact that the directive is not allowed causes apache to actively deny access instead even though it would work perfectly if the .htaccess file weren’t there at all. I don’t know why, it just does.

One solution would be to delete the .htaccess file, but I prefer not to adjust the plugin as a simple adjustment to the apache configuration will solve the problem. Apache needs to be told to allow the .htaccess file to specify an Allow directive using the AllowOverride directive in the main configuration.

Those who have implemented Permalinks will already have included:

All you need to do is extend it to include Limit as well:

You could achieve the same result with:

I heavily recommend against it as it has the potential to be a security threat.

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

This is a very simple thing, but it seems not widely known.

You login to, or start, X as a regular user as you rightly should, but you want to be able to su to root and then run a GUI application as root.

There are a number of ways to do this, some better than others, including using “kdesu”, “xhost” etc; the simplest however is:

… where xuser is the user you are running X as. The export line may not be required depending on how you became root.

The root shell you are in now has full authority to communicate with and manipulate X.

I am pleased to report my desktop is no longer Slackware-13.0, but is now Slackware-current and using KDE SC 4.4.0 as provided by alienBOB: http://alien.slackbook.org/blog/its-been-released-kde-sc-4-4-0/

I’m very pleased with the new KDE. With the exception of the polkit argument that’s going on every new release of KDE brings fresh delight, and I hope it never stops.

There’s one little thing it took me a short while to realise and so is worth mentioning here. I use “Desktop Grid” and “Present Windows” a lot and have them mapped to the top corners of the desktop for quick-access. After upgrading to KDE SC 4.4.0, my panel started disappearing whenever I used “Desktop Grid” and, while it’s not exactly a problem, it doesn’t look very good. The panel always disappears in “Present Windows” but that is expected behaviour.

The reason I discovered is that “Desktop Grid” now includes a per-desktop “Present Windows” by default, so if you have multiple windows open in a desktop, they will be “Presented” within that desktop in the grid view, and for this reason the panel disappears. Some may like this feature, and I see how it could be very useful, but I don’t want it. As I have, you can turn it off:

System Settings -> Desktop -> Desktop Effects -> All Effects -> Desktop Grid (Configure)

Uncheck “Use Present Windows effect to layout the windows”.