SOLVED [CPANEL-30253] Version 84 update, apache global configuration settings reset

vacancy · Nov 6, 2019

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.

anton_latvia · Nov 7, 2019

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)

ciao70 · Nov 7, 2019

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:

Code:

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 3472

ciao70 · Nov 7, 2019

Hello,

New Thread - Bug, when upgrading v82 to v84

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

forums.cpanel.net

cPanelLauren · Nov 7, 2019

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?

ciao70 · Nov 7, 2019

Hello cPanelLauren,

The problem also concerns the case reported by me and by anton_latvia ?

warn [xml-api] DNS query failure:

Thanks

vacancy · Nov 7, 2019

cPanelLauren said:
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)

cPanelLauren · Nov 7, 2019

ciao70 said:
Hello cPanelLauren,

The problem also concerns the case reported by me and by anton_latvia ?

warn [xml-api] DNS query failure:

Thanks

I'd check this thread it's related to IPv6 and libunbound but not the error in this thread: In Progress - [CPANEL-30266] AutoSSL did not renew the certificate

vacancy said:
When I click the whm logo after the update process, I see the welcome screen.

The logo in the top left? And by welcome screen do you mean the WHM home page?

vacancy · Nov 7, 2019

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.

cPanelLauren · Nov 7, 2019

vacancy said:
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 information

SJR · Nov 7, 2019

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:

Security/Server Side TLS - MozillaWiki

wiki.mozilla.org

The 'Intermediate' Cipher suite is the one used.
This answers ciao70's comment about the modified ciphers above.
When comparing the previous cipher suite with the new one, I think there were 4 deleted and 2 added.
Since I prefer to use the 'defaults', I then changed the SSL Cipher Suite setting to the default, rather than my old settings, and rebuilt apache.
I wanted to do a rebuild anyway due to my concerns about the settings being scrambled somehow during the update to version 84.
As a further note, I changed all the other configurations (Webdisk, Web services, ftp, exim, and mailserver) to use the new cipher suite, or new default in these other configurations. I want to keep the cipher lists current.
Yes, there appears to be something broken in the version upgrade, but this is how I dealt with it.
Good luck.

amin alnasra · Nov 12, 2019

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

rahnev · Nov 12, 2019

Same here. Apache settings were reset to defaults...very annoying...

anton_latvia · Nov 12, 2019

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.

sahostking · Nov 13, 2019

oooo not good. I better check our servers

gnt · Nov 13, 2019

Hello,
Same here. All the Global settings returned to defaults...

cPanelLauren · Nov 13, 2019

Hello,

This should have been resolved as of cPanel 84.0.8 which versions are you guys on?

vacancy · Nov 13, 2019

I've updated from version 82 to 84.0.9 and confirmed that the settings remain constant.

Thank you.

rahnev · Nov 14, 2019

cPanelLauren said:
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.

eLIANT · Nov 14, 2019

Just upgraded to 84.0.9 - many services down:
cphulkd
exim-26
ftpd
httpd
imap
pop

What's going on?!

Thread starter	Similar threads	Forum	Replies	Date
A	Nginx status cpanel/whm lastversion LTS	Web Servers and Applications	1	May 11, 2023
A	What is the recommended/ good way for installing PHPExcel Library files in Cpanel?	Web Servers and Applications	1	Apr 2, 2023
L	cPanel / Litespeed 8.1 and 8.2	Web Servers and Applications	9	Mar 1, 2023
M	Will installation of mastodon be possible on cpanel in the future?	Web Servers and Applications	1	Jan 21, 2023
G	lfd on cpanel server: Excessive resource usage:	Web Servers and Applications	3	Jan 18, 2023

SOLVED [CPANEL-30253] Version 84 update, apache global configuration settings reset

Well-Known Member

Well-Known Member

Well-Known Member

Well-Known Member

Product Owner II

Well-Known Member

Well-Known Member

Product Owner II

Well-Known Member

Product Owner II

Active Member

Member

Well-Known Member

Well-Known Member

Well-Known Member

Registered

Product Owner II

Well-Known Member

Well-Known Member

Active Member