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

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

1. Status og demo
2. Sensorbasert sikkerhetsvarsling (Suricata)
3. Videre utvikling

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

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.

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.

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.

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: I subnet matrix hos NTNU. En del nett /23-nett får feil visning og hyperlenke (men ikke konsekvent).
• BUG Launchpad: 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 Launchpad: 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 Launchpad: 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 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.

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