Wangoo

Der kurze und schmerzlose weg zum Upgrade von Postgres auf das gestern erschienene Postgres 9.2 sieht so aus:

“sudo” braucht ihr nur, wenn ihr nicht schon direkt als root arbeitet

sudo add-apt-repository ppa:pitti/postgresql
sudo apt-get update
sudo apt-get install postgresql-9.2
sudo pg_dropcluster –stop 9.2 main
sudo pg_upgradecluster 9.1 main (9.1 ersetzt bitte durch die Versionsnummer eurer alten PG Installation / evtl. screen benutzen weil es doch etwas dauern kann bis er so weit ist)

Nachdem ihr überprüft habt, das alles glatt gegangen ist. Entfernt ihr den alten Cluster.

sudo pg_dropcluster –stop 9.1 main (hier wieder die alte Versionsnummer angeben)
sudo apt-get remove postgresql-9.1

Fertig

Quellen:
http://blog.tquadrado.com/2008/pg_upgradecluster-82-main/
http://www.ubuntuupdates.org/ppa/pitti_postgresql?dist=oneiric

Um Icinga-Web auch unter nGinx zu nutzen, muss man ein wenig in die Trickkiste greifen und die Requests umschreiben. Leider führte das Tutorial von Andis Blog nicht zu einem funktionierenden Ergebnis.

Voraussetzung ist: Icinga-Web ist unter /opt/icinga installiert:

server {
        server_name HIER_DEIN_SERVERNAME;
        listen 80;

        root /opt/icinga/pub;

        location /icinga-web/styles {
                alias /opt/icinga/pub/styles;
        }

        location /icinga-web/images {
                alias /opt/icinga/pub/images;
        }
        location /icinga-web/js {
                alias /opt/icinga/lib;
        }
        location /icinga-web/modules {
                rewrite ^/icinga-web/(.*)$ /index.php?/$1 last;
        }
        location /icinga-web/web {
                rewrite ^/icinga-web/(.*)$ /index.php?/$1 last;
        }
        location / {
                # HINT: Das Verzeichnis wo die index.php ist
                root   /opt/icinga/pub;
                index index.php;
                location ~* ^/(robots.txt|static|images) {
                    break;
                }

                if ($uri !~ "^/(favicon.ico|robots.txt|static|index.php)") {
                        rewrite ^/([^?]*)$ /index.php?/$1 last;
                }
        }
        location ~ \.php($|/) {
                include /opt/nginx/conf/fastcgi_params;
                fastcgi_pass 127.0.0.1:9001;
                fastcgi_param SCRIPT_FILENAME /opt/icinga/pub$fastcgi_script_name;
                fastcgi_param PATH_INFO $fastcgi_script_name;
    }
}

Ich war auf der Suche nach einem Plugin, welches Staging mit WordPress ermöglicht. Leider gibt es da nicht viele und vor allem sind die Foren voll mit “Diskussionen” über das für und wider.

Heute habe ich DeployMint in einem Blogeintrag von Mark Maunder gefunden, ein interessanter Ansatz für das Staging unter WordPress. Es verwendet GIT als Revisionsbasis. Der Ansatz ist gut, nur leider geht es nicht mit einem schon vorhandenen Blog, daher kann ich das ganze nicht ausprobieren. Auch die Kommentare deuten auf einige Fehler hin. Das Video allerdings überzeugt schon mal. Hat wer von euch das ganze schon getestet?

Warum ich Staging will:

• Nur html Files auf dem Frontendserver
• Schnellere Seiten als mit *cache* Plugin
• Sicherer da kein PHP/Whatever ausgeführt werden muss
• Durch schnellere Seiten erhöht sich auch das google Ranking

Heute morgen ereignete sich etwas seltsames, mein Unison meldete plötzlich beim synchronisieren mit meinem Testserver

Unison: End_of_file exception raised in loading archive (this indicates a bug!)

Auch googlen half nicht zu einer Lösung. Die meisten Einträge dazu waren schon mehr als ein Jahr alt und brachten keine Hilfestellung. Die Lösung des Problems war, unison mit dem -debug all Parameter auszustatten.

Dort meckerte er ein Backupfile an. Also löschte ich auf dem Remoteserver den Ordner .unison. Startete unison mit dem Parameter -ignorearchives und schon klappte es wieder.

Unison ist eine perfekte Alternative um zwei oder mehrere Server/Systeme synchron zu halten. So teste ich meinen Patch erst am Testsystem um ihn anschließend zum Produktivserver zu übertragen. Auch die Synchronisationsgeschwindigkeit ist sehr hoch, was gerade bei großen Dateien von Vorteil ist. Unison gibt es für Linux, Windows, OS X.

Lustige Sache, in der standard Konfiguration von vsftpd wird nirgends die möglichkeit gegeben zu sagen, zeig mir auch Dateien an die “versteckt” (führender Punkt im Dateinamen) sind. Tief in der Manpage steht dann plötzlich:

force_dot_files
If activated, files and directories starting with . will be shown in directory listings even if the "a" flag was not used by the client. This override excludes the "." and ".." entries.
Default: NO

Einfach den Switch in der vsftpd.conf auf YES stellen.

Vielleicht hilft es dem ein oder anderen der danach Googled schneller den Switch zu finden.

Nach einem Reinstall eines meiner RootServer hatte ich lustige Probleme, zur Auswahl hatte man Debian Sarge oder SuSe Linux 9.3. Beides doch recht veraltete Distros – Mehr…