Login or Register to Ask a Question and Join Our Community


Software Releases - RSS News

FreeNIBS 3.0.0 release candidate 2 (3.x branch)

Login to Discuss or Reply to this Discussion in Our Community

 
Thread Tools Search this Thread
Special Forums News, Links, Events and Announcements Software Releases - RSS News FreeNIBS 3.0.0 release candidate 2 (3.x branch)
# 1  
Old 11-08-2008
FreeNIBS 3.0.0 release candidate 2 (3.x branch)
FreeNIBS is a loadable plugin for the FreeRADIUS radius server. FreeNIBS provides authorization, authentication, and accounting for dial-in (PPP/PPPOE/PPTP) users. It can be used for real-time prepaid and postpaid billing. FreeNIBS can bill users based on service accuration, time, traffic, and both time and traffic. FreeNIBS has very flexible settings for groups, users, and prices. All data is stored in SQL databases such as MySQl, PgSQL, and Oracle. License: GNU General Public License v2 Changes:
The database backend was completely rewritten. PostgreSQL is now used as the only database backend. Many bugs were fixed. Image

Image

More...
Login or Register to Ask a Question

Previous Thread | Next Thread
Login or Register to Ask a Question

LEARN ABOUT DEBIAN

radrelay

RADRELAY(8)							 FreeRADIUS Daemon						       RADRELAY(8)

NAME

       radrelay -- Deprecated command.

DESCRIPTION

       The  functions  of  radrelay have been added to radiusd.  One benefit is that one instance of radiusd can read multiple detail files, among
       others.

       The rlm_sql_log module does something similar, but for SQL queries.  See it's man page for details.

REPLICATION FOR BACKUPS

       Many sites run multiple radius servers; at least one primary and one backup server. When the primary goes down, most NASes detect that  and
       switch to the backup server.

       That  will  cause your accounting packets to go the the backup server - and some NASes don't even switch back to the primary server when it
       comes back up.

       The result is that accounting records are missed, and/or the administrator must jump through hoops in order to combine the different detail
       files  from  multiple servers. It also means that the session database ("radutmp", used for radwho and simultaneous use detection) gets out
       of sync.

       We solve this issue by "relaying" packets from one server to another, so they both have the same set of accounting data.

       See raddb/sites-available/buffered-sql for more information.

BUFFERING FOR HIGH-LOAD SERVERS
       If the RADIUS server suddenly receives a many accounting packets, there may be insufficient CPU power to process them all in a timely  man-
       ner.  This problem is especially noticable when the accounting packets are going to a back-end database.

       Similarly,  you	may  have  one	database  that	tracks "live" sessions, and another that tracks historical accounting data.  In that case,
       accessing the first database is fast, as it is small.  Accessing the second database many be slower, as it may contain  multiple  gigabytes
       of data.  In addition, writing to the first database in a timely manner is important, while data may be written to the second database with
       a few minutes delay, without any harm being done.

       See raddb/sites-available/copy-to-home-server for more information.

SEE ALSO

       radiusd(8), rlm_sql_log(5)

AUTHOR

       The FreeRADIUS Server Project

								  23 October 2007						       RADRELAY(8)