0. INTRODUCTION
The 'fastusers' module provides an interface for authentication
- very similar to the standard RADIUS 'users' file. However, because
- the users are stored in a different way, there are three main
- differences to be aware of:
-
- a. It's much faster than standard 'users' authentication
- b. Order of the entries in the file does *not* matter
- c. DEFAULT entries behave differently than in 'users'
+ 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.
1. WHAT DOES IT DO
usersfile = ${confdir}/users_fast
hashsize = 1000
compat = no
+ hash_reload = 600
}
- 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 similar to that of the standard 'users' file, but you must
- keep the following differences in mind:
-
- 1. Order does not matter
-
- Order of the standard 'users' file is important, where in
- fastusers it is not. Multiple DEFAULT entries are not
- possible (see below), so don't be surprised when things
- don't work exactly as they would in 'users'.
-
- 2. DEFAULT entries
-
- While you can have multiple DEFAULT entries in the file
- you use with fastusers, only the last one will be used.
- Furthermore, the DEFAULT entry has a *very* different
- purpose in fastusers than it does in 'users'.
-
- In fastusers, if you add a DEFAULT entry, what you are
- telling the server is: Add the check items and reply
- items I list for this DEFAULT entry to *every* request
- that matches a user in this file. Example:
-
- test Auth-Type:=Local, Password=="test"
- Reply-Message = "User test"
+ 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:
- test2 Auth-Type:=Local, Password=="test2"
- Reply-Message = "User test2"
+ authorize {
+ preprocess
+ realm
+ fastusers
+ }
- DEFAULT Simultaneous-Use == 1
- Service-Type = Framed-User
+3. MODULE OPTIONS
- Normally you would expect that if a user other than 'test'
- or 'test2' logged in, the DEFAULT entry would apply. This
- is not the case in fastusers.
+ A. usersfile
- NOTE: No users other than ones listed explicitly in the file
- can authenticate via fastusers because DEFAULT entries
- do not work like they do in the 'users' file.
+ 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.
- Now, if either test or test2 logs in with their respec-
- tive password, when the request is passed back to the main
- server (and to the NAS), the check item Simultaneous-Use==1
- and the reply item Service-Type=Framed-User will be added.
-
- Why does it behave this way? The reason is because if it
- does not do this, the administrator will have to duplicate
- the check items and reply items for every user in the file
- unnecessarily. This will cause the fastusers file to be
- substantially larger than necessary, which in turn takes
- the server long to read on startup or when it receives
- a -HUP signal.
-
- This way, you need only put the necessary check and reply
- items on the DEFAULT entry, and then the individual users
- will need only have the items that are *unique* to them
- listed explicitly (ie, password, static ip address, etc).
-
- This behaviour will probably be configurable in future
- releases of the module. For now, you don't have to add
- a DEFAULT entry if you don't want one, and the attributes
- listed for each individual will be the ones used for check
- and reply items.
-
- NOTE: Because the attributes from DEFAULT are added to the
- user authenticating, it is best to *AVOID* listing an
- Auth-Type in the DEFAULT entry. If you set one in
- the DEFAULT entry, it will override the one you set
- for the user in the file. Just don't do it, it's not
- worth the confusion.
-
B. hashsize
The 'hashsize' variable controls how many 'buckets' or 'nodes'
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.
-
- Finally, you must put 'fastusers' in the 'authorize{}' section of your
- radiusd.conf. For example:
- authorize {
- preprocess
- realm
- fastusers
- }
+ 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;
-3. CAVEATS
+4. CAVEATS
- *NOTE: DEFAULT USERS DON'T WORK AS YOU MIGHT EXPECT! SEE ABOVE!!!
+ 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.
-4. ACKNOWLEDGEMENTS
+5. ACKNOWLEDGEMENTS
- Author - Jeff Carneal
+ Author - Jeff Carneal <jeff@apex.net>
projects / freeradius.git / blobdiff