Die Installation der Rolling-Release-Distribution Arch Linux übernimmt in der Regel Archinstall.

Mit OSMC setzt man schnell ein Kodi-basiertes Media-Center-System auf dem Raspberry Pi, Vero oder Apple TV auf.

Der TS101 lässt sich, wie auch der Pinecil v2, mit einem eigenen Bootlogo versehen. Beim TS101 muss das Logo der IronOS Firmwaredatei hinzugefügt werden # Arch Linux sudo pacman -S python-pillow python-intelhex git #...

Die Arch-basierte Distribution Manjaro erhält ein umfassendes Update, das auch den Cosmic Desktop zu den Anwendern bringt. Zudem wurde die Webseite generalüberholt.

Quelle

MiniOS wird seinem Namen gerecht, eine kleine Distribution, die sich gut auf einem USB-Stick für die Hosentasche eignet. Der modulare Aufbau erlaubt individuelle Anpassung.

Quelle

Dokumentenmanagement-Software sorgt dafür, dass sich die Papierflut in Grenzen hält und Dokumente schnell auffindbar sind. Paperwork und Paperless-NGX stecken das Leistungsspektrum für Heimanwender und SoHo ab.

Quelle

Ein Erfahrungsbericht über den Umstieg von PiOS Lite auf Ubuntu Server und eine einfache Anleitung zur Nutzung von Docker.

Dies ist ein Erfahrungsbericht zur Migration meiner Ansible-Rolle „Nextcloud im Container“ in eine Ansible Collection. Er umfasst die Migration der bestehenden Rolle und die Ergänzung der neuen Collection um eine weitere Rolle, welche sich um die Aufgaben Backup und Restore kümmert.

Wer es ganz eilig hat, kann direkt zur Zusammenfassung springen. Allen anderen wünsche ich viel Spaß bei der Lektüre.

Für grundlegende Informationen zu Ansible Collections siehe:

• Ansible Content Collections
• Using Ansible collections
• Developing collections

Randnotiz: Dass ihr zu meiner ersten Ansible Collection hier im Blog nicht fündig werdet, liegt darin begründet, dass meine Arbeit daran eingeschlafen ist.

Die Entwicklung der hier beschriebenen Collection könnt ihr auf Codeberg.org verfolgen. Die Repo-URL lautet: https://codeberg.org/Tronde/nextcloud

Motivation

Für mein Wochenendprojekt „Nextcloud im Container“ habe ich eine Ansible-Rolle entwickelt und auf Github veröffentlicht, die dem Zweck dient, Nextcloud mit einer MariaDB in einer rootless Podman-Umgebung zu installieren.

Wie ihr in Teil 5 der Artikel-Serie nachlesen könnt, war ich mit der Lösung für Backup und Restore nicht ganz zufrieden. Ich möchte dieses Thema erneut angehen und mithilfe einer Ansible-Rolle lösen.

Backup und Restore beschreiben jedoch andere Anwendungsfälle als die Bereitstellung, weswegen ich den dafür notwendigen Quelltext nicht mit in die bestehende Rolle pressen möchte. Da Backup und Restore für mich jedoch zum Betrieb dazugehören, möchte ich alle Ansible-Rollen, die ich zum Betrieb meines Nextcloud-Setups benötige, in einer Collection zusammenfassen.

Migration der bestehenden Rolle in eine Collection

Ich orientiere mich hierzu an der englischsprachigen Dokumentation „Migrating a role to a collection“. Da ich bereits einen Galaxy Namespace besitze, nutze ich diesen auch für die Erstellung der Collection. Der folgende Codeblock zeigt die verwendeten Befehle.

]$ ansible-galaxy collection init tronde.nextcloud
- Collection tronde.nextcloud was created successfully

]$ mkdir tronde/nextcloud/roles/deploy_nextcloud_with_mariadb_pod && rsync -a ../roles/ansible_role_deploy_nextcloud_with_mariadb_pod/ tronde/nextcloud/roles/deploy_nextcloud_with_mariadb_pod/

]$ tree -L 3 tronde/nextcloud/
tronde/nextcloud/
├── docs
├── galaxy.yml
├── meta
│   └── runtime.yml
├── plugins
│   └── README.md
├── README.md
└── roles
    └── deploy_nextcloud_with_mariadb_pod
        ├── defaults
        ├── meta
        ├── README.md
        ├── tasks
        ├── tests
        └── vars

]$ rm -rf tronde/nextcloud/roles/deploy_nextcloud_with_mariadb_pod/.git

Im letzten Schritt entferne ich das .git-Verzeichnis, da ich die Collection als Ganzes in einem Repository verwalten möchte, statt alle Rollen einzeln zu versionieren und dann in die Collection einzufügen.

Anschließend aktualisiere ich die Dateien galaxy.yml und README.md. In der Rolle habe ich ein Playbook zum Testen verwendet, welches im Pfad deploy_nextcloud_with_mariadb_pod/tests/test.yml liegt. Um konform mit der Struktur einer Ansible Collection zu sein, erstelle ich im Wurzelverzeichnis meiner Collection das Verzeichnis playbooks und kopiere das Test-Playbook hier hinein:

]$ tree playbooks/
playbooks/
└── deploy_nextcloud_with_mariadb_pod.yml

An dieser Stelle halte ich zunächst inne und überlege mir, welche Tools ich noch benötige, um meine Collection entwickeln und testen zu können.

Ansible Development Tools

Ansible Development Tools (ADT) ist ein Projekt mit dem Ziel, einen Werkzeugkasten mit allen wichtigen Werkzeugen zur Entwicklung von Ansible Content zu bieten. Genau so etwas habe ich gesucht. Das probiere ich gleich aus.

Um mir mein System nicht zu verhunzen, installiere ich die ADT in ein Python Virtual Environment und lasse mir anzeigen, welche Werkzeuge ADT mitbringt:

]$ python -m venv adt
]$ . adt/bin/activate
(adt) ]$ pip install --upgrade pip
(adt) ]$ pip install ansible-dev-tools
(adt) ]$ pip install molecule-podman
(adt) ]$ adt --version
ansible-builder                          3.1.0
ansible-core                             2.17.1
ansible-creator                          24.7.0
ansible-dev-environment                  24.7.0
ansible-dev-tools                        24.7.1
ansible-lint                             24.7.0
ansible-navigator                        24.7.0
ansible-sign                             0.1.1
molecule                                 24.7.0
pytest-ansible                           24.7.0
tox-ansible                              24.7.0

Bei molecule-podman handelt es sich um einen Molecule-Treiber, welcher benötigt wird um Molecule-Tests in Podman-Containern ausführen zu können. Ich habe dieses Paket mitinstalliert, da ich mir vorstellen kann, dies in naher Zukunft zu nutzen.

ansible-lint

Ansible Lint ist das erste Werkzeug aus der ADT-Sammlung, welches ich verwende, um den Quelltext meiner Collection zu prüfen. Dazu wird das Kommando einfach im Wurzelverzeichnis der Collection ausgeführt. Anschließend können die gefundenen Fehler behoben werden.

Da es den Rahmen dieses Artikels sprengen würde, werde ich dem Thema einen eigenen Text widmen.

molecule

Ansible Molecule eignet sich zum Testen von Ansible-Rollen und Collections. Ich nutze meine Ansible Collection, um mich mit diesem Werkzeug vertraut zu machen.

Zwar gibt es auch hier erst eine Lernkurve, doch wird mir eine durchdachte Test-Konfiguration bei der weiteren Entwicklung sicher zugutekommen. Ich orientiere mich zu Beginn am Ansible Molecule Getting Started Guide.

Zu Beginn möchte ich meine in die Collection migrierte Rolle testen. Dazu bearbeite ich die Datei tronde/nextcloud/extensions/molecule/default/converge.yml. Sie enthält schließlich folgenden Inhalt:

extensions]$ cat molecule/default/converge.yml 
---
- name: Converge
  hosts: localhost
  gather_facts: false
  tasks:
    - name: Test collection role deploy_nextcloud_with_mariadb_pod
      ansible.builtin.import_role:
        name: tronde.nextcloud.deploy_nextcloud_with_mariadb_pod

Und mit folgendem Befehl teste ich, ob meine Nextcloud-Instanz erfolgreich deployt wird:

extensions]$ molecule converge
…
PLAY RECAP *********************************************************************
localhost                  : ok=10   changed=9    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0

extensions]$ podman ps
CONTAINER ID  IMAGE                                    COMMAND               CREATED             STATUS             PORTS                    NAMES
48438d1bd884  quay.io/centos/centos:stream8            bash -c while tru...  7 minutes ago       Up 7 minutes                                instance
104c525a6b50  localhost/podman-pause:5.1.1-1717459200                        About a minute ago  Up About a minute  127.0.0.1:40671->80/tcp  e34ddf4d4203-infra
f27842b12d56  docker.io/library/mariadb:10.11.2        mariadbd              About a minute ago  Up About a minute  127.0.0.1:40671->80/tcp  nc_mariadb
9ee391a57fbd  docker.io/library/nextcloud:25-apache    apache2-foregroun...  13 seconds ago      Up 13 seconds      127.0.0.1:40671->80/tcp  nextcloud

Das Ergebnis ist positiv und kann durch Aufruf von http://127.0.0.1:40671 im Webbrowser überprüft werden. Ein Login mit den Default-Werten aus tronde/nextcloud/roles/deploy_nextcloud_with_mariadb_pod/defaults/main.yml bestätigt das erfolgreiche Deployment.

Es handelt sich hierbei noch nicht um ein adäquates Test-Setup; doch für den Moment ist es ausreichend. Ich werde mich noch weiter einarbeiten müssen, um das Test-Setup verbessern zu können. Vermutlich wird auch dazu dann ein weiterer Artikel folgen.

Falls sich jemand wundert, es ist durchaus Absicht, dass die Nextcloud nur via 127.0.0.1 und per HTTP erreichbar ist. Ich betreibe diese hinter einem Reverse-Proxy. Details können in Nextcloud im Container — Teil 3: Mit Reverse-Proxy nachgelesen werden.

Backup und Restore für die Nextcloud

Um die Konfiguration und die in der Nextcloud gespeicherten Daten sichern und wiederherstellen zu können, werde ich eine Offline-Sicherung der verwendeten Podman Volumes durchführen. Der Ablauf für die Sicherung sieht wie folgt aus:

1. Den Pod ˋnc_podˋ inkl. aller darin enthaltenen Container stoppen
2. Alle zum Setup gehörenden Podman Volumes in Tarballs exportieren
3. Diese Tarballs vom managed Node auf den Control Node sichern
4. Den ˋnc_podˋ wieder starten

Die Wiederherstellung läuft sinngemäß andersherum ab:

1. Die Tarballs werden vom Control Node auf den Managed Node kopiert
2. Der Pod ˋnc_podˋ inkl. aller darin enthaltenen Container wird gestoppt
3. Die Podman Volumes aus Schritt 1 werden importiert
4. Der nc_pod wird wieder gestartet
5. Die zur Wiederherstellung auf den Managed Node kopierten Tarballs werden wieder entfernt

Um diese neue Rolle der Collection hinzuzufügen, navigiere ich in das Rollenverzeichnis tronde/nextcloud/roles/ und erstelle dort das Grundgerüst für die Rolle: ansible-galaxy role init backup_nextcloud

Die Struktur sieht bei mir wie folgt aus, wobei nicht benötigte Verzeichnisse noch nicht entfernt wurden:

ansible_collections]$ tree -L 2 tronde/nextcloud/roles/backup_restore_nextcloud/
tronde/nextcloud/roles/backup_restore_nextcloud/
├── defaults
│   └── main.yml
├── files
├── handlers
│   └── main.yml
├── meta
│   └── main.yml
├── README.md
├── tasks
│   └── main.yml
├── templates
├── tests
│   ├── inventory
│   └── test.yml
└── vars
    └── main.yml

9 directories, 8 files

Den aktuellen Entwicklungsstand könnt ihr unter dieser URL einsehen: https://codeberg.org/Tronde/nextcloud/src/branch/main/roles/backup_restore_nextcloud

Das dortige README.md enthält wie bei dedizierten Rollen die Dokumentation zu dieser Rolle. Um doppelte Texte zu vermeiden, verweise ich im Collection-README auf die jeweiligen README-Dateien in den einzelnen Rollen.

Getestet wird diese Rolle ebenfalls mit Molecule. Zu den Tests mit Molecule werde ich noch mehr schreiben, sobald ich dies etwas verfeinert habe.

Fallen mir noch weitere Anwendungsfälle ein, können diese nun einfach als weitere Rollen der Collection hinzugefügt werden.

Ansible-Variablen definieren

Jede Rolle in dieser Collection ist für sich alleine nutzbar. Somit definiert jede Rolle die Eingangs-Variablen in der defaults/main.yml der jeweiligen Rolle.

Bei der Entwicklung achte ich darauf, dass Variablen, die z.B. den Namen eines Podman Volumes enthalten, in allen Rollen gleich geschrieben werden. Damit ist es möglich, diese Variablen an anderer Stelle zu definieren und in den verschiedenen Rollen nutzbar zu machen. So können an individuelle Deployments angepasste Variablen in Playbooks, group_vars, host_vars, etc. definiert werden.

Wo Variablen definiert werden können und welche Präzedenz diese besitzen, kann in der offiziellen Doku nachgelesen werden: Variable precedence: Where should I put a variable?

Zusammenfassung

Eine Ansible-Rolle ohne Plug-ins in eine Ansible Collection zu überführen, ist mit dem kurzen Abschnitt aus der Dokumentation schnell erledigt.

Weitere Rollen können der Collection hinzugefügt werden, indem man sie im Verzeichnis roles der Collection-Verzeichnisstruktur wie gewohnt mit ansible-galaxy role init <Rollenname> erstellt und mit Leben füllt. Sorgfalt ist und bleibt bei der Benennung von Variablen und deren Präzedenz geboten, um nicht wahnsinnig zu werden. Dies ist nicht wirklich schwierig, doch muss ich fast jedes Mal in der Dokumentation nachschlagen, um sicher zu sein.

Die Ansible Development Tools (ADT) sind eine praktische Sammlung von Werkzeugen zur Entwicklung von Rollen und Collections für Ansible. Für mich sind aktuell Ansible Lint und Ansible Molecule die wichtigsten Werkzeuge aus dieser Sammlung. Wobei gerade die Dokumentation von Molecule auf dem Weg zu meinem Ziel, nämlich meine Collections in verschiedenen rootless Podman Containern mit nested Podman und Ansible zu testen, leider viele Fragen offen lässt. Grundsätzlich lassen sich Testpläne damit realisieren und vereinfachen mein bisheriges Testsetup bestehend aus diversen Skripts und virtuellen Maschinen. Und sie bieten Stoff für weitere Einträge in diesem Blog.

Die weitere Entwicklung meiner Nextcloud Collection findet auf Codeberg statt. Ihr findet sie dort unter der URL: https://codeberg.org/Tronde/nextcloud

Haiku ist seit über 20 Jahren in der Entwicklung und verfolgt das Ziel, ein zu BeOS binär­kompatibles Open-Source-System zu schreiben. Gerade steht die Portierung von Firefox vor der Vollendung.

Quelle

Die schlanke und flexible Firewall-Distribution bietet einen erweiterten, verteilten Schutz gegen Denial-of-Service-Angriffe.

Der COSMIC Desktop von System76 ist nach zwei Jahren Entwicklung in einer ersten Alpha-Version für Tests verfügbar. Ein erster Blick verrät: Das Warten hat sich gelohnt.

Quelle

Der Wayland-Compositor Sway erhält über die Wlroots-Bibliothek Zugang zu Explicit Sync, einer Technik, die den verbliebenen Problemen mit Nvidia unter Wayland ein Ende setzen soll.

Quelle

Ein neuer adminForge Service kann ab sofort genutzt werden.

IT Tools ist eine Sammlung praktischer Online-Tools für Entwickler, mit großartiger UX.

IT Tools

IT Tools ist eine Sammlung praktischer Online-Tools für Entwickler, mit großartiger UX.

https://tools.adminforge.de

Features:

• verschiedene Generatoren
• Texte verschlüsseln
• verschiedene Konverter
• QR-Codes erstellen
• Kamera-Rekorder
• Chmod-Rechner
• Docker run zu Docker compose Konverter
• IPv4-Subnetzrechner
• Emoji-Picker
• und vieles mehr …

Software: IT Tools

Euer adminForge Team

Das Betreiben der Dienste, Webseite und Server machen wir gerne, kostet aber leider auch Geld. Unterstütze unsere Arbeit mit einer Spende und diskutiere in unserem Chat mit.

by adminForge.

Vor einigen Wochen habe ich um Empfehlungen für Laptop-Hardware, eine Linux-Distribution und eine Desktopumgebung gebeten. Für die vielen Rückmeldungen, die ich erhalten habe, an dieser Stelle vielen Dank.

Heute möchte ich euch wissen lassen, welche Kombination es geworden ist.

Die Hardware

Ich habe mich für ein wiederaufbereitetes Lenovo T570 entschieden, welches für günstige 240 Euro im Onlinehandel verfügbar war. Da war dann auch noch für 30 Euro ein Schutzbrief drin, der Flüssigkeiten und Stürze abdeckt.

Mit dem Intel Core-i5 der 6. Generation, 8 GB RAM und einer 256 GB SSD bietet dieses Gerät mehr als ausreichend Leistung.

Das Gerät weist einige Gebrauchsspuren auf. Den Preis empfinde ich dennoch günstig, da Geräte dieser Klasse nicht unter 1.000 Euro Neupreis zu bekommen sind. Viel wichtiger jedoch ist, dass der Nutzer sich ebenfalls über das Gerät freut.

Linux-Distribution und Desktopumgebung

Wer die Wahl hat, hat die Qual. Um mir einen ersten Eindruck zu verschaffen, habe ich mir einen USB-Stick mit Ventoy und einer Auswahl an verschiedenen Linux-Distributionen erstellt. So konnte ich die verschiedenen Live-Systeme booten und prüfen, ob alles funktioniert und wie es sich in der Oberfläche navigieren lässt.

Schlussendlich habe ich mich für Debian Cinnamon entschieden. Dies machte nach dem ersten kurzen Test insgesamt den besten Eindruck. Firefox, Thunderbird, Bookmarks, Desktop-Verknüpfungen und Zoom-Client waren schnell eingerichtet und das Gerät bereit zur Übergabe.

Die Übergabe ist erfolgt

Mit der Übergabe gab es eine kurze Einweisung in das Gerät:

• Wo schließt man das Netzteil an
• Wo schaltet man das Gerät ein
• Wie meldet man sich an
• Wo findet man die Programme inkl. Tests aller wichtigen Dienste
• Druck eines Anhangs aus Thunderbird
• Wie fährt man das Gerät herunter

So reibungslos hat das bisher noch nie geklappt. Die Nutzungserfahrung ist positiv. Wir freuen uns.

Ende 2021 bin ich von einem Raspberry Pi 4 mit 4 GB auf einen Intel NUC7PJYH mit Proxmox VE umgestiegen. Hauptgrund damals war, dass bei mir das Upgrade von Raspberry Pi OS 10 auf...

Ikey Doherty ist kein Unbekannter in der Linux-Szene. Er zeichnet unter anderem für Solus Os und den Budgie-Desktop verantwortlich. Jetzt stellt er nach vier Jahren Entwicklung sein von Grund auf gebautes Betriebssystem Serpent OS vor.

Quelle

Für viele Beteiligte in Projekten im Bereich Freier Software und Open Source sind Konferenzen das Salz in der Suppe. In zwei Wochen bietet die FrOSCon wieder Gelegenheit zu Hacking und Socializing.

Quelle

Das Crowdfunding für das neue SBC des US-amerikanischen Unternehmens Particle begann heute auf Kickstarter. Die gut ausgestattete Platine ist mit dem Raspberry-Pi-Ökosystem kompatibel und bietet Ubuntu 24.04 als Standard-Distribution.

Quelle

Lange hat es gedauert, nach über einem Jahr intensiver Entwicklung ist sie nun da, die stabile Version 2.0 von Vanilla

Quelle

Vor einiger Zeit habe ich beschlossen eine Serie von Artikeln zum Thema Nextcloud auf dem RasPi auf meinem Blog intux.de zu veröffentlichen. Ziel ist es, eine eigene Cloud zu erstellen, die produktiv nutzbar ist. Diese soll später über das Internet erreichbar sein.

Was benötigt man dafür?

Um langfristig sicherzustellen, dass alles funktioniert, empfehle ich, die neueste Hardware zu verwenden, wie den Raspberry Pi 5. Allerdings würde hier auch ein Einplatinencomputer der vorherigen Generation mit 4GB RAM ausreichen.

Vorbereitung

Diese kleine Anleitung soll helfen, das Projekt Nextcloud auf dem Raspberry Pi nicht nur umzusetzen, sondern auch besser zu verstehen. Der Schwerpunkt liegt dabei auf der Software und der Konfiguration. So können später auftretende Fehler besser lokalisiert und abgestellt werden.

Der Raspberry Pi wird als LAMP-Server (Linux, Apache, MariaDB, PHP) dienen, die Nextcloud zu betreiben. Wie man diese vier Bausteine aufsetzt, zeige ich im folgenden Abschnitt.

Installation

Der erste Baustein der installiert wird, ist Linux. Hierbei handelt es sich um das Betriebssystem Raspberry Pi OS. Dieses spielt man ganz einfach mit dem Raspberry Pi Imager auf die MicroSD.

Hier wählt man (siehe Screenshot) das zu installierende Betriebssystem aus. In diesem Fall ist es das Raspberry Pi OS (64-bit). Im Imager können vorab einige Einstellungen vorgenommen werden. Ich werde in dieser Anleitung einfache Bezeichnungen und Passwörter verwenden. Diese können während der Installation entsprechend frei angepasst werden!

Über das Zahnrad des Imagers lässt sich das Raspberry Pi OS vorkonfigurieren. Hier trägt man für den Anfang die entsprechenden Daten ein:

Danach wählt man am PC/Notebook die MicroSD aus, auf die geschrieben werden soll.

Zum Schluss werden die Daten auf die MicroSD geflasht. Ist dies erledigt, kann die Karte ausgeworfen und in den vorbereiteten Raspbberry Pi (Kühlkörper, Gehäuse, Lüfter) geschoben werden. Dieser wird dann via LAN-Kabel mit dem heimischen Router verbunden und über das Netzteil mit Strom versorgt.

Natürlich könnte der RasPi auch via WLAN mit dem Router kommunizieren. Hiervon rate ich jedoch ab, da über die Funkverbindung oft nicht die volle Geschwindigkeit einer Ethernet-Verbindung genutzt werden kann. Weiterhin kann es zu Verbindungsabbrüchen bzw. -lücken kommen.

Nachdem der Raspberry Pi mit Strom versorgt wird, startet dieser. Ist der Raspberry Pi hochgefahren, kann dieser via arp-scan vom PC/Notebook im Netzwerk lokalisiert werden. In meinem Fall hat er die IP-Adresse 192.168.178.136.

sudo apt install arp-scan
sudo arp-scan -l

Zugriff auf den Pi erhalte ich nun via zuvor im Imager aktiviertem SSH-Zugang.

ssh Benutzer@IP-Adresse

Ist man eingeloggt, empfiehlt es sich die Lokalisierung über raspi-config auf deutsch (siehe Screenshots) umzustellen. Damit wird Datum und Uhrzeit des Servers an die europäische Zeitzone (Berlin) angepasst.

sudo raspi-config

Nun wählt man de_DE.UTF-8 UTF-8 aus und deaktiviert en_GB.UTF-8 UTF-8. Die deutsche Lokalisierung wird abschließend noch bestätigt.

Danach wird der Raspberry Pi mit

sudo reboot

neu gestartet. Ist dies geschehen, empfiehlt es sich, das OS zu aktualisieren.

sudo apt update && sudo apt upgrade -y

Danach werden die noch fehlenden 3 Bausteine (Apache 2, MariaDB und PHP) nachinstalliert.

sudo apt install apache2 mariadb-server php php-mysql php-zip php-gd php-json php-curl php-mbstring php-intl php-imagick php-xml php-dom php-bcmath -y

Nachdem die Installation durchgelaufen ist, kann man zum Testen den Webserver Apache via Browser über die Web-Adresse http://ip erreichen.

Anschließend wird die von der Nextcloud benötigte Datenbank installiert. Zuerst wird jedoch die mysql_secure_installation durchgeführt. Ich empfehle hier das Ganze gemäß meinen Empfehlungen (Enter, n, n, y, y, y, y) zu durchlaufen. Hierbei wird für den MariaDB-Server kein separates Root-Passwort vergeben, der anonyme User wird gelöscht, die Remote-Root-Anmeldung wird verboten, die Test-DB wird gelöscht und die Änderungen ausgeführt.

sudo mysql_secure_installation

Nachdem dieser Schritt durchgeführt wurde, kann über folgenden Befehl die Datenbank erstellt werden.

sudo mysql -u root -p

In meinem Fall heißen die Datenbank und der Benutzer „nextcloud“. Die Datenbank liegt dann auf dem „localhost“.

> CREATE DATABASE nextcloud;
> CREATE USER 'nextcloud'@'localhost' IDENTIFIED BY 'geheim';
> GRANT ALL ON nextcloud.* TO 'nextcloud'@'localhost';
> FLUSH PRIVILEGES;
> \q

Im Nachgang wechselt man in das Verzeichnis /var/www/html, wo die Nextcloud installiert wird. Die letzte Version wird vom Entwickler herunter geladen und entpackt. Danach wird die nicht mehr benötigte Zip-Datei wieder gelöscht und die Rechte der Dateien an den Benutzer www-data übertragen.

cd /var/www/html
sudo wget https://download.nextcloud.com/server/releases/latest.zip
sudo unzip *.zip
sudo rm *.zip
sudo chown -R www-data:www-data /var/www/html/nextcloud

Nun ist die Nextcloud über http://ip/nextcloud (http://102.168.178.136/nextcloud) erreichbar. Man legt den Admin fest und trägt die Daten der zuvor erstellten MariaDB-Datenbank in die Eingabemaske ein. Hat das alles geklappt, dann dauert die Einrichtung ein paar Minuten und die Nextcloud steht bereit zum ersten Login des neuen Administrators.

Vorschau

Im nächsten Teil zeige ich, wie man die App Collabora Online – Built-in CODE Server (ARM64) in der Nextcloud via Terminal installiert.

Viel Spaß!

Murena arbeitet beständig an der Verbesserung seines mobilen Betriebssystems /e/OS. Mit v2.2 haben Eltern mit Parental Control jetzt ein Werkzeug zur Kontrolle der Surf-Zeiten der Kinder zur Hand.

Quelle

In diesem Überblick beschreibe ich am Beispiel der Proxmox inventory source, wie eine eigene Inventory Source im Ansible Automation Controller hinzugefügt werden kann.

Die folgenden Schritte wurden mit der Ansible Automation Platform 2.4 getestet. Die einzelnen Schritte sollten in gleicher Weise auch in Ansible AWX ausgeführt werden können.

Um diesem Text folgen zu können, werden Kenntnisse im Umgang mit Ansible und Git auf der Kommandozeile vorausgesetzt.

Der Text verweist, wo möglich, auf bestehende Dokumentation. Es handelt sich bei diesem Text nicht um ein klassisches Tutorial. Er dient mir als Gedächtnisstütze und mag euch eine Anregung sein, bzw. im besten Fall die Wissenslücken schließen, die sich mit der Dokumentation allein nicht schließen lassen.

Ausgangssituation

Abschnitt 18.4.5.1. Inventory sources im Automation Controller User Guide führt die in der Ansible Automation Platform (AAP) unterstützten Inventory Sources auf. Möchte man nun bspw. Proxmox Virtual Environment (PVE), Microsoft Active Directory oder Cisco DNA Center als Quelle für sein Inventar benutzen, wird man auf den ersten Blick nicht fündig.

Für das Beispiel in diesem Text werden Hosts aus der Bestandsliste eines PVE als Inventory Source hinzugefügt. Die dabei verwendete Vorgehensweise kann auch für andere Inventory Plugins verwendet werden. Die Entwicklung von Inventory Plugins ist jedoch nicht Gegenstand dieses Textes. Hierzu wird auf die Dokumentation unter „Developing dynamic inventory“ verwiesen.

Mein Kollege Steffen Scheib hat mir geholfen, das Proxmox-Plugin zu konfigurieren, wofür ich ihm an dieser Stelle nochmal ganz herzlich danke. Es liegt auf meiner Arbeitsstation als Ansible Project in folgender Verzeichnisstruktur vor:

]$ tree proxmox_inventory/
proxmox_inventory/
├── collections
│   └── requirements.yml
├── inventory
│   └── inventory.proxmox.yml
└── vault_password_file

3 directories, 3 files

Mit Ausnahme der Datei vault_password_file wurden alle Dateien und Verzeichnisse in Git aufgenommen. Ich verwende einen einfachen Git-Server in meiner Laborumgebung, auf welchen ich meine lokalen Repositorys pushe. Der Automation Controller synchronisiert das Projekt aus dem Git-Repo, um es als Inventory Source verfügbar zu machen.

Die Vorgehensweise im Überblick

1. Ansible Credential für Source Control erstellen
2. Ein Ansible Projekt hinzufügen
3. Einen Custom Credential Type erstellen
4. Ein Ansible Inventory hinzufügen

Ansible Credential für Source Control erstellen

Das Proxmox Inventory Plugin befindet sich in einem Git-Repository, auf welches mit SSH-Key-Authentifizierung zugegriffen werden kann. Damit auch der Automation Controller auf dieses Repository zugreifen kann, wird ein Credential vom Typ Source Control erstellt.

Der SSH-Private-Key wurde von meinem Host hochgeladen und verschlüsselt im Automation Controller gespeichert. Der Key lässt sich in der GUI nicht wieder sichtbar machen, lediglich ersetzen.

Ein Ansible Projekt hinzufügen

Der Dokumentation folgend, wird ein Projekt hinzugefügt:

Wenn alles passt, wird das Projekt nach dem Speichern erfolgreich synchronisiert:

Dieses Projekt wird in einem späteren Schritt zur Erstellung des Inventory benötigt.

Einen Custom Credential Type erstellen

Bevor ich auf die Erstellung selbst eingehe, möchte ich kurz beschreiben, warum dieser Schritt notwendig ist.

Folgender Codeblock zeigt meine Datei inventory.proxmox.yml welche einige mit Ansible Vault verschlüsselte Werte enthält:

]$ cat inventory/inventory.proxmox.yml 
---
plugin: 'community.general.proxmox'
url: 'https://pve.example.com'
user: !vault |
          $ANSIBLE_VAULT;1.1;AES256
          30623661316338386633623162303036346562346238386162633263636164636338393532613565
          3332616265353962326139363533313261623739643765640a623032613034613139653162356266
          34646464323233313964663939643631313539353736313364333433643136306632633065633664
          3234346635396563350a656334353632643830353534386636306365656261356436613662623163
          31663535363264356537336531393731633164613733316537383433653334643433
token_id: !vault |
          $ANSIBLE_VAULT;1.1;AES256
          62356662336534646661353666356263363734666231643932393430336639363032303266636432
          3762343235633335613663393838343532326230353130380a616161313830373265306137346562
          61613662333764393565316362623838633332376366373161646237363163663039613863393439
          3165616664626633390a396465343430373837343662373634653634643138613131633034306432
          62623438366166353765366339323263393833396133653866343833663335663766
token_secret: !vault |
          $ANSIBLE_VAULT;1.1;AES256
          66386338643463373837666164396332306261366634396630306430663937613963346164636433
          3362396566343932393234353439383932316436396437380a336365393038373566383534623136
          30353332383464356664393666383664636536666531663463623232353136353636363366653431
          3234616531623537630a393530643437376363653438643036636436316636616265316361623661
          35313832613063633662363531346164306638373538393164373663633335333863646430663232
          6339343164633865636239356538326438333937366134613738

validate_certs: false

# fail if a variable is not resolvable
strict: true

# facts are required to retrieve proxmox_vmtype
want_facts: true

# only allow qemu VMs
filters:
  - "proxmox_vmtype == 'qemu'"

Auf der Kommandozeile meines Hosts kann ich den Inhalt des Dynamic Inventory wie folgt anzeigen lassen:

ansible-inventory -i inventory/inventory.proxmox.yml --list --vault-password-file vault_password_file

Die Datei vault_password_file befindet sich jedoch nicht im Git, da sie das Passwort im Klartext enthält. Aus diesem Grund möchte ich die Datei auch nicht auf dem Automation Controller ablegen. Irgendwie müssen auf dem Automation Controller jedoch Credentials hinterlegt werden, um die Ansible Vault encrypted_strings zu entschlüsseln. Die Lösung steckt in diesem Kommentar auf Github. Im Automation Controller User Guide gibt es dazu Chapter 11. Custom credential types.

Fertig sieht das dann so aus:

Das Schlüssel-Wert-Paar secret: true stellt sicher, dass das Passwort verschlüsselt gespeichert wird. Es kann danach im Automation Controller nicht mehr im Klartext angezeigt werden. Nachdem der neue Credential Typ erstellt ist, kann dieser instanziiert werden:

Das Vault Passwort wird in das entsprechende Formularfeld kopiert. Es ist standardmäßig nicht sichtbar und wird wie oben bereits erwähnt, verschlüsselt gespeichert. Mit diesem Credential verfügt der Automation Controller nun über die notwendigen Informationen, um das Proxmox Inventory auszulesen.

Ein Ansible Inventory hinzufügen

Zuerst wird ein Inventory nach Dokumentation erstellt. Anschließend wird diesem eine Inventory Source hinzugefügt.

Die Formularfelder sind dabei wie folgt zu befüllen:

• Name: Kann frei vergeben werden
• Source: Sourced from a Project
• Credential: Hier wird das im vorangegangenen Schritt erstellte Credential ausgewählt
• Project: Hier wird das in obigen Abschnitt erstellte Projekt ausgewählt
• Inventory file: Kann in diesem Fall auf `/ (project root)` gesetzt werden

Nach dem Speichern wird die Inventory Source durch Klick auf ‚Sync‘ synchronisiert:

Und wir haben 17 Hosts in unserem Inventory:

Damit endet dieser kurze Überblick auch schon. Ich wünsche euch viel Freude bei der Inventarpflege.

Die Fotoverwaltung Immich als freie Alternative zu Google Photos hat ein neues Unterstützungsmodell zur Finanzierung der weiteren Entwicklung vorgestellt. Die Software bleibt aber weiterhin in vollem Umfang frei nutzbar.

Quelle

Das mit Firefox 128 und der „Privacy Preserving Attribution“ (PPA) Funktion dürften die meisten mitbekommen haben. Ich zeige euch in diesen Beitrag, wie ihr die PPA Funktion unter Linux, Windows, macOS und Android deaktivieren...

Ein neuer adminForge Service kann ab sofort genutzt werden.

Redlib ist ein datenschutzorientiertes und quelloffenes Frontend für Reddit.

Redlib

Redlib ist ein datenschutzorientiertes und quelloffenes Frontend für Reddit.

https://reddit.adminforge.de

Features:

🚀 Schnell: geschrieben in Rust für blitzschnelle Geschwindigkeit und Speichersicherheit
☁️ Leicht: kein JavaScript, keine Werbung, kein Tracking, keine Aufblähung
🕵 Privat: alle Anfragen werden über den Server geleitet, einschließlich Medien
🔒 Sicher: starke Content Security Policy verhindert Browser-Anfragen an Reddit

Browser Addons:

Mit dieser Erweiterung könnt ihr sämtlichen Reddit Traffic in eurem Browser auf eine Redlib Instanz umleiten.

Firefox: LibRedirect
Chrome: LibRedirect

Software: Redlib

Euer adminForge Team

Das Betreiben der Dienste, Webseite und Server machen wir gerne, kostet aber leider auch Geld. Unterstütze unsere Arbeit mit einer Spende und diskutiere in unserem Chat mit.

by adminForge.