Category Archives: diverse

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.

tcp ecn/cwr & panos

diverse,

Scriu postul asta in aproape Noiembrie 2017. Nu ca n-ar avea blog-ul timestamp, da e bine de retinut ca e vorba de sfarsitul lui 2017. Si e important acest aspect.

Pentru un client cu nevoi de Client-to-Site VPN am ales sa folosesc PaloAlto Networks VM-100. Ca are capabilitati misto, e super click-click de folosit, si pe langa VPN pot sa fac si alte lucruri bune cu el in retea.

Cum focusul principal e VPN-ul acum, m-am apucat voiniceste sa configurez GlobalProtect sa ajunga lumea de pe unde o fi in reteaua interna. Si da-i si configureaza, salveaza si incearca sa te conectezi pe portul 443 la firewall sa te loghez in portal sa downloadezi clientul, sa-l instalezi si sa te conectezi.

Pula. Ca nu mergea neam. Vreo 3 zile am incercat toate bifele de acolo, ca poate imi scapa mie ceva. Bai da nimic. O singura regula de firewall cu Any-Any-Allow-Log. Ca nu pot da gres cu asta cand lasi traficul sa curga in toate directiile.

Dupa ce n-a vrut si n-a vrut, am zis sa sun pe cine stiam eu ca s-a mai dat cu PaloAlto. Se uita omul, face config de la zero ca eu il stersem sa nu fi uitat vreo chestie si sa debugheze aiurea. Rezultatul: fix pula. Coincidenta face ca omul sa fie fost la un curs de refresh de PAN si l-a pus si pe ala de era instructor sa se uite. Teoretic trebuia sa mearga, practic nu mergea.

Si ca sa fie treaba si mai si, cateodata puteai accesa portalul pentru cateva minute pana cand iar nu mai mergea, dar doar daca fix in acelasi timp te dadeai pe interfata de management a echipamentului. Ca daca tot e voodoo, sa fie pana la capat.

Plecand de la premisa ca e buna configuratia, omul de l-am sunat s-a apucat sa faca dump de pachete, sa vedem daca ajung la jucarie. Si ajungeau bine mersi, doar ca erau “silent dropped”. De ce? Pai pentru ca toate pachetele de SYN aveau si flag-urile de ECN si CWR setate. Cu care firewall-ul nu avea nici o problema sa le accepte pentru management, dar avea o problema cand se duceau spre portalul minune pentru VPN. Care stau in mortii lor fix pe acelasi echipament, si pachetele trec fix prin acelasi loc si morti in inima, singura diferenta e portul pe care stau componentele.

Sa retinem, la sfarsit de 2017 inca mai sunt unii si altii care nu au auzit de ECN.

Pentru ca eu n-am ce sa-i fac, m-am apucat sa vorbesc cu suportul. Care primul nivel de suport este evident format din indieni incompetenti, dar care sunt foarte bine dresati sa caute motive sa dea vina pe tine din ce cauza nu merge jucaria si sa inchida cazul. Si sa scrie in notitele de la caz aproape orice altceva decat ca este o problema cu produsul.

Ultima scremere e ca IP-ul extern il iau prin DHCP si s-a gandit Pradeep ca poate de acolo e, desi el se conecta pe interfata de management la echipament fix prin acea interfata. Dar probabil ca in logica indieneasca o avea vreun sens.

Si cireasa de pe tort (cel putin pana acum) e ca dupa ce am stat iar cateva ore sa refaca configuratia de cateva ori, a scris pe notitele de la caz ca “we discussed that this is a cosmetic issue”. Asta o zic asa, sa nu zica lumea p’aci ca’s am ceva in mod gratuit cu indienii cand zic despre ei ca majoritatea sunt imbecili “summa cum laude”.

Asta dupa ce prima oara mi-a zis senin ca “da, pai dezactiveaza ECN pe clientii care o sa se conecteze si asta”. S-o dezactivez pe ma-sa. Ca daca voiam sfaturi cretine despre cum sa depanez problema ma duceam in parc sa discut cu un caine despre asta.

Si acu ca sa ma laud, am gasit si workaround temporar la problema pana ma termin de certat cu astia si isi fixeaza cacatul de produs. Am mai configurat o interfata pe firewall, am bagat-o intr-un alt VR si am legat-o intr-un Linux, legat fix pe DHCP la acelasi provider. Si pe Linux am un redir care asculta pe 443 pe interfata externa si trimite toate conexiunile pe IP-ul de pe interfata de la firewall. Ca stack-ul de IP de la Linux nu e scris de oameni care nu stiu sa citeasca un RFC si sa implementeze corect ce scrie acolo si il doare fix intre buci ca vin pachete cu SYN+ECN+CWR. Si uite asa merge treaba, cu workaround-uri din astea tembele. La workaround-ul asta am ajuns gandidu-ma cum sa fac sa scap de flag-urile alea fara sa impactez clientul.

Deci da, nu toata lumea stie ca internetul a mai evoluat din 2000 pana azi.

distributed teams

diverse

De cand o ard freelancer, cu exceptia proiectelor in care ma duc cateva zile la client sa fac cate o chestie punctuala, lucrez in echipe distribuite pe proiecte la distanta:

  • eu si cu oamenii de la client
  • eu, alti freelanceri si oamenii de la client

Ce inseamna distribuit? Pai ca fiecare suntem pe unde ne nimerim si facem treaba impreuna. Fiecare cu ce stie mai bine cand e super mult de treaba, sau fiecare cum e mai liber sau cand e ceva de depanat si trebuie sa ne punem capetele la contributie.

Cel mai important in toata treaba asta e sa ne sincronizam cu ce facem, ce planuri avem etc. Pentru ca nimeni nu poate tine minte tot ce-a zis, sau ce-o sa facem sau cum, mai ales cand nu ai mintea intr-un singur loc tot timpul, dar chiar si-asa.

Ce merg ca si tool-uri pentru asta:

  • Slack (in mare parte) pentru conversatii in timp real care sa ramana si scrise, snippet-uri de configuratii sau cod, iar in ultima vreme chiar si pentru conferinte. Skype e o idee super proasta pentru ca mai pierde mesaje, clientul se misca super greu cand sunt multi oameni care scriu (cel putin ala nou de pe mobil e o retardare crunta).
  • Skype/Hangouts in mare parte pentru conferinte. Desi pe Skype merge cu clientii corporate ca nu-i lasa politicile de firma pe Slack. In principiu merge orice solutie de videoconferinta care permite si screen-sharing.
  • JIRA. Urmarirea task-urilor, “accountability” in sensul de cine ce-a facut si cand. Exista si alte sisteme de ticketing, insa pe unde m-am dat doar JIRA era.
  • Google Docs pentru prezentari, scris documente in echipa (ocazie cu care am ajuns sa urasc mailurile alea cand se plimba un document pe la fiecare sa mai scrie ceva in el si dupa aia ala de trebuie sa le puna cap la cap se sinucide subit).
  • Confluence (unde e) pentru documentat procese, arhitecturi, howto-uri si alte cele. Acum mai nou (de anul asta) stie si asta de editare concurenta, ceea ce e foarte misto. Daca nu e confluence, atunci Wiki-ul din GitHub. Sau orice altceva tip Wiki unde sa ai mereu informatia la zi.
  • GitHub pentru cod. De obicei scripturi sau chestii de configuration management. Merg si solutiile hosted precum GitLab, da tre’ sa ai grija de ele :))

Ca toata treaba asta sa mearga bine, e nevoie de doua componente esentiale:

  • Comunicarea (duh). Adica sa fii la curent la ce lucreaza membrii echipei, sa spui cand te apuci sa faci ceva sa nu se trezeasca altul ca i-ai restartat masina pe care lucra, iar in cazurile sensibile sa explici ce vrei sa faci si de ce ca sa elimini erorile de gandire. Ca desi poate ai o idee buna, aplicand-o strici mai multe decat repari.
  • Procesul. Adica treaba de mai sus sa zici ce faci, tichete prin care se poate urmari progresul si documentarea operatiunilor sau, dupa caz, adaugarea de comentarii utile in cod sau pe commit-urile de git. E foarte important aici sa n-o arzi “cowboy style” ca se duce totul pe pula super repede.

Periodic, o data pe saptamana sau mai rar/des in functie de volumul de munca si de cati sunt in echipa, niste teleconferinte de sincronizare fac minuni. E ca terapia in grup: fiecare spune la ce lucreaza, raspunde la intrebari de la altii ca sa inteleaga lumea mai bine lucrurile, se formuleaza planuri, se dezbat si se trag concluzii.

Este de remarcat faptul ca in functie de cat de OK este echipa si de cum se raporteaza membrii echipei unii la altii, cu atat mai productive sunt aceste teleconferinte. Suna a truism, dar daca raportul de forte este dezechilibrat, rezultatele nu vor fi chiar cele asteptate.

Lucrul asta merge super bine cand te cunosti cu aia cu care vorbesti, si bine cand nu te cunosti dar esti “on the same page” sau la acelasi nivel de cunostinte. Si prost, evident, cand nu exista deloc aliniere intre oameni, cunostinte si proiect.

Ce nu merge prea bine e cand faci lucruri remote si nu te-ai vazut niciodata cu oamenii cu care lucrezi si exista intelegeri diferite asupra aceluiasi lucru. Treaba asta am rezolvat-o prin a ma duce sa ma vad cu oamenii, sa vorbim, sa discutam si de alte chestii in afara de munca si atunci lucrurile se imbunatatesc.

Fara un pic de “personal touch” nu prea merge treaba asa cum ar trebui, si prin asta se elimina multa neintelegeri si sincope in colaborare.

Evident, sunt si lucruri care nu merg distribuit daca co-echipierii nu au experienta cu ceva anume si este si greu sa explici cum vrei sa arate lucrurile de la distanta. Oricate desene ai face, nimic nu se compara cu dusul la fata locului si explicat/aratat ce si cum. Dar aici se aplica treaba cu vizita la fata locului descrisa mai sus.

Ziceam la inceput ca “fiecare pe unde e”. Asta poate insemna mai multe lucruri:

  • fiecare e in acelasi timezone sau +/- o ora, maxim doua.
  • fiecare e pe continente diferite.

Pentru proiectele care necesita lucru cu clientul in timpul programului lui de lucru, atunci e  bine sa nu fii la prea multe ore distanta fata de client; ca nu e nici o distractie sa ai conferinte la 4 dimineata sau la 12 noaptea, sau sa incepi programul la 17 si sa termini la 02. Sau sa incepi la 4 dimineata sa apesi butoane. Cel mai important aspect fiind ca-ti futi tot ritmul circadian si o sa fii mereu defazat fata de restul societatii, da daca esti mai “special” e ok, nu pierzi nimic :))

Pentru proiecte cu activitati asincrone si fara restrictii, cum ar fi tichete care trebuie rezolvate/implementate oricand, atunci orice loc cu ceva Internet e suficient, ca poti fi si +/- 11 ore fata de client ca n-are importanta.

Astea fiind zise, cand lucrezi distribuit sau solo, ideal ar fi sa ai numai clienti care nu necesita sa fii si tu treaz cand sunt ei la munca, si in felul asta sa poti sa te plimbi peste tot in lume ca n-ai nici un impediment. Sau mai bine zis, asta ar fi “the perfect work/life balance” ;)

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.

freelancing

diverse,

Problema, ca sa zic asa, cu job-ul e ca trebuie sa te duci la birou. Sa vezi oameni, sa interactionezi cu ei, chiar daca-ti place sau nu. Si sa stai la program. Nu peste tot e nevoie, da in mare parte cam asta e regula. Si pe langa chestiile interesante de la job,mai sunt si restul de cacaturi neinteresante si de-a dreptul complet enervante pe care trebuie sa le faci. Pentru ca ai sefi si pula mea, aia au idei. N-am vazut niciodata o fisa de post care sa nu se termine cu “si trebuie sa faci si orice alte lucruri pe care le zice sef’tu”. In caz ca au uitat aia de la HR sa scrie tot ce trebuie sa faci ca sa fie acoperiti legal.

Prin 2015 m-am gandit ca ar fi cazul sa renunt la ideea asta cu statutul de angajat asa in urmatoarea perioada. Mi-a placut in 2013-2014 treaba asta cu rolul de contractor prin desert. Vii, faci treaba, iei banu’ si pleci. Te eneverzi un pic, da la sfarsitul lunii te simti bine cand ai buzunarul greu :)) Cre’ca ce mi-a pus capac asa au fost cele 3 luni de UK cand ma sufocam in “procese si proceduri”. Cu chestiile astea sunt mai din topor asa: vreau sa fac treaba, nu sa ma fut in proceduri si sedinte si celelalte pisaturi corporatiste prin care unii si altii isi justifica existenta.

(poza luata cu nerusinare de pe imgur)

Si uite asa m-am apucat eu de prostitutie intelectuala. Pentru o suma oarecare, clientul are acces la cunostintele mele pentru o ora. Mai vrea o ora, mai baga niste fise. Ca la curve.

Pentru mine a cumva varianta OK de antreprenoriat in oferirea de servicii. Riscul e ca daca nu mai gasesc proiecte mai stau pe bara un pic, insa nu am stresul ala cand ai si angajati si te gandesti ce faci cu ei daca n-ai proiecte.

Uitandu-ma inapoi, e cea mai buna decizie de-am luat-o intr-o lunga perioada de timp. Imi pare rau ca nu m-am apucat sa fac asta cu mult mai mult timp inainte. Da-i prostului mintea cea de pe urma, cum zice proverbul…

Treaba asta e mai motivatoare ca orice bonus de l-ai putea lua ca angajat undeva: cu cat faci treaba mai buna, cu atat ai sanse sa mai ai contracte cu clientii si sa te recomande mai departe si tot asa sa iti faci un portofoliu frumos, sa castigi si mai multa experienta. Si sa faci bani. Ca pana la urma, trecand peste orice vise hippie pe care le mai am eu din cand in cand, fara bani poti s-o arzi romantic doar foarte putin timp. Si dupa o varsta parca dormitul pe jos intr-un sac de dormit sau intr-o masina nu mai e asa amuzat.  O dai de gard, nu faci bani, mori de foame. Cum zic americanii “it keeps me on my toes”.

Exista un singur stres, si ala e sa fii mereu la zi cu cunostintele, ca de aia te ia lumea – ca esti expert, cu ce se intampla in industrie, cine ce mai zice, cam ce se preconizeaza sa se intample in viitorul apropiat si tot asa. Bine, mult spus stres, ca e o asteptare normala sa fii la curent cu diverse chestii de pe langa tine. Noroc ca nu se fac revolutii tehnologice peste noapte.

Pe langa cunostinte, ce conteaza super mult e experienta. Din a mea am invatat ca daca stiu multe lucruri, pot sa iau decizii mai bune in proiecte, pot sa fac inferente mai bune cand ceva se strica si pot elimina repede posibile cauze sau pot gasi solutii creative.

Experienta cel mai bine si mai repede capeti facand lucruri variate si diverse. Intr-o zi o retea, in alta zi un deployment de servere, in alta zi un design sau o implementare de WiFi, mai o arhitectura completa de sisteme. Si bineinteles multa inginerie.

Daca trebuie sa faci treaba la sediul clientului, o sa ai mereu colegi noi, si cum contractele astea nu tin foarte mult, n-au timp sa te enerveze prea tare :)) Si cu unii chiar ajungi sa te intelegi OK si uite asa nici partea cu socializtul nu sufera prea mult.

Daca faci treaba la distanta, atunci si mai bine. Nu trebuie sa vezi pe nimeni in jur si poti sa-ti faci treaba linistit. Asta iarna n-am interactionat cu nimeni vreo 2 luni. Ma uitam pe geam, vedeam mormanul de zapada de afara, bagam repede un “Fuck this shit” si ma intorceam in pat la caldura. Singurele iesiri din casa erau la Mega Image si sa dau zapada jos de pe masina si sa fac curat in jur ca sa pot sa plec repede de acasa in caz de vreo urgenta ceva. Cumva, avand treaba, iarna asta am reusit sa nu ma ingras deloc stand in caz ca o leguma.

Dezavantajul in a lucra la distanta e ca te cam salbaticesti stand prea mult timp prin casa. D’aia in ultima vreme am inceput sa ma campez prin diverse firme, sa mai vad oameni la fata, chiar daca n-am nici un proiect cu respectivele firme.

Acum, cu treaba asta de freelancing, am cateva probleme:

  • Necesita foarte multe disciplina sa te concentezi la lucruri utile cand de exemplu ai de fapt chef sa te uiti la un film. Si nu se uita nimeni urat la tine ca e 11 si te uiti la seriale :))
  • Cateodata n-am chef de facut treaba cu zilele. Si asta ma costa mai mult decat vreau sa recunosc. Cre’ca mi-as da cu ciocanul in degete si cu tesla in coaie in acelasi timp daca as primi banii in avans si dupa aia ar trebui sa-i dau inapoi ca nu i-am muncit.
  • Nu scaleaza. Munca de facut e, dar nu te poti multiplica si nici nu poti munci 24 de ore pe zi. Si dupa 12-14 ore de munca zi de zi in perioadele aglomerate tot ce vrei e sa dormi si sa te mai trezesti peste o saptamana. Si cand esti liber si bagi acolo 3-4 ore pe zi iti doresti sa ai mai mult de munca. Si cand ai vrei mai putin si tot asa. Si piata e dispusa sa plateasca un om un maxim pe ora si nu poti cere mai mult doar ca esti tu super ocupat. Ca mai sunt si altii care stiu sa faca ce faci tu, si sunt mai putini ocupati. Si desi imi place sa cred ca’s super special, sunt la fel de super special ca restul de super speciali. Singura varianta e sa-mi construiesc o reputatie si mai buna, sa imi pun la punct niste procese de a face treaba super-eficient si atunci sa pot sa cer mai mult pe o bucata mai scurta de timp.

Pe langa cele de mai sus, cea mai mare problema pe care o am e ca atunci cand vine vorba de potentiali clienti si de explicat ce stiu sa fac, sunt mega autist. Adica pe scurt, nu stiu sa ma exprim in termeni prin care sa ma fac inteles. La intrebarea “ce stii sa faci”, se pare ca “ce vrei tu boss” nu e raspunsul potrivit… Da’ lucrez intens la asta sa invat sa ma promovez/vand mai bine. Noroc cu ma mai stie unul si altul si ma recomanda :))

Am primit un pic de feedback pe partea asta si se pare ca sunt prea exhaustiv in explicatii si nu sumarizez cum trebuie lucrurile importante. Cumva sunt constient de treaba asta, dar sunt un pic tras din spate de faptul ca eu cred ca daca cineva mai departe trebuie sa ia o decizie pe baza a ce spun eu, e bine sa inteleaga si cum am ajuns eu la concluziile respective. Asta si faptul ca mereu am fost deschis cu toata lumea.

Cel mai mare risc in treaba asta este sa sa se anuleze proiectul din senin si sa te trezesti ca daca aveai planuri, le poti tipari linistit pe hartie moale si dupa aia sa te stergi la cur cu ele. Si sa incepi sa-ti cauti proiecte noi daca nu cumva se anuleaza iarna cand e un moment bun sa te duci in vacanta.

Ce-ti da freelancing-ul e libertate. Libertatea de a alege ce vrei sa faci, cand vrei sa faci, cum vrei sa faci (in limite, ca poti sa ai cea mai mega geniala idee, ca daca clientul are buget de un arc cu sageti, n-o sa poti face niciodata un tanc de banii aia, desi tanc e ce-i trebuie). Si daca nu vrei sa faci ceva, iar e bine. Pana ramai fara bani :))

Bine, trebuie sa stii si ce sa faci cu libertatea asta, ca nu e chiar pentru toata lumea. Zic asta pentru ca am futut la timp liber… asa cu nemiluita. Ca nu stiam sa-l apreciez. Si acum nu mai pot sa-l iau inapoi. Ceea ce suge maxim, dar asa capeti experienta…

TL;DR: m-am facut freelancer, imi place, yay me!

PS: Nu mai scrisesem de mult p’aci, si nu, n-am mierlit-o ca am facut glume proaste la momentul nepotrivit, ci am avut super multa treaba si inca mai am. Si visez sa se termine anul o data sa ma duc intr-o vacanta super lunga sa-mi clatesc creierul.

wonder woman

diverse

Me likey.

In sfarsit am impresia ca s-au prins si astia de la DC Comics cum sa faca un film cu super eroi care sa nu suga. Sper ca Justice League sa fie la fel de bun sau poate chiar mai bun ca au loc de povesti pe acolo.

ubuntu 16.04 pxe install

diverse

De anul trecut am trecut incet, incet spre DevOps. Mai bag si pe security, da mai rar in ultima vreme.

Doar Ops n-am mai facut de ceva vreme si evident, ca m-am mai ramolit un pic pe partea asta. Iar cu Dev-ul din DevOps  o lalai in Python, ca e bun pentru a programa chestii de sistem.

Pentru un client nou, am avut de facut un server de deployment pentru niste servere fizice astfel incat sa bagi serverul poaspat scos din cutie in priza, sa-l conectezi la retea si 15min mai tarziu sa-l ai instalat. Bine, depinde de viteza mirror-ului asta, ca prin unele tari merge intrnetul de zici ca’l aduc cu galeata.

Ca si distro am folosit Ubuntu 16.04 LTS pentru ca $reasons.

Partea usoara e sa instalezi un server de TFTP si un server de DHCP care sa aloce IP-uri si sa spuna la clienti cum se cheama fisierul pentru BOOTP.

Ca si server de deployment am folosit tot un Ubuntu 16.04, sa fie instalarea intre prieteni sa mearga bine si fara probleme :))

Si pentru ca multe servere, evident ceva care sa faca orchestrare si management. Si ca ziceam mai sus ca o lalai cu Python, SaltStack a fost raspunsul.

Asa ca, cum se face sa deployezi multe servere fizice in vremea lui AWS, GCP si Azure:

  1. Se instaleaza atftpd, se modifica  /etc/default/atftpd si se schimba USE_INETD din true in false. Dupa care systemctl enable atftpd si systemctl start atftpd.
  2. Se downloadeaza un ISO de Ubuntu Server 16.04 si se monteaza cu loop pe sistem.
  3. Se copiaza de unde s-a montat ISO continutul directorului netboot in /srv/tftp.
  4. Dupa nevoie se editeaza /srv/tftp/boot-screens/menu.cfg astfel incat sa bata cu realitatea la fata locului. Cateva note la exemplul meu:
    1. installerul e retardat si daca serverul de DNS raspunde cu AAAA RRs, o sa vrea sa se conecteze pe IPv6 la mirror, chiar daca nu are ruta default pe IPv6.
    2. A.B.C.D se inlocuieste cu adresa IP a serverului de TFTP
    3. eno3 e cum stiu eu ca se cheama interfata de retea pe care o foloseste masina ce va fi instalata pentru DHCP, pentru ca in cazul meu aveam mai multe interfete si se blocheaza installer-ul si te pune sa alegi una (chiar si cu optiunea auto tot la fel face).
  5. Se creeza /srv/tftp/preseed/ubuntu-16.04-preseed.cfg unde se va scrie configuratia pentru installer. La fel, cateva note la exemplul meu:
    1. Installer-ul va crea un setup de tip RAID10 din primele patru discuri de pe sistem. Recipe-ul de RAID l-am bunghit cu #mumu help, ca nu prea e documentat cum se face. E un pic de magie in toata treaba aia.
    2. Peste va configura LVM si / va fi un LV de 30GB pe VG-ul nou creat.
    3. In cazul in care masina va avea mai multe interfete de retea, trebuie specificat ce intefata sa foloseasca in mod automat. Altfel va sta ca boul asteptand sa selectezi pe care sa o folosesti.
    4. $magic_postinstall_setup_script poate fi orice script (bash, python, perl etc.) care face chestii pe sistem inainte de reboot dupa instalare. Scriptul asta de obicei se pune pe un server web, se downloadeaza si se executa. O sa revin mai tarziu cu ce si cum.
  6. Se instaleaza isc-dhcp-server si se modifica /etc/dhcp/dhcpd.conf sa dea adrese dintr-un pool la clienti si se adauga urmatoarea optiune in definitia de subnet:
  7. filename "pxelinux.0";

    systemctl enable isc-dhcp-server si systemctl start isc-dhcp-server.

  8. Se buteaza o masina fizica si se asteapta pana termina de instalat. Daca da oroare sa ceva, trebuie fixata in fisierul de preseed, reboot si de la cap cu instalarea pana merge. Nu exista checker pentru fisierul de preseed. Pe mine m-a enervat maxim treaba asta ca instalarea se facea pe niste Dell R430 si pana buteaza alea mori incet.

Ziceam mai sus ca inainte de reboot, pot da comenzi in sistemul nou instalat sa-l configurez cumva inainte sa porneasca prima oara.

d-i preseed/late_command string \
 in-target wget -P /tmp/ -t 0 -c http://A.B.C.D/myscript.sh; \
 in-target chmod +x /tmp/myscript.sh; \
 in-target /tmp/myscript.sh; \
 in-target wget -P /tmp/ https://repo.saltstack.com/apt/ubuntu/16.04/amd64/latest/SALTSTACK-GPG-KEY.pub; \
 in-target apt-key add /tmp/SALTSTACK-GPG-KEY.pub; \
 /bin/echo "dev.raid.speed_limit_max = 1000000" >> /target/etc/sysctl.conf; \
 /bin/echo "deb http://repo.saltstack.com/apt/ubuntu/16.04/amd64/latest xenial main" > /target/etc/apt/sources.list.d/saltstack.list; \
 in-target apt-get update; \
 in-target apt-get install -y salt-minion

Se pot da comenzi succesive in late_command. Ce trebuie stiut:

  1. Cuvantul in-target ii zice installer-ului sa faca chroot() in noul sistem si sa execute comanda de acolo.
  2. Comenzile date fara in-target se ruleaza de pe mediul de instalare (din installer cum s-ar zice).
  3. Se foloseste combinatia normala + in-target ca unele comenzi nu merg in chroot, ca de exemplu echo $stuff merge doar din installer, in chroot nu merge. Poate imi scapa mi ceva, dar sa stau sa debughez asta dura prea mult.

Ziceam ca pentru orchestrare si configurare am mers pe SaltStack. Eu pentru ca are minioni, colegul de proiect ca i s-a luat de Puppet. Bine, nici eu nu m-am omorat dupa Puppet ca e scris in Ruby.

Cine a facut SaltStack asta a fost inteligent si minionii daca n-au nici o configuratie, o sa incerce sa se lege la salt.domain.name. Si asta inseamna ca tot ce trebuie sa am este un salt-master instalat si configurat acolo un pic, configurat DNS-ul atfel incat salt.domain.com sa bata la un serverul pe care ruleaza salt-master si, dupa ce fiecare masina fizica se rebuteaza, minionul se va conecta automat la salt-master. Magie adevarata.

salt-key –accept-all este raspunsul la intrebarea cum confirm ca minionii inregistrati sunt ai mei :)