1. Operations
   1.1 Setup
   1.2 Architektur
   1.3 Benutzerkonzept & Zugriffe
   1.4 Services

2. CI / CD
   2.1 Tooling
   2.2 Pipeline
   3.3 Vulnerabilities

Der Betrieb und die Sicherstellung der Verfügbarkeit ist Voraussetzung für die Bereitstellung einer Software. Im Folgenden werden die einzelen Punkte zur Servereinrichtung, Härtung und Bereitstellung diverser Services beschrieben.

• Einrichten der Benutzerprofile
• Installationen mit Paketmanager

sudo apt-get update && apt-get upgrade -y \
&& sudo apt-get install -y docker-ce docker-ce-cli containerd.io curl iptables-persistent rsync git nginx certbot davfs2 mutt

• Installation ohne Paketmanager
  • Docker-Compose (Paketmanager liefert zu alte Version)
  • certbot (falls die Version aus dem Paketmanager zu alt ist) -> Anleitung

# installation docker-compose
cd $BASE_DIR_OPS/bin \
&& wget https://github.com/docker/compose/releases/download/v2.4.1/docker-compose-linux-x86_64 \
&& mv docker-compose-linux-x86_64 docker-compose

Einbinden der individuellen Binaries beim Login. Genauer beschrieben in Benutzer Individualisierung
Alternativ könnte das Binary in den offiziellen PATH gelinkt / kopiert werden.

• Best Pracises

• Netzwerk (IP-Tables mit GeoIP)

Note: Komplexe Firewall Regeln können zu Connection Problemen führen. Alternativ kann dieser Schritt auch übersprungen werden, sorgt aber für eine geringere Härtung des Systems.

Schematischer Aufbau wie Packages gefiltert und geroutet werden. Detailliert Aufbau ist hier zu finden.

Um den Netzwerkverkehr von außerhalb Deutschlands zu Blockieren ist das Zusatzmodul GeoIP notwendig. Das Modul ließt eine Liste von Länderzugeordneten IP-Ranges ein.

Installationsanleitung
Alternative Installationsanleitung mit Beispielen

# bsp. Regel
# -t mangle       = verwenden der spezifischen IP Tabelle
# -I PREROUTING   = einfügen der Regel an erster Stelle der Chain
# -p tcp          = Ankommendes Protocol TCP
# --dport 443     = Ziel Port (https)
# -m geoip        = verwenden des Modules geoip
# ! --src-cc DE   = wenn Quell IP keine Deutsche (DE), Range
# -j DROP         = Paket verwerfen

iptables -t mangle -I PREROUTING -p tcp --dport 443 -m geoip ! --src-cc DE,US -j DROP

Um die Github Action Server zuzulassen müssen die entsprechenden IP Adressen als "ACCEPT" vor den "DROP" Regeln eingefügt werden.

Das Script $BASE_DIR_OPS/bin/getGithubActionIP.sh baut die Regeln automatisch mit der aktuellsten IP-Referenzliste von Github auf.
Die Regeln sind in dem Moment nur statisch und nach jedem Neustart gelöscht.
Zum persistieren wird der Befehl iptables-save > ${BASE_DIR_OPS}/iptables/rules.v4 verwendet. (Dies ist im Script inkludiert)

Zu Testzwecken / Fehlersuche können die Regeln der Chain gelöscht und später wieder hinzugefügt werden
Löschen: iptables -t mangle -F PREROUTING
Hinzufügen: iptables-restore < ${BASE_DIR_OPS}/iptables/rules.v4

• SSH (Secure Shell)\
  • Port nicht verändert, freie Ports der Uni-Firewall (22,80,443)
  • sshd config

# bsp. sshd config: /etc/ssh/sshd_config.d/cust.conf
PermitRootLogin no
PermitEmptyPasswords no
AllowUsers bspUser1 bspUser2 bspUser3
Match User bspUser1,bspUser2
	PasswordAuthentication no
Match all
Protocol 2
MaxAuthTries 5
X11Forwarding no

Gilt nur für deployadm und deploydata. Die Eintragungen Unterscheiden sich. Ein Backup der Home-Verzeichnisse wird auf BSCW gespeichert.

• add nützliche aliases in .bashrc
• add erweiterte aliases in .bashrc_aliases
• add Erweiterten Path + Environment Variablen in .profile

# bsp. PATH erweitern: ~./profile

export BASE_DIR_OPS="***"
if [ -d "$BASE_DIR_OPS/bin" ] ; then
    PATH="$BASE_DIR_OPS/bin:$PATH"
fi

# Hauptverzeichnis

    Owner       Group      Ordner
--------------------------------------    
├── [deploydata install ]  app          -> für DEV
├── [deploydata install ]  html         -> für DEV
└── [deployadm  admin   ]  operations

# operations

├── bin
│   ├── backup_db.sh
│   ├── cleanup.sh
│   ├── docker-compose
│   ├── getGithubActionIP.sh
│   └── reboot.sh
├── compose
│   ├── app_compose.yaml                -> für Preprod und Prod
│   └── app_DEV_compose.yaml
├── config                              -> Applikation / Script bezogene config
│   ├── .env_{DEV/PREPROD/PROD}_app     -> config mount für Application Container
│   ├── .env_{DEV/PREPROD/PROD}_compose -> config für Docker-Compose Container run
│   ├── muttrc                          -> Email (SMTP) Config
│   ├── receiverList                    -> Email Empfänger Liste
│   └── nginx-frontend.conf
├── iptables
│   ├── ghIPList.txt
│   ├── oldIP
│   └── rules.v4
├── logs
├── nginx
├── old
└── tmp

Zugriff BSCW (mount WebDav)

# /etc/fstab

https://bscw.frankfurt-university.de/EduRes/bscw/bscw.cgi/home /mnt/bscw davfs uid=1003,gid=1007,rw,auto,_netdev,x-systemd.after=network-online.target 0 0

In der Datei /etc/davfs2/secrets werden die Credentials hinterlegt um das Interaktive Einbinden zu umgehen.

Zugriff auf den Server:
ssh [email protected]

Zugriff auf die Applikation erhält man durch folgende Url`s:

• https://softdsim.pro/
• https://pp.softdsim.pro/
• https://dev.softdsim.pro/

Ansprechpartner für die Domain welche über namecheap verwaltet wird ist Herr Hefter.

Konfiguration in namecheap:

Wie in der Architektur dargestellt gibt es auf dem Server dieverse laufende Programme und Scripte zur Produktbereitstellung.

Beispielkonfiguration für mutt. Für das Projekt wird lediglich der SMTP (Mails senden) benötigt.

# bsp.: ~/.muttrc -> ${BASE_DIR_OPS}/config/muttrc

set smtp_url = "smtps://[email protected]"    
set smtp_pass = "***"       
set from = "softDSim-Admin <[email protected]>"
set ssl_starttls= yes

Note: Um die Uni Mail Adresse zum versenden nutzen zu können muss der DNS-Resolver umgestellt werden in /etc/resolv.conf auf bspw. 8.8.8.8. Die Standardeinstellung löst die Adresse nicht auf.

Die Konfiguration orientiert sich an folgenden Best Pracises.

# Verlinkung Nginx Config

/etc/nginx -> $BASE_DIR_OPS/nginx/

Anpassung des Services war notwendig da nginx nach dem Server Reboot nicht gestartet werden konnte.
Service Datei: /lib/systemd/system/nginx.service
Add in Sektion "[Serivce]" : ExecStartPre=/bin/sleep 10

IMAGE                                        PORTS        NAMES
-------------------------------------------------------------------------
ghcr.io/fra-uas-project/app-backend:0.1.4    8000->8000   APP_PROD
mariadb:10.7.3                               3320->3306   APP_DB_PROD
ghcr.io/fra-uas-project/app-frontend:0.1.4   8080->80     WEB_PROD

ghcr.io/fra-uas-project/app-backend:0.1.4    8001->8000   APP_PREPROD
mariadb:10.7.3                               3321->3306   APP_DB_PREPROD
ghcr.io/fra-uas-project/app-frontend:0.1.4   8081->80     WEB_PREPROD

ghcr.io/fra-uas-project/dj:latest            8002->8000   APP_DEV
mariadb:10.7.3                               3322->3306   APP_DB_DEV

• Manuell start/stop der Umgebungen mit Alias (für docker-compose)

Bsp.: dcad up -d
Alternativ zu: docker-compose -f $BASE_DIR_OPS/compose/app_DEV_compose.yaml --env-file $BASE_DIR_OPS/config/.env_DEV_app_compose

CI/CD steht je nach Auslegung für Continuous Integration, Continuous Delivery und Continuous Deployment. Dabei geht es um die Automatisierung von der Entwicklung bis zur integration in Produktion. Anhand der DevOps Phylosophie bei welcher Development und Operations in starkem Austausch stehen können in effizienten Iterationen Änderungen eingespielt werden. Der Lifecycle mit exemplarischen Produkten ist durch folgendes Bild dargestellt.

Produkte wie Circle CI, Jenkins, Github Actions und viele weitere dienen als Software zur Umsetzung solcher CI/CD Pipelines.

Das Projekt entschied sich für den Cloud-based Hosting Service Github mit git als Version Control System.
Github inkludiert viele Funktionen wie bspw.:

• Github Actions (Workflows)
• Container Registry
• Wiki (Dokumentation)
• Kanban Boards
• Issue Ticket System
• ...

Es gibt 2 Pipelines. Eine für Development und eine für die integration in Produktion ab dem main Branche.

• Development Pipe

Pipe Stages - Backend

*Dep=Dependencie (Abhängigkeit zu Stage Nr.)

Pipe Stages - Frontend

*Dep=Dependencie (Abhängigkeit zu Stage Nr.)

Für die Kompilation der Software müssen in DEV folgende Parameter genutzt werden.

Environment Variable CI=false, default in Github true ( Information zum CI Paramter)

npm ci --legacy-peer-deps ignore all peerDependencies when installing, in the style of npm version 4 through version 6

• PreProd / Prod Pipeline

Das grundsätzliche Ziel der Produktions Pipeline ist es

• Best Practices bspw. bei npm zu beachten
• keine Vulnerabilities zulassen

Pipe Stages - CI/CD

*Dep=Dependencie (Abhängigkeit zu Stage Nr.)

Note: Bei jedem Commit auf den main Branch muss einer der folgende Begriffe enthalten sein, da die Pipe sonst abbricht.
Beispiel Message: "fixed size Button #patch"

• #major
• #minor
• #patch

<TBD by Othmane>