Nette Software – neben Celestia einige der wenigen Pakete zum Thema, die sich direkt in den Repos von Ubuntu befinden. Im Ordner ./stellarium in /home befindet sich die config.ini und hier sind die Daten für Nehren einzutragen:
name = Nehren
latitude = +48d25’52.32″
longitude = +09d04’10.26″
altitude = 427
Es war mal wieder der erste Sonntag im Monat und mein Software Raid hat sich wie üblich mit sich selbst beschäftigt. Das ging mir nun aber so auf den Wecker, dass ich die Ursachenforschung noch einmal anging – und dann leider feststellen musste, dass meine Platten nicht im DMA Modus liefen, da konnte ich hdparm-en so viel ich wollte.
Also hab ich mir über ebay eine 3ware 7006-2 besorgt, heute eingebaut und siehe da – die Plattengeschwindigkeit hat sich verzehnfacht.
Hier gab es dann noch ein Debian-Paket für die einfachere Verwaltung und dort die Anleitung für die Einbindung in Nagios. Die passt noch nicht so 100%ig – aber dafür kann ich mit ./tw_cli arbeiten.
tw_cli info c0 allunitstatus
ist die schnellste Lösung. Nach einem
tw_cli
sind in einem interaktiven Modus weitere Befehle möglich – z.B.
/c0 show unitstatus
/c0 show drivestatus
Eine Übersicht liefert diese man page: http://www.cyberciti.biz/files/tw_cli.8.html
Unter OpenSuSE 11.1 und auch unter Intrepid war es nur möglich auf dem Server-share Dateien und Verzeichnisse zu schreiben, zu lesen und zu löschen. An den Inhalt von Dateien durfte ich nicht ran. Speicherversuche quittierte gedit z.B. mit der Meldung
Unerwarteter Fehler not a directory
Dieses Problem hatten auch andere. Leider hab ich das erst gemerkt, als die SuSE vom Vostro schon wieder verschwunden und ein Intrepid installiert war. Dabei ist die SuSE garnicht die Schuldige – die Ursache für Probleme beim Verändern von Dateiinhalten auf Server-shares scheint eher an CIFS selbst zu liegen.
Bei mir (Debian Etch Server mit unixextensions = yes) hat es ausgereicht in der fstab auf den Intrepid Clients
//10.32.1.1/verwalter /home/dirk/Serververz cifs
rw,user,nounix,auto,uid=dirk,gid=dirk,credentials=/home/dirk/.credentials/server.cred,iocharset=utf8 0 0
zu schreiben.
Vom Intrepid Client aus gesehen erhalten die Dateien nun
-rwxrwSrwx 1 dirk dirk 307 2009-01-20 10:04 test.txt
Die gleiche Datei vom Hardy Client aus gesehen:
-rw-r–r– 1 dirk dirk 389 2009-01-20 10:05 test.txt
Auf dem Server sieht es aber richtig so aus:
-rw-r–r– 1 verwalter teachers 389 2009-01-20 10:05 test.txt
Die Übersetzung klappt also. Änderungen an der smb.conf waren nicht nötig.
Nebenwirkungen habe ich noch nicht getestet – aber jetzt kann ich wenigstens wieder von allen Clients aus den Inhalt von Dateien verändern.
Ob das nun alles auch mit rsync noch hinhaut werde ich sehen: Bisher rsyncte ich vor einem Dienstgang meine Verzeichnisse des Servers mit denen des Clients und wenn ich zurückkam ging es in die andere Richtung. Im dümmsten Fall tut rsync garnix mehr – im anderen dümmsten Fall schiebt rsync alles rüber und nicht nur die Veränderungen.
Andreas hat mich (mehr oder weniger) dazu überredet mal auch die neue OpenSuSE auszuprobieren und da ich gerade eben einen Dienstlaptop erhalten habe tat ich das auch gleich.
Die Installation auf dem Dell Vostro 1510 lief ohne Probleme durch, die zuerst falsch erkannte Bildschirmauflösung konnte über YaST angepasst werden und auch die Installation des nvidia Treibers klappte auf Anhieb.
Nur die WLan Karte wurde nicht erkannt bzw. es wurde kein Treiber eingebunden – ein Problem, das unter Ubuntu 8.10 wohl nicht auftritt, wie ein erster Test mit der LiveCD zeigte.
lspci
findet aber die richtigen Angaben für die Karte und für eine Suche im Netz nach Hilfe:
Network controller: Broadcom Corporation BCM4312 802.11b/g (rev 01)
Auf den Seiten von Broadcom gibt es für das Ding einen Treiber: http://www.broadcom.com/support/802.11/linux_sta.php
Der Rest ergibt sich aus diesem Blogbeitrag (vielen Dank) und der Beschreibung in den Treiberdateien selbst:
tar xfz hybrid-portsrc-x86-32_5_10_27_12.tar.gz
su –
zypper ref ; zypper in kernel-source linux-kernel-headers
make -C /lib/modules/(uname -r)/build M=`pwd` clean
make -C /lib/modules/(uname -r)/build M=`pwd`
mkdir /lib/modules/$(uname -r)/extra
cp wl.ko /lib/modules/$(uname -r)/extra
depmod -a
modprobe -v ieee80211_crypt_tkip wl
Jetzt noch neu booten – und schon begrüßt einen das Leuchtdiödchen für WLan und auch der gnome Netzwerkmanager findet Kontakt.
Ob das auch mit verschlüsselten WLan APs läuft – keine Ahnung. Das konnte ich noch nicht testen. Was auf jeden Fall auf mich zukommt ist, dass ich nach den sicherlich unter SuSE ebenfalls üblichen monatlichen Kernelupdates wieder neu kompilieren muss.
Seit Sonntag beschäftigt sich mein Homeserver mit sich selbst und reagiert nur noch mit großer Verzögerung auf Anfragen der Clients. Außerdem binden die Clients die Serververzeichnisse nicht mehr richtig ein – soll heißen: Nur noch jeweils ein Client hat Zugriff, die anderen gehen leer aus.
Auf der Suche nach den Ursachen warf ich einen Blick auf das Raid:
# cat /proc/mdstat
Personalities : [raid1]
md2 : active raid1 hda3[0] hdb3[1]
192434496 blocks [2/2] [UU]
[=================>…] check = 88.0% (169503744/192434496) finish=422.0min speed=904K/secmd1 : active raid1 hda2[0] hdb2[1]
2931776 blocks [2/2] [UU]md0 : active raid1 hda1[0] hdb1[1]
48829440 blocks [2/2] [UU]
Ein mdadm -D /dev/md2 beruhigt ebenfalls mit der Meldung „State : clean, recovering“ (und ich muss gerade entdecken, dass WordPress aus –detail einen Einzelstrich macht).
Die Ursache ist nun also klar: Am Sonntag war wohl /md0, am Montag /md1 und Teile von /md2 dran – und ich bin inzwischen froh, dass ich nur 250GB Platten im Raid hab. Zuerst dachte ich an einen Fehler – doch dann entdeckte ich, dass dieser Job regelmäßig abläuft.
In /etc/cron.d/mdadm steht wann:
#
# cron.d/mdadm — schedules periodic redundancy checks of MD devices
#
# Copyright © martin f. krafft <madduck@madduck.net>
# distributed under the terms of the Artistic Licence 2.0
#
# $Id: mdadm.cron.d 147 2006-08-30 09:26:11Z madduck $
## By default, run at 01:06 on every Sunday, but do nothing unless the day of
# the month is less than or equal to 7. Thus, only run on the first Sunday of
# each month. crontab(5) sucks, unfortunately, in this regard; therefore this
# hack (see #380425).
6 1 * * 0 root [ -x /usr/share/mdadm/checkarray ] && [ $(date +\%d) -le 7 ] && /usr/share/mdadm/checkarray –cron –all –quiet
Seit einem Jahr hab ich das Raid nun schon am Laufen und hab nichts von dieser Funktion gemerkt. Wenn /usr/share/mdadm/checkarray tatsächlich jeden ersten Sonntag im Monat aufgerufen werden muss, dann darf ich a) mein Raid auflösen b) dies auf jeden Sonntag beschränken, der vor dem 3ten eines Monats liegt oder c) den Prozess im Bedarfsfall anhalten mit
/usr/share/mdadm/checkarray -x
Eine –help Option gibt es für checkarray auch. Eine Dokumentation lieg in /usr/share/doc/mdadm/README.checkarray, eine man Page hat weder mein Debian noch mein Ubuntu zu bieten.
Jetzt bin ich zwar was die Geschwindigkeit meines Servers angeht beruhigter, kann aber nicht arbeiten, weil alle Daten ja auf dem Server (und dort in md2) liegen und dieser Prozess so viel Systemressourcen frisst, dass schon der Aufruf von Google scheinbar ewig dauert. Hier rächt sich nun der integrierte IPCop.
Die Schnapsidee, an den Moodleseiten auf dem LFB zu arbeiten quittierte mein DreamWeaver heute Morgen mit einer Wartezeit von 90 Minuten für das Einlesen des Verzeichnisbaums und eine Sicherungskopie von /elearning/moodle vor der notwendigen Restrukturierung läuft nun schon seit 4 Stunden, obwohl das Archiv auf dem Client liegt. Mein Server will wohl, dass ich Urlaub mache.
Die einzige Art, wie ein Software Raid unter der Herrschaft von mdadm auf einem Linux überprüft werden kann, scheint demnach zu sein, die Partitionen zu rsyncen.
Hm?!
Der in einer OpenSource Version vorliegende MindMapper XMind hat es mir angetan. Zwar bringt das Programm in der freien Version einige Dinge nicht mit, die FreeMind hat (z.B. PDF Export), aber die Vielzahl der Optionen für die Darstellung der Map und die schicke Programmoberfläche hält mich gerade gefangen.
Nervig wird das Programm jedoch, wenn man Maps auf share.xmind.net hochladen will: Ein Updatedialog versucht einem dauernd die Pro Version unterzuschieben.
Wirklich überzeugend finde ich die Portable Version: ZIP herunterladen und auf dem USB Stick auspacken – und schon steht in vier Unterverzeichnissen XMind für Linux 32, Linux 64, Windows und Mac OS X zur Verfügung. Ebenfalls nicht schlecht ist die einfache Möglichkeit in XMind eigene Bilder als Icons zu nutzen und diese thematisch zu gruppieren.
Endlich ein Linuxtool, das Screenshots fast so einfach macht, wie es einst nur Hardcopy unter Windows konnte. Es fehlen zwar noch einige Funktionen des IMHO ungeschlagenen Vorbilds, aber nichts, was ich mir bisher unter Linux ansah, kam so nah ran wie gscrot.
gscrot kann – neben den üblichen Funktionen wie Aufnahme des gesamten Bildschirms, Aufnahme eines Fensters mit oder ohne Rahmen usw – auch eine Auswahl des Bildschirms aufnehmen und zeigt dabei die Größe der Auswahl an.
Weiter bringt es eine Reihe von Funktionen mit, die Effekte direkt auf den Screenshot anwendet – z.B. auch den Effekt „torn paper“. Verschiedene Effekte lassen sich kombinieren – es fehlt aber leider noch eine Rückgängig-Funktion.
Ein eingebauter Editor erlaubt es, verschiedene Icons sowie Auswahlrahmen und Texte in das aufgenommene Bild einzufügen, so dass Anleitungen leichter erstellt werden können. Aber auch hier gibt es ein „aber“: gscrot speichert die Dateien im eingestellten Format (png oder jpg), so dass jede Veränderungen destruktiv wirkt. Gimp’s XCF inklusive Ablage der Veränderungen auf Ebenen wäre hier eine gute Alternative gewesen. Trotzdem: Im Vergleich zur in Gimp eingebauten Screenshotfunktion oder gar dem simplen Pressen der [Print Screen] Taste ein echter Fortschritt.
Lediglich die Installation über heruntergeladene DEB Pakete wollte wegen nicht erfüllter Abhängigkeiten bei mir nicht so einfach gelingen. Ich habe mich deswegen dazu durchgerungen, die Paketquellen von gscrot in die sources.list einzutragen, damit alles rund läuft.
OCR ist unter Linux ein Problemkind. Es gibt zwar gocr, ocrad und hoffentlich bald auch ein einfach zu installierendes tesseract, das deswegen hier nicht mehr weiter behandelt wird, aber weder gocr noch ocrad liefern bei mir Erkennungsraten von mehr als 90% unter Idealbedingungen.
Damit dauert die Bearbeitung der Ergebnisse oft länger als das Abtippen – vor allem weil a und o, l und 1 sowie in bzw. rn und m Fehler auch beim Korrekturlesen nur schwer zu finden sind, wenn man den Text schon kennt.
Dabei würde mit kooka eine völlig ausreichende Oberfläche für OCR zur Verfügung stehen, die bis auf Mehrfachauswahlen schon fast alles mitbringt, was man im OCR Alltag als Pauker braucht.
sudo apt-get install kooka ocrad gocr
Unter Hardy und Gnome nistet sich kooka dann im Menü unter /Anwendungen /Grafik ein.
Der Scan erfolgt aus der Oberfläche von kooka heraus.
Bei der ersten Verwendung fragt kooka nach dem Standarddateiformat, in dem die Scans in einer Art „internen Speicher“ vorrätig gehalten werden sollen.
Nach einer einfachen Auswahl des zu übersetzenden Bildbereichs mit der Maus kann das OCR durch Klick auf das entsprechende Icon auch einfach gestartet werden – hier mit ocrad.
Nach kurzer Zeit wird ein Textfensterchen mit dem Plaintextergebnissen eingeblendet. Ein Klick in das Fenster gefolgt von [Strg] [A] und [Strg] [C] sowie ein folgender Klick in die Textverarbeitung und [Strg] [V] erledigt den Rest. Jetzt darf Korrektur gelesen werden – und das nicht zu knapp.
Völlig unerträgliche Ergebnisse werden IMHO mit gocr erzeugt, das als Erkennungsengine ebenfalls eingestellt werden kann. Die Installation von ocrad lohnt also. Außerdem ist ocrad meist um Einiges schneller als gocr.
Was weder unter gocr noch ocrad funktioniert ist die Erkennung von Layouts. Selbst einfachste Tabellen, wie im Bild oben leidlich zu erkennen, bringen beide OCR völlig aus dem Tritt. Was relativ gut hinhaut ist, wenn man etwas Glück hat, die Erkennung von reinen Textblöcken bei serifenlosen Schriften mit mindestens 12 Pixel Schriftgröße.
Im Alltag setze ich an dieser Stelle auf eine VM unter Windows 98 SE oder auch Windows XP. Für beide Betriebssysteme habe ich schließlich Lizenzen irgendwann im Laufe meiner Computergeschichte erworben, warum sollte ich diese verkommen lassen?
In diese VM habe ich mir einen FineReader 6 installiert, den ich einst bei pearl für 5€ kaufte (oder war es bei zweitausendeins? Ich weiß es nicht mehr). Der Scan erfolgt unter Linux mit Sane, die Bilder werden in einem Tauschverzeichnis abgelegt auf das aus der VM heraus zugegriffen werden kann. Die Ergebnisse des FineReader – meist erstelle ich eine DOC und eine TXT Datei – landen dann ebenfalls wieder im Tauschverzeichnis. Die Weiterverarbeitung erfolgt dann in OpenOffice. Sobald das Endergebnis fertig ist, lösche ich die Inhalte im Tauschverzeichnis. Insgesamt recht umständlich – aber im Alltag viel viel schneller und weniger Nervenaufreibend als die Arbeit mit kooka und ocrad / gocr. Leider habe ich es bisher nicht hinbekommen den FineReader unter Wine zur Mitarbeit zu überreden – das wäre eindeutig die bessere Lösung. Andere waren da erfolgreicher: WineHQ
Bis tesseract soweit ist werde ich wohl bei diesem workaround bleiben müssen. Leider.
Nur als Memo für mich, da mich dies demnächst auch selbst erwartet: Der Umzug des IPCop der Rea war relativ einfach zu bewerkstelligen – sofern man sich gleich von Anfang an an die Anleitung im Adminhandbuch hält 😉
Zuerst wird ein Backup eines noch funktionierenden, alten IPCops erstellt, das das Skript unter /var/backup/linuxmuster/ipcop mit Zeit und Datumsstempel ablegt:
/usr/share/linuxmuster-ipcop/backup-settings.sh
Hier wäre demnach auch eine Eingriffsmöglichkeit zu finden, falls beim Restore Änderungen nötig werden – durch Löschen der Backupdatei, die nicht-funktionierende Systemzustände beinhalten: Das Restore Skript greift sich jeweils das aktuellste Backup!
Dann die neue Hardware nach der Installation des IPCop von der paedML CD ins Netz hängen und kurz überprüfen, ob diese vom Server aus zu erreichen ist. Wenn ja, wird der Restoreprozess gestartet:
/usr/share/linuxmuster-ipcop/restore-dedicated.sh
Die Bildschirmausgabe hierzu:
linuxmuster’s dedicated IPCop restoring tool
——————————————–Please enter IPCop’s root password:
Moving known_hosts away …
Uploading ssh key … Success!
Reading IPCop version … Success!
Upgrading IPCop 1.4.18 to 1.4.19 … Success!
Upgrading IPCop 1.4.19 to 1.4.20 … Success!
Upgrading IPCop 1.4.20 to 1.4.21 … Success!
Creating addon package … Success!
Uploading addon package … Success!
Installing addons (may take a while) … Success!
Restoring settings from backup:
* Uploading archive backup-090102-094722.tar.gz … Success!
* Unpacking archive … Success!
Done. Rebooting IPCop.
Nach einem erfolgreichen Reboot des „neuen“ IPCop fehlt noch ein reconfigure:
# dpkg-reconfigure linuxmuster-ipcop
Backing up ipcop settings to /var/backup/linuxmuster/ipcop …
Checking IPCop’s time server config …
Checking IPCop’s extern access config …
Checking IPCop’s bot config …
Checking if BOT’s admin mac is set …
Setting BOT’s admin mac to server’s internal mac address …
Für den Abschluss muss dann noch überprüft werden, ob die Keys an den richtigen Stellen liegen:
# ssh ipcop -p 222
The authenticity of host ‚ipcop (10.16.1.254)‘ can’t be established.
RSA key fingerprint is dd:f6:f8:ac:22:4c:bd:71:e1:8b:97:b4:b0:ca:e3:67.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added ‚ipcop‘ (RSA) to the list
Fertig. Sollte auf dem neuen IPCop eine andere Netzwerkkartenkonfiguration vorhanden sein hilft ein
setup
auf der IPCop-Root-Konsole weiter, das den Setupprozess des IPCop anwirft.
Seit nunmehr einem Jahr gibt es nur noch Tux auf meinem Produktivsystem – und passend zu diesem Datum liefert die ARD auch gleich eine Doku zum Maskotchen: Die Reise der Pinguine
Ganz so schwer wie die Aufzucht der Kleinen für die Kaiserpinguine in der Doku war es dann doch nicht, dieser Umstieg von XP auf Linux, auch wenn es doch einige Hürden zu nehmen galt. Diese ganzen – sicherlich sehr persönlichen – Erfahrungen seien hier mal kurz zusammengefasst:
Dass mein Umstieg auch nach einem Jahr noch nicht komplett abgeschlossen ist, steht in der Liste zwischen den Zeilen: Noch immer vergleiche ich meine Möglichkeiten und auch konkrete Anwendungen unter Linux mit denen, die ich unter XP hatte. Nach einer so langen Prägungsphase ist das kein Wunder – aber für viele Menschen sicherlich der Hauptgrund, warum diese überhaupt nicht an Veränderungen denken.
Die Macht der Gewöhnung sorgt für die Einnahmen von MS – sicherlich auch in Zukunft.