Benutzer-Werkzeuge

Webseiten-Werkzeuge


Seitenleiste

Was fehlt?

Es liegt in der Natur der Sache: Ein Wiki ist niemals fertig. Wir geben uns große Mühe, mit der Entwicklung Schritt zu halten; lassen Supportanfragen direkt in neue Artikel einfließen … aber auch wir sind nicht perfekt. Wenn du hier nicht fündig wirst: Nicht schmollen - Bescheid sagen! Unter hallo@uberspace.de steht dir unser Team gerne bereit. Hand drauf!

brainstorming

Brainstorming

Auf dieser Seite sammeln wir in roher Form Ideen, Anregungen, Wünsche, … alles, was Uberspace.de weiterbringt. Es dient in erster Linie dazu, solche Dinge zu konsolidieren und zwischen „ist mit vertretbarem Aufwand umsetzbar“ und „wird von vielen gewünscht“ abzuwägen. Die Reihenfolge ist alphabetisch und stellt insofern keine Wertung dar. Wir entwickeln Dinge bei Uberspace.de grundsätzlich so, dass sie online gehen, wenn sie fertig sind - ganz einfach. Wir prognostizieren daher grundsätzlich keine Angaben, wann, ob und wie etwas umgesetzt wird. Sieh diese Seite eher als unsere Spielwiese an, auf der wir manchmal auch mit Ideen hantieren, die wir letzten Endes vielleicht auch einfach wieder als „dumme Idee“ verwerfen.

Wenn du irgendwo per Mail oder auch per Twitter Fragen oder Vorschläge äußerst, kommen wir typischerweise ganz von selbst auf die Idee, sie hier auf die Brainstorming-Seite zu packen (ansonsten sag uns Bescheid). Wir haben überlegt, diese Wiki-Seite hier öffentlich bearbeitbar zu machen, aber im Moment erscheint es uns sinnvoller, die Diskussion konkret mit den Leuten zu führen, die bestimmte Features vorschlagen, und hier im Wiki nur die Dokumentation dieser Punkte in einigermaßen strukturierter Form vorzunehmen - letztlich geht es hierbei ja auch darum, einen Einblick zu geben, wie wir Uberspace.de weiter entwickeln wollen. Es ist also am ehesten eine Art interner Notizzettel, mit dem wir offen kommunizieren wollen, wohin bei uns die Reise so geht, was wir gut finden, was wir vielleicht schon als „wollen wir nicht“ abgehakt haben …

Bitcoins

Bitcoin ist eine anopseudonyme digitale Währung, die auf einem Peer-to-Peer-Netzwerk aufbaut.“

Technologisch hochinteressant; außerdem voll zu unserem Konzept in puncto „Wir erfassen keine Daten“ passend. Dieser Punkt wird ja derzeit regelmäßig mit Eingang einer Überweisung gebrochen, bei dem wir zwar keine Adress- oder Telekommunikationsdaten enthalten, aber über die Bankverbindung werden Personen - zumindest für Ermittlungsbehörden - greifbar. Auch hier gilt wiederum: Uberspace.de will natürlich kein Platz für illegale Aktivitäten sein. Wir halten die Möglichkeit, Leistungen anonym oder pseudonym einkaufen zu können, aber umgekehrt für eine Selbstverständlichkeit; Anonymität und Pseudonymität sind durchaus auch für Menschen da, die „nichts zu verbergen“ haben.

Bitcoins zu implementieren stellt technisch eigentlich kein großes Problem dar: Es ist freie Software; es gibt einen Daemon, der sich über eine simple API steuern lässt; es gibt mit Finance::Bitcoin ein CPAN-Modul, mit dem das besonders einfach integrierbar ist.

Lange Zeit war unklar, wie Bitcoins steuerlich zu behandeln sind, denn der Punkt ist: Alle unsere Lieferanten wollen in Euro bezahlt werden; wir müssen die Bitcoins also in Euro umwandeln lassen. Nun sind wir schon gefühlte siebenhundertdreiunvierzig Mal von Leuten darauf hingewiesen worden, dass doch nun klar sei, dass der Tausch von Bitcoins in Euro nach einem Jahr ertragssteuerfrei sind. Das mag sein, nur sind Bitcoins für uns ja auch gar kein Spekulationsobjekt, mit dem wir Gewinne machen wollten; wir wollen sie „so bald wie möglich“ in Euro tauschen, um einen für uns nutzbaren Gegenwert zu haben - nicht erst nach einem Jahr Haltezeit. Solange es aber niemanden gibt, dem wir sagen, hey, wir haben nullkommasoundsoviele Bitcoins eingenommen, gib uns *jetzt* Euro dafür, und wir schreiben dem User genau diesen Euro-Betrag gut, bleiben Bitcoins Spekulationsobjekt, ob wir das wollen oder nicht: Wir gehen ein Kursschwankungsrisiko ein, bei dem wir entweder Geld verlieren oder aber Geld hinzugewinnen, auf das dann aber (aufgrund der Haltezeit von unter einem Jahr) Ertragssteuer anfiele. Damit hätten wir einen administrativen Overhead, den wir eigentlich gerne vermeiden würden. Die vielen Verweise auf bitcoin.de sind da nur bedingt hilfreich, denn das ist nun mal keine Wechselstube, sondern ein Marktplatz: Weder können wir dort Bitcoins zu einem zuvor garantierten Kurs tauschen, noch wäre sichergestellt, dass wir dort *überhaupt* einen Abnehmer fänden.

Nun finden sich allerdings auch einige Anbieter, die Bitcoin-basierende Payment-Gateways anbieten, beispielsweise BitPay. Im Prinzip machen die auch, was wir brauchen: Es steht vorher ein Kurs fest, so dass klar ist, wieviel €€€ wir einem mit Bitcoins zahlenden User auf seinem Uberspace gutschreiben können, und der entsprechende Gegenwert wird dann ausgezahlt. Das Kursschwankungsrisiko und damit auch der steuerliche Aufwand liegt damit nicht mehr bei uns. Das Problem ist, dass uns kein einziger derartiger Anbieter in Deutschland bekannt wäre (der damit auch der deutschen Jurisdiktion unterläge) - oder auch nur in Europa. Ein Account beispielsweise bei BitPay würde Terms of Use wie beispielsweise Zusicherungen wie diese einschließen: „your use of the Services will not violate the laws of the United States of America“. Wie könnten wir denn bitte garantieren, dass unsere Leistungen nicht mit US-Gesetzen kollidieren - insbesondere angesichts dessen, dass die USA insbesondere in puncto Datenschutz und Überwachungsregelungen ja nun häufig auch etwas andere Vorstellungen haben als wir? Keiner von uns würde sich auch nur im Traum anmaßen, anzusagen, das amerikanische Rechtssystem in ausreichender Detailtiefe zu kennen. Auch in unsere Büroräume möchte BitPay offenbar gerne mal hineinschauen dürfen („We may ask for permission to inspect your business location […] If you refuse our request, we may suspend or terminate your BitPay account“). Zum Thema Datenschutz besagen die ToS ganz offen: „In order to provide the Services, we may share information about you and your BitPay account with third parties, including but not limited to your bank and purchasers“. Entschuldigung, aber das kann doch niemand unterschreiben, der noch ganz bei Trost ist.

Lange Rede, kurzer Sinn: So einfach ist das alles nicht. Wir beobachten die Entwicklung weiter; wir freuen uns auch durchaus über sachdienliche Hinweise; für den Moment sehen wir aber noch keine Möglichkeit, eine Zahlung via Bitcoins anzubieten.

Update: bips.me aus Dänemark sieht auf den ersten Blick ganz gut aus.

Devotionalien

Nachdem schon mehrfach die Frage aufkam, ob's T-Shirts von uns gibt, sollten wir vielleicht mal welche machen lassen. Wichtig: Wir wollen keine menschlichen Werbeträger; die Motive müssen halt von sich aus ansprechend sein. Zu überlegen wäre außerdem, ob's die Shirts dann letztlich nicht zu kaufen gibt, sondern wir damit eher Leute „belohnen“, die uns z.B. auf coole Ideen gebracht haben, tolle Doku für's Wiki geschrieben haben oder sich sonst irgendwie um Uberspace.de verdient gemacht haben. Hochwertigkeit geht vor - von diesem Rotz, der nach dreimal Waschen hinüber ist, hat ja niemand was.

Explizit gewünscht wurden Aufkleber, die man sich ans Notebook (oder sonstwohin) pappen kann …

Diaspora

Mal schauen, ob sich das bei uns installieren lässt. Wenn ja, wäre hier etwas Doku unter Coole Sachen nett.

Kopfzerbrechen bereitet hier vor allem die Anbindung an Redis, weil hier offenbar vorausgesetzt wird, dass der Redis-Server einfach „offen“ ist; zumindest haben sich uns hier nicht ad hoc irgendwelche Konfigurationsmöglichkeiten für Redis-Zugangsdaten in den Weg gestellt. Ihn einfach so offen laufen zu lassen, verbietet sich bei einem Shared-Hosting-System, wo noch andere User über localhost zugreifen können, aber von selbst. Hier wäre noch zu schauen, wie sich das dann auf sichere Weise implementieren ließe - das braucht aber noch Zeit, und die Nachfrage ist gering, spätestens seit es Friendica gibt (was out of the box funktioniert).

Domains und DNS

Viele User scheinen erstaunlich wenig Kenntnisse von den Zusammenhängen zwischen Domains und DNS zu haben (auch was die Unterscheidung zwischen Registry und Registrar angeht), was die Zahl der Supportanfragen zeigt. Es könnte daher sinnvoll sein, mal einen allgemeinen Eintrag ins Wiki zu packen, der einsteigerfreundlich erklärt, was das alles bedeutet und wie es zusammenhängt, und auch, welche konkreten Optionen hier bei Uberspace.de bestehen (Domain woanders, aber DNS bei uns ⇔ Domain und DNS woanders ⇔ Domain und DNS bei uns).

Hilfreich wäre außerdem etwas Dokumentation darüber, wie Domainumzüge konkret bei den verschiedenen TLDs laufen, weil sich die Abläufe zum Teil erheblich unterscheiden (Stichworte: Papier nötig oder nicht, AuthCode/AuthInfo, FOA-Mail oder nicht, explizite Freigabe des alten Registrars erforderlich oder nicht, muss vorher ein LOCK entfernt werden, etc.pp.), da auch hierzu verhältnismäßig viele Anfragen reinkommen.

Zu DNS: Einige User wünschen sich direkten Zugriff auf die DNS-Einträge bei uns, was wir derzeit nicht anbieten. Fast interessanter als eine Integration ins Webinterface wäre hier ggf. eine Möglichkeit, tinydns-kompatible Zonefiles im Userspace zu ermöglichen, die wir dann periodisch „einsammeln“ und in unser DNS integrieren. Hier müsste allerdings irgendein Mechanismus erfolgen, der Kollisionen vermeidet, damit User nur die Domains steuern, die auch zu ihrem Uberspace gehören - ließe sich ggf. mit der Domainaufschaltung verbinden. Außerdem müsste hier ein vernünftiger Syntaxcheck jener Zonefiles stattfinden.

Dynamisches DNS

Wir planen derzeit nicht eine Lösung für Dynamisches DNS anzubieten.

  • Wir haben die Hoffnung noch nicht ganz aufgegeben, daß die Internet-Anbieter der Welt sich endlich mal aufraffen und IPv6 einführen und sich der Bedarf nach dynamischem DNS damit erledigt. Feste IPv6-Adressen für alle. Wir wollen hier nicht mehr viel Zeit und Energie in eine Technik stecken, von der wir hoffen, dass sie demnächst endlich ausstirbt.
  • Es gibt für dynamisches DNS keinen wirklich etablierten Standard, über den die DNS-Updates realisiert werden können. (Ja, es gibt DDNS und in letzter Zeit sieht es ein bisschen danach aus, als würde sich das jetzt allmählich durchsetzen.) Wir wollen hier auf gar keinen Fall noch ein Anbieter-spezifisches System einführen. Für alle Geräte auf denen man leicht Skripts ausführen kann wäre es ja in Ordnung, wenn die User sich ihre DNS-Updates „mal eben skripten“ können, aber unserer Einschätzung nach werden viele User solche Funktionen auch in ihren Plaste-Routern zu Hause nutzen wollen und dort haben sie in der Regel keinen Shellzugang oder zumindest nicht die Möglichkeit selbstgeschriebene Skripte auszuführen.
  • Es gibt schon so viele Anbieter für dynamisches DNS. Solange wir da nicht eine Lösung anbieten können die unserer Meinung nach viel toller ist als die der anderen, haben wir daran im Grunde kein Interesse. Wir machen Uberspace weil es uns Spaß macht (wir schreiben das nicht nur so). Das ist mal aus der Idee entstanden, Shared Hosting so zu machen wie wir selbst es gerne hätten (was impliziert, daß es damit aus unserer Sicht viel toller als das aller anderen Anbieter ist).
  • Eigentlich sind Domains insgesamt nicht so unser Ding. Wir bieten im Rahmen von Uberspace zwar an, dass User ihre Domains bei uns unterbringen können, aber eher deswegen weil wir sonst viel zu oft danach gefragt würden – und weil wir einsehen, daß es durchaus sehr praktisch ist. Um ehrlich zu sein, macht uns das aber wenig Spaß. Jede einzelne Top Level Domain hat komplett andere, zum Teil recht bizarre Regeln die es zu beachten gilt (etwa: Domaininhaber muß Wohnsitz im Land nachweisen) und / oder komplett uneinheitliche und zum Teil absurd hohe Preise. Über Datenschutz im whois brauchen wir gar nicht erst reden. Dann kommen noch uneinheitliche Regeln für Vorgänge wie Besitzerwechsel und Registrarwechsel hinzu… es ist ein Irrenhaus. Das ist auch der Grund, warum wir auch längst nicht jede Top Level Domain anbieten.

DNSSEC

Generell halten wir Verbesserungen der Sicherheit des DNS für eine sehr gute Idee und hätten das auch sehr gerne. DNSSEC ist in unseren Augen aber bestenfalls ein erster Schritt in die richtige Richtung – und angesichts der Schwächen von DNSSEC sehen wir das eher als so etwas wie eine „early alpha version“. Die extrem langsame Ausbreitung von DNSSEC stiftet leider keine Hoffnung, dass verbesserte Standards in diesem Bereich dann zügig nachgerüstet werden.

Wir verwenden djbdns als DNS Serversoftware und schätzen diese Software enorm. (Wenn eine Software einem erheblich weniger Schmerzen bereitet als BIND und viel einfacher und logischer in der Benutzung ist und einen über viele Jahre hinweg nie im Stich lässt, wächst sie einem sehr ans Herz.) djbdns hat keinen DNSSEC-Support und es gibt keine Patche die welchen hinzufügen. Das liegt zum Großteil auch daran, dass der Autor von djbdns, Daniel J. Bernstein, seit Jahren fundierte Kritik an DNSSEC übt und seine Zeit und Energie lieber in die Entwicklung eines konkurrierenden Standards namens DNSCURVE steckt.

Wir stimmen der Kritik von Daniel J. Bernstein an DNSSEC in großen Teilen zu und sehen das ähnlich:

  • DNSSEC kann extrem einfach für Denial-of-Service-Attacken (sogenannte DNSSEC Amplification) missbraucht werden, so einfach, dass man sich überlegen könnte Projekte wie LOIC einzustellen, wenn DNSSEC erstmal weite Verbreitung gefunden hat. Wir finden DoS-Attacken reichlich kindisch und können auf ein für jeden frei nutzbares DDoS-Botnetz namens DNSSEC dankend verzichten.
  • DNSSEC ermöglicht eine Technik namens 'NSEC walking'. – DNSSEC hat einen Mechanismus der sagt „zwischen Eintrag A und Eintrag D gibt es keinen Eintrag B oder C“. Der kann ausgenutzt werden, um alle Einträge einer Zone abzufragen. Es gab eine Verbesserung des Standards die dieses Problem nicht beseitigt, sondern die Attacke lediglich für den Angreifer und den Angegriffenen teurer macht. Mit anderen Worten: DNSSEC hat eine offene Hintertür für Zone Transfers. Immer.
  • Die beiden oberen Punkte lassen sich auch so sehen: DNSSEC sorgt dafür, dass ein DNS Server wesentlich mehr Traffic generieren muss (selbst wenn er nicht für Attacken missbraucht wird) und lädt zu trivialen Attacken ein, bei denen der Server mit sehr viel Traffic zugeschüttet würde.
  • DNSSEC bietet ein Fenster für Replay-Attacken nach IP-Wechseln etc. Das kann durch Administratoren vermieden werden, aber wir wissen alle: „Was schief gehen kann, wird irgendwann auch schief gehen.“
  • Es ist bei DNSSEC durch administrative Fehler leicht möglich, seine Zone wegzubomben, wenn man es nämlich versäumt regelmäßig neue Signaturen zu generieren. Wieder etwas aus der Kategorie „Was schief gehen kann…“ – Das ist bei DNSSEC auch schon häufiger vorgekommen. Auch bei sehr großen Unternehmen.
  • DNSSEC verwendet 1024 Bit RSA als kryptographischen Algorithmus. RSA mit dieser Schlüssellänge gilt heute bereits (seit 2003) als unsicher, weil er mit vertretbarem Aufwand gebrochen werden kann. Ein Wechsel auf einen stärkeren Algorithmus findet immer noch nicht statt und angesichts der Langsamkeit mit der DNSSEC sich ausbreitet steht zu befürchten, dass so ein Wechsel sich dann ähnlich langsam durchsetzt.
  • Für DNSSEC wird empfohlen, dass Signaturen auf einem Server generiert werden der nicht mit dem Internet verbunden ist, am besten überhaupt nicht mit einem Netzwerk. – Das ist natürlich total realistisch, dass auf der ganzen Welt jetzt Admins wieder auf's Turnschuhnetzwerk umsteigen um bei jedem Zonenupdate oder mindestens einmal im Monat bevor die Signaturen zu alt werden USB-Sticks zwischen dem sicheren Server™ und ihren DNS Servern hin und her zu tragen. Und natürlich hat jedes Unternehmen einen Tresorraum für so einen Server, zu dem die Putzkraft keinen Zutritt hat. Klar. – Offen gesagt können wir Standards mit solchen Sicherheitsempfehlungen nicht ganz ernst nehmen. Für die Schlüssel von CA-Rootzertifikaten ist das ja ganz sinnvoll, die braucht man auch so selten, dass es realistisch ist, aber für DNSSEC… nun ja.
  • DNSSEC bietet keine Transport-Verschlüsselung, somit schafft es keine Verbesserung der Privatssphäre der User. DNS-Anfragen lassen sich auch bei DNSSEC trivial mitschneiden. Lediglich die Antworten sind (etwas) schwerer zu fälschen.

Und auch wenn es pingelig ist, aber angesichts der bisherigen Liste ist das gerechtfertigt:

  • DNSSEC ist falsch benannt. SEC soll für Security stehen. DNSSEC sorgt aber lediglich für verifizierbare Integrität der Daten im DNS. Das ist nicht gut, denn normale User assoziieren mit dem Begriff Security eben auch Vertraulichkeit von Kommunikationsvorgängen. Auch sonst bietet DNSSEC ein so enttäuschend niedriges Level von Security, dass es den Namen eigentlich kaum verdient.

Wir wären aber durchaus bereit Zonen, bei denen einzelne Kunden es wünschen, auf extra DNS-Server auszulagern, die dann DNSSEC können – es gibt aber eben keinen Patch für unsere bevorzugte DNS Serversoftware. Damit wir uns in eine andere DNS Serversoftware einarbeiten und den übrigen Aufwand in Kauf nehmen müsste man uns aber eher etwas in der Größenordnung von €€€ bis €.€€€ dafür bieten. (Falls als Software nur BIND in Frage käme, eher €€.€€€ um unsere seit Jahren kultivierte Abneigung gegen BIND zu überwinden.)

Finger

Tim Krüger fragt, ob Thimbl bei uns liefe, was im Hintergrund einen Finger-Server braucht. Derzeit haben wir keinen, und eigenständige Daemons, die mit root-Rechten laufen (und darüber hinaus auch Rechte auf dem Home-Verzeichnis von Usern brauchen) sind immer erstmal mit Vorsicht zu genießen („Make your users' home directories allow the Finger user to open them (i.e. chmod a+x)“) und nicht leichtfertig zu installieren, zumal das bedeuten würde, dass User akribisch darauf achten müssen, dass die restlichen Dateien in ihrem Home-Verzeichnis nicht für andere lesbar sind. Als Zwischenlösung könnte man hier ggf. mit Gruppenrechten arbeiten, so dass faktisch nur der Finger-Daemon in die Home-Verzeichnisse schauen kann - ideal ist das aber nicht. Da der Daemon auf Port 79 lauschen muss, kann er auch nicht im Userspace laufen. Interessante Finger-Daemons, die „with security in mind“ designed aussehen, wären z.B. ffingerd und dffingerd. Letzeres sieht insbesondere deshalb interessant aus, weil es Daten aus einer CDB-Datei serviert und nicht direkt in die Home-Verzeichnisse der User schaut. Letztere könnte dann wiederum von einem mit root-Rechten laufenden Cronjob periodisch erstellt werden.

Gitorious

Es steht die Frage im Raum, ob sich Gitorious - das nicht nur ein Online-Service ist, sondern auch als Source vorliegt - auch bei Uberspace.de nutzen lässt. Alle bisher vorgefundenen Installationsanleitungen setzen allerdings root-Rechte voraus, wobei hier wie bei so vielen Tools nicht klar ist, ob das sein muss; auf den ersten Blick ließen sich eigentlich keine Schritte erkennen, die das zwingend nötig machen würden. Als Alternative für ein Multi-User-System, das aber ohne Webinterface kommt, ist bei uns ja schon der Einsatz von gitolite möglich.

inotify

Selten, aber schon mehr als einmal kamen Anfragen nach dem Betrieb eines incron-Daemons. Da jener root-Rechte benötigt, kann er nicht im Userspace laufen. Hier wäre zu prüfen, ob ein Einsatz möglich und auch sicherheitstechnisch unkritisch zu bewerkstelligen ist.

IPv6

Derzeit ermöglichen unsere Scripts „eine IPv6-IP pro Uberspace“. Es wäre zu überlegen, hier auch noch mehrere pro Uberspace zu vergeben, vielleicht pro Domain, oder „einfach so“. Es gab bisher aber erst einezwei Nachfragen danach.

Java

Gelegentlich kommen Fragen nach Java auf, wobei wir da bisher in dem Bereich nichts zu bieten haben (was ein kleines bisschen vielleicht auch dem Umstand geschuldet ist, dass Java unter Systemadministratoren eher einen Ruf als Bloatware hat). Problematisch ist im Allgemeinen, dass die meisten, die nach „Java“ fragen, in Wirklichkeit konkret beispielsweise die Ausführung von Java Server Pages o.ä. meinen, was zum Beispiel einen Tomcat als Application Server bedingen würde. Sowas ist aber mit Shared Hosting praktisch nicht kompatibel, da sämtliche Applikationen dann unter der Tomcat-User-ID laufen und jegliche Rechtetrennung ausgehebelt wäre. Soll heißen, dieser Weg führt zügig in eine Sackgasse, wo wir sagen müssen: Geht aus prinzipiellen Gründen nicht.

Hinzu kommt das andere große Problem, daß serverseitiges Java nummal eine laufende Java Virtual Machine erfordert. Architekturbedingt kann man diese Java Virtual Machine leider nicht bei Bedarf laden, ihre Arbeit verrichten lassen und dann beenden, da das Laden einfach zu lange dauert und außerdem Java Applikationen erst zur Laufzeit optimiert werden, eine frisch gestartete Java Applikation läuft also langsamer als eine bereits länger laufende. Startet man Java ständig neu, laufen die Applikationen dadurch immer mit niedriger Geschwindigkeit. Läßt man die Java Virtual Machine aber laufen, belegt sie permanent Resourcen. Im Leerlauf ist das zwar vor allem RAM aber auch der ist natürlich nicht in unbegrenzter Menge verfügbar. Bei Shared Hosting müssen sich nunmal alle Users eines Hosts die Resourcen teilen und es wäre von daher anderen Usern gegenüber schlicht unfair, wenn einige User permanent große Mengen RAM belegen. Letztlich läuft es darauf hinaus, daß wir schlicht und ergreifend nicht genügend RAM verbauen können um den RAM-Bedarf von Java in einer Shared Hosting Umgebung zu stillen. Ein typischer Uberspace-Server ginge komplett in die Knie, sobald mehr als eine Handvoll User Java Applikationen ausführen würden.

Allerdings kamen vereinzelt auch Fragen in anderen Zusammenhängen, konkret zu PlantUML sowie zum Play Framework, wobei bei letzterem noch die Frage ist, ob hier irgendeine Art von „Deployment“ vorgesehen ist oder ob Applikationen eben einfach auf einem Port X laufen und via Proxy-RewriteRule Requests dahin durchgereicht werden. In beiden Fällen scheint aber keine Integration mit dem Webserver erforderlich zu sein, was wiederum heißt: Eine nackte Installation einer aktuellen JRE könnte hier schon völlig ausreichend sein, damit User beispielsweise java -jar pipapo.jar ausführen können, was dann rechtemäßig komplett innerhalb ihres Uberspaces bliebe. Das dürfte von daher eigentlich nicht so das riesige Problem sein. Müsste mal im Team diskutiert und dann beschlossen werden; vielleicht erstmal auf einem Development-Host umsetzen. Wobei: Im Prinzip kann sich ein User ja eh schon alleine ein JRE runterladen und in seinem Uberspace entpacken. Ginge dann halt auf seine Quota, aber die ist ja groß genug.

Let's encrypt

https://letsencrypt.org/ ist eine Initiative, die für Sommer 2015 erstens eine CA plant, die kostenlose Zertifikate ausstellt, zweitens ein Protokoll (derzeit als Entwurf) bereitstellt, über das die Validierung der Domaininhaberschaft so automatisiert werden kann, dass die Beantragung und Einbindung mit einem einzigen Befehl abgewickelt werden kann, und drittens eben jenes lets-encrypt-Tool, das wir zum jetzigen Zeitpunkt, wo noch keine Details bekannt sind, erstmal für einen Wunschtraum halten.

Wir wurden schon dutzendfach gefragt, ob wir das dann anbieten werden, und das Beste, was wir dazu im Moment sagen können, ist: Leute, es ist noch nicht Sommer 2015. Wir wissen nicht, was da dann faktisch sein wird. Wir sind da genauso neugierig wie ihr. Bisher gibt es die CA nicht, das Protokoll ist nur ein Draft, und vor allem gibt es die sagenumwobene lets-encrypt-Software noch nicht. Das ist eine Idee, und zwar eine, bei der uns bisher noch völlig unklar ist, wie jenes Tool dazu in der Lage sein soll, die nötige Validierung durchzuführen (gemäß Protokoll-Draft kann das ja z.B. über spezielle DNS-Einträge geschehen, auf die das Script aber ja keinen Zugriff hat, weil die ganz woanders liegen, oder über eine Challenge, dass auf der Website eine bestimmte Datei mit einem bestimmten Inhalt abgelegt werden muss, wobei jenes Tool ja nicht wissen kann, wo z.B. der DocumentRoot der Website liegt, und wie es dort was einfügen kann). Vor allem ist unklar, wie das Script - das ja offenbar mit Userrechten ausgeführt werden soll; jedenfalls legt der $- anstelle des #-Prompt das nahe - ein ausgestelltes Zertifikat ohne root-Rechte in die Konfiguration eines Webservers bekommen soll, die typischerweise einerseits nur für root bearbeitbar ist, und vor allem kann ein derartiges Tool ja nicht einmal wissen, welchen Webserver man überhaupt einsetzt, wie der konfiguriert wird, und selbst wenn es da Config-Sets für die verbreitetsten Webserver hat, kann es faktisch ja nicht das konkrete Deployment kennen, wo die Configs auf einem Host liegen, oder wie die dahinkommen, ob sie vielleicht einem Config-Management unterliegen, und so weiter und so fort. Wenn ihr euch https://letsencrypt.org/howitworks/technology/ mal genauer anschaut, werdet ihr sehen, dass das zwar „Domain Validation“ und „Certificate Issuance and Revocation“ abdeckt, aber den spannenden Part des vorher beworbenen Features „Obtain a browser-trusted certificate and set it up on your web server“ überhaupt nicht anspricht. Da dieser Part aber vermutlich nicht durch den Einsatz von Magie gelöst werden kann, ist das erstmal nichts weiter als Marketing-Geblubber, solange wir da nicht etwas Konkreteres sehen.

Das alles sind selbstredend keine vollkommen unlösbaren Probleme, und wir wären auch die letzten, die das ablehnen würden, Verschlüsselung für User einfacher bereitzustellen. Auf den schlichten technischen Ablauf, wie ein Tool wie lets-encrypt dies ganz konkret abwickeln können soll, hat die Website aber derzeit eben keine Antworten. Verfallt doch bitte nicht gleich in Schnappatmung, nur weil da jemand sagt, hey, das wird in Zukunft ganz einfach gehen. Ja, natürlich schauen wir uns das an. Ja, auch wir finden das Projekt interessant. Ja, wenn es technisch machbar ist, wäre für uns auch vorstellbar, dass wir das anbinden. Aber das ist dann eben auch schon alles, was wir heute dazu sagen können.

LibreOffice headless

Es wurde von bisher zwei Usern (im Abstand von Jahren) angeregt, LibreOffice headless bereitzustellen. Die Abhängigkeiten davon sind allerdings ganz erheblich: Da sind dann unter anderem die cdparanoia-libs gefragt (für ein Office-Paket?!), das komplette GStreamer-Framework, und vor allem: Die Installation einer kompletten Java-Umgebung. Vor allem gegenüber Letzterem sträuben wir uns wirklich ganz erheblich, was wir auch schon verargumentiert haben; wir haben die realistische Befürchtung, dass, wenn Java erstmal „da“ wäre, viele Leute das dann auch zu benutzen beginnen (statt im Wiki nach Java zu suchen und dann auf unseren Brainstorming-Artikel zu stoßen, der erläutert, dass wir das nicht wollen, und auch, warum) und dann auch entsprechend Support dazu fordern, weil's dann ja von unserer Seite aus bereitgestellt wird.

Wir haben insofern einvernehmlich im Team beschlossen, dass wir LibreOffice headless auf unseren Hosts nicht zur Verfügung stellen möchten.

memcached

Einige User fragten nach einem memcached. Es dürfte unproblematisch sein, eine Instanz in seinem Uberspace zu starten. Ein globaler memcached erscheint wenig sinnvoll, da die Möglichkeiten für eine Authentifizierung eher mau aussehen. Das wirkt sich indirekt auch auf innerhalb von Uberspaces installierte memcached-Instanzen aus, die über localhost ja frei auch für andere User erreichbar wären. Vernünftigster Einsatz wäre hier wohl über Unix-Sockets, da diese dann Rechte im Dateisystem voraussetzen - einen Unix-Socket innerhalb seines Home-Verzeichnisses abzulegen, wäre daher ein effektiver Zugriffsschutz.

Ärgerlicherweise gibt es z.B. für PHP gleich zwei PECL-Module, nämlich memcache und memcached (siehe auch http://code.google.com/p/memcached/wiki/PHPClientComparison), wobei das neuere noch ärgerlichererweise nur TCP-Verbindungen, aber keine Sockets unterstützt. Das Changelog der aktuellen Beta verrät, dass das wohl kommt, aber eben jetzt noch nicht. Soll heißen: memcached an sich dürfte fix gemacht sein; da fehlt eigentlich nur ein uberspace-setup-memcached und etwas Doku. Die Einschränkung, nur mit Sockets arbeiten zu „dürfen“ (TCP geht natürlich auch, ist dann aber unsicher) dürfte aber vermutlich noch Einiges an Doku zu verschiedenen Programmiersprachen nach sich ziehen.

Update: Inzwischen hat einer unserer User eine Anleitung für die Einrichtung von memcached auf einem Uberspace verfasst.

mod_pagespeed

Vereinzelt kamen Fragen nach dem Einsatz von mod_pagespeed. Sieht auf den ersten Blick unproblematisch aus; vor allem, weil es von Usern selbstständig innerhalb von .htaccess-Dateien ein- und ausgeschaltet und auch weitergehend konfiguriert werden kann.

Allerdings wurden auch in kurzer Zeit mehrere remote ausnutzbare Sicherheitslücken gefunden, und zwar CVE-2012-4001 („makes it possible to trick it into doing HTTP fetches and resource processing from arbitrary host names, including potentially bypassing firewalls“) und CVE-2012-4360 („performs insufficient escaping in some cases, which can permit a hostile 3rd party to inject JavaScript running in context of the site“) - auch wenn die Software nun offiziell als „stable“ deklariert ist, macht sie insofern noch nicht wirklich den Eindruck, dass man sie guten Gewissens auf produktiven Systemen einsetzen wollen würde.

Inzwischen ist Oktober 2014 und wir haben nochmal geschaut. Das letzte Update ist gerade zwei Monate her und fixt erneut zwei Sicherheitslücken von einem Kaliber, das man nicht haben will, CVE-2012-4001 („trick it into fetching resources from other machines. This could be an issue if the HTTP server has access to machines that are not otherwise publicly visible“) und CVE-2012-4360 („would permit a hostile third party to execute JavaScript in users' browsers in context of the domain running mod_pagespeed, which could permit interception of users' cookies or data on the site“). Das festigt leider eher noch unseren Eindruck, dass wir uns mit mod_pagespeed zwar etwas mehr Performance verschaffen könnten, aber zu dem Preis, dass wir uns eine Software mit Lücken eintreten, die ansonsten kein Thema wären.

mod_spdy

Ebenfalls vereinzelt gab es Fragen nach dem Einsatz von mod_spdy, einer Implementierung von SPDY. Allerdings ist das nicht so einfach, wie sich die meisten das vorstellen. Das Grundproblem ist: mod_spdy setzt einen Apache 2.2.4 mit einem gepatchten mod_ssl voraus. Abgesehen davon, dass zumindest unsere CentOS-5-basierenden Hosts einen Apache 2.2.3 haben, würde der Einsatz eines gepatchten mod_ssl auch bedeuten, von den gewohnten Paketupdates des Linux-Distributors abweichen zu müssen. Aber der springende Punkt ist, dass wir ab unseren CentOS-6-Hosts sowieso überhaupt kein mod_ssl mehr einsetzen, sondern Pound als HTTPS-Frontend verwenden - insbesondere, um damit vorzubereiten, künftig ein stabiles, aber wesentlich schlankeres und performanteres HTTP-/HTTPS-Frontend für Applikationen zu haben, die selbst HTTP „sprechen“, was auf node.js-Applikationen zutrifft, genauso wie auf viele Ruby-basierende Deployments, bei denen der Apache, frech gesagt, eher im Weg ist.

Da Google als Hauptentwickler die Entwicklung von SPDY ab 2016 einstellen wird, um stattdessen den Fokus auf HTTP/2 zu setzen, werden wir keine weiteren Versuchen unternehmen, SPDY zu implementieren

HTTP2

Wir haben bisher noch keine praktische Erfahrung mit HTTP/2, haben aber ein Auge drauf und werden versuchen, möglichst frühzeitig damit zu experimentieren.

mod_wsgi

Aus dem Python-Umfeld wird immer mal wieder die Frage an uns herangetragen, warum wir kein mod_wsgi unterstützen bzw. das auch nicht vorhaben. Da die Frage nicht so ganz einfach zu beantworten ist, sammeln wir an dieser Stelle die bisherigen Ergebnisse unserer Beschäftigung mit mod_wsgi.

Zunächst einmal: Wir unterstützen mit FastCGI bereits eine gängige und seit vielen Jahren etablierte Technik, um persistent laufende Applikationen an den Webserver anzudocken. FastCGI startet hierbei eine Applikation „on demand“; sie kann nach Änderungen am Code einfach gekillt werden und wird dann beim nächsten Request neu gestartet. FastCGI trifft dabei einen ganz entscheidenden Punkt: Es ist sprachunabhängig. Perl unterstützt es mit CGI::Fast, unser PHP läuft unter FastCGI, Ruby kann das fcgi-Gem nutzen, und viele verbreitete Frameworks vieler Sprachen unterstützen FastCGI nativ.

mod_wsgi hingegen taugt ausschließlich für Python, und der Standardmodus („embedded mode“) läuft wie folgt:

mod_wsgi works in a similar way to mod_python in that the Python application code will be executed within the context of the normal Apache child processes

Das ist für einen virtuellen oder dedizierten Server sicherlich prima und auch performant, taugt aber keinesfalls für Shared Hosting, bei dem sichergestellt sein muss, dass die Applikationen verschiedener User rechtemäßig separiert sind (was wir mit suEXEC realisieren). mod_wsgi bietet aber auch einen „daemon mode“, der wie folgt beschrieben wird:

This mode operates in similar ways to FASTCGI/SCGI solutions, whereby distinct processes can be dedicated to run a WSGI application […] Daemon processes may if required also be run as a distinct user ensuring that WSGI applications cannot interfere with each other or access information they shouldn't be able to.

Wenn nun also dieser „daemon mode“ so ähnlich wie FastCGI ist, fragt sich, warum man dann nicht einfach gleich FastCGI nimmt. Und hier greift die mod_wsgi-Dokumentation dann auch direkt ein und kommentiert, dass mod_wsgi sowieso nicht für „mass virtual hosting arrangements“ gedacht sei und man dort FastCGI nehmen solle:

Specifically, mod_wsgi is not designed for nor intended for use in over allocated shared mass virtual hosting setups for different users on a single Apache instance. For such mass virtual hosting arrangements, FASTCGI in particular would still be the preferred choice in most situations.

(Nur damit hier keine Missverständnisse entstehen: „over allocated“ hat schnell den Geruch von „überlasteten Maschinen“. „Überbucht“ ist aber nicht das gleiche wie „überlastet“, und Ressourcenverwaltung ist bei Shared-Hosting-Systemen gar nicht vernünftig anders zu machen als in Form von Überbuchung - jedenfalls nicht, solange man für den Shared-Hosting-Account nicht ähnlich viel Geld wie für einen VServer verlangen würde. Eine definierte CPU-Leistung und RAM-Menge kosten ja nicht plötzlich weniger, nur weil sie im Rahmen einer anderen Plattform genutzt werden. Der günstigere Preis entsteht wegen der Überbuchung.)

Selbst wenn wir aber mal ignorieren, dass mod_wsgi selbst sagt, dass in Shared-Hosting-Umgebungen FastCGI besser geeignet sei, gibt es aber noch weitere Argumente gegen einen Einsatz, und zwar vor allem:

mod_wsgi unterstützt nur genau eine Python-Version, mit der dann alle Applikationen ausgeführt werden, und krankt damit genau am gleichen Problem wie z.B. Passenger, das auch nur für exakt eine Ruby-Version funktioniert. Wir stellen sowohl das Distributions-Python (2.4/2.5) zur Verfügung als auch ein selbst kompiliertes Python 2.7 als auch ein selbst kompiliertes Python 3.2 (mit dem mod_wsgi nebenbei noch überhaupt nicht kompatibel ist), und zudem wäre es nicht einmal ein Problem, dass sich User binnen weniger Minuten auch noch ihr eigenes Python kompilieren. Wir müssten uns insofern zwingend auf eine Python-Version festlegen, und selbst wenn wir hier die 2.7 als „vernünftigste“ Option wählen: Was machen wir, wenn User zunehmend 3.2 verwenden wollen? Es wird dann nicht möglich sein, die von mod_wsgi verwendete Variante upzugraden, ohne dass dabei alle bis dahin unter 2.7 laufenden Applikationen kaputtgehen, deren Module in ~/lib/python2.7 installiert wurden und somit nicht mehr gefunden werden, wenn mod_wsgi dann ein Python 3.2 benutzt, das seine Module in ~/lib/python3.2 suchen würde (und davon abgesehen auch keineswegs 100% kompatibel zu 2.7 ist). Das ist schlicht ein strukturelles Problem, wo uns mod_wsgi nicht flexibel genug ist. Und ja: Wir haben auch ein bisschen recherchiert dazu und sind dabei auf Beiträge wie zum Beispiel diesen mit dem Titel app hosting with multiple versions of python gestoßen, der die Situation wie folgt zusammenfasst:

Would it be possible (perhaps in the future) to compile a single mod_wsgi module for multiple versions of Python or have the ability load multiple mod_wsgi modules, one for each Python version, into a single Apache instance? Then, maybe there could be a configuration option or parameter to WSGIDaemonProcess to specify which version to use.

Some thought has been given to that, but non trivial. First off it means no longer supporting embedded mode. Secondly, it means having to have a separate monitor process for each Python version, rather than having Apache parent process do it. That presumes of course that same fork model is used. The alternative is to use fork/exec model and defer loading Python until exec, but then you would just have FASTCGI.
So, if running multiple Apache installations is an issue, it may be easier for you to use FASTCGI solutions instead.

Insofern: Wir halten mod_wsgi für eine prima Sache für den Einsatz auf virtuellen oder dedizierten Servern. Wir halten sie aber nicht wirklich für tauglich, um sie in einem Virtual-Hosting-Umfeld mit verschiedenen Systemusern und verschiedenen Python-Versionen einzusetzen.

Eine mögliche Alternative könnte eventuell uWSGI sein, was darauf verzichtet, das Handling des Python-Interpreters in den Apache zu stopfen und jenem sozusagen ausschließlich das uWSGI-Protokoll beibringt. Die eigentliche Applikation würde dabei vollständig außerhalb des Webservers laufen (idealerweise unter den daemontools) und von jenem via TCP-Port oder Unix-Socket angesprochen werden. Es bliebe aber das Problem, dass hierbei immer noch neu einzurichtende Applikationen im Webserver „registriert“ werden müssten (sprich, es müsste festgelegt werden, welcher URL-Pfad via uWSGI auf welchen Port/Socket geroutet werden soll), was einen Webserver-Restart bedingen würde - was wir möglichst vermeiden möchten, weil damit ein Restart sämtlicher vom Webserver gestarteter Applikationen (also nicht nur der Apache-Prozesse selbst, sondern auch aller PHP-Interpreter und aller sonstigen via FastCGI gestarteten Applikationen) verbunden wäre.

Naheliegender dürfte hier sein, solche außerhalb des Apache-Webservers laufenden Applikationen direkt in Pound anzudocken, das wir als HTTP-Frontend einsetzen. Auch Pound müsste dann zwar nach Änderungen neu gestartet werden, was aber sehr viel schneller ginge und vor allem nicht mit dem Restart von User-Applikationen verbunden wäre. Allerdings beherrscht Pound ausschließlich das HTTP-Protokoll, würde also auch mit den Backend-Applikationen nur per HTTP kommunizieren können, nicht per uWSGI - insofern erscheint uns WSGI selbst bei intensiverer Betrachung zunehmend als Sackgasse. uWSGI könnte mit … --socket 12345 --protocol=http … eine Applikation durchaus als Standalone-HTTP-Server exportieren, die dann von Pound aus direkt angesprochen werden könnte (was wir derzeit noch nicht supporten, aber planen), auf jeden Fall aber auch über eine Proxy-RewriteRule in einer .htaccess-Datei - und das wiederum funktioniert heute schon.

Passenger

Von mehreren Seiten wurde unser Rails-FastCGI-Deployment als „ungewöhnlich“ oder auch als „nicht optimal“ bezeichnet. State of the art scheint hier der Phusion Passenger zu sein. Im Gegensatz zu den meisten anderen Apache-Modulen, die Programmiersprachen in den Webserver einbetten, wurde hier ein Feature namens User switching implementiert, das im Prinzip unseren Sicherheitsvorstellungen durchaus entgegenkommt, da es eine Analogie zu suEXEC darstellt. Es bleibt das ungute Bauchgefühl, dass es prinzipiell nicht als gute Idee erscheint, eine Programmiersprache „in den Webserver“ zu integrieren, sondern hier eine saubere Trennung über eine schmale, definierte API zu nutzen, wie FastCGI das vorsieht. mod_passenger ist in erster Linie dafür da, um die verschiedenen Rails-Prozesse zu spawnen (die dann mit den jeweiligen Userrechten laufen) und das Deployment zu erleichtern. Insofern sehen wir hier im Moment nicht allzu viele Vorteile: Um das Spawning kann sich FastCGI genauso gut kümmern. Das Deployment ist nur auf den ersten Blick einfacher - es erfordert Anpassungen in der VirtualHost-Konfiguration, für die wir dann auch erstmal ein Frontend entwickeln müssten; es erfordert von daher einen Apache-Restart, kann also nicht autark im Userspace konfiguriert werden; und es ist nicht mit unserem derzeitigen Multi-Domain-Setup kompatibel. Dazu kommt, dass Passenger alle Applikationen unter ein- und derselben Ruby-Version ausführt, was für unsere Zwecke schon mal nicht optimal ist, weil wir ja gerade Wert darauf legen, mehrere Versionen sowie RVM anbieten zu können. Die gemeinsame Nutzung von Gems, die schon interpretiert im RAM vorliegen, dürfte vermutlich auch nicht wirklich möglich sein, weil wir eben gerade kein zentrales Rails haben, sondern jeder User sich sein eigenes (in der von ihm benötigten Version) installieren kann.

Möglicherweise implementieren wir Passenger mal auf einem Entwicklungs-Host, lassen ein paar einzelne Ruby-User drauf und sammeln ein wenig Erfahrung damit. Im Moment sieht's aber nicht so aus, als ob es bei uns eine große Zukunft hätte.

Paysafecard

Wir werden gelegentlich nach alternativen Zahlungsmethoden als der Überweisung gefragt. Wir wollen ja aus Gründen nichts mit PayPal, Kreditkarten oder sofortüberweisung.de machen. Was allerdings auf den ersten Blick ganz reizvoll klingt, wäre die Paysafecard, die gegenüber Überweisungen den Vorzug bietet, voll anonym zu sein (man kann sie in Kiosken, in Drogerien, an Tankstellen oder auch an Automaten kaufen). Sie würde insofern gut dazu passen, dass wir ja auch bei der Account-Registrierung keine Daten erfassen. Problematisch ist, dass die Paysafecard als zwielichtig angesehen wird, wobei wir dazu neigen, das nicht als konkretes Problem dieses Anbieters zu sehen, sondern eher als inhärentes Problem jedes anonymen Zahlungsmittels, was beispielsweise auch Bitcoins gerne zum Vorwurf gemacht wird. Auf der anderen Seite ist die Paysafecard ein Prepaid-Produkt, was insofern eine stornofreie Auszahlung bietet, was wiederum für uns zwingende Voraussetzung ist, damit wir unser Prinzip, uns grundsätzlich von jeglichem Mahn- und Inkassowesen fernzuhalten, treu bleiben können. Um diesen Punkt soll es hier aber erstmal nicht gehen.

Nun liegt es vermutlich in der Natur der Sache, dass allen Dingen, die irgendwas mit Anonymität oder zumindest besonderer Datensparsamkeit zu tun haben, etwas Anrüchiges anzuhaften scheint - immer stehen gleich Begriffe wie Pornografie, Drogen, Waffen, Geldwäsche im Raum, ganz schlimm, das muss unbedingt verboten werden. Spannenderweise fällt diese Klappe im Kopf bei den meisten Leuten nicht bei Bargeld, obwohl Drogen an der Straßenecke wohl überwiegend mit Scheinen bezahlt werden, der Zoll bei Grenzkontrollen immer wieder nach Koffern mit Barem sucht und im Sexshop an der Ecke vermutlich auch eher bar bezahlt wird als mit Karte. Dennoch würde kaum jemand, der beim Wocheneinkauf seine Kiste Mineralwasser und die Packung Toast mit ein paar Münzen bezahlt, das Zahlungsmittel für etwas Anrüchiges halten.

Im Grunde geht es hierbei doch um das „auch“. Man kann mit Bargeld auch sozial geächtete Dinge tun, und man kann damit sogar Illegales tun. Das hält aber niemanden davon ab, es mit gutem Gewissen auch für „ganz normale Dinge“ einzusetzen. Umgekehrt kann man mit einer Paysafecard natürlich durchaus auf Pornoseiten oder bei Sportwetten bezahlen. Warum aber sollte man damit nicht auch ganz normale Sachen wie eben zum Beispiel seinen Uberspace damit bezahlen können? Wir haben eine gewisse Tendenz dazu, Zahlungsmittel schlicht und einfach als etwas Wertfreies anzusehen, das nicht deswegen besser oder schlechter ist, weil man damit auch Dinge tun kann, die potentiell anecken, völlig egal ob moralisch oder rechtlich. Und wir finden es problematisch, sich in vorauseilendem Gehorsam deswegen solchen Zahlungswegen zu verweigern. Das wäre nämlich im Grunde nur eine weitere Ausprägung von „Wer nichts zu verbergen hat …“. Man muss auch nichts zu verbergen haben. Privatsphäre ist schließlich nichts Verbotenes.

Was uns an der Paysafecard auf den ersten Blick abschrecken lässt, ist der Umstand, dass man uns dort zumindest im ersten Anlauf nicht direkt als Kunden haben möchte, sondern uns an einen „Aggregations-Partner“ verweist. Wir nehmen das durchaus nicht persönlich; es kann ja für ein Unternehmen durchaus Strategie sein, sich nicht mit tausenden von kleinen Händlern herumschlagen zu wollen, sondern selbst in erster Linie Beziehungen zu Resellern zu pflegen, die sich um die eigentliche Implementierung kümmern. Ärgerlicherweise wurden wir direkt an einen Partner verwiesen, der die Paysafecard direkt neben Kreditkarten, PayPal und ausgerechnet dem besonders absurden sofortüberweisung.de anbietet. Nun könnte man hier genauso argumentieren, dass das ja nur ein „auch“ ist und das dessen Paysafecard-Anbindung deswegen nicht entwertet, aber im ersten Moment ist es für uns schon eine gewisse Abschreckung, weil wir durchaus die geschäftliche Distanz zu Unternehmen wahren möchten, die sich in puncto Datenschutz nicht gerade mit Ruhm bekleckert haben. Ja, natürlich fällt auch uns auf, dass das im Grunde das Gleiche in grün ist, wieso andere eine Zahlung per Paysafecard ablehnen, eben wegen dem, was man damit auch machen kann. Wir sind hier schlicht mit uns selbst noch nicht einig - deshalb steht's hier noch auf der Brainstorming-Seite.

Nachtrag: Alternative/Ergänzung wäre Ukash.

Ports

Gelegentlich kommt es vor, dass User eigene Dienste auf eigenen Ports betreiben wollen, insbesondere dann, wenn WebSockets im Spiel sind (von denen die meisten User annehmen, dass das doch „eigentlich HTTP“ wäre und somit über eine Proxy-RewriteRule laufen könnte, was aber nicht stimmt). Derzeit machen wir das auf Anfrage per Hand, insbesondere um zu verhindern, dass Daemons, die nicht aktiv von Usern installiert wurden (sondern von einem Angreifer, der sich eine Lücke in einem von einem User installierten CMS aus dem 20. Jahrhundert zunutze gemacht hat), von außen erreichbar sind und Uberspace-Hosts unbemerkt zu Botnet-Kontroll-Hosts machen. Das ist aber auf lange Sicht nicht allzu vernünftig zu verwalten, zumal die Ports beim Deaktivieren eines Uberspaces ja auch wieder dichtgemacht werden sollten. Es wäre also sinnvoll, die offenen Ports pro User/Host in einer Datenbank/Datei zu verwalten und daraus automatisch iptables-Regeln zu generieren. Wäre dieser Schritt erstmal gemacht, ließe sich ggf. auch ein Script in der Art uberspace-open-port 12345 realisieren, das dann (mittels sudo mit Passworteingabe) einen Eintrag in der Portliste des Users ermöglicht, der dann in iptables-Regeln umgesetzt wird. Allerdings ist so ein sensibler Teil der Konfiguration immer etwas haarig zu automatisieren; fürs erste ist das nur mal eine lose Idee, die dann noch auf Praktikabilität hin untersucht werden müsste.

RZ-Führungen

Im Zuge unserer offenen Kommunikation wäre evtl. vorstellbar, für interessierte User RZ-Führungen anzubieten und zu zeigen, wo die Server physisch stehen und mal ein bisschen die Räumlichkeiten, Zugangskontrolle, Dieselgeneratoren etc. zu zeigen. Der Erkenntnisgewinn dürfte hier zwar eher gering sein, weil im RZ natürlich „nur gucken, nicht anfassen“ gilt, aber erfahrungsgemäß fänden es viele durchaus spannend, mal reinzuschauen. Tendentiell dürfte das beim Standort rh-tec etwas einfacher sein als beim Standort Plus.line. Fraglich wäre, ob solche Führungen ggf. kooperativ mit dem RZ gemacht werden könnten, um auch einen Blick auf die Räume werfen zu können, in denen wir kein Equipment haben. Dürfte dann aber vermutlich was kosten; wir können ja nicht regelmäßig rh-tec-Personal „for free“ damit beschäftigen - wenn diese denn überhaupt dazu bereit wären; mal anfragen.

Offene Frage hierzu vor allem: Haftung? Hier müssten dann ggf. schriftliche Haftungsübernahmeerklärungen zusammen mit Ausweiskopien eingesammelt werden, um den Sicherheitsvorgaben des RZs Genüge tun zu können.

SFTP-Zugänge

Gelegentlich kommt der Wunsch auf, mehrere SFTP-Zugänge zu einem Uberspace bereitzustellen. Problematisch ist hierbei grundsätzlich, wenn dabei solche „Unter-User“ Dateien hochladen, die dann im Kontext des betreffenden Uberspaces ausgeführt werden, sprich, mit den entsprechenden Rechten des Haupt-Users. Während wir grundsätzlich empfehlen, hier dann lieber komplett separierte Uberspaces anzulegen, damit auch bei der Ausführung von Scripts eine saubere Rechtetrennung durchgehalten wird. Es müsste von daher sichergestellt werden, dass die zusätzlichen Zugänge zwar Zugriff auf Unterverzeichnisse innerhalb des Home-Verzeichnisses des betreffenden Uberspaces haben (und dort dann via chroot eingesperrt werden), aber keinesfalls irgendwo schreiben dürfen, wo es hinterher vom Webserver ausgeführt wird.

Derzeit haben wir für dieses Problem keine Lösung, sondern nur Ideen. Die vielversprechendste ist dabei, das SSH-Subsystem „sftp- internal“ zu benutzen und mit der Chroot-Funktionalität von OpenSSH zu kombinieren. „sftp-internal“ hat den Charme, dass man nicht für jeden User haufenweise Binaries und Libraries in sein Chroot-Verzeichnis kopieren (oder hardlinken) muss. Aber: Das Home-Verzeichnis des Users und alle Verzeichnisse auf dem Weg dorthin müssen hierbei root:root gehören, was schon mal heißt: Sie können keine Unterordner im normalen Home-Verzeichnis sein. Es ergibt aber auch nicht viel Sinn, sie *völlig* autark zu haben, denn dann wäre es einfacher, sich schlicht einen separaten Uberspace zu klicken, und damit hat man ja einen eigenständigen Zugang. Es geht aber ja darum, dass die Unter-User vom Haupt-User jeweils abgeschottet sind, jener aber eine Art Master-Zugang hat und in all ihre Verzeichnisse reinkommt. Eine Möglichkeit könnte dabei sein, solche ausgelagerten Verzeichnisse mittels eines bind mount innerhalb des Home-Verzeichnisses einzuklinken. Da hierbei Userspace-Tools vonnöten wären, die dann mit sudo hantieren, müsste hier dann ganz besonderer Augenmerk auf Sicherheit gelegt werden.

Statistiken

Im Lauf der Zeit sollten wir die offene Kommunikation möglicherweise auch im Bereich Statistiken ausweiten. Vorstellbar wären hier beispielsweise Angaben zu „wieviele User gibt es“, „wie verteilen die sich auf die Hosts“, eine zeitliche Kurve über die Anmeldungen, möglicherweise auch Kurven, wieviel Leute durchschnittlich und maximal für einen Uberspace zahlen - wobei das auch dazu führen könnte, dass User versuchen, ihren Preis dem Durchschnitt anzupassen, weil es offenbar zum menschlichen Bestreben gehört, sich immer möglichst unauffällig irgendwo in der Mitte gruppieren zu wollen. Das könnte im Hinblick darauf, dass wir die Preisbildung ja eigentlich an die Wertschätzung koppeln, möglicherweise nach hinten losgehen - auf der anderen Seite wollen wir aber ja einen „normalen“ Umgang mit Geld durchaus auch fördern und es nicht als etwas ansehen, „worüber man nicht spricht“. Mal schauen, was hier so sinnvoll sein könnte und auch interessant für die User, wobei es eigentlich nie einen Grund gibt, Informationen nicht öffentlich zu machen, selbst wenn sie nur für einen oder auch gar nur für uns selbst interessant sind, solange sie anonymisiert sind.

Auch noch zum Thema Statistiken: Simon wünscht sich sowas wie einen munin. Wäre durchaus nicht schlecht und würde auch gut zu unserer offenen Außenkommunikation passen, Leistungsauswertungen der Maschinen öffentlich anzuzeigen - auch als Kontrapunkt zu den Providern, die mit „nur X User pro Host“ argumentieren, obwohl die Userzahl ohne Relation zur Ressourcennutzung und überhaupt zur Leistungsfähigkeit der Maschine praktisch gar nichts aussagt - mit Laststatistiken könnten wir gut kommunizieren, dass wir unsere Maschinen nur in vernünftigem Maß auslasten.

Umbuchen

Es soll möglich werden, Geld von einem Uberspace auf einen anderen Uberspace umzubuchen, mit dem Ziel, dass User, die mehrere Accounts haben, nur eine Überweisung tätigen müssen und das Guthaben dann nach Gutdünken verteilen können. Denkbar wäre außerdem, einen Schlüssel zu hinterlegen, nach dem bei Aufbuchungen eingehendes Geld automatisch weiterverteilt wird.

Umbuchen lässt sich jetzt im Dashboard unter dem Punkt „Finanzielles“ regeln. Eine automatische Weiterverteilung bei Zahlungseingang steht noch als Idee im Raum.

Umzüge

Bei Plus.line haben wir derzeit 25% Ökostrom; bei rh-tec dagegen 100%. Neue Hosts kommen schon aus Platz- und Klimatisierungsgründen zu rh-tec, aber davon unabhängig stellten schon mehrere User die Frage, ob sie ihren Uberspace „zum Ökostrom-Standort umziehen“ können. Da unsere Usernamen ja global eindeutig sind (nicht nur pro Host), gäbe es im Prinzip tatsächlich die Möglichkeit, Accounts 1:1 zu migrieren, wobei sich die numerische User-ID ändern würde, aber eben nicht die alphanumerische, womit auch Pfade etc. erhalten bleiben. Statt einer speziellen Plus.line-zu-rh-tec-Umzieh-Aktion würde sich hier eher ein generisches Tool anbieten, das im Grunde auf einem anderen Host einen gleichnamigen User anlegt, die Daten via rsync über SSH überträgt, die MySQL-Datenbanken dumpt und auf dem anderen Host wieder einspielt, etc.pp. - wobei es hier auch noch diverse andere Punkte gibt, die hier Beachtung finden müssten, z.B. ob ein User eine eigene svscan-Instanz hat, wo dann erstmal Dienste gestoppt werden müssten, um Daten in einem konsistenten Zustand syncen zu können; außerdem liegen einige Daten außerhalb des Uberspaces (z.B. die Webalizer-Auswertungen); soll heißen: So ganz einfach ist das alles nicht, wenngleich machbar. Die Frage ist halt, ob die Nachfrage danach so groß ist, dass es lohnt, hier umfangreich Zeit zu investieren. Nebenbei wäre mit einem solchen Umzug zwingend auch ein IP-Wechsel erforderlich (sowohl IPv4 als auch IPv6), was ggf. im DNS vorbereitet werden will, und vor allem ist hier ja auch nicht gesagt, dass DNS für die aufgeschalteten Domains bei uns liegt …

Usertreffen

Im Zusammenhang mit RZ-Führungen kam die Idee auf, gelegentlich Usertreffen zu veranstalten, wobei da nicht so richtig klar ist, was das bringen soll, außer halt „nette Leute treffen“ - aber das könnte ja auch schon ein Grund sein. :-) Wir haben halt einerseits kein Budget dafür, um Leute einzuladen; andererseits sollte es unsererseits aber auch nicht als Einnahmequelle angesehen werden; ist ja keine Fachtagung oder sowas. Irgendwas Selbstkostenmäßiges möglicherweise; einfach mal als Idee im Hinterkopf halten.

XMPP

Es wird gewünscht, dass Uberspace.de auch XMPP („Jabber“) anbietet. Inhaltlich sind wir da voll dabei: Offenes Protokoll, dezentral, gute Verschlüsselungsmöglichkeiten sowohl auf Transportebene als auch end-to-end. Mögliche Optionen:

  • User kompilieren sich selbst einen XMPP-Server und lassen ihn auf einem beliebigen hohen Port laufen, für den wir dann punktuell die Firewall öffnen. Vorteil: Maximale Flexibilität, was Wahl des Servers und dessen Konfiguration angeht. Nachteile: Verbraucht mehr Ressourcen als eine zentrale Instanz; erfordert wesentlich mehr Einarbeitung durch die User; globales Wildcard-TLS-Cert kann nicht mitgenutzt werden.
  • Zentraler XMPP-Server pro Uberspace-Host. Vorteil: Ressourcenschonend; globales Wildcard-TLS-Cert kann mitgenutzt werden; einfacher zu nutzen. Nachteil: User können Wahl des Servers und auch seiner Plugins nicht mitbestimmen; erhöhter Administrationsaufwand für uns; spezielle Wünsche z.B. bestimmte Transports können ggf. nicht erfüllt werden; Frontend zur Einrichtung von Domains/Usern erforderlich, da User hier dann keinen direkten Zugriff auf die Konfiguration des XMPP-Servers haben können. Es ist fraglich, inwieweit hier IP-Anonymisierung in Logfiles stattfinden kann, um Datenschutzanforderungen zu genügen.
  • Zentraler XMPP-Server. Im Grunde identische Vor- und Nachteile. Noch ressourcenschonender; stärkere Zentralisierung muss aber nicht unbedingt gut sein (insbesondere nicht unter dem Aspekt „wenn's mal ausfällt, ist gleich alles weg“).

Außerdem steht die Frage nach Support via XMPP im Raum. Prinzipiell könnte das wohl auch mit einer Art Role-Account geleistet werden, wobei die Unterstützung vieler Clients für das Priority-Flag eines Realms relativ mau ist und wir insofern das Risiko eingingen, dass Anfragen bei jemandem „versanden“, der in Wirklichkeit gerade gar nicht am Rechner ist. Derzeit ist die Nachfrage aber ohnehin gering; der Fokus liegt hier erstmal weiterhin auf dem Ticketsystem.

Yubikey

FreXxx wünscht sich Yubikey-Support. Bei einem Yubikey handelt es sich um ein USB-Device, das zur Authentifizierung verwendet werden kann, wahlweise anstelle oder aber ergänzend zu einem Passwort.

Die Implementierung des PAM-Moduls lässt derzeit noch zwei Fragen offen:

  1. Ist eine Opt-In-Implementierung möglich, sprich, gibt es einen Fallback auf die normale Passwort-Authentifizierung, wenn ein User keine Yubikey-Konfiguration hat? https://github.com/Yubico/yubico-pam/wiki/YubikeyAndSSHViaPAM formuliert: „individual users have the ability to configure yubikey token ID assigned to them“ (Hervorhebung durch uns), was darauf hinweisen könnte, aber auch einfach nur ungeschickt ausgedrückt worden sein kann (bei der Google-Two-Factor-Authentifizierung las sich das auch erst anders, letztlich war dann aber ein Patch vonnöten).
  2. Ist die Konfiguration kompatibel mit dem, was wir bereits produktiv einsetzen? Die Dokumentation sagt: „Change challenge-response passwords yes to challenge-response passwords no“, was das genaue Gegenteil der Einstellung ist, die die Google-Two-Factor-Authentifizierung braucht. https://github.com/Yubico/yubico-pam/wiki/ReadMe hingegen legt nahe, dass das nur dann sein muss, wenn man das PAM-Modul mit verbose_otp benutzt, was man ohnehin nicht tun sollte. Hier käme es also auf einen Test an.

Fraglich ist außerdem, ob es viel Sinn ergibt, Zeit in die Implementierung eines Produkts zu stecken, das so gut wie niemand besitzt (wir selbst haben keins, und wir kennen - abgesehen jetzt von FreXxX - nicht mal irgendjemanden, der einen besitzt) - und noch dazu ist das Stück Hardware mit rund 25 Euro nicht so ganz preiswert. Schließlich und endlich gibt es auch noch weitere Zwei-Faktor-Modelle, die ohne zusätzliche Hardware arbeiten, wie z.B. http://www.duosecurity.com/ mit einem Telefon-Callback, was auch eine ganz coole Idee ist.

brainstorming.txt · Zuletzt geändert 2015/02/10 14:46 von uber