<?xml version="1.0" encoding="UTF-8"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns="http://purl.org/rss/1.0/" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:syn="http://purl.org/rss/1.0/modules/syndication/" xmlns:admin="http://webns.net/mvcb/">
  <channel rdf:about="http://blog.gmane.org/gmane.network.nav.user">
    <title>gmane.network.nav.user</title>
    <link>http://blog.gmane.org/gmane.network.nav.user</link>
    <description/>
    <syn:updatePeriod>hourly</syn:updatePeriod>
    <syn:updateFrequency>1</syn:updateFrequency>
    <syn:updateBase>1901-01-01T00:00+00:00</syn:updateBase>
    <items>
      <rdf:Seq>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.network.nav.user/1154"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.network.nav.user/1154"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.network.nav.user/1151"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.network.nav.user/1146"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.network.nav.user/1143"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.network.nav.user/1141"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.network.nav.user/1139"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.network.nav.user/1138"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.network.nav.user/1134"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.network.nav.user/1128"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.network.nav.user/1124"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.network.nav.user/1113"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.network.nav.user/1110"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.network.nav.user/1109"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.network.nav.user/1106"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.network.nav.user/1105"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.network.nav.user/1100"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.network.nav.user/1098"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.network.nav.user/1095"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.network.nav.user/1092"/>
      </rdf:Seq>
    </items>
    <image rdf:resource="http://gmane.org/img/gmane-25t.png"/>
    <textinput rdf:resource=""/>
  </channel>
  <image rdf:about="http://gmane.org/img/gmane-25t.png">
    <title>Gmane</title>
    <url>http://gmane.org/img/gmane-25t.png</url>
    <link>http://gmane.org</link>
  </image>
  <item rdf:about="http://comments.gmane.org/gmane.network.nav.user/1154">
    <title>Announcement: NAV 3.14.15926 released</title>
    <link>http://comments.gmane.org/gmane.network.nav.user/1154</link>
    <description>&lt;pre&gt;NAV 3.14.15926, another maintenance release of the endless NAV 3.14
series is now available for download at Launchpad:
https://launchpad.net/nav/3.14/3.14.15926

This release fixes the following reported issues:

  * LP#1177754 (SRV and OTHER category devices have no uplinks)
  * LP#1185786 (maintengine.py crashes on any maintenance task with room or
                location components)
  * LP#1185848 (VLAN topology direction is wrong in cases of multiple links
                between two devices)
  * LP#1186193 (Cricket collects statistics from EDGE switches in NAV 3.14.1592)


Please report bugs at https://launchpad.net/nav/+filebug


Binary packages for Debian will be made available as soon as possible.
The Debian package is maintained by Morten Werner Forsbring, on
commission from UNINETT.


Happy NAVing everyone!

&lt;/pre&gt;</description>
    <dc:creator>Morten Brekkevold</dc:creator>
    <dc:date>2013-06-20T08:06:01</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.network.nav.user/1154">
    <title>Announcement: NAV 3.14.15926 released</title>
    <link>http://comments.gmane.org/gmane.network.nav.user/1154</link>
    <description>&lt;pre&gt;NAV 3.14.15926, another maintenance release of the endless NAV 3.14
series is now available for download at Launchpad:
https://launchpad.net/nav/3.14/3.14.15926

This release fixes the following reported issues:

  * LP#1177754 (SRV and OTHER category devices have no uplinks)
  * LP#1185786 (maintengine.py crashes on any maintenance task with room or
                location components)
  * LP#1185848 (VLAN topology direction is wrong in cases of multiple links
                between two devices)
  * LP#1186193 (Cricket collects statistics from EDGE switches in NAV 3.14.1592)


Please report bugs at https://launchpad.net/nav/+filebug


Binary packages for Debian will be made available as soon as possible.
The Debian package is maintained by Morten Werner Forsbring, on
commission from UNINETT.


Happy NAVing everyone!

&lt;/pre&gt;</description>
    <dc:creator>Morten Brekkevold</dc:creator>
    <dc:date>2013-06-20T08:06:01</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.network.nav.user/1151">
    <title>Hardware recommendation</title>
    <link>http://comments.gmane.org/gmane.network.nav.user/1151</link>
    <description>&lt;pre&gt;Hi,

first of all welcome to the list!

we (UniBasel) use NAV for quite some while now and are very pleased with the possibilities NAV gives us. We use Debian as OS with the following Setup:

root&amp;lt; at &amp;gt;urz-nav:~# uname -a
Linux urz-nav 2.6.32-5-amd64 #1 SMP Fri May 10 09:44:53 UTC 2013 x86_64 GNU/Linux
root&amp;lt; at &amp;gt;urz-nav:~# cat /etc/debian_version
6.0.7
root&amp;lt; at &amp;gt;urz-nav:~# dpkg -l | grep nav
ii  nav                                 2+3.14.15-1                  Network Administration Visualized

A problem we have since a while is that our system is permanently under a lot of load (mostly CPU bound) and we haven't really found a way to reduce the pressure. The hardware we use is a hp blade (ProLiant BL460c G6) with:

Intel(r) Xeon(r) Processor X5550 (4 Cores/ 8 Threats)
(8M Cache, 2.66 GHz, 6.40 GT/s Intel(r) QPI)

and:
root&amp;lt; at &amp;gt;urz-nav:~# free
             total       used       free     shared    buffers     cached
Mem:      12321700   11673596     648104          0     387768    9123748


At the moment we have 1460 active Devices (mainly Cisco Switches). Around 30 or 40 are OVERDUE in:
https://urz-nav/report/lastupdated

So my question is, do you have any good experience with HW-systems that are actually dealing with this amount of devices or is there any tuning possibility (without losing functionality) we could try to reduce the pressure on the system?

Thanks in advance,
Mischa Diehm

--
Mischa Diehm           |  Network Operation Center (NOC)
Universitaet Basel     |  Universitaetsrechenzentrum
Klingelbergstr. 70     |  CH-4056 Basel         |  Switzerland
Tel. +41 61 267 15 74  |  Fax +41 61 267 22 82  |  http://urz.unibas.ch

&lt;/pre&gt;</description>
    <dc:creator>Mischa Diehm</dc:creator>
    <dc:date>2013-06-18T10:25:25</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.network.nav.user/1146">
    <title>NAV dashboard teaser</title>
    <link>http://comments.gmane.org/gmane.network.nav.user/1146</link>
    <description>&lt;pre&gt;Hi NAV'ers!

In an effort to break the silence on this mailing-list I decided to post a
teaser of what we're working with regarding new layout and user friendlyness.

The attached image shows the last iteration of the front page. The plan is to
make it customizable for the individual user by provinding a set of "Navlets" or
widgets that show updated information and provide shortcuts to NAV's tools.

A user can add, remove and reorder Navlets to create the dashboard he wants.
Some of the Navlets are individually configured, for instance to display the
graph or the status the user finds most interesting.

A Navlet can be set to auto-update periodically so that the dashboard can be
used on always on screens in network monitoring environments.

This is a work in progress. Any input from you is appreciated!

NB: The logo is a placeholder.


Regards

&lt;/pre&gt;</description>
    <dc:creator>John-Magne Bredal</dc:creator>
    <dc:date>2013-05-27T08:51:45</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.network.nav.user/1143">
    <title>mod_python error and InterfaceError: connection already closed</title>
    <link>http://comments.gmane.org/gmane.network.nav.user/1143</link>
    <description>&lt;pre&gt;I've been running NAV (3.14.15 on Debian appliance) for a few weeks without 
any issues but recently I started getting errors when running the Layer 2 
trace tool. I tried upgrading but I guess the package for Debian hasn't been 
released yet... Any suggestions would be appreciated. Thank you.


The error message is below:

MOD_PYTHON ERROR

ProcessId:      1023
Interpreter:    'nav-appliance.uninett.no'

ServerName:     'nav-appliance.uninett.no'
DocumentRoot:   '/usr/share/nav/htdocs'

URI:            '/l2trace/'
Location:       '/'
Directory:      None
Filename:       '/usr/share/nav/htdocs/l2trace'
PathInfo:       '/'

Phase:          'PythonHandler'
Handler:        'django.core.handlers.modpython'

Traceback (most recent call last):

  File "/usr/lib/python2.6/dist-packages/mod_python/importer.py", line 1537, 
in HandlerDispatch
    default=default_handler, arg=req, silent=hlist.silent)

  File "/usr/lib/python2.6/dist-packages/mod_python/importer.py", line 1229, 
in _process_target
    result = _execute_target(config, req, object, arg)

  File "/usr/lib/python2.6/dist-packages/mod_python/importer.py", line 1128, 
in _execute_target
    result = object(arg)

  File "/usr/lib/pymodules/python2.6/django/core/handlers/modpython.py", 
line 228, in handler
    return ModPythonHandler()(req)

  File "/usr/lib/pymodules/python2.6/django/core/handlers/modpython.py", 
line 208, in __call__
    signals.request_finished.send(sender=self.__class__)

  File "/usr/lib/pymodules/python2.6/django/dispatch/dispatcher.py", line 
162, in send
    response = receiver(signal=self, sender=sender, **named)

  File "/usr/lib/pymodules/python2.6/django/db/__init__.py", line 84, in 
close_connection
    conn.close()

  File "/usr/lib/pymodules/python2.6/django/db/backends/__init__.py", line 
70, in close
    self.connection.close()

InterfaceError: connection already closed




&lt;/pre&gt;</description>
    <dc:creator>Ted</dc:creator>
    <dc:date>2013-05-07T13:23:06</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.network.nav.user/1141">
    <title>Bruk av NAV og uheldige konsekvenser for Cisco-utstyr</title>
    <link>http://comments.gmane.org/gmane.network.nav.user/1141</link>
    <description>&lt;pre&gt;Hei,

Takk for et glitrende program! Jeg har testkjørt dette hos oss i et halvårs tid, men sliter med et alvorlig og et mindre alvorlig problem:

1: Cisco ASA. Vi bruker denne serien ganske mye og i de fleste tilfeller fungerer NAV bra. Mot bokser som har 10-30 VLAN ser det ut til å gå som det skal. På bokser med mange VLAN (128+) får vi derimot en feil på SNMP-tasken hvert kvarter:

2013-05-02T11:27:18.100301+02:00 XXX &amp;lt;164&amp;gt;May 02 2013 11:27:18: %ASA-4-711004: Task ran for 150 msec, Process = snmp, PC = 8c4b7c8, Call stack =
2013-05-02T11:27:18.100301+02:00 XXX &amp;lt;164&amp;gt;May 02 2013 11:27:18: %ASA-4-711004: Task ran for 150 msec, Process = snmp, PC = 8c4b7c8, Call stack =   0x08B70783  0x08B50B1D  0x08B4F87C  0x08063B63
2013-05-02T11:27:18.100311+02:00 XXX &amp;lt;164&amp;gt;May 02 2013 11:27:18: %ASA-4-711004: Task ran for 152 msec, Process = snmp, PC = 8b77990, Call stack =
2013-05-02T11:27:18.100311+02:00 XXX &amp;lt;164&amp;gt;May 02 2013 11:27:18: %ASA-4-711004: Task ran for 152 msec, Process = snmp, PC = 8b77990, Call stack =   0x08B77990  0x08B76699  0x08B734A9  0x08B75F48  0x08B50E0E  0x08B4F87C  0x08063B63
2013-05-02T11:27:23.113341+02:00 XXX &amp;lt;164&amp;gt;May 02 2013 11:27:23: %ASA-4-711004: Task ran for 150 msec, Process = snmp, PC = 8b7772e, Call stack =
2013-05-02T11:27:23.113417+02:00 XXX &amp;lt;164&amp;gt;May 02 2013 11:27:23: %ASA-4-711004: Task ran for 150 msec, Process = snmp, PC = 8b7772e, Call stack =   0x08B7772E  0x08B7645B  0x08B734A9  0x08B75F48  0x08B50E0E  0x08B4F87C  0x08063B63

Melding ASA-4-711004 gir beskjed om at en task er et "CPU Hog", noe som kan få alvorlige konsekvenser tradisjonelle ASA-bokser (pre-SMP). Når dette skjer, vil nodene i ASA-klyngen oppleve pakketap og vil nodene vil kunne miste kontakten med hverandre både på inn og utsiden. Det siste ser ut til å være avhengig av den øvrige CPU-belastningen i øyeblikket.

2013-05-02T11:27:28.147580+02:00 XXX &amp;lt;161&amp;gt;May 02 2013 11:27:28: %ASA-1-105005: (Secondary) Lost Failover communications with mate on interface YYY
2013-05-02T11:27:28.147628+02:00 XXX &amp;lt;161&amp;gt;May 02 2013 11:27:28: %ASA-1-105008: (Secondary) Testing Interface YYY
2013-05-02T11:27:28.349692+02:00 XXX &amp;lt;161&amp;gt;May 02 2013 11:27:28: %ASA-1-105009: (Secondary) Testing on interface YYY Passed
2013-05-02T11:27:33.263707+02:00 XXX &amp;lt;161&amp;gt;May 02 2013 11:27:33: %ASA-1-105005: (Secondary) Lost Failover communications with mate on interface outside
2013-05-02T11:27:33.416249+02:00 XXX &amp;lt;161&amp;gt;May 02 2013 11:27:33: %ASA-1-105008: (Secondary) Testing Interface outside
2013-05-02T11:27:33.726430+02:00 XXX &amp;lt;161&amp;gt;May 02 2013 11:27:33: %ASA-1-105009: (Secondary) Testing on interface outside Passed

Er dette et kjent problem? Mulig det er tilfeldig, men jeg fikk samme problem når jeg forsøkte noen SNMP bulk-transfers.

2: Cisco switcher. Her får vi en feilmelding fra samtlige switcher hvert kvarter. Meldingen er noe obskur:

"2013-05-01T00:04:36.711253+02:00 ZZZ &amp;lt;132&amp;gt;266532: 147851: May  1 00:04:36.638 MEST: %BIT-4-OUTOFRANGE: bit 0 is not in the expected range of 1 to 4094"

med hilsen,

&lt;/pre&gt;</description>
    <dc:creator>Inge Bjørnvall Arnesen</dc:creator>
    <dc:date>2013-05-02T12:42:03</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.network.nav.user/1139">
    <title>Announcement: NAV 3.14.1592 released</title>
    <link>http://comments.gmane.org/gmane.network.nav.user/1139</link>
    <description>&lt;pre&gt;NAV 3.14.1592, another maintenance release of the endless NAV 3.14
series is now available for download at Launchpad:
https://launchpad.net/nav/3.14/3.14.1592

This release changes some aspects of how Cricket is configured to
collect traffic statistics, so we have added a couple of important
upgrade notes:

  * The Cricket trees `switch-ports` and `router-interfaces` have been
    consolidated into a single `ports` tree, where all physical ports' traffic
    stats now also are collected. After running the usual `syncdb.py` command,
    you should run `mcc.py` once manually (as the navcron user) to ensure the
    Cricket config tree is updated right away.

    When everything is up and running again, you can optionally delete the
    `switch-ports` and `router-interfaces` directories from your
    `cricket-config` directory, as they are no longer used by NAV.

  * NAV now supplies its own `subtree-sets` configuration to Cricket. If you
    have made manual changes to your Cricket collection setup and/or this
    file, you may need to update your setup accordingly.

This release fixes the following reported issues:

  * LP#1165193 (Prefix Matrix Doesn't Handle HSRP)
  * LP#1165206 (ARP Entries on HSRP Subnets are Double Counted)
  * LP#1169553 (Consolidate switch-ports, router-interfaces and physical port
                traffic statistics in Cricket)
  * LP#1169837 (servicemon debug logs no matter what the log level is set to)
  * LP#1169872 (VRRP/HSRP plugin is not enabled by default)
  * LP#1169986 (ipdevpoll spins in its tracks and doesn't reconnect on database
                connection loss)
  * LP#1170221 (Subnet matrix crashes with AttributeError when only one scope
                prefix is registered)
  * LP#1170291 (Mac search + DNS crashes with AttributeError in NAV 3.14.159)
  * LP#1170329 (eventengine dies on loss of database connection)
  * LP#1170374 (Alertengine dies on loss of database connection)
  * LP#1170634 (The SMS daemon dies when database connection is lost)
  * LP#1172204 (Device history crashes with NameError on invalid date input)


Please report bugs at https://launchpad.net/nav/+filebug


Binary packages for Debian will be made available as soon as possible.
The Debian package is maintained by Morten Werner Forsbring, on
commission from UNINETT.


Happy NAVing everyone!

&lt;/pre&gt;</description>
    <dc:creator>Morten Brekkevold</dc:creator>
    <dc:date>2013-04-25T07:48:20</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.network.nav.user/1138">
    <title>Announcement: NAV 3.14.1592 released</title>
    <link>http://comments.gmane.org/gmane.network.nav.user/1138</link>
    <description>&lt;pre&gt;NAV 3.14.159, another release of the endless NAV 3.14 series is now
available for download at Launchpad:
https://launchpad.net/nav/3.14/3.14.159

The release fixes the following reported issues:

  * LP#1155128 (IndexError crash in Machine Tracker)
  * LP#1158214 (mcc.py does debug logging even when configured not to)
  * LP#1160921 (Geomap won't load map data over HTTPS in Chrome)
  * LP#1161108 (Room bulk import format doesn't include geo position)
  * LP#1163256 (snmptrapd crashes with "interrupted system call" error)
  * LP#1164582 (netmap bails on fetching network graph if interface.speed
                missing)
  * LP#1165017 (Adding 0.0.0.0/0 as excepted range causes netbiostracker to
                hang)

Please report bugs at https://launchpad.net/nav/+filebug


Binary packages for Debian will be made available as soon as possible.
The Debian package is maintained by Morten Werner Forsbring, on
commission from UNINETT.


Some people have experienced that the Debian package upgrade seems to
freeze. While the NAV backend services are shut down during an upgrade,
parts of NAV are still running inside Apache, and may hold on to
database locks. This may prevent the package upgrade from updating the
database schema - in such a case, restarting Apache from another
terminal should unfreeze the upgrade.


Happy NAVing everyone!


&lt;/pre&gt;</description>
    <dc:creator>Morten Brekkevold</dc:creator>
    <dc:date>2013-04-25T07:43:46</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.network.nav.user/1134">
    <title>Announcement: NAV 3.14.159 released</title>
    <link>http://comments.gmane.org/gmane.network.nav.user/1134</link>
    <description>&lt;pre&gt;NAV 3.14.159, another release of the endless NAV 3.14 series is now
available for download at Launchpad:
https://launchpad.net/nav/3.14/3.14.159

The release fixes the following reported issues:

  * LP#1155128 (IndexError crash in Machine Tracker)
  * LP#1158214 (mcc.py does debug logging even when configured not to)
  * LP#1160921 (Geomap won't load map data over HTTPS in Chrome)
  * LP#1161108 (Room bulk import format doesn't include geo position)
  * LP#1163256 (snmptrapd crashes with "interrupted system call" error)
  * LP#1164582 (netmap bails on fetching network graph if interface.speed
                missing)
  * LP#1165017 (Adding 0.0.0.0/0 as excepted range causes netbiostracker to
                hang)

Please report bugs at https://launchpad.net/nav/+filebug


Binary packages for Debian will be made available as soon as possible.
The Debian package is maintained by Morten Werner Forsbring, on
commission from UNINETT.


Some people have experienced that the Debian package upgrade seems to
freeze. While the NAV backend services are shut down during an upgrade,
parts of NAV are still running inside Apache, and may hold on to
database locks. This may prevent the package upgrade from updating the
database schema - in such a case, restarting Apache from another
terminal should unfreeze the upgrade.


Happy NAVing everyone!


&lt;/pre&gt;</description>
    <dc:creator>John-Magne Bredal</dc:creator>
    <dc:date>2013-04-11T07:28:20</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.network.nav.user/1128">
    <title>rsyslog, logger.conf and cisco devices</title>
    <link>http://comments.gmane.org/gmane.network.nav.user/1128</link>
    <description>&lt;pre&gt;I am running NAV ver. 3.14.15 (downloaded the virtual appliance and did an 
upgrade) but I am unable to get the syslog part to work (as well as cricket 
but that I am still researching) 

The original logger.conf points to /var/lib/nav/log/cisco.log - shouldn't that 
point to /var/log/nav? Anyway I changed that to point to /var/log/messages

I also had to enable in rsyslog.conf to receive UDP messages by uncommenting 
the lines $ModLoad imudp and $UDPServerRun 514.

When I do tail -f /var/log/messages I can see that the Cisco switches are 
sending messages. If I try to pull up the syslog messages through NAV however 
it tells me that there are no messages. 

Any pointers would be greatly appreciated. 


&lt;/pre&gt;</description>
    <dc:creator>Ted</dc:creator>
    <dc:date>2013-04-09T15:26:24</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.network.nav.user/1124">
    <title>Single device configurations</title>
    <link>http://comments.gmane.org/gmane.network.nav.user/1124</link>
    <description>&lt;pre&gt;Guys, is it possible to configure NAV to:

1 - ignore a single or a range of devices to be ignored from the polling
process? I think this will be possible when we put it in maintenance mode.
I'm right?

2 - apply per device ipdevpool's plugins intervals? According to docs, its
is possible to set intervals for all devices but I hope that exists some
other "hide" config to do that :)

&lt;/pre&gt;</description>
    <dc:creator>Bruno Galindro da Costa</dc:creator>
    <dc:date>2013-04-03T20:59:36</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.network.nav.user/1113">
    <title>Device Uplink</title>
    <link>http://comments.gmane.org/gmane.network.nav.user/1113</link>
    <description>&lt;pre&gt;What is the process that discover device's uplink?
Is /usr/local/nav/bin/navtopology? Is it possible to put it's execution in
debug mode?

I've some devices that not have uplink information after added. Whitout
this information, netmap can't draw it.

&lt;/pre&gt;</description>
    <dc:creator>Bruno Galindro da Costa</dc:creator>
    <dc:date>2013-03-27T14:00:13</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.network.nav.user/1110">
    <title>Unmanaged devices</title>
    <link>http://comments.gmane.org/gmane.network.nav.user/1110</link>
    <description>&lt;pre&gt;Hi!

    Question 1: Is it possible to change the device type? I know this
information is gathered from device, but when the device has no snmp
support, but only an ip address (like a printer), I need to specify it's
type in the system to built more detailed and consistent reports.

    Question 2: How can I insert an unmanaged switch or hub in NAV? I need
this because I want to know where this kind of devices are inserted in our
network to planning a future replacement of it.

    Question 3: Where I can change the netmap device icons? The device icon
is related to type or category? Would be great if it where possible to
change the device's icon to reflect it's model.
Hi!

&lt;/pre&gt;</description>
    <dc:creator>Bruno Galindro da Costa</dc:creator>
    <dc:date>2013-03-21T17:54:11</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.network.nav.user/1109">
    <title>Netmap - link colors</title>
    <link>http://comments.gmane.org/gmane.network.nav.user/1109</link>
    <description>&lt;pre&gt;Hi!

    Which is the premisse for netmap colorize the link between two devices?
What is the meaning of grey's link color?
    I'm wondering this because from yesterday to today, the links between
my devices changed from green to grey...

&lt;/pre&gt;</description>
    <dc:creator>Bruno Galindro da Costa</dc:creator>
    <dc:date>2013-03-21T17:37:41</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.network.nav.user/1106">
    <title>Announcement: NAV 3.14.15 released</title>
    <link>http://comments.gmane.org/gmane.network.nav.user/1106</link>
    <description>&lt;pre&gt;NAV 3.14.15, the first maintenance release of the NAV 3.14 series is now
available for download at Launchpad:
https://launchpad.net/nav/3.14/3.14.15

The 3.14.15 fixes the following reported issues:

  * LP#1152173 (Deleting rrdviewer.conf causes crash when attempting to view
                graphs from ipdevinfo)
  * LP#1152599 (VLANs periodically lose one or more prefixes)
  * LP#1154626 (Threshold bulk config UI unresponsive, with javascript console
                error)
  * LP#1155096 (Filtering by category in syslog analyzer doesn't work)
  * LP#1156647 (Topology is not cleared when ports are shut down)
  * LP#1157154 (Netmap stopped working in NAV 3.14.1)
  * LP#1157594 (netbiostracker crashes when a netbios host reports an empty mac
                address)
  * LP#1157658 (Failing ipdevpoll plugin should be identified in log messages at
                the ERROR level)

Please report bugs at https://launchpad.net/nav/+filebug :-)


Binary packages for Debian will be made available as soon as possible.
The Debian package is maintained by Morten Werner Forsbring, on
commission from UNINETT.


Some people have experienced that the Debian package upgrade seems to
freeze. While the NAV backend services are shut down during an upgrade,
parts of NAV are still running inside Apache, and may hold on to
database locks. This may prevent the package upgrade from updating the
database schema - in such a case, restarting Apache from another
terminal should unfreeze the upgrade.


Happy NAVing everyone!

&lt;/pre&gt;</description>
    <dc:creator>Morten Brekkevold</dc:creator>
    <dc:date>2013-03-21T09:19:39</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.network.nav.user/1105">
    <title>Netmap broken in 3.14.1</title>
    <link>http://comments.gmane.org/gmane.network.nav.user/1105</link>
    <description>&lt;pre&gt;Just updated the Debian package to from 3.13.1 to 3.14.1 and netmap 
appears to no longer work, just the spinning wheel.
Anyone else experiencing this? Haven't looked much further into it yet, 
but save myself some time if others have noticed the problem and have a 
solution.

Also, (again, I haven't had time to look closely at it yet) is there a 
way to configure the geomap to plot only physical layer-2 connections? 
It is plotting vl1 connections to root hub along with the physical 
connections.

Thanks for any assistance in advance, and I'll report if I find anything.

&lt;/pre&gt;</description>
    <dc:creator>Corey Thompson</dc:creator>
    <dc:date>2013-03-20T16:06:24</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.network.nav.user/1100">
    <title>Dlink DGS-3100 / DGS-3120 support</title>
    <link>http://comments.gmane.org/gmane.network.nav.user/1100</link>
    <description>&lt;pre&gt;Hi!

   Is Dlink DGS-3100 / DGS-3120 supported by NAV? If yes, why these errors
are ocurring with ipdevpoll module?

2013-03-19 19:52:09,257 [WARNING plugins.typeoid.typeoid] [inventory
10.10.25.110] Netbox has changed type from unknown to unknown (sysObjectID
1.3.6.1.4.1.171.10.94.3)
2013-03-19 19:52:30,376 [ERROR jobs.jobhandler] [inventory 10.10.25.110
Job 'inventory' for 10.10.25.110 aborted: ('Job aborted due to plugin
failure', TimeoutError('',))
2013-03-19 19:54:49,507 [ERROR jobs.jobhandler] [linkcheck 10.10.25.110]
Job 'linkcheck' for 10.10.25.110 aborted: ('Job aborted due to plugin
failure', TimeoutError('',))

   Is there a way to put ipdevpoll module in debug mode to see what is
happening with more details?

   The device is correctly configured with snmpv2c. See it:

# snmpwalk -v2c -c public 10.10.25.110 .1.3.6.1.2.1.2.2.1.2.40
iso.3.6.1.2.1.2.2.1.2.40 = STRING: "Ethernet Interface"

   That command was executed from the same VM that NAV is installed.


I have another two monitored devices: Dlink DES-3028P and Dlink DES-3526.
These two are correctly functional in NAV and those snmp configurations are
set in the same way of Dlink DGS-3100.



&lt;/pre&gt;</description>
    <dc:creator>Bruno Galindro da Costa</dc:creator>
    <dc:date>2013-03-19T19:24:56</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.network.nav.user/1098">
    <title>Announcement: NAV 3.14.1 released</title>
    <link>http://comments.gmane.org/gmane.network.nav.user/1098</link>
    <description>&lt;pre&gt;Just a week shy of Pi Day, we bring you a new NAV feature release: NAV
3.14.1 is now available for download at Launchpad:
https://launchpad.net/nav/3.14/3.14.1

The 3.14.1 release adds the following user-visible features and
improvements:

  * NAV now fully supports SNMP communication over IPv6. Please see the
    release notes for more information.

  * Most of the service monitor plugins now support IPv6.

  * NAV documentation is slowly moving out of the wiki and into Sphinx. Now,
    every NAV installation includes a link from the front page to the
    browseable, locally installed documentation.

  * The Toolbox can now be collapsed into an icon/title-based list if the tool
    descriptions aren't needed or wanted.

  * The ordering of tools in the Toolbox can now be customized individually by
    each user.

  * The status page and portadmin have been adapted to work well on small
    screens/mobile devices.

  * Portadmin now supports editing trunks. 

  * Portadmin includes a new feature to enable trunking of predefined voice
    VLANs on access ports, for SIP phones that support 802.1Q trunking

And contains fixes for these reported issues:

  * LP#483534  (Subnet Matrix: Display description of prefix in dropdown)
  * LP#736818  (Reorganise toolbox webpage)
  * LP#965144  (Front page needs link to Status page)
  * LP#1060976 (Portadmin imports nav.Snmp.pysnmp_se directly)
  * LP#1062206 (Camlogger should log entries from non-access ports if connected
                device is not a networking device)
  * LP#1062317 (Support SNMP over IPv6)
  * LP#1062318 (Servicemon plugins should be reviewed for IPv6 support)
  * LP#1069770 (Want a mobile version of the status page)
  * LP#1069771 (Want a mobile version of port admin)
  * LP#1092154 (Portadmin crash when unicode characters in ifalias)
  * LP#1092156 (Portadmin crash when it cannot find a netbox by name or ip,-
                and interface by id)
  * LP#1092551 (Bug in threshold, crashes when searching for netboxes
  * LP#1103376 (portadmin should highlight changes in a better way)
  * LP#1134390 (Machine tracker crashes when inputting non-ASCII characters in
                search)
  * LP#1134392 (Invalid IP search patterns cause abnormal Machine Tracker
                behavior)
  * LP#1135699 (arnold fails to open quarantined ports on cisco devices)
  * LP#1137799 (cricket runs eval on config that contains curly braces)
  * LP#1143962 (Device history search for location crashes)
  * LP#1146602 (Maintengine TypeError crash)
  * LP#1146604 (arnold lacks links to relevant information)


Please report bugs at https://launchpad.net/nav/+filebug :-)


Binary packages for Debian will be made available as soon as possible.
The Debian package is maintained by Morten Werner Forsbring, on
commission from UNINETT.

Happy NAVing everyone!

&lt;/pre&gt;</description>
    <dc:creator>Morten Brekkevold</dc:creator>
    <dc:date>2013-03-07T09:16:46</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.network.nav.user/1095">
    <title>maintengine.py has trouble with TypeError</title>
    <link>http://comments.gmane.org/gmane.network.nav.user/1095</link>
    <description>&lt;pre&gt;Sometime this last week our maintengine has stopped working:


/#/usr/local/nav/bin/maintengine.py
Traceback (most recent call last):
  File "/usr/local/nav/bin/maintengine.py", line 45, in &amp;lt;module&amp;gt;
    main()
  File "/usr/local/nav/bin/maintengine.py", line 39, in main
    check_devices_on_maintenance()
  File "/usr/local/nav/lib/python/nav/maintengine.py", line 479, in check_devices_on_maintenance
    send_event(events, maxdate_boxes, boxes_off_maintenance)
  File "/usr/local/nav/lib/python/nav/maintengine.py", line 343, in send_event
    str(curr_event['maint_end'])))
TypeError: not all arguments converted during string formatting


NAV 3.13.0

I guess something has gone wrong in the database. Where to look?


--Ingeborg
&lt;/pre&gt;</description>
    <dc:creator>Ingeborg Hellemo</dc:creator>
    <dc:date>2013-03-04T12:42:45</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.network.nav.user/1092">
    <title>Announcement: NAV 3.13.1 final released</title>
    <link>http://comments.gmane.org/gmane.network.nav.user/1092</link>
    <description>&lt;pre&gt;The first maintenance release of NAV 3.13 is now available for download
at Launchpad: https://launchpad.net/nav/3.13/3.13.1

The 3.13.1 updates the release notes with some information about the
netbiostracker feature and the new alert message template system, and
fixes the following reported issues:

  * LP#1126340 (arnold t1000 crashes on pursuit)
  * LP#1126341 (arnold autoenable crashes on missing interface)
  * LP#1128868 (Arnold does not display a candidate for manual block)
  * LP#1130093 (NetworkX 1.6 throws exception in eventengine)
  * LP#1130103 (Typo in ReportListTemplate.tmpl)

Please report bugs at https://launchpad.net/nav/+filebug :-)

Binary packages for Debian will be made available as soon as possible.
The Debian package is maintained by Morten Werner Forsbring, on
commission from UNINETT. Although he did not post a notice to this list,
the 3.13.0 packages have been available at pkg-nav.alioth.debian.org
since last week.

Happy NAVing, everyone!

&lt;/pre&gt;</description>
    <dc:creator>Morten Brekkevold</dc:creator>
    <dc:date>2013-02-21T11:40:42</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.network.nav.user/1085">
    <title>Warning from eventengine - topology problem</title>
    <link>http://comments.gmane.org/gmane.network.nav.user/1085</link>
    <description>&lt;pre&gt;NAV 3.13.0

Eventengine logs a lot of topology problems of two kinds. 

One regarding the NAV-server itself:

2013-02-18 11:23:37,173 [WARNING nav.eventengine.topology] 
NAVServer('129.242.5.182') topology problem: router ma-gsw3.infra is up, but 
not in VLAN graph for &amp;lt;Prefix: 129.242.5.0/24 (vlan 103 (nett,srv,5-nettet))&amp;gt;. 
Defaulting to 'reachable' status.

The other kind regarding some (but not all) random devices: 

2013-02-18 11:23:37,740 [WARNING nav.eventengine.topology] nfh-b100-nc.prn 
topology problem: router nfh-gsw.infra is up, but not in VLAN graph for 
&amp;lt;Prefix: 10.253.19.0/24 (vlan 600 (uit,prn))&amp;gt;. Defaulting to 'reachable' 
status.


Is there anything we can do to in our setup to eliminate the warnings (except 
changing the debug level...)?


--Ingeborg
&lt;/pre&gt;</description>
    <dc:creator>Ingeborg Hellemo</dc:creator>
    <dc:date>2013-02-18T10:31:08</dc:date>
  </item>
  <textinput rdf:about="http://search.gmane.org/?group=$group=gmane.network.nav.user">
    <title>Search Engine</title>
    <description>Search the mailing list at Gmane</description>
    <name>query</name>
    <link>http://search.gmane.org/?group=$group=gmane.network.nav.user</link>
  </textinput>
</rdf:RDF>
