• úvod
  • témata
  • události
  • tržiště
  • diskuze
  • nástěnka
  • přihlásit
    registrace
    ztracené heslo?
    INDIANCentralizovaná správa stanic a ostatních prvků v síti - automation/monitoring/alerting a dalsi devops nastroje
    RAGNAROK
    RAGNAROK --- ---
    AQUARIUS:
    Agentovy jsem se chtel vyhnout ale ted budu zkouset ssh-agent.
    AQUARIUS
    AQUARIUS --- ---
    RAGNAROK: Co použít ssh agenta?
    RAGNAROK
    RAGNAROK --- ---
    Zkousim v ansible authentikaci pres ssh.
    Server ma nastaveno AuthenticationMethods pubkey,password
    Klic ma passphrase.

    V ansiblu se mi zatim povedlo jen authentikace: pubkey a passphrase nebo pubkey a password.

    Kombinace passphrase, pubkey a password ale nejde. Ansible se na passphrase nezepta.

    Jde to vubec?
    CHOROBA
    CHOROBA --- ---
    dela to, co update-alternative command dela v debianu
    QUIP
    QUIP --- ---
    FATBOZZ: Co presne ten modul dela? Z popisu na webu jsem to uplne nepochopil. To vytvori system wide symlink, nebo jen pro pouziti Ansible (v ansible home?)
    A tim "install" se mysli, ze vytvori symlink, nebo ze to nainstaluje balik package managerem?
    FATBOZZ
    FATBOZZ --- ---
    A tohle by se nehodilo ?
    community.general.alternatives module – Manages alternative programs for common commands — Ansible Documentation
    https://docs.ansible.com/ansible/latest/collections/community/general/alternatives_module.html
    QUIP
    QUIP --- ---
    HEINZZ: Ono je to nasledovne:
    Kdyz si nainstalujes neco, co zavisi na Pythonu, tak se ti nainstaluje i Python a mas tam jen ten konkretni, napriklad "python3.9".
    Muzes si ale nainstlaovat i tzv meta balik python3, ktery ti udela ten symlink "python3", nebo meta balik python, ktery ti udela i symlink "python". (ve skutecnosti to dela symlinky na vicero souboru: bin/2to3-3, bin/idle3, bin/pydoc3, bin/python3, bin/python3-config, libdata/pkgconfig/python3.pc)

    Ty symlinky nemuzou byt soucasti python-3.9 balicku, protoze by to kolidovalo se stejnymi symlinky z balicku python-3.7 atp.

    Pokud bych na to sel z opacne strany a rekl, ze chci nainstalovat balicek "python" a je mi jedno, jake verze, tak se nainstaluje ta defaultni verze, coz je ted tusim 3.9 a k tomu se nainstalujou i oba dva meta balicky, protoze retezec zavislosti je "python" > "python3" > "python3.9".
    Tedy "pkg install python", nainstaluje to, co ty povazujes za defaultni na Debianu.

    No a ja to u sebe asi vyresim tak, ze si upravim svuj meta balik, ktery mam pojmenovany "ansible-client", coz neobsahuje zadne soubory, jenom seznam zavislosti, ktere je potreba nainstalovat tam, kde chci provozovat Ansible (sudo + python39). Upravim to na "sudo + python3", pri pristi aktualizaci se mi tak na vsechny stroje nainstaluje meta balik "python3", ktery vytvori ty symlinky a ja pak muzu upravit ansible_python_interpreter na /usr/local/bin/python3

    Takze vsem diky za prinosnou diskuzi :)
    HEINZZ
    HEINZZ --- ---
    QUIP: OK sry, v *BSD nejsem zbehlej a na deb-based linuxu kde se vetsinou pohybuju je tohle soucasti python* balicku..
    QUIP
    QUIP --- ---
    HEINZZ No to jsem popisoval tady QUIP. Da se to zaridit, aby tam symlinky byly, ale defaultne nejsou.
    Ten muj konkretni pripad by to ted asi vyresilo nejjednodusim zpusobem.
    Ale je pro me zajimave i zamysleni nad tou manipulaci s ansible_python_interpreter v ramci jednotlivych tasku v playbooku (tak nejak akademicky) :).
    SAMGARR
    SAMGARR --- ---
    A neslo by si pro Ansible udelat dedikovany pyenv aby nebyl zavislej na systemovym Pythonu?
    HEINZZ
    HEINZZ --- ---
    HEINZZ:
    ^_^ hzz@~$> ls -al /usr/bin/ | grep python3
    lrwxrwxrwx 1 root root        7 Aug  3 19:39 python -> python3
    lrwxrwxrwx 1 root root       10 Aug  3 19:39 python3 -> python3.10
    -rwxr-xr-x 1 root root    14280 Aug  3 19:39 python3.10
    HEINZZ
    HEINZZ --- ---
    Hele a proč prostě nepoužít
    ansible_python_interpreter=/usr/bin/python3
    ..? *BSD nemá tyhle symlinky?
    QUIP
    QUIP --- ---
    CHOROBA: No pokud ti neprojde zadny ansible task, protoze mas spatny python, tak z toho asi cesta nevede :) Ja bych to v mem pripade zjistoval jeste pred tim upgradem.

    A nebo si udelas playbook, ktery postupne vyzkousi vsechny verze interpreteru, ktere prichazeji v uvahu :)
    CHOROBA
    CHOROBA --- ---
    mi spis reknete, jak zjidtit ansiblem verzi pythonu, kdyz mi zjistovani verze pythonu zemre na spatny verzy pythonu ;-D
    QUIP
    QUIP --- ---
    ZBYNEK: I nad tim jsem premyslel, on na to i existuje balicek, ktery tohle dela (tech symlinku je tam vic), ale je to pak symlink jen na jednu "defaultni" verzi Pythonu, zatim co tech verzi muze byt nainstalovanych nekolik soucasne (2.7, 3.7 - 3.11). Hlavne pri prechodu z 2.7 na 3. to byl docela problem, u tech 3.x uz to tak zasadni neni.

    Cest je mnoho, staci si vybrat tu jednu spravnou :)
    ZBYNEK
    ZBYNEK --- ---
    QUIP: A co si tam udělat nějakej symlink, kterej bude ukazovat na aktuální python a při aktualizaci si symlink upravíš?
    QUIP
    QUIP --- ---
    INDIAN: Jo, neco takoveho bych si predstavoval, jen jeste premyslim o tom, jak to rozsirit o nejake "podminky", abych tam nemusel mit natvrdo zadratovanou tu verzi, respektive jak pred taskem s "pkg upgrade" zjistit, ze se tentokrat bude menit i verze Pythonu a ze je teda potreba po provedeni "pkg upgrade" pretizit ansible_python_interpreter.

    Zkratka tenhle playbook pro update poustim tak 2x do mesice, ale jen jednou za dva roky se zmeni verze Pythonu.

    Ale mozna bude jednodussi, mit pro tenhle pripad samostatny specializovany playbook, prave pro to, ze se to deje jednou za dva roky, nez se snazit nejak vymyslet automatickou detekci a podminkovani.
    INDIAN
    INDIAN --- ---
    QUIP: jestli sem to dobre pochopil, potrebujes po tom upgradu ihned pouzivat novou verzi interpreteru?
    co ho jednoduse po tom upgradu pretizit?
    - name: Override python interpreter
      set_fact:
        ansible_python_interpreter: /usr/local/bin/python3.9
    QUIP
    QUIP --- ---
    Pouzivam Ansible pro nektere hromadne ukoly udrzby FreeBSD serveru (HW i virtualni) a mam tu takovy jeden problem pri upgrade verze Pythonu.

    V hosts mam
    [freebsd:vars]
    ansible_python_interpreter=/usr/local/bin/python3.7
    ansible_perl_interpreter=/usr/local/bin/perl5
    #ansible_shell_type=csh

    V playbooku pro provedeni aktualizace balicku je nekolik tasku, jednim z nich je provedeni "pkg upgrade", jenze to ted spusti i aktualizaci Pythonu z 3.7 na 3.9, takze pro nasledujici task uz neni k dispozici ten definovany interpreter python3.7, takze nasledujici task v tom playbooku selze a je po legraci.

    Pro stroje, ktere uz touhle aktualizaci prosly, mam pak dalsi skupinu
    [py39host:vars]
    ansible_python_interpreter=/usr/local/bin/python3.9
    ansible_perl_interpreter=/usr/local/bin/perl5
    Takze dalsi spusteni nejakeho playbooku uz funguje zase normalne, kdyz do te skupiny pridam ty prave zaktualizovane stroje.

    Je to tak trochu "vejce nebo slepice" problem.
    A jak to elegantne resit?
    Napada me, ze pro tenhle pripad, kdy dochazi ke zmene verze Pythonu, budu muset mit jiny playbook, ktery uz nebude mit zadny dalsi task po provedeni "pkg ugprade" a k nemu dalsi playbook, ktery spustim az po tom upgrade a uprave hosts (ale ztraci to tu eleganci toho, ze playbook bude fungovat vzdy a sam - takhle ja budu muset predem "tusit", ze dochazi ke zmene verze Pythonu v repozitari balicku)

    Nebo by slo detekovat tuhle zmenu pred jejim provedenim, po provedeni pkg upgrade provest zmenu v lokalnim hosts file dalsim taskem stejneho playbooku a pak pokracovat s dalsimi tasky s jinym interpreterem (da se tahle zmena ansible_python_interpreter provest a reflektovat uprostred nejakeho playbooku?)? Ale cele mi to prijde takove nejake neelegantni, navic kdyz je to neco, co se provede treba jednou za dva roky.
    MAJA
    MAJA --- ---
    INDIAN: občas mám pocit, že se ve vyhledávání v Google točím pořád dokola na skoro stejných výsledcích ... a pak zkusím DuckDuckGo ... :-)
    Kliknutím sem můžete změnit nastavení reklam