rlm_fastusers   [plain text]

Radius FastUsers Module


    The 'fastusers' module provides an interface for authentication
    exactly like the standard RADIUS 'users' file.  It's function is
    is exactly like that of rlm_files in FreeRadius, but it is consid-
    ably faster.  So why keep rlm_files around?  Because it's good,
    working code, and rlm_fastusers may still have bugs causing it
    to behave differently from rlm_files in very exotic cases. 


    Very simply, the module reads in the file you specify in radiusd.conf
    into a hash table and then authenticates the users out of it.  This
    is very similar to the way that passwd caching works (see README.cache),
    but because of the 'users' file format, we can specify arbitrary
    check items and reply items for each user.

    First thing you do is declare the module in radiusd.conf.  The
    default setting looks like this:

    fastusers {
       usersfile = ${confdir}/users_fast
       hashsize = 1000
       compat = no
       hash_reload = 600

    See below for a detailed explanation of the module options.
    Then you must put 'fastusers' in the 'authorize{}' section of your
    radiusd.conf.  For example:

    authorize {


    A.  usersfile

        The 'usersfile' is the path and filename of the file you want
        fastusers to read and use to authenticate users.  The format
        is exactly like that used by rlm_files.

    B.  hashsize

        The 'hashsize' variable controls how many 'buckets' or 'nodes'
        the hash table will have in it.  This allows the admnistrator
        to control how much memory is allocated to the hash table.  It
        also allows him/her to significantly impact the performance of
        the hash (for better or worse!!).

        Each hash 'bucket' is a pointer to a list of users that fit 
        the requirements to be in that bucket.  If the number of users
        is very high and the 'hashsize' is very small, that means you
        will have a large number of users per bucket.  This will 
        *negatively* impact performance.  In an ideal world, you would
        have exactly one user per bucket, but this is very unlikely to
        happen.  Conversely, if you have only 10 users in listed in the
        file and you set 'hashsize' to be 1000, you know that you have
        100 times as many buckets as users, and are therefore wasting

        So what should you shoot for?  Well, I'll tell you as a general
        rule to simply take the number of users you list in the file 
        and use that for the 'hashsize' value.  However, the frugal 
        admin could divide that number by 5 or 10 and still achieve
        much greater performance that that produced by 'users'.  Still,
        if you aren't strapped for memory, I recommend going no lower
        than 'hashsize= # of users / 3'.  It's up to you though, test
        it with different values and see how it affects performance
        (see README.testing).
        NOTE:  If you use value of '1' for hashsize, you will have 
               effectively created a singly linked list, and thus
               removed all performance benefit of using the module.
    C.  compat

        This works the same as it does in the rlm_users config section.
        It allows you to declare cistron compatibility mode when reading
        in the 'users' file.

    D.  hash_reload = 600

        Number of seconds between automatic reloading of the users
        cache.  Using this option means the module will double memory
        usage, but only while the reload is in progress.  However, it
        will eliminate blocking of user access during a reload and
        allow longer times between server HUPs.

        You can disable this feature with hash_reload = 0;


    It probably still has bugs.  Most notably, there is a small memory
    leak somewhere in the reloading code.  I suspect it's in pairlist_read
    from files.c, but I have no proof yet.  


    Author - Jeff Carneal <jeff@apex.net>