login.txt issue during installation (not corrected by the various fixes discussed previously)

I'm experiencing the behavior in which the irst check of login.txt (at step 1) succeeds, but when moving to step 2, authentication begins looping to fail ("Error: your login.txt key does not match correctly. Please download a new authentication string from below and try again."), each time producing a new authentication string in the page which does NOT match the string in the presented download link. (That seems like a pretty big problem to me...)

I installed gallery2 2.3 (via FreeBSD ports) on a host that I own and have complete control over. I moved the entire application directory (as yet unconfigured) under a regular user's UserDir (that is, the Apache directive), and then started in with installation. I am certain that I am creating login.txt with the correct content and in the correct location because step 1 completes successfully on the first pass.

I inserted echoes of $fileAuth and $this->_uniqueKey in install/steps/AuthenticateStep.class and found that upon each click of "authenticate" on the failure page, $this->_uniqueKey is updated to whatever is currently displayed, and $fileAuth is picking up the correct value from the file (but that is no longer what the session's looking for).

I have taken all the steps at http://codex.gallery2.org/Gallery2:FAQ#The_installer_does_not_accept_my_login.txt.2C_what.27s_wrong.3F without any change.

I am not running PHP in safe mode (ie, I don't have the same problem as http://gallery.menalto.com/node/84866, http://gallery.menalto.com/node/83614, or http://gallery.menalto.com/node/82854).

I know that this is not a file permissions problem (ie, it's not http://gallery.menalto.com/node/74131), as Apache httpd is running as the user www which does have access (by way of the group web) to write to files in the gallery2 directory and all subdirectories:

% ls -l /home/gr/public_html/Pictures/gallery2
total 230
-r--rw-r-- 1 gr web 18011 Oct 18 03:16 LICENSE
-r--rw-r-- 1 gr web 65556 Oct 18 03:16 MANIFEST
-r--rw-r-- 1 gr web 85092 Oct 18 03:16 README.html
-r--rw-r-- 1 gr web 2118 Oct 18 03:16 bootstrap.inc
-r--rw-r-- 1 gr web 1520 Oct 18 03:16 embed.php
drwxrwxr-x 2 gr web 512 Oct 18 03:18 images
-r--rw-r-- 1 gr web 1989 Oct 18 03:16 index.php
-r--rw-r-- 1 gr web 9206 Oct 18 03:16 init.inc
drwxrwxr-x 6 gr web 512 Oct 18 03:18 install
drwxrwxr-x 15 gr web 512 Oct 18 03:18 lib
drwxrwxr-x 34 gr web 512 Oct 18 03:18 locale
-rw-r--r-- 1 gr web 32 Feb 12 13:06 login.txt
-r--rw-r-- 1 gr web 22978 Oct 18 03:16 main.php
drwxrwxr-x 73 gr web 1536 Oct 18 03:18 modules
-rw-rw-r-- 1 gr web 20 Feb 12 12:17 phpinfo.php
drwxrwxr-x 2 gr web 512 Feb 12 13:26 phpsessions
drwxrwxr-x 11 gr web 512 Oct 18 03:18 themes
drwxrwxr-x 6 gr web 512 Oct 18 03:18 upgrade

I'm also sure that's functioning, since I modified session.save_path to use that phpsessions directory there, and sessions are being created (ie, it's not http://gallery.menalto.com/node/83012):

% cat .htaccess
php_value upload_max_filesize 20M
php_value session.save_path /home/gr/public_html/Pictures/gallery2/phpsessions
% ls -l phpsessions
total 22
-rw------- 1 www web 1905 Feb 12 13:36 sess_244de443bdbe4012f5fb0da0cc119942
-rw------- 1 www web 1887 Feb 12 13:06 sess_628a5048209b8971a78f80ee7a639fd7
-rw------- 1 www web 1887 Feb 12 13:05 sess_66a57a15b206aacc1150b79541323c93
-rw------- 1 www web 1887 Feb 12 13:33 sess_7dfad130642183f71ea9a3dee73f06c9
-rw------- 1 www web 1887 Feb 12 13:06 sess_81562198ebd7aaf79daa04d1a4c351dc
-rw------- 1 www web 1887 Feb 12 13:05 sess_824af5a6c98843601c3de02a043a02c2
-rw------- 1 www web 1887 Feb 12 13:26 sess_a87e1db0d3629e320677d3a3a9d6f21f
-rw------- 1 www web 1887 Feb 12 13:05 sess_c098f2b4e485ccfa187e34021300d27b
-rw------- 1 www web 1887 Feb 12 13:07 sess_ce3d612a1e440bdade67776c6c6923ad
-rw------- 1 www web 1905 Feb 12 13:07 sess_dec27f46648e953be90cd07839d72556
-rw------- 1 www web 1887 Feb 12 13:34 sess_ed51437f840268002a4d641d40dcf807

I presume that the authentication key is supposed to be stored in the most recent of these session files, and I do see a string of the right length, but it doesn't match what was on the screen last, what's on the screen at the present time step, nor what was in the provided file either of those times, so I'm not too sure what to make of that.

Following http://codex.gallery2.org/Gallery2:FAQ#What_information_is_required_when_I_ask_for_help_in_the_forums.3F to the best of my abilities:

- Since installation hasn't completed, I can't provide Site Admin -> Maintenance -> System information. Since the FAQ says nothing of what information might be included there, I can't do so by hand. Might want to update that answer in the FAQ!

- The gallery in question is at http://eclipsed.net/~gr/Pictures/gallery2/.

- There is a phpinfo for the environment (as modified by .htaccess) http://eclipsed.net/~gr/Pictures/gallery2/phpinfo.php, and I'm attaching its current state (in case I go tinker with things further, to avoid muddying the waters) to this post (as a text document, given the file attachment limitations here).

- I can't really follow the directions under http://codex.gallery2.org/Gallery2:FAQ#How_can_I_make_sure_that_my_installation_files_are_all_intact.3F. Again, providing a manual method to answer that question in the FAQ might be helpful.

- I don't see any debug output beyond the "Error: your login.txt key does not match correctly. Please download a new authentication string from below and try again." error in this case. It does not appear that there is a config.php created as yet, and it's not clear to me that modifying the argument to $gallery->setDebug() in install/config.php-template will do much. Please let me know if I should make this modification somewhere else (init.inc?).

The stance you describe is pretty distressing, considering that 2.3 is still the shipping version of the software and this forum does exist with the explicit assertion that it is canonical location to look for assistance installing and configuring Gallery2.

That said, your suggestion is a good one. I didn't need to go so far as pulling down the completely vanilla distribution, instead I backed off and tried with the package-installed version of the files, which FreeBSD ports put at /usr/local/www/gallery2, and found that I did not have the same issue.

Next, I made the file ownerships and permissions under /home/gr/public_html/Pictures/gallery2 exactly match those under /usr/local/www/gallery2, and made it past the login.txt looping with the relocated installation.

But since I would really prefer not to use sudo to edit files under this directory by hand, I tried switching ownership back from matching the default install (www:www) to what I had previously (gr:web), but this time instead of simply doing a `chmod -R g+w /home/gr/public_html/Pictures/gallery2`, I did `find /home/gr/public_html/Pictures/gallery2 -perm +u+w -exec chmod g+w {} \;` (and then removed group write permissions from the files under my sessions directory, which I chose to locate under this same directory hierarchy, but is not there by default), which avoided adding write permissions to the various files, especially PHP script and class files, that are, by default, read-only for user, group, and other.

With that last change, I can still get past the login.txt looping in the version of Gallery2 relocated to my home directory. I tend to presume that some portion of AuthenticateStep.class is calling foul based on some important file being writable, although I did also restart Apache httpd once in here (to add a Directory block and Alias for /usr/local/www/gallery2), so it's plausible that I made some other change (configuration or otherwise) to PHP that I've forgotten but that mod_php hadn't picked up. (Should anyone else run into the same issue that I have, please feel free to contact me privately if what I describe doing doesn't fix things for you.)