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

Following http://learn.elgg.org/en/stable/intro/install.html , 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.

Thanks,

~Robert C

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