The situation of maintained ansible roles for boring server stuff like setting up a LEMP stack (Linux, nginx, mariadb, php) is dire and I would like to improve that. This project is about creating a handful of ansible roles with focus on
- Fully supported in openSUSE (Leap and Tumbleweed)
- Configurable to fit a basic setup but not more
- Automated testing of the deployment
- If possible support all SLE variants (SLE > 15)
- If possible support support for Debian, Ubuntu + RHEL, this is secondary though
Wishlist of roles I want to create
- LEMP stack (Linux, nginx, mariadb, php)
- LAMP stack (Linux, apache, mariadb, php)
- PXE Boot server
- Simple standalone mail server (postfix + dovecot)
- Perhaps a openQA installation role, analog to the bootstrapping bash script
Looking for hackers with the skills:
This project is part of:
Hack Week 20
Activity
Comments
-
almost 5 years ago by pagarcia | Reply
Why not Salt? https://www.uyuni-project.org/uyuni-docs/uyuni/salt/formulas-custom.html
In fact, why not go the extra mile and implement an Uyuni Cluster Provider (which is a Salt module and a one YAML file for the UI) to Uyuni? https://github.com/uyuni-project/uyuni/wiki/Cluster-Provider-development
BTW: Uyuni already provides a formula to deploy a PXE boot server with Salt. It can be used with Salt alone too: https://github.com/SUSE/salt-formulas/tree/master/pxe-formula
-
almost 5 years ago by ph03nix | Reply
The reason I still prefer ansible over salt is that I hadn't any good experiences with agentless salt, which is 100% the use case I'm aiming for.
However feel free to take that project. I'm sure, that to give people the choice to choose between
ansibleandsaltis definitely of value to the openSUSE and SUSE communities!
-
-
almost 5 years ago by ybonatakis | Reply
i am also in favor of ansible. it is more simple and clear IMO.
-
over 4 years ago by ph03nix | Reply
As part of the work, I had to build a custom openSUSE Leap container that allows me to test the Ansible roles.
I've wrote a blog post about creating a custom openSUSE Leap container
-
-
-
over 4 years ago by ph03nix | Reply
As finalizing touch, I've created https://geekoops.github.io/ and a rich webserver example there
-
over 4 years ago by nicoladm | Reply
Nice one! we can probably add these roles (or any new ones!) to this project i created https://github.com/gnuninu/kwinble the aim there is to build a desired image with kiwi and the run ansible with roles to get a running VM (or multiple) which reflects the selected roles. For libvirt it should also support multiple kvm hosts....and looking also for a way to integrate cloud platform like Azure, AWS (in that case probably terraform, pulumi is the better option but code base and the dependencies grow proportionally)
-
-
-
Reply to ph03nix
The reason I still prefer ansible over salt is that I hadn't any good experiences with agentless salt, which is 100% the use case I'm aiming for.
However feel free to take that project. I'm sure, that to give people the choice to choose between ansible and salt is definitely of value to the openSUSE and SUSE communities!
# A First Level Header ## A Second Level Header Use one asterisk to *emphasize* Use two asterisks for **strong emphasis** - Use hyphens - for unordereed - lists This is an [link to example.com](http://example.com/) This is an image  This is a user link @hans This is a project link hw#some-cool-title
Similar Projects
mgr-ansible-ssh - Intelligent, Lightweight CLI for Distributed Remote Execution by deve5h
Description
By the end of Hack Week, the target will be to deliver a minimal functional version 1 (MVP) of a custom command-line tool named mgr-ansible-ssh (a unified wrapper for BOTH ad-hoc shell & playbooks) that allows operators to:
- Execute arbitrary shell commands on thousand of remote machines simultaneously using Ansible Runner with artifacts saved locally.
- Pass runtime options such as inventory file, remote command string/ playbook execution, parallel forks, limits, dry-run mode, or no-std-ansible-output.
- Leverage existing SSH trust relationships without additional setup.
- Provide a clean, intuitive CLI interface with --help for ease of use. It should provide consistent UX & CI-friendly interface.
- Establish a foundation that can later be extended with advanced features such as logging, grouping, interactive shell mode, safe-command checks, and parallel execution tuning.
The MVP should enable day-to-day operations to efficiently target thousands of machines with a single, consistent interface.
Goals
Primary Goals (MVP):
Build a functional CLI tool (mgr-ansible-ssh) capable of executing shell commands on multiple remote hosts using Ansible Runner. Test the tool across a large distributed environment (1000+ machines) to validate its performance and reliability.
Looking forward to significantly reducing the zypper deployment time across all 351 RMT VM servers in our MLM cluster by eliminating the dependency on the taskomatic service, bringing execution down to a fraction of the current duration. The tool should also support multiple runtime flags, such as:
mgr-ansible-ssh: Remote command execution wrapper using Ansible Runner
Usage: mgr-ansible-ssh [--help] [--version] [--inventory INVENTORY]
[--run RUN] [--playbook PLAYBOOK] [--limit LIMIT]
[--forks FORKS] [--dry-run] [--no-ansible-output]
Required Arguments
--inventory, -i Path to Ansible inventory file to use
Any One of the Arguments Is Required
--run, -r Execute the specified shell command on target hosts
--playbook, -p Execute the specified Ansible playbook on target hosts
Optional Arguments
--help, -h Show the help message and exit
--version, -v Show the version and exit
--limit, -l Limit execution to specific hosts or groups
--forks, -f Number of parallel Ansible forks
--dry-run Run in Ansible check mode (requires -p or --playbook)
--no-ansible-output Suppress Ansible stdout output
Secondary/Stretched Goals (if time permits):
- Add pretty output formatting (success/failure summary per host).
- Implement basic logging of executed commands and results.
- Introduce safety checks for risky commands (shutdown, rm -rf, etc.).
- Package the tool so it can be installed with pip or stored internally.
Resources
Collaboration is welcome from anyone interested in CLI tooling, automation, or distributed systems. Skills that would be particularly valuable include:
- Python especially around CLI dev (argparse, click, rich)
Bring to Cockpit + System Roles capabilities from YAST by miguelpc
Bring to Cockpit + System Roles features from YAST
Cockpit and System Roles have been added to SLES 16 There are several capabilities in YAST that are not yet present in Cockpit and System Roles We will follow the principle of "automate first, UI later" being System Roles the automation component and Cockpit the UI one.
Goals
The idea is to implement service configuration in System Roles and then add an UI to manage these in Cockpit. For some capabilities it will be required to have an specific Cockpit Module as they will interact with a reasource already configured.
Resources
A plan on capabilities missing and suggested implementation is available here: https://docs.google.com/spreadsheets/d/1ZhX-Ip9MKJNeKSYV3bSZG4Qc5giuY7XSV0U61Ecu9lo/edit
Linux System Roles:
- https://linux-system-roles.github.io/
- https://build.opensuse.org/package/show/openSUSE:Factory/ansible-linux-system-roles Package on sle16 ansible-linux-system-roles
First meeting Hackweek catchup
- Monday, December 1 · 11:00 – 12:00
- Time zone: Europe/Madrid
- Google Meet link: https://meet.google.com/rrc-kqch-hca
Multimachine on-prem test with opentofu, ansible and Robot Framework by apappas
Description
A long time ago I explored using the Robot Framework for testing. A big deficiency over our openQA setup is that bringing up and configuring the connection to a test machine is out of scope.
Nowadays we have a way¹ to deploy SUTs outside openqa, but we only use if for cloud tests in conjuction with openqa. Using knowledge gained from that project I am going to try to create a test scenario that replicates an openqa test but this time including the deployment and setup of the SUT.
Goals
Create a simple multimachine test scenario with the support server and SUT all created by the robot framework.
Resources
- https://github.com/SUSE/qe-sap-deployment
- terraform-libvirt-provider
Dynamic Ansible Inventory for Orthos 2 by SchoolGuy
Description
Ansible is used in the context of Orthos 2. To enhance the parallel execution of Ansible playbooks for Orthos 2 hosts (machine scanning), the Cobbler dynamic Inventory plugin should be evaluated.
Goals
Improve the parallelization of machine scanning in Orthos 2.
Resources
- https://github.com/openSUSE/orthos2/
- https://docs.ansible.com/projects/ansible/latest/inventoryguide/introdynamic_inventory.html#inventory-script-example-cobbler
Ansible to Salt integration by vizhestkov
Description
We already have initial integration of Ansible in Salt with the possibility to run playbooks from the salt-master on the salt-minion used as an Ansible Control node.
In this project I want to check if it possible to make Ansible working on the transport of Salt. Basically run playbooks with Ansible through existing established Salt (ZeroMQ) transport and not using ssh at all.
Goals
- [v] Prepare the testing environment with Salt and Ansible installed
- [v] Discover Ansible codebase to figure out possible ways of integration
- [v] Create Salt/Uyuni inventory module
- [v] Make basic modules to work with no using separate ssh connection, but reusing existing Salt connection
- [v] Test some most basic playbooks
Resources