NAV referansegruppemøte 6. september 2023

NAV-ref Home

Tilstede:

• Peder Smart Sefland, HiVolda
• Rune Kittelsen, UiA
• Ingeborg Hellemo, UiT
• Nils-Arild Grav, NTNU
• Sigurd Refvik, UiO

• Vidar Faltinsen, Sikt (Gikk tidlig for å delta i et annet møte)
• Hanne Moa, Sikt
• Johanna England, Sikt
• Simon Oliver Tveit, Sikt
• Ilona Podliashanyk, Sikt
• Morten Brekkevold, Sikt

Møtet blir avholdt som videokonferanse vha. Zoom, fra kl. 09:00 til 12:00.

• Morten ønsker velkommen på vegne av Sikt.

• Bare èn NAV-release siden forrige møte:
  • Bugfix-release: 5.6.1
• NAV 5.7.0 forventes sluppet i morgen, 7. september:
  • CHANGELOG.md

• Siste sprint før sommeren hadde et visst fokus på PortAdmin, men resulterte ikke i noen release. Mange PortAdmin-oppgaver står i kø, og det krever en del endringer av både måten PortAdmin fungerer i backend og i front-end, så dette tar tid.
  • Ting det jobbes med akkurat nå:
    • PoE-config for Juniper (NETCONF)
    • PoE-config for Cisco (SNMP)
  • Andre oppgaver som ligger i PortAdmin-sfæren:
    • Proxying av config-endringer til eksterne API, som CNaaS-NMS
    • Portprofiler/templates/tags

• I tillegg har arbeidet med refresh-knapp i ipdevpoll blitt tatt opp igjen (#1073 - Refresh button to update single device)

• Ikke minst jobbes det igjen med å betale ned en del teknisk gjeld i kodebasen.
  • Modernisering av pakkingen av NAV. Pakking i Python har tatt noen syvmilssteg videre siden NAV ble et rent Python-prosjekt, og det kreves en del endringer her for at NAV fremdeles skal være byggbart under Python 3.12 og nyere.
  • Se ellers listen over “Developer-centric fixes” i CHANGELOG.md.

• SNMPv3
  • Sikt får jevnlige tilbakemeldinger og spørsmål om ikke det skjer noe med SNMPv3-støtte i NAV, jfr. #1177. Utenfor at flere Sikt-kunder har meldt seg på GitHub, har vi også mottatt tilbakemeldinger fra Statsbygg, som vurderer NAV, men hvor SNMPv3 er et krav.
  • Skal vi opp-prioritere SNMPv3-arbeidet?

• Juniper SRX
  • UiA hadde diverse spørsmål om SRX-plattformen og NAV i 2021, men dette har ikke blitt diskutert noe nærmere. UiA kan sikkert selv redegjøre for hva som er ønskelig, men det som ble nevnt den gangen var at man ønsket statistikk/tall på:
    • Hvor mange klienter er koplet til totalt (I og med at en IP kommer fra et VLAN så vil NAV og ha den oversikten).
    • Hvor mange klienter pr pool (NAV og pr VLAN her og, men det er for vår konfig med et VLAN pr pool).
    • Hvor mange porter/flows/conntrack(?) er i bruk pr pool. Det er vel 65536 tilgjengelig pr 1x IP-adresse. I NAT44 til Svein Ove brukes vel 16 adresser pr /20 nett.
    • Trafikken som genereres. Men den kan for totalen i alle fall hentes fra switch SRX henger mot.
  • Kan godt hende dette er noe CNaaS vil ha en formening om også, da vi leverer SRX til enkelte kunder.

• Validering av SMS-telefonnumre i alarmprofiler
  • Dagens løsning validerer bare at et telefonnummer består av siffer og ingenting annet. Vi burde forbedre valideringen, men hva med internasjonale numre?

• PaloAlto ARP-støtte i ipdevpoll, hilsen UiT
  • UiT har innlevert følgende bidrag: https://github.com/Uninett/nav/pull/2631
  • Hvor raskt får vi den inn i en NAV-release?

• Trege Graphite-spørringer
  • UiT har meldt inn: Ranked statistics caching not working on large installations #2575
  • Kan Sikt bidra med feilsøking av konfigurasjon mm. hos UiT?

• Multi-factor authentication (MFA)
  • Vi mener fremdeles dette kan la seg løse i første omgang ved å konfigurere inn Feide-innlogging i NAV.
  • Dokumentasjon: https://nav.readthedocs.io/en/latest/howto/mod_auth_openidc_feide.html
  • Eksisterende howto-guide sier ikke noe om autorisasjon. Det er ønskelig å begrense *hvilke* brukere som kan logge inn.
    • Dette skal formodentlig være mulig å styre med konfigurasjon av ''mod_auth_openidc'', men vi mangler en proof-of-concept.
      • Vi foreslår at vi forsøker å bygge en proof-of-concept for CNaaS (hvor det er ønskelig med Feide-innlogging på alle involverte VK-er) og dokumenterer denne.

Runde rundt “bordet”. UiT har meldt inn ett innspill i forkant:

UiT har nylig slengt seg på VRF-kjøret. Er det mange andre i sektoren som gjør dette og bør NAV legge noen planer i den retninga?

Vi velger neste møtedato, ca. 6. desember. Mulig fysisk, i Trondheim (men Sikt har en personalsamling i Bergen 7-8. desember)

Morten ønsket velkommen på vegne av Sikt.

Status for utvikling siden sist ble presentert.

• Stort sett bugfikser er kommet som release.
• Det jobbes med PortAdmin.
• Det jobbes igjen med rydding av “teknisk gjeld”, så ikke kodebasen skal bli hengende bak en verden som går videre.

HiVolda har hittil latt være å bruke PortAdmin grunnet manglende kryptering i SNMP v2c. PortAdmins NETCONF-støtte fungerer bare for Juniper, og mye må lages på nytt for en eventuell NETCONF-støtte for Cisco. SNMP v3 kan formodentlig gi HiVolda det de trenger uavhengig av leverandør.

UiA har mye som støtter SNMPv3, men lite som støtter NETCONF.

Ingen store motforestillinger mot opp-prioritering av oppgaven i gruppen.

UiAs ønsker omkring Juniper SRX-plattformen dreier seg i stor grad om å samle inn samme type statistikk som man får fra Uninetts gamle NAT44-løsning.

Det trengs en issue for å gjøre research på hvilke Juniper-MIBs som kan gi slike data, om noen.

Avklart at Joar fremdeles jobber aktivt med dette, så Sikt kan forvente å få svar fortløpende når vi gir tilbakemeldinger.

Utviklerne tilbyr seg å debugge oppsett og svartider hos UiT. UiT får selv ta kontakt ved behov.

Sikt jobber videre med å utvikle dokumentasjon og proof-of-concept på å integrere Feide-autentisering og autorisasjon med NAV via tredjepartsmoduler i Apache, da dette vil være den raskeste veien i mål for å oppnå MFA i NAV. Dette er veldig nyttig også for Sikts egne CNaaS-deployments.

Evt. tettere integrasjon med f.eks. SAML i NAV vil kreve en god del endringer på NAV sentrale mekanismer for innlogging og brukerhåndtering, og er et lengre lerret å bleke.

Ifm. gjennomgang av grensesnittet under diskusjonen, ble det påpekt av NAV grafer load average med enhetsbetegnelsen “prosent”, men load average måles ikke i prosent. Dette bør inn som en bugrapport.

Runde rundt bordet:

• VRF (som nevnt i agenda)
  • NTNU bruker VN (Virtual Network) i SDA (Software-Defined Access)
  • UiA bruker VRF på GSW i Grimstad?
  • Vidar Faltinsen foreslår at UiT presenterer sitt VRF-opplegg på nettsamlingen i oktober.
  • Notatene våre er litt uklare på dette punktet, men vi antar det betyr at vi ikke kom til noen konkrete konklusjoner eller NAV-messige tiltak.
• Device Groups API
  • Melder samme ønske/behov som NTNU har flagget på nav-users om API for å hente/manipulere device groups.
  • Planlegger selv å etablere en asset-database utenfor NAV, og er avhengig av å kunne putte in all informasjon om en boks via API.
• OpenAPI
  • Ingeborg videreformidler spørsmål om hvordan NAV stiller seg til OpenAPI. Svar: NAVs API er allerede dokumentert automatisk vha. OpenAPI (tidl. kjent som Swagger).
    • AKSJON: Melde tilbake til gruppen hvor i NAV man finner denne dokumentasjonen.

Ifm. diskusjonen her ble det stilt spørsmål til resten av gruppen hvordan de håndterer asset management. Brukes det Cisco-produkter?

AKSJON: Sikt bruker kindnavsync til å holde NAV i sync med sin egen “asset-database”, Kind. Koden til denne er åpen. Send lenke til hele gruppen slik at koden kan studeres av de som vil.

• Threshold-alarmer
  • Rune mener å ha opplevd å få threshold-alarmer selv om en boks er på maintenance.
    • AKSJON Rune varsler/oppretter bugrapport med mer detaljer dersom det skjer igjen.

• SNMPv3
  • Interessert i SNMPv3. Har som sagt holdt seg borte fra PortAdmin fordi autentisering skjer i klartekst.
• AV over IP og vilkårlige MIBs i NAV
  • UiA lurer på om HiVolda bruker PTP (sidediskusjon). UiA får mange PTP multicastpakker inn i sitt nett fra hele forskningsnettet.

• Dot1x config i Portadmin er fremdeles høyeste ønske.
• Device Groups API
  • Har meldt et behov for Device Groups API end-point på nav-users, men har ikke kapasitet til å utvikle selv: https://lister.sikt.no/hyperkitty/list/nav-users@lister.sikt.no/thread/6UVTPSRN4DFTNWCD73ULINWG6JRAAZ5Z/
  • AKSJON: Bedt innsender opprette issue i GitHub, men har til gode å se noe.

• Egentlig ganske fornøyd så langt.

Neste møtedato ble satt til 5. desember. Avklaring på om det blir fysisk eller virtuelt kommer senere.