mySQL und die Zeit

Oft wurstelt man bei der Entwicklung mit UNIX-Timestamps für Zeitangaben herum. Das ist kein Hexenwerk, aber direkt das Gelbe vom Ei ist es auch nicht. Speziell zur Implementierung von Zeit- und Datums-Filtern benötigt dieser Lösungsansatz eine Menge Logik, die in PHP gegossen werden muss (Schaltjahre, Schaltsekunden, …). Das Herumrechnen damit ist mühsam und sorgt oft für Knöten im Hirn.

Dies kann man wesentlich einfacher haben. mySQL kommt mit einer großen Vielfalt von Datums- und Zeitfunktionen daher, derer man sich wunderbar bedienen kann. Wenn man sich zum Beispiel die Funktion

TIMESTAMPADD()

ansieht, wird man schnell merken, dass diese Funktionen das Entwicklerleben erheblich vereinfachen können. Musste man früher mühsam herumrechnen, um bspw. ein Jahr zu einem gegebenen Datum hinzuzuaddieren, funktioniert das mit

SELECT TIMESTAMPADD(YEAR,1,'2012-01-03')

völlig problemlos – und das Beste: Schaltjahre, -Sekunden und dergleichen sind schon drin. Ein anderes Beispiel: Oft sollen Daten im Monatsraster dargestellt werden. Mit PHP mühsam, mit mySQL eine etwas ausführlichere WHERE-Klausel:

[...] WHERE `date`>SELECT TIMESTAMPADD(day,1,LAST_DAY(TIMESTAMPADD(month, -1, NOW()))) AND `date`<=LAST_DAY(NOW()) [...]

Dieser Where-Klausel liefert alle Datensätze, die im aktuellen Monat liegen, mit einigen Handgriffen kann man sie so erweitern, dass allein ein übergebener Parameter wie bspw. die Angabe, der wievielte Monat vor dem aktuelle angezeigt werden soll, die Filterung schon komplett macht.

Sollte doch einmal – aus welchen Gründen auch immer – der UNIX-Timestamp nötig sein, kann man sich diesen für ein beliebiges Datum mittels der Funktion

UNIX_TIMESTAMP()

zurückgeben lassen. Will man auch so nette Gimmicks wie bspw.

DATE_FORMAT()

nutzen, ist es sinnvoll, vorher die Systemvariable für die Darstellung von Monats- und Tagnamen über

SET SESSION lc_time_names=de_DE

entsprechend zu definieren. Auf diese Weise kann man sich den Unwägbarkeiten der PHP-Datumsfunktionen einfach und nachhaltig entziehen.

Viele weitere Funktionen und genauere Infos kann man der mySQL-Dokumentation entnehmen.

Einfügen / aktualisieren von SSL-Zertifikaten unter ispCP

SSL-Zertifikate unter ispCP einzurichten oder zu Verlängern ist etwas aufwändiger als im Apache aus der Dose.

Grundlagen

Das Vorgehen sieht im Detail wie folgt aus:
Auf dem fraglichen Server prüft man zuerst, ob die notwendigen Voraussetzungen erfüllt sind. Am einfachsten fällt dies, indem man sich über

crontab -l

die aktuellen Cronjobs anzeigen lässt. Hier muss folgende Zeile vorhanden sein:

 M  H  D   Mo   DoW    test -x /var/www/ispcp-bin/upd-ssl.pl && /var/www/ispcp-bin/upd-ssl.pl > /etc/apache2/sites-enabled/ispcp-ssl.conf 2>/dev/null

Hier erkennt man auch schon, welches Script relevant ist, in diesem Fall

/var/www/ispcp-bin/upd-ssl.pl

Sieht man sich dieses Script genauer an, wird man im Konfigurationsbereich u. a. die folgenden beiden Zeilen vorfinden:

my $sslenabledconfig='{Pfad zur}ssl.list';
my $sslcertfificatepath = "{Pfad}/ssl";

Zertifikate erstellen (die .pem-Dateien)

In den .pem-Dateien werden Schlüssel und Zertifikat gemeinsam gehalten. Sie sollten am Ende immer folgendermaßen aussehen:

-----BEGIN RSA PRIVATE KEY-----
MIIEp/IB//bC/QE/0f00rZqqrzbJZ0BtXCMzY3yVrQ4rHVLJVHBsX0IEbjq4RYnB
[...]
5j6je638LnVrVryj1iz3JmCN+ChyCpileIh4oe7FeP/m7CfY3bOmX/==
-----END RSA PRIVATE KEY-----
-----BEGIN CERTIFICATE-----
MIIFoTCCBImg/XIB/gIR/P+iVOuoGOHV6V5tX1YXFr4XVQYJboZIhvcN/QEFBQ/X
[...]
Y8eGOYE=
-----ENV CERTIFICATE-----

Wie man unschwer erkennen kann bestehen diese Dateien also aus einer Konkatenation von Schlüssel und Zertifikat als flache Textdatei. Nachdem man sichergestellt hat, dass die Datei mit einer Leerzeile endet, war es das an diesem Punkt auch schon. Die Datei wird unter dem Namen „sub.domainmitssl.org.pem“ im Verzeichnis, das in „$sslcertfificatepath“ definiert ist, abgespeichert.
Dieser Vorgang ist selbstverständlich für alle einzufügenden oder zu aktualisierenden Zertifikate entsprechend zu wiederholen.

Intermediate-Zertifikate

Für die meisten Zertifikate ist ein Intermediate-Zertifikat erforderlich um die Vertrauenskette zu einem Rootzertifikat lückenlos sicherstellen zu können. Diese werden analog zu den Zertifikatsdateien selbst als „sub.domainmitssl.org.pem.CA“ benannt und ebenfalls im Verzeichnis „$sslcertfificatepath“ abgelegt.

Zertifikate hinzufügen

„$sslenabledconfig“ zeigt auf die Liste von SSL-Zertifikaten, die berücksichtigt werden sollen. Der Inhalt dieser Datei folgt stets dem Schema

sub.domainmitssl.org sub.domainmitssl.org.pem

Im Detail bedeutet das, für die Domain „sub.domainmitssl.org“ ist die „Zertifikatdatei“ „sub.domainmitssl.org.pem“ zu benutzen.
Hier fügt man nun die Domain(s) mit den zugehörigen .pem-Dateien ein.

Hat man alle Domains in die Liste eingetragen und sichergestellt, dass die notwendigen Zertifikatdateien existieren, kann man entweder warten, bis der Cron, den wir am Anfang betrachtet haben, wieder läuft oder man startet das Script

/var/www/ispcp-bin/upd-ssl.pl

einfach manuell. Das Script erzeugt dann automatisch alle notwendigen Konfigurationen.

#!/usr/bin/perl 
#
use strict;

#####CONFIG
#
my $ispcpconfig='/etc/apache2/sites-enabled/ispcp.conf';
my $sslenabledconfig='/etc/ispcp/apache/ssl.list';
my $sslcertfificatepath = "/etc/apache2/ssl";

##


# ssl sites list
open (SSL,"<$sslenabledconfig");
my @tmpssl=grep /\w+/, <SSL>;
my %sslsites;
foreach(@tmpssl)
    {
    @_=split(/\s+/,$_);
    $sslsites{$_[0]}=$_[1];
    }

open(APACHE,"<$ispcpconfig");

my %virtualhosts;
while(<APACHE>)
    {
    my @tmpvirthost;
    chomp($_);
    if ($_ =~ /^\s*<VirtualHost/i)
        {
        push @tmpvirthost,$_;
        while(<APACHE>)
            {
            chomp($_);
            push @tmpvirthost,$_;
            last if ($_ =~ /^\s*<\/VirtualHost/i);
            }

        my @servname=map { $_ =~ /^\s+Servername\s+([\w.-]+)/i; $1 } grep(/ServerName/i, @tmpvirthost);
        my $serv=$servname[0];

#        print Dumper(@tmpvirthost);
    $virtualhosts{$serv}=\@tmpvirthost;
        }
            
        
        
    }

foreach my $onessl (keys %sslsites)
    {
    if (!defined($virtualhosts{$onessl}))
        {
        print "$onessl config is missing\n";
        next;
        }


    @{$virtualhosts{$onessl}}[0] =~ s/(<VirtualHost\s.+):80(.+)/$1:443$2/i;
    splice @{$virtualhosts{$onessl}},2,0,"SSLEngine ON";
    splice @{$virtualhosts{$onessl}},3,0,"SSLCertificateFile $sslcertfificatepath/$sslsites{$onessl}";
    if ( -f "$sslcertfificatepath/$sslsites{$onessl}.CA" )
        {
        splice @{$virtualhosts{$onessl}},3,0,"SSLCACertificateFile  $sslcertfificatepath/$sslsites{$onessl}.CA";
        }

    # print out the config, but only if the certificate file exists
    if ( -f "$sslcertfificatepath/$sslsites{$onessl}" )
        {
        print join("\n",@{$virtualhosts{$onessl}})."\n";
        }
    }

Fertig

Zum Abschluss startet man den Apache einmal neu, sodass die neuen Einstellungen greifen.

TYPO3 Core Dokumentation

Mit dem neuen Release haben sich auch wieder ein paar Dinge geändert bzw. kamen neue Dinge hinzu. Folglich wurden auch einige der Core-Dokumentationen aktualisiert. Nachdem die PDFs davon nicht mehr ganz so schnell und einfach aus dem Repository runtergeladen werden können, habe ich mal eine Liste der Dokumente samt PDF-Verlinkung zusammengestellt.

Kurz noch die Erklärung von typo3.org, wie die Dokumente allgemein einzusortieren sind:

These documents are related to the core of TYPO3 and address the built in functionality of TYPO3. They are designed to provide you with in-depth information. Each Core Manual addresses a particular process or function and how it is implemented within the TYPO3 source code. These may include information on available APIs, specific configuration options, etc. The Core Manuals are written as reference manuals. You should rely on the Table of Contents to identify what particular section will best address the task at hand.

Alle Core-Dokumentationen als PDF (ZIP)

Weiterlesen»

Dokumentation von Extensions

RTFM – wenn denn wirklich eines da wäre… Viel zu oft trifft man auf TYPO3-Extensions – auch eigene – deren Dokumentation mit etwas Glück mager ausgefallen ist, oft aber schlicht nicht existiert. Dies ist ärgerlich, weil man dadurch im TER nur schwer abschätzen kann, ob eine vorhandene Extension die gesuchte Funktionalität bietet, und weil bei individuellen (Kunden-)Extensions nach gewisser Zeit oft Kollegen (und man selbst) auch nicht mehr so genau weiß, was die Extension tut, wie sie es tut oder warum sie es so tut.
Aber warum dokumentieren wir so wenig? Mit ein paar wenigen Schritten und mit Vorlagen erleichtern wir uns selbst, unseren Kollegen und der Community das Leben. Also auf geht’s!

In „How typo3.org works“ beschreibt Kasper Automatismen rund um die TYPO3-Plattform incl. TER. Uns interessiert hierbei insbesondere der Abschnitt „1.3. Writing documentation for TYPO3“. Dort wird erklärt, wie aus einem einfachen OpenOffice-Manual die Online-Ansichten der Manuals entstehen, und warum die Struktur und Formatierung dabei entscheidend ist.
Ein Documentation template für korrekt formatierte Manuals mit zahlreichen Hinweisen steht im TER bereit.

Es ist wirklich kein Hexenwerk. Packen wir also mal wieder unseren inneren Schweinehund, und dokumentieren unsere Extensions.

Links:

Extbase & Fluid

Die Basis für Extensions in TYPO3 v5 wird das PHP-Framework FLOW3 und die Template-Engine Fluid bilden. Daher sollten langsam aber sicher Extension aufwärstkompartibel programmiert werden. Seit TYPO3 4.3 stehen mit den Extensions extbase und fluid die passenden Rahmenbedingungen bereit.

Lesenswertes und weiterführende Infos: