Read this and especially this reply

tl;dr

It seems to be the SELinux that restricts the read/write permissions. I set SELinux to the permissive mode for testing and the 'Cache path is not writable' error is gone.

Hi,

Thanks for replying so quickly. I have triple-checked and can tell you for certain that `apache:apache` owns all of /var/www/html and all children, including /var/www/html/elgg-config. It also has the correct SELinux context (`httpd_sys_rw_content_t`), but like I said in the original post, I'm pretty sure something else is at fault because even when setting SELinux to permissive mode, the same error still occurs in the same way.

# ls -laZ /var/www/html/                                                               
total 280                                                                                                             
drwxrwxr-x.  5 apache apache system_u:object_r:httpd_sys_rw_content_t:s0        237 Mar 31 13:03 .                    
drwxr-xr-x.  4 apache apache system_u:object_r:httpd_sys_content_t:s0            33 Nov  3 19:23 ..                   
-rw-r--r--.  1 apache apache unconfined_u:object_r:httpd_sys_rw_content_t:s0    744 Mar 31 13:03 composer.json
-rw-r--r--.  1 apache apache unconfined_u:object_r:httpd_sys_rw_content_t:s0 235515 Mar 31 13:03 composer.lock
drwxr-xr-x.  2 apache apache unconfined_u:object_r:httpd_sys_rw_content_t:s0     65 Mar 31 15:46 elgg-config
-rw-r--r--.  1 apache apache unconfined_u:object_r:httpd_sys_rw_content_t:s0    100 Mar 31 13:03 .gitignore
-rw-r--r--.  1 apache apache unconfined_u:object_r:httpd_sys_rw_content_t:s0   4443 Mar 31 13:03 .htaccess
-rw-r--r--.  1 apache apache unconfined_u:object_r:httpd_sys_rw_content_t:s0    244 Mar 31 13:03 index.php
-rw-r--r--.  1 apache apache unconfined_u:object_r:httpd_sys_rw_content_t:s0    281 Mar 31 13:03 install.php
drwxr-xr-x.  3 apache apache unconfined_u:object_r:httpd_sys_rw_content_t:s0   4096 Mar 31 13:13 mod
-rw-r--r--.  1 apache apache unconfined_u:object_r:httpd_sys_rw_content_t:s0    312 Mar 31 13:03 phpunit.xml
-rw-r--r--.  1 apache apache unconfined_u:object_r:httpd_sys_rw_content_t:s0    360 Mar 31 13:03 README.md
-rw-r--r--.  1 apache apache unconfined_u:object_r:httpd_sys_rw_content_t:s0    388 Mar 31 13:03 .travis.yml
-rw-r--r--.  1 apache apache unconfined_u:object_r:httpd_sys_rw_content_t:s0    246 Mar 31 13:03 upgrade.php
drwxr-xr-x. 39 apache apache unconfined_u:object_r:httpd_sys_rw_content_t:s0   4096 Mar 31 13:03 vendor

# ls -laZ /opt/<my-application>/data/                                                   
total 0                                                                                                               
drwxr-xr-x. 3 apache apache unconfined_u:object_r:httpd_sys_rw_content_t:s0 40 Mar 19 12:39 .                         
drwxr-xr-x. 3 apache apache unconfined_u:object_r:httpd_sys_rw_content_t:s0 18 Mar 17 03:03 ..
drwxr-x---. 4 apache apache unconfined_u:object_r:httpd_sys_rw_content_t:s0 37 Mar 19 12:39 caches
-rwxr-xr-x. 1 apache apache unconfined_u:object_r:httpd_sys_rw_content_t:s0  0 Mar 17 04:36 settings.php

I have not seen any errors or diagnostics about the cache path being unwritable or otherwise not working correctly, it's only been "The site secret is not set.".

# ./vendor/elgg/elgg/elgg-cli                                                          
 WARNING: Deprecated in 3.3: 'simplecache_lastupdate' config option is deprecated. Use 'lastcache'                    
An error occured during the execution of the command './vendor/elgg/elgg/elgg-cli': The site secret is not set.

Is there a log file or some sort of verbose switch I can toggle that I can look through to see if the cache path is part of my issue?

Only this...

I can’t help you anymore because I don’t use CentOS (in fact, I don’t understand why people choose it).
I believe this is a common bug for all CentOS users.

If you don't find help here then refer to specialized sites with advanced CentOS users.

Robert,

When I installed Elgg 3.3.16 on the same system as yours, I did not have the site secret issue. But I encountered it later when trying to migrate Elgg 2.x data to Elgg3.x database.

I did not use 'vendor/elgg/elgg/elgg-cli' like you did when installing Elgg. I do not know if that is the cause of this issue or not. What I did was running 'vendor/bin/elgg-cli install' inside the project directory.

With that being said, below is how I debug this site secret issue. 

1. If you have an access to your MariaDB server, you can get the site secret from the config table - select value from {prefix}config where name like '%site_secret%';. 

2. If the query above returns a value, then copy it (only string inside the double quotes) and paste it to the elgg-config/settings.php - $CONFIG->__site_secret__ = 'paste your site secret here';

@Nikolai:

That thread is still revolving around permissions issues with the elgg directories. I've already checked all of that several times over.

I use CentOS because I'm familiar with the Red Hat ecosystem and use it for all of my projects. I've not had any major issues configuring a CentOS server to run anything to this extent before.

If this actually is a really common scenario, that apparently there's something about the CentOS environment that is consistently causing issues for people, would it be worth it at this point to file a bug on the Github issue tracker? I was originally thinking that my issues were rooted in dumb newbie mistakes that could be easily rectified, so I avoided posting my issue there. Now that I'm seeing that issues with CentOS are not particularly rare, I'm becoming more inclined to file an issue.

@seri_ng:

Thanks much for the hint about the config value in the settings file. I tried setting my own temporary dummy site secret in the hopes I could at least get Elgg to 'boot' properly and let me reset it automatically, but alas there is now a different error about an SQL query failure, which implies there's more deep-seated breakage in the database than I have much of a chance at fixing by hand being completely new to Elgg.

I took some time to move on to other things in my project and came back to this problem last week. With a little bit of assistance from someone who is more familiar than I am with administrating CentOS, I found what needs to be done in order to make SELinux happy.

In short:

• Enable the `httpd_sys_rw_content_t` context for your project root, data directory, and all children of those directories (after having chowned the directories to 'apache:apache')
• Enable the `httpd_can_network_connect` and `httpd_can_network_connect_db` booleans.

I set up the database using the mysql_setpermission tool, which has created consistent working results for me. I do option 2 ("Create a database + user privilege for that database and host combination (user can only do SELECT)") and then option 6 ("Create/append full privileges for an existing database and host combination (user has FULL privilege)"), using the same parameters as in option 2. It appears that you can't skip straight to option 6; it won't create the database for you.

Below is a shell script that I worked on that will set Elgg up enough that you can browse to the setup page:

#!/bin/bash

# Bail if any command fails
set -e

### Package updates
dnf upgrade -y

### Install needed packages
dnf install -y httpd mariadb mariadb-server php php-gd php-pdo php-json php-mbstring php-xml php-mysqlnd

### Add appropriate config file for rewrite rules
cat >/etc/httpd/conf.d/rewrite.conf <<"EOF"
<Directory "/var/www/html">
       AllowOverride All
       RewriteEngine On
</Directory>
EOF

### Install php composer tool (straight from https://getcomposer.org/download )
# You may need to edit this if the 'Installer corrupt' message appears; likely
# culprit is probably just that the setup program has been updated
php -r "copy('https://getcomposer.org/installer', 'composer-setup.php');"
php -r "if (hash_file('sha384', 'composer-setup.php') === '756890a4488ce9024fc62c56153228907f1545c228516cbf63f885e036d37e9a59d27d63f46af1d4d07ee0f76181c7d3') { echo 'Installer verified'; } else { echo 'Installer corrupt'; unlink('composer-setup.php'); } echo PHP_EOL;"
php composer-setup.php --install-dir=/usr/local/bin --filename=composer
php -r "unlink('composer-setup.php');"

### Install Elgg components
composer create-project elgg/starter-project:dev-master /var/www/html
cd /var/www/html
composer install
# yes, twice... specified on Elgg installation material - https://learn.elgg.org/en/latest/intro/install.html
composer install
cd -

### Create data directory
mkdir -p /YOUR/DATA/DIRECTORY
chown -R apache:apache /YOUR/DATA/DIRECTORY

# semanage will error if the context has been applied already so just... ignore it
set +e
# Give /YOUR/DATA/DIRECTORY/ and all child files the 'httpd_sys_rw_content_t' permission context
semanage fcontext -a -t httpd_sys_rw_content_t "/YOUR/DATA/DIRECTORY(/.*)?"
set -e

restorecon -R /YOUR/DATA/DIRECTORY/

### Fixup /var/www/html
chown -R apache:apache /var/www/html

# semanage will error if the context has been applied already so just... ignore it
set +e
# Give /var/www/html/ and all child files the 'httpd_sys_rw_content_t' permission context
semanage fcontext -a -t httpd_sys_rw_content_t "/var/www/html(/.*)?"
set -e

restorecon -R /var/www/html

### Other SELinux permissions needed by Apache
setsebool -P httpd_can_network_connect 1
setsebool -P httpd_can_network_connect_db 1

### Setup MariaDB
systemctl enable mariadb && systemctl start mariadb
mysql_secure_installation
mysql_setpermission

### Enable firewall
# Note: change service to 'https' for production!
firewall-cmd --add-service=http --permanent && firewall-cmd --reload

### Start services
systemctl enable httpd && systemctl start httpd

echo "Things are set up! (Hopefully...)"

I hope that this will prove useful to the folks that were struggling to get things running. I'm going to try getting this information included in the documentation so that it's not so painful for others to get this information in the future.

~Robert C

Thanks for sharing!

Robert, you should definitely report this as a bug in Elgg (failures are not being logged) but can you please see if you can find a docker image that most matches your system (ideally with Apache/PHP)? We can then have a shot at reproducing this locally.

I'm going to try getting this information included in the documentation so that it's not so painful for others to get this information in the future.

A patch has been landed into the 3.3 branch (which, as I understand, will propagate elsewhere) which updates the documentation to mention the SELinux contexts and booleans, so hopefully more people will see the note in the documentation and get it right the first time. :)

@Steve Clay - I'm not familiar with Docker, so I'm not really sure what exactly you're asking me to produce for you. The system in question is a vanilla CentOS 8 amd64 virtual machine that was installed straight from the DVD image with SELinux left in 'enforcing' mode, so chances are good you might be able to find such a thing on your own?