next message in archive
no next message in thread
previous message in archive
previous message in thread
Index of Subjects
Index of Subjects On Fri, 26 May 2000, Jason Currell wrote: > On Thu, 25 May 2000, Ian White wrote: > > > And then theres issues around graphical stuff.. things like some sort of > > standard for kicking off PPP users (again.. compatability.. need to > > implement something that works for PM3s, portslaves, etc.).. perhaps > > include a standard radius server. > > This is kind-of a difficult one from what I remember since there is no > radius command which kills a user. The Radius daemon responds to requests > from the remote access concentrator it does not initiate anything. The > radius daemon can tell the remote access concentrator what "type" of > session to setup for a user but once that user session has started radius > has no way of communicating to the remote access unit that it would like > the session to end. > > Often there are Radius extensions which allow you to mold the user session > to how you would like. For example Ascend provides the > "Ascend-Maximum-Call-Duration" attribute which basically tells an Ascend > remote access concentrator, setup a user session which will not last > longer than so many minutes. It doesn't work by the radius daemon sending > a request to kill the account it just tells the RAC unit what type of > session to setup when things are initially being setup. This probably > won't help however because there is no standardized > (non-proprietary) radius directive which does this so although it works > for Ascend equipment it isn't going to work for everyone. > > There are a few ways to kill off sessions if you are willing to do some > proprietary stuff. Most units will speak SNMP and will respond to SNMP > requests. When I was playing around with this stuff the perl mods for > dealing with SNMP requests were fairly complex and were taking me too much > time to figure out so I droped it. The other thing to do which is much > easier is to is to write an expect script. Expect is a Tcl extension > language built for interfacing directly with the terminal. Basically you > build the program to telnet into the command line interface of your RAC > and input the appropriate keystrokes to kill off the user of your choice. > Just a warning however, there are ways of slowing down keystrokes in > expect. Use them. I had some serious problems with buffer overload on my > Max 4000 which was causing it to crash because the expect script was > sending info too fast. > > If you don't want to go proprietary however you can do things the way we > do now. I have a script which runs once every 10 minutes and rewrites the > radius users file. The script goes through the radius logs and figures > out how much time each user has spend dialed in. If they have spent too > much time dialed in already then I simply don't write an entry for them in > the radius file. I rotate the logs once per week so they don't get too > big to parse. This means that the time limits are weekly > limits. ie) People are allowed 8 hours of dialup time per week on our > system. We don't care how much time they spend telneting into our > system. We have plenty of processor to spare but dialup is at a premium. > To ensure that people don't simply dial in and then never hangup again > you must however set a maximum session timelimit on your RAC. This was mostly wishful thinking on my part. VTN is using the Cistron radius server which has support for preventing multiple logins, and also allows you can call a program and check the results before authorizing the user. Our current user file contains only default entries, to deal with both PPP and rlogin users. When a PPP user attempts to login, a program is run which checks a SQL database to see how much time the user has left and returns the time limit (using the standard Session-Timeout attribute) to the radius server to prevent them from staying on longer than their allowed time. If they have no time left, it denies the connection. When their connection finishes and it deals with the stop record, it subtracts their time this call from their remaining amount. This seems like a good way of dealing with it, as it allows for flexibility, like doing time of day restrictions based on a flag in the users database record, etc. The downsides are that we're still using the namedb file to hold all of the other user information, and it probably would make sense to integrate the two. The other issue is dealing with the weekly resetting of time, for users who are already on. But this isn't the way that CSuite normally deals with users time limits. Normally it has minimum time guarantees and will kick off people over their guarantee time when the number of lines used hits a certain percentage. Which leads me to another issue.. CSuite currently tries to keep track of the number of lines in use on its own, by checking the users online against regexps to decide what class of lines they were using. We should probably make a way of specifying to pull the number of lines in use in a pool through another method such a SMTP or making the radius server responsible for keeping track. That way sites which have one pool for both text and PPP users will have the text users kicked off appropriately. Ian ------------------------------------------- Ian White BC Community Networks Association (BCCNA) email: iwhite@victoria.tc.ca
next message in archive
no next message in thread
previous message in archive
previous message in thread
Index of Subjects