Tuesday, December 10, 2019

Radiator 4.24 is now available!

We are pleased to announce the release of Radiator version 4.24.

This version contains new features, enhancements, and bug fixes, including new Radiator packages now available for Red Hat Enterprise Linux 8, CentOS 8, and Debian 10 (Buster). 


Selected compatibility notes, enhancements and fixes
  • Added configuration parameters TLS_SecurityLevel and EAPTLS_SecurityLevel and calls to set accepted TLS version ranges. This allows for Radiator module level control of desired TLS settings without modifications of system defaults.
  • ClientListSQL configuration can now be simplified with ClientColumnDef parameters.
  • AuthBy SQLHOTP and SQLTOTP SQL query parameter support was added.
  • Dynamically updated Diameter RealmTable for request routing and forwarding is now available for advanced Diameter applications.
  • Added a new configuration flag parameter IgnoreIfMissing.
  • Added a new check item ExistsInRequest for matching requests by attribute presence. Useful for Handlers.
  • Added new AuthBy REST, which is built on a new class called HTTPClient.
  • Packages are now available for Red Hat Enterprise Linux 8 and CentOS 8 and Debian 10 (Buster).
  • Added configuration guide and samples for SecureW2 integration.
Known caveats and other notes
  • TLSv1.3 remains disabled by default for TLS based EAP methods and Stream based classes, such as RadSec.
  • EAP-FAST functionality is reported to vary between TLS versions, TLS library security level settings and client implementations.
As always, more detailed changes can be found in the revision history.

Monday, November 18, 2019

Fix to lost zsh prompt settings in MacOS Catalina

A major portion of our Radiator team are MacOS/Linux users and even on Windows usually run Linux/GNU/UNIX command line tools. In the recent MacOS Catalina Apple switched from bash shell to the zsh shell and there was much rejoicing.

However, to the annoyance of at least the writer, Apple changed their zsh configuration so that setting up terminal prompt in user's own .zshenv did not work anymore.

This is caused by Apple's default configuration in /etc/zshrc, which is read/run for interactive shells after user's .zshenv. In the Apple's default configuration the prompt is set up as follows:

# Default prompt
PS1="%n@%m %1~ %# "

To override this, just put PS1/PROMPT settings (and other settings you may want to override for interactive shells) into user's .zshrc and the problem is solved.

Tuesday, June 25, 2019

Grouping and controlling multiple Radiator instances with systemd

Introduction


Radiator Linux packages provide by default two systemd service files — /lib/systemd/system/radiator.service for single instance and /lib/systemd/system/radiator@.service for multiple instances configuration. The single instance configuration expects to find its configuration from /etc/radiator/radiator.conf while the multiple instances configuration expects each instance configuration to be named as /etc/radiator/radiator-<instance>.conf e.g. /etc/radiator/radiator-proxy.conf. When naming instances, it's better to use underscores instead of hyphens, so filenames would be like radiator-auth_internal.conf or radiator-wifiaccounting.conf.

When configuration files are in place, the instances can be enabled/disabled with following commands.

Single instance enable/disable:

systemctl enable radiator
systemctl disable radiator


Multiple instance enable/disable (instance name proxy, configuration file name radiator-proxy.conf):

systemctl enable radiator@proxy
systemctl disable radiator@proxy

All the commands above and in these instructions require root privileges, so open a root shell or use sudo to make sure that commands work.

Please note that enabling or disabling an instance does not start or stop the instance. It only controls if an enabled instance is started when starting the server. For starting and stopping instances manually there are systemctl start <instance> and systemctl stop <instance> commands e.g systemctl start radiator@proxy.

Sometimes there exists a need to run multiple Radiator hosts on a single host — for example when one has separated RADIUS proxy and authentication functionality into multiple separate instances. The reasons to do so vary from clarifying configuration to optimising performance by running multiple Radiator processes instead of a single one.

When multiple instances are used, managing and restarting them separately may become burdensome. Together with Radiator's systemd service files, systemd provides the means to group and control multiple Radiator instances with one virtual systemd service. These instructions follow the systemd configuration guidelines as described by Linux distribution manuals.

Preparations before starting


Please check and do at least the following before starting to migrate to virtual systemd service model:
  1. Ensure that your Radiator instance configurations work as manually controlled services. This means that you have working configurations for them and are able to enable, disable, start and stop them without any problems. If you run into trouble getting instance configurations running, check the configuration file owner, group and file permissions so that they are readable by radiator user or group.
  2. Stop and disable all Radiator instances.
These will ensure that you can more easily detect problems with the virtual systemd service configuration, when you know for sure that the instances and their configurations are already tested to be working. Stopping and disabling them ensures that you will start from clean slate when adding new virtual systemd service files.

When editing systemd service files, please do not edit and change files in /lib/systemd/system as the next Linux Radiator package upgrade will overwrite those files. The proper place to do these adjustments is under /etc/systemd/system as the following instructions will also describe.

Setting up virtual systemd service to control multiple instances


The actual implementation varies with the version of systemd, but for clarity, we have divided the instructions according to tested and compatible Linux distribution versions.

RHEL 8 / 9, Ubuntu 18.04 / 20.04 / 22.04 / 24.04 LTS, Debian 10 / 11 / 12


Configuration files


Create the virtual systemd service file /etc/systemd/system/radiator-instances.service with the following content:

[Unit]
Description=Virtual service for managing all Radiator instances

[Service]
# The dummy program will exit
Type=oneshot
# Execute a dummy program
ExecStart=/bin/true
# This service shall be considered active after start
RemainAfterExit=yes

[Install]
# Components of this application should be started at boot time
WantedBy=multi-user.target


Adjust existing radiator@.service file by creating a directory /etc/systemd/system/radiator@.service.d and creating adjustment file /etc/systemd/system/radiator@.service.d/custom.conf with the following content:

[Unit]
PartOf=radiator-instances.service

[Install]
WantedBy=radiator-instances.service

Controlling the instances


When you have finished creating the files and directory, you can enable the virtual service and instance(s) for example with the following command (assuming you have instances proxy and auth):

systemctl enable radiator-instances radiator@proxy radiator@auth

You can then control all instances either separately or by directing the virtual service radiator-instances with commands like:

systemctl start radiator-instances
systemctl stop radiator-instances
systemctl restart radiator-instances

The virtual radiator-instances now controls all radiator@.instance based instances on host. If you need more granular control, of which services are controlled radiator-instances, you need check Grouping instances to control section in the end.

Centos 7, Debian 9, RHEL 7, Ubuntu 16.04 LTS, Oracle Linux


Configuration files


Centos 7, Red Hat 7 and Ubuntu 16.04 LTS have an older version of systemd, which is not able to understand instance configuration adjustment directories like /etc/systemd/system/radiator@.service.d. Because of this, on these platforms, the radiator@.service itself needs to be copied to /etc/systemd/system directory to be adjusted. The disadvantage of this is that if new Radiator packages update the radiator@.service, the updates need to be edited manually to the /etc/systemd/system/radiator@.service file.


Create the virtual systemd service file /etc/systemd/system/radiator-instances.service with the following content:

[Unit]
Description=Virtual service for managing all Radiator instances

[Service]
# The dummy program will exit
Type=oneshot
# Execute a dummy program
ExecStart=/bin/true
# This service shall be considered active after start
RemainAfterExit=yes

[Install]
# Components of this application should be started at boot time
WantedBy=multi-user.target


Copy the /lib/systemd/system/radiator@.service file to /etc/systemd/system/radiator@.service and add the following lines to it.

To [Unit] section add line:

PartOf=radiator-instances.service

To [Install] section add line:

WantedBy=radiator-instances.service

Controlling the instances


When you have finished creating the files, you can control the instances like already presented in the RHEL 8 / 9, Ubuntu 18.04 / 20.04 / 22.04 / 24.04 LTS, Debian 10 / 11 / 12 — Controlling the instances section.

Grouping instances to control


The above instructions assume that you want to control all Radiator instances on a host with the radiator-instances service, but if you want to select the instances the control, the recommended way is to create renamed radiator-instances and radiator@.service under /etc/systemd/system. This approach is common for all mentioned Linux distributions and Radiator packages

For example if you wanted to group certain organisation's instances on host under a virtual service, you could create radiator-organisation-instances.service and copy /lib/systemd/system/radiator@.service as radiator-organisation@.service under /etc/systemd/system. In this case it does not matter if you use newer or older systemd as it is better to separate radiator-organisation@.service from radiator@.service. What you need to do is to adjust radiator-organisation@.service file so that it has PartOf and WantedBy lines pointing to the new renamed radiator-organisation-instances.service file.

After setting up those renamed files, you will be able to command the group of instances the same way as above with system wide instances group. The only difference is that for example in this case you would use the same commands with differently named services and instances, for example:

systemctl enable radiator-organisation-instances radiator-organisation@auth radiator-organisation@proxy

systemctl start radiator-organisation-instances

systemctl stop radiator-organisation-instances


For more information


In case you have any questions, comments or feedback, please contact support@radiatorsoftware.com.

Thursday, June 20, 2019

TNC19 Radiator technical workshop presentations available!

Terena Networking Conference 2019 (TNC19) is over as is our Radiator technical workshop, which was part of the conference. Here are all of Radiator Software presentations presented in the Radiator technical workshop. You are able to find these also on our SlideShare account, where we will upload also future public presentations about Radiator.

1) TNC19 Radiator Technical Workshop -- Introduction, what's new with Radiator (Software)

2) TNC19 Radiator Technical Workshop -- Using Radiator to ensure better SP/IdP connections to eduroam/govroam

3) TNC19 Radiator Technical Workshop -- Meet Radiator developers

Thank you to all Radiator technical workshop participants, we hope to see you again. We also will look into possibilities of repeating our technical workshop as a webinar together with TNC19 organisers for those who were not able to attend live.

Thursday, April 11, 2019

Radiator Version 4.23 released - security fixes, new features, enhancements and bug fixes

We are pleased to announce the release of Radiator version 4.23. This version contains security fixes for EAP-pwd authentication and certain TLS configurations. Other changes include new features, enhancements and bug fixes.

Selected compatibility notes, enhancements and fixes 
  • Improved AcctLogFILE to support JSON. 
  • Security fixes for EAP-pwd authentication and certain TLS configurations. OSC recommends all users to review OSC security advisory OSC-SEC-2019-01
Known caveats and other notes
  • TLSv1.3 is not enabled by default for TLS based EAP methods.
  • TLSv1.3 is not enabled by default for Stream based classes, such as RadSec.
As always, all changes and updates can be found from product history page.

Thursday, March 7, 2019

Connect your organization to govroam with Radiator

Recently, we have been implementing solutions for our customers that want to join govroam. With govroam, for example UK public-sector staff can roam in Wi-Fi networks in different locations - in a similar way that eduroam works in academic sector internationally.

As Radiator has strong background in eduroam and in other federated wifi networks, our solutions are a very good fit with govroam as well. We already have good experiences working, for example, with NHS organizations in the UK.

In couple of recent cases, Radiator provides the govroam compliant solution for user authentication and proxying. With Radiator, this has solved a a challenge for customers especially when using Windows AD / Windows NPS in their environment. While working with these cases, we have tailored couple of solutions that helps the organizations to be compliant with govroam specifications.

Also, Radiator can be run on Windows and Linux platforms, and in the cloud as well. In govroam cases, installations have been made to many different environments.

What Radiator Software offers

In our govroam use cases, we have developed two solutions for different types of organizations. The packs include both Radiator licenses as well as the support service for Radiator products:

  • Radiator Govroam Federation Support Pack
    • Solution for organisations that want to create a regional root service that is connected to govroam
  • Radiator Govroam Support Pack
    • Solution for individual organisations that will connect to regional root service connected to govroam. In this solution, Radiator is used as a RADIUS proxy providing the needed configuration in order to comply to govroam specifications.

For more info, please contact our sales team at sales@radiatorsoftware.com . We are happy to have a call about your govroam needs in order to provide a suitable solution for your own organization.

Tuesday, January 29, 2019

Migrating to new Radiator packages

New package formats

Radiator 4.22 is our first release that comes with Windows MSI package and Linux packages for Red Hat Enterprise Linux 7, CentOS 7, Ubuntu 18.04 and 16.04, and Debian 9. The old package formats, tar, zip and generic RPM, are also available. Our plan is to relabel the generic RPM package to legacy RPM and depreate it in favour of distribution specific RPMs.

See our earlier posts for more about new Linux and Windows packages. The topics below refer these posts for background information.

Before going to the topics below, here's what is common with each migration case. See the posts mentioned above for more details:
  • Your current Radiator configuration requires no large changes
  • Log directory is a prime example of packaging and startup related configuration file option that likely needs an update
  • New packages automatically configure Radiator to start at system boot. You may need to remove or disable what you currently use for starting Radiator

 Upgrading from old package format on Windows

Radiator MSI package comes with its own Strawberry Perl. As described in the aforementioned post, Radiator MSI package is designed to be self-contained. This also means that if you already have Radiator installed from a non-MSI package, you can switch to MSI without uninstalling your current Radiator.

We recommend making a copy of your current configuration before installation and checking that old Radiator installation is disabled or removed in Windows services after MSI installation. The blog post mentioned above has a wealth of information about MSI installation and post installation tasks.

Upgrading from generic RPM on Linux

Before starting an upgrade to new el7 RPM, review the Linux post from above to see what updates your current configuration requires. Most likely log directory needs to be updated, but also note the other changes, such as, new configuration file name, and system user and group radiator that are now used to run radiusd.

RPM packages for el7 replace generic RPM, which means you do not have to remove it before installing RPM for el7. We recommend making a backup of your configuration files, dictionaries and edited startup scripts and systemd service files. Although RPM package management tool renames edited files with rpmsave extension when upgrading from generic RPM, backups are recommended.

After the upgrade check that old startup scripts are disabled and Radiator is started with new systemd based unit file. It should run as radiator. See that logging and logrotate work as required.

Upgrading from tar or zip to RPM or deb

When Radiator is installed from RPM or deb package, old tar or zip based installation is not removed. Both RPM and deb packages prefer Radiator files from /opt/radiator directory, but you could consider locating old Radiator files installed from zip or tar package and removing them after the upgrade.

Because zip or tar based installation does not create any system user or group, log directories or require any other settings that come with new el7 RPM and deb packages, you need to review and updated your current Radiator configuration. See the Linux packaging blog post mentioned above for the details of paths, users and other information.

Also note that you need to manually disable old startup scripts. After the upgrade check that Radiator is started with new systemd based unit file. It should run as radiator. See that logging and logrotate work as required.

Thursday, January 24, 2019

Radiator SIM support 2.4 released

We are pleased to announce release 2.4 of Radiator SIM support. This release includes support for SCTP multihoming and has a number of smaller enhancements and bug fixes.

Revision 2.4 detailed updates and fixes
  • 3GPPAutHSS now supports Peer-Auth-Application-Id as DiaPeerDef selector. Requires Carrier module 1.5 or later and Radiator 4.20 or later.
  • Added configuration parameter HSSRealm to 3GPPAuthHSS. This value for this parameter is typically the realm where HSS resides. If not set, messages’ realm is set from DestinationRealm parameter of DiaPeerDef used to forwarding messages to the HSS. Defaults to not set.
  • Subscription-Id AVP is now added to SWm DEA messages to relay MSISDN to ePDG.
  • Updated EAP-SIM, EAP-AKA and EAP-AKA’ permanent, pseudonym (TMSI) and fast re-authentication identity leading characters to match RFC 4186, 4187 and 5448, and 3GPP TS 23.003 suggestions and requirements. Because of historical reasons, EAP-SIM fast re-authentication and EAP-AKA TMSI leading characters were swapped. EAP-AKA’ non-permanent identifiers are now fully separate from the respective EAP-AKA identifiers.
  • Removed obsolete configuration parameters TestNoMAP and GetReauthQueryEAP. Support for TestClient and TestVectorFile were removed from AuthAKA.pm and related files because they are obsolete. Use AuthAKATEST or ServerWXMAP based configurations for testing.
  • A number of code clean up and maintenance changes were done based on Perl::Critic and other tools.
  • SCTP multihoming is now supported. Requires Radiator 4.22 and Radiator Radius::UtilXS package.
Also, for more information, please do not hesitate to contact us at info@radiatorsoftware.com . See also Radiator SIM Pack product page.

Tuesday, January 15, 2019

Radiator Carrier Pack revision 1.5 released!


We are pleased to announce that Radiator Carrier revision 1.5 has been released. The many upgrades and enhancements in the new revision provide even better support for different carrier infrastructures than before.

Detailed changes and upgrades in revision 1.5
  • Added StreamServerUnix which allows to use UNIX domain sockets to connect to Radiator process. Integrator.pm in goodies shows an example how to create an integration interface which uses StreamServerUnix.
  • Updated ServerDIAMETERTelco and DiaPeerDef to fully support TLS_* configuration parameters.
  • DiaPeerDef now supports ReconnectTimeout parameter.
  • AuthBy DiaRelay now supports newly added DiaPeerDef selector Peer-Auth-Application-Id which allows selecting next hop Diameter peer based on the Auth-Application-Id advertised in the peer's CER or CEA. Requires Radiator 4.20 or later.
  • ReconnectTimeout and TLS support in DiaPeerDef requires Radiator 4.21 or later.
  • DiaPeerDef and ServerDiameterTelco now support SCTP multihoming when Radius::SCTP bindings for libsctp are available. Multiple local IP addresses are bound when BindAddress or LocalAddress are configured for ServerDIAMETERTelco or DiaPeerDef, respectively. DiaPeerDef now accepts one or more SCTPPeer configuration parameter for connecting to multiple destination IP addresses. Requires Radiator 4.22 and Radiator Radius::UtilXS package.
  • A number of code clean up and maintenance changes were done based on Perl::Critic and other tools.
  • Information about Diameter connection establishment, termination and DiaPeer selection is now logged on INFO level.

Now available as new Linux packages


Similar to Radiator 4.22, Radiator Carrier Pack is now available as packages suitable for Red Hat, CentOS and Ubuntu. These packages are based on the best practices we have used in our deployments and they comply with the current Linux distribution packaging practices. For more info regarding the new Radiator packages, please see our recent blog

These new packages are now available at:

As these are new packages, we are interested in any feedback you may have on the package design and installation. If you have any ideas, suggestions, feedback or questions of the new  packages, please do send them via this package feedback form or via email to support (a) radiatorsoftware.com.
Radiator Carrier Pack is now known as Radiator Service Provider Pack.

Friday, January 11, 2019

Radiator v4.22: Now with Windows installer package!

In our efforts to make Radiator easier to install, deploy and update in Windows environment, we have build a Windows installer package for Windows installations. The new package comes as an MSI that can be installed silently when needed. Supported Windows versions are Windows Server 2012 or newer, but older Windows Server versions can also be used provided they have at least PowerShell 3.0 installed.

These new packages are now first available at:
https://radiatorsoftware.com/products/radiator/downloads/

The MSI package includes Strawberry Perl for convenience, so that separate installation of Perl is no longer needed. However, if your environment already has a Perl installation, Strawberry Perl in Radiator MSI package does not disturb it. Since Radiator does require certain Perl modules that are available in the Windows package, it is mandatory to use the Radiator binaries from provided command line shortcuts. These shortcuts are located under Program Files\Radiator folder and for convenience shortcut to this folder and to reference manual are also available in the Start Menu under Radiator Software.

In addition of the Strawberry Perl command line shortcuts there are other important files available on the Program Files\Radiator folder. For example the basic configuration that is automatically installed and installation time log. This folder is never cleaned during upgrade or uninstallation, so this is the suggested location for all your own configurations.


 Differences between the new Windows package and installation from zip 

  • Radiator will install itself automatically under Radiator\Radiator in the drive with largest space available
  • Automatically provided dictionary and users are no longer copied to Program Files\Radiator, instead they should be used from original location. If the files are changed locally, then these should be stored under Program Files\Radiator so they are not removed
  • Installation and other logs are available under Program Files\Radiator
  • Basic configuration file is available under Program Files\Radiator
    • Basic configuration file name has changed to radiator.conf
  • Strawberry Perl is included in the Windows package
    • Only way to avoid this is to install manually from package as before
    • Strawberry Perl is not in path, so when running commands manually they must be done from Perl command line shortcuts available under Program Files\Radiator
  • Windows Service with basic configuration is created automatically
    • This helps testing that installation has been successful with radpwtst
  • Radiator Software is added to Start menu, with shortcut to Program Files\Radiator and link to reference manual
  • Binary files are not copied under Strawberry Perl, instead they are available in Radiator location

 

 

Installing, upgrading and uninstalling the Windows Package

 

Installing the new Windows package is simple. Once the MSI file is copied to the target machine, double click the file, approve license screens, and the installation is done. It is not possible to select where Radiator is installing, it will automatically install to the drive with most space available under Radiator\Radiator. Strawberry Perl is installed under Radiator\StrawberryPerl-Radiator and configuration and logs will go under Program Files\Radiator.

Upgrading works similar way, double clicking the MSI file on the target machine will launch the upgrade functionality. Upgrade will not remove anything from Program Files\Radiator, and also the Windows Service will be available as it was before the upgrade.

Uninstalling can be done either from double clicking the MSI file used to install the software or from Control Panel - Add/Remove Programs. When uninstalling via MSI file, the only option available is Remove. Repair or Change is not available. All Radiator Software specific items are cleared out during the uninstall, except the Program Files\Radiator folder. This is to ensure your configurations are not lost.

The MSI also supports silent operations, so it is possible to start the installation, upgrade, or uninstallation from command line without any UIs.

Note that the MSI package is not signed.



How to change the Windows Service configuration

 

When Radiator Software is installed with the help of MSI package, it has automatically created Windows service with basic configuration. This configuration is mainly aimed to help testing with radpwtst that the installation was successful. Changing the configuration to the Windows Service requires manual steps:

Create the configuration and store it under Program Files\Radiator


Open Windows Services



Stop the Radiator service and close the Services dialog


Open Perl command line Elevated from Program Files\Radiator by double clicking



Initialize the new configuration to Windows Service with command:
perl  "C:\Radiator\Radiator\radiusd" -installservice -config "C:\Program Files\Radiator\lsa_eap_peap.cfg" -prepend_env PATH:C:\Radiator\StrawberryPerl-Radiator\perl\site\bin;C:\Radiator\StrawberryPerl-Radiator\perl\bin;C:\Radiator\StrawberryPerl-Radiator\c\bin;


Open Windows Services and verify from the Radiator service properties that the new configuration is available. Start the service.


Opening ports in Windows firewall for Radiator

 

For connections to work from outside localhost, UDP ports 1645, 1646, 1812, and 1813 need to be opened from the Windows firewall.


Open the Windows Defender Firewall with Advanced Security



Create new Inbound Rule



Rule Type should be Port



Select UDP protocol and specify the needed ports: 1645, 1646, 1812, 1813



Allow the connection



Apply the rule to all profiles



Give suitable name for the rule and Finish the creation

New firewall rule is now active, and incoming Radiator connections are possible.


Give us feedback

As these are new packages, we are interested in any feedback you may have on the package design and installation. If you have any ideas, suggestions, feedback or questions of the new  packages, please do send them via this package feedback form or via email to support (a) radiatorsoftware.com.

Thursday, January 10, 2019

Radiator v4.22: New Linux packages for Radiator products

Background


In our efforts to make Radiator easier to install, deploy and update, we have concentrated our efforts first to ensure Radiator software packaging is up-to-date with current Linux distribution packaging practices. We have started by designing our new packages based on the best practices we have used in our deployments and enhanced those with recommendations for packaging suitable for Red Hat, CentOS, Ubuntu and Debian.

These new packages are now available at:

In the near future we intend to introduce Linux package repositories for our customer interested in automating their Radiator updates. We will also continue making legacy RPM packages for a small number of future Radiator releases to provide time for users to migrate to new packages. We will publish blog posts with more detailed migration information during January 2019.

What has changed in packaging?

  • New packages are named as radiator-4.22-1.el7.noarch.rpm and radiator_4.22-1_all.deb. Legacy RPMs are named as Radiator-4.22-1.noarch.rpm. Note the changes in RPM name.
  • Radiator AAA server software now installs completely separately to /opt/radiator/radiator directory to keep Radiator product files separate from system files and Perl libraries. For this reason radiusd and radpwtst and other utilities are no longer copied in /usr/bin and other directories. Startup configuration that comes with the new packages sets this directory as the primary source for Radiator module files.
  • A system user and group radiator is created for Radiator as there is no need to run Radiator as a privileged user. Also the default configuration file and log file permissions have been revised to more secure defaults.
  • Radiator's log directory is now /var/log/radiator/ with permissions set correctly for radiator system user and group. If this directory exists, its permissions are updated but existing old log files are not changed.
  • Radiator package is now fully compliant with systemd for running a single as well as multiple Radiator  instances. This however means that the oldest supported Red Hat / CentOS distribution version for new packages is Red Hat Enterprise Linux or CentOS 7. For Ubuntu we support 16.04 LTS (Xenial Xerus) as well as 18.04 LTS (Bionic Beaver). For Debian we support 9 (stretch).
  • systemd unit files set Radiator configuration file to /etc/radiator/radiator.conf
  • Radiator service is installed but is neither enabled nor started by default according to Red Hat packaging recommendations. This is also how deb packages are configured.
  • In addition to a new example configuration file, located at /etc/radiator/radiator.conf, the new package installs also a logrotate configuration file at /etc/logrotate.d/radiator. By default the configuration rotates and compresses Radiator logs every month and keeps 24 months worth of logs.
  • Root privileges are no longer needed for TACACS+. Radiator is started with privileges that allow binding to reserved ports.
  • New packages are signed. More information will be available in Radiator documentation.
See Radiator documentation for the latest installation instructions and other information. See the separate blog post about migration information.

What packages do not do?

Package configuration tries to keep system changes at minimum. For example, firewall rules are not updated. 

Some Linux distributions such as Red Hat Enterprise Linux 7 and Centos 7, have a firewall setup enabled by default. To make Radiator accessible from the network on Red Hat or Centos, use firewall configuration command (sudo firewall-cmd --permanent --zone=public --add-service=radius; sudo firewall-cmd --reload) to setup and enable rules for RADIUS.

Give us feedback

As these are new packages, we are interested in any feedback you may have on the package design and installation. If you have any ideas, suggestions, feedback or questions of the new packages, please do send them via this package feedback form or via email to support (a) radiatorsoftware.com.


UPDATE 2019-01-29: Mention Debian 9. Firewall configuration example was added. Link to migration information post was added.

Wednesday, January 9, 2019

Radiator version 4.22 released!

We are pleased to announce the release of Radiator version 4.22!

This version comes with additional Radiator package formats and contains new features, enhancements and bug fixes.

Radiator is now packaged as RPM for Red Hat Enterprise Linux 7 and CentOS 7, deb for Ubuntu 16.04 and 18.04, and MSI for Windows. These are  in addition to the previous package formats: generic RPM, zip and tgz.  Other software, such as Radiator SIM pack, will be packaged later. More information about new packages will be posted separately.

Revision 4.22 (2019-01-09) major packaging update, new features,  enhancements and bug fixes

Selected compatibility notes, enhancements and fixes:

  • New Radiator packages: Red Hat Enterprise Linux 7 and Centos 7, Ubuntu 16.04 and 18.04, and Windows MSI
  • Major updates to Yubikey Validation server support
  • SCTP multihoming support for Diameter and other stream modules

Known caveats and other notes

  • TLSv1.3 is not enabled by default for TLS based EAP methods.
  • TLSv1.3 is not enabled by default for Stream based classes, such as RadSec.
More info and detailed changes can be found from our Radiator revision history.