Today I found my old Fujitsu Siemens Lifebook B in the cellar and wanted to play a bit with it. It's very small and handy (might be useful for certain tasks) and due to the recent hype on eeePCs, I need something small too The specs for this notebook aren't very cool, but the display is a bit larger than the eeePCs display and it has a touchscreen which is also very handy when properly configured.
The main problem with installing operating systems onto this device is that there's neither a CD-Rom drive nor a floppy drive available and due to the age of this system, it's not possible to boot from USB drives, so I chose to install Debian via PXE on this device.

There are plenty of howtos on the web about configuring a PXE/Bootp/DHCP combination to make this work but I always need to write such things down on my own for easier reference in the future, so here's the way to go:

1. Install a DHCP Server
   
   I chose "dhcp3-server" from Debian, so
   

   apt-get install dhcp3-server

   will do the trick. After installation, you need to configure it to allow booting from it. Besides the usual dhcp server configuration, you need to add the following configuration options:
   

     allow booting;
     allow bootp;
     class "pxeclients" {
       match if substring(option vendor-class-identifier, 0, 9) = "PXEClient";
       next-server 192.168.0.254;
       filename "/pxelinux.0";
     }
   

   (Assuming that 192.168.0.254 is the IP address of the host the TFTP server will reside and that pxelinux.0 is the pxe bootfile name of choice).
   
   
2. Install the TFTP Server
   
   I chose "tftpd-hpa" because it seems to have special features wrt PXE configurations, so

   apt-get install tftpd-hpa

   will install the software for you. Change "RUN_DAEMON" in /etc/default/tftpd-hpa from "No" to "Yes" and start this service using `/etc/init.d/tftpd-hpa start`.
   
   
3. Download the netboot files
   
   Download the latest netboot.tar.gz from http://ftp.nl.debian.org/debian/dists/etch/main/installer-i386/current/images/netboot/ into your tftpboot directory (for tftpd-hpa, it's usually set to /var/lib/tftpboot):
   

   cd /var/lib/tftpboot
   wget http://ftp.nl.debian.org/debian/dists/etch/main/installer-i386/current/images/netboot/netboot.tar.gz
   tar xf netboot.tar.gz

Make sure all the necessary services are started (dhcpd and tftpd) and try to bot your target system via PXE boot.

I hope I don't have forgotten some vital parts for this configuration and if so, feel free to leave a comment here.

Today I upgraded one of my customers ISVW5 for SMB installations to the new ISVW6 (namely ISVW_v6.02_7672_release.tar.gz). Of course - as always - Trendmicro doesn't officialy support Debian as host operating system and therefore you need to make some changes to your Debian system to make this combination work. I'll summarize the necessary changes here for your convenience but I don't know if it's a complete summary, by now, everything seems to work with the new version but there might be additional pitfalls I've not stumbled in by now, so if you experience troubles, please drop me a comment here or write me an e-mail and I'll have a look.

First of all, when upgrading from ISVW5 to ISVW6, make sure to either backup your ISVW5 configuration using the migration script or choose the upgrade method during the setup. Due to my paranoia I chose to manually backup the settings just to be sure in case the setup script wouldn't work - I suggest you do this too.

1. Download the ISVW6 archive
wget -q http://www.trendmicro.com/ftp/products/interscan/ISVW_v6.02_7672_release.tar.gz

2. Extract it
tar xf ISVW_v6.02_7672_release.tar.gz

3. Change to the newly created directory
cd isvw

4. Run the migration script to backup your current configuration
tool/isvw-migr5to6 -o /path/to/backup.conf

5. Verify that the configuration was exported successfully
tool/isvw-migr5to6 -v /path/to/backup.conf

Now, your current configuration should be safe and you might want to continue the installation process.

Before you do so, you should prepare some things. First of all, you should add the following library locations to your ldconfig configuration. On Debian, this is usually achieved by adding a file called "/etc/ld.so.conf.d/trendmicro.conf" with the following contents:

/opt/trend/isvw6/cmagent
/opt/trend/isvw6/http
/opt/trend/isvw6/main
/opt/trend/isvw6/scan
/opt/trend/isvw6/services
/opt/trend/isvw6/webui

This file can also be downloaded from here, check the links at the end of this article.
I recognized that ISVW installs some libraries also available on standard Debian systems into these directories, e.g. libgssapi_krb5.so.2 a.s.o, so you need to make sure that your system's libraries are used primarily on your system by adding the paths "/lib/" and "/usr/lib" at the beginning of "/etc/ld.so.conf".

As these directories aren't populated by now (ISVW6 has not been installed yet) it is pointless to run `ldconfig` now. The installer should do this automatically after the installation has finished.

Next, make sure the `awk` binary can be called by "/bin/awk" and the `basename` binary can be called by "/bin/basename". This was a tough one to find out, I had to dig through quite some `strace` output to get an idea about why my diskspace seems to be insufficient :-/
The webui uses the hardcoded path "/bin/awk" to parse the `df -P -k /opt/trend/isvw6` output to gain information about the free disk space on your machine. If /bin/awk is not available you cannot manage your ISVW installation through the webinterface and will receive the following error message in your webbrowser:

Unable to process the request. Insufficient disk space. Increase available disk space and try again.

Use the following command to make a symlink to Debian's default installation path:

ln -s /usr/bin/awk /bin/awk
ln -s /usr/bin/basename /bin/basename

After installation the startup script "/etc/init.d/isvw6" uses the `usleep` command to delay the startup of particular ISVW processes. Needless to say, `usleep` isn't available on Debian systems so you either need to rewrite /etc/init.d/isvw6 or create a usleep wrapper script. I decided to implement the latter because you never know whereelse they're using usleep, so here's an example of a simple usleep wrapper script that calls sleep with the re-calculated delay (copy this script to /bin/usleep and make it executable):

#!/bin/sh
# small usleep - sleep wrapper for Debian systems
# This tool needs "bc" installed
#
# by Alexander Griesser , 2008-02-10

if [  "$#" != "1" ]; then
  echo "usage: $(basename $0) time_in_usecs"
  exit 1
fi

sleep $(echo "scale=1; $1 / 1000000" | bc)

This script can be downloaded from here, check the links at the end of this article.

Now your system should be prepared and it is safe to run the setup script. Please follow the Getting Started Guide for detailed information about the installation procedure.

./setup.sh

After the installation completed successfully, stop the ISVW services, run `ldconfig` to make sure the library cache gets updated, apply a small patch to /etc/init.d/isvw6 to avoid warnings of deprecated `tail` usage and start the services again:

1. Stop ISVW6
/etc/init.d/isvw6 stop

2. Run ldconfig
ldconfig

3. Apply a small patch to /etc/init.d/isvw6
cd /tmp
wget -q http://tuxx-home.at/projects/isvw6/isvw6-deprecated-tail-usage.diff
cd /etc/init.d
patch < /tmp/isvw6-deprecated-tail-usage.diff

4. Start the services again now
/etc/init.d/isvw6 start

Everything should be fine now, have fun enjoying your ISVW6 installation on Debian :)

Downloads:

• usleep wrapper script
• trendmicro library configuration file
• iswv6-deprecated-tail-usage.diff

Well, back on track now. After two weeks of vacation I spent with my wife and my children, I'm back and available for business duties.
Of course, the first thing that has to be done is updating all my systems. There could have been milestones released during my abscense!!!1

On my notebook, I had to patch the binary fglrx driver so that it doesn't refuse to load in Xorg 1.3.0 (Yes, Debian finally changed the version numbering of Xorg which definetly breaks all binary-only drivers at once) with the help of the magic install-fglrx-debian.sh out of the Kanotix project. After that I had some troubles updating the fonts cache on my notebook (the error message was something like "failed to write cache" and came from the utility `fc-cache` during the configuration of the "ttf-opensymbol" package on my Debian lenny system. Fortunately, I found an article (forgot to bookmark the link, sorry) that suggested to simply `touch` all directories and files with error messages again because the cache directories might have bad timestamps (whatever "bad" means in this regard), so a simple

find /dir/that/has/problems -print0 | xargs -0 touch

gladfully solved this issue.

But not enough, afterwards I experienced that acroread doesn't work anymore. I don't know why this did happen to me today, as the issue seems a bit older (I found an article on about how to fix this that is dated at november 2006...

Last but not least, Gallery Remote (from the gallery project) doesn't work anymore due to curious error messages:

tuxx@vi-edv003:~/Gallery_Remote$ ./Gallery_Remote
nawk: error while loading shared libraries: libdl.so.2: cannot open shared object file: No such file or directory
dirname: error while loading shared libraries: libc.so.6: cannot open shared object file: No such file or directory
/bin/ls: error while loading shared libraries: librt.so.1: cannot open shared object file: No such file or directory
basename: error while loading shared libraries: libc.so.6: cannot open shared object file: No such file or directory
dirname: error while loading shared libraries: libc.so.6: cannot open shared object file: No such file or directory
basename: error while loading shared libraries: libc.so.6: cannot open shared object file: No such file or directory
grep: error while loading shared libraries: libc.so.6: cannot open shared object file: No such file or directory
/opt/jre1.5.0_11/bin/java: error while loading shared libraries: libpthread.so.0: cannot open shared object file: No such file or directory
tuxx@vi-edv003:~/Gallery_Remote$

I haven't fixed this by now, but I'm hardly trying too...
Update:
I finally fixed it. Simply comment out all "export LD_ASSUME_KERNEL" lines in the Gallery_Remote script and voila, it works again...

What I finally managed to do is catch up on the forum, setup a gallery site on http://gallery.tuxx-home.at, migrate nearly all data and operating system installations from my old notebook to my new one and had a good coffee, or two, don't remember. And if the Gallery_Remote tool finally would let itself convince to work again, I will migrate all my old galleries on tuxx-home.at to the new gallery subdomain.

All in all, not a very good first day at work :-/

Today I returned from my vacation and finally got myself some time to fix the apt-proxy issue where apt-proxy can't handle the new '~' characters in Debian's package names.
To me it seems as if the problem is caused by the python urlparse module, but as I'm no real python programmer, I don't know for sure.

I filed a bugreport at the Debian BTS, but until now it is not online...

Anyway, here's a patch that solves this issue by working around this issue. The patch has to be applied to the file "/usr/share/pycentral/apt-proxy/site-packages/apt_proxy/apt_proxy.py".

--- apt_proxy.py	2006-08-15 00:00:45.000000000 +0200
+++ /root/apt_proxy.py.new	2006-09-08 09:07:49.849166662 +0200
@@ -182,6 +182,10 @@
 
         self.scheme, netloc, self.path, parameters, \
                      query, fragment = urlparse.urlparse(uri)
+
+	# ``~`` are allowed in urls!!!
+	self.path = self.path.replace("%7e", "~")
+
         if is_rsync:
             self.scheme = 'rsync'
 
@@ -284,6 +288,10 @@
     def clean_path(self, uri):
         # Clean up URL given
         scheme, netloc, path, params, query, fragment = urlparse.urlparse(uri)
+
+	# ``~`` are allowed in urls!!!
+	path = path.replace("%7e", "~")
+
         return os.path.normpath(path)
 
     def not_modified(self):

Downloads:

• apt_proxy.py.diff

Today I received lots of this error messages on one of my mailservers.
Google wasn't as helpful as usual, but after searching for a long while I found the solution and want to provide it here so that the next time googling for this issue won't take that long again.

imaplogin is part of the courier-imap(-ssl) suite so this issue may only be relevant for those who use courier to provide IMAP to your users.

After checking all parts of the courier suite, the authentication mechanism and some other stuff the problem still hasn't gone away.
The only thing that helped was restarting the FAM daemon which suddenly stopped working as it seems.

Here's a short documentation of how to install TrendMicro ISVW SMB on Debian based installations:

You need to have chkconfig for Debian installed (check here for installation instructions).
The second thing you need is libstdc++2.10-glibc2.2 (isinst relies on this library).

The current version of the ISVW installer (isinst) is only able to recognize postfix or sendmail as local MTA, so you need to have one of them installed (I tried to modify isinst but that would me too much work because you'll have to modify all scripts in several tgz-files to reflect the changes for the whole installation procedure, anyhow if you're still interested in this approach, click here for a diff to isinst).

After your system is prepared, start the installer and answer all the questions according to your needs and you should be fine.

Known Issues:
After installation you will get the following warnings when running ldconfig:

ldconfig: File /usr/lib/libem_shell.so.lock is too small, not checked.
ldconfig: /usr/lib/libem_shell.so is not an ELF file - it has the wrong magic bytes at the start.

According to the knowledgebase of TrendMicro you can ignore these warnings (although I don't understand, why they put their own object-format-files into the global shared objects directory...).

Yesterday I tried to import all address book entries from Mozilla Thunderbird into an OpenLDAP server. That was quite a pain, because the TB-exported LDIF-scheme did not import into LDAP, so I had to do quite some stuff.

1. Import the mozillaOrgPerson_V0.6.2 schema into your ldap-server
2. Adjust slapd.conf's sizelimit option if your address book contains more than 500 (= default value) entries
3. Run the conversion script to fix all issues regarding TB-Addressbook Export and OpenLDAP LDIF import.

1. Import the mozillaOrgPerson schema

Download the mozillaOrgPerson_V0.6.2 schema and copy it to "/etc/ldap/schema/".
Add the following include statement anywhere on top of your "/etc/ldap/slapd.conf" file.

include         /etc/ldap/schema/mozillaOrgPerson_V0.6.2.schema

After this, restart your slapd.

2. Adjust slapd.conf's sizelimit option

If your address book has more than 500 entries, you need to set the sizelimit option in slapd.conf. By default, it is not mentioned and so I added a newline at the end of the file containing the following directive:

# Because we have more than 500 entries in our database...
sizelimit       1500

3. Run the conversion script

I wrote a cool perl script to prepare the exported LDIF-file from Thunderbirds addressbook for importing it into my OpenLDAP server (I used phpldapadmin to import the file).

Check out the syntax highlighted version of the script for a precise explanation of what it does exactly or alternatively download the script.

I was very happy to have a LDIF-source file with soooo many exceptions and unusual statements so I could take care of all of them.
If you experience any errors or want to provide additional features to this script, please contact me on the usual ways.

Happy converting

Today I recognized, that Debian's courier-imapd has a very ugly default value for IMAP_EMPTYTRASH (found in /etc/courier/imapd). This value maybe costs me about 10 hours of additional work to get all trash-mails back from the backups to the corresponding IMAP-folders.

The reason, why my users need there trash folder is that they "archived" their mails in the trash folder which is - of course - not usual, but why not...

So for you guys out there: Comment this setting out. Not mentioning it in the configuration file works well.

Today I tried to install Trend Micro Interscan Virus Wall (ISVW) on a Debian System and prompt I went into some troubles. First of all, the install script of isvw (isinst) is very ugly. Next it does only support rpm-based distributions and requires the existance of chkconfig.
My first approach to detect the operating system and then use either chkconfig or Debian's way update-rc.d seemed to work fine, but the installable modules for isvw have their own install scripts which also need chkconfig and therefore the startup- and shutdown-links were not created after the installation process (I also added support to detect exim as MTA and allowed the script to find out if either inetd or xinetd is running + some other useful stuff). Patching all install scripts may be a lot of work because you never know in which tar.gz archives another install script may exist and also require chkconfig. So I decided to give chkconfig for debian a try. I found a working version here which is currently only available for Debian woody and depends on libnewt0. In Debian Sarge, libnewt0 is not available anymore, instead libnewt0.51 has to be installed.
chkconfig for debian is unfortunately linked to libnewt.so.0.50 so one has to create a symlink for that version too and that finally worked then. So the list of commands necessary to get chkconfig for Debian to work can be found here:

wget ftp://ftp.skolelinux.no/skolelinux/dists/woody/local/binary-i386/non-official/chkconfig_1.2.24d-1_i386.deb
apt-get install libnewt0.51
ln -s /usr/lib/libnewt.so.0.51 /usr/lib/libnewt.so.0.50
dpkg -i chkconfig_1.2.24d-1_i386.deb

To avoid breaking your package management system you'd also have to edit "/var/lib/dpkg/status" and change "libnewt0" to "libnewt0.51" in the Depends: line for the package chkconfig.

If the version of chkconfig is ever to be removed from ftp.skolelinux.no, I mirrored it here.