On Thu, 18 Jul 1996, Darren R Besler wrote:
> First off, this solution has a basic assumptions which are sometimes
> are overlooked.
So, you have a backup accounting server to make sure you don't miss
anything. You also poll the portmasters occaisionally with SNMP to make
sure of the status of connections you've gotten no STOP packet for.
> - If you are running multiple RADIUS (authentication/accounting) on
> multiple computers that they are UNIX based and all can share a NFS
> mounted disk.
The file system has to really exist somewhere. When that somewhere goes
down you have to have a backup plan.
> It appears that much of the concern of this kind of control is ensuring
> sycnronization of state data between NAS and the RADIUS servers. I have never
> liked the fact that these two entities can get out of sync. This may be
> partially to do with using a connectionless protocol like UDP aot TCP (but that
> is another debate!).
Quoting from the Livingston 1.16 radius.h:
#define PW_STATUS_START 1
#define PW_STATUS_STOP 2
#define PW_STATUS_ALIVE 3
That looks like there could be accounting packets that indicate a
connection is still alive. I haven't seen any of those packets come my
way, nor have I seen anything about that in the developping radius
standard, nor could I find any way to coax the portmaster to send one. It
seems like a logical thing to have. It would be nice if ComOS could be
configured to send them at certain intervals, or if the radius protocol
include a packet from the server to the portmaster requesting one of
these for all active ports or all ports or a specific port.
> Here is my proposal:
>
> - Create a directory 'pm-users' in the UNIX filesystem that is shared via NFS
> (or any other file sharing mechanism) by all servers.
>
> - Modify RADIUS server for authentication functions, after correctly validating
> the user (more on this later), to create (touch) a file of the form
>
> NAS-PORT-USERID
>
> where NAS = NAS id, PORT = the NAS port, USERID = the userid
A slight variant I've thought about would be a fixed length flat file with
space reserved for each port. Space would be reserved for 64 bytes per
port. A portmaster would be assigned a 2K region of the file. That way
you can access a port instantly with a trivial hashing function, instead
of a linear search through a directory. Of course, my way you have to
write more tools. You can't do "ls /usr/local/pm_user/*/*-username" to
find out which port username is logged into.
(BTW the 64 bytes provides plenty of space to store dynamic IP, numerous
timestamps, service type, partial billing information, etc.)
> - Somehow the RADIUS authentication or accounting server needs to determine
> when a PM is rebooted or reset. Is anything sent up? I don't know, I don't
> have any of my Livingston stuff online right now! If so, then use this
> "boot" information as an indicator to clear all entries for that specific
> NAS. for exmaple:
>
> rm pm/users/NAS*
I recall reading that there is such a flag sent. I don't remember the
exact details.
Steven P. Crain scrain@shore.net
Unix Administration and Programming
North Shore Access
-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
Comment: Finger me for a public key.
iQB1AwUBMfE+U40DAXSiDippAQGmqAMAkBIbn/9ujX0fI4ZkTC1/ux87YMX99Sr9
JPXN6vZnHNlCwgy5vZiaIiDdh14vKqfw3QhSUEn8aBrrrSK8BExVP+zKDylaWqBy
QDMJiI0rgpNpbLNpQWFUFRDIYWk69GRq
=WbYe
-----END PGP SIGNATURE-----