====== NAV referansegruppemøte 24. april 2018 ====== [[nav-ref|NAV-ref Home]] Tilstede: * John-Magne Bredal, UNINETT * Morten Brekkevold, UNINETT * Hanne Moa, UNINETT * Vidar Faltinsen, UNINETT (Special guest star appearance, ca. 12:30-13:00) * Sigurd Refvik, UiO * Peder Magne Sefland, HiVolda * Rune Kittelsen, UiA * Knut-Helge Vindheim, NTNU Forfall: * Ingeborg Hellemo, UiT ===== Agenda ===== Møtet ble avholdt i UNINETTs lokaler i Trondheim, og varte fra kl. 9-15, avbrutt av lunsj. ==== 0. Velkommen/Innledning ==== John-Magne ønsker velkommen. ==== 1. Presentasjoner/Status ==== === Hva har blitt gjort siden sist === * [[https://github.com/UNINETT/nav/releases|NAV releases]] (JM) * Oppgradering av Django og Python (MB og HM) * Topologi (MB) * Auditlog utvidelser (JM) * Event details (JM) === Annet === * Status opphavsrett (JM) * Status NMAAS (MB) ==== 2. Fokus for videre utvikling/tilbakemelding ==== [[nav-ref:nav-ref-arbeidsliste|nav-ref Arbeidsliste]] * Relisensiere * NETCONF * Gjøre ferdig oppgraderinger * Videre support og bugfix * GDPR ==== 3. Nye ønsker og innspill fra gruppen ==== **Runde rundt bordet** //Før vi reiser hver til vårt avtaler vi nytt møte til høsten// ===== Referat ===== ==== Del 1 - Presentasjoner/Status ==== John-Magne ønsket velkommen og begynte med å gå gjennom noen nyheter siden forrige møte (inkludert listen over nye versjoner som er sluppet siden sist). Deretter gikk Morten og Hanne gjennom noe av arbeidet som foregår i kulissene for å holde tritt med nyere versjon av store avhengigheter som Python og Django. Morten gikk gjennom endringer som er gjort, og som må gjøre videre ift. topologi i nettverk med link-aggregation, og spesielt i [[https://github.com/UNINETT/nav/issues/1669|nett med multi-chassis link-agreggation]]. John-Magne presenterte noen av forbedringene i audit-logging, ny event/alert details-side og status for opphavsrettsoverdragelsene vi jobber med. Morten gjennomgikk nok en gang formålet med NMaaS-aktiviteten (GN4-2 JRA2/T5) i Géant, og oppsummerte status for UNINETT-piloten så langt. Rune Kittelsen (UiA) har tidligere stilt seg villig som pilotkunde/forsøkskanin. Tilbakemeldinger gitt underveis: * NTNU er veldig fornøyde med vårt nye varslingsregime for vedlikeholdsvinduet på verktøykassene. * **[[https://github.com/UNINETT/nav/issues/1705|1705]]** Knut-Helge har prøvd å lære seg bruk av NAVs API, men ble forvirret over at API-eksemplene i doc ikke inneholdt ettallet i URL-en, for dette virket ikke. * Her er det en redirect som ikke virker, må sjekkes opp., * En diskusjon om støtte for telemetri. Dette er interessant i NAV-sammenheng, og noe det jobbes med internt i UNINETT, men ingen konkrete planer for NAV foreligger enda (dette vil antageligvis være avhengig av NETCONF-utvidelsene som skal gjøres). * **[[https://github.com/UNINETT/nav/issues/new|ISSUE]]** Knut-Helge har en issue med en HP-stack som NAV bare får PSU og FAN-status fra det ene chassiset på. Knut-Helge følger opp med mer informasjon i etterkant av møtet. * Auditlog: * **[[https://github.com/UNINETT/nav/issues/1706|1706]]** Auditlogge "operate as this user" (og ikke minst, hvordan skal auditlog forholde seg til ting én bruker gjør i en annens navn?) * Kan auditlog ta med både den faktisk og den presumptive brukerens navn i loggen? * **[[https://github.com/UNINETT/nav/issues/1709|1709]]** change-status-to-up: Denne meldingen gir ikke mening. Man enabler eller disabler porten, men man kan ikke bestemme om porten får link eller ikke. * **[[https://github.com/UNINETT/nav/issues/new|ISSUE]]** Logge IP-adressen ved logins? * **[[https://github.com/UNINETT/nav/issues/1716|1716]]** auditlog-tabellen i useradmin-grensesnittet er altfor smal. * **[[https://github.com/UNINETT/nav/issues/new|ISSUE]]** API for å legge til auditlog fra tredjeparts verktøy som benytter seg av NAV? * **[[https://github.com/UNINETT/nav/issues/1501|1501]]** Endringslogg for utstyr (SW-versjonsendringer, etc.). Dette hører egentlig ikke hjemme som auditlog, men som events i devicehistory. Disse eventene eksisterer, og var i brukt under f.eks. getDeviceData, men har ikke vært i bruk siden. De bør gjeninnføres. * **[[https://github.com/UNINETT/nav/issues/new|ISSUE]]** Auditlogge at folk gjør ting med alarmer (ack, clear, delete module, etc) i statusverktøyet. * Port list: * **[[https://github.com/UNINETT/nav/issues/new|ISSUE]]** Orddeling og camelcase: PortList -> Port list * Kanskje også bruke "Interface" i stedet for port. * **[[https://github.com/UNINETT/nav/issues/new|ISSUE]]** Søkefeltet nevner //ifalias//, //ifname// og //ifdescr//, som kan være ukjente begreper for sluttbruker og **har ingen sammenheng** med kolonneoverskriftene som er i bruk lenger ned på siden. * **[[https://github.com/UNINETT/nav/issues/new|ISSUE]]** PoE-kolonner? * **[[https://github.com/UNINETT/nav/pull/1720|PR1720]]** Knut-Helge vil ha en slags "se andre room i samme kartutsnitt"-funksjon når man ser på et kart i room-details. * Forøvrig ser romkartet (på uninav) fullstendig kaotisk og uleselig ut. Kan vi implementered en slags feature clustering her? Se * https://openlayers.org/en/latest/examples/cluster.html * http://dev.openlayers.org/examples/strategy-cluster-extended.html Lunsj ble aviklet fra 11:30-12:30. Etter lunsj kom Vidar Faltinsen for å presentere SUNETs arbeid med en kommende tjeneste: Campus Network as a Service (CNaaS). ==== Del 2 - Fokus for videre utvikling/tilbakemelding ==== Den [[https://nav.uninett.no/wiki/nav-ref:nav-ref-arbeidsliste|stående arbeidslisten]] ble gjennomgått og kommentert. * Kommentarer til arbeidslisten: * [[https://github.com/UNINETT/nav/issues/1242|1242]] POE: Ønsker mer portsentrisk informasjon. * [[https://github.com/UNINETT/nav/issues/1176|1176]] NETCONF: * KHV mener HP ikke støtter NETCONF/RESTCONF men fokuserer på egne REST-APIer. Dersom dette stemmer og det ikke er YANG inne i bildet her, får vi problemer med HP. Hvorfor må leverandørene være så egenrådige? :-P * [[https://github.com/UNINETT/nav/issues/1156|1156]]: Problem med at mange duplikate VLAN dukker opp pga. forskjellige navn i switchene og ruterportbeskrivelsene. * [[https://github.com/UNINETT/nav/issues/1232|1232]]: Egentlig gjennomført, men mangler støtte for HP. HP sitt system ser ut til å kreve "priming" før man kan hente data: Dvs. man må sende en SNMP-forespørsel og bestille data før man etterpå kan lese de av, som er en fremgangsmåte som bryter fullstendig med måten NAVs eksisterende statistikkinnsamling fungerer. Det ble en kort diskusjon om det fins udekte behov hos NAV-brukere for å få oppfylt kravene stilt av **GDPR**, men de som satt rundt bordet hadde ikke noen større grad overveid noen problemstillinger med NAV og GDPR hittil. UNINETT selv skal gjennomføre en GDPR-kartlegging av Nettadministrasjons-tjenesten i inneværende uke. Ting som **ble** diskutert var: * Ved innsynsforespørsel, hva finner man da? "Jeg vil se hvilke data dere har registrert om **meg**" * NAV knytter ikke navn til logger. Man kan f.eks. på MAC-adresse som identifikator, mens IP-adresse kan være flytende over tid. * Brukernavn i radius accounting log? * Trenger vi verktøy for å slette data etter andre kriterier enn tid/datamengde? * Burde vi ha et eget API for å slette slike data? * Per i dag har vi bare ''%%navclean%%'' * Trenger man sletting av Auditlog-data? Er auditlog-data omfattet av GDPR, eller er man unntatt, siden det bare vil dreie seg om bruk i et ansettelsesforhold? ==== Del 3 - Nye ønsker og innspill fra gruppen ==== Runde rundt bordet * **HiVolda**: * har rapportert inn en merkelig sak i forkant. mulig bug eller feiltolkning av data. tar det utenfor møtet. * netconf * **NTNU**: * Bedre API * Eller egentlig: Mulighet til å definere egen statistikkinnsamling til Graphite fra egne MIB-filer. * Ønsker også få visualisert disse dataene i selve NAV, fremfor utenfor NAV. Jfr. at NAV ikke har mulighet til å tegne grafer for relaterte data som ikke NAV selv har samlet inn. * Kan Grafana på VK dekke et behov her? * DOM-data for HP * PoE * API-versjon redirect-sak, nevnt lenger opp * **UiO**: * Sigurd ramset opp en del spesifikke ønsker relatert til APIet, som han videreformidlet fra andre på UiO. Vi foreslår å legge inn disse skriftlige ønskene som issues i i GitHub, da vi jobber kontinuerlig med å forbedre APIet, og det her allerede forelå veldig konkrete eksempler på mangler/ønsker. * Aktive IP-records i Machine Tracker er ikke "aktive nok". UiO vil ha et søk over IP-adresser som virkelig er aktive nå, korrelert mot CAM. * Dette er egentlig noe litt annet enn hva Machine Tracker egentlig er lagt opp til å være nå: Nemlig et søk i historiske logger. * "What if" - det står et visst antall berørte brukere/verter, men de kunne tenkt seg mer detaljer om de berørte brukerne her. Dvs. porter eller MAC-adresser eller noe, slik at de kan varsles direkte. * Usikkert hvordan man kan gjøre en fornuftig oversetting av en liste av porter eller MAC-adresser til en liste over personer, men det er neppe NAVs jobb. * Den opprinnelige meningen i "What If" her var bare å illustrere hvor mange sluttbrukere som kunne bli berørt av et spesifikt utfall, ikke nødvendigvis hvem sluttbrukerne er. Derfor er fokuset heller på å varsle IT-ansvarlige for de berørte organisasjonsenhetene, noe grensesnittet har støtte for (dersom man har lagt inn kontaktdata i NAV). * **[[https://github.com/UNINETT/nav/issues/new|ISSUE]]** Under visning av grensesnittet på UNINETTs egen lokalnav ser //antall berørte// ut til å være på syre. Ser på en av våre store rutere, står det bare "2" brukere her, mens på de underliggende switchene er det langt flere. Er det pga. feil i VLAN-topologiavledningen, mon tro? * **UiA**: * Alle aktuelle tema er allerede tatt opp av de andre i løpet av runden. Neste møtedato ble satt til **23. oktober 2018**.