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 …

Devotionalien

Wir haben inzwischen Sticker - einfach mal einen Blick ins Blog werfen.

Außerdem haben wir T-Shirts, mit inzwischen vier Motiven. Die gibt's aber nicht zu kaufen, sondern wir tragen die einerseits natürlich selbst (damit man uns auf Konferenzen etc. auch erkennen kann), und wir verschenken sie andererseits an User, von denen wir finden, dass sie ein T-Shirt verdient hätten. Sei es, weil sie uns z.B. auf coole Ideen gebracht haben, kritische Probleme aufgedeckt haben, die wir dann fixen konnten, oder die sich sonst irgendwie um Uberspace.de verdient gemacht haben. Hier gilt aber ganz generell: Wir kommen dann von uns aus auf dich zu.

Domains und DNS

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.

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.

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

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.

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. (Das gehört inzwischen wohl auch zu Paysafecard und wird eingestellt.)

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. Wir haben inzwischen bei allen unseren Standorten 100% Ökostrom.

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.

Es gab auf dem 31c3 ein erstes, spontanes Usertreffen und wir sind auch weiteren Treffen auf Veranstaltungen nicht abgeneigt. Falls wir uns spontan dazu entschliessen, kündigen wir das mit etwas Vorlaufzeit auf Twitter an. Eventuell haben wir auch ein paar Devotionalien dabei.

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: 2016/04/28 18:10 von uber