subject:"Re\: \[rlug\] flame de vineri \( ubuntu\)"



Și da, văd că acum se poate, la jessie nu se putea pentru că erau 
dependențe explicite de systemd la toate serviciile. Văd că au revenit 
în mod tacit.


Ai tăiat mesajul la care ți-am răspuns, dar l-am recuperat, că nu-mi 
place să fiu acuzat aiurea.  Asta e ce ne-ai scris: „Eu am preferat să 
îmi derivez niște imagini din whezzy și voiam să le "upgradez" la 
jessie dar a fost un interval în care nu exista docker bazat pe 
jessie.”


Chiar și în mesajul la care răspund acum faci inițial confuzia între 
imagini și fișierul Dockerfile.  Cât ne mai potopești cu asemenea 
bălmăjeli?  Și care-i scopul?


Iar din apelativul colorat ce să mai înțeleg?  Când cineva pare că 
greșește, merită să fie apelat ca o persoană de sex feminin?  Deci 
misoginism, nene?  Hai să ne oprim totuși, că deja cădem în ridicol…


Îmi cer scuze pentru apelativ, nu m-am gândit că ar fi ofensiv, voiam să 
sugerez că nu ne auzim între noi "ca niște babe surde".
Deci și din propoziția de mai sus rezultă că voiam să upgradez 
imaginile, nu containerele. Cum? N-am specificat. Btw, asta chiar nu 
știu, poți să te conectezi la imagine ca la un container ca să rulezi 
dist-upgrade?
Am explicat mai pe larg în răspunsul la Petre ce am vrut să fac și de 
ce, nu de alta dar dacă tot discutăm să discutăm despre ce s-a întâmplat 
concret și nu despre ce ar fi putut să se întâmple.


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

Re: [rlug] flame de vineri ( ubuntu)

On Tue, Mar 26, 2024 at 12:19 PM Mihai Badici  wrote:

>
> >>
> >> Cred ca capcana in care se cade usor aici e impacarea a "vreau ca
> >> mediul
> > de dev sa fie identic cu productia" si "vreau ca devii sa-si poata face
> > management singuri la mediul lor asa ca trebuie sa fie cat mai simplu".
> > Daca le iei pe ambele ca atare, inseamna ca ajungi ca mediul de
> > productie
> > sa fie designed de devi, pe criteriile lor, si in majoritatea cazurilor
> > nu
> > vrei asta :)
> >
> > Proiectul la care lucrez de vreo 5 ani si unde am inceput sa dau serios
> > cu
> > nasul de de-astea a inceput cu aceeasi abordare: un container facut de
> > mai
> > stiu eu cine ca de pe tutorialele de youtube si tiktok, cu purcel si
> > catel
> > in el, unde mergea totul ca root ca sa n-aiba probleme de permisiuni,
> > care
> > avea php, nginx, node, supervisord si inca cativa pokemoni.
> >
> Yep, acum ai înțeles. Cum am mai zis eu într-un post, poate nu toate
> deciziile au fost cele mai bune dar nici complet greșite nu au fost.
> În plus dacă ești admin într-o firmă îți permiți să îi pui la respect pe
> devi mai ușor, când "prestezi servicii" trebuie să te limitezi la
> persuasiune și argumente mai simplu de înțeles.
>

Ce voiam sa subliniez e ca e usor sa cazi in capcana "am 25 de ani de
experienta cu linux, repar cu ciocanelul orice problema apare", si sa te
trezesti tras la fund de deciziile astea proaste luate din nestiinta. Eu
m-am trezit pe cap cu kuberneti, dockere, docker-compose, go-uri,
composere, etc etc. Mi-am suflecat manecile si am sapat prin cod sursa,
documentatie, etc sa inteleg mai exact cum functioneaza si cum se
intentioneaza sa fie operate si m-am prins repede ca explicatiile primite
de la devi cu "a, e simplu, scrii aici magic si rulezi comanda asta magica
si merge" sunt dintr-o perspectiva in cel mai bun caz ortogonala cu
interesele de productie si ca multi au invatat astea din tutoriale care fac
skip foarte repede peste basics ca sa ajunga la meat and potatoes.

Asa ca astea cu "ce prosti sunt astia cu tehnologia X, cand era mult mai
simplu sa faci Y" sunt mai degraba root cause care ar trebui tratat, chit
ca asta presupune niste "back to school".

-- 
P. "si hai sa incheiem flama ca martea nu e vineri decat daca e ceva foarte
gresit cu ntp-ul".
___
RLUG mailing list
RLUG@lists.lug.ro
http://lists.lug.ro/mailman/listinfo/rlug_lists.lug.ro

Re: [rlug] flame de vineri ( ubuntu)





Cred ca capcana in care se cade usor aici e impacarea a "vreau ca 
mediul

de dev sa fie identic cu productia" si "vreau ca devii sa-si poata face
management singuri la mediul lor asa ca trebuie sa fie cat mai simplu".
Daca le iei pe ambele ca atare, inseamna ca ajungi ca mediul de 
productie
sa fie designed de devi, pe criteriile lor, si in majoritatea cazurilor 
nu

vrei asta :)

Proiectul la care lucrez de vreo 5 ani si unde am inceput sa dau serios 
cu
nasul de de-astea a inceput cu aceeasi abordare: un container facut de 
mai
stiu eu cine ca de pe tutorialele de youtube si tiktok, cu purcel si 
catel
in el, unde mergea totul ca root ca sa n-aiba probleme de permisiuni, 
care

avea php, nginx, node, supervisord si inca cativa pokemoni.

Yep, acum ai înțeles. Cum am mai zis eu într-un post, poate nu toate 
deciziile au fost cele mai bune dar nici complet greșite nu au fost.
În plus dacă ești admin într-o firmă îți permiți să îi pui la respect pe 
devi mai ușor, când "prestezi servicii" trebuie să te limitezi la 
persuasiune și argumente mai simplu de înțeles.


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

Re: [rlug] flame de vineri ( ubuntu)

On Tue, Mar 26, 2024 at 11:53 AM Mihai Badici via RLUG 
wrote:

> On 2024-03-26 11:26, Alex 'CAVE' Cernat via RLUG wrote:
> > On 26-Mar-24 11:21, Petru Rațiu via RLUG wrote:
> >> Daca tratezi containerele ca pe golden images de VM care au si pe
> >> dracu si
> >> pe ta-su in ele, o sa ai un numar de probleme la care raspunsul mai
> >> normal
> >> la cap e "de ce nu folosesti pana la urma vm-uri".
> >
> > ca ai mai putin overhead si pornesc mai repede, cu posibilele riscuri
> > de securitate la pachet (ca ai acelasi kernel) - asta ca si comparatie
> > intre LXC si VMs
> >
> > Alex
> >
> > ps: nu-s avocatul LXC (nici nu folosesc), mai curand al VMs, deci nu
> > sariti :-P
> Păi în final tot acolo ajungi. Eu am construit imagini din imaginea de
> bază, deci în sistem ai imaginea de bază plus diferențele ( cum era la
> mine, una era wheezy+php, alta wheezy+nginx. Cele două imagini ar
> cuprinde  imaginea de bază  -cum zice Petre, golden image - ca la
> Microsoft+ diferența care e pachetul util plus ceva customizări. Acum că
> rememorez am și o explicație, la un moment dat ajunsesem folosind
> imagini de php de la docker la un balamuc total în ceea ce priveșțe
> modulele de php; eu aveam deja un script cu care le instalam pe mașina
> fizică și în felul ăsta, punând scriptul în docker file-ul de php
> obțineam o configurație identică cu cea a serverului fizic în privința
> modulelor. Inițial scopul deploymentului a fost să realizez un mediu de
> test pentru dezvoltare, înainte de a pune aplicatia pe serverul fizic,
> care, ați ghicit, era tot wheezy. Așa se explică și insistența mea de a
> folosi imagini de jessie, ca după ce făceam upgrade pe cele fizice la
> jessie să am un mediu compatibil.
>   Ulterior urma să folosesc sistemul și în mediul de producție și dacă
> stau bine să mă gândesc chiar încă există unul în producție, dar
> varianta ulterioară, cu alpine. Tipul respectiv însă a avut probleme
> fără legătură cu IT-ul și proiectul a rămas așa...
> PS: am avut și virtuale cu golden image pe hyperv. După câțiva ani de
> update-uri diferențele au devenit mai mari decât imaginea așa că le-am
> comis sau nu mai știu cum se numește la MS și am trecut la imagini
> normale ca să economisesc spațiu...
>
> Cred ca capcana in care se cade usor aici e impacarea a "vreau ca mediul
de dev sa fie identic cu productia" si "vreau ca devii sa-si poata face
management singuri la mediul lor asa ca trebuie sa fie cat mai simplu".
Daca le iei pe ambele ca atare, inseamna ca ajungi ca mediul de productie
sa fie designed de devi, pe criteriile lor, si in majoritatea cazurilor nu
vrei asta :)

Proiectul la care lucrez de vreo 5 ani si unde am inceput sa dau serios cu
nasul de de-astea a inceput cu aceeasi abordare: un container facut de mai
stiu eu cine ca de pe tutorialele de youtube si tiktok, cu purcel si catel
in el, unde mergea totul ca root ca sa n-aiba probleme de permisiuni, care
avea php, nginx, node, supervisord si inca cativa pokemoni.

Dupa ce am pierdut niste zeci de ore citind diverse dockerfiles de la
oameni mai seriosi, am facut o abordare hibrida, cu multiple stage, ceva
gen:

FROM: php-fpm: AS base
< compilat diverse module, configurat php, pus scripturi custom>
CMD php-fpm -f
FROM base AS  local
< instalat nginx, supervisord, node, balarii>
CMD supervisord

Scripturile de build fac docker build -t base --tag  ;
respectiv docker build -t local --tag 

Devii isi trag tagul local, si au acolo tot cele trebuie (node imi trebuie
pentru ca au un webpack care face minuni cu js-uri si css-uri, pe productie
nu ruleaza decat la build).

Pe producite plec cu tagul de base, pun in el codul (masat cu composer si
webpack pe alte containere dedicate) si la runtime nu stie decat de fpm,
nginxul e in alt container, etc, etc.

In timp si pe local am mai facut split la chestii (gen nginx dedicat pentru
ca am inceput sa avem mai multe servicii care depindeau de url si care
aveau nevoie de ssl, etc), dar pot lucra local cu o chestie care seamana
doar vag cu productia, dar macar au acelasi versiuni, cai pe disc, etc.

Daca in schimb lasi ca deciziile de "sa fie usor pt dev" se informeze
setupul de prod, ajungi la probleme de-astea de care devilor nu prea le
pasa, gen cum facem upgrade-uri, cum strangem loguri, cum stim cine ce-a
modificat, etc.

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

Re: [rlug] flame de vineri ( ubuntu)


On 2024-03-26 11:20, Alex 'CAVE' Cernat via RLUG wrote:

On 26-Mar-24 11:00, Mihai Badici via RLUG wrote:
Păi soro, în imagine, dar nici în imagine, ceea ce voiam era să 
înlocuiesc From: wheezy to From:jessie în imaginile pe care le aveam.
Pe scurt fiecare imagine era builduită cu From: whezzy / apt install 
$my_app. O să îți trimit un Dockerfile dacă tot nu e clar 🙂


Eu am zis pe scurt "upgradez containerele" dar nu mi-a trecut prin cap 
ideea de a le upgrada manual 🙂


mi-am adus aminte de "ubiquitous language" din ddd (nu, nu e 
dezinsectie, deratizare si de..molare, ce spanac mai era)


cand zici "upgradezi containere", primul lucru la care ma gandesc chiar 
si eu e dist-upgrade in container :-D; dupa aia, gandul doi, e: stai ca 
asta nu se face (desi cineva zicea ca - culmea - se mai face, sper ca 
era doar o neintelegere si vorbea de fapt de LXC, unde e alta 
filosofie, chiar daca tot containere sunt)
Da, exprimarea a fost imprecisă, chiar incorectă, recunosc, dar am 
încercat să revin.
Dar e ca la meci când te arată unii "ăsta ține cu Rapidul" degeaba 
încerci să scoți steagul cu Steaua, ca nu mai apuci în mijlocul flamei 
:)



daca ziceai si prima "upgradez imaginile de container", atunci nu mai 
incapea nicio discutie


Și da, văd că acum se poate, la jessie nu se putea pentru că erau 
dependențe explicite de systemd la toate serviciile. Văd că au revenit 
în mod tacit.


oricum, si cu systemd asta, daca stam bine si ne gandim e cam invers 
filosofiei initiale de *nix (binare multe, fiecare face treaba lui si 
atat); insa in general isi face treaba chiar si systemd, astept cu 
interes server de web (tare mi-e ca deja exista) si server de baze de 
date direct in systemd, ca vad ca asa e moda mai nou ... insa e de abia 
marti, insa ar putea fi un subiect de flama pentru vineri


Problema cu systemd era că rulează ca daemon, dar docker zice că nu poți 
rula decât o aplicație (că altfel nu mai izolezi nimic ). Nu am fost 
interesat de internals dar bănuiesc că în final l-au patchuit în sensul 
ăsta, să poți să îl rulezi și one time ca să inițializeze containerul 
înainte de a porni aplicația propriu-zisă. Altfel eu n-am mare lucru cu 
el, nu sunt chiar atât de taliban, mai evoluează și filozofia. Așa ca 
fapt divers, debian are pentru apache folderul apache2 până în zilele 
noastre tocmai pentru că au vrut multă vreme să mențină compatibilitatea 
și cu apache-ul vechi și cu ăla nou. Dar în jessie au făcut schimbarea 
asta fără alternativă; motivul pentru care voiam să folosesc pachete de 
jessie l-am spus în postul anterior. Acum cred că au revenit dar sincer 
n-am mai urmărit.


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

Re: [rlug] flame de vineri ( ubuntu)

On Tue, Mar 26, 2024 at 11:27 AM Alex 'CAVE' Cernat via RLUG <
rlug@lists.lug.ro> wrote:

> On 26-Mar-24 11:21, Petru Rațiu via RLUG wrote:
> > Daca tratezi containerele ca pe golden images de VM care au si pe dracu
> si
> > pe ta-su in ele, o sa ai un numar de probleme la care raspunsul mai
> normal
> > la cap e "de ce nu folosesti pana la urma vm-uri".
>
> ca ai mai putin overhead si pornesc mai repede, cu posibilele riscuri de
> securitate la pachet (ca ai acelasi kernel) - asta ca si comparatie
> intre LXC si VMs
>
>
Overheadul ala e mai putin doar daca nu faci de-astea de care discutam si
ramai la nivelul "un binar, bibliotecile de care are nevoie si ceva sare si
piper pe langa". Daca ajungi sa vrei un chroot care face enspe chestii, mai
bine ramai pe abordarea cu simulat full OS. Also ziceam de containere in
sensul de docker/containerd/stuff , nu in sensul generic care acopera
lxc/vserver/etc. Alea cred ca intra la VM-uri in discutia asta cu
mentenanta, pentru ca in general nu se trateaza ca immutable infra,
modificarile in ele persista si ca atare incep sa faca radacini unde-s
deployate, le upgradezi in place, etc.

La dockere (sic), ideea e ca imaginea de disc e un fel de cache care ar
trebui sa poata fi refacut identic oricand pornind de la acelasi Dockerfile
si sa le poti trata mai mult ca pe artefacte de build (din taguri,
repo-uri, etc) la fel ca binare, pachete, jaruri, apk-uri, etc. De-acolo
deriva si tot felul de scheme despre minimizat dimensiunile, cache-uri pe
layere, etc., care la "vm-uri" nu prea au sens, ca acolo faci deploy o
singura data si le mai modifici oricum din mers.

Desigur, esti liber sa amesteci ciorbele dar o sa se uite lumea ciudat la
tine de ce tii tesla asa.

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

Re: [rlug] flame de vineri ( ubuntu)


On 2024-03-26 11:26, Alex 'CAVE' Cernat via RLUG wrote:

On 26-Mar-24 11:21, Petru Rațiu via RLUG wrote:
Daca tratezi containerele ca pe golden images de VM care au si pe 
dracu si
pe ta-su in ele, o sa ai un numar de probleme la care raspunsul mai 
normal

la cap e "de ce nu folosesti pana la urma vm-uri".


ca ai mai putin overhead si pornesc mai repede, cu posibilele riscuri 
de securitate la pachet (ca ai acelasi kernel) - asta ca si comparatie 
intre LXC si VMs


Alex

ps: nu-s avocatul LXC (nici nu folosesc), mai curand al VMs, deci nu 
sariti :-P
Păi în final tot acolo ajungi. Eu am construit imagini din imaginea de 
bază, deci în sistem ai imaginea de bază plus diferențele ( cum era la 
mine, una era wheezy+php, alta wheezy+nginx. Cele două imagini ar 
cuprinde  imaginea de bază  -cum zice Petre, golden image - ca la 
Microsoft+ diferența care e pachetul util plus ceva customizări. Acum că 
rememorez am și o explicație, la un moment dat ajunsesem folosind 
imagini de php de la docker la un balamuc total în ceea ce priveșțe 
modulele de php; eu aveam deja un script cu care le instalam pe mașina 
fizică și în felul ăsta, punând scriptul în docker file-ul de php 
obțineam o configurație identică cu cea a serverului fizic în privința 
modulelor. Inițial scopul deploymentului a fost să realizez un mediu de 
test pentru dezvoltare, înainte de a pune aplicatia pe serverul fizic, 
care, ați ghicit, era tot wheezy. Așa se explică și insistența mea de a 
folosi imagini de jessie, ca după ce făceam upgrade pe cele fizice la 
jessie să am un mediu compatibil.
 Ulterior urma să folosesc sistemul și în mediul de producție și dacă 
stau bine să mă gândesc chiar încă există unul în producție, dar 
varianta ulterioară, cu alpine. Tipul respectiv însă a avut probleme 
fără legătură cu IT-ul și proiectul a rămas așa...
PS: am avut și virtuale cu golden image pe hyperv. După câțiva ani de 
update-uri diferențele au devenit mai mari decât imaginea așa că le-am 
comis sau nu mai știu cum se numește la MS și am trecut la imagini 
normale ca să economisesc spațiu...


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

Re: [rlug] flame de vineri ( ubuntu)

2024-03-26 Thread Alex 'CAVE' Cernat via RLUG


On 26-Mar-24 11:21, Petru Rațiu via RLUG wrote:

Daca tratezi containerele ca pe golden images de VM care au si pe dracu si
pe ta-su in ele, o sa ai un numar de probleme la care raspunsul mai normal
la cap e "de ce nu folosesti pana la urma vm-uri".


ca ai mai putin overhead si pornesc mai repede, cu posibilele riscuri de 
securitate la pachet (ca ai acelasi kernel) - asta ca si comparatie 
intre LXC si VMs


Alex

ps: nu-s avocatul LXC (nici nu folosesc), mai curand al VMs, deci nu 
sariti :-P

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

Re: [rlug] flame de vineri ( ubuntu)

2024-03-26 Thread Dumitru Moldovan via RLUG


On 3/26/24 11:00, Mihai Badici wrote:

On 2024-03-26 10:16, Dumitru Moldovan via RLUG wrote:
Nu a fost niciodată ceva „canonic” să faci dist-upgrade la o nouă 
versiune majoră Debian într-un container Docker.  Asta îi o 
năstrușnicie în sine și probabil explică cum ai căzut în eroarea de a 
crede că aveai nevoie de systemd într-un container Debian cu nginx.


Iar pericolul monoculturii systemd cred că a cam trecut…  Și în Debian 
există suport pentru alte init-uri: https://wiki.debian.org/Init.  Mai 
nou văd că merge implicit GNOME cu GDM fără systemd, interesant…


Referință obligatorie: https://xkcd.com/386/.

Păi soro, în imagine, dar nici în imagine, ceea ce voiam era să 
înlocuiesc From: wheezy to From:jessie în imaginile pe care le aveam.
Pe scurt fiecare imagine era builduită cu From: whezzy / apt install 
$my_app. O să îți trimit un Dockerfile dacă tot nu e clar :)


Eu am zis pe scurt "upgradez containerele" dar nu mi-a trecut prin cap 
ideea de a le upgrada manual :)


Și da, văd că acum se poate, la jessie nu se putea pentru că erau 
dependențe explicite de systemd la toate serviciile. Văd că au revenit 
în mod tacit.


Ai tăiat mesajul la care ți-am răspuns, dar l-am recuperat, că nu-mi 
place să fiu acuzat aiurea.  Asta e ce ne-ai scris: „Eu am preferat să 
îmi derivez niște imagini din whezzy și voiam să le "upgradez" la jessie 
dar a fost un interval în care nu exista docker bazat pe jessie.”


Chiar și în mesajul la care răspund acum faci inițial confuzia între 
imagini și fișierul Dockerfile.  Cât ne mai potopești cu asemenea 
bălmăjeli?  Și care-i scopul?


Iar din apelativul colorat ce să mai înțeleg?  Când cineva pare că 
greșește, merită să fie apelat ca o persoană de sex feminin?  Deci 
misoginism, nene?  Hai să ne oprim totuși, că deja cădem în ridicol…



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

Re: [rlug] flame de vineri ( ubuntu)

On Tue, Mar 26, 2024 at 11:00 AM Mihai Badici via RLUG 
wrote:

> On 2024-03-26 10:16, Dumitru Moldovan via RLUG wrote:
> > Nu a fost niciodată ceva „canonic” să faci dist-upgrade la o nouă
> > versiune majoră Debian într-un container Docker.  Asta îi o
> > năstrușnicie în sine și probabil explică cum ai căzut în eroarea de a
> > crede că aveai nevoie de systemd într-un container Debian cu nginx.
> >
> > Iar pericolul monoculturii systemd cred că a cam trecut…  Și în Debian
> > există suport pentru alte init-uri: https://wiki.debian.org/Init.  Mai
> > nou văd că merge implicit GNOME cu GDM fără systemd, interesant…
> >
> > Referință obligatorie: https://xkcd.com/386/.
> >
> Păi soro, în imagine, dar nici în imagine, ceea ce voiam era să
> înlocuiesc From: wheezy to From:jessie în imaginile pe care le aveam.
> Pe scurt fiecare imagine era builduită cu From: whezzy / apt install
> $my_app. O să îți trimit un Dockerfile dacă tot nu e clar :)
>
>
Ok, acum am inteles cum ai ajuns la problema asta. Scripturile de
post-install de pachete nu-s intentionate pentru mediul de containere. Vezi
cum se fac imaginile oficiale de diverse chestii: se compileaza binarele si
se copiaza in imagine.

Tot tam-tam-ul cu scripturi de init, logrotate, samd sunt inutile in
container, pentru ca e instantiat direct cu exec nginx (sau whatever),
practic finalul scriptului de init (sau unit file). In cel mai bun caz, pui
un script ca entrypoint care sa faca nitica bucatarie (gen sa seteze
anumite variabile de mediu sau configuri in functie de ce descopera la
runtime), si de-aia te ajuta sa ai distributie, sa poti instala usor ce
pachete iti trebuie pentru asta.

> Eu am zis pe scurt "upgradez containerele" dar nu mi-a trecut prin cap
> ideea de a le upgrada manual :)
>

Daca interiorizezi putin ce ti-am zis inainte, constati ca "upgrade" la
containere inseamna "schimb niste versiuni in dockerfile si refac pe niste
containere upgradate de altii". apt upgrade e nerecomandat pentru ca poate
schimba multe lucruri si nu doar ca iti face imaginea mult mai mare dar e
si stufos de documentat ce s-a schimbat, in momentul in care incepe sa-ti
pese de probleme de-alea de supply chain security etc.
Daca tratezi containerele ca pe golden images de VM care au si pe dracu si
pe ta-su in ele, o sa ai un numar de probleme la care raspunsul mai normal
la cap e "de ce nu folosesti pana la urma vm-uri".

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

Re: [rlug] flame de vineri ( ubuntu)

2024-03-26 Thread Alex 'CAVE' Cernat via RLUG


On 26-Mar-24 11:00, Mihai Badici via RLUG wrote:
Păi soro, în imagine, dar nici în imagine, ceea ce voiam era să 
înlocuiesc From: wheezy to From:jessie în imaginile pe care le aveam.
Pe scurt fiecare imagine era builduită cu From: whezzy / apt install 
$my_app. O să îți trimit un Dockerfile dacă tot nu e clar 🙂


Eu am zis pe scurt "upgradez containerele" dar nu mi-a trecut prin cap 
ideea de a le upgrada manual 🙂


mi-am adus aminte de "ubiquitous language" din ddd (nu, nu e 
dezinsectie, deratizare si de..molare, ce spanac mai era)


cand zici "upgradezi containere", primul lucru la care ma gandesc chiar 
si eu e dist-upgrade in container :-D; dupa aia, gandul doi, e: stai ca 
asta nu se face (desi cineva zicea ca - culmea - se mai face, sper ca 
era doar o neintelegere si vorbea de fapt de LXC, unde e alta filosofie, 
chiar daca tot containere sunt)
daca ziceai si prima "upgradez imaginile de container", atunci nu mai 
incapea nicio discutie


Și da, văd că acum se poate, la jessie nu se putea pentru că erau 
dependențe explicite de systemd la toate serviciile. Văd că au revenit 
în mod tacit.


oricum, si cu systemd asta, daca stam bine si ne gandim e cam invers 
filosofiei initiale de *nix (binare multe, fiecare face treaba lui si 
atat); insa in general isi face treaba chiar si systemd, astept cu 
interes server de web (tare mi-e ca deja exista) si server de baze de 
date direct in systemd, ca vad ca asa e moda mai nou ... insa e de abia 
marti, insa ar putea fi un subiect de flama pentru vineri :-D


Alex


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

Re: [rlug] flame de vineri ( ubuntu)


On 2024-03-26 10:16, Dumitru Moldovan via RLUG wrote:
Nu a fost niciodată ceva „canonic” să faci dist-upgrade la o nouă 
versiune majoră Debian într-un container Docker.  Asta îi o 
năstrușnicie în sine și probabil explică cum ai căzut în eroarea de a 
crede că aveai nevoie de systemd într-un container Debian cu nginx.


Iar pericolul monoculturii systemd cred că a cam trecut…  Și în Debian 
există suport pentru alte init-uri: https://wiki.debian.org/Init.  Mai 
nou văd că merge implicit GNOME cu GDM fără systemd, interesant…


Referință obligatorie: https://xkcd.com/386/.

Păi soro, în imagine, dar nici în imagine, ceea ce voiam era să 
înlocuiesc From: wheezy to From:jessie în imaginile pe care le aveam.
Pe scurt fiecare imagine era builduită cu From: whezzy / apt install 
$my_app. O să îți trimit un Dockerfile dacă tot nu e clar :)


Eu am zis pe scurt "upgradez containerele" dar nu mi-a trecut prin cap 
ideea de a le upgrada manual :)


Și da, văd că acum se poate, la jessie nu se putea pentru că erau 
dependențe explicite de systemd la toate serviciile. Văd că au revenit 
în mod tacit.



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

Re: [rlug] flame de vineri ( ubuntu)

2024-03-26 Thread Dumitru Moldovan via RLUG

Nu a fost niciodată ceva „canonic” să faci dist-upgrade la o nouă 
versiune majoră Debian într-un container Docker.  Asta îi o năstrușnicie 
în sine și probabil explică cum ai căzut în eroarea de a crede că aveai 
nevoie de systemd într-un container Debian cu nginx.


Iar pericolul monoculturii systemd cred că a cam trecut…  Și în Debian 
există suport pentru alte init-uri: https://wiki.debian.org/Init.  Mai 
nou văd că merge implicit GNOME cu GDM fără systemd, interesant…


Referință obligatorie: https://xkcd.com/386/.

On 3/25/24 20:28, Mihai Badici via RLUG wrote:
Da, uite, acum la rece să încerc să pun problema altfel. Eu am un 
oarecare interes pentru sistemele embeded, chestie care nu e deloc 
depășită ci chiar devine din ce în ce mai la modă. Referințele la 
slackware le fac mai mult ca să epatez burghezii; el a evoluat fix 
invers: încercând să fie cât mai clean a devenit irelevant pentru 
sistemele normale.


Docker e oarecum în aceeași găleată, chiar dacă e "embeded" software, nu 
hardware.


De asta sunt un pic debusolat de ușurința cu care se renunță (de tot) la 
un init minimal pentru unul maximal. Că evident că în multe scenarii 
systemd are avantaje și până la urmă dacă se poate de ce nu.


Asta înseamnă că la un moment dat o distribuție care se vrea universală 
nu prea mai e ce trebuie pentru o întreagă categorie de device-uri (ca 
să mă autoconving că nu vorbeam chiar prostii am verificat în 
changelog-ul systemd și chiar există un patch prin 2014 referitor la 
"tratarea docker ca un tip special de container").


Eu am preferat să îmi derivez niște imagini din whezzy și voiam să le 
"upgradez" la jessie dar a fost un interval în care nu exista docker 
bazat pe jessie. Acum văd că dezvoltatorii au devenit mai flexibili, 
pentru că nginx din bookworm nu pare că mai depinde, cel puțin nu 
direct, de systemd. Dar deduc că și tu folosești alpine, eu am ajuns la 
el pentru că atunci nu aveam alternativă și în general fără momentul ăla 
de talibăneală probabil că nici nu s-ar fi auzit de el...


Te asigur că tot ce am făcut era complet "canonic" și că am studiat 
destul de mult docker la momentul respectiv. Doar că am optat pentru 
niște pachete pe care le știam stable, nu pentru nginx/latest .


Mă gândesc că vreo zece ani tot o să mai fim cât de cât relevanți, măcar 
să mai reparăm din trăznăile pe care le fac ăștia micii din prea mult 
entuziasm... doar că hai să zicem că aria mea de interes e un pic 
diferită. Mă gândeam că anumite lucruri ar fi putut coexista într-o lume 
"mai bună și mai dreaptă", cum zicea un dictator din tinerețea mea. KISS 
e încă valid și va mai fi probabil și în următorul mileniu, chiar dacă 
evident, în afară de a ține lucrurile simple trebuie să avem în vedere 
să ne rezolve și problemele, ceea ce, suntem cu toții de acord, ar putea 
să fie mai complicat decât ne dorim.


Ce să zic, pe următoarea vineri când mă mai enervez :)

On 3/23/24 09:24, Dumitru Moldovan via RLUG wrote:

Mihai,

Ca de la un „linuxist bătrân” la altul, ca să citez un clasic al 
acestei liste de discuții…  Petru a încercat în mod repetat, cu o 
răbdare pe care io personal nu o mai am, să te ajute să înțelegi unde 
greșești.  Cu cât se dezvoltă discuția însă, cu atât ne dezvălui mai 
multe niveluri unde se întâmplă aceste greșeli.


Acuma mno, toți avem un ego care ne orbește și ne împiedică să ne 
vedem propriile limitări.  Dar, vorba aia, până la urmă ce vrem să 
ajungem la vârsta a treia?  Niște moșnegi oțetiți de propriile 
frustrări, pe care nici măcar nu le prea înțelegem?  Sau, precum un 
vin de calitate, ceva încă recomandabil?


Dacă duci dorul vechii configurări de rețea din Slackware, îți 
recomand OpenBSD, care a dus această simplificare până la concluzia ei 
logică, o soluție elegantă ce unifică inclusiv configurările de rețea 
fără fir. Însă de vrem să supraviețuim dpdv comercial în actualul 
context, trebuie să înțelegem care-i treaba cu Docker, de exemplu. 
Abia apoi ne putem avânta în lamentări mai la obiect privind „the old 
ways”…


On 3/23/24 07:28, Mihai Badici via RLUG wrote:

Neața :)

Da, cumva ne apropiem, după cum ziceam vorbim de un proiect de prin 
2014-16 deci nu îmi mai amintesc nici eu bine.


Tu folosești nginx:latest care la rândul lui e și el derivat din ceva 
( nu de către tine, de către alții, dar e) . Dacă te uiți la ce am 
dat eu, imaginile mele erau derivate dintr-o imagine de wheezy.


Acum poate oi fi greșit eu la acel moment, fiecare imagine era cu 
From: debian/wheezy și apt-install  aplicația mea. Aș fi putut 
probabil să le iau direct cu from: nginx:latest și să ignor că unul 
din containere ar putea fi bazat pe debian și altul pe alpine; eu așa 
m-am gândit, că e mai bine ca toate imaginile să aibă aceeași bază și 
pentru că debian foloseam atunci, să fie debian.


Cum docker e bazat pe layere succesive m-am gândit că așa e cel mai 
economic și mai ușor de întreținut.


Sigur că tu dacă o iei din nginx:latest pasezi problema la altul, 
ceea ce e bine

Re: [rlug] flame de vineri ( ubuntu)

2024-03-25 Thread Cristian Paslaru via RLUG

Tineretu ca tineretu, dar nici batranii nu se lasa, cum este COBOL, care a
mai scos totusi un standard "COBOL 2023" ;)

On Mon, Mar 25, 2024 at 8:08 PM Petru Rațiu via RLUG 
wrote:

> Eu tot zic ca ai niste XY problem derivate din insistenta de a vedea niste
> probleme in modul in care le-ai intuit initial. Sunt cel putin 2-3 acolo si
> poate intr-o discutie mai la rece cu "uite ce problema am _de fapt_ si uite
> de ce nu mi se pare ca solutiile pe care le gasesc la prima vedere pe
> internet nu mi se aplica" s-ar putea rezolva.
>
> Ce m-a zgariat insa pe corazon e abordarea aia zeflemitoare cu "tineretu
> din ziua de azi / pe vremea mea / yadda yadda" pe care nu doar ca o
> recunosc de pe vremea cand _noi_ eram "tineretul din ziua de azi", dar
> chiar e o abordare pe care trebuie sa ma conving singur in oglinda
> dimineata sa n-o am. Ca unul care se apropie in viteza de faza "cine n-are
> batrani sa-si cumpere / o sa ajungeti la vorba mea", sunt de parere ca
> relevanta aia de care zici n-o sa fie sub forma "o sa vina momentul cand or
> sa aiba astia nevoie de cineva care sa stie tehnologia antica X", ci din
> experienta de a vedea usor lucrurile si din alte puncte de vedere :)
>
> Si mai era si vineri, si flama...
>
> --
> P.
>
> On Mon, Mar 25, 2024 at 8:28 PM Mihai Badici via RLUG 
> wrote:
>
> > Da, uite, acum la rece să încerc să pun problema altfel. Eu am un
> > oarecare interes pentru sistemele embeded, chestie care nu e deloc
> > depășită ci chiar devine din ce în ce mai la modă. Referințele la
> > slackware le fac mai mult ca să epatez burghezii; el a evoluat fix
> > invers: încercând să fie cât mai clean a devenit irelevant pentru
> > sistemele normale.
> >
> > Docker e oarecum în aceeași găleată, chiar dacă e "embeded" software, nu
> > hardware.
> >
> > De asta sunt un pic debusolat de ușurința cu care se renunță (de tot) la
> > un init minimal pentru unul maximal. Că evident că în multe scenarii
> > systemd are avantaje și până la urmă dacă se poate de ce nu.
> >
> > Asta înseamnă că la un moment dat o distribuție care se vrea universală
> > nu prea mai e ce trebuie pentru o întreagă categorie de device-uri (ca
> > să mă autoconving că nu vorbeam chiar prostii am verificat în
> > changelog-ul systemd și chiar există un patch prin 2014 referitor la
> > "tratarea docker ca un tip special de container").
> >
> > Eu am preferat să îmi derivez niște imagini din whezzy și voiam să le
> > "upgradez" la jessie dar a fost un interval în care nu exista docker
> > bazat pe jessie. Acum văd că dezvoltatorii au devenit mai flexibili,
> > pentru că nginx din bookworm nu pare că mai depinde, cel puțin nu
> > direct, de systemd. Dar deduc că și tu folosești alpine, eu am ajuns la
> > el pentru că atunci nu aveam alternativă și în general fără momentul ăla
> > de talibăneală probabil că nici nu s-ar fi auzit de el...
> >
> > Te asigur că tot ce am făcut era complet "canonic" și că am studiat
> > destul de mult docker la momentul respectiv. Doar că am optat pentru
> > niște pachete pe care le știam stable, nu pentru nginx/latest .
> >
> > Mă gândesc că vreo zece ani tot o să mai fim cât de cât relevanți, măcar
> > să mai reparăm din trăznăile pe care le fac ăștia micii din prea mult
> > entuziasm... doar că hai să zicem că aria mea de interes e un pic
> > diferită. Mă gândeam că anumite lucruri ar fi putut coexista într-o lume
> > "mai bună și mai dreaptă", cum zicea un dictator din tinerețea mea. KISS
> > e încă valid și va mai fi probabil și în următorul mileniu, chiar dacă
> > evident, în afară de a ține lucrurile simple trebuie să avem în vedere
> > să ne rezolve și problemele, ceea ce, suntem cu toții de acord, ar putea
> > să fie mai complicat decât ne dorim.
> >
> > Ce să zic, pe următoarea vineri când mă mai enervez :)
> >
> > On 3/23/24 09:24, Dumitru Moldovan via RLUG wrote:
> > > Mihai,
> > >
> > > Ca de la un „linuxist bătrân” la altul, ca să citez un clasic al
> > > acestei liste de discuții…  Petru a încercat în mod repetat, cu o
> > > răbdare pe care io personal nu o mai am, să te ajute să înțelegi unde
> > > greșești.  Cu cât se dezvoltă discuția însă, cu atât ne dezvălui mai
> > > multe niveluri unde se întâmplă aceste greșeli.
> > >
> > > Acuma mno, toți avem un ego care ne orbește și ne împiedică să ne
> > > vedem propriile limitări.  Dar, vorba aia, până la urmă ce vrem să
> > > ajungem la vârsta a treia?  Niște moșnegi oțetiți de propriile
> > > frustrări, pe care nici măcar nu le prea înțelegem?  Sau, precum un
> > > vin de calitate, ceva încă recomandabil?
> > >
> > > Dacă duci dorul vechii configurări de rețea din Slackware, îți
> > > recomand OpenBSD, care a dus această simplificare până la concluzia ei
> > > logică, o soluție elegantă ce unifică inclusiv configurările de rețea
> > > fără fir. Însă de vrem să supraviețuim dpdv comercial în actualul
> > > context, trebuie să înțelegem care-i treaba cu Docker, de exemplu.
> > > Abia apoi ne putem avânta în lamentări mai la obiect privind

Re: [rlug] flame de vineri ( ubuntu)

2024-03-25 Thread Mihai Badici via RLUG

Păi nu aveam nici o problemă concretă de rezolvat, aplicația a fost deja 
livrată :)


Exact cum zici, acum incerc să văd lucrurile în perspectivă, uneori îmi 
iese alteori nu.


Evident că și la mine era vineri și am scris și eu vreo două prostii din 
graba tastării iar pe altele nu le-am explicat coerent.


Și da, și eu încerc să îmi pun problema (că sunt și mai bătrân decât 
tine) dacă nu cumva sufăr de sindromul ăsta ( așa, un pic, e inevitabil, 
oricât ne-am feri :) ) dar zic că aici problema e reală.


Că dacă ar fi să postez de câte ori îmi zic în gând "tinerii din ziua de 
azi" lista ar avea deja traficul de pe vremuri :) Dar după aia mă 
gândesc mai bine și văd că au și ei dreptatea lor.  Dar na, uneori te 
mai apucă. După cum nu totdeauna "era mai bine pe vremea noastră" nici 
reciproca nu e chiar adevărată. În plus cu timpul devii mai defensiv, 
dar asta nu e neapărat o problemă de bătrânețe ci de experiență.


Mai e o chestie: când ești în mijlocul evenimentelor ai parte și de o 
grămadă de garbage. Unele chestii par cool acum dar dispar anul următor. 
Mai ții minte cum se numeau containerele folosite pe proxmox înainte de 
lxc? Eu nu, și am folosit. Adică există și bullyngul de sens contrar, în 
care ți se spune că ești depășit iar în anul următor... surpriză, a 
murit americanu' :)


Cumva în tehnologia asta există o oarecare circularitate, anumite 
chestii vechi se reinventează și devin cool. Mai ții minte vremea cănd 
procesoarele aveau coprocesor matematic? Acum au GPU :)



On 3/25/24 21:07, Petru Rațiu via RLUG wrote:

Eu tot zic ca ai niste XY problem derivate din insistenta de a vedea niste
probleme in modul in care le-ai intuit initial. Sunt cel putin 2-3 acolo si
poate intr-o discutie mai la rece cu "uite ce problema am _de fapt_ si uite
de ce nu mi se pare ca solutiile pe care le gasesc la prima vedere pe
internet nu mi se aplica" s-ar putea rezolva.

Ce m-a zgariat insa pe corazon e abordarea aia zeflemitoare cu "tineretu
din ziua de azi / pe vremea mea / yadda yadda" pe care nu doar ca o
recunosc de pe vremea cand _noi_ eram "tineretul din ziua de azi", dar
chiar e o abordare pe care trebuie sa ma conving singur in oglinda
dimineata sa n-o am. Ca unul care se apropie in viteza de faza "cine n-are
batrani sa-si cumpere / o sa ajungeti la vorba mea", sunt de parere ca
relevanta aia de care zici n-o sa fie sub forma "o sa vina momentul cand or
sa aiba astia nevoie de cineva care sa stie tehnologia antica X", ci din
experienta de a vedea usor lucrurile si din alte puncte de vedere :)

Si mai era si vineri, si flama...



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

Re: [rlug] flame de vineri ( ubuntu)

2024-03-25 Thread Petru Rațiu via RLUG

Eu tot zic ca ai niste XY problem derivate din insistenta de a vedea niste
probleme in modul in care le-ai intuit initial. Sunt cel putin 2-3 acolo si
poate intr-o discutie mai la rece cu "uite ce problema am _de fapt_ si uite
de ce nu mi se pare ca solutiile pe care le gasesc la prima vedere pe
internet nu mi se aplica" s-ar putea rezolva.

Ce m-a zgariat insa pe corazon e abordarea aia zeflemitoare cu "tineretu
din ziua de azi / pe vremea mea / yadda yadda" pe care nu doar ca o
recunosc de pe vremea cand _noi_ eram "tineretul din ziua de azi", dar
chiar e o abordare pe care trebuie sa ma conving singur in oglinda
dimineata sa n-o am. Ca unul care se apropie in viteza de faza "cine n-are
batrani sa-si cumpere / o sa ajungeti la vorba mea", sunt de parere ca
relevanta aia de care zici n-o sa fie sub forma "o sa vina momentul cand or
sa aiba astia nevoie de cineva care sa stie tehnologia antica X", ci din
experienta de a vedea usor lucrurile si din alte puncte de vedere :)

Si mai era si vineri, si flama...

-- 
P.

On Mon, Mar 25, 2024 at 8:28 PM Mihai Badici via RLUG 
wrote:

> Da, uite, acum la rece să încerc să pun problema altfel. Eu am un
> oarecare interes pentru sistemele embeded, chestie care nu e deloc
> depășită ci chiar devine din ce în ce mai la modă. Referințele la
> slackware le fac mai mult ca să epatez burghezii; el a evoluat fix
> invers: încercând să fie cât mai clean a devenit irelevant pentru
> sistemele normale.
>
> Docker e oarecum în aceeași găleată, chiar dacă e "embeded" software, nu
> hardware.
>
> De asta sunt un pic debusolat de ușurința cu care se renunță (de tot) la
> un init minimal pentru unul maximal. Că evident că în multe scenarii
> systemd are avantaje și până la urmă dacă se poate de ce nu.
>
> Asta înseamnă că la un moment dat o distribuție care se vrea universală
> nu prea mai e ce trebuie pentru o întreagă categorie de device-uri (ca
> să mă autoconving că nu vorbeam chiar prostii am verificat în
> changelog-ul systemd și chiar există un patch prin 2014 referitor la
> "tratarea docker ca un tip special de container").
>
> Eu am preferat să îmi derivez niște imagini din whezzy și voiam să le
> "upgradez" la jessie dar a fost un interval în care nu exista docker
> bazat pe jessie. Acum văd că dezvoltatorii au devenit mai flexibili,
> pentru că nginx din bookworm nu pare că mai depinde, cel puțin nu
> direct, de systemd. Dar deduc că și tu folosești alpine, eu am ajuns la
> el pentru că atunci nu aveam alternativă și în general fără momentul ăla
> de talibăneală probabil că nici nu s-ar fi auzit de el...
>
> Te asigur că tot ce am făcut era complet "canonic" și că am studiat
> destul de mult docker la momentul respectiv. Doar că am optat pentru
> niște pachete pe care le știam stable, nu pentru nginx/latest .
>
> Mă gândesc că vreo zece ani tot o să mai fim cât de cât relevanți, măcar
> să mai reparăm din trăznăile pe care le fac ăștia micii din prea mult
> entuziasm... doar că hai să zicem că aria mea de interes e un pic
> diferită. Mă gândeam că anumite lucruri ar fi putut coexista într-o lume
> "mai bună și mai dreaptă", cum zicea un dictator din tinerețea mea. KISS
> e încă valid și va mai fi probabil și în următorul mileniu, chiar dacă
> evident, în afară de a ține lucrurile simple trebuie să avem în vedere
> să ne rezolve și problemele, ceea ce, suntem cu toții de acord, ar putea
> să fie mai complicat decât ne dorim.
>
> Ce să zic, pe următoarea vineri când mă mai enervez :)
>
> On 3/23/24 09:24, Dumitru Moldovan via RLUG wrote:
> > Mihai,
> >
> > Ca de la un „linuxist bătrân” la altul, ca să citez un clasic al
> > acestei liste de discuții…  Petru a încercat în mod repetat, cu o
> > răbdare pe care io personal nu o mai am, să te ajute să înțelegi unde
> > greșești.  Cu cât se dezvoltă discuția însă, cu atât ne dezvălui mai
> > multe niveluri unde se întâmplă aceste greșeli.
> >
> > Acuma mno, toți avem un ego care ne orbește și ne împiedică să ne
> > vedem propriile limitări.  Dar, vorba aia, până la urmă ce vrem să
> > ajungem la vârsta a treia?  Niște moșnegi oțetiți de propriile
> > frustrări, pe care nici măcar nu le prea înțelegem?  Sau, precum un
> > vin de calitate, ceva încă recomandabil?
> >
> > Dacă duci dorul vechii configurări de rețea din Slackware, îți
> > recomand OpenBSD, care a dus această simplificare până la concluzia ei
> > logică, o soluție elegantă ce unifică inclusiv configurările de rețea
> > fără fir. Însă de vrem să supraviețuim dpdv comercial în actualul
> > context, trebuie să înțelegem care-i treaba cu Docker, de exemplu.
> > Abia apoi ne putem avânta în lamentări mai la obiect privind „the old
> > ways”…
> >
> > On 3/23/24 07:28, Mihai Badici via RLUG wrote:
> >> Neața :)
> >>
> >> Da, cumva ne apropiem, după cum ziceam vorbim de un proiect de prin
> >> 2014-16 deci nu îmi mai amintesc nici eu bine.
> >>
> >> Tu folosești nginx:latest care la rândul lui e și el derivat din ceva
> >> ( nu de către tine, de către alții, dar e) . Dacă

Re: [rlug] flame de vineri ( ubuntu)

2024-03-25 Thread Mihai Badici via RLUG

Da, uite, acum la rece să încerc să pun problema altfel. Eu am un 
oarecare interes pentru sistemele embeded, chestie care nu e deloc 
depășită ci chiar devine din ce în ce mai la modă. Referințele la 
slackware le fac mai mult ca să epatez burghezii; el a evoluat fix 
invers: încercând să fie cât mai clean a devenit irelevant pentru 
sistemele normale.


Docker e oarecum în aceeași găleată, chiar dacă e "embeded" software, nu 
hardware.


De asta sunt un pic debusolat de ușurința cu care se renunță (de tot) la 
un init minimal pentru unul maximal. Că evident că în multe scenarii 
systemd are avantaje și până la urmă dacă se poate de ce nu.


Asta înseamnă că la un moment dat o distribuție care se vrea universală 
nu prea mai e ce trebuie pentru o întreagă categorie de device-uri (ca 
să mă autoconving că nu vorbeam chiar prostii am verificat în 
changelog-ul systemd și chiar există un patch prin 2014 referitor la 
"tratarea docker ca un tip special de container").


Eu am preferat să îmi derivez niște imagini din whezzy și voiam să le 
"upgradez" la jessie dar a fost un interval în care nu exista docker 
bazat pe jessie. Acum văd că dezvoltatorii au devenit mai flexibili, 
pentru că nginx din bookworm nu pare că mai depinde, cel puțin nu 
direct, de systemd. Dar deduc că și tu folosești alpine, eu am ajuns la 
el pentru că atunci nu aveam alternativă și în general fără momentul ăla 
de talibăneală probabil că nici nu s-ar fi auzit de el...


Te asigur că tot ce am făcut era complet "canonic" și că am studiat 
destul de mult docker la momentul respectiv. Doar că am optat pentru 
niște pachete pe care le știam stable, nu pentru nginx/latest .


Mă gândesc că vreo zece ani tot o să mai fim cât de cât relevanți, măcar 
să mai reparăm din trăznăile pe care le fac ăștia micii din prea mult 
entuziasm... doar că hai să zicem că aria mea de interes e un pic 
diferită. Mă gândeam că anumite lucruri ar fi putut coexista într-o lume 
"mai bună și mai dreaptă", cum zicea un dictator din tinerețea mea. KISS 
e încă valid și va mai fi probabil și în următorul mileniu, chiar dacă 
evident, în afară de a ține lucrurile simple trebuie să avem în vedere 
să ne rezolve și problemele, ceea ce, suntem cu toții de acord, ar putea 
să fie mai complicat decât ne dorim.


Ce să zic, pe următoarea vineri când mă mai enervez :)

On 3/23/24 09:24, Dumitru Moldovan via RLUG wrote:

Mihai,

Ca de la un „linuxist bătrân” la altul, ca să citez un clasic al 
acestei liste de discuții…  Petru a încercat în mod repetat, cu o 
răbdare pe care io personal nu o mai am, să te ajute să înțelegi unde 
greșești.  Cu cât se dezvoltă discuția însă, cu atât ne dezvălui mai 
multe niveluri unde se întâmplă aceste greșeli.


Acuma mno, toți avem un ego care ne orbește și ne împiedică să ne 
vedem propriile limitări.  Dar, vorba aia, până la urmă ce vrem să 
ajungem la vârsta a treia?  Niște moșnegi oțetiți de propriile 
frustrări, pe care nici măcar nu le prea înțelegem?  Sau, precum un 
vin de calitate, ceva încă recomandabil?


Dacă duci dorul vechii configurări de rețea din Slackware, îți 
recomand OpenBSD, care a dus această simplificare până la concluzia ei 
logică, o soluție elegantă ce unifică inclusiv configurările de rețea 
fără fir. Însă de vrem să supraviețuim dpdv comercial în actualul 
context, trebuie să înțelegem care-i treaba cu Docker, de exemplu.  
Abia apoi ne putem avânta în lamentări mai la obiect privind „the old 
ways”…


On 3/23/24 07:28, Mihai Badici via RLUG wrote:

Neața :)

Da, cumva ne apropiem, după cum ziceam vorbim de un proiect de prin 
2014-16 deci nu îmi mai amintesc nici eu bine.


Tu folosești nginx:latest care la rândul lui e și el derivat din ceva 
( nu de către tine, de către alții, dar e) . Dacă te uiți la ce am 
dat eu, imaginile mele erau derivate dintr-o imagine de wheezy.


Acum poate oi fi greșit eu la acel moment, fiecare imagine era cu 
From: debian/wheezy și apt-install  aplicația mea. Aș fi putut 
probabil să le iau direct cu from: nginx:latest și să ignor că unul 
din containere ar putea fi bazat pe debian și altul pe alpine; eu așa 
m-am gândit, că e mai bine ca toate imaginile să aibă aceeași bază și 
pentru că debian foloseam atunci, să fie debian.


Cum docker e bazat pe layere succesive m-am gândit că așa e cel mai 
economic și mai ușor de întreținut.


Sigur că tu dacă o iei din nginx:latest pasezi problema la altul, 
ceea ce e bine pentru tine dar nu schimbă lucrurile. Și nginx:latest 
e probabil derivat tot din bookworm:latest, doar că nu de tine, și 
după from probabil tot apt-get install nginx are (eu am refuzat moda 
de a compila aplicația în Dockerfile, deși venind dinsprte slackware 
s-ar zice că e contraintuitiv :) )


Mă rog, nu are importanță, era doar o problemă de demult pe care am 
adus-o în discuție ca să ilustrez o tendință.


Aparent, proiectele de it sunt doar de două feluri: alea 
subfinanțate, unde se improvizează ca să meargă, și alea 
suprafinanțate, în care oamenii trebuie

Re: [rlug] flame de vineri ( ubuntu)

2024-03-23 Thread Mihai Badici via RLUG

Aia pe care o foloseam eu, derivată din installerul de slack, avea 
uclibc, cred că într-o vreme cam asta se folosea. Tot așa, am mai 
înlocuit și eu cu binare pe ici pe colo. Dar nu m-am mai interesat de mult.


Depinde și ce aplicații păstorești, cred că eu pe vremuri am avut 
probleme cu rulat bitdefender cu uclibc - că pe ăsta îl integrasem în 
imagine-  dar de la o anumită versiune în sus a mers.


On 3/23/24 18:25, Dumitru Moldovan via RLUG wrote:

On 3/22/24 22:48, Petru Rațiu via RLUG wrote:
[…]

Also, hate-ul cu alpine nu se refera la busybox (appleturile alea din
busybox sunt relativ usor de invatat ce limitari au si la o adica 
poti pune
binarele care iti trebuie), ci la faptul ca libc-ul folosit nu e 
glibc sau

eglibc, ci musl, o implementare mult mai light. Care merge suficient de
bine pana dai cu capul de chestii lipsa (sau de binare "pentru linux" 
care

au fost linkate cu glibc).


Chestiile lipsă în musl îs pe cale de dispariție…  Eu am descoperit 
acest libc în Alpine, unde cred că a fost un factor important în 
succesul distribuției în containere.  Dar și pe laptop folosesc tot 
ceva pe bază de musl și nu cred că mai revin la glibc vreodată.


Pe lângă că e mai ușurel, mai bine scris și ceva mai modern, musl are 
pentru mine calitatea unui filtru de mizerii…  Dacă un software merge 
cu musl (de regulă și cu alte libc-uri, precum cele din BSD-uri), e 
semnul unei bune portabilități și de regulă a unei bune calități.


În plus, nu prea există software comercial să meargă cu musl (aș fi 
zis că nu există deloc, dar cum binarele Go includ propriul libc, 
probabil că există destule).  Deci mi-e mai greu spre imposibil să 
ajung să depind pe propriile stații de lucru de ceva ce nu e free 
software.


Chiar și acel plugin DRM din Firefox, de exemplu, necesită glibc. Asta 
poate părea un moft, dar pentru mine e important.  Neavând glibc, am 
simțit imediat de exemplu impactul trecerii canalelor Digi Online de 
la stream-uri „normale” la unele ce necesită decodare DRM.  Inițial 
le-au codat DRM doar pe cele de sport ale lor, acuma toate necesită 
DRM.  Dacă eram pe Devuan cu glibc și Firefox/Kodi cu decodare DRM 
out-of-the-box, nici nu realizam ce se întâmplă…


Nu contest, mai am nevoie de decodare DRM uneori ori alte fantezii, 
motiv pentru care folosesc Flatpak, Wine și chiar o mașină virtuală cu 
Windows o dată pe an pentru PDF-ul vieții de la ANAF.  Dar îs 
conștient de fiecare dată de ce fac asta și ce implică asemenea 
compromisuri.


___
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] flame de vineri ( ubuntu)

2024-03-23 Thread Dumitru Moldovan via RLUG


On 3/22/24 22:48, Petru Rațiu via RLUG wrote:
[…]

Also, hate-ul cu alpine nu se refera la busybox (appleturile alea din
busybox sunt relativ usor de invatat ce limitari au si la o adica poti pune
binarele care iti trebuie), ci la faptul ca libc-ul folosit nu e glibc sau
eglibc, ci musl, o implementare mult mai light. Care merge suficient de
bine pana dai cu capul de chestii lipsa (sau de binare "pentru linux" care
au fost linkate cu glibc).


Chestiile lipsă în musl îs pe cale de dispariție…  Eu am descoperit 
acest libc în Alpine, unde cred că a fost un factor important în 
succesul distribuției în containere.  Dar și pe laptop folosesc tot ceva 
pe bază de musl și nu cred că mai revin la glibc vreodată.


Pe lângă că e mai ușurel, mai bine scris și ceva mai modern, musl are 
pentru mine calitatea unui filtru de mizerii…  Dacă un software merge cu 
musl (de regulă și cu alte libc-uri, precum cele din BSD-uri), e semnul 
unei bune portabilități și de regulă a unei bune calități.


În plus, nu prea există software comercial să meargă cu musl (aș fi zis 
că nu există deloc, dar cum binarele Go includ propriul libc, probabil 
că există destule).  Deci mi-e mai greu spre imposibil să ajung să 
depind pe propriile stații de lucru de ceva ce nu e free software.


Chiar și acel plugin DRM din Firefox, de exemplu, necesită glibc.  Asta 
poate părea un moft, dar pentru mine e important.  Neavând glibc, am 
simțit imediat de exemplu impactul trecerii canalelor Digi Online de la 
stream-uri „normale” la unele ce necesită decodare DRM.  Inițial le-au 
codat DRM doar pe cele de sport ale lor, acuma toate necesită DRM.  Dacă 
eram pe Devuan cu glibc și Firefox/Kodi cu decodare DRM out-of-the-box, 
nici nu realizam ce se întâmplă…


Nu contest, mai am nevoie de decodare DRM uneori ori alte fantezii, 
motiv pentru care folosesc Flatpak, Wine și chiar o mașină virtuală cu 
Windows o dată pe an pentru PDF-ul vieții de la ANAF.  Dar îs conștient 
de fiecare dată de ce fac asta și ce implică asemenea compromisuri.


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

Re: [rlug] flame de vineri ( ubuntu)

2024-03-23 Thread Dumitru Moldovan via RLUG


On 3/23/24 17:53, Mihai Badici via RLUG wrote:
[…]> Sunt interesat de ubuntu pentru că e important ca o distribuție să 
aibă
un suport comercial în spate ( de la un nivel încolo o firmă vrea să 
știe la cine să sune când are probleme) , modelul economic mi se pare 
viabil și în afară de RedHat nu mai e altcineva disponibil, dar de 
fiecare dată când am încercat să mă apropii de distribuția asta am găsit 
tot felul de "amănunte" care nu mi-au plăcut


SUSE.  Mai îs și europeni sadea, adică d-ai noștri…

și care în cotinuare cred că sunt datorate unor dezvoltatori cu prea 
multă "personalitate".  Cam asta era discuția din punctul meu de vedere. 
Ce a ieșit... hai să zicem că a ieșit "ca pe vremuri", asta am căutat 
asta am primit :)


;-]


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

Re: [rlug] flame de vineri ( ubuntu)

2024-03-23 Thread Mihai Badici via RLUG


Merci pentru încercarea de a mă trage de mânecă.

Singurul motiv pentru care am continuat discuția a fost pentru că deja 
apăream prea lame că rulam apt-get update pe containere. Nu , n-am făcut 
asta. :)


Restul au fost niște decizii care atunci mi s-au părut bune, nici acum 
nu consider că erau greșite doar că evident puteam să iau altele mai 
bune, ca în orice situație în care privești în 2024 lucruri pe care 
le-ai făcut în 2014-2016 .


Poate o să mai revin asupra discuției deși nu cred.

Greșeala mea e că am adus în discuție niște exemple prea concrete într-o 
discuție care trebuia să fie destul de abstractă. Docker era un exemplu 
destul de evident în care aveam nevoie de un init simplu și nu îl mai 
aveam la dispoziție. Nu vreau să fie "ca înainte" , mai ales că am prins 
vremurile de dinainte și sigur nu era mai bine :)


Mie mi s-a părut bun ca exemplu dar nu mă așteptam ca discuția să ajungă 
la "de ce ai făcut așa și nu altminteri" pentru că nu despre asta era 
vorba.


Sunt interesat de ubuntu pentru că e important ca o distribuție să aibă 
un suport comercial în spate ( de la un nivel încolo o firmă vrea să 
știe la cine să sune când are probleme) , modelul economic mi se pare 
viabil și în afară de RedHat nu mai e altcineva disponibil, dar de 
fiecare dată când am încercat să mă apropii de distribuția asta am găsit 
tot felul de "amănunte" care nu mi-au plăcut


și care în cotinuare cred că sunt datorate unor dezvoltatori cu prea 
multă "personalitate".  Cam asta era discuția din punctul meu de vedere. 
Ce a ieșit... hai să zicem că a ieșit "ca pe vremuri", asta am căutat 
asta am primit :)


On 3/23/24 09:24, Dumitru Moldovan via RLUG wrote:

Mihai,

Ca de la un „linuxist bătrân” la altul, ca să citez un clasic al 
acestei liste de discuții…  Petru a încercat în mod repetat, cu o 
răbdare pe care io personal nu o mai am, să te ajute să înțelegi unde 
greșești.  Cu cât se dezvoltă discuția însă, cu atât ne dezvălui mai 
multe niveluri unde se întâmplă aceste greșeli.


Acuma mno, toți avem un ego care ne orbește și ne împiedică să ne 
vedem propriile limitări.  Dar, vorba aia, până la urmă ce vrem să 
ajungem la vârsta a treia?  Niște moșnegi oțetiți de propriile 
frustrări, pe care nici măcar nu le prea înțelegem?  Sau, precum un 
vin de calitate, ceva încă recomandabil?


Dacă duci dorul vechii configurări de rețea din Slackware, îți 
recomand OpenBSD, care a dus această simplificare până la concluzia ei 
logică, o soluție elegantă ce unifică inclusiv configurările de rețea 
fără fir. Însă de vrem să supraviețuim dpdv comercial în actualul 
context, trebuie să înțelegem care-i treaba cu Docker, de exemplu.  
Abia apoi ne putem avânta în lamentări mai la obiect privind „the old 
ways”…


On 3/23/24 07:28, Mihai Badici via RLUG wrote:

Neața :)

Da, cumva ne apropiem, după cum ziceam vorbim de un proiect de prin 
2014-16 deci nu îmi mai amintesc nici eu bine.


Tu folosești nginx:latest care la rândul lui e și el derivat din ceva 
( nu de către tine, de către alții, dar e) . Dacă te uiți la ce am 
dat eu, imaginile mele erau derivate dintr-o imagine de wheezy.


Acum poate oi fi greșit eu la acel moment, fiecare imagine era cu 
From: debian/wheezy și apt-install  aplicația mea. Aș fi putut 
probabil să le iau direct cu from: nginx:latest și să ignor că unul 
din containere ar putea fi bazat pe debian și altul pe alpine; eu așa 
m-am gândit, că e mai bine ca toate imaginile să aibă aceeași bază și 
pentru că debian foloseam atunci, să fie debian.


Cum docker e bazat pe layere succesive m-am gândit că așa e cel mai 
economic și mai ușor de întreținut.


Sigur că tu dacă o iei din nginx:latest pasezi problema la altul, 
ceea ce e bine pentru tine dar nu schimbă lucrurile. Și nginx:latest 
e probabil derivat tot din bookworm:latest, doar că nu de tine, și 
după from probabil tot apt-get install nginx are (eu am refuzat moda 
de a compila aplicația în Dockerfile, deși venind dinsprte slackware 
s-ar zice că e contraintuitiv :) )


Mă rog, nu are importanță, era doar o problemă de demult pe care am 
adus-o în discuție ca să ilustrez o tendință.


Aparent, proiectele de it sunt doar de două feluri: alea 
subfinanțate, unde se improvizează ca să meargă, și alea 
suprafinanțate, în care oamenii trebuie să își justifice salariul și 
adaugă layere succesive de complexitate la problemele simple. Cale de 
mijloc nu mai e :)



On 3/23/24 00:23, Petru Rațiu via RLUG wrote:
On Sat, Mar 23, 2024 at 12:09 AM Mihai Badici via RLUG 


wrote:


Tu o ții pe a ta și ai tras niște concluzii greșite.

Eu builduiam o imagine locală - de exemplu porneam de la un build de
nginx , îi aplicam ceva scripturi de customizare și obțineam o imagine
locală, să zicem nginx-mihai.

Pe aia încercam să o țin upgradată și toate containerele le derivam 
din

ea. Până aici cred că ești de acord. În felul ăsta nici nu descărcam
decât o dată, nu că ar mai conta.

Într-adevăr nu îți trebuie systemd în container. Dar pe debian toate

Re: [rlug] flame de vineri ( ubuntu)

2024-03-23 Thread Dumitru Moldovan via RLUG

Mihai,

Ca de la un „linuxist bătrân” la altul, ca să citez un clasic al acestei
liste de discuții… Petru a încercat în mod repetat, cu o răbdare pe
care io personal nu o mai am, să te ajute să înțelegi unde greșești. Cu
cât se dezvoltă discuția însă, cu atât ne dezvălui mai multe niveluri
unde se întâmplă aceste greșeli.

Acuma mno, toți avem un ego care ne orbește și ne împiedică să ne vedem
propriile limitări. Dar, vorba aia, până la urmă ce vrem să ajungem la
vârsta a treia? Niște moșnegi oțetiți de propriile frustrări, pe care
nici măcar nu le prea înțelegem? Sau, precum un vin de calitate, ceva
încă recomandabil?

Dacă duci dorul vechii configurări de rețea din Slackware, îți recomand
OpenBSD, care a dus această simplificare până la concluzia ei logică, o
soluție elegantă ce unifică inclusiv configurările de rețea fără fir.
Însă de vrem să supraviețuim dpdv comercial în actualul context, trebuie
să înțelegem care-i treaba cu Docker, de exemplu. Abia apoi ne putem
avânta în lamentări mai la obiect privind „the old ways”…

On 3/23/24 07:28, Mihai Badici via RLUG wrote:

Neața :)

Da, cumva ne apropiem, după cum ziceam vorbim de un proiect de prin
2014-16 deci nu îmi mai amintesc nici eu bine.

Tu folosești nginx:latest care la rândul lui e și el derivat din ceva (
nu de către tine, de către alții, dar e) . Dacă te uiți la ce am dat eu,
imaginile mele erau derivate dintr-o imagine de wheezy.

Acum poate oi fi greșit eu la acel moment, fiecare imagine era cu From:
debian/wheezy și apt-install aplicația mea. Aș fi putut probabil să le
iau direct cu from: nginx:latest și să ignor că unul din containere ar
putea fi bazat pe debian și altul pe alpine; eu așa m-am gândit, că e
mai bine ca toate imaginile să aibă aceeași bază și pentru că debian
foloseam atunci, să fie debian.

Cum docker e bazat pe layere succesive m-am gândit că așa e cel mai
economic și mai ușor de întreținut.

Sigur că tu dacă o iei din nginx:latest pasezi problema la altul, ceea
ce e bine pentru tine dar nu schimbă lucrurile. Și nginx:latest e
probabil derivat tot din bookworm:latest, doar că nu de tine, și după
from probabil tot apt-get install nginx are (eu am refuzat moda de a
compila aplicația în Dockerfile, deși venind dinsprte slackware s-ar
zice că e contraintuitiv :) )

Mă rog, nu are importanță, era doar o problemă de demult pe care am
adus-o în discuție ca să ilustrez o tendință.

Aparent, proiectele de it sunt doar de două feluri: alea subfinanțate,
unde se improvizează ca să meargă, și alea suprafinanțate, în care
oamenii trebuie să își justifice salariul și adaugă layere succesive de
complexitate la problemele simple. Cale de mijloc nu mai e :)

On 3/23/24 00:23, Petru Rațiu via RLUG wrote:
On Sat, Mar 23, 2024 at 12:09 AM Mihai Badici via RLUG

wrote:

Tu o ții pe a ta și ai tras niște concluzii greșite.

Eu builduiam o imagine locală - de exemplu porneam de la un build de
nginx , îi aplicam ceva scripturi de customizare și obțineam o imagine
locală, să zicem nginx-mihai.

Pe aia încercam să o țin upgradată și toate containerele le derivam din
ea. Până aici cred că ești de acord. În felul ăsta nici nu descărcam
decât o dată, nu că ar mai conta.

Într-adevăr nu îți trebuie systemd în container. Dar pe debian toate
serviciile, inclusiv nginx depindeau de systemd. Deci dacă vrei să
instalezi un jessie sau mai nou oricum trebuie să instalezi și systemd.

Vezi, aici m-ai pierdut. Pentru ca daca vrei nginx, folosesti
nginx:latest

sau whatever. Care poate avea intern debian sau nu (default are, dar nu
prea conteaza), dar nu depinde in nici un fel de systemd (daca imi arati
unde scrie systemd la
https://github.com/nginxinc/docker-nginx/blob/1f227619c1f1baa0bed8bed844ea614437ff14fb/mainline/debian/Dockerfile
. il mananc).

Faptul ca o tot dai cu pachetele din Debian si dependinta lor de systemd
imi spune ca ai incercat sa pui full distro in container, si sigur-sigur
faci ceva foarte in raspar daca ajungi sa faci de-astea.

Aia cu "imaginea aia incercam sa o tin upgradata" e semn ca faceai
ceva gen
golden image de VM, si efectiv la containere nu vrei sa faci asta
decat in

anumite situatii foarte particulare. Daca vrei sa ai containere
maintainable, vrei sa tii un layer cat mai subtire de customizare pe
imagini facute de upstream (preferabil chiar de catre maintainerii
softurilor respective) si sa faci periodic rebuild cu acelasi
scripturi ale

tale bazate pe latest security updates.

Si ma rog, treaba ta, faci ce vrei, dar nu veni sa bombani ca ale naibii
iphoanele astea noi, bati doua cuie cu ele si trebuie schimbate.

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

Re: [rlug] flame de vineri ( ubuntu)


Also, hate-ul cu alpine nu se refera la busybox (appleturile alea din
busybox sunt relativ usor de invatat ce limitari au si la o adica poti pune
binarele care iti trebuie), ci la faptul ca libc-ul folosit nu e glibc sau
eglibc, ci musl, o implementare mult mai light. Care merge suficient de
bine pana dai cu capul de chestii lipsa (sau de binare "pentru linux" care
au fost linkate cu glibc).

Parcă pe vremuri astea bazate pe bizibox veneau de obicei cu uclibc, că 
m-am încurcat și eu de asta la un alt proiect. Dar containerele mele 
erau relativ standard, la ele nu am avut probleme.

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

Re: [rlug] flame de vineri ( ubuntu)

Neața :)

Da, cumva ne apropiem, după cum ziceam vorbim de un proiect de prin
2014-16 deci nu îmi mai amintesc nici eu bine.

Cum docker e bazat pe layere succesive m-am gândit că așa e cel mai
economic și mai ușor de întreținut.

Mă rog, nu are importanță, era doar o problemă de demult pe care am
adus-o în discuție ca să ilustrez o tendință.

On 3/23/24 00:23, Petru Rațiu via RLUG wrote:

On Sat, Mar 23, 2024 at 12:09 AM Mihai Badici via RLUG
wrote:

Tu o ții pe a ta și ai tras niște concluzii greșite.

Eu builduiam o imagine locală - de exemplu porneam de la un build de
nginx , îi aplicam ceva scripturi de customizare și obțineam o imagine
locală, să zicem nginx-mihai.

Pe aia încercam să o țin upgradată și toate containerele le derivam din
ea. Până aici cred că ești de acord. În felul ăsta nici nu descărcam
decât o dată, nu că ar mai conta.

Vezi, aici m-ai pierdut. Pentru ca daca vrei nginx, folosesti nginx:latest
sau whatever. Care poate avea intern debian sau nu (default are, dar nu
prea conteaza), dar nu depinde in nici un fel de systemd (daca imi arati
unde scrie systemd la
https://github.com/nginxinc/docker-nginx/blob/1f227619c1f1baa0bed8bed844ea614437ff14fb/mainline/debian/Dockerfile
. il mananc).

Aia cu "imaginea aia incercam sa o tin upgradata" e semn ca faceai ceva gen
golden image de VM, si efectiv la containere nu vrei sa faci asta decat in
anumite situatii foarte particulare. Daca vrei sa ai containere
maintainable, vrei sa tii un layer cat mai subtire de customizare pe
imagini facute de upstream (preferabil chiar de catre maintainerii
softurilor respective) si sa faci periodic rebuild cu acelasi scripturi ale
tale bazate pe latest security updates.

Si ma rog, treaba ta, faci ce vrei, dar nu veni sa bombani ca ale naibii
iphoanele astea noi, bati doua cuie cu ele si trebuie schimbate.

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

Re: [rlug] flame de vineri ( ubuntu)

On Sat, Mar 23, 2024 at 12:09 AM Mihai Badici via RLUG 
wrote:

> Tu o ții pe a ta și ai tras niște concluzii greșite.
>
> Eu builduiam o imagine locală - de exemplu porneam de la un build de
> nginx , îi aplicam ceva scripturi de customizare și obțineam o imagine
> locală, să zicem nginx-mihai.
>
> Pe aia încercam să o țin upgradată și toate containerele le derivam din
> ea. Până aici cred că ești de acord. În felul ăsta nici nu descărcam
> decât o dată, nu că ar mai conta.
>
> Într-adevăr nu îți trebuie systemd în container. Dar pe debian toate
> serviciile, inclusiv nginx depindeau de systemd. Deci dacă vrei să
> instalezi un jessie sau mai nou oricum trebuie să instalezi și systemd.
>
>
Vezi, aici m-ai pierdut. Pentru ca daca vrei nginx, folosesti nginx:latest
sau whatever. Care poate avea intern debian sau nu (default are, dar nu
prea conteaza), dar nu depinde in nici un fel de systemd (daca imi arati
unde scrie systemd la
https://github.com/nginxinc/docker-nginx/blob/1f227619c1f1baa0bed8bed844ea614437ff14fb/mainline/debian/Dockerfile
. il mananc).

Faptul ca o tot dai cu pachetele din Debian si dependinta lor de systemd
imi spune ca ai incercat sa pui full distro in container, si sigur-sigur
faci ceva foarte in raspar daca ajungi sa faci de-astea.

Aia cu "imaginea aia incercam sa o tin upgradata" e semn ca faceai ceva gen
golden image de VM, si efectiv la containere nu vrei sa faci asta decat in
anumite situatii foarte particulare. Daca vrei sa ai containere
maintainable, vrei sa tii un layer cat mai subtire de customizare pe
imagini facute de upstream (preferabil chiar de catre maintainerii
softurilor respective) si sa faci periodic rebuild cu acelasi scripturi ale
tale bazate pe latest security updates.

Si ma rog, treaba ta, faci ce vrei, dar nu veni sa bombani ca ale naibii
iphoanele astea noi, bati doua cuie cu ele si trebuie schimbate.

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

Re: [rlug] flame de vineri ( ubuntu)


Tu o ții pe a ta și ai tras niște concluzii greșite.

Eu builduiam o imagine locală - de exemplu porneam de la un build de 
nginx , îi aplicam ceva scripturi de customizare și obțineam o imagine 
locală, să zicem nginx-mihai.


Pe aia încercam să o țin upgradată și toate containerele le derivam din 
ea. Până aici cred că ești de acord. În felul ăsta nici nu descărcam 
decât o dată, nu că ar mai conta.


Într-adevăr nu îți trebuie systemd în container. Dar pe debian toate 
serviciile, inclusiv nginx depindeau de systemd. Deci dacă vrei să 
instalezi un jessie sau mai nou oricum trebuie să instalezi și systemd.


Acum ce e drept că în principiu poți să îl instalezi dar să nu îl 
pornești, că tu oricum  nu rulezi decât acel exec. Nu mai știu care era 
problema atunci, poate o fi fost un  blocaj al meu, n-are rost să 
despicăm firul în patru.


Asta cu rulat php, mysql în același container nu știu de unde ai scos-o. 
docker e un container- un serviciu, am containere de toate versiunile de 
php, de node, de redis și tot ce mai trebuia. Doar că la trecerea de la 
wheezy la jessie am avut acest blocaj,  nu mai țin minte, hai să zicem 
că a fost blocajul meu mental ca să o închidem.


Cert e că au fost diverse discuții pe tema asta la acel moment și tot 
atunci alpine a devenit popular, tocmai pentru că era mai "primitiv". 
Practic un container docker nu are nevoie de un init prea complex, 
trebuie doar să seteze ip-ul și să pornească un script ( mă rog, ar mai 
fi câteva dar simplificat vorbind). Ori, noi avem unul foarte complex . 
Uite, acum mă uit pe computerul meu, acum nginx nu mai depinde de 
systemd ( apache : Pre-Depends: init-system-helpers (>= 1.54~)


) deci asta a fost soluția în final . Ok, m-am lămurit, vorbim de epoci 
diferite. Atunci am încercat în fel și chip să scap de el, se pare că 
s-a rezolvat ulterior.




Uite aici câte containere aveam, de unde ai scos-o că rulam mai multe 
servicii pe unul? Păi așa puneam cpanel  :)


ls docker-project/
create-django-stack  create-php-once  docker-dovecot  docker-node 
docker-php56-40-fpm  docker-php7.4-fpm docker-puppeteer 
 docker-slapd  lemp.yml   oracle-mysql  templates
create-lemp  create-redmine   docker-dynamo 
  docker-node-alpine  docker-php7.2-fpm    docker-php7-fpm 
  docker-python2    lemp-54.yml   newdb.sql  README.txt
create-node  django.yml   docker-nginx-naxsi 
 docker-php54-fpm    docker-php7.3-fpm    docker-php7-libkolab 
 docker-redis  lemp-56.yml   node.yml   sites



În fine, discuția chiar că a divagat, dar ce să fac, ai tras niște 
concluzii care nu mă avantajează și trebuie să te contrazic- măcar 
pentru că sunt false :)


Ceea ce voiam să spun e că în zilele noastre sunt situații în care ai 
nevoie de scripturi cât mai simple, docker de pildă, iar distribuțiile 
merg spre soluții din ce în ce mai complicate.


CentOS de pildă (presupun că e la fel și la RedHat) are totuși un sistem 
destul de spartan; alpine e de-a dreptul primitiv; debian am impresia că 
încearcă să împace și capra și varza, dar cumva ubuntu (și nu e prima 
dată când îmi dă impresia asta) mi se pare că s-a dus undeva de unde nu 
mai poți să faci lucrurile simple și nu văd nici un folos.  Dacă tu vezi 
un folos... please, dar mâine, că sunt moș și mă culc :)



On 3/22/24 22:48, Petru Rațiu via RLUG wrote:

Upgrade-ul se face facand rebuild de la un tag mai nou (si probabil vrei
unul batut in cuie ca sa nu se schimbe la fiecare build decat daca tii
neaparat).

Also, nu-ti trebuie systemd in container decat daca ai explicit nevoie de
systemd (pentru naiba stie ce voodoo). Ca sa rulezi nginx (sau apache sau
whatever), setezi ca entrypoint binarul de nginx cu ce parametri vrei, si
ruleaza doar el in "chrootul" ala. Mai flexibil de atat, se practica sa ai
ca entrypoint un script care face alte chestii la runtime (poate hookuri
sau ceva) si la sfarsit face exec nginx. Vrei exec la final de entrypoint
ca sa mufeze corect stdout/stderr si semnalele cu docker sau ce alt runtime
folosesti. Sau mai bine de atat, folosesti direct din upstream imaginea de
nginx sau apache sau mariadb care expune fix ce are nevoie (si eventual o
forkuiesti tu local daca vrei un modul in plus sau ceva).

Daca din ceva masochism vrei sa ai mai multe procese in acelasi container,
se mai practica sa rulezi ca top-level process altceva gandit pentru asta
(am vazut ca tini e foarte popular, in medii mai phpiste am vazut ca se
practica supervisord), dar trebuie tinut cont de cum se trateaza semnalele
si cum obtii logurile (probabil prin fisiere puse intr-un volum extern).
Aproape niciodata nu vrei sa intri in el sa dai apt upgrade, decat poate
pentru teste.

Patternul cu "facem un container cu apache si php si mysql in el" e gresit
(unless vrei un mediu de development fara prea multe zorzoane), normal e sa
ai un container cu apache, unul cu php, unul cu mysql, sa le poti intretine
separat. Altfel mai bine faci un vm si-l tratezi batraneste.

Tot ecos

Re: [rlug] flame de vineri ( ubuntu)

Upgrade-ul se face facand rebuild de la un tag mai nou (si probabil vrei
unul batut in cuie ca sa nu se schimbe la fiecare build decat daca tii
neaparat).

Also, nu-ti trebuie systemd in container decat daca ai explicit nevoie de
systemd (pentru naiba stie ce voodoo). Ca sa rulezi nginx (sau apache sau
whatever), setezi ca entrypoint binarul de nginx cu ce parametri vrei, si
ruleaza doar el in "chrootul" ala. Mai flexibil de atat, se practica sa ai
ca entrypoint un script care face alte chestii la runtime (poate hookuri
sau ceva) si la sfarsit face exec nginx. Vrei exec la final de entrypoint
ca sa mufeze corect stdout/stderr si semnalele cu docker sau ce alt runtime
folosesti. Sau mai bine de atat, folosesti direct din upstream imaginea de
nginx sau apache sau mariadb care expune fix ce are nevoie (si eventual o
forkuiesti tu local daca vrei un modul in plus sau ceva).

Daca din ceva masochism vrei sa ai mai multe procese in acelasi container,
se mai practica sa rulezi ca top-level process altceva gandit pentru asta
(am vazut ca tini e foarte popular, in medii mai phpiste am vazut ca se
practica supervisord), dar trebuie tinut cont de cum se trateaza semnalele
si cum obtii logurile (probabil prin fisiere puse intr-un volum extern).
Aproape niciodata nu vrei sa intri in el sa dai apt upgrade, decat poate
pentru teste.

Patternul cu "facem un container cu apache si php si mysql in el" e gresit
(unless vrei un mediu de development fara prea multe zorzoane), normal e sa
ai un container cu apache, unul cu php, unul cu mysql, sa le poti intretine
separat. Altfel mai bine faci un vm si-l tratezi batraneste.

Tot ecosistemul cu containere pleaca de la conceptul de immutable
infrastructure, pornesti imagini "pe curat" de fiecare data si stii ca
orice modificari pe ele tin pana la urmatorul restart. Vrei update-uri
explicite, faci altele. Asta ajuta sa nu-ti bati capul daca a plecat pe
acelasi server sau are acelasi ip samd samd. Discutabil daca se justifica
cand de fapt ai un server, dar daca inoti impotriva curentului nu-i de
mirare ca esti tras periodic la fund.

Also, hate-ul cu alpine nu se refera la busybox (appleturile alea din
busybox sunt relativ usor de invatat ce limitari au si la o adica poti pune
binarele care iti trebuie), ci la faptul ca libc-ul folosit nu e glibc sau
eglibc, ci musl, o implementare mult mai light. Care merge suficient de
bine pana dai cu capul de chestii lipsa (sau de binare "pentru linux" care
au fost linkate cu glibc).

-- 
P.

On Fri, Mar 22, 2024 at 10:26 PM Mihai Badici via RLUG 
wrote:

> Alpine e cu bizibox ca să facă economie de spațiu. De acord că e o
> prostie dar și-a făcut treaba.
>
> Acum că am căutat pentru că m-ai provocat,  systemd pare că a fost
> introdus în jessie deci pe atunci am avut de-a face cu situația asta,
> pentru că wheezy era deja oldstable și nu voiam să mai lucrez cu el
>
> Nu aș fi schimbat nici distribuția că preferam să lucrez cu ceva ce
> știam. Și evident ca nu intram pe containere să dau update, asta a fost
> presupunerea ta, ca să mărești flame-ul , eu am zis doar că nu le puteam
> upgrada :)
>
> Ăsta primul e de la început, 2016 - cel din 2022  e cu alpine, dar n-am
> prea mai lucrat la el, da fost doar o actualizare...
>
> drwxr-xr-x  10 mihai mihai 4.0K Oct 13  2016  docker-local
> -rw-r--r--   1 mihai mihai  27K Jun 15  2018  docker-php5-fpm.zip
> drwxr-xr-x  22 mihai mihai 4.0K Dec  7  2022  docker-project
>
>
> cat docker-mariadb/Dockerfile
> FROM debian:wheezy
>
>
> On 3/22/24 22:08, Petru Rațiu via RLUG wrote:
> > Serious, io rulez nginx (si altele) in productie in containere de ani de
> > zile si nu m-am lovit de problema asta cu systemd. I guess ca se poate
> daca
> > tii neaparat, dar n-a fost nevoie. Ah si tin up-to-date (cat de cat)
> > imaginile. Desigur, in moduri total diferite de "intru pe toate vm-urile
> si
> > dau apt upgrade", dar asta e.
> >
> > Also, fuck alpine with a chainsaw. Primul an m-am tot dat cu capul de
> > probleme mizerabile doar pentru ca desteptii initiali vrusesera ei sa fie
> > cool si au plecat de la alpine. O avea si el rostul lui, dar am dat de
> > atatea ori cu capul de limitarile libc-ului ala "special" ca am zis ca
> trec
> > totul pe debian si aia e.
> >
> ___
> 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] flame de vineri ( ubuntu)

Alpine e cu bizibox ca să facă economie de spațiu. De acord că e o 
prostie dar și-a făcut treaba.


Acum că am căutat pentru că m-ai provocat,  systemd pare că a fost 
introdus în jessie deci pe atunci am avut de-a face cu situația asta, 
pentru că wheezy era deja oldstable și nu voiam să mai lucrez cu el


Nu aș fi schimbat nici distribuția că preferam să lucrez cu ceva ce 
știam. Și evident ca nu intram pe containere să dau update, asta a fost 
presupunerea ta, ca să mărești flame-ul , eu am zis doar că nu le puteam 
upgrada :)


Ăsta primul e de la început, 2016 - cel din 2022  e cu alpine, dar n-am 
prea mai lucrat la el, da fost doar o actualizare...


drwxr-xr-x  10 mihai mihai 4.0K Oct 13  2016  docker-local
-rw-r--r--   1 mihai mihai  27K Jun 15  2018  docker-php5-fpm.zip
drwxr-xr-x  22 mihai mihai 4.0K Dec  7  2022  docker-project


cat docker-mariadb/Dockerfile
FROM debian:wheezy


On 3/22/24 22:08, Petru Rațiu via RLUG wrote:

Serious, io rulez nginx (si altele) in productie in containere de ani de
zile si nu m-am lovit de problema asta cu systemd. I guess ca se poate daca
tii neaparat, dar n-a fost nevoie. Ah si tin up-to-date (cat de cat)
imaginile. Desigur, in moduri total diferite de "intru pe toate vm-urile si
dau apt upgrade", dar asta e.

Also, fuck alpine with a chainsaw. Primul an m-am tot dat cu capul de
probleme mizerabile doar pentru ca desteptii initiali vrusesera ei sa fie
cool si au plecat de la alpine. O avea si el rostul lui, dar am dat de
atatea ori cu capul de limitarile libc-ului ala "special" ca am zis ca trec
totul pe debian si aia e.


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

Re: [rlug] flame de vineri ( ubuntu)

Serious, io rulez nginx (si altele) in productie in containere de ani de
zile si nu m-am lovit de problema asta cu systemd. I guess ca se poate daca
tii neaparat, dar n-a fost nevoie. Ah si tin up-to-date (cat de cat)
imaginile. Desigur, in moduri total diferite de "intru pe toate vm-urile si
dau apt upgrade", dar asta e.

Also, fuck alpine with a chainsaw. Primul an m-am tot dat cu capul de
probleme mizerabile doar pentru ca desteptii initiali vrusesera ei sa fie
cool si au plecat de la alpine. O avea si el rostul lui, dar am dat de
atatea ori cu capul de limitarile libc-ului ala "special" ca am zis ca trec
totul pe debian si aia e.

-- 
P.

On Fri, Mar 22, 2024 at 9:52 PM Mihai Badici via RLUG 
wrote:

> Da, actually era nginx dar nu are nici o importanță ce serviciu e,
> important e că e al doilea.
>
>
> Uite că am dat peste un blog care e din 2019 (cred că eu mă jucam o țâră
> mai devreme, inițial am încercat cu openstack dar ăștia nu suportau
> atunci docker, nu știu ce s-a mai întâmplat, pe urmă am făcut o chestie
> mai custom made, după care ne-am apucat să ne jucăm de-a altceva). Aveam
> pe cineva care ținea morțiș să își mute serviciul de hosting pe docker,
> până la urmă am rezolvat cumva că apăruse moda cu alpine, am renunțat la
> debian. Chiar ajunsese să meargă, doar că între timp respectivul s-a
> apucat de alte chestii și a lăsat-o baltă.
>
>
> https://developers.redhat.com/blog/2019/04/24/how-to-run-systemd-in-a-container
>
> Eu nu am stat să despic firul în patru dar cam asta era discuția, n-am
> inventat-o eu că sunt bătrân și demodat...
>
> Ea a fost rezolvată în principal pentru că majoritatea utilizatorilor au
> trecut pe alpine la momentul ăsta. Acum n-am mai urmărit că nu am nici
> un proiect serios pe docker, bănuiesc că au găsit niște căi de "mitigare".
>
>
>
> On 3/22/24 21:38, Petru Rațiu via RLUG wrote:
> > Asa e cand folosesti tehnologii de-astea super experimentale, sunt
> convins
> > ca esti printre putinii de pe planeta care are nevoie de apache in
> docker.
> >
> > Tu de fapt ai alta problema dar te-ai tot dus pe firul presupunerilor
> > undeva in imposibil. Dar cum ziceam, s-a cam terminat vinerea, se raceste
> > flama. Poate facem clubul ala al pensionarilor si vorbim acolo.
> >
> > On Fri, Mar 22, 2024 at 9:33 PM Mihai Badici via RLUG  >
> > wrote:
> >
> >> Păi da, așa se face. Tu pui "from" și el îți descarcă imaginea de la
> >> versiunea respectivă. Însă nu exista această imagine pentru că nu se
> >> rezolvase problema cu systemd. Chestia asta a durat cel puțin un an și
> >> probabil că mai găsești urme pe net dacă o să cauți.
> >>
> >> Alternativ dacă nu exista puteai să o faci tu, dar erai fix în aceeași
> >> situație.
> >>
> >> On 3/22/24 21:28, Petru Rațiu via RLUG wrote:
> >>> La docker ideea normala e ca faci mereu build din dockerfile, poti
> >> schimba
> >>> statementul de FROM sa porneasca de la ce base image vrei tu (si ofc sa
> >>> validezi ca ce urmeaza in pasii urmatori mai are sens).
> >>>
> >>> Jur ca ma gandesc sa fac cursuri de recalificare pt linuxistii batrani
> >> unde
> >>> 70% din timp il vom petrece cu "cum sa citim documentatia fara sa facem
> >>> skip la exemple" si 25% cu "hai sa ne uitam pe github pe la altii si
> prin
> >>> surse sa intelegem cum functioneaza de fapt, nu prin flyerele de la
> >> salesi".
> >> ___
> >> 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
>
> ___
> 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] flame de vineri ( ubuntu)

Da, actually era nginx dar nu are nici o importanță ce serviciu e, 
important e că e al doilea.



Uite că am dat peste un blog care e din 2019 (cred că eu mă jucam o țâră 
mai devreme, inițial am încercat cu openstack dar ăștia nu suportau 
atunci docker, nu știu ce s-a mai întâmplat, pe urmă am făcut o chestie 
mai custom made, după care ne-am apucat să ne jucăm de-a altceva). Aveam 
pe cineva care ținea morțiș să își mute serviciul de hosting pe docker, 
până la urmă am rezolvat cumva că apăruse moda cu alpine, am renunțat la 
debian. Chiar ajunsese să meargă, doar că între timp respectivul s-a 
apucat de alte chestii și a lăsat-o baltă.


https://developers.redhat.com/blog/2019/04/24/how-to-run-systemd-in-a-container

Eu nu am stat să despic firul în patru dar cam asta era discuția, n-am 
inventat-o eu că sunt bătrân și demodat...


Ea a fost rezolvată în principal pentru că majoritatea utilizatorilor au 
trecut pe alpine la momentul ăsta. Acum n-am mai urmărit că nu am nici 
un proiect serios pe docker, bănuiesc că au găsit niște căi de "mitigare".




On 3/22/24 21:38, Petru Rațiu via RLUG wrote:

Asa e cand folosesti tehnologii de-astea super experimentale, sunt convins
ca esti printre putinii de pe planeta care are nevoie de apache in docker.

Tu de fapt ai alta problema dar te-ai tot dus pe firul presupunerilor
undeva in imposibil. Dar cum ziceam, s-a cam terminat vinerea, se raceste
flama. Poate facem clubul ala al pensionarilor si vorbim acolo.

On Fri, Mar 22, 2024 at 9:33 PM Mihai Badici via RLUG 
wrote:


Păi da, așa se face. Tu pui "from" și el îți descarcă imaginea de la
versiunea respectivă. Însă nu exista această imagine pentru că nu se
rezolvase problema cu systemd. Chestia asta a durat cel puțin un an și
probabil că mai găsești urme pe net dacă o să cauți.

Alternativ dacă nu exista puteai să o faci tu, dar erai fix în aceeași
situație.

On 3/22/24 21:28, Petru Rațiu via RLUG wrote:

La docker ideea normala e ca faci mereu build din dockerfile, poti

schimba

statementul de FROM sa porneasca de la ce base image vrei tu (si ofc sa
validezi ca ce urmeaza in pasii urmatori mai are sens).

Jur ca ma gandesc sa fac cursuri de recalificare pt linuxistii batrani

unde

70% din timp il vom petrece cu "cum sa citim documentatia fara sa facem
skip la exemple" si 25% cu "hai sa ne uitam pe github pe la altii si prin
surse sa intelegem cum functioneaza de fapt, nu prin flyerele de la

salesi".
___
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


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

Re: [rlug] flame de vineri ( ubuntu)

Asa e cand folosesti tehnologii de-astea super experimentale, sunt convins
ca esti printre putinii de pe planeta care are nevoie de apache in docker.

Tu de fapt ai alta problema dar te-ai tot dus pe firul presupunerilor
undeva in imposibil. Dar cum ziceam, s-a cam terminat vinerea, se raceste
flama. Poate facem clubul ala al pensionarilor si vorbim acolo.

On Fri, Mar 22, 2024 at 9:33 PM Mihai Badici via RLUG 
wrote:

> Păi da, așa se face. Tu pui "from" și el îți descarcă imaginea de la
> versiunea respectivă. Însă nu exista această imagine pentru că nu se
> rezolvase problema cu systemd. Chestia asta a durat cel puțin un an și
> probabil că mai găsești urme pe net dacă o să cauți.
>
> Alternativ dacă nu exista puteai să o faci tu, dar erai fix în aceeași
> situație.
>
> On 3/22/24 21:28, Petru Rațiu via RLUG wrote:
> > La docker ideea normala e ca faci mereu build din dockerfile, poti
> schimba
> > statementul de FROM sa porneasca de la ce base image vrei tu (si ofc sa
> > validezi ca ce urmeaza in pasii urmatori mai are sens).
> >
> > Jur ca ma gandesc sa fac cursuri de recalificare pt linuxistii batrani
> unde
> > 70% din timp il vom petrece cu "cum sa citim documentatia fara sa facem
> > skip la exemple" si 25% cu "hai sa ne uitam pe github pe la altii si prin
> > surse sa intelegem cum functioneaza de fapt, nu prin flyerele de la
> salesi".
> >
>
> ___
> 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] flame de vineri ( ubuntu)

Vai ce trist, am citit acum, vad ca raspunsul oficial e "de fapt nu era
suportat nici inainte".

Initial am vrut sa raspund la misto, ca tot e flama, dar acu serios
vorbind,
http://ftp.lug.ro/debian/dists/stable/main/installer-amd64/current/images/netboot/

:D

-- 
P.

On Fri, Mar 22, 2024 at 9:22 PM Bogdan-Stefan Rotariu via RLUG <
rlug@lists.lug.ro> wrote:

> Avand in vedere ca suntem in toiul entuziasmului de vineri, poate reusim
> sa scoatem ceva constructiv.
>
> Pana de curand, era relativ simplu pxeboot si preseed pentru bubuntu, insa
> de la incepand cu 22.04 (ultimul functional a fost 20.04) au ucis legacy
> installers si implicit a disparut si imaginea de netboot,
> https://discourse.ubuntu.com/t/server-installer-plans-for-20-04-lts/13631
>
> Acum folosesc ceva de genul, evident, fara preseed:
>
>   kernel http://192.168.1.1/ubuntu/22/vmlinuz
>   initrd http://192.168.1.1/ubuntu/22/initrd
>   append ip=dhcp cloud-config-url=/dev/null url=
> http://mirrors.chroot.ro/ubuntu-releases/22.04.1/ubuntu-22.04.1-live-server-amd64.iso
> autoinstall ds=nocloud-net;s=http://192.168.1.1/ubuntu/22/
>
> Sunt curios ce solutie aveti/vedeti voi care sa nu includa load la .iso,
> fie el si pe http, tot lent este.
>
> --
> Bogdan-Stefan Rotariu
> bog...@rotariu.ro
>
>
>
>
> > On 22 Mar 2024, at 21:07, Petru Rațiu via RLUG 
> wrote:
> >
> > Voiam sa-ti raspund punctual la cele cateva prostii pe care le-ai spus,
> dar
> > mi-am dat seama ca toate se rezuma la "daca n-ai presupune ca esti
> destept
> > si le stii deja pe toate pentru ca faci astea de hat-hat, ai putea vedea
> > din documentatie (care exista!) ca lucrurile nu-s asa complicate".
> >
> > Seara faina, programul de flama s-a terminat,
> >
> > --
> > P.
> >
> > On Fri, Mar 22, 2024 at 8:56 PM Mihai Badici via RLUG  >
> > wrote:
> >
> >> Netplan a fost dat afară pentru că s-au gândit ei că dacă am dezinstalat
> >> python nu îmi mai trebuie nici netplan.
> >>
> >> Problema e că aparent netplan e sistemul default de configurare network
> >> în ubuntu, cel puțin asta înțeleg ( btw, de când ubuntu a ajuns noul
> >> windows e aproape imposibil să mai găsești o documentație ca lumea
> >> pentru că numărul de kizi a înecat în zgomot orice informație utilă. By
> >> default aleg răspunsurile care nu conțin "ub)untu")
> >>
> >> Și sigur că ai dreptate, mi-am permis o atitudine mai laxă pentru că era
> >> un vps nou, nu aveam aplicații în producție (adică nu aveam deloc) și
> >> aveam și VNC. Dar încă o dată, nu despre asta vorbeam. Sigur că
> >> providerul chiar îmi dădea dhcp, dar cu ce script de inițializare
> >> trebuia să primesc eu dhcp-ul ăla?  Eu în general prefer căile simple,
> >> în general să lași setările așa cum erau pare suficient de sigur.
> >>
> >> Acu' știu, când începi să zici că "pe vremea noastră... " sigur e semn
> >> de bătrânețe  și probabil că nici nu e adevărat, pentru că acum
> >> sistemele merg mai bine decât atunci (chiar merg) . Dar chiar mi se pare
> >> că unele lucruri au început să fie complicate excesiv și fără vreo
> >> utilitate concretă. Evident nu toate, și nu totdeauna, dar uneori chiar
> >> e adevârat.
> >>
> >> Sunt ani de zile de când folosesc debian, că deși în continuare apreciez
> >> simplitatea și curățenia unui sistem ca slackware îmi dau seama și de
> >> slăbiciunile pe care le implică. Debian are niște scripturi de
> >> networking extrem de legacy care însă fac față și nu dau rateuri
> >> niciodată ( a, da, a fost și la ei o bătaie de cap când s-a schimbat
> >> schema de denumire a interfețelor, dar aia era justificată, o schimbare
> >> majoră în kernel). Dacă vrei ceva mai complicat, ai network-manager
> >> (acum ai chiar și în slackware 15.0 , de pildă). Mi se pare o atitudine
> >> sănătoasă și sigură. Un sistem simplu și sigur, dublat de unul mai
> >> complex dacă ai nevoie. Dincoace, la ubuntu, au preferat să meargă
> >> direct pe calea complicată. cloud-init, netplan, python... Evident, ai
> >> și network-manager.  Nici nu îmi e clar dacă a mai rămas vreo variantă
> >> simplă în afară de a-ți scrie tu un script "ca pe vremuri".
> >>
> >> .Și apropo, că am avut niște treburi mai acum ceva ani cu containerele,
> >> la un moment dat vine docker și zice: filozofia mea e "un container, un
> >> proces". Oops. nu pot rula ubuntu sau debian, pentru că am deja un
> >> proces, systemd, și nu îl mai pot porni pe al doilea. Până la urmă au
> >> fușerit-o cumva, dar a fost o perioadă în care nu puteai să upgradezi
> >> containerele vechi, care nu aveau systemd, pentru că alea noi aveau
> >> systemd mandatory. O aberație, care s-a rezolvat prin altă aberație,
> >> când soluția evidentă era să facă systemd default dar opțional (de ce am
> >> nevoie de systemd pe docker?).  Încerc să nu fiu taliban, dar uneori...
> >> :)  Parcă nu mi se mai pare așa de aberant când căutam la windows2008
> >> prin regiștri după plăci de rețea "fantomă" ...
> >>
> >>
> >>
> >>
> >> On 3/22/24 20:00, Petru Rațiu via RLUG wrote:
> >>> Deci sa traduc: vp

Re: [rlug] flame de vineri ( ubuntu)

Păi da, așa se face. Tu pui "from" și el îți descarcă imaginea de la 
versiunea respectivă. Însă nu exista această imagine pentru că nu se 
rezolvase problema cu systemd. Chestia asta a durat cel puțin un an și 
probabil că mai găsești urme pe net dacă o să cauți.


Alternativ dacă nu exista puteai să o faci tu, dar erai fix în aceeași 
situație.


On 3/22/24 21:28, Petru Rațiu via RLUG wrote:

La docker ideea normala e ca faci mereu build din dockerfile, poti schimba
statementul de FROM sa porneasca de la ce base image vrei tu (si ofc sa
validezi ca ce urmeaza in pasii urmatori mai are sens).

Jur ca ma gandesc sa fac cursuri de recalificare pt linuxistii batrani unde
70% din timp il vom petrece cu "cum sa citim documentatia fara sa facem
skip la exemple" si 25% cu "hai sa ne uitam pe github pe la altii si prin
surse sa intelegem cum functioneaza de fapt, nu prin flyerele de la salesi".



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

Re: [rlug] flame de vineri ( ubuntu)


On 22-Mar-24 21:19, Petru Rațiu via RLUG wrote:

Iti traduc eu: am aflat cu stupoare ca e lume care foloseste containerele
ca pe vm-uri, intri in el, modifici chestii, eventual dai docker commit (or
some such) si merge mai departe. Imaginea aia practic nu paraseste serverul
(si nu are backup sau ceva), si te poti lauda ca uite mama, dockere.

Eu am dat cu capul de lumea asta pe "high road", cu construit imagini in
alta parte, impins in repository, tras de acolo pe diverse masini care le
ruleaza, tinut datele locale in volume separate, etc. Dar am dat de oameni
care lucreaza cum am descris mai sus, si mi-e mila de ei (sau nu).


pana la urma nu zic, exista containere lxc (ca tot containere sunt, 
folosesc in principiu aceleasi primitive ca si kubernetzi/dockeri gen 
namespaces/cgroups/etc.), DAR ... dincolo de asta e cu totul alta filosofie


LXC-urile sunt pana la urma niste light VMs, doar kernelul e din host 
(cu bune, cu rele), in rest same shit (doar ca nu poti - cel putin din 
cate stiu, poate o mai fi vreo inovatie - sa faci live migration); deci 
... containere permanente


in schimb docker/k8s si restul de solutii de genul pornesc de la premisa 
ca toate containerele sunt temporare (chit ca poate ruleaza cu 
sapta-lunile fara problema); a crapat unu, ghinion, pornesti altul; daca 
aplicatia nu e in stare sa suporte asta, inseamna ca nu trebuia sa o fi 
containerizat, punct!


bine, pana la urma mai nou poti sa pui si baze de date in containere, 
insa era o vreme cand asa ceva cam insemna sa te joci cu focul, intre 
timp au mai evoluat toate ...


insa sa folosesti containere "temporare" ca si vm-uri ... mi-e si frica 
sa intreb pe unde ... sau de fapt poate ar fi bine sa stiu, ca sa 
ocolesc cat pot; o fi frumos un pic de "cowboy diplomacy", dar nu in 
productie :-P


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

Re: [rlug] flame de vineri ( ubuntu)

La docker ideea normala e ca faci mereu build din dockerfile, poti schimba
statementul de FROM sa porneasca de la ce base image vrei tu (si ofc sa
validezi ca ce urmeaza in pasii urmatori mai are sens).

Jur ca ma gandesc sa fac cursuri de recalificare pt linuxistii batrani unde
70% din timp il vom petrece cu "cum sa citim documentatia fara sa facem
skip la exemple" si 25% cu "hai sa ne uitam pe github pe la altii si prin
surse sa intelegem cum functioneaza de fapt, nu prin flyerele de la salesi".

-- 
P.

On Fri, Mar 22, 2024 at 9:25 PM Mihai Badici via RLUG 
wrote:

> În principiu asta e valid la lxc, unde poți să tratezi containerul ca pe
> o virtuală, și de fapt cam așa e gândit. Docker are o altă filozofie -
> nici nu știu dacă merge ce zici tu, probabil că merge- dar oricum ar fi
> pachetele tot sunt bazate pe o distribuție, indiferent cum ai lucra cu ele.
>
> On 3/22/24 21:19, Petru Rațiu via RLUG wrote:
> > On Fri, Mar 22, 2024 at 9:13 PM Alex 'CAVE' Cernat via RLUG <
> > rlug@lists.lug.ro> wrote:
> >
> >> On 22-Mar-24 20:53, Mihai Badici via RLUG wrote:
> >>> .Și apropo, că am avut niște treburi mai acum ceva ani cu
> >>> containerele, la un moment dat vine docker și zice: filozofia mea e
> >>> "un container, un proces". Oops. nu pot rula ubuntu sau debian, pentru
> >>> că am deja un proces, systemd, și nu îl mai pot porni pe al doilea.
> >>> Până la urmă au fușerit-o cumva, dar a fost o perioadă în care nu
> >>> puteai să upgradezi containerele vechi, care nu aveau systemd, pentru
> >>> că alea noi aveau systemd mandatory. O aberație, care s-a rezolvat
> >>> prin altă aberație, când soluția evidentă era să facă systemd default
> >>> dar opțional (de ce am nevoie de systemd pe docker?).  Încerc să nu
> >>> fiu taliban, dar uneori... 🙂  Parcă nu mi se mai pare așa de aberant
> >>> când căutam la windows2008 prin regiștri după plăci de rețea "fantomă"
> >>> ...
> >> pai stai ... de ce sa upgradezi un container? sau ce sa upgradezi la el?
> >>
> >> pana la urma asta e filosofia containerelor, faci build cu versiunea
> >> noua de pachet(e) si dai deploy (sau cu ceva kubernetzi schimbi imaginea
> >> si reporneste el containerele noi)
> >>
> >> sau poate n-am inteles eu exact ce voiai sa zici, ca deh, vineri seara,
> >> s-a adunat oboseala
> >>
> >>
> > Iti traduc eu: am aflat cu stupoare ca e lume care foloseste containerele
> > ca pe vm-uri, intri in el, modifici chestii, eventual dai docker commit
> (or
> > some such) si merge mai departe. Imaginea aia practic nu paraseste
> serverul
> > (si nu are backup sau ceva), si te poti lauda ca uite mama, dockere.
> >
> > Eu am dat cu capul de lumea asta pe "high road", cu construit imagini in
> > alta parte, impins in repository, tras de acolo pe diverse masini care le
> > ruleaza, tinut datele locale in volume separate, etc. Dar am dat de
> oameni
> > care lucreaza cum am descris mai sus, si mi-e mila de ei (sau nu).
> >
>
> ___
> 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] flame de vineri ( ubuntu)

În principiu asta e valid la lxc, unde poți să tratezi containerul ca pe 
o virtuală, și de fapt cam așa e gândit. Docker are o altă filozofie - 
nici nu știu dacă merge ce zici tu, probabil că merge- dar oricum ar fi 
pachetele tot sunt bazate pe o distribuție, indiferent cum ai lucra cu ele.


On 3/22/24 21:19, Petru Rațiu via RLUG wrote:

On Fri, Mar 22, 2024 at 9:13 PM Alex 'CAVE' Cernat via RLUG <
rlug@lists.lug.ro> wrote:


On 22-Mar-24 20:53, Mihai Badici via RLUG wrote:

.Și apropo, că am avut niște treburi mai acum ceva ani cu
containerele, la un moment dat vine docker și zice: filozofia mea e
"un container, un proces". Oops. nu pot rula ubuntu sau debian, pentru
că am deja un proces, systemd, și nu îl mai pot porni pe al doilea.
Până la urmă au fușerit-o cumva, dar a fost o perioadă în care nu
puteai să upgradezi containerele vechi, care nu aveau systemd, pentru
că alea noi aveau systemd mandatory. O aberație, care s-a rezolvat
prin altă aberație, când soluția evidentă era să facă systemd default
dar opțional (de ce am nevoie de systemd pe docker?).  Încerc să nu
fiu taliban, dar uneori... 🙂  Parcă nu mi se mai pare așa de aberant
când căutam la windows2008 prin regiștri după plăci de rețea "fantomă"
...

pai stai ... de ce sa upgradezi un container? sau ce sa upgradezi la el?

pana la urma asta e filosofia containerelor, faci build cu versiunea
noua de pachet(e) si dai deploy (sau cu ceva kubernetzi schimbi imaginea
si reporneste el containerele noi)

sau poate n-am inteles eu exact ce voiai sa zici, ca deh, vineri seara,
s-a adunat oboseala



Iti traduc eu: am aflat cu stupoare ca e lume care foloseste containerele
ca pe vm-uri, intri in el, modifici chestii, eventual dai docker commit (or
some such) si merge mai departe. Imaginea aia practic nu paraseste serverul
(si nu are backup sau ceva), si te poti lauda ca uite mama, dockere.

Eu am dat cu capul de lumea asta pe "high road", cu construit imagini in
alta parte, impins in repository, tras de acolo pe diverse masini care le
ruleaza, tinut datele locale in volume separate, etc. Dar am dat de oameni
care lucreaza cum am descris mai sus, si mi-e mila de ei (sau nu).



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

Re: [rlug] flame de vineri ( ubuntu)

2024-03-22 Thread Bogdan-Stefan Rotariu via RLUG

Avand in vedere ca suntem in toiul entuziasmului de vineri, poate reusim sa 
scoatem ceva constructiv.

Pana de curand, era relativ simplu pxeboot si preseed pentru bubuntu, insa de 
la incepand cu 22.04 (ultimul functional a fost 20.04) au ucis legacy 
installers si implicit a disparut si imaginea de netboot, 
https://discourse.ubuntu.com/t/server-installer-plans-for-20-04-lts/13631

Acum folosesc ceva de genul, evident, fara preseed:

  kernel http://192.168.1.1/ubuntu/22/vmlinuz
  initrd http://192.168.1.1/ubuntu/22/initrd
  append ip=dhcp cloud-config-url=/dev/null 
url=http://mirrors.chroot.ro/ubuntu-releases/22.04.1/ubuntu-22.04.1-live-server-amd64.iso
 autoinstall ds=nocloud-net;s=http://192.168.1.1/ubuntu/22/

Sunt curios ce solutie aveti/vedeti voi care sa nu includa load la .iso, fie el 
si pe http, tot lent este.

--
Bogdan-Stefan Rotariu
bog...@rotariu.ro




> On 22 Mar 2024, at 21:07, Petru Rațiu via RLUG  wrote:
> 
> Voiam sa-ti raspund punctual la cele cateva prostii pe care le-ai spus, dar
> mi-am dat seama ca toate se rezuma la "daca n-ai presupune ca esti destept
> si le stii deja pe toate pentru ca faci astea de hat-hat, ai putea vedea
> din documentatie (care exista!) ca lucrurile nu-s asa complicate".
> 
> Seara faina, programul de flama s-a terminat,
> 
> -- 
> P.
> 
> On Fri, Mar 22, 2024 at 8:56 PM Mihai Badici via RLUG 
> wrote:
> 
>> Netplan a fost dat afară pentru că s-au gândit ei că dacă am dezinstalat
>> python nu îmi mai trebuie nici netplan.
>> 
>> Problema e că aparent netplan e sistemul default de configurare network
>> în ubuntu, cel puțin asta înțeleg ( btw, de când ubuntu a ajuns noul
>> windows e aproape imposibil să mai găsești o documentație ca lumea
>> pentru că numărul de kizi a înecat în zgomot orice informație utilă. By
>> default aleg răspunsurile care nu conțin "ub)untu")
>> 
>> Și sigur că ai dreptate, mi-am permis o atitudine mai laxă pentru că era
>> un vps nou, nu aveam aplicații în producție (adică nu aveam deloc) și
>> aveam și VNC. Dar încă o dată, nu despre asta vorbeam. Sigur că
>> providerul chiar îmi dădea dhcp, dar cu ce script de inițializare
>> trebuia să primesc eu dhcp-ul ăla?  Eu în general prefer căile simple,
>> în general să lași setările așa cum erau pare suficient de sigur.
>> 
>> Acu' știu, când începi să zici că "pe vremea noastră... " sigur e semn
>> de bătrânețe  și probabil că nici nu e adevărat, pentru că acum
>> sistemele merg mai bine decât atunci (chiar merg) . Dar chiar mi se pare
>> că unele lucruri au început să fie complicate excesiv și fără vreo
>> utilitate concretă. Evident nu toate, și nu totdeauna, dar uneori chiar
>> e adevârat.
>> 
>> Sunt ani de zile de când folosesc debian, că deși în continuare apreciez
>> simplitatea și curățenia unui sistem ca slackware îmi dau seama și de
>> slăbiciunile pe care le implică. Debian are niște scripturi de
>> networking extrem de legacy care însă fac față și nu dau rateuri
>> niciodată ( a, da, a fost și la ei o bătaie de cap când s-a schimbat
>> schema de denumire a interfețelor, dar aia era justificată, o schimbare
>> majoră în kernel). Dacă vrei ceva mai complicat, ai network-manager
>> (acum ai chiar și în slackware 15.0 , de pildă). Mi se pare o atitudine
>> sănătoasă și sigură. Un sistem simplu și sigur, dublat de unul mai
>> complex dacă ai nevoie. Dincoace, la ubuntu, au preferat să meargă
>> direct pe calea complicată. cloud-init, netplan, python... Evident, ai
>> și network-manager.  Nici nu îmi e clar dacă a mai rămas vreo variantă
>> simplă în afară de a-ți scrie tu un script "ca pe vremuri".
>> 
>> .Și apropo, că am avut niște treburi mai acum ceva ani cu containerele,
>> la un moment dat vine docker și zice: filozofia mea e "un container, un
>> proces". Oops. nu pot rula ubuntu sau debian, pentru că am deja un
>> proces, systemd, și nu îl mai pot porni pe al doilea. Până la urmă au
>> fușerit-o cumva, dar a fost o perioadă în care nu puteai să upgradezi
>> containerele vechi, care nu aveau systemd, pentru că alea noi aveau
>> systemd mandatory. O aberație, care s-a rezolvat prin altă aberație,
>> când soluția evidentă era să facă systemd default dar opțional (de ce am
>> nevoie de systemd pe docker?).  Încerc să nu fiu taliban, dar uneori...
>> :)  Parcă nu mi se mai pare așa de aberant când căutam la windows2008
>> prin regiștri după plăci de rețea "fantomă" ...
>> 
>> 
>> 
>> 
>> On 3/22/24 20:00, Petru Rațiu via RLUG wrote:
>>> Deci sa traduc: vps-ul pe care l-ai primit avea dhcp setat cu netplan for
>>> some reason si nu era marcat pachetul ca manually installed sau a fost
>> alt
>>> fuckup pe-acolo. Prin ghidul de dist-upgrade (care, btw, merita citit din
>>> scoarta in scoarta de fiecare data cand nu vrei sa-ti gasesti sistemul pe
>>> branci, oricat de destept esti), cu siguranta zice sa faci review la
>>> pachetele care se instaleaza/dezinstaleaza la fiecare pas, poate sunt
>> unele
>>> de care-ti pasa mai mult decat apt-ului si trebuie sa faci ceva in
>> direct

Re: [rlug] flame de vineri ( ubuntu)

Păi și cu ce pachete faci build la versiunea nouă? Să zicem că ai un 
docker care rulează ceva simplu, un apache. Dockerul ăla e bazat pe, să 
zicem, debian wheezy sau ce mai era pe atunci că nu mai țin minte.


Teoretic tu ai face build la imaginea nouă de debian și după aia deploy 
(ok, asta înțeleg prin upgrade). Dar... nu poți face o imagine nouă că 
imaginea nouă are apache2 dependent de systemd . În practică tu poți să 
pornești câte servicii vrei într-un docker, pentru că nimic nu te 
oprește ca "serviciul" să fie de fapt un script care pornește alte 
servicii, însă asta e doar o cârpeală.


On 3/22/24 21:12, Alex 'CAVE' Cernat via RLUG wrote:

On 22-Mar-24 20:53, Mihai Badici via RLUG wrote:
.Și apropo, că am avut niște treburi mai acum ceva ani cu 
containerele, la un moment dat vine docker și zice: filozofia mea e 
"un container, un proces". Oops. nu pot rula ubuntu sau debian, 
pentru că am deja un proces, systemd, și nu îl mai pot porni pe al 
doilea. Până la urmă au fușerit-o cumva, dar a fost o perioadă în 
care nu puteai să upgradezi containerele vechi, care nu aveau 
systemd, pentru că alea noi aveau systemd mandatory. O aberație, care 
s-a rezolvat prin altă aberație, când soluția evidentă era să facă 
systemd default dar opțional (de ce am nevoie de systemd pe 
docker?).  Încerc să nu fiu taliban, dar uneori... 🙂  Parcă nu mi se 
mai pare așa de aberant când căutam la windows2008 prin regiștri după 
plăci de rețea "fantomă" ... 


pai stai ... de ce sa upgradezi un container? sau ce sa upgradezi la el?

pana la urma asta e filosofia containerelor, faci build cu versiunea 
noua de pachet(e) si dai deploy (sau cu ceva kubernetzi schimbi 
imaginea si reporneste el containerele noi)


sau poate n-am inteles eu exact ce voiai sa zici, ca deh, vineri 
seara, s-a adunat oboseala


Alex



___
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] flame de vineri ( ubuntu)

On Fri, Mar 22, 2024 at 9:13 PM Alex 'CAVE' Cernat via RLUG <
rlug@lists.lug.ro> wrote:

> On 22-Mar-24 20:53, Mihai Badici via RLUG wrote:
> > .Și apropo, că am avut niște treburi mai acum ceva ani cu
> > containerele, la un moment dat vine docker și zice: filozofia mea e
> > "un container, un proces". Oops. nu pot rula ubuntu sau debian, pentru
> > că am deja un proces, systemd, și nu îl mai pot porni pe al doilea.
> > Până la urmă au fușerit-o cumva, dar a fost o perioadă în care nu
> > puteai să upgradezi containerele vechi, care nu aveau systemd, pentru
> > că alea noi aveau systemd mandatory. O aberație, care s-a rezolvat
> > prin altă aberație, când soluția evidentă era să facă systemd default
> > dar opțional (de ce am nevoie de systemd pe docker?).  Încerc să nu
> > fiu taliban, dar uneori... 🙂  Parcă nu mi se mai pare așa de aberant
> > când căutam la windows2008 prin regiștri după plăci de rețea "fantomă"
> > ...
>
> pai stai ... de ce sa upgradezi un container? sau ce sa upgradezi la el?
>
> pana la urma asta e filosofia containerelor, faci build cu versiunea
> noua de pachet(e) si dai deploy (sau cu ceva kubernetzi schimbi imaginea
> si reporneste el containerele noi)
>
> sau poate n-am inteles eu exact ce voiai sa zici, ca deh, vineri seara,
> s-a adunat oboseala
>
>
Iti traduc eu: am aflat cu stupoare ca e lume care foloseste containerele
ca pe vm-uri, intri in el, modifici chestii, eventual dai docker commit (or
some such) si merge mai departe. Imaginea aia practic nu paraseste serverul
(si nu are backup sau ceva), si te poti lauda ca uite mama, dockere.

Eu am dat cu capul de lumea asta pe "high road", cu construit imagini in
alta parte, impins in repository, tras de acolo pe diverse masini care le
ruleaza, tinut datele locale in volume separate, etc. Dar am dat de oameni
care lucreaza cum am descris mai sus, si mi-e mila de ei (sau nu).

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

Re: [rlug] flame de vineri ( ubuntu)


On 22-Mar-24 20:53, Mihai Badici via RLUG wrote:
.Și apropo, că am avut niște treburi mai acum ceva ani cu 
containerele, la un moment dat vine docker și zice: filozofia mea e 
"un container, un proces". Oops. nu pot rula ubuntu sau debian, pentru 
că am deja un proces, systemd, și nu îl mai pot porni pe al doilea. 
Până la urmă au fușerit-o cumva, dar a fost o perioadă în care nu 
puteai să upgradezi containerele vechi, care nu aveau systemd, pentru 
că alea noi aveau systemd mandatory. O aberație, care s-a rezolvat 
prin altă aberație, când soluția evidentă era să facă systemd default 
dar opțional (de ce am nevoie de systemd pe docker?).  Încerc să nu 
fiu taliban, dar uneori... 🙂  Parcă nu mi se mai pare așa de aberant 
când căutam la windows2008 prin regiștri după plăci de rețea "fantomă" 
... 


pai stai ... de ce sa upgradezi un container? sau ce sa upgradezi la el?

pana la urma asta e filosofia containerelor, faci build cu versiunea 
noua de pachet(e) si dai deploy (sau cu ceva kubernetzi schimbi imaginea 
si reporneste el containerele noi)


sau poate n-am inteles eu exact ce voiai sa zici, ca deh, vineri seara, 
s-a adunat oboseala


Alex



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

Re: [rlug] flame de vineri ( ubuntu)

Voiam sa-ti raspund punctual la cele cateva prostii pe care le-ai spus, dar
mi-am dat seama ca toate se rezuma la "daca n-ai presupune ca esti destept
si le stii deja pe toate pentru ca faci astea de hat-hat, ai putea vedea
din documentatie (care exista!) ca lucrurile nu-s asa complicate".

Seara faina, programul de flama s-a terminat,

-- 
P.

On Fri, Mar 22, 2024 at 8:56 PM Mihai Badici via RLUG 
wrote:

> Netplan a fost dat afară pentru că s-au gândit ei că dacă am dezinstalat
> python nu îmi mai trebuie nici netplan.
>
> Problema e că aparent netplan e sistemul default de configurare network
> în ubuntu, cel puțin asta înțeleg ( btw, de când ubuntu a ajuns noul
> windows e aproape imposibil să mai găsești o documentație ca lumea
> pentru că numărul de kizi a înecat în zgomot orice informație utilă. By
> default aleg răspunsurile care nu conțin "ub)untu")
>
> Și sigur că ai dreptate, mi-am permis o atitudine mai laxă pentru că era
> un vps nou, nu aveam aplicații în producție (adică nu aveam deloc) și
> aveam și VNC. Dar încă o dată, nu despre asta vorbeam. Sigur că
> providerul chiar îmi dădea dhcp, dar cu ce script de inițializare
> trebuia să primesc eu dhcp-ul ăla?  Eu în general prefer căile simple,
> în general să lași setările așa cum erau pare suficient de sigur.
>
> Acu' știu, când începi să zici că "pe vremea noastră... " sigur e semn
> de bătrânețe  și probabil că nici nu e adevărat, pentru că acum
> sistemele merg mai bine decât atunci (chiar merg) . Dar chiar mi se pare
> că unele lucruri au început să fie complicate excesiv și fără vreo
> utilitate concretă. Evident nu toate, și nu totdeauna, dar uneori chiar
> e adevârat.
>
> Sunt ani de zile de când folosesc debian, că deși în continuare apreciez
> simplitatea și curățenia unui sistem ca slackware îmi dau seama și de
> slăbiciunile pe care le implică. Debian are niște scripturi de
> networking extrem de legacy care însă fac față și nu dau rateuri
> niciodată ( a, da, a fost și la ei o bătaie de cap când s-a schimbat
> schema de denumire a interfețelor, dar aia era justificată, o schimbare
> majoră în kernel). Dacă vrei ceva mai complicat, ai network-manager
> (acum ai chiar și în slackware 15.0 , de pildă). Mi se pare o atitudine
> sănătoasă și sigură. Un sistem simplu și sigur, dublat de unul mai
> complex dacă ai nevoie. Dincoace, la ubuntu, au preferat să meargă
> direct pe calea complicată. cloud-init, netplan, python... Evident, ai
> și network-manager.  Nici nu îmi e clar dacă a mai rămas vreo variantă
> simplă în afară de a-ți scrie tu un script "ca pe vremuri".
>
> .Și apropo, că am avut niște treburi mai acum ceva ani cu containerele,
> la un moment dat vine docker și zice: filozofia mea e "un container, un
> proces". Oops. nu pot rula ubuntu sau debian, pentru că am deja un
> proces, systemd, și nu îl mai pot porni pe al doilea. Până la urmă au
> fușerit-o cumva, dar a fost o perioadă în care nu puteai să upgradezi
> containerele vechi, care nu aveau systemd, pentru că alea noi aveau
> systemd mandatory. O aberație, care s-a rezolvat prin altă aberație,
> când soluția evidentă era să facă systemd default dar opțional (de ce am
> nevoie de systemd pe docker?).  Încerc să nu fiu taliban, dar uneori...
> :)  Parcă nu mi se mai pare așa de aberant când căutam la windows2008
> prin regiștri după plăci de rețea "fantomă" ...
>
>
>
>
> On 3/22/24 20:00, Petru Rațiu via RLUG wrote:
> > Deci sa traduc: vps-ul pe care l-ai primit avea dhcp setat cu netplan for
> > some reason si nu era marcat pachetul ca manually installed sau a fost
> alt
> > fuckup pe-acolo. Prin ghidul de dist-upgrade (care, btw, merita citit din
> > scoarta in scoarta de fiecare data cand nu vrei sa-ti gasesti sistemul pe
> > branci, oricat de destept esti), cu siguranta zice sa faci review la
> > pachetele care se instaleaza/dezinstaleaza la fiecare pas, poate sunt
> unele
> > de care-ti pasa mai mult decat apt-ului si trebuie sa faci ceva in
> directia
> > asta.
> > Puteai rezolva problema fie verificand de ce a fost dat netplan afara (nu
> > mai e suportat? versiunea urmatoare conflicta cu altceva din sistem? nu
> > stiu), fie setandu-ti alt mod de configurare a placii de retea
> (providerul
> > iti da pe dhcp, sunt convins ca i se falfaie ce client folosesti tu).
> >
> > Asta cu "de ce depind eu de X" e mult mai subiectiva decat ai crede. Cum
> > ziceam, in Debian perl-base e marcat ca Essential pentru ca sunt pe ici
> pe
> > colo niste scripturi perl care tin toata sandramaua in picioare.
> Alternativ
> > /bin/sh nu e bash by default pentru ca viata fara sa descoperi ca un
> script
> > avea bashisms in el era prea simpla (I'm not bitter, no).
> >
> > In orice caz, astea vin la pachet imho cu credentialele de root. Userii
> > care nu vor sa le pese de ce reteaua are nevoie de python n-ar trebui sa
> > poata da do-dist-upgrade :D
> >
> > Si revenind la original XY problem, se recomanda ca pentru aplicatii care
> > depind de versiuni specifice de python/perl/ruby s

Re: [rlug] flame de vineri ( ubuntu)

Netplan a fost dat afară pentru că s-au gândit ei că dacă am dezinstalat 
python nu îmi mai trebuie nici netplan.


Problema e că aparent netplan e sistemul default de configurare network 
în ubuntu, cel puțin asta înțeleg ( btw, de când ubuntu a ajuns noul 
windows e aproape imposibil să mai găsești o documentație ca lumea 
pentru că numărul de kizi a înecat în zgomot orice informație utilă. By 
default aleg răspunsurile care nu conțin "ub)untu")


Și sigur că ai dreptate, mi-am permis o atitudine mai laxă pentru că era 
un vps nou, nu aveam aplicații în producție (adică nu aveam deloc) și 
aveam și VNC. Dar încă o dată, nu despre asta vorbeam. Sigur că 
providerul chiar îmi dădea dhcp, dar cu ce script de inițializare 
trebuia să primesc eu dhcp-ul ăla?  Eu în general prefer căile simple, 
în general să lași setările așa cum erau pare suficient de sigur.


Acu' știu, când începi să zici că "pe vremea noastră... " sigur e semn 
de bătrânețe  și probabil că nici nu e adevărat, pentru că acum 
sistemele merg mai bine decât atunci (chiar merg) . Dar chiar mi se pare 
că unele lucruri au început să fie complicate excesiv și fără vreo 
utilitate concretă. Evident nu toate, și nu totdeauna, dar uneori chiar 
e adevârat.


Sunt ani de zile de când folosesc debian, că deși în continuare apreciez 
simplitatea și curățenia unui sistem ca slackware îmi dau seama și de 
slăbiciunile pe care le implică. Debian are niște scripturi de 
networking extrem de legacy care însă fac față și nu dau rateuri 
niciodată ( a, da, a fost și la ei o bătaie de cap când s-a schimbat 
schema de denumire a interfețelor, dar aia era justificată, o schimbare 
majoră în kernel). Dacă vrei ceva mai complicat, ai network-manager 
(acum ai chiar și în slackware 15.0 , de pildă). Mi se pare o atitudine 
sănătoasă și sigură. Un sistem simplu și sigur, dublat de unul mai 
complex dacă ai nevoie. Dincoace, la ubuntu, au preferat să meargă 
direct pe calea complicată. cloud-init, netplan, python... Evident, ai 
și network-manager.  Nici nu îmi e clar dacă a mai rămas vreo variantă 
simplă în afară de a-ți scrie tu un script "ca pe vremuri".


.Și apropo, că am avut niște treburi mai acum ceva ani cu containerele, 
la un moment dat vine docker și zice: filozofia mea e "un container, un 
proces". Oops. nu pot rula ubuntu sau debian, pentru că am deja un 
proces, systemd, și nu îl mai pot porni pe al doilea. Până la urmă au 
fușerit-o cumva, dar a fost o perioadă în care nu puteai să upgradezi 
containerele vechi, care nu aveau systemd, pentru că alea noi aveau 
systemd mandatory. O aberație, care s-a rezolvat prin altă aberație, 
când soluția evidentă era să facă systemd default dar opțional (de ce am 
nevoie de systemd pe docker?).  Încerc să nu fiu taliban, dar uneori... 
:)  Parcă nu mi se mai pare așa de aberant când căutam la windows2008 
prin regiștri după plăci de rețea "fantomă" ...





On 3/22/24 20:00, Petru Rațiu via RLUG wrote:

Deci sa traduc: vps-ul pe care l-ai primit avea dhcp setat cu netplan for
some reason si nu era marcat pachetul ca manually installed sau a fost alt
fuckup pe-acolo. Prin ghidul de dist-upgrade (care, btw, merita citit din
scoarta in scoarta de fiecare data cand nu vrei sa-ti gasesti sistemul pe
branci, oricat de destept esti), cu siguranta zice sa faci review la
pachetele care se instaleaza/dezinstaleaza la fiecare pas, poate sunt unele
de care-ti pasa mai mult decat apt-ului si trebuie sa faci ceva in directia
asta.
Puteai rezolva problema fie verificand de ce a fost dat netplan afara (nu
mai e suportat? versiunea urmatoare conflicta cu altceva din sistem? nu
stiu), fie setandu-ti alt mod de configurare a placii de retea (providerul
iti da pe dhcp, sunt convins ca i se falfaie ce client folosesti tu).

Asta cu "de ce depind eu de X" e mult mai subiectiva decat ai crede. Cum
ziceam, in Debian perl-base e marcat ca Essential pentru ca sunt pe ici pe
colo niste scripturi perl care tin toata sandramaua in picioare. Alternativ
/bin/sh nu e bash by default pentru ca viata fara sa descoperi ca un script
avea bashisms in el era prea simpla (I'm not bitter, no).

In orice caz, astea vin la pachet imho cu credentialele de root. Userii
care nu vor sa le pese de ce reteaua are nevoie de python n-ar trebui sa
poata da do-dist-upgrade :D

Si revenind la original XY problem, se recomanda ca pentru aplicatii care
depind de versiuni specifice de python/perl/ruby sa folosesti unele
instalate local, nu pe cele ale sistemului, ca sa poti sa le upgradezi
separat, cu pachetele lor, samd. Nu neaparat containere, dar ceva sa placa
la toata lumea (virtualenv, rvm, whatever).



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

Re: [rlug] flame de vineri ( ubuntu)

Deci sa traduc: vps-ul pe care l-ai primit avea dhcp setat cu netplan for
some reason si nu era marcat pachetul ca manually installed sau a fost alt
fuckup pe-acolo. Prin ghidul de dist-upgrade (care, btw, merita citit din
scoarta in scoarta de fiecare data cand nu vrei sa-ti gasesti sistemul pe
branci, oricat de destept esti), cu siguranta zice sa faci review la
pachetele care se instaleaza/dezinstaleaza la fiecare pas, poate sunt unele
de care-ti pasa mai mult decat apt-ului si trebuie sa faci ceva in directia
asta.
Puteai rezolva problema fie verificand de ce a fost dat netplan afara (nu
mai e suportat? versiunea urmatoare conflicta cu altceva din sistem? nu
stiu), fie setandu-ti alt mod de configurare a placii de retea (providerul
iti da pe dhcp, sunt convins ca i se falfaie ce client folosesti tu).

Asta cu "de ce depind eu de X" e mult mai subiectiva decat ai crede. Cum
ziceam, in Debian perl-base e marcat ca Essential pentru ca sunt pe ici pe
colo niste scripturi perl care tin toata sandramaua in picioare. Alternativ
/bin/sh nu e bash by default pentru ca viata fara sa descoperi ca un script
avea bashisms in el era prea simpla (I'm not bitter, no).

In orice caz, astea vin la pachet imho cu credentialele de root. Userii
care nu vor sa le pese de ce reteaua are nevoie de python n-ar trebui sa
poata da do-dist-upgrade :D

Si revenind la original XY problem, se recomanda ca pentru aplicatii care
depind de versiuni specifice de python/perl/ruby sa folosesti unele
instalate local, nu pe cele ale sistemului, ca sa poti sa le upgradezi
separat, cu pachetele lor, samd. Nu neaparat containere, dar ceva sa placa
la toata lumea (virtualenv, rvm, whatever).

-- 
P.

On Fri, Mar 22, 2024 at 7:16 PM Mihai Badici via RLUG 
wrote:

> Da, concret problema a fost că am dat apt-remove la python3 (înainte de
> a da dist-upgrade) și nu am observat că a dezinstalat netplan. (nu mai
> țin minte de ce am dezinstalat python dar clar aplicația nu mergea cu
> python3.8.) După aia la do-dist-upgrade zicea că nu am terminat upgrade
> ( upgradease kernelul așa că avea nevoie de restart) . Drept pentru care
> am dat liniștit restart fără să îmi pun problema că aș putea rămâne fără
> conexiune. Până la urmă acel config yml îl pot ridica și cu rc.inet1,
> asta ziceam, care nu depinde decât de /bin/sh dar parcă te aștepți ca
> shell-ul să existe totdeuna în linux, spre deosebire de python, chiar
> dacă, evident, nici asta nu e sigur :)
>
> On 3/22/24 18:58, Mihai Badici via RLUG wrote:
> > Da, bun. știu care a fost problema mea, dar nu despre asta e vorba ci
> > de ceva mai general, că nu te aștepți ca placa de rețea să depindă de
> > python, perl, mâine de go sau dotnet. Placa de rețea mi se pare
> > esențială în zilele noastre când toți lucrăm remote și ar trebui să
> > aibă măcar un fallback acolo să ruleze un dhcp client dacă nu are
> > config dacă tot vrem să fie complicat.
> >
> > On 3/22/24 18:55, Petru Rațiu wrote:
> >> Cred ca de fapt problema ta e ca la dist-upgrade n-ai fost atent ca
> >> iti scoate netplan si daca stiai ca depinzi in mod particular de el
> >> trebuia sa faci ceva in directia asta. Poate trebuia marcat ca
> >> manually installed sau ceva, poate (daca a fost obsoleted, nu stiu)
> >> trebuia in prealabil sa folosesti alt client de dhcp, etc.
> >>
> >> --
> >> P.
> >>
> >> On Fri, Mar 22, 2024 at 5:52 PM Mihai Badici  wrote:
> >>
> >> Asta-i problema: ca să își ia ip ubuntu rulează netplan:
> >>
> >>
> >> cat /usr/share/netplan/netplan.script
> >> #!/usr/bin/python3
> >> #
> >> # Copyright (C) 2018 Canonical, Ltd.
> >> # Author: Mathieu Trudel-Lapierre
> >> 
> >> 
> >> #
> >>
> >>
> >> On 3/22/24 17:48, Petru Rațiu wrote:
> >>> N-am inteles exact ce probleme ai cu python si de ce esti
> >>> dependent de el. Clientul de dhcp de obicei trimite ce-a primit
> >>> la ceva hook care-i primeste ca parametri si face $chestii . Nu
> >>> prea stiu eu cu ubunti si netplanuri si de-astea, da' pe debian
> >>> lucrurile astea se fac cu shellscripts all the way down. Besides,
> >>> problemele astea cu "se schimba pythonul" nu-s chiar asa grave,
> >>> in special la probleme de-astea cu "uite un string, da-l mai
> >>> departe". Probabil ai tu niste ptsd de la trecerea de la 2 la 3.
> >>>
> >>> Nu mai sunt nici eu chiar spring chicken, da' asta cu "pe vremea
> >>> mea maica, puneam chestii hardcodate in rc.local si mergea" erau
> >>> ridicole si acum vreo 15 ani. Si tin minte flame-uri si de pe
> >>> atunci ca haha, Debian e bloated ca are nevoie de perl sa booteze.
> >>> -- P.
> >>>
> >>> On Fri, Mar 22, 2024 at 5:18 PM Mihai Badici via RLUG
> >>>  wrote:
> >>>
> >>> > IIRC e in documentatia de preseed ceva exemplu despre cum
> >>> poti folosi
> >>> > stringul de agent (? am uitat exact detaliile si e prea
> >>> vineri ca sa caut
> >>> >

Re: [rlug] flame de vineri ( ubuntu)

Da, concret problema a fost că am dat apt-remove la python3 (înainte de 
a da dist-upgrade) și nu am observat că a dezinstalat netplan. (nu mai 
țin minte de ce am dezinstalat python dar clar aplicația nu mergea cu 
python3.8.) După aia la do-dist-upgrade zicea că nu am terminat upgrade 
( upgradease kernelul așa că avea nevoie de restart) . Drept pentru care 
am dat liniștit restart fără să îmi pun problema că aș putea rămâne fără 
conexiune. Până la urmă acel config yml îl pot ridica și cu rc.inet1, 
asta ziceam, care nu depinde decât de /bin/sh dar parcă te aștepți ca 
shell-ul să existe totdeuna în linux, spre deosebire de python, chiar 
dacă, evident, nici asta nu e sigur :)

On 3/22/24 18:58, Mihai Badici via RLUG wrote:
Da, bun. știu care a fost problema mea, dar nu despre asta e vorba ci 
de ceva mai general, că nu te aștepți ca placa de rețea să depindă de 
python, perl, mâine de go sau dotnet. Placa de rețea mi se pare 
esențială în zilele noastre când toți lucrăm remote și ar trebui să 
aibă măcar un fallback acolo să ruleze un dhcp client dacă nu are 
config dacă tot vrem să fie complicat.

On 3/22/24 18:55, Petru Rațiu wrote:
Cred ca de fapt problema ta e ca la dist-upgrade n-ai fost atent ca 
iti scoate netplan si daca stiai ca depinzi in mod particular de el 
trebuia sa faci ceva in directia asta. Poate trebuia marcat ca 
manually installed sau ceva, poate (daca a fost obsoleted, nu stiu) 
trebuia in prealabil sa folosesti alt client de dhcp, etc.

--
P.

On Fri, Mar 22, 2024 at 5:52 PM Mihai Badici  wrote:

    Asta-i problema: ca să își ia ip ubuntu rulează netplan:

    cat /usr/share/netplan/netplan.script
    #!/usr/bin/python3
    #
    # Copyright (C) 2018 Canonical, Ltd.
    # Author: Mathieu Trudel-Lapierre

    #

    On 3/22/24 17:48, Petru Rațiu wrote:

    N-am inteles exact ce probleme ai cu python si de ce esti
    dependent de el. Clientul de dhcp de obicei trimite ce-a primit
    la ceva hook care-i primeste ca parametri si face $chestii . Nu
    prea stiu eu cu ubunti si netplanuri si de-astea, da' pe debian
    lucrurile astea se fac cu shellscripts all the way down. Besides,
    problemele astea cu "se schimba pythonul" nu-s chiar asa grave,
    in special la probleme de-astea cu "uite un string, da-l mai
    departe". Probabil ai tu niste ptsd de la trecerea de la 2 la 3.

    Nu mai sunt nici eu chiar spring chicken, da' asta cu "pe vremea
    mea maica, puneam chestii hardcodate in rc.local si mergea" erau
    ridicole si acum vreo 15 ani. Si tin minte flame-uri si de pe
    atunci ca haha, Debian e bloated ca are nevoie de perl sa booteze.
    --     P.

    On Fri, Mar 22, 2024 at 5:18 PM Mihai Badici via RLUG
     wrote:

    > IIRC e in documentatia de preseed ceva exemplu despre cum
    poti folosi
    > stringul de agent (? am uitat exact detaliile si e prea
    vineri ca sa caut
    > terminologia exacta) setat de d-i in clientul de dhcp ca sa
    identifici
    > installerul, am folosit asta in trecut dar am uitat de ce,
    pana la urma e
    > mai simplu de debugat daca primesti acelasi lucru de la
    serverul de dhcp si
    > la pxe, si in installer si la normal boot. (fiecare din
    cele 3 situatii e
    > cu agentul ei, poti fi foarte creativ daca te mananca).
    >
    > PS: si n-am inteles niciodata insistenta asta pe ip-uri
    configurate manual,
    > e mai simplu si mai maintainable sa le tii pe serverul de
    dhcp, what is
    > wrong with you people.

    Păi na, nu era vps-ul meu și nu am eu control pe DHCP dar
    sunt destul de
    sigur că și cu dhcp tot depinde de python. Că problema e că
    ori că îi
    dai un bash script cu ip add x.x.x.x ori un dhclient care
    sunt să zicem
    utilitare mandatory pe un container tot e mai simplu decât să
    rulezi un
    script python la care peste un an o să mai schimbe vreo
    bibliotecă și
    n-o să mai meargă by default :)

    ___
    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

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

Re: [rlug] flame de vineri ( ubuntu)

Da, bun. știu care a fost problema mea, dar nu despre asta e vorba ci de 
ceva mai general, că nu te aștepți ca placa de rețea să depindă de 
python, perl, mâine de go sau dotnet. Placa de rețea mi se pare 
esențială în zilele noastre când toți lucrăm remote și ar trebui să aibă 
măcar un fallback acolo să ruleze un dhcp client dacă nu are config dacă 
tot vrem să fie complicat.

On 3/22/24 18:55, Petru Rațiu wrote:
Cred ca de fapt problema ta e ca la dist-upgrade n-ai fost atent ca 
iti scoate netplan si daca stiai ca depinzi in mod particular de el 
trebuia sa faci ceva in directia asta. Poate trebuia marcat ca 
manually installed sau ceva, poate (daca a fost obsoleted, nu stiu) 
trebuia in prealabil sa folosesti alt client de dhcp, etc.

--
P.

On Fri, Mar 22, 2024 at 5:52 PM Mihai Badici  wrote:

Asta-i problema: ca să își ia ip ubuntu rulează netplan:

cat /usr/share/netplan/netplan.script
#!/usr/bin/python3
#
# Copyright (C) 2018 Canonical, Ltd.
# Author: Mathieu Trudel-Lapierre

#

On 3/22/24 17:48, Petru Rațiu wrote:

N-am inteles exact ce probleme ai cu python si de ce esti
dependent de el. Clientul de dhcp de obicei trimite ce-a primit
la ceva hook care-i primeste ca parametri si face $chestii . Nu
prea stiu eu cu ubunti si netplanuri si de-astea, da' pe debian
lucrurile astea se fac cu shellscripts all the way down. Besides,
problemele astea cu "se schimba pythonul" nu-s chiar asa grave,
in special la probleme de-astea cu "uite un string, da-l mai
departe". Probabil ai tu niste ptsd de la trecerea de la 2 la 3.

Nu mai sunt nici eu chiar spring chicken, da' asta cu "pe vremea
mea maica, puneam chestii hardcodate in rc.local si mergea" erau
ridicole si acum vreo 15 ani. Si tin minte flame-uri si de pe
atunci ca haha, Debian e bloated ca are nevoie de perl sa booteze.
-- 
P.

On Fri, Mar 22, 2024 at 5:18 PM Mihai Badici via RLUG
 wrote:

> IIRC e in documentatia de preseed ceva exemplu despre cum
poti folosi
> stringul de agent (? am uitat exact detaliile si e prea
vineri ca sa caut
> terminologia exacta) setat de d-i in clientul de dhcp ca sa
identifici
> installerul, am folosit asta in trecut dar am uitat de ce,
pana la urma e
> mai simplu de debugat daca primesti acelasi lucru de la
serverul de dhcp si
> la pxe, si in installer si la normal boot. (fiecare din
cele 3 situatii e
> cu agentul ei, poti fi foarte creativ daca te mananca).
>
> PS: si n-am inteles niciodata insistenta asta pe ip-uri
configurate manual,
> e mai simplu si mai maintainable sa le tii pe serverul de
dhcp, what is
> wrong with you people.

Păi na, nu era vps-ul meu și nu am eu control pe DHCP dar
sunt destul de
sigur că și cu dhcp tot depinde de python. Că problema e că
ori că îi
dai un bash script cu ip add x.x.x.x ori un dhclient care
sunt să zicem
utilitare mandatory pe un container tot e mai simplu decât să
rulezi un
script python la care peste un an o să mai schimbe vreo
bibliotecă și
n-o să mai meargă by default :)

___
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] flame de vineri ( ubuntu)

Stai că probabil ai dat tu cumva mailul că am dat reply pe adresa ta 
personală.

Deci problema mea nu e că e configul static ori dinamic, exemplul ăla 
din bsd l-am dat din răutate, problema e că nu știu precis cum ia datele 
networkd de la netplan dar dacă nu merge netplanul placa de rețea nu se 
ridică. Iar netplan depinde de python3.  Acum sigur că o dată ce știi 
asta nu o să o mai pățești a doua oară dar mi se pare o idee bună ca 
scripturile de init să fie cât mai simple și de preferință statice. Așa 
sigur că putem supraviețui dar asta e ca pe vremea părinților noștri cu 
"merge și-așa". Da systemd rezolvă și el unele probleme (majoritatea 
sunt probleme pe care nu le aveam, ce mișto bootează laptopul meu în 2 
secunde o dată la două săptămâni când îl pornesc) și da, e mișto să ai 
python și să faci tot felul de vrăjitorii cu el, dar chiar trebuie să 
depindă pornirea plăcii de rețea de el?

Așa putem să stăm și cu 3 versiuni de python în sistem, cum stăm și cu 3 
versiuni de .net sau de java, dar chiar e stupid :)

On 3/22/24 17:48, Petru Rațiu wrote:
N-am inteles exact ce probleme ai cu python si de ce esti dependent de 
el. Clientul de dhcp de obicei trimite ce-a primit la ceva hook care-i 
primeste ca parametri si face $chestii . Nu prea stiu eu cu ubunti si 
netplanuri si de-astea, da' pe debian lucrurile astea se fac cu 
shellscripts all the way down. Besides, problemele astea cu "se 
schimba pythonul" nu-s chiar asa grave, in special la probleme 
de-astea cu "uite un string, da-l mai departe". Probabil ai tu niste 
ptsd de la trecerea de la 2 la 3.

Nu mai sunt nici eu chiar spring chicken, da' asta cu "pe vremea mea 
maica, puneam chestii hardcodate in rc.local si mergea" erau ridicole 
si acum vreo 15 ani. Si tin minte flame-uri si de pe atunci ca haha, 
Debian e bloated ca are nevoie de perl sa booteze.

--
P.

On Fri, Mar 22, 2024 at 5:18 PM Mihai Badici via RLUG 
 wrote:

> IIRC e in documentatia de preseed ceva exemplu despre cum poti
folosi
> stringul de agent (? am uitat exact detaliile si e prea vineri
ca sa caut
> terminologia exacta) setat de d-i in clientul de dhcp ca sa
identifici
> installerul, am folosit asta in trecut dar am uitat de ce, pana
la urma e
> mai simplu de debugat daca primesti acelasi lucru de la serverul
de dhcp si
> la pxe, si in installer si la normal boot. (fiecare din cele 3
situatii e
> cu agentul ei, poti fi foarte creativ daca te mananca).
>
> PS: si n-am inteles niciodata insistenta asta pe ip-uri
configurate manual,
> e mai simplu si mai maintainable sa le tii pe serverul de dhcp,
what is
> wrong with you people.

Păi na, nu era vps-ul meu și nu am eu control pe DHCP dar sunt
destul de
sigur că și cu dhcp tot depinde de python. Că problema e că ori că îi
dai un bash script cu ip add x.x.x.x ori un dhclient care sunt să
zicem
utilitare mandatory pe un container tot e mai simplu decât să
rulezi un
script python la care peste un an o să mai schimbe vreo bibliotecă și
n-o să mai meargă by default :)

___
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] flame de vineri ( ubuntu)

N-am inteles exact ce probleme ai cu python si de ce esti dependent de el.
Clientul de dhcp de obicei trimite ce-a primit la ceva hook care-i primeste
ca parametri si face $chestii . Nu prea stiu eu cu ubunti si netplanuri si
de-astea, da' pe debian lucrurile astea se fac cu shellscripts all the way
down. Besides, problemele astea cu "se schimba pythonul" nu-s chiar asa
grave, in special la probleme de-astea cu "uite un string, da-l mai
departe". Probabil ai tu niste ptsd de la trecerea de la 2 la 3.

Nu mai sunt nici eu chiar spring chicken, da' asta cu "pe vremea mea maica,
puneam chestii hardcodate in rc.local si mergea" erau ridicole si acum vreo
15 ani. Si tin minte flame-uri si de pe atunci ca haha, Debian e bloated ca
are nevoie de perl sa booteze.
-- 
P.

On Fri, Mar 22, 2024 at 5:18 PM Mihai Badici via RLUG 
wrote:

> > IIRC e in documentatia de preseed ceva exemplu despre cum poti folosi
> > stringul de agent (? am uitat exact detaliile si e prea vineri ca sa caut
> > terminologia exacta) setat de d-i in clientul de dhcp ca sa identifici
> > installerul, am folosit asta in trecut dar am uitat de ce, pana la urma e
> > mai simplu de debugat daca primesti acelasi lucru de la serverul de dhcp
> si
> > la pxe, si in installer si la normal boot. (fiecare din cele 3 situatii e
> > cu agentul ei, poti fi foarte creativ daca te mananca).
> >
> > PS: si n-am inteles niciodata insistenta asta pe ip-uri configurate
> manual,
> > e mai simplu si mai maintainable sa le tii pe serverul de dhcp, what is
> > wrong with you people.
>
> Păi na, nu era vps-ul meu și nu am eu control pe DHCP dar sunt destul de
> sigur că și cu dhcp tot depinde de python. Că problema e că ori că îi
> dai un bash script cu ip add x.x.x.x ori un dhclient care sunt să zicem
> utilitare mandatory pe un container tot e mai simplu decât să rulezi un
> script python la care peste un an o să mai schimbe vreo bibliotecă și
> n-o să mai meargă by default :)
>
> ___
> 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] flame de vineri ( ubuntu)


IIRC e in documentatia de preseed ceva exemplu despre cum poti folosi
stringul de agent (? am uitat exact detaliile si e prea vineri ca sa caut
terminologia exacta) setat de d-i in clientul de dhcp ca sa identifici
installerul, am folosit asta in trecut dar am uitat de ce, pana la urma e
mai simplu de debugat daca primesti acelasi lucru de la serverul de dhcp si
la pxe, si in installer si la normal boot. (fiecare din cele 3 situatii e
cu agentul ei, poti fi foarte creativ daca te mananca).

PS: si n-am inteles niciodata insistenta asta pe ip-uri configurate manual,
e mai simplu si mai maintainable sa le tii pe serverul de dhcp, what is
wrong with you people.


Păi na, nu era vps-ul meu și nu am eu control pe DHCP dar sunt destul de 
sigur că și cu dhcp tot depinde de python. Că problema e că ori că îi 
dai un bash script cu ip add x.x.x.x ori un dhclient care sunt să zicem 
utilitare mandatory pe un container tot e mai simplu decât să rulezi un 
script python la care peste un an o să mai schimbe vreo bibliotecă și 
n-o să mai meargă by default :)


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

Re: [rlug] flame de vineri ( ubuntu)



On 3/22/24 16:07, Dumitru Moldovan via RLUG wrote:

On 3/22/24 09:13, Mihai Badici via RLUG wrote:
Acum că e vineri m-am gândit să lansez un flame, zilele trecute era 
traficul prea mare pe listă :)


Iacă-tă ce am pățit: am primit un vps cu ubuntu 20 configurat cu 
netplan să instalez o aplicație.


[…]


"Era mai bine înainte" ...


VPS, netplan, șamd…  Astea-s probleme din trecut, nene!  :-]

Cum de ai scăpat în ultimii ani de containerizarea aplicației? Ori în 
prezent de orchestrarea ca micro-serviciu în vreun Kubernetes ori ceva?


"We can solve any problem by introducing an extra level of indirection."


N-am scăpat chiar de tot dar eu nu prea iau aplicații de făcut, așa că 
mă mulțumesc cu ce a mai rămas pe infrastructură :)


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

Re: [rlug] flame de vineri ( ubuntu)

On Fri, Mar 22, 2024 at 12:31 PM Alex 'CAVE' Cernat via RLUG <
rlug@lists.lug.ro> wrote:

>
> folosind debian exista ceva asemanator, insa nu am gasit (ce-i drept,
> nici n-am incercat la vremea respectiva) metoda asta din 2 pasi, si nici
> nu am gasit pe undeva vreo referinta
>
>
IIRC e in documentatia de preseed ceva exemplu despre cum poti folosi
stringul de agent (? am uitat exact detaliile si e prea vineri ca sa caut
terminologia exacta) setat de d-i in clientul de dhcp ca sa identifici
installerul, am folosit asta in trecut dar am uitat de ce, pana la urma e
mai simplu de debugat daca primesti acelasi lucru de la serverul de dhcp si
la pxe, si in installer si la normal boot. (fiecare din cele 3 situatii e
cu agentul ei, poti fi foarte creativ daca te mananca).

PS: si n-am inteles niciodata insistenta asta pe ip-uri configurate manual,
e mai simplu si mai maintainable sa le tii pe serverul de dhcp, what is
wrong with you people.

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

Re: [rlug] flame de vineri ( ubuntu)

2024-03-22 Thread Dumitru Moldovan via RLUG


On 3/22/24 09:13, Mihai Badici via RLUG wrote:
Acum că e vineri m-am gândit să lansez un flame, zilele trecute era 
traficul prea mare pe listă :)


Iacă-tă ce am pățit: am primit un vps cu ubuntu 20 configurat cu netplan 
să instalez o aplicație.


[…]


"Era mai bine înainte" ...


VPS, netplan, șamd…  Astea-s probleme din trecut, nene!  :-]

Cum de ai scăpat în ultimii ani de containerizarea aplicației?  Ori în 
prezent de orchestrarea ca micro-serviciu în vreun Kubernetes ori ceva?


"We can solve any problem by introducing an extra level of indirection."


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

Re: [rlug] flame de vineri ( ubuntu)


On 22-Mar-24 14:10, Mihai Badici via RLUG wrote:
eu aș avea o idee și mai revoluționară: să facem o bază de date, 
numită registru, în care să punem toate setările 🙂 


si pentru ca suntem in rromania, musai trebuie sa vina la pachet cu 
renumitul dosar cu sina :-P


Alex


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

Re: [rlug] flame de vineri ( ubuntu)

eu aș avea o idee și mai revoluționară: să facem o bază de date, numită 
registru, în care să punem toate setările :)


On 3/22/24 12:30, Alex 'CAVE' Cernat via RLUG wrote:

On 22-Mar-24 12:06, Adrian Sevcenco via RLUG wrote:
Nu nu! dhcp da ip-ul la boot (si permite accesul la ks) iar apoi se 
aplica kickstart-ul care seteaza informatiile de ip static
eu folosesc doar rhel distros deci folosesc in kickstart asta (in 99% 
din cazuri):
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9/html/performing_an_advanced_rhel_9_installation/kickstart-commands-and-options-reference_installing-rhel-as-an-experienced-user#kickstart-commands-for-network-configuration_kickstart-commands-and-options-reference 



dar pentru networkd poti sa pui in kickstart in post
sa se creeze fisierele dorite, dai enable la systemd-networkd, 
disable la NetworkManager

si la reboot pleaca setarile networkd-ului

asta daca nu faci o chestie gen default dhcp cu un script (care se 
pune din kickstart)
care iti face post cu curl-ul cu informatiile de ip ale masinii la o 
destinatie fixa
si apoi aplici un playbook facut/generat care sa provizioneze masina 
cu network-ul dorit

eu mi-am facut asta: https://github.com/adriansev/dyndns_home
care imi genereaza entry-uri in dnsmasq 


interesant (bine, se stie ca redhatul e cu un cap peste, de aia e si 
pe bani :-P)


folosind debian exista ceva asemanator, insa nu am gasit (ce-i drept, 
nici n-am incercat la vremea respectiva) metoda asta din 2 pasi, si 
nici nu am gasit pe undeva vreo referinta


poti sa automatizezi (fie dhcp, fie hackish static), insa odata pusa 
adresa, din cate stiu nu o mai poti modifica pana dupa instalare


ma rog, pana la urma se poate oricand modifica in post-install, ca 
dupa aia in configuration management (ansible, chef, etc) sa ai ip-ul 
curat final


Alex



___
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] flame de vineri ( ubuntu)


On 22-Mar-24 12:06, Adrian Sevcenco via RLUG wrote:
Nu nu! dhcp da ip-ul la boot (si permite accesul la ks) iar apoi se 
aplica kickstart-ul care seteaza informatiile de ip static
eu folosesc doar rhel distros deci folosesc in kickstart asta (in 99% 
din cazuri):
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9/html/performing_an_advanced_rhel_9_installation/kickstart-commands-and-options-reference_installing-rhel-as-an-experienced-user#kickstart-commands-for-network-configuration_kickstart-commands-and-options-reference 



dar pentru networkd poti sa pui in kickstart in post
sa se creeze fisierele dorite, dai enable la systemd-networkd, disable 
la NetworkManager

si la reboot pleaca setarile networkd-ului

asta daca nu faci o chestie gen default dhcp cu un script (care se 
pune din kickstart)
care iti face post cu curl-ul cu informatiile de ip ale masinii la o 
destinatie fixa
si apoi aplici un playbook facut/generat care sa provizioneze masina 
cu network-ul dorit

eu mi-am facut asta: https://github.com/adriansev/dyndns_home
care imi genereaza entry-uri in dnsmasq 


interesant (bine, se stie ca redhatul e cu un cap peste, de aia e si pe 
bani :-P)


folosind debian exista ceva asemanator, insa nu am gasit (ce-i drept, 
nici n-am incercat la vremea respectiva) metoda asta din 2 pasi, si nici 
nu am gasit pe undeva vreo referinta


poti sa automatizezi (fie dhcp, fie hackish static), insa odata pusa 
adresa, din cate stiu nu o mai poti modifica pana dupa instalare


ma rog, pana la urma se poate oricand modifica in post-install, ca dupa 
aia in configuration management (ansible, chef, etc) sa ai ip-ul curat final


Alex



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

Re: [rlug] flame de vineri ( ubuntu)

2024-03-22 Thread Adrian Sevcenco via RLUG

 Original Message 
Subject: [rlug] flame de vineri ( ubuntu)
From: Alex 'CAVE' Cernat via RLUG
To: rlug@lists.lug.ro
Date: 3/22/2024, 10:58:04 AM

On 22-Mar-24 10:49, Adrian Sevcenco via RLUG wrote:

 Original Message 
Subject: [rlug] flame de vineri ( ubuntu)
From: Alex 'CAVE' Cernat via RLUG
To: rlug@lists.lug.ro
Date: 3/22/2024, 10:31:17 AM

On 22-Mar-24 10:02, Adrian Sevcenco via RLUG wrote:
eu am incercat la masini virtuale sa folosesc cloud-init-ul (care ar fi minunat ca se elimina etapa de instalare a 
masinii virtuale) dar mi-am prins urechile (din lipsa de timp) si quick and dirty am instalat masinile cu kickstarturi
generate automat .. 

de curiozitate ... cum integrai kickstartul in instalare ? ca pentru a-l pune pe net trebuia sa ai netul deja 
configurat ... problema de ou vs gaina :-P

pai exista un dhcp si default gw .. sau la ce te referi?
sau la --extra-args dat la virt-install?

mdea, corect, exista dhcp, chiar si cu rezervari, atunci cand vrei adrese "statice", gusturile nu se discuta, eu 
personal nu-s fan la dhcp (in afara de retelele cu statii de lucru)

la adrese statice eram curios de o solutie eleganta, stiu hack-uri sa mearga, 
dar nu e prea frumos si nici portabil
Nu nu!  dhcp da ip-ul la boot (si permite accesul la ks) iar apoi se aplica kickstart-ul care seteaza informatiile de ip 
static

eu folosesc doar rhel distros deci folosesc in kickstart asta (in 99% din 
cazuri):
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9/html/performing_an_advanced_rhel_9_installation/kickstart-commands-and-options-reference_installing-rhel-as-an-experienced-user#kickstart-commands-for-network-configuration_kickstart-commands-and-options-reference

dar pentru networkd poti sa pui in kickstart in post
sa se creeze fisierele dorite, dai enable la systemd-networkd, disable la 
NetworkManager
si la reboot pleaca setarile networkd-ului

asta daca nu faci o chestie gen default dhcp cu un script (care se pune din 
kickstart)
care iti face post cu curl-ul cu informatiile de ip ale masinii la o destinatie 
fixa
si apoi aplici un playbook facut/generat care sa provizioneze masina cu 
network-ul dorit
eu mi-am facut asta: https://github.com/adriansev/dyndns_home
care imi genereaza entry-uri in dnsmasq

Adrian

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

Re: [rlug] flame de vineri ( ubuntu)

On 22-Mar-24 10:49, Adrian Sevcenco via RLUG wrote:

 Original Message 
Subject: [rlug] flame de vineri ( ubuntu)
From: Alex 'CAVE' Cernat via RLUG
To: rlug@lists.lug.ro
Date: 3/22/2024, 10:31:17 AM

On 22-Mar-24 10:02, Adrian Sevcenco via RLUG wrote:
eu am incercat la masini virtuale sa folosesc cloud-init-ul (care ar 
fi minunat ca se elimina etapa de instalare a masinii virtuale) dar 
mi-am prins urechile (din lipsa de timp) si quick and dirty am 
instalat masinile cu kickstarturi
generate automat .. 

de curiozitate ... cum integrai kickstartul in instalare ? ca pentru 
a-l pune pe net trebuia sa ai netul deja configurat ... problema de 
ou vs gaina :-P

pai exista un dhcp si default gw .. sau la ce te referi?
sau la --extra-args dat la virt-install?

mdea, corect, exista dhcp, chiar si cu rezervari, atunci cand vrei 
adrese "statice", gusturile nu se discuta, eu personal nu-s fan la dhcp 
(in afara de retelele cu statii de lucru)

la adrese statice eram curios de o solutie eleganta, stiu hack-uri sa 
mearga, dar nu e prea frumos si nici portabil

Alex

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

Re: [rlug] flame de vineri ( ubuntu)

2024-03-22 Thread Adrian Sevcenco via RLUG

 Original Message 
Subject: [rlug] flame de vineri ( ubuntu)
From: Alex 'CAVE' Cernat via RLUG
To: rlug@lists.lug.ro
Date: 3/22/2024, 10:31:17 AM

On 22-Mar-24 10:02, Adrian Sevcenco via RLUG wrote:
eu am incercat la masini virtuale sa folosesc cloud-init-ul (care ar fi minunat ca se elimina etapa de instalare a 
masinii virtuale) dar mi-am prins urechile (din lipsa de timp) si quick and dirty am instalat masinile cu kickstarturi
generate automat .. 

de curiozitate ... cum integrai kickstartul in instalare ? ca pentru a-l pune pe net trebuia sa ai netul deja configurat 
... problema de ou vs gaina :-P

pai exista un dhcp si default gw .. sau la ce te referi?
sau la --extra-args dat la virt-install?

Adrian

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

Re: [rlug] flame de vineri ( ubuntu)