History | Log In     View a printable version of the current page.  
Issue Details (XML | Word | Printable)

Key: OX-1310
Type: Bug Bug
Status: Closed Closed
Resolution: Fixed
Priority: Critical Critical
Assignee: andrew.hill
Reporter: Arlen Coupland
Votes: 0
Watchers: 0
Operations

If you were logged in you would be able to see more operations.
OpenX Ad Server

Failed To Upgrade Configuration File during Upgrade

Created: 20/Feb/08 10:57 AM   Updated: 28/Apr/08 02:51 PM
Component/s: OXP: Installation & Upgrade System
Affects Version/s: OpenX 2.4.4
Fix Version/s: OpenX 2.5.67-beta, OXP 2.7.5-dev, OpenX 2.4.6, Milestone 19
Security Level: Public (All users can see these issues)

Time Tracking:
Original Estimate: 4h
Original Estimate - 4h
Remaining Estimate: 2.8h
Time Spent - 1.2h Remaining Estimate - 2.8h
Time Spent: 1.2h
Time Spent - 1.2h Remaining Estimate - 2.8h

Issue Links:
Reference


 Description  « Hide
Users have reported that during the upgrade to 2.4.4 from previous versions of 2.4, they recieve the message 'Failed To Upgrade Configuration File'
This does not seem specific to 2.4.4, as there were some reports during 2.4.3.

It seems to occur when a user has moved their old copy to a backup folder. They then upload the new files to their active foldername, and copy their config files (default.conf.php and www.example.com.conf.php) to the new installation's var folder. Perhaps this assists in testing, but it is not guarenteed all users took this step, or that it is part of the cause.

The upgrader will pass the System Check page - and full write permissions are granted to the 'var' folder.

1 user reported that deleting the 'default.conf.php' helped them solve this error message, however it didn't seem this fix helped other users.

It seems to happen during the part of Upgrade which creates a backup of the configuration file, and then tries to overwrite the current config file.

http://forum.openx.org/index.php?showtopic=503417758

This might be related to the issue of ticket OX-1311



 All   Comments   Work Log   Change History   FishEye   Crucible   Builds      Sort Order: Ascending order - Click to sort in descending order
Monique Szpak - 20/Feb/08 11:57 AM
The user should ensure that the copied config file is writeable. Copying a read-only config file into a writeable var folder does not by default alter the permission of the copied file.

The installer sys check page checks for file permissions prior to determing whether a config file exists. If a config file exists, denoting an upgrade, an additional check on the config file permission could be made.



Arlen Coupland - 28/Feb/08 02:49 PM
It has been reported in the forum thread that the users have checked the owner and chmod of the file and it does not fix it for them

What has helped some users is that they were installing on 'test.example.com' while the configuration file was for 'www.example.com'
Editing the config file to be 'test.example.com' solved the issue for them



Arlen Coupland - 28/Feb/08 03:17 PM - edited
I think that enough users have experienced the problem that either:

a) We edit error message in this specific case to say that the user is upgrading using a domain which OpenX isn't configured to use as default
However, this goes against the idea of the 'default.conf.php' – what if OpenX is configured to use http://www.example.com as default, but user is upgrading using http://example.com ? Accessing OpenX admin using this URL has worked for them because of default.conf.php. Starting the upgrade and getting through most steps worked for them. At some point, the upgrader is trying to edit example.com.conf.php instead of www.example.com.conf.php, and can't do so because that file doesn't exist.

b) It could instead update the config file for the domain used in default.conf.php
However, what if they do have a config for ads2.example.com, yet ads1.example.com is the default? The upgrader should update ads2.example.com.conf.php and leave the other config file alone in the case that these config files are different and used for different purposes. In this case, perhaps it should notify that the other config file wasn't updated and the upgrader needs to be re-run for the other configuration file (could be using a different DB).
What if example.com.conf.php config file only contains 'realConfig=www.example.com' ? Is the updater replacing the content of example.com.conf.php and not updating www.example.com.conf.php, even though that is the 'default' config file ?

c) It could create ads2.example.com.conf.php if it doesn't exist, and set it as default. The old default config file would be outdated.

...

There are many options and variables, too many to list here once I truly started thinking about it. A document of user-cases would be needed to explore what each case would be and what the best solution for each case is.

Perhaps the following idea will fit:

if ( $CurrentDomain.conf.php does not exist, or content contains 'realConfig=' ) { --> update the config file listed in 'realConfig' or, if that does not exist, default.conf.php } else { --> update $CurrentDomain.conf.php }

The case where $CurrentDomain is not the domain used in default.conf.php AND $CurrentDomain.conf.php does exist AND contains actual configuration information will be rare. It means they are either A) advanced users who have seperate configs for seperate domains, or they are B) basic users who in the past (before default.conf.php existed) copied www.example.com.conf.php to example.com.conf.php without using the recommended 'realConfig' option.

In case A) they will need to upgrade the other domain seperately. This should be known to them. They will need to place the UPGRADE file back in the var folder.

In case B) there could be a problem where only example.com.conf.php is updated, leaving www.example.com.conf.php un-updated. This might be an issue if www.example.com.conf.php requires an update, and is set as the default config file, yet does not get updated. This case would be rare, and I see no easy solution, as it revolves around an imperfect configuration of OpenX
edit Actually in case B, we would have to research to see that this might affect users who didn't themself copy www.example.com.conf.php to example.com.conf.php, but perhaps a previous upgrade overwrote example.com.conf.php even though it only contained 'realConfig' inside of it. This could be a more common case, if the upgrader does truly behave in this fashion.



Pawel Dachterski - 28/Apr/08 01:14 PM
Failing test cases:
TC1:
1. Setup

127.0.0.2.conf.php (delivery) (realConfig=85.111.111.111)
127.0.0.3.conf.php (HTTPS delivery) (realConfig=85.111.111.111)
85.111.111.111.conf.php (not writeable, real config)
85.111.111.112.conf.php (realConfig=85.111.111.111)
[webpath]
admin=85.111.111.112:1080/openx/www/admin
delivery=127.0.0.2:1080/openx/www/delivery
deliverySSL=127.0.0.3:1081/openx/www/delivery
images=127.0.0.4:1080/openx/www/images
imagesSSL=127.0.0.5:1080/openx/www/images

2. Installation stated from 85.111.111.112:
"File Permissions - no errors"
and 85.111.111.111.conf.php is not checked! (not on the list )
rrr- 1 85.111.111.111.conf.php

On the list:
-127.0.0.2.conf.php
-127.0.0.3.conf.php
-85.111.111.112.conf.php
-default conf.php

3. After installation:

  • 127.0.0.2.conf.php (now contains updated realConfig from 85.111.111.111.conf.php)
    -127.0.0.3.conf.php (realConfig=127.0.0.2)
  • 85.111.111.112.conf.php (realConfig=127.0.0.2)

BTW: (only 85.111.111.112.conf.php was copied for backup)



Pawel Dachterski - 28/Apr/08 02:51 PM
Verified on openx-2.5.67-beta-rc4 and openx-2.4.6-rc2