Ansibile Inventory Setup im LXC Container
Im letzten Artikel habe ich den Ansible und Semaphore LXC Container aufgesetzt. Zeit diesen so zu konfigurieren, dass wir zuerst einmal mit dem Ansible auf andere Komponenten zugreifen können und dann auch die gewünschten Playbooks schreiben und nutzen können. Zuerst möchte ich aus meiner lokalen Bash ohne grosses hängen und würgen auf den Container per SSH zugreifen können. Auf dem LXC Container existiert zu erst nur der User ROOT und genau mit diesem möchte ich mich auf Port 22 einloggen. Als Loglevel hätte ich gerne nur INFOs und wichtigere Meldungen. Das alles soll logischerweise per IPv6 erfolgen und ich würde gerne mit dem Kurznamen „rooti“ zu Zugriff herstellen, ohne in der /etc/hosts oder dem DNS herum Spielen zu müssen.
Lokale SSH-Config und Login Test
Also erzeuge ich mir auf meinem lokalen Linux PC einen Eintrag für den Host ansi und gebe dort die ganzen Werte an. Da geht natürlich noch viel mehr, aber für meine Zwecke ist das erst einmal ausreichend. Wer gerne unterschiedliche SSH-Keys pro Host nimmt, wird diese Datei natürlich zur Genüge kennen, denn genau hier lassen sich die Sessions-Keys für den jeweiligen Host definieren. 😉
|17:21:57|eric@cthulhu:[~]> more .ssh/config
Host rooti
Hostname fda0:d594:f020:ffff::55
User root
Compression yes
LogLevel info
Dann werde ich mal testen ob ich mit dem Befehl „ssh rooti“ eine Session per IPv6 mit dem Username ROOT öffne.
|17:22:02|eric@cthulhu:[~]> ssh rooti
The authenticity of host 'fda0:d594:f020:ffff::55 (fda0:d594:f020:ffff::55)' can't be established.
ED25519 key fingerprint is SHA256:kZYWZhePmRFHQGY3Y2KhFVWCv2311CH6zUWvIGD85Ck.
This key is not known by any other names.
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added 'fda0:d594:f020:ffff::55' (ED25519) to the list of known hosts.
root@fda0:d594:f020:ffff::55's password: Aligator3
Welcome to Ct101-ansible, TurnKey GNU/Linux 17.1 (Debian 11/Bullseye)
System information for Tue Mar 19 13:25:50 2024 (UTC+0000)
System load: 0.00 Memory usage: 3.9%
Processes: 30 Swap usage: 0.0%
Usage of /: 2.0% of 50.00GB IP address for eth0: 192.168.2.55
Linux CT101-Ansible 6.5.13-1-pve #1 SMP PREEMPT_DYNAMIC PMX 6.5.13-1 (2024-02-05T15:50Z) x86_64
Last login: never
root@CT101-Ansible ~#
IPv6-Test
Ich bin also auf dem Host „rooti“ angekommen, werfen wir noch einen Blick auf die Session selbst (also IPv4 oder IPv6).
root@CT101-Ansible ~# netstat -tnpa | grep 'ESTABLISHED.*sshd'
tcp6 0 0 fda0:d594:f020:ffff::22 fda0:d594:f020:ff:51474 ESTABLISHED 4145/sshd: root@pts
root@CT101-Ansible ~# ss | grep -i ssh
tcp ESTAB 0 0 [fda0:d594:f020:ffff::55]:ssh [fda0:d594:f020:ffff:e7a4:7470:c426:ceae]:51474
root@CT101-Ansible ~# journalctl -fu ssh
-- Journal begins at Sat 2024-03-19 15:16:34 UTC. --
Mar 19 15:16:34 CT101-Ansible sshd[4142]: Connection closed by fda0:d594:f020:ffff:e7a4:7470:c426:ceae port 50160 [preauth]
Mar 19 15:25:50 CT101-Ansible sshd[4145]: Accepted password for root from fda0:d594:f020:ffff:e7a4:7470:c426:ceae port 51474 ssh2
Mar 19 15:25:50 CT101-Ansible sshd[4145]: pam_unix(sshd:session): session opened for user root(uid=0) by (uid=0)
Ich hab hier mal die drei gängigen Befehle netstat, ss und journalctl genommen. Einer davon sollte auf jedem Linux Type eigentlich vorhanden sein.
Es ist gut zu erkennen, dass eine IPv6 Session für SSH genutzt wurde, damit ist meine .ssh/config funktional und kann so bleiben.
Ansible Check
Dann möchte ich mir das im letzten Artikel installierte Ansible doch mal etwas genauer ansehen, also welche Version habe ich und welche Plugins sind mit installiert worden. Fangen wir beim Versions Check an.
root@CT101-Ansible ~# ansible --version
ansible 2.10.17
config file = /etc/ansible/ansible.cfg
configured module search path = ['/root/library', '/usr/share/ansible/library']
ansible python module location = /usr/local/lib/python3.9/dist-packages/ansible
executable location = /usr/local/bin/ansible
python version = 3.9.2 (default, Feb 28 2021, 17:03:44) [GCC 10.2.1 20210110]
Und nun noch die Prüfung der mit installierten Connection Plugins.
root@CT101-Ansible ~# ansible-doc -t connection -l
ansible.netcommon.httpapi Use httpapi to run command on network appliances
ansible.netcommon.libssh (Tech preview) Run tasks using libssh for ssh connection
ansible.netcommon.napalm Provides persistent connection using NAPALM
ansible.netcommon.netconf Provides a persistent connection using the netconf protocol
ansible.netcommon.network_cli Use network_cli to run command on network appliances
ansible.netcommon.persistent Use a persistent unix socket for connection
community.aws.aws_ssm execute via AWS Systems Manager
community.docker.docker Run tasks in docker containers
community.docker.docker_api Run tasks in docker containers
community.general.chroot Interact with local chroot
community.general.docker Run tasks in docker containers
community.general.funcd Use funcd to connect to target
community.general.iocage Run tasks in iocage jails
community.general.jail Run tasks in jails
community.general.lxc Run tasks in lxc containers via lxc python library
community.general.lxd Run tasks in lxc containers via lxc CLI
community.general.oc Execute tasks in pods running on OpenShift
community.general.qubes Interact with an existing QubesOS AppVM
community.general.saltstack Allow ansible to piggyback on salt minions
community.general.zone Run tasks in a zone instance
community.kubernetes.kubectl Execute tasks in pods running on Kubernetes
community.libvirt.libvirt_lxc Run tasks in lxc containers via libvirt
community.libvirt.libvirt_qemu Run tasks on libvirt/qemu virtual machines
community.okd.oc Execute tasks in pods running on OpenShift
community.vmware.vmware_tools Execute tasks inside a VM via VMware Tools
containers.podman.buildah Interact with an existing buildah container
containers.podman.podman Interact with an existing podman container
local execute on controller
lxc_ssh connect via ssh and lxc to remote lxc guest
paramiko_ssh Run tasks via python ssh (paramiko)
psrp Run tasks over Microsoft PowerShell Remoting Protocol
ssh connect via ssh client binary
winrm Run tasks over Microsoft's WinRM Sowie die mit installierten Inventoty Plugins.
root@CT101-Ansible ~# ansible-doc -t inventory -l
advanced_host_list Parses a 'host list' with ranges
amazon.aws.aws_ec2 EC2 inventory source
amazon.aws.aws_rds rds instance source
auto Loads and executes an inventory plugin specified in a YAML config
awx.awx.tower Ansible dynamic inventory plugin for Ansible Tower
azure.azcollection.azure_rm Azure Resource Manager inventory plugin
cloudscale_ch.cloud.inventory cloudscale.ch inventory source
community.docker.docker_containers Ansible dynamic inventory plugin for Docker containers
community.docker.docker_machine Docker Machine inventory source
community.docker.docker_swarm Ansible dynamic inventory plugin for Docker swarm nodes
community.general.cobbler Cobbler inventory source
community.general.docker_machine Docker Machine inventory source
community.general.docker_swarm Ansible dynamic inventory plugin for Docker swarm nodes
community.general.gitlab_runners Ansible dynamic inventory plugin for GitLab runners
community.general.kubevirt KubeVirt inventory source
community.general.linode Ansible dynamic inventory plugin for Linode
community.general.nmap Uses nmap to find hosts to target
community.general.online Scaleway (previously Online SAS or Online.net) inventory source
community.general.proxmox Proxmox inventory source
community.general.scaleway Scaleway inventory source
community.general.stackpath_compute StackPath Edge Computing inventory source
community.general.virtualbox virtualbox inventory source
community.hrobot.robot Hetzner Robot inventory source
community.kubernetes.k8s Kubernetes (K8s) inventory source
community.kubernetes.openshift OpenShift inventory source
community.kubevirt.kubevirt KubeVirt inventory source
community.libvirt.libvirt Libvirt inventory source
community.okd.openshift OpenShift inventory source
community.vmware.vmware_vm_inventory VMware Guest inventory source
constructed Uses Jinja2 to construct vars and groups based on existing inventory
generator Uses Jinja2 to construct hosts and groups from patterns
google.cloud.gcp_compute Google Cloud Compute Engine inventory source
hetzner.hcloud.hcloud Ansible dynamic inventory plugin for the Hetzner Cloud
host_list Parses a 'host list' string
ini Uses an Ansible INI file as inventory source
netbox.netbox.nb_inventory NetBox inventory source
ngine_io.vultr.vultr Vultr inventory source
openstack.cloud.openstack OpenStack inventory source
ovirt.ovirt.ovirt oVirt inventory source
script Executes an inventory script that returns JSON
servicenow.servicenow.now ServiceNow Inventory Plugin
theforeman.foreman.foreman Foreman inventory source
toml Uses a specific TOML file as an inventory source
yaml Uses a specific YAML file as an inventory source Okay, in Debian 11 (nicht mehr ganz Tau frisch) ist die Ansible Community Version 2.10.17 dabei (gut abgehangen). Als Plugins habe ich in jedem Falle Network_Cli dabei (ssh), was insgesammt für meine Belange ausreichend erscheint.
Ansible User anlegen anlegen
Natürliche möchte ich nicht mit dem User Root arbeiten, um Ansible zu nutzen und auf andere Systeme zuzugreifen. Es ist also an der Zeit einen User dafür anzulegen. Ich wähle hier für den User Name „ansible“.
useradd -m -G users,sudo -s /bin/bash ansible
passwd ansible
<starkes Passwort>
nano /etc/sudoers
%sudo ALL=(ALL:ALL) NOPASSWD:ALL
Alle weiteren Arbeiten werden mit dem User Ansible durchgeführt.Ansible Host Inventory anlegen
Damit Ansible Control Node auf die Hosts zugreifen kann, bedarf es des einer Inventar-Liste in der Form eines für Ansible lesbaren Inventorys. Dieses Inventory kann nach meinem Wissen an unterschiedlichen stellen liegen und wird in folgender Reihenfolge in der Wertigkeit absteigend abgearbeitet:
- Durch Angabe innerhalb der Befehlsoption, z. B. ansible-playbook -i filepath
- Die Konfigurationsdatei ansible.cfg: [defaults] inventory = /some/other/filepath
- Der Standardspeicherort: /etc/ansible/hosts
Um sicher zu gehen, dass Ansible auf der Komandozeile, sowie Semaphore das selbe Inventory nutzt, werde ich mit der /etc/ansible/hosts arbeiten. Diese wiederum kann dann in zwei verschiedenen Arten geschrieben sein, entweder im INI-Format oder als YAML-File. Ich bevorzuge das YAML-Format, da ich glaube, dass das langfristig existieren wird. 😉
Ich teile das Inventory dabei in die drei Gruppen Containers, Physicals und Storage ein. Diese Gruppen fasse ich dann in der Metagruppe Server zusammen. Eventuel kommen später noch weitere Gruppem oder Metagruppen hinzu, aber das kann ich heute noch nicht abschätzen.
Wie sieht denn dann so eine Ansible-Inventory Datei im YAML Format aus:
ansible@CT101-Ansible ~# more /etc/ansible/hosts
---
containers:
hosts:
ct100-nextcloud:
ansible_host: fda0:d594:f020:ffff::50
ct101-ansible:
ansible_host: fda0:d594:f020:ffff::55
physicals:
hosts:
pve1:
ansible_host: fda0:d594:f020:ffff::30
bammbamm:
ansible_host: fda0:d594:f020:ffff:21e:6ff:fe45:135f
storage:
hosts:
simstim:
ansible_host: fda0:d594:f020:ffff::beaf
servers:
children:
containers:
physicals:
storage:Doch Ansible hat da noch weitere Boardmittel zu Anzeige des Inventorys, welche später bei der Variablen-Definition auch gute dienste leisten werden. Okay, zu erst stellt sich die Frage wie sieht Ansible die Datei? Dafür kann man sich das Inventory als Liste ausgeben lassen.
ansible@CT101-Ansible ~# ansible-inventory --list
{
"_meta": {
"hostvars": {
"bammbamm": {
"ansible_host": "fda0:d594:f020:ffff:21e:6ff:fe45:135f"
},
"ct100-nextcloud": {
"ansible_host": "fda0:d594:f020:ffff::50"
},
"ct101-ansible": {
"ansible_host": "fda0:d594:f020:ffff::55"
},
"pve1": {
"ansible_host": "fda0:d594:f020:ffff::30"
},
"simstim": {
"ansible_host": "fda0:d594:f020:ffff::beaf"
}
}
},
"all": {
"children": [
"servers",
"ungrouped"
]
},
"containers": {
"hosts": [
"ct100-nextcloud",
"ct101-ansible"
]
},
"physicals": {
"hosts": [
"bammbamm",
"pve1"
]
},
"servers": {
"children": [
"containers",
"physicals",
"storage"
]
},
"storage": {
"hosts": [
"simstim"
]
}
}
In komplexeren Umgebungen wird dieser Auszug dann schnell unübersichtlich, was die nächste Befehlsoption für ansible-inventory sinvoll erscheinen läßt – nämlich Option Graph. Wir eine logische Struktur als Graph dargestellt.
ansible@CT101-Ansible ~# ansible-inventory --graph
@all:
|--@servers:
| |--@containers:
| | |--ct100-nextcloud
| | |--ct101-ansible
| |--@physicals:
| | |--bammbamm
| | |--pve1
| |--@storage:
| | |--simstim
|--@ungrouped:
Natürlich kann man sich auch die Details nur einer Komponente im Inventory anzeigen lassen, das geht dan mit der Option Host <xyz>.
ansible@CT101-Ansible ~# ansible-inventory --host pve1
{
"ansible_host": "fda0:d594:f020:ffff::30"
}Verbindungskontrolle durch Modul Ping
Dann prüfen wir doch mal mittels Ansible Modul Ping, ob wir uns bei den Komponeten anmelden können. Das muss(!!) jetzt schief gehen, da keine Public-Keys ausgetauscht wurden und ich nicht mit Usernamen+Passwörtnern herum hantieren will… 😉
ansible@CT101-Ansible ~# ansible -m ping servers
pve1 | UNREACHABLE! => {
"changed": false,
"msg": "Failed to connect to the host via ssh: Warning: Permanently added 'fda0:d594:f020:ffff::30' (ECDSA) to the list of known hosts.\r\nroot@fda0:d594:f020:ffff::30: Permission denied (publickey,password).",
"unreachable": true
}
ct101-ansible | UNREACHABLE! => {
"changed": false,
"msg": "Failed to connect to the host via ssh: Warning: Permanently added 'fda0:d594:f020:ffff::55' (ECDSA) to the list of known hosts.\r\n\nroot@fda0:d594:f020:ffff::55: Permission denied (publickey,password).",
"unreachable": true
}
bammbamm | UNREACHABLE! => {
"changed": false,
"msg": "Failed to connect to the host via ssh: Warning: Permanently added 'fda0:d594:f020:ffff:21e:6ff:fe45:135f' (ECDSA) to the list of known hosts.\r\nroot@fda0:d594:f020:ffff:21e:6ff:fe45:135f: Permission denied (publickey,password).",
"unreachable": true
}
ct100-nextcloud | UNREACHABLE! => {
"changed": false,
"msg": "Failed to connect to the host via ssh: Warning: Permanently added 'fda0:d594:f020:ffff::50' (ECDSA) to the list of known hosts.\r\n\nroot@fda0:d594:f020:ffff::50: Permission denied (publickey,password).",
"unreachable": true
}
simstim | UNREACHABLE! => {
"changed": false,
"msg": "Failed to connect to the host via ssh: Warning: Permanently added 'fda0:d594:f020:ffff::beaf' (RSA) to the list of known hosts.\r\nroot@fda0:d594:f020:ffff::beaf: Permission denied (publickey,password,keyboard-interactive).",
"unreachable": true
}
Was sehen wir im Output? Er hat alle Hosts der Metagruppe Servers und damit auch die echten Hosts in den Gruppen per SSH versucht zu erreichen und ist wegen mangelendem Publickey oder Passwort beim Versuch abgewiesen worden. Allerdings hat er in diesem Test auch gleich die Fingerprints der Server eingesammelt. Der Fingerprint der oben angelegten 5 Server läßt sich gut als Treasure Map Output der lokalen SSH Known Hosts Datei darstellen mit ssh-keygen.
ansible@CT101-Ansible ~/.ssh# ssh-keygen -l -v -f ~/.ssh/known_hosts
256 SHA256:PF7+vUYuVdp0J5pTxQOOi89WA2GWbmhFOzB2z+RxjXc |1|Ho+JJ1swoyouCm0GnsyqHi57Xxc=|hbe7LQpltrAdaZmuMamMtHni37Q= (ECDSA)
+---[ECDSA 256]---+
| +.*.+.+.|
| . *oX +.E|
| += = oo|
| . o.o+ o =|
| S.o. * *o|
| . +o = = .|
| . .+ = |
| ....o |
| .oo. |
+----[SHA256]-----+
256 SHA256:k14SkrnMi+NCldQvzE8OFTxf1Wx4E4uN3JmSEnzUe8E |1|QDEQ4TRydOWWQPmeevnUAQkz8gY=|OWcAxe9X8W02I3rm7gJ+SSdm5JM= (ECDSA)
+---[ECDSA 256]---+
| . ......o+=.|
| . .o+ .+.BEO|
| . ++o.o o.* O+|
| oo=ooo. . ...|
| . +*S . .|
| . . oo+ |
| . o . . |
| .. . |
| .. |
+----[SHA256]-----+
256 SHA256:jlUKiFC6HhsbnE+1HtI85aqOjASzMjmcmZUdFrweINU |1|QfGQ0dLww4m5KEwDWF4UDf+ONSg=|hyzL8JMg6flQyqlBkcOwafeO8y8= (ECDSA)
+---[ECDSA 256]---+
|..o.o. |
| + o E. |
|. o o+o. . |
|... Bo=. o |
|+* =.B..S |
|++& o.++ |
|*X . o. . |
|=o. . |
|.o.o |
+----[SHA256]-----+
256 SHA256:XHIV05fJpMcCjildoQwC6ilicaRum1ofRgWCa0h99CU |1|jYtmrzfE2VFF7+06jZaE9DPSfhM=|/kaTGBH4S0/mOOYii5UTKjHU7i8= (ECDSA)
+---[ECDSA 256]---+
| .oo+o E . +=oo.o|
|..+o oo * *...++.|
|o= .. .o.*o. o + |
|=.+ . ..+ o |
|+* . S |
|= o. |
| o. o |
|.. o . |
|. . |
+----[SHA256]-----+
2048 SHA256:xOC7v/H6mli+IGS2pFVakM2VO3Kjv9SeQn67tU0DNQ8 |1|xzz4PWUgki+T6hOv0jZOwiB6/Ac=|52e4WoWIvItfh31VfWRV2PGC6f0= (RSA)
+---[RSA 2048]----+
| .+.... |
| .ooo. |
| + o. E |
| +.o= . + |
| B .+So . .|
| B ..... . |
| . o o++ . . o |
| . B+=.o + . |
| . XXBo. . |
+----[SHA256]-----+
Anlegen eines SSH Keys
Da fällt mir doch glatt auf, dass ich noch keinen SSH_Key für das Login erzeugt habe auf dem Container Ansible. Dann holen wir das mal flott nach, damit ich überhaupt einen Schlüssel zum Austauschen habe. Hier nur als Beispiel, der echte Schlüssel ist dann zur Nutzung ein anderer. Ich kodiere gerne meinen Usernamen, das Nutzungssystem und den Zeitpunkt der Erzeugung mit in den Schlüssel, damit ich später nachvollziehen kann, woher der Stammt. 🙂
ansible@CT101-Ansible ~/.ssh# ssh-keygen -o -a 100 -t ed25519 -C "$(whoami)@$(uname -n)-$(date -I)"
Generating public/private ed25519 key pair.
Enter file in which to save the key (~/.ssh/id_ed25519):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in ~/.ssh/id_ed25519
Your public key has been saved in ~/.ssh/id_ed25519.pub
The key fingerprint is:
SHA256:C8hq+RrXVKexX0zMakzdJKe+hDpJTNQ6sY/XA53+fBY ansible@CT101-Ansible
The key's randomart image is:
+--[ED25519 256]--+
| .. . o |
| .. .+ * |
| ++o.*.. |
| . . ++B.*o |
| o o S+=+= |
| o o o.*oo+. E |
| = . . =.. .+ .|
| . + . o o|
| ... o |
+----[SHA256]-----+
Wenn dieser Publickey dann auf einem anderen System liegt kann man hinein sehen und zumindest nachvollziehen, wer ihn auf welchem System wann erzeugt hat. Das geht dann Beispielsweise so.
ansible@CT100-Nextcloud ~/.ssh# ssh-keygen -l -v -f ~/.ssh/authorized_keys
SHA256:C8hq+RrXVKexX0zMakzdJKe+hDpJTNQ6sY/XA53+fBY root@CT101-Ansible-2024-03-21
+--[ED25519 256]--+
| .. . o |
| .. .+ * |
| ++o.*.. |
| . . ++B.*o |
| o o S+=+= |
| o o o.*oo+. E |
| = . . =.. .+ .|
| . + . o o|
| ... o |ansible@CT101-Ansible ~#
+----[SHA256]-----+
Verteilen des SSH-Keys
Der Publickey muss nun noch auf die Systeme verteilt werden. Ich hatte dummerweise vorher nicht geprüft, ab alle Systeme ED25519 kompatibel sind.. 🙁
Als Beispiel nehme ich hier zum zeigen nur einen Server, was zum Verstehen des Ablaufs allerdings ausreichend sein sollte. Ich pushe also den Publickey, logge mich direkt im Anschluß mittels Publickey auf diesem Server in ssh ein und lasse mir die /root/.ssh/authorized_keys anzeigen.
pushen:
------>
ansible@CT101-Ansible ~/.ssh# ssh-copy-id -i ~/.ssh/id_ed25519.pub root@fda0:d594:f020:ffff::50
/usr/bin/ssh-copy-id: INFO: Source of key(s) to be installed: "/root/.ssh/id_ed25519.pub"
/usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed
/usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keys
root@fda0:d594:f020:ffff::50's password:
Number of key(s) added: 1
Now try logging into the machine, with: "ssh 'root@fda0:d594:f020:ffff::50'"
and check to make sure that only the key(s) you wanted were added.
ssh login mit publickey:
----------------------->
ansible@CT101-Ansible ~/.ssh# ssh fda0:d594:f020:ffff::50
Welcome to Ct100-nextcloud, TurnKey GNU/Linux 17.2 (Debian 11/Bullseye)
System information for Thu Mar 21 19:14:30 2024 (UTC+0000)
System load: 0.04 Memory usage: 5.1%
Processes: 43 Swap usage: 0.0%
Usage of /: 5.0% of 294.23GB IP address for eth0: 192.168.2.50
Linux CT100-Nextcloud 6.5.13-1-pve #1 SMP PREEMPT_DYNAMIC PMX 6.5.13-1 (2024-02-05T13:50Z) x86_64
Last login: Wed Mar 20 17:01:47 2024
authorized_keys:
--------------->
root@CT100-Nextcloud ~# cat .ssh/authorized_keys
ssh-ed25519 xOC7v/H6mli+IGS2pFVakM2VO3Kjv9SeQn67tU0DNQ8
Erneute Verbindungskontrolle durch Modul Ping
Auf allen Systemen ist nun der Publickey verteilt. Wollen wir doch noch einmal prüfen, ob wir dann jetzt zu den Komponenten durch Ansible sprechen können. Also wieder das Modul Ping nutzen und den Output analysieren.
ansible@CT101-Ansible ~# ansible -m ping servers
pve1 | SUCCESS => {
"ansible_facts": {
"discovered_interpreter_python": "/usr/bin/python3"
},
"changed": false,
"ping": "pong"
}
ct100-nextcloud | SUCCESS => {
"ansible_facts": {
"discovered_interpreter_python": "/usr/bin/python3"
},
"changed": false,
"ping": "pong"
}
bammbamm | SUCCESS => {
"ansible_facts": {
"discovered_interpreter_python": "/usr/bin/python3"
},
"changed": false,
"ping": "pong"
}
ct101-ansible | SUCCESS => {
"ansible_facts": {
"discovered_interpreter_python": "/usr/bin/python3"
},
"changed": false,
"ping": "pong"
}
simstim | SUCCESS => {
"ansible_facts": {
"discovered_interpreter_python": "/usr/bin/python"
},
"changed": false,
"ping": "pong"
}
Alle Systeme antworten und sind erreichbar. Damit ist das Etappenziel für Ansible mit dem Inventory-Setup erreicht.
Neueste Kommentare