[freeside] I think I have this down....
ivan at sisd.com
Wed Jul 21 00:33:22 PDT 1999
On Sun, Jul 18, 1999 at 11:38:46PM -0600, Tech Account wrote:
> > No, the instructions are skeletal at best. Thanks; hopefully your outline
> > will be useful!
> The thing about the instructions is that they only cover the physical
> software installation and not it's proper intent and use. If I get this
> thing working, and have a chance to test it, I will write some docs which
> will hopefully more clearly outline the way to use it correctly.
A couple other people have expressed interest in helping out with this so
you might want to coordinate with them on the list.
> > Err, no. You should not have to edit Conf.pm
> Well, to put it simply, the shells config file doesn't work at all on EITHER
> of my installations. They are both completely up to date with perl, apache,
> and freeside. I found this hard path for the config files which points to
> Which isn't correct, since such a thing doesn't exist in any form on either
> box, nor is mentioned anywhere in the docs. In a desperate attempt to get
> the thing working, I changed this path to /usr/etc/freeside and things
> started to work better. That was the ONLY change that I made. However,
> Shells still didn't work, and since your error message doesn't tell me
> WHERE it is actually looking for the shells file, all I could do was
> change a simple line of code to kludge around it.
> No, of course this isn't the proper thing to do, but it actually works.
I was responding to that as part of an outline for installation
instructions. You are of course free to do whatever you like to the
The config file locations in 1.2 confused a lot of people as things had to
be moved to support multiple configurations on a single box. It wasn't
documented very well.
> > Reporting them is still useful; it helps me make the error messages more
> > informative. :)
> Freeside suffers from but one problem, freeside reports the same error no matter
> WHAT is wrong. Making the error useful and easy to debug is matter of passing
> some of the variables in the program out to the real world, then people could
> tell you exactly whats wrong without any effort at all. Saying that someone
> has a bad shell for example, without telling them shell not found in:
> /usr/local/etc/freeside/shells isn't of much use, since they could have a
> number of errors, a bad shell entry, a missing shells file, a bad shells
> path, or another problem.
Okay; this now returns the shell you typed, the full pathname of the file
Freeside looked in, and the shells that were in this file.
> Currently, if you have a package problem you can
> still add a user without a package, but if you go to order one, the order
> cancel screen can be blank, when it should report that no packages are
> currently configured for use. Specifically I hadn't linked any packages
> to agents!
Okay; it now does.
> Without docs to know that I had to have working agents to sell
> packages, and that if I added a package AFTER I had the agent around then
> I could not use the package, life is very difficult. With terribly generic
> error messages it's very hard to find such issues.
Let me know any other suggestions you have for better error messages.
> In any case, I'll try to document more fully such things.
> I'm still interested in a solution to add onetime charges to a given
> customer account...
You can use the `Customize Pricing' link on each package, on the main
customer view screen.
>Freeside appears to have most of the setup and
> config account work done, and much less flexibility in the billing side.
Well, all prices are Perl expressions, so we should be able to implement
any billing scheme.
Ivan Kohler <ivan at sisd.com> - finger for PGP key - <moc.dsis at navi> Relhok Navi
Open-source billing and administration for ISPs - http://www.sisd.com/freeside
20 4,16 * * * saytime # please don't be surprised if you find me dreaming too
More information about the freeside-users