Beiträge von Anthracite

Zitat von dolbyman

Mit was lief denn die RAMdisk voll?

Die Sache ist nicht klar.

Mit du habe ich schon gründlich nach Platzfressern gesucht, aber nichts gefunden. Vor dem Reboot - also als / voll war - waren lt. du 311MB belegt, nach dem Reboot 305MB. Es ist jetzt auch nicht so, dass eine Datei, z. B eine ständig weiter vollgeschriebene Protokolldatei, allen Platz aufsaugen würde. Nachdem ich vor dem Reboot mühsam etwas Platz freigeschafft hatte, blieb dieser Platz auch frei.

Vor dem Reboot:

$ sudo du -h -x --max-depth 1
0    ./rpc
0    ./samba
4.0K    ./.system
0    ./samba_third_party
0    ./flashfs_tmp
12K    ./run
88M    ./usr
84M    ./home
0    ./share
0    ./sys
0    ./dev
48K    ./root
0    ./proc
81M    ./lib
0    ./tmp
8.2M    ./etc
8.1M    ./var
4.5M    ./bin
39M    ./sbin
0    ./lost+found
9.0K    ./mnt
0    ./new_root
311M    .

Nach dem Reboot:

$ sudo du -h -x --max-depth 1 /
Password: 
8.0K    /opt.bak
0    /rpc
0    /samba
0    /.system
0    /samba_third_party
0    /flashfs_tmp
12K    /run
88M    /usr
84M    /home
0    /share
0    /sys
0    /dev
48K    /root
0    /proc
81M    /lib
0    /tmp
8.1M    /etc
5.0M    /var
4.5M    /bin
39M    /sbin
0    /lost+found
9.0K    /mnt
0    /new_root
308M    /

Letztlich ist mir völlig egal, ob die Ramdisk nun 100MByte mehr im Speicher belegt oder nicht, aber ich möchte nicht Zeit damit verschwenden, lange zu suchen, ob irgendeine Datei ein paar MByte größer ist, als sie sein müsste. Daher mein Wunsch, einfach die Ramdisk vergrößern, und gut ist.

Hast du eine Fritzbox?

Möglicherweise kommst du mit Filter -> Priorisierung -> Hintergrundanwendungen besser zum Ziel.

Im Prinzip geht das, was du willst. Man kann aus einem Raid 1 mit zwei Festplatten eines mit drei Festplatten machen, von denen zwei Spiegelungen wären. Und man kann ein Raid 1 aus drei Festplatten wieder zu einem mit zwei Platten machen.

Aber das geht nicht in qts in der Browseroberfläche, sondern das geht nur mit lvm in der Shell. Und da lvm nicht trivial in der Bedienung ist und bei leicht möglicher Fehlbedienung erheblicher Schaden angerichtet werden kann, würdest du dadurch nicht die Sicherheit erhöhen, sondern senken.

Hinzu kommt, dass du mit deinem Vorhaben bei Raid 1 nichts gewinnen würdest gegenüber der einfachen Methode "Platte-ziehen-neue-Platte-stecken". Sollte beim Rebuilt des Raid 1 von einer auf zwei Platten was Ernstes schief gehen (z. B. die andere alte Platte fällt mit Totaldefekt aus), hättest du die noch lesbare¹) erste Platte, die du wieder einsetzen könntest, und von der aus du ebenfalls einen Rebuilt machen kannst. Und zur Not ließe sich die Platte auch unter Linux auslesen (was aber nicht trivial ist, da hier nicht nur dein Volume, sondern auch noch Systemvolumes drauf sind). Und im allerschlimmsten Fall hast du noch ein Backup (ein Raid ist kein Backup!).

¹) Wir gehen hier davon aus, dass die Platte noch lesbar ist, denn sonst wäre die Idee mit Raid 1 über drei Platten erst recht Unsinn.

Zitat von kheinisch

Was haltet ihr von meiner 600-Tage-Strategie bzw. davon, dass die jeweiligen Disks im halben Maximal-Alter-Stand ersetzt werden?

Gar nichts. Das maximale Alter ist nur eine statistische Größe. Für die einzelne Platte lassen sich daraus keine Aussagen ableiten. Ich hatte eine Platte, die zeigte nach zwei Tagen Fehler an, andere Platten laufen auch nach zehn Jahren noch. Ersetze sie dann, wenn die Smart-Werte Warnungen anzeigen.

Hier hatte ich gestern den Fall, dass die Root-Partition, also die RAM-Disk, zu 100% voll war. Danach lief so einiges nicht mehr, so liefen die Backup-Jobs auf Fehler, aber diese Fehler konnten nicht per Mail gemeldet werden. Ein Reboot hat das Problem erst einmal behoben, aber mit den Aufräumarbeiten danach war ich noch etwas beschäftigt.

Jetzt würde ich gerne die Größe der RAM-Disk dauerhaft ändern. Die hat eine Größe von 400MByte, und bei 48GByte Speicherausbau ist das lächerlich wenig.

Frage:

Wie lässt sich die Größe ändern? Es darf auch ein "Hack" sein (z. B. Systemdateien ändern).

Ist die neue Festplatte vom gleichen Typ oder vielleicht ein wenig kleiner? Einige Bytes weniger würden schon ausreichen, damit die neue Platte nicht eingebunden werden kann.

Zitat von charly700

Meiner Meinung nach müsste QNAP dann beide gleichzeitig veröffentlichen.

Nein, besser zu unterschiedlichen Zeitpunkten. Wenn dann doch mal ein Fehler die internen Tests passiert, dann sind nicht gleich alle Geräte im Feld betroffen.

Ich erinnere mich an einen früheren Arbeitgeber, bei dem ein Kollege mit einem verunglückten Update ein paar tausend Rechner abgeschossen hatte. Danach wurde ein System geschaffen, mit dem Updates erst nach und nach ausgespielt wurden.

Andere große Firmen machen das auch. Wenn Microsoft ein neues Funktionsupdate veröffentlicht, wird das auch nicht gleich allen Rechnern angeboten.

Auch beim Mac ist mittlerweile SMB Standard. In meinen Geschwindigkeitstests war SMB auch ein klein wenig schneller. (NFS ist allerdings keine Alternative zu AFP, da ein anderes Sicherheitskonzept vorliegt, die Konfiguration schwieriger ist und da NFS auf dem Mac ein Stück langsamer ist.) Daher ist, wenn man nicht gerade noch sehr alte Macs im Netz hat, AFP eigentlich überflüssig.

"Eigentlich", weil es im Detail doch mal Fälle geben kann, wo AFP nützlich ist. Ich habe hier den Effekt, dass unter gewissen Umständen der Finder keine weiteren Freigaben mit SMB mounten kann. Unter AFP klappt es hingegen.

Mit 2. Zugang meinst du einen zweiten User auf dem NAS?

Wenn du cd ~admin/.ssh bzw. cd ~Nils-86/.ssh auf dem NAS ausführst, springst du in das korrekte Verzeichnis, wo die authorized_keys angelegt werden muss (bzw. kriegst das Verzeichnis mit "Permission denied" angezeigt).

In der authorized_keys muss der öffentliche Schlüssel id_rsa.pub von dem Benutzer auf dem PC eingetragen werden. Wenn es einen PC-Nutzer gibt, der sich bei beiden NAS-Benutzern einloggen kann, dann sind die beiden authorized_keys gleich mit Ausnahme des Besitzers der Datei.

Beim Login mit ssh musst du angeben, als welcher NAS-Nutzer du dich einloggen willst (es sei denn, er hat denselben Namen wie der PC-Benutzer).

Ja, aber per Default loggt sich Putty mit Benutzer und Passwort ein (war vor 15 Jahren so, wenn ich mich recht erinnere). Den Zugang über Passwort hast du abgestellt, und damit kann sich Putty nicht mehr einloggen.

Mit "Putty-Problem" meine ich nur, dass es an deinen Einstellungen von Putty liegt, und nicht am sshd-Dämon.

Solange man den AFP-Port nicht im Internet freigibt und man keine bösartigen Nutzer im eigenen LAN hat, ist die Schwachstelle auch unerheblich.

Für Firmen, wo Angestellte auf dumme Gedanken kommen könnten, ist das eher ein Problem.

FSC830

Na bitte. Es funktioniert. password ist nicht mehr als Authentifizierungsmethode zugelassen, d. h. die geänderte sshd-Konfigdatei wird verwendet.

Gibt es einen Grund, dass du keyboard-interactive zulässt?

Dein Putty-Problem ist ein Putty-Problem, d. h. das hat erst einmal nichts mit der anderen Konfigurationsdatei zu tun. Vermutlich ist der ssh-Key, den Putty verwendet, nicht in Authorized_keys eingetragen. Oder Putty ist nicht für den ssh-Key konfiguriert. (Ich habe Putty das letzte Mal vor etwa 15 Jahren verwendet, kann dir da also nicht weiterhelfen.)

Zitat von carsten_h

Wieso soll man immer die authorized_keys editieren, wenn es doch das geniale Tool ssh-copy-id gibt?

Warum soll ich ssh-copy-id nehmen, wenn ich ruck-zuck Authorized-keys editieren kann?

Alles klar, es gibt viele Wege nach Rom.

Zitat von gga33

Wie bekomme ich HBS3 eigentlich auf meinen NAS-Starbildschirm? Das weigert sich, ausser man heisst Admin. Und ich nutze aber einen anderen (Admin)Account....

Links oben das Menü (drei Striche) aufklappen, dann kann HBS da rausgezogen und auf dem Bildschirm platziert werden.

Zitat von Nils-86

Es wird immer ein Passwort abgefragt, auch wenn ich den SSH Key nicht hinterlegt habe und dieser Zugang sollte ja auch nur mit Key funktionieren.

Wenn Authentifizierung sowohl über Passwort als auch über ssh-Keys möglich ist, dann wird immer zuerst ein Login über ssh-Keys versucht. Nur wenn dieser nicht geht, wird nach dem Passwort gefragt.

Dass in deinem Falle die Passwortabfrage kommt, wird daran liegen, dass lokal der private Schlüssel id_rsa fehlt, dass der Eintrag in Authorized_keys fehlt (Datei im falschen Verzeichnis editiert?) oder dass eine der beiden Dateien oder das .ssh Verzeichnis andere Rechte als 600 haben.

Zitat von Nils-86

aber hab das Gefühl das er die nicht lädt

Tut er auch nicht, weil du die falsche Datei editiert hast. Die richtige Datei ist /etc/config/ssh/sshd_config. ps | grep sshd hätte dir das auch verraten.

Allerdings würde dir das Editieren der richtigen Datei auch nicht helfen, weil diese, wie FSC830 schon geschrieben hat, bei Neustart des sshd-Dämons neu aufgebaut wird und damit deine Änderungen weg sind.

Was nötig ist, ist dem sshd-Dämon eine andere Konfigurationsdatei unterzuschieben. Dies geht, indem /etc/daemon_mgr.conf geändert wird und dort auf eine Kopie der Konfiguration, welche du nach Belieben ändern kannst, verwiesen wird (Parameter -f). Wenn das Ganze dann auch Reboot-fest sein soll, siehe Beitrag #7.

Zitat von FSC830

Ich habe auch mehrfach versucht irgendwo ein PasswordAuthentication no einzubauen, aber bisher ohne Erfolg.

Es geht aber, siehe über dem Zitat und Beitrag #7. Die Lösung funktioniert bei mir stabil und zuverlässig und hat sogar alle qts-Updates überlebt.

Zitat von Nils-86

Eventuell liegt es auch an den verschiedenen Versionen.

Nein. Das hat mit der Version nichts zu tun. Das Verhalten ist bei beiden Versionen dasselbe, und Fehler an dieser Stelle, also Fehler im Programm, gibt es nicht.

Kann man ein degradiertes Raid nicht erweitern? Hab' ich nie probiert. Na ja, ist auch egal, das Rebuild läuft eh schon, und damit wirst du zum Ziel kommen. (Ich hätte allerdings trotzdem den Versuch mit LVM gemacht.)

Zitat von Barungar

Auf eigene Gefahr kannst Du den SSH-Login mittels Passwort verhindern, in dem Du in die sshd_config die folgende Zeile aktivierst:

PasswordAuthentication no

Normal muss mann dann noch den sshd restarten, und dann war es das, wenn man keinen Key zur Authentifizierung hat.

Das überlebt keinen Reboot des NAS. Damit das reboot-fest wird, siehe meinen vorangegangenen Beitrag.

Eine Gefahr besteht nicht.

Ein funktionierender Telnet-Zugang ist als Fallback hilfreich.

Notfalls hilft der 3-Sekunden-Reset (autorun.sh wird deaktiviert) und folgender Reboot (sshd-config wird neu aufgebaut).

Zitat von Nils-86

Nun ich wollte halt einfach nur etwas mehr Sicherheit... Ich habe diese Zeile versucht einzufügen, jedoch hat es keine Auswirkung.

Wird bei dem Login. also dem, der nicht mehr sollte sein und trotzdem funktioniert, ein Passwort angefragt?

Wenn nein: Dann ist dein öffentlicher ssh-Schlüssel noch in der passenden Authorized_keys auf dem NAS eingetragen.

Wenn ja: Du hast die falsche Konfigurationsdatei geändert,

oder deine Änderung ist fehlerhaft,

oder du hast den sshd-Server falsch neu gestartet (Wenn du den sshd-Server nur mit killall abschießt, so dass er sich automatisch neu startet, dann wird beim automatischen Neustart die sshd-config neu aufgebaut, wenn ich mich recht erinnere, womit deine Änderung wieder weg ist. killall funktioniert nur nach Änderung von /etc/daemon_mgr.conf, siehe meinen Beitrag, wie gewünscht.)

Zitat von carsten_h

Warum sollte ich die Fotos jetzt extra mit einem anderen Programm auslesen

Mit "Programm" war jetzt in deinem Falle "Fotos" gemeint und kein anderes Programm. Ich kenne "Fotos" jetzt nicht gut (hatte mir das nur einmal angesehen und als für meine Zwecke unbrauchbar empfunden) und weiß nicht, wie weit "Fotos" den Import mit Kopie der Bilder an einen anderen Ort automatisieren kann.

Die Bilder außerhalb der Bibliothek zu lagern hat einige klare Vorteile. Im Falle des Fragestellers hier ist es die Möglichkeit, die Bilder extern ablegen zu können. Andere Vorteile sind die Möglichkeit, Bilder auch unkompliziert von einem anderen Programm (z. B. Gimp für eine besondere Bearbeitung) nutzen zu können, Bilder einfach einzeln aus einem Backup zurückholen zu können, und letztlich ist man nicht in dem Maße von dem einen Fotoverwaltungsprogramm, welches die Bibliothek angelegt hat, abhängig.

Zitat von carsten_h

Mir wäre das viel zuviel Streß, denn die müßte man dann ja auch noch irgendwie sinnvoll sortieren.

Eine Sortierung nach Importdatum oder Aufnahmedatum sollte reichen. Und je nach Programm geht das auch automatisch.

Ich sehe da keine Mehrarbeit.

Du kannst die Einzelplatte jahrelang als degradiertes Raid betreiben. Das sollte funktionieren. Aber sobald du irgendetwas in den zweiten Schacht steckst, wird das Rebuild des Raid angestoßen, d. h. du kannst den zweiten Schacht zu nichts anderem als zur Vervollständigung des Raid benutzen, es sei denn, du sagst dem Raid mit lvm, wie oben angerissen, dass es ab sofort nur noch aus einer Platte bestehe.

Zitat von rushjo

Im nächsten Schritt werde ich wahrscheinlich nochmal eine größere HDD in den zweiten Slot stecken um das RAID zu vervollständigen (Rebuild um den "Bereit Status" zu erreichen um die Expansion auf 4TB machen zu können.

Danach kommt die laute HDD aber direkt wieder raus.

Mir ist nicht klar, was du damit bezwecken willst. Sobald du die Festplatte wieder herausziehst, wird das Raid doch wieder degradiert sein.

Und wie willst du damit eine Expansion auf 4TB machen? Wie viel TB hat die SSD eigentlich jetzt?

Die Migration Raid 1 zu Einzeldisk ist auf Linux-artigen Systemen, wozu Qnap dazu gehört, prinzipiell möglich. Das Vorgehen wäre in deinem Falle wie folgt:

1. Eine Platte durch SSD ersetzen

2. warten, bis das Rebuild vom Raid 1 fertig ist

3. die zweite Platte entfernen

4. dem Gerät mitteilen, dass das Raid nur aus einer Platte besteht; das ist die Magie, geschieht in der Shell mit

 mdadm --grow --raid-devices=1 --force /dev/mdx

5. Zweite SSD einstecken und als Einzelplatte in Betrieb nehmen.

Wenn etwas schief geht, musst du das System neu aufsetzen. Aber das müsstest du sonst ohnehin.

Ich habe das nur auf Synology durchgezogen (auf Qnap hatte ich noch nicht den Bedarf), das aber mit Erfolg.

Also Links haben mir geholfen

https://www.synology-forum.de/…loesen.25030/#post-202331

Bin bis Punkt 3. oder 4. gekommen, wo es einen Fehler gab. Weiter gemacht habe ich mit

https://www.synology-forum.de/…glich.108971/#post-882318

Vermutlich hätte nur die zweite Anleitung auch funktioniert.

Noch zu den beiden Links: /volume1 ist bei Syno der Mountpoint des Raid-Volumes. Auf Qnap ist das /share/CE_CACHEDEVx_DATA

Und dev/md2 passt sicher auch nicht und braucht eine andere Nummer.

Zitat von Qnatsch

Mit Commandozeile kann man das Raid etwas auflösen.

Ist aber nur Halbgares.

Halbgar ist das nicht. Das ist Linux-Standard. Seit ich das vorgenommen habe, laufen beide dadurch entstandenen Einzelplatten stabil und zuverlässig ohne irgendwelche Auffälligkeiten.

Bei qts besteht potentiell noch die Gefahr, dass die Raid-Konfiguration noch in Qnap-spezifischen Dateien abgelegt wurde, welche dann nicht passen. Das ist aber nur eine Möglichkeit; bei Syno hatte ich kein derartiges Problem.

Wenn du die Eieruhr länger als 30s siehst, mach mal einen Refresh (Aktualisieren) im Browser. Manchmal hilft das.