Skip to content

Semaphore - Die API

Verschoben Ansible
  • Nehmen wir mal an, wir haben bei Gitlab oder auch Github, oder was auch immer, ein Repo das wir gelegentlich bearbeiten und das danach automatisch auf einen Server soll. So was ist ja in der Entwicklung von Software normal. Dafür gibt es ganz viele Möglichkeiten, ich habe mir gedacht das kann man sicherlich auch mit einem Playbook realisieren. Mittlerweile, nach vielen Kopfschmerzen, funktioniert es.

    PyCharm (commit & push) -> Gitlab -> Semaphore (Playbook) -> Server mit Applikation

    Wir müssen also mit Gitlab das Playbook auf dem Semaphore Server triggern. Meine ersten Versuche zielten darauf ab, meinen lokalen Semaphore Server zu triggern. Dazu wollte ich die IPv6 Adresse benutzen. Dies scheiterte aber die ganze Zeit.

    Die Docker Container, die Gitlab startet, scheinen keine IPv6 Funktionalität zu besitzen!?? Da ich aber schauen wollte, ob das so klappt wie ich mir das vorstellte, habe ich einen Semaphore Server im Netz aufgesetzt. Und da funktionierte es (IPv4 & IPv6) einwandfrei.

    Ok, die Doku zur API (Application Programming Interface) findet man -> https://docs.ansible-semaphore.com/administration-guide/api

    Ganz wichtig ist das Thema Authentifizierung. Damit ein User auf die API zugreifen kann, benötigt dieser meistens einen s.g. Token. Den kann man mit der API auch erzeugen, aber zuerst muss man sich mal anmelden, an der API.

    LOGIN

    curl -v -c /tmp/semaphore-cookie -XPOST \
    -H 'Content-Type: application/json' \
    -H 'Accept: application/json' \
    -d '{"auth": "YOUR_LOGIN", "password": "YOUR_PASSWORD"}' \
    http://localhost:3000/api/auth/login
    

    Login & Passowort sind die Login Daten Eures Semaphores Users. Danach ist man angemeldet und kann weiter arbeiten.

    TOKEN erzeugen

    curl -v -b /tmp/semaphore-cookie -XPOST \
    -H 'Content-Type: application/json' \
    -H 'Accept: application/json' \
    http://localhost:3000/api/user/tokens
    
    
    curl -v -b /tmp/semaphore-cookie \
    -H 'Content-Type: application/json' \
    -H 'Accept: application/json' \
    http://localhost:3000/api/user/tokens
    

    Danach erscheint in der Konsole die Ausgabe und man kann sich den Token kopieren. Damit kann man dann weiter arbeiten. Beispiel aus der Doku.

    [{"id":"YOUR_ACCESS_TOKEN","created":"2017-03-11T13:13:13Z","expired":false,"user_id":1}]
    

    Um jetzt mit Gitlab einen Task anzustoßen, braucht man diesen curl-String.

    curl -v -XPOST \
    -H 'Content-Type: application/json' \
    -H 'Accept: application/json' \
    -H 'Authorization: Bearer YOUR_ACCESS_TOKEN' \
    -d '{"template_id": 1}' \
    http://localhost:3000/api/project/1/tasks
    

    Ok, das bekommt man hin, oder? War für mich leider doch ein sehr lange Sessions des Ausprobierens usw. Das Problem war die Formatierung des curl-Strings bei gitlab. Ok, weiter geht es.

    Gitlab

    Wir legen im Gitlab Projekt eine Datei mit dem Namen

    gitlab-ci.yml
    

    an. Die Testdatei hat folgenden Inhalt.

    # Here we test to trigger a semaphore task from gitlab runner.
    stages:
      - deploy
    
    deploy:
      stage: deploy
    
      script:
        # $SEMAPHORE_API_TOKEN is stored in gitlab Settings/ CI/CD / Variables
        >
        curl -v -XPOST -H 'Content-Type: application/json' -H 'Accept: application/json' -H "Authorization: Bearer $SEMAPHORE_API_TOKEN " -d '{"template_id": 2}' https://<DOMAIN>/api/project/2/tasks
      only:
        - master  # Specify the branch to trigger the pipeline (adjust as needed)
    

    Ich wollte den Code eigentlich lesbar reinschreiben, also mit \ mehrere Zeilen. Aber alle meine Versuche sind gescheitert, egal was ich im Internet gefunden habe oder auch bei ChatGPT, es ging erst als ich alles in eine Zeile geklatscht habe. Naja, dann halt nicht.

    Wie ihr seht, habe ich zu dem Token was kommentiert.

    # $SEMAPHORE_API_TOKEN is stored in gitlab Settings/ CI/CD / Variables
    

    Unter dem Pfad kann man Token usw. ablegen und ihnen einen Namen geben. Damit kann man die sensiblen Informationen aus dem Code raushalten. Wenn man dann noch in den Einstellungen, den Token auf masked setzt, wird er auch in den Logs usw. nicht angezeigt, sondern maskiert.

    > authorization: Bearer [MASKED]
    

    Das sieht ja schon gut aus 🙂 Wenn man nun was in Pycharm editiert und das per commit & push nach gitlab befördert, führt gitlab nach der Ausführung der Befehle das File gitlab-ci.yml aus.
    Und das sorgt dafür, das der entsprechende Task auf dem Semaphore Server ausgeführt wird.

    Ein wunderbares Spielzeug 🙂 Viel Spaß beim Spielen!

    Wer Fehler findet, bitte kommentieren. Ich mag es nicht, wenn unnützes Zeug im Internet steht.

  • Ich hasse schlecht lesbaren Code, scheint man sich bei Python so anzugewöhnen. Habe da nochmal was mit der langen Zeile getestet.

    stages:
      - deploy
    
    deploy:
      stage: deploy
    
      script:
        # $SEMAPHORE_API_TOKEN is stored in gitlab Settings/ CI/CD / Variables
        - >-
         curl -v XPOST
         -H 'Content-Type: application/json'
         -H 'Accept: application/json'
         -H "Authorization: Bearer $SEMAPHORE_API_TOKEN "
         -d '{"template_id": 2}'
         https://<DOMAIN>/api/project/2/tasks
      only:
        - master  # Specify the branch to trigger the pipeline (adjust as needed)
    

    Hier noch was Dr. ChatGPT dazu schreibt

    631de9d4-b04d-4043-bfff-c5f2d1b6eea7-grafik.png

    Erledigt - läuft 🙂 Und verstanden habe ich es auch.

  • FrankMF FrankM verschob dieses Thema von Linux am

  • Crowdsec - Ein fail2ban Ersatz?

    Linux
    2
    0 Stimmen
    2 Beiträge
    519 Aufrufe
    FrankMF

    Ich kann jetzt hier von meiner ersten Erfahrung berichten und wie CrowdSec mich gebannt hat 🙂

    Was war passiert? Ich war gestern sehr intensiv mit der Konfiguration von Nextcloud <-> Collabora Online beschäftigt. Nachdem ich irgendwie nicht weiterkam habe ich mich der Erstellung eines Dokumentes gewidmet. Nach einiger Zeit war die Nextcloud nicht mehr erreichbar.

    Ok, hatte ich bei der Konfiguration auch schon mal, den Server einmal neugestartet und fertig. Doch jetzt kam es, Server neugestartet - hilft nicht. Gut, schauen wir mal nach, Der SSH Login ging auch nicht 😞

    Jetzt war guter Rat gefragt. Zu diesem Zeitpunkt ging ich noch davon aus, das auf diesem Server kein CrowdSec installiert war, sondern fail2ban. Und fail2ban hatte eine sehr kurze Bantime vom 10M.

    Also blieb wohl nur noch das Rescue System von Hetzner.

    488866bc-3dcf-4abc-9e98-6107d65aa4c7-grafik.png

    Da hatte ich ja so gut wie gar keine Erfahrung mit. Also mal kurz den Nico angetriggert und es kam folgender Link.

    Link Preview Image Hetzner Rescue-System - Hetzner Docs

    favicon

    (docs.hetzner.com)

    Das Laufwerk war schnell bestimmt und schnell nach /tmp gemountet. Danach musste man sich noch mit chroot in diese Umgebung anmelden.

    chroot-prepare /mnt chroot /mnt

    Nachdem das klappte, habe ich eben fail2ban disabled.

    sysmctl disable fail2ban

    Danach das Rescue beendet. Der Server startete wieder und ich kam wieder per SSH drauf. Puuh.
    Bei meiner ersten Kontrolle fiel mir was auf

    root@:~# pstree systemd─┬─2*[agetty] ├─atd ├─cron ├─crowdsec─┬─journalctl │ └─8*[{crowdsec}] ├─crowdsec-firewa───9*[{crowdsec-firewa}]

    Wie? Da läuft CrowdSec? Da ich dabei bin die Server auf CrowdSec umzustellen, war das wohl hier schon gemacht, aber leider nicht vernünftig. fail2ban hätte mindestens disabled werden müssen und in meiner Dokumentation war das auch nicht enthalten. 6 setzen!

    CrowdSec besteht ja aus zwei Diensten, CrowdSec und dem Firewall-Bouncer. Der CrowdSec Dienst lief aber nicht, der war irgendwie failed. Ok, starten wir ihn und schauen was passiert. Nachdem er gestarte war mal die Banliste angeschaut.

    cscli decisions list

    ergab diesen Eintrag.

    2551501 │ crowdsec │ Ip:5.146.xxx.xxx │ crowdsecurity/http-crawl-non_statics │ ban │ │ │ 53 │ 1h5m55.391864693s │ 1671

    Meine IP war gebannt. Dann wissen wir ja , woher die Probleme kamen.

    cscli decisions delete --id 2551501

    Nach Eingabe war der Ban entfernt. Na gut, aber da ich aktuell immer noch an der richtigen Konfiguration von NC <-> CODE bastel, könnte das ja wieder passieren. Was machen? Kurz gegoogelt. Es gibt eine Whitelist. Aha!

    /etc/crowdsec/parsers/s02-enrich/whitelists.yaml

    name: crowdsecurity/whitelists description: "Whitelist events from private ipv4 addresses" whitelist: reason: "private ipv4/ipv6 ip/ranges" ip: - "127.0.0.1" - "::1" - "5.146.XXX.XXX" cidr: - "192.168.0.0/16" - "10.0.0.0/8" - "172.16.0.0/12" # expression: # - "'foo.com' in evt.Meta.source_ip.reverse"

    Danach den Dienst neustarten. Jetzt hoffen wir mal, das es hilft.

    Zum Schluss noch was, was mir aufgefallen war und was mich auch sehr verwirrt hatte. CrowdSec hatte wegen einem crowdsecurity/http-crawl-non_statics gebannt. Dadurch konnte ich meine
    subdomain.<DOMAIN> nicht erreichen. Ok, logisch, wenn der Ban von da ausgeht. Ich konnte aber gleichzeitig eine andere subdomain mit derselben <DOMAIN> auch nicht erreichen. Komplett verwirrte es mich dann, als ich eine andere <DOMAIN> auf dem selben Server erreichen konnte. Und zum Schluss ging auch der SSH nicht.

    Also, wieder viel gelernt.. 🤓

  • 0 Stimmen
    4 Beiträge
    704 Aufrufe
    FrankMF

    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

  • KDE Plasma setzt auf Wayland

    Linux
    1
    0 Stimmen
    1 Beiträge
    50 Aufrufe
    Niemand hat geantwortet
  • NAS 2023 - Hardware

    Angeheftet Verschoben Linux
    3
    0 Stimmen
    3 Beiträge
    566 Aufrufe
    FrankMF

    Ich war nicht so ganz zufrieden 🙂 Die zwei 4TB 5 1/4 Zoll HDDs müssen jetzt mal weichen.

    20230520_091729.jpg

    Ich habe jetzt wieder einen Proxmox Backup Server im Einsatz, da brauche ich nicht mehr so viel Speicherplatz im NAS. Kleiner, aber wichtiger Nebeneffekt ist der, das ich jetzt ca. 7W eingespart habe. In Zeiten wie diesen, rechnet sich das. Nein, die Investitionskosten rechnen wir jetzt nicht dagegen 😉

    Screenshot_20230520_140727_Voltcraft SEM6000_ergebnis.jpg

    Aktuelle Platten Ausstattung

    1 TB NVMe SSD (Proxmox Systemplatte) 2 * 2,5 Zoll 1TB SSD WD Red (ZFS Pool für mein NAS) 1 * 2,5 Zoll HDD 2TB für Datensicherung
  • Debian Buster 10.9 released

    Linux
    1
    0 Stimmen
    1 Beiträge
    190 Aufrufe
    Niemand hat geantwortet
  • 1 Stimmen
    1 Beiträge
    253 Aufrufe
    Niemand hat geantwortet
  • NGINX - Installation

    NGINX
    1
    0 Stimmen
    1 Beiträge
    283 Aufrufe
    Niemand hat geantwortet
  • Upgrade auf NodeBB 1.11.0

    NodeBB
    1
    0 Stimmen
    1 Beiträge
    364 Aufrufe
    Niemand hat geantwortet