[CPANEL-30253] Version 84 update, apache global configuration settings reset
Hello there
All the settings that I made in Apache global configuration before version 84 are reverted to the default settings after updating to version 84.
Hundreds of servers we've configured have returned to the default settings, which caused us serious problems.
Edit: In addition, the memory_limit settings returned to default.
-
I am posting here, so other administrators are warned. When upgrading from v82 to v84 - on all our servers PHP setting memory_limit was reset to default 128M, causing sites, which require more memory - stop working. Please beware and fix after the upgrade. Support ticket has been opened (13716113) 0 -
Hello, Same problem after upgrading from v82 to v84 info [set_php_memory_limits] The memory limit for ea-php56 has been set to 128M based on the servers installed memory (64440 MiB) info [set_php_memory_limits] The memory limit for ea-php71 has been set to 128M based on the servers installed memory (64440 MiB) We had to manually set it to 1GB In addition, the ssl cipher order was also modified and two ciphers were deleted In addition: warn [xml-api] DNS query failure (.......in-addr.arpa/PTR): Cpanel::Exception::Timeout/(XID p2jpa5) DNS query (.........in-addr.arpa/PTR) timeout! at /usr/local/cpanel/Cpanel/DNS/Unbound.pm line 366. Cpanel::DNS::Unbound::_die_if_query_failed(HASH(0x25a8700)) called at /usr/local/cpanel/Cpanel/DNS/Unbound.pm line 355 Cpanel::DNS::Unbound::recursive_query_or_die(Cpanel::DNS::Unbound=HASH(0x1ef7518), "............in-addr.arpa", "PTR") called at /usr/local/cpanel/Cpanel/DNS/Unbound.pm line 416 eval {...} called at /usr/local/cpanel/Cpanel/DNS/Unbound.pm line 416 Cpanel::DNS::Unbound::recursive_query(Cpanel::DNS::Unbound=HASH(0x1ef7518), "..........in-addr.arpa", "PTR") called at /usr/local/cpanel/Cpanel/DnsUtils/ReverseDns.pm line 341 Cpanel::DnsUtils::ReverseDns::_validate_ptr("IP......", "........in-addr.arpa", "A", CODE(0x25afa60)) called at /usr/local/cpanel/Cpanel/DnsUtils/ReverseDns.pm line 329 Cpanel::DnsUtils::ReverseDns::validate_ipv4_ptr_record("IP.......") called at /usr/local/cpanel/Cpanel/DnsUtils/ReverseDns.pm line 159 Cpanel::DnsUtils::ReverseDns::validate_ptr_record("IP") called at /usr/local/cpanel/Cpanel/DnsUtils/ReverseDns.pm line 96 Cpanel::DnsUtils::ReverseDns::__ANON__() called at /usr/local/cpanel/3rdparty/perl/528/lib/perl5/cpanel_lib/Try/Tiny.pm line 97 eval {...} called at /usr/local/cpanel/3rdparty/perl/528/lib/perl5/cpanel_lib/Try/Tiny.pm line 88 Try::Tiny::try(CODE(0x2586100), Try::Tiny::Catch=REF(0x251ecd0)) called at /usr/local/cpanel/Cpanel/DnsUtils/ReverseDns.pm line 101 Cpanel::DnsUtils::ReverseDns::validate_ptr_records_for_ips(ARRAY(0x25869a0)) called at /usr/local/cpanel/Cpanel/DnsUtils/MailRecords.pm line 658 Cpanel::DnsUtils::MailRecords::validate_ptr_records_for_domains(HASH(0x1db38b8)) called at /usr/local/cpanel/Whostmgr/API/1/EmailAuth.pm line 50 Whostmgr::API::1::EmailAuth::validate_current_ptrs(HASH(0x1dbf7d8), HASH(0x1d87ef0), HASH(0x1d87e30)) called at whostmgr/bin/xml-api.pl line 3619 whostmgr::bin::xml_api::__ANON__(HASH(0x1d87ef0), HASH(0x1dbf7d8), HASH(0x1d87e30), undef) called at /usr/local/cpanel/Whostmgr/API/1/Data/Wrapper.pm line 219 Whostmgr::API::1::Data::Wrapper::__ANON__() called at /usr/local/cpanel/3rdparty/perl/528/lib/perl5/cpanel_lib/Try/Tiny.pm line 97 eval {...} called at /usr/local/cpanel/3rdparty/perl/528/lib/perl5/cpanel_lib/Try/Tiny.pm line 88 Try::Tiny::try(CODE(0x1dbf7f0), Try::Tiny::Catch=REF(0x1ef75d8)) called at /usr/local/cpanel/Whostmgr/API/1/Data/Wrapper.pm line 238 Whostmgr::API::1::Data::Wrapper::execute_internal(CODE(0x1ed5cc0), HASH(0x1dbf7d8), HASH(0x1d87e30), HASH(0x1dc0520), undef) called at whostmgr/bin/xml-api.pl line 3794 whostmgr::bin::xml_api::runapp("validate_current_ptrs", HASH(0x1d87e30), HASH(0x1db3d20), 1, undef) called at whostmgr/bin/xml-api.pl line 3875 eval {...} called at whostmgr/bin/xml-api.pl line 3875 whostmgr::bin::xml_api::batch_runapp(HASH(0x18abd08), HASH(0x1d618a8), HASH(0x1d681f8)) called at whostmgr/bin/xml-api.pl line 3619 whostmgr::bin::xml_api::__ANON__(HASH(0x1d618a8), HASH(0x18abd08), HASH(0x1d681f8), CODE(0x1d5d618)) called at /usr/local/cpanel/Whostmgr/API/1/Data/Wrapper.pm line 219 Whostmgr::API::1::Data::Wrapper::__ANON__() called at /usr/local/cpanel/3rdparty/perl/528/lib/perl5/cpanel_lib/Try/Tiny.pm line 97 eval {...} called at /usr/local/cpanel/3rdparty/perl/528/lib/perl5/cpanel_lib/Try/Tiny.pm line 88 Try::Tiny::try(CODE(0x1d6d7f8), Try::Tiny::Catch=REF(0x1d6b600)) called at /usr/local/cpanel/Whostmgr/API/1/Data/Wrapper.pm line 238 Whostmgr::API::1::Data::Wrapper::execute_internal(CODE(0x1d67a00), HASH(0x18abd08), HASH(0x1d681f8), HASH(0x1d616c8), CODE(0x1d5d618)) called at whostmgr/bin/xml-api.pl line 3794 whostmgr::bin::xml_api::runapp("batch", HASH(0x1d681f8), HASH(0x17b9f08), 0, CODE(0x1d5d618)) called at whostmgr/bin/xml-api.pl line 3526 whostmgr::bin::xml_api::script(CODE(0x1d5d618), "-json", "./batch") called at whostmgr/bin/xml-api.pl line 3472 at /usr/local/cpanel/Cpanel/DNS/Unbound.pm line 425. Cpanel::DNS::Unbound::_warn_query_failure(".........in-addr.arpa", "PTR", "") called at /usr/local/cpanel/Cpanel/DNS/Unbound.pm line 417 Cpanel::DNS::Unbound::recursive_query(Cpanel::DNS::Unbound=HASH(0x1ef7518), ".............in-addr.arpa", "PTR") called at /usr/local/cpanel/Cpanel/DnsUtils/ReverseDns.pm line 341 Cpanel::DnsUtils::ReverseDns::_validate_ptr("IP......", "............in-addr.arpa", "A", CODE(0x25afa60)) called at /usr/local/cpanel/Cpanel/DnsUtils/ReverseDns.pm line 329 Cpanel::DnsUtils::ReverseDns::validate_ipv4_ptr_record("IP......") called at /usr/local/cpanel/Cpanel/DnsUtils/ReverseDns.pm line 159 Cpanel::DnsUtils::ReverseDns::validate_ptr_record("IP........") called at /usr/local/cpanel/Cpanel/DnsUtils/ReverseDns.pm line 96 Cpanel::DnsUtils::ReverseDns::__ANON__() called at /usr/local/cpanel/3rdparty/perl/528/lib/perl5/cpanel_lib/Try/Tiny.pm line 97 eval {...} called at /usr/local/cpanel/3rdparty/perl/528/lib/perl5/cpanel_lib/Try/Tiny.pm line 88 Try::Tiny::try(CODE(0x2586100), Try::Tiny::Catch=REF(0x251ecd0)) called at /usr/local/cpanel/Cpanel/DnsUtils/ReverseDns.pm line 101 Cpanel::DnsUtils::ReverseDns::validate_ptr_records_for_ips(ARRAY(0x25869a0)) called at /usr/local/cpanel/Cpanel/DnsUtils/MailRecords.pm line 658 Cpanel::DnsUtils::MailRecords::validate_ptr_records_for_domains(HASH(0x1db38b8)) called at /usr/local/cpanel/Whostmgr/API/1/EmailAuth.pm line 50 Whostmgr::API::1::EmailAuth::validate_current_ptrs(HASH(0x1dbf7d8), HASH(0x1d87ef0), HASH(0x1d87e30)) called at whostmgr/bin/xml-api.pl line 3619 whostmgr::bin::xml_api::__ANON__(HASH(0x1d87ef0), HASH(0x1dbf7d8), HASH(0x1d87e30), undef) called at /usr/local/cpanel/Whostmgr/API/1/Data/Wrapper.pm line 219 Whostmgr::API::1::Data::Wrapper::__ANON__() called at /usr/local/cpanel/3rdparty/perl/528/lib/perl5/cpanel_lib/Try/Tiny.pm line 97 eval {...} called at /usr/local/cpanel/3rdparty/perl/528/lib/perl5/cpanel_lib/Try/Tiny.pm line 88 Try::Tiny::try(CODE(0x1dbf7f0), Try::Tiny::Catch=REF(0x1ef75d8)) called at /usr/local/cpanel/Whostmgr/API/1/Data/Wrapper.pm line 238 Whostmgr::API::1::Data::Wrapper::execute_internal(CODE(0x1ed5cc0), HASH(0x1dbf7d8), HASH(0x1d87e30), HASH(0x1dc0520), undef) called at whostmgr/bin/xml-api.pl line 3794 whostmgr::bin::xml_api::runapp("validate_current_ptrs", HASH(0x1d87e30), HASH(0x1db3d20), 1, undef) called at whostmgr/bin/xml-api.pl line 3875 eval {...} called at whostmgr/bin/xml-api.pl line 3875 whostmgr::bin::xml_api::batch_runapp(HASH(0x18abd08), HASH(0x1d618a8), HASH(0x1d681f8)) called at whostmgr/bin/xml-api.pl line 3619 whostmgr::bin::xml_api::__ANON__(HASH(0x1d618a8), HASH(0x18abd08), HASH(0x1d681f8), CODE(0x1d5d618)) called at /usr/local/cpanel/Whostmgr/API/1/Data/Wrapper.pm line 219 Whostmgr::API::1::Data::Wrapper::__ANON__() called at /usr/local/cpanel/3rdparty/perl/528/lib/perl5/cpanel_lib/Try/Tiny.pm line 97 eval {...} called at /usr/local/cpanel/3rdparty/perl/528/lib/perl5/cpanel_lib/Try/Tiny.pm line 88 Try::Tiny::try(CODE(0x1d6d7f8), Try::Tiny::Catch=REF(0x1d6b600)) called at /usr/local/cpanel/Whostmgr/API/1/Data/Wrapper.pm line 238 Whostmgr::API::1::Data::Wrapper::execute_internal(CODE(0x1d67a00), HASH(0x18abd08), HASH(0x1d681f8), HASH(0x1d616c8), CODE(0x1d5d618)) called at whostmgr/bin/xml-api.pl line 3794 whostmgr::bin::xml_api::runapp("batch", HASH(0x1d681f8), HASH(0x17b9f08), 0, CODE(0x1d5d618)) called at whostmgr/bin/xml-api.pl line 3526 whostmgr::bin::xml_api::script(CODE(0x1d5d618), "-json", "./batch") called at whostmgr/bin/xml-api.pl line 34720 -
There is an issue we are aware of involving accessing WHM using the initial setup interface: CPANEL-30253 - If a customer uses the "Initial Setup" URL to login to WHM, php.ini settings are edited without confirmation. The URL on a test server looks like the following: https://1.2.3.4:2087/cpsess8874645215/scripts3/initial_setup_wizard1_do
We've been unable to replicate this behavior when not accessing in this manner - are you able to replicate this @vacancy?0 -
Hello cPanelLauren, The problem also concerns the case reported by me and by anton_latvia ? warn [xml-api] DNS query failure: Thanks 0 -
There is an issue we are aware of involving accessing WHM using the initial setup interface: CPANEL-30253 - If a customer uses the "Initial Setup" URL to login to WHM, php.ini settings are edited without confirmation. The URL on a test server looks like the following:
https://1.2.3.4:2087/cpsess8874645215/scripts3/initial_setup_wizard1_do
We've been unable to replicate this behavior when not accessing in this manner - are you able to replicate this @vacancy?
When I click the whm logo after the update process, I see the welcome screen. Apache global configuration settings back to default (cipher settings, min-max connections, keepalive settings, timeout etc.) Php.ini memory_limit settings back to default (128M)0 -
Yes after updating, I click whm logo to return to the main page and the first setup screen open. However, the apache global settings for the automatically cpanel updated servers returned to default. 0 -
Yes after updating, I click whm logo to return to the main page and the first setup screen open. However, the apache global settings for the automatically cpanel updated servers returned to default.
I'll add that to the case notes - thanks for that information0 -
I also noticed my apache options were changed and set back to defaults as soon as I upgraded to verson 84. However, the first thing I did after I noticed this was to change the apache memory back to my previous value and click save. (without checking the 'resart apache' button) As soon as I did this, without doing anything else, I looked at the settings in the apache global configuration - All of the settings were now back to the state they were in prior to the upgrade to version 84, except the SSL Cipher Suite was set to a custom string. I discovered the reason for the changed Cipher Suite - My new custom string was actually the default string prior to the upgrade to 84. (I keep track of these) There is a new value for the default string of ciphers. I read somewhere that cPanel uses Mozilla defaults to set cPanel defaults. Here are the defaults provided by Mozilla: 0 -
I faced the same issue in 6 servers and 1 vps after the automatic update the Apache returned to default while we was sleeping .... in this case really we lose thousands of visitors and our severs appears down or very slow for users and search engines. is this the new quality of service after rising the price of cpanel? I'm very annoyed from your service you must stop this update immediately for other users 0 -
Same here. Apache settings were reset to defaults...very annoying... 0 -
I can not confirm, as all our servers were updated, but at least on one I have noticed reset of other PHP setting - auto_prepend_file - was reset to empty value. 0 -
oooo not good. I better check our servers 0 -
Hello, Same here. All the Global settings returned to defaults... 0 -
Hello, This should have been resolved as of cPanel 84.0.8 which versions are you guys on? 0 -
I've updated from version 82 to 84.0.9 and confirmed that the settings remain constant. Thank you. 0 -
Hello, This should have been resolved as of cPanel 84.0.8 which versions are you guys on?
2 days ago I updated from 82 to 84.0.8 and settings were reset.0 -
Just upgraded to 84.0.9 - many services down: cphulkd exim-26 ftpd httpd imap pop What's going on?! 0 -
Just upgraded to 84.0.9 - many services down: cphulkd exim-26 ftpd httpd imap pop What's going on?!
I"d suggest opening a ticket, the issue noted in this thread does not involve the symptoms you're reporting.0 -
@cPanelLauren Where are the apache settings stored now? Prior to the update it was stored in /var/cpanel/conf/apache/local but I can't find this file anymore. I need to manually remove the min/max directives from that file to adjust it in an include config file. Found it: /etc/cpanel/ea4/ea4.conf 0 -
Upgraded two servers from 82.0 (build 19) to v84.0.19 yesterday, and all the Apache Global Configurations were reset to default. I thought you've fixed the bug! 0 -
Hello @garconcn This is reported as being resolved in 84.0.8 and as far as I am aware this shouldn't have occurred after the update from 82.0.X -> 84.0.19. I'm not seeing any other reports on this as well, can you please open a ticket using the link in my signature? Once open please reply with the Ticket ID here so that we can update this thread with the resolution once the ticket is resolved. Thanks! 0 -
That's the problem with this thread. I saw 2 things talked about. 1. Apache global configuration settings back to default 2. Php.ini memory_limit settings back to default I only ever saw #2 in the release notes or mentioned as being addressed. At least 2 people here have mentioned a problem with #1 since the "fix". I personally have avoided upgrading to 84 since I hadn't heard anything specific about #1 and apparently it's till affecting people. I was planning on upgrading when I had time to make a note of all my global apache settings so they can quickly be reset afterward if things go wrong. One would think when developers are changing where and how settings or stored, they'd do their best to make sure the settings are preserved in all cases. I just don't trust things right now. 0
Please sign in to leave a comment.
Comments
25 comments