Konfiguration von ISCSI Targets unter Linux mit targetcli

Ein paar Videos zur Konfiguration von ISCSI Targets unter Linux mit targetcli
Part 1: http://www.youtube.com/watch?v=BkBGTBadOO8
Part 2: http://www.youtube.com/watch?v=mKjBsgOlYmE
Part 3: http://www.youtube.com/watch?v=f6cgZotqUj0
 
Quellen:
http://de.wikipedia.org/wiki/ISCSI
http://de.wikipedia.org/wiki/LIO
http://linux-iscsi.org/wiki/Main_Page
https://wiki.archlinux.org/index.php/ISCSI_Target
https://wiki.archlinux.org/index.php/ISCSI_Boot
https://wiki.archlinux.org/index.php/Persistent_block_device_naming
 

Umleitung des Netzwerkverkehrs auf eine neue IP Adresse mit IPtables

Bei der Migration bzw. Umzug von Diensten z.B. HTTP von einer alten Maschine auf eine neue Maschine kann eine zeitlich eingerichtete Umleitung sehr nützlich sein.
Gründe für eine Umleitung sind z.B.:

  • Benutzer verwenden die IP-Adresse anstatt des Domainnames
  • Andere Dienste oder Rechner verwenden die IP-Adresse anstatt des Domainnames
  • Die Umstellung des DNS-Namens auf eine andere IP-Adresse dauert länger bis alle DNS-Caches aktualisiert sind.

Wir gehen beim System davon aus, daß iptables noch nicht verwendet wird und insbesondere kein NAT eingerichtet ist.
Für die Umleitung benutzen wir die PREROUTING und POSTROUTING Chain benutzt und benutzen IPtables mit dem Masquerade Feature.
Forwarding aktivieren:

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

 
Allen Netzwerkverkehr auf neue IP Adresse umleiten:

iptables -t nat -A PREROUTING -p tcp –dport 80 -j DNAT –to-destination x.x.x.x:80

 
Masquerade mit IPtables:

iptables -t nat -A POSTROUTING -j MASQUERADE

 
Optional kann man auch die Regel auf ein definiertes Quellnetzwerk bzw. -IP Adresse einschränken

iptables -t nat -A PREROUTING -s 192.168.1.1 -p tcp –dport 80 -j DNAT –to-destination x.x.x.x:80

oder:

iptables -t nat -A PREROUTING -s 192.168.1.0/24 -p tcp –dport 80 -j DNAT –to-destination x.x.x.x:80

Der Netzwerkverkehr wird nun von Port 80 (HTTP Port) auf die IP-Adresse x.x.x.x umgeleitet.
Auf dem Host x.x.x.x kann man mit tcpdump die Pakete vom Host, auf dem die Umleitung eingerichtet ist, beobachten.

OpenVPN Version 2.3 auf Debian Wheezy installieren

Wieso das frühe Upgrade auf OpenVPN 2.3?
Die Releasenotes beantworten eigentlich schon die Frage, hier nur ein kurzer Auszug davon:

  • komplette IPv6 Unterstützung für transport und payload
  • one-to-one NAT um Konflikte mit IP Adressen in lokalen und entfernten Netzen zu verhindern
  • Optinaler PolarSSL Support
Weiterführende Informationen findet Ihr in den Releasenotes.

 
OpenVPN in der Version 2.3 hat es bisher noch nicht in die offiziellen Repositories von Debian geschafft.
Laut der Homepage von OpenVPN ist die Version noch nicht getestet mit Debian 7 (wheezy).
Habe es trotzdem versucht und war positiv überrascht, wie reibungslos und schnell das Upgrade von OpenVPN 2.2 auf 2.3 funktioniert hat.
Notwendige Pakete für OpenVPN 2.3 nach installieren:

apt-get install openssl-blacklist openvpn-blacklist

Installation OpenVPN 2.3

cd /root
http://repos.openvpn.net/repos/apt/squeeze-snapshots/openvpn_2.3-alpha1-debian0_amd64.deb
dpkg -i openvpn_2.3-alpha1-debian0_amd64.deb

Version prüfen:

openvpn –version
OpenVPN 2.3-alpha1 x86_64-linux-gnu [SSL (OpenSSL)] [LZO2] [EPOLL] [PKCS11] [eurephia] [MH] [PF_INET6] [IPv6 payload 20110522-1 (2.2.0)] built on Feb 21 2012
Originally developed by James Yonan
Copyright (C) 2002-2010 OpenVPN Technologies, Inc. <sales@openvpn.net>
$ ./configure –enable-pthread –enable-password-save –host=x86_64-linux-gnu –build=x86_64-linux-gnu –prefix=/usr –mandir=${prefix}/share/man –with-ifconfig-path=/sbin/ifconfig –with-route-path=/sbin/route CFLAGS=-g -O2 build_alias=x86_64-linux-gnu host_alias=x86_64-linux-gnu LDFLAGS= CPPFLAGS= –no-create –no-recursion
Compile time defines: ENABLE_CLIENT_SERVER ENABLE_DEBUG ENABLE_EUREPHIA ENABLE_FRAGMENT ENABLE_HTTP_PROXY ENABLE_MANAGEMENT ENABLE_MULTIHOME ENABLE_PASSWORD_SAVE ENABLE_PORT_SHARE ENABLE_SOCKS USE_CRYPTO USE_LIBDL USE_LZO USE_OPENSSL USE_PKCS11 USE_SSL

 
 
 
 
Quellen:
http://repos.openvpn.net/repos/apt/squeeze-snapshots/
https://community.openvpn.net/openvpn/wiki/OpenvpnSoftwareRepos
http://openvpn.net/index.php/manuals/523-openvpn-23.html
http://openvpn.net/index.php/open-source/downloads.html
https://community.openvpn.net/openvpn/wiki/ChangesInOpenvpn23

files list file for package 'mysql-common' is missing final newline

files list file for package ‚mysql-common‘ is missing final newline
Problem:
Aus irgendeinem Grund ist die Datei:
/var/lib/dpkg/info/mysql-common.list
in einem inkonsistenten Zustand geraten.
Lösung:
Die Datei löschen und durch apt erstellen lassen
rm /var/lib/dpkg/info/mysql-common.list
apt-get update
apt-get upgrade

OCR- Texterkennung von PDF zu Text

Die Entscheidung fiel auf Tesseract, da es die besten OCR-Ergebnisse liefert und von Google langfristig weiterentwickelt wurde.
OCR-Software

apt-get install tesseract-ocr tesseract-ocr-deu

PDF zu Text mit GhostScript

apt-get install ghostscript

Aus einem PDF ein TIFF Bild zu erzeugen
gs -sDEVICE=tiff24nc -r400x400 -sOutputFile=output.tif — test.pdf
Mit der Option -sDEVICE=tiff24nc erzeugt man ein sehr hochwertiges TIFF aus dem PDF. z.B. wurden aus einem 15MB PDF eine 320MG großes TIFF-Datei.
Die OCR Texterkennung in Deutsch durchführen
tesseract output.tif text.txt -l deu
Quellen:
http://de.wikipedia.org/wiki/Tesseract_(Software)
 
 
 
 

php5-memcache vs php5-memcached Debian Paket

Ich bin bei der Geschwindigkeitsoptimierung meines Apache2 auf die Idee gekommen, die Sessions mit Memcached in Hauptspeicher zu halten. Dadurch sollte sich die Antwortzeiten des Apache2 deutlich verbessern lassen.
Dabei bin ich auf zwei Debian Pakete gestoßen php5-memcache und php5-memcached.
Als erstes fragte ich mich was ist den wirklich der Unteschied zwischen beiden. Außer dass php5-memcached deutlich schneller ist als php-5-memcache.
php5-memcache ist ein in PHP geschriebenes Paket zur Nutzung von des Memcache Deamon.
php5-memcached ist ein Wrapper für die Bibliothek libmemcached2.
Fazit:
Habe beide ausprobiert empfehle php5-memcached.

Zentralen Log-Server (Rsyslogd) unter Debian einrichten

Zentraler Log-Server mit Rsyslogd

LOG-Server

Die Konfiguration des zentralen Log-Servers (Version 4) ist einfach :
Eine Konfigurationsdatei unter /etc/rsyslog.d/ anlegen und folgende Zeilen einfügen:
z.B.:

vim /etc/rsyslog.d/remote_logging_server.conf

TCP:

# provides TCP syslog reception
$ModLoad imtcp
$InputTCPServerRun 514

Oder UDP:

# provides UDP syslog reception
$ModLoad imudp
$InputUDPServerRun 514

TCP ist zu bevorzugen. Nach dem Neustart des Daemons wartet dieser auf eingehende TCP-Pakete mit Log-Einträge auf dem Default-Port 514.
Test ober der Service erfolgreich gestartet wurde mit:

netstat -lntp | grep 514

Es sollte folgende Ausgabe erscheinen:

tcp        0      0 0.0.0.0:514             0.0.0.0:*               LISTEN      24369/rsyslogd
tcp6       0      0 :::514                  :::*                    LISTEN      24369/rsyslogd

Weiterführende Konfiguration:
Dokumentation
Beispielscript zur Sortierung der Log-Dateien nach den einzelnen Domains steht hier zu download
Weiter Beispielscripte

LOG-Client

Die Konfigurationsdatei (/etc/rsyslog.conf oder /etc/syslog.conf) auf dem Client muss folgendermaßen angepasst werden.
TCP:

*.* @@<ip-adresse-log-server>

Oder UDP:

*.* @<ip-adresse-log-server>

Nach dem Neustart des Log-Daemons sollten die Einstellungen greifen.

TEST

Test ober der Client erfolgreich konfiguriert wurde:
Auf dem Client:

netstat -tap | grep syslog

Ausgabe:
tcp        0      0 <client>:50441 <server>:shell        ESTABLISHED 28698/rsyslogd

Auf dem Server:

netstat -tap | grep syslog

Ausgabe:

tcp        0      0 <server>:shell    <client>:50441         ESTABLISHED 24369/rsyslogd

Anmerkung:
Einer meiner Server ist natürlich ein Mailserver. Ohne die Konfiguration anzupassen werden viele Events defaultmäßig in /var/log/syslog geschrieben. Damit das nicht mehr der Fall ist müssen wir den Rsyslogd-Server anpassen.
vim /etc/rsyslog.conf

*.*;auth,authpriv.none               -/var/log/syslog

folgendermaßen ergänzen:

*.*;auth,authpriv.none;mail.none                -/var/log/syslog

Anschließend den Rsyslog neustarten. Damit werden keine Mail-Log-Events mehr in /var/log/syslog geschrieben.
Vergleich zwischen RSyslog und Syslog-NG findet Ihr hier.

WordPress – You are not allowed to call this page directly.

Das aktivierte WordPress Plugin NextGEN ImageFlow hat mir nicht mehr erlaubt unter Einstellungen das Autoupdate auszuführen bzw.  die update-core Seite aufzurufen.
Fehlermeldung:
You are not allowed to call this page directly.
Lösung:
NextGEN ImageFlow deaktivieren und die Funktionen stehen wieder zur Verfügung.