ADDENDUM Willkommen zu Release 6 von 4D v11 SQL. Dieses Dokument beschreibt die neuen Funktionalitäten und Änderungen der Version. Erweiterte Verschlüsselungsmöglichkeiten Release 6 von 4D v11 SQL erweitert die Möglichkeiten von 4D Anwendungen für Verschlüsselung mit zwei neuen Funktionalitäten: Ein neuer Selector ermöglicht, die von 4D verwendete Cipher Liste zu verändern. Der Befehl GENERATE ENCRYPTION KEYPAIR ermöglicht, Schlüssel mit einer Länge bis zu 2048 Bits zu generieren. SET DATABASE PARAMETER, Get database parameter SET DATABASE PARAMETER und Get database parameter haben einen neuen Selector erhalten. Selector = 64 (SSL Cipher List) Werte: String Beschreibung: Dieser Selector ermöglicht, die Cipher Liste, die 4D für das SSL Protokoll verwendet, beizuerhalten oder zu ändern. Sie können über diesen Selector z.b. SSL 3.0 Verschlüsselungsalgorithmen festlegen und so alle Verbindungen in SSL 2.0 abweisen. Die Cipher Liste ist eine Folge von Strings, getrennt durch Doppelpunkt: "RC4-MD5:RC4-64-MD5:..." Diese Einstellung gilt für die gesamte Anwendung (sie betrifft HTTP Server und SQL Server sowie alle 4D Funktionen, die das SSL Protokoll nutzen) aber sie ist temporär, d.h. sie bleibt zwischen Sitzungen nicht erhalten. Wurde die Cipher Liste geändert, müssen Sie den betroffenen Server neu starten, damit die neuen Einstellungen berücksichtigt werden. 4D v11 SQL Release 6 (11.6) Addendum 1
Um die Cipher Liste auf ihren Standardwert zurückzusetzen, der permanent in der SLI Datei gespeichert ist, rufen Sie den Befehl SET DATABASE PARAMETER auf und übergeben im Parameter Wert einen leeren String (""). 4D verwendet standardmäßig den RC4 cipher Algorithmus. Wollen Sie den neueren AES Algorithmus verwenden, übergeben Sie im Parameter Wert folgenden String: "AES:ALL:!aNULL:!eNULL:+RC4:@STRENGTH" Hinweis: Mit der Funktion Get database parameter wird die Cipher Liste im optionalen Parameter StringWert zurückgegeben und der Parameter ist immer 0. Konfiguration von 4D in SSL 3.0 nur bei Verweigern von SSL 2.0 Verbindungen: C_TEXT($ssl3) $ssl3:="null-md5:null-sha:exp-rc4-md5:rc4-md5:rc4-sha: EXP-RC2-CBC-MD5:IDEA-CBC-SHA:EXP-DES-CBC-SHA:DES-CBC-SHA: DES-CBC3-SHA:EXP-EDH-DSS-DES-CBC-SHA:EDH-DSS-CBC-SHA:EDH- DSS-DES-CBC3-SHA:EXP-EDH-RSA-DES-CBC-SHA:EDH-RSA-DES-CBC- SHA:EDH-RSA-DES-CBC3-SHA:EXP-ADH-R"+"C4-MD5:ADH-RC4-MD5: EXP-ADH-DES-CBC-SHA:ADH-DES-CBC-SHA:ADH-DES-CBC3-SHA" SET DATABASE PARAMETER(SSL Cipher List;$ssl3) GENERATE ENCRYPTION KEYPAIR 4D kann jetzt mit dem Befehl GENERATE ENCRYPTION KEYPAIR RSA Schlüssel mit einer Länge von 2048 Bits generieren. Dafür übergeben Sie im Parameter Länge den Wert 2048. Web Areas WA Execute JavaScript Unter Windows gibt die Funktion WA Execute JavaScript jetzt auch wie auf Mac OS das Ergebnis von der JavaScript Code Ausführung zurück. 2 4D v11 SQL Release 6 (11.6) Addendum
Geänderte Vorgehensweise beim Spiegeln Geänderte Vorgehensweise beim Spiegeln In 4D v11 SQL Release 6 hat sich die Vorgehensweise zum Übernehmen von Backup-Daten über einen Spiegel-Server geändert. Wir empfehlen jetzt, das aktuelle Logbuch auf dem Spiegelrechner zu deaktivieren. Öffnen Sie dazu im Dialogfenster Einstellungen des 4D Spiegel-Server die Seite "Backup/Konfiguration". Deaktivieren Sie die Option "Benutze Logbuch" und bestätigen Sie die Operation, indem Sie in der Meldung, die auf dem Bildschirm erscheint, auf die Schaltfläche Stop klicken. Entsprechend lässt sich der Befehl INTEGRATE LOG FILE jetzt verwenden, ohne dass zwingenderweise ein aktuelles Logbuch aktiviert ist. Diese neue Vorgehensweise verhindert das potentielle Risiko der Desynchronisation der Logbücher, wenn ein Zwischenfall passiert. Dazu kam es in bisherigen Versionen von 4D v11 SQL. Haben Sie bereits eine Lösung für Spiegeln mit 4D v11 SQL eingerichtet, raten wir dringend, Release 6 auf dem Server sowie den Spiegelrechnern zu installieren und Ihre Entwicklung gemäß den o.a. Vorgaben anzupassen. Neue Vorgehensweise Gehen Sie jetzt folgendermaßen vor, um ein Backup-System mit einem Spiegel einzurichten. Text in Kursivschrift gibt Schritte an, die sich gegenüber früheren Versionen geändert haben: Schritt Produktionsrechner 1 - Anwendung starten - Backup der Datendatei - Falls bisher nicht der Fall, Logbuch aktivieren. 4D erstellt die Datei MeineDatenbank.journal. Diese Datei sollte für bessere Sicherheit auf einer separaten Festplatte gespeichert werden. - Programm beenden - Alle Dateien der Datenbank inkl. Logbuch auf den Spiegelrechner kopieren. Spiegelrechner 4D v11 SQL Release 6 (11.6) Addendum 3
Schritt Produktionsrechner 2 - Anwendung neu starten (prüfen Sie, dass kein Vollbackup per Programmiersprache oder Planer durchgeführt wird). - Server ist betriebsbereit. Spiegelrechner - Spiegel-Server starten. 4D Server fragt nach dem aktuellen Logbuch: Wählen Sie die Datei MeineDatenbank.journal, die vom Produktionsrechner übertragen wurde. - Deaktivieren Sie das aktuelle Logbuch im Dialogfenster Einstellungen auf der Seite Backup/Konfiguration. 3 - Der Spiegelserver soll aktualisiert werden, z.b. nach einer bestimmten Zeitspanne. - Die Methode, welche die Funktion New log file enthält, ausführen. Die gesicherte Datei lautet MeineDatenbank[0001-0000].journal - Die Datei MeineDatenbank[0001-0000].journal per Programmierung an den Spiegelserver senden (über 4DIC, Web Services, etc.) - Server ist betriebsbereit. 4 - Eine zu integrierende Datei wird erhalten. - Die Methode, welche den Befehl INTEGRATE LOG FILE enthält, um die Datei MeineDatenbank[0001-0000].journal zu integrieren, wird ausgeführt. 5 - Auf dem Rechner passiert ein Zwischenfall, die Datendatei ist nicht mehr verwendbar. - Administrator entscheidet: Der Spiegelrechner soll als Ersatzrechner verwendet werden. - Kopieren Sie das aktuelle Logbuch MeineDatenbank.journal manuell auf den Zielordner des Spiegelrechners. 4 4D v11 SQL Release 6 (11.6) Addendum
Voreinstellung öffnen (Kompatibilität) 6 - Zwischenfall analysieren und Rechner reparieren 7 - Der Rechner ist repariert. - Die beschädigten Dateien der Datenbank mit denen der Spiegeldatenbank ersetzen. - Die Anwendung starten: 4D Server fordert das Logbuch an. Wählen Sie die von der Spiegeldatenbank übertragene Datei. Voreinstellung öffnen (Kompatibilität) - Eine zu integrierende Datei wird erhalten. Die Methode, welche den Befehl INTEGRATE LOG FILE enthält, um die Datei MeineDatenbank.journal zu integrieren, wird ausgeführt. - Als zusätzliche Vorsichtsmaßnahme über die Voreinstellungen, Seite Backup/Konfiguration ein aktuelles Logbuch erstellen (da es derzeit keinen Spiegel gibt). - Server ist betriebsbereit. - Die Datenbank wird beendet. - Zurück zu Schritt 2 In den Einstellungen auf der Seite Datenbank/Datenverwaltung gibt es die neue Option Öffne v12 Datendatei. Damit haben Sie die Möglichkeit, Datendateien wiedermit 4D v11 SQL zu öffnen, die bereits für Version 12 (nächstes Major Release von 4D) konvertiert wurden. 4D v11 SQL Release 6 (11.6) Addendum 5
Diese Möglichkeit wurde vorgesehen, um die Test- und Migrationsphase von v11 auf v12 zu erleichtern. Solange in der Struktur keine der neuen Funktionalitäten von Version 12 benutzt wurden, kann die Datendatei wieder mit v11 geöffnet und verwendet werden, auch wenn bereits Daten erfasst bzw. geändert wurden. Dies gilt nicht für die Struktur. Aus Sicherheitsgründen ist standardmäßig die Option Nein markiert, d.h. es ist nicht möglich, eine v12 Datendatei zu öffnen. Sie müssen das explizit über die Option Fragen (zeigt das Dialogfenster Bestätigen) oder die Option Ja (direktes Öffnen) autorisieren. Hinweis: Nur Datendateien bleiben zwischen zwei Versionen kompatibel. Eine Strukturdatei, die einmal in v12 konvertiert wurde, lässt sich nicht länger mit v11 öffnen. 6 4D v11 SQL Release 6 (11.6) Addendum