New install of CMS 1.8.1 unable to save settings

Get Help
1

I’ve just setup a new install of CMS on a Centos 7 system. I (believe) I have this new instance setup correctly. This is a native install (not Docker). I previously have CMS 1.7.4 setup under Centos 6 and its running flawlessly. For this setup we decided to setup a new server since we wanted to migrate away from Centos 6.

When we go to Administration -> Settings. If we make no changes but do press the Save button. It throws an error “Unexpected error, please contact support”

If we look at the Xibo logs we see this error:
“RecursiveDirectoryIterator::__construct(/opt/xibo-library/cache/0fea6a13c52b4d47/25368f24b045ca84/b8ac4316b44f99ee/f0cf6447439815bc/2245023265ae4cf8/7d02c8b6ba991139/5f9a94e12fe51ea6): failed to open dir: Permission denied Exception Type: UnexpectedValueException”

There are no errors at all in the apache error_log.

I do have a directory setup in /opt/xibo-library. The directory is owned by apache and I’ve even set the permissions to 777 with no joy.

selinux is enabled on this box but its mode is currently set to permissive. Just for assurance I’ve run this command on the xibo-library “chcon -R -t httpd_sys_rw_content_t /opt/xibo-library/”.

I’m about out of ideas on this one. As far as I can tell all other functions and settings can be changed except for the ones under the Administration -> Settings

2

For those that may find this tread some time in the future.

I found the issue. For some reason the .php file in the path above was owned by root and not apache. I didn’t create the file as root, some process did. I reset the permissions on the entire library directory and then I was able to save the settings via the web gui.

3

Whelp, not so fast. That solved that instant of the issue. I went to make a few more changes after some time and the error is back. Looking at the new error message it appears that there is a process running as root that is creating or managing the cache directory. Because now there are new files owned by root [56052205b811effc.php] that are blocking the save function. I can reset the permissions to allow me to save the settings. But this isn’t a sustainable solution.

4

Have you configured the Xibo Task Runner (XTR) or older Maintenance routine? If that is running as root, any cache that it creates during its runtime will be owned by root.

5

Thank you for your response.

I did find that out yesterday, if I removed the xtr call from cron the saved function worked as it should. I was going to wait over night to confirm that was the root cause. It appears that function is the case.

So if it is the XRT code causing this issue, what did I do wrong? I thought I followed the instructions for installation correctly by adding the maintenance call command to cron (which I understand will run as root).

thank you for your time on this.

6

The documentation could be improved, I think.

If you’ve run crontab -e as the root user, then anything in there is run as root. If you were to run that logged in as www-data then it would be www-data that ran that command.

If you’ve edited /etc/crontab, then you can prepend the username to the command, like:

* * * * * www-data /usr/bin/php /var/www/xibo/bin/xtr.php

I’ll improve the docs:

7

Excellent I will test that out and confirm. Just for what its worth for RHEL/Centos the httpd process is run as apache. But I will test as the apache use and report back.

thank you

8

I can confirm that updating the crontab for Centos 7 with
* * * * * apache /usr/bin/php /opt/xibo-cms/bin/xtr.php

Corrected the issue with the Save settings function.

If I could ask a slightly unrelated question (If I need to open a new thread I will): The the xmr service, what user should that run as? I did find an upstart script in the cms path. From that I gleaned it should run as nobody but wasn’t sure if that was correct.

Edit: The above solution is wrong. It did not solve the issue. While it allowed saving in the gui, It wasn’t actually running. Its not possible to run as apache since you can’t login or su to apache. The full solution is below I just wanted to note that this solution didn’t work.

9

Great, I am pleased that is working.

The XMR process can run as nobody - it is entirely disconnected from the CMS in terms of access to any files, and only communicates over a socket. It is best to run it with as little privilege as possible, provided it can read its own files and open the ports specified in its configuration.

10

Well my solution was no solution. An important point to remember, just because its not throwing an error doesn’t mean its really working. But in my case root was getting an email failure message on each execution.

Here is what I know so far. crontab -e and anything you place in there is meant for personal cron jobs. You can’t su to apache in root’s personal crontab. You can how ever run crontab -u apache -e and place the xtr code in there. I did not end up doing it that way because its a bit hidden from the other admins (and my self in a few days).

I elected to just use /etc/crontab to place the command because everyone knows to look there for cron jobs :wink:
* * * * * apache /usr/bin/php /opt/xibo-cms/bin/xtr.php

So far this change has been in place for about 1 hr and there are no error messages or emails from cron saying that the command is failing. I guess I will see if the xtr program is actually doing its daily maintenance at some time in the future. But so far I can save configurations in the web gui. I hope this is now case closed on this issue.

In regards to the systemd startup code. (I know mixing threads here)
I created the file /etc/systemd/system/xmr.service with the following content:

[Unit]
Description=xmr
After=network.target

[Service]
Type=simple
ExecStart=/usr/bin/php /opt/xibo-cms/vendor/bin/xmr.phar
Restart=always
User=nobody
Group=nobody

[Install]
WantedBy=multi-user.target

Then I ran the following commands
systemctl daemon-reload
systemctl enable xmr.service
systemctl start xmr.service

2 Likes