Derzeit ist keine selbständige Registrierung möglich.

Funktionen eines invis Servers

invis Server sind „voll ausgestattete“ Server für kleine Unternehmen. Ihre Leistungen umfassen von Aufgaben zur Netzwerkorganisation via DHCP und DNS über klassische Serverdienste wie Datei und Mail-Server bis hin zu Groupware und ERP Funktionen.

Im Einzelnen:

  • Router/Gateway + Firewall.
  • Netzwerkorganisation: ISC DHCP/DNS
  • zentrale Benutzerverwaltung: Samba4 Active Directory mit RFC2307 Erweiterung (Unter Windows als SFU (Services for UNIX) bekannt)
  • Druckserver: Samba + CUPS
  • Dateiserver: Samba + NFS
  • Mailserver: Postfix + dovecot IMAP oder Kopano + amavisd-new + fetchmail + CorNAz + Mailman
  • Webserver: Apache2 + PHP usw.
  • SQL-Server: MySQL + PostgreSQL. FirebirdSQL optional
  • Faxserver: capisuite + Faxgate (Wird dank des ISDN Sterbens früher oder später entfallen)
  • VPN: openVPN
  • Groupware: Kopano 8.x (und in Vorbereitung Tine 2.0)
  • ERP Kivitendo – ab Version 8 auch waWision
  • User-Interface: invis Portal

Eine Diskussion darüber, ob die Konzentration dieser Fülle an Diensten auf nur einer einzigen Maschine sinnvoll ist, wird an dieser Stelle nicht geführt. Hier lade ich zur Nutzung unserer Mailinglisten ein.

invis Server erheben den Anspruch ihre Dienste weitestgehend unabhängig vom verwendeten Client-Betriebssystem anzubieten. Daher legen wir Wert darauf Nutzung und Administration im Browser zu ermöglichen.

Versionen und Versionsnummerierung

invis-Server gibt es in den Versionen „invis Classic“ und „invis ActiveDirectory“. Davon wird die Classic Version nicht mehr gepflegt und ist auch allenfalls noch mit reichlich Mühe unter openSUSE 13.1 (die im November 2016 endgültig ausläuft) installieren. Wir raten davon ab.

Die letzte Version des invis-Classic trug die Versionsnummer 9.2.

Ab Version 10.0 wurde der invis-Server dank Samba 4 auf ActiveDirectory anstelle von OpenLDAP umgestellt. Dies entspricht einer Aktualisierung der Windows Domänenstruktur von NTLM (Windows Server NT 4.0) auf ActiveDirectory mit Kerberos Authentifizierung (ab Windows Server 2000). Notwendig war dies, da immer mehr Business-Applikationen das Vorhandensein eines ActiveDirectories voraussetzen und neuere Windows-Versionen nur noch mit zunehmend großem Aufwand zum Beitritt in eine NTLM-Domäne zu bewegen sind.

Die Versionen 10.0 bis 10.3 basierten auf openSUSE 13.1. Mit dem Auslaufen der Evergreen Maintenance für openSUSE 13.1 im November sollten solche Installationen auf invis-Server 10.4 unter openSUSE Leap 42.1 aktualisiert werden. Wie das funktioniert ist hier im Wiki dokumentiert.

Die Versionsnummer eines invis-Servers besteht aus 3 Teilen bzw. Stellen:

„Major_Number-Minor_Number-Build-Number“

Eine Erhöhung der ersten Nummer kennzeichnet eine Veränderung des Paketes, die es inkompatibel mit dem Vorgänger macht. Das bedeutet, ein Upgrade auf ein solches Paket, erfordert immer händische Anpassungen am System. Wir werden uns Mühe geben, die notwendigen Anpassungen im Wiki zu dokumentieren. Es kann auch möglich sein, dass eine neue Major-Release eine Neuinstallation erfordert. Dies war beispielsweise beim Sprung von 9.x auf 10.x notwendig, da ein „Upgrade“ von Samba3 + openLDAP auf Samba4 ActiveDirectory die Struktur des invis-Servers grundlegend verändert hat.

Eine Erhöhung der zweiten Stelle bedeutet neue Features, die die Kompatibilität nicht brechen. Dabei kann es sein, dass diese Features auf einer bestehenden Installation händisch nachinstalliert bzw. konfiguriert werden können. Den Betrieb eines bestehenden invis-Servers sollte dies nicht stören.

Änderungen in der dritten Stelle deuten lediglich auf Bugfixes hin. Auch hier kann es sein, dass nach einem Update händische Eingriffe notwendig sind. Die Funktion eines in Betrieb befindlichen Servers wird bei einem Update nicht gestört.

Grundsätzlich werden wir (soweit es unsere Zeit erlaubt) versuchen alle erforderlichen Update bzw. Upgrade Schritte hier im Wiki zu dokumentieren. Sollte etwas fehlen, bedenken Sie bitte, dass wir alle neben der Pflege und Entwicklung des invis-Servers auch noch Jobs zu erledigen haben, die uns ernähren.

Mit Einführung von invis-Server 11.0 werden wir die Major-Versionsnummer in den Namen des invis-Setup Paketes aufnehmen. Also wird aus „invisAD-setup“ dann „invisAD-Setup-11“. Dies verhindert versehentliche Updates des Paketes bei dem ein bestehendes System beschädigt werden könnte. Um zur neuen Version zu kommen ist also immer ein Upgrade, entsprechend der Beschreibungen hier im Wiki, erforderlich.

invis Server im Netz

Vor allem hinsichtlich der Integration eines invis-Servers in bestehenden Netzwerkstrukturen kommt es immer wieder zu Missverständnissen. Sie sind definitiv nicht dazu gedacht als einfacher Fileserver ihren Dienst zu verrichten. Auch eine Beschränkung auf die Nutzung als Groupware-Server, wird der in invis Servern steckenden Arbeit nicht gerecht. Solche Einzellösugungen lassen sich ohnehin mit wenig Aufwand individuell installieren.

Internetzugang

invis Server arbeiten prinzipiell als Router/Gateway deren Firewall so ausgelegt ist, dass sie ein dahinter liegendes Netzwerk vor Zugriffen aus dem Internet schützen. D.h. es ist der invis Server, der den Zugang des gesamten Netzwerkes zum Internet regelt. Ein vorgeschalteter Router ermöglicht die Einrichtung eines „Gastnetzes“ zwischen invis-Server und dem Router, wie die Abbildung „Variante Router“ zeigt.

Achtung: Ab openSUSE Leap ist es nicht mehr möglich mittels YaST eine direkte DSL-Verbindung via PPPoE und ein einfaches DSL-Modem einzurichten. Hier ist Handarbeit notwendig. Eine entsprechende Anleitung fehlt hier im Wiki noch!

invis Server müssen mit mindestens zwei Netzwerkschnittstellen/Netzwerkkarten ausgestattet sein, von denen eine „extern“ mit dem Router und die zweite „intern“ mit dem lokalen Netz verbunden ist.

Aus Sicht der Firewall des invis Servers ist „extern“ ihrem Namen entsprechend die externe und „intern“ die interne Zone. Die Einrichtung einer DMZ ist im Normalfall nicht notwendig, aber möglich.

Ist ein Router für den Internetzugang vorhanden, bilden Router und externe Zone ein eigenständiges Netz welches als Netz für „Gäste“ genutzt werden kann. Dies ermöglicht Gästen den Zugang zum Internet, ohne auf Ressourcen des lokalen Netzes zugreifen zu können. Eine etwaig vorhandene WLAN-Funktion des Routers kann für den gleichen Zweck genutzt werden.

Achtung: Es darf keine Verbindung zwischen Router und zentralem Netzwerk-Switch geben.

Sinnvoll ist es in diesem Fall, den Router als DHCP-Server für dieses Zwischennetz zu betreiben und die Schnittstelle „extern“ des Server als DHCP-Client zu konfigurieren. Achten Sie darauf, dass Sie im Router die per DHCP an den invis-Server vergebene Adresse als feste Reservierung einrichten. Weiterhin kann es hier nicht schaden, den Routers in der Datei Forward-Nameserver zu nutzen. Die Forwarder-Addressen werden im Verlauf des Setups abgefragt und automatisch in die Konfiguration des Nameservers aufgenommen.

Achtung: Ändern Sie bitte niemals die Datei /etc/resolv.conf des invis Servers und sorgen Sie dafür, dass dies auch nicht automatisch per DHCP geschieht.

Sollen Dienste des invis-Servers auch via Internet erreichbar sein, muss ein vorhandener Router so konfiguriert werden, dass der invis Server als "exposed Host" geführt oder für jeden Dienst eine Port-Weiterleitung eingerichtet wird. Beachten Sie hierbei die auf invis Servern üblicherweise von den Standards abweichenden Ports für HTTPS und SSH.

Um einen invis Server möglichst einfach via Internet erreichbar zu machen, ist die Einrichtung eines DynDNS-Accounts empfehlenswert.

Wer einen eigenen DNS-Server im Internet betreibt, kann sich alternativ eine Subdomain einrichten und diese direkt per DDNS bei der Internet-Einwahl aktualisieren. Das auf dem Server alle 10 Minuten ausgeführte Script inetcheck kann die Adresse automatisch im zuständigen Nameserver per DDNS aktualisieren.

Achtung: Einige Router des Herstellers AVM blockieren im Standard-Setup manche ausgehenden DNS-Abfragen, was etwa Schwierigkeiten mit DDNS machen kann. Nicht bei allen Geräten kann die Konfiguration so geändert werden, dass der Betrieb eines invis-Servers nicht beeinträchtigt wird. Dieses Verhalten habe ich allerdings in den letzten Jahren nicht mehr beobachtet.

Wird im lokalen Netzwerk ein WLAN benötigt, muss dieses mit WLAN-Accesspoints realisiert werden.

Die folgenden Grafiken verdeutlichen die beiden Szenarien.


  • Variante „Modem“


  • Variante „Router“


Zugang von "Außen"

Eine Warnung vorweg:

Achtung: Manche Kabelnetzbetreiber (beispielsweise Unitymedia), die schnelle Internetanbindungen anbieten, fassen bei Privatkunden-Anschlüssen mehrere Kunden hinter einen Router in einem privaten IPv4 Netz zusammen. Ein invis-Server an einem solchen Anschluss wird niemals via Internet erreichbar sein. Wechseln Sie zu einem Business-Tarif und beantragen Sie eine feste IP-Adresse um dies zu beheben.

invis Server sind dafür ausgelegt auf verschiedenen Wegen via Internet erreichbar zu sein. Vorgesehen sind 5 unterschiedlich Zugänge:

  1. SSH – Administrativer Zugriff. Der Port des SSH-Servers wird während des Setups auf einen zufälligen hohen Port verschoben.
  2. HTTPs – Zugriff auf das invis-Portal und installierte Webapplikationen. Auch der HTTPs Port wird während des Setups auf einen zufälligen hohen Port verschoben.
  3. OpenVPN – VPN Zugang auf den Server und das dahinter liegende Netz.
  4. HTTPs – ActiveSync/z-push auf Port 443
  5. HTTPs – Zugriff auf einen eigenen Apache vHost für ownCloud. Auch hier wird der Port auf einen zufällig gewählten hohen Port verschoben.

Der Zugriff auf installierte Webapplikationen via Internet setzt den den vorherigen Zugriff auf das invis-Portal sowie die Mitgliedschaft in der Gruppe „mobilusers“ voraus. Deeplinking auf die Webapplikationen wird verhindert. Davon ausgenommen sind z-Push und ownCloud.

Im Zusammenhang mit ownCloud sollte folgender Umstand klar sein:

ownCloud muss sowohl von innen, wie auch von außen unter der gleichen URL erreichbar sein.

Als Hostname kommt entweder ein DDNS-Name oder eine feste IP-Adresse (muss vom Provider gestellt werden) in Frage. D.h. auch beim Zugriff aus dem internen Netz wird die extern gültige URL genutzt. Ansonsten wäre es nicht möglich konsistente URLs zu erzeugen über die Dritte auf freigegebene Dateien oder Ordner zugreifen können.

Dies bedeutet auch, dass es keinen Sinn macht ownCloud zu installieren, wenn weder ein DDNS-Name oder eine feste IP zur Verfügung steht, über die der Server via Internet erreichbar ist.

Ordnung im Netz

Vor der Integration eines invis Server in ein Netzwerk, sollten Sie dort für Ordnung sorgen. So ist es sinnvoll sich ein einheitliches Namensschema für alle im Netzwerk vorhandenen Geräte und Computer auszudenken und umzusetzen. Praktisch ist, wenn aus dem Namen eines Gerätes bzw. Computers Rückschlüsse auf dessen Funktion oder Standort möglich sind. Weniger sinnvoll ist es PCs nach ihren Benutzern zu benennen, PCs wechseln gelegentlich ihren Platz und Benutzer können ihr Unternehmen verlassen.

Achtung: Vorsicht ist bei der Umbenennung von PCs dann geboten, wenn darauf Dienste laufen, die fest an den Hostnamen gekoppelt sind, wie etwa Microsoft-SQL-Server. Klären Sie im Vorfeld einer Änderung, welche Auswirkung diese haben kann.

Alle im Netz vorhandenen Computer und Geräte sollten Ihre IP-Adressen unbedingt per DHCP vom invis Server erhalten, sind also für den automatischen Adressbezug zu konfigurieren. Sind die MAC-Adressen der Geräte bekannt, können Sie über das invis-Portal Adress-Reservierungen (Leases) und Einträge im DNS Server anlegen.

Benutzerverwaltung

Eines der wesentlichen Merkmale der invis Server ist die zentrale Benutzerverwaltung. Der gesamte Datenbestand der Benutzerverwaltung (wie auch der von DNS, DHCP uvw.) liegt in einem LDAP-Verzeichnis. Als LDAP-Dienst nutzen invis-Server ein Active Directory auf Basis von Samba 4.

Die Anbindung von Linux-Clients wird mittels des Dienstes sssd realisiert. Je nach eingesetzter Linux Distribution kann sssd mit Bordwerkzeugen eingerichtet oder muss von Hand konfiguriert werden. Eine Anleitung ist hier im Wiki zu finden.

Windows Clients müssen zur Integration einen Domänenbeitritt durchführen. Auch dies steht hier im Wiki beschrieben.

Achten Sie darauf, dass Sie vor einem Domänenbeitritt mit einem Windows-PC diesem seinen endgültigen Host-Namen gegeben und ihn bereits in die DHCP und DNS Konfiguration integriert haben.

Die sinnvolle Nutzung eines invis Servers setzt die Nutzung der zentralen Benutzerverwaltung voraus!

email

Grundsätzlich wird bei invis Servern davon ausgegangen, dass keine Internetverbindung via Standleitung und fester IP-Adresse vorhanden ist. Für den Mailserver bedeutet dies, dass für den email Versand jeweils eine Internet-Einwahl angestossen werden muss und der email-Empfang indirekt geschieht. emails können nicht direkt beim invis Server eingeliefert werden, sondern verbleiben zunächst in den jeweiligen Postfächern eines Mail-Providers im Internet. Sie werden dort zyklisch per fetchmail abgeholt und dann in lokale Postfächer eingeliefert.

Jeder auf einem invis Server angelegte Benutzer verfügt über eine lokales email-Konto (Postfach), dem eine Adresse nach dem Schema „username@lokale-domain.loc“ zugeordnet ist. Diese Adresse hat ausschließlich im lokalen Netzwerk Bedeutung und kann im Internet nicht verwendet werden. Diesem Mailkonto können mittels CorNAz (Eintrag „Mailkonten“ im invis-Portal) vom User selbst beliebig viele externe Mailkonten zugeordnet werden.

Alle Mail-Clients im Netzwerk (Thunderbird, Outlook usw.) kennen nur die lokale Mail-Adresse. Wird von einem Client aus eine email versendet, prüft der invis-Server, ob sich der Empfänger im lokalen Netzwerk oder im Internet befindet. Trifft letzteres zu, tauscht der invis Server automatisch die in der email verankerten lokalen Absender-Adresse gegen eine im Internet Gültige (sender address rewriting) aus.

Hat der Benutzer mehrere externe Mailkonten/email-Adressen angegeben, kann er mit unserem Mail-Konten-Verwaltungs-Tool „CorNAz“ festlegen, welches seine bevorzugte Absender-Adresse ist.

Emails an lokale Empfänger werden direkt zugestellt, hier findet kein „address rewriting“ statt.

Wird eine email an eine externe Adresse eines lokalen Benutzer gesendet, findet ein „adress rewriting“ in umgekehrter Richtung statt (recipient address rewriting). Dies führt ebenfalls zu einer direkten Zustellung solcher emails ohne Umweg über einen externen Mail Provider.

Hinweis: Die sinnvolle Nutzung der Groupware-Funktionen des Servers ist nur unter Verwendung der lokalen Mailserver-Funktion möglich!


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