Ansible Nub help

[Shihatsu]

Joa, meine Jungs verwenden zur Automatisierung Ansible. Ich kann das nicht. Um zu verstehen was sie machen (muss ich nicht, will ich aber!) hab ich mir für die Ferien vorgenommen meine Installation eines EndevourOS zu automatisieren mit Hilfe von Ansible. Workflow wird also sein: Installation von base EndevourOS, installation von git und ansible, git pull, ansible-playbook laufen lassen, fertig. Soweit, so gut. Die basics hab ich mir beigebracht, aber jetzt struggle ich mit was simplem: Escaping.
Aktueller tasks: Eza installatieren und konfigurieren. Eza macht ls "toll", dafür müssen ein paar aliase in die bashrc (oder sonstewo) eingetragen werden. Leider kommt EndevourOS schon von Haus aus mit einem alias (kp ob das EndevourOS oder arch upstream ist oder KDe oder sonstewer macht, ist mir auch latte):
alias ls='ls --color=auto'
Also hab ich mir folgendes geschrieben:
- name: remove alias ls ansible.builtin.replace: path: ~/.bashrc regexp: 'alias ls=''ls --color=auto' replace: '#alias ls=''ls --color=auto'
Das schmeißt aber folgenden Fehler:
ERROR! We were unable to read either as JSON nor YAML, these are the errors we got from each: JSON: Expecting value: line 1 column 1 (char 0) Syntax Error while loading YAML. did not find expected key The error appears to be in '/home/shihatsu/git/eos-ansible/playbook_eza.yml': line 16, column 28, but may be elsewhere in the file depending on the exact syntax problem. The offending line appears to be: replace: '#alias ls=''ls --color=auto' ^ here There appears to be both 'k=v' shorthand syntax and YAML in this task. Only one syntax may be used.
Wie escape ich hier richtig?

 

[derduder]

Ich glaube du hast da mit den verschachtelten Quotes Schindluder getrieben. Müsste das nicht so heißen:

regexp: "alias ls='ls --color=auto'" replace: "#alias ls='ls --color=auto'"

 

[sweetie]

Ich stimme derduder zu und noch zwei weitere Punkte:

Die Einrückung der letzten zwei Zeilen aus dem Codeschnipsel passt nicht, da fehlt vorne ein Leerzeichen. regexp und replace müssen so eingedrückt sein wie path (kann aber auch nur ein copy paste Fehler hier sein).

Grundsätzlich noch die Frage (unabhängig von dem Error): Setzt endeavour den obigen alias in der bashrc? Denn wenn du diesen nur auskommentierst ist der alias danach vermutlich immer noch definiert. In dem Fall sollte ein 'unalias ls' und darauffolgendes sourcen der bashrc das Problem lösen.

Quelle: meine Freundin, hab persönlich keine Ahnung von dem Kram

 

[Shihatsu]

Einrückungen hat das Forum verkackt, unfähige Admins hier
Und ja, doppelquotes solven, wenn man es denn "richtig" macht:
- name: remove alias ls #ansible.builtin.replace: lineinfile: path: ~/.bashrc regexp: "alias ls='ls --color=auto" line: "#alias ls='ls --color=auto'"
unalias ls fubktioniert einfach nicht, warum auch immer. Aber ja, der alias wird von EndevourOS gesetzt. Am Ende der ganzen Ansible Geschichte wird eh rebootet, dadurch wird die basrc ja angezogen und es sollte sauber sein - zumindest funktioniert es jetzt so.
Mein nächstes Thema: Wie finde ich raus welches Panel mein mainpanel ist... In der configdatei wird es offenbar random benannt...

 

[TealC]

Quelle: meine Freundin, hab persönlich keine Ahnung von dem Kram

Was hast Du denn für ne abgefahrene Freundin? da brauchen wir Pics um Dir das zu glauben

 

[sweetie]

not gonna happen
Aber sie ist halt krasse RedHat-IT-Consultant und ich nur popeliger Oberstudienrat

 

[drwilly]

Aktueller tasks: Eza installatieren und konfigurieren. Eza macht ls "toll", dafür müssen ein paar aliase in die bashrc (oder sonstewo) eingetragen werden. Leider kommt EndevourOS schon von Haus aus mit einem alias (kp ob das EndevourOS oder arch upstream ist oder KDe oder sonstewer macht, ist mir auch latte):
alias ls='ls --color=auto'

Ugh. Ansible.
Das Problem bei diesen Config-Tools (ob salt, puppet, chef, cdist oder jetzt ansible) ist immer, dass sie nicht den Zustand des Systems beschreiben, sondern einfach nur ihre Regeln abarbeiten.
Heißt in deinem Beispiel: Wenn du die eza regel entfernst, wird dadurch nicht etwa das eza setup rückgängig gemacht. Nö, das bleibt alles einfach so. Eigentlich bräuchtest du zu jeder "install eza"-Regel also noch eine dazu inverse "uninstall eza"-Regel, wobei du je nach config immer die eine oder die andere Regel anwendest. Macht natürlich keiner, aber damit verabschiedet man sich halt vom Ideal der deklarativen Beschreibung des Systems. Wenn's nur darum geht die Systeme initial von einem Standardimage aufzusetzen macht das nix, aber bei der Administration von langlebigen Systemen geht wird das schon eher zum Problem. Ich würde also davon abraten, mit Ansible da in irgendwelchen Dateien rumzufummeln, sondern möglichst Ansible vom Rest zu trennen. Wenn steht also die .bashrc komplett unter der Verwaltung von Ansible und du machst darin nix anderes als erst ~/.bashrc.vendor.d/* und dann ~/.bashrc.d/* zu laden. Änderungen an der .bashrc werden überschrieben, nicht explizit konfigurierte Dateien im .bashrc.vendor.d/ Verzeichnis gelöscht.
Man merkt leider an allen Ecken und Enden, dass diese Tools alle nur so drangeschraubt sind. Funktioniert umso besser je mehr man sich mit dem Gedanken anfreunden kann das System neu aufzusetzen.
Konzeptionell richtig machen das Guix und NixOS, aber da ist der Einstieg schwer und man merkt doch hin und wieder, dass man kein standard Linux verwendet.