|
Notes |
|
|
|
We will take an approach where the clients settings are stored in the database. We decided to store them internally inside the pf schema and not in an external database because it is less complex (no new db, new db user, etc. to handle).
For info check:
http://github.com/alandekok/freeradius-server/blob/v2.1.x/raddb/sql.conf [^]
http://old.nabble.com/NAS-list-with-MySQL-td14971644.html [^]
Tasks:
Test
- Try out the SQL module in the lab as a PoC, if it works with only nas client activated that's great!
Integration:
- Integrate the schema in pf's schema. change the name to radius_nas instead of nas
- Add a new param in switches.conf: radius_shared_secret or something similar
- On PF startup, at the config check phase (where we generate the templates) populate the NAS table in the database based on the switches IPs and shared secrets
- Do not forget that this will then require freeradius2 packages to be installed. Minimally: freeradius2, freeradius2-perl and freeradius2-mysql |
|
|
|
|
Successfully got the SQL module to use a nas table. Changes required:
- install freeradius2-mysql
- add table to database
- in radiusd.conf:
- uncomment $INCLUDE sql.conf under modules { ... }
- add sql under instantiate { ... }
- in sql.conf
- setup login, password, hostname, database name
- uncomment readclients = yes
- set nas_table (if not default) |
|
|
|
|
New radiusSecret parameter in switches.conf and pf::freeradius module are created. However nothing is done by default. See addons/freeradius-integration/README on help to enable that feature.
This will probably change in the future but for now, until we can fully control FreeRADIUS (config, start/stop/restart, etc.) from within PacketFence, it was preferred to keep things simple (avoiding everyone the need to change their config when upgrading). When things will be more integrated this will likely change. |
|