Aus alter Gewohnheit läuft man Arbeitsplatzrechner noch mit einem 32-Bit Ubuntu. Das möchte ich ändern und habe testweise ein 64-Bit Ubuntu 16.04 installiert.

Nun habe ich eine Anwendung, für die ich kein aktuelle Download-Verzeichnis kenne und für die ich keine 64-Bit Version bekommen kann. Diese Anwendung ist der PDF-Editor Cabaret Stage.

Im Prinzip lässt sich auch ein 32-Bit Java auf einem 64-Bit Linux installieren. Dazu holt man sich bei Oracle einfach die entsprechende Version, z.B. jre-8u102-linux-i586.tar.gz . Dieses Archiv kann man dann z.B. im Verzeichnis /opt entpacken. Ich habe das entstandene Verzeichnis dann etwas umbenannt, so dass mein Java unter /opt/jre32 erreichbar ist.

Im Startprogramm cabaretstage.sh habe ich dann die Zeile mit dem eigentlichen Programmaufruf erweitert zu:

/opt/jre32/bin/java -classpath "$MY_CLASSPATH" -Xms64m -Xmx256m com.cabaret.claptz.stage.main.StandardStage $*

Dadurch wird das systemweit installierte Java überhaupt nicht gestört.

Leider gibt es nun das Problem, dass im Zusammenhang mit dem Java AWT eine Reihe von 32-Bit Bibliotheken benötigt wird. Zum Glück kann man die auch auf einem 64-Bit System zusätzlich installieren.

sudo apt install libgtk2.0-0:i386 libxtst6:i386 libfreetype6:i386 libxrandr2:i386 libglib2.0-0:i386 libpulse0:i386 libgdk-pixbuf2.0-0:i386
sudo apt install libnspr4:i386 gtk2-engines-murrine:i386 libgail-common:i386 gnome-session-canberra:i386
sudo apt install libfreetype6:i386 unity-gtk3-module:i386 unity-gtk2-module:i386 atk-bridge2.0-0:i386 libcurl3:i386

Es werden dann noch einige Pakete aufgrund von Abhängigkeiten installiert.

dpkg-query -l *:i386

liefert bei mir als Ergebnis insgesamt 169 Pakete.

Dann noch

cd /usr/lib/i386-linux-gnuln -s libfreetype.so.6 libfreetype.so
Veröffentlicht unter linux.

Mit letsencrypt soll es für alle Webseiten einfach und erschwinglich werden eine Verschlüsselung zu ermöglichen.

Eine schöne Beschreibung findet sich unter https://lukasthiel.de/wiki/SSL-Zertifikate_mit_Let%27s_Encrypt

Installation

Die Installation erfolgt mittels:

cd /root
git clone https://github.com/letsencrypt/letsencrypt

Das Script lädt notwendige Pakete und Aktualisierungen beim ersten Aufruf nach, hier z.B. über den Aufruf der Hilfefunktion:

/root/letsencrypt/letsencrypt-auto -h

Dabei werden einige Pakete über die Paketverwaltung der Distribution ergänzt und zusätzlich einiger Python-Code nach /root/.local/share/letsencrypt/ gebracht.

Bootstrapping dependencies for openSUSE-based OSes...

The following 8 NEW packages are going to be installed:
  dialog libdialog11 libffi48-devel python-devel python-pip python-setuptools 
  python-virtualenv python-xml 

The following package is suggested, but will not be installed:
  terminfo 

8 neue Pakete zu installieren.
Gesamtgröße des Downloads: 5,8 MiB. Nach der Operation werden zusätzlich 26,8 
MiB belegt.
Fortfahren? [j/n/? zeigt alle Optionen] (j): j
Creating virtual environment...
Installing Python packages...
...

Am Ende wird der Hilfe-Text ausgegeben.

Das Tool legt an einer Reihe von Stellen Dateien ab:

  • /etc/letsencrypt/  hier liegen die Zertifikate und die zugehörigen Einstellungen
  • /root/.local/share/letsencrypt/ in diesem Verzeichnis liegen die benötigten Python Scripte
  • /var/log/letsencrypt hier liegt die Logdatei und die zugehörigen Archive
  • /var/lib/letsencrypt für Backups
  • /root/letsencrypt vom Benutzer festgelegtes Verzeichnis für das Programmpaket, denkbar z.B. auch /opt/letsencrypt

Zertifikats-Erzeugung im Dialog

Der Aufruf von

/root/letsencrypt/letsencrypt-auto --rsa-key-size 4096 certonly

erzeugt dann im Prinzip das Zertifikat. Bei mit (OpenSUSE) wollte das nicht funktionieren, weil das Tool das Verzeichnis /etc/apache2/sites-enabled vermisste. Nachdem ich das Verzeichnis angelegt hatte (das Verzeichnis selber kann leer bleiben) ließ sich das Zertifikat erzeugen.

Es startet ein fensterbasiertes Tool an der Konsole. Im ersten Schritt gibt man an, wie sich der Webserver gegenüber dem Zertifikats-Aussteller authentifizieren soll. Die einfachste Version besteht darin das Script eine Datei im Webroot der Seite plazieren zu lassen. Dazu muss das Script die Pfade kennen:

letsencrypt-1

letsencrypt-2

letsencrypt-3

letsencrypt-4

Wenn die Datei über den Webserver erreichbar war, dann kommt die Erfolgsmeldung:

IMPORTANT NOTES:
 - Congratulations! Your certificate and chain have been saved at
   /etc/letsencrypt/live/elearn-server.de/fullchain.pem. Your cert will
   expire on 2016-09-14. To obtain a new or tweaked version of this
   certificate in the future, simply run letsencrypt-auto again. To
   non-interactively renew *all* of your certificates, run
   "letsencrypt-auto renew"
 - If you lose your account credentials, you can recover through
   e-mails sent to <admin>@<domain>.
 - Your account credentials have been saved in your Certbot
   configuration directory at /etc/letsencrypt. You should make a
   secure backup of this folder now. This configuration directory will
   also contain certificates and private keys obtained by Certbot so
   making regular backups of this folder is ideal.
 - If you like Certbot, please consider supporting our work by:

   Donating to ISRG / Let's Encrypt:   https://letsencrypt.org/donate
   Donating to EFF:                    https://eff.org/donate-le

Zertifikats-Erzeugung mit Parametern

Man kann sich den Ablauf auch etwas einfacher machen, vor allem, wenn man mehrere Domains betreut, indem man statt der Dialog orientierten Variante eine Parameter orientierte Variante benutzt (alles in einer Zeile):

/root/letsencrypt/letsencrypt-auto --rsa-key-size 4096 certonly --webroot -w /srv/www/vhosts/elearn-server.de/httpdocs/ -d elearn-server.de -d www.elearn-server.de

Für umfangreiche Nutzung kann es noch geschickter sein sich für jede Domain eine Konfigurationsdatei, z.B. letsencrypt.ini, anzulegen

# Wir nutzen 4096 bit RSA key statt 2048
rsa-key-size = 4096

# allgemeine Angaben
email = <admin>@<domain>
authenticator = webroot

# Domains fuer die wir Zertifikate beantragen, die erste in
# der liste legt den Hauptnamen fest. Alle Domains müssen beim
# Aufruf erreichbar sein
domains = elearn-server.de, www.elearn-server.de

# Dies ist das Verzeichnis zur Domain, wo letsencrypt seinen Hash in
# /.well-known/acme-challenge schreiben will. Der Pfad muss auf / enden
webroot-path = /srv/www/vhosts/elearn-server.de/httpdocs/

Aufgerufen wird letsencrypt-auto dann mittels (alles in einer Zeile):

/root/letsencrypt/letsencrypt-auto certonly --config /srv/www/vhosts/elearn-server.de/letsencrypt.ini

Aufpassen muss man aber unbedingt mit Subdomains. Letsencrypt lässt nämlich nur etwa 5 Aufrufe pro Domain und Woche zu. In dem Beispiel sind dann schon zwei Aufrufe verbraucht. Mehr als 5 Subdomains im gleichen Zertifikat sind wohl nicht möglich.

Im Laufe der Erzeugung legt letsencrypt in der Wurzel des angegebenen Servers ein Verzeichnis .well-known an. Das Zertifikat selber wird unter /etc/letsencrypt/live/<domain>/ abgelegt und besteht aus den vier Dateien

  • cert.pem
  • chain.pem
  • fullchain.pem
  • privkey.pem

dies sind Links auf die Dateien

  • /etc/letsencrypt/archive/<domain>/cert1.pem
  • /etc/letsencrypt/archive/<domain>/chain1.pem
  • /etc/letsencrypt/archive/<domain>/fullchain1.pem
  • /etc/letsencrypt/archive/<domain>/privkey1.pem

Diese Verlinkung soll vermutlich die Aktualisierung der Zertifikate vereinfachen.

Apache konfigurieren

Jetzt muss nur noch der Apache-Webserver von den neuen Möglichkeiten wissen. Die notwendigen Einstellungen für den Host sind in der Datei /etc/letsencrypt/options-ssl-apache.conf zu finden:

# Baseline setting to Include for SSL sites

SSLEngine on

# Intermediate configuration, tweak to your needs
SSLProtocol             all -SSLv2 -SSLv3
SSLCipherSuite          ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA
SSLHonorCipherOrder     on
SSLCompression          off

SSLOptions +StrictRequire

# Add vhost name to log entries:
LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-agent}i\"" vhost_combined
LogFormat "%v %h %l %u %t \"%r\" %>s %b" vhost_common

#CustomLog /var/log/apache2/access.log vhost_combined
#LogLevel warn
#ErrorLog /var/log/apache2/error.log

# Always ensure Cookies have "Secure" set (JAH 2012/1)
#Header edit Set-Cookie (?i)^(.*)(;\s*secure)??((\s*;)?(.*)) "$1; Secure$3$4"

Testen kann man das Zertifikat dann unter https://www.ssllabs.com/ssltest/

Weitere Informationen

Möchte man sein Zertifikat um weitere Subdomains erweitern, so ist das kein Problem. Hat man z.b. nur für <domain> und www.<domain> ein Zertifikat erstellt und möchte jetzt auch blog.<domain> mit aufnehmen, so erweitert man einfach die Liste der Domains entsprechend und löst die Erstellung des Zertifikats erneut aus. Es erscheint jetzt ein Dialog, der nachfragt, ob man das Zertifikat erweitern möchte. Hier klickt man auf Expand und wenn die Subdomain erreichbar ist, dann wir das Zertifikat neu erzeugt.
Laut https://community.letsencrypt.org/t/rate-limits-for-lets-encrypt/6769 gilt hierfür nicht das Limit von 5 pro Woche.

Unter /etc/letsencrypt/csr/ findet man die Key-signing-requests, ein Hinweis darauf, dass das Schlüsselpaar auf dem eigenen Server erzeugt wurde und der private Schlüssel auch letsencrypt nicht bekannt ist.

Bei owncloud gibt es einen Abschnitt in der .htacess, der die Überprüfung durch letsencrypt verhindert:

<IfModule mod_rewrite.c>
RewriteEngine on
RewriteRule .* - [env=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
RewriteRule ^\.well-known/host-meta /public.php?service=host-meta [QSA,L]
RewriteRule ^\.well-known/host-meta\.json /public.php?service=host-meta-json [QSA,L]
RewriteRule ^\.well-known/carddav /remote.php/carddav/ [R=301,L]
RewriteRule ^\.well-known/caldav /remote.php/caldav/ [R=301,L] 
RewriteRule ^apps/calendar/caldav\.php remote.php/caldav/ [QSA,L]
RewriteRule ^apps/contacts/carddav\.php remote.php/carddav/ [QSA,L]
RewriteRule ^remote/(.*) remote.php [QSA,L]
RewriteRule ^(build|tests|config|lib|3rdparty|templates)/.* - [R=404,L]
RewriteRule ^(\.|autotest|occ|issue|indie|db_|console).* - [R=404,L] 
</IfModule>

Das Einfügen der Zeile

RewriteRule ^\.well-known/acme-challenge - [L]

löst das Problem. Mal sehen,  ob es Seiteneffekte gibt.

 

Löschen von Schlüsseln

Mit

/root/letsencrypt/certbot-auto certificates

kann man abfragen, wie die Zertifikate auf dem Server genau heißen und die zugehörigen Dateien dann mittels

/root/letsencrypt/certbot-auto delete --cert-name <gefundener Name>

vom eigenen Server entfernen.

Mit folgendem Kommando kann man abfragen, welche Domains im Zertifikat eingetragen sind:

openssl x509 -in /etc/letsencrypt/live/<domain-bezeichnung>/cert.pem -text -noout | grep DNS

Mit den Schritten ist das Zertifikat selber aber nicht gelöscht, das wäre dann erst nach einigen Tagen automatisch der Fall. Noch nicht getestet habe ich die Schritte:

certbot revoke --cert-path /PATH/TO/cert.pem --key-path /PATH/TO/key.pem

das müsste natürlich vor dem Löschen der lokalen Dateien erfolgen.

 

Links

Ruft man unter Linux mit dem Firefox eine Youtube-Seite auf, so wird das Video im Dateisystem temporär gespeichert. Lange Zeit konnte man die zugehörige Datei im Verzeichnis /tmp finden. Sie wurde erst beim Schließen des Browser-Fensters gelöscht. Seit einiger Zeit hat sich das Verhalten, zumindest bei Ubuntu, deutlich verändert.

Die Datei wird zwar im /tmp -Verzeichnis angelegt, aber gleich wieder glöscht. Dafür kann man sie im Cache-Verzeichnis des Firefox finden.

Es gibt jetzt also zwei Möglichkeiten an die Flash-Datei zu kommen (die entsprechenden Informationen habe ich unter http://sartoo.de/articles/update–flash-videos-werden-nicht-mehr-unter–tmp-gespeichert.html gefunden):

1. Cache-Verzeichnis

Der Firefox legt die gecachten Dateien im Home-Verzeichnis des Benutzers ab und zwar unter:

~/.mozilla/firexox/<kryptische zeichenkette>.default/Cache/

Die kryptische Zeichenkette ist für jeden Benutzer verschieden. Für das Video http://www.youtube.com/watch?v=qFCj0FJ7Ia4 finde ich hier folgenden Eintrag, wenn das Video vollständig geladen wurde:

-rw-------  1 debacher debacher 11931147 2011-07-09 17:06 A2E8FC60d01

als Dateiname dient hier eine wohl zufällige Zeichenkette. Im Nautilus-Browser wird beim Anzeigen des Verzeichnisses ein Vorschaubild angezeigt.

2. /tmp/Verzeichnis

Im Verzeichnis /tmp ist die Datei zwar gelöscht, sie ist aber vom Flash-Player geöffnet und solange sie geöffnet ist kann man ihren Inhalt auch wieder aktivieren. Dazu muss man erst einmal mittels lsof den Dateinamen bestimmen:

lsof  +aL1 /

zeigt alle Dateien an, die zwar geöffnet sind, aber weniger als einen Dateilink besitzen, genau so etwas suchen wir:

COMMAND    PID     USER   FD   TYPE DEVICE SIZE/OFF NLINK NODE NAME
plugin-co 7275 debacher   16u   REG    8,6 11931147     0 8927 /tmp/FlashXXwFVrmk (deleted)

Man sieht hier die gleiche Dateigröße wie im Cache-Verzeichnis, aber einen etwas sprechenderen Namen. Diese Datei kann man nun aus dem /proc-Dateisystem restaurieren:

 cat /proc/7275/fd/16 > /tmp/FlashXXwFVrmk

Dabei entspricht die 7275 hier der PID aus der lsof-Anzeige und die 16 ist der numerische Teil der FD. Der Dateiname des Ziels ist eigentlich beliebig, muss nicht mit dem Originalnamen übereinstimmen.

 

In manchen Netzwerke sind alle Ports gesperrt. Aber die Ports 80 und meist auch 443 sind zumindest über einen Proxy erreichbar. Diese Situation kann man ausnutzen, um trotzdem über eine OpenVPN-Verbindung eine Zugriff auf alle Dienst zu ermöglichen.

Man benötigt hierfür aber einen Rechner, der außerhalb des gesicherten Netzwerkes steht und ständig erreichbar ist. Notfalls reicht aber auch ein heimischer Rechner mit einer DynDNS-Adresse. Auf diesem Rechner erfolgt die Serverkonfiguration von OpenVPN, auf dem Arbeitsplatzrechner im abgeschotteten Netz die Client-Konfiguration.

Ich bin im Prinzip lediglich der Anleitung unter http://wiki.ubuntuusers.de/openvpn gefolgt. Die Beschreibungen gehen davon aus, dass OpenVPN bereits installiert ist.

Auf dem Server

sudo cp /usr/share/doc/openvpn/examples/sample-config-files/server.conf.gz /etc/openvpn/
sudo gunzip /etc/openvpn/server.conf.gz
sudo cp -r /usr/share/doc/openvpn/examples/easy-rsa/2.0 /etc/openvpn/easy-rsa2

Damit werden die Beispieldateien in den Konfigurationsordner von OpenVPN kopiert.

Nun wechselt man in den neuen Ordner easy-rsa2:

cd /etc/openvpn/easy-rsa2

und editiert dort die Datei vars

export KEY_COUNTRY=DE
export KEY_PROVINCE=NRW
export KEY_CITY=Düsseldorf
export KEY_ORG=”Vpntest”
export KEY_EMAIL=”onlyspam@myhomepage.net”

Diese Werte passt man an die eigenen Gegebenheiten an.

Dann kann man aus dem Verzeichnis easy-rsa2 heraus mit folgenden Schritten die Schlüssel erzeugen:

sudo mkdir keys
source ./vars
sudo -E ./clean-all
sudo -E ./build-ca
sudo -E ./build-key-server server
sudo -E ./build-key meinclient
sudo -E ./build-dh

Hierdurch werden im Verzeichnis keys die notwendigen Schlüssel erzeugt.Von den dort angelegten Dateien müssen drei später zum Client-Rechner kopiert werden:

  • ca.crt
  • meinclient.crt
  • meinclient.key

Jetz muss man noch die Server-Konfigurationsdatei anpassen, die wir nach /etc/openvpn kopiert haben. Da die Datei 300 Zeilen lang ist, hier nur die veränderten Zeilen:

# Which TCP/UDP port should OpenVPN listen on?
# If you want to run multiple OpenVPN instances
# on the same machine, use a different port
# number for each one.  You will need to
# open up this port on your firewall.
;port 1194
port 443

# TCP or UDP server?
proto tcp
;proto udp

...

# Any X509 key management system can be used.
# OpenVPN can also use a PKCS #12 formatted key file
# (see "pkcs12" directive in man page).
ca ./easy-rsa2/keys/ca.crt
cert ./easy-rsa2/keys/server.crt
key ./easy-rsa2/keys/server.key  # This file should be kept secret

# Diffie hellman parameters.
# Generate your own with:
#   openssl dhparam -out dh1024.pem 1024
# Substitute 2048 for 1024 if you are using
# 2048 bit keys.
dh ./easy-rsa2/keys/dh1024.pem
...

Wichtig ist hier vor allem die Wahl des Ports 443, damit man durch den Proxy kommt und auch das Protokoll TCP, sowie die Pfade zu den Schlüssel-Dateien.

Mit einem Neustart werden die Einstellungen aktiv:

sudo /etc/init.d/openvpn restart

Client

Wenn der Server läuft, dann geht es an die Client-Konfiguration.Zuerst wird wieder eine Besipieldatei kopiert, jetzt die client.conf.

sudo cp /usr/share/doc/openvpn/examples/sample-config-files/client.conf /etc/openvpn/

Im nächsten Schritt werden jetzt die drei Schlüsseldateien (s.o.) vom Server kopiert, einfach in das Verzeichnis /etc/openvpn.

Nun muss noch die Datei client.conf angepasst werden:

# Are we connecting to a TCP or
# UDP server?  Use the same setting as
# on the server.
proto tcp
;proto udp

# The hostname/IP and port of the server.
# You can have multiple remote entries
# to load balance between the servers.
remote stern.lokales-netz.de 443
...
# SSL/TLS parms.
# See the server config file for more
# description.  It's best to use
# a separate .crt/.key file pair
# for each client.  A single ca
# file can be used for all clients.
ca ca.crt
cert meinclient.crt
key meinclient.key

Nunkann man die Verbindung testweise aufbauen mittels:

openvpn /etc/openvpn/client.conf

Wenn in der Datei /etc/default/openvpn die Zeile

AUTOSTART="none"

steht, dann muss die Verbindung per Hand aufgebaut werden, bei

AUTOSTART="all"

wird sie beim Systemstart automatisch aufgebaut. Nach der Konfiguration kann man per

sudo /etc/init.d/openvpn restart

einen Neustsart auslösen.

Heute tauchte das Problem auf, dass ich einen fertig konfigurierten Server bei mir im Hause testen wollte, unter Nutzung seiner eigenen IP. Mein häuslicher Server hat aber nur noch eine Netzwerkkarte (eth0) und ist auf die IP-Adresse 192.168.1.1 konfiguriert. Der andere Rechner hat eine IP-Adresse von z.B. 143.100.122.200 und ein Gateway von 143.100.122.254.

Also habe ich meinem Rechner virtuell die Gateway-IP gegeben:

ifconfig eth0:1 143.100.122.254

damit ist dann mein Rechner von dem fremden Rechner aus erreichbar, aber nicht das Intenet. Dazu muss man das Forwarding überhaupt aktivieren mittels:

echo 1 > /proc/sys/net/ipv4/ip_forward

Jetzt fehlt nur noch die iptables Regel:

iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

eventuell vorhandene Regeln muss man vorher löschen.

In manchen Netzwerke sind alle Ports gesperrt. Aber die Ports 80 und meist auch 443 sind zumindest über einen Proxy erreichbar. Diese Situation kann man ausnutzen, um trotzdem eine SSH-Verbindung auf den eigenen Rechner zu  ermöglichen. Das Programm shellinabox leistet alles was man braucht.

Auf der Seite http://code.google.com/p/shellinabox/downloads/list sind aktuelle Programmpakete verfügbar, auch ein Debian-Paket für Ubuntu. Dieses Paket kann man durch Anklicken des Links auf der Website mittels GDebi installieren.

Normalerweise lauscht shellinabox auf dem etwas ungewöhnlichen Port 4200, der nicht unbedingt über alles Proxy-Server erreichbar ist. Sofern der lokale Webserver den Port 443 nicht nutzt kann man shellinabox auch auf diesem Port lauschen lassen. Eine Anleitung dazu findet sich unter https://help.ubuntu.com/community/shellinabox.

Letztendlich muss man nur in der Konfigurationsdatei

/etc/default/shellinabox

die Portangabe ändern und das Programm dann mittels

invoke-rc.d shellinabox restart

neu starten.

Von außen ist shellinabox dann mittels:

https://mein-rechner.meine-domain

erreichbar.

Beim Sichern einer Datenbank mittels mysqldump hatte ich das Problem, dass immer irgendeine Fehlermeldung auftauchte, die auf das Fehlern irgendeiner Datei hinwies. Bei genauerer Recherche stellte ich fest, dass es sich um ein Problem mit der Zahl der offenen Dateien handelt. Mysqldump versucht anscheinen alle Tabellen parallel zu öffnen und diese Datenbank besitzt sehr viele Tabellen.

Eine Einfache Lösung besteht darin statt (hier als root):

mysqldump datenbank -p > /tmp/datenbank.sql

zu schreiben:

mysqldump datenbank --single-transaction -p > /tmp/datenbank.sql

Damit funktioniert der Dump dann auch. Siehe dazu auch http://rackerhacker.com/2007/08/19/mysql-errcode-24-when-using-lock-tables/

Nachdem Ghostery nun in meinem Firefox alle kommerziellen Webwanzen blockt habe ich begonnen selber mit Webwanzen zu experimentieren. Dafür gibt es das Programm Piwik, das man auf einem eigenen Server installieren und dann in die eigenen Seiten einbinden kann. Damit bekommt man ausführliche Hinweise über die Nutzung der Seiten, ohne Daten aus der Hand zu geben. Alles läuft auf eigenen Rechnern.

In die Webseiten, die ausgewertet werden sollen, muss man nur folgenden Code integrieren (und natürlich anpassen):

<!-- Piwik -->
 <script type="text/javascript">
 var pkBaseURL = (("https:" == document.location.protocol) ? "https://mein-server.de/piwik/" : "http://mein-server.de/piwik/");
 document.write(unescape("%3Cscript src='" + pkBaseURL + "piwik.js' type='text/javascript'%3E%3C/script%3E"));
 </script><script type="text/javascript">
 try {
 var piwikTracker = Piwik.getTracker(pkBaseURL + "piwik.php", 2);
 piwikTracker.trackPageView();
 piwikTracker.enableLinkTracking();
 } catch( err ) {}
 </script><noscript><p><img  src="http://mein-server.de/piwik/piwik.php?idsite=2" style="border:0"  alt="" /></p></noscript>
 <!-- End Piwik Tag -->

Für die Integration in Content Management Systeme findet sich unter http://piwik.org/faq/plugins/ eine Reihe von Plugins. Leider ist deren Nutzung nicht immer unproblematisch.

Für die Mediawiki-Integration findet sich unter http://www.mediawiki.org/wiki/Extension:Piwik_Integration eine passende Software. Man muss nur beim Download aufpassen. Hier wird man nach der benutzten Mediawiki-Version gefragt. Wählt man hier z.B. wahrheitsgemäß 1.15.x so bekommt man eine alte, bei mir nicht funktionsfähige Version. Man sollte hier als Mediawiki-Version unbedingt Development version (trunk) auswählen. Dann lädt man momentan die funktionsfähige Version Piwik-trunk-r72455.tar.gz .

Auch bei WordPress ist die Integration nicht unbedingt problemlos. Das Plugin Piwik Analytics ist über die Plugin-Verwaltung zu installieren und vermutlich auch funktionsfähig. Ich benutze aber momentan ein Template, bei dem in der Footer-Datei der Aufruf von wp_footer() fehlt. In diese Funktion klingt sich das Plugin wohl ein. Da in der footer.php zu meinem Template nur HTML-Code steht habe ich den Piwik-Code hier direkt eingebunden, damit funktioniert Piwik auch hier, zumindest solange ich das Template nicht wechsle.

Für Typo3 gibt es unter http://typo3.org/extensions/repository/view/piwik/current/ ebenfalls eine passend Extension. Diese muss ich noch ausprobieren. Bisher habe ich den Piwik-Code einfach mit in das Root-Template aufgenommen:

page.headerData.199 = TEXT
page.headerData.199.value (
 <!-- Piwik -->
 <script type="text/javascript">
 var pkBaseURL = (("https:" == document.location.protocol) ? "https://mein-server.de/piwik/" : "http://mein-server.de/piwik/");
 document.write(unescape("%3Cscript src='" + pkBaseURL + "piwik.js' type='text/javascript'%3E%3C/script%3E"));
 </script><script type="text/javascript">
 try {
 var piwikTracker = Piwik.getTracker(pkBaseURL + "piwik.php", 1);
 piwikTracker.trackPageView();
 piwikTracker.enableLinkTracking();
 } catch( err ) {}
 </script><noscript><p><img src="http://mein-server.de/piwik/piwik.php?idsite=1" style="border:0" alt="" /></p></noscript>
 <!-- End Piwik Tag -->
)

Damit erscheint der Code im Header-Bereich der Seite und nicht wie in der Anleitung beschrieben am Ende des Body-Bereiches, aber auch das funktioniert bisher.

Inzwischen habe ich auch die Extension piwiki aus dem Typo3-Repository ausprobiert und zwar in der Version 2.0.0. Die Extension muss nur installiert und aktiviert werden, dann folgen noch vier Zeilen im Root-Template:

config.tx_piwik {
  piwik_idsite = 1
  piwik_host   = http://mein-server.de/piwik/
}

Entgegen der Beschreibung muss hier wirklich http:// mit angegeben werden, sonst entstehen relative Verweise. Bevor man die Installation testen kann, muss man sich unbedingt vom Backend abmelden. Solange man im Backend angemeldet ist erfolgt nämlich keine Integration des Piwik-Codes.

Weitere Informationen zur Integration von Piwik in Typo3 finden sich bei Mittwald.

Heute hatte ich etwas Stress mit meinem Ubuntu-9.10 System.  Der Rechner wollte nicht booten und lieferte nach dem Boot-Menü die Fehlermeldung

Gave up waiting for root device. Common problems
- Boot args (cat /proc/cmd/line)
  - Check rootdelay= (did the system wait long enough?)
  - Check root= (did the system wait the right device?)
- Missing modules (cat /proc/modules;ls /dev)
Alert! /dev/disk/by-uuid/xxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx does not exist

Da sowohl bei Grub2, als auch in der fstab alle Partitionen per UUID angesprochen wurden ein ernsthaftes Problem. Als ich ein Testsystem von Ubuntu 10.04 gestartet habe war die Partition auch per UUID erreichbar und keine Fehler auf der Festplatte erkennbar.

Ich habe den Rechner dann mit einer Grub-Shell erfolgreich starten können mittels:

set root=(hd0,6)
linux  /vmlinuz  root=/dev/sda6
initrd  /initrd.img
boot

Das System startete auf diese Art. Es war dann aber wirklich die Partition sda6 nicht per UUID erreichbar.  In /dev/disk/by-uuid fehlte der Link auf die Partition und

blkid

lieferte Informationen über alle Partitionen außer sda6. Mittels

blkid -p /dev/sda6

kann man Informationen erzwingen, aber hier kam nur ein Hinweis auf verschiedene Partitionstypen.

ambivalent result (probably more filesystems on the device)

Es scheint sich hierbei um ein unglückliches Zusammenspiel mehrerer normalerweise unauffälliger Fehler zu handeln, zumindest unter 10.04 tritt das Problem so nicht auf. Eine Beschreibung habe ich dann unter http://www.mail-archive.com/ubuntu-bugs@lists.ubuntu.com/msg2057379.html gefunden.

Minix uses the "magic number" 137f, 138f, 2468,2478,  at  the location 0x410   to mark a Minix file system.
- 0x410 is also the location any ext filesystem uses to record the number of free inodes.
- (The number of free inodes is essentially the number of files you are still able to create on the file system)
+ 0x410 is also the location any ext filesystem uses to record the number
+ of free inodes.

  In  decimals  those four umbers are  4991,5007,9320,9336

  If the number of free inodes happens to  be one of those four numbers plus a multiple of 65536,
  then  the  ext filesystem will write  one of the four  Minix magic numbers  to the 0x410 location.

Bei einer unglücklichen Zahl von freien Inodes in der Partition lässt sich blkid irritieren und die Informationen z.B. über die ID werden nicht richtig gelesen.

Die Lösung ist im Prinzip einfach. Man muss nur einen einzigen zusätzlichen Inode belegen oder freigeben. Mein System hätte ich also nur rebooten müssen, ich hatte es ja zum Laufen gebracht und damit die Zahl der Inodes verändert.

Da unklar ist, wann dieses Problem mal wieder auftritt habe ich lieber von UUID auf Devices umgestellt. Dazu muss man einerseits die /etc/fstab umstellen, die notwendigen Informationen finden sich dort aber als Kommentare. Dann muss man die Grub2-Konfiguration umstellen.

Am Ende der Datei /etc/default/grub muss man ein Kommentarzeichen entfernen, damit GRUB_DISABLE_LINUX_UUID=true aktiv wird

# Uncomment if you don't want GRUB to pass "root=UUID=xxx" parameter to Linux
GRUB_DISABLE_LINUX_UUID=true

# Uncomment to disable generation of recovery mode menu entrys
#GRUB_DISABLE_LINUX_RECOVERY="true"

Nun noch die Konfiguration neu erzeugen lassen mittels:

update-grub

und dann steht einem Reboot nichts mehr im Wege. Das Ändern der /etc/default/grub ist nicht mal unbedingt notwendig, da update-grub die Partition perr UUID nicht findet und dann von sich aus mit den Device-Bezeichnungen arbeitet.

Bei der Recherche zu diesem Problem habe ich zusätzlich gelernt, dass die UUID per tune2fs und per mkfs gesetzt werden kann.

Bei der Entwicklung von Webseiten muss man gelegentlich das Browserfenster exakt auf eine bestimmte Größe einstellen. Dabei hilft das Programm xdotool (ggf. Nachinstallieren). Die Nutzung erfolgt von der Textkonsole aus. Will man das Firefox-Fenster auf exakt 1024×768 Punkte einstellen so muss man zuerst an seine Nummer herankommen. Dies geschieht mittel:

xdotool search --onlyvisible --title "Mozilla Firefox"

Als Rückgabe erhält man eine oder ggf. mehrer Nummern von passenden Fenstern, z.B. 71802061 Mit dieser Nummer kann man das Fenster dann manipulieren:

xdotool windowsize 71802061 1023 768

nimmt die entsprechende Einstellung vor.  Das Fenster darf aber nicht im Vollbild sein, sondern muss schon etwas verkleinert sein.

Mit dem Programm xdotool kann man auch Eingaben in Fenster machen.

Sollte es mühsam sein die Fensternummer über den Titel zu ermitteln, so kann man auch das Programm xwinfo benutzen. Das fordert einen auf das gewünschte Fenster anzuklicken und gibt dann eine Reihen von Informationen aus, unter Window-Id die Nummer. Die Nummer ist hier hier hexadezimal angegeben, aber auch damit kann xdotool umgehen.