/etc/mysql/mysql.conf.d/mysqld.cnf

In der [mysqld] Sektion muss nun folgende Zeile eingefügt werden:

sql_mode=NO_ENGINE_SUBSTITUTION

Danach muß der Dienst mysql neu gestartet werden:

service mysql restart

Es ist nun möglich unter Ubuntu Xenial fort zu fahren.

Im Fehlerfall updaten Sie bitte Ihre Netbootprodukte!
Nur für den Notfall finden sie alte bootimages unter http://download.uib.de/opsi4.0/archiv/opsi-linux-bootimage/

Es gibt ein Problem bei der Überprüfung der Server Zertifikate, so dass wir vorerst empfehlen, diese Option im opsiclientd vor einem Upgrade zu deaktivieren, was auch der Default Konfiguration entspricht. Gegebenenfalls muß der Hostparameter für den opsiclientd wie folgt geändert werden:

opsiclientd.global.verify_server_cert : false

Und vor dem Upgrade sollten die Clients die geänderte Konfiguration auch erhalten haben.

Aufgrund der Verwendung eines neuen Default-Protokolls für die HTTPS-Verbindung TSLv1.2 kann es zu unterschiedlichen Fehlerbildern im Configed kommen. Folgende Probleme sind beobachtet worden.

Als vorübergehende Lösung empfehlen wir für den Aufruf das bisherige HTTPS-Protokoll TLSv1 zu verwenden. Hierfür gibt es die folgenden Lösungsansätze:

...javaw -Dhttps.protocols=TLSv1 -Xmx1024m -jar "C:\Program Files (x86)\opsi.org\configed\configed.jar ...

Bisher wurden die Windows Netboot-Produkte nur aktualisiert, wenn man den opsi-product-updater mit der Option -i aufgerufen hat. Dieses Verhalten wurde nun geändert. Die Windows Netboot-Produkte werden nicht mehr bei einem Update der Produkte ausgeschlossen. Diese Produkte werden wie die Localboot-Produkte upgedatet. Falls Sie weiterhin Ausnahmen beibehalten möchten, pflegen Sie bitte den excludes-Eintrag entsprechend.

Ein ensprechender Hinweis bei der Paketinstallation weist auf eine geänderte Konfigurationsdatei hin. Falls Sie die geänderte Konfigurationsdatei übernehmen, müssen Sie eventuell anschließend ihre Zugangsdaten in der Konfigurationsdatei erneuet eintragen.

In bestehenden opsi Installationen wurde die Shares bisher mit oplock Parametern angelegt. Dies führt zu einem Bug zwischen Linux Rechnern. Wir empfehlen daher die oplock Parameter aus der Konfiguration für alle Shares zu entfernen und den Samba Dienst neu zu starten. Bei einer Neuinstallation des opsi-Servers werden die Shares ohne den oplock Parameter angelegt.

Sollten Sie eine Multidepot Umgebung haben, so machen Sie zunächst das Upgrade auf Ihrem config-server, bevor Sie die Depots upgraden.

Die Installation erfordert ansonsten keine besonderen Arbeiten. Sie erfolgt im Rahmen der normalen Updates ihres Servers und der opsi-Produkte. Sie sollten Ihre Server updaten bovor Sie die Clients Updaten. Benutzen Sie dazu die Befehle entsprechend Ihrer Linux-Distribution.
Sollten Sie eine Multidepot Umgebung haben, so machen Sie zunächst das Upgrade auf Ihrem config-server, bevor Sie die Depots upgraden.

Wir empfehlen in der Datei /etc/opsi/opsi-product-updater.conf in der Sektion [repository_uib] den Eintrag excludes wie folgt zu modifizieren, damit Sie auch Produkte bekommen welche mit win* anfangen::

excludes =

Wenn Sie die opsi-linux Produkte benötigen so hängen Sie an den dirs Eintrag:
den Pfad opsi4.0/products/opsi-linux an.

Wenn Sie die opsi-local-image Produkte benötigen so hängen Sie an den dirs Eintrag den Pfad opsi4.0/products/opsi-local-image an.

Danach die opsi-Produkte. Dies erledigt der opsi-product-updater:

opsi-product-updater -i -vv

Um nur Updates zu installieren:

opsi-product-updater -vv

Sollten Sie eine Multidepot Umgebung haben, so machen Sie zunächst das Upgrade auf Ihrem config-server, bevor Sie die Depots upgraden.

Falls Sie Produkt-IDs mit einer Länge von mehr als 32 Zeichen verwenden wollen und das MySQL-Backend einsetzen, so führen Sie bitte ein Update der Tabellen-Definition auf Ihrem Config-Server mittels opsi-setup durch:

opsi-setup --update-mysql

In diesem Kapitel werden die Abkündigungen aufgelistet. Diese Distributionsversionen werden aus verschiedenen Gründen nicht weiter
von opsi unterstützt.

Siehe auch gesondertes Kapitel: Kapitel 9, opsi Support Matrix.

Ab opsi v4.0.7 werden wir die Netbootpakete für

nicht weiter pflegen. Ebenso planen wir für diese Windowsversionen die
Unterstützung in den Update Abo’s einzustellen.
Falls Sie hierzu Fragen oder Probleme haben, melden Sie sich bitte bei uns.

Siehe auch gesondertes Kapitel: Kapitel 17, opsi Support Matrix Windows Clients.

Ab opsi v4.0.7 werden wir die Netbootpakete für

nicht weiter pflegen.
Falls Sie hierzu Fragen oder Probleme haben, melden Sie sich bitte bei uns.

Stand: 17.07.2017

: Unterstützt : Nicht unterstützt : In Entwicklung : Abgekündigt

Sollten Sie den opsi-server auf einer Betriebssystemversion einsetzen,
welche im vorigen Abschnitt nicht als Unterstützt aufgeführt ist, so empfehlen wir Ihnen ein Betriebssystem-Update bevor Sie opsi v4.0.7 einspielen.

Bei der WakeOnLan-Funktion kann ab opsi-configed Version 4.0.7 gewählt, werden

Wenn der Client einem mit dem configserver nicht identischen Depotserver zugeordnet ist, wird das WakeOnLan-Signal nicht direkt an den Client geschickt, sondern es wird eine Verbindung zum opsiconfd auf dem Depotserver aufgebaut und dieser veranlasst, in seinem Netz das Netzwerkpaket zu schicken.

Wenn der Client einem mit dem configserver nicht identischen Depotserver zugeordnet ist, wird das WakeOnLan-Signal nicht direkt an den Client geschickt, sondern es wird eine Verbindung zum opsiconfd auf dem Depotserver aufgebaut und dieser veranlasst, in seinem Netz das Netzwerkpaket zu schicken.

Abbildung 10.1. opsi-configed: Scheduler für Wake On Lan

Zu beachten ist, dass es der opsi-configed ist, der die Aktionen auslöst, d.h. das Programm darf in diesem Zeitraum nicht beendet werden.

Property-Werte, die als Passwörter dienen, sollten nicht direkt angezeigt werden.

Solange bis dieses Feature in einer künftigen opsi-Version als spezifischer Datentyp konstruiert ist, wird der folgende Hack implementiert:

In den Fällen, dass der Property-Schlüsseltext

wird der Property-Wert erst sichtbar, wenn der User auf das Werte-Feld klickt und im aufpoppenden Dialog der Anzeige des Wertes zustimmt.

Z.B. zeigt der opsi-configed für das Property root_password bei den Linux-Netbootprodukten standardmäßig, solange der User die Anzeige nicht anfordert, nur eine Sternchenfolge.

Der opsi-configed speichert im lokalen Benutzerprofil einige Information über die jeweilige Session, damit beim erneuten Login die Arbeitsumgebung wiederhergestellt werden kann. Seit Version 4.0.7 werden die Session-Informationen auch genutzt, um eine Auswahlliste der zuletzt verbundenen opsi-Server (z.B. produktiver und Test-Server) zu erzeugen. An oberster Stelle steht der zuletzt genutzte, der damit ohne explizite Auswahlaktion wieder verwendet werden kann.

Abbildung 10.2. Loginmaske des opsi-configed

Über den neuen Hauptmenü-Punkt "Fenster" können statt über die Schaltflächen in der Menüleiste rechts oben die Seiten für das Lizenzmanagement sowie die Gruppen- und Produktspezialfunktionen geöffnet werden. Außerdem befindet sich hier ein neuer Menüpunkt "Fenster anordnen", mit dem auf dem Desktop hinter anderen Fenstern "verloren gegangene" configed-Fenster wieder in den Vordergrund geholt werden können.

Abbildung 10.3. opsi-configed: Hauptmenü mit "Fenster"-Aufrufen

Die Funktion für die Suche innerhalb der Client-Tabelle mittels Suchstring-Eingabe ist erweitert:

Wie die Suche ausgeführt wird, ist durch die Auswahl in den Drop-down-Listen zu den Feldern und die erweiterte Liste zum Suchverfahren bestimmt:

Betätigen der Return-Taste springt auf den nächsten Treffer der Suche (ohne Treffer: auf die nächste Zeile). Weitere Auswahlfunktionen basierend auf der Suche zeigt das Kontextmenü des Suchfeldes:

Mittels dem etwas erweiterten Kontextmenü einer Gruppe ist es jetzt möglich,

Seit opsi 4.0.7 beinhaltet der opsi-linux-client-agent 15 Freistarts bei denen der Agent auch ohne Freischaltung verwendet werden kann.

Genauer formuliert: Nach der initalen Installation des opsi-linux-client-agent kann der der opsi-script 15 mal im Servicekontext gestartet werden ohne eine Freischaltung zu fordern.
Dies gibt Ihnen die Möglichkeit einen Linuxrechner aufzusetzen und mit den entsprechenden opsi-Produkten für den geplanten Einsatz zu konfigurieren. Beispielsweise können Sie nach der Installation das Produkt l-opsi-server aufrufen um aus dem frisch installierten Rechner einen opsi-server zu machen.

Für eine dauerhafte Pflege des installierten Linuxrechners über diese 15 Freistarts hinaus benötigen Sie aber eine Freischaltung dieses Features.

Bei Installationen unter Linux kann es gerade nach einem Neustart vorkommen, dass ein Installationsversuch über das Paketsystem der Distribution scheitert, da diese gerade durch einen anderen Prozess belegt ist.

Für diese Problematik gibt es jetzt die neue boolsche Funktion:
waitForPackageLock(<seconds timeout string>,<bool should we kill>)
Liefert true zurück wenn das Linux Packagesystem nicht gesperrt ist.
Ist es gesperrt, so wird <seconds timeout string> Sekunden auf die Freigabe gewartet.
Ist der Timeout erreicht, so wird der Prozess welcher den Lock erzeugt hat abgeschossen wenn <bool should we kill> gleich true ist. Dieses Vorgehen ist aber nicht empfohlen.

Beispiel:

Message "Try to get Package Lock..."
if waitForPackageLock("60","false")
        comment "we got the package lock."
else
        LogError "could not get Package Lock"
        isFatalError "package lock failed"
endif

Die Funktion getLinuxVersionMap liefert als weiteren Key SubRelease. Dem Key SubRelease wird auf SLES Systemen der Patchlevelstand als Wert zugewiesen. Also bei SLES11SP4: SubRelease=4.

Das Produkt l-opsi-server dient dazu automatisiert auf einer Linuxmaschine per opsi-linux-client-agent einen opsi-server zu installieren. Dies kann dazu dienen um schnell einen neuen opsi-depot-server zu installieren oder z.B. ein opsi Testsystem.

Das Produkt l-opsi-server hat folgende Properties:

Das Produkt hat eine setup required before Abhängigkeit zu dem Produkt l-system-update. D.h. wenn Sie l-opsi-server auf setup stellen wird automatisch l-system-update auch auf setup gestellt und vorher installiert.

In dem Verzeichnis custom des Produktes l-opsi-server kann eine Freischaltdatei (modules) abgelegt werden, welche bei der Installation durch das Produkt l-opsi-server verwendet wird und beim Einspielen einer neuen Version des Produktes erhalten bleibt.

Mit dem debian8 und ubuntu16-04 Paket ist es nun möglich von einem lokalen Apache2 Repository zu installieren.
Dazu müssen bei dem Produkt im Property '' die entsprechende Adresse angeben nach dem Muster http://<opsi-server>/opsi/<productId> z.B http://opsiserver/opsi/debian8
Weiterhin muss das lokale Repository natürlich erstellt werden.
Stellen Sie dazu sicher, dass das Produkt opsi-linux-support auf Ihrem opsi-server installiert ist. Dieses Paket installiert die hierfür benötigten Distributions-Pakete (apache2) und erstellt auch die benötigten Ordner. Dieser muss danach mit einem passenden distributions Repository gefüllt werden.
Hierfür gibt es zwei Möglichkeiten:

Einfach:
Führen Sie das nachfolgende Script als root aus.
Beachten Sie das der Pfad zum Apache2 DocumentRoot zum einen Distributiontypisch unterschiedliche Defaults hat und darüberhinaus abweichend vom Default konfiguriert sein kann.
Daher müssen Sie evtl. die zweite Zeile des Scriptes anpassen !

#! /bin/bash
DOCUMENTROOT=/var/www/html
URL=http://download.uib.de/opsi4.0/products/opsi-linux
FILE=debian8.tgz
mkdir -p ${DOCUMENTROOT}/opsi
cd ${DOCUMENTROOT}/opsi
wget ${URL}/${FILE}
tar xzf ${FILE}
opsi-set-rights .

#! /bin/bash
DOCUMENTROOT=/var/www/html
URL=http://download.uib.de/opsi4.0/products/opsi-linux
FILE=ubuntu16-04.tgz
mkdir -p ${DOCUMENTROOT}/opsi
cd ${DOCUMENTROOT}/opsi
wget ${URL}/${FILE}
tar xzf ${FILE}
opsi-set-rights .

Hier folgen die neuen Konfigurationsoptionen, die der 4.0.7 opsi-client-agent mitbringt.

# Use a proxy for connecting configservice
# proxy_mode:
#   'system' will try to check the system setting,
#   'static' to use proxyurl from configfile/hostparameter
# proxy_url usage: http://<user>:<password>@<proxy-url>:<proxy-port>
# Example: http://proxyuser:proxypass123@proxy.domain.local:8080
proxy_mode = static
proxy_url =

Mit opsi 4.0.7 wird die bisherige webbasierte Darstellung des Kioskclients (ehemals kofinanzierte Erweiterung "Software on Demand") durch eine Applikation abgelöst. Hintergrund dieses Wechsels sind:

12.2.1. Client Kiosk: Verwendung

Wenn der opsi-client-agent während der Installation merkt, dass die Konfiguration: software-on-demand.active auf true gesetzt wurde, wird automatisch während der Installation auf dem Client ein Startmenü-Eintrag erstellt, über den die Kioskanwendung direkt aufgerufen werden kann. Diesen findet man dann unter: Start → Programme → opsi.org → software-on-demand.

Nach dem Start der Anwendung zeigt sich folgendes Hauptfenster:

Abbildung 12.1. opsi-client-kiosk: Hauptfenster

Elemente:

1. Headerleiste (Kundenspezifisch anpassbar)
2. Info Button: Version und geladenen Sprache
3. Datenladeanzeige
4. Button zum Anzeigen der gesetzten Aktionen
5. Button zum speichern und anzeigen der gesetzten Aktionen
6. Button zum Beenden des Programms
7. Anzeige der Gruppenliste
8. Neuladen der Daten (z.B. nachdem Aktionen ausgeführt wurden)
9. Gesetzten Filter löschen und alle Daten anzeigen
10. Suchmaske (Filter Eingabefeld)
11. Filter aktivieren
12. Nach mögliche Produktupgrades filtern
13. Produktanzeige
14. Spalte zum Setzen der Aktionsanforderungen
15. Tab: Produktdetailinfo: Beschreibung / Hinweis / Versionen
16. Tab: Produktdetailinfo: Abhängigkeiten / Prioritäten
17. Statusleiste mit Meldungen

Das Hauptfenster zeigt auf der linken Seite eine Liste der Produktgruppen (7) welche über die Config software-on-demand.product-group-ids für diesen Client freigegeben sind. Findet sich hier mehr wie eine Gruppe, so gibt es hier den zusätzlichen Eintrag Alle Gruppen an erster Stelle. In dieser Liste kann ausgewählt werden aus welchen Produktgruppen Produkte angezeigt werden sollen. Per Default wird der erste Eintrag ausgewählt, also Alle Gruppen oder die einzige Gruppe.
Beim Start oder bei Veränderung der Auswahl werden die benötigten Daten eingelesen. Dies kann etwas dauern und der Lagevorgang wird im oberen Teil des Fensters (3) angezeigt.
Die Produkte werden in der zentralen Tabelle (13) angezeigt. Sobald ein Produkt angeklickt ist werden unten Detailinformationen zu diesem Produkt eingeblendet (15/16). In der rechten Spalte ActionRequest (14) kann eine Aktionsanforderung gesetzt werden.
Über den Button Zeige Aktionen (4) werden die bisher der Anwendung bekannten Aktionen gezeigt aber noch nicht gespeichert. Erst der Button Aktionen Speichern (5) sendet die gesetzten Aktionen an den Server. Dieser prüft ob über Produktabhängigkeiten noch weitere Produkte auf setup gesetzt werden müssen. Abschließend wird in einem gesonderten Fenster die Gesamtliste der anstehenden Aktionen angezeigt.

Abbildung 12.2. opsi-client-kiosk: Aktionsbestätigung

In diesem Fenster kann nun über den oberen Button Installiere jetzt eine sofortige Installation ausgelöst werden. In diesem Fall ist es schlau möglichst alle Applikationen zu schließen (bzw. zumindest Daten abzuspeichern) da die gestarteten Installationen mit laufenden Anwendungen in Konflikt geraten können.
Über den unteren Button Installiere bei nächster Standard-Gelegenheit wird das Programm an dieser Stelle beendet und die gespeicherten Aktionen werden später ausgeführt.

Der config software-on-demand.show-details aus opsi vor 4.0.7 hat in der Kioskanwendung keinen Einfluß mehr und kann gelöscht werden.

Auf das Modul kann auch über das Netzwerk zugegriffen werden, hierbei ist jedoch eine Authentifizierung notwendig.

[TitleLabel]
Text= opsi Client Kiosk
FontName = Arial
FontSize = 20
FontColor = $00000000
FontBold = true
FontItalic = false
FontUnderline = false

opsi-setup --set-rights /var/lib/opsi/depot/opsi-client-agent

Diese Funktionen dienen dazu JSON Ausdrücke auf String oder Stringlisten zu analysieren und zu modifizieren. Notwendig ist hierfür, die Struktur des zu bearbeitenden JSON-Ausdrucks zu kennen und zu verstehen. Dies kann dazu verwendet werden, um über opsiservicecall Sektionen mit den objektorientierten opsi-webservice Methoden zu arbeiten.

jsonIsValid(<jsonstr>) : boolean //since 4.11.6: [W/L]
Liefert true zurück wenn, <jsonstr> einen gültigen JSON Ausdruck enthält.

jsonIsArray(<jsonstr>) : boolean //since 4.11.6: [W/L]
Liefert true zurück wenn, <jsonstr> ein gültiges JSON Array enthält.

jsonIsObject(<jsonstr>) : boolean //since 4.11.6: [W/L]
Liefert true zurück wenn, <jsonstr> ein gültiges JSON Object enthält.

jsonAsObjectHasKey(<jsonstr>,<keystr>) : boolean //since 4.11.6: [W/L]
Liefert true zurück wenn, <jsonstr> ein gültiges JSON Object welches <keystr> als key enthält.
Folgendes Beispiel würde true zurückliefern:

jsonAsObjectHasKey('{"productVersion" : "4.4.1","packageVersion" : "2","productId" : "jedit"}','productId')

jsonAsArrayCountElements(<jsonstr>) : intstr //since 4.11.6: [W/L]
Wenn <jsonstr> ein gültiges JSON Array enthält ist der Rückgabewert ein String mit der Zahl der Elemente des Arrays.
Im Fehlerfall = "0"

jsonAsObjectCountElements(<jsonstr>) : intstr //since 4.11.6: [W/L]
Wenn <jsonstr> ein gültiges JSON Object enthält ist der Rückgabewert ein String mit der Zahl der Elemente des Objects.
Im Fehlerfall = "0"

jsonAsArrayGetElementByIndex(<jsonstr>, <indexstr>) : jsonstring //since 4.11.6: [W/L]
Liefert vom JSON Array <jsonstr> das Element mit dem Index <indexstr>
Der Index beginnt bei 0.
Im Fehlerfall = ""

jsonAsObjectGetValueByKey(<jsonstr>, <keystr>) : valuestring //since 4.11.6: [W/L]
Liefert vom JSON Object <jsonstr> den Wert des Key <keystr>
Im Fehlerfall = ""

jsonAsObjectSetValueByKey(<jsonstr>, <keystr>,<valuestring>) : jsonstring //since 4.11.6: [W/L]
Liefert einen String mit dem in <jsonstr> übergebenen JSON Object bei dem für den Key <keystr> der Wert <valuestring> gesetzt ist. Ist der Key nicht vorhanden, so wird er erzeugt.
Wenn <valuestring> als Stringwert erzeugt werden soll (also in doppelten Anführungszeichen), dann verwenden Sie besser die folgende Funktion: jsonAsObjectSetStringtypeValueByKey.
Im Fehlerfall = ""

jsonAsObjectSetStringtypeValueByKey(<jsonstr>, <keystr>,<valuestring>) : jsonstring //since 4.11.6: [W/L]
Liefert einen String mit dem in <jsonstr> übergebenen JSON Object bei dem für den Key <keystr> der Wert <valuestring> als String (also in doppelten Anführungszeichen) gesetzt ist. Ist der Key nicht vorhanden, so wird er erzeugt.
Wenn <valuestring> nicht als Stringwert erzeugt werden soll , dann verwenden Sie besser die vorherige Funktion: jsonAsObjectSetValueByKey.
Im Fehlerfall = ""

jsonAsArrayPutObjectByIndex(<jsonstr>, <indexstr>, <objectstr>) : jsonstring //since 4.11.6: [W/L]
Liefert einen String mit dem in <jsonstr> übergebenen JSON Array bei dem am Index <indexstr> das Object <objectstr> gesetzt ist.
Im Fehlerfall = ""

jsonAsArrayToStringList(<jsonstr>) : stringlist //since 4.11.6: [W/L]
Liefert einen String mit dem in <jsonstr> übergebenen JSON Array als Stringliste mit einem Arrayelement pro Zeile.

jsonStringListToJsonArray(<strlist>) : jsonstr //since 4.11.6: [W/L]
Liefert einen String mit einem JSON Array der die Zeilen der Stringliste <strlist> als Elemente enthält.

jsonAsObjectGetKeyList(<jsonstr>) : stringlist //since 4.11.6: [W/L]
Liefert eine Stringliste mit den Keys der im JSON Object <jsonstr> vorhandnen Keys.

Beispiel:
Lese productOnClients Objekte aus einer Datei, ändere die clientId auf den Wert der aktuellen Maschine und schreibe die Objekte über den opsi-webservice zurück.

[Actions]
requiredWinstVersion >= "4.11.6"

DefVar $ProductId$
DefVar $poc_file$
DefVar $objectStr$
DefVar $ArrayStr$

DefStringlist $pocList$

set $poc_file$ = "c:\tmp\product_on_client.json"

Message "Restore productOnClient from file ..."
comment " get Restore data from file ..."
Set $ArrayStr$ = strLoadTextFile($poc_file$)
if not(jsonIsValid($ArrayStr$))
        LogError "got no valid json from file"
        isFatalError
endif
if not(jsonIsArray($ArrayStr$))
        LogError "got no json Array from file"
        isFatalError
endif

comment "get list from array"
set $pocList$ = jsonAsArrayToStringList($ArrayStr$)
comment "loop over list"
for %pocindex% = "0" to calculate(count($pocList$)+"-1") do sub_set_clientid_in_poclist
comment "convert modified list to json array"
set $ArrayStr$ = jsonStringListToJsonArray($pocList$)
comment "write back"
opsiServiceCall_updatePOC

[sub_set_clientid_in_poclist]
set $objectStr$ = takeString("%pocindex%", $poclist$)
set $objectStr$ = jsonAsObjectSetStringtypeValueByKey(($objectStr$, "clientId","%opsiserviceUser%")
set $poclist$ = setStringInListAtIndex($objectStr$,$poclist$,"%pocindex%")

[opsiServiceCall_updatePOC]
"method": "productOnClient_updateObjects"
"params": [
                                        '$ArrayStr$',
                                        ]

waitForPackageLock(<seconds timeout string>,<bool should we kill>) : bool //since 4.11.6.1 [L]
Liefert true zurück wenn das Linux Packagesystem nicht gesperrt ist.
Ist es gesperrt, so wird <seconds timeout string> Sekunden auf die Freigabe gewartet.
Ist der Timeout erreicht, so wird der Prozess welcher den Lock erzeugt hat abgeschossen wenn <bool should we kill> gleich true ist. Dieses Vorgehen ist aber nicht empfohlen.

processIsRunning(<process name>) : boolean //since 4.11.6.1 [W/L]
Liefert true wenn der Prozess <process name> in der aktuellen Prozessliste ist.

Es gibt drei Varianten des shellCall Befehls:

Alle drei führen <command string> in der standard shell (cmd.exe / bash) aus. Die Funktionen unterscheiden sich aber bezüglich des Rückgabewertes

set $list$= shellCall('net start')

Ist eine Abkürzung für den Ausdruck:

set $list$ = getOutStreamFromSection ('DosInAnIcon_netstart winst /sysnative')

[DosInAnIcon_netstart]
net start

shellCall('net start')

Ist eine Abkürzung für den Ausdruck:

DosInAnIcon_netstart winst /sysnative

[DosInAnIcon_netstart]
net start

set $exitcode$ = shellCall('net start')

Ist eine Abkürzung für den Ausdruck:

DosInAnIcon_netstart winst /sysnative
set $exitcode$ = getLastExitcode

[DosInAnIcon_netstart]
net start

set $exitcode$ = processCall('setup.exe /S')

Ist eine Abkürzung für den Ausdruck:

Winbatch_setup
set $exitcode$ = getLastExitcode

[Winbatch_setup]
setup.exe /S

Tatsächlich basiert processCall intern auf den selben Routinen wie winbatch und verarbeitet daher auch die selben Modifier:

encryptStringBlow(<keystring>,<datastring>) : string //since 4.11.6 [W/L]
Verschlüsselt <datastring> mit dem Key <keystring> unter Verwendung von Blowfish und liefert den verschlüsselten Wert zurück.

decryptStringBlow(<keystring>,<datastring>) : string //since 4.11.6 [W/L]
Entschlüsselt <datastring> mit dem Key <keystring> unter Verwendung von Blowfish und liefert den entschlüsselten Wert zurück.

md5sumFromFile(<path to file>) : string //since 4.11.6 [W/L]
Liefert die md5summe der unter <path to file> gefundenen Datei zurück.
Im Fehlerfall ist der Rückgabewert ein Leerstring.

timeStampAsFloatStr : string (Floating Number - format: days.decimal days) //since 4.11.6 [W/L]
Liefert einen aktuellen Timestamp als Fließkommazahlstring. Dabei ist Zahl vor dem Komma die Tage seit dem 30. Dezember 1899. Nach dem Komma kommt die Zeit in Bruchteilen des Tages.
Just for Fun: Warum nicht der 31. Dezember 1899: ?
siehe http://www.delphibasics.co.uk/RTL.asp?Name=TDateTime

(Stand 10.3.2017)

: Unterstützt : Nicht unterstützt : In Entwicklung : Abgekündigt