Well, despite the fact that I am writing this journal entry on April Fools Day, this is in fact my very first journal entry. I am really terrible at keeping these things up do date if not just getting them started. Anyhow, I made a lot of progress this weekend and later part of last week so I thought I'd share what all happend. This weekend I worked on the scripts for the user-interface side of the utility. These scripts will generate the HTML that the user will see in their web browser and then also execute all of the necessary functions to do the heavy lifting. Orrigonally we had thought of writing this part in PHP, but due to time constraints, I've decided to put off the PHP of this project untill a later revision. This simplifies a few things since now I can do all of the output from the perl in HTML. It may make things easier when switching to PHP, but I'll worry about that later. Anyhow, one of the big hurdles that I was trying desperately to get over was the authentication side of the scripts. I found a perl module which interfaces with a Database and a Radius server to do authentication. I guess what I would really like is a module that used cookies and a Radius Server, but this will probably work just fine. The added advantage of having the database interaction is that I can set up group-wise authentication, which is one thing that we'd had on our minds since the initial stages of planning this project. What this means is that we can designate a group of users that have extended permissions to the utility. This feature may be present from within Radius, but if it is I am unaware of it. If it is, then we could probably get away with just having the Apache::AuthenRadius (or something similar) package. If that functionality is not there (within Apache::Radius), it might be possible to (in the future) to write an extention to Apache::AuthenRadius so that it would support gropus. Of course it group identification is not there, then I'd have to try to find some way to do it. This is why the datbase aproach seems apropriate. Cookies are nice in this situation (in my opinion) becaue it allows us to protect things at the server layer instead of weaving our security into our code. This also make security modular and would allow you to replace it with whatever type of security you wish. Well, anyhow... Enough on all the ways that I'm finding that this is really a good idea. After hours and hours of what now seem to have been spend chasing my tail, I now finally have something working that resembles what I set out to achieve. There are still problems with the actual authentication and the cookies, but I don't think that will be too much trouble to sort out. What my time was spent doing was trying to solve problems in the modules that I was trying to install. The modules just kept spitting out errors about non-existing methods and objects that I couldn't find the source to the problem for. Turns out that a good part of the problems stemed from the fact that I was using CPAN to install the modules and aparently the modules must be run from within an Apache environment, not a command line. Once I started trying to execute in a browser window (after forceably installing the modules) things started working. The other problem was I was chasing wrong modules around. I think I may have been trying to install modules (that weren't installing) but that didn't need to be installed for this to work. Since I have perl and all of the coresponding programs installed via RPM it turns out that it would be relatively impossible to make a clean slate without getting rid of a lot of stuff. I'll have to see about cleaning up the mess after I get the inital release out and "working". So now on to the rest.