Skip to content

Could not lchown() symlink

Did I mention that I like rsnapshot very much? Well, I do, but this particular installation is giving me the heebeegeebees:
  WARNING: Could not lchown() symlink "/foo/some/symlink"
Apparently my Perl installation does not have the Lchown module, hence the messages. Well, I switched from SunFreeware to OpenCSW, but rsnapshot is using /usr/bin/perl anyway and rsnapshot itself is from a current GIT checkout, so why are these messages coming up just now? The cure for this is to install Lchown from CPAN - unfortunately, this does not went so well, and we have a lot of CPAN surgery ahead just to get Lchown working (again?):
  CPAN.pm: Going to build N/NC/NCLEATON/Lchown-1.00.tar.gz

Checking if your kit is complete...
Looks good
Writing Makefile for Lchown
cp Lchown.pm blib/lib/Lchown.pm
/usr/bin/perl /usr/perl5/5.8.4/lib/ExtUtils/xsubpp -typemap /usr/perl5/5.8.4/lib/ExtUtils/typemap \
                   Lchown.xs > Lchown.xsc && mv Lchown.xsc Lchown.c
cc -c  -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -xarch=v8 -D_TS_ERRNO -xO3 \
         -xspace -xildoff    -DVERSION=\"1.00\"  -DXS_VERSION=\"1.00\" -KPIC \
         "-I/usr/perl5/5.8.4/lib/sun4-solaris-64int/CORE"   Lchown.c
sh: cc: not found
*** Error code 1
Well, we could edit Config.pm, but this stock Perl-5.8 installation from Solaris10 does not seem to have this file. The OpenCSW version was no better, forcing it to compile with gcc did not succeed either, as expected:
[...]
gcc -c   -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -xarch=v8 -D_TS_ERRNO \
           -xO3 -xspace -xildoff    -DVERSION=\"1.00\"  -DXS_VERSION=\"1.00\" -KPIC \
           "-I/usr/perl5/5.8.4/lib/sun4-solaris-64int/CORE"   Lchown.c
gcc: unrecognized option `-KPIC'
gcc: language ildoff not recognized
gcc: Lchown.c: linker input file unused because linking not done
So I went a different direction:
$ wget http://rsnapshot.org/downloads/extras/Lchown-1.00.tar.gz -O - | gzip -dc | tar -xf -
$ cd Lchown-1.00
$ perl Makefile.PL 
Checking if your kit is complete...
Looks good
Writing Makefile for Lchown
$ cat ../Lchown.diff
--- Lchown-1.00/Makefile        Mon Aug 31 22:03:58 2009
+++ Lchown-1.00.edited/Makefile Mon Aug 31 22:02:06 2009
@@ -23,12 +23,12 @@
 
 # They may have been overridden via Makefile.PL or on the command line
 AR = ar
-CC = cc
-CCCDLFLAGS = -KPIC
+CC = gcc
+CCCDLFLAGS = -fPIC
 CCDLFLAGS = -R /usr/perl5/5.8.4/lib/sun4-solaris-64int/CORE
 DLEXT = so
 DLSRC = dl_dlopen.xs
-LD = cc
+LD = gcc
 LDDLFLAGS = -G
 LDFLAGS = 
 LIBC = /lib/libc.so
@@ -254,8 +254,8 @@
 
 # --- MakeMaker cflags section:
 
-CCFLAGS = -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -xarch=v8 -D_TS_ERRNO
-OPTIMIZE = -xO3 -xspace -xildoff
+CCFLAGS = -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_TS_ERRNO
+OPTIMIZE = -O2
 PERLTYPE = 
 MPOLLUTE = 

$ gpatch < ../Lchown.diff
$ make
$ sudo make install
Running rsnapshot again, the errors are gone now, heh!

rpc.statd: recv_rply: can't decode RPC message!

Apparently, this one bugged me before and then it just disappeared. Now it's back and the logs get filled again with:
Aug 30 01:54:08 bogon rpc.statd[3423]: recv_rply: can't decode RPC message!
Aug 30 01:54:39 bogon rpc.statd[3423]: recv_rply: can't decode RPC message!
Aug 30 01:55:10 bogon rpc.statd[3423]: recv_rply: can't decode RPC message!
Aug 30 01:55:41 bogon rpc.statd[3423]: recv_rply: can't decode RPC message!
Aug 30 01:56:12 bogon rpc.statd[3423]: recv_rply: can't decode RPC message!
Again, not really flooding, but still annoying. While I still fail to see *which* message cannot be decoded, CentOS found a cure for this one. From looking at the diff, it seems rpc.statd is started too early (perhaps before the portmapper?). Well, restarting rpc.statd was enough to stop these messages for now - let's see if they show up again after the next reboot...

mdadm b0rked

Oh, the joys of Debian/unstable: a few days ago, udev was being upgraded - and introduced a conflict with mdadm. Unfortunately, it did not set the usual Conflicts: tag, so one has to go to the changelog to find a pretty terse comment:
     * New upstream release.
     + vol_id and libvolume_id have been removed. (Closes: #500883, #534765)
       Breaks: dmsetup (<< 2.02.51-1), mdadm (<< 3.0-3)
The real story however is told in #541884:
The next udev upload will not contain the vol_id program anymore, since
it was removed by the upstream maintainer in May, and will declare a
Breaks relationship with the current version of your package.

You need to update the rules file in your package to use:
   /sbin/blkid -o udev -p ...
instead of:
  vol_id --export ...
Your package will need to depend on util-linux >> 2.16.
Well, I won't blame them for ripping things apart, that's what unstable is for. In fact, I'd wish they'd do this more often to get rid of old packages. But a Conflicts: tag would have been nice too :-\

Update: the new udev package sets another tag called Breaks instead of Conflicts. Wow, I think I've never seen a Breaks: tag before.

stripped down opensolaris

OpenSolaris still only comes as a Live CD and can't be installed without a GUI, at least AFAIK. Well, I managed to boot the CD into cmdline mode, then started sshd to be able to login from a remote box - only to start the GUI installation again via X11 forwarding :-\
So, here are a few things I did to start a minimal OpenSolaris system and a few other things I always have to look for after another installation procedure - yes, the memory upgrade for my brain is already ordered.
$ svcadm disable gdm ppd-cache-update desktop-mime-cache mime-types-cache ogl-select \
                 gconf-cache input-method-cache pixbuf-loaders-installer fc-cache \
                 icon-cache pkg/update stosreg dbus hal autofs dns/multicast intrd \
                 rmvolmgr avahi-bridge-dsd name-service-cache routing/ndp
$ cat /etc/hostname.xnf0 /etc/defaultrouter /etc/nodename
192.168.10.12
192.168.10.1
foo
$ svcadm disable svc:/network/physical:nwam
$ svcadm enable svc:/network/physical:nwam
$ cp /etc/nsswitch.dns /etc/nsswitch.conf
$ cat /etc/inet/ntp.conf 
server de.pool.ntp.org
server europe.pool.ntp.org
server 2.pool.ntp.org
$ svcadm enable svc:/network/ntp
$ rolemod -K type=normal root
Now booting takes only 105 seconds on this box - heh, we just saved 5 seconds! :-)
$ grep -v ^\# /rpool/boot/grub/menu.lst 
timeout 30
default 0
title opensolaris
findroot (pool_rpool,0,a)
bootfs rpool/ROOT/opensolaris
kernel$ /platform/i86pc/kernel/$ISADIR/unix -B $ZFS-BOOTFS,console=tty -v
module$ /platform/i86pc/$ISADIR/boot_archive

$ cat ~/.bash_profile 
export HISTSIZE=9000
export HISTTIMEFORMAT='%F %T '
export GREP_OPTIONS='--color=tty'
export EDITOR=vi
export PAGER=less

alias la='ls -lah'
alias locate='slocate'
Oh, and as a bonus, although totally unrelated to this article: check out this package manger cheatsheet - how often I have needed that ("How do I do 'dpkg -S' with RPM? Or pkg?"). Thanks, nakedape!

pgrep -u

I love proctools, they're so very handy and they're almost always available on Solaris and sometimes on Linux too. On MacOS you have MacPorts, but there's this annoying bug that will match all processes when -u or -U is used. Unfortunately, proctools development seems to be stalled, so we will have to fix this ourselves...or live with it :-\

Warning: No xauth data; using fake authentication data for X11 forwarding.

When connecting to remote hosts via Terminal.app in MacOS X, I always get this annoying warning. X11 forwarding is working though ($DISPLAY is set, even I'm not in a real xterm), I only wanted to get rid of this message:
$ ssh bob /bin/true
Warning: No xauth data; using fake authentication data for X11 forwarding.

$ xauth generate $DISPLAY .
xauth:  creating new authority file /Users/alice/.Xauthority
$ ssh bob /bin/true
$ 

syslog-ng & MacOS X

MacOS X still ships with good ol' syslogd which may suffice for most of us but I still prefer syslog-ng. Luckily MacPorts ships syslog-ng - unfortunately compilation fails with:
ranlib: file: libsyslog-ng.a(afsql.o) has no symbols
ranlib libsyslog-ng.a
ranlib: file: libsyslog-ng.a(afsql.o) has no symbols
if /usr/bin/gcc-4.0 -DHAVE_CONFIG_H -I. -I. -I..  \
  -I/opt/local/include \
  -I/opt/local/include/glib-2.0 -I/opt/local/lib/glib-2.0/include \
  -I/opt/local/include   -I/opt/local/include/eventlog \
  -DHAVE_SOCKADDR_SA_LEN -DLIBNET_BSDISH_OS \
  -DLIBNET_BSD_BYTE_SWAP  -D_GNU_SOURCE \
  -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 \
  -O2 -Wall -MT main.o -MD -MP -MF ".deps/main.Tpo" \
  -c -o main.o main.c; \
        then mv -f ".deps/main.Tpo" ".deps/main.Po"; \
  else rm -f ".deps/main.Tpo"; exit 1; fi
/usr/bin/gcc-4.0  -O2 -Wall  -L/opt/local/lib -o syslog-ng \
    main.o libsyslog-ng.a -lresolv  -lfl -L/opt/local/lib \
   -lglib-2.0 -lintl -liconv   -L/opt/local/lib -levtlog   -lnet \
   -lwrap 
Undefined symbols:
  "_configuration", referenced from:
      _configuration$non_lazy_ptr in libsyslog-ng.a(cfg.o)
      _configuration$non_lazy_ptr in libsyslog-ng.a(cfg-grammar.o)
ld: symbol(s) not found
collect2: ld returned 1 exit status

The compilation will succeed when we specify globals.o explicitly on the command line, but I wanted to take this opportunity to try a newer version of syslog-ng, the MacPorts way:
$ mkdir -p ~/.ports/sysutils/syslog-ng
$ cd ~/.ports
$ cp $macports/release/ports/sysutils/syslog-ng/Portfile sysutils/syslog-ng/
$ egrep '^version|master_sites|checksums' sysutils/syslog-ng/Portfile 
version           3.0.4
master_sites   http://www.balabit.com/downloads/files/syslog-ng/sources/3.0.4/source/
checksums      md5 86c39779261545d2289e9c309e262b8d
$ portindex
$ port clean --all syslog-ng
$ port install syslog-ng
Well, even the latest version will fail, so we fix it ourselves:
$ cd sysutils/syslog-ng/work/syslog-ng-3.0.4/src/
$ gcc  -O2 -Wall  -L/opt/local/lib -o syslog-ng globals.o main.o \
       libsyslog-ng.a -lfl -L/opt/local/lib -lglib-2.0 -lintl -liconv \
       -L/opt/local/lib -levtlog -L/opt/local/lib -lssl -lcrypto \
       -lz  -lz -lnet -lwrap  -lresolv
$ cd -
$ port install syslog-ng

The MacPorts install provides a hint how to (disable Apple's syslogd and) enable syslog-ng:
$ launchctl unload -w /System/Library/LaunchDaemons/com.apple.syslogd.plist
$ launchctl load   -w /Library/LaunchDaemons/org.macports.syslog-ng.plist
However, when doing this, syslog-ng is started over and over again, as if launchd doesn't recognize it as "already running" and respawns it all the time. No good :(

Designed in California...

...but assembled in (and shipped from) Shanghai, CN - a shiny new 13" MPB. Here are just a few things I've come across during the setup routines:

  • Installing rEFIt wasn't so easy this time: the graphical installer completes, but no rEFIt does not show up during the next boot. The trick was to manually execute enable-always.sh.Minor nitpick: rEFIt still does not show any inserted CDs during bootup, so I still have to press "C" to boot up a CD. This seems to be known issue though.

  • Neither Jaunty (2.6.28) nor Karmic (2.6.31-rc5) are able to reboot the machine. poweroff is working, but reboot just hangs when it prints "restarting system". Even sysrq-b wouldn't help. Grrr.

  • very important: replace login window background image in MacOS X: sudo defaults write /Library/Preferences/com.apple.loginwindow DesktopPicture '/path/to/picture.jpg' :-)

  • Strange, MacOS X makes heavy use of xattr but the rsync version that comes with 10.5 still has no support for xattrs. Fortunately there's a more current version on macports, now we can even backup all the attributes.

  • Oh, did I mention that I really dislike this crappy nvidia 9400M graphic chip? I mean, I was expecting that it'll piss me off - now the madness begins again, with crappy binary drivers and gluecode, and breaking video every time a new kernel is built, oh...how I did not miss those times :-\

  • extra geek points for enabling verbose booting with sudo nvram boot-args="-v"

  • To enable daily updates of the locate database, simply copy /etc/periodic/weekly/310.locate into the daily directory. Oh yes, there's Spotlight of course...not my cup of tea though.
  • rsnapshot & cmd_preexec

    Even today with block-based snapshotting filesystems getting more and more popular, they're just not the thing I'm looking for when 1) backing up different filesystems and 2) backing up to a remote host, thousands of miles away. My weapon of choice to tackle this one is still rsnapsot - fairly portable (needs only perl, rsync, probably ssh) and does incremental backups via hardlinks if possible, so it's quite space efficient.

    Minor nitpick: rsnapshot has this cmd_preexec parameter and I thought I could use this to (re)mount the target partition rw - turns out this is not how it's supposed to work, but this task can easily handed over to a wrapper script, which you're probably using anyway when backing up lots of machines.