NAV-ref Home

Tilstede:

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

• Vidar Faltinsen, Sikt (På en del av møtet)
• Johanna England, Sikt
• Simon Oliver Tveit, Sikt
• Ilona Podliashanyk, Sikt
• Morten Brekkevold, Sikt

Forfall:

• Hanne Moa, Sikt

Møtet blir avholdt fysisk på Sikts møterom Perl i 5. etg. i Teknobyen, Trondheim, fra kl. 09:00 til 15:00. Vi beregner lunsj ca. 11:30-12:15.

• Morten ønsker velkommen på vegne av Sikt.

• Arbeidsmetodikken fortsetter med “sprints” med varighet på to til tre uker hver, med unntak av under avviklingen av sommerferien.
  • Siden møtet i mai har vi gjennomført to NAV-sprints på tre uker hver, men kun én ny release.
  • Nyttige lenker:
    • CHANGELOG
    • Åpne pull requests
    • Arbeidslisten som Kanban-board på GitHub

• Andre prosjekter
  • Argus

• Veivalg: Siste avstemning over innkomne innspill fant sted i mai 2020. Arbeidet med denne har ikke begynt å skyte fart før nå i år, når vi har et team på fem utviklere som begynner å få mer erfaring med kodebasen. Trenger vi en ny avstemning? Legger vi til saker på listen, eller trenger vi en full reprioritering?

Den gamle kjente #1504. Strategien er foreløping innføring av caching-mulighet. Usikkert hvor sterk effekt det vil ha, da problemet i utgangspunktet er ineffektivitet i selve Graphite. Pull request in progress: #2398

Oversiktssak #1997:

• #2393 er ferdig.
• #2391 er underveis.
• #2392 gjenstår.

Vi skal hente frem igjen arbeid som er gjort tidligere ifm.: #1073. Ønsker en kort diskusjon om hvordan funksjonen skal se ut fra brukersiden (f.eks. refresh fra jobblisten i ip device info).

#1938 - diskutert sist av gruppen i 2021. Har vi noe å tilføye? Hvordan skal dette se ut i grensesnittet?

Runde rundt bord. Foreløping ingen skriftlig innmeldte saker. Vi tar evt. opp diskusjonen vi ikke rakk å holde ved forrige møte, vedrørende Peders innspill om strategi for monitorering av tjenester i sky.

Vi velger neste møtedato, ca. 1. mars, halv dag over videokonferanse.

• Morten ønsket velkommen på vegne av Sikt.

Teamet presenterte status og arbeid som var gjort siden sist, med utgangspunkt i changelogs og project boards på GitHub.

Innspill underveis:

• HiVolda: Nevner at nyere switcher fra Cisco har muligheter for å kjøre containere. Kan man utnytte dette i overvåkningssammenheng?
• Hivolda: Uttrykker ellers litt bekymring for at forbedret Cisco-støtte i NAV går på bekostning av internt CNaaS-fokus pa Juniper-utstyr.

På spørsmål om det er på tide med en reprioritering av hele arbeidslisten:

• UiT og HiVolda er /for/ reprioritering
• De andre er litt mer tilbakeholdne.
• NTNU er bekymret for at reprioritering kan føre at deres hjertesak (802.1X-konfigurasjon i Portadmin) havner enda lenger ned enn dagens 11. plass på listen.

Status på pågående arbeid ble presentert, feedback ble etterspurt. Også arbeid som krever mer feedback fra nav-ref før tiltak kan iverksettes ble omtalt.

Utviklerteamet presiserte underveis: Manglende eller dårlig dokumentasjon regnes som en bug, man skal derfor ikke være redd for å rapportere inn dette som issues på GitHub.

Under presentasjonen av alle småoppgavene rundt re-innføring av “device lifecycle events” dukket det opp et spørsmål: Hva skjer når en modul forsvinner og dukker opp i en annen netbox, uten at man har manuelt fjernet den fra den første netboxen? Vil NAV fjerne modulen fra den gamle enheten, eller blir den stående på begge? Teamet skal undersøke hva som faktisk skjer i dag, men trenger kanskje mer feedback fra nav-ref på hva som er ønsket ved et slikt forløp.

Gruppen er enig i at det høres fornuftig ut at brukergrensesnitt for dette knyttes til jobb-utlistingen for enkeltbokser i ipdevinfo. F.eks. at linjen med status for siste inventory-jobb får en knapp (eller lignende) for å iverksette en ny kjøring av inventory.

Spørsmålet er hvordan feedback til brukeren skal gis i grensesnittet. Dersom en jobb feiler, vil status bli rød. Men hva hvis man lurer på hvorfor jobben feilet? I dag må man gå og grave i loggfilene til ipdevpoll. Et godt spørsmål fra nav-ref er om det her hadde vært mulig for NAV å vise hele kjøringsloggen for siste jobb direkte i brukergrensesnittet.

Dette er ikke helt trivielt i dag, siden loggmeldinger kan komme fra hvor som helst i systemet, og det er ikke helt klart hvordan man kan samle opp de meldingene som angår en bestemt kjøring og legge disse et “annet sted” en vanlig logg-output.

Dette er en veldig god idé, men krever litt research for å finne ut hvordan det kan løses og hvor mye arbeid det evt. vil bli.

• Konklusjon: Når man slår på PoE-funksjonalitet i PortAdmin skal det vises en ny PoE-kolonne i portlisten, med dropdown box med valgene off/auto/powerclass for porter som støtter det.
  • PortAdmin ser ok ut i dag på mobilskjerm - vi må være forsiktige / ta hensyn til hva som skjer når man kaster på flere og flere kolonner i et allerede trangt grensesnitt. Kan man få dette til å se bra ut på små skjermer?

Et spørsmål som kom fra gruppen underveis: Kan man få bulk-funksjonalitet i PortAdmin? “Port ranges” hvor man kaster på samme config? Vi forstår dette som at man kan huke av et utvalg av porter fra en liste og be om at alle skal settes til samme VLAN, uten å gjøre den samme dropdown-operasjonen for hver enkelt port. Dette må vi ha en intern designdiskusjon på når vi går gjennom kommende endringer i PortAdmin.

HiVolda meldte inn behov for en diskusjon om overvåkning av skytjenester til forrige nav-refmøtet, men Peder måtte gå tidlig den gangen, så det ble ingen diskusjon. HiVolda fikk derfor gå først i den sedvanlige runden rundt bordet.

• HiVolda:
  • Det ble en lang diskusjon om overvåkning av skytjenester. Det store spørsmalet er egentlig om det er noe nettverksrelatert som skal overvåkes, eller om det er servere og tjenesteinfrastruktur, som egentlig er litt på siden av det NAV driver med. Man kom egentlig ikke til noen konklusjon her, som kan tyde på at dette foreløpig ikke representerer noe som er konkret nok til at det skal jobbes videre med av utviklingsteamet.
  • #2586 Kan NAV generere QR-kodelapper for lenke til rom, utstyr, mac-adresser etc.?
    • Det hadde vært kjekt for teknikere i felt om de kunne skanne QR-kode klistret på utstyr og komme direkte til riktig NAV-side.
    • En ting er å generere kodelapper for individuelle objekter. Hva med å generere 1000 QR-lapper for 1000 netboxene på en gang?
  • #2553 Kan NAV få “Dark Mode”? Peder har postet noe sånt i diskusjonsforumet på GitHub, men det kom ikke klart frem at det var han som var avsender. Vi kan ta det inn som en issue med navref-tag.
  • Spørsmål om alternativer til NfSen på verktøykasser (det er godt kjent at NfSen ikke har vært videreutviklet på mange år). Peder skal mase på CERT om hva de ser for seg å bruke til NetFlow i fremtiden. Vi har snakket om å bytte ut NfSen i mange år, men har avventet hva slags verktøy vår egen sikkerhetsavdeling ville lande på.
  • Har sendt inn en dokumentasjonsreferanse fra PaloAlto, ifm. UiTs ønske om å hente ARP-cache fra PaloAlto-brannmurer (som ikke støtter dette vha. SNMP): https://docs.paloaltonetworks.com/iot/iot-security-api-reference/iot-security-api/get-device-details-per-mac-address

• UiA
  • #2587 Skulle gjerne sett statistikk på forbruk av lagringsplass/diskplass på Juniper.
    • Fins dette i egen MIB, eller kan det tenkes at det rapporteres som minne i de MIB-ene vi allerede støtter?
    • Ettersendt referanse fra UiO: https://supportportal.juniper.net/s/article/How-to-view-the-available-disk-space-on-Junos-devices-by-using-an-OID?language=en_US
  • UiA opplever at description mangler på Juniper-stacker, f.eks. under /ipdevinfo/krs-ad4033-sw-7.uia.no/#!deviceinfo. Det ser ut som det skjer på Juniper-stacker når det blir mange members.
    • Feedback etter møte tyder på at det var en software-bug i JunOS som løste seg ved oppgradering.
  • Ønsker seg FTP-tjener på verktøykassen for lagring av Juniper-konfigurasjon, for Juniper støtter ikke tftp. Dette fins allerede som en tjeneste på VK-er brukt til CNaaS-formål. Kan dette bli tilgjengelig som en standard tjenesten til alle VK-er? (UiA har allerede en supportsak mot Sikt / Nettadministrasjon på dette: #334272)
  • Spørsmål vedrørene UiTs ønske om MFA (multi-factor authentication) og utviklerteamets forslaget om “workaround” med Feide-autentisering (REMOTE_USER-basert):
    • Kan alle Feide-brukere logge inn på NAV om vi slår det på? Er det godt nok dokumentert hvordan man begrenser adgangen til innlogging i NAVs howto guides?
      • Utviklerteamet må følge opp spørsmålet og komme tilbake med svar.
  • UiA mobile duppedingser som flyttes rundt ved behov og av og til havner på hylla. De ønsker ikke fjerne disse fra NAV, men vil heller ikke ha varslinger om at de er unåbare når de er offline. Hva er beste mekanisme for å unngå disse varslene?
  • Godt forslag fra NTNU: Ha en “no-alerts” device group som du unntar i Alert Profiles og Status-
  • Maintenance kan være en aktuelle alternativ mekanisme, men det føles ikke helt riktig å kalle tilstanden for “vedlikehold”.
    • Kan man lage noe som fungerer som maintenance, men hvor status heter “offline” fremfor maintenance?
    • Noen har tidligere uttrykt ønske om en “recurring maintenance”-funksjon, men det ville fungert best der hvor det er faste perioder hvor utstyr er utilgjengelig.

• NTNU:
  • Kan man i fremtiden se for seg at PortAdmin proxyer configendringer via Cisco DNA Centers API, på lik måte som Sikt jobber med for CNaaS-NMS?
    • Det burde være teknisk mulig (gitt et godt dokumentert API), men spørsmålet er om forslaget vil ha bred nok støtte i nav-ref til å bli gjennomført. CNaaS-NMS-koden kan evt. være en god mal for å gjennomføre lignende for Cisco DNA Center.
  • Venter fremdeles mest på 802.1X i PortAdmin, som står et godt stykke nede på arbeidslisten.
  • Jobber fremdeles mot en fremtid (horisont på kanskje 10 år) hvor hele infrastrukturen på NTNU er Cisco-basert og bruker Cisco-verktøy for adminsitrasjon (og dessverre ikke noe NAV).

• UiO:
  • Ingenting spesielt å melde. Kun et spørsmal om https://github.com/Uninett/nav/issues/2161 - som i skrivende stund ligger som nr. 10 på arbeidslisten.

• UiT:
  • Fikk levert mesteparten av sine ønsker sist. Må bare få tagget dem opp som nav-ref-relevante i GitHub så de blir gjenstand for neste avstemning.

UiT minner om muligheten for å ta korte ad-hoc møter innimellom bare for å vise frem ting. Det er ikke alltid nødvendig å vente til neste fulle nav-refmøte for å få feedback.

Neste møtedato ble opprinnelig satt til onsdag 1. mars, klokken 09-12, som videomøte, men ble senere flyttet til tirsdag 7. mars, klokken 12-15