Server Internes

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 Repositoryies 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 Packet und Konfiguratonen 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 Konfigurationfile, 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 Packete 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 siche 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.

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

Development

siehe Github README.md.

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 empfielt 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.

Weiterführendes findest du in der Github README.md.