Server Installation

Aus Opennet
Wechseln zu: Navigation, Suche

Inhaltsverzeichnis

Basisinstallation Hardwareserver

Allgemeines zur Grundinstallation siehe Server Installation/DELL R330 (Stand 2017 Erneuerung mit DELL R330).

Basisinstallation Virtuelle Server

Zum Anlegen von virtuellen Hosts auf Virtualisierungsservern von Opennet genügen folgende Schritte (jeweils auf dem ausgewählten Virtualisierungsserver auszuführen):

  1. Opennet Mesh IP unter Server reservieren, Dokuseite Server anlegen
  2. per vhost-admin.sh .. Server erzeugen, siehe Server Installation/vhost-admin
  3. virsh start NAME
  4. virsh autostart NAME
  5. SSH-Schlüssel in den root-Account importieren:
    1. ssh NAME
    2. deinen ssh-Schlüssel in die ~/.ssh/authorized_keys eintragen
  6. den DNS-Namen eintragen
  7. ansible auf den Server anwenden:
    1. Hostdatei in host_vars/NAME im ansible-Verzeichnis anlegen
    2. Hostnamen in hosts-Datei im ansible-Verzeichnis eintragen
    3. ansible-playbook playbook-servers.yml --limit=NAME.on
  8. Monitoring (siehe Opennet munin) und Backup (siehe Opennet ansible) einrichten

Konfiguration

Ansible

Alle neuen Server werden per Konfigurationsautomatisierung installiert und verwaltet.

Siehe Server Installation/Ansible.

OLSRd v1

  • OLSR /etc/olsrd.conf, Defaults mit:
UseHysteresis       no
LinkQualityLevel    2
Interface "eth1"    { <defaults> }
Hna4
{
 # ipkg repositories
 195.56.146.238	255.255.255.255
 212.91.225.42	255.255.255.255
 # downloads.openwrt.org
 78.24.191.177   255.255.255.255
}
  • WAN-Routing /etc/network/ip-up.d/gatewaysetup.sh (Kopie besorgen)

IPv6 Miredo

Sollte kein IPv6 nativ oder via Tunnel bereit stehen, kann über Miredo (freie Toredo Implementierung) eine externe IPv6 Erreichbarkeit hergestellt werden. Gleichzeit kein DNS Update (dynamic dns) erfolgen. Details siehe Server Installation/miredo.

SSH-Server

  • ggf. neue Schlüssel erstellen in /etc/ssh/
    • RSA-Host-Key per ssh-keygen -b 2048 -t rsa -f ssh_host_rsa_key
    • DSA-Host-Key per ssh-keygen -b 2048 -t dsa -f ssh_host_dsa_key
  • Einige änderungen in /etc/ssh/sshd_config
PermitRootLogin without-password
#RSAAuthentication yes
#PasswordAuthentication no
  • auf Opennet Servern ist stets molly-guard installiert

OpenVPN

Siehe Server Installation/OpenVPN.

Nameserver

Siehe Server Installation/BIND.

Webserver

Siehe Server Installation/Apache und Server Installation/PHP

Timeserver

  • ntp (Server) via apt installieren

MTA (Mail Transfer)

Siehe Server Installation/Postfix.

IMAP (Mail Server)

Siehe Server Installation/Cyrus.

Policy Routing

Für Server wird inzwischen Policy Routing verwendet, um die lokalen Routen (z.B. zum Default-GW) von den Opennet-internen OLSR Routen zu trennen.

  • Paket iproute installieren
  • /etc/iproute2/rt_tables ergänzen:
250     hardroutes
  • /etc/network/if-up.d/policy_routing.sh erstellen, ggf. Interface anpassen
#!/bin/sh
if [ $IFACE = 'eth0' ] ; then
       # leave those to olsr
       ip route add throw 192.168.0.0/16 table hardroutes
       ip route add throw 10.0.0.0/8 table hardroutes
       # everything else, send through the gateway to the rest of the world
       ip route add 0.0.0.0/0 via $IF_GATEWAY table hardroutes
       ip rule add table hardroutes pref 10
fi
  • bei User-GW Server in /etc/network/interfaces ergänzen:
auto lo:0
iface lo:0 inet static
       address 192.168.0.247
       netmask 255.255.255.255

VPN-Status

RAID u. Partitionierung

Siehe Server Installation/RAID.

Dnsmasq

Falls die WAN-IP eines Servers via DHCP konfiguriert wird (z.B. Server/ryoko), dann kann eine lokale dnsmasq-Installation die Domain-basierte Namensauflösung sicherstellen:

apt install dnsmasq resolvconf

Folgende Konfigurationsdatei für dnsmasq ist anzulegen (/etc/dnsmasq.d/opennet.conf):

# Opennet-Nameservice
server=/on/192.168.0.246
server=/on/192.168.0.247
server=/on/192.168.0.248
rev-server=192.168.0.0/24,192.168.0.246
rev-server=192.168.0.0/24,192.168.0.247
rev-server=192.168.0.0/24,192.168.0.248

Der DHCP-Client schreibt seine Upstream-DNS-Information nun in /var/run/dnsmasq/resolv.conf, welche von dnsmasq verwendet wird.

Virtualisierung

Bezüglich KVM siehe Server Installation/KVM und Server Installation/vhost-admin.

Bezüglich UML siehe Server Installation/UML.

Dienste

OLSRd v1

Siehe https://github.com/opennet-initiative/build-olsrd

OLSRd v2

Build Debian 11 package (via Docker)

Siehe https://github.com/opennet-initiative/build-oonf

Build Debian 9 package (via VM)

If you want to have any easy way to build olsrd2 for debian 9 then do the following steps.

  apt install git gcc build-essential autoconf automake doxygen pkg-config libnl-genl-3-dev devscripts
  • configure git user data else one of the next steps will fail
   git config --global user.email "username@opennet-initiative.de"
   git config --global user.name "my username"
  • now do all the steps for compiling:
git clone https://github.com/OLSR/OONF.git
cd OONF/build/
#less ../BUILDING 
cmake ..
make
cd ../files/
./create_debian_package.sh 
ls ..

ACPI

  • alle Opennet Server haben einen acpid Dienst, so ist es möglich per Taster oder KVM den Server ein Signal zum herunterfahren zu senden
  • das parallel häufig mitinstallierte dbus sowie consolekit und policykit ist nicht notwendig, kann deinstalliert werden

Ferm (Firewall)

Siehe Server Installation/ferm.

Trac (Projektmanagement)

Siehe Server Installation/trac.

Gitolite (Git Server)

Siehe Server Installation/gitolite.

MediaWiki

Siehe Server Installation/MediaWiki.

Postgresql

  • Installation per APT
  • bei Bedarf Zugriffe erweitern in /etc/postgresql/<version>/main/pg_hba.conf
# allow other connections to DB
# added mathias mahnke 2012-05-12
#
# "local" is for Unix domain socket connections only
local   all         all                               ident
# IPv4 local connections:
host    all         all         127.0.0.1/32          md5
# IPv6 local connections:
host    all         all         ::1/128               md5
  • nach einem Debian od. Postgres Major Release Wechsel muessen die DBs manuell migriert werden (Versionen anpassen):
pg_dropcluster 9.1 main --stop
/etc/init.d/postgresql restart
pg_upgradecluster 8.4 main
diff -u 8.4/main/pg_hba.conf 9.1/main/pg_hba.conf
.. Rechte in /etc/postgresql/<version>/main/pg_hba.conf pruefen ..
.. Anwendung pruefen, wenn okay, fortfahren ..
pg_dropcluster 8.4 main
apt-get remove postgresql-8.4 postgresql-client-8.4
  • hierbei wurde zunächst die Default DB gelöscht und dann per Migr neu angelegt mit den Daten der urspr. DB

IRC

Siehe Server Installation/IRC.

Gallery3

  • Installation oder Upgrade durch Download Archives von galleryproject.org
  • bei Upgrade in neuen Unterordner ablegen
  • entpacken und ggf. ../var/ übernehmen
  • alte Installation umbenennen und neue auf alten Namen anpassen
  • .htaccess von alter Installation auf neue übertragen
  • http://<server>/<installation>/upgrader aufrufen
  • Modul "randimg" hinzufügen, http://codex.galleryproject.org/Gallery3:Modules:randimg

Mailman

Siehe Server Installation/Mailman.

Opennet CA

Siehe Server Installation/Opennet CA. Basiert auf OpenSSL.

Opennet Mitgliedsantrag

Siehe Server Installation/Opennet Mitgliedsantrag.

Subversion

Siehe Server Installation/Subversion.

Roundcube (Webmail)

Siehe Server Installation/Roundcube.

Websieve (Mailmanagement)

Siehe Server Installation/Websieve.

SSL Zertifikate (Let's Encrypt)

Siehe Server Installation/Let's Encrypt.

Apt Repository

Siehe Server Installation/Apt Repository (Debian).

Wireguard Server

Siehe Server Installation/Wireguard.

Hugo Static Webpage

Siehe Server Installation/hugo.

Buildbot (Opennet DEV)

Siehe Server Installation/buildbot.

Monitoring

apticron

Derzeit nicht verwendet, liefert zu häufig Fehler.

  • prüft den Update Status des Debian OS
  • Default-Installation ausreichend, liefert Änderungen per Mail an root
  • werden durch postfix dann automatisch an das ONI-NOC gesendert

apt-listchanges

  • zeigt eine Zusammenfassung des Paket Changelogs bei der Instalation
  • Versand parallel an Opennet NOC (via /etc/aliases - "root : noc@....")
  • Installation per apt-get install apt-listchanges, keine weitere Konfiguration notwendig

munin

Siehe Server Installation/munin.

monit

  • Debian Default-Installation ausführen und Opennet Config-File unter /etc/monit/conf.d/opennet ablegen
  • Dienst in /etc/default/monit aktivieren
  • Check auf Default-GW (IP) und PID-Files (Pfade) prüfen
  • überwacht dann dauerhaft Prozesse und startet diese ggf. neu
  • Zugriff per https://<host>:444 und Username/Passwort (siehe Config-File)
  • PEM File (Key + Cert) in /etc/ssl/private/<server-cert_year.pem> samt Symlink (<server-cert.pem>) ablegen + absichern (chmod go-r *.pem)
  • DH Paramter zum PEM File hinzufügen: openssl gendh 2048 >> /etc/ssl/private/<server-cert.pem>

vnstat

  • vnstat installieren: apt-get install vnstat; vnstat -u -i <wan-interface>
  • wird regelmässig durch den cron gestartet
  • Werte können an der Console abgefragt werden, z.B. Monatswerte per vnstat -m

logcheck

  • derzeit nicht im Einsatz auf Opennet Servern!
  • prüft Logdateien auf Anomalien und sendet dieses per E-Mail
  • Installation per apt-get install logcheck und Konfiguration von /etc/logcheck/logcheck.conf:
FQDN=0
MAILASATTACH=0
REPORTLEVEL="server"
SENDMAILTO="noc@opennet-initiative.de"
TMP="/tmp"
  • Ausnahmen bitte in /etc/logcheck/ignore.d.server/opennet ablegen

Nagios

Siehe Server Installation/Nagios.

changetrack

Siehe Server Installation/changetrack.

apt-dater

  • zentrale Überwachung von ausstehende Updates via apt-dater
  • hierzu muss auf jedem Server der Hostsupport via apt-dater-host installiert sein
  • Zugriff dann per SSH Key vom eigenen Client PC und installiertem apt-dater
  • Installationslogs entstehen wie üblich unter /var/log/apt/

SmokePing

Siehe Opennet SmokePing

Backup

Rsync

  • die meisten Server werden zu Server/akito per rsync gesichert
  • hierzu wird folgendes Script (/usr/local/sbin/backup.sh) als Grundgerüst je Server verwendet (hier heartofgold als Beispiel):
#!/bin/bash
FORMAT='%H:%M:%S %d.%m.%Y'; 
LOGFILE=/var/log/backup.log
renice 19 -p $$ >/dev/null
ionice -c 3 -p $$
echo "$(date +"$FORMAT") Start Backup: hog" >>  $LOGFILE
rsync -azx --numeric-ids --delete --bwlimit 300 --exclude-from /tank/exclude/ALL.txt 
 \ --exclude-from /tank/exclude/heartofgold.txt hog.on-i.de:/ /tank/hog/
echo "$(date +"$FORMAT") Start Backup: fertig" >>  $LOGFILE
  • neue Server dort entsprechend ergänzen

Tartarus

  • externes Backup der Server, wird für Server bei Hetzner verwendet (Hetzner Backup Service your-server.de)
  • Zugangsdaten im Conf-File hinterlegen und Start via /etc/crontab
15  4   2-31 * * root   /usr/sbin/tartarus -i /etc/tartarus/www.conf >> /var/log/tartarus.log 2>&1
15  4   1 * *   root    /usr/sbin/tartarus /etc/tartarus/www.conf >> /var/log/tartarus.log 2>&1

Karten-Software

Die Opennet-Karten basieren auf den Link Quality Daten die OLSR bereit stellt. Ein PHP Script bereitet diese Daten auf und legt sie auf dem Webserver in einem Textfile ab. Es gibt die Übersichtskarten und die AP-Positionskarten.

Übersichtskarten

Die Übersichtskarten werden über ein iFrame und der URL wiki.opennet-initiative.de/osm.php?lat=54.085&lng=12.12&zoom=14&maptype=gmap in Wiki-Seiten eingebunden. Statt dem Maptype gmap kann man auch mapnik verwenden. Mapnik Karten basieren auf dem Kartendaten von Openstreetmap.

AP-Positionskarten

Durch das Wiki-Plugin OnApPos lassen sich Karten erzeugen die einen AP und dessen Nachbarn darstellt. Um z.B. eine Karte für AP100 und dessen Nachbarn zu erzeugen würde man folgendes einfügen:

<OnApPos>100</OnApPos>

Damit die Karte passend am rechten Rand positioniert wird kann man folgende Vorlage verwenden:

{{Accesspoint Kartenposition|ap=100}}

PHP Link Quality Script

Wir befinden uns auf dem Webserver. Über ein Cron Script (/usr/local/sbin/get_topo) werden alle 60 Sekunden per OLSR-TXT Plugin die Topo und HNA Informationen ausgelesen und in Text Dateien (/var/www/olsrtopo/hna|topo) geschrieben. Diese werden anschließend über das PHP Script /var/www/olsrtopo/engine.php ausgewertet. Das Ergebnis ist die Datei /var/www/olsrtopo/topo_output.csv die als Grundlage für die Karten-Scripte dient.

Das Script engine.php führt folgende Aktionen aus.

  • HNA's aus /var/www/olsrtopo/hna einlesen.
  • AP Liste im Wiki Parsen und Koordinaten sammeln.
  • Topo aus /var/www/olsrtopo/topo einlesen.
  • Netz Qualität der einzelnen AP's berechnen. Dabei wird von den AP's ausgegangen die direkten Kontakt mit einem Gateway haben das HNA's ausgibt. Von hier werden absteigend die Links verfolgt. Die LQ eines AP's ist die LQ des schlechtesten Link zum nächsten Gateway.
  • Liste mit Links zwischen den AP's ausgeben.
  • Liste mit AP's ausgeben.
  • Die Daten landen in topo_output.csv.
  • Daten werden ein mal pro Minute aktualisiert.

Python Link Quality Script

Das Python Script (von sh01) läuft auf Opennet_Server/heartofgold und verwendet ein spezielles OLSR Plugin um an die LQ Daten zu kommen. Die Daten landen auf Opennet_Server/heartofgold in /var/www/htdocs/topology/olsr/alfredi_output.csv. Das passiert alle 5 Minuten durch einen Cronjob.

Auf www.on-i.de läd ein weiterer Cronjob /usr/local/sbin/olsrtopoloader alle 5 Minuten die csv-Datei auf den Webserver nach /var/www/olsrtopo/alfredi_output_old.csv. Durch zwei Mediawiki Erweiterungen können die Informationen nun im Wiki angezeigt werden. Diese Daten werden aktuell nicht verwenden. Zum Vergeichen der Karten kann man alfredi_output_old.csv nach topo_output.csv kopieren.

OpenLayers Karte

  • siehe Geronimo (früher Openlayers)
  • aufgeteilt in Programmteil (nicht öffentlich, /var/www/map/) und Webanteil (öffentlich, /var/www/htdocs/map/)
  • Triggern von www.opennet-initiative.de/api/ auf /var/www/map/src/geronimoCGI.py mittels WSGI
  • Python Lib "wikitools" notwendig - http://code.google.com/p/python-wikitools/
  • Python Lib geojson und cherrypy notwendig - Installation via pip install geojson cherrypy
  • Crontab notwendig (Zugriffsdaten Wikibot einsetzen) mit
*/10 * * * * /var/www/map/geronimo.py 

Abuse Handling

Als Abuse Kontakt verwenden wir unsere Admin-Mailingliste. Dort wird sich dann unser Hoster melden, sollten Sie eine Abuse-Anfrage erhalten. Wir versuchen diese nach besten Möglichkeiten zu unterstützen. I.d.R. gibt es eine Frist für die Antwort an den Hoster. Diese könnte beispielsweise so aussehen:

Sehr geehrte Damen und Herren,
vielen Dank für Ihre Benachrichtigung. Wir werden den Vorfall überprüfen 
und ggf. Maßnahmen ergreifen, um eine Verletzung von Rechten zu beenden.
(...)
Mit freundlichen Grüßen


Im Zweifel nehmen wir eine temporäre Sperre eines APs od. Protokolls vor. Ganz wichtig ist das Sensibilisieren der Nutzer bzw. des Nutzerkreises. Hierzu haben wir sowohl Aushänge (in verschiedenen Sprachen) als auch die Infoseite für freie Zugangspunkte und weiteres im Opennet Wiki.

Sollten die Informationen nicht ausreichen, so könnte unsere Antwort wie folgt aussehen:


Sehr geehrte Damen und Herren,
Leider können wir den Fall nicht selbst nachvollziehen.
Wir bieten auf dem Server einen Zugang für einen offenen Personenkreis
an (Opennet Initiative e.V.). Sollten wir mehr Informationen erhalten
können, versuchen wir gern die Ursache zu finden und abzustellen.
Entspr. den rechtlichen Anforderungen in Bezug auf den Datenschutz
erfassen wir keine personenbezogenen Daten.
Meine Werkzeuge
Namensräume

Varianten
Aktionen
Start
Opennet
Kommunikation
Karten
Werkzeuge