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.

Lucid auf Dell

Auf meinen Dell D830 und Vostro 1510 hat die Installation des Lucid RC reibungslos geklappt. Eine Dokumentation der Programme und Installationsschritte ist im KvFG Wiki zu finden.

Das einzige Programm, das ich bisher noch nicht installiert habe und das auf Karmic auch gleich am ersten Tag mit an Bord kam, war meine VMWare Workstation in der Version 6.5.4. Eine Installationsanleitung, wenn auch sehr kurz, ist aber im Netz zu finden. So simple sieht die mir aber nicht aus und deswegen versuch ich jetzt erst einmal vollständig ohne VM aus zukommen. VirtualBox wird hoffentlich bald ein Alternativangebot machen und so lange kann ich auf Web-OCR zurückgreifen.

Linsenbühl

Der Linsenbühl ist ein Sammlung an Felsen oberhalb der Schlösslessteige in Lichtenstein und enthält ein paar nette Höhlen. Eine der längeren dürfte rund 130m haben und diese haben wir heute, so weit die Kinder konnten, durchkrochen.

https://www.openstreetmap.org/?lat=48.411965&lon=9.25736&zoom=15&layers=B000FTFTT&mlat=48.41024&mlon=9.25318

Von der Schlösselsteige aus ist (im Herbst und im Frühjahr) die rechte Höhle zu sehen, die allerdings weniger interessant, weil nur rund 3m tief ist. Dafür kann man dort gut sitzen und vespern.

Der Aufstieg zur Höhle ist recht beschwerlich, weil der Hang überwiegend aus Laub und Schotter besteht und dauernd unter den Füßen wegrutscht. Mit einem Seil (und einem gewandten Vorkletterer) geht es dann aber, wenn man diagonal läuft und so den kleinen Lawinen der Vorkletterer ausweicht.

Der Eingang zur linken Höhle ist selbst oben am Hang kaum zu sehen.

Nach einer hübschen ersten Halle mit Kamin folgt eine Gangstrecke, die mehr oder weniger klar Schlüssellochprofil erkennen lässt. Stellenweise ist die Druckröhre noch klar zu sehen.

Weiter hinten wird der Gang dann zuerst zunehmend schmaler …

… und dann auch niedriger. Die letzte Hälfte darf man in einem linsenförmigen Gang durch ziemlich zähen Höhlenlehm robben, der einem fast die Hose auszieht.

Ganz am Ende wurde die Höhle dann leider für mich zu eng, kleinere Persönchen kommen aber durchaus noch ein paar Biegungen weiter.

Wadelbrunnen

Wir waren am Mittwoch kurz bei der Falke, die hübsch schüttete, was auch schon auf der Höhe des Elsachbröllers gut zu sehen war, weil das Flussbett gut Wasser führte. Außerdem schütteten die Elsach-Hang- sowie auch die Elsach-Wiesenquelle.

https://www.openstreetmap.org/?lat=48.511325&lon=9.44833&zoom=16&layers=B000FTFTT&mlat=48.51132&mlon=9.44774

Den Wadelbrunnen suchten wir dann als nächstes.

Auch dieser musste erst vor Kurzem Wasser gespuckt haben: Viele Blätter lagen noch über weite Strecken perfekt ausgerichtet im Bachbett. Der Wadelbrunnen selbst war kaum zu sehen.

Nach etwas Buddeln konnte aber der Eingang vom Laub befreit werden.

Leider verließ meine Arbeiter aber nun die Lust am Graben – die fast 1m dicke Laubschicht im Bachbett war anziehender.

Eingraben

Reinhüpfen

Abtauchen

Backup II

Nicht wundern – rsnapshot meldet in seinem Log

[14/Mar/2010:15:30:01] /usr/bin/rsnapshot weekly: started
[14/Mar/2010:15:30:01] echo 18667 > /var/run/rsnapshot.pid
[14/Mar/2010:15:30:01] rm -f /var/run/rsnapshot.pid
[14/Mar/2010:15:30:01] /usr/bin/rsnapshot weekly: completed successfully

aber auf der Sicherungsplatte ist evtl. nichts zu sehen.

Das liegt daran, dass rsnapshot erst dann einen Ordner weekly.0 anlegt und das dazu gehörende Backup ausführt, wenn die in der /etc/rsnapshot.conf angegebene Zahl an daily Sicherungen erreicht wurde. Das Gleiche gilt dann auch für monthly Sicherung. [Quelle]

Lösung: Abwarten.

Mehrseitendruck

Der Ausdruck von mehreren Seiten auf ein Din A4 Blatt lässt sich unter Linux vielfältig organisieren. gtklp ist eine Möglichkeit, die ich hier schon beschrieben habe. Auf der shell eigenet sich psnup oder auch mpage.

Dabei kann zumindest OpenOffice das auch von sich aus – und zwar aus der Seitenansicht heraus.

Zuerst werden in der Seitenansicht selbst die „Druckoptionen Seitenansicht“ aufgerufen – das ist das Icon mit der zeigenden Hand links vom „Seitenansicht schließen“ Knopf.

Hier kann die Aufteilung der zu druckenden Seiten auf das Einzelblatt eingestellt werden.

Zum Abschluss den Schalter „Seitenansicht drucken“ in der Seitenvorschau anklicken.

Backup

Bisher nutzte ich rsync bzw. grsync für ein von Hand angestoßenes Backup meines /home Verzeichnisses auf ein über NFS gemountetes Volume auf meinem heimischen Backupserver.

Jetzt hab ich mir zusätzlich, für die tägliche Praxis, noch rsnapshot installiert und bin mehr als zufrieden.

sudo apt-get install rsnapshot

Konfiguration

Dann wird die zentrale Konfigurationsdatei angepasst. Hierbei muss als Trennzeichen immer Tab verwendet werden und nicht Space:

sudo vi /etc/rsnapshot.conf

Hier habe ich eine USB Festplatte als Backupmedium definiert, nachdem ich das Verzeichnis auf dieser angelegt hatte,

snapshot_root   /media/trekstore/rsnapshot/

und dann dafür gesorgt, dass rsnapshot nur arbeitet, wenn die Platte auch angeschlossen ist:

no_create_root  1

Im Bereich Interval wird angegeben, wie viele Backups jeweils gespeichert werden sollen:

interval        daily   7
interval        weekly  4
interval        monthly 6

Am Ende dieser Konfigurationsdatei können dann die Verzeichnisse (und auch Dateien sowie auszuschließende Dateien etc.) definiert werden, die in das Backup geschrieben werden:

backup  /home/dirk/.evolution/  localhost/
backup  /home/dirk/.mozilla/    localhost/
backup  /home/dirk/.ssh/        localhost/
backup  /home/dirk/MyPDA/       localhost/
backup  /home/dirk/openvpn/     localhost/
backup  /home/dirk/Dokumente/   localhost/
backup  /home/dirk/Public/      localhost/
backup  /home/dirk/Bilder/      localhost/
backup  /home/dirk/Desktop/     localhost/
backup  /home/dirk/Vorlagen/    localhost/

Der trailing Slash ist ebenso Pflicht wie die Angabe von localhost.

Ob man bei der Syntax etwas verbockt hat, zeigt ein

sudo rsnapshot configtest

Syntax OK sollte als Antwort kommen – oder die Zeilennummer mit dem Fehler.

Starten

Für den ersten Aufruf könnte man noch den Verbose Level in der Konfigurationsdatei höher einstellen, damit man nicht nur warten darf, sondern auch was sehen kann:

verbose         3

Per Hand gestartet mit

sudo rsnapshot daily

fängt das Programm nun an zu werkeln.

Da händisch anzustoßende Backups aber immer wieder in Vergessenheit geraten, sollten Backupjobs eigentlich über cron bzw. anacron gestartet werden. Zumindest war das meine Motivation bei der Installation von rsnapshot. Ich wählte für meinem Desktoprechner anacron – wer weiß, wann der läuft;  anacron holt dann vergessene Jobs nach.

Hierzu wird im Ordner

/etc/cron.daily

mit Rootrechten eine Datei mit dem Namen rsnapshot angelegt,

sudo vi /etc/cron.daily/rsnapshot

die den folgenden Inhalt hat:

#!/bin/sh
/usr/bin/rsnapshot daily

Für die Verzeichnisse

/etc/cron.weekly
/etc/cron.monthly

wird der Vorgang wiederholt und der Aufruf von rsnapshot entsprechend angepasst.

Mit

sudo su –

nun in den Rootaccount gewechselt und

crontab -e

aufgerufen. Das startet nano als Editor, womit jeder zu Recht kommen sollte.

Hier wurden dann die Aufrufzeiten für die Backups eingetragen:

# m h  dom mon dow   command
30 8,12,18 * * *      /usr/bin/rsnapshot daily
30 15           * * 0     /usr/bin/rsnapshot weekly
30 19         1 * *       /usr/bin/rsnapshot monthly

Wichtig ist, dass zwischen daily, weekly und monthly zeitlich genug Platz ist, sollten die Jobs durch einen dummen Zufall sich an einem Tag „zeitlich kreuzen“ und sich so gegenseitig behindern. rsnapshot würde in einem solchen Fall einen der Jobs schlicht auslassen.

Die Wirkung des eigenen Eintrags in die crontab kann man auf dieser Seite gut testen: http://www.hxpi.com/cron_sandbox.php und so sicher stellen, dass man keinen Mist einträgt.

Das war’s.

Der erste Aufruf von rsnapshot nimmt etwas Zeit in Anspruch – danach rast das Backup meiner rund 200GB zu sichernden Daten in weniger als 3 Minuten durch, weil nur veränderte Dateien geschrieben werden. Alle anderen Dateien werden nur als Hardlinks angelegt. rsnapshot spart mit diesem Verfahren ziemlich Platz und ich kann unterbrechungsfrei weiter arbeiten.

Weiter: Nachtrag zum Thema „Wo ist denn nun meine weekly.0 Sicherung?“

64 Bit Papierformat

US Letter PDF Dokumente so auszudrucken, dass diese zentriert auf DIN A4 erscheinen ist nicht nicht so trivial, wie ich dachte. Klar – es gibt die Möglichkeit den Job an Acrobat zu übergeben, das auch im Partner Repo von Ubuntu zu finden ist. Acrobat zentriert von sich aus, ist für 64 Bit Hardy aber nicht nativ zu haben. Das Gefummel mit getlibs wollte ich mir sparen.

Also dann halt mit evince.Theoretisch sollte der folgende Ansatz zum Erfolg führen:

Evince ignoriert die Angaben in /etc/papersize und auch in /usr/share/ghostscript/8.61/lib/gs_init.ps. Auf Teufel komm raus will das Ding die Angaben in /etc/environment haben und dort als

LC_PAPER=“de_DE.UTF-8″

dann sieht evince – so die Theorie – endlich ein, dass es sich auf einem deutschen Rechner befindet und behandelt PDFs dementsprechend.

Auf meinem 64 Bit Hardy ist dem nicht so. Ich konnte im Druckdialog von evince zwar A4 einstellen – aber das US Letter Dokument wurde nicht zentriert und der Druck sah schwer danach aus, also wäre US Letter schlicht auf ein zu großes Blatt gepresst worden.

Was ich dann probierte, war eine Umwandlung von US Letter nach DIN A4 mit psresize. Theoretisch klappt das wie folgt:

psresize -w279mm -h216mm -W297mm -H21cm -q input.pdf output.pdf

psresize kennt auch einige Kurzformen, die in der Manpage dokumentiert sind und dann wie folgt zu schreiben wären:

psresize -Pletter -pA4 in.pdf out.pdf

Installiert wird das Paket psresize unter Hardy mit

sudo apt-get install psutils

Leider war das aber auch nur pure Theorie: Hardy 64 Bit wandelt nicht – das PDF bleibt im Format US Letter.

Die einzige Lösung, die ich dann noch hatte, war der Druck mit gv – das dann endlich das Papier zentrierte und zwar offensichtlich gleich von sich aus, als default.

Sun Java 6 auf Hardy 64 Bit

Was hab ich mir nicht einen abgebrochen mit Symlinks nach irgendwelchen Anleitungen in Blogs und Foren zu setzen, um das Sun Java Firefox Plugin unter Ubuntu Hardy 64 Bit zum Laufen zu überreden.  Am Ende war es ganz einfach und klappte ohne Gefummel in den Untiefen des Systems durch den Rauswurf von IcedTea:

sudo apt-get remove –purge icedtea-gcjwebplugin

Dann wird Suns Java schlicht erneut installiert:

sudo apt-get reinstall sun-java6-bin sun-java6-fonts sun-java6-jre sun-java6-plugin

Fertig.

Keine Ahnung warum das nun will und früher nicht. Meiner Erinnerung nach hab ich IcedTea irgendwann installiert, um Java zum Laufen zu überreden – aber ich kann mich auch täuschen. Auf jeden Fall hab ich so kurz vor Erscheinen von Lucid ein rund um konfiguriertes 64 Bit System, in dem auch das Dragmath-Plugin für Moodle läuft.

Das brauch ich zwar nicht – aber nett ist es trotzdem 🙂