Uyuni/SUSE Manager - hostname beallitas VMware VM-eknel.

Linux-haladó

Sziasztok!

 

Aki a cimben szereplo programot hasznalja, attol kernek egy kis helpet!

 

Ti hogyan oldjatok meg a hostname automatikus beallitasat (VMware VM-eknel)?

 

Nalam ugy nez ki a dolog, hogy keszitettem egy kb 60 megas iso-t, amirol bebootolva a centos szepen feltepul az Uyuni serverrol (autoinstallation) majd egy post scriptel az Uyuni ala is berakja magat, a bootstrap-al megkapja a kezdo configot, feliratkozik a megfelo software channelre etc... Ez mukodik is szepen, de gondoltam tovabbfejesztem az alabbiakkal:

 

- beleptetes active directoryba (sssd, install utan felrakja, meg a dependency-ket is)

- sudoers beallitasa (AD group)

- Cockpit telepitese (wines kollegak ragaszkodnak hozza...:) )

- par alap progi felrakasa (check_mk, fail2ban, etc...)

 

Viszont ezek egy reszehez mindenkepp kell, hogy hostnevet adjak a gepnek, mielott barmi tortenne.... Wines gepeknel Ivanti DSM-et hasznalunk, ott vagy a VMwarebol atveszi a VM nevet, ha BIOS alapu a boot (policy nalunk, hogy a VM neve a hostname), vagy a DSMben kell elnevezni a gepet (UEFI boot eseten) igy legyegeben erintesmentesen foltelepulnek a win-ek. Hasonlot akarnek a linuxokkal is.

 

Csatlakoztattam a vCentert az uyunihoz, de azon kivul, hogy melyik regisztralt kliens melyik hoston van, masra nem igazan latom, hogy hasznalhato lenne ez a funkcio...

 

Szoval a kerdesem a kovetkezo. Ti hogyan oldanatok meg, hogy telepites vegen valahogy megkapja a megfelelo hostnevet a kliens?

 

(Ha lehet, uyuni oldalon oldanam meg, tehat pl nem akarnek ezert modjuk pyVmomi-t rakni minden kliensre)

  • 428 megtekintés

( zwei | 2021. 03. 09., k – 11:36 )

Szerkesztve: 2021. 03. 09., k – 11:52

Suse Manager mellett retek módon ansible-t használok provision-ra :)

Ennek történeti okai vannak - hamarabb volt ansible, és elég sok minden van benne, lusta voltam salt-ra átírni.

Szóval úgy néz ki a dolog, hogy a vmware template klónozás után futtatok egy ansible playbookot, ami  beállítja a hostnevet és többek közt futtatja a Suse manager bootstrap scriptet, és felhúzza a szabvány konfigot.

(sssd install, pam konfig, security hardening, stb.)

Egyébként a hostnevet linux is át tudja venni vmware-ből. Red Hat esetén openvmtools+ cloud init, Ubuntu esetén simán open vm tools   megteszi.

szerk:

Red Hat esetén  ezek a csomagok vannak a template-ben, amivel megy a hostnév és IP bellítás vmware profilból:

python-backports
python-backports-ssl_match_hostname
python-ipaddres
cloud-init
perl-File-Temp
network-scripts
open-vm-tools

 

Ubuntu esetén  úgy emlékszem elég volt levakarni a cloud initet, ha alapból rajta lenne  (open-vm-tools is kell ha nem lenne)

 

Arra kell ügyelni, hogy klónozás után a /etc/machine-id  -t újra kell generálni (rm /etc/machine-id;systemd-machine-id-setup), mert úgy tapasztaltam a Suse Manager (Uyuni) hajlamos ezt is egyedi azonosítóként használni.

Vcenterben lehet "Policies and Profiles" -> "VM Customization Specification" alatt csinálni egy custom profilt. Ebben meg lehet adni, hogy a hostnév a VM-név legyen -e , vagy klónozáskor megkérdezze.

Klónozáskor van egy "Customize the operating system" opció is, ott ki lehet választani a profilt, be lehet állítani  nevet és IP címet a guest-nek.

Új VM esetén nincs ilyen opció, szerintem ilyenkor nem is lehet a vmware-ből kinyerni a vm nevét.

 

A hálózatot hogy állítod be? DHCP?

Ha az IP címet reverse DNS-el fel tudod oldani FQDN-re, az alapján elvileg a hostnév is beállítható.

Az open tools-nál egy fokkal jobb a gyári tools. A vcenter a tools-on keresztül customizálja a vm-et. Tehát, ha szeretnél egy hostnév változtatást, akkor fent kell lennie a tools-nak és kell egy megfelelő management eszköz, ami szót ért a vcenterrel.

Azt nem írtad, milyen verziójú vmware (vcenter és esx)

6.7 es ESXi hostok es a Vcenter is.

 

Amit en szeretnek, az a kovetkezo:

 

Fut az automatikus telepites, amikor vegzett, lefutna egy egyszeru bash script, ami "kideriti" az adott VM nevet es egy sima 

hostnamectl set-hostname <vm_neve>

parancsal beallitja.

A gondom az, hogy egy relative "szuz" Centos telepitessel hogyan oldjam ezt meg? Neztem a VMware REST api-t is, de nem nagyon talalok olyan kozos indexet ami alapjan le tudnam kerni az adott VM nevet... elv az UUID -t le tudom kerni a VM alatt is, es elv ez alapjan kereshetnek a REST apival... de nem talalom a szintaxist, mikepp tehetem ezt meg.

 

Neztem a vmware-toolbox-cmd nevu toolt, de azzal sem lehet sajna lekerni...

Még nem ismerem ezt az uyuni nevű csodát, de felvettem a "megismerkedni vele" listámra.

Viszont amivel most ismerkedem az a terraform és ezzel készítek vm-eket vmware alatt.

Ott a terraform kapcsolódik a vcenter-hez a maga provider-én keresztül és mondja meg neki, hogy mit kell beállítani a vm-en. Fontos, hogy jól legyen beállítva és ismerje is az adott guest os-t, mert innen tudja, hogy hova nyúljon pontosan, ha mondjuk a hálózati interfészt állít. (ubuntunál ne a /etc/network-be kotorásszon mondjuk)

A hostnevet is szépen beállítja.

A kiindulási alap egy előre elkészített template vm, amin be van számos olyan dolog már állítva, ami a terraform-hoz kell. Van rajta már tools, fent van egy user ssh kulcsostól és nem kér a sudo-nál jelszót.

(A saját célkitűzésem, hogy feltoljon egy működő openstack környezetet a hivatalos tesztkörnyezet alapján. Még nagyon az elején vagyok, mert többek között az sem segítség, hogy a teljes hivatalos terraform dokumentáció szintaxisa "deprecated", a fellelhető példakonfigok a vmware-hez szintén elavultak. De legalább tanul is közben az ember, mert itt nem tud copy-paste-el másolni.)

( Vamp | 2021. 03. 09., k – 18:13 )

Szerkesztve: 2021. 03. 09., k – 18:13

Most a VMware REST api-it nezegetem. ha valahogy tudnek MAC-re/ vagy ID-re szurni (es az alapjan meghatarozni a VM nevet) akkor nyert ugyem lenne es a kliens gepre csak egy curl kene... Egy uyuni autoinstallation post scriptel pedig be tudnam igy allitani a hostnevet.

( Vamp | 2021. 03. 10., sze – 00:46 )

Szerkesztve: 2021. 03. 10., sze – 01:05

Vegul csak pyVmomi lett (ugy voltam vele, az a 400kb nem faj, python meg ugyis van a Centos-eken... )

 

Viszont itt is van egy kis bibi... UUID alapjan probalnam osszeparositani a gepeket, de valami nem kerek..

Lekerem dmidecode-al az UUID-t es ez jon:

 

0c4c1742-cfb6-6552-e799-a133cd9e7050

 

Viszont, ha megnezem a vmx fajlban, ezt latom:

 

uuid.bios = "42 17 4c 0c b6 cf 52 65-e7 99 a1 33 cd 9e 70 50"

 

Nyilvan a hasonlosag szembetuno , ugyanazok a karakter parok vannak mindkettoben csak nem ugyanazon sorrendben.... Igy nyilvan a script nem talalja a VM-et...

 

a python script igy nez amugy ki:

 

#!/usr/bin/env python
import atexit
import pyVmomi
import ssl

from pyVmomi import vim, vmodl
from pyVim.connect import SmartConnect, Disconnect


context = ssl._create_unverified_context()
si = SmartConnect(host='hostname', port='443', user='username', pwd='pass', sslContext=context)


atexit.register(Disconnect, si)
file = open('/sys/devices/virtual/dmi/id/product_uuid')
uuid = file.read().strip().lower()
file.close()

search_index = si.content.searchIndex
vm = search_index.FindByUuid(None, uuid, True, False)

print vm.summary.config.name

 

 

Meg annyi, hogy igy amugy mukodik. Viszont abban nem vagyok biztos, hogy amikor lefutna, mar olyan allapotban lesz az open-vm-tools, hogy adni fog IP-t... Ezert lenne jobb az UUID modszer.

 

#!/usr/bin/env python
import atexit
import pyVmomi
import ssl
import socket

from pyVmomi import vim, vmodl
from pyVim.connect import SmartConnect, Disconnect


ip = ((([ip for ip in socket.gethostbyname_ex(socket.gethostname())[2] if not ip.startswith("127.")] or [[(s.connect(("8.8.8.8", 53)), s.getsockname()[0], s.close()) for s in [socket.socket(socket.AF_INET, socket.SOCK_DGRAM)]][0][1]]) + ["no IP found"])[0])

context = ssl._create_unverified_context()
si = SmartConnect(host='hostname', port='443', user='username', pwd='pass', sslContext=context)


atexit.register(Disconnect, si)

search_index = si.content.searchIndex

vm = search_index.FindByIp(None, ip, True)

name = vm.summary.config.name

print name.lower()

Lekerem dmidecode-al az UUID-t es ez jon:

0c4c1742-cfb6-6552-e799-a133cd9e7050

Viszont, ha megnezem a vmx fajlban, ezt latom:

uuid.bios = "42 17 4c 0c b6 cf 52 65-e7 99 a1 33 cd 9e 70 50"

Nincs időm most kirakni a konkrétat, de az alsó valami elbaszás, ami  little endiannak tűnik, de kb a kötőjelek mentén darabolva. Egyrészt az uuid.UUID talán initelhető fieldek alapján , és lehet neki byte ordert mondani, másrészt meg szétszeded, és vagy az int.to_bytes / .from_bytes, meg utána a bytes.int, vagy ugyanez a struct modullal, és a jól forgatott inttel meg már csinálhatsz UUIDt és hasonlítgathatod.

Piszkált, megnéztem :D

Elég hányás az egész (az utolsó taktus nincs fordítva), szóval elég olvashatatlan egy hányás (tuti, hogy azt an unhexet meg az intet lehet valahogy nem ilyen randán), de:

 

>>> from binascii import unhexlify                                                                                                                                                          

>>> u = '0c4c1742-cfb6-6552-e799-a133cd9e7050'                                                                                  

>>> u_vmdk = "42 17 4c 0c b6 cf 52 65-e7 99 a1 33 cd 9e 70 50"                                                                                                                              

>>> u_vmdk_iterator = iter(u_vmdk.replace(' ', '').replace('-', ''))                                                                                                                        

>>> fields = [int.from_bytes(unhexlify(''.join(next(u_vmdk_iterator) for _ in range(size))),'little') for size  in (8,4,4,2,2)]                                                             

>>> fields.append([int.from_bytes(unhexlify(''.join(next(u_vmdk_iterator) for _ in range(12))),'big')][0])                                                                                  

>>> uuid_vmdk = UUID(fields=fields)                                                                                                                                                         

>>> uuid_dmidecode = UUID(u)                                                                                                                                                                

>>> uuid_dmidecode                                                                                                                                                                          
UUID('0c4c1742-cfb6-6552-e799-a133cd9e7050')

>>> uuid_vmdk                                                                                                                                                                               
UUID('0c4c1742-cfb6-6552-e799-a133cd9e7050')


>>> uuid_vmdk == uuid_dmidecode                                                                                                                                                             
True

> Igen, Centos7-esek a kliensek (meg nem leptuk meg az update-et, a jelenlegi helyzetben az sem biztos, h meglepjuk egyaltalan...)

Persze. A jajjajj annak szólt, hogy bár a python2->3 körül nagy a sírás, de a gyakorlatban ez többnyire egy jó seddel kezelhető szokott lenni. Kivéve, ha bitbaszni kell, mert pont az str, byte, és ilyesmit fordították erősen fejre (és lett elvhelyes egyébként), szóval ott pont gondolkodni kell, nem lehet agy nélkül replacelni.

> Meg az iranyt is meg kell valtoztatnom, mert ugye a dmidecode az adott, azt kell az ESXi formajara hoznom.

ja, hogy azt kell felküldd, nem lehet mindkettőt helyretenni. Hát, akkor sajna ugyanez vissza, bár az talán kicsit egyszerűbb, mert kb csinálsz belőle egy UUID-t, a fieldsben ott van a minden intben, azt kell átforgatni little endianra (kivéve az utolsót), azt a ranges filteres borzalmat ki lehet hagyni.

Meg ki kell deritenem, hogy pontosan milyen formaban van tarolva, pontosabban a pyvmomi hogyan keresi ESXi oldalon a UUID-t. mert az, amit beillesztettem, az a vmx fajlbol van, nem tudom, hogy a pontos formatum milyen.

 

szerk: meg is van: 42174c0c-b6cf-5265-e799-a133cd9e7050

Kesz a cucc. Nem szep, de legalabb csunya :D

 

Ellenben mukodik:

 

import atexit
import pyVmomi
import ssl

from pyVmomi import vim, vmodl
from pyVim.connect import SmartConnect, Disconnect

domain = "domain"

context = ssl._create_unverified_context()
si = SmartConnect(host='hostname', port='443', user='username', pwd='pass', sslContext=context)


atexit.register(Disconnect, si)
file = open('/sys/devices/virtual/dmi/id/product_uuid')
uuid = file.read().strip().lower()
file.close()

uuidString = uuid.replace("-","")

newOrder = [6,7,4,5,2,3,0,1,10,11,8,9,14,15,12,13]
for i in range(16, len(uuidString)): newOrder.append(i)

uuid_string = str.join('', [uuidString[i] for i in newOrder])

uuid_string = uuid_string[:8] + '-' + uuid_string[8:]
uuid_string = uuid_string[:13] + '-' + uuid_string[13:]
uuid_string = uuid_string[:18] + '-' + uuid_string[18:]
guid = uuid_string[:23] + '-' + uuid_string[23:]


search_index = si.content.searchIndex
vm = search_index.FindByUuid(None, guid, True, False)

hostname = vm.summary.config.name.lower()

fqdn = hostname + domain

subprocess.call(["hostnamectl", "set-hostname", fqdn])

subprocess.call(["hostnamectl", "set-hostname", "--pretty", hostname])

 

A wiki szocikk segitett. ezek szerint a linux "szabvanyos" (ugye a wiki azt irja a big-endian a legelterjedtebb formatum. a VMware viszont a microsoft fele mixed-endian-t hasznalja (....) szoval lenyegeben csak a sorrendet kellett beloni.

 

Koszi megegyszer a segitseget, elinditottal a helyes uton :)

 

Szerk: igy van teljesen kesz. Hozzadtam a hostname beallitast is. most mar csak tesztelni kell....:)

No problem, azert osztottam meg, hogy mas is tudja hasznalni :)

 

Jelenleg a domain join van porondon:

 

#!/bin/sh
hostname=$(/bin/curl http://10.51.38.74/pub/join_domain.py | /usr/bin/python)


/usr/bin/echo pass|/usr/sbin/realm join domain.local --computer-name="${hostname}" --user=username --computer-ou="OU=Server" -v

/usr/bin/sed -i -e 's/use_fully_qualified_names = True/use_fully_qualified_names = False/g' /etc/sssd/sssd.conf

/usr/bin/sed -i -e 's/%u@%d/%u/g' /etc/sssd/sssd.conf

 

Problema jelenleg hasonlo... telepitett gepen problema nelkul lefut, kickstart post scriptkent kiall hibaval, hogy nem jo a hostname...

 

(a domain_join.py ugyanaz mint a fenti, csak a kimenet itt nem az fqdn hanem a gepnev)

Na a mai nap margojara :D

 

Sajnos Kickstart scriptel nem tudtam megoldani, mert hiaba adtam meg a "--cumputer-name" kapcsolot, akkor is kellett neki a jol beallitott hostname. Amihez meg restart kellett... Ezert azt talaltam ki, hogy a telepites utani reboot utan futtatom a domain csatlakozast (amikor mar jo a hostname)

 

Szal igy nez ki a script:

 

chmod +x /etc/rc.d/rc.local

echo -e "function finish {\n\nshred -u /root/domain_join_data.sh;\n\n}\n\n/usr/bin/echo pass|/usr/sbin/realm join domain --user=user --computer-ou="OU=Server"\n\n/usr/bin/sed -i -e 's/use_fully_qualified_names = True/use_fully_qualified_names = False/g' /etc/sssd/sssd.conf\n\n/usr/bin/sed -i -e 's/%u@%d/%u/g' /etc/sssd/sssd.conf\n\nchmod -x /etc/rc.d/rc.local\n\nsed -i '""$"""d"' /etc/rc.d/rc.local\n\ntrap finish EXIT" > /root/domain_join_data.sh

chmod +x /root/domain_join_data.sh

echo "/root/domain_join_data.sh" >> /etc/rc.d/rc.local

 

Eloszor futtathatova teszem a rc.local-t aztan letrehozok egy shell scriptet a root konyvtarban amit szinten futtathatova teszek. majd ezt beszurom a rc.local-ba.

 

Maga a script elvegzi a domainba illesztest, meg par finomhangolast az sssd.conf ban (ahogy mi szeretjuk :) ) majd elveszi a futasi jogot az rc.local-tol illetve kitorli a tartalmat, majd a legvegen sajat magat is torli :) 

 

Rohadt kusza tudom, lehetne csinositani, de egyelore megteszi.

Hmm... én már feladtam a "nyomjuk meg egyszer a gombot és kész a szerver" elvet, az ehhez hasonló okok miatt.

A telepítés (klónozás) legyárt egy alap image-et, ami rajta van a hálózaton nulla konfiggal, csak egy ssh szerver.
Aztán indítok egy ansible playbookot, ami ssh-n keresztül felkonfigurál mindent. Ezzel a módszerrel pl. a "hostnamectl set hostname"  - is beállítja jól a hostnevet.
Igazából annak nincs jelentőssége , hogy ansible-vagy bármi más, akár  salt-al is meg lehet csinálni.

Nekem is ez lenne a terv (csak uyuni miatt salt al) csak elotte akartam egy alapot.aztan ha specifikalni akarom valamire (DB, web, etc... )akkor azt mar tudom utolag.Csak azt a lepest akartam kihagyni h a telepites utan nyomni kelljen meg egy gombothogy megkapja a configot is...:)

Jelenleg minden modosithato, uyuni oldalrol. meg domainba leptetes adatai is onnan toltodnek at. (direkt nem akartam semmi statikus fajlt a telepitobe integralni, eztert toltom az a scriptet is ugy, ahogy)

jelenleg ennyi mindent csinal. Mast nagyon nem is tervezek. Ezek elegge static dolgok. Minden masra ott a Configuration meg az Actions

https://www.uyuni-project.org/uyuni-docs/uyuni/reference/configuration/config-overview.html

https://www.uyuni-project.org/uyuni-docs/uyuni/administration/actions.html

 

Script Type       Script Name                       Scripting Language
Post              add_uyuni                         bash
Post              install_pyvmomi                   bash
Post              change_hostname                   bash
Post              enable_cockpit                    bash
Post              add_admins_to_sudoers             bash
Post              uninstall_pyvmomi                 bash
Post              copy_domain_join_data             bash
Post              Registration and server actions   Not Applicable

 

Pl bar kickstartal allitom be az sssd.conf-ot, illetve a sudoers.d-ben levo cuccokat, ezeket a kliensek kesobb a configuration channelbol kapjak. Csak az elso telepiteskor jon kickstart bol.

 

Amugy a Action Chain-el tok jo folyamatokat lehet mar utana letrehozni. Szuperul ossze lehet fogni az Uyuni 3 alappilleret (Package management,Configuration files, Remote command)

https://www.uyuni-project.org/uyuni-docs/uyuni/reference/schedule/actio…

Pl MySQL telepiteshez eloszor beleraksz egy package installt, majd egy Configuration file copy-t a parameterezett my.conf-ra, esetleg teljes DB copyra, aztan meg Action-kent a vegere egy sql restore-t, vagy egy szolgaltatas ujrainditast, esetleg egy teljes ujrainditast. Igy szepen lefut a folyamat beavatkozas nelkul.

Ismerem a konfig menedzsmentjét, én mondjuk Suse Managerrel dolgozok már pár éve, de az ugyanaz, csak fáziskéséssel.

Én tisztán salt-ban szertném megcsinálni ezeket a dolgokat, nem shell scriptekkel, csak nehéz átállítani az agyam ansible-ről salt-ra.  Elkezdtem csinálni, de az igények folyton jönnek, úgyhogy mindíg ott kötök ki, hogy az ansible-t fejlesztem tovább.
Elvileg a salt is python alapú, meg yaml és jinja, akárcsak az ansible de valahogy jobban rá áll az agyam az ansible logikájára. Viszont a salt alapból jobban skálázódik mint az ansible, extra reszelés nélkül is nagyobb a párhuzamosság, úgyhogy ezt a részt még nem adtam fel teljesen. (rajta van a meg kell tanulni listán)

A bajom az, hogy amit az Uyuni (Suse Manager) webes felületén meg lehet csinálni, az eléggé statikus. Én elég sok változóval dolgozok, sok jinja template-el, hostonkénti kivétel változókkal, amiket a webes felülettel nem látom hogy lehet megoldani.  De lehet, hogy lehet, még csak keveset foglalkoztam vele.
Ami viszont a webes konfig menedzsment részben tetszik, az a verzió kezelés.  (Mondjuk az ansible cuccokat is gitben tárolom, de azt nekem kellett megoldani, itt meg készen benne van.)

 

 

 

Be tudsz építeni a scriptbe várakozást. Vagyis, ha nem ad vissza értelmezhető IP-t, akkor várjon kicsit, és próbálja újra x másodperc múlva.
AZ UUID módszer annyiban nem tetszi, hogy az előállítási módja nem tudom mennyire konyisztens is, szóval  időnkéntakár változhat is, akárcsak a vmtools által visszaadott string.

 

Amúgy mi a gond a template-ből klónolással? Ott nincs ilyen szívás.
 

Az jó, ha neked belefér, de erősen use-case függő. Egy csomó esetben az, hogy minden új image az elmúlt 2-3 évet be apt/yum/akármi updateli deploy után, az nem mindig szerencsés. Mivel jellemzően kézzel kell összelapátolni, ezért nehezen reprodukálható, ráadásul mindenféle (distro specifikus) matatást is sokszor el kell követni a végén, ami könnyen kimarad (mac címet éppen melyik persistentből kell kibaszni ugye). Elképzelhető, hogy származtatnál belőle valami deviáns verziót, akkor ez még jobban fáj. Ha még esetleg olyan igényeid is vannak, hogy nem csak vmwaren akarod használni, akkor sokkal jobb valami, amit értelmesen lehet kezelni máshol is, és reprodukálható.

A filerendszer testreszabás is olyan, hogy pl a mekkora legyen benne a disk nem egy teljesen triviális kérdés.

Illetve -- bár ez nyilván egyszocprob -- az a perles customizer még a cloud initnél is szarabb, pedig ahhoz azért dolgozni kell.

"Egy csomó esetben az, hogy minden új image az elmúlt 2-3 évet be apt/yum/akármi updateli deploy után, az nem mindig szerencsés. "

Ha ISO-ból telepítesz, akkor is van update. Egyébként meg időnként igény szerint rágörgethetők a template-ra is a patchek.

Mivel jellemzően kézzel kell összelapátolni, ezért nehezen reprodukálható, ráadásul mindenféle (distro specifikus) matatást is sokszor el kell követni a végén, ami könnyen kimarad (mac címet éppen melyik persistentből kell kibaszni ugye).

Bármi ami a next-next finish installon túlmutat, már ansible-ből megy, ami bármikor pontosan reprodukálható. Semmi kézi matatás utólag.

File rendszer testreszabás csak annyi, hogy kialakítom azt, ami külön FS-t igényel, minimál méretben. 1db boot és 1db LVM partíció van rajta.  Klónolás után az LVM partíciót automatikusan kiterjeszti a provisioning a diszk max. méretére. A file rendszerek klónolás után igény szerint variálhatók, ha a default nem lenne megfelelő.

"Ha még esetleg olyan igényeid is vannak, hogy nem csak vmwaren akarod használni, akkor sokkal jobb valami, amit értelmesen lehet kezelni máshol is, és reprodukálható."

Mivel minden módosítás  ansible-el megy, ezért ha fizikai vasat telepítek, akkor ISO boot és next-next finish után is rámegy ugyanaz a provisioning script, és megcsinál minden beállítást.
 

Nem kötözködök, tényleg érdekel a pro és kontra.

A bootszerveres provisioning nálam azért nem játszik, mert több tucanyit különféle VLAN-on  levő szervert kell menedzselni (mármint VLAN-ból van tucatnyi, szerverből némileg több), és semmilyen hálózatról bootolás nem oldható meg (abba, most nem menjünk bele, hogy miért. ez van, és kész.)

> Nem kötözködök, tényleg érdekel a pro és kontra.

Egyáltalán nem vettem annak, nem tartom a templatet ördögtől valónak.

> Ha ISO-ból telepítesz, akkor is van update. Egyébként meg időnként igény szerint rágörgethetők a template-ra is a patchek.

Persze, a delta nem mindegy. És ha már patchelni kell, akkor az már pont az a lifecycle, amit meg kell oldani, mert nem az van, hog 2-3 évente csinálok egy templatet.

> Bármi ami a next-next finish installon túlmutat, már ansible-ből megy, ami bármikor pontosan reprodukálható. Semmi kézi matatás utólag.

Az image patchelés is? Mert persze lehet, de az jellemzően úgy megy, hogy rendesgép, megupdate, újra takarít, újra kiütni, hogy ez nem egy template. Szóval vagy kézi basz, vagy ezt is meg kell csinálni. Akkor meg már _lehet_, hogy egyszerűbb mondjuk cloud-imageből, van, akinek ebből van daily vagy weekly,, ha abból megy, nem templateből, akkor ezt az egész macerákot adott esetben elfelejtheted, egyszer megcsinálod, és friss lesz, elég csak a telepítés részét megoldani.

> Mivel minden módosítás  ansible-el megy, ezért ha fizikai vasat telepítek, akkor ISO boot és next-next finish után is rámegy ugyanaz a provisioning script, és megcsinál minden beállítást.

Persze. Én csak annyit mondtam, hogy ha egyébként ki lehet hagyni a tempaltet, mert lehet isobol/imageből ezt csinálni, mert ott van integráltan mondjuk a cloud-init, ami injektálja az ansible kulcsát, akkor én ezt jobban szeretem, mert nem kell még a template managementet is megoldani. Igazából az egész csak fókusz tologatás, mert ugyanazt csinálja meg mind, a kérdés, hogy épp melyikkel egyszerűbb ott, ahol éppen csinálni kell. (Mert egyébként mire pl a cloud-init configos isoját is mire összekalapálod, az is idő, meg vmomi fájdalom.

( Vamp | 2021. 03. 11., cs – 09:19 )

Szerkesztve: 2021. 03. 11., cs – 09:20

Hat meg nem teljes az orom... A scipt mar mukodik, de a kickstart post scriptben nem allitja at a hostnevet... Vagyis atallitja, (beraktam a scriptbe egy printet ami kiirja a hostnamectl eredmenyet, miutan lefutott a script) viszont a restart utan (amivel az uyuni befejezi az egeszet) megint localhost.localdomain.... 

 

Nem errtem mi lehet a gond.

Siker! Vegul az lett a megoldas, hogy shell sriptkent fut le az alabbi 

 

/bin/curl http://10.51.38.74/pub/hostname_change.py | /bin/python > /etc/hostname

a python scriptet atirtam h kimenetnek printelje az fqdn valtozot, majd felmasoltam az Uyuni public konyvtaraba, onnan hivja meg. Igy, hogy beirom direktbe a hostname fajlba, mukodik (vegre...)

 

Next step: Domainbe leptetes :D