Hei Morten,
morten.brekkevold@uninett.no said:
On Wed, 25 Jul 2012 13:55:27 +0200 Borge Brunes borge.brunes@uit.no wrote:
Hei,
om denne saken spesielt: Ifm. en sak vi skulle feilsøke så dukket det opp noe som forvirret oss. Vi var på jakt etter en mac-adr i nettet da vi oppdaget at innsamlingen av cam og arp-data hadde stoppet opp (ipdevpoll gikk som den skulle).
Selv om innsamlingen hadde stoppet opp for lenge siden så fikk man likevel opp status "still active" under "End time" i machinetracker. machinetracker gjør altså en antakelse om at mac&arp-adr. lever evig dersom den er sett før innsamlingen stoppet opp, selv om den ikke er sett på en boks. Hvorfor det? Jeg mener at dette er feil. arp/mac-adr er ikke samlet inn på over en mnd. og da kan man ikke si at den er "still active"
om slike ting generelt: i første møtet i NAV-ref-gruppa som diskuterte vi veien videre og vi ble enig om at datakvaliteten i NAV burde bedres. Man skal kunne stole på de dataene man har i NAV. Slik jeg ser det så er overnevnte et eks. på det motsatte.
Dette er et godt og konkret innspill, Børge. Da vi etterspurte hva som lå bak formuleringen "heve datakvaliteten" tidligere i år var det relativt få konkrete svar å spore, bortsett fra mumling om "topologi".
På helt generelt grunnlag kan jeg foreslå at cam- og arp-innslag i databasen kan utsettes for en expiry-mekanisme som er uavhengig av innsamling. Dvs. at dersom en arp/cam-record ikke er blitt bekreftet av innsamleren innen en viss tid, så vil den automatisk bli lukket. Ulempen er at dersom innsamleren skal bekrefte alle åpne innslag til enhver tid, vil det føre til bloat i databasen. Alternativt kan innsamleren bare bekrefte med timestamp at den har kjørt ferdig for en gitt boks, slik at expiry er relativt til dette tidspunktet.
Problemet er slik jeg ser det at systemet ikke har noen mekanisme for å handtere feilsituasjoner. I dette tillfellet så hadde innsamleren ikke samlet inn noe data (men heller ikke stoppet). Kanskje burde det gjøres en sjekk etter at innsamleren er ferdig? Eks. når innsamleren melder at den er ferdig med å samle inn CAM-innslag fra en boks så burde det sjekkes hvorvidt den faktisk har samlet inn data.
Det kan selvsagt dukke opp tilfeller hvor en switch ikke har noen devicer bak seg og at dermed ikke er samlet inn CAM-innslag, men det får vi leve med. Det er uansett nyttig å vite om at en switch står og trekker strøm uten gjøre noe fornuftig.
Slik har jeg tenk at ting fungerer. ARP-innsamling starter og henter inn ARP-data fra box:
1) Dersom man oppdager ny IP-adr. så legges denne inn i en tabell med tidsstempel for når den ble oppdaget og tagges med AKTIV
2) Dersom en IP-adr. som samles inn eksisterer fra før av med status AKTIV så oppdateres tidstempel for sist sett.
3) Innsamling avsluttes og ryddejobb starter
4) Dersom det ligger IP-adr. i tabellen med status AKTIV og med tidsstempel eldre enn når siste innsamling ble avsluttet så tagges IP-adr. med IKKE-AKTIV (Dukker IP-adr opp igjen så betraktes IP-adr. som ny). UNNTATT
5) Dersom ikke tidsstempel på noen av de AKTIVE IP-adr. ble oppdatert (altså ikke sett) eller det ikke kom til noen nye IP-adr. så må det gå ut varsel (se tekst om varsel lenger ned i eposten) og IP-adr. settes til status DATARÅTE el.
6) ryddejobb avsluttes
Nårjeg så gjør en spørring gjennom web-gresesnittet på en IP-adr. så bør det opplyses (i tillegg til dagens info) - hvilke GW/GSW IP-adr. ble samlet inn på og - når ble siste innsamling av ARP-data foretatt på denne GW/GSW - status på evnt. IP-adr. i punkt 5 må da være DATARÅTE el.
Litt usikker på jeg fikk forklart dette på en møte som var forståelig, men Ingeborg skjønte det etter hvert :-)
Helt spesifikt, til din problemstilling, lurer jeg på hvordan dere bekreftet at "innsamleren" hadde stoppet opp? Hadde NAV sluttet å logge ARP og CAM-innslag for alle bokser dere overvåker, eller bare for bestemte bokser? Hadde den sluttet å logge _både_ ARP og CAM eller bare en av delene?
Se post fra Ingeborg i dag som gikk utenom nav-ref.
Dette er nyttig informasjon, da ARP og CAM samles inn av to forskjellige jobber, til forskjellige tidspunkt og individuelt pr. boks, i motsetning til tidligere, da både ARP-innsamling og CAM-innsamling var individuelle prosesser som kjørte fra cron og samlet inn for alle bokser i "runder".
På møtet ivret jeg for et internt system-check som fanget opp feilsituasjoner som f.eks.
- cam/arp-innsamling har stoppet opp
- bokser av type GW uten ruterporter
- bokser av type SW uten switcheporter
- annen datainnsamling som ikke virker som den skal.
- osv.
Jeg ivrer enda mer for et slikt system nå :-)
Hvilket grensesnitt skal et slikt system ha?
Skal systemsjekken kjøres manuelt av administrator, eller som en cronjobb?
Dersom systemsjekken kjører automatisk i cron, hvem skal overvåke at systemsjekkeren virker?
Skal systemsjekken ha en statusside på web og/eller CLI?
Skal feil i systemsjekken sendes som alarmer i alert profiles, eller bare direkte som mail til ADMIN_MAIL fra nav.conf?
Her tenker jeg at systemcheck må/kan gjøres på ulike nivåer, og at varsler skjer via alarmer i alert profiles og/eller ADMIN_MAIL fra nav.conf
Eks. 1) Ny box legges inn med type GW. Når den så legges inn så burde man sjekke at: - at boxen har ruterporter - at boxen ikke har vensentlig mindre støttede OIDer enn tilsvarende bokser som allerde ligger inne. - etc. Feiler overnevnte check så burde det sendes ut alarm i alert profiles
2) Nevnte checker bør kjøres (via cron?) med gjevne mellomrom slik at evnt. bug innført i nye versjoner av NAV blir fanget opp. I tillegg til varsel så kan det kanskje være lurt med en statusside som sier noe om hvilke checker som kjører og når de sist har kjørt
3) Siden den nye boxen er type GW så bør det finnes flere enn 2 x antall. aktive egne ruterporter i arp-tabell. Dette må det sjekkes på når ARP-innsamleren har kjørt.
Børge
-- Morten Brekkevold UNINETT
On Tue, 21 Aug 2012 14:44:55 +0200 Borge Brunes borge.brunes@uit.no wrote:
Problemet er slik jeg ser det at systemet ikke har noen mekanisme for å handtere feilsituasjoner.
Hvordan er dette forskjellig fra den systemsjekken du beskriver lenger ned? Dette høres for meg ut til å bare være en del-mekanisme i en slik systemsjekk.
I dette tillfellet så hadde innsamleren ikke samlet inn noe data (men heller ikke stoppet). Kanskje burde det gjøres en sjekk etter at innsamleren er ferdig? Eks. når innsamleren melder at den er ferdig med å samle inn CAM-innslag fra en boks så burde det sjekkes hvorvidt den faktisk har samlet inn data.
Det kan selvsagt dukke opp tilfeller hvor en switch ikke har noen devicer bak seg og at dermed ikke er samlet inn CAM-innslag, men det får vi leve med. Det er uansett nyttig å vite om at en switch står og trekker strøm uten gjøre noe fornuftig.
Slik har jeg tenk at ting fungerer. ARP-innsamling starter og henter inn ARP-data fra box:
Dersom man oppdager ny IP-adr. så legges denne inn i en tabell med tidsstempel for når den ble oppdaget og tagges med AKTIV
Dersom en IP-adr. som samles inn eksisterer fra før av med status AKTIV så oppdateres tidstempel for sist sett.
Det er dette punktet jeg mener vil skape bloat i databasen, samt veldig mye ekstra write-I/O til disk.
Med PostgreSQL vil du i praksis opprette en ny rad som er en kopi av den gamle, bare med en endret timestamp i et felt. Dvs. så lenge et ARP-innslag er aktivt i ruteren, så vil det lages en kopi hver halve time frem til ARP-innslaget avsluttes.
Det ene er altså I/O-en, det andre er hvor flink den aktuelle PostgreSQL-versjonen er til å gjenbruke lagringsplassen til døde rader.
Innsamling avsluttes og ryddejobb starter
Dersom det ligger IP-adr. i tabellen med status AKTIV og med tidsstempel eldre enn når siste innsamling ble avsluttet så tagges IP-adr. med IKKE-AKTIV (Dukker IP-adr opp igjen så betraktes IP-adr. som ny). UNNTATT
Dersom ikke tidsstempel på noen av de AKTIVE IP-adr. ble oppdatert (altså ikke sett) eller det ikke kom til noen nye IP-adr. så må det gå ut varsel (se tekst om varsel lenger ned i eposten) og IP-adr. settes til status DATARÅTE el.
ryddejobb avsluttes
Det du beskriver her er den måten ARP-loggeren allerede fungerer på, bare at du i tillegg vil ha den til å oppdatere alle eksisterende rader hver gang.
Problemet ditt her er at innsamlingen sannsynligvis aldri startet eller ikke fullførte, og hvordan vet "ryddejobben" da at den skal starte?
Når en ARP-jobb er fullført og fikk lagret endringer til database, så vet den det selv. Det bør den kvittere for. En systemsjekk må så kunne se at den siste ARP-kvitteringen for en gitt boks er for gammel og lage en alarm på det.
Hvis du ser på rapporten /report/lastupdated (den ble innført i 3.11 et sted), ser du tid siden siste kjøring av inventory-jobben til ipdevpoll for hver boks, kombinert med ping-status og SNMP-status for hver boks. Dersom en boks både er oppe og har ok SNMP-status, men det er over 6 timer siden inventory kjørte, så er noe galt.
Denne mekanismen bygger på lastupdate-timestampen som henger igjen fra getDeviceData, og som i dag bare er koblet til inventory-jobben. Tanken er at dette skal utvides, slik at hver ipdevpoll-jobb skal sette en timestamp for seg selv når den har fullført og lagret sine endringer.
Sett opp mot det konfigurerte jobbintervallet i ipdevoll.conf kan man da raskt se hvilke jobber som har uteblitt, og det er en god jobb for en automatisk systemsjekker (så slipper du å reloade disse rapportene til enhver tid).
Dette bør være nok til å vite om jobbene kjører som de skal. Et system som kvitterer for hvert eneste ARP-innslag hver gang innsamlingen kjører vil bare være marginalt bedre ved at det kan oppdage en bug i selve koden til ARP-loggeren som gjør at den ikke lukker døde innslag etter seg selv, selv om den har kvittert for en suksessfull kjøring.
Andre mekanismer som kan være interessante å tenke på:
* Om en ruter går ned, skal vi da lukke alle åpne ARP-innslag logget fra den? * Om en switch går ned, skal vi da lukke alle åpne CAM-innslag logget fra den?
Nårjeg så gjør en spørring gjennom web-gresesnittet på en IP-adr. så bør det opplyses (i tillegg til dagens info)
- hvilke GW/GSW IP-adr. ble samlet inn på og
Disse dataene ligger der, så denne er mulig allerede nå ved å bare utvide tabellen med en kolonne.
- når ble siste innsamling av ARP-data foretatt på denne GW/GSW
Denne er mulig når lastupdated utvides til å være en kvittering per jobb per boks.
- status på evnt. IP-adr. i punkt 5 må da være DATARÅTE el.
Altså, når det er >X tid siden ARP-jobb for kildeboksen kjørte, der X er konfigurert intervall i ipdevpoll.conf, så skal raden flagges som mistenkelig på et eller annet vis.
Helt spesifikt, til din problemstilling, lurer jeg på hvordan dere bekreftet at "innsamleren" hadde stoppet opp? Hadde NAV sluttet å logge ARP og CAM-innslag for alle bokser dere overvåker, eller bare for bestemte bokser? Hadde den sluttet å logge _både_ ARP og CAM eller bare en av delene?
Se post fra Ingeborg i dag som gikk utenom nav-ref.
Ja, denne diskusjonen har Ingeborg og jeg vært innom før. Heia FreeBSD. Dette vil kreve hacking av det SNMP-biblioteket vi benytter oss av, slik at vi enten må bundle biblioteket i NAV eller krysse fingrene for at noen tar i mot patcher upstream - kombinert med at vi ikke har noen FreeBSD-boks å teste evt. patcher på :-P
- Skal feil i systemsjekken sendes som alarmer i alert profiles, eller bare direkte som mail til ADMIN_MAIL fra nav.conf?
Her tenker jeg at systemcheck må/kan gjøres på ulike nivåer, og at varsler skjer via alarmer i alert profiles og/eller ADMIN_MAIL fra nav.conf
Eks.
- Ny box legges inn med type GW. Når den så legges inn så burde man sjekke at: - at boxen har ruterporter
- at boxen ikke har vensentlig mindre støttede OIDer enn tilsvarende bokser som allerde ligger inne.
Her er jo et godt spørsmål hva som er "vesentlig", ettersom det ikke fins særlig rom for skjønn i en programmert algoritme. Dessuten vil de fleste registrerte OIDene forsvinne fra databasen snart, ettersom det bare er de som logges av Cricket som er interessante i dag (det er bare mcc.py som henger seg opp i hvordan OID-profilen ser ut i NAV 3.11, så kolonnen vil nok forsvinne fra netbox-rapporten også).
- etc.
Feiler overnevnte check så burde det sendes ut alarm i alert profiles
Så med andre ord er ADMIN_MAIL uaktuell? Hva om problemet er at event/alarmsystemet ikke fungerer som det skal? Skal det finnes en systemsjekk for det også?
- Nevnte checker bør kjøres (via cron?) med gjevne mellomrom slik at evnt. bug innført i nye versjoner av NAV blir fanget opp. I tillegg til varsel så kan det kanskje være lurt med en statusside som sier noe om hvilke checker som kjører og når de sist har kjørt
Så en cronjobb med forskjellige systemsjekker da, med andre ord. Da bør hver feil registreres som en tilstandsfull alarm i NAV, slik at du ikke får de samme varslene hver eneste gang systemsjekken kjører.
Mye mat til møtet 2. oktober her :)
Ser fram til 2. oktober :)
Et innspill til i forhold til arp og cam-databasen:
Vi tenger å ha en mekanisme for å slette unna innslag i databasen som vi ikke har lov til å beholde. NTNU har f.eks vedtak fra datatilsynet på at vi kun kan beholde arp/cam-data for studentbyene i 21 dager. Jeg husker ikke hvordan/om det ryddes i databasen pr i dag.
Gro-Anita
-----Original Message----- From: nav-ref-request@uninett.no [mailto:nav-ref-request@uninett.no] On Behalf Of Morten Brekkevold Sent: Wednesday, August 22, 2012 11:03 AM To: Borge Brunes Cc: nav-ref@uninett.no Subject: Re: [nav-ref] Om arp og cam-innsamling og "end time" - system check
On Tue, 21 Aug 2012 14:44:55 +0200 Borge Brunes borge.brunes@uit.no wrote:
Problemet er slik jeg ser det at systemet ikke har noen mekanisme for å handtere feilsituasjoner.
Hvordan er dette forskjellig fra den systemsjekken du beskriver lenger ned? Dette høres for meg ut til å bare være en del-mekanisme i en slik systemsjekk.
I dette tillfellet så hadde innsamleren ikke samlet inn noe data (men heller ikke stoppet). Kanskje burde det gjøres en sjekk etter at innsamleren er ferdig? Eks. når innsamleren melder at den er ferdig med å samle inn CAM-innslag fra en boks så burde det sjekkes hvorvidt den faktisk har samlet inn data.
Det kan selvsagt dukke opp tilfeller hvor en switch ikke har noen devicer bak seg og at dermed ikke er samlet inn CAM-innslag, men det får vi leve med. Det er uansett nyttig å vite om at en switch står og trekker strøm uten gjøre noe fornuftig.
Slik har jeg tenk at ting fungerer. ARP-innsamling starter og henter inn ARP-data fra box:
Dersom man oppdager ny IP-adr. så legges denne inn i en tabell med tidsstempel for når den ble oppdaget og tagges med AKTIV
Dersom en IP-adr. som samles inn eksisterer fra før av med status AKTIV så oppdateres tidstempel for sist sett.
Det er dette punktet jeg mener vil skape bloat i databasen, samt veldig mye ekstra write-I/O til disk.
Med PostgreSQL vil du i praksis opprette en ny rad som er en kopi av den gamle, bare med en endret timestamp i et felt. Dvs. så lenge et ARP-innslag er aktivt i ruteren, så vil det lages en kopi hver halve time frem til ARP- innslaget avsluttes.
Det ene er altså I/O-en, det andre er hvor flink den aktuelle PostgreSQL- versjonen er til å gjenbruke lagringsplassen til døde rader.
Innsamling avsluttes og ryddejobb starter
Dersom det ligger IP-adr. i tabellen med status AKTIV og med tidsstempel eldre enn når siste innsamling ble avsluttet så tagges IP-adr. med IKKE-
AKTIV
(Dukker IP-adr opp igjen så betraktes IP-adr. som ny). UNNTATT
Dersom ikke tidsstempel på noen av de AKTIVE IP-adr. ble oppdatert (altså ikke sett) eller det ikke kom til noen nye IP-adr. så må det gå ut varsel (se tekst om varsel lenger ned i eposten) og IP-adr. settes til status DATARÅTE el.
ryddejobb avsluttes
Det du beskriver her er den måten ARP-loggeren allerede fungerer på, bare at du i tillegg vil ha den til å oppdatere alle eksisterende rader hver gang.
Problemet ditt her er at innsamlingen sannsynligvis aldri startet eller ikke fullførte, og hvordan vet "ryddejobben" da at den skal starte?
Når en ARP-jobb er fullført og fikk lagret endringer til database, så vet den det selv. Det bør den kvittere for. En systemsjekk må så kunne se at den siste ARP-kvitteringen for en gitt boks er for gammel og lage en alarm på det.
Hvis du ser på rapporten /report/lastupdated (den ble innført i 3.11 et sted), ser du tid siden siste kjøring av inventory-jobben til ipdevpoll for hver boks, kombinert med ping-status og SNMP-status for hver boks. Dersom en boks både er oppe og har ok SNMP-status, men det er over 6 timer siden inventory kjørte, så er noe galt.
Denne mekanismen bygger på lastupdate-timestampen som henger igjen fra getDeviceData, og som i dag bare er koblet til inventory-jobben. Tanken er at dette skal utvides, slik at hver ipdevpoll-jobb skal sette en timestamp for seg selv når den har fullført og lagret sine endringer.
Sett opp mot det konfigurerte jobbintervallet i ipdevoll.conf kan man da raskt se hvilke jobber som har uteblitt, og det er en god jobb for en automatisk systemsjekker (så slipper du å reloade disse rapportene til enhver tid).
Dette bør være nok til å vite om jobbene kjører som de skal. Et system som kvitterer for hvert eneste ARP-innslag hver gang innsamlingen kjører vil bare være marginalt bedre ved at det kan oppdage en bug i selve koden til ARP- loggeren som gjør at den ikke lukker døde innslag etter seg selv, selv om den har kvittert for en suksessfull kjøring.
Andre mekanismer som kan være interessante å tenke på:
- Om en ruter går ned, skal vi da lukke alle åpne ARP-innslag logget fra
den?
- Om en switch går ned, skal vi da lukke alle åpne CAM-innslag logget
fra den?
Nårjeg så gjør en spørring gjennom web-gresesnittet på en IP-adr. så bør det opplyses (i tillegg til dagens info)
- hvilke GW/GSW IP-adr. ble samlet inn på og
Disse dataene ligger der, så denne er mulig allerede nå ved å bare utvide tabellen med en kolonne.
- når ble siste innsamling av ARP-data foretatt på denne GW/GSW
Denne er mulig når lastupdated utvides til å være en kvittering per jobb per boks.
- status på evnt. IP-adr. i punkt 5 må da være DATARÅTE el.
Altså, når det er >X tid siden ARP-jobb for kildeboksen kjørte, der X er konfigurert intervall i ipdevpoll.conf, så skal raden flagges som mistenkelig på et eller annet vis.
Helt spesifikt, til din problemstilling, lurer jeg på hvordan dere bekreftet at "innsamleren" hadde stoppet opp? Hadde NAV sluttet å logge ARP og CAM-innslag for alle bokser dere overvåker, eller bare for bestemte bokser? Hadde den sluttet å logge _både_ ARP og CAM eller bare en av delene?
Se post fra Ingeborg i dag som gikk utenom nav-ref.
Ja, denne diskusjonen har Ingeborg og jeg vært innom før. Heia FreeBSD. Dette vil kreve hacking av det SNMP-biblioteket vi benytter oss av, slik at vi enten må bundle biblioteket i NAV eller krysse fingrene for at noen tar i mot patcher upstream - kombinert med at vi ikke har noen FreeBSD-boks å teste evt. patcher på :-P
- Skal feil i systemsjekken sendes som alarmer i alert profiles, eller bare direkte som mail til ADMIN_MAIL fra nav.conf?
Her tenker jeg at systemcheck må/kan gjøres på ulike nivåer, og at varsler skjer via alarmer i alert profiles og/eller ADMIN_MAIL fra nav.conf
Eks.
- Ny box legges inn med type GW. Når den så legges inn så burde man
sjekke
at: - at boxen har ruterporter
- at boxen ikke har vensentlig mindre støttede OIDer enn tilsvarende bokser som allerde ligger inne.
Her er jo et godt spørsmål hva som er "vesentlig", ettersom det ikke fins særlig rom for skjønn i en programmert algoritme. Dessuten vil de fleste registrerte OIDene forsvinne fra databasen snart, ettersom det bare er de som logges av Cricket som er interessante i dag (det er bare mcc.py som henger seg opp i hvordan OID-profilen ser ut i NAV 3.11, så kolonnen vil nok forsvinne fra netbox-rapporten også).
- etc.
Feiler overnevnte check så burde det sendes ut alarm i alert profiles
Så med andre ord er ADMIN_MAIL uaktuell? Hva om problemet er at event/alarmsystemet ikke fungerer som det skal? Skal det finnes en systemsjekk for det også?
- Nevnte checker bør kjøres (via cron?) med gjevne mellomrom slik at
evnt.
bug innført i nye versjoner av NAV blir fanget opp. I tillegg til varsel så kan det kanskje være lurt med en statusside som sier noe om hvilke checker som kjører og når de sist har kjørt
Så en cronjobb med forskjellige systemsjekker da, med andre ord. Da bør hver feil registreres som en tilstandsfull alarm i NAV, slik at du ikke får de samme varslene hver eneste gang systemsjekken kjører.
Mye mat til møtet 2. oktober her :)
-- Morten Brekkevold UNINETT
On Fri, 24 Aug 2012 11:44:23 +0000 Gro-Anita Hillestad Vindheim gro-anita.vindheim@ntnu.no wrote:
Et innspill til i forhold til arp og cam-databasen:
Vi tenger å ha en mekanisme for å slette unna innslag i databasen som vi ikke har lov til å beholde. NTNU har f.eks vedtak fra datatilsynet på at vi kun kan beholde arp/cam-data for studentbyene i 21 dager. Jeg husker ikke hvordan/om det ryddes i databasen pr i dag.
Sett opp en cronjobb med navclean.py.
Godt forslag.
Sånn bortsett fra at jeg trenger å gjøre forskjell på studentby og resten av NTNU, og det ser ikke ut som om navclean har støtte for sånt :) Og bortsett fra at det er startdato som teller, ikke utløpsdatoen. (Ønsker å rydde i innslag med startdato eldre enn 21/X dager.) Har laget et script, men det bruker griselang tid og kunne sikkert vært optimalisert, men det funker i hvert fall sånn som vi vil ha det.
Vi kan ta det opp ved en passende anledning, godt mulig at dette er en NTNU-spesifikt ønske :)
GA
-----Original Message----- From: Morten Brekkevold [mailto:morten.brekkevold@uninett.no] Sent: Friday, August 24, 2012 1:55 PM To: Gro-Anita Hillestad Vindheim Cc: Borge Brunes; nav-ref@uninett.no Subject: Re: [nav-ref] Om arp og cam-innsamling og "end time" - system check
On Fri, 24 Aug 2012 11:44:23 +0000 Gro-Anita Hillestad Vindheim <gro- anita.vindheim@ntnu.no> wrote:
Et innspill til i forhold til arp og cam-databasen:
Vi tenger å ha en mekanisme for å slette unna innslag i databasen som vi ikke har lov til å beholde. NTNU har f.eks vedtak fra datatilsynet på at vi kun kan beholde arp/cam-data for studentbyene i 21 dager. Jeg husker ikke hvordan/om det ryddes i databasen pr i dag.
Sett opp en cronjobb med navclean.py.
-- Morten Brekkevold UNINETT
-
Borge Brunes -
Gro-Anita Hillestad Vindheim -
Morten Brekkevold