Re: IP Accounting and 2.4
On Tue, Jul 03, 2001 at 05:44:42PM -0500, Chad C. Walstrom wrote: I'm interested in finding out what others have done for IP accounting for a large number of customers. (Rate limiting and traffic shaping We use CISCO and now have moved our accounting to CISCO's Netflow, i.e. the routers export a list of all connctions with their consumed bytes every x minutes (a lot of data..). But as you're using a linux router I would suggest you the net-acct package that's available as .deb, too. It does pretty much the same as netflow and should be the right thing for you. bye, -christian- -- You know you're a nerd when your os uptime is longer than you've ever had a girlfriend. ([EMAIL PROTECTED]) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: IP Accounting and 2.4
On Tue, Jul 03, 2001 at 05:44:42PM -0500, Chad C. Walstrom wrote: I'm interested in finding out what others have done for IP accounting for a large number of customers. (Rate limiting and traffic shaping We use CISCO and now have moved our accounting to CISCO's Netflow, i.e. the routers export a list of all connctions with their consumed bytes every x minutes (a lot of data..). But as you're using a linux router I would suggest you the net-acct package that's available as .deb, too. It does pretty much the same as netflow and should be the right thing for you. bye, -christian- -- You know you're a nerd when your os uptime is longer than you've ever had a girlfriend. ([EMAIL PROTECTED])
Re: IP Accounting and 2.4
On Tue, 3 Jul 2001, Chad C. Walstrom wrote: snip Now, I searched the archives here and took someone's [7] suggestion to look at fiprad[8]. However, it's kernel module and patch are for the 2.2.14 kernel alone. The last update to the website looks to be in March of 2000. I was intrigued because of the fiprad daemon that inserted accounting for ipblocks (VERY nice way to configure by the way), directly into MySQL (not my favorite, but not a problem). I was also intrigued by the efficient logic for logging the packets (no nest of ipchains rules). I'm interested in finding out what others have done for IP accounting for a large number of customers. (Rate limiting and traffic shaping aside -- a topic for another day.) If anyone else is interested in fiprad for the 2.4 kernel, let me know. I'll send off a copy of this to the fiprad developers and see if they've worked on it since May 2000. snip Hello. Unfortunately we havent had so much time over to work on fipra, but now it is summer here and vacation times is upon us. So right now I am in the process of rewriting it to 2.4.x kernels and with the netfilter structure it seems possible that it can be totally modular finally. Hopefully we'll have some alpha release done in a week or two for the daring. Regards Roger Abrahamsson PS. We have run tests with fipra, and a PII-350 managed about 30mbit of continous throughput while logging was activated for 3000 ip adresses. (That was with the 2.2.14 kernel.) - Roger Abrahamsson, Sys/Net Admin, Obbit AB Phone: (+46)(0)90 133310Fax:(+46)(0)90 133370 -
Re: IP Accounting and 2.4
On Wed, Jul 04, 2001 at 07:10:56PM +0200, Alexander Reelsen wrote: On Tue, Jul 03, 2001 at 05:44:42PM -0500, Chad C. Walstrom wrote: The powers that be, those that provide my paycheck, didn't like the ipac-ng graphics and wanted something prettier. Welcome to the club. :) You might have heard from hoth, an rrdtool based accounting tool for ipchains. Incidentally written by me ;-) I had heard of hoth[1], but I didn't really get a chance to check it out. Partly because I did notice that you said it wasn't ready for Linux 2.4 yet. So, if you have either patience or you're able to hack perl you're invited to join me and to make the perfect[tm] rrdtool based iptables accounting tool. I'll take a look at it and let you know. It's obvious that I'll have to hack on something, so I may as well help you. ;-) Last, but not leased you asked for intelligent accounting rules. My hint would be to have three chains, acct_in, acct_out, acct_both and to have tree style subchains for networks like (not an ascii art freak, sorry) The sub-chains for subnets is a very good idea. I had considered that as well, but I think that even a few stops for any packet in an accounting chain is a bit too much. We should really be able to use one rule that shoves a copy of each packet into a non-blocking que where it can be fetched and analyzed by some userspace program. I've not looked nor run any benchmarks to support this idea, but it seems logical enough. That's partly why I was so intrigued by fiprad[2]. I do agree that tree-style rules are nice, but I really only want to use them for a useful purpose, such as blocking @home users. ;-) (I wish.) -- Chad Walstrom [EMAIL PROTECTED] | a.k.a. ^chewie http://www.wookimus.net/| s.k.a. gunnarr Key fingerprint = B4AB D627 9CBD 687E 7A31 1950 0CC7 0B18 206C 5AFD PGP signature
Re: IP Accounting and 2.4
On Wed, Jul 04, 2001 at 02:52:50PM +0200, Russell Coker wrote: How do customers connect to you? If they are using any decent terminal server device then it should send accounting packets to the RADIUS server that list the number of bytes and packets sent and received. We have some dialup users, but not all of our clients authenticate against the RADIUS server. I don't think I'm at liberty to discuss too much about it at this point, partially out of embarrasment, partially out of NDA. Needless to say, the most practical way of monitoring useage is through the core router, a Linux potato box with a 2.4 kernel. Everything must pass through the core router, and therefore it is the only place we can guarantee that we'll account for each packet. The tree-based approach to packet matching has obvious advantages, but as I noted in a previous email, I don't place gleaning packet info in the same priority as I do throughput or true firewalling. Up to this point, I've very little experience with radius servers, but I'm interested in finding out about these accounting packets. Would it be worth our while to develop a Linux kernel/userspace equivalent? -- Chad Walstrom [EMAIL PROTECTED] | a.k.a. ^chewie http://www.wookimus.net/| s.k.a. gunnarr Key fingerprint = B4AB D627 9CBD 687E 7A31 1950 0CC7 0B18 206C 5AFD PGP signature
Re: IP Accounting and 2.4
On Thu, 5 Jul 2001 16:41, Chad C. Walstrom wrote: On Wed, Jul 04, 2001 at 02:52:50PM +0200, Russell Coker wrote: How do customers connect to you? If they are using any decent terminal server device then it should send accounting packets to the RADIUS server that list the number of bytes and packets sent and received. We have some dialup users, but not all of our clients authenticate against the RADIUS server. I don't think I'm at liberty to discuss too much about it at this point, partially out of embarrasment, partially out of NDA. Sounds like you wrote your own mgetty type program to do it. I did the same in 1997 and am still in the process of migrating the clients who use it to Portslave... Up to this point, I've very little experience with radius servers, but I'm interested in finding out about these accounting packets. Would it be worth our while to develop a Linux kernel/userspace equivalent? Why develop a new RADIUS server when the Cistron one is quite good and the FreeRADIUS project will be even better when they fix the last few bugs. Also a kernel-space RADIUS server makes no sense. On a network with 500,000 users you still only get about 400 RADIUS packets per second which is not enough to need a kernel version. -- http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/projects.html Projects I am working on http://www.coker.com.au/~russell/ My home page -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: IP Accounting and 2.4
On Thu, Jul 05, 2001 at 04:58:45PM +0200, Russell Coker wrote: Sounds like you wrote your own mgetty type program to do it. I did the same in 1997 and am still in the process of migrating the clients who use it to Portslave... No. You didn't read between the lines. Not all of our customers use dialup/isdn. Not all of our customers have the ability to authenticate against the current Livingston RADIUS server. End of sentance. Why develop a new RADIUS server when the Cistron one is quite good and the FreeRADIUS project will be even better when they fix the last few bugs. You misunderstand me. If we need to use a RADIUS server, believe you me, I won't reinvent the wheel. Also a kernel-space RADIUS server makes no sense. On a network with 500,000 users you still only get about 400 RADIUS packets per second which is not enough to need a kernel version. If I understand this correctly, Cisco routers provide accounting packets. They do not run RADIUS servers. RADIUS servers run on servers; they authenticate and collect data. If my Linux router is not a server, or acting as one, why would it be a bad thing to provide the same features as a Cisco router, i.e. sending account/RADIUS packets to a radius server? We've got so many hacks to do IP accounting for Linux to fill an obvious need, why not standardize? Please understand this: we cannot use RADIUS for all of our users. We could care less what the dialup users do for bandwidth consumption. The limits of a dialup connection alone are sufficient for bandwidth limitation. The only viable solution to cover those clients we really care about is for IP accounting on the core router. End of problem domain. Association of byte counts of IP addresses to user accounts will be resolved at the database level. Collection of bandwidth useage data is what is important here. How it's done is limited to the Linux kernel in one way or another: iptables, iptables+userspace daemon, ethernet tap device (ntop) + MySQL/Postgresql database storage, etc. -- Chad Walstrom [EMAIL PROTECTED] | a.k.a. ^chewie http://www.wookimus.net/| s.k.a. gunnarr Key fingerprint = B4AB D627 9CBD 687E 7A31 1950 0CC7 0B18 206C 5AFD PGP signature
Re: IP Accounting and 2.4
On Wed, Jul 04, 2001 at 07:10:56PM +0200, Alexander Reelsen wrote: On Tue, Jul 03, 2001 at 05:44:42PM -0500, Chad C. Walstrom wrote: The powers that be, those that provide my paycheck, didn't like the ipac-ng graphics and wanted something prettier. Welcome to the club. :) You might have heard from hoth, an rrdtool based accounting tool for ipchains. Incidentally written by me ;-) I had heard of hoth[1], but I didn't really get a chance to check it out. Partly because I did notice that you said it wasn't ready for Linux 2.4 yet. So, if you have either patience or you're able to hack perl you're invited to join me and to make the perfect[tm] rrdtool based iptables accounting tool. I'll take a look at it and let you know. It's obvious that I'll have to hack on something, so I may as well help you. ;-) Last, but not leased you asked for intelligent accounting rules. My hint would be to have three chains, acct_in, acct_out, acct_both and to have tree style subchains for networks like (not an ascii art freak, sorry) The sub-chains for subnets is a very good idea. I had considered that as well, but I think that even a few stops for any packet in an accounting chain is a bit too much. We should really be able to use one rule that shoves a copy of each packet into a non-blocking que where it can be fetched and analyzed by some userspace program. I've not looked nor run any benchmarks to support this idea, but it seems logical enough. That's partly why I was so intrigued by fiprad[2]. I do agree that tree-style rules are nice, but I really only want to use them for a useful purpose, such as blocking @home users. ;-) (I wish.) -- Chad Walstrom [EMAIL PROTECTED] | a.k.a. ^chewie http://www.wookimus.net/| s.k.a. gunnarr Key fingerprint = B4AB D627 9CBD 687E 7A31 1950 0CC7 0B18 206C 5AFD pgpwKpeYVyFV6.pgp Description: PGP signature
Re: IP Accounting and 2.4
On Wed, Jul 04, 2001 at 02:52:50PM +0200, Russell Coker wrote: How do customers connect to you? If they are using any decent terminal server device then it should send accounting packets to the RADIUS server that list the number of bytes and packets sent and received. We have some dialup users, but not all of our clients authenticate against the RADIUS server. I don't think I'm at liberty to discuss too much about it at this point, partially out of embarrasment, partially out of NDA. Needless to say, the most practical way of monitoring useage is through the core router, a Linux potato box with a 2.4 kernel. Everything must pass through the core router, and therefore it is the only place we can guarantee that we'll account for each packet. The tree-based approach to packet matching has obvious advantages, but as I noted in a previous email, I don't place gleaning packet info in the same priority as I do throughput or true firewalling. Up to this point, I've very little experience with radius servers, but I'm interested in finding out about these accounting packets. Would it be worth our while to develop a Linux kernel/userspace equivalent? -- Chad Walstrom [EMAIL PROTECTED] | a.k.a. ^chewie http://www.wookimus.net/| s.k.a. gunnarr Key fingerprint = B4AB D627 9CBD 687E 7A31 1950 0CC7 0B18 206C 5AFD pgpRREr6y8O3l.pgp Description: PGP signature
Re: IP Accounting and 2.4
On Thu, 5 Jul 2001 16:41, Chad C. Walstrom wrote: On Wed, Jul 04, 2001 at 02:52:50PM +0200, Russell Coker wrote: How do customers connect to you? If they are using any decent terminal server device then it should send accounting packets to the RADIUS server that list the number of bytes and packets sent and received. We have some dialup users, but not all of our clients authenticate against the RADIUS server. I don't think I'm at liberty to discuss too much about it at this point, partially out of embarrasment, partially out of NDA. Sounds like you wrote your own mgetty type program to do it. I did the same in 1997 and am still in the process of migrating the clients who use it to Portslave... Up to this point, I've very little experience with radius servers, but I'm interested in finding out about these accounting packets. Would it be worth our while to develop a Linux kernel/userspace equivalent? Why develop a new RADIUS server when the Cistron one is quite good and the FreeRADIUS project will be even better when they fix the last few bugs. Also a kernel-space RADIUS server makes no sense. On a network with 500,000 users you still only get about 400 RADIUS packets per second which is not enough to need a kernel version. -- http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/projects.html Projects I am working on http://www.coker.com.au/~russell/ My home page
Re: IP Accounting and 2.4
On Thu, Jul 05, 2001 at 04:58:45PM +0200, Russell Coker wrote: Sounds like you wrote your own mgetty type program to do it. I did the same in 1997 and am still in the process of migrating the clients who use it to Portslave... No. You didn't read between the lines. Not all of our customers use dialup/isdn. Not all of our customers have the ability to authenticate against the current Livingston RADIUS server. End of sentance. Why develop a new RADIUS server when the Cistron one is quite good and the FreeRADIUS project will be even better when they fix the last few bugs. You misunderstand me. If we need to use a RADIUS server, believe you me, I won't reinvent the wheel. Also a kernel-space RADIUS server makes no sense. On a network with 500,000 users you still only get about 400 RADIUS packets per second which is not enough to need a kernel version. If I understand this correctly, Cisco routers provide accounting packets. They do not run RADIUS servers. RADIUS servers run on servers; they authenticate and collect data. If my Linux router is not a server, or acting as one, why would it be a bad thing to provide the same features as a Cisco router, i.e. sending account/RADIUS packets to a radius server? We've got so many hacks to do IP accounting for Linux to fill an obvious need, why not standardize? Please understand this: we cannot use RADIUS for all of our users. We could care less what the dialup users do for bandwidth consumption. The limits of a dialup connection alone are sufficient for bandwidth limitation. The only viable solution to cover those clients we really care about is for IP accounting on the core router. End of problem domain. Association of byte counts of IP addresses to user accounts will be resolved at the database level. Collection of bandwidth useage data is what is important here. How it's done is limited to the Linux kernel in one way or another: iptables, iptables+userspace daemon, ethernet tap device (ntop) + MySQL/Postgresql database storage, etc. -- Chad Walstrom [EMAIL PROTECTED] | a.k.a. ^chewie http://www.wookimus.net/| s.k.a. gunnarr Key fingerprint = B4AB D627 9CBD 687E 7A31 1950 0CC7 0B18 206C 5AFD pgp73tSphiDJr.pgp Description: PGP signature
Re: IP Accounting and 2.4
On Wed, 4 Jul 2001 00:44, Chad C. Walstrom wrote: OK. New job, new problems. Whereas I used to be able to ignore systems administration and networking, it's now my focus. Our ISP wants to be able to record IP traffic and bandwidth useage for each of its users, a common need amongst ISP's. How do customers connect to you? If they are using any decent terminal server device then it should send accounting packets to the RADIUS server that list the number of bytes and packets sent and received. If they connect via a Linux terminal server then if you use the latest version of my Portslave package (which isn't in Debian yet because I haven't fixed all the bugs) then it'll log bytes (logging packets requires changes to pppd). -- http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/projects.html Projects I am working on http://www.coker.com.au/~russell/ My home page -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: IP Accounting and 2.4
And if you want an accounting system to go with Portslave or just plain pppd's you can use ACUA, http://acua.ebbs.com.au/ -- Regards, Robert Davidson. On Wed, Jul 04, 2001 at 02:52:50PM +0200, Russell Coker wrote: On Wed, 4 Jul 2001 00:44, Chad C. Walstrom wrote: OK. New job, new problems. Whereas I used to be able to ignore systems administration and networking, it's now my focus. Our ISP wants to be able to record IP traffic and bandwidth useage for each of its users, a common need amongst ISP's. How do customers connect to you? If they are using any decent terminal server device then it should send accounting packets to the RADIUS server that list the number of bytes and packets sent and received. If they connect via a Linux terminal server then if you use the latest version of my Portslave package (which isn't in Debian yet because I haven't fixed all the bugs) then it'll log bytes (logging packets requires changes to pppd). -- http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/projects.html Projects I am working on http://www.coker.com.au/~russell/ My home page -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: IP Accounting and 2.4
On Wed, 4 Jul 2001 00:44, Chad C. Walstrom wrote: OK. New job, new problems. Whereas I used to be able to ignore systems administration and networking, it's now my focus. Our ISP wants to be able to record IP traffic and bandwidth useage for each of its users, a common need amongst ISP's. How do customers connect to you? If they are using any decent terminal server device then it should send accounting packets to the RADIUS server that list the number of bytes and packets sent and received. If they connect via a Linux terminal server then if you use the latest version of my Portslave package (which isn't in Debian yet because I haven't fixed all the bugs) then it'll log bytes (logging packets requires changes to pppd). -- http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/projects.html Projects I am working on http://www.coker.com.au/~russell/ My home page
Re: IP Accounting and 2.4
And if you want an accounting system to go with Portslave or just plain pppd's you can use ACUA, http://acua.ebbs.com.au/ -- Regards, Robert Davidson. On Wed, Jul 04, 2001 at 02:52:50PM +0200, Russell Coker wrote: On Wed, 4 Jul 2001 00:44, Chad C. Walstrom wrote: OK. New job, new problems. Whereas I used to be able to ignore systems administration and networking, it's now my focus. Our ISP wants to be able to record IP traffic and bandwidth useage for each of its users, a common need amongst ISP's. How do customers connect to you? If they are using any decent terminal server device then it should send accounting packets to the RADIUS server that list the number of bytes and packets sent and received. If they connect via a Linux terminal server then if you use the latest version of my Portslave package (which isn't in Debian yet because I haven't fixed all the bugs) then it'll log bytes (logging packets requires changes to pppd). -- http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/projects.html Projects I am working on http://www.coker.com.au/~russell/ My home page -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
IP Accounting and 2.4
OK. New job, new problems. Whereas I used to be able to ignore systems administration and networking, it's now my focus. Our ISP wants to be able to record IP traffic and bandwidth useage for each of its users, a common need amongst ISP's. In my initial search, I found ipac[1] for Debian potato. It worked with the 2.2 kernels, but nothing greater. A little digging brought me to the ipac-ng[2] site at Sourceforge[3]. Three patches, a new debian/rules file, multiple debhelper support files later, a manual include directive to gcc in agents/iptables/Makefile.in, and I had a working ipac-ng 1.04 package[4] that used iptables.* The powers that be, those that provide my paycheck, didn't like the ipac-ng graphics and wanted something prettier. With ipac-ng came a few contrib scripts, one for displaying the data via mrtg[5]. The process is painfully slow and resource intensive, but workable.** sarcasm Making it scriptable is going to be fun. /sarcasm I'm interested in trying rrdtool[6] with the mrtg data, but we're not there quite yet (another step to set up the web cgi). The IP's we need to track number in the hundreds, and we're expecting to have to scale this whole operation many times over. With ipac-ng inserting two rules into iptables for each ip tracked, the tables are starting to look REAL ugly. I fear that performance on the router is going suffer (as if it isn't already). Now, I searched the archives here and took someone's [7] suggestion to look at fiprad[8]. However, it's kernel module and patch are for the 2.2.14 kernel alone. The last update to the website looks to be in March of 2000. I was intrigued because of the fiprad daemon that inserted accounting for ipblocks (VERY nice way to configure by the way), directly into MySQL (not my favorite, but not a problem). I was also intrigued by the efficient logic for logging the packets (no nest of ipchains rules). I'm interested in finding out what others have done for IP accounting for a large number of customers. (Rate limiting and traffic shaping aside -- a topic for another day.) If anyone else is interested in fiprad for the 2.4 kernel, let me know. I'll send off a copy of this to the fiprad developers and see if they've worked on it since May 2000. Footnote * 1.05, the latest of the ipac-ng thread, had problems parsing the config file. In the interest of time alone, I dropped down one version. References -- 1. http://packages.debian.org/stable/main/ipac.html 2. http://ipac-ng.sourceforge.net/ 3. http://sf.net 4. *.dsc available upon request 5. http://packages.debian.org/stable/main/mrtg.html 6. http://packages.debian.org/stable/main/rrdtool.html 7. http://lists.debian.org/debian-isp-0101/msg00166.html 8. http://www.umplug.org/fipra/ -- Chad Walstrom [EMAIL PROTECTED] | a.k.a. ^chewie http://www.wookimus.net/| s.k.a. gunnarr Key fingerprint = B4AB D627 9CBD 687E 7A31 1950 0CC7 0B18 206C 5AFD PGP signature
IP Accounting and 2.4
OK. New job, new problems. Whereas I used to be able to ignore systems administration and networking, it's now my focus. Our ISP wants to be able to record IP traffic and bandwidth useage for each of its users, a common need amongst ISP's. In my initial search, I found ipac[1] for Debian potato. It worked with the 2.2 kernels, but nothing greater. A little digging brought me to the ipac-ng[2] site at Sourceforge[3]. Three patches, a new debian/rules file, multiple debhelper support files later, a manual include directive to gcc in agents/iptables/Makefile.in, and I had a working ipac-ng 1.04 package[4] that used iptables.* The powers that be, those that provide my paycheck, didn't like the ipac-ng graphics and wanted something prettier. With ipac-ng came a few contrib scripts, one for displaying the data via mrtg[5]. The process is painfully slow and resource intensive, but workable.** sarcasm Making it scriptable is going to be fun. /sarcasm I'm interested in trying rrdtool[6] with the mrtg data, but we're not there quite yet (another step to set up the web cgi). The IP's we need to track number in the hundreds, and we're expecting to have to scale this whole operation many times over. With ipac-ng inserting two rules into iptables for each ip tracked, the tables are starting to look REAL ugly. I fear that performance on the router is going suffer (as if it isn't already). Now, I searched the archives here and took someone's [7] suggestion to look at fiprad[8]. However, it's kernel module and patch are for the 2.2.14 kernel alone. The last update to the website looks to be in March of 2000. I was intrigued because of the fiprad daemon that inserted accounting for ipblocks (VERY nice way to configure by the way), directly into MySQL (not my favorite, but not a problem). I was also intrigued by the efficient logic for logging the packets (no nest of ipchains rules). I'm interested in finding out what others have done for IP accounting for a large number of customers. (Rate limiting and traffic shaping aside -- a topic for another day.) If anyone else is interested in fiprad for the 2.4 kernel, let me know. I'll send off a copy of this to the fiprad developers and see if they've worked on it since May 2000. Footnote * 1.05, the latest of the ipac-ng thread, had problems parsing the config file. In the interest of time alone, I dropped down one version. References -- 1. http://packages.debian.org/stable/main/ipac.html 2. http://ipac-ng.sourceforge.net/ 3. http://sf.net 4. *.dsc available upon request 5. http://packages.debian.org/stable/main/mrtg.html 6. http://packages.debian.org/stable/main/rrdtool.html 7. http://lists.debian.org/debian-isp-0101/msg00166.html 8. http://www.umplug.org/fipra/ -- Chad Walstrom [EMAIL PROTECTED] | a.k.a. ^chewie http://www.wookimus.net/| s.k.a. gunnarr Key fingerprint = B4AB D627 9CBD 687E 7A31 1950 0CC7 0B18 206C 5AFD pgpNyH5dUlcbA.pgp Description: PGP signature
