Hide Forgot
Description of problem: After the update was installed via yum, e.g.: May 09 06:13:08 Updated: gallery2-quotas.noarch 2.2-0.2.svn20070506.fc5 the formerly-working gallery finds itself redirecting to /install/ Version-Release number of selected component (if applicable): 2.2-0.2.svn20070506.fc5 How reproducible: unknown Steps to Reproduce: 1. have a working gallery 2. allow update of version 2.2-0.2.svn20070506.fc5 Actual results: back to installer Expected results: gallery continues to work Additional info: I don't have a solution yet - I opened this bug in case others are coming in this morning and finding the same problem - maybe somebody else will find the problem first. If not, I'll modify the bug to reflect the root cause.
Can you provide a full listing of all gallery2 packages you have installed? (rpm -qa | grep gallery2)
Created attachment 154410 [details] list of installed gallery2 packages Attaching a list of packages. I haven't yet figured this out - it seems that this symptom can happen if the config.php file is missing - unfortunately, /srv/ wasn't in my backup routine so I'm not sure what it looked like before, but now /srv/gallery2/ looks like: #ls -la /srv/gallery2/ total 16 drwxr-xr-x 2 apache root 4096 May 9 06:14 ./ drwxr-xr-x 4 root root 4096 Mar 14 05:15 ../ -rw-r--r-- 1 root root 33 Dec 3 23:32 login.txt~ - note the modification date on the directory is the same time yum installed the update, so I'm guessing the rpm script at least 'touch'-ed the directory - perhaps deleted something.
Where is your g2data directory located, and is it intact? Your current theory seems to me to be correct - I believe I didn't handle the config.php file properly in the upgrade; RPM should have saved the config.php file since it was marked as a config(noreplace) file but it seems that didn't happen. What appears in your /etc/gallery2 directory currently? If there is a config.php in there, can you attach it? I'm attempting to reproduce this by setting up a working Gallery2 installation using the old package versions, but I'm running into issues since I no longer have an FC5 machine available.
Judging by the date, I'd guess this config.php came from the rpm: #ls -l /etc/gallery2/config.php -rw-r--r-- 1 apache root 170 May 7 11:34 /etc/gallery2/config.php Not certain what was there previously, but it would have been whatever was there from the prior package. #cat /etc/gallery2/config.php <?php /* This file intentionally empty - it is populated during Gallery's setup / configuration process*/ $gallery->setConfig('data.gallery.base', '/srv/gallery2/'); ?> I *think* there was a /srv/gallery2/config.php but I'd only bet small dollars on that. g2data is at /var/lib/gallery2/g2data/ and appears to be untouched by the update (by mtime, anyhow). I could probably setup an fc5 vm for you if it'd help.
Oops - forgot to paste this in: #ls -la /etc/gallery2/ total 24 drwxr-xr-x 2 root root 4096 May 9 06:14 ./ drwxr-xr-x 110 root root 12288 May 9 11:23 ../ -rw-r--r-- 1 apache root 170 May 7 11:34 config.php -rw-r--r-- 1 root root 0 May 7 11:34 login.txt
*** Bug 239619 has been marked as a duplicate of this bug. ***
My data directory on /media/Drive 4/gallery was untouched by the update (FC6). However my /etc/gallery2/config.php was wiped by the update. At minimum it should have been moved to config.php.rpmsave. rpm updates can't wipe user configurations! ( I was the creator of bug 239619 on FC6 )
The config file issue is one of the items I'm addressing. Removing config.php was a result of not checking my specfile carefully enough. As soon as I've figured out a recovery procedure, or as close to one as I can, I'll post it here.
OK, I'm about to release new packages. To recover from the failed upgrades will require a bit more work than just updating to the new packages, unfortunately - my apologies for that. First, you'll need to revert to the 2.1 packages. I've made these available at the following URLs for convenience: FC-5: http://www.ncphotography.com/g2dist/FC5/ FC-6: http://www.ncphotography.com/g2dist/FC6/ Please note this is not an official Fedora repository, I've simply made the gallery2 2.1 packages available here for convenience. These are exact copies of the 2.1 packages available on the download.fedora.redhat.com server. You'll need to go through the initial setup procedure, being sure to specify the same data store and database information, and the installer will realize you already have valid data and ask if you want to re-use the existing information. Say yes here. You should then have your original gallery back up and running. With the new packages I'm about to push, the upgrade should work much better - the config.php will be saved and you will be prompted to copy it to /etc/gallery2, then change a symlink in /usr/share/gallery2. I've tested this on a local machine starting from a fresh gallery2-*2.1* install and it worked as expected. You should also be prompted to step through the upgrade procedure at http://<hostname>/gallery2/upgrade, which I've also run through, and which resulted in a functional, upgraded gallery for me. Most of the Fedora Release Engineering team is at the Summit this week, so I can't guarantee when the newly built packages will be pushed to live repo's, but I have initiated the builds for them. Look for the 0.3.svn20070506 packages.
I'm not sure anybody more sane than me could call this a 'recovery procedure' but what I've done is to run 'strings' on the block device the file was on, redirected to a file on another block device, and then used 'less' to search for gallery->setConfig to find the config.php contents. ext3 seems to be abysmal for 'undelete' types of operations. This works - unfortunately 'strings' kills whitespace and /* and */ lines, so some comment reconstructing was necessary. After I recovered my config.php file, I was greeted with the Gallery 2.2 Upgrader. It completed successfully and we're back in business. There was one warning during the upgrade, and I'm not sure if it's important or not: Gallery File Integrity [something about modified files] lib/tools/bin/extractClassXml.pl lib/tools/bin/getIllegalFunctions.pl lib/tools/bin/makeManifest.pl lib/tools/uml/make-java-classes.pl Even if the config.php problem hadn't happened, it's worth noting that gallery installs all over the place would have effectively been offline waiting for admins to enter the password and click, click, click. I understand why that is, and wouldn't want to risk excluding gallery2 from yum, as I'm keen on getting security updates, but I can wish for a world with backported security patches, right? :) John, don't feel too bad, this happens on many packages, more often than I care to admit to clients. It would be nice if there was a lint for SPEC files that would throw warnings on easy-to-make mistakes like this, and maybe the build process could throw on them. If you can, pester the release folks to get this out now - it's going to save alot of people headaches, especially knuckleheads like me without properly functioning backups.
I'm talking with some of the release folks now. This wasn't so much a security fix, though, as correcting some egregiously nasty hacks I put in place to handle a read-only /usr. Even had I not updates to 2.2, the same issue would have cropped up when I shifted config.php into it's new home-away-from-home. Basically, I left out a %config(noreplace) on the new symlink, not thinking about what would happen there. The file integrity messages are something I need to take up with upstream - they can be ignored as far as I'm aware, I believe they're due to changing permission bits after generating the manifest in the build process. I just haven't had the bandwidth to check up on that when I've been thinking of it lately.
Just for completeness's sake, where is the proper location for config.php at this point? Thanks for appreciating the need for a read-only /usr on some installs, and especially for maintaining gallery2 in Extras so we can have it package-managed and updated.
For the 2.1 packages, it's /usr/share/gallery2/. For 2.2, /etc/gallery2/ with a symlink to it in /usr/share/gallery2/.
OK, looks like the new packages have made it out to the repos. I'm going to set this bug NEEDINFO - feel free to bounce it back to me if you encounter problems, or close it if your happy.
Maybe related to this bug (maybe not), the lastest FC6 gallery2 update show a postinstall failed script error. Updating : gallery2 ######################### [3/6] /var/tmp/rpm-tmp.13379: line 3: syntax error near unexpected token `(' /var/tmp/rpm-tmp.13379: line 3: ` echo Your old configuration file (config.php) has not been replaced.' error: %post(gallery2-2.2-0.3.svn20070506.fc6.noarch) scriptlet failed, exit status 2 I have not the time right now to dig this pb further.
Fortunately, the post scriptlet consists entirely of echo statements, and does not actually do any work. I've corrceted the syntax and new packages are building now.
I was able to update an existing gallery2 install with the first set of new packages (my mirror apparently didn't have the latest), but I think there's still one bug - or I'm misunderstanding. I had a config.php in /usr/share/gallery2. The update made a symlink for: config.php.rpmnew -> ../../../etc/gallery2/config.php but left my config.php there. I expected it would move it to /etc/gallery2/ and then symlink it. I did that by hand, and the prompt for upgrade came up fine.
That's intended behavior. I couldn't come up with a reliable way to only move the config file if you're upgrading from the 2.1 package to the 2.2 versus from 2.2 to a later 2.2.