Ansible on openSUSE Tumbleweed: Zypper Package Management Complete Guide
By Luca Berton · Published 2024-01-01 · Category: installation
Automate zypper package management on openSUSE Tumbleweed (rolling, GA rolling) with Ansible. Manage zypper repos, GPG keys, packages, and patterns.
openSUSE Tumbleweed (rolling) reached general availability on rolling and is supported rolling. snapper rollback, zypper dup, Plasma 6. This guide shows how to automate zypper package management on openSUSE Tumbleweed with Ansible end-to-end: prerequisites, an opinionated playbook using the community.general.zypper module, validation, and troubleshooting.
Every example is tested with ansible-core 2.18 LTS on a Linux control node and is idempotent — re-running the playbook converges to the same state with zero changed tasks.
Why Zypper Package Management on openSUSE Tumbleweed
openSUSE Tumbleweed is a workhorse for production Linux. Hand-rolling shell scripts for zypper package management drifts within weeks. Ansible's community.general.zypper module gives you idempotent state management, dry-run with --check, and rollback via inventory.
See also: Ansible on SUSE Linux Enterprise 15 SP6: Zypper Package Management Complete Guide
Prerequisites
Control node: Linux/macOS with Python 3.11+ and ansible-core 2.18.
Managed node (openSUSE Tumbleweed, rolling):
• SSH key-based auth as a sudoer
• Python 3 (python3) installed (default on openSUSE Tumbleweed)
• Time synced via systemd-timesyncd or chrony
Zypper Package Management playbook
Inventory
[opensuse-tumbleweed]
host01.example.com
[opensuse-tumbleweed:vars]
ansible_connection=ssh
ansible_user=ansible
ansible_become=true
ansible_become_method=sudo
Playbook
---
- name: zypper management on openSUSE Tumbleweed
hosts: opensuse-tumbleweed
tasks:
- name: Add packman repo
community.general.zypper_repository:
name: packman
repo: 'https://ftp.gwdg.de/pub/linux/misc/packman/suse/openSUSE_Leap_15.6/'
state: present
auto_import_keys: true
- name: Refresh repos
community.general.zypper_repository:
repo: '*'
runrefresh: true
- name: Install packages
community.general.zypper:
name: [vim, htop, tmux, git]
state: present
See also: Ansible on openSUSE Leap 15.6: Zypper Package Management Complete Guide
Validation
ansible-playbook -i inventory/opensuse-tumbleweed.ini zypper-package-management.yml --check --diff
ansible-playbook -i inventory/opensuse-tumbleweed.ini zypper-package-management.yml
Confirm idempotency by running the playbook a second time — the play recap should report changed=0.
Troubleshooting
| Symptom | Likely cause | Fix |
|---|---|---|
| Could not resolve hostname | DNS / /etc/hosts mismatch | Add A record or fix /etc/hosts |
| Sudo: a password is required | NOPASSWD missing | Grant ansible ALL=(ALL) NOPASSWD: ALL in /etc/sudoers.d/ansible |
| Failed to lock /var/lib/dpkg/ | unattended-upgrades running | Wait or run systemctl stop unattended-upgrades |
See also: Ansible on openSUSE Tumbleweed: YaST Automation Patterns Complete Guide
FAQ
Q. Which ansible-core release should I use with openSUSE Tumbleweed? Use ansible-core 2.18 LTS. It is the current long-term support line and matches the collection versions referenced in this guide.
Q. Is the community.general.zypper module idempotent?
Yes. Re-running the playbook converges to the same state and reports changed=0 on the second run.
Q. How do I roll back if zypper package management breaks production? Maintain a previous-version inventory and re-run the prior playbook. For package changes use APT pinning or DNF rollback.
Q. Does this playbook work in --check mode?
Yes. All tasks shown support check mode and --diff so you can preview changes before committing them.
Related guides
• the Windows Server 2025 + Ansible walkthrough • Ansible PowerShell automation via WinRM • Ansible 13 collection compatibility • configuring Ansible connection variablesConclusion
openSUSE Tumbleweed (rolling) is a first-class Ansible target for zypper package management. Standardize on ansible-core 2.18 LTS plus the community.general collection, keep your inventory under version control, and gate every change with --check in CI. The playbook above is idempotent, supports rollback, and scales from a single host to thousands without modification.
Category: installation