Kategoriearchiv: Linux

Alles rund um die Pinguine – auf dem Desktop und dem Server

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)

.kde/share/config

Ralfs KDE Programme zickten heftigst unter Lucid. Beim Starten warfen Sie die Meldung aus, dass Ralf keine Berechtigung habe, in das Verzeichnis .kde/share/config zu schreiben.

Ein Blick auf meinen .kde Ordner zeigte mir:

dirk@server:~$ stat .kde
File: „.kde“
Size: 4096 Blocks: 8 IO Block: 4096 Verzeichnis
Device: 803h/2051d Inode: 3277409 Links: 3
Access: (0700/drwx——) Uid: ( 1001/ dirk) Gid: ( 1001/ dirk)
Access: 2010-07-10 13:55:46.902923310 +0200
Modify: 2010-04-30 08:24:39.539869106 +0200
Change: 2010-04-30 08:24:39.539869106 +0200

Bei Ralf war aus irgendeinem Grund plötzlich (?) root der Besitzer. Der Spuk konnte dann durch ein

sudo chown -R ralf.ralf .kde

behoben werden.

So einfach die Lösung sein mag, aber woher das Problem kam, konnte ich nicht herausfinden.

Acer Travelmate 8471 944G32Mn

Ralf hatte sich schon vor einiger Zeit ein hübsches Notebook von Acer gekauft – mit den üblichen Windowsbeigaben: Vista und XP Pro.

Ich hab gerade ein Ubuntu Lucid 10.04 installiert und musste feststellen, dass das CD/DVD Laufwerk nicht funktioniert. Es liegt an der BIOS Version 1.02. Nach einem Update auf die BIOS Version 1.24 funktioniert das Laufwerk reibungslos, WLan tat schon vorher und auch sonst konnte ich auf die Schnelle keine Zicken mehr feststellen.

Von der MS-Zwangssteuer einmal abgesehen scheint es sich hier um ein auch unter Linux gut laufendes Gerät zu handeln.

Hier zu Dokumentationszwecken für Interessierte die Ausgabe von

sudo lsusb -vv

travelmate8471usb.txt

und die Ausgabe von

sudo lspci -vv

travelmate8471.txt

Das sollte für eine Orientierung reichen.

Sportsline 90

Ich hab mir für unsere Höhlentouren eine wasserdichte Digicam mit Fixfocus zugelegt – eine Rollei Sportsline 90. Für unter 50€ war das Ding ein Schnäppchen, an dem ich nicht vorbeigehen konnte.

Die Kamera ist für Linux geeignet: Mein Lucid 64 erkennt sie als externen Speicher und wie ich gerade feststellte: Über USB angeschlossen und mit Hilfe von Cheese arbeitet sie brav auch als Webcam.

Der Fixfocus der Kamera ist nicht mal so schlecht – meine bisherigen Testaufnahmen können sich sehen lassen. Außerdem ist Fixfocus in Höhlen evtl. besser, weil dann der Autofokus nicht erst sinnlos und ewig einen Punkt im Dunkeln raten muss, auf den er scharfstellen könnte. Eine leidige Erfahrung mit meiner anderen Digicam, die hier manchmal „pumpte“.

Was mir auch gefällt:

  • das Gehäuse fühlt sich stabil an;
  • ein Stativgewinde ist vorhanden;
  • der Blitz füllt zumindest meinen Keller mit Licht;
  • das Gehäuse ist sehr klein;
  • das Gehäuse hat kaum Knöpfe;
  • die Stromversorgung sind zwei AAA Batterien – da kann man Ersatz leicht in die Unterwelt mitnehmen;
  • der Umschalter zwischen Makro- und Telemodus ist mechanisch;

Was mir nicht so gefällt:

  • ein Digitalzoom an einer Fixfokus-Kamera: Da schneide ich lieber mit Hilfe von Gimp ein Detail aus einem Bild, als diesen Pseudozoom zu nutzen;
  • das Objektiv hat keinen Deckel und kann deswegen leicht zerkratzen;
  • die Gehäuseschrauben auf der Vorderseite stehen leicht über;
  • ein Sucher ist nicht vorhanden;

Alles aber kein Drama – wenn sie denn tatsächlich auch unter Wasser dicht hält.

Altgerät

Auf meinem Asus L8400K (einem P III mit 850 Mhz und 300 und ein paar zerquetschten RAM) lief bis heute Morgen ein Xubuntu 8.04 – eigentlich ganz ordentlich. Dazu war noch ein normaler Ubuntu-Gnome- und auch ein KDE-Desktop vorhanden, die sich zwar etwas schwerfällig aber durchaus akzeptabel bedienen ließen. Als Medienplayer arbeitete Amarok – in ausreichender Geschwindigkeit.

Heute wollte ich also Ubuntu 10.04 installieren – was auch ging. Nur die Nutzung war unmöglich. Nach 4 Minuten warten waren noch immer keine Panels nach dem Login zu sehen – dafür aber reihenweise Fehlermeldungen abstürzender Applets. Der Start des Dateimanagers dauert wieder eine Ewigkeit und so ging es grad weiter.

Dann also Xubuntu 10.04 installiert. Das ging nun – aber nicht schneller als zuvor der Gnome Desktop von 8.04.

Jetzt bin ich bei Lubuntu 10.04 angekommen, das sich ungefähr so schnell anfühlt wie zuvor Xubuntu 8.04.

Ubuntu ist fett geworden.

imagemagick

Das Ausgangsbild war dieses hier:

Also erstens zu groß (angestrebt war eine Breite von 150 Pixeln), zweitens im falschen Format (png) und drittens auch noch zu dick, weil mehr als 10kb schwer.

for i in `ls *.png`; do convert $i -resize 150 conv_$i.jpg; done

Ergebnis:

Schwarze Ecken? Das war die Transparenz im PNG. Die musste nun weg und zwar in Richtung weiß.

for i in `ls *.png`; do convert $i -alpha off -resize 150 conv_$i.jpg; done

Ergebnis:

So stimmt’s.

DokuWiki on a stick

Mein DokuWiki on a Stick warf mir auf meinem Lucid heute Morgen die folgende Meldung entgegen:

[error] [client ::1] client denied by server configuration: /media/truecrypt1/DokuWiki/dokuwiki/doku.php

Offensichtlich will der Microapache in seiner httpd.conf den Eintrag 127.0.0.1 nicht mehr fressen.

<Location />
Order Deny,Allow
Deny from all
Allow from localhost
</Location>

Wenn dann allerdings die Konfiguration auf localhost umgestellt wird, dann lässt er mich wieder rein.

DokuWiki Blog zickt

Bei mir zickt das DokuWiki Blog Plugin bei der Installation. Ich trage den Pfad zum Archiv auf der Admin Plugin Seite ein, drücke Enter und die Seite wird weiß. Im Error Log des Apachen steht dann:

?PHP Fatal error:  Cannot redeclare class action_plugin_blog in /var/www/dokuwiki/lib/plugins/blog/action.php on line 215, referer: https://my.dokuwiki.site/doku.php?do=admin&page=plugin

Das Problem ist, dass sich das Archiv mit einem falschen Dateinamen entpackt:

dokufreaks-plugin-blog-a32b5ed

Deswegen hilft ein

mv dokufreaks-plugin-blog-a32b5ed/ blog

in

dokuwiki/lib/plugins

und alles tut wieder.

DreamWeaver 8 auf Lucid 64

… funktionierte einfach überhaupt nicht! Während DW8 unter meinen 32bittigen Laptops unter Lucid einfach das tat, was er die letzten Jahre immer tat – arbeiten – brach der Start des DW unter der 64 Bit Version von Ubuntu Lucid Lynx 10.04 LTS mit der Fehlermeldung

err:module:attach_process_dlls „odbc32.dll“ failed to initialize, aborting

ab. Erst ein Post in den Ubuntuforen brachte mich auf die richtige Spur, nur wusste ich nicht, wie wörtlich ich diesen nehmen sollte. Die Antwort: Sehr wörtlich!

Benötigt wird eine funktionierende Installation von Windows XP. Ist die nicht vorhanden, dann kann man nach den benötigten DLLs auch googlen und welche aus dem Netz verwenden. Ich würde aber dazu raten, diese auf jeden Fall auf Viren zu scannen (clamav – oder noch besser mit Hilfe von Webdiensten).

Lange Vorrede: Man kopiert sich die Dateien

odbcint.dll
odbc32.dll

aus dem Ordner

Windows/system32

des Windowsrechners (aus XP – wenn in Wine XP eingestellt ist) nach

/home/benutzername/.wine/drive_c/windows/system32

Dann stellt man auf dem Reiter von WineCFG (in der Shell mit winecfg aufgerufen oder über das Menü /Anwendungen /Wine /Konfiguriere Wine) ein, dass Wine die odbc32.dll nativ behandeln soll.

Dazu fügt man eine neue Überschreibung hinzu, indem man aus dem Dropdownmenü die odbc32.dll auswählt und dann im kleinen Popup-Fenster ein Häkchen bei „Nativ (Windows)“ macht.

Voila. Einen Bugreport hab ich auch gleich mal dazu geschrieben, in der Hoffnung, dass sich ein Experte darum kümmert. Schließlich sollte Wine Windows emulieren können, ohne derartige Krücken – und konnte dies bisher auch.

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.