Bug 239559

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.