Login, bitte

Login, bitte

Aus Gründen die ich später sicher nochmal erläutern werde möchte ich ein Dokumentenmanagementsystem (DMS) installieren. Die Wahl fällt Heute auf Alfresco, einem kommerziell entwickelten System von dem es eine kostenlos nutzbare Community-Version gibt.

Haken an der Sache: das ist eine Java-Anwendung, und die drückt ganz schön auf mein kleines Heimserverchen. Um es nicht zu sehr ausarten zu lassen möchte ich nach Möglichkeit kein volles KVM installieren, sondern in einem OpenVZ-Container (wir erinnern uns: ich habe Proxmox auf meinem Server installiert). Problem dabei: in OpenVZ habe ich nur 32-Bit-Gäste, und der vergleichsweise einfach zu bedienende Installer von Alfresco läuft nur auf 64 Bit.

Also zu Fuss. Und da ich zwar mehrere Anleitungen gefunden habe, keine davon aber wirklich alle meine Probleme gelöst hat, schreibe ich hier mal zusammen was ich gemacht habe. Ich installiere erstmal nur das Basispaket, Zusatzmodule kommen bei Bedarf später nach.

Noch ein Disclaimer vorweg: alles was hier steht ist gefährliches Halbwissen! Meine Erfahrungen mit Alfresco beschränken sich auf wenige Stunden Spielerei, auch Java und Tomcat sind für mich kein Heimspiel. Was ich aufgeschrieben habe hat zumindest auf den ersten Blick für mich funktioniert. Mit dem Ergebnis habe ich noch nicht viel Zeit verbracht. Es kann also durchaus sein dass ich Quatsch geschrieben habe. Falls jemandem Fehler oder Verbesserungen einfallen wäre ich sehr dankbar für einen kurzen Hinweis. Falls mir noch was auffällt werde ich einen entsprechenden Nachtrag schreiben.

  • Maschine anlegen. Ich gebe erstmal nur 1,5GB RAM, dazu 5GB Festplatte.
  • Debian installieren. Debian 7.0 ist mittlerweile so gut wie stabil, also gibt es direkt Wheezy. Dazu das übliche: Apt-Cache eintragen und alles erstmal aktualisieren.
  • Datenbank anlegen. Ich nutze MySQL, die Datenbank liegt auf einem anderen Server. ‚create database alfresco‚.
  • Benötigte Pakete installieren: apt-get install libreoffice openjdk-7-jre imagemagick tomcat7 mysql-client libmysql-java zip‚. Die Java-Version scheint wirklich wichtig zu sein, mit Version 6 hatte ich kein Glück beim vollständigen Anlegen der Datenbank.
  • Die SWFTools kennt Debian zwar als Paket, hier fehlt dann allerdings das essentiell wichtige pdf2swf. Wir ziehen uns die Sourcen (Version 0.9.1, 0.9.2 bringt einen Fehler bei der Installation) und compilieren klassisch mit ./configure && make && make install. Voraussetzung hierfür: apt-get install zlib1g-dev libjpeg62-dev libgif-dev libfreetype6-dev g++ make.
  • Alfresco herunterladen. Wir brauchen das Paket für die manuelle Installation, aktuell also alfresco-community-4.2.c.zip.
  • Den Inhalt des Paketes unter /opt/alfresco auspacken.
  • Sicherstellen dass Tomcat nicht läuft, damit der uns nicht in die Quere kommt: /etc/init.d/tomcat7 stop
  • Dateien und Verzeichnisse vorbereiten:

    # cp -r /opt/alfresco/web-server/shared/ /var/lib/tomcat7/
    # cp -r /opt/alfresco/web-server/webapps/ /var/lib/tomcat7/
    # cp -r /opt/alfresco/bin/ /var/lib/tomcat7/
    # ln -s ../../java/mysql-connector-java.jar /usr/share/tomcat7/lib/
    # mv /var/lib/tomcat7/shared/classes/alfresco-global.properties.sample /var/lib/tomcat7/shared/classes/alfresco-global.properties
    # mv /var/lib/tomcat7/shared/classes/alfresco/web-extension/share-config-custom.xml.sample /var/lib/tomcat7/shared/classes/alfresco/web-extension/share-config-custom.xml
    # mkdir /opt/alfresco/alf_data
    # chown -R tomcat7:tomcat7 /var/lib/tomcat7/ /opt/alfresco/alf_data/

  • Konfigurationsdatei /var/lib/tomcat7/shared/classes/alfresco-global.properties anpassen. Hier nur die geänderten Zeilen:

    dir.root=/opt/alfresco/alf_data
    db.username=alfresco
    db.password=GEHEIMESPASSWORT
    ooo.exe=/usr/bin/soffice
    ooo.enabled=true
    jodconverter.officeHome=/usr/lib/libreoffice/
    jodconverter.portNumbers=8101
    jodconverter.enabled=true
    img.root=/usr
    img.exe=/usr/bin/convert
    swf.exe=/usr/local/bin/pdf2swf
    db.driver=org.gjt.mm.mysql.Driver
    db.url=jdbc:mysql://DATENBANKSERVER/alfresco?useUnicode=yes&characterEncoding=UTF-8

  • Speichermanagement für Tomcat anpassen, in /etc/default/tomcat7 folgende Einstellungen hinzufügen:
    JAVA_OPTS="${JAVA_OPTS} -XX:MaxPermSize=512m -Xms128m -Xmx768m -Dalfresco.home=/opt/alfresco -Dcom.sun.management.jmxremote"
  • Tomcat starten: /etc/init.d/tomcat7 start

Danach kann man seinen Browser ganz vorsichtig auf http://SERVERNAME:8080/share oder http://SERVERNAME:8080/alfresco loslassen. Nicht vorschnell aufgeben, der erste Aufruf kann durchaus mehrere Minuten dauern. Die Zeit kann man sich zum Beispiel damit vertreiben, in der Datenbank nachzusehen ob tatsächlich die nötigen Tabellen angelegt werden. Direkt nach dem Laden der Startseite sind in der DB schon 102 Tabellen und mehrere Tausend Datensätze vorhanden.

Genau hier hat mich übrigens der Fehlerteufel eine Weile in Schach gehalten: in meinen ersten Anläufen hatte ich openjdk-6-jre installiert, so wie die meisten (zugegeben: teils alten) Howtos raten. Das führt neben einem Riesenhaufen Logs — die für einen nicht-Java-affinen Menschen erstmal nichtssagend sind — zu genau 20 Tabellen in der Datenbank, und dazu dass man unter /alfresco nur eine Fehlermeldung präsentiert bekommt. Darauf, das mal mit Java 7 zu testen muss man erstmal gestossen werden:-(

Wenn die Startseite (endlich!) sauber lädt kann man sich mit admin:admin anmelden und anfangen zu überlegen was man mit so einem schönen, neuen, großen Spielzeug anfangen kann… Aber das ist eine andere Geschichte, und die soll ein anderes Mal erzählt werden… ;-)

Geholfen haben mir bei der Installation hauptsächlich diese beiden Anleitungen, sowie dieser Thread im Support-Forum. Den Rest habe ich mir zusammengegoogled. Danke an alle die Ihr Wissen im Netz teilen!

Nachtrag (05.03.): Aufgrund eines Fehlers im Zusammenspiel zwischen Flash und dem Browser habe ich Flash-Upload abgeschaltet. Sonst hätte ich in der Weboberfläche keine Dateien hochladen können. Nutzen kann man Alfresco auch anders, aber wenn schon… Um abzuschalten in der Datei /var/lib/tomcat7/shared/classes/alfresco/web-extension/share-config-custom.xml den Wert adobe-flash-enabled auf false setzen und den Tomcat durchstarten.

Eigentlich ist es schade drum:

root:~# stat /var/log/installer.log.1 | grep Modify
Modify: 2002-12-03 21:03:20.000000000 +0100

Das Debian auf meinem Heimserver habe ich vor genau zehn Jahren, einem Monat, einem Tag und ein paar Stunden installiert. Vor einem halben Jahr habe ich das einem Arbeitskollegen erzählt, er hat es mir nicht geglaubt — vermutlich übersteigt das die wildesten Fantasien eines Windows-Admins… :-)
Wenn ich mich recht erinnere war das meine erste Debian-Installation überhaupt, vorher liefen da ein SuSE, ein Mandrake und ein Red-Hat Linux. Ich meine, mich auch noch dunkel an ein Halloween Linux erinnern zu können.
Damals müsste das eine Hardware in Pentium-Klasse gewesen sein, sicher nicht mehr als 166MHz. An den Speicher und die Festplatte kann ich mich nicht mehr erinnern.
Sicher ist es nicht weiter schwer, ein System zehn Jahre am Leben zu erhalten. Das Ding hat aber eine bewegte Geschichte hinter sich. Mal abgesehen davon dass es immer wieder auf neuere Hardware umgezogen ist hatte es im Laufe der Zeit schon folgende Funktionen:

  • Durchgehend hat es Basis-Dienste für mein Netz bereitgestellt: NFS, DNS (Bind), DHCP, Web (Apache)… sogar ein NIS lief da.
  • Kuriosester Einsatz war wohl der als Wecker: Weckzeit mit Barcode-Scanner programmiert, dann Wecken mit abwechseln MP3 und Zeitansage (Sprachsynthese mit Mbrola). :-D
  • Es war mal ein Fax-Server (Hylafax) und ein Drucker-Server (erst ohne, später mit Cups).
  • Es war mal ein Anrufbeantworter (Vbox3).
  • Es war mal ein Videorecorder (VDR). Seit der Server in den Keller gewandert ist habe ich im Wohnzimmer einen Festplattenlosen Rechner der per PXE vom Server booted.
  • Ursprünglich war nur eine Platte drin. Dann mal mehrere separate, dann RAID5, seit ein paar Jahren RAID1.
  • Da liefen mal Teile eines Konfigurationsvorschlags von der c’t, mit Virtualisierung einer Endian Firewall per UML (User Mode Linux).
  • Der nächste Virtualisierungsansatz hiess Xen, auch wieder mit einer Endian Firewall. Zusätzlich aber mit einer vierfach-Netzwerkkarte.
  • Irgendwann fand ich Endian doof, um das FreeBSD-basierte pfSense nutzen zu können habe ich Xen durch KVM ersetzt.
  • Und um die Sache spannender zu machen habe ich neben KVM auch Linux-Vserver eingesetzt.

Wohlgemerkt: alles ohne das Betriebssystem neu zu installieren! Das System habe ich Heute abgeschaltet, und so wie es aussieht endgültig. :-(

Nicht erschrecken: ich bin mit Debian als Serversystem mehr als zufrieden. Und nein, ich werde mein Heimnetz nicht abschalten. :-)

Aber die Grundlage wird eine andere. Ich hatte ja schon erwähnt dass mir Proxmox VE gut gefällt. Nicht zuletzt weil es auf Debian basiert. Hier und da gibt es Verbesserungspotential, aber im Moment scheint mir das für mich die beste Lösung zu sein.
Ich habe in den letzten zwei Wochen viel Zeit in den Umbau gesteckt. Proxmox auf der Umweltsau installiert, erst die KVM-Virtualisierten Systeme — zwei FreeBSD und ein Ubuntu — rübergeholt, dann die Vserver. Letztere mussten ja auch noch an OpenVZ angepasst werden.
Heute kam der finale Schritt: ich habe meinen Hauptserver virtualisiert. Also oben genanntes Debian-System. Das siecht jetzt erstmal als KVM vor sich hin. Noch macht es DNS, DHCP und Web, Backups der anderen Systeme, und ein paar andere Kleinigkeiten. Nach und nach werde ich es seiner Dienste berauben und dann wirklich entsorgen.
Aber vorher warte ich ein paar Tage ab ob die ganze Geschichte so auf dem neuen Server funktioniert. Wenn nicht kann ich die alte Kiste mit wenig Aufwand wieder anschalten. Wenn doch wird da auch ein Proxmox installiert, und ich migriere die ganzen virtuellen Maschinen zurück. Auf Dauer will ich die Umweltsau doch nicht 24/7 laufen lassen…

Das Zabbix-Item

Das Zabbix-Item

Lange Zeit habe ich die Überwachung meines Netzwerkes Nagios anvertraut. Vor einiger Zeit habe ich das durch ein Icinga ersetzt, einfach nur um mal zu sehen inwiefern der Fork besser oder anders ist. Seit einigen Wochen beschäftige ich mich aber aus verschiedenen Gründen mit Zabbix, und das ist auf dem besten Wege sowohl Nagios als auch Icinga zu verbannen. Zabbix kann einfach viel mehr als Nagios/Icinga, und wenn man sich an die Konzepte gewöhnt hat ist es absolut nicht schwieriger zu beherrschen.

Eine der letzten Überwachungen die Nagios und Icinga bei mir gemacht haben, Zabbix aber noch nicht, war der Test auf aktualisierte Softwarepakete. Da die meisten Systeme unter meiner Fuchtel unter Debian laufen ist das nicht allzu schwer. Bislang habe ich regelmäßig durch den Nagios Remote Plugin Executor (NRPE) ein apt-get update && apt-get upgrade ausgeführt und rausgeparst wie viele Pakete aktualisiert würden. Das hat mehrere Nachteile: zum einen sind die Prozesse — gerade bei meiner schmalen Internetanbindung — teilweise recht lange unterwegs, und das führt zu Timeouts. Zum anderen bekommt das Monitoring erst beim nächsten Test mit dass ein System aktualisiert wurde, und da ich meine Kisten nicht unnötig stressen will teste ich nur zweimal täglich. Das bedeutet, dass ein Alarm unter Umständen knapp zwölf Stunden weiter besteht, obwohl die Situation schon bereinigt wurde.

Das geht besser.

Ich vermute dass das auch mit Nagios/Icinga besser ginge, aber ich gestehe dass ich damals nicht die Zeit investiert habe. Für Zabbix habe ich jetzt eine Lösung die mir gut gefällt:

Im nebenstehenden Bild sieht man den Parameter (Zabbix-Sprech: ‚das Item‘) das ich dazu angelegt habe. Das ist in meiner Konfiguration das erste Item vom Typ Zabbix-Trapper, daher stelle ich das hier mal vor. Zabbix-Trapper bedeutet, dass der Parameter nicht aktiv gepollt wird. Zabbix wartet passiv darauf, dass jemand mittels zabbix_sender einen Wert in das System schießt. Das funktioniert natürlich sowohl direkt bei Übergabe an den Zabbix-Server, als auch bei Übergabe an einen Zabbix-Proxy (ja, auch so einen habe ich zu Hause… ;-) ).

Nur wer sagt jetzt beim Zabbix Bescheid ob Pakete zu aktualisieren sind? Keine schlechte Idee ist, regelmäßig ein apt-get update auszuführen, um den Katalog aufzufrischen. Das erledigt Cron gerne, dem könnte man dann auch direkt sagen dass er den aktuellen Wert an Zabbix schicken soll. Das würde aber bedeuten, dass das Problem mit der Verzögerung nach einer Auffrischung des Systems immer noch bestünde. Also habe ich mir Apt mal etwas näher angesehen.

Im Verzeichnis /etc/apt/apt.conf.d/ kann man Hooks ablegen die vor oder nach bestimmten Aktionen des Paketmanagements ausgeführt werden. Bei mir gibt es da jetzt eine Datei namens 99zabbix, die hat einen Inhalt in dieser Form:

APT::Update::Post-Invoke-Success { "zabbix_sender -z zabbix.intern -s $(hostname -s).intern -k debian.updates -o $(apt-get -s upgrade | sed -ne 's/^\([0-9][0-9]*\) .*/\1/p') > /dev/null" };
DPkg::Post-Invoke { "zabbix_sender -z zabbix.intern -s $(hostname -s).intern -k debian.updates -o $(apt-get -s upgrade | sed -ne 's/^\([0-9][0-9]*\) .*/\1/p') > /dev/null" };

Das Kommando ist in beiden Fällen das gleiche. Mit APT::Update::Post-Invoke-Success wird festgelegt was nach einem erfolgreichen apt-get update passieren soll. So bekommt Zabbix nach jedem Update mit ob es etwas neues gibt, unabhängig davon ob Cron das angestossen hat oder ob ich das manuell war. Der Eintrag DPkg::Post-Invoke sagt nach jeder Änderung an den installierten Paketen noch einmal Bescheid wie der Stand der Dinge ist. So wird also nach einem apt-get upgrade der Wert direkt wieder auf 0 zurückgesetzt.

Dazu habe ich folgenden Trigger gebaut:

{Template OS Linux:debian.updates.last(0)}>0

Der meldet bislang nur, wenn der letzte Wert in dem Item debian.updates größer ist als 0. Da muss ich aber noch einmal Hand anlegen, so dass der auch aktiv wird wenn seit einer gewissen Zeit kein aktueller Wert gesetzt wurde. Dann ist davon auszugehen dass der Cron-Job kaputt ist der das apt-get update ausführt, oder dass an der Paketverwaltung grundsätzlich etwas schief läuft. Aber wie das geht muss ich mir noch genauer ansehen…

Ich habe seit ein paar Wochen ein mistiges Problem mit meinem Server zu Hause. Ich bin mir nicht bewusst eine Änderung gemacht zu haben die als Ursache her halten könnte, aber das ist ja immer so… ;-)

Vielleicht kann mir ja jemand aus der Leserschaft helfen:

Nach einer gewissen Laufzeit — beobachtet habe ich Zeiten zwischen einer und drei Wochen — fängt die Systemuhr an zu rasen. Alles ist wie immer, nur dass die Zeit etwa vier mal so schnell gezählt wird wie auf allen anderen Uhren. Der Server liefert die Zeit in mein Netz, also fängt früher oder später auch der Videorecorder und alles andere an zu spinnen. :-(

Auf dem Server (Debian Etch, 2.6.18-6-xen-vserver-686) läuft ein ntpd, an dessen Konfiguration ich aber ewig nichts mehr gemacht habe. Alle Versuche dem Spuk ein Ende zu bereiten sind bislang fehlgeschlagen. Nur ein Reboot hilft. Für ein bis drei Wochen zumindest…

Ich bin ratlos. Hat wer einen Tip?

Eigentlich bin ich der Ansicht, dass einem auf einem Server nicht viel besseres passieren kann als ein Debian. Heute wurde dieser Eindruck böse getrübt, allerdings glaube ich weiterhin dass andere Systeme nicht besser sind. Höchstens ‚anders Scheiße‘. :-)

Was passiert ist? Ich habe endlich mal den angestaubten Apache einspunktirgendwas durch einen hypermodernen Apache 2 ersetzt. Das hat im Wesentlichen gut funktioniert, mit einem kleinen Dämpfer: ich benutze SysCP um den Server zu verwalten. Das Ding hat eine MySQL-Datenbank, und darin stehen unter anderem meine Mitbenutzer. Also Namen und (verschlüsselte) Passwörter der Leute die auf dem Server was zu sagen haben. Ich habe an einer Stelle verschiedene administrative Tools installiert, auf die eben diese Benutzer zugreifen können sollen. Sowas wie phpMyAdmin, aber auch die Oberfläche von SysCP selbst. Diese Seite war bis dato über libapache-mod-auth-mysql geschützt. Naheliegend, da die Namen und die Passwörter eh in einer Tabelle liegen. Dummerweise gibt es kein libapache2-mod-auth-mysql für Etch, und damit fingen die Probleme an…

Klar, ich hätte mir da eben selbst was stricken können. Wollte ich aber nicht, unter anderem weil absehbar ist dass das keine Dauerlösung werden würde. Und genau das ist es, was mich aufregt: Das Modul gab es für Sarge, das gibt es für Sid und das wird es für Lenny auch wieder geben. Nur eben für Etch nicht. Grund ist, dass der Maintainer die Klamotten hin geschmissen hat und zur Zeit der Veröffentlichung von Etch niemand den Job haben wollte. :-(

Naja, viele Versuche und einiges an Nerven später habe ich es dann doch geschafft, wieder gegen die SysCP-Datenbank zu autorisieren. Geholfen hat eine Kurzanleitung die ich hier zu meiner persönlichen Referenz noch mal wieder gebe. Ist zwar eigentlich für Ubuntu, hat aber auch auf Etch geklappt:

To get mysql authentication working in Gutsy, you have to manually compile mod_auth_mysql:

1. wget http://heanet.dl.sourceforge.net/sourceforge/modauthmysql/mod_auth_mysql-3.0.0.tar.gz
2. wget http://www.bleb.org/software/mod_auth_mysql-3.0.0-apache-2.2.3.patch
3. tar zxf mod_auth_mysql-3.0.0.tar.gz
4. apt-get install apache2-prefork-dev libmysqlclient15-dev; apt-get --purge remove libapache2-mod-auth-mysql
5. cd mod_auth_mysql-3.0.0
6. patch < ../mod_auth_mysql-3.0.0-apache-2.2.3.patch
7. sed -i 's|#include <mysql.h>|#include <mysql /mysql.h>|' mod_auth_mysql.c
8. apxs2 -c -lmysqlclient -lm -lz mod_auth_mysql.c
9. apxs2 -i mod_auth_mysql.la
10. echo 'LoadModule mysql_auth_module /usr/lib/apache2/modules/mod_auth_mysql.so' > /etc/apache2/mods-available/auth_mysql.load
11. a2enmod auth_mysql

Configure it as follows (adapt to your environment):

<location /mysqlauth>
  AuthName "test"
  AuthType Basic
  AuthUserFile /dev/null
  AuthBasicAuthoritative Off

  AuthMySQLEnable On
  AuthMySQLAuthoritative On
  AuthMySQLDB apache_auth_test
  AuthMySQLUser authtestuser
  AuthMySQLPassword something
  AuthMySQLUserTable auth
  AuthMySQLNameField username
  AuthMySQLPasswordField passwd
  require valid-user
</location>

Hope this helps someone.

Also mir hat es definitiv geholfen, Dank an mrts. Ich musste nur noch mittels AuthMySQLPwEncryption md5 angeben wie die Passwörter verschlüsselt sind.