March 20, 2003

CVS woes

So I’m working on adding a vadddomain and vdeldomain to my postfix-virtual-tools package. Last night I got a hard-on to put the stuff in a CVS repository, mostly to keep a backup of it and see when a change I’ve made fucked something up. Maybe I also remembered that I had thought it a good idea to start stuffing stuff in CVS to try and keep it all in one place. I could stuff some little scripts in CVS and pull them out when I needed them later, perhaps. It helped last night when I remembered that you could do CVS over SSH, which meant I didn’t have to set up pserver or anything like that. I just did a cvs init on one box I use, made sure I had my SSH proxy authentication working, and set CVS_RSH=ssh and CVS_ROOT=:ext:some.box:/home/darkness/cvsroot, and I was off to the races. (It’s just that simple.)

Anyway, working well last night, had a little postfix-virtual-tools package going, had a cute lil’ Makefile that does some fucked up shit, etc. Today I make vadddomain and vdeldomain, then I go to check in to CVS after I think I’ve tested enough, and I get (text wrapped by me): 

cvs: error while loading shared libraries:
libgssapi_krb5.so.2: cannot open shared object file:
No such file or directory

WTF? Obviously something APT updated didn’t work quite right. Now, the first thing I think of is my poor APT repository’s full drive: 

Filesystem           1k-blocks      Used Available Use% Mounted on
/dev/hda12            30723336  30588504    134832 100% /srv

Oops. However, my apt-build script exited normally, and last time the disk actually filled up rsync hung around. This leads me to think that perhaps the disk isn’t quite full yet, or even if it is that perhaps this isn’t the problem. Plus, I don’t think APT would upgrade packages if it couldn’t satisfy dependencies — such as when a package was left out because it wouldn’t fit on disk.

As it turns out, the output of ldd `which cvs` was very pretty: 

[darkness@gateway rpms]$ !ldd
ldd `which cvs`
        libz.so.1 => /usr/lib/libz.so.1 (0x40018000)
        libcrypt.so.1 => /lib/libcrypt.so.1 (0x40027000)
        libgssapi_krb5.so.2 => not found
        libresolv.so.2 => /lib/libresolv.so.2 (0x40054000)
        libkrb4.so.2 => not found
        libdes425.so.3 => not found
        libk5crypto.so.3 => not found
        libcom_err.so.3 => not found
        libc.so.6 => /lib/libc.so.6 (0x40067000)
        /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
        libkrb5.so.3 => not found

Anyone notice a trend? All these libs look like Kerberos libs. RPM, any help? 

[darkness@gateway rpms]$ rpm -qla | grep libgssapi_krb5
/usr/kerberos/lib/libgssapi_krb5.so.2.2
[darkness@gateway rpms]$ ls -al /usr/kerberos/lib/*gssapi*
lrwxrwxrwx    1 root     root           21 Feb 27 13:34 /usr/kerberos/lib/libgssapi_krb5.so.2 -> libgssapi_krb5.so.2.2
-rwxr-xr-x    1 root     root        91685 Jan 23 20:11 /usr/kerberos/lib/libgssapi_krb5.so.2.2

Looks like we have a winner — but wait: 

[darkness@gateway rpms]$ sudo ldconfig -v | grep -i gss
[darkness@gateway rpms]$

So lets add /usr/kerberos/lib to /etc/ld.so.conf and see what happens, mmkay? 

[darkness@gateway rpms]$ sudo ldconfig -v | grep -i gss
        libgssrpc.so.3 -> libgssrpc.so.3.0
        libgssapi_krb5.so.2 -> libgssapi_krb5.so.2.2
[darkness@gateway rpms]$ ldd `which cvs`
        libz.so.1 => /usr/lib/libz.so.1 (0x40019000)
        libcrypt.so.1 => /lib/libcrypt.so.1 (0x40028000)
        libgssapi_krb5.so.2 => /usr/kerberos/lib/libgssapi_krb5.so.2 (0x40055000)
        libresolv.so.2 => /lib/libresolv.so.2 (0x40068000)
        libkrb4.so.2 => /usr/kerberos/lib/libkrb4.so.2 (0x4007a000)
        libdes425.so.3 => /usr/kerberos/lib/libdes425.so.3 (0x4008f000)
        libk5crypto.so.3 => /usr/kerberos/lib/libk5crypto.so.3 (0x40093000)
        libcom_err.so.3 => /usr/kerberos/lib/libcom_err.so.3 (0x400a4000)
        libc.so.6 => /lib/libc.so.6 (0x400a6000)
        libkrb5.so.3 => /usr/kerberos/lib/libkrb5.so.3 (0x401e3000)
        /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)

Looks much better to me. How the fuck did that directory ever get out of /etc/ld.so.conf, assuming it was in there to start with? And… how did I manage to get two different versions of glibc-utils installed? (I found this when running apt-get -f install to make sure I wasn’t losing my mind.)

You know… remember that file server I built a month or two ago? Remember how I put Kerberos everywhere? I wonder… 

[darkness@darkbook darkness]$ ssh root@the.kerberos.box
root@the.kerberos.box's password: 
Permission denied, please try again.
root@the.kerberos.box's password: 
Received disconnect from 192.168.666.666: 2: Too many authentication failures for root

Well lookie there. I suspect things are highly fucked on that side of the hub. Lets go console and hope we can log in.

At this point darky has dropped dead. This is very bad. I hope to be able to explain later.

No comments | | Permalink