From: David Bussenschutt (d.bussenschutt@mailbox.gu.edu.au)
Date: Mon Sep 02 2002 - 07:15:19 CDT
Hi All,
Sorry for the delay, here's the latest alpha version of my unofficial
to-be-contrib version of the southwestern uni netreg (netreg.org) Let's
call this say 1.3rc2-a just so we have a common version to compare
against (it's loosely based on 1.3rc2 code, and it's my first alpha).
PLEASE don't even consider using this in production. It's for
constructive comment, and development consideration etc only. I will be
releasing another alpha version in I expect 10-14 days with more features,
and probably a few more bugs too. All constructive criticism accepted.
I've only included files in this attached .zip are those that have been
changed or added to the original. (ie everything important in the cgi-bin
folder)
An approximate "changes" list of what I've done:
* I have made it all "perl 5" compliant, so the requires are now are all
'use' modules now. That's what the @ISA, @EXPORT, @EXPORT_OK, $VERSION,
'require Exporter;' and 'package XXX;' statements at the start of each .pm
file are for. The important one is @EXPORT since to make a variable or
function available to other perl apps/modules that 'use XXX;' it, the name
must be included in that list, otherwise it's not available. At a later
date, we can move them into @EXPORT_OK, and then define only what we want
to import as part of the calling app's 'use' statement: eg: 'use Variables
qw( $AUTH_METHOD $IP $SUBNETFILE);' or similar... but for now, this is
easier, and acceptable.
* This includes the functionality, and modified code (and the subnet.dat
format) of the latest CIDR contrib (and some not-yet-released CIDR changes
from the CIDR author).
* I've separated all file accessing functionality to subroutines (and
moved them to Files_Omapi.pm), so it's a slightly cleaner API.
* I've created two new files called Files_Omapi.pm and Error.pm these
contain utility functions that are shared between admin.cgi and
register.cgi. in the same way that the Subnet.pm file does for subnet
stuff. I hope the titles are mostly self-evident. (for those that don't
think they are self-evident names, one contains File and Omapi related
routines, the other Error handling ones!)
* It now requires more perl modules. Including OMAPI::DHCP and
MIME::Base64. All except OMAPI::DHCP are available on
http://search.cpan.org. OMAPI::DHCP is available at: http://BHudson.UCIS.Dal.Ca/~hudson/omapi.zip
I've also included a README file that I wrote for OMAPI::DHCP because
there wasn't one (just a near-empty template file), and compiling it isn't
completely obvious...this readme file is attached. I have contacted the
author asking if he intends to put it on cpan, and have had no response
yet.
* The OMAPI leases stuff is fully implemented for both register.cgi and
admin.cgi. admin.cgi was the tricky one. Unfortunately it uses
iteration, which I consider a HACK. It's also slower i(because of this
hack) in retrieving the info, but it should be able to query a remote
server now. I am looking into de-hacking this, but it's going to mean
writing some C code to be included into the ISC dhcpd server omapi code,
because not all of the omapi interface is implemented yet...so someone
(maybe me, maybe Robert Lowe, maybe you) has to write it!. It supports
multiple dhcpd servers.
* To use omapi, you need a 'omapi-key somekeyname;' (and 'key somekeyname
{...};' ) and 'omapi-port 7911;' added to the start of your dhcpd.conf.
These settings must match those in Variables.pm.
* The OMAPI hosts stuff is not even started yet. all 'known host' info is
still recorded into the dhcpd.conf file. I will work on this part
soonish. Once that is done, the DHCP server/s can be on a completely
different server/s to the webserver. Oh, and it'll support multile dhcp
servers too.
.
* You'll also see in the Files_Omapi.pm file that there is a
read_leases() and read_leases_omapi(). These are designed to be
completely compatible in terms of the data that they return. read_leases()
is not used by default anywhere. To use the non-omapi version, just
replace the two calls (in admin.cgi) to read_leases_omapi() with calls to
read_leases().
* To make register.cgi non-omapi, someone will have to write a non-omapi
equivalent to the omapi_init() and omapi_execleasemac() which I expect
would just use a call to read_leases() under the hood.a I haven't done
this as using omapi in register.cgi requires no iteration, and is very
fast and friendly.
* All file accesses have been put into Files_Omapi.pm, and they all return
arrays containing 'records' from the file on success, or some form of
undef on error.
* I tried to make all the new subroutine names meaningful in one way or
another, but they can be changed if you don't like them. Let me know.
* I've done so much stuff, that I really don't remember it all. Seriously.
* I've added the -w option to the interpreter for both admin.cgi and
register.cgi. Fixing the batch of issues this showed up. I will
hopefully do 'use strict;' later.
* I've tried to reduce the number of global variables that are used across
files (excluding of course Variables.pm, which is the whole point) but
there are still a few of these nasties. All variables used across-files
are required to use the "our" syntax instead of the "my" or "local" syntax
(or worse still, no variable declaration at all) because we are now using
perl 5 syntax.
* There are still quite a number of debugging print statements in the
code, but I think I've commented all of them out...to be deleted later.
If you're keen, give it a go, and let me know how you went.
David.
--------------------------------------------------------------------
David Bussenschutt Email: D.Bussenschutt@mailbox.gu.edu.au
Senior Computing Support Officer & Systems Administrator/Programmer
RedHat Certified Engineer.
Member of Systems Administrators Guild of Australia.
Location: Griffith University. Information Technology Services
Brisbane Qld. Aust. (TEN bldg. rm 1.33) Ph: (07)38757079
--------------------------------------------------------------------
Robert Lowe <Robert.H.Lowe@lawrence.edu>
31/08/2002 02:23 PM
To: David Bussenschutt <d.bussenschutt@mailbox.gu.edu.au>
cc:
Subject: Re: NetReg: is anyone using OMAPI ?
David,
I read through omapi.c -- lots of placeholders. The only objects that are
close to fully implemented are leases and hosts. To get what we want,
pools
would have to be fleshed out, and to support that, a new object for ranges
would have to be created. Each range object needs two appropriately sized
bit-fields (or just one if you want to implement active leases only),
which
can be updated when leases are handed out and freed. Rebuilding those on
startup would be non-trivial; the rest probably not that hard.
Honestly though, I haven't dug deep enough to have really figured this
out.
Is OMAPI implemented as a piece of shared memory, or is it all within the
context of dhcpd, which listens on two ports -- one for dhcp protocol
messages
and one for OMAPI requests??
Have a good weekend!
-Robert
This archive was generated by hypermail 2.1.4 : Thu Aug 12 2004 - 12:01:38 CDT