- noctool-devel@lists.common-lisp.net - mailman3.common-lisp.net

[noctool-devel] Fwd: [ann] cl-net-snmp 3.0 released
by Chun Tian (binghe) 21 Jul '08

21 Jul '08

A.T.T. > > Hi, Lispers > > After one and a half year since I started this project (0.01 on May > 2007, 1.2 on Oct 2007), I'm glad to > release cl-net-snmp 3.0 today, the pure-lisp implementation of Simple > Network Management Protocol (SNMP, RFC 2271). > > From this release, I throw out the ZEBU LALR parser and write a simple > ASN.1 compiler (based on LispWorks parsergen) to > generate Lisp code from ASN.1 MIB files, then use ASDF to load them > directly. Any ASN.1 Object Identifier value are treated as a Lisp > variable. > > This project is part of my big plan: write a new system administration > platform (like HP OpenView) completely in Common Lisp. > > Cliki page: (contains link to other resources) > > http://www.cliki.net/cl-net-snmp > > Current Supported Platforms: > > * LispWorks > * CMUCL > * SBCL > * Clozure CL > * Allegro CL > > Features: > > * Full SNMP protocol support (SNMPv1, SNMPv2c, SNMPv3) > * Support MIB and ASN.1 object id names > * Fast BER encode/decode based on CLOS > * UDP retransmit support > * [LispWorks] Simple SNMP Server > * [LispWorks] GUI MIB Browser > > Download: > > You can use ASDF-INSTALL to install cl-net-snmp 3.0, or download > following release files: > > * The core: SNMP 3.0: > > http://common-lisp.net/project/cl-net-snmp/release/snmp_3.0.tar.gz > > * ASN.1 runtime and compiler, version 2.3: > > http://common-lisp.net/project/cl-net-snmp/release/asn.1_2.3.tar.gz > > * UDP patch for usocket, version 1.2: > > http://common-lisp.net/project/cl-net-snmp/release/usocket-udp_1.2.tar.gz > > * LispWorks UDP support, version 2.1: > > http://common-lisp.net/project/cl-net-snmp/release/lispworks-udp_2.1.tar.gz > > Sample Usage: > > ? (snmp:snmp-walk "debian-amd64.local" '("system")) > (((#<OBJECT-ID sysDescr.0> > "Linux debian-amd64 2.6.25-2-amd64 #1 SMP Fri Jun 27 00:16:12 UTC > 2008 x86_64") > (#<OBJECT-ID sysObjectID.0> #<OBJECT-ID netSnmpAgentOIDs.10>) > (#<OBJECT-ID sysUpTimeInstance (0) [0]> #<TIMETICKS (208848) > 0:34:48.48>) > (#<OBJECT-ID sysContact.0> > "Root <root@localhost> (configure /etc/snmp/snmpd.local.conf)") > (#<OBJECT-ID sysName.0> "debian-amd64") > (#<OBJECT-ID sysLocation.0> "Unknown (configure /etc/snmp/ > snmpd.local.conf)") > (#<OBJECT-ID sysORLastChange.0> #<TIMETICKS (0) 0:00:00.00>) > (#<OBJECT-ID sysORID.1> #<OBJECT-ID snmpFrameworkMIBCompliances.1>) > (#<OBJECT-ID sysORID.2> #<OBJECT-ID snmpMPDMIBCompliances.1>) > (#<OBJECT-ID sysORID.3> #<OBJECT-ID usmMIBCompliances.1>) > (#<OBJECT-ID sysORID.4> #<OBJECT-ID snmpMIB (1) [2]>) > (#<OBJECT-ID sysORID.5> #<OBJECT-ID tcpMIB (49) [1]>) > (#<OBJECT-ID sysORID.6> #<OBJECT-ID ip (4) [39]>) > (#<OBJECT-ID sysORID.7> #<OBJECT-ID udpMIB (50) [1]>) > (#<OBJECT-ID sysORID.8> #<OBJECT-ID vacmBasicGroup (1) [0]>) > (#<OBJECT-ID sysORDescr.1> "The SNMP Management Architecture MIB.") > (#<OBJECT-ID sysORDescr.2> "The MIB for Message Processing and > Dispatching.") > (#<OBJECT-ID sysORDescr.3> > "The management information definitions for the SNMP User-based > Security Model.") > (#<OBJECT-ID sysORDescr.4> "The MIB module for SNMPv2 entities") > (#<OBJECT-ID sysORDescr.5> "The MIB module for managing TCP > implementations") > (#<OBJECT-ID sysORDescr.6> > "The MIB module for managing IP and ICMP implementations") > (#<OBJECT-ID sysORDescr.7> "The MIB module for managing UDP > implementations") > (#<OBJECT-ID sysORDescr.8> "View-based Access Control Model for > SNMP.") > (#<OBJECT-ID sysORUpTime.1> #<TIMETICKS (0) 0:00:00.00>) > (#<OBJECT-ID sysORUpTime.2> #<TIMETICKS (0) 0:00:00.00>) > (#<OBJECT-ID sysORUpTime.3> #<TIMETICKS (0) 0:00:00.00>) > (#<OBJECT-ID sysORUpTime.4> #<TIMETICKS (0) 0:00:00.00>) > (#<OBJECT-ID sysORUpTime.5> #<TIMETICKS (0) 0:00:00.00>) > (#<OBJECT-ID sysORUpTime.6> #<TIMETICKS (0) 0:00:00.00>) > (#<OBJECT-ID sysORUpTime.7> #<TIMETICKS (0) 0:00:00.00>) > (#<OBJECT-ID sysORUpTime.8> #<TIMETICKS (0) 0:00:00.00>))) > > Regards, > > Chun Tian (binghe) >

1 0

[noctool-devel] Re: NOCtool and SNMP
by Ingvar 13 Jul '08

13 Jul '08

Chun Tian writes: [ I have CCd the noctool-devel mailing list ] > Hi, Ingvar Mattsson > > I'm a UNIX system administrator and Lisp programmer in China. > > Recently I saw your NOCtool project [1] on common-lisp.net. I also > want to build such a package for monitor my UNIX servers. My plan is > write a pure lisp SNMP client first, then IPMI client, then other > monitoring support (HTTP, Ping, ...), finally build a Web server on cl- > http and add graph drawing facility. > > It seems that your project already done the later part of my plan:) Yeah, it's slowly getting there and I was looking at SNMP packages a while back, since I can see that having (some sort of) SNMP support would make it much easier monitoring some types of equipment. > Now I have a working SNMP client (even server) package[2]. For this > project, I also write a USOCKET UDP patch and LispWorks UDP support. > If your're still interesting in improve your package to monitor more > things, you may want to see my work. > > The SNMP package is on SVN: (tested on LispWorks, other CLs maybe need > small fixes) > > https://cl-net-snmp.svn.sourceforge.net/svnroot/cl-net-snmp/snmp/trunk > > The USOCKET UDP patch (as an ASDF package, waiting USOCKET author > merge it): > > https://cl-net-snmp.svn.sourceforge.net/svnroot/cl-net-snmp/usocket-udp/tru… > > The IPMI package (still under development, not usable) > > https://cl-net-snmp.svn.sourceforge.net/svnroot/cl-net-snmp/ipmi/trunk Cool. Are the packages in such a stage that it would make sense to package them up so ASDF-INSTALL can grab and build them? From what I can tell, what's needed is an ASDF system definition file, a tar-ball with the relevant source files and an entry in CLiki. //Ingvar

3 3

[noctool-devel] Re: [noctool-cvs] CVS source
by Ingvar 09 Jul '08

09 Jul '08

> Modified Files: > scheduler.lisp classes.lisp > Log Message: > > moved :BEFORE PROCESS method for EVENT class into scheduler.lisp Noooo! Now it won't compile from a clean image (the class definitions in classes.lisp provide the definition of the PROXIES generic, that's not available at the time scheduler.lisp is compiled). Yes, I found this the hard way (as I needed to have two images running to test the network code) and the non-SLIME kept breaking on load. Probably should've been a bit more clearer on why things were done as they were. One way would be to split "classes.lisp" into "classes.lisp" and "methods.lisp" and have scheduler.lisp depend on classes.lisp and do the PROCESS :BEFORE method definition in scheduler.lisp and the rest of the stuff in classes.lisp in methods.lisp. Alternatively, re-jigger the ASDF definition to have schedler.lisp depend on classes.lisp. //Ingvar

2 3

[noctool-devel] network-remote-calls.lisp
by Jim Prewett 07 Jul '08

07 Jul '08

Hi Ingvar, I think you forgot to add network-remote-calls.lisp to the CVS repository. noctool.asd now says that it needs this file - I'm assuming this is merely an oversight. Thanks, Jim James E. Prewett Jim(a)Prewett.org download(a)hpc.unm.edu Systems Team Leader LoGS: http://www.hpc.unm.edu/~download/LoGS/ Designated Security Officer OpenPGP key: pub 1024D/31816D93 HPC Systems Engineer III UNM HPC 505.277.8210

1 0

[noctool-devel] Re: [noctool-cvs] CVS source [ network update ]
by Ingvar 03 Jul '08

03 Jul '08

> Update of /project/noctool/cvsroot/source > In directory clnet:/tmp/cvs-serv14870 > > Modified Files: > classes.lisp graphing.lisp network-globals.lisp > network-utils.lisp network.lisp noctool.asd packages.lisp > scheduler.lisp tests.lisp > Log Message: > IM > > Bulk update of (mostly) network-code-related changes. > There's one change that pertains to graph code (setting the last-updated > field). Fair chunk of update. It is my belief that the network code should now work (more or less) and is ready to be played with. The general idea is "request a list of objects for a specific class to get the IDs you need to subscribe to", "subscribing to a piece of equipment gets updates for all the monitors", "if you want graph data you have to subscribe to the graph" and "you get updates until you unsubscribe". I'll try to get something on the hacking page, in the next week-or-so. //Ingvar

1 0

[noctool-devel] W00t, I think
by Ingvar 02 Jul '08

02 Jul '08

I've integrated the networking code into the rest of teh code base (it was a bit chunkier than expected) and have carefully intervowen tis wit the rest. Things are compiling cleanly, I think (will have to do another test) and unless there are objections, I am feeling fairly ready to check the whole chunk in. Yes, it touches scarily many parts of the code-base outside the "network*.lisp" files (hooks into the scheduler, into the graphing and a few more places). Shouldn't make a blind bit of difference unless you have network connections. //Ingvar

1 0

[noctool-devel] More network protocol success!
by Ingvar 22 Jun '08

22 Jun '08

Haha! One step further, I have now managed to transfer a list of equipment objects in a specified class. Unfortunately, I need to flange things around a bit, so things get put in the right place, in the right places, as it were (not happening right just yet). But the networky side is looking brighter, day by day. //Ingvar

1 0

[noctool-devel] Re: [noctool-cvs] CVS source
by Ingvar 20 Jun '08

20 Jun '08

Jim writes: > Modified NEXT-TIMESLOT so if it is called without the optional > scheduler and there is no *DEFAULT-SCHEDULER*, a default scheduler is > created and bound to *DEFAULT-SCHEDULER*. Good one! Managed to get bitter by the lack of a PROCESS method for CPU-MONITOR this morning (no, yesterday morning). Quick cheat, until we know what to do with it: (defmethod process ((mon cpu-monitor)) nil) I'm populating a LINUX-HOST equipment with data and will hopefully have time to get data flowing from one lisp instance to another either beginning of next week or over the weekend, depending on how much hack time there is. Unfortunately, this means my source code is FULL of stuff that really should be submitted together, so I'll hold off checking in any changes for now. //Ingvar

2 3

[noctool-devel] CSS is good, right?
by Jim Prewett 17 Jun '08

17 Jun '08

Hi everyone, I've never been much of a web person and am certainly not up on the latest trends :P Are the kids still using CSS for making their webpages pretty? If so, I was thinking something like CSS could be really useful for the Noctool web UI. Mostly because I couldn't design a decent color scheme to save my life ;P I don't know any CSS, but I'm willing to learn a little ... Jim James E. Prewett Jim(a)Prewett.org download(a)hpc.unm.edu Systems Team Leader LoGS: http://www.hpc.unm.edu/~download/LoGS/ Designated Security Officer OpenPGP key: pub 1024D/31816D93 HPC Systems Engineer III UNM HPC 505.277.8210

2 3

[noctool-devel] Re: [noctool-cvs] CVS source/docs
by Ingvar 17 Jun '08

17 Jun '08

Jim writes: [ I am CCing this to the devel list, as it probably shoudl be archived there ] > Ingvar writes: > > Some sort of GUID? It gets REAL messy, REAL fast. I've just changed (but > > not yet checked in) an improved GET-PROXY that uses both connection and > > ID to find a proxy object (one needed on each end, though the client end > > instantiates equipment and montitor objects as needed and link to them > > in the proxy object, whereas the server end uses the proxy objects to > > know where to send updates). > > I've done GUID's before, but its been 10 years and I don't really recall > the issues :P :) I'm happy to say "Hell NO!" ;) For one, I want IDs to persist across reboots, if at all possible (this is, obviously, much easier with in-process interafces, though saving off a list with remote-node-name/ID-there as key is doable). This should, ideally, also survive "pack everything up and ship to new server", but as the classic GUID implementation use (among other things) the MAC address (well, "a" MAC address) on the generating computer, you suddenly lose the ability to check IDs that have been generated before, once the original box is sufficiently rebuilt (NOTE: I think they usually mix in time-of-day, in these things). > > > 2. I was thinking of factoring out the ID slot into an id-object class and > > > then creating an after method for initialize-instance to throw the > > > instance into a hash table based on its ID > > > > Better to just change the basic storage for *equipment* and change > > NOCTOOL-CONFIG:LOAD to do The Right Thing > > Hmmm... I don't know that I agree. I think its possible, for example, > that a monitor might be created by some process besides > noctool-config:load - making CLOS do The Right Thing seems better to me. Well, there are examples of that already (disk-monitor or whatever it's called generates monitors for individual volumes) and will only become more prevalent (traffic-monitoring on, say, a switch will need to do the same). It's probably sane doing that in CLOS. > I'm a big fan of "mixin" classes. > > > > 3. Is there any particular reason you chose to use uninterned symbols for > > > the IDs (GENSYM instead of GENTEMP)? > > > > Yeah, kinda. It's guaranteed to exist on all lisps and we're essentially > > doing string-compares anyway (ooops, need to fix that in the network > > code). As long as we're OK with having only locally-unique IDs, we could > > fall back on a plain counter. > > Well, we're using Common Lisp and GENTEMP is part of the standard > according to CLHS. Also, I think we should be realistic about targeting > *ONLY* SBCL for the first (real) release. If it doesn't work with SBCL it > doesn't work with Noctool. :P > > Why I'd wanted an ID to be an interned symbol is that it makes it so much > easier to convert from a string given by the user. The other way to do it > is to hash on the symbol-name of the gensym'd symbol - that actually is a > tad more efficient since I don't always have to convert between strings > and symbols. I am thinking that we should move to using (one or two) plain counters, as we'd have to make sure there are no ID collisions after un-persisting stored data. > So, In short, I no longer care if we use gensym or gentemp. :P :) > > I think my arguments of if its in the spec its fair game and if its > supported by SBCL its fair game should still be considered. (If its in > the spec and not suppored by SBCL, I'll take the abuse and submit a bug > report ;) Yeah, SBCL first, the world later. :) > > > I'm thinking about the web interface stuff and, man would I like to be > > > able to look up a monitor by its name for the purposes of the GUI... > > > > Name and ID are different, though. The name is supposed to be human-friendly > > and the ID is supposed to be code-friendly (with the obvious problem that > > human-friendly doesn't necessarily imply unique). > > OOOPS! I was speaking /far/ too losely :) NEED MORE COFFEE! Can't have too much. Speaking of that, I realy should get some lunch. > I want to look up a monitor by its ID, not its name. (I probably also > want to look it up by its name at some point, but... ) > > > It gets even bizarrer with monitors, since they don't (strictly > > speaking) have names, they do have associated equipment objects, though > > (and they have names). > > > > I suspect the best (as in "easiest", not necessarily as in "technically > > most superior) is to have something akin to: > > http://noctolweb/equipment-by-name/jprewett-server-17/ping-monitor > > This looks up jprewett-server-17 (a piece of equipment), by name and > > spots that there are more stuff after. It then checks the ID and > > builds a new URL and redirects to > > http://noctoolweb/equipment/EQ-42/MON-872 > > > > That way, you tend towards persisting ugly (but fast-to-render) URLs, but > > still have an easy way of actually finding them. > > Thats pretty much what I was thinking. Your suggested URI's are > remarkably simular to what I was playing with yesterday :) They make sense, in some sort of human-readable way. > I'm intentionally *not* looking at your X11 GUI until I've taken a first > stab at the Web-based one. I don't want to be biased by your interface. > After I've got something I'm reasonably happy with, I'll take a look at > your X11 GUI and fix all the things I flubbed ;) At the moment, there isn't an X11 GUI. The closest you get is using either an XLIB:DISPLAY or XLIB:DRAWABLE as a sink for IMAGE:EXPORT-IMAGE. //Ingvar

1 0