Im Startmenü: MS SQL Server -> Client Network Utility -> Registerkarte „DB-Library Options“ und dann „Automatic Ansi to OEM conversation“ das Häkchen entfernen.

MS-SQL speichert im UCS-2 bzw. UTF-16 Zeichensatz, aber alle Konvertierungen innerhalb PHP wurden durch die Einstellung in den Netzwerk-Parametern zunichte gemacht.

Zusätzlich müssen nach meinen Experimenten folgende Voraussetzungen gegeben sein:

1. PHPs interne Zeichendarstellung sollte 8bit sein. Falls jemand mit Iconv herumspielt, sollte er probieren, ob es auch mit anderen Einstellungen geht.
2. Die Spalten in der SQL-Server Datenbanktabelle müssen vom Typ NVARCHAR statt VARCHAR sein. Analog NTEXT statt TEXT, etc.
3. Bei mir seltsamerweise nicht notwendig, aber sauberer: Die Strings für die Unicode-Spalten bei INSERT und UPDATE sollten mit N’xxxx’ statt sonst ‘xxxx’ geschrieben werden.

Kaum war das Häkchen weg und die Spaltendefinition umgestellt, funktionierte das Skript ohne Änderungen und insbesondere ohne Konvertierungen mit mb_convert_encoding() oder iconv().

Danke an Michael Bieri in Problem mit Umlauten mit MS-SQL und PHP.

Zu BIRT gehört eine Web-Applikation, die die Report-Dateien aus dem Designer im Webbrowser darstellen und als PDF, Excel und so weiter exportieren kann. Diese Engine läuft in einem Applikationsserver wie Apache Tomcat oder JBoss. Im BIRT-Projekt wird dies beschrieben unter [1]

Um diese Applikation zu nutzen sind folgende Schritte erforderlich:

1. Tomcat installieren
2. BIRT Engine in Tomcat installieren und testen
3. BIRT Engine mit einem Report aus einer Webseite aufrufen
4. Reports als aus einem Skript heraus erzeugen
5. PDF-Dateien per Mail verschicken

Tomcat installieren

Die aktuelle Version BIRT 2.3.2 läuft mit Tomcat 5.5, obwohl es schon die Tomcat 6 gibt. Meine Versuche mit Tomcat 6 waren nicht sehr erfolgreich, also bleibe ich erst mal bei 5.5.

Tomcat wiederum läuft auf JRE 6. Zuerst stellen wir also sicher, dass JRE6 SE betriebsbereit ist. Falls nicht vorhanden, kann man JRE 6 SE von [2] laden.

Das Windows Binary von Tomcat 5.5 liegt auf [3] Am einfachsten ist das Binary mit Installer. Nach der Installation muss der Tomcat manuell gestartet werden; entweder mit der Frage am Ende der Installation oder über das Startmenü.

Tomcat nistet sich im Tray mit einem Symbol ein. Das Systemmenü von Tomcat kann man dort mit der rechten Maustaste erreichen.

Achtung: Tomcat läuft, einmal gestartet, als Dienst, das heisst auch ohne das Tray-Symbol.

Mit dem Webbrowser kann man unter http://127.0.0.1:8080 nachsehen, ob alles funktioniert.

BIRT-Viewer in Tomcat installieren

Viele Details dazu stehen auf [4] Hier kommt die Kurzfassung.

Zuerst brauchen wir das BIRT-Binary. Das steht auf [5] Wir brauchen die Datei „Runtime“ unter Deployment. Das Zip-File packen wir erst mal in ein temporäres Verzeichnis aus.

Als nächstes suchen wir das Tomcat-Installationsverzeichnis. Unter Windows dürfte das „c:\Programme\Apache Software Foundation\Tomcat 5.5″ sein. Darin findet sich das Verzeichnis webapps, in dem alle Tomcat-Applikationen installiert werden, jede Applikation in einem eigenen Unterverzeichnis. In dieses Unterverzeichnis webapps kopieren wir aus dem temporären Auspackverzeichnis der BIRT-Runtime das Unterverzeichnis WebViewerExample. Schliesslich benennen wir das kopierte Verzeichnis um in birt-viewer.

Um die Applikation zu aktivieren müssen wir den Tomcat einmal stoppen und wieder starten; am einfachsten mit der rechten Maustaste auf das Tomcat-Tray-Icon. Im Browser rufen wir wieder die Startseite von Tomcat auf – http://127.0.0.1:8080/ – und klicken auf „Tomcat Manager“. In der Liste der Anwendungen muss birt-viewer auftauchen.

Für einen ersten Funktionstest der Web-Applikation klicken wir auf „birt-viewer“ in der Tomcat-Liste. Das Eclipse-Symbol und die Bemerkung „BIRT viewer has been installed“ sollte angezeigt werden.

Mit einem Klick auf „View Example“ sollte der Report Viewer angezeigt werden und uns zur korrekten Installation beglückwünschen.

MySQL-Treiber installieren und eigenen Report testen

Auch in der Web-Applikation muss der MySQL-Treiber installiert werden, bevor wir den Test-Report abrufen können. Der Treiber ist wieder die Jar-Datei aus dem vorherigen Beitrag. Diesmal muss sie in das Verzeichnis „WEB-INF\platform\plugins\org.eclipse.birt.report.data.oda.jdbc_2.3.2.r232_v20090212\drivers\“ im birt-viewer-Verzeichnis kopiert werden.

Dann muss der Test-Report in Reichweite der Engine gebracht werden. Es ist die Datei kpi-report1.rptdesign aus dem Workspace des Report-Designer, die nach birt-viewer\Report kopieren.

Im Browser können wir jetzt den Report im BIRT-Viewer direkt aufrufen: http://localhost:8080/birt-viewer/frameset?__report=Report\kpi-report1.rptdesign. Gezeigt wird der komfortable Webviewer mit Frames und Export-Möglichkeiten. Die Engine bietet auch eine web-only, report-only Ansicht, wenn man sie mit run statt frameset aufruft: http://localhost:8080/birt-viewer/run?__report=Report\kpi-report1.rptdesign

Insgesamt kennt die Engine folgende Parameter:

• __format: Output format. „html“ oder „pdf“.
• __isnull: Definiert einen reportParameter als Null
• __locale: Setzt die Java Sprachvorwahl (locale), wie en, de, en-us oder ch-zh. Default: Java-Default
• __report: Pfad zur Report-Datei
• __document: Pfad zum erzeugten Dokument, wenn run und frameset getrennt benutzt werden.
• reportParameter: Ein Parameter, wie im Report design definiert.

Zulässig sind…

• … in frameset: __locale, __report, __document, reportParam
• … in run: __format, __isnull, __locale, __report, reportParam

Beispiel: http://localhost:8080/birt-viewer/run?__format=pdf&__report=Report\kpi-report1.rptdesign&mypara=17

Wichtig bei Parametern und Pfaden: Alles muss URL-kompatibel sein. Bei Leerzeichen oder Umlauten muss gegebenenfalls urlencode() verwendet werden.

Eine vollständige Beschreibung aller Argumente für die Engine steht unter [6].

Der Pfad zur Report-Datei kann absolut oder relativ angegeben werden. Für relative Pfade sucht die Engine mit Hilfe der beiden Settings BIRT_VIEWER_DOCUMENT_FOLDER und BIRT_VIEWER_WORKING_FOLDER in der Datei web.xml im birt-viewer. Wenn die Datei darüber nicht gefunden werden kann, wird das Verzeichnis birt-viewer als Basis genommen.

In der web.xml können auch verschiedene andere Einstellungen gesetzt werden.

Reports aus PHP heraus erzeugen und an den Browser ausliefern

Natürlich können wir die Reports einfach als Link auf die Engine anbieten. Damit liefern wir den Anwendern aber zum einen viele Informationen über unsere Installation und die Reports. Zum anderen ist offen, ob er überhaupt auf den Report-Server und die Portnummer des Tomcat zugreifen kann.

Wir können aber den Aufruf der BIRT-Engine in einem PHP-Skript verbergen und so tun, als ob dieses Skript den Report ausliefert:

<?php
$r = fopen('http://127.0.0.1:8080/birt-viewer/run?__report=Report\kpi-report1.rptdesign&__format=pdf', 'r');
if(!$r) { print "Kann Report nicht öffnen!"; exit; }
header('Content-Type: application/pdf');
fpassthru($r); // gesamte Datei an den Browser liefern
?>

Dieses Skript benutzt die Wrapper-Funktionen, durch man eine URL wie eine Datei öffnen kann. Hier geht natürlich nur die run-Methode der Engine und sämtliche Parameter für den Report müssen bereits beim Aufruf in der URL übergeben werden.

Je nach Laufzeit muss hier unter Umständen ein set_time_limit() eingefügt werden, wenn die Engine länger braucht.

Etwas ähnliches steht unter [7] beschrieben, aber die dortige bewirkt eine Umleitung des Browsers, womit die Original-URL der Engine wieder dem Empfänger bekannt gegeben würde; siehe oben.

Report als PDF erzeugen und abspeichern

Zum Schluss sollen Reports automatisch erzeugt und per Mail verschickt werden. Mit PHP sieht das so aus:

<?php
$rname = 'kpi-report1';
$wname = $rname . '_' . date('Ymd_Hi') . '.pdf';
$pdf = file_get_contents("http://127.0.0.1:8080/birt-viewer/run?__report=Report\\" . $rname . ".rptdesign&__format=pdf");
file_put_contents($wname, $pdf);
?>

Wieder wird der Wrapper benutzt. Der Report wird als PDF komplett geladen und dann in die Zieldatei gespeichert. Als Komfort-Add-on hängen wir einen Zeitstempel und die Dateiendung an den Namen an.

Dieses Skript kann aus einem Batchfile heraus aufgerufen werden, das wiederum zyklisch durch den Windows Scheduler („Geplante Tasks…“) oder unter Linux per cron gestartet werden kann.

Die andere Methode für den Aufruf der Engine führt über Java. Das ist beschrieben in [8] und [9]. Da dies aber für unsere bisherigen Zwecke keine Vorteile bietet, belasse ich es bei den Links.

Oh, Mailversand! PDFs sollten wir als ordentlichen Anhang verschicken. Das geht mit mail() in PHP nicht so einfach. Ich habe gute Erfahrungen mit der SMTP-Klasse von [10] gemacht, aber auf phpclasses.org finden sich verschiedene andere Lösungen, zum Beispiel [11]. Damit sieht der Versand der PDF-Datei oben so aus:

<?php
$mail = new attach_mailer
( $name = "Mein Name",
$from = "me@mymail.com",
$to = "you@gmail.com",
$cc = "kopie@provider.org",
$bcc = "blind@copy.org",
$subject = "Report", $body = "Was zum Report zu sagen ist"
);
$mail->create_attachment_part($wname);
$mail->process_mail();
?>

Links

[1] http://www.eclipse.org/birt/phoenix/deploy/viewerSetup.php
[2] http://java.sun.com/javase/downloads/
[3] http://tomcat.apache.org/
[4] http://www.eclipse.org/birt/phoenix/deploy/viewerSetup.php
[5] http://download.eclipse.org/birt/downloads/
[6] http://www.eclipse.org/birt/phoenix/deploy/viewerUsage.php
[7] http://www.eclipse.org/birt/phoenix/deploy/usingPHP.php
[8] http://www.theserverside.com/tt/articles/article.tss?l=IntegratingBIRTwithPHP
[9] http://www.birt-exchange.com/devshare/deploying-birt-reports/743-calling-birt-from-php/
[10] http://www.phpclasses.org/browse/package/1044.html
[11] http://www.phpclasses.org/browse/package/2822.html

Unser Tool sollte ausserdem eine einigermassen zuverlässige Entwicklerbasis haben. Bei Open Source Software achte ich normalerweise darauf, ob noch regelmässig am Projekt gearbeitet wird und wie groß die Gruppe ist. Wenn es dann noch Teil eines größeren, aktiven Projekts ist, stehen die Chancen gut, dass es weiter gepflegt wird.

Für mich ist derzeit Eclipse BIRT das Reporting-Tool der Wahl. Eclipse ist ein sehr großes Open Source Projekt für eine Software-Entwicklungsumgebung. Es besteht aus einer Basis-Oberfläche, die mit Plug-Ins und Add-Ons erweitert werden kann. Man kann nicht nur in Java, C/C++ oder PHP programmieren, sondern eben auch mit dem BIRT-Plug-In Reports erstellen oder mit dem BPEL-Plug-In Business-Prozesse modellieren.

Eclipse läuft auf allen gängigen Plattformen, die eine Java Runtime-Umgebung bieten. Es besteht zum einen aus dem Report-Designer, mit dem man Reports erstellen, testen und drucken kann, inklusive Export nach PDF, Excel und so weiter. Das reicht schon mal für Einzelanwender, die lokal für sich Berichte erstellen wollen.

Die zweite Komponente ist die Report-Engine, die in einem Java-Applikationsserver installiert wird. Damit kann man lokal erstellte Reports in einem Web-Portal bereitstellen. Beim Aufruf können sogar Parameter abgefragt werden. Den Abruf kann man natürlich auch automatisieren. Das werden wir uns zunutze machen, um zeitgesteuert Berichte zu erzeugen und zu versenden.

Eclipse/BIRT installieren

Für Windows-Anwender ist die einfachste Art der direkte Download von der Projektseite http://download.eclipse.org/birt/downloads/ und dort den Button „All-In-One“. Die Zip-Datei packt man in ein neues Verzeichnis irgendwo auf der Platte aus. Das ist alles. Die Datei eclipse.exe kann direkt gestartet werden.

Wer nicht auf Windows arbeitet findet unter „More Downloads“ auch eine Version für Linux und den BIRT Report-Designer als Plug-In für eine vorhandene Eclipse-Umgebung. Wie man das Plug-In installiert steht unter http://www.eclipse.org/birt/phoenix/build/#updating

Kontakt zur Datenbank

Für die Verbindung zu unserer MySQL-Datenbank benötigen wir noch einen JDBC-Treiber. Den gibt es bei MySQL.com unter dem Namen „MySQL Connector/J“ auf der MySQL-Downloadseite. Windows-User laden am besten die Zip-Version. Aus diesem Archiv kopieren wir die Datei mysql-connector-java-5.1.6-bin.jar (oder die gerade aktuelle Version) erst mal in das Eclipse-Verzeichnis. Sie wird später bei unserem ersten Report integriert.

Erststart, Datenquelle und erster Report

Ziel des ersten Berichts ist eine Wochenübersicht ausgewählter Messwerte als Kreuztabelle und Grafik. Die Kreuztabelle soll die Namen der Messstellen zeilenweise auflisten und das Tagesdatum als Spalten. Zeilen- und Spaltensummen sind selbstverständlich. Die Grafik soll für jeden Tag der Woche die Tageswerte der Messstellen übereinander gestapelt anzeigen. Los geht’s:

• Eclipse.exe starten
• Workspace auswählen, optional: Neuen Ordner anlegen (empfohlen)
• Für Erstanwender ist es auch empfehelnswert, den „Overview“ anzugucken
• Danach „To Workbench“ – Zur Arbeitsumgebung
• Zuerst ein neues Projekt anlegen: File / New / Project… / Business Intelligence and Reporting Tools / Report Project. Name „KPI“.
• Eclipse fragt, ob es die Oberfläche entsprechend anpassen soll: „Open Perspective?“; ja, das ist eine gute Idee.
• Im neuen Projekt einen neuen Report anlegen: File / New / Report;Parent Folder: KPI;File name: „kpi-report1.rptdesign“;Type of Report: „Blank Report“

Datenquellen

Um echte Daten in den Report einzufügen brauchen wir mindestens eine Datenquelle (Data Source). Das ist bei uns unsere MES-Datenbank. Das Hinzufügen geht so: Data / New Data Source / Create from a data source in the following list / JDBC Data Source. Data source name: „KPI“. Der Name ist willkürlich.

Jetzt wird einmalig der MySQL-Datenbank-Treiber mit BIRT verbunden: „Manage Drivers…“ / Tab „JAR Files“ / „Add…“. Wenn der mysql-driver im Eclipse-Verzeichnis liegt, steht er in der Liste. Einfach auswählen und Okay klicken.

Weiter mit der Definition der Datenquelle:

• Zurück in „Create a new data source. Driver class: „com.mysql.jdbc.Driver (v5.1)“ wählen, das ist der eben hinzugefügte Treiber
• Die Driver URL enthält Verbindungstyp, Datenbanktyp und die Verbindungsparameter nach dem Schema: „jdbc:mysql://[host][,failoverhost...][:port]/[database]„. Bei lokaler Datenbank kann man das meiste weglassen: „jdbc:mysql:///mes“, wobei „mes“ der Datenbankname in MySQL ist. Näheres steht in der Dokumentation zum Treiber unter http://dev.mysql.com/doc/refman/5.1/en/connector-j-reference-configuration-properties.html
• Zum Schluss: Username und Passwort eingeben und Finish klicken

Data Set

Zur Datenquelle können wir jetzt Data Sets anlegen. Data Sets sind entweder einzelne Abfragen aus genau einer Datenquelle oder ein „Joint Data Set“ aus zwei verschiedenen Datenquellen.

• Data / New Data Set / New Data Set.
• Data Source Selection: „KPI“.
• Data Set Type: „SQL Select Query“.
• Data Set Name: „Wasser“.
• Als Query nehmen wir die „Daten der letzten Woche“:
  

  select * from tagvalues v
join tagequipment e on v.tagname = e.tagname
where e.eqpath = 'Wasser/STW/Verbraucher/Sekundär'
and v.time like '____-__-__'
and v.time between from_days(to_days(now()) - (7 + weekday(now()))) and from_days(to_days(now()) - (1 + weekday(now())))

• Weil Zeitangaben und Messwerte als Strings aus der Datenbank kommen, legen wir Computed Columns an, die in den passenden Datentyp wandeln:
  Column Name: Datum; Data Type: Date; Expression: row["time"]
  Column Name: Wert; Data Type: Float; Expression: Math.round(new Number(row["value"]))
  
• Preview Results

Statt der Computed Columns hätten wir auch in der SQL-Abfrage selbst die passenden Typen durch MySQL-Funktionen herstellen können. Das ist weitgehend Geschmackssache. Geschwindigkeitsunterschiede habe ich noch nicht getestet.

Daten für Kreuztabelle anlegen

Für die Kreuztabelle benötigen wir einen Data Cube. Cube deshalb, weil er im Gegensatz zu einer einfachen Tabelle, wie sie aus der SQL-Abfrage kommt, die Werte („measures“) über mehrere sogenannte Dimensions in Beziehung setzt. Dimensions spannen sozusagen Koordinatensysteme auf, in deren Kreuzungspunkten die jeweiligen Werte stehen. Bei zwei Dimensions – Name der Messstelle und Tagesdatum – ist der Cube eine Kreuztabelle. Näheres zu Data Cubes steht zum Beispiel in der Wikipedia unter Cube_(OLAP).

• Im Outline oder Data Explorer bei Data Cubes rechts klicken und „New Data Cube“ wählen.
  Der Name soll „WasserCube“ sein.
  Mit Rechtsklick auf „WasserCube“ und „Edit“ die Einstellungen öffnen
• Als Dataset „Wasser“ wählen.
• Bei Groups and Summaries werden die Dimensionen und Measures festgelegt
• Feld „Datum“ in die Groups ziehen („Drop a field here to create a group“), um eine Group bzw. Dimension zu erzeugen
• Feld „eqproperty“ ebenso erzeugt eine zweite Gruppe mit den Namen der Messstellen
• Feld „Wert“ in die Summaries ziehen

Der Data Explorer (linke Spalte) sollte so aussehen:

Crosstab (Pivot-Tabelle) anlegen

Jetzt kann die eigentliche Kreuztabelle angelegt werden.

• Im Hauptfenster den Tab Layout anwählen. Hier wird der Bericht entworfen
• Aus der Palette eine Crosstab auf die Fläche ziehen
• Im Data Explorer den WasserCube ausklappen und die Group mit eqproperty in die linke Zelle ziehen („… to define rows here“).
• Desgleichen die Group mit time in die obere Zelle ziehen („… to define columns here“).
• Summary Field1 aus WasserCube in das Summenfeld ziehen („… to be summarized here“).

Das Ergebnis können wir sofort testen durch einen Klick auf den Tab Preview oder über das Menü mit Run / View Report / as PDF
Im Detail können noch sehr viele Einstellungen optimiert werden.

Chart anlegen

Charts zu erzeugen funktioniert ebenso wie bei der Kreuztabelle. Das Tagesdatum – Spalte „Datum“ – wird auf die X-Achse gestellt, die Messwerte auf die Y-Achse. Die Stapelung der Werte pro Tag wird durch Gruppierung nach den Namen der Messstellen erreicht.

• Layout anklicken und aus der Palette ein Chart auf die Fläche ziehen.
• Rechtsklick auf das Chart im Layout für die Einstellung der Parameter.
• Chart-Typ: Gestapelt

• Select Data:
• Use Data from: „Data Source Wasser“
• Value Series: Spalte „Wert“ ins Feld ziehen
• Category Series: Spalte „Datum“ ins Feld ziehen
• Y Series Grouping: Spalte „eqproperty“ ins Feld ziehen

• Format Chart: Achsenbeschriftungen einstellen, X-Axis, Format Datum

Fertig. Den ganzen Report mit Tabelle und Grafik sehen wir durch einen Klick auf Preview oder Run / View Report / as PDF. Meinen habe ich hier etwas unkenntlich gemacht, weil ja Originaldaten drin sind.

CREATE TABLE  TagValues
(
tagname varchar(128) NOT NULL, -- Name des Datenpunktes
time varchar(20) NOT NULL, -- Zeit als String
timetype varchar(10),  -- Zeitliche Auflösung
value varchar(50) NOT NULL, -- Wert
PRIMARY KEY  (tagname,time,timetype),
KEY tagvalue_time (time,timetype)
);

Alles Strings? Bei MySQL als Datenbank und PHP als Skriptsprache ja, denn da ist die Konvertierung einfach. Der Speicherplatz stellt bei der Anzahl der Zeilen auch kein gravierendes Problem dar. Man gewinnt aber eine Menge Komfort bei den Abfragen aus dem Report-Tool. Der Trick steckt ausserdem in der Kodierung der Zeit als ISO-8601-String, siehe [ISO-Zeitkodierung].

Die Felder im Einzelnen:

• tagname – der Name des Datenpunktes. Wir genehmigen uns ausreichend Platz für sprechende Namen, auch wenn wir gleich noch weitere Ordnungsmerkmale einführen.
• time – Zeitstempel in ISO-8601-Schreibweise.
• timetype – Zeitintervall des Werts. Ich verwende einfach die Buchstaben der PHP date()-Funktion, also zum Beispiel d = Tageswert, m = Monatswert, H = Stundenwert, usw. Man braucht dieses Feld nicht unbedingt, wenn man einen Mustervergleich mit like auf das Feld time einfügt. Aber die Abfrage auf „timetype=’d'“ ist schneller und übersichtlicher.
• value – der eigentliche Wert. Bei Fliesskommawerten muss auf Punkt statt Komma für die Dezimalstellen geachtet werden, dann kann MySQL mit den Werten sofort rechnen. Genauer: Ein Komma in einer Zahl beendet die Zahl. Für MySQL ist ’2,5′ = 2, aber ’2.5′ bleibt beim Rechnen zweieinhalb.

Wie groß kann die Wertetabelle werden? Das wurde in http://openmes.wordpress.com/2008/12/18/wieviel-reporting-braucht-der-mensch-teil-ii/ schon mal ausgerechnet: Bei 400 Datenpunkten mit den Auflösungen Tag, Woche, Monat, Jahr insgesamt 172.800 Werte pro Jahr. Für meine Experimente nehme ich fast das 40-fache: 1000 Datenpunkte, 3 Jahre. Macht: 432*1000*3 = 1.296.000 Zeilen. Durchschnittliche Zeilenlänge ist 52 Byte, also ist eine Gesamtgröße der Tabelle von ungefähr 67,4MB zu erwarten.

Die größten Kosten der Abfragen werden in der Selektion der gewünschten Werte liegen, weil wir ja die Werte aller Datenpunkte und ihrer Intervalle in eine Tabelle packen. Die Wochenwerte des vergangenen Jahres für 10 bestimmte Datenpunkte sind 53*10 = 530 Werte aus 1,3 Mio. Zeilen. Daher der Index, der timetype und time kombinieren.

Kritisierbar ist natürlich, bei jedem Wert den Tagname als String abzuspeichern, weil er meistens mehrfach mehr Speicherplatz benötigen wird als der eigentliche Wert. Normalerweise würde man eine Beschreibungstabelle für Datenpunkte erstellen und jedem Datenpunkt eine eindeutige ID zuordnen. Kann man machen, wenn man das will. Vorteil der String-Methode ist jedoch, dass die Tabelle auch für sich alleine funktioniert, zum Beispiel auch nach dem Export nach Excel oder CSV. Die Definitionstabelle machen wir jedoch trotzdem.

CREATE TABLE  TagDefs
(
tagid int(10) unsigned NOT NULL auto_increment,
tagname varchar(128) NOT NULL,
physunit varchar(25),
description varchar(25),
label varchar(128),
PRIMARY KEY  USING BTREE (tagid,tagname)
);

Hier spendieren wir eine Unique ID, schaden kann’s nicht. Ausserdem hinterlegen wir die physikalische Einheit der Messwerte und einen Beschreibungstext, der zum Beispiel den Ort des Messgebers enthält oder eine innerbetriebliche Referenznummer. Das Label hingegen soll der Text sein, der zu diesem Datenpunkt in Reports angezeigt wird.

Für kleinere Anwendungen dürften diese zusätzlichen Attribute zu Tags ausreichend sein. Wenn man aber die gleichen Messwerte aus unterschiedlichen Perspektiven zusammenstellen möchte braucht es meist mehr Ordnungskriterien, die man in den Berichten zur Selektion benutzen kann.

Exkurs:

Equipment und Properties. Die meisten MES-Pakete lehnen sich an die ISA-S95 an, die eine Produktionslandschaft in eine bestimmte Hierarchie aufteilt, genannt Enterprise / Site / Area / Cell / Unit. Eine vollständige Angabe von Enterprise bis Unit nennt sich Equipmentpath und bezeichnet eine einzelne Produktionseinheit. Equipmentpfade werden in der Regel durch ‘/’ oder ‘.’ getrennt. „Hummel-Honig/Werk_Hintersen/Bereich_Hinten/Abfüllung_1/Füller_3″ wäre ein vollständiger Equipmentpfad zu einem Objekt „Füller 3″.

Jedem so beschriebenen Objekt können Properties – Eigenschaften bzw Attribute – zugeordnet werden. Das gilt auch für Zwischenebenen wie eine Area oder Site. Properties werden dann mit realen Datenpunkten verknüpft. Zum Beispiel wäre die aktuelle Auftragsnummer am „Füller 3″ eine Property dieser Unit.

Ende Exkurs.

Energie- und Verbrauchsdaten stehen allerdings etwas quer zur S95-Struktur, weil viele ihrer Elemente nicht direkt Teil der Produktion sondern der Infrastruktur sind: Trafos, Lüfter, Brauchwasserleitungen, usw. Deshalb erlauben wir, dass jedem Datenpunkt mehrere Equipmentpfade und Properties zugeordnet werden können. Nur die Kombination Pfad+Property muss unique sein.

CREATE TABLE  TagEquipment
(
tagname varchar(128) NOT NULL,
eqpath varchar(255) NOT NULL,
eqproperty varchar(128) NOT NULL,
description varchar(255),
label varchar(128),
PRIMARY KEY  (eqpath,eqproperty)
);

Wie bei der Tagdefinition erlauben wir pro Satz je einen beschreibenden Text und ein Label für die Anzeige.

Jetzt können wir zusätzlich zu den durch die Produktion definierten Equipmentpfaden zusätzliche Ordnungen über unsere Fabrik legen. Zum Beispiel könnte „Hummel-Honig/Werk_Hintersen/Wasser/Entsorgung/Abwasser“ das Selektionskriterium für alle Abwassermessungen sein. Wir sind aber nicht an die Site/Area/Cell/Unit-Struktur gebunden, sondern können den Pfad beliebig verkürzen oder erweitern. Beispiel: „Wasser/Entsorgung/Abwasser“ wird als Prefix in allen Pfaden verwendet, die Abwasser messen. Beim Füller 3 von oben wird auch Abwasser gemessen. Der Equipmentpfad könnte also zum Beispiel „Wasser/Entsorgung/Abwasser/Abfüllung_1″ sein und die Property „Füller_3″. Ob man Enterprise und Site vorschaltet hängt davon ab, ob man tatsächlich Werte aus mehreren Werken in der gleichen Datenbank hat.

Welche Abfragen sind dadurch möglich?

Zum Beispiel „alle Abwasser-Messwerte im ganzen Werk“:

"select * from tagequipment where eqpath like 'Wasser/Entsorgung/Abwasser/%'"

Oder „alle Wasser-Messwerte von Füller 3″:

"select * from tagequipment where eqpath like 'Wasser/%' and property = 'Füller_3'"

Wie man sieht, muss man nur aufpassen, Füller 3 auch jedes Mal gleich zu benennen. Die Definitionen, Bezeichnungen, Pfade und so weiter für ein paar hundert Datenpunkte konsistent zu halten ist eine friemelige Arbeit, die häufig in großen Excel-Tabellen endet.

Wir können aber auch Konsistenzprüfungen auf unserer Datenbank durchführen. Zum Beispiel: Sind für alle Tags Definitionen verfügbar? "select distinct tagname from tagvalues where tagname not in (select tagname from tagdefs)"

Das geht genauso für Equipments.

Mit diesen Definitionen erzeugen wir eine Datenbank mit Testdaten. Ich nehme mir einfach meine echten Kundendaten, aber genauso gut kann man Zufallszahlen durch ein Skript erzeugen lassen.

Im nächsten Teil geht es dann endlich ums das Reporting selbst: Berichte für lau – Reporting mit BIRT

• Die Installation war aufwändig, kompliziert und ohne spezielle „unter der Hand“-Doku nicht zu bewerkstelligen.
• Das Webportal läuft nur mit IIS, der wirklich nicht easy zu administrieren ist.
• Die Software kann sehr viel mehr als was benötigt wurde. Diese Über-Features erzeugten zusätzlichen Arbeitsaufwand.
• Das Reporting ist eigentlich sehr komfortabel (Abfragen aus Objektbaum zusammenklicken), aber die Implementation des Objektverzeichnisses (SQL-Makro-Ersetzung) führt zu sehr langwierigen Abfragen (bis über 10 Minuten Laufzeit).
• Alle Daten (Rohdaten und verdichtete) sind in einem Topf, der damit sehr groß und unübersichtlich wird.
• Die Datenaufzeichnung und das Reporting haben unterschiedliche Vorstellung von Zeitstempeln und UTC, was bei Sommerzeit und Jahreswechseln zu Problemen führte, die in der Zwischenschicht gelöst werden mussten.

Aber kann man die Aufgabe auch anders lösen? Mit freier Software, weniger Aufwand und weniger Problemen mit den riesigen Paketen? Ich wünsche mir:

• Ein schlankes System, das einfach zu installieren und zu administrieren ist.
• Möglichst große Unabhängigkeit von Betriebssystem-Features oder bestimmten Releases eines Betriebssystems
• Schnelle Abfragen und Auswertungen
• Trennung zwischen Rohdatenaufzeichnung und verdichteten Daten
• Sinnvolle Datums- und Zeitstempel, die für Abfragen in den Reports geeignet sind.

Lassen wir die Datenaufzeichnung erst mal weg und gehen auf das Reporting. Diese Teilaufgabe lautet: Aus einer Datenbank mit Tages/Wochen/Monatssummen werden automatisch und per Abfrage im Webportal Berichte erzeugt. Die automatisch erzeugten Berichte werden per Mail an verschiedene Empfänger verschickt. Wir brauchen also:

• Datenbank-Tabellen mit Definitionen der Datenpunkte und den Werten.
• Reporting-Engine, webfähig
• Report-Designer
• Automatische Report-Erzeugung als PDF, zeitgesteuert
• Mailversand für die erzeugten PDFs an verschiedene Adressen
• Archiv für die erzeugten PDFs mit Auflistung und Ansicht/Download
• Web-Portal für Report-Auswahl und Konfiguration des Mailversands

Und eben mit freier Software, möglichst portabel und einfach zu realisieren.

Nächster Teil: Datenpunkt-Tabellen und SQL für das KPI- und Verbrauchsdatenarchiv

1. There are three states of being. Not knowing, action and completion.
2. Accept that everything is a draft. It helps to get it done.
3. There is no editing stage.
4. Pretending you know what you’re doing is almost the same as knowing what you are doing, so just accept that you know what you’re doing even if you don’t and do it.
5. Banish procrastination. If you wait more than a week to get an idea done, abandon it.
6. The point of being done is not to finish but to get other things done.
7. Once you’re done you can throw it away.
8. Laugh at perfection. It’s boring and keeps you from being done.
9. People without dirty hands are wrong. Doing something makes you right.
10. Failure counts as done. So do mistakes.
11. Destruction is a variant of done.
12. If you have an idea and publish it on the internet, that counts as a ghost of done.
13. Done is the engine of more.

Immer wieder sollen Produktionsdaten zeitlich eingeordnet und in Berichten zusammengestellt werden. Das sind Verbrauchswerte oder erzeugte Produkte. Und immer wieder ist wenigstens für mich der Aufwand ärgerlich, mit Datum, Uhrzeit, Schichtmodellen, Sommer/Winterzeit und so weiter rumzurechnen, bzw. die Daten per SQL irgendwo herauszufischen.

Die Ursache des Aufwands liegt für mich in der Genauigkeit. Der Datentyp Datetime oder auch die Unix time() ist immer bis auf die Sekunde genau. Aber welcher Zeitpunkt gilt für eine ganze Woche? 23:59:59 am Sonntag? 00:00:00 am Montag? Und wenn, wie beim Beispielkunden, die Woche von Sonntag bis Samstag geht und die Daten vom Werk in die Konzernzentrale in einer anderen Zeitzone berichtet werden? Gleiches gilt für Tage (Sommerzeit, Zeitzonen) und Monate.

Wenn ich einen Wochenwert abspeichern möchte, dann mit der Angabe Jahr-Woche. Schichtwerte mit der Angabe Jahr-Monat-Tag-Schicht, usw. Dann kann ich sie auch per SQL einfach selektieren.

Also wie geht das? Dafür gibt es die Schreibweisen der ISO-8601. Ausführliche Beschreibungen gibt es hinter den unten angegebenen Links. Für unsere Zwecke – Produktionsdaten mit Zeitangaben – reichen folgende Konventionen:

Tagesdatum: ’YYYY-MM-DD’ – Eigentlich ’[YY]YY[-]MM[-]DD’, aber wenn man die ’-’ und oder das Jahrhundert weglässt, kann das in einem SQL-Query missverständlich werden. Also: Jahr-Monat-Tag immer mit 4-stelligem Jahr und ’-’ als Trenner.

Die Angaben können von rechts weggelassen werden: YYYY-MM = Monatswert, YYYY = Jahreswert.

Eine Erweiterung der ISO möchte ich mir herausnehmen: ’YYYY-MM-DD"S"S’ für die Schicht, zum Beispiel 2009-02-05S2 = Zweite Schicht am 5.2.2009. Richtig nett wird es nämlich, wenn man sekundengenaue Zeitstempel bei Schichtmodellen verwendet. Dann muss man sämtliche Schichtmodelle archivieren, um vor der eigentlichen Abfrage herauszufinden, welches Schichtmodell an welchem Tag gültig war. Die Beantwortung der Frage, wie hoch die Ausschussrate in allen ersten Schichten der vergangenen 12 Monate war ist damit nicht mehr trivial: Sonderschichten, Sommer/Winterzeit, ausgefallene Schichten („Montags fangen wir immer erst zur Spätschicht an“), usw.

Wochendatum ’YYYY-"W"WW[-D]’ – Das ist eine Kalenderwoche mit optionalem Tag in der Woche. Beispiel: 2009-W07 = Kalenderwoche 7 in 2009 oder 2009-W07-3 = Der dritte Tag in KW7 in 2009. Dabei ist die ISO-Kalenderwoche sehr genau definiert; Montag – Sonntag, erste Kalenderwoche ist die mit mindestens 4 Tagen. Das kollidiert allerdings manchmal mit der Arbeitswoche einiger Firmen.

Die Wochentagskodierung mit angehängtem -D zu verwenden sollte man sich gut überlegen. Hier ist die Umrechnung oder der Vergleich mit den anderen Tages-Kodierungen wie YYYY-MM-DD oder YYYY-DDD nicht so einfach. Am besten verwendet man so häufig wie möglich die gleiche Kodierung, um sich Umrechnungen und kombinierte Abfragen (UNION) zu sparen.

Uhrzeiten ’HH[:MM[:SS]]’ – Uhrzeiten können laut ISO mit einem Leerzeichen oder „T“ dazwischen an jedes Tagesdatum angehängt werden. Wieder kann von rechts weggelassen werden: HH:MM = Minute, HH = Stunde.

Zeitspannen, „P“ – Zwei Datum/Zeitangaben können laut ISO mit einem „P“ kombiniert werden, um die Zeitspanne zwischen ihnen zu kodieren. Beispiele: 2000P2008 = Jahre 2000 bis 2008, 2007-01P2007-03 = Erstes Quartal 2007, 2008-W10P2008-W19 = Wochen 10-19 in 2008 komplett.

Als Zeitangabe in einer Datenbank ist mir das noch nicht begegnet. Ich würde es auf den ersten Blick auch ungern verwenden, weil ungeschickte Abfragen mit Mustervergleichen versehentlich auch diese Werte liefern könnten.

SQL-Abfragen für ISO-8601 Datums- und Zeitangaben

Wenn wir jetzt eine große Tabelle mit gemischten Datumswerten haben, zum Beispiel meine geliebten Energie- und Verbrauchszahlen als Tages-, Wochen- und Monatssummen; wie kriegen wir dann die gewünschten Daten heraus? Das hängt von der verwendeten Datenbank ab.

Am komfortabelsten ist MySQL, weil es automatisch von String in Datum umrechnet. Wir nehmen eine Tabelle mit den Spalten tagname, zeit und wert. Zeit ist als varchar() definiert und kann alle oben angegebene Datumsformate enthalten.

Beispiele:

(1) Alle Tageswerte der letzten sieben Tage:

select * from isozeit
where zeit like ’____-__-__’
and zeit > subdate(now(), interval 7 day)


Der Mustervergleich ’____-__-__’ selektiert das Tagesformat, das nach obigen Konventionen eindeutig ist. Deshalb die Pflicht, den ’-’ zwischen die Felder zu schreiben.

(2) Wochenwerte dieses Jahres:

select * from isozeit
where zeit like concat(year(now()), ’-W__’)

Die Abfrage ist sicher, weil sie optional angehängte Wochentage (’-D’) ausblendet.

(3) Werte mehrerer Wochen, z.B. Woche 10-19, wie oben erwähnt:

select * from isozeit
where time like ’____-W__’
and zeit between concat(year(now()), ’-W10’) and concat(year(now()), ’-W19’)

Die Wochennummern kann man natürlich auch relativ berechnen. Leider ist das „-W“ im between-Teil allein nicht ausreichend, um angehängte Wochentage auszuschliessen, daher das zusätzliche like ’____-W__’.

(4) Wochenwerte der vergangenen Woche:

select * from isozeit
where zeit = date_format(subdate(now(), interval 1 week), ’%x-W%v’)

Hier glänzt MySQL richtig. Date_format() kann nämlich verschiedene Wochenzählweisen und liefert dann Jahr und Woche entsprechend.

Beispiel:

select date_format(’2008-12-31’, ’%x-W%v’), date_format(’2009-01-01’, ’%x-W%v’),
date_format(’2008-12-31’, ’%X-W%V’), date_format(’2009-01-01’, ’%X-W%V’)

liefert:

’2009-W01’, ’2009-W01’, ’2008-W52’, ’2008-W52’

’%x-W%v’ ist also die europäische (und ISO-)Zählung; ’%X-W%V’ die US-/UK-Zählung.

Bei anderen DBs wird es etwas komplizierter. MS-SQL kennt datepart(), aber die Art der Wochenzählung kann nur global eingestellt werden. Könnte man den Wochencode auch aus year() und week() zusammensetzen, zum Beispiel mit

concat(year(subdate(now(), interval 1 week)), ’-W’, week(subdate(now(), interval 1 week)))

Leider nicht. Wenn die Woche 1 des aktuellen Jahres im vergangenen Jahr beginnt, liefert year() möglicherweise bereits das aktuelle Jahr und week() 0. Beweis:

select yearweek(’2009-01-01’), year(’2009-01-01’), week(’2009-01-01’)

(5) Tageswerte der vergangenen Woche, z.B. für einen Wochenreport:

select * from isozeit
where zeit like ’____-__-__’
and zeit
between from_days(to_days(now()) - (7 + weekday(now())))
and from_days(to_days(now()) - (1 + weekday(now())))

Uff. Das ist nicht ganz einfach, aber die scheinbar einfachere Lösung,

where date_format(zeit, ’%x%v’) = date_format(subdate(now(), interval 1 week), ’%x%v’)

würde bewirken, dass der erste date_format()-Term für jeden Datensatz durchgeführt würde.

Noch etwas flinker wäre vielleicht

zeit between date_format(from_days(to_days(now()) - (7 + weekday(now()))), ’%Y-%m-%d’) and date_format(from_days(to_days(now()) - weekday(now())), ’%Y-%m-%d’)

aber wahrscheinlich wandelt MySQL die from_days()-Terme schon gleich vor dem ersten Vergleich zu Strings. Ich konnte jedenfalls keinen Unterschied messen.

(6) Monatssummen aus Tageswerten bilden:

select tagname, year(zeit), month(zeit), sum(wert) from isozeit
where time like ’____-__-__’
group by 1,2,3
order by 1,2,3

Das ist einfach.

Allerdings weiss man noch nicht, ob auch für alle Tage des jeweiligen Monats Daten vorliegen, die Summe also korrekt ist. Das kann man durch eine zusätzliche Spalte

count(wert) = day(last_day(zeit))

ermitteln. Hier steht 1 für korrekt und 0 für fehlerhaft. Last_day() ist wieder ein Pluspunkt für MySQL. Es liefert das Datum des letzten Tages im angegebenen Monat.

(7) Wochensumme aus Tageswerten? Okay.

select tagname, date_format(zeit, ’%x-W%v’), sum(wert), count(wert) = 7 from isozeit
where zeit like ’____-__-__’
group by 1,2
order by 1,2

Gut, dass Wochen immer sieben Tage haben.

(8) und zum Schluss: Sind die Wochenwerte gleich der Summe der Tagswerte der Woche? Das sieht zunächst einfach aus:

select a.tagname, a.woche, a.summe, b.summe, a.korrekt, a.summe=b.summe
from
( select tagname, date_format(zeit, ’%x-W%v’) as woche, sum(wert) as summe, (count(wert) = 7) as korrekt
from isozeit where zeit like ’____-__-__’ group by 1,2 order by 1,2
) a
join
( select tagname, zeit as woche, wert as summe, 1 as korrekt
from isozeit where zeit like ’____-W__’ group by 1,2 order by 1,2
) b
on a.tagname=b.tagname and a.woche=b.woche

Subselect a kennen wir aus (7). Subselect b sind die Wochenwerte. Nur macht mir auf meinem Rechner MySQL einen Strich durch die Richtung, weil es zwar bei Typen tolerant ist, aber nicht bei Zeichensätzen. Die stimmen bei den Subselects wegen der Berechnung nicht überein, deshalb musste ich bei mir folgendes schreiben:

select a.tagname, a.woche, a.summe, b.summe, a.korrekt, a.summe=b.summe
from
( select
convert(tagname using latin1) as tagname,
convert(date_format(zeit, ’%x-W%v’) using latin1) as woche,
convert(sum(wert) using latin1) as summe,
convert((count(wert) = 7) using latin1) as korrekt
from isozeit where zeit like ’____-__-__’ group by 1,2 order by 1,2
) a
join
( select
convert(tagname using latin1) as tagname,
convert(zeit using latin1) as woche,
convert(wert using latin1) as summe,
convert(1 using latin1) as korrekt
from isozeit where zeit like ’____-W__’ group by 1,2 order by 1,2
) b
on a.tagname=b.tagname and a.woche=b.woche

Das soll an Beispielen reichen. Ähnliche Abfragen für die anderen Formate können ziemlich direkt abgeleitet werden.

Links

Wikipedia (dt): ISO-8601
Wikipedia (en): ISO-8601
The Mathematics of the ISO 8601 Calendar
http://www.dmoz.org/Science/Reference/Standards/Individual_Standards/ISO/ISO_8601/

Ganz dem Ubuntu-Gedanken folgend, gibt es das Buch zum freien Download als PDF und als gedruckte Ausgabe.

Teil 3: XAMPP installieren

Profis würden jetzt die Pakete einzeln installieren; Apache, MySQL, PHP, Perl. Kann man auch, aber es dauert eine Weile und man muss an vielen Stellen Einstellungen ändern, Dateien verschieben und so weiter.

Deshalb holen wir uns das Komplettpaket XAMPP von Apachefriends.org. Das gibt es für Linux, Windows und Mac, und es ist gerade auf Linux sehr einfach zu installieren.

Download und Installation

• In der VM den Firefox-Browser öffnen, entweder oben in der Mitte des Bildschirms oder über Anwendungen / Internet.
• apachefriends.org im Browser aufrufen und XAMPP für Linux anwählen. Die Seite am besten mal kurz durchlesen.
• XAMPP Linux runterladen. Normalerweise speichert Firefox ins Desktop-Verzeichnis, in unserem Fall /home/mes/Desktop.
• Terminal-Fenster (Shell) öffnen (Anwendungen / Zubehör / Terminal) und ins Download-Verzeichnis wechseln: „cd Desktop“
• Prüfen, dass das XAMPP-Paket hier liegt: „ls -l“
  Es sollte xampp-linux-1.7.tar.gz oder ähnlich heissen
• Jetzt folgt der Zauberspruch für die Installation: „sudo tar xvfz xampp-linux-1.7.tar.gz -C /opt“
  Dabei wird das User-Passwort abgefragt; siehe Teil 2.

Das war’s schon. Was ist passiert? Der Inhalt des Pakets wurde in das System-Verzeichnis opt entpackt. Mehr muss man nicht tun, um XAMPP lauffähig zu installieren.

Im einzelnen:
„sudo“ – den folgenden Befehl im „super user“-Modus ausführen, deshalb die Passwortabfrage.
„tar“ – ist ein Standard-Unix Pack/Entpackprogramm. Dateien mit der Endung tar sind seine.
„xvfz“ – sind die Parameter für tar: x = entpacken; v = verbose, viel Ausgabe; f = es folgt ein tar-Dateiname; z = es ist ein komprimiertes tar (.gz).
„xampp-linux-1.7.tar.gz“ – der Paketname
„-C /opt“ – eine Option von tar, bedeutet Auspacken in das folgende Verzeichnis (/opt).

Warum „/opt“? Das ist Konvention. Technisch könnten wir XAMPP und jedes andere Programm in jedem Verzeichnis abspeichern und starten. Aber opt ist das traditionelle Systemverzeichnis für optionale Pakete.

Erststart

Im schon geöffneten Terminal tippen wir: „sudo /opt/lampp/lampp start“

„sudo“ kennen wir schon. „/opt/lampp/lampp“ ist das Startprogramm für XAMPP im Verzeichnis /opt/lampp und „start“ heisst genau das: XAMPP starten. Die anderen Optionen für das Startprogramm sind „stop“ und „restart“.

Es sollte „XAMPP fuer Linux gestartet“ ausgegeben werden. Wenn ja, dann laufen jetzt Apache (Webserver), MySQL (Datenbank) und PHP sollte auch verfügbar sein. Das testen wir im Firefox, indem wir localhost oder 127.0.0.1 aufrufen. Der Splash-Screen von XAMPP sollte erscheinen. Wir klicken auf „Deutsch“ – die Hauptseite von XAMPP erscheint – und danach links auf „Status“.

So sollte es dann auf dem Bildschirm aussehen:

Wo ist was?

Das wichtigste Verzeichnis auf unserer VM ist jetzt /opt/lampp/htdocs. Das ist das Web-Hauptverzeichnis. Zum Test erstellen wir eine erste PHP-Seite.

• Im Terminalfenster ins Web-Verzeichnis wechseln: „cd /opt/lampp/htdocs“
• Mit einem Editor eine neue Datei anlegen: „sudo gedit info.php“
• In diese Datei die Zeile „<?php phpinfo(); ?>“ eintippen
• Abspeichern, und
• im Firefox „localhost/info.php“ aufrufen.

Wenn alles geklappt hat, sollte folgendes zu sehen sein:

Gruppenarbeit (Berechtigungen)

Warum schon wieder sudo bei einem simplen Editor? Weil /opt ein Systemverzeichnis ist, in dem wir als Benutzer mes eigentlich nicht schreiben dürfen. Andererseits muss der Webserver die Dateien auch lesen dürfen. Das heisst: Bei allen Dateien, die wir über den Webserver verarbeiten wollen, müssen wir darauf achten, dass die Leserechte ausreichen.

Der Webserver läuft unter dem User nobody. Wir sind normalerweise als mes angemeldet und mit sudo sind wir plötzlich root, also Systemadministrator.

Welche Berechtigungen bei einer Datei gesetzt sind, sieht man mit „ls -l“.

Wichtig für uns: Vor jeder Datei, die der Webserver verarbeiten soll, müssen links in der ls-Liste drei „r“ stehen. Drei, weil es die Lese-Berechtigungen („read“) für den Besitzer, die Gruppe des Besitzers und „other“ sind. Sollten keine drei „r“ dort stehen, kann man sie mit „sudo chmod ugo+r dateiname“ setzen. Alles weitere erklärt die man page für chmod, die man im Terminalfenster mit „man chmod“ ansehen kann. Die Kurzfassung gibt es mit „chmod –help“.

Automatischer Start

Leider müssen wir XAMPP bei jedem Start der VM neu starten („sudo /opt/lampp/lampp start“). Das ist hinderlich, deshalb benutzen wir die immer noch geöffnete Shell (das Terminalfenster), um XAMPP automatisch mit Ubuntu zu starten:

• Wechseln ins Verzeichnis /etc: „cd /etc“
• Die Datei rc.local in einen Editor laden: „sudo nano rc.local“
• vor „exit 0″ die Zeile „sudo /opt/lampp/lampp start“ einfügen
• Beenden mit Strg-X, speichern bestätigen mit J

Jetzt die VM neu starten, um den Autostart zu testen.

Was haben wir getan? Die Datei „/etc/rc.local“ enthält Befehle, die beim Start von Ubuntu ausgeführt werden. Normalerweise ist sie leer, aber aufgerufen wird sie trotzdem. Wir haben einfach die Zeile eingefügt, die wir sonst per Hand eintippen müssten.

Linux-Profis werden hier möglicherweise die Nase rümpfen; wenn sie diese Anleitung überhaupt lesen. Ja, es gibt andere Wege, Programme beziehungsweise „Dienste“ beim Systemstart zu starten. Aber wir bauen eine Spielwiese und beschränken uns auf die einfachste Methode.

Und nu?

Well, die Spielwiese läuft. Am besten jetzt eine Kopie der VM erstellen, denn so rein und frisch kriegen wir sie nie wieder zusammen. Der nächste Teil, Installation von Drupal in der VM, erscheint nicht hier, sondern im Blog Doku-Hotline meiner Frau, für die ich diese kleine Anleitung eigentlich geschrieben habe.