[freeside-devel] Some Ideas

[ivan]

On Wed, Nov 16, 2005 at 02:03:56PM +1100, Jason Thomas wrote:
> Hi All,
> 
> I've been evaluating FreeSide for the company I work for, and as I'm a
> Debian developer I had a go at packaging it up for Debian.
> 
> Well to put it bluntly things look to be a mess. Which explains why it
> took Richard Siddall 6 months to create redhat packages.
> http://www.sisd.com/pipermail/freeside-devel/2005-September/000521.html

Certainly I don't disagree that things are a mess from a packaging 
standpoint.

> Anyway, so I've written down some ideas which should help spur some
> developement work on FreeSide and maybe even new users. Hopefully this
> will lead to packagable product for Debian/Redhat/<insert distro>.

Ideas are great (and I've commented on yours below) but more importantly 
is folks interested in actually contirbuting work towards making them 
happen.  Are you interested in working on one or more of these items?  
Let us know what you're interested in actually spending some time on.

As Richard pointed not, most of these are not actually prerequisites to 
getting stuff packaged up, if not immediately clean enough to upload to 
unstable.

> IDEAS
> =====
> 
>  * Split freeside into nicely defined parts (which can still be in the same
>    tarball):
> 	- fs
> 	- fs docs
> 	- fs web interface
> 	- fs self service server
> 	- fs self service client

The above are all more-or-less separatable.

I don't think we necessarily need to split things down in the "upstream" 
source tarball so much as build multiple packages from it along the 
lines you outline above.

You might want to take a look at debian/control, which, though quite 
out-of-date, contains some thoughts along these lines with regard to how 
the system might be broken down into packages.

> 	- fs modules; radius, bind, postfix, sendmail, apache, etc

I don't think these need to be abstracted out from a packaging 
standpoint (they're already factored out from a library standpoint into 
FS/FS/part_export/).

>  * Use autoconf in each part, so that various configuration options can be
>    changed easily, like install directories. AutoMake can be used to substitute
>    paths in perl scripts and modules.

I must admit I'm a personally a bit skeptical that this stuff would be 
ideal for a pure-perl project, but if someone wanted to work on it, I 
certainly wouldn't stand in the way of progress.  :)  Seems to work okay 
for RT.

>  * There can still be a single Makefile in the base of the directory structure
>    to make it easy for people use to the current install method.

*shrug* not terribly important IMO.

>  * Each part should not rely on others. This is so that the web interface or
>    self service server could be run on another machine.

Hmm... The self-service stuff is *designed* to run on another 
machine or machines (your public web server or servers).

The backend web interface as well as the daemons controlling the 
self-service machines all depend on the library layer, and while 
"farmable" (with a few caveats) are usually run on a single machine 
along with the database.

I could discuss a lot about this if you wanted to work on how things are 
organized.  In the most ideal setup, you'd have a "super back end" 
machine that doesn't even run the backend web interface and is the sole 
box with the private key used for CC decryption.

>  * The web interface should not need to run as the freeside user.

I agree (for the various command-line stuff with that requirement as 
well), I just don't know what a good alternative would be.  
World-readable database connection information certainly isn't.  :(
RT uses a group and setgid, which doesn't seem to me to be much of an 
improvement.

>  * If we make freeside self service server a module than other modules can be
>    written. Or perhaps we can write an some sort of socket based API with which
>    to interact with freeside.

I'm not sure I understand what you mean when you're talking about making 
the self-service a module.

Self-service stuff is already designed to run on a separate, external 
machine.  The self-service web interface is built on top of a Perl API.  
The idea is to use that to make a language-neutral self-service API 
available.

XML-RPC seems like a good choice, not because I have anything for XML 
specifically, but because there's implementations avaialble for 
everything under the sun its a lot simpler than SOAP while still rich 
enough to pass complex data structures.

>  * A clearly seperate web interface would make it easier for people to write
>    there own, or for us to have more than one. Perhaps we could use some sort
>    of templating system.

That's what's being worked towards, certainly, using HTML::Mason.

>  * The configuration files should be cleaned up. why so many dirs. Let use
>    something familiar look INI files.

I think configuration should go in the database instead.  Configuration 
in the filesystem would be limited to database conneciton information.

>  * DB choice should be in the config file. The name of the DB shouldn't have
>    anything todo with the other config files.

This was originally done to support multiple, separate Freeside 
instances running on a single machine.  While I wouldn't want to lose 
this ability entirely, its a rare enough case that I agree we should 
make the most common case simple.  :)

>  * Each part should have its own config file. The minimum in each config would
>    probably be database info.
> 
>  * All paths should be configurable in the config file, and use sensible
>    defaults. e.g logging to log/freeside instead of etc/freeside/
> 
>  * Logging probably should use syslog or at least be configurable. There is a
>    perl module for that.

Okay.  By default I'd rather log to files directly than use syslog.

>  * handler.pl where should that go, not etc/freeside/

Good question.

Following RT's example (RT seems to be the only HTML::Mason app 
currently packaged), /usr/share/freeside/libexec/ 

>  * Template path should be in config file.
> 
>  * Provide example web server conf files.

See htetc/freeside-base.conf and htetc/freeside-rt.conf

>  * Pages in web interface should be split into multiple pages, instead of one
>    big long page.

Again, that's certainly what's being worked towards; 
httemplate/view/cust_main/ and httemplate/edit/cust_main/ for example.  

I could certainly use more help if folks aren't happy with the pace at 
which things are progressing.  :)

>  * It would be cool if freeside could be neutral when it comes to 
>    things like DNS. So you store DNS entries but there not specific 
>    to bind. Then we could have some sort of module to populate bind. 
>    Same with mail softwarei and radius. etc. Like modular I suppose.

This is already the case.  There's nothing particularly BIND-specific 
about the DNS data.  There is already a BIND export, as well as exports 
for various mail and RADIUS servers.  Exports are written in a modular 
fashion by creating an FS::part_export subclass.  

-- 
_ivan