Schlagwort: FTP

SFTP-Einstellung – die Nachwehen vom Server-Umzug

Ich bin bereits vor einigen Monaten mit meinem Server bzw. V-Server umgezogen, aber einige Sachen sind noch immer nicht ganz aufgeräumt bzw. vollständig eingerichtet. Etwa der FTP-Zugang. Ich habe aus Sicherheitsgründen sowieso mittlerweile (weitgehend) auf SFTP umgestellt, aber genau da gab es Probleme.

Als root konnte ich mich mit SFTP einloggen, aber die Dateien und Verzeichnisse nur ansehen und nicht runterladen bzw. irgendetwas hochladen. Bei ein paar Verzeichnissen bzw. Domain hat FTP funktioniert – mit verschiedenen Usern, bei anderen nicht. Und SFTP ging mit anderen Usern gar nicht. Aber ich konnte den zentralen Fehler irgendwann identifizieren.

ERROR: Received unexpected end-of-file from SFTP server

Die Suche danach in Internet hat zur Lösung geführt. Auch wenn die bei mir etwas anders gelagert war als in den Quellen beschrieben. Aber im Kern war es das – in der Konfiguration des SSH-Daemons gab es ein Problem. Da wurde was bei der Installation des V-Servers durch den Provider nicht ganz korrekt konfiguriert.

Ein Lösungsvorschlag war, in der Datei /etc/ssh/sshd_config nach dem folgenden Eintrag zu suchen:

# Subsystem sftp /usr/lib/openssh/sftp-server

Auskommentieren beibehalten und das folgende ergänzen, war der Tipp:

Subsystem sftp internal-sftp

Dumm nur, dass der Kommentar bei mir nicht gesetzt war. Das SFTP-Subsystem war also schon aktiv.

Eine andere Quelle hat die Zeile genannt:

Subsystem sftp /usr/libexec/openssh/sftp-server

Und das hat mich zu der Lösung geführt, die für meinen Server gepasst hat. Denn diese Pfadangabe gab es bei mir nicht. Folge – ich habe verstanden, was es dem ersten Fall mit dem Verweis auf das interne SFTP auf sich hat.

Die Lösung bei mir war, den SFTP-Server von OpenSSH auszukommentieren, auf das interne SFTP umzustellen und dann mit

service sshd restart

den SSH-Daemon neu zu starten.

Jetzt scheint der Zugang mit SFTP bei allen Domains bzw. allen eingerichteten Usern zu funktionieren.

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.