Seit einigen Tagen habe ich auch GNOME 3.0 auf meinem Produktiv System. Das ganze System läuft auch sehr gut damit, mir sind nur 4 Punkte aufgefallen die aktuell wirklich nervig sind:

• Rhythmbox geht beim klicken auf die Fenster schließen Schaltfläche komplett zu, ich habe mir damit bestimmt schon 50 mal die Musik ausgemacht! Leider konnte ich hierzu noch keine Einstellung finden, ein richtiges Tray gibts ja für GNOME 3.0 nicht mehr :-/
• Im Gegensatz zu GNOME Do ist die Shell nicht so clever und startet einen eingegeben Befehl direkt wie man ihn eingibt, stattdessen geht Wikipedia auf. ALT-F2 ist ein Shortcut den ich schon 2 Jahre nicht mehr verwenden musste :-/
• Gajim Integration, hier gibt es noch einiges an Arbeit zu tun. Zwar gibt es eine Integration über Extensions für die Shell, schöner wäre aber nativer Support von gajim für GNOME 3.0.
• Empathy kann nach wie vor weder GPG, OTR noch E2E. Das ist einer der Hauptgründe warum ich es nicht verwenden kann.

Ich denke aber auch das dies Dinge sind, die vielleicht schon mit 3.2 gefixt oder geändert werden. Bei Gajim müssen natürlich die Entwickler selbst aktiv werden!

Seit heute ist ja GNOME 3.0.1 offiziell in den normalen Paketquellen von Arch angekommen, natürlich habe ich auch mein Produktivsystem auf die neue Version aktualisiert.

Das ganze hat auch prima funktioniert, aber nach dem 2. Boot ging auf einmal nichts mehr und nur noch das Hintergrund Bild war sichtbar beim Anmelden über den GDM. Wie sich heraus gestellt hat schlampt das neue GNOME noch bei der Session Verwaltung etwas, daher ist es ratsam den Haken "Automatisch die laufenden Programme beim Abmelden merken" in den gnome-session-properties abzuschalten. Zusätzlich kann man nach dem Logout noch die Dateien unterhalb von ~.config/gnome-session/saved-sessions/ löschen.

So wie ich das sehe hat die GNOME Shell sich wohl selbst in die Session gepackt, und wollte sich dann nach dem Start gleich nochmal starten und dann ging natürlich garnichts mehr. So weit meine Theorie, vielleicht hilft euch die Lösung ja auch falls ihr dieses Problem mal haben solltet.

Man liest es ja überall: GNOME 3.0 wurde veröffentlicht.

Ich selbst habe es natürlich auch mal getestet, aber natürlich beachtet das es ein .0 Release ist was halt einfach noch nicht so 100%ig stabil sein kann. Installiert habe ich es aus dem testing Repository unter Arch Linux, was man nur tun sollte wenn man mit dem System rumspielen will. Auf einem Produktivsystem würde ich erst mal bei 2.* bleiben bis es die ersten Bugfix Releases von 3.0 gibt. Für andere Distributionen gibt es Fremdquellen (z.B. PPAs bei Ubuntu) oder die Möglichkeit jhbuild zu verwenden.

Was mir beim ersten Start vom neuen GNOME aufgefallen ist: Es ist sehr aufgeräumt und nur mit dem nötigsten versehen. Das finde ich generell eigentlich schön da ich mit viel Schnickschnack kaum was anfangen kann, aber im Control Center hat man das doch deutlich übertrieben. Es gibt eigentlich nichts mehr das man wirklich Einstellen kann, auch das extra Tool gnome-tweak-tool erlaubt einem nur eine Hand voll mehr Einstellungen.

Der neue Workflow von GNOME gefällt mir aber sehr gut, man hat sich schnell dran gewöhnt und kann zu einem Teil auf Tools wie z.B. gnome-do verzichten, hier und da gibt es noch ein paar Sachen die nicht so funktionieren wie es die Entwickler erwarten, aber im großen und ganzen macht es einen brauchbaren Eindruck. Vor einem halben Jahr noch hatte ich zu diesem Thema ja die Befürchtung das 3.0 ein Schuss in den Ofen wird, da hatte ich aber unrecht.

Meine Freundin hat 3.0 auch probiert, und ist damit auch zufrieden. Hauptkritikpunkt einer Frau ist aber das man nicht mal das Thema umstellen kann ohne das man irgendwelche Extensions braucht. Was Anpassbarkeit angeht muss GNOME also doch wieder etwas nacharbeiten, und auch der Verzicht auf den beliebten "Ausschalten"-Button ist mir unerklärlich.

Sehr praktisch finde ich das dynamische Anlegen von neuen Desktops, das ist was wo ich bei 2.* vermisse, meistens reichen mir 2-3 virtuelle Desktops, aber manchmal darf es auch gerne etwas mehr sein. Ebenfalls schön gemacht ist die automatische Gruppierung von Anwendungen und eine Leiste wo man seine Lieblingsprogramme anpinnen kann.

Das waren meine Eindrücke vom neuen GNOME, mal sehen was die nächsten Releases bringen, Potential hat die neue Version nämlich!

Update:Mir ist klar das man an die Funktion Ausschalten noch kommt wenn man im Usermenu die ALT-Taste drück, das wissen aber nur die wo danach gesucht haben und nicht Leute die eher wenig mit der IT zu tun haben oder glauben das Google das Internet ist ;-)

Häufig hat man das Problem das man nicht weis wie lange den ein dd noch brauchen wird um die Platte zu spiegeln, oder wie schnell der Datentransfer via netcat überhaupt läuft. Genau hierfür wurde das kleine Tool pv geschrieben welches den Datendurchsatz von pipes messen kann.

Ich selbst muss leider gestehen das ich dieses prima Tool bis letzten Sonntag noch nicht mal kannte und eher zufällig von guten bekannten davon erfahren habe.

pv ist bei Ubuntu im universe, bei Debian im main und bei Arch im community Repository zu finden. Es benötigt nur wenige KByte auf der Festplatte und ist daher auf jedem System verwendbar.

Ich werde hier nicht die Manpage 1:1 runterleiern und nur die 2 häufigsten Verwendungsarten anschneiden, welche man im täglichen Alltag verwenden dürfte.

Das eine ist ein Ersatz für das gute alte cat welches wohl jeder Leser dieses Blog kennen dürfte:

pv dateiname | nc -w 1 serveradresse portnummer

Hier erkennt pv selbständig wie groß dateiname eigentlich ist und baut einen schönen Ladebalken damit der anzeigt wie lange der Transfer bzw. die Verarbeitung noch dauert. Bei Special Files wie z.b. named Pipes oder einfach nur Device Files wird dies natürlich nicht gehen und man sieht nur einen Balken der hin und her wandert, wie man es von zahlreichen grafischen Oberflächen gewöhnt ist.

Die andere Variante hängt Inline in der Pipe und zeigt natürlich die gleichen Daten an:

cat dateiname | pv | nc -w 1 serveradresse portnummer

Nachteilig ist natürlich das man hier nicht sieht wie lange der Transfer noch dauert, was logisch ist da über die Pipes ja keine Größeninformationen ausgetauscht werden. Wenn man natürlich weis welche Datenmenge übertragen wird kann man das pv mit auf den Weg geben:

cat dateiname | pv -s 200m | nc -w 1 serveradresse portnummer

Und schon hat man wieder den schönen Ladebalken, wenn man Sachen natürlich zuvor durch ein Kompressionstool wie gzip,bzip2 oder xz jagt ist der Ladebalken natürlich bestenfalls ein Schätzeisen im Glastkugelmodus.

Es gibt noch einige zusätzliche Schalter in der Manpage von pv, doch die wird man eher selten benötigen ;-)

Gerade auf Systemen die nur wenig freien Speicherplatz auf der Festplatte haben lohnt es sich ab und an den Paketcache von pacman zu leeren. Man sollte das aber nur machen wenn gerade alles perfekt läuft, idr. verwendet man den Cache nämlich für Downgrades von kaputten bzw. nicht funktionierenden Paketen.

Das ganze steht auch in der Manpage, ist also kein wirklicher Geheimtipp: sudo pacman -Scc

Bei Android ist ja Standardmäßig kein CACert im Zertifikatsmanager als Root-CA hinterlegt.

Bei vielen Webdiensten ist ein Verzicht auf ordentliche HTTPS-Sicherheit vielleicht noch akzeptabel, spätestens bei Mails auf dem eigenen Server aber vollkommen inakzeptabel!

Man hat nun verschiedene Möglichkeiten das Problem zu lösen:

• CACert Root Certificate in den Zertifikatsmanager importieren: Umständlich
• VPN verwenden: Möglich
• IMAP über SSH mit ConnectBot tunneln: Einfach

Das Tunneln über ConnectBot geht natürlich nur wenn man Shellzugriff auf den Server hat, was bei einem eigenen Rootserver ja der Fall ist.

Man richtet sich ConnectBot ganz normal, wie jeden anderen SSH Clienten ein. Ich selbst bevorzuge ein Passwortloses Login über das integriert Public Key Verfahren welche mit einer Passphrase geschützt sind.

Im nächsten Schritt baut man den Tunnel auf, hierzu einfach auf die Verbindung im ConnectBot gehen (langer Druck mit dem Finger) und dann die Portforwardings bearbeiten, folgende benötigen wir für IMAP und SSH:

• SMTP von 1125 auf 127.0.0.1:25
• IMAP von 1143 auf 127.0.0.1:143

Sobald man jetzt eine Verbindung zu diesem Host aufbaut wird automatisch auch die Portweiterleitung aktiviert. Im Mailclient wird jetzt immer 127.0.0.1 (alternativ auch gerne localhost) als Server verwendet, der Port für IMAP ist dann die 1143 und für SMTP nimmt man 1125. Die Verbindung zum Server ist aber nicht Verschlüsselt, das übernimmt ja der gute alte ConnectBot für uns. Ob man für den Postausgangssserver (SMTP) ein Passwort benötigt kommt auf die Konfiguration des Mailservers an, oft benötigt man kein Login wenn man über SSH zugreift, da es sich dann um eine lokale Verbindung hat die meistens in der my_networks vom Postfix schon erlaubt ist.

Abgesehen davon kann man den Mailclient wie gewohnt verwenden und konfigurieren, einen Nachteil möchte ich aber nicht verschweigen: Automatische Mailchecks oder Aktionen die ausgeführt werden wenn kein ConnectBot im Hintergrund läuft funktionieren mit dieser Lösung natürlich nicht. Wird dies benötigt muss man also auf den umständlichen Weg das CACert Certificate importieren.

Schöner fände ich es wenn man Root-CAs einfacher importieren könnte, und nicht dieses umständlichen Weg gehen müsste, der noch dazu Root Rechte erfordert! Leider kann Android auch kein OpenVPN ohne Root, so macht das mit einem VPN natürlich auch keinen Spaß :-(

Nachdem Motorola ja schon bei Froyo für das Milestone geschlampt hat, haben die wenigstens die Sache mit Gingerbread richtig gemacht: Link

Momentan gibt es im Linux Kernel 4 Sicherheitserweiterungen die alle mehr oder weniger eine MAC (Mandatory Access Control) nachrüsten. Diese sind:

• SELinux
• SMACK
• TOMOYO
• AppArmor

SELinux wird schon immer von Fedora/RedHat/CentOS verwendet, das sind auch die Leute welche hinter diesem System stehen. Die Anpassung ist natürlich bei diesen Distributionen am besten. SELinux benötigt einige Anpassungen im Userspace, was mich persönlich etwas stört.

SMACK habe ich mir bisher noch garnicht angesehen, ggf. hat jemand schon damit Erfahrungen gemacht. Soweit ich weis ist es aber auch bei keiner Distribution Standard, und auch SMACK benötigt einige Anpassungen im Userspace.

TOMOYO ist seit 2.6.30 im Kernel dabei, das ganze ist eine relativ junge Sicherheitserweiterung bei der noch einige Features fehlen. Der IMHO größte Vorteil von TOMOYO ist dass man einen schönen Live Editor (tomoyo-editpolicy) hat, mit diesem kann man den Learning Mode von TOMOYO prima überprüfen und auch neue Regeln eintragen sowie alte Löschen. Die Userspace Tools von TOMOYO sind relativ klein, so dass man fast nichts nachinstallieren muss.

AppArmor ist ein etwas älterer bekannter, welcher mit Kernel 2.6.36 auch endlich Einzug in den Standardkernel erhält. Unschön an AppArmor finde ich dass die Userspace Tools etwas fett sind, dies fällt einem aber erst auf wenn man sie zum Beispiel unter Arch installiert und massig Abhängigkeiten nachinstalliert werden.

Problematisch finde ich eigentlich nur das viele Distributionen unterschiedliche Sicherheitserweiterungen installieren. Ohne einen Standard werden viele Leute sowas einfach nicht einrichten wollen, da man es für jede Distribution neu lernen darf. Ubuntu hat z.B. AppArmor, Fedora SELinux und Arch kann TOMOYO und AppArmor, openSuSE wiederum verwendet auch AppArmor, usw...

Wenn jetzt noch GRSecurity in den Kernel kommt haben wir alle Sicherheitserweiterungen die mir bekannt sind im Kernel, doch keine einzige die irgendwie ein Standard wäre. Schade eigentlich, da geht viel Potential verloren... :-/

Gerade für Serverdienste wäre das erstmal wichtiger als Unity, Themes oder Wallpapers!

Arch Linux hat ab dem Kernel 2.6.36 die Sicherheitserweiterung TOMOYO aktiviert (Feature Request), auch Debian Squeeze hat diese Sicherheitserweiterung schon aktiviert.

Ich selbst teste aktuell die ein oder andere Sicherheitserweiterung, bisher ist mir aufgefallen das TOMOYO diejenige ist welche die schlankesten Tools im Userspace benötigt. AppArmor zieht hier viele viele Abhängigkeiten nach sich was ich nicht besonders toll finde. Bei SELinux muss man sehr viel am System anpassen, dafür kann SELinux natürlich auch am meisten.

Ich plane daher für die Zukunft auf meinen Servern wenn möglich immer TOMOYO zu verwenden, natürlich werde ich auch den ein oder anderen Artikel hierüber in mein Blog schreiben.

Oft ist man gezwungen ein unverschlüsseltes Protokoll zwischen 2 Server einzusetzen. Dies ist in einem Firmennetzwerk noch vertretbar, aber über der Internet will man sowas auf gar keinen Fall machen.

Es gibt nun mehrere Möglichkeiten wie man die benötigte Verschlüsselung zwischen 2 Servern realisieren kann:

SSH

Das war früher ein sehr gängiger weg alles mit SSH zu Tunneln und dann AutoSSH & Co zu verwenden. Heute möchte man sowas eigentlich nicht mehr verwenden, es sei den es ist der einzige weg da man z.B. keine zusätzliche Software installieren darf oder man nur eingeschränkte Rechte hat.

OpenVPN

OpenVPN ist eine vor allem im OpenSource Umfeld gerne eingesetzte VPN Software. Der Vorteil von OpenVPN ist das man nur einen TCP oder UDP Port benötigt und man sich damit in der Regel fast überall "durchmogeln" kann. Der Nachteil von OpenVPN ist das jedes IP Paket fröhlich zwischen Kernel und Userspace hin und her geschoben wird, was natürlich auf die Performance geht.

IPSec

IPSec ist schon lange ein Standard wenn es um die Verschlüsselung von IP Traffic geht, der Vorteil ist das so gut wie jedes Betriebssystem irgendwie auch IPSec kann, der Nachteil ist das IPSec ein relativ komplexes Protokoll ist.

Wie der Titel dieses Beitrages schon zeigt habe ich mich für IPSec entschieden. Auf den beiden Servern läuft Arch Linux, wenn man hier und da etwas rumschraubt läuft es aber auf jeder Linux Distribution ähnlich.

Benötigte Pakete

Es muss nur das Paket ipsec-tools installiert werden, leider hat Arch noch kein Script das beim starten automatisch die Security Policy Database initialisiert. Aus diesem Grund habe ich ein Ticket aufgemacht das einen Patch für das Paket bereitstellt. Wenn man sich ipsec-tools aus dem ABS holt kann man das Paket selbst patchen, ich gehe aber davon aus das mein Patch die nächsten Tage in die normalen Repositories aufgenommen wird.

Konfiguration

Ich gehe in meiner Konfiguration davon aus das 10.0.0.1 und 10.0.0.2 die IPs der Server sind. Bei den Konfigurationsdateien muss man natürlich immer die IP Adressen vertauschen, auf beiden Servern ist die Konfiguration aber abgesehen davon identisch.

Die Security Policy Database (SPD) vom Kernel kann mit der Datei /etc/ipsec.conf konfiguriert werden. Die SPD dient dazu dem Kernel beizubringen ob er für ein bestimmtes Ziel IPSec verwenden soll, und wenn ja wie davon die Konfiguration aussieht.

#!/usr/sbin/setkey -f
flush;
spdflush;
spdadd 10.0.0.1 10.0.0.2 any -P out ipsec
        esp/transport//require;
spdadd 10.0.0.2 10.0.0.1 any -P in ipsec
        esp/transport//require;

In diesem Beispiel verwende ich zwischen beiden Servern nur eine Verschlüsselung im Transport Mode, ein vollständiger Tunnel wäre mir hier zu viel Overhead. Gleichzeitig gehen in diesem Beispiel alle IP Daten durch IPSec, d.h. auch ICMP Pakete.

Der nächste Schritt ist es racoon zu konfigurieren, racoon ist der IKE (Internet Key Exchange) Daemon welcher für IPSec nicht zwingend erforderlich ist, doch die ganze Sache ordentlich sicherer macht. Wie man IPSec ohne IKE verwendet werde ich hier nicht erklären, u.a. weil ich nicht viel von sowas halte ;-)

Racoon wird über die Datei /etc/racoon.conf konfiguriert, in welcher Beispielsweise folgender Inhalt sein könnte:

# PSK Path
path pre_shared_key "/etc/ipsec-psk.txt";

remote 10.0.0.2 {
 exchange_mode main;
 proposal {
  encryption_algorithm aes;
  hash_algorithm sha1;
  authentication_method pre_shared_key;
  dh_group modp2048;
 }
}

sainfo address 10.0.0.2 any address 10.0.0.1 any {
 pfs_group modp2048;
 lifetime time 6 hour;
 encryption_algorithm aes;
 authentication_algorithm hmac_sha1;
 compression_algorithm deflate;
}

sainfo address 10.0.0.1 any address 10.0.0.2 any {
 pfs_group modp2048;
 lifetime time 6 hour;
 encryption_algorithm aes;
 authentication_algorithm hmac_sha1;
 compression_algorithm deflate;
}

Kleiner Hinweis noch: Bei remote muss dahinter die IP Adresse vom jeweils anderen Server stehen.

Nun muss man sich nur noch ein Password für die Verschlüsselung ausdenken und dies in die Datei /etc/ipsec-psk.txt schreiben:

10.0.0.2 strenggeheim

Auch hier muss wieder die IP zum jeweils anderen System passen, damit racoon diese Datei akzeptiert muss die Datei dem Benutzer root gehören und darf keine Rechte für andere Benutzer haben:

chown root:root /etc/ipsec-psk.txt
chmod 0600 /etc/ipsec-psk.txt

Start

Hat man dies alles gemacht kann man nun IPSec starten:

/etc/rc.d/racoon start
/etc/rc.d/ipsec start

Ab jetzt wird zwischen den beiden Servern IPSec zur Verschlüsselung verwendet. Wenn alles funktioniert kann man dies natürlich in den Autostart der /etc/rc.conf packen, so dass bei jedem Sytemstart automatisch IPSec aktiviert wird.

Bitte beachtet das dies nur eine mögliche Konfiguration ist, für wirklich wichtige Daten will man statt eines PSK lieber X.509 Zertifikate einsetzen. Auch gehe ich in den Beispiel davon aus das mein Patch wirklich akzeptiert wird.