Differences

This shows you the differences between two versions of the page.

--- nav-ref:navref_070323 [2023/03/17 09:39] – forfall/tilstede morten
+++ nav-ref:navref_070323 [2023/03/17 12:14] (current) – sitat-tegn morten
@@ Line 76: / Line 76: @@
   * UiT har følgende innspill:
-    Flere i sektoren bruker Mazemap som verktøy for å finne fram til rom. UiT har
+> 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
+> hatt stor nytte av å legge til et eget Mazemap-felt i room-versikten med link
-    til rommet i Mazemap.
+> til rommet i Mazemap.
+>
-    I tillegg inneholder Mazemap geografiske koordinater til rommet og beskrivelse
+> I tillegg inneholder Mazemap geografiske koordinater til rommet og beskrivelse
-    av rommet (undervisningsrom, auditorium etc). Dette er informasjon vi svært
+> 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
+> gjerne skulle hatt hentet inn i NAV i eksisterende felt i stedet for å skrive
-    inn manuelt.
+> inn manuelt.
+>
-    Mazemap har et API der alle disse opplysningene kan hentes ut.
+> 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å
+> 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å
+> 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 å
+> tenke ut noe lurt rundt navngiving i NAV kontra Mazemap slik at man greier å
-    mappe de mot hverandre.
+> mappe de mot hverandre.
 === 4. Neste møte ===
@@ Line 99: / Line 99: @@
 ===== 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
+-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.