Nav-users Juni 2020

nav-users@lister.sikt.no

3 participants
5 discussions

Status Check on Dell N2048P (PoE)
by Vinsonnaud Ludovic 19 Feb '24

19 Feb '24

Hello, I've check my logs on ipdevpoll and I found this : 2019-01-28 17:37:28,698 [ERROR jobs.jobhandler] [statuscheck PAL-SW-R1-13.res.iogs] Caught exception during save. Last manager = DefaultManager(<class 'nav.ipdevpoll.shadows.POEPort'>, 'ContainerRepository'(...)). Last model = <class 'nav.ipdevpoll.shadows.POEPort'> Traceback (most recent call last): File "/usr/lib/python2.7/dist-packages/nav/ipdevpoll/jobs.py", line 442, in _perform_save manager.save() File "/usr/lib/python2.7/dist-packages/nav/ipdevpoll/storage.py", line 87, in save obj.save(self.containers) File "/usr/lib/python2.7/dist-packages/nav/ipdevpoll/storage.py", line 476, in save obj.save() File "/usr/lib/python2.7/dist-packages/django/db/models/base.py", line 589, in save force_update=force_update, update_fields=update_fields) File "/usr/lib/python2.7/dist-packages/django/db/models/base.py", line 617, in save_base updated = self._save_table(raw, cls, force_insert, force_update, using, update_fields) File "/usr/lib/python2.7/dist-packages/django/db/models/base.py", line 698, in _save_table result = self._do_insert(cls._base_manager, using, fields, update_pk, raw) File "/usr/lib/python2.7/dist-packages/django/db/models/base.py", line 731, in _do_insert using=using, raw=raw) File "/usr/lib/python2.7/dist-packages/django/db/models/manager.py", line 92, in manager_method return getattr(self.get_queryset(), name)(*args, **kwargs) File "/usr/lib/python2.7/dist-packages/django/db/models/query.py", line 921, in _insert return query.get_compiler(using=using).execute_sql(return_id) File "/usr/lib/python2.7/dist-packages/django/db/models/sql/compiler.py", line 921, in execute_sql cursor.execute(sql, params) File "/usr/lib/python2.7/dist-packages/django/db/backends/utils.py", line 65, in execute return self.cursor.execute(sql, params) File "/usr/lib/python2.7/dist-packages/django/db/utils.py", line 94, in __exit__ six.reraise(dj_exc_type, dj_exc_value, traceback) File "/usr/lib/python2.7/dist-packages/django/db/backends/utils.py", line 65, in execute return self.cursor.execute(sql, params) IntegrityError: ERREUR: une valeur NULL viole la contrainte NOT NULL de la colonne « classification » DETAIL: La ligne en échec contient (599034, 49, 66, null, 34, t, 2, 4, null) 2019-01-28 17:37:28,701 [ERROR jobs.jobhandler] [statuscheck PAL-SW-R1-13.res.iogs] Job 'statuscheck' for PAL-SW-R1-13.res.iogs aborted: Job aborted due to save failure (cause=IntegrityError('ERREUR: une valeur NULL viole la contrainte NOT NULL de la colonne \xc2\xab classification \xc2\xbb\nDETAIL: La ligne en \xc3\xa9chec contient (599034, 49, 66, null, 34, t, 2, 4, null)\n',)) 2019-01-28 17:37:28,703 [INFO schedule.netboxjobscheduler] [statuscheck PAL-SW-R1-13.res.iogs] statuscheck for PAL-SW-R1-13.res.iogs failed in 0:00:14.603465. next run in 0:04:59.999955. It seems it doesn't like the PoE on my Dell N2048P because of a NULL value in "classification" column. Do you have an idea ? Regards -- Cordialement, IOGS Logo <https://www.institutoptique.fr> *Ludovic Vinsonnaud * - Ingénieur Réseau basé à Bordeaux, bureau F108 (IOA, Rue François Mitterrand, 33400 Talence) *Institut Optique Graduate School* 2 Avenue Augustin Fresnel - 91127 PALAISEAU Cedex Tel. +33 5 57 01 71 52 - Mob. +33 6 08 08 41 05

5 16

NAV with Cisco 3850
by Mischa Diehm 15 Sep '23

15 Sep '23

Hi, we have a 3850 Stack with 3x ES-C3850-48T-S and 5x WS-C3850-12X48U. When we try to PortAdmin and edit a Port we get (see also attached Jpg): „IP device found but has no type“ Any ideas? Cheers, Mischa -- Mischa Diehm | Network Team (NINS) UniBasel | IT-Services (ITS) Klingebergstr. 70 | CH-4056 Basel Tel. +41 61 267 1574 | https://its.unibas.ch

4 4

NAV auth with LDAP and MS AD
by Ingeborg Hellemo 05 Jun '20

05 Jun '20

We have had our own local patch which authenticates via Radius, but the time has come to move in the direction of LDAP and MS AD. [ldap] enabled = yes server = dc10.ad.uit.no port = 636 encryption = ssl uid_attr = sAMAccountName basedn = ou=people,dc=uit,dc=no lookupmethod=direct suffix = @ad.uit.no debug = yes I get authentication to work with an existing account, but can not create a new account. The debug-log shows a strange ldap url during referral: It begins ok: ldap_url_parse_ext(ldaps://dc10.ad.uit.no:636) ... connect success But then: ldap_chase_v3referrals ldap_url_parse_ext(ldaps://uit.no/ou=people,dc=uit,dc=no) Where does the domain uit.no in the URL come from? Is there a config setting I have overlooked? This of course ends in Unable to chase referral "ldaps://uit.no/ou=people,dc=uit,dc=no" (-1: Can't contact LDAP server) (If I use "lookupmethod=search" the webpage throws an error and no account is created. If I use "lookupmethod=direct" the account is created, but without Name, because that was not found in the search - since it was sent to the wrong server) --Ingeborg -- Ingeborg Østrem Hellemo -- ingeborg.hellemo(a)uit.no Dep. of Information Technology --- Univ. of Tromsø

2 1

Issues with Nav docker container - logs, graph gaps and high postgres utilization
by Steve Kersley 03 Jun '20

03 Jun '20

Morning, TLDR: Gaps in graphs after Nav container running for a day or two. Nav container doesn't create logfiles. Nav postgres container has lots of postgres processes running, consuming ¾ of host CPU. Is this normal or bug (in container, or with my setup?) So, after killing my old Nav system with a series of conflicting upgrades, I decided to embrace the Docker approach, so that Nav (and other services) would be self-contained and not affected by upgrading components. All was initially well, but I'm starting to run into increasing graph gaps that I've not been able to resolve. If I stop and rebuild all of the containers with docker-compose, all seems well to start with, but after a while (few hours to a day or two) I start to get gaps and then it's downhill from there. The next issue I discovered while looking into the graph gaps is that there are no logs. Docker does mount a volume on /var/log/nav (from the dockerfile) but nothing ever gets created in it, meaning it's hard to look for warnings or errors. Is that expected behaviour, or is it something I got wrong when adapting the docker-compose file? The only logs I get from 'docker logs' show smsd being spawned and exiting every second: 2020-05-28 07:29:19,089 INFO spawned: 'smsd' with pid 28112 2020-05-28 07:29:20,092 INFO success: smsd entered RUNNING state, process has stayed up for > than 1 seconds (startsecs) 2020-05-28 07:29:20,560 INFO exited: smsd (exit status 1; not expected) 2020-05-28 07:29:21,563 INFO spawned: 'smsd' with pid 28116 2020-05-28 07:29:22,565 INFO success: smsd entered RUNNING state, process has stayed up for > than 1 seconds (startsecs) 2020-05-28 07:29:22,971 INFO exited: smsd (exit status 1; not expected) 2020-05-28 07:29:23,975 INFO spawned: 'smsd' with pid 28118 2020-05-28 07:29:24,977 INFO success: smsd entered RUNNING state, process has stayed up for > than 1 seconds (startsecs) 2020-05-28 07:29:25,355 INFO exited: smsd (exit status 1; not expected) (looking into this, appears to be exiting because python-gammu is not configured in the container, but is unlikely to be connected to the issue) I did increase UDP receive buffers on the host, which I first thought had solved the issue, but the improvement was a side effect of restarting all of the containers and reverted to gaps later. Nav's seeddb has 65 devices. Almost all just switches, with a handful of vmware hosts. The job durations are peculiar too - the 1minstats job for instance, on some switches takes a couple of seconds to run. On others, nearly a minute (or often several minutes on one in particular), but whether that's the cause or a symptom I don't know. It looks as though the postgres database used by Nav is what's eating resources and presumably causing the graph gaps. The docker host typically has a load average of 9-12. Looking at the processes, there are typically at least 10 postgres processes running in the NavDB container, continually using 20-30% of CPU for each process. This does not seem normal to me? I also gave that container more shared memory, as it was logging occasional errors about not being able to allocate enough. Again no change - worse if anything. The docker host is running as a VM as an in-production 'test' - in the fullness of time (when I'm not remote working), I'll likely move the containers onto a bare metal host. Docker host has 4 cores and 8Gb allocated, and is not hitting swap, but I can increase both. The vmware host it runs on has plenty of CPU and RAM with not a massive amount running on it, and the docker host is running from an array of SSDs. Besides Nav and NavDB containers, it's running containers for Icinga, and the Icinga backend mysql database; a dedicated shared graphite container accessed by both Icinga and Nav; Grafana as a dashboard for both; and nginx as a web proxy for all services. (Previously these services were all running fine alongside each other on a physical host of similar specification, until conflicting dependencies broke things). Does anyone have any thoughts? Entries from my docker-compose.yml: nav: container_name: nav build: context: /docker/build/nav args: NAV_VERSION: 5.0.5 ports: - "8002:80" - "162:162/udp" volumes: - /docker/nav/storage/roomimages:/var/lib/nav/uploads/images/rooms depends_on: - navdb environment: - PGHOST=navdb - PGDATABASE=nav - PGUSER=nav - PGPASSWORD=Password - PGPORT=5432 - CARBONHOST=graphite - CARBONPORT=2003 - GRAPHITEWEB=http://graphite/ - NOINITDB=0 env_file: - /docker/build/nav/nav-variables.env restart: always navdb: image: "postgres:12" container_name: navdb volumes: - /docker/navdb/storage/postgresql:/var/lib/postgresql/data environment: - POSTGRES_PASSWORD=Password - POSTGRES_USER=nav - POSTGRES_DB=nav restart: always shm_size: '256mb' Steve.

2 3

Monitor Paloalto equipment
by Edgar Matias 03 Jun '20

03 Jun '20

Hello NAV community, I recently added a Paloalto firewall to the NAV to be monitored. This is the gateway for some vlan. NAV lists all interfaces, but does not classify them as routing or switching ports. There are other things that are not recognized as power supply sensors, for example. I believe this is because the NAV does not have specific MIBs configured. Is there a way to import MIBs to this specific device, or a workaround ? Thanks in advance. Great tool ;) -- Edgar Matias Application Infrastructures Area Fundação para a Ciência e a Tecnologia Unidade FCCN – Computação Científica Nacional Av. do Brasil, 101, 1700-066 Lisboa, Portugal T: [+351] 218 440 100 | [+351] 900 000 000 www.fccn.pt

2 3

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Nav-users Juni 2020