Nav-dev

nav-dev@lister.sikt.no

96 discussions

Re: Integration with GIS
by Morten Brekkevold 09 Mai '14

09 Mai '14

On Thu, 01 May 2014 10:44:48 -0500 Corey Thompson <cthompson(a)eastgrandforks.net> wrote: > Before I start doing such, I'm wondering if anyone has done any integration > between NAV and a PostGIS based GIS system (mostly using QGIS for "frontend"), > as I would rather add to existing work rather than repeating it...I thinking > of just creating views in postgres referencing NAV data for the GIS to use to > retrieve device inventory, status, and statistics in spatial queries. If it > becomes successful and useful, I will do a writeup. I don't know that anyone is working on this, no. NAV's only "GIS"-related information are the geo-coordinates of rooms, but these are stored as simple point datatypes (latitude/longitude numbers stored as (x,y) points), as NAV doesn't currently have any need for geospatial queries. If you have something useful to contribute, we would be glad to hear about :) -- Morten Brekkevold UNINETT

1 0

Re: Increase rommid column size table room
by Morten Brekkevold 02 Okt '13

02 Okt '13

On Mon, 26 Aug 2013 16:25:42 -0300 Bruno Galindro da Costa <bruno.galindro(a)gmail.com> wrote: > I need to add a roomid that has more than 30 chars. > > I've altered the size of rommid column in table room (at database level), > but the HTML fields has a 30 chars limitation. > > Nav web has built on Django framework which is very nice ;), but I don't > know where I can make this modification. The Django model Room is defined in the Python module nav.models.manage. The max_length attribute is set to 30 there. Modifying data model would require a SQL changescript under the `sql/changes/` directory, and a change to the Room model class. The Location/Room data models are modeled after the scheme used at NTNU (from which NAV originated). NTNU has multiple campuses and locations, but all wiring closets are identified by a unique 3 digit number (which makes the limit of 30 characters seem immense). That being said, the 30 character limit is entirely artificial. The database field is of the type VARCHAR, and could be changed to have no limit at all. However, since this string is a primary key, having it be a huge string isn't a good way to normalize the schema. > My sugestion is: > > 1 - add a field called Location in Edit IP Device screen which filters the > Room field. > 2 - add Location and Parent Organization information at IP Device Info. > > We can help you and your development team to make these modifications (and > maybe others). This could be a nice starting. IIUC, your use case is that you have so many rooms in your database, that the Room dropdown box for editing IP Devices is overpopulated? John-Magne has suggested something like this component: http://ivaynberg.github.io/select2/ - I.e. a hierarchical (Location/Room), searchable dropdown. I'm Cc:ing nav-dev, since your getting into development territory with this question. -- Morten Brekkevold UNINETT

2 3

Installer for third party NAV tools
by Ole Martin Bjørndalen 22 Aug '13

22 Aug '13

Hi, We have written a lot of third party tools for NAV here at UiT. Installing these every time we made a change was a chore, so I wrote a tool installer to automate this. An typical install script looks like this: from nav.uit.toolinst import install_tool install_tool( name='dhcp', title='DHCP', description='Add MAC-address to DHCP-service.') The installer will discover all relevant files and install them in their proper place. A full blueprint with a link to the code and examples can be found here: https://blueprints.launchpad.net/nav/+spec/tool-installer Is there any interest in such a tool? - Ole Martin

2 2

Trenger innspill til visning av topologigrafer i ipdevinfo
by Roy Sindre Norangshol 09 Nov '12

09 Nov '12

Hei hei! Det er et ønske for å vise topologigrafer i ipdevinfo, men her trenger vi innspill på hva som ønskes av funksjonalitet og hvordan vi skal løse problemene. Det første er hvordan dere ser for dere de to toplogigrafene skal representeres i ipdevinfo. Den første grafen, «Next-hop grafen» er relativt en liten og enkel graf som lett kan vises ved siden av andre elementer i same arkfane (f.eks. «Device Info») under ipdevinfo . Jeg ser for meg at grafen vil se tilsvarende ut som dette: (Netbox)<------+ +----------------> (Netbox) + + (Selected Netbox) + + | | | +-----> (Netbox) | (Netbox)<-----+ Vi ser for oss at det er naturlig at vi bare viser den «fysiske» topologien for «Next-hop grafen» (les lag2), eller er det ønskelig å kunne endre visning mellom lag2 og lag3? Om ja, hvordan? Mitt forslag om det skal støttes visning mellom lag 2 og lag 3 i «Next-hop grafen», gjøres dette ved å ha et klikkbart bilde som illustrerer å bytte visning mellom lag 2 og lag 3 i topologien. Selve kartet blir plassert i en «blå infoboks» (Jeg tenker på de blå infoboksene som har overskrifter som «IP Device: ip-adresse» og «DNS: ip-adresse» som vises på http://nav/ipdevinfo/x.x.x.x ) hvor overskriften kan være «Next-hop graph [bildelink for å endre visning mellom nettverkslagene]{egenskaper på bildet: flyter til høyre i infoboksen slik bildet alltid dukker opp helt til høyre i infoboksen}». Har dere forslag til hvordan bildet for visning mellom lag 2 og lag 3 ev. skal se ut? Eksisterer det allerede et allment kjent ikon som bør brukes? Funksjonaliteten til «Next-hop grafen» er å gi et kjapt innblikk over hvem som er dens nærmeste nabo for valgt «netbox». Når du klikker på en «netbox» i grafen, vil du bli videresendt til ipdevinfo-siden til «netboxen» du klikket på med visning for dens «Next-hop graf». I tillegg vil det nedenfor «Next-hop grafen» ligge en hyperlenke til /netmap hvor du kan se hele topologien med den valgte «netboxen» som nullpunkt i nettkartet. Den andre grafen som er ønsket er en visning av «downlinks» fra en valgt «netbox». Jeg velger å kalle grafen TFSDID («Topology from selected device and it's downlinks») inntil dere kommer med et betre forslag. :-) TFSDID-grafen har flere spennende problemer. Om valgt «netbox» er en GW eller GSW vil det å navigere seg ned igjennom grafen føre til at vi viser hele topologien som NAV kjenner til, og dette er vel allerede jobben til /netmap. Det same problemet oppstår om «next-hop» fra valgt «netbox» er en GW eller GSW, og vil ende opp med at du viser store deler av topologien som NAV kjenner til. Hvordan løser vi dette? Skal vi tillate å vise en TFSDID-graf om valgt «netbox» er av typen GW eller GSW? Ønsker dere å vise «downlinks» til GW-en om GW-en står som «next-hop» til valgt «netbox»? Vil det fungere å legge inn et unntak for å ikke utvide grenen i grafen om «next-hop netboxen» til den valgte «netboxen» er av typen GW eller GSW? Jeg har også et inntrykk av at TFSDID-grafen kan bli ganske diger, og må plasseres i egen arkfane i /ipdevinfo. Er det kanskje bedre at dette blir en funksjon i /netmap? Jeg ser for meg at TFSDID-grafen vil se tilsvarende ut som dette: (SW)<-------+ +----> (SW)+ +----> (SW) | | | | This is actaully fine, as it limits | | | | the topology graph somehow at least... + + | + (Selected Netbox) +-> (GW)+------> (SW)+------>(GW)+--->(SW) + + | | | +-------> (GW)+--->(SW) (GW)<----------+ -- Roy Sindre Norangshol Studenthospitant hos UNINETT norangshol(a)uninett.no

1 0

UNINETT is hiring a NAV developer
by Morten Brekkevold 30 Apr '12

30 Apr '12

Hi everyone, our mailing lists aren't too high-traffic, so I hope it doesn't hurt to spam you with a job ad ;) Up until now, I've been the only full-time employee working on NAV development at UNINETT. This is finally about to change: We are now hiring another full-time software engineer to join our NAV development team in Trondheim. If you are interested, or know of someone who might be, please see the full job ad here: http://www.uninett.no/en/job-opportunity-software-engineer-network-monitori… -- Morten Brekkevold UNINETT

1 1

Problemet i NAV hos deg
by Vidar Faltinsen 20 Sep '11

20 Sep '11

Heisan Asbjørn, Har snakket med Morten om ditt NAV problem. Har skrudd på mer debugging ved å endre nav.conf litt. Da får nå en mer fornuftig feilmelding enn "something went wrong". Denne er nå den samme som jeg ser opptrer på andre verktøykasser, så dette er en bug. Det gjelder etter det jeg kan se når man skal opprette filter og/eller filtergrupper. Det er postet som bug her https://bugs.launchpad.net/nav/+bug/854696 Jeg tør ikke love når vi har en fiks, men håper snart. Du hadde også et problem i seed db når du skulle legge til utstyr elns? Dersom dette opptrer igjen, vennligst gi beskjed. mvh - Vidar

1 0

Adding support for 3Com 2900-family
by Mikael Knutsson 14 Sep '11

14 Sep '11

Hello, I'm interested in helping out adding support for the 3Com switch family 2900 also known as HP V1910. I've managed to find the SNMP OIDs it uses to store VLAN information and I've also discovered how it stores it (it may be very standard though, I've just never done this before) and I've also managed to get my hands on the MIB-files to cover it. I've already ran into some problems trying to figure out how to write to the OIDs for VLANs though. There are multiple storing the same kind of data in different formats, but all of them gives me 'inconsistentValue' when I try writing to them in - as far as I can figure out - a 'proper' format. I'm in your IRC channel on freenode asking around and they directed me here. I appreciate any assistance I can get in the matter! -- // Best Regards, Mikael K. ************************************ Webhallen Sverige AB Svetsarvägen 10B 171 41 Solna Tel: 08 - 673 60 00 Fax: 08 - 650 00 30 Sida: www.webhallen.com Mail: mikael(a)webhallen.com ************************************

2 6

Weathergoose 2 support (Bug #737446)
by Halden Marius 25 Mai '11

25 Mai '11

Hi! I have made a patch to add support for weathergoose 2, a mercurial bundle with the changes is attached to this email. Regards Marius Halden

2 5

NAV 3.7
by Vidar Faltinsen 10 Okt '10

10 Okt '10

Hi, 3.6 i out, what next... A reminder of our blueprints set for NAV 3.7 in less than a month from now (Nov 4): https://blueprints.launchpad.net/nav/3.7 Fredrik * threshold-interface * active directory support Magnus * seeddb * sudo Morten * UTM field for OSM support * ipdevpoll static routes * ipdevpoll vrrp (where do we target the ipdevinfo refresh button?) Do we need a status meeting for 3.7, Morten? regards, - Vidar

1 0

Defined dates and changed around on milestones
by Vidar Faltinsen 20 Sep '10

20 Sep '10

Hi all, After today's meeting the following dates and targets are set: - 3.6: Oct 7 - 3.7: Nov 4 - 3.8: Feb 3 2011 - 3.9: Apr 7 2011 - 3.10: Jun 23 2011 The idea is more rapid and smaller feature releases for the community to give new functionality more often. It is better to have the date fixed and postpone a given milestone, rather than keep postponing the release. If development should be faster than expected more can be included in the release. So moving around blueprints will be a highly dynamic activity. 3.7 has now: https://blueprints.launchpad.net/nav/3.7 3.8 will have portadmin which is the adoption of vlanadmin from NTNU. It is hard to be accurate regarding 3.9 and 3.10, but some blueprints are set for those milestones to. A number of blueprints are not set for a target at all. Morten and I should discuss further if the 3.7 volume is within reach of Nov 4. In discussion with John Magne we find portAdmin to be more realistic for 3.8. cheers, - Vidar

1 0

← Newer
1
2
3
4
5
6
7
8
9
10
Older →

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

Nav-dev