At 09:57 AM 10/19/99 +1000, Hugh Irvine wrote:
>I think I need to know a little bit more about what is in your "users" file,
>shown above, as well as what form your usernames are and what makes them part
>of the trial group other than the UNIX group file? ie - do they dial into a
>different phone number? do they have a username of the form
>[EMAIL PROTECTED]? In other words, how can we distinguish who they are
>by the contents of the incoming packet. Otherwise, we will have to use a
>PreClientHook or a PreHandlerHook to massage the packet prior to passing it to
>the relevant Handler (which is going to be messy if we have to check the UNIX
>group file). Hopefully we can come up with something a little more elegant.
>Of course, you could always do something completely different like:
>
># Configure accounting to an SQL database or whatever
># Do accounting by UNIX group, etc. during post-processing
Unfortunately, there is nothing to differentiate the userids other than
the group. What we have is a group of "normal" userids that we want to
track differently for billing purposes until they sign up for a higher
level of service. They dial the same phone numbers as anyone else.
As now configured, they would hit our default users file entry, which
is shown below.
DEFAULT Auth-Type = System, NAS-Port-Type = Async
Service-Type = Framed-User,
Framed-Protocol = PPP,
Framed-Address = 255.255.255.254,
Framed-Netmask = 255.255.255.255,
Reply-Message="choice: ",
Port-Limit = 1,
Idle-Timeout = 1200,
Session-Timeout = 28800
We could pull their accounting from the existing detail files as part of
our billing process, but our billing system is about to be revamped and
the people who maintain it don't want to change their current processing
to separate out these users.
We'd thought about using a realm of something like "trial," but if the
user changes his type of service we would then have to have him take
out or change the realm when connecting. We've been told to split out
the billing, but also to make it where the user doesn't have to change
his configuration. I can understand the reasons for that, but it
does make the task more difficult. :-)
To make our choices even more limited, we don't send our accounting
directly to a database. We currently have only one MySQL box that would
be reachable by our radius servers and are concerned about failover and
network latency between the radius boxes and the DB.
I'm interpreting your suggestion about accounting by group during
post-processing to be based on the use of SQL accounting, so please let
me know if I'm wrong. :-)
We're not set on using a unix group to break out these users, but our
limitations made that initially seem like the easiest approach. If we
created an additional default users entry that used Group as a check-item,
would that give us any way to snag these userids for separate accounting?
Any ideas you might have would be greatly appreciated! Thanks for your
time and assistance.
Dawn Lovell
[EMAIL PROTECTED]
===
Archive at http://www.thesite.com.au/~radiator/
To unsubscribe, email '[EMAIL PROTECTED]' with
'unsubscribe radiator' in the body of the message.
