[open] PHAR installer upgrade config.php side-effects

[fredp]

Summary: The PHAR installer upgrade "resets" previously set 'root_url' and 'ssl_url' $config variable values which results in these variables no longer having their values automatically generated. Downstream effects impact the entire system.

Details:
I've been testing upgrades of 1.12.1 installs using the PHAR installer. After a successful upgrade, I started to debug some of my smarty and module issues. I enabled $config['debug'] and $config['debug_to_log'] in config.php. While testing, I noticed odd entries in debug.log:

exception Could not connect to the async processing action

and occasionally, at the top of both front-end and Admin console pages, I'd see these errors:

Warning: fsockopen(): php_network_getaddresses: getaddrinfo failed: Name or service not known in /home/cms2/public_html/modules/CmsJobManager/CmsJobManager.module.php on line 303

Warning: fsockopen(): unable to connect to :80 (php_network_getaddresses: getaddrinfo failed: Name or service not known) in /home/cms2/public_html/modules/CmsJobManager/CmsJobManager.module.php on line 303

I did some debugging of CmsJobManager.php and found that, indeed, the hostname used was an empty string (''). Strange.

Further investigation found that in smarty, the {root_url} tag was also returning an empty string.

So, I looked more closely at config.php and noticed that the PHAR installer had changed the values of my 1.21.1 $config['root_url'] and $config['ssl_url'] variables to empty strings. Not good.

I worked around the issue by calling unset() on these two variables, as I do with other ArrayAccess objects, and that resolved the issue--the automatic value generation magic of cms_config was restored for these variables and no more fsockopen() errors.

This should be reproducible, but if not, let me know if you need more info.

[calguy1000]

I did a quick upgrade test from 2.1.6 to 2.2 with a site that had the root_url specified in the config file, and could not reproduce this issue with empty values in the output config.php

So a bit more digging is required.

[deactivated010521]

For the time being I run CmsJobManager.module.php -> trigger_async_processing() with some extra audit statements. Switching between hostnames with and without https gave some weird problems.

These are now solved but I will keep an eye on the admin logs during testing:

Code: Select all

 audit('', 'prefix_scheme', $prefix_scheme);
 audit('', 'get_host', $url_ob->get_host());
 audit('', 'get_port', $url_ob->get_port());
 audit('', 'errno', $errno);
 audit('', 'errstr', $errstr);

[esmiran]

I have similar problem on clean instalation 2.2 beta2 + svn.
On top of front and admin page sometimes displays these errors:

Code: Select all

Warning: fsockopen(): php_network_getaddresses: getaddrinfo failed: Name or service not known in /var/www/cms2/modules/CmsJobManager/CmsJobManager.module.php on line 296

Warning: fsockopen(): unable to connect to :80 (php_network_getaddresses: getaddrinfo failed: Name or service not known) in /var/www/cms2/modules/CmsJobManager/CmsJobManager.module.php on line 296

Using only http protocol, my config.php is:

Code: Select all

$config['dbms'] = 'mysqli';
$config['db_hostname'] = 'localhost';
$config['db_username'] = '*********';
$config['db_password'] = '*************';
$config['db_name'] = 'cms2DB';
$config['db_prefix'] = 'cms_';
$config['timezone'] = 'Europe/Prague';
$config['db_port'] = 3306;
$config['debug'] = false;
$config['debug_to_log'] = false;
$config['admin_dir'] = 'admin';
$config['admin_url'] = 'http://my.testserver.cz/admin';
$config['default_encoding'] = 'utf-8';
#$config['page_extension'] = '.html';
$config['url_rewriting'] ='mod_rewrite';
$config['root_url'] = '';
$config['ssl_url'] = '';

System information:
----------------------------------------------
Cms Version: 2.2-beta2

Installed Modules:
AdminSearch: 1.0.3
CGContentUtils: 2.2.2
CGExtensions: 1.54.1
CGSimpleSmarty: 2.1.6
CMSContentManager: 1.1.5
CMSMailer: 6.2.14
CmsJobManager: 0.1
DesignManager: 1.1.2
FileManager: 1.6.3
FilePicker: 1.0.alpha
FrontEndUsers: 2.3.2
MenuManager: 1.50.3
MicroTiny: 2.1
ModuleManager: 2.1
Navigator: 1.0.6
News: 2.51
Search: 1.51.1

Config Information:
php_memory_limit:
max_upload_size: 12000000
url_rewriting: mod_rewrite
page_extension:
query_var: page
auto_alias_content: true
locale:
set_names: true
timezone: Europe/Prague
permissive_smarty: false

Php Information:
phpversion: 5.6.29-0+deb8u1
md5_function: On (True)
json_function: On (True)
gd_version: 2
tempnam_function: On (True)
magic_quotes_runtime: Off (False)
E_ALL: 22527
E_STRICT: 0
E_DEPRECATED: 0
test_file_timedifference: No time difference found
test_db_timedifference: No time difference found
create_dir_and_file: 1
memory_limit: 128M
max_execution_time: 60
register_globals: Off (False)
output_buffering: 4096
disable_functions:
open_basedir:
test_remote_url: Failure
file_uploads: On (True)
post_max_size: 20M
upload_max_filesize: 12M
session_save_path: /var/lib/php5/sessions (1733)
session_use_cookies: On (True)
xml_function: On (True)
xmlreader_class: On (True)
check_ini_set: On (True)
curl: On

Performance Information:
allow_browser_cache: On (True)
browser_cache_expiry: 60
php_opcache: On (True)
smarty_cache: Off (False)
smarty_compilecheck: Off (False)
auto_clear_cache_age: On (True)

Server Information:
Server Software: Apache/2.4.10 (Debian)
Server Api: apache2handler
Server Os: Linux 3.16.0-4-amd64 On x86_64
Server Db Type: MySQL (mysqli)
Server Db Version: 5.5.54
Server Db Grants: Found a "GRANT ALL" statement that appears to be suitable


Permission Information:
tmp: /var/www/cms2/tmp (0777)
tmp_cache: /var/www/cms2/tmp/cache (0777)
templates_c: /var/www/cms2/tmp/templates_c (0777)
modules: /var/www/cms2/modules (0777)
uploads: /var/www/cms2/uploads (0777)
File Creation Mask (umask): /var/www/cms2/tmp/cache (0777)
config_file: 0666
----------------------------------------------

[calguy1000]

I still cannot get the install or the upgrade routines to corrupt the root url.

I have now done four different tests with the brand-new 2.2-beta2 code and cannot reproduce this issue. For new installs the root_url is never placed in the output config.php file, and for upgrades... when the root_url is explicitly specified in the config.php then it is properly preserved.

So I am going to need you people that are running svn to do a bit more digging into the code.