phoenitydawn

July 28th, 2014

systemd und seine Auswirkungen

Posted by Dunedan in Computer, Debian, Linux

Seit neuneinhalb Jahren nutze ich Debian und war immer ausgesprochen zufrieden damit. Als technisch versierterer Benutzer kann man ja dank testing und unstable ausreichend frische Softwareversionen nutzen. Der neueste Schrei ist nun der Ersatz von SysVinit durch systemd als Init-System. Da es bei meinem Setup noch kleinere Haken mit systemd gibt und mir systemd nach wie vor etwas ungeheuer ist, hatte ich vor so lange wie möglich bei SysVinit zu bleiben.

Die letzten Wochen mehrten sich dann aber mehrere Probleme:

  • Mein Notebook zeigte nach dem starten kein Bild mehr an, wenn beim starten der Splash von Plymouth aktiv war.
  • Auf sämtlichen Rechnern wird das tun-Modul für openvpn nicht mehr automatisch geladen, sondern muss per Hand geladen werden.
  • Suspend-to-RAM und Suspend-to-Disk waren im “Verlassen”-Bildschirm von KDE nicht mehr zu finden und das schließen des Notebookdeckels legte ihn auch nicht mehr schlafen.

Insbesondere der letzte Punkt nervte mich und ich machte mich auf die Suche nach der Ursache. Die fand ich auch recht schnell in Form eines Debian Bugreports: #752413 kde-workspace-bin: upower-1.0 transition. Spannend dabei die Aussage im letzten Kommentar:

It does mean as a consequence, that kde will depend on systemd/logind
for suspend/hibernate support.

Kurz entschlossen habe ich mein Notebook mal mit systemd neu gestartet und siehe da: Alle oben genannten Probleme waren mit einem Mal verschwunden. Das ärgert mich, denn es zeigt, dass SysVinit in Zukunft wohl kaum mehr vernünftig als Init-System für Desktoprechner verwendet werden können wird, wenn sogar jetzt schon ohne systemd Probleme auftreten, die mit ihm nicht auftreten.

January 2nd, 2013

Rate-Limiting requests to CouchDB using nginx

Posted by Dunedan in Computer

Some time ago I had the requirement to limit the number of requests per IP to a CouchDB-instance. I couldn’t find an option for CouchDB to achieve that, but as communication with CouchDB is based on HTTP-requests I thought that it should be possible to use nginx as reverse proxy with rate-limiting capabilities for CouchDB. The CouchDB-wiki lists some basic steps how to use nginx as reverse proxy, but rate limiting isn’t mentioned there.

Beside the actual rate limiting I noticed that nginx won’t work, because it doesn’t support chunked request-bodies out of the box, which CouchDB seems to rely onto. But to the rescue there is a nginx module called ngx_chunkin, which adds chunkin support to nginx. To get that module in Debian you need to install nginx-extras from the repository (available since squeeze-backports). The configuration of that module is straight forward as described on the wiki page. All you have to do is to put the following code snippet into the server-context of your nginx configuration:

        chunkin on;

        error_page 411 = @my_411_error;
        location @my_411_error {
                chunkin_resume;
        }

Having solved that issue, doing the actual rate limiting was the next step. Therefore nginx ships the module ngx_http_limit_req_module. All I had to do was to configure a zone for the limited requests in the http-context of the configuration:

limit_req_zone $binary_remote_addr zone=couchdb_write:10m rate=10r/s;

and the logic what to rate limit (writing requests in my case) into the server-context:

        location / {
                # POST, PUT, DELETE ... requests will get rate limiting
                if ($request_method !~* GET) {
                        rewrite ^(.*)$ /throttled$1 last;
                }

                proxy_pass       http://127.0.0.1:5985;
                proxy_buffering  off;
                proxy_set_header Host $host;
                proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        }

        location /throttled {
                internal;
                limit_req        zone=couchdb_write burst=10000;
                rewrite /throttled(.*) $1 break;
                proxy_pass       http://127.0.0.1:5985;
                proxy_buffering  off;
                proxy_set_header Host $host;
                proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        }

So if you put together the chunkin support and the rate limiting, you’ll get the following piece of configuration for a server which does rate limiting of writing CouchDB-requests using nginx:

limit_req_zone $binary_remote_addr zone=couchdb_write:10m rate=10r/s;

server {
        listen 5984;

        chunkin on;

        error_page 411 = @my_411_error;
        location @my_411_error {
                chunkin_resume;
        }

        location / {
                # POST, PUT, DELETE ... requests will get rate limiting
                if ($request_method !~* GET) {
                        rewrite ^(.*)$ /throttled$1 last;
                }

                proxy_pass       http://127.0.0.1:5985;
                proxy_buffering  off;
                proxy_set_header Host $host;
                proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        }

        location /throttled {
                internal;
                limit_req        zone=couchdb_write burst=10000;
                rewrite /throttled(.*) $1 break;
                proxy_pass       http://127.0.0.1:5985;
                proxy_buffering  off;
                proxy_set_header Host $host;
                proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        }
}

I really enjoyed figuring that out, because it was a lot of fun to be able to use a great tool (nginx) to extend another great tool (CouchDB), because they’re using the same protocol (HTTP).

April 17th, 2008

Rechnermigration

Posted by Dunedan in Computer, Debian, Linux

Schon lange hatte ich vor meinen Desktoprechner komplett neu zu bespielen, dabei die komplette Festplatte zu verschlüsseln und auf 64Bit umzusteigen. Gestern nahm ich dies nun endlich mal in Angriff und ich muss sagen ich bin mal wieder entzückt von Linux. Insbesondere natürlich von Debian. Es sind noch keine 24 Stunden seit dem Beginn der Neuinstallation vergangen und von der Benutzung her merkt man dem System nichts an, was auf eine komplett neue Installation schließen lassen würde.
Wichtig dafür war natürlich, dass sämtliche persönlichen Daten und persönlichen Einstellungen erhalten bleiben. Glücklicherweise liegen die unter Linux alle zusammen schön im Nutzerverzeichnis des Benutzers, sodass ich einfach nur ein Backup dieses Verzeichnisses auf meinen Rechner zurückkopieren musste. Das ging wider Erwarten auch erstaunlich gut. Selbst fremdsprachige Zeichen in Dateinamen (französisch, russisch, …) blieben erhalten (ein plus für Unicode 🙂 ).
Was anzupassen blieb waren ein paar systemweite Einstellungen. So wollte der Drucker neu konfiguriert werden und auch der Flashplugin erforderte eine andere Herangehensweise als unter 32Bit. Immerhin funktioniert Flash und das ohne großen Frickelaufwand!
Ich bin auf jeden Fall trotz einiger kleinerer Problemchen die bisher auftauchten (Rechner startete auf einmal nicht mehr weil’s mir die initial ramdisk zerhauen hatte, …) sehr zufrieden wie das alles so gelaufen ist.

Endlich habe ich keinerlei unverschlüsselte Festplatte mehr in meinem Haushalt. 🙂

December 4th, 2007

Lästerei

Posted by Dunedan in Computer, Linux

Heute will ich mal ein bisschen lästern. Aber alle potenziellen Leser können beruhigt sein, denn ich habe nicht vor über konkrete Personen zu lästern. Genauergesagt will ich über gewisse Linuxdistributionen lästern. Und zwar über die aus der Red Hat-Ecke. Als Beispiel nehme ich Fedora und CentOS, da ich beide vor kurzem benutzt habe, aber bei Redhat Enterprise Linux (RHEL) ist die Problematik natürlich die gleiche. Und zwar will ich über das Paketmanagement lästern. Es kann durchaus auch sein, dass ich einfach nur aus Unwissen lästere, aber ich bin froh über jeden Wissenszuwachs. Wer also Ergänzungen zu meinen Ausführungen hat, den bitte ich diese doch in den Kommentaren niederzuschreiben.
Also, Thema Paketmanagement: Ich bin ja nun eher der Debianer. Und unter Debian ist alles ganz toll. Das Paketmanagement dpkg ist sehr ausgereift und es gibt sehr komfortable Tools zur Installation und zum Management von Software. Natürlich gibt es grafische Tools, doch ich ziehe ein Kommandozeilentool wie aptitude vor, da ich es durch die Keyboardnavigation bedeutend komfortabler als irgendwelche grafischen Tools finde. Aber das ist Geschmackssache. Bis auf den Fall wenn man ohne grafische Oberfläche dasitzt. Beispielsweise bei Servern oder weil, aus welchem Grund auch immer, keine grafische Oberfläche mehr starten will.
Im Rahmen meines Hiwi-Jobs arbeitete ich bisher mit Fedora 7. Dort konnte ich kein auch nur ansatzweise komfortables Kommandozeilentool finden, was vor allem dann unpraktisch ist wenn ein Sicherheitsupdate das grafische Tool names pirut unbrauchbar macht, wie mir vor kurzem passiert ist (glücklicherweise behob ein weiteres Update ein paar Tage später das Problem wieder). Da bleibt dann nur sowas unkomfortables wie yum übrig. Heute dann der nächste Knaller. Mein Rechner hing grade nicht am Internet und ich wollte pirut starten. Ging nicht, da kein Internet verfügbar. Das einzige was ich machen konnte war pirut gewaltsam zu beenden.
Was mich an pirut auch ziemlich stört ist das man Abhängigkeiten von Paketen nicht vernünftig angezeigt bekommt. Erst nachdem man Pakete zur Installation ausgewählt hat und auf “weiter” klickt ist pirut der Meinung einem mitteilen zu müssen dass es gerne noch dieses und jenes Paket installieren wolle.
Was soll so ein Schrott? Und wie administriert man vernünftig einen Server der mit einer RPM-basierten Linuxdistribution läuft? Hab ich da vielleicht irgendein Tool übersehen?
Wie dem auch sei. Ich finde es einfach nur peinlich was da an Paketmanagement-Werkzeugen mitgeliefert wird. Als Konsequenz wird morgen auf meinem neuen Arbeitsrechner (den ich heute gekriegt habe), erstmal Debian installiert. \o/