Test einer Synology DS416play mit DSM 6.1

Synology DS416play

Die taiwanische Firma Synology wurde im Jahr 2000 von den ehemaligen Microsoft Managern Cheen Liao und Philip Wong gegründet und hat sich zum Ziel gesetzt Network Attached Storage-Geräten (kurz NAS) mit umfangreicher Software auf Basis von Linux zu bauen. Dabei nennt Synology die Hardware DS (DiskStation) und die Software DSM (DiskStation Manager).

Als ich vor 10 Jahren die ersten NAS (Network Attached Storage) Geräte von Synology eingerichtet habe, war ich bereits überrascht wir groß der Funktionsumfang der Software und die Anpassungsmöglichkeiten dieser Geräte waren. Man merkte den Geräten aber an, dass sie eher für kleinere Firmen und den privaten Gebrauch gebaut wurden. Für den Einsatz in großen Firmennetzen waren sie noch nicht reif.

Inzwischen hatte ich einige Jahre keine Synology mehr in der Hand und es wurde höchste Zeit, sich so ein Gerät mit der aktuellen Software mal wieder näher anzuschauen. Als zudem noch mein Speicherplatz für das Backup meiner privaten Daten knapp wurde, beschoss ich mir ein aktuelles NAS der Firma Synology zuzulegen und dieses genauestens unter die Lupe zu nehmen.

Welches NAS von Synology ist für mich das beste?
Zunächst stellte sich die Frage, welches der aktuellen NAS-Geräte von Synology am ehesten für meine Bedürfnissen passt. Synology bietet inzwischen über 20 unterschiedliche NAS Geräte an, die für verschiedenste Einsatzzwecke ausgelegt sind. Es gibt sowohl für den Privatanwender als auch für Firmen verschiedener Größenordnungen passende Geräte zu finden. Für mich persönlich war eine große Speicherkapazität und ein geringer Stromverbrauch wichtig. Außerdem wollte ich gerne eine etwas leistungsfähigere CPU, um 4k Videos von dem NAS auf den Fernseher übertragen zu können. Nach einer Recherche im Internet entschied ich mich für das Model DS416play welches es aktuell bei Amazon für 442,19- € gibt. Es kann mit vier Platten bestückt werden und bringt eine etwas leistungsstärkere CPU mit. Mit vier Festplatten mit einer Größe von 4 TB und der Verwendung eines RAID (Redundant Array of Independent Disks) mit einer Festplatte für Redundanz erhält man über 10 TB Speicherplatz. Für meine privaten Zwecke ist das zunächst ausreichend. Zudem reicht die CPU der DS416play, um 4k Videos zum Fernseher zu übertragen.

Zusammenbauen und einrichten
Das zusammenbauen und einrichten des NAS ist für jemanden mit Computerkenntnissen schnell erledigt. Die Festplatten können ohne Schrauben eingebaut werden. Sobald man das Gerät anschaltet, holt es sich eine IP-Adresse per DHCP und ist über die URL http://diskstation:5000 erreichbar. Wenn man diese URL im Browser aufruft, landet man auf dem Desktop des DSM (DiskStation Managers). Dort kann man in der Systemsteuerung die Konfiguration des Gerätes vornehmen. Die vier von mir verbauten Festplatten hatte das NAS bereits automatisch zu einem SHR1 (Synology Hybrid RAID) zusammengefasst. Bei Bedarf kann das NAS natürlich auch andere RAID-Arten. Das SHR1 dürfte für die meisten aber auch das geeignetste RAID sein, da es am flexibelsten ist. Danach ist das Gerät prinzipiell einsatzbereit. Es gibt natürlich noch haufenweise kostenlose und kostenpflichtige Zusatzsoftware, die man über das sogenannte „Paket-Zentrum“ installieren kann. Ähnlich wie bei einem iPhone, ist das NAS damit nach Bedarf erweiterbar und kann zu einem kleinen Server mit diversen Funktionalitäten ausgebaut werden.

Fazit
Die NAS Systeme von Synology sind extrem erweiterbar, haben ein sehr gutes Preis-Leistung-Verhältnis und sind fast schon kleine Applikationsserver mit diversen Funktionen. Für den privaten Gebrauch und für kleine Firmen sind sie völlig ausreichend und mehr Leistung und mehr Funktionen sind für das Geld nicht zu bekommen. Ich kann diese Geräte sehr empfehlen.

Wenn man möchte gibts die Synology DS416play bei Amazon auch bereits bestückt mit Festplatten. Die Variante mit 12 TB Speicherplatz kostet bei Amazon aktuell z.B. gerade 995,- €.

Wilder Westen: USA-Reise durch Kalifornien, Nevada, Utah und Arizona

Nachdem unsere letzten Herbsturlaube immer sehr naß und kalt waren, wollten wir mal etwas weiter in den Süden. Nach einer längeren Diskussion haben wir uns deshalb entschlossen im Herbst 2017 an die südliche Westküste der USA zu fliegen und einen Road Trip durch den Wilden Westen der USA zu machen. Nachdem diese Entscheidung getroffen war, lasen wir uns durch diverse Blogs und Reiseführer und erstellten eine Liste mit den Sehenswürdigkeiten, die wir und ansehen wollen. Danach priorisieren wir die Sehenswürdigkeiten und überlegten uns eine sinnvolle Route. Nach einigen weiteren Tagen und Diskussionen war dann die folgende 3300 km lange Strecke entstanden, die wir in zwei Wochen bewältigen wollten.

Anreise

Mit einer Boeing 777-300ER von Swiss Air fliegen wir in der Holzklasse über Zürich nach San Francisco. Die Sitze sind sehr eng. Wir sind aber sowieso zu aufgeregt, um zu schlafen. Der Flug dauert durch den Umweg über Zürich und das Umsteigen insgesamt mehr als 15 Stunden. Bis wir durch die Einreisekontrolle sind, den Mietwagen abgeholt haben und im Hotel Pullman in Redwood City in der Nähe von San Francisco ankommen, vergehen weitere vier Stunden. Wir fallen danach nur noch völlig erschöpft ins Bett und schlafen bis zum nächsten Morgen.

San Francisco

Als erstes sind zwei Tage in San Francisco eingeplant. Am ersten Tag in San Francisco fahren wir Vormittags als erstes im Mission Dolores Park im spanischen viertel von San Francisco. Von diesem Park hat man eine geniale Aussicht über die Innenstadt. Das Wetter ist ein Traum. Es ist sonnig, wir haben eine klare Sicht auf die Innenstadt und die Temperaturen stiegen auf mehr ls 20 Grade Celsius. Überall sitzen kleine Familien mit Kindern und es ist eine entspannte und friedliche Stimmung.

Am Nachmittag des ersten Tages in San Francisco ziehen wir weiter in die Innenstadt und nach Chinatown, um die Stadt und ihre Geschäfte etwas näher kennen zu lernen. Da wir viel Outdoor unterwegs sind, darf dabei natürlich auch ein Besuch im Flagshipstore von The North Face nicht fehlen. Diese Firma für Outdoor-Bekleidung wurde schließlich in San Francisco gegründet.

Am zweiten Tag in San Francisco besichtigen wir am Vormittag die ehemalige Gefängnisinsel Alcatraz (inzwischen die beliebteste Touristenattraktion in San Francisco). Gerade zur Urlaubszeit ist die Besichtigung der Besichtigung der Insel meistens ausgebucht. Dies ist auch der Fall als wir dort eintreffen. Zu Glück hatte ich dies vorher im Internet gelesen und schon vorher Katen gekauft. Somit können wir wie geplant um 10:00 Uhr mit der Fähre auf die Insel fahren und in ruhe das dortige Museum ansehen.

Als wir von Alcatraz wieder zurück sind, gibt es das Mittagessen im Hafen auf dem Pier 39. Die ehemalige Bootsanlegestelle Pier 39 im Stadtteil Fisherman’s Wharf im Norden San Franciscos ist inzwischen ein bekannter und ganzjähriger Rummel mit vielen Restaurants und Geschäften. Am Nachmittag fahren wir dann über die Golden Gate Bridge aus der Stadt raus und in die Marin Headlands, um die Aussicht auf die Stadt und die Golden Gate Bridge in der Abendsonne zu genießen. Die dort gelegenen Aussichtspunkte Battery Spencer und Hawk Hill sind für so etwas bestens geeignet. Sie sind nur etwas schwierig mit dem Auto zu finden. Man kann leicht an der Abfahrt vorbeifahren, deshalb hatte ich mir vorher eine genaue Wegbeschreibung über Google Maps vorbereitet. Wir kommen pünktlich zum Sonnenuntergang bei den Aussichtspunkten an und genießen die Aussicht bei Sonnenschein, klarer Sicht und warmen Temperaturen. Ein absolutes Highlight auf unserer Reise!

Yosemite Nationalpark

Von San Francisco geht es weiter zum Yosemite Nationalpark in der Sierra Nevada. Die Fahrt dauert 4 Stunden und wir kommen Mittags im Nationalpark an. Den Nachmittag über schauen wir uns das Yosemite Valley an und unternehmen eine kleine Wanderung zum Mirror Lake. Am späten Nachmittag stehen wir im Valley dann leider in einem Stau und schaffen es deshalb nicht mehr den berühmten Glacier Point zum Sonnenuntergang zu erreichen. Wir fahren deshalb direkt zu unserem Hotel und kommen dort kurz nach Sonnenuntergang an. Die Enttäuschung den Glacier Point verpasst zu haben ist natürlich groß, aber es warten ja noch weiter tolle Aussichtspunkte auf uns. Bei meinem nächsten Besuch im Yosemite Nationalpark werde ich auf jeden Fall mehr Zeit und mögliche Staus mit einplanen.

Über die Sierra Nevada und durch das Death Valley

Am nächsten Tag steht unsere Königsetappen an. Wir wollen Abends im Amargosa Valley übernachten und vorher die Sierra Nevada und das Death Valley durchqueren. Unser Weg ist gepflastert mit genialen Aussichtspunkten, von denen wir uns den einen oder andern anschauen wollen. Die Etappe hat eine Länge von 536 km und die reine Fahrtzeit soll bereits 6 Stunden und 20 Minuten betragen. Es gibt an diesem Tag 11 Stunden Tageslicht und wir benötigen 40 Minuten für das Mittagessen. Somit verbleiben uns ca. 4 Stunden für die Aussichtspunkte.

Die Nacht im Hotel war ein wenig anstrengend, da wir nicht ausreichend Betten im Zimmer hatten und deshalb drei Leute in einem kleinen Doppelbett schlaffen mussten. Dennoch starten wir pünktlich um 6:30 Uhr noch vor Sonnenaufgang. Der Weg führt uns über Serpentinen hinaus aus dem Yosemite Valley über eine kleine Passstraße (Tioga Rd / California State Route 120) über den Tioga Pass der Sierra Nevada Richtung Death Valley. Der Tioga Pass ist mit einer Höhe von bis zu 3031 Metern der höchstgelegene Highway-Pass in Kalifornien und der Sierra Nevada. Wir haben Glück, dass er Ende Oktober noch geöffnet ist. Er wird im Winter geschlossen, sobald Schneefall einsetzt. Der Blick über die zum Teil schon schneebedeckten Gipfel der Sierra Nevada ist beindruckend und wir sind von den Eindrücken völlig überwältigt. Ein weiteres Highlight unseres Road Trips!

Nachdem wir die Sierra Nevada überquert haben gönnen wir uns bei Hank & Matt’s Copper Top BBQ ein tolles Mittagessen, bevor es weiter in das Death Valley geht. Dieser BBQ-Grill hat bei TripAdvisor weit und breit die beste Bewertung bekommen und diese kann ich nur bestätigen. Das Fleisch ist zart, saftig und sehr lecker.

Nach dem Mittagessen geht es weiter durch das Death Valley und kaum sind wir am Anfang des Tals angekommen, fängt es an zu regnen. Was für ein Zufall. Wir sind in dem trockensten Tal der USA und genau jetzt regnet es. Der angenehme Nebeneffekt des Regens ist, dass es nicht ganz so heiß ist und wir das Tal somit bei angenehmen Temperaturen besichtigen können. Bis die Sonne untergeht, bleiben wir immer wieder an Aussichtspunkten stehen und laufen ein kleines Stück. Die Natur ist beeindruckend schön und ich mache natürlich wieder diverse Fotos. Wir kommen erst spät im Hotel an. Das Hotel mit dem Namen Longstreet Inn Casino ist ein Casino und Truckertreff mitten in der Wüste und entspricht in jeder Hinsicht dem amerikanischen Klischee. Eine absolut stielechte Unterkunft im Amargosa Valley.

Las Vegas

Nach der schweren und langen Etappe des Vortages lassen wir es heute etwas gemächlicher angehen. Das nächste Ziel ist Las Vegas und das liegt nur 155 km entfernt. Nach einem gemütlichen Frühstück in der Sonne vor dem Hotel, besuchen wir noch das Ash Meadows National Wildlife Refuge. Ein nicht ganz so überlaufener und wunderschöner Nationalpark. Durch eine Quelle mitten in der Wüste entsteht hier eine Vielfalt von Leben.

Nach der Besichtigung des Ash Meadows National Wildlife Refuge  fahren wir weiter nach Las Vegas und beziehen dort für zwei Tage ein ruhiges Hotel etwas abseits aber nicht weiter als 5 Gehminuten von dem Las Vegas Strip entfernt. Die Stadt Las Vegas ist das absolute Gegenteil zu der einsamen Natur der Nationalparks. Sie ist hektisch, laut, bunt und schrill. Wenn man mit dem Auto aus einem Nationalpark kommt und in die Stadt fährt, wird man durch den Unterschied regelrecht geschockt. Aber wenn man schon in der Gegend ist, muss man so etwas sicherlich auch mal gesehen haben. Wir bleiben also für zwei Tage und schauen und die Stadt bei Tag und Nacht an und natürlich mache ich auch das eine oder andere Foto in Las Vegas. Als wir nach den beiden Tagen Las Vegas wieder verlassen, bin ich sehr froh, wieder in die Stille der Natur zu entkommen. Bei anderen Großstädten bin ich gerne auch mal eine Woche geblieben. Zwei Tage Las Vegas waren für mich aber absolut ausreichend. Im Vergleich zu London, Paris oder New York, war mir diese Stadt doch zu künstlich, zu übertrieben und zu schrill.

Bryce Canyon

Im Anschluss an Las Vegas geht es weiter zum Bryce Canyon. Ein weiteres Highlight unseres Road Trips und mein Favorit. Dieser Canyon liegt in einer Höhe von 2400 bis 2700 Metern und ist somit wesentlich höher als der nahegelegene Zion-Nationalpark und der Grand-Canyon-Nationalpark. Zudem ist ist der Canyon sehr trocken. Es ist also wichtig ausreichend Wasser mitzunehmen.

Wir beschließen das Auto auf einem der zahlreichen Parkplätze abzustellen und wandern vom Rand des Canyon mehrere Kilometer in diesen hinein. In dieser Höhe ist die Luft unglaublich dünn und klar. Der Himmel ist tief Blau und in der Sonne ist es warm. An jeder Ecke gibt es andere uns faszinierende Gesteinsformationen zu sehen und alle erstrahlen im Sonnenlicht in einer unglaublich intensiven, orangen Farbe. Man kommt sich vor wie in einer Märchenwelt. Gleichzeitig immer wieder dieser weite Blick hinunter in den Canyon und auf die Berge in der Ferne.

Während unseres Aufenthalts im Bryce Canyon übernachten wir zwei mal in der Riverside Ranch in dem kleinen Ort Hatch. Der immer gut gelaunte und freundliche Betreiber Bill läßt dieses kleine Motel mit angeschlossenem Campingplatz zu unserer Lieblingsunterkunft auf dem ganzen Urlaub werden. Er erzählt uns Anekdoten aus der Gegend, spielt zum Frühstück Musik die er extra für uns raussucht und gibt uns diverse Tipps für gute Parkmöglichkeiten und Aussichtspunkte in der Gegend. Dieses Hotel kann man wärmstens empfehlen.

Antelope Canyon

Und weiter geht’s zum Antelope Canyon bei der Kleinstadt Page in Arizona. Diese Stadt hat aktuell gerade einmal 7.000 Einwohner und wurde erst im Jahr 1957 gegründet. Sie ist somit die jüngste Stadt in den USA. Die Stadt wurde damals für die Bauarbeiter errichtet, die den Glen Canyon Dam bauten, um den Lake Powell aufzustauen.

Der Antelope Canyon ist ein sehr langer und tiefer Spalt im Sandstein, der durch Wasser und Wind entstanden ist. Der Canyon liegt im Indianerland und es ist nicht erlaubt diesen allein aufzusuchen. Man kann ihn aber im Rahmen einer Führung besichtigen. Es gibt mehrere Anbieter für solche Führungen, die leicht im Internet zu finden sind.

Da die Führungen für den Antelope Canyon oft ausgebucht sind, sollte man bereist ein paar Wochen vor der Reise eine Führung bei einem dieser Anbieter buchen. Bei der Buchung ist zu beachten, dass man zwei Stellen in dem Canyon besichtigen kann. Die eine Stelle heißt Upper Antelope Canyon und die andere Lower Antelope Canyon. Der Lower Antelope Canyon ist über eine Treppe vom Parkplatz aus zugänglich, währen der Upper Antelope Canyon nur über geführte Touren mit Bussen erreichbar ist. Deshalb ist der Besuch des Lower Antelope Canyon deutlich günstiger. Zudem sollte man möglichst zur Mittagszeit eine Tour buchen. Dann steht die Sonne am höchsten und beleuchtet die Gesteinsformationen in dem Canyon deshalb am eindrucksvollsten.

Ich hatte bereits einige Wochen zuvor eine Tour bei dem Anbieter Dixie Ellis für den Lower Antelope Canyon gebucht. Wir waren gespannt, wie die Führung wird, weil man im Internet teilweise Berichte über nicht sonderlich freundliche Führer findet. Die Sorge war aber unbegründet. Unser Führer ist sehr freundlich, zuvorkommend und erklärte uns viel über das frühere Leben der Indianer und die Geschichte des Landes. Es wird eine eindrucksvolle Führung, die ich nur empfehlen kann. Die Farben und die Lichtstimmung in diesem Canyon sind wirklich beeindruckend.

Monument Valley

Nach dem Antelope Canyon geht es weiter zum fast jedem bekannten Monument Valley. Dieses Valley liegt innerhalb der Navajo-Nation-Reservation an der südlichen Grenze des US-Bundesstaates Utah, sowie im Norden Arizonas. Durch seine riesigen, roten und markanten Gesteinsformationen ist es Kulisse in diversen Werbesendungen und Filmen und dürfte nahezu jedem bekannt sein. Das Valley kann mit dem eigenen Auto oder mit einer Bustour mit Führung befahren werden. Wir entscheiden uns für das eigene Auto. Bei der Fahrt durch das Valley stellt sich diese Entscheidung als sehr mutig heraus. Die Schotterpisten sind für unseren Van durch die vielen Schlaglöcher und die steile Steigungen absolut grenzwertig. Auf unserer Tour kommen wir sogar an Geländewagen vorbei, die einen Plattfuss haben oder festgefahren sind. Es geht aber alles gut.

Am Abend übernachten wir in der kleinen Stadt Kayenta. Diese hat noch nicht mal 5.000 Einwohner, liegt mitten in der Navajo Nation Reservation und es ist kein Verkauf von Alkohol erlaubt.

Grand Canyon und Route 66

Das Monument Valley ist auch der östlichste Punkt unserer Reise. Von hier aus geht es wieder Richtung Westen. Unser erstes Etappenziel ist der Grand Canyon. Um diesen Riesigen Canyon zu besichtigen, fahren wir nach Grand Canyon Village an die Südkante des Canyon. Von dort wandern wir auf einem Wanderweg entlang der Felswand hinunter Richtung Colorado River. Nach einer Stunde und ein paar hundert Metern drehten wir aber lieber wieder um und laufen zurück. Für die ganze Strecke bis zum Fluß und zurück würde man zwei Tage benötigt. So viel Zeit haben wird nicht und wenn man im Canyon übernachten will, muss man das vorher anmelden.

 

Nach der Besichtigung des Grand Canyon fahren wir weiter und beziehen ein Hotel in der kleinen Stadt Kingman. Diese Stadt liegt auf der ehemaligen Route 66. Deshalb findet man hier überall etwas über diese erste durchgehend geteerte Straße, die von der Ostküste an die Westküste ging. Um ein bisschen von der Geschichte der Route 66 mitzubekommen, fahren wir ein Stück nicht auf der Schnellstraße, sondern auf der ehemaligen Route 66 nach Oatman. Diese ehemalige Goldgräber ist sehr gut erhalten und es leben sogar noch Menschen dort. Es wird inzwischen nicht mehr nach Gold gesucht, aber einige Einwohner sind geblieben und bieten Souvenirs und Krimskrams für die Touristen an. Wir sind in Oatman vor allem von den wilden Eseln begeistert, die durch die ganze Stadt laufen und versuchen von den Touristen Futter zu bekommen.

Pazifikküste und Paso Robles

Als letztes steht ein Schlenker zu der Pazifikküste auf unserer Reise an. Wir übernachten in einem Hotel in der bekannten Weinanbauregion Paso Robles und testen dort natürlich auch den einen oder anderen kalifornischen Wein. Am nächsten Tag fahren wir noch ein Stück die California 1 (eine Landstraße direkt am Pazifik) entlang und danach wieder zurück nach San Francisco. Am letzten Tag unseres Urlaubs besichtigen wir dann noch die Universität Stanford bei Palo Alto und dann geht es mit dem Flugzeug wieder nach Hause. Am Ende wäre man – wie so oft – gerne eine Woche länger geblieben. Aber so ist das ja bei jedem schönen Urlaub.

Selbstgemachte Hamburger

Nach einigen Jahren des Testens, hier mein aktuelles Rezept für selbstgemachte Hamburger mit Honig-Senf Sauce.

Mein Tipp für richtig leckere Hamburger: Wenn man richtig leckere Hamburger möchte, sollte man nicht das normale Hackfleisch aus dem Supermarkt nehmen, sondern ein richtiges gutes Stück Rindfleisch zu Hack verarbeiten. Sehr zart und geeignet ist z.B. das Bürgermeisterstück.

Zutaten für 6 Personen

  • 900 g Hackfleisch vom Rind
  • 3 Eier
  • 280 g Typ 405 Mehl
  • 150 ml Vollmilch
  • 100 g Parmesan (sehr fein gerieben)
  • 28 g frische Hefe
  • 30 g Butter
  • 1 EL Zucker
  • Salat
  • 1 süße Zwiebel
  • Käse zum überbacken (z.B. Cheddar)
  • Salz und Pfeffer
  • 2 Tomaten
  • 80 ml Majonäse
  • 60 ml Dijon Senf
  • 30 ml Honig
  • 1/2 EL frischer Estragon
  • 2 EL gehackter Rosmarin

Zubereitung (Brötchen / Buns)
Parmesan mit einer Pamesanreibe ganz klein reiben und mit dem Mehl vermischen. Milch mit der Butter und dem Zucker in einem Topf etwas erwärmen bis sich der Zucker vollständig aufgelöst hat. Hefe klein bröseln und unter die Milch mischen (Hefe sollte dabei nicht wärmer als 37 Grad werden) und das ganze in eine Küchenmaschine mit Knethacken füllen. Ein Ei mit etwas Milch verquirlen und dazu geben. Rosmarin klein hacken und ebenfalls dazu geben. Küchenmaschine einschalten und nach und nach die Mischung aus Mehl, Parmesan hinzugegeben. Den Teig 10 Minuten durchkneten lassen. Danach die Schüssel abdecken und mindesten eine Stunde gehen lassen. Danach 6 Brötchen aus dem Teig formen mit ein wenig gequirltem Ei lasieren und diese ca. 10 Minuten im Backofen bei ca. 200 Grad backen.

Zubereitung der Sauce
80 ml Majonäse, 60 ml Dijon Senf, zwei EL Honig und einen halben kleingehackten EL Estragon in einer Schüssel verrühren. Danach je nach Geschmack mit Salt und Pfeffer abschmecken.

Zubereitung des Rinderhacks
Grill oder Pfanne auf ca. 250 Grad vorheizen. Das Ei aufrühren, zu dem Hackfleisch geben, durchkneten und mit Salz und Pfeffer würzen. Aus der Masse sechs Hackfleischkugeln formen. Die Kugeln zwischen ausreichend Folie legen und zu einem großen Paddy formen. Das Paddy sollte ruhig richtig groß werden, da es sich beim braten wieder zusammen zieht. Zum Schluss die Paddys in der Pfanne oder auf dem Grill von jeder Seite ca. 4 Minuten braten. Zum Schluss den Käse auf die Paddys legen und leicht anschmelzen lassen.

Zum Schluss die Brötchen mit dem Paddy und Käse belegen und nach belieben die anderen Zutaten (Salat, Zwiebel, Tomaten, Sauce) dazu gegeben.

Vielen Dateien eine andere Dateiendung geben

Ab und zu hat man bei der Administration die Aufgabenstellung vielen Datei eine andere Dateiendung zu geben. Hier eine kleine Programmzeile, mit der man diese Aufgabe sehr erleichtern kann. Mit dieser kann man unter Linux oder MacOSX an alle Dateien in einem Verzeichnis die Dateiendung „.pdf“ anhängen.

ls * | cat | while read n; do mv "$n" "$n.pdf"; done

Große Mengen an Dateien per Kommandozeile mit FTP löschen

Eine häufige Aufgabenstellung bei einem Dateitransfer per FTP (File Transfer Protocol) ist das löschen von großen Mengen von Dateien per FTP. Bei einem FTP-Client mit GUI ist dies mit wenigen Klicks gemacht. Wenn man das ganze jedoch per Kommandozeile mit dem Befehlt mdel machen möchte, ist dies mit der Schwierigkeit verbunden, dass der Befehl mdel bei jeder Datei nachfragt, ob er diese wirklich löschen soll. Dies kann bei vielen Dateien sehr anstrengend werden.

Wenn man jetzt nach einem Parameter sucht, der den Befehlt mdel dazu bringt ohne eine Nachfrage alle Dateien zu löschen, wird man nicht fündig. Dies liegt daran, dass es diesen gar nicht gibt.

Man kann das Problem aber dennoch anders lösen. Und zwar in dem man als erstes den Befehlt prompt eingibt. Dieser stellt den „interactive mode“ auf off. Dadurch laufen alle FTP-Befehle ohne Rückfragen oder Rückmeldungen. Somit läuft auch der Befehlt mdel, ohne bei jeder Datei nachzufragen, ob er diese wirklich löschen soll.

Reparatur eines Servers mit Ubuntu oder Debian bei Hetzner

Des öfteren habe ich einen Linux-Server in einem Rechenzentrum der nicht mehr bootet und bei dem man nicht direkt auf den Monitor schauen kann. Bei dem Anbieter Hetzner ist es z.B. so, dass zunächst ein Gerät an den Server angeschlossen werden muss, bevor man das Monitorbild des Servers angezeigt bekommt. Dies dauert etwas länger und man verliert wertvolle Zeit.

Wesentlich schneller ist man bei Hetzner, wenn man das Rescue-System bootet und von diesem aus den Server untersucht. Dazu muss man nur über die Management-Webseite von Hetzner das Rescue-System aktivieren und den Server rebooten.

Im folgenden habe ich mir ein paar nützliche Befehle notieret, mit denen man im Rescue-System den Server untersuchen und reparieren kann. Damit habe ich diese im Notfall immer schnell zur Hand und muss nicht lange im Wiki von Hetzner suchen.

Überprüfung des RAID (Plattenspiegelung)
mit dem Befehl cat /proc/mdstat kann man sich den Status des RAID-Systems ausgeben lassen. Dies ausgäbe sollte dann wie folgt aussehen, wenn alles o.k. ist.

root@rescue ~ $ cat /proc/mdstat
Personalities : [raid1]
md2 : active raid1 sda3[0] sdb3[1]
      1936077760 blocks super 1.2 [2/2] [UU]
 
md1 : active raid1 sda2[0] sdb2[1]
      523968 blocks super 1.2 [2/2] [UU]
 
md0 : active raid1 sda1[0] sdb1[1]
      16768896 blocks super 1.2 [2/2] [UU]

Filesystem-Check
Mit dem Befehlt fsck /dev/md1 und fsck /dev/md2 kann man dann die Filesysteme prüfen lassen. Wenn diese heil sind, sollte die Ausgabe wie folgt aussehen.

root@rescue ~ $ fsck /dev/md1
fsck from util-linux 2.25.2
e2fsck 1.42.12 (29-Aug-2014)
/dev/md1: recovering journal
/dev/md1: clean, 313/131072 files, 125273/523968 blocks
root@rescue ~ $ fsck /dev/md2
fsck from util-linux 2.25.2
e2fsck 1.42.12 (29-Aug-2014)
/dev/md2: recovering journal
Setting free blocks count to 440126453 (was 440126531)
/dev/md2: clean, 5444918/121012224 files, 43892987/484019440 blocks

Erneutes schreiben des Boot-Blocks
Oft ist auch nur der Boot-Block auf der Festplatte nicht vorhanden, oder beschädigt. Mit den folgenden Befehlen kann man diesen neu schreiben.

mount /dev/md2 /mnt
mount /dev/md1 /mnt/boot
mount -o bind /dev /mnt/dev
mount -o bind /sys /mnt/sys
mount -t proc /proc /mnt/proc
cp /proc/mounts /mnt/etc/mtab
chroot /mnt /bin/bash
grub-install /dev/sda
grub-install /dev/sdb
grub-install --recheck /dev/sda
grub-install --recheck /dev/sdb
mkdir /run/lock
cp /proc/mounts /etc/mtab
update-grub

10 Jahre Purrucker Blog und ein moderneres Layout

dsc_9873Mein alter Technik-Blog feiert seinen zehnten Geburtstag. Somit hatte er ziemlich genau 10 Jahren das gleiche Layout. Im Internet ist das eine Ewigkeit. Außerdem störte mich zunehmend der für Smartphones und Tabletts nicht ganz optimale Aufbau der Menüs und Widgets. Deshalb habe ich den Blog auf ein neues und moderneres Layout mit einem Responsive Webdesign umgestellt. Damit ist der Blog jetzt auch optimal auf mobilen Geräten zu lesen.

Backup mit duply

Seit geraumer Zeit sichere ich meine Linuxserver am liebsten mit der Software duply. Der Name duply ist die Abkürzung von „simple duplicity“. Wie der Name schon verrät, wurde diese Software entwickelt, um das komplexe aber gleichzeitig auch leistungsfähige Backupframework duplicity einfach bedienbar zu machen. Und dies ist meiner Meinung nach auch hervorragend gelungen.dsc_9889

In diesem Artikel blogge ich die einzelnen Schritte, mit denen ich ein duply auf einem Debian 8 oder Ubuntu 16.04 einrichte.

Als erstes muss duply und ein brauchbares FTP-Programm für die Datenübertragung installiert werden.

apt-get install duply
apt-get install lftp

Danach muss ein zentrales Verzeichnis für die Konfiguration unter /etc angelegt und danach eine Backup-Konfiguration erstellt werden. Es ist wichtig, dass das Verzeichnis als erstes angelegt wird, da duply die Konfiguration sonst in das home-Verzeichnis und nicht unter /etc ablegt. Als Namen für die Konfiguration wähle ich immer den vollen Hostnamen. Dies ist zumeist eindeutig und läßt sich im Nachhinein leichter Skripten.

mkdir /etc/duply
duply hostname.domain.de create

Danach erzeugt man sich einen GPG-Schlüssel.

gpg --gen-key

Sofern man einen bereits existierenden GPG-Schlüssel verwenden möchte, kann man natürlich auch Schlüssel in GPG importieren. Dabei sollte man dann aber nicht vergessen, neben dem öffentlichen auch den privaten Schlüssel und die Ownertrusts zu importieren. Ich habe die beiden Schlüssel und die Ownertrusts für diese Zwecke immer in drei Dateien mit den Namen backup-key.asc, backup-secret-key.asc und backup-ownertrusts.asc. Diese brauche ich dann nur übermitteln und importieren.

gpg --import backup-key.asc
gpg --import backup-secret-key.asc
gpg --import-ownertrust backup-ownertrusts.asc

Sobald man den Schlüssel angelegt oder importier hat, läßt man sich die Public-Key-ID des GPG-Schlüssels anzeigen. Diese muss man nämlich später in die Konfiguration von duply eintragen, damit die Backups mit GPG verschlüsselt werden. Dies führt zu einer zusätzlichen Datensicherheit, die gerade bei FTP-Servern im Internet zu empfehlen ist.

gpg --list-keys

Danach passt man die Konfiguration von duply entsprechend an.

cd /etc/duply/hostname.domain.de/
vi conf

Die Datei sollte ungefähr wie folgt aussehen. Dabei muss die Schlüssel-ID und die FTP-VErbindung natürlich auf die eigene Umgebung angepasst werden.

# gpg encryption settings, simple settings:
#  GPG_KEY='disabled' - disables encryption alltogether
#  GPG_KEY='<key1>[,<key2>]'; GPG_PW='pass' - encrypt with keys,
#   sign if secret key of key1 is available use GPG_PW for sign & decrypt
#  Note: you can specify keys via all methods described in gpg manpage,
#        section "How to specify a user ID", escape commas (,) via backslash (\)
#        e.g. 'Mueller, Horst', 'Bernd' -> 'Mueller\, Horst, Bernd'
#        as they are used to separate the entries
#  GPG_PW='passphrase' - symmetric encryption using passphrase only
GPG_KEY='1234567'
GPG_PW='Hier kommt das Passwort fuer den eigenen key hin'
# gpg encryption settings in detail (extended settings)
#  the above settings translate to the following more specific settings
#  GPG_KEYS_ENC='<keyid1>[,<keyid2>,...]' - list of pubkeys to encrypt to
#  GPG_KEY_SIGN='<keyid1>|disabled' - a secret key for signing
#  GPG_PW='<passphrase>' - needed for signing, decryption and symmetric
#   encryption. If you want to deliver different passphrases for e.g.
#   several keys or symmetric encryption plus key signing you can use
#   gpg-agent. Simply make sure that GPG_AGENT_INFO is set in environment.
#   also see "A NOTE ON SYMMETRIC ENCRYPTION AND SIGNING" in duplicity manpage
# notes on en/decryption
#  private key and passphrase will only be needed for decryption or signing.
#  decryption happens on restore and incrementals (compare archdir contents).
#  for security reasons it makes sense to separate the signing key from the
#  encryption keys. https://answers.launchpad.net/duplicity/+question/107216
#GPG_KEYS_ENC='<pubkey1>,<pubkey2>,...'
#GPG_KEY_SIGN='<prvkey>'
# set if signing key passphrase differs from encryption (key) passphrase
# NOTE: available since duplicity 0.6.14, translates to SIGN_PASSPHRASE
#GPG_PW_SIGN='<signpass>'
 
# uncomment and set a file path or name force duply to use this gpg executable
# available in duplicity 0.7.04 and above (currently unreleased 06/2015)
#GPG='/usr/local/gpg-2.1/bin/gpg'
 
# gpg options passed from duplicity to gpg process (default='')
# e.g. "--trust-model pgp|classic|direct|always"
#   or "--compress-algo=bzip2 --bzip2-compress-level=9"
#   or "--personal-cipher-preferences AES256,AES192,AES..."
#   or "--homedir ~/.duply" - keep keyring and gpg settings duply specific
#   or "--pinentry-mode loopback" - needed for GPG 2.1+ _and_
#      also enable allow-loopback-pinentry in your .gnupg/gpg-agent.conf
#GPG_OPTS=''
 
# disable preliminary tests with the following setting
#GPG_TEST='disabled'
 
# backend, credentials & location of the backup target (URL-Format)
# generic syntax is
#   scheme://[user[:password]@]host[:port]/[/]path
# eg.
#   sftp://bob:secret@backupserver.com//home/bob/dupbkp
# for details and available backends see duplicity manpage, section URL Format
#   http://duplicity.nongnu.org/duplicity.1.html#sect7
# NOTE:
#   some backends (eg. cloudfiles) need additional env vars to be set to
#   work properly, when in doubt consult the man page mentioned above.
# ATTENTION:
#   characters other than A-Za-z0-9.-_.~ in the URL have to be
#   replaced by their url encoded pendants, see
#     http://en.wikipedia.org/wiki/Url_encoding
#   if you define the credentials as TARGET_USER, TARGET_PASS below duply
#   will try to url_encode them for you if the need arises.
#TARGET='scheme://user[:password]@host[:port]/[/]path'
TARGET='ftp://user:passwort@ftphost.domain.de/'
# optionally the username/password can be defined as extra variables
# setting them here _and_ in TARGET results in an error
#TARGET_USER='_backend_username_'
#TARGET_PASS='_backend_password_'
# alternatively you might export the auth env vars for your backend here
# when in doubt consult (if existing) the NOTE section of your backend on
#  http://duplicity.nongnu.org/duplicity.1.html for details
# eg. for cloud files backend it might look like this (uncomment for use!)
#export CLOUDFILES_USERNAME='someuser'
#export CLOUDFILES_APIKEY='somekey'
#export CLOUDFILES_AUTHURL ='someurl'
 
# base directory to backup
SOURCE='/'
 
# a command that runs duplicity e.g.
#  shape bandwidth use via trickle
#  "trickle -s -u 640 -d 5120" # 5Mb up, 40Mb down"
#DUPL_PRECMD=""
 
# override the used python interpreter, defaults to "python2"
#   e.g. "python" or "/usr/bin/python2.7"
#PYTHON="python2"
 
# exclude folders containing exclusion file (since duplicity 0.5.14)
# Uncomment the following two lines to enable this setting.
#FILENAME='.duplicity-ignore'
#DUPL_PARAMS="$DUPL_PARAMS --exclude-if-present '$FILENAME'"
 
# Time frame for old backups to keep, Used for the "purge" command.
# see duplicity man page, chapter TIME_FORMATS)
MAX_AGE=3M
 
# Number of full backups to keep. Used for the "purge-full" command.
# See duplicity man page, action "remove-all-but-n-full".
MAX_FULL_BACKUPS=3
 
# Number of full backups for which incrementals will be kept for.
# Used for the "purge-incr" command.
# See duplicity man page, action "remove-all-inc-of-but-n-full".
#MAX_FULLS_WITH_INCRS=1
 
# activates duplicity --full-if-older-than option (since duplicity v0.4.4.RC3)
# forces a full backup if last full backup reaches a specified age, for the
# format of MAX_FULLBKP_AGE see duplicity man page, chapter TIME_FORMATS
# Uncomment the following two lines to enable this setting.
#MAX_FULLBKP_AGE=1M
#DUPL_PARAMS="$DUPL_PARAMS --full-if-older-than $MAX_FULLBKP_AGE "
 
# sets duplicity --volsize option (available since v0.4.3.RC7)
# set the size of backup chunks to VOLSIZE MB instead of the default 25MB.
# VOLSIZE must be number of MB's to set the volume size to.
# Uncomment the following two lines to enable this setting.
#VOLSIZE=50
#DUPL_PARAMS="$DUPL_PARAMS --volsize $VOLSIZE "
 
# verbosity of output (error 0, warning 1-2, notice 3-4, info 5-8, debug 9)
# default is 4, if not set
#VERBOSITY=5
 
# temporary file space. at least the size of the biggest file in backup
# for a successful restoration process. (default is '/tmp', if not set)
#TEMP_DIR=/tmp
 
# Modifies archive-dir option (since 0.6.0) Defines a folder that holds
# unencrypted meta data of the backup, enabling new incrementals without the
# need to decrypt backend metadata first. If empty or deleted somehow, the
# private key and it's password are needed.
# NOTE: This is confidential data. Put it somewhere safe. It can grow quite
#       big over time so you might want to put it not in the home dir.
# default '~/.cache/duplicity/duply_<profile>/'
# if set  '${ARCH_DIR}/<profile>'
#ARCH_DIR=/some/space/safe/.duply-cache
 
# DEPRECATED setting
# sets duplicity --time-separator option (since v0.4.4.RC2) to allow users
# to change the time separator from ':' to another character that will work
# on their system.  HINT: For Windows SMB shares, use --time-separator='_'.
# NOTE: '-' is not valid as it conflicts with date separator.
# ATTENTION: only use this with duplicity < 0.5.10, since then default file
#            naming is compatible and this option is pending depreciation
#DUPL_PARAMS="$DUPL_PARAMS --time-separator _ "
 
# DEPRECATED setting
# activates duplicity --short-filenames option, when uploading to a file
# system that can't have filenames longer than 30 characters (e.g. Mac OS 8)
# or have problems with ':' as part of the filename (e.g. Microsoft Windows)
# ATTENTION: only use this with duplicity < 0.5.10, later versions default file
#            naming is compatible and this option is pending depreciation
#DUPL_PARAMS="$DUPL_PARAMS --short-filenames "
 
# more duplicity command line options can be added in the following way
# don't forget to leave a separating space char at the end
#DUPL_PARAMS="$DUPL_PARAMS --put_your_options_here "

Bei Bedarf, kann man dann noch Verzeichnisse vom Backup ausschließen.

vi exclude

Anzeige der bereits gelaufenen Backups:

duply $(hostname -f) status

Starten eines Full-Backups:

duply $(hostname -f) full

Löschen veralteter Backups:

duply $(hostname -f) purge-full --force

Einrichtung einer täglichen, inkrementellen Sicherung mit anschließendem löschen der veralteten Backups:
Um duply jede Nacht ein Backup machen zu lassen, muss ein Cron-Job angelegt werden. Dazu legt man am besten die Datei /etc/cron.d/duply mit dem folgenden Befehlt an.

vi /etc/cron.d/duply

Wenn man jede Nacht um 2 Uhr eine Sicherung machen möchte, sollte in dieser Datei die folgende Zeile eingetragen werden.

0 2 * * * root /usr/sbin/duply.sh >/dev/null 2>&1

Danach muss die Datei /usr/sbin/duply.sh angelegt werden, die vom Cron-Job aufgerufen wird.

vi /usr/sbin/duply.sh

In dieser sollte dann das folgende stehen.

#!/bin/sh
#
# Script created on 04-10-2015 KPU
#
# This script was created to make Duplicity backups.
#
# 05.01.2016 K.Purrucker
# Ergaenzung: Es wird immer der Hostname als Konfigname verwendet
#
 
duply $(hostname -f) backup >>/var/log/duply.log
duply $(hostname -f) purge-full --force >>/var/log/duply.log
 
exit 0

Danach muss noch cron neu gestartet, die Datei ausführbar gemacht und das Log-File angelegt werden.

chmod a+x /usr/sbin/duply.sh
service cron restart
touch /var/log/duply.log

Beispiel: Rücksicherung einer 7 Tage alten Version der Datei etc/fstab in das Verzeichnis /root/:
duply $(hostname -f) fetch etc/fstab /root/fstab 7D

Umleitung auf einen anderen DNS-Namen und erzwingen von HTTPS innerhalb eines VirtualHosts

Wenn man eine Webseite mit mehreren DNS-Namen betreibt, möchte man meistens nur ein SSL-Zertifikat für diese erwerben. Eine solche Webseite wird bei einem Apache Webserver zudem meistens innerhalb eines VirtualHost konfiguriert. Daraus ergibt sich somit die Anforderung, innerhalb eines VirtualHost bei einem Apache Webserver gleich zwei Weiterleitungen zu konfigurieren.

  1. Eine Weiterleitung von http://<hostname1>.<domain>.de auf http://<hostname2>.<domain>.de
  2. Eine Weiterleitung von  http://<hostname2>.<domain>.de auf https://<hostname2>.<domain>.de

Damit der Browser keine Warnmeldung ausgibt, muss dass Zertifikat für den richtigen DNS-Namen ausgestellt sein. Deshalb ist es sehr wichtig, dass die Weiterleitungen nicht gleichzeitig sondern nacheinander ausgeführt werden. Beim ersten Aufruf der Seite muss nur auf den zweiten DNS-Namen umgeleitet werden. Beim zweiten Aufruf der Seite (der dann ja schon über den zweiten DNS-Namen erfolgt) muss dann von HTTP auf HTTPS umgeleitet werden.

Die serverseitige Umleitung von einer URL auf die andere Erfolg bei Apache üblicherweise über das Modul mod_rewrite. Bevor man dieses verwendet, muss es aktiviert werden. Dies geschieht bei Debien oder Ubuntu mit den folgendem Befehl.

a2enmod rewrite

Danach muss der Apache neu gestartet werden, damit das Modul geladen wird. Dies erledigt man bei einem neueren Ubuntu z.B. mit dem folgenden Befehl.

service apache2 restart

Die Regel für eine Weiterleitung besitzt bei Apache sogenannte Flags. Diese legen die genaue Funktionsweise der Weiterleitung fest. Um eine Weiterleitung durch Ersetzen zu erreichen wird das Flag R benötigt. Das Flag R steht für Replace und bedeutet, dass Teile der URL durch etwas anderes ersetzt werden. Wenn die Weiterleitung zudem dauerhaft sein soll, ist bei dem Flag R zudem ein Grund 301 hilfreich. Dieser Grund signalisiert, dass die Weiterleitung dauerhaft sein soll. Das Flag wird dann als „R=301“ geschrieben.

Obwohl die Konfiguration für beide Weiterleitungen in der Konfiguration von demselben VirtualHost steht, darf nur eine zur Zeit ausgeführt werden. Dies wird durch das Flag L erreicht. Dieses Flag steht für Last und bedeutet, dass beim Greifen der Rewrite-Regel keine weitere Rewrite-Regel ausgeführt wird. Es wird also immer nur eine Regel pro Aufruf ausgeführt.

Zudem ist wichtig, dass als erstes die Regel für die Weiterleitung auf den ersten DNS-Namen kommt. Erst danach darf die Regel für die Weiterleitung auf HTTPS kommen.

Wenn man all diese Bedingungen beachtet, sollten Rewrite-Regeln wie folgt aussehen.

RewriteEngine on
RewriteCond %{HTTP_HOST}   ^hostname1\.domain\.de$ [NC]
RewriteRule   ^/(.*)$ http://hostname2.domain.de/$1  [R=301,L]
 
RewriteCond %{HTTPS} off
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]

Weitere Informationen zum mod_rewrite gibt es auf den entsprechenden Webseiten beim Apache-Projekt unter http://httpd.apache.org/docs/current/mod/mod_rewrite.html oder https://httpd.apache.org/docs/current/rewrite/flags.html zu finden.

SVN auf einem Ubuntu 14.04 mit Plesk installieren

Ich habe Heute ein SVN (Subversion) auf einem Ubuntu 14.04 Server mit einem SVN Plesk 12.5 installiert. Damit dies gelingt muss man ein Kleinigkeiten beachten. Zudem gibt es diverse Anleitungen im Netz, die sich nicht an die Vorgaben von Plesk halten. Wenn man eine solche Anleitung befolgt, kann dies Folgeproblemen verursachen. Kurz um … ich beschreibe hier mal, wie man die Installation richtig macht.

1. Installation von svn aus den Paketquellen von Ubuntu
Dazu loggt man sich per ssh auf dem Server ein und installiert die Pakete mit dem folgenden Befehl (muss als root ausgeführt werden):

apt-get install subversion libapache2-svn

2. Eine Subdomain in Plesk anlegen
In meinem Fall heißt die Subdomain save. Wie das geht ist im Handbuch von Plesk zu finden: https://docs.plesk.com/de-DE/12.5/customer-guide/websites-und-domains/domains-und-dns/hinzufügen-von-subdomains.65180/

3. Authentifizierung und die SVN-Einstellungen in die Konfiguration des vHost einbauen
Damit diese Konfiguration bei Änderungen in Plesk nicht überschrieben wird, sollte man sie über das Webinterface von Plesk einbauen. Dazu muss man in die „Web Server Settings. Um dorthin zugegangen, klickt man auf der Linken Seite auf „Hosting Services“ Domains bei der richtigen Domain auf „Hosting Settings“ Es geht ein Reiter auf. Auf diesem findet man die „Web Server Settings“
Plesk 12.5 Web Server Settings
Dort trägt man dann als „Alditional direktives“ für HTTP und HTTPS (sofern man https nutzen möchte) die folgenden Zeilen ein (dabei die Domain und Subdomain anpassen!):

<Location /svn>
DAV svn
SVNParentPath /var/www/vhosts/[DOMAIN NAME]/subdomain-name
SVNListParentPath On
 
AuthType Basic
AuthName "SVN Authorization Realm"
AuthUserFile /etc/apache2/mods-enabled/dav_svn.passwd
Require valid-user
</Location>

4. Benutzer, Verzeichnis und Repository anlegen
Dazu gibt man als root die folgenden Befehle ein:

htpasswd -c /etc/apache2/mods-enabled/dav_svn.passwd USERNAME
cd /var/www/vhosts/DOMAIN/subdomains/subdomain-name
mkdir svn
svnadmin create svn/projektname
chown -R www-data:www-data svn/
service apache2 restart

Danach sollte das SVN laufen. Falls nicht, sind hier noch ein paar weiterführende Informationen zur Fehlerbehebung zu finden: https://talk.plesk.com/threads/basic-subversion-svn-on-plesk-12-5.338617/