ipmi-config.conf

title: ipmi-config.conf(5)

summary: IPMI configuration file details

text:
# ipmi-config.conf(5)

## NAME
ipmi-config - IPMI configuration file details

## DESCRIPTION
Before many IPMI tools can be used over a network, a machine's Baseboard Management Controller (BMC) must be configured. The configuration can be quite daunting for those who do not know much about IPMI. This manpage hopes to provide enough information on BMC configuration so that you can configure the BMC for your system. When appropriate, typical BMC configurations will be suggested.

The following is an example configuration file partially generated by running the --checkout option with the ipmi-config(8) command. This configuration comes from the core category of configuration values (the default). This example configuration should be sufficient for most users after the appropriate local IP and MAC addresses are input. Following this example, separate sections of this manpage will discuss the different sections of the configuration file in more detail with explanations of how the BMC can be configured for different environments.

Note that many options may or may not be available on your particular machine. For example, Serial-Over-Lan (SOL) is available only on IPMI 2.0 machines. Therefore, if you are looking to configure an IPMI 1.5 machine, many of the SOL or IPMI 2.0 related options will be be unavailable to you. The number of configurable users may also vary for your particular machine.

The below configuration file and most of this manpage assume the user is interested in configuring a BMC for use with IPMI over LAN. Various configuration options from ipmi-config(8) have been left out or skipped because it is considered unnecessary. Future versions of this manpage will try to include more information.

```
     Section User1

      ## Give username

      ## Username NULL

      ## Give password or leave it blank to clear password

      Password mypassword

      ## Possible values: Yes/No or blank to not set

      Enable_User Yes

      ## Possible values: Yes/No

      Lan_Enable_Ipmi_Msgs Yes

      ## Possible values: Callback/User/Operator/Administrator/OEM_Proprietary/No_Access

      Lan_Privilege_Limit Administrator

        ## Possible values: 0-17, 0 is unlimited; May be reset to 0 if not specified

        ## Lan_Session_Limit

      ## Possible values: Yes/No

      SOL_Payload_Access Yes

     EndSection

     Section User2

      ## Give username

      Username user2

      ## Give password or leave it blank to clear password

      Password userpass

      ## Possible values: Yes/No or blank to not set

      Enable_User No

      ## Possible values: Yes/No

      Lan_Enable_Ipmi_Msgs No

      ## Possible values: Callback/User/Operator/Administrator/OEM_Proprietary/No_Access

      Lan_Privilege_Limit No_Access

        ## Possible values: 0-17, 0 is unlimited; May be reset to 0 if not specified

        ## Lan_Session_Limit

        ## Possible values: Yes/No

        SOL_Payload_Access No

     EndSection

     Section Lan_Channel

      ## Possible values: Disabled/Pre_Boot_Only/Always_Available/Shared

      Volatile_Access_Mode Always_Available

      ## Possible values: Yes/No

      Volatile_Enable_User_Level_Auth Yes

      ## Possible values: Yes/No

      Volatile_Enable_Per_Message_Auth Yes

      ## Possible values: Yes/No

      Volatile_Enable_Pef_Alerting No

      ## Possible values: Callback/User/Operator/Administrator/OEM_Proprietary/No_Access

      Volatile_Channel_Privilege_Limit Administrator

      ## Possible values: Disabled/Pre_Boot_Only/Always_Available/Shared

      Non_Volatile_Access_Mode Always_Available

      ## Possible values: Yes/No

      Non_Volatile_Enable_User_Level_Auth Yes

      ## Possible values: Yes/No

      Non_Volatile_Enable_Per_Message_Auth Yes

      ## Possible values: Yes/No

      Non_Volatile_Enable_Pef_Alerting No

      ## Possible values: Callback/User/Operator/Administrator/OEM_Proprietary/No_Access

      Non_Volatile_Channel_Privilege_Limit Administrator

     EndSection

     Section Lan_Conf

      ## Possible values: Unspecified/Static/Use_DHCP/Use_BIOS/Use_Others

      Ip_Address_Source Static

      ## Give valid IP Address

      Ip_Address 192.168.1.100

      ## Give valid MAC Address

      Mac_Address 00:0E:0E:FF:AA:12

      ## Give valid Subnet mask

      Subnet_Mask 255.255.255.0

      ## Give valid IP Address

      Default_Gateway_Ip_Address 192.168.1.1

      ## Give valid MAC Address

      Default_Gateway_Mac_Address 00:0E:0E:FF:AA:18

      ## Give valid IP Address

      Backup_Gateway_Ip_Address 192.168.1.2

      ## Give valid MAC Address

      Backup_Gateway_Mac_Address 00:0E:0E:FF:AA:15

     EndSection

     Section Lan_Conf_Auth

      ## Possible values: Yes/No

      Callback_Enable_Auth_Type_None No

      ## Possible values: Yes/No

      Callback_Enable_Auth_Type_Md2 No

      ## Possible values: Yes/No

      Callback_Enable_Auth_Type_Md5 No

      ## Possible values: Yes/No

      Callback_Enable_Auth_Type_Straight_Password No

      ## Possible values: Yes/No

      Callback_Enable_Auth_Type_Oem_Proprietary No

      ## Possible values: Yes/No

      User_Enable_Auth_Type_None No

      ## Possible values: Yes/No

      User_Enable_Auth_Type_Md2 Yes

      ## Possible values: Yes/No

      User_Enable_Auth_Type_Md5 Yes

      ## Possible values: Yes/No

      User_Enable_Auth_Type_Straight_Password No

      ## Possible values: Yes/No

      User_Enable_Auth_Type_Oem_Proprietary No

      ## Possible values: Yes/No

      Operator_Enable_Auth_Type_None No

      ## Possible values: Yes/No

      Operator_Enable_Auth_Type_Md2 Yes

      ## Possible values: Yes/No

      Operator_Enable_Auth_Type_Md5 Yes

      ## Possible values: Yes/No

      Operator_Enable_Auth_Type_Straight_Password No

      ## Possible values: Yes/No

      Operator_Enable_Auth_Type_Oem_Proprietary No

      ## Possible values: Yes/No

      Admin_Enable_Auth_Type_None No

      ## Possible values: Yes/No

      Admin_Enable_Auth_Type_Md2 Yes

      ## Possible values: Yes/No

      Admin_Enable_Auth_Type_Md5 Yes

      ## Possible values: Yes/No

      Admin_Enable_Auth_Type_Straight_Password No

      ## Possible values: Yes/No

      Admin_Enable_Auth_Type_Oem_Proprietary No

      ## Possible values: Yes/No

      Oem_Enable_Auth_Type_None No

      ## Possible values: Yes/No

      Oem_Enable_Auth_Type_Md2 No

      ## Possible values: Yes/No

      Oem_Enable_Auth_Type_Md5 No

      ## Possible values: Yes/No

      Oem_Enable_Auth_Type_Straight_Password No

      ## Possible values: Yes/No

      Oem_Enable_Auth_Type_Oem_Proprietary No

     EndSection

     Section Lan_Conf_Security_Keys

        ## Give string or blank to clear. Max 20 chars

        K_G

     EndSection

     Section Lan_Conf_Misc

      ## Possible values: Yes/No

      Enable_Gratuitous_Arps Yes

      ## Possible values: Yes/No

      Enable_Arp_Response No

      ## Give valid number. Intervals are 500 ms.

      Gratuitous_Arp_Interval 4

     EndSection

     Section Rmcpplus_Conf_Privilege

      ## Possible values: Unused/User/Operator/Administrator/OEM_Proprietary

      Maximum_Privilege_Cipher_Suite_Id_0 Unused

      ## Possible values: Unused/User/Operator/Administrator/OEM_Proprietary

      Maximum_Privilege_Cipher_Suite_Id_1 Unused

      ## Possible values: Unused/User/Operator/Administrator/OEM_Proprietary

      Maximum_Privilege_Cipher_Suite_Id_2 Unused

      ## Possible values: Unused/User/Operator/Administrator/OEM_Proprietary

      Maximum_Privilege_Cipher_Suite_Id_3 Administrator

      ## Possible values: Unused/User/Operator/Administrator/OEM_Proprietary

      Maximum_Privilege_Cipher_Suite_Id_4 Administrator

      ## Possible values: Unused/User/Operator/Administrator/OEM_Proprietary

      Maximum_Privilege_Cipher_Suite_Id_5 Administrator

      ## Possible values: Unused/User/Operator/Administrator/OEM_Proprietary

      Maximum_Privilege_Cipher_Suite_Id_6 Unused

      ## Possible values: Unused/User/Operator/Administrator/OEM_Proprietary

      Maximum_Privilege_Cipher_Suite_Id_7 Unused

      ## Possible values: Unused/User/Operator/Administrator/OEM_Proprietary

      Maximum_Privilege_Cipher_Suite_Id_8 Administrator

      ## Possible values: Unused/User/Operator/Administrator/OEM_Proprietary

      Maximum_Privilege_Cipher_Suite_Id_9 Administrator

      ## Possible values: Unused/User/Operator/Administrator/OEM_Proprietary

      Maximum_Privilege_Cipher_Suite_Id_10 Administrator

      ## Possible values: Unused/User/Operator/Administrator/OEM_Proprietary

      Maximum_Privilege_Cipher_Suite_Id_11 Unused

      ## Possible values: Unused/User/Operator/Administrator/OEM_Proprietary

      Maximum_Privilege_Cipher_Suite_Id_12 Administrator

      ## Possible values: Unused/User/Operator/Administrator/OEM_Proprietary

      Maximum_Privilege_Cipher_Suite_Id_13 Administrator

      ## Possible values: Unused/User/Operator/Administrator/OEM_Proprietary

      Maximum_Privilege_Cipher_Suite_Id_14 Administrator

     EndSection

     Section SOL_Conf

      ## Possible values: Yes/No

      Enable_SOL Yes

      ## Possible values: Callback/User/Operator/Administrator/OEM_Proprietary

      SOL_Privilege_Level Administrator

      ## Possible values: Yes/No

      Force_SOL_Payload_Authentication Yes

      ## Possible values: Yes/No

      Force_SOL_Payload_Encryption Yes

      ## Give a valid integer. Each unit is 5ms

      Character_Accumulate_Interval 50

      ## Give a valid number

      Character_Send_Threshold 100

      ## Give a valid integer

      SOL_Retry_Count 5

      ## Give a valid integer. Interval unit is 10ms

      SOL_Retry_Interval 50

      ## Possible values: Serial/9600/19200/38400/57600/115200

      Non_Volatile_Bit_Rate 115200

      ## Possible values: Serial/9600/19200/38400/57600/115200

      Volatile_Bit_Rate 115200

     EndSection
```

## Section User1, User2, ...
The User sections of the BMC configuration file are for username configuration for IPMI over LAN communication. The number of users available to be configured on your system will vary by manufacturer. With the exception of the Username for User1, all sections are identical.

The username(s) you wish to configure the BMC with are defined with Username. The first username under Section User1 is typically the NULL username and cannot be modified. The password for the username can be specified with Password. It can be left empty to define a NULL password. Each user you wish to enable must be enabled through the Enable_User configuration option. It is recommended that all usernames have non-NULL passwords or be disabled for security reasons.

Lan_Enable_Ipmi_Msgs is used to enable or disable IPMI over LAN access for the user. This should be set to "Yes" to allow IPMI over LAN tools to work.

Lan_Privilege_Limit specifies the maximum privilege level limit the user is allowed. Different IPMI commands have different privilege restrictions. For example, determining the power status of a machine only requires the "User" privilege level. However, power cycling requires the "Operator" privilege. Typically, you will want to assign atleast one user with a privilege limit of "Administrator" so that all system functions are available to atleast one user via IPMI over LAN.

Lan_Session_Limit specifies the number of simultaneous IPMI sessions allowed for the user. Most users will wish to set this to "0" to allow unlimited simultaneous IPMI sessions. This field is considered optional by IPMI standards, and may result in errors when attempting to configure it to a non-zero value. If errors to occur, setting the value back to 0 should resolve problems.

SOL_Payload_Access specifies if a particular user is allowed to connect with Serial-Over-LAN (SOL). This should be set to "Yes" to allow this username to use SOL.

The example configuration above disables "User2" but enables the default "NULL" (i.e. anonymous) user. Many IPMI tools (both open-source and vendor) do not allow the user to input a username and assume the NULL username by default. If the tools you are interested in using allow usernames to be input, then it is recommended that one of the non-NULL usernames be enabled and the NULL username disabled for security reasons. It is recommended that you disable the NULL username in section User1, so that users are required to specify a username for IPMI over LAN communication.

Some motherboards may require a Username to be configured prior to other fields being read/written. If this is the case, those fields will be set to <username-not-set-yet>.

## Section Lan_Channel
The Lan_Channel section configures a variety of IPMI over LAN configuration parameters. Both Volatile and Non_Volatile configurations can be set. Volatile configurations are immediately configured onto the BMC and will have immediate effect on the system. Non_Volatile configurations are only available after the next system reset. Generally, both the Volatile and Non_Volatile should be configured identically.

The Access_Mode parameter configures the availability of IPMI over LAN on the system. Typically this should be set to "Always_Available" to enable IPMI over LAN.

The Privilege_Limit sets the maximum privilege any user of the system can have when performing IPMI over LAN. This should be set to the maximum privilege level configured to a username. Typically, this should be set to "Administrator".

Typically User_Level_Auth and Per_Message_Auth should be set to "Yes" for additional security. Disabling User_Level_Auth allows "User" privileged IPMI commands to be executed without authentication. Disabling Per_Message_Auth allows fewer individual IPMI messages to require authentication.

## Section Lan_Conf
Those familiar with setting up networks should find most of the fields in this section self explanatory. The example BMC configuration above illustrates the setup of a static IP address. The field IP_Address_Source is configured with "Static". The IP address, subnet mask, and gateway IP addresses of the machine are respectively configured with the IP_Address, Subnet_Mask, Default_Gateway_Ip_Address, and Backup_Gateway_Ip_Address fields. The respective MAC addresses for the IP addresses are configured under Mac_Address, Default_Gateway_Mac_Address, and Backup_Gateway_Mac_Address.

It is not required to setup the BMC IP_Address to be the same P_Address used by your operating system for that network interface. However, if you choose to use a different address, an alternate ARP configuration may need to be setup.

To instead setup your BMC network information via DHCP, the field IP_Address_Source should be configured with "Use_DHCP".

It is recommended that static IP addresses be configured for address resolution reasons. See Lan_Conf_Misc below for a more detailed explanation.

## Section Lan_Conf_Auth
This section determines what types of password authentication mechanisms are allowed for users at different privilege levels under the IPMI 1.5 protocol. The currently supported authentication methods for IPMI 1.5 are None (no username/password required), Straight_Password (passwords are sent in the clear), MD2 (passwords are MD2 hashed), and MD5 (passwords are MD5 hashed). Different usernames at different privilege levels may be allowed to authenticate differently through this configuration. For example, a username with "User" privileges may be allowed to authenticate with a straight password, but a username with "Administrator" privileges may be allowed only authenticate with MD5.

The above example configuration supports MD2 and MD5 authentication for all users at the "User", "Operator", and "Administrator" privilege levels. All authentication mechanisms have been disabled for the "Callback" privilege level.

Generally speaking, you do not want to allow any user to authenticate with None or Straight_Password for security reasons. MD2 and MD5 are digital signature algorithms that can minimally encrypt passwords. If you have chosen to support the NULL username (enabled User1) and NULL passwords (NULL password for User1), you will have to enable the None authentication fields above to allow users to connect via None.

## Section Lan_Conf_Security_Keys
This section supports configuration of the IPMI 2.0 (including Serial-over-LAN) K_g key. If your machine does not support IPMI 2.0, this field will not be configurable.

The key is used for two-key authentication in IPMI 2.0. In most tools, when doing IPMI 2.0, the K_g can be optionally specified. It is not required for IPMI 2.0 operation.

In the above example, we have elected to leave this field blank so the K_g key is not used.

## Section Lan_Conf_Misc
This section lists miscellaneous IPMI over LAN configuration options. These are optional IPMI configuration options that are not implemented on all BMCs.

Normally, a client cannot resolve the ethernet MAC address without the remote operating system running. However, IPMI over LAN would not work when a machine is powered off or if the IP address used by the operating system for that network interface differs from the BMC IP Address. One way to work around this is through gratuitous ARPs. Gratuitous ARPs are ARP packets generated by the BMC and sent out to advertise the BMC's IP and MAC address. Other machines on the network can store this information in their local ARP cache for later IP/hostname resolution. This would allow IPMI over LAN to work when the remote machine is powered off. The Enable_Gratuitous_Arps option allows you to enable or disable this feature. The Gratuitous_Arp_Interval option allows you to configure the frequency at which gratuitous ARPs are sent onto the network.

Instead of gratuitous ARPs some BMCs are able to respond to ARP requests, even when powered off. If offerred, this feature can be enabled through the Enable_Arp_Response option.

Generally speaking, turning on gratuitous ARPs is acceptable. However, it will increase traffic on your network. If you are using IPMI on a large cluster, the gratuitous ARPs may easily flood your network. They should be tuned to occur less frequently or disabled. If disabled, the remote machine's MAC address should be permanently stored in the local ARP cache through arp(8).

See bmc-watchdog(8) for a method which allows gratuitous ARPs to be disabled when the operating system is running, but enabled when the system is down.

## Section Rmcpplus_Conf_Privilege
This section supports configuration of the IPMI 2.0 (including Serial-over-LAN) cipher suite IDs. If your machine does not support IPMI 2.0, the fields will not be configurable.

Each cipher suite ID describes a combination of an authentication algorithm, integrity algorithm, and encryption algorithm for IPMI 2.0. The authentication algorithm is used for user authentication with the BMC. The integrity algorithm is used for generating signatures on IPMI packets. The confidentiality algorithm is used for encrypting data. The configuration in this section enables certain cipher suite IDs to be enabled or disabled, and the maximum privilege level a username can authenticate with.

The following table shows the cipher suite ID to algorithms mapping:

0 - Authentication Algorithm = None; Integrity Algorithm = None; Confidentiality Algorithm = None

1 - Authentication Algorithm = HMAC-SHA1; Integrity Algorithm = None; Confidentiality Algorithm = None

2 - Authentication Algorithm = HMAC-SHA1; Integrity Algorithm = HMAC-SHA1-96; Confidentiality Algorithm = None

3 - Authentication Algorithm = HMAC-SHA1; Integrity Algorithm = HMAC-SHA1-96; Confidentiality Algorithm = AES-CBC-128

4 - Authentication Algorithm = HMAC-SHA1; Integrity Algorithm = HMAC-SHA1-96; Confidentiality Algorithm = xRC4-128

5 - Authentication Algorithm = HMAC-SHA1; Integrity Algorithm = HMAC-SHA1-96; Confidentiality Algorithm = xRC4-40

6 - Authentication Algorithm = HMAC-MD5; Integrity Algorithm = None; Confidentiality Algorithm = None

7 - Authentication Algorithm = HMAC-MD5; Integrity Algorithm = HMAC-MD5-128; Confidentiality Algorithm = None

8 - Authentication Algorithm = HMAC-MD5; Integrity Algorithm = HMAC-MD5-128; Confidentiality Algorithm = AES-CBC-128

9 - Authentication Algorithm = HMAC-MD5; Integrity Algorithm = HMAC-MD5-128; Confidentiality Algorithm = xRC4-128

10 - Authentication Algorithm = HMAC-MD5; Integrity Algorithm = HMAC-MD5-128; Confidentiality Algorithm = xRC4-40

11 - Authentication Algorithm = HMAC-MD5; Integrity Algorithm = MD5-128; Confidentiality Algorithm = None

12 - Authentication Algorithm = HMAC-MD5; Integrity Algorithm = MD5-128; Confidentiality Algorithm = AES-CBC-128

13 - Authentication Algorithm = HMAC-MD5; Integrity Algorithm = MD5-128; Confidentiality Algorithm = xRC4-128

14 - Authentication Algorithm = HMAC-MD5; Integrity Algorithm = MD5-128; Confidentiality Algorithm = xRC4-40

Generally speaking, HMAC-SHA1 based algorithms are stronger than HMAC-MD5, which are better than MD5-128 algorithms. AES-CBC-128 confidentiality algorithms are stronger than xRC4-128 algorithms, which are better than xRC4-40 algorithms. Cipher suite ID 3 is therefore typically considered the most secure. Some users may wish to set cipher suite ID 3 to a privilege level and disable all remaining cipher suite IDs.

The above example configuration has decided to allow any user with "Administrator" privileges use any Cipher Suite algorithm suite which requires an authentication, integrity, and confidentiality algorithm. Typically, the maximum privilege level configured to a username should be set for atleast one cipher suite ID. Typically, this is the "Administrator" privilege.

A number of cipher suite IDs are optionally implemented, so the available cipher suite IDs available your system may vary.

## Section SOL_Conf
This section is for setting up Serial-Over-Lan (SOL) and will only be available for configuration on those machines. SOL can be enabled with the Enable_SOL field. The minimum privilege level required for connecting with SOL is specified by SOL_Privilege_Level. This should be set to the maximum privilege level configured to a username that has SOL enabled. Typically, this is the "Administrator" privilege. Authentication and Encryption can be forced or not using the fields Force_SOL_Payload_Authentication and Force_SOL_Payload_Encryption respectively. It is recommended that these be set on. However, forced authentication and/or encryption support depend on the cipher suite IDs supported.

The Character_Accumulate_Interval, Character_Send_Threshold , SOL_Retry_Count and , SOL_Retry_Interval options are used to set SOL character output speeds. Character_Accumulate_Interval determines how often serial data should be regularly sent and Character_Send_Threshold indicates the character count that if passed, will force serial data to be sent. SOL_Retry_Count indicates how many times packets must be retransmitted if acknowledgements are not received. SOL_Retry_Interval indicates the timeout interval. Generally, the manufacturer recommended numbers will be sufficient. However, you may wish to experiment with these values for faster SOL throughput.

The Non_Volatile_Bit_Rate and Volatile_Bit_Rate determine the baudrate the BMC should use. This should match the baudrate set in the BIOS and operating system, such as agetty(8). Generally speaking, both the Volatile and Non_Volatile options should be set identically.

In addition to enabling SOL in this section, individual users most also be capable of connecting with SOL. See the section Section User1, User2, ... above for details.

## REPORTING BUGS
Report bugs to <freeipmi-users@gnu.org> or <freeipmi-devel@gnu.org>.

## SEE ALSO
freeipmi(7), bmc-watchdog(8), ipmi-config(8), agetty(8)

http://www.gnu.org/software/freeipmi/


ipmidetect.conf

package: freeipmi

title: ipmidetect.conf(5)

text:
# ipmidetect.conf(5)

## NAME
ipmidetect.conf - specify alternate default values for the ipmidetect library

## DESCRIPTION
Through a configuration file, system administrators may override the default values used in the ipmidetect_load_data(3) API function.

The configuration file is stored at /etc/freeipmi//ipmidetect.conf.

## CONFIGURATION OPTIONS
The following are a list of configuration options that can be specified in the configuration file. Each configuration option must be listed on a separate line. Arguments for an option are separated by any amount of whitespace. Multiple arguments are also separated by whitespace. Comments can be marked by using the pound sign ("#") character, and lines can be continued on the next using backslash ("\").

hostnames host1 host2 host3 ...

Specify the hostname of the server to reach. Multiple hostnames can be listed up to a maximum of 8.

port num

Specify the port.

timeout_len seconds

Specify the timeout length in seconds.

## FILES
/etc/freeipmi//ipmidetect.conf

## REPORTING BUGS
Report bugs to <freeipmi-users@gnu.org> or <freeipmi-devel@gnu.org>.

## COPYRIGHT
Copyright (C) 2007-2015 Lawrence Livermore National Security, LLC.

Copyright (C) 2007 The Regents of the University of California.

## SEE ALSO
libipmidetect(3), ipmidetect(8)

http://www.gnu.org/software/freeipmi/

branch: sisyphus


libipmiconsole.conf

title: libipmiconsole.conf(5)

text:
# libipmiconsole.conf(5)

## NAME
libipmiconsole.conf - specify default values for libipmiconsole

## DESCRIPTION
The Libipmiconsole configuration file can be used to set alternate default values for the libipmiconsole library. The configuration of these defaults may be useful for environments in which programs link to libipmiconsole but do not support configuration of libipmiconsole parameters. Users should be ware that setting alternate default values into libipmiconsole will affect all tools that link to the library, such as the ipmiconsole(8) tool. For users wishing to set alternate defaults to ipmiconsole(8) please use the freeipmi.conf(5) file instead.

The configuration file is stored at /etc/freeipmi//libipmiconsole.conf.

## FORMAT
The configuration options that can be specified in the configuration file are listed below. Each configuration option must be listed on a separate line. Arguments for an option are separated by any amount of whitespace. Multiple arguments are also separated by whitespace. Comments can be marked by using the pound sign ("#") character, and lines can be continued on the next using backslash ("\").

## CONTEXT IPMI CONFIG OPTIONS
Every SOL session is housed within an libipmiconsole context. The following defines IPMI config default values for each context created.

libipmiconsole-context-username USERNAME

Specify the default username to use.

libipmiconsole-context-password PASSWORD

Specify the default password to use.

libipmiconsole-context-k_g str

Specify the default BMC key (K_g) to use. Prefix with '0x' to enter the key in hex.

libipmiconsole-context-privilege-level PRIVILEGE-LEVEL

Specify the default privilege type to use. The following privilege levels are supported: USER, OPERATOR, ADMIN.

libipmiconsole-context-cipher-suite-id CIPHER-SUITE-ID

Specify the default cipher suite id to use. The following cipher suite ids are supported: 0, 1, 2, 3, 6, 7, 8, 11, 12.

libipmiconsole-context-workaround-flags WORKAROUNDS

Specify default workaround flags to use. Multiple workarounds can be specified separated by whitespace. The following workarounds are supported: authcap, intel20, supermicro20, sun20, opensesspriv, integritycheckvalue, solpayloadsize, solport, solstatus, solchannelsupport, serialalertsdeferred, solpacketseq

## CONTEXT PROTOCOL CONFIG OPTIONS
Every SOL session is housed within an libipmiconsole context. The following defines protocol config default values for each context created.

libipmiconsole-context-session-timeout-len MILLISECONDS

Specify the default session timeout length to use in milliseconds.

libipmiconsole-context-retransmission-timeout-len MILLISECONDS

Specify the default retransmission timeout length to use in milliseconds.

libipmiconsole-context-retransmission-backoff-count NUM

Specify the default retransmission backoff count to use.

libipmiconsole-context-keepalive-timeout-len MILLISECONDS

Specify the default keepalive timeout length to use in milliseconds.

libipmiconsole-context-retransmission-keepalive-timeout-len MILLISECONDS

Specify the default retransmission timeout length to use for keepalive packets in milliseconds.

libipmiconsole-context-acceptable-packet-errors-count NUM

Specify the default packet errors count to use.

libipmiconsole-context-maximum-retransmission-count NUM

Specify the default maximum retransmission count to use.

## CONTEXT ENGINE CONFIG OPTIONS
Every SOL session is housed within an libipmiconsole context. The following defines engine config default values for each context created. Knowledge of the libipmiconsole library may be necessary to understand the meaning of these settings. Please see the ipmiconsole.h header file for additional information on the library.

libipmiconsole-context-engine-flags FLAGS

Specify default engine flags to use. Multiple flags can be specified separated by whitespace. The following flags are supported: closefd, outputonsolestablished, lockmemory, serialkeepalive.

libipmiconsole-context-behavior-flags FLAGS

Specify default behavior flags to use. Multiple flags can be specified separated by whitespace. The following flags are supported: erroronsolinuse, deactivateonly, deactivateallinstances.

libipmiconsole-context-debug-flags FLAGS

Specify default debug flags to use. Multiple flags can be specified separated by whitespace. The following flags are supported: stdout, stderr, syslog, file, ipmipackets.

libipmiconsole-context-sol-payload-instance NUM

Specify default SOL payload instance. Has range of 1 to 15.

## FILES
/etc/freeipmi//libipmiconsole.conf

## REPORTING BUGS
Report bugs to <freeipmi-users@gnu.org> or <freeipmi-devel@gnu.org>.

## COPYRIGHT
Copyright (C) 2007-2015 Lawrence Livermore National Security, LLC.

Copyright (C) 2006-2007 The Regents of the University of California.

FreeIPMI is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 3 of the License, or (at your option) any later version.

## SEE ALSO
freeipmi.conf(5), freeipmi(7), libipmiconsole(3), ipmiconsole(8),

http://www.gnu.org/software/freeipmi/


ipmidetectd.conf

package: freeipmi-ipmidetectd

title: ipmidetectd.conf(5)

summary: ipmidetectd configuration file

text:
# ipmidetectd.conf(5)

## NAME
ipmidetectd.conf - ipmidetectd configuration file

## DESCRIPTION
The ipmidetectd configuration file configures the ipmidetectd daemon.

The default configuration file loaded is /etc/freeipmi//ipmidetectd.conf.

The configuration options that can be specified in the configuration file are listed below. Each configuration option must be listed on a separate line. Arguments for an option are separated by any amount of whitespace. Multiple arguments are also separated by whitespace. Comments can be marked by using the pound sign ("#") character, and lines can be continued on the next using backslash ("\").

## IPMIDETECTD CONFIGURATION OPTIONS
ipmiping_period num

Specify the period time in milliseconds that IPMI pings should be regularly sent out. Default is 15000.

ipmidetectd_server_port port

Specify the alternate default port the ipmidetectd server should listen for requests off of. Default is 9225.

host string[:port]

Specify a host or IP address the ipmidetectd daemon should send IPMI pings to. Can be specified as many times as necessary. An optional port can be specified. Can accept host ranges as input. See HOSTRANGED SUPPORT in ipmidetect(8) for information on ranged formats. If specifying an IPv6 address and port, use the format [ADDRESS]:PORT.

## FILES
/etc/freeipmi//ipmidetectd.conf

## REPORTING BUGS
Report bugs to <freeipmi-users@gnu.org> or <freeipmi-devel@gnu.org>.

## COPYRIGHT
Copyright (C) 2007-2015 Lawrence Livermore National Security, LLC.

Copyright (C) 2007 The Regents of the University of California.

## SEE ALSO
ipmidetectd(8), ipmidetect(8)

http://www.gnu.org/software/freeipmi/


ipmiseld.conf

package: freeipmi-ipmiseld

title: ipmiseld.conf(5)

summary: ipmiseld configuration file

text:
# ipmiseld.conf(5)

## NAME
ipmiseld.conf - ipmiseld configuration file

## DESCRIPTION
The ipmiseld configuration file configures the ipmiseld daemon.

The default configuration file loaded is /etc/freeipmi//ipmiseld.conf.

The configuration options that can be specified in the configuration file are listed below. Each configuration option must be listed on a separate line. Arguments for an option are separated by any amount of whitespace. Multiple arguments are also separated by whitespace. Comments can be marked by using the pound sign ("#") character, and lines can be continued on the next using backslash ("\").

Note that it is possible to list the username, password and other potentially sensitive information in the configuration file. If this data is stored in a configuration file, system administrators should limit access to this file.

## IPMISELD CONFIGURATION OPTIONS
driver-type IPMIDRIVER

Specify the driver type to use.

disable-auto-probe ENABLE|DISABLE

Specify if IPMI devices should be probed for settings.

driver-address DRIVER-ADDRESS

Specify the in-band driver address to use.

driver-device DEVICE

Specify the in-band driver device path to use.

register-spacing REGISTER-SPACING

Specify the in-band driver register spacing to use.

target-channel-number CHANNEL-NUMBER

Specify the in-band driver target channel number.

target-slave-address SLAVE-ADDRESS

Specify the in-band driver target slave address.

hostname IPMIHOST1,IPMIHOST2,...

Specify the remote host(s) to communicate with. Multiple hostnames may be separated by comma or may be specified in a range format.

username USERNAME

Specify the username to use.

password PASSWORD

Specify the password to use.

k_g str

Specify the BMC key (K_g) to use. Prefix with '0x' to enter the key in hex.

session-timeout MILLISECONDS

Specify the session timeout length to use in milliseconds.

retransmission-timeout MILLISECONDS

Specify the retransmission timeout length to use in milliseconds.

authentication-type AUTHENTICATION-TYPE

Specify the authentication type to use. The following authentication types are supported: NONE, STRAIGHT_PASSWORD_KEY, MD2, and MD5.

cipher-suite-id CIPHER-SUITE-ID

Specify the cipher suite id to use. The following cipher suite ids are supported: 0, 1, 2, 3, 6, 7, 8, 11, 12.

privilege-level PRIVILEGE-LEVEL

Specify the privilege type to use. The following privilege levels are supported: USER, OPERATOR, ADMIN.

workaround-flags WORKAROUNDS

Specify workaround flags to use. Multiple workarounds can be specified separated by whitespace. Please see tool manpages for details about available workarounds for each tool. The following workarounds are supported: assumeio, spinpoll, idzero, forcepermsg, unexpectedauth, endianseq, authcap, intel20, supermicro20, sun20, opensesspriv, integritycheckvalue, assumesystemevent.

verbose-count COUNT

Specify default verbose count to use for ipmi-sel(8).

sensors-types TYPE-LIST

Specify sensor types of SEL events to log. Multiple types can be specified separated by whitespace. Users may specify sensor types by string or by number (decimal or hex). Please see ipmi-sel(8) --list-types option to see possible string input types.

exclude-sensor-types ENSOR-TYPES-LIST

Specify sensor types of SEL events to not log. default sensor types to not show sensor outputs for. Multiple sensor types can be specified separated by whitespace. Users may specify sensor types by string or by number. Please see ipmi-sel(8) --list-types option to see possible string input types.

system-event-only ENABLE|DISABLE

Specify if output should only include system event records.

oem-event-only ENABLE|DISABLE

Specify if output should only include OEM event records.

event-state-config-file FILE

Specify the event state configuration file.

interpret-oem-data ENABLE|DISABLE

Specify if ipmiseld should attempt to interpret OEM data or not.

entity-sensor-names ENABLE|DISABLE

Specify if output of sensor names should include entity ids and instances or not.

non-abbreviated-units ENABLE|DISABLE

Specify if output should have units abbreviated by default or not.

event-state-filter FILTERSTRING

Specify event states to be filtered out and not logged.

--warning-threshold PERCENTINT

Specify SEL fullness warning threshold as an integer percentage.

--clear-threshold PERCENTINT

Specify SEL fullness clear threshold as an integer percentage.

system-event-format FORMATSTRING

Specify the format of the log output when a SEL system event is encountered.

oem-timestamped-event-format FORMATSTRING

Specify the format of the log output when a SEL OEM timestamped event is encountered.

oem-non-timestamped-event-format FORMATSTRING

Specify the format of the log output when a SEL OEM non-timestamped event is encountered.

poll-interval SECONDS

Specify the poll interval to check the SEL for new events.

log-facility STRING

Specify the log facility to use.

log-priority STRING

Specify the log priority to use.

cache-directory DIRECTORY

Specify the cache directory to use.

ignore-sdr DISABLE

Specify if the SDR should be ignored.

re-download-sdr DISABLE

Specify if the SDR should be re-downloaded on start.

clear-sel DISABLE

Specify if the SEL should be cleared on start.

threadpool-count NUM

Specify the threadpool count for parallel SEL polling.

## FILES
/etc/freeipmi//ipmiseld.conf

## REPORTING BUGS
Report bugs to <freeipmi-users@gnu.org> or <freeipmi-devel@gnu.org>.

## COPYRIGHT
Copyright (C) 2012-2015 Lawrence Livermore National Security, LLC.

## SEE ALSO
ipmiseld(8), ipmi-sel(8)

http://www.gnu.org/software/freeipmi/


checkrad

package: freeradius

title: checkrad(5)

text:
# checkrad(5)

## NAME
checkrad -- See if a user is (still) logged in on a certain port.

## SYNOPSIS
checkrad [-d] nas-type nas-ip nas-port login session-id

## DESCRIPTION
Checkrad is used by the radius server to check if its idea of a user logged in on a certain port/NAS is correct if a double login is detected.

Returns: 0 = no duplicate, 1 = duplicate, >1 = error.

## OPTIONS
-d

Enable printing of debugging information.

nas-type

Type of port/NAS. Can be one of:

- ascend

- bay

- cisco

- cisco_l2tp

- computone

- cvx

- digitro

- dot1x

- livingston

- max40xx

- mikrotik

- mikrotik_snmp

- multitech

- netserver

- other

- pathras

- patton

- portslave

- pr3000

- pr4000

- redback

- tc

- usrhiper

- versanet

The "other" type cause checkrad to skip any check and always returns 1.

nas-ip

IP address of the NAS to check.

nas-port

The NAS port to check (may be ignored by some nas-type).

login

The login name to check.

session-id

Session to check. (actually ignored by all nas-type)

## SEE ALSO
radiusd(8)

## AUTHOR
Written by Miquel van Smoorenburg, miquels@cistron.nl.

This manual page was written by Marco Nenciarini <mnencia@debian.org> for the Debian project (but may be used by others).


clients.conf

title: clients.conf(5)

summary: FreeRADIUS client configuration

text:
# clients.conf(5)

## NAME
clients.conf - FreeRADIUS client configuration

## DESCRIPTION
The clients.conf file contains definitions of RADIUS clients.

The information in this file overrides any information provided in the deprecated clients and naslist files.

The file format is the same as that used for radiusd.conf. See radiusd.conf(5) for more details.

Each RADIUS client entry has the following basic form:

```
client <short-name> {

       <attribute> = <value>

 }
```

Clients have many configuration parameters. Most are documented in the file itself as comments. This page documents only the format of the file. Please read the clients.conf file itself for more information.

The old-style format from 1.x is still accepted by the server, but that form is deprecated.

## FILES
/etc/raddb/clients.conf

/etc/raddb/radiusd.conf

## SEE ALSO
radiusd(8), radiusd.conf(5)

## AUTHOR
FreeRADIUS is authored by the FreeRADIUS team. http://freeradius.org/


dictionary

title: dictionary(5)

summary: RADIUS dictionary file

text:
# dictionary(5)

## NAME
dictionary - RADIUS dictionary file

## DESCRIPTION
The master RADIUS dictionary file resides in /etc/raddb/dictionary. It references other dictionary files located in /usr/share/freeradius/. Each dictionary file contains a list of RADIUS attributes and values, which the server uses to map between descriptive names and on-the-wire data. The names have no meaning outside of the RADIUS server itself, and are never exchanged between server and clients.

That is, editing the dictionaries will have NO EFFECT on anything other than the server that is reading those files. Adding new attributes to the dictionaries will have NO EFFECT on RADIUS clients, and will not make RADIUS clients magically understand those attributes. The dictionaries are solely for local administrator convenience, and are specific to each version of FreeRADIUS.

The dictionaries in /usr/share SHOULD NOT be edited unless you know exactly what you are doing. Changing them will most likely break your RADIUS deployment.

If you need to add new attributes, please edit the /etc/raddb/dictionary file. It's sole purpose is to contain site-local definitions that are added by the local administrator.

## FORMAT
Every line starting with a hash sign ('#') is treated as comment and ignored.

Each line of the file can contain one of the following strings:

ATTRIBUTE name oid type [flags]

Define a RADIUS attribute name to number mapping. The name field is a printable field, taken from various specifications or vendor definitions. It is most commonly used as a series of words, separated by hyphens. e.g. "User-Name". Vendor-specific attributes (VSAs) are prefixed by the vendor name, e.g. "Cisco-AVPair". The names should be globally unique, as they are used as a key to look up the properties of the attribute.

The oid field is taken from the relevant specification for that name. In most cases, it is a decimal number, such as "256". For certain attributes, a "dotted number" notation is used, e.g. "1.2". The "dotted number" notation is used only for certain attributes.

The type field can be one of the standard types:

string UTF-8 printable text (the RFCs call this "text")

octets opaque binary data (the RFCs call this "string")

ipaddr IPv4 address

date Seconds since January 1, 1970 (32-bits)

integer 32-bit unsigned integer

ipv6addr IPv6 Address

ipv6prefix IPV6 prefix, with mask

ifid Interface Id (hex:hex:hex:hex)

integer64 64-bit unsigned integer

The type field can be one of the following non-standard types:

ether Ethernet MAC address

abinary Ascend binary filter format

byte 8-bit unsigned integer

short 16-bit unsigned integer

signed 31-bit signed integer (packed into 32-bit field)

tlv Type-Length-Value (allows nested attributes)

ipv4prefix IPv4 Prefix as given in RFC 6572.

The last (optional) field of an attribute definition are additional flags for that attribute, in a comma-separated list. Previous versions of the server allowed these flags to include a vendor name. This behavior may still work, but it is deprecated, and is not recommended.

The options are:

array Multiple values are packed into one attribute.

concat Multiple attributes should be concatenated

encrypt=# set encryption type 1, 2, or 3.

has_tag The attribute can have an RFC 2868 style tag

secret A value which should not be printed in debug mode

virtual The attribute is special to the server.

The "array" flag is only used for DHCP. It indicates that a DHCP option can contain an array of multiple values.

The "concat" flags indicates that when multiple attributes are present in a packet, the contents should be concatenated together to get the final contents. Similarly, when encoding packets, a long value should be split into multiple attributes.

The "encrypt" flag marks the attribute as being encrypted with one of three possible methods. "1" means that the attribute is encrypted with the method as defined in RFC2865 for the User-Password attribute. "2" means that the password is encrypted with the method as defined in RFC2868 for the Tunnel-Password attribute. "3" means that the attribute is encrypted as per Ascend's definitions for the Ascend-Send-Secret attribute.

The "has_tag" flag marks the attribute as being permitted to have a tag, as defined in RFC2868. The purpose of the tag is to allow grouping of attributes for tunneled users. See RFC2868 for more details.

The "secret" flag indicates that the value should not be printed in normal debug mode. The value will be printed when the debug level is 3 or higher.

The "virtual" flag is for the server, and indicates that the attribute does not really exist. Instead, the value is taken from an internal callback.

When the server receives an encoded attribute in a RADIUS packet, it looks up that attribute by number in the dictionary, and uses the definition found there for printing diagnostic and log messages. When the server sees an attribute name in a configuration file, it looks up that attribute by name in the dictionary, and uses the definition found there.

VALUE attribute-name value-name number

Define an attribute value name to number mapping, for an attribute of type integer. The attribute-name field MUST be previously defined by an ATTRIBUTE entry. The value-name field can be any non-space text, but is usually taken from RFC2865, or other documents.. The number field is also taken from the relevant documents, for that name. When the server receives an encoded value in a RADIUS packet, it looks up the value of that attribute by number in the dictionary, and uses the name found there for printing diagnostic and log messages.

VENDOR vendor-name number [format=...]

Define a Vendor Specific Attribute encapsulation for vendor-name to number. For a list of vendor names and numbers, see http://www.iana.org/enterprise-numbers.txt. The "format=t,l" statement tells the server how many octets to use to encode/decode the vendor "type" and "length" fields in the attributes. The default is "format=1,1", which does not have to be specified. For USR VSA's, the format is "format=4,0", for Lucent VSA's it's "format=2,1", and for Starent VSA's it's "format=2,2".

The supported values for the number of type octets (i.e. the first digit) are 1, 2, and 4. The support values for the number of length octets (i.e. the second digit) are 0, 1, and 2. Any combination of those values will work.

BEGIN-VENDOR vendor-name

Define the start of a block of Vendor-Specific attributes. All of the following ATTRIBUTE definitions are interpreted as being for the named vendor, until the block is closed by an "END-VENDOR" statement. This practice is preferred to placing the vendor name at the end of an ATTRIBUTE definition.

For VSAs in the RFC 6929 "Extended vendor-specific" space, a format can be specified following the "vendor-name". The format should be "format=Extended-Vendor-Specific-1", through "format=Extended-Vendor-Specific-6". The matching "END-VENDOR" should just have the "vendor-name", without the format string.

END-VENDOR vendor-name

End a previously defined BEGIN-VENDOR block. The "vendor-name" must match.

$INCLUDE filename

Include dictionary entries from the file filename. The filename is taken as relative to the location of the file which is asking for the inclusion.

BEGIN-TLV name

This feature is supported for backwards compatibility with older dictionaries. It should not be used. The new "oid" form for defining the attribute number should be used instead.

END-TLV name

This feature is supported for backwards compatibility with older dictionaries. It should not be used. The new "oid" form for defining the attribute number should be used instead.

## FILES
/etc/raddb/dictionary, /usr/share/freeradius/dictionary.*

## SEE ALSO
radiusd(8), RFC2865, RFC2866, RFC2868 RFC6929


radiusd.conf

title: radiusd.conf(5)

text:
# radiusd.conf(5)

## NAME
radiusd.conf - configuration file for the FreeRADIUS server

## DESCRIPTION
The radiusd.conf file resides in the radius database directory, by default /etc/raddb. It defines the global configuration for the FreeRADIUS RADIUS server.

## CONTENTS
There are a large number of configuration parameters for the server. Most are documented in the file itself as comments. This page documents only the format of the file. Please read the radiusd.conf file itself for more information.

The configuration file parser is independent of the server configuration. This means that you can put almost anything into the configuration file. So long as it is properly formatted, the server will start.

When the server parses the configuration file, it looks only for those configurations it understands. Extra configuration items are ignored. This "feature" can be (ab)used in certain interesting ways.

## FILE FORMAT
The file format is line-based, like many other Unix configuration files. Each entry in the file must be placed on a line by itself, although continuations are supported.

The file consists of configuration items (variable = value pairs), sections, and comments.

Variables

Variables can be set via:

```
	name = value
```

Single and double-quoted strings are permitted:

```
	string1 = "hello world"

	string2 = 'hello mom'
```

Sections

A section begins with a section name, followed on the same line by an open bracket '{'. Section may contain other sections, comments, or variables. Sections may be nested to any depth, limited only by available memory. A section ends with a close bracket ´}', on a line by itself.

```
	section {

		...

	}
```

Sections can sometimes have a second name following the first one. The situations where this is legal depend on the context. See the examples and comments in the radiusd.conf file for more information.

```
	section foo {

		...

	}
```

Comments

Any line beginning with a (#) is deemed to be a comment, and is ignored. Comments can appear after a variable or section definitions.

```
	# comment

	foo = bar # set variable 'foo' to value 'bar'

	section {	# start of section

	...

	}		# end of section
```

Continuations

Long lines can be broken up via continuations, using '\' as the last character of the line. For example, the following entry:

```
	foo = "blah \

	blah \

	blah"
```

will set the value of the variable "foo" to "blah blah blah". Any CR or LF is not turned into a space, but all other whitespace is preserved in the final value.

## REFERENCES
The value of a variable can reference another variable. These references are evaluated when the configuration file is loaded, which means that there is no run-time cost associated with them. This feature is most useful for turning long, repeated pieces of text into short ones.

Variables are referenced by ${variable_name}, as in the following examples.

```
	foo = bar       # set variable 'foo' to value 'bar'

	who = ${foo}    # sets variable 'who' to value of variable 'foo'

	my = "${foo} a" # sets variable 'my' to "bar a"
```

If the variable exists in a section or subsection, it can be referenced as ${section.subsection.variable}. Forward references are not allowed. Relative references are allowed, by pre-pending the name with one or more period.

```
	blogs = ${.foo}
```

Will set variable blogs to the value of variable foo, from the current section.

```
	blogs = ${..foo}
```

Will set variable blogs to the value of variable foo, from the section which contains the current section.

```
	blogs = ${modules.detail.filename}
```

Will set variable blogs to the value of variable filename, of the detail module, which is in the modules section of the configuration file.

Properties of anonymous parent sections may also be referenced, currently name and instance are supported.

```
	modules {
		example foo {
			file = ${.:name}
		}
	}

```

Will set variable file to the name of the containing section (example).

```
	modules {
		example foo {
			file = ${.:instance}
		}
	}

```

Will set variable file to the instance name of the containing section (foo).

```
	modules {
		example foo {
			file = ${..:name}
		}
	}

```

Will set variable file to the name of the parent of the containing section (modules).

## FILES
/etc/raddb/radiusd.conf

## SEE ALSO
radiusd(8) unlang(5)

## AUTHOR
Alan DeKok <aland@freeradius.org>


radrelay.conf

title: radrelay.conf(5)

text:
# radrelay.conf(5)

## NAME
radrelay.conf - configuration file for the FreeRADIUS server "radrelay" personality

## DESCRIPTION
The radrelay.conf file resides in the radius database directory, by default /etc/raddb. It defines the global configuration for the FreeRADIUS server, when the server is operating as "radrelay".

## FILE FORMAT
For a detailed description of the file format, see "man radiusd.conf". The configuration entries are much the same for radrelay.conf, with a few differences as noted here.

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

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

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

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

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

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

## RELAYING OF ACCOUNTING PACKETS
The radrelay.conf file controls the "radrelay" personality of the server, which can perform both of the functions above at the same time.

## USAGE
First, you should configure the main radius server to log to an extra, single detail file. This may be done by adding an extra instance of the detail module to radiusd.conf:

For example:

```
	detail radrelay-detail {

		filename = ${radacctdir}/radrelay/detail

		permissions = 0600

		dir_permissions = 0755

		locking = yes

	}

	...

	accounting {

		...

		radrelay-detail

		...

	}
```

This configuration will cause accounting packets to be logged to the ${radacctdir}/radrelay/detail file. This file should not be rotated by standard log rotation scripts, as the radrelay program will read and rotate it.

## RADRELAY.CONF EXAMPLE
See the radrelay.conf file for detailed instructions on configuration entries, what they mean, and how to use them.

To have the "radrelay" portion of the server read the above detail file, configure radrelay.conf with the following section:

```
	listen {

		type = detail

		filename = ${radacctdir}/radrelay/detail

		max_outstanding = 100

		identity = radrelay

	}
```

The server will read the accounting packets from the detail file, and process them just as if it had received them from the NAS. Therefore, you should configure the "accounting" section of radrelay.conf to write the accounting records to an "sql" module, or to proxy them to another RADIUS server.

Then, start the server via the following command:

$ radiusd -n radrelay

The server should start up, read the detail file, and process accounting packets from it.

## NOTES
The radiusd.conf file is not read at all when the server is running as radrelay. Please edit radrelay.conf.

## CREDITS
The original "radrelay" program was written by Miquel van Smoorenburg for the Cistron radius project, and ported to FreeRADIUS by Simon Ekstrand. The "radsqlrelay" was written by Kostas Kalavras. It was never released as part of an official FreeRADIUS release, but served as a basis for the design of this implementation.

## FILES
/etc/raddb/radrelay.conf

## SEE ALSO
radiusd(8), radiusd.conf(5)

## AUTHOR
Alan DeKok <aland@ox.org>


title: rlm_always(5)

summary: FreeRADIUS Module

text:
# rlm_always(5)

## NAME
rlm_always - FreeRADIUS Module

## DESCRIPTION
The rlm_always module provides a simple way to "always" return a value during the processing of a configuration section.

The main configuration item is rcode, which sets the return code that this instantiation of the module will return. The default, if none specified, is 'fail'.

The valid options for rcode are as follows:

reject

reject the user;

fail

a failure has occurred;

ok

success;

handled

the request has been handled: processing should be stopped and the response sent;

invalid

request is invalid;

userlock

the user account has been locked out;

notfound

the user account cannot be found;

noop

no-op: nothing has happened;

updated

the request has been updated.

## CONFIGURATION
rcode = <code>

This module will always return with the code specified, as listed in the table above. If unspecified, the default is 'fail'.

simulcount = <n>

If this module is used in the session{} section, the simulcount option simulates the user having 'n' current sessions. The default is to not override the number of sessions.

mpp = <yes|no>

If set to yes, and this module is used in the session{} section, this simulates the user having multilink sessions. The default is 'no'.

## EXAMPLE

```
modules {

  ...

  # instantiate the "always" module with the name "ok"

  always ok {

	# return code for this instantiation is "ok":

	rcode = ok

  }

  ...

}

authorize {

  ...

  redundant {

     sql1          # try to find the user in sql1

     sql2          # try to find the user in sql2

     # the default here would be to fail, but...

     ok            # if still not found, it's OK.

  }

  ...

}
```

## SECTIONS
authorization, authentication, postauthentication, preaccounting, accounting, preproxy, postproxy

## FILES
/etc/raddb/mods-available/always

## SEE ALSO
radiusd(8), radiusd.conf(5), unlang(5)

Further details of how module return codes operate can be found at <http://wiki.freeradius.org/config/Fail-over>.

## AUTHOR
Chris Parker <cparker@segv.org>, Matthew Newton <matthew@newtoncomputing.co.uk>.


title: rlm_attr_filter(5)

summary: FreeRADIUS Module

text:
# rlm_attr_filter(5)

## NAME
rlm_attr_filter - FreeRADIUS Module

## DESCRIPTION
The rlm_attr_filter module exists for filtering certain attributes and values in received ( or transmitted ) radius packets. It gives the server a flexible framework to filter the attributes we send to or receive from home servers or NASes. This makes sense, for example, in an out-sourced dialup situation to various policy decisions, such as restricting a client to certain ranges of Idle-Timeout or Session-Timeout.

Filter rules are normally defined and applied on a per-realm basis, where the realm is anything that is defined and matched based on the configuration of the rlm_realm module. Filter rules can optionally be applied using another attribute, by editing the key configuration for this module.

In 2.0.1 and earlier versions, the "accounting" section filtered the Accounting-Request, even though it was documented as filtering the response. This issue has been fixed in version 2.0.2 and later versions. The "preacct" section may now be used to filter Accounting-Request packets. The "accounting" section now filters Accounting-Response packets. Administrators using "attr_filter" in the "accounting" section SHOULD move the reference to "attr_filter" from "accounting" to "preacct".

The file that defines the attribute filtering rules follows a similar syntax to the users file. There are a few differences however:

```
    There are no check-items allowed other than the name of the key.
```

```
    There can only be a single DEFAULT entry.
```

```
The rules for each entry are parsed to top to bottom, and an
attribute must pass *all* the rules which affect it in order to
make it past the filter.  Order of the rules is important.
The operators and their purpose in defining the rules are as
follows:
```

=

```
THIS OPERATOR IS NOT ALLOWED.  If used, and warning message is
printed and it is treated as ==
```

:=

```
Set, this attribute and value will always be placed in the
output A/V Pairs.  If the attribute exists, it is overwritten.
```

==

```
Equal, value must match exactly.
```

=*

```
Always Equal, allow all values for the specified attribute.
```

!*

```
Never Equal, disallow all values for the specified attribute.
( This is redundant, as any A/V Pair not explicitly permitted
will be dropped ).
```

!=

```
Not Equal, value must not match.
```

>=

```
Greater Than or Equal
```

<=

```
Less Than or Equal
```

>

```
Greater Than
```

<

```
Less Than
```

```
If regular expressions are enabled the following operators are
also possible.  ( Regular Expressions are included by default
unless your system doesn't support them, which should be rare ).
The value field uses standard regular expression syntax.
```

=~

```
Regular Expression Equal
```

!~

```
Regular Expression Not Equal
```

```
See the default /etc/raddb/mods-config/attr_filter/ for working examples of
sample rule ordering and how to use the different operators.
```

The configuration items are:

file

This specifies the location of the file used to load the filter rules. This file is used to filter the accounting response, packet before it is proxied, proxy response from the home server, or our response to the NAS.

key

Usually %{Realm} (the default). Can also be %{User-Name}, or other attribute that exists in the request. Note that the module always keys off of attributes in the request, and NOT in any other packet.

relaxed

If set to 'yes', then attributes which do not match any filter rules explicitly, will also be allowed. This behaviour may be overridden for an individual filter block using the Relax-Filter check item. The default for this configuration item is 'no'.

## SECTIONS
preacct

Filters Accounting-Request packets.

accounting

Filters Accounting-Response packets.

pre-proxy

Filters Accounting-Request or Access-Request packets prior to proxying them.

post-proxy

Filters Accounting-Response, Access-Accept, Access-Reject, or Access-Challenge responses from a home server.

authorize

Filters Access-Request packets.

post-auth

Filters Access-Accept or Access-Reject packets.

## FILES
/etc/raddb/radiusd.conf /etc/raddb/mods-config/attr_filter/*

## SEE ALSO
radiusd(8), radiusd.conf(5)

## AUTHOR
Chris Parker, cparker@segv.org


title: rlm_chap(5)

summary: FreeRADIUS Module

text:
# rlm_chap(5)

## NAME
rlm_chap - FreeRADIUS Module

## DESCRIPTION
The rlm_chap module provides CHAP functionality.

This module validates a user with CHAP authentication. If called in Authorize, it will look for CHAP-Password attribute in the Access-Request and adds an Auth-Type attribute set to CHAP if the Config-Items list unless Auth-Type has already set.

CHAP authentication requires access to the clear-text password for the user. Standard Unix system authentication or passwords encrypted via crypt() are not compatible with CHAP.

## SECTIONS
authorization, authentication

## FILES
/etc/raddb/radiusd.conf

## SEE ALSO
radiusd(8), radiusd.conf(5)

## AUTHOR
Chris Parker, cparker@segv.org


title: rlm_counter(5)

summary: FreeRADIUS Module

text:
# rlm_counter(5)

## NAME
rlm_counter - FreeRADIUS Module

## DESCRIPTION
The rlm_counter module provides a general framework to allow access based on accumulated usage of a resource, such as total time online in a given period, total data transferred in a given period, etc. This is very useful in a 'Prepaid Service' situation, where a user has paid for a finite amount of usage and should not be allowed to use more than that service. Collection, monitoring, and replenishment of prepaid services are beyond the scope of this module.

The main configuration items to be aware of are:

filename

The filename where the usage data is stored.

key

An attribute which will be present in the Access-Request to be used as the 'index' value for the counter. A counter entry is tracked for each unique key. The most likely key you will want to use is User-Name.

count_attribute

An attribute which will be used to increment the counter value. If this attribute is Acct-Session-Time or an integer value the counter data is incremented by the Attribute value. For all other attribute types the counter is incremented by one.

reset

How frequently the counter data should be set back to 0. Valid values for this variable are: hourly, daily, weekly, monthly, ornever Alternatively, it can be user defined, in the form: num[hdwm]. num is a numeric value, followed by one or none of the following letters. h: hours, d: days, w: weeks, m: months.

check_name

This defines an attribute name which will be registered by the counter module and can be used to set the maximum allowed value for the counter after which the user is rejected. If Daily-Session-Time is set, you can use the following syntax in the Users file to set a cap of 3600 seconds ( 8 hours ):

```
DEFAULT Max-Daily-Session := 3600
```

reply_name

This is the name of the attribute which will contain the remaining value for the counter in the reply packet when the user is successfully authorized. The default attribute name is "Session-Timeout".

allowed_service_type

This can be used to only apply the limitations to specific service types of sessions. For example, setting this to Framed-User will only apply the counter module to Framed sessions, excluding other types such as Telnet or Rlogin.

cache_size

The maximum size of the cache to be used by the module. The default is 1000.

## NOTES
This module registers an attribute, so it should be added to the instantiate section, to be called on server startup. When used in the authorize section, it must come after any modules which set the 'check_name' attribute.

## SECTIONS
instantiate, authorize, accounting

## FILES
/etc/raddb/radiusd.conf

## SEE ALSO
radiusd(8), radiusd.conf(5) rlm_sqlcounter(5)

## AUTHOR
Chris Parker, cparker@segv.org


title: rlm_detail(5)

summary: FreeRADIUS Module

text:
# rlm_detail(5)

## NAME
rlm_detail - FreeRADIUS Module

## DESCRIPTION
The rlm_detail module writes radius packets to 'detail' files. It is primarily used for storing accounting information, but can be used in other sections to write packet details as well.

The file format is similar to that of the old Livingston servers, and many 'detail' file parsers should work with FreeRADIUS.

The main configuration items to be aware of are:

file

The file name in which to store the radius packet records. NOTE: this variable is run through dynamic string expansion, and can include FreeRADIUS variables to create a dynamic filename.

%{radacctdir}/%{Client-IP-Address}/detail-%Y%m

This will create one file per month, for each client.

This accomplishes 'file rotation' automatically from

within the server.

permissions

The file permissions of the file. If omitted, the default is 0600.

locking

This option is set to 'yes' or 'no'. By default it is 'no'. Set this to yes to enable file locking, which is used with the 'radrelay' program.

## CONFIGURATION

```
modules {

  ...

  detail {

    filename = ${radacctdir}/%{Client-IP-Address}/detail-%Y%m

    permissions = 0600

    dir_permissions = 0755

    locking = no

  }

  ...

}

  ...

accounting {

 ...

 detail

 ...

}
```

## SECTIONS
authorization, accounting, pre_proxy, post_proxy, post_authentication

## FILES
/etc/raddb/radiusd.conf

## SEE ALSO
radiusd(8), radiusd.conf(5)

## AUTHORS
Chris Parker, cparker@segv.org


title: rlm_digest(5)

summary: FreeRADIUS Module

text:
# rlm_digest(5)

## NAME
rlm_digest - FreeRADIUS Module

## DESCRIPTION
The rlm_digest module authenticates RADIUS Access-Request packets that contain Cisco SIP digest authentication attributes. The module should be listed in the authorize and authenticate sections of radiusd.conf.

## CONFIGURATION
The digest module requires no additional configuration items. When it is being used to authenticate requests, however, it does require access to the clear-text password for the user. Hashed passwords are not acceptable, and will not work.

## EXAMPLES
Add the following lines to the top of your 'raddb/users' file:

```
#---

test	Auth-Type := Digest, User-Password = "test"

	Reply-Message = "Hello, test with digest"

#---
```

Once the server has been started (debugging mode is recommended), use 'radclient to send the following packet to the server:

```
$  radclient -f digest localhost auth testing123
```

Where 'digest' is a file containing:

```
  User-Name = "test",

  Digest-Response = "631d6d73147add2f9e437f59bbc3aeb7",

  Digest-Realm = "testrealm",

  Digest-Nonce = "1234abcd",

  Digest-Method = "INVITE",

  Digest-URI = "sip:5555551212@example.com",

  Digest-Algorithm = "MD5",

  Digest-User-Name = "test",

  Message-Authenticator = ""
```

You should see the authentication succeed.

## SECTIONS
authorize, authenticate

## FILES
/etc/raddb/radiusd.conf, draft-sterman-aaa-sip-00.txt

## AUTHOR
Alan DeKok <aland@ox.org>


title: rlm_expr(5)

summary: FreeRADIUS Module

text:
# rlm_expr(5)

## NAME
rlm_expr - FreeRADIUS Module

## DESCRIPTION
The rlm_expr module allows the server to perform limited mathematical calculations. This module is not called directly in any section, it is invoked through the dynamic expansion of strings.

For example, some NAS boxes send a NAS-Port attribute which is a 32-bit number composed of port, card, and interface, all in different bytes. To see these attributes split into pieces, you can have an entry in the 'users' file like:

```
DEFAULT

    Vendor-Interface = `%{expr: %{NAS-Port} / (256 * 256)}`,

    Vendor-Card = `%{expr: (%{NAS-Port} / 256) %% 256}`,

    Vendor-Port = `%{expr: %{NAS-Port} %% 256}`
```

where the attributes Vendor-Interface, Vendor-Card, and Vendor-Port are attributes created by either you or a vendor-supplied dictionary.

The mathematical operators supported by the expression module are:

+

addition

-

subtraction

/

division

%%

modulo remainder

*

multiplication

&

boolean AND

|

boolean OR

()

grouping of sub-expressions

NOTE: The modulo remainder operator is '%%', and not '%'. This is due to the '%' character being used as a special character for dynamic translation.

NOTE: These operators do NOT have precedence. The parsing of the input string, and the calculation of the answer, is done strictly left to right. If you wish to order the expressions, you MUST group them into sub-expression, as shown in the previous example.

All of the calculations are performed as unsigned 32-bit integers.

## CONFIGURATION

```
modules {

  ...

  expr {

  }

  ...

}

 ...

instantiate {

  ...

  expr

  ...

}
```

## SECTIONS
instantiate

## FILES
/etc/raddb/radiusd.conf

## SEE ALSO
radiusd(8), radiusd.conf(5)

## AUTHOR
Chris Parker, cparker@segv.org


title: rlm_files(5)

summary: FreeRADIUS Module

text:
# rlm_files(5)

## NAME
rlm_files - FreeRADIUS Module

## DESCRIPTION
The rlm_files module uses the 'users' file for accessing authorization information for users. Additionally, it supports a 'users' file syntax to be applied to the accounting and pre-proxy sections.

The main configuration items to be aware of are:

usersfile

The filename of the 'users' file, which is parsed during the authorization stage of this module.

acctusersfile

The filename of the 'users' file, which is parsed during the accounting stage of this module.

preproxy_usersfile

The filename of the 'users' file, which is parsed during the pre_proxy stage of this module.

compat

This option allows FreeRADIUS to parse an old style Cistron syntax. The default is 'no'. If you need to parse an old style Cistron file, set this option to 'cistron'.

key

This option lets you set the attribute to use as a key to find entries. The default is "%{%{Stripped-User-Name}:-%{User-Name}}". Note that the key MUST supply real data. Dynamic attributes like "Group" will not work, because the "Group" attribute can only be used as a comparison, to see if a user is in a Unix group. It will not return the name of the Unix group that a user is in.

If you want to use groups as a key, see the rlm_passwd, which will create a real attribute that contains the group name.

This configuration entry enables you to have configurations that perform per-group checks, and return per-group attributes, where the group membership is dynamically defined by a previous module. It also lets you do things like key off of attributes in the reply, and express policies like "when I send replies containing attribute FOO with value BAR, do more checks, and maybe send additional attributes".

## CONFIGURATION

```
modules {

  ... stuff here ...

  files {

    usersfile = %{confdir}/users

    acctusersfile = %{confdir}/acct_users

    preproxy_usersfile = %{confdir}/preproxy_users

    compat = no

    key = %{%{Stripped-User-Name}:-%{User-Name}}

  }

  ... stuff here ...

}
```

## SECTIONS
authorization, accounting, pre_proxy

## FILES
/etc/raddb/radiusd.conf, /etc/raddb/users, /etc/raddb/acct_users, /etc/raddb/preproxy_users

## SEE ALSO
radiusd(8), radiusd.conf(5), users(5)

## AUTHORS
Chris Parker, cparker@segv.org


title: rlm_idn(5)

summary: FreeRADIUS Module

text:
# rlm_idn(5)

## NAME
rlm_idn - FreeRADIUS Module

## DESCRIPTION
When instantiated, the rlm_idn module provides an xlat for performing IDNA encoding of internationalized domain names. Decoding and other similar encodings like plain punycode are not currently supported.

For example, the following unlang expression would evaluate to TRUE:

"%{idn:fūbar.site}" == "xn--fbar-v7a.site"

Each instance of rlm_idn may take the following parameters:

use_std3_ascii_rules

This boolean is set by default and prohibits e.g. underscores in domain names.

allow_unassigned

This boolean is unset by default, which prohibits use of unassigned Unicode points.

## FILES
/etc/raddb/radiusd.conf

## REFERENCES
RFC 3490

## SEE ALSO
radiusd(8), radiusd.conf(5) idna_to_ascii_8z(3)

## AUTHOR
Brian S. Julin, bjulin@clarku.edu


title: rlm_mschap(5)

summary: FreeRADIUS Module

text:
# rlm_mschap(5)

## NAME
rlm_mschap - FreeRADIUS Module

## DESCRIPTION
The rlm_mschap module provides MS-CHAP and MS-CHAPv2 authentication support.

This module validates a user with MS-CHAP or MS-CHAPv2 authentication. If called in Authorize, it will look for MS-CHAP Challenge/Response attributes in the Acess-Request and adds an Auth-Type attribute set to MS-CHAP in the Config-Items list unless Auth-Type has already set.

The module can authenticate the MS-CHAP session via plain-text passwords (User-Password attribute), or NT passwords (NT-Password attribute). The module cannot perform authentication against an NT domain.

The module also enforces the SMB-Account-Ctrl attribute. See the Samba documentation for the meaning of SMB account control. The module does not read Samba password files. Instead, the fIrlm_passwd module can be used to read a Samba password file, and supply an NT-Password attribute which this module can use.

The main configuration items to be aware of are:

authtype

This is the string used to set the authtype. Normally it should be left to the default value of MS-CHAP.

use_mppe

Unless this is set to 'no', FreeRADIUS will add MS-CHAP-MPPE-Keys for MS-CHAPv1 and MS-MPPE-Recv-Key/MS-MPPE-Send-Key for MS-CHAPv2. The default is 'yes'.

require_encryption

If MPPE is enabled, setting this attribute to 'yes' will cause the MS-MPPE-Encryption-Policy attribute to be set to require encryption. The default is 'no'.

require_strong

If MPPE is enabled, setting this attribute to 'yes' will cause the MS-MPPE-Encryption-Types attribute to be set to require a 128 bit key. The default is 'no'.

with_ntdomain_hack

Windows clients send User-Name in the form of "DOMAIN\User", but send the challenge/response based only on the User portion. Setting this value to yes, enables a work-around for this error. The default is 'no'.

## CONFIGURATION

```
modules {

  ...

  mschap {

	authtype = MS-CHAP

	use_mppe = yes

  }

  ...

}

 ...

authorize {

  ...

  mschap

  ...

}

 ...

authenticate {

  ...

  mschap

  ...

}
```

## SECTIONS
authorization, authentication

## FILES
/etc/raddb/radiusd.conf

## SEE ALSO
radiusd(8), radiusd.conf(5)

## AUTHOR
Chris Parker, cparker@segv.org


title: rlm_pap(5)

summary: FreeRADIUS Module

text:
# rlm_pap(5)

## NAME
rlm_pap - FreeRADIUS Module

## DESCRIPTION
The rlm_pap module authenticates RADIUS Access-Request packets that contain a User-Password attribute. The module should also be listed last in the authorize section, so that it can set the Auth-Type attribute as appropriate.

When a RADIUS packet contains a clear-text password in the form of a User-Password attribute, the rlm_pap module may be used for authentication. The module requires a "known good" password, which it uses to validate the password given in the RADIUS packet. That "known good" password must be supplied by another module (e.g. rlm_files, rlm_ldap, etc.), and is usually taken from a database.

## CONFIGURATION
The only configuration item is:

normalise

The default is "yes". This means that the module will try to automatically detect passwords that are hex- or base64-encoded and decode them back to their binary representation. However, some clear text passwords may be erroneously converted. Setting this to "no" prevents that conversion.

## USAGE
The module looks for the Password-With-Header control attribute to find the "known good" password. The attribute value comprises the header followed immediately by the password data. The header is given by the following table.

```
Header       Attribute           Description

------       ---------           -----------

{clear}      Cleartext-Password  Clear-text passwords

{cleartext}  Cleartext-Password  Clear-text passwords

{crypt}      Crypt-Password      Unix-style "crypt"ed passwords

{md5}        MD5-Password        MD5 hashed passwords

{base64_md5} MD5-Password        MD5 hashed passwords

{smd5}       SMD5-Password       MD5 hashed passwords, with a salt

{sha}        SHA-Password        SHA1 hashed passwords

             SHA1-Password       SHA1 hashed passwords

{ssha}       SSHA-Password       SHA1 hashed passwords, with a salt

{sha2}       SHA2-Password       SHA2 hashed passwords

{sha224}     SHA2-Password       SHA2 hashed passwords

{sha256}     SHA2-Password       SHA2 hashed passwords

{sha384}     SHA2-Password       SHA2 hashed passwords

{sha512}     SHA2-Password       SHA2 hashed passwords

{ssha224}    SSHA2-224-Password  SHA2 hashed passwords, with a salt

{ssha256}    SSHA2-256-Password  SHA2 hashed passwords, with a salt

{ssha384}    SSHA2-384-Password  SHA2 hashed passwords, with a salt

{ssha512}    SSHA2-512-Password  SHA2 hashed passwords, with a salt

{nt}         NT-Password         Windows NT hashed passwords

{nthash}     NT-Password         Windows NT hashed passwords

{md4}        NT-Password         Windows NT hashed passwords

{x-nthash}   NT-Password         Windows NT hashed passwords

{ns-mta-md5} NS-MTA-MD5-Password Netscape MTA MD5 hashed passwords

{x- orcllmv} LM-Password         Windows LANMAN hashed passwords

{X- orclntv} NT-Password         Windows NT hashed passwords
```

The module tries to be flexible when handling the various password formats. It will automatically handle Base-64 encoded data, hex strings, and binary data, and convert them to a format that the server can use.

If there is no Password-With-Header attribute, the module looks for one of the Cleartext-Password, NT-Password, Crypt-Password, etc. attributes as listed in the above table. These attributes should contain the relevant format password directly, without the header prefix.

Only one control attribute should be set, otherwise behaviour is undefined as to which one is used for authentication.

## NOTES
It is important to understand the difference between the User-Password and Cleartext-Password attributes. The Cleartext-Password attribute is the "known good" password for the user. Simply supplying the Cleartext-Password to the server will result in most authentication methods working. The User-Password attribute is the password as typed in by the user on their private machine. The two are not the same, and should be treated very differently. That is, you should generally not use the User-Password attribute anywhere in the RADIUS configuration.

## SECTIONS
authorize authenticate

## FILES
/etc/raddb/mods-available/pap

## SEE ALSO
radiusd(8), radiusd.conf(5)

## AUTHOR
Alan DeKok <aland@freeradius.org>


title: rlm_passwd(5)

summary: FreeRADIUS Module

text:
# rlm_passwd(5)

## NAME
rlm_passwd - FreeRADIUS Module

## DESCRIPTION
The rlm_passwd module provides authorization via files similar in format to /etc/passwd.

This module allows you to retrieve any account information from any files with passwd-like format (/etc/passwd, /etc/group, smbpasswd, .htpasswd, etc). Every field of the file may be mapped to a RADIUS attribute, with one of the fields used as a key.

The module reads the file when it initializes, and caches the data in memory. This makes it very fast, even for files with thousands of lines. To re-read the file the module will need to be reloaded with radmin(8), or the server will need to be sent a SIGHUP, as dynamic updates are not supported.

## CONFIGURATION
The configuration item(s):

allow_multiple_keys

If set to 'yes', and more than one record in file matches the request, then the attributes from all records will be used. If set to 'no' (the default) the module will warn about duplicated records.

delimiter = ":"

The character to use as a delimiter between fields. The default is ":"

filename

The path to the file.

format

The format of the fields in the file, given as an example line from the file, with the content of the fields as the RADIUS attributes which the fields map to. The fields are separated by the ':' character in the configuration (no matter what is configured for the 'delimiter' option).

hash_size

The size of the hash table. A larger value means less probability of a collision so records will be found faster, at the expense of greater memory usage. Having a hash_size in the range of 30-100% of the number of passwd file records is reasonable.

ignore_empty

When set to "yes", the default, empty fields in the input will be skipped and the RADIUS attribute will not be added. By setting this value to "no", all attributes in the format list will always be added, even if they have no value.

ignore_nislike

If set to 'yes', then all records from the file beginning with the '+' sign will be ignored. The default is 'no'.

## FORMAT
The format option controls how lines are read from the file, and which fields are mapped to which RADIUS attributes.

The key field is the field being searched for within the file. It is normally signified by being preceded with a '*' character, which indicates that the field has only one key, like the /etc/passwd file. The key field may instead be preceded with '*,', which indicates that the field has multiple possible comma-separated keys, such as when searching the /etc/group file.

The other fields signify RADIUS attributes. By default they will be added as a control attribute list.

To add an attribute to the RADIUS request (as though it had been sent by the NAS), prefix the attribute name in the "format" string with the '~' character.

To add an attribute to the RADIUS reply (to be sent back to the NAS), prefix the attribute name in the "format" string with the '=' character.

## EXAMPLES

```
format = "*User-Name:Crypt-Password:"
```

For a file the looks similar to /etc/passwd. The first field, User-Name, is the key to look up in the file. When the record is found, a control attribute, 'Crypt-Password', will be added with the contents of the second field. (Note this will not work with shadow passwords.)

```
format = "My-Group:::*,User-Name"
```

Parse a file similar to the /etc/group file. An entry matches a request when the name in a User-Name attribute exists in the comma-separated list of a line in the file. When an entry matches, a "My-Group" attribute will be created and added to the control items for the request. The value of that attribute will be taken from the first field of the matching line in the file.

The ":::" in the format string means that there are extra two fields in the line, in between the group name and list of user names. Those fields do not map to any RADIUS attribute, and are therefore ignored.

For this example to work in practice, you will have to add the My-Group attribute to the dictionary file. See dictionary(5) for details on how this may be done.

```
format = "~My-Group:::*,User-Name"
```

Similar to the previous entry, except the My-Group attribute is added to the request, as though it was sent by the NAS.

## SECTIONS
authorize

## FILES
/etc/raddb/mods-available/passwd

## SEE ALSO
radiusd(8), radiusd.conf(5), radmin(8), dictionary(5), rlm_unix(5)

## AUTHOR
Alan DeKok <aland@freeradius.org>, Matthew Newton <matthew@newtoncomputing.co.uk>.


title: rlm_realm(5)

summary: FreeRADIUS Module

text:
# rlm_realm(5)

## NAME
rlm_realm - FreeRADIUS Module

## DESCRIPTION
The rlm_realm module parses the User-Name attribute into a User section and a Realm section. This is used primarily in a proxy situation, however, Realms can also be used locally to provide different service profiles based on the Realm being used.

The main configuration items to be aware of are:

format

This can be either 'prefix' or 'suffix'. It specifies whether the Realm is before or after the User portion in the User-Name string.

delimiter

A single character in quotes, which is used as the delimiting character that separates the Realm and User sections of the string.

ignore_default

This is set to either 'yes' or 'no'. If set to 'yes', this will prevent the module instance from matching a realm against the DEFAULT entry. This may be useful if you have multiple realm module instances. The default is 'no'.

ignore_null

This is set to either 'yes' or 'no'. If set to 'yes', this will prevent the module instance from matching a realm against the NULL entry. This may be useful if you have multiple realm module instances. The default is 'no'.

This module parses the realm from the User-Name attribute according to the instance configuration, and then performs a lookup to find a matching realm in the '/etc/raddb/proxy.conf' file. Depending on the configuration of the Realm as matched in the file, the username may be rewritten in a 'stripped' format, or with the Realm portion removed. In either case, a Realm attribute is created and added to the packet on a match, which can be used by other modules.

## CONFIGURATION

```
modules {

  ... stuff here ...

  # useranme@realm syntax

  realm suffix {

    format = suffix

    delimiter = "@"

  }

   # realm/username syntax

   realm prefix {

    format = prefix

    delimiter = "/"

  }

  ... stuff here ...

}
```

## SECTIONS
authorization, pre-accounting

## FILES
/etc/raddb/radiusd.conf, /etc/raddb/proxy.conf

## SEE ALSO
radiusd(8), radiusd.conf(5), proxy.conf(5)

## AUTHORS
Chris Parker, cparker@segv.org


title: rlm_sql(5)

summary: FreeRADIUS Module

text:
# rlm_sql(5)

## NAME
rlm_sql - FreeRADIUS Module

## DESCRIPTION
The rlm_sql module provides an SQL interface to retrieve authorization information and store accounting information. It can be used in conjunction with, or in lieu of the files and detail modules. The SQL module has drivers to support the following SQL databases:

```
     db2

     iodbc

     mysql

     oracle

     postgresql

     sybase

     unixodbc
```

Due to the size of the configuration variables, the sql module is usually configured in a separate file, which is included in the main radiusd.conf via an include directive.

The main configuration items to be aware of are:

driver

This variable specifies the driver to be loaded.

server

login

password

These specify the servername, username, and password the module will use to connect to the database.

radius_db

The name of the database where the radius tables are stored.

acct_table1

acct_table2

These specify the tables names for accounting records. acct_table1 specifies the table where Start records are stored. acct_table2 specifies the table where Stop records are stored. In most cases, this should be the same table.

postauth_table

The name of the table to store post-authentication data.

authcheck_table

authreply_table

The tables where individual Check-Items and Reply-Items are stored.

groupcheck_table

groupreply_table

The tables where group Check-Items and Reply-Items are stored.

usergroup_table

The table where username to group relationships are stored.

deletestalesessions

This option is set to 'yes' or 'no'. If you are doing Simultaneous-Use checking, and this is set to yes, stale sessions ( defined as sessions for which a Stop record was not received ) will be cleared.

logfile

This option is useful for debugging sql problems. If logfile is set then all sql queries for the containing section are written to the file specified. This is useful for debugging and bulk inserts.

num_sql_socks

The number of sql connections to make to the database.

connect_failure_retry_delay

The number of seconds to wait before attempting to reconnect to a failed database connection.

sql_user_name

This is the definition of the SQL-User-Name attribute. This is set once, so that you can use %{SQL-User-Name} in the SQL queries, rather than the nested username substitution. This ensures that Username is parsed consistently for all SQL queries executed.

default_user_profile

This is the default profile name that will be applied to all users if set. This is not set by default.

query_on_not_found

This option is set to 'yes' or 'no'. If set to yes, then the default user profile is returned if no specific match was found for the user.

authorize_check_query

authorize_reply_query

These queries are run during the authorization stage to extract the user authorization information from the ${authcheck_table} and ${authreply_table}.

authorize_group_check_query

authorize_group_reply_query

These queries are run during the authorization stage to extract the group authorization information from the ${groupcheck_table} and ${groupreply_table}.

accounting_onoff_query

The query to be run when receiving an Accounting On or Accounting Off packet.

accounting_update_query

accounting_update_query_alt

The query to be run when receiving an Accounting Update packet. If the primary query fails, the alt query is run.

accounting_start_query

accounting_start_query_alt

The query to be run when receiving an Accounting Start packet. If the primary query fails, the alt query is run.

accounting_stop_query

accounting_stop_query_alt

The query to be run when receiving an Accounting Stop packet. If the primary query fails, the alt query is run.

simul_count_query

The query to be run to return the number simultaneous sessions for the purposes of limiting Simultaneous Use.

simul_verify_query

The query to return the detail information needed to confirm that all suspected connected sessions are valid, and are not stale sessions.

group_membership_query

The query to run to check user group membership.

postauth_query

The query to run during the post-authentication stage.

## CONFIGURATION
Due to the size of the configuration for this module, it is not included in this manual page. Please review the supplied configuration files for example queries and configuration details.

## SECTIONS
authorization, accounting, checksimul, post-authentication

## FILES
/etc/raddb/radiusd.conf, /etc/raddb/sql.conf, /etc/raddb/sql/<DB>/dialup.conf, /etc/raddb/sql/<DB>/schema.sql,

## SEE ALSO
radiusd(8), radiusd.conf(5),

## AUTHORS
Chris Parker, cparker@segv.org


title: rlm_unbound(5)

summary: FreeRADIUS Module

text:
# rlm_unbound(5)

## NAME
rlm_unbound - FreeRADIUS Module

## DESCRIPTION
Each instance of rlm_unbound provides an embedded DNS client for performing DNS lookups. Each instance may be configured separately to query different DNS horizons, change DNSSEC options, etc.

The module is primarily intended for use by other modules through internal APIs, and so, instances should be initialized earlier than those modules which use them. Each instance does also provide some xlat functionalities for general use and for troubleshooting.

Each instance of rlm_unbound may take the following parameters:

filename

This file must exist and must point to a valid libunbound configuration file. The default is ${raddbdir}/mods-config/unbound/default.conf.

timeout

While libunbound provides an asyncronous API for internal use, using any xlat is done syncronously from the perspective of unlang. This value limits the amount of time a request will wait for DNS to respond, after which the xlat will fail. The default is 3000 milliseconds. This setting is independent of any libunbound configuration values.

resolvconf

Full path of a resolv.conf file to load resolver details from. If this is not set then libunbound will query root DNS servers.

hosts

Full path of a hosts file to load. This provides a mechanism for local overrides to names which would otherwise not resolve or need different results to those which a DNS resolution would provide.

An instance named, for example, "dns" will provide the following xlat functionalities:

%{dns-a:<owner>}

Performs an A lookup for the owner name, returning a stringified IPv4 address. Only the first A record in the RRSET will be returned.

%{dns-aaaa:<owner>}

Performs an AAAA lookup for the owner name, returning a stringified IPv6 address. Only the first AAAA record in the RRSET will be returned.

%{dns-ptr:<owner>}

Performs a PTR lookup for the owner.

## CAVEATS
Logging from rlm_unbound can be problematic, especialy if more than one instantiation of the module is used. This is due to the need for additional features in the underlying libunbound which hopefully will be enhanced over time.

There is a potential for a FreeRADIUS server using rlm_unbound to either fail to terminate cleanly (leaving zombie processes, failing to clean up other modules, and hanging after a SIGTERM until a SIGKILL is sent) or to fail valgrind checks during termination when run with -m. Likewise this problem will rely on upstream enhancements before it can be fixed, and the exact behavior may change in interim releases until then.

The logging behavior of rlm_unbound may vary depending on whether FreeRADIUS is compiled with support for threads.

## FILES
/etc/raddb/modules-available/rlm_unbound /etc/raddb/modules-config/unbound/

## SEE ALSO
radiusd(8), radiusd.conf(5) libunbound(3) unbound.conf(5)

## AUTHOR
Brian S. Julin, bjulin@clarku.edu


title: rlm_unix(5)

summary: FreeRADIUS Module

text:
# rlm_unix(5)

## NAME
rlm_unix - FreeRADIUS Module

## DESCRIPTION
The rlm_unix module reads crypt(3) passwords from the system password file, and allows the server to use them for authentication. The module also provides FreeRADIUS an interface into a radwtmp file (used by "radlast") when added to the accounting section.

The rlm_unix module should be listed in the "authenticate" section. Please see the default radiusd.conf shipped with the server for an example of the correct usage of this module.

As of FreeRADIUS 1.1.0, the module no longer reads, or caches /etc/passwd, /etc/shadow, or /etc/group. If you wish to cache those files, see rlm_passwd. Most, if not all, configurations should not need those files to be cached.

The main configuration items to be aware of are:

radwtmp

The path to the system wtmp file to be used for keeping the database of online users as read by the 'radlast' program.

## CONFIGURATION

```
modules {

  ...

  unix {

    radwtmp = ${logdir}/radwtmp

  }

  ...

}
```

## SECTIONS
authentication, accounting

## FILES
/etc/raddb/radiusd.conf,

## SEE ALSO
radiusd(8), radiusd.conf(5), rlm_passwd(5), radlast(1)

## AUTHORS
Chris Parker, cparker@segv.org