Category Archives: paedML

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.

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.

Virtualbox saved state recovery

(C) leonlai @ sxc

Für den Wirtsrechner kam ein neuer Kernel, ein Reboot wurde notwendig. Auf mein Virtualbox Start-Stop-Skript vertrauend startete ich den Wirt neu, ohne vorher die virtuellen Maschinen einzeln anzuhalten oder einzufrieren – was auch bei den meisten reibungslos funktionierte, nicht jedoch bei der virtualisierten paedML. Die warf mir nach dem Reboot die folgende Meldung entgegen:

The VM is missing a block device. Please make sure the source and target VMs have compatible storage configurations

Ein Beitrag im Forum bei Virtualbox lies vermuten, dass die Lösung nah ist. Hier wird empfohlen, in der .vbox Datei den stateFile=”{xxxxxxxxxx-xxxx-xxxx-xxxxxxxx}.sav” Eintrag zu löschen. Leider half das bei mir nicht.

Dafür half es, den saved state zu verwerfen. In der grafischen Oberfläche ist das lediglich ein Klick auf den Knopf Discard. VBox warnt dann, dass dies dem Ziehen des Netzsteckers gleichkomme … was auch nicht weiter schlimm ist. Im dümmsten Fall bekommt fsck Arbeit.

Es geht aber auch auf der Shell mit

vboxmanage discardstate name_der_vm

wie das Handbuch zu VBox ausführt.

Netzwerkkartenwechsel

(C) somadjinn @ sxc

Bei der Virtualisierung bestehender Maschinen erhalten diese in ihrer dann virtuellen Umgebung einen anderen Netzwerkkarten Typ und damit auch eine neue Schnittstellen-Bezeichnung. Dies sorgt dann für Probleme, wenn z.B. eth0 auf eine fixe IP Adresse gelegt war, sich nun die virtuelle Maschine mit der “neuen” Karte aber so fühlt, als hätte diese nur eth1. Diese Schnittstelle ist dann nämlich nicht konfiguriert und die VM kommt nicht ins Netz.

Abhilfe schafft die Bearbeitung der Datei

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

In diese trägt Ubuntu ein, welcher Karte es welche Schnittstellen-Bezeichnung zugewiesen hat und hier kann man dann die nicht benötigten Zuweisungen (an die nicht mehr vorhandenen Karten) löschen und die bestehenden anpassen (also eth1 durch eth0 ersetzen).

Reboot und tut.

Auch praktisch ist dieses Vorgehen auf einem IPCop, der zwei identische NICs verbaut hat. Da darf man im Setup nämlich raten, welche NIC nun welches Netz erhalten hat. Kein Drama, wenn es den IPCop in real gibt. Da steckt man schlicht die Kabel um. Wenn man jedoch einen UnCop aufgesetzt hat und ein Interface an einer Bridge hängt, dann ist das schon fummeliger, weil die Re-konfiguration im Virtualisierer erfolgen muss.

Einfacher geht es durch Anpassung dieser Datei auf dem IPCop selbst:

/var/ipcop/ethernet/settings

Nach einem Reboot klappt es dann wieder mit der Verbindung.

Truecrypt mit Benutzerrechten

(C) CDWaldi @ sxc

Da Lehrer ihren Rechner in einem gemischten Betrieb – privat und dienstlich – einsetzen, müssen diese besondere Vorkehrungen treffen, dass Schülerdaten nicht in fremde Hände gelangen können. Das Programm der Wahl hierzu ist Truecrypt.

Ist man Root an seinem Rechner hat man keine Probleme mit Truecrypt, das für das Einbinden von Tresordateien Adminrechte benötigt. Die treten erst auf, wenn weitere Mitglieder der Familie (oder Kollegen, Schüler etc.) den Rechner ebenfalls nutzen wollen. Diesen nun für das Einbinden von Truecrypt Volumes Adminrechte zu geben ist nicht schlau. Besser ist der folgende Weg:

sudo visudo

startet einen speziellen Editor für die Datei /etc/sudoers. Hier dann am Ende die folgenden Zeilen hinzufügen:

# Truecrypt fuer normale Nutzer

%users  ALL=(root) NOPASSWD:/usr/bin/truecrypt

Jetzt haben alle Mitglieder der Benutzergruppe users die Möglichkeit ohne Eingabe eines Passworts Truecrypt auszuführen. Damit keine Missverständnisse auftreten: Für das Öffnen einer Tresordatei braucht man selbstverständlich weiterhin das zu dieser passende Passwort!

Wer noch radikalere Lösungen bevorzugt, könnte dieses Recht auch allen Nutzern unabhängig von der konkreten Benutzergruppe geben:

ALL  ALL=(root) NOPASSWD:/usr/bin/truecrypt

Weitere Informationen sowie Installations- und Konfigurationshinweise für Windows sind auf dem LFB zu finden. Weitere Informationen rund um sudo Konfigurationsmöglichkeiten sind bei ubuntuusers im Wiki.

OpenLML in Virtualbox

Um linbo für mein Schulnetz zu testen und ein paar neue Geräte, die mit dem Rembo/MySHN der paedML nicht zurecht kommen mit Images zu versorgen hab ich mir auf meinem Laptop die OpenSource Version der paedML mit integriertem IpCop installiert. Im Vorfeld rätselte ich noch herum, wie wohl das Netzwerksetup aussehen müsse, damit der Server dann nach Außen über WLan ins Netz kommt, während die LAN Buchse meines Laptops dann das 10.16er Netz sei, über die dann PXE Boot möglich wäre. Es geht ganz einfach:

Für die “nach Außen” zeigende Netzwerkkarte (ROT – aus Sicht des IpCop) wählte ich eine Intel Karte und stellte diese in Virtualbox auf NAT.

Für die “nach Innen” zeigende Netzwerkkarte (GRÜN – aus Sicht des IpCop) wählte ich zur leichteren Unterscheidung eine PCnet Karte, schloss diese an eine Netzwerkbrücke an und verpasste ihr die Schnittstelle, die auf meinem Laptop das LAN Interface ist – also eth0.

Für Versuche in einem vollständig virtualisierten Netz, in dem auch die Clients auf Virtualbox liefen, stellte ich dann die zweite Netzwerkkarte des Servers wie auch die erste des Clients jeweils um auf Internes Netzwerk.

paedML2twitter

Michael hat mir eine geschickte Exportfunktion für meinen Nagios zukommen lassen. Zu bearbeiten ist

/etc/nagios2/conf.d/linuxmuster_main.cfg

Zusätzlich einzutragen ist:

# ‘external-support’ contact definition
# do NOT change this!
define contact{
contact_name external-support
alias Fernwartung
service_notification_period 24×7
host_notification_period 24×7
service_notification_options w,u,c,r
host_notification_options d,u,r
service_notification_commands notify-by-email
host_notification_commands host-notify-by-email
email geheim@twittermail.com
}

Ob ich das allerdings über längere Zeit so machen werde, weiß ich noch nicht. twittermail.com ist schnarchlangsam. Ich denke im Moment deswegen eher über Jabber oder identi.ca nach. Mal sehen.

MRBS als Klassenarbeitsordner

Das für Moodle ebenfalls erhältliche Zusatzmodul MRBS kann als Klassenarbeitsordner gebraucht werden, in den die Kolleg/innen Ihre Termine eintragen. Hierzu müssen aber ein paar Anpassungen gemacht werden.

Sprachliche Anpassungen

screenshot_001

Als Admin im Moodle anmelden und die Texte von MRBS bearbeiten.

screenshot_002

Dazu die Datei block_mrbs.php auswählen und dort alles was nach Raumbuchung klingt durch Klassenarbeitsordner ersetzen.

Ich habe hier die Raumkategorien (Bereiche) als Stufen angelegt und die Räume als Klassen. Außerdem hab ich “Klasse/Lehrer” durch “Eintrag für Fach” ersetzt.

Weitere Modulanpassungen

Weiter macht es Sinn, nicht Stunden eingetragen zu haben, sondern “Slots” für Klassenarbeiten – sonst fangen die Kollegen an, parallel unterichtete Fächer wie Ethik, kath Rel und ev Rel (oder auch Spanisch, Französisch, NwT) an verschiedenen Tagen einzutragen, in der Annahmen, “Ihre Stunde” sei schon besetzt. Das führt zu einer schnellen Verknappung an Tagen, die überhaupt für Klassenarbeiten zur Verfügung stehen.

Außerdem sollten die MRBS-Kategorien “Intern” und “Extern” durch “Klassenarbeit” und “Test” ersetzt werden. Ich hab noch zusätzlich die Kategorie “geblockt” eingeführt – man weiß ja nie.

Alle diese Einträge finden sich im Moodle Administrationsmenü unter Module /Blöcke / MRBS, was einem Moodle-Admin durchaus bekannt sein dürfte.

Aufrufen des Berichts

screenshot_003

Aufgerufen wird der Klassenarbeitsordner für die Erstellung eines Aushangs dann durch Klick auf [Bericht] in der MRBS Oberfläche.

screenshot_004

Einzutragen ist bei “Suche Klasse” die Klasse und auszuwählen ist “Test” bzw. “Klassenarbeit” als Kategorie. Ein Klick auf den Schalter [Bericht erstellen] wirft diesen aus.

Auf der Seite mit dem Bericht nun nach Unten scrollen und auf Druckansicht klicken, Seite ausdrucken und im Klassenzimmer aushängen. Fertig.

Anmerkungen: Ideal wäre es, den Klassenarbeitsordner den Schülern mit reinen Leserechten online zur Verfügung zu stellen, dann können die sich gleich im Moodle informieren. Das macht aber nicht jede Personalvertretung mit.

Weiter kann für jeden Raum (hier: Klasse) eine Mailadresse eingerichtet werden (Raumadministrator), die alle Einträge und Veränderungen zugeschickt bekommt. Wenn hier als Empfänger ein Listendaemon eintragen wird (Mailman), der die Mails an die Klassenmailingliste weiter verteilt, sind alle glücklich!

Anhübschen und Datensparsamkeit

Leider sieht der Bericht nun nicht hübsch aus, weil er viele Zusatzinfos mit sich bringt, die eine Klasse nicht haben muss (wer hat was wann eingetragen und verändert). Diese Informationen müssen auf Modulebene bearbeitet werden:

Dazu wurden die Zeilen 192-195 in der report.php auskommentiert, nachdem diese zuerst als report.php.bak gesichert wurde:

# Created by and last update timestamp:
 # echo "<tr><td class=\"BL\" colspan=2><small><b>".get_string('createdby','block_mrbs')."</b> " .
 # htmlspecialchars($row[6]) . ", <b>".get_string('lastmodified')."</b> " .
 # time_date_string($row[7]) . "</small></td></tr>\n";

Und jetzt funktioniert’s und sieht ordentlich aus.

cups

Updates von CUPS kommen regelmäßig – und fallen auf der paedML 4  fast immer auf die Schnauze mit der folgenden Fehlermeldung:

Fehler traten auf beim Bearbeiten von:
 cupsys
E: Sub-process /usr/bin/dpkg returned an error code (1)
Ein Paket konnte nicht installiert werden. Versuche zu lösen:
Richte cupsys ein (1.2.7-4etch7) ...
ln: Erzeugen der harten Verknüpfung „/usr/lib/cups/backend/dnssd“ zu „/usr/lib/cups/backend-available/dnssd“: Die Datei existiert bereits
dpkg: Fehler beim Bearbeiten von cupsys (--configure):
 Unterprozess post-installation script gab den Fehlerwert 1 zurück
Fehler traten auf beim Bearbeiten von:
 cupsys

Zur Serverrettung in diesem Fall dann:

cd /usr/lib/cups/backend/
mv dnssd dnssd.paedml4.backup5

… oder ein anderer Dateiname – hauptsache die alte dnssd ist aus dem Weg.

Ein erneutes

aptitude dist-upgrade

funktioniert dann:

Paketlisten werden gelesen... Fertig
Abhängigkeitsbaum wird aufgebaut... Fertig
Lese erweiterte Statusinformationen
Initialisiere Paketstatus... Fertig
Lese Task-Beschreibungen... Fertig
Erzeuge Tag-Datenbank... Fertig
Es werden keine Pakete installiert, aktualisiert oder entfernt.
0 Pakete aktualisiert, 0 zusätzlich installiert, 0 werden entfernt und 0 nicht aktualisiert.
Muss 0B an Archiven herunterladen. Nach dem Entpacken werden 0B zusätzlich belegt sein.
Richte cupsys ein (1.2.7-4etch7) ...
Starting Common Unix Printing System: cupsd.

IPCop Memo

Es sieht so aus, als würde 2009 noch das Jahr des IPCop werden. Jetzt spinnt der paedML Linux Cop meiner Schule auch noch – und trennt uns dauernd vom Netz.

Hier eine Reihe von Memos zum Thema – mehr für mich, als für andere:

Neuinstallation

Bei Konfigurationsproblemen nach dem Neuaufsetzen des paedML IPCops hilft es wohl, vorher den Inhalt von

/var/backup/linuxmuster/ipcop/

zu löschen und dann nochmal den IPCop nach Handbuch aufzusetzen. Ausführlichere Informationen zur Neuinstallation sind hier zu finden.

Trennungsschmerzen

Ich hoffe mal, dass ich meinen IPCop jetzt wieder im Griff habe. Ziemlich schnell hatte ich für die dauernd um 9, 12 und 15 Uhr erfolgenden Trennungen vom Netz den Squid im Verdacht. Das hat sich nun erhärtet. Auf die Spur gebracht hat mich freshclam, das nicht mehr wollte:

# freshclam
ClamAV update process started at Sat Jan 24 19:29:24 2009
main.cld is up to date (version: 49, sigs: 437972, f-level: 35, builder:
sven)
connect_error: getsockopt(SO_ERROR): fd=4 error=111: Connection refused
Can’t connect to port 80 of host db.local.clamav.net (IP: 130.59.10.36)
Trying host db.local.clamav.net (193.1.193.64)…

usw usw. Auf der Suche nach einer Ursache bin ich auf einen Fehler in unserer squid.conf gestoßen, der den sauberen Restart des Squid nach dem Neuaufbau des Caches verhindert.

Auf dem IPCop:

# /usr/local/bin/restartsquid
2009/01/24 19:36:03| squid.conf line 14: acl QUERY urlpath_regex cgi-bin ?
2009/01/24 19:36:03| aclParseRegexList: Invalid regular expression ‘?’:
Invalid preceding regular expression
2009/01/24 19:36:03| Creating Swap Directories
2009/01/24 19:36:14| squid.conf line 14: acl QUERY urlpath_regex cgi-bin ?
2009/01/24 19:36:14| aclParseRegexList: Invalid regular expression ‘?’:
Invalid preceding regular expression

Sieht offensichtlich nicht gut aus.

# vi /var/ipcop/proxy/squid.conf

Dort stand in Zeile 14:

acl QUERY urlpath_regex cgi-bin ?

Es müsste aber lauten – so zeigte ein Vergleich mit meinem eigenen IPCop:

acl QUERY urlpath_regex cgi-bin \\?

Das hab ich verändert und dann den Squid auf dem IPCop neu gestartet:

# /usr/local/bin/restartsquid
2009/01/24 19:44:02| Creating Swap Directories

Jetzt geht freshclam vom Server aus wieder (das so oder so automatisiert ist):

# freshclam
ClamAV update process started at Sat Jan 24 19:36:33 2009
main.cld is up to date (version: 49, sigs: 437972, f-level: 35, builder:
sven)
Downloading daily-8896.cdiff [100%]
Downloading daily-8897.cdiff [100%]
Downloading daily-8898.cdiff [100%]
Downloading daily-8899.cdiff [100%]
daily.cld updated (version: 8899, sigs: 61181, f-level: 38, builder: edwin)
Database updated (499153 signatures) from db.local.clamav.net (IP:
130.59.10.36)
Clamd successfully notified about the update.

Jetzt bin ich mal gespannt. Komisch ist es aber schon, dass ein backslash so einfach verschwinden kann.