...and Citrix puts "Xen" in every product they have since its XenSource acquisition. Boy, I searched for quite some time now (don't ask) for the Mac ICA client only to find out that it's now called XenApp Plug-in for Mac. A "plugin"? Funny, it installs like every other piece of software, I wonder where the plug-in part comes into play. And what if I don't connect to a XenServer? Will my computer explode? Sigh...
auto_rotateby its EXIF data but via the Rotate... buttons in the image details. However, these buttons are grayed out, with no reason given. Well, there's #3010 to
"Disable rotation radio buttons if 'auto_rotate' not set- but I don't remember to turn off
auto_rotate. Looking again at the config, I noticed that the
auto_rotatebutton is grayed out too - what's going on?
Turns out, ZenPhoto is missing the imagerotate() funcition in our GD build. Hm,
gdis provided by php5-gd and there we go:
> gd seems to build with an external gd library, > php5 has it's own gd library shipped with it. > One functions that isn't available when gd is build with an external lib > is ImageRotate();Well, the report is from 2005, now it's 2009 and this one has been tagged as
wontfix, for debatable reasons. Sure, there are workarounds available, but I wonder how the others are dealing with this particular issue...
WARNING: Could not lchown() symlink "/foo/some/symlink"Apparently my Perl installation does not have the
Lchownmodule, hence the messages. Well, I switched from SunFreeware to OpenCSW, but
/usr/bin/perlanyway 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 1Well, 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
gccdid 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 doneSo 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 installRunning
rsnapshotagain, the errors are gone now, heh!
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: recv_rply: can't decode RPC message! Aug 30 01:54:39 bogon rpc.statd: recv_rply: can't decode RPC message! Aug 30 01:55:10 bogon rpc.statd: recv_rply: can't decode RPC message! Aug 30 01:55:41 bogon rpc.statd: recv_rply: can't decode RPC message! Aug 30 01:56:12 bogon rpc.statd: 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.statdis started too early (perhaps before the portmapper?). Well, restarting
rpc.statdwas enough to stop these messages for now - let's see if they show up again after the next reboot...
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.
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
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 rootNow 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!
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 is used. Unfortunately, proctools development seems to be stalled, so we will have to fix this ourselves...or live with it :-\
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 $
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 statusThe 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-ngWell, 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-ngThe 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.plistHowever, when doing this,
syslog-ngis started over and over again, as if
launchddoesn't recognize it as "already running" and respawns it all the time. No good :(