mgutt

Links biddö

Mit den Daten auf der Platte stimmt was nicht. Schon mal abgestürzt oder hart abgeschaltet? Dann unbedingt einen btrfs scrub machen. btrfs ist extrem pingelig, wenn man nicht ordentlich runterfährt. Ansonsten kann es alles mögliche sein. Defekte Platte, Wackelkontakt... Wie gesagt, Logs checken (unter Tools).

Fehler stehen in den Logs bzw auf das Festplatten Icon klicken. Oder Diagnostics posten.

Ja, dies ist ein Problem, was wohl auch zu Abstürzen führen kann, wenn VMs und Container beide br0 nutzen. Das soll aber in der nächsten unRAID Version 6.10 nicht mehr auftreten, wenn man bei den Docker Einstellungen von macvlan auf ipvlan ändert.

Dann läuft der Container denke ich mal und das Problem liegt woanders. Denk dran, dass jeder Container ein paar Sekunden braucht, bis er eine GUI anzeigt. Gerade die mit VNC brauchen ein paar Sekunden länger.

Ich möchte möglichst alle Docker über https verschlüsseln. Über NPM kann ich jedem Docker eine Domain zuweisen und dann ein Let's Encrypt Zertifikat anfordern. Allerdings möchte ich nicht jeden Container öffentlich erreichbar machen. Daher kam ich auf die Idee nur lokale Zugriffe zu erlauben: 1.) Ich trage in NPM bei jedem Host, der nur lokal erreichbar sein soll, unter "Advanced" folgende Regel ein: location / { # allow anyone in 192.168.178.0/24 allow 192.168.178.0/24; # allow our public ipv4 allow 169.254.1.1; # allow our public ipv6 allow fe80::/10; # drop rest of the world deny all; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection $http_connection; proxy_http_version 1.1; # Proxy! include conf.d/include/proxy.conf; } 2.) Nun wird das folgende Skript alle 5 Minuten ausgeführt, damit die Platzhalter IP 169.254.1.1 bzw fe80::/10 aus der zuvor genannten Konfiguration gegen meine öffentliche IP ersetzt wird: #!/bin/bash # make script race condition safe if [[ -d "/tmp/${0//\//_}" ]] || ! mkdir "/tmp/${0//\//_}"; then exit 1; fi; trap 'rmdir "/tmp/${0//\//_}"' EXIT; # get public ipv4 ipv4=$(getent ahostsv4 server.example.com | grep STREAM | head -n 1 | cut -d ' ' -f 1) ipv6=$(ip -6 addr show dev br0 scope global | grep -oP "(?<=inet6 )[^/]+" | head -n 1 | cut -d ':' -f 1-4)"::/56" # replace ipv4 in nginx config sed -i "/# allow our public ipv4/!b;n;c\ \ allow $ipv4;" /mnt/user/appdata/npm/data/nginx/proxy_host/*.conf # replace ipv6 in nginx config sed -i "/# allow our public ipv6/!b;n;c\ \ allow $ipv6;" /mnt/user/appdata/npm/data/nginx/proxy_host/*.conf # reload nginx configuration docker exec -i npm nginx -s reload Das ist wichtig, denn obwohl ich von lokal auf den Container zugreife, kommen meine Zugriffe "von außen" über die öffentliche IP-Adresse. Ich komme nun über die Domain auf meinen Container (Falls ich den Proxy Host über NPM bearbeite, verliert er kurz die IP, aber nach 5 Minuten ist sie wieder erlaubt): Haltet ihr das für die "einfachste" Lösung oder habt ihr eine bessere Idee wie man das umsetzen könnte?

Doch gibt es. Laut Bewertungen sind sie sogar alle zufrieden, weil eben keine Hitzeprobleme mehr da seien. Das wäre denke ich die beste Option. @Kamek0na Wo soll der Server stehen? Wenn er zB im selben Raum steht, könnte man den SFP+ Adapter und ein DAC Kabel (1 oder 3m) nehmen und komplett auf einen Switch verzichten. Einfach Server und Mac direkt verbinden (jeweils feste IP) und beide zusätzlich per RJ45 (oder WLAN) mit dem Router, damit sie ins Internet kommen. Längere optische Kabel quer durch die Bude gingen natürlich auch. Kommt drauf an wie schön das am Ende werden soll 😉

Pi-Hole schleift schon mal gar nichts durch (löst als DNS Server ja nur Domains auf) und Unbound kenne ich nicht. Kann aber gut sein, dass es andere Gründe hatte. Deswegen sollte dein erster Blick immer sein: Läuft der Container laut Übersicht und wenn du ihn nicht erreichst: Was sagen die Logs des Containers?

1.) Ein Passwort was man nicht erraten kann, wird auch ohne Fail2Ban nicht erraten. Einen Schutz vor Bruteforce hat Nextcloud nämlich schon eingebaut: https://docs.nextcloud.com/server/latest/admin_manual/configuration_server/bruteforce_configuration.html 2.) 2FA ist dagegen schon sinnvoll, wenn man davon ausgeht, dass ein Angreifer das Passwort irgendwie stehlen könnte. 3.) Hilft beides nicht gegen Sicherheitslücken innerhalb von Nextcloud. Und genau die brechen einem das Genick, wenn der Nextcloud Container auf dem Host System mehr Rechte hat, als er eigentlich sollte. Die Angreifer brechen dann nämlich nicht "nur" in die Website ein, sondern ins Host System und genau das soll ja ein Container bzw eine VM verhindern. Also sind das jetzt die Logs wo Nextcloud mit erweiterten Rechten läuft? Das nützt ja nichts. Dann tritt ja offensichtlich kein Fehler auf. Du musst schon die Rechte entziehen. Vorzugsweise den Container inkl Image löschen und mit dem Plugin "Appdata Cleanup" auch die Dateien auf der SSD entfernen.

Follow the steps to find the problem: https://forums.unraid.net/topic/110245-support-nginx-proxy-manager-npm-official/#:~:text=Debug Server Errors 5xx

Die von den Containern. Eine VM oder Container ist ein isoliertes System mit strengen Regeln. Wenn man anfängt das Konzept aufzuweichen, könnte man auch gleich die Software auf dem Host installieren. Dann passiert aber das was Syno und Qnap passiert, nämlich Sicherheitslücken, die sich auf das gesamte System auswirken. Aus dem Grund lehne ich auch klar Unraid's MyServer ab bzw eigentlich alle lokal laufenden Dienste wie auch Wireshark. Konkret zu deinen Containern wäre dann schon die Frage ob Nextcloud öffentlich erreichbar sein wird. Wenn ja, stellt sich da gar nicht die Frage ob nur du darauf zugreifst, denn dass ist garantiert nicht der Fall. Aber auch nur bei lokalem Zugriff sollten die Hürden hoch bleiben. Schließlich könnte sich dein Client einen Virus einfangen, der gezielt nach Lücken auf anderen Systemen im Netzwerk sucht. Wenn dir die 2% Restrisiko nachher alles zerschießen, wirst du das auch nicht mehr lustig finden. Natürlich bleibt es deine Entscheidung, aber ganz klar gesagt: Die Container laufen normalerweise alle so wie sie eingestellt sind. Das ist ja das schöne an unRAID.

Mehr Input. Welcher Container und was kommt in den Logs?

Check auf jeden Fall die Bewertungen. Die meisten 10G Adapter überhitzen und liefern daher eh keine stabilen 10G.

Siehe hier: https://forums.unraid.net/topic/93844-kernel-panic-rip-0010nf_nat_setup_info-nf_nat/

Manche Intel CPUs haben einen Bug, wenn sie C10 erreichen. Setz mal hpet=disable als Kernel Option und starte neu.

Thread lesen und per Input liefern? Ein bisschen wenig Infos von dir 😉

Erstmal alte Version weiter nutzen?

Ne, "sind die lautesten", sollte es eigentlich werden. Die hören sich beim Schreiben so an als seien sie kaputt ^^

Klingt so als sei @ich777 gefragt: https://forums.unraid.net/topic/60306-audio-support-in-kernel-usb-dac-alsa/?do=findComment&comment=1007638 Die Frage ist auch, ob man Spotify Container A ganz gezielt an Kanal 1 und 2 senden lassen kann und Spotify Container B an Kanal 3 und 4?!

Man könnte alle kleinen Dateien auf die SSD kopieren. Der Mover kann sie dann nicht aufs Array verschieben, da er bereits existierende überspringt. Dann braucht es einen rsync, der Änderungen der Dateien aufs Array synct und gelöschte vom Array entfernt. Einziger Fallstrick wäre, wenn neue Dateien erstellt werden und der Mover dann vor rsync startet. In so einem Fall würde der Mover die Datei ins Array schieben und rsync würde sie löschen (weil SSD die Quelle ist). Man müsste also den Mover Zeitplan mit dem rsync abstimmen.

Die ist schuld. WD Black und Crucial sind instabil in Linux. Daher muss man ASPM deaktivieren. Ich habe deswegen auch wieder Samsung gekauft.

Da nicht, aber der Adapter für den Mac ist sauteuer.

Er hat eine gebrauchte und günstige ECC fähige CPU gekauft. Das bekäme er mit einem 8th oder 9th i3 ebenfalls und die gibt es massig für kleines Geld gebraucht. Und soweit sind die von der Leistung her nicht auseinander: https://www.cpubenchmark.net/compare/Intel-Xeon-E5-2670-vs-Intel-i3-8100-vs-Intel-i3-9350K/1220vs3103vs3709 Bzw im Single Thread verspeist der i3 den Xeon zum Frühstück. So geil skalieren Apps auch in Windows nicht über alle Kerne. Single Thread ist King. Wenn Kohle dafür da ist, dann natürlich eher ein 6 bis 10 Kern Workstation Xeon der E-21xx, E-22xx oder W-12xx Serien. Und wenn ECC egal ist, dann geht natürlich auch ein i5/i7. Aber erstmal hören, was er zu sagen hat.

Dann würden die SSDs beim Schreiben auf die Geschwindigkeit der Paritätsdisk gedrosselt (also ca 70 MB/s). Das willst du sicher nicht. Was meinst du damit? Die 10te Gen sollte das können. Daher braucht es die saubere Trennung zwischen Hot und Cold Storage. Die SSDs müssen einfach groß genug sein, damit du quasi nie auf die HDDs zugreifen musst. Wenn du aber wirklich viele Spiele und der Bibliothek vorhalten willst (kann man die eigentlich aufs Netzwerk auslagern?!), dann wäre tatsächlich ein RAID besser. Du kannst Uploads übrigens auch über viel RAM beschleunigen: Größere SSDs kaufen. Probleme muss man manchmal mit Geld lösen ^^ Vom Prinzip geht ja auch alles. Also Array, RAID und Pool. Es ginge ja sogar NVMe an VM durchschleifen. Alle Möglichkeiten stehen dir offen. Das ist nicht normal. Muss an den Platten gelegen haben. Das geht nur in dem du selbst die SMB Config bearbeitest. Also von Hand Shares dafür erstellst. Das ist nicht so schlimm wie es sich anhört. Es gibt das Config Editor Plugin und mit dem kannst du über die GUI die smb-extra.conf auf dem Stick bearbeiten und zb sowas hinzufügen: [Minecraft] path = /mnt/user/appdata/minecraft comment = browseable = yes # Private writeable = no read list = write list = max,moritz valid users = max,moritz case sensitive = auto preserve case = yes short preserve case = yes Bei mir ist der Share appdata nicht über das Netzwerk erreichbar, dafür aber der Unterordner Minecraft, so dass mein Sohn selbst Level hochladen kann. Das wäre bei einem RAID wieder so eine Sache. Also ständig laufende Platten meine ich jetzt. Deine Hardware ist dafür auch nicht optimal gewählt (Netzteil, Board und GPU). Aber wenn du eine Gaming VM haben willst, ist das Thema eh schwieriger.

Ich empfehle dir dein Setup zu tauschen. Schon ein i3-8100 hat mit seiner iGPU genug Leistung: https://forums.unraid.net/topic/97593-intel-i3-8100-with-uhd630-the-plex-transcoding-beast/ Da brauchst du dann gar keine dGPU mehr. Alternativ solltest du auf der Abspielseite für bessere Clients sorgen. Zb ein Nvidia Shield. Der spielt alles ohne Transcoding.