Skip to content

Semaphore - Installation & Anwendung

Verschoben Ansible
  • Semaphore ist ein UI für Ansible, geschrieben mit Go & Vue.js. Beim Besuch der letzten FrOSCon 18 lernt man ja immer was dazu. Es wurde Zeit das mal auszuprobieren.

    Bis jetzt habe ich meine Server, einmal in der Hetzner-Cloud zum anderen Lokal, immer mit ClusterSSH administriert. Das ist für mich völlig ausreichend, aber ich möchte gerne auch immer was dazu lernen.

    Ok, dann fangen wir mal an.

    Installation

    Voraussetzungen

    • Debian Bookworm 12 Server
    • vorhandenen MariaDB Instanz
    • Linux Grundkenntnisse

    Ich werde nicht alles bis ins letzte Detail hier aufschreiben, aber mit Grundkenntnissen sollte man in der Lage sein, das erfolgreich umzusetzen.

    Die Anleitung empfiehlt folgende Vorgehensweise.

    wget https://github.com/ansible-semaphore/semaphore/releases/\
    download/v2.8.75/semaphore_2.8.75_linux_amd64.deb
    
    sudo dpkg -i semaphore_2.8.75_linux_amd64.deb
    

    Ich ändere das ein wenig ab. Zum einen, ist die Dokumentation nicht ganz aktuell und zum anderen brauche ich kein sudo.

    wget https://github.com/ansible-semaphore/semaphore/releases/\
    download/v2.8.90/semaphore_2.8.90_linux_amd64.deb
    
    dpkg -i semaphore_2.8.90_linux_amd64.deb
    

    Danach ruft man das Setup auf

    semaphore setup
    

    und ergänzt die Abfragen. Kleiner Tipp von mir, der Web Host bleibt leer, sonst ist die Installation defekt. Für Euch getestet. Bezieht sich nur auf eine lokale Installation. Siehe meine Ergänzung zum Thema Email.

    "web_host": "",
    

    Wenn man das Ganze jetzt als User root gemacht hat, liegt die Konfigurationsdatei config.json unter /root

    Das machen wir jetzt mal was sicherer. Eine Anwendung sollte ja unter seinem eigenen User laufen, kein Dienst der nicht unbedingt Rootrechte benötigt, bekommt diese auch. Also legen wir uns dafür einen User an, der heißt hier semaphore - Überraschung 🙂

    User anlegen

    Den User legen wir mit

    useradd -m semaphore
    

    an. Damit hat dieser User auch ein Home-Verzeichnis unter /home/semaphore Nun kopieren wir schon mal die config.json hierhin.

    mv /root/config.json /home/semaphore
    

    Jetzt muss der Dienst auch noch gestartet werden, dazu legen wir einen SystemD Service an.

    /etc/systemd/system/semaphore.service

    [Unit]
    Description=Ansible Semaphore
    Documentation=https://docs.ansible-semaphore.com/
    Wants=network-online.target
    After=network-online.target
    ConditionPathExists=/usr/bin/semaphore
    ConditionPathExists=/home/semaphore/config.json
    
    [Service]
    ExecStart=/usr/bin/semaphore service --config /home/semaphore/config.json
    ExecReload=/bin/kill -HUP $MAINPID
    Restart=always
    RestartSec=10s
    User=semaphore
    Group=semaphore
    
    
    [Install]
    WantedBy=multi-user.target
    

    Den Dienst aktivieren und starten ihn

    systemctl enable semaphore.service
    systemctl start semaphore.service
    

    Danach sollte man in der Lage sein, das Webinterface aufzurufen. Hier das Beispiel meiner Proxmox VM. Passt das an Eure Gegebenheiten bitte an.

    http://192.168.3.14:3000/
    

    TASK_ergebnis.png

    NGINX

    Sollte man das ganze im Netz betreiben wollen, dann sollte man einen Proxy davor schalten. Hier mal ein Beispiel aus der Doku.

    Man muss dann nicht

    http://192.168.3.14:3000/
    

    eingeben, um den Server zu erreichen. Es reicht dann

    http://192.168.3.14
    

    Die NGINX Beispiel Konfiguration

    server {
      listen 443 ssl;
      server_name  _;
    
      # add Strict-Transport-Security to prevent man in the middle attacks
      add_header Strict-Transport-Security "max-age=31536000" always;
    
      # SSL
      ssl_certificate /etc/nginx/cert/cert.pem;
      ssl_certificate_key /etc/nginx/cert/privkey.pem;
    
      # Recommendations from 
      # https://raymii.org/s/tutorials/Strong_SSL_Security_On_nginx.html
      ssl_protocols TLSv1.1 TLSv1.2;
      ssl_ciphers 'EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH';
      ssl_prefer_server_ciphers on;
      ssl_session_cache shared:SSL:10m;
    
      # required to avoid HTTP 411: see Issue #1486 
      # (https://github.com/docker/docker/issues/1486)
      chunked_transfer_encoding on;
    
      location / {
        proxy_pass http://127.0.0.1/;
        proxy_set_header Host $http_host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        
        proxy_set_header X-Forwarded-Proto $scheme;
    
        proxy_buffering off;
        proxy_request_buffering off;
      }
    
      location /api/ws {
        proxy_pass http://127.0.0.1/api/ws;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
        proxy_set_header Origin "";
      }
    }
    

    Das habe ich aktuell nicht getestet, da mein Semaphore-Server lokal steht und es auch so bleiben soll.

    Für eine Anwendung, gitlab.com, brauch ich den doch im Netz. Habe das probiert und funktioniert auch. Kommt aber sicher noch ein ergänzender Beitrag von mir (Update: 20.08.23)

    SSH

    Wichtig ist, das der User semaphore auf alle Server, die er erreichen soll, mittels

    ssh root@<DOMAIN oder IP>
    

    connecten kann. Dazu muss die id_rsa.pub auf den Zielsystemen unter authorized_keys hinterlegt sein. Das solltet ihr kennen, wenn nicht mal kurz hier rein lesen. Zusammenfassung:

    Der User semaphore muss mittels

    ssh root@<DOMAIN oder IP>
    

    connecten können!

    Einrichtung eines Projektes

    Wir legen ein neues Projekt an.

    2395e6ef-847a-4abb-8541-1fb0e20abf2d-grafik.png

    Namen eingeben, der Rest ist optional. Danach legen wir den Key an.

    Key Store

    3157efe2-fe75-46ce-8d28-62ea0a13bf72-grafik.png

    Wir geben ihm einen Namen, wählen SSH Key aus, als Username wählen wir root und geben den Private Key des Semaphore Servers ein.

    Repositories

    dead2fe3-156d-4b3f-b9a0-ea3cf79cbc80-grafik.png

    Wir geben ihm einen Namen. Der Pfad zeigt auf einen Ordner im Home-Verzeichnis des Users semaphore. Ich nenne das hier im Beispiel ansible, dort liegen hinterher die Playbooks usw.

    Environment

    170bfcec-5683-426f-aef1-6e92613c0536-grafik.png

    Dort kann man Umgebungsvariablen ablegen. Brauchen wir aktuell nicht, muss aber angelegt sein. Deswegen muss das so aussehen. Also, ohne Inhalt.

    Inventory

    23f609ca-e37b-42fb-82a7-5a726d736ffe-grafik.png

    Hier legt man an, welche Server bearbeitet werden sollen. Denke, das ist selbsterklärend. Der Name [Name] kann beliebig sein.

    Task Template

    94b8c36c-c5ab-4e7d-84c7-46cf8fb73ac3-grafik.png

    Jetzt könnt Ihr alles auswählen. Das Playbook Filename hat mich etwas Zeit gekostet um zu verstehen, wo das liegt. Da kommt jetzt wieder das Repository zum Einsatz. Der dort hinterlegte Pfad wird jetzt für das Playbook benutzt.

    Das Playbook task.yml haben wir noch nicht, kommt noch 🙂 Das kann man jetzt aber nicht in dem UI anlegen und bearbeiten, wir müssen auf die Konsole des Servers.

    Playbook anlegen

    Das Playbook muss hier liegen

    /home/semaphore/ansible
    

    /home/semaphore/ansible/task.yml

    ---
    - name: My task
      hosts: all
      tasks:
        # Update and install the base software
        - name: Update apt package cache.
          apt:
            update_cache: yes
            cache_valid_time: 600
    
        - name: Upgrade installed apt packages.
          apt:
            upgrade: 'yes'
            #register: upgrade
    
        - name: Ensure that a base set of software packages are installed.
          apt:
            name:
             - duf
             - needrestart
             - htop
             # - build-essential
             # - curl
             # - fail2ban
             # - firewalld
             # - git
             # - needrestart
             # - pwgen
             # - resolvconf
             # - restic
             # - rsync
             # - sudo
             # - unbound
             # - unzip
             # - vim-nox
            state: latest
    
        - name: Check if a new kernel is available
          ansible.builtin.command: needrestart -k -p > /dev/null; echo $?
          register: result
          ignore_errors: yes
    
        - name: No new kernel
          ansible.builtin.command: uname -r
          when: result.rc == 0
    
        - name: Restart the server if new kernel is available
          ansible.builtin.command: reboot
          when: result.rc == 2
          async: 1
          poll: 0
    
        - name: Wait for the reboot and reconnect
          wait_for:
            port: 22
            host: '{{ (ansible_ssh_host|default(ansible_host))|default(inventory_hostname) }}'
            search_regex: OpenSSH
            delay: 10
            timeout: 60
          connection: local
    
        - name: Check the Uptime of the servers
          shell: "uptime"
          register: Uptime
    
        - debug: var=Uptime.stdout
    

    Ich habe die letzten Tage an meinem Playbook gefeilt, die Dokumentation ist riesig. Richtige Hilfe im Netz ist selten, ChatGPT hat auch mehr Blödsinn geschrieben, als Hilfe. Zum Schluss habe ich es aber doch hinbekommen.

    Die Tasks

    1. Update apt package cache.
      Macht das was apt update auch macht, schaut nach neuen Paketen.

    2. Upgrade installed apt packages.
      Also ein apt upgrade

    3. Ensure that a base set of software packages are installed.
      Stellt sicher, das man bestimmte Software Pakete auf seinem Server installiert hat.

    4. Check if a new kernel is available
      Hat apt upgrade einen neuen Kernel installiert? Dazu nutze ich das Tool needrestart. Rückgabewert 0 bedeutet keinen neuen Kernel, Rückgabewert 2 bedeutet, es ist Zeit für einen Reboot. Interessantes Feature von ansible ist, man kann gewisse Dinge auch async machen. Ohne das knallte das Playbook immer mit Failure, weil logischerweise der Server nicht mehr erreichbar war. Spannend.

    5. No new kernel
      Rückgabe 0

    6. Restart the server if new kernel is available
      Rückgabe 2

    7. Wait for the reboot and reconnect
      Wir warten auf alle Server, bis alle Server wieder on sind.

    8. Check the Uptime of the servers
      Wir schauen nach dem die Server alle wieder on sind, ob sie auch leben 😉

    9. debug: var=Uptime.stdout
      Kontrolle der Uptime.

    Fertig!

    Task Ausgabe

    Task_1.png

    Task_2.png

    Fazit

    Mal wieder ein Tool, was @Nico mir empfohlen hat und was vermutlich aus meinem Leben nicht mehr verschwindet 🙂

    Hinweise

    Für einen Server im Netz fehlen da noch einige Dinge, also bitte so nicht ins Internet. Lokal ist das ausreichend.

    Sollte jemand Fehler finden, würde ich mich über eine Korrektur freuen. Man kann immer nur dazu lernen.

    Viel Spaß mit dem Tool!

  • Email

    Als Ergänzung, wenn man beim Setup keine Email Daten eingegeben hat.

    In der config.json findet man folgendes

            "email_sender": "<SENDER ADRESS>",
            "email_host": "smtps.<DOMAIN>.de",
            "email_port": "587",
            "email_username": "<USERNAME>",
            "email_password": "<PASSWORD>",
    

    Ging danach noch nicht. Man findet noch diese beiden Einstellungen.

            "email_alert": true,
            "email_secure": true,
    

    Der erste schaltet wohl die Email Funktionalität ein. Der zweite steuert vermutlich den Email-Port.

    Ports: 465 (SSL/TLS), 587 (STARTTLS)
    

    Ich nutze den Port 587 und email_secure muss auf true stehen.

    Habe dann einen Server ausgeschaltet um einen Failure zu provozieren. Danach kam diese Email.

    Task 119 with template 'TEST' has failed!`
    Task Log: /project/1/templates/1?t=119
    

    Und nun macht auch die Einstellung

    "web_host": "",
    

    Sinn. Bei einem ordentlich konfigurierten Server im Internet, der einen Domainnamen hat, kommt dieser jetzt in das Feld und dann wird der auch in der Email ergänzt. Somit hätte man auch direkt einen Link zum Log.

    Noch was, unter Edit User kann man einstellen das der User Emails versendet. Diese Mailadresse empfängt die Mails. Sieht nach einer schlechten Übersetzung aus!?

    Email.png

    Und unter den Projekt Settings kann man einstellen, ob das Projekt überhaupt Emails versenden darf.

    e880c667-bdb7-450c-aaab-5e3e95b9c8ce-grafik.png

  • Heute geht es dann mal ans Testen der Gitlab bzw. Github Funktionalität. Das Playbook jedes mal auf der Konsole zu editieren ist doof und macht ja auch kein Profi, viel zu mühsam. Das möchte man ja alles von seiner Maschine aus machen, im Idealfall mit seiner Entwicklungsumgebung.

    Gitlab

    Ihr erstellt Euch ein leeres neues Projekt. Dann legt man einen Access Token an.

    4f5fcf59-3250-43ec-886b-8c03540e2dfe-grafik.png

    Pycharm

    Ich nutze Pycharm, das geht aber mit jeder Entwicklungsumgebung gleich. Man legt ein neues Projekt an, erstellt das Playbook (task.yml) und commitet das zum Gitlab Projekt. Dazu benötigt man die URL des Gitlab Projektes und den Benutzer & das Passowrt des Access Tokens. Fertig, danach ist das Playbook im Gitlab.

    833caaa8-f201-490c-8609-dedc1abb1cc1-grafik.png

    Semaphore

    Im Semaphore Projekt muss man jetzt zwei Dingen anpassen.

    Key Store

    eaeb7b55-cd01-4de6-a776-b439e464a56f-grafik.png

    Wir geben dem Key einen Namen (beliebig), der Login wird auf Login with password eingestellt. Und User & Password befüllen wir mit den Daten des Access Tokens - fertig.

    Repositories

    e395246b-d2f6-488a-82f2-da1420f44587-grafik.png

    Dort gibt man die URL zum Gitlab Projekt ein. Dann den Branch, hier master. Ganz unten wählt man noch den eben angelegten Key aus. Um die Warnung weg zu bekommen, siehe unteres Bild, muss man nur anstelle von playbook - playbook.git eingeben.

    Resultat

    gitlab.png

  • FrankMF FrankM verschob dieses Thema von Linux am
  • Ich parke das mal hier, damit ich das nicht noch mal vergesse. Hat mich eben mal wieder eine Stunde gekostet 😞

    /etc/ansible/ansible.cfg

    [defaults]
    host_key_checking = False
    

    Edit -> https://linux-nerds.org/topic/1493/ansible-host_key_checking

  • FrankMF FrankM hat am auf dieses Thema verwiesen

  • Intel ARC A580

    Linux
    4
    0 Stimmen
    4 Beiträge
    387 Aufrufe
    FrankMF

    Zwei Monitore ausprobiert, einen 4K und einen Full-HD (HDMI). Lief einwandfrei, auch gemeinsam.

  • Restic v0.16.1 released

    Restic
    1
    0 Stimmen
    1 Beiträge
    115 Aufrufe
    Niemand hat geantwortet
  • HSTS - Sicherheitsmechanismus für HTTPS-Verbindungen

    Linux
    1
    0 Stimmen
    1 Beiträge
    67 Aufrufe
    Niemand hat geantwortet
  • Debian Bookworm 12 - Btrfs Installation

    Linux
    3
    0 Stimmen
    3 Beiträge
    2k Aufrufe
    FrankMF

    Das mit den Namen der btrfs Subvolumes ist bekannt bei Timeshift. Im Readme steht dazu folgendes.

    BTRFS volumes

    BTRFS volumes must have an Ubuntu-type layout with @ and @home subvolumes. Other layouts are not supported. Systems having the @ subvolume and having /home on a non-BTRFS partition are also supported.

    Text file busy / btrfs returned an error: 256 / Failed to create snapshot can occur if you have a Linux swapfile mounted within the @ or @home subvolumes which prevents snapshot from succeeding. Relocate the swapfile out of @ or *@home, for example into it's own subvolume like @swap.

  • Linux Mint Cinnamon 20.2 "Uma" released

    Linux
    3
    0 Stimmen
    3 Beiträge
    268 Aufrufe
    FrankMF

    Was noch gestört hatte, war der Scrollbalken im FF. Der war zu schmal, konnte man schlecht erwischen.

    8e403120-11e2-413f-a479-0ebc3002e6d4-grafik.png

    Quelle: https://forums.linuxmint.com/viewtopic.php?f=47&t=330849&sid=1c7c71850931d5c34d8a0dd41ff57679

  • Mainline 5.12.x

    Images
    2
    0 Stimmen
    2 Beiträge
    304 Aufrufe
    FrankMF

    5.12.0-1149-ayufan released

    ayufan: defconfig: add MT76x* drivers
  • Ubiquiti ER-X - Firewall

    Verschoben OpenWRT & Ubiquiti ER-X
    1
    0 Stimmen
    1 Beiträge
    257 Aufrufe
    Niemand hat geantwortet
  • Restic - forget --keep-last 3 --prune

    Restic
    2
    0 Stimmen
    2 Beiträge
    598 Aufrufe
    FrankMF

    Ich habe mich damit noch ein wenig beschäftigt, die letzten drei zu behalten, ist nicht so optimal. Da es viele Optionen bei dem Befehl gibt, hier ein Ausschnitt

    Flags: -l, --keep-last n keep the last n snapshots -H, --keep-hourly n keep the last n hourly snapshots -d, --keep-daily n keep the last n daily snapshots -w, --keep-weekly n keep the last n weekly snapshots -m, --keep-monthly n keep the last n monthly snapshots -y, --keep-yearly n keep the last n yearly snapshots

    habe ich das ein wenig so angepasst, das ich denke es passt für mich.

    restic --password-file /root/passwd -r /media/NAS_neu/Restic/Home/ forget --keep-last 3 --keep-monthly 3 --prune

    Damit behalte ich auch die jeweils eines pro Monat. Und die letzten drei. Das sieht dann so aus.

    root@debian:~# ./backup2.sh repository 2f3f6147 opened successfully, password is correct Files: 38 new, 100 changed, 13268 unmodified Dirs: 0 new, 1 changed, 0 unmodified Added to the repo: 10.166 GiB processed 13406 files, 50.324 GiB in 3:24 snapshot 849f614c saved repository 2f3f6147 opened successfully, password is correct Applying Policy: keep the last 3 snapshots, 3 monthly snapshots snapshots for (host [debian], paths [/home/frank]): keep 5 snapshots: ID Time Host Tags Reasons Paths ------------------------------------------------------------------------------------ a7251cfd 2019-11-28 17:00:01 debian monthly snapshot /home/frank 283d4027 2019-12-31 17:00:01 debian monthly snapshot /home/frank ae2b96ec 2020-01-01 21:47:46 debian last snapshot /home/frank 079e00a6 2020-01-02 17:00:01 debian last snapshot /home/frank 849f614c 2020-01-03 21:08:45 debian last snapshot /home/frank monthly snapshot ------------------------------------------------------------------------------------ 5 snapshots remove 26 snapshots: ID Time Host Tags Paths ------------------------------------------------------------------ 896f16c2 2019-11-07 22:23:40 debian /home/frank b21bcf6d 2019-11-11 17:00:01 debian /home/frank f89248fb 2019-11-12 17:00:01 debian /home/frank 123ab546 2019-11-13 17:00:01 debian /home/frank b82d87d0 2019-11-18 17:00:01 debian /home/frank 040b0ab7 2019-11-19 17:00:01 debian /home/frank 7221d8ef 2019-11-20 17:00:01 debian /home/frank 84132a25 2019-11-21 17:00:01 debian /home/frank b558a52c 2019-11-25 17:00:01 debian /home/frank e5cc0c3e 2019-12-02 17:00:01 debian /home/frank 22423fa5 2019-12-03 17:00:01 debian /home/frank 39df1ab9 2019-12-04 17:00:01 debian /home/frank 98843457 2019-12-05 17:00:01 debian /home/frank b0cdd4b6 2019-12-09 17:00:01 debian /home/frank 828414f9 2019-12-10 17:00:01 debian /home/frank e34a27c3 2019-12-11 17:00:01 debian /home/frank 6e488c3b 2019-12-12 17:00:01 debian /home/frank 17898403 2019-12-16 17:00:01 debian /home/frank 1973305a 2019-12-17 17:00:01 debian /home/frank 9553bedd 2019-12-18 17:00:01 debian /home/frank fedf749d 2019-12-19 17:00:01 debian /home/frank 8e7cb876 2019-12-23 17:00:01 debian /home/frank 0bd0d102 2019-12-25 17:00:01 debian /home/frank 13d348b0 2019-12-26 17:00:01 debian /home/frank c7d960aa 2019-12-30 17:00:01 debian /home/frank f6ea9118 2020-01-01 17:00:01 debian /home/frank ------------------------------------------------------------------ 26 snapshots 26 snapshots have been removed, running prune counting files in repo building new index for repo [0:35] 100.00% 7806 / 7806 packs repository contains 7806 packs (46537 blobs) with 41.110 GiB processed 46537 blobs: 0 duplicate blobs, 0 B duplicate load all snapshots find data that is still in use for 5 snapshots [0:01] 100.00% 5 / 5 snapshots found 32654 of 46537 data blobs still in use, removing 13883 blobs will remove 0 invalid files will delete 715 packs and rewrite 752 packs, this frees 5.027 GiB [2:28] 100.00% 752 / 752 packs rewritten counting files in repo [0:01] 100.00% 6571 / 6571 packs finding old index files saved new indexes as [d137b425 f7caee99 a6e9711a] remove 35 old index files [1:13] 100.00% 1467 / 1467 packs deleted done using temporary cache in /tmp/restic-check-cache-916655151 repository 2f3f6147 opened successfully, password is correct created new cache in /tmp/restic-check-cache-916655151 create exclusive lock for repository load indexes check all packs check snapshots, trees and blobs read all data [7:47] 100.00% 6571 / 6571 items duration: 7:47 no errors were found root@debian:~#

    Am Ende seht ihr noch, wie Restic alle Files testet. Mein Script sieht jetzt so aus.

    #!/bin/bash # Script um mit Restic Daten automatisiert zu sichern! # Dient zum Sichern der Homepartition auf dem ROCKPro64 NAS! # Was soll gesichert werden? backup_pfad=/home/frank # Programm Start restic --password-file /root/passwd -r /media/NAS_neu/Restic/Home/ backup $backup_pfad --exclude-file=excludes.txt restic --password-file /root/passwd -r /media/NAS_neu/Restic/Home/ forget --keep-last 3 --keep-monthly 3 --prune # Testen restic --password-file /root/passwd -r /media/NAS_neu/Restic/Home/ check --read-data

    Das dann schön mit einem Cronjob laufen lassen und die Datensicherung ist erledigt 😉