====== NAV referansegruppemøte 12. november 2015 ======
[[nav-ref|NAV-ref Home]]

Tilstede:
  * John-Magne Bredal, UNINETT 
  * Morten Brekkevold, UNINETT
  * Rune Kittelsen, UiA
  * Jan Sigurd Refvik, UiO
  * Peder Sefland, HiVolda
  * Gro-Anita Vindheim, NTNU

Gjesteopptreden:

  * Rune Sydskjør, UNINETT
  * Jarle Bjørgeengen, UiO
  
Forfall:
  * Børge Brunes, UiT
  * Vidar Faltinsen, UNINETT

===== Agenda =====

Møtet ble avholdt på Universitetet i Oslo, og varte fra kl. 9-15, avbrutt av lunsj.

  - Status og demo
  - Sensorbasert sikkerhetsvarsling (Suricata)
  - Videre utvikling

===== Referat =====

  * Merk: Punkter merket :!: følges opp og vurderes som Launchpad-issue. Da skrives bugnr. Når dette er fikset og sluppet skrives FIX RELEASED.

==== Status og demo ====

=== Innledning ===

Morten innledet møtet.

Ikke all verdens til nyutvikling på NAV siden forrige møte. Mange timer brukt
på Puppet-migrering av VK-plattformen, den seneste migrert i går. Mange
erfaringer vunnet ift. NAV-deployment.

Vi opplever mange nye brukere utenfor Norge (blant annet fra Sverige, Litauen
og Kanariøyene). Dette merkes på mer tid brukt til support. Vi prioriterer å
hjelpe nye brukere i gang - flere brukere er bra for NAV.

UNINETT har fått et betalt oppdrag fra Universitet i Basel for å utvikle
støtte for Cisco Voice VLAN i PortAdmin. Dette var ikke mer enn et dagsverk,
og var en grei øvelse hvordan vi kan organisere sponset utvikling.

Også mottatt en pull request (kodebidrag) fra Universitetet i Linköping. Helt
spesifikt en forbedret måte å autentisere mot Microsoft AD ved
LDAP-innlogging. Koden trenger små justeringer før vi kan ta den inn.

=== Demo ===

John-Magne demonstrerte ny funksjonalitet i NAVs webgrensesnitt:

    * Interaktive grafer (basert på Rickshaw) til erstatning for statiske bilder fra Graphite.
        * Spørsmål fra Jarle om vi har tatt inspirasjon fra Grafana.
            * Det har vi ikke. Påfølgende diskusjon om Grafana - vi bruker det på UNINETT, så vi har mulighet til å se på det allerede.
      * Spørsmål fra John-Magne til gruppen hva de ellers ønsker seg av NAVs grafer
          * Peder foreslår "trendgrafig", vha. "Tidsforskyvning". F.eks. sammenligne forrige ukes trafikk med denne ukes trafikk på samme graf.
          * Grafing av avvik/anomalier?
              * Kan være vanskelig å gjøre dette autmatisk eller pålitelig.
              * Varsling av de samme avvikene?
          * Grafing av maxima (aggregering av maksverdier i tillegg til snittverdier)

    * Sparklines på "job info" i IP Device Info.
        * John-Magne etterlyser flere steder i grensesnittet Sparklines kunne vært nyttig i.
            * I rapportsystemet?

    * "Business reports".
        * Vi ser for oss at dette er et nytt sted å legge mer avanserte rapporter på - rapporter som ikke nødvendigvis er begrenset til SQL-data i tabellformat.
        * Gro-Anita etterspør rapporter som viser trender i antallet bokser av forskjellige typer (Graphite-statistikk pr. typeinnslag i NAV, dette har NTNU tatt opp før)
        * Forslag fra Jarle om bubble charts for å fremstille hendelser.
        * Spørsmål fra utviklerne om man vise availability basert på NAV-alarmer eller på pakketapsstatistikk?
            * Konsensus ser ut til å være at vi bør ta vekk det som er basert på pakketap. Disse rapportene er for det meste rettet mot ikke-teknikere, og for mange detaljer er bare egnet til å forvirre.
	    
    * Temperatur-gauges fra "Environment sensors"-fanen kan nå legges til som widget på forsiden.
        * Diskusjon om vi ikke kan legge til muligheten for å vise alle temperaturer med gauge-widgeten (og til og med legge til på dashboardet).
    
Fem minutters benstrekk ca. kl. 10:15.

==== Sensorbasert sikkerhetsvarsling (SBSV) ====

Rune Sydskjør presenterte den nye tjenesten Sensorbasert Sikkerhetsvarsling, basert på programvaren Suricata på målepålene. (CERT-leder på UiO tok en tur innom møtet for å overvære denne delen).

Deretter fulgte litt diskusjon rundt videre utvikling og integrasjon med andre
verktøy i VK/MP-porteføljen:

    * Hvordan finner man den egentlige klient bak et varsel fra SBSV når den involverte adressen hører til en nat44-boks? NetFlow? NAV?
    * Spørsmål om koblinger mellom NAV/VK, SBSV, MP og IP-register. Kobling til prefix/VLAN i NAV? Maskinsporing?
    * Peder ønsker seg mer integrasjon mellom nat44 og NAVs maskinsporing.
        * Kan være at vi klarer å lage et verktøy som gjør automagisk oppslag i NAV og NetFlow basert på et sikkerhetsvarsel med IP, port og klokkeslett? Stort potensiale for innsalg her.

Rune Sydskjør sa litt om den siste nyutviklingen i Firewall Builder.

    * Et viktig arbeid her er å støtte flercampusløsninger.
    * Akkurat nå står utviklingen litt stille, vi er avhengige av tilbakemeldinger fra brukerne om evt. nye behov.
    * fwbuilder blir tungt brukt hos UNINETT.

Møtet ble avbrutt av lunsj ca. 11:30-12:30.

==== Veien videre ====

Møtet gikk gjennom innkomne innspill fra referansegruppen og annet som dukket opp på møtet.

NTNU har spilt inn et ønske om NAV som verktøy for IP Address Management (IPAM):

    * NTNU begynner å få mange scopes nå som de fusjonerer med tre andre institusjoner. Det er også overlapp på RFC 1918-adresser. De ønsker en bedre sortering og/eller organisering av scope-prefikser når det blir mange av dem.
    * BUG :!: [[https://bugs.launchpad.net/nav/+bug/1518251|LP#1518251]] [[https://bugs.launchpad.net/nav/+bug/1518254|LP#1518254]]: I subnet matrix hos NTNU. En del nett /23-nett får feil visning og hyperlenke (men ikke konsekvent).
    * BUG :!: [[https://bugs.launchpad.net/nav/+bug/1518246|LP#1518246]]: Første subnett i 129.241.0.0/16 vises ikke, matrix starter på 129.241.1.0.
    * Rune Sydskjøer ønsker seg en slags IPAM for UNINETT, der vi også ser hvordan institusjonene har delt opp adressetildelingene sine.
        * UNINETT har sitt IP-register register som tekstfiler i dag; om vi lager noe nytt her burde vi ta i bruk NAV-APIet på de forskjellige VK-ene for å finne de faktiske inndelingene (slik unngår vi dobbeltregistreringer, og institusjoner som bruker NAV har allerede et større insitament for å holde NAV vedlike enn et sentralt IP-register).

REQ: NTNU ønsker forvørig en måte å sammenstille sine DHCP-pool-statistikker på VLAN-grafene til NAV. Konfigurasjon for å ta inn custom-metrikker basert på subnettadresse?

UiT har spilt inn et ønske om å innføre et nytt nivå over Location i Location/Room-hierarkiet, kalt "Sted" i forslaget.

    * Utviklernes motforslag er å innføre hierarki i Location og fjerne unikhetskravet i romnavn og locationnavn. Da kan man selv definere hva man vil bruke Locations til.
        * Flere brukere har også meldt inn at unike rommnummer er en merkelig begrensning (som kommer av at dette var realiteten på NTNU den gangen NAV oppsto).
    * Mye diskusjon rundt hvorvidt hierarki eller multi-lokasjon er veien å gå. Kanskje rom-begrepet skulle forsvinne også?
    * Jarle spiller inn at Locations kanskje kan brukes som "tags" - at man tagger et rom med flere locations, og at kombinasjonen av disse angir det spesifikke stedet for rommet.
        * Et tenkt tifelle: Et rom tagges med "Alta" og "Realfagbygget", mens et annet rom tagges med "Tromsø" og "Realfagbygget". Slik skiller man mellom rom i det ene og andre bygget som heter det samme på forskjellige campus.
    * En annen utfordring som har oppstått er utstyr som kan spres over flere rom, f.eks. switcher med fabric extenders. NAV kan i dag si hvilket rom en IP-adresse er på, men man kan f.eks. ikke angi romplassering for moduler (ettersom antagelsen fremdeles er at disse er *inni* boksen).
  
John-Magne og Morten går i tenkeboksen, i etterkant av møtet, for å se hvilke
konsekvenser de forskjellige lokasjons-forslagene har for NAV.
Oppfølgingsdiskusjon på mailinglisten før man kan legge frem et endelig
feature-forslag som tillegg på arbeidslisten.

Jarle greide ut om UiOs utfordringer ift. ytelse på og skalering av Graphite.
De opplevde veldig raskt problemer i sin Graphite-infrastruktur etter
overgangen til NAV 4. Man skalerte opp på dokumentert vis, horisontalt, ved
bruk av carbon-relay og flere carbon-cache-instanser (slik UNINETT gjør hos
kunder med flere samarbeidende VK-kasser). De hadde også stor nytte av vår
artikkel om UDP buffer overflow i carbon, som også rammet dem.

BUG :!: [[https://bugs.launchpad.net/nav/+bug/1518219|LP#1518219]]: UiO opplever også ytelsesproblemer med ipdevinfo, som konsekvent bruker
opp mot 15 sekunder på å laste en netbox-visning. DEBUG-mode viser at
SQL-setningene tilsammen ikke bruker mer enn et sekund. Her har vi
forbedringspotensiale.

REQ :!: [[https://bugs.launchpad.net/nav/+bug/1518222|LP#1518222]]: Peder ønsker seg at powerstats-tillegget til NAV skal støtte mer en ett enkelt serverrom.
    * Utvidelsen bør støtte mønstergjenkjenning av pdu-navn, i stedet for å være låst på "pdu-*"

REQ: NTNU ønsker støtte for "virtuelle powersupplies", som er i bruk på bl.a.
Nexus. Dette er PSUer med to inngangner, men som ellers fremstår som én PSU
(men inngangene er utskiftbare).
    * UiA har det samme på andre plattformer enn Nexus
    * NTNU og UiA må melde inn hvilke bokser dette er snakk om, så vi kan gjøre undersøkelser.

Rune Kittelsen nevner SDN og OpenStack som fremtidige utfordringer. Bør vi
begynne å snuse allerede nå på hva vi kan gjøre ift. disse nye teknologiene?
    * UiO: Cisco kommer snart med løsninger som kan plugges inn i OpenStack-infrastruktur.

REQ: UiO ønsker API-utvidelser.
    * Med Mulighet for flere tokens og token-administrasjon.
    * Tokens knyttet til brukere, som gir tilgang som denne brukeren
        * Liten ufordring her at NAV ikke har noen ordentlig autorisasjonsløsning utover URL-mønstre. Her bør vi begynne å se nærmere på alternative fremgangsmåter.


Møtet ble hevet kl. 15:09.

==== Dato for neste møte ====

Dato ble ikke valgt på møtet. UNINETT planlegger neste års tekniske samlinger,
og det søkes å finne en dato inntil en av disse. Morten skal undersøke nærmere
og komme med datoforslag.

==== Kommentarer ====

Gro-Anita, 16/11-15:
* enighet om full revisjon/ny-prioritering av oppgavelista