Add users to FreeRadius USERS file without restart
-
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.