Dann würde ich die Warteschleife oben gar nicht brauchen.
Das sollte ohne die Warteschleife funktionieren. Ich habe es aber nie probiert.
Beiträge von Anthracite
-
-
Es soll bei fehlendem Gateway ein "reboot" durchgeführt werden, kein "Shutdown"
Ein Reboot ist ein Shutdown mit anschließendem automatischem Neustart. Für deine konkrete Fragestellung ist es also dasselbe.
Was ist mit diesen aufstartenden Prozessen, wenn vorher ein "reboot" in meinem Script startet? Verhindert "reboot" das Aufstarten weitere Prozesse? Gefahr für Datenbanken?
Das hängt letztlich von dem Programm ab, das den neuen Prozess startet.
Beim Shutdown wird allen normalen (s. u.) Prozessen ein SIGTERM-Signal geschickt. Dies ist eine freundliche Bitte sich zu beenden. Eine kurze Gnadenfrist später (einige Sekunden) wird allen dann laufenden Prozessen, egal ob nach dem ersten Signal noch nicht beendet oder neu gestartet, ein SIGKILL-Signal geschickt, womit der Prozess sofort beendet und aus dem System entfernt wird.
SIGTERM kann ein Prozess abfangen. Dies sollte er tun, um laufende Operationen, insbesondere Datei-Operationen, sauber abzuschließen, so dass sich danach alles im konsistenten Zustand befindet. Und er sollte dann natürlich keine neuen Prozesse für neue Aufgaben mehr starten.
SIGKILL kann nicht abgefangen werden. Der Zustand kann nicht bereinigt werden. Ein Prozess mit Schreibzugriffen auf Dateien kann diese in beschädigtem Zustand zurücklassen.
Bei ein paar Prozessen wird hiervon abgewichen, Prozesse für Dateisysteme. Diese dürfen sich nicht beim ersten SIGTERM beenden, da dann womöglich andere Prozesse ihre Aufräumarbeiten mangels Dateisystem nicht durchführen könnten. Stattdessen werden erst zu einem späteren Zeitpunkt des Shutdowns alle Dateisysteme sorgsam abgemeldet.
Ob deine Programme beim Shutdown sauber funktionieren, hängt also von deren Implementierung ab.
Shell-Skripte brechen bei SIGTERM direkt ab und die Shell führt das Skript nicht fort, d. h. startet keine weiteren Prozesse.
Datenbanken speichern laufende Transaktionen ab (eventuell einen Zwischenstand, der später wieder aufgenommen werden kann). Datenbanken sind sehr gut auf Shutdowns getestet, da sie durchgehend laufen und ein Shutdown der normale Fall zur Beendigung ist.
Wenn du irgendein exotisches oder selbstgeschriebenes Programm (nicht Skript!) hast, was SIGTERM nicht korrekt handhabt, kann aber was schief laufen.
Beim Systemstart werden üblicherweise Skripte (Shell, bei Qnap auch viel Python) ausgeführt. Da diese sauber abgebrochen werden, kann durch einen Reboot nichts schief gehen.
=> Du hast nichts zu befürchten.
-
Ja, kannst du machen.
Beim Shutdown werden alle Prozesse, insbesondere auch der des Dateisystems, sauber heruntergefahren. Daher darf dadurch kein Schaden entstehen.
Übrigens, falls du doch was falsch machst und eine Endlos-Shutdown-Schleife einbaust, musst du den 3-Sekunden- oder 10-Sekunden-Reset (weiß gerade nicht, welchen) machen, damit autorun.sh wieder deaktiviert wird. Sieh zu, dass du dann dein Default-Admin-Passwort hast.
-
Den mysql-Client musst du dafür installieren. Der wird nicht mitgeliefert.
-
Code
sudo: mysql: command not foundGemeint war, den MySQL- bzw. MariaDB-Client auf dem PC aufrufen. Mir ist nicht bekannt, dass es diesen auch direkt auf QNAP gäbe.
sudo brauchst du dafür nicht.
-
Gibt es Log-Meldungen dazu (in den Linux-Log-Verzeichnissen oder mit dmesg) dazu? Eventuell im App-Center einmal MariaDB stoppen und starten, um Meldungen zu provozieren.
Hast du (vom PC aus) versucht, dich im Terminal mit mysql --host <ip des NAS> zu verbinden?
Beim Versuch die /usr/local/mariadb/my-mariadb.cnf grade zu biegen scheiter ich, weil die die Rechte 644 hat und deren Benutzer ist admin, ich habe aber ein anderes Administrator-Konto angelegt.
sudo ist dein Freund.
Mir fällt auf, dass auch hier z.B. das tmp- und das data- dir 755 Rechte hat und dem Benutzer admin gehört - oder läuft intern alles als Benutzer admin???
Der Prozess läuft unter dem User admin, das ist also in Ordnung.
-
Bei Installieren der VM habe ich die Netzwerkschnittstelle in der Anwendung der VM auf die IP 192.168.0.10 eingerichtet.
Warum wird der Virtual Adapter (ganz links im Bild) ohne IP angezeigt?
Das ist bei mir auch so.
Das ist kein Problem, es funktioniert trotzdem.
-
Warum rufst du die App über das App-Center und nicht über das Menü links oben auf?
-
Für das TS-877 ist die Version auch wieder da - mit gleicher Build-Nummer.
Insofern frage ich mich, was da falsch gemacht wurde, so dass es zu diesem Hin-und-Her gekommen ist.
An diejenigen, die die Datei schon heruntergeladen hatten, bevor sie vom Netz genommen wurde: Ist die jetzt wieder neu eingestellte Datei identisch, oder ist diese unterschiedlich?
Bei unterschiedlichen Dateien dürfte es ein Fehler in der Versionszusammenstellung gewesen sein, und dann würde ich denjenigen, die diese Version schon hatten, empfehlen, noch mal zu installieren.
-
TS-877
Aber nicht auf der Webseite, da wird die Version nicht angezeigt, sondern wenn ich in der Systemsteuerung/Firmwareaktualisierung nach einer neuen Version schaue.
-
Vermutlich haben sie vergessen, die Änderungen in den Build zu integrieren. Irgendeinen Grund muss es doch gegeben haben, dass die Firmware bei allen problemlos läuft.
Mal im Ernst:
Wenn ich in der Systemsteuerung nach einer neuen Version suche, wird mir die 3410 noch angezeigt,
-
Ich habe es aus Neugier einmal bei mir ausprobiert.
Sowohl bei Linux als auch bei qts beschwert er sich über die IP-Adresse im Eintrag Hostname, davon abgesehen wird bei beiden Systemen, also auch bei qts, die config-Datei verwendet. Mit anderen Worten: Es liegt kein qts-Problem vor, sondern prinzipiell funktioniert es bei qts auch.
Damit ist die Frage, was bei dir anders als bei mir ist. Kommentiere mal für einen Test mit einem # die Zeilen Host und Hostname aus, damit die Konfigurationsdatei bei jedem Host gezogen wird und ein falsch geschriebener Hostname als Fehlerursache ausgeschlossen wird.
sehe ich bei ssh -vvv
Den Parameter -vvv brauchst du übrigens nicht. Bei der Abfrage der Passphrase zeigt ssh an, für welchen Key, und damit siehst du, ob der Eintrag in der config-Datei seine Wirkung zeigt.
-
Die Datei truenas-test gibt es in deinem ssh-Verzeichnis nicht. Und wenn es sie gibt, muss sie auch die Dateirechte 600 besitzen.
ssh ist mit den Dateirechten sehr kleinlich. Und wenn da was nicht stimmt, gibt es keine Fehlermeldung, sondern die Datei oder der Schlüssel wird einfach nicht benutzt.
-
Mach mal chmod 600 auf die config-Datei. Das könnte dein Problem lösen.
-
- bei jedem Verbindungsversuch bei dem ich nicht explizit den private key angebe, wird automatisch und immer der private key "id_rsa" genutzt
Das ist auch der Default bei ssh.
- id_rsa ist bei QNAP nur ein link auf die Datei "ssh_host_rsa_key".
Bei mir nicht. Ich habe ohne Probleme eigene Dateien dort ablegen können, und ich erinnere mich nicht, etwas Spezielles gemacht zu haben. Zeig mal ein ls -l auf den Link, so dass der Pfad sichtbar wird, um sicher zu gehen, dass wir über dieselbe Datei reden.
Dann ist mir nicht klar, wie du per ssh auf die GUI zugreifst. Bei mir funktioniert das über einen ssh-Tunnel, den ich aber manuell aufbaue.
Oder meinst du einen ssh-Zugriff in HBS3, den HBS3 automatisch aufbaut (also nicht über die GUI), der aber über die GUI konfiguriert wird?
-
Da tiermutter mich herbeigerufen hat:
Du nimmst HBS, wenn du die Daten deines NAS woanders hin (USB-Platte, anderes NAS, Cloud) sichern willst.
Wenn du einen PC (Linux, Mac oder Windows) sichern willst, dann nimmst du ein Backup-Programm auf dem PC (z. B. Back-in-time, Time-Machine oder was für Windows).
Da du Letzteres vor hast, brauchst du kein HBS (außer s. u.).
Wenn du Linux mit KDE hast, dann empfehle ich dir Back-in-Time. Unter Gnome geht das vermutlich auch, oder du nimmst ein Backup-Programm für Gnome.
Mit Back-in-time kannst du per ssh auf dem Qnap sichern. Dazu musst du auf Qnap in der Systemsteuerung den ssh-Zugriff freigeben und SFTP aktivieren. Back-in-time geht über sshfs, was bedeutet, du brauchst auf dem Qnap keinen rsync-Server.
Dann brauchst du auf dem NAS noch einen Back-in-time-Benutzer. Ich würde nicht Admin nehmen, obwohl das funktionieren würde. Sicherer ist es, einen eigenen Benutzer hierfür anzulegen. Dieser Benutzer muss sich per ssh anmelden können. Dafür muss er in die Gruppe der Administratoren aufgenommen werden auf Grund einer Einschränkung in qts. (Besser wäre es, der Benutzer wäre kein Administrator, aber dafür müsste man auf dem Qnap die sshd-Konfigurationsdatei ändern, was kniffelig ist.) Der Benutzer muss Schreibrechte auf das Backup-Verzeichnis haben.
Für den automatischen Login brauchst du keine Zertifikate, sondern ssh-Schlüssel. Diese musst du auf dem Linux-PC mit ssh-keygen erzeugen, und zwar, da Back-in-time als root laufen wird (ist sonst sinnlos), muss das auch für root geschehen, nicht für deinen Privatuser. Den öffentlichen Schlüssel kopierst du auf das Qnap in .ssh/authorized_keys für den Back-in-time-Benutzer. Siehe auch hier.
Anschließend musst du in Back-in-time einen Job mit ssh anlegen.
Falls du nicht Back-in-time nimmst, sondern ein anderes Programm, könnte es dein, dass du einen rsync-Server auf dem NAS brauchst. Diesen müsstest du dann in HBS aktivieren.
-
Ich habe hier zwei Switche von Mikrotik und einen von Qnap (ein zweiter ist verkauft). Inkompatibilitäten habe ich mit einer Ausnahme nicht gehabt. Alles spricht miteinander. Sowohl Qnap als auch Mikrotik sind genügsam, was Transceiver und DAC-Kabel betrifft. Man braucht nicht auf eine Kodierung zu achten.
Die eine Ausnahme betrifft den Qnap-Switch und einen alten 10GbE-Thunderbolt-Adapter (war noch das erste Thunderbolt) für den Mac. Die mochten einander nicht und eine stabile Verbindung kam nicht zustande. Mit einem Mikrotik-Switch hat es dann geklappt.
Außerdem hatte ich schon mal Probleme, wenn an den beiden Enden eines LWL-Kabels Transceiver verschiedener Hersteller hingen. Das kann klappen, muss aber nicht. Beim DAC-Kabel ist das natürlich nicht relevant.
Ist denn in den passiven DAC überhaupt was drin außer Kupfer ?
DAC steht für "Direkt Attached Copper". Insofern ist für die eigentliche Übertragung nur ein Kupferkabel (sowie Isolierung und Abschirmung) drin.
Allerdings enthalten die Kabelenden einen Chip, der dem sfp(+)-Port sagt, was das Kabel kann (Geschwindigkeit), und der manchmal eine herstellerspezifische Kodierung enthält, damit die teuren Geräte vom Originalhersteller nur mit den teuren Kabeln von demselben Originalhersteller zusammen funktionieren. Letzteres ist z. B. bei Intel und HP der Fall, nicht aber bei Qnap und Mikrotik.
-
Vielleicht, aber Fragesteller hat qts, nicht hero, und ich weiß auch nicht, ob das mit dem HBS-Job kollidieren würde.
-
Leider kann man die Daten immer noch über den Admin überschreiben, auch mit dem Skript passiert das:
Ja das ist so. Das liegt an Unix und Linux.
Wenn du das Recht hast, in einem Verzeichnis zu schreiben, kannst du dort beliebige Dateien löschen und anlegen, auch wenn du auf die Datei selbst, die du löschen willst, keine Rechte hast.
Und root/admin darf ohnehin auf alle Dateien und Verzeichnisse lesend und schreibend zugreifen, egal wie die Rechte sind.
Und wenn du auch per SMB auf die Dateien zugreifst, dann umgeht SMB die Unix-Rechte.
Du bräuchtest ein WORM-Dateisystem (write once read many). Ich habe nicht den Überblick, ob es da was für Linux gibt und noch weniger, ob man das für Qnap nutzen kann.
Mein Tipp: Sei mit deinem Skript zufrieden, erweitere es eventuell noch auf die Verzeichnis-Rechte (so dass dann nicht mit dem HBS-Job kollidiert), oder überdenke das ganze Konzept noch einmal.
Ein Hinweis: chmod -R ist rekursiv. Vielleicht hilft's.
-
Der rsync-User muss aber laut Recheche auf der Syno durchaus Adminrechte haben, denn bei Syno haben nur Admins Zugang zur Shell.
Bei mir hat der rsync-User keine Admin-Rechte, und es funktioniert. Allerdings erfolgt der Login über ssh-Keys, die Datei /etc/ssh/sshd_config habe ich (u. A. für die ssh-Keys) individuell angepasst, das System läuft mit DSM 6.2 (altes Modell) und die Konfiguration wurde ursprünglich unter DSM 4.x erstellt. Woran es letztlich liegt, dass kein Admin-Recht für den Zugang benötigt wird, weiß ich nicht mehr.
Ich verstehe auch nicht, warum Syno und Qnap die ssh-Anmeldung auf Admin-User beschränken. Gerade bei einem automatisch ablaufenden Backup-Job, der sich selbstständig per ssh anmelden und der daher die Anmeldedaten gespeichert haben muss, ist das Risiko potentiell höher, dass die Anmeldedaten in falsche Hände geraten, und dann ist es von Vorteil, wenn der rsync-User auf dem fernen NAS nicht gleich ein Admin ist.
