Archiv der Kategorie: Schule

Routerbau

netzwerk

Als nächsten Schritt für das iptables Projekt mit meiner AG dachte ich an einen kleinen dreckigen Router, der den „Charme“ hat, dass er die zentrale IP Adressvergabe der Schule für Fremdrechner umgeht. So etwas motiviert Schüler immer 🙂

Wir nutzen dazu am einfachsten ein paar Rechner in der Bibliothek und aktivieren deren zweite Netzwerkkarte, die bisher auf Grund ihrer PXE-Unfähigkeit brach lag. Die schon vorhandene Hardware „kennt“ das Schulnetz – das wird dann eth0.

Ein

echo 1 > /proc/sys/net/ipv4/ip_forward

schaltet auf dem Rechner zwischen Schulnetz und Clients die Routerfunktionalität ein. Dabei zeigt dessen eth0 wie gesagt zur Schule und würde vom schulischen DHCP Server mit einer Adresse versorgt. Da ich das für router-unpassend halte, wird die per DHCP zugewiesene IP Adresse ermittelt und dann mit ipconfig statisch auf eth0 gesetzt. Die eth1 (und damit die bisher brach liegende Karte) des Routers zeigt zu einem kleinen Switch, an dem die Clients hängen. Hier wird per ipfonfig eine 192er Adresse gesetzt und die Clients erhalten ebenfalls statische Adressen. Die Bearbeitung von

/etc/udev/rules.d/70-persistent-net.rules

kann die Zuordnung der MAC-Adressen zu Interface-Namen auf dem Router erzwingen. Mehr muss für dieses Experiment nicht sein.

Ein

iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

stellt den Router auf NAT um.

Damit Clients hinter diesem Router weiterhin über SSH zu erreichen sind, wird Port 22 ge-forward-ed

iptables -t nat -A PREROUTING -p tcp -i eth0 –dport 22 -j DNAT –to-destination ip.adresse.des.clients

Das sollte es dann gewesen sein: Der Router selbst ist von Außen nicht mehr über SSH auf Port 22 zu erreichen, da er diesen ja nach Innen zum Client weiter reicht. Weitere Ports können für einen Webserver auf einem weiteren Client auch noch dazu kommen … mal sehen, wie viel Zeit überhaupt noch bleibt. Ein kurzer Exkurs für den Schluss wäre: Wir schreiben die ganzen Befehle in ein Skript und tragen dieses in /etc/rc.local ein, damit sie einen Reboot überleben.

REJECT und DROP

Für meine Linux AG habe ich nach einer einfachen Möglichkeit gesucht, wie man den Unterschied zwischen REJECT und DROP bei der Nutzung von iptables zeigen könnte. Ich denke, mit ICMP Paketen zeigt sich das deutlich genug:

iptables DROP

Ich nutze hierzu eine VM unter Debian, die über eine Schnittstelle (eth1 – in VBOX dann bridge) direkt mit dem Schulnetz verbunden ist – mit der anderen (eth0 – in VBOX dann nat oder intern) hängt sie am Wirtsrechner selbst. Ein

iptables -t filter -A INPUT -j DROP -i eth1 -s ip.des.anfragenden.rechners

schaltet die Anworten auf ping ip.der.vbox.unter.debian sichtbar komplett ab: ping erhält überhaupt keine Antworten mehr.

iptables REJECT

Nach einem iptables -F zum Putzen der Chains kann man dann weiter spielen und ein REJECT ausprobieren:

iptables -t filter -A INPUT -j REJECT -i eth1 -s ip.des.anfragenden.rechners

Es wird sichtbar, dass nun ping mit „Destination Port Unreachable“ reagiert.

Welches der beiden Verfahren nun sicherer ist, wenn man iptables basierte Firewalls aufbaut, können wir im Anschluss ja endlos diskutieren.

Manchmal hat man schon einen Knoten im Kopf: Zuerst setzte ich auf einen Apache in der VM, den man mit Hilfe von

iptables -t filter -A INPUT -j DROP -i eth1 -s ip.des.anfragenden.rechners -p tcp –dport 80

gegenüber Anfragen von Außen an Port 80 absichern kann.

Aber das ist für den Einstieg a) zu komplex und b) zu langweilig, weil am anfragenden Firefox nicht zu sehen ist, ob nun DROP oder REJECT in der Chain steht: Er meckert halt rum, dass die Verbindung nicht zustande kommt.

Lieber also den brutalen, weil auf alle Ports und alle Protokolle wirkenden Befehl oben zuerst verwenden und dann mit

iptables -t filter -A INPUT -j DROP -i eth1 -s ip.des.anfragende.rechners -p icmp

einschränken, dabei zeigen, dass man dann noch per ssh auf die VM kommt, und dann weiter machen. Außerdem ist der allgemein gegen eine einzelne IP gerichtete Eintrag in iptables sicherlich der Befehl, den man im Alltag häufiger benötigt: Wenn eine IP schon geblockt werden muss, dann ja meist komplett.

Etherpad Lite, npm und node.js

Um es kurz zu machen: Wer (wie ich) auf die Idee kam, node.js aus dem PPA von Chris Lea für seinen EPL Server zu nutzen … hat nun keinen mehr.

Das liegt schlicht daran, dass node.js inzwischen von diesem Maintainer in Version 0.10 zur Verfügung gestellt wird und dieses mit npm aus den Ubuntu Quellen nicht zusammenarbeiten will. Leider hilft es auch nicht, wenn man npm ebenfalls passend macht – z.B. indem man Chris Leas PPA durch das PPA von ric_harvey ersetzt: Dann passen zwar node.js und npm wieder zusammen – aber mit Version 0.10 kommt EPL nicht mehr richtig hoch.

Wer richtig Lust auf’s Basteln hat, der kann sich im Moment diesen Thread bei Github entlang hangeln und landet evtl. einen Treffer.

Oder man greift auf die Ubuntu-Wiki Anleitung zur Installation von EPL zurück und wirft den Compiler an. Dann hat man einen ziemlich alten npm und node.js Server – aber ein funktionierendes EPL.

Oder man wartet ab, bis bei Github eine EPL Version liegt, die mit npm und node.js 0.10 zusammen arbeiten will.

EPlite Update

Aus aktuellem Anlass ein kurzes EPL Update … und das ist auf Grund von git ganz besonders einfach zu bewerkstelligen.

Erst einmal wird der laufende EPL-Server angehalten

sudo stop etherpad-lite

Anschließend wechselt man in den Benutzerkontext des etherpad

sudo su – etherpad -s /bin/bash

und landet in dessen Home. Von dort hangelt man sich bis zum Verzeichnis mit dem Unterverzeichnis .git durch. Wer die im Ubuntu-Wiki und auch hier liegende Anleitung zur Installation von EPL genutzt hat, für den ist das das hier:

/opt/etherpad/local/etherpad/etherpad-lite/

Ein

git pull origin

im oben genannten Verzeichnis spielt das Update ein.

Die Datei mit den Einstellungen für den EPL Server – settings.jason – kann man hierbei getrost liegen lassen, da diese nicht überschrieben wird.

Nun wird der Benutzerkontext von etherpad mit einem STRG + D wieder verlassen und der EPL Server mit

sudo start etherpad-lite

neu gestartet. Ein

tail -f /var/log/etherpad-lite/error.log

zeigt evtl. entstandene Probleme.

Mir reicht das so: ohne Backups und Dumps. Wenn beim Updateprozess Pads verloren gehen würden – egal. Dann setz ich EPL neu auf und hab wieder ein sauberes Ding.

linuxmuster.net

linuxmusternetlogo

Der Verein linuxmuster.net ist nun aus der Taufe gehoben. Auch wenn man nicht mit Code und eigener Arbeitszeit zum Projekt beitragen kann oder will … Fördermitglieder sind ja auch gerne gesehen, erlauben diese doch die Arbeit der Entwickler an dieser freien Lösung für Schulnetze auf Basis von Debian / Ubuntu.

Man stelle sich schlicht vor, 100 Menschen spenden jeweils einen Jahresbeitrag von 50€. Das tut dem Einzelnen nicht arg weh, entspricht dies doch nicht einmal einer Packung Tabak mit Blättchen und Filter – aber mit dem Geld könnte man für das Projekt schon fast eine Stelle für einen Hauptamtlichen finanzieren.

Ein Traum.

Jetzt muss ich an der Schule noch weiter drängeln, damit wir als Institution mit an Bord kommen. Auf den Weg haben wir uns gemacht – Windows ist in eine Virtuelle Maschine gesperrt, damit auch die Redmondfraktion beruhigt werden kann.

etherpad-lite

UPDATE: https://www.bdjl.de/localhost/?p=5153

Das hier ist sicherlich die hunderste Installationsanleitung im Netz zum Thema Installation von Etherpad Lite unter Ubuntu – aber es ist eine, die bei mir funktioniert hat. Ich werf die jetzt mal hierher, damit ich ein Memo habe (und auf den LFB).

Die Installation von Ubuntu Server ist weder Teil dieser Anleitung noch die Absicherung eines solchen Servers für den Betrieb im Internet. Hier sei lediglich geschildert, wie ein EtherPad Lite (EPL) Server für den Betrieb im lokalen Netz aufgesetzt werden kann.

Die folgende Anleitung wurde für Ubuntu Precise Pangolin (12.04 LTS) geschrieben und auf dieser getestet. Andere Ubuntu Version könnten ebenfalls eine Basis für einen EPL Server darstellen – Sie müssen dann aber selbst herausfinden, wie Sie vorgehen müssen.

Basisinstallation

Melden Sie sich als administrativer Benutzer an Ihrem Server im lokalen Schulnetz an. Wenn Sie eine grafische Oberfläche nutzen, dann öffnen Sie eine Shell.

In einem ersten Schritt legen wir einen Benutzer etherpad für EPL an. Dessen Homeverzeichnis wird /opt/etherpad. Der Benutzer erhält eine Kennung unterhalb der ID 1000 und ist hiermit Systembenutzer (damit er sich nicht direkt am System anmelden kann):

sudo adduser --system --home=/opt/etherpad --group etherpad

Als nächstes kommen die wichtigsten Programme für den Betrieb von EPL an Bord:

sudo apt-get install gzip git-core curl python libssl-dev build-essential abiword python-software-properties

Ubuntu 12.04 enthält zwar node.js (den eigentlichen Server für EPL) in seinen Repositories – es gibt aber ein PPA, das neuere Versionen liefert und diese jeweils auf Zusammenarbeit mit EPL abklopft, so dass wir dieses für die Installation nutzen:

sudo add-apt-repository ppa:chris-lea/node.js

sudo apt-get update

sudo apt-get install nodejs npm

Es folgt der Wechsel in den Benutzerkontext unseres Users etherpad:

sudo su - etherpad -s /bin/bash

Dort werden einige Verzeichnisse und Unterverzeichnisse angelegt:

mkdir ~/local

mkdir ~/local/etherpad

cd ~/local/etherpad

In diesem Verzeichnis wird nun EPL installiert, indem man das Programm aus GIT klont:

git clone git://github.com/ether/etherpad-lite.git

Um einen ersten Testlauf zu starten, wird in das Programmverzeichnis gewechselt

cd etherpad-lite

und Etherpad gestartet

bin/run.sh

EPL ist nun ausschließlich auf dem lokalen Rechner unter der URL

http://127.0.0.1:9001

zu erreichen.

Sofern Ihr Rechner eine grafische Oberfläche hat, können Sie dies auch auf diesem überprüfen. Sind Sie nur in der Shell unterwegs, warten Sie ein wenig ab, bis Sie die Startmeldungen von EPL sehen können. Fortgeschrittene Benutzer können mit netstat -tulpen überprüfen, ob ein Server auf Port 9001 lauscht.

Schießen Sie den EPL Prozess dann mit STRG C ab.

Erreichbarkeit aus dem Schulnetz

Die nächsten Anpassungen sorgen dafür, dass EPL aus dem gesamten Schulnetz heraus aufgerufen werden kann. Wir nehmen dazu an, dass Ihr EPL Server über die IP-Adresse 10.16.2.100 zu erreichen ist.

Öffnen Sie mit dem Editor Ihrer Wahl die Datei

/opt/etherpad/local/etherpad/etherpad-lite/settings.json

Die Einstellungen für die Bezeichnung des EPL Servers, die IP Adresse und die Portnummer werden nun eingetragen:

"title": "Etherpad Lite auf internem Testserver",

// favicon default name
// alternatively, set up a fully specified Url to your own favicon
„favicon“: „favicon.ico“,

//IP and port which etherpad should bind at
„ip“: „10.16.2.100“,
„port“ : 9001,

Weiter unten in diesem Skript (ca. Zeile 70) finden Sie die Möglichkeit, Abiword einzubinden. Das schalten wir gleich scharf:

"abiword" : "/usr/bin/abiword",

Noch ein wenig weiter unten in diesem Skript (ca. ab Zeile 80) finden Sie die Möglichkeit zur Administration des EPL Servers über ein Webinterface. Entfernen Sie das Kommentarzeichen /* in Zeile 80 und in Zeile 91 das Kommentarzeichen */, um diese Funktion zu nutzen. Tragen Sie Kennwörter ein, die den Namen verdienen:

"users": {
"admin": {
"password": "geheim",
"is_admin": true
},
"user": {
"password": "geheim",
"is_admin": false
}
},

Starten Sie nun den EPL Server neu

bin/run.sh

und rufen Sie diesen über die IP 10.16.2.100 von einem anderen Rechner aus auf. Sie sollten diesen demnach unter

http://10.16.2.100:9001

erreichen können und das Admininterface unter

http://10.16.2.100:9001/admin

Schießen Sie EPL mit STRG C aus der Shell wieder ab, um weitere Anpassungen vorzunehmen.

EPL Server für Dauerbetrieb einrichten

Öffnen Sie eine zweite Shell und werden Sie in dieser root:

sudo su -

Sie haben nun zwei Shells: In einer sind Sie noch immer der Benutzer etherpad – in der anderen sind Sie root.

In der root Shell installieren Sie nun einen MySQL Server:

apt-get install mysql-server mysql-common apache2 phpmyadmin mysql-client

Während der Installation werden Sie nach einem MySQL root Passwort gefragt und nach einem Passwort für phpMyAdmin. Vergeben Sie Passwörter, die den Namen auch wirklich verdienen.

Bearbeiten Sie nun die settings.json (Pfad siehe oben) als Benutzer etherpad. Kommentieren Sie den Bereich für die Nutzung von MySQL als Datenbank ein – und den für die „dirty“-DB Datenbank aus:

//The Type of the database. You can choose between dirty, postgres, sqlite and mysql
//You shouldn't use "dirty" for for anything else than testing or development
//"dbType" : "dirty",
//the database specific settings
//"dbSettings" : {
// "filename" : "var/dirty.db"
// },

// An Example of MySQL Configuration
"dbType" : "mysql",
"dbSettings" : {
"user" : "eplite",
"host" : "localhost",
"password": "geheim",
"database": "eplite"
},

Rufen Sie dann phpMyAdmin im Browser auf:

http://10.16.2.100/phpmyadmin

Melden Sie sich als root mit Passwort an, und klicken Sie auf den Tab „Rechte“.

Klicken Sie auf „Neuen Benutzer hinzufügen“

Als Benutzername wählen Sie eplite, als Host localhost und als Passwort wieder eines, das den Namen verdient und das mit dem Passwort in der settings.json – siehe oben: Sie haben es gerade eben eingetragen – übereinstimmt.

Setzen Sie einen Haken bei „Erstelle eine Datenbank mit gleichem Namen und gewähre alle Rechte“.

Klicken Sie im Bereich „Globale Rechte“ auf „Alle auswählen“ und danach auf „Erzeuge Benutzer“.

Wechseln Sie in die Shell und starten Sie einmal als Benutzer etherpad den EPL

bin/run.sh

und stoppen Sie diesen wieder mit STRG C.

Wechseln Sie zurück zum Browser.

Klicken Sie nun in phpMyAdmin auf Datenbanken und dort auf die neu angelegte Datenbank eplite. Klicken Sie auf den Tab SQL. Legen Sie den folgenden Code in das Fensterchen:

ALTER DATABASE `eplite` CHARACTER SET utf8 COLLATE utf8_bin;

USE `eplite`;

ALTER TABLE `store` CONVERT TO CHARACTER SET utf8 COLLATE utf8_bin;

und klicken Sie dann auf den Schalter „OK“. phpMyAdmin sollte zurückmelden, dass alle Befehle erfolgreich umgesetzt wurden.

Starten Sie EPL wieder (als Benutzer etherpad)

bin/run.sh

und rufen Sie dieses im Browser auf

http://10.16.2.100:9001

Ab jetzt schreibt EPL die Daten nach MySQL. Achten Sie auf Fehlermeldungen in Ihrer Shell.

Beenden Sie den EPL Prozess durch STRG C und melden Sie sich durch Eingabe von exit aus dem Shell-Fenster des Benutzers etherpad ab.

Autostart beim EPL Server-Start

In Ihrer root Shell geben Sie nun nacheinander die folgenden Befehle ein, um die Verzeichnisse für die Logfiles zu erstellen und um den Autostart von EPL beim Hochfahren des Rechners einzurichten:

mkdir /var/log/etherpad-lite

chown -R etherpad /var/log/etherpad-lite

Bearbeiten Sie die folgende Datei mit einem Editor Ihrer Wahl. Im Beispiel ist das vi:

vi /etc/init/etherpad-lite.conf

und legen Sie in diese Datei den folgenden Codeschnipsel.

In der root Shell geben Sie nun ein

start etherpad-lite

und der Server sollte starten.

Wenn das geklappt hat, dann fahren Sie das System einmal runter und dann gleich wieder hoch – der EPL Server sollte nun selbst starten und sich über Browser weitgehend verwalten lassen.

Logdateien

Mit der Zeit würden die Logdateien bei einem permanent laufenden EPL Server den Plattenplatz auffressen. Deswegen wird mit den folgenden Einstellungen dafür gesorgt, dass die Logs nach einer Woche zusammen gepackt werden und nur die Logdateien der letzten 4 Wochen auf dem Server liegen bleiben.

In einer root Shell wird mit dem Editor der Wahl die Datei /etc/logrotate.conf bearbeitet und dort der folgende Eintrag eingefügt:

# Etherpad Lite - weekyl compression and rotation

/var/log/etherpad-lite/*.log {

weekly

missingok

rotate 4

compress

notifempty

}

Literatur und Vorlage: https://help.ubuntu.com/community/Etherpad-liteInstallation

GoAccess

accesslogfiles

Logfileanalyse frisst im Normalfall Systemressourcen – nicht viele, aber unnötig viele, wenn man sich nicht wirklich für die Zugriffszahlen interessiert und nur alle paar Wochen einmal guckt. Dazu ein AwStats oder einen Webalizer zu betreiben ist overkill. Der Einsatz von PiWik ist praktisch, aber das Programm hält sich derartig brav an die Do Not Track Einstellungen, dass man nicht erfährt, wie viele Menschen einen wirklich besucht haben. Hier einmal im Vierteljahr vergleichen zu können ist schön.

Praktisch ist ein Tool wie GoAccess, das man nur bei Bedarf einsetzt und das man gezielt auf ausgewählte Logfiles loslassen kann. Das jeweils aktuelle Apache Log holt man sich mit

goaccess -f access.log.1

in den Betrachter. Will man gz archivierte Archive betrachten, muss man diese zuerst auspacken – z.B. mit zcat. Wenn man sich schon die Mühe macht, dann kann gleich ein ganzer Monat zusammen ausgepackt und dann betrachtet werden. Dazu schaut man die Logs in ihrem Verzeichnis zuerst mit ls -lat an, um das Datum etwas einzugrenzen und erzeugt dann ein Gesamtdokument aus der Auswahl:

zcat access.log.[4-7].gz >> accesslogcombined ; goaccess -f accesslogcombined

Wenn man fertig ist, kann man die kombinierte Logdatei wieder löschen.

Neuere Versionen von goaccess – nicht jedoch die für Debian aus den Repos verfügbaren Oldtimer – erlauben auch das Erstellen von HTML Reports. Sehr praktisch. Und viel hübscher als eine nscurses Oberfläche ist es auch.

Oracle Java auf Ubuntu

Oracle Java Pakete von Hand auf einem aktuellen Stand zu halten ist eine blöde Aufgabe – zumindest für Server. Auf dem Desktop mag das ja noch gehen – aber wenn ein Etherpad-Server irgendwo im Netz liegt, dann hätte man doch lieber ein PPA für die Pflege. Ein solches gab es auch eine Zeit lang, wurde dann aber auf Grund von Lizenzgezerfel mit Oracle von Canonical gekillt. Was jetzt bleibt ist die Lösung, die Flexion vorschlägt:

Ein Skript lädt das jeweils aktuelle Java Paket von Oracle herunter, baut daraus DEB Pakete und legt diese in einem lokalen APT-Repository ab. Aus diesem heraus installiert man sich dann die Java Updates.

Eine schöne Idee, die hier näher beschrieben ist:

http://blog.flexion.org/2012/01/16/install-sun-java-6-jre-jdk-from-deb-packages/

Wer direkt auf GitHub nachsehen will, um welche Art Skript es sich handelt, bevor man dieses auf den eigenen Server loslässt, wird hier fündig:

https://github.com/flexiondotorg/oab-java6

paedML auf Virtualbox

Hier hatte ich schon einmal kurz beschrieben, wie man sich eine paedML unter VirtualBox einrichtet. Die aktuelle 5.0.4er paedML brauchte ich neulich (zum Zwecke der Bugsuche auf dem Schulserver) mal wieder und deswegen hier eine Aktualisierung der Hinweise.

Zuerst den IPCop einrichten.

Das erste Interface, das dessen Setup-Prozess findet, wird die grüne Schnittstelle. Deswegen wird die erste Netzwerkkarte in VBox gleich auf inet gesetzt.

Dies gilt selbstverständlich nur, wenn man die Server+IPCop Installation für Testzwecke auf dem heimischen Rechner haben will. Virtualisiert man sich die Installation in der Schule mit Hilfe von VBox (was durchaus so performant ist wie unter Xen oder KVM),  dann würde man in diesem Schritt eine der physikalischen NICs des Wirtsrechners im promiscuous Modus wählen – aber hierzu an anderer Stelle mehr.

Die zweite Schnittstelle im IPCop wird später dann das rote Interface und deswegen steht dieses hier und für den geschilderten Zweck (Spielwiese für zu Hause) auf NAT.

Um die beiden Netzwerkkarten im IPCop-Setup leichter unterscheiden zu können, wählt man sich hier einen anderen NIC Typ aus, als für die erste Schnittstelle. Wer sich total vertut, kann aber auch auf dem IPCop selbst die Kartenzuordnungen ändern, ohne ins Setup zu gehen – hier steht wie.

Im Setup des IPCop dann für GREEN den gewünschten Adressbereich auswählen (10.16.1.1 etc.) – für RED wird DHCP ausgewählt, was einem die restliche Konfiguration erspart (DNS usw). Ist der Cop mal an Bord, dann diesen booten und mit ping überprüfen, ob er ins Netz kommt. Erst weitermachen, wenn auch die Namensauflösung klappt.

Dann den 5.0.4er Server aufsetzen, der bei mir nur mit PAE/NX = aktiv booten wollte:

Dessen Netzwerkkonfiguration ist nun die folgende:

Über die VirtualBox Bridge intnet kommunizieren die beiden miteinander – und auch alle Client-Rechner, die man sich testweise und ebenfalls unter VBox dazu installiert.