svc_broadband merge to HEAD (fwd)

ivan at 420.am ivan at 420.am
Wed Sep 11 07:04:34 PDT 2002


Cc:ing -devel, too, no reason for us to be discussing this stuff in
secret :)

On Mon, Sep 09, 2002 at 08:51:43PM -0700, Mark Wells wrote:
> 
> Ivan:
> 
> Since you missed the original message in which I described my
> scheme, here's the short version:
> 
> 
>       (svcpart)    (exportnum)   (exportnum)
> part_svc-|->export_svc--->part_export--->part_acct_field
>          |                                 |
>          |                                 | (fieldnum)
>          |         (svcnum)     (svcnum)   V
>          |->cust_svc----->svc_acct----->acct_field
> 
> 
> We recently created (part_)sbp_field, to go with svc_broadband, and we've
> been planning to create a similar set of tables to hold the RADIUS
> attributes from svc_acct.  It seems that both of these are examples of
> 'export fields'--Freeside doesn't use them for anything, but we have to
> keep them around because certain exports need them.

Hmmmmmmmmmmmm....

I agree svc_* tables could really benefit from "add your own" fields.

I'm not sure about tying the custom fields to exports (part_acct_field).
Can't they just be defined as global custom fields for a particular
svc_* table?

> It really seems that ALL of the fields in svc_acct (except svcnum and
> maybe username) are export fields.  uid and gid, for example, don't make
> much sense for any kind of svc_acct except one that represents a shell
> account.

I'm don't think I'm ready to move existing fields (uid, gid, etc.) to
such a mechanism yet...  It would be nice if we designed the API so that
this would be an internal change, though (i.e. make all custom fields
available as "pseudo-fields" in svc_whatever.pm).

> What I'm proposing is to move the export fields into a separate table
> (acct_field), like we were going to do with sbp_field.  This subsumes the
> functions of both sbp_field and the RADIUS attribute table.

RADIUS attributes feel wrong mixed up with the custom fields, for some
reason, though.... For some reason it still feels like we should have
RADIUS attributes in their own table, like the schema I described in my
other email...  unlike other custom fields, they have a specific meaning
and come out of a dictionary.

> It makes
> svc_broadband completely unnecessary; a broadband service is just a
> svc_acct that exports to a broadband device of some kind.

I don't think this would make svc_broadband unnecessary... svc_broadband
seems to be appropriate for "network connections", and especially if
they aren't provisioned with a username in RADIUS, you want someplace to
keep their info, IP/netblock, and so on.  svc_broadband is for "network
connection things" whereas svc_acct is for "username things".

BTW, I do hope we can fit FreeIPdb in the svc_broadband picture,
though... (the backend, not necessarily the web interface)... it does
several things that svc_broadband doesn't yet, no reason to dupliate
that work.  The author is willing to help us if we tell him what we
want.

> A shell account is just a svc_acct that exports to a shell host.  A
> mail account is just a svc_acct that exports to a mail server.  Et cetera.

I think we've achieved this with 1.4 and exports, actually.

-- 
_ivan



More information about the freeside-devel mailing list