Internet

Kopano Deskapp Rollout per Batchdatei

von

Ich habe mir zuletzt ein paar Gedanken darüber gemacht, wie man das Rollout von Kopano vereinfachen könnte. Nachdem das Paket als MSI Datei vorliegt, kann man es per WSUS Package Publisher ausrollen. Was aber, wenn man keinen WSUS / Package Publisher hat und sich dennoch, das „herumgerenne“ sparen will?

Remoteausführung auf dem Client-PC

Grundsätzlich muss die MSI-Datei mit Administratorrechten auf einem Remote-PC ausgeführt werden.

Bei einer Neuinstallation, kann das Setup einzig mit dem MSI Zusatzparameter /quiet angestoßen werden.

Aufpassen muss man, sofern eine bestehende Kopano DeskApp Installation aktualisiert werden soll! In der Regel, hat der Benutzer die Deskapp offen. Wenn man nun ohne Parameter – per Remote – eine Installation anstößt, dann startet der PC nach Fertigstellung der Installation von selbst neu, ohne Rücksicht auf offene Programme etc zu nehmen, oder den Benutzer zu informieren.

In meiner Testumgebung wurde der Parameter (sinngemäß) „Prompt for Restart“ ignoriert, weshalb ich auf den Parameter /norestart zurückgegriffen habe.

Die Crux: Der Benutzer sollte den PC nach der Installation möglichst zeitnah neu starten.

Tool zur Remoteausführung von Programmen

Einigen vermutlich gut bekannt, ist der Befehl „psexec“, enthalten im Paket Windows Sysinternals (Entwickler Mark Russinovich). (Download hier).

Bitte downloaden und installieren, ohne geht’s nicht.

Vorgangsweise

Die Installation soll per Batchdatei auf einem PC in der Adminkonsole (in der Domäne > Ausführung als Domänenadmin) angestartet werden. Diese kopiert notwendige Setupdateien auf den Ziel-PC und startet die Installation.

Vor Start der Installationsprozedur,  soll aber geprüft werden, ob der Ziel-PC überhaupt online ist, da es ansonsten zu einer nervigen Verzögerung kommt, bis Windows „merkt“, dass der PC nicht online ist.

Die eigentlichen Installationsparameter + Verweis auf die MSI Datei sind in einer eigenen Batchdatei enthalten.

Eine separate Batchdatei (die am Admin-PC gestartet wird) schaut so aus:

@echo off
ping -n 1 -4 %1 | findstr /r /c:“[0-9] *ms“

if %errorlevel% == 0 (
cls
echo ————————————————-
echo === DEPLOYING KOPANO DESKAPP 2 ===
echo ————————————————-
echo –> Kopiere kopano.bat nach \\%1\C$
copy \\server\Daten\deploy\kopano.bat \\%1\c$
copy \\server\Daten\deploy\kopano-deskapp-2.0.31-x64.msi \\%1\c$
echo –>Starte PSEXEC und fuehre Remoteinstaller aus…
psexec \\%1 -u domäne\administrator -p <geheimespasswort> c:\kopano.bat
goto ende
) else (
goto error
)
:error
cls
echo ——————————————————-
echo Ping nicht ok! PC offline bzw. falscher PC-Name?!
echo ——————————————————-
:ende

Per Ping wird geprüft, ob der PC online ist, wenn ja (=Errorlevel ist 0), werden die darauffolgenden Befehle abgearbeitet.

Das %1 ist der „Platzhalter“ für den PC-Namen der beim Aufruf der BAT Datei als Parameter übergeben wird.

Bsp: Angenommen ihr startet obiges BAT-File mit dem Namen „kopano.bat“, dann würde der korrekte Befehlsaufruf so aussehen:

kopano.bat pc-name

Das BAT-File mit den Setupparametern von Kopano und die MSI Datei selbst, liegen in dem Fall auf einem Server und werden auf den PC kopiert, auf dem die Installation angestoßen werden soll.

Die BAT Datei, die auf den jeweiligen PC kopiert wird, sieht so aus:

c:\kopano-deskapp-2.0.31-x64.msi /quiet /norestart

Fazit

Es gibt sicher noch viel bessere Lösungen und auch in diesem Fall viel Luft nach oben. Braucht man eine kurzfristige Lösung, läuft aber auch diese Herangehensweise ganz gut. So könnte man beispielsweise die Installation direkt über ein Netzwerkshare anstarten, auf das alle Benutzer Zugriff haben etc.

 

Debian Stretch Mariadb – Rootlogin phpmyadmin funktioniert nicht mehr

von

Es ist zwar kein neuer Hut mehr, dass es mit Mariadb in Verbindung mit dem rootlogin in phpmyadmin Probleme gibt, ich möchte es an dieser Stelle aber dennoch erwähnen und eine – meiner Meinung nach gute – Lösung anbieten.

Hintergrund

Bei Mariadb (aktuell in Version 10.1.26-0+deb9u1) ist für den root-user ein unix_socket Plugin aktiv. Dieses Plugin prüft, ob man:

1.) Als Rootuser in der Konsole eingeloggt ist und
2.) den vorhandenen Mariadb-root-user.

Wenn man sich nun bei phpmyadmin als Benutzer root einloggen will, schlägt dies fehl. Klar! In dem Fall meldet man sich ja nicht per Konsole (als User root) bei der Mariadb an, sondern über das Web.

Lösungsweg

Es gäbe nun die Möglichkeit, das Plugin für den Mariadb-Benutzer root zu deaktivieren. (Davon sehe ich hier aber ab). Besser ist es, einen neuen Datenbankbenutzer anzulegen, der -so wie root- auch Vollzugriff auf alle Datenbanken hat, um letztendlich alle Datenbanken per phpmyadmin verwalten zu können.



Im Terminal des Servers  bzw. des Linuxsystems sind folgende Schritte (eingeloggt als root) durchzuführen:

mysql

grant all on *.* to neuerrootuser@localhost (RETURN)
identified by 'deinpasswort' with grant option;

Es ist nun ein weiterer Benutzer mit DB-Rootrechten angelegt worden.

Absicherung der Installation

Es ist immer eine gute Idee, den Befehl

mysql_secure_installation

auszuführen, um einige DB-Einstellungen sicherer zu gestalten. Hierbei kann (und sollte!) auch für den bereits vorhandenen DB-Benutzer „root“ ein Passwort gesetzt werden. (In der Standardkonfiguration hat dieser DB-Benutzer kein Passwort, da ja u.a. auf das unix_socket-Plugin zurückgegriffen wird).

Bestehende MariaDB-Benutzer abfragen / Plugincheck

Will man prüfen, welche User angelegt sind / für wen das oben erwähnte Plugin aktiv ist, begibt man sich abermals in ein Rootterminal und startet folgende Abfrage:

mysql

select user, plugin from mysql.user;

 

 

Bugs, Security-Super-GAUs und andere Bosheiten – „IT“ working as expected?

von

Datenklau leicht gemacht?

Bequemlichkeit und Unwissen

Wenn man sich die momentane Situation (Spectre, Meltdown, Bugs, Faktor Mensch,…) anschaut und nur ein wenig darüber nachdenkt, sollte grundsätzlich jedem klar werden, dass die Informationstechnologie NIE wirklich sicher sein kann, sobald Daten über Netzwerke ausgetauscht werden. Noch schlimmer wird es in diesem Kontext, wenn von außen (Internet) auf Geräte zugegriffen wird bzw. ein Datenaustausch über das Internet stattfindet (z.B: Surfen).

Innerhalb eines Netzwerkes ohne Außenanbindung (Internet) ist man verhältnismäßig sicher, aber…

Nehmen wir die Daten einfach mit nach Hause

Im Allgemeinen braucht es kein Netzwerk, um Datenklau zu ermöglichen. So kann innerhalb eines Betriebes auch ein Mitarbeiter Daten „absaugen“. Dies geschieht jedoch meist nicht aus einer bösartigen Absicht heraus!

Ich möchte nicht wissen, wie oft Firmendaten per USB Stick auf den heimischen PC transferiert werden, um dann auch außerhalb der Dienstzeiten an einem „Projekt“ weiterzuarbeiten.

Nebst dem Datenaustausch mit dem klassischen USB-Stick, gäbe es hier dann noch:

  • E-Mail (nach Hause)
  • diverse Online-Cloud-Services (Dropbox, Nextcloud, Onedrive…)
  • Das Smartphone als USB-Stick
  • …

Das Tolle an den Cloudservices ist, dass NIEMAND weiß, wo die Daten wirklich liegen (vielleicht irgendwo auf einer Serverfarm in den USA) bzw. was mit ihnen gemacht wird.

Passwortsicherheit – Aus Sicht des Anwenders

Anwender sehen ihr Passwort eher als lästig an. „Muss halt sein… nervt!“.

Admins, die es eigentlich gut meinen, ernten Kritik, sofern eine strikte Passwortrichtlinie zum Einsatz kommt. In diesem Zusammenhang meinen viele immer noch, dass der Zwang zur Passwortänderung binnen x Tagen zu einer Erhöhung der Sicherheit führt. Dem muss ich entschieden widersprechen!

Überspitzt formuliert wird aus dem Passwort Test1234 dann halt Test5678.

Besser ist es ein langes (12 Zeichen+) komplexeres Passwort ohne Änderungszwang zu fordern.

Viele User geben ihr Passwort an Kollegen/innen weiter, speichern Passwörter im Browser, legen sich ungeschützte Dateien an, in denen jede User-/Passwortkombination brav mitdokumentiert wird, verwenden unsichere Passwörter, weil ein sicheres Passwort zu schwer zu merken ist, …

Passwortsicherheit – Aus Sicht der Hersteller, Provider usw.

Die meisten Menschen auf dieser Erde, wollen die IT nutzen. Sie wollen sich keine Gedanken darüber machen, warum etwas funktioniert, oder wie etwas funktioniert und das ist auch ihr gutes Recht!

Beispiel „WLAN-Router Installation durch den Provider“:
Provider X stellt einen WLAN-Router zur Verfügung. Der Techniker des Providers kommt, steckt den Router an, checkt die ordnungsgemäße Funktion und geht.

Es wird weder darauf hingewiesen, dass am Router selbst noch per Standardlogin (admin, admin) eingestiegen werden kann, noch dass man bestenfalls bitte für das WLAN ein neues langes Passwort vergeben soll.

Prinzip: Hinstellen, funktioniert, tschüss – also sozusagen „fire and forget“.

Nun redet die Welt schon länger über das Internet of Things (IoT). Vernetzte Kühlschränke, Trockner, Waschmaschinen, Klorollenhalter, Zahnbürsten, Vibratoren, Türöffner, Heizungssteuerungen,…

Wozu überhaupt noch Sicherheitslücken? Der Gau ist doch auch so programmiert! Quasi: „Mit Plug&Play zum Super-GAU“

  • „Jeder“ will alles besitzen und verwenden.
  • Die Wenigsten wollen sich mit den Grundlagen auseinandersetzen um zu verstehen, worauf man achten muss.
  • „Alle“ schreien schließlich, wenn etwas passiert.

Arbeiten mit Adminrechten / Rootrechten

Man arbeitet NICHT mit Admin oder Rootrechten! Diese erhöhten Berechtigungen sind ausschließlich für die Installation / Konfiguration zu verwenden und nicht im „daily-business“.

(Ich kenne zig Systemadmins die permanent mit Adminrechten unterwegs sind – ein NO GO!)

Updates

Softwareupdates können Nebenwirkungen haben, stimmt. Dies wurde in der Vergangenheit leider viel zu oft durch MS vorgemacht. Dennoch sind sie ein notwendiges Übel.

Unter „Linux“ läuft dies meiner Erfahrung nach problemlos(er) ab. Ein Riesenvorteil gegenüber Windows ist, dass sämtliche installierten Pakete über die Paketverwaltung aktualisiert werden können. (Einfacher geht es einfach nicht mehr!)

Generell sollten Updates immer zeitnah eingespielt werden!

Meltdown und Spectre

Unterm Strich ein ziemlicher GAU, ja. In Summe jedoch nur ein weiterer Fingerzeig, dass die IT ganz einfach nicht sicher ist!

Fakt ist, dass:

  • Es die Sicherheitslücken schon Jahrzente gibt.
  • Ein Ausnutzen der Sicherheitslücke nicht protokolliert wird.
  • Intel meint, dass sich die Prozessoren „as expected“ verhalten.
  • AMD weniger betroffen ist.
  • der Anwender „übrigbleibt“, wenn etwas passiert.

Wie kann man eigentlich ausschließen, dass es in den vergangenen Jahrzehnten nicht bereits unzählige Übergriffe gegeben hat?

Hilft nur patchen, patchen und nochmals patchen…

Details: https://www.golem.de/news/updates-wie-man-spectre-und-meltdown-loswird-1801-132125.html

 

Fazit

Eine Verbesserung der Gesamtsituation kann nur dann erreicht werden, wenn möglichst flächendeckend ein gewisses Grundverständnis für die IT geschaffen wird. (Bsp: Passwörter sind nicht lästig, sondern in vielen Fällen als letzte Bastion zu sehen. Ein Kühlschrank, der von überall aus dem Internet erreichbar ist, ist nicht cool!).

Die Kommunikationskultur der Hersteller in Richtung der Verbraucher MUSS verbessert werden (Transparenz!)

Sicher war die IT noch nie!

A1 Cube statische IP Adresse APN

von

Vor kurzem habe ich mich damit beschäftigt, wie ich denn die mir zugewiesene statische IP beim A1 Internettarif „Cube S – nur Sim“ nun auch wirklich zugeordnet bekomme. Nach der problemlosen Aktivierung der Simkarte und dem Einstecken selbiger in den dafür vorgesehen Simkartenslot meines TP-LINK 4G Routers, konnte ich auch schon lossurfen.

Allerdings offenbarte mir der Router eine offizielle IP, die nicht der IP entsprach, die ich von A1 zugewiesen bekommen hatte.

Ein erster Reflex war die Kontaktaufnahme mit dem Kundendienst. Nach einigem hin und her, war der Supporter davon überzeugt, dass es an der aktivierten A1 Firewall liegen müsse.

„…ich deaktiviere die Firewall, dann starten Sie bitte den Router neu und dann passt das…“

…leider passte das dennoch nicht.

Es muss doch einen eigenen APN für statische IPs geben… Google + die korrekten Schlagworte bringen den Erfolg:

A1 Einstellungen statische IP LTE

  • APN Type: static
  • APN: fixip.a1.net
  • Username:ppp
  • Password: ppp
  • Authentication: CHAP

…und schon klappt es auch mit der statischen IP.

 

Starre Vorgaben versus Flexibilität? Exchange vs. Opensource Groupware

von

Ich habe mich in den letzten Wochen relativ intensiv mit der Groupwarelösung Kopano auseinandergesetzt. Dabei habe ich sicher bei Weitem nicht alles ausgekostet. Nun führten mich meine Gedanken im Zuge dessen wiedereinmal zur Frage, was im Grunde genommen für und gegen eine Opensourcegroupwarelösung spricht.

Andersrum gefragt: Wieso braucht man Exchange?

Aus der Hüfte geschossen, würde ich sagen: „Ich weiß es nicht… mir fällt nichts ein.“

Irgendwelche Behauptungen in den Raum zu stellen, ist natürlich immer leicht, deshalb versuche ich im Folgenden einige Aspekte zu beleuchten. Es würde mich freuen, wenn daraus eine (Kommentar)diskussion entsteht. (…sofern modsecurity gnädig ist).

MS Exchange (aktuell 2016)

Softwareanforderungen

Ohne Frage, ist Microsoft-Exchange ein rundum ausgereiftes Produkt, das Unmengen an Funktionen liefert. Es tut was es soll. Es ist ganz einfach das Standardprodukt in der Groupwarewelt.

Eingesetzt wird es innerhalb einer Active Directory Domain. Der hierfür notwendige Domänencontroller benötigt MS Windows Server  ab Version 2008. (Exchange wird nicht auf dem DC installiert!)

Es wird empfohlen, dass Exchange nur auf Mitgliedsservern installiert wird. Unterstützt wird MS Windows Server ab Version 2012. Die IIS Komponente für die Nutzung von Outlook Web Acces ist bereits inkludiert.

Dies gilt auch für die Datenbank, die für Exchange notwendig ist.

Wenn man die gesamte Funktionalität von Exchange auskosten will, muss man MS Outlook einsetzen. (Mindestens Version 2010 inkl. KB 296525).

Outlook Web Access ermöglicht die Nutzung der Groupware per Webbrowser.

Hardwareanforderungen

  • Mindestens 8 GB Ram / bei Edge-Transport mindestens 4GB Ram
  • Mindestens 30GB+ Festplattenspeicher für die Exchange-Installation

Notwendige Lizenzen / Software

Server 2016

Annahme: Physischer Server mit 2 CPUs und 8 physischen Kernen / CPU. (Entspricht der Minimallizenzierung nach Cores = 16 Cores.)

  • 1x Server Lizenz 2016
  • x-mal Benutzerzugriffslizenzen / Gerätezugriffslizenzen Server

Wird nur die Hyper-V Rolle installiert, dürfen 2 VMs mit Server 2016 auf dem Host betrieben werden.

Die Konfiguration könnte (minimal) so aussehen:

 

1x VM Server 2016 Domänencontroller
1x VM Server 2016 (Domainmember) für Exchange

Exchange 2016

  • 1x Lizenz für Exchange
  • x-mal Benutzerzugriffslizenzen / Gerätezugriffslizenzen Exchange

Kopano

Softwareanforderungen

Als Betriebssystemplattform kommt eine kostenlose Linuxdistribution zum Einsatz, die die Datenbank (MySQL, MariaDB, …)  und den Webserver (Apache) mit im Gepäck hat.

Hardwareanforderungen

Kurz und bündig mit einem Ausschnitt aus einer Grafik (Quelle: Kopano) veranschaulicht.

Notwendige Lizenzen / Software

In der Community Edition kann Kopano kostenlos eingesetzt werden.

Im  Firmenumfeld bietet es sich jedoch an, eine Subscription abzuschließen. Die Kosten richten sich hier nach der Anzahl der User und nach der Ausstattung des Kopano Paketes.

Fokussiert auf die Serverkomponenten der Groupware (Linuxserver / Kopano + Module) gibt es also keine Kosten für Einzellizenzen, Serverlizenzen, Clientzugriffslizenzen, Corelizenzen, Lizenzen zum Töten, erröten…

Zitat:

„Die Serverlizenzkosten / Cals etc. hat man im Firmenumfeld doch immer! Es sind mehrere Windows Domänencontroller und x Windows Clients im Einsatz“.

Stimmt sicher, will ich auch gar nicht abstreiten. Die Exchange Lizenzkosten spart man sich aber!

Fazit

Warum bin ich der Meinung, dass Opensource Groupware, wie zum Beispiel Kopano, ganz einfach die bessere Wahl ist? Warum muss es nicht immer gleich Exchange sein, nur weil  es ja „die Anderen auch alle so machen“ ?

  1. Keine Lizenzgebühren, nur eine Subscription (oder gratis community-edition).
  2. Keine komplizierte Lizenzpolitik
  3. Selbst hosten auf einem günstigen Rootserver möglich
  4. Nicht abhängig von MS-Server-Struktur
  5. Stand-Alone-Installation möglich
  6. Somit geringe Kostenbelastung für Unternehmen
  7. Unabhängigkeit von den „Big Playern“
  8. Komplett flexibler, modularer Aufbau
  9. Keine starren Vorgaben, man macht sich die Welt, wie sie einem gefällt!
  10. Opensource = Mehraugenprinzip = Sicherheit
  11. Annähernd freie Wahl der OS-Plattform
  12. Ersatz von Outlook@Desktop via Deskapp

Ehrlich gesagt finde ich keine Argumente, die gegen eine Groupwarelösung wie z.B. Zarafa, Kopano etc. sprechen. Es läuft und läuft und läuft und läuft…