Linux Build Service (OBS)

Die Linux-Gruppe betreibt für interessierte Nutzer eine lokale (im RRZE gehostete) Instanz des OpenSUSE Build Service (OBS).
OBS kann dazu genutzt werden automatisiert Pakete für verschiedene Architekturen und Distribution zu bauen und als Paketquelle bereitzustellen.

Der Linux Build Service ist erreichbar unter https://www.linux.rrze.fau.de/obs/

Diese Anleitung beschreibt einige Aspekte der Nutzung der RRZE-Instanz dieses Dienstes.
Es besteht kein Versorgungsanspruch.

 

Vorbereitung

Bitte prüfen Sie die vorbereitenden Schritte bevor Sie versuchen einzelne Teile der Anleitung durchzuführen.
In der Regel müssen diese Vorraussetzungen für ein sinnvolles Umsetzen der Anleitung erfüllt sein.

Vorraussetzungen

Es werden grundlegende Kenntnisse im Umgang mit Ubuntu und der Kommandozeile vorrausgesetzt.

Es werden sehr gute Kenntnisse im Paketbau und Umgang mit OBS vorrausgesetzt.
Bei Problemen können wir hier wenig oder keine Beratung liefern, da dies oft mit hohem Aufwand verbunden ist.

Zugang/Login

Der Zugang zum Linux Build Service ist derzeit per Apache Konfiguration auf die folgenden Netze beschränkt:

Require ip 131.188.19.0/27
Require ip 131.188.18.0/26
Require ip 10.84.2.0/24

Um einen Login zum Linux Build Service zu erhalten wenden Sie sich mit Ihrem Anliegen (inkl. kurzer Beschreibung was Sie vorhaben) bitte an rrze-linux@fau.de
Bitte beachten Sie, dass wir den Dienst aktuell nur intern nutzen.

Pakete

Zum Einbinden von Paketquellen müssen folgende Pakete ür Ubuntu 16.04/18.04/20.04 installiert werden:

bash$ sudo apt-get install apt

Zur Verwaltung und Bau eigener Pakete müssen folgende Pakete für Ubuntu 16.04/18.04/20.04 installiert werden:

bash$ sudo apt-get install osc

Einbinden von Paketquellen

Für das Einbinden von Linux OBS Repositories werden Zugangsdaten benötigt. Diese haben nichts mit dem Login für die Online Oberfläche zu tun und können bei Bedarf unter rrze-linux@fau.de erfragt werden.

Das Folgende Beispiel zeigt exemplarisch das Vorgehen zum Einbinden des System:Net:Apache Projektes:

# 1. Create file with reference to the repo
bash$ cat /etc/apt/sources.list.d/rrze-obs.list
deb https://www.linux.rrze.fau.de/obsrepo/System%3A/Net%3A/Apache/xUbuntu_18.04/ ./

# 2. Add file containing the authentication credentials
bash$ cat /etc/apt/auth.conf.d/rrze-obs.list
machine www.linux.rrze.fau.de login {USERNAME} password {PASSWORD}

# 3. Download and add the repository to the trusted APT keys
bash$ curl -L https://{USERNAME}:{PASSWORD}@www.linux.rrze.fau.de/obsrepo/System%3A/Net%3A/Apache/xUbuntu_18.04/Release.key | apt-key add -
 % Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 1428 100 1428 0 0 95200 0 --:--:-- --:--:-- --:--:-- 95200
OK

Bau eigener Pakete

Der Linux Build Service ist erreichbar unter https://www.linux.rrze.fau.de/obs/

TODO

Command Line Interface über OSC

Der BuildService stellt mit OSC auch ein Kommandozeileninterface bereit.
Als Server-URL ist hier ebenfalls https://www.linux.rrze.fau.de/obs/ einzutragen.

CIP-Pool Remote Zugriff über VNC

Im RRZE-Betreuten CIP-Pool EEIWW kann mittels VNC die CIP-Pool Maschinen zugegriffen werden.
Hierzu wird folgende Software benötigt:

  • VPN Client – Empfohlen wird der CISO VPN Client im Splittunnel Betrieb
  • SSH Client – für Windows wird PuTTY empfohlen
  • TurboVNC Client – Clients für alle gängigen Betriebssysteme (Windows, Linux, MacOS) vorhanden

Nach der Installation der Programme sind folgende Schritte zum Starten des VNC Servers und Aufbau der Verbindung notwendig.

  1. Verbindung zum FAU-VPN (VPN Client im Splittunnel)
  2. Anmeldung per SSH und starten des VNC-Servers
  3. Starten des TurboVNC Clients und Aufbau der VNC Verbindung

Es muss zunächst eine Verbindung zum FAU-VPN bestehen, da die CIP-Pool Maschinen ohne VPN nicht von außerhalb des UNI-Netzes erreichbar sind. Mit vorhandener VPN-Verbindung kann nun mittels des SSH-Clients eine Verbindung zu einer CIP-Pool Maschine hergestellt werden. Die Anmeldung erfolgt den CIP-Anmeldedaten. Nach erfolgreichen Login kann mit „start_vnc“ der VPN Server gestartet werden. Zunächst muss einmalig ein Passwort für den Zugriff gesetzt werden (bitte nicht das IdM-Passwort). Nachdem der VNC Server erfolgreich gestartet wurde ist eine Ausgabe wie folgt zu sehen:

Desktop 'TurboVNC: cip114-23:1 (<kennung>)' started on display cip114-23:1

Starting applications specified in /home/eeiww/<kennung>/.vnc/xstartup.turbovnc
(Enabling VirtualGL)
Log file is /home/eeiww/<kennung>/.vnc/cip114-23:1.log

 

Jetzt kann mit dem TurboVNC Client die Verbindung zum Server aufgebaut werden. Hier sind Hostname und Display (siehe VNC-Server Log) notwendig. Z. B. cip114-23.ww.uni-erlangen.de:1. Daraufhin erfolgt die Authentifizierung mit dem vorher gesetzten Passwort.

Falls bereits eine VNC Session durch einen anderen Benutzer gestartet wurde, wird der nächste verfügbare Display z.B. :2 genutzt. Es wird emfohlen auf einer Maschine maximal 3 VNC Sessions zu nutzen. Falls ein Display größer :3 zugewiesen wird, sollte eine andere CIP-Pool Maschine genutzt werden.

Zum Schließen der Verbindung sollte ein Terminal geöffnet werden und der Befehl „stop_vnc“ abgesetzt werden.

Dokumentation für vom RRZE betreute CIP-Pools

Diese FAQ ist für Betreiber und Nutzer von CIP-Pool Systemen bestimmt, die vom RRZE betreut werden.

  • Wie können weitere Personen einen Benutzer-Login/Admin-Login auf den betreuten Systemen erhalten?
    Falls Sie einen Login benötigen, so wenden Sie sich bitte direkt an den Betreiber des jeweiligen Systems.
    Wir bitten von direkten Anfragen an das RRZE abzusehen. Die Systeme gehören dem jeweiligen Betreiber und werden lediglich vom RRZE betreut. Das Freischalten weiterer Nutzer kann dementsprechend nur durch eindeutige Anweisung des Betreibers erfolgen.

    Zur Freischaltung weitere Kennungen benötigen wir einen entsprechenden Auftrag (zB per Mail) des Betreibers mit der jeweiligen Kennung und der hinzuzufügenden Gruppenzugehörigkeit.
  • Welche Rechte können vergeben werden?
    In der Regel besteht die Infrastruktur der betreuten Systeme aus einem Management-Server und den daran angebundenen Clients.
    Zur Rechteverwaltung werden zwei Gruppen herangezogen:
    ${PREFIX}_sudo für administrativen Zugang zum Management-Server und allen Clients (per sudo)
    ${PREFIX}_all für Zugang mit normalen Benutzerrechten zu allen Clients.

    Jegliche Rechtevergabe auf die betreuten Systeme kann nur durch eindeutige Anweisung des Betreibers erfolgen.
  • Wie können zusätzliche Ubuntu-Pakete auf allen Systemen installiert werden?
    Zu installierende Packete aus den Ubuntu Paketquellen können auf direkte Anweisung des Betreibers (am besten per Mail an rrze-linux@fau.de) automatisch auf alle Systeme verteilt werden.
    Eine Übersicht aller verfügbaren Pakete erhalten Sie unter https://packages.ubuntu.com/de/
  • Wie können Dateien/Programme, die nicht in der Ubuntu Paketverwaltung enthalten sind, auf alle Systeme verteilt werden?
    Um auf einfache Weise beliebige Dateien auf die lokale Festplatte aller Systeme zu verteilen steht auf dem Management-Server das Verzeichnis /data/dist zur Verfügung.
    Der Inhalt dieses Verzeichnisses wird einmal stündlich auf alle Clients synchronisiert. Das Zielverzeichnis auf den Clients ist ebenfalls /data/dist/.

    Um diesen Dienst nutzen zu können benötigen Sie administrativen Zugang zum Management-Server.
    Diese Aufgabe können wir nur für Sie übernehmen, falls der Betreiber einen entsprechenden Premium-Supportvertrag abgeschlossen hat, der die Verteilung generischer Software umfasst.
  • Ich möchte eine Software verteilen, die auf dem jeweiligen Zielsystem erst übersetzt werden muss. Wie gehe ich vor?
    In der Regel ist es nicht nötig die Software auf jedem Zielrechner erneut zu übersetzen, solange alle Zielrechner den gleichen Soft- und Hardwarestand haben. In CIP-Pools ist das üblicherweise der Fall.
    Und so gehen Sie vor:
    1. Installieren Sie die benötigen Bibliotheken aus den Ubuntu Paketquelle wie oben beschrieben (siehe Wie können zusätzliche Ubuntu-Pakete auf allen Systemen installiert werden?)
    2. Übersetzen Sie die Software auf einem der Clients
    3. Verteilen Sie das Ergebnis wie oben beschrieben vom Management-Server auf alle anderen Clients (siehe Wie können Dateien/Programme, die nicht in der Ubuntu Paketverwaltung enthalten sind, auf alle Systeme verteilt werden?).

    Um diesen Dienst nutzen zu können benötigen Sie administrativen Zugang zum Management-Server.
    Diese Aufgabe können wir nur für Sie übernehmen, falls der Betreiber einen entsprechenden Premium-Supportvertrag abgeschlossen hat, der die Verteilung generischer Software umfasst
  • Wie kann ich Befehle auf allen System gleichzeitig absetzen?
    In der Regel können Sie hierfür die dsh (Distributed Shell) einsetzen. Diese können Sie auf Ihrem Rechner installieren und dann per SSH-Verbindung Kommandos auf einer Liste von Zielrechnern absetzen.
    Für Einzelheiten zur Verwendung lesen Sie http://manpages.ubuntu.com/manpages/bionic/man1/dsh.1.html
    Wichtig:
    Nutzen Sie zum Absetzen der Befehle am besten einen der CIP-Pool Rechner.
    Dies ermöglicht Ihnen die anderen Rechner ohne Eingabe eines Passwortes zu erreichen (via Kerberos).

    Um diesen Dienst nutzen zu können benötigen Sie Zugang als Benutzer oder – je nach Art des abzusetzenden Befehls – auch administrativen Zugang auf die betreuten Systeme.
    Falls der Betreiber einen entsprechenden Premium-Supportvertrag abgeschlossen hat, können wir diese Aufgabe auch für Sie übernehmen.
  • Die bisherigen Lösungen reichen für mein Anliegen nicht aus. Welche Möglichkeiten gibt es noch?
    Kontaktieren Sie uns gerne unter rrze-linux@fau.de mit einer kurzen Beschreibung Ihres Anliegens und ggf einer Begründung warum die beschriebenen Lösung nicht ausreichend sind.
    Wir werden Ihr Anliegen dann prüfen und uns mit einem Lösungvorschlag bei Ihnen melden.

    Bei Anfragen betreffend Leistungen, die bereits durch bestehende Angebote abgedeckt sind, werden wir lediglich auf diese verweisen. (z.B. Verteilung generischer Software -> Premium-Modell)

Verwendung von Adressbereichen

An dieser Stelle sollen die Verwendung von Adressbereichen öffentlich dokumentiert werden, so dass Mitarbeiter des RRZE sowie auch externe Administratoren in der Lage sind reservierte Bereiche zu meiden bzw. frei nutzbare Bereiche bestimmungsgemäß zu verwenden.

Benutzer und Gruppen

Dokumentation von verschiedenen reservierten Bereichen in Bezug auf die Vergabe von uidNumber und gidNumber.

Grundsätzlich darf kein Bereich einfach verwendet werden, auch wenn dieser als „–frei–“ gekennzeichnet ist.

Nur grün hinterlegte Adressbereiche stehen zur freien Verwendung durch lokale Administratoren zur Verfügung!

Legende

SYSTEM RESERVED Dieser Bereich wird durch das Betriebssystem selbst verwendet, um Benutzer/Gruppen für Systemdienste anzulegen.
RRZE RESERVED Dieser Bereich wird vom RRZE genutzt.
FUTURE RESERVED Dieser Bereich ist für zukünftige Anforderungen reserviert.
Auch wenn der Bereich grundsätzlich als frei anzusehen ist, kann dieser in Zukunft einer festen Verwendung zugeordnet werden. Sie dürfen diesen Bereich deshalb keinesfalls ohne Absprache mit dem RRZE einfach verwenden.

Benutzer (uidNumber)

Bereich Beschreibung Verwendung PAM
0 root SYSTEM RESERVED  
 
 
1-999 pseudo-users
SYSTEM RESERVED
1.000-1.999 lokale Benutzer freie Vergabe durch Systemadministrator
2.000-9.999 — frei — FUTURE RESERVED

K
E

R
B
E
R
O
S

10.000-65.533 RRZE-BV (legacy) RRZE RESERVED
65.534 „nobody“-Benutzer SYSTEM RESERVED
65.535-79.999 RRZE-BV (legacy) RRZE RESERVED
80.000-89.999 — frei — FUTURE RESERVED
90.000-99.999 Kursverwaltung (COMA) RRZE RESERVED
100.000-109.999 RRZE-BV (legacy) RRZE RESERVED
110.000-199.999 — frei — FUTURE RESERVED
200.000-209.999 RRZE-BV (legacy) RRZE RESERVED
210.000-249.999 — frei — FUTURE RESERVED
250.000-299.999 RRZE-BV (legacy) RRZE RESERVED
300.000- IdM RRZE RESERVED

Gruppen (gidNumber)

0 root SYSTEM RESERVED
1-999 system allocated groups
SYSTEM RESERVED
1.000-1.999 lokale Gruppen freie Vergabe durch Systemadministrator (TODO: cleanup 1202 to free up this chunk)
2.000-4.999 — frei — FUTURE RESERVED
5.000-5.999 RRZE-BV (legacy) RRZE RESERVED
6.000-9.999 — frei — FUTURE RESERVED
10.000-28.999 RRZE-BV (legacy) RRZE RESERVED
29.000-37.999 — frei — FUTURE RESERVED
38.000-49.999 RRZE-BV (legacy) RRZE RESERVED
50.000-89.999 — frei — FUTURE RESERVED
90.000-90.999 Windows-Gruppe RRZE RESERVED
91.000-91.999 Kursverwaltung (COMA) RRZE RESERVED
92.000-99.000 — frei — FUTURE RESERVED
100.000- IdM RRZE RESERVED

 

Nutzung des RRZE Ubuntu FTP-Mirrors

Das RRZE empfiehlt die Nutzung des RRZE Ubuntu FTP-Mirrors, um

  • nicht abhängig von der Verfügbarkeit externer Paketquellen zu sein
  • die Verteilung von Paketen an viele Clients bei beschränkter Bandbreite der Internetanbindung zu beschleunigen
  • und die offiziellen Ubuntu-Paketserver nicht unnötig zu belasten

Diese Anleitung beschreibt die Konfiguration eines Ubuntu-Clients für die Nutzung des RRZE Ubuntu FTP-Mirrors.

Vorbereitung

Bitte prüfen Sie die vorbereitenden Schritte bevor Sie versuchen einzelne Teile der Anleitung durchzuführen.
In der Regel müssen diese Vorraussetzungen für ein sinnvolles Umsetzen der Anleitung erfüllt sein.

Vorraussetzungen

Es werden grundlegende Kenntnisse im Umgang mit Linux und der APT-Paketverwaltung vorrausgesetzt.

Pakete

Es müssen keine zusätzlichen Pakete installiert werden

Einrichtung

Um den RRZE Ubuntu FTP-Mirror zu nutzen müssen lediglich die entsprechenden Einträge in der Datei /etc/apt/sources.list angepasst werden.

Bevor Änderungen vorgenommen werden, sollte die Originaldatei gesichert werden:

bash$ cp /etc/apt/sources.list /etc/apt/sources.list.orig

Die nötigen Ersetzungen können dann mit folgenden Befehlen durchgeführt werden:

bash$ sed -i "s/de\.archive\.ubuntu\.com/ftp.fau.de/" /etc/apt/sources.list
bash$ sed -i "s/ports\.ubuntu\.com/ftp.fau.de\/ubuntu-ports/" /etc/apt/sources.list

Absichtlich ausgnommen ist security.ubuntu.com, so dass die neuesten Sicherheitsupdates immer direkt vom Ubuntu Server bezogen werden können.


Test

Ein Update der Paketquellen sollte – mit Ausnahme von security.ubuntu.com – eine Ausgabe liefern, die ausschließlich ftp.uni-erlangen.de als Quelle angibt.

bash$ apt-get update
Hit:2 http://ftp.uni-erlangen.de/pub/mirrors/ubuntu bionic InRelease             
Get:3 http://ftp.uni-erlangen.de/pub/mirrors/ubuntu bionic-updates InRelease [88.7 kB]
Get:16 http://security.ubuntu.com/ubuntu bionic-security InRelease [83.2 kB]        
Get:17 http://security.ubuntu.com/ubuntu bionic-security/main amd64 DEP-11 Metadata [204 B]
Get:18 http://security.ubuntu.com/ubuntu bionic-security/universe amd64 DEP-11 Metadata [9,412 B]
Get:19 http://security.ubuntu.com/ubuntu bionic-security/universe DEP-11 64x64 Icons [16.3 kB]
Get:5 http://ftp.uni-erlangen.de/pub/mirrors/ubuntu bionic-updates/main amd64 Packages [438 kB]
Get:6 http://ftp.uni-erlangen.de/pub/mirrors/ubuntu bionic-updates/main i386 Packages [389 kB]
Get:7 http://ftp.uni-erlangen.de/pub/mirrors/ubuntu bionic-updates/main amd64 DEP-11 Metadata [192 kB]
Get:8 http://ftp.uni-erlangen.de/pub/mirrors/ubuntu bionic-updates/main DEP-11 48x48 Icons [47.1 kB]
Get:9 http://ftp.uni-erlangen.de/pub/mirrors/ubuntu bionic-updates/main DEP-11 64x64 Icons [89.9 kB]
Get:10 http://ftp.uni-erlangen.de/pub/mirrors/ubuntu bionic-updates/universe i386 Packages [570 kB]
Get:11 http://ftp.uni-erlangen.de/pub/mirrors/ubuntu bionic-updates/universe amd64 Packages [575 kB]
Get:12 http://ftp.uni-erlangen.de/pub/mirrors/ubuntu bionic-updates/universe amd64 DEP-11 Metadata [194 kB]
Get:13 http://ftp.uni-erlangen.de/pub/mirrors/ubuntu bionic-updates/universe DEP-11 48x48 Icons [178 kB]
Get:14 http://ftp.uni-erlangen.de/pub/mirrors/ubuntu bionic-updates/universe DEP-11 64x64 Icons [298 kB]
Get:15 http://ftp.uni-erlangen.de/pub/mirrors/ubuntu bionic-updates/multiverse amd64 DEP-11 Metadata [2,464 B]
Fetched 3,176 kB in 6s (557 kB/s)              
Reading package lists... Done

PPA spiegeln mit apt-mirror

Um nicht abhängig von der Verfügbarkeit externer Paketquellen zu sein und/oder die Verteilung von Paketen an viele Clients bei beschränkter Bandbreite der Internetanbindung zu beschleunigen, kann ein lokaler Mirror der benötigten Paketquellen eingerichtet werden.

Diese Anleitung beschreibt die Einrichtung eines Mirrors für Ubuntu Personal Package Archives (PPA) mit apt-mirror.

Vorbereitung

Bitte prüfen Sie die vorbereitenden Schritte bevor Sie versuchen einzelne Teile der Anleitung durchzuführen.
In der Regel müssen diese Vorraussetzungen für ein sinnvolles Umsetzen der Anleitung erfüllt sein.

Vorraussetzungen

Es werden Kenntnisse im Umgang mit Linux und der APT-Paketverwaltung vorrausgesetzt.

Pakete

Die folgender Pakete müssen installiert werden.

Ubuntu 16.04

bash$ sudo apt-get install apt-mirror

Einrichtung

Nach der Installation der Pakete müssen lediglich die zu spiegelnden PPAs konfiguriert werden.
Um Zugriff auf den Mirror durch die Clients zur Verfügung zu stellen wird ebenfalls ein Webserver, wie z.B. Apache oder Nginx benötigt.

Siehe auch https://wiki.ubuntuusers.de/apt-mirror/ für weitere Informationen.

Konfiguration von apt-mirror

Die Konfiguration wird am Beispiel des PHP PPAs von Ondřej Surý durchgeführt und kann leicht auf weitere PPAs erweitert werden.

bash$ cat /etc/apt/mirror.list
############# config ##################
set base_path    /var/spool/apt-mirror
set mirror_path  $base_path/mirror
set skel_path    $base_path/skel
set var_path     $base_path/var
set cleanscript $var_path/clean.sh
#set postmirror_script $var_path/postmirror.sh
#set run_postmirror 0

set limit_rate 500K # 10 * 500K = 5000K = 5M => 50MBit
set nthreads     10
set _tilde 0
############# end config ##############

# PHP
deb http://ppa.launchpad.net/ondrej/php/ubuntu xenial main 
deb http://ppa.launchpad.net/ondrej/php/ubuntu trusty main 
deb http://ppa.launchpad.net/ondrej/php/ubuntu bionic main 
clean http://ppa.launchpad.net/ondrej/php/ubuntu

Automatische Synchronisation per Cronjob

Das apt-mirror Paket liefert gleich einen passenden Cronjob mit, der nur noch aktiviert werden muss.

bash$ cat /etc/cron.d/apt-mirror
#
# Regular cron jobs for the apt-mirror package
#
0 4 * * * apt-mirror /usr/bin/apt-mirror > /var/spool/apt-mirror/var/cron.log

Bereitstellen der Pakete

Damit Clients den Mirror nutzen können muss serverseitig die Pakete per HTTP freigegeben werden (z.B. mittels Apache oder Nginx).
Die Installation des entsprechenden Webservers vorausgesetzt ist hierfür nur noch ein entsprechender Symlink notwendig.

Zum Beispiel

bash$ ln -s /var/spool/apt-mirror/mirror/ /var/www/html/

Einbinden auf den Clients

Um den Mirror zu nutzen, kann eine entsprechende Datei unter /etc/apt/sources.list.d/ erstellt werden.
Wegen https://bugs.launchpad.net/ubuntu/+source/apt-mirror/+bug/1586573 muss (sofern der Bug noch besteht) auf das hashbasierte Abrufen der Pakete verzichtet werden.

bash$ cat /etc/apt/sources.list.d/mirror-php.list
deb [arch=amd64 by-hash=no] http://[your-server]/mirror/ppa.launchpad.net/ondrej/php/ubuntu bionic main

Test

Die Synchronisation kann zum Test jederzeit manuell gestartet werden.

bash$ apt-mirror
Downloading 42 index files using 10 threads...
Begin time: Thu Nov 15 12:02:43 2018
[10]... [9]... [8]... [7]... [6]... [5]... [4]... [3]... [2]... [1]... [0]... 
End time: Thu Nov 15 12:02:43 2018

Processing tranlation indexes: [TTT]

Downloading 9 translation files using 9 threads...
Begin time: Thu Nov 15 12:02:43 2018
[9]... [8]... [7]... [6]... [5]... [4]... [3]... [2]... [1]... [0]... 
End time: Thu Nov 15 12:02:43 2018

Processing DEP-11 indexes: [DDD]

Downloading 0 dep11 files using 0 threads...
Begin time: Thu Nov 15 12:02:43 2018
[0]... 
End time: Thu Nov 15 12:02:43 2018

Processing indexes: [PPP]

0 bytes will be downloaded into archive.
Downloading 0 archive files using 0 threads...
Begin time: Thu Nov 15 12:02:43 2018
[0]... 
End time: Thu Nov 15 12:02:43 2018

0 bytes in 0 files and 0 directories can be freed.
Run /var/spool/apt-mirror/var/clean.sh for this purpose.

Running the Post Mirror script ...
(/var/spool/apt-mirror/var/postmirror.sh)


Post Mirror script has completed. See above output for any possible errors.

	

Windows Shares unter Linux einbinden

Bei der Verwendung von Windows-Netzlaufwerken (Shares) unter Linux ist einiges zu beachten, um eine reibungslose Funktion sicherzustellen.
Neben den verschiedenen Methoden einen Mount unter Linux generell zu realisieren sind auch einige Eigenheiten von Windows/Linux zu beachten.

Diese Anleitung beschreibt einige gängige Varianten, um Windows-Netzlaufwerke unter Ubuntu einzubinden und liefert unter Anderem auch Beispiele für die Nutzung mit der FAUAD.

Vorbereitung

Bitte prüfen Sie die vorbereitenden Schritte bevor Sie versuchen einzelne Teile der Anleitung durchzuführen.
In der Regel müssen diese Vorraussetzungen für ein sinnvolles Umsetzen der Anleitung erfüllt sein.

Vorraussetzungen

Es werden root-Zugriff auf den Rechner und allgemeine Kenntnisse im Umgang mit der Linux-Konsole vorrausgesetzt.

Für Varianten mit Kerberos Authentifizierung ist die Einrichtung Kerberos erforderlich.
Entsprechende Hinweise zur Konfiguration von Kerbero finden Sie unter „Kerberos Grundkonfiguration„.

Pakete

Die folgender Pakete müssen installiert werden.

CIFS unter Ubuntu 14.04/16.04/18.04

Für das Common Internet File System (CIFS) werden folgende Pakete benötigt.

bash$ sudo apt-get install cifs-utils

GVFS unter Ubuntu 14.04/16.04/18.04

Für Gnome Virtual Filesystem (GVFS) werden folgende Pakete benötigt.
Bei einer Standard Ubuntu-Desktop Installation sind diese Pakete in der Regel schon als Teil von ubuntu-desktop vorinstalliert.

bash$ sudo apt-get install gvfs gvfs-bin gvfs-backends gvfs-fuse

FUSE unter Ubuntu 14.04/16.04/18.04

Für Nutzung des Filesystem in USErspace (FUSE) werden folgende Pakete benötigt.
Bei einer Standard Ubuntu-Desktop Installation sind diese Pakete in der Regel schon als Teil von ubuntu-desktop vorinstalliert.

bash$ sudo apt-get install fuse

Besonderheiten zu Windows Distributed File Services (DFS) und der FAUAD

Windows (und damit auch die FAUAD) nutzen ein Feature namens Distrubuted File Services (DFS), um die von diversen Shares genutzen Pfade auf konkrete Dateiserver zu Mappen, die dann letzendlich den Dienst stellen. DFS-Pfade erkennt man an der Nutzung von fauad.fau.de als Servernamen.

Leider ist die Unterstützung dieses Features in den Linux-Implementierungen des CIFS-Protokolls nicht komplett integriert. Der empfohlene Workaround ist die direkte Nutzung der entsprechenden Dateiserver anstatt des DFS-Pfades (inkl. der genannten Nachteile bei Umstellungen).

Sollten Sie Windows-Dateidienste des RRZE nutzen und sich nicht sicher sein, wie der Name das entsprechenden Dateiservers lautet, so wenden Sie sich bitte an die Windows-Gruppe unter rrze-windows@fau.de.

Detailierte Erklärung

Der Vorteil dieses Systems liegt daran, das bei Umzug eines Dateidienstes auf einen neuen Server lediglich das Mapping des bestehenden DFS-Pfades angepasst werden muss. Alle angebundenen Clients bleiben von der Änderung verschont, da diese weiterhin den ungeänderten DFS-Pfad nutzen und über das angepasste Mapping automatisch auf den neuen, aktualisierten Dateiserver geleitet werden.

Speziell wird in der FAUAD eine Aufteilung der Rechner auf mehrere Sites vorgenommen, die von der aktuellen CIFS Implementierung nicht beachtet wird. Daher kommt es bei Nutzung von DFS-Pfaden in CIFS-Mounts zu dem geht/geht-nicht Phänomen – je nachdem, ob man zufällig auf einem Domänenkontroller in der richtigen Site landet, oder eben nicht.

Einrichtung

Mountvorgänge für das Common Internet File System (CIFS) mittels mount.cifs können in der Regel nur mit root-Rechten durchgeführt werden.
Der Zugriff kann dann – je nach Dateirechten – als normaler Benutzer erfolgen.

Um auch als unpriviligierter Benutzer Netzlaufwerke einhängen zu können stehen ebenfalls verschiedene Möglichkeiten zur Verfügung. Zum Beispiel ermöglicht das Gnome Virtual Filesystem (GVFS) schon seit längerem das Einbinden von diversen Netzlaufwerkstypen über die graphische Oberfläche ohne besondere Rechte. Als Grundlage des gvfs-fuse Moduls soll auch das Filesystem in USErspace (FUSE) nicht unerwähnt bleiben.

Die Folgenden Abschnitte zeigen wie man die häufigsten Anwendungsfälle mit den verschiedenen Tools  bewältigen kann und geht auf Vor- und Nachteile, sowie die Besonderheiten der Lösungen ein.

Zunächst kann man zwischen zwei großen Hauptkategorien unterscheiden: systemweites oder benutzerbezogenes Einrichten eines Netzlaufwerkes

Systemweite Einrichtung

Das systemweite Einhängen von Netzlaufwerken ermöglicht den Zugriff durch alle Benutzer des Systems (passende Benutzer-/Dateirechte vorrausgesetzt), kann aber nur als Administrator mit root-Rechten vorgenommen werden.

 

Manuelles Einhängen mit dediziertem Benutzer

Ein einfaches Beispiel ist das Einhängen mittels des mount Befehls auf der Konsole.

Ersetzen Sie ggf. die fett hervorgehobenen Daten durch passende Werte. Der angegebene Befehl stellt lediglich zum Testen sinnvolle Standardeinstellungen her.

# mount
bash$ sudo mount -t cifs -o user=$USER,uid=$UID,gid=0,file_mode=0660,dir_mode=0770,domain=FAUAD,noserverino,nodfs,vers=2.1 //projekte.rrze.uni-erlangen.de/rrze_projekte/RRZE-Share /mnt/projekte
Password for $USER@//projekte.rrze.uni-erlangen.de/rrze_projekte/RRZE-Share: ********

# check rights (uid/gid are mapped as access rights for the mountpoint)
bash$ ls -aldn /mnt/projekte
drwxr-xr-x 2 $UID 0 0 Mai 15 14:08 /mnt/projekte/

# umount
bash$ sudo umount /mnt/projekte

Der Einhängepunkt ist so zwar generell durch den Benutzer uid=$USER und alle Mitglieder der Gruppe gid=0 nutzbar, allerdings gelten auf dem Dateiserver lediglich die Rechte des Benutzers user=$USER mit dem der Mount aufgebaut wurde, egal welcher Benutzer auf Client-Seite den Zugriff durchführt.

Zudem ist der Mount nicht persistent, wird also nach Verlust des Mounts nicht wiederhergestellt.

 

Manuelles Einhängen mit Kerberos-Authentifizierung

Im Prinzip funktioniert dieser Mount ähnlich dem vorhergehenden, mit dem Unterschied, das die Authentifizierung gegen den Dateiserver diesmal nicht mit manuell einzugebenden Daten und nur einem Benutzer erfolgt.
Stattdessen kann jeder per Kerberos authentifizierte Benutzer des System mit den Rechten seines eigenen Prinzipals auf den Dateiserver zugreifen.
Siehe hierzu auch Kerberos Grundkonfiguration zur Einrichtung von Kerberos auf Ihrem System.

Die Option cruid bestimmt den zu nutzenden Kerberos credentials cache. Sofern der sudo-Befehl von einem per Kerberos authentifizierten Benutzer ausgeführt wird, muss hier keine Anpassung vorgenommen werden.

bash$ sudo mount -t cifs -o domain=FAUAD,sec=krb5,cruid=$UID,multiuser,noserverino,nodfs,vers=2.1 //projekte.rrze.uni-erlangen.de/rrze_projekte/RRZE-Share /mnt/projekte

Möglich wird dies durch die Option multiuser:

multiuser
Map user accesses to individual credentials when accessing the server. By default, CIFS mounts only use a
single set of user credentials (the mount credentials) when accessing a share. With this option, the client
instead creates a new session with the server using the user’s credentials whenever a new user accesses the
mount. Further accesses by that user will also use those credentials.  Because the kernel cannot prompt
for passwords, multiuser mounts are limited to mounts using sec= options that don’t require passwords.

Nach erfolgreichem Mount können nun alle per Kerberos authentifizierten Benutzer des Systems auf das Netzlaufwerk mit ihren eigenen Benutzerrechten zugreifen.
Allerdings ist der Mount noch immer nicht persistent und wird bei einem Verbindungsabbruch nicht wiederhergestellt.

 

Automatisches Einhängen mit autofs

AutoFS ermöglicht die das automatische Ein- und Aushängen von Netzlaufwerken bei Bedarf und ermöglicht es auch Mounts nach Verbindungsabbrüchen wiederherzustellen.
Beachten Sie bitte hierzu  bitte zunächst die Hinweise zum Betrieb von AutoFS am RRZE.

Ein zu den bisherigen Beispielen passender Eintrag in der Datei /etc/auto.proj könnte zum Beispiel wie folgt aussehen:

bash$ sudo vi /etc/auto.proj
projekte -fstype=cifs,domain=FAUAD,sec=krb5,multiuser,cruid=$UID,noserverino,nodfs,vers=2.1 ://projekte.rrze.uni-erlangen.de/rrze_projekte/RRZE-Share

Vergessen Sie nicht nach Änderungen der Konfiguration den autofs Dienst neu zu starten.

Die Verwendung von AutoFS ist vom RRZE für die meisten Fälle empfohlen.

 

Benutzerbezogene Einrichtung

Das benutzerbezogene Einhängen von Netzlaufwerken ermöglicht lediglich den Zugriff durch den aktuellen Benutzer und kann ohne Administratorrechte durchgeführt werden.

 

Halbautomatisches Einhängen mittels GVS

Siehe  Gnome Samba Client.

 

Paketverwaltung mit apt

Diese Seite befindet sich noch im Aufbau und wird von Zeit zu Zeit erweitert werden!

Um Softwarepakete auf Debian-basierten Systemen (wie zB Ubuntu) zu verwalten kommt in der Regel das Paketverwaltungsystem rund um APT (Advanced Packaging Tool) zum Einsatz.  Dieses sehr mächtige System bietet eine Reihe von Möglichkeiten Pakete zu installieren und aktuell zu halten.

Diese Anleitung beschreibt das vom RRZE empfohlene Vorgehen im Umgang mit der APT Paketverwaltung und gibt Lösungsvorschläge für einige häufig auftretende Szenarien.

Vorbereitung

Bitte prüfen Sie die vorbereitenden Schritte bevor Sie versuchen einzelne Teile der Anleitung durchzuführen.
In der Regel müssen diese Vorraussetzungen für ein sinnvolles Umsetzen der Anleitung erfüllt sein.

Vorraussetzungen

Es werden grundlegende Kenntnisse im Umgang mit Ubuntu und der Kommandozeile vorrausgesetzt.

Pakete

Folgender Pakete für Ubuntu 16.04/18.04 müssen installiert werden:

bash$ sudo apt-get install apt

Basisfunktionen

Hier soll auf die wichtigsten Kommandos und Abläufe im täglichen Umgang mit der APT Paketverwaltung eingegangen werden.
Weitere Informationen finden Sie auch auf der Ubuntu APT Übersichtsseite.

Paketquellen einrichten und aktualisieren

Die Konfiguration der APT Paketquellen findet sich unter /etc/apt/sources.list bzw. /etc/apt/sources.list.d/.

Sollten hier Erweiterungen um neue Paketquellen vorgenommen werden, empfiehlt es sich eine neue Datei mit thematisch passendem Namen und der Endung .list unter /etc/apt/sources.list.d/ anzulegen und die entsprechenden Repositories dort zu erfassen.
Die Datei /etc/apt/sources.list wird eher für die System-/Basiskonfiguration der Ubuntu Paketquellen verwendet und sollte nicht für externe Repositories „missbraucht“ werden.

Sobald Änderungen an den Paketquellen vorgenommen wurden oder die letzte Aktualisierung schon eine Weile her ist sollten die Paketinformationen aktualisiert werden bevor neue Pakete installiert oder Aktualisierungen eingespielt werden.

Die Aktualisierung der Paketquellen erfolgt mittels

bash$ sudo apt update

Pakete finden/installieren/entfernen

System aktuell halten

Einzelne Pakete von der Aktualisierung ausnehmen

Regelmäßige Aufräumarbeiten

Lokale Firewall mit IP-Tables

Um Systeme mit sensiblen Daten vor unbefugtem Zugriff zu schützen, können beim RRZE besondere Netzzugriffsfilter (ACLs) beantragt werden, die über netzseitige Hardware-Firewalls realisiert werden. In manchen Fällen kann es dennoch sinnvoll sein zusätzlich eine lokale Firewall zu pflegen, um zB erhöhte Sicherheitsanforderungen oder sich häufig ändernde Regeln abbilden zu können.

Diese Anleitung beschreibt das vom RRZE empfohlene Anlegen und Verwalten einer IP-Tables basierten lokalen Firewall unter Ubuntu.

Vorbereitung

Bitte prüfen Sie die vorbereitenden Schritte bevor Sie versuchen einzelne Teile der Anleitung durchzuführen.
In der Regel müssen diese Vorraussetzungen für ein sinnvolles Umsetzen der Anleitung erfüllt sein.

Vorraussetzungen

Es werden Kenntnisse im Umgang mit Firewalls im Allgemeinen und IP-Tables im Speziellen vorrausgesetzt.

Pakete

Die folgender Pakete müssen installiert werden.

Ubuntu 16.04

bash$ sudo apt-get install netfilter-persistent iptables-persistent

Ubuntu 18.04

bash$ sudo apt-get install netfilter-persistent iptables-persistent

Einrichtung

Das netfilter-persistent Paket liefert bereits einige Möglichkeiten, um Firewall-Regeln aus dem laufenden Betrieb zu persistieren und beim Systemstart wieder zu laden.
Eine kurze Einführung in die wichtigsten Funktionen finden Sie unten.
Für weitere Informationen besuchen Sie am besten die Ubuntu Manpage zu netfilter-persistent

Systemdienst einrichten

Der netfilter-persistent Dienst wird über die Plugins in /usr/share/netfilter-persistent/plugins.d/ konfiguriert.
Die Aufrufe des Init-Systems werden im Wesentlichen an alle verfügbaren Plugins der Reihe nach weitergereicht.

Der netfilter-persistent Dienst kennt die folgenen Aufrufe:

# Load firewall rules from /etc/iptables/rules.v[4|6]
# IMPORTANT: stop can be called but is essentially a no-op
bash$ sudo systemctl start netfilter-persistent

# Flush the firewall rules
bash$ sudo netfilter-persistent flush

# Show some status info
bash$ sudo systemctl status netfilter-persistent

# Enable loading of configured rules on startup
bash$ sudo systemctl enable netfilter-persistent

Regeln erstellen/persistieren

Um Firewall Regeln zu erstellen nutzt man am besten die iptables Kommandos, um die Firewall manuell zu konfigurieren.
Eine bestehende Konfiguration kann dann mittels

bash$ sudo systemctl save netfilter-persistent

gespeichert werden.
Nach dem Speichern kann die Konfiguration in den Dateien /etc/iptables/rules.v4 bzw /etc/iptables/rules.v6 wiedergefunden werden.
Weitere Änderungen können – dem Format folgend – auch direkt in diesen Dateien vorgenommen werden.

Beim Systemstart wird die Firewall aus den Regeln dieser Dateien wieder aufgebaut.

Regeln flushen/Firewall deaktivieren

Um die Regeln der Firewall komplett zu entladen und somit die Firewall zu deaktivieren, kann man entweder das entsprechende netfilter-persistent Kommando oder direkt IP-Tables verwenden.
WICHTIG: Ein Stoppen des netfilter-persistent Dienstes bewirkt kein deaktivieren der Firewall!

bash$ sudo netfilter-persistent flush
bash$ sudo iptables -F

Erweiterung um benutzerdefinierte Skripte

Um es beispielweise zu ermöglichen dynamische Firewallregeln aus einem Bash-Skript zu laden oder zu generieren kann auch der Plugin-Mechanismus von netfilter-persistent, um ein Plugin zum Aufruf eines entsprechenden Bash-Skriptes erweitert werden.

Die beiden nötigen Dateien samt Inhalt können nach folgender Anleitung erstellt werden.
Im Anschluss nicht vergessen die entsprechenden Regeln zu definieren 🙂

Skript für benutzerdefinierte Regeln

# create rules.custom skript and fill it with your firewall rules/generation script
bash$ sudo touch /etc/iptables/rules.custom
bash$ sudo chmod +x /etc/iptables/rules.custom
bash$ sudo vi /etc/iptables/rules.custom 
#!/bin/bash
set -e 
rc=0

load_rules() {
        # add config here
        echo "Called load_rules()!"   
}

flush_rules() {
        # add config here
        echo "Called flush_rules()!" 
}

case "$1" in
start)
        load_rules
        ;;
stop|flush)
        flush_rules
        ;;
*)
    echo "Usage: $0 {start|stop|flush}" >&2
    exit 1
    ;;
esac

exit $rc

 

Plugin für netfilter-persistent

# create netfilter-persistent plugin to execute your rules.custom script
bash$ sudo vi /usr/share/netfilter-persistent/plugins.d/99-custom
#!/bin/sh
set -e
rc=0

load_rules(){
	if [ ! -x /etc/iptables/rules.custom ]; then
		echo "Warning: skipping rules.custom (no rules to load)"
	else
		/etc/iptables/rules.custom start 2> /dev/null
		if [ $? -ne 0 ]; then
			rc=1
		fi
	fi
}

flush_rules(){
	if [ ! -x /etc/iptables/rules.custom ]; then
		echo "Warning: skipping rules.custom (no rules to flush)"
	else
		/etc/iptables/rules.custom flush 2> /dev/null
		if [ $? -ne 0 ]; then
			rc=1
		fi
	fi
}

case "$1" in
start|restart|reload|force-reload)
	load_rules
	;;
save)
	echo "Warning: skipping save_rules on rules.custom - not supported!"
	;;
stop)
	# Why? because if stop is used, the firewall gets flushed for a variable
	# amount of time during package upgrades, leaving the machine vulnerable
	# It's also not always desirable to flush during purge
	echo "Automatic flushing disabled, use \"flush\" instead of \"stop\""
	;;
flush)
	flush_rules
	;;
*)
    echo "Usage: $0 {start|restart|reload|force-reload|save|flush}" >&2
    exit 1
    ;;
esac

exit $rc

Test

Testen Sie die korrekte Initialisierung der Firewall einfach mit

bash$ sudo iptables -L

Linux

Das RRZE bietet Support für Linux für die Friedrich-Alexander-Universität Erlangen-Nürnberg (FAU) an.
Wir unterstützen Sie gerne bei Fragen zum Betrieb oder zur Betreuung von Linux-Systemen und versorgen Sie mit nützliche Informationen rund um Linux an der FAU.

Informationen zu Linux an der FAU

Für weitere Informationen zu Linux an der FAU besuchen Sie bitte die Homepage zu Linux am RRZE.

Dokumentation für vom RRZE betreute Systeme

Als Hilfe zur Selbsthilfe bieten wir Anleitungen zu häufig wiederkehrenden Problemen als Online-Dokumentation an.
Dieser Abschnitt ist für Betreiber und Nutzer von Systemen bestimmt, die vom RRZE betreut werden.
Für detailierte Anleitungen und Hilfestellungen lesen Sie unten weiter.

Dokumentation für selbstverwaltete Systeme

Als Hilfe zur Selbsthilfe bieten wir Anleitungen zu häufig wiederkehrenden Problemen als Online-Dokumentation an.
Dieser Abschnitt ist für Systemadministratoren bestimmt, die die jeweiligen Arbeiten in Eigenverantwortung selbst durchführen möchten.
Für detailierte Anleitungen und Hilfestellungen lesen Sie unten weiter.

Anbindung an die Infrastruktur des RRZE

In der folgenden Liste finden Sie Hilfestellungen zur Anbindung von selbstverwalteten Systemen an die RRZE-Infrastruktur.

  • FAU-CA Zertifikat einbinden
    Diese Anleitung beschreibt die Installation der FAU-CA Zertifkatskette in einem Ubuntu System, so dass das System in Zukunft allen Zertifikaten, die von der FAU-CA ausgestellt wurden vertraut.
  • LDAP-Anbindung für Rechner mit SSSD
    Diese Anleitung beschreibt das Anlegen eines Hosteintrags zum Zugriff auf die RRZE LDAP-Server für einen selbstverwalteteten Rechner und die Installation und Konfiguration des SSSD zur Benutzerauthentifizierung unter Ubuntu.
  • LDAP-Anbindung generischer Systeme
    Diese Anleitung beschreibt allgemein die Infrastruktur der RRZE LDAP-Server, um ggf eine Anbindung von eigenen Softwarepaketen realisieren zu können
  • LDAP-Gruppen
    Diese Anleitung beschreibt wie Sie automatisch befüllte oder manuell gepflegte Gruppen für Ihre Zwecke in den LDAP-Servern des RRZE bereitstellen lassen können
  • rrzelinux Kommandozeileninterface (CLI) (nur für IT-Betreuer) – derzeit Überführung in Produktivbetrieb
    Diese Anleitung beschreibt die Installation des rrzelinux Kommdozeileninterfaces für Administratoren nicht vom RRZE verwalteter Rechner. Dies ermöglicht es Ihnen beliebige Rechner unterhalb Ihrer DNS Domain in Eigenverantwortung an die RRZE-Infrastruktur (zB LDAP/Kerberos) anzubinden.
  • IPv6 Leitfadenin Entstehung
    Hier sollen Informationen zur Nutzung von IPv6 an der FAU gesammelt werden

Anbindung an die Kerberos-Infrastruktur des RRZE

Das RRZE setzt – wo immer möglich – auf die Authentifizierung mit Kerberos. Manche Dienste sind sogar ausschließlich per Kerberos nutzbar (z.B. das Linux-Homelaufwerk).
Die folgenden Anleitungen sollen Ihnen helfen Ihre selbstverwalteten Systeme an die Kerberos Infrastruktur des RRZE anzubinden.

  • Kerberos und langlaufende Prozesse
    Hinweise zur Ausführung langlaufender Prozesse (>10 Stunden) und Kerberos
    Bitte beachten, um Probleme mit abgebrochenen Jobs zu vermeiden!
  • Kerberos und WebSSO
    Anleitungen für gängige Browser, für automatische Kerberos Authentifizierung am WebSSO-Dienst der FAU

Druck- und Dateiserver

Das RRZE bietet diverse Druck-  und Dateidienste an, die teilweise sogar kostenlos allen Mitgliedern der FAU zur Verfügung stehen.
Die folgenden Anleitungen sollen Ihnen helfen diese Dienste zu nutzen.

  • Drucken über FAUPRINT
    Diese Anleitung beschreibt die Einrichtung von Druckern, die über den FAU-weiten Druckserver des RRZE (FAUPRINT) verwaltet werden
  • NFSv4-Server
    Kurzanleitung mit benötigten Paketen und Konfigurationsbeispielen zum Betrieb eines NFSv4 Dateiservers (inkl. Kerberos)

Hinweise zum Betrieb diverser Softwarepakete an der FAU

In der folgenden Liste von Softwarepaketen finden Sie wichtige Hinweise und Hilfe zum Betrieb der jeweiligen Software an der FAU.
Falls Sie eines der hier aufgelisteten Pakete einsetzen beachten Sie bitte die ggf. vorhandenen Hinweise auch dann, wenn vermeintlich „alles läuft“.
So kann ein reibungsloser und sicherer Betrieb sichergestellt werden.

  • AutoFS
    Kurze Einführung und empfohlene Standardkonfiguration mit Beispielen
  • Docker
    Betrieb von Docker-Containern an der FAU
    Bitte Hinweise zur Netzwerkkonfiguration beachten!
  • Paketverwaltung mit apt
    Pakete installieren, aktualisieren, von der Aktualisierung ausschließen, deinstallieren und das System sauber halten
  • Verwendung von Adressbereichen
    Übersicht über die Verwendung verschiedener Adressbereiche zur Vergabe von IDs (z.B. uidNumber, gidNumber, …)
    Bitte unbedingt beachten bei der Anlage lokaler Benutzer/Gruppen auf RRZE-verwalteten Rechnern!

Sonstige Dokumentation

Hier sammeln sich Dinge, die sonst nirgends reinpassen.

Diese Liste von Anleitungen ist nicht als grundsätzliche Empfehlung des RRZE zu verstehen, die entsprechende Software selbst zu betreiben bzw. die beschriebenen Schritte durchzuführen!
Die Inhalte sind nur als Ideensammluing oder allgemeine Dokumentation zu verstehen.