Bei einem Serverwechsel taucht immer wieder das Problem auf, dass man auch vorhandene Mailman-Listen umziehen möchte. Der Vorgang ist eigentlich ganz einfach. Die Beschreibung geht davon aus, dass Mailman auf dem Zielrechner bereits eingerichtet und funktionsfähig ist.

Im ersten Schritt müssen die Listen-Verzeichnisse aus den Ordnern

/var/lib/mailman/archives/private/
/var/lib/mailman/lists/

kopieren. Für jede Liste gibt es in den Ordnern ein gleichnamiges Verzeichnis und in dem Archivordner noch jeweils eines mit der Extension .mbox. Diese Verzeichnisse werden einfach auf den neuen Server kopiert und dem richtigen Eigentümer übereignet. Unter Ubuntu gehören die Dateien in der Regel lists.list und die übergeordneten Verzeichnisse root.list.

Die Eigentümer müssen jeweils noch richtig gesetzt werden.

Dann geht es noch an zwei Dateien im Verzeichnis data:

aliases
virtal-mailman

Hier finden sich für jede Liste mehrere Zeilen mit den Weiterleitungen. Die benötigten Zeilen holt man sich vom alten Server und hängt sie an die Dateien auf dem neuen Server an. Am Ende müssen die entstandenen Dateien noch in das benutzte Datenbank-Format umgewandelt werden:

/usr/lib/mailman/bin/genaliases

oder man wartet bis mailman das selber macht.

Danach kann man dann vorsichtshalber mailman neu starten.

Falls es Probleme mit der URL für die Liste gibt, so ist wichtig zu wissen, dass die Listenkonfiguration in der Datei:

/var/lib/mailman/lists/<listenname>/config.pck

steckt. Diese Datei kann man z.B. mittels

withlist -l -r fix_url <listname> -u mailman.yyy.com

bearbeiten.

 

Weitere Hinweise unter:

Bei den neuen Ubuntu-Versionen ist anscheinend kein Oracle-Java mehr dabei. Das ist nicht weiter schlimm, da das Oracle-Java nicht wirklich installiert werden muss, es langt, wenn man die Archive an einem geeigneten Ort entpackt.

Es mach aber Sinn diese Version in die alternatives Verwaltung einzubinden.

Hat man also das Oracle-Java im Pfad /opt/oracle/jre entpackt, dann muss man es noch in das System einbinden mittels:

sudo update-alternatives --install "/usr/bin/java" "java" "/opt/oracle/jre/bin/java" 1
sudo update-alternatives --install "/usr/bin/javaws" "javaws" "/opt/oracle/jre/bin/javaws" 1

Aktivieren kann man es nun mittels:

sudo update-alternatives --set "java" "/opt/oracle/jre/bin/java"
sudo update-alternatives --set "javaws" "/opt/oracle/jre/bin/javaws"

oder über

sudo update-alternatives --config java

Hier kann man dann die gewünschte Version auswählen.

Weitere Hinweise unter:

  • https://wiki.ubuntuusers.de/Java/Installation/Oracle_Java/Java_8/
  • https://wiki.ubuntuusers.de/Java/Oracle_Java/

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.

Das aktuelle Heft (1/2014) der Zeitschrift c’t hat sich mal wieder gelohnt. Auf Seite 59 findet sich ein kleine Beitrag über die Software OCRMyPDF. Damit ist man in der  Lage einfache PDF-Dokumente mit einer Textebene per OCR zu versehen.

Die Software selber gibt es unter https://github.com/fritz-hh/OCRmyPDF zum Download. Ich musste noch das Pakt tesseract nachinstallieren, welches die eigentlich OCR-Arbeit übernimmt.

Das Tool, eine Sammlung von Scripten für sowieso vorhandene Programmpakete, muss nicht weiter installiert werden. Direkt nach dem Entpacken ist es per

 sh OCRmyPDF.sh -l deu quelle.pdf ziel.pdf

ausführbar.

Beim Aktualisieren von moneyplex 09 auf moneyplex 12 unter Ubuntu 12.04 hatte ich das Problem, dass die neue Software-Version nicht auf das Internet zugreifen konnte. Damit waren weder Software-Updates noch Konto-Aktualisierungen möglich.

Nach einem hilfreichen Hinweis vom Matrica-Support habe ich dann das Problem in der resolf.conf gefunden.

Mein Arbeitsplatzrechner hat eine feste IP-Adresse (er vergibt auch die IP-Adressen im Netz). Außerdem läuft auf dem Rechner auch der Nameserver für das Netz. Bisher hat das allen Programmen gelangt. Die 12 moneyplex fragt nun wohl irgendwo die resolv.conf ab, was die Version 09 anscheinend nicht machte. Das erklärt auch, warum moneyplex 12 auf anderen Rechnern im Netz problemlos lief, nur auf meinem Hauptrechner nicht. Die anderen Rechner haben ihre Daten per DHCP  bezogen und dabei wird automatisch die resolv.conf aktualisiert.

Ich habe auf meinem Hauptrechner jetzt also die Datei /etc/network/interfaces etwas erweitert:

 auto lo 
 iface lo inet loopback 
 auto eth0 iface eth0 inet static 
 address 192.168.1.1 
 netmask 255.255.255.0 
 gateway 192.168.1.254
 dns-domain debacher.local
 dns-search  debacher.local
 dns-nameservers 192.168.1.1 192.168.1.254

Die ersten 7 Zeilen waren schon vorhanden, ich habe jetzt die drei letzten Zeilen ergänzt. Nach einem /etc/networking/restart wurden die Informationen dann in die /etc/resolv.conf bzw. genaugenommen /run/resolvconf/resolv.conf übernommen.

Schön, dass es Firmen gibt, die sich darum bemühen ihren Kunden bei Problemen zu helfen.

Nach längerer Vorbereitungszeit habe ich jetzt mein Evolution von POP3 auf IMAP-Nutzung umgestellt. Die Umstellung war eigentlich ganz einfach, ich habe einfach unter Einstellungen für mein Standard-Postfach unter Abrufen von E-Mails statt POP in der Drop-Down-Liste IMAP ausgewählt. Seitdem gibt es nun zwei Gruppen von Ordnern, einerseits die POP-Ordner unter Auf diesem Rechner und die neuen IMAP-Ordner unter Uwe@meine-maildomain.de. Nun kann ich meine Mails aus den alten Ordnern einfach in die neuen Ordner kopieren, wodurch mir auch meine alten Mails jetzt unter IMAP zur Verfügung stehen. Das dauert zwar etwas, ich habe auch etwa 4GB alte Mails, aber einfacher kann es kaum sein.

Womit ich etwas Probleme hatte sind die Mail-Filter. Ich habe die alle so verändert, dass sie die neu erstellten Ordner als Ziel nutzen, das hat aber nicht automatisch funktioniert. Ich musste erst unter den Einstellungen des IMAP Kontos auf Empfangsoptionen klicken und dort ein Häkchen setzen bei: „Filter auf neue Nachrichten in INBOX dieses Servers anwenden“.

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.