Beiträge von subitus

    Zitat von "biboca"

    Die DLAN-Geräte müssen an Steckdosen mit gleicher Phase angeschlossen werden.

    Sie müssen nicht unbedingt , aber sie sollten am selben Außenleiter betrieben werden. Entscheidend ist die Höhe der hochfrequenten Dämpfung zwischen den Außenleitern bzw. die Güte und Höhe des Übersprechens. Diese Problematik ist aber hinfällig, wenn beide Adapter an der selben Steckdose betrieben werden (s.o.).


    Powerline-Adapter sind naturgemäß ziemlich anfällig für leitungsgebundene EMV (Elektromotoren, Schaltnetzteile, Trimmer, ... ) und stellen zugleich eine starke EMV-Quelle dar, welche durch die Elektroinstallation (=Antenne) nicht leitungsgebunden bleibt.


    Es ist durchaus möglich, dass ein Powerline-Adapter eines anderen Herstellers oder eine andere Gerätegeneration in der selben Konstellation funktioniert, bspw. durch die Verwendung anderer Modulationfrequenzen oder -Verfahren, bessere (adaptive) Kerbfilter und bessere (angepasste) Auskopplung usw.



    Gruß vom subitus

    Zitat von "Eraser-EMC2-"

    So wie ich geschrieben habe, liegt sein Problem an der Portweiterleitung des Ports 9 in der FritzBox,
    da so jeder sein NAS aus dem Internet wecken kann.

    Momentan ist das (unser beider) Vermutung. Die genaue Konstellation ist freilich unklar.


    Zitat von "biboca"

    Warum das NAS aufgeweckt wurde, war bereits aufgeklärt [...]

    s. o.

    Zitat von "biboca"

    [..] es ging in der Folge um eine Lösung, das NAS ohne Portweiterleitung aufzuwecken.

    Sehr löblich :D Aber dazu braucht Erazor2k11 kein VPN einrichten. So wie ich es verstanden habe, hat er in der fritz.box die Funktion bereits aktiviert, welche das NAS automatisch starten lässt, wenn ein Zugriff darauf stattfindet. Das funktioniert bei mir vorzüglich :)


    Warten wir doch erst mal ab, bis Erazor2k11 sich geäußert hat, bevor es zu weit abdriftet... 8-)



    Gruß vom subitus

    Zurück zum eigentlichen Thema: Der Threadstarter hat eigentlich kein Problem mit dem Aufwecken des NAS, sondern damit, dass das NAS ständig aufgeweckt wird. VPN ist schön und toll (ich nutze es regelmäßig), aber nicht für alle interessant oder geeignet. Lassen wir also Erazor2k11 sprechen, was er will. 8-)


    Erazor2k11:
    Wie hast du bislang das NAS aus dem Tiefschlaf geholt? Über die Weckfunktion der fritz.box, über ein fritz-Mod, via Magic-Paket innerhalb des VPN oder über ein WAN-seitiges Serverskript?



    Gruß vom subitus

    Du musst an den Porteinstellungen des QNAP für gewöhnlich nichts ändern. Richte einfach in der fritz.box eine Portweiterleitung von 443 WAN-seitig auf 8081 LAN-seitig ein:


    Zitat

    xxx.noip.org:443 -> fritz-box -> QNAP:8081



    Grß vom subitus

    Zitat von "Krejci"

    Wenn ich aber meinedomain.no-ip.org:8081 eingebe, bekomme ich die Meldung das ein Zertifikatsfehler vorliegt?! [..] Kann/Muss ich ein Zertifakt erstellen? Oder was kann ich dagegen machen?

    Wenn du mit der Meldung leben kannst, dann nicke es ab und alles ist in Ordnung. Die meisten Browser werden dich nicht weiter mit einer Fehlermeldung nerven. Wenn du nicht damit leben kannst, musst du ein Zertifikat für die gewünschte (Sub)Domain erstellen und signieren lassen.


    Zitat von "Krejci"

    Außerdem versuche ich verzweifelt, über den no-ip account das so zu konfigurieren, das ich nicht immer den port 8081 hinten anhängen muss. Ist das irgendwie möglich? Meine FritzBox kann ich via SSL und dem no-ip domain ohne port anzuhängen erreichen!

    Jede IP-Kommunikation verwendet eine Port-Nummer. HTTP-Verbindungen nutzen implizit Port 80 und HTTPS-Verbindungen Port 443. Wenn du eine SSL-Seite aufrufst, ohne einen Port anzugeben, macht dies der Browser für dich (implizit). Wenn du einen anderen Port für die SSL-Verbindung benutzen willst, musst du ihn explizit angeben. Da pro IP-Adresse ein und der selbe Port logischerweise nur einmal benutzt werden kann und dir SSL-Seite bereits von der Fernwartungsseite deiner fritz.box genutzt wird, musst du für die QNAP-SSL-Seite einen abweichenden SSL-Port verwenden und daher explizit angeben.


    Lösungsvorschläge:
    (1) Du gibst den SSL-Port der QNAP-Seite weiterhin explizit an :)
    (2) Du legst die Fernwartungsseite deiner fritz.box nicht mehr im WAN offen (was sehr zu empfehlen ist) und nutzt stattdessen den freigewordenen SSL-Port für das QNAP.
    (3) Du stellst eine unverschlüsselte Verbindung zu dem QNAP her unter Verwendung von Port 80.



    Gruß vom subitus

    Die Anschlüsse am Adapter ist (wahrscheinlich) unerheblich, da es sich um einen Switch handeln wird.


    Ich habe überlesen, dass du das NAS anpingen kannst, damit ist die IP-Ebene in Ordnung.


    Wie weit sind die Power-LAN-Adapter auseinander?
    Gibt es mit anderen Geräten Verbindungsprobleme am Adapter?
    Haben die Adapter einen MAC-Filter?


    Mögliche Ursachen gibt es viele....



    Gruß vom subitus

    Hallo Fred,


    ich kenne den devolo dlan 500 Adapter nicht - spannt er zwei getrennte Netzwerke auf? In diesem Fall könnte es an der Netzwerkkonfiguration liegen.


    Der QFinder findet das NAS nicht auf der IP-Ebene!



    Gruß vom subitus

    Du hast dir zwar die Mühe gemacht, die IP-Adresse in der Adresszeile des Browsers unkenntlich zu machen, aber die Tab-Beschriftung vergessen ;)


    Was kommt im Browser für eine Fehlermeldung?
    Kann die Seite nicht gefunden werden -> dann stimmt die Portweiterleitung oder WAN-IP nicht -
    oder bleibt das Fenster auch leer, nachdem der Browser fertig ist mit Laden -> ein häufiges Problem mit manchen Browsern + Addons. Hast du jemanden im Bekanntenkreis, den du darum bitten kannst, den Zugriff über die WAN-IP und den MyCloudNAS-Dienst mal zu testen. Ich vermute, dass es an deinem Browser (Browser wechseln, Addons deaktivieren) oder Rechner (Firewall oder Defense-Systeme temporär deaktivieren oder über einen anderen Benutzeraccount des Rechners testen) liegt.


    Logge dich bitte vor den Tests von deinem NAS aus, um den Login-Screen zu erhalten.
    Nach dem LogIn scheint es eine kritische Stelle zu geben, bei der ein AJAX-Fragment geladen wird, welches weiteren Code des GUI-Frameworks nachlädt. Dies schlägt manchmal fehl.



    Gruß vom subitus

    Wie Eraser-EMC2 es schon vermutet, kann das WOL-Request auch aus dem Internet kommen. Daher der Test mit der unterbrochenen Netzwerkverbindung.


    Solltest du Port 9 WAN-seitig auf Port 9 LAN-seitig weiterleiten, weil du das NAS von unterwegs aus aufwecken willst, könntest du den WAN-Port auch auf eine andere Port-Adresse verschieben und einfach das Wakeup-Skript entsprechend anpassen.



    Gruß vom subitus

    1. Dem NAS eine statische IP-Adresse vergeben (ist zu ca. 25% der Fehler).


    2. Möglichst viele Fehlerquellen ausschließen, d.h. öffnet sich die gewünschte Seite(n) im lokalen Netz?
    Wenn ja, weiter mit 3.


    3. Die vollständige URL notieren - Protokoll, URL-Pfad, Portnummer.


    4. Die externe IP-Adresse (WAN-IP) ermitteln (bspw. hiermit: http://forum.qnap.com/mywanip.php) und die IP-Adresse des NAS mit der WAN-IP ersetzen, sowie ggfs. die WAN-Ports mit den LAN-Ports ersetzen. Häufig wird falsch gemacht, dass das falsche Protokoll (HTTPS statt HTTP) verwendet wird und damit die Weiterleitung ins Leere läuft.
    Öffnet sich die gewünschte Seite? Wenn nein: Ports im Router überprüfen, Firewall und Defense-Systeme temporär abschalten (häufiges Problem), etc.pp.


    5. MyCloudNAS erneut konfigurieren und testen. Alternativ zu MyCloudNAS kann man sich bspw. bei NoIP.com eine dynamische Adresse besorgen und im NAS bzw. Router hinterlegen.



    Wie bereits beschrieben kann es vorkommen, dass trotz aktiviertem UPnP nicht alle Ports geöffnet sind. Da UPnP ohnehin ein Einfallstor ist, rate ich dazu, die Portweiterleitung von Hand zu setzen und UPnP nicht zu nutzen.



    Gruß vom subitus

    Ok, aktiviere WOL und ziehe mal das Netzwerkkabel und fahre das NAS herunter. Wacht dann das NAS auf?


    Nicht dass ein Skript dein Gerät ständig aufweckt - möglicherweise der Router. Wenn ich mich noch korrekt erinnere, kann bspw. die fritz.box automatisch Geräte aufwecken, wenn darauf zugegriffen wird, diese aber abgeschaltet sind.


    Nutzt du den Energiezeitplan?



    Gruß vom subitus

    Was meinst du mit "NUR Webserver aufsetzen"? Der Webserver ist in die Firmware integriert. So wie es scheint, läuft der Webserver bei dir vorzüglich - die Fehlermeldung wurde schließlich auch vom Webserver ausgeliefert, weil es ihm so befohlen wurde. :?


    Du hast die Webapplikation hoffentlich in einen eigenen Unterordner gepackt?


    ____
    Edit:
    Wahrscheinlich wird von einem atrium-Skript eine Weiterleitung auf die Administrationsseite ausgelöst. Häufig geschieht dies, wenn die selbe IP-Adresse an ihrem SSL-Anschluss aufgerufen wird.



    Gruß vom subitus

    nuggy:
    Nichts für Ungut, aber wirklich einfacher als das hier im Forum befindliche HowTo ist deine Anleitung nicht unbedingt - und auch nicht wirklich aktuell. Wozu noch Pre-1.6-kompatible Datenbanken (mit allen Nachteilen) verwenden?


    Aktuell liegt die Version 1.7.7-x vom 10.10.2012 in den Optware Paketquellen - für ARM und Intel. Das ist leider auch schon ziemlich veraltet, vielleicht will ja mal jemand den Compiler anwerfen? Neuinstallationen sollten nicht mehr mit Versionen 1.6 und älter erfolgen. Ausführliche Release-Notes liegen hier: http://svn.apache.org/repos/asf/subversion/trunk/CHANGES


    Ein QPKG ist zwar schön, aber nicht unbedingt zielführend, da es sehr unterschiedliche Anforderungen an eine SVN-Installation gibt. Einige Stichworte:
    - Hook-Skripte
    - Skriptsprache (Perl, Python, ...)
    - SVN via svnserve oder via Apache-DAV-SVN
    - Autorisation via SVNAuth, passwd, LDAP, Windows-Logon/ Kerberos oder SSPI
    - individuelle Repository-Regeln
    - ...


    Entweder müsste das OPKG sehr flexibel sein und alle gängigen Anforderungen erfüllen (ich halte dies für unwahrscheinlich, dass sich diese Mühe wirklich lohnen würde), oder man hätte eine Versionskontrolle, die genauso lieblos umgesetzt ist, wie derzeit das Git-QPKG.



    Gruß vom subitus

    Hallo,


    der Freigabeordner Web liegt im Linux-Dateisystem unter /share/Web. Apache kennt aber keine SMB-Freigabeordner, sondern greift direkt auf das Linux-Dateisystem unter Verwendung des Dateisystempfades zu. Pfade, die mit / anfangen, sind immer absolute Pfade, bezogen auf den Dateisystem-Root. Leider verwirrt das Admin-Interface an manchen Stellen, da hier der Wurzel / die Wurzel der Freigabeordner meint.


    Versuche also mal dies:

    Apache Configuration
    AuthUserFile /share/Web/member/.htpasswdAuthGroupFile /dev/nullAuthName "MyLogin"AuthType Basic<Limit GET>require valid-user</Limit>


    Auf Groß-/Kleinschreibung achten!



    Es wird der absolute Pfad aus Dateisystemsicht benutzt - du könntest (nein: solltest) die Datei .htpasswd außerhalb des Web-Roots speichern. In jedem Verzeichnis, in dem eine .htpasswd liegt, sollte mindestens eine .htaccess erstellt werden, welche die Rule

    Code
    <Files .ht*>
       deny from all
    </Files>

    enthält, damit die Datei .htpasswd nicht versehentlich über den Browser ausgeliefert wird. Erfreulicherweise enthält die Apache-Konfiguration diese Rule bereits, aber sicher ist sicher.


    Es wird empfohlen, Passwort-Dateien außerhalb des Web-Roots (htdocs) abzulegen. Leider ist die Standard-QNAP-Apache-Konfiguration nicht sehr praxistauglich, da der Freigabeordner bereits der Web-Root ist. Ich habe meinen Web-Root. nach /share/Web/htdocs verschoben und somit unter /share/Web/ die Möglichkeit, Unterverzeichnisse anzulegen, die bspw. Logs, Download-Content, Datenbanksicherungen und auch Passwort-Dateien enthalten, welche nicht direkt über den Browser (sondern nur über Skripte) abrufbar sind.



    BTW: um den Apache-Log zu aktivieren, müsste man sich per SSH auf das NAS einloggen.



    Gruß vom subitus

    Zitat von "Krejci"

    Ordnerstruktur ist: /web/member

    Bist du dir sicher, dass du den absoluten Pfad /web/... meinst und nicht einen relativen Pfad? Bei mir liegt der htdocs-Ordner in /share/Web.


    Ich denke, Apache findet die Datei .htpasswd nicht: Zunächst wird vom Apache das Login-Request erzeugt und dann wird versucht, die eingegebenen Login-Daten mit denen in der Passwort-Datei abzugleichen. Da diese fehlt, wird eine Fehlermeldung ausgegeben, da die Serveranfrage nicht komplettiert werden kann.


    Tipp: Wenn du viel mit .htaccess arbeitest, empfiehlt es sich, den Apache-Log zu aktivieren und auf Level warn zu stellen. Obiges Problem würde dann mit der eindeutigen Fehlermeldung "Kann Datei .htpasswd nicht finden." o.ä. protokolliert.



    Gruß vom subitus