sudo add-apt-repository ppa:mozillateam/firefox-stable
sudo add-apt-repository ppa:mozillateam/thunderbird-stable

Wenn nun eine Aktualisierung durchgeführt wird, z.B. über die Benutzeroberfläche “System” -> “Systemverwaltung” -> “Aktualisierungsverwaltung” werden die bereits installierten Programme geupdated und die neuen Firefox- bzw. Thunderbird-Versionen installiert.

ACHTUNG: Je nachdem welche Add-ons installiert sind, sollte zuvor abgeglichen werden, ob diese auch für die neue Version verfügbar sind.

Bei dem Update werden die alten Sprachdateien der Version 3.16.x von Firefox unter Umständen nicht deinstalliert und lassen sich dann auch nicht über die Add-on-Verwaltung deinstallieren. Für diesen Fall kann das folgendermaßen nachgeholt werden: die Ordner bzw. *.xpi-Dateien der entsprechenden Erweiterung müssen gelöscht werden (dabei sollte das Programm geschlossen sein). Die Dateien der Spracherweiterung befinden sich in dem globalen extensions-Ordner unter /usr/lib/firefox/extensions bzw. /usr/lib/firefox-8.0/extensions. Diese sind nur mit root-Rechten beschreibbar und sollten mit Vorsicht behandelt werden, also sollte dieser Schritt nur dann durchgeführt werden, wenn man sich bewusst ist, was man tut, anderenfalls sollte er übersprungen werden, da die nicht kompatiblen Sprachdateien keine Probleme bereiten.

Auf der Suche nach guten HowTos fand ich schnell das Tutorial der Ubuntu-Community, allerdings entstand beim abarbeiten genau der Fehler, der auch im Titel erschien. Dieser Fehler lies sich auch nach zahlreichen Versuchen nicht lösen, weshalb ich entschied einmal selbst Hand anzulegen und getreu dem Motto “Weniger ist manchmal mehr” zu handeln. Nun genug des Vorgeplänkels:

Voraussetzung ist ein Computer mit 2 Netzwerkkarten:
eth0 – Verbindung in das Internet
eth1 – neues Netzwerk für die zu schützenden Computer

Die Installation des Ubuntu-Servers funktioniert ohne jegliche Besonderheiten. Es muss auch nichts aus dem Auswahlmenü installiert werden, allerdings ist ein SSH-Server sehr hilfreich. Die Netzwerkkonfiguration sollte man hier für die Netzwerkkarte festlegen, die mit dem Internet verbunden ist (bei mir ist das eth0).

Als nächstes sollte das System auf den aktuellen Stand gebracht werden:

sudo apt-get update
sudo apt-get upgrade
sudo reboot

Um die Benutzer zu authentifizieren nutzt CoovaChilli Freeradius, der als nächstes installiert werden sollte:

sudo apt-get install freeradius

Freeradius besitzt eine Vielzahl von unterschiedlichen Ressourcen, in denen die Benutzer gesucht werden, u.a. SQL, LDAP und einfache Dateien. Nach der Installation von freeradius muss lediglich ein Benutzer in die Datei /etc/freeradius/users eingefügt werden. Die Konfiguration von Freeradius, um SQL oder LDAP zu nutzen wird hier nicht weiter erwähnt.

# /etc/freeradius/users
“benutzer”  Cleartext-Password:=”password”

Nach dem Speichern und neu starten des Services sollte der Benutzer sich mit radtest bereits erfolgreich testen lassen:

sudo service freeradius restart
sudo radtest “benutzer” “password” 127.0.0.1 0 testing123

Als Resultat müsste etwas wie

rad_recv: Access-Accept packet from host 127.0.0.1 port 1812, id=213 length=20

ausgegeben werden. Wenn der Radius-Server auf dem gleichen Rechner läuft wie das Captive-Portal, muss nichts weiter verändert werden, anderenfalls muss der Rechner, auf dem CoovaChilli läuft als Client in die Datei /etc/freeradius/clients.conf eingetragen werden, z. B.:

# /etc/freeradius/clients.conf
client 192.168.0.0/24 {
secret  =  testing123-2
shortname  =  private-network-rad
}

Für die nächsten Schritte wird voraus gesetzt, dass Freeradius ordnungsgemäß wie oben beschrieben funktioniert. Sonst müssen erst die Fehler behoben werden, bevor fortgefahren wird.

Installation von CoovaChilli

Die CoovaChilli installation unter Ubuntu 10.04 ist sehr einfach: Den aktuellen Binary-Build herunterladen und mit dpkg installieren:

wget http://ap.coova.org/chilli/coova-chilli_1.2.5_i386.deb
sudo dpkg -i coova-chilli_1.2.5_i386.deb

Damit CoovaChilli startet, muss die Datei /etc/default/chilli so angepasst werden, dass der Parameter START_CHILLI auf 1 steht:

# /etc/default/chilli
START_CHILLI=1

Wenn CoovaChilli beim Systemstart automatisch gestartet werden soll, müssen noch Startuplinks angelegt werden:

sudo update-rc.d chilli defaults 99 1

Eine Konfigurationsdatei von CoovaChilli ist neben der default-Datei noch nicht vorhanden, um also eine eigene Konfiguration zu verwenden, muss die default-Datei kopiert werden. Danach kann diese angepasst werden:

sudo cp /etc/chilli/default /etc/chilli/config
sudo nano /etc/chilli/config
# /etc/chilli/config
# minimale Änderungen die durchgeführt werden müssen
# Radius-Einstellungen:
HS_NASID=0
HS_RADIUS=127.0.0.1
HS_RADIUS2=127.0.0.1
HS_UAMALLOW=10.1.0.1,www.coova.org
HS_RADSECRET=testing123

Alle weiteren Einstellungen können auch modifiziert werden, allerdings sollte Vorsicht walten, bevor man Parameter verändert und danach nichts mehr funktioniert.

Eine letzte Anpassung die gemacht werden muss ist die Installation von Haserl:

wget http://downloads.sourceforge.net/project/haserl/haserl-devel/haserl-0.9.28.tar.gz
tar -xzf haserl-0.9.28.tar.gz
cd haserl-0.9.28
./configure
# Sollten hier Fehler auftreten, liegt es vermutlich daran,
# dass die nötigen Programme nicht installiert sind:
# sudo apt-get install build-essential
# schafft in diesen Fällen Abhilfe
make
sudo make install
# Jetzt einfach neu starten:
sudo reboot

Nach diesem Neustart sollte nun eigentlich alles Funktionieren und bei der Verbindung eines Clients auf der Netzwerkkarte eth1 sollte dieser auf die Login-Seite weitergeleitet werden.

Bei mir trat jedoch ein Fehler auf, beim Versuch eine Seite aufzurufen:

You need to install haserl to serve pages with this wwwsh script!
see http://haserl.sourceforge.net

Der Fehler verwunderte mich, da ja haserl bereits installiert war. Ein Blick in das Script /etc/chilli/wwwsh brachte mich auch nicht weiter, denn das Kommando, um den Pfad von haserl zu bestimmen funktionierte bei mir tadelos. Da der Pfad bekannt war, wurde er schlichtweg statisch eingetragen (vielleicht nicht unbedingt elegant, aber es funktioniert):

#haserl=$(which haserl 2>/dev/null)
haserl=/usr/local/bin/haserl

nun funktionierte alles wie gewünscht und die Clients konnten sich erfolgreich Authentifizieren.

Voraussetzung:

Grundsätzlich gibt es viele Möglichkeiten die Gateway-Software zu installieren. Man kann Sie z.B. auf einem OpenWRT-System installieren – z.B. auf dem berühmten Linksys WRT54GL oder ähnlichen Routern. Andererseits kann man auch einen Computer mit 2 Netzwerkkarten nutzen, was wir getan haben:

Computer/Server mit 2 Netzwerkkarten
Die Hardware-Kompatibilität mit Ubuntu 8.04 versteht sich von selbst. Eine der Netzwerkkarten ist mit dem Netz verbunden, in dem der Webserver steht und von welchem aus Zugang zum Internet besteht. Die andere ist für die zukünftigen Clients des Captive-Portals zuständig.

Installation von Ubuntu 8.04.04 i386 Server-Edition:

Der Installation von Ubuntu folgen bis zur Auswahl der primären Netzwerkkarte. Hier muss man die Ethernet-Karte auswählen, die mit dem zu sperrenden Netz – im Normalfall dem Netz mit dem Webserver und Zugang zum Internet – verbunden ist. Als nächstes habe ich die automatische Konfiguration der Netzwerkinformationen abgebrochen und das Netzwerk manuell konfiguriert – wie zum Beispiel:

Adresse 10.49.127.10
Subnetzmaske 255.255.255.0
Gateway/DNS-Server auch entsprechend angeben.

Die Installation abschließen (sinnvoll wäre auch gleich während der Installation von Ubuntu den OpenSSH-Server zu installieren, welcher allerdings keine Voraussetzung für die Software ist).

Update und Grundkonfiguration

Nach der Installation und dem Neustart des Rechners wird es Zeit das System zunächst auf den aktuellen Stand zu bringen und nötige Updates zu installieren:

sudo apt-get update
sudo apt-get upgrade

Als erstes ist es sinnvoll die 2. Netzwerkkarte richtig zu konfigurieren. Diese Netzwerkkarte wird Teil des späteren Client-Netzwerks sein. Die Clients die in diesem Netzwerk verbunden sind versuchen durch diese Netzwerkkarte auf das gesperrte Netzwerk (auf der während der Installation eingerichteten Netzwerkkarte) zuzugreifen. Folgende Konfiguration könnte man vornehmen:

sudo nano /etc/network/interfaces
# öffnet die Netzwerkkonfigurationsdatei
# anfügen und gegebenfalls anpassen:
auto eth1
iface eth1 inet static
address 192.168.10.1
netmask 255.255.255.0

eth1 muss man durch die entsprechende Netzwerkkarte ersetzt werden. Wenn eth1 benutzt wird um ins Internet zu gelangen, dann sollte es üblicherweise eth0 sein. Speichern und Schließen und anschließen ein Neustart der Netzwerk-Komponenten:

sudo /etc/init.d/networking restart

Um nun den Clients die im Netzwerk, des gerade ebend konfigurierten Interfaces, angeschlossen sind durch das 1. Interface Informationen aus dem gesperrten Netz empfangen zu lassen richtet man eine NAT-Regel ein und stellt IP-Forward an:

sudo sysctl net.ipv4.ip_forward=1
sudo iptables -A POSTROUTING -t nat -o eth0 -j MASQUERADE
# wenn eth0 das Interface ins gesperrte Netz ist
sudo iptables -A FORWARD -i eth1 -j ACCEPT
# wenn eth1 das Interface für die Clients ist

Um dieses Konfiguration dauerhaft zu übernehmen muss sie in /etc/sysctl.conf (um IP-Forward zu enablen, Suchstring: “net.ipv4.ip_forward”) bzw. /etc/rc.local für die iptables-Regeln. Die iptables-Regeln sind einfach (ohne sudo) in die rc.local einzufügen.

DHCP und Bind9 (DNS-Server) Installation:

Um die Clients auch automatisch mit den nötigen Netzwerkinformationen zu versorgen, sobald sie sich ins Netzwerk einklinken, ist ein DHCP- und ein DNS-Server notwendig. Diese installiert man mit folgendem Kommando:

sudo apt-get install dhcp3-server bind9

Anschließend muss man beide Konfigurieren. Beginnen wir mit dem DHCP-Server. Die entsprechende Datei ist /etc/dhcp3/dhcpd.conf Eine minimale Konfigurationsdatei könnte folgendermaßen aussehen:

default-lease-time 36000;
max-lease-time 72000;
authoritative;
subnet 192.168.10.0 netmask 255.255.255.0 {
range 192.168.10.5 192.168.10.250;
option domain-name-servers 192.168.10.1;
option broadcast-address 192.168.10.255;
option routers 192.168.10.1;
option subnet-mask 255.255.255.0;
}

Nun sollte man den DNS-Server konfigurieren. Das Konfigurations-Verzeichnis ist /etc/bind9 hier sind vor allem die Dateien named.conf.options und named.conf.local interessant. Man muss mindestens den bzw. die Referenz-DNS-Server angeben, den der lokale DNS-Server fragt, wenn er selbst den Namen nicht kennt.

/etc/bind/named.conf.options
…
forwarders {
# Eine Liste öffentlicher DNS-Server findet man leicht
# in einer Suchmaschine
194.25.2.129;
194.25.2.130;
};
….

Nun muss man den DHCP- und DNS-Server neu starten, um die neue Konfiguration zu übernehmen

sudo /etc/init.d/dhcp3-server restart
sudo /etc/init.d/bind9 restart

Jetzt kann man Testen, ob alles einwandfrei funktioniert. Dies ist erforderlich, um mit den nächsten Schritten fortzufahren. Wenn ein Computer, der im Client Netzwerk hängt eine IP-Adresse via DHCP zugewiesen bekommt und ins Internet bzw. in das später gesperrte Netz zugriff hat, dann sollte alles geklappt haben.

Wifidog-Gateway Installation

Zuerst einmal sollte man Programme installieren, die für das Kompilieren notwendig sind:

sudo apt-get install build-essential

Jetzt ist es Zeit den Quelltext der Wifidog-Gateway-Software herunterzuladen und zu installieren:
Aktuelle Download-Links sind auf http://dev.wifidog.org/wiki/Download zu finden.

wget http://downloads.sourceforge.net/project/wifidog/wifidog-gateway/1.1.5/wifidog-1.1.5.tar.gz
tar -xzf wifidog-1.1.5.tar.gz
cd wifidog-1.1.5
./configure
make
make install

Jetzt nur noch die Konfigurationsdatei kopieren und Wifidog mittels Symbolischen Link zur Verfügung stellen:

cp wifidog.conf /etc
# Befindet sich die Datei wifidog.conf nicht im aktuellen
# Verzeichnis (dem Verzeichnis der entpackten Software), kann
# man danach suchen: find / -name wifidog.conf
# Symbolischer Link für Wifidog-Software erstellen.
ln -s /etc/wifidog.conf /usr/local/etc/wifidog.conf

Wifidog-Gateway Konfiguration

Nun ist es an der Zeit die Software zu konfigurieren. Die Wifidog-Konfigurationsdatei (/etc/wifidog.conf) ist eigentlich selbsterklärend. Für eine minimale Konfiguration sollten folgende Dinge geändert werden:

GateWay Id: hotspot1
ExternalInt: eth1
InternalInt: eth0
AuthServer {
Hostname login.example.com
SSLAvailable no
Path /
}
# Hier muss man login.example.com durch die spätere
# (Sub)Domain des Webservers ersetzen, auf dem die
# Login-Seite laufen soll. Natürlich auch die Interfaces
# entsprechend ändern.

Wifidog Starten

Nun sollte alles erfolgreich konfiguriert und installiert sein. Für das starten der Gateway-Software ist es notwendig den Webserver für den Login bereits installiert zu haben.

wifidog -f -d 7
# -f bedeutet, dass wifidog im Vordergrund auf der Konsole laufen soll
# -d 7 wählt das Debuglevel.

Wenn folgender Fehler auftritt: “wifidog: error while loading shard libraries: libhttpd.so.0: cannot open shared object file: No such file or directory”, muss man folendes Kommando ausführen, danach sollte Wifidog normal starten:

ldconfig

Voraussetzung:

Computer/Server mit 2 Netzwerkkarten
Die Hardware-Kompatibilität mit Ubuntu 8.04 versteht sich von selbst. Eine der Netzwerkkarten ist mit dem Internet verbunden. Die andere bespeist ein eigenes Netz für die zukünftigen Clients des Terminal-Servers.

Installation von Ubuntu 8.04.03 amd64 Server-Edition:

Der Installation von Ubuntu folgen bis zur Auswahl der primären Netzwerkkarte. Hier muss man die Ethernet-Card auswählen, die mit dem Internet verbunden ist. Als nächstes habe ich die automatische Konfiguration der Netzwerkinformationen abgebrochen und das Netzwerk manuell konfiguriert – wie zum Beispiel:

Adresse 192.168.49.10
Subnetzmaske 255.255.255.0
Gateway/DNS-Server auch entsprechend angeben.

Als nächstes der Installationsroutine folgen, bis man zur Auswahl der zusätzlichen Software-Pakete kommt. Hier habe ich Openssh-Server ausgewählt. (Diesen kann man natürlich auch später per Hand installieren, aber grundsätzlich braucht man einen SSH-Server eigentlich immer, weshalb ich ihn schon hier mit installieren lasse.) ACHTUNG: Für den LTS ist der Openssh-Server Voraussetzung. Nun lediglich die Installation vervollständigen und die gewohnten Einstellungen ausführen.

Update und Installation des LTS

Nach der Installation und dem Neustart des Rechners wird es Zeit das System zunächst auf den aktuellen Stand zu bringen und nötige Updates zu installieren:

sudo apt-get update
sudo apt-get upgrade

Nun muss man das Desktop-System installieren, welches Voraussetzung für den Terminal-Server ist:

sudo apt-get install ubuntu-desktop
# Dies kann eine ganze Weile dauern.
# Danach rein Reboot:
sudo reboot

Ist alles bis hierhin gut Verlaufen, so müsste man sich jetzt in einer Grafischen Benutzeroberfläche  befinden. Nun öffnen wir ein Terminal ([ALT] + [F2] und dann gnome-terminal gefolgt von [ENTER] eingeben), indem wir schließlich den eigentlichen Terminal-Server installieren:

sudo apt-get install ltsp-server-standalone ltspfsd
# Dies installiert den LTS und ein Paket welches zur
# Verwendung von USB-Sticks an den Clients  erforderlich ist

Konfiguration

Zunächst muss die 2. Netzwerkkarte konfiguriert werden. Dazu öffnet man die entsprechende Datei und fügt dieser die entsprechenden Zeilen hinzu:

sudo nano /etc/network/interfaces
#öffnet die Netzwerkkonfigurationsdatei
# folgende Zeilen sind anzufügen:
auto eth1
iface eth1 inet static
address 10.49.0.1
netmask 255.255.255.0
# eventuelle zusätzlich Informationen wie broadcast
# oder network, aber nicht zwingend erforderlich
# [STRG] + [O] gefolgt von [ENTER] Speichert die Datei
# [STRG] + [X] schließt den Editor

Als nächstes muss man überprüfen, ob der TrivialFileTransferProtocoll-Daemon gestartet wird. Bei mir wurde das immer korrekt vom Installer ausgeführt. Dies erkennt man daran, wenn in der Datei /etc/inetd.conf die folgende Zeile vorhanden ist:

tftp           dgram   udp     wait    root  /usr/sbin/in.tftpd /usr/sbin/in.tftpd -s /var/lib/tftpboot

Nun – fast als letztes – muss man den DHCP-Server anpassen. ACHTUNG: Die Konfigurationsdatei findet man unter /etc/ltsp/dhcpd.conf und nicht unter /etc/dhcp3/dhcpd.conf:

authoritative;
allow booting;
allow bootp;
subnet 10.49.0.0 netmask 255.255.255.0 {
range 10.49.0.20 10.49.0.250;
option domain-name “example.com”;
option domain-name-servers 10.49.0.1;
option broadcast-address 10.49.0.255;
option routers 10.49.0.1;
option subnet-mask 255.255.255.0;
option root-path “/opt/ltsp/i386″;
if substring( option vendor-class-identifier, 0, 9 ) = “PXEClient” {
filename “/ltsp/i386/pxelinux.0″;
} else {
filename “/ltsp/i386/nbi.img”;
}
}

Anschließend habe ich den Server neu gestartet und kontrolliert, ob die Dienste und die Netzwerkkonfiguration erfolgreich übernommen wurden. (ifconfig zeigt z.B. die momentanen Netzwerkinformationen)

LTS-Client bauen und Finale Konfiguration

Wenn alle Einstellungen erfolgreich waren und der Server soweit funktioniert, dann kann das Client-Image erstellt werden:

sudo ltsp-build-client –arch i386

Die Angabe der Option arch i386 ist nicht zwingend erforderlich. Fehlt sie, so wird ein Image von amd64 anstatt eines i386 (Natürlich nur auf einer Basis von Ubuntu amd64. Auf Basis von Ubuntu i386 kann NUR ein i386-Image erstellt werden.

sudo ltsp-update-sshkeys
# muss ausgeführt werden, um die aktuellen
# Einstellungen zu übernehmen

Abschließend habe ich noch kontrolliert, ob auch die Freigabe für das Image erstellt wurde. Diese findet man in /etc/inetd.conf. Hier müsste mindestens einer der folgenden Einträge zu sehen sein:

2000 stream tcp nowait nobody /usr/sbin/tcpd /usr/sbin/nbdrootd /opt/ltsp/images/amd64.img
2001 stream tcp nowait nobody /usr/sbin/tcpd /usr/sbin/nbdrootd /opt/ltsp/images/i386.img
# Fehlen diese, sollte man sie hinzufügen und den
# Dienst neu starten: sudo /etc/init.d/openbsd-inetd restart

Das war’s! Nun sollte es möglich sein von einem Computer/ThinClient der über das Netzwerk – der mit eth1 verbundenen Karte – in Ubuntu zu booten.

Weiterführende Links:

http://wiki.ubuntuusers.de/LTSP
http://wiki.ubuntuusers.de/LTSP/lts.conf
https://help.ubuntu.com/community/UbuntuLTSP/LTSPQuickInstall
https://help.ubuntu.com/community/UbuntuLTSP

Deprecated: Assigning the return value of new by reference is deprecated in /*****/xajax_core/xajax.inc.php on line 360
Deprecated: Assigning the return value of new by reference is deprecated in /*****/xajax_core/xajax.inc.php on line 1305

PHP hatte also ein Problem mit dem Xajax-Code, wobei dieser Error erst mit der Version 5.3.x von PHP hinzugefügt wurde, weshalb er zuvor auch nicht erschienen ist. Man kann das auswerfen dieses Fehlers unterbinden, indem man im php-Script

<?php error_reporting(E_ALL ^ E_DEPRECATED); ?>

einfügt. Dieser Code bewirkt, dass alle Fehler, außer den Deprecated-Errors ausgegeben werden. Alternativ kann man die Fehlerebene auch anders wählen. Deprecated-Error sind Hinweise, dass die Funktion in zukünftigen PHP-Versionen nicht mehr verfügbar sein wird. Die Xajax-Funktionen funktionierten danach wieder problemlos bei mir. Nichts desto trotz erwarte ich mit Spannung die Xajax Version 0.6, mit der Xajax, laut Website (“For starters, we are going to take full advantage of PHP5 (even supporting STRICT mode).”), die vollständige Unterstützung und Nutzung der Vorteile von PHP 5 plant.

Nähere Hinweise:
http://php.net/manual/de/migration53.deprecated.php,
http://www.php.net/manual/en/errorfunc.constants.php