Archiv der Kategorie: Schule

Serienbrief in OOo

Für einen Serienbrief mit OpenOffice den Assistenten von OOo zu bemühen, macht mehr Stress:

Vorbereitung: In einem OOo Calc Sheet die Tabelle mit den Namen, Vornamen und sonstigen Feldern anlegen und dieses speichern.

In OOo Writer den gewünschten Text verfassen, der nur noch um die entsprechenden Einträge aus dem Calc Sheet ergänzt werden muss. Beachte: Nicht die Funktionen für Serienbriefe in OOo-Writer nutzen – wir gehen hier einfachere Wege.

In OOo Writer die Taste [F4] drücken, um die möglichen Datenquellen angezeigt zu bekommen (alternativ über das Menü /Ansicht /Datenquellen).

Hier auf die Taste [Serienbriefbedingungen] klicken.

Im aufpoppenden Fenster auf den Schalter [Datenquelle zuweisen] klicken.

Durch einen Klick auf [Durchsuchen] öffnet sich der Dateimanager.

Im Dateimanager das Tabellendokument auswählen, das die Namen etc. enthält. [Öffnen] anklicken.

Das Fenster für den Datenbankaustausch wieder [Schließen].

Die Überschriften (nicht die Inhalte!) mit der Maus in das OOo Writer Dokument ziehen. Der entsprechende Feldname wird dann dort eingesetzt.

Ein [Strg] [P] oder über das Menü /Datei /Drucken löst die Rückfrage von OOo aus, ob man einen Serienbrief drucken möchte. [Ja] – das wollen wir.

Im Druckdialog dann die gewünschten Einstellungen vornehmen.

Ich wähle diese meist so, dass die Ausgabe mir einzelne PDFs liefert, wobei das Feld <Name> den Dateinamen ergibt.

rsync über ssh mit Hop

Einer meiner Laptops steht in der Schule – also hinter einer Firewall und nur über seine schulinterne IP erreichbar. Angenehm ist, wenn der Datenbestand auf dieser Maschine dem Datenbestand auf meinem heimischen Arbeitsplatzrechner entspricht. Bisher trug ich den Schullaptop deswegen immer in den Ferien mit nach Hause, synchronisierte diesen im heimischen Netz und nahm diesen dann am ersten Schultag wieder mit zum Arbeitsplatz. Der Datenbestand hinkte demnach etwas hinterher.

Für eine Erstsynchronisation ist dieses Vorgehen immer noch ratsam. Aber jetzt aktualisiere ich öfter – mit Hilfe von rsync über ssh und einem Hop über einen anderen Rechner im Schulnetz, der – so zu sagen – „in der Mitte“ steht, von Außen erreichbar ist und immer am Netz hängt. Ich nenne diese Maschine hier „rechnermitte“.

Die Maschine rechnermitte ist nicht über den Standard SSH Port 22, sondern (sagen wir mal) über Port 2244 zu erreichen. Der SSH Server auf dem Schullaptop jedoch hört auf Port 22.

Hinweis: Damit keiner Blödsinn mit meinem Schullaptop macht, ist der Login über SSH nur für einen bestimmten User (hier: schullaptopnutzer) erlaubt und außerdem hab ich auf diesem als zusätzliche Hürde fail2ban installiert.

Zuerst wird ein SSH-Tunnel zum Schullaptop geöffnet, und zwar so, dass dessen Port 22 über rechnermitte an den Port 2223 am Heimarbeitsplatz (localhost) gebunden wird:

ssh -L 2223:interne_ip_schullaptop:22 user_mitte@rechnermitte.schuldomain.de -p 2244

Der Aufruf verlangt nach dem Passwort für user_mitte auf rechnermitte.

Steht diese Verbindung, kann ich meinen Schullaptop vom heimischen Rechner aus schon wie folgt über SSH erreichen:

ssh schullaptopnutzer@localhost -p 2223

Es folgt der Aufruf von rsync auf dem heimischen Rechner, mit dem Ziel, die zu Hause geänderten Daten auf den Schulrechner zu übertragen (umgekehrt geht das auch – aber das ist nicht Teil dieser Beschreibung):

rsync -r -t -p -x -v –progress –delete -z /home/heimrechnernutzer/Dokumente/Schule/ –rsh=’ssh -p2223′ schullaptopnutzer@localhost:/home/schullaptopnutzer/Dokumente/schule

Selbstverständlich dauert eine derartige Synchronisation über das Internet wesentlich länger – ich hab hier nur „Bauern-DSL“ und entsprechend niedrige Upload-Raten. Aber es klappt trotz aller Einschränkungen erstaunlich flott – die Zeit für das Abendessen reicht fast immer.

Nach einer erfolgreichen Synchronisation kann ich den Schullaptop dann von zu Hause aus herunterfahren.

Vereinfachend für mich ist, dass ich auf dem Schullaptop nur selten viele Dateien überarbeite: Die Maschine dient im Wesentlichen als Präsentationsrechner. Wenn doch umfangreichere Änderungen vorgenommen werden, dann schick ich mir diese meist per Mail oder werf sie nach Dropbox, so dass ich extrem selten einen rsync vom Laptop in Richtung Heimrechner benötige. Sollte dies sich ändern, dann käme evtl. noch unison ins Spiel und würde weitere Vereinfachungen ermöglichen: http://wiki.ubuntuusers.de/Unison

Eine gute Sammlung verschiedener Methoden für rsync über ssh liefert die folgenden Website inklusive Sicherheitshinweise: http://samba.anu.edu.au/rsync/firewall.html

Umbenennen Versionitis

Hier habe ich ein Skript veröffentlicht, das mir am LFB dazu dient, mehrere Verzeichnisse und die darin enthaltenen Dateien von Leerzeichen, Großbuchstaben, Umlauten und Ligaturen rekursiv zu reinigen.

Inzwischen arbeitet auch meine Linux AG daran und wird hoffentlich aktualisierte Versionen hier im KvFG Wiki veröffentlichen. Meine aktuellste Version liegt schon da.

etherpad v 1.1

Das Update auf etherpad 1.1 auf dem Ubuntu 10.04 Server meiner Computer AG lief zwar reibungslos durch, aber etherpad bekam nach dem Update den Hintern nicht mehr hoch. Auch händische Startversuche scheiterten ohne jegliche Rückmeldung. Als Problem identifizierte ich auf diesem Server das Startskript in

/etc/init.d/etherpad

Hier steht als lokales Installationsverzeichnis

DAEMON_BASE=“/usr/local/etherpad“

Für Version 1.1 müssen aber entsprechende Anpassungen vorgenommen werden:

DAEMON_BASE=“/usr/share/etherpad“

Die Start- und Stop-Skripte

/etc/rc0.d/K95etherpad
/etc/rc1.d/K95etherpad
/etc/rc2.d/S05etherpad
/etc/rc3.d/S05etherpad
/etc/rc4.d/S05etherpad
/etc/rc5.d/S05etherpad
/etc/rc6.d/K95etherpad
/etc/rcS.d/K95etherpad

müssen dann nicht mehr weiter händisch angepasst werden, sondern übernehmen auf Grund der Verlinkung den Eintrag.

Weitere Punkte zum Update oder Skripte mit dem falschen Pfad sind mir bisher nicht aufgefallen – können aber durchaus noch zu finden sein. Ich freu mich jetzt mal, dass die alten Pads das Update überlebt haben und mein Server wieder rund läuft.

Sobby

Der Editor gobby hat ein paar unschlagbare Vorteile: Mehrere Menschen können gemeinsam an einem Dokument in Echtzeit (naja – fast) arbeiten und außerdem bringt er Syntax-Highlighting für auch die wildesten Sprachen mit.

Im Normalfall installieren sich alle, die diese Funktionen nutzen wollen gobby

sudo apt-get install gobby

auf dem lokalen Client und einer stellt seinen Editor dann als Serverinstanz ins lokale Netz.

Die Nachteile dieses Vorgehens sind aber offensichtlich: Das gemeinsam bearbeitete Dokument ist nur im Intranet zu erreichen und sobald der Nutzer, der den Gobbyserver gestartet hat, seine Arbeit beendet, haben auch alle anderen Bearbeiter des Dokumentes keinen Zugriff mehr.

Eine Alternative ist sicherlich etherpad: Freie Server stehen im Netz zu Hauf zur Verfügung (eine Übersicht bietet diese Seite: http://etherpad.org/etherpadsites.html), aber die Installation eines eigenen etherpad Servers ist kein Zuckerschlecken und frisst auch einiges an Hardware-Ressourcen – wie hier ausführlich beschrieben.

Viel einfacher und auch Ressourcen-schonender geht es mit einem Sobbyserver und ein solcher ist nun auch auf Karlchen, dem Server meiner Computer-AG, am Laufen. Informationen zur Installation, Konfiguration und zum Start sind hier im KvFG Wiki zu finden.

Die Nachteile von sobby / gobby sind jedoch klar: Auf dem jeweiligen Client muss gobby in einer passenden Version installiert sein und ein Versionsmanagement bringt der Sobbyserver leider auch nicht mit. Dafür ist gobby jedoch als Portable App zu haben. Bleibt also das fehlende Versionsmanagement, das nur durch regelmäßiges Speichern der bearbeiteten Dokumente auf dem lokalen Client „geheilt“ werden kann.

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.

etherpad

Die c’t von heute hat einen Artikel zur Installation von etherpad auf debianoiden Linuxen veröffentlicht, den ich gerade in einer VM unter Debian 5 nachzuvollziehen versuche. Der Artikel scheint jedoch für Ubuntu geschrieben worden zu sein. Unter Debian 5 will es wie von der c’t beschrieben einfach nicht klappen – und aus diesem Grund hier eine veränderte und erweiterte Anleitung, die hoffentlich Idioten sicher ist:

Zuerst kommt die Installation eines Debian5-Minimalsystems dran. Dann als root

deb http://apt.etherpad.org all .
deb http://ftp.de.debian.org/debian  sid main non-free

in die /etc/apt/sources.list eintragen. Ein

apt-get update

aktualisiert die Paketliste. Aufpassen: Durch das SID Repo würde ein apt-get dist-upgrade zu einem Wechsel von der stable Version von Debian zu Sid führen. Wer das vermeiden will, sollte das Repo für Sid nach Fertigstellung der ehterpad-Installation dann wieder aus der sources.list auskommentieren. Die Fehlermeldungen wegen den evtl. nicht vorhandenen Keys (auf’s Erste) ignorieren. Ein

apt-get install  sun-java6-jdk

führt zur Installation der folgenden zusätzlichen Pakete:

avahi-daemon dbus gsfonts gsfonts-x11 java-common libasound2 libavahi-common-data libavahi-common3 libavahi-core7 libc-bin libc6 libc6-i686 libdaemon0 libdbus-1-3 libexpat1 libfontenc1 libfreetype6 libltdl7 libncurses5 libnss-mdns libreadline6 libx11-6 libxcb1 libxfont1 libxi6 libxtst6 locales odbcinst odbcinst1debian2 sun-java6-bin sun-java6-jre unixodbc xfonts-encodings xfonts-utils

Insgesamt landen hier rund 75 MB an zusätzlichen Daten aus dem Netz auf dem Rechner und brauchen ca. 180 MB an Platz nach der Installation. Wegrennen kann man in dieser Phase nicht, weil (neben einigen anderen notwendigen Userinteraktionen) die Lizenzbedingungen von Sun abgenickt werden müssen.

Ein

java -version

sollte die folgende Ausgabe bringen:

java version „1.6.0_20“
Java(TM) SE Runtime Environment (build 1.6.0_20-b02)
Java HotSpot(TM) Client VM (build 16.3-b01, mixed mode, sharing)

Wenn nicht, dann ist die Sun Java VM mit dem folgenden Befehl als Default einzurichten:

update-alternatives –config java

Es folgt die Installation des mysql Servers sowie der Verbindungssoftware zwischen Java und dem Datenbankserver. Ich zieh mir hier auch gleich noch phpmyadmin und einen Apachen:

apt-get install scala mysql-server libmysql-java mercurial phpmyadmin apache2

Debian zieht sich nun

apache2-mpm-prefork apache2-utils apache2.2-bin apache2.2-common dbconfig-common fontconfig-config javascript-common libapache2-mod-php5 libapr1 libaprutil1 libaprutil1-dbd-sqlite3 libaprutil1-ldap libdb4.7 libdb4.8 libdbd-mysql-perl libdbi-perl libfontconfig1 libgd2-xpm libgssapi-krb5-2 libhtml-template-perl libjpeg62 libjs-mootools libk5crypto3 libkrb5-3 libkrb5support0 libmcrypt4 libmysqlclient16 libnet-daemon-perl libonig2 libpcre3 libplrpc-perl libpng12-0 libqdbm14 libsqlite3-0 libssl0.9.8 libt1-5 libuuid1 libxml2 libxpm4 make mercurial-common mysql-client-5.1 mysql-common mysql-server-5.1 mysql-server-core-5.1 openssl perl perl-base perl-modules php5-cli php5-common php5-gd php5-mcrypt php5-mysql php5-suhosin psmisc python-support scala-library ssl-cert wwwconfig-common

und lädt hierzu 67 MB aus dem Netz. Nach der Installation ist der Plattenplatz wieder um 130 MB kleiner.

Bei der Installation ist dann das mysql root-Passwort anzugeben und dieser für den Apachen zu konfigurieren (ist nur ein Klick in einem Auswahlfenster). Weiter ist der administrative Benutzer für phpmyadmin anzugeben und ein Passwort zu setzen.

Jetzt kann man im Browser durch Aufruf der IP / Domain des Servers mal nachsehen, ob alles geklappt hat und der Server sowie phpmyadmin erreichbar sind.

In die Datei /etc/profile wird nun der folgende Code hinzugefügt, damit alle Komponenten sich auch gegenseitig finden können:

export JAVA_HOME=“/usr/lib/jvm/java-6-sun“
export SCALA_HOME=“/usr/share/java“
export JAVA=“/usr/bin/java“
export SCALA=“/usr/bin/scala“
export PATH=“/usr/bin:/usr/bin:/usr/local/mysql/bin:$PATH“
export MYSQL_CONNECTOR_JAR=“/usr/share/java/mysql-connector-java-5.1.10.jar“
export JAVA_HOME SCALA_HOME JAVA SCALA MYSQL_CONNECTOR_JAR PATH

Ein

echo $PATH

zeigt, ob es mit den Exporten klappt. Wenn nicht, dann entweder „sourcen“ oder ab- und wieder anmelden und erneut überprüfen.

Ein

apt-get install etherpad

zieht die notwendigen Abhängigkeiten mit sich. Man sollte hier aber nicht wie gewohnt ein paar Mal [Enter] drücken, sondern beachten, dass auf Grund der fehlenden Keys für die neu hinzugefügten Repos die Vorauswahl von Debian bei der Rückfrage, ob man nicht vertrauenswürdige Pakete einspielen will, auf Nein steht. Das sieht so aus:

WARNUNG: Die folgenden Pakete können nicht authentifiziert werden!
etherpad
Diese Pakete ohne Überprüfung installieren [j/N]? j

Rund 30 MB werden aus dem Netz geholt, die nach der Installation weitere 44 MB belegen werden. Während der Installation sind dann wieder das mysql root Passwort anzugeben (damit etherpad seine Datenbank anlegen kann). Außerdem ist der administrative Benutzer für Etherpad anzugeben und auch die Domain, unter der etherpad zu erreichen sein soll. Der Eintrag localhost ist hier entsprechend zu ergänzen.

In der Datei

/usr/share/etherpad/etherpad/bin/run-local.sh

sind ist noch eine Anpassungen nötig: Ziemlich weit oben in diesem Startskript steht

MXRAM=“1G“

Das ist für die ersten Tests ein wenig viel, schreibt die c’t, und meint, der folgende Eintrag würde auch reichen:

MXRAM=“128m“

Hervorzuheben ist, dass hier nicht 128MB oder 128M stehen darf, da sonst ein Syntaxfehler moniert wird. In vielen Anleitungen im Netz ist das aber der Fall. Komisch.

Die während der Installation gemachten Angaben sind dann hier

/etc/etherpad/etherpad.local.properties

zu finden und können falls nötig angepasst werden. Ich habe am Ende noch die Zeile

etherpad.skipHostnameCheck = true

eingefügt, um später weniger Probleme zu bekommen. Hier besteht aber auch die Möglichkeit, den etherpad Server auf HTTPS umzubiegen. Gelogt wird im default nach

/var/log/etherpad

Da das Startskript in /etc/init.d/etherpad extrem schweigsam ist, empfiehlt sich für den ersten Start die Nutzung von run-local.sh im oben angegebenen Verzeichnis.

root@debian5:/usr/share/etherpad/etherpad# ./bin/run-local.sh

Wichtig ist hier, dass der etherpad Server wirklich aus dem Verzeichnis /usr/share/etherpad/etherpad heraus gestartet wird, sonst erhält man die Fehlermeldung

Using config file: ./etc/etherpad.localdev-default.properties
Exception in thread „main“ java.lang.NoClassDefFoundError: net/appjet/oui/main
Caused by: java.lang.ClassNotFoundException: net.appjet.oui.main
at java.net.URLClassLoader$1.run(URLClassLoader.java:202)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:190)
at java.lang.ClassLoader.loadClass(ClassLoader.java:307)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301)
at java.lang.ClassLoader.loadClass(ClassLoader.java:248)
Heap
def new generation   total 14784K, used 263K [0x9f880000, 0xa0880000, 0xa0880000)
eden space 13184K,   2% used [0x9f880000, 0x9f8c1ec8, 0xa0560000)
from space 1600K,   0% used [0xa0560000, 0xa0560000, 0xa06f0000)
to   space 1600K,   0% used [0xa06f0000, 0xa06f0000, 0xa0880000)
concurrent mark-sweep generation total 245760K, used 0K [0xa0880000, 0xaf880000, 0xaf880000)
concurrent-mark-sweep perm gen total 16384K, used 1567K [0xaf880000, 0xb0880000, 0xb3880000)
Could not find the main class: net.appjet.oui.main.  Program will exit.

Jetzt kann etherpad auch auf der Shell mit dem Browser links2 erreicht werden:

links2 http://localhost:9000/

Damit der Server auch über Port 80 und nicht nur lokal zu benutzen ist, passen wir den Apache an.

a2enmod proxy_http
/etc/init.d/apache2 restart

Der folgende Code kommt in die Apache Konfigurationsdatei:

<IfModule mod_proxy_http.c>
ProxyPass               /       http://localhost:9000/
ProxyPassReverse        /       http://localhost:9000/
ProxyPreserveHost       on
<Proxy http://localhost:9000/>
Order Allow,Deny
Allow from all
</Proxy>
</IfModule>

der daraufhin einen restart braucht:

/etc/init.d/apache2 restart

Wenn man dann immer bei einer komischen Seite mit dem Namen „false“ landet, liegt es an der Konfiguration von etherpad. Ein Eintrag der IP des Servers hinter

topdomains =

in

/etc/etherpad/etherpad.local.properties

und nachfolgendem Neustart von etherpad und Apache erledigt das Problem.

Und nach dem vielen Text, hier dann endlich das Ergebnis mit Bild:

Ich muss schon sagen: Die Herren Jo Bager und Alvar Freude machen es sich in der c’t doch ein wenig einfach 🙂 Ohne meinen Basteltrieb hätte ich zügig wieder aufgegeben.

Sicherheitstechnisch ist der etherpad-Server, den ich hier beschreibe, nicht eine Bohne wert – aber für das interne Netz müsste es reichen. Hoffentlich. Sobald ich das Ding dann in meiner Schule am laufen habe, werde ich die Konsequenzen ja miterleben und auch mittragen. Für einen solchen Einsatzzweck sollte man dann screen für den Start im Hintergrund nutzen – oder mit nohup arbeiten, vor allem aber die Namensauflösung in den Griff bekommen und so evtl. um den Apache-Proxy rumkommen. Ob man hierzu etherpad aus den Quellen selbst kompilieren muss – das will ich heute nach dem ganzen Gefrickel gar nicht wissen.

Quellen, Ideen und vor allem Problemlösungen gibt es hier:

http://oceanobservatories.org/spaces/display/~gadavis/Etherpad+Migration

http://mclear.co.uk/2010/03/10/installing-etherpad-on-debian/

Diesen Text habe ich auch – etwas geglättet – auf dem LFB veröffentlicht: http://lehrerfortbildung-bw.de/werkstatt/sonstige/txtimnetz/1_ethpad.htm

Siehe hierzu auch: http://www.bdjl.de/localhost/?p=1489 (Update auf etherpad 1.1)

DokuWiki und Google

Obwohl eine DokuWiki Seite von mir schon längere Zeit online war, wurde diese scheinbar nicht von Google gefunden. Also setzte ich die Google Webmastertools ein, um die Indexierung etwas zu beschleunigen.

Um die Webmastertools nutzen zu können, muss in die jeweilige Seite im Kopf ein Eintrag gesetzt werden, der Google versichert, dass man selbst Besitzer der Seite ist:

<meta name="google-site-verification" content="C8uYblaehfAseLMurksblablaRN8INewX" />

Dieser Eintrag gehört in

lib/tpl/themename/main.php

In diesem Zusammenhang fiel mir dann auf, dass DokuWiki im Seitenheader ein noindex und nofollow stehen hat und sich so doch sehr verschlossen zeigt. Ein Artikel zu diesem Thema brachte mich auf die richtige Spur.

In der Datei conf/local.php können einige Anpassungen von Hand vorgenommen werden, die DokuWiki für Suchmaschinen besonders attraktiv macht:

$conf['userewrite'] = 2;
$conf['useslash'] = 1;

Eine tiefer gehende Beschreibung ist hier zu finden.

Allerdings schoss mir diese Einstellung – im Zusammenhang mit weiteren, die ich gleich nennen werde – jedoch das Blogsystem von DokuWiki kaputt, das nicht alle Umstellungen gut verkraftet. Dies gilt zumindest dann, wenn das Blog wie auf http://www.kvfg.info auf der Startseite eingebunden wird.

Über /Admin /Konfiguration lassen sich die wichtigsten Einstellungen auch ohne direkten Eingriff in die conf/local.php setzen:

Dies – und die Webmastertools selbst – sorgen nun für suchmaschinenverträglichere Einträge im Header der Site. Ein

http://dokuwikiseite.domain/lib/exe/indexer.php?debug=1

prüft, ob die Sitemap erzeugt werden kann. Will das nicht gleich klappen, dann sollte diese mit

touch sitemap.xml.gz

im Webroot von DokuWiki so angelegt werden, dass der Webserver schreiben kann. Ob alles geklappt hat, kann dann mit

http://dokuwikiseite.domain/sitemap.xml.gz

überprüft werden: DokuWiki müsste die Datei zum Download anbieten. Hat alles funktioniert, dann macht man diese Datei nun wiederum den Webmastertools bekannt, die sofort Erfolg oder Misserfolg zurückmelden.

Mehrseitendruck

Der Ausdruck von mehreren Seiten auf ein Din A4 Blatt lässt sich unter Linux vielfältig organisieren. gtklp ist eine Möglichkeit, die ich hier schon beschrieben habe. Auf der shell eigenet sich psnup oder auch mpage.

Dabei kann zumindest OpenOffice das auch von sich aus – und zwar aus der Seitenansicht heraus.

Zuerst werden in der Seitenansicht selbst die „Druckoptionen Seitenansicht“ aufgerufen – das ist das Icon mit der zeigenden Hand links vom „Seitenansicht schließen“ Knopf.

Hier kann die Aufteilung der zu druckenden Seiten auf das Einzelblatt eingestellt werden.

Zum Abschluss den Schalter „Seitenansicht drucken“ in der Seitenvorschau anklicken.

Bugtracker für Moodle

Das Moodle Bug Tracker Modul ist praktisch  – für Seiten, die nicht zu viele Ansprüche an eine derartige Software stellen, sondern wie ich in der Schule erfassen müssen, welcher PC welches Problem hat.

Leider fällt das Modul auf einem „deutschen Moodle“ auf die Nase, weil ihm eine Kleinigkeit fehlt: Das deutsche Sprachmodul.

Also wechselt man in das Verzeichnis des Trackers und dort in das Unterverzeichnis mails/. Auf vielen Systemen dürfte dies einem Pfad wie dem folgenden entsprechen:

…/moodle/mod/tracker/mails

Dort kopiert man nun das englische Verzeichnis schlicht unter einem neuen Namen durch Eingabe von:

cp -rp en_utf8/ de_utf8/

Jetzt klappt die Erfassung von neuen Meldungen – wenn auch nicht komplett auf Deutsch.