Dateien regelmäßig von FTP Server in Datenverzeichniss von Nextcloud kopieren

hokaido
Goto Top
Hallo,

mein Scanner legt die Scans auf einem FTP Account auf Server 1 ab.

Auf Server 2 mit Ubuntu 20.04 habe ich eine Nextcloud laufen.

Kann ich irgendwie z.B. alle 5 min von Server 2 auf dem FTP Account auf Server 1 nachschauen ob neue Dateien drin sind und wenn ja diese ineinen bestimmten Ordner (im NC Datenverzeichnis) verschieben?

Hintergrund:
Binde ich den FTP in Nextcloud ein, erscheinen die Daten nicht im Webmenü der Nextcloud. Erst nach occ files:scan
Gehe ich den Umweg mit der Verschiebeaktion ins NC Datenverzeichnis werden sie angezeigt.
Extra einen FTP Server auf Server 2 zu installieren will ich auch aus Sicherheitsgründen nicht.

Kann jemand weiterhelfen?

Danke
Christian

Content-Key: 831551565

Url: https://administrator.de/contentid/831551565

Ausgedruckt am: 04.07.2022 um 09:07 Uhr

Mitglied: 126231
126231 27.06.2021 um 20:15:10 Uhr
Goto Top
Servus!
Warum nicht einfach einen cron-job auf dem Server erstellen, der das alle 5-10 Minuten occ files:scan macht?

Gruß
Luigi
Mitglied: hokaido
hokaido 27.06.2021 um 20:42:30 Uhr
Goto Top
Da hatte ich auch daran gedacht. Aber die Nextcloud hat mehrere 100 GB Daten. Und die mit occ files:scan zu scannen dauert deutlich länger als 5min bis zur nächsten Ausführung des Cronjobs
Mitglied: hokaido
hokaido 27.06.2021 um 23:31:49 Uhr
Goto Top
Gerne auch irgendeine andere Lösung die den Ordner auf Server 1 überwacht und neue Dateien sofort auf Server 2 verschiebt
Mitglied: colinardo
colinardo 28.06.2021 aktualisiert um 07:50:55 Uhr
Goto Top
Servus.
Rsync oder die Live-Variante lsyncd die via inotify auf Dateisystemänderungen reagiert.

Grüße Uwe
Mitglied: magicteddy
magicteddy 28.06.2021 um 07:49:11 Uhr
Goto Top
Moin,

was läuft denn auf Server 1 an Software und Betriebssystem?
Ich kenne die Möglichkeit das ein FTP Server nach einem Upload ein Kommando ausführt, er könnte dann ja die Datei aktiv auf Server 2 kopieren...

-teddy
Mitglied: hokaido
hokaido 28.06.2021 um 08:22:18 Uhr
Goto Top
Danke, schaue ich mir an. Auf beiden Servern Ubuntu 20.04 LTS
Mitglied: hokaido
hokaido 28.06.2021 um 09:25:51 Uhr
Goto Top
Ich hab es jetzt so gelöst:

sudo -u www-data crontab -e

*/5 * * * * php /var/www/nextcloud/occ files:scan --path="/USER/files/Ordner"

Das funktioniert. Aber ich muss halt immer 5 min warten. Ich schaue mir deshalb die naderen Lösungen an. Vll. geht damit ja ein sofortiges Kopieren / Verschieben
Mitglied: colinardo
colinardo 28.06.2021 aktualisiert um 09:50:08 Uhr
Goto Top
Zitat von @hokaido:

Vll. geht damit ja ein sofortiges Kopieren / Verschieben
Ja klar, wie oben schon geschrieben nutzt lsyncd inotify und damit die Events die das Dateisystem beim erstellen/modifizieren von Dateien generiert. Kann man sich natürlich mit inotifywait und rsync auch selbst in nem Bash Script zimmern wenn man will.
Mitglied: hokaido
hokaido 28.06.2021 um 09:58:24 Uhr
Goto Top
Muss ich mir anschauen, die Tage...
Mitglied: linuxer1
linuxer1 28.06.2021 um 19:32:22 Uhr
Goto Top
Ich hatte ein ähnliches Szenario: Dateien werden in ein Verzeichnis kopiert, das auch in der NextCloud ersichtlich ist / sein soll.

Mein Lösungsansatz: das Verzeichnis unterhalb des Datenvezeichnisses auf Dateisystemebene in der Nextcloud eingebunden und in der
Nextcloud als external Storage eingebbunden und freigegeben.
Die Rechteproblematik die sich daraus ergibt habe ich mit mount --bind gelöst.

Wenn du genauere Infos haben möchtest einfach ansagen.
Schliesslich gibt es viele Wege die nach Rom führen ;)
Mitglied: hokaido
hokaido 28.06.2021 um 22:36:41 Uhr
Goto Top
@linuxer1:
Ja gerne genauere Infos bitte.
Mitglied: hokaido
hokaido 28.06.2021 um 22:37:49 Uhr
Goto Top
Ich habe derweil lsyncd nach der Anleitung
https://www.howtoforge.de/anleitung/wie-synchronisiert-man-verzeichnisse ...
installiert und eingerichtet.

Leider funktioniert das aber nicht.

systemctl status lsyncd
● lsyncd.service - LSB: lsyncd daemon init script
Loaded: loaded (/etc/init.d/lsyncd; generated)
Active: active (exited) since Mon 2021-06-28 22:11:04 CEST; 18min ago
Docs: man:systemd-sysv-generator(8)
Tasks: 0 (limit: 2279)
Memory: 0B
CGroup: /system.slice/lsyncd.service

Jun 28 22:11:04 srv2 systemd[1]: Starting LSB: lsyncd daemon init script...
Jun 28 22:11:04 srv2 lsyncd[9864]: * Starting synchronization daemon lsyncd
Jun 28 22:11:04 srv2 lsyncd[9870]: 22:11:04 Normal: --- Startup, daemonizing ---
Jun 28 22:11:04 srv2 lsyncd[9870]: Cannot open logfile [/var/log/lsyncd/lsyncd.log]!
Jun 28 22:11:04 srv2 lsyncd[9864]: ...fail!
Jun 28 22:11:04 srv2 systemd[1]: Started LSB: lsyncd daemon init script.

Alle Verzeichnisse und .log & .status Dateien sind eingerichtet.

Woran kann das liegen?
Mitglied: linuxer1
linuxer1 29.06.2021 um 07:32:49 Uhr
Goto Top
folgende Vorgehensweise hat bei mir zum erfolg geführt:

ich habe das als nfs verzeichnis vorliegen und eingebunden

prereq
verzeichnis das die ftp daten vorhält: SERVER1/FTPVERZ
nextcloud-datenverzeichnis: NCVERZ
Das Datenverzeichnis meint das Verzeichnis in dem auch die NC-User die Daten vorhalten.

auf dem Nextcloud server
mountpoint erstellt: NCVERZ/FTPVERZ
mount SERVER1/FTPVERZ /NCVERZ/FTPVERZ --bind -o force-user=www-data,force-group=www-data

wobei www-data der user ist unter dem der Webserver läuft (bei mir debian)

und um das ganze direkt beim neustart wieder verfügbar zu haben
/etc/fstab edietieren

das bind mount war notwendig, weil sonst die cloud die daten nicht lesen konnte
ich habe hier kein lsync oder inotify oder ähnliches am laufen fuer diesen Vorgang
Mitglied: hokaido
hokaido 29.06.2021 um 07:52:30 Uhr
Goto Top
Danke, auch das probiere ich mal aus...
Jetzt hab ich schon 3 Möglichkeiten. Mal schaun, welche die geeignetste ist
Mitglied: hokaido
hokaido 29.06.2021 um 07:55:41 Uhr
Goto Top
Aktuell favorisiere ich aber lysnc, wobei das irgendwie noch zickt
Mitglied: colinardo
colinardo 29.06.2021 aktualisiert um 09:08:23 Uhr
Goto Top
Deswegen hasse ich solche Anleitungen, da schaltet der gemeine User schnell mal das Hirn aus.
Zitat von @hokaido:
Jun 28 22:11:04 srv2 lsyncd[9870]: Cannot open logfile [/var/log/lsyncd/lsyncd.log]!
Woran kann das liegen?
Die Meldung kommt genau dann wenn das Log-Verzeichnis nicht existiert oder die falschen Berechtigungen hat.

Hier ein aktuelles Ubuntu mit einwandfrei arbeitendem lsyncd

screenshot

Und jetzt provoziere ich deinen Fehler mal selbst indem ich das Log-Verzeichnis aus dem Dateisystem entferne

screenshot

Grüße Uwe
Mitglied: hokaido
hokaido 29.06.2021 aktualisiert um 09:17:32 Uhr
Goto Top
Wie geschrieben, Verzeichnis und Logfile vorhanden. In der Anleitung steht nämlich nicht, dass man beides erstellen muss. Habe ich aber gemacht. Hirn war also an...
Welche Berechtigungen hast du vergeben?
Mitglied: colinardo
colinardo 29.06.2021 aktualisiert um 09:39:46 Uhr
Goto Top
Zitat von @hokaido:

Wie geschrieben, Verzeichnis und Logfile vorhanden. In der Anleitung steht nämlich nicht, dass man beides erstellen muss. Habe ich aber gemacht. Hirn war also an...
Welche Berechtigungen hast du vergeben?
Keine, wenn du mal ins Service-File reinschaust erkennst du das der Dienst per Default mit Root-Rechten läuft. Die Logfiles selbst darfst du nicht selbst erstellen das macht der Dienst selbst, nur das Log-Verzeichnis erstellst du!.
Kann also Root in das Logfile Verzeichnis schreiben reicht das, danach noch ein systemctl restart lsyncd und es läuft einwandfrei. Ansonsten poste doch bitte deine Configs und Rechte der Verzeichnisse.
Läuft auf sämtlichen hier verfügbaren Distros problemlos, liegt also an deiner Installation.
Mitglied: hokaido
hokaido 29.06.2021 um 10:07:11 Uhr
Goto Top
Das Verzeichnis hat diese Rechte:
drwxr-xr-x 2 root root 4096 Jun 29 09:56 lysncd
Mitglied: linuxer1
linuxer1 29.06.2021 um 14:07:19 Uhr
Goto Top
setz dich mal die Rechte fuers LOG zu testzwecken auf
chmod 0777 lsyncd

BITTE NUR ZU TESTZWECKEN VERY INSECURE und ausserhalb Testszenario NOGO
sollte es dann starten, Rechte und Eigentümer entsprechend anpassen.
Mitglied: hokaido
hokaido 30.06.2021 aktualisiert um 09:56:30 Uhr
Goto Top
Also mit chmod 0777 lsyncd bekomme ich diese Fehlermeldung nicht mehr. Dafür dann eine, die angbelich den absoluten Pfad des Quell Ordners nicht finden kann, obwohl der definiert ist.

Ist sehr seltsam das Tool. Ich werds mal auf nem anderen Server probieren.
Mitglied: colinardo
colinardo 30.06.2021 aktualisiert um 14:15:48 Uhr
Goto Top
Zitat von @hokaido:

Also mit chmod 0777 lsyncd bekomme ich diese Fehlermeldung nicht mehr.
OK, dann schau mal wem das Logfile nun gehört, also wer ist der Owner?
Dafür dann eine, die angbelich den absoluten Pfad des Quell Ordners nicht finden kann, obwohl der definiert ist.
Geh doch bitte noch mal in dich und versetze dich in unsere Lage. Uns liegt hier nur das vor was du uns an Informationen lieferst. Ohne jegliche Information über deine Konfiguration von lsyncd und Informationen wo Quell- und Zielordner liegen geschweige denn unter welchem Account diese Ordner evt. mit welchen Rechten gemountet sind, oder ob private keys für SSH Accounts nicht richtig hinterlegt sind, können wir hier lange rum raten.
Ist sehr seltsam das Tool.
Wie gesagt lsyncd basiert auf bewährten Tools wie inotifywait und rsync und ist keine große Sache. Das gleiche kannst du dir mit einem simplen Shell-Script auch selber bauen bspw. im einfachsten Fall so
inotify-tools installieren
Und einem Bash Script ala
Dann noch ne systemd-unit für nen Daemon zusammengetippt und du hast etwas sehr ähnliches ohne weitere Software realisiert.

Grüße Uwe
Mitglied: hokaido
hokaido 30.06.2021 um 13:10:47 Uhr
Goto Top
Vielen Dank. Wie gesagt, am Server ist eigentlich nichts großartiges umkonfiguriert. Alles andere läuft ja einwandfrei.
Quelle und Ziel hatte ich schon div. ausprobiert:
/test/1
/test/2

/home/xyz/quelle
/home/xyz/ziel

etc
SSH Keys funktionieren alle.
Aber ich teste es auch auf dem anderen Server mal.

Da bisher alle Scipte zuverlässig laufen, würde ich das auch ausprobieren. Quelle und Ziel sind klar, aber worauf bezieht sich "/path/to/folder".
Mitglied: colinardo
colinardo 30.06.2021 aktualisiert um 13:24:36 Uhr
Goto Top
Zitat von @hokaido:
Quelle und Ziel sind klar, aber worauf bezieht sich "/path/to/folder".
Auf den Quellordner, hatte den Namen hinterher aber nochmal angepasst das es eindeutiger ist. INotify muss ja die Quelle auf Änderungen überwachen nicht das Ziel face-wink.
Mitglied: hokaido
hokaido 30.06.2021 um 13:24:32 Uhr
Goto Top
Danke, das probier ich doch gleich mal
Mitglied: colinardo
colinardo 30.06.2021 aktualisiert um 14:24:04 Uhr
Goto Top
Kannst du meine erste Frage aus dem vorletzten Post evtl auch noch beantworten, da du dich ja scheust hier vollständige Configs zu posten.
Zitat von @colinardo:
OK, dann schau mal wem das Logfile nach dem Anpassen der Rechte nun gehört, also wer ist der Owner?

Mitglied: hokaido
hokaido 30.06.2021 aktualisiert um 23:54:14 Uhr
Goto Top
Also auf dem anderen Server läuft lsyncd ohne irgendwelche Anpassungen der Rechte. Lediglich das
Log Verzeichnis und die Log Datei musste ich manuell anlegen (ohne manuellen Eingriff ging es nicht):


Lösche ich allerdings die Dateien aus dem Quellordner, sind Sie auch aus dem Zielordner weg. Die Dateien aber nur an einem Ort zu haben, war das Ziel.

Die Dateien sollen also von der Quelle zum Ziel kopiert werden und dann aus Quelle gelöscht werden, oder aber gleich komplett nach Ziel verschoben werden
Mitglied: colinardo
colinardo 01.07.2021 aktualisiert um 08:04:40 Uhr
Goto Top
Zitat von @hokaido:

Also auf dem anderen Server läuft lsyncd ohne irgendwelche Anpassungen der Rechte.
Jepp.
Lediglich das
Log Verzeichnis und die Log Datei musste ich manuell anlegen (ohne manuellen Eingriff ging es nicht):
Log Verzeichnis anlegen reicht, die Log-Datei erstellt lsyncd selbst!
Lösche ich allerdings die Dateien aus dem Quellordner, sind Sie auch aus dem Zielordner weg.
Das musst du ja über die Config Datei von lsyncd konfigurieren, dort gibt es die Direktive delete die du auf false festlegen musst!
<Code>
delete = false
</code>
https://axkibe.github.io/lsyncd/manual/config/layer4/
Wie gesagt baut lsyncd auf rsync auf und kennt deshalb so gut wie alle Parameter von diesem welche sich in der lsyncd config konfigurieren lassen.
Warum liest hier eigentlich keiner mehr Dokumentationen?!
Mitglied: hokaido
hokaido 01.07.2021 um 08:13:50 Uhr
Goto Top
Naja, delete = false hab ich schon eingebaut gehabt.
Löscht mir die Dateien aus beiden Ordnern, sowohl Quelle als auch Ziel
Mitglied: colinardo
colinardo 01.07.2021 aktualisiert um 08:26:45 Uhr
Goto Top
Zitat von @hokaido:

Naja, delete = false hab ich schon eingebaut gehabt.
Löscht mir die Dateien aus beiden Ordnern, sowohl Quelle als auch Ziel
Das ist Blödsinn! Das würde auch rsync niemals machen und tut es hier auch nicht! Die Quelle fast rsync niemals an.
Du erzählst hier ein Märchen nach dem anderen, sorry.

<Code>
Deletions
By default Lsyncd will delete files on the target that are not present at the source since this is a fundamental part of the idea of keeping the target in sync with the source. However, many users requested exceptions for this, for various reasons, so all default implementations take delete as an additional parameter.

Valid values for delete are:

delete = true Default. Lsyncd will delete on the target whatever is not in the source. At startup and what's being deleted during normal operation.
delete = false Lsyncd will not delete any files on the target. Not on startup nor on normal operation. (Overwrites are possible though)
delete = 'startup' Lsyncd will delete files on the target when it starts up but not on normal operation.
delete = 'running' Lsyncd will not delete files on the target when it starts up but will delete those that are removed during normal operation.
</code>
Zusätzlich lassen sich Aktionen nach dem Durchlauf konfigurieren
https://axkibe.github.io/lsyncd/manual/config/layer3/


Ich bin jetzt raus. Lsyncd arbeitet einwandfrei man muss es nur mit den richtigen Parametern füttern.

Viel Erfolg
Grüße Uwe
Mitglied: hokaido
hokaido 01.07.2021 um 08:36:08 Uhr
Goto Top
Und der delete Befehl kann in jeder Ausprägung nur aus dem Ziel löschen. Und genau da sollen die Dateien bleiben. Sie sollen in der Quelle nach dem kopieren gelöscht werden oder eben gleich verschoben. Das geht aber anscheinend nicht.
Mitglied: colinardo
colinardo 01.07.2021 aktualisiert um 09:38:54 Uhr
Goto Top
Zitat von @hokaido:

Und der delete Befehl kann in jeder Ausprägung nur aus dem Ziel löschen.
Korrekt aber das tut er nur wenn die Option falsch oder nicht gesetzt ist.
Und genau da sollen die Dateien bleiben.
Was delete = false ja schon macht. Es verhindert das in der Quelle gelöschte Dateien im Ziel auch gelöscht werden.
Sie sollen in der Quelle nach dem kopieren gelöscht werden oder eben gleich verschoben. Das geht aber anscheinend nicht.
Doch das geht, genau deswegen habe ich in meinem letzten Post den Link zu den 'Actions" gepostet, darin kannst du ein Löschbefehl für die Quelldateien hinterlegen, der nach dem Übertragen automatisch ausgeführt wird.
https://axkibe.github.io/lsyncd/manual/config/layer3/

Alternativ kannst du rsync in den lsyncd Optionen den Parameter --remove-source-files mitgeben der erledigt das gleich mit.
Mitglied: colinardo
Lösung colinardo 01.07.2021 aktualisiert um 11:01:32 Uhr
Goto Top
So damit das hier jetzt mal zu einem Ende kommt hat eine funktionsfähige Basis-Config die das macht was du oben geschildert hast nämlich folgendes:

Einen Quell-Ordner mit einem Zielordner One-Way synchronisieren ohne bereits existierende Dateien im Ziel zu löschen und nach der Übertragung die im Quellordner eingeworfenen Dateien zu löschen.

back-to-topVor dem Sync

screenshot

back-to-topNach dem Sync

screenshot


Fazit: Works how it was as designed.

Grüße Uwe

Wenns das dann war, den Beitrag bitte noch auf gelöst setzen, und Lösungen markieren. Merci.

-edit-

Wenn man dann noch leere von rsync hinterlassene Ordner in der Quelle tilgen möchte geht das mit folgender Config
Statt dem rsync Binary gibt man den Pfad zu einem benutzerdefiniertem Script (im Beispiel "/test/lsyncd.sh") an und fügt dort folgendes ein:
Das führt also den Rsync Befehl nach Vorgabe von lsyncd aus und bei Erfolg löscht es leere Unterordner aus der Quelle.
Mitglied: hokaido
hokaido 01.07.2021 um 10:10:12 Uhr
Goto Top
Danke.
Für alle, die ähnliches suchen. Damit ihr nicht mühsam suchen müsst:


settings {
logfile = "/var/log/lsyncd/lsyncd.log",
statusFile = "/var/log/lsyncd/lsyncd.status",
statusInterval = 20,
nodaemon = false
}

sync {
default.rsync,
source = "/Quelle",
target = "/Ziel",
delete = false,
rsync = {
_extra = { "--remove-source-files" }
}
}
Mitglied: hokaido
hokaido 01.07.2021 um 23:07:45 Uhr
Goto Top
Nur noch eine kurze Rückmeldung:
Das funktioniert soweit jetzt einwandfrei. Danke.
Falls jemand aber damit wie ich die Dateien in die Nextcloud verschieben will => Dort kann man die Dateien nicht öffnen, weil sie alle dem Besitzer root zugeordnet werden. Alle Dateien für Nextcloud müssen aber den Besitzer www-data haben.
Mitglied: hokaido
Lösung hokaido 02.07.2021 um 08:34:39 Uhr
Goto Top
Wenn man den Benutzer dabei gleich ändern will, dann so. Dann funktioniert es:
Lösung hokaido vor 22 Stunden | Bearbeiten
quote
Goto Top
Danke.
Für alle, die ähnliches suchen. Damit ihr nicht mühsam suchen müsst:


settings {
logfile = "/var/log/lsyncd/lsyncd.log",
statusFile = "/var/log/lsyncd/lsyncd.status",
statusInterval = 20,
nodaemon = false
}

sync {
default.rsync,
source = "/Quelle",
target = "/Ziel",
delete = false,
rsync = {
_extra = {"-og", "--chown=www-data:www-data", "--remove-source-files"}
}
}
Mitglied: aqui
aqui 02.07.2021 um 15:56:28 Uhr
Goto Top
Damit ihr nicht mühsam suchen müsst:
Wäre doch mal klasse und hilft der Community hier wenn du die Snippets und Screenshots von oben mal zusammensammelst und davon mal ein tolles Tutorial für alle machst !! 😉
Solche Szenarien werden ja gefühlt mindestens 3mal pro Woche hier gefragt und ein Tutorial würde garantiert helfen !