📲 Hat Euer Smartphone noch eine Zukunft? Der "HandyCheck" von mobilsicher.de hilft Euch mit individuellen Tipps und Anleitungen zu alten und/oder defekten Smartphones.

Das fnordkollektiv bietet mit WA-Backstage eine quelloffene Arbeitsplatzverwaltung auf der Arbeitsplatz-Suite WorkAdventure. Damit lassen sich Remote-Arbeitsplätze genauso wie Online-Konferenzen verwalten.

12 Jahre alter Raspberry Pi dient als Streaming Server, mit Alpine Linux und MPD.

Ein Guide um mit OpenKiosk und GNU/Linux ein einfaches Infoterminal/Digital Signage aufzubauen.

Welche Organisationen gibt es im Open Collective Umfeld und welche Alternativen gibt es nach der Auflösung?

Mit "Invidious Router" lassen sich bequem Videos verlinken und einbetten. Dabei wird auf verfügbare und schnelle Invidious Instanzen weitergeleitet.

In diesem Jahr möchte das OpenStreeMap-Projekt die Raster-Karten durch Vektor-Karten ersetzen. Daraus ergeben sich viele Vorteile.

Das Bezahlsystem GNU Taler ermöglicht das schnelle und einfache Geldüberweisen mit Datenschutz und hoher technischer Sicherheit. Nun hat sich ein europäisches Konsortium gebildet, um die Bezahlmethode voran zu bringen.

Mit dem neuen Projekthandbuch liefert das GNOME-Team eine überarbeitete Zusammenstellung von Informationen, die sich an Contributoren richtet.

Der Linux-App-Store verzeichnet mittlerweile 1,6 Milliarden Downloads von über 2.400 Apps im Flatpak-Format und wächst weiter.

Das Redox-Projekt, ein komplett in Rust geschriebenes Desktop-Betriebssystem, hat einen Überblick über die im Januar erzielten Fortschritte veröffentlicht, und es ist eine wirklich lange Liste.

Heute möchte ich noch einmal ein Thema aus der Mottenkiste holen, welches ja eigentlich schon abgehakt sein sollte. Es geht um das Upgrade von Raspbian 10 auf das Raspberry Pi OS 11.

Anlass des Ganzen ist unsere Community-Cloud mit über 25 Nutzern. Diese Cloud wurde vor über fünfeinhalb Jahren zum Zwecke des Datenteilens ins Leben gerufen. Durch einen bedingten öfteren Standortwechsel verblieb das System auf einem Softwarestand von vor über zwei Jahren. Jetzt im neuen Zuhause stand dadurch ein gründlicher Tapetenwechsel an. D.h., dass im ersten Schritt das Betriebssystem auf Raspberry Pi OS 11 Bullsleye angehoben werden musste, bevor die Nextcloud von Version 22 auf 27 aktualisiert wurde. Weiterhin musste parallel PHP 7.3 auf Version 8.1 gezogen werden, um wieder in sicheres Fahrwasser zu gelangen. Bei der Hardware handelt es sich um einen Raspberry Pi 3 Model B. Auch dieses Gerät soll im laufe des Jahres noch ein Refresh erhalten.

Nun zum Upgrade auf das erwähnte Raspberry Pi OS 11.

Installation

Hilfreich bei der Installation war die Anleitung von linuxnews.de, die ich abschließend noch um zwei Punkte ergänzen musste. Hierbei konnte ich mich noch an mein erstes Upgrade dieser Art erinnern, dass es zu Unverträglichkeiten mit dem Desktop kam. Dieses Problem wird ganz am Ende des Artikels behandelt.

Zuerst wurde ein vollständiges Upgrade auf die aktuellste Version Raspbian 10 durchgeführt.

sudo apt update
sudo apt full-upgrade
sudo rpi-update

Danach wurden die Quellen auf Bullseye angepasst.

sudo sed -i 's/buster/bullseye/g' /etc/apt/sources.list
sudo sed -i 's/buster/bullseye/g' /etc/apt/sources.list.d/raspi.list

Im Anschluss folgte ein Update der Quellen und die erforderliche Installation von gcc-8.

sudo apt update && sudo apt install libgcc-8-dev gcc-8-base
sudo apt full-upgrade 
sudo apt -f install

Danach wurden unnötige Pakete und verbliebene heruntergeladene Pakete entfernt.

sudo apt autoremove
sudo apt clean

Nun mussten noch die Kernelbased Mode-Setting (KMS) in der /boot/config.txt angepasst werden. Hierzu wurden folgende zwei Befehle ausgeführt:

sudo sed -i 's/dtoverlay=vc4-fkms-v3d/#dtoverlay=vc4-fkms-v3d/g' /boot/config.txt
sudo sed -i 's/\[all\]/\[all\]\ndtoverlay=vc4-kms-v3d/' /boot/config.txt

Desktop aufräumen

Nach dem Reboot mit angeschlossenem Monitor fiel auf, dass sich das Programm Parcellite in der Menüleiste verewigt hatte. Parcellite war vor dem Systemupgrade auf Raspberry Pi OS 11 Bullseye nicht an Bord. Aus diesem Grund konnte es auch ohne Bedenken gelöscht werden.

sudo apt remove parcellite

Weiterhin fiel auf, dass die ganze Menüleiste des Desktops etwas vermurkst aussah. Diese wurde auf die Grundeinstellungen mit

cd ~/
sudo rm -rf .cache

zurückgesetzt.

Nach einem erneuten Reboot läuft Raspberry Pi OS 11 wie gewünscht.

sudo reboot

Fazit

Um unsere Community-Cloud wieder sicher zu machen, war ein wenig Wochenendarbeit nötig. Die so investierte Zeit hat sich aber durchaus gelohnt. Im nächsten Schritt erfolgt dann der Tausch des Raspberry Pi und ein Wechsel der Daten-SSD gegen ein größeres Modell.

Bei (streams) handelt es sich um eine relativ unbekannte Fediverse-Software, die inzwischen aber sehr stabil läuft und in der Tradition von Friendica und Hubzilla steht.

Bei MX Linux handelt es sich um eine Distribution, die sich für ältere Geräte eignet. Nun wurde die zweite Verbesserung Version 23.2 veröffentlicht.Sie umfasst Bugfixes, Kernel und Anwendungsaktualisierungen.

Collabora Online hat am 18.01.2024 die Version 23.05.7 veröffentlicht. Das sind die Details der Version:

Geschehnisse in der FLOSS Welt aus KW 51

Neuigkeiten von Framasoft zu PeerTube.

Nextcloud Hub 7 wurde veröffentlicht.

Am 16. September 2023 fanden in Halle am Institut für Informatik der Martin-Luther-Universität die Campus Medien Tage 2023 statt.

Hierzu wurde ich von der Studierendenzeitschrift hastuzeit angefragt, einen kleinen Workshop zum Thema WordPress durchzuführen. Da dies eine gute Plattform bot, die freie Software WordPress vorzustellen, habe ich nicht lange überlegt und ja gesagt. Ich wusste zu diesem Zeitpunkt nicht, in wie weit das Puplikum schon mit diesem Content-Management-System gearbeitet hat, deshalb habe ich mich kurzerhand dazu entschieden auf die Grundlagen von WordPress einzugehen und die Basics etwas näher zu beleuchten.

Da tatsächlich nur ein Viertel der anwesenden Studierenden mit WordPress (aus administrativer Sicht) bisher in Berührung kam, lag ich mit meinem Gefühl hier durchaus richtig. Einige Fragen konnten in der anschließenden Diskussion noch beantwortet werden.

Neben meinem Vortrag gab es viele weitere interessante Themen, wie Grafikbearbeitung, die richtige Verwendung von Suchmaschinen, Künstliche Intelligenz, Fotografie, Tipps zum redaktionellen Schreiben und Rechtliches, in Form von Vorträgen und Workshops.

Alles in allem war es eine sehr gute Veranstaltung, organisiert und durchgeführt von engagierten jungen und wissbegierigen Menschen.

Paperless-NGX ist ein bekanntes und beliebtes Open Source Dokumenten-Management-System (DMS). Auch ich möchte zukünftig meinen „Papierkram“ darin verwalten.

In diesem Artikel halte ich meine Gedanken fest, wie ich plane, paperless-ngx in meiner Umgebung aufzusetzen und zu betreiben.

Dies hilft mir, zu prüfen, ob ich auch an alles Wichtige gedacht habe. Falls euch das Konzept gefällt, dürft ihr es selbstverständlich gerne nachahmen. Und wenn ihr schwerwiegende Fehler darin entdeckt, freue ich mich über einen Hinweis.

Es ist kein Tutorial und keine Schritt-für-Schritt-Anleitung. Zwar mag dieser Text dazu dienen, sich eine eigene Umgebung aufzubauen, Mitdenken ist dabei jedoch zwingend erforderlich.

Ziele

• Betrieb von Paperless-NGX als rootless-Podman-Container
• Consumption-Ordner als Samba-Share freigegeben, um via Netzwerk Dateien hineinkopieren zu können
• Getrennte Benutzerkonten für meine Frau und mich
• Freigabe gewisser Dokumente für weitere Benutzer(gruppen)
• Erfolgreicher Restore-Test

Infrastruktur

In meinem Heimnetzwerk betreibe ich einen Desktop-/Server-PC. Auf diesem läuft aktuell RHEL 9 als KVM/QEMU-Hypervisor. Er dient mir ebenfalls als Ansible Control Node. Hierauf betreibe ich eine RHEL-9-VM mit einer rootless-Podman-Installation. Diese VM wird auch meine Paperless-NGX-Instanz hosten.

In der VM wird das EPEL-Repository aktiviert, um daraus die Pakete podman-compose und python3-pexpect installieren zu können.

Falls ich mal nicht mehr weiß, wie dieses Setup aufgebaut wird, finden sich dazu Hinweise in folgenden Links:

• RHEL 9 Setting up your host, creating and administering virtual machines, and understanding virtualization features
• Using Podman, Buildah, and Skopeo on Red Hat Enterprise Linux 9
• Podman Installation Instructions
• Basic Setup and Use of Podman in a Rootless environment
• GitHub: containers/podman-compose
• python3-pexpect

Installation mit Ansible

Für die Installation der Anwendung wird die Container Route verwendet. Die Installation wird dabei unter Nutzung der Ansible-Rolle tronde.paperless_ngx_with_rootless_podman automatisiert.

Das Playbook deploy_paperless_ngx.yml, welches auf meiner Synology Diskstation abgelegt ist, führt die Installation und Konfiguration der Anwendung durch. Es installiert und konfiguriert zudem Samba und die Datei-Freigabe des Consumption-Verzeichnisses.

In dem Playbook werden folgende Rollen verwendet:

• tronde.paperless_ngx_with_rootless_podman (Eigenkreation)
• vladgh.samba.server

Die Rollen sind mit dem Playbook in meinem Ansible-Projekt-Verzeichnis auf meiner Synology Diskstation installiert.

Alle Playbooks und Rollen werden mit Git versioniert. Die Repositories werden auf entfernte Rechner synchronisiert.

Vorbereitung

Die Dateien docker-compose.postgres-tika.yml, docker-compose.env und .env werden aus dem Projekt-Repository in das Rollen-Verzeichnis files meiner Ansible-Rolle heruntergeladen. Die Datei docker-compose.postgres-tika.yml wird dabei zu docker-compose.yml umbenannt und bearbeitet.

Um Datenverlust vorzubeugen, wird die Ansible-Rolle mit den angepassten Dateien in die regelmäßige Datensicherung aufgenommen.

Folgende Variablen werden in meinem Ansible-Vault hinterlegt:

# Paperless-ngx with podman-compose
pnwrp_podman_user: alice
pnwrp_podman_group: alice
pnwrp_compose_dir: /home/{{ pnwrp_podman_user }}/paperless-ngx
pnwrp_paperless_superuser: alice
pnwrp_paperless_superuser_email: alice@example.com
pnwrp_paperless_superuser_password: ImWunderland
## Username and password for document scanner
brother_scanner_user: scanner
brother_scanner_pass: ImWunderland

Die Werte der Variablen werden selbstverständlich angepasst.

Das Playbook

Folgender Code-Block zeigt das fertige Playbook mit Beispielwerten:

---
- hosts: host.example.com
  remote_user: alice
  debugger: never
  vars_files:
    - files/alice.vault
  tasks:
    - name: Setup Paperless-NGX with podman-compose in rootless Podman
      include_role:
        name: ansible_role_paperless-ngx_with_rootless_podman

    - name: Enable Port 8000/tcp in host firewall
      ansible.posix.firewalld:
        port: 8000/tcp
        immediate: true
        permanent: true
        state: enabled
      become: true

    - name: >-
        Create and add {{ brother_scanner_user }} to
        {{ pnwrp_podman_group }}
      ansible.builtin.user:
        name: "{{ brother_scanner_user }}"
        comment: "Brother Dokumenten-Scanner"
        create_home: false
        groups: "{{ pnwrp_podman_group }}"
        append: true
        shell: /usr/sbin/nologin
        state: present
        system: true
      become: true

    - name: Include role vladgh.samba.server
      include_role:
        name: vladgh.samba.server
      vars:
        ansible_become: true
        samba_users:
          - name: "{{ pnwrp_podman_user }}"
            password: "{{ alice_password }}"
          - name: "{{ brother_scanner_user }}"
            password: "{{ brother_scanner_pass }}"
        samba_shares:
          - name: consumption
            comment: 'paperless consumption directory'
            path: "{{ pnwrp_compose_dir }}/consume"
            read_only: false
            guest_ok: false
            browseable: true
            owner: "{{ pnwrp_podman_user }}"
            group: "{{ pnwrp_podman_group }}"
            write_list: +{{ pnwrp_podman_group }}

    - name: Enable samba in host firewall
      ansible.posix.firewalld:
        service: samba
        immediate: true
        permanent: true
        state: enabled
      become: true

Das Playbook gewinnt sicher keinen Schönheitswettbewerb, doch arbeitet es bisher robust und tut, was es soll. In Tests habe ich meine Wunschumgebung damit mehrmals provisioniert.

Backup & Restore

Wie es sich gehört, wird erst ein Backup erstellt, dann die Anwendung inkl. aller Daten gelöscht und wiederhergestellt.

Backup

Für das Backup verwende ich ein Ansible-Playbook, welches sich zum Podman-Host verbindet und dort folgende Aufgaben ausführt:

1. Stelle sicher, dass das Backup-Verzeichnis auf dem Remote-Host existiert
2. Stoppe alle Paperless-NGX-Container
3. Exportiere Podman-Volumes in TAR-Archive; hänge das aktuelle Datum an die Dateinamen an
4. Archiviere und komprimiere paperless-ngx-Verzeichnis auf Remote-Host; hänge das aktuelle Datum an die Dateinamen an
5. Starte alle Paperless-NGX-Container
6. Komprimiere die Exporte der Podman-Volumes
7. Synchronisiere das Backup-Verzeichnis auf dem Remote-Host mit einem Verzeichnis auf meiner Diskstation
8. Synchronisiere das Diskstation-Verzeichnis mit einem verschlüsselten S3-Bucket

Es fehlt die Aufgabe, alte Backups aufzuräumen. Darum werde ich mich kümmern, wenn 70% des verfügbaren Speicherplatzes belegt sind.

Der folgende Code-Block zeigt ein Muster des verwendeten Playbooks:

---
- name: Backup podman volumes
  hosts: host.example.com
  gather_facts: true
  vars:
    paperless_ngx_dir: /home/alice/paperless-ngx
    docker_compose_file: docker-compose.yml
    remote_backup_dir: /home/alice/backups
    diskstation_backup_dir: /home/alice/diskstation/home/backups/host.example.com

  tasks:
    - name: Ensure backup directory exists
      ansible.builtin.file:
        path: "{{ remote_backup_dir }}"
        state: directory
        owner: alice
        group: alice
        mode: 0777

    - name: Stop paperless-ngx containers
      ansible.builtin.command: >
        podman-compose -f {{ paperless_ngx_dir }}/{{ docker_compose_file }} stop

    - name: List podman volumes
      ansible.builtin.command: podman volume ls --quiet
      register: __podman_volumes
      tags:
        - volumes

    - name: Output __podman_volumes
      ansible.builtin.debug:
        msg: "{{ item }}"
      loop: "{{ __podman_volumes['stdout_lines'] }}"
      tags:
        - volumes

    - name: Export podman volumes
      ansible.builtin.command: >
        podman volume export {{ item }} --output {{ remote_backup_dir }}/{{ item }}_{{ ansible_facts['date_time']['date'] }}.tar
      loop: "{{ __podman_volumes['stdout_lines'] }}"

    - name: Compact {{ paperless_ngx_dir }}
      community.general.archive:
        path: "{{ paperless_ngx_dir }}"
        dest: "{{ remote_backup_dir }}/paperless-ngx_{{ ansible_facts['date_time']['date'] }}.tar.gz"
        format: gz

    - name: Start paperless-ngx containers
      ansible.builtin.command: >
        podman-compose -f {{ paperless_ngx_dir }}/{{ docker_compose_file }} start

    - name: Compress volume exports
      community.general.archive:
        path: "{{ remote_backup_dir }}/{{ item }}_{{ ansible_facts['date_time']['date'] }}.tar"
        format: gz
        remove: true
      loop: "{{ __podman_volumes['stdout_lines'] }}"
      tags:
        - compress

    - name: Sync backups to diskstation
      ansible.posix.synchronize:
        archive: true
        compress: false
        delete: false
        dest: "{{ diskstation_backup_dir }}"
        mode: pull
        private_key: /home/alice/.ssh/ansible_id_rsa
        src: "{{ remote_backup_dir }}/"
      delegate_to: localhost
      tags:
        - rsync

    - name: Sync backups from diskstation to contabo S3
      ansible.builtin.command: rclone sync -P ../backups/ secure:backups
      delegate_to: localhost
      tags:
        - rsync

Das Playbook wird einmal wöchentlich ausgeführt. Ob ich für die geplante Ausführung cron oder systemd timer units verwende, habe ich noch nicht entschieden. Ich tendiere aus Neugier zu letzterem.

Um ein Offsite-Backup zu haben, werden die Dateien von der Diskstation einmal wöchentlich verschlüsselt und in einen S3-Speicher synchronisiert. Ich nutze dafür das Programm rclone und S3-kompatiblen Speicher von Contabo. Die folgenden Links bieten weiterführende Informationen dazu:

• Contabo: What is S3 compatible Object Storage?
• https://rclone.org
• Contabo: rclone
• Verschlüsselung mit rclone Crypt

Restore

Der Ablaufplan für die Wiederherstellung der Anwendung mit ihren Daten sieht wie folgt aus:

1. Eine rootless-Podman-Umgebung bereitstellen
2. podman-compose bereitstellen
3. TAR-Archive auf Zielsystem übertragen
4. Paperless-NGX mit Playbook installieren
5. Alle Container stoppen
6. Inhalt der TAR-Archive in die Podman-Volumes importieren (siehe podman-volume-import(1)): gunzip -c hello.tar.gz | podman volume import myvol -
7. Alle Container starten

Fazit

Bereitstellung, Sicherung und Wiederherstellung funktionieren wie beschrieben. Damit kann ich nun beginnen und die Anwendung konfigurieren und mit meinem Papierkram füttern.

Die Samba-Freigabe habe ich ebenfalls getestet. Sie funktioniert wie erwartet. PDF-Dateien mit dem Befehl find Documents -type f -iname "*.pdf" -exec cp {} /consume \; hineinzukopieren ist übrigens besonders dann eine gute Idee, wenn man sehen möchte, welche Dateien so in den Tiefen des eigenen Dateisystems schlummern.

Vor meinem Urlaub hatte ich ein tolles YouTube-Video von Teslaundmehr gesehen, was mich dazu animierte, eine stylische Nixie Uhr selbst zu bauen. Das kleine Projekt wollte ich natürlich sofort in die Tat umsetzen. Nixie-Röhren erfreuten sich in den 1960er- und 1970er-Jahren vor allem als Ziffernanzeige in Messgeräten und elektronischen Rechenmaschinen großer Beliebtheit. Diese Röhren sind oft nur noch gebraucht erhältlich.

Auch wenn es sich hierbei um kein Open-Source Vorhaben handelt, möchte ich meine Erfahrung teilen und vielleicht den ein oder anderen zum Nachbauen animieren.

Ich habe also auf eBay nach den benötigten Nixie-Röhren IN-14 gesucht und musste feststellen, dass die Preise aufgrund der geopolitischen Lage enorm angezogen haben. Egal, ich hatte mein Projekt gefunden und gleich Röhren bei einem osteuropäischen Anbieter geordert, die dann fast einen Monat auf dem Weg zu mir waren.

Die Platine Zirrfa 5V Elektronische DIY kit in14 nixie digitale LED uhr platine kit PCBA habe ich auch, wie im Video beschrieben, bei AliExpress bestellt. Hierbei ist darauf zu achten, dass Glimmlampen für die Kommastellen der Anzeige dabei sind. Bei näherer Suche fand ich sogar ein schönes Holzgehäuse inkl. Glimmlampen, Messing-Accessoires und Metallknöpfen zur Bedienung der Uhr.

Für die Real Time Clock wurde noch eine 3V Batterie CR1220 benötigt, die ich bei Amazon bestellen konnte.

Da alle Teile erst zwei Tage vor meinem Urlaub komplett bei mir zu Hause eintrafen, musste ich die Montage auf nach dem Urlaub verschieben.

Nun ist meine Nixie-Clock allerdings fertig und das Resultat kann sich wirklich sehen lassen.

Quelle: YouTube

Fazit

Die einzelnen Komponenten waren zwar nicht gerade günstig, jedoch ist die fertige Nixie Uhr ein echter Hingucker. Mit etwas handwerklichem Geschick beim Zusammenbau und Löten kann man einen einzigartigen Retro Zeitmesser selbst bauen.

In den Zeiten der Pandemie hatte fast jeder den Drang danach, Kontakte weiter aufrecht zu erhalten und zu pflegen. Die meisten traf das Kontaktverbot völlig unvorbereitet. Das man Videokonferenzen abhalten konnte, war bekannt, aber wer nutzte so etwas schon im Alltag. Viele von uns suchten plötzlich nach Möglichkeiten sich irgendwo online zu treffen. Große Softwarekonzerne ermöglichten einem plötzlich diese Funktionen kostenlos zu nutzen, mit dem Hintergrund spätere Kunden zu gewinnen. Zwar war die Nutzung dieser Dienste kostenlos, jedoch nicht umsonst. Nutzer bezahlten für diese Art der Nothilfe mit ihren Daten.

Da ich schon lange zuvor Open-Source-Lösungen dieser Art wie Nextcloud Talk nutzte, brauchte ich nur die Leute mit denen ich mich nicht treffen konnte, dort hin einzuladen. Für kleine Gesprächsrunden eignete sich meine Nextcloud durchaus. Für eine größere Anzahl von Nutzern war dies jedoch problematisch. Deshalb suchte ich nach einer anderen Lösung.

Perfekt für reine Audio-Treffen war Mumble, welches die ganze Pandemie-Zeit auf einem meiner Server lief. Die Nutzung meines Mumble-Servers verhielt sich aber umgekehrt proportional zur Aufhebung der Kontaktbeschränkung. Reale Treffen waren wieder möglich und man traf sich weniger online. Da ich aber die Technik doch hin und wieder nutzen möchte, habe ich den Versuch gewagt, einen Mumble-Server auf einem Raspberry Pi aufzusetzen. Wie das ganze geht, zeige ich in diesem Artikel.

Installation

Als Server dient ein Raspberry Pi 4 mit 4 GB RAM. Auf diesem wurde ein Raspberry Pi OS mit 64-Bit installiert. Der Mumble-Server wird wie folgt aufgesetzt:

sudo apt install mumble-server

Während der Installation wird abgefragt, ob der Server automatisch starten soll. Diese Frage beantwortet man mit „Ja“. Danach wird abgefragt, ob der Mumble-Server mit einer höheren Priorität zu nutzen ist. Diese Frage habe ich in meinem speziellen Fall mit „Nein“ beantwortet. Danach vergibt man noch ein SuperUser-Passwort und widmet sich dann der erweiterten Konfiguration.

Konfiguration

In der Konfigurationsdatei können nun gewünschte Anpassungen vorgenommen werden, wie z.B. Begrüßungstext, Port etc. Hier habe ich aber nur ein Passwort für die Nutzung meines Server vergeben, um die Kontrolle über den Server zu behalten. Weiterhin kann hier die maximale Anzahl der Besucher festgelegt werden.

sudo nano /etc/mumble-server.ini

Damit der Server jedoch aus dem Internet erreichbar ist, muss der Raspberry Pi mit einer DynDNS verbunden sein. Hier ein Beispiel für den Hoster all-inkl.com. Weiterhin muss der Port im heimischen Router freigegeben werden. Ich nutze den voreingestellten Standard-Port „64738“. Für das Forwarding muss TCP und UDP aktiviert werden.

Sind diese Voraussetzungen erfüllt, kann der Mumble-Server gestartet werden.

sudo service mumble-server start

Client

Als Client auf dem PC und Notebook verwende ich Mumble.

Wer diesen Blog regelmäßig liest, kann den Eindruck gewinnen, es sei mein Hobby, Ansible-Rollen zu schreiben, mit denen von mir genutzte Web-Anwendungen auf Servern bereitgestellt werden können. Dieses Mal habe ich es mit Seafile getan und möchte in diesem Beitrag darüber berichten.

Was ist Seafile?

Seafile ist eine Sync&Share- bzw. Private-Cloud-Lösung ähnlich wie Nextcloud, ownCloud oder TeamDrive. Auf mich erweckt Seafile den Eindruck, als wenn der Schwerpunkt jedoch auf der Synchronisation und dem Teilen von Dateien liegt und damit genau meinem Suchmuster entspricht.

Seafile gibt es in einer Community und einer Professional Edition. Die Professional Edition darf mit bis zu drei Benutzern kostenlos verwendet werden.

Für weiterführende Informationen wird auf die Seiten des Herstellers und den Wikipedia-Artikel verwiesen.

Was ist das Ziel?

Nun, es gibt nicht das eine Ziel. Ich habe mit diesem kleinen Wochenendprojekt folgende Ziele verfolgt:

• Beschäftige dich mit Ansible.
• Beschäftige dich mit der Collection Containers.Podman.
• Beschäftige dich mit rootless Podman.
• Deploye Seafile Professional Edition in einer rootless-Podman-Umgebung, um es als Sync&Share-Lösung nutzen zu können.

Die Vorgehensweise

Zuerst habe ich mich informiert, ob es Container-Images für Seafile gibt und ob entsprechende Installationswege in der Dokumentation beschrieben sind. Meine Recherche förderte folgende Treffer zutage:

• Installation of Seafile Server Professional Edition with Docker
• Seafile with podman

Ansible-Rollen haben eine einheitliche Struktur. Mit dem Befehl ansible-galaxy role init ansible_role_deploy_seafile_with_rootless_podman habe ich das Grundgerüst für meine Rolle erstellt. Anschließend habe ich die notwendigen Dateien {defaults,meta,tasks,vars}/main.yml mit Inhalt gefüllt und nicht benötigte Verzeichnisse wie handlers gelöscht. Mir ist dabei wichtig, dass alle notwendigen Parameter über Variablen definiert werden, die in defaults/main.yml zu finden sind. In vars/main.yml befinden sich hingegen nur Variablen, welche intern von der Rolle verwendet werden und vom Benutzer nicht explizit gesetzt werden sollen. So lässt sich die Rolle leicht wiederverwenden, um verschiedene Seafile-Instanzen auf dem gleichen Host oder in unterschiedlichen Umgebungen zu deployen.

Bevor ich die Rolle zum ersten Mal auf meinen Server angewendet habe, habe ich sie mit yamllint und ansible-lint geprüft und vorhandene Warnungen und Fehler behoben. Allerdings lassen sich mit den Lint-Werkzeugen und der Option --syntax-check nicht alle Fehler im Vorfeld finden. Da mir ein zweites Augenpaar fehlte, habe ich die letzten Tippfehler erst durch die Verwendung des Ansible Playbook Debugger gefunden.

Das Ergebnis

Das Ergebnis findet ihr auf:

• Codeberg.org: Tronde/ansible_role_deploy_seafile_with_rootless_podman
• GitHub: Tronde/ansible_role_deploy_seafile_with_rootless_podman
• Ansible Galaxy: Tronde/deploy_seafile_with_rootless_podman

Unter allen drei URLs könnt ihr meine Rolle herunterladen. Es ist damit möglich, eine lauffähige Seafile Pro Instanz bereitzustellen. Ein Test auf Idempotenz und ob diese Rolle auch zur Aktualisierung einer bestehenden Umgebung genutzt werden kann, steht noch aus.

Ihr seid herzlich eingeladen, die Rolle bei Interesse zu testen. Ich freue mich über Rückmeldungen zur Rolle und Dokumentation (Readme.md).

Ich habe das Deployment bisher nur auf Debian Buster getestet. Daher freue ich mich besonders über Rückmeldungen, wenn ihr die Rolle erfolgreich auf anderen Plattformen angewendet habt. Dann kann ich die entsprechenden Angaben für Ansible Galaxy ergänzen.

Eure Rückmeldungen nehme ich in den Kommentaren zu diesem Beitrag, per E-Mail oder in meinem neuen Matrix-Kanal #my-it-brain:matrix.org entgegen.

Fragen an meine Leser*innen

Ich interessiere mich für Themen rund um Ansible und Podman und frage mich, wie dies bei euch aussieht. Daher freue ich mich, wenn ihr in den Kommentaren oder gern auch per E-Mail und Chat folgende Fragen beantworten mögt:

• Verwendet ihr Ansible für Software-Deployments?
• Kennt ihr Podman und nutzt ihr es im privaten und/oder beruflichen Umfeld?
• Findet ihr die Nutzung von Ansible zur Bereitstellung von Software auf (rootless) Podman sinnvoll? Oder bevorzugt ihr andere Bereitstellungsverfahren?

Ich freue mich auf eure Antworten.

Ende 2016 habe ich das Experiment vServer begonnen. Mein Anspruch war, so viel wie möglich für mich selbst zu hosten, wie Webseiten, Mailserver, eine eigene Cloud, aber auch Kommunikationsdienste wie Mastodon und einen XMPP-Server.

Dieses Experiment neigt sich nun dem Ende zu.

Aus gegebenem Anlass möchte ich informieren, dass es wenig Sinn macht einen neuen XMPP-Account anzulegen. Weiterhin möchte ich den Usern raten, die noch einen Zugang auf intux.de besitzen, auf einen anderen Server umzuziehen, da ich meinen XMPP-Server zeitnah abschalten werde!