This shows you the differences between two versions of the page.
Both sides previous revision Previous revision Next revision | Previous revision | ||
nav-ref:navref_070323 [2023/03/03 14:59] morten initiell agenda |
nav-ref:navref_070323 [2023/03/17 12:14] (current) morten sitat-tegn |
||
---|---|---|---|
Line 4: | Line 4: | ||
- | Innkalt: | + | Tilstede: |
* Peder Smart Sefland, //HiVolda// | * Peder Smart Sefland, //HiVolda// | ||
* Rune Kittelsen, //UiA// | * Rune Kittelsen, //UiA// | ||
* Ingeborg Hellemo, //UiT// | * Ingeborg Hellemo, //UiT// | ||
- | * Nils-Arild Grav, //NTNU// | ||
* Sigurd Refvik, //UiO// | * Sigurd Refvik, //UiO// | ||
- | * Vidar Faltinsen, //Sikt// | ||
* Hanne Moa, //Sikt// | * Hanne Moa, //Sikt// | ||
* Johanna England, //Sikt// | * Johanna England, //Sikt// | ||
* Simon Oliver Tveit, //Sikt// | * Simon Oliver Tveit, //Sikt// | ||
- | * Ilona Podliashanyk, //Sikt// | + | * Ilona Podliashanyk, //Sikt// (Gikk tidlig for å delta i et annet møte) |
* Morten Brekkevold, //Sikt// | * Morten Brekkevold, //Sikt// | ||
+ | |||
+ | |||
+ | Forfall: | ||
+ | |||
+ | * Nils-Arild Grav, //NTNU// | ||
+ | * Vidar Faltinsen, //Sikt// | ||
Line 67: | Line 71: | ||
=== 3. Nye ønsker og innspill fra gruppen === | === 3. Nye ønsker og innspill fra gruppen === | ||
- | Runde rundt "bordet". Foreløping ingen skriftlig innmeldte saker. | + | Runde rundt "bordet". Forhåndsinnmeldte ting: |
+ | |||
+ | * HiVolda kan tenkes å ville snakke om "Morpheus": https://youtu.be/9figuE_LJPo | ||
+ | * UiT har følgende innspill: | ||
+ | |||
+ | > Flere i sektoren bruker Mazemap som verktøy for å finne fram til rom. UiT har | ||
+ | > hatt stor nytte av å legge til et eget Mazemap-felt i room-versikten med link | ||
+ | > til rommet i Mazemap. | ||
+ | > | ||
+ | > I tillegg inneholder Mazemap geografiske koordinater til rommet og beskrivelse | ||
+ | > av rommet (undervisningsrom, auditorium etc). Dette er informasjon vi svært | ||
+ | > gjerne skulle hatt hentet inn i NAV i eksisterende felt i stedet for å skrive | ||
+ | > inn manuelt. | ||
+ | > | ||
+ | > Mazemap har et API der alle disse opplysningene kan hentes ut. | ||
+ | > | ||
+ | > Man ønsker ikke å trøkke heile Mazemap-databasen inn i NAV, slik at dette må | ||
+ | > gjøres for de aktuelle rommene man har lagt inn i NAV. Jeg ser også at man må | ||
+ | > tenke ut noe lurt rundt navngiving i NAV kontra Mazemap slik at man greier å | ||
+ | > mappe de mot hverandre. | ||
=== 4. Neste møte === | === 4. Neste møte === | ||
Line 75: | Line 99: | ||
===== Referat ===== | ===== Referat ===== | ||
- | Kommer. | + | === 0. Velkommen/Innledning === |
+ | |||
+ | * Morten ønsket velkommen på vegne av Sikt. | ||
+ | |||
+ | === 1. Presentasjoner/Status === | ||
+ | |||
+ | Utviklerteamets arbeidsmetodikker ble kort presentert, deretter ble NAVs | ||
+ | changelog siden sist gjennomgått. | ||
+ | |||
+ | == JWT-tokens == | ||
+ | |||
+ | Gjennomgang av Cybersikkerhetssenterets behov for å finne informasjon om et | ||
+ | kundesubnetts //formål//. Ved hjelp av KUDAF-midler har man jobbet frem et API | ||
+ | som gjør CSC i stand til å slå opp informasjon om IP-adressetildelinger i | ||
+ | forskningsnettets IP-register. Dette IP-registeret sier derimot ikke så mye om | ||
+ | kundens faktiske formål med subnettet, bare at kunden er tildelt et | ||
+ | adresseområde. | ||
+ | |||
+ | //"The last mile"// her er å gjøre CSC i stand til å slå opp i kundenes egne | ||
+ | subnett-data i NAV, gitt en IP-adresse. Dette kan gi mer informasjon om hva | ||
+ | slags formål et subnett faktisk har hos kunden (ansattnett, studentnett, | ||
+ | servernett osv.). For å gjøre noe sånt, krever det muligheten til å delegere | ||
+ | ansvaret for API-autorisasjon til en tredjepart, f.eks. Feide. Dette er noe | ||
+ | som kan løses ved å bruke JWT-tokens i NAV i stedet for dagens løsning med | ||
+ | genererte, ugjennomsiktige tokens. Et JWT-token er et kryptografisk signert | ||
+ | krav om aksess, og med den nye løsningen kan NAV konfigureres til å stole på | ||
+ | JWT-tokens signert av Feide. NAVs interne tokenløsning vil også etter hvert | ||
+ | byttes ut med en JWT-basert løsning (slik at NAV vil utstede og signere sine | ||
+ | egne JWT-tokens fra Useradmin-panelet). | ||
+ | |||
+ | == Aktivitetsnivå == | ||
+ | Sikt får finansiert færre timer for Argus-utvikling fra GÉANT i år, noe som | ||
+ | nødvendigvis vil medføre mindre aktivitet her. NAV og CNaaS-NMS har tilnærmet | ||
+ | lik aktivitet som før, men i tillegg har Sikt nå fått i oppdrag fra NORDUnet å | ||
+ | omskrive Zino til Python. | ||
+ | |||
+ | == Zino 2.0 == | ||
+ | Uninett utviklet Zino til overvåkning av forskningsnettet på midten av | ||
+ | 90-tallet, og har brukt det i produksjon siden. Zino er et rimelig småskala, | ||
+ | robust system med få avhengigheter, som har tjent både Uninett, NORDUnet og | ||
+ | SUNET godt i mange år. | ||
+ | |||
+ | En ulempe ved Zino er at det er implementert i //Tcl//, et språk som nesten | ||
+ | ingen bruker lenger, og har hovedsakelig bare én utvikler (som har få år igjen | ||
+ | i yrkeslivet). Sikt har derfor lagt frem et prosjektforslag for NORDUnet for å | ||
+ | skrive om Zino til Python, i tillegg til å lage et web-basert grensesnitt som | ||
+ | et tillegg til eksisterende X11 og terminal-baserte grensesnitt. Dette | ||
+ | prosjektforslaget er godkjent av NORDUnet, som finansierer opp mot et årsverk | ||
+ | for denne oppgaven i 2023. Oppgaven har tilfalt utviklerteamet i PO | ||
+ | Campusnett, da dette teamet både har bred faglig kompetanse på både Python og | ||
+ | nettverksovervåkning. | ||
+ | |||
+ | |||
+ | === 2. Fokus for videre utvikling/tilbakemelding === | ||
+ | |||
+ | == Device lifecycle management == | ||
+ | |||
+ | Det som gjenstår her er hovedsakelig å poste events når utstyr forsvinner ut av drift. I tillegg jobbes det med et problem som UiT har rapportert, hvor varsler om sw/hw/fw-oppgraderinger kommer med feilmeldingen "No alert template defined" i stedet for en pent formatert alarm (dette har man funnet et løsning på i etterkant, i [[https://github.com/Uninett/nav/pull/2594|#2594]]). | ||
+ | |||
+ | == DHCP-statistikk i NAV == | ||
+ | |||
+ | Det er et ønske fra CNaaS-teamet om at NAV skal kunne presentere statistikk over DHCP-leases i subnett, selv om dette statistikken nødvendigvis må sendes til NAVs Graphite-server fra et eksternt system. Ettersom CNaaS bruker ISC DHCP, er det utviklet et contrib-script i NAV som kan lese tilstandsdata om dhcp-pools fra ISC DHCP og sende disse tallene som metrikker til en Graphite-tjener (scriptet må kjøre på selve DHCP-tjeneren). | ||
+ | |||
+ | Scriptet er utviklet basert på innmeldte behov for CNaaS, men dette representerer bare ett brukseksempel. UiT har forsøkt å ta i bruk det samme scriptet på sin ISC DHCP-tjener, men fordi UiT bruker en annen konvensjon enn CNaaS for navngiving av sine DHCP-pools har forsøket foreløpig strandet. | ||
+ | |||
+ | For at NAV skal være i stand til å relatere en ekstern metrikk i Graphite til et VLAN eller Prefix i NAVs database, må metrikkene ha navn/stier som gjør dette mulig (ettersom det er svært begrensede muligheter for å legge til andre metadata til metrikker i Graphite). Derfor må det defineres en navnestandard som kan tjene flere parter, og som muliggjør integrering av også andre DHCP-tjenere enn ISC. | ||
+ | |||
+ | Tanken var å ha en slik diskusjon på dette møtet, men ettersom ingen representanter for CNaaS-teamet hadde anledning til å delta, ble det valgt å utsette diskusjonen til et eget møte, der Vidar Stokke (Sikt/CNaaS) og Ingeborg Hellemo (UiT), samt representanter for utviklerteamet, deltar. | ||
+ | |||
+ | |||
+ | == PaloAlto og ARP-innsamling i NAV == | ||
+ | |||
+ | UiT har engasjert en student (Joar Heimonen) til å arbeide frem et kodebidrag til NAV som vil gjøre NAV i stand til å hente ARP-informasjon fra PaloAlto-brannmurer. Denne informasjonen har aldri vært mulig å få ut med SNMP, men PaloAlto tilbyr ARP-data gjennom et lettfattelig REST-API. Joar har utarbeidet en proof-of-concept til NAV, men basert på NAVs service-monitor. UiT og Sikt har møttes for å veilede Joar i hvordan han kan innlemme sin implementasjon i ipdevpoll-motoren i NAV i stedet, der den hører mer naturlig hjemme, og hvor koden også kan støtte seg på eksisterende funksjonalitet for håndtering av ARP-logger i NAV-databasen. | ||
+ | |||
+ | Sikt har foreløpig ikke hørt mer fra Joar etter dette møtet (24.02.2023). | ||
+ | |||
+ | Peder spilte inn to PaloAlto-lenker i chatten underveis: | ||
+ | * https://github.com/netdisco/snmp-info/issues/256 (om å gjøre noe tilsvarende med SSH i netdisco, men konklusjonen i møtet er at REST-API er mye enklere å implementere, så UiT har valgt riktig vei) | ||
+ | * [[https://docs.paloaltonetworks.com/pan-os/10-1/pan-os-admin/monitoring/snmp-monitoring-and-traps/supported-mibs|PaloAlto MIB-dokumentasjon]] | ||
+ | |||
+ | == Ranked statistics is slow == | ||
+ | |||
+ | Dette står fremdeles som punkt nr. 2 på arbeidslisten, men vi velger å lukke dette punktet med caching-implementasjonen som kom i siste NAV-versjon ([[https://github.com/Uninett/nav/pull/2398|#2398]]). | ||
+ | |||
+ | Cachingen hjelper dessverre ikke mot det underliggende problemet, som er at Graphite i seg selv er veldig treg til å svare på en forespørsel om rangering av store mengder data. Det største problemet i dag er kanskje at deler av infrastrukturen timer ut mens man venter på svar fra Graphite, dersom man har veldig store datamengder å prosessere. Selv den nye funksjonaliteten som cacher resultatet vil feile pga. timeouts. Man kan kanskje bøte noe på akkurat dette problemet ved å øke noen timeoutverdier, men det underliggende problemet med at Graphite er tregt er vanskeligere å gjøre noe fornuftig med. | ||
+ | |||
+ | Møtet er enige om at dette ikke lenger har veldig høy prioritet, og kan lukkes fra listen. UiT åpner et nytt issue om timeout-problematikken ([[https://github.com/Uninett/nav/issues/2575|#2575]]). | ||
+ | |||
+ | |||
+ | === 3. Nye ønsker og innspill fra gruppen === | ||
+ | |||
+ | == HiVolda == | ||
+ | |||
+ | Peder ønsket å trekke frem frem "Morpheus"-konseptet ([[https://youtu.be/9figuE_LJPo]]), en slags GPU-powered AI fra NVIDIA som analyserer nettverkstrafikk i realtime og detekterer trusler. Spørsmålet fra Peder er om ikke noe sånt kunne vært foret med data fra NAV, men det kom ingen konkrete forslag ut av dette. | ||
+ | |||
+ | == UiT == | ||
+ | |||
+ | UiT har i likhet med mange andre UH-institusjoner valgt å benytte Mazemap som løsning for å la ansatte, studenter og publikum navigere sine campus. Man kan for eksempel få navigeringshjelp til ethvert telematikkrom på Campus. UiT kunne tenkt seg en løsning hvor alle telematikkrom i NAV kan kobles til Mazemap for å fysisk kunne navigere til dem i den virkelige verden. | ||
+ | |||
+ | Ingeborg deler lenke i chat: | ||
+ | > Eksempel på standardisert link inn mot Mazemap. Legg merke til campusid og sharepoi som identifiserer campus og rom. https://use.mazemap.com/?campusid=39&sharepoitype=identifier&sharepoi=1043 | ||
+ | |||
+ | Peder deler lenker i chat: | ||
+ | > https://www.mazemap.com/solutions/system-integrations | ||
+ | > https://www.mazemap.com/solutions/heat-maps | ||
+ | |||
+ | //Utviklerteamets kommentar//: Dette høres ut som noe som best løses med et tillegsverktøy til NAV. Et slikt verktøy må kommunisere både med NAVs API og med Mazemaps API, og være i stand til å oversette roomid i NAV til rom-id i Mazemap (disse kan fort ha forskjellig standard). Verktøyet kan gå over alle rom i en NAV-installasjon, finne rommets tilsvarende innslag i Mazemap, og annotere NAV-rommet (med data-attributter) med en URL til rommets Mazemap-innslag. | ||
+ | |||
+ | :!: Det er uklart hvordan og hvem som kan jobbe med en slik oppgave ut i fra forutsetningene, men det kan gjerne forfattes et issue med navref-label på det i NAVs tracker. | ||
+ | |||
+ | == Dokumentasjon av optisk kabelføring == | ||
+ | |||
+ | Innspillet om Mazemap avstedkom en diskusjon om dokumentasjon av fiberføringer på kart i NAV. På generell basis er ikke dette noe NAV vil befatte seg med. NAV kan brukes til å dokumentere fysisk ethernet-kabling og patching innenfor bygningsmassen, mens de fleste som ønsker å dokumentere fiberføringer bruker verktøy som Telemator for oppnå dette. | ||
+ | |||
+ | Sigurd nevner at han har litt lyst til å lage et NAV-tillegg som gjør det mulig å koble fiberføringsinformasjon i andre systemer til NAV. | ||
+ | |||
+ | Morten påpeker at både UiT og Sikt har gjort hver sin integrasjon mellom Telemator og NAV, som kanskje kunne vært delt. UiTs løsning baserer seg på å dumpe Telemator-databaser inn i NAV-databasen. Sikts løsning baserer seg på å gjøre oppslag direkte mot Telemators MS-SQL-database fra et NAV-tillegg, slik at fiberføringsinformasjon kan søkes opp via sambandsnumre, direkte fra søkeboksen i NAVbar. | ||
+ | |||
+ | Rune melder sin interesse for fiberdokumentasjon, og nevner at UiA i dag har noe "håndtegnet" dokumentasjon i Visio som ser ut som en KLM-sketsj. UiO har også papirtegninger av fiberføringer. | ||
+ | |||
+ | == Løst og fast == | ||
+ | |||
+ | Noen delte en lenke til [[https://internet2.edu/2023-internet2-technology-exchange/|2023 Internet 2 Technology Exchange]], men det fremgår ikke av møtenotatene hva hensikten var. | ||
+ | |||
+ | === 4. Neste møte === | ||
+ | |||
+ | Møtet ble foreløpig enige om 6. juni, kl. 12-15 som neste møtedato (digitalt). Det må gjøres avsjekk med Nils-Arild/NTNU om dette passer. Dessuten viser det seg i etterkant at dette kanskje kræsjer med datoer TNC 2023, så det er mulig vi likevel må sende ut en Doodle for å enes om ny dato. | ||