NAV-ref Home

Innkalt:

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

• Vidar Faltinsen, Sikt
• 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”. Foreløpig ingen forhåndsinnmeldte saker.

Vi velger neste møtedato, ca. 6. desember. Mulig fysisk, i Trondheim.

Kommer.