Erstellung einer Nextcloud unter Debian 11
Die Installationsmedien für den zugrundeliegenden Linux-Server erhalten Sie hier:
Ubuntu 20.04.x LTS:
Server-Installation - SSH wird vorausgesetzt
Debian 11.x: Net ISO Installation - Standardsystemwerkzeuge u. SSH werden vorausgesetzt
Nur Debian Server:
su -
{{{ apt install -y sudo }}}
usermod -aG sudo
{{{ exit }}}
exit
Ab hier geht es wieder für beide Server-Betriebssysteme (Ubuntu und Debian) weiter:
Wechseln Sie mittels sudo zu Ihrem privilegierten Benutzer:
sudo -s
Laden Sie das Installationsskript nach /usr/local/src herunter:
**cd /usr/local/src && apt install -y bzip2 wget**
{{{ }}}
**Debian** v. 3.4.1:
{{{ wget [[https://it-services.c-rieger.de/s/TgrELJyJLYt6trk/download]] -O install.zip }}}
{{{ **Ubuntu** v. 3.4.1: }}}
wget [[https://it-services.c-rieger.de/s/r76FgAWcLN7HsM7/download]] -O install.zip
und entpacken dort das Skript:
apt install -y unzip && unzip install.zip
Markieren Sie das Skript als „ausführbar“
chmod +x install.sh
und führen es dann zur Installation aus:
./install.sh
Das Logfile finden Sie unter /usr/local/src/install.log. Sie werden im Lauf der Installation nach folgenden Daten gefragt:
**MariaDB**:
{{{ - Enter current password for root (enter for none): |ENTER| }}}
- Switch to unix_socket authentication [Y/n]: + |ENTER|
{{{ - Change the root password? [Y/n]: + |ENTER| }}}
- New password: + |ENTER|
{{{ - Re-enter new password: + |ENTER| }}}
- Remove anonymous users? [Y/n]: + |ENTER|
{{{ - Disallow root login remotely? [Y/n]: + |ENTER| }}}
- Remove test database and access to it? [Y/n]: + |ENTER|
{{{ - Reload privilege tables now? [Y/n]: + |ENTER| }}}
{{{ Nextcloud: }}}
- Enter your Nextcloud Administrator: + |ENTER|
{{{ - Enter your Nextcloud Administrator password: + |ENTER| }}}
- Enter your absolute Nextcloud datapath (/your/path): </absoluter Pfad/zum/Datenverzeichnis> + |ENTER|
{{{ }}}
**SSH**:
{{{ - Command may disrupt existing ssh connections. Proceed with operation (y|n)? + |ENTER| }}} Optional: Einrichtung von SSL über Let’s Encrypt
Bitte stellen Sie zuerst sicher, dass Ihr Server sowohl über Port 80/TCP als auch über Port 443/TCP von außen erreichbar ist.
Für die Let’s Encrypt – Zertifikatserstellung wechseln Sie in die Shell des technischen Benutzers acmeuser
su - acmeuser
und requestieren (beantragen) dann die SSL-Zertifikate. Ersetzen Sie dabei ihre.domain.de mit Ihrer „echten“ Domain :
acme.sh --issue -d **ihre.domain.de** --server letsencrypt --keylength 4096 -w /var/www/letsencrypt --key-file /etc/letsencrypt/rsa-certs/privkey.pem --ca-file /etc/letsencrypt/rsa-certs/chain.pem --cert-file /etc/letsencrypt/rsa-certs/cert.pem --fullchain-file /etc/letsencrypt/rsa-certs/fullchain.pem --reloadcmd "sudo /bin/systemctl reload nginx.service"
{{{ acme.sh issue -d ihre.domain.de server letsencrypt keylength ec-384 -w /var/www/letsencrypt key-file /etc/letsencrypt/ecc-certs/privkey.pem ca-file /etc/letsencrypt/ecc-certs/chain.pem cert-file /etc/letsencrypt/ecc-certs/cert.pem fullchain-file /etc/letsencrypt/ecc-certs/fullchain.pem reloadcmd "sudo /bin/systemctl reload nginx.service" }}}
Verlassen Sie die Shell des neuen Benutzers
exit
und und fügen die neue Domain in Ihrer Nextcloud hinzu. Ersetzen Sie ihre.domain.de mit Ihrer „echten“ Domain:
sudo -u www-data php /var/www/nextcloud/occ config:system:set trusted_domains 1 --value=**ihre.domain.de**
Setzen Sie Ihre Domain als overwrite.cli.url. Ersetzen Sie dabei ihre.domain.de mit Ihrer Domain:
sudo -u www-data php /var/www/nextcloud/occ config:system:set overwrite.cli.url --value=https://**ihre.domain.de**
Legen Sie sich dann ein Skript an, dass zukünftig die Berechtigungen überprüft und korrigiert (permissions.sh):
nano /root/permissions.sh
Kopieren Sie alle Zeilen in die Datei permissions.sh.
Passen Sie ggf. das Datenverzeichnis im Skript an, sofern Sie nicht das exemplarische /daten -Verzeichnis während der Skriptinstallation verwendet haben.
#!/bin/bash
{{{ find /var/www/ -type f -print0 | xargs -0 chmod 0640 }}}
find /var/www/ -type d -print0 | xargs -0 chmod 0750
{{{ chmod -R 775 /var/www/letsencrypt /etc/letsencrypt }}}
chown -R www-data:www-data /var/www /etc/letsencrypt
{{{ chown -R www-data:www-data **/daten** }}}
chmod 0644 /var/www/nextcloud/.htaccess
{{{ chmod 0644 /var/www/nextcloud/.user.ini }}}
exit 0
Markieren Sie das Skript als ausführbar und führen es dann direkt aus:
chmod +x /root/permissions.sh && /root/permissions.sh
Entfernen Sie Ihre bisher verwendeten Self-Signed-Zertifikate aus nginx und aktivieren Sie die neuen, vollwertigen und bereits gültigen SSL Zertifikate von Let’s Encrypt:
sed -i '/ssl-cert-snakeoil/d' /etc/nginx/conf.d/nextcloud.conf
{{{ sed -i s/#\\ssl/\\ssl/g /etc/nginx/conf.d/nextcloud.conf }}}
service nginx restart
Über einen automatisch angelegten Cronjob
crontab -l -u acmeuser
werden Ihre SSL-Zertifikate fortan regelmäßig und vollautomatisch erneuert. Bitte nehmen Sie sich etwas Zeit und überprüfen den Sicherheitsstatus Ihres Servers. Ziel sollte mind. folgendes „A+“-Ergebnis sein.
- Details
- Geschrieben von: Frank
- Kategorie: Anleitungen
Checkliste Backbone-Wartung (je Standort)
Vorbereitung
- Wartungsdokument vorbereiten (oder Vorjahr kopieren)
- Vorlagen/wartungsprotokoll.ott
- Geräte eintragen
- Zabbix: Configuration->Hosts->Host groups: "Standorte/[Standort]"
- Geräte ohne Wartungsauftrag aufführen, aber kennzeichnen
- Aktuelle Fotos der Standorte für Dokumetation machen
Updates
PTMP (über ansible)
- ansible-playbook deploy-ssh-ubnt.yml --ask-pass --limit ptmp-[standort]*ansible-playbook update-ubnt.yml --limit ptmp-[standort]
PTP (über ansible)
- ansible-playbook deploy-ssh-ubnt.yml --ask-pass --limit ptp-[standort]*ansible-playbook update-ubnt.yml --limit ptp-[standort]
Switch
Mikrotik
- über Browser aktualisieren: http://172.16.x.250/webfig/#System:Packages.Check_For_Updates
UBNT
- ???
Server (über ansible)
- Versionssprünge sollten händisch aufgelöst werden.
- sudo apt update
- sudo apt upgrade
- sudo apt dist-upgrade
- sudo apt autoremove
- sudo apt autoclean
- sudo find /etc -name '.dpkg-' -o -name '.ucf-' -o -name '*.merge-error'
- sudo systemctl reboot
- ansible-playbook local-apt.yml --limit bb[xx]
- sudo apt update
- sudo apt upgrade --without-new-pkgs
- sudo apt full-upgrade
- sudo systemctl reboot
- sudo apt --purge autoremove
- sudo apt autoclean
- ansible-playbook server-bb-default.yml --limit bb[xx]
neues Gerät im Ansible aufnehmen
- inventory.ini anpassen
- Gerätenamen an verschiedenen Stellen/Gruppen hinterlegen
- ssh-config anpassen
- einmalig ssh foo@ip machen, damit der key aufgenommen wird
- Details
- Geschrieben von: Andreas Vogel
- Kategorie: Anleitungen
<
Einführung
Immer wieder mal taucht die Frage auf, warum der Freifunk so langsam ist. Prinzipiell ist er das nicht, man kann an einem 100er DSL-Anschluß durchaus auf Downloadraten von 80 Mbps und Uploads von 20 Mbps und mehr kommen. Wenn es aber klemmt, kann das viele verschiedene Ursachen haben. In Richtung Internet laufen die Daten über etliche Stationen, z.B.:
Endgerät (PC/Smartphone/Tablet)
|
v
Freifunk-WLAN
|
v
Freifunk-Knoten (Router)
|
v
Freifunk-Mesh
|
v
Freifunk-Knoten (Router)
|
v
Tunnel (VPN) zum Gateway über...
|
v
Heimnetzwerk
|
v
DSL-Router
|
v
Provider
|
v
Internet
|
v
Gateway FFGGRZ
|
v
Tunnel zum FF Rheinland übers Internet
|
v
Gateway FF Rheinland
|
v
Internet
|
v
Ziel im Internet (z.B. Speedtest-Server)
Aus dem Internet durchlaufen die Daten den umgekehrten Weg, dabei kann auch noch ein weiteres Gateway involviert sein. An jeder einzelnen Stelle kann nun ein Engpaß auftreten, der dazu führt, daß eine der üblichen Speedtest-Seiten im Internet eine geringe Übertragungsrate anzeigt. Beispiele:
- Endgerät zu schwach oder durch eine andere laufende Anwendung ausgelastet.
- WLAN zwischen Endgerät und Freifunk-Router. Im meist verwendeten 2,4GHz-Bereich sind im Idealfall höchstens 20 Mbits/s möglich. Meist nutzen noch andere Accesspoints den gleichen Kanal, dann ist es wesentlich weniger. Zum Test kann man sich einmal direkt über den LAN-Port des Routers mit dem Freifunknetz verbinden.
- Freifunkrouter zu schwach und/oder durch andere Endgeräte ausgelastet. Ein WR841 mit dem per Default genutzten Fastd-VPN zum Gateway schafft z.B. nicht wesentlich mehr wie 10 Mbits/sec.
- Schwache Mesh-Verbindung zwischen Freifunkroutern.
- Fehlerhafte Anbindung des Freifunkrouters (fehlerhaftes Kabel, falsche Einstellungen am Switch...)
- Gateway überlastet (weil z.B. ein anderes gerade gewartet wird oder viele Nutzer hohen Traffic erzeugen). Die Daten aller angeschlossenen Knoten müssen über den Netzwerkanschluß ins Gateway gelangen, über den gleichen Anschluß dieses wieder in Richtig Internet verlassen. In der anderen Richtung (vom Internet zum Knoten) müssen die Daten auch nochmal durch diesen einen Netzwerkanschluß. Der Anschluß schafft max. 1 Gbits/sec, bei Gateway3 derzeit nur 100Mbits/sec.
- Backbone beim Freifunk Rheinland ausgelastet
- Ziel im Internet durch viele Nutzer ausgelastet
Bereits wenn einer dieser Punkte zutrifft, wirds langsam. Auf Grund dieser Vielschichtigkeit ist es den Administratoren unserer Community unmöglich, auf Fragen nach der Ursache für einen langsamen Download schnell eine eindeutige Antwort zu geben. Deswegen sollte zuerst die eigene Technik geprüft werden. Ein paar Tips dazu gibt es im folgenden.
Prüfen der WLAN-Umgebung
Dazu eignet sich eine der verschiedenen Apps, z.B. der WiFiAnalyzer für Android. Damit kann man schnell erkennen, ob der Empfang ausreicht und wieviele andere Accesspoints den Kanal mitnutzen. Einen groben Anhaltspunkt für die Belegung der für Freifunk genutzten WLAN-Kanäle gibt auch die Airtime-Grafik auf unserer Karte (nach Auswahl des gewünschten Knotens).
Prüfen des eigenen Internet-Anschlusses
Freifunk kann nie schneller wie der Internet-Anschluß sein, über welchen sich der Freifunk-Router mit dem Gateway verbindet. Deswegen wird mit einem direkt am Heimnetzwerk angeschlossenen Gerät und einer der üblichen Speedcheck-Seiten die erreichbare Geschwindigkeit geprüft.
Prüfen der Übertragungsrate zwischen Endgerät und Gateway
Zur Ermittlung der Übertragungsrate ist auf allen Gateways iperf3 installiert und läuft dort als Server auf der Freifunk-internen IPv4-Adresse und dem Standard-Port 5201. Zu dessen Nutzung muß man selbst auch iperf3 installieren. Das gibt es für alle üblichen Betriebssysteme.
Zu Messung muß man sich natürlich mit dem Freifunknetz verbinden, öffnet eine Konsole und gibt dort folg. ein:
iperf3 -4 -c gw1.ffggrzDadurch sendet man Daten in Richtung Gateway1, für die anderen Gateways kann man entsprechend gw2 oder gw3 verwenden. Sinnvoll ist es, das Gateway anzugeben, mit welchem der eigene Knoten verbunden ist (s. Freifunk-Karte). Die Ausgabe sollte dann die im folgenden Beispiel aussehen:
Connecting to host gw1.ffggrz, port 5201 [ 5] local 10.181.1.1 port 47570 connected to 10.181.0.11 port 5201 [ ID] Interval Transfer Bitrate Retr Cwnd [ 5] 0.00-1.00 sec 3.01 MBytes 25.3 Mbits/sec 46 167 KBytes [ 5] 1.00-2.00 sec 3.04 MBytes 25.5 Mbits/sec 0 194 KBytes [ 5] 2.00-3.00 sec 3.48 MBytes 29.2 Mbits/sec 0 209 KBytes [ 5] 3.00-4.00 sec 3.04 MBytes 25.5 Mbits/sec 15 153 KBytes [ 5] 4.00-5.00 sec 3.04 MBytes 25.5 Mbits/sec 0 171 KBytes [ 5] 5.00-6.00 sec 3.04 MBytes 25.5 Mbits/sec 0 180 KBytes [ 5] 6.00-7.00 sec 2.61 MBytes 21.9 Mbits/sec 4 139 KBytes [ 5] 7.00-8.00 sec 2.61 MBytes 21.9 Mbits/sec 0 165 KBytes [ 5] 8.00-9.00 sec 3.04 MBytes 25.5 Mbits/sec 0 180 KBytes [ 5] 9.00-10.00 sec 3.04 MBytes 25.5 Mbits/sec 0 185 KBytes - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate Retr [ 5] 0.00-10.00 sec 30.0 MBytes 25.2 Mbits/sec 65 sender [ 5] 0.00-10.00 sec 29.4 MBytes 24.6 Mbits/sec receiver
Entscheidend ist die Spalte "Bitrate" und die letzten beiden Zeilen mit der Zusammenfassung. Die vorletzte Zeile ist das, was der Sender (das eigene Gerät), die letzte was der Empfänger (das Gateway) "gesehen" hat. Das unterscheidet sich etwas, weil immer mal ein paar Datenpakete verlorengehen (im Beispiel 65, s. Spalte "Retr"). Wenn es nicht zuviele sind, ist das normal. Im Beispiel, an einem 100er DSL-Anschluß, sind die 25 Mbits/sec in Upload-Richtung ein guter Wert.
Um die meist interessantere Downloadrate zu messen, wird der Parameter "-R" eingefügt:
iperf3 -R -4 -c gw1.ffggrzDamit sendet Gateway1 Daten zum eigenen Endgerät, die Ausgabe entspricht dann folg. Beispiel:
Connecting to host gw1.ffggrz, port 5201 Reverse mode, remote host gw1.ffggrz is sending [ 5] local 10.181.1.1 port 47684 connected to 10.181.0.11 port 5201 [ ID] Interval Transfer Bitrate [ 5] 0.00-1.00 sec 6.77 MBytes 56.8 Mbits/sec [ 5] 1.00-2.00 sec 9.26 MBytes 77.7 Mbits/sec [ 5] 2.00-3.00 sec 8.03 MBytes 67.3 Mbits/sec [ 5] 3.00-4.00 sec 6.79 MBytes 56.9 Mbits/sec [ 5] 4.00-5.00 sec 6.30 MBytes 52.9 Mbits/sec [ 5] 5.00-6.00 sec 7.02 MBytes 58.9 Mbits/sec [ 5] 6.00-7.00 sec 6.90 MBytes 57.8 Mbits/sec [ 5] 7.00-8.00 sec 7.22 MBytes 60.6 Mbits/sec [ 5] 8.00-9.00 sec 6.91 MBytes 57.9 Mbits/sec [ 5] 9.00-10.00 sec 7.08 MBytes 59.4 Mbits/sec - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate Retr [ 5] 0.00-10.00 sec 74.7 MBytes 62.7 Mbits/sec 365 sender [ 5] 0.00-10.00 sec 72.3 MBytes 60.6 Mbits/sec receiver
Hier werden also 60 Mbits/sec erreicht. Da zum Testzeitpunkt noch 7 andere Clients mit dem Accesspoint verbunden waren, ist auch das kein schlechter Wert an einem 100er DSL-Anschluß.
Wem die Installation und Nutzung von iperf3 zu kompliziert ist, kann auch unseren internen Speedtest unter test.ffggrz nutzen. Hier kann es aber schon wieder Verfälschungen geben, da die Daten vom Gateway erst noch zum separaten Testserver geleitet werden müssen.
Beim Durchführen dieses und weiterer Tests sollte beachtet werden, daß damit die beteiligten Komponenten (Client, Router, Gateways, Internet-Anschluß) teilweise bis zur Maximal-Grenze ausgelastet werden. Bei anderen Nutzern dieser Komponenten wird das also mindestens zu Geschwindigkeitseinbußen führen. Man sollte also auch nicht zuviel und zulange testen.
Prüfen der Übertragungsrate zwischen einzelnen Freifunk-Komponenten
Das fürs Routing im Freifunk-Netz verwendete B.A.T.M.A.N. hat einen eingebauten Speedtest. Damit kann man die Datenrate zwischen einzelnen Routern und zum Gateway ermitteln. Dazu muß man sich per SSH mit seinem Freifunk-Router verbinden. Um den Durchsatz Richtung Gateway zu messen, muß man zuerst die Adresse vom Gateway ermitteln (hier werden keine IP- sondern Mac-Adressen verwendet). Das geschieht mit folgendem Kommando:
batctl gwlDadurch werden alle Gateways angezeigt, beispielsweise so:
[B.A.T.M.A.N. adv 2017.2, MainIF/MAC: primary0/3a:0c:5c:83:26:33 (bat0/f0:9f:c2:de:d0:58 BATMAN_IV)] Router ( TQ) Next Hop [outgoingIf] Bandwidth de:ad:be:60:05:00 (195) 9a:2a:d6:d6:ff:27 [ mesh-vpn]: 96.0/96.0 MBit de:ad:be:ef:03:04 (195) 9a:2a:d6:d6:ff:27 [ mesh-vpn]: 96.0/96.0 MBit * de:ad:be:ef:01:01 (255) 9a:2a:d6:d6:ff:27 [ mesh-vpn]: 96.0/96.0 MBit de:ad:be:ef:02:03 (195) 9a:2a:d6:d6:ff:27 [ mesh-vpn]: 96.0/96.0 MBit
Das verwendete Gateway ist das mit dem "*", gleich dahinter steht dessen Adresse, hier also die de:ad:be:ef:01:01. Um den Durchsatz dahin zu messen, gibt man nun folg. ein:
batctl tp de:ad:be:ef:01:01Die Ausgabe sieht wie folgt aus:
Test duration 10100ms. Sent 17471412 Bytes. Throughput: 1.65 MB/s (13.84 Mbps)
Hier wurden bei der vorgegebenen Testdauer von 10 Sekunden 17471412 Bytes übertragen, was 13.84 Mbps (also Megabits pro Sekunde) entspricht. Die Werte schwanken teilweise stark, man sollte den Test also ein paarmal wiederholen.
Bewertung der Ergebnisse
"Wer mißt, mißt Mist." Diese Weisheit sollte man immer beherzigen.Wenn z.B. 2 Nutzer an einem Freifunk-Knoten gleichzeitig einen Speedtest durchführen, muß man sich nicht wundern, daß nicht die maximal mögliche Datenrate erzielt wird. Beim Test sollten also möglichst keine anderen Nutzer mit dem Knoten verbunden sein. Auch wenn ein anderes Familienmitglied gerade einen Film streamt, wird der am selben Netz angeschlossene Freifunk-Router nicht die volle Bandbreite nutzen können. Auch die Tests zu oder über unsere Gateways können zu unterschiedlichen Ergebnissen führen, je nachden, wieviel Traffic andere Nutzer dort gerade erzeugen. Da kann es sinnvoll sein, die Tests z.B. zu einer anderen Tageszeit zu wiederholen.
Auch andere Dinge können das Meßergebnis beeinflussen. Eine goldene Regel besagt z.B., daß man dür Prüfung eines Gerätes niemals dieses selbst zum Messen nutzen sollte. Das wäre zum Beispiel bei der Prüfung der Übertragungsrate zwischen einzelnen Freifunk-Komponenten mittels "batctl tp" (s.o.) der Fall. Gerade auf leistungsschwachen Knoten kann das Erzeugen des Test-Traffics soviel Prozessorlast erzeugen, daß diese für die eigentliche Übertragung fehlt. Dann sieht es so aus, als würde wesentlich weniger Bandbreite zur Verfügung stehen, was im realen Betrieb gar nicht der Fall ist.
Man sollte also immer überlegen, wie die Meßergebnisse zustandegekommen sind.
Fehlermeldungen
Unsere Administratoren sind natürlich interessiert daran, bei möglichen Fehlern über das Forum oder das Ticketsystem informiert zu werden. Um dabei aber zu vermeiden, Fehler zu melden, deren Ursache im Netz des Nutzers, dessen Internet-Anbindung oder beim Endgerät zu suchen sind, sollten nach Möglichkeit die oben beschriebenen Tests ausgeführt und deren Ergebnis in die Fehlermeldung aufgenommen werden. Natürlich wird auch bei diesen Problemen geholfen, es ist aber sehr nützlich, wenn im Freifunknetz nicht erst nach garnicht vorhandenen Fehlern gesucht werden muß.
Folgende Angaben sind bei Geschwindigkeitsproblemem hilfreich:
- Name des betroffenen Knotens und dessen Typ
- Wie ist der Knoten mit dem Gateway verbunden (direkt übers per Internet/VPN oder Mesh zu anderem Knoten)
- Wenn bekannt: welches VPN wird verwendet (Fastd oder Tunneldigger)
- genutzter WLAN-Bereich (2,4 oder 5 GHz), falls nicht per LAN mit Knoten verbunden
- genutztes Gateway (s. Karte oder "batctl gwl")
- iperf3-Werte zum Gateway
- Speedtest-Ergebnisse aus dem Heimnetz (wo der Freifunk-Router angeschlossen ist)
Wurden am Freifunk-Router bereits intern (z.B. per SSH) Parameter geändert, sollten diese Änderungen vor einer evtl. Fehlermeldung wieder rückgängig gemacht an nochmal getestet werden. Die meisten Änderungen, die über das hinausgehen, was per Browser im Config-Mode geändert werden kann, bewirken eher das Gegenteil.
Abschließend sollte auch die eigene Erwartungshaltung überprüft werden. Ziel des Freifunks ist es definitiv nicht, z.B. für Videostreaming oder Downloads eine hohe Bandbreite zur Verfügung zu stellen. Es geht eher darum, an möglichst vielen Stellen überhaupt ein frei nutzbares Netz zuhaben. Da geht es eher um Mailempfang, Chatten, Abruf von Webseiten u.v.a.m. Dafür sollte i.A. auch ein Durchsatz von z.B. 10 Mbits/sec genügen.
- Details
- Geschrieben von: Jörg
- Kategorie: Anleitungen
Die Geräte starten mit einer Werks-IP (192.168.88.1).
Falls die Konfiguration per Netzwerk vorgenommen werden soll, müssen also verschiedene Punkte beachtet werden.
- PC in das passende Netzwerk bringen
- keine Konfigurationseinstellungen kopiert übernehmen, die die eigene Verbindung abbrechen lassen
Konfiguration per Calc-Macro-Konfigurator
- VLAN-IDs eintragen (Spalte C)
- Interface-Beschriftungen eintragen (Zeile 8)
- Matrix ausfüllen (U-untagged, T-tagged)
- LACP/Channel werden nicht automatisch erzeugt
- je nach Hersteller/Modell haben die Schnittstellen unterschiedliche Präfixe (z.B. "ether" oder "0/"), Zeile 6 ggf. anpassen
- Konfiguration durch Klick auf den Herstellernamen (aktuell nur Mikrotik und Ubiquiti) erstellen lassen
Bei Zugriff per Netzwerk sollten die Einstellung für die eigene Verbindung (aktuell genutzte Schnittstelle) ausgespart werden. Dies betrifft auch bridge-Einstellungen und die Änderung des Managementzugangs.
Nacharbeiten
- Standard-bridge löschen
- Bridgeports ohne (Standard) bridge löschen
- (R)STP ggf. je bridge aktivieren
- ggf. bond0 anlegen
- ggf. DHCP-Server aktivieren
- Details
- Geschrieben von: Matthias Drobny
- Kategorie: Anleitungen
Zu einer sinnvollen Bewertung von Knoten- /Backbonestandorten sollten Fotos gemacht werden.
Dabei ist meist auch ein Rundumbild eine gute Entscheidung um im Nachgang relativ einfach die Richtungen und Sichtbarkeiten von möglichen Gegenstellen feststellen zu können.
Folgende Schritte sollten beachtet werden:
- Beim Fotografieren
- für ausreichende Überlappung der Bilder sorgen
- am besten ein Stativ verwenden
- die Drehrichtung zwischen den Panoramen beibehalten (der erleichtert die Sortierung am Nachgang)
- nichts am Zoom ändern
- automatischen Weißabgleich abschalten
- Bei der Nachbearbeitung
- Müssen Fotos aus verschiedenen Quellen (Kameras) in eine Sortierung eingepasst werden, dann stimmen häufig die Zeiten (in den EXIF-Daten) nicht überein. (Das hat erstmal nichts mit Panoramas zu tun.)
Mit diesem Befehl kann unter Linux die in den EXIFs hinterlegte Zeit geändert werden. (Hier: +55 Minuten für alle Bilddateien, die in und unter dem aktuellen Verzeichnis liegen und "DSC_" im Namen haben.)
exiftool muss dafür vorhanden sein
Anschließend können die Bilder anhand ihres Zeitstempels umbenannt werden um die verschiedenen Präfixe der Kameras ("IMG", "DSC", ...) vernachlässigen zu können.
find . -iname "DSC_*" -exec exiftool -d %Y%m%d-%H%M%S%%-c-%%f.%%e "-filenameHiermit werden alle Bilder unterhalb des aktuellen Ordners auf das Originaldatum umbenannt.
- Beim Zusammenfügen
- Es gibt verschiedene Softwarelösungen, mit denen die Bilder zusammengefügt (stitching) werden können.
- Als Empfehlung macht Hugin Sinn, da der eingebaute Assistent ziemlich gute Arbeit leistet.
- Hugin starten (Assistent startet automatisch)
- "1. Bilder laden"
- Ggf. "Ansicht -> Panorama Editor" um Kontrollpunkte manuell zu setzen
- "2. Ausrichten": Hier werden Kontrollpunkte automatisch anhand des Bildmaterials erstellt.
- "3. Panorama erstellen"
Für Anfänger macht Sinn, bei der Erstellung erst einmal auf den Assistenten zu vertrauen und nicht sofort über den Panorama Editor alles selbst einzustellen.
- Details
- Geschrieben von: Matthias Drobny
- Kategorie: Anleitungen