Archiv der Kategorie: Linux

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

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.

Routerbau

netzwerk

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:

iptables DROP

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.

iptables REJECT

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.

Optionen - LibreOffice - Allgemein_001

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.

Optionen - LibreOffice - Pfade_002

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

Etherpad Lite, npm und node.js

Um es kurz zu machen: Wer (wie ich) auf die Idee kam, node.js aus dem PPA von Chris Lea für seinen EPL Server zu nutzen … hat nun keinen mehr.

Das liegt schlicht daran, dass node.js inzwischen von diesem Maintainer in Version 0.10 zur Verfügung gestellt wird und dieses mit npm aus den Ubuntu Quellen nicht zusammenarbeiten will. Leider hilft es auch nicht, wenn man npm ebenfalls passend macht – z.B. indem man Chris Leas PPA durch das PPA von ric_harvey ersetzt: Dann passen zwar node.js und npm wieder zusammen – aber mit Version 0.10 kommt EPL nicht mehr richtig hoch.

Wer richtig Lust auf’s Basteln hat, der kann sich im Moment diesen Thread bei Github entlang hangeln und landet evtl. einen Treffer.

Oder man greift auf die Ubuntu-Wiki Anleitung zur Installation von EPL zurück und wirft den Compiler an. Dann hat man einen ziemlich alten npm und node.js Server – aber ein funktionierendes EPL.

Oder man wartet ab, bis bei Github eine EPL Version liegt, die mit npm und node.js 0.10 zusammen arbeiten will.

Shutter

PPAforShutterTeam:“ShutterTeam”team-MozillaFirefox_001

Der „zerfetztes Papier“ Effekt von Shutter wird mit Hilfe von imagemagick erstellt. In

/usr/share/shutter/resources/system/plugins/shell/sptornedpaper

liegt ein entsprechendes Skript, das im Grunde die folgenden Befehle ausführt:

convert „${FILE}“ \( +clone -threshold -1 -virtual-pixel black \
-spread 10 -blur 0x3 -threshold 50% -spread 1 -blur 0x.7 \) \
+matte -compose Copy_Opacity -composite „${FILE}“

convert „${FILE}“ \( +clone -background black  -shadow 80×3+5+5 \) \+swap -background none -mosaic +repage „${FILE}“

Sollte also die Ausführung von Shutter-Plugins nicht recht gelingen wollen und die Fehlermeldung

FILE /home/usernamen/dateiname.png DOES NOT EXIST OR IS NOT AN ORDINARY FILE, NOT READABLE OR HAS ZERO SIZE

auftauchen, dann muss man sicherstellen, dass imagemagick auch wirklich an Bord ist. Ich war mir sicher … und lag falsch. Ein

sudo apt-get install imagemagick

zieht, was nötig ist. Wenn das nicht hilft, dann lohnt sich der Versuch, das Problem durch Upgrade von Shutter über das entsprechende PPA anzugehen.

KDE Notification

In meiner Taskleiste befand sich seit dem letzten Update für den flashplugin-installer jedes mal nach dem Einloggen ein Hinweis, dass das Update misslungen sei … dabei hatte ich das längst repariert. KDE hatte sich demnach verschluckt.

In /var/lib/update-notifier/user.d/ befand sich eine Datei data-downloads-failed-permanently, deren Löschung dann auch die Meldung beseitigte.

Ob ich damit nun was zerlegt habe … ich weiß es nicht. Wer nach dem Pfad oben googled, findet mehr Hinweise zum Mechanismus in den Kubuntu-Foren, die ich mir allerdings noch nicht komplett durchgesehen habe. Meine Lösung „brennt“ also – scheint jedoch bisher Nebenwirkungsfrei zu funktionieren.

CSync konnte keine lock-Datei erstellen

ownCloud 1.2.0_001

Die meiste Zeit bin ich mit der Kombination OwnCloud 4.5.x Server und 1.2.x Client zufrieden: Es läuft. Die Synchronisation mit Android wie auch mit allen Endgeräten klappt.

ownCloud 1.2.0_002

Immer mal wieder zickt das Client-Programm aber rum und teilt mit:

CSync konnte keine lock-Datei erstellen.

Was bisher geholfen hat, war ein Klick auf /Anhalten. Dann die vorhandene lock Datei schlicht löschen

rm /home/username/.local/share/data/ownCloud/lock

und den Client durch Klick auf /Fortsetzen wieder starten.