Running RadiantOne FID as a Linux systemd Service with Non-Root Service Account

When configuring RadiantOne FID (Federated Identity) and Control Panel to run as systemd services using a non-root service account instead of the default root user, there are specific ownership and permission requirements that must be met to avoid startup failures and access denied errors.

Overview

When using a service account for running the systemd Control Panel and VDS services instead of root, the following issues may occur:

• Files and change log entries are created with root ownership instead of the intended service account ownership
• AccessDeniedException errors appear when the server attempts to write to the change log directory
• The VDS server takes an extended time to initialize during startup
• File ownership issues in directories like cn_changelog where Lucene index files are created under root ownership

Environment

• Product Version: 7.4.x
• OS Platform: RHEL 8

Root Cause

File ownership mismatches occur when:

• Services were previously started as root even once, causing files to be created with root ownership
• The systemd service unit files specify a service account, but certain directories or files were not properly transferred to that account
• Subdirectories (such as /jdk/bin) were missed during ownership transfer
• The main application continues creating or modifying files as root, leading to inconsistent permissions in changelogs or logs

Solution

Prerequisites and Configuration Steps

1. File Ownership Requirements

Ensure the entire RadiantOne install directory is owned by the service account:

chown -R service_account:service_group /opt/radiantone

Verify ownership of all subdirectories including:

• /opt/radiantone/vds/bin
• /opt/radiantone/vds/logs
• /opt/radiantone/vds/vds_server/conf
• /opt/radiantone/vds/vds_server/data
• /opt/radiantone/vds/vds_server/data/cn_changelog
• /opt/radiantone/vds/jdk/bin (Java subdirectory)

2. File Permission Requirements

The service account must have read, write, and execute permissions on:

• bin/ directory and all executables
• logs/ directory
• config/ directory
• data/ directory including all subdirectories

Set appropriate permissions:

chmod 750 /opt/radiantone/vds/bin/*

3. SystemD Service Unit File Configuration

Configure the service unit files to explicitly specify the service account.

control_panel.service example:

[Unit]
Description=Radiant One Control Panel
After=network-online.target
Wants=network-online.target

[Service]
User=service_account
Type=forking
Environment=RLI_HOME=/opt/radiantone/vds
Environment=RLI_APPSERVER_HOME=/opt/radiantone/vds/appserver/glassfish
ExecStart=/opt/radiantone/vds/bin/launchControlPanel.sh
ExecStop=/opt/radiantone/vds/bin/stopWebAppServer.sh
KillMode=none
TimeoutStopSec=30s

[Install]
WantedBy=multi-user.target

vds.service example:

[Unit]
Description=Radiant One VDS Server
After=network-online.target
Wants=network-online.target

[Service]
User=service_account
Type=forking
Environment=RLI_HOME=/opt/radiantone/vds
ExecStart=/opt/radiantone/vds/bin/runVDSServer.sh
ExecStop=/opt/radiantone/vds/bin/stopVDSServer.sh
KillMode=none
TimeoutStopSec=30s
Restart=on-failure

[Install]
WantedBy=multi-user.target

4. System Resource Limits

Ensure nofile (file descriptors) and nproc (processes) limits are raised for the service account in /etc/security/limits.conf:

service_account soft nofile 65536
service_account hard nofile 65536
service_account soft nproc 4096
service_account hard nproc 4096

5. SELinux Considerations

If SELinux is enforcing, the service account may need additional policy rules to allow Java to:

• Bind to network ports
• Write to log directories
• Access required system resources

Important Notes

• Only root can execute systemctl commands. The User= directive in the service file causes systemd to switch the process owner to the service account after root initiates the command
• Never manually start services as root if they are configured to run as a service account, as this will create files with incorrect ownership
• After any reboot, verify that file ownership persists with the service account and has not reverted to root
• When RadiantOne Identity Data Management is set up as an OS-managed service, it cannot be started or stopped via the Control Panel to prevent manual intervention

Verification Steps

After configuration, verify:

1. Check process ownership:

ps -ef | grep VDSServer

2. Verify file ownership in critical directories:

ls -l /opt/radiantone/vds/vds_server/data/cn_changelog

3. Check service status:

systemctl status vds.service
systemctl status control_panel.service

4. Review logs for any AccessDeniedException errors:

tail -f /opt/radiantone/vds/vds_server/logs/vds_server.log

Related Documentation

For additional information, refer to:

• Deployment and Tuning Guide: Starting and Stopping Components and Services
  https://developer.radiantlogic.com/idm/v7.4/deployment-and-tuning-guide/06-starting-and-stopping-components-and-services/
• How to start FID on port 389 (or any port under 1024) on Linux with a Non-Root Account https://support.radiantlogic.com/hc/en-us/articles/4412529597972-How-to-start-FID-on-port-389-or-any-port-under-1024-for-LINUX-platforms-with-a-non-admin-root-account
• Starting RadiantOne FID as a Linux systemd Service (Non-Root Service Account) KB article https://support.radiantlogic.com/hc/en-us/articles/42022729635988-Starting-RadiantOne-FID-as-a-Linux-System-d-services-Non-Root-Service-Account