Kernmodul Komponentenverwaltung - Versionsgeschichte

Danielq: /* Entfernen der Passworteingabe unter Windows */

2025-11-07T10:50:05Z

Entfernen der Passworteingabe unter Windows

← Nächstältere Version		Version vom 7. November 2025, 10:50 Uhr
Zeile 256:		Zeile 256:
	[[Bild:puttygen.png\|413x402px]]		[[Bild:puttygen.png\|413x402px]]
	* Kopieren Sie Ihren Public Key, den Sie oben mit PuttyGen erzeugt haben, zur Datei "authorized_keys" und kopieren Sie diese in das Verzeichnis ~/.ssh/		* Kopieren Sie Ihren Public Key, den Sie oben mit PuttyGen erzeugt haben, zur Datei "authorized_keys" und kopieren Sie diese in das Verzeichnis ~/.ssh/
			* Im Profil unter Connection -> SSH -> Auth -> Credentials geben Sie den Pfad zum privaten Schlüssel in "Private key file" an.
	* Bei erneutem Login mit Putty oder Winscp sollte die Passwortabfrage entfallen.		* Bei erneutem Login mit Putty oder Winscp sollte die Passwortabfrage entfallen.

Danielq: /* Entfernen der Passworteingabe unter Windows */

2025-11-07T10:39:37Z

Entfernen der Passworteingabe unter Windows

← Nächstältere Version		Version vom 7. November 2025, 10:39 Uhr
Zeile 250:		Zeile 250:

	==== Entfernen der Passworteingabe unter Windows ====		==== Entfernen der Passworteingabe unter Windows ====
	Wenn Sie die ssh-Shell putty aus dem Installationspaket nutzen, haben Sie im Installationsordner auch die Anwendung "puttyGen.exe". Wenn Sie putty als reine Executable nutzen, laden Sie die Anwendung separat herunter. [http://winscp.net/download/puttygen.exe PuttyGen]		Wenn Sie die ssh-Shell putty aus dem Installationspaket nutzen, haben Sie im Installationsordner auch die Anwendung "puttyGen.exe". Wenn Sie putty als reine Executable nutzen, laden Sie die Anwendung separat herunter. [http://winscp.net/download/puttygen.exe PuttyGen]
	* Folgen Sie der Anleitung auf der Seite http://winscp.net/eng/docs/ui_puttygen, um den SSH2-DSA oder RSA Schlüssel zu erzeugen. Für den Schlüssel bitte kein Passwort vergeben.		* Folgen Sie der Anleitung auf der Seite http://winscp.net/eng/docs/ui_puttygen, um den SSH2-DSA oder RSA Schlüssel zu erzeugen. Für den Schlüssel bitte kein Passwort vergeben, wenn Sie das Tool automatisiert nutzen.
	* Den privaten Schlüssel geben Sie in Putty bzw. Winscp im Menü "Session" im Feld "Private Key File" an.		* Den privaten Schlüssel geben Sie in Putty bzw. Winscp im Menü "Session" im Feld "Private Key File" an.
	* Der Button "Save public key" ist nicht für OPENSSH unter Linux als Zielserver geeignet. Im folgenden Screenshot sehen Sie den markierten Bereich, den Sie kopieren müssen:		* Der Button "Save public key" ist nicht für OPENSSH unter Linux als Zielserver geeignet. Im folgenden Screenshot sehen Sie den markierten Bereich, den Sie kopieren müssen:
	[[Bild:puttygen.png\|413x402px]]		[[Bild:puttygen.png\|413x402px]]
	* Kopieren Sie Ihren Public Key, den Sie oben mit PuttyGen erzeugt haben, zur Datei "authorized_keys" und kopieren Sie diese in das Verzeichnis ~/.ssh/		* Kopieren Sie Ihren Public Key, den Sie oben mit PuttyGen erzeugt haben, zur Datei "authorized_keys" und kopieren Sie diese in das Verzeichnis ~/.ssh/
	* Bei erneutem Login mit Putty oder Winscp sollte die Passwortabfrage entfallen.		* Bei erneutem Login mit Putty oder Winscp sollte die Passwortabfrage entfallen.

	==== Einrichtung von SFTP (Server) ====		==== Einrichtung von SFTP (Server) ====

Danielq: /* Entfernen der Passworteingabe unter Unix */

2025-03-12T18:48:45Z

Entfernen der Passworteingabe unter Unix

← Nächstältere Version		Version vom 12. März 2025, 18:48 Uhr
Zeile 206:		Zeile 206:
	ssh superx@superxhost		ssh superx@superxhost
	Beim ersten Mal müssen Sie die Sicherheitsabfrage mit "yes" bestätigen.		Beim ersten Mal müssen Sie die Sicherheitsabfrage mit "yes" bestätigen.
	Erzeugen Sie auf dem Quellrechner einen öffentlichen Schlüssel mittels ssh-keygen -t ~~rsa,~~ wobei man eine leere Passphrase vergibt ~~(Achtung: mögliche Sicherheitslücke!)~~. Der öffentliche Teil dieses Schlüssels (~/.ssh/~~id_rsa~~.pub) muss auf dem Zielrechner in die Datei ~/.ssh/authorized_keys eingefügt werden, ggf. muss die Datei neu erzeugt werden.		Erzeugen Sie auf dem Quellrechner einen öffentlichen Schlüssel mittels

			ssh-keygen -t ed25519 -C "cob@cobhost"

			wobei man eine leere Passphrase vergibt. Der öffentliche Teil dieses Schlüssels (~/.ssh/id_ed25519.pub) muss auf dem Zielrechner in die Datei ~/.ssh/authorized_keys eingefügt werden, ggf. muss die Datei neu erzeugt werden.
	Wenn z.B. auf dem COB-Server unter der Kennung cob ein Key wie folgt erzeugt wurde:		Wenn z.B. auf dem COB-Server unter der Kennung cob ein Key wie folgt erzeugt wurde:

	;Beispieleintrag eines Public Keys: ssh-~~rsa AAAAB3Nza..~~.[hier viele kryptische Zeichen]...~~pg6VkCc=~~ cob@cobhost		;Beispieleintrag eines Public Keys:


			ssh-ed25519 AAAAC3N.[hier viele kryptische Zeichen]....4V cob@cobhost

	Dann wird genau diese Zeile in der Datei /home/superx/.ssh/authorized_keys angefügt (die Datei kann mehrere PublicKeys enthalten, ein Eintrag pro Absatz).		Dann wird genau diese Zeile in der Datei /home/superx/.ssh/authorized_keys angefügt (die Datei kann mehrere PublicKeys enthalten, ein Eintrag pro Absatz).

Danielq: /* Einrichtung von SFTP (Server) */

2024-11-11T06:49:37Z

Einrichtung von SFTP (Server)

← Nächstältere Version		Version vom 11. November 2024, 06:49 Uhr
Zeile 263:		Zeile 263:
	ForceCommand internal-sftp		ForceCommand internal-sftp
	AllowTcpForwarding no		AllowTcpForwarding no

			Danach starten Sie den SSH-Dienst neu:
			service ssh restart

	Dann legen Sie die Gruppe "sftponly" an:		Dann legen Sie die Gruppe "sftponly" an:

Danielq: /* Upgrade eines Moduls: Allgemeines Vorgehen */

2024-11-06T07:21:50Z

Upgrade eines Moduls: Allgemeines Vorgehen

← Nächstältere Version		Version vom 6. November 2024, 07:21 Uhr
Zeile 476:		Zeile 476:
	Zum Upgrade bzw. zum Zurücksetzen des Moduls auf den Auslieferungszustand entpacken Sie das Paket in $SUPERX_DIR und gehen in das Verzeichnis $SUPERX_DIR/db/module/-Modulname-/upgrade und führen das Script aus:		Zum Upgrade bzw. zum Zurücksetzen des Moduls auf den Auslieferungszustand entpacken Sie das Paket in $SUPERX_DIR und gehen in das Verzeichnis $SUPERX_DIR/db/module/-Modulname-/upgrade und führen das Script aus:
	-Modulname-_upgrade.x		-Modulname-_upgrade.x
	Ausnahme: beim Kernmodul gibt es i.d.R. ein spezielles Upgrade Script.		Ausnahme: beim Kernmodul gibt es i.d.R. ein spezielles [[Kern_Installation_Upgrade#Standardvorgehen_beim_Upgrade\|Upgrade Script]].

	Die Logdatei lautet upgrade.log, im Mandantenfähigen Betrieb "upgrade-MANDANTID-.log".		Die Logdatei lautet upgrade.log, im Mandantenfähigen Betrieb "upgrade-MANDANTID-.log".

	Wenn Sie einen separaten Tomcat-Rechner betreiben, müssen Sie das Paket dort ebenfalls entpacken, und vom Datenbankserver die Datei $SUPERX_DIR/webserver/tomcat/webapps/superx/WEB-INF/dbforms-config.xml an die gleiche Stelle auf den Tomcat Rechner kopieren. Ein nochmaliges Ausführen des Upgrade Scriptes ist nicht nötig, weil dies nur die Datenbank betrifft.		Wenn Sie einen separaten Tomcat-Rechner betreiben, müssen Sie das Paket dort ebenfalls entpacken, und vom Datenbankserver die Datei $SUPERX_DIR/webserver/tomcat/webapps/superx/WEB-INF/dbforms-config.xml an die gleiche Stelle auf den Tomcat Rechner kopieren. Ein nochmaliges Ausführen des Upgrade Scriptes ist nicht nötig, weil dies nur die Datenbank betrifft.

Danielq: /* Einrichtung von SFTP (Server) */

2024-07-18T21:24:58Z

Einrichtung von SFTP (Server)

← Nächstältere Version		Version vom 18. Juli 2024, 21:24 Uhr
Zeile 264:		Zeile 264:
	AllowTcpForwarding no		AllowTcpForwarding no

	Dann legen Sie die Gruppe "sftponly" an und dann den Unix-User an, und geben ihm die Gruppe "sftponly". Hier ein Script:		Dann legen Sie die Gruppe "sftponly" an:
			groupadd sftponly
			und dann den Unix-User an, und geben ihm die Gruppe "sftponly". Hier ein Script:
	#!/bin/sh		#!/bin/sh
	SFTPUSERNAME=$1		SFTPUSERNAME=$1

Danielq: /* Einrichtung von SFTP (Server) */

2024-07-18T21:24:01Z

Einrichtung von SFTP (Server)

← Nächstältere Version		Version vom 18. Juli 2024, 21:24 Uhr
Zeile 287:		Zeile 287:
	müssen Sie darauf achten dass das Home-Verzeichnis des Users nicht dem User gehört, sondern root.		müssen Sie darauf achten dass das Home-Verzeichnis des Users nicht dem User gehört, sondern root.

	Wenn der Login klappt, können Sie nach dem oben beschriebenen Verfahren die Passworteingabe durch PublicKey-Authentifizierung ersetzen.		Wenn der Login klappt, können Sie nach dem [[Kernmodul_Komponentenverwaltung#Entfernen_der_Passworteingabe_unter_Unix\|oben]] beschriebenen Verfahren die Passworteingabe durch PublicKey-Authentifizierung ersetzen.

	==== Einrichtung von SFTP ====		==== Einrichtung von SFTP ====

Danielq: /* Einrichtung von SFTP (Server) */

2024-07-18T21:23:05Z

Einrichtung von SFTP (Server)

← Nächstältere Version		Version vom 18. Juli 2024, 21:23 Uhr
Zeile 253:		Zeile 253:
	==== Einrichtung von SFTP (Server) ====		==== Einrichtung von SFTP (Server) ====
	Beim Push-Verfahren wird, wenn mit scp oder rsync kopiert wird, eine Login-Shell vorausgesetzt. Wenn dies aus Sicherheitsgründen nicht gewünscht ist bzw. wg. Einsatz von Windows nicht möglich ist, können Sie auch sftp nutzen, dies wird in modernen ssh-Servern mitgeliefert und bietet ebenfalls verschlüsselten Datentransfer. Zur Einrichtung des Servers:		Beim Push-Verfahren wird, wenn mit scp oder rsync kopiert wird, eine Login-Shell vorausgesetzt. Wenn dies aus Sicherheitsgründen nicht gewünscht ist bzw. wg. Einsatz von Windows nicht möglich ist, können Sie auch sftp nutzen, dies wird in modernen ssh-Servern mitgeliefert und bietet ebenfalls verschlüsselten Datentransfer. Zur Einrichtung des Servers:
	Der SSH-Dienst wird wie folgt konfiguriert (am Beispiel Ubuntu Linux 14.04 LTS):		Der SSH-Dienst wird wie folgt konfiguriert (am Beispiel Ubuntu Linux 22.04 LTS) mit dem SFTP-Verzeichnis /home/sftp/-benutzername:
	In der /etc/ssh/sshd_config ~~folgende Zeilen hinzufügen~~:
			In der Datei /etc/ssh/sshd_config die Zeile auskommentieren:
			#Subsystem sftp /usr/lib/openssh/sftp-server
			und stattdessen:
	Subsystem sftp internal-sftp		Subsystem sftp internal-sftp
	~~UsePAM yes~~
	~~X11Forwarding yes~~
	Match Group sftponly		Match Group sftponly
	~~AllowAgentForwarding no~~		ChrootDirectory /home/sftp/%u
	~~AllowTcpForwarding no~~		ForceCommand internal-sftp
	~~AuthorizedKeysFile~~ /home/~~%u/.ssh/authorized_keys~~		AllowTcpForwarding no
	~~ChrootDirectory /home~~/%u
	ForceCommand internal-sftp ~~-l INFO -u 0027~~		Dann legen Sie die Gruppe "sftponly" an und dann den Unix-User an, und geben ihm die Gruppe "sftponly". Hier ein Script:
	~~X11Forwarding~~ no		#!/bin/sh
	Dann legen Sie die Gruppe "sftponly" an und dann den Unix-User an, und geben ihm die Gruppe "sftponly":		SFTPUSERNAME=$1
	~~useradd -m $KENNUNG~~		mkdir -p /home/sftp/$SFTPUSERNAME
	~~usermod -aG sftponly~~ $~~KENNUNG~~		useradd -b /home/sftp -s /bin/false -G sftponly $SFTPUSERNAME
	~~usermod~~ -s /~~sbin~~/~~nologin~~ $~~KENNUNG~~		chown root:root /home/sftp/$SFTPUSERNAME
	~~usermod~~ -~~d "~~/" $~~KENNUNG~~		chmod 755 /home/sftp/$SFTPUSERNAME
	~~Dann vergeben Sie mit~~		mkdir -p /home/sftp/$SFTPUSERNAME/incoming
	~~passwd $KENNUNG~~		chown $SFTPUSERNAME:sftponly /home/sftp/$SFTPUSERNAME/incoming
	~~ein Passwort, und legen die Verzeichnisse an:~~
	~~Ubuntu~~:		Danach legen Sie mit
	~~mkdir~~ /home/$~~KENNUNG~~		passwd $SFTPUSERNAME
	~~mkdir~~ /home/$~~KENNUNG/.ssh~~		ein Passwort fest.
	~~chown -R $KENNUNG:-Gruppe~~- /home/$~~KENNUNG~~/*
	chown -R $~~KENNUNG~~:~~-Gruppe-~~ /home/$~~KENNUNG~~/.~~ssh~~

	~~OpenSuse (siehe https://en.opensuse.org/SDB:SFTP_server_with_Chroot ):~~
	~~mkdir /home/$KENNUNG~~
	~~chown root:sftponly /home/$KENNUNG~~
	~~chmod 750 /home/$KENNUNG~~
	~~mkdir /home/$KENNUNG/.ssh~~
	~~chown -R $KENNUNG:-Gruppe- /home/$KENNUNG/.ssh~~


	Der User kann sich dann nicht mehr mit ssh einloggen, nur noch mit sftp, und ~~landen~~ beim Login in /home/$KENNUNG, in einem "chroot-Käfig". Zum Testen geben Sie ein:		Der User kann sich dann nicht mehr mit ssh einloggen, nur noch mit sftp, und landet beim Login in /home/$KENNUNG, in einem "chroot-Käfig", und der User kann mit SFTP in den Ordner "incoming" schreiben. Zum Testen geben Sie ein:
	sftp $KENNUNG@-Host-		sftp $KENNUNG@-Host-

Danielq: /* Datenbankbasierte hochschulspezifische Laderegeln */

2024-06-24T09:51:53Z

Datenbankbasierte hochschulspezifische Laderegeln

← Nächstältere Version		Version vom 24. Juni 2024, 09:51 Uhr
Zeile 493:		Zeile 493:
	und füllen Sie diese mit einem beliebigen Inhalt. Das Script wird beim Upgrade des Moduls automatisch am Ende ausgeführt.		und füllen Sie diese mit einem beliebigen Inhalt. Das Script wird beim Upgrade des Moduls automatisch am Ende ausgeführt.
	==Datenbankbasierte hochschulspezifische Laderegeln ==		==Datenbankbasierte hochschulspezifische Laderegeln ==
	~~Bislang war es~~ möglich über sog. "Preparation"- oder "Finalize"-[[Kernmodul_Shellscripte#Hochschulspezifische_Transformationen_im_ETL-Prozess\|Scripte]] die Laderoutine ~~zu steuern~~. Dieses Verfahren ist weiterhin möglich, ist aber bzgl. Clustering und Schreibzugriff recht unflexibel.		Eine Laderoutine gliedert sich in die Schritte
			#Unload: Entladen der CSV Dateien aus dem jew. Vorsystem
			#Load: Upload der CSV Dateien
			#Trans: Transformation der Daten
			#Aggr: Aggregation der Daten
			#Test: Test der Daten
			#System: Standdatum bei Erfolg aktualisieren
			Es ist möglich über sog. "Preparation"- oder "Finalize"-[[Kernmodul_Shellscripte#Hochschulspezifische_Transformationen_im_ETL-Prozess\|Scripte]] die Laderoutine am Ende von LOAD bzw. TRANS anzupassen. Dieses Verfahren ist weiterhin möglich, ist aber bzgl. Clustering und Schreibzugriff recht unflexibel.

	Es ist ~~nun~~ möglich im Browser hochschulspezifische Scripte am Ende des jeweiligen Schrittes einer Laderoutine anzulegen. Dies funktioniert so: Die Laderoutine führt zunächst den allgemeinen, von uns vorgegebenen Ladeschritt aus. Wenn dann eine Repository-Variable mit einem gewissen Namensschema existiert, wird sie ausgeführt. Das Namensschema lautet		Es ist auch möglich im Browser hochschulspezifische Scripte am Ende des jeweiligen Schrittes einer Laderoutine anzulegen. Dies funktioniert so: Die Laderoutine führt zunächst den allgemeinen, von uns vorgegebenen Ladeschritt aus. Wenn dann eine Repository-Variable mit einem gewissen Namensschema existiert, wird sie ausgeführt. Das Namensschema lautet
	<source lang="xml">		<source lang="xml">
	<<Kürzel der Komponente>>_<<Ladeschritt>>_CUSTOM		<<Kürzel der Komponente>>_<<Ladeschritt>>_CUSTOM

Danielq: /* Datenbankbasierte hochschulspezifische Laderegeln */

2024-06-24T09:34:55Z

Datenbankbasierte hochschulspezifische Laderegeln

← Nächstältere Version		Version vom 24. Juni 2024, 09:34 Uhr
Zeile 496:		Zeile 496:

	Es ist nun möglich im Browser hochschulspezifische Scripte am Ende des jeweiligen Schrittes einer Laderoutine anzulegen. Dies funktioniert so: Die Laderoutine führt zunächst den allgemeinen, von uns vorgegebenen Ladeschritt aus. Wenn dann eine Repository-Variable mit einem gewissen Namensschema existiert, wird sie ausgeführt. Das Namensschema lautet		Es ist nun möglich im Browser hochschulspezifische Scripte am Ende des jeweiligen Schrittes einer Laderoutine anzulegen. Dies funktioniert so: Die Laderoutine führt zunächst den allgemeinen, von uns vorgegebenen Ladeschritt aus. Wenn dann eine Repository-Variable mit einem gewissen Namensschema existiert, wird sie ausgeführt. Das Namensschema lautet
	<source lang="~~aml~~">		<source lang="xml">
	<<Kürzel der Komponente>>~~'''~~_~~'''~~<<Ladeschritt>>~~'''~~_CUSTOM		<<Kürzel der Komponente>>_<<Ladeschritt>>_CUSTOM
	</source>.		</source>.
	* Bei Hauptladeroutinen ist dies		* Bei Hauptladeroutinen ist dies