Beiträge von Anthracite

Mein TS-877 ist davon betroffen. Habe ich aber erst bemerkt, als ich den Fehler hier beschrieben gesehen habe. Ich schaue dort nie rein.

Ich glaube, deine Idee mit dnsmasq geht in die falsche Richtung.

Bei mir funktioniert die Auflösung der Namen über einen eigenen DNS-Server

$ nslookup ubuntu-server
[...]
Non-authoritative answer:
Name:   ubuntu-server
Address: 172.17.7.144

und dnsmasq läuft

$ ps -eaf | grep dnsmasq   
17091 admin      1828 S   /sbin/dnsmasq

(Die Container Station läuft, aber nur, weil dies Bedingung für die Virtualisation Station ist.)

Auch resolv.conf und resolv.dnsmasq scheinen mir bei dir richtig zu sein.

$ cat /etc/resolv.conf 
nameserver 127.0.1.1
$ cat /etc/resolv.dnsmasq 
nameserver 172.17.7.3@qvs0
nameserver 9.9.9.9@qvs0
nameserver fda1:[...]:fdf1@qvs0
nameserver 2a01:[...]:fdf1@qvs0

Im Detail ist letztere zwar etwas unterschiedlich, denke aber nicht, dass es daran liegt.

Ich denke, dass es bei dir irgendein Fehler in den Netzwerkeinstellungen ist, aber frag mich nicht, welcher. Die Adaptereinstellungen und den virtuellen Switch in der GUI kannst du mal prüfen.

Zitat von FSC830

Was aber nach 12 Stunden nicht viel heißt

Nach zwölf Stunden weißt du schon eine ganze Menge (bei einem NAS). Die meisten fatalen Fehler treten sofort auf, d. h. beim ersten Hochfahren. Wenn dann die VM nicht startet oder die Freigaben fehlen.

Nach 24 Stunden, wenn alle Backups einmal durchgelaufen sind, bist du schon fast auf der sicheren Seite.

Fehler, die sich erst später zeigen, sind beim NAS eher selten. (Beim PC ist das anders.)

Was Qnap bei den Tests das Genick bricht, ist nicht die Zeitdauer, die ein Test benötigt, sondern die große Anzahl der Modelle und möglicher Konfigurationen.

Zitat von Mavalok2

ies bestätigt mich aber auch weiterhin, dass diese NAS "nur" als NAS - sprich Datenspeicher - [...] geeignet ist.

Und genau diese Funktion war es, die durch das Firmware-Update außer Gefecht gesetzt worden war. Die Volumes waren verschwunden, damit auch der Datenspeicher. Selbst dafür braucht man die Möglichkeit, einen Schritt zurückgehen zu können.

Kann sein, aber in diesem Thread geht es nur um die Shell.

Betrifft jetzt zwar qts ohne hero, aber ich überlege, ob ich nicht dauerhaft bei der letzten 5er Version bleiben sollte. Die Möglichkeit, in der Version wieder zurück gehen zu können, ist ein echter Vorteil und war ein Argument für Qnap und gegen Synology. Gebraucht habe ich das zwar bisher nur ein einziges Mal, aber da hat es mir ein funktionsfähiges System gerettet (mit der damals aktuellen Version waren plötzlich alle Volumes verschwunden, mit der Vorgängerversion waren sie wieder da).

Zitat von dolbyman

Ich rede von GUI Nutzung und nicht Shell.

Damit bist du hier alleine. In dem ganzen Thread geht es nur um den Zugriff per Shell.

Zitat von dolbyman

1. Normale Nutzer sollten gar keinen Shell Zugang haben

Auch für normale Nutzer kann ein Shell-Zugang sinnvoll sein. Aber das ist nicht der Punkt. Es geht darum, dass auch der Systemadministrator (jetzt ist der Mensch gemeint) sich als normaler User anmeldet und erst dann, wenn er dies für die Shell-Kommandos wirklich braucht, sich mit sudo die erweiterten Rechte besorgt.

Zitat von dolbyman

2. Programme werden Intern immer mit UID:0 ausgeführt, deswegen kann der richtige Admin ja auch gar nicht deaktiviert werden.

Nur Programme, die mit sudo aufgerufen werden, laufen mit der UID 0. Alle anderen laufen mit der UID des Benutzers, der sie gestartet hat.

Korrekt ist, dass der richtige Admin nicht deaktiviert wird. Es wird nur die Anmeldung als Admin deaktiviert. Das ist in der GUI missverständlich verkürzt worden.

Zitat von dolbyman

3. Externe Angriffe haben meist via Exploits agiert und dann UID:0 ausgenutzt egal ob aktiv oder nicht.

Angriffe durch Exploits werden durch Deaktivierung der Adminanmeldung nicht beeinflusst, das ist korrekt.

Es gibt aber weiterhin Angriffe, die auf Erraten oder Abfangen von Passwörtern geschehen. (Diese Angriffe tauchen seltener in der Berichterstattung auf, weil es idR. nur einzelne Systeme betrifft.) Und nur diese Eingangstür wird verengt.

Zur Verhinderung von Angriffen über Exploits sind andere Sicherheitsmaßnahmen (z. B. System aktuell halten) nötig. Aber diese anderen Sicherheitsmaßnahmen sind idR. wirkungslos gegen das Abfangen/Erraten von Passwörtern. Daher müssen mehrere Sicherheitsmaßnahmen kombiniert werden.

Wie gesagt, das Deaktivieren der Adminanmeldung ist kein Rundum-Sorglos-Paket, das alleine Schutz bieten würde. Aber es schränkt nicht ein und bedeutet nur sehr geringen Komfortverlust.

Zitat von dolbyman

QNAP brauchte irgendeine vorgeschobene Anti Panik Sicherheitsanweisung

Das ist keine Qnap-Eigenleistung, sondern da zieht Qnap nur nach, was auf anderen Systemen schon längst üblich ist.

Auf dem Mac ist die root-Anmeldung seit jeher deaktiviert.

Auf modernen Linux- und Unix-Systemen ist die Anmeldung als root ebenfalls defaultmäßig deaktiviert.

Zitat von tiermutter

In der GUI gibt es wohl kaum Unterschiede, in der CLI hingegen sind sie gravierend: der normale user mit Adminrechten ist krass eingeschränkt, daher unbedingt echten admin nehmen.

Du hast zwar sonst meistens recht, hier widerspreche ich dir aber.

Der User mit Admin-Rechten hat in der Shell zwar erst einmal nur normale Rechte, kann aber jederzeit mit einem vorangestellten sudo Befehle als admin ausführen. Mit sudo -i kann man sich sogar eine vollwertige Admin-Shell besorgen, wenn doch mal nötig. Dann gibt es keine Einschränkungen mehr.

Qnap hat Recht mit der Empfehlung, der Sicherheit wegen den Admin zu deaktivieren.

In der Shell gibt es an folgenden Stellen Sicherheitsgewinne:

1. Schutz gegen eigene Dummheit. Wenn ein normaler Befehl (z. B. rm von harmlosen Dateien) plötzlich Admin-Rechte verlangt, hat man noch Gelegenheit, zu prüfen, ob Befehl, Pfad und Wildcard-Expansion korrekt sind. Beim echten Admin-User hätte man erst danach gesehen, dass man sich sein System zerschossen hat.
2. Wenn man ein schädliches Programm ausführt, egal ob mit Sicherheitslücke oder untergeschobene Schadsoftware, so wird dieses erst mal nur mit normalen Rechten ausgeführt.
3. Wenn ein externer Angreifer versucht, über Login einzudringen, muss er nicht nur das Passwort sondern auch den Benutzernamen raten.

Benutzer mit Adminrechten statt echtem Admin ist kein Rundum-Sorglos-Paket, bringt aber einen echten Sicherheitsgewinn.

Ich habe vor fünf Jahren den echten Admin deaktiviert, und brauchte ihn bis heute nicht zu aktivieren (mit einer Ausnahme, wo ich die sshd-Konfiguration kaputt gemacht hatte und mich über Telnet anmelden musste). Ich arbeite meistens in der Shell.

Zitat von Becker2020

Laut QNAP soll das Problem vermutlich am "nicht QNAP-Server" liegen. Im Post gibt es auch eine Lösung.

Ja, genau das ist das Problem. Das Backup läuft durch bis 100%, und dann wird die Meldung

"not using a post-quantum key exchange algorithm"

als Fehler betrachtet und das Backup schlägt fehl. (Genaugenommen gibt es eine Warnung, dann wird das Backup erneut durchgeführt, und erst daraufhin gibt es die Fehlermeldung.)

Ich habe mir die Sache mittlerweile mal genauer angesehen. Mit dem letzten Firmware-Update gab es ein Update auf OpenSSH 10.3p1. Alle ssh-Versionen ab 10.0 produzieren diese Warnung. Auf dem Server, einem alten Syno, ist OpenSSH 7.4p1 installiert. Die Version kennt noch keine Post-Quantum-Algorithmen. Ein Update ist nicht möglich, da das Gerät von Syno keine Updates mehr erhält (geht nach 13 Jahren auch in Ordnung).

Lösung:

Auf dem Qnap muss die Warnung in OpenSSH ausgeschaltet werden. Dazu wird in die Datei /share/homes/admin/.ssh/config (Hinweis: Das Backup läuft unter dem User admin, daher muss dessen ssh-Einstellung geändert werden) die Zeile

WarnWeakCrypto no-pq-kex

hinzugefügt werden. Datei neu anlegen mit Rechten 600 falls die Datei noch nicht vorhanden ist.

Eine oft empfohlene Einschränkung auf nur einen Host hat bei mir nicht funktioniert.

Und ja, es ist ein Qnap-Fehler. Die Warnung darf nicht als Fehlermeldung mit Fehlschlag des Backups interpretiert werden. Allerdings habe ich eine etwas ältere HBS-Version bei mir im Einsatz, da die neueste Version hier schwerwiegende Performanceprobleme hat. Kann also sein, dass der Fehler in der neuesten Version behoben ist.

Negativ. Backups auf ein anderes NAS über einen SSH-Tunnel funktionieren nicht mehr.

Die folgende Fehlermeldung kommt:

[Hybrid Backup Sync] Failed to complete Sync job: "xxxxxx". Encountered error "** WARNING: connection is not using a post-quantum key exchange algorithm."

Das dürfte nicht an HBS liegen (ein HBS-Update habe ich nicht gemacht), sondern vermutlich das Update einer darunter liegenden Komponente.

Wenn ich das recht verstehe, hast du auf deinem NAS einen Web-Server installiert, auf dem deine Seite mit den Plugins laufen soll.

Dann hast du eine eigene Internet-Domain, und bei einem Hoster hast du für diese Domain oder eine Sub-Domain die statische IP deines Anschlusses eingestellt. Oder du hast bei einem DynDNS-Provider eine Subdomain angelegt, die auf deine dynamische IP weitergeleitet wird.

In beiden Fällen läuft zwar dein Webserver auf deinem NAS, aber der DNS-Server für die DNS-Namensauflösung läuft bei deinem Hoster bzw. bei deinem DynDNS-Anbieter. Dort musst du den TXT-Record anlegen, nicht auf deinem NAS. Im Falle des Hosters und einer festen IP-Adresse funktioniert das auch tatsächlich. Bei DynDNS-Anbietern weiß ich nicht, ob diese Option überhaupt geboten wird.

Eine Alternative ist, du setzt auf dem NAS einen eigenen DNS-Server auf. Der große Nachteil an der Lösung ist, dass dafür die Seitenaufrufer diesen DNS-Server als ihren ersten DNS-Server konfiguriert haben müssen. Das werden nur Besucher aus deinem eigenen LAN machen. Für ein Testsystem (Test deiner Web-Seite) ist das aber in Ordnung. Den DNS-Server würde ich aber nicht direkt auf dem Qnap-NAS laufen lassen. Ob der vorhandene dnsmasq-Server das könnte, weiß ich nicht, aber er lässt sich nicht irgendwie vernünftig konfigurieren. Ich würde dann den DNS-Server auf einem anderen System laufen lassen, z. B. einer virtuellen Maschine mit Linux (da kenne ich mich, was den DNS-Server betrifft, nicht weiter aus), oder auf eigener Hardware. Für Letzteres sind z. B. managed Mikrotik-Switche eine Möglichkeit, zumal man einen Switch ohnehin mal brauchen kann.

Was die Sicherheit betrifft (siehe vorangegangene Beiträge):

Wenn du die Seite auf dem NAS hosten willst, dann gehört das NAS (oder wenigstens die VM, auf der das läuft) in eine DMZ, damit der externe Zugriff abgesichert werden kann. Kennst du dich mit Firewalls hinreichend aus, um das aufsetzen zu können?

Welche qts-Version? Ich habe zwar noch nicht die allerneueste Version im Einsatz, denke aber, dass sich auf qts-Seite nichts geändert hat.

Das Problem vermute ich eher im Browser oder im Schlüsselbund. Da sind die üblichen Mac-Schlüsselbundtricks einen Versuch wert, wie Schlüsselbundeintrag zum NAS manuell pflegen oder gleich ganz löschen.

Auch im Browser kann es hängen. Schon mal Firefox statt Safari versucht (und sei es für einen Test)?

Zitat von Becker2020

Hochformat deutet meist auf ein Handy-Bild hin.

Banause!

Mit der Spiegelreflex habe ich zu einem Drittel Hochformatbilder.

Das Seitenverhältnis spricht aber für das Handy. "Richtige" Kameras haben meistens 3:2 oder 4:3 bzw. 2:3 und 3:4, in seltenen Fällen auch 16:9 (Aufnahme beim Filmen). Natürlich kann ein Bild auch mal manuell auf Panoramaformat zurechtgeschnitten sein, aber dann ist das Seitenverhältnis idR. individuell für dieses eine Bild.

Zitat von NetzNoob

Da kann ich unter "Alle Aktualisierungen automatisch installieren" und "Erforderliche Aktualisierungen automatisch installieren" auswählen. Welche wäre richtig und was ist der Unterschied?

Beide sind falsch. Du willst keine Aktualisierung, weder von erforderlichen noch von anderen Versionen. "Eine Benachrichtigung versenden" wäre richtig. Den Haken ganz rausnehmen ist in deinem Falle noch besser - du willst auf diesem Softwarestand stehen bleiben.

Zitat von NetzNoob

aber die Aufforderung zur Aktualisierung von MMC erscheint nach wie vor.

Kleines schwarzes Kästchen rechts unten? Ja, das ist so, das kommt immer wieder, das kriegst du meines Wissens nach nicht weg. Einfach ignorieren und nicht dran stören.

Zitat von NetzNoob

btw. wie kann ich verhindern, dass sich die MMC wieder auf 2.10.2 aktualisiert?

Im App-Center unter Einstellungen→Aktualisieren kannst du dies auswählen. Das betrifft dann alle Apps.

Es kann sein, dass du auch bei der Firmware eine ältere Version einspielen musst. In dem Falle musst du dann noch in der Systemsteuerung→Firmwareaktualisierung das automatische Update abstellen.

Da nicht davon auszugehen ist, dass Qnap dieses Ressourcenproblem in späteren Versionen beheben wird, bedeutet das, dass du auf diesem Versionsstand stehen bleiben wirst. Wenn es sich nicht um ein Firmen-NAS handelt und das NAS von außen nicht erreichbar ist (keine Portfreigaben!) halte ich das für nicht problematisch, da du das NAS im Gegensatz zum PC nicht als Surf-, Mail- und Arbeitplatzgerät verwendest.

Ohne es auszuprobieren, ist es schwer vorherzusagen.

Folgende Bedingungen müssen erfüllt sein:

1. Die Adapterkarte muss kompatibel zu deinen TPU-Kärtchen sein
2. Die Adapterkarte muss ohne Treiber funktionieren. Grund: In qts ist ein passender Treiber garantiert nicht enthalten.
3. Es darf keine (unfreiwillige) Beschränkung in Hardware oder der qts-Firmware auf maximal zwei M.2-Slots im System geben
4. Die Virtualisation Station muss den Zugriff auf die Karten an die VM weiter leiten.

Nach einer oberflächlichen Lektüre zu der Adapterkarte scheinen 1. und 2. gegeben zu sein.

Zu 3.: Mit unfreiwilliger Beschränkung ist gemeint, dass Qnap mehr als zwei M.2-Slots vermutlich nicht absichtlich blockiert, aber die haben höchstwahrscheinlich noch nie ein TS-473A getestet, bei dem sich mehr als zwei M.2-Slots gemeldet haben. Es kann sein, dass auf Grund eines hierfür nicht geeigneten Programmes oder einer hierauf nicht angepassten Konfiguration das nicht funktioniert.

Zu 4.: Es gibt häufiger Probleme mit Geräten, die in der VM nicht auftauchen. Auch hier gilt, Qnap hat deine Konfiguration vermutlich nie ausprobiert.

Wenn jetzt jemand das schon ausprobiert hätte, und vermutlich zielt genau da deine Frage drauf ab, dann wüsstest du mehr. Ich denke aber, dafür ist dein Vorhaben hier im Forum zu speziell. Es wird dir nichts übrig bleiben, als es selbst auszuprobieren. Nach Gefühl würde ich die Wahrscheinlichkeit, dass es funktioniert, auf nicht über 50% schätzen. Bei zukünftigen Firmwareupdates wird dann auch immer das Risiko bleiben, dass es plötzlich nicht mehr geht, da von Qnap natürlich nicht getestet.

Ich habe die letzten sechs Jahre genau einmal ein Downgrade machen müssen. Tragisch wäre es gewesen, wenn ich kein Downgrade hätte machen können, denn dann hätte ich entweder das Teil neu aufsetzen müssen (zwei Tage nicht einsatzbereit + einiger Arbeitsaufwand) oder auf die nächste Firmware von Qnap warten müssen (14 Tage nicht einsetzbar). Das Gerät wird für die Arbeit genutzt.

Zitat von cbronson

Wenn die 6er Firmware gut läuft, warum sollte ich ein downgrade machen? Mit dem Update kann ja jeder warten solange er will

Ob die Firmware gut läuft, weiß man aber erst, nachdem man das Update gemacht hat, und dann ist es zu spät.

Es ist auch die Frage, ob einmalig kein Downgrade mehr möglich ist, z. B. weil die 6er Firmware Strukturen in den Volumes ändert, oder ob dauerhaft keine Downgrades mehr möglich sein werden.

Zitat von Becker2020

Anmerkung: Wenn dies für alle neuen QuTShero 6 Versionen gilt, muss man mit dem Einspielen eines Firmwareupdates zukünftig sehr sehr vorsichtig sein

Das wäre ein schwerer Rückschritt. Zu den großen Vorteilen von Qnap gegenüber Synology gehörte immer, dass man bei der Firmware einfach und weitgehend problemlos wieder eine Version zurück gehen konnte. Gelegentlich braucht man das auch. Einmal hatte ich das. Nach einem Firmware-Update waren sämtliche Volumes weg. Eine Firmware zurück, und sie waren wieder da. Zwei Wochen später gab es eine Korrektur der Firmware, die den Fehler behob. Ohne Möglichkeit der Rückkehr wäre das eine ziemliche Katastrophe gewesen. Bei Synology war es hingegen eine ziemliche Bastelei, mit der Firmware zurückzugehen, als Syno meinte, mein Backup-Programm außer Betrieb nehmen zu müssen.

Sollte man ab Version 6 keine vorangegangenen Firmwares mehr einspielen können, würde ich dauerhaft bei 5.x bleiben.