Krausmueller.de

Ansible Rolle hass für die Installation von Home Assistant

2018-11-20T00:00:00+00:00

Wie im letzten Artikel beschrieben verwende ich die manuelle Installation von Home Assistant. Um ein System schnell wieder herstellen zu können kann Ansible verwendet werden. Dazu habe ich eine Rolle erstellt. Diese ist als Github Repository verfügbar. Im gleichen Repository finden sich (in naher Zukunft) noch andere Rollen die für eine Home Assistant Installation sinnvoll sein können. Eine Beschreibung der Variablen befindet sich in der README.

Der grobe Ablauf lässt sich mit diesen Schritten zusammenfassen:

benötigte Pakete installieren (abhängig von der Linux Distribution)
Benutzer für Home Assistant anlegen
Home Assistant in Virtual Environment installieren
systemd Startscript erstellen und aktivieren

Ein Playbook das die Rolle nutzt könnte z.B. so aussehen:

1
2
3
4
5
6
7


- hosts: hass
 vars:
 hass_version: "0.81.6"
 hass_user: "pi"
 hass_virtualenv: "/srv/hass"
 roles:
 - hass

Dieses Playbook würde die Version 0.81.6 von Home Assistant in das Verzeichnis /srv/hass installieren. Diese Installation läuft unter dem User “pi”.

Die Rolle wurde mit Hilfe von Molecule für folgende Distributionen getestet:

Debian 9 Stretch
Debian 10 Buster
Ubuntu 18.04
Ubuntu 18.10
Fedora 28
Centos 7

Produktiv genutzt habe ich die Rolle lediglich um eine Installation unter Raspbian (Debian 9 Stretch) durchzuführen. Auf den anderen erwähnten Distributionen sollte es aber ebenfalls funktionieren.

Vorstellung Home Assistant und Installationsvarianten

2018-10-30T00:00:00+00:00

Mein Einstieg in die Heimautomatisierung war die Messung von Temperaturen und später die Schaltung von Steckdosen per 433 MHz Funk (diese und diese). Um die Werte zu betrachten und die Steckdosen zu schalten habe ich mit Python einen eigenen kleinen Webserver geschrieben. Für richtige Automatisierungen bietet es sich jedoch an ein bereits bestehendes System zu benutzen. Meine Wahl fiel auf Home Assistant.

Home Assistant ist ein auf Python basierendes Open Source System mit dem viele Produkte zur Heimautomatisierung unterschiedlicher Hersteller in einem System zentral gesteuert werden können. Die verschiedenen Produkte werden als Components eingebunden. Für diese können dann z.B. Automatisierungen erstellt werden. Beim Eintreten von Bedingungen (Trigger) können diese automatisch ausgeführt werden. So kann z.B. automatisch Musik gestartet werden, wenn man nach Hause kommt. Die Seite Components gibt einen Überblick über die Geräte die eingebunden werden können. Mit der Suche kann man schauen ob bereits vorhandene Produkte unterstützt werden und erhält die passende Dokumentation (z.B. Sonos). Ähnliche Systeme sind z.B. openHAB, ioBroker oder FHEM.

Es gibt verschiedene Varianten um Home Assistant zu installieren. Es ist sehr beliebt Home Assistant auf einem Raspberry Pi (möglichst Raspberry Pi 3 Model B+) zu installieren. Zumindest zum Testen ist dies absolut ausreichend. Sollten die Ressourcen nicht ausreichen kann später immer noch auf ein leistungsfähigeres System gewechselt werden. Für die Installation auf einem Raspberry Pi stehen 3 (unterschiedlich komplexe) Möglichkeiten zur Auswahl:

Hass.io Ein Image wird auf die SD-Karte geschrieben und der Raspberry Pi kann direkt davon gebootet werden. Hass.io verwendet Docker und kann durch Addons (weitere Docker Container) erweitert werden.
Hassbian Auch hier wird lediglich ein Image auf die SD-Karte geschrieben. Hassbian ist ein Raspian auf dem beim ersten Booten automatisch Home Assistant installiert wird.
Manuelle Installation Die manuelle Installation kann theoretisch auf einem beliebigen Linux System erfolgen. Die verlinkte Anleitung zeigt wie auf einem Raspberry Pi vorgegangen werden kann.

Ich habe mich für Varainte 3, die manuelle Installation, entschieden. Mit dieser ist man am flexibelsten und kann z.B. auch die Komponente LIRC verwenden, wofür ich mit Variante 1 keine Lösung gefunden habe.

Um den Vorgang weitestgehend zu automatisieren habe ich Ansible verwendet. Es gibt bereits eine fertige Rolle für Home Assistant (untertstützt Debian/Raspbian und Fedora). Allerdings habe ich diese erst gefunden, nachdem ich bereits eine eigene Rolle angefangen hatte. Meine Rolle unterstützt lediglich Debian/Raspbian und ergibt im Zusammenspiel mit weiteren Rollen meine fertige Home Assistant Installation (weitere Rollen sind z.B. mosquitto oder lirc). Für die einzelnen Rollen sollen noch weitere erklärende Artikel folgen.

Dynamischer DNS Client für IPv6

2017-07-04T00:00:00+00:00

Dynamisches DNS wird genutzt um den DNS Eintrag für einen Host dessen IP sich regelmäßig und häufig ändert zu aktualisieren. Dies ermöglicht z.B. das Bereitstellen von Diensten hinter einem (V)DSL-Anschluss unter einem gleich bleibenden Namen. Es gibt mehrere Anbieter die einen solchen Dienst anbieten. Ich nutze z.B. SPDyn. Die Aktualisierung des DNS-Eintrags kann durch einen Client wie z.B. ddclient oder auch direkt über eine Fritzbox erfolgen. Für IPv4 Hosts ist das Verfahren einfach, die IP ist immer die des Routers der dann bestimmte Ports an interne Hosts weiterleitet (Portforwarding). Da ich von meinem Provider einen Dual-Stack Anschluss erhalten habe, hatte ich in der Vergangenheit auch einen AAAA-Record für IPv6 bei SPDyn angelegt. Worauf ich allerdings nicht achtete: mein Provider vergibt bei jedem Neuverbinden ein anderes IPv6 Präfix. Dadurch ändert sich also auch jedes mal die IPv6-Adresse meines internen Hosts. Aufmerksam auf diese Problematik wurde ich durch einen Fehler beim Erneuern meines Let’s Encrypt Zertifikats (vgl. Artikel zu acme-tiny).

Wenn ein AAAA-Record vorhanden ist bevorzugt Let’s Encrypt seit kurzem diesen um die Domain zu verifizieren (API Announcements). Da mein vor langer Zeit angelegter AAAA-Record sich mittlerweile (schon oft) geändert hat, schlug das Erneuern des Zertifikats also fehl.

Parsing account key...
Parsing CSR...
Registering account...
Already registered!
Verifying domain.com...
Traceback (most recent call last):
File "acme_tiny.py", line 199, in 
main(sys.argv[1:])
File "acme_tiny.py", line 195, in main
signed_crt = get_crt(args.account_key, args.csr, args.acme_dir, log=LOGGER, CA=args.ca)
File "acme_tiny.py", line 150, in get_crt
domain, challenge_status))
ValueError: domain.com challenge did not pass: {u'status': u'invalid', u'validationRecord': [{u'addressesResolved': [u'217.251.47.207', u'2003:86:2455:9c00:d1:3ff:fe81:bd3f'], u'url': u'http://domain.com/.well-known/acme-challenge/PDUNtwiHq5dncDrvs4V2NE9nSR9vLF2WhnAbX1jQ7f0', u'hostname': u'domain.com', u'addressesTried': [], u'addressUsed': u'2003:86:2455:9c00:d1:3ff:fe81:b46f', u'port': u'80'}], u'keyAuthorization': u'PDUNtwiHq5dncDrvs4V2NE9nSR9vLF2WhnAbX1jQ7f0.YW7Ac9LxjjuWvWzD542ZzSKxcFKDIdehVVzAuYA0vHI', u'uri': u'https://acme-v01.api.letsencrypt.org/acme/challenge/-yjij3RP1r4YC_TkQrUemgjhfWI17pQZSjMZ8kr-Lps/1441804350', u'token': u'PDUNtwiHq5dncDrvs4V2NE9nSR9vLF2WhnAbX1jQ7f0', u'error': {u'status': 400, u'type': u'urn:acme:error:connection', u'detail': u'Fetching http://domain.com/.well-known/acme-challenge/PDUNtwiHq5dncDrvs4V2NE9nSR9vLF2WhnAbX1jQ7f0: Timeout'}, u'type': u'http-01'}

In der Fehlerausgabe ist bei addressUsed zu sehen, dass eine IPv6-Adresse zur Überprüfung verwendet wird. Da die Adresse falsch ist kommt es zu einem Timeout.

Um diesen Fehler zu beheben und in Zukunft auch per IPv6 auf meinen Host zu Hause zugreifen zu können muss nicht nur der A-Record für IPv4 sondern eben auch der AAAA-Record für IPv6 bei einer Änderung aktualisiert werden.

Im Wiki von SPDyn wird beschrieben wie eine Fritzbox konfiguriert werden kann um IPv4 und IPv6 Einträge zu aktualisieren. Allerdings wird dann der AAAA-Record auf die IPv6-Adresse der Fritzbox aktualisiert und nicht auf die Adresse des eigentlichen Ziel-Hosts. Ich verwende die Fritzbox also nur um den A-Record für IPv4 zu aktualisieren. SPDyn ermöglicht das Aktualisieren der DNS-Einträge auch durch den Aufruf einer URL, z.B. mit wget. Für IPv6 habe ich mir deshalb ein kleines Script geschrieben, dass per Cronjob regelmäßig auf dem Host ausgeführt wird, auf den ich per IPv6 zugreifen möchte.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36


#!/bin/bash

USER="user"
PASSWORD="password"
HOSTNAME="subdomain.spdns.org"
CACHE_FILE="/tmp/update_ipv6_cache"

while getopts ":d" opt; do
 case $opt in
 d) DEBUG=1;;
 esac
done


IPV6=`ip addr show eth0 | grep 'scope global dynamic' | grep -Po 'inet6 \K[0-9a-fA-F:]+' | grep -v fd00`
URL="https://update.spdyn.de/nic/update?hostname=$HOSTNAME&myip=$IPV6"
if [ -f $CACHE_FILE ]; then
 IPV6_CACHE=`cat $CACHE_FILE`
else
 IPV6_CACHE=""
fi

if [[ $IPV6 == $IPV6_CACHE ]]; then
 if [[ $DEBUG -eq 1 ]]; then
 echo "IP not changed"
 fi
 exit
else
 echo $IPV6 > $CACHE_FILE
 if [[ $DEBUG -eq 1 ]]; then
 echo wget -q -O - "$URL" --http-user=$USER --http-password=$PASSWORD
 wget -q -O - "$URL" --http-user=$USER --http-password=$PASSWORD
 else
 wget -q -O - "$URL" --http-user=$USER --http-password=$PASSWORD >/dev/null 2>&1
 fi
fi

Durch Variablen werden die notwendigen Daten für den URL-Aufruf (z.B. User und Passwort) definiert. Im ersten Schritt wird die aktuelle IPv6-Adresse ermittelt (Zeile 15). In meinem Fall wird aus allen IPv6 Adressen für das Device eth0 die Adresse herausgefiltert die “global dynamisch” und keine lokale Adresse (fd00) ist. Unter Umständen muss das Ermitteln der richtigen IP angepasst werden. Danach wird die ermittelte IPv6-Adresse mit einem evtl. vorhandenen gecachten Wert verglichen (Zeile 23). Ergibt der Vergleich, dass sich die Adresse nicht geändert hat wird das Script beendet. Es ist keine Aktualisierung des DNS-Eintrags notwendig. Sind die beiden Adressen nicht identisch bzw. keine gecachte Adresse vorhanden wird die URL zum Aktualisieren des DNS-Eintrags mit wget aufgerufen (Zeile 34). Beim Start des Script mit dem Parameter -d (für Debug) wird zusätzlich der wget-Aufruf (Zeile 31) bzw. eine Info wenn sich die Adresse nicht geändert hat (Zeile 25) ausgegeben.

Per Cronjob wird das Script bei mir alle 15 Minuten gestartet und aktualisiert somit bei Bedarf den DNS-Eintrag bei SPDyn. Um mit dem Host kommunizieren zu können sind zusätzlich noch Portfreigaben für IPv6 in der Fritzbox notwendig. Nach dieser Änderung kann auf den Host nun per IPv6 zugegriffen werden und auch die Erneuerung des Let’s Encrypt Zertifikats funktioniert wieder.

Geschwindigkeit bei Zugriff von Mac OS X auf Samba Share

2016-09-07T00:00:00+00:00

Ich nutze meinen Cubietruck als Samba Server. Irgendwann fiel mir auf, dass die Geschwindigkeit beim Kopieren von meinem Mac mit OS X El Capitan nur knapp über 10 MB/s lag. Da der Cubietruck eine Gigabit-Netzwerkkarte hat, sollte das um einiges schneller gehen. Außerdem war ich der Meinung früher schon Werte um die 30 MB/s gesehen zu haben. Der Gigabit-Anschluss wäre damit zwar auch noch nicht ausgelastet, aber immerhin.

Nach etwas Recherche im Internet habe ich eine Einstellung (Heise Artikel) gefunden mit der die Geschwindigkeit wieder auf bis zu 30 MB/s steigt. OS X verwendet wohl seit Version 10.11.5 standardmäßig SMB Signing. Das Tool smbutil zeigt die Samba Version und Optionen für aktuell verbundene Freigaben an:

Mini:~ johannes$ smbutil statshares -a
==================================================================================================
SHARE ATTRIBUTE TYPE VALUE
==================================================================================================
media
SERVER_NAME cubie
USER_ID 502
SMB_NEGOTIATE AUTO_NEGOTIATE
SMB_VERSION SMB_3.0
SMB_SHARE_TYPE DISK
SIGNING_SUPPORTED TRUE
EXTENDED_SECURITY_SUPPORTED TRUE
LARGE_FILE_SUPPORTED TRUE
CLIENT_REQUIRES_SIGNING TRUE
FILE_IDS_SUPPORTED TRUE
DFS_SUPPORTED TRUE
MULTI_CREDIT_SUPPORTED TRUE
ENCRYPTION_SUPPORTED TRUE
SIGNING_ON TRUE
--------------------------------------------------------------------------------------------------

Die Zeile “SIGNING_ON TRUE” zeigt, dass SMB Signing aktiviert ist. Diese Konfiguration kann in der Datei ~/Library/Preferences/nsmb.conf geändert werden:

Mini:~ johannes$ echo "[default]" >> ~/Library/Preferences/nsmb.conf; echo "signing_required=no" >> ~/Library/Preferences/nsmb.conf
Mini:~ johannes$ cat ~/Library/Preferences/nsmb.conf
[default]
signing_required=no

Nach einem Neustart oder dem Trennen aller Verbindungen zum Samba Server und erneuten Verbinden sollte SMB Signing deaktiviert sein (SIGNING_ON wird nicht aufgeführt):

Mini:~ johannes$ smbutil statshares -a
==================================================================================================
SHARE ATTRIBUTE TYPE VALUE
==================================================================================================
media
SERVER_NAME cubie
USER_ID 502
SMB_NEGOTIATE AUTO_NEGOTIATE
SMB_VERSION SMB_3.0
SMB_SHARE_TYPE DISK
SIGNING_SUPPORTED TRUE
EXTENDED_SECURITY_SUPPORTED TRUE
LARGE_FILE_SUPPORTED TRUE
FILE_IDS_SUPPORTED TRUE
DFS_SUPPORTED TRUE
MULTI_CREDIT_SUPPORTED TRUE
ENCRYPTION_SUPPORTED TRUE
--------------------------------------------------------------------------------------------------

Um wieder auf den Standard zurück zu wechseln reicht es die Datei ~/Library/Preferences/nsmb.conf zu löschen.

Um SMB Signing über ~/Library/Preferences/nsmb.conf nicht global zu deaktivieren, kann der Share auch mit cifs://Hostname statt mit smb://Hostname verbunden werden. Dadurch wird automatisch Samba Version 1 ohne SMB Signing verwendet:

Mini:~ johannes$ smbutil statshares -a
==================================================================================================
SHARE ATTRIBUTE TYPE VALUE
==================================================================================================
pyload
SERVER_NAME cubie
USER_ID 502
SMB_NEGOTIATE SMBV_NEG_SMB1_ONLY
SMB_VERSION SMB_1
SMB_SHARE_TYPE UNKNOWN
EXTENDED_SECURITY_SUPPORTED TRUE
UNIX_SUPPORT TRUE
LARGE_FILE_SUPPORTED TRUE
CLIENT_REQUIRES_SIGNING TRUE
--------------------------------------------------------------------------------------------------

PowerShell Scripte mit WhatIf

2016-08-04T00:00:00+00:00

Manchmal ist es sinnvoll den Aufruf eines eigenen PowerShell Scripts nur zu simulieren. Statt die Aktionen wirklich auszuführen möchte man lediglich sehen was passieren würde. Viele Cmdlets unterstützen den Parameter -WhatIf. Benutzt man diesen z.B. beim Anlegen eines Verzeichnis wird dieses nicht erstellt, sondern lediglich die im Beispiel angezeigte Meldung ausgegeben:

1

New-Item -ItemType Directory -Name "test" -Path "c:\temp" -WhatIf

PS C:\> New-Item -ItemType Directory -Name "test" -Path "c:\temp" -WhatIf
What if: Performing the operation "Create Directory" on target "Destination: C:\temp\test".

In einem eigenen Script kann die Option -WhatIf durch CmdletBinding verwendet werden.

1
2
3
4
5
6


[CmdletBinding(SupportsShouldProcess=$True)]
Param()

Get-ChildItem -Directory "c:\temp"
Out-File -FilePath "c:\temp\Test-WhatIf.log" -InputObject "Text" -Encoding ASCII
New-Item -ItemType Directory -Name "test" -Path "c:\temp"

Das Script lautet Test-WhatIf.ps1. Gibt man beim Aufruf den Parameter WhatIf an, werden alle Cmdlets die WhatIf unterstützen ausgeführt als wäre der Parameter im Code selbst angegeben. Das Cmdlet Get-ChildItem z.B. unterstützt WhatIf nicht, der Inhalt wird also aufgelistet.

PS C:\> ./Test-WhatIf.ps1 -WhatIf
Directory: C:\temp
Mode LastWriteTime Length Name
---- ------------- ------ ----
d---- 19.05.2016 14:58 directory1
d---- 11.07.2016 10:22 directory2
d---- 06.07.2016 15:56 directory3
d---- 19.05.2016 15:12 directory4
What if: Performing the operation "Output to File" on target "c:\temp\Test-WhatIf.log".
What if: Performing the operation "Create Directory" on target "Destination: C:\temp\test".

Evtl. möchte man aber auch Teile des Scripts trotzdem ausführen. In diesem Fall kann man -WhatIf manuell auf $False setzen:

1
2
3
4
5
6


[CmdletBinding(SupportsShouldProcess=$True)]
Param()

Get-ChildItem -Directory "c:\temp"
Out-File -FilePath "c:\temp\Test-WhatIf.log" -InputObject "Text" -Encoding ASCII -WhatIf:$False
New-Item -ItemType Directory -Name "test" -Path "c:\temp"

Das Script schreibt den Text in die Datei, erstellt das Verzeichnis aber nicht.

PS C:\> ./Test-WhatIf.ps1 -WhatIf
Directory: C:\temp
Mode LastWriteTime Length Name
---- ------------- ------ ----
d---- 19.05.2016 14:58 directory1
d---- 11.07.2016 10:22 directory2
d---- 06.07.2016 15:56 directory3
d---- 19.05.2016 15:12 directory4
What if: Performing the operation "Create Directory" on target "Destination: C:\temp\test".
PS C:\> Get-Content "c:\temp\Test-WhatIf.log"
Text

Ausserdem kann es sinnvoll sein im Script zu unterscheiden, ob es mit -WhatIf augerufen wurde oder nicht. Dafür kann die Variable $WhatIfPreference genutzt werden:

1
2
3
4
5
6
7
8


[CmdletBinding(SupportsShouldProcess=$True)]
Param()

If ($WhatIfPreference) {
 Write-Host "aufgerufen mit WhatIf"
} Else {
 Write-Host "aufgerufen ohne WhatIf"
}

PS C:\> ./Test-WhatIf.ps1 -WhatIf
aufgerufen mit WhatIf
PS C:\> ./Test-WhatIf.ps1
aufgerufen ohne WhatIf

Infrarot Fernbedienung (z.B. Logitech Harmony) mit WeTek OpenELEC

2016-07-27T00:00:00+00:00

WeTek OpenELEC ist eine kleine Box mit installiertem OpenELEC, welches wiederum auf Kodi basiert. WeTek OpenELEC enthält je nach Variante bereits einen Tuner (DVB-C/T, DVB-S oder ATSC). Bei mir hat die Box einen Raspberry Pi ersetzt. Zum Lieferumfang gehört eine AirMouse. Das ist eine Fernbedienung die sich durch Bewegungssensoren auch als Maus verwenden lässt. Da ich aber bereits eine Logitech Harmony als Universalfernbedienung verwende, soll diese die Steuerung übernehmen. Bei WeTek OpenELEC handelt es sich um eine Sonderedition von WeTek Play (Unterschiede zwischen WeTek Play und WeTek OpenELEC). Die Einrichtung einer Fernbedienung sollte für WeTek Play also ähnlich sein.

WeTek OpenELEC hat einen Infrarotempfänger eingebaut. Standardmäßig wird dieser jedoch nur zum Ein- und Ausschalten des Geräts verwendet. Die Steuerung der anderen Funktionen ist etwas komplizierter einzurichten. Ich werde zuerst erklären wie man (um sich Arbeit zu sparen) meine Konfiguration übernehmen kann. Danach gibt es mehr Details wie die Vorgehensweise war und die Konfiguration auch für andere Fernbedienungen selbst angepasst werden kann. Die verwendete Fernbedienung muss das NEC Protokoll verwenden.

Steuerung mit Logitech Harmony als Mut@nt HD2400 konfiguriert

Um möglichst viele Tasten der Harmony Fernbedienung nutzen zu können habe ich als Gerät “Mut@nt HD2400” konfiguriert. Wählt man als Gerät WeTek Play aus bleiben leider viele Tasten der Harmony ohne Funktion.

Die Tasten und die jeweilige Aktion werden auf WeTek OpenELEC über die Datei remote.conf gesteuert. Für eine möglichst schnelle Konfiguration stelle ich meine Datei hier bereit.

Es muss also für die Harmony das Gerät Muta@nt HD2400 hinzugefügt (und in gewünschte Aktionen aufgenommen) werden. Danach per Samba (\<IP_des_Geräts>\Configfiles) auf die Box verbinden, eine Sicherheitskopie der remote.conf anlegen und sie danach durch meine Version ersetzen. Nach einem Neustart sollte sich WeTek OpenELEC mit der Harmony steuern lassen.

Zusätzlich habe ich noch einige weitere Tasten konfiguriert:

Sie sind in der remote.conf auf die Tasten M, S, L, Z, T und V gemappt. T und L sind in der Standardkonfiguration von Kodi den Aktionen “Untertitel umschalten” und “Videotext” zugeordnet. Die anderen Tasten können über eine eigene Keymap (Datei keymap.xml) Aktionen zugeordnet werden. In meinem Fall sind dies M = “Ansicht Filme”, S = “Ansicht Serien”, L = “Audiospur umschalten” und Z = “TV”. Des Weiteren enthält die Keymap die Tasten zur Navigation im Videotext (red, green, yellow, blue). Die keymap.xml wird unter \<IP_des_Geräts>\Userdata\keymaps abgelegt.

Codes für beliebige (NEC) Fernbedienung ermitteln

Wie kann man selbst eine beliebige Fernbedienung für WeTek OpenELEC konfigurieren? Als erstes muss der SSH Zugang zu der Box in den Einstellungen aktiviert werden. Das Standardpasswort für den Benutzer root lautet openelec. Jetzt kann eine beliebige Taste auf der Fernbedienung gedrückt werden. Mit dmesg -c | grep custom erhält man den Factory Code für seine Fernbedienung:

OpenELEC:~ # dmesg -c | grep custom
[ 1657.693666@0] Wrong custom code is 0xe21d1f00

Dieser muss in die Datei remote.conf eingetragen werden. Entweder man editiert die Datei direkt in der SSH Sitzung (z.B. vi /storage/.config/remote.conf) oder mit einem beliebigen Editor über die Freigabe \<IP_des_Geräts>\Configfiles. In der Datei muss der ermittelte Code in die Zeile die mit “factory_code” beginnt eingetragen werden. Dabei müssen die ersten 4 Zeichen nach “factory_code = 0x” mit den letzten 4 Zeichen der Ausgabe mit “Wrong custom code” ersetzt werden. Aus 0xff000001 (Wert bei Auslieferung) wird bei diesem Beispiel also 0x1f000001.

OpenELEC:~ # head -n 15 /storage/.config/remote.conf
# WeTek Play NEC remote
factory_code = 0x1f000001
work_mode = 1
repeat_enable = 1
release_delay = 150
debug_enable = 1
reg_control = 0xfbe40
key_begin
; Code = IR keycode
; Linux = Linux keycode
; Android = Android keycode
; Button = Description button on Logitech remote
; KODI = Action in KODI (focus on video playback)
; Further info: http://kodi.wiki/view/Keyboard_controls

Damit die Änderung an der remote.conf aktiv wird, muss das System entweder neu gestartet oder der Befehl remotecfg /storage/.config/remote.conf ausgeführt werden. Danach kommt der aufwendige Teil: Für jede Taste muss der Code ermittelt werden. Dafür muss zuerst die gewünschte Taste auf der Fernbedienung gedrückt und danach der empfangene Code ausgelesen werden:

OpenELEC:~ # dmesg -c | grep scan
[ 3135.540356@0] scancode is 0x002b, invalid key is 0x0000.
[ 3135.812065@0] scancode is 0x002b, invalid key is 0x0000.
OpenELEC:~ # dmesg -c | grep scan
[ 3163.433223@0] scancode is 0x0028, invalid key is 0x0000.
[ 3163.702069@0] scancode is 0x0028, invalid key is 0x0000.

Jedem empfangenen Code (scancode) wird ein Keycode zugeordnet, der wiederum eine Aktion in Kodi auslöst. Meine remote.conf enthält bereits die wichtigsten Keycodes wie z.B. 114 und 115 zum Verändern der Lautstärke (siehe Erklärung der Funktion in der Spalte “Kodi”). Einige der gültigen Keycodes können dieser Liste entnommen werden.

Die Tasten werden im Bereich zwischen “key_begin” und “key_end” definiert. Die bereits vorhandenen können einfach geändert werden. Dafür muss der Wert in der ersten Spalte “Code” auf die Codes der eigenen Fernbedienung angepasst werden. Nicht benötigte Zeilen werden mit ; oder # auskommentiert. Für die Codes aus dem Beispiel könnte das wie folgt aussehen:

key_begin
0x2b 114 # Vol -
0x28 115 # Vol +
key_end

Wenn alle Codes in der remote.conf eingetragen wurden kann die neue Konfiguration mit remotecfg /storage/.config/remote.conf aktiviert werden.

Die Vorgehensweise wird auch in diesem Foreneintrag erläutert.

Intermediate Zertifikat für acme-tiny

2016-06-14T00:00:00+00:00

Wie im Artikel zu acme-tiny erwähnt muss ein eigenes Script zum regelmäßigen Erneuern der Let’s Encrypt Zertifikate erstellt werden. In diesem Script wird das passende Intermediate Zertifikat von Let’s Encrypt heruntergeladen, damit dem Besucher die vollständige Zertifizierungs-Kette übermittelt werden kann. Wird das Intermediate Zertifikat vom Webserver nicht ausgeliefert, fällt die Bewertung von SSL Labs auf “B” zurück.

Das Intermediate Zertifikat von Let’s Encrypt hat sich zwischenzeitlich geändert. In der Beschreibung zu acme-tiny bei Github wurde die URL zum Download deshalb angepasst.

Um jedoch einen weiteren Wechsel in Zukunft abzufangen kann die URL zum Download des Intermediate Zertifkats aus dem Zertifkat ausgelesen werden. Das vollständige Script könnte so ähnlich aussehen:

1
2
3
4
5
6
7


#!/bin/bash
python /path/to/acme_tiny.py --account-key /path/to/account.key --csr /path/to/domain.csr --acme-dir /var/www/challenges/ > /tmp/signed.crt || exit
URL=`openssl x509 -in signed.crt -text -noout | grep "CA Issuers - URI:" | cut -d":" -f2,3`
wget -O - $URL > /tmp/intermediate.der
openssl x509 -in /tmp/intermediate.der -inform der -outform pem -out /tmp/intermediate.pem
cat /tmp/signed.crt /tmp/intermediate.pem > /path/to/chained.pem
service nginx reload

In Zeile 3 wird die URL des Intermediate Zertifikats bestimmt und in Zeile 4 heruntergeladen. Zeile 5 ändert das Format des Intermediate Zertifikats und in Zeile 6 werden das Intermediate Zertifikat und das Zertfikat für die Domain kombiniert in einer Datei gespeichert (je nach Konfiguration und verwendeten Webserver evtl. nicht notwendig).

Passwörter in PowerShell

2016-06-01T00:00:00+00:00

Bei verschiedenen Gelegenheiten kann es vorkommen, dass man Passwörter in Powershell verwenden muss. Soll z.B. ein anderer Rechner heruntergefahren und für die Authentifizierung ein anderer als der aktuell angemeldete Benutzer verwendet werden, müssen Benutzername und Passwort angegeben werden. Diese können mit Get-Credential zur Laufzeit abgefragt werden:

1
2


$Credential = Get-Credential
Stop-Computer -Computer 192.168.2.10 -Credential $Credential -WhatIf

Der Benutzername kann auch vorbelegt werden, so dass statt Benutzernamen und Passwort nur noch das Passwort eingegeben werden muss:

1
2


$Credential = Get-Credential -Credential "Domain\User"
Stop-Computer -Computer 192.168.2.10 -Credential $Credential -WhatIf

Erstellt man ein Script das ohne Benutzereingaben laufen muss (z.B. ein Nagios Plugin oder Scheduled Task), kann das Passwort auch direkt im Script angegeben werden. Dort muss es allerdings in einen SecureString umgewandelt werden.

1
2
3


$SecurePassword = ConvertTo-SecureString "SecurePassword" -AsPlainText -Force
$Credentials = New-Object System.Management.Automation.PSCredential("Domain\User", $SecurePassword)
Stop-Computer -Computer 192.168.2.10 -Credential $Credential -WhatIf

Diese Variante ist jedoch ziemlich unsicher und sollte unbedingt vermieden werden. Jeder der Zugriff auf das Script hat kann auch das Passwort auslesen. Ein solches Script in öffentlichen oder halb-öffentlichen Code Repositories (z.B. GitHub) zu verwalten ist ein hohes Sicherheitsrisiko. Eine einfache Suche könnte so die Passwörter zurückgeben.

Man könnte das Passwort als Parameter übergeben. Aber auch so wird evtl. das Passwort im Klartext in einer Datei gespeichert (z.B. bei der Definition eines Nagios Checks) oder ist in der Konfiguration eines Scheduled Tasks zu sehen:

1
2
3
4
5
6
7
8


Param(
 [Parameter(Mandatory=$True)]
 [string]$Password
)

$SecurePassword = ConvertTo-SecureString $Password -AsPlainText -Force
$Credentials = New-Object System.Management.Automation.PSCredential("Domain\User", $SecurePassword)
Stop-Computer -Computer 192.168.2.10 -Credential $Credential -WhatIf

Das Passwort kann auch als verschlüsselter String in einer Datei gespeichert werden. Dafür wird das Passwort einmalig eingelesen, verschlüsselt und z.B. in der Datei password.txt abgespeichert.

1
2
3


$SecurePassword = Read-Host -AsSecureString
$EncryptedPassword = ConvertFrom-SecureString -SecureString $SecurePassword
Set-Content -Path "password.txt" -Value $EncryptedPassword

Danach kann das Passwort immer wieder aus dieser Datei eingelesen werden:

1
2
3
4


$EncryptedPassword = Get-Content -Path "password.txt"
$SecurePassword = ConvertTo-SecureString -String $EncryptedPassword
$Credentials = New-Object System.Management.Automation.PSCredential "Domain\User", $SecurePassword
Stop-Computer -Computer 192.168.2.10 -Credential $Credential -WhatIf

Für die Verschlüsselung des Passwortes wird die Windows Data Protection API (DPAPI) verwendet. Aus diesem Grund ist das verschlüsselte Passwort immer nur für den bei der Erstellung verwendeten Benutzer und Host gültig. Außerdem ist das abgespeicherte Passwort ungültig sobald sich das Passwort des Windows-Benutzers ändert. Um das Passwort unabhängig vom angemeldeten Benutzer und verwendeten Host zu machen, kann der Parameter Key oder SecureKey beim Erstellen des Passworts verwendet werden. Bei Key wird ein Schlüssel als ByteArray angegeben, bei SecureKey als SecureString. In beiden Fällen wird zusätzlich zur Datei mit dem verschlüsselten Passwort ein weitere Datei, die den verwendeten Key (im Beispiel key.txt) enthält, abgelegt.

Parameter Key

Einmaliges Erstellen eines zufälligen Keys (ByteArray):

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


Function RandomByte {
 $RandomByte = @()
 For ($i=1; $i -le 16; $i++) {
 [Byte]$RByte = Get-Random -Minimum 0 -Maximum 256
 $RandomByte += $RByte
 }
 $RandomByte
}
$Key = RandomByte
$Key | out-file "key.txt"
$SecurePassword = ConvertTo-SecureString -String "SecurePassword" -AsPlainText -Force
$EncryptedPassword = ConvertFrom-SecureString -SecureString $SecurePassword -Key $Key
Set-Content -Path "password.txt" -Value $EncryptedPassword

Einlesen des Passwortes und Keys:

1
2
3
4


$EncryptedPassword = Get-Content -Path "password.txt"
$Key = Get-Content -Path "key.txt"
$SecurePassword = ConvertTo-SecureString -String $EncryptedPassword -Key $Key
$Credentials = New-Object System.Management.Automation.PSCredential "User", $SecurePassword

Parameter SecureKey

Einmaliges Erstellen eines zufälligen Keys (SecureString):

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


Function RandomString {
 $RandomString = ""
 For ($i=1; $i -le 16; $i++) {
 [Char]$RChar = Get-Random -Minimum 33 -Maximum 127
 $RandomString += $RChar
 }
 $RandomString
}
$KeyString = RandomString
Set-Content -Path "key.txt" -Value $KeyString
$SecurePassword = ConvertTo-SecureString -String "SecurePassword" -AsPlainText -Force
$Key = ConvertTo-SecureString -String $KeyString -AsPlainText -Force
$EncryptedPassword = ConvertFrom-SecureString -SecureString $SecurePassword -SecureKey $Key
Set-Content -Path "password.txt" -Value $EncryptedPassword

Einlesen des Passwortes und Keys:

1
2
3
4
5


$EncryptedPassword = Get-Content -Path "password.txt"
$KeyString = Get-Content -Path "key.txt"
$Key = ConvertTo-SecureString -String $KeyString -AsPlainText -Force
$SecurePassword = ConvertTo-SecureString -String $EncryptedPassword -SecureKey $Key
$Credentials = New-Object System.Management.Automation.PSCredential "User", $SecurePassword

Fazit

Nach Möglichkeit sollte das Passwort zur Laufzeit mit Get-Credential oder Read-Host eingelesen werden. Muss das Script automatisiert werden und wird immer von dem selben Benutzer auf dem selben Host gestartet, kann das Passwort als SecureString in einer Datei abgelegt werden. Ist dies nicht möglich muss der Key zum Verschlüsseln des Passworts ebenfalls entweder mit -Key oder -SecureKey in einer zusätzlichen Datei abgelegt werden.

Auch wenn das Passwort bei den beschriebenen Verfahren nicht in Klartext gespeichert wird ist es für einen erfahrenen Benutzer unter Umständen möglich das eigentliche Passwort auszulesen. Die Dateie(en) mit den verschlüsselten Daten sollte also zusätzlich durch weitere Maßnahmen (z.B. NTFS Berechtigungen) geschützt werden.

NetApp vFiler DR mit Data ONTAP Simulator Teil 10: Disaster Failover

2016-05-14T00:00:00+00:00

Dies ist Teil einer Artikelserie.

Im Prinzip läuft der Disaster Failover ähnlich wie der geplante Failover aus Teil 9 ab. Da der Master überraschend ausfällt, kann allerdings der vFiler nicht gestoppt und auch die temporäre Replikation vom Slave zum Master nicht bereits bei der Aktivierung des Slave eingerichtet werden. Beim Einschalten des Masters muss deshalb sicher gestellt werden, dass der vFiler nicht automatisch startet und somit auf Slave und Master gleichzeitig läuft. Sobald der Master wieder verfügbar ist muss außerdem die Replikation vom Slave zum Master angelegt und abgeschlossen werden, bevor der alte Master wieder den vFiler übernimmt. Im Vergleich zum geplanten Failover wandern Schritte 1, 4 und 5 vom Failover also in den Rollback.

Disaster Failover von Master zu Slave:

vFiler DR auf Slave starten => “running”

netapp02> vfiler dr activate vfiler01@netapp01
CIFS local server is running.
Mon May 9 22:01:06 CEST [vfiler01@netapp02:cifs.startup.local.succeeded:info]: CIFS: CIFS local server is running.
Mon May 9 22:01:06 CEST [netapp02:httpd.config.mime.missing:warning]: /etc/httpd.mimetypes.sample file is missing.
Mon May 9 22:01:06 CEST [vfiler01@netapp02:httpd.config.mime.missing:warning]: /etc/httpd.mimetypes file is missing.
Mon May 9 22:01:06 CEST [vfiler01@netapp02:httpd.config.mime.missing:warning]: /etc/httpd.mimetypes.sample file is missing.
Mon May 9 22:01:06 CEST [netapp02:wafl.scan.ownblocks.done:info]: Completed block ownership calculation on volume vol_vfiler01. The scanner took 0 ms.
Vfiler vfiler01 activated.
e0a: flags=0xe48867 mtu 1500
inet 192.168.2.67 netmask 0xffffff00 broadcast 192.168.2.255
ether 00:0c:29:61:01:2b (auto-1000t-fd-up) flowcontrol full
netapp02> Mon May 9 22:01:07 CEST [netapp02:cmds.vfiler.dr.activated:info]: Disaster recovery backup vFiler unit: 'vfiler01' of the vFiler unit at remote storage system: 'netapp01' was activated.
Mon May 9 22:01:11 CEST [vfiler01@netapp02:export.host.resolve.timeout:warning]: Trial 1 for the nameservice lookup request timed out.
Mon May 9 22:01:30 CEST [vfiler01@netapp02:nbt.nbns.registrationComplete:info]: NBT: All CIFS name registrations have completed for the local server.
netapp02> vfiler status
vfiler0 running
vfiler01 running

State des SnapMirrors prüfen => “Broken-off” auf Slave

netapp02> snapmirror status
Snapmirror is on.
Source Destination State Lag Status
netapp01_vfiler01_con:vol_vfiler01 netapp02:vol_vfiler01 Broken-off 00:02:30 Idle

Wie bereits erwähnt sollte der vFiler auf dem Master (netapp01) nicht gestartet werden, solange er noch auf dem Slave (netapp02) läuft. Um dies zu verhindern kann z.B. das automatische Booten von Data ONTAP auf dem Master deaktiviert werden. Wenn Data ONTAP nicht automatisch bootet, wird auch der vFiler nicht gestartet. Data ONTAP muss dann manuell gebootet (Befehl: boot_ontap) und sofort danach der vFiler gestoppt werden (vfiler stop vfiler). Alternativ kann auch vor dem Booten von Data ONTAP die IP Konfiguration des vFilers deaktiviert werden.

Rollback von Slave zu Master

Resync von Slave auf Master (-s für synchrone Replizierung)

netapp01> vfiler dr resync -s vfiler01@netapp02
One can optionally provide an alternate ip
path for sync snapmirroring
Alternate IP address/Hostname for remote filer netapp02 []:
Alternate IP address/Hostname for local filer netapp01 []:
netapp02's Administrative login: root
netapp02's Administrative password:
CIFS local server on vFiler vfiler01 is shutting down...
waiting for CIFS shut down (^C aborts)...
CIFS local server on vfiler vfiler01 has shut down...
Mon May 9 22:06:03 CEST [vfiler01@netapp01:telnet_0:notice]: IP address 192.168.2.68 is removed from interface "e0a"
Configuring SnapMirror to mirror vfiler vfiler01's storage units from remote filer netapp02.
Starting snapmirror initialize commands. It
could take a very long time when the source or
destination filers are involved in many
simultaneous transfers. The console will not be
available until all initialize commands are
started successfully. Please use the
"snapmirror status" command on the source
filer to monitor the progress.
Mon May 9 22:06:07 CEST [netapp01:snapmirror.dst.resync.info:notice]: SnapMirror resync of vol_vfiler01 to netapp02:vol_vfiler01 is using netapp02(4082368507)_vol_vfiler01.27 as the base snapshot.
Mon May 9 22:06:07 CEST [netapp01:vFiler.storageUnit.off:warning]: vFiler vfiler01: storage unit /vol/vol_vfiler01 now offline.
Mon May 9 22:06:08 CEST [netapp01:wafl.snaprestore.revert:info]: Reverting volume vol_vfiler01 to a previous snapshot.
Mon May 9 22:06:09 CEST [netapp01:vFiler.storageUnit.On:notice]: vFiler vfiler01: storage unit /vol/vol_vfiler01 now online.
Revert to resync base snapshot was successful.
Mon May 9 22:06:10 CEST [netapp01:replication.dst.resync.success:notice]: SnapMirror resync of vol_vfiler01 to netapp02:vol_vfiler01 was successful.
SnapMirror transfer initiated for vfiler storage units.

SnapMirror von netapp02 (Source) auf netapp01 (Destination) prüfen => zusätzliche Einträge mit State “Snapmirrored” auf Master und “Source” auf Slave

netapp01> snapmirror status
Snapmirror is on.
Source Destination State Lag Status
netapp02_vfiler01_con:vol_vfiler01 netapp01:vol_vfiler01 Snapmirrored 00:00:39 Idle
netapp01:vol_vfiler01 netapp02:vol_vfiler01 Source 00:06:42 Idle

netapp02> snapmirror status
Snapmirror is on.
Source Destination State Lag Status
netapp01_vfiler01_con:vol_vfiler01 netapp02:vol_vfiler01 Broken-off 00:07:17 Idle
netapp02:vol_vfiler01 netapp01:vol_vfiler01 Source 00:00:21 Idle

Warten bis SnapMirror von netapp02 (Source) auf netapp01 (Destination) “In-sync”

netapp01> snapmirror status
Snapmirror is on.
Source Destination State Lag Status
netapp02_vfiler01_con:vol_vfiler01 netapp01:vol_vfiler01 Snapmirrored 00:00:00 In-sync
netapp01:vol_vfiler01 netapp02:vol_vfiler01 Source 00:08:10 Idle

netapp02> snapmirror status
Snapmirror is on.
Source Destination State Lag Status
netapp01_vfiler01_con:vol_vfiler01 netapp02:vol_vfiler01 Broken-off 00:08:27 Idle
netapp02:vol_vfiler01 netapp01:vol_vfiler01 Source 00:00:00 In-sync

vFiler auf Slave stoppen => “stopped”

netapp02> vfiler stop vfiler01
vfiler01 stopped
Mon May 9 22:09:45 CEST [netapp02:vf.stopped:warning]: vfiler: 'vfiler01'; stopped
netapp02> vfiler status
vfiler0 running
vfiler01 stopped

vFiler auf Master starten => “running”

netapp01> vfiler dr activate vfiler01@netapp02
Waiting for "vol_vfiler" to become stable.
Mon May 9 22:10:51 CEST [netapp01:snapmirror.sync.fail:notice]: Synchronous SnapMirror from netapp02_vfiler01_con:vol_vfiler to netapp01:vol_vfiler01 failed.
Mon May 9 22:10:58 CEST [netapp01:wafl.scan.ownblocks.done:info]: Completed block ownership calculation on volume vol_vfiler01. The scanner took 0 ms.
CIFS local server is running.
Mon May 9 22:10:58 CEST [vfiler01@netapp01:cifs.startup.local.succeeded:info]: CIFS: CIFS local server is running.
Mon May 9 22:10:58 CEST [netapp01:httpd.config.mime.missing:warning]: /etc/httpd.mimetypes.sample file is missing.
Mon May 9 22:10:58 CEST [vfiler01@netapp01:httpd.config.mime.missing:warning]: /etc/httpd.mimetypes file is missing.
Mon May 9 22:10:58 CEST [vfiler01@netapp01:httpd.config.mime.missing:warning]: /etc/httpd.mimetypes.sample file is missing.
Vfiler vfiler01 activated.
e0a: flags=0xe48867 mtu 1500
inet 192.168.2.66 netmask 0xffffff00 broadcast 192.168.2.255
inet 192.168.2.69 netmask 0xffffff00 broadcast 192.168.2.255
ether 00:0c:29:ee:ee:f2 (auto-1000t-fd-up) flowcontrol full
netapp01> Mon May 9 22:10:59 CEST [netapp01:cmds.vfiler.dr.activated:info]: Disaster recovery backup vFiler unit: 'vfiler01' of the vFiler unit at remote storage system: 'netapp02' was activated.
Mon May 9 22:11:22 CEST [vfiler01@netapp01:nbt.nbns.registrationComplete:info]: NBT: All CIFS name registrations have completed for the local server.
netapp01> vfiler status
vfiler0 running
vfiler01 running

Status des SnapMirrors von netapp02 (Source) auf netapp01 (Destination) prüfen => “Source” auf netapp02 und “Broken-off” auf netapp01

netapp01> snapmirror status
Snapmirror is on.
Source Destination State Lag Status
netapp02_vfiler01_con:vol_vfiler01 netapp01:vol_vfiler01 Broken-off 00:03:45 Idle
netapp01:vol_vfiler01 netapp02:vol_vfiler01 Source 00:12:19 Idle

netapp02> snapmirror status
Snapmirror is on.
Source Destination State Lag Status
netapp01_vfiler01_con:vol_vfiler01 netapp02:vol_vfiler01 Broken-off 00:13:03 Idle
netapp02:vol_vfiler 01 netapp01:vol_vfiler01 Source 00:04:29 Idle

Resync von Master auf Slave => Status SnapMirror von netapp01 (Source) auf netapp02 (Destination) “In-sync” (dauert eine Weile)

netapp02> vfiler dr resync -s vfiler01@netapp01
One can optionally provide an alternate ip
path for sync snapmirroring
Alternate IP address/Hostname for remote filer netapp01 []:
Alternate IP address/Hostname for local filer netapp02 []:
netapp01's Administrative login: root
netapp01's Administrative password:
CIFS local server on vFiler vfiler01 is shutting down...
waiting for CIFS shut down (^C aborts)...
CIFS local server on vfiler vfiler01 has shut down...
Mon May 9 22:14:02 CEST [vfiler01@netapp02:telnet_0:notice]: IP address 192.168.2.68 is removed from interface "e0a"
Configuring SnapMirror to mirror vfiler vfiler01's storage units from remote filer netapp01.
Starting snapmirror initialize commands. It
could take a very long time when the source or
destination filers are involved in many
simultaneous transfers. The console will not be
available until all initialize commands are
started successfully. Please use the
"snapmirror status" command on the source
filer to monitor the progress.
Mon May 9 22:14:06 CEST [netapp02:snapmirror.dst.resync.info:notice]: SnapMirror resync of vol_vfiler01 to netapp01:vol_vfiler01 is using netapp01(4082368508)_vol_vfiler01.4 as the base snapshot.
Mon May 9 22:14:06 CEST [netapp02:vFiler.storageUnit.off:warning]: vFiler vfiler01: storage unit /vol/vol_vfiler01 now offline.
Mon May 9 22:14:07 CEST [netapp02:wafl.snaprestore.revert:info]: Reverting volume vol_vfiler01 to a previous snapshot.
Mon May 9 22:14:08 CEST [netapp02:vFiler.storageUnit.On:notice]: vFiler vfiler01: storage unit /vol/vol_vfiler01 now online.
Revert to resync base snapshot was successful.
Mon May 9 22:14:08 CEST [netapp02:replication.dst.resync.success:notice]: SnapMirror resync of vol_vfiler01 to netapp01:vol_vfiler01 was successful.
SnapMirror transfer initiated for vfiler storage units.
netapp02> snapmirror status
Snapmirror is on.
Source Destination State Lag Status
netapp01_vfiler01_con:vol_vfiler01 netapp02:vol_vfiler01 Snapmirrored 00:00:00 In-sync
netapp02:vol_vfiler01 netapp01:vol_vfiler01 Source 00:07:31 Idle

netapp01> snapmirror status
Snapmirror is on.
Source Destination State Lag Status
netapp02_vfiler01_con:vol_vfiler01 netapp01:vol_vfiler01 Broken-off 00:07:56 Idle
netapp01:vol_vfiler01 netapp02:vol_vfiler01 Source 00:00:00 In-sync

SnapMirror Beziehungen von Slave zu Master löschen

netapp02> snapmirror release vol_vfiler01 netapp01:vol_vfiler01
snapmirror release: vol_vfiler01 netapp01:vol_vfiler01: No release-able destination found that matches those parameters. Use 'snapmirror destinations' to see a list of release-able destinations.

netapp01> snapmirror release vol_vfiler01 netapp01:vol_vfiler01
snapmirror release: vol_vfiler01 netapp01:vol_vfiler01: No release-able destination found that matches those parameters. Use 'snapmirror destinations' to see a list of release-able destinations.

Wie vor dem Failover wird der vFiler jetzt wieder auf dem Master (netapp01) ausgeführt und die Daten zum Slave (netapp02) repliziert.

netapp01> vfiler status
vfiler0 running
vfiler01 running
netapp01> snapmirror status
Snapmirror is on.
Source Destination State Lag Status
netapp01:vol_vfiler01 netapp02:vol_vfiler01 Source 00:00:00 In-sync

netapp02> vfiler status
vfiler0 running
vfiler01 stopped, DR backup
netapp02> snapmirror status
Snapmirror is on.
Source Destination State Lag Status
netapp01_vfiler01_con:vol_vfiler01 netapp02:vol_vfiler01 Snapmirrored 00:00:00 In-sync

Alle Artikel der Serie:
Teil 1: Download der benötigten Komponenten
Teil 2: Einrichtung des 1. Simulators
Teil 3: Einrichtung des 2. Simulators
Teil 4: Erstellen eines Aggregats und Volumes
Teil 5: DNS Konfiguration
Teil 6: vFiler erstellen und vFiler DR konfigurieren
Teil 7: Synchroner vFiler DR
Teil 8: Freigaben auf vFiler erstellen
Teil 9: Geplanter Failover
Teil 10: Disaster Failover

NetApp vFiler DR mit Data ONTAP Simulator Teil 9: Geplanter Failover

2016-04-28T00:00:00+00:00

Dies ist Teil einer Artikelserie.

So wie die Umgebung in den bisherigen Schritten konfiguriert wurde kann man netapp01 als Master und netapp02 als Slave bezeichnen. Clients nutzen die Freigaben des vFilers auf dem Master (netapp01) und die Daten werden auf den Slave (netapp02) repliziert. Dadurch kann der vFiler bei einem Ausfall des Masters ohne Datenverlust auch auf dem Slave gestartet werden. Die Abbildung verdeutlicht die Konfiguration noch einmal.

Wird der Slave (netapp02) z.B. für Wartungsarbeiten heruntergefahren und fällt somit aus, hat dies auf die Freigaben erst mal keine Auswirkungen. Die CIFS und NFS Freigaben sind weiter verfügbar. Natürlich können die Daten vom Master (netapp01) nicht mehr auf den Slave (netapp02) repliziert werden, die Datenbestände laufen also auseinander. Sobald netapp02 aber wieder erreichbar ist setzt die Replikation automatisch wieder ein und die Daten werden abgeglichen.

Aber was geschieht wenn der Master (netapp01) heruntergefahren werden muss oder ausfällt? Um weiter auf die Freigaben zugreifen zu können ist ein Failover auf den Slave (netapp02) notwendig. Dabei wird zwischen einem geplanten Failover (also ein kontrolliertes Umschalten auf den Slave) und einem Disaster Failover unterschieden. In diesem Teil wird der geplante Failover durchgespielt.

Geplanter Failover von Master zu Slave:

vFiler auf Master (netapp01) stoppen => “stopped”

netapp01> vfiler stop vfiler01
vfiler01 stopped
netapp01> Thu Apr 28 20:20:52 CEST [netapp01:vf.stopped:warning]: vfiler: 'vfiler01'; stopped
netapp01> vfiler status
vfiler0 running
vfiler01 stopped

netapp02> vfiler status
vfiler0 running
vfiler01 stopped, DR backup

vFiler DR auf Slave starten => “running”

netapp02> vfiler dr activate vfiler01@netapp01
Waiting for "vol_vfiler01" to become stable.
Thu Apr 28 20:33:58 CEST [netapp02:snapmirror.sync.fail:notice]: Synchronous SnapMirror from netapp01_vfiler01_con:vol_vfiler01 to netapp02:vol_vfiler01 failed.
CIFS local server is running.
Thu Apr 28 20:34:04 CEST [vfiler01@netapp02:cifs.startup.local.succeeded:info]: CIFS: CIFS local server is running.
Thu Apr 28 20:34:04 CEST [netapp02:httpd.config.mime.missing:warning]: /etc/httpd.mimetypes.sample file is missing.
Thu Apr 28 20:34:04 CEST [vfiler01@netapp02:httpd.config.mime.missing:warning]: /etc/httpd.mimetypes file is missing.
Thu Apr 28 20:34:04 CEST [vfiler01@netapp02:httpd.config.mime.missing:warning]: /etc/httpd.mimetypes.sample file is missing.
Thu Apr 28 20:34:05 CEST [netapp02:wafl.scan.ownblocks.done:info]: Completed block ownership calculation on volume vol_vfiler01. The scanner took 0 ms.
Vfiler vfiler01 activated.
e0a: flags=0xe48867 mtu 1500
inet 192.168.2.67 netmask 0xffffff00 broadcast 192.168.2.255
ether 00:0c:29:61:01:2b (auto-1000t-fd-up) flowcontrol full
netapp02> Thu Apr 28 20:34:05 CEST [netapp02:cmds.vfiler.dr.activated:info]: Disaster recovery backup vFiler unit: 'vfiler01' of the vFiler unit at remote storage system: 'netapp01' was activated.
Thu Apr 28 20:34:29 CEST [vfiler01@netapp02:nbt.nbns.registrationComplete:info]: NBT: All CIFS name registrations have completed for the local server.
netapp02> vfiler status
vfiler0 running
vfiler01 running

State des SnapMirrors prüfen => “Source” auf Master und “Broken-off” auf Slave

netapp01> snapmirror status
Snapmirror is on.
Source Destination State Lag Status
netapp01:vol_vfiler01 netapp02:vol_vfiler01 Source 00:04:22 Idle

netapp02> snapmirror status
Snapmirror is on.
Source Destination State Lag Status
netapp01_vfiler01_con:vol_vfiler01 netapp02:vol_vfiler01 Broken-off 00:05:12 Idle

Resync von Slave auf Master (-s für synchrone Replizierung)

netapp01> vfiler dr resync -s vfiler01@netapp02
One can optionally provide an alternate ip path for sync snapmirroring
Alternate IP address/Hostname for remote filer netapp02 []:
Alternate IP address/Hostname for local filer netapp01 []:
netapp02's Administrative login: root
netapp02's Administrative password:
CIFS local server on vFiler vfiler is shutting down...
CIFS local server on vfiler vfiler has shut down...
Thu Apr 28 20:40:57 CEST [vfiler01@netapp01:telnet_0:notice]: IP address 192.168.2.68 is removed from interface "e0a"
Configuring SnapMirror to mirror vfiler vfiler01's storage units from remote filer netapp02.
Starting snapmirror initialize commands. It
could take a very long time when the source or
destination filers are involved in many
simultaneous transfers. The console will not be
available until all initialize commands are
started successfully. Please use the
"snapmirror status" command on the source
filer to monitor the progress.
Thu Apr 28 20:41:00 CEST [netapp01:snapmirror.dst.resync.info:notice]: SnapMirror resync of vol_vfiler01 to netapp02:vol_vfiler01 is using netapp02(4082368507)_vol_vfiler01.4 as the base snapshot.
Thu Apr 28 20:41:00 CEST [netapp01:vFiler.storageUnit.off:warning]: vFiler vfiler01: storage unit /vol/vol_vfiler01 now offline.
Thu Apr 28 20:41:01 CEST [netapp01:wafl.snaprestore.revert:info]: Reverting volume vol_vfiler01 to a previous snapshot.
Thu Apr 28 20:41:02 CEST [netapp01:vFiler.storageUnit.On:notice]: vFiler vfiler01: storage unit /vol/vol_vfiler01 now online.
Revert to resync base snapshot was successful.
Thu Apr 28 20:41:02 CEST [netapp01:replication.dst.resync.success:notice]: SnapMirror resync of vol_vfiler01 to netapp02:vol_vfiler01 was successful.
SnapMirror transfer initiated for vfiler storage units.

SnapMirror von netapp02 (Source) auf netapp01 (Destination) prüfen => zusätzliche Einträge mit State “Snapmirrored” auf Master und “Source” auf Slave

netapp01> snapmirror status
Snapmirror is on.
Source Destination State Lag Status
netapp02_vfiler01_con:vol_vfiler01 netapp01:vol_vfiler04 Snapmirrored 00:00:00 In-sync
netapp01:vol_vfiler01 netapp02:vol_vfiler01 Source 00:10:45 Idle

netapp02> snapmirror status
Snapmirror is on.
Source Destination State Lag Status
netapp01_vfiler01_con:vol_vfiler01 netapp02:vol_vfiler01 Broken-off 00:11:31 Idle
netapp02:vol_vfiler01 netapp01:vol_vfiler01 Source 00:00:00 In-sync

Nach diesen Aktionen haben Master und Slave ihre Rollen getauscht. Der vFiler läuft auf netapp02 und die Daten werden von netapp02 auf netapp01 repliziert. Jetzt kann netapp01 für Wartungszwecke heruntergefahren werden.

Ist der “alte” Master (netapp01) wieder einsatzbereit, kann der vFiler wieder zurück verschoben werden.

Rollback von Slave zu Master

Warten bis SnapMirror von netapp02 (Source) auf netapp01 (Destination) “In-sync”

netapp01> snapmirror status
Snapmirror is on.
Source Destination State Lag Status
netapp02_vfiler01_con:vol_vfiler01 netapp01:vol_vfiler01 Snapmirrored 00:00:00 In-sync
netapp01:vol_vfiler01 netapp02:vol_vfiler01 Source 00:14:45 Idle

netapp02> snapmirror status
Snapmirror is on.
Source Destination State Lag Status
netapp01_vfiler01_con:vol_vfiler01 netapp02:vol_vfiler01 Broken-off 00:15:31 Idle
netapp02:vol_vfiler01 netapp01:vol_vfiler01 Source 00:00:00 In-sync

vFiler auf Slave stoppen => “stopped”

netapp02> vfiler stop vfiler01
vfiler01 stopped
Thu Apr 28 20:47:10 CEST [netapp02:vf.stopped:warning]: vfiler: 'vfiler01'; stopped
netapp02> vfiler status
vfiler0 running
vfiler01 stopped

vFiler auf Master starten => “running”

netapp01> vfiler dr activate vfiler01@netapp02
Waiting for "vol_vfiler01" to become stable.
Thu Apr 28 20:48:23 CEST [netapp01:snapmirror.sync.fail:notice]: Synchronous SnapMirror from netapp02_vfiler01_con:vol_vfiler01 to netapp01:vol_vfiler01 failed.
Thu Apr 28 20:48:30 CEST [netapp01:wafl.scan.ownblocks.done:info]: Completed block ownership calculation on volume vol_vfiler01. The scanner took 0 ms.
CIFS local server is running.
Thu Apr 28 20:48:31 CEST [vfiler01@netapp01:cifs.startup.local.succeeded:info]: CIFS: CIFS local server is running.
Thu Apr 28 20:48:31 CEST [netapp01:httpd.config.mime.missing:warning]: /etc/httpd.mimetypes.sample file is missing.
Thu Apr 28 20:48:31 CEST [vfiler01@netapp01:httpd.config.mime.missing:warning]: /etc/httpd.mimetypes file is missing.
Thu Apr 28 20:48:31 CEST [vfiler01@netapp01:httpd.config.mime.missing:warning]: /etc/httpd.mimetypes.sample file is missing.
Vfiler vfiler01 activated.
e0a: flags=0xe48867 mtu 1500
inet 192.168.2.66 netmask 0xffffff00 broadcast 192.168.2.255
inet 192.168.2.69 netmask 0xffffff00 broadcast 192.168.2.255
ether 00:0c:29:ee:ee:f2 (auto-1000t-fd-up) flowcontrol full
netapp01> Thu Apr 28 20:48:32 CEST [netapp01:cmds.vfiler.dr.activated:info]: Disaster recovery backup vFiler unit: 'vfiler01' of the vFiler unit at remote storage system: 'netapp02' was activated.
Thu Apr 28 20:48:55 CEST [vfiler01@netapp01:nbt.nbns.registrationComplete:info]: NBT: All CIFS name registrations have completed for the local server.
netapp01> vfiler status
vfiler0 running
vfiler01 running

Status des SnapMirrors von netapp02 (Source) auf netapp01 (Destination) prüfen => “Source” auf netapp02 und “Broken-off” auf netapp01

netapp01> snapmirror status
Snapmirror is on.
Source Destination State Lag Status
netapp02_vfiler01_con:vol_vfiler01 netapp01:vol_vfiler01 Broken-off 00:03:38 Idle
netapp01:vol_vfiler01 netapp02:vol_vfiler01 Source 00:17:04 Idle

netapp02> snapmirror status
Snapmirror is on.
Source Destination State Lag Status
netapp01_vfiler01_con:vol_vfiler01 netapp02:vol_vfiler01 Broken-off 00:17:58 Idle
netapp02:vol_vfiler01 netapp01:vol_vfiler01 Source 00:04:32 Idle

Resync von Master auf Slave => Status SnapMirror von netapp01 (Source) auf netapp02 (Destination) “In-sync” (dauert eine Weile)

netapp02> vfiler dr resync -s vfiler01@netapp01
One can optionally provide an alternate ip
path for sync snapmirroring
Alternate IP address/Hostname for remote filer netapp01 []:
Alternate IP address/Hostname for local filer netapp02 []:
netapp01's Administrative login: root
netapp01's Administrative password:
CIFS local server on vFiler vfiler01 is shutting down...
waiting for CIFS shut down (^C aborts)...
CIFS local server on vfiler vfiler01 has shut down...
Thu Apr 28 20:53:02 CEST [vfiler01@netapp02:telnet_0:notice]: IP address 192.168.2.68 is removed from interface "e0a"
Configuring SnapMirror to mirror vfiler vfiler01's storage units from remote filer netapp01.
Starting snapmirror initialize commands. It
could take a very long time when the source or
destination filers are involved in many
simultaneous transfers. The console will not be
available until all initialize commands are
started successfully. Please use the
"snapmirror status" command on the source
filer to monitor the progress.
Thu Apr 28 20:53:06 CEST [netapp02:snapmirror.dst.resync.info:notice]: SnapMirror resync of vol_vfiler01 to netapp01:vol_vfiler01 is using netapp01(4082368508)_vol_vfiler01.5 as the base snapshot.
Thu Apr 28 20:53:06 CEST [netapp02:vFiler.storageUnit.off:warning]: vFiler vfiler01: storage unit /vol/vol_vfiler01 now offline.
Thu Apr 28 20:53:08 CEST [netapp02:wafl.snaprestore.revert:info]: Reverting volume vol_vfiler01 to a previous snapshot.
Thu Apr 28 20:53:09 CEST [netapp02:vFiler.storageUnit.On:notice]: vFiler vfiler01: storage unit /vol/vol_vfiler01 now online.
Revert to resync base snapshot was successful.
Thu Apr 28 20:53:10 CEST [netapp02:replication.dst.resync.success:notice]: SnapMirror resync of vol_vfiler01 to netapp01:vol_vfiler01 was successful.
SnapMirror transfer initiated for vfiler storage units.
netapp02> snapmirror status
Snapmirror is on.
Source Destination State Lag Status
netapp01_vfiler01_con:vol_vfiler01 netapp02:vol_vfiler01 Snapmirrored 00:00:00 In-sync
netapp02:vol_vfiler01 netapp01:vol_vfiler01 Source 00:08:02 Idle

netapp01> snapmirror status
Snapmirror is on.
Source Destination State Lag Status
netapp02_vfiler01_con:vol_vfiler01 netapp01:vol_vfiler01 Broken-off 00:08:37 Idle
netapp01:vol_vfiler01 netapp02:vol_vfiler01 Source 00:00:00 In-sync

SnapMirror Beziehungen von Slave zu Master löschen

netapp02> snapmirror release vol_vfiler01 netapp01:vol_vfiler01
snapmirror release: vol_vfiler01 netapp01:vol_vfiler01: No release-able destination found that matches those parameters. Use 'snapmirror destinations' to see a list of release-able destinations.

netapp01> snapmirror release vol_vfiler01 netapp01:vol_vfiler01
snapmirror release: vol_vfiler01 netapp01:vol_vfiler01: No release-able destination found that matches those parameters. Use 'snapmirror destinations' to see a list of release-able destinations.

Wie vor dem Failover wird der vFiler jetzt wieder auf dem Master (netapp01) ausgeführt und die Daten zum Slave (netapp02) repliziert (vgl. erste Abbildung).

netapp01> vfiler status
vfiler0 running
vfiler01 running
netapp01> snapmirror status
Snapmirror is on.
Source Destination State Lag Status
netapp01:vol_vfiler01 netapp02:vol_vfiler01 Source 00:00:00 In-sync

netapp02> vfiler status
vfiler0 running
vfiler01 stopped, DR backup
netapp02> snapmirror status
Snapmirror is on.
Source Destination State Lag Status
netapp01_vfiler01_con:vol_vfiler01 netapp02:vol_vfiler01 Snapmirrored 00:00:00 In-sync

NetApp vFiler DR mit Data ONTAP Simulator Teil 8: Freigaben auf vFiler erstellen

2016-02-21T00:00:00+00:00

Dies ist Teil einer Artikelserie.

In diesem Schritt werden eine CIFS und eine NFS Freigabe erstellt. Die Freigaben auf dem vFiler können nicht über OnCommand System Manager konfiguriert werden, stattdessen muss die Console oder SSH genutzt werden. SSH muss auf dem vFiler zuerst aktiviert werden. Dazu wird eine Sitzung auf dem 1. Simulator (netapp01) verwendet. Kommandos können von dort aus auf dem vFiler ausgeführt werden. Das Muster ist dabei vfiler run <Name des vFilers> <Kommando>.

netapp01> vfiler run vfiler01 secureadmin setup ssh
===== vfiler01
SSH Setup
---------
Determining if SSH Setup has already been done before...no
SSH server supports both ssh1.x and ssh2.0 protocols.
SSH server needs two RSA keys to support ssh1.x protocol. The host key is
generated and saved to file /vol/vol_vfiler01/etc/sshd/ssh_host_key during setup. The server
key is re-generated every hour when SSH server is running.
SSH server needs a RSA host key and a DSA host key to support ssh2.0 protocol.
The host keys are generated and saved to /vol/vol_vfiler01/etc/sshd/ssh_host_rsa_key and
/vol/vol_vfiler01/etc/sshd/ssh_host_dsa_key files respectively during setup.
SSH Setup will now ask you for the sizes of the host and server keys.
For ssh1.0 protocol, key sizes must be between 384 and 2048 bits.
For ssh2.0 protocol, key sizes must be between 768 and 2048 bits.
The size of the host and server keys must differ by at least 128 bits.
Please enter the size of host key for ssh1.x protocol [768] :
Please enter the size of server key for ssh1.x protocol [512] :
Please enter the size of host keys for ssh2.0 protocol [768] :
You have specified these parameters:
host key size = 768 bits
server key size = 512 bits
host key size for ssh2.0 protocol = 768 bits
Is this correct? [yes]
Setup will now generate the host keys. It will take a minute.
After Setup is finished the SSH server will start automatically.
netapp01> Wed Feb 17 20:15:16 CET [vfiler01@netapp01:secureadmin.ssh.setup.passed:info]: SSH setup is done and ssh2 is enabled. Host keys are stored in /vol/vol_vfiler01/etc/sshd/ssh_host_key, /vol/vol_vfiler01/etc/sshd/ssh_host_rsa_key, and /vol/vol_vfiler01/etc/sshd/ssh_host_dsa_key.
netapp01> vfiler run vfiler01 secureadmin status
===== vfiler01
ssh2 - active
ssh1 - inactive

Ab sofort ist es möglich sich per SSH direkt auf den vFiler zu verbinden und Kommandos dort auszuführen. Alternativ kann man diesen Schritt natürlich auch überspringen und alle Kommandos mit vfiler run … vom Host auf dem der vFiler läuft (in diesem Fall netapp01) aus aufrufen.

Als nächstes wird die CIFS Freigabe erstellt. Falls während der Erstellung des vFilers CIFS noch nicht konfiguriert wurde, muss dies als erstes geschehen (vgl. Teil 6). In diesem Beispiel wird der vFiler nicht in eine Active Directory Domäne aufgenommen, sondern für Berechtigungen nur die lokalen Benutzer des vFilers verwendet (Option 3 während der Konfiguration).

vfiler01@netapp01> cifs setup
....
This process will enable CIFS access to the filer from a Windows(R) system.
Use "?" for help at any prompt and Ctrl-C to exit without committing changes.
Your filer does not have WINS configured and is visible only to
clients on the same subnet.
Do you want to make the system visible via WINS? [n]: n
A filer can be configured for multiprotocol access, or as an NTFS-only
filer. Since multiple protocols are currently licensed on this filer,
we recommend that you configure this filer as a multiprotocol filer
(1) Multiprotocol filer
(2) NTFS-only filer
Selection (1-2)? [1]: 1
CIFS requires local /etc/passwd and /etc/group files and default files
will be created. The default passwd file contains entries for 'root',
'pcuser', and 'nobody'.
The default name for this CIFS server is 'VFILER'.
Would you like to change this name? [n]: n
Data ONTAP CIFS services support four styles of user authentication.
Choose the one from the list below that best suits your situation.
(1) Active Directory domain authentication (Active Directory domains only)
(2) Windows NT 4 domain authentication (Windows NT or Active Directory domains)
(3) Windows Workgroup authentication using the filer's local user accounts
(4) /etc/passwd and/or NIS/LDAP authentication
Selection (1-4)? [1]: 3
What is the name of the Workgroup? [WORKGROUP]: WORKGROUP
CIFS - Starting SMB protocol...
It is recommended that you create the local administrator account
(VFILER01\administrator) for this filer.
Do you want to create the VFILER01\administrator account? [y]: y
Enter the new password for VFILER01\administrator:
Retype the password:
Welcome to the WORKGROUP Windows(R) workgroup
vfiler01@netapp01> Wed Feb 17 21:41:06 CET [vfiler01@netapp01:cifs.startup.local.succeeded:info]: CIFS: CIFS local server is running.

Für den Zugriff auf Freigaben kann man den soeben angelegten Benutzer VFILER01\administrator verwenden, oder es kann ein eigener Benutzer angelegt werden:

vfiler01@netapp01> useradmin user add user01 -g Guests
New password:
Retype new password:
User <user01> added.
vfiler01@netapp01> Wed Feb 17 21:49:18 CET [vfiler01@netapp01:useradmin.added.deleted:info]: The user 'user01' has been added.

Nachdem CIFS jetzt auf dem vFiler aktiviert ist, kann die Freigabe angelegt werden. Dazu wird erst ein qtree und danach die Freigabe erstellt.

vfiler01@netapp01> qtree create /vol/vol_vfiler01/q_cifs
vfiler01@netapp01> qtree security /vol/vol_vfiler01/q_cifs ntfs
vfiler01@netapp01> qtree status
Volume Tree Style Oplocks Status
-------- -------- ----- -------- ---------
vol_vfiler01 unix enabled normal
vol_vfiler01 q_cifs ntfs enabled normal
vfiler01@netapp01> cifs shares -add cifs01 /vol/vol_vfiler01/q_cifs
vfiler01@netapp01> cifs shares
Name Mount Point Description
---- ----------- -----------
ETC$ /vol/vol_vfiler01/etc Remote Administration
** priv access only **
HOME /vol/vol_vfiler01/home Default Share
everyone / Full Control
C$ / Remote Administration
** priv access only **
cifs01 /vol/vol_vfiler01/q_cifs
everyone / Full Control

Auf die Freigabe kann jetzt z.B. über \\192.168.2.68\cifs01 (als Benutzer VFILER01\user01) zugegriffen werden. Eine Einschränkung der Berechtigungen ist für diese Artikelserie nicht notwendig. Jeder hat volle Rechte auf die Freigabe.

Für die NFS Freigabe wird auch wieder ein qtree erstellt und danach der Share für alle Hosts im Netz 192.168.2.0/24 freigegeben.

vfiler01@netapp01> qtree create /vol/vol_vfiler01/q_nfs
vfiler01@netapp01> qtree security /vol/vol_vfiler01/q_cifs unix
vfiler01@netapp01> qtree status
Volume Tree Style Oplocks Status
-------- -------- ----- -------- ---------
vol_vfiler01 unix enabled normal
vol_vfiler01 q_cifs ntfs enabled normal
vol_vfiler01 q_nfs unix enabled normal
vfiler01@netapp01> exportfs -p rw=192.168.2.0/24,root=192.168.2.0/24 /vol/vol_vfiler01/q_nfs
vfiler01@netapp01> exportfs
/vol/vol_vfiler01/q_nfs -sec=sys,rw=192.168.2.0/24,root=192.168.2.0/24
/vol/vol_vfiler01 -sec=sys,rw,anon=0,nosuid

Von einem Linux Server kann die Freigabe nun gemountet werden.

hostname:~# mount 192.168.2.68:/vol/vol_vfiler01/q_nfs /media/cdrom

NetApp vFiler DR mit Data ONTAP Simulator Teil 7: Synchroner vFiler DR

2016-02-12T00:00:00+00:00

Dies ist Teil einer Artikelserie.

Hinweis: Dieser Schritt kann übersprungen werden wenn statt einem synchronen Spiegel ein asynchroner SnapMirror (wie in Teil 6 eingerichtet) ausreicht und vFiler DR bereits konfiguriert wurde.

In Teil 6 der Serie wurde der DR vFiler mit einem asynchronen SnapMirror angelegt. Die Daten werden also mit einem leichten Zeitversatz übertragen. Stattdessen kann auch ein synchroner SnapMirror angelegt werden, die Daten werden dann sofort auf dem vFiler und seinem Spiegel geschrieben. Dafür müssen alle Volumes des vFilers mindestens 10 GB groß sein (deswegen wurde in Teil 4 ein Volume mit der Größe 10 GB angelegt). Zusätzlich muss zwingend die Namensauflösung des jeweils anderen Simulators funktionieren. Wenn die DNS Einstellungen (wie auch im Video von Teil 1) nicht bei der Installation konfiguriert wurden, können die richtigen Einstellungen auch im Nachhinein über OnCommand System Manager (Configuration => Network => DNS) gesetzt werden. Wenn kein DNS Server zur Verfügung steht ist es auch möglich die Daten in die Datei /etc/hosts auf dem jeweiligen Simulator einzutragen.

netapp01> rdfile /etc/hosts
127.0.0.1 localhost localhost-stack
127.0.10.1 localhost-10 localhost-bsd
127.0.20.1 localhost-20 localhost-sk
192.168.2.66 netapp01 netapp01-e0a
# 0.0.0.0 netapp01-e0b
# 0.0.0.0 netapp01-e0c
# 0.0.0.0 netapp01-e0d
netapp01> wrfile /etc/hosts
127.0.0.1 localhost localhost-stack
127.0.10.1 localhost-10 localhost-bsd
127.0.20.1 localhost-20 localhost-sk
192.168.2.66 netapp01 netapp01-e0a
# 0.0.0.0 netapp01-e0b
# 0.0.0.0 netapp01-e0c
# 0.0.0.0 netapp01-e0d
192.168.2.67 netapp02
read: error reading standard input: Interrupted system call
netapp01> rdfile /etc/hosts
127.0.0.1 localhost localhost-stack
127.0.10.1 localhost-10 localhost-bsd
127.0.20.1 localhost-20 localhost-sk
192.168.2.66 netapp01 netapp01-e0a
# 0.0.0.0 netapp01-e0b
# 0.0.0.0 netapp01-e0c
# 0.0.0.0 netapp01-e0d
192.168.2.67 netapp02

Mit rdfile /etc/hosts wird der Inhalt der Datei /etc/hosts ausgegeben. Die Datei kann mit SSH leider nicht editiert werden, sondern muss neu geschrieben werden. Man muss also den vorherigen Inhalt kopieren und die Datei mit wrfile /etc/hosts neu schreiben. Nach dem Einfügen des bisherigen Inhalts aus der Zwischenablage wird die zusätzliche Zeile (Eintrag besteht aus IP und Hostname der anderen Simulators) eingegeben und das Editieren der Datei mit Ctrl+C beendet. Danach kann der Inhalt mit rdfile /etc/hosts kontrolliert werden. Ein kurzes Video verdeutlicht die Vorgehensweise am Beispiel des 2. Simulators (netapp02).

Die Konfiguration kann mit einem ping von beiden Systemen kontrolliert werden:

netapp01> ping netapp02
netapp02 is alive

netapp02> ping netapp01
netapp01 is alive

Der vFiler DR wird fast genauso wie in Teil 6 beschrieben eingerichtet.Für einen synchronen SnapMirror muss lediglich die Option -s hinzugefügt werden.

netapp02> vfiler dr configure -s vfiler01@192.168.2.66
One can optionally provide an alternate ip
path for sync snapmirroring
Alternate IP address/Hostname for remote filer 192.168.2.66 []:
Alternate IP address/Hostname for local filer netapp02 []:
192.168.2.66's Administrative login: root
192.168.2.66's Administrative password:
Configuring SnapMirror to mirror vfiler vfiler01's storage units from remote filer 192.168.2.66.
Upon Activation, configure vfiler IP address 192.168.2.68? [y]:
Interface to assign this address to {e0a, e0b, e0c, e0d}: e0a
Netmask to use: [255.255.255.0]:
Starting snapmirror initialize commands. It
could take a very long time when the source or
destination filers are involved in many
simultaneous transfers. The console will not be
available until all initialize commands are
started successfully. Please use the
"snapmirror status" command on the source
filer to monitor the progress.
Volume 'vol_vfiler01' is now restricted.
Upon activation, do you want the DR vfiler to use a different
set of DNS servers from the production vfiler? [n]:
SnapMirror transfer initiated for vfiler storage units.

Der SnapMirror sieht bei einem snapmirror status zuerst genauso aus wie ein asynchroner SnapMirror. Nach dem ersten erfolgreichen Abgleich wechselt der Status jedoch auf “In-sync”.

netapp02> snapmirror status
Snapmirror is on.
Source Destination State Lag Status
192.168.2.66_vfiler01_con:vol_vfiler01 netapp02:vol_vfiler01 Snapmirrored 00:00:30 Idle
netapp02> snapmirror status
Snapmirror is on.
Source Destination State Lag Status
192.168.2.66_vfiler01_con:vol_vfiler01 netapp02:vol_vfiler01 Snapmirrored 00:00:00 In-sync

Falls der Status nicht auf “In-sync” wechseln sollte, können die Syslog-Einträge im OnCommand System Manager (Diagnostics => Logs => Syslog) helfen die Ursache zu finden. Bei falscher bzw. fehlender DNS Konfiguration erhielt ich z.B. “SnapMirror is unable to setup a multipath connection to vol_vfiler01, resorting to the standard single TCP connection.” und “SnapMirror: destination transfer from 192.168.2.66_vfiler01_con:vol_vfiler01 to vol_vfiler01 : Error in snapmirror sync mode negotiation.” als Fehlermeldungen.

Temperatur messen mit Cubietruck und DS18B20 Sensor

2016-02-08T00:00:00+00:00

Hinweis: Wenn die generelle Vorgehensweise bekannt ist, der Sensor allerdings nicht zuverlässig funktioniert bitte die Stromsparfunktion der CPU prüfen.

Im Vergleich zum Raspberry Pi ist der Cubietruck leider nicht allzu weit verbreitet, weshalb es nur wenige Anleitungen für die Nutzung der GPIO Pins gibt. Ziel des Artikels ist die Temperatur mit einem DS18B20 Sensor zu messen. Als erstes muss man sich natürlich den Sensor besorgen (z.B. bei Amazon oder ebay). Der Sensor besitzt 3 Leitungen: Masse (GND), 3,3 Volt (VDD) und das Singal (DQ).

Zwischen VDD und DQ wird ein 4,7 K Ohm Widerstand geschaltet (siehe auch Datenblatt). Zum Testen baut man die Schaltung am besten mit einem Breadboard auf. Ich habe den Sensor und den Widerstand direkt verlötet.

Der Kernel benötigt die Module gpio_sunxi, w1_therm, w1_sunxi und w1_gpio. Als Betriebssystem kann ich armbian empfehlen. In der Variante Legacy Jessie sind die Module schon integriert. Um sie automatisch zu laden kann man sie in die Datei /etc/modules aufnehmen.

hostname:~# cat /etc/modules
# /etc/modules: kernel modules to load at boot time.
#
# This file contains the names of kernel modules that should be loaded
# at boot time, one per line. Lines beginning with "#" are ignored.
brcmfmac
rfcomm
hidp
bonding
gpio_sunxi
w1_therm
w1_sunxi
w1_gpio
hostname:~#

Danach sucht man sich passende GPIO Pins auf dem Cubietruck aus. Ich habe mich für PB18 für DQ entschieden. Die Leitungen für Masse (GND) und Spannung (VDD) müssen an entsprechende Pins angeschlossen werden (z.B. Pin 1 und 2 auf CN8). Der gewählte DQ Pin muss aktiviert werden. Die Konfiguration läuft über eine bin-Datei. Die genaue Vorgehensweise wird hier beschrieben. Bei armbian lautet die Datei /boot/script.bin und ist ein Link auf /boot/bin/cubietruck.bin. Am besten kopiert man sich die Datei erst mal in sein Home-Verzeichnis und wandelt sie dort in eine editierbare fex-Datei um.

hostname:~# cp /boot/bin/cubietruck.bin ~
hostname:~# bin2fex cubietruck.bin cubietruck.fex
hostname:~# cp cubietruck.fex cubietruck_own.fex

Die Datei cubietruck_own.fex kann jetzt editiert werden. Es muss der Bereich [gpio_para] angepasst und der Bereich [w1_para] hinzugefügt werden. Bei mir sieht das dann so aus:

[gpio_para]
gpio_used = 1
gpio_num = 4
gpio_pin_1 = port:PH20<1><1>
gpio_pin_2 = port:PH10<0><0>
gpio_pin_3 = port:PG08<1><1>
gpio_pin_4 = port:PB18<0><0>
[w1_para]
gpio = 4

Es werden 4 GPIO Pins genutzt (gpio_num=4). GPIO Pin 4 wird der Pin PB18 zugewiesen (gpio_pin_4 = …) und 1-wire auf Pin 4 konfiguriert (gpio=4 im Bereich [w1_para]). Nach dem Editieren der Datei erstellt man daraus wieder die bin-Datei und tauscht die usprüngliche mit der angepassten aus.

hostname:~# fex2bin cubietruck_own.fex cubietruck.bin
hostname:~# cp cubietruck.bin /boot/bin/cubietruck.bin

Die Änderung wird nach einem Reboot aktiv. Sind die Module geladen, der Sensor richtig verbunden und die GPIO Pins richtig konfiguriert erscheint der Sensor unter /sys/bus/w1/devices/. Für jeden Sensor (es könnten auch mehrere gleichzeitig angeschlossen werden) gibt es dort ein Verzeichnis nach dem Muster 28-XXXXXXXXXXXX. Bei mir war der Sensor nur direkt nach dem Booten vorhanden und verschwand nach kurzer Zeit wieder. Die CPU taktet sich je nach Anforderung herunter und ab einem bestimmten Wert funktioniert dann der Sensor nicht mehr. Ich habe den minimalen Wert auf 700 MHz gesetzt.

hostname:~# sudo cpufreq-set -d 700000

Ist der Sensor unter /sys/bus/w1/devices/ vorhanden, lässt sich die Temperatur leicht auslesen.

hostname:~# cat /sys/bus/w1/devices/28-000003ca3e36/w1_slave
e7 00 4b 46 7f ff 09 10 94 : crc=94 YES
e7 00 4b 46 7f ff 09 10 94 t=14437

Das YES in der 1. Zeile besagt, dass die Checksumme stimmt und damit der Temperaturwert gültig ist. Die Temperatur von 14437 entspricht 14,437 °C. Der Wert kann also einfach durch 1000 geteilt werden. Mit einem einfache Shellscript (basiert auf Code aus dem Wiki der “linux-sunxi community”) oder Python Script (basiert auf my-pi-scripts) kann der Wert richtig formatiert ausgegeben werden.

Die Vorgehensweise wird auch auf www.cubieforums.com erklärt.

NetApp vFiler DR mit Data ONTAP Simulator Teil 6: vFiler erstellen und vFiler DR konfigurieren

2016-01-27T00:00:00+00:00

Dies ist Teil einer Artikelserie.

Hinweis: In diesem Artikel wird vFiler DR mit asynchroner Replikation eingerichtet. Wenn synchrone Replikation gewünscht ist, bitte in diesem Teil nur den vFiler erstellen und dann mit Teil 7 fortsetzen. Den Abschnitt “vFiler DR konfigurieren” aus diesem Artikel überspringen.

Jetzt wird endlich der eigentliche vFiler auf dem ersten Simulator (netapp01) angelegt. Entweder per OnCommand System Manager

oder über SSH.

netapp01> vfiler create vfiler01 -i 192.168.2.68 /vol/vol_vfiler01
Tue Jan 17 00:21:06 CET [netapp01:vFiler.etcPath.exists:warning]: Warning: /vol/vol_vfiler01/etc already exists. Old configuration will be deleted.
Tue Jan 17 00:21:06 CET [vfiler01@netapp01:lun.vfiler.oldConfigDeleted:notice]: Warning: Old LUN configuration exists and will be deleted.
Tue Jan 17 00:21:06 CET [vfiler01@netapp01:secureadmin.ssh.setup.passed:info]: SSH setup is done and ssh2 is enabled. Host keys are stored in /vol/vol_vfiler01/etc/sshd/ssh_host_key, /vol/vol_vfiler01/etc/sshd/ssh_host_rsa_key, and /vol/vol_vfiler01/etc/sshd/ssh_host_dsa_key.
Tue Jan 17 00:21:06 CET [netapp01:httpd.config.mime.missing:warning]: /etc/httpd.mimetypes.sample file is missing.
Tue Jan 17 00:21:06 CET [vfiler01@netapp01:httpd.config.mime.missing:warning]: /etc/httpd.mimetypes file is missing.
Tue Jan 17 00:21:06 CET [vfiler01@netapp01:httpd.config.mime.missing:warning]: /etc/httpd.mimetypes.sample file is missing.
Tue Jan 17 00:21:06 CET [vfiler01@netapp01:useradmin.added.deleted:info]: The role 'compliance' has been added.
Tue Jan 17 00:21:07 CET [vfiler01@netapp01:export.file.missing:warning]: Could not open '/etc/exports' for reading.
The etc configuration directory for vfiler "vfiler01" is /vol/vol_vfiler01/etc.
Setting up vfiler vfiler01
Tue Jan 17 00:21:07 CET [vfiler01@netapp01:cmds.vfiler.info:notice]: vFiler unit vfiler01 initialized.
Configure vfiler IP address 192.168.2.68? [y]: y
Interface to assign this address to {e0a, e0b, e0c, e0d}: e0a
Netmask to use: [255.255.255.0]: 255.255.255.0
The administration host is given root access to the filer's
/etc files for system administration. To allow /etc root access
to all NFS clients enter RETURN below.
Please enter the name or IP address of the administration host:
Do you want to run DNS resolver? [n]: y
Please enter DNS domain name []: test.local
You may enter up to 3 nameservers
Please enter the IP address for first nameserver []: 192.168.2.50
Do you want another nameserver? [n]: n
Do you want to run NIS client? [n]: n
e0a: flags=0xe48867 mtu 1500
inet 192.168.2.66 netmask 0xffffff00 broadcast 192.168.2.255
ether 00:0c:29:ee:ee:f2 (auto-1000t-fd-up) flowcontrol full
Default password for root on vfiler vfiler01 is "".
New password:Tue Jan 17 00:21:51 CET [vfiler01@netapp01:useradmin.added.deleted:info]: The user 'root' has been added.
Retype new password:
Tue Jan 17 00:22:05 CET [vfiler01@netapp01:passwd.changed:info]: passwd for user 'root' changed.
Do you want to setup CIFS? [y]: y
This process will enable CIFS access to the filer from a Windows(R) system.
Use "?" for help at any prompt and Ctrl-C to exit without committing changes.
Your filer does not have WINS configured and is visible only to
clients on the same subnet.
Do you want to make the system visible via WINS? [n]: n
A filer can be configured for multiprotocol access, or as an NTFS-only
filer. Since multiple protocols are currently licensed on this filer,
we recommend that you configure this filer as a multiprotocol filer
(1) Multiprotocol filer
(2) NTFS-only filer
Selection (1-2)? [1]: 1
CIFS requires local /etc/passwd and /etc/group files and default files
will be created. The default passwd file contains entries for 'root',
'pcuser', and 'nobody'.
The default name for this CIFS server is 'VFILER01'.
Would you like to change this name? [n]: n
Data ONTAP CIFS services support four styles of user authentication.
Choose the one from the list below that best suits your situation.
(1) Active Directory domain authentication (Active Directory domains only)
(2) Windows NT 4 domain authentication (Windows NT or Active Directory domains)
(3) Windows Workgroup authentication using the filer's local user accounts
(4) /etc/passwd and/or NIS/LDAP authentication
Selection (1-4)? [1]: 3
What is the name of the Workgroup? [WORKGROUP]: WORKGROUP
CIFS - Starting SMB protocol...
It is recommended that you create the local administrator account
(VFILER01\administrator) for this filer.
Do you want to create the VFILER01\administrator account? [y]: y
Enter the new password for VFILER01\administrator:
Retype the password:
Welcome to the WORKGROUP Windows(R) workgroup
netapp01> Tue Jan 17 00:23:23 CET [vfiler01@netapp01:cifs.startup.local.succeeded:info]: CIFS: CIFS local server is running.

vFiler DR konfigurieren

vFiler DR wird auf dem zweiten Simulator per SSH eingerichtet.

netapp02> vfiler dr configure vfiler01@192.168.2.66
192.168.2.66's Administrative login: root
192.168.2.66's Administrative password:
Configuring SnapMirror to mirror vfiler vfiler01's storage units from remote filer 192.168.2.66.
Upon Activation, configure vfiler IP address 192.168.2.68? [y]: y
Interface to assign this address to {e0a, e0b, e0c, e0d}: e0a
Netmask to use: [255.255.255.0]: 255.255.255.0
Starting snapmirror initialize commands. It
could take a very long time when the source or
destination filers are involved in many
simultaneous transfers. The console will not be
available until all initialize commands are
started successfully. Please use the
"snapmirror status" command on the source
filer to monitor the progress.
Volume 'vol_vfiler01' is now restricted.
Upon activation, do you want the DR vfiler to use a different
set of DNS servers from the production vfiler? [n]: n
SnapMirror transfer initiated for vfiler storage units.
netapp02> Tue Jan 17 21:14:02 CET [netapp02:cmds.vfiler.dr.configure:info]: vFiler unit 'vfiler01' is now disaster recovery backup of remote vFiler unit present at storage system '192.168.2.66'.
Tue Jan 17 21:14:02 CET [netapp02:vFiler.storageUnit.On:notice]: vFiler vfiler01: storage unit /vol/vol_vfiler01 now online.
Tue Jan 17 21:14:02 CET [netapp02:vFiler.etcStorage.readOnly:warning]: vFiler vfiler01: vFiler cannot be started because the volume containing its root, volume vol_vfiler01, is read-only.

Dabei handelt es sich um einen asynchronen SnapMirror. Das bedeutet die Daten werden auf den ersten Simulator geschrieben und landen mit einem leichten zeitlichen Versatz auf dem zweiten Simulator. Standardmäßig findet die Replizierung alle 3 Minuten statt. Mit einem snapmirror status kann man sich den aktuellen Zustand anzeigen lassen. Dabei sieht man das die Zeit in der Spalte “Lag” bis zu 3 Minuten beträgt und danach die Replizierung startet.

netapp02> snapmirror status
Snapmirror is on.
Source Destination State Lag Status
192.168.2.66:vol_vfiler01 netapp02:vol_vfiler01 Snapmirrored 00:02:52 Idle
netapp02> snapmirror status
Snapmirror is on.
Source Destination State Lag Status
192.168.2.66:vol_vfiler01 netapp02:vol_vfiler01 Snapmirrored 00:03:01 Transferring
netapp02> snapmirror status
Snapmirror is on.
Source Destination State Lag Status
192.168.2.66:vol_vfiler01 netapp02:vol_vfiler01 Snapmirrored 00:03:02 Transferring (84 KB done)
netapp02> snapmirror status
Snapmirror is on.
Source Destination State Lag Status
192.168.2.66:vol_vfiler01 netapp02:vol_vfiler01 Snapmirrored 00:00:07 Idle

NetApp vFiler DR mit Data ONTAP Simulator Teil 5: DNS Konfiguration

2016-01-26T00:00:00+00:00

Dies ist Teil einer Artikelserie.

Hinweis: Falls bereits beim Einrichten der VMs (Teil 2 und 3) DNS konfiguriert wurde (“DNS resolver”), kann direkt die Namensauflösung per ping geprüft werden.

Für den weiteren Verlauf ist es sinnvoll, dass DNS auf beiden NetApp VMs richtig konfiguriert ist. Sie sollen sich also mindestens gegenseitig auflösen können. Soll im späteren Verlauf ein synchroner vFiler DR genutzt werden, sind die richtigen DNS Einstellungen sogar zwingend notwendig. Bei falscher bzw. fehlender DNS Konfiguration erhielt ich z.B. “SnapMirror is unable to setup a multipath connection to vol_vfiler, resorting to the standard single TCP connection.” und “SnapMirror: destination transfer from 192.168.2.66_vfiler_con:vol_vfiler1 to vol_vfiler1 : Error in snapmirror sync mode negotiation.” als Fehlermeldungen.

Es stehen 2 Varianten zur Auswahl: “Konfiguration mit DNS Server” und “Konfiguration über /etc/hosts”. Die Konfiguration muss auf beiden Simulatoren analog erfolgen.

Konfiguration mit DNS Server:

Wenn ein DNS Server im Netzwerk vorhanden ist und dort Einträge für die beiden Simulatoren hinterlegt sind, reicht es aus diesen DNS Server auf beiden VMs zu konfigurieren. Dafür kann der OnCommand System Manager genutzt werden (Configuration => Network => DNS).

Sollte der OnCommand System Manager nicht zur Verfügung stehen kann die Änderung auch per SSH mit rdfile und wrfile vorgenommen werden:

netapp01> rdfile /etc/resolv.conf
netapp01> wrfile /etc/resolv.conf
nameserver 192.168.2.50
search test.local
read: error reading standard input: Interrupted system call
netapp01> options dns.domainname test.local
netapp01> options dns.enable on

Mit rdfile /etc/resolv.conf wird der Inhalt der Datei /etc/resolv.conf ausgegeben. Die Datei kann über SSH leider nicht direkt editiert werden, sondern muss komplett neu geschrieben werden. Man muss also, falls vorhanden, den vorherigen Inhalt kopieren und die Datei mit wrfile /etc/resolv.conf neu schreiben. Nach dem Einfügen des bisherigen Inhalts aus der Zwischenablage wird die zusätzliche Zeile (Eintrag besteht aus nameserver und der IP des DNS Servers) eingegeben und das Editieren der Datei mit Ctrl+C beendet. Danach kann der Inhalt mit rdfile /etc/resolv.conf kontrolliert werden (vgl. Video unten).

Konfiguration über /etc/hosts

Ist kein DNS Server vorhanden, oder sollen die beiden VMs unabhängig von einem DNS Server sein, können die IP-Adressen und zugehörigen Hostnamen auch in der Datei /etc/hosts eingetragen werden. Der Eintrag muss wieder auf beiden Simulatoren erfolgen. Dazu kann wieder der OnCommand System Manager genutzt werden (Configuration => Network => Network Files).

Das Editieren der Datei ist natürlich auch wieder per SSH möglich:

netapp01> rdfile /etc/hosts
127.0.0.1 localhost localhost-stack
127.0.10.1 localhost-10 localhost-bsd
127.0.20.1 localhost-20 localhost-sk
192.168.2.66 netapp01 netapp01-e0a
# 0.0.0.0 netapp01-e0b
# 0.0.0.0 netapp01-e0c
# 0.0.0.0 netapp01-e0d
netapp01> wrfile /etc/hosts
127.0.0.1 localhost localhost-stack
127.0.10.1 localhost-10 localhost-bsd
127.0.20.1 localhost-20 localhost-sk
192.168.2.66 netapp01 netapp01-e0a
# 0.0.0.0 netapp01-e0b
# 0.0.0.0 netapp01-e0c
# 0.0.0.0 netapp01-e0d
192.168.2.67 netapp02
read: error reading standard input: Interrupted system call
netapp01> rdfile /etc/hosts
127.0.0.1 localhost localhost-stack
127.0.10.1 localhost-10 localhost-bsd
127.0.20.1 localhost-20 localhost-sk
192.168.2.66 netapp01 netapp01-e0a
# 0.0.0.0 netapp01-e0b
# 0.0.0.0 netapp01-e0c
# 0.0.0.0 netapp01-e0d
192.168.2.67 netapp02

Mit rdfile /etc/hosts wird der Inhalt der Datei /etc/hosts ausgegeben, der Inhalt in die Zwischaenablage kopiert und mit wrfile /etc/hosts neu geschrieben. Nach dem Einfügen des bisherigen Inhalts aus der Zwischenablage wird die zusätzliche Zeile (Eintrag besteht aus IP und Hostname des anderen Simulators) eingegeben und das Editieren der Datei mit Ctrl+C beendet. Danach kann der Inhalt mit rdfile /etc/hosts kontrolliert werden. Ein kurzes Video verdeutlicht die Vorgehensweise am Beispiel des 2. Simulators (netapp02).

Test der Konfiguration mit ping

Die Konfiguration kann mit einem ping von beiden Systemen kontrolliert werden:

netapp01> ping netapp02
netapp02 is alive

netapp02> ping netapp01
netapp01 is alive

NetApp vFiler DR mit Data ONTAP Simulator Teil 4: Erstellen eines Aggregats und Volumes

2016-01-21T00:00:00+00:00

Dies ist Teil einer Artikelserie.

In diesem Teil wird auf beiden Data ONTAP Simulatoren jeweils ein neues Aggregat (aggr1) und darin ein Volume (vol_vfiler01) für den vFiler angelegt. Dem Aggregat werden 14 Festplatten zugeordnet und das Volume wird mit einer Größe von 10 GB (minimale Größe für synchrone SnapMirror Beziehungen) angelegt. Auf dem ersten Simulator (netapp01) habe ich den OnCommand System Manager genutzt.

Auf dem zweiten Simulator (netapp02) habe ich die Schritte per SSH durchgeführt.

netapp02> aggr create aggr1 -t raid_dp 14
Mon Jan 16 21:50:53 CET [netapp02:raid.vol.disk.add.done:notice]: Addition of Disk /aggr1/plex0/rg0/v4.25 Shelf ? Bay ? [NETAPP VD-1000MB-FZ-520 0042] S/N [07762208] to aggregate aggr1 has completed successfully
Mon Jan 16 21:50:53 CET [netapp02:raid.vol.disk.add.done:notice]: Addition of Disk /aggr1/plex0/rg0/v5.24 Shelf ? Bay ? [NETAPP VD-1000MB-FZ-520 0042] S/N [07152307] to aggregate aggr1 has completed successfully
Mon Jan 16 21:50:53 CET [netapp02:raid.vol.disk.add.done:notice]: Addition of Disk /aggr1/plex0/rg0/v4.24 Shelf ? Bay ? [NETAPP VD-1000MB-FZ-520 0042] S/N [07762207] to aggregate aggr1 has completed successfully
Mon Jan 16 21:50:53 CET [netapp02:raid.vol.disk.add.done:notice]: Addition of Disk /aggr1/plex0/rg0/v5.22 Shelf ? Bay ? [NETAPP VD-1000MB-FZ-520 0042] S/N [07152306] to aggregate aggr1 has completed successfully
Mon Jan 16 21:50:53 CET [netapp02:raid.vol.disk.add.done:notice]: Addition of Disk /aggr1/plex0/rg0/v4.22 Shelf ? Bay ? [NETAPP VD-1000MB-FZ-520 0042] S/N [07762206] to aggregate aggr1 has completed successfully
Mon Jan 16 21:50:53 CET [netapp02:raid.vol.disk.add.done:notice]: Addition of Disk /aggr1/plex0/rg0/v5.21 Shelf ? Bay ? [NETAPP VD-1000MB-FZ-520 0042] S/N [07152305] to aggregate aggr1 has completed successfully
Mon Jan 16 21:50:53 CET [netapp02:raid.vol.disk.add.done:notice]: Addition of Disk /aggr1/plex0/rg0/v4.21 Shelf ? Bay ? [NETAPP VD-1000MB-FZ-520 0042] S/N [07762205] to aggregate aggr1 has completed successfully
Mon Jan 16 21:50:53 CET [netapp02:raid.vol.disk.add.done:notice]: Addition of Disk /aggr1/plex0/rg0/v5.20 Shelf ? Bay ? [NETAPP VD-1000MB-FZ-520 0042] S/N [07152304] to aggregate aggr1 has completed successfully
Mon Jan 16 21:50:53 CET [netapp02:raid.vol.disk.add.done:notice]: Addition of Disk /aggr1/plex0/rg0/v4.20 Shelf ? Bay ? [NETAPP VD-1000MB-FZ-520 0042] S/N [07762204] to aggregate aggr1 has completed successfully
Mon Jan 16 21:50:53 CET [netapp02:raid.vol.disk.add.done:notice]: Addition of Disk /aggr1/plex0/rg0/v5.19 Shelf ? Bay ? [NETAPP VD-1000MB-FZ-520 0042] S/N [07152303] to aggregate aggr1 has completed successfully
Mon Jan 16 21:50:53 CET [netapp02:raid.vol.disk.add.done:notice]: Addition of Disk /aggr1/plex0/rg0/v4.19 Shelf ? Bay ? [NETAPP VD-1000MB-FZ-520 0042] S/N [07762203] to aggregate aggr1 has completed successfully
Mon Jan 16 21:50:53 CET [netapp02:raid.vol.disk.add.done:notice]: Addition of Disk /aggr1/plex0/rg0/v5.18 Shelf ? Bay ? [NETAPP VD-1000MB-FZ-520 0042] S/N [07152302] to aggregate aggr1 has completed successfully
Mon Jan 16 21:50:53 CET [netapp02:raid.vol.disk.add.done:notice]: Addition of Disk /aggr1/plex0/rg0/v4.18 Shelf ? Bay ? [NETAPP VD-1000MB-FZ-520 0042] S/N [07762202] to aggregate aggr1 has completed successfully
Mon Jan 16 21:50:53 CET [netapp02:raid.vol.disk.add.done:notice]: Addition of Disk /aggr1/plex0/rg0/v5.17 Shelf ? Bay ? [NETAPP VD-1000MB-FZ-520 0042] S/N [07152301] to aggregate aggr1 has completed successfully
Creation of an aggregate with 14 disks has completed.
Mon Jan 16 21:50:57 CET [netapp02:wafl.aggr.btiddb.build:info]: Buftreeid database for aggregate 'aggr1' UUID 'bc9d185d-55e8-4bd2-b537-5123f859ff87' was built in 0 msec, after scanning 0 inodes and restarting -1 times with a final result of starting.
Mon Jan 16 21:50:57 CET [netapp02:wafl.aggr.btiddb.build:info]: Buftreeid database for aggregate 'aggr1' UUID 'bc9d185d-55e8-4bd2-b537-5123f859ff87' was built in 25 msec, after scanning 0 inodes and restarting 0 times with a final result of success.
Mon Jan 16 21:50:57 CET [netapp02:wafl.vol.add:info]: Aggregate aggr1 has been added to the system.

netapp02> vol create vol_vfiler01 aggr1 10G
Creation of volume 'vol_vfiler01' with size 10g on containing aggregate 'aggr1' has completed.

PowerShell Parameter auf gültige Werte prüfen

2016-01-18T00:00:00+00:00

Bei der Übergabe von Parametern möchte man diese evtl. auf gültige Werte einschränken. Natürlich kann diese Überprüfung selbst mit if-Anweisungen erledigt werden. Gültige Werte können aber auch schon bei der Definition der Parameter vorgegeben werden.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32


# Definition der Parameter
Param(
 [Parameter(Mandatory=$True)]
 [string]$StringParameter1,

 [Parameter(Mandatory=$True)]
 [ValidateSet("String1","String2")]
 [string]$StringParameter2,

 [Parameter(Mandatory=$True)]
 [int]$IntegerParameter1,

 [Parameter(Mandatory=$True)]
 [ValidateRange(0, 5)]
 [int]$IntegerParameter2
)

# eigene Überprüfung der Parameter
if (-not($StringParameter1 -eq "String1" -or $StringParameter1 -eq "String2")) {
 Write-Output "Fehler! Gültige Werte für StringParameter1 sind ""String1"" und ""String2""."
 exit
}
if ($IntegerParameter1 -lt 0 -or $IntegerParameter1 -gt 5) {
 Write-Output "Fehler! Wert für IntegerParameter1 muss im Bereich 0 bis 5 liegen."
 exit
}

# Ausgabe der Parameter
Write-Output "StringParameter1: $StringParameter1"
Write-Output "StringParameter2: $StringParameter2"
Write-Output "IntegerParameter1: $IntegerParameter1"
Write-Output "IntegerParameter2: $IntegerParameter2"

Im Beispiel werden $StringParameter1 und $IntegerParameter1 durch eigenen Code überprüft (Zeile 18 bis 24). Die beiden anderen Parameter werden mit ValidateSet (Zeile 7) und ValidateRange (Zeile 14) auf gültige Werte geprüft. In beiden Fällen dürfen als String “String1” oder “String2” und als Integer die Zahlen von 0 bis 5 übergeben werden. Als Beispiele die Fehlerausgabe bei der eigenen Überprüfung

PS C:\> .\ValidatePowerShellParameter.ps1 -StringParameter1 "ein anderer String" -StringParameter2 "String2" -IntegerParameter1 3 -IntegerParameter2 5
Fehler! Gültige Werte für StringParameter1 sind "String1" und "String2".
At C:\ValidatePowerShellParameter.ps1:20 char:10
+ Throw <<<< "Fehler! Gültige Werte für StringParameter1 sind ""String1"" und ""String2""."
+ CategoryInfo : OperationStopped: (Fehler! Gültige... und "String2".:String) [], RuntimeException
+ FullyQualifiedErrorId : Fehler! Gültige Werte für StringParameter1 sind "String1" und "String2".

und bei einem Fehler mit ValidateRange.

PS C:\> .\ValidatePowerShellParameter.ps1 -StringParameter1 "String1" -StringParameter2 "String2" -IntegerParameter1 3 -IntegerParameter2 8
C:\ValidatePowerShellParameter.ps1 : Cannot validate argument on parameter 'IntegerParameter2'. The 8 argument is greater than the maximum allowed range of 5. Supply an argument that is less than 5 and then try the command again.
At line:1 char:120
+ .\ValidatePowerShellParameter.ps1 -StringParameter1 "String1" -StringParameter2 "String2" -IntegerParameter1 3 -IntegerParameter2 <<<< 8
+ CategoryInfo : InvalidData: (:) [ValidatePowerShellParameter.ps1], ParameterBindingValidationException
+ FullyQualifiedErrorId : ParameterArgumentValidationError,ValidatePowerShellParameter.ps1

Neben ValidateSet und ValidateRange gibt es noch weitere [Möglichkeiten](https://technet.microsoft.com/en-us/library/dd347600.aspx ““about_Functions_Advanced_Parameters” im Microsoft TechNet”):

ValidateCount
ValidateLength
ValidatePattern
ValidateRange
ValidateScript
ValidateSet
ValidateNotNull
ValidateNotNullOrEmpty

Ein kurzes Beispiel für ValidateScript:

1
2
3
4
5
6
7
8
9


# Definition der Parameter
Param(
 [Parameter(Mandatory=$True)]
 [ValidateScript({$_ -match "St.*g"})]
 [string]$StringParameter
)

# Ausgabe der Parameter
Write-Output "StringParameter: $StringParameter"

Leider ist es nicht möglich innerhalb des ValidateScript-Teils auf andere übergebene Parameter zuzugreifen. Sind die gültigen Werte eines Parameters also abhängig vom Wert eines weiteren Parameters, muss die Überprüfung außerhalb der Parameterdefinition erfolgen.

Außerdem ist zu beachten, dass nur übergebene Parameter überprüft werden. Wird ein Wert als Default gesetzt und nicht als Parameter übergeben, findet keine Überprüfung statt und der Wert muss (soweit wirklich erforderlich) mit eigenem Code geprüft werden.

1
2
3
4
5
6
7
8
9


# Definition der Parameter
Param(
 [Parameter(Mandatory=$False)]
 [ValidateRange(0,5)]
 [string]$IntegerParameter=8
)

# Ausgabe der Parameter
Write-Output "IntegerParameter: $IntegerParameter"

PS C:\> .\ValidatePowerShellParameter.ps1
IntegerParameter: 8
PS C:\> .\ValidatePowerShellParameter.ps1 -IntegerParameter 8
C:\ValidatePowerShellParameter.ps1 : Cannot validate argument on parameter 'IntegerParameter'. The 8 argument is greater than the maximum allowed range of 5. Supply an argument that is less than 5 and then try the command again.
At line:1 char:43
+ .\ValidatePowerShellParameter.ps1 -IntegerParameter <<<< 8
+ CategoryInfo : InvalidData: (:) [ValidatePowerShellParameter.ps1], ParameterBindingValidationException
+ FullyQualifiedErrorId : ParameterArgumentValidationError,ValidatePowerShellParameter.ps1

Zukunft von jk_poll

2016-01-12T00:00:00+00:00

jk_poll gibt es mittlweile schon seit 10 Jahren (erster Upload in 2005). Neue Versionen erscheinen nur noch sehr selten und sind meist auch nur kleinere Bugfixes wie z.B. auch die Kompatibilität zu TYPO3 6.2.x. Aus meiner Sicht ist die Extension “Feature complete”.

Ich startete jk_poll weil ich für eine TYPO3-Installation eine Umfrage umsetzen wollte und keine für mich passende fand. Über die Jahre kamen immer mal wieder Anfragen für neue Features, wodurch die Extension sich weiterentwickelte. Mittlerweile setze ich jk_poll selber nicht mehr ein (außer im Demo-Bereich). Generell nutze ich TYPO3 nur noch für ein paar alte Installationen. Deshalb wird es vermutlich auch in Zukunft keine neuen Features geben. Im Gegenteil, evtl. fallen auch Features weg da benötigte Extensions wie comments mit der heute aktuellen TYPO3-Version 6.2.17 nicht mehr kompatibel sind. Anfragen können natürlich weiterhin gestellt werden, sie werden allerdings nur in absoluten Ausnahmefällen umgesetzt. Weiterhin geben wird es (soweit notwendig) Bugfixes und die Kompatibilität für zumindest TYPO3 in der Version 6.x.

Auf Github wurde jk_poll auch “geforkt”. Vielleicht ist auch dieser Fork für manche Benutzer von jk_poll interessant.

Zusammenfassung: jk_poll wird keine neuen Features erhalten. Bugfixes und Kompatibilität zu TYPO3 Version 6.x sind weiterhin gewährleistet.

NetApp vFiler DR mit Data ONTAP Simulator Teil 3: Einrichtung des 2. Simulators

2015-12-19T00:00:00+00:00

Dies ist Teil einer Artikelserie.

Prinzipiell wird der 2. Simulator genauso eingerichtet wie die 1. VM. Als einzige Besonderheit müssen wie in Teil 1 angedeutet die Seriennummer und Systemid der Data ONTAP Installation geändert und die dazu passenden Lizenzen genutzt werden.

Aus der Datei “VSIM Licenses: 8.2.3 licenses Clustered-ONTAP” wird nun eine passende Seriennummer ausgewählt. In meinem Fall enthält die Datei die Zeile “Licenses for the non-ESX build (Serial Number 4082368507)”. Die Seriennummer für die 2. VM lautet also 4082368507 und darunter sind die Lizenzen für die 2. VM aufgeführt.

Nach dem Einschalten der 2. VM wird an der Stelle “Hit [Enter] to boot immediately, or any other key for command prompt.” eine beliebige andere Taste gedrückt. Das command prompt meldet sich dann mit “SIMLOADER>”. An dieser Stelle werden Seriennummer und Systemid mit den Befehlen set SYS_SERIAL_NUM=4082368-50-7 und set bootarg.nvram.sysid=4082368507 neu gesetzt und das System danach mit “boot” gestartet.

Die restliche Konfiguration läuft wie beim 1. Simulator ab. Also erst Ctrl+C, mit 4 die Konfiguration neu starten und Hostnamen und IP-Einstellungen vergeben. Danach wieder per SSH einloggen und die Befehle wie in Teil 2 eingeben. Die Lizenzen müssen jetzt natürlich wie die Seriennummer aus der Datei “VSIM Licenses: 8.2.3 licenses Clustered-ONTAP” entnommen werden.

Jetzt stehen also 2 Data ONTAP Simulatoren zur Verfügung auf denen in den weiteren Teilen der Serie ein vFiler DR eingerichtet werden kann.

Alternativer Client für Let's Encrypt

2015-12-17T00:00:00+00:00

Wie schon im 1. Artikel zu Let’s Encrypt kurz erwähnt ist die Installation des Clients und die notwendige Umgebung unter ~/.local/ nicht ganz durchsichtig. Als Alternative habe ich den Client acme-tiny getestet. Voraussetzung für den Client ist lediglich Python und OpenSSL. Der Quellcode ist unter 200 Zeilen und somit noch einigermaßen leicht nachvollziehbar.

Als weiteren Vorteil kann man durch Subject Alternative Names auch ein Zertifikat erstellen, dass für mehrere Domains (die auf den gleichen Server und Webspace verweisen) gültig ist. So kann also z.B. ein für die Domains krausmueller.de und www.krausmueller.de gültiges Zertifikat ausgestellt werden. Die README enthält alle notwendigen Schritte, weshalb ich nur kurz auf die aus meiner Sicht wichtigsten Schritte gesondert eingehe.

Die Domains für die das Zertifikat ausgestellt wird (Subject Alternative Names) werden in Schritt 2 angegeben.

Der Nachweis, dass die Domain auch von einem verwaltet wird erfolgt bei acme-tiny per Dateien im Ordner .well-known/acme-challenge/ unterhalb der Domain. Es muss also entweder beim Aufruf des Clients in Schritt 4 als acme-dir der volle Pfad zu diesem Ordner angegeben (also z.B. /var/www/domain/.well-known/acme-challenge) oder ein Alias auf ein anderes Verzeichnis angelegt werden, welches dann als acme-dir angegeben werden kann (Beispiel unten für Apache).

1

Alias /.well-known/acme-challenge/ "/var/www/challenges/"

Die Beispielkonfiguration in Schritt 5 der README ist für nginx. Ein Konfiguration für Apache könnte folgendermaßen aussehen:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


<VirtualHost *:443>
 ServerAdmin webmaster@localhost
 ServerName krausmueller.de
 ServerAlias www.krausmueller.de
 DocumentRoot /var/www/krausmueller

 SSLEngine on
 SSLCertificateFile /home/johannes/lets_encrypt/signed.crt
 SSLCertificateChainFile /home/johannes/lets_encrypt/intermediate.pem
 SSLCertificateKeyFile /home/johannes/lets_encrypt/domain.key
 SSLProtocol all -SSLv2 -SSLv3 -TLSv1
 SSLCipherSuite ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!3DES:!MD5:!PSK
 SSLHonorCipherOrder on
</VirtualHost>

Zusätzlich kann man noch alle HTTP-Zugriffe automatisch auf HTTPS umleiten. Als Ausnahme muss dabei der Ordner .well-known/acme-challenge definiert werden, da dieser Pfad beim Erneuern des Zertifikats per HTTP erreichbar sein muss.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


<VirtualHost *:80>
 ServerAdmin webmaster@localhost
 ServerName krausmueller.de
 ServerAlias www.krausmueller.de
 DocumentRoot /var/www/

 <IfModule mod_rewrite.c>
 RewriteEngine On
 RewriteCond %{REQUEST_URI} !^/\.well\-known/acme\-challenge/
 RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]
 </IfModule>
</VirtualHost>

Für das Erneuern des Zertifikats muss wie in Schritt 6 der README beschrieben ein Script erstellt werden, welches dann per Cronjob regelmäßig ausgeführt wird.

NetApp vFiler DR mit Data ONTAP Simulator Teil 2: Einrichtung des 1. Simulators

2015-12-15T00:00:00+00:00

Dies ist Teil einer Artikelserie.

Nach dem Entpacken der Datei vsim_netapp-7m.tgz muss die Datei DataONTAP.vmx in VMware Fusion geöffnet werden. Die virtuellen Netzwerkkarten sind standardmäßig auf “Host-only” bzw. “Privat auf meinem Mac” eingestellt, also nur vom Fusion Host selbst erreichbar. Um mit den Simulatoren im normalen Netzwerk kommunizieren zu können, sollte der Netzwerktyp auf “Bridged” gesetzt werden.

Nach dem Start der VM muss sie neu konfiguriert werden (z.B. IP-Adress und Hostname). Dazu erst Ctrl+C drücken und mit 4 die Konfiguration neu starten und alle Disks neu initialisieren. Die Nachfragen jeweils mit “Y” bestätigen. Die VM startet neu und fragt nach einer Weile den Hostnamen und die IP-Einstellungen ab. Ich habe nur die erste Netzwerkkarte konfiguriert. Alle anderen Fragen werden durch “ENTER” mit dem Default-Wert beantwortet. Nach Vergabe eines Passworts steht der erste Filer prinzipiell bereit. Ein kurzes Video veranschaulicht die Einrichtung vermutlich am besten:

Ab jetzt kann man sich z.B. mit putty per SSH einloggen (Benutzer root und das vorher vergebene Passwort) und die restliche Konfiguration vornehmen.

Als erstes sollte man den Autosupport abschalten, so daß das System Fehler nicht automatisch zu NetApp schickt. Außerdem kann man gleich die Zeitzone richtig einstellen (sofern nicht schon bei der initialen Konfiguration richtig gesetzt). Durch die Aktivierung von TLS lässt sich später auch der OnCommand System Manager nutzen.

netapp01> options autosupport.support.enable off
netapp01> timezone Europe/Berlin
netapp01> options tls.enable on

Als nächstes kann man die virtuellen Festplatten der NetApp zuordnen, so daß sie später genutzt werden können:

netapp01> disk show -n
DISK OWNER POOL SERIAL NUMBER HOME DR HOME
------------ ------------- ----- ------------- ------------- -------------
v4.16 Not Owned NONE 08523900
v4.17 Not Owned NONE 08523901
v4.18 Not Owned NONE 08523902
v4.19 Not Owned NONE 08523903
v4.20 Not Owned NONE 08523904
v4.21 Not Owned NONE 08523905
v4.22 Not Owned NONE 08523906
v4.24 Not Owned NONE 08523907
v4.25 Not Owned NONE 08523908
v4.26 Not Owned NONE 08523909
v4.27 Not Owned NONE 08523910
v4.28 Not Owned NONE 08523911
v4.29 Not Owned NONE 08523912
v4.32 Not Owned NONE 08523913
netapp01> disk assign all
Mon Dec 14 22:31:18 CET [netapp01:diskown.changingOwner:info]: changing ownership for disk v4.16 (S/N 08523900) from unowned (ID 4294967295) to netapp01 (ID 4082368508)
Mon Dec 14 22:31:18 CET [netapp01:diskown.changingOwner:info]: changing ownership for disk v4.17 (S/N 08523901) from unowned (ID 4294967295) to netapp01 (ID 4082368508)
Mon Dec 14 22:31:18 CET [netapp01:diskown.changingOwner:info]: changing ownership for disk v4.18 (S/N 08523902) from unowned (ID 4294967295) to netapp01 (ID 4082368508)
Mon Dec 14 22:31:18 CET [netapp01:diskown.changingOwner:info]: changing ownership for disk v4.19 (S/N 08523903) from unowned (ID 4294967295) to netapp01 (ID 4082368508)
Mon Dec 14 22:31:18 CET [netapp01:diskown.changingOwner:info]: changing ownership for disk v4.20 (S/N 08523904) from unowned (ID 4294967295) to netapp01 (ID 4082368508)
Mon Dec 14 22:31:18 CET [netapp01:diskown.changingOwner:info]: changing ownership for disk v4.21 (S/N 08523905) from unowned (ID 4294967295) to netapp01 (ID 4082368508)
Mon Dec 14 22:31:18 CET [netapp01:diskown.changingOwner:info]: changing ownership for disk v4.22 (S/N 08523906) from unowned (ID 4294967295) to netapp01 (ID 4082368508)
Mon Dec 14 22:31:18 CET [netapp01:diskown.changingOwner:info]: changing ownership for disk v4.24 (S/N 08523907) from unowned (ID 4294967295) to netapp01 (ID 4082368508)
Mon Dec 14 22:31:18 CET [netapp01:diskown.changingOwner:info]: changing ownership for disk v4.25 (S/N 08523908) from unowned (ID 4294967295) to netapp01 (ID 4082368508)
Mon Dec 14 22:31:18 CET [netapp01:diskown.changingOwner:info]: changing ownership for disk v4.26 (S/N 08523909) from unowned (ID 4294967295) to netapp01 (ID 4082368508)
Mon Dec 14 22:31:18 CET [netapp01:diskown.changingOwner:info]: changing ownership for disk v4.27 (S/N 08523910) from unowned (ID 4294967295) to netapp01 (ID 4082368508)
Mon Dec 14 22:31:18 CET [netapp01:diskown.changingOwner:info]: changing ownership for disk v4.28 (S/N 08523911) from unowned (ID 4294967295) to netapp01 (ID 4082368508)
Mon Dec 14 22:31:18 CET [netapp01:diskown.changingOwner:info]: changing ownership for disk v4.29 (S/N 08523912) from unowned (ID 4294967295) to netapp01 (ID 4082368508)
Mon Dec 14 22:31:18 CET [netapp01:diskown.changingOwner:info]: changing ownership for disk v4.32 (S/N 08523913) from unowned (ID 4294967295) to netapp01 (ID 4082368508)

Als letztes werden noch die Lizenzen eingespielt und Features aktiviert. Die Lizenzen sind in der Datei “VSIM Licenses: 8.2.3 licenses 7-Mode” aus Part 1 im Bereich “Licenses for the non-ESX build” zu finden und müssen für jeden License Code mit “license add” hinzugefügt werden (im Beispiel unten ist dies nur für einen License Code aufgeführt und die Lizenz durch “XXXXXXXXXXXXXXXXXXXXXXXXXXXX” dargestellt).

netapp01> license add XXXXXXXXXXXXXXXXXXXXXXXXXXXX
license add: successfully added license key "XXXXXXXXXXXXXXXXXXXXXXXXXXXX".
netapp01> options licensed_feature.multistore.enable on
netapp01> options snapmirror.enable on
netapp01> options rsh.enable on

Nginx mit SSL und Let's Encrypt absichern

2015-12-13T00:00:00+00:00

Hinweis: Wenn man den Client und Pakete die für ihn benötigt werden nicht zusätzlich auf seinem Server installieren will kann man auch mit der Hilfe einer Webseite die einzelnen Schritte zur Ausstellung des Zertifikats manuell durchführen.

Seit dem 3. Dezember 2015 befindet sich Let’s Encrypt in der Public Beta. Das bedeutet man kann sich ohne vorherige Registrierung und Wartezeit ein kostenloses SSL Zertifikat für seine Domain erstellen. Für mein “Heimcloud” nutze ich einen Cubietruck (ähnlich zum weitaus bekannteren Raspberry Pi) mit Nginx. Dieser Artikel zeigt wie ich Nginx mit einem SSL-Zertifikat von Let’s Encrypt eingerichtet habe.

Als erstes musss der Let’s Encrypt Client installiert werden. Dabei werden alle benötigten Debian-Pakete installiert:

hostname:~# git clone https://github.com/letsencrypt/letsencrypt
hostname:~# cd letsencrypt
hostname:~/letsencrypt# ./letsencrypt-auto

Für Nginx gibt es noch kein Plugin das die Installation des Zertifikats automatisch vornimmt. Deshalb wird als Plugin standalone verwendet und die Nginx Konfiguration danach manuell angepasst. Zur Validierung der Domain (nicht das man sich ein Zertifikat für eine Domain ausstellt die man gar nicht administriert) werden Port 80 oder 443 genutzt. Da Nginx auf diesen Ports lauscht muss er während der Ausstellung des Zertifikats gestoppt werden. In meinem Fall habe ich kein Problem damit wenn der Webserver kurz nicht verfügbar. Alternativ kann die Domain auch über ein Verzeichnis im Webroot validiert werden:

hostname:~# sudo /etc/init.d/nginx stop
hostname:~# ./letsencrypt-auto certonly -d example.krausmueller.de
hostname:~# sudo /etc/init.d/nginx start

Wenn alles geklappt hat liegen die Dateien des Zertifiktas unter /etc/letsencrypt/live/example.krausmueller.de/:

hostname:~# sudo ls /etc/letsencrypt/live/example.krausmueller.de/
cert.pem chain.pem fullchain.pem privkey.pem

Neben dem Zertifikat sollte man noch seien eigenen Diffie-Hellman-Parameter erstellen:

hostname:~# sudo openssl dhparam -out /etc/nginx/dhparams.pem 2048

Eine möglichst sichere Konfiguration für Nginx lässt sich mit dem Mozilla SSL Configuration Generator erstellen. Wichtig ist es dabei die richtige Version des Servers und von OpenSSL einzutragen. Die für meine Zertifikate angepasste Konfiguration:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22


server {
 listen 443 ssl;
 server_name example.krausmueller.de;

 # certs sent to the client in SERVER HELLO are concatenated in ssl_certificate
 ssl_certificate /etc/letsencrypt/live/example.krausmueller.de/fullchain.pem;
 ssl_certificate_key /etc/letsencrypt/live/example.krausmueller.de/privkey.pem;
 ssl_session_timeout 1d;
 ssl_session_cache shared:SSL:50m;

 # Diffie-Hellman parameter for DHE ciphersuites, recommended 2048 bits
 ssl_dhparam /etc/nginx/dhparams.pem;

 # modern configuration. tweak to your needs.
 ssl_protocols TLSv1.1 TLSv1.2;
 ssl_ciphers 'ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!3DES:!MD5:!PSK';
 ssl_prefer_server_ciphers on;

 # HSTS (ngx_http_headers_module is required) (15768000 seconds = 6 months)
 add_header Strict-Transport-Security max-age=15768000;

}

Nach einem Neustart des Nginx sollte ein Test bei SSL Labs jetzt ein “A Rating” ergeben.

Zertifikate von Let’s Encrypt sind lediglich 90 Tage gültig und müssen deshalb regelmäßig erneuert werden. Am einfachsten lässt sich das über einen Cronjob erledigen. Bei diesem Beispiel wird das Zertifikat jeden 2. Monat am 28. (wichtig durch möglichen Schalttag im Februar) erneuert:

hostname:~# crontab -l
# m h dom mon dow command
0 1 28 2,4,6,8,10,12 * sudo /etc/init.d/nginx stop; /home/user/letsencrypt/letsencrypt-auto certonly --renew -d example.krausmueller.de; sudo /etc/init.d/nginx start

NetApp vFiler DR mit Data ONTAP Simulator Teil 1: Download der benötigten Komponenten

2015-12-03T00:00:00+00:00

Dies ist Teil einer Artikelserie.

Um die NetApp vFiler DR Funktionalität, aber auch andere Funktionen, zu testen bietet sich der Data ONTAP Simulator an. Ziel dieser Artikelserie sind 2 NetApps im 7-Mode auf denen alle nötigen Lizenzen eingespielt und die vFiler eingerichtet sind. Als Grundlage dient hier VMware Fusion unter Mac OS X, es sollte aber auf anderen Plattformen (z.B. VMware Workstation unter Windows) ähnlich funktionieren.

Zum Download des Simulators muss man sich (sofern noch kein Account vorhanden ist) bei NetApp registrieren. Danach kann dann die passende VM heruntergeladen werden. Die VMs stehen im Format für VMware ESX oder Workstation, Player und Fusion bereit. Außerdem wird zwischen “7-Mode” und “Clustered-ONTAP” unterschieden. In diesem Beispiel wird 7-Mode (Version 8.2.3) für VMware Fusion verwendet.

Neben der Datei vsim_netapp-7m.tgz werden noch die Lizenzen für Features wie SnapMirror benötigt. Die Lizenzen sind abhängig von der Seriennummer der Data ONTAP Installation. Der heruntergeladene Simulator besitzt immer die gleiche Seriennummer. Um einen 2. Simulator zu verwenden muss dessen Seriennummer geändert werden. Das bedeutet das auch andere Lizenzen (passend zu der geänderten Seriennumer) benötigt werden. Zum Glück kann man dazu die Lizenzen für Clustered-ONTAP nutzen. Es müssen also die Lizenzen “VSIM Licenses: 8.2.3 licenses 7-Mode” und “VSIM Licenses: 8.2.3 licenses Clustered-ONTAP” heruntergeladen werden.

Frontend Editing in TYPO3 6.2

2015-12-01T00:00:00+00:00

Nach dem Update von TYPO3 4.5 auf Version 6.2 funktionierte die Systemextension “Frontend Editing” (feedit) nicht mehr. Die Icons zum Editieren von Inhalten werden nicht angezeigt. Die Benutzer sind alle Mitglied einer Benutzergruppe mit folgender TSconfig:

1
2
3
4
5
6
7
8


admPanel {
 enable.edit = 1
 module.edit.forceNoPopup = 1
 module.edit.forceDisplayFieldIcons = 0
 module.edit.displayIcons = 1
 module.edit.forceDisplayIcons = 1
 hide = 1
}

Nach ein wenig Debuggen stellte sich heraus, dass bei dieser Konfiguration die CSS-Datei für das Admin-Panel nicht eingebunden wird. Der Bug ist auch hier beschrieben. Der Fehler ist wohl in TYPO3 7.4 behoben, aber leider nicht für Version 6.2.

Als Workaround habe ich die CSS-Datei manuell über das Template eingebunden:

1
2
3
4
5
6


# Workaround für feedit
[globalVar = TSFE : beUserLogin > 0]
page.includeCSS {
 file1 = typo3/sysext/t3skin/stylesheets/standalone/admin_panel.css
}
[global]

Sobald ein User am Backend angemeldet ist, wird die CSS-Datei admin_panel.css in die Seite eingebunden.

Parameter an PowerShell Script übergeben

2015-11-26T00:00:00+00:00

Um einem PowerShell Script Parameter übergeben zu können müssen diese vorher definiert werden. Dabei legt man auch den Datentyp des Parameters fest. Ein kleines Beispiel verdeutlicht es denke ich am besten:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


# Definition der Parameter
Param(
 [string]$StringParameter,
 [bool]$BooleanParameter = $False,
 [int]$IntegerParameter = 10,
 [switch]$SwitchParameter
)

# Ausgabe der Parameter
Write-host "StringParameter: $StringParameter"
Write-host "BooleanParameter: $BooleanParameter"
Write-host "IntegerParameter: $IntegerParameter"
Write-host "SwitchParameter: $SwitchParameter"

Mehrere Parameter werden durch Komma getrennt, nach dem letzten Parameter folgt kein Komma. Es können auch gleich Werte zugewiesen werden (im Beispiel $BooleanParameter und $IntegerParameter) die durch den übergebenen Parameter überschrieben werden. Wird ein Parameter beim Aufruf nicht angegeben, gilt der zugewiesene Wert. Statt eines Parameters mit dem Typ Boolean kann auch der Typ Switch verwendet werden. Mit Switch ist die Variable “True” sobald sie im Aufruf vorhanden ist (es reicht also ein “-SwitchParameter” anstatt “-SwitchParameter:$True”).

Ein Aufruf und die Ausgabe könnte dann so aussehen:

PS C:\> .\PowerShellParameter.ps1 -StringParameter "Text" -BooleanParameter $True
StringParameter: Text
BooleanParameter: True
IntegerParameter: 10
SwitchParameter: False

Außerdem kann definiert werden das bestimmte Parameter unbedingt angegeben werden müssen:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20


# Definition der Parameter
Param(
 [Parameter(Mandatory=$True)]
 [string]$StringParameter,

 [Parameter(Mandatory=$False)]
 [bool]$BooleanParameter = $False,

 [Parameter(Mandatory=$False)]
 [int]$IntegerParameter = 10,

 [Parameter(Mandatory=$False)]
 [switch]$SwitchParameter
)

# Ausgabe der Parameter
Write-host "StringParameter: $StringParameter"
Write-host "BooleanParameter: $BooleanParameter"
Write-host "IntegerParameter: $IntegerParameter"
Write-host "SwitchParameter: $SwitchParameter"

Durch “(Mandatory=$True)” wird festgelegt, dass der Parameter angebeben werden muss (Zeile 3). Bei “$False” kann der Parameter angegeben werden, muss er aber nicht. Muss ein Parameter nicht angegeben werden ist es meist sinnvoll ihn wie schon im 1. Beispiel mit einem Default-Wert zu belegen (Zeile 7 und 10).

Wird im Beispiel “$StringParameter” nicht angegeben wird er von PowerShell abgefragt:

PS C:\> .\PowerShellParameter.ps1 -BooleanParameter $True
cmdlet PowerShellParameter.ps1 at command pipeline position 1
Supply values for the following parameters:
StringParameter: