NAV-ref Home

Tilstede:

• Morten Brekkevold, Uninett
• Hanne Moa, Uninett
• Sigurd Refvik, UiO
• Peder Magne Sefland, HiVolda
• Rune Kittelsen, UiA
• Ingeborg Hellemo, UiT
• Nils-Arild Grav, NTNU

Forfall:

• Vidar Faltinsen, Uninett
• Kat Hößel, Uninett

Med gjesteopptreden fra noen™ fra CNaaS-teamet @ Uninett.

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

• Morten ønsker velkommen på vegne av Uninett.

• NAV 5.1.0 - 5.1.3
  • “NETCONF” på plass i PortAdmin for Juniper
  • “Kloning” av bokser og rom
  • UiOs “skaleringsfunksjon” for ipdevpoll og pping

• Argus har vært i produksjon hos Uninett siden før jul
• Veien videre
• Limetjenester

Et viktig punkt som har opptatt oss siden sist er å definere begrepet “Severity”. Vi har gjort noen designvalg for Argus omkring dette, og er i ferd med å implementere dette der. I tillegg har CNaaS-teamet begynt å drodle rundt hvordan severity-verdier skal tildeles forskjellige hendelser som kommer fra NAV inn i Argus. Ulempen med disse reglene er at de bare påvirker limetjenesten nav-argus-glue.

NAV har hatt en konsept om en “Severity”-verdi i sin datamodell i alle år, men det er aldri foretatt noen ordentlige veivalg for hvordan denne verdien skal brukes eller tolkes i NAV. Dette har på et tidspunkt vært tolket som en verdi mellom 0 og 100, og det er litt uklart om alvorligheten i en hendelse er proporsjonal eller omvendt proporsjonal med tallverdien. Selv om man kan filtrere på dette feltet i alarmprofilen sin, settes alle hendelser i NAV i dag i praksis til verdien “50”. Dette har ingen formidlingsverdi, og hendelser i NAV kunne derfor like gjerne vært modellert uten.

Vi ser diskusjonen om severity-verdier i Argus som en mulighet til å diskutere hvordan dette begrepet kan tas ordentlig i bruk i NAV. Kan vi i stedet vri diskusjonen til å definere/omdefinere “Severity” i NAV, slik at limetjenestens jobb blir enklere og vi kan levere forbedret funksjonalitet også til dem som ikke vil har planer om å ta i bruk Argus?

For litt bakgrunnsinformasjon om “Severity”-feltet i Argus, se https://github.com/Uninett/Argus/issues/70

For oversikt over event/alarmtype-hierarkiet til NAV, se alerttypes

Ingenting er forhåndsinnmeldt (ut over at UiT jevnt og trutt har meldt inn saker på GitHub - det setter vi stor pris på!).

Runde rundt bordet.

Neste møte blir et videomøte. Foreløpig datoforslag: Tirsdag 25. mai

Morten ønsket velkommen til møtet.

• Sentrale nyheter i 5.1-serien ble gjennomgått/repetert.
• Argus ble produksjonssatt hos Uninett før jul.
  • Dokumentasjon: https://argus-server.readthedocs.io/en/latest/
  • Kildekode API-tjener: https://github.com/Uninett/Argus/
  • Kildekode for grensesnitt: https://github.com/Uninett/Argus-frontend/
  • Vi ser etter hvert mange behov for endringer i Argus fremover
    • Et felt for “Severity” er viktigst, for å gjøre USC i stand til å skille hvilke hendelser de skal reagere på fra de som er uviktige #70.
    • Varslingssystemet trenger en god del arbeid for å bli minst like bra og deretter bedre enn det vi har i NAV i dag.

Argus innfører severity-verdier på hendelser, på en tallskala fra 1-5, der 1 betyr kritisk, og 5 er til informasjon.

CNaaS-teamet har foreslått et sett med ønskede severity-verdier på hendelser fra NAV (Et utdrag finner du her). Forslagene dreier seg i stor grad om å sette severity først og fremst basert på event-type i NAV, men deretter moderere verdien avhengig av “viktigheten” av det affekterte utstyret:

• Hvilken kategori er nettboksen? (Switch er middels, distribusjonsswitch har høy alvorlighet, ruter er kritisk)
  • Dette mapper ikke 1:1 til NAVs hovedkategorier, device group må derfor tas i bruk (noe Ingeborg også kommenterte underveis i møtet).
• Hvilken organisasjonsenhet har ansvaret for boksen? (Dersom det er kundens eget ansvar, settes lav alvorlighetsgrad, i.e. Uninett skal ikke reagere på dette)

Vi ser at denne diskusjonen bør løftes ut av Argus og limetjenesten, og heller tas inn i NAV. NAVs Severity-konsept har vært ubrukt i mange, mange år.

Utviklernes foreløpig forslag lyder:

• Ikke alle NAV-brukere vil ønske de samme reglene for setting av “Severity”. Dette må derfor være konfigurerbart i NAV.
• Konfigurasjonsfilen bør komme med et sett “fornuftige defaults”.
• Det bør være to måter å konfigurere regler for “severity” på:
  1. Et lettvekts konfigurasjonsspråk for de enkle tingene (“dersom event er av type X, sett severity=A. Dersom event samtidig gjelder boks av kategori GSW, juster severity til B”).
     • Rekkefølge bør være signifikant i denne konfigurasjonen, for å sikre deterministisk oppførsel.
  2. Dersom man har behov for arbitrær kompleks logikk for å sette severity, bør det alternativt tilbys å plugge inn sin egen Python-funksjon for å sette severity (Avanserte brukere trenger formodentlig noe som er Turing-complete for å bli fornøyde).

Innspill fra den påfølgende diskusjonen tyder på at dette burde være en farbar vei. Utviklerteamet viol utarbeide et mer konkret designforslag som kan forelegges nav-ref til evaluering.

Runde rundt bordet:

• UiA:
  • Har ønsker for mer kompleks funksjonalitet i “Ranked statistics”
    • Noen ganger hadde det vært interessant å se top talkers-rapporten bare innenfor et gitt intervall (for eksempel: “Hva er de mest trafikkerte portene under 1Gbit/s?”)
    • En som er fargeblind får vanskelig for å skille alle linjene i de resulterende grafene fra hverandre.
    • Dette må forstås som frustrasjoner uten konkrete NAV-løsninger i kikkerten.
    • Utviklerne peker på Grafana som et overlegent verktøy her. Her kan man bygge rapporten etter eget ønske i et dedikert grensesnitt, med de filtrene man ønsker. Man kan også jobbe interaktivt med den resulterende grafen og vha. mouseover og andre UI-elementer oppdage hvilke graflinjer som representerer hva, uavhengig av farger.

• UiT:
  • Har postet GitHub-issue om MFA - Multifaktorautentisering (#2248).
    • Økt sikkerhetsfokus på UiT etter datainnbrudd. Man ønsker multifaktor-autentisering på alle systemer der det er praktisk mulig.
    • Foreløpig uklart hvordan MFA kan løses i NAV. Her må evt. feedback gis i GitHub-issuet.
    • Det nevnes at Feide muligens kan brukes med tofakturautentisering i kobling med institusjonens Azure. Det ble i 2020 laget et proof-of-concept med Feide-innlogging i NAV, som vi ønsker å dokumentere og sette i produksjon i CNaaS-sammenheng. Dette kan være en mulig farbar vei for UiT på kortere sikt enn ny funksjonalitet i NAV lar seg utvikle.
  • Også postet GH-issue om at maintenance task-grensesnittet blir ulidelig tregt og lite hensiktsmessig når man har over 3000 bokser i NAV (#2251)
    • Dette er delvis rettet som en bugfiks, men det er fremdeles et problem at JavaScript-widgeten som brukes til å søke opp bokser og andre komponenter i NAV blir veldig treg jo flere elementer den har å søke i. Dette kan bare fikses ved en omskriving, og det er en mye større oppgave.
  • Vil gjerne ha mulighet til å se en IP Device sine historiske maintenance tasks ( ISSUE).
    • Ikke nødvendigvis direkte i ipdevinfo, men på en underside eller noe.
    • Dette gjelder å få en kobling til faktiske maintenance tasks i maintenance-kalenderen - det holder ikke å bruke device history til å bare se at boksen “har vært på maintenance”, for det sier ingenting om “hvorfor”, eller hvilke andre ting som ble satt på maintenance i samme omgang.
  • Har tjenester i sky som må overvåkes av NAV, men deler av disse kjører kun i private adresseområder. Har forsøksvis brukt tunneler for å løse problemet, men det er noen problemer relatert til returtrafikk. Spørsmål: Kunne ipdevpoll/pping/servicemon velge avsenderadresse/avsender-interface når de kommuniserer over IP?
    • * Konklusjon: Man kommer raskere i mål ved å sette opp en egen ipdevpoll-node i en sone som kan snakke direkte med de private adresseområdene.

• UiO:
  • Ingen nye ønsker. Svært fornøyd :)

• HiVolda:
  • Løfter en bekymring for at HiVoldas ønsker blir nedprioritert fordi de er en liten institusjon sammenlignet med de andre.
    • Uninett forsikrer om at dette ikke er tilfellet. Arbeidslisten nav-ref utarbeider setter prioriteringer, og er stemt fram av alle medlemmene i gruppen. Det er likevel ikke til hinder for at Uninett prioriterer bugfikser og quick-wins.
  • Har et problem med at filterskjemaet i Syslogger blir nullstilt dersom man klikker seg ned i detaljene og deretter trykker Back-knappen i nettleseren. Dette er en ren bug, som bør rapporteres og bekreftes ( BUG).
    • Uninett understreker forøvrig at Syslogger er et nedprioritert delsystem i NAV, og at Uninett ser på andre måter å håndtere logging på (f.eks. vha. Humio, som er en tjeneste Uninett har kjøpt og skal bruke selv, men også tilby videre til kunder).
  • Fremdeles meget opptatt av PoE-sakene på arbeidslisten, spesielt for #2163 og Cisco.

• NTNU:
  • Ingenting nytt.
  • Største ønske er fremdeles #2164 (dot1x-parametre i Portadmin), men denne er foreløpig plassert på 11. plass på arbeidslisten av gruppen.

Neste møte ble satt til 25. mai 2021, kl. 12:30-15:00, over Zoom.