siarp.de

dpkg-reconfigure locales als root bzw mit sudo

Angeblich ist dafür das Paket debconf erforderlich.

Erstmal ein paar Schöne generiert, die man so haben will.

Als Standard habe ich "keine" bzw "none" angegeben.

Upgrade auf Debian etch (testing)

Änderung von /etc/apt/sources.list:

 cd /etc/apt/
 pico sources.list

So, hab ich mein tolles Umleitkonzept auch für Subversion richtig umgesetzt. Egal was man jetzt eingibt als URL, man gelangt immer auf https://siarp.de/svn/...

In Repositories gehören nur Produktivdaten, keine Metainformationen von IDEs, etc.
Konkret bedeutet das, dass das Verzeichnis .settings von Eclipse-Projekten nicht eingecheckt wird (genauso wie die Datei .project).

Nach wie vor gilt:
Standard encoding: UTF-8
Text file line delimiter: UNIX style

Keywords Eclipse Konvention Projekt project settings

Problem: Normale Zertifikate gelten nur für eine (Sub-)Domain
Erkenntnis: Es gibt auch Wildcard-Zertifikate, die alle Subdomains abdecken
Folgefrage: Bekommt man diese Wildcardzertifikate von einer halbwegs anerkannten CA ohne kosten?

Allgemein zum Thema pro/contra Subdomains:
+ sie sehen hübsch aus
- wirklich sinnvoll eingesetzt sind sie nur, wenn sie auf verschiedene Recher bzw. IPs zeigen, was sie bei uns nicht tun
- uns fällt kein Service ein, für den eine Subdomain wirklich nötig wäre.

Die Entscheidung: Es sollen alle Dienste ohne Subdomain unter protokoll://siarp.de erreichbar sein.

Wäre es nicht schön, Subdomains wie svn und sflog zu haben? Die Einrichtung von Virtual Hosts habe ich im Apache schonmal begonnen. Läuft auch soweit, nur dass ihm irgendwas fehlt, um eine Subdomain anzusprechen. Ich befürchte, das wäre in Plesk ein Klick und wir müssen das jetzt mit BIND irgendwie manuell einrichten. Oder müssen wir das nur im KIS machen, damit HE ihre eigenen NS aktualisiert? Fürs KIS habe ich leider keinen Zugang.

SF_log läuft jetzt produktiv auf siarp.de, sollte ich hier vielleicht noch dazusagen. Komme auch erstmal ohne Subdomain aus.

Kaum macht man's richtig...

Das Problem mit den Bildern in Drupal war, dass GD nicht mit JPEG-Support lief. Das wäre auch aus der phpinfo() ersichtlich gewesen... Dank eines Bugs habe ich dann noch stundenlang gebraucht. Naja, ob dieser Bug jetzt eine Auswirkung hatte, weiß ich nicht. Schließlich lief GD ja schon. Aber die Kombination der beiden JPEG-Optionen ist entscheidend.

PHP ist nun mit folgendem Script kompiliert und versteht jetzt auch JPEG.

Ich habe ein Repository tests, in dem sich ein Verzeichnis automaticupdate/website befindet, das bei jedem Commit automatisch ins htdocs-Verzeichnis ausgecheckt werden soll.

Dazu erstelle ich ein Verzeichnis htdocs/tests und übertrage es an Benutzer svn.
Danach wird manuell der 'initial checkout' durchgeführt:

Für die automatischen Updates wird jetzt noch ein hook-Skript geschrieben. Es heißt post-commit, gehört selbstverständlich dem Benutzer svn, ist ausführbar und liegt im Unterverzeichnis /hooks des Repository. (Da sind auch schon templates für die verschiedenen möglichen hooks.)

...erstellt ein Repository und liegt unter /root/tilman/create_repository.sh. Nächstes Ziel: Subversion hook script für automatisiertes Update, damit die Webentwicklung so richtig losgehen kann.

Migration von BerkeleyDB nach FSFS sollte ganz leicht sein.

Man kann einen Dump exportieren. Das ist eine menschenlesbare Datei, die man für heftige Änderungen auch bearbeiten kann. Tolle Sache das, damit gehen auch so Sachen, wie Zusammenlegung von zwei Repositories etc. Noch besser: LIES ES NACH. In der wie immer hervorragenden Doku.