Derzeit ist keine selbständige Registrierung möglich.

invis Server Administration

Ein komplexer Unternehmensserver wie der „invis-Server“ erfordert im laufenden Betrieb immer wieder Aufmerksamkeit. Es müssen gelegentlich Konfigurationen angepasst oder Online-Updates installiert werden. Diese Seite beschreibt wo und wie Sie an Ihrem Server arbeiten.

Hinweis: Nicht Aufgabe dieser Seite ist die Vermittlung von IT-Basiswissen. System- und Netzwerkadministratoren sollten darüber verfügen, oder in der Lage sein es sich anzueignen. Dies ist kein Vorwurf, an die Leser dieser Zeilen, sondern der Hinweis darauf, dass Server-Produkte wie ein invis-Server hoch komplexe Systeme sind, deren Administration Fachwissen verlangen. Wenn ich beispielsweise eine neue Wasserleitung im Haus benötige, wende ich mich auch an einen Sanitärbetrieb und versuche nicht selbst meine Wohnung unter Wasser zu setzen.

invis Portal

Das invis-Portal ist eine Schnittstelle für einfache administrative Tätigkeiten, weiterhin ermöglicht es den Zugriff auf komplexere Administrations-Software. Die nachfolgend genannten Funktionen stehen im invis-Portal nur nach erfolgreicher Anmeldung mit einem administrativen Konto sichtbar. Auf invis-Classic Systemen ist dies nach der Installation der Benutzer domadmin, auf invis-AD Systemen der Benutzer administrator.

Funktionen

  • Benutzerverwaltung: Anlegen und Löschen von Benutzern. Das Portal unterscheidet zwischen fünf verschiedenen Benutzertypen (Mailkonto, Benutzerkonto, Benutzerkonto mit Groupware-Zugang, Administratorenkonto und Gastkonto). Die Benutzertypen auf Active Directory Versionen des invis-Servers unterscheiden sich von denen des Classic Servers.
  • Gruppenverwaltung: Hinzufügen und Entfernen von Benutzergruppen und Zuordnen von Benutzern zu Gruppen. Werden hierüber Gruppen angelegt, wird automatisch ein Gruppenverzeichnis auf dem Fileserver angelegt.
  • Netzwerkorganisation: Hinzufügen und Entfernen von Netzwerkgeräten zur DHCP- und DNS-Konfiguration. Das Portal unterscheidet zwischen vier verschiedenen Geräteklassen (Server, Drucker, Client-PC und IP-Gerät). In Abhängigkeit der Klassen werden IP-Adressen aus dafür reservierten Bereichen vergeben.
  • Dienste: Ab invisAD 10.1 können über das Portal auch Dienste gestartet und gestoppt werden.

Zusätzliche administrative Werkzeuge

  • Mailinglisten: Mailinglisten sind das eMail Pendant zum klassischen Serienbrief. Über diese Schaltfläche können Sie neue Mailinglisten einrichten.
  • Verzeichnisdienst: Das LDAP-Verzeichnis Ihres invis-Server ist der zentrale Speicherort einer vielzahl von Konfigurationsdaten des Servers. Sie finden hier Daten zu DHCP, DNS, Benutzerverwaltung usw. Achtung der Umgang mit einem LDAP-Verzeichnis setzt entsprechende Grundkenntnisse voraus.
  • MySQL Administration: Administration der Datenbank-Engine MySQL. MySQL wird beispielsweise vom Groupware-System Ihres invis-Server genutzt. Sie können hiermit neue Datenbanken anlegen, sollten aber keine vorhandenen Löschen. Sie können phpMyAdmin auch zur Erstellung von Datensicherungen der Datenbanken nutzen.
  • PostgreSQL Administration: Administration der Datenbank-Engine PostgreSQL. PostgreSQL wird beispielsweise vom Warenwirtschaftssystem Ihres invis-Server genutzt. Sie können hiermit neue Datenbanken anlegen, sollten aber keine vorhandenen Löschen. Sie können phpPGAdmin auch zur Erstellung von Datensicherungen der Datenbanken nutzen.
  • Server Administration: Hinter diesem Link steht das Programm Shell-in-a-box, mit dem Sie aus dem Browser heraus auf die Kommandozeile Ihres Servers zugreifen können. Dabei ist zu beachten, dass Shell-in-a-box keine direkten Zugriffe als Benutzer „root“ zulässt (su - verwenden) und, dass es ein denkbar schlechte Idee ist in einer solchen Shell-Sitzung den Apache-Webserver zu stoppen.
  • Druckerverwaltung: Ihr invis-Server ist in der Lage im Netzwerk vorhandene Drucker zentral zu verwalten und freizugeben. Hierüber erhalten Sie Zugriff auf die Administrationsseiten des zugehörigen Dienstes CUPS.
  • Netzwerkanalyse: Das Programm ntop dient der Analyse des Datenverkehrs in Ihrem Netzwerk, nützlich etwa bei der Suche nach Fehlern. ntop ist im Normalbetrieb Ihres invis-Servers deaktiviert, da es diesen ansonsten unnötig belastet.
  • Firewall-Test: Dieser Link führt Sie auf die Internetseite von hackerswatch.org. Sie haben von dort umfangreiche Möglichkeiten die Firewall Ihres invis-Servers von außen zu testen.

Eine weitere Funktion des Portals ist die Verwaltung externer Mailkonten von denen der invis-Server die Emails der Benutzer abruft. Diese Funktion verlangt allerdings keine administrativen Rechte, sondern kann von jedem Benutzer selbst genutzt werden. Sie wird weiter unten auf dieser Seite gesondert beschrieben.

Anpassung des Portals

Für die Konfiguration des invis-Portals sind zwei Dinge von Bedeutung:

  1. Die Datei /etc/invis/portal/config.php (siehe unten)
  2. Der Knoten ou=informationen,ou=iportal im LDAP-Verzeichnis des Classic-Servers
  3. Der Knoten cn=informationen,cn=iportal,cn=invis-server im LDAP-Verzeichnis des AD-Servers

Die genannte Konfigurationsdatei dient der grundsätzlichen Anpassung des Portals an die lokale Umgebung. Hier muss im laufenden Betrieb in der Regel nichts geändert werden, außer evtl.:

  • Die Passwortlaufzeiten der Benutzer und
  • ob eine an den invis server angepasste Datensicherungslösung (udevrdbu oder udevsync) überwacht werden soll.

Für letzteres kann auf der Zyklus der Datensicherungen vorgegeben werden. Das Portal warnt dann, wenn die Datensicherung überfällig ist. Die Konfigurationsdatei ist gut dokumentiert und weitestgehend selbsterklärend.

Interessant sind die Möglichkeiten das Portal via LDAP zu steuern. Für nahezu jeden Link (bzw. jede Schaltfläche) im Portal existiert ein eigener Knoten im LDAP. Über diese Knoten können die Links aktiviert bzw. deaktiviert werden:

  • iPortEntryActive – [TRUE/FALSE]

Es lassen sich alle Links anpassen oder neue hinzufügen. Die Attribute im Einzelnen:

  • iPortEntryButton – Beschriftung des Links bzw. der Schaltfläche.
  • iPortEntryDescription – zugehöriger Beschreibungstext.
  • iPortEntryName – Name des Eintrag, kennzeichnendes Attribut des LDAP-Knotens (RDN).
  • iPortEntryPosition – Position des Links bzw. der Scaltfläche. [Lokal/Internet/Dokumentation/Administration]
  • iPortEntryPriv – Entscheidet, welche Benutzerrechte für die Sichtbarkeit des Eintrages Voraussetzung sind. [admin/user/guest]
    • admin – Setzt die Mitgliedschaft eines Benutzers in der Gruppe „Domain Users“ voraus.
    • user – Setzt eine erfolgreiche Anmeldung am Portal voraus.
    • guest – Wird jedem gezeigt, vorausgesetzt er greift aus dem lokalen Netz heraus auf das Portal zu
  • iPortEntrySSL – Legt fest, ob der Link TLS-Verschlüsselung erfordert.
  • iPortEntryURL – Legt die Zieladresse des Links fest. Dabei müssen externe Ziele vollständig aber ohne vorangestelltes „http:“ oder „https:“ angegeben werden. Interne Ziele werden wie folgt angegeben: [servername]/phpldapadmin.

Beispiel für eine LDIF Datei

# Groupware Tine 2.0
dn: cn=Tine-2.0,cn=invis-Portal,cn=Informationen,cn=invis-server,dc=invis-net,dc=loc
objectClass: top
objectClass: iPortEntry
cn: Tine-2.0
iPortEntryName: Tine-2.0
iPortEntrySSL: FALSE
iPortEntryURL: [servername]/tine20
iPortEntryDescription: Die Groupware "Tine 2.0" bietet unter anderem Zugriff auf Terminkalender, Kontakt- & Projektverwaltung, E-Mails, CRM und Zeiterfassung. 
iPortEntryActive: FALSE
iPortEntryPosition: Lokal
iPortEntryButton: Groupware
iPortEntryPriv: user

Um Einträge im Portal über die Kommandozeile zu aktivieren oder deaktivieren bringen invis-Server das Script swpestat mit:

linux:~ # swpestat entryname [TRUE|FALSE]

Um die Namen der Einträge zu ermitteln bietet das Script eine Statusabfrage an:

linux:~ # swpestat status
....

Achten Sie bei der Verwendung des Scripts auf die Korrekte Schreibweise der Eintragsnamen.

Die Konfigurationsdateien

/etc/invis/invis.conf

Dies ist die zentrale Konfigurationsdatei des invis-Servers. Sie hat derzeit noch einen recht überschaubaren Umfang. Aus Ihr beziehen die Tools der invis Toolbox ihre Vorgaben.

Sie wird während des Setups angelegt und an die Umgebung des invis Servers angepasst. Spätere Anpassungen sind kein Problem.

Alle Einträge sind in der Datei gut dokumentiert.

Bei manuellen Veränderungen an der Datei ist auf die Dateisyntax zu achten.

Beispiel:

# Wo liegt das Quarantäne-Verzeichnis?
quarDir:/var/spool/infected

Jede Zeile beginnt mit dem Namen der Konfigurationsoption gefolgt von zugehörigen Parameter. Option und Parameter sind durch einen Doppelpunkt getrennt. Vor und nach dem Doppelpunkt darf sich kein Leerzeichen befinden.

Hier noch ein paar Beispiele zu besonderen invis-Server Funktionen, die über die Konfigurationsdatei gesteuert werden können.

Bereinigung der Tranfer-Freigabe

Die Transfer-Freigabe ist eine File-Server Freigabe die vor allem dem Datenaustausch zwischen Benutzern und Gruppen ohne Veränderung von Zugriffs- und Besitzrechten dient. Es ist die „jeder darf alles“ Freigabe, und somit prädestiniert zur Betriebsmüllhalde zu mutieren.

Um dem zu begegnen können invis-Server dieses Verzeichnis selbsttätig bereinigen. Es werden alle Dateien die älter als X Tage sind werden gelöscht, resultieren daraus leere Verzeichnisse, werden auch diese gelöscht. In der Freigabe wird immer eine „Liesmich-Datei“ angelegt, die auf diesen Umstand hinweist.

Über die invis-Konfigurationsdatei kann das maximale Alter von Dateien eingestellt und die Funktion im Ganzen aktiviert oder deaktiviert werden:

# Clean Transfer Directory
# Soll das Transferverzeichnis des Fileservers regelmässig von alten Dateien befreit werden?
# [j/n]
cleanTrOn:j

# Maximales Alter der Dateien und Verzeichnisse im Transferordner
trMaxDays:42

# Pfad zum Transferordner
trDir:/srv/shares/transfer

Bereinigung der Netzwerk-Papierkörbe

In wichtigen Freigaben pflegen invis-Server einen recht nützlichen „Netzwerk-Papierkorb“. Damit auch diese nicht ins unermessliche anwachsen, gibt es für die Papierkörbe eine entsprechende Funktion wie für die Bereinigung der Tranfer-Freigabe.

Auch hier können die Zeiten über die invis-Konfigurationsdatei geteuert werden:

# Clean Recycle Directories
# Sollen die Samba-Recycle-Verzeichnisse des Fileservers regelmässig von alten Dateien befreit werden?
# [j/n]
cleanRecOn:j

# Maximales Alter der Dateien und Verzeichnisse im Transferordner
RecMaxDays:30

Interne Datensicherungen

invis-Server führen regelmäßig interne Datensicherungen des Active-Directories, der lokalen Datenbanken und des Dokuwiki Datenbestandes durch. Die Sicherungen werden jeweils als Vollsicherungen in der Archiv-Freigabe abgelegt. Dabei sammeln sich mit der Zeit nicht unwesentliche Datenmengen an. Um dem entgegen zu wirken kann der invis-Server regelmäßig alte Sicherungen im Sicherungsverzeichnis löschen. Es lassen sich über die invis-Konfigurationsdatei sowohl die Zielpfade, als auch die Aufbewahrungsdauer einstellen.

# Datensicherungen
DasiDir:/srv/shares/archiv/sicherungen
DBTarget:datenbanksicherungen
DWTarget:dokuwikisicherungen

# Soll aeltere Sicherhungen automatisch aus dem Sicherungsverzeichnis geloescht werden
cleanDasi:j
# Maximales Alter
dasiMaxDays:21

Achtung: Die interne Datensicherungsfunktion entbindet Sie NICHT von der Pflicht regelmäßige Datensicherungen Ihres Servers durchzuführen. Vor dem Gesetzt gilt eine Datensicherung nur dann als Datensicherung wenn gesicherte Daten „räumlich getrennt“ von den Originaldaten aufbewahrt werden. Dabei meint „räumlich getrennt“ mindestens einen anderen Brandabschnitt!

DDNS Funktion

DDNS oder „dynamic DNS“ ist eine Funktion mit der ein Client selbsttätig Daten eines DNS-Servers aktualisieren kann. invis-Server werden meist hinter einfachen DSL-Anschlüssen ohne feste-IP Adresse betrieben. Um einen invis-Server zuverlässig auch aus dem Internet heraus erreichen zu können, braucht er daher einen festen Namen dem automatisch die jeweils gültige IP-Adresse zugeordnet werden. DDNS ist Teil des DNS-Netzwerk-Protokolls. invis-Server können als DDNS-Client arbeiten.

Hinweis: DDNS hat in diesem Fall zwar die gleiche Funktion wie das was beispielsweise das Unternehmen „dynDNS.org“ anbietet, ist aber nicht das Gleiche. Im Falle von dynDNS.org oder deren Mitbewerber setzt der Client keinen DDNS-Call ab, sondern übermittelt die zu aktualisierenden Daten per HTTP.

Um die DDNS-Client-Funktion zu nutzen müssen Sie Zugriff auf den Primary-DNS-Server verfügen, der für die Domain verantwortlich ist, in der Sie für Ihren invis-Server einen Namen eintragen möchten.

Die DDNS-Funktion des invis-Servers setzt voraus, dass die Ziel-Domain auf dem DNS-Server für DDNS vorbereitet ist und Sie über einen DNSsec Key zur Authorisation eines DNS-Updates verfügen.

Kopieren Sie zunächst die Schlüsseldateien nach:

/etc/ssl/ddns

Jetzt können Sie die Funktion in der invis-Konfigurationsdatei aktivieren. Weiterhin müssen Sie den im Internet gültigen Namen des invis-Servers, den anzusprechenden DNS-Server und die 5-stellige Nummer des DNSsec Keys eintragen.

# DDNS-Update
# Verwenden Sie anstelle von z.B. DynDNS.org einen eigenen DNS-Server, den Sie per DDNS aktualisieren?
# [j/n]
ddnsOn:n

# Adresse des Nameservers
nameServer:ns.fspisp.de

# Hostname (FQDN) Ihres Servers im Internet
fqdn:clt.invis-server.org

# Schlüsselnummer Ihres DDNS-Keys
keyNumber:00000

Der DDNS-Abgleich wird jetzt zyklisch vom Script inetcheck durchgeführt.

Hinweis: Möchten Sie statt dessen die Dienste von dynDNS.org oder deren Mitbewerber nutzen empfehlen wir die Nutzung der entsprechenden Funktionen Ihres Routers oder die Installation des Programms „ddclient“ auf Ihrem invis-Server.

/etc/invis/invis-pws.conf

In dieser Datei werden Passwörter für den Zugriff auf das LDAP-Verzeichnis sowie die Datenbank-Systeme gespeichert. Notwendig ist dies, damit die verschiedenen Tools der invis-Toolbox ihre Arbeit erledigen können. Die Datei wird während des Setups angelegt und muss in der Regel im laufenden Betrieb nicht mehr angefasst werden. Zugriff darauf hat lediglich root.

/etc/cron.d/invis.cron

Über diese Datei werden alle für den invis Server relevanten Cronjobs gesteuert. Die Datei wird während des Setups automatisch angeleget und braucht in der Regel nicht verändert werden.

Sind Veränderungen notwendig, finden sich in der Datei zu jedem Eintrag Kommentare, die den Sinn und Zweck des jeweiligen Jobs erläutern.

/etc/invis/portal/config.php

Dies ist die zentrale Konfigurationsdatei des invis-Portals. Sie wird während des Setups automatisch an die Installationsumgebung angepasst.

Datensicherung

Wird eine Datensicherung per udevsync oder udevrdbu durchgeführt, kann das Portal an die fällige Datensicherung erinnern und über Erfolg bzw. Misserfolg informieren. Diese Funktion kann in der Datei config.php freigeschaltet und konfiguriert werden.

Dazu ist einfach die Zeile:

//$STATUS_BACKUP_TIMER = 3;

von den beiden führenden Slashes zu befreien. Die Zahl am Ende der Zeile legt das gewünschte Datensicherungsintervall in Tagen fest. Dies ist allerdings nur eine Erinnerungsfunktion, die Datensicherung müssen Sie schon selbst durchführen.

USV Überwachung

Seit invis-Server AD 10.3 können invis-Server auch mit USVs des Herstellers APC kommunizieren und wichtige Zustandsdaten im Portal anzeigen. Voraussetzung dafür ist, dass die USV „modbus“ unterstützt und „modbus“ auch aktiviert ist.

Um einen invis-Server entsprechend einzurichten muss der standardmäßig installierte apcupsd laufen und für „modbus“ konfiguriert sein. Bearbeiten Sie für diesen Zweck die Datei

/etc/apcupsd/apcupsd.conf

wie folgt:

...
UPSCABLE usb
...
UPSTYPE modbus
...

Danach können Sie in der Portal-Konfiguration die folgende Zeile von „false“ auf „true“ setzen:

// Aktivieren der APCUPS Daemon Abfrage
$STATUS_APCUPSD = true;

Nach wenigen Minuten sollten auf der Statusseite des Portals Zustandsdaten Ihrer USV angezeigt werden.

IP-Adressbereiche

Auf invis-Servern werden verschiedenen IP-Geräte Gattungen verschiedene IP-Adressbereiche innerhalb eines IP-Netzes zugewiesen. Dies hilft Geräte, wie etwa Drucker schon anhand Ihrer IP-Adresse zu erkennen. invis-Server unterscheiden folgende Geräteklassen:

  • Server
  • Drucker
  • Client PCs
  • IP Geräte

Die Bereiche werden ebenfalls in der Konfiguration des Portals vorgenommen. Ein Beispiel:

// DHCP
$DHCP_IP_BASE = '192.168.42';
$DHCP_IP_REV = '42.168.192';
$DHCP_RANGE_SERVER = array(11, 19);
$DHCP_RANGE_PRINTER = array(20, 50);
$DHCP_RANGE_IPDEV = array(60, 90);
$DHCP_RANGE_CLIENT = array(120, 199);

Seit invis-Server 11.0 können invis-Server auch mit privaten Klasse B Netzen (172.16.0.0/16 bis 172.31.0.0/16) umgehen.

Dienste

Seit invis-Server AD 10.2 ist es möglich auf dem Server laufende Dienste über die Administrationsseite des invis-Portals zu steuern. Die Dienste die dort aufgeführt werden sollen müssen in der Portal-Konfiguration aufgeführt werden:

$SERVER_SERVICES = array(
        array('amavis', 'Spamfilter'),
        array('clamd', 'Virenscanner'),
        array('cups', 'Druckserver'),
        array('dhcpd','IP Adressvergabe'),
        array('fetchmail','Emails abholen'),
        array('freshclam', 'Virenscanner Updater'),
        array('mysql', 'MariaDB Datenbank'),
        array('named','DNS Namensauflösung'),
        array('ntop', 'Netzwerkanalyse'),
        array('ntpd', 'Zeitserver'),
        array('postfix','Email-Versand'),
        array('postgresql', 'PostgreSQL Datenbank'),
        array('samba', 'Active Directory'),
        array('kopano-dagent', 'Kopano Empfang'),
        array('kopano-gateway', 'Kopano Postfach'),
        array('kopano-ical', 'Kopano Kalender'),
        array('kopano-monitor', 'Kopano Monitor'),
        array('kopano-search', 'Kopano Suche'),
        array('kopano-server', 'Kopano Server'),
        array('kopano-spooler', 'Kopano Versand'),
        array('kopano-precense', 'Kopano Anwesenheit'),
        );

Dabei muss in der ersten Spalte der genaue Name des Dienstes und in der zweiten Spalte ein „Menschen-verständlicher“ Name eingetragen werden.

Passwortsicherheit

Es ist möglich Anforderungen an die Komplexität der Benutzerpasswörter zu konfigurieren. Leider sind die derzeit noch im Portal eingebauten Anforderungen nicht kompatibel mit den Einstellungen des Microsoft Active Directory.

Gültig sind die Einstellungen nur für Passworteingaben oder Passwortänderungen die über das Portal getätigt werden.

Hier die entsprechenden Konfigurationszeilen:

$USER_PW_EXPIRE = '365';
$USER_PW_MIN_LENGTH = '8'; // 0 = Check disabled
$USER_PW_MIN_STRENGTH = '80'; // 0 = Check disabled, 100 = Max

Wartungsarbeiten

Online Updates

Sorgen Sie dafür, dass Ihr invis Server über den Maintenance-Zeitraum der zugrunde liegenden openSUSE Version immer mit den aktuellen Sicherheits-Updates versorgt wird.

invis-Server bringen seit Version invisAD 10.1 ein „Updater Script“ mit. Gedacht ist es als „fire & forget“ Updater für funktionsunkritische Sicherheitsaktualisierungen. Es werden dabei bestimmte Updates wie etwa solche installierter SQL-Dienste und auch Updates die einen Neustart erfordern ausgeklammert. Das Script kümmert sich selbsttätig um das Neustarten betroffener Dienste und die Anwendung des invis afterup Scripts. Rufen sie es einfach ohne weitere Optionen auf:

linux:~ # invis-updater

Eine vollständige Aktualisierung können Sie mit zypper durchführen:

linux:~ # zypper refresh
linux:~ # zypper up
linux:~ # afterup

Es ist weder notwendig noch ratsam ein „Distribution Upgrade“ mit zypper dup durchzuführen.

SMTP-Relay / SMTP-Auth für Postfix einrichten

invis Server sind meist via DSL mit dem Internet verbunden, verfügen also nicht über eine dauerhafte Internet-Anbindung. Das macht sie aus Sicht vieler Mailserver nicht vertrauenswürdig. Um aus dieser Situation heraus zuverlässig Emails versenden zu können, wird für den Mailversand eine Relais-Station (Relay-Server) benötigt, die uns vertraut. Dabei handelt es sich eigentlich um nichts anderes als die Konfiguration eines Postausgangsservers, so wie das auch in Mail-Clients gemacht wird.

Üblicherweise kann, von wenigen Ausnahmen abgesehen, der Postausgangsserver des eigenen Providers genutzt werden. Für die Postfix-Konfiguration werden dessen Name (FQDN), sowie Benutzernam und Passwort für die Anmeldung via SMTP-Auth benötigt.

Hinweis: Wenn T-Online der Provider ist, kann auf keinen Fall „smtpmail.t-online.de“ oder der alte „mailto.t-online.de“ verwendet werden, wenn mit einer eigenen Domain gearbeitet wird. Die beiden genannten Mailserver haben die Angewohnheit beim relayen die Absender-Adressen umzuschreiben. Da wird aus „absender@eigenedomain.tld“ dann einfach „T-Online-Nr@t-online.de“. Das wäre in vielen Fällen mehr als peinlich. Mit „smtprelay.t-online.de“ bietet T-Online einen weiteren Mailserver an, der diese miese Angewohnheit nicht hat. Wie nicht anders zu erwarten kostet dessen Nutzung allerdings Geld.

Achtung: Die folgenden Konfigurationsschritte müssen nur dann vorgenommen werden, wenn Sie Ihrem invis-Server nicht bereits während der Installation mit den entsprechenden Daten versorgt haben. Das invis-Setup-Script sine fragt nach den entsprechenden Daten und nimmt die Konfiguration automatisch vor.

Zunächst muss in der Datei „/etc/postfix/main.cf“ der zu verwendende Relay-Server nebst zu verwendetem Protokoll (SMTP: Port 25 oder Submission: Port 587) eingetragen werden. Diese Einstellung ist bereits vorbereitet. Suchen Sie in der Datei einfach nach „relayhost“:

#relayhost = $mydomain
#relayhost = [gateway.my.domain]
relayhost = [mail.example.de]:587
#relayhost = uucphost
#relayhost = [an.ip.add.ress]

Tragen Sie an dieser Stelle einfach den vollen Namen des für Sie zuständigen Postausgangsserver ein. Ist der Postausgangsserver bekannt gemacht, muss Postfix noch Zugangsdaten bekommen um sich an diesem als berechtigter Nutzer anmelden zu können. Tragen Sie dazu in der Datei „/etc/postfix/sasl_passwd“ die Zugangsdaten in folgender Form ein:

[mail.example.de]:587             benutzername:passwort

Als Zugangsdaten werden einfach Benutzername und Passwort eines beim Provider angelegten Mail-Kontos verwendet.

Sind alle Einträge vorgenommen, müssen Sie zunächst die SASL-Passwort-Datei in eine für Postfix lesbare Form umwandeln. Dabei hilft das Kommando postmap:

Kommandozeile: postmap /etc/postfix/sasl_passwd

Abschließend müssen wir Postfix noch dazu bewegen seine Konfiguration neu einzulesen:

Kommandozeile: postfix reload

Danach steht dem Mailversand über Ihren invis-Server nichts mehr im Wege. Aus Sicht Ihrer Clients ist der invis-Server der zu verwendende Postausgangsserver. Konfigurieren Sie Ihre Mailclients entsprechend. Im lokalen Netzwerk verlangt der invis-Server derzeit beim Mailversand weder Verschlüsselung noch die Authentifizierung mit Benutzernamen und Passwort.

openVPN Starten/Stoppen/Neustarten

Mit Einführung des Systemd lässt sich openVPN nicht mehr pauschal mittels „rcopenvpn“ starten/stoppen/neustarten. Statt dessen müssen jetzt mittels systemctl alle vorhandenen openVPN Konfigurationen einzeln verwaltet werden. Für die mittels sine vorbereite openVPN Verbindung sieht dies wie folgt aus:

linux:~ # systemctl {start|stop|restart} openvpn@invis-server.service

Verwaltung von Schlüsseln und Zertifikaten

Einige Dienste Ihres Servers sind aus Sicherheitsgründen auch oder ausschließlich verschlüsselt erreichbar. Darunter der LDAP-Dienst des Active-Directory, die Mailserver-Funktionen sowie die Webserver-vHosts für Portal, z-Push oder ownCloud, so diese via Internet angesprochen werden.

invis-Server verfügen dafür über eine eigene Zertifizierungsstelle (Certification Authority / CA). Mit dieser CA werden alle Zertifikate des Servers signiert. Ab invis-Server 12.1 besteht die Möglichkeit, das für den externen Zugriff auf den invis-Server notwendige Zertifikat auch via Let's Encrypt zu beziehen.

interne Zertifikatsverwaltung

Ab invisAD Version 11.0 werden alle Server- und Client-Zertifikate mittels der Software easy-rsa mit einer einzigen CA verwaltet. Damit unterscheidet sich Version 11.0 von Ihren Vorgängern, in denen zwei CAs, einmal eine für das System selbst und eine für den VPN-Dienst.

Physikalisch liegt die CA im Verzeichnis

/etc/easy-rsa/interne-domain.tld

. Zur Verwaltung aller Schlüssel und Zertifikate verfügen invis-Server über das Script inviscerts.

inviscerts verfügt über folgende Funktionen:

  • Erzeugen und Verlängern des LDAP-Server Zertifikats.
  • Erzeugen und Verlängern des Zertifikats für externen Zugriff. Es wird sowohl vom Apache-Webserver für Portal-Zugriff, z-Push und ownCloud, sowie dem openCPN-Server genutzt.
  • Erzeugen und Verlängern des Mailserver-Zertifikates.
  • Erzeugen, Sperren und Verlängern von VPN-Client-Zertifikaten.

Nebenstehend erläutert ein Ablaufdiagramm die Funktionsweise des Scripts.

Es ist dem Script im Unterschied zu seinen Vorgängern nicht mehr möglich noch gültige Zertifikate zu erneuern. Damit verstößt inviscerts nicht mehr gegen gängige Regeln der Zertifikatsverwaltung.

Die voreingestellten Lebensdauern der Server- und Client-Zertifikate beträgt 730 Tage, also 2 Jahre. Die Lebensdauer der CA selbst liegt bei 10 Jahren. Ändern lässt sich dies in:

/etc/easy-rsa/vars

Notwendig ist das aber nicht.

Die Anwendung des Scripts ist denkbar einfach:

linux:~ # inviscerts [ms|ldap|extern|vpn]

Sie benötigen in jedem Fall das Passwort der Zertifizierungsstelle. Werden mit inviscerts VPN-Client-Zertifikate erzeugt, so werden Zertifikat und privater Schlüssel in einer Passwort-geschützten PKCS-12 Datei verpackt. inviscerts fordert Sie zur Eingabe eines solchen Passwortes auf. Bedenken Sie dass eine solche Datei ungehinderten Zugang zu Ihrem Server ermöglicht, nutzen Sie also bitte sichere Passwörter.

Selbstsignierte Zertifikate, auch wenn die Signatur über eine eigene CA erfolgte, erzeugen auf Client-Seite immer eine Sicherheitswarnung. Diese Warnungen, etwa wenn sie in einem Browser auftauchen, verunsichern Anwender erfahrungsgemäß. Um Sie zu verhindern muss das Stammzertifikat der Zertifizierungsstelle in den Client integriert werden. Für diesen Zweck halten invis-Server das Zertifikat zum Download im invis-Portal (unten rechts) vor.

Unter Windows muss ein solches Stammzertifikat mit dem Zertifikatsmanager importiert werden, damit steht es allen Microsoft-Produkten zur Verfügung, nicht aber Software von Drittherstellern wie etwa Mozilla Firefox. Dieser und andere Produkte verfügen über eine eigene Zertifikatsverwaltung in die das Stammzertifikat importiert werden muss.

Weiterhin gibt das invis-Portal auf der Status-Seite auch Auskunft darüber, wie lange die vom Server genutzten Zertifikate noch gültig sind. Nichts ist ärgerlicher als überraschend abgelaufene Zertifikate, da man in einem solchen Fall Gefahr läuft viel Zeit in die Suche von Fehlern zu investieren, die gar nicht existieren.

Weitere Informationen zum Umgang mit easyRSA sind im deutschsprachigen Wiki von OpenVPN zu finden: OpenVPN Wiki

Zertifikate von Let's Encrypt (ab invis Version 12.1)

Wir unterscheiden hier generell zwischen Zertifikaten die nur innerhalb des vom invis-Server verwalteten Netzes eine Rolle spielen und solchen die beim Server Zugriff via Internet relevant sind. Lediglich für letzteres besteht die Möglichkeit mit einem Zertifikat von Let's Encrypt zu arbeiten. Für die internen Zwecke müssten Zertifikate für eine im Internet nicht gültige Fantasie-Domain generiert werden, was die Let's Encrypt Verfahrensweise schlicht nicht zulässt. Dafür ist es einfach nicht gedacht.

Hintergrund: Sinn und Zweck der Nutzung von Let's Encrypt Zertifikaten ist es natürlich beim Server-Zugriff via Internet nicht mit verunsichernden Sicherheitswarnungen bezüglich ungültiger Zertifikate belästigt zu werden. Sicherlich ist es bei einem überschaubaren Nutzerkreis möglich auf allen beteiligten Geräten zunächst das Stammzertifikat des invis-Servers zu installieren um solche Warnungen zu umgehen. Schwieriger ist das schon, wenn Links für per ownCloud geteilte Dateien an externe Dritte versendet werden. Den Empfängern solcher Links deren Unbedenklichkeit glaubhaft zu vermitteln liegt irgendwo zwischen „nicht einfach“ und „unmöglich“.

Für folgende Dienste des Servers sind die Let's Encrypt Zertifikate gedacht:

  • Zugriff auf das invis-Portal
  • Zugriff auf ownCloud
  • Nutzung von ActiveSync

Da alle drei Funktionen ausschließlich HTTPs nutzen, spielt sich die wesentliche Konfiguration im Apache Webserver ab und wird bereits beim Setup des invis-Servers vorbereitet.

In den vHost-Konfigurationen aller drei Funktionen befindet eine wie folgt aussehende Passage:

<IfDefine LETSENCRYPT>
#   You can use per vhost certificates if SNI is supported.
    SSLCertificateFile /etc/dehydrated/certs/your.ddns-name.de/cert.pem
    SSLCertificateKeyFile /etc/dehydrated/certs/your.ddns-name.de/privkey.pem
    SSLCertificateChainFile /etc/dehydrated/certs/your.ddns-name.de/chain.pem
</IfDefine>

<IfDefine OWNCERTS>
    SSLCertificateFile /etc/apache2/ssl.crt/invis-server.crt
    SSLCertificateKeyFile /etc/apache2/ssl.key/invis-server.key
</IfDefine>

Dabei handelt es sich um zwei konkurrierende Konfigurationen die jeweils über ein Apache Server Flag aktiviert werden können (ja ich weiss, man müsste das Setup noch davor schützen, dass jemand versucht beide Flags gleichzeitig zu setzen, aber wer das macht ist selbst schuld!).

Die Pfade zu den Let's Encrypt Dateien sind natürlich individuell, abhängig vom Namen des Servers, Sie werden aber automatisch angepasst.

Die Umschaltung zwischen beiden Setup funktioniert wie folgt:

invis:~ # ae2nflag -d OWNCERTS
invis:~ # a2enflag LETSENCRYPT
invis:~ # systemctl restart apache2.service

Achtung: Beim Aktivieren oder deaktivieren von Apache Server-Flags muss ein Neustart erfolgen, ein Reload genügt nicht!

Weiterhin wurde ein zusätzlicher vHost eingerichtet, der das Let's Encrypt Challenge-Verzeichnis beherbergt. Dieses Verzeichnis wird verwendet, damit sich der eigene Server als berechtigter Empfänger der Let's Encrypt Zertifikate verifiziert und umgekehrt sich der Zet's Encrypt Server sich gegenüber dem invis-Server authentifiziert.

Dieser vHost ist nach dem Setup des invis Servers bereits aktiv und so konfiguriert, dass er Anfragen auf Port 80, allerdings lediglich auf der externen Netzwerkschnittstelle entgegen nimmt. Damit die Zertifikats Übertragung und das Challenge Verfahren funktionieren muss dieser vHost unter dem gültigen DDNS-Namen des Servers via Internet erreichbar sein. Steht der invis-Server hinter einem Router, was der Standard sein dürfte ist am Router ein Portforwarding für Port 80 auf den invis-Server einzurichten.

Nach der Installation des invis-Servers ist das Flag „OWNCERTS“ aktiviert und es werden die von der eigenen CA signierten Zertifikate verwendet.

Um auf Zertifikate von Let's Encrypt umzuschalten bringt der invis-Server mit actdehydrated ein eigenes Script mit. Es schaltet automatisch mittels der zuvor genannten Server Flags die vHosts von „invis-Portal“, „ownCloud“ und „ActiveSync“ Apache auf das Let's Encrypt Setup um, legt für den DDNS-Namen einen Let's Encrypt Account an und generiert die gewünschten Zertifikate.

Das Script wird einmalig (es sei den, es geht etwas schief) ohne weitere Optionen aufgerufen:

invis:~ # actdehydrated

Danach sollte es beim externen Zugriff auf den invis-Server keine Sicherheitswarnung bezüglich ungültiger Zertifikate mehr geben.

Alles weitere wird dann per Cron-Job erledigt. Let's Encrypt Zertifikate haben nur eine Lebenszeit von 90 Tagen, der eingerichtete Cron-Job erneuert das eigene Zertifikat automaitsch.

DNS Forwarder anpassen

invis-Server arbeiten als DNS-Server für die eigene lokale Domäne und als Forward-Nameserver für die Namensauflösung im Internet. Für letzteren Zweck nutzt der auf einem invis-Serverlaufende DNS-Dienst bind seinerseits wieder Forward-Nameserver. Oft werden hierfür beispielsweise die DNS-Server des Internet-Providers oder der vorgeschaltete Router genutzt. Es kann vorkommen, beispielsweise bei einem Provider-Wechsel, dass auf andere DNS-Forwarders umgestellt werden muss.

Die Einstellungen werden in der Datei

/etc/named.conf

vorgenommen. Hier können in der folgenden Zeile bis zu drei Nameserver eingetragen werden:

...
forwarders { 8.8.8.8; 194.129.25.2; 8.8.4.4; };
...

Achten Sie darauf, dass hinter jeder IP-Adresse wie auch am Ende der Zeile ein Semikolon stehen muss.

Danach, genügt es den Nameserver zum auffrischen seiner Konfiguration zu bringen:

Mit systemd

linux:~ # systemctl reload named.service

Alt

linux:~ # /etc/init.d/named reload

Benutzer anlegen

Das Anlegen von Benutzern über die Administrationsseite des invis-Portal ist weitestgehend selbsterklärend. Ungewöhnlich ist lediglich, dass es nicht möglich ist mit der Tabualtor-Taste zwischen den Eingabefeldern zu springen. (Gerade für Tastatur-Junkies wie mich ist das immer wieder ein Ärgernis, lässt sich aber leider nicht ohne weiteres beheben.)

Wichtig für das Verständnis beim Anlegen von Benutzern ist allerdings die Unterschiede zwischen den verschiedenen Benutzertypen zu kennen:

  1. Gast – Gäste sind einfache „Windows-Benutzer“, die lediglich der Gruppe „Domain Guests“ angehören. Das berechtigt Sie zum Zugriff auf die Transfer-Freigabe. Sie können sich nicht an Linux-Computern oder auch an der Kommandozeile des Servers anmelden. Auch steht für Sie kein Mailkonto zur Verfügung.
  2. Mailkonto – Benutzer dieses Typs verfügen über Windows und Unix Attribute, können sich aber dennoch nicht an der Linux-Kommandozeile des Servers anmelden. Sie sind Mitglied der Gruppe „maildummies“ und können das Mailsystem nutzen. Wird Kopano (ehemals Zarafa) als Groupware genutzt, werden Benutzer dieses Typs mit den Attributen „zarafaAccount“ und „zarafaSharedStoreOnly“ versehen. Dadurch können Sie Emails empfangen, sich aber nicht an Kopano anmelden. Gedacht ist dies für Email-Funktionskonten wie z.B. „info@…“ usw. Diese Konten können in Kopano freigegen werden. Um in deren Namen Mails zu versenden müssen zugelassene Absender als „SendAs Benutzer“ im Benutzerkonto des Mailusers eingetragen werden. Dies ist entweder über phpLDAPAdmin oder die Microsoft Remote Server Administration Tools möglich.
  3. Windows+UNIX – Reiner Windows-Benutzer und Linux-Benutzer, ohne Zugang zum Mailsystem. Sie sind Mitglied der Gruppe „Domain Users“ haben also das Recht verschiedene Verzeichnisfreigaben des Servers zu nutzen.
  4. Windows+UNIX+Groupware – Wie oben nur ergänzt um die Möglichkeit die Groupware und das Mailsystem zu nutzen.
  5. WinAdmin+UNIX – Wie „Windows+UNIX“, allerdings Mitglied der Gruppe „Domain Admins“. Sie verfügen also auf allen Windows-PCs der Domäne über administrative Rechte.
  6. WinAdmin+UNIX+Groupware – Wie „Windows+UNIX+Groupware“ und Mitglied der Gruppe „Domain Admins“. Zusätzlich werden Benutzer dieses Typs wenn Kopano als Groupware eingesetzt wird auch als kopano Admins geführt. Sie haben also das Recht jedes Postfach zu öffnen.

Group-e aktualisieren

Hinweis: Die Weiterentwicklung von Group-e wurde im Frühjahr 2016 eingestellt. Es wird keine Aktualisierungen mehr geben.

Achtung: Beginnen Sie das Update nicht, wenn ihnen das root-Passwort für MySQL unbekannt ist!

Die Aktualisierung einer Group-e Installation auf die jeweils neueste Version ist recht einfach. Laden Sie sich zunächst die neue Version von http://sourceforge.net/projects/group-e/files/ herunter und entpacken Sie auf Ihrem Server.

Kommandozeile: tar -xjvf group-e_v1.710.tar.bz2

Im Paket sind die Unterverzeichnisse „doc“, „dump“, „dyn“, „etc“ und „www“ enthalten. Mit diesen – ausgenommen „dyn“ müssen die entsprechenden Verzeichnisse unter „/srv/www/htdocs/group-e“ ersetzt werden. Bevor Sie allerdings die neuen Verzeichnisse über die vorhandenen kopieren müssen noch ein paar Konfigurationsdateien gesichert werden.

Sichern Sie aus der bestehenden Installation die Dateien:

  • /srv/www/htdocs/group-e/etc/phplib/lib/local.inc
  • /srv/www/htdocs/group-e/www/cfg/global.inc.php
  • /srv/www/htdocs/group-e/www/cfg/ge/config.inc.php

Überschreiben Sie jetzt mit den jeweils neuen Versionen die Verzeichnisse „doc“, „dump“, „etc“ und „www“ der bestehenden Installation.

Kopieren Sie jetzt die gesicherte Datei local.inc wieder nach /srv/www/htdocs/group-e/etc/phplib/lib/local.inc. Die beiden gesicherten Konfigurationsdateien schreibe ich in der Regel nicht zurück, da auch diese bei Group-e Aktualisierungen schon erneuert wurden. Hier gilt es lediglich die an invis-Server angepassten Einträge aus den gesicherten Dateien zu übernehmen.

Aus der Datei „global.inc.php“ ist dies zunächst der Pfad zur Datei „prepend.php“. Im nachfolgenden Code-Beispiel ist der korrekte Pfad (ca. Zeile 28) eingetragen.

define('PREPEND_FILE','/srv/www/htdocs/group-e/etc/phplib/prepend.php');
$THEME='ge';
$USE_DOMAIN=false;
$CFG['SUPERADMIN']=3000;
$CFG['GROUP_ALL']=3000;
$CFG['LDAP_MIN_UID']=3000;
$CFG['LDAP_MIN_GID']=3000;

Vergleichen Sie die Einträge für „LDAP_MIN_UID“ und „LDAP_MIN_GID“ mit den entsprechenden Einträgen in der zuvor gesicherten Datei und passen Sie die neue Datei gegebenenfalls an.

Das gleiche Spiel ist für die Datei „config.inc.php“ durchzuführen. Auch hier sind die Werte für „LDAP_MIN_UID“ und „LDAP_MIN_GID“ (ab Zeile 46) mit denen der gesicherten Datei zu vergleichen und gegebenenfalls anzupassen.

if (!isset($CFG['SUPERADMIN'])) $CFG['SUPERADMIN']=3000;
if (!isset($CFG['GROUP_ALL'])) $CFG['GROUP_ALL']=3000;
if (!isset($CFG['LDAP_MIN_UID'])) $CFG['LDAP_MIN_UID']=3000;
if (!isset($CFG['LDAP_MIN_GID'])) $CFG['LDAP_MIN_GID']=3000;

Melden Sie sich jetzt mit dem Benutzer „config“ an Group-e an. Sie werden jezt dazu aufgefordert die MySQL-Datenbank von Group-e an die neue Version anzupassen. Sie benötigen dafür den Root-Zugang zu Ihrer MySQL-Installation. Geben Sie einfach den Benutzernamen root und das zugehörige Passwort (Achtung: nicht das root-Passwort des Systems!) in die entsprechenden Felder ein und klicken sie auf die zugehörige Schaltfläche.

Damit ist die Aktualisierung komplett und Sie können sich wieder normal an Group-e anmelden.

Mailkonten verwalten

Noch aus den Anfangstagen des invis-Servers stammt das Programm „CorNAz“ zur Verwaltung von Email-Konten. Zu finden ist es in der Rubrik „local“ des Portals hinter der Schaltfläche „Mailkonten“. CorNAz steht jedem Benutzer des Servers zur Verfügung, es benötigt also keinen administrativen Zugang zum invis-Portal. Ziel dahinter ist, dass Benutzer in der Lage sein sollen Ihre Mailkonten selbst zu verwalten. Dabei können jedem lokalen Benutzer beliebig viele externe Mailkonten zugeordnet werden.

Funktionen

  • externe Mailkonten einrichten oder löschen
  • Benutzer auf an- oder abwesend setzen.
  • Urlaubsbenachrichtigung einrichten oder abschalten
  • Auswahl des Mailkontos über welches die Emails eines Benutzers versendet werden sollen.

CorNAz verlangt eine gesonderte Anmeldung desjenigen lokalen Benutzers, dessen externe Mailkonten verwaltet werden sollen. Benötigt werden die Zugangsdaten des Benutzers die er auch zur Anmeldung am PC benötigt.

Hinweis: Die Anmeldung an CorNAz erfolgt gegen den auf dem invis-Server installierten IMAP-Dienst. Verfügt der Benutzer nicht über ein lokales Postfach (dies ist abhängig vom Benutzertyp) schlägt die Anmeldung fehl. Das ist gewünschtes Verhalten, da es keinen Sinn macht Emails von einem externen Server abzuholen, wenn diese nicht in einem lokalen Konto abgelegt werden können.

Nach der Anmeldung stehen die verschiedenen Funktionen über entsprechende Schaltflächen zur Verfügung.

Mailkonto anlegen

Klicken Sie auf die Schaltfläche „Konto hinzufügen“. Das Anlegen erfolgt in zwei Schritten. Im ersten Schritt können (müssen aber nicht) Sie einen Mailprovider aus einer Liste bekannter Provider auswählen und wenn gewünscht IMAP als Protokoll für den Mailabruf bevorzugen. Beides ist nicht notwendig, es kann im nächsten Schritt alles manuell angepasst werden.

Hinweis: Die Verwendung von IMAP macht hier weniger Sinn. IMAP belässt abgerufene Emails auf dem externen Server beim Provider. Da diese Konten meist in ihrer Größe begrenzt sind, besteht die Gefahr, dass ein solches Postfach irgendwann unbemerkt voll läuft. Nützlich ist dies lediglich um unabhängig vom invis-Server von „Überall“ auf eingehende Emails zugreifen zu können. Da Ihr invis-Server aber ebenfalls von „Überall“ erreichbar ist, spielt dies keine Rolle.

Klicken Sie auf Schaltfläche „Weiter zu Schritt 2“. Hier können Sie die Zugangsdaten zu Ihrem externen Postfach eingeben. Die Zuordnung zum lokalen Benutzer erfolgt automatisch, da Sie ja mit dem gewünschten Benutzer an CorNAz angemeldet sind.

Sie benötigen für diesen Schritt die Zugangsdaten zum externen Postfach. Als Protokoll für den Mail-Abruf ist die Auswahl „POP3s“ zu bevorzugen. D.h. Alle Mails werden über eine verschlüsselte Verbindung vom Provider abgerufen und nach Erhalt beim Provider gelöscht. Nach Bestätigung der Zugangsdaten zeigt CorNAz alle eingegebenen Daten inklusive Passwort zur Überprüfung noch einmal an. Achten Sie also darauf, wer Ihnen über die Schulter schaut.

Über die Verknüpfung „Hauptmenü“ gelangen Sie wieder zurück zur Funktionsübersicht.

Abschließend müssen Sie zumindest beim Erstanlegen eines externen Kontos den Benutzer als „Anwesend“ führen. Dazu einfach auf die Schaltfläche Anwesend klicken.

Mailkonto löschen

Zum Löschen eines externen Kontos müssen Sie einfach auf die Schaltfläche „Konto löschen“ klicken und dann aus der Liste der Konten des Benutzers das zu löschende Auswählen. Klicken Sie zum Löschen einfach auf die Schaltfläche „Löschen“ links neben dem zu entfernenden Konto.

Der im Screenshot gezeigte Warntext ist ernst gemeint. Es erfolgt beim Löschen keine Sicherheitsabfrage, es wird unmittelbar gelöscht.

weitere Funktionen

Grundsätzlich sind alle weiteren Funktionen von CorNAz in Ihrer Anwendung weitgehend selbsterklärend.

Hauptadresse auswählen

Verfügt ein invis-Benutzer über mehrere externe Email-Konten, muss dem invis-Server mitgeteilt werden, welche Adresse für den Versand von genutzt werden soll. Sie wählen die jeweilige Adresse einfach im Hauptmenü über die Schaltfläche „“ links neben dem gewünschten Konto aus. Diese Auswahl kann jederzeit geändert werden. Sollen statt dessen mehrere Konten gleichberechtigt genutzt werden, sollten dafür jeweils eigene invis-Server Benutzer angelegt werden. Hierfür eignet sich der Benutzertyp „Maildummy“ bzw. „Mailkonto“.

Abwesend / Anwesend

Diese Funktion schaltet den Abruf von Emails aus externen Konten eines Benutzers je nach Wunsch ein oder aus. Nützlich ist dies bei längerer Abwesenheit, wenn der invis-Server nicht via Internet erreicht werden kann. In diesem Fall können während der Abwesenheit neue Emails direkt beim Provider, so dieser eine Webmail-Anbindung anbietet eingesehen werden. Im Normalfall sollte hier also immer Anwesend aktiviert sein.

Urlaubsbeginn / Urlaubsende

Diese Funktion generiert nach Wunsch Abwesenheitsbenachrichtigungen. Sie wurde von uns in letzter Zeit allerdings etwas stiefmütterlich behandelt, da Zarafa, Group-e und auch Roundcubemail eine solche Funktion anbieten.

Filter

Ältere invis-Server verfügen noch über die Möglichkeit Server-seitige Mailfilter per Sieve zu generieren. Diese Funktion wurde nie fertiggestellt und auf neueren invis-Versionen wieder entfernt, da auch dies die meisten Mailclients wie auch Groupware-Systeme besser beherrschen.

System allgemein

In diesem Abschnitt werden Themen der Server-Administration beschrieben, die nicht direkt die invis-Server Funktionen, sondern das System allgemein betreffen und aus unserer Sicht für den Umgang mit dem invis-Server von Bedeutung sein könnten.

System-Protokolle

Mit der Einführung des systemd unter openSUSE Linux wurde auch dessen System-Protokolldienst journald eingeführt. Seit openSUSE 42.1 ersetzt dieser den alten Syslog-Dienst vollständig. Neben einigen praktischen Eigenschaften verfügt Journald aber auch über ein paar echte Ärgernisse.

Eines davon, ist seine Langsamkeit beim Umgang mit dem Systemprotokoll. Seitens openSUSE wurde die maximale Größe des Protokolls auf 4GB beschränkt. Aber auch 4GB verlangen dem Admin einiges an Geduld ab, wenn er beispielsweise vom Anfang des Protokolls direkt ans Ende springen möchte. Auch die Ausgabe der Status-Abfragen bei System-Diensten mit systemctl werden mit einem 4GB großen Protokoll unangenehm langsam.

Wir empfehlen daher das Protokoll auf einen kleineren Wert zu beschränken.

Dazu ist in der Datei

/etc/systemd/journald.conf

der folgende Wert auf eine vernünftige Größe zu ändern:

...
SystemMaxUse=1000M
...

In der Vorgabe ist diese Option auskommentiert. Auch mit einem auf 1GB reduzierten Journal wird aus dem Journald kein Rennpferd, die Wartezeiten verkürzen sich jedoch deutlich. (Schade eigentlich, von einem binären Datenformat hätte ich mehr erwartet….)

Nachdem der Wert gesetzt wurde muss der Journal-Daemon noch neu gestartet werden.

invis:~ # systemctl restart systemd-journald.service

Jeder Admin muss für sich selbst entscheiden, wie weit seine Protokolle zurückreichen sollen. Die voreingestellten 4G decken auf unserem Server einen Zeitraum von ca. 2 bis 3 Monaten ab. Das mag im einzelnen unterschiedlich sein, mehr als ein bis 2 Monate sollten aber eigentlich zur Fehlersuche nicht notwendig sein. Auch in Sachen Datenschutz macht es Sinn das Protokoll zu reduzieren, schließlich können Systemprotokolle auch Daten aus denen sich ein Personenbezug herstellen lässt enthalten. Solche Daten dürfen ohnehin nicht bzw. nur zur Fehlersuche gespeichert werden. Auch bei personenbezogenen Daten die zur Fehlersuche gespeichert wurden besteht eine Löschpflicht, ist doch schön, wenn unser Server dem selbständig nachkommt.

Das Protokoll lässt sich auch manuell verkleinern:

invis:~ # journalctl --vacuum-size=1000M

…und mit folgendem Befehl lässt sich abfragen wie viel Platz das Systemprotokoll aktuell belegt:

invis:~ # journalctl --disk-usage

QR-Code
QR-Code invis_server_wiki:administration (erstellt für aktuelle Seite)