Server Internes: Unterschied zwischen den Versionen

Aus Freifunk Dresden - Anwender-Wiki
Zur Navigation springen Zur Suche springen
Zeile 227: Zeile 227:
 
Es empfiehlt sich dringend für andere Communities, dieses Repository zu forken, da hier generelle Umstellungen zusammen mit der passenden Firmware für Dresdener Anforderungen erfolgen.<br/>
 
Es empfiehlt sich dringend für andere Communities, dieses Repository zu forken, da hier generelle Umstellungen zusammen mit der passenden Firmware für Dresdener Anforderungen erfolgen.<br/>
 
Communities sollten dann auf das geforkte Repository (gilt auch für das "[https://github.com/Freifunk-Dresden/firmware-freifunk-dresden firmware]" Repository) aufbauen. Jede Community trägt die alleinige Verantwortung und Kontrolle über ihr Netz und sollte eigene Erfahrene Leute/Admins bereitstellen. Hilfe von Dresden ist aber jederzeit möglich, aber Administrative Aufgaben oder Garantien werden nicht übernommen, da das einfach den organisatorischen Aufwand sprengt.<br/>
 
Communities sollten dann auf das geforkte Repository (gilt auch für das "[https://github.com/Freifunk-Dresden/firmware-freifunk-dresden firmware]" Repository) aufbauen. Jede Community trägt die alleinige Verantwortung und Kontrolle über ihr Netz und sollte eigene Erfahrene Leute/Admins bereitstellen. Hilfe von Dresden ist aber jederzeit möglich, aber Administrative Aufgaben oder Garantien werden nicht übernommen, da das einfach den organisatorischen Aufwand sprengt.<br/>
 +
 +
Im moment gibt es keinen Schutz, dass Routerfirmware einer Communitiy sich mit Servern oder Routern anderer Communities verbinden. Es ist ''Fatal'', wenn sich die Netze wegen gleicher WLAN BSSID oder via Backbone verbinden. Da überall das gleiche Routingprotokoll verwendet wird, würden Geräte von verschiedenen Communities miteinander reden können und das Netz würde gigantisch groß und die Router überlasten.
 +
 +
Bitte einhalten:
 +
* Ändern der BSSID auf eine eigene!
 +
* Keine Verwendung von Registratoren anderen Communities (Webserverdienst zum Verteilen von Knotennummern)
 +
* Kein Aufbau von Brücken zwischen Routern/Vservern verschiedener Communities über Backboneverbindungen. (das wird in Zukunft noch unterbunden, dazu ist aber eine Änderung am Routingprotokoll notwendig). Verbindungen von Communities dürfen nur über das ICVPN erfolgen.
 +
* <code>/usr/local/bin/ddmesh-ipcalc.sh</code> muss angepasst werden!

Version vom 3. November 2019, 14:41 Uhr

Allgemeines

Projektseite

Releases - latest Stable Release - CHANGELOG - Issues

Debian Security Informations - Salt Dokumentation

Git-Repository

Die aktuellste ffdd-server Version sowie Release Informationen findest du direkt auf der Projektseite.

 https://github.com/Freifunk-Dresden/ffdd-server

Bereitstellung / Initialisierung

Die Initialisierung des Gateway-Server erfolgt über das init_server.sh Script. Dieses stellt sicher dass der Server auch den Grundlegenden Anforderungen entspricht und die Basis Konfiguration für Salt vorhanden ist.

Wichtige Punkte sind hier:

  • Konfiguration:
    • /etc/nvram.conf (Enthält alle Gateway Spezifische Informationen)
    • /etc/salt/minion.d/freifunk-masterless.conf (Definiert das Arbeitsverzeichnis für Salt - /srv/ffdd-server/salt/freifunk/base/ )
  • Pakete:
    • git - für die Bereitstellung und Aktualisierung des Repositories
    • salt-minion (Salt) - Automatisierung 'Masterless-Orchestration-Management'
  • Bereitstellung des Repositories unter /srv/ffdd-server/

Im init_server.sh Script wird der salt-call state.highstate --local Befehl aufgerufen. Damit übernimmt Salt nun die weitere Initialisierung des Gateway-Server und wird die von uns definierten Pakete und Konfiguration wie gewünscht auf das System spielen.

Betrieb / Operating

Salt Basics

Salt benötigt seine Konfiguration ( /etc/salt/minion.d/freifunk-masterless.conf )

file_client: local
file_roots:
  base:
    - /srv/ffdd-server/salt/freifunk/base

und das Arbeitsverzeichnis ( /srv/ffdd-server/salt/freifunk/base/ ) welches einen "Ablaufplan" die top.sls bereitstellt.

Alle hier definierten Aufgaben bekommen je nach Umfang und Komplexität im Arbeitsverzeichnis entweder:

eine Konfigurationsdatei ( ../freifunk/base/AUFGABE.sls )
oder
einen Unterordner ( ..freifunk/base/AUFGABE/ ) welcher eine init.sls enthält.

Des weiteren gibt es noch ein Konfigurationsfile, die config.jinja, welche dynamische Variablen enthält. Diese Variablen können in den einzelnen "Aufgaben-Scripten" einfach eingebunden und genutzt werden.

Salt - Aufgaben (top.sls)

Über SLS-Dateien (Salt State), die im YAML-Format verfasst werden, legen wir die Konfiguration, zu installierende Pakete und einiges mehr für FFDD-Gateway-Server fest.

apt

Das Kommandline Interface für die Paketverwaltung. Hier werden die aktuellen 'source.list' für die Paketverwaltung hinterlegt.
Weiterhin definieren wir in der 'apt.conf.d' dass einmal am Tag ein Packagelist-Update sowie ein Security-Update gemacht werden soll.
Sollten Updates einen Neustartet benötigen so wird dieser um 4:30 Uhr (Serverzeit) durchgeführt.

Ebenso hinterlegen wir einen Cronjob der prüft ob sich eine alte Kernel-Version auf dem Server befindet welche entfernt werden kann.

remove_pkg

Entfernt alle überflüssigen Pakete welche die Funktionalität des Servers einschränken könnten.

cleanup_old_env

'cleanup_old_env' wird für die Bereinigung alter und Überflüssiger Konfigurations-Versionen genutzt.

install_pkg

Installiert alle für den Server nötigen Pakete welche keine zusätzliche Konfiguration benötigen.

tools

Stellt Programme und Verknüpfungen als "Helferlein" für die Unterstützung des Administrators bereit.

root

Hinterlegt für den User 'root' eine .bashrc Konfiguration für die default shell: bash.
In dieser werden unter anderem aliases (Kürzel) bereitgestellt Kommandos abzukürzen.

Es gibt die Möglichkeit auch eigene aliases in der /root/.bash_user_aliases zu definieren. Diese wird in /root/.bash_aliases eingebunden und automatisch mitgeladen.

users

Stellt sicher das alle Benutzer für den Betrieb mit den richtigen Berechtigungen vorhanden sind.

bash

Hinterlegt die Standart Konfiguration für die default Shell "bash".

inputrc

Hinterlegt die Standart Konfiguration für das Console-Verhalten.

locales

Konfiguriert die Ausgabe-Sprache des Servers.

timezone

Konfiguriert die Zeitzone nach der die Uhr des Servers gestellt wird.

ntp

Stellt sicher dass die Serverzeit immer aktuell ist.

kernel

kernel.sysctl

systemd

sudo

rsyslog

logrotate

cron

devel

bmxd

fastd

salt-minion

ddmesh

nvram

Die /etc/nvram.conf enthält alle Gateway Spezifische Informationen.

nvram Konfigurtations Optionen

Hier ist eine nvram.conf Beispiel mit allen verfügbaren Optionen:

# install_dir !Please do not touch!
install_dir=/srv/ffdd-server

# set autoupdate (0=off 1=on)
autoupdate=1

# Git-Branch
branch=T_RELEASE_latest

# Register key must be uniq. See http://wiki.freifunk-dresden.de/index.php/Technische_Information#Berechnung_IP_Adressen
ddmesh_node=
ddmesh_registerkey=

# If set to 1, vserver will not announce itself as gateway. normally you do not need to change this.
ddmesh_disable_gateway=0

# used by webpage and /etc/issue.net
servername=VPN Server <number>

#vserver network interface; this depends on vserver provider (hoster)
ifname=eth0

# this is the secret key which is used to decrypt secured backbone connection
# the corresponding public key should be given to the peers, so those can encrpyt/connect to this server
# To generate the keys: /etc/init.d/S53backbone-fastd genkey
fastd_secret=
fastd_public=

# to accept all in comming connection, set this to 0 or remove this line.
# When set to 1, only already known connections are accepted. this may be used
# to prevent overloading a server.
fastd_restrict=0

# SSH Password-Authentification
# To disable tunneled clear text passwords (0=off 1=on)
ssh_pwauth=1

# BMXD
#bmxd_prefered_gateway=

# gps coordinates. see /var/www/sysinfo.json
# this functionality is not part of Basic Vserver installation, as this service should only run on one or an backup server.
gps_latitude=51.033865
gps_longitude=13.653252
gps_altitude=0
city=Dresden

contact_name=
contact_location=your Hosting Provider
contact_email=
contact_note=VPN X

iproute2

network

iptables

conntrack

fail2ban

ssh

openvpn

wireguard

bind

iperf3

apache2

php

letsencrypt

monitorix

vnstat

Autoupdate

Bei jeder Durchführung des salt Befehls wird überprüft ob das locale ffdd-server Repository unter /srv/ffdd-server auf dem aktuellsten Stand ist. Dies gewährleistet das Änderungen sowie Bugfixes aber auch Neuerungen schnellst möglich zur Verfügung gestellt werden können.

Manuell Update

Es gibt jederzeit die Möglichkeit das Autoupdate abzuschalten. Dazu muss dieses lediglich über das folgende Kommando in der /etc/nvram.conf deaktiviert werden:
nvram set autoupdate 0


Ein manuelles Update durchzuführen:

cd /srv/ffdd-server
git stash
git checkout $(nvram get branch)
git pull -f origin $(nvram get branch)
salt-call state.highstate --local -l error

Fehlerhaftes Repository

Sollte salt Probleme jeglicher Art mit dem 'ffdd-server' repo haben dann ist der einfachste Weg dieses neu zu erstellen und salt erneut auf zu rufen:

cd /srv/ ; rm -rf /srv/ffdd-server
git clone https://github.com/Freifunk-Dresden/ffdd-server/ /srv/ffdd-server
cd /srv/ffdd-server/ ; git checkout T_RELEASE_latest
salt-call state.highstate --local -l error

Development

Um eine andere Release-Version zu benutzen ist ein notwendig in der /etc/nvram.conf die Option "branch=" anzupassen.

Default (Stable):

branch=T_RELEASE_latest

Development:

branch=master

DEV init_server.sh - Installation

apt install -y git
git clone https://github.com/Freifunk-Dresden/ffdd-server.git /srv/ffdd-server
cd /srv/ffdd-server

# master branch
./init_server.sh dev
# or
./init_server.sh dev <branch/tag>

Wichig für Communitiy Forks

HINWEIS:
Der FFDD-Server ist auf Freifunk Dresden zugeschnitten. Soll dieses als Basis für andere Freifunk Communities verwendet werden, müssen Anpassungen gemacht werden. Bitte ein Issue im Github erstellen.

Es empfiehlt sich dringend für andere Communities, dieses Repository zu forken, da hier generelle Umstellungen zusammen mit der passenden Firmware für Dresdener Anforderungen erfolgen.
Communities sollten dann auf das geforkte Repository (gilt auch für das "firmware" Repository) aufbauen. Jede Community trägt die alleinige Verantwortung und Kontrolle über ihr Netz und sollte eigene Erfahrene Leute/Admins bereitstellen. Hilfe von Dresden ist aber jederzeit möglich, aber Administrative Aufgaben oder Garantien werden nicht übernommen, da das einfach den organisatorischen Aufwand sprengt.

Im moment gibt es keinen Schutz, dass Routerfirmware einer Communitiy sich mit Servern oder Routern anderer Communities verbinden. Es ist Fatal, wenn sich die Netze wegen gleicher WLAN BSSID oder via Backbone verbinden. Da überall das gleiche Routingprotokoll verwendet wird, würden Geräte von verschiedenen Communities miteinander reden können und das Netz würde gigantisch groß und die Router überlasten.

Bitte einhalten:

  • Ändern der BSSID auf eine eigene!
  • Keine Verwendung von Registratoren anderen Communities (Webserverdienst zum Verteilen von Knotennummern)
  • Kein Aufbau von Brücken zwischen Routern/Vservern verschiedener Communities über Backboneverbindungen. (das wird in Zukunft noch unterbunden, dazu ist aber eine Änderung am Routingprotokoll notwendig). Verbindungen von Communities dürfen nur über das ICVPN erfolgen.
  • /usr/local/bin/ddmesh-ipcalc.sh muss angepasst werden!