Stork 2.6 unifikon gjurmimin e DHCP lease dhe transferimeve DNS

Stork 2.6 zgjeron mjetin open-source të menaxhimit me gjurmim të konsoliduar të Dynamic Host Configuration Protocol (DHCP) lease dhe monitorim të Domain Name System (DNS) zone transfer. DHCP u cakton automatikisht pajisjeve adresa rrjeti, ndërsa DNS i drejton emrat e internetit te sistemet që i shërbejnë ato. ISC e përshkruan versionin 2.6 si një release të qëndrueshëm, të përshtatshëm për përdorim në production, megjithëse identifikon gjithashtu dy probleme të njohura që administratorët duhet t’i shqyrtojnë përpara deployment.

Release ka katër shtesa kryesore: gjurmimin e lease në disa serverë Kea DHCP, authentication përmes OpenID Connect, monitorimin e BIND 9 DNS zone transfer dhe mbështetjen për Kea Configuration Backend. ISC ka zëvendësuar gjithashtu një dependency kryesore të user interface dhe ka paraqitur disa ndryshime që lidhen me sigurinë.

Gjurmimi i konsoliduar i lease synon t’u japë administratorëve një pamje të vetme të caktimeve të adresave në një deployment Kea që mund të jetë i madh. Një lease është caktimi i përkohshëm i një IP address për një pajisje. Kur kjo veçori aktivizohet, agjentët Stork mbledhin informacionin e lease nga skedarët e lease të instancave Kea të zbuluara dhe ia dërgojnë serverit qendror. Më pas, Stork krijon një database ku mund të bëhen kërkime dhe që përfshin lease nga të gjithë serverët e monitoruar. Implementimi aktual funksionon vetëm me memfile backend të Kea, i cili i ruan të dhënat e lease në skedarë.

Administratorët mund t’i renditin, filtrojnë dhe kërkojnë lease e mbledhura, duke përfshirë DHCPv6 lease që përdoren me versionin më të ri të Internet Protocol, si dhe të hapin një record individual për më shumë hollësi. ISC thotë se projekti më i gjerë synon t’i ndihmojë operatorët të shohin se cilët client mbajnë lease, të hetojnë problemet e allocation, të gjejnë lease që i përkasin një client të caktuar, të shqyrtojnë historikun e lease të një client, të identifikojnë pajisjet që marrin një lease për herë të parë dhe të përshpejtojnë rinovimin ose heqjen e parakohshme në rrethana të caktuara. Jo të gjitha këto synime përshkruhen si veçori të përfunduara në këtë release. ISC po kërkon use case të tjera për të orientuar diagnostikimet e ardhshme, veçanërisht për rrjete me shumë subnet dhe numër të madh lease.

Ndryshimi i dytë kryesor është OpenID Connect (OIDC), një standard që i lejon një shërbimi të mbështetet te një identity provider i jashtëm për të konfirmuar identitetin e një përdoruesi. Më parë, Stork mbështeste credentials të ruajtura në database e vet dhe LDAP, një sistem që përdoret zakonisht për mirëmbajtjen e llogarive të përdoruesve të një organizate. Kur OIDC është konfiguruar, serveri Stork vepron si relying party dhe ia kalon authentication një provider të jashtëm. Kjo mund ta lidhë aplikacionin me Single Sign-On (SSO), ku një llogari e vetme organizative përdoret në disa shërbime, dhe i lejon provider të jashtëm të kërkojë multi-factor authentication.

Për operatorët DNS, Stork 2.6 paraqet monitorim të centralizuar të BIND 9 zone transfer. Një zone transfer kopjon record autoritative DNS, domethënë record që japin përgjigjet zyrtare për një domain, ndërmjet serverëve DNS. Diagnostikimi i një transferimi të bllokuar ose të ngecur tradicionalisht u ka kërkuar operatorëve të shqyrtojnë log të BIND dhe të mbledhin informacion nga disa vende.

Agjentët Stork tani mund të marrin record për transferimet e nisura, të përfunduara dhe të dështuara nga disa instanca BIND 9. Serveri i ndërlidh këto event dhe paraqet një listë të vetme për mjedisin e monitoruar. Çdo record ka një timestamp me saktësi në milisekonda dhe mund të tregojë kohën e fillimit, kohëzgjatjen, serverin dërgues dhe serverin marrës. Për transferimet e dështuara, Stork mund të shfaqë hollësi shtesë të marra nga mesazhet përkatëse të log. Kjo u jep operatorëve një mënyrë të drejtpërdrejtë për të dalluar synchronization të suksesshëm nga transferimet që nuk përfunduan.

Release gjithashtu e bën Stork të pajtueshëm me Kea Configuration Backend, i cili ruan pothuajse të gjithë configuration të Kea në një ose më shumë database. Përparësitë e tij të mundshme përfshijnë ripërdorimin e seksioneve identike të configuration në disa serverë, mirëmbajtjen e një source of truth të vetëm, zbatimin e ndryshimeve përmes një API me kontrolle logjike në kohë reale, integrimin e mjeteve third-party ose të automation të brendshëm dhe përdorimin e vetive të database për concurrency, consistency dhe ndryshime atomike. Database mund të mbështesë gjithashtu reporting dhe replication për fault tolerance në kohë reale.

ISC vëren gjithashtu kompromiset. Përdorimi i backend mund të kërkojë përgatitje të konsiderueshme për integration ose automation, skenarët e mbështetur kërkojnë që pjesa më e madhe e punës së configuration të kryhet përmes API dhe kjo API është e disponueshme vetëm për klientët e ISC që kanë një kontratë mbështetjeje me pagesë. Versionet e mëparshme nuk mund ta përdornin Stork për të menaxhuar configuration të ruajtur në këtë backend.

Stork 2.6 mund të krijojë, ndryshojë dhe fshijë subnet të ruajtura në backend kur janë ngarkuar hook libraries `cb_cmds` dhe `subnet_cmds`. Një subnet është një pjesë e përcaktuar e një rrjeti IP, ndërsa një hook library e zgjeron Kea me command ose behavior shtesë. Daemon që përdorin të njëjtën backend database dhe server tag grupohen në formularin e subnet, në mënyrë që administratori të mos mund t’i konfigurojë individualisht në mënyra jokonsistente. Administratorët mund të zgjedhin server tag që lidhen me një subnet, gjë që përcakton se cilët serverë e marrin atë. Teksti ndihmës dallon operation që ndryshojnë skedarin JSON configuration nga ato që ndryshojnë backend database.

ISC ka zëvendësuar PrimeNG, library e interface component që përdorej më parë për tabela, pagination, butona dhe control të tjera. PrimeTek njoftoi në fund të qershorit se do të ndalonte punën për library open-source PrimeNG dhe do të kalonte në një model komercial. ISC shqyrtoi mundësinë e mirëmbajtjes vetë të disa component të përzgjedhura, kalimin në Angular Material dhe rindërtimin e interface me HTMX. Në fund, ajo miratoi Optimus-UI, një community fork open-source që mirëmbahet përmes OpenNG, dhe thotë se po planifikon në buxhet një kontribut financiar vjetor për atë organizatë.

Për mirëmbajtjen e sigurisë, ekipi i Stork po eksperimenton me update javore të dependency si përgjigje ndaj vëllimit të vulnerability të raportuara në të gjithë software ecosystem e tij. ISC thotë se versioni 2.6.0 përmban gjithashtu përmirësime dhe rregullime të tjera të sigurisë, të dokumentuara në release notes. Meqë mbeten dy probleme të njohura, administratorët duhet të lexojnë si release notes, ashtu edhe Stork Known Issues List, ta testojnë upgrade me configuration e tyre dhe të ruajnë një mundësi recovery përpara se ta përdorin në production.

Source code është i disponueshëm përmes zonës së shkarkimeve të ISC. ISC shpërndan gjithashtu package për sistemet Debian, Alpine dhe ato të bazuara në RPM përmes repository Cloudsmith, ndërsa për udhëzime mbi deployment ofrohen Quickstart Guide dhe Administrator Reference Manual. Mbështetja profesionale për Stork ofrohet si pjesë e një kontrate mbështetjeje për Kea DHCP. ISC liston Bronze me mbështetje përmes email gjatë orarit të punës, Silver me mbështetje pa ndërprerje përmes email dhe telefonit sipas service-level agreement, dhe Gold me kohë më të shpejtë përgjigjeje. Silver dhe Gold përfshijnë Role-Based Access Control hook, ndërsa kostoja e subscription bazohet në madhësinë e deployment, të matur sipas lease të njëkohshme.

Për organizatat që kanë nevojë për ndihmë të jashtme në operimin e sistemeve të tilla, AEU-I ofron IT, infrastructure dhe consulting me sigurinë në plan të parë.