[BUG] ipdevpoll fails to start after upgrade to 5.8.0

[Zotan]

Describe the bug

I have Nav installed on Debian Buster using the debian packages and after upgrade to 5.8.0 ipdevpoll fails to start. The end of the back trace is:

  File "/opt/venvs/nav/lib/python3.7/site-packages/nav/ipdevpoll/snmp/common.py", line 213, in factory
    kwargs_out["version"] = int(kwargs_out["version"])
builtins.ValueError: invalid literal for int() with base 10: '2c'

It appears to reject 2c as a valid SNMP version

To Reproduce

1. With prexisting Nav install, upgrade to version 5.8.0, using the debian packages
2. Notice that web interface is no longer running and that ipdevpoll has not started and will not start.

Expected behaviour

After upgrade, notice that version has changed to 5.8.0 in the web interface

Tracebacks

2023-11-27 13:47:10,319 [CRITICAL twisted] Unhandled failure in data reload loop, stopping ipdevpoll
Traceback (most recent call last):
  File "/opt/venvs/nav/lib/python3.7/site-packages/twisted/internet/base.py", line 1292, in mainLoop
    self.runUntilCurrent()
  File "/opt/venvs/nav/lib/python3.7/site-packages/twisted/internet/base.py", line 886, in runUntilCurrent
    f(*a, **kw)
  File "/opt/venvs/nav/lib/python3.7/site-packages/twisted/internet/defer.py", line 501, in errback
    self._startRunCallbacks(fail)
  File "/opt/venvs/nav/lib/python3.7/site-packages/twisted/internet/defer.py", line 568, in _startRunCallbacks
    self._runCallbacks()
--- <exception caught here> ---
  File "/opt/venvs/nav/lib/python3.7/site-packages/twisted/internet/defer.py", line 654, in _runCallbacks
    current.result = callback(current.result, *args, **kw)
  File "/opt/venvs/nav/lib/python3.7/site-packages/nav/ipdevpoll/schedule.py", line 445, in _handle_reload_failures
    failure.trap(db.ResetDBConnectionError)
  File "/opt/venvs/nav/lib/python3.7/site-packages/twisted/python/failure.py", line 460, in trap
    self.raiseException()
  File "/opt/venvs/nav/lib/python3.7/site-packages/twisted/python/failure.py", line 488, in raiseException
    raise self.value.with_traceback(self.tb)
  File "/opt/venvs/nav/lib/python3.7/site-packages/twisted/python/threadpool.py", line 250, in inContext
    result = inContext.theWork()
  File "/opt/venvs/nav/lib/python3.7/site-packages/twisted/python/threadpool.py", line 266, in <lambda>
    inContext.theWork = lambda: context.call(ctx, func, *args, **kw)
  File "/opt/venvs/nav/lib/python3.7/site-packages/twisted/python/context.py", line 122, in callWithContext
    return self.currentContext().callWithContext(ctx, func, *args, **kw)
  File "/opt/venvs/nav/lib/python3.7/site-packages/twisted/python/context.py", line 85, in callWithContext
    return func(*args,**kw)
  File "/opt/venvs/nav/lib/python3.7/site-packages/nav/ipdevpoll/db.py", line 108, in _reset
    return func(*args, **kwargs)
  File "/opt/venvs/nav/lib/python3.7/site-packages/nav/ipdevpoll/dataloader.py", line 119, in load_all_s
    netbox_list = storage.shadowify_queryset(queryset)
  File "/opt/venvs/nav/lib/python3.7/site-packages/nav/ipdevpoll/storage.py", line 574, in shadowify_queryset
    new_list = [shadowify(obj) for obj in result]
  File "/opt/venvs/nav/lib/python3.7/site-packages/nav/ipdevpoll/storage.py", line 574, in <listcomp>
    new_list = [shadowify(obj) for obj in result]
  File "/opt/venvs/nav/lib/python3.7/site-packages/nav/ipdevpoll/storage.py", line 567, in shadowify
    model = new_cls(model)
  File "/opt/venvs/nav/lib/python3.7/site-packages/nav/ipdevpoll/shadows/netbox.py", line 42, in __init__
    self.snmp_parameters = SNMPParameters.factory(obj)
  File "/opt/venvs/nav/lib/python3.7/site-packages/nav/ipdevpoll/snmp/common.py", line 213, in factory
    kwargs_out["version"] = int(kwargs_out["version"])
builtins.ValueError: invalid literal for int() with base 10: '2c'

Environment (please complete the following information):

• OS on the NAV server: Debian 10/Buster
• NAV version installed: 5.8.0
• Method of installation: Debian package

[lunkwill42]

It appears to reject 2c as a valid SNMP version

Thanks for your report!

You are probably correct. SNMP versions are stored as strings in management profiles, but it seems there is some confusion about whether version 2 is stored as 2 or 2c - apparently both have been seen in the wild.

This is a bad regression, so we'll get on it ASAP.

[lunkwill42]

@Zotan Can you confirm that your profiles actually use the string "2c"? I have checked 32 separate NAV installations, and none of them actually use anything other than the integer 2 or the string "2" in their profiles...

If you can connect to your NAV's PostgreSQL database (typically using sudo -u postgres nav on Debian), what is the output of the following SQL statement?

SELECT DISTINCT ON (version)
    configuration::jsonb -> 'version'::text AS version
FROM
    management_profile
WHERE
    protocol = 1;

[Zotan]

@lunkwill42 It looks like I have it once.

psql (11.22 (Debian 11.22-0+deb10u1))
Type "help" for help.

nav=# SELECT DISTINCT ON (version)
nav-#     configuration::jsonb -> 'version'::text AS version
nav-# FROM
nav-#     management_profile
nav-# WHERE
nav-#     protocol = 1;
 version 
---------
 "2c"
(1 row)

nav=# 

[lunkwill42]

"2c"

Strangeness. Only thing I can think of is that NAV changed this at some point, but I can't remember when it might have been. There's a fix in the pipeline for review now, at #2768 - but maybe you would be able to work around it by editing your SNMP v2c profiles by changing them to version 1 and then back to 2?

[lunkwill42]

So, this is fixed by #2768 and will be out in a release soon.

I think I also have found the source of your problem:

nav/python/nav/models/sql/changes/sc.05.00.0011.sql

Line 9 in 2776ccb

'{"version": "2c", "community": "public"}'::JSONB

This problem will be exclusive to those whose first installed NAV version was 5.0 or later.

The above-linked migration script installs an example SNMP v2c profile for the public community if no management profiles were created while migrating from an older NAV version. The script explicitly inserts a version value of v2c, and anyone using this example profile unchanged in production will be hit by this bug in 5.8.0.

SeedDB will never store a value of v2c when editing or adding your own profiles. I have tested the potential workaround mentioned above, and it works. All you need to do to workaround the problem is to open the faulty profile in SeedDB and save it without changes. I.e. at least you can get this working for you before the 5.8.1 release is available, @Zotan .

[Zotan]

@lunkwill42 Thanks for the 5.8.1 release, ipdevpoll is back to normal. FYI with 5.8.0 the web interface was not accessible for me, with an exception trace in the apache log. So I couldn't use your workaround. Should I post that trace somewhere? Or should I just move on as the problem no longer exists?

[Zotan]

Ah sorry, just seen that this a known issue in the 5.8.1 release notes about ciscoconfparse, so already fixed.