Add users to FreeRadius USERS file without restart
-
Hi,
I implemented the pfsense with fr2 and freeradius list of 30k codes yesterday in our test hotel. The machine handles the number of users and codes with no problems and the cp page runs fine. There are just 2 things that i'm stuck with maybe you can help.
1. the "users" file gets reset every time i restart the box. I generated a custom users file not through the gui and uploaded it with all the correct information and it works but when i restart the box it gets erased. Will the method you posted earlier altering freeradius.inc line 571 prevent this from happening?
2. i've tried all the methods below and still having the problems with the code timing when using start/stop acct from the cp. I tried to remove all the idle/session timeouts from fr2 and cp page. Also removed th eoption to use the radius session time out and there are no session timeouts on the user.
However what i did notice is that the first session time that is sent is not correct. it should send 60 second increments but the first time packet send 40 seconds and from there it throws the entire time off and it keeps increasing. So let's say that every time it should be 60 the first is 40 then the second is 100, 160, 220, etc. do you know where this is coded? maybe if we change the variable to a static number of 60 it will correct the problem? just an idea and what i noticed.
Also with that the only way i can keep the code timer correct is if i switch to interim accounting but then the fr2 session time never decreases and thus hinders the valid time useless because it would never expire.
-
1.)
Remove or comment the two lines I posted in the posts before if you want to prevent that any process overwrites your "users" file.2.)
Try the patch/changes from ermal or find the corresponding file and lines:
http://redmine.pfsense.org/issues/2164In this patch ermal is reducing the time every accounting stop by 60 seconds.
-
i've never done the patch before and so what is the command i'll need to run to add the patch from that cp.diff? Sorry i'm not the greatest with these BSD commands but inside the files i can find my way around.
I did comment out the lines and now all is ok with the users file.
Thanks!
-
I am no BSD guy, too ;-)
Find the file "captiveportal.inc"
Probably modify the file by hand would be the easiest way:
The lines with an "-" in front need to be removed.
The lines with an "+" in front need to be addedWhat the patch - as far as I understand it does is:
It just substracts 60 seconds from the stop-time.$stop_time - 60,You said that the first accounting stop packet sends 40 seconds instead of 60. The reason could be this comment:
/* XXX: *start time* Timer is static since prunce records is every 60secs. Max it needs to be configurable with prune records interval */ -
Wouldn't it still be easier to install the MySQL server by hand inside pfSense so you can leave the current sources the way they are? Setting up users from outside the pfSense GUI is so much easier using a "realtime" DB setup.
-
nachtfalke - i tried both those changes and everything is ok for the moment!! thanks for your help with this. While updating the captiveportal.inc from the redmine link i saw that you posted a fix for the rladump error that comes up on the logs. Where do you add the line exec("sleep 1");? thanks!
If found a fix for an other "bug":
rlm_radutmp: Logout for NAS CP port 76, but no Login record
rlm_radutmp: Login entry for NAS CP port 76 wrong orderThis is happening because the accounting stop/start packets are to short after another. I added this line:
exec("sleep 1");
fesoj- would but i'm running this on a CF card on embedded device. Don't think it's too smart to use mysql on a CF card because of the amount of writes it's required. So far with these latest patches the USERS file of 30k users is working great no problems and loads really quick. It's relativily small 1.3MB. However if you have any other ideas of how i can improve this system i would be glad to hear them. I am just testing all of the solution at the moment to see if it will hold up before we deploy to our different sites.
-
You may be right. My hotel solutions are hosted inside Atom boxes with real disks, so this is not an issue here.
On the other hand, maybe not. If the CF card is large enough and there is enough RAM, it might still work. Only interim updates require a lot of writes.
-
(…)
Only interim updates require a lot of writes.For CP on pfsense this is not correct because the updates - no matter if interim or stop/start will be send every 60 seconds. So in this case there will be no difference.
Unfortunately there are some thing which pfsense CP does not support or does not support correctly according RADIUS protocol. But as far as I can see that, there are some improvements made on CP on the new version 2.1.
@fsantaana
You are right - on redmine I posted this exec("sleep 1"); command … but I opend these tickets in the past when I developed the freeradius2 package and tried to test these features. I am not using this at the moment so I need some time to remember where I added this line ;-) -
Ok, I think I found the part where I probably added this in the past ::)
This is the part in the captiveportal.inc which generates the accouting stop/start packets.
First part is accouting stop and then there is immediatly an accounting start. In most cases this is to short after another so I added this one second of sleep time. Not sure if there is any other value shorter than one second which can be used or not. This is the actual code on github:if ($config['captiveportal']['reauthenticateacct'] == "stopstart") { /* stop and restart accounting */ RADIUS_ACCOUNTING_STOP($cpentry[1], // ruleno $cpentry[4], // username $cpentry[5], // sessionid $cpentry[0], // start time $radiusservers, $cpentry[2], // clientip $cpentry[3], // clientmac 10); // NAS Request exec("/sbin/ipfw table 1 entryzerostats {$cpentry[2]}"); exec("/sbin/ipfw table 2 entryzerostats {$cpentry[2]}"); RADIUS_ACCOUNTING_START($cpentry[1], // ruleno $cpentry[4], // username $cpentry[5], // sessionid $radiusservers, $cpentry[2], // clientip $cpentry[3]); // clientmacSo probably adding the sleep between this two lines would help:
exec("/sbin/ipfw table 2 entryzerostats {$cpentry[2]}"); exec("sleep 1"); RADIUS_ACCOUNTING_START($cpentry[1], // rulenoRemember:
This will make accouting a little bit inaccurate over a long distance because you lose one second every minute which will not be counted. In theory you could try to use:$stop_time - 59,instead of:
$stop_time - 60,Not sure if there are side effects or not.
If you calculate one day which has 24*60 accounting stop/start packets you lose 24min or your customer wins 24min per day ;-)PS: If this will help you and fix your problem(s) - It would be nice to comment this on redmine what you changed, on which version of pfsense and what it fixed so that there will be hopefully a commit on future pfsense 2.0.x and pfsense 2.1.x versions.
-
Nachtfalke:
whether writing to MySQL results in any disk activity is largely a matter which storage engine is used. There's none if the MEMORY engine is used, though this is vulnerable to various hardware and power problems. Maybe a temporary copy to a disk based format make this usable.
I'll try to measure the disk activity on my boxes with iostat or s.th. similar to see whether FreeRadius on a pfSense box really triggers a lot of disk activity. I could report later about this.
Except for the transferred number of octets FR basically works for my setups.
-
UPDATE Everything between the FR2 and the CP are working great. I am able to manage the users and they are now only decreasing 60 seconds at a time. I am thinking of increasing the stop time to 61 and adding the exec sleep 1 so it removes that rwadump error and still gives the customer the full time. If i got it right from your explanation that leaving it at 60 and adding the sleep the customer would lose 1 second of time so in a full day it would be 24 min. But what if we compensate with the 1 second in the stop time to 61 and then they would actual start again from 60. This is just theory so i'm not sure.
Also a big problem i'm seeing now is the logging of the radius server is eating up all of the /var filesystem and it's causing my DHCPD to stop giving ip's since it can't write to the database. Is this somethign that you have seen before? I'm looking into reducing the logs since I don't need too much logging.
Maybe there is a way to decrease the logging of FR2 or increase the /var filesystem size. The ideal would be to have a reset of the logs every 8 hours or so.
Jan 22 17:02:46 kernel: pid 58856 (dhcpd), uid 1002 inumber 22 on /var: filesystem full Jan 22 17:02:49 kernel: pid 58856 (dhcpd), uid 1002 inumber 23 on /var: filesystem full Jan 22 17:02:56 kernel: pid 58856 (dhcpd), uid 1002 inumber 22 on /var: filesystem full Jan 22 17:03:11 kernel: pid 58856 (dhcpd), uid 1002 inumber 23 on /var: filesystem full Jan 22 17:03:34 kernel: pid 58856 (dhcpd), uid 1002 inumber 22 on /var: filesystem full Jan 22 17:04:01 kernel: pid 58856 (dhcpd), uid 1002 inumber 23 on /var: filesystem full Jan 22 17:08:33 kernel: pid 58856 (dhcpd), uid 1002 inumber 22 on /var: filesystem fullJan 22 17:02:45 dhcpd: DHCPDISCOVER from 00:21:5a:f7:76:67 (CGASWS9189) via em2 Jan 22 17:02:45 dhcpd: unexpected ICMP Echo Reply from 10.1.3.254 Jan 22 17:02:46 dhcpd: DHCPOFFER on 172.14.255.249 to 00:21:5a:f7:76:67 (CGASWS9189) via em2 Jan 22 17:02:46 dhcpd: write_lease: unable to write lease 172.16.0.135 Jan 22 17:02:46 dhcpd: DHCPREQUEST for 172.14.255.249 (172.14.0.1) from 00:21:5a:f7:76:67 (CGASWS9189) via em2: database update failed Jan 22 17:02:49 dhcpd: write_lease: unable to write lease 172.16.0.135$ df -h Filesystem Size Used Avail Capacity Mounted on /dev/ufs/pfsense0 908M 337M 498M 40% / devfs 1.0K 1.0K 0B 100% /dev /dev/md0 38M 632K 35M 2% /tmp /dev/md1 58M 58M -4.6M 109% /var /dev/ufs/cf 49M 1.1M 44M 2% /cf devfs 1.0K 1.0K 0B 100% /var/dhcpd/dev$ du -k -h -d 1 /var 2.0K /var/.snap 4.0M /var/db 6.0K /var/tmp 50K /var/etc 38K /var/run 50M /var/log 4.0K /var/at 2.0K /var/empty 3.3M /var/dhcpd 4.0K /var/cron 58M /var -
@fsantaana
I think you are right. using 61 instead of 59 will make it accurate for the user.Logrotation:
Possibilities are:
a) Disable logging
b) logging to syslog - should be cleared/limited by pfsense 2000 lines max - I think but not sure
c) logging to external syslog server
d) logging to /var/log/radiusd.log and create a small script which does a log rotation of the last 5.000 lines every night and run this with cron. Example could be the one from squidguard:#!/bin/sh # Rotates radiusd.log file tail -5000 /var/log/radiusd.log > /var/log/radiusd.log.0 tail -5000 /var/log/radiusd.log.0 > /var/log/radiusd.log rm -f /var/log/radiusd.log.0 -
I tried with the time to 61 and it's reducing an extra second. When I was doing the count i realized it doesn't matter if the sleep is 1 because it's only using the session time. So in reality it just takes an extra second for the account start to load and doesn't affect the session time which is what it uses. The point is that the sleep 1 correct the logging issue and that is now ok!
I come to find what was keep all the space in /var/log is the detail-YYYYMMDD file in the /var/log/radacct/IP Is there a way to remove these? It's the detail of each accounting start/stop packet throughout the day and i have about 200 simultaneous connections during those days which leads to a ~20MB file each day.
I'm trying to create a cron job that will erase the detail-YYYYMMDD that is older that 1 week. Do you have any suggestions on purging these old detail files? can i even purge them?
Also is there a way to see the Session Timeout (time remaining) of the users without them being logged in? I know i can add a line to the logging that will show me the Session Timeout remaining but what if they are not logged in? Is there a way i can pull that info from there? Would this be outside the scope of the USERS file and more into SQL for accounting?
Thanks
-
Hi,
perhaps radwho command can give you some information:
http://freeradius.org/radiusd/man/radwho.htmlFor accounting - go to freeradius.inc a search this part:
# # Accounting. Log the accounting data. # accounting { # # Create a 'detail'ed log of the packets. # Note that accounting requests which are proxied # are also logged in the detail file. detailThen comment the line with "detail" - this will probably disable logging of accounting information.
A better way could be to modify this file to make the file rotation every week or something like that:
http://freeradius.org/radiusd/man/rlm_detail.txtI suppose somewhere in ../raddb/modules/ is this file and we should modify it a little bit.
Instead of this:
%{radacctdir}/%{Client-IP-Address}/detail-%Y%mtry something like that:
%{radacctdir}/%{Client-IP-Address}/detail-%Y%m%d -
Nacht thanks for all your help you are awesome!!
I tried those changes in the detail file and it doesn't help me too much as it just generates new files. What i need is to flush the files as to avoid having such a large log sizes.
I managed this with a simple cron job every week to delete all the detail files in /var/log/radacct/IP-Address/ this works for what i need and it's great.
I have another question- Is there a way to set timeouts on individual users? I know there is the session-timeout that will force them to re-login at the specific time set. I was looking for something like an idle timeout per user instead of a global one in the CP page.
Also i have done the testing as you said earlier and all signs look great! I have a USERS file with 25K Lines and the users are authenticated very quickly! Alot faster than what i expected. I haven't seen any performace issues with this. I always have approx 30-40 simultaneous connections at this current site and everything works great. I am now deploying to 2 other sites and will post the results from those. They will have heavier usage than the current one.