OwnCloud zickt

OwnCloud zickt seit Version 5.x vermehrt rum:

Erstens mag es keine Connections mit mehreren Clients gleichzeitig. Das führt regelmäßig dazu, dass *conflict* Dateien angelegt werden, obwohl sich an der Dateiversion überhaupt nichts verändert hat. Dies ist leider auch der Fall, wenn alle beteiligten Endgeräte sowie der Server gegenüber dem gleichen Server per NTP ihre Uhrzeit holen. Der Bug sitzt demnach tiefer im System.

Zweites: Der OwnCloud-Sync-Client frisst so lange an den Ressourcen, bis es sich selbst als dysfunct nach Zombieland abmeldet. Schießt man den Prozess noch rechtzeitig ab, sinken umgehend CPU- und RAM-Last wieder beinahe auf Normalmaß.

Der Screenshot von meinem Arbeitsplatzrechner oben zeigt jedoch ein leider typisches Phänomen. Wirkliches Normalmaß wäre das hier:

Zu swappen hat mein Quadcore mit 8GB RAM nämlich eigentlich nichts.

Da selbst nach Beendigung eines amoklaufenden OwnCloud-Prozesses noch „etwas hängen“ bleibt, vermute ich auch hier dickere Probleme. Die OwnCloud-Foren sind zumindest voll von Menschen, die ähnliche Erfahrungen machen.

Ethercalc

Auf BeeHive [1, 2] habe ich schon hierzu geschrieben: Meine Schule hat nun neben einem Etherpad-Lite-Server auch einen Ethercalc-Server zur gemeinsamen Arbeit an Tabellen im Netz.

Die Installation verlief tatsächlich so einfach wie auf den Seiten der Programmierer angegeben.

Was mich zuerst zögern ließ, war die Frage, wo ich den auf unserem Testserver hinlegen sollte und wie sich das Programm im Dauerbetrieb dann verhält. Ich entschied mich nun für die Installation von Ethercalc in den Benutzeraccount des schon vorhandenen Etherpad-Lite-Servers. Also nochmal zum Nachturnen hier mein Vorgehen.

Zuerst in den Benutzeraccount von etherpad wechseln:

sudo su – etherpad -s /bin/bash

Dann in

/opt/etherpad/local

ein Unterverzeichnis einrichten

mkdir ethercalc

cd ethercalc

Das Programm installieren

npm install ethercalc

und nachsehen, ob es läuft:

./node_modules/ethercalc/bin/ethercalc

Im Browser unter der eigenen Domain auf Port 8000 sollte dann der Ethercalc-Server wie hier auftauchen: https://ethercalc.org/

Mit STRG C schießt man diesen Prozess wieder ab und meldet sich mit

exit

aus dem Benutzeraccount von Etherpad ab.

Dann – wieder als root auf dem System unterwegs – legt man sich ein Startskript für Ethercalc an. Das kann so einfach wie das hier sein:

cd /etc/initd

vi ethercalc.conf

und in diese Datei sowas wie das hier pasten:

description „ethercalc“

start on started networking

stop on runlevel [!2345]

env ECHOME=/opt/etherpad/local/ethercalc

env ECLOGS=/var/log/ethercalc

env ECUSER=etherpad

# Programpath /opt/etherpad/local/ethercalc/node_modules/ethercalc/bin/ethercalc

pre-start script

chown -R $ECUSER $ECLOGS ||true

chmod -R 755 $ECLOGS ||true

end script

script

cd $ECHOME/

exec su -s /bin/sh -c ‚exec „$0“ „$@“‚ $ECUSER — node_modules/ethercalc/bin/ethercalc \

>> $ECLOGS/access.log \

2>> $ECLOGS/error.log

end script

Die Verzeichnisse für die Logs anlegen und dem Benutzer etherpad übergeben:

mkdir /var/log/ethercalc

chmod -R 755 /var/log/ethercalc

chown -R etherpad /var/log/ethercalc

Die Logs müssen auch weg-rotated werden. Also

vi /etc/logrotate.conf

und hier am Ende hinzufügen:

# Ethercalc – weekly rotation and compression

/var/log/ethercalc/*.log {

weekly

missingok

rotate 8

compress

notifempty

}

Ein

service ethercalc start

sollte den Dienst nun hochbringen.

Mal sehen, wie sich das Ding verhalten wird. Die Konfiguration hier ist noch arg mit der Axt in den Server geklopft, aber es läuft erst einmal … Redis kommt dann als nächstes mit auf die Maschine, damit Ethercalc einen echten Datenbankserver zum Speichern der Tabellen hat.

antiX

Mein Asus L8400 K mit Pentium III 850 Mhz CPU sowie 256 MB RAM fristete ein Schattendasein unter dem demnächst ablaufenden Ubuntu 8.04 LTS. Bedienbar war die Kiste mit diesem Betriebssystem nicht wirklich, aber sie diente das eine oder andere mal als Printserver in der Schule während den Projekttagen für die Anbindung von Geräten, die nur eine LPT mitbrachten.

Mit dem EOL von Ubuntu 8.04 wollte ich zuerst eine aktuelle Lubuntu Version auprobieren … was auf Grund der nicht mehr zu Pentium 3 CPUs passenden Kernel jedoch nicht gelang. Also musste etwas noch Schlankeres her: Optisch relativ ansprechend, gut anpassbar Dank icewm und vor allem nun auch wieder (mit Abtrichen – ist ja klar) zu bedienen wurde das Gerät mit antiX. Selbst Firefox und LibreOffice kann man nutzen, wenn man etwas Geduld hat. Der Desktop selbst ist ohne Wartezeit zu bedienen … ein echter Fortschritt gegenüber Ubuntu 8.04.

Abiword, Chromium und viel weitere Software lässt sich aus den Debian Repos nachinstallieren und Dank rolling-release Konzept muss ich mich nicht gleich wieder nach einer anderen Distri umsehen, nur um das Gerät aktuell zu halten. Was zu meinem Erstaunen sofort funktionierte, war die Einbindung meines WLAN USB Sticks TP-Link TL-WN727N – und nicht nur über WEP, sondern sogar mit WPA als Verschlüsselung.

lsb_release

Für das Netbook meiner Schwiegereltern unter Xubuntu 12.04 LTS habe ich TeamViewer 8 installiert und das führt nun dazu, dass X/K/Ubuntu permanent beim Login einen lsb_release Fehler auswirft. Hier ist die Bugbeschreibung zum Problem und im gleichen Thread weiter unten die passende Lösung dazu.

Ab Zeile 20 in /opt/teamviewer8/tv_bin/script/tvw_main befindet sich die Funktion function LogStartupInfo(). Hier werden zwei Zeilen auskommentiert und eine neue hinzugefügt

if [ -x „$(type -p lsb_release)“ ] ; then # log information about the Linux distribution
#lsb_release -a # TempFix(Bug#1094218)
make_path „$WINEPREFIX/drive_c“
cat /etc/lsb-release | grep DESCRIPTION | cut -f2 -d= | sed ’s/\“//g‘ > „$WINEPREFIX/drive_c/distrelease“ # TempFix(Bug#1094218)
#lsb_release -ds > „$WINEPREFIX/drive_c/distrelease“
else

und man ist den Bug los.

Bergrutsch Mössingen

Schönes, sonniges Wetter, nasser Boden – kein Tag, um in den Kalk zu gehen, aber immerhin in dessen Nähe. Also kurz zum Bergrutsch nach Mössingen, der einen wenigstens rieselnden Kalkstein hören lässt.

1459

… Tage lebt im Durchschnitt ein von Google bereit gestellter Dienst – von der Suche selbst einmal abgesehen. Errechnet und mit vielen weiteren Beispielen untermauert hat dies der Guardian. Losgetreten wurde dieser Artikel sicherlich durch die Ankündigung des Suchmaschinenbetreibers, seinen Reader einzustellen.

Da würde ich doch glatt losrennen und mir ein Chromebook kaufen.

Routerbau

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:

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.

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.

LibreOffice 4.0.1 Pfade

Ich dachte schon, ich werde narrisch: Was auch immer ich in Libreoffice 4.0.1 als Pfad zu meinem Arbeitsverzeichnis und zu meinen Dokumentenvorlagen eintragen wollte, das Programm übernahm (unter LinuxMint 14 KDE 64Bit) meine Einstellungen nicht.

Erst als ich unter /Extras /Optionen /LibreOffice /Allgemein den Schalter bei „LibreOffice-Dialoge verwenden“ sitzen hatte (siehe Bild oben), klappte es. LO mag wohl Dolphin nicht.

Das Arbeitsverzeichnis kann nun geändert werden und die Einstellungen bleiben auch.

/localhost

127.0.0.1