User Tools

Site Tools


nav-ref:navref_120915

NAV referansegruppemøte 12. november 2015

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.

  1. Status og demo
  2. Sensorbasert sikkerhetsvarsling (Suricata)
  3. 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 :!: LP#1518251 LP#1518254: I subnet matrix hos NTNU. En del nett /23-nett får feil visning og hyperlenke (men ikke konsekvent).
  • BUG :!: 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 :!: 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 :!: 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

nav-ref/navref_120915.txt · Last modified: 2016/09/21 12:42 by morten