flicflac's Tipps und Tricks:

Synology-NAS
Anleitung für Konfigurations-Modifikationen

 


NAS

NAS (Network Attached Storage) beziehungsweise NAS-Stationen ist der übergeordnete Begriff für Speicher-Systeme in einem Netzwerk. Hier wird er vereinfachend für die folgenden Produktnamen von Synology verwendet: DiskStation, RackStation und (die frühere) CubeStation. Praktisch alle Produzenten solcher Systeme bieten Speicher-Systeme mit einer mehr oder weniger kompakten Firmware an, die mittels eines Konfigurationsprogramms die Anpassung der Station an die Bedürfnisse der Kunden ermöglichen. Bei Synology heisst dieses Programm DSM (Disk Station Manager); zurzeit ist dessen sechste Version Stand der Dinge.

Um eine solche Station (und insbesondere die Funktionen als Web-, FTP- und PhotoStation-Server) nutzen zu können, sollte der Nutzer einer solchen diese korrekt an seinem Router angeschlossen und eingebunden haben. Dazu gehört, dass
 
- die Station eine fixe IP-Adresse innnerhalb des privaten Netzes des Nutzers erhält (je nach Routertyp kann/muss diese innerhalb/ausserhalb der dynamisch zugeteilten Adressen liegen),
- der Station ein Name (ohne kleine Buchstaben und Umlaute) gegeben wird, damit sie (und alle ihre Gemeinsamen Ordner) sicher innerhalb des privaten Netzwerks analog zu weiteren "Computern" angezeigt werden,
- Datenpakete an Ports der gewünschten Dienste (http, ftp, ...) an die NAS-Station geleitet werden (je nach Routertyp sind auch summarische Angaben möglich),
- alle diese Ports nicht durch eine interne Firewall blockiert werden.

Die Station verfügt dann über eine fixe interne IP-Adresse (also meistens von der Art 192.168.x.y) und wird im Windows-Explorer als Netzwerkstation (mit den Eigenschaften eines Computers) aufgeführt. Stellt jedoch ein Internet-Provider seinem Kunden nicht zumindest eine fixe oder dynamische öffentliche IP-Adresse, sondern einzig eine oder mehrere innerhalb des Provider-Bereichs zur Verfügung, kann der Kunde seine Station Sites nicht selbständig adressieren. Dies ist vereinzelt als Blockade unerwünschter Server so eingerichtet und wirkungsvoller als nur die Sperrung der jeweiligen Ports (Anschlussnummern), die durch die Vergabe zusätzlicher Nummern durch jeden Abonnenten relativ einfach umgangen werden kann.


Konfigurationseingriffe

Der
Käufer einer NAS-Station kann davon ausgehen, dass nach der Inbetriebnahme alle wesentlichen Funktionen ohne grössere Konfigurationsänderungen funktionieren. Hat er zusätzliche Wünsche, kann er sich diese heute meist mittels des Konfigurationsprogramms ohne separate Anleitungen selbst erfüllen. Dies war hingegen in den frühen Versionen des DSM noch nicht so. Da musste man sich mit viel weniger Funktionalität zufrieden geben, oder sich die nötigen Kenntnisse als Server-Programmierer aneignen. Das veranlasste damals verschiedene Server-Kundige Kurzanleitungen zu bekannten Konfigurationsmängel ins Internet zu stellen, die durch kleinere Eingriffe in die Konfiguration von jedem Benutzer auch ohne Vorkenntnisse selbständig ausgeführt werden konnten. So ist denn auch die Urfassung dieser Anleitung im Jahr 2007 entstanden. Konkret ging es um folgende Punkte:
 
- Einrichtung von Telnet
- Bearbeitung von Konfigurations-Dateien mit Windows
- Möglichkeit zur Erstellung von Log-Dateien analog den Log-Dateien bei kommerziellen Hosting-Firmen
- Modifikationen bei den Autoindex-Einstellungen
- Ermöglichung virtueller Hosts (beispielsweise für Sites für Vereine zusätzlich zur eigenen Site des Nutzers)

Im Folgenden soll hier über die Fort- und Rückschritte bis heute bei den Konfigurations-Veränderungen berichtet werden.
 

Einrichtung von Telnet

Wer zusätzlich zu den normal zugänglichen Ordner und Dateien eines Systems auch die internen lesen - oder gar verändern - will benötigt ein entsprechendes Zugangsprogramm. Das dafür altbekannte Telnet muss heute auf der NAS-Station nicht mehr wie früher separat nachgeladen werden. Nach seiner Aktivierung im Systemsteuerungsbereich "Terminal & SNMP" von DSM kann es auf dem PC im Kommandozeilenmodus (also unter DOS) über die Windows-Eingabeaufforderung ausgeführt werden. Dazu ist "telnet" und die IP-Adresse einzutippen. Ab Windows7 funktioniert Telnet allerdings nur noch, wenn zuvor in der PC-Systemsteuerung unter Programme und Funktionen in Windows-Features aktivieren oder deaktivieren der Telnet-Client ebenfalls manuell aktiviert wurde.

Telnet sollte allerdings ohne besondere Schutzmassnahmen nicht verwendet werden. Eine davon ist die mittels DSM "Sicherheit" ermöglichte Blockierung von IP-Adressen, über die innert einem bestimmten Zeitraum mehrmals ein Zugriff unter Verwendung eines falschen Passwortes versucht wurde. Verwendet man die Standardeinstellung (5 Minuten / 10 Fehler) werden bei intensiven Hackerattacken mehrere Dutzend Blockierungen pro Tag ausgeführt.

Wer aber einen komfortableren Telnet-Zugang oder gar ein neueres Zugangsprogramm besitzt, kann natürlich Lesen und Modifikationen auch über solche ausführen. In der vorliegenden Anleitung wird aber ausschliesslich der einfache Telnet-Zugang beschrieben. Dies aber nicht allein darum, weil die Aktivierung von SSH nicht immer gelingt und dann meist ein Profi hinzugezogen werden muss. Sondern auch darum, weil die Nachfolgeprodukte und alle ihre Möglichkeiten in andern Anleitungen gut beschrieben sind.

Nach dem Eintippen von

telnet 192.168.x.y

meldet sich die Station mit dem im DSM eingetragenen Rufnamen und verlangt in der Folge dass Eintippen eines Benutzernamens. Dieser kann nun aber nicht mehr wie früher root heissen; vielmehr muss bereits seit einiger Zeit der Name eines Administrators der Station (also meist admin) und anschliessend auch dessen Passwort eingetippt werden.

Für alle weiteren Eingaben sind dann (auch bei SSH) Unix/Linux-Befehle zu verwenden. Da aber nur wenige wirklich erforderlich sind, kann hier auf eine Beschreibung aller übrigen verzichtet werden. Im Internet sind aber umfangreiche Beschreibungen abrufbar. Hier sei somit nur erwähnt, dass man mit
 
sudo -i sich mit zweimaligem Eintippen des Passwortes die root-Berechtigung erteilen kann
cd / in den Grund-Ordner wechseln kann
cd (Ordner, -folge) in (Unter-)Ordner samt Folge-Ordnern wechseln kann
cd .. in den nächsthöheren (Unter-)Ordner zurückwechseln kann
dir oder ls das Verzeichnis des aktuellen (Unter-)Ordners anzeigen kann
cp (von/nach) Datei(en) kopieren kann (bisherige Zieldatei wird überschrieben)
mv (von/nach) Datei(en) verschieben kann (Ursprungsdatei wird gelöscht, Zieldatei überschrieben)
rm (Name, *) Datei(en) löschen kann
rmdir (Name) einen leeren (Unter-)Ordner löschen kann
mkdir (Name) einen Unterordner neu erstellen kann
chmod xyz (Name, *) Lese- (4), Schreib- (2) und Ausführungs- (1) Berechtigung für Ordner und Dateien erteilen kann (x, y, z für System, Gruppe, Benutzer, je kumulativ von 0 bis 7)


Bearbeitung von Konfigurations-Dateien mit Windows

Telnet (sowie bereits auch seine verbesserten Nachfolger) sind bei den heutigen Anwendern nicht mehr besonders beliebt. Und auch DOS, Unix und Linux sind nicht jedermanns Sache. So wird immer mehr die Zugänglichkeit solcher Systeme über Windows gefordert. Die offizielle Aufrüstung solcher NAS-Stationen mit Software von Windows würde aber ihren Anschaffungspreis so ungefähr verdoppeln und dürfte wohl kaum je verwirklicht werden. Aber es gibt dennoch Möglichkeiten, zumindest für einfache Konfigurationseingriffe auf Windows nicht verzichten zu müssen.

So lässt sich beispielsweise der eigentliche NAS-Root-Ordner mit root-Berechtigung durch Eintippen des Bind-Befehls unter Telnet (oder Nachfolger) mit

mount --bind / /volume1/root

in den zuvor unter DSM (nur für den Administrator !) zu schaffenden Gemeinsamen Ordner /root/ m
ounten. Das Mounten muss aber nach jedem Wiedereinschalten der Station wiederholt werden. Die für den Betrieb der Webstation wesentlichen Dateien sind unter /usr/local/etc/apache2x/... (x= 2 oder 4 entsprechend der Unter-Version des Apachen) zu finden. Man muss sich aber bewusst sein, dass sich nicht alle unter Windows sichtbaren Dateien dann auch tatsächlich öffnen und ändern lassen, da die root-Berechtigung ja nicht mitkopiert wird. Wer beispielsweise in einer geschützten conf -Datei etwas ändern will, muss diese aus dem vorgenannten Ordner mittels Telnet/SSH in einen offenen Ordner herunterladen und dann auch in der gleichen Weise nach einer allfälligen Änderung wieder hochladen.

Komfortabel lassen sich dann aber doch alle durch das System oder den Benutzer freigegebenen Konfigurations-Dateien mit dem Windows-Explorer modifizieren. Zuvor sollte allerdings jeweils eine Kopie der zu ändernden Originaldatei erstellt werden, damit man nach einem fehlerhaften Eingriff nicht die ganze Station auf den Werkszustand zurücksetzen muss. Zudem empfiehlt es sich, geänderte Include-Conf 's in einem gesonderten Unterordner (statt in /extra/) zu speichern. Dann muss nämlich nach einem Upgrade des Apachen oder der Virtual-Host-Definitionen nur die eigentliche Konfigurationsdatei (http2x.conf) neu angepasst werden. Es empfiehlt sich, sowohl vom gesonderten Unterordner als auch von der Konfigurationsdatei Kopien in einem separaten Backup-Ordner ausserhalb der Konfiguration zu speichern, da diese Dateien bei Upgrades manchmal gelöscht werden.

Kommt es aber trotz grosser Vorsicht doch einmal zu einem Ausfall der Station (beispielsweise weil man versehentlich die Zugriffsberechtigungen zu /root/ verändert hat), kann diese ohne Löschung der eigenen Dateien einfach auf den Werkszustand (der zuvor verwendeten DSM-Version) zurückgesetzt werden. Man drückt dafür beispielsweise einen Zahnstocher etwa vier Sekunden ins Reset-Loch auf der Rückseite der Station bis zum Pfeifton ab. Dann wartet man höchstens neun Sekunden ohne zu drücken und wiederholt anschliessend das Drücken. Ein weiterer Pfeifton signalisiert den erwünschten Erfolg und zeigt den für den Reload notwendigen Zeitbedarf an. Danach müssen allerdings alle Konfigurationsangaben frisch eingetippt und die Programmpakete neu geladen werden. 

Konfigurations-Dateien für einzelne Komponenten der NAS sind natürlich auch anderswo zu finden. Deren Modifikation sollte aber geübten Modifizierern überlassen werden.
 

Möglichkeit zur Erstellung von Log-Dateien analog den Log-Dateien bei kommerziellen Hosting-Firmen

Frühere DSM-Versionen erstellten für die gespeicherten Internet-Site(s) gar keine Besucher-Fehler- und Besucher-Zugriffs-Dateien. Aktuell werden zumindest die Fehler-Meldungen mit LogLevel error (möglich wären die Levels debug, info, notice, warn, error, crit, alert oder emerg) in die Datei apache2x-error_log abgespeichert. Als Alternative wird als Kommentarzeile (#....) in der entsprechenden Konfigurations-Datei httpd2x.conf der Verzicht auf eine solche Datei mit #ErrorLog /dev/null gezeigt. Es genügt also eine Verschiebung des #-Zeichens an den Anfang der anderen Zeile, wenn keine Fehler-Log-Datei erstellt werden soll.

Genau umgekehrt werden die Zugriffs-Meldungen behandelt. Hier ist der Verzicht auf die Datei der Default-Wert. Wird das #-Zeichen an den Anfang der andern Zeile verschoben, wird eine Besucher-Log-Datei im combined-Modus erstellt.

Wer sich zu einer Anpassung entschliesst, kann diese Dateien auch gleichzeitig umbenennen und/oder diese an einem vernünftigeren Ort (also zum Beispiel irgendwo im normal zugriffsberechtigten /Volume1/...) platzieren. 


Modifikationen bei den Autoindex-Einstellungen

Die erste DSM-Version unterstützte anfänglich keine Index-Seiten für Dateien in Ordnern, die keine "index.html"-Datei (oder gleichwertige) enthalten hatten. Wenig später konnte dies ein Nutzer mit System-Kenntnissen selbst korrigieren, hingegen fehlten noch lange die für "Fancy Indexing" - der für kommerzielle Anwendungen üblichen Darstellungsart - benötigten Icons. Aus dieser Zeit stammt die hier (klicken) immer noch abrufbare Icons-Sammlung, die aber heute eigentlich nur noch zur Demonstration für Text-Einfügungen in Autoindex-Seiten dient. Denn alle andern damaligen Kritikpunkte zu diesem Thema wurden durch Synology eigentlich schon vor einiger Zeit korrigiert.

Heute wird nur vereinzelt noch die Darstellungsart und die Namen für Readme- und/oder Header-Einfügungen kritisiert. Mit den grösseren Hosting-Firmen in der Schweiz seien diese nicht kompatibel. Die daran Schuld tragende Include-Conf-Datei httpd-autoindex.conf kann aber leicht durch das Überschreiben der drei abweichenden Zeilen wie folgt angepasst werden (hier im Beispiel mit bis zu 50 Zeichen für die Datei-Namen):

IndexOptions FancyIndexing FoldersFirst VersionSort NameWidth=50
ReadmeName README.htm
HeaderName HEADER.htm

Passende Einfügungstexte für Readme und Header sind übrigens leicht neu zu erstellen. Der jeweilige Web-Seitengestalter erfasst den Text in einer normalen HTML-Datei und streicht dann vor der Abspeicherung in den gewünschten Ordner noch schnell alle Zeilen vom Beginn bis und mit <body> weg. Dies sollte so von allen Apache-Servern ohne Darstellungsfehler interpretiert werden können. LiteSpeed-Server (beispielsweise die von Cyon) und andere einfachere Web-Server sind zurzeit auch dann überfordert, wenn die beiden Dateinamen wie üblich ohne .htm (also nur README und HEADER) geschrieben werden.


Emöglichung virtueller Hosts (beispielsweise für Sites für Vereine zusätzlich zur eigenen Site des Nutzers)

Die erste DSM-Version erlaubte nur das Hosten einer einzigen Internet-Site im Hauptordner /web/. Viele Nutzer wollten aber schon damals den riesigen Speicherplatz für mehrere Sites (zum Beispiel für Vereine) ausnützen, was nun seit langem unter dem Begriff "Virtual Hosts" auch direkt unter Web Station im Disk Station Manager konfigurierbar ist. Da die Funktion aber früher eher als "Pointing zu Subdomains" zu bezeichnen gewesen wäre, konnte sie die vielfältigen zusätzlichen Möglichkeiten der echten "Name based Virtual Hosts" nicht bieten. Bis und mit DSM-Version 2 konnten solche "echten" Zusatz-Sites mit relativ wenig Konfigurations-Aufwand in irgend einem Ordner der NAS-Station untergebracht werden. Mit den neueren Versionen war der Aufwand aber um einiges grösser geworden. Zudem musste man von lieb gewordenen Zusatzfunktionen (beispielsweise der separaten File Station unter den Port-Nummern 7000 und 7001) Abschied nehmen, was doch noch lange einige Betreuer von Vereins-Sites veranlasste, nicht auf neuere DSM-Versionen upzugraden.

Für neu zu erstellende Sites (ohne nostalgische Funktionen) war aber die eigene Lösung von Synology durchaus empfehlenswert. Allerdings waren anfänglich ausnahmslos alle Sites (Namen frei wählbar) als Unterordner von /web/ anzulegen (eben als Subdomains), was natürlich eine saubere Trennung (zum Beispiel für die Nachführungsrechte mithilfe von FTP) verunmöglichte. Einer der Vorteile ab DSM 6.0-7321 war, dass virtuelle Sites in einer neuen Maske definiert werden konnten, die die Ansteuerung jedes beliebigen Haupt- oder Unterordners als Standort einer eigenständigen Site zugelassen hat. Zudem musste ab dann beispielsweise für HTTPS keine zusätzliche Zeilen mehr geopfert werden. Und auch einzelne andere Eigenschaften konnten ab dieser (oder allenfalls einer späteren) Version ohne Systemeingriffe programmiert werden. Schön wäre es gewesen, wenn man bald darauf auch Alias-Namen, Logs und Error-Seiten so hätte definieren können. Dann wären tatsächlich aus den bisherigen dreissig "Pointing zu Subdomains" endlich ziemlich echte zwanzig "Virtual Hosts" geworden.  

Synology hat aber einen andern Weg eingeschlagen. Mit jedem weiteren Update wurden dem Nutzer neue Hürden für eine eigenständige Nutzung seiner NAS in den Weg gelegt. So wurden immer wieder Dateien umbenannt und/oder in andere Ordner verschoben. Dann waren vorübergehend Unterordner als Site-Standorte wieder nicht mehr konfigurierbar. Konfigurations-Dateien konnten zwar noch angesehen, aber eben nur noch auf Umwegen mutiert werden. In vielen Dateien wurden zudem die Anleitungs-Zeilen weggelassen. Natürlich lassen sich mit den entsprechenden Fachkenntnissen alle diese Hürden ausmerzen. Der Aufwand war aber zeitweise um einiges teurer einzuschätzen, als das Ausweichen auf ein alternatives Hardware-Angebot. Auf so ziemlich allen andern erhältlichen Apache-Servern kann jeder Nutzer grundsätzlich alle Funktionen frei verändern. Vielleicht sind dies ja die Gründe für das schwindende Interesse an der vorliegenden Anleitungs-Seite. Entweder man ist mit dem Angebot von Synology zufrieden, oder man hat auf ein anderes Produkt gewechselt. Somit kann man hier wohl gut auf die bisher gewohnte, detailliertere Anleitung verzichten.

Beibehalten werden hingegen einige grundsätzliche Erläuterungen für Nutzer von Virtual Hosts von Synology und auf andern Web- und FTP-Servern.
 

Adressierung von Internet-Sites mit Domänen-Namen

Wer eine oder mehrere Internet-Sites auf dem Web-Server einer NAS-Station zur öffentlichen Benutzung hosten will, muss eine vernünftige Möglichkeit für die Verlinkung suchen. Steht eine fixe öffentliche IP-Adresse zur Verfügung, kann diese direkt für den Aufruf der Seiten (und auch für andere Dateien) verwendet werden. Bevorzugt man aber einen (oder benötigt man für virtuelle Host unbedingt gar mehrere) Domänen-Namen, muss dafür ein Name-Server vorhanden sein, der Domänen-Namen mit der korrekten IP-Adresse verknüpfen kann. Ein solcher Dienst ist in der Regel kostenpflichtig oder wird allenfalls zusammen mit andern kostenpflichtigen Leistungen auch mal kostenlos (beispielsweise von Hosting-Firmen für deren Kunden) angeboten.

Da in Europa fixe öffentliche v4-IP-Adressen - wenn überhaupt noch - nur sehr teuer erhältlich sind, wird wohl vorderhand anstelle des einfachen Name-Servers meist ein komplexeres Verfahren im Vordergrund stehen. Um ein eigenhändiges Anpassen an die üblichen, sich immer mal wieder verändernden dynamischen IP-Adressen zu umgehen, kann ein spezieller Name-Server verwendet werden, der dies selbständig erledigen kann. Nebst andern Anbietern (darunter auch Synology selbst) betreibt DynDNS seit rund fünfzehn Jahren solche spezielle Name-Server (Über deren Einbindung in Router und NAS-Station orientiert der drittletzte Abschnitt dieser Anleitung).

DynDNS bietet heute keine kostenlosen (früher fünf) Domänen-Einträge mehr an. Zumindest einen kann man durch das Austesten der kostenpflichtigen Version (ohne rechtzeitige Kündigung vor Ende der Testphase werden aber pro Jahr 55$ für das Pro-Abo verrechnet) oder über Hardware-Produzenten - beispielsweise D-Link (hier klicken) - zurzeit immer noch für eine beschränkte Dauer kostenfrei erhalten. Allerdings muss der Top- und der Second-Level des Namens aus einer Liste ausgewählt werden, die ungefähr noch 20 (früher 88) Namen umfasst (also beispielsweise neu "dyndns-work.com" während früher auch ".net" als Top-Level  und auch ".dynalias" als Second möglich war). Erst der dritte Level kann durch den Benutzer selbst ausgewählt werden, sofern nicht ein anderer Interessent den schon früher für sich in Beschlag genommen hat. Jeder Namenseintrag (auch ein im Pro-Abo bezahlter) hat dann die Form: "aaaa.dyndnsname.tld".


"Wildcards"

DynDNS gestattete früher auch beim Gratisangebot die Benutzung des vierten Levels für die Namenseinträge, ohne allerdings eine Aufteilung auf verschiedene IP-Adressen zu ermöglichen. Die entsprechende Option wird "Wildcards" genannt, weil sie auch einen beliebigen (Vor-)Namen in der Form "*.aaaa.dyndnsname.tld" (also beispielsweise für ein voran gestelltes "www.") an Web-Server weitergibt.

Allerdings sind bei Nutzung der aktuellen "Vitual Host"-Lösung von Synology die Verwendung eigentlicher Wildcards nicht vorgesehen. Vielmehr muss stattdessen jeweils eine eigene Zeile für jede zulässige Namenskombination (also beispielsweise "www.aaaa.dyndnsname.tld") in der im Vorvorabschnitt erwähnten Eingabemaske verwendet werden. Durch ein einfache Konfigurations-Änderung (Angabe als Alias-Name) kann dies allenfalls umgangen werden.

Andrerseits verwendet auch Synology den vierten Level, zum Beispiel für den Aufruf der Photo Station (Version 6). Dazu kann einfach "http://beliebigeZeichen.aaaa.dyndnsname.tld/photo/" verwendet werden. Funktioniert dies nicht korrekt, ist in den Ordner /photo/ eine index.htm-Datei einzustellen, die im <head> den Refresher-Befehl

<meta http-equiv="refresh" content="0; URL=/photo/">

enthält Vielleicht gibt es aber dafür später eine einfachere Lösung. Die von Synology empfohlene direkte Adressierung unter Verwendung der IP-Adresse ist in Europa nicht empfehlenswert, da sie eigentlich nur fixe externe IP-Adressen taugt.

 
Weiterleitung von eigenen Domänen-Namen an DynDNS

Über einen normalen Name-Server können eigene Domänen-Namen in der Regel problemlos auch an DynDNS-Namen weitergeleitet werden. So kann man beispielsweise "myname.tld" und/oder "xxxx.myname.tld" auf die durch DynDNS erschlossenen Seiten "aaaa.dyndnsname.tld" oder auch auf einen Unter-Ordner ("aaaa.dyndnsname.tld/xxxx") hinführen. Durch geschicktes Konfigurieren können so auch mehrere unabhängige Sites vorgetäuscht werden, wenn der korrekte Name nicht in der Anzeige der Seiten erscheint. Der gewiefte Internet-Surfer findet aber meist einen Weg um die Verwandtschaft solcher Seiten festzustellen.
 

FTP - Adressierung und Zugriffsbeschränkungen

Alle vorstehend beschriebenen Adressierungsmöglichkeiten gelten bei korrekter Konfigurierung nicht nur für Internet-Browser ("http://__", "https://__"  und "ftp://__"), sondern auch für FTP-Client-Programme und den File Manager. Allerdings führen alle Adressen zum jeweils gleichen FTP-Server. Alle Benutzerkonten sind durch den zuständigen Administrator im Konfigurationsprogramm so einzurichten, dass unerwünschte Zugriffe auf die unter "Gemeinsamer Ordner" gespeicherten Hauptordner gesperrt bleiben. Unterordner sind nicht unabhängig sperrbar.

Der passwortfreien FTP-Zugang kann separat für das Lesen oder Lesen/Schreiben für jeden Hauptordner frei gegeben werden. Zudem lässt sich das Lesen/Schreiben jeweils unter "Erweiterte Berechtigungen" so einschränken, dass weder der Inhalt des Ordners noch die einzelnen Dateien gelesen werden können. Damit kann beispielsweise verhindert werden, dass neu gespeicherte Daten ohne Bewilligung eines Administrators auch gelesen werden können. Wer keinen passwortfreien Zugang einrichten will, kann natürlich auch Benutzerkonten mit veröffentlichtem Passwort schaffen. Dabei ist zu beachten, dass für deren Benutzer die Änderung des Passwortes gesperrt werden sollte.
 

HTTP - Zugriffsbeschränkungen / .htaccess

Hosting-Firmen bieten ihren Kunden vielmals auch die Möglichkeit, HTTP-Zugriffe auf Gruppen von Seiten gleich oder zumindest ähnlich wie für FTP zu sperren. Eine solche generelle Konfigurationsseite besteht aber für die Synology NAS-Station nicht. Der Administrator hat jedoch die Möglichkeit ohne direkten Eingriff in die Konfiguration, Sperren durch Einstellung von ".htaccess"-Dateien in allen Ordnern und Unterordnern selbst zu organisieren. Eine solche, jeweils auch für alle Unterordner gültige, Sperre kann etwa folgendermassen aussehen:

AuthUserFile /volume1/web/.htpass
AuthGroupFile /dev/null
AuthName 'Gesperrter Bereich'
AuthType Basic

<limit GET PUT POST>
require valid-user
</limit>

Gemäss der ersten Zeile gehört zu dieser Datei eine ".htpass"-Datei im web-Ordner (Name und Ordner frei wählbar), die alle berechtigten Benutzer und ihre Passworte enthalten muss, also zum Beispiel für den Benutzer "Micky" mit dem Passwort "Pluto" die Zeile:

Micky:XV1.WNgDFvQxA

Eine gültige Zeichenkombination nach der oben dargestellten CRYPT-Verschlüsselung erhält man beispielsweise durch Benutzung der in der Firmware der Synology NAS-Station integrierten Passwort-Generierungs-Routine, welche sich am einfachsten nach dem Einloggen mit Telnet aufrufen lässt:

htpasswd -ndb Micky Pluto

Sehr Sicherheitsbewusste lassen das "b" weg. Sie erhalten dann statt den bisher üblichen 13 Stellen deren 37 (MDS-Verschlüsselung). Alle ".ht__"-Dateien werden übrigens in den mit einem Browser öffnenbaren Verzeichnissen der Synology NAS-Station bei unveränderter Grundeinstellung nicht angezeigt. Will man ein (oder mehrere) Verzeichnis(se) ganz für die Anzeige sperren, kann man dies in einer bereits bestehenden oder einer neuen ".htaccess"-Datei mit der Zeile

Options -Indexes

tun. Zur Entsperrung der Verzeichnisse für Unterordner muss dort folglich eine Datei mit der Zeile

Options +Indexes

eingefügt werden.

Im Gegensatz zu FTP kann kein Benutzer sein Passwort selbst ändern.

".htaccess"-Dateien können aber heute weit mehr als hier beschrieben. So lassen sich beispielsweise die weiter oben beschriebenen
Modifikationen bei den Autoindex-Einstellungen statt durch eine Konfigurationsänderung auch durch eine Einfügung der dort aufgeführten drei Zeilen in eine ".htaccess"-Datei bewerkstelligen.
 

Nachführung dynamischer IP-Adressen mit DynDNS

Sowohl Synology-NAS (unter Externer Zugriff) als auch die meisten Router ermöglichen mehr oder weniger komfortabel IP-Adress-Updates. In der Folge müssten dann eigentlich nur noch die dafür nötigen Angaben in die Konfiguration der NAS-Station oder des Routers übertragen werden. Die Firmware hätte dann die Aufgabe, DynDNS die jeweils durch den zuständigen Internet-Provider zugeteilte dynamische IP-Adresse mitzuteilen. Selbst der unbegabteste Firmware-Programmierer sollte eigentlich eine solch leichte Aufgabe einwandfrei lösen können.

Die Enttäuschungen für den Anwender beginnen vielfach schon, wenn man versucht mehrere Namen in der von DynDNS geforderten Form (kommagetrennt ohne Zwischenraum) in das Namensfeld einzutragen. Bei DynDNS könnte man so bis zu zwanzig Namen für "Virtual Hosts" in einem Aufwasch nachtragen lassen. Die immer noch bestehenden Gratisnutzer wären heute ja schon mit viel weniger zufrieden, aber die Synology NAS-Station und die meisten Router gestatten nur den Eintrag eines einzigen Namens. Es gibt aber auch Router, die mehrere Namen zulassen, dann aber diese Information nicht oder falsch an DynDNS weiterleiten.

Aber auch andere Pannen sind in Ausnahmefällen noch heute zu beobachten: Router, die die Erstmeldung vergessen; Router, die nach dem Ausschalten oder einer Strompanne nicht überprüfen, ob ein Update nötig ist; oder auch Router, die eine Updatemeldung nicht im Log eintragen (oder wenn sie sie schon eintragen, das Log wegen falscher oder fehlender Authentifizierung nicht per Mail übermitteln können). Und eigentlich müssten Router auch in der Lage sein, ab etwa achtundzwanzig Tagen nach der letztmaligen Änderung einer IP-Adresse selbständig eine Erinnerungsmeldung an DynDNS auszulösen. Denn ohne eine solche Meldung (oder ein Einloggen) kann das Konto mit allen Domänen beim Gratis-Abo von DynDNS (auch ohne gemailte Vorwarnung) nach etwa fünfunddreissig Tagen gelöscht werden. Und damit geht dann auch bei "Alt-Kunden" das Gewohnheitsrecht auf fünf Gratiseinträge definitiv verloren.

Für das problemlose Weiterarbeiten mit "Wildcards" (also nur noch gegen Bezahlung bei DynDNS möglich) müssten die Firmware-Programmierer zusätzlich einzig den Parameter "&wildcard=NOCHG" in ihr Update-Telegramm integrieren. Leider haben das viele nicht begriffen, immerhin bei "Synology - Externer Zugriff" funktioniert es. Aber den Programmierern bliebe ja auch die Möglichkeit, im Konfigurationsprogramm des Routers ein besonderes Markierungsfeld für "ON" oder "OFF" zu schaffen. Das haben früher doch zumindest einige getan. So beispielsweise die Leute von ZyXEL. Seit ihrem ersten B-WLAN-Router vor vielen Jahren (P-316; allerdings auch etwa zwanzig Mal so teuer, als die heutigen Produkte) gehörte nicht nur die Frage nach den "Wildcards" zum Standard. Selbstverständlich waren ab dann auch lange Zeit ebenso zwei bis drei Namen (je nach Länge) zum gleichzeitigen Update zugelassen. Es gab sogar einmal als einsame Spitze einen Router (P-324), der bis zu neun (offiziell sechs) Namen ermöglichte. Dann wurde irgendwann in den letzten Jahren auf solchen "Luxus" verzichtet.

Ganz allgemein muss man einen Trend bei fast allen Produzenten zu günstigeren Geräten feststellen, dafür aber mit einer Reduktion des Funktionsumfangs und teilweise auch der Qualität rechnen. Dafür haben aber andere Hersteller offenbar dazugelernt. So erfüllen beispielsweise neuere Spitzengeräte von NETGEAR (zum Beispiel das R6300v2) alle hier erwähnten Anforderungen. Insbesondere ist die Nachführung von mehreren Domänen-Namen (getrennt durch Kommas) problemlos möglich, obwohl das nirgendwo in der Installationsanleitung steht. Ohne einen solchen oder gleichwertigen Router, der mehrere Namen zulässt, bleibt aber die Anzahl der nachtragbaren Adressen auf zwei beschränkt (davon eine über Externer Zugriff der NAS-Station).

Funktioniert die Nachführung dynamischer IP-Adressen mit DynDNS plötzlich nicht mehr, hatte dies seit November 2015 einen einfachen Grund. Bis zu diesem Zeitpunkt konnten die langjährigen Nutzer dieses Dienstes ihr Zugangspasswort auch als Nachführungscode gebrauchen. Seit dann müssen aber alle Benutzer den schon vor einiger Zeit neugeschaffenen 32-stelligen Nachführungscode verwenden, den man im eigenen Benutzer-Profil findet.
 

Nachführung dynamischer IP-Adressen mit andern Anbietern als DynDNS

Wie bei vielen Routern üblich, ermöglichen Synology-NAS seit langem auch die Nachführung dynamischer IP-Adressen durch andere Anbieter als DynDNS. Im Rahmen dieser Anleitung kann darauf aber nicht eingegangen werden, da jeder Anbieter natürlich eigene Regeln für die Nutzung seiner Dienstleistung aufgestellt hat.
 

Nachführung dieser Anleitungs-Seite

Eine systematische Nachführung dieser Seite ist nicht mehr vorgesehen. Nach über zehn Jahren möchte der Autor seine Zeit für andere Dinge nutzen, die nicht so viele graue Haare zur Folge haben. Somit ist davon auszugehen, dass der Inhalt ab März 2018 nicht mehr in allen Teilen den effektiven Entwicklungsstand wiedergibt. Aber auch für Richtigkeit und Vollständigkeit dieser Ausgabe kann nicht garantiert werden. Änderungsvorschläge von Dritten werden aber gerne zur Kenntnis genommen und allenfalls auch mal im Text integriert.


Ausgabe vom 09.02.2017 (Basis DSM 6.0.2-8451 Update 9); sie ist nicht mehr direkt verlinkt, aber über Suchdienste immer noch auffindbar (und sicher zurzeit aktueller als alle andern deutschsprachigen "Hilfen", wie zum Beispiel die seit langem nicht mehr zutreffenden Angaben im offiziellen User-Forum oder im Wiki)

Nachtrag vom 28.04.2017: Das am 09.02.2017 im Abschnitt Modifikationen bei den Autoindex-Einstellungen bemängelte Nichtfunktionieren der Autoindex-Funktion unter Apache 2.4 wurde mit dem Update des Pakets im Rahmen von DSM 6.1.1-15101 behoben

Ausgabe vom 09.02.2018 (Basis DSM 6.1.5-15254); wurde aufgrund von Anregungen Dritter nochmals angepasst und wieder direkt verlinkt

Nachträge vom 13.03.2018 und 15.08.2018: Kleinere Text-Änderungen und -Ergänzungen

Ausgabe vom 23.08.2019: Entfernung von Angaben über frühere Testseiten und hier noch angemerkt, dass Synology-NAS offenbar ab den August-Updates in allen Windows-Versionen nur noch dann vom "Explorer" als "Computer" im Netzwerk (mit Ordnerliste und Zugriff auf die Dateien) anerkannt werden, wenn zuvor im DSM die Funktion WS-Discovery (zu finden unter Dateidienste / Erweitert) aktiviert wurde

Nachtrag vom 09.10.2019: Angebots-Verteuerung von DynDNS dokumentiert und kleine Text-Änderungen
  

  Inhaltsverzeichnis      E-Mail an "flicflac"