subject:"\[rlug\] Plan de migrare Centos 6 \-> Centos 7"


On Mon, Jun 29, 2020 at 04:33:32PM +0300, Alex 'CAVE' Cernat wrote:

On 29-Jun-20 12:35 PM, Dumitru Moldovan wrote:

Tot cumva la subiect…  Am inclusiv câteva VM-uri cu Windows cu un setup
asemănător, până acuma am folosit Salt.  A fost un pic de chin pentru
noi, că-s cam bâtă în privința administrării Windows, dar funcționează
relativ bine, cu doar câteva bug-uri Salt minore, pentru care am găsit
alternative.  Are cineva idee de cât de bun e suportul Ansible pentru
administrarea de sisteme Windows?  Eventual în comparație cu Salt?
Mulțumiri anticipate!


din ce stiu (cultura generala dar pe care nu stiu cat de mult te poti
baza) ar suporta cu succes si geamurile, dar cum nu am avut nevoie nu
pot sa las niciun fel de feedback

mai curand as paria pe partea de echipamente de retea (switch-uri,
routere etc), unde are o groaza de module pentru o gama larga de device-uri

oricum, pe partea de linux/ansible mai toata lumea se orienteaza fie
spre redhat/centos (ca de ceva vreme ansible e marca redhat), fie spre
debian/ubuntu; asta nu inseamna ca nu poate merge pe orice linux, insa
marea majoritate a "galaxiei" ansible trateaza explicit mai ales
particularitatile distributiilor mai sus aminte


În cazul de față nu e alegerea mea pe ce sistem de operare trebuie
instalate și configurate chestii…  E vorba de testare automată pentru
toate platformele suportate de un anumit produs.  Windows nici măcar nu
e cea mai exotică țintă, mă bucur că am scăpat recent de monștri precum
Solaris, AIX ori HP-UX.

___
RLUG mailing list
RLUG@lists.lug.ro
http://lists.lug.ro/mailman/listinfo/rlug_lists.lug.ro

Re: [rlug] Plan de migrare Centos 6 -> Centos 7

2020-06-29 Fir de Conversatie Bogdan-Stefan Rotariu

On Jun 26, 2020, at 11:57, Adrian Popa  wrote:
> 
> Salut,
> Am mai multe servere cu Centos6 în subordine (unele fizice, altele
> virtuale). Văd că nu există o procedură suportată de upgrade la Centos7 (o
> să încerc distrorejuve pe un vm să vedem ce iese). Aş vrea să întreb - care
> a fost abordarea voastră în situaţii similare? Tentativă de upgrade, sau
> install pe curat? În caz de install pe curat, în afară de backup /etc,
> /home, date aplicaţii, listă pachete + install pe target + test aţi mai
> făcut şi alţi paşi? Există o procedură de reinstall cu portare
> setări/aplicaţii documentată pe undeva

Salut,

In trecut am facut cu succes dar cu mare efort upgrade de la centos 5 la centos 
6. Totusi, au ramas tot felul de ramasite, de la librarii la binare care nu mai 
apar prin rpmdb iar dupa experientele avute nu as mai face asta.

Noi avem un numar foarte mare de masini cu CentOS 6 cat si un numar mare de 
masini cu CentOS 7 iar fiindca configurarile sunt similare am putut sa le face 
provisionare prin puppet.

Dupa experienta upgradeului c5->c6, am inceput sa scriem module puppet care sa 
faca in mare parte tot ce este necesar pentru ca noul sistem sa fie functional 
fara a fi necesara interventia manuala.

Nu am testat inca CentOS 8 pe setupul actual, dar urmeaza sa facem planul 
necesar pentru a migra serviciile ce ruleaza acum pe c6 pe c8.

Problemele pe care le vad si pe care le-am intampinat sunt legate de versiunea 
masterului de puppet cat si a clientilor, aici au fost necesare diferite 
artificii pentru a putea suporta simultan si servere cu os modern cat si 
legacy(c6,debian{6,7},ubuntu{12,14}.04.

La fel cum au spus si colegii, trebuie sa vezi exact ce vrei si sa alegi 
solutia de provisionare corecta.

___
RLUG mailing list
RLUG@lists.lug.ro
http://lists.lug.ro/mailman/listinfo/rlug_lists.lug.ro

Re: [rlug] Plan de migrare Centos 6 -> Centos 7

On 29-Jun-20 12:35 PM, Dumitru Moldovan wrote:
> Tot cumva la subiect…  Am inclusiv câteva VM-uri cu Windows cu un setup
> asemănător, până acuma am folosit Salt.  A fost un pic de chin pentru
> noi, că-s cam bâtă în privința administrării Windows, dar funcționează
> relativ bine, cu doar câteva bug-uri Salt minore, pentru care am găsit
> alternative.  Are cineva idee de cât de bun e suportul Ansible pentru
> administrarea de sisteme Windows?  Eventual în comparație cu Salt?
> Mulțumiri anticipate! 

din ce stiu (cultura generala dar pe care nu stiu cat de mult te poti
baza) ar suporta cu succes si geamurile, dar cum nu am avut nevoie nu
pot sa las niciun fel de feedback

mai curand as paria pe partea de echipamente de retea (switch-uri,
routere etc), unde are o groaza de module pentru o gama larga de device-uri

oricum, pe partea de linux/ansible mai toata lumea se orienteaza fie
spre redhat/centos (ca de ceva vreme ansible e marca redhat), fie spre
debian/ubuntu; asta nu inseamna ca nu poate merge pe orice linux, insa
marea majoritate a "galaxiei" ansible trateaza explicit mai ales
particularitatile distributiilor mai sus aminte

Alex



___
RLUG mailing list
RLUG@lists.lug.ro
http://lists.lug.ro/mailman/listinfo/rlug_lists.lug.ro

Re: [rlug] Plan de migrare Centos 6 -> Centos 7

On 29-Jun-20 1:30 PM, Dumitru Moldovan wrote:
> On Mon, Jun 29, 2020 at 01:12:04PM +0300, Alex 'CAVE' Cernat wrote:
>> Scrie atât în documentație cât și pe ecran când îl instaleaza, nu e
>> nimic
>> pe la spate. Doar ca nu e ceva ce tu ai instalat EXPLICIT!
>
> Ok, de înțeles.  Dar ideea e că ce am în repo-ul cu regulile Salt /
> Ansible / etc. e persistent, pe când output-ul ce zboară doar la mine
> pe ecran o singură dată la prima aplicare e ceva volatil.  Un fel de
> „verba volant, scripta manent” în accepțiune IT.
>
> De gustibus…  :-]
>
m-am uitat acum prin documentatie si nu pare sa scrie ca se
auto-instaleaza, dar modulul de python-apt / python3-apt e trecut ca si
dependinta; mai mult chiar, daca faci doar check va da eroare ca nu e
instalat si nu va trece mai departe

avand in vedere ca apt-ul e unul din modulele fara de care nu poti trai
pe Debian, n-as putea sa zic ca acest side-effect e chiar suparator, ba
chiar dimpotriva ... doar sa stii de el ca exista (cred ca mai nou l-am
bagat si ca default in lista pachetelor de instalat, sa scap de o grija :-P)

altele sunt chestii mult mai stresante, de genul: atentie mare la roluri
/ task-uri incluse cu when, ca handler-urile "mostenesc" when-ul, si
s-ar putea sa te trezesti ca in anumite cazuri nu se executa, desi din
punctul de vedere ai unei programari iterative ai zice ca totul e ok...

Alex

___
RLUG mailing list
RLUG@lists.lug.ro
http://lists.lug.ro/mailman/listinfo/rlug_lists.lug.ro

Re: [rlug] Plan de migrare Centos 6 -> Centos 7


On Mon, Jun 29, 2020 at 01:12:04PM +0300, Alex 'CAVE' Cernat wrote:

Scrie atât în documentație cât și pe ecran când îl instaleaza, nu e nimic
pe la spate. Doar ca nu e ceva ce tu ai instalat EXPLICIT!


Ok, de înțeles.  Dar ideea e că ce am în repo-ul cu regulile Salt /
Ansible / etc. e persistent, pe când output-ul ce zboară doar la mine
pe ecran o singură dată la prima aplicare e ceva volatil.  Un fel de
„verba volant, scripta manent” în accepțiune IT.

De gustibus…  :-]


___
RLUG mailing list
RLUG@lists.lug.ro
http://lists.lug.ro/mailman/listinfo/rlug_lists.lug.ro

Re: [rlug] Plan de migrare Centos 6 -> Centos 7

Scrie atât în documentație cât și pe ecran când îl instaleaza, nu e nimic
pe la spate. Doar ca nu e ceva ce tu ai instalat EXPLICIT!

On Mon, 29 Jun 2020, 13:08 Dumitru Moldovan,  wrote:

> On Mon, Jun 29, 2020 at 12:58:39PM +0300, Alex 'CAVE' Cernat wrote:
> >Ca exemplu, modulul ansible de apt are nevoie de python-apt sau python
> >3-apt pe client. Dacă nu îl ai deja instalat, ți-l instalează. Altul nu-mi
> >aduc aminte momentan, dar am lăsat rezerva.
>
> Ah, ok, mulțam!  Bine de știut…  Mi se pare de prost gust să instaleze
> el chestii de capul lui, dar poate îs mai de modă veche.  Salt doar îți
> zice ce-ți lipsește sau ți-ar prinde bine.
>
>
> ___
> RLUG mailing list
> RLUG@lists.lug.ro
> http://lists.lug.ro/mailman/listinfo/rlug_lists.lug.ro
>
___
RLUG mailing list
RLUG@lists.lug.ro
http://lists.lug.ro/mailman/listinfo/rlug_lists.lug.ro

Re: [rlug] Plan de migrare Centos 6 -> Centos 7


On Mon, Jun 29, 2020 at 12:58:39PM +0300, Alex 'CAVE' Cernat wrote:

Ca exemplu, modulul ansible de apt are nevoie de python-apt sau python
3-apt pe client. Dacă nu îl ai deja instalat, ți-l instalează. Altul nu-mi
aduc aminte momentan, dar am lăsat rezerva.


Ah, ok, mulțam!  Bine de știut…  Mi se pare de prost gust să instaleze
el chestii de capul lui, dar poate îs mai de modă veche.  Salt doar îți
zice ce-ți lipsește sau ți-ar prinde bine.


___
RLUG mailing list
RLUG@lists.lug.ro
http://lists.lug.ro/mailman/listinfo/rlug_lists.lug.ro

Re: [rlug] Plan de migrare Centos 6 -> Centos 7

Ca exemplu, modulul ansible de apt are nevoie de python-apt sau python
3-apt pe client. Dacă nu îl ai deja instalat, ți-l instalează. Altul nu-mi
aduc aminte momentan, dar am lăsat rezerva.

On Mon, 29 Jun 2020, 12:37 Dumitru Moldovan,  wrote:

> On Sun, Jun 28, 2020 at 04:31:37PM +0300, Alex 'CAVE' Cernat wrote:
>
> […]
>
> >toate astea cu absolut nimic instalat in plus pe "client", decat un
> >acces ssh si python-ul, care oricum e instalat by default din ce stiu eu
> >cam pe orice distributie de linux (si pe alocuri vreo 2-3 pachete de
> >python instalate automat de catre ansible la momentul necesar).
>
> Err… nope.  Tocmai m-am apucat să învăț Ansible și am început cu niște
> VM-uri cu Alpine Linux, pentru că acolo oricum aveam probleme cu Salt
> în ultima vreme.  Python nu e instalat implicit și pun pariu că Alpine
> nu e o excepție în privința asta.
>
> Dar chestia de mai sus e minoră.  Ce mă miră mai tare e e chestia cu
> „2-3 pachete de python instalate automat”.  Deocamdată n-am văzut așa
> ceva…  Face Ansible chestii din astea pe la spate?  Nu-s expert nici în
> Alpine, dar modulele de Python împachetate apk par să aibă toate nume
> ce încep cu „py”.  N-am asemenea pachete pe VM-urile configurate prin
> Ansible să funcționeze ca clienți NFS, Zabbix și Buildbot, deci un
> setup nu foarte, foarte simplu.
>
> Tot cumva la subiect…  Am inclusiv câteva VM-uri cu Windows cu un setup
> asemănător, până acuma am folosit Salt.  A fost un pic de chin pentru
> noi, că-s cam bâtă în privința administrării Windows, dar funcționează
> relativ bine, cu doar câteva bug-uri Salt minore, pentru care am găsit
> alternative.  Are cineva idee de cât de bun e suportul Ansible pentru
> administrarea de sisteme Windows?  Eventual în comparație cu Salt?
> Mulțumiri anticipate!
>
>
> ___
> RLUG mailing list
> RLUG@lists.lug.ro
> http://lists.lug.ro/mailman/listinfo/rlug_lists.lug.ro
>
___
RLUG mailing list
RLUG@lists.lug.ro
http://lists.lug.ro/mailman/listinfo/rlug_lists.lug.ro

Re: [rlug] Plan de migrare Centos 6 -> Centos 7


On Sun, Jun 28, 2020 at 04:31:37PM +0300, Alex 'CAVE' Cernat wrote:

[…]


toate astea cu absolut nimic instalat in plus pe "client", decat un
acces ssh si python-ul, care oricum e instalat by default din ce stiu eu
cam pe orice distributie de linux (si pe alocuri vreo 2-3 pachete de
python instalate automat de catre ansible la momentul necesar).


Err… nope.  Tocmai m-am apucat să învăț Ansible și am început cu niște
VM-uri cu Alpine Linux, pentru că acolo oricum aveam probleme cu Salt
în ultima vreme.  Python nu e instalat implicit și pun pariu că Alpine
nu e o excepție în privința asta.

Dar chestia de mai sus e minoră.  Ce mă miră mai tare e e chestia cu
„2-3 pachete de python instalate automat”.  Deocamdată n-am văzut așa
ceva…  Face Ansible chestii din astea pe la spate?  Nu-s expert nici în
Alpine, dar modulele de Python împachetate apk par să aibă toate nume
ce încep cu „py”.  N-am asemenea pachete pe VM-urile configurate prin
Ansible să funcționeze ca clienți NFS, Zabbix și Buildbot, deci un
setup nu foarte, foarte simplu.

Tot cumva la subiect…  Am inclusiv câteva VM-uri cu Windows cu un setup
asemănător, până acuma am folosit Salt.  A fost un pic de chin pentru
noi, că-s cam bâtă în privința administrării Windows, dar funcționează
relativ bine, cu doar câteva bug-uri Salt minore, pentru care am găsit
alternative.  Are cineva idee de cât de bun e suportul Ansible pentru
administrarea de sisteme Windows?  Eventual în comparație cu Salt?
Mulțumiri anticipate!


___
RLUG mailing list
RLUG@lists.lug.ro
http://lists.lug.ro/mailman/listinfo/rlug_lists.lug.ro

Re: [rlug] Plan de migrare Centos 6 -> Centos 7

Salut

In primul rand cum se zice la noi "la mulțean!", deci o sa ma limitez
azi la a face mega polemici :-P

Asimov vs. Herbert, coca coca vs. pepsi, push vs. pull ... subiecte mai
mult sau mai putin filosofice de discutat la un pahar de vorba ...
Polemica intre push si pull e mare si pe internet, dar am gasit un
"landmark" care, vorba poetului, "face sens": pentru chestiile statice
si cvasi-statice push, pentru chestii dinamice si mega-dinamice pull.
Sau eventual direct best of both worlds, dupa gusturi.

La push (cel putin pentru ansible) ai sarit totusi peste o chestie
mega-importanta, si anume idempotenta. Daca ai dat definitie de
push/pull, sa dau si eu una: idempotenta => rezultatul final ar trebui
sa fie acelasi fie ca rulezi o data, de doua, de zece ori sau de mii de
ori aceeasi chestie. Singura chestie ar fi sa nu o rulezi de 2 ori in
paralel in acelasi moment, ca in unele cazuri s-ar putea sa dea cu
virgula (in conditiile in care se fac si modificari la momentul
respectiv). La fel, nu conteaza ca e un server, ca sunt 10, 100, 1000
sau chiar mai multe, nu te apuci tu sa intri pe fiecare, ci face
CM_push-ul pentru tine, cel mai probabil in paralel. Desigur, de la un
punct in colo (mii / zeci de mii de masini) un sistem pull posibil poate
scala mai bine pentru ca workloadul se imparte per interval (nu se
executa job-urile in acelasi timp), doar ca incepi sa pierzi controlul
in ceea ce priveste CAND se intampla lucrurile, ceea ce s-ar putea
conteze, s-ar putea sa nu. In plus la un sistem pull se vor consuma
resurse inutil de fiecare data cand verifica configuratiile locale,
chiar daca TU stii prea bine ca nu s-a facut nicio modificare (in schimb
e o metoda in plus de detectie ca cineva de-al casei sau nu neaparat
si-a bagat nasul pe unde nu trebuia - ma rog, nu o metoda pe care sa te
si bazezi ca intrusion detection).
Iar aia cu "am facut eu asta, tu faci aia", cat timp exista un
uber-scenariu (sau mai multe) nu-si are sensul, in acel uber-scenariu ai
definit tot ce misca (binenteles, totul definit granular, ca sa poti
rula pe bucati). Pentru ca exista idempotenta, ajunge sa rulezi bucata
de care ai nevoie (poate sa fie acel uber-playbook, sau doar unul sau
mai multe bucati / roluri, sau doar un simplu task, si asta pe un singur
server, un grup de servere sau ce vrei, libertatea fiind deplina). Cum
iti organizezi bucataria, iarasi, depinde de bucatari.

In fine, o discutie de genul push/pull nu cred ca se poate termina
vreodata, ambele variante au plusuri si minusuri si din fericire e loc
pentru ambele pe lume.

Insa pentru cultura mea generala as fi curios cum vezi tu urmatorul
scenariu pe varianta "pull" (ca pe push ar fi doar o insiruire de
task-uri cu niste parametri):
- update sa zicem de kernel la un "cluster" de 12 (sau 24, sau 100, cate
vrei) sa zicem in spatele unor LB, cu reboot inclus, astfel incat sa nu
fie mai mult de 1 (2, 5, 10, 20 ...) server(e) down la un moment dat (ca
altfel s-au dus naibii performantele clusterului) si in worst case de 1,
2, 3, x erori sa se opreasca toata procedura
(aici puristii cu containere ar zice clar - ma rog, NU la update de
kernel, ca nu e cazul: deploy new containers and dispose old ones, ca
asa e treaba in 2020)
sau daca iti place mai mult ideea cu un cluster de măria cu 3, 5, 7, 9,
x servere be my guest ... ideea e ca doar un numar limitat de servere
pot fi afectate la un moment dat, iar procedura sa se poata opri automat
atunci cand erorile trec de un anumit prag

Alex

On 28-Jun-20 5:06 PM, Petru Rațiu wrote:
> On Sun, Jun 28, 2020 at 4:33 PM Alex 'CAVE' Cernat  wrote:
>
>> Si nu stiu ce-l deranja pe Petru ca e push, pentru ca pana la urma tu
>> decizi cand vrei modificarile, nu cand "vrea muschiul serverului" (de
>> asta am injurat puppet-ul la inceput, pe urma au bagat si partea de
>> meckanize).
>
> Asta e tot clenciul: nu vreau sa fac eu lucrurile _acum_, vreau sa descriu
> la un moment dat cum sa fie si ele sa se aplice continuu pe servere as
> needed. Push inseamna ca lucrurile le triggerezi tu pe server ad-hoc, care
> server trebuie sa fie available si intr-o stare care sa poata prelua
> schimbarile alea. Pull inseamna ca nu ma leg eu la server, daca maine fac
> altul va face fix acelasi lucru, fara sa trebuiasca sa-mi aduc aminte sa-i
> zic eu ce e de facut. Also, cand ai cateva zeci-sute-mii de servere, vrei
> sa-si faca ele in paralel treburile, nu sa te duci pe fiecare (plus ca e
> mereu unul care e down for maintenance si trebuie sa-l tii minte si sa
> revii cand e cazul etc). Also cand lucrezi in stil push incepi sa ai
> probleme de coordonare cand sunteti mai multi "ai facut tu aia, o fac eu,
> etc". Nu zic ca nu se poate dar scula nu te incurajeaza sa evoluezi in
> directia asta, e pe abordarea "un baiat cu 5 servere". Cand sunteti 5 si
> sunt cateva sute iti dai seama ca trebuie schimbata abordarea, nu mai merge
> cu "sa fac aceleasi lucruri dar mai mult / mai repede".
>
> Pe scurt, vreau sa fiu inginer de sistem care descrie cum sa

Re: [rlug] Plan de migrare Centos 6 -> Centos 7

2020-06-28 Fir de Conversatie Petru Rațiu

On Sun, Jun 28, 2020 at 4:33 PM Alex 'CAVE' Cernat  wrote:

> Si nu stiu ce-l deranja pe Petru ca e push, pentru ca pana la urma tu
> decizi cand vrei modificarile, nu cand "vrea muschiul serverului" (de
> asta am injurat puppet-ul la inceput, pe urma au bagat si partea de
> meckanize).

Asta e tot clenciul: nu vreau sa fac eu lucrurile _acum_, vreau sa descriu
la un moment dat cum sa fie si ele sa se aplice continuu pe servere as
needed. Push inseamna ca lucrurile le triggerezi tu pe server ad-hoc, care
server trebuie sa fie available si intr-o stare care sa poata prelua
schimbarile alea. Pull inseamna ca nu ma leg eu la server, daca maine fac
altul va face fix acelasi lucru, fara sa trebuiasca sa-mi aduc aminte sa-i
zic eu ce e de facut. Also, cand ai cateva zeci-sute-mii de servere, vrei
sa-si faca ele in paralel treburile, nu sa te duci pe fiecare (plus ca e
mereu unul care e down for maintenance si trebuie sa-l tii minte si sa
revii cand e cazul etc). Also cand lucrezi in stil push incepi sa ai
probleme de coordonare cand sunteti mai multi "ai facut tu aia, o fac eu,
etc". Nu zic ca nu se poate dar scula nu te incurajeaza sa evoluezi in
directia asta, e pe abordarea "un baiat cu 5 servere". Cand sunteti 5 si
sunt cateva sute iti dai seama ca trebuie schimbata abordarea, nu mai merge
cu "sa fac aceleasi lucruri dar mai mult / mai repede".

Pe scurt, vreau sa fiu inginer de sistem care descrie cum sa fie sistemul,
nu meserias de sistem care il ia mereu la ciocan si cheie franceza. Fiecare
abordare are nivelul de scara unde e mai eficienta, dar e diferenta intre
ele e mai profunda decat de cat de shiny si yaml-istice sunt sculele.

Again, nu tineam musai sa intru in discutia asta, voiam doar sa punctez ca
asta cu minunile automatizarii nu inseamna doar sa ai ciocan nichelat. Si
in nici un caz nu e atat de simplu ca "citesti 2 howto-uri".

-- 
P.
___
RLUG mailing list
RLUG@lists.lug.ro
http://lists.lug.ro/mailman/listinfo/rlug_lists.lug.ro

Re: [rlug] Plan de migrare Centos 6 -> Centos 7

2020-06-28 Fir de Conversatie Alex 'CAVE' Cernat

Sincer, s-ar putea sa-ti bati cuie multe in cap la inceput pana cand vei
incepe sa intelegi cum functioneaza, dar overall o sa ai numai de
castigat, mai ales cand ai categorii de servere / servicii cu
configuratii comune (sau parametrizate). Insa daca ai fiecare server cu
motul lui, atunci s-ar putea sa te incurce mai mult decat sa te ajute
(sau eventual sa il aplici doar la chestiile comune), insa cand ai macar
3 "de alea", 3 "de alelalte" samd, folosind un "configuration manager"
te ajuta mult si sa eviti pe cat posibil acele "subtle differences" (sau
nu neaparat subtile, ca faci pe 2 din 3 modificari la cine stie ce
config si dupa aia te intrebi de ce merge cu virgule).

Dupa cum vad eu ca merge IT-ul, scripturile de instalare a serverelor nu
prea mai sunt la moda, ci se merge pe definirea "starii" dorite a
sistemului / serviciilor, intr-un format descriptiv (de obicei yaml).
Cum se face la "low level" nu te intereseaza, si da, aici pe alocuri
ansible poate sa devina lent (unii ar zice "ca porcul"), insa ai
garantia ca dupa ce ai rulat task-urile respective (daca le si scrii
bine) pachetele si configuratiile sunt asa cum trebuie sa fie,
serviciile au fost restartate la nevoie samd. Nu zic ca m-am lovit de
buguri idioate (care nici macar nu sunt catalogate ca buguri, ci "asa
functioneaza"), dar trecem peste. Si cat timp nu rulezi efectiv ceva nu
ai nicio amprenta de idle, ca nu exista serviciu sa ruleze pe clienti.

Si nu stiu ce-l deranja pe Petru ca e push, pentru ca pana la urma tu
decizi cand vrei modificarile, nu cand "vrea muschiul serverului" (de
asta am injurat puppet-ul la inceput, pe urma au bagat si partea de
meckanize). Singurul scenariu la care ma gandesc ca ai nevoie de pull e
atunci cand vrei sa automatizezi total instalarea unui server fizic (si
sa incluzi un script de post-install), altfel se reduce la  1) push
creare / instalare / clonare de vm / lxc container 2) rulare config
management, ambele in principiu posibile ca task-uri in ansible. Si
toate astea cu absolut nimic instalat in plus pe "client", decat un
acces ssh si python-ul, care oricum e instalat by default din ce stiu eu
cam pe orice distributie de linux (si pe alocuri vreo 2-3 pachete de
python instalate automat de catre ansible la momentul necesar).

Oricum, ce merge acum, aproape garantat ca peste 5-10 va trebui sa-ti
bagi surubelnita pana la capat, dar macar vei avea un punct de plecare
cu "inventarul". Pana atunci poti avea la nevoie un server nou
functional in maxim minute / zeci de minute (bine, nu vorbim aici de
mega importuri de date, ca atunci se impute treaba). Ca de fapt asta e
toata smecheria cu "configuration managementul": sa ai chestii comune
aplicabile la mai multe servere, altfel ... mai rau te complici si mai
rau pierzi timpul.

Si ca sfat: inainte de rularea pe server fizic poate n-ar fi rau sa
testezi pe o masina virtuala (o data, de doua, de zece ori pana iese
perfect). E mai simplu de refacut, mai ales daca hypervizorul suporta si
ceva snapshot-uri.

Alex

On 28-Jun-20 3:51 PM, Adrian Popa wrote:
> Planul meu era sa ma ajut de ansible pentru taskuri relativ repetitive post
> OS-upgrade. De exemplu, instaleaza cacti versiunea X, sau upgradeaza cacti
> versiunea Y. Am suficient de multe servere vechi in ograda cat sa merite
> investitia de efort. Chiar daca fiecare server e facut de capul lui, e o
> oportunitate buna sa le mai unific configurile.
>
> Ce-i drept, post install nu cred ca orice modificare o sa se faca via
> ansible (obiceiuri vechi), ci tot cu shell, dar ma gandesc ca daca fac
> backup de config/chestii modificate si fac restore la upgrade cu ansible,
> ar putea sa mearga si pe termen mai lung, chiar daca nu e 100% clean/the
> ansible way.
>
> Oricum e mai bine decat sa fac server cu server si sa nu ramana nimic
> documentat post upgrade, ca peste 5-10 ani sa o iau de la capat...
>
> Daca trimit trafic din productie in server si nu merge, asta e - castig
> experienta si vad ce am uitat, se imbunatatesc scripturile, workflow-ul,
> etc. Toata lumea castiga (mai putin end userul).
> :)
>
>
> On Sat, Jun 27, 2020 at 1:55 PM Andrei POPESCU 
> wrote:
>
>> On Vi, 26 iun 20, 14:51:09, Adrian Popa wrote:
>>> P.S. De la Centos 7 la 8 există upgrade path, sau e aceeaşi problemă?
>> Oare
>>> pe Ubuntu de ce se poate şi pe CentOS nu? Sau intrăm în holy flame war?
>>> Mersi!
>> Ubuntu probabil moștenește (mai mult sau mai puțin) actualizarea "in
>> place" de la Debian.
>>
>> În Debian orice pachet *trebuie* să suporte actualizare "in place" de la
>> versiunea "stable" precedentă ("oldstable")[1][2].
>>
>> Excepții se admit doar în cazuri speciale[3], care ar trebui să fie
>> documentate în Notele de lansare (Release Notes) și/sau NEWS.Debian
>> (afișat automat dacă pachetul 'apt-listchanges' este instalat).
>>
>> Versiunile pachetelor din Ubuntu (LTS) posibil/probabil să nu corespundă
>> 1:1 cu cele din Debian "oldstable"/"stable". În caz de diferențe depinde
>> de Ubuntu să testeze și, dacă este cazul,

Re: [rlug] Plan de migrare Centos 6 -> Centos 7

2020-06-28 Fir de Conversatie Adrian Popa

Planul meu era sa ma ajut de ansible pentru taskuri relativ repetitive post
OS-upgrade. De exemplu, instaleaza cacti versiunea X, sau upgradeaza cacti
versiunea Y. Am suficient de multe servere vechi in ograda cat sa merite
investitia de efort. Chiar daca fiecare server e facut de capul lui, e o
oportunitate buna sa le mai unific configurile.

Ce-i drept, post install nu cred ca orice modificare o sa se faca via
ansible (obiceiuri vechi), ci tot cu shell, dar ma gandesc ca daca fac
backup de config/chestii modificate si fac restore la upgrade cu ansible,
ar putea sa mearga si pe termen mai lung, chiar daca nu e 100% clean/the
ansible way.

Oricum e mai bine decat sa fac server cu server si sa nu ramana nimic
documentat post upgrade, ca peste 5-10 ani sa o iau de la capat...

Daca trimit trafic din productie in server si nu merge, asta e - castig
experienta si vad ce am uitat, se imbunatatesc scripturile, workflow-ul,
etc. Toata lumea castiga (mai putin end userul).
:)

On Sat, Jun 27, 2020 at 1:55 PM Andrei POPESCU 
wrote:

> On Vi, 26 iun 20, 14:51:09, Adrian Popa wrote:
> >
> > P.S. De la Centos 7 la 8 există upgrade path, sau e aceeaşi problemă?
> Oare
> > pe Ubuntu de ce se poate şi pe CentOS nu? Sau intrăm în holy flame war?
> > Mersi!
>
> Ubuntu probabil moștenește (mai mult sau mai puțin) actualizarea "in
> place" de la Debian.
>
> În Debian orice pachet *trebuie* să suporte actualizare "in place" de la
> versiunea "stable" precedentă ("oldstable")[1][2].
>
> Excepții se admit doar în cazuri speciale[3], care ar trebui să fie
> documentate în Notele de lansare (Release Notes) și/sau NEWS.Debian
> (afișat automat dacă pachetul 'apt-listchanges' este instalat).
>
> Versiunile pachetelor din Ubuntu (LTS) posibil/probabil să nu corespundă
> 1:1 cu cele din Debian "oldstable"/"stable". În caz de diferențe depinde
> de Ubuntu să testeze și, dacă este cazul, să modifice pachetele ca să
> funcționeze actualizarea "in place".
>
> [1] nu găsesc acum exact unde este scris în Debian Policy
> [2] pentru versiuni mai vechi de "oldstable" nu se oferă garanții și în
> general nu se testează, deși este posibil să funcționeze
> [3] exemplu: aplicația s-a modificat prea mult și nu oferă posibilitatea
> de actualizare automată
>
> Spor,
> Andrei
> --
> If you can't explain it simply, you don't understand it well enough.
> (Albert Einstein)
> ___
> RLUG mailing list
> RLUG@lists.lug.ro
> http://lists.lug.ro/mailman/listinfo/rlug_lists.lug.ro
>
___
RLUG mailing list
RLUG@lists.lug.ro
http://lists.lug.ro/mailman/listinfo/rlug_lists.lug.ro

Re: [rlug] Plan de migrare Centos 6 -> Centos 7

2020-06-27 Fir de Conversatie Andrei POPESCU

On Vi, 26 iun 20, 14:51:09, Adrian Popa wrote:
> 
> P.S. De la Centos 7 la 8 există upgrade path, sau e aceeaşi problemă? Oare
> pe Ubuntu de ce se poate şi pe CentOS nu? Sau intrăm în holy flame war?
> Mersi!

Ubuntu probabil moștenește (mai mult sau mai puțin) actualizarea "in 
place" de la Debian.

În Debian orice pachet *trebuie* să suporte actualizare "in place" de la 
versiunea "stable" precedentă ("oldstable")[1][2].

Excepții se admit doar în cazuri speciale[3], care ar trebui să fie 
documentate în Notele de lansare (Release Notes) și/sau NEWS.Debian 
(afișat automat dacă pachetul 'apt-listchanges' este instalat).

Versiunile pachetelor din Ubuntu (LTS) posibil/probabil să nu corespundă 
1:1 cu cele din Debian "oldstable"/"stable". În caz de diferențe depinde 
de Ubuntu să testeze și, dacă este cazul, să modifice pachetele ca să 
funcționeze actualizarea "in place".

[1] nu găsesc acum exact unde este scris în Debian Policy
[2] pentru versiuni mai vechi de "oldstable" nu se oferă garanții și în 
general nu se testează, deși este posibil să funcționeze
[3] exemplu: aplicația s-a modificat prea mult și nu oferă posibilitatea 
de actualizare automată

Spor,
Andrei
-- 
If you can't explain it simply, you don't understand it well enough.
(Albert Einstein)

signature.asc
Description: PGP signature
___
RLUG mailing list
RLUG@lists.lug.ro
http://lists.lug.ro/mailman/listinfo/rlug_lists.lug.ro

Re: [rlug] Plan de migrare Centos 6 -> Centos 7

2020-06-26 Fir de Conversatie Petru Rațiu

> btw, nu numai pentru servere e ff util ansible ci si pentru desktopurile
> userilor: daca unul dintr-un grup iti zice ca are nevoie ceva, SIGUR
> toti vor avea nevoie .. asa ca aplici reteta la toate desktopurile si
> laptopurile lor :D
> in plus am citit (doar) ca ansible stie si windows si am auzit de
> automatizari interesante legate de diverse proceduri de backup... dar nu
> ma ocup de personalul administrativ deci nu am experienta practica cu
> asta ...
>
>
N-am vrut sa intru foarte mult in aspectul asta, dar ansible e o scula cam
de rahat pentru problema asta. Nu te ajuta sa scrii policy-uri despre cum
sa arate sistemele ci e pe principiul "foloseste un ciocan mai mare",
simuleaza in continuare actiuni pe care le faci ad-hoc. Asta sa nu mai zic
ca e extrem de incet si ca e push in loc de pull. Se pot rezolva sau adapta
lucrurile astea, dar greu si oarecum in raspar fata de ce vrea scula sa
faca. Ca sa nu mai zic ca galaxy e in mare parte plin de opinionated
installs si nu neaparat de metodologii de management (lucru care e scuzabil
daca faci mereu de la zero lucrurile, mai putin daca lucrezi pe bare metal
sau pe sisteme critice). All in all fanboyismul pt. ansible nu mi se pare
foarte diferit de moda cu "stiu bash si nu mi-e frica sa-l folosesc" de
acum 20 de ani care producea shellscripturi monumentale de sute si mii de
randuri (macar alea mergeau repede, nu ca pitoanele si yaml-urile lui peste
prajit)

All in all in opinia mea principalul shift de mentalitate care trebuie
facut in administrarea de servere este ca sistemele persistente (pe care le
instalezi si raman asa ani intregi cu modificari incrementale) incep sa fie
exceptia nu regula si in general sculele se fac pentru sisteme efemere
(vm-uri, instante, containere) pe care mai degraba le refaci pe curat decat
sa le modifici. Nu zic ca asta e ceva bun, doar ca nu mai e surprinzator sa
constati ca nu-s suportate upgrade-uri ci doar instalari pe curat la
diverse componente software (os-uri, baze de date, etc).

-- 
P.
___
RLUG mailing list
RLUG@lists.lug.ro
http://lists.lug.ro/mailman/listinfo/rlug_lists.lug.ro

Re: [rlug] Plan de migrare Centos 6 -> Centos 7


On 6/26/20 11:21 PM, Petru Rațiu wrote:

O chestie pe care n-am vazut-o mentionata este ca intre "am un server
legacy, cum il upgradez" si "foloseste ansible (sau whatever), asa e cool
si hip si modern" mai e un salt mental destul de important. Sculele de
da, corect, esti obligat de a face acest salt, de la "hai ca am intrat 
prin ssh si am manarit si merge" la "pentru obiectivul X am aceasta 
reteta Y (reteta determinista). am nevoie de obiectivul X la masina si 
atunci rulez reteta Y prin ssh (adica ansible)"



management automat se folosesc cand ai (sau vrei sa ai) infrastructura pe
care poti sa o razi sa o faci de la zero fara batai mari de cap, si asta se
face doar repetand pasii astia de destule ori. Daca ai UN server (sau ma
rog, suficient de putine incat sa fie fiecare un fulg de nea aparte care a
fost configurat manual de-a lungul a cativa ani), e relativ complicat sa
treci din mers la mentalitatea de "productie de serie". Asta se face doar
da, foarte adevarat, dar cu atat mai mult trebuie sa iti translatezi 
"configurarea manuala" in actiuni clare documentate ce ajung sa 
defineasca unul sau mai multe taskuri.
daca faci upgrade-ul si repeti configurarea manuala, chiar daca ai noroc 
si repeti toti pasii din history (sau scritpuri/documentatie etc) nu 
inseamna ca devine facil sa o mai faci de cateva ori ...

nu e o trecere din mers, ci o oportunitate de a incepe


construind pe curat mediul langa (pe un sever nou) de suficient de multe
ori sa ai curajul sa-ti muti traficul live acolo. Lucrul asta poate fi
dificil din mult mai multe motive, nu toate de ordin tehnic. Sigur ca
merita facut efortul dar nu e de loc neglijabil, si partea cu "inveti
ansible sau puppet" este cea mai simpla chestie din tot procesul.
da, totul se reduce la aranjamentul logic in detaliu a ceea ce vrei sa 
faci... IMHO asta e intotdeauna o buna investitie



Sursa: cam de vreo 15 ani incoace lucrez sau ma stradui sa lucrez in stilul
asta si inca n-am vazut vreo situatie unde sa fi mers cu succes "din mers"
tranzitia de la "intri pe server si faci chestii as needed" la "intri pe
server doar foarte rar ca sa investighezi ceva". Tot timpul a fost nevoie
sa reinstalez pe curat masinile langa (ocazional de cateva ori pe zi).
mda.. depinde fff mult ce activitati are fiecare .. eu de ex nici nu pot 
sa imi imaginez de ce ai avea nevoie sa reinstalezi o masina (in afara 
de upgrade de OS evident - hdd cazut si instalat from scratch nu intra 
la re-instalare)



Intr-un mediu cloud e ceva mai simplu, pe "serverul din debara" e cel mai
complicat. Cel mai complicat este insa sa te dezveti sa te loghezi pe
masina sa faci lucruri, si asta nu se face cu ocazia upgrade-ului.
eh, daca upgrade-ul e de fapt install from scratch as zice ca e un 
moment bun sa te apuci si scrii si documentezi TOATE configurarile 
manuale ;) :)


btw, nu numai pentru servere e ff util ansible ci si pentru desktopurile 
userilor: daca unul dintr-un grup iti zice ca are nevoie ceva, SIGUR 
toti vor avea nevoie .. asa ca aplici reteta la toate desktopurile si 
laptopurile lor :D
in plus am citit (doar) ca ansible stie si windows si am auzit de 
automatizari interesante legate de diverse proceduri de backup... dar nu 
ma ocup de personalul administrativ deci nu am experienta practica cu 
asta ...


IMHO, nu e nici un moment mai bun decat prezentul sa inveti cum sa faci 
masina sa munceasca in locul tau :


Adrian


___
RLUG mailing list
RLUG@lists.lug.ro
http://lists.lug.ro/mailman/listinfo/rlug_lists.lug.ro

Re: [rlug] Plan de migrare Centos 6 -> Centos 7

2020-06-26 Fir de Conversatie Petru Rațiu

O chestie pe care n-am vazut-o mentionata este ca intre "am un server
legacy, cum il upgradez" si "foloseste ansible (sau whatever), asa e cool
si hip si modern" mai e un salt mental destul de important. Sculele de
management automat se folosesc cand ai (sau vrei sa ai) infrastructura pe
care poti sa o razi sa o faci de la zero fara batai mari de cap, si asta se
face doar repetand pasii astia de destule ori. Daca ai UN server (sau ma
rog, suficient de putine incat sa fie fiecare un fulg de nea aparte care a
fost configurat manual de-a lungul a cativa ani), e relativ complicat sa
treci din mers la mentalitatea de "productie de serie". Asta se face doar
construind pe curat mediul langa (pe un sever nou) de suficient de multe
ori sa ai curajul sa-ti muti traficul live acolo. Lucrul asta poate fi
dificil din mult mai multe motive, nu toate de ordin tehnic. Sigur ca
merita facut efortul dar nu e de loc neglijabil, si partea cu "inveti
ansible sau puppet" este cea mai simpla chestie din tot procesul.

Sursa: cam de vreo 15 ani incoace lucrez sau ma stradui sa lucrez in stilul
asta si inca n-am vazut vreo situatie unde sa fi mers cu succes "din mers"
tranzitia de la "intri pe server si faci chestii as needed" la "intri pe
server doar foarte rar ca sa investighezi ceva". Tot timpul a fost nevoie
sa reinstalez pe curat masinile langa (ocazional de cateva ori pe zi).
Intr-un mediu cloud e ceva mai simplu, pe "serverul din debara" e cel mai
complicat. Cel mai complicat este insa sa te dezveti sa te loghezi pe
masina sa faci lucruri, si asta nu se face cu ocazia upgrade-ului.

-- 
P.

On Fri, Jun 26, 2020 at 10:57 PM Adrian Sevcenco 
wrote:

> On 6/26/20 7:48 PM, Adrian Popa wrote:
> > Ok, mulţumesc amândurora pentru sfaturi/idei.
> >
> > Încă o întrebare legată de ansible. Să zicem că îmi definesc propriile
> > playbook-uri în care îmi fac deploy la aplicaţie. Cum e mai bine - fac
> > deploy de mână pe un server de test şi testez că merge acolo după care mă
> > uit prin history şi scriu playbook-ul, sau încep să scriu playbook-ul şi
> îl
> > tot rulez/modific până merge aplicaţia? Care e mai productiv mod de
> lucru?
> pai vezi ca exista
> -C, --check   don't make any changes; instead, try to predict some
>  of the changes that may occur
>-D, --diffwhen changing (small) files and templates, show
> the
>  differences in those files; works great with
> --check
>
> ;)
>
> dar in principiu nu ar trebui sa fii surprins de nimic ca iti scrii
> taskurile de mana .. mai intii iti scrii "piesele de lego" (taskurile)
> si apoi le combini .. un task poate sa includa si alte taskuri
> astfel un playbook e doar o constructie de lego
>
> sfatul meu e mai intii sa citetesti si sa lecturezi usor searchuri de
> "ansible howto" pe google :) pana sa pui mana sa faci diverse
>
> estimez un max 12 ore de documentatie pentru a incepe sa scrii taskuri
> si apoi pe masura ce iti traduci "vreau ca masina sa aiba aceasta stare"
> in taskuri individuale ce apoi le compui, o sa fii din ce in ce mai
> comfortabil cu ansible :)
>
> Succes!
> Adrian
>
> P.S. vezi ca multe/majoritatea modulelor din pagina cu module are si
> exemple de folosire
>
>
> >
> > On Fri, Jun 26, 2020 at 3:56 PM Adrian Sevcenco  >
> > wrote:
> >
> >> On 6/26/20 2:51 PM, Adrian Popa wrote:
> >>> Salut,
> >> Salut!
> >>
> >>> Hmm, ansible sună interesant pentru problema asta... Mersi de sfat.
> Măcar
> >>> aşa ar rămâne documentat ce e pe fiecare server...
> >>>
> >>> Nu am eu foarte mare experienţă cu ansible, dar presupun că o să încep
> să
> >>> caut playbook-uri pentru diverse taskuri şi o să le customizez după
> >>> nevoi... Recomanzi să încep de la https://galaxy.ansible.com/, sau
> >> există o
> >>> resursă mai bună?
> >> well.. e dupa gust :) pe galanxy gasesti roluri complete unde doar
> >> setezi niste parametrii si gata ... dar daca vrei sa stii ce se
> >> intimpla, ca inceptator iti prinzi urechile ...
> >>
> >> eu pas cu pas mi-am definit taskurile mele si apoi mi-am definit
> >> playbook-urile incluzand aceste taskuri .. nu e elegant si felxibil ca
> >> un role dar stiu exact ce am pus si unde ... dupa ceva vreme probabil
> >> ajung natural la roluri
> >>
> >> iti recomand sa ai pagina asta la indemana :D
> >>
> https://docs.ansible.com/ansible/latest/modules/modules_by_category.html
> >>
> >> in principiu un playbook are host-ul definit obligatoriu dar eu mi-am
> >> facut un scriptulet care lanseaza playbookul cu hostul din argument
> >> https://github.com/adriansev/bin-scripts/blob/master/ansplay2host
> >>
> >>
> >>> P.S. De la Centos 7 la 8 există upgrade path, sau e aceeaşi problemă?
> >> Oare
> >> nici la asta .. din cate am "auzit" de abia de la 8->9 va fi
> >> infrastructura pregatita pentru asta
> >>
> >>> pe Ubuntu de ce se poate şi pe CentOS nu? Sau intrăm în holy flame war?
> >> pai .. nu e acelasi lucru ... daca vrei poti sa zici : de ce pe debian
> >> se poate si pe centos nu :

Re: [rlug] Plan de migrare Centos 6 -> Centos 7

2020-06-26 Fir de Conversatie manuel "lonely wolf" wolfshant


On 6/26/20 7:48 PM, Adrian Popa wrote:

Ok, mulţumesc amândurora pentru sfaturi/idei.

Încă o întrebare legată de ansible. Să zicem că îmi definesc propriile
playbook-uri în care îmi fac deploy la aplicaţie. Cum e mai bine - fac
deploy de mână pe un server de test şi testez că merge acolo după care mă
uit prin history şi scriu playbook-ul, sau încep să scriu playbook-ul şi îl
tot rulez/modific până merge aplicaţia? Care e mai productiv mod de lucru?

pai vezi ca exista
-C, --check   don't make any changes; instead, try to predict some
of the changes that may occur
  -D, --diffwhen changing (small) files and templates, show the
differences in those files; works great with 
--check


;)

dar in principiu nu ar trebui sa fii surprins de nimic ca iti scrii 
taskurile de mana .. mai intii iti scrii "piesele de lego" (taskurile)

si apoi le combini .. un task poate sa includa si alte taskuri
astfel un playbook e doar o constructie de lego

sfatul meu e mai intii sa citetesti si sa lecturezi usor searchuri de 
"ansible howto" pe google :) pana sa pui mana sa faci diverse


estimez un max 12 ore de documentatie pentru a incepe sa scrii taskuri
si apoi pe masura ce iti traduci "vreau ca masina sa aiba aceasta stare" 
in taskuri individuale ce apoi le compui, o sa fii din ce in ce mai 
comfortabil cu ansible :)


Succes!
Adrian

P.S. vezi ca multe/majoritatea modulelor din pagina cu module are si 
exemple de folosire





On Fri, Jun 26, 2020 at 3:56 PM Adrian Sevcenco 
wrote:


On 6/26/20 2:51 PM, Adrian Popa wrote:

Salut,

Salut!


Hmm, ansible sună interesant pentru problema asta... Mersi de sfat. Măcar
aşa ar rămâne documentat ce e pe fiecare server...

Nu am eu foarte mare experienţă cu ansible, dar presupun că o să încep să
caut playbook-uri pentru diverse taskuri şi o să le customizez după
nevoi... Recomanzi să încep de la https://galaxy.ansible.com/, sau

există o

resursă mai bună?

well.. e dupa gust :) pe galanxy gasesti roluri complete unde doar
setezi niste parametrii si gata ... dar daca vrei sa stii ce se
intimpla, ca inceptator iti prinzi urechile ...

eu pas cu pas mi-am definit taskurile mele si apoi mi-am definit
playbook-urile incluzand aceste taskuri .. nu e elegant si felxibil ca
un role dar stiu exact ce am pus si unde ... dupa ceva vreme probabil
ajung natural la roluri

iti recomand sa ai pagina asta la indemana :D
https://docs.ansible.com/ansible/latest/modules/modules_by_category.html

in principiu un playbook are host-ul definit obligatoriu dar eu mi-am
facut un scriptulet care lanseaza playbookul cu hostul din argument
https://github.com/adriansev/bin-scripts/blob/master/ansplay2host



P.S. De la Centos 7 la 8 există upgrade path, sau e aceeaşi problemă?

Oare
nici la asta .. din cate am "auzit" de abia de la 8->9 va fi
infrastructura pregatita pentru asta


pe Ubuntu de ce se poate şi pe CentOS nu? Sau intrăm în holy flame war?

pai .. nu e acelasi lucru ... daca vrei poti sa zici : de ce pe debian
se poate si pe centos nu :))

IMHO raspunsul scurt e ca rpm-ul a suferit schimbari/inbunatatiri
radicale (backward incompatible) pe cand apt-ul (sau cum s-o numi
infrastructura de packaging) nu ...

dar fedora are distro upgrade de pe vremea lui 16 parca ... nu sunt
sigur de loc pe memoria mea dar oricum de multa vreme (si ca sa incerc
si eu un flame war : de dinainte sa renunte debian la sysinit :))) )

Adrian



Mersi!

On Fri, Jun 26, 2020 at 12:31 PM Adrian Sevcenco <

adrian.sevce...@cern.ch>

wrote:


On 6/26/20 11:55 AM, Adrian Popa wrote:

Salut,

Salut!


Am mai multe servere cu Centos6 în subordine (unele fizice, altele
virtuale). Văd că nu există o procedură suportată de upgrade la Centos7

(o

să încerc distrorejuve pe un vm să vedem ce iese). Aş vrea să întreb -

care

a fost abordarea voastră în situaţii similare? Tentativă de upgrade,

sau

install pe curat? În caz de install pe curat, în afară de backup /etc,
/home, date aplicaţii, listă pachete + install pe target + test aţi mai
făcut şi alţi paşi? Există o procedură de reinstall cu portare
setări/aplicaţii documentată pe undeva?

eu nu stiu sa existe posibilitatea trecerii de la 6 la 7 mai ales ca din
cate imi amintesc s-au schimbat chestii la rpmdb ...
sfatul meu ar fi sa faci clean install
/home-ul poate linistit sa ramana la fel (mai ales daca e inexistent in
cazul serverelor)

la servicii trebuie sa evaluezi daca formatul lor e portabil .. eu
pentru mysql->mariadb si postgres am facut dump complet (mai ales ca la
postgres folosesc upstream repo)

de asemeni mi-a folosit investitia de timp pentru familiarizarea cu
ansible : am scris retete (aproape) distro-agnostice pentru serviciile
ce necesitau configuratii adaptate, iar pentru celelalte retete doar de
pus la loc fisierele cu configuratii

firewall-ul poate fi configurat tot independent de distro

dupa toata aceasta pregatire, cu un kickstart pregatit, instalarea de
centos 7 si apoi rulatul retetelor

Re: [rlug] Plan de migrare Centos 6 -> Centos 7

2020-06-26 Fir de Conversatie George Pochiscan

Salut,

Iti recomand mai intai sa faci manual un server, sa notezi toate pachetele, 
modificarile, etc, si abia apoi sa construiesti playbook-ul.
Bineinteles, cat timp faci playbookul il vei rula de multiple ori pe servere de 
test pana iti iese.

PS: ca sa fii sigur de success, fa un snapshot inainte de a rula playbook-ul. 
Daca nu merge, revii la snapshot, modifici reteta, mai bagi o fisa. Si tot asa 
pana ruleaza corect __

George Pochiscan 

On 26/06/2020, 19:51, "Adrian Popa"  wrote:

Ok, mulţumesc amândurora pentru sfaturi/idei.

Încă o întrebare legată de ansible. Să zicem că îmi definesc propriile
playbook-uri în care îmi fac deploy la aplicaţie. Cum e mai bine - fac
deploy de mână pe un server de test şi testez că merge acolo după care mă
uit prin history şi scriu playbook-ul, sau încep să scriu playbook-ul şi îl
tot rulez/modific până merge aplicaţia? Care e mai productiv mod de lucru?

On Fri, Jun 26, 2020 at 3:56 PM Adrian Sevcenco 
wrote:

> On 6/26/20 2:51 PM, Adrian Popa wrote:
> > Salut,
> Salut!
>
> > Hmm, ansible sună interesant pentru problema asta... Mersi de sfat. 
Măcar
> > aşa ar rămâne documentat ce e pe fiecare server...
> >
> > Nu am eu foarte mare experienţă cu ansible, dar presupun că o să încep 
să
> > caut playbook-uri pentru diverse taskuri şi o să le customizez după
> > nevoi... Recomanzi să încep de la https://galaxy.ansible.com/, sau
> există o
> > resursă mai bună?
> well.. e dupa gust :) pe galanxy gasesti roluri complete unde doar
> setezi niste parametrii si gata ... dar daca vrei sa stii ce se
> intimpla, ca inceptator iti prinzi urechile ...
>
> eu pas cu pas mi-am definit taskurile mele si apoi mi-am definit
> playbook-urile incluzand aceste taskuri .. nu e elegant si felxibil ca
> un role dar stiu exact ce am pus si unde ... dupa ceva vreme probabil
> ajung natural la roluri
>
> iti recomand sa ai pagina asta la indemana :D
> https://docs.ansible.com/ansible/latest/modules/modules_by_category.html
>
> in principiu un playbook are host-ul definit obligatoriu dar eu mi-am
> facut un scriptulet care lanseaza playbookul cu hostul din argument
> https://github.com/adriansev/bin-scripts/blob/master/ansplay2host
>
>
> > P.S. De la Centos 7 la 8 există upgrade path, sau e aceeaşi problemă?
> Oare
> nici la asta .. din cate am "auzit" de abia de la 8->9 va fi
> infrastructura pregatita pentru asta
>
> > pe Ubuntu de ce se poate şi pe CentOS nu? Sau intrăm în holy flame war?
> pai .. nu e acelasi lucru ... daca vrei poti sa zici : de ce pe debian
> se poate si pe centos nu :))
>
> IMHO raspunsul scurt e ca rpm-ul a suferit schimbari/inbunatatiri
> radicale (backward incompatible) pe cand apt-ul (sau cum s-o numi
> infrastructura de packaging) nu ...
>
> dar fedora are distro upgrade de pe vremea lui 16 parca ... nu sunt
> sigur de loc pe memoria mea dar oricum de multa vreme (si ca sa incerc
> si eu un flame war : de dinainte sa renunte debian la sysinit :))) )
>
> Adrian
>
>
> > Mersi!
> >
> > On Fri, Jun 26, 2020 at 12:31 PM Adrian Sevcenco <
> adrian.sevce...@cern.ch>
> > wrote:
> >
> >> On 6/26/20 11:55 AM, Adrian Popa wrote:
> >>> Salut,
> >> Salut!
> >>
> >>> Am mai multe servere cu Centos6 în subordine (unele fizice, altele
> >>> virtuale). Văd că nu există o procedură suportată de upgrade la 
Centos7
> >> (o
> >>> să încerc distrorejuve pe un vm să vedem ce iese). Aş vrea să întreb -
> >> care
> >>> a fost abordarea voastră în situaţii similare? Tentativă de upgrade,
> sau
> >>> install pe curat? În caz de install pe curat, în afară de backup /etc,
> >>> /home, date aplicaţii, listă pachete + install pe target + test aţi 
mai
> >>> făcut şi alţi paşi? Există o procedură de reinstall cu portare
> >>> setări/aplicaţii documentată pe undeva?
> >> eu nu stiu sa existe posibilitatea trecerii de la 6 la 7 mai ales ca 
din
> >> cate imi amintesc s-au schimbat chestii la rpmdb ...
> >> sfatul meu ar fi sa faci clean install
> >> /home-ul poate linistit sa ramana la fel (mai ales daca e inexistent in
> >> cazul serverelor)
> >>
> >> la servicii trebuie sa evaluezi daca formatul lor e portabil .. eu
> >> pentru mysql->mariadb si postgres am facut dump complet (mai ales ca la
> >> postgres folosesc upstream repo)
> >>
> >> de asemeni mi-a folosit investitia de timp pentru familiarizarea cu
> >> ansible : am scris retete (aproape) distro-agnostice pentru serviciile
> >> ce necesitau configuratii adaptate, iar pentru celelalte retete doar de
> >> pus la loc fisierele cu configuratii
> >>
> >> firewall-ul poate fi configurat tot independent de distro
> >>
> >> dupa toata aceasta pregatire, cu un kicksta

Re: [rlug] Plan de migrare Centos 6 -> Centos 7

2020-06-26 Fir de Conversatie Adrian Popa

Ok, mulţumesc amândurora pentru sfaturi/idei.

Încă o întrebare legată de ansible. Să zicem că îmi definesc propriile
playbook-uri în care îmi fac deploy la aplicaţie. Cum e mai bine - fac
deploy de mână pe un server de test şi testez că merge acolo după care mă
uit prin history şi scriu playbook-ul, sau încep să scriu playbook-ul şi îl
tot rulez/modific până merge aplicaţia? Care e mai productiv mod de lucru?

On Fri, Jun 26, 2020 at 3:56 PM Adrian Sevcenco 
wrote:

> On 6/26/20 2:51 PM, Adrian Popa wrote:
> > Salut,
> Salut!
>
> > Hmm, ansible sună interesant pentru problema asta... Mersi de sfat. Măcar
> > aşa ar rămâne documentat ce e pe fiecare server...
> >
> > Nu am eu foarte mare experienţă cu ansible, dar presupun că o să încep să
> > caut playbook-uri pentru diverse taskuri şi o să le customizez după
> > nevoi... Recomanzi să încep de la https://galaxy.ansible.com/, sau
> există o
> > resursă mai bună?
> well.. e dupa gust :) pe galanxy gasesti roluri complete unde doar
> setezi niste parametrii si gata ... dar daca vrei sa stii ce se
> intimpla, ca inceptator iti prinzi urechile ...
>
> eu pas cu pas mi-am definit taskurile mele si apoi mi-am definit
> playbook-urile incluzand aceste taskuri .. nu e elegant si felxibil ca
> un role dar stiu exact ce am pus si unde ... dupa ceva vreme probabil
> ajung natural la roluri
>
> iti recomand sa ai pagina asta la indemana :D
> https://docs.ansible.com/ansible/latest/modules/modules_by_category.html
>
> in principiu un playbook are host-ul definit obligatoriu dar eu mi-am
> facut un scriptulet care lanseaza playbookul cu hostul din argument
> https://github.com/adriansev/bin-scripts/blob/master/ansplay2host
>
>
> > P.S. De la Centos 7 la 8 există upgrade path, sau e aceeaşi problemă?
> Oare
> nici la asta .. din cate am "auzit" de abia de la 8->9 va fi
> infrastructura pregatita pentru asta
>
> > pe Ubuntu de ce se poate şi pe CentOS nu? Sau intrăm în holy flame war?
> pai .. nu e acelasi lucru ... daca vrei poti sa zici : de ce pe debian
> se poate si pe centos nu :))
>
> IMHO raspunsul scurt e ca rpm-ul a suferit schimbari/inbunatatiri
> radicale (backward incompatible) pe cand apt-ul (sau cum s-o numi
> infrastructura de packaging) nu ...
>
> dar fedora are distro upgrade de pe vremea lui 16 parca ... nu sunt
> sigur de loc pe memoria mea dar oricum de multa vreme (si ca sa incerc
> si eu un flame war : de dinainte sa renunte debian la sysinit :))) )
>
> Adrian
>
>
> > Mersi!
> >
> > On Fri, Jun 26, 2020 at 12:31 PM Adrian Sevcenco <
> adrian.sevce...@cern.ch>
> > wrote:
> >
> >> On 6/26/20 11:55 AM, Adrian Popa wrote:
> >>> Salut,
> >> Salut!
> >>
> >>> Am mai multe servere cu Centos6 în subordine (unele fizice, altele
> >>> virtuale). Văd că nu există o procedură suportată de upgrade la Centos7
> >> (o
> >>> să încerc distrorejuve pe un vm să vedem ce iese). Aş vrea să întreb -
> >> care
> >>> a fost abordarea voastră în situaţii similare? Tentativă de upgrade,
> sau
> >>> install pe curat? În caz de install pe curat, în afară de backup /etc,
> >>> /home, date aplicaţii, listă pachete + install pe target + test aţi mai
> >>> făcut şi alţi paşi? Există o procedură de reinstall cu portare
> >>> setări/aplicaţii documentată pe undeva?
> >> eu nu stiu sa existe posibilitatea trecerii de la 6 la 7 mai ales ca din
> >> cate imi amintesc s-au schimbat chestii la rpmdb ...
> >> sfatul meu ar fi sa faci clean install
> >> /home-ul poate linistit sa ramana la fel (mai ales daca e inexistent in
> >> cazul serverelor)
> >>
> >> la servicii trebuie sa evaluezi daca formatul lor e portabil .. eu
> >> pentru mysql->mariadb si postgres am facut dump complet (mai ales ca la
> >> postgres folosesc upstream repo)
> >>
> >> de asemeni mi-a folosit investitia de timp pentru familiarizarea cu
> >> ansible : am scris retete (aproape) distro-agnostice pentru serviciile
> >> ce necesitau configuratii adaptate, iar pentru celelalte retete doar de
> >> pus la loc fisierele cu configuratii
> >>
> >> firewall-ul poate fi configurat tot independent de distro
> >>
> >> dupa toata aceasta pregatire, cu un kickstart pregatit, instalarea de
> >> centos 7 si apoi rulatul retetelor a durat 30 min.. dureaza mai mult
> >> coafatul, daca te trezesti ca ai mult prea multe pachete in plus (asta
> >> cand o faci prima oara e o procedura iterativa, pana iti dai seama ce ai
> >> nevoie, ce scoti etc dureaza cateva iteratii)
> >> Dupa rodajul cu 1-2 servere, poti sa ajungi la 10-15 min de re-intors in
> >> productie (bine, depinde si de volumul de install, viteza la local sau
> >> remote repository etc)
> >>
> >> HTH,
> >> Adrian
> >>
> >> ___
> >> RLUG mailing list
> >> RLUG@lists.lug.ro
> >> http://lists.lug.ro/mailman/listinfo/rlug_lists.lug.ro
> >>
> > ___
> > RLUG mailing list
> > RLUG@lists.lug.ro
> > http://lists.lug.ro/mailman/listinfo/rlug_lists.lug.ro
> >
>
>
> --
> ---

Re: [rlug] Plan de migrare Centos 6 -> Centos 7

On June 26, 2020 2:51:09 PM GMT+03:00, Adrian Popa
wrote:

Salut,
Hmm, ansible sună interesant pentru problema asta... Mersi de sfat.
Măcar
aşa ar rămâne documentat ce e pe fiecare server...

Nu am eu foarte mare experienţă cu ansible, dar presupun că o să încep
să
caut playbook-uri pentru diverse taskuri şi o să le customizez după
nevoi... Recomanzi să încep de la https://galaxy.ansible.com/, sau
există o
resursă mai bună?

P.S. De la Centos 7 la 8 există upgrade path, sau e aceeaşi problemă?
Oare
pe Ubuntu de ce se poate şi pe CentOS nu? Sau intrăm în holy flame war?
Mersi!

1. Diferenta intre versiunle pachetelor incluse in fiecare major release
de RHEL (si prin consecinta, CentOS) este mare. Mult mai mare decit
intre 2 versiuni succesive ale oricaror distro deb-based. Iar la mine
apt upgrade de la ubuntu 16.04 la 18.04 a dat niste chixuri monstruoase
( am niste SBCuri cu arm pe care am ubuntu ), a trebuit sa revin la backup.
2. Pt RHEL exista un tool oficial de migrare a _serverelor_ ( DACA
satisfac niste conditii... ) de la 6 la 7. Din motive pe care nu prea am
voie sa le mentionez, scula respectiva nu mai merge pe CentOS de citiva
ani. Raspunsul oficial este "fiindca nu o intretine si nu a actualizat-o
nimeni".
3. Pentru trecerea de la 7 la 8 exista
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html-single/upgrading_from_rhel_7_to_rhel_8/index
care teoretic merge si pe CentOS.
4. Politica oficiala pe care o recomandam cei ce dam asistenta pe
#centos & friends este backup, install fresh, restore. Oricum la
postgres de pilda nu se poate face upgrade direct fiindca postgres. Si
nici la MySQL/MariaDB nu e prea facil sa faci upgrade fara dump/restore
fiindca se mai schimba una alta, gen criptare sau drepturi. Neoficial
insa, se poate face. De la 5 la 6 a fost jale mare, de la 6 la 7, in
special daca nu ai X, e fezabil dar e posibil sa dureze mai mult luatul
la pila decit instalatul fresh.

On Fri, Jun 26, 2020 at 12:31 PM Adrian Sevcenco

wrote:

On 6/26/20 11:55 AM, Adrian Popa wrote:
> Salut,
Salut!

> Am mai multe servere cu Centos6 în subordine (unele fizice, altele
> virtuale). Văd că nu există o procedură suportată de upgrade la

Centos7

(o
> să încerc distrorejuve pe un vm să vedem ce iese). Aş vrea să

întreb -

care
> a fost abordarea voastră în situaţii similare? Tentativă de

upgrade, sau

> install pe curat? În caz de install pe curat, în afară de backup

/etc,

> /home, date aplicaţii, listă pachete + install pe target + test aţi

mai

> făcut şi alţi paşi? Există o procedură de reinstall cu portare
> setări/aplicaţii documentată pe undeva?
eu nu stiu sa existe posibilitatea trecerii de la 6 la 7 mai ales ca

din

cate imi amintesc s-au schimbat chestii la rpmdb ...
sfatul meu ar fi sa faci clean install
/home-ul poate linistit sa ramana la fel (mai ales daca e inexistent

cazul serverelor)

la servicii trebuie sa evaluezi daca formatul lor e portabil .. eu
pentru mysql->mariadb si postgres am facut dump complet (mai ales ca

postgres folosesc upstream repo)

de asemeni mi-a folosit investitia de timp pentru familiarizarea cu
ansible : am scris retete (aproape) distro-agnostice pentru

serviciile

ce necesitau configuratii adaptate, iar pentru celelalte retete doar

pus la loc fisierele cu configuratii

firewall-ul poate fi configurat tot independent de distro

dupa toata aceasta pregatire, cu un kickstart pregatit, instalarea de
centos 7 si apoi rulatul retetelor a durat 30 min.. dureaza mai mult
coafatul, daca te trezesti ca ai mult prea multe pachete in plus

(asta

cand o faci prima oara e o procedura iterativa, pana iti dai seama ce

nevoie, ce scoti etc dureaza cateva iteratii)
Dupa rodajul cu 1-2 servere, poti sa ajungi la 10-15 min de re-intors

productie (bine, depinde si de volumul de install, viteza la local

remote repository etc)

HTH,
Adrian

___
RLUG mailing list
RLUG@lists.lug.ro
http://lists.lug.ro/mailman/listinfo/rlug_lists.lug.ro

Re: [rlug] Plan de migrare Centos 6 -> Centos 7


On 6/26/20 2:51 PM, Adrian Popa wrote:

Salut,

Salut!


Hmm, ansible sună interesant pentru problema asta... Mersi de sfat. Măcar
aşa ar rămâne documentat ce e pe fiecare server...

Nu am eu foarte mare experienţă cu ansible, dar presupun că o să încep să
caut playbook-uri pentru diverse taskuri şi o să le customizez după
nevoi... Recomanzi să încep de la https://galaxy.ansible.com/, sau există o
resursă mai bună?
well.. e dupa gust :) pe galanxy gasesti roluri complete unde doar 
setezi niste parametrii si gata ... dar daca vrei sa stii ce se 
intimpla, ca inceptator iti prinzi urechile ...


eu pas cu pas mi-am definit taskurile mele si apoi mi-am definit 
playbook-urile incluzand aceste taskuri .. nu e elegant si felxibil ca 
un role dar stiu exact ce am pus si unde ... dupa ceva vreme probabil 
ajung natural la roluri


iti recomand sa ai pagina asta la indemana :D
https://docs.ansible.com/ansible/latest/modules/modules_by_category.html

in principiu un playbook are host-ul definit obligatoriu dar eu mi-am 
facut un scriptulet care lanseaza playbookul cu hostul din argument

https://github.com/adriansev/bin-scripts/blob/master/ansplay2host



P.S. De la Centos 7 la 8 există upgrade path, sau e aceeaşi problemă? Oare
nici la asta .. din cate am "auzit" de abia de la 8->9 va fi 
infrastructura pregatita pentru asta



pe Ubuntu de ce se poate şi pe CentOS nu? Sau intrăm în holy flame war?
pai .. nu e acelasi lucru ... daca vrei poti sa zici : de ce pe debian 
se poate si pe centos nu :))


IMHO raspunsul scurt e ca rpm-ul a suferit schimbari/inbunatatiri 
radicale (backward incompatible) pe cand apt-ul (sau cum s-o numi 
infrastructura de packaging) nu ...


dar fedora are distro upgrade de pe vremea lui 16 parca ... nu sunt 
sigur de loc pe memoria mea dar oricum de multa vreme (si ca sa incerc 
si eu un flame war : de dinainte sa renunte debian la sysinit :))) )


Adrian



Mersi!

On Fri, Jun 26, 2020 at 12:31 PM Adrian Sevcenco 
wrote:


On 6/26/20 11:55 AM, Adrian Popa wrote:

Salut,

Salut!


Am mai multe servere cu Centos6 în subordine (unele fizice, altele
virtuale). Văd că nu există o procedură suportată de upgrade la Centos7

(o

să încerc distrorejuve pe un vm să vedem ce iese). Aş vrea să întreb -

care

a fost abordarea voastră în situaţii similare? Tentativă de upgrade, sau
install pe curat? În caz de install pe curat, în afară de backup /etc,
/home, date aplicaţii, listă pachete + install pe target + test aţi mai
făcut şi alţi paşi? Există o procedură de reinstall cu portare
setări/aplicaţii documentată pe undeva?

eu nu stiu sa existe posibilitatea trecerii de la 6 la 7 mai ales ca din
cate imi amintesc s-au schimbat chestii la rpmdb ...
sfatul meu ar fi sa faci clean install
/home-ul poate linistit sa ramana la fel (mai ales daca e inexistent in
cazul serverelor)

la servicii trebuie sa evaluezi daca formatul lor e portabil .. eu
pentru mysql->mariadb si postgres am facut dump complet (mai ales ca la
postgres folosesc upstream repo)

de asemeni mi-a folosit investitia de timp pentru familiarizarea cu
ansible : am scris retete (aproape) distro-agnostice pentru serviciile
ce necesitau configuratii adaptate, iar pentru celelalte retete doar de
pus la loc fisierele cu configuratii

firewall-ul poate fi configurat tot independent de distro

dupa toata aceasta pregatire, cu un kickstart pregatit, instalarea de
centos 7 si apoi rulatul retetelor a durat 30 min.. dureaza mai mult
coafatul, daca te trezesti ca ai mult prea multe pachete in plus (asta
cand o faci prima oara e o procedura iterativa, pana iti dai seama ce ai
nevoie, ce scoti etc dureaza cateva iteratii)
Dupa rodajul cu 1-2 servere, poti sa ajungi la 10-15 min de re-intors in
productie (bine, depinde si de volumul de install, viteza la local sau
remote repository etc)

HTH,
Adrian

___
RLUG mailing list
RLUG@lists.lug.ro
http://lists.lug.ro/mailman/listinfo/rlug_lists.lug.ro


___
RLUG mailing list
RLUG@lists.lug.ro
http://lists.lug.ro/mailman/listinfo/rlug_lists.lug.ro




--
--
Adrian Sevcenco, Ph.D.   |
Institute of Space Science - ISS, Romania|
adrian.sevcenco at {cern.ch,spacescience.ro} |
--

___
RLUG mailing list
RLUG@lists.lug.ro
http://lists.lug.ro/mailman/listinfo/rlug_lists.lug.ro

Re: [rlug] Plan de migrare Centos 6 -> Centos 7

2020-06-26 Fir de Conversatie Adrian Popa

Salut,
Hmm, ansible sună interesant pentru problema asta... Mersi de sfat. Măcar
aşa ar rămâne documentat ce e pe fiecare server...

Nu am eu foarte mare experienţă cu ansible, dar presupun că o să încep să
caut playbook-uri pentru diverse taskuri şi o să le customizez după
nevoi... Recomanzi să încep de la https://galaxy.ansible.com/, sau există o
resursă mai bună?

P.S. De la Centos 7 la 8 există upgrade path, sau e aceeaşi problemă? Oare
pe Ubuntu de ce se poate şi pe CentOS nu? Sau intrăm în holy flame war?
Mersi!

On Fri, Jun 26, 2020 at 12:31 PM Adrian Sevcenco 
wrote:

> On 6/26/20 11:55 AM, Adrian Popa wrote:
> > Salut,
> Salut!
>
> > Am mai multe servere cu Centos6 în subordine (unele fizice, altele
> > virtuale). Văd că nu există o procedură suportată de upgrade la Centos7
> (o
> > să încerc distrorejuve pe un vm să vedem ce iese). Aş vrea să întreb -
> care
> > a fost abordarea voastră în situaţii similare? Tentativă de upgrade, sau
> > install pe curat? În caz de install pe curat, în afară de backup /etc,
> > /home, date aplicaţii, listă pachete + install pe target + test aţi mai
> > făcut şi alţi paşi? Există o procedură de reinstall cu portare
> > setări/aplicaţii documentată pe undeva?
> eu nu stiu sa existe posibilitatea trecerii de la 6 la 7 mai ales ca din
> cate imi amintesc s-au schimbat chestii la rpmdb ...
> sfatul meu ar fi sa faci clean install
> /home-ul poate linistit sa ramana la fel (mai ales daca e inexistent in
> cazul serverelor)
>
> la servicii trebuie sa evaluezi daca formatul lor e portabil .. eu
> pentru mysql->mariadb si postgres am facut dump complet (mai ales ca la
> postgres folosesc upstream repo)
>
> de asemeni mi-a folosit investitia de timp pentru familiarizarea cu
> ansible : am scris retete (aproape) distro-agnostice pentru serviciile
> ce necesitau configuratii adaptate, iar pentru celelalte retete doar de
> pus la loc fisierele cu configuratii
>
> firewall-ul poate fi configurat tot independent de distro
>
> dupa toata aceasta pregatire, cu un kickstart pregatit, instalarea de
> centos 7 si apoi rulatul retetelor a durat 30 min.. dureaza mai mult
> coafatul, daca te trezesti ca ai mult prea multe pachete in plus (asta
> cand o faci prima oara e o procedura iterativa, pana iti dai seama ce ai
> nevoie, ce scoti etc dureaza cateva iteratii)
> Dupa rodajul cu 1-2 servere, poti sa ajungi la 10-15 min de re-intors in
> productie (bine, depinde si de volumul de install, viteza la local sau
> remote repository etc)
>
> HTH,
> Adrian
>
> ___
> RLUG mailing list
> RLUG@lists.lug.ro
> http://lists.lug.ro/mailman/listinfo/rlug_lists.lug.ro
>
___
RLUG mailing list
RLUG@lists.lug.ro
http://lists.lug.ro/mailman/listinfo/rlug_lists.lug.ro

Re: [rlug] Plan de migrare Centos 6 -> Centos 7