Showing posts with label RPM. Show all posts
Showing posts with label RPM. Show all posts

Monday, October 19, 2020

Radiator Software Ansible playbooks for easy Radiator setup and instance management

To help manage and install Radiator in a more automatic way, we now provide Radiator Software Ansible playbooks as part of the goodies available in every Radiator package. The playbooks make it easy to:

  • Install Radiator with basic prerequisites easily to multiple servers in single command.
  • Upgrade or downgrade Radiator to multiple servers in single command.
  • Deploy multiple Radiator configurations to multiple servers running Radiator, in single command/Deploy Radiator configuration to single server running multiple Radiator instances.
  • Rollback latest Radiator configuration deployment quickly to previous Radiator configuration.
  • Restart/start/stop all Radiator instances on multiple servers running Radiator in single command.

As general playbooks aimed for easy automation starting point, these playbooks are usable with Radiator RPM/deb packages after a few simple steps like setting up the Ansible control node and Radiator servers with SSH user for Ansible to use. After that just create your Radiator configuration and run the playbooks to setup the Radiator server and deploy the configuration. There are very simple authentication and accounting example configurations available in the Ansible role used by the deployment playbook, so testing the system is possible by just deploying the default example configurations. 

These playbooks are meant to be a starting point for various situations, but naturally they do not answer every need. So go ahead and modify the playbooks when needed! We do recommend storing both the modified playbooks (with the Ansible roles) and Radiator configurations deployed by these playbooks to a version control of your choice. Although for the rollback mechanism there is a simple backup system built-in, it is strictly for the rollback and is limited to the latest deployed Radiator configuration version only.

To get the Radiator Software Ansible playbooks, just download the latest Radiator package of your choice. When using the playbooks, Radiator is not required to be installed on the Ansible control node, but if it is you should copy the playbooks from the default location to some other location for usage. This way upgrading the possible Radiator installation on Ansible control node does not overwrite any changes you may have done to Ansible related files.

Check out the README document from the goodies/Ansible directory for how to run the playbooks!

Find more information about Ansible and Ansible playbooks on Ansible website.

 Requirements for using the Radiator Software Ansible playbooks

  • Ansible 2.7 is the minimum supported version on Ansible control node.
  • Supported Radiator host Linux distributions are Ubuntu 18.04 or newer, Debian 10 or newer, CentOS 7 or newer, and RHEL 7 or newer.
  • Radiator hosts must have sudo capable SSH user that Ansible can use.
  • Radiator hosts need internet access for apt/yum/dnf usage.
  • Radiator and/or Radius::UtilXS installation files (RPM/deb) are available on Ansible control node.

Radiator Dockerfiles now available

Radiator Dockerfiles are now available with all our Radiator packages! The Dockerfiles and the accompanying README provided makes it easy to build Docker containers where Radiator is run. Currently available are five different variations:

  • Radiator installed from Radiator public repository to CentOS 8 container
  • Radiator installed from Radiator public repository to Ubuntu 20.04 container
  • Radiator installed from RPM packages to CentOS 8 container
  • Radiator installed from deb packages to Ubuntu 20.04 container
  • Radiator installed from MSI to Windows Server Core 2019 container

Each Dockerfile has a command ready for copying your own Radiator configuration to the container image already on the build phase. Each Linux-based Dockerfile uses ENTRYPOINT for running the Radiator. In the Windows container, Radiator is run as a Windows Service. Of course, these Dockerfiles are meant just as starting points and there are several tips on what could be done differently in the accompanying README. Be sure to check it out!

Due to the nature of the Docker containers, systemd is not readily available on the Linux containers. This means that instead of running multiple Radiator instances in a single Docker container via systemd, you should be running several containers with each of them having different Radiator configuration.

Wednesday, March 25, 2020

Introducing new Radiator Repository

Recently, Radiator Software team has been putting their efforts into making life easier for system administrators. Following the introduction of the new Radiator Linux packages, we are now very proud to announce the new Radiator Repository. This is good news for the Linux users, since the new repository allows you to streamline maintenance and to easily distribute the updates to all Radiator servers in your organisation. What is even better, this new service is included with all active Radiator Support contracts. 

Supported platforms are RHEL 7/8, CentOS 7/8, Ubuntu 16.04/18.04/20.04/22.04, Debian 9/10/11. Here are the steps how to get it:

  1. Visit our repository page and log in using your existing Radiator user credentials: https://downloads.radiatorsoftware.com/repo/ 
  2. Scroll down to your Linux distribution version 
  3. Follow the instructions and use the commands in instructions to set up Radiator Repository
  4. Enjoy easy updates

For security, the repository URLs are customer specific and generated for your organization, and the packages provided from Radiator repositories are never marked as security upgrades. This means that using unattended-upgrades for system's security upgrades is safe as Radiator will not be automatically upgraded. You also get to pick whether you want the official releases only, or include the testing versions. 

For our customers using other platforms or with download access only contracts, Radiator Downloads site has been redesigned and is sporting a clean new look. You will continue to get the software updates the classic way by downloading the packages from our website, whether you are using Mac or Windows, older Linux distributions, or simply prefer to do so.  

Please contact our team at sales@radiatorsoftware.com if you want to check your subscription status, renew or upgrade your support contract, or reset your password. Let us know if you try the new repositories. We would like to hear your feedback!

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, 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.