Schlagwort: SSH

Was ein Gefuddel für Android

Nachdem mir die Raspberry PIs als auch vergleichbare Platinen im Moment einfach zu teuer sind, habe ich mich daran gemacht, ein uraltes Notebook, dass ich vor einigen Monaten mit Deepin Linux neu eingerichtet habe, für die Cordova-Entwicklung einzurichten. Das ist zwar fertig, liegt aber sowieso da rum und einen Test war es mir wert.

Im Grunde geht das Einrichten von Cordova ja auch recht einfach, wenn es nicht die elenden Fallen geben würde.
Einmal ist da im Fall von Android das Problem mit der Java-Version. So richtig geht es – falls man für Android die App erstellen will – nur mit Java 8 bzw. dem JDK 8. Das Problem habe ich schon vor gefühlten Ewigkeiten bemerkt und mir immer damit geholfen, dass ich eben Java 8 installiert habe. Neben den aktuellen Versionen. Leider ist es dann aber blöde, weil man für Gradle-Skripte (zumindest die vorgefertigten von Cordova) die Default-Version von Java auch auf eben dieses Java 8 umstellen muss. Das geht in Linux (Debian, Ubuntu, Mint und Derivate) so:

sudo update-alternatives --config java

In der Folge kann man zwischen den installierten Java-Versionen auswählen und eine davon zur Default-Version machen. Aber dann muss man dann auch noch JAVA_HOME korrekt setzen. Etwa so:

env JAVA_HOME /usr/lib/jvm/java-8-openjdk-amd64/

oder

export JAVA_HOME /usr/lib/jvm/java-8-openjdk-amd64/

Ging unter Deepin als normaler User, aber komischer Weise hat das als root nicht funktioniert bzw. die Einstellungen wurden nicht übernommen. Letztendlich habe ich viel rumgebastelt, wieder viel gelernt, bin aber wie so oft im Grunde gescheitert.
Wobei das Problem mit Java 8 ist vermutlich ein ganz anderes, als man vermutet. Denn vor einigen Monaten hatte ich eine Schulung rund um Java EE gehalten und da hatten wir bei JSF ein ähnliches Problem. Die Meldung sah so aus als wäre die Version von Java nicht passend bzw. zu alt, obwohl sie neuer als die geforderte/angezeigte Version war. Ganz wie hier bei Cordova. Aber dann ist mir aufgefallen, dass die Versionsnummern in dem Framework nur einstellig (!) evaluiert wurden. Also Java 11 oder Java 17 werden als Java 1 interpretiert. So was vermute ich mittlerweile auch bei Cordova bzw. den Gradle-Skripten. Man müsste es mal mit Java 9 testen, aber dazu habe ich im Moment keine Zeit.
Letztendlich ist aber sowieso das Hauptproblem dieses elende Android-Gefuddel. Das Android-SDK und die Android-Tools etc. habe ich nach und nach alle installiert, aber ständig kam die Meldung, dass das Zeug nicht da wäre. Genaugenommen hat das Gradle-Skript diese Meldung gebracht. Letztendlich habe ich sogar das Android Studio auf dem uralten Notebook mit Deepin installiert, dort diverse Fernzugriffservice eingerichtet und gestartet, alle möglichen SDK-Versionen nachinstalliert und sogar ein Cordova-Template im Android Studio als Plugin eingerichtet.
Resultat – das Gradle-Skript weigert sich, die Android-Ressourcen zu finden. Und selbst das Android Studio nimmt dieses Gradle-Skript und kennt sich quasi dann selbst nicht mehr.

Irgendwann hatte ich die Faxen dicke, denn so schön Deepin Linux von der Oberfläche auch ist – es hat so ein paar Macken, die ich von der administrativen Seite nicht wirklich gut finde. Und der VNC- als auch RDP-Zugriff haben darauf ums Verrecken nicht funktioniert. Nur ssh – auch mit X-Umleitung von einem anderen Linux-Rechner.
Apropos anderer Linux-Rechner – das ist mein Terra-Notebook, auf dem ich Windows 10 und Mint Linux im Dualboot betreibe. Unter Windows habe ich das Cordova (auch für Android) mit Visual Studio 2017 im Griff (und im Prinzip auch mit dem Android Studio – das macht aber keinen Spass). Die Linux-Version kann ich aber seit Monaten nicht mehr aktualisieren oder da ein Programm installieren. Die Sache hier war für mich der Anlass, dass Problem mal anzugehen. Denn egal was ich probiert habe die letzte Zeit – mit der Fehlermeldung, dass die Quellen nicht zu lesen wären, haben sämtliche Aktualisierungsversuche als auch Installationsversuche abgebrochen.
Ich bin nun auf den Lösungsansatz gestoßen, dass man die Datei mit einem geeigneten Repo füllen sollte. Etwa das:

sudo nano /etc/apt/sources.list
deb http://de.archive.ubuntu.com/ubuntu bionic main restricted

Habe ich gemacht – keine Wirkung!
Dann habe ich endlich die Meldung genauer angesehen – Linux hat nicht die Datei /etc/apt/sources.list beim Installieren/Aktualisieren ausgelesen, sondern die Datei /etc/apt/sources.list.d/vivaldi.list.
Aus irgendeinem Grund wurde der Pfad umgebogen. Wo genau, habe ich noch nicht raus, aber einfach das Repo da reingeschrieben. Und gut ist es – aktualisieren und installieren geht wieder.
Jetzt kann ich auch mal den Linux-Rechner nutzen und versuchen, da Cordova-Apps für Android zu kompilieren. Wenn das auch da nicht geht, habe ich ja immer noch Visual Studio 2017 und meinen Docker-Container.

Und so ganz unwahrscheinlich ist es nicht, dass ich darauf beschränkt bleibe. Denn bei dem Mint-Linux ist node.js und damit auch npm in einer alten Version dabei. Was nicht schlimm wäre, wenn nicht jede Art der Installation, die ich versucht habe, immer diese uralte Version 8 installiert hätte. Mit apt bzw. apt-get entfernt, neu installiert, andere Quellen genommen, verschiedene Package-Manager ausprobiert -> immer die Version 8, obwohl es schon die Version 18 gibt. Ein Problem führt bei den ganzen Aktionen – wie eigentlich immer – zum nächsten.

Ich bin jetzt auf das Level zurückgegangen, dass ich die Quellcodes von Git geholt und dann bei mir neu kompiliert und installiert habe.

Also klassisch

git clone https://github.com/joyent/node.git

Und dann:

./configure
make
make install

Dazu gibt es im Netz eine ziemlich gute Anleitung.

Der kleine Hinweis dort, dass das Kompilieren ein „bisschen länger“ dauert, war aber untertrieben. Ich bin mit der Erwartung von vielleicht 30 Minuten maximal in den make-Befehl rein und nach gut 5 Stunden war noch kein Ende zu sehen. Das Zeug ist dann über Nacht durchgelaufen und heute morgen war es erledigt. Das dauert also brutal lang, wobei mein Terra-Notebook auch schon in die Jahre gekommen ist.

Anyway – die Sache ging durch und nun habe ich node.js bzw. npm in der Version 18. Cordova ist damit auch eben fix installiert und wie es mit Android aussieht, schaue ich mir später an. Das ist ja die einzige kritische Stelle.

 

(Liebe) Spamer gebt gut acht, der kleine Raspi wacht

Nachdem ich mein Python-Skript zur Identifizierung und Löschung von Spam auf Basis bestimmter Schlagworte im Betreff ein bisschen getestet habe, habe ich es sowohl auf meinem Server als auch dem Raspberry Pi als CronJob bereitgestellt. Mal sehen, wie gut die Putzkolonne das E-Mail-Postfach frei hält. Die letzten Nächte hatte ich – trotz SpamAssasin & Co jeden Morgen gut 20 Dreckmails im Postfach. Ich bin guter Hoffnung, dass Raspi einen guten Torwächter abgibt und da das Python-Skript redundant auch auf dem eigentlichen Server per CronTab aufgerufen wird, werde ich mal schauen, wie ich das in Zukunft austariere. Aber vorher werde ich das Skript noch optimieren.

Python-Skript zur Spam-Abwehr

Die momentane Überflutung mit E-Mail-Spam auf meinem eigenen Server geht mir gewaltig auf die Nerven. Ich habe die Woche etwas Zeit gehabt und immer mal wieder diverse Wege ausprobiert, um diesen Angriffen etwas entgegenzusetzen. Und dabei – das ist das Positive – doch wieder was gelernt. Ich habe zig Einstellungen und Optionen an meinem Server verändert, was aber nur begrenzten Erfolg hatte und auch nicht ungefährlich ist. Sogar den Email-Server habe ich gewechselt.

Klar verwende ich SpamAssassin und habe auch Blacklist- und Whitelist-Einstellungen. Aber das hilft in meinem Fall nicht wirklich was. Oder anders ausgedrückt – ohne das Zeug würde ich vermutlich die 10-fache Menge an Spam bekommen, aber was immer noch durchkommt, ist erschreckend. Vor allen Dingen greifen die Einstellungen, dass man Absender blockiert oder freigibt, nicht. Wie gesagt – bekannte Spammer zu blocken ist garantiert sinnvoll, um 90% des Drecks wegzuhalten, aber nicht ausreichend. Denn die Spammer in der derzeitigen Flut verwenden Einmal-Adressen. Es ist daher leider vollkommen nutzlos, den Server, die Domain oder gar einen einzelnen Absender zu blockieren.

Leider kann ich auf meinem Server kein Greylisting aktivieren. Grundsätzlich ist es verfügbar, aber beim Aktivieren bekomme ich einen Bug im Serverskript angezeigt :-(. Dabei wäre Greylisting in vielen Fällen garantiert sinnvoll. Im Gegensatz zu Whitelisting (bekannte Adresse immer durchlassen) und Blacklisting (bekannte Adressen immer blockieren) lehnt man bei Greylisting unbekannte Adressen genau 1x mit einer passenden Meldung ab und trägt die Absenderadresse in eine DB ein, um bei der nächsten Zustellung den Absender durchzulassen. Seriöse Versender bzw. SMTP-Server senden einfach nach einer ersten Fehlermeldung des Adressaten automatisch nochmal (ohne dass es der Absender bemerkt), Spammer in der Regel nicht. Aber wie gesagt – kann ich (derzeit) nicht aktivieren. Mal sehen, ob ich den Fehler noch rausbekomme, aber ich bin einfach kein (echter) Admin – sondern Programmierer.

Natürlich habe ich auch SPF-Spamschutz aktiviert, aber dennoch erscheint mir das als ein nutzloser Kampf gegen Windmühlen. Eigentlich helfen nur Inhaltsfilter, denn die Spam-Flut lässt sich derzeit bei mir auf etwa 5 – 10 Schlagworte eingrenzen.

Solche Filter kann ich in Thunderbird sehr schön anlegen und auch meine GMX-Accounts erlauben das. Nur die E-Mail-Programme, die ich bisher für mein SmartPhone gefunden habe, haben dieses Feature nicht. Deshalb habe ich sogar mal versucht, meine rjs.de-Adresse auf eine GMX-Adresse weiterzuleiten, dort mit Inhaltsfiltern zu reinigen und dann zurück auf eine neue rjs.de-Adresse weiterzuleiten. Funktioniert, aber ist mir dann doch zu umständlich gewesen. Außerdem will ich meine bisherige E-Mail-Adresse nicht wegen diesen Dreckschweinen aufgeben bzw. so kastrieren.

Überhaupt – das Filtern verlagert die Sache – soweit ich es hinbekomme – vom Server in den Client, denn bei beiden POP3/IMAP-Servern, die ich verwende, gibt es dieses Filtern nach dem Inhalt leider nicht – soweit ich es herausgefunden habe .

Bei POP3-Accounts ist das Filtern mit einem E-Mail-Client aber sowieso ziemlich unnütz und deshalb habe ich jetzt mal die Geschichte komplett auf IMAP umgestellt. Hätte ich schon lange tun müssen. Aber auch dann muss ein Client mit Filtern regelmäßig das Konto überwachen (etwa ein entsprechend konfigurierter Thunderbird auf einem meiner Rechner), damit ein anderer Client ohne die passenden Filter (etwa auf dem SmartPhone) gar nicht erst den Schmutz lädt.

Die Grundidee schien mir aber ok, da ich anders nicht weiter kam. Aber einen PC Tag und Nacht laufen lassen und alle paar Minuten Thunderbird das Konto checken lassen? Das kostet zu viel Strom und ist schon auf den zweiten Blick nicht wirklich optimal.

Mir kam dann die Idee, meinen alten Raspberry Pi das machen zu lassen. Braucht kaum Strom und die Platine verstaubt sowieso vor sich hin, nachdem ich den Zwerg vom Kryptomining wieder abgezogen habe. Also damit eine Weile experimentiert. Da ich an der Platine weder Maus und Tastatur noch Monitor hängen habe und auch W-LAN nicht eingerichtet war, musste ich das Kistchen erst einmal etwas aktualisieren bzw. neu einrichten. Natürlich kann ich mit klassischem SSH mit X-Umleitung darauf zugreifen, aber ich arbeite auch bei Fernzugriff gerne mit dem Desktop. Nur komischer Weise ging der Zugriff über VNC auf den Raspi nicht. Obwohl auf der Raspi auch ein VNC-Server automatisch mit startet und ich das schon früher so gemacht habe. Ich habe es absolut nicht hinbekommen und in meiner Verzweiflung sogar xrdp installiert und – oh Wunder – der Remotedesktop-Zugriff ging einwandfrei – von Windows (!) aus.

Aber da es sich bei meinem Raspi um die Version 1 handelt, konnte ich da kein vernünftiges E-Mail-Programm installieren. Viel experimentiert bis hin zur versuchten Installation von iceweasel und icedove, aber erfolglos. Der Weg war mir dann einfach zu steinig und ich habe ihn als Sackgasse begraben.

Und dann kam mir ein Gedanke! Warum kein Python-Skript schreiben und damit das IMAP-Postfach regelmäßig abfragen? Die ursprüngliche Idee war, dass ich das dann auf dem Raspi laufen lasse, aber relativ schnell kam ich auf den Dreh, dass das natürlich auch auf dem Server selbst erfolgen kann. Ich habe ja in meinen regelmäßigen Entwickler-Tipp zu Python bei LinkedIn Learning schon einen Tipp veröffentlich, wie man per CronTab zeitgesteuert Python-Skripte ausführen kann. Was aber natürlich auch für den Raspi interessant wäre.

Das Skript, das ich dann programmiert habe, nutzt im Wesentlichen imaplib, ist aber noch nicht ganz fertig und auch noch nicht auf dem Server bzw. Raspi installiert. Aber wenn ich die derzeitige Vorversion in IDLE laufen lasse, kann ich recht zuverlässig im Betreff von E-Mails (theoretisch auch in der gesamten Mail) Schlagworte finden, die ich als SPAM empfinde und dann die Mails vom Skript automatisiert löschen lassen.

Ich werde von dem Skript noch eine Datei mit den Schlagworten einlesen lassen, reguläre Ausdrücke mit dem Modul re integrieren, das Skript eine Weile manuell testen, und dann in einen Cron-Job auf dem Server und/oder Raspi einbauen. Das sollte eine brauchbare Ergänzung meiner Spamabwehr werden und ich habe wie gesagt wieder neue Sachen gelernt, was dem Mist etwas Positives abgewinnt.

Und wenn mein Vorrat an bereits eingespielten Videos für die regelmäßigen Entwickler-Tipps zu Python zur Neige geht, habe ich damit ein interessantes Thema für die neuen Tipps, die ich dann vermutlich einspiele.

 

Mac Mini als Druckserver

Im Rahmen der Neugestaltung meines Büros mit eingeschlossenem grundlegendem Neuaufbau meiner IT bin ich zwei Probleme bzw. Fragen angegangen, die ich schon viele Monate nicht so richtig gelöst habe.

  1. Wie bekomme ich meinen Drucker-Fehlkauf – den Samsung Xpress M2026w Laserdrucker – doch noch vernünftig im Netzwerk zu laufen?
  2. Was mache ich mit meinem uralten, überzähligen Mac Mini?

Der Samsung-Drucker bekommt von mir die Krone für meine schlechteste IT-Anschaffung ever. Billig war er, aber ständig hat das Dreckding Ärger gemacht. Dabei ist es nicht einmal so schlimm, dass man den Papierschacht nur halb voll machen kann und Papierstau oder nicht richtig eingezogene Blätter den Ausdruck behindern. Das Schriftbild ist zumindest ok. Aber – der Drucker ist funktioniert im W-LAN total unzuverlässig. Deshalb habe ich ihn nach viel Arbeit und Ärger irgendwann per USB an mein NAS angeschlossen. Von ein paar Rechnern – vor allen Dingen aus Linux heraus – war er damit halbwegs zuverlässig anzusprechen. Aber von mehreren anderen Rechnern ging auch dann einfach nichts. Nun habe ich beim Neuaufbau der IT in meinem Büro eine Weile experimentiert. Sowohl an mehreren Windows- als auch Linux-Rechnern wird der Drucker per USB erkannt. Aber im Netzwerk ist er – trotz Freigabe und allen denkbaren Einrichtungen – nicht anzusprechen. Man sieht ihn, aber er reagiert einfach nicht auf Druckaufträge oder die Abfrage des Status. In alle Richtungen:

  • Linux -> Linux
  • Linux -> Windows
  • Windows-> Linux
  • Windows-> Windows

Keine Chance. Ich habe sogar meinen Rasberry PI 1 als Druckserver ausprobiert, aber da wurde der Drucker noch nicht einmal richtig erkannt.

Dann kam mir mein zweites IT-Problem in den Sinn – was mache ich mit dem Mac Mini? Meine Abneigung gegen Apple-Produkte ist ja bekannt, wenn man meinen Blog liest. Die Dinger sind viel zu teuer, zu unfrei bzw. zensiert, zu eigenwillig zu bedienen und zu viel auf Schein statt Sein optimiert (Design statt Funktionalität). Aber in einem Punkt hatte ich meinen alten Mac Mini über die Corona-Krise schätzen gelernt. Über mehrere Monate musste ich mit meiner Band Corona-bedingt eine Pause hinsichtlich von Live-Proben einhalten. Aber wir hatten uns zu regelmäßigen virtuellen Proben mit JamKazam aufgerafft und das ging mit keiner anderen Hardware auch nur ansatzweise so gut wie mit dem Mac Mini. Seit wir aber wieder live proben können, habe ich einfach keinen Bedarf mehr an dem Mac Mini. Ich kann das macOS einfach nicht bedienen. Es ist mir (!) viel zu wenig intuitiv, unlogisch, beschränkt und unbequem.

Aber unter dieser unangenehmen Oberfläche und hinter dem ganzen lächerlichen Rummel um Apple befindet sich eine solide Basis. Denn der Drucker war am Mac Mini sofort eingerichtet (ok – das ging unter Linux und Windows am USB-Port auch) als auch direkt im Netzwerk verfügbar. Und das habe ich wie gesagt mit keiner anderen Konstellation hinbekommen.

Der alte Mac Mini von 2013 wird also sein – vermutlich 4. oder 5. – Leben in Zukunft als Druckserver fristen. Ohne Monitor, Tastatur oder Maus. Aber natürlich ist SSH- und VNC-Zugriff auf dem Teilchen eingerichtet – für alle Fälle.

Apropos „Für alle Fälle“: wenn die Sache mit Corona sich weiter so schlimm entwickelt, kann er (leider) vielleicht seinen Zwei-Job für virtuelle Proben mit JamKazam wiederaufnehmen :-(.

CronTab, Schedule und Python

Nachdem ich vor ein paar Wochen meinen neuen V-Server auch gleich auf eine neue Version von Ubuntu umgestellt hatte, musste ich sämtliche Webseiten wieder neu einspielen. Bis auf meine Webseite zum Gleitschirmfliegen, in der ich eine Webcam und Wetterdaten von einem Flughang bereitstelle, konnte ich auch alle Seiten problemlos wieder einspielen. Nur diese Seite (ein Joomla!-System) hatte herumgezickt und deshalb habe ich sie einfach neu aufgesetzt (jedoch mit WordPress). Aber ein Feature habe ich da auf die Schnelle nicht hinbekommen – das Kopieren und Sichern des aktuellen Bildes der Webcam, das minütlich mit FTP auf meinen V-Server geladen wird.

Es ist aber ganz hilfreich, wenn man über eine gewisse Zeitspanne verfolgen kann, wie etwa schon vor Ort befindliche Gleitschirme oder Windfahnen sich verhalten, um zu entscheiden, ob sich ein Tripp an den Hang lohnt. Ich wurde sogar explizit gebeten, dieses Feature wieder bereitzustellen.

Die originalen PHP-Skripte hatte ich noch alle, aber das Zeug war so zusammengefrickelt (wie so oft), dass ich erst einmal meine eigenen Codes nicht mehr verstanden habe.

Aber da ich parallel im Moment Themen sammle, die ich irgendwann in meinen wöchentlichen Tipps & Tricks zu Python bei LinkedIn Learning (LiL) verwenden kann, kam ich auf die Idee, das Kopieren doch mit Python statt mit PHP zu machen sowie auch das Schedulen vielleicht auch gleich mit Python. Es gibt ja dazu das sched-Modul und/oder die klassischen Module shutil, datatime und time. Dazu gibt es noch in der Community das zusätzliche Module schedule. Also habe ich mich damit eine Weile beschäftigt. Allerdings kam ich darüber über kurz oder lang auch auf die eigentlichen Crontabs von Linux/Unix. Und wenn man die genauer ansieht, ist es fast einfacher, die direkt zu schreiben, als sie von einem Framework wie dem schedule-Modul generieren zu lassen.

Auf der anderen Seite musste ich zudem noch meinen V-Server weiter konfigurieren. Dabei habe ich auf dem Weg nano nachinstalliert, denn ich greife ja per SSH auf den V-Server zu und mit Erschrecken festgestellt, dass da bisher mir nur vim zur Verfügung stand. Also so rudimentär will ich doch nicht mehr arbeiten.

In der Folge habe ich meine neu erstellen Python-Skripte zum Kopieren der Dateien und dem täglichen Löschen des Verzeichnisses (mein Server soll ja nicht volllaufen) hochgeladen und in die CronTab direkt eingebunden. Das geht ganz einfach und logisch, wenn man sich von der Syntax nicht abschrecken lässt.

  • crontab -e öffnet die CronTab-Datei.
  • Wenn man mit nano arbeitet, kann man mit Strg+o die Datei speichern und mit Strg+x den Editor verlassen. Mehr braucht man da eigentlich nicht zu wissen.
  • Mit crontab -l kann man sich alle Cronjobs anzeigen lassen und
  • mit crontab -r bei Bedarf alle Cronjobs löschen (was aber brutal ist, weil direkt alles weg ist).

Die eigentlichen Einträge in der CronTab sehen etwa so aus:

# m h dom mon dow command
*/2 8-20 * * * python3 [pfad]/copierereichenbach.py >> /var/www/vhosts/rjs.de/rb.autoren-net.de/thumb/log.txt
* 5,23 * * * python3 [pfad]/loeschereichenbach.py

Das kopiert dann alle 2 Minuten in der Zeit von 8 bis 20 Uhr das aktuelle Bild der Webcam und um 5 und 23 Uhr wird das Verzeichnis gelöscht.

In Python selbst arbeite ich mit shutil.rmtree() und os.mkdir() beim Löschen des Verzeichnisses. Einfach alles weghauen und dann das Verzeichnis neu erstellen.

Beim Kopieren nehme ich shutil.copy2() und hänge an den Standarddateinamen einfach einen Timestamp an der von datetime.datetime.now().timestamp() geliefert wird.

Das Anzeigen der Bilddateien mache ich natürlich weiter mit PHP – da konnte ich eines meiner altern Skripts nach einer kleinen Anpassung wieder verwenden.

Server-Umzug abgeschlossen

Der Umzug meines V-Servers sollte jetzt fertig sein. Der E-Mail-Server läuft und ist hinreichend konfiguriert. Der Spamschutz scheint besser wie vorher zu sein und auch die Kommunikation mit einer E-Mail-Adresse, die bisher nie durchging, hat eben funktioniert.

Soweit ich das sehen kann, sind jetzt auch alle Webseiten von mir wiederhergestellt und gleich mal auf den neusten Stand aktualisiert. Die unwichtigste Seite hat – natürlich ;-(  – die meiste Arbeit gemacht. Aber ich habe zumindest wieder etwas zu der Bedeutung von Eigentum und Gruppenzugehörigkeit unter Linux (und auch WordPress) gelernt und diverse Linux-Shell-Befehle geübt. Bisher war ich wirklich so naiv und dachte, dass Dateirechte die entscheidenden Stellen sind und man spätestens mit 755 auf der sicheren Seite hinsichtlich der Ausführung, dem Zugriff und ggfl. Schreiben in entsprechende Verzeichnisse auf dem Server sein sollte, wenn man Webseiten bereitstellt. Ich habe wegen diverser Probleme eine gefühlte Ewigkeit erfolglos mit den Schreibrechten herum experimentiert (sowohl über FTP als auch direkt per SSH mit chmod bis hin zu 777), bis mir aufgefallen war, dass bei den Webseiten ohne Probleme ganz andere Eigentumsrechte und Gruppenzugehörigkeiten da waren als bei denen mit Problemen. Da lag der Hase im Pfeffer und root ist nicht immer root (zumindest nicht im universellen Sinn – der root des SSH ist nicht immer der root der Webserver oder gar irgendeiner Verwaltungssoftware wie Plesk). Admin fuddeln vielleicht da rum – unglaublich.

Mit chown -R für den Eigentümer und chown : für die Gruppenzugehörigkeit haben sich dann aber (fast) alle Probleme in Luft aufgelöst. Nur die Zugriffs- bzw. Rechteprobleme bei der unwichtigsten Seite (einem Joomla!-System) habe ich einfach nicht in Griff bekommen. Die Seite habe ich dann kurzentschlossen komplett neu aufgesetzt (jetzt aber als WordPress-System) und dann einfach die wichtigsten Inhalte aus meiner lokalen Sicherung eingefügt.

Und da ich gerade dabei war, habe ich auf dem neuen V-CordovaServer Docker angeschaltet und gleich mit meinem Cordova-Skript für die kommende Vorlesung an der TH Bingen getestet. Das ging wie Butter durch ein heißes Messer – oder auch umgekehrt. Alle notwendigen Programme und Bibliotheken wurden problemlos (und fix) installiert und der Container ist sofort gelaufen. Das konkrete Erstellen der Cordova-App für eine Android-Plattform ging ebenso perfekt. Ich habe mich dann noch von einem anderen Rechner per SSH auf dem Server eingeloggt und aus dem Terminal die generierte App aus dem Docker-Container auf das Host-System kopiert. Null Problemo. Unter Linux läuft so Zeug die Docker einfach perfekt.

Ich komme immer mehr auf den Geschmack, meine Kenntnisse um Docker etwas zu intensivieren und zudem mehr mit dem Server zu machen als bisher.