Beiträge von subitus

Die Passwortadministration klappt prima über:

/mnt/ext/opt/mysql/bin/mysqladmin

Gruß vom subitus

"Echte" Zertifikate sind an eine IP-Adresse + Portnummer gebunden, da die Verschlüsselung mittels TLS-Layer aufgebaut, bevor eine URI angefragt wird. Benutzt man virtuelle Hosts (heutzutage auf Grund des beschränkten IP-Adressraums die Regel), weiss der Webserver nicht, welches Zertifikat für die Verbindung genutzt werden soll. Hier kommt die TLS-Erweiterung SNI ins Spiel: Diese ermöglicht die Übertragung des Servernamens zum Zeitpunkt des Verbindungsaufbaus. Somit lassen sich virtuelle Hosts mit jeweils ihren eigenen Zertifikaten nutzen. Allerdings besteht die Gefahr, dass nicht alle Clients mit SNI klarkommen - dies ist zu beachten, wenn nicht nur Browser auf eine entsprechende verschlüsselte Seite zugreifen sollen.

Mit SNI lassen sich Wildcard-Zertifikate nutzen, dann kann TLS/ SSL für alle Subdomains genutzt werden. Kostet i.d.R. aber Extra.

Weitere Infos zur TLS-Erweiterung im RFC6066: http://tools.ietf.org/html/rfc6066

BTW: Hast du eine statische IP, an der das QNAP hängt?

Gruß vom subitus

Hallo mcflyy,

was immer du damit machen willst:

/mnt/ext/home/httpd/cgi-bin/images/cmp/login_perview_1.jpg
/mnt/ext/home/httpd/cgi-bin/images/cmp/login_perview_2.jpg
...

Gruß vom subitus

Hallo,

das Posten einer IP-Adresse reicht bei Netzwerkproblemen in der Regel nicht aus, relevant ist stets die Angabe der Subnetz-Maske.
Zwar mögen alle Netzwerkteilnehmer physisch miteinander verbunden sein, direkt miteinander kommunizieren können sie nur, wenn sie im selben Subnetz liegen (andernfalls verbindet ein Router die unterschiedlichen Netze).

Typischerweise ist 192.168.x.x ein Klasse-C-Netz mit der Subnetzmaske 255.255.255.0. Bei allen Teilnehmern sollten dann die ersten drei Zahlen der IP-Adresse gleich sein.

192.168.2.x und 192.168.10.x sind unterschiedliche logische Netzwerke, unter der Annahme eines Klasse-C-Netzes!

Weitere Begrifflichkeiten:
DNS: Namensauflösung - i.d.R. reicht hier die Angabe des Routers aus, es können weitere Teilnehmer DNS-Dienste bereitstellen.
Gateway: Das Routing ins Internet - für eine interne LAN-Kommunikation nicht notwendig, IP-Adresse des Routers
DHCP: vergibt IP-Adressen (und damit verbundenene Parameter wie Subnetz, DNS etc) automatisch. In der Fritzbox kann man Geräten eine feste DHCP-Zuordnung vergeben, sodass bspw. ein NAS trotz DHCP unter der selben IP-Adresse ansprechbar ist.

Die weitere Vorgehensweise:
Poste die IP-Infrastruktur deines Netzwerkes (IP-Adressen, Subnetzmasken, DHCP, DNS) von allen relevanten Teilnehmern (Router, NAS, PC).

Gruß vom subitus

siehe auch hier:http://forum.qnapclub.de/viewt…&t=24030&start=30#p172746

Hallo Schmidder,

mal etwas ausführlicher... 8-)

Prüfe mal den Inhalt deiner crontab mit:

crontab -l

Da sollte das nächste Shutdown und das nächste Power-On-Ereignis stehen, bspw.:

# m h dom m dow cmd0 1 * * 4 /etc/init.d/poweroff0 9 * * 5 /etc/init.d/startup

Zudem ist der Inhalt von schedule_boot_setting interessant:

cat /etc/config/schedule_boot_setting

Diese Datei enthält die Konfigurationen, die von der Admin-Oberfläche gesetzt und aus der die crontab-Einträge erzeugt werden.

Liste parallel dazu die Konfiguration deines Zeitplans im Admin-Panel auf (screen dump).

Letztendlich bewirkt ein Alarm-Eintrag der RTC den Start des NAS:

cat /proc/acpi/alarm

bzw.

cat /proc/driver/rtc

Die QNAP-Skripte sichern den Inhalt des letzten RTC-Alarms:

cat /etc/config/rtc_last_save

--

[Allgemein]
Im Zusammenhang mit der RTC und dem Wakeup-Alarm gibt es mehrere (viele!!) Fehler - nicht unbedingt nur ein QNAP-Problem.

In einigen Fällen "verholpert" sich irgendwann die RTC, dann hilft eine "Stromunterbrechung", um die RTC-Peripherie/ RTC-Alarm zurückzusetzen. In anderen Fällen funktioniert die RTC auf den ARM-Controller-Die schlichtweg nicht. Dies ist einer der Gründe, warum eigentlich jeder Systemdesigner (so auch ich) einem ARM-Linux-System eine externe RTC spendiert, das weiss auch QNAP ;).

Das Wakeup-Problem der ARM-basierten QNAPs ist wohl ein "Eigenes". Im englischen Forum wird berichtet, dass manchmal NACH einer Stromunterbrechung das Wakeup nicht funktioniert (also genau umgekehrt zum ersten Workaround). Dies KANN eine Hardwarelimitierung sein oder ein SW-Bug. Also ein bisschen testen: QNAP starten, Zeitplan einrichten und speichern, herunterfahren & warten. Währenddessen die o.g. Dateien regelmäßig studieren!

Es ist nicht unmöglich, dass die Hardware fehlerhaft ist, aber es muss nicht die Begründung dafür sein. Selbst bei der bereits reklamierten Hardware muss nicht zwingend ein Hardwarefehler vorgelegen haben, der durch einen Platinentausch hätte behoben werden können, es sei denn, QNAP hätte das Hardwaredesign geändert. Aus meiner Erfahrung nach kennt sich nur QNAP-Taiwan mit "speziellen" Fehlern hinreichend gut aus. Viele "Techniker" wechseln einfach die Platine und hoffen, das Problem ist damit behoben. Das ist nicht QNAP-typisch, sondern betrifft die ganze Branche.

--

Was im Zusammenhang mit QNAP leider häufig auftritt ist, dass Firmwareupdates nicht sauber durchlaufen. Es gibt eine Vielzahl von Skripten und Konfigurationen, die im Laufe der Zeit etwas voneinander abweichen, sodass theoretisch viele Kombinationen entstehen, welche nicht alle sauber durch ein Update migriert werden (können). Manchmal hilft es daher auch, mit einer jungfräulichen Platte das System sauber aufzusetzen und zu prüfen, ob das Problem noch besteht.

Gruß vom subitus

GorillaBD:
Je nach individueller Systemumgebung (welche Systeme treffen aufeinander - exakte Firmwarebuilds, Anzahl und Reihenfolge vorangegangener Updates, usw.) kann es sein, dass der Dienst sogar sauber läuft - was aber nach Analyse des Fehlers eher Zufall sein dürfte. Von v3.7.x nach v4.02 wurde einiges im RTRR-Dienst mehrfach verändert und bereinigt. Dabei hat man aber die Regeln der Abwärtskompatibilität leider durchbrochen (man muss auch notfalls alte Fehler "mitschleifen" ). Man hat mir bestätigt, dies nicht hinreichend mit älterer FW getestet zu haben, daher habe ich QNAP in mehreren nächtlichen Sitzungen die Möglichkeit gegeben, das Problem auf meiner Maschine zu untersuchen. Damals "versprach" man mir, ernsthaft über eine gefixte 3.x-Firmware nachzudenken (woran ich allerdings nicht glaube - siehe Problematik Produktmanagement).

Immerhin hat man das Performanceproblem des QTS4-AJAX-Frameworks aufgegriffen und hoffentlich auch die berichteten Leaks...

Ich hätte nichts dagegen, wenn QNAP die Quellen der v3.x vollständig freigeben würde. Ich hätte einige Ideen, die den Weg in die FW finden würden... 8-)

Gruß vom subitus

Dinosaurier:
Der RTRR-Bug wird sichtbar, wenn auf einem QNAP-System mit einer 3.x-Firmware ein RTRR-Job eingerichtet werden soll, bei der ein lokaler Ordner mit einem Remote-Ordner per Zeitplan synchronisiert werden soll. Während der Konfiguration/ Einrichtung im Wizard klappt alles wie beabsichtigt und sieht fehlerfrei aus. Sobald dieser Job erstmalig (i.d.R. direkt nach der Erstellung) ausgeführt wird, tritt ein Fehler auf: Der RTRR-Dienst interpretiert die eingestellten Verzeichnispfade des Remote-Systems als Pfadangabe eines externen Device - welches natürlich nicht existiert. Da die 4.x-Binaries des Backup-Dienstes mit neuen Bibliotheken übersetzt wurden, kann man die Binaries auch nicht einfach austauschen.

Daher kann der RTRR-Dienst nicht genutzt werden, wenn:
- auf dem Quellsystem (RTRR-Master) eine 3.x-Firmware läuft
- auf dem Zielsystem eine 4.x Firmware läuft
- RTRR mit Scheduling (Zeitsynchronisation) verwendet werden soll

Auswege:
(a) RTRR-Rollentausch der QNAP-Systeme (das 4.x-System führt die RTRR-Synchronisation durch)
(b) RTRR via FTP
(c) RSYNC verwenden

Wenn man bedenkt, dass es durchaus aufwändig sein kann, die Infrastruktur ständig umzustellen, um Workarounds für vorhandene und neue Bugs zu finden (ich synchronisiere mehrere lokale und getunnelte QNAPs und Webserver regelmäßig), bleibe ich lieber bei einer funktionierenden Firmware und kann mich auf meine Konfiguration verlassen.

Hoffe, geholfen zu haben.
Gruß vom subitus

Der RTRR-Dienst ab QTS4.x ist mit dem RTRR-Dienst von 3.8 und älter nicht mehr 100% kompatibel. QNAP arbeitet seit über 6 Monaten daran.

Gruß vom subitus

BTW: Der OpenSSL-Bug ist bei den o.g. QNAP-Diensten das geringste Problem :-/

Gruß vom subitus

Hallo Schmidder,

hängt dein Gerät an einer USV oder permanent am Netz?

Einige Benutzer berichten, dass der Zeitplan wieder funktionierte, nachdem die Netzspannung für einige Minuten unterbrochen wurde.
Es ist bekannt, dass einige Echtzeituhren (RTC) der ARM-Serie nicht ganz fehlerfrei sind...

Gruß vom subitus

Zitat von "Dinosaurier"

Mich hat jedenfalls das immer noch nicht beeendete Drama QTS4 recht nachdenklich gemacht.

Ich kann daher nur anraten, regelmäßig Kontakt mit QNAP aufzunehmen und den Jungs und Mädels auf die Füße zu treten. Die Entwickler sind meiner Erfahrung nach sehr gewillt etwas zu verbessern - aber auch QNAP-intern herrscht nicht unbedingt Friede-Freude-Eierkuchen was die Produktphilosophie angeht. QTS4 wurde und wird dort genauso heiß diskutiert wie hier im Board. Erst wenn man das Produktmanagement überzeugt hat, dass der Umsatz nicht ausschließlich mit Neukunden generiert wird, sondern vielfach eher Stammkunden hochpreisige Neugeräte mit 6+ Slots erwerben und denen klar wird, was diese Anwenderkreise wirklich interessiert, werden die Prioritäten wieder stärker in Richtung Zuverlässigkeit, Stabilität und Basisfunktionalität verschoben.

Für den Erstkontakt gibt es mittlerweile einen funktionierenden Helpdesk: http://helpdesk.qnap.com/

Aus meiner Erfahrung lohnt sich der Kontakt an QNAP Deutschland nicht. Dort scheint man nur die Hochglanzprospekte einiger Produkte zu kennen - nicht aber die Produkte im alltäglichen Einsatz.

Der Mitbewerber S****** hat auch seine Schwächen. Grundsätzlich kann man sagen, dass es keine perfekte All-In-One-Lösung am Markt gibt. Es bleibt immer ein Kompromiss, den man bereit sein muss einzugehen. Andernfalls muss man sich einen eigenen Server aufsetzen - mit der Virtualisierungstechnik ist solch ein Server sehr gut administrierbar.

Gruß vom subitus

Hallo,

ich möchte mich nicht den Kraftausdrücken einiger Vorschreiber anschließen, sehe es aber auch nicht so gelassen, wie diejenigen, die meinen, sie hätten nie Probleme nach Firmwareupdates gehabt. Es ist nicht selten, dass einige Benutzer Funktionen verwenden, welche anderen Benutzern völlig fremd sind. Wenn bspw. eine Echtzeit-Synchronisierung unter 4.x in bestimmten (heterogenen) Umgebungen nicht funktioniert, kann man dies nicht wegargumentieren.

Die v4.x-Versionen bringen nicht wirklich nennenswerte Vorteile gegenüber den stabilen 3.7.x-Versionen - wenn man mal von den Multimediafeatures absieht. So ist der Dateimanager unter 4.x zwar endlich akzeptabel, eine AjaXplorer/ Pydio-Installation kann er aber nicht ersetzen. Das Plugin-Handling (neudeutsch Äpp) ist zwar schicker, war aus meiner Sicht unter 3.7/ 3.8 schon akzeptabel. Stabilitätsverbesserungen sind kaum zu erkennen - von div. Bugfixes mal abgesehen.

4.x bringt leider eine ganze Latte neuer Bugs mit (meine Liste an QNAP war zwei Seiten lang), das Ajax-Framework ist auf Low-Performance nicht ausgelegt (ARM11/ Cortex oder Intel-Atom-Prozessoren von Tablets/ Netbooks haben ernsthafte Probleme) und ist sehr buggy. Einige Dienste sind ab der v4.x nicht mehr 100% kompatibel mit 3.x-Versionen (vgl. RTRR-Bug), der Kernel ist weiterhin veraltet, Samba mächtig verstaubt und Sicherheitslecks ungepatcht und neue Leaks im Framework hinzugekommen.

Alles in Allem bleibt mein Fazit nach (sehr) langer und intensiver Testphase sowie vielen Sessions mit den Entwicklern in Taipeh/ Taiwan: Version 4.x kommt nicht auf meine Produktivsysteme und ich kann es weiterhin nicht empfehlen. Wenngleich mir versichert wurde, die berichteten und teilw. vorgeführeten Bugs und Leaks ernstzunehmen. Bleibt abzuwarten, was kommen wird...

Gruß vom subitus

Zitat von "bifbaf"

Naja ich hab ja ein RAID 5

Dazu fällt mir ein:
Ich habe vor einigen Jahren in einem kleinen RZ einen Storage-Server aus den Sumpf ziehen dürfen, nachdem die Admin's ratlos vor den Bildschirmen und Festplattenrack saßen und es nicht fassen konnten, dass alle (!!) Festplatten gecrasht sind (es war ein sehr heißer Sommertag vorausgegangen und die Klimaanlage fiel aus). Die Argumentation damals lautete: "Wir dachten, wir haben doch RAID 15"...

RAID bietet absolut keine Datensicherheit. RAID dient der Erhöhung der Ausfallsicherheit (wenn Storagedienste rund um die Uhr zur Verfügung stehen müssen) oder der Performanceerhöhung oder eine Kombination aus Beidem.

Gruß vom subitus

Auf welche Version willst du umstellen? Auf QTS4? Warum? Funktioniert etwas nicht? Oder ist es reine Neugier?

Möglicherweise weisst du noch garnicht, wie glücklich du momentan sein kannst

Gruß vom subitus

Das bekannteste fritz.box-Mod nennt sich freetz. Dort gibt es ein Modul wol-cgi, welches eine Webseite zur Verfügung stellt, mit der ein WOL-Request an das gewünschte Device verschickt werden kann. Vorteil: Man muss nicht die Wartungs- und Konfigurationsseite der fritz.box public machen, um an die WOL-Funktion der Box zu kommen.

Um Internetpakete zu sniffen, die URL http://fritz.box/html/capture.html aufrufen und sich dort mit dem Administrationspasswort der fritz.box einloggen. Unter "Internetverbindung" den Start-Button betätigen, anschließend startet der Mitschnitt, bis der Stopp-Button betätigt wird. Der Browser generiert ein Download-Fenster, dort den Speicherort auswählen, wohin der Mittschnitt abgelegt werden soll. Solange das Capturing nicht gestoppt wird, sendet der Browser die Log-Daten an die ausgewählte Datei. Internetlogs nicht zu lange laufen lassen, da sie sehr groß werden können. Sobald das NAS aufwacht, kann der Mitschnitt beendet werden.

Wenn der Mitschnitt beendet ist, kann man die Datei mit Wireshark (vormals Etherreal) öffnen und auswerten, bspw. entsprechende Filter setzen ("Expression" -> WOL eintippen -> ...).

Gruß vom subitus

Glückwunsch!

Tipps für das Firmwareupdate:
- Automatisches Update abschalten
- Release-Note der neuen Firmware gründlich studieren: Lohnt sich das Update für mich?
- Etwas Gedult üben und Andere die Firmware testen lassen
- Vor dem Update: Aktualität des letzten Backups prüfen - Arbeitsordner wie Web oder Multimedia sowie Datenbanken nicht vergessen.
- Konfiguration der aktuellen Firmware sichern.
- Neue Firmware herunterladen und sichern.
- Firmwareupdate über das Admin-Interface anstoßen.

_____
EDIT:

Da war jemand schneller Und dann auch noch im Prinzip die selbe Aussage

Gruß vom subitus

Ich würde mir die Mühe machen und mal eine Platte am PC komplett löschen, d.h. alle Partitionen entfernen und formatieren, und anschließend nur mit dieser Platte das NAS starten und neu aufsetzen. Die "Formatierung" des NAS während der Initialisierungsprozedur entfernt eben nicht die alten Konfigurationspartitionen der Platte, sodass das erneute Aufsetzen des Systems immer wieder scheitert: Das NAS findet trotz Formatierung eine alte Konfiguration und baut darauf auf.

Ich habe für solche Aufgaben einen externen USB-SATA-Adapter. Kann ich nur weiterempfehlen, da man mal schnell eine Platte klarmachen kann, selbst wenn auf die Schnelle nur ein Laptop o.ä. zur Verfügung steht oder man nicht jedes Mal den verkabelten PC auseinanderpflücken will.

Viel Erfolg!

Gruß vom subitus

Zitat von "biboca"

[..] wozu dann noch PowerLAN.

Irgendwo muss der ganze Ökostrom schließlich hin... :mrgreen:

Gruß vom subitus

Woher die Emotionen?

Zitat von "Eraser-EMC2-"

Das stelle ich nicht in Frage. [..]

Es wird doch nicht behauptet, dass du es in Frage stellst? :roll:

Es bleibt bislang eine Vermutung, dass jemand den WAN-Port 9 mit Wakeup-Requests überflutet. Nur weil Port 9 WAN-seitig geöffnet ist, heisst es noch lange nicht, dass es auch die Ursache ist (vgl. Kausalitätsprinzip). Um dies zu verifizieren, könnte der Threadstarter den Paketsniffer der fritz.box anwerfen (http://fritz.box/html/capture.html) und auf magische Pakete Ausschau halten, die aus dem Internet kommen.

Zitat von "Eraser-EMC2-"

Damit es nicht mehr geschieht, müssen die Portweiterleitung zum NAS deaktiviert werden, [..]

Um Wakeups aus dem Internet auszuschließen: Einverstanden Alternativ könnte man WAN-seitig den Port verschieben.

Zitat von "Eraser-EMC2-"

[..] somit bietet ein VPN die einzige Möglichkeit, das WoL vom Intermet zu trennen ohne die Funktionseinbuße.

Man könnte aber auch ein WOL-Mod auf der fritz.box installieren.

Gruß vom subitus