Nav-dev

nav-dev@lister.sikt.no

96 discussions

Rewritten MySQL checker
by olemb＠cc.uit.no 28 Feb '07

28 Feb '07

Here's the first in a series of new service checkers for NAV: a rewritten MySQL checker. The old MySQL checker didn't work with protocol version 10. It also closed the connection too early, causing the server to shut it out after 12 attempts. Usage is the same as before. Since this is a complete rewrite, I've attached the full code instead of a patch. I hope this is OK. -- Ole Martin Bjoerndalen olemb(a)cc.uit.no

1 0

New sms-dispatcher for NAV
by a.l.prois＠usit.uio.no 19 Feb '07

19 Feb '07

Hello. I've written a python script working as a dispatcher for smsd in NAV. It's been made for UiOs smsgateway, but may be usefull to others allso. The dispatcher and the settings for smsd.conf can be found at : http://folk.uio.no/asbjorp/nav_dev/ This is my first python-script, so dont expect perfect code #:) -Asbj?rn- >From stein.magnus.jodal at uninett.no Mon Feb 19 16:47:56 2007 From: stein.magnus.jodal at uninett.no (Stein Magnus Jodal) Date: Mon Feb 19 16:48:02 2007 Subject: [Nav-dev] New sms-dispatcher for NAV In-Reply-To: <Pine.LNX.4.63-L.0702191101010.5364(a)klodrik.uio.no> References: <Pine.LNX.4.63-L.0702191101010.5364(a)klodrik.uio.no> Message-ID: <1171900076.22682.8.camel(a)myh.jodal.no> On Mon, 2007-02-19 at 11:11 +0100, Asbj?rn Pr?is wrote: > I've written a python script working as a dispatcher for smsd in NAV. It's > been made for UiOs smsgateway, but may be usefull to others allso. > > The dispatcher and the settings for smsd.conf can be found at : > http://folk.uio.no/asbjorp/nav_dev/ > > This is my first python-script, so dont expect perfect code #:) Hi, Asbj?rn! I've generalized your dispatcher a bit and committed it to trunk[1]. The smsd README and default config are also updated with regard to the new dispatcher. Thanks for your contribution! [1] http://svn.itea.ntnu.no/repos/nav/navme/trunk/subsystem/smsd/ -- Stein Magnus Jodal UNINETT

1 0

OidTester dupeMap
by morten.brekkevold＠uninett.no 23 Jan '07

23 Jan '07

Hi Kristian, I'm debugging some getDeviceData problems that occur when devices change type in NAV, where, among other things, OID testing sometimes does not run properly. Apparently, OID testing runs properly only every second time a device changes its type (this is what my tests show when using the refresh function and switching type several times in a row). When OID testing does not run properly, all the OIDTester logs is that OID testing is done, without having tested anything. I've found that the doTest method of the OIDTester exits early because all the OIDs are found in a MultiMap called dupeMap. What I would like to know, if you can remember, what exactly is the purpose of this dupeMap? Incidentally, the netbox refresh function of gDD suddenly stops working after an arbitrary number of refreshes and will not work again until after a gDD restart. gDD logs the refresh event and says it will start an immediate collection run for that box, but then proceeds to do nothing... -- mvh Morten Brekkevold UNINETT >From kreide at gmail.com Mon Jan 29 01:25:27 2007 From: kreide at gmail.com (Kristian Eide) Date: Mon Jan 29 10:25:32 2007 Subject: [Nav-dev] Re: OidTester dupeMap In-Reply-To: <45B5EBF8.7010602(a)uninett.no> References: <45B5EBF8.7010602(a)uninett.no> Message-ID: <b4c110fd0701290125i1668ea71we8fa4b812b335e7a(a)mail.gmail.com> > I've found that the doTest method of the OIDTester exits early because > all the OIDs are found in a MultiMap called dupeMap. > What I would like to know, if you can remember, what exactly is the > purpose of this dupeMap? Sorry for the late reply, but here goes: it is used to flag a combination of IP and OID as already tested. I added it because testing happens in parallel and a IP/OID combination can be tried both from testing a single OID with all IPs (netboxes) and a single IP with all OIDs. I remember I tried to be clever when implementing this map since I wanted it to have O(1) lookup cost, but I have no doubt that there are bugs in the implementation, especially since I did not write any tests for it, something which is a necessity for testing the corner cases of something like this. I cannot remember how entries are removed from it, but since this is going to be tricky with the current implementation I probably got it wrong back then (and this is probably the source of the problem). > Incidentally, the netbox refresh function of gDD suddenly stops working > after an arbitrary number of refreshes and will not work again until > after a gDD restart. gDD logs the refresh event and says it will start > an immediate collection run for that box, but then proceeds to do nothing... I will recommend that you add a proper test case to the queueing mechanism and I am sure you will find this (and probably a few more) bugs in short order. -- Kristian

1 0

[Patch] setVersion() for FtpChecker.py
by olemb＠cc.uit.no 02 Nov '06

02 Nov '06

Hi, Here's a small patch for FtpChecker. It gets the ServerIdent string from the banner and uses it as the version string. --- FtpChecker_orig.py Thu Nov 2 12:32:11 2006 +++ FtpChecker.py Thu Nov 2 13:08:38 2006 @@ -63,12 +63,20 @@ s = FTP(self.getTimeout()) ip, port = self.getAddress() output = s.connect(ip,port or 21) + + # Get server version from the banner. + version = '' + for line in s.welcome.split('\n'): + if line.startswith('220 '): + version = line[4:].strip() + self.setVersion(version) + args = self.getArgs() username = args.get('username','') password = args.get('password','') path = args.get('path','') output = s.login(username,password,path) - print output + if output[:3] == '230': return Event.UP,'code 230' else: -- Ole Martin Bjoerndalen olemb(a)cc.uit.no >From olemb at cc.uit.no Thu Nov 2 15:02:39 2006 From: olemb at cc.uit.no (Ole Martin Bjorndalen) Date: Thu Nov 2 15:02:58 2006 Subject: [Nav-dev] [PATCH] Small typo in abstractChecker.py Message-ID: <20061102140239.GA31233(a)cc.uit.no> --- abstractChecker_orig.py 2006-11-02 14:58:31.000000000 +0100 +++ abstractChecker.py 2006-11-02 14:59:25.000000000 +0100 @@ -226,7 +226,7 @@ if self._sysname: return self._sysname else: - return self.geIp() + return self.getIp() def setResponsetime(self,usage): """Sets the responsetime of this service. Is updated by self.run() """ self._usage = usage -- Ole Martin Bjoerndalen olemb(a)cc.uit.no >From morten.brekkevold at uninett.no Wed Nov 8 15:10:49 2006 From: morten.brekkevold at uninett.no (Morten Brekkevold) Date: Wed Nov 8 15:10:59 2006 Subject: [Nav-dev] [Patch] setVersion() for FtpChecker.py In-Reply-To: <20061102124220.GA30191(a)cc.uit.no> References: <20061102124220.GA30191(a)cc.uit.no> Message-ID: <4551E569.5080401(a)uninett.no> Ole Martin Bjorndalen wrote, On 02-11-2006 13:42: > Here's a small patch for FtpChecker. It gets the ServerIdent string > from the banner and uses it as the version string. Thanks for this, Ole Martin, and also the other one :) As soon as they're tested, I'll commit them. -- mvh Morten Brekkevold UNINETT >From andreas.knudsen at hiof.no Thu Nov 9 11:11:54 2006 From: andreas.knudsen at hiof.no (Andreas Knudsen) Date: Thu Nov 9 11:12:33 2006 Subject: [Nav-dev] Patch for dump.py Message-ID: <734A5B19-A57C-49AA-849B-8907A6F488CC(a)hiof.no> Hi! I've written a small patch for dump.py that provides support for dumping the patch and cabling tables. This is my first attempt at writing a patch for NAV, and hopefully it works as intended. -------------- neste del -------------- Et vedlegg som ikke var tekst, ble skilt ut... Navn : dump.py_patch Type : application/octet-stream Størrelse : 1486 bytes Beskrivelse: ikke tilgjengelig URL : http://mailman.itea.ntnu.no/mailman/private/nav-dev/attachments/20061109/ac… -------------- neste del -------------- -- Andreas Knudsen ?stfold University College >From olemb at cc.uit.no Mon Nov 20 13:07:23 2006 From: olemb at cc.uit.no (Ole Martin Bjorndalen) Date: Mon Nov 20 13:07:44 2006 Subject: [Nav-dev] [PATCH] Server version not escaped in servicemon Message-ID: <20061120120723.GA32345(a)cc.uit.no> The server version was not escaped before it was inserted into the database. This caused a syntax error when the server version for DNS contained a single quote. (BTW, nav.db.escape() should probably be called nav.db.quote() since it also quotes the string.) -- Ole Martin Bjoerndalen olemb(a)cc.uit.no

1 0

Re: Modules up and down
by kreide＠gmail.com 11 Okt '06

11 Okt '06

> code, adding more debug output (and cursing the logging system, which I > would like to replace with Log4j). What I've found is that when the Yes, if I had known better at the time I would have used log4j. It should not be that hard to do a bulk replace of all the calls though (or even easier, simply have my log system forward to log4j). > and a null value otherwise. But it appears that is also checks whether > the OID is "ready to be fetched"; i.e. it checks an internal OID > run-queue in the NetboxImpl instance, and if it's nextRun timestamp has > passed, the OID is returned - otherwise, null is returned. You are correct, this is the cause of the problem. > What seems to be happening is that, for some reason, one hour after a > normal collection run, another run is initiated (could this be a > moduleMon run?). This seems to trigger the regular set of Yes, this is the moduleMon run. > What I have yet to figure out is what this oid run-queue and "oid is > ready/not ready to be fetched" is good for? The idea of the run queue is that different OIDs can be collected at different intervals, however, the level of complexity due to this is unfortunately (perhaps too) high - gDD certainly is an ambitious project. This problem is caused by a simple bug, however. The ModuleMon for Cisco uses the CiscoModule plugin to note which modules are down, but to avoid this situation ModuleMon will not mark modules as down unless mmc.commit() is called. If you look in CiscoModule.java that method is called regardless of whether module info was collected or not. The solution is to only call this method if collection happened, e.g. you can check if catModModel is non-null. This of course assumes that the schedule for all the Cisco module OIDs is the same, but for now I think you should make that a requirement. -- Kristian >From morten.brekkevold at uninett.no Thu Oct 12 11:31:37 2006 From: morten.brekkevold at uninett.no (Morten Brekkevold) Date: Thu Oct 12 10:31:58 2006 Subject: [Nav-dev] Re: Modules up and down In-Reply-To: <b4c110fd0610111157n33f01970gd77e1cdddb889384(a)mail.gmail.com> References: <44C0D670.6050306(a)uninett.no> <451BCE52.4090903(a)uninett.no> <b4c110fd0610111157n33f01970gd77e1cdddb889384(a)mail.gmail.com> Message-ID: <452DFD69.2040402(a)uninett.no> Kristian Eide wrote, On 11-10-2006 20:57: > Yes, if I had known better at the time I would have used log4j. It > should not be that hard to do a bulk replace of all the calls though > (or even easier, simply have my log system forward to log4j). Although the latter sounds tempting, I would rather make sure I had a proper logger hierarchy based on class names. My primary need is to be able to change the logging levels for different parts of gDD (and the other Java applications), and filter out the irrelevant stuff, without having to resort to grep. >> What seems to be happening is that, for some reason, one hour after a >> normal collection run, another run is initiated (could this be a >> moduleMon run?). This seems to trigger the regular set of > > Yes, this is the moduleMon run. My previous understanding of this was that when the moduleMon oidkey is scheduled for collection, only the device-plugins who have expressed their ability to handle this oid would be triggered. Am I now to understand that all the regular plugins matching a given device will trigger, but among all the SNMP queries they put forth, only a request for the moduleMon OID will succeed? > The idea of the run queue is that different OIDs can be collected at > different intervals, however, the level of complexity due to this is > unfortunately (perhaps too) high - gDD certainly is an ambitious > project. I knew about the idea of different collection intervals for OIDs, of course, but I thought the implemention relied on triggering only the relevant plugins. I did not know the design actually prevented the OIDs from being collected at such a low level. > This problem is caused by a simple bug, however. The ModuleMon for > Cisco uses the CiscoModule plugin to note which modules are down, but > to avoid this situation ModuleMon will not mark modules as down unless > mmc.commit() is called. If you look in CiscoModule.java that method is > called regardless of whether module info was collected or not. Aha! Thanks for this valuable hint :) > This of course assumes that the schedule for all the Cisco module > OIDs is the same, but for now I think you should make that a > requirement. I'm sure a lot of things will break down if we start experimenting with different collection intervals for arbitrary OIDs from the database ;) So far, it's mostly the moduleMon OID that has been interesting to collect more often than the rest. -- mvh Morten Brekkevold UNINETT

1 0

Nav-dev list open to public
by morten.brekkevold＠uninett.no 26 Sep '06

26 Sep '06

Greetings! For months I've been procrastinating, but now I've finally gotten around to fixing it. Public subscription to the NAV developers' mailing list (nav-dev(a)itea.ntnu.no) has been enabled, whereas it was previously moderated. The list archives have been purged, because: 1. They were in Norwegian, which is useless to many. 2. Sensitive information may have been posted on the list, since membership was granted only to a select few within the Norwegian higher education community. I hereby welcome anyone interested in NAV development discussions, and in participating in NAV development to subscribe at http://mailman.itea.ntnu.no/mailman/listinfo/nav-dev :-) (Oh, and the preferred list language is now, of course, English) -- mvh Morten Brekkevold UNINETT

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

Nav-dev