Arndt Schönbergs Weblog

Montag Dez 12, 2016

Probleme mit Schriften und BIRT 4.6 unter Linux

Umgebung

  • EE7
  • Wildfly 10.1
  • BIRT 4.6
Unter Windows erkennt BIRT beim direkten Aufruf – also keinem Aufruf über das Web-Viewer-Example – alle Schriften automatisch. Deployed man die notwendigen jars mit einer EE(7) Anwendung auf einem Wildfly kann es zu Problemen mit nicht Standard-Schriften kommen. Auch eine Installation der Schriften unter
/user/share/fonts
oder anderen üblichen Verzeichnissen führt nicht immer zum Erfolg. Ursache hierfür ist, dass BIRT die Verzeichnisse in denen Schriften gesucht wird in einer xml Datei konfiguriert. Werden lediglich die jar Dateien von BIRT beim deployment verwendet so findet sich die für die Schriftsuche verwendete Datei (fontsConfig.xml) in dem Archiv
org.eclipse.birt.runtime_X.X.X_XXXXXXXXX.jar
Es sind innerhalb der Datei verschiedene Pfade für Windows und Linux-Systeme konfiguriert
      <font-paths>
		<path path="C:/windows/fonts" />
		<path path="d:/windows/fonts" />
		…
		<path path="/usr/share/fonts/truetype" />
		<path path="/usr/share/fonts/ko/TrueType" />
		<path path="/usr/share/fonts/zh_CN/TrueType" />
		<path path="/usr/share/fonts/zh_TW/TrueType" />
		<path path="/var/lib/defoma/x-ttcidfont-conf.d/dirs/TrueType" />
		<path path="/usr/share/fonts/TTF" />
		<path path="/usr/share/fonts/OTF" />
	</font-paths>
Leider werden die angegebenen Verzeichnisse nicht rekursiv durchsucht, so dass entweder die ttf-Dateien direkt in einem der Verzeichnisse auf dem Server abgelegt werden müssen oder die Konfigurationsdatei im Archiv bzw. eine externe Konfiguration mit den Pfaden gepflegt werden muss.

Montag Aug 08, 2016

Oracle 11 - Zeichensatz von WE8MSWIN1252 auf UTF8 umstellen

Umstellung des Zeichensatz von WE8MSWIN1252 auf UTF8

Viele „alte“ Oracle Datenbanken laufen noch mit der Kodierung WE8MSWIN1252. Wenn nun die Internationalisierung stärker in den Fokus der Entwicklung kommt, werden schnell die Grenzen deutlich, da viele Sprachen mit der Kodierung WE8MSWIN1252 nicht in der Datenbank abgebildet werden können.

Die heute übliche Lösung ist die Umstellung der Datenbank auf UTF(8). Wie viele andere administrative Aufgaben ist auch diese bei Oracle Systemen leider nicht trivial und schlecht oder gar nicht dokumentiert. Dieser Blog beschreibt ein Vorgehen, das bei uns für eine Oracle 11 Datenbank funktioniert hat. Je nach den aktuell in der Datenbank verwendeten Datentypen können weitere Schritte notwendig sein. Folgende Schritte werden im Folgenden beschrieben:

  1. Anpassung von großen Varchar2 Elementen auf CLOB
  2. Erstellen eines Datenbanksicherung in der Kodierung UTF8
  3. Umstellen der Datenbank auf UTF8
  4. Anpassen des Schemas für Varchar2 Elemente
  5. Import der Tabelleninhalte

Umstellung von großen Varchar2 Attributen auf CLOB

Ein Zeichen in UTF-8 benötigt mehrere Bytes Speicherplatz im Gegensatz zu einem Zeichen in WE8MSWIN1252, welches lediglich ein Byte benötigt. In Oracle werden Längen von Varchar2 Attributen, wenn keine weiteren Angaben gemacht werden, in Byte angegeben. Ein Varchar2(18) Element kann also nicht 18 Zeichen verwalten, sondern 18 Byte. Da Oracle 3 Byte je UTF8 Zeichen benötigt, können in einem solchen Feld nach der Umstellung lediglich 6 Zeichen gespeichert werden.

Die Umstellung von kleineren Varchar2-Attributen wird weiter unten beschrieben und erfolgt innerhalb der neuen Datenbank. Problematisch sind Varchar2-Attribute, die in der Ausgangsdatenbank größer als 1333 Zeichen (Achtung hier sind wirklich Zeichen gemeint) sind. Diese Elemente würden nach der Umwandlung mehr als 4000 Byte benötigen Die maximale Länge eines Varchar2 in Oracle liegt allerdings nur bei 4000 Byte.

Daher müssen solche Felder vor den weiteren Schritten in Clobs umgewandelt werden.

  1. Ausgangsattribut löschen
  2. Clob Attribut anlegen
Die folgende SQL-Anweisung erzeugt ein Skript, um die Varchar2 Attribute mit einer Größe von über 1333 in clob Felder umzusetzen:
SELECT 'ALTER TABLE ' || TABLE_NAME || ' DROP COLUMN ' || COLUMN_NAME || ';' || 
CHR(13) || 'ALTER TABLE ' || TABLE_NAME || ' ADD ' || COLUMN_NAME || ' CLOB;' FROM USER_TAB_COLUMNS WHERE DATA_TYPE = 'VARCHAR2' AND DATA_LENGTH > 1333;
Die Ergebniszeilen werden als Skript ausgeführt.

Erstellen eines DB-Dumps mit UTF8 Zeichenkodierung

Nachdem nun alle Vorbereitungen getroffen wurden, kann nun eine Sicherung des Datenbestands erstellt werden. Beim Export wird das „normale“ Dump Kommando verwendet und die Zeichenkodierung mit der Umgebungsvariable
export NLS_LANG=.UTF8
auf UTF8 gestellt.

Umstellen der Datenbank auf UTF8

In dem Wiki Beitrag

https://de.wikibooks.org/wiki/Oracle:_CharacterSet_%C3%A4ndern

ist die (interne) Umstellung von Oracle 11 auf UTF 8 beschrieben. Die folgende Auflistung enthält die Schritte, die bei der in diesem Blog verwendeten Oracle 11 Version notwendig waren:

  1. Als Nutzer sys mit sysdba-Berechtigung via sqlplus an der Oracle-Instanz anmelden.
     
               sqlplus "sys/password@orcl as sysdba"
           
  2. CharacterSet der Datenbank überprüfen
     
               select value from nls_database_parameters where parameter='NLS_CHARACTERSET';
           
    bzw. um sämtliche Einstellungen zu sehen
     
               select * from nls_database_parameters;
           
  3. Die Datenbank anhalten
     
               shutdown immediate;
           
  4. Bei der verwendeten Versionen gibt es einen Bug, bei dem ein Fehler beim Ausführen von "startup mount;" ausgegeben wird. Daher vorher folgenden Befehl ausführen:
     
                connect / as sysdba;
           
  5. Die Datenbank einhängen aber noch nicht öffnen
     
              startup mount;
           
  6. Session für Operation vorbereiten
     
                 alter system enable restricted session;
                 alter system set job_queue_processes=0;
           
  7. Nun die Datenbank öffnen
     
                alter database open;
           
    und den CharacterSet ändern
     
                alter database character set internal_use utf8;
           
  8. Datenbank wieder schließen und herunterfahren
     
                 shutdown immediate;
           
  9. Datenbank normal hochfahren
     
               startup;
           
  10. Nochmals die aktuellen Werte prüfen
     
                select value from nls_database_parameters where parameter='NLS_CHARACTERSET';
           
  11. Damit kann SqlPlus wieder beendet werden
     
                 exit;
           

Anpassen des Schemas für Varchar2 Felder

Mit dem folgenden SQL-Befehl wird ein Skript erzeugt, um die verbliebenen Varchar2 Attribute der Tabellen so zu erweitern, dass sie UTF8-Kodierte Zeichen aufnehmen zu können.
 
SELECT 'ALTER TABLE ' || TABLE_NAME || ' MODIFY ' || COLUMN_NAME || ' VARCHAR2(' || DATA_LENGTH || ' CHAR);'
FROM USER_TAB_COLUMNS WHERE DATA_TYPE = 'VARCHAR2';
Die Ergebniszeilen werden als Skript ausgeführt.

Wenn in der Datenbank Char Attribute existieren, muss ein analoges Vorgehen für diese verwendet werden.

Import der Tabelleninhalte

Da wir bisher nur die Datenbank auf UTF-8 umgestellt haben, die Daten aber nicht verändert wurden, würden bei der Nutzung des aktuellen Standes z.B. alle Umlaute falsch angezeigt werden. Um dies zu bereinigen, müssen die Daten aus dem oben erstellten UTF-8 Datenbank-Dump eingespielt werden. Dies erfolgt mit folgenden Schritten:
  1. Deaktivieren der Constraints der Datenbank
  2. Erzeugung eines Scripts, um die Inhalte der Tabellen zu löschen
  3. Ausführung des erzeugten Scripts zum Löschen der Inhalte
  4. Import der Inhalte
  5. Reaktivierung der Constraints.

Constraints deaktivieren

Mit der folgenden SQL-Anweisung wird ein Skript erzeugt, das die Constraints der Datenbank daktiviert:
 
SELECT 'alter table '|| table_name||' disable constraint '||CONSTRAINT_NAME||';' from user_constraints where table_name In (SELECT table_name from user_tables);
Die erzeugten Ergebniszeilen werden als Skript ausgeführt.

Löschen der Tabelleninhalte

Die Inhalte der Tabellen werden mit den Ergebnissen der folgenden Anweisung gelöscht
 
SELECT 'TRUNCATE TABLE ' || table_name || ';' from user_tables;

Einspielen der Tabelleninhalte aus dem Dump

Die zu Beginn gesicherten Daten in UTF-8 Kodierung werden nun eingespielt. Wichtig sind hierbei die Parameter FULL=Y IGNORE=Y CONSTRAINTS=N und das Setzen der Umgebungsvariable export NLS_LANG=.UTF8.
#!/bin/bash
...
export NLS_LANG=.UTF8
...
$IMP $USER/$PASS@orcl FILE=$FILENAME LOG=$LOG FULL=Y IGNORE=Y CONSTRAINTS=N
...

Constraints aktivieren

Nachdem die Daten wieder eingespielt wurden, müssen nun die Constraints aktiviert werden. Das folgende SQL-Kommando erstellt ein Skript, um die Constraints der Datenbank wieder zu aktivieren:
 
SELECT 'alter table '|| table_name||' enable constraint '||CONSTRAINT_NAME||';' from user_constraints where table_name In (SELECT table_name from user_tables);
Die Ergebniszeilen müssen als Skript ausgeführt werden.

Zusammenfassung

Mit dem obigen Vorgehen wurde eine Datenbank auf UTF-8 umgestellt. Da Oracle die Änderung von Kodierungen nicht unterstützt, sind sehr viele manuelle Schritte notwendig. Für einen der Marktführer im Datenbank-Sektor ist dies aus meiner Sicht nicht verständlich.

Postgis Update für Major- oder Minor-Releases

PostGis besteht als Erweiterung von PostgreSql aus einigen nativen Bibliotheken und über 1.000 Funktionen, die bei Hinzufügen des entsprechenden Features in der Datenbank angelegt werden (früher wurde eine Vorlage in PostgreSql bei Installation von PostGis angelegt).

Für ein Update eines Major- oder Minor-Releases, wird empfohlen die altes Datenbank zu exportieren und im Anschluss wieder in eine PostGis Datenbank der neuen Version zu importieren. Da die Funktionen mit „Create“ und nicht mit „Create or Replace“ aus dem Backup erzeugt werden, werden auf diesem Wege die eventuell im Release veränderten PostGis Funktionen ersetzt, da Create keine bereits in der Datenbank befindende Funktionen ersetzt.

Nachteil dieser Methode ist, dass Funktionen, die nicht mehr genutzt werden bzw. die in der neuen Version nicht mehr enthalten sind, mit dem Einspielen des Backups wieder in das System gespielt werden. Für einen „sauberen“ Import ist es also notwendig im ersten Schritt selbst erstellt Funktionen zu sichern. Da es leider nicht möglich ist Funktionen von einem Export auszuschließen, sollte ein SQL Export der Datenbank erstellt und die sich im oberen Bereich der Datei befindenden Funktionsdefinitionen und Typen gelöscht werden.

Beim Einspielen wird eine neue Datenbank mit PostGis Erweiterung und ggf weiteren Erweiterungen anlegt und dann die angepasste SQL Datei importiert. Im letzten Schritt werden die eigenen Funktionen wieder angelegt.

Dienstag Jul 26, 2016

Postgres Template löschen

In dem Datenbankmanagementsystem PostgreSql können Templates nicht direkt gelöscht werden. Um eine solche Vorlage zu löschen, muss zuerst das entsprechende Kennzeichen mit folgendem Befehl (hier für das Template 'template_postgis_20')

UPDATE pg_database SET datistemplate='false' WHERE datname='template_postgis_20';
zurückgesetzt werden. Danach ist das Löschen problemlos möglich.

Donnerstag Jun 30, 2016

Keine Ausreden - SSL für alle Webseiten

Durch das Projekt Lets Encrypt ist es nun möglich für alle Web-Seiten einfach und kostenfrei ein SSL Zertifikat zu erstellen. Es gibt also keine Ausreden mehr für ungesichert Verbindungen. Neben dem Sicherheitsaspektwerden Nutzer nicht mehr durch Warnungen im Browser irritiert. Des Weiteren ist zwar im offiziellen Standard von HTTP/2 zwar auch Verbindungen ohne SSL (https://) vorgesehen, aber die Browser-Hersteller bieten HTTP/2 nicht ohne Verschlüsselung an.

Also ran an die Zertifikate! Die folgende Beschreibung beschreibt wie ein Apache auf einer Ubuntu Installation abgesichert wird und wie die erstellten Zertifikate automatisch aktualisiert werden. Parmeter und andere Informationen auf die ich hier nicht eingehe, können unter anderem in der Dokumentation nachgelesen werden.

Installation

Die Installation der Let's-Encrypt Skripte erfolgt entweder über apt-get (in Ubuntu 14.04. sind diese noch nicht in den Repositories) oder durch Auschecken der Skripte aus Git.
git clone https://github.com/letsencrypt/letsencrypt
./letsencrypt-auto --help
Eine erste Hilfe wird mit folgenden Befehlen angezeigt.
cd letsencrypt
./letsencrypt-auto --help

Aktualisierung der Installation

Die Installation wird automatisch mit dem Befehl letsencrypt-auto aktualisiert, der im Folgenden noch öfter zum Einsatz kommt.

Erzeugen eines Zertifikats

Das Erzeugen der Zertifikate erfolgt in dem Installationsverzeichnis. Im ersten Schritt wird festgelegt für welche Domains das Zertifikat gelten soll (z.B. mit und ohne www) und wo sich das Homeverzeichnis für die Domain befindet. In dieses Verzeichnis wird im Laufe der Erzeugung eine Datei abgelegt über die geprüft wird, ob der Antragsteller Zugriff auf den Server hat.
./letsencrypt-auto certonly -d www.mein-name.de -d mein-name.de -w /var/www/mein-name/
Die obige Anweisung erzeugt für www.mein-name.de und mein-name.de ein Zertifikat. Das Basisverzeichnis der Web-Seiten liegt unter /var/www/mein-name/. Auf die Frage
How would you like to authenticate with the Let's Encypt CA?
wähle ich
2 place files in webroot directory.
Im Anschluss werden die Dateien für das Zertifikat erzeugt und verfiziert. Sie finden sic dann unter
/etc/letsencrypt/live/www.mein-name.de

Konfiguration von Apache

Für die installation benötige ich die Version des installierten Apache.
apache2ctl -v
Bis Apache 2.4.7 sieht die Konfiguration wie folgt aus
...
SSLEngine on
SSLCertificateFile /etc/letsencrypt/live/thomas-leister.de/cert.pem
SSLCertificateChainFile /etc/letsencrypt/live/thomas-leister.de/chain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/thomas-leister.de/privkey.pem
...
Ab Apache 2.4.8 (Ubuntu 15.04) sollte auf das SSLCertificateChainFile“ verzichtet und stattdessen nur SSLCertificateFile mit der Datei fullchain.pem statt cert.pem genutzt werden:
...
SSLEngine on
SSLCertificateFile /etc/letsencrypt/live/thomas-leister.de/fullchain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/thomas-leister.de/privkey.pem
...

Erneuerung der Zertifikate

Let‘s Encrypt stellt Befehle für die Erneuerung von Zertifikaten bereit (link). Mit dem Befehl
./letsencrypt-auto renew
werden alle aktuellen Zertifikate geprüft. Läuft dieser Befehl problemlos, kann er in crontab übernommen werden und legt somit automatisch die Zertifikate bei Bedarf neu an. Es werden Zertifikate erneuert, die keine 30 Tage Gültigkeit mehr besitzen.

Das war es ...

Einfach und sicher ... Vielen Dank an Let‘s Encrypt!!!!

Calendar

Feeds

Search

Links

Navigation