User Tools

Site Tools


nav-ref:navref_230221

Differences

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

Link to this comparison view

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.
  
nav-ref/navref_230221.txt · Last modified: 2021/02/24 11:23 by morten