Tag Archives: computers

enigmatique

diverse,

Vineri ma plictisisem de prostituat pe la birou si m-am bagat si eu in seama intr-o discutie dintre niste programatori PHP-isti si Ops. In seama in sensul ca ascultam ca poate mai aflu chestii depsre una-alta.

La un moment dat s-au apucat sa vorbreasca despre scos metrice din aplicatii PHP si despre cum ar fi complicat ca alea ruleaza pe multe pod-uri in Kubernetes si ca php-fpm iti omoara procese si ai multe procese si alte cele.

In momentul ala mi-a scaparat o idee ca se pot scoate metrici super usor, trebuie doar sa le tii undeva :))

Eu sunt asa super fan Redis ca mi se pare ca e genul ala de software scris cum trebuie (adica in C) si cu grija (adica merge repede).

M-am gandit eu vineri ca pot scrie din PHP in Redis si dupa aia sa le iau de acolo si sa le pune undeva de unde le poata lua Prometheus.

Problema asta fiind rezolvata, am ajuns la cum fac sa nu trebuiasca sa populez inainte Redis-ul cu informatii si dupa aia sa scrie aplicatia chestii pe acolo. Am zis ca’s fan Redis? E, Redix are SETNX, prin care setezi o cheie la o anumita valoare doar daca cheia aia nu exista. Si asta inseamna ca poti sa spawnezi ‘jde aplicatii care prima oara fac SETNX si dupa aia incrementeaza pe acolo contoare. Mi-am dat un self-highfive si m-am apucat de scris.

M-am apucat de scris azi, ca peste weekend am avut altele de facut, da mi-a mers acolo ganditul in background si azi stiui ce sa scriu.

Cam asta e povestea lui Enigmatique. Ca e enigmatic asa sa nu stii cate metrici o sa ai si nici Prometheus cand face scrape n-o sa stie :))

Am scris asta din doua motive mari asa:

  • Stiu ca vocile nu’s reale, dar cateodata au idei bune. Asta fu’ unu’ din cazuri.
  • Sa mai fac ceva practica cu programatul, ca nu se stie cand mai au vocile idei.

Si ii facui si logo, ca nu se stie cand e nevoie de-un logo. Sa traiasca Shopify ca are aplicatie de facut logo-uri :))

python challenges

diverse

Mai acu vreo luna asa, cautam eu niste chestii de Python si dintr-una in alta am dat de un site care se cheama CodingBat si are niste probleme de Python acolo. Cum nu mai facusem de ceva vreme chestii in Python (si in programare in general) m-am apucat sa rezolv probleme de acolo. Primele au fost ok, dupa care au inceput din alea mai dubioase.

Initial am zis sa salvez solutiile la alea dubioase, dar pe ultimele le-am salvat pe toate ca erau toate dubioase la final.

A fost interesant asa ca mi-am mai descretit creierul si am mai invatat una alta.

Cu ocazia asta am mai comis si ceva in GitHub ca tot am acolo un mic repository pentru blog si am facut un mic director si pentru challenge-urile astea.

Postul asta e din capitolul: doar ma laud, nu vreau sa zic nimic :))

mssql replication & log shipping

diverse, ,

Acu ceva vreme am instalat la niste oameni niste multe servere de MSSQL pentru niste chestii de logistica.

Anul asta au zis oamenii ca bai, e important sa nu pierdem datele pe care le avem pe servere si hai sa facem un backup offsite.

Backup-ul offsite n-a fost sa fie ca latenta si TCP e picky cu latenta cand vrei sa transferi single-connection fisiere mari si eram intr-o situatie din aia in care dura mai mult de-o zi sa transfer un fisier de backup (mind you, gigabit in ambele parti, da TCP…). “Stiintific” treaba asta se cheama “long fat pipe problem” si necesita un pic de inginerie sa mearga cum trebuie, da’ in cazul de fata n’aveam ce inginerie sa fac ca tehnologia era la impuse.

Long story short, zic hai ca am solutia: facem replicare intre servere de MSSQL si o sa fie aproape realtime datele, eventual o sa se mai piarda cateva tranzactii, da’ nu e un capat de lume.

Si ma apuc eu si instalez un SQL server in alta parte si da-i sa fac replicare. Ma gandeam eu ca e la MySQL undeva faci un master/slave, restaurezi un backup pe ala remote si dupa aia trimiti binlog-urile pe al doilea sa le face replay si aia e. Simplu.

Well… not really, ca Microsoft fiind Microsoft au zis ca de ce sa fie simplu cand poate sa fie complicat si nu poti face replicare asa simplu. Ca de exemplu daca ai tabele fara primary key nu le poti include in replicare. Procedurile stocate nu se replica, because reasons…

Multa muie lor pe tema asta ca mi-au scos peri albi.

Zic bine, facem transaction log shipping care “replica” tot. O sa fie baza de date remote un pic in urma, da’ a zis lumea ca poate trai si daca se pierd 30min de date.

Acum, astia cu logistica sunt mai speciali… cam ca niste autisti de speciali, si ei nu cred in versiuni prea noi de software si asa am ajuns eu sa am si MSSQL 2014 si 2016, ca fiecare producator are versiunea lui de baza de date “suportata”.

Mno, acu aveam servere din astea diferite, zic hai ca pun MSSQL 2017 in locatia remote si stochez acolo toate bazele de date ca fiecare baza de date un Compatibility Level care e in functie de versiunea de SQL Server, gen 2014, 2016 si 2017.

Instalez eu serverul vietii, dau sa setez transcation log shipping: nu se poate prietene ca trebuie upgradata versiunea de baza de date pe serverul remote si ghinion ca tu ai o versiune mai veche. Morti si raniti si muie alora de-au programat mizeria asta.

Se pare ca desi poti bifa acolo Compatibility Level, intern MSSQL mai modifica un pic baza de date ca sa fie compatibila cu noul engine de SQL, da’ la suprafata se comporta ca ala vechi…

Alte ore pierdute aiurea, da-le-as muie la imbecilii pulii. Pai orice esti backward compatible ori nu esti.

Zic bine, hai ca pun un 2014 remote sa se impace cu 2014 local. Pun serverul pulii, setez acolo replicarea, face primul backup mare de pe sursa, il copiaza super repede pe destinatie si imi da prin gura: n-ai destul loc pe C:\ ca sa restaurez baza de date pe destinatie. Mi-au scapat instant multe mui inspre Microsoft pe tema asta…

Asta desi din setup era configurat sa tina bazele de date pe alt disk cu suficient de mult spatiu. Dar nu, el vrea musai pe C:\ pentru ca ma gandesc eu ca acolo are setat “Instance Root Directory” si simte nevoia s-o puna acolo desi ar trebui s-o puna in alta parte.

Varianta complicata a fost sa fac eu un backup full la o baza de date, s-o copiez in 3 ore in partea ailata si s-o restaurez unde trebuie si abia dupa aia sa setez transaction log shipping pe sursa si sa-i zic la sursa ca deja exista baza de date in partea ailalta.

Asta era azinoapte. Dupa un pic de investigatii descoperii ca de fapt nu merge log shipping.

Banuiesc ca e din cauza ca pana s-a copiat baza de date si s-a restaurat a trecut prea mult timp pe sursa si logurile pe care le genereaza nu au logica pe destinatie ca’s la prea mare distanta in timp.

Back to the drawing board. Sa moara in chinuri aia de la MS care in loc sa faca un setup simplu, l-au complicat pana i-au scos mucii pe cur. Unfuckingbelieveable…

(Cateva zile mai tarziu…)

Dupa un pic de desenat am descoperit cum pot sa-l fac sa restaureze baza de date unde trebuie. La Restore are niste optiuni semi-ascunse in care ii zici unde sa restaureze baza de date si unde sa restaureze logurile. La asta cu restauratul evident ca nu e simplu: baza da date pe sursa se cheama ABC si are doua fisiere mari si late: ABC.MDF si ABC_LOG.LDF (baza de date propriuzisa si logurile). Eh, cand le faci restore in alta parte, poti sa schimbi numele bazei de date – asa cum am facut eu, ca poate vrei s-o prefixezi cu ceva. Catch-ul e ca numele de pe disk al fisierelor nu se schimba in noul prefix, gen baza sa fie LS-ABC si fisierele sa se cheme LS-ABC.MDF si LS-ABC_LOG.LDF… Pai ce erau prosti sa-l schimbe? Nu, pe disc ramane la fel. Si daca ai doua servere din medii diferite de productie si cu acelasi nume de baza de date si vrei sa faci log shipping de pe ambele pe un singur server… ghici ce… la a doua restuare o sa-ti dea eroare ca deja exista baza de date si ca bla bla e folosita. Si trebuie sa faci alte directoare pentru baza si pentru loguri ca sa poti face log shipping si pentru al doilea server…

Problema de dinainte era din cauza ca aveam alte job-uri de log backup si MSSQL asta nu e asa inteligent sa nu amestece oalele, si se facea backup la loguri din 2 in 5 si evident ca unele loguri era salvate undeva si alte altundeva si pula continuitate in loguri si n-avea ala la ce sa faca restore.

Fixat asta, dat backup/restore si log shipping si pare sa mearga. Trebuie sa stau cu geana pe el sa vad ca nu sughita, sa dau un reboot pe ici pe colo sa vad cum face cand se mai pierde sursa sau destinatia un pic.

Sa-i chis in freza pe astia de la Microsoft si mai ales pe aia de scriu la MSSQL ca au gandit diverse chestii din puta gandirii…

next-gen retail

diverse

Ca si consultant nimeresc in tot felul de proiecte, unele la care nu m-as fi gandit vreodata. Una din cauze ar fi ca nu m-am gandit ca in anumite industrii ar fi nevoie de ce stiu eu sa fac, dar cateodata se pare ca e :)

Un exemplu de proiect din asta ar fi magazine fizice in mall-uri:)) Iar anul trecut am participat la deschiderea primelor doua magazine (din cateva sute) de la niste oameni. Pentru unul ca mine care nu s-a plimbat niciodata prin spatele magazinelor, toata treaba a fost super interesanta.

Super interesant pentru ca am apucat sa vad tot procesul cap coada a ceea ce inseamna deschiderea unui magazin de la un spatiu gol pana la primii clienti in magazin. Si este exagerat de multa munca sa te intelegi cu toata lumea, de la arhitecti la vopsitori. Ca si anecdota din multe altele, a trebuit sa vina un contractor sa traga cabluri de retea pentru niste senzori si s-a gandit sa fie de ajutor si a tras 16 cabluri in loc de 8 ca s-a gandit el ca sa fie acolo trase in caz ca se strica vreo unul.

Acum, de ce “next-gen” retail? Pai pentru ca spre deosebire de restul magazinelor din mall-uri, astea de le-am deschis sunt mai high-tech asa:

WiFi pe bune + security si nu o petarda de $50 aruncata in vre-un colt. Asta a fost mana mea, ca daca sa ai conexiune buna de date si acoperire calumea nu poti s-o faci “el cheapo”. La fel si cu segmentarea retelei, ca fiecare producator are o idee de ce vrea sa faca si nu e bine sa-l lasi de capul lui cu acces peste tot. Treaba asta o pusei prima sa ma laud :)

RFID: toata marfa are tag-uri de RFID si in felul asta stii exact ce si cate SKU-uri sunt intr-un magazin. Dupa ce am vazut cate zeci de mii de produse pot intra in cateva sute de metri patrati de magazin, n-as vrea eu sa fiu ala care face inventarul manual ca in cazul unui magazin clasic. Cu un scanner portabil de RFID poti face in doua-trei ore inventarul la tot magazinul cu o rata de eroare neglijabila. O alta utilitate a tag-urilor este sistemul de antifurt, ca nu mai trebuie sa gauresti marfa sa-i pui chestii din alea mari cu vopsea inauntru.

Cabine de proba inteligente: fiecare cabina de proba are o tableta conectata la un mic server local care la randul lui este conectat la niste cititoare de RFID de la distanta si cand intri intr-o cabina de proba, poti vedea pe tableta exact ce ai luat cu tine in cabina si daca ceva nu se potriveste poti vedea in timp real daca este pe stoc in magazin si daca da, “apesi” pe un buton pe tableta si un asistent de vanzari primeste un mesaj pe telefon cu ce ai nevoie si iti aduce in cateva minute. Eu m-am bucurat maxim de optiunea asta ca numai eu stiu de cate ori m-am dus sa probez ceva si dupa aia a trebuit sa ma imbrac la loc sa ma duc sa caut alta masura sau stil si dupa aia sa stau iar la coada la cabina de proba sa mai bag o fisa sa vad daca acu se potriveste ce cautam.

In urmatoarele magazine o sa fie niste oglinzi mari cu touch screen integrat pe aproape jumatate din suprafata si experienta o sa fie si mai high-tech ca o sa fie ca’n Star Trek sau orice alt SF de calitate, cam ca in poza de mai jos (care poza e pe bune, doar persoana de probeaza e un model retusat sa dea bine la reclama):

Treaba cu versiunile noi de magazine e misto ca poti itera prin concepte pana gasesti unul sau mai multe care se potrivesc zonei geografice unde se deschide fizic magazinul.

Traffic counters: niste camera inteligente puse la intrarea in magazin si in interiorul sau pot identifica persoanele (adica faptul ca prin magazin se plimba o persoana si nu o pisica) si fac analiza aproape in timp real pentru niste metrici de genul:

  • cati oameni au trecut pe langa magazin si cati din ei au intrat in magazin (cred ca se numeste rata de conversie sau pe acolo)
  • heatmaps cu ce zone din magazin s-au oprit cei mai multi oameni
  • vanzari medii per persoana intrata in magazin (in combinatie cu informatiile transmise de POS)
  • trail heatmaps care arata cum s-au plimbat oamenii prin magazin. asta arata interesant ca incepe cu niste liniii subtiri si se tot ingroasa in functie de cat de multi oameni se plimba.

Asta cu numaratul de persoane este foarte misto, ca daca pui harta magazinului in sistem si descrii ce se afla in fiecare zona poti sa afli super usor care sunt cele mai interesante produse pe care le ai de vanzare.

Acum toate astea sunt in sisteme diferite pentru ca fiecare producator a avut focus pe o nisa, dar prin niste API-uri cred ca se pot agrega toate informatiile astea sub o singura umbrela si doar trebuie sa dai un click sa vezi cum sta treaba intr-un magazin anume. Mai ramane de vazut daca exista acele API-uri…

Ma fascineaza tehnologia asta, ca te ajuta sa optimizezi lucrurile in cele mai mici detalii si sa faci experienta pentru clienti cat mai placuta, dar in acelasi timp ajuta si asistentii de vanzari sa fie mai eficienti. Si n-as fi stiut de ea si cum functioneaza daca nu eram implicat activ in jucaria asta cu retail-ul.

Suna naiv prima fraza din paragraful de mai sus, dar tot procesul de cumparare este mult mai simplu cand ai un pic de tehnologie la indemana.

Desi nu prea te gandesti la ce inseamna logistica din spate cand intri intr-un magazin sa-ti cumperi pantofi sau haine, este tare interesant domeniul asta pentru ca daca vrei sa fii eficient ai tot felul de dileme, de la cum atragi clienti sa intre la tine in magazin pana la cum calculezi la cat stoc sa ai si cum sa-l refaci cand se mai vand produse fara sa ai prea multa marfa blocata intr-un magazin – marfa care costa s-o produci si sa o stochezi.

cn & san

diverse

Pe vremea mea ™, când voiai să generezi un certificat, îi puneai acolo la CN sau Subject cu ce nume îl accesai sau cum îl validai, că poate îl puneai la SMTP sau la alt serviciu, trimiteai CSR-ul la semnat, primeai certificatul și erai fericit.

După aia s-a inventat SAN-ul (Subject Alternative Name) și puteai să ai mai multe “nume” pe același certificat, gen alias-uri. Și regula era cam așa: la CN puneai FQDN-ul primar și la SAN băgai cum era hostname-ul sau adresa IP sau alte FQDN-uri etc… și nu-ți dădea oroare indiferent de cum accesai serviciul atâta timp cât nimereai unul din numele alea pentru care era emis certificatul.

Acu ceva vreme m-am învârtit ca un coi într-o căldare neînțelegând de ce accesând un serviciu cu numele din CN, Chrome și Safari îmi dădeau prin gură că nu e certificatul valid, deși dacă mă uitam la Chain of Trust îmi zicea că certificatul e valid. Un fel de e valid, da de fapt nu.

Dacă accesam serviciul folosind ce mai pusesem la SAN în certificat, nu mai dădea oroare. Evident că a urmat un bă ce morții și răniții mă-sii.

După ce-am terminat de înjurat, m-am apucat să sap să văd daca m-am tâmpit sau ceva.

CAB forum a decis că utilizarea CN este opțională (secțiune 7.1.4.2 din Baseline Requirements) și chiar descurajează treaba asta.

Ei și se pare că de la nu’șce versiune, browserele astea noi precum Chrome si Safari (deși cre’că și Firefox face la fel), ce treci în CN trebuie să existe și în SAN, că acum se uită doar în SAN după sub ce nume este valid certificatul. Sau mai bine zis, CN nu mai are nici o relevanță; sau îmi scapă mie la ce mai e folosit.

Asta din categoria cum învățăm despre evoluția tehnologiei “the hard way”.

hatereala de duminica seara

diverse,

Din categoria “noi dam reboot, nu gandim”.

Asta e ultima chestie care m-a secat asa un pic, ca am asa impresia ca toti inginerii au murit intr-un canal ceva si-au ramas aia care dau reboot daca ceva nu merge.

In ultima vreme am avut asa niste experiente sa zicem interesante in care vad oameni care invata produse (software/hardware) aproape pe de rost, stiu mai mult sau mai putin unde sa dea click, da’ nu pricep ce se intampla in spate si ce inseamna click-urile alea, si cand nu merge ceva, mai dau un reboot… si inca unul… da’ e bine ca stiu sa trimita emoticoane in SMS-uri.

tcp ecn/cwr & panos – concluzia

diverse

Intr-un post de anul trecut ziceam ca astia de la PAN nu prea se pricep la cum merge Internetul.

Dupa ce le-am dat feedback negativ la indienii de la suport ca s-au incapatanat sa-mi spuna ca fac eu ceva gresit si ca nu e de la ei, m-a sunat un manager de la ei sa-si ceara scuze ca a fost suportul imbecil si ca o sa remedieze problema ca sa nu se mai intample si la alti clienti si sa escaleze cum trebuie cazurile pe care nu le inteleg si nu se muleaza pe playbook-ul lor cu “da reboot ati dat?”. Le-am dat credit ca au fost printre putinii producatori care chiar citesc feedback-ul de la clienti.

Azi citeam RN de PANOS 8.1.1 si ce sa vezi:

 TCP is hard…

lio fun stuff

diverse, , ,

Acu multi ani, cand voiai sa faci un target de ISCSI pe Linux, existau tgtd si tgtadm. Pen’ca tgtd rula in userspace, avea ceva penalitati de performanta, ca luai chestii de pe disk si le trimiteai peste retea. Niste oameni, adica Datera prin http://linux-iscsi.org/wiki/LIO au scris toata partea de target si initiator in kernel ca sa nu mai faci context-switching aiurea fara motiv.

Partea misto e ca pe langa ISCSI “normal” au implemenant si primitivele VAAI ale lui VMware si accelereaza diverse operatiuni pe care le face ESXi: gen zero-ing, copiere si scriere de date de pe acelasi LUN etc.

Intr-un proiect de acu aveam nevoie de shared storage pentru niste ESXi-uri si m-am apucat sa fac niste target-uri pe un CentOS7. Initial din toate discurile de aveam sa le export, am exportat unul singur mi-am facut treaba si restul sa le export cand aveam nevoie de ele.

Intr-o zi cu soare am ajuns si la exportat restul de discuri ca aveam nevoie de loc unde sa fac backup, sa mut niste masini pe niste discuri mai rapide etc.

Am adaugat si restul de discuri ca LUN-uri, le-am mapat in ESXi-uri si m-am luat cu alta treaba. A doua zi incepe lumea sa se agite ca bai nu mai merge “serverul”, unde “serverul” era un VM pe care lucrau oamenii. Pana a ajuns la mine asta, pana am terminat ce aveam de facut, a inceput sa mearga “serverul”. Am zis ca cine stie, o fi sughitat reteaua sau ceva (ca lumea era pe Wi-Fi si na… nu e obligatoriu sa mearga mereu ca te mai pui cu laptop-ul aiurea si poate nu ai cel mai bun semnal) si d’aia n-a mers, ca nici nu a stiu lumea sa-mi spuna exact ce inseamna “nu merge”.

A doua zi dupa incident, eram eu pe langa rack-uri si trageam de niste cabluri pe acolo, cand aud un bipait din ala de cand buteaza un server. M-am apucat sa ascult sa vad de unde e, da pana am gasit un monitor, pana l-am montat, pana am luat-o din server in server, totul era iar OK. Dupa aia am luat-o cu verificat de uptime-uri, pana dau de asta cu storage care avea uptime de cateva minute.

Evident, dictai WTF-ul pe fata mea, ca n-atinsesem nimic care sa-l afecteze. Noroc ca mai eram cu cineva acolo pe post de martor, ca zicea lumea ca-i sabotez. E, cat incercam io sa ma uit in loguri sa vad ce-ar fi putut sa aiba (bine, sperand sa gasesc loguri), vad cum incepe un kdump sa ruleze si buf, reboot iar.

Cat am apucat io sa vad ce scria pe ecran, baga ceva cu “BIOS corrupted by…”. Zic sa vezi acu distractie, ca daca e ceva de BIOS si nu exista update la producator, o sa se lase cu sugeri maxime, ca aia n-o sa fixeze peste noapte si o sa dureze pana se prind ce ma-sa are.

Cat ma gandeam eu la posibilitati si ce-ar putea sa aiba, s-a rebutat, a pornit fain frumos, a mai mers vreo 10-15 minute si iar kdump si biiip restart.

Eram asa un pic cu morcovul in cur ca 1) lumea chiar avea nevoie de storage pentru VM-uri 2) eu propusesem solutia. Mai mult 2) ma ardea maxim. Ca ma gandeam c-am pizdit-o grav. Desi era prima oara cand se intampla asta, am auzit de atatea ori scuza asta la diversi cu “pana acu nu mi s-a intamplat” ca ma gandeam ca sigur o sa ma creada din parti clientul daca zic si io asta. Ca eu sigur nu l-as fi crezut pe unul cand zice asta.

Si m-am apucat sa ma gandesc ca ma-sa s-a schimbat intre timp, ce-am facut, unde, de ce. Si nu imi venea nimic in cap sa fi facut acolo, care sa prezinte un risc. Pana cand dupa vreo ora asa, si vreo 2 reboot-uri, m-a palit ca poate e de la ISCSI ca adaugasem alea 2 LUN-uri in portal.

Le-am demonat de pe ESXi-uri, le-am sters din portal si am asteptat sa vad daca mai crapa.

Si n-a mai crapat.

Dupa ce mi-a trecut sperietura cu asta, am inceput sa ma gandesc ca “ba bine, nu mai crapa, da acu ce cacat fac cu restul de discuri, ca nu pot sa nu le mai prezint la ESXi-uri, ca am nevoie de ele”. Cat timp ma gandeam eu la asta, mi-am adus aminte de kdump. Si m-am apucat sa ma uit prin ele, ca se salvasera toate de cand a inceput sa moara kernelul.

Si mi-a trecut panica, ca absolut de fiecare data crapa in acelasi loc:

[ 5241.534120] BUG: unable to handle kernel NULL pointer dereference at 000000000000001c
[ 5241.534194] IP: [<ffffffff816abb5c>] _raw_spin_lock+0xc/0x30
[ 5241.534245] PGD 0 
[ 5241.534264] Oops: 0002 [#1] SMP 
[ 5241.536014] Call Trace:
[ 5241.536048] [<ffffffffc05d1c90>] ? target_complete_ok_work+0x180/0x330 [target_core_mod]
[ 5241.536109] [<ffffffff810a881a>] process_one_work+0x17a/0x440
[ 5241.536153] [<ffffffff810a94e6>] worker_thread+0x126/0x3c0
[ 5241.536196] [<ffffffff810a93c0>] ? manage_workers.isra.24+0x2a0/0x2a0
[ 5241.536244] [<ffffffff810b098f>] kthread+0xcf/0xe0
[ 5241.536281] [<ffffffff810b08c0>] ? insert_kthread_work+0x40/0x40
[ 5241.536327] [<ffffffff816b4f58>] ret_from_fork+0x58/0x90
[ 5241.536367] [<ffffffff810b08c0>] ? insert_kthread_work+0x40/0x40
[ 5241.536410] Code: 5d c3 0f 1f 44 00 00 85 d2 74 e4 0f 1f 40 00 eb ed 66 0f 1f 44 00 00 b8 01 00 00 00 5d c3 90 0f 1f 44 00 00 31 c0 ba 01 00 00 00 <f0> 0f b1 17 85 c0 75 01 c3 55 89 c6 48 89 e5 e8 a4 2a ff ff 5d 
[ 5241.536649] RIP [<ffffffff816abb5c>] _raw_spin_lock+0xc/0x30
[ 5241.536694] RSP <ffff88085de0fdf8>
[ 5241.536720] CR2: 000000000000001c

Bine, mi-a trecut panica ca m-am gandit eu ca ba, sa vezi ca se confuzeaza in vreo chestie de concurrency ca mai multe host-uri vor chestii relativ similare de pe mai multe discuri in acelasi timp si poate se dezaloca ceva aiurea si d’aia ajunge ala in NULL pointer dereference. Sau poate cand aloca nu si incrementeaza numarul de alocari si prima dezalocare merge da restul nu mai au cum… Sau ceva de SerDes aiurea la scrieri/citiri.

Da’ fiind in _raw_spin_lock cand crapa… slabe sanse sa pot debuga ceva, ca asta e treaba de lucruri low level in kernel.

Long-story short: mai multe LUN-uri intr-un portal exportate la mai multe host-uri != love.

Acum stiam de ce crapa, da nu-mi rezolva problema, si anume sa pot folosi toate discurile din sistem.

Si mi-am adus aminte ca atunci cand am mai avut probleme din astea cand nu mergeau mai multe lucruri in acelasi timp in kernel am folosit VM-uri se separ pe caprarii componentele.

Asa am ajuns ca pentru fiecare disc pe care trebuie sa-l export sa fac cate o masina cu KVM la care sa-i atasez discul din host, sa fac cate o configuratie simpla de ISCSI target si s-o prezint mai departe la ESXi-uri. E o solutie scarpinata pe dupa ureche, da’ merge si pentru ca virtualizare si discuri din host in VM direct, nu se observa nici un overhead.

Nu e cea mai eleganta solutie, dar merge fara prea mult efort de administrare.

ipv6 & ipsec & bugs

diverse,

Mai anul trecut la inceput de vara ma jucam io in niste masini virtuale cu Layer2 peste Layer3 in Linux. Anul asta am gasit un client unde sa bag jucaria in productie sa vad ca toate treburile merg cum trebuie si pe bune :)

Eh, pentru ca atunci cand ai optiuni multe iti vin idei, am zis ce-ar fi daca intre 2 gateway-uri de VPN as face io conexiunea pe IPV6 in loc de IPv4, ca e bine sa fim pregatiti de viitor :))

Am pus io doua CentOS 7, configurat interfete & shit, am pus libreswan, am facut un tunel IPSec si am dat ping6 intre cele doua masini si a mers jucaria (tcpdump zicea ca vede ESP pe fir).

Ca oricem om prevazator, zic sa dau reboot ca poate am uitat sa configurez ceva sa porneasc la boot si daca ramai fara curent sau s-o panica kernelul de singuratate, sa mearga treaba cand dai restart de la buton.

Si dau io restart si evident ca pula tunel. ipsec status zicea ca e in CONNECTING, da nici in loguri si nici pe fir nu vedeam vreun pachet plecat la alalalt gateway. Ce-are, ce-are. Dat restart la libreswan, o lua. Am zis ca poate e vreo problema cu libreswan, ca mai dadusem de una draguta un pic inainte.

Aia draguta era misto, ca fix imediat dupa boot nu voia sa ridice tunelul de nici un fel. ipsec auto –up $nume_conexiune zicea ca nici una din cheile RSA nu e buna de folosit pentru autentificare, insa fara a modifica nimic, dupa un libreswan restart brusc deveneau bune cheile.

De draci ajunsesem la o varianta taraneasca, dupa pornirea sistemului sa-si dau un start/stop manual s-o ia.

Hai ca zic merge tunelul, sa fac niste teste de trafic cu ping6 sa vad daca MTU-ul e cum trebuie, dau io ping6 -s 1500 si timeout. Pe la vreo 1300 bytes si ceva payload mergea. Pun de mana MTU-ul la 9000 (ca interfete gigabit) si dau iar ping6, si iar timeout. Mai dau si un restart lu’ libreswan (ca vorba aia: when in doubt, restart) ca poate fiind pornit se uita o data la MTU si dupa aia o tine cumva cont de el. tcpdump zicea ca pachetele pleaca da nu ajung.

Uite asa m-am trezit io in zona crepusculara, unde lucrurile in teorie trebuiau sa mearga iar in practica erau diferite de teorie. Si e frustrant ca zici ca, mortii ma-sii, e un VPN, mai mult de cateva ore n-are ce sa ia, ca doar ma dau cu IPsec pe Linux de cand eram mic si stiam ce fac.

Dupa o zi de injuraturi, am oprit IPSec, si zic hai ca in clar tre sa mearga cacatul si o iau dupa aia pe dos sa vad unde se strica. Intre astea doua masini aveam un switch ca sa simulez realitatea. Si zic sa pun un cablu direct intre ele sa elimin orice element in plus care ar putea sa induca erori.

Evident, cu cablu direct mergea treaba de n’avea aer. Acuma switch-ul avea porturi gigabit si cablurile erau bagate in el in porturile alea. Si totusi ce n’avea switch-ul pe porturile gigabit? Jumbo frames in pizda ma-sii. Jumbo frames n-avea. Ca HP in vasta sa inteligenta s-a gandit ca probabil nu sunt bune si n-a implementat suport pentru ele in switch. Si uite asa ai conexiune la gigabit da cu frame-uri de maxim 1504 bytes, sa incapa si un VLAN tag acolo da nimic in plus.

Dupa dracii cu HP, m-am intors la problema initiala, de ce ma-sa dupa reboot n-o ia tunelul. S-a facut tarziu si m-am dus sa dorm.

Evident ca n-am dormit ca ma rodea problema, mi-am facut repede un laborator cu doua CentOS 7 si zic sa incerc strongswan in loc de libreswan, ca poate o avea ala suport mai bun pentru ce fac. Suport in a vorbi cu framework-ul de XFRM din kernel unde se intampla magia.

Fac repede o configuratie si dau reboot la un nod, si dupa reboot pula tunel. Dupa niste tcpdump ma loveste problema: Cand un neighbor IPv6 vrea sa afle ce adresa MAC are alt neighbor, trimite pe multicast FF02::1 un mesaj de Neighbor Solicitation (echivalent de mesajul trimis pe broadcast in IPV4 pentru a afla MAC-ul unui computer din reteaua locala) si primeste unicast un raspuns.

Ce se intampla in kernel in combinatie cu IPSec-ul: pachetele de solicitation plecau cum trebuie si ajungeau la alalalt nod, ala raspundea unicast si nodul care a trimis solicitarea le ignora pentru ca… tananana… se astepta sa fie criptate conform configuratiei (SA-urile erau facute intre 2 /128).

Acu la 2 noaptea stiam care e problema, sa o si rezolv:

conn ipv6nd
   auto=route
   keyexchange=ikev2
   authby=never
   type=passthrough
   leftsubnet=2001:abc:def:ffff::2/128[ipv6-icmp/136]

Unde leftsubnet reprezinta IP-ul aluilalt gateway, iar pe ala se face pe dos configuratia. Et voila, merg chestiile dupa configuratia asta.

Ce inseamna ce-am facut mai sus? Inseamna ca sistemul va accepta pachete ICMPv6 Neighbor Advertisement necriptate. E important ca regula asta sa fie scrisa prima in config ca sa aiba precedenta fata de urmatoarele. E ca la firewall, de sus in jos :)

Asa, acu c-am rezolvat-o, am trecut la pasul urmator. Tipul conexiunii era de tip transport, ca aveam treaba sa protejeze doar traficul intre cele 2 gateway-uri.

Peste am facut un tunel L2TPv3 si cateva sesiuni sa car niste VLAN-uri dintr-o parte in alta. Pe fiecare cap aveam o interfata fizica cu tag-uri de VLAN, una de pseudowire, ambele bagate intr-un bridge.

Pe o interfata de bridge am pus o adresa IPv4, la fel si pe alalalt gateway si minune… mergea ping-ul intre ele. Scopul declarat fiind sa le folosesc pe post de adrese de management pe un VLAN de management.

Cu experimentul pe IPv4 reusit, am pus un set de adrese IPv6 pe interfetele de bridge asteptand acelasi rezultat. Si-am asteptat, si-am asteptat… cum asteapta un caine parasit stapanii care nu se mai intorc.

Pentru ca IPv6 e special, cand ai o adresa pusa pe interfata de bridge, neighbor solicitation nu se duce doar pe interfetele de compun bridge-ul, ci pe toate interfetele din sistem, mai putin pe alea de pseudowire.

Aci ma panicasem un pic, ca sa nu pot sa fac management pe IPv6 nu era un capat de lume, da incepusem sa ma gandesc ca daca se intampla la fel si pe trafic intre 2 host-uri din acelasi VLAN care trec prin jucaria mea?

Well, aci am avut noroc si asta nu se intampla. De aflat am aflat testand si injurand iar HP-ul ca are ceva cu pachetele de IPv6 multicast si nu merge Neighbor Discovery. O sa investighez daca intr-o versiune mai noua de firmware au facut lucrurile sa mearga.

De ramas am ramas la strongswan din mai multe motive:

  • pare mai robust fata de libreswan
  • suporta DH Group 19/20/21 (curbe eliptice, chei mai mici, securitate mai mare)
  • suporta chei de tip ECDSA (cu ocazia asta mi-am facut si niste certificate digitale pe 521biti de tip Elliptic Curve)
  • nu are dilemele lui libreswan cu cheile (ba sunt bune, ba nu sunt bune)
  • merge OK partea de fragmentare a pachetelor care depasesc MTU la nivel de IKE (e misto sa dai ping cu -s 65000 si sa mearga fara sa faci nimic)
  • are suport de TFC (traffic flow confidentiality) pe IKEv2 in mod tunel. Asta inseamna ca face padding pana la MTU-ul interfetei si indiferent de cat trafic ai de fapt, unu care sta cu urechea pe fir va vedea mereu pachete de 9000 bytes (in cazul gigabit ethernet), fara sa stie exact cat sunt date utile si cat e gunoi.

Cu procesoare care au AES-NI (Intel Ivy Bridge sau mai noi) exista si accelerare hardware pentru criptare, via aesni_intel, mai ales daca AES e folosit in GCM. La fel, functiile de hash pentru integritatea datelor pot fi efectuate direct pe procesor prin sha512-ssse3 daca se foloseste SHA512 la IPSec.

Long story short, merge. Bine, merge da violat un pic tot setup-ul ca am dat de un bug in kernel care e nefixat in toate versiunile cu care am testat, adica de la 3.10 la 4.5 sau 4.10 cat era ultimul din CentOS 7 plus cand am testat.

BUG-ul e super misto: dupa cam o saptamana, moare treaba si fara reboot nu-si revine. Si asta se intampla pe ambele gateway-uri.

Dupa miliarde de draci si debug in fata serverului cu monitor si tastatura ca in vremurile bune, am descoperit problema, si anume un leak in kernel, mai mult de file descriptors din ce am bunghit pana acum.

Ce se intampla, ca e atunci cand se schimba cheile, nu se face free la esp6 si xfrm6 daca pe aceasi masina e si un tunel L2TP pentru setup-ul de pseudowires. Si creste utilizarea modulelor pana se strica jucaria.

[root@vpn-gw-1-1-c7-v ~]# lsmod | grep esp6
esp6 17180 1566 
[root@vpn-gw-1-1-c7-v ~]# lsmod | grep xfrm6
xfrm6_mode_transport 12631 3132

Si cand ajungi la cateva sute sau chiar mii, pocneste si nu mai merge. Si asta doar in combinatie cu modulul de L2TP pentru IPv6.

Pentru a rezolva asta, varianta cea mai buna a fost sa fac o masina virtuala in care sa termin partea de L2TP. Adica pe masina fizica am partea de IPSec intre capete, dupa care pe masina virtuala am facut multe interfete: una de inbound pe unde vin pachetele de L2TP si multe pe care sa scot pachetele in cate in un bridge, VLAN tagged sa le dau mai departe.

Postul asta trebuia sa-l public anul trecut cam acum (28 Septembrie 2016), da am uitat de el, da nu conteaza, ca BUG-ul nu e fixat nici acu si jucaria merge de atunci, line rate, fara nici o problema. Ar fi frumos sa fie si BUG-ul ala fixat pentru simplificarea setup-ului.

Cum setup super perfect nu exista, acum e un pic urata adaugarea de noi VLAN-uri pe acelasi pseudowire, in sensul ca trebuie sa le adaug de mana si sa editez si fisierele de configuratie astfel incat sa fie ce trebuie la reboot. Asta e din cauza ca pe CentOS nu exista script de network pentru a seta interfete de tip l2tp_eth. Insa e OK, ca nu schimb zilnic setari.

#slack

diverse,

De prin Noiembrie asa de cand sunt intr-un contract nou lucrez intr-o echipa distribuita, fiecare de pe unde apuca. Pentru comunicatie si sincronizare la ce facem folosim Slack.

Slack, pentru comunicatie e asa… “the next best thing since sliced bread”. Poti sa te uiti sa vezi ce au discutat oamenii inainte sa intri pe un canal, ca de exemplu ce zicea lumea inainte sa vii in corporatie. Sa pornesti clientul si sa te lase acolo unde a inceput convorbirea de cand te-ai logat ultima oara.

Se integreaza cu tot felul de aplicatii (gen Dropbox pentru link-uri la poze/documente). Eu sunt mare fan ca pot sa uploadez poze cu diverse chestii, pot sa fac highlight pe text, pot sa editez ce-am scris (in mare parte pentru a corecta typo-uri), pot sa fac echivalentul a preformatted cand am snippet-uri de configuratie sau cod.

Si arata super bine. Fontul la scris, temele, cum sunt aranjate discutiile. Poate nu parea important, da pentru mine conteaza sa nu folosesc aplicatii care-mi displac cum arata.

Ce suge la Slack sunt thread-urile, da ii dau asa doar juma de bila neagra ca abia au fost introduse si probabil o sa le mai schimbe de cateva multe ori pana o sa gaseasca formula sa arate si alea normal si decent.

Nu e Slack o noutate, da voiam de mai demult sa scriu despre un el ca pur si simplu este foarte misto si pentru cine n-o fi auzit de el, recomand cu cea mai mare caldura.