Re: [Koha-devel] Major surprise - "automatic" upgrade
At 06:41 PM 4/30/2013 -0400, Ian Walls wrote: [snip]
This is definitely a confusing situation, and I'm sorry it's cause you alarm. Hopefully with more information we can get to the bottom of exactly how it's happening, understand it, and prevent it from happening to you (and anyone else) again.
Thanks to all for your patience, summary of my "reproducible upgrade" is that under some | [perhaps] exceptional conditions 'cleanup_database.pl' does upgrade the Koha version. Under what might be called "normal" conditions, absolutely everything is as expected with no problems. You'll see from the notes below, that having a *koha owned* koha-3.08.10 at / prompts a version upgrade [the *Important Note* below.] There is no "verbosity" using -v with './cleanup_database.pl' Best - Paul Update 6 May: Logged in as user=koha, no tarred|untarred Koha installation files on this box koha@hardy:/$ cat /usr/share/koha/misc/koha-install-log | grep KOHA_INSTALLED_VERSION KOHA_INSTALLED_VERSION=3.08.05.000 koha@hardy:/usr/share/koha/bin/cronjobs$ ./cleanup_database.pl --zebraqueue 1 -v Zebraqueue purge triggered for 1 days. 19847 records were deleted. Done with zebraqueue purge. cat /usr/share/koha/misc/koha-install-log | grep KOHA_INSTALLED_VERSION KOHA_INSTALLED_VERSION=3.08.05.000 So far, so good; OPAC and staff-admin both functional. To reproduce upgrade, restore db; sftp [...] koha-3.08.05.tar.gz and koha-3.08.10.tar.gz /home/paul; "untar" koha-3.08.10.tar.gz in /home/paul/; cp koha-3.08.10.tar.gz to / koha@hardy:/$ ls -l /home/paul /.../ -rwxrw-r-- 1 paul paul 48446365 Sep 22 2012 koha-3.08.05.tar.gz -rwxrw-r-- 1 paul paul 50084604 Mar 2 19:34 koha-3.08.10.tar.gz drwxrwxr-x 42 paul paul 4096 Feb 23 05:09 koha-3.08.10 koha@hardy:/$ ls -l / / ... / -rw-r--r-- 1 koha koha 50084604 May 6 18:26 koha-3.08.10.tar.gz drwxrwxr-x 42 koha koha 4096 Feb 23 05:09 koha-3.08.10 [Important Note: if chown is either "me" or root, the following version upgrade does not happen.] koha@hardy:/usr/share/koha/bin/cronjobs$ ./cleanup_database.pl --zebraqueue 1 -v Zebraqueue purge triggered for 1 days. 19847 records were deleted. Done with zebraqueue purge. cat /usr/share/koha/misc/koha-install-log | grep KOHA_INSTALLED_VERSION KOHA_INSTALLED_VERSION=3.08.10.000 ... and OPAC announces under "maintenance". Trying to staff-admin: Web installer Step 3 We are upgrading from Koha 3.08.05.000 to 3.08.10.000, you must update your database Web installer Step 3 Updating database structure Update report : Upgrade to 3.08.06.000 (3.8.6 release) done Upgrade to 3.08.07.000 (3.8.7 release) done Upgrade to 3.08.08.000 (3.8.8 release) done Upgrade to 3.08.09.000 (3.8.9 release) done Upgrade to 3.08.10.000 (3.8.9 release) done Everything went OK, update done. Continue to log in to Koha _______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/ --- Maritime heritage and history, preservation and conservation, research and education through the written word and the arts. <http://NavalMarineArchive.com> and <http://UltraMarine.ca>
Paul schreef op ma 06-05-2013 om 20:02 [-0400]:
koha@hardy:/usr/share/koha/bin/cronjobs$ ./cleanup_database.pl --zebraqueue 1 -v Zebraqueue purge triggered for 1 days. 19847 records were deleted. Done with zebraqueue purge. ... koha@hardy:/usr/share/koha/bin/cronjobs$ ./cleanup_database.pl --zebraqueue 1 -v Zebraqueue purge triggered for 1 days. 19847 records were deleted. Done with zebraqueue purge.
So, it deletes the same records twice? That seems a bit fishy.
cat /usr/share/koha/misc/koha-install-log | grep KOHA_INSTALLED_VERSION KOHA_INSTALLED_VERSION=3.08.10.000
This isn't the best way to see what version you have. Also, there are only two places in Koha that reference this file: the Makefile and koha-conf.xml (and nothing refers to the key that is in it, except (I think) for the Makefile.) The best way to check is to look in kohaversion.pl, which is in the root of your koha installation. That tells you about the exact version of the code that is running. Use: locate kohaversion.pl (if you get an error about mlocate or missing files or something, run 'sudo updatedb' first.) to find it. I suspect you may have more than one, make sure you check that you are using the same one as both the apache configuration, the location of the cleanup_database.pl you run, and the paths reflected in the koha-conf.xml that you are using, which will be revealed by either: echo $KOHA_CONF or you'll find it in /etc/koha/koha-conf.xml. Be totally sure you're looking at the right one. In a nutshell, the only way this could possibly happen, afaict, is if something is finding the untarred archive in '/' and running 'make' in there. This doesn't seem like a thing that anything in Koha would do. In a quick test, I couldn't make it happen. -- Robin Sheat Catalyst IT Ltd. ✆ +64 4 803 2204 GPG: 5957 6D23 8B16 EFAB FEF8 7175 14D3 6485 A99C EB6D
Robin Sheat schreef op di 07-05-2013 om 17:13 [+1200]:
So, it deletes the same records twice? That seems a bit fishy.
Oh, I overlooked where you said you restored the DB. Ignore this bit. One important thing is that you never look at the version the very moment _before_ you run cleanup_database.pl so we really have no reference to come from. -- Robin Sheat Catalyst IT Ltd. ✆ +64 4 803 2204 GPG: 5957 6D23 8B16 EFAB FEF8 7175 14D3 6485 A99C EB6D
* Robin Sheat (robin@catalyst.net.nz) wrote:
Robin Sheat schreef op di 07-05-2013 om 17:13 [+1200]:
So, it deletes the same records twice? That seems a bit fishy.
Oh, I overlooked where you said you restored the DB. Ignore this bit.
One important thing is that you never look at the version the very moment _before_ you run cleanup_database.pl so we really have no reference to come from.
Also we can see it hasn't updated the database, because it would not be in maintenance mode if it had. That is not updated until you log into the webinstaller and upgrade the db. All that has happened is you have the koha-conf.xml and the the apache2 config pointing to your 3.8.10 code. Like I previously said this can only happen if you untarred over top of your old directory or you run make upgrade. So there is a lot more diagnostics we need to see exactly what you have done. Including seeing which koha-conf.xml you have set before you run the cleanup script and what directory that file points to. Chris -- Chris Cormack Catalyst IT Ltd. +64 4 803 2238 PO Box 11-053, Manners St, Wellington 6142, New Zealand
At 05:40 PM 5/7/2013 +1200, Chris Cormack wrote:
* Robin Sheat (robin@catalyst.net.nz) wrote:
Robin Sheat schreef op di 07-05-2013 om 17:13 [+1200]:
So, it deletes the same records twice? That seems a bit fishy.
Oh, I overlooked where you said you restored the DB. Ignore this bit.
One important thing is that you never look at the version the very moment _before_ you run cleanup_database.pl so we really have no reference to come from.
Also we can see it hasn't updated the database, because it would not be in maintenance mode if it had. That is not updated until you log into the webinstaller and upgrade the db.
Thanks Chris - agreed (although there is apparently no MySQL differences between 3.8.5 and 3.8.10 - despite the browser running through five steps before either admin or OPAC are functional.)
All that has happened is you have the koha-conf.xml and the the apache2 config pointing to your 3.8.10 code.
Again agreed -- but the 3.8.10 code is in exactly the same place as the 3.8.5, so no difference in the "pointers."
Like I previously said this can only happen if you untarred over top of your old directory or you run make upgrade.
/koha-3.08.05 had been moved to backup. /koha-3.08.10 was there. But the bigger problem is that I did not *knowingly* upgrade, AND I ran cleanup_database.pl as user=koha who is not a sudoer (required for make, make upgrade.) Certainly no password was requested.
So there is a lot more diagnostics we need to see exactly what you have done. Including seeing which koha-conf.xml you have set before you run the cleanup script and what directory that file points to.
paul@hardy:/$ diff -s /etc/koha/koha-conf.xml /home/paul/koha-conf.xml_3.8.5 Files /etc/koha/koha-conf.xml and /home/paul/koha-conf.xml_3.8.5 are identical Relevant part (consistent with apache, no changes over v. 5 ==> 10): <!-- ADDITIONAL KOHA CONFIGURATION DIRECTIVE --> <!-- db_scheme should follow the DBD driver name --> <!-- port info: mysql:3306 Pg:5432 (5433 on Debian) --> <config> <db_scheme>mysql</db_scheme> <database>koha384</database> <hostname>localhost</hostname> <port>3306</port> <user>koha</user> <pass>************</pass> <biblioserver>biblios</biblioserver> <biblioservershadow>1</biblioservershadow> <authorityserver>authorities</authorityserver> <authorityservershadow>1</authorityservershadow> <intranetdir>/usr/share/koha/intranet/cgi-bin</intranetdir> <opacdir>/usr/share/koha/opac/cgi-bin/opac</opacdir> <opachtdocs>/usr/share/koha/opac/htdocs/opac-tmpl</opachtdocs> <intrahtdocs>/usr/share/koha/intranet/htdocs/intranet-tmpl</intrahtdocs> <includes>/usr/share/koha/intranet/htdocs/intranet-tmpl/prog/en/includes/</includes> <logdir>/var/log/koha</logdir> <pazpar2url>http://hardy:11002/search.pz2</pazpar2url> <install_log>/usr/share/koha/misc/koha-install-log</install_log> <useldapserver>0</useldapserver><!-- see C4::Auth_with_ldap for extra configs you must add if you want to turn this on --> <zebra_bib_index_mode>dom</zebra_bib_index_mode> <zebra_auth_index_mode>dom</zebra_auth_index_mode> </config> </yazgfs> Best - Paul
At 05:18 PM 5/7/2013 +1200, Robin Sheat wrote:
Robin Sheat schreef op di 07-05-2013 om 17:13 [+1200]:
So, it deletes the same records twice? That seems a bit fishy.
Oh, I overlooked where you said you restored the DB. Ignore this bit.
One important thing is that you never look at the version the very moment _before_ you run cleanup_database.pl so we really have no reference to come from.
Robin, Again thanks, and again just so as to not leave this archive incomplete. The version (admittedly from the install-log) was done immediately before cleanup_database. The first part of my email was clear (these are successive cli lines) -- maybe I was less clear for the second "cleanup" in my email, but from my notes it was identical. Sorry for the confusion. koha@hardy:/$ cat /usr/share/koha/misc/koha-install-log | grep KOHA_INSTALLED_VERSION KOHA_INSTALLED_VERSION=3.08.05.000 koha@hardy:/usr/share/koha/bin/cronjobs$ ./cleanup_database.pl --zebraqueue 1 -v Zebraqueue purge triggered for 1 days. 19847 records were deleted. Done with zebraqueue purge. Best - Paul
Robin, many thanks. Just for the "completeness" of the archives, a few comments|answers below: At 05:13 PM 5/7/2013 +1200, Robin Sheat wrote: [snip]
cat /usr/share/koha/misc/koha-install-log | grep KOHA_INSTALLED_VERSION KOHA_INSTALLED_VERSION=3.08.10.000
This isn't the best way to see what version you have. Also, there are only two places in Koha that reference this file: the Makefile and koha-conf.xml (and nothing refers to the key that is in it, except (I think) for the Makefile.)
Agreed - and neither seem to mention version at all, relying purely on the log (which is why, perhaps over-simplistically, I cat'ed the log.
The best way to check is to look in kohaversion.pl, which is in the root of your koha installation. That tells you about the exact version of the code that is running.
sub kohaversion { our $VERSION = '3.08.10.000'; # version needs to be set this way /.../ instead of previous: sub kohaversion { our $VERSION = '3.08.05.000'; # version needs to be set this way /.../
[snip] I suspect you may have more than one,
No - it gets overwritten (new file dated as per the tarball.)
make sure you check that you are using the same one as both the apache configuration, the location of the cleanup_database.pl you run, and the paths reflected in the koha-conf.xml that you are using, [snip]
Yup - all is consistent
In a nutshell, the only way this could possibly happen, afaict, is if something is finding the untarred archive in '/' and running 'make' in there.
That's exactly the problem ..., but further it would have had to run 'Makefile.PL --prev-install-log /path/to/koha-install-log'
This doesn't seem like a thing that anything in Koha would do. In a quick test, I couldn't make it happen.
And I had never seen it before ... Again, thanks and best regards, Paul
On 8 May 2013 02:51, Paul <paul.a@aandc.org> wrote:
Robin, many thanks. Just for the "completeness" of the archives, a few comments|answers below:
At 05:13 PM 5/7/2013 +1200, Robin Sheat wrote: [snip]
cat /usr/share/koha/misc/koha-install-log | grep KOHA_INSTALLED_VERSION KOHA_INSTALLED_VERSION=3.08.10.000
This isn't the best way to see what version you have. Also, there are only two places in Koha that reference this file: the Makefile and koha-conf.xml (and nothing refers to the key that is in it, except (I think) for the Makefile.)
Agreed - and neither seem to mention version at all, relying purely on the log (which is why, perhaps over-simplistically, I cat'ed the log.
The best way to check is to look in kohaversion.pl, which is in the root of your koha installation. That tells you about the exact version of the code that is running.
sub kohaversion { our $VERSION = '3.08.10.000'; # version needs to be set this way /.../ instead of previous: sub kohaversion { our $VERSION = '3.08.05.000'; # version needs to be set this way /.../
[snip] I suspect you may have more than one,
No - it gets overwritten (new file dated as per the tarball.)
That's exactly the problem ..., but further it would have had to run 'Makefile.PL --prev-install-log /path/to/koha-install-log'
No, as you wrote above, you replaced your 3.8.5 code with 3.8.10. Then you ran the webinstaller to upgrade the database. All of this has absolutely nothing to do with the clean up script, its all to do with you replacing the 3.8.5 code with 3.8.10, ie upgrading it. The make upgrade would do that copy, but you did it yourself.
This doesn't seem like a thing that anything in Koha would do. In a quick test, I couldn't make it happen.
And I had never seen it before ...
And you never will again, unless you go around replacing a version of the code with a newer version of the code. Chris
To reproduce upgrade, restore db; sftp [...] koha-3.08.05.tar.gz and koha-3.08.10.tar.gz /home/paul; "untar" koha-3.08.10.tar.gz in /home/paul/; cp koha-3.08.10.tar.gz to /
Hey: untar 3.8.10 and copy 3.8.10 to root ??
koha@hardy:/$ ls -l / drwxrwxr-x 42 koha koha 4096 Feb 23 05:09 koha-3.08.10
Paul: If I read well what you are doing here, you are restoring your database to 3.8.5 and your code to 3.8.10 !! The 3.8.10 script cleanup_database does not complain about that; it does not really care about the exact version. It gets a db handle. It runs. But if you go to OPAC or staff, of course Koha will complain. The newer code sees the older database.. Mystery solved? Marcel
participants (6)
-
Archives and Collections Society -
Chris Cormack -
Chris Cormack -
Marcel de Rooy -
Paul -
Robin Sheat