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.

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.

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.

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.

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/

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.

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.

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.

Beim aktuellen OpenSuSe wird majordomo immer noch mit ausgeliefert. Daher war die Idee naheliegend das RPM-Paket mittels alien in ein Debian-Paket zu verwandeln und dann zu installieren. Leider war das nicht ganz so einfach. Das Ubuntu-Alien kommt teilweise mit aktuellen RPM-Paketen nicht zurecht, da die Art der Komprimierung verändert wurde. Das Problem scheint aber schon älter zu sein, es hat sich anscheinend aber noch niemand ernsthaft darum gekümmert. Es gibt Fehlermeldungen der Art:

Unpacking of 'majordomo-1.94.5-457.1.i586.rpm' failed at /usr/share/perl5/Alien/Package/Rpm.pm line 155.

In dem Artikel http://forum.ubuntuusers.de/topic/kivio-2-0-installieren/#post-2054853 habe ich dann eine Lösung gefunden. Dort ist ein kleiner Patch zu finden, der das Problem in der Zeile 155 angeht.

sub unpack {
	my $this=shift;
	$this->SUPER::unpack(@_);
	my $workdir=$this->unpacked_tree;
	my $rpmunpack="rpm2cpio ".$this->filename." | lzma -d | ";

	$this->do($rpmunpack."(cd $workdir; cpio --extract --make-directories --no-absolute-filenames --preserve-modification-time) 2>&1")
	      or (($rpmunpack="rpm2cpio ".$this->filename." | ")
	      and $this->do($rpmunpack."(cd $workdir; cpio --extract --make-directories --no-absolute-filenames --preserve-modification-time) 2>&1"))
	      or die "Unpacking of '".$this->filename."' failed";

	# cpio does not necessarily store all parent directories in an
	# archive, and so some directories, if it has to make them and has
	# no permission info, will come out with some random permissions.
	# Find those directories and make them mode 755, which is more
	# reasonable.
	my %seenfiles;
	open (RPMLIST, $rpmunpack."cpio -it --quiet |")
		or die "File list of '".$this->filename."' failed";

Ich habe einfach die entsprechenden vorhandenen Zeilen auskommentiert und diese Zeilen hineinkopiert. Nach der Änderung konnte ich mein Majordomo-Paket erfolgreich konvertieren mittels:

sudo alien --scripts majordomo-1.94.5-457.1.i586.rpm

Herzlichen Dank an den Autor hakunamatata.

Diese Dateien dienen dazu Browser automatisch zu konfigurieren, so dass sie sich die Proxy-Einstellungen selbständig erfragen können. Grundlage dafür ist eine Konfigurationsdatei namens wpad.dat, die im einfachsten Fall folgenden Inhalt besitzt:

function FindProxyForURL(url, host)
{
  if(isPlainHostName(host) || localHostOrDomainIs(host, "localhost") ||  localHostOrDomainIs(host, "127.0.0.1") || isInNet(host, "192.168.1.1", "255.255.0.0")) {
     return "DIRECT";
  }else {
     return "PROXY 192.168.1.1:3128";
  }
}

Im Prinzip wird hier in der letzten Zeile die Adresse und der Port des Proxy-Server übergeben. Der Teil davor umgeht den Proxy-Server, wenn ein Rechnername ohne Domain aufgerufen wird, der Name oder die IP für localhost oder ein Rechner aus dem lokalen Netz.

Detaillierte Informationen findet man unter http://findproxyforurl.com und natürlich http://de.wikipedia.org/wiki/WPAD.

Diese Datei muss nun nur noch zum Browser kommen. Dazu muss der Browser passend eingestellt sein: Bearbeiten -> Einstellungen -> Erweitert -> Netzwerk -> Verbindung -> Einstellungen -> Die Proxy-Einstellungen für dieses Netzwerk automatisch erkennen

Nun muss auf dem Server noch der Webserver-Apache entsprechend konfiguriert werden. Er sollte im Idealfall auf folgende URL hin die Datei ausliefern: http://wpad.<rechnername.lokale-domain>/wpad.dat In den meisten Installationen langte es sicherlich im Nameserver einen cname für wpad einzurichten:

wpad       CNAME   boss

Zusätzlich wird noch empfohlen die zugehörigen Mime-Types zu registrieren. Dazu kommen folgende Zeilen in die bisher leere Datei /etc/apache2/httpd.conf:

AddType application/x-ns-proxy-autoconfig .dat
AddType application/x-ns-proxy-autoconfig .pac
Redirect permanent  /proxy.pac /wpad.dat

Hier sind zwei Dateien eingetragen, die wpad.dat und die proxy.pac, die beide identisch sind. Eine Version ist für WPAD-fähige Systeme zuständig, die andere für ältere Versionen. Durch den Redirect muss nur eine der beiden Dateien wirklich vorhanden sein. Anfragen an die andere Datei werden passend weitergeleitet.

Im Prinzip suchen die Browser nun nach einem festen System nach der Konfigurationsdatei. Man kann ihnen das Leben erleichtern und auch den cname wpad für den Webserver vermeiden, wenn man die DHCP-Server Konfiguration etwas anpasst.

# /etc/dhcpd.conf
#
# Configuration file for ISC dhcpd
#
# -- global options --
default-lease-time                 160000;
max-lease-time                     200000;
use-host-decl-names                on;
option dhcp-max-message-size       1024;
option wpad code 252 = text;
ddns-update-style                  none;
authorative;

subnet 192.168.1.0 netmask 255.255.255.0 {
    range 192.168.1.40 192.168.1.160;
    server-identifier 192.168.1.1;
    option broadcast-address 192.168.1.255;
    option routers 192.168.1.254;
    option domain-name-servers 192.168.1.1, 192.168.1.254;
    option domain-name "debacher.net";
    option wpad "http://www.debacher.net/wpad.dat ";
}

Die beiden hinzuzufügenden Zeilen sind fett unterlegt. Damit wird dem Client-Rechner schon beim Starten die Adresse der wpad.dat (Code 252) mit übermittelt. Hier ist eine beliebige URL möglich, die auch nicht unbedingt im eigenen Netz liegen muss. Die Adressübermittlung per DHCP hat übrigens Vorrang gegenüber der Übermittlung per DNS. Man muss also nicht unbedingt an den Nameserver heran.

Weitere Informationen:

• http://www.mynakedgirlfriend.de/wpad-web-proxy-autodiscovery-protocol/
• http://www.kai-hildebrandt.de/tutorials/wpad.html
• http://homepage.ntlworld.com./jonathan.deboynepollard/FGA/web-browser-auto-proxy-configuration.html
• http://rolfrost.de/proxypac.html