Basic Backup Basic Backup

[luddi]

[...] Optionsschalter einbauen, der ein Verbose für SSH bereitstellt [...]

Das wäre eine feine Sache

 

[sccsmz]

Hallo Tommes,
ich habe die SSH Verbindungen nochmal neu erstellt und jetzt gehen sie Backupjobss wieder ohne Fehler.
Warum ich die Prozedur nochmals machen musste, ist allerding ein Rätzel, denn die Backups liefen schon eine ganze Weile ohne Fehler.
Den Optionsschalte finde ich gut.
Aber nochmals zu dem SSH log, wo findet man das in der Syno, unter var/log steht nichts.
Liegt das am dem DSM 7.x?

 

[Tommes]

Ich vermute mal, das @luddi das mit der log Ausgabe für SSH etwas anders meinte, auch wenn Linux das sicherlich irgendwo und in irgendeiner Form in einer Log-Datei protokolliert. In Basic Backup selbst wird die SSH Verbindung nicht weiter protokolliert, man erhält nur eine Information, ob die Verbindung steht oder nicht. Man kann den meisten Shell Befehlen - und SSH gehört dazu - aber einen Optionsschalter mitgeben, um weitere Informationen während der Verarbeitung des Befehls zu erhalten. Man nennt diesen Prozess auch Verbose oder Debugging Mode. @luddi hat das in seinem Screenshot im Post #199 für rsync gezeigt… also das mit dem -v, -vv bzw. -vvv. Gleiches kann man auch für SSH verwenden und man erhält dann sowas, wie es hier z.B. beschrieben wird.

Den Optionsschalter in Basic Backup einzubauen und die Ausgabe in das Protokoll schreiben zu lassen, sollte kein Problem sein. Die Frage ist halt nur, ob ich das irgendwie trennen soll? Also das wenn der Optionsschalter gesetzt ist, das gleichzeitig für rsync und ssh gelten sollte, oder ob ich für rsync und ssh unterschiedliche Optionsschalter einbauen sollte, um das zu trennen.

ich habe die SSH Verbindungen nochmal neu erstellt und jetzt gehen sie Backupjobss wieder ohne Fehler.
Warum ich die Prozedur nochmals machen musste, ist allerding ein Rätzel…

Das ist wieder so eine Glaskugelfrage, die sich kaum beantworten lässt. Halten wir einfach fest, das es wieder funktioniert und hinterfragen in diesem Zusammenhang nicht die Gründe dafür.

 

[Tommes]

Basic Backup Version 0.6-300 vom 15.04.2022​

• Es wurde der Vorgang beschrieben, wie man über die File Station der "autopilot" Datei das Attribut "ausführbar" vergeben kann.
• UUID eines SATA-Datenträgers wurde nicht ausgelesen. Fehler wurde behoben.
• Über die Optionsschalter -v, -vv sowie -vvv werden neben den erweiterten rsync Protokollen nun auch SSH Verbindungsprotokolle für den Debugging Mode 1, 2 und 3 ausgegeben.

GitHub Downloadlink​

Weiterhin viel Spaß mit Basic Backup

 

[luddi]

Über die Optionsschalter -v, -vv sowie -vvv werden neben den erweiterten rsync Protokollen nun auch SSH Verbindungsprotokolle für den Debugging Mode 1, 2 und 3 ausgegeben.

Du bist der Beste! Ganz große Klasse die schnelle Umsetzung.

 

[Tommes]

Du bist der Beste!

Grrrrr Baby!

Ich sehe aber grade, das die Ausgabe der SSH Debug Protokolle nur in der Konsole ausgegeben werden und nicht im Sicherungsprotokoll auftauchen. Komisch, das ich das nicht kontrolliert habe ... da muss ich also nochmal ran. Shit.

 

[Tommes]

Ich sehe aber grade, das die Ausgabe der SSH Debug Protokolle nur in der Konsole ausgegeben werden und nicht im Sicherungsprotokoll auftauchen.

Fehler behoben. Habe das Paket mit der Version 0.6-300 nochmal neu auf GitHub geladen. All diejenigen, die sich die ursprüngliche Verion 0.6-300 bereits installiert haben, bitte ich, die jetzt auf GitHub verfügbare Version erneut zu installieren.

Sorry für dieses Missgeschick und das ihr das Paket evt. ein zweites mal installieren müsst.

 

[luddi]

Fehler behoben.

Prima, ich habe es bei mir einmal ausprobiert und kann dies bestätigen.

Habe das Paket mit der Version 0.6-300 nochmal neu auf GitHub geladen.

Weshalb wird dann der Version String nicht angepasst? Ist meine persönliche Meinung, aber ein Bugfix mit der gleichen Versionskennung auszuliefern finde ich unmöglich
Ich bin ein Freund von Transparenz! Wofür hat man denn einen Version String wenn man diesen nicht pflegt? Sobald eine Version für einen Release verwendet wurde ist dieser "verbrannt" und die Software darf die gleiche Kennung nicht noch einmal verwenden. Wünschenswert wäre hier z.B. eine 0.6-301 mit der man kennzeichnet dass es sich um ein Bugfix handelt und eine kurze Release Note dazu was sich geändert hat wäre sicher die saubere Variante gewesen.
Aber ich will ja jetzt nicht päpstlicher als der Papst sein. Dein Projekt und Engagement ist Klasse! Ich denke du hast diesen Weg vermutlich nur aus Bequemlichkeit gewählt um schnell handeln zu können und um den Patch schnellstmöglich bereitzustellen.

@Tommes: Lass dich von mir nicht ärgern... Frohe Ostern!

 

[Tommes]

Lass dich von mir nicht ärgern...

Ich habe damit aufgehört, mich von dir ärgern zu lassen, seit dem klappt das mit uns beiden scheinbar wieder besser … obwohl ich dir ja wirklich viel zu verdanken habe, hast du dich doch sehr ausdauernd darum bemüht, mir einige Dinge zu erklären, die mir zu dem Zeitpunkt nicht bekannt waren bzw. ich anfangs nicht verstehen wollte.

Ist meine persönliche Meinung, aber ein Bugfix mit der gleichen Versionskennung auszuliefern finde ich unmöglich

Schimpf und Schande über mich! Aber ja, du hast natürlich vollkommen recht, sowas macht man eigentlich nicht. Ich kann zu meiner Verteidigung nur sagen, das zwischen dem ersten und dem zweiten Release grade mal 2 Stunden an einem Freitagvormittag lagen. Daher habe ich…

…diesen Weg vermutlich nur aus Bequemlichkeit gewählt um schnell handeln zu können und um den Patch schnellstmöglich bereitzustellen.

So oder so ähnlich muss es wohl gewesen sein. Man könnte es auch als künstlerische Freiheit abtun. Egal. Kommt nicht mehr vor.

Prima, ich habe es bei mir einmal ausprobiert und kann dies bestätigen.

Freut mich, das du mit dem Ergebnis zufrieden bist. Dein Tipp - oder Wink mit dem Zaunpfahl - das ins Protokoll aufzunehmen, war aber auch wirklich gut und wird in Zukunft wohl dabei helfen, Verbindungsprobleme schneller zu identifizieren.

Frohe Ostern!

Frohe Ostern!

 

[stere]

Hallo Zusammen,
vorab mal vielan Dank an Tommes für das coole Tool.
Leider habe ich Probleme beim Handshake. Ich habe alles nach der Anleitung gemacht, bekomme aber den Fehler

root@NAS01:~# ssh -p 22 stefan@192.168.178.12
kex_exchange_identification: read: Connection reset by peer

Kann mir jemand dabei weiterhelfen?

 

[Tommes]

Werf bitte mal einen Blick in die Blockierungsliste deiner DS (NAS01) falls du diese aktivert hast. Handelt es sich bei dem Remote Server ebenfalls um eine DS, dann schau auch dort nach. Du findest diese im DSM unter Systemsteuerung > Sicherheit im Reiter Schutz. Ziemlich weit unten findest du eine Schaltfläche mit der Bezeichnung "Freigabe-/Blockierungsliste". Nachdem sich ein weiters Fenster geöffnet hat, wechselst du in den Reiter "Blockierungsliste". Ich vermute, das hier die IP 192.168.178.12 hinterlegt ist. Falls ja, dann entferne die IP aus der Liste und versuch erneut, dich per SSH zu verbinden.

 

[stere]

Beim Remote-NAS war das lokale NAS blockiert, aber es funktioniert dennoch nicht.
Was ich vorhin gergessen hatte: Das lokale NAS ist ein DS215j und das Remote-NAS ein DS216j

 

[Tommes]

Gib bitte mal…

ssh -p 22 -v stefan@192.168.178.12

… ein und poste, was dir ausgegeben wird. Achte ggf. auf sensible Daten, die du nicht veröffentlichen möchtest.

 

[stere]

root@NAS01:~# ssh -p 22 -v stefan@192.168.178.12
OpenSSH_8.2p1, OpenSSL 1.1.1l  24 Aug 2021
debug1: Authenticator provider $SSH_SK_PROVIDER did not resolve; disabling
debug1: Connecting to 192.168.178.12 [192.168.178.12] port 22.
debug1: Connection established.
debug1: identity file /root/.ssh/id_rsa type 0
debug1: identity file /root/.ssh/id_rsa-cert type -1
debug1: identity file /root/.ssh/id_dsa type -1
debug1: identity file /root/.ssh/id_dsa-cert type -1
debug1: identity file /root/.ssh/id_ecdsa type -1
debug1: identity file /root/.ssh/id_ecdsa-cert type -1
debug1: identity file /root/.ssh/id_ecdsa_sk type -1
debug1: identity file /root/.ssh/id_ecdsa_sk-cert type -1
debug1: identity file /root/.ssh/id_ed25519 type -1
debug1: identity file /root/.ssh/id_ed25519-cert type -1
debug1: identity file /root/.ssh/id_ed25519_sk type -1
debug1: identity file /root/.ssh/id_ed25519_sk-cert type -1
debug1: identity file /root/.ssh/id_xmss type -1
debug1: identity file /root/.ssh/id_xmss-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_8.2
kex_exchange_identification: read: Connection reset by peer

 

[luddi]

stefan@192.168.178.12

Ist der User "stefan" Mitglied der Gruppe "administrators"?

 

[stere]

ja, ist er

 

[luddi]

root@NAS01:~# ssh -p 22 stefan@192.168.178.12

Hier im Post #210 wird versucht die Verbindung von NAS01 auf das andere NAS herzustellen.

Wie sieht es aus wenn man die gleiche Verbindung von einem anderen Host versucht aufzubauen?
Also von der gleichen Maschine mit der du die Verbindung zu NAS01 aufbaust.

Bekommst du dann auch den gleichen Fehler?

 

[Tommes]

Was mich ein wenig verwundert ist, das nach dem hier…

debug1: identity file /root/.ssh/id_rsa type 0
debug1: identity file /root/.ssh/id_rsa-cert type -1

… weiter nach dem passenden Schlüssel gesucht wird…

debug1: identity file /root/.ssh/id_dsa type -1
debug1: identity file /root/.ssh/id_dsa-cert type -1
debug1: identity file /root/.ssh/id_ecdsa type -1
debug1: identity file /root/.ssh/id_ecdsa-cert type -1
debug1: identity file /root/.ssh/id_ecdsa_sk type -1
debug1: identity file /root/.ssh/id_ecdsa_sk-cert type -1
debug1: identity file /root/.ssh/id_ed25519 type -1
debug1: identity file /root/.ssh/id_ed25519-cert type -1
debug1: identity file /root/.ssh/id_ed25519_sk type -1
debug1: identity file /root/.ssh/id_ed25519_sk-cert type -1
debug1: identity file /root/.ssh/id_xmss type -1
debug1: identity file /root/.ssh/id_xmss-cert type -1

Das sollte eigentlich nicht sein. Daher gehe ich davon aus, das bei der Schlüsselerstellung irgendwas schief gelaufen ist. Ich teste gleich mal bei mir, ob bzw. wie ich diesen Fehler provozieren kann. Geh du am besten nochmal die Anleitung durch, scheinbar hast du irgendwas übersehen

Oder hast du anstatt des Standard Dateinamen id_rsa einen alternativen Namen verwendet?

 

[Tommes]

Basic Backup Version 0.6-400 vom 24.04.2022​

• Ändern der Art und Weise, wie Basic Backup einer Gruppe hinzugefügt werden kann, um Ordner-, Datei- und Systemrechte zu erweitern (App-Berechtigungen).
• Die App-Berechtigungen können ab sofort, falls gewünscht, wieder entzogen werden. Basic Backup wird dabei aus der entsprechenden Gruppe entfernt.
• Die Beschreibung zum erweitern bzw. beschränken der App-Berechtigungen wurde in die interne Hilfe verschoben.
• Die Beschreibung zum (de)-aktivieren der USB/SATA-Autopilot Funktion wurde in die interne Hilfe verschoben.
• Die Beschreibung zum einrichten eines externen USB/SATA-Datenträgers für AutoPilot wurde in die interne Hilfe kopiert.

GitHub Downloadlink​

Weiterhin viel Spaß mit Basic Backup

 

[luddi]

Hi @Tommes wie du vielleicht schon mitbekommen hast habe ich Werbung für dein Tool gemacht.

In diesem Beitrag rsync Kopie und Ordnerstruktur ist folgender Request entstanden... bzw. ich selbst habe das als Möglichkeit vorgeschlagen

Wäre es dir möglich eine Option zu implementieren um das Backup der Task Configs zu deaktivieren?
Damit allein die gewählten Quelldateien am Ziel abgelegt werden ohne das "@configs" Verzeichnis.

Quasi per default aktiviert, und wenn jemand besonderen Wert darauf legt dies nicht mit zu sichern die Option zu haben deaktivieren zu können.
Ich denke das sollte kein großes Problem für dich sein.

Beste Grüße
luddi