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 Voraussetzungen für ein sinnvolles Umsetzen der Anleitung erfüllt sein.

Voraussetzungen

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

Es werden sehr gute Kenntnisse im Paketbau und Umgang mit OBS vorausgesetzt.
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 empfohlen 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.

LDAP-Gruppen

Das RRZE stellt LDAP-Server zur Authentifizierung von Linux-Systemen, die von IT-Betreuern in Eigenverantwortung genutzt werden können (siehe auch Installation des rrzelinux CLI Tools). Um ebenfalls eine sinnvolle Autorisierung basierend auf Gruppenmitgliedschaften nutzen zu können, bietet das RRZE die Möglichkeit Gruppen nach Ihren Vorgaben einzurichten und zu befüllen (automatisch oder manuell).

Weitere Informationen zu diesem Thema enthält auch der passende BI-Artikel unter
https://www.rrze.fau.de/2020/01/rechteverwaltung-im-idm-grueppchenbildung-leicht-gemacht/.

Beantragung

Neue Gruppen oder Änderungen bestehender Gruppen können von einem IT-Betreuer (siehe https://www.rrze.fau.de/infocenter/rahmenbedingungen/it-beauftragte/) per E-Mail an rrze-linux@fau.de beantragt werden.

Bitte senden Sie zur Beantragung einer neuen Gruppe immer die folgenden Angaben mit:

  1. Gruppenname nach Namensschema
  2. Regelwerk zur Befüllung der Gruppe
  3. Zu aktivierende Zielsysteme — Windows (FAUAD) und/oder Linux (linuxldap)

Wir werden Ihre Anfrage dann schnellstmöglich bearbeiten.
Genauere Erläuterungen zu den einzelnen Punkten finden Sie in den folgenden Abschnitten.

Um die Übersicht für IT-Betreuer an dieser Stelle zu verbessern, ist bereits eine Weboberfläche in Entwicklung, um die bestehenden Gruppen samt Regelwerken sichtbar zu machen.
Es ist ebenfalls geplant, die Möglichkeit für IT-Betreuer zu schaffen, einfache Änderungen selbst durchzuführen.

Beispiele/Vorlagen

Hier werden kurz einige E-Mail-Beispiele aufgeführt, die Sie gerne als Vorlage verwenden können, um eine neue Gruppe oder Änderungen an einer bestehenden Gruppe an uns zu übermitteln.

Gruppe für alle Beschäftigten an Einrichtung/Präfix XYZ (Windows+Linux)

Gruppenname: xyz_employee
Regel zu Befüllung: 
    - Nutzergruppe: "Beschäftigte"
    - OrgEinheit: 1011120000 RRZE und darunter
Zielsysteme: Windows, Linux

Gruppe für alle Hilfskräfte an Einrichtung/Präfix XYZ (nur Windows)

Gruppenname: xyz_assistant
Regel zu Befüllung: 
    - Nutzertypen: 
        - "Studentische Hilfskräfte" 
        - "Wissenschaftliche Hilfskräfte"
    - OrgEinheit: 1011120000 RRZE und darunter
Zielsysteme: Windows

Gruppe für Whitelist zusammen mit OrgEinheit (nur Linux)

Gruppenname: xyz_project_x
Regel zu Befüllung: 
    - Whitelist: abcdefg, hijklmn, opqrst, uvwxyz
    - OrgEinheit: 1011120000 RRZE und darunter
Zielsysteme: Linux

1.Name

Alle Gruppennamen müssen der Bildungsregel [PRÄFIX]_[GRUPPENNAME] folgen.

Präfixe

Es handelt sich dabei um dieselben Präfixe, die auch zur Bildung von E-Mail-Adressen und im Active Directory der FAU (FAUAD) zum Einsatz kommen.
Weitere Informationen zum Einsatz und zur Beantragung von Präfixen finden Sie unter https://www.rrze.fau.de/internet-e-mail/e-mail/funktionsadressen/nicht-personenbezogene-e-mail-adressen/.
Nur in dieser Form beim RRZE beantragte und genehmigte Präfixe sind zur Anlage von Gruppen verwendbar.

Sollten Sie noch kein Präfix besitzen, das zur Verwaltung Ihrer Gruppen verwendet werden kann, muss dieses noch beantragt werden.

Gruppenname

Der Namensteil kann grundsätzlich frei gewählt werden, unterliegt aber folgenden Einschränkungen

  • Die Gesamtlänge (Präfix + ‚_‘ + Gruppenname) darf 80 Zeichen nicht überschreiten
  • Es dürfen keine Leer- oder Sonderzeichen verwendet werden
    Sonderzeichen sind: * \ $ ! \* ' " & ( ) \[ ] { } / # + = : ; | < > ? , ä ö ü (Umlaute), ß (scharfes s)

Gruppennamen sind jederzeit änderbar.
Die Attribute gidNumber und Windows SID werden sich bei einer Umbenennung nicht ändern.

3.Regelwerk

Das Regelwerk bestimmt, welche Kennungen der Gruppe hinzugefügt werden sollen.
Die Auswertung der hinterlegten Regeln wird durch unser IdM-System im Hintergrund erledigt und Ihre Gruppenmitgliedschaften somit automatisch aktuell gehalten.
Grundsätzlich können auch komplexe Regelwerke hinterlegt werden, in der Praxis lassen sich die meisten Anforderungen aber mit wenigen Bausteinen abdecken.
Im Folgenden werden einige der am häufigsten verwendeten Bausteine kurz vorgestellt.
Sollten Sie komplexere Anforderungen haben, besprechen Sie diese gerne mit uns persönlich oder stellen Sie Ihre Frage per E-Mail an rrze-linux@fau.de.

Organisationseinheiten

Ein grundlegender Baustein betrifft die Einschränkung auf Personen mit einer Zugehörigkeit zu Ihrer Organisationseinheit.
Gemeint ist hier letztendlich die FAU.org Nummer Ihrer Organisationseinheit (siehe auch https://www.rrze.fau.de/medien-entwicklung/daten-systemintegration/fau-org/). Manchmal wird als Synonym auch „Kostenstelle“ verwendet (obwohl das nicht ganz dasselbe ist).
Am besten ist es uns direkt Ihre FAU.org Nummer zu nennen, falls Sie diese kennen.
Normalerweise können wir auch über den Namen Ihrer Einrichtung an der FAU selbst herausfinden, wie die entsprechende FAU.org Nummer lautet.
Falls Sie sicher gehen möchten nennen Sie uns am besten beides:
  • Einrichtungsname und
  • FAU.org Nummer (falls bekannt)

Da die Organisationsstruktur an der FAU hierarchisch organisiert ist, ist es zudem wichtig anzugeben, ob jeweils die exakte Organisationseinheit oder auch alle darunter gemeint sind.

Nutzergruppen/-typen

Nach Festlegung der Organisationseinheit ist eigentlich immer eine zusätzliche Einschränkung auf einen bestimmten Personenkreis gewünscht, um beispielsweise Gruppen mit allen Mitarbeitern oder den Hilfskräften zu erstellen.
Bitte beachten Sie dazu die Übersicht der verfügbaren Nutzergruppen/Nutzertypen unter
https://www.idm.fau.de/dsms/docs/affiliations

Beachten Sie bitte die Unterscheidung zwischen Nutzergruppe (grob) und Nutzertyp (fein).

Spezialfall: Studierende

Mitglieder der Nutzergruppe „Studierende“ sind im FAU.org-Baum der Einheit „(90 00 00 00 00) Studierende“ zugeordnet.
Falls Sie eine Gruppe mit Studierenden erstellen möchten, ist eine Filterung derzeit meist nur auf Studiengänge möglich.

Kontaktieren Sie uns in jedem Fall gerne mit Ihrem Anliegen (rrze-linux@fau.de), damit wir Sie entsprechend beraten können und eine Lösung finden.

Whitelists

Hier können Sie uns eine Liste von Kennungen geben, die wir einfach als Mitglieder der Gruppe eintragen.
Das ist die unschönste Variante, da hier ständige manuelle Pflege erforderlich ist, aber manchmal lässt sich wohl nicht vermeiden.

Verknüpfen Sie die Whitelist mit zusätzlichen Kriterien, wie der Organisationseinheit und/oder den Nutzergruppen/-typen, so werden Kennungen wenigstens trotzdem automatisch aus der Gruppe entfernt, sobald beispielsweise ein Mitarbeiter Ihre Einrichtung verlässt.

Da es leider noch keine Möglichkeit gibt, als „IT-Betreuer“ die Whitelist selbst pflegen zu können, müssen Sie uns Änderungen per E-Mail an rrze-linux@fau.de mitteilen. Alle Änderungen werden dann gewöhnlich binnen einer Stunde von uns eingepflegt.

3.Zielsysteme

Alle Gruppen werden zentral in unserem IdM-System verwaltet und nach den jeweilig verknüpften Regelwerken befüllt. Das Ergebnis dieser Berechnung wird dann in den ausgewählten Zielsystemen aktualisiert.

Als Zielsysteme stehen Ihnen aktuell

  • die FAUAD für Windows-Systeme (ActiveDirectory) und
  • der LINUXLDAP für Linux-Systeme (OpenLDAP)

zur Auswahl.

Die Provisionierung der Gruppen kann nach Ihren Vorgaben in beide Zielsystem oder auch nur in ein Zielsystem erfolgen.
Diese Einstellung kann jederzeit angepasst werden.

Bitte beachten Sie, dass ein Deaktivieren und späteres Reaktivieren des Zielsystems FAUAD zur Neuanlage der Gruppe führt, wobei sich die Windows SID ändert.

RRZE-Chat

Das RRZE stellt eine auf XMPP basierende Chatlösung bereit, die zur FAU-internen Kommunikation genutzt werden kann.

Es handelt sich hierbei nicht um eine offizielle Dienstleistung! Es besteht kein Versorgungsanspruch.

Zur Authentifizierung wird die Verwendung von Kerberos empfohlen, da viele verbreitete XMPP-Clients Passwörter im Klartext ablegen und daher ein Sicherheitsrisiko darstellen.
Für eine Liste möglicher Chat-Clients siehe Abschnitt „Empfohlene Clients„.

Als Alternative zur lokalen Installation kann auch der Web-Chat unter https://www.linux.rrze.fau.de/chat genutzt werden.


Voraussetzungen

Soweit bekannt funktioniert der Kerberos Login nur mit Linux Installationen.
Für Windows-Nutzer wird der Web-Chat unter https://www.linux.rrze.fau.de/chat empfohlen.
Alternativ kann auch das „Windows Credentials“ Plugin für Pidgin verwendet werden.

Authentifizierung mit Kerberos — empfohlen!

Voraussetzung für die Nutzung der Kerberos-Authentifizierung ist eine funktionierende Grundkonfiguration von Kerberos für Ihr System. Falls noch nicht geschehen führen Sie bitte die entsprechenden Einrichtungsschritte wie beschrieben durch bevor Sie dieser Anleitung weiter folgen.

Falls Sie der Grundkonfiguration von Kerberos gefolgt sind und ihr Domain-Realm Mapping per Default auf LINUX.FAU.DE zeigt müssen Sie nichts weiter tun.

Für den Fall einer abweichenden Konfiguration stellen Sie sicher das folgendes Mapping existiert:
linux-chat.rrze.fau.de ---map-to-realm---> LINUX.FAU.DE

Zertifikatscheck (FAU-CA)

Ggf. werden Sie aufgefordert dem Zertifikat des Chat-Servers zu vertrauen.
Entweder Sie prüfen die Informationen des präsentierten Zertifikats manuell oder folgen der Anleitung FAU-CA Zertifikat einbinden, um das FAU-CA-Zertifikat systemweit als vertrauenswürdig einzubinden.

DNS-Cache

Um eine evtl. ungültige DNS-Konfiguration aus dem lokalen Cache zu entfernen, sollte dieser zur Sicherheit noch geleert werden.

bash$ systemd-resolve --flush-caches

Pakete für Ubuntu 16.04/18.04

# PIDGIN
bash$ sudo apt-get -y install pidgin libsasl2-modules-gssapi-mit
# GAJIM
bash$ sudo apt-get install gajim python3-kerberos

Konfiguration

Einrichtung von System und Chat-Client.

XMPP-Client Einstellungen

Die Einstellungen für den XMPP-Client sind wie folgt vorzunehmen:

Protocol XMPP
Username [IdM-Benutzername]
Domain linux-chat.rrze.fau.de
Ressource [frei wählbar, z.B. rrze, workstation, laptop, home, …]
Die Ressource bezeichnet das Gerät, von dem aus die Verbindung aufgebaut wird.
Conference-Server
conference.linux-chat.rrze.fau.de

Weitere Einstellungen sind für den Zugriff aus den FAU-Netzen nicht nötig.

Insbesondere ein evtl. vorhandenes Feld für ein Passwort muss für die Kerberos-Authentifizierung leer gelassen werden!


Für den Zugriff von außerhalb der FAU muss abweichend von der XMPP-Domain linux-chat.rrze.fau.de der Zugangsserver linux.rrze.fau.de (Port 5222) gesetzt werden. Hier ist momentan noch kein Zugang mittels Kerberos möglich.

 

 

Gruppen-Chats

Über Gruppen-Chats (sog. Multi-User-Chats oder kurz MUCs) können sich zwei oder mehr Personen austauschen.

Service: conference.linux-chat.rrze.fau.de

Gruppenchats können von jedem erstellt werden. Dazu einfach dem gewünschten Chat mit dem Chat-Client „joinen“ und ggf. die Einstellungen anpassen.

Persistente Chats bleiben bestehen (inkl. History).
Temporäre Chats werden automatisch wieder vom Server entfernt sobald der letzte Benutzer den Chat verlässt.

 

Kontaktlisten / Contact List (Roster) Sharing

Kontaktlisten werden — zumindest teilweise — vom Server vorgegeben (evtl. erlauben Clients auch das manuelle Pflegen von Einträgen).

Manuelle Kontaktlisten können Sie nach belieben lokal in Ihrem Chatclient pflegen. Achten Sie beim hinzufügen von Kontakten allerdings darauf immer die vollständige JID zu verwenden. Diese ist folgendermaßen aufgebaut: ${IDM-Benutzername}@linux-chat.rrze.fau.de

Serverseitige Kontaktlisten werden ausschließlich auf Basis von bestehenden Linux-Gruppen eingerichtet, die über die IdM-Gruppenverwaltung angelegt wurden.
Die Mitglieder der Kontaktliste werden entsprechend automatisch synchronisiert.

Damit nicht jeder jeden „sehen“ kann bzw. um eine gewisse Einteilung vorzugeben, können Kontaktlisten anhand von Gruppenzugehörigkeiten in unserem LDAP automatisch gepflegt werden.

Beispielsweise haben wir eine Kontaktliste „rrze_employee“ die auf der gleichnamigen LDAP-Gruppe basiert.
So können alle RRZE-Mitarbeiter sich gegenseitig leicht finden bzw. „sehen“.

Haben Sie bereits eine Gruppe, die Sie als Kontaktliste freischalten lassen möchten, so schreiben Sie bitte Ihr Anliegen mit Gruppennamen an rrze-linux@fau.de.

 

Paralleles Login mit mehreren Clients

Die parallele Nutzung mehrerer Chat-Clients wird unterstützt, sofern jeder Client eine eigene Ressource verwendet (siehe „XMPP-Client Einstellungen“) .
Die „Ressource“ bezeichnet dabei das Endgerät/den Standort oder Einsatzzweck des Clients und kann prinzipiell frei gewählt werden. Viele Clients wählen auch eine zufallsgenerierte Ressource.

Um das Ziel einer Nachricht eindeutig zu bestimmen, bildet der Server eine Zieladresse in der Form
Benutzername@Domain/Resource

Erfolgt ein Login auf eine bereits angemeldete Ressource, so wird die bestehende Verbindung getrennt.

 

Empfohlene Clients

Hier eine kleine Liste von Anwendungen, die wir zumindest schon einmal selbst getestet haben.
Kein Anspruch auf Vollständigkeit oder Funktionalität.

Mobile: Apple/iOS

Mobile: Android

Desktop: Apple/Mac OS

Desktop: Linux

Desktop: Windows

 

Spezielle Server-Einstellungen

Hier werden einige spezielle Einstellungen des Chat-Servers dokumentiert, die evtl. auch bei der Nutzung zu beachten sind.

Zustellung von Nachrichten an alle angemeldeten Ressourcen

Entgegen dem Standard-Verhalten wurde der Server so konfiguriert, dass Nachrichten an einen Benutzer immer an alle angemeldeten Clients des Benutzers (Ressourcen) weitergeleitet werden. Auf diese weise kann eine Synchronisation der Chat-Verläufe auf allen parallel angemeldeten Clients erreicht werden.

Diese Einstellung ignoriert evtl. vergebene Prioritäten auf die angemeldeten Ressourcen, mit Ausnahme von „-1“ (keine Zustellung).

(Referenz: route.all-resources/route.really-all-resources)

 

Supportete XMPP-Features

Das XMP-Protokoll besitzt zahlreiche Erweiterungen, welche nicht von allen Clients unterstützt werden.
Für Interessierte sind hier einige Informationen über die wichtigsten Erweiterungen zusammengetragen, welche auch von unserem Chat-Server unterstützt werden.

Der Web-Chat unter https://www.linux.rrze.fau.de/chat unterstützt alle aufgeführten Erweiterungen.

 

XEP-0363: HTTP File Upload

Unterstützt für das Hochladen von Dateien auf den Server und liefert einen Link zum erneuten Download der Datei.
Dies ist vor allem deshalb praktisch, da der oder die Empfänger der Datei nicht zum Zeitpunkt des Versendens online sein muss. Der Chatverlauf wird nach Upload der Datei einen Link enthalten unter dem diese auch zu einem späteren Zeitpunkt wieder heruntergeladen werden kann.

Derzeit ist der Upload von Dateien auf eine Größe von maximal 25MB beschränkt.
Die Dateien werden gelöscht, sobald der Speicherplatz zur neige geht oder der Chat-Server neu gestartet wird.

Siehe auch https://xmpp.org/extensions/xep-0363.html

——————–

Aktuelle Einschränkung:
Die Download Links funktionieren nur innerhalb des Uni-Netzes.  Das liegt aber nur an der Generierung des Links, was mit dem nächsten Update behoben wird.
Ersetzt man „https://linux-chat.rrze.fau.de:7443/“ durch „https://linux.rrze.fau.de/chat/“ so funktioniert es auch von außerhalb des Uni-Netzes.

Update (25.7.2019): Die Download Links werden jetzt korrekt generiert, so dass der Download auch außerhalb des Uninetzes funktioniert.

 

XEP-0313: Message Archive Management

Unterstützt das Abrufen und Konfigurieren eine Nachrichtenprotokolls auf dem Chat-Server.
Clients können so den Verlauf eines Gesprächs Abrufen und Anzeigen, auch wenn das Gespräch mit einem anderen Client/auf einem anderen Gerät stattgefunden hat.

Derzeit werden alle Chat-Nachrichten der letzten 90 Tage im Archiv des Servers gespeichert und sind durch die Clients abrufbar.

Siehe auch https://xmpp.org/extensions/xep-0313.html

 

XEP-0280: Message Carbons

Unterstützt das Senden von Nachrichtenkopien an parallel eingeloggte Clients des selben Benutzers.
So kann der Nachrichtenverlauf auf allen Clients (Ressourcen) synchron gehalten werden.

Siehe auch https://xmpp.org/extensions/xep-0280.html

——————–

Für Pidgin gibt es ein entsprechendes Plugin zum Download unter https://github.com/gkdr/carbons/releases
oder direkt per Shell mit

bash$ wget https://github.com/gkdr/carbons/releases/download/v0.2.2/carbons-0.2.2.so -O ~/.purple/plugins/carbons-0.2.2.so

 

XEP-0184: Message Receipts

Ermöglicht das Anfordern einer Empfangsbestätigung vom Empfänger einer Nachricht.
Clients können so das erfolgreiche Empfangen einer Nachricht anzeigen (z.B. mittels Häkchen).

Siehe auch https://xmpp.org/extensions/attic/xep-0184-1.0.html

 

XEP-0384: OMEMO Encryption

Ermöglicht Ende-zu-Ende Verschlüsselung in 1-zu-1 Chats.

Siehe auch https://xmpp.org/extensions/xep-0384.html

 

XEP-0048: Bookmarks

Ermöglicht das Speichern von Bookmarks aus Webseiten und Multi-User-Chaträume (MUCs).
So wird z.B. das automatische Beitreten zu MUCs (auto-join) beim Login ermöglicht.

Siehe auch https://xmpp.org/extensions/xep-0048.html

 

Pidgin Gnome Keyring

Speichert Passwörter verschlüsselt im Gnome Keyring ab. Damit wird die Klartext Speicherung in der accounts.xml Datei verhindert.

bash$ sudo apt install pidgin-gnome-keyring

Pidgin Encryption

Verschlüsselung mittels RSA-Keys. Plugin generiert, tauscht aus und verwaltet RSA-Keys zur Verschlüsselung. Gegenseite muss Plugin installiert haben.

bash$ sudo apt install pidgin-encryption

 

Pidgin Windows Credentials

  • Pidigin öffnen und „Extras“ => „Plugins“ auswählen
  • Im dann erscheinenden Fenster das Plugin „Windows Credentials“ auswählen und aktivieren
  • „Plugin konfigurieren“ auswählen
  • Im dann erscheinenden Fenster den Haken bei „Clear plaintext passwords from memory“ setzen
  • Die beiden Fenster (Windows Credentials und Erweiterungen) mit Klick auf „Schließen“ schließen

Ab jetzt wird das Chat-Passwort verschlüsselt im Windows-Passwort-Store gespeichert.
Wer das genannte Plugin „Windows Credentials“ in seinem installierten Pidgin nicht finden kann bitte bei der Windows-Gruppe melden.

 

 

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 Pakete 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ösungsvorschlag 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 High Performance Computing (HPC) RRZE 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-79.999 — frei — FUTURE RESERVED
80.000-89.999
High Performance Computing (HPC) RRZE 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

 

IPv6 Leitfaden

Hier sollen Informationen zur Nutzung von IPv6 an der FAU gesammelt werden.

Vorbereitung

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

Voraussetzungen

Es werden Kenntnisse im Umgang mit Linux und Netzwerken vorausgesetzt.

Pakete

Die folgender Pakete müssen installiert werden.

Einrichtung

{TODO}

Tests

Aktuelle DUID herausfinden

Der folgende one-liner kann dazu benutzt werden die aktuell verwendete DUID des Systems herauszufinden.
Diese wird zB benötigt, um einen entsprechenden DHCP-Eintrag zu beantragen.

bash$ for i in $(sudo find /var/lib/NetworkManager/ /var/lib/dhcp -name *.lease?); do grep client-id $i; done | sed -e 's/^[[:space:]]*//' | uniq

 

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 Voraussetzungen für ein sinnvolles Umsetzen der Anleitung erfüllt sein.

Voraussetzungen

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

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 ausgenommen 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 Voraussetzungen für ein sinnvolles Umsetzen der Anleitung erfüllt sein.

Voraussetzungen

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

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$ sudo -u apt-mirror 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 translation 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.

Problembehebung

Falsche Dateirechte nach Ausführung als root

APT-mirror legt beim Aufruf verschiedene Dateien mit den Rechten des aufrufenden Benutzers an. Da der Cronjob allerdings als Benutzer apt-mirror läuft klappt der Zugriff im Anschluss nicht mehr.
Zur Behebung kann man sich ein kleines Bash Script anlegen, dass man im Anschluss ausführt.

bash$ cat /root/fix-apt-mirror-permissions.sh 
#!/bin/bash
chown -R apt-mirror:apt-mirror /var/spool/apt-mirror/
chmod -R u=rwX,g=rwX,o=rX /var/spool/apt-mirror/

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 Voraussetzungen für ein sinnvolles Umsetzen der Anleitung erfüllt sein.

Voraussetzungen

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

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

Pakete

Die folgenden 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 Distributed File Services (DFS), um die von diversen Shares genutzten Pfade auf konkrete Dateiserver zu Mappen, die dann letztendlich 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.

Detaillierte 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 unprivilegierter 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 vorausgesetzt), 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.