Installation fails with "The site secret is not set."

Following , installation abruptly stops with "The site secret is not set". Doesn't matter if I do it through the web installer (by visiting mypage.example/install.php ) or by using `vendor/elgg/elgg/elgg-cli` (which is up and refusing to work at all without the site secret at this point) to do the installation.

I've tried several clean starts, and it always gets stuck right at the very end. Apache owns /var/www/html and all contained files, as well as the data directory, which is located in /opt/ (following the advice that "this folder MUST be stored outside of your document root" in the guide). This is a CentOS machine, so SELinux is enabled and enforcing. The appropriate contexts have been applied in both directories, but even so, the error still occurs even if you temporarily disable SELinux (`setsenforce 0`).

I'm at a loss at what to do next. The guide's complete lack of mentioning the site secret implies that something has gone astray and that I'm not meant to manually fix this, but trying to search the web for this issue hasn't been fruitful for me.


Some of the relevant version numbers:

# cat /etc/redhat-release                                                                                                                                                                                      
CentOS Linux release 8.3.2011

# php -v                                                                                                                                                                                                       
PHP 7.2.24 (cli) (built: Oct 22 2019 08:28:36) ( NTS )                                                                                                                                                                                        
Copyright (c) 1997-2018 The PHP Group
Zend Engine v3.2.0, Copyright (c) 1998-2018 Zend Technologies

# httpd -v                                                                                                                                                                                                     
Server version: Apache/2.4.37 (centos)                                                                                                                                                                                                        
Server built:   Nov  4 2020 03:20:37

# mysql --version                                                                                                                                                                                              
mysql  Ver 15.1 Distrib 10.3.27-MariaDB, for Linux (x86_64) using readline 5.1  

Please let me know if more information is needed.


~Robert C

  • Read this and especially this reply


    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
    -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.


    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:

    # 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
    ### Install php composer tool (straight from )
    # 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('', '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 -
    composer install
    cd -
    ### Create 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
    ### 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

  • 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?