Date: Tue, 21 Aug 2001 00:28:37 +1000 From: "Hugh Blandford" <hugh@island.net.au> To: "Andrew Reid" <andrew.reid@plug.cx> Cc: <freebsd-isp@FreeBSD.ORG> Subject: Re: RADIUS Accounting with SQUID Message-ID: <002001c12984$67378c00$0bdea8c0@island.net.au> References: <997919908.1446.1202.camel@localhost><20010815094331.B12922@jake.akitanet.co.uk><997984620.1446.2253.camel@localhost> <20010816141325.C19104@jake.akitanet.co.uk> <998149933.1602.360.camel@localhost>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi Andrew, maybe you can find something at: http://www.caida.org/tools/measurement/ They have various useful tools, though working out what student is on what particular IP address and tieing them to the flows could be interesting, though it is not impossible. This way you can measure all their traffic :)) Regards, Hugh ----- Original Message ----- From: "Andrew Reid" <andrew.reid@plug.cx> To: "Paul Robinson" <paul@akita.co.uk> Cc: <freebsd-isp@FreeBSD.ORG> Sent: Monday, August 20, 2001 9:04 AM Subject: Re: RADIUS Accounting with SQUID > On 16 Aug 2001 14:13:26 +0100, Paul Robinson wrote: > > > I am assuming that a bandwidth cap would be out of the question, or perhaps > > even the use of something like dummynet or whatever to do bandwidth > > 'shaping'? (I love the 'phrase' shaping when used to mean 'restriction'. :) > > ). > > The reason that it is not done this way is two-fold: > > 1. You've got to tie things down to the username. Seeing as the > machines are somewhere else, that'd at least require the use of > ident. Ident can be easily forged. That'd be bad. > > 2. We can't/don't/won't charge students for usage of internal sites. > People get stroppy about being charged for using the Intranet et al. > > > > So, we've got something, working and I'm happy. I've decided that I want > > > to be able to get some more information. Things like per-user MRTG-ish > > > graphs and the like would be great. > > > > Personally, if there was more than just a few students, I'd find this > > horrendous to look at, but each to their own. :-) > > I wanted to be able to give users graphs, rather than me :-) From that > same data, I suppose I could generate year-level graphs etc. That's > where I'm going. > > > > I've not had much to do with RADIUS, but I know that it provides some > > > accounting functionality. I thought that the two (SQUID and RADIUS) > > > could be mushed together somehow to provide a slightly more workable > > > solution to Internet Quota. > > > > Well. Hmph. OK, this might be quite awkward. The only way I can think of > > getting an Accounting-Start is with munging some sort of proxy > > authentication. However, you will get a start saying 'this kid has just > > started' but will get no more further information until they > > de-authenticate, or log-off, thereby causing an accounting-stop which > > contains all the information like how long they were logged in for, amount > > of data moved, etc. This is because RADIUS is meant for dial-up work - the > > fact that people have just managed to make it work elsewhere, particularly > > for authentication doesn't mean to say it's the best way to handle this sort > > of thing. > > Hrm... OK. Thanks for the explanations. My knowledge of RADIUS only > extends as far as "It's used to do authentication and accounting" :-) > > > There is a need for this sort of stuff, but in an ISP context, you're going > > to be able to get it off the RADIUS accounting from the dial-up port. In > > this context there is a clear start and end to a session. In the situation > > you're talking about, we're talking more 'hot-desking', and users may share > > machines, or the end of a session might not be as easily visible to the > > proxy. > > Yeah, a pain, eh? The more I read this, the more I think RADIUS isn't > the most appropriate solution for this particular problem. > > > The only way I can think of reliably doing this is to take a list of network > > login/logoff times and your bandwidth figures taken off the switch, or > > whatever, and consider correlating the two - a Perl script to do this > > shouldn't be more than an afternoon's work. :-) > > Again, it's a matter of differentiating between general traffic and > Internet traffic, usernames, machines, etc. > > > In fact, I'm relatively new to Squid, but having just looked around the > > logging it does, you could actually correlate the Squid logs with the user > > login/logoff logs quite successfully. As to how you then stop a user > > leeching bandwidth automatically, is another question... You might however > > want to take a look at: > > [ ... ] > > We're currently using our own patched version of SquidGuard to stop > people after they've used their quota. > > As to SQUID's logon/logoff's, I didn't think they existed in the sense > you've mentioned here. Each HTTP request is marked with the username of > the authenticated client. There isn't any marked "start" and/or "stop". > > [ ... ] > > > If I think of any other way of doing this, I'll post back, but I'm sure > > there are others around here that will have ideas. > > Thanks, your help is greatly appreciated :-) > > I've been digging through the SQUID source code this evening, and I had > a thought. src/logfile.c contains the functions that src/access_log.c > uses to write the log information to $PREFIX/logs/access.log. If one was > to engineer src/logfile.c to write to somewhere like, say, a database, > you'd be half-way there. > > Doing this creates several other things to think about. src/logfile.c is > used by more than just src/access_log.c (i.e., it's used to generate > more than just $PREFIX/logs/access.log). > > I suppose it could be made to work in such a way that only > src/access_log.c sent logs to the database, either in src/logfile.c or > by changing the functions that src/access_log.c calls. I think the > former would be a cleaner way of doing things, having only one file that > needs patching. > > Then there's the issue of performance. I suppose on a SMP machine it's > less of a worry, but logging directly to a database may prove to by > fundementally slow. Some thought would have to be put into the coding to > ensure as few TCP connections to the SQL server are made as possible. > > *Sigh*. Some thinking is going to be required on my part methinks.[1] > > - andrew > > [1] Thinking? What's that? [ :-) ] > > -- > void signature () { > cout << "Andrew Reid -- andrew.reid@plug.cx" << endl ; > cout << "Cell: +61 401 946 813" << endl; > cout << "Quidquid latine dictum sit, altum viditur" << endl; > } > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-isp" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-isp" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?002001c12984$67378c00$0bdea8c0>