Followup of: #1958680: Drupal 8 does not install with safe_mode = On
It turns out that when safe_mode is used, Drupal installation will currently fail when visiting /core/install.php.
Fatal error: Uncaught exception 'Drupal\Core\Config\StorageException' with message 'Missing configuration file: system.logging' in /home/sddf226a7261cfa9/www/core/lib/Drupal/Core/Config/InstallStorage.php:54 Stack trace: #0 /home/sddf226a7261cfa9/www/core/lib/Drupal/Core/Config/FileStorage.php(73): Drupal\Core\Config\InstallStorage->getFilePath('system.logging') #1 /home/sddf226a7261cfa9/www/core/lib/Drupal/Core/Config/FileStorage.php(82): Drupal\Core\Config\FileStorage->exists('system.logging') #2 /home/sddf226a7261cfa9/www/core/lib/Drupal/Core/Config/Config.php(410): Drupal\Core\Config\FileStorage->read('system.logging') #3 /home/sddf226a7261cfa9/www/core/lib/Drupal/Core/Config/Config.php(204): Drupal\Core\Config\Config->load() #4 /home/sddf226a7261cfa9/www/core/includes/errors.inc(156): Drupal\Core\Config\Config->get('error_level') #5 /home/sddf226a7261cfa9/www/core/includes/bootstrap.inc(2271): error_displayable() #6 [internal function]: _drupal_exception_handler(Object(Drupal\Core\Config\StorageException)) #7 {main} in /home/sddf226a7261cfa9/www/core/lib/Drupal/Core/Config/InstallStorage.php on line 54
Proposed solution
It took me a while to figure out that the use of safe_mode was the actual issue here,
so I'd propose to check the requirement to have safe_mode Off very early in the installation process.
Comment | File | Size | Author |
---|---|---|---|
#29 | check_safe_mode-1959062-7.patch | 719 bytes | patrickd |
#19 | check_safe_mode-1959062-19.patch | 1.04 KB | brad.bulger |
#7 | check_safe_mode-1959062-7.patch | 719 bytes | patrickd |
#2 | check_safe_mode-1959062-2.patch | 588 bytes | patrickd |
Comments
Comment #1
webchickSwitching to a task, since there's no reason for this to be held up by thresholds.
Great investigation work!
Comment #2
patrickd CreditAttribution: patrickd commentedThis patch adds a simple "if (ini_get('safe_mode'))" check directly after the PHP version requirement was checked
Comment #3
patrickd CreditAttribution: patrickd commentedTo test the patch:
- Apply it locally (where you have safe_mode turned off by default)
=> Installation should work as always
- Either turn "safe_mode = On" in your php.ini file
- Or as simplytest.me is currently using safe_mode itself you can test it directly:
http://simplytest.me/project/drupal/8.x?patch[]=http://drupal.org/files/...
=> On the installation page a warning about the requirement should show up
Comment #4
penyaskitoTested it locally and with simpletest.me and the user message is more user friendly than a WSOD. RTBCing.
Comment #5
frankcupid CreditAttribution: frankcupid commented#2: check_safe_mode-1959062-2.patch queued for re-testing.
Comment #6
catchSafe mode is deprecated in PHP 5.3 and completely removed in PHP 5.4. I'm OK with failing early in case there's a 5.3 installation with it still enabled, but we should add a comment to remove this check again once we require > 5.4.
Comment #7
patrickd CreditAttribution: patrickd commentedOkay, added a @todo
BUT it also seems like the same error mentioned in the issue summary happens when "open_basedir" is used. open_basedir is AFIAK not deprecated in PHP .. is there a consensus about the compatibility of drupal with the open_basedir option?
Comment #8
JakeWilund CreditAttribution: JakeWilund commentedI've applied the patch in #7 and receive the following error when attempting installation:
Comment #9
patrickd CreditAttribution: patrickd commented@JakeWilund did you have safe_mode activated when you tested it? does the installation work without having the patch applied?
Comment #10
JakeWilund CreditAttribution: JakeWilund commentedI tried installation prior to applying the patch and received the same error. I then proceeded to set safe_mode in my php.ini, but then received an error stating that safe_mode has been deprecated in PHP 5.4 (which I didn't realize my server was running up until that point).
So then I attempted installation after applying the patch, and that's where I'm at now. Back to the original error that I posted above.
Comment #11
patrickd CreditAttribution: patrickd commentedIf you get this error without having the patch applied and without having safe_mode enabled this has nothing to do with this issue.
Please search the queue for similar bug reports / ask on IRC for help / create a new bug report with your error and your server configuration.
Comment #12
patrickd CreditAttribution: patrickd commentedbtw, @JakeWilund can you have a look into your php.info and tell me whether "open_basedir" is set? (See comment #7)
Comment #13
JakeWilund CreditAttribution: JakeWilund commentedopen_basedir is commented out, so not set.
I posted in this issue because it was the closest I could find to the issue I am having. Unless you think that the open_basedir option has something to do with the error I am getting, I will open a new issue as you suggested.
Comment #14
patrickd CreditAttribution: patrickd commentedhmm, when it's not set then it probably hasn't something to do with this.. but your right, the errors are similar
Comment #15
brad.bulger CreditAttribution: brad.bulger commentedi've confirmed that having open_basedir set causes a similar exception:
that's with open_basedir set to /var/www/
Comment #16
patrickd CreditAttribution: patrickd commentedGreat job! thank you.
So we now have to enhance the patch of #7 and add the same check for open_basedir in.
Comment #17
patrickd CreditAttribution: patrickd commentedtagging with novice
Comment #18
brad.bulger CreditAttribution: brad.bulger commentedbtw, testing that glob() has not returned FALSE in InstallStorage->getComponentNames() prevents that exception. that looks like a PHP bug - https://bugs.php.net/bug.php?id=47358
instead, the installation fails in "Verify requirements" (core/install.php?langcode=en&profile=standard) with the message
it seemed worth looking into why it was failing, since as mentioned in #7 open_basedir is not deprecated, but that was all i found.
Comment #19
brad.bulger CreditAttribution: brad.bulger commentedthis is an update of the patch to include a similar check of open_basedir, if in fact that's what you all want to do.
Comment #20
patrickd CreditAttribution: patrickd commentedI just talked about this with chx and he also thinks that we should not specifically support open_basedir because it's just not really secure and you can bypass it with most of the commonly used php extensions. So if we don't specifically support open_basedir and drupal does not work with it turned on - just drop it completely.
Patch looks good for me!
thanks!
Comment #21
John Pitcairn CreditAttribution: John Pitcairn commentedWon't that be a problem for a lot of hosting environments, where open_basedir use is mandated by the hosting provider, or by corporate IT requirements? It may be hard to convince IT departments that their requirement of a non-deprecated PHP "safety" feature should be relaxed just to support Drupal 8.
Comment #22
patrickd CreditAttribution: patrickd commentedThese hosting providers have to understand that this isn't a "safety" feature, because it can be bypassed stupidly simple (just google for open_basedir).
I'm also a little sad that there are currently no very good ways to secure php environments without using a virtual-machine or kernel-virualization technology. But that's just the way it is
Comment #24
John Pitcairn CreditAttribution: John Pitcairn commentedSadly, the hosts and (especially) company IT crew tend to just mandate policy and that's it. Changing their minds can be impossible. In the case of hosting providers we can always switch, but for some of the more entrenched company-hosted environments we will most likely just be stuck with it.
It's going to be hard to tell whoever is in charge of the shiny new Drupal project that their IT department won't let Drupal 8 run because it requires an "insecure" (their words) server setup. We can't claim it's a deprecated feature, and whether it actually provides any meaningful security will be largely irrelevant in that discussion. Just sayin'.
Comment #25
patrickd CreditAttribution: patrickd commented#19: check_safe_mode-1959062-19.patch queued for re-testing.
Comment #26
brad.bulger CreditAttribution: brad.bulger commentedlast requeue for testing passed
Comment #27
alexpottI can see the sense if bailing out with safe_mode being ON as that is deprecated in 5.3 and gone in 5.4... but I feel uncomfortable with the open_basedir change.
Putting back to needs review for more discussion. Also I would not be against this issue re-focussing to just the safe_mode check (as it was originally) and creating a new issue to discuss the open_basedir problem.
Comment #28
catchI'd be fine with splitting the issue.
With open_basedir can we do something like read the current value of open_basedir, remove the current working directory, set it back with ini_set(), then check a hook_requirements() warning up?
Comment #29
patrickd CreditAttribution: patrickd commentedCreated a separate issue for open_basedir: #2019911: Add install requirement that open_basedir = Off since 8.x currently doesn't support it
Re-adding the safe_mode = Off patch of comment #7
Can we switch this back to RTBC then? (when patch stays green, what it most likely will)
Comment #30
brad.bulger CreditAttribution: brad.bulger commentedi'd think so. there and back again.
Comment #31
alexpottCommitted 00155e5 and pushed to 8.x. Thanks!