The XLX Multiprotocol Reflector has a nice web-based dashboard that is also the linchpin of having your reflector registered in the XLX database.
It’s important to understand the interplay between the xlxd process, the dashboard, and the XLX directory hosted at api.rlx.lu. To setup an XLX reflector, one chooses an unused number from the reflector list. Then, while configuring XLX, that number is used both for the xlxd startup script and the dashboard configuration. The dashboard is actually what is responsible for registering your reflector number into the directory.
When the dashboard registers for the first time, a password of sorts called a hash is created on your system. Subsequent updates and pings to the directory to keep your entry active must use the hash stored on your system. This prevents someone from stomping on your number, accidentally or on purpose.
The default configuration in pgs/config.inc.php in the distribution of the dashboard stores the keys in /tmp. This is an easily-accessible place that will “just work” for everyone, but it is a very bad place to store files you care about. First, all data in /tmp is subject to be deleted at anytime – it’s “temp” for a reason. Second, systemd creates abstractions for /tmp and that includes Apache. When starting up the services, what Apache httpd thinks is /tmp is actually something like /tmp/systemd-private-811f16f4de3940cfa1f84a0ce80c7f95-apache2.service-0ETGBO/tmp. Also, this directory is not persistent across reboots.
To keep your files together and to avoid any accidental deletion of the data, store your data files for the dashboard in the /xlxd directory. Create a directory /xlxd/etc, own that subdirectory by the user of the webserver, and update your dashboard configuration appropriately. For a Debian example for the sub directory setup:
# mkdir /xlxd/etc # chown www-data:www-data /xlxd/etc # cp /tmp/systemd-private-811f16f4de3940cfa1f84a0ce80c7f95-apache2.service-0ETGBO/tmp/*.php /xlxd/etc
Then edit your dashboard configuration (most likely /var/www/html/pgs/config.inc.php) to configure the new hash location.
$CallingHome['HashFile'] = "/xlxd/etc/callinghome.php"; $CallingHome['LastCallHomefile'] = "/xlxd/etc/lastcallhome.php";
Then test that the configuration worked by calling the main index page with the parameter ?callhome=1 (e.g. http://xlx.megalink.network?callhome=1). This will force the dashboard to make the directory ping and will update the file /xlxd/etc/lastcallhome.php. The datecode will advance to the current time (it’s unix epoch time) if everything worked correctly.
Now, backup the file /xlxd/etc/callinghome.php – this is the file that contains your password hash key. I recommend putting this file in your cloud storage provide of choice (OneDrive, Google Drive, Box, Dropbox, etc.)
Consider adding a cron job on your system to ping the directory once per day to keep your number active, especially if your dashboard has low web use. You can do this simply by creating a /etc/cron.daily/xlxapi-update with the following contents:
#!/bin/bash /usr/bin/wget -q -O- http://localhost/index.php?callhome=1 > /dev/null
Make sure to mark the file executable after it’s created:
# chmod 755 /etc/cron.daily/xlxapi-update
