Mysql WP Deploying Free Radius

Deploying FreeRADIUS with the MySQL Cluster Database
A MySQL & FreeRADIUS Deployment Guide
Copyright 2009, MySQL & Network RADIUS
Table of Contents 1 ABSTRACT:................................................................................................................................. 3 2 OVERVIEW:................................................................................................................................. 3

2.1 FreeRADIUS............................................................................................................................................................................. 3 2.2 MySQL Cluster Database........................................................................................................................................................ 4 2.2.1 What is MySQL Cluster ?................................................................................................................................................... 5 2.3 Sun Fire X4200 Servers............................................................................................................................................................6
3 DEPLOYING FREERADIUS WITH MYSQL CLUSTER............................................................. 6

3.1 Deployment Topologies............................................................................................................................................................ 7 Two Data Nodes, 1 FreeRADIUS Node: Three servers (Configuration 1) ................................................................................. 7 Four Data Nodes, 1 FreeRADIUS node: Five Servers (Configuration 2)...................................................................................9
4 CONFIGURING FREERADIUS WITH MYSQL CLUSTER:..................................................... 10

4.1 Configuring MySQL Cluster:................................................................................................................................................ 11 4.2 Configure FreeRADIUS to use MySQL Cluster:................................................................................................................ 16 4.3 Testing the FreeRADIUS & MySQL Cluster Configuration.............................................................................................. 17
5 CONCLUSION........................................................................................................................... 18 6 REFERENCES AND FURTHER READING..............................................................................19 7 ACKNOWLEDGEMENTS......................................................................................................... 20 8 APPENDIX-I:(CONFIG.INI, MY.CNF)........................................................................................ 20 9 APPENDIX-II: (RADIUSD.CONF, SQL.CONF, CLIENTS.CONF)............................................23 10 APPENDIX-III:(ADMIN.SQL, SCHEMA.SQL, LOADUSERS.SH).......................................44
Page 2 of 46
1 Abstract:
The purpose of this Guide is to document a best-practice approach to configuring and testing a FreeRADIUS server deployed with the MySQL Cluster database storage engine, serving as the backend data store for user and accounting data. To learn more about Authentication, Authorization and Accounting (AAA) protocols, FreeRADIUS and the benefits of deploying MySQL Cluster as an AAA data store, please refer to the first whitepaper in this series entitled "Delivering Massively Scalable & Highly Available Authentication Services", posted at http://www.mysql.com/why-mysql/white-papers/mysql_wp_ha_auth_account.php Several different scenarios are considered in this Deployment Guide: 1. The FreeRADIUS server is co-hosted with a MySQL Server which provides SQL access to AAA data replicated across two MySQL Cluster data nodes. The MySQL Cluster Management Node is also hosted on the FreeRADIUS / MySQL Server A FreeRADIUS configuration capable of supporting the AAA demands of several million network users. In this scenario the data store infrastructure is scaled with multiple MySQL Server and MySQL Cluster database nodes.
2.
The Appendix section of this whitepaper includes the configuration files used in the scenarios descibed above.
2 Overview:
This section provides a brief overview of the products used in the deployment of this solution. For more information on these products, please refer to the "Delivering Massively Scalable & Highly Available Authentication Services" whitepaper.
2.1 FreeRADIUS
FreeRADIUS was founded in June 1999 by Miquel van Smoorenburg and Alan DeKok. FreeRADIUS includes a RADIUS server, a client library, Pluggable Authentication Modules (PAM) library, and an Apache module. The FreeRADIUS server is licensed under the GNU General Public License (GPL) version 2. As an open-source product, FreeRADIUS offers all of the associated open source benefits including the freedom and quality of open and collaborative code development and breakthrough economic models. It also includes many features not found in either free or many commercial RADIUS servers, including: Access based on huntgroups Multiple DEFAULT entries in raddb/users files Maintains a list of logged in users (via SQL or radutmp file) Logs both UNIX wtmp file format and RADIUS detail logfiles
Page 3 of 46
Supports Simultaneous-Use = X parameter, preventing double user logins Supports more than 100 Vendor-Specific dictionaries, including all major vendors Supports proxying, with multiple methods for fail-over and load-balancing Full support for Accounting packets, including Interim-Update (Alive) Exec-Program-Wait, allows users to set up an external program which is executed after authentication and outputs a list of Attribute / Value (AV) pairs which is then added to the reply. Runs on all Posix operating systems Full support for the WiMAX Forum NWG 1.2 specification Supports Change of Authorization (CoA) [RFC 5176] Has virtual server support for easy separation of policies into different classes High performance (thousands of authentications or accounting packets per second on commodity hardware) Full 802.1X (EAP) support, including all major EAP types. PEAP, EAP-TTLS, EAP-TLS, LEAP, EAP-MD5, SIM, AKA. Supports integrated scripting in Perl, Python, Ruby, and Java Plug-in interface permits simple extensibility SNMP and custom extensions for additional statistics PAM support
For more information about FreeRADIUS including information on the project, mailing lists, downloads, support, etc the reader should visit the web site: http://freeradius.org/ The leading commercial vendor supporting the FreeRADIUS community is Network RADIUS, with Alan Dekok one of the two original founders of the FreeRADIUS project as its Chief Executive Officer. Network RADIUS provides commercial support, consulting and development services for FreeRADIUS users. More information is available from http://networkradius.com/ FreeRADIUS runs on a large number of 32 and 64bit, which are detailed at the following URL: http://wiki.freeradius.org/Platforms
2.2 MySQL Cluster Database

As network services are deployed to an ever increasing user population, the challenge many administrators face is how to maintain their AAA back-end data management performance and availability requirements, without increasing cost and complexity. MySQL Cluster1 provides a robust, highly available and scalable solution to these issues with automatic load-balancing, failover and recovery capabilities built into the database. MySQL Cluster can be presented as a shared database resource over the network, transparently providing AAA database services for multiple FreeRADIUS instances. Delegating the management of the FreeRADIUS user and accounting data to a dedicated, highavailability database addresses the issue of replication overhead and maintaining database integrity, freeing up AAA servers to keep pace with the growing demands of authentication workloads. All Accounting detail updates are automatically propagated by extremely efficient and trustworthy mechanisms, at fraction of the time and effort of more traditional methods.
To learn more about the architecture of MySQL Cluster, please refer to the whitepaper posted here: http://www.mysql.com/why-mysql/white-papers/mysql_wp_cluster7_architecture.php
1
Page 4 of 46
2.2.1 What is MySQL Cluster ?

MySQL Cluster2 is a real-time open source transactional database designed for fast, always-on access to data under high throughput conditions. MySQL Cluster utilizes a shared nothing architecture which does not require any additional infrastructure investment and provides 99.999% data availability with no single point of failure. MySQL Cluster is most often used as an in-memory database, with data persisted to disk for durability. MySQL Cluster can also be configured to store data on disk, thereby scaling storage capacity beyond the physical limits of RAM. Application developers can easily integrate applications using their preferred database-independent method. MySQL Cluster Carrier Grade Edition provides multiple, simultaneous data access using a variety of means including SQL, Direct APIs (C++/Java), LDAP, and HTTP. MySQL Cluster automatically and transparently distributes data across multiple data nodes. It delivers extremely fast failover times so your applications can recover quickly from any failure. Cluster nodes automatically restart, recover, and configure themselves in case of failure, providing a zero administration high availability solution. The shared-nothing architecture means applications can start small and make incremental investments to increase capacity as demand grows. Typical response times for MySQL Cluster are in the range of a few milliseconds and MySQL Cluster has been proven to handle tens of thousands of distributed transactions per second.
Figure 1: The MySQL Cluster architecture delivers carrier-grade availability and performance, without the traditional fault-tolerant database price tag! To learn more about the architecture of MySQL Cluster for an AAA environment, please refer to the "Delivering Massively Scalable & Highly Available Authentication Services" whitepaper.3
2
For more information on MySQL Cluster including datasheets, whitepapers, webinars and case studies, please refer to http://www.mysql.com/products/database/cluster/ http://www.mysql.com/why-mysql/white-papers/mysql_wp_ha_auth_account.php
Page 5 of 46
2.3 Sun Fire X4200 Servers

The Sun Fire X4200 M2 server is fast, reliable, and expandable, offering scalability from one-way to eight-way processing with AMD x86 64-bit processors. The Sun Fire x4200 Server runs the Solaris Operating System in addition to Linux, Windows, and VMware. The deployment scenarios in this Guide used the dual core AMD processors, though quad core processors are available in the Sun Fire X4200 M2 series platforms.
3 Deploying FreeRADIUS with MySQL Cluster

When deploying MySQL Cluster with FreeRADIUS, a good starting design is to deploy at least two FreeRADIUS servers running the Virtual Router Redundancy Protocol (VRRP) in order to provide high availability to the authenication environment. Both of these servers then connect to the MySQL Cluster database to authenticate users and write accounting details. As a result, the AAA environment continues to operate even if: One of the FreeRADIUS servers fail One of the MySQL Cluster data nodes fail Both a FreeRADIUS Server and MySQL Cluster data node fails
Figure 2: FreeRADIUS with MySQL Cluster using VRRP
MySQL Cluster Data Nodes implicitly creates node groups, with each node group storing a part of the data set. Each node group usually consists of 2 data nodes (as default). The data is automatically and evenly partitioned across the data nodes. Data replication between the data nodes is synchronous and ensures that a copy, i.e., a replica of the partitioned data, is consistent and stored safely in each node group. All data nodes are participating actively in the cluster, there is no concept of active/passive nodes with MySQL Cluster. Data requests are transparently load balanced across the partitions/data nodes. This allows the FreeRADIUS servers to utilize all the data nodes with no resource duplication or
Page 6 of 46
waste. As a result of MySQL Cluster's distributed design, parallelized and batch oriented access to the database can further increase AAA performance. Increasing capacity of the database can be achieved by adding new Data Nodes. This is an on-line operation. The data set will be automatically re-partitioned across the new node groups while transactions are continuously running on the cluster. Throughput and load can easily be increased by adding more FreeRADIUS servers, again without any service interruption. MySQL's distributed design and ability to perform maintenance operations on-line ensures localized failure scenarios are addressed and service outages are avoided. This capability can be further extended using MySQL Cluster's Geographic Replication capabilities to withstand failures of a whole site. To assist DBAs and Network Administrators, MySQL and Network RADIUS provide a range of consulting, development and training services to accelerate the deployment of AAA projects that would benefit from using MySQL Cluster as the back-end database.
3.1 Deployment Topologies

Two Data Nodes, 1 FreeRADIUS Node: Three servers (Configuration 1)
A typical hardware configuration for a Two Data Node MySQL Cluster deployment consists of the following components:
One server (Node 3) for the Management Node, SQL Node and the freeRADIUS server. This example configuration has omitted a second FreeRADIUS server normally needed for a HA setup. 2 servers (DB Node 1 & 2) hosting the MySQL Cluster Data Nodes with raided local disks Dedicated private network for the MySQL Cluster Data Nodes to optimize the data replication traffic and performance of the Data Nodes while separating application traffic. Link aggregation is an option for cluster interconnect redundancy. Public network interfaces. IP multipathing is an option for network interface redundancy. Figure 3 below depicts a high level diagram of the hardware environment for a two Data Node MySQL Cluster. Each Data Node has a raided local disk, redundant private and public network interfaces.
Page 7 of 46
The FreeRADIUS server is using the SQL Node as a pass-through to the MySQL Cluster Data Nodes. The SQL Node, i.e., mysqld server provides the SQL interface for SQL based applications. The FreeRADIUS DB schema needs to be created using the storage engine option NDB or NDBCLUSTER which will then store the tables in MySQL Cluster. The FreeRADIUS schema.sql file for MySQL can be altered to include a STORAGE ENGINE option. Existing FreeRADIUS deployments using a MySQL server with InnoDB or MyISAM storage engines can easily migrate the schema to use MySQL Cluster. There are two options: 1. mysqldump and restore with a storage engine set to NDBCLUSTER. or 2. mysql> ALTER TABLE <tablename> STORAGE ENGINE NDBCLUSTER; Multiple connections from a single SQL Node to the MySQL Cluster data nodes can be configured. The general recommendation is to set the cluster connection pool to less than number of CPUs available. Data Nodes should be running on their own dedicated hardware. However if deploying on massively multi-core, multi-threaded hardware, for example Sun Chip Multi-Threading (CMT) servers, then the SQL Nodes could be co-located with the Data Nodes on the same physical host. On a Quad-core system or higher, the Data Node's internal threads (main execution and maintenance threads) can be locked to a specified CPU and, using the MySQL Cluster multithreaded binaries, up to 8 cores can be utilized. To provide more authentication capacity, the FreeRADIUS server can also be hosted in an isolated environment using a choice of virtualization options available with the server platform. When running OpenSolaris or Solaris, for example, it is possible to use the in-built Solaris Container technology which runs multiple isolated FreeRADIUS instances on a single OS image with little to no performance impact and ease of maintenance
Page 8 of 46
The software processes deployed are:
radiusd the FreeRADIUS server which is co-hosted with the SQL Node and the Management Node. mysqld the SQL Node/mysqld server process which provides the SQL interface for SQL based applications, e.g. FreeRADIUS, and handles geographical replication between MySQL clusters. ndbmtd (multi-thread) or ndbd the MySQL Cluster Data Node. Depending on how many cores are available the ndbmtd processes can be configured to use up to 8 cores and also lock the main execution and maintenance threads to a specific core. ndb_mgmd the MySQL Cluster Management Node which provisions the cluster configuration, maintains the cluster log and initiates backups. ndb_mgm the MySQL Cluster Management command line client used to connect to the Management node to perform various administration and maintenance tasks.
Four Data Nodes, 1 FreeRADIUS node: Five Servers (Configuration 2)

A typical hardware configuration for a four Data Node MySQL Cluster deployment consists of the following components:
One server (Node 5) for the Management Node, SQL Node and the freeRADIUS server. This example configuration has omitted a second freeRADIUS server normally needed for a HA setup. 4 servers (DB Nodes 1,2,3,& 4) hosting the MySQL Cluster Data Nodes with raided local disks Dedicated private network for the MySQL Cluster Data Nodes to optimize the data replication traffic and performance of the Data Nodes while separating application traffic. Link aggregation is an option for cluster interconnect redundancy. Public network interfaces. IP multipathing is an option for network interface redundancy. Figure 4 below depicts a high level diagram of the hardware environment for a 4 Data Node MySQL Cluster. Each Data Node has a raided local disk, redundant private and public network interfaces.
Page 9 of 46
In total there are three SQL Nodes and four MySQL Cluster Data Nodes. Two of the SQL Nodes are co-located with Data Nodes. By co-locating the SQL Node with a Data Node we reduce the network round-trip between the Data Node and SQL Node.
Please refer to the "Delivering Massively Scalable & Highly Available Authentication Services" whitepaper4 for a sizing study conducted with FreeRADIUS and MySQL Cluster
4 Configuring FreeRADIUS with MySQL Cluster:

The following section demonstrates how to configure FreeRADIUS with MySQL Cluster, deployed with the Configuration 1 topology described in Section 3 above. Hardware & Software used:
S# 1 2 3 Hostname x4200-01 x4200-02 radsrvr OS Solaris10 Update 6 (10/08) Solaris10 Update 6 (10/08) Solaris10 Update 6 (10/08) Software and Version MySQL Cluster 7.0.5 MySQL Cluster 7.0.5 MySQL Cluster 7.0.5 mysqld 32bit binaries FreeRADIUS 2.1.3 Remarks Data node 1 Data node 2 Cluster Management MySQL Server RADIUS server
http://www.mysql.com/why-mysql/white-papers/mysql_wp_ha_auth_account.php Page 10 of 46
4.1 Configuring MySQL Cluster:

Build the environment to install & configure MySQL Cluster: 1. Create the appropriate directory structure to host the various files. The MySQL Cluster Configurator is designed to enable users to create real, production-grade configurations across multiple hosts and is available from http://www.severalnines.com/config/ For more information on getting started with MySQL Cluster, refer to the Getting Stated Guide here: http://www.mysql.com/products/database/cluster/get-started.html
2. Extract and create appropriate links on all of the servers for the binaries. root@x4200-02:/usr/local# ln -s mysql-cluster-gpl-7.0.5-solaris10-x86_64 mysqlcluster root@x4200-01:/usr/local# ln -s mysql-cluster-gpl-7.0.5-solaris10-x86_64 mysqlcluster root@radsrvr:/usr/local# ln -s mysql-cluster-gpl-7.0.5-solaris10-x86_64 mysqlcluster 3. Create the data directory on all the nodes root@x4200-01:/usr/local# mkdir -p /data/mysqlcluster/ root@x4200-02:/usr/local# mkdir -p /data/mysqlcluster/ root@radsrvr:/usr/local# mkdir -p /data/mysqlcluster/ root@radsrvr:/usr/local# mkdir -p /data/mysql 4. Create the MySQL user & group, making the user the same UID & GID while creating the user & group. 5. chown -R mysql:mysql on all the data directories created above. root@radsrvr:/usr/local# chown -R mysql:mysql /data/mysqlcluster/ root@radsrvr:/usr/local# chown -R mysql:mysql /data/mysql root@x4200-01:/usr/local# chown -R mysql:mysql /data/mysqlcluster/ root@x4200-02:/usr/local# chown -R mysql:mysql /data/mysqlcluster/ 6. Create the link level aggregation as follows: root@x4200-02:/# dladm create-aggr -d e1000g2 -d e1000g3 1 root@x4200-01:/# dladm create-aggr -d e1000g2 -d e1000g3 1 7. Edit the following files so that the aggr1 interface is plumbed after subsequent reboots. x4200-02:/# cat >> /etc/hosts 11.11.11.2 dbn2 Ctrl+d x4200-02:/# cat >> /etc/hostname.aggr1 dbn2 Ctrl+d
Page 11 of 46
x4200-02:/# cat >> /etc/netmasks 11.11.11.0 255.255.255.0 Ctrl+d Repeat this step on the other node (x4200-01) and configure 11.11.11.1 as the IP address. 8. Issue the following command to launch the interface without rebooting the server. root@x4200-02:/# ifconfig aggr1 plumb 11.11.11.2/24 up OR root@x4200-02:/# svcadm restart network/physical Repeat this step on the other node (x4200-01) and configure 11.11.11.1 as the IP address.
Build the configuration files using the online configuration resources: 1. Go to http://www.severalnines.com/config/index.php 2. Scroll down and enter the following details that reflect the settings for this sample configuration

Select the appropriate cluster version (MySQL Cluster 7.0.x is recommended) Number of Data Nodes == 2 Number of APIs (MySQLD) == 1 DataMemory == 5400 DiskPageBufferMemory == 2048
3. Provide the hostnames for the following

NDB_MGMD (id = 1) == radsrvr NDBD (id = 2) == x4200-01 NDBD (id = 3) == x4200-02 MYSQLD (id = 4) == radsrvr Check this check box "Enable Multi-Connection"
4. Click Next button and Click on "config.in" link & open on a different window/tab. Use this file to bring up the management server. Click on "my.cnf" link & open on a different window/tab. Use this file to bring up the MySQL server and the MySQL Cluster (ndbd) server.
5. Save these configuration files as master file, and then edit the "config.ini" to add the following entries which enable direct TCP/IP connection This ensure the data replication traffic is routed among the data nodes on the appropriate network path: [TCP] NodeId1=2 NodeId2=3 HostName1=11.11.11.1 HostName2=11.11.11.2
Page 12 of 46
Copy the configuration files and bring up the processes: 1. Refer to Appendix-I later in this guide for the final version of config.ini & my.cnf. 2. On radsrvr, place config.ini & my.cnf as /var/lib/mysqlcluster/config.ini & /etc/my.cnf 3. Bring up Management Node as follows: root@radsrvr:/usr/local# /usr/local/mysqlcluster/bin/ndb_mgmd -f /var/lib/mysqlcluster/config.ini Done 4. Configure the MySQL Server as follows: Edit and place the /etc/my.cnf as per Appendix-I. Install the MySQL Server : root@radsrvr:/usr/local/mysqlcluster# scripts/mysql_install_db --basedir=/usr/local/mysqlcluster --datadir=/data/mysql --user=mysql Installing MySQL system tables... OK Filling help tables... OK To start mysqld at boot time you have to copy support-files/mysql.server to the right place for your system PLEASE REMEMBER TO SET A PASSWORD FOR THE MySQL root USER ! To do so, start the server, then issue the following commands: /usr/local/mysqlcluster/bin/mysqladmin -u root password 'new-password' /usr/local/mysqlcluster/bin/mysqladmin -u root -h radsrvr password 'newpassword' Alternatively you can run: /usr/local/mysqlcluster/bin/mysql_secure_installation which will also give you the option of removing the test databases and anonymous user created by default. This is strongly recommended for production servers. See the manual for more instructions. You can start the MySQL daemon with: cd /usr/local/mysqlcluster ; /usr/local/mysqlcluster/bin/mysqld_safe & You can test the MySQL daemon with mysql-test-run.pl cd /usr/local/mysqlcluster/mysql-test ; perl mysql-test-run.pl Please report any problems with the /usr/local/mysqlcluster/scripts/mysqlbug script! The latest information about MySQL is available at http://www.mysql.com/ Support MySQL by buying support/licenses from http://shop.mysql.com/ 5. Bring up the MySQL Server as follows:
Page 13 of 46
root@radsrvr:/usr/local/mysqlcluster# /usr/local/mysqlcluster/bin/mysqld_safe --basedir=/usr/local/mysqlcluster --datadir=/data/mysql --user=mysql & 6. Set the root user password root@radsrvr:/usr/local/mysqlcluster# /usr/local/mysqlcluster/bin/mysqladmin -u root password 'radiusdb' root@radsrvr:/usr/local/mysqlcluster# /usr/local/mysqlcluster/bin/mysqladmin -u root -h radsrvr password 'radiusdb' 7. Connect to the MySQL prompt as follows: root@radsrvr:/usr/local/mysqlcluster# bin/mysql -u root -p Enter password: Welcome to the MySQL monitor. Commands end with ; or \g. Your MySQL connection id is 5 Server version: 5.1.32-ndb-7.0.5-cluster-gpl MySQL Cluster Server (GPL) Type 'help;' or '\h' for help. Type '\c' to clear the buffer. mysql> 8. Bring-up the MySQL Cluster (ndbd) data nodes. No configuration files are required as MySQL Cluster (ndbd) gets configuration data from the Management Node. To start MySQL Cluster (ndbd) for the first time use --initial option. This option is not required for subsequent starts root@x4200-01:/usr/local/mysqlcluster# bin/ndbd --ndb-nodeid=2 --ndb-mgmdhost=radsrvr:1186 --initial root@x4200-02:/usr/local/mysqlcluster# bin/ndbd --ndb-nodeid=3 --ndb-mgmdhost=radsrvr:1186 --initial 9. Go to the Management Node Issue the following command to verify that MySQL Cluster is up and running. root@radsrvr:/usr/local/mysqlcluster# bin/ndb_mgm -e "show" Connected to Management Server at: localhost:1186 Cluster Configuration --------------------[ndbd(NDB)] 2 node(s) id=2 @192.168.107.21 (mysql-5.1.32 ndb-7.0.5, Nodegroup: 0, Master) id=3 @192.168.107.31 (mysql-5.1.32 ndb-7.0.5, Nodegroup: 0) [ndb_mgmd(MGM)] 1 node(s) id=1 @192.168.107.52 (mysql-5.1.32 ndb-7.0.5) [mysqld(API)] 5 node(s) id=4 @192.168.107.52 (mysql-5.1.32 ndb-7.0.5) id=5 @192.168.107.52 (mysql-5.1.32 ndb-7.0.5) id=6 @192.168.107.52 (mysql-5.1.32 ndb-7.0.5)
Page 14 of 46
id=7 id=8
@192.168.107.52 @192.168.107.52
(mysql-5.1.32 ndb-7.0.5) (mysql-5.1.32 ndb-7.0.5)
root@radsrvr:/usr/local/mysqlcluster# Note that 5 MySQL Server connections are established from a single MySQL Server. 10. Verify that the cluster is up and running using the MySQL prompt. Could verify the status even from MySQL Server, issue the following command. root@radsrvr:/usr/local/mysqlcluster# bin/mysql -u root -p -e 'show engine ndbcluster status' Enter password: +------------+----------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------+ | Type | Name | Status | +------------+----------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------+ | ndbcluster | connection | cluster_node_id=6, connected_host=radsrvr, connected_port=1186, number_of_data_nodes=2, number_of_ready_data_nodes=2, connect_count=0 | | ndbcluster | NdbTransaction | created=2, free=2, sizeof=296 | | ndbcluster | NdbOperation | created=4, free=4, sizeof=928 | | ndbcluster | NdbIndexScanOperation | created=0, free=0, sizeof=1136 | | ndbcluster | NdbIndexOperation | created=0, free=0, sizeof=936 | | ndbcluster | NdbRecAttr | created=0, free=0, sizeof=88 | | ndbcluster | NdbApiSignal | created=16, free=16, sizeof=144 | | ndbcluster | NdbLabel | created=0, free=0, sizeof=200 | | ndbcluster | NdbBranch | created=0, free=0, sizeof=32 | | ndbcluster | NdbSubroutine | created=0, free=0, sizeof=72 |
Page 15 of 46
| ndbcluster | NdbCall sizeof=24 | ndbcluster | NdbBlob sizeof=496 | ndbcluster | NdbReceiver sizeof=144
| created=0, free=0, | created=0, free=0, | created=0, free=0, | |
| | ndbcluster | binlog | latest_epoch=13460427505672, latest_trans_epoch=25769803783, latest_received_binlog_epoch=0, latest_handled_binlog_epoch=0, latest_applied_binlog_epoch=0 | +------------+----------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------+ root@radsrvr:/usr/local/mysqlcluster# Note: /usr/local/mysql has 32 bit MySQL Server binaries installed, as the FreeRADIUS server needs 32 bit libmysqlclient.so to load it's module.
4.2 Configure FreeRADIUS to use MySQL Cluster:

Default location for FreeRADIUS to be installed is /usr/local. The radiusd binary is available at /usr/local/sbin/radiusd.
Configure FreeRADIUS: 1. Edit the following files under the specified directories root@radsrvr:/usr/local/etc/raddb# vi radiusd.conf root@radsrvr:/usr/local/etc/raddb# vi sql.conf root@radsrvr:/usr/local/etc/raddb# vi clients.conf Detailed examples of all the above *.conf configuration files are available in Appendix-II of this Guide. 2. Configure the MySQL Server for FreeRADIUS:

Go to the /usr/local/etc/raddb/sql/mysql directory, and connect to the MySQL Server as root. All of the .sql files are available Appendix-III of this Guide. Create the database as follows:
root@radsrvr:/usr/local/etc/raddb/sql/ndb# /usr/local/mysqlcluster/bin/mysql -uroot -p Enter password: Welcome to the MySQL monitor. Commands end with ; or \g. Your MySQL connection id is 4 Server version: 5.1.32-ndb-7.0.5-cluster-gpl MySQL Cluster Server (GPL) Type 'help;' or '\h' for help. Type '\c' to clear the buffer. mysql> create database radius;
Page 16 of 46
Query OK, 1 row affected (0.01 sec) mysql>
Create the RADIUS user account in the database
root@radsrvr:/usr/local/etc/raddb/sql/ndb# /usr/local/mysqlcluster/bin/mysql -uroot -p radius < admin.sql Enter password: root@radsrvr:/usr/local/etc/raddb/sql/ndb# mysql> GRANT ALL on radius.* TO 'radius'@'radsrvr' identified by 'radpass'; Query OK, 0 rows affected (0.00 sec) mysql> GRANT ALL on radius.* TO 'radius'@'localhost' identified by 'radpass'; Query OK, 0 rows affected (0.00 sec)
Create the schema to host the data (change all the table creation statements and add "ENGINE=ndbcluster" at the end).
root@radsrvr:/usr/local/etc/raddb/sql/ndb# /usr/local/mysqlcluster/bin/mysql -uroot -p radius < schema.sql Enter password: root@radsrvr:/usr/local/etc/raddb/sql/ndb#
Populate the database with the sample data from the "loadusers.sh" which is available in Appendix-III of this Guide.
3. Bring up the "radiusd" FreeRADIUS server.
Edit the /usr/local/etc/raddb/sites-enabled/default and uncheck the "sql" under the "authorize" section. You may have to do the same under the authentication & accounting sections too if you are enabling the database for those activities.
root@radsrvr:/usr/local/etc/raddb/sql/ndb/scripts# type radiusd radiusd is /usr/local/sbin/radiusd root@radsrvr:/usr/local/etc/raddb/sql/ndb/scripts# nohup radiusd -Xxx 2>&1 > /var/tmp/radiusd.log & [1] 3932 root@radsrvr:/usr/local/etc/raddb/sql/ndb/scripts# Sending output to nohup.out root@radsrvr:/usr/local/etc/raddb/sql/ndb/scripts#
4.3 Testing the FreeRADIUS & MySQL Cluster Configuration
Successful authentication of "user50 and user35" as these users are present in the database.
root@radsrvr:/# radtest user50 user50 radsrvr 0 testing123
Page 17 of 46
Sending Access-Request of id 60 to 192.168.107.52 port 1812 User-Name = "user50" User-Password = "user50" NAS-IP-Address = 192.168.107.52 NAS-Port = 0 rad_recv: Access-Accept packet from host 192.168.107.52 port 1812, id=60, length=34 Reply-Message = "Hello user50" root@radsrvr:/# radtest user35 user35 radsrvr 0 testing123 Sending Access-Request of id 82 to 192.168.107.52 port 1812 User-Name = "user35" User-Password = "user50" NAS-IP-Address = 192.168.107.52 NAS-Port = 0 rad_recv: Access-Accept packet from host 192.168.107.52 port 1812, id=82, length=34 Reply-Message = "Hello user35" root@radsrvr:/# type radtest radtest is hashed (/usr/local/bin/radtest)
Authentication fails for "user550" as this user does not exists in the database
root@radsrvr:/usr/local/etc/raddb/sql/ndb/scripts# radtest user550 user35 radsrvr 0 testing123 Sending Access-Request of id 129 to 192.168.107.52 port 1812 User-Name = "user550" User-Password = "user35" NAS-IP-Address = 192.168.107.52 NAS-Port = 0 rad_recv: Access-Reject packet from host 192.168.107.52 port 1812, id=129, length=20 root@radsrvr:/usr/local/etc/raddb/sql/ndb/scripts#
5 Conclusion
Upgrading existing FreeRADIUS data stores to MySQL Cluster is a simple, non-disruptive and seamless operation, requiring minimal changes to the FreeRADIUS server configuration and no changes to associated applications. First time FreeRADIUS users could initially configure their data store with flat text files, and as their needs of back-end data management increases for higher performanxe and scalability, upgrade to MySQL Server configured to use the popular MyISAM storage engine. Administrators can then still access their existing MySQL Server data, even while moving to the MySQL Cluster storage engine for more demanding AAA environments. This simply involves updating the MySQL Server configuration to enable use of the MySQL Cluster (ndb) storage engine. Deploying the MySQL Cluster database with FreeRADIUS offers many advantages over more traditional approaches to data management, including: Deploying the MySQL Cluster database with FreeRADIUS offers many advantages over more traditional approaches to data management, including:
Page 18 of 46
Providing a fault tolerant database environment with integrated and automatic load balancing, failover, recovery and geographic replication. AAA developers and administrators do not need to build these capabilities themselves or change their existing applications in any way. All database updates, including Accounting details, are automatically and transparently propagated across each database node using MySQL Cluster's synchronous replication features. Eliminating the need to configure, manage and monitor data replication processes reduces administrative overhead. Hardware utilization is significantly improved using MySQL's Active / Active clustered architecture, coupled with the ability to virtualize multiple software components onto fewer physical hardware resources. The ability to scale the AAA environment and the database layers independently add to deployment and configuration flexibility As demonstrated by the sizing study5, a simple deployment of just four commodity servers and open source software can support demanding AAA requirements, delivering both high availability with high performance, while providing a foundation for simple scalability as the network grows.
Deploying MySQL Cluster as an AAA data store is a seamless upgrade, enabling FreeRADIUS users to scale their AAA infrastructure to new heights, while achieving continuous availability.
6 References and Further Reading

Delivering Massively Scalable & Highly Available Authentication Services: http://www.mysql.com/why-mysql/white-papers/mysql_wp_ha_auth_account.php FreeRADIUS on the web: http://freeradius.org/ Network RADIUS on the web: http://networkradius.com/ MySQL Cluster on the web: http://www.mysql.com/products/database/cluster/ MySQL Cluster Datasheet: http://www.mysql.com/products/database/cluster/mysql-cluster-datasheet.pdf MySQL Cluster Architecture and New Features Whitepaper: http://www.mysql.com/why-mysql/white-papers/mysql_wp_cluster7_architecture.php MySQL Cluster Evaluation Guide: http://www.mysql.com/why-mysql/white-papers/mysql_cluster_eval_guide.php
http://www.mysql.com/why-mysql/white-papers/mysql_wp_ha_auth_account.php
Page 19 of 46
7 Acknowledgements
The authors wish to thank Alan Dekok, Founder of the FreeRADIUS project and CEO of Network RADIUS, for his contributions in the development of this Deployment Guide Copyright 2009, MySQL is a registered trademark in the U.S. and in other countries. Other products mentioned may be trademarks of their companies.
8 Appendix-I:(config.ini, my.cnf)
Got these files compiled from http://www.severalnines.com by providing the inputs as mentioned above in the "Build configuration files section". [/var/lib/mysqlcluster/config.ini] [TCP DEFAULT] SendBufferMemory=2M ReceiveBufferMemory=2M [NDB_MGMD DEFAULT] PortNumber=1186 Datadir=/data/mysqlcluster/ [NDB_MGMD] Id=1 Hostname=radsrvr [NDBD DEFAULT] NoOfReplicas=2 Datadir=/data/mysqlcluster/ DataMemory=5400M IndexMemory=675M LockPagesInMainMemory=1 MaxNoOfConcurrentOperations=100000 StringMemory=25 MaxNoOfTables=4096 MaxNoOfOrderedIndexes=2048 MaxNoOfUniqueHashIndexes=512 MaxNoOfAttributes=24576 DiskCheckpointSpeedInRestart=100M FragmentLogFileSize=256M InitFragmentLogFiles=FULL NoOfFragmentLogFiles=32 RedoBuffer=32M TimeBetweenLocalCheckpoints=20 TimeBetweenGlobalCheckpoints=1000 TimeBetweenEpochs=100 MemReportFrequency=30 BackupReportFrequency=10 ### Params for setting logging LogLevelStartup=15 LogLevelShutdown=15 LogLevelCheckpoint=8 LogLevelNodeRestart=15
Page 20 of 46
### Params for increasing Disk throughput BackupMaxWriteSize=1M BackupDataBufferSize=16M BackupLogBufferSize=4M BackupMemory=20M #Reports indicates that odirect=1 can cause io errors (os err code 5) on some systems. You must test. #ODirect=1 ### Watchdog TimeBetweenWatchdogCheckInitial=30000 ### TransactionInactiveTimeout - should be enabled in Production #TransactionInactiveTimeout=30000 ### CGE 6.3 - REALTIME EXTENSIONS #RealTimeScheduler=1 #SchedulerExecutionTimer=80 #SchedulerSpinTimer=40 ### DISK DATA SharedGlobalMemory=384M #read my blog how to set this: DiskPageBufferMemory=2048M [NDBD] Id=2 Hostname=x4200-01 ### CGE 6.3 - REALTIME EXTENSIONS ### PLEASE NOTE THAT THE BELOW ONLY WORKS IF YOU HAVE >1 CORE. ### YOU SHOULD CHECK cat /proc/interrupts AND CHOOSE THE CPUs ### THAT GENERATE THE LEAST INTERRUPS. TYPICALLY THE CPU HANDLING ### THE INTERRUPTS FOR THE COMMUNICATION INTERFACE USED FOR THE DATA NODE SHOULD ### BE AVOIDED FOR THE LockExecuteThreadToCPU, BUT YOU CAN ### LockMaintThreadsToCPU TO THAT CPU SINCE IT DOES NOT AFFECT THE ### REALTIME ASPECTS (THIS IS TRUE FOR UP TO TWO DATA NODES ONE ONE COMPUTER. #LockExecuteThreadToCPU=X #LockMaintThreadsToCPU=Y [NDBD] Id=3 Hostname=x4200-02 ### CGE 6.3 - REALTIME EXTENSIONS ### PLEASE NOTE THAT THE BELOW ONLY WORKS IF YOU HAVE >1 CORE. ### YOU SHOULD CHECK cat /proc/interrupts AND CHOOSE THE CPUs ### THAT GENERATE THE LEAST INTERRUPS. TYPICALLY THE CPU HANDLING ### THE INTERRUPTS FOR THE COMMUNICATION INTERFACE USED FOR THE DATA NODE SHOULD ### BE AVOIDED FOR THE LockExecuteThreadToCPU, BUT YOU CAN ### LockMaintThreadsToCPU TO THAT CPU SINCE IT DOES NOT AFFECT THE ### REALTIME ASPECTS (THIS IS TRUE FOR UP TO TWO DATA NODES ONE ONE COMPUTER. #LockExecuteThreadToCPU=X #LockMaintThreadsToCPU=Y [MYSQLD] Hostname=radsrvr [MYSQLD] Hostname=radsrvr [MYSQLD] Hostname=radsrvr [MYSQLD]
Page 21 of 46
Hostname=radsrvr [MYSQLD] Hostname=radsrvr [TCP] NodeId1=2 NodeId2=3 HostName1=11.11.11.1 HostName2=11.11.11.2 [/etc/my.cnf] [MYSQLD] user=mysql basedir=/usr/local/mysqlcluster/mysql/ datadir=/data/mysql/ socket=/tmp/mysql.sock port=3306 ndb-cluster-connection-pool=5 ndbcluster ndb-connectstring="radsrvr:1186" ndb-force-send=1 ndb-use-exact-count=0 ndb-extra-logging=1 ndb-autoincrement-prefetch-sz=256 engine-condition-pushdown=1 #REPLICATION SPECIFIC - GENERAL #server-id must be unique across all mysql servers participating in replication. #server-id=X #REPLICATION SPECIFIC - MASTER #log-bin #LOGS log-err=error.log #log #log-slow-queries #OTHER THINGS, BUFFERS ETC #log-bin key_buffer = 256M max_allowed_packet = 16M sort_buffer_size = 512K read_buffer_size = 256K read_rnd_buffer_size = 512K thread_cache_size=1024 myisam_sort_buffer_size = 8M memlock sysdate_is_now max-connections=200 thread-cache-size=64 query-cache-type = 0 query-cache-size = 0 table-open_cache=1024 table-cache=512 lower-case-table-names=0
Page 22 of 46
[MYSQL] socket=/tmp/mysql.sock
9 Appendix-II: (radiusd.conf, sql.conf, clients.conf)

[radiusd.conf]
root@radsrvr:/usr/local/etc/raddb# less radiusd.conf # -*- text -*## ## radiusd.conf -- FreeRADIUS server configuration file. ## ## http://www.freeradius.org/ ## $Id$ ## ###################################################################### # # Read "man radiusd" before editing this file. See the section # titled DEBUGGING. It outlines a method where you can quickly # obtain the configuration you want, without running into # trouble. # # Run the server in debugging mode, and READ the output. # # $ radiusd -X # # We cannot emphasize this point strongly enough. The vast # majority of problems can be solved by carefully reading the # debugging output, which includes warnings about common issues, # and suggestions for how they may be fixed. # # There may be a lot of output, but look carefully for words like: # "warning", "error", "reject", or "failure". The messages there # will usually be enough to guide you to a solution. # # If you are going to ask a question on the mailing list, then # explain what you are trying to do, and include the output from # debugging mode (radiusd -X). Failure to do so means that all # of the responses to your question will be people telling you # to "post the output of radiusd -X". ###################################################################### # # The location of other config files and logfiles are declared # in this file. # # Also general configuration for modules can be done in this # file, it is exported through the API to modules that ask for # it.
Page 23 of 46
# # # # # # # # # #
See "man radiusd.conf" for documentation on the format of this file. Note that the individual configuration items are NOT documented in that "man" page. They are only documented here, in the comments. As of 2.0.0, FreeRADIUS supports a simple processing language in the "authorize", "authenticate", "accounting", etc. sections. See "man unlang" for details.
prefix = /usr/local exec_prefix = ${prefix} sysconfdir = ${prefix}/etc localstatedir = ${prefix}/var sbindir = ${exec_prefix}/sbin logdir = ${localstatedir}/log/radius raddbdir = ${sysconfdir}/raddb radacctdir = ${logdir}/radacct # # name of the running server. name = radiusd See also the "-n" command-line option.
# Location of config and logfiles. confdir = ${raddbdir} run_dir = ${localstatedir}/run/radiusd # Should likely be ${localstatedir}/lib/radiusd db_dir = ${raddbdir} # # libdir: Where to find the rlm_* modules. # # This should be automatically set at configuration time. # # If the server builds and installs, but fails at execution time # with an 'undefined symbol' error, then you can use the libdir # directive to work around the problem. # # The cause is usually that a library has been installed on your # system in a place where the dynamic linker CANNOT find it. When # executing as root (or another user), your personal environment MAY # be set up to allow the dynamic linker to find the library. When # executing as a daemon, FreeRADIUS MAY NOT have the same # personalized configuration. # # To work around the problem, find out which library contains that symbol, # and add the directory containing that library to the end of 'libdir', # with a colon separating the directory names. NO spaces are allowed. # # e.g. libdir = /usr/local/lib:/opt/package/lib # # You can also try setting the LD_LIBRARY_PATH environment variable # in a script which starts the server. #
Page 24 of 46
# If that does not work, then you can re-configure and re-build the # server to NOT use shared libraries, via: # # ./configure --disable-shared # make # make install # libdir = ${exec_prefix}/lib # pidfile: Where to place the PID of the RADIUS server. # # The server may be signalled while it's running by using this # file. # # This file is written when ONLY running in daemon mode. # # e.g.: kill -HUP `cat /var/run/radiusd/radiusd.pid` # pidfile = ${run_dir}/${name}.pid # chroot: directory where the server does "chroot". # # The chroot is done very early in the process of starting the server. # After the chroot has been performed it switches to the "user" listed # below (which MUST be specified). If "group" is specified, it switchs # to that group, too. Any other groups listed for the specified "user" # in "/etc/group" are also added as part of this process. # # The current working directory (chdir / cd) is left *outside* of the # chroot until all of the modules have been initialized. This allows # the "raddb" directory to be left outside of the chroot. Once the # modules have been initialized, it does a "chdir" to ${logdir}. This # means that it should be impossible to break out of the chroot. # # If you are worried about security issues related to this use of chdir, # then simply ensure that the "raddb" directory is inside of the chroot, # end be sure to do "cd raddb" BEFORE starting the server. # # If the server is statically linked, then the only files that have # to exist in the chroot are ${run_dir} and ${logdir}. If you do the # "cd raddb" as discussed above, then the "raddb" directory has to be # inside of the chroot directory, too. # #chroot = /path/to/chroot/directory # user/group: The name (or #number) of the user/group to run radiusd as. # # If these are commented out, the server will run as the user/group # that started it. In order to change to a different user/group, you # MUST be root ( or have root privleges ) to start the server. # # We STRONGLY recommend that you run the server with as few permissions # as possible. That is, if you're not using shadow passwords, the # user and group items below should be set to radius'. # # NOTE that some kernels refuse to setgid(group) when the value of # (unsigned)group is above 60000; don't use group nobody on these systems!
Page 25 of 46
# # On systems with shadow passwords, you might have to set 'group = shadow' # for the server to be able to read the shadow password file. If you can # authenticate users while in debug mode, but not in daemon mode, it may be # that the debugging mode server is running as a user that can read the # shadow info, and the user listed below can not. # # The server will also try to use "initgroups" to read /etc/groups. # It will join all groups where "user" is a member. This can allow # for some finer-grained access controls. # #user = radius #group = radius # max_request_time: The maximum time (in seconds) to handle a request. # # Requests which take more time than this to process may be killed, and # a REJECT message is returned. # # WARNING: If you notice that requests take a long time to be handled, # then this MAY INDICATE a bug in the server, in one of the modules # used to handle a request, OR in your local configuration. # # This problem is most often seen when using an SQL database. If it takes # more than a second or two to receive an answer from the SQL database, # then it probably means that you haven't indexed the database. See your # SQL server documentation for more information. # # Useful range of values: 5 to 120 # max_request_time = 30 # cleanup_delay: The time to wait (in seconds) before cleaning up # a reply which was sent to the NAS. # # The RADIUS request is normally cached internally for a short period # of time, after the reply is sent to the NAS. The reply packet may be # lost in the network, and the NAS will not see it. The NAS will then # re-send the request, and the server will respond quickly with the # cached reply. # # If this value is set too low, then duplicate requests from the NAS # MAY NOT be detected, and will instead be handled as seperate requests. # # If this value is set too high, then the server will cache too many # requests, and some new requests may get blocked. (See 'max_requests'.) # # Useful range of values: 2 to 10 # cleanup_delay = 5 # # # # # max_requests: The maximum number of requests which the server keeps track of. This should be 256 multiplied by the number of clients. e.g. With 4 clients, this number should be 1024. If this number is too low, then when the server becomes busy,
Page 26 of 46
# it will not respond to any new requests, until the 'cleanup_delay' # time has passed, and it has removed the old requests. # # If this number is set too high, then the server will use a bit more # memory for no real benefit. # # If you aren't sure what it should be set to, it's better to set it # too high than too low. Setting it to 1000 per client is probably # the highest it should be. # # Useful range of values: 256 to infinity # max_requests = 1024 # listen: Make the server listen on a particular IP address, and send # replies out from that address. This directive is most useful for # hosts with multiple IP addresses on one interface. # # If you want the server to listen on additional addresses, or on # additionnal ports, you can use multiple "listen" sections. # # Each section make the server listen for only one type of packet, # therefore authentication and accounting have to be configured in # different sections. # # The server ignore all "listen" section if you are using '-i' and '-p' # on the command line. # listen { # Type of packets to listen for. # Allowed values are: # auth listen for authentication packets # acct listen for accounting packets # proxy IP to use for sending proxied packets # detail Read from the detail file. For examples, see # raddb/sites-available/copy-acct-to-home-server # status listen for Status-Server packets. For examples, # see raddb/sites-available/status # type = auth # # # # # # # Note: "type = proxy" lets you control the source IP used for proxying packets, with some limitations: * * * * Only ONE proxy listener can be defined. A proxy listener CANNOT be used in a virtual server section. You should probably set "port = 0". Any "clients" configuration will be ignored.
# IP address on which to listen. # Allowed values are: # dotted quad (1.2.3.4) # hostname (radius.example.com) # wildcard (*) ipaddr = 192.168.107.52 # OR, you can use an IPv6 address, but not both
Page 27 of 46
# at the same time. ipv6addr = :: # any.
::1 == localhost
# Port on which to listen. # Allowed values are: # integer port number (1812) # 0 means "use /etc/services for the proper port" #port = 0 port = 1812 # Some systems support binding to an interface, in addition # to the IP address. This feature isn't strictly necessary, # but for sites with many IP addresses on one interface, # it's useful to say "listen on all addresses for eth0". # # If your system does not support this feature, you will # get an error if you try to use it. # interface = eth0 # Per-socket lists of clients. This is a very useful feature. # # The name here is a reference to a section elsewhere in # radiusd.conf, or clients.conf. Having the name as # a reference allows multiple sockets to use the same # set of clients. # # If this configuration is used, then the global list of clients # is IGNORED for this "listen" section. Take care configuring # this feature, to ensure you don't accidentally disable a # client you need. # # See clients.conf for the configuration of "per_socket_clients". # clients = per_socket_clients
# }
# This second "listen" section is for listening on the accounting # port, too. # listen { ipaddr = * # ipv6addr = :: port = 0 type = acct # interface = eth0 # clients = per_socket_clients } # # # # # # # # hostname_lookups: Log the names of clients or just their IP addresses e.g., www.freeradius.org (on) or 206.47.27.232 (off). The default is 'off' because it would be overall better for the net if people had to knowingly turn this feature on, since enabling it means that each client request will result in AT LEAST one lookup request to the nameserver. Enabling hostname_lookups will also mean that your server may stop randomly for 30 seconds from time
Page 28 of 46
# to time, if the DNS requests take too long. # # Turning hostname lookups off also means that the server won't block # for 30 seconds, if it sees an IP address which has no name associated # with it. # # allowed values: {no, yes} # hostname_lookups = no # Core dumps are a bad thing. This should only be set to 'yes' # if you're debugging a problem with the server. # # allowed values: {no, yes} # allow_core_dumps = no # Regular expressions # # These items are set at configure time. If they're set to "yes", # then setting them to "no" turns off regular expression support. # # If they're set to "no" at configure time, then setting them to "yes" # WILL NOT WORK. It will give you an error. # regular_expressions = yes extended_expressions = yes # # Logging section. The various "log_*" configuration items # will eventually be moved here. # log { # # Destination for log messages. This can be one of: # # files - log to "file", as defined below. # syslog - to syslog (see also the "syslog_facility", below. # stdout - standard output # stderr - standard error. # # The command-line option "-X" over-rides this option, and forces # logging to go to stdout. # destination = files # # The logging messages for the server are appended to the # tail of this file if destination == "files" # # If the server is running in debugging mode, this file is # NOT used. # file = ${logdir}/radius.log # # If this configuration parameter is set, then log messages for
Page 29 of 46
accepted
# # #
a *request* go to this file, rather than to radius.log. i.e. This is a log file per request, once the server has
# the request as being from a valid client. Messages that are # not associated with a request still go to radius.log. # # Not all log messages in the server core have been updated to use # this new internal API. As a result, some messages will still # go to radius.log. Please submit patches to fix this behavior. # # The file name is expanded dynamically. You should ONLY user # server-side attributes for the filename (e.g. things you control). # Using this feature MAY also slow down the server substantially, # especially if you do thinks like SQL calls as part of the # expansion of the filename. # # The name of the log file should use attributes that don't change # over the lifetime of a request, such as User-Name, # Virtual-Server or Packet-Src-IP-Address. Otherwise, the log # messages will be distributed over multiple files. # # Logging can be enabled for an individual request by a special # dynamic expansion macro: %{debug: 1}, where the debug level # for this request is set to '1' (or 2, 3, etc.). e.g. # # ... # update control { # Tmp-String-0 = "%{debug:1}" # } # ... # # The attribute that the value is assigned to is unimportant, # and should be a "throw-away" attribute with no side effects. # #requests = ${logdir}/radiusd-%{%{Virtual-Server}:-DEFAULT}-%Y%m %d.log # # Which syslog facility to use, if ${destination} == "syslog" # # The exact values permitted here are OS-dependent. You probably # don't want to change this. # syslog_facility = daemon # request. Log the full User-Name attribute, as it was found in the
# # allowed values: {no, yes} # stripped_names = no # Log authentication requests to the log file. # # allowed values: {no, yes} #
Page 30 of 46
auth = no # Log passwords with the authentication requests. # auth_badpass - logs password if it's rejected # auth_goodpass - logs password if it's correct # # allowed values: {no, yes} # auth_badpass = no auth_goodpass = no } # The program to execute to do concurrency checks. checkrad = ${sbindir}/checkrad # SECURITY CONFIGURATION # # There may be multiple methods of attacking on the server. This # section holds the configuration items which minimize the impact # of those attacks # security { # # max_attributes: The maximum number of attributes # permitted in a RADIUS packet. Packets which have MORE # than this number of attributes in them will be dropped. # # If this number is set too low, then no RADIUS packets # will be accepted. # # If this number is set too high, then an attacker may be # able to send a small number of packets which will cause # the server to use all available memory on the machine. # # Setting this number to 0 means "allow any number of attributes" max_attributes = 200 # # reject_delay: When sending an Access-Reject, it can be # delayed for a few seconds. This may help slow down a DoS # attack. It also helps to slow down people trying to brute-force # crack a users password. # # Setting this number to 0 means "send rejects immediately" # # If this number is set higher than 'cleanup_delay', then the # rejects will be sent at 'cleanup_delay' time, when the request # is deleted from the internal cache of requests. # # Useful ranges: 1 to 5 reject_delay = 1 # # # # # status_server: Whether or not the server will respond to Status-Server requests. When sent a Status-Server message, the server responds with
Page 31 of 46
# an Access-Accept or Accounting-Response packet. # # This is mainly useful for administrators who want to "ping" # the server, without adding test users, or creating fake # accounting packets. # # It's also useful when a NAS marks a RADIUS server "dead". # The NAS can periodically "ping" the server with a Status-Server # packet. If the server responds, it must be alive, and the # NAS can start using it for real requests. # # See also raddb/sites-available/status # status_server = yes } # PROXY CONFIGURATION # # proxy_requests: Turns proxying of RADIUS requests on or off. # # The server has proxying turned on by default. If your system is NOT # set up to proxy requests to another server, then you can turn proxying # off here. This will save a small amount of resources on the server. # # If you have proxying turned off, and your configuration files say # to proxy a request, then an error message will be logged. # # To disable proxying, change the "yes" to "no", and comment the # $INCLUDE line. # # allowed values: {no, yes} # proxy_requests = yes $INCLUDE proxy.conf # CLIENTS CONFIGURATION # # Client configuration is defined in "clients.conf". # # The 'clients.conf' file contains all of the information from the old # 'clients' and 'naslist' configuration files. We recommend that you # do NOT use 'client's or 'naslist', although they are still # supported. # # Anything listed in 'clients.conf' will take precedence over the # information from the old-style configuration files. # $INCLUDE clients.conf # THREAD POOL CONFIGURATION # # The thread pool is a long-lived group of threads which # take turns (round-robin) handling any incoming requests. #
Page 32 of 46
# You probably want to have a few spare threads around, # so that high-load situations can be handled immediately. If you # don't have any spare threads, then the request handling will # be delayed while a new thread is created, and added to the pool. # # You probably don't want too many spare threads around, # otherwise they'll be sitting there taking up resources, and # not doing anything productive. # # The numbers given below should be adequate for most situations. # thread pool { # Number of servers to start initially --- should be a reasonable # ballpark figure. start_servers = 5 # # # # # Limit on the total number of servers running. If this limit is ever reached, clients will be LOCKED OUT, so it should NOT BE SET TOO LOW. It is intended mainly as a brake to keep a runaway server from taking the system with it as it
spirals
# down... # # You may find that the server is regularly reaching the # 'max_servers' number of threads, and that increasing # 'max_servers' doesn't seem to make much difference. # # If this is the case, then the problem is MOST LIKELY that # your back-end databases are taking too long to respond, and # are preventing the server from responding in a timely manner. # # The solution is NOT do keep increasing the 'max_servers' # value, but instead to fix the underlying cause of the # problem: slow database, or 'hostname_lookups=yes'. # # For more information, see 'max_request_time', above. # max_servers = 32 # Server-pool size regulation. Rather than making you guess # how many servers you need, FreeRADIUS dynamically adapts to # the load it sees, that is, it tries to maintain enough # servers to handle the current load, plus a few spare # servers to handle transient load spikes. # # It does this by periodically checking how many servers are # waiting for a request. If there are fewer than # min_spare_servers, it creates a new spare. If there are # more than max_spare_servers, some of the spares die off. # The default values are probably OK for most sites. # min_spare_servers = 3 max_spare_servers = 10 # # There may be memory leaks or resource allocation problems with the server. If so, set this value to 300 or so, so that the
Page 33 of 46
# resources will be cleaned up periodically. # # This should only be necessary if there are serious bugs in the # server which have not yet been fixed. # # '0' is a special value meaning 'infinity', or 'the servers never # exit' max_requests_per_server = 0 } # MODULE CONFIGURATION # # The names and configuration of each module is located in this section. # # After the modules are defined here, they may be referred to by name, # in other sections of this configuration file. # modules { # # Each module has a configuration as follows: # # name [ instance ] { # config_item = value # ... # } # # The 'name' is used to load the 'rlm_name' library # which implements the functionality of the module. # # The 'instance' is optional. To have two different instances # of a module, it first must be referred to by 'name'. # The different copies of the module are then created by # inventing two 'instance' names, e.g. 'instance1' and 'instance2' # # The instance names can then be used in later configuration # INSTEAD of the original 'name'. See the 'radutmp' configuration # for an example. # # # As of 2.0.5, most of the module configurations are in a # sub-directory. Files matching the regex /[a-zA-Z0-9_.]+/ # are loaded. The modules are initialized ONLY if they are # referenced in a processing section, such as authorize, # authenticate, accounting, pre/post-proxy, etc. # $INCLUDE ${confdir}/modules/ # Extensible Authentication Protocol # # For all EAP related authentications. # Now in another file, because it is very large. # $INCLUDE eap.conf # # Include another file that has the SQL-related configuration. This is another file only because it tends to be big.
Page 34 of 46
# $INCLUDE sql.conf # # This module is an SQL enabled version of the counter module. # # Rather than maintaining seperate (GDBM) databases of # accounting info for each counter, this module uses the data # stored in the raddacct table by the sql modules. This # module NEVER does any database INSERTs or UPDATEs. It is # totally dependent on the SQL module to process Accounting # packets. # $INCLUDE sql/mysql/counter.conf #$INCLUDE sql/postgresql/counter.conf # # IP addresses managed in an SQL table. # #$INCLUDE sqlippool.conf # OTP token support. # $INCLUDE otp.conf } # Instantiation # # This section orders the loading of the modules. Modules # listed here will get loaded BEFORE the later sections like # authorize, authenticate, etc. get examined. # # This section is not strictly needed. When a section like # authorize refers to a module, it's automatically loaded and # initialized. However, some modules may not be listed in any # of the following sections, so they can be listed here. # # Also, listing modules here ensures that you have control over # the order in which they are initalized. If one module needs # something defined by another module, you can list them in order # here, and ensure that the configuration will be OK. # instantiate { # # Allows the execution of external scripts. # The entire command line (and output) must fit into 253 bytes. # # e.g. Framed-Pool = `%{exec:/bin/echo foo}` exec # # # # # # # The expression module doesn't do authorization, authentication, or accounting. It only does dynamic translation, of the form: Session-Timeout = `%{expr:2 + 3}` Not included by default.
Page 35 of 46
# So the module needs to be instantiated, but CANNOT be # listed in any other section. See 'doc/rlm_expr' for # more information. # expr # # We add the counter module here so that it registers # the check-name attribute before any module which sets # it daily expiration logintime # subsections here can be thought of as "virtual" modules. # # e.g. If you have two redundant SQL servers, and you want to # use them in the authorize and accounting sections, you could # place a "redundant" block in each section, containing the # exact same text. Or, you could uncomment the following # lines, and list "redundant_sql" in the authorize and # accounting sections. # #redundant redundant_sql { # sql1 # sql2 #}
###################################################################### # # Policies that can be applied in multiple places are listed # globally. That way, they can be defined once, and referred # to multiple times. # ###################################################################### # # We add the counter module here so that it registers # the check-name attribute before any module which sets # it # daily expiration logintime # subsections here can be thought of as "virtual" modules. # # e.g. If you have two redundant SQL servers, and you want to # use them in the authorize and accounting sections, you could # place a "redundant" block in each section, containing the # exact same text. Or, you could uncomment the following # lines, and list "redundant_sql" in the authorize and # accounting sections. # #redundant redundant_sql { # sql1 # sql2 #}
Page 36 of 46
} ###################################################################### # # Policies that can be applied in multiple places are listed # globally. That way, they can be defined once, and referred # to multiple times. # ###################################################################### $INCLUDE policy.conf ###################################################################### # # As of 2.0.0, the "authorize", "authenticate", etc. sections # are in separate configuration files, per virtual host. # ###################################################################### ###################################################################### # # Include all enabled virtual hosts. # # The following directory is searched for files that match # the regex: # # /[a-zA-Z0-9_.]+/ # # The files are then included here, just as if they were cut # and pasted into this file. # # See "sites-enabled/default" for some additional documentation. # $INCLUDE sites-enabled/
[sql.conf]
# -*- text -*## ## sql.conf -- SQL modules ## ## $Id$ ###################################################################### # # Configuration for the SQL module # # The database schemas and queries are located in subdirectories: # # sql/DB/schema.sql Schema # sql/DB/dialup.conf Basic dialup (including policy) queries # sql/DB/counter.conf counter # sql/DB/ippool.conf IP Pools in SQL # sql/DB/ippool.sql schema for IP pools.
Page 37 of 46
# # #
Where "DB" is mysql, mssql, oracle, or postgresql.
sql {
# # Set the database to one of: # # mysql, mssql, oracle, postgresql # database = "mysql" # # Which FreeRADIUS driver to use. # driver = "rlm_sql_${database}" # Connection info: server = "radsrvr" #port = 3306 login = "radius" password = "radpass"
# Database table configuration for everything except Oracle radius_db = "radius" # If you are using Oracle then use this instead # radius_db = "(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=localhost) (PORT=1521))(CONNECT_DATA=(SID=your_sid)))" # If you want both stop and start records logged to the # same SQL table, leave this as is. If you want them in # different tables, put the start table in acct_table1 # and stop table in acct_table2 acct_table1 = "radacct" acct_table2 = "radacct" # Allow for storing data after authentication postauth_table = "radpostauth" # If you are using Oracle then use this instead # radius_db = "(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=localhost) (PORT=1521))(CONNECT_DATA=(SID=your_sid)))" # If you want both stop and start records logged to the # same SQL table, leave this as is. If you want them in # different tables, put the start table in acct_table1 # and stop table in acct_table2 acct_table1 = "radacct" acct_table2 = "radacct" # Allow for storing data after authentication postauth_table = "radpostauth" authcheck_table = "radcheck" authreply_table = "radreply" groupcheck_table = "radgroupcheck" groupreply_table = "radgroupreply"
Page 38 of 46
# Table to keep group info usergroup_table = "radusergroup" # If set to 'yes' (default) we read the group tables # If set to 'no' the user MUST have Fall-Through = Yes in the radreply table # read_groups = yes # Remove stale session if checkrad does not see a double login deletestalesessions = yes # Print all SQL statements when in debug mode (-x) #sqltrace = no .... this the default... sqltrace = yes sqltracefile = ${logdir}/sqltrace.sql # number of sql connections to make to server num_sql_socks = 5 # number of seconds to dely retrying on a failed database # connection (per_socket) connect_failure_retry_delay = 60 table) # Set to 'yes' to read radius clients from the database ('nas' # Clients will ONLY be read on server startup. For performance # and security reasons, finding clients via SQL queries CANNOT # be done "live" while the server is running. # #readclients = yes # Table to keep radius client info nas_table = "nas" # Read driver-specific configuration $INCLUDE sql/${database}/dialup.conf
[clients.conf] This config file is to test the working of radiusd.
root@radsrvr:/usr/local/etc/raddb# less clients.conf # -*- text -*## ## clients.conf -- client configuration directives ## ## $Id$ ####################################################################### # # Define RADIUS clients (usually a NAS, Access Point, etc.). #
Page 39 of 46
# # # # # # # #
Defines a RADIUS client. '127.0.0.1' is another name for 'localhost'. It is enabled by default, to allow testing of the server after an initial installation. If you are not going to be permitting RADIUS queries from localhost, we suggest that you delete, or comment out, this entry.
# # Each client has a "short name" that is used to distinguish it from # other clients. # # In version 1.x, the string after the word "client" was the IP # address of the client. In 2.0, the IP address is configured via # the "ipaddr" or "ipv6addr" fields. For compatibility, the 1.x # format is still accepted. # client radsrvr { # Allowed values are: # dotted quad (1.2.3.4) # hostname (radius.example.com) #ipaddr = 127.0.0.1 ipaddr = 192.168.107.52 # OR, you can use an IPv6 address, but not both # at the same time. ipv6addr = :: # any. ::1 == localhost # # # # # # # # # # # # # # # # # # # # # # # # # # # A note on DNS: We STRONGLY recommend using IP addresses rather than host names. Using host names means that the server will do DNS lookups when it starts, making it dependent on DNS. i.e. If anything goes wrong with DNS, the server won't start! The server also looks up the IP address from DNS once, and only once, when it starts. If the DNS record is later updated, the server WILL NOT see that update. One client definition can be applied to an entire network. e.g. 127/8 should be defined with "ipaddr = 127.0.0.0" and "netmask = 8" If not specified, the default netmask is 32 (i.e. /32) We do NOT recommend using anything other than 32. There are usually other, better ways to acheive the same goal. Using netmasks of other than 32 can cause security issues. You can specify overlapping networks (127/8 and 127.0/16) In that case, the smallest possible network will be used as the "best match" for the client. Clients can also be defined dynamically at run time, based on any criteria. e.g. SQL lookups, keying off of NAS-
Page 40 of 46
Identifier, # etc. # See raddb/sites-available/dynamic-clients for details. # netmask = 32 # # The shared secret use to "encrypt" and "sign" packets between # the NAS and FreeRADIUS. You MUST change this secret from the # default, otherwise it's not a secret any more! # # The secret can be any string, up to 8k characters in length. # # Control codes can be entered vi octal encoding, # e.g. "\101\102" == "AB" # Quotation marks can be entered by escaping them, # e.g. "foo\"bar" # # A note on security: The security of the RADIUS protocol # depends COMPLETELY on this secret! We recommend using a # shared secret that is composed of: # # upper case letters # lower case letters # numbers # # And is at LEAST 8 characters long, preferably 16 characters in # length. The secret MUST be random, and should not be words, # phrase, or anything else that is recognizable. # # The default secret below is only for testing, and should # not be used in any real environment. # secret = testing123 # # Old-style clients do not send a Message-Authenticator # in an Access-Request. RFC 5080 suggests that all clients # SHOULD include it in an Access-Request. The configuration # item below allows the server to require it. If a client # is required to include a Message-Authenticator and it does # not, then the packet will be silently discarded. # # allowed values: yes, no require_message_authenticator = no # # The short name is used as an alias for the fully qualified # domain name, or the IP address. # # It is accepted for compatibility with 1.x, but it is no # longer necessary in 2.0 # shortname = localhost #
Page 41 of 46
# the following three fields are optional, but may be used by # checkrad.pl for simultaneous use checks # # # The nastype tells 'checkrad.pl' which NAS-specific method to # use to query the NAS for simultaneous use. # # Permitted NAS types are: # # cisco # computone # livingston # max40xx # multitech # netserver # pathras # patton # portslave # tc # usrhiper # other # for all other types # nastype = other # localhost isn't usually a NAS...
# #
# # The following two configurations are for future use. # The 'naspasswd' file is currently used to store the NAS # login name and password, which is used by checkrad.pl # when querying the NAS for simultaneous use. # login = !root password = someadminpas # # As of 2.0, clients can also be tied to a virtual server. # This is done by setting the "virtual_server" configuration # item, as in the example below. # virtual_server = home1
# }
# IPv6 Client #client ::1 { # secret = testing123 # shortname = localhost #} # # All IPv6 Site-local clients #client fe80::/16 { # secret = testing123 # shortname = localhost #} #client some.host.org { # secret = testing123
Page 42 of 46
# #}
shortname
= localhost
# # You can now specify one secret for a network of clients. # When a client request comes in, the BEST match is chosen. # i.e. The entry from the smallest possible network. # #client 192.168.0.0/24 { # secret = testing123-1 # shortname = private-network-1 #} # #client 192.168.0.0/16 { # secret = testing123-2 # shortname = private-network-2 #} #client # # # # # # # # #} 10.10.10.10 { # secret and password are mapped through the "secrets" file. secret = testing123 shortname = liv1 # the following three fields are optional, but may be used by # checkrad.pl for simultaneous usage checks nastype = livingston login = !root password = someadminpas
####################################################################### # # Per-socket client lists. The configuration entries are exactly # the same as above, but they are nested inside of a section. # #client fe80::/16 { # secret = testing123 # shortname = localhost #} #client some.host.org { # secret = testing123 # shortname = localhost #} # # You can now specify one secret for a network of clients. # When a client request comes in, the BEST match is chosen. # i.e. The entry from the smallest possible network. # #client 192.168.0.0/24 { # secret = testing123-1 # shortname = private-network-1 #} # #client 192.168.0.0/16 { # secret = testing123-2
Page 43 of 46
# #} #client # # # # # # # # #}
shortname
= private-network-2
10.10.10.10 { # secret and password are mapped through the "secrets" file. secret = testing123 shortname = liv1 # the following three fields are optional, but may be used by # checkrad.pl for simultaneous usage checks nastype = livingston login = !root password = someadminpas
####################################################################### # # Per-socket client lists. The configuration entries are exactly # the same as above, but they are nested inside of a section. # # You can have as many per-socket client lists as you have "listen" # sections, or you can re-use a list among multiple "listen" sections. # # Un-comment this section, and edit a "listen" section to add: # "clients = per_socket_clients". That IP address/port combination # will then accept ONLY the clients listed in this section. # #clients per_socket_clients { # client 192.168.3.4 { # secret = testing123 # } #}
10 Appendix-III:(admin.sql, schema.sql, loadusers.sh)

[admin.sql] root@radsrvr:/usr/local/etc/raddb/sql/ndb# cat admin.sql # -*- text -*## ## admin.sql -- MySQL commands for creating the RADIUS user. ## ## WARNING: You should change 'localhost' and 'radpass' ## to something else. Also update raddb/sql.conf ## with the new RADIUS password. ## ## $Id$ # # Create default administrator for RADIUS # CREATE USER 'radius'@'localhost'; SET PASSWORD FOR 'radius'@'localhost' = PASSWORD('radpass');
Page 44 of 46
# The server can read any table in SQL GRANT ALL ON radius.* TO 'radius'@'localhost' identified by 'radpass'; GRANT ALL ON radius.* TO 'radius'@'radsrvr' identified by 'radpass'; # The server can write to the accounting and post-auth logging table. # # i.e. #GRANT ALL on radius.radacct TO 'radius'@'localhost' identified by 'radpass'; #GRANT ALL on radius.radacct TO 'radius'@'radsrvr' identified by 'radpass';
[schema.sql] Trimmed to show the storage engine at the end of the statement.
# # Table structure for table 'radreply' # CREATE TABLE radreply ( id int(11) unsigned NOT NULL auto_increment, username varchar(64) NOT NULL default '', attribute varchar(32) NOT NULL default '', op char(2) NOT NULL DEFAULT '=', value varchar(253) NOT NULL default '', PRIMARY KEY (id), KEY username (username(32)) ) ENGINE=ndbcluster; [loadusers.sh]
root@radsrvr:/usr/local/etc/raddb/sql/ndb/scripts# cat loadusers.sh #!/usr/bin/bash #set -x StartCount=1; #EndCount=10000000; EndCount=100; SQLServer='radsrvr'; SQLUser='radius'; SQLPassword='radpass'; DBName='radius'; i=$StartCount; while [ $i -le $EndCount ] do echo "user$i is being created"; /usr/local/mysql/bin/mysql -u${SQLUser} -h${SQLServer} -p${SQLPassword} $ {DBName} -e "INSERT INTO radcheck (username, Attribute, op, Value) values('user${i}', 'Cleartext-Password', ':=', 'user${i}');" /usr/local/mysql/bin/mysql -u${SQLUser} -h${SQLServer} -p${SQLPassword} $ {DBName} -e "INSERT INTO radreply (username, Attribute, op, Value) values('user${i}', 'Reply-Message', ':=', 'Hello user${i}');" echo "user$i creation is completed...";
Page 45 of 46
i=$(( $i + 1 )) done
Page 46 of 46

Mysql WP Deploying Free Radius

Загружено:

Сведения о документе

Исходное описание:

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Mysql WP Deploying Free Radius

Загружено:

Авторское право:

Доступные форматы

Deploying FreeRADIUS with the MySQL Cluster Database

A MySQL & FreeRADIUS Deployment Guide

Copyright 2009, MySQL & Network RADIUS

3 DEPLOYING FREERADIUS WITH MYSQL CLUSTER............................................................. 6

4 CONFIGURING FREERADIUS WITH MYSQL CLUSTER:..................................................... 10

Copyright 2009, MySQL & Network RADIUS

Copyright 2009, MySQL & Network RADIUS

2.2 MySQL Cluster Database

Copyright 2009, MySQL & Network RADIUS

2.2.1 What is MySQL Cluster ?

Copyright 2009, MySQL & Network RADIUS

2.3 Sun Fire X4200 Servers

3 Deploying FreeRADIUS with MySQL Cluster

Figure 2: FreeRADIUS with MySQL Cluster using VRRP

Copyright 2009, MySQL & Network RADIUS

3.1 Deployment Topologies

Copyright 2009, MySQL & Network RADIUS

Copyright 2009, MySQL & Network RADIUS

The software processes deployed are:

Four Data Nodes, 1 FreeRADIUS node: Five Servers (Configuration 2)

Copyright 2009, MySQL & Network RADIUS

4 Configuring FreeRADIUS with MySQL Cluster:

Copyright 2009, MySQL & Network RADIUS

4.1 Configuring MySQL Cluster:

Copyright 2009, MySQL & Network RADIUS

3. Provide the hostnames for the following

Copyright 2009, MySQL & Network RADIUS

Copyright 2009, MySQL & Network RADIUS

Copyright 2009, MySQL & Network RADIUS

(mysql-5.1.32 ndb-7.0.5) (mysql-5.1.32 ndb-7.0.5)

Copyright 2009, MySQL & Network RADIUS

| ndbcluster | NdbCall sizeof=24 | ndbcluster | NdbBlob sizeof=496 | ndbcluster | NdbReceiver sizeof=144

| created=0, free=0, | created=0, free=0, | created=0, free=0, | |

4.2 Configure FreeRADIUS to use MySQL Cluster:

Copyright 2009, MySQL & Network RADIUS

Query OK, 1 row affected (0.01 sec) mysql>

Create the RADIUS user account in the database

root@radsrvr:/usr/local/etc/raddb/sql/ndb# /usr/local/mysqlcluster/bin/mysql -uroot -p radius < schema.sql Enter password: root@radsrvr:/usr/local/etc/raddb/sql/ndb#

3. Bring up the "radiusd" FreeRADIUS server.

4.3 Testing the FreeRADIUS & MySQL Cluster Configuration

root@radsrvr:/# radtest user50 user50 radsrvr 0 testing123

Copyright 2009, MySQL & Network RADIUS

Copyright 2009, MySQL & Network RADIUS

6 References and Further Reading

Copyright 2009, MySQL & Network RADIUS

Copyright 2009, MySQL & Network RADIUS

Copyright 2009, MySQL & Network RADIUS

Copyright 2009, MySQL & Network RADIUS

9 Appendix-II: (radiusd.conf, sql.conf, clients.conf)

Copyright 2009, MySQL & Network RADIUS

Copyright 2009, MySQL & Network RADIUS

Copyright 2009, MySQL & Network RADIUS

Copyright 2009, MySQL & Network RADIUS

Copyright 2009, MySQL & Network RADIUS

# at the same time. ipv6addr = :: # any.

Copyright 2009, MySQL & Network RADIUS

Copyright 2009, MySQL & Network RADIUS

Copyright 2009, MySQL & Network RADIUS

Copyright 2009, MySQL & Network RADIUS

Copyright 2009, MySQL & Network RADIUS

Copyright 2009, MySQL & Network RADIUS

Copyright 2009, MySQL & Network RADIUS