Like Luminis But Spelled Right
This code was a labor of love and a really fun six months spent replacing a system that cost hundreds of thousands of dollars per year. I regularly tell folks that I replaced Luminis with a small Python script. That does somewhat diminish the work that went into coming up with this. It also diminishes the fact that Luminis was a full-featured portal system long before such things were as streamlined as they are today - and Radiant ONLY serves to replace the message queuing and user authentication portions of the system. The "other 95% of the code" that was spent on web-based email, calendar, announcements, etc, etc is not represented here.
This project is in no way endorsed or supported by any corporate entity.
Get yourself a Radiant virtual environment
python3 -m venv .venv
Install requirements, and wheel
pip install -r requirements.txt
pip install wheel build
** Once your dev environment is set up and working, you really should go down to Upgrading Requirements and upgrade the requirements.txt file. **
** Ensure the version number has changed in the VERSION file **
Build the new package
python -m build
This will create ./dist/radiant-VERSION-py3-none-any.whl which you will
deploy when installing or upgrading.
When you deploy a change, it is good to upgrade the Python requirements. Of course this is risky because there could be a breaking change, but honestly, Python is pretty good about this.
Upgrade all requirements
pip install --upgrade $(cat requirements.txt | cut -d = -f 1)
Write a new requirements file
pip freeze > requirements.txt
See what changed
git diff requirements.txt
Go back and build a new package.
Radiant is heavily dependent upon systemd for process management. Set up a
new Linux system with any recent python3. Ensure that the venv module is
installed globally with pip3 install venv
Create the Radiant structure:
mkdir -p /opt/radiant/etc
Leave it owned by root.
Create a radiant user and group:
useradd radiant
Create a Radiant logging space owned by radiant:
mkdir /var/log/radiant
chown radiant:radiant /var/log/radiant
Create a virtual environment for Radiant:
python3 -m venv /opt/radiant/venv
See Upgrading Radiant below for the rest of the steps which are the same when installing or upgrading.
Note that for a from-scratch install you will need to install and configure
systemd units from system/systemd/ in this repo. See
Enabling and Starting Radiant.
See Building Radiant for how to generate the package file.
Copy the package file up to the server.
Ensure you have a copy of which Radiant services are running. (If this is a fresh install, you can skip this step.)
systemctl status 'radiant*'
Take note of all running services, which really ought to be documented somewhere anyway.
Stop all radiant services. (If this is a fresh install, you can skil this step)
systemctl stop 'radiant*'
Enter the Python virtual environment on the server.
[root@radiant-dev ~]# . /opt/radiant/venv/bin/activate
(venv) [root@radiant-dev ~]#
Install or upgrade the package file.
pip install radiant-VERSION-py3-none-any.whl
If Radiant is already configured (this is not a fresh install) then skip down to Enabling and Starting Radiant. If this is a fresh install though, go through the next few steps.
Radiant Gateway connects to Banner's Oracle DB and monitors for LDI events.
It also can be run standalone to generate or re-generate events. Consult
radiant-gateway --help for more info after it is installed.
Deploy the following files from ./etc to /opt/radiant/etc, renaming
without the dist extension:
gateway.confldigenerator.conf
Do not modify ldigenerator.conf.
Modify gateway.conf to set Oracle and RabbitMQ (AMQP) connection info. Do not
modify anything else.
Deploy ./system/systemd/radiant-gateway.service to /etc/systemd/system.
It should not need to be modified.
See Enabling and Starting Radiant to start the gateway service.
The gateway service can run independently of HTTP or Shell adapters, but it's the adapters that create the queues, so on a first-time startup you should get all the configuration done first.
Radiant HTTP Adapter pushes messages to HTTP endpoints. It performs an HTTP POST with the following custom headers:
RDI-TimestampThe timestamp of the messageRDI-Message-Id: The unique Message IDRDI-Message-Seqno: The Banner LDI Sequence Number (useful for tracing/debugging)RDI-Version:3.0
The body of the message is Luminis Data Interconnect (LDI) XML data.
Deploy httpadapter.conf and configure RabbitMQ (AMQP) connection details. do
not modify anything else.
FOR EACH HTTP LISTENER, choose a name. In this example it's named RECIP.
Deploy http_recipient.conf.dist to /opt/radiant/etc/http_RECIP.conf and
configure for the service.
See Enabling and Starting Radiant to start the Recipient-specific HTTP adapter service.
Radiant Shell Adapter is very much like Radiant HTTP Adapter, although a little more limited. Instead of sending XML messages to something, it will run a shell script with a limited subset of available LDI information. If it's too limiting, you may want to use it as a template to build a new adapter, or modify to add more possiblities.
Deploy shelladapter.conf and configure RabbitMQ (AMQP) connection detauls. Do
not modify anything else.
FOR EACH SHELL LISTENER, choose a name. In this example it's named RECIP.
Deploy shell_recipient.conf.dist to /opt/radiant/etc/shell_RECIP.conf and
configure for the service.
See Enabling and Starting Radiant to start the Recipient-specific Shell adapter service.
Each Adapter Instance creates its own Queue in RabbitMQ. These Queues are of
the "fanout" type from one radiant Exchange. The queues are created when the
service first starts. As such, the first time you start Radiant, you should
start the adapters first, look at Rabbit to make sure you like it, and then
start the Gateway.
After the first startup, order does not matter. If you start Gateway first, then any messages will queue. Or, if you start the listener first, it'll just be bored.
Take note that if you introduce a new Adapter, when you first start the service, that is when its queue will start accepting messages. There is no way to say, "start accepting messages after this one." If tight synchronization is required, then you might ened to stop gateway, start the queue, make sure message IDs are synced, and then start gateway back up.
Anyway, I digress. Here's how you start Radiant.
Enable and Start All Adapters (HTTP and Shell)
systemctl enable radiant-httpadapter@RECIP.service
systemctl enable radiant-httpadapter@RECIP2.service
systemctl enable radiant-shelladapter@RECIP.service
systemctl enable radiant-shelladapter@RECIP2.service
systemctl start radiant-httpadapter@RECIP.service
systemctl start radiant-httpadapter@RECIP2.service
systemctl start radiant-shelladapter@RECIP.service
systemctl start radiant-shelladapter@RECIP2.service
Enable and start Radiant Gateway
systemctl enable radiant-gateway.service
systemctl start radiant-gateway.service
Now, tail things in /var/log/radiant and make sure things are working.
Check RabbitMQ to ensure messages are flowing.
Reboot the Radiant host to make sure things go down and come back up uneventfully.
system/gam-createorupdate - can be used with radiant-shelladapter
to create or update Google Workspace users using
GAM
system/nrpe.cfg - NRPE monitoring configuration that includes monitoring
for the Luminis event queue in Oracle DB.