Problems upgrading AtoM to 2.2
|Assignee:||Jesús García Crespo||% Done:|
|Target version:||Release 2.2.1|
|Google Code Legacy ID:||Tested version:||2.2, 2.3|
Reported by multiple users in the user forum.
Most users are encountering a 500 error via PDO, that looks something like this:
2015/07/13 13:55:46 [error] 755#0: *8 FastCGI sent in stderr: "PHP message: Unable to open PDO connection [wrapped: SQLSTATE  Access denied for user 'root'@'localhost' (using password: NO)]" while reading response header from upstream, client: 192.168.100.99, server: _, request: "GET / HTTP/1.1", upstream: "fastcgi://unix:/var/run/php5-fpm.atom.sock:", host: "192.168.100.101"
A workaround has been reported by another user (https://groups.google.com/d/msg/ica-atom-users/L3jB7FQMaN8/emSoKf9ISp4J)
I'm using Ubuntu 14.04 x32, Ubuntu 14.04 x64, Windows8 x64 and so far, this is what I tried and seemed to have worked: Workaround in Ubuntu: After following AtoM's instructions you will get a 505 error. As said in this thread just rename or remove /usr/share/nginx/atom/config/config.php. Now it will appear another error (Unable to open PDO connection [wrapped: SQLSTATE  Access denied), so on Terminal type: sudo su sudo chown -R www-data:www-data /usr/share/nginx/atom/uploads sudo service php5-fpm restart Workaround in Windows: In version 2.1.2 if you placed AtoM's files directly in WAMP's WWW folder or the original AtoM's folder without modifying its name (e.g. <atom-2.1.2>) you just had to type "localhost" in browser to start it. However if you place Atom's folder with another name (e.g. just <atom>) it would give a 505 error. Now in 2.2.0 version, no matter how files or folders are placed in WAMP's WWW folder you will get a 505 error, so all you have to do is paste http://localhost/<foldername_ifexists>/index.php/sfInstallPlugin/Checksystem in your browser to start installing Atom.
Another user reported a theory as to the source of the issue (https://groups.google.com/d/msg/ica-atom-users/L3jB7FQMaN8/ca7NIyLix2IJ):
I think that there is some problem in getvalues on plugins/sfInstallPlugin. Because, I did some testing and the form Database configuration isn't sending the values. In first time, I didn't change the standard values (database: atom, username: root) and I typed my password only. It doesn't work! So, I tried to use other the username. ... I restarted the service php5-fpm in Database Configuration form and the installation worked. I'm using AtoM in Ubuntu/Linux and I used the command XXXXX@XXXX:~$ sudo restart php5-fpm to restart.
Users can upgrade without receiving 500 errors. Database password set up during creation of new DB should be respected by the rest of the import process.
This, along with the ES issue for which Mike C has made a patch (outlined in #8744), may require a 2.2.1 release, depending on the cause once we have investigated. As dicussed in internal AtoM meeting, assigning to David J for investigation upon his return.
#3 Updated by Mike Gale about 5 years ago
In my testing I still ran into an issue. It might be because of how I do my php5-fpm/nginx configs or something weird, but I don't believe so...Steps I took:
- clone fresh AtoM install - git clone firstname.lastname@example.org:atom -b dev/issue-8747-cached-config-php test
- setup permissions / nginx config / etc
- in the web installer, enter an invalid username (e.g. 'root2') when it gets to the form to fill in database credentials
- the page will refresh with the correct error expected ('root2' invalid username)
- enter some correct user credentials
- hit next
At this point I kept running into a generic 'permission denied' error page.
#4 Updated by Jesús García Crespo about 5 years ago
- Status changed from Code Review to Feedback
- Assignee changed from David Juhasz to Mike Gale
I would suggest to look at configureDatabase() in detail (in sfInstall.class.php). After writing the new contents of config.php with file_put_contents() make sure that a call to file_get_contents() is not getting the old values but the news. If you are getting the old ones, try to do the same call after opcache_invalidate() and apc_delete_file() are invoked and see if that fixes the problem. Let's sit together on Monday to take a look, but I wanted to add these details so I don't forget where we should be looking at.
#6 Updated by Mike Gale about 5 years ago
- File pasted_image_at_2015_09_14_04_08_pm.png added
I'm getting a different result now on my dev box. Instead of saying invalid user 'root2', it says '' is an invalid user for some reason. But if I subsequently enter a correct login, the installer continues properly.
HOWEVER, I tested this bug on a new vagrant box, and it let me continue in the installer with an invalid mysql login until I clicked next a couple times, then it gave me a stack trace / error. I've attached a screen shot.