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

Willkommen zum dritten Teil meiner Docker-Serie. Bitte lest unbedingt auch die vorhergehenden Teile!

Der NPM ist nun via Full-Qualified-Domain-Name und einem offiziellem SSL Zertifikat von Let’s Encrypt erreichbar. Der nächste Schritt wäre nun, auch Portainer mittels offiziellem SSL Zertifikat und über HTTPS (ohne Port 9443) erreichbar zu machen.

Portainer erhält ein zusätzliches Netzwerk

Da unser NPM sich in einem 10.0.0.x Netzwerk befindet, Portainer aber noch immer mit der Docker-Standard-IP 172.17.0.x läuft, muss unser Netzwerk (10.0.0.x — bei mir mit Namen „it-yourself“) mit Portainer verbunden werden.

Dies ist mit wenigen Klicks erledigt.

  • Einloggen in Portainer
  • Auswahl von Containers (links)
  • Danach Portainer wählen (den Container)
  • Ganz nach unten scrollen
  • Bei Connected Networks das Dropdownmenü öffnen und das selbst erstellte Netzwerk auswählen (it-networker bei mir)
  • Abschließend auf Join network klicken

Von nun an, ist der Portainer mit 2 Netzwerken verbunden. Der Standardbridge (172.17.0.x) und dem benutzerdefinierten Netzwerk (10.0.0.x).

NPM – SSL Zertifikat erstellen und Host eintragen

Wir müssen jetzt via NPM einerseits ein SSL-Zertifikat erstellen und andererseits einen Hosteintrag für portainer.it-networker.at (ihr nehmt natürlich euren Sub(domainnamen) den ihr gewählt habt).

Auch das ist in wenigen Schritten erledigt.

  • Einloggen in den NPM
  • Menü SSL Certificates
  • Add SSL Certificate -> Letsencrypt (rechts)
  • Domain im „Domain Names“ Feld angeben. (nicht Return drücken, sondern unterhalb der eingabe auf „Add <……>“ klicken
  • Email-Address for Letsencrypt eintragen
  • Den „Terms of Service“ zustimmen
  • Auf Save klicken
  • Nach rund 30 Sekunden erscheint nun auch dieses SSL Zertifikat in der Übersicht

Einen Hosteintrag erstellen

Wieder befinden wir uns im NPM-Backend.

  • Auswahl von Hosts -> Proxyhost
  • Rechts auf „Add Proxy Host“ gehen
  • Domain Names: Eure Sub(Domain) bei mir portainer.it-networker.at
  • Scheme: HTTPS
  • Forwart Hostname/IP: IP oder Containername von Portainer. Bestenfalls immer den Namen nehmen. In meinem Fall: portainer
  • Forward Port: 9443
  • Block Common Exploits
  • Reiter SSL: Auswahl des zuvor erstellten SSL Zertifikates für Portainer.
  • Force SSL
  • Save

Testlauf

Nach Eingabe von https://portainer.it-networker.at (ohne Port) gelangen wir jetzt direkt zum Portainer-Login. Wie immer müsst ihr hier natürlich eure Sub(domain) nehmen.

Absicherung und eine kurze Zusammenfassung

Von außen ist nur unser NPM auf Port 80 und 443 erreichbar. Wir prüfen das mittels den aktuellen UFW-Firewallregeln. Wichtig ist, dass alle Regeln die ALLOW FWD als Action hinterlegt haben sich ausschließlich auf den Zugriff auf die Docker-Container beziehen. Standardregeln – Action: ALLOW IN, beziehen sich auf den Host und nicht auf die Container.

Nachdem wir uns via ssh auf unseren Server eingeloggt haben, tippen wir:

ufw status verbose

Abgesehen von einer ALLOW IN Regel, die uns den Zugriff auf SSH erlaubt, sollte es hier nur 2 weitere Regeln geben.

  • 10.0.0.3 ist in dem Fall mein NPM-Container (bei euch könnte der Container eine andere IP haben)
  • ALLOW FWD = Action
  • Anywhere = From
  • Also: Erlaube den Zugriff von überall her auf Port 80 und 443 des Containers mit der IP 10.0.0.3

Mehr sollte in unseren Firewallregeln nicht enthalten sein!

Zugriffssteuerung per NPM

Der NPM erlaubt es uns, den Zugriff auf die angebotenen Services einzuschränken. Dies gelingt mit sogenannten Access-Lists, die direkt im NPM angelegt werden können.

Einschränkung

Es ist NICHT möglich, Seiten die bereits eine Benutzerauthentifizierung druchführen zusätzlich via NPM-Accesslists mit User/Passwort zu schützen.  Eine Einschränkung auf IP-Adressen ist möglich. (Funktioniert nur dann, wenn man eine statische öffentliche IP hat!)

Der Grund hierfür ist:

Having an Access Control List (ACL) with username and password requires the browser to always send this username and password in the Authorization header on each request. If your proxied app also requires authentication (like Nginx Proxy Manager itself), most likely the app will also use the Authorization header to transmit this information, as this is the standardized header meant for this kind of information. However having multiples of the same headers is not allowed in the internet standard and almost all apps do not support multiple values in the Authorization header. Hence one of the two logins will be broken. This can only be fixed by either removing one of the logins or by changing the app to use other non-standard headers for authorization.

Quelle: https://nginxproxymanager.com/faq/#do-i-have-to-use-docker

Das heißt soviel wie, dass man – sofern eine Website hat – die bereits eine Autorisierung mittels Benutzername und Passwort durchführt, nicht noch eine zweite Authorisierung mit Benutzername und Passwort (in dem Fall von NPM aus) erfolgen kann. Man hätte dann nämlich mehrfache sogenannte Authorization Headers, die bei jeder Anfrage mitgeschickt werden müssten. Dies widerspricht den Internetstandards und funktioniert somit nicht!

Sofern ihr also nicht die Möglichkeit habt, die Anfragen zu kritischen Bereichen euerer Infrastruktur zumindest auf eure statische öffentliche IP einzuschränken, wäre dies, wenn man auf Nummer sicher gehen will, eventuell per VPN zu lösen.

Zugriff auf die IP Adresse einschränken

Durch einen Klick auf das Menü Access Lists und folgend die Auswahl von „Add Access List“ kann der Zugriff auf angelegte Hosts eingeschränkt werden. Dies geschieht entweder mittels Username / Passwort (wenn möglich! siehe oben!), oder direkt via eurer öffentlichen IP. Natürlich können beide Einschränkungen auch kombiniert werden. Hier hat man dann eine Differenzierung vorzunehmen. Gemeint ist mit Differenzierung der Parameter Satify Any, im Zuge der Erstellung einer Access-List.

Wie oben ersichtlich, will ich eine IP Zugriffsliste erstellen. Der Parameter Satisfy Any ist deaktiviert. Was bedeutet das?

Angenommen, ihr würdet hier nur einen Benutzer&Passwort anlegen und die IP-Settings auf den Standardeinstellungen belassen. IP Seitig wären dann alle IPs auf „Deny“ = verweigern. Selbst wenn ihr Usernamen und Passwort korrekt angebt, könnt ihr euch deshalb nicht einloggen. (Es müssen beide Kriterien zutreffen)

Setzt man aber den Parameter Satisfy Any auf ON (Eingeschaltet), so reicht es, wenn entweder Username und Passwort angegeben werden, oder die IP Regel stimmt.

Das heißt also: Sobald die User/Passwortkombination ok ist, funktioniert der Einstieg.

Wir wollten aber eine Einschränkung auf IP-Addresse vornehmen und belassen den Schalter „satisfy any“ auf aus / off.

  • Im Reiter „Access“ fügen wir im Feld „allow“ unsere öffentliche statische IP hinzu.
  • Und klicken auf Save

Die angelegte Access-List kann dann einem Host hinzugefügt werden.

  • Im Reiter Hosts -> Proxyhost des NPM, bearbeiten wir einen bereits angelegten Host (=Drei Punkte rechts des Hosteintrages anklicken -> EDIT).
  • Gleich im ersten erscheinenden Fenster (Edit Proxy Host) ist nun unten unsere Access-Liste zu wählen. (Dropdown-Menü)

 

  • Abschließend mit „Save“ speichern

Schon ist der Zugriff auf unseren NPM-Container auf unsere IP eingeschränkt. Somit kann niemand (mit anderer IP) auf die Seiten zugreifen.

Hier  geht’s zu Teil 4…

Diskussionsforum zum Thema

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!

Kopano – Nach Aktualisierung auf Deskapp 2.0 leerer Ausdruck

Nach dem Upgrade auf die DeskApp 2.0, kann es vorkommen, dass die Druckvorschau bzw. die Ausdrucke nur eine leere Seite zum Vorschein bringen. Dieses Problem lässt sich in der Regel leicht lösen, denn es liegt zumeist an einer veralteten Version der Webapp!

Die Druckvorschau, sieht dann so aus:

 

Am Kopanoserver ist in diesem Fall bitte die Webapp in Version 3.4.24 zu installieren.

Achtung, bitte nicht vergessen, den Webserver neu zu starten 😉

Kopano Deskapp Autohide betreffend „Reminder“ funktioniert nicht korrekt

Mit der letzten WebApp Aktualisierung (3.4.24), wurde ein Fehler in der Reminderfunktion behoben. (Bei Deaktivieren von „Autohide für Erinnerungen“, wurden das Erinnerungs-Popup dennoch nach x Sekunden ausgeblendet.)

Mir ist es nun bei mehreren PCs passiert, dass dies trotz der Aktualisierung, bei der DeskApp nicht funktioniert hat.

In allen Fällen half es, das Kopano-DeskApp-Profil zu löschen, anschließend alle Daten im Ordner C:\Benutzer\<Benutzername>\AppData\Local\Kopano Deskapp zu löschen und das Profil per DeskApp dann neu anzulegen.

Ich setze aktuell die Deskapp 2.0 von Kopano ein. Dieses Verhalten ist aber auch bei Version 1.9 aufgetreten!

Infos zur Web- und DeskApp: https://forum.kopano.io/category/10/final-releases

 

Sämtliche Kopano Artikel aktualisiert und getestet

Wie manche von euch vielleicht mitbekommen haben, hatte ich vor einiger Zeit 3 Artikel zum Thema „Kopano Groupware“ geschrieben, die -dankenswerterweise- sehr viel Zuspruch gefunden haben.

Nachdem sich bei Kopano, betreffend die Konfiguration, einiges geändert hat, bin ich nun endlich sämtliche Artikel nochmals von vorne bis hinten durchgegangen und habe sie aktualsiert. (Stand 28.10.2018).

Um sicherzugehen, dass auch wirklich alles so funktioniert wie beschrieben, habe ich mit Hilfe meiner Doku einen Kopanoserver von 0 weg aufgesetzt.

Als Basis hierfür wurde Debian Stretch (Version 9) herangezogen.

Wünsche und Anregungen, aber auch Kritik ist gerne gelesen.

Zusammengefasst

Artikel 1: https://www.pc-howto.com/kopano-der-neue-stern-am-groupwarehimmel-teil-1/

Artikel 2: https://www.pc-howto.com/kopano-der-neue-stern-am-groupwarehimmel-teil-2/

Artikel 3: https://www.pc-howto.com/kopano-der-neue-stern-am-groupwarehimmel-teil-3/