mastodontech.de ist einer von vielen unabhängigen Mastodon-Servern, mit dem du dich im Fediverse beteiligen kannst.
Offen für alle (über 16) und bereitgestellt von Markus'Blog

Serverstatistik:

1,4 Tsd.
aktive Profile

#ansible

14 Beiträge14 Beteiligte1 Beitrag heute

Oh please!!!!

I wanted to add a smoke-test/integration test for my Ansible FreeBSD connection plugin against a test-server and the GitHub Actions don't support outgoing IPv6 in 2025?! WTF!

Tempted to move my remaining stuff off of GitHub and migrate my CI/CD to @Codeberg Woodpecker

I refuse to use IPv4 for that, just because of GitHub.

#ipv6#github#legacy
Fortgeführter Thread

So, der Kollege und ich haben diese Woche reihenweise uralte Server abgeschaltet, andere Server gepatcht, Schutzmechanismen hochgezogen etc.

OpenVAS scannt über das Wochenende nach Sicherheitslücken und wir erwarten, dass das Ergebnis am Montag eeetwas weniger rot ist 🙄

Automatisches Installieren von Updates, Konfiguration von SELinux, lokalen Firewalls etc. habe ich per Ansible auf dem Schirm.

Proxmox fully automated! From ClickOps to Code: Automated. Audited. Revisioned. Repeatable.

Starting from the base by automating:
- Cluster initialization
- Cluster join
- Storage Integration
- Proxmox Backup Server Integration
- SDN Networks (different ones for pros/dev)
- Guest Resources utilizing the cluster infrastructure

#Proxmox #PVE #Pbs #ProxmoxBackupServer #opensource #Automation #Ansible #python #devops #terraform #cicd #pipeline #cluster #nfs #iscsi

peertube.gyptazy.com/w/4cp7ddL

🚀 IT‑Spezialist:in für digitale Langzeitverfügbarkeit gesucht!
Das Zuse‑Institut Berlin (ZIB) sucht Unterstützung für das digitale Langzeitarchiv „EWIG“. Du arbeitest mit #OpenSource Tools wie Archivematica an Archivierungs‑Workflows, CI/CD, Deployment, Monitoring und Datenkuratierung.
🔧 Techstack: #Python, #Linux, Container, idealerweise #Ansible & CI/CD-Tools
📍 Vollzeit · befristet (3 Jahre) · EG 12 TV‑L · Berlin
📅 Bewerbung bis 31.08.2025
👉 zib.de/jobadvertisement/1725-i

I build a custom #Ansible facts module which works fine when I add something like this to ansible.cfg:
facts_modules = smart,name_of_my_custom_fact_module
However this module makes sense for a certain role only.
Is there a way to limit calling this module to a certain role?

For admins who speak YAML like a native: Passbolt’s Ansible playbook documentation is available.

This installation method is recommended for experienced users proficient with Ansible and requires a clean Debian 12 or Red Hat 9 server.

Full step-by-step guide here → passbolt.com/docs/hosting/inst

GitHub repo → github.com/passbolt/passbolt-a

www.passbolt.comInstall Passbolt with an Ansible playbook | Passbolt documentation.PRO
Fortgeführter Thread

I mentioned recently that the configurability of {{ ansible_managed }} is being removed for #ansible 2.23. The reasoning appears to be “can be set in an inventory or other vars source”.

Anybody have any clever ideas on how to accomplish template filename modification time without prior invocation of a module or two, preferably also without having to create a custom lookup/filter plugin? (The template filename is in {{ template_path }}, {{ template_uid }} )

I’m out of ideas.

2/2

When we originally invented #ansible’s “ansible_managed” variable, we made it configurable. Before the default was broken a few years ago, it was roughly:

ansible_managed = Ansible managed: {file} modified on %Y-%m-%d %H:%M:%S by {uid} on {host}

One of the cool bits (I say this as its inventor) was that such an entry in an ansible.cfg caused the templated value to have the filename of the template source {file}, it’s owner {uid}, and it’s modification time in the strftime() patterns.

1/2

Fortgeführter Thread

Actually on the topic of feature flags, I'm curious if they exist/what people are doing at the infra / #IaC / #GitOps level.

At one point I was thinking "can I hookup like launchdarkly into #Puppet's Hiera" to handle phased rollouts of things.

More recently, want the same thing for my #FluxCD stuff. Higher level than like Flagger I think, as in gradual rollout of Deployments over many clusters, than gradual rollout of Pod within a deployment.

Kinda like #Ansible's strategies and it's "max_fail_percentage" where it'll halt.

Ever wondered which SSH keys are lurking on your servers?

Just published a comprehensive Ansible playbook in my gists that audits your entire infrastructure for SSH keys and finds dangerous unprotected private keys!

- Detects unprotected private keys
- Lists all Pubkeys for root and users
- Comprehensive reporting (TXT + CSV)

codeberg.org/Larvitz/gists/src

Zusammenfassungskarte des Repositorys Larvitz/gists
Codeberg.orggists/2025/20250804-SSHKeyAuditPlaybook.md an maingists - Just some gists in Markdown, I wanted to share
#ansible#devops#security