Re: [rlug] probleme cu placa DELL Intel X520-DA2
On 23-May-24 12:14, Petru Rațiu via RLUG wrote: Din experienta mea de pana acu, fix "la nivelul ala" incepi sa dai de tampenii gen "iti trebuie driverul proprietar de la noi care merge doar pe RHEL tzshpe si doar daca ai configuratia hardware cutare pentru ca am decis noi sa hardcodam irq-uri sau alte chestii care pot genera conflicte". asta e deja episodul 2, care intr-adevar, e foarte "distractiv"; stiu ce zici, din fericire nu m-am fript prea rau (sau poate am uitat ...), dar asta nu inseamna ca nu port niste urme de "arsura" :-P eu ma refeream la primul episod, compatibilitatea hardware, care se cam stie, daca intri pe un brand, atunci acolo ramai (cel putin la nivel de masina fizica); ca asa e-n tenis Alex ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug_lists.lug.ro
Re: [rlug] probleme cu placa DELL Intel X520-DA2
acum sincer, cand vorbim de configuratie de brand, nu vaporene ce mai facem noi incropind din draq stie ce ... atunci la nivelul ala eu unul ma astept sa mearga din fuleu fara probleme de compatibilitate (macar la prima rulare, ca in rest ... vise umede, tot se strica ceva in feng shui mai devreme sau mai tarziu) asa ca daca vorbim de hashpeu (care nu face mitraliere pentru ca munitia ar fi mai scumpa decat arma in sine :-P) mai bine baga placa tot de la hashpe, ca poate cine stie, o fi citit sau doar "simtit" niste dell si a inceput sa sughite :-P Alex On 23-May-24 11:44, Paul Lacatus via RLUG wrote: De vreo doua săptămâni mă lupt cu o placa de rețea Intel 2xSFP+. Placa este DELL Intel X520-DA2 si încerc sa o instalez într-un HP Elitedesk 800 G5 SFF La început sistemul a dat eroare de POST trei beepuri lungi si doua scurte adica hardware configuration timeout . După ce am plimbat-o in alt slot sistemul a pornit , am pus pe el proxmox , am vazut toate interfețele , am mai pus un mesaj pe lista rlug, cu proxmox care a dublat interfețele când le-am plimbat intre slot-uri lucru care pare a fi o problema a PXMX. AM pus doua NVMe in sistem in pool ZFS pentru siguranță si am vrut sa închid cutia la sistem. De aici s-a terminat povestea. Orice am făcut aceleași trei beep-uri lungi si doua scurte. Scoasă placa sistemul merge. Am încercat totul , setări BIOs, update de BIOS , reset de BIOS . Nimic nu a mers. Am schimbat placa cu una identică schimbată de furnizor si totul a rămas la fel. Orice am făcut nimic nu a ajutat. Incompatibilitatea intre placa si sistem a mai fost observată si de alții si notificata pe forum pfSense, Autorul post-ului a pus si pe forum HP dar fără rezultat. Astăzi insa într-o discuție cu furnizorul plăcii mi s-a dat un link la un clip YTB cu o placa asemănătoare in care a izolat pinii B5,B6 (SMBus) de pe edge connector PCI . Am încercat si eu si sistemul a pornit , placa se vede la lspci , interfețele pe ea se vad si totul pare ok . Furnizorul insa mi-a spus ca au mai găsit o placa cu branding HP si ar putea sa mi-o schimbe. Alte date despre placa HP nu am nici daca e cu Intel sau Broadcom . Vreau si eu sa schimb o părere, ce sa fac: 1. Sa merg cu placa aceasta cu pinii de SMBus izolați știind ca SMBus e folosit doar la inițializare sistem , unde avea probleme cu host si ca placa apare corect la lspci? 2. Sa schimb placa cu cea HP si sa sper ca va merge implicit ? Multumesc Paul ___ 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] NIC-uri dublate in proxmox
1. da-i un reboot daca nu i-ai dat, suna stupid, insa rezolva multe (de la geam citire: for minor problems reboot, for major problems reinstall ... din cand in cand e valabil si pentru pinguin) 2. te-ai jucat cu schimbatul placilor in ultimul timp? de l-o fi vazut la un moment dat pe enp2 si apoi ai mutat in alt slot ? 3. nu mai stiu exact de unde determina proxmox care sunt placile de retea (presupun ca te referi la $server$/system/network in gui), insa am o vaga impresie ca se bazeaza pe /etc/network/interfaces, asa ca as recomanda sa arunci un ochi si pe acolo, poate au ramas niste gunoaie prin zona binenteles, preferabil e sa fii fizic prin zona sau cumva sa mai ai vreo modalitate de a intra pe server in caz de vreo gherla (ca deh, se intampla si la case mai mari); deci, avand in vedere ca te joci cu chestii foarte importante (si care-ti pot taia craca de sub picioare), atunci atentie maxima Alex ps: cum "simplicity is divine" (parca de la slack citire), intreb si eu: nu-s totusi cam multe placi de retea pe acolo? :-D daca nu le folosesti, mai scoate din ele :-P On 08-May-24 11:49, Paul Lacatus via RLUG wrote: Vreau sa fac un router ci opnSense sau pfSense virtualizat in proxmox . Pe sistem am un NIC in placa de baza si apoi o placa Intel cu 4 porturi de 1Gbps si o alta placa intel cu doua sfp+ de 10Gbps. Daca intreb la Lspci apar corect 00:1f.5 Serial bus controller: Intel Corporation Cannon Lake PCH SPI Controller (rev 10) 00:1f.6 Ethernet controller: Intel Corporation Ethernet Connection (7) I219-LM (rev 10) 01:00.0 Ethernet controller: Intel Corporation Ethernet 10G 2P X520 Adapter (rev 01) 01:00.1 Ethernet controller: Intel Corporation Ethernet 10G 2P X520 Adapter (rev 01) 02:00.0 Non-Volatile memory controller: Samsung Electronics Co Ltd NVMe SSD Controller SM981/PM981/PM983 03:00.0 Ethernet controller: Intel Corporation 82580 Gigabit Network Connection (rev 01) 03:00.1 Ethernet controller: Intel Corporation 82580 Gigabit Network Connection (rev 01) 03:00.2 Ethernet controller: Intel Corporation 82580 Gigabit Network Connection (rev 01) 03:00.3 Ethernet controller: Intel Corporation 82580 Gigabit Network Connection (rev 01) la ip addr show e corect ip addr show 1: lo: mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host noprefixroute valid_lft forever preferred_lft forever 2: enp3s0f0: mtu 1500 qdisc noop state DOWN group default qlen 1000 link/ether 90:e2:ba:dc:85:d4 brd ff:ff:ff:ff:ff:ff 3: enp3s0f1: mtu 1500 qdisc noop state DOWN group default qlen 1000 link/ether 90:e2:ba:dc:85:d5 brd ff:ff:ff:ff:ff:ff 4: eno1: mtu 1500 qdisc pfifo_fast master vmbr0 state UP group default qlen 1000 link/ether 9c:7b:ef:3a:80:3a brd ff:ff:ff:ff:ff:ff altname enp0s31f6 5: enp3s0f2: mtu 1500 qdisc noop state DOWN group default qlen 1000 link/ether 90:e2:ba:dc:85:d6 brd ff:ff:ff:ff:ff:ff 6: enp3s0f3: mtu 1500 qdisc noop state DOWN group default qlen 1000 link/ether 90:e2:ba:dc:85:d7 brd ff:ff:ff:ff:ff:ff 7: enp1s0f0: mtu 1500 qdisc noop state DOWN group default qlen 1000 link/ether a0:36:9f:cf:8f:64 brd ff:ff:ff:ff:ff:ff 8: enp1s0f1: mtu 1500 qdisc noop state DOWN group default qlen 1000 link/ether a0:36:9f:cf:8f:66 brd ff:ff:ff:ff:ff:ff 9: vmbr0: mtu 1500 qdisc noqueue state UP group default qlen 1000 link/ether 9c:7b:ef:3a:80:3a brd ff:ff:ff:ff:ff:ff inet 10.50.0.20/8 scope global vmbr0 valid_lft forever preferred_lft forever inet6 fe80::9e7b:efff:fe3a:803a/64 scope link valid_lft forever preferred_lft forever dar in proxmox placa cu patru porturi apare dublata si pe enp2 si pe enp3 . ce sa fac ? Paul ___ 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] query plan mariadb
apropos de ordine diferita in join, am patit niste chestii de astea, unde desi bagasem la greu indecsi tocmai pentru a optimiza query-urile, ma trezeam ca incepe cu a doua / treia tabela ca i se parea lui ca ar fi mai avantajos, si binenteles ca se alegea praful de query time, ca desi la prima vedere avea dreptate, in final o lua rau pe ulei cu tabele temporare, full table scan & shit atunci un straight_join bine tintit il calma, pentru a forta ordinea de join; insa cu framework si orm-uri se mai complica treaba, ca nu stiu cat de mult control low level ai pentru asa ceva; chit ca by default nu-mi place sa dau cu bocancu in masa cu force index si forced join, dupa cum ziceam am cam prins-o pe maria de multe ori pe aratura, asa ca ... de curiozitate uita-te prin 'show index from $tabela', in special pe cardinalitate; si eventual mai verifica inca o data ca sunt definiti la fel (ar fi culmea sa nu fie, dar ... deh, nu se stie niciodata, shit happens everytime) si inca un hint: analyze format=json $query, iti da niste info in plus fata de explain, inclusiv timpi (dar vezi ca ruleaza si query-ul in spate, ceea ce e bine pentru raport, insa tu stii cat de bine e pentru server si date) mysql 8 are suport mult mai misto pentru ce am zis mai sus (output-ul seamana foarte mult cu ce iese de la postgres), insa la maria mai e de asteptat se pare (la 10.5 garantat nu e ... sau poate cine stie, descopar si eu apa calda :-P) Alex On 23-Apr-24 18:44, Petru Rațiu wrote: Cum ziceam, stiu deja teoriile astea. Wtf-urile mele au inceput cand mi-am dat seama ca query-ul care dura 3 minute pe master termina in cateva secunde pe slave, avand aceleasi date; vad ca la explain cele doua servere au idei diferite despre in ce ordine sa inceapa joinurile (ala rapid pleaca cu un dataset relativ mare la inceput dar dupa aia sunt mai simple restul de chestii). N-am reusit sa ma prind cum pot zice db-ului sa-mi zica mai mult despre la ce s-a uitat cand a facut planul (evident amicii cu postgres au zis ca la ei e simplu) si nu inteleg exact pe unde pe disc sunt tinute datele astea sa ma pot uita mai exact la ele nu sa aflu ca toata ziua de marti a mers infect cu acelasi gen de trafic ca luni. Cat despre scheme cu force index... Pe langa ca nu sunt sigur de ce ar fi mai util alt index in cazul ala, e foarte multa ungabunga de framework si de ORM pe drum unde nu-s convins cum as putea insera hinturi dinalea... -- P. On Tue, Apr 23, 2024 at 6:20 PM Alex 'CAVE' Cernat via RLUG wrote: si inca ceva, desi aici deja tine de programare: intotdeauna poti folosi in query use index sau chiar force index, daca maria e prea tembela (si din pacate am prins-o in offside, ce-i drept, si query-urile erau de-a dreptul cretine, dar deh, nu puteau fi modificate substantial din pacate) iar daca result set-ul e relativ mic, poti sa te joci cu deferred joins (in special cand gasesti imbecilisme de genul select * - ca atat s-a putut), procedura prin care intr-o prima faza selectezi in general id-uri si apoi pe baza lor poti sa selectezi si row-uri intregi, daca ai programatori lenesi; in felul asta nu mai scrie maria de nebuna pe disc tabele temporare imense (asa cum face daca vede ca are texte si bloburi prin tabela) https://aaronfrancis.com/2022/efficient-pagination-using-deferred-joins idem sunt bune si covering indexes, aka toate coloanele din result-ul respectiv sunt acoperite de index/indecsi, si atunci (presupunand ca indexul e in memorie) nu se mai duce pe disc sa citeasca tone de date iar legat de ce-ai cerut punctual (aka statistici de indecsi) sunt si eu curios, pana acum n-am gasit nimic de genul Alex On 23-Apr-24 14:19, Petru Rațiu via RLUG wrote: > Ma poate ajuta cineva sa inteleg la ce se uita mariadb (cu engine-ul > innodb) cand decide query plan la un query? Problema mea e ca am niste > query-uri care se fac mult mai greu pe master fata de slave care au date > identice, diferenta fiind ca slave-ul are date refacute dintr-un dump > recent (si resincronizat). Query planul arata diferit intre cele doua > servere si in trecut cand am mai avut problema asta s-a rezolvat dupa ce am > "optimizat" tabelele implicate (cu un alter table force). > > Stiu eu asa din legendele Olimpului ca planul se face pe baza unor > statistici pe indecsi mentinute in background, dar nu m-am lamurit din > documentatie unde sunt tinute, cum sa le urmaresc si daca le pot da un sut > mai simplu fara sa fac alter care dureaza 10 minute. Am gasit niste povesti > despre mysql.innodb_index_stats dar la o prima vedere si aia e replicata si > am oricum o jena sa modific chestii pe acolo fara sa inteleg. Also, nu m-am > prins daca am vreun mecan
Re: [rlug] query plan mariadb
si inca ceva, desi aici deja tine de programare: intotdeauna poti folosi in query use index sau chiar force index, daca maria e prea tembela (si din pacate am prins-o in offside, ce-i drept, si query-urile erau de-a dreptul cretine, dar deh, nu puteau fi modificate substantial din pacate) iar daca result set-ul e relativ mic, poti sa te joci cu deferred joins (in special cand gasesti imbecilisme de genul select * - ca atat s-a putut), procedura prin care intr-o prima faza selectezi in general id-uri si apoi pe baza lor poti sa selectezi si row-uri intregi, daca ai programatori lenesi; in felul asta nu mai scrie maria de nebuna pe disc tabele temporare imense (asa cum face daca vede ca are texte si bloburi prin tabela) https://aaronfrancis.com/2022/efficient-pagination-using-deferred-joins idem sunt bune si covering indexes, aka toate coloanele din result-ul respectiv sunt acoperite de index/indecsi, si atunci (presupunand ca indexul e in memorie) nu se mai duce pe disc sa citeasca tone de date iar legat de ce-ai cerut punctual (aka statistici de indecsi) sunt si eu curios, pana acum n-am gasit nimic de genul Alex On 23-Apr-24 14:19, Petru Rațiu via RLUG wrote: Ma poate ajuta cineva sa inteleg la ce se uita mariadb (cu engine-ul innodb) cand decide query plan la un query? Problema mea e ca am niste query-uri care se fac mult mai greu pe master fata de slave care au date identice, diferenta fiind ca slave-ul are date refacute dintr-un dump recent (si resincronizat). Query planul arata diferit intre cele doua servere si in trecut cand am mai avut problema asta s-a rezolvat dupa ce am "optimizat" tabelele implicate (cu un alter table force). Stiu eu asa din legendele Olimpului ca planul se face pe baza unor statistici pe indecsi mentinute in background, dar nu m-am lamurit din documentatie unde sunt tinute, cum sa le urmaresc si daca le pot da un sut mai simplu fara sa fac alter care dureaza 10 minute. Am gasit niste povesti despre mysql.innodb_index_stats dar la o prima vedere si aia e replicata si am oricum o jena sa modific chestii pe acolo fara sa inteleg. Also, nu m-am prins daca am vreun mecanism de-a-l convinge pe mariadb sa zica cum a ajuns la concluziile din explain. Ce carti de mysql am prin casa trec mai rapid peste subiectul asta si am o banuiala ca implementarea de innodb din mariadb s-ar putea sa faca lucrurile putin altfel (as putea sa ma dau prin codul sursa dar nu prea sunt familiarizat cu internals, prefer sa intreb inainte). Mersi, ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug_lists.lug.ro
Re: [rlug] query plan mariadb
e poveste lnga cu indecsii, nu numai pe maria, ci si pe oricare alta baza de date, poate pe astea mai enterprise trebuie sa mesteci mai putin, insa din cand in cand tot nu scapi de "mentenanta" presupunand ca indecsii sunt la fel si pe master si pe slave (desi din ce-mi aduc aminte in replicari binare nici nu cred ca se poate altfel), inseamna ca statisticile sunt "outdated" pe unul din ele, si de aia ai query plan-uri diferite (la fel, presupun ca versiunile de maria sunt aceleasi pe master si slave) in principiu un analyze pe tabela/tabele ar trebui sa ajunga; optimize nu e suportat pe innodb, pur si simplu va recrea tabela (actually, cam la fel face si la un alter table add/drop index); ca sa intreb asa: ai multe update/delete pe respectivele tabele incat sa se fragmenteze? (desi indecsii sunt alta mancare de peste) ca idee, in orice query pentru fiecare instanta de tabela (ca poate e de 2 ori sau poate ceva subquery etc) este folosit un singur index, pe care il considera maria mai "atractiv"; de aceea cand vad jde indecsi pe o singura coloana ma uit urat, pentru ca cel mai probabil mai mult de jumatate din ei sunt total inutili; intotdeauna trebuie preferati indecsi compoziti, prin care sa prinzi cam tot ce e where si join, dar aici depinde exact ce query-uri ai si cat de multa memorie iti permiti (asta si vis-a-vis de recomandarile ca toata baza sa fie in innodb_pool, ceea ce - desi corect per se - mi se pare total si absolut overkill); inca ceva, IIRC: daca printr-un index nu pare ca se filtreaza macar 20% din tabela/rezultate, atunci o sa cam faca full table scan poate daca descrii un pic tipurile de indecsi si query (fara a da tot query-ul ca deh, confidential stuff) ne mai vine vreo idee Alex On 23-Apr-24 14:19, Petru Rațiu via RLUG wrote: Ma poate ajuta cineva sa inteleg la ce se uita mariadb (cu engine-ul innodb) cand decide query plan la un query? Problema mea e ca am niste query-uri care se fac mult mai greu pe master fata de slave care au date identice, diferenta fiind ca slave-ul are date refacute dintr-un dump recent (si resincronizat). Query planul arata diferit intre cele doua servere si in trecut cand am mai avut problema asta s-a rezolvat dupa ce am "optimizat" tabelele implicate (cu un alter table force). Stiu eu asa din legendele Olimpului ca planul se face pe baza unor statistici pe indecsi mentinute in background, dar nu m-am lamurit din documentatie unde sunt tinute, cum sa le urmaresc si daca le pot da un sut mai simplu fara sa fac alter care dureaza 10 minute. Am gasit niste povesti despre mysql.innodb_index_stats dar la o prima vedere si aia e replicata si am oricum o jena sa modific chestii pe acolo fara sa inteleg. Also, nu m-am prins daca am vreun mecanism de-a-l convinge pe mariadb sa zica cum a ajuns la concluziile din explain. Ce carti de mysql am prin casa trec mai rapid peste subiectul asta si am o banuiala ca implementarea de innodb din mariadb s-ar putea sa faca lucrurile putin altfel (as putea sa ma dau prin codul sursa dar nu prea sunt familiarizat cu internals, prefer sa intreb inainte). Mersi, ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug_lists.lug.ro
[rlug] force innodb checkpoint la mariadb
Salutare De la MDEV-23855 (maria 10.5.7) maria a devenit mult mai lenesa la facut checkpoint-uri pe innodb. Daca baza e forjata nici nu prea te prinzi, insa daca nu e activitate prea mare atunci te trezesti prin backup-uri cu chestii de genul: [00] 2024-04-10 02:48:02 DDL tracking : create 241 "./racktables/innodb_test.ibd" [00] 2024-04-10 02:48:02 DDL tracking : delete 241 "./racktables/innodb_test.ibd" [00] 2024-04-10 02:48:02 DDL tracking : create 242 "./racktables/innodb_test.ibd" [00] 2024-04-10 02:48:02 DDL tracking : delete 242 "./racktables/innodb_test.ibd" E "normal" ce se intampla, nu asta e baiu, dar e cam stresant la ochi pe alocuri, mai ales cand mai gasesti vreun framework de ala de se apuca sa faca "migrari" pe banda rulanta, si atunci umple vreo 2 pagini cu mesaje de genul. Si persista pana la sf. asteapta (daca nu are serverul activitate astfel incat sa se genereze un checkpoint). Se rezolva cu un restart de maria, dar e prea din topor solutia. So, ca utilizator / admin (deci nu ca developer de mariadb), am vreo sansa sa fortez un checkpoint? Ca am citit MDEV-3, da poate am imbatranit eu ... cine stie, ca nu am inteles nimic concret. Mersi, Alex ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug_lists.lug.ro
Re: [rlug] Exploitul de vineri
daca esti pe stable stai linistit; cel putin momentan, pana cine stie ce ganganii se mai descopera si in versiunile vechi, la ce-am citit zilele astea ma pot astepta la orice si in mod normal n-ar fi trebuit sa fie probleme cu openssh, insa atat debian/ubuntu cat si redhat/fedora au modificat ssh-ul pentru integrare cu systemd, si atunci poof :-P oricum, frumoasa treaba, chiar opera de arta (mai ales discutiile de re-integrare cu fedora); astept cu interes deznodamantul, ca deja pare dintr-un film cu james bond :-D Alex On 30-Mar-24 21:21, Mihai Gaitos via RLUG wrote: (raportat sambata, ca deh, m-am uitat intr-o doara cu gand ca altii mai stiitori ca mine au raportat deja) Salutare lista, Presupun ca multi deja stiti, dar poate nu toti, daca aveti xz 5.6.0 sau 5.6.1 (si *systemd* care injecteaza in sshd >:) ) aveti bonus backdoor in sshd. https://www.openwall.com/lists/oss-security/2024/03/29/4 https://www.theregister.com/2024/03/29/malicious_backdoor_xz/ Cu bine si spor la verificari. ___ 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 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)
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 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)
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)
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)
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)
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)
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 Alex ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug_lists.lug.ro
Re: [rlug] boot de pe un disc clonat cu grub rescue
On 19-Dec-23 09:10, Paul Lacatus via RLUG wrote: Salut La o masina cu proxmox ssd de pe care booteza proxmox a inceput sa dea erori. L-am clonat cu clonezilla pe un disc de dimensiune apropiata . Discul nou porneste in grub rescue . cum fac sa bootez si sa repar grub ? Multumesc Paul salut daca vorbim de proxmox atunci foarte probabil avem de-a face cu lvm sau zfs care mai complica treaba; eventual si cu combinatii de EFI / secure boot care sporesc "distractia" care era configuratia exacta? Alex ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug_lists.lug.ro
Re: [rlug] diff mai diferit
interesanta abordare, si e de retinut pe viitor, insa changed e pe grupul de linii care s-a schimbat, si nu vad cum are sanse sa prinda spre exemplu schimbarea partiala a unei linii anume cred ca in timpul de cautare scriam fix ce-mi trebuie cu serpisoru, dar deh, cica sa nu reinventez roata :-P Alex On 05-Dec-23 20:46, Mihai Osian wrote: On Mon, Dec 4, 2023 at 12:46 PM Alex 'CAVE' Cernat via RLUG wrote: salut poate s-a mai lovit careva de chestia asta si a gasit o solutie simpla si eficienta, pana acum n-am gasit nimic si parca e peste mana sa reinventez roata, daca deja exista si se invarte pe undeva concret: diff-ul, fiind o scula de programare, e all or nothing, aka ori s-a pus linia, ori s-a scos; pe mine m-ar interesa ceva cat mai simplu care sa aiba si optiunea de "s-a modificat" linia respectiva (mdea, aici devine subiectiv, deci preferabil ar fi sa fie cumva configurabila "similaritatea" ... sau poate am noroc si merge din fuleu, pe baza unui criteriu gen daca incepe la fel atunci s-ar putea sa ...) a folosit cineva ceva de genul si poate recomanda? ca nea gogu gpt vad ca minte cam mult in ultimul timp 😛 mersi Alex Daca ai timp si rabdare sa il bibilesti atunci si diff-ul clasic are optiuni de formatare. De exemplu: mike@kermix:~/tmp$ cat a a b c mike@kermix:~/tmp$ cat b a d c mike@kermix:~/tmp$ diff --unchanged-group-format='' --old-line-format='%l' --new-line-format='%l' --changed-group-format='s-a schimbat modificarea, linia %df din A (adica "%<") se facu linia %dF (adica "%>") din B ' a b s-a schimbat modificarea, linia 2 din A (adica "b") se facu linia 2 (adica "d") din B mike@kermix:~/tmp$ Daca vrei si culori se poate inventa o minune de genul (cauta "ansi escape colors", desi deja o ia razna treaba): mike@kermix:~/tmp$ diff --unchanged-group-format='' --old-line-format='\033[0;31m%l\033[0m' --new-line-format='\033[1;35m%l\033[0m' --changed-group-format='s-a schimbat modificarea, linia %df din A (adica "%<") se facu linia %dF (adica "%>") din B ' a b | xargs echo -e s-a schimbat modificarea, linia 2 din A (adica b) se facu linia 2 (adica d) din B mike@kermix:~/tmp$ Sau, cel mai simplu: mike@kermix:~/tmp$ diff -y a b a a b | d c c Mihai ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug_lists.lug.ro
Re: [rlug] diff mai diferit
aproape perfect (nu tineam neaparat la 2 panes, ca trebuie monitor mai mare :-P), oricum infinit mai bine decat diff-ul clasic, poate ma bag prin surse, ca vad ca e python danke shoshon! Alex On 04-Dec-23 14:07, Dumitru Ciobarcianu via RLUG wrote: icdiff On 04.12.2023 13:59, Alex 'CAVE' Cernat via RLUG wrote: mea culpa, am uitat sa precizez ca vreau consola chioara, eventual configurabil cu niste culori la nevoie la fel cum face si diff-ul si nu e doar pentru git, e pentru mai multe chestii, spre exemplu intre recaps de ansible; sau bazdaganii de csv etc. Alex On 04-Dec-23 13:54, valy cozma wrote: daca vrei vizual iti recomand meld daca te referi la whitespaces-urile de la git : https://stackoverflow.com/questions/7310033/how-to-make-git-diff-ignore-space-change-the-default On Mon, Dec 4, 2023 at 1:46 PM Alex 'CAVE' Cernat via RLUG wrote: salut poate s-a mai lovit careva de chestia asta si a gasit o solutie simpla si eficienta, pana acum n-am gasit nimic si parca e peste mana sa reinventez roata, daca deja exista si se invarte pe undeva concret: diff-ul, fiind o scula de programare, e all or nothing, aka ori s-a pus linia, ori s-a scos; pe mine m-ar interesa ceva cat mai simplu care sa aiba si optiunea de "s-a modificat" linia respectiva (mdea, aici devine subiectiv, deci preferabil ar fi sa fie cumva configurabila "similaritatea" ... sau poate am noroc si merge din fuleu, pe baza unui criteriu gen daca incepe la fel atunci s-ar putea sa ...) a folosit cineva ceva de genul si poate recomanda? ca nea gogu gpt vad ca minte cam mult in ultimul timp 😛 mersi 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 ___ 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] diff mai diferit
mea culpa, am uitat sa precizez ca vreau consola chioara, eventual configurabil cu niste culori la nevoie la fel cum face si diff-ul si nu e doar pentru git, e pentru mai multe chestii, spre exemplu intre recaps de ansible; sau bazdaganii de csv etc. Alex On 04-Dec-23 13:54, valy cozma wrote: daca vrei vizual iti recomand meld daca te referi la whitespaces-urile de la git : https://stackoverflow.com/questions/7310033/how-to-make-git-diff-ignore-space-change-the-default On Mon, Dec 4, 2023 at 1:46 PM Alex 'CAVE' Cernat via RLUG wrote: salut poate s-a mai lovit careva de chestia asta si a gasit o solutie simpla si eficienta, pana acum n-am gasit nimic si parca e peste mana sa reinventez roata, daca deja exista si se invarte pe undeva concret: diff-ul, fiind o scula de programare, e all or nothing, aka ori s-a pus linia, ori s-a scos; pe mine m-ar interesa ceva cat mai simplu care sa aiba si optiunea de "s-a modificat" linia respectiva (mdea, aici devine subiectiv, deci preferabil ar fi sa fie cumva configurabila "similaritatea" ... sau poate am noroc si merge din fuleu, pe baza unui criteriu gen daca incepe la fel atunci s-ar putea sa ...) a folosit cineva ceva de genul si poate recomanda? ca nea gogu gpt vad ca minte cam mult in ultimul timp 😛 mersi 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
[rlug] diff mai diferit
salut poate s-a mai lovit careva de chestia asta si a gasit o solutie simpla si eficienta, pana acum n-am gasit nimic si parca e peste mana sa reinventez roata, daca deja exista si se invarte pe undeva concret: diff-ul, fiind o scula de programare, e all or nothing, aka ori s-a pus linia, ori s-a scos; pe mine m-ar interesa ceva cat mai simplu care sa aiba si optiunea de "s-a modificat" linia respectiva (mdea, aici devine subiectiv, deci preferabil ar fi sa fie cumva configurabila "similaritatea" ... sau poate am noroc si merge din fuleu, pe baza unui criteriu gen daca incepe la fel atunci s-ar putea sa ...) a folosit cineva ceva de genul si poate recomanda? ca nea gogu gpt vad ca minte cam mult in ultimul timp 😛 mersi Alex ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug_lists.lug.ro
Re: [rlug] grupuri
apropos, astia sunt "de stat", ca macar sa nu ne intrebam degeaba de ce s-a cam ales praful si pulberea? (nu ca pe la privati ar fi numai lapte si miere, si in plus in ultimii ani pe afara nume sonore si-au furat-o la greu) Alex On 20-Oct-23 12:25, Paul Lacatus via RLUG wrote: Certsign nu au fost in stare sa-si reporneasa sistemele nici azi dupa trei zile de la atac. Asa ca semnatura mea a expirat, token dead! Ca sa se vada rezilienta la atacuri cybersecurity la un furnizor "trused" din Romanica noastra cea de toate zilele. Stiti vreun furnizor din UE cu preturi rezonabile, numar de semnari nelimitat, tot cu token sa imi recomnadati ? Paul On 18.10.2023 19:05, Paul lacatus (personal) via RLUG wrote: Cred ca da! A pornit chat și o operatoare mi-a zis ca nu garantează ca îmi vor face actualizarea în timp util până la expirare ! Pe 18 oct. 2023, la 14:25, Mihai Badici via RLUG a scris: încă negociază :) On 10/18/23 14:09, Petru Rațiu via RLUG wrote: On Wed, Oct 18, 2023 at 1:35 PM Paul lacatus (personal) via RLUG < rlug@lists.lug.ro> wrote: Treaba cu CertSIGN e interesantă ! Trebuiau să îmi trimită procedura de reactualizare a semnăturii electronice care îmi expiră pe 20 și nimic. Telefon nimic, mesaj pe site are eroare . Sunt în incommunicado se pare . Sunt intr-un pseudo-communicado, cam tot ce au zis public e aici: https://www.certsign.ro/ro/certsign-se-confrunta-cu-un-atac-cibernetic-masuri-in-curs-de-implementare-pentru-restabilirea-serviciilor/ (cu amendamentul ca in prima jumatate de ora a fost mentionat si cuvantul "ransomware" care a disparut ulterior, e inca vizibil in screenshoturile facute de hotnews). Pana la reactualizarea semnaturii tale mai au multe chestii mai presante de rezolvat. Ieri au fost deconectati complet de la internet cam 6 ore, pe la pranz au inceput sa raspunda ns-urile, pe seara au restabilit site-ul web si crl-ul. Azi de dimineata a inceput sa mearga ocsp-ul deci e semn ca pki-ul inca mai functioneaza. Sadly webservice-ul care ma doare pe mine cu semnaturi remote e inca pe jos, sunt in proces de a muta diverse institutii de stat romanesti pe furnizori de semnatura calificata cu mai putin "specific romanesc" pentru ca csf, ncsf. La firme surprinzatori de mari de la noi procedura de disaster recovery e un mare "doamne-ajuta". ___ 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] Proxmox vs. VMware ESXi 7
desi intr-adevar poti sa folosesti gratis proxmox-ul (fiind un semi-cobai, insa n-am auzit de probleme), frumos ar fi si o licenta, ca nimic pe lumea asta nu e gratis, si daca n-ar fi destui platitori probabil si calitatea s-ar duce de rapa .. dar deh, suntem romani, asa ca sa nu fiu lupul moralist :-P ca backup merge brici cu PBS, facut tot de ei, in timp ce la vmware e distractiv, te duci la veeam cu portofelul plin, ca asta e viata (desi nu stiu exact cat de suportat este esxi, de obicei se joaca de la vcenter in sus) oricum, daca vrei cu adevarat HA "real-time" trebuie sa lucrezi la nivel de aplicatie (balansari, clustere de baze etc.), altfel vei astepta dupa niste timeout-uri care sunt de ordinul zecilor de secunde ... ceea ce poate e ok, poate nu, depinde de bucataria fiecaruia insa macar in cluster ai live migration (cel putin pentru vm-uri), care mi se pare o bijuterie Alex On 18-Oct-23 19:35, Paul lacatus (personal) via RLUG wrote: În discuție e esxi 7 free și proxmox. Nu se licențiază niciunul dar proxmox permite clustering HA în varianta free pe când esxi free nu știe. La fel backup la pxmx e mai flexibil cu un server de backup . La esxi free nu prea e de loc. Și e ideea de a a face și un cluster în viitor ca se va reface și prelua un serverul pe care vreau să-l mut. Și doi mie soft plătit la grei din asta ca VMware când există un OPenSource rezonabil îmi cam dă urticarie. Trimis de pe iPad‑ul meu Pe 18 oct. 2023, la 19:18, Alex 'CAVE' Cernat via RLUG a scris: nu e proxmox-ul elefant ca vmware (cu jde mii de features), insa isi face destul de bine treaba, plus ca poti sa faci multe hack-uri (gen inclusiv manarit id-uri de vm, care nu se recomanda, insa merge fara belele daca stii ce faci), ceea ce prin vmware ... mai greu, ca nu prea te lasa (ceea ce nu e neaparat rau, ca vorba ceea, cand iti bagi nasul prea adanc s-ar putea sa te "frigi") zfs e excelent, desigur nu e primul in materie de performanta, insa nu pentru asta il iubim noi; daca pui zfs-ul ti-as recomanda sa faci niste teste pe diverse variante de raid sa vezi cat iti mananca un guest dupa instalare / clonare ... s-ar putea sa ramai surprins :-P desi fiind o singura masina as recomanda un raidz2 (echivalent raid6) daca datele si vm-urile respective sunt esentiale (aici tu stii) si binenteles sa fii pregatit in vreo 2-3 ani sa faci upgrade la urmatoarea versiune (ceea ce se face smooth, dar cu downtime la guests); frumos e cand e cluster, dar cu o singura masina, cam greu :-P Alex On 18-Oct-23 19:03, Paul lacatus (personal) via RLUG wrote: Am următoarea dilemă : pe un server IBM mai vechi dar strong vroiam să pun niște servere. Nu merită să pun fără virtualizare ca are resurse suficiente RAM, procesoare, HDD. Eu vroiam să pun un proxmox dar cei care l-au dat l-au dat cu un ESXi 7 cel care e free. Am făcut un VM pe el dar parcă aș fi mai liniștit cu un proxmox. Parcă e mult mai flexibil și poți face mai multe chestii. Deocamdată îmi lipsesc template și clone asta însă înseamnă să mă duc cu stick să instalez? Vroiam să îi pun și raid în JBOD și să fac un pool cu zfs. Ce mă sfătuiți ? ___ 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] Proxmox vs. VMware ESXi 7
nu e proxmox-ul elefant ca vmware (cu jde mii de features), insa isi face destul de bine treaba, plus ca poti sa faci multe hack-uri (gen inclusiv manarit id-uri de vm, care nu se recomanda, insa merge fara belele daca stii ce faci), ceea ce prin vmware ... mai greu, ca nu prea te lasa (ceea ce nu e neaparat rau, ca vorba ceea, cand iti bagi nasul prea adanc s-ar putea sa te "frigi") zfs e excelent, desigur nu e primul in materie de performanta, insa nu pentru asta il iubim noi; daca pui zfs-ul ti-as recomanda sa faci niste teste pe diverse variante de raid sa vezi cat iti mananca un guest dupa instalare / clonare ... s-ar putea sa ramai surprins :-P desi fiind o singura masina as recomanda un raidz2 (echivalent raid6) daca datele si vm-urile respective sunt esentiale (aici tu stii) si binenteles sa fii pregatit in vreo 2-3 ani sa faci upgrade la urmatoarea versiune (ceea ce se face smooth, dar cu downtime la guests); frumos e cand e cluster, dar cu o singura masina, cam greu :-P Alex On 18-Oct-23 19:03, Paul lacatus (personal) via RLUG wrote: Am următoarea dilemă : pe un server IBM mai vechi dar strong vroiam să pun niște servere. Nu merită să pun fără virtualizare ca are resurse suficiente RAM, procesoare, HDD. Eu vroiam să pun un proxmox dar cei care l-au dat l-au dat cu un ESXi 7 cel care e free. Am făcut un VM pe el dar parcă aș fi mai liniștit cu un proxmox. Parcă e mult mai flexibil și poți face mai multe chestii. Deocamdată îmi lipsesc template și clone asta însă înseamnă să mă duc cu stick să instalez? Vroiam să îi pun și raid în JBOD și să fac un pool cu zfs. Ce mă sfătuiți ? ___ 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] random check > 1 luna
On 26-Sep-23 23:43, George-Cristian Bîrzan via RLUG wrote: E okay, se duc toate în spam se duceau, acum dupa un pic de interactiune si ceva trafic incepe gogu incet-incet sa le puna inapoi acolo unde le era locul, aka inbox Alex ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug_lists.lug.ro
Re: [rlug] random check > 1 luna
On 26-Sep-23 17:22, Adrian Sevcenco via RLUG wrote: On 9/26/23 14:51, Alex 'CAVE' Cernat via RLUG wrote: On 26-Sep-23 14:36, Adrian Sevcenco via RLUG wrote: Din ce stiu la raid6 e detectabila notiunea de chunk corupt si se reface (cu repair in loc de check) dar pentru raid1 am inteles ca solutia pentru bit-rot e sa pui sub raid1 un dm-integrity bine am citit si raid6 facut peste dm-integrity dar nu vad rostul Adrian la raid6+ da, pentru ca ai 2+ paritati (presupunand ca raidul e 100% functional cu toate hardurile, daca nu ... cred ca sanatate), insa mai fiecare chunk are si celelate 2 paritati, cu 2 discuri cazute poti sa faci rebuild chiar si in productie ... doar ca iti cam tzatzaie backside-ul ca rebuildul in productie poate dura si mai mult de o saptamana si daca ai un un-recoverable error la ce ai in rest in timpul rebuild-ului atunci chiar ai pierdut tot (poti sa ai nroc si sa lamuresti md-ul ca ce i se pare lui ca lipsestes in mod ne-recuperabil de fapt e ok si apoi sa iti mearga fsck-ul pe ce se vede in sistemul de fisiere si sa ai doar un numar de indouri lipsa) nu vorbeam de refacerea array-ului, vorbeam de integritatea datelor; din 2 paritati cred ca poti sa-ti dai seama care din stripe-uri a luat-o razna si sa corectezi problema (combinatorica + brute force, sau poate o fi ceva mai inteligent), dintr-o singura paritate poti constata doar ca ceva e belit, aka ai cel mult error detection, nu si correction Dupa primele 2x100 TB pierdute acum scot direct din productie md-urile cu 2 discuri picate, dar nu s-a mai intimplat de atunci (era o masina dubioasa cu cablaj dubios la expandere etc) jos cutzu, poti detecta eroarea citind de pe disc, dar nu ai de unde sa stii care date sunt cele corecte de aia la zfs au bagat din start checksumming, acolo integritatea datelor se testeaza chiar on-the-fly si repararea asisderea (cat timp nu esti marele ghinionist sa ti se beleasca fix chunkurile care trebuie :-P); si asta la orice fel de raid, inclusiv mirror; la non-raid, doar stii ca ai pus-o de mamaliga, eventual poate te apuci de brute-force sa reconstitui datele :-D din punctul meu de vedere zfs-ul e irelevant atat timp cat nu exista in kernel .. evident punctul meu de vedere e irelevant, dar sunt multi oameni cu mult hardware in spate care gandesc (si actioneaza) la fel ... pe aceiasi idee in cercul meu "social" ferme de gpu computing cu nvidia au fost inlocuite cu insticturile de la amd ... nu pentru performante este iubit zfs-ul (desi culmea, daca investesti destul in hardware poti obtine rezultate chiar comparabile cu "concurenta"), ci pentru "feature-urile" care le are tu am vazut ca esti pe calea "palariei", afaik ubuntu are support in kernel, iar pe debian ai pachetele de kernel & utils de la proxmox (recompilat kernelul din ubuntu), pe care le folosesc cu succes de cateva versiuni incoace, deci s-ar putea sa fac in curand deceniul :-P in plus tin minte ca acum ani de zile a fost testat la profilul nostru de load-uri si a fost categorisit ca imposibil de utilizat :D noi (cercul meu "social" :) ) folosim un sistem numit EOS, ce e un fel de sistem distribuit de fisiere (ce foloseste fs-uri existente pe masina deci nu raw block deviceuri) ce are si checksumming si stie si modele de redundanta, doar ca are niste quirk-uri ce pentru oameni saraci ca mine (4 PB) il fac un pic detrimental utilizarii, desi ar fi niste facilitati obligatorii pentru siguranta datelor (in fault mode, daca nu gaseste prin cluster un fs pentru recovery atunci blocheaza cel putin write-ul la grupul respectiv de fs-uri) Mno, nu e vineri dar mi-a fost dor de o flama pe aici ... am putea sa mai bagam ca prea e liniste :D pai da, cam liniste pe grupul asta, toata lumea o fi pe fb (sau mai nou noile generatii-s pe tictoci) idem pe la san-uri si (macar) unele hw raid, doar ca pe acolo sunt mai NAS-uri vrei sa zici ? sa san-urile sunt mai multe discuri prin diverse locuri in data center la care au access 1 sau mai multe servere (prin SAS) .. e ca si cum ar fi in carcasa (asa cum in curand o sa fie memoria, gpu-uri, NIC-uri/DPU-uri, NVME etc prin CXL) nope, nas am zis, nas am gandit; bine, sper ca nu m-au pacalit cu terminologia zfs, insa un "scrub" nu vad cum il pot traduce decat ca o operatie de verificare a array-ului (sau plural), poate eventual si ceva rebalansare, daca e cazul au san-urile de la hp (chiar si alea msa mici) de vreo 10 ani cel putin mult sau mai putin "invaluite in magie", ca nu ai acces low level mda, acum 15-20 ani am fost fan la placile raid hw dar dupa niste intimplari (legate si de faptul ca la noi servere pot sa fie in productie si dupa 10 ani) m-am jurat ca nu mai folosesc asa ceva vreodata sunt bune daca urmezi "calea"; daca iesi de pe traseul lor (de exemplu sa te apuci sa pui zfs pe niste hp-uri) deja incepe distractie maxima, i
Re: [rlug] random check > 1 luna
On 26-Sep-23 14:36, Adrian Sevcenco via RLUG wrote: Din ce stiu la raid6 e detectabila notiunea de chunk corupt si se reface (cu repair in loc de check) dar pentru raid1 am inteles ca solutia pentru bit-rot e sa pui sub raid1 un dm-integrity bine am citit si raid6 facut peste dm-integrity dar nu vad rostul Adrian la raid6+ da, pentru ca ai 2+ paritati (presupunand ca raidul e 100% functional cu toate hardurile, daca nu ... cred ca sanatate), insa mai jos cutzu, poti detecta eroarea citind de pe disc, dar nu ai de unde sa stii care date sunt cele corecte de aia la zfs au bagat din start checksumming, acolo integritatea datelor se testeaza chiar on-the-fly si repararea asisderea (cat timp nu esti marele ghinionist sa ti se beleasca fix chunkurile care trebuie :-P); si asta la orice fel de raid, inclusiv mirror; la non-raid, doar stii ca ai pus-o de mamaliga, eventual poate te apuci de brute-force sa reconstitui datele :-D idem pe la san-uri si (macar) unele hw raid, doar ca pe acolo sunt mai mult sau mai putin "invaluite in magie", ca nu ai acces low level Alex ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug_lists.lug.ro
Re: [rlug] random check > 1 luna
On 26-Sep-23 13:14, Adrian Sevcenco via RLUG wrote: Salutare! Am nevoie de un sfat privind executia intr-un interval random centrat pe o durata de timp mai mare de o luna... Sa zic ca exemplu check-ul de raid care sa ruleze la 36 zile +- 6 zile si pentru fiecare raid din masina sa fie diferit Tot ce ma gandesc in acest moment e sa scriu in /var/tmp data ultimului check iar scriptul de cron verifica zilnic conditia pentru un md dat sa aiba ultimul timestamp mai vechi de 30 + $(( $RANDOM % 12 + 1 )) si daca da, scrie time-ul curent si da drumul la checkul md-ului ... E aiurea ce zic? e vreo metoda mai buna de a face asa ceva? (inca mai am servere cu centos 7, deci cam asta ar fi baseline-ul posibilitatilor) o intrebare related: din cate stiu (ca poate e cazul sa-mi fac "upgrade" la info) raid-urile md nu au checksumm-uri (cum e la zfs si la unele modele raid hardware), astfel incat poti cel mult detecta eroarea, nu s-o si rezolvi sau mai nou exista "scrub" cu recovery si la md-uri? (ca folosesc mult prea rar in ultimul timp) Alex ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug_lists.lug.ro
Re: [rlug] debian news
On 07-Feb-23 12:47, Catalin Bucur wrote: O discutie cu ceva legatura cu subiectul: vad ca multe servere incep sa fie "acaparate" din ce in ce mai mult de Ubuntu (in detrimentul Debian), o solutie pe care am ocolit-o cu incapatanare, in primul rand de frica a ce s-a intamplat cu CentOS 😄 Mai exista vreo garantie in momentul de fata ca daca te bazezi pe Debian/Ubuntu/YouNameIt ai sanse mai mari sa nu dispara in viitorul apropiat? debianul are o istorie lnga (printre primele distributii de linux) si este sustinut de o comunitate foarte mare, asa ca in teorie ar trebui sa fie safe ubuntu are in spate o companie puternica (canonical) si au adus inovatii insemnate pe partea de linux (bine, poate nu ca pe banda precum redhat, insa orisicum); insa vad ca incet incet ubuntu cam devine pe bani, ramane de vazut daca pe partea de home & very small business va mai ramane 100% moka (bine, pana la urma e firma comerciala, trebuie sa traiasca si stomacul ei :-) ) oricum, teoria e una, practica e alta, greu de prezis viitorul; dupa pataniile cu centos sufli si-n iaurt; vorba ceea "hope for the best and prepare for the worst" :-P Alex ps: apropos de ce ziceai de "acaparare": debianul ramane traditionalist (stable este stable, dar cam vechiut), in timp ce ubuntu merge mai pe "testing" (ca sa dau un exemplu mizeaza inclusiv pe kernel non-lts, care ma rog, probabil va fi upgradat la un lts de-a lungul vietii distributiei); oricum, dupa cum se stie, sursa primara a ubuntul e debian, cu modificari de pachete atat ca si cosmetizare cat si ca feature-uri ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug_lists.lug.ro
[rlug] debian news
salut si la multi ani pe anul asta :-P! sa-mi fie rushinica, ar fi trebuit sa fiu in stare sa dau raspunsul la intrebare, nu sa intreb, dar sa nu raman ignorant daca la ubuntu pr-ul functioneaza cu motoarele turate (deh, firma mare, comerciala care va sa zica), in schimb pe partea de debian parca trebuie sa sapi ceva ca sa obtii informatii, mai ales despre viitorul distributiei concret, daca pentru stable lucrurile sunt simple (ca nu se modifica prea multe - ca asta e si filosofia debian), anunturile de update-uri si din 2 in 3 luni anuntul de versiune intermediara ajung in schimb pe partea de testing si care este filosofia pe viitor, mi se cam pare ca bate vantul, articole prin diverse surse externe samd ca si exemple: - saptamanile trecute s-a bagat in testing/bookworm python 3.11; macar asta s-a vazut la updates, ca e pachet de baza - "din greseala" am descoperit ca deb 12 va avea php 8.2 (cel putin daca nu o fi ceva catastrofal) - mai nou rsyslog-ul nu mai e instalat ca pachet de baza samd si acum formuland intrebarea: avem debianisti sa recomande vreo sursa (rss, site, mailing list, orice) unde sa gasesc si sa fiu anuntat de schimbarile "majore" (da, stiu, e un termen subiectiv), plus idei despre "planuri de viitor"? ca altfel, dupa cum ziceam, nu e deloc distractiv sa "aduni firmituri" mersi Alex ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug_lists.lug.ro
Re: [rlug] networking:: routing dual-ip host
On 14-Oct-21 08:06, Dan B wrote: H, nu e "up to the kernel" Cand rezolvi un hostname care are mai multe ip-uri, dns-ul de obicei ti le va tot roti ca sa nu te complici tu sa alegi unul random O aplicatie cand se conecteaza, prima data rezolva numele (getaddrinfo) dupa care alege un ip din lista si se apuca de treaba (socket + connect) Daca vrei sa expui adrese diferite ale unui host pentru diversi clienti functie de ip-ul astora, bind views exact, bind views e solutia, la round robin daca cumva ai vreun ip/serviciu neaccesibil va trece la urmatorul ip (dar tine de cum implementeaza aplicatia, in browsere merge) tu vrei un fel de 'geo-dns', deci bind views ftw! Alex ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug_lists.lug.ro
Re: [rlug] optimizari de mysql / mariadb
nope, am incercat, n-a ajutat, cat timp are * in join si varchar/text in tabele tot scuipa in draci tabele temporare si dupa cum ziceam rescrierea query-urilor nu este o optiune valida, ca atat se poate :-( desi imbunatatirea de performante pe teste a fost mai mult decat evidenta ma uit acum peste parametrii optimizorului (care sunt o groaza), insa nu pare sa ajute Alex On 03-Aug-21 15:47, valy cozma wrote: > nu sunt eu prea tare in sql dar am senzatia ca cauti asa ceva : > > https://mariadb.com/kb/en/index-hints-how-to-force-query-plans/ > > > > On Tue, Aug 3, 2021 at 2:40 PM Alex 'CAVE' Cernat wrote: > >> On 03-Aug-21 14:16, manuel wolfshant wrote: >>> On 8/3/21 2:03 PM, Alex 'CAVE' Cernat wrote: >>>> salut >>> mysqltuner >>> >>> >> iti dai seama ca a fost invartit pe fata si pe dos; din pacate ce vreau >> eu e sa modific modul in care executa maria join-urile, tare mi-e ca >> vrabia malai viteazu >> >> cred ca low level scuipa in temporare tot ce are nevoie (produs >> cartezian pe tabele, si daca i-a pus draq sa puna steluta scuipa tot ce >> prinde), si apoi selecteaza din temporar ce are nevoie; presupun ca >> postgresul o face mai inteligent, intai vede ce are nevoie (pk-uri & >> shit) si apoi de abia extrage datele propriu-zise din tabele; adica >> exact ce i-am dat eu mura-n gura mariei cu query-ul "optimizat" >> >> 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 ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug_lists.lug.ro
Re: [rlug] optimizari de mysql / mariadb
On 03-Aug-21 14:16, manuel wolfshant wrote: > On 8/3/21 2:03 PM, Alex 'CAVE' Cernat wrote: >> salut > mysqltuner > > iti dai seama ca a fost invartit pe fata si pe dos; din pacate ce vreau eu e sa modific modul in care executa maria join-urile, tare mi-e ca vrabia malai viteazu cred ca low level scuipa in temporare tot ce are nevoie (produs cartezian pe tabele, si daca i-a pus draq sa puna steluta scuipa tot ce prinde), si apoi selecteaza din temporar ce are nevoie; presupun ca postgresul o face mai inteligent, intai vede ce are nevoie (pk-uri & shit) si apoi de abia extrage datele propriu-zise din tabele; adica exact ce i-am dat eu mura-n gura mariei cu query-ul "optimizat" Alex ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug_lists.lug.ro
[rlug] optimizari de mysql / mariadb
salut m-am lovit de destule ori de urmatorul caz: query-uri in mysql cu numar redus de rezultate in final, dar cu join-uri peste join-uri, inclusiv * pe tabele principale cu tot tacamul de varchar si text, mai pe romaneste bomba nucleara (trecem peste faptul ca sa folosesti * in join e 99.99% semn de oligofrenism, mai ales cand ai si texte care sigur nu vor trebui toate, inclusiv in mizeria de wordpress varianta "sugerata" e tot cu *, nu ca wordpress-ul ar fi un standard in materie de query-uri, poate mai curand invers) bun, ideea e ca rescriind query-ul, selectand intai pk-urile necesare si apoi refacut join-ul, desi arata query-ul ca dupa razboi, ca performanta e ca trecerea de la trabant la avion; insa din pacate rescrierea query-urilor nu este o optiune (life sucks, I know) are cineva vreo idee cum sa-i oferim măriei niste "inteligenta artificiala" in a face planning-ul si executia query-ului (oricat de prost ar fi fost scris) mai cu cap ? ca in afara de a mari in draci tabelele temporare sau a face un ramdisk si a aloca memorie aiurea in tramvai nu am nicio idee, by default mysql/maria cand vede varchar/text prin join scuipa tot pe disc si asta e, incepe distractia postgresul pe de alta parte a mers din fuleu, desi nu-i facusem absolut nicio optimizare, setari default si bazele doar importate din mysql mersi Alex ps: n-am testat pe maria 10.5, desi nu cred ca au facut mega improvment pentru astfel de situatii, situatia e de la origini pana la 10.3 ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug_lists.lug.ro
[rlug] despre zerossl
iertata-mi fie ignoranta :-P, insa daca nu citeam changelog-ul de la acme.sh nici nu auzeam vreodata poate de zerossl.com avand in vedere ca mai nou a fost trecut ca default CA (si la prima vedere nu par chinezi, sa zic ca-si promoveaza produsele neaose), macar un pic de documentare sa fie ... a lucrat cineva cu ei ? sunt ok ? macar letsencrypt are niste 'suporteri' mari in spate, la zerossl feedback-ul personal e zero barat mersi Akex ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug_lists.lug.ro
Re: [rlug] [Rant] Ubuntu 18.04 -> 20.04 do-release-upgrade
cel mai probabil de la vreun update de kernel la cat probabil ai rebutat geamuri ca "paote merge dupa aia" ce mai conteaza un reboot la linux care oricum trebuia ? Alex On 29-Jul-21 15:35, Adi Pircalabu wrote: > root@ubuntu-ap-syd1:~# do-release-upgrade > Checking for a new Ubuntu release > You have not rebooted after updating a package which requires a > reboot. Please reboot before upgrading. > root@ubuntu-ap-syd1:~# > > Got to be that package. *THAT* package, oh-lala! > Care-i pachetul ala minune care vrea reboot inainte de un release > upgrade? Suna retorica intrebarea, dar dupa 10 minute in fata > paharu^H^H^monitorului inca ma macina. O fi grub? Or kernel? Da' las, > hai sa m-apuc sa-i fu^H^H^execut un reboot c-asa zice installer-ul. > Yeah, nah... > ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug_lists.lug.ro
Re: [rlug] http_proxy vs https_proxy
On 10-Apr-21 11:31, Iulian Roman wrote: > dar din pacate asta se intimpla (mai frecvent decit vrem sa credem ) , ceea > ce e destul de ingrijorator ! si toata chestia cu protectia TLS devine > debatable , dar asta e o total alta discutie. pentru ca tls interception sa functioneze din ce stiu trebuie in primul rand ca cineva sa-ti bage pe gat pe device un CA (nu ca ar fi mare branza in mediul enterprise, mai mult, au fost si cazuri - cu mare scandal - la nivel de tari intregi) si cum lista de CA-uri a ajuns mare cat o zi de post, cine sta oare sa se uite de fiecare data sa vada ce "gunoaie" au mai aparut pe acolo? certificate pinning complica mult prea mult treaba, mai ales ca din ce in ce mai multa lume foloseste letsencrypt, caa-ul din dns e o solutie interesanta, insa nu stiu exact cat suport are (sa fim seriosi, nici macar partea de revocation nu stiu cat de serios e tratata de browsere, noroc cu letsencrypt ca expira dupa 3 luni automat :-P) Alex ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug_lists.lug.ro
Re: [rlug] http_proxy vs https_proxy
On 10-Apr-21 10:47, Iulian Roman wrote: > aici probabil ca e diferenta, pentru ca daca https_proxy e exclusiv folosit > pentru trafic https (care oricum e encrypted intre client si end server) , la > ce ma ajuta ? Asa cum am spus in celalat reply singura masura de > extra-protectie este un eventual intercept intre proxy si end server (ceea ce > nu e chiar rau). sincer nu prea inteleg intrebarea, dar o sa incerc sa raspund la ce cred ca ai vrut sa intrebi luand-o de la traian si decebal, proxy-urile au fost "inventate" pentru doua chestii: caching (pe vremea cand banda era ceva scump al naibii) si apoi posibilitatea de a stabili niste acl-uri (in special prin mediile enterprise); apoi s-a adaugat si posibilitatea de a inspecta traficul (virusi & stuff); dupa "explozia" de https in ultimii ani si-au mai pierdut din "stralucire", filtrarea fiind mult mai limitata (desigur, exista tls interceptors, dar daca stai bine sa te gandesti ele reprezinta o violare a ceea ce inseamna https in sine) dupa umila mea parere proxy-urile intra in prezent la ceea ce am putea numi "legacy"; vor mai ramane cu noi destule decenii, dar epoca lor de glorie a cam apus Alex ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug_lists.lug.ro
Re: [rlug] http_proxy vs https_proxy
On 09-Apr-21 23:26, Iulian Roman wrote: > Nu ma intereseaza sa fac ceva anume, e mai mult curiozitatea de a intelege > cum functioneaza si mai ales de ce si cand e indicat sa se foloseasca > https_proxy. Totul a pornit de la o discutie cu un coleg cand testam > conectarea prin Bluecoat (care are rolul de proxy) si l-am intrebat de ce are > setat https_proxy iar el a raspuns ca http_proxy e pentru trafic http si > https_proxy pentru trafic https , ceea ce nu are sens. Apoi am incercat sa > caut pe net explicatii dar nu am gasit ceva foarte concret. > Daca am setat http_proxy si https_proxy, cum se face conectarea clientului la > proxy ? Inteleg ca depinde de client ? > In concluzie , la ce ma ajuta https_proxy si cand e indicat de folosit , ca > eu nu prea inteleg de ce ar trebui utilizat (in special in intranet) ? gandeste-te la urmatoarea paralela: pe geamuri ai niste setari de exploder de proxy-uri (care de fapt sunt cumva "globale"); lasand la o parte exploderul, firefoxul are (sau cel putin avea ultima data cand m-am uitat) propriile setari de proxy, disponibile strict in aplicatie; in schimb chrome-ul le foloseste pe cele de exploder (aka cele "globale") la fel si pe linux au aparut (deja e istorie) acele setari de proxy (http_proxy si apoi https_proxy) care nu sunt nicaieri batute in cuie, insa le poti privi ca "best practices", iar in ziua de astazi orice aplicatie care se respecta ar trebui sa tina seama de ele, dar dupa cum spuneam nu este obligatoriu de ce sunt setari separate pentru normal si secure ? cred ca in primul rand pentru usurinta in configurare, pentru ca asa cum ti-a zis si Petru, proxy-ing-ul de https e un pic mai cu mot, lucrand (dincolo de stabilirea conexiunii) mai mult la level 4 decat la level 7 (asa cum e http-ul simplu); in plus e posibil (dar nu am dovezi si iarasi depinde de implementarea clientului) ca sa faca fallback la http_proxy atunci cand https_proxy nu e definit (dar daca proxy-ul nu suporta connect, atunci ghinion, o sa dea cu virgula) Alex ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug_lists.lug.ro
Re: [rlug] Problema routing
On 29-Mar-21 17:55, manuel wolfshant wrote: > oricum asterisk face fite cind trebuie sa iasa cu mai multe IPuri, dar > asta e alta problema decit cea pusa in discutie oare ? daca nu stie sa faca bind la iesire pe o adresa ip / interfata cum poti sa rutezi mai departe corect avand in vedere ca adresa destinatie este aceeasi pentru ambele iesiri ? procesul de asterisk e acelasi, deci uid-ul e acelasi deci nu te poti baza pe niste reguli, poate doar sa faci un round robin ceva Alex ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug_lists.lug.ro
Re: [rlug] Problema routing
salut tcpdump is your best friend :-P vad ca ai eth1 si eth2, sa inteleg ca eth0 e o alta interfata pe unde ai ruta default aia principala ? ca sa nu te incurci poti sa bagi frumos nume in /etc/iproute2/rt_tables parca, nu cred ca am incercat niciodata doar cu id-ul de tabela, desi cel mai probabil ar trebui sa functioneze, doar ca e mai frumos si mai usor cu "label-uri" in primul rand ar trebui sa vezi daca ai ping in adresa cu problema, pe ambele interfete (si tcpdump te poate ajuta sa vezi daca se duc si vin pachetele pe unde trebuie) mai e o mare problema: tu ai specificat asterisk-ului cu ce adrese sa iasa atunci cand face conexiuni ? ca altfel s-ar putea sa se duca pe interfata principala (eth0) daca acolo e ruta default in tabela default; si fiind in cealalta parte o singura adresa, nu prea vad cum poti sa diferentiezi doar pe baza adresei destinatie pe unde sa faci rutarea Alex On 29-Mar-21 16:30, Mihai wrote: > Salut, > > Am 2 SIP-uri de la vodafone ce conectate prin 2 interfete eth1 si > eth2, as vrea sa leg la asterisk dar am o problema cu o ruta statica. > (ims.vodafone.ro - 81.12.175.68) > > eth1: 10.1.255.2/30 > eth2: 10.30.45.254/30 > > ambelele interfete trebuie sa ajunga la ims.vodafone.ro prin gw lor. > > ip route add 10.1.255.2/30 dev eth1 table 100 prio 100 > ip route add 10.30.45.254/30 dev eth2 table 100 prio 200 > > ip rule add from 10.1.255.2/30 table 100 prio 100 > ip route add table 100 default via 10.1.255.1 prio 100 > > ip rule add from 10.30.45.254/30 table 200 prio 200 > ip route add default via 10.30.45.253 dev eth0.10 table 200 prio 200 > > dar nu am ping catre IMS. > > Sa incerc sa fac markez pachete (connmark si fwmark) ? > > ___ > 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] certificate ssl pe multiple masini
Mersi de raspunsuri ... si daca pentru cultura mea generala am mai citit acum niste info de ssl, sa fac un rezumat la ce am inteles vis-a-vis de subiectul "session resumption" In TLS 1.2+ ai doua variante de session resumption: 1. session ids, trimise de catre server catre client la inceput de handshake (daca binenteles clientul se jura ca stie ce-i aia si cu ce se mananca); la restabilirea conexiunii clientul va trimite session id-ul, si daca din verificarile serverului totul e ok vor putea folosi cheia de sesiune din handshake-ul primordial cum informatiile de sesiune sunt tinute pe server, in caz ca ai mai multe servere trebuie un spatiu comun de stocare; insa daca cloudflare la nivelul la care este o face la nivel de POP inseamna ca nu e chiar asa de nefezabil pe cat credeam (btw: foloseste memcache); in cazul asta nu ai nevoie de vreo alta cheie de criptare decat daca vrei un layer in plus de securitate (cloudflare are, ceea ce inseamna alte chei cu rotatiile de rigoare, insa tine strict de cum stochezi sesiunile, nu de protocolul tls in sine) 2. session tickets, care stau doar pe client, daca nu ma insel e cheia de sesiune criptata cu o cheie pe care doar serverul o stie (alta decat cheia privata "principala" de ssl); partea distractiva e ca pana la tls 1.2 se transmite in clar (totusi, macar informatia este criptata, insa nu face parte din canalul tls); aici nu mai ai nevoie de spatiu comun de stocare, ci doar o cheie care trebuie sa existe pe toate serverele, pentru a putea decripta tichetul de sesiune (si cum aceasta cheie trebuie sa fie rotita cat mai des, iti trebuie un mecanism care sa genereze respectivele chei si sa le faca push catre masini, plus sa pastrezi ultimile x chei pentru clientii mai vechi); desi e mai noua varianta cu tichete, are macar teoretic flaw-urile ei pe partea de forward secrecy, deci de abia pe la tls1.3 isi atinge scopul in concluzie in niciunul din cazuri nu depinde de cheia "primara", pe baza caruia a fost generat certificatul, asa cum ma si asteptam de altfel Alex ps: bine punctat cu intentia protocolului (asta de fapt ar fi argumentul ca probabil imi fac griji degeaba) ... insa una e teoria initiala si alta e practica curenta :-P On 24-Mar-21 16:42, Petru Rațiu wrote: > On Wed, Mar 24, 2021 at 3:33 PM Alex 'CAVE' Cernat wrote: > >> On 24-Mar-21 14:29, Petru Rațiu wrote: >>> In afara de aspectul financiar (care zici ca nu te apasa pentru ca LE), >>> problemele sunt exact aceleasi pe care le-ai avea cand reinnoiesti >>> certificatul/cheia (plus niste chestii dragute daca vrei sa faci session >>> resumption de TLS 1.2+, dar sigur nu faci de-alea ca ai fi stiut de >>> problema). >> ar fi interesant de stiut in cazul mai multor servere cum procedeaza >> clientul pentru session resumption (mai ales pe la tls 1.3 unde s-ar >> vrea 0-rtt), daca o face dupa dns sau dupa ip-ul la care se conecteaza >> ... n-am sapat chiar atat de jos dar ceva imi zice ca depinde de >> implementare >> > Se face un shared cache de care trebuie sa ai grija sa se sincronizeze out > of band (sau te multumesti sa faca fallback la handshake mai explicit), > de-aia ziceam ca daca nu stii explicit de problema asta, probabil nu te > intereseaza :) Probabil ca nici acolo nu depinde de cheia de certificat in > sine dar s-ar putea sa dea cu virgula cand treci de pe un certificat pe > altul si sa pierzi 1-2 RTT-uri (nu m-am mai dat de mult prin TLS internals > si nu tin foarte tare sa reincep acum). > > >> iar in cazul in care nimeresti pe alt server clientul oricum nu va fi >> recunoscut (ca nu e in session cache), indiferent daca cheile si >> certificatele sunt aceleasi sau diferite (decat eventual daca ai o >> tabela globala de cache de sesiuni ssl, ceea ce mi se pare total sf, >> nici nu stiu daca e posibil de implementat, nu mai vorbim de fezabil) >> >> > Daca conteaza asta pentru tine, exact asa se face, cu shared session cache. > Tine ofc de balancer si daca suporta asta. > > > >> ideea era urmatoarea: cu sa zicem mai multe servere distincte pe acelasi >> domeniu, eventual si in locatii diferite (deci fara posibilitatea de a >> avea un unic LB in fata); ai 2 variante: >> 1. fiecare server cu cheile / certificate lui, solutie de tipul fire & >> forget (binenteles cu monitorizarea de rigoare, ca sa nu ai surprize, >> desi s-a vazut la case infinit mai mari :-P); bonus, dupa cum ziceai, >> cheia privata nu paraseste serverul, everybody happy >> 2. o masina suplimentara care sa se ocupe de reinnorea certificatelor, >> pe care apoi sa le distribuie tuturor serverelor; efort in plus, inca o >> rotita care poate sa se blocheze samd, complicatie inutila(?) >> >> intrebarea era de fapt ce impediment ar exista in
Re: [rlug] certificate ssl pe multiple masini
On 24-Mar-21 14:29, Petru Rațiu wrote: > In afara de aspectul financiar (care zici ca nu te apasa pentru ca LE), > problemele sunt exact aceleasi pe care le-ai avea cand reinnoiesti > certificatul/cheia (plus niste chestii dragute daca vrei sa faci session > resumption de TLS 1.2+, dar sigur nu faci de-alea ca ai fi stiut de > problema). ar fi interesant de stiut in cazul mai multor servere cum procedeaza clientul pentru session resumption (mai ales pe la tls 1.3 unde s-ar vrea 0-rtt), daca o face dupa dns sau dupa ip-ul la care se conecteaza ... n-am sapat chiar atat de jos dar ceva imi zice ca depinde de implementare iar in cazul in care nimeresti pe alt server clientul oricum nu va fi recunoscut (ca nu e in session cache), indiferent daca cheile si certificatele sunt aceleasi sau diferite (decat eventual daca ai o tabela globala de cache de sesiuni ssl, ceea ce mi se pare total sf, nici nu stiu daca e posibil de implementat, nu mai vorbim de fezabil) ideea era urmatoarea: cu sa zicem mai multe servere distincte pe acelasi domeniu, eventual si in locatii diferite (deci fara posibilitatea de a avea un unic LB in fata); ai 2 variante: 1. fiecare server cu cheile / certificate lui, solutie de tipul fire & forget (binenteles cu monitorizarea de rigoare, ca sa nu ai surprize, desi s-a vazut la case infinit mai mari :-P); bonus, dupa cum ziceai, cheia privata nu paraseste serverul, everybody happy 2. o masina suplimentara care sa se ocupe de reinnorea certificatelor, pe care apoi sa le distribuie tuturor serverelor; efort in plus, inca o rotita care poate sa se blocheze samd, complicatie inutila(?) intrebarea era de fapt ce impediment ar exista in cazul 1, evident mai simplu; pana acum nu am gasit niciunul (in afara de a "polua" dublu, triplu, etc. lista globala de certificate - dar vorbim de cateva servere, nu de zeci, sute, mii etc) nu am vazut pe nicaieri in recomandarile LE sa ai un singur certificat per domeniu, nu am gasit nimic legat de faptul ca vreun client ar putea stramba din nas ca pentru acelasi domeniu exista mai multe certificate (corect cazul expus de tine cu reinnoirea certificatelor unde nu ai cum sa le faci chiar simultan pe toate masinile); insa intreb, sa fiu sigur ca nu mi-a scapat ceva Alex ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug_lists.lug.ro
Re: [rlug] f33 php :: non-functional dupa disparitia mod_php - SOLVED
On 24-Mar-21 14:54, Adrian Sevcenco wrote: > sigur nu te referi la paginile html salvate de mine in spatiul de web > personal? > > Merci!! > Adrian n-aveam de unde sa stiu ca sunt salvate, sau ca era vreo rutare ceva facuta, ca nu am stat sa fac penetration test, cert este ca in html-urile alea erau niste info-uri "in plus", deci daca le-ai salvat ar trebui sterse, chiar daca e doar paranoia, insa best practice e cu cat mai putine informatii date cu atat mai bine :-P Alex ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug_lists.lug.ro
Re: [rlug] f33 php :: non-functional dupa disparitia mod_php - SOLVED
On 24-Mar-21 14:02, Adrian Sevcenco wrote: > am un acl cu DN-ul certificatului .. eu si colegii (in fapt toata > lumea in contact cu GRID-ul > si cern-ul) avem certificatele personale incarcate in browser si > atunci pentru majoritatea > serviciilor/paginilor de http cu cerc restrans aplic verificarea dupa > dn-ul certificatului > (iar masinile au oricum instalate CA-urile iar ssl-ului apache-ului ii > spun sa se uite la > SSLCACertificatePath-ul respectiv) si mai bine, doar sa ai siguranta ca sunt si activate; eu n-am treaba cu voi (deci cutzu certificat) dar mai devreme m-am uitat linistit prin pagina de status, am vazut path-uri, nume de aplicatii samd; cum am vazut eu poate sa vada oricine, deci de aia zic, chestiile private e bine sa ramana private Alex ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug_lists.lug.ro
Re: [rlug] f33 php :: non-functional dupa disparitia mod_php - SOLVED
On 24-Mar-21 13:16, Adrian Sevcenco wrote: > so... acel proxy in final mi-a atras atentia ... din prea multa > optimizare, > TOATE modulele de proxy erau comentate :))) > > Multumesc!! > Adrian apropos, scoate acel ifmodule cu mod_proxy din configuratie (daca l-ai pus) ... mai bine sa dea 500 pe un php decat sa-l scuipe in clar ca si sursa in cazul in care cumva modulele de proxy ajung din nou comentate iar pagina de status ar trebui sa nu fie publica, macar restrictionata dupa ip, ca nu stii cine se uita Alex ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug_lists.lug.ro
Re: [rlug] f33 php :: non-functional dupa disparitia mod_php
On 24-Mar-21 13:02, Adrian Sevcenco wrote: > On 3/24/21 12:39 PM, Alex 'CAVE' Cernat wrote: >> salut > Salutare! > >> aproape sigur indianu' nu stie sa trimita cererea mai departe catre php >> (care acum prin fpm nu mai e builtin in apache, ci e de sine statator, >> comunicand prin socketul de fastcgi) >> >> vad ca ai un 2.4 de ultima generatie, deci trebuie sa activezi >> proxy_fcgi ca si modul in apache, si apoi sa adaugi ceva de genul in >> vhost / directory / whatever > humm.. ok caut, ar trebuie sa fie pe undeva niste defaults > >> >> >> # Run php-fpm via proxy_fcgi >> >> SetHandler "proxy:unix:/var/run/php5-fpm.sock|fcgi://localhost" >> >> >> >> in exemplul meu se va conecta prin unix socket (care mi se pare cea mai > da, configurarea default e cu sock > grep ^listen /etc/php-fpm.d/www.conf > listen = /run/php-fpm/www.sock > listen.acl_users = apache,nginx > listen.allowed_clients = 127.0.0.1 > >> "normala" modalitate), dar poti daca tii mortis poti sa conectezi si >> prin tcp, inclusiv pe alta masina (daca vrei sa fii haiduc) >> >> verifica in configurarile de php ca socket-ul sa coincida ca path (si ca > care configuratie de php? /etc/php.ini? > sau a httpd-ului? > > in httpd/conf.d/php.conf am asa ceva > presupun ca ai verificat deja ca nu ai mod_php-ul instalat, astfel incat sa ignore configurarea respectiva bucata pare ok, eventual poti sa incerci sa dai copy paste in vhostul default sau pe care il folosesti, ca se pare ca dintr-un motiv sau altul e ignorata (apropos, conf-ul ala de conf.d/php.conf e si folosit ? ca mai nou prin debian au bagat si conf-enabled, la fel ca la module si vhosturi) in rest pare normal ce ai dat, oricum daca era vreo duda cu php-ul trebuia sa dea 500, tie iti afiseaza direct scriptul ca si cum nu ar lua in considerare acel filematch > # Redirect to local php-fpm (no mod_php in default configuration) > > > # Enable http authorization headers > SetEnvIfNoCase ^Authorization$ "(.+)" HTTP_AUTHORIZATION=$1 > > > SetHandler "proxy:unix:/run/php-fpm/www.sock|fcgi://localhost" > > > > > pare in sync nu? > >> face listen pe un unix socket) >> >> Alex >> >> ps: welcome to the 21th century, fpm-ul e de pe la vreo 5.3 parca si isi >> face treaba cu prisosinta, ce-i drept pentru un site accesat din an in >> pasti e un pic overkill la configurare, dar prinde bine ca knowledge > am doar un dyndns facut de mine > https://github.com/adriansev/dyndns_home > pentru masinile de user (cu dhcp privat) ce le mai administrez si > diversele vm-uri > >> pps: daca esti cumva pe geam ai xampp, wamp si alte balarii single > lol, nu .. in general e procedura de cleanup la orice laptop nou ca > maninca spatiu :)) > distro-ul e specificat in subiect, acel anonim (vad) f33 ce vine de la > fedora 33 :) > > Multumesc frumos! > Adrian > > >> click, care iti instaleaza toata suita de lamp (poate si bonus un perl); >> insa asta strict pentru dezvoltare sau utilizare personala sporadica >> >> On 24-Mar-21 12:23, Adrian Sevcenco wrote: >>> Salutare! Aveam si eu o "aplicatie" obosita de php pe desktopul meu >>> si am realizat de curand ca de prin decembrie nu mai e functionala... >>> am descoperit ca mod_php nu mai exista si se foloseste php-fpm >>> ce l-am instalat (era excluded si masked pt ca idea de a avea un >>> serviciu suplimentar >>> pentru 5 linii obosite mi-a parut o prostie) >>> Ok, instalat, unmasked si ruleaza dar o o prostie de genul: >>> >> phpinfo(); >>> ?> >>> >>> e tot nefunctionala (adica imi apare o pagina goala alba la care daca >>> dau view source imi apare >>> codul de mai sus) >>> >>> Pana ma pun pe google ca sa fac trecerea in python (pentru ca nici >>> perl nici java/javascript (acelasi lucru nu :D?)) >>> exista o posibilitate sa fac php-ul sa mearga? >>> >>> server status si info se gasesc aici: >>> https://asevcenc.web.cern.ch/asevcenc/apache/ >>> >>> Multumesc frumos de ajutor! >>> Adrian > > > ___ > RLUG mailing list > RLUG@lists.lug.ro > http://lists.lug.ro/mailman/listinfo/rlug_lists.lug.ro ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug_lists.lug.ro
[rlug] certificate ssl pe multiple masini
daca tot vad ca mai sunt miscari in front pe aici, sa vin cu o intrebare abisala: in cazul in care mai multe masini diferite servesc acelasi domeniu (spre exemplu din motive de geo-load-balancing, sau pur si simplu LB via dns RR), care ar fi partea negativa in faptul ca fiecare server ar avea certificat diferit / cheie diferita ? (vorbim desigur de letsencrypt, ca doar se apuca nimeni de nebun sa cumpere x certificate diferite) desigur, conectarea ulterioara la ACEEASI MASINA vine cu niste posibilitati de resume session samd, dar asta e cu totul alta discutie; cat timp in mod normal cheia publica nici nu ar mai trebui sa fie folosita ca pe vremuri la stabilirea cheii simetrice (ca in douazeci douasunu vrem forward secrecy) incerc sa gasesc un downside in a folosi certificate / chei multiple pentru acelasi domeniu si nu gasesc bine, ar fi certificate pinning, dar sa fim seriosi, letsencrypt (sau in general certificate cu durata scurta de viata) cu pinning deja suna a distractie Alex ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug_lists.lug.ro
Re: [rlug] f33 php :: non-functional dupa disparitia mod_php
salut aproape sigur indianu' nu stie sa trimita cererea mai departe catre php (care acum prin fpm nu mai e builtin in apache, ci e de sine statator, comunicand prin socketul de fastcgi) vad ca ai un 2.4 de ultima generatie, deci trebuie sa activezi proxy_fcgi ca si modul in apache, si apoi sa adaugi ceva de genul in vhost / directory / whatever # Run php-fpm via proxy_fcgi SetHandler "proxy:unix:/var/run/php5-fpm.sock|fcgi://localhost" in exemplul meu se va conecta prin unix socket (care mi se pare cea mai "normala" modalitate), dar poti daca tii mortis poti sa conectezi si prin tcp, inclusiv pe alta masina (daca vrei sa fii haiduc) verifica in configurarile de php ca socket-ul sa coincida ca path (si ca face listen pe un unix socket) Alex ps: welcome to the 21th century, fpm-ul e de pe la vreo 5.3 parca si isi face treaba cu prisosinta, ce-i drept pentru un site accesat din an in pasti e un pic overkill la configurare, dar prinde bine ca knowledge pps: daca esti cumva pe geam ai xampp, wamp si alte balarii single click, care iti instaleaza toata suita de lamp (poate si bonus un perl); insa asta strict pentru dezvoltare sau utilizare personala sporadica On 24-Mar-21 12:23, Adrian Sevcenco wrote: > Salutare! Aveam si eu o "aplicatie" obosita de php pe desktopul meu > si am realizat de curand ca de prin decembrie nu mai e functionala... > am descoperit ca mod_php nu mai exista si se foloseste php-fpm > ce l-am instalat (era excluded si masked pt ca idea de a avea un > serviciu suplimentar > pentru 5 linii obosite mi-a parut o prostie) > Ok, instalat, unmasked si ruleaza dar o o prostie de genul: > phpinfo(); > ?> > > e tot nefunctionala (adica imi apare o pagina goala alba la care daca > dau view source imi apare > codul de mai sus) > > Pana ma pun pe google ca sa fac trecerea in python (pentru ca nici > perl nici java/javascript (acelasi lucru nu :D?)) > exista o posibilitate sa fac php-ul sa mearga? > > server status si info se gasesc aici: > https://asevcenc.web.cern.ch/asevcenc/apache/ > > Multumesc frumos de ajutor! > Adrian > > > ___ > RLUG mailing list > RLUG@lists.lug.ro > http://lists.lug.ro/mailman/listinfo/rlug_lists.lug.ro ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug_lists.lug.ro
Re: [rlug] apache / nginx reload vs restart
On 27-Jan-21 19:36, Petru Rațiu wrote: > Sugestia mea e sa te uiti mai atent la > https://www.nginx.com/resources/wiki/start/topics/tutorials/commandline/ > (in special la diferenta intre SIGHUP si SIGUSR2) si sa vezi cand nu merge, > ce zice mai exact in loguri. In cele mai multe situatii, nu i-a placut ceva > la sanity check-ul pe care il face configului inainte sa faca ceva, poate > fi ceva de la mediul tau local sau cum e pornit. Vezi ca pe la 0.7.ceva > si-a schimbat comportamentul (in mod normal asta e istorie veche dar vad ca > povestesti de apache 2.4 de parca ar fi ceva fresh, deci naiba stie ce-i la > tine pe masina). deja la SIGUSR2 vorbim de schimbare de executabil, ceea ce e mult peste o modificare de configurare; de fapt cautam ceva oficial in care sa zica "poti sa faci reload linistit pentru orice modificare mai putin x", sau eventual sa ai minim versiunea v ca sa mearga altfel ... tot la teste ad-labam ajung si nici acolo nu poti fi sigur 100%, ca nu poti sa faci absolut toate testele ca sa acoperi 100% toate modificarile de care te vei lovi in viata reala Alex ps: faptul ca am dat exemple nu inseamna ca si sunt din prezent, dar daca alte impresii negative nu sunt, ne descurcam cu amintirile din epoca de aur ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug_lists.lug.ro
Re: [rlug] apache / nginx reload vs restart
On 27-Jan-21 18:24, manuel wolfshant wrote: > mie nu mi s-a intimplat vreodata, de cind ma stiu cu apache -- aka > 1999 -- apachectl graceful sa nu fi facut ceea ce trebuie. aici iti dau eu un exemplu: la un apache 2.2 cu chroot din mod_security un simplu reload nu ajungea daca voiai ca fisierele de conf sa ramana strict in /etc-ul de la mama lui insa nu ma refeream in mailul initial la avioane de genul, ci la configuratii "normale" sau uzuale ... iar "belelele" de care stiu era neincarcarea noilor certificate la apache (candva), respectiv ignorarea modificarilor de listen la nginx; poate or fi si altele dar nu-mi aduc aminte sa ma fi lovit de ele Alex ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug_lists.lug.ro
Re: [rlug] apache / nginx reload vs restart
On 27-Jan-21 17:57, Alex 'CAVE' Cernat wrote: > Salut > > Caut pe net si nu gasesc (inca) informatii oficiale ca de la versiunea x > incolo indianu si ruznacu garanteaza ca un simplu reload (aka graceful > la indian) garanteaza ca toate modificarile facute in configuratii vor > fi aplicate. > Si aici ma refer la: > - modificari in lista de module > - modificari in configuratiile de module > - modificari in lista de vhosturi (adaugare, modificare, stergere) > - SI MAI ALES aplicarea noilor chei / certificate (la fel > add/modify/delete), ca de obicei aici e buba - si inca una pe lista: pentru nginx adaugarea de ip-uri/porturi ... desi cumva intra la capitolul vhosturi ruznacul face figuri; la "talpa iute" nu am vazut pana acum probleme la ip-uri/port-uri la graceful > > ca intotdeauna mai bine gadili un buton decat sa dai cu ciocanul, insa > nu peste tot un reload simplu isi facea treaba, si inca nu am un pattern > complet > > la apache 2.4 de la o versiune (care o fi) incoace pare sa functioneze, > insa niste info oficiale ar fi binevenite > > mersi, > Alex > ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug_lists.lug.ro
[rlug] apache / nginx reload vs restart
Salut Caut pe net si nu gasesc (inca) informatii oficiale ca de la versiunea x incolo indianu si ruznacu garanteaza ca un simplu reload (aka graceful la indian) garanteaza ca toate modificarile facute in configuratii vor fi aplicate. Si aici ma refer la: - modificari in lista de module - modificari in configuratiile de module - modificari in lista de vhosturi (adaugare, modificare, stergere) - SI MAI ALES aplicarea noilor chei / certificate (la fel add/modify/delete), ca de obicei aici e buba ca intotdeauna mai bine gadili un buton decat sa dai cu ciocanul, insa nu peste tot un reload simplu isi facea treaba, si inca nu am un pattern complet la apache 2.4 de la o versiune (care o fi) incoace pare sa functioneze, insa niste info oficiale ar fi binevenite mersi, Alex ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug_lists.lug.ro
Re: [rlug] block device level gpt raid1
On 10-Jan-21 8:36 PM, Adrian Sevcenco wrote: > prin urmare as dori sa reusesc sa fac raid1 cu intreg deviceul asa cum > am pe systemele bios/mbr si de aia intreb daca a mai incercat cineva > (bine, nu doresc chiar ff tare ca teoretic esp-ul poate fi modificat > in afara array-ului si apoi la asamblarea de la boot vor fi probleme) > din ce am vazut se practica copierea fisierelor pe toate partitiile luate ca atare; adicatelea desi nu e vreun array (care ar complica probabil configuratia), pe fiecare hard din array ai o partitie de esp, deci se poate boota de pe oricare disc > si un pic divagat dar relativ la subiect, o intrebare teoretica: > pentru raid-uri 6 are vreo importanta daca in loc sa fac raid intre > partitii fac direct intre deviceuri? in afara de erorile de parted&co > care o sa imi zica ca nu exista/nu recunosc tabela de partitie, ar mai > fi vreo problema? daca pana si zfs-ul iti creeaza partitii desi tu ai specificat sa-ti ia tot discul cred ca ar trebui sa-l asculti; pana la urma e o combinatie intre protectie anti-prost (sa nu belesti mbr-ul care de fapt nu mai exista si astfel sa belesti superblocul sau mai stiu eu ce) combinata cu o probabilitate mult mai mica ca vreun alt program sa o dea in balarii ca nu vede o tabela de partitii valida atunci cand tu folosesti discul intreg deci pentru mai putine batai de cap, foloseste partitii Alex ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug_lists.lug.ro
Re: [rlug] prioritate biblioteci php
On 08-Jan-21 4:46 PM, Mihai Badici wrote: >> > Momentan am încercat să redenumesc folderul VObject din php și să > rulez composer install în plugin-ul respectiv. > > Nu a mers. Acum mai e o chestiune, că s-ar putea să am nevoie de el și > în alt plugin ( ăsta e libcalendaring, dar mai există și plugin-ul > calendar care folosește biblioteca asta) vezi ca nu cumva fiecare plugin sa aiba directorul lui separat de vendor, ca path-ul initial era un pic cam ciudat > > O să mai încerc să îl adaug direct la roundcube. > > Oricum, mulțumesc. Eu am ridicat problema tocmai pentru că e oarecum > universală, sigur că biblioteca asta e mai exotică, dar în general > dacă ai o aplicatie care are nevoie de o bibliotecă mai nouă mi se > pare un pic pe dos că întâi caută în php și după aia în vendor , în > viziunea mea ar fi trebuit să fie invers. tocmai de aia prefer organizare pe namespace-uri, adio php_include_path si balarii de genul din 1900 toamna; sa stii sigur ce si cand incarci, si fiecare proiect sa aiba dependintele lui, nu sa se bazeze pe cine stie ce versiuni globale bine, acum de cand cu containerizarea izolarea e mult mai simpla si mult mai buna, insa mai e pana cand toata lumea o sa se apuce de kuberneti sau ce o mai veni in viitorul apropiat, mai ales pentru un server de webmail Alex ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug_lists.lug.ro
Re: [rlug] prioritate biblioteci php
On 08-Jan-21 4:23 PM, Mihai Badici wrote: > în principiu mie mi-ar fi util să am clasele astea disponibile în > roundcube ( să fie aceleași și în main și în plugins) Doar că nu am > știut cum să fac . > > În variantele mai vechi îmi mergea cu php-sabre ( sau cum se numește) > din distribuție. Nu știu exact cum face composer-ul: în roundcube > fișierul config.json nu face referință la sabredav, doar în plugin-ul > respectiv am referința la el. Îmi sugerezi că dacă dezinstalez > php-sabre php va căuta automat în "vendor" ? Încerc un pic mai încolo > și zic :) în principiu toate componentele sistemului meu importă > plugin-urile astea din roundcube, deci ar fi ideal așa că aș avea > structurile consecvente. > da, incearca sa scoti pachetul de debian (care cel mai probabil e vechi) si sa lasi composerul sa-si faca treaba de dependinte si sa genereze autoloadul cu siguranta ca se poate si fara uninstall (heck, e doar php) insa nu pot sa-ti dau un raspuns concret ce si cum fara sa-mi fi bagat surubelnita prin cod sa vad cu ce se mananca ... poate doar daca vreun colistas s-o fi lovit de fix aceeasi problema si deja stie o cale de rezolvare concreta Alex ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug_lists.lug.ro
Re: [rlug] prioritate biblioteci php
On 08-Jan-21 1:58 PM, Mihai Badici wrote:
>
>
> roundcube-ul e și el din surse.
>
> Se pare că dacă vrei să folosești modulul de calendar la justa lui
> valoare ( să poți invita alți useri de exemplu la un meeting)
> VObject-ul pe care îl am eu în debian nu are toate atributele. Deci e
> musai să folosesc sabre ăla, 3.5.3 pe care îl zice composerul.
>
> Aș putea să schimb la roundcube să încarce clasele din altă parte?
> Dacă da, cum?
de aia ziceam ca ori instalez tot din pachete (ceea ce la pachete de
clase php ... personal slabe sanse), ori totul "de la sursa"; din ce vad
tu ai instalat cumva "distribution based", folosind path-urile de sistem
(/usr & friends), de aia banuiam ca ai fi instalat din pachet
vezi daca are referinte de autoload si de unde incarca, si atunci ai
putea sa pui ceva de genul:
"autoload": {
"psr-4": {
"Path\\To\\FQCNDir\\": "app/"
}
}
in exemplul de mai sus tot ce e namespace-ul \Path\To\FQCNDir (aplicatia
"ta") va fi incarcat din directorul app, iar la composer dump-autoload
se va uita el prin vendor si va genera un autoload cat sa incarce la
nevoie si ce e prin vendor
iarasi, vorbesc chestii generale, nu am mai lucrat de mult cu roundcube
ca sa ma uit prin surse, insa dupa cum spuneam prefer ca tot ce tine de
proiect php sa fie intr-un $project_root, iar doc_root-ul sa fie
$project_root/public, asa cum e la moda de la laravel incoace (prima
data si eu am injurat, ca era ceva nou, insa daca te gandesti bine face
foarte mult sens sa nu expui direct decat minimul de surse necesare,
recte front-controllerul si ideal doar atat, restul statice)
mai mult, daca folosesti nginx cu try_files poti sa "ascunzi" si
front-controller-ul intr-un alt director separat, dar aici deja vorbim
de specializari prea mari :-P
Alex
___
RLUG mailing list
RLUG@lists.lug.ro
http://lists.lug.ro/mailman/listinfo/rlug_lists.lug.ro
Re: [rlug] prioritate biblioteci php
ai 2 varianta la php: ori folosesti numai ce-ti da distributia, ceea ce
inseamna ca vor fi chestii mai vechi, insa in general mai stabile, si nu
te trezesti ca se strica ceva ca a facut un third party update si a
explodat; ar trebui sa mearga din fuleu insa nu prea vad de ce te-ai mai
juca cu composerul (ca sa fac o paralela e oarecum cazul in care
instalezi un pachet si dupa aia vii si compilezi o versiune noua din
surse, ceea ce inseamna cam ciorba)
ori privesti vhostul tau ca si un tot unitar, unde ai in vendor toate
dependintele la nivel de clase (desigur ca modulele necesare de php,
daca e cazul vor fi instalate global); in cazul asta instalezi inclusiv
roundcube-ul din surse, nu din pachetul de distributie
in mod normal, de la psr-4 citire, daca folosesti composerul iti va crea
el automat un script autoload pe care sa-l incluzi in scripturile "tale"
(de fapt cu arhitectura actuala ar trebui doar in front-controller, ca
cica nu mai avem jde mii de scripturi de intrare - da, stiu, gluma buna,
trebuia sa o pastrez pentru 1 aprilie); dat fiind ca folosesti
roundcube-ul din pachet, ar trebui sa vezi ce spl_autoload_register are
hardcodat prin el, ca sa vezi de unde-ti incarca clasele
mai e si varianta veche cu include_path, insa mi se pare old school si
de kko, de cand cu namespace-urile de la 5.3 sau 5.4 in sus
de ce exact ai apelat la cocktail de apt si composer ?
Alex
On 08-Jan-21 12:37 PM, Mihai Badici wrote:
> Salut,
>
> Am întâlnit o problemă legată de composer (și cumva am și rezolvat-o)
> doar că aș vrea să pricep cum funcționează.
>
>
> Am un modul de roundcube care folosește biblioteca sabre ( pentru
> formatul ical)
>
> Din ce văd eu în debian buster ( dar problema a tot reapărut de-a
> lungul timpului și în altele) biblioteca default nu conține toate
> clasele pe care le vreau eu.
>
> am la început următoarele incluziuni:
>
> use \Sabre\VObject;
> use \Sabre\VObject\DateTimeParser;
>
> În formatul ăsta plugin-ul plânge după o anume clasă Text.php care
> într-adevăr nu există în VObject
>
> în composer.json plugin-ul are:
>
> "require": {
> "php": ">=5.4.0",
> "roundcube/plugin-installer": ">=0.1.3",
> "sabre/vobject": "~3.5.3"
> }
>
> după ce dau composer install nu se întâmplă nimic însă, aparent el
> caută tot în clasele php-ului .
>
> Dacă adaug un:
>
> include("/usr/share/roundcubemail/plugins/libcalendaring/vendor/sabre/vobject/lib/Property/Text.php");
>
> eroarea dispare, însă apar alte probleme legate de incompatibilitatea
> între vobject-ul de aici și cel din
>
> /usr/share/php/Sabre . Definițiile din php sunt mai vechi decât cele
> cerute de plugin
>
> Soluția mea provizorie și funcțională a fost să copiez manual tot ce e
> în "vendor" referitor la VObject în folderul Sabre de mai sus.
>
> Dar evident e o soluție ciobănească. Interesul meu ar fi ca cel puțin
> tot ce e în roundcube (dacă nu tot ce e php) să folosească versiunea
> actualizată a bibliotecilor sabre, evident fără să stric package
> manager-ul.
>
> Pe scurt: în ce ordine folosește php-ul bibliotecile în cazul în care
> are mai multe versiuni disponibile și cum se procedează să le
> folosești pe cele pe care le vrei tu, unde vrei tu?
>
> Danke,
>
> Mihai
>
>
>
>
>
>
>
> ___
> 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] Killing CentOS (softly)
On 14-Dec-20 8:37 PM, Andrei POPESCU wrote: > În practică destul de mulți o pățesc, tocmai pentru că nu se gândesc că > ar fi o imagine diferită, publicată în altă parte. > > Sau se sperie de „unofficial”? :) cred ca "unofficial" tine mai curand de "legaleza" decat de "suportabilitate"; adica politica "noastra" e "all free", dar pentru ca ai nevoie la instalare de pachete care nu sunt gpl, deci daca le bagam incalcam politica noastra de pachete, fac "altii" (dar tot din familie) niste imagini cu pachete "nepermise" incluse, voi le folositi linistit, doar ca cutzu suport (nu ca nu te-ai putea lipsi de acel suport, doar ca e frumos sa mai si dai ceva, daca tot iei totul pe gratis) Alex ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug_lists.lug.ro
Re: [rlug] Killing CentOS (softly)
On 14-Dec-20 7:53 PM, Mihai Badici wrote: > Oricum se pare că vrând ( pe CentOS) sau nevrând (pe slackware) ne > îndreptăm spre release-ul continuu, după cum ne amenință și Microsoft :) asa daca stam stramb si judecam drept, pana la urma si debianul are rolling ... si nu una, ba chiar doua (testing si sid); unii chiar folosesc testing-ul in productie bine mersi, deci se poate eu personal prefer contractul de x ani ca nu ma voi trezi ca se upgradeaza spre exemplu php-ul de la 7.x la 7.x+1 si draq stie ce bucata bazata pe o functionare anormala nu mai merge ca au reparat-o astia (kidding); desigur, upgrade-ul e mai putin facil, insa bine planificat si cu timp de testare e alta mancare de peste si sa nu mai aduc aminte de "legacy apps", ca incepe lumea sa injure non-stop (si suntem in post) :-P Alex ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug_lists.lug.ro
Re: [rlug] Killing CentOS (softly)
On 14-Dec-20 6:55 PM, Mihai Badici wrote: > îi primește cu pâine și systemd :) pentru cei cu alergie la systemd exista si devuan :-P oricum, daca te apuci sa faci arborele "ginecologic" al lui debian te apuca durerea de cap pana numeri toti "plozii" Alex ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug_lists.lug.ro
Re: [rlug] Killing CentOS (softly)
On 14-Dec-20 6:16 PM, Tiberiu ATUDOREI wrote: > ...ca veni vorbi: pentru minoritatea aflata la intersectia diagramelor Venn > a grupurilor "anti corporate" / "fara redhat si clone" / "fara debian si > clone" / "fara manager de pachete" / "tendinte SM" ...va reamintesc ca inca > mai exista "the good old Slack". Ce RH 8...Slack-ul a ajuns la 14.2. > http://www.slackware.com/ pai 14.2 e listat acum 4 ani, a ajuns rolling distribution si n-am aflat ? (nu ca in ultimul timp m-ar interesat subiectul) desi din ce vad in changelog lucrurile se mai misca pe acolo, insa 4 ani de la ultimul release e al naibii de mult ... Alex ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug_lists.lug.ro
Re: [rlug] nginx time interval
On 21-Nov-20 12:21 AM, Petru Rațiu wrote:
> On Sat, Nov 21, 2020 at 12:02 AM Alex 'CAVE' Cernat wrote:
>
>> salut
>>
>> are careva vreo idee cum s-ar putea scoate ora si ziua saptamanii in
>> variabile de folosit prin conf-ul de nginx ?
>>
>> o idee (doar pentru ora) ar fi de extras din $time_iso8601, insa deja mi
>> se pare cam overkill, implicand aiurea regexp-uri in map, plus ca nu
>> acopera partea cu ziua saptamanii
>>
>> in mod normal mizerii de genul ar trebui facute la nivel superior, dar
>> oare s-ar putea direct in nginx ?
> Daca nginxul ala e compilat cu modulul de lua, foloseste si tu os.date("%H
> %a") sau ce format vrei.
mda, imi trecuse prin gand de lua, insa cum ar zice caragiale, momentan
experienta cu lua e minunata, e sublima, dar lipseste cu desavarsire :-P
dar da, merita studiat subiectul
> In mod normal te-as intreba la ce doamne iarta-ma iti trebuie dar prefer sa
> nu stiu :)
trecand de la dramaturgie la poezie, sa-l citez si pe eminescu: " nu
cerceta aceste legi, caci esti nebun de le-ntelegi" :-P
idei cretze everywhere ...
mersi
Alex
___
RLUG mailing list
RLUG@lists.lug.ro
http://lists.lug.ro/mailman/listinfo/rlug_lists.lug.ro
[rlug] nginx time interval
salut are careva vreo idee cum s-ar putea scoate ora si ziua saptamanii in variabile de folosit prin conf-ul de nginx ? o idee (doar pentru ora) ar fi de extras din $time_iso8601, insa deja mi se pare cam overkill, implicand aiurea regexp-uri in map, plus ca nu acopera partea cu ziua saptamanii in mod normal mizerii de genul ar trebui facute la nivel superior, dar oare s-ar putea direct in nginx ? gogu nu e prietenos la astfel de request-uri :-( 10x Alex ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug_lists.lug.ro
[rlug] bash vs sh
din ciclul "bah, tu n-ai servici" (nea marin miliardar sa traiasca!) tot nu mai fusese de mult flama de vineri o discutie filosofala, bazata pe linux-urile actuale care mai toate au instalat bash-ul (versiune minim 4.0), deci din start zic ca nu mizez pe "suportabilitate" si posix, insa: bash 4 gasesti la orice pas e axioma si acum intrebarea: daca tot bash 4 stie multe si marunte, atunci nu ar mai fi indicat ca toate scripturile relativ simple posibile (gen monitorizare & stuff) sa foloseasca noile (desi vechi de ani) facilitati din bash 4 ? cu alte cuvinte de ce in ziua de azi m-as chinui cu sed-uri, grep-uri si awk-uri si alte marafeturi de genul cand bash-ul are builtin marea majoritate a functiilor respective (vorbim de chestii relativ simple si mai ales pe maxim cateva zeci de linii de output de procesat) ok, sunt de acord ca /bin/sh are vreo 120k (si asta ca e de fapt dash), iar bash-ul peste un mega, insa fork-urile si executia la mai stiu eu cate grep-uri si awk-uri costa si alea ... da, stiu, teoria chibritului dar e vineri si pe vremuri era la moda Alex ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug_lists.lug.ro
Re: [rlug] Dns for acme challenge
In afară de faptul ca e făcut de un chinez (care săracul probabil are degeaba frigiderul plin din cauza jocurilor geopolitice de la nivel înalt) acme.sh își face treaba cu prisosință și de când îl știu vine cu pluginuri sa faci ce vrei și ce nu vrei, având nevoie doar de un curl/wget (și poate un socat pe alocuri). Certbot ar fi doar pentru ca ar fi scris cică in limbaj mai evoluat (deja fițe). Insa pe partea de dns challenge bind + nsupdate nu mi se pare o soluție prea granulara, de aia și caut înlocuitor. Bine pana la urma merge și o soluție in-house care sa poată scrie într-o baza de date comuna cu serverul dns, însă dacă roata deja o exista, de ce sa o mai redescoperi? On Sun, 12 Jul 2020, 14:10 Catalin Muresan, wrote: > Eu am făcut cu clientul lego care știe multe dns apis și am folosit BIND cu > dezavantajul că trebuie să pui în config exact adresele IP de unde faci > update. > > Alege un dns provider de la cei suportati > > https://github.com/go-acme/lego > > Opțiunea 2 e terraform cu dns și acme și ce suporta terraform > > On Sun, 12 Jul 2020, 13:26 Alex 'CAVE' Cernat, wrote: > > > Salut > > > > O recomandare de un server dns prin care sa se poată face dns challenge > la > > letsencrypt, sa fie destul de granular, sa aibă un api gen http și sa fie > > suportat de acme.sh/certbot? > > > > Powerdns nu prea e granular și parca e mult prea mult pentru doar câteva > > zone, acme-dns parca e prea granular cu uuid-urile lui (deși pana acum > pare > > cea mai interesanta soluție)... > > > > 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 > ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug_lists.lug.ro
Re: [rlug] Dns for acme challenge
Probabil se bazează pe nsupdate care funcționează, dar nu e chiar asa granular (sau poate nu am studiat destul, dar mai bine scot de tot bind-ul din ecuație). Nu mi-e frica de api http, ba chiar m-am lovit de un caz în care chiar ar fi de preferat unui nsupdate. Bine, dacă serverul de dns ar ști și de înregistrări efemere, cu atât mai bine 😛 (nu m-am uitat prin sursele de la acme=dns dacă are asa ceva, însă pluginul doar adaugă, la șters nu face nimic) On Sun, 12 Jul 2020, 13:44 Petru Rațiu, wrote: > Uitandu-ma la pluginurile de DNS mentionate in documentatia de certbot la > https://certbot.eff.org/docs/using.html#dns-plugins , singurul care pare a > merge cu nameserver self-hosted ar fi certbot-dns-rfc2136, care are in > manpage un exemplu cu BIND, dar probabil merge cu orice implementare de > dynamic dns. Vezi poate te scoti fara api http. > > -- > P. > > On Sun, Jul 12, 2020 at 1:26 PM Alex 'CAVE' Cernat wrote: > > > Salut > > > > O recomandare de un server dns prin care sa se poată face dns challenge > la > > letsencrypt, sa fie destul de granular, sa aibă un api gen http și sa fie > > suportat de acme.sh/certbot? > > > > Powerdns nu prea e granular și parca e mult prea mult pentru doar câteva > > zone, acme-dns parca e prea granular cu uuid-urile lui (deși pana acum > pare > > cea mai interesanta soluție)... > > > > 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 > ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug_lists.lug.ro
[rlug] Dns for acme challenge
Salut O recomandare de un server dns prin care sa se poată face dns challenge la letsencrypt, sa fie destul de granular, sa aibă un api gen http și sa fie suportat de acme.sh/certbot? Powerdns nu prea e granular și parca e mult prea mult pentru doar câteva zone, acme-dns parca e prea granular cu uuid-urile lui (deși pana acum pare cea mai interesanta soluție)... Alex ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug_lists.lug.ro
Re: [rlug] Ferma de masini
Arunca un ochi și pe șopârlă (lizardfs) On Sat, 4 Jul 2020, 01:43 Petre Mihail, wrote: > Salut! > Am mai multe masini prin ograda de diferite config uri, capacitati, viteze > de lucru, etc. Am ceva vin nebaut ca energizant, timp si ceva minte libere > ca sa experimentez. Pot sa fac un volum mare adunand drive urile fiecarei > masini, si cum? Orice hint este este binevenit! M-am documentat ceva dar nu > prea stiu dupa ce sa il intreb pe Gogu. Ma inteleg acceptabil cu Debian si > CentOS. Multam! Servus! Petre Mihail > PS. stiu ca este de offtopic dar: Vodafone=UPC stiu, dar VF = Digi? Vad ca > tot Andreea raspunde si la Digi. > ___ > RLUG mailing list > RLUG@lists.lug.ro > http://lists.lug.ro/mailman/listinfo/rlug_lists.lug.ro > ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug_lists.lug.ro
Re: [rlug] Plan de migrare Centos 6 -> Centos 7
On 30-Jun-20 11:16 AM, Dumitru Moldovan wrote: > E cumva videoul ăsta de o oră jumate împărțit în segmente? > https://www.ansible.com/resources/webinars-training/introduction-to-ansible > > > Atinge maxim Ansible Roles și Ansible Tower. mdea, sa traiasca marketingul, ce frumos sa dai moka time limited ceea ce deja e oricum moka in alta parte :-( oricum, e de urmarit pentru cultura generala (ma rog, mai putin formatul yaml din video care e actual nerecomandat, daca nu chiar deprecated - sau soon do be), daca bagau mai mult de tower ar fi fost si mai interesant (cel putin pentru mine) dar pentru cei ce vor sa invete atinge cam toate chestiile de baza, fiind un punct bun de plecare Alex ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug_lists.lug.ro
Re: [rlug] Plan de migrare Centos 6 -> Centos 7
On 29-Jun-20 6:18 PM, Dumitru Moldovan wrote: > În cazul de față nu e alegerea mea pe ce sistem de operare trebuie > instalate și configurate chestii… E vorba de testare automată pentru > toate platformele suportate de un anumit produs. Windows nici măcar nu > e cea mai exotică țintă, mă bucur că am scăpat recent de monștri precum > Solaris, AIX ori HP-UX. pentru cei interesati azi e ultima zi la liber la curs introductiv de ansible: https://www.redhat.com/rhtapps/promo-do007 insa cand zic introductiv, zic pe bune ... eu unul am dat la greu pe fast forward, insa pentru cei care de abia ating subiectul mi se pare ok Alex ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug_lists.lug.ro
Re: [rlug] Plan de migrare Centos 6 -> Centos 7
On 29-Jun-20 12:35 PM, Dumitru Moldovan wrote: > Tot cumva la subiect… Am inclusiv câteva VM-uri cu Windows cu un setup > asemănător, până acuma am folosit Salt. A fost un pic de chin pentru > noi, că-s cam bâtă în privința administrării Windows, dar funcționează > relativ bine, cu doar câteva bug-uri Salt minore, pentru care am găsit > alternative. Are cineva idee de cât de bun e suportul Ansible pentru > administrarea de sisteme Windows? Eventual în comparație cu Salt? > Mulțumiri anticipate! din ce stiu (cultura generala dar pe care nu stiu cat de mult te poti baza) ar suporta cu succes si geamurile, dar cum nu am avut nevoie nu pot sa las niciun fel de feedback mai curand as paria pe partea de echipamente de retea (switch-uri, routere etc), unde are o groaza de module pentru o gama larga de device-uri oricum, pe partea de linux/ansible mai toata lumea se orienteaza fie spre redhat/centos (ca de ceva vreme ansible e marca redhat), fie spre debian/ubuntu; asta nu inseamna ca nu poate merge pe orice linux, insa marea majoritate a "galaxiei" ansible trateaza explicit mai ales particularitatile distributiilor mai sus aminte Alex ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug_lists.lug.ro
Re: [rlug] Plan de migrare Centos 6 -> Centos 7
On 29-Jun-20 1:30 PM, Dumitru Moldovan wrote: > On Mon, Jun 29, 2020 at 01:12:04PM +0300, Alex 'CAVE' Cernat wrote: >> Scrie atât în documentație cât și pe ecran când îl instaleaza, nu e >> nimic >> pe la spate. Doar ca nu e ceva ce tu ai instalat EXPLICIT! > > Ok, de înțeles. Dar ideea e că ce am în repo-ul cu regulile Salt / > Ansible / etc. e persistent, pe când output-ul ce zboară doar la mine > pe ecran o singură dată la prima aplicare e ceva volatil. Un fel de > „verba volant, scripta manent” în accepțiune IT. > > De gustibus… :-] > m-am uitat acum prin documentatie si nu pare sa scrie ca se auto-instaleaza, dar modulul de python-apt / python3-apt e trecut ca si dependinta; mai mult chiar, daca faci doar check va da eroare ca nu e instalat si nu va trece mai departe avand in vedere ca apt-ul e unul din modulele fara de care nu poti trai pe Debian, n-as putea sa zic ca acest side-effect e chiar suparator, ba chiar dimpotriva ... doar sa stii de el ca exista (cred ca mai nou l-am bagat si ca default in lista pachetelor de instalat, sa scap de o grija :-P) altele sunt chestii mult mai stresante, de genul: atentie mare la roluri / task-uri incluse cu when, ca handler-urile "mostenesc" when-ul, si s-ar putea sa te trezesti ca in anumite cazuri nu se executa, desi din punctul de vedere ai unei programari iterative ai zice ca totul e ok... Alex ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug_lists.lug.ro
Re: [rlug] Plan de migrare Centos 6 -> Centos 7
Scrie atât în documentație cât și pe ecran când îl instaleaza, nu e nimic pe la spate. Doar ca nu e ceva ce tu ai instalat EXPLICIT! On Mon, 29 Jun 2020, 13:08 Dumitru Moldovan, wrote: > On Mon, Jun 29, 2020 at 12:58:39PM +0300, Alex 'CAVE' Cernat wrote: > >Ca exemplu, modulul ansible de apt are nevoie de python-apt sau python > >3-apt pe client. Dacă nu îl ai deja instalat, ți-l instalează. Altul nu-mi > >aduc aminte momentan, dar am lăsat rezerva. > > Ah, ok, mulțam! Bine de știut… Mi se pare de prost gust să instaleze > el chestii de capul lui, dar poate îs mai de modă veche. Salt doar îți > zice ce-ți lipsește sau ți-ar prinde bine. > > > ___ > RLUG mailing list > RLUG@lists.lug.ro > http://lists.lug.ro/mailman/listinfo/rlug_lists.lug.ro > ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug_lists.lug.ro
Re: [rlug] Plan de migrare Centos 6 -> Centos 7
Ca exemplu, modulul ansible de apt are nevoie de python-apt sau python 3-apt pe client. Dacă nu îl ai deja instalat, ți-l instalează. Altul nu-mi aduc aminte momentan, dar am lăsat rezerva. On Mon, 29 Jun 2020, 12:37 Dumitru Moldovan, wrote: > On Sun, Jun 28, 2020 at 04:31:37PM +0300, Alex 'CAVE' Cernat wrote: > > […] > > >toate astea cu absolut nimic instalat in plus pe "client", decat un > >acces ssh si python-ul, care oricum e instalat by default din ce stiu eu > >cam pe orice distributie de linux (si pe alocuri vreo 2-3 pachete de > >python instalate automat de catre ansible la momentul necesar). > > Err… nope. Tocmai m-am apucat să învăț Ansible și am început cu niște > VM-uri cu Alpine Linux, pentru că acolo oricum aveam probleme cu Salt > în ultima vreme. Python nu e instalat implicit și pun pariu că Alpine > nu e o excepție în privința asta. > > Dar chestia de mai sus e minoră. Ce mă miră mai tare e e chestia cu > „2-3 pachete de python instalate automat”. Deocamdată n-am văzut așa > ceva… Face Ansible chestii din astea pe la spate? Nu-s expert nici în > Alpine, dar modulele de Python împachetate apk par să aibă toate nume > ce încep cu „py”. N-am asemenea pachete pe VM-urile configurate prin > Ansible să funcționeze ca clienți NFS, Zabbix și Buildbot, deci un > setup nu foarte, foarte simplu. > > Tot cumva la subiect… Am inclusiv câteva VM-uri cu Windows cu un setup > asemănător, până acuma am folosit Salt. A fost un pic de chin pentru > noi, că-s cam bâtă în privința administrării Windows, dar funcționează > relativ bine, cu doar câteva bug-uri Salt minore, pentru care am găsit > alternative. Are cineva idee de cât de bun e suportul Ansible pentru > administrarea de sisteme Windows? Eventual în comparație cu Salt? > Mulțumiri anticipate! > > > ___ > RLUG mailing list > RLUG@lists.lug.ro > http://lists.lug.ro/mailman/listinfo/rlug_lists.lug.ro > ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug_lists.lug.ro
Re: [rlug] Plan de migrare Centos 6 -> Centos 7
Salut In primul rand cum se zice la noi "la mulțean!", deci o sa ma limitez azi la a face mega polemici :-P Asimov vs. Herbert, coca coca vs. pepsi, push vs. pull ... subiecte mai mult sau mai putin filosofice de discutat la un pahar de vorba ... Polemica intre push si pull e mare si pe internet, dar am gasit un "landmark" care, vorba poetului, "face sens": pentru chestiile statice si cvasi-statice push, pentru chestii dinamice si mega-dinamice pull. Sau eventual direct best of both worlds, dupa gusturi. La push (cel putin pentru ansible) ai sarit totusi peste o chestie mega-importanta, si anume idempotenta. Daca ai dat definitie de push/pull, sa dau si eu una: idempotenta => rezultatul final ar trebui sa fie acelasi fie ca rulezi o data, de doua, de zece ori sau de mii de ori aceeasi chestie. Singura chestie ar fi sa nu o rulezi de 2 ori in paralel in acelasi moment, ca in unele cazuri s-ar putea sa dea cu virgula (in conditiile in care se fac si modificari la momentul respectiv). La fel, nu conteaza ca e un server, ca sunt 10, 100, 1000 sau chiar mai multe, nu te apuci tu sa intri pe fiecare, ci face CM_push-ul pentru tine, cel mai probabil in paralel. Desigur, de la un punct in colo (mii / zeci de mii de masini) un sistem pull posibil poate scala mai bine pentru ca workloadul se imparte per interval (nu se executa job-urile in acelasi timp), doar ca incepi sa pierzi controlul in ceea ce priveste CAND se intampla lucrurile, ceea ce s-ar putea conteze, s-ar putea sa nu. In plus la un sistem pull se vor consuma resurse inutil de fiecare data cand verifica configuratiile locale, chiar daca TU stii prea bine ca nu s-a facut nicio modificare (in schimb e o metoda in plus de detectie ca cineva de-al casei sau nu neaparat si-a bagat nasul pe unde nu trebuia - ma rog, nu o metoda pe care sa te si bazezi ca intrusion detection). Iar aia cu "am facut eu asta, tu faci aia", cat timp exista un uber-scenariu (sau mai multe) nu-si are sensul, in acel uber-scenariu ai definit tot ce misca (binenteles, totul definit granular, ca sa poti rula pe bucati). Pentru ca exista idempotenta, ajunge sa rulezi bucata de care ai nevoie (poate sa fie acel uber-playbook, sau doar unul sau mai multe bucati / roluri, sau doar un simplu task, si asta pe un singur server, un grup de servere sau ce vrei, libertatea fiind deplina). Cum iti organizezi bucataria, iarasi, depinde de bucatari. In fine, o discutie de genul push/pull nu cred ca se poate termina vreodata, ambele variante au plusuri si minusuri si din fericire e loc pentru ambele pe lume. Insa pentru cultura mea generala as fi curios cum vezi tu urmatorul scenariu pe varianta "pull" (ca pe push ar fi doar o insiruire de task-uri cu niste parametri): - update sa zicem de kernel la un "cluster" de 12 (sau 24, sau 100, cate vrei) sa zicem in spatele unor LB, cu reboot inclus, astfel incat sa nu fie mai mult de 1 (2, 5, 10, 20 ...) server(e) down la un moment dat (ca altfel s-au dus naibii performantele clusterului) si in worst case de 1, 2, 3, x erori sa se opreasca toata procedura (aici puristii cu containere ar zice clar - ma rog, NU la update de kernel, ca nu e cazul: deploy new containers and dispose old ones, ca asa e treaba in 2020) sau daca iti place mai mult ideea cu un cluster de măria cu 3, 5, 7, 9, x servere be my guest ... ideea e ca doar un numar limitat de servere pot fi afectate la un moment dat, iar procedura sa se poata opri automat atunci cand erorile trec de un anumit prag Alex On 28-Jun-20 5:06 PM, Petru Rațiu wrote: > On Sun, Jun 28, 2020 at 4:33 PM Alex 'CAVE' Cernat wrote: > >> Si nu stiu ce-l deranja pe Petru ca e push, pentru ca pana la urma tu >> decizi cand vrei modificarile, nu cand "vrea muschiul serverului" (de >> asta am injurat puppet-ul la inceput, pe urma au bagat si partea de >> meckanize). > > Asta e tot clenciul: nu vreau sa fac eu lucrurile _acum_, vreau sa descriu > la un moment dat cum sa fie si ele sa se aplice continuu pe servere as > needed. Push inseamna ca lucrurile le triggerezi tu pe server ad-hoc, care > server trebuie sa fie available si intr-o stare care sa poata prelua > schimbarile alea. Pull inseamna ca nu ma leg eu la server, daca maine fac > altul va face fix acelasi lucru, fara sa trebuiasca sa-mi aduc aminte sa-i > zic eu ce e de facut. Also, cand ai cateva zeci-sute-mii de servere, vrei > sa-si faca ele in paralel treburile, nu sa te duci pe fiecare (plus ca e > mereu unul care e down for maintenance si trebuie sa-l tii minte si sa > revii cand e cazul etc). Also cand lucrezi in stil push incepi sa ai > probleme de coordonare cand sunteti mai multi "ai facut tu aia, o fac eu, > etc". Nu zic ca nu se poate dar scula nu te incurajeaza sa evoluezi in > directia asta, e pe abordarea "un baiat cu 5 servere". Cand sunteti 5 si > sunt cateva sute iti
Re: [rlug] Plan de migrare Centos 6 -> Centos 7
Sincer, s-ar putea sa-ti bati cuie multe in cap la inceput pana cand vei
incepe sa intelegi cum functioneaza, dar overall o sa ai numai de
castigat, mai ales cand ai categorii de servere / servicii cu
configuratii comune (sau parametrizate). Insa daca ai fiecare server cu
motul lui, atunci s-ar putea sa te incurce mai mult decat sa te ajute
(sau eventual sa il aplici doar la chestiile comune), insa cand ai macar
3 "de alea", 3 "de alelalte" samd, folosind un "configuration manager"
te ajuta mult si sa eviti pe cat posibil acele "subtle differences" (sau
nu neaparat subtile, ca faci pe 2 din 3 modificari la cine stie ce
config si dupa aia te intrebi de ce merge cu virgule).
Dupa cum vad eu ca merge IT-ul, scripturile de instalare a serverelor nu
prea mai sunt la moda, ci se merge pe definirea "starii" dorite a
sistemului / serviciilor, intr-un format descriptiv (de obicei yaml).
Cum se face la "low level" nu te intereseaza, si da, aici pe alocuri
ansible poate sa devina lent (unii ar zice "ca porcul"), insa ai
garantia ca dupa ce ai rulat task-urile respective (daca le si scrii
bine) pachetele si configuratiile sunt asa cum trebuie sa fie,
serviciile au fost restartate la nevoie samd. Nu zic ca m-am lovit de
buguri idioate (care nici macar nu sunt catalogate ca buguri, ci "asa
functioneaza"), dar trecem peste. Si cat timp nu rulezi efectiv ceva nu
ai nicio amprenta de idle, ca nu exista serviciu sa ruleze pe clienti.
Si nu stiu ce-l deranja pe Petru ca e push, pentru ca pana la urma tu
decizi cand vrei modificarile, nu cand "vrea muschiul serverului" (de
asta am injurat puppet-ul la inceput, pe urma au bagat si partea de
meckanize). Singurul scenariu la care ma gandesc ca ai nevoie de pull e
atunci cand vrei sa automatizezi total instalarea unui server fizic (si
sa incluzi un script de post-install), altfel se reduce la 1) push
creare / instalare / clonare de vm / lxc container 2) rulare config
management, ambele in principiu posibile ca task-uri in ansible. Si
toate astea cu absolut nimic instalat in plus pe "client", decat un
acces ssh si python-ul, care oricum e instalat by default din ce stiu eu
cam pe orice distributie de linux (si pe alocuri vreo 2-3 pachete de
python instalate automat de catre ansible la momentul necesar).
Oricum, ce merge acum, aproape garantat ca peste 5-10 va trebui sa-ti
bagi surubelnita pana la capat, dar macar vei avea un punct de plecare
cu "inventarul". Pana atunci poti avea la nevoie un server nou
functional in maxim minute / zeci de minute (bine, nu vorbim aici de
mega importuri de date, ca atunci se impute treaba). Ca de fapt asta e
toata smecheria cu "configuration managementul": sa ai chestii comune
aplicabile la mai multe servere, altfel ... mai rau te complici si mai
rau pierzi timpul.
Si ca sfat: inainte de rularea pe server fizic poate n-ar fi rau sa
testezi pe o masina virtuala (o data, de doua, de zece ori pana iese
perfect). E mai simplu de refacut, mai ales daca hypervizorul suporta si
ceva snapshot-uri.
Alex
On 28-Jun-20 3:51 PM, Adrian Popa wrote:
> Planul meu era sa ma ajut de ansible pentru taskuri relativ repetitive post
> OS-upgrade. De exemplu, instaleaza cacti versiunea X, sau upgradeaza cacti
> versiunea Y. Am suficient de multe servere vechi in ograda cat sa merite
> investitia de efort. Chiar daca fiecare server e facut de capul lui, e o
> oportunitate buna sa le mai unific configurile.
>
> Ce-i drept, post install nu cred ca orice modificare o sa se faca via
> ansible (obiceiuri vechi), ci tot cu shell, dar ma gandesc ca daca fac
> backup de config/chestii modificate si fac restore la upgrade cu ansible,
> ar putea sa mearga si pe termen mai lung, chiar daca nu e 100% clean/the
> ansible way.
>
> Oricum e mai bine decat sa fac server cu server si sa nu ramana nimic
> documentat post upgrade, ca peste 5-10 ani sa o iau de la capat...
>
> Daca trimit trafic din productie in server si nu merge, asta e - castig
> experienta si vad ce am uitat, se imbunatatesc scripturile, workflow-ul,
> etc. Toata lumea castiga (mai putin end userul).
> :)
>
>
> On Sat, Jun 27, 2020 at 1:55 PM Andrei POPESCU
> wrote:
>
>> On Vi, 26 iun 20, 14:51:09, Adrian Popa wrote:
>>> P.S. De la Centos 7 la 8 există upgrade path, sau e aceeaşi problemă?
>> Oare
>>> pe Ubuntu de ce se poate şi pe CentOS nu? Sau intrăm în holy flame war?
>>> Mersi!
>> Ubuntu probabil moștenește (mai mult sau mai puțin) actualizarea "in
>> place" de la Debian.
>>
>> În Debian orice pachet *trebuie* să suporte actualizare "in place" de la
>> versiunea "stable" precedentă ("oldstable")[1][2].
>>
>> Excepții se admit doar în cazuri speciale[3], care ar trebui să fie
>> documentate în Notele de lansare (Release Notes) și/sau NEWS.Debian
>> (afișat automat dacă pachetul 'apt-listchanges' este instalat).
>>
>> Versiunile pachetelor din Ubuntu (LTS) posibil/probabil să nu corespundă
>> 1:1 cu cele din Debian "oldstable"/"stable". În caz de diferențe depinde
>> de Ubuntu să testeze și, dacă este cazul,
Re: [rlug] hardlink shits
Ma uitam după posibile soluții de deduplicare la nivel de fișier (ca la nivel de bloc de date nici măcar zfs 0.8 nu e încă soluție viabilă) cu posibilitatea de a copia/backup-a prin rsync păstrând maparile de hard link dar și fără a omorî memoria și deci serverul nici pe sursa nici pe destinație când se aduna milioane de fișiere. Pana acum la ce am testat nu am văzut diferențe de memorie între cu și fără -H, sincer ma întreb dacă respectiva opțiune a fost luată în considerare. On Wed, 9 Oct 2019, 16:51 Petru Rațiu, wrote: > On Wed, Oct 9, 2019 at 4:31 PM Alex 'CAVE' Cernat wrote: > > > --inplace poate fi o binefacere sau un blestem, in functie de > > imprejurari, de obicei prefer sa nu-l folosesc decat cand chiar e musai > > nevoie de el (better safe than sorry) > > > > revenind la oile noastre strict cu -H, tot nu am gasit vreo referinta ca > > s-ar comporta diferit daca chiar sunt hardlink-uri in sursa fata de > > cazul in care nu ar fi > > iar pentru cazul (testat) in care nu sunt, nu am vazut schimbari > > evidente in utilizarea de memorie pe parcursul transferului (cu si fara > > -H); deci nu prea inteleg momentan de ce se plange lumea de extra consum > > de memorie si posibil blocari de sistem atunci cand volumul de date si > > numarul de fisiere este semnificativ ... > > > > Alex > > > > Daca ai -H specificat senderul mentine in memorie cate un hashtable pe > fiecare device cu toate inode-urile vazute pana atunci, si daca ai un tree > foarte stufos, ala tinde sa se umfle. Poti sa te uiti si prin cod ce anume > face: https://sources.debian.org/src/rsync/3.1.3-7/hlink.c/ (de notat ca-s > tot felul de if-uri care schimba comportamentul la versiuni mai mari de 3, > n-am stat sa sap prin release notes, feel free). > > Da' de fapt, care e problema ta? > -- > P. > ___ > 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] hardlink shits
--inplace poate fi o binefacere sau un blestem, in functie de imprejurari, de obicei prefer sa nu-l folosesc decat cand chiar e musai nevoie de el (better safe than sorry) revenind la oile noastre strict cu -H, tot nu am gasit vreo referinta ca s-ar comporta diferit daca chiar sunt hardlink-uri in sursa fata de cazul in care nu ar fi iar pentru cazul (testat) in care nu sunt, nu am vazut schimbari evidente in utilizarea de memorie pe parcursul transferului (cu si fara -H); deci nu prea inteleg momentan de ce se plange lumea de extra consum de memorie si posibil blocari de sistem atunci cand volumul de date si numarul de fisiere este semnificativ ... Alex On 09-Oct-19 4:01 PM, Cristian Paslaru wrote: > Daca doar vrei sa mentii o copie cat mai unu la unu si cu cat mai putin > transfer si unde -H ar merge cum ar trebui poti folosi optiunea de > --inplace > > On Wed, Oct 9, 2019 at 3:02 PM Alex 'CAVE' Cernat wrote: > >> On 09-Oct-19 2:45 PM, Cristian Paslaru wrote: >>> Salut, >>> >>> la 1. este in vfs: >>> >> https://www.usenix.org/legacy/publications/library/proceedings/usenix01/full_papers/kroeger/kroeger_html/node8.html >> deci de fapt e si mai bine, intra pe page cache (aka bucati de fisier), >> deci ar trebui sa ramana o singura copie in memorie oricate >> hard-link-uri ar fi existente (pentru ca refera aceeasi portiune de date >> de pe disk) >>> 2. la rsync cu multe hard-links incepe slow down si limita de inodes in >> FS, >>> nu neparat de storage still available, aveam some backups servers cu >> rsync >>> cu hard-links, si ca sa "overcome the issue of scanning all older >> folders" >>> foloseam --list-dest doar cu last previous days of backups, si merge fara >>> issues. Daca dadeam pentru all old folders, atunci la peste 7 zile de >>> backups incepea slowdown-ul. >>> Use-case-ul tau e pentru backups, sau altceva? >>> >>> Sporuri. >> m-ar interesa strict ca hard-link-urile de pe sursa sa se materializeze >> in hard-link-uri pe destinatie (ma rog, sunt acolo niste posibile >> "feature-uri" in care desi un fisier e hard-link-at e posibil sa fie >> transferat si dupa aia nu stiu, cred ca e sters la destinatie si facut >> hard-link asa cum trebuie, in functie de cum vine ordonata lista de >> fisiere in rsync; nu e perfect, dar e acceptabil) >> >> si nu, nu ma intereseaza sa pastrez "snapshot-uri" facute de rsync ca >> hard-linkuri (am testat / cred ca si folosit mai de mult, dar e criminal >> pe masura ce trece timpul), pentru asta un snapshot la nivel de >> filesystem (cu conditia sa si suporte asa ceva) e o solutie cu ani >> lumina mai departe >> >> Alex >> >>> On Wed, Oct 9, 2019 at 2:31 PM Alex 'CAVE' Cernat >> wrote: >>>> Salut >>>> >>>> Doua intrebari destul de low level legat de hard-link-uri: >>>> >>>> 1. cum tine linux-ul cache-ul cand e vorba de hard-linkuri ? sper ca >>>> tine la nivel de i-node, recte daca exista x fisiere accesate care >>>> pointeaza catre aceeasi zona de date (acelasi inode) se pastreaza o >>>> singura copie in cache, nu x bucati (nu stiu daca e de vfs sau >>>> implementare de filesystem, in cazul al doilea ar fi curios de stiut la >>>> ext4, xfs, zfs si nfs) >>>> >>>> 2. se plange lumea pe net ca optiunea -H (preserve hard links) genereaza >>>> posibile blocari si memory bomb-uri atunci cand e folosita pe directoare >>>> cu multe fisiere; din ce am facut niste teste nu am vazut modificari >>>> majore in memoria programului nici la sender, nici la receiver, in >>>> conditiile in care nu exista momentan din cate stiu hard link-uri in >>>> datele respective (testat inclusiv cu vreun milion de fisiere, ceea ce >>>> incepe sa devina semnificativ, dar dupa cum ziceam fara hard link-uri); >>>> dupa cum as implementa eu algoritmul, as trimite in plus in lista de >>>> fisiere/metadate si inode-ul (sau combinatie de fsid/partitionid/blockid >>>> si inode) iar in receiver as tine seama de informatiile astea daca e >>>> prezenta optiunea; s-ar putea totusi sa nu fie implementat asa, iar >>>> diferenta sa se simta doar daca exista efectiv hard-link-uri (eventual >>>> multe) in datele transferate; intrebarea e: si-a bagat cineva >>>> surubelnita destul de adanc in codul de rsync incat sa ma lamureasca si >>>> pe mine ce si cum ? >>>> >>>> mersi >>>> >>>> Alex >>>> >&g
Re: [rlug] hardlink shits
On 09-Oct-19 2:45 PM, Cristian Paslaru wrote: > Salut, > > la 1. este in vfs: > https://www.usenix.org/legacy/publications/library/proceedings/usenix01/full_papers/kroeger/kroeger_html/node8.html deci de fapt e si mai bine, intra pe page cache (aka bucati de fisier), deci ar trebui sa ramana o singura copie in memorie oricate hard-link-uri ar fi existente (pentru ca refera aceeasi portiune de date de pe disk) > > 2. la rsync cu multe hard-links incepe slow down si limita de inodes in FS, > nu neparat de storage still available, aveam some backups servers cu rsync > cu hard-links, si ca sa "overcome the issue of scanning all older folders" > foloseam --list-dest doar cu last previous days of backups, si merge fara > issues. Daca dadeam pentru all old folders, atunci la peste 7 zile de > backups incepea slowdown-ul. > Use-case-ul tau e pentru backups, sau altceva? > > Sporuri. m-ar interesa strict ca hard-link-urile de pe sursa sa se materializeze in hard-link-uri pe destinatie (ma rog, sunt acolo niste posibile "feature-uri" in care desi un fisier e hard-link-at e posibil sa fie transferat si dupa aia nu stiu, cred ca e sters la destinatie si facut hard-link asa cum trebuie, in functie de cum vine ordonata lista de fisiere in rsync; nu e perfect, dar e acceptabil) si nu, nu ma intereseaza sa pastrez "snapshot-uri" facute de rsync ca hard-linkuri (am testat / cred ca si folosit mai de mult, dar e criminal pe masura ce trece timpul), pentru asta un snapshot la nivel de filesystem (cu conditia sa si suporte asa ceva) e o solutie cu ani lumina mai departe Alex > > On Wed, Oct 9, 2019 at 2:31 PM Alex 'CAVE' Cernat wrote: > >> Salut >> >> Doua intrebari destul de low level legat de hard-link-uri: >> >> 1. cum tine linux-ul cache-ul cand e vorba de hard-linkuri ? sper ca >> tine la nivel de i-node, recte daca exista x fisiere accesate care >> pointeaza catre aceeasi zona de date (acelasi inode) se pastreaza o >> singura copie in cache, nu x bucati (nu stiu daca e de vfs sau >> implementare de filesystem, in cazul al doilea ar fi curios de stiut la >> ext4, xfs, zfs si nfs) >> >> 2. se plange lumea pe net ca optiunea -H (preserve hard links) genereaza >> posibile blocari si memory bomb-uri atunci cand e folosita pe directoare >> cu multe fisiere; din ce am facut niste teste nu am vazut modificari >> majore in memoria programului nici la sender, nici la receiver, in >> conditiile in care nu exista momentan din cate stiu hard link-uri in >> datele respective (testat inclusiv cu vreun milion de fisiere, ceea ce >> incepe sa devina semnificativ, dar dupa cum ziceam fara hard link-uri); >> dupa cum as implementa eu algoritmul, as trimite in plus in lista de >> fisiere/metadate si inode-ul (sau combinatie de fsid/partitionid/blockid >> si inode) iar in receiver as tine seama de informatiile astea daca e >> prezenta optiunea; s-ar putea totusi sa nu fie implementat asa, iar >> diferenta sa se simta doar daca exista efectiv hard-link-uri (eventual >> multe) in datele transferate; intrebarea e: si-a bagat cineva >> surubelnita destul de adanc in codul de rsync incat sa ma lamureasca si >> pe mine ce si cum ? >> >> mersi >> >> 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 ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug_lists.lug.ro
[rlug] hardlink shits
Salut Doua intrebari destul de low level legat de hard-link-uri: 1. cum tine linux-ul cache-ul cand e vorba de hard-linkuri ? sper ca tine la nivel de i-node, recte daca exista x fisiere accesate care pointeaza catre aceeasi zona de date (acelasi inode) se pastreaza o singura copie in cache, nu x bucati (nu stiu daca e de vfs sau implementare de filesystem, in cazul al doilea ar fi curios de stiut la ext4, xfs, zfs si nfs) 2. se plange lumea pe net ca optiunea -H (preserve hard links) genereaza posibile blocari si memory bomb-uri atunci cand e folosita pe directoare cu multe fisiere; din ce am facut niste teste nu am vazut modificari majore in memoria programului nici la sender, nici la receiver, in conditiile in care nu exista momentan din cate stiu hard link-uri in datele respective (testat inclusiv cu vreun milion de fisiere, ceea ce incepe sa devina semnificativ, dar dupa cum ziceam fara hard link-uri); dupa cum as implementa eu algoritmul, as trimite in plus in lista de fisiere/metadate si inode-ul (sau combinatie de fsid/partitionid/blockid si inode) iar in receiver as tine seama de informatiile astea daca e prezenta optiunea; s-ar putea totusi sa nu fie implementat asa, iar diferenta sa se simta doar daca exista efectiv hard-link-uri (eventual multe) in datele transferate; intrebarea e: si-a bagat cineva surubelnita destul de adanc in codul de rsync incat sa ma lamureasca si pe mine ce si cum ? mersi Alex ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug_lists.lug.ro
Re: [rlug] debian wheezy in archive
On 25-Mar-19 3:02 PM, Adrian Minta wrote: > Salut, > > https://lists.debian.org/debian-devel-announce/2019/03/msg6.html mdea, e timpul sa verific subscriptiile la liste, ca se pare ca s-au mai auto-unsubscris pe alocuri ma asteptam totusi sa fie anuntata mai pe larg o astfel de mutare (decat un simplu mail), sau macar sa-si modifice readme-ul de pe ftp.debian.org & friends cat sa reflecte realitatea (probabil ca detaliul asta le-a scapat) si in teorie trebuia sa se intample dupa release-ul lui buster (d10), dar se pare ca se mai schimba politicile on-the-fly dar este mai mult decat clar mersi, Alex ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug_lists.lug.ro
[rlug] debian wheezy in archive
salut exista vreo informatie oficiala cum ca vechitura de debian 7 (wheezy) a fost bagata in archive ? ca pe repository asa pare, desi in readme e inca acolo bine mersi ... si nici nu am reusit sa gasesc vreo informatie oficiala in acest sens Alex ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug_lists.lug.ro
Re: [rlug] perl chinese
On 23-Jan-19 11:21 AM, Mihai Badici wrote: > Doar că am preferat să las pe cineva care chiar a lucrat în perl și știe > mai bine. > > Pe de altă parte, arată ca în chineză, se interpretează ca în chineză, > sigur e chineză ;) Mihai, ce-ar gogu' cu tine de-ti baga toate mesajele in spam ? vad ca ale lui Petru incep incet incet sa ajunga unde trebuie, sa vedem pentru cata vreme daca tot am inceput cu perl-eza, interesant e ca dupa $ poti sa pui aproape orice caracter, si functioneaza; distractia incepe la alea "magice" (cea mai simpla fiind $_) imbatranim nene, nici draq nu mai foloseste perl, azi toata lumea s-a bagat pe serpisori, daca nu au trecut deja la go si ruby Alex ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug_lists.lug.ro
Re: [rlug] perl chinese
On 23-Jan-19 8:22 AM, Petru Rațiu wrote:
> Cu amendamentul ca inca nu mi-am baut cafeaua si n-am testat absolut nimic
> din ce scriu mai jos:
>
> - s{lala}{lulu} e echivalentul lui s/lala/lulu/ dar cu alta forma de
> quoting,e binecunoscutul operator search-and replace ;
> - mxs sunt flaguri: m si s impreuna inseamna ca \n e considerat un caracter
> oarecare, x inseamna ca whitespaces nu conteaza si ar ajuta la formatare
> sau comments (oarecum degeaba in acest context, se pare)
> - "> [^<]+ \z" din prima parte pare sa vrea sa insemne "> urmat de oricate
> caractere care nu sunt <, dar minim unul, dupa care \z care e un soi de $
> mai strict (prinde si enter-uri, de ex)
> ">" din partea a doua e mai simplu :)
>
Mersi
nebanuite sunt caile perl-ului si sintaxa lui, uneori ma gandesc ca daca
dai vreo 3 pumni in tastatura (aleator) ai sanse mari sa se "compileze"
rezultatul ca program perl
citisem si eu intre timp de forma asta de s&r, dar e prima data cand o
intalnesc (chiar si schimbatul / se face destul de rar, macar la
regexp-uri lumea e conservatoare si prefera sa escapeze / decat sa-l
inlocuiasca)
revenind la "> [^<]+ \z", spatiile sunt acolo si match-uiesc in regexp
exact ca si cum ar fi fost in /, nu ? adica faptul ca foloseste acolade
nu inseamna nimic, doar chinuie creierul celui care nu e obisnuit cu
forma asta ...
Alex
ps: ai intuit corect, e legat de xml cleanup; daca idiotii de la hp isi
faceau treaba si macar respectau specificatiile scrise chiar de ei nu
era nevoie de hack-uri si alte balarii de genul (inclusiv algoritmi care
suna: sparge output-ul in chunk-uri si ia-l pe cel mai lung dintre ele
... suna groaznic insa culmea, e varianta corecta)
___
RLUG mailing list
RLUG@lists.lug.ro
http://lists.lug.ro/mailman/listinfo/rlug_lists.lug.ro
[rlug] perl chinese
salut
intr-un script de perl am gasit chestia asta:
s{ > [^<]+ \z }{>}mxs for @array;
imi poate si mie traduce careva ? ca nici nu stiu de unde sa incep :-P
mersi
Alex
___
RLUG mailing list
RLUG@lists.lug.ro
http://lists.lug.ro/mailman/listinfo/rlug_lists.lug.ro
[rlug] soft IPAM & DCIM
mi s-a acrit de Racktables asa ca vreau sa bag divort cat de curand, dar pentru asta trebuie ceva facut mai cu cap si mai in 201x, cu x cat mai mare cerintele ar fi: - IPAM & DCIM (doh) - la DCIM inclusiv cablari fizice (evidenta lor) - free :-P (sau macar ceva gen free pana la 500-1000 de obiecte, la cam toate chestiile comerciale limita maxima de free - daca exista - e undeva pe la 50 - 100) - preferabil PHP & mySQL - softurile in javra trebuie sa fie cu adevarat exceptionale ca sa ma uit la ele (asta e, fiecare cu alergiile lui) - interfata moderna (m-am saturat de interfete din 200x, ca sa nu mai zic de cele din 1900-toamna) - API - interfatare cu ansible (asta poate inseamna si un simplu API, atata timp cat e facut cu cap) - nu neaparat sa aiba auto-discovery dar un mare plus ar fi sa poata compara situatia cunoscuta (din baza de date) cu cea de pe teren momentan pana acum cel mai bun candidat este netbox-ul celor de la digitalocean, cu singura mentiune e ca trebuie sa imblanzesc serpisorii, dar nu e capat de tara tot ce am mai vazut ori e pe (multi) bani, ori are interfete de pe vremea lui pazvante, ori sunt mult prea stufoase pentru nevoile mele sau cu lipsuri majore (vezi ralph) mersi, Alex ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug_lists.lug.ro
Re: [rlug] subdomeniu in nginx
On 06-Dec-18 11:44 AM, Petru Rațiu wrote: > Vezi ca "domeniul unui subdomeniu" e o chestie cam vag definita. La " > sandbox.service.domain.co.uk" ce vrei sa fie capturat? Sau, mai bine zis, > in ce scop vrei sa le mapezi pe domenii? Dincolo de chestia asta, regex > should be fine, dar e posibil sa ajungi sa predefinesti manual variabila pe > fiecare vhost :) > am zis ca toate sunt de genul subdomeniu.domeniu.ro, si ma intereseaza acel "subdomeniu" intr-o variabila pentru a o folosi in configuratie mai departe ca parametru atata timp cat stiu ca sunt toate pe 3 "nivele" (ca doar le setez de mana in server_name) si am grija sa nu se duca vreun default ip pe server block-ul respectiv, abordarea as zice ca e safe intr-adevar, din map se mai poate face o verificare in plus, in caz ca isi baga cineva nasul si pune aiurea in server_name un alt.subdomeniu.domeniu.ro (pe 4 nivele), insa dupa cum ziceam, incercam un over-engineering sa-l crut pe nenea nginx de un regexp in plus Alex ps: nu prea am inteles aia cu predefinirea manuala, la ce scenariu te gandeai ? ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug_lists.lug.ro
[rlug] subdomeniu in nginx
pentru niste subdomenii (toate de genul sub.domeniu.ro) am nevoie cumva sa obtin numele subdomeniului intr-o variabila, pentru a putea sa o folosesc mai departe in configurari (configurarile sunt aproape identice, difera doar subdomeniul ca variabila) vreau sa evit sa folosesc regexp in server_name, pentru ca pe de o parte regexp overhead, pe de alta parte cred ca se va bate putin cap in cap cu un catchall (bine, se poate modifica si ala cu regexp, si iese cu si mai mare overhead) pana acum cea mai buna solutie mi se pare server_name unu.domeniu doi.domeniu ...; si apoi extras $subdomain din $server_name printr-un map (nu scap de regexp, dar macar va fi aplicat strict pentru subdomeniile respective) exista vreo solutie mai simpla, de preferat fara regexp ? (in afara de cea muncitoreasca cu X server blocks, cate unul pentru fiecare subdomeniu, si apoi hardcodat in fiecare block subdomeniul?) Alex ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug_lists.lug.ro
Re: [rlug] nginx fastcgi_cache
On 09-Oct-18 5:27 PM, Catalin Muresan wrote: > Daca ai probleme de genul asta (cache cross apps, etc) atunci probabil ca > solutia corecta e alta, adica sa implementezi caching in toate layerele: > DB(proxysql), APP(memcache), Webserver(fastcgi_cache), HTTP(varnish). > Ramin la opinia mea initiala ca daca faci cache-uri in acelasi director o > sa manince prea multa memorie ca sa incarce cheile care nu o sa fie > folosite vreodata. aici cred ca m-am exprimat eu gresit, nu doar spatiul pe disc sa fie comun, ci inclusiv cheile din memorie, ca ar fi nebunie sa incarci aiurea acelasi continut in mai multe cache-uri, nici nu stiu daca nu crapa cu alte cuvinte tot cache-ul (fisiere si chei in memorie) sa fie comun mai multor aplicatii (vhosturi) bine, nu stiu exact la ce ar folosi, decat eventual servirea aceluiasi continut prin mai multe domenii total diferite (cu certificate diferite, astfel incat sa nu le poti baga in acelasi vhost) etc. asta oricum s-ar face mult mai eficient punand o masina in fata, dar dupa cum ziceam, era doar filosofia chibritului, celelalte intrebari erau esentiale, restul ... fantezie Alex ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug_lists.lug.ro
Re: [rlug] nginx fastcgi_cache
On 09-Oct-18 3:42 PM, Alex 'CAVE' Cernat wrote: > > aici ca mi-ai ridicat mingea la fileu, inca o intrebare de si mai mare > baraj: considerand un cache gigantic, unde dureaza sa incarce toate > cheile, oare ce se intampla cu o cerere care este cache-uita pe disk, > dar cheia nu a ajuns in memorie inca (cache loaderul nu a terminat inca) > ? o verifica pe disc sau direct face cererea la backend ? > o sa incerc sa ma uit si eu prin surse, sa vad daca inteleg ce se > intampla pe acolo; gogu' nu stie sa raspunda si se pare ca doar eu am > intrebari filosofice de genul :-D finally primul raspuns la obiect gasit, dupa lungi cautari, in caz ca mai intereseaza si pe altcineva: e de bun simt, insa de prea multe ori in it bunul simt si implementarea concreta nu prea au multe in comun :-P If the cache isn’t yet loaded, nginx will try to check if a cache file is there by a looking into disk directly from a worker process. That is, it will work without problems and will use cached responses, but will be slightly less effective. ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug_lists.lug.ro
Re: [rlug] nginx fastcgi_cache
On 09-Oct-18 2:27 PM, Catalin Muresan wrote: > > Both the key and file name in a cache are a result of applying the MD5 > function to the proxied URL. > > Deci lookup se face cind esti pe location-ul respectiv si URL-ul e > disponibil > Din surse > https://github.com/nginx/nginx/blob/master/src/http/modules/ngx_http_fastcgi_module.c > se pare totusi ca face hash pe url si pe header. aici cel mai bine te joci cu fastcgi_cache_key si nu o lasi default, ca sa se plieze fix pe ce ai nevoie; bine, fiind md5 intotdeauna exista o mica sansa de coliziune, dar deja intram in filosofii ... ma uit pe documentatie si la default value e trasa bara, si nu am incercat niciodata valoarea default, intotdeauna o setez (inclusiv la proxy cache) > Nu e o idee buna sa pui un cache zone comun din alt motiv: > > A minute after the start the special “cache loader” process is activated. > It loads information about previously cached data stored on file system > into a cache zone. The loading is also done in iterations. During one > iteration no more than loader_files items are loaded (by default, 100). > Besides, the duration of one iteration is limited by the loader_threshold > parameter (by default, 200 milliseconds). Between iterations, a pause > configured by the loader_sleep parameter (by default, 50 milliseconds) is > made. aici ca mi-ai ridicat mingea la fileu, inca o intrebare de si mai mare baraj: considerand un cache gigantic, unde dureaza sa incarce toate cheile, oare ce se intampla cu o cerere care este cache-uita pe disk, dar cheia nu a ajuns in memorie inca (cache loaderul nu a terminat inca) ? o verifica pe disc sau direct face cererea la backend ? o sa incerc sa ma uit si eu prin surse, sa vad daca inteleg ce se intampla pe acolo; gogu' nu stie sa raspunda si se pare ca doar eu am intrebari filosofice de genul :-D > pentru fiecare cache nginx tine in memorie keys > > In addition, all active keys and information about data are stored in a > shared memory zone, whose name and size are configured by the keys_zone > parameter. One megabyte zone can store about 8 thousand keys. vorbeam de cazuri mai mult sau mai putin ipotetice unde chiar s-ar putea beneficia de cache-uri comune, nu de aplicatii total diferite unde numai prin prisma separarii aplicatiilor cache-ul comun nu are ce cauta - existand riscul chiar si ipotetic sa servesc un cache dintr-o alta aplicatie (parerea mea) Alex ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug_lists.lug.ro
[rlug] nginx fastcgi_cache
Salut Ca de obicei o intrebare de baraj. Incerc sa inteleg exact cum functioneaza fastcgi cache-ul la nginx, insa toata lumea da doar exemple de configuratii, insa pe nicaieri nu am gasit informatii de inside. Concret, ma intereseaza cand sau unde se face lookup-ul in cache. Presupunerea mea ar fi ca ar trebui sa-l faca numai cand requestul ajunge in location-ul unde este definit acel cache. (bine, configuratia de nginx fiind declarativa si nu imperativa, trebuie mare atentie la cuvinte, dar traducem pe alocuri :-P). Poate cineva sa-mi confirme cu ceva documentatie ? Asta ar insemna ca la nevoie multiple locatii ar putea folosi acelasi cache, ba chiar si mai multe vhosturi ar putea sa-l share-uiasca, atata timp cat vorbim de acelasi cache, iar cache key-ul este definit cu mare atentie. Si repet, o diagrama cu modul de functionare si timing al fastcgi cache-ului ar fi de mare ajutor, dar n-am gasit nimic de genul asta Mersi, Alex ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug_lists.lug.ro
Re: [rlug] Rebuild RAID HP cu hpacucli
On 17-Aug-18 11:18 AM, Adrian Popa wrote: > logicaldrive 2 (1.4 TB, RAID 5, Interim Recovery Mode) > > physicaldrive 1I:1:3 (port 1I:box 1:bay 3, SAS, 300 GB, Predictive > Failure) > physicaldrive 1I:1:4 (port 1I:box 1:bay 4, SAS, 300 GB, OK) > physicaldrive 2I:1:5 (port 2I:box 1:bay 5, SAS, 300 GB, Failed) > physicaldrive 2I:1:6 (port 2I:box 1:bay 6, SAS, 300 GB, OK) > physicaldrive 2I:1:7 (port 2I:box 1:bay 7, SAS, 300 GB, OK) > physicaldrive 2I:1:8 (port 2I:box 1:bay 8, SAS, 300 GB, OK) > ai mare grija ca si discul din portul 3 e pe moarte, oare de asta sa nu porneasca rebuildul ? totusi e un non-sense pana acum n-am avut probleme de genul asta cu niciun server hp, la crapat de hard am bagat altul si s-a rebuild-uit fara probleme fara vreo comanda data nu poti sa fortezi rebuildul din consola ? n-am testat, dar sigur exista vreun parametru pentru asta Alex ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug_lists.lug.ro
Re: [rlug] cum pun toate hardurile la comun?
ia cauta shoparla (aka lizardfs, derivat din moosefs) On 26-Jul-18 10:17 PM, George-Cristian Bîrzan wrote: > 1) GlusterFS? > 2) Vrei 5 masini. > > 2018-07-26 21:59 GMT+03:00 Mai Ling : > >> >> >> >> >> >> >> >> Am 4 masini identice, conectate in acelasi LAN, fiecare avand cate un >> disc nefolosit, separat de discul pe care e instalata o clona de RHEL7 >> (care nu poate fi inlocuita) >> >> >> >> Vreau sa pun la un loc toate aceste discuri, dupa care fiecare server sa >> acceseze fie o parte fie tot acest spatiu comun, indiferent in ce fel >> (nfs/iscsi/whatever). >> >> >> >> Mai vreau sa pot pierde oricare 2 masini simultan fara ca acest lucru sa >> duca la indisponibilitatea spatiului comun. >> >> >> >> Ce solutii free beer exista care ar satisface toate cerintele de mai sus? >> >> >> >> (Mi-am imaginat o strutocamila in varianta in care le export pe toate >> peste iscsi, le adun pe una din masini, fac un raid6 din ele, re-export >> rezultatul peste nfs si il montez in fiecare - dar asta ar avea >> dezavantajele ca ar functiona foarte lent, iar daca pica masina care >> share-uieste spatiul comun, am si pierderi de date (ce era in cache-ul ei >> si nu ajunsese pe discuri) si downtime (reboot la toate masinile ca nu stiu >> daca ma lasa nfs sa-l demontez cu fisiere deschise), dezavantaje care >> elimina aceasta varianta.) >> >> >> >> >> >> >> >> >> >> >> >> >> ___ >> 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] mpm_itk + mpm_event
Știu ca ma uitam pe vremuri după el, dar nu am ajuns să-l folosesc niciodată. Ce are el și nu are echivalent în FPM? On 4 Jan 2018 16:03, "Andrei-Florian Staicu" wrote: Mda. Intre timp m-am lamurit: itk nu merge cu altceva decat prefork (zice in documentatia lui). Am renuntat la itk si o sa ma mut pe event. Imi pare rau de separarea intre useri. Merci. On Wed, Jan 3, 2018 at 10:21 PM Andrei-Florian Staicu < andrei.sta...@gmail.com> wrote: > Salutare, > Pe un Ubuntu 16.04.3 LTS, am apache2 de la sury (2.4.29-1+ubuntu16.04.1+ > deb.sury.org+1) cu mpm_prefork si mpm_itk (mai multe site-uri, fiecare cu > userul lui). > Acum incerc sa ma mut pe mpm_event, ca sa pot sa http2, dar se pare ca itk > depinde de event: > a2enmod mpm_itk > Considering dependency mpm_prefork for mpm_itk: > Considering conflict mpm_event for mpm_prefork: > Considering conflict mpm_worker for mpm_prefork: > Module mpm_prefork already enabled > Module mpm_itk already enabled > Imi puteti spune daca itk poate functiona cu event? > Merci. > > > -- > Beware of programmers who carry screwdrivers. > -- Beware of programmers who carry screwdrivers. ___ 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] mpm_itk + mpm_event
Dacă tot treci pe event, de ce nu treci și pe php-fpm? Deja prefork-ul cu mod_php ar trebui sa fie history On 3 Jan 2018 22:25, "Andrei-Florian Staicu" wrote: > Salutare, > Pe un Ubuntu 16.04.3 LTS, am apache2 de la sury (2.4.29-1+ubuntu16.04.1+ > deb.sury.org+1) cu mpm_prefork si mpm_itk (mai multe site-uri, fiecare cu > userul lui). > Acum incerc sa ma mut pe mpm_event, ca sa pot sa http2, dar se pare ca itk > depinde de event: > a2enmod mpm_itk > Considering dependency mpm_prefork for mpm_itk: > Considering conflict mpm_event for mpm_prefork: > Considering conflict mpm_worker for mpm_prefork: > Module mpm_prefork already enabled > Module mpm_itk already enabled > Imi puteti spune daca itk poate functiona cu event? > Merci. > > > -- > Beware of programmers who carry screwdrivers. > ___ > 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] intrebare abisala symlink-uri
pana vineri, sa ne stoarcem creierii de miercuri cu intrebari abisale exista vreo diferenta semnificativa de performanta intre a utiliza symlink-uri absolute (full path target) vs. symlink-uri relative (cu mai multe sau mai putine ../ in target) ? vorbim strict de cazul in care target-ul este 'prin zona' (acelasi filesystem) path-ul absolut e sfant, asta se stie, din pacate insa nu prea ofera foarte multa flexibilitate ... si ar fi 2 aspecte: 1. accesul direct la fisiere (gen open /path/to/symlink) 2. normalizarea target-ului prin diverse limbaje de programare (readlink/realpath etc); aici clar castiga absolut-ul, important e ca diferenta sa fie nesemnificativa Alex iar pentru Gogu sunt prea filosofic la ora asta se pare ... ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] recuperare db-uri innodb
Doar o idee: încearcă și cu un mariadb sau percona. Din câte știu formatele binare ar trebui sa fie compatibile și poate ai noroc. Oricum, preferabil dump și import de la zero, ca să fii cât de cât sigur ca nu au rămas gunoaie On 5 Apr 2017 7:56 pm, "Vlad Georgescu" wrote: > Da, lucrez pe copie. Am incercat cu innodb_force_recovery, incepand de > la 1 si pana la 6, pe copie, dar server-ul crapa la pornire, indiferent > de valoare. > > On 04/05/2017 07:48 PM, Claudiu Cismaru wrote: > >> ibdata1" zice ca totul e ok. Am incercat pornire cu > >> innodb_force_recovery de la 1 la 6 in my.cnf, dar fara succes. Am > >> transferat /var/lib/mysql pe alt system, punand ultima versiune de > >> mysql, dar din pacate eroarea e similara. S-a mai confruntat cineva cu > >> asa ceva? Ce pisici sa-i mai fac? > > Daca ai facut o copie si lucrezi pe copie, foloseste > innodb_force_recovery la > > 2, apoi la 3 si apoi mai sus... (see manual), chair daca documentatia nu > > recomanda. > > > > Vezi pentru ce valoare nu mai crapa. Dupa ce ai stabilit, uite-te prin > loguri > > si vezi daca incearca sa execute vreun quey inainte sa crape... Sau la > care > > tabela ai probleme. > > > > Eu am reusit sa recuperez, in majoritatea cazurilor, pe device-urile > > clientilor, cu rata de succes 100%. Insa au fost situatii cand nu prea > am mai > > avut ce sa-i fac... > > > > ___ > RLUG mailing list > RLUG@lists.lug.ro > http://lists.lug.ro/mailman/listinfo/rlug > ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] terminal vertical split (xargs parallel command output)
On 15-Mar-17 2:52 PM, Petru Rațiu wrote: > De ce tii musai sa faci din oneliner? Pregateste listele de comenzi in > niste scripturi si ruleaza-le in terminalele cu pricina. Also, la 1000 de > chestii care fac stuff, de ce te agiti asa de mult cu terminale si nu le > faci neinteractive? "watching shit scroll" value? > nu se ruleaza 1000 simultan, ci maxim X, care ar fi ideal sa fie cat mai flexibil; de aia cautam ceva deja facut, ca altfel e posibil sa ma pot juca cu niste coduri escape, insa n-am chef sa reinventez roata si ca sa-ti raspund: probabil mi s-a facut dor de matrix, n-am mai vazut de mult seria :-P Alex ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
