Springe zum Inhalt

4

Mittlerweile gibt es eine unüberschaubare Anzahl an Chat-Programmen und Chat-Anbietern. Um den Konversationen der Freunde folgen zu können müssen auf dem heimischen PC mehrere Programme installiert und auf dem Smartphone soll für jeden Anbieter eine eigene App installiert werden. Warum nicht einfacher? Einen eigenen Server aufsetzen, welcher das genormte Protokoll XMPP spricht und mit Gateways zu den entsprechenden Diensten erweitert werden kann: Prosody. ...weiterlesen "Prosody: Chatserver mit Anbindung zu G+, FB, Twitter und IRC"

3

Electrum ist ein Desktop-Client zur Verwaltung eines Bitcoin-Wallets, der sich zunehmender Beliebtheit erfreut. Bis zu Linux Mint 17 war er in den offiziellen Paketquellen von Mint enthalten, wurde aber leider entfernt, da sich wohl kein Maintainer gefunden hat, der die enthaltene Uraltversion ersetzt. Trotzdem ist eine Installation unter Linux Mint 18 relativ einfach möglich. ...weiterlesen "Linux Mint 18: Electrum installieren"

10

Primär ist der Einsatz der kostenlosen Let's Encrypt Zertifikate für Webseiten vorgesehen. Wie erzeugt man nun aber ein Zertifikat für einen Mail- bzw. IMAP-Server, auf dem vielleicht gar kein Webserver läuft? Auch das ist in wenigen Schritten möglich. Ich verwende hier certbot zur Kommunikation mit Let's Encrypt, da er für Debian in den Jessie-Backports enthalten ist.

In der Beschreibung hier verwende ich <Domain-Name> für alle Stellen, an der die Domain des eigenen Mailservers eingetragen werden muss. ...weiterlesen "Let’s Encrypt Zertifikate für Dovecot und Postfix"

Mit dem WordPress-Plugin Cachify steht eine Lösung zur Verfügung, die ein einfaches Zwischenspeichern von dynamisch erzeugten Webseiten bietet. Die Inhalte können mit unterschiedlichen Methoden zwischengespeichert werden. Unterstützt werden APC, Disk, DB und Memcached (nur mit Nginx). Da ich hier Nginx einsetze, bietet sich Memcached als schnellste Variante an. Wie Cachify und Nginx dann zu konfigurieren sind kann im Cachify-Wiki nachgelesen werden.

Die erfolgreiche Konfiguration läßt sich einfach überprüfen: es wird an das Ende der jeweiligen Webseite ein HTML-Kommentar von Cachify eingefügt. Ist dieser im Quelltext der Seite vohanden, dann wurde die Seite aus dem Cache, bei mir also von Nginx/Memcached ausgeliefert.

<!-- Cachify | http://cachify.de
Memcached @ 08.07.2016 13:25:07 -->

Nach ein paar Tests stellte sich heraus, dass genau eine Seite hier aus dem Blog nicht zwischengespeichert wird. Nach langem Suchen fand ich dann den Grund: der Seitenquelltext ist größer als 1 MB (bedingt durch sehr viele Kommentare auf der Seite) und Memcached speichert in der Standardkonfiguration nur Items bis zu einer Größe von 1 MB.

Ab der Version 1.4.2 von Memcached kann diese Größe konfiguriert werden. Unter Debian 8 fügt man dazu in die Datei /etc/memcached.conf eine neue Zeile mit z.B.

-I 2m

ein. Damit wird die Maximalgröße eines Items auf 2 MB angehoben. Anschließend muss Memcached neu gestartet werden. Mit folgendem Kommando lassen sich die aktuellen Einstellungen eines laufenden Memcached anzeigen:

# echo "stats settings" | netcat localhost 11211
STAT maxbytes 134217728
STAT maxconns 1024
STAT tcpport 11211
STAT udpport 11211
STAT inter 127.0.0.1
STAT verbosity 0
STAT oldest 0
STAT evictions on
STAT domain_socket NULL
STAT umask 700
STAT growth_factor 1.25
STAT chunk_size 48
STAT num_threads 4
STAT num_threads_per_udp 4
STAT stat_key_prefix :
STAT detail_enabled no
STAT reqs_per_event 20
STAT cas_enabled yes
STAT tcp_backlog 1024
STAT binding_protocol auto-negotiate
STAT auth_enabled_sasl no
STAT item_size_max 2097152
STAT maxconns_fast no
STAT hashpower_init 0
STAT slab_reassign no
STAT slab_automove 0
STAT lru_crawler no
STAT lru_crawler_sleep 100
STAT lru_crawler_tocrawl 0
STAT tail_repair_time 0
STAT flush_enabled yes
STAT hash_algorithm jenkins
END
^C

Unter item_size_max ist die neue Einstellung zu erkennen. Alternativ kann auch phpMemcachedAdmin verwendet werden, um den Inhalt der Caches anzuzeigen.

Knapp zwei Jahren wurde dieses Blog durch HHVM angetrieben. Obwohl die Unterstützung vieler PHP-Funktionen in der Vergangenheit nicht immer zufriedenstellend war, so war die Geschwindigkeit doch immer ein Hauptvorteil von HHVM. Mit zunehmender Serviceanzahl, drängte sich jedoch ein Problem immer mehr in den Vordergrund: viele Dienste benötigen einen Cronjob, welche ebenfalls in PHP realisiert sind.  HHVM per CLI ist einfach zu speicherhungrig. Den Speicherhunger kann man schön in folgender Grafik erkennen:

HHVM PHP memory-day

In der linken Hälfte sieht man die HHVM-Cronjobs immer schön als Zacken. Nach der Umstellung auf PHP-FPM rechts ist wieder jede Menge Luft.

Wirklich schwierig war die Umstellung nach der Installation von PHP mit "apt install php5-fpm" (und einiger weiterer php5-Pakete) nicht. In jeder Host-Definitionsdatei für NGINX unter /etc/nginx/sites-enabled hatte ich bereits einen Eintrag "include hhvm.conf". Dieser wurde einfach durch "include php5-fpm.conf" ersetzt, wobei diese Datei folgenden Inhalt hat:

location ~ \.php$ {
	include snippets/fastcgi-php.conf;
	fastcgi_pass unix:/var/run/php5-fpm.sock;
}

Nach einem "nginx -s reload" wird dann sofort PHP benutzt. Einige dauernd laufenden Dienste auf PHP-Basis mussten noch mit einem "systemctl restart ..." neu gestartet werden und fertig war die Umstellung.

Von Seiten der Zugriffszeit erwarte ich eigentlich keine großen Änderungen, da die generierten Seiten jetzt schon dauerhaft per Memcached ausgeliefert werden. Eine Statistik der durch Google in den Webmaster-Tools gemessenen Zeiten hänge ich für einen späteren Vergleich mal an:

GWT blog.tausys.de Crawling 2016-07-05 22-50-34