Docker mit NGINX-Proxymanager, UFW, Fail2Ban, MariaDB und Nextcloud — Teil 2

Nicht benötigte Container, Volumes & Images löschen

Willkommen zum zweiten Teil meiner Docker-Serie.

Bitte lest unbedingt auch die vorhergehenden Teile!Nachdem wir unsere Dockerinstallation mittels des  „hello-world-Container“ nur getestet haben, ist nun ein für uns nun nutzloser Container vorhanden. Deshalb löschen wir selbigen. Es ist generell ratsam, nicht verwendete Container, Images, Volumes etc. zu entfernen. Nach dem Löschen des Containers, ist auch das Image von „hello-world“ zu löschen.

Installation NGINX-Proxy Manager

Der NGINX-Proxymanager (kurz NPM) wird anfragen vom externen Netzwerk (Internet) entgegen nehmen und diese dann zum jeweiligen Container weiterleiten. Für jede Weiterleitung muss ein Full-Qualified-Domain-Namen (eine Domäne, Subdomäne…) vorhanden sein.

D.h. beispielsweise, dass die Subdomain portainer.it-networker.at an Container „portainer“ bzw. dessen Container-IP weitergeleitet wird.

Ebenso wäre es möglich eine Subdomain proxy.it-networker.at zu erstellen und diese dann vie NPM an unseren NPM-Container weiterleiten zu lassen.

Widmen wir uns aber zuerst der Einrichtung.

Volumes erstellen

Wir benötigen 2 sogenannte Volumes. Ein Volume verweist auf das Dateisystem des Servers (Hosts). Selbst nach einem Neustart, oder der Neuerstellung des betroffenen Containers, bleiben die Daten auf diesem quasi „gemappten“ Dateisystem erhalten.

Es sind 2 Volumes zu erstellen:

  • Ein Datenverzeichnis für den NPM
  • Ein Datenverzeichnis für Letsencrypt (SSL Zertifikate)

Anmerkung: Der NPM macht es möglich, durch Einbindung von Let’s encrypt, kostenlose offizielle SSL Zertifikate zu erstellen.

In Portainer wählen wir links Volumes, dann oben rechts „Add Volume“ und vergeben (ganz oben) als Name „nginx_data“. Es ist völlig egal, welchen Namen ihr hier vergebt. Wichtig ist nur, dass ihr das Volume später eindeutig zuordnen könnt. (Ihr müsst wissen, welches Volume ihr hier für welchen Container vorbereitet habt 😉 ).

Alle anderen Einstellungen belassen wir auf den Vorgaben und klicken auf „Create the volume“.

Das Volume für Letsencrypt erstellen wir auf die gleiche Art und Weise. Ich wähle hierfür den Namen „letsencrypt_data“.

Container erstellen

In Portainer klicken wir links im Menü auf „Containers“ und danach oben rechts auf „Add Container“.

  • Der Name kann beliebig vergeben werden. Ich wähle „NginxPM“.
  • Als Image bitte: jc21/nginx-proxy-manager:latest eingeben.
  • Unter „Network ports configuration“ -> Manual network port pubishing auf „publish a new port“ klicken und folgende Ports erstellen. (Für jedes zusätzliche Port immer wieder auf „publish a network port“ klicken.

Sieht dann so aus:

NGINX-PM wird anfragen auf 80 und 443 annehmen. Port 81 ist das Managementport.

Advanced Container Settings

Command and Logging

Interactive & TTY wählen (=man hat dann eine Konsole für den Container, in die man sich einloggen kann).

Volumes

Im Reiter Volumes müssen wir nun unsere erstellten Volumes für den NPM zuordnen. Wir klicken also 2x auf „map additional volume„, da wir ja auch 2 Volumes zuordnen wollen.

Die Zuordnung der Volumes sollte nun so aussehen:

Network

Network wird aktuell noch auf den Standardeinstellungen belassen.

Env & Labels

Hier kann man Umgebungsvariablen (ENVironment variables) für den Container ein-/erstellen. In unserem Fall müssen wir hier aber nichts ändern oder eintragen. Dies gilt ebenso für den Reiter Labels.

Restart policy

Hier wird es wieder interessant, denn mit dieser Policy kann gesteuert werden, wie sich der Container z.B. nach einem Hostneustart verhält. Wir setzen die Policy auf „Always“.

Runtime & Resources / Capabilities

Können so belassen werden. Die Standardeinstellungen sind in dem Fall ok.

Container „deployen“

Nun ist es an der Zeit den Container auszurollen und zu starten. Dies gelingt mit einem simplen Klick auf „Deploy the container„. Läuft alles glatt, wird nun das Image heruntergeladen und der Container mit unseren Einstellungen gestartet. Landet ihr nach dem Deployment auf folgender Seite, dann hat alles wie gewünscht funktioniert.

Erreichbarkeit prüfen

An sich müsste der NGINX-PM nun auf Port 81 ansprechbar sein. Der Versuch eines Aufrufs von http://portainer.it-networker.at:81/ führt jedoch zu einem Fehler. Die Website ist nicht erreichbar.

Nach kurzer Überlegung wird klar, weshalb das so ist. Wir hatten ja im ersten Teil via ufw-Firewall den Zugriff auf Port 22 und 9443 eingeschränkt. Ein anderer Port ist ja eingehend nicht offen. Hat man eine öffentliche statische IP, kann man den Zugriff auf Port 81 des Containers (NGINX-PM) freigeben:

ufw route allow from <eure öffentliche IP> to 172.17.0.3 port 81

Jetzt klappts…

Danach könnt ihr euch bei eurem NGINX-PM einloggen. Der Standarduser ist admin@example.com, das Passwort changeme

Nach dem Login, müsst ihr eure „Admindetails“ angeben und ein neues Passwort setzen.

UFW Firewall anpassen & IP-Adresse des NGINX-PM adaptieren

Alle eingehenden Anfragen auf Port 80 oder 443 sollen ausschließlich auf den NGNIX-PM weitergeleitet werden. Es ist klar, dass unsere UFW –  Firewall angepasst werden muss. Hier kommt es jetzt aber zu einem kleinen Problem, denn Docker vergibt innerhalb des Standardnetzwerkes (172.17.0.x) die IP Adressen automatisch (DHCP). Es könnte theoretisch passieren, dass die Container bei jedem Neustart eine andere IP-Adresse bekommen.

Unsere Firwallregeln wären somit dann im schlimmsten Fall nutzlos bzw. würden zumindest ins Leere laufen.

Ein eigenes Netzwerk erstellen

Um dem entgegen zu wirken, erstellen wir uns ein eigenes Netzwerk.

  • In Portainer wählen wir auf der linken Seite „Networks“ und folgend oben rechts „Add Network“.
  • Der Name kann frei vergeben werden.
  • Driver verbleibt auf „bridge“.
  • Unter „IPV4 Network configuration“ müssen wir nun aber eine IP Adresse vergeben. Ich wähle hier „10.0.0.0/24“. Hiermit stehen uns also 254 Adressen zur Verfügung.
  • Ebenso müssen wir einen Gateway eintragen. (10.0.0.1)

Abschießend einfach noch ganz unten auf „Create the network“ klicken.

Wir haben nun also ein „eigenes Netzwerk“ mit dem Adressraum 10.0.0.1-10.0.0.254 erstellt. Aufgrund dessen können nun Container erstellt werden, die eine fixe IP bekommen. Diese IP-Adresse bleibt auch erhalten, wenn der Container neu gestartet wird.

NGINX-PM IP Anpassungen

Wir wollen, dass der NGINX-PM immer die IP Adresse 10.0.0.3 erhält. Der Container muss also angepasst werden. In Portainer wählen wir links „Containers„, danach suchen wir uns in der Liste rechts den NPM heraus, klicken ihn an und klicken oben auf „Duplicate / Edit„.

Bei den nun angezeigten Einstellungen, nach unten scrollen, bis zu „Advanced container settings“ und wählen den Reiter „Network“ aus.

Im Dropdown „Network“ wählen wir das zuvor erstellte Netzwerk bei mir „it-networker„. Weiter unten bei „IPV4 Address“ ist nun die gewünschte IP – bei mir 10.0.0.3 – einzugeben.

Letztlich „deployen“ wir den Container nochmals per Klick auf „Deploy the containter„. Die Nachfrage „Are you sure?“ quittieren wir mit „Replace„.

Unser NPM hat nun die IP 10.0.0.3

Achtung: Ufw-Firwall

Nachdem sich die IP unseres NGINX-PM geändert hat, muss nun ufw wieder angepasst werden!

Mittels ufw status numbered lassen wir uns die geltenden Regeln anzeigen.

Die „alte Regel“ -unten Nr 3- für den NPM (NGINX Proxymanager) kann gelöscht werden.

ufw delete 3

…und entsprechend bestätigen.

Um  weiterhin Zugriff auf den NPM zu haben, muss eine neue Regel erstellt werden:

ufw route allow from <eure öffentliche IP> to 10.0.0.3 port 81

Jetzt ist der NPM wieder für euch erreichbar! (Port 81)

Dies sollte nur eine kurzfristige Lösung sein! Vor  allem dann, wenn ihr keine statische öffentliche IP habt. Spätestens, sobald der NPM via Subdomain und HTTPS erreichbar ist, ist die oben angeführte Firewallregel zu löschen, denn die Verbindung ist nicht verschlüsselt!

Eigene Subdomain für NPM

Das, was wir oben bezüglich des Netzwerkes durchexerziert haben, war einerseits nötig, diente aber auch Verständnis. Es ist jetzt an der Zeit, den NPM über eine Subdomain anzusprechen. Natürlich via SSL!

Ich habe deshalb eine neue Subdomain im DNS meines Providers angelegt. Diese lautet proxy.it-networker.at

Zusätzliche Regeln mit ufw erstellen

Jeder soll von extern auf Port 80 und 443 unseres NGINX-PM Container (der intern auf IP 10.0.0.3 läuft) zugreifen können. Die Aktion ist auch nötig, damit wir uns via Letsencrypt ein valides SSL Zertifikat für die Subdomain proxy.it-yourself.at holen können!

 ufw route allow from any proto tcp to 10.0.0.3 port 80

ufw route allow from any proto tcp to 10.0.0.3 port 443

Die  weitere Einrichtung erfolgt nun im Adminbackend des NPM (Port 81/http mit dem FQDN)

  1. Einloggen in den NPM
  2. Auswahl des Reiters SSL Certificates
  3. Klick (oben rechts) auf Add SSL Certificates -> Letsencrypt
  4. Bei „Domain Names“ tragt ihr bitte eure Subdomain ein, die ihr für den NPM vorgesehen habt. Achtung wenn ihr den FQDN im Feld eingegeben habt, nicht Return drücken, sondern gleich unterhalb auf „Add <euer FQDN>“ klicken.
  5. Unten „I Agree……….“ wählen
  6. Auf Save klicken

Der Test „Test Server Reachability“ ist nicht immer erfolgreich. Ich führe ihn deshalb nicht jedesmal durch. Egal, ob der Test erfolgreich ist, oder nicht. Nach dem Klick auf Save, dauert es meist rund 30 – 40 Sekunden und ihr habt euer Zertifikat.

Regel im NPM für proxy.it-networker.at erstellen

  • Oben klick auf Hosts -> Proxyhosts
  • Mittig (grüner Button) -> Add Proxy Host
  • Domain Names: proxy.it-networker.at (nach Eingabe wieder auf das Add… unten klicken)
  • Scheme: http
  • Forward Hostname / IP: Name des Containers: NginxPM / oder IP
  • Forward Port: 81
  • Block common exploits
  • Reiter SSL: Das zuvor erstellte SSL Zertifikat auswählen
  • Force SSL
  • HTTP/2 Support
  • Save

Gebt ihr nun https://<eure Subdomain> ein -> in meinem Fall https://proxy.it-networker.at gelangt ihr HTTPS-Verschlüsselt direkt zum Login euers NPM.

Zugriffssteuerung / Absicherung

Es ist jetzt an der Zeit, die Firewallregel, die einen direkten Zugriff auf Port 81 (des NPM) erlaubt, zu löschen. Mittlerweile wisst ihr schon, wie das geht.

ufw status numbered

Danach die betreffende Regel sichten und per Nummer davor in der Eckigen klammer löschen.

ufw delete 2

Natürlich kann es sein, dass die betroffene Regel bei euch eine andere Nummer hat!

Weiter zu Teil 3

Diskussionsforum zum Thema

Docker mit NGINX-Proxymanager, UFW, Fail2Ban, MariaDB und Nextcloud — Teil 1

Willkommen zum ersten Teil meiner Docker-Serie. Ich versuche in diesem mehrteiligen Tutorial darzustellen, wie man Docker auf einem VServer verwenden kann. Wenn ihr so etwas vor habt, müsst ihr euch dessen bewusst sein, dass dieser Server 24/7 im Internet steht. Der Server muss also laufend aktualisiert und auch überwacht werden. Dies gilt für den Host selbst, aber natürlich auch für die Dockercontainer! Wo immer möglich, solltet ihr Zugriffe einschränken, auf IPtables (ufw) zurückgreifen und ein Monitoring und Update-tool installieren.

 💡 WICHTIG: Das hier ist KEINE Docker-Rootless-Installation! D.h. die Prozesse innerhalb der Dockercontainer laufen mit dem User root. Selbst wenn man Container mit einem Standarduser ausrollt, heißt es nicht, dass somit alle anderen Prozesse (der Container) „rootless“ laufen.

Ich habe den Zugriff auf die Dienste, die vom Internet aus zugreifbar sind, auf meine 2 statischen öffentlichen IPs eingeschränkt. Sofern ihr aus Sicherheitsgründen Docker ohne Root verwenden wollt, gibt es hier eine ganz gute Anleitung (allerdings auf englischer Sprache). Ich werde mich dem Thema später zuwenden, jedoch nicht innerhalb dieser Artikelserie.

Zielsetzung

  • Auf einem Server, der im Internet steht, oder aus dem Internet erreichbar ist, wird -basierend auf Ubuntu Server – Docker installiert.
  • Es ist bereits ein Full-Qualified-Domain-Name (eine Domain) registriert, die auf den Dockerhost zeigt. In meinem Fall ist das portainer.it-networker.at
  • Als Verwaltungstool kommt Portainer zum Einsatz.
  • Zum Schutz von Host und Client wird UFW eingesetzt.
  • Nachdem die gesamte Netzwerkkonnektivität von Docker via iptables gesteuert wird, wird UFW adapiert, damit die – mittels UFW- gesetzten Regeln greifen.
    ACHTUNG: Eine nicht-adaptierte Konfiguration von UFW hat zur Folge, dass -sofern man Containerports „exposed“ = nach außen öffnet- jeder von überall aus  darauf Zugriff hat! (Mehr dazu unten in der Anleitung)
  • Es wird NGINX-Proxy-Manager installiert, der die Verbindungen von außen zu den angebotenen Webseiten / Services „verwaltet“.
  • Über den NGINX-Proxy-Manager werden via Letsencrypt SSL Zertifikate zur Verfügung gestellt.
  • Fail2Ban (im Dockercontainer) sorgt für die zusätzliche Absicherung von Host und Container.

Weiterlesen

Weshalb es Opensource-Software im Firmenumfeld schwer haben kann

Bei meinen Projekten lege ich verstärkt Augenmerk darauf, dass -sofern möglich- Opensourcesoftware (im Folgenden OSS) eingesetzt wird. Gerade wenn es um Serversoftware geht, ist OSS gut und stark vertreten. Abgesehen davon spricht absolut nichts dagegen, die Dienste auch gleich selbst zu hosten.

Warum? Ein paar wichtige Aspekte:

  • Nichts verschwindet in ominösen, aufgeblähten Cloudinfrastrukturen.
  • Man weiß, was mit den Daten passiert.
  • Durch das „Selfhosting“ hat man volle Kontrolle über den Server, ohne dass „Big Player“ a la Microsoft, Google und Konsorten Zugriff auf die Dienste (und die Daten haben).
  • Obiges wirkt sich wiederum auf den Datenschutz (DSGVO) positiv aus, wenn es korrekt umgesetzt wird.
  • Man spart Kosten und muss dennoch nicht auf Dienste verzichten, die zeitgemäß sind.
  • Größtenteils bessere -weil kurzfristigere- Updateversorgung (Security).
  • Man ist von eklatanten Sicherheitslücken der Big Player „weniger“ betroffen. Dieser Vergleich hinkt vielleicht ein wenig, da es ja auch bei OSS und „Linux“ Sicherheitslücken gibt. Ja, auch eklatante, gefährliche.  Allerdings werden derartige Lücken schneller entschärft, wie bei proprietärer Software. Denke ich an die Exchange-Sicherheitslücken der letzten Monate, bleibe ich ganz entspannt, denn ich setze kein MS Exchange ein, sondern eine Alternative.

 

Herangehensweise – ein fiktiver Exkurs

Als ITler bemüht man  sich, für ein Unternehmen die optimale Plattform entsprechend Anforderungsprofil zu finden, vergleicht diverse Anbieter, hat die DSGVO immer persistent im Hinterkopf und ja, kommt vielleicht zu dem Schluss, dass aufgrund des Tätigkeitsfeldes Opensourcealternativen für 95% aller [Online]Tätigkeiten (Videomeeting, Mail, Kontakte, Kalender, Active Sync, Cloudspeicher) ausreichen und noch dazu kostensparend sind.

Wichtig: OSS ist im Unternehmensumfeld nicht kostenlos, wenn man Wert darauf legt, dass es seitens des Herstellers auch professionellen Produktsupport gibt!

Leider ist es immer noch so, dass man als „EDV-Mensch“ oft Alleinunterhalter ist [SoHo-Bereich].

Sprich, man deckt von Projektabwicklung über User- / Hardwarebetreuung, Security, Serververwaltung, Betreuung von Fachanwendungen bis hin zu organisatorischen Tätigkeiten alles ab. Aufgrund der Priorität, die die IT heutzutage einnimmt und natürlich auch wegen der Komplexität der Systeme, hat der verantwortungsvolle Admin (egal ob Opensource oder nicht) zusätzlichen Support (einen Dienstleister) in der Hinterhand! Denn was ist, wenn man selbst nicht mehr weiter weiß?

Gott sei Dank gibt es heutzutage viele Firmen, die a.) OSS anbieten und b.) diese Software auch supporten! Dem war nicht immer so!

Aufbau einer OSS Kommunikationslösung

Jeder der heutzutage meint, dass Microsoft (mit Windows, Office [365], Exchange etc.) nicht zum Standard gehört, hat die letzten rund 25+ Jahre verschlafen. Hat man z.B. vor, ein bestehendes System, das auf Microsoftlösungen setzt, auf eine offene Kommunikationsplattform zu stellen (Server & Client), wird es mit Sicherheit schwierig. Die Akzeptanz der Anwender ist von immens hoher Priorität!

Stufenplan

Schritt 1: Inbetriebnahme einer OSS Kommunikationsplattform (serverseitig) unter Beibehaltung der Desktop Applikationen (Outlook).

Ziel: Der Anwender soll möglichst nichts von der Änderung mitbekommen. Der gewohnte Email-Client bleibt im Einsatz. Es erfolgt die Anbindung an das Active Directory (User-/Gruppenverwaltung).

Mögliches Problem: Um Outlook weiter verwenden zu können, wird ein Outlook-Connector auf jedem Client installiert. Dieser Connector stellt sicher, dass alle Funktionen (shared Kalender, Emails, Kontakte, Notizen etc.) wie gewohnt zur Verfügung stehen, obwohl „im Hintergrund“ kein MS Exchange Server [mehr] läuft. Nun verhält es sich hier aber ab und zu so, dass ein Outlook-Update an der Schnittstelle (=Kommunikation mit dem Connector) eine Kleinigkeit ändert, was wiederum dazu führen kann, dass aus heiterem Himmel einige Funktionen (zb. die shared Kalender) nicht mehr zur Verfügung stehen.

Der Connector muss in so einem Fall vom Anbieter angepasst (aktualisiert) werden. Danach muss der Admin diesen Connector wieder ausrollen.

Dieses Spiel wiederholt sich immer wieder und stellt natürlich (abgesehen vom Unmut der Anwender) einen Aufwand für den Admin da. Irgendwann könnte der Connector eingestellt werden!

Schritt 2: Umstellung auf einen „native“ Client = einem „Desktop-Mailclient“ der mit der OSS-Lösung / ersetzen von MS Outlook.

Ja, den Anwendern wird MS Outlook „weg genommen“. Klingt einfach… ist es aber nicht… 😉

Ein derartiger Schritt muss sehr behutsam erfolgen. Die Anwender sind bereits vor dem Austausch entsprechend zu Schulen und an die Hand zu nehmen. Letztlich gelingt aber auch dieser Meilenstein, wenn man genug Überzeugungsarbeit geleistet hat (und viel Geduld mitbringt). Der Outlook Connector ist -so wie die Synchronisierungsprobleme mit Outlook – somit Geschichte!

Schritt 3: Einbindung der Mobilgeräte (z.B. via Activesync — zpush)

Damit auch „mobile Endgeräte“ mitreden dürfen, wird ein zusätzlicher Dienst (z.b. ActiveSync) in Betrieb genommen.

Das System läuft

Im Laufe der Zeit -über Jahre hinweg- (und ich kann hier nur für mich sprechen), lernt man die Plattform immer mehr zu schätzen.

  • Das System läuft stabil
  • Die Probleme halten sich extrem in Grenzen
  • Keine Ausfälle durch Softwareupdates
  • Minimalistische Hardwareanforderungen (verglichen mit den Business-Produkten der Big Player)
  • Geringe laufende Kosten, verglichen mit aktuellen Standardprodukten anderer Anbieter
  • Im Worst-Case: Einen lokalen Ansprechpartner, der auch greifbar ist

Die Anforderungen steigen

  • Ein Clouddienst wäre nicht schlecht? Die Datenhoheit soll aber nicht aufgegeben werden?
  • Wie ists eigentlich mit einer Videokonferenzlösung, aber bitte ohne die Daten über X Server zu jagen, die außerhalb des eigenen Einflussbereichs liegen?
  • Aja, ein Ticketsystem steht ja auch noch auf dem Plan!
  • Eine unternehmensweite Chatplattform soll auch noch her…

Kein Problem

  • Warum nicht Nextcloud um -wie die Großen- Wolken in den digitalen Himmel malen zu können?
  • Videokonferenz… hm, wie wäre es mit BigBlueButton, oder -etwas weniger komplex- mit Jitsi Meet?
  • Die Ticketproblematik wäre u.a. mit OS-Ticket zu lösen…
  • Chatten“ könnte man ja mit Rocket-Chat

Alles machbar – natürlich mit einmaligem Aufwand verbunden. Wenn es aber läuft, dann läuft es.

High Noon

Bei all den Bemühungen, die man ggf. über Jahre in eine funktionierende OSS-Lösung gesteckt hat, kann es so gut wie immer passieren, dass plötzlich ein anderer Wunsch auf der Agenda der Entscheidungsträger steht. Dies gilt an sich für alle Softwareprodukte, die nicht der gewohnten Norm entsprechen.

Aussagen wie: „Wieso setzen wir eigentlich nicht überall Lösung X ein?“, „…können wir nicht das verwenden, was alle haben?“, „Also Software X ist schon ein Mist, weil das sieht alles anders aus, wie die damalige Software Y“, „Programm X funktioniert nicht“ (oft ein Bedienungsfehler) usw. usf. sind vermutlich vielen bekannt.

Haben sich diese Phrasen in den Köpfen manifestiert, wird es schwierig dagegen zu argumentieren – egal ob obige Aussagen aufgrund von lösbaren Problemen entstanden sind, oder andere Gründe haben. Am Beispiel von „LiMux“ z.b. hier zu lesen: derstandard.at sieht man wie verzwickt es werden kann. Gestartet wurde das Limux-Projekt (Stadtverwaltung München) im Jahr 2004, danach gab es ein hin und her (Linux installiert – „Microsoft“ weg, Linux weg – Microsoft „installiert“… Fortsetzung folgt).

Anwendersicht

Aus Anwendersicht ist die Angelegenheit (wie weiter oben schon angerissen) natürlich schwer. Vor allem dann, wenn die vermeintlich geliebte und gewohnte Standardsoftware gegen ein anderes Softwareprodukt ausgetauscht wird. Selbst wenn das neue Produkt besser ist. Es spielt hier gar keine Rolle, ob proprietär oder nicht. Essentiell ist, dass eine neue Plattform grundsätzlich anders aussieht und eine alternative Bedienung erfordert.

Täglich prasselt Werbung auf uns ein, die nur Proprietärsoftwarelösungen am Plan hat. Mir wäre noch nie Werbung untergekommen, die von „Linux“ oder OSS spricht.

Schulen

Computerunterricht – bereits schon in der Volksschule. Toll! Welche Softwareschiene wird gepredigt? (ich lasse die Antwort offen).

Welche Alternativen werden aufgezeigt? Darauf habe ich eine Antwort parat: KEINE!

Dies gilt übrigens auch für die meisten höheren Schulen!

Corona und die Digitalisierung

Im Zuge der Coronapandemie wurde allen bewusst, wie wichtig Digitalisierung ist. Die Intensivierung des notwendig gewordenen „Home-Office“ führte dazu, dass man sich mit Technologien bzgl. Videokonferenzen, Online-Meetings usw. auseinander setzen musste. Viele hatten bis zu diesem Zeitpunkt mit dem Thema „Videokonferenzen und Onlinemeetings“ nichts am Hut. Es fehlte die Infrastruktur. Natürlich sprangen die großen Anbieter auf diesen Zug auf. Es gab ein Zeitfenster, in dem z.B. MS Teams selbst Firmen kostenlos zur Verfügung gestellt worden ist.

Durchaus sinnvoll und ein Entgegenkommen von Microsoft.

Wenn man das nun weiter denkt (Angenommen, es ist noch kein Office 365 Abo vorhanden):

  • MS Teams ist corona-bedingt im Einsatz (man muss sich aufgrund der Situation damit täglich auseinander setzen, lernt es kennen und schätzen).
  • Optimale Kompatibilität mit der MS Office Schiene ist aber nur gegeben, wenn man ein komplettes MS Office (Abo) (Word, Excel, Powerpoint…) verwendet – inkl. Microsoft Exchange.
  • Letztlich kann man dann im Sinne der Produktivität (und vor allem Kompatibilität) gleich auf den Office 365 Zug aufspringen, wenn es mit dem vorhandenen Budget machbar ist.
  • Dies wiederum macht serverseitig sämtliche andere Produkte (Maillösung, Videokonferenzlösung, Chat-Lösung…) „inkompatibel“ und obsolet, selbst wenn alles perfekt läuft.

Fachanwendungen – Da war ja noch etwas

All das oben Erwähnte sehe ich als Argumente, die gegen den Einsatz von Opensource sprechen könnten. Nun gibt es aber eine Sache. Ein Killerargument – vor allem wenn man auch am Desktop PC „OSS-Office“ einsetzt.

Firmen haben oft sogenannte Fachanwendungen im Einsatz. Diese Anwendungen verwenden beispielsweise diverse Schnittstellen, um mit anderen Programmen Daten austauschen zu können. Es zählt, was Standard ist! Auf einem Desktop PC ist erwähnter Standard „Microsoft Office“.

Eine andere Plattform wird nicht unterstützt. Ich kann mich gut an eine Diskussion mit einem Entwickler erinnern. Auf die Frage hin, weshalb nicht auch z.b. Open-Office unterstützt wird, bekam ich ein Trockenes: „Ich unterstütze SICHER NICHT eine zusätzliche Plattform!“ Damit war die Diskussion auch schon beendet.

Als Firma bist du somit an die Microsoft Office Schiene gebunden. Wie man in Österreich so schön sagt: „Da fährt die Eisenbahn drüber!“

Das Eine führt zum Anderen

Bevor von allen Seiten in die „Cloud“ gedrängt wurde, konnte z.B. bezgl. MS Office bedenkenlos zu Volumenlizenzen gegriffen werden, die kein Online-Abo diverser Dienste bedingt haben. Je nach Lizenzmodell, war eine Einmalinvestition zu tätigen und „Office“ war dann bis zum Supportende hin im Einsatz. Vieles lief (und läuft) noch „in-house“ — u.a. die Kommunikationsinfrastrukur – vielleicht sogar auf OSS-Basis!

Heute drängt man in die „Cloud“. Cloudabos, bezahlt nach Useranzahl und Monat sind das Topthema. Das „Rundum-sorglos-Paket“, Exchange – Online inklusive und immer aktuell.

Jetzt hat man also einerseits einen „MS-Office am Desktop Zwang“ und andererseits Office-Pakete, die vielleicht bald nur noch im Rahmen von Office 365 angeboten werden. Ach ja… man will ja auch noch MS Teams (in Office 365 inklusive) einsetzen.

Zusammengefasst

  • Cloudlösungen werden forciert
  • MS-Office-Zwang aufgrund fehlender Schnittstellen zu alternativen Officeprodukten
  • Wunsch nach Standardsoftware für Onlinemeetings: MS-Teams soll sinnvoll & produktiv eingesetzt werden
  • MS-Exchange ist Voraussetzung für die intuitive Verwendung aller Office-Applikationen (verstärkt durch das MS Teams Thema!)

Alle Fakten des gesamten Artikels zusammen genommen: Wohin führt der Weg wohl, was meint ihr?

Fazit

Ich möchte klar stellen, dass ich mit meinem Artikel weder Microsoft noch einen anderen Softwareanbieter kritisieren oder an den Pranger stellen will. Ganz im Gegenteil. Die Microsoft Office 365 Plattform ist ausgereift und in Sachen programmübergreifender Zusammenarbeit und Kompatibilität unerreicht.

Dennoch bitte ich DRINGEND darum, auch OSS eine Chance zu geben! Viele Anforderungen kann auch OSS problemlos abdecken und hilft dabei Kosten zu sparen.

Lasst euch nicht unterkriegen und unterstützt (verwendet) OSS-Lösungen wo immer möglich und sinnvoll. Bestehende Proprietär-Platzhirschen im Unternehmensumfeld vom Desktop zu verdrängen, wird ohne eigene Entwicklungsabteilung schwer bis unmöglich. Serverseitig gibt es jedoch dennoch viele Möglichkeiten, auf OSS zu bauen! Bestenfalls selbst gehostet! Das sollten eure Daten euch wert sein.

Danke fürs Lesen!

EA Sports NHL Hockey 2022 Pucks und Bugs inklusive

Als Anhänger der NHL Serie auf dem PC hatte ich mir vor ein paar Jahren extra eine PS4 gekauft. Ich verstehe noch immer nicht, weshalb EA nebst FIFA nicht auch NHL für den PC rausbringt. Die Vermutung liegt nahe, dass in unseren Breiten Eishockey wohl einen geringen Verbreitungsgrad hat. Dabei ist das Spiel selbst wirklich unterhaltsam. Nach langer Abstinenz hatte ich mich vor 2 Wochen dazu entschieden in NHL 2022 zu investieren. Ein Grund dafür war die neue Engine namens „Frostbite“ und ein paar zusätzliche Extras. Mein letztes NHL Hockey auf der PS4 war die Versoin 2018.

Nach ein paar simplen Einstellungen bezüglich Steuerung legte ich (wie immer) mit einer NHL Saison los. Als Mannschaft mussten es (mein Standard) die Pittsburgh Penguins sein.

Der Puck flitzt samt Spieler flitzen über das Feld. Die Effekte sind knackig, der Moderator etwas eintönig, aber dennoch nicht von schlechten Eltern.

Ich habe Mühe, dem Spielverlauf zu folgen. Vielleicht war es doch keine gute Idee, dass ich die Spielgeschwindigkeit (Realismus) auf eher hoch gestellt habe. Ein paar Pässe (des Gegners) später scheppert es. Ich bin 0:1 hinten. Mist!

Aufgeben gibt es nicht! Plötzlich verspüre ich das Gefühl des „Underdogs“… Ich muss das Match noch drehen!

Nach einem Breakaway, angetäuschtem Schuss und Querpass vor dem Tor hämmert mein Center (Crosby) den Puck ins Netz. Vor lauter Euphorie balle ich – vor dem Monitor sitzend – die Faust und denke mir: „yes, lets go!“

Synching…

Ich schaue mir die Wiederholung an, die automatisch abgespielt wird… Das Pittsburgh Logo erscheint… rechts oben stehst „Synching…“ und noch immer „Synching“…

Im Hintergrund nehme ich wahr, dass das Spiel bereits weiterläuft, da der Kommentator fröhlich kommentiert, wie mein Gegner das nächste Tor macht, ohne dass ich davon auch nur irgendetwas mitbekomme! WTF! Gefühlt hundert – Gamepad- Tastendrucke später gebe ich genervt auf und würge die Konsole ab.

Recherche und Schlussfolgerung

Letztlich bemühe ich die Suchmaschine meines Vertrauens und stelle fest, dass NHL Hockey 2022 einen Bug hat, der bis jetzt noch immer nicht gefixt wurde. Wie zum Teufel (sorry) kann EA ein derartiger Fehler nicht auffallen? Haben die Damen und Herren dort schonmal etwas von Qualitätskontrolle gehört? Ich habe nun also rund EUR 60 für ein Spiel ausgegeben, das ich nicht spielen kann, weil es einen massiven Bug hat.

Debian Testing doch keine stabile Gamingplattform?

Diskussionsforum zum Thema

Ich teste in letzter Zeit Vieles bezüglich „Gaming unter Linux“. Meine präferierte Plattform war hier „Debian Testing“. Grundlegend verwende ich Debian GNU Linux für viele Projekte und kenne mich damit deshalb relativ gut aus. Folgendes ist nun aber in den letzten Tagen passiert:

  • Ich habe ein dist-upgrade durchgeführt.
  • Im Zuge des Upgrades wurden viele der 32-Bit Komponenten von Lutris bzgl. Wine ausgetauscht (aktualisiert).

Nach dem Upgrade habe ich meinen PC durchgestartet und alles getestet. Letztlich stellte ich fest, dass einige der installierten Spiele nicht mehr funktioniert haben. World of Tanks lief kurz an, beendete sich jedoch von selbst. Auch einige Steam-Spiele starteten nicht mehr. Ich habe dann einige Zeit versucht, den Fehler zu finden, bin jedoch gescheitert.

Die Experimente beginnen

Einige Stunden später, ich wollte das nicht einfach hinnehmen, überlegte ich mir, was das Ziel von „Gaming unter Linux“ sein muss bzw. sein sollte:

  • Der „Gamer“ muss eine Plattform zur Verfügung gestellt bekommen, die leicht installiert werden kann.
  • Die Wartung muss relativ simpel zu bewerkstelligen sein.
  • Die Pakete sollen möglichst aktuell ein.
  • Die Distribution selbst muss unbedigt als „stable“ eingestuft werden können.

Pop OS!

In Verbindung mit der Headline „Gaming unter Linux“ liest man immer wieder von POP OS!, welches grundlegend auf Ubuntu Linux basiert. POP OS! soll DIE Gamingplattform sein. Nun gut, probieren wir es aus!

Ich verwende eine NVIDIA Grafikkarte, weshalb ich gleich das ISO-File mit dem integrierten proprietären NVIDIA-Treiber herunterlade. Die Installation selbst ist als selbsterklärend einzustufen.  Für die Installation von Steam, verwende ich die in POP-OS! integrierte Softwareveraltung. Anders als bei Linus Tech Tips (Video), zerschießt mir die Steaminstallation nicht meinen X-Server (hier wurde offenbar nachgebessert).

Nach Anmeldung und Installation einiger Spiele in Steam, stelle ich fest, dass KEINES der installierten Spiele (auch keine Linux-native-Spiele) funktionieren. Bei Klick auf Start poppt kurz ein Fenster auf und der Spielstatus springt dann wieder auf Start. Das Spiel hängt sich also gleich nach dem Start auf. In die Fehlersuche selbst, hab ich so gut wie keine Energie gesteckt. Es fanden sich zwar einige Beiträge zu dieser Problematik, die mir bei meinem Problem aber nicht weiter halfen.

Abseits der Steam-Problematik meinte Pop OS! 2-3 mal, es müsse einfrieren, oder mir zwar noch die GUI anzeigen, jedoch keine Eingaben mehr akzeptieren. Sorry, dafür habe ich keine Zeit!

Bye, bye Pop OS! In der Form kann ein Linuxneuling leider gar nichts damit anfangen und wird genervt das Handtuch werfen.

Debian Stable

Nach wie vor davon überzeugt, dass meine ursprüngliche Problematik (Debian Testing) dadurch ausgelöst wurde, dass Debian Testing durchaus auch „unstable“ sein kann, kam nun das gute Debian Stable auf die Platte. Nach der NVIDIA-Treiber-Installation bemühte ich apt, um Steam zu installieren, das nach dem Start sofort ein Update (auf die aktuellste Version von Steam) durchführte. Leider jedoch, kam ich nie zum Loginfenster. Warum? Nun, Steam stürzte kurz nach dem Start mit einem „Memory segmentation error“ ab. Nachdem ich nie Probleme mit meinem RAM hatte, schloss ich einen Hardwaredefekt aus.

Leider führte in meinem Test auch Debian Stable nicht zum gewünschten Ziel. Auch in dem Fall habe ich nicht viel Zeit damit verschwendet, den Fehler zu finden und bin zur nächsten Distribution gesprungen.

Manjaro Linux

Es war für mich kein einfacher Schritt, debianbasierten Distributionen den Rücken zu kehren. Manjaro Linux ist eine, auf Arch Linux basierende, Distribution. Mit Arch habe ich 0 Erfahrung. Manjaro soll jedoch auch für „Arch-Anfänger“ geeignet sein. Auch hier läuft die Installation sehr schnell und einfach ab. Als Basis dient -wie immer- ein ISO File. Bezüglich  GUI hat man die Qual der Wahl zwischen XFCE, GNOME und Plasma. Ich wähle Gnome als Desktopumgebung. Die NVIDIA Installation wird direkt im Zuge der Installation erledigt.

Nun ging ich daran Steam, Wine und Lutris mittels der Applikation „Software hinzufügen / entfernen“ zu installieren. Folgendes wurde ausgewählt:

  • steam-manjaro
  • steam-native
  • lutris
  • playonlinux
  • wine
  • winetricks

Mittlerweile eher skeptisch loggte ich mich in Steam ein und testete ein paar Spiele. Oh, es funktioniert alles. Sensationell! Durch den Erfolg, war ich guter Dinge, dass auch mein geliebtes World of Tanks unter Lutris wieder läuft. Ich sollte nicht enttäusch werden. Alles läuft rund.

Fazit und Schlussworte

Ich möchte hier auf keinen Fall eine Distribution schlecht reden und beziehe mich rein darauf, ob man sofort nach der Installation mit dem Gaming loslegen kann, oder auch nicht. Im Falle von POP OS! und auch Manjaro Linux bin ich absoluter Neuling. Bei meinen Tests galt die Vorgabe, dass alles (Spiele und Plattformen) sofort nach der Installation funktionieren müssen. Unbedingt zu erwähnen ist, dass es nicht DIE Distribution für Spiele gibt. Genausowenig kann man davon ausgehen, dass Spiele, die eigentlich für Windows produziert worden sind, unter „Linux“ laufen bzw. durchgängig funktionieren. Vor allem bezogen auf Windowsspiele und der fortlaufenden Weiterentwicklung von Linux(paketen), kann es zu Inkompatibilitäten kommen, die den Start von Spielen verhindern. Genaugenommen dürfte man (wenn alles soweit funktioniert) wohl kein Upgrade seiner installierten Distribution mehr durchführen, um in keine Probleme zu laufen. Dies geht insofern nicht, als dass man ja auf Sicherheitsupdates angewiesen ist und diese zeitnah installiert werden sollten. Eventuell könnte man ein Pinning von Wine, Lutris, Playonlinux etc. durchführen. (Dadurch würden die installierten Versionen nicht mehr aktualisiert werden). Es wird sich zeigen, wie weit ich mit Manjaro Linux komme.

So oder so rate ich jedem Linuxinteressierten dazu, auf Linux zu setzen und -wenn möglich- nur Spiele zu kaufen die „native“ unter Linux betrieben werden können.

Wünsche, Anregungen, Beschwerden, Tipps und positiv gemeinte Kritik gerne via Kommentarfunktion. 🙂