Sven's Blog – Die alltäglichen Kostbarkeiten

Seit geraumer Zeit nutze ich extrem gern die Pandas Data Analysis Library um Daten zu importieren/exportieren und aufzubereiten. Einen ganz guten Überblick über die Grundfunktionen erhält man z.B. mit diesem Pandas Cheat Sheet (PDF).

Was mir dort bisher noch gefehlt hat war ein gutes Modul, um einen schnellen Überblick über die Daten eines Datasets zu erhalten. Besonders Unikate, Duplikate, Korrelationen und Anomalien möchte man in der Regel möglichst schnell identifizieren, bevor man sich tiefgehender mit einem Datensatz auseinandersetzt.

Für die sogenannte Exploratory Data Analysis (EDA) gibt es mit Pandas-Profiling ein großartiges Modul, um sich einen detaillierten Report über ein DataFrame ausgeben zu lassen.

Hier mal ein Pandas-Profiling Report als Beispiel vom DataSet des NPGEO Corona - RKI Corona Bundesländer

Feature Service mit den aktuellen Covid-19 Infektionen pro 100.000 Einwohner auf die deutschen Bundesländer. Der Service wird täglich mit den aktuellen Fallzahlen des Robert Koch-Instituts aktualisiert.

Nachdem ich die letzten Jahrzehnte die Horde Groupware als Webmail-Oberfläche im Einsatz hatte, war ich schon länger sporadisch auf der Suche nach einem adäquaten Ersatz.

Zum einen nutze ich für Kalender und Kontakte seit ein paar Jahren eine Nextcloud-Instanz, wodurch die meisten zusätzlichen Features ungenutzt waren. Zum anderen bot es sich mit dem aktuellen Wechsel von Apache auf Nginx nun gerade an.

RainLoop ist ein modernes Frontend, was einfach imap/smtp Server einbinden kann und komplett ohne eine Datenbank auskommt. Es besitzt eine vergleichsweise übersichtliche Konfiguration und ein Plugin-System um es um zusätzliche Funktionen zu erweitern.

Auch das Einbinden in eine bestehende Nginx-Struktur ist straight forward.

RainLoop gibt es ebenfalls direkt als App für Nextloud.

Nachdem ich die Tage darauf aufmerksam gemacht wurde, dass offensichtlich die Detail-Ansicht der Posts auf meinem Blog nicht funktionierte, nahm ich dies nach einem schnellen Fix mal endlich zum Anlass mir den Blog generell nochmal vorzuknöpfen.

Immerhin hatte ich noch ein paar kleinere Wünsche schon seit geraumer Zeit im Kopf, die aufgrund von anderen Beschäftigungen nie realisiert wurden. Wie zum Beispiel eine Paginierung, die Post-Länge auf der Index-Seite zu begrenzen und auch eine Kommentarfunktion einzubauen.

Schnell fühlte ich mich allerdings an das Kinderbuch von Petterson und Findus – Eine Geburtstagstorte für die Katze erinnert, welche ich zugegebenermaßen zufällig kürzlich gelesen hatte. Um eine triviale Aufgabe zu lösen, müssen in der Geschichte eine Menge aufgeschobene Tätigkeiten erledigt werden, damit man das eigentliche Projekt umsetzen kann.

Wo ist mein GIT-Server?

Es fing direkt damit an, dass ich mich erinnerte meinen GIT-Server, welcher unter anderem den Quellcode des Blog beherbergte, nach einem Crash mit einer korrupten Festplatte vom Netz genommen zu haben.

Also wollten zunächst einmal die Daten gerettet werden und auf einem neuen Speicher abgelegt werden. Schnell merkte ich dass an dem Dateisystem nicht mehr viel zu retten ist und der letzte Clone des Servers schon ca. 2 Jahre alt war. Also den Server komplett neu aufsetzen, neue SSH-Keys vergeben, neue SSL-Zertifikate anfordern und die Daten aus dem Backup wieder aufspielen...

Ein perfekter Zeitpunkt also, um auch gleich mal einen aktuellen Clone vom Server anlegen.

Jetzt gehts endlich los!

Endlich Zeit die IDE zu starten, um auch hier ein Update zu fahren. Nur um dann festzustellen, dass die Lizenz nur eine Update-Subscription bis zum Oktober vergangenen Jahres hatte... Also auch diese schnell erneuert.

Nach einem kurzen Compare des GIT-Trees mit der aktuellen Produktiv-Umgebung wurde mir wieder bewusst, dass ich wohl doch schon öfter direkt am Live-Code Veränderungen vorgenommen hatte, welche natürlich auch noch ge-merged werden wollten...

Was soll ich sagen? Zum Coden bin ich nicht gekommen, aber zumindest ein ordentlicher Frühjahrsputz der Systeme war drin...

Nun gut, jetzt ging es los, allerdings hatte mich dies doch deutlich mehr Zeit gekostet als ich geplant hatte und die Kommentarfunktion ist auf einen weiteren freien Abend aufgeschoben.

Die Ausgangslage

Schon seit geraumer Zeit bin ich auf der Suche nach günstigen Heizkörperthermostaten für die Hausautomation, sogenannte Smart Home Geräte. Leider bin ich sehr wählerisch was diese alles können sollen und vor allem kosten sollen.

Folgende Bedingungen sollen sie erfüllen:

• Die Thermostate sollen kabellos steuerbar sein
• Die Thermostatsteuerung sollte im Batteriebetrieb mind. ein halbes Jahr funktionieren
• Es sollen keine Server/Kommunikation ausserhalb des eigenen LAN benötigt werden
• Es soll günstig sein, max. 30 € Heizkörperthermostat
• Die Protokolle sollten quelloffen sein

Recherche im Netz

Zunächst habe ich mich natürlich nach bestehenden Systemen umgesehen und nach längerer Recherche wurde mir klar, dass es z.Z. ein solches System scheinbar nicht gibt, oder ich es schlicht nicht finde. Am interessantesten fand ich das eCozy Heizungsthermostat (auf Zigbee Basis), welche pro Thermostat z.Z. unter 40 € liegen.

Projekt auf Arduino-Basis

Da ich schon seit geraumer Zeit einen Arduino UNO zuhause liegen habe, war die Idee naheliegend daraus ein Projekt zu machen. Schnell merkte ich allerdings dass es nur sehr wenig Arduino Projekte im Batteriebetrieb gibt.

Das liegt vor allem daran dass der Arduino selbst beim idlen einiges an Power braucht, was ihm im Stand-By nur ein paar Tage mit 2000-2500mA Akkus beschert. Eine Alternative wäre hier der Arduino Mini Pro, allerdings habe ich mich dank des Artikels From Arduino to a Microcontroller on a Breadboard bereits entschieden, das Projekt direkt auf dem Breadboard direkt mit dem ATMEGA328P-PU (Microcontroller) zu starten.

Zum Start soll das Projekt nun erstmal die Raumtemperatur und Luftfeuchtigkeit, durch den DHT22 messen und per Funk-Modul (NRF24L01) übertragen. Die benötigten Bauteile (ohne Akkus) haben auf eBay unter 10 € gekostet. Geplant ist, das System auf 8Mhz und 3V zu betreiben. Lediglich der DHT22 benötigt in seinen Specs mindestens 3.3V, mal sehen.

Jetzt heisst es erstmal auf die China-Ware ein paar Wochen warten...

Heute habe ich mir nach längerer Zeit mal wieder den Blog angeschaut und wie er so im Speed-Test des performed.

Um sowohl bei Google Pagespeed Insight für die Mobile- als auch die Desktop-Darstellung 100 Punkte zu erreichen, als auch im Varvy SEO tool optimal abzuschneiden, musste ich doch noch ein paar kleinere Tweaks vornehmen.

Gegen meine Erwartung musste ich meine default.css mit den Standard-Styles der Webseite direkt im Header lagern, da dies schneller ist als eine weitere, rendering blockende CSS-File zu laden.

Die zusätzlich von externen Quellen geladenen Ressourcen, wie Google Fonts, Font-Awesome und das pygments-CSS für das Code-Highlighting habe ich in einer lokalen CSS-Datei zusammengefasst und dementsprechnend die Verweise auf die Fonts angepasst.

Ein weiterer Punkt war das Caching der statischen Files, die bei mir auch über den Apache ausgeliefert werden. Hierfür verwende ich die klassische Erweiterung mod_expires mit einer Gültigkeitsdauer von einem Monat für alle gängigen statischen Dateien.

<IfModule mod_expires.c>      
    ExpiresActive ON      
    <FilesMatch "\.(gif|png|jpg|jpeg|ico|css|js)$">         
        ExpiresDefault "access plus 1 month"        
    </FilesMatch>       
</IfModule>

Desweiteren habe ich die verwendeten Hintergrund-Bilder mit jpegoptim optimiert, um hier noch einige KB sparen zu können.

Ich war auf der Suche nach einer Möglichkeit ganze IP-Bereiche mit Fail2Ban zu blocken. Um IP Bereiche blocken zu können ergänzen wir zuerst die jail.local (Debain: /etc/fail2ban/)

jail.local

[ip-blacklist]
enabled   = true
port      = anyport
action = action_ip-blacklist
filter    = filter_ip-blacklist
logpath   = /etc/fail2ban/ip-blacklist
maxretry  = 0
findtime  = 15552000
bantime   = -1

[ip-blacklist24]
enabled   = true
port      = anyport
action    = action_ip-blacklist[mask=24]
filter    = filter_ip-blacklist24
logpath   = /etc/fail2ban/ip-blacklist
maxretry  = 0
findtime  = 15552000
bantime   = -1

[ip-blacklist16]
enabled   = true
port      = anyport
action    = action_ip-blacklist[mask=16]
filter    = filter_ip-blacklist16
logpath   = /etc/fail2ban/ip-blacklist
maxretry  = 0
findtime  = 15552000
bantime   = -1

[ip-blacklist8]
enabled   = true
port      = anyport
action    = action_ip-blacklist[mask=8]
filter    = filter_ip-blacklist8
logpath   = /etc/fail2ban/ip-blacklist
maxretry  = 0
findtime  = 15552000
bantime   = -1

Danach erstellen wir die action Konfiguration (Debain: /etc/fail2ban/action.d/).

action_ip-blacklist.conf

[Definition]

# Option:  actionstart
# Notes.:  command executed once at the start of Fail2Ban.
# Values:  CMD
#
actionstart = iptables -N fail2ban-<name>
              iptables -A fail2ban-<name> -j RETURN
              iptables -I <chain> -p <protocol> -j fail2ban-<name>

# Option:  actionstop
# Notes.:  command executed once at the end of Fail2Ban
# Values:  CMD
#
actionstop = iptables -D <chain> -p <protocol> -j fail2ban-<name>
             iptables -F fail2ban-<name>
             iptables -X fail2ban-<name>

# Option:  actioncheck
# Notes.:  command executed once before each actionban command
# Values:  CMD
#
actioncheck = iptables -n -L <chain> | grep -q fail2ban-<name>

# Option:  actionban
# Notes.:  command executed when banning an IP. Take care that the
#          command is executed with Fail2Ban user rights.
# Tags:    <ip>  IP address
#          <failures>  number of failures
#          <time>  unix timestamp of the ban time
# Values:  CMD
#
actionban = iptables -I fail2ban-<name> 1 -s <ip>/<mask> -j DROP

# Option:  actionunban
# Notes.:  command executed when unbanning an IP. Take care that the
#          command is executed with Fail2Ban user rights.
# Tags:    <ip>  IP address
#          <failures>  number of failures
#          <time>  unix timestamp of the ban time
# Values:  CMD
#
actionunban = iptables -D fail2ban-<name> -s <ip>/<mask> -j DROP

[Init]

# Defaut name of the chain
#
name = default

# Option:  protocol
# Notes.:  internally used by config reader for interpolations.
# Values:  [ tcp | udp | icmp | all ] Default: all
#
protocol = all

# Option:  chain
# Notes    specifies the iptables chain to which the fail2ban rules should be
#          added
# Values:  STRING  Default: INPUT
chain = INPUT

# Option:  mask
# Notes.:  used to ban an address-range by netmask(s) in CIDR notation.
# Values:  [ 32 | 24 | 16 | 8 ] Default: 32
#
mask = 32

Im nächsten Schritt erzeugen wir unsere 4 verschiedenen Filter Konfigurationen für die IP-Bereiche (Debian: /etc/fail2ban/filter.d/).

filter_ip-blacklist.conf

[Definition]

# Option:  failregex
# Notes :  Detection of blocked ip addresses.
# Values:  TEXT
#

failregex = ^<HOST>(/32.*|[^/].*)?$

# Option:  ignoreregex
# Notes :  Regex to ignore.
# Values:  TEXT
#

ignoreregex =

filter_ip-blacklist24.conf

[Definition]

# Option:  failregex
# Notes :  Detection of blocked ip addresses.
# Values:  TEXT
#

failregex = ^<HOST>/24.*$

# Option:  ignoreregex
# Notes :  Regex to ignore.
# Values:  TEXT
#

ignoreregex =

filter_ip-blacklist16.conf

[Definition]

# Option:  failregex
# Notes :  Detection of blocked ip addresses.
# Values:  TEXT
#

failregex = ^<HOST>/16.*$

# Option:  ignoreregex
# Notes :  Regex to ignore.
# Values:  TEXT
#

ignoreregex =

filter_ip-blacklist8.conf

[Definition]

# Option:  failregex
# Notes :  Detection of blocked ip addresses.
# Values:  TEXT
#

failregex = ^<HOST>/8.*$

# Option:  ignoreregex
# Notes :  Regex to ignore.
# Values:  TEXT
#

ignoreregex =

Als letzten Schritt können wir nun unsere Datei mit der Liste der sperrenden IP Adressen erstellen (Debian: /etc/fail2ban/)

ip-blacklist

########################################
#
# Single IP Example:
# 10.10.10.10       [2015-01-01 12:00:00]
# 10.10.10.10/32    [2015-01-01 12:00:00]
#
#########################################
#
# IP Range Options:
# 10.10.10.10/24 = 10.10.10.*
# 10.10.10.10/16 = 10.10.*.*
# 10.10.10.10/8  = 10.*.*.*
#
#########################################
#
# IP Range Examples:
# 10.10.10.10/16    [2015-01-01 12:00:00]
# 10.10.10.10/24    [2015-01-01 12:00:00]
#
#########################################

Zu guter letzt muss Fail2Ban neu geladen werden, immer wenn die Blackliste verändert wird (Debian: /etc/init.d/fail2ban reload).

Das wars, nun können einfach ganze IP-Bereiche (aber auch einzelne IP-Adressen) über die Datei ip-blacklist geblockt werden.

Regular Expressions (kurz Regex) sind ein mächtiges Werkzeug, können einem manchmal aber etwas Kopfzerbrechen bereiten. Zum Glück gibt es im Netz viele kleine Helferlein, die den Umgang mit Regex erleichtern.

Um eigene Regular Expressions zu testen, empfiehlt sich der Test von regular expressions 101.

Soll eine bestimmter Zahlenbereich abgedecken werden, ist dies nicht einfach per [1-100] möglich, da hier immer nur ein Zeichen betrachtet wird. Eine großartige Hilfe bietet hier der Regex Numeric Range Generator von UtilityMill.

Will man hingegen eine Regex visualisieren, gibt es auch hierfür ein nettes Tool names Regulex, einen JavaScript Regular Expression Visualizer.

Natürlich gibt es auch Spiele, in denen man sein eigenes Wissen über Regular Expressions auf die Probe stellen kann, wie zum Beispiel Regex Crossword: Challenges. Als Tutorial für den Einstieg empfiehlt sich RegexOne - Interactive Tutorial.

Heute wurde die SSLv3 Lücke names POODLE bekannt. Daher lohnt es sich ab sofort auf das veraltete SSLv3 zu verzichten und nur noch TLS zuzulassen.

Ob auf dem eigenen Server noch SSLv3 verfügbar ist, kann schnell über den Befehl curl -v3 -X HEAD https://beispieldomain.de, oder über die Webseite Free POODLE SSL Check herausgefunden werden.

Um das SSLv3 Protokoll für ISPconfig zu deaktivieren ist eine Anpassung in der Datei /etc/apache2/mods-available/ssl.conf nötig.

Die Zeile SSLProtocol all -SSLv2 muss in SSLProtocol +ALL -SSLv3 -SSLv2 geändert werden um SSLv3 zu deaktivieren.

Dabei bietet es sich an gleich die Zeile SSLCipherSuite HIGH:MEDIUM:!aNULL:!MD5 in

SSLCipherSuite DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-SHA256:DHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA:AES256-SHA:AES128-SHA zu ändern.

SHA1 auf SHA256 umstellen

Aktuell werden (self-signed) Zertifikate unter ISPconfig 3.0.5.4p3 noch mit SHA1 erstellt. Till Brehm hat vor einigen Tagen einen SHA256 Patch bereit gestellt, der allerdings Stand heute noch nicht veröffentlicht wurde. Diese Änderungen kann man aber auch schnell per Hand einpflegen, für Apache liegt die Datei unter /usr/local/ispconfig/server/plugins-available/apache2_plugin.inc.php

Um die eigenen SSL Zertifikate zu testen, bietet sich in jedem Fall der Test von SSL Labs an.

Bisher war ich dem kostenlosen Service von dnsdynamic.org sehr zufrieden, doch leider liefert mir der Dienst seit einigen Wochen falsche IP Adressen, obwohl diese passend übermittelt werden und auch dort korrekt in der Weboberfläche erscheinen. Höchste Zeit sich mal um eine Alternative zu kümmern. Auf Dauer vermisst man es doch auf den Server zuhause zugreifen zu können.

Mein erster Gedanke war auf dem eigenen root Server den DDNS Dienst laufen zu lassen, da ich eh eine eigene Subdomain per CNAME dafür genutzt habe. Allerdings müsste ich dafür die gasamte Domain über den eigenen Server verwalten und müsste mich nach einem passenden Nameserver umsehen. Das lohnt nicht so richtig für eine einzelne Subdomain.

Nach einiger Suche habe einen kostenlosen DDNS Anbieter gefunden, der meinen Kriterien erfüllt. SPDNS ist ein deutscher, kostenloser DDNS Anbieter, welcher sowohl IPv4 als auch IPv6 unterstützt, für die Registrierung lediglich Email, Benutzernamen und Passwort verlangt und sich auch mit dem vom mir verwendeten DDClient updaten lässt.

Jetzt ist der Heimserver ohne viel Aufwand, trotz Zwangstrennung, erstmal wieder erreichbar.

Als ich den Bericht Freifunker gehen gegen Störerhaftung vor Gericht las, erinnerte ich mich daran, dass ich auch schon immer einen Router für den Freifunk nutzen wollte. Aktuell habe ich sogar zwei TP-LINK Router übrig, allerdings gibt es für beide (TL-WR641G / TD-W8961NB) leider keine OpenWrt Firmware, worauf das Freifunk-Netz aufbaut. Möglicherweise sollte ich einfach mal in einen weiteren Router investieren, allerdings wäre es natürlich deutlich schöner, einen der alten dafür nutzen zu können.

In Bielefeld gibt es bereits 62 Freifunk Knoten, ein guter Anlaufpunkt ist in jedem Fall Freifunk Bielefeld.

Bleibt zu hoffen, dass die Störerhaftung auch in nächster Zeit fällt, damit man auch problemlos das Internet mit anbinden kann.

Um die Verwaltung der Domains, Postfächer etc. für mich und andere etwas zu erleichtern, habe ich mich für die Server Administrationssoftware ISPConfig entschieden. Für Debian gibt es auf howtoforge.com ein ganz nettes The Perfect Server Tutorial.

Da ich mich bisher noch nicht mit python Apps unter Apache beschäftigt hatte, insbesondere im Zusammenspiel mit ISPConfig und Subdomains hat mich das ganze doch etwas Recherche gekostet.

Daher hier eine kurze Anleitung.

1. wgsi_mod installieren - Unter Debian kann die wgsi_mod für den Apache Webserver einfach als Paket apt-get install wgsi_mod installiert werden.

2. Struktur - Die Struktur der Flask-App (mit Namen flaskTest) sieht wie folgt aus:

flaskTest/
    flaskTest.wgsi      (WGSI File)
    config.py           (Configuration)
    run.py              (Development Server)
    env/                (Virtualenv)
    flaskTest/
        __init__.py
        static/
            ...
        templates/
            ...

3. Die .wgsi Datei

#!/usr/bin/python
# -*- coding: utf-8 -*-
import sys
import logging
logging.basicConfig(stream=sys.stderr)
sys.path.insert(0,"/path-to/flaskTest")
from flaskTest import app as application
application.secret_key = 'my secret key'

4. Die Subdomain im IPSConfig anlegen. Da es sich bei der Subdomain nicht um eine Weiterleitung handeln soll, muss diese als neue Webseite eigegeben werden. Um die Direktiven für Apache zur App zu hinterlegen, kann der Bereich Optionen im ISPConfig genutzt werden. Hier steht dann folgendes:

WSGIScriptReloading On
WSGIScriptAlias / /path-to/flaskTest/flaskTest.wsgi
WSGIDaemonProcess flaskTest python-path=/path-to/flaskTest/flaskTest:/path-to/flaskTest/env/lib/python2.7/site-packages
WSGIProcessGroup flaskTest
<Directory /path-to/flaskTest>
    Order allow,deny
    Allow from all
</Directory>

5. DNS Einstellung - Zu guter letzt, muss natürlich noch der DNS Eintrag für die Subdomain vorgenommen werden, hier reicht ein einfacher subdomain IN CNAME www und fertig ist die Seite.

Sooo...! Das neue Blog steht und ich bin sehr zufrieden.

Wie auf meiner Wunschliste schon angemerkt, wollte ich die Seite gern in Python schreiben. Da mir das Django Framework für diese Zwecke doch etwas zu überdimensioniert ist, habe ich mich für das grandiose Microframework Flask entschieden. Dieses bringt gleich ein Plugin für Markdown mit, sowie ein tollen Markdown-Syntax-Highlighter basierend auf Pygments.

Während meiner Suche bin ich noch auf das mini Tutorial von James Sharding gestoßen, ein Blog aus statischen .md Dateien - zwar nix für ein größeres Blog, aber solange ich mich noch auf keine Datenbankstruktur festgelegt habe, ein guter und schneller Anfang.

Für das Responsive Design habe ich mich für das Responsive Grid System, mal sehen, dass ich auf Dauer die Seite noch etwas hübscher mache.

Auch ein RSS Feed ist schonmal eingebunden.

Im Frühjahr dieses Jahres haben wir uns endlich von den v-Servern verabschiedet und sind zu einem echten root-Server übergegangen. Endlich eine Kiste, die nicht mehr bei 10 SQL-Verbindungen direkt in die Knie geht und schon beim vorinstallierten Plesk standardmäßig am Ressourcen-Limit arbeitet. Jetzt ist auch endlich genug Saft da, um einen eigenen Minecraft Server nebenher darauf laufen zu lassen.

Bedauerlicherweise habe ich beim Übertragen der Domains die Datenbank meiner eigenen Subdomain vergessen - ein Anfängerfehler - somit war mein altes Wordpress Blog weg... zum Glück nur meine eigenen paar Einträge, trotzdem alles sehr, sehr ärgerlich.

Das einzig positive daran ist, dass ich schon lange mit dem Gedanken gespielt hatte, mich endlich von PHP und Wordpress loszusagen. Also die perfekte Gelegenheit, endlich neu anzufangen. Aber was sollte das neue Blog können?

Folgende Wunschliste sollte das neue Blog mitbringen:

• Kein PHP mehr, stattdessen lieber Python
• Möglichst einfach wartbar und erweiterbar
• Benutzerfreundliche URLs
• Einträge in Markdown
• Responsive Design
• Einfaches Syntax-Highlighting für verschiedenste Sprachen

Schon seit geraumer Zeit spiele ich nun mit dem Gedanken einen Heim-Server aufzustellen. Hauptsächlich um nicht immer den Computer im Arbeitszimmer laufen zu lassen, wenn man per WLAN-Radio seine Musik im Wohnzimmer hören, oder seine Fotos und Videos auf dem Fernseher schauen möchte.

Aber dafür einen ausgedienten Rechner als Stromfresser mit ständiger Geräuschkulisse – das war irgendwie keine richtige Option. Nun habe ich endlich einen Server gefunden, welcher wie geschaffen scheint, ein ictPlug – Plug PC (Sheevaplug). Dies ist ein kleiner, stromsparender Server mit 1,2 GHz und 512 MB RAM.

Der Sheevaplug verfügt über eine relativ geringe Speicherkapazität von nur 512 MB auf dem internen NAND-Speicher, die aber durch den vorhandenen SD-Karten Slot und die USB-Schnittstelle nicht so sehr ins Gewicht fallen. Eine 15 GB SD-Karte bekommt man heute schon für unter 20 € und eine externe USB-Festplatte bietet noch deutlich mehr Platz für Musik, Fotos und Videos.

In den kommenden Wochen werde ich meine Erfahrungen mit dem handtellergroßen Server hier teilen.

Weiterführende Links:

• http://de.wikipedia.org/wiki/SheevaPlug

Da das Online-Handbuch von xt:Commerce VEYTON 4.0 keine Anleitung zum einbinden eines Favicons in die WebShop-Software enthält, habe ich mich entschlossen hier eine kurze Anleitung zum Einbinden template-abhängiger Favicons zu geben.

Damit man für unterschiedliche Templates verschiedene Favicons einsetzen kann, muss die Datei styles.php im Verzeichnis xtCore (/xtCore/styles.php) ergänzt werden. Wichtig ist, dass der folgender Code innerhalb der PHP Brackets liegt.

if( file_exists( $_SERVER{'DOCUMENT_ROOT'}._SRV_WEB_TEMPLATES._STORE_TEMPLATE.'/img/favicon.ico')) {
    echo '<link rel="shortcut icon" href="'._SYSTEM_BASE_URL._SRV_WEB._SRV_WEB_TEMPLATES._STORE_TEMPLATE.'/img/favicon.ico" type="image/x-icon" />'."\n";
}

Mit diesen Zeilen wird geprüft, ob im Unterordner img des jeweiligen Template-Verzeichnisses eine Datei favicon.ico vorhanden ist, und diese dann eingebunden.

Nun kann unter jedem Template ein eigenes Favicon abgelegt werden. Bsp.: <webshop_root>/templates/<eigenes template>/img/favicon.ico

Da ich mich ja für das Amazing Grace Theme entschieden habe, wollte ich natürlich trotzdem nicht auf die deutsche Übersetzung verzichten.

Daher habe ich das Theme mal schnell überstetzt. Ein sehr nützliches Programm dafür ist PoEdit.

Eine sehr ausführliche Anleitung, wie das ganze funktioniert, findet ihr in einem Artikel von texto.de.

Ihr findet die deutschen Sprachdateien für das Amazing Grace Theme hier:

• de_DE.mo
• de_DE.po

Diese müsst ihr einfach in das Amazing Grace Verzeichniss eures WordPress kopieren und schon sollte das Theme auf deutsch sein.

Update 21.09.2010: Leider fehlten dem Theme die Übersetzungsstrings für die Kommentare, daher ist hierfür erst noch eine kleine Änderung an der functions.php von Amazing Grace nötig.

Dafür müsst ihr die Zeilen 423 bis 428 ersetzen. Ich habe die Codeänderungen mal auf pastebin.com eingestellt, solange ich noch kein gutes Plugin gefunden habe, um Quellcode anschaulich im Blog zu veröffentlichen.

Sooo… das ist es nun… mein ganz persönliches Weblog. Wie gesagt aller Anfang ist schwer, und es stellt sich durchaus die berechtigte Frage, wozu das ganze?! Manche mögen sagen: “Du hast doch schon dein Leisure Linux Blog, das nicht gerade durch seine Aktualität glänzt”. Das stimmt! Allerdings wollte ich schon länger ein Blog haben, wo ich quer alles Mögliche schreiben kann, ohne mich an bestimmt Themen wie z.B. Linux Spiele halten muss und trotzdem meinen Senf loswerde.

Zu diesem Zweck habe ich mal ganz ungezwungen dieses Blog gestartet und werde mal schauen, wie es sich denn so weiterentwickelt.

Wie ihr sehen könnt habe ich mich dem (wie ich finde) recht schicken Theme Amazing Grace von Vladimir Prelovac bedient.