Will man auf einem Hyper-V-Host ein VM mit aktivierter Virtualisierung – z.B. einen Server mit der Hyper-V-Rolle – installieren, muss man die VM erstellen und dann das Nested Virtualization-Feature für die VM mit folgenden Befehlen per Powershell aktivieren:
Ich mache bei meinen WLAN-Projekten eigentlich fast alles immer mit der UniFi-Serie von Ubiquiti. Ich war bzw. bin da eigentlich auch immer zufrieden gewesen.
Jetzt hatte ich für ein Projekt mir das Aruba Instant On System (in dem genauen Fall die AP11) angesehen – und wollte kurz über die AccessPoint bzw. das System berichten.
Aruba Instant On ist komplett Cloud-managed -> ohne Account bei arubainstanton.com geht gar nix. Die Einrichtung erfolgt über die App (iOS und Android) oder über die Webseite unter portal.arubainstanton.com. Wer hier also Bedenken hat -> leider das falsche System.
Das Instant On System ist auf Einfachkeit und für schnelle Bereitstellung konzipiert. Auch gibt es Limits – sowohl die maximale Anzahl (25) an AccessPoints pro Standort und auch an Optionen zur Konfiguration – z.B. keine Möglichkeit zur Kanalwahl etc.
Die Geräte supporten alles was man so braucht – natürlich Mesh-fähig, support von DFS, ARM, Band Steering, Airtime Fairness, 802.11ac Wave 2 mit 802.11v. Leider kein Wifi 6 :-/
Das Setup ist sehr einfach gehalten – man kann eigentlich nix falsch machen. Hier kann man den ganzen Prozess mal in einem Video anschauen: Youtube
Das Setup sieht so aus : die AccessPoints anstecken damit die AccessPoints online sind. Sie werden automatisch geupdatet und geben durch blinken dann Bescheid wenn sie ready sind – das kann dauern…
Danach in der App oder im WebPortal einen Netwerk einrichten – hier werden nur die wichtigsten Sachen abgefragt : SSID (Name des WLANs), Passwort oder Radius, WPA3 an oder aus (WPA2 oder WPA2+WPA3-Mix-Mode) und VLAN. Danach gibt man noch die Seriennummer eines oder mehreren AcessPoints an -> fertig. Dauer des Setups: wenige Minuten.
Danach hat man in der App und im Webportal folgende Ansicht:
Unter Netwerke befindet sich die Verwalrung der WLAN-Netzte.
Unter IP und VLAN-Zuweisung zwischen Standard und NAT-Modus wählen. Bei Standard macht der lokale Router, Firewall oder DHCP-Server die Adressvergabe -ausserdem kann man bei Bridge-Modus ein VLAN vergeben. Beim NAT-Modus werden alle Clients in ein eigenes Netz gelegt. Ausserdem kann hier die Bandbreite beschränkt werden – falls das benötigt wird.
Ausserdem kann ein Zeitplan gesetzt werden
Und noch ein bischen Statistik
Mehr Optionen gibt es nicht – alles andere regelt der Controller bzw. die AcessPoints selbst.
Unter Clients sieht man alle verbundenen Geräte
Unter Anwendungen gibt es eine Katogerosierung sowie einen kleinen WebFilter. Hier können Kategorien pro Netwerk zugelasen oder verboten werden.
Unter Inventar sind die Geräte. Hier können Namen vergeben werden. Mehr Konfiguration ist nicht möglich – ausser neustarten über das Werkzeugschlüssel-Tool
In der Standortverwaltung kann man noch rudimentäre Optionen wie Name, Zeitzone, etc setzen – und ein Portal anlagen:
Das Portal erscheint wenn beim Netzwerk der Netwerk-Typ Gast ausgewählt wurde:
Fazit
Das Instant On ist ein gutes Fire-and-Forget-System das gut gegen das UniFi-System konkurrieren kann (die AP11 gegen das AC-Lite, der AP12 gegen den AC-LR und der AP15 gegen den AC-HD). Die Performance ist einen Ticken besser – die Reichweite ähnlich. Stabilität des Wifis war besser als ein vergleichbares Unifi-System (ca. 4 Wochen jetzt am laufen).
Bei UniFi kann ich halt alles mögliche einstellen und selber meinen Controller betreiben – das kann ich hier halt nicht -> der das nicht will oder braucht bekommt ein super System – den man merkt schon das Aruba weiß wie Wifi geht. Mit dem Verhalten out-of-box war ich sehr zufrieden. An einigen Stellen merkt man zwar noch dass das System sehr jung ist (Markteinführung Mitte 2019) -> aber wer keine Angst vor der Cloud hat und sich keinen Controller selbst hosten will/kann bekommt mit dem Instant On von Aruba ein kostengünstiges, stabiles Wifi-System für Zuhause und kleine Büros/Geschäfte.
Ich werde jetzt mal weiter testen und wohl noch den einen oder anderen beim nächsten kleineren Projekt verbauen 🙂
Wen man Debian/Ubuntu nutzt kann man jetzt den ganzen Fedora/Redhat/Centos-Teil löschen und die UNIFI_DIR, JAVA_DIR und KEYSTORE Zeilen für Debian/Ubuntu auskommentieren.
Dann LE_MODE auf yes setzten
PRIV_KEY, SIGNED_CRT und CHAIN_FILE noch auskommentieren
# CONFIGURATION OPTIONS
UNIFI_HOSTNAME=unifi.friedlandreas.net
UNIFI_SERVICE=unifi
# Uncomment following three lines for Fedora/RedHat/CentOS
#UNIFI_DIR=/opt/UniFi
#JAVA_DIR=${UNIFI_DIR}
#KEYSTORE=${UNIFI_DIR}/data/keystore
# Uncomment following three lines for Debian/Ubuntu
UNIFI_DIR=/var/lib/unifi
JAVA_DIR=/usr/lib/unifi
KEYSTORE=${UNIFI_DIR}/keystore
# Uncomment following three lines for CloudKey
#UNIFI_DIR=/var/lib/unifi
#JAVA_DIR=/usr/lib/unifi
#KEYSTORE=${JAVA_DIR}/data/keystore
# FOR LET'S ENCRYPT SSL CERTIFICATES ONLY
# Generate your Let's Encrtypt key & cert with certbot before running this script
LE_MODE=yes
LE_LIVE_DIR=/etc/letsencrypt/live
# THE FOLLOWING OPTIONS NOT REQUIRED IF LE_MODE IS ENABLED
#PRIV_KEY=/etc/letsencrypt/live/unifi.friedlandreas.net//hostname.example.com.key
#SIGNED_CRT=/etc/ssl/certs/hostname.example.com.crt
#CHAIN_FILE=/etc/ssl/certs/startssl-chain.crt
# CONFIGURATION OPTIONS YOU PROBABLY SHOULDN'T CHANGE
ALIAS=unifi
PASSWORD=aircontrolenterprise
Jetzt noch das Script ausführbar machen
chmod a+x unifi_ssl_import.sh
und jetzt noch für das Script einen Cronjob erstellen:
Alle Vorkommen ersetzen: :%s/[Suchstring]/[Ersetzungsstring]/g
Alle Vorkommen ersetzen – mit Parameter i case-insensitive (Groß- und Kleinschreibung egal): :%s/[Suchstring]/[Ersetzungsstring]/gi
Alle Vorkommen ersetzen – mit Parameter i case-insensitive (Groß- und Kleinschreibung egal) und Parameter c für Nachfrage ob ersetzt werden soll: :%s/[Suchstring]/[Ersetzungsstring]/gic
Beispiel:
:%s/AlterServerName/NeuerServerName/gi
Hier wird der String AlterServerName durch den String NeuerServerName ersetzt – egal wie AlterServerName geschrieben ist -> also auch alterservername, ALTERSERVERNAME, etc
Achtung: Da der String hier als Regulärer Ausdruck interpretiert wird, müssen reservierte Zeichen, z.B. „.“, escaped werden, indem man ihm ein „\“ voranstellt.
Ich hatte das Problem das nach dem Update bzw. Upgrade von Nextcloud 16 auf Nextcloud 17 (über den Web-Updater) meine Nextcloud nicht mehr erreichbar war und
HTTP ERROR 500
ausgab.
Lösen konnte ich das Problem über die Shell (der Pfad ist euer Nextcloud-Verzeichnis):
Will man ein Debian 8 mit apt-get update oder apt update updaten und schlägt dies mit einer Meldung wie dieser fehl
Fehl http://ftp.debian.org jessie-backports/main amd64 Packages 404 Not Found [IP: 130.89.148.12 80] W: Fehlschlag beim Holen von http://ftp.debian.org/debian/dists/jessie-backports/main/binary-amd64/Packages 404 Not Found [IP: 130.89.148.12 80] E: Einige Indexdateien konnten nicht heruntergeladen werden. Sie wurden ignoriert oder alte an ihrer Stelle benutzt.
liegt das daran, dass Debian im März 2019 die Sourcen verschoben haben – und die alten in der sources.list nicht mehr funktionieren.
Man muss jetzt nur die sources.list Datei in /etc/apt/ auf die neuen Quellen ändern:
deb http://security.debian.org/ jessie/updates main
deb-src http://security.debian.org/ jessie/updates main
deb http://archive.debian.org/debian/ jessie-backports main
deb-src http://archive.debian.org/debian/ jessie-backports main
deb http://archive.debian.org/debian/ jessie main contrib non-free
deb-src http://archive.debian.org/debian/ jessie main contrib non-free
Und zusätzlich muss noch folgender Befehl auf der Shell ausführt werden:
echo "Acquire::Check-Valid-Until false;" | tee -a /etc/apt/apt.conf.d/10-nocheckvalid
Jetzt sollte einem gepflegten apt update && apt upgrade -y nichts mehr im Wege stehen 🙂
Ich hab ja hier beschrieben wie man mit der Powershell Base64 en- und decodiert. Unter Linux geht das natürlich auch super einfach auf der Shell mittels dem base64-Tool:
