[2013] app.net – Die spießige Sehnsucht nach Ruhe

Ich bin ja nicht der älteste, und so habe ich Anfang der 1990er Jahre als armer Schüler und Azubi noch CB-Funk gemacht. Da kaufte man sich Hardware, schraubte die Antenne aufs Haus- oder Autodach und konnte ohne jede Zugangsbeschränkung (die Anmeldepflicht beim Amt war bereits abgeschafft) in die Kommunikation mit anderen einsteigen. Vollkommen anonym übrigens, denn das Ausplaudern von Klarnamen war praktisch geächtet.
So etwa Anfang 1993 habe ich dann von einem Computerflohmarkt ein 2400-Baud-Modem mitgebracht. Ab da ging es ganz schön rund. Von heute betrachtet, ist es fast unvorstellbar, wie schnell sich die Dinge damals für mich weiterentwickelten und änderten.
Zu der Zeit hatte ich schon 10 Jahre in Zeitungen von diesen Mailboxen gelesen, aber jetzt konnte ich mich endlich selbst einwählen. Mein Zuhause waren bald das MausNet, und FidoNet, das damals eben gerade den großen Fido-Putsch hinter sich hatte und in Deutschland in zwei bis aufs Blut verfeindete Netze gespalten war. Das war eine ziemlich gesellige Zeit mit wirklich großen regelmäßigen Mailboxtreffen der beiden MausNet-Mailboxen aus Wiesbaden und der Mailbox aus dem Rhein-Lahn-Kreis, bei der ich FidoNet-Point war.
Nach dem Ende meiner Lehre hatte ich ein Einkommen und bald auch meine eigene FidoNet-Mailbox. Das müßte so Ende 1994 gewesen sein. Der Putsch wirkte noch nach. Es gab zahlungskräftige Mailboxbetreiber, die per Ferngespräch nachts das Routing in andere Länder abwickelten und von den in der Hierarchie unterhalb von ihnen angesiedelten Mailboxen wahlweise Anerkennung oder Geld forderten, eigentlich aber beides. Kürzlich habe ich auf meinem Fileserver die Digitalfotos von einem Treffen in Frankfurt-Bockenheim im Jahr 1995 wiedergefunden, wo es genau um dieses Thema ging.
Parallel hatte ich im Frühjahr 1995 mit Compuserve angefangen. Im “Compuserve Information Manager”, der proprietären Zugangssoftware, hatte man themenbezogene sogenannte “Foren” (etwa: “Deutschland” oder “Filme”), die aus einem Chatbereich, einem Messagebereich und einem Download-Bereich bestanden. In Compuserve herrschte Ruhe. Anders als im nervigen FidoNet gab keine Diskussionen darüber, wer Geber und Nehmer war, sondern alle bezahlten in einer Richtung ihre monatlichen und stündlichen Beiträge an Compuserve und ihre Telefongebühren an die Post.
Nachdem ich per Compuserve die ersten Schritte ins WWW gemacht hatte, tauchte die erste Reklame eines örtlichen ISP auf, bei dem ich Kunde wurde. Das Mailboxthema habe ich dann bald an den Nagel gehängt. Nach den Querelen der FidoNet-Zeit empfand ich es als Erleichterung, die Infrastruktur nicht mehr nach Gutsherrenart vom lokalen Netzfürsten zu bekommen, sondern einfach dafür zu bezahlen. Wie es weiterging, kann man sich ausrechnen: Noch 1995 die erste Homepage, 1996 die erste eigene Domain, bei meinem Arbeitgeber das Internetthema komplett betreut, 1997 selbständig mit meiner eigenen Firma.
Das Social Networking lief in dieser Zeit per Mailinglisten, IRC und Newsgroups. Wer einen Internetzugang hatte, konnte ohne jede Zugangsbeschränkung in die Kommunikation mit anderen einsteigen.
Als es Anfang der 2000er Jahre mit den Blogs losging, dachte ich ernsthaft, wir hätten es geschafft und hätten die öffentliche Meinung im Internet wirklich befreit. Die Grenzen von Mailboxen oder Uni-Rechnern waren gesprengt, jeder konnte frei sein Ding machen und seine Meinung veröffentlichen. Man hatte das Gefühl, richtig was bewegen zu können, aber die realistischeren Mitglieder der Szene wussten ehrlich gesagt immer, dass es außerhalb der “Bloggeria” eigentlich gar keine Anteilnahme an unseren großen Aufregern gab.
Und dann kamen Facebook und vor allem Twitter. Gerade Twitter, am Anfang noch aufgrund seines speziellen Funktionsumfangs belächelt, wurde zum Zentralorgan der engagierten Netzbewohner. Der CB-Funk des Netzes. Wer es schaffte, sich vor einen Rechner mit Internetzugang zu setzen, oder ein Smartphone in die Hand zu nehmen, hatte plötzlich ein weltweites Publikum und konnte ohne Zugangsbeschränkung in die Kommunikation mit anderen einsteigen. Als 2009 das Flugzeug im Hudson gewassert war, stammelte der Nachrichtensprecher in den deutschen Abendnachrichten noch, während die Bilder der geretteten Passagiere bereits seit einer halben Stunde per Twitter um die Welt gingen. Von 2010-2012 rollte eine Welle von Revolutionen  durch Nordafrika, auch getragen durch Twitter und Facebook. 2012 hat Twitter es geschafft, tausende für Occupy und gegen ACTA auf die Straße zu bringen.
Mahnende Stimmen wegen dieser kostenlosen Dienste hatte es schon länger gegeben: “Wenn ihr für das Produkt nichts bezahlt, seid ihr selbst das Produkt.” Ob das stimmt? Es fällt mir schwer, es abschließend zu beurteilen. Aber gerade in 2012 wurden mehrere vermeintlich seriösere, offenere und verteiltere Twitter-Alternativen mit ungeheuer großem Enthusiasmus angekündigt und frenetisch begrüßt, die anschließend in Rekordgeschwindigkeit vergessen wurden. Eine kam durch, und die war weder offen noch verteilt: Das kostenpflichtige app.net will eine vielfältig benutzbare Plattform sein, und kein reiner Dienst fürs Microblogging. Für 3 US-Dollar im Monat schmorten ein halbes Jahr lang die ausgewiesensten Spezialisten für Social Networking im exklusiven eigenen Saft.
Dass app.net mit diesem reinen Bezahlsystem lebensunfähig geboren war, wurde nur von wenigen erkannt, jedoch immerhin von app.net selbst. Und so wurden die Tore Anfang 2013 geöffnet und es durften auch nicht-zahlende Benutzer mitspielen, jedoch nicht ohne Zugangsbeschränkungen, sondern zu bestimmten Bedingungen, die die Möglichkeiten zur Kommunikation mit anderen reglementieren. Das war der Tag, an dem app.net für mich interessant wurde und ich meine 36 US-Dollar für 12 Monate bezahlt habe, um mir die Sache anzuschauen. Gleich nach dem ersten Anmelden war erkennbar, dass diese Freigabe für reichlich Aufruhr bei den zahlenden Usern der ersten Stunde sorgte. Viele waren sichtlich nicht begeistert waren vom Anblick der einfallenden Usermengen. Der Untergang der Diskussionskultur und eine Welle an Fernseh- und Fussballtweets wurden herbeibeschworen.
Viele halten app.net für das nächste große “Ding”, das die Netzwerkkommunikation revolutionieren wird. Ich melde Zweifel an. Und ich habe die Geduld in dem Moment verloren, als ich einen Chat-Dienst auf Basis von app.net gesehen habe. Hier gibt es in der Außenwelt Protokolle wie XMPP und IRC, die bereits für Millionen von Nutzern etabliert sind – teils seit Jahrzehnten – und deren Benutzung jedermann offensteht. Die hier erkennbare Tendenz, sich nach der totalen Offenheit von Twitter in ein geschlossenes Netzwerk zurückziehen zu wollen, um den Anblick des Pöbels nicht mehr ertragen zu müssen, erschreckt mich. App.net ist für mich ein Rückschritt um 20 Jahre, in die abgeriegelte Umgebung von Compuserve. Aus Angst vor der Kränkung, vermeintlich das Produkt zu sein, verkriechen sich vermeintlich erleuchtete Experten in einen kostenpflichtigen privaten Zirkel.
Bereits heute klafft die Schere weit auseinander: Auf Twitter werden Menschenrechtsdemos organisiert, während sich auf dem intellektuell ausgebluteten Facebook schonmal Lynchmobs bilden. Als die erfahrensten Netznutzer müssen wir das verstehen, handeln und Verantwortung übernehmen. Die freie Kommunikation für jedermann muss geschützt werden.
Wie sollen sich ein Schüler aus einfachen Verhältnissen, ein arbeitsloser junger Mensch oder ein Rentner am Rand des Existenzminimums gut vernetzen, wenn alles, wo sie gehört werden würden, app.net mit seinen rigiden Limits für kostenlose User ist? Welcher Sache ist gedient, wenn sich eine selbsternannte netzintellektuelle Oberschicht in ihrem Club einsperrt, vom dem aus die normalen Menschen nicht mehr sichtbar sind? Und selbst wenn kostenlose User mit viel mehr Möglichkeiten ausgestattet werden: Was, wenn ein solcher Bezahlservice pleite geht, oder wir ihm aufgrund der Rechtslage in seinem Land nicht mehr vertrauen können? Ein “Fork” wie er zur Zeit des unseligen Fido-Putsch möglich war, wird dann undenkbar sein.
Jedermann sollte ohne Zugangsbeschränkung mit anderen kommunizieren können. Freie Software für verteilte soziale Netze ist seit Jahren verfügbar und wird aktiv entwickelt. Der Weg zurück in die Steinzeit der sozial undurchlässigen bezahlten Datennetze ist der falsche.

FTPS vs. SFTP, once and for all.

I had to provide an explanation about the differences between FTPS and SFTP today, which sound so similar, but are in reality extremely different and can easily confused by those who don’t spend lots of quality time with them.

SFTP (“SSH FTP”) is based on SSH (Secure Shell) version 2. It uses the same communication channels and encryption mechanisms as SSH.

FTPS (“FTP over SSL”) is based on the the legacy FTP protocol, with an additional SSL/TLS encryption layer. There are several implementations of FTPS, including those with “implicit SSL” where a distinct service listens for encrypted connections, and “explicit SSL” where the connection runs over the same service and is switched to an encrypted connection by a protocol option. In addition, there are several potential combinations of what parts of an FTPS connection are actually being encrypted, such as “only encrypted login” or “encrypted login and data transfer”.

FTPS uses the same communication channels as legacy unencrypted FTP, including dynamically negiotiated side-band connections. Due to these side-band connections, FTP has always been problematic with firewalls. The encryption layer further exacerbates these issues.

Due to this rather long list of ins-and-outs, FTPS can be considered an exotic protocol, while SFTP has widespread acceptance due to the omnipresence of SSH servers on all Linux or UNIX servers.

The only objective advantage of FTPS is that FTPS uses an SSL certificate that is signed by a trusted third party and can be used in an opportunistic way, similar to HTTPS encryption in web browsers. However, if password authentication is not enough and mutual authentication using X.509 client certificates comes into play, this advantage loses part of its validity, because mutual authentication nearly always requires manual intervention from both sides.

OpenSSH connection multiplexing

The Challenge
I was in touch with a developer the other day who used SSH to programmatically connect to a remote machine where he would start some kind of processing job. Unfortunately, he was in trouble when he wanted to kill the remote process. Killing the local SSH client would leave his job active. He claimed that there used to be some sort of signal forwarding feature in OpenSSH on the machine where he had developed his application in OpenSSH 3.x days, but this feature seems to have been removed by now.
I wasn’t able to confirm anything of this, but this gentleman’s problem got me curious. I started to wonder: Is there some kind of sideband connection that I might use in SSH to interact with a program that is running on a remote machine?
The first thing I thought of were port forwards. These might actually be used to maintain a control channel to a running process on the other side. On the other hand, sockets aren’t trivial to implement for a /bin/ksh type of guy, such as the one I was dealing with. Also, this approach just won’t scale. Coordination of local and remote ports is bound to turn into a bureaucratic nightmare.
I then started to skim the SSH man pages for anything that looked like a “sideband”, “session control” or “signaling” feature. What I found, were the options ControlMaster and ControlPath. These configure connection multiplexing in SSH.
Proof Of Concept
Manual one-shot multiplexing can be demonstrated using the -M and -S options:
1) The first connection to the remote machine is opened in Master mode (-M). A UNIX socket is specified using the -S option. This socket enables the connection to be shared with other SSH clients:

localhost$ ssh -M -S ~/.ssh/controlmaster.test.socket remotehost


2) A second SSH session is attached to the running session. The socket that was opened before is specified with the -S option. The remote shell opens without further authentication:

localhost$ ssh -S ~/.ssh/controlmaster.test.socket remotehost


The interesting thing about this is that we now have two login sessions running on the remote machine, who are children of the same sshd process:

remotehost$ pstree -p $PPID
sshd(4228)─┬─bash(4229)
           └─bash(4252)───pstree(4280)


What About The Original Challenge?
Well, he can start his transaction by connecting to the remote machine in Master mode. For simplicity’s sake, let’s say he starts top in one session and wants to be able to kill it from another session:

localhost$ ssh -t -M -S ~/.ssh/controlmaster.mytopsession.socket remotehost top


Now he can pick up the socket and find out the PIDs of all other processes running behind the same SSH connection:

localhost$ ssh -S ~/.ssh/controlmaster.mytopsession.socket remotehost 'ps --ppid=$PPID | grep -v $$'
  PID TTY          TIME CMD
 4390 pts/0    00:00:00 top


This, of course, leads to:

localhost$ ssh -S ~/.ssh/controlmaster.mytopsession.socket remotehost 'ps --no-headers -o pid --ppid=$PPID | grep -v $$ | xargs kill'


Then again, our shell jockey could just use PID or touch files. I think this is what he’s doing now anyway.
Going Fast And Flexible With Multiplexed Connections
With my new developer friend’s troubles out of the way, what else could be done with multiplexed connections? The SSH docs introduce “opportunistic session sharing”, which I believe might actually be quite useful for me.
It is possible to prime all SSH connections with a socket in ~/.ssh/config. If the socket is available, the actual connection attempt is bypassed and the ssh client hitches a ride on a multiplexed connection. In order for the socket to be unique per multiplexed connection, it should be assigned a unique name through the tokens %r (remote user), %h (remote host) and %p (destination port):

ControlPath ~/.ssh/controlmaster.socket.%r.%h.%p
# Will create socket as e.g.: ~/.ssh/controlmaster.socket.root.remotehost.example.com.22


If there is no socket available, SSH connects directly to the remote host. In this case, it is possible to automatically pull up a socket for subsequent connections using the following option in ~/.ssh/config:

ControlMaster auto


So Where’s The Actual Benefit?
I use a lot of complex proxied SSH connections who take ages to come up. However, connecting through an already established connection goes amazingly fast:

# Without multiplexing:
localhost$ time ssh remotehost /bin/true
real    0m1.376s
...
# With an already established shared connection:
localhost$ time ssh remotehost /bin/true
real    0m0.129s
...


I will definitely give this a try for a while, to see if it is usable for my daily tasks.
Update, 2009/05/04: No, it isn’t. Disconnecting slave sessions upon logout of the master session are too much of a nuisance for me.

Using the SSH agent from daemon processes

One of my more recent installations, the BackupPC server I wrote about earlier, needs full access as the user root to his clients in order to retrieve the backups. Here’s how I implemented authentication on this machine.
BackupPC runs as its own designated user, backuppc. All authentication procedures therefore happen in the context of this user.
The key component in ssh-agent operation is a Unix domain socket that the ssh client uses to communicate with the agent. The default naming scheme for this socket is /tmp/ssh-XXXXXXXXXX/agent.<ppid>. The name of the socket is stored in the environment variable SSH_AUTH_SOCK. The windowing environments on our local workstations usually run as child processes of ssh-agent. They inherit this environment variable from their parent process (the agent) and therefore the shells running inside our Xterms know how to communicate with it.
In the case of a background server using the agent, however, things are happening in parallel: On one hand, we have the daemon which is being started on bootup. On the other hand, we have the user which the daemon is running as, who needs to interactively add his SSH identity to the agent. Therefore, the concept of an automatically generated socket path is not applicable and it would be preferable to harmonize everything to a common path, such as ~/.ssh/agent.socket.
Fortunately, all components in the SSH authentication system allow for this kind of harmonization.
The option -a to the SSH agent allows us to set the path for the UNIX domain socket. This is what this small script, /usr/local/bin/ssh-agent-wrapper.sh does on my backup server:

#!/bin/bash
SOCKET=~/.ssh/agent.socket
ENV=~/.ssh/agent.env
ssh-agent -a $SOCKET > $ENV


When being started in stand-alone mode (without a child process that it should control), ssh-agent outputs some information that can be sourced from other scripts:

SSH_AUTH_SOCK=/var/lib/backuppc/.ssh/agent.socket; export SSH_AUTH_SOCK;
SSH_AGENT_PID=1234; export SSH_AGENT_PID;
echo Agent pid 1234;


This file may sourced from the daemon user’s ~/.bash_profile:

test -s .ssh/agent.env && . .ssh/agent.env


However, this creates a condition where we can’t bootstrap the whole process for the first time. So it might be somewhat cleaner to just set SSH_AUTH_SOCK to a fixed value:

export SSH_AUTH_SOCK=~/.ssh/agent.socket


Here’s the workflow for initializing the SSH agent for my backuppc user after bootup:

root@foo:~ # su - backuppc
backuppc@foo:~ $ ssh-agent-wrapper.sh
backuppc@foo:~ $ ssh-add


In the meantime, what is happening to the backuppc daemon?
In /etc/init.d/backuppc, I have added the following line somewhere near the top of the script:

export SSH_AUTH_SOCK=~backuppc/.ssh/agent.socket


This means that immediately after boot-up, the daemon will be unable to log on to other systems, as long as ssh-agent has not been initialized using ssh-agent-wrapper.sh. After starting ssh-agent and adding the identity, the daemon will be able to authenticate. This also means that tasks in the daemon that do not rely on SSH access (in the case of BackupPC, things like housekeeping and smbclient backups of “Windows” systems) will already be in full operation.

Massengenerierung von PGP-Schlüsseln

Wenn man jemandem ins Pflichtenheft geschrieben hat, daß seine Software unter der Last von 10.000 PGP-Keys nicht schwächeln darf, muß man irgendwann auch mal ins kalte Wasser springen und tatsächlich 10.000 Keys generieren:

#!/bin/sh -e
export LANG=C
for I in `seq 1 10000`
do
        NUMBER=`printf "%5.5d\n" $I`
        USERNAME="Testuser #$NUMBER"
        COMMENT="auto-generated key"
        EMAIL="testuser-$NUMBER@pgp-loadtest.example.com"
        (
        cat <<EOF
        %echo Generating Key for $EMAIL
        Key-Type: DSA
        Key-Length: 1024
        Subkey-Type: ELG-E
        Subkey-Length: 1024
        Name-Real: $USERNAME
        Name-Comment: $COMMENT
        Name-Email: $EMAIL
        Expire-Date: 2009-01-01
        Passphrase: foo
        %commit
EOF
        ) | gpg --gen-key --batch --no-default-keyring \
            --secret-keyring /var/tmp/gpg-test.sec \
            --keyring /var/tmp/gpg-test.pub
done


Die schlechte Nachricht: Spätestens nach dem dritten Key wird GnuPG eine Pause einlegen, weil der Entropie-Pool ausgelutscht ist. Ich habe meine Lösung für dieses Problem gefunden, indem ich (und das ist wirklich sehr, sehr böse, bitte auf keinen Fall zuhause nachmachen) /dev/urandom zu /dev/random umgelötet habe. Kreative alternative Lösungsvorschläge für das schmutzige kleine Entropie-Problem werden auf jeden Fall gern entgegengenommen.

Swap im Reality Check

Swap unter Linux scheint so eine Sache zu sein, um die sich reichlich Mythen und Legenden ranken. Deshalb schreibe ich heute mal auf, was ich so von der Sache halte.
Wie wir alle wissen, wird der Swap-Bereich zusammen mit dem realen Arbeitsspeicher (RAM) zum sogenannten Virtual Memory (VM) zusammengefaßt. Auf einem System mit 2 GB RAM und 2 GB Swap steht also ein für Appikationen nutzbares VM von 4 GB zur Verfügung. Die Hälfte davon befindet sich als Swap auf Festplatte. Zugriffe darauf sind sehr viel langsamer als Zugriffe auf den normalen Arbeitsspeicher.
Mythos: “Jedes UNIX-System braucht Swap!”
Swap ist nicht mehr als eine sehr, sehr langsame Speichererweiterung. Ist der Arbeitsspeicher voll, werden Speichersegmente auf Festplatte ausgelagert. Dadurch, daß diese Auslagerung deutlich langsamer als normale RAM-Aktiviät geschieht, wird das System in aller Regel extrem langsam. Diese Auslagerungsaktivität kann im Rahmen einer Überwachung erkannt werden. Idealerweise wird auch die Problemquelle identifiziert und der entsprechende Prozeß von Hand beendet, so daß das System weiterlaufen kann.
Daraus folgt im Prinzip nichts anderes, als daß Swap nichts weiter bringt, als einen gefühlten Zeitgewinn für das Beenden von Speicherfressern.
Auf der Hand liegt andererseits auch, daß man z.B. ein Flash-basiertes (und damit read-only)-System ohne Swap betreiben können muß. Folglich gilt, daß ein Linux-System ohne Swap problemlos laufen kann, solange der Arbeitsspeicher für den gesamten Speicherbedarf aller zu benutzenden Applikationen ausreichend dimensioniert ist.
Mythos: “Swap muß immer auf einer eigenen Partition liegen!”
Unter Linux (und vermutlich auch den meisten anderen UNIX-Systemen) ist es problemlos möglich, anstelle einer Swap-Partiton ein Swapfile zu verwenden. Die Vorgehensweise dazu ist dort in der Manpage von mkswap beschrieben. Da ein swappendes System ohnehin ein schweres Problem mit der Performance von Speicherzugriffen hat, kann man den marginalen zusätzlichen Performanceverlust durch die Dateisystemebene praktisch vernachlässigen. (Eine Ausnahme gilt, die erwähne ich im übernächsten Absatz.)
Mythos: “Es muß immer doppelt soviel Swap vorhanden sein, wie Arbeitsspeicher!”
Das ist so eine ganz alte Daumenregel, deren historischer Hintergrund schwer durchschaubar ist. Sie ist vermutlich teilweise darin begründet, daß es UNIX-Systeme gegeben haben soll, bei denen der Arbeitsspeicher auf Swap gespiegelt wurde. Um also eine wirksame Vergrößerung des VM durch Swap zu haben, war also wesentlich mehr Swap als Arbeitsspeicher erforderlich.
Eine Mindestgröße für Swap ergibt sich bei tragbaren Systemen, die für die Hibernation ihren Arbeitsspeicher auf Swap auslagern. Dies ist meines Wissens die einzige Situation, in der nicht nur eine wirkliche Mindestgröße für Swap vorliegt, sondern in der es sich auch tatsächlich um eine Swap-Partition handeln muß.
Generell gilt, daß es über die altbekannte Daumenregel hinaus keine feststehende Regel für die Swap-Größe gibt. Wer sich an der alten Regel festhalten will, darf das gern tun. Man sollte sich aber durchaus fragen, welche Dinge man von einem System mit 8, 16 oder 32 GB Swap zu erwarten glaubt.
Mythos: “Aber tmpfs braucht Swap!”
Nur um dem unvermeidlichen Kommentar vorzubeugen: Das tmpfs-Dateisystem, z.B. unter Solaris und Linux, braucht nicht Swap, sondern Virtual Memory. Es wird also bei ausreichenden Platzverhältnissen im Arbeitsspeicher gehalten, kann aber von Applikationen auf Swap verdrängt werden. Es stellt sich die Frage, inwieweit ein dediziertes Filesystem für /tmp überhaupt eine Berechtigung hat, wenn seine Schreib- und Leseperformance im Prinzip unvorhersagbar sind.

What goes up, must come down. Ask any system administrator.