Ansible on openSUSE Leap 15.6: Zypper Package Management Complete Guide

openSUSE Leap 15.6 (Linux 6.4) reached general availability on 2024-06-12 and is supported 2025-12 (final Leap before SLFO). Last classic Leap; Adaptable Linux Platform succession. This guide shows how to automate zypper package management on openSUSE Leap 15.6 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 Leap 15.6

openSUSE Leap 15.6 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 Leap 15.6, Linux 6.4): • SSH key-based auth as a sudoer • Python 3 (python3) installed (default on openSUSE Leap 15.6) • Time synced via systemd-timesyncd or chrony

Zypper Package Management playbook

Inventory

[opensuse-leap-15-6]
host01.example.com
[opensuse-leap-15-6:vars]
ansible_connection=ssh
ansible_user=ansible
ansible_become=true
ansible_become_method=sudo

Playbook

---
- name: zypper management on openSUSE Leap 15.6
  hosts: opensuse-leap-15-6
  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 Tumbleweed: Zypper Package Management Complete Guide

Validation

ansible-playbook -i inventory/opensuse-leap-15-6.ini zypper-package-management.yml --check --diff
ansible-playbook -i inventory/opensuse-leap-15-6.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 Leap 15.6: YaST Automation Patterns Complete Guide

FAQ

Q. Which ansible-core release should I use with openSUSE Leap 15.6? 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

• Ansible support for Windows Server 2025 • WinRM listener configuration for Ansible • Ansible 13 upgrade guide: breaking changes ansible-core 2.20 migration • when to use local vs SSH in Ansible

Conclusion

openSUSE Leap 15.6 (Linux 6.4) 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.