Differences

This shows you the differences between two versions of the page.

--- nav-ref:navref_230221 [2021/02/16 14:04] – riktig årstall hjelper morten
+++ nav-ref:navref_230221 [2021/02/24 11:23] (current) – 1. utkast til referat morten
@@ Line 4: / Line 4: @@
-Innkalt:
+Tilstede:
-  * Vidar Faltinsen, //Uninett//
   * Morten Brekkevold, //Uninett//
   * Hanne Moa, //Uninett//
-  * Kat Hößel, //Uninett//
   * Sigurd Refvik, //UiO//
   * Peder Magne Sefland, //HiVolda//
@@ Line 15: / Line 13: @@
   * Ingeborg Hellemo, //UiT//
   * Nils-Arild Grav, //NTNU//
+Forfall:
+  * Vidar Faltinsen, //Uninett//
+  * Kat Hößel, //Uninett//
 Med gjesteopptreden fra noen(tm) fra CNaaS-teamet @ Uninett.
@@ Line 63: / Line 67: @@
 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 [[nav-ref:navref_230221:alerttypes]]
 === 3. Nye ønsker og innspill fra gruppen ===
@@ Line 77: / Line 83: @@
 ===== 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.