You have an interesting command line scripts aproach if I understand correctly.
The only improvement I see is that you could substitute most of the shell scripts with php ones updating the external radius server and database with most of the info you need and send the emails and maybe even skip the administrator intervention for every user. But this is a matter of tools preference. Thx for the info. Cheers, On Thu, Apr 26, 2012 at 10:23 PM, Christian Neumann <cneum...@pih.org> wrote: >> Date: Wed, 25 Apr 2012 14:49:14 +0300 >> From: NorthPole <morfeas3...@gmail.com> >> To: pfSense support and discussion <list@lists.pfsense.org> >> Subject: Re: [pfSense] Quick Thanks from a Happy user >> Message-ID: >> <CA+wR77o_jGyMi3F9u-xooHXeWXazdVa1SgcFY3m3=Sq=fzk...@mail.gmail.com> >> Content-Type: text/plain; charset=ISO-8859-1 >> >> Hi >> >> This is a very interesting application and congratulations on making it! >> If you can It would be very interesting if you could provide details >> in the following. >> >>> - Mail notifications for important events (new user signed up, weekly RRD >>> stats, reboots, ...) > > Various solutions: We have a custom portal page where every new user (system) > is redirected to. From there a couple of shell scripts get the IP, Hostname > and Mac-Address together with the values that the user entered on the portal > page (name, email, ack'ed the terms of usage, organization he/she belongs > to). At the end of this process a shell script sends out an email to a group > of admins with these details. > > For the weekly RRD stats (we are just interested in the traffic graphs) we > use the package 'mailreport'. > > Startup/reboot notifications are send via a simple cronjob with the time > '@reboot'. > > For all of this we have installed some perl libs to simplify the email > handling. Ideally this should be done in a PHP extension / pfSense package, > but I didn't go that far yet. > >>> - 'Jail' for misbehaving systems and a HTTP redirecting to let them know > > Misbehaving systems could be simply slowed-down to a minimum by the bandwidth > limits of the Captive Portal (e.g. just 1 Kbit/s for up- and download). But > this way the user wouldn't know that his system is blocked. In case we want > them to know what happened, we redirect them through a Squid config with the > package squidGuard to a dedicated page for this system. This page then > indicates what happened and why. As this is the only white-listed page in > this particular SquidGuard category, the user (with this system) can't go > anywhere else. > >>> - Reports with last time systems were connected (usefull for cleanup RADIUS >>> users) > > With the options 'Reauthenticate connected users every minute' of the Captive > Portal, the freeRADIUS logs contain detailed information about how and when > systems connected. Again a couple of shell scripts dig through this data and > provide some useful stats. With the build-in freeRADIUS and our ~100 > systems/day we have hit a limit, so that we had to deactivate the ongoing > RADIUS accounting information for now. It seems like we have to move to a > dedicated freeRADIUS installation in order to bypass this. But the idea will > remain the same. It might also be that the freeRADIUS 2 package is providing > some of these features. > >>> - Support for external monitoring solutions of internal network devices > > We have dedicated nTop and Zabbix systems running outside of the pfSense box > (for us pfSense is the inner firewall between our server subnet and all > client subnets). But many network devices are inside of the client subnets, > so depending on the devices (printer, access point, switch, server), what we > want to monitor, and which access Zabbix needs to the devices, we have > created a bunch of firewall rules and port forwards to selectively allow > access. Maybe the zabbix-proxy package helps to make this simpilier, but we > haven't looked so deep. > >>> - Default (low) speed group for unknown users through Captive portal >>> bandwidth restriction > > Whenever a user/system is going through the self-signup process (see above), > we assign the system with low bandwidth limits. This way someone can connect, > but can't consume much of our scarce bandwidth. As we receive an email > whenever this happened, we can then check if the system should have > more/faster access to the network and 'promote' it through assigner higher > bandwidth limits within freeRADIUS. > >> did you use an external non custom application for these and if yes which? > > I could see that some of our features eventually make its way into a clean > pfSense package, but we haven't had the time and skills to investigate deeper > here. So there are a couple of manual installation and config tasks required, > before this all works together. I'm open for any suggestions if or how this > could be made more usable. > > Cheers, > christian > _______________________________________________ > List mailing list > List@lists.pfsense.org > http://lists.pfsense.org/mailman/listinfo/list _______________________________________________ List mailing list List@lists.pfsense.org http://lists.pfsense.org/mailman/listinfo/list
