[BUG] Global php.ini files reverted to defaults, if PHP is CL/etc-supplied (RE-499)
Closed this issue · 12 comments
Describe the bug
ELevate process does not seem to restore php.ini backups into the live locations, hence things like timezone are lost.
I thought that it was taking backups of the files and then restoring them?
Server time is OK, it's PHP config that gets defaulted.
Keep in mind that many websites will not enter a failed state due to this, however heavy websites will perish.
To Reproduce
Steps to reproduce the behavior:
- Upgrade server via ELevate.
- Crons fire at incorrect time.
- PHP timezone revert to UTC.
- memory_limit etc all defaulted.
See below diff check between the in-place files and the rpmsave/SOE (which ELevate did not produce):
# diff -u /opt/cpanel/ea-php81/root/etc/php.ini /opt/cpanel/ea-php81/root/etc/php.ini.rpmsave
--- /opt/cpanel/ea-php81/root/etc/php.ini 2024-07-31 00:23:41.564004268 +1000
+++ /opt/cpanel/ea-php81/root/etc/php.ini.rpmsave 2024-05-07 16:08:46.160442066 +1000
@@ -119,7 +119,7 @@
; Production value: On
; log_errors
-; Default Value: On
+; Default Value: Off
; Development Value: On
; Production Value: On
@@ -259,7 +259,7 @@
; Note: You need to use zlib.output_handler instead of the standard
; output_handler, or otherwise the output will be corrupted.
; http://php.net/zlib.output-compression
-zlib.output_compression = Off
+zlib.output_compression = On
; http://php.net/zlib.output-compression-level
;zlib.output_compression_level = -1
@@ -370,7 +370,7 @@
; Maximum execution time of each script, in seconds
; http://php.net/max-execution-time
; Note: This directive is hardcoded to 0 for the CLI SAPI
-max_execution_time = 30
+max_execution_time = 660
; Maximum amount of time each script may spend parsing request data. It's a good
; idea to limit this time on productions servers in order to eliminate unexpectedly
@@ -380,18 +380,18 @@
; Development Value: 60 (60 seconds)
; Production Value: 60 (60 seconds)
; http://php.net/max-input-time
-max_input_time = 60
+max_input_time = 330
; Maximum input variable nesting level
; http://php.net/max-input-nesting-level
;max_input_nesting_level = 64
; How many GET/POST/COOKIE input variables may be accepted
-; max_input_vars = 1000
+max_input_vars = 5000
; Maximum amount of memory a script may consume (128MB)
; http://php.net/memory-limit
-memory_limit = 128M
+memory_limit = 256M
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
; Error handling and logging ;
@@ -481,7 +481,7 @@
; server-specific log, STDERR, or a location specified by the error_log
; directive found below. While errors should not be displayed on productions
; servers they should still be monitored and logging is a great way to do that.
-; Default Value: On
+; Default Value: Off
; Development Value: On
; Production Value: On
; http://php.net/log-errors
@@ -659,7 +659,7 @@
; Its value may be 0 to disable the limit. It is ignored if POST data reading
; is disabled through enable_post_data_reading.
; http://php.net/post-max-size
-post_max_size = 8M
+post_max_size = 96M
; Automatically add files before PHP document.
; http://php.net/auto-prepend-file
@@ -802,7 +802,7 @@
; Maximum allowed size for uploaded files.
; http://php.net/upload-max-filesize
-upload_max_filesize = 2M
+upload_max_filesize = 92M
; Maximum number of files that can be uploaded via a single request
max_file_uploads = 20
@@ -813,7 +813,7 @@
; Whether to allow the treatment of URLs (like http:// or ftp://) as files.
; http://php.net/allow-url-fopen
-allow_url_fopen = Off
+allow_url_fopen = On
; Whether to allow include/require to open URLs (like http:// or ftp://) as files.
; http://php.net/allow-url-include
@@ -880,7 +880,7 @@
[Date]
; Defines the default timezone used by the date functions
; http://php.net/date.timezone
-date.timezone = "UTC"
+date.timezone = "Australia/Sydney"
; http://php.net/date.default-latitude
;date.default_latitude = 31.7667
@@ -1642,3 +1642,4 @@
; Local Variables:
; tab-width: 4
; End:
Expected behavior
php.ini backups for all versions being restored should bring the customisations back, avoiding impact to applications.
This seems confirmed now via cPanel Support ticket 95340245 (access within re: triage/diagnostics).
How quickly will this be addressed once verified?
When RPMs are removed, files classified as "config" are backed up to .rpmsave files (php.ini.rpmsave, for example). This happens when we remove EA4, prior to upgrading the operating system (assuming the config file has been altered from the state it was shipped with). When the RPM is re-installed in stage 4, we follow up by finding all of the .rpmsave files associated with easy apache and putting them back into place.
We do this here https://github.com/cpanel/elevate/blob/main/lib/Elevate/Components/EA4.pm#L139 and it was added in #367 back in January.
Out of curiosity, what is the contents of ea4_config_files in /var/cpanel/elevate on the server where this didn't happen for you?
When RPMs are removed, files classified as "config" are backed up to .rpmsave files (php.ini.rpmsave, for example).
The php.ini.rpmsave files present were not added by ELevate, rather by previous processes months ago.
(Unless there is another location where you're saving the rpmsave copies to?)
/opt/cpanel $ ls -l ea-php*/root/etc/php.ini.rpmsave
-rw-r--r-- 1 root root 60881 Dec 17 2020 ea-php73/root/etc/php.ini.rpmsave
-rw-r--r-- 1 root root 60893 May 7 16:08 ea-php74/root/etc/php.ini.rpmsave
-rw-r--r-- 1 root root 60893 May 7 16:08 ea-php81/root/etc/php.ini.rpmsave
-rw-r--r-- 1 root root 60893 May 7 16:08 ea-php82/root/etc/php.ini.rpmsave
-rw-r--r-- 1 root root 60893 May 7 17:44 ea-php83/root/etc/php.ini.rpmsave
we follow up by finding all of the .rpmsave files associated with easy apache and putting them back into place.
That doesn't seem to have happened, as the default files persisted on many (if not all) servers for us at least.
Out of curiosity, what is the contents of ea4_config_files in /var/cpanel/elevate on the server
"ea4_config_files" : {}, (checked on 7x servers, all have the same value)
I've sent you leapp-upgrade.log for 1x machine.
Thank you for this report and the additional information. We were able to replicate this and I believe that I see the source of the issue. It is currently being tracked internally as RE-499.
@lsthompson TLDR: If you move those ini.rpmsave files back in place post-upgrade, this is all our fix will end up doing. Sorry for the oversight/bug. Thank you for the additional information. This helped us understand the problem. We'll get it fixed going forward.
Thanks folks. @toddr - how does that work given their date stamps? Please ensure you have identified all causes before being confident of a fix. It seems fortunate that any rpmsave files existed in this instance - or no?
Thanks, but I don't see how that makes sense with a May 7th date on the rpmsave file variants? ELevate was this week.
Thanks, but I don't see how that makes sense with a May 7th date on the rpmsave file variants? ELevate was this week.
I believe the date stamp would be the date the file was last modified not when it was renamed.
I believe the date stamp would be the date the file was last modified not when it was renamed.
Ah cool, thanks for clarifying - I'd appreciate if you could please double-check / confirm this, too. :-)
EDIT: I think you are correct - restoring the rpmsave on the impacted servers, it did seem fairly consistent.
Hey @toddr - don't forget that Changelog.md is missing v51 and v52, and version is missing v52!