NVIDIA driver, libglx.so and hardware acceleration crashing X server

My users on CentOS complained that Firefox would crash the X server after I updated the package xorg-x11-server-Xorg.

A search returned suggestions to disable hardware acceleration in Firefox. However a user mentioned that when he reinstalled the NVIDIA driver, it gave the warning libglx.so is not a symbolic link before setting things right.

An investigation showed that the NVIDIA installer replaces the file /usr/lib64/xorg/modules/extensions/libglx.so with a symlink to /usr/lib64/xorg/modules/extensions/libglx.so.X.Y where X.Y is the NVIDIA package version. So every time the xorg-x11-server-Xorg package is reinstalled, it replaces the symlink and hardware acceleration fails, crashing the X server.

The same problem for Debian is documented in this forum thread.

I could blacklist xorg-x11-server-Xorg in yum but I rather not do that. Since I may forget when an update of that package happens, I wrote a shell script to restore the symlink if removed and a cron job to call it periodically. But I'm also looking to make a Puppet stanza to do this.

Apache won't start on CentOS 5 because self-signed certificate used by mod_nss expired

You are not likely to hit this error with the usual configuration since mod_ssl is the one normally used. However mod_nss is used by the Fedora Directory Server (aka 389 Directory Server now) in CentOS for the console for LDAP authentication (centos-idm-console). Possibly also used by RHEL.

One day I found that Apache would not start. The error log indicated that the certificate had expired. I searched and searched for how to generate a new certificate and tried various things. Too many steps and too hard.

Then I had an idea. The certificate must have been generated when the package mod_nss was installed. Let's try reinstalling it. First we move the old database directory out of the way:

mv /etc/httpd/alias /etc/httpd/alias.old

Then reinstall mod_nss:

yum reinstall mod_nss

and voila, after a while, a new database with a fresh certificate was generated and I could start Apache.

CentOS/RHEL: dig axfr works but zone transfer fails?

I set up named as a secondary with a stanza like this:

zone "example.com" IN {
        type slave;
        masters { 10.0.0.1; };
        file "example.com.zone";
        notify yes;
};

When I restarted named the log messages in /var/log/messages told me that the transfer failed. However I could do:

dig @10.0.0.1 axfr example.com

just fine. What was the problem?

Looking in /var/named/chroot/var/named I saw that there was a directory named slaves. Should I be using that? Looking at the permissions, I saw:

total 88
drwxr-x--- 4 root  named 4096 Jan  7  2013 .
drwxr-x--- 6 root  named 4096 Jan  7  2013 ..
drwxrwx--- 2 named named 4096 Mar  4 23:23 data
-rw-r----- 1 root  named  208 Apr 28  2005 localdomain.zone
-rw-r----- 1 root  named  195 Apr 28  2005 localhost.zone
-rw-r----- 1 root  named  427 Apr 28  2005 named.broadcast
-rw-r----- 1 root  named  424 Apr 28  2005 named.ip6.local
-rw-r----- 1 root  named  426 Apr 28  2005 named.local
-rw-r----- 1 root  named 1892 Feb 26  2008 named.root
-rw-r----- 1 root  named  427 Apr 28  2005 named.zero
drwxrwx--- 2 named named 4096 Mar  5 00:59 slaves

Yes, I bet I'm supposed to use the directory slaves because that's writable by named but the top zone directory isn't, so I changed the line in the stanza to:

        file "slaves/example.com.zone";

and it worked.

You may see advice on the Web to change permissions of the top zone directory. Don't do that. Work with the structure and permissions that the distribution makers have developed.

enable ext4 for RHEL/Centos 5.6+ installs

This tip doesn't get enough publicity so I'm repeating it here:

Installing on ext4

Note the limitation on boot filesystems. I used it for the /home filesystem for better performance.

And if you forget during install time, you can still convert ext3 to ext4 afterwards, a search will find you many pages on how to do this.

Building openconnect for RHEL 5

This blog entry is of historical interest now. If you just want openconnect ready to run for RHEL/CentOS/clones, you can get openconnect 4.0 from EPEL now, thanks to David Woodhouse. (2012-07-26)

Openconnect is an open source client that can connect to Cisco's AnyConnect SSL VPN. There are packages for Fedora but none for RHEL 5. I needed one (actually for CentOS 5) so I set myself the task of building it from the latest Fedora 18 source RPM.


First of all install mock from the EPEL repo. You will need to track down the latest version of Mock 1.0, as Mock 1.1 has Python 2.5 constructs which won't work on RHEL 5.


You can't just do a mock rebuild right away. The Fedora SRPM has an MD5 sum which causes an error when extracting on RHEL 5. In any case we need to make some edits to the spec file. So first extract the Fedora 18 openconnect SRPM in the standard RHEL area, /usr/src/redhat:


rpm -i --nomd5 openconnect-...src.rpm


Now edit the spec file and remove the dependency on libproxy and change vpnc-script to vpnc. Also change the openssl dependency to the latest available for RHEL 5. RedHat keeps the version number the same while backporting fixes so it's ok that the required version decreases.


Create a new SRPM with


rpmbuild -bs openconnect.spec


Do the mock build on the new SRPM


mock openconnect-...src.rpm


You will encounter missing dependencies, so use tell mock to install those in the fakeroot and try again. Eventually you will get a binary RPM in /var/lib/mock/epel-5-x86_64/result (i386 for 32-bit of course).


Unfortunately the associated NetworkManager-openconnect cannot be ported to RHEL 5 due to requiring higher versions of X libraries. However it isn't too unfriendly to run openconnect from the command line (with root privilege, as it configures a TUN device):


openconnect ip_address_of_gateway


and it will prompt you for the username and password. You may want to look at command line options of openconnect to see what else is needed.


Probably the best you can do to make it user friendly is to use sudo to run it, and then create a GNOME or KDE launcher to run a terminal running it.