- Am ajuns sa traiesc in Ticketland. Pentru orice chestie trebuie sa deschid un ticket la Service Desk.
- Cand indienii ma fac trist, ma duc si-l intristez pe sef’miu. Care se duce sa-i intristeze si mai tare pe indienii de m-au intristat. Dupa aia e totul bine. Pana data viitoare.
- Au trecut 4 saptamani de nici nu stiu cum. Pe principiul “sa dai chestii tipului nou” am primit de facut vreo 6 proiecte cu altele pe teava. Sa fie, sa nu ma plictisesc.
- Astia in Abu Dhabi sunt obsedati cu moscheile, sunt peste tot. Am una la geam, in fiecare dimineata ma trezesc cu unu care tipa cat il tin bosogii “Allahu Akhbaru”. La munca am o moschee sub geamul de la birou, si tot asa tipa unul de zeul lor.
- Se pare ca ITIL-ul a fost facut fix pentru a crea o super-mega-birocratie. D’aia am ajuns io in Ticketland. “There is a process that needs to be followed”. Din pacate e ilegal sa bati oamenii cu tastatura in dinti. Dar i-as bate pe aia de au inventat monstruozitatea aia.
- Consultantii seniori de la vendori/integratori sunt cam ca juniorii de-i angajam prin Romania la nivel de cunostinte. Unii ceva mai sus, iar unii sunt retardati de-a dreptul.
- O sa ma las de job-ul asta de contractor angajat. Ma prosteste. Trebuie sa ma intorc inapoi la engineering-ul de unde am plecat.
Monthly Archives: February 2014
microsoft, certificatele si rdp-ul
Incepand cu Vista, Microsoft a inventat pentru conexiunile de tip Remote Desktop (RDP) o noua metoda de autentificare numita Network Level Authentication (NLA).
Daca ai servere Windows si un CA de la Microsoft in acelasi domeniu Active Directory, atunci se intampla o chestie misto: toate computerele primesc automat un certificat de la CA-ul din domeniu.
Eh, cand te conectezi folosind RDP de pe o statie din domeniu la un server din domeniu, intra NLA-ul in functiune care face autentificare folosind Kerberos.
Cand te conectezi folosind un computer din afara domeniului sau un alt client de RDP care nu stie de NLA, atunci se face fallback si se foloseste un certificat digital pentru autentificarea serverului.
Cum de curand am trecut la Mac, am importat Root CA certificate in Keychain. Cand m-am conectat la serverele din domeniu a trebuit sa dau accept la toate certificatele prezentate de server (ca MS Remote Desktop de Mac nu stie de NLA). Atunci am dat click-click repede pe accept ca am zis ca nu stiu io sa umblu cu Keychain-ul de la Mac si ca de aia nu se valideaza certificatele.
Acu vreo cateva saptamani m-am apucat sa ma conecteze la niste servere si am fost iar bazait sa dau Trust sau nu la certificate. Si am intrat la banuieli, ca poate s-a futut CA-ul. Numai ca nu stiam de ce, ca nu dadea erori, totul era OK.
Azi m-a dus capul ca inainte sa incerc sa repar CA-ul sa intreb si Internetul ce parere are de asta. Si m-am dumirit. Si am injurat.
Chiar daca serverul are un certificat emis de CA-ul din domeniu, pentru RDP foloseste un certificat self-signed cu validitate de 6 luni la care isi face renewal periodic.
Ca sa faci un server sa foloseasca un certificat semnat de CA pentru RDP, trebuie facut template dedicat in CA, creat un GPO care sa zica la servere sa foloseasca template-ul ala si tot asa.
Microsoft style: de ce sa fie simplu cand poate sa fie complicat.
f5 upgrade
Din categoria ce am mai invatat io azi: cum se face upgrade la un cluster de f5 fara sa te panichezi si sa belesti tot in incercarea de a debuga o problema care nu exista…
- Se downloadeaza ISO de OS nou + ISO de HF-uri dupa caz
- Se uploadeaza ISO-urile in OS sau HF dupa caz
- Se instaleaza OS-ul pe o partitie nefolosita sau cu un OS mai vechi (din cele 3 disponibile)
- Se rebuteaza in noul OS
- Cand OS-ul nou rebuteaza, o sa se strice un pic clusterul in sensul ca n-o sa se mai sincronizeze, insa membrul nou stie ca face parte din cluster si o sa treaca in Standby (Disconnected, Changes Pending etc)
- Asta e partea in care nu e nici nu motiv de panica si nu trebuie debugat nimic.
- Se instaleaza si HF pentru noul OS (daca e cazul) si se da reboot.
- La fel, nici un motiv de panica ca nu se sincronizeaza cei doi membri de cluster
- Se face un failover de pe Active pe Standby
- Se purcede la instalarea OS-ului + HF-ului pe celalalt membru care acum este in Standby
- Dupa ce buteaza si ambele sisteme vor avea acelasi OS, se face o sincronizare manuala intre ele
- Celebrate!