On 3/26/24 12:56, Mihai Badici via RLUG wrote:
Ș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
Ș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ă
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".
>
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
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
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 /
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
>
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
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
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
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ă
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ă
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
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
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
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
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
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
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
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
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
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ă
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
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
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
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.
>
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
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
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
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
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
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
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
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
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
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
Î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.
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
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
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
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
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
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
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
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
(
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
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
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
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
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
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
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,
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
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
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):
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
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
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
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
Si eu tot cu Cobra si Basic + OPUS am inceput ;)
https://cobrasov.com/CoBra%20Project/index.html
On Fri, Mar 22, 2024 at 8:47 AM 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
Original Message
Subject: [rlug] flame de vineri ( ubuntu)
From: Mihai Badici via RLUG
To: Romanian Linux Users Group
Date: 3/22/2024, 9:13:43 AM
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
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.
Doar că aplicația mea avea nevoie de un python mai mare, 3.10 măcar,
decât cel din
62 matches
Mail list logo
