This shows you the differences between two versions of the page.
Both sides previous revision Previous revision | |||
nav-ref:navref_230221 [2021/02/22 11:53] morten |
nav-ref:navref_230221 [2021/02/24 11:23] (current) morten 1. utkast til referat |
||
---|---|---|---|
Line 4: | Line 4: | ||
- | Innkalt: | + | Tilstede: |
- | * Vidar Faltinsen, //Uninett// | ||
* Morten Brekkevold, //Uninett// | * Morten Brekkevold, //Uninett// | ||
* Hanne Moa, //Uninett// | * Hanne Moa, //Uninett// | ||
- | * Kat Hößel, //Uninett// | ||
* Sigurd Refvik, //UiO// | * Sigurd Refvik, //UiO// | ||
* Peder Magne Sefland, //HiVolda// | * Peder Magne Sefland, //HiVolda// | ||
Line 15: | Line 13: | ||
* Ingeborg Hellemo, //UiT// | * Ingeborg Hellemo, //UiT// | ||
* Nils-Arild Grav, //NTNU// | * Nils-Arild Grav, //NTNU// | ||
+ | |||
+ | Forfall: | ||
+ | |||
+ | * Vidar Faltinsen, //Uninett// | ||
+ | * Kat Hößel, //Uninett// | ||
+ | |||
Med gjesteopptreden fra noen(tm) fra CNaaS-teamet @ Uninett. | Med gjesteopptreden fra noen(tm) fra CNaaS-teamet @ Uninett. | ||
Line 79: | Line 83: | ||
===== Referat ===== | ===== Referat ===== | ||
- | Referat kommer. | + | Morten ønsket velkommen til møtet. |
+ | |||
+ | === 1. Presentasjoner/Status === | ||
+ | |||
+ | * 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 [[https://github.com/Uninett/Argus/issues/70|#70]]. | ||
+ | * Varslingssystemet trenger en god del arbeid for å bli minst like bra og deretter bedre enn det vi har i NAV i dag. | ||
+ | |||
+ | === 2. Fokus for videre utvikling/tilbakemelding === | ||
+ | |||
+ | 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 ([[nav-ref:navref_230221:severity-rules|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å: | ||
+ | - 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. | ||
+ | - 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. | ||
+ | |||
+ | |||
+ | === 3. Nye ønsker og innspill fra gruppen === | ||
+ | |||
+ | |||
+ | 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 ([[https://github.com/Uninett/nav/issues/2248|#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 ([[https://github.com/Uninett/nav/issues/2251|#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 [[https://github.com/Uninett/nav/issues/2163|#2163]] og Cisco. | ||
+ | |||
+ | * NTNU: | ||
+ | * Ingenting nytt. | ||
+ | * Største ønske er fremdeles [[https://github.com/Uninett/nav/issues/2164|#2164]] (dot1x-parametre i Portadmin), men denne er foreløpig plassert på 11. plass på arbeidslisten av gruppen. | ||
+ | |||
+ | === 4. Neste møte === | ||
+ | |||
+ | Neste møte ble satt til [[navref_250521|25. mai 2021, kl. 12:30-15:00]], over Zoom. | ||