Skip to main content

s9y dev

Enjoying s9y-dev, clicking on various links gave: Parse error: parse error, unexpected t_endif in ... This blogentry helped: setting the blog's style to something else than "Default-PHP" (like "Serendipity 3.0") made the errors go away.

having fun with mozilla plugins

Tracking development snapshots of Mozilla Firefox can be fun, especially when the thing almost always (sic!) behaves like a friggin' -final, which is a good thing. However, this means of course that plugins have to keep up with the pace set by this development, which is hardly possible for all available plugins. My favourite plugin, Flashblock, says: Works with: Firefox 1.4.1 – 3.0a7 But 3.0a8 is already out! Let's try something then:

# wget --no-check-certificate https://addons.mozilla.org/en-US/firefox/downloads/file/17855/flashblock__45_1.5.4.1__45_fx__43_fl.xpi # mkdir fb && cd fb && unzip ../flashblock* # sed -ie 's/3\.0a7/3.0a9/' install.rdf # zip -9r ../flashblock-1.5.4.1-fx+fl_3.0a9.xpi *
Now install this new .xpi - if we're lucky, that's all it took to change. If not, RTFS :-\

apt-get segfaults

While installing a box, it happened that apt-get would segfault upon upgrade or install. Suspecting memory issues first, we tried quite a few things, before coming across a blogentry: a corrupt pkgcache was to blame. One should simply remove it and start over again:

cd /var/cache/apt rm pkgcache.bin srcpkgcache.bin
Unfortunately, we didn't save the corrupt files, so we cannot even open a bug.

freshclam, you bastard!

For a while now freshclam kept barfing with:

# /usr/bin/freshclam -u clamav -v
ClamAV update process started at Fri Aug 31 18:42:55 2007
WARNING: Your ClamAV installation is OUTDATED!
WARNING: Local version: 0.90.1 Recommended version: 0.91.2
DON'T PANIC! Read http://www.clamav.net/support/faq
main.inc is up to date (version: 44, sigs: 133163, f-level: 20, builder: sven)
Downloading daily-4092.cdiff [100%]
Ignoring mirror 85.25.252.58 (too often connections with outdated version)
ERROR: getpatch: Can't download daily-4093.cdiff from db.de.clamav.net
Ignoring mirror 85.25.252.58 (too often connections with outdated version)
Trying host db.de.clamav.net (194.77.146.139)...
Downloading daily-4093.cdiff [100%]
Ignoring mirror 194.77.146.139 (too often connections with outdated version)
Since we're running Debian/stable, we won't receive any newer clamav version (without pinning and stuff), but the too often connections with outdated version is more serious, since our virus db could not be updated. Searching for this error turned up quite a few results, but nothing related to a particular debian bug. Finally I came accross bug# 606 which contains an actual fix for newer clamav versions and a workaround, for (debian/stable-)users like us:
# sed 's/^ScriptedUpdates.*/ScriptedUpdates no/' -i /etc/clamav/freshclam.conf
# freshclam -u clamav -v
....
# sed 's/^ScriptedUpdates.*/ScriptedUpdates yes/' -i /etc/clamav/freshclam.conf
Now the daily updates should work again. Read why this works.

Having more than one version of gcc

GCC 4.2 is out and already in Debian/unstable. While I'm keen to try out the latest and the greatest, I'd like to keep gcc-3.4 around, just in case some weird software cannot be compiled with gcc-4.x (btw, is gcc-2.95 really obsolete by now?). And I only want to have one gcc-4.x on my system - however, that's not yet possible, because various applications are depending on gcc-4.1.x.

OK, fine, I'm gonna have 3 different GCC versions on the box. Luckily Debian comes with update-alternatives and I finally came across a useful post in ubuntuforums.org describing how to actually use it:
$ old=4.1 new=4.2
$ update-alternatives --install /usr/bin/gcc gcc /usr/bin/gcc-${new} 60 \
                      --slave /usr/bin/cc   cc   /usr/bin/gcc-${new} \
                      --slave /usr/bin/cpp  cpp  /usr/bin/cpp-${new} \
                      --slave /usr/bin/gcov gcov /usr/bin/gcov-${new} \
                      --slave /usr/bin/g++  g++  /usr/bin/g++-${new}

$ update-alternatives --install /usr/bin/gcc gcc /usr/bin/gcc-${old} 40 \
                      --slave /usr/bin/cc   cc   /usr/bin/gcc-${old} \
                      --slave /usr/bin/cpp  cpp  /usr/bin/cpp-${old} \
                      --slave /usr/bin/gcov gcov /usr/bin/gcov-${old} \
                      --slave /usr/bin/g++  g++  /usr/bin/g++-${old}

$ update-alternatives --config gcc

There are 2 alternatives which provide `gcc'.

  Selection    Alternative
-----------------------------------------------
*+      1    /usr/bin/gcc-4.2
        2    /usr/bin/gcc-4.1

Press enter to keep the default[*], or type selection number: 1
Using `/usr/bin/gcc-4.2' to provide `gcc'.
Note: the '40' and '60' are priorities, which are explained in the manpage.

bcm43xx my ass!

grrr, I love this iBook but this airport thingy is a sick bastard:

# iwconfig eth1 mode managed essid camp07-foo nick camp07-foo key off enc off # dhclient eth1
...but all I got was:
ADDRCONF(NETDEV_UP): eth1: link is not ready SoftMAC: Authentication timed out with 00:0b:0e:56:d7:00
bcm43xx module and loaded it again - after this it worked instantly. Yeah I know, I should file a bug or better yet: send a patch....-ENOSKILL :-\ The good thing is that I'm lying in a hammock surrounded by trees, good music, fantastic visuals and kind h4x0rs...guess where I am :)

conntrack_ftp: partial 227

Today I came across the following message in the kernel's log: conntrack_ftp: partial 227 4048680485+13 Fortunately this link helped:

The FTP conntrack helper has found a partial matching when parsing a request to start a connection in passive mode (ie. needs missing information to track that connection, malformed packets,...). In that case such packet is silently drop[ped].

snippets from da brain

Wanna clone a debian installation real quick? Try:

# dpkg --get-selections \* > ~/dpkg.selections
# dpkg --set-selections < ~/dpkg.selections
# apt-get install dselect-upgrade
Or how about installing Fedora in 3 steps?
# rpm --root /fc7/ --initdb
# rpm --root /fc7/ -ivh --nodeps ftp://ftp-stud.fht-esslingen.de/Mirrors/\
fedora.redhat.com/linux/core/development/ppc/os/Fedora/fedora-release-*.noarch.rpm
# yum --installroot=/fc7/ -y groupinstall Base
(the latter is from Arnd Bergmann in <200703190134.26030.arnd@arndb.de>)

learning sth. new every day

You sure noticed that this is not a diary, more a monthly(?) if at all. But now I decided to move my irregular braindumps to this place, so I and you can find even more (un)interesting stuff. Today: samba! Having used samba since 1.9.18 or so, I thought I've come across every configuration option mentioned in the ever growing smb.conf. Of course I was wrong:

  • With socket address I can finally restrict nmbd to a single IP address, so it does not listen on every freaking interface.
  • Using load printers = no printing = bsd printcap name = /dev/null disable spoolss = yes gets rid of the annoying Unable to open printcap file /etc/printcap messages in the syslog when printing NOT via smb.
  • And finally I found some time to play around with socket options, I guess I'll go with

    socket options = SO_KEEPALIVE TCP_NODELAY IPTOS_LOWDELAY IPTOS_THROUGHPUT SO_SNDBUF=8192 SO_RCVBUF=8192

    for a while and see what it gives.
  • When mount.cifs is missing, cifs.ko might complain: CIFS VFS: cifs_mount failed w/return code = -22. See this irclog why this might be OR use an IP address for the hostname when mounting the share OR just install smbfs and be done with it.
  • testing xfs again with slightly more interesting results ;)

    Since my last benchmark with XFS was kinda stupid (testing 512 MB of data on a box with 1GB RAM), I tested again, this time with 4GB of data.

    • "Sequential output" and "random delete" seem to be higher with an external logdev set (here: l_logdevhda5_size67108864)
    • In other places the external log seem to slow down operations (well, the logdev (hda5) *is* slower that the devices the tests were run on, but I somehow thought the journal would fit into RAM anyway. Hm, OTOH a journal written to RAM makes no sense, does it?
    • adjusting "-b size" from 4096 to 512 during mkfs(8) does not seem to change much, except for "sequential output" (+1MB/s) and 'sequential delete' (twice as much deletes/s)
    • adjusting the "-l size" to 4MB decreased 'random deletes' (with 64MB it's twice as fast)
    The mountoptions do not seem to do much, but I really need to learn gnuplot(1) to generate nice graphs out of all these fine numbers....