Auf meinem aktuellen Karmic-System wollte ich gern majordomo installieren. Primär eigentlich nur, um das Kommando approve absetzen zu können, mit dem ich bouncende Mails aus den von mir betreuten Mailinglisten bestätigen kann. Leider habe ich bisher kein Debian-Paket für mein Ubuntu finden können, vermutlich hat das mit Sicherheitsproblemen dieser etwas älteren Software zu tun.

Beim aktuellen OpenSuSe wird majordomo immer noch mit ausgeliefert. Daher war die Idee naheliegend das RPM-Paket mittels alien in ein Debian-Paket zu verwandeln und dann zu installieren. Leider war das nicht ganz so einfach. Das Ubuntu-Alien kommt teilweise mit aktuellen RPM-Paketen nicht zurecht, da die Art der Komprimierung verändert wurde. Das Problem scheint aber schon älter zu sein, es hat sich anscheinend aber noch niemand ernsthaft darum gekümmert. Es gibt Fehlermeldungen der Art:

Unpacking of 'majordomo-1.94.5-457.1.i586.rpm' failed at /usr/share/perl5/Alien/Package/Rpm.pm line 155.

In dem Artikel http://forum.ubuntuusers.de/topic/kivio-2-0-installieren/#post-2054853 habe ich dann eine Lösung gefunden. Dort ist ein kleiner Patch zu finden, der das Problem in der Zeile 155 angeht.

sub unpack {
	my $this=shift;
	$this->SUPER::unpack(@_);
	my $workdir=$this->unpacked_tree;
	my $rpmunpack="rpm2cpio ".$this->filename." | lzma -d | ";

	$this->do($rpmunpack."(cd $workdir; cpio --extract --make-directories --no-absolute-filenames --preserve-modification-time) 2>&1")
	      or (($rpmunpack="rpm2cpio ".$this->filename." | ")
	      and $this->do($rpmunpack."(cd $workdir; cpio --extract --make-directories --no-absolute-filenames --preserve-modification-time) 2>&1"))
	      or die "Unpacking of '".$this->filename."' failed";

	# cpio does not necessarily store all parent directories in an
	# archive, and so some directories, if it has to make them and has
	# no permission info, will come out with some random permissions.
	# Find those directories and make them mode 755, which is more
	# reasonable.
	my %seenfiles;
	open (RPMLIST, $rpmunpack."cpio -it --quiet |")
		or die "File list of '".$this->filename."' failed";

Ich habe einfach die entsprechenden vorhandenen Zeilen auskommentiert und diese Zeilen hineinkopiert. Nach der Änderung konnte ich mein Majordomo-Paket erfolgreich konvertieren mittels:

sudo alien --scripts majordomo-1.94.5-457.1.i586.rpm

Herzlichen Dank an den Autor hakunamatata.

Da in meinen Webserver-Log-Dateien häufiger Anfragen nach Dateien namens wpad.dat auftauchten habe ich mich mal mit dem Thema Web Proxy Autodiscovery Protocol (WPAD) beschäftigt. Positiv daran ist, dass es als Webstandard gilt und von allen aktuellen Browsern unterstützt wird. WPAD benutzt Proxy Auto-Configuration (PAC) Dateien um die Einstellungen zu übermitteln.

Diese Dateien dienen dazu Browser automatisch zu konfigurieren, so dass sie sich die Proxy-Einstellungen selbständig erfragen können. Grundlage dafür ist eine Konfigurationsdatei namens wpad.dat, die im einfachsten Fall folgenden Inhalt besitzt:

function FindProxyForURL(url, host)
{
  if(isPlainHostName(host) || localHostOrDomainIs(host, "localhost") ||  localHostOrDomainIs(host, "127.0.0.1") || isInNet(host, "192.168.1.1", "255.255.0.0")) {
     return "DIRECT";
  }else {
     return "PROXY 192.168.1.1:3128";
  }
}

Im Prinzip wird hier in der letzten Zeile die Adresse und der Port des Proxy-Server übergeben. Der Teil davor umgeht den Proxy-Server, wenn ein Rechnername ohne Domain aufgerufen wird, der Name oder die IP für localhost oder ein Rechner aus dem lokalen Netz.

Detaillierte Informationen findet man unter http://findproxyforurl.com und natürlich http://de.wikipedia.org/wiki/WPAD.

Diese Datei muss nun nur noch zum Browser kommen. Dazu muss der Browser passend eingestellt sein: Bearbeiten -> Einstellungen -> Erweitert -> Netzwerk -> Verbindung -> Einstellungen -> Die Proxy-Einstellungen für dieses Netzwerk automatisch erkennen

Nun muss auf dem Server noch der Webserver-Apache entsprechend konfiguriert werden. Er sollte im Idealfall auf folgende URL hin die Datei ausliefern: http://wpad.<rechnername.lokale-domain>/wpad.dat In den meisten Installationen langte es sicherlich im Nameserver einen cname für wpad einzurichten:

wpad       CNAME   boss

Zusätzlich wird noch empfohlen die zugehörigen Mime-Types zu registrieren. Dazu kommen folgende Zeilen in die bisher leere Datei /etc/apache2/httpd.conf:

AddType application/x-ns-proxy-autoconfig .dat
AddType application/x-ns-proxy-autoconfig .pac
Redirect permanent  /proxy.pac /wpad.dat

Hier sind zwei Dateien eingetragen, die wpad.dat und die proxy.pac, die beide identisch sind. Eine Version ist für WPAD-fähige Systeme zuständig, die andere für ältere Versionen. Durch den Redirect muss nur eine der beiden Dateien wirklich vorhanden sein. Anfragen an die andere Datei werden passend weitergeleitet.

Im Prinzip suchen die Browser nun nach einem festen System nach der Konfigurationsdatei. Man kann ihnen das Leben erleichtern und auch den cname wpad für den Webserver vermeiden, wenn man die DHCP-Server Konfiguration etwas anpasst.

# /etc/dhcpd.conf
#
# Configuration file for ISC dhcpd
#
# -- global options --
default-lease-time                 160000;
max-lease-time                     200000;
use-host-decl-names                on;
option dhcp-max-message-size       1024;
option wpad code 252 = text;
ddns-update-style                  none;
authorative;

subnet 192.168.1.0 netmask 255.255.255.0 {
    range 192.168.1.40 192.168.1.160;
    server-identifier 192.168.1.1;
    option broadcast-address 192.168.1.255;
    option routers 192.168.1.254;
    option domain-name-servers 192.168.1.1, 192.168.1.254;
    option domain-name "debacher.net";
    option wpad "http://www.debacher.net/wpad.dat ";
}

Die beiden hinzuzufügenden Zeilen sind fett unterlegt. Damit wird dem Client-Rechner schon beim Starten die Adresse der wpad.dat (Code 252) mit übermittelt. Hier ist eine beliebige URL möglich, die auch nicht unbedingt im eigenen Netz liegen muss. Die Adressübermittlung per DHCP hat übrigens Vorrang gegenüber der Übermittlung per DNS. Man muss also nicht unbedingt an den Nameserver heran.

Weitere Informationen:

Ich wollte mich gern mit der erschreckenden Gesichtererkennung des neuen Picasa 3.6  beschäftigen. Leider bietet Google keine aktuellen Versionen für Linux an. Unter http://www.mail-archive.com/google-labs-picasa-for-linux@googlegroups.com/msg01748.html habe ich einen Beitrag gefunden mit dessen Hilfe ich 3.6 erfolgreich unter Ubuntu 9.10 installieren konnte.

Die Beschreibung geht davon aus, dass man Picasa 3.0 auf dem eigenen Rechner installiert hat. Ich hatte das schon vor einiger Zeit gemacht. Das Picasa 3.0 findet sich dann unter /opt/google auf dem Rechner.

Zuerst lädt man sich die Datei picasa36-setup.exe von der Google-Download-Seite.

cd /opt/google/picasa/3.0/wine/bin
./wine /home/debacher/Downloads/picasa36-setup.exe

Dabei wird Picasa in das Verzeichnis /home/debacher/.wine installiert. Soll es allgemein zur Verfügung stehen, so muss diese Installation nach /opt verschoben werden. Dazu benötigt man Root-Rechte:

sudo su -
cd /opt/google/picasa/3.0/wine/drive_c/Program\ Files/Google/
rm -Rf Picasa3
cp -R /home/debacher/.wine/drive_c/Programme/Google/Picasa3/  .
cd Picasa3
mv PicasaUpdater.exe PicasaUpdater.exe.old

Danach startet dann zukünftig Picasa 3.6 auch über alle Menüeinträge der alten Installation. Man kann dann sogar das gesamte .wine Verzeichnis im Homeverzeichnis löschen, zumindest wenn es nicht vorher schon vorhanden war.