Re: [Koha-devel] Major surprise - "automatic" upgrade
Good morning all, Many thanks. I've got a major exhibition opening Saturday (and our annual dinner) but will get back to this early next week. Not sure what you mean by "screencast" so will assume that the complete CLI readout will be OK ... Best - Paul At 06:41 PM 4/30/2013 -0400, Ian Walls wrote:
Paul,
You mentioned earlier in this thread that you could reproduce this issue now that you've restored. Would it be possible for you to create a screencast of what steps you're taking and what your output is for each of those steps? When you're performing the commandline operations, what directory are you in? What are you KOHA_CONF and PERL5LIB variables? Is your KOHA_CONF appropriate for the paths of your current version of the software, and does it point to the right iteration of your database?
Chris, Jared and Mason are right; the code simply cannot upgrade the database without running installer/data/mysql/<http://updatedatabase.pl>updatedatabase.pl, which is not invoked in misc/cronjobs/<http://cleanup_database.pl>cleanup_database.pl. The prototypical way to do this update is through the web installer; if the system detects that your codebase version is greater than your database version, it will take you to the update page in the staff client. You then login with the username/password that MySQL has for your koha database, and the updates are performed. It's also possible to run this manually on the commandline; is there any chance you have any configured triggers in place to invoke this command?
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.
Cheers,
-Ian
On Tue, Apr 30, 2013 at 6:20 PM, Chris Cormack <<mailto:chris@bigballofwax.co.nz>chris@bigballofwax.co.nz> wrote: There is no way, no way at all that running <http://cleanup_database.pl>cleanup_database.pl did the upgrade. It didn't. The only way you would get the webpage telling you your db needed updating is because the code is different to the db. This means your Koha was pointing to the 3.8.10 code. Not the 3.8.5 one.
This can only happen if you untarred the code over top of your 3.8.5, or ran make upgrade, or edited your koha-conf.xml and apache config to point at the new code.
None of this was caused by you running <http://cleanup_database.pl>cleanup_database.pl, That is a red herring.
So by you logging into the web installer and telling it to update your db, you updated your db, you untarring the 3.8.10 and somehow switching your koha site to use that (one of the ways above) you were running 3.8.10 which triggered the screen telling you you needed to upgrade your db to match.
None of this was automatic and I repeat none of this was caused by <http://cleanup_database.pl>cleanup_database.pl.
This will also be my last message on this subject, but I can not leave the thread with the assertion that somehow running <http://cleanup_database.pl>cleanup_database.pl downloaded a tarball, untarred it, ran make upgrade, and then logged into your koha installer page with the db user and clicked update database. It didn't.
If you really didn't do it yourself, then yes, the only other conclusion is you were/are hacked by someone who likes to upgrade Koha
Chris
At 06:44 AM 5/1/2013 +1200, Mason James wrote: [snip]
lol, no Paul - i do not 'misunderstand' anything here
I'm not laughing, I'm "a little worried."
hmmm, your 'automatic upgrade' was caused by...
 - you manually pointing your 3.8.5 Koha to a 3.8.10 codebase, (then forgetting you did that)
No. (and despite my advancing years, not only is my memory way above average, but I keep notes of everything I do. On this particular box, I did a wget for the tarball to /home/paul/, tar xvfz'ed to /home/paul/, and cp'ed the .gz to / with the unfulfilled intention of upgrading, all on 23 Feb
On 1 May 2013 10:10, Paul <<mailto:paul.a@aandc.org>paul.a@aandc.org> wrote: this
year.)
 - you manually logging-in as the Koha database user at the install/upgrade page
No. I was logged in as user=koha to run './<http://cleanup_database.pl>cleanup_database.pl --zebraqueue -v', *not* at any "install" page.
 - you manually clicking 'upgrade'
No. Or rather, upgrade what?
For an upgrade 3.8.5 ==> 3.8.10, categorically "No."
After running './<http://cleanup_database.pl>cleanup_database.pl --zebraqueue -v', neither the OPAC nor the staff/8080 interface was available. My only way forward was a "staff/8080" login as user=koha and agree to "Web installer ⺠Step 3: update your database" -- note *database*, nothing about version.
Did i miss anything??
Yes. Using '-v' with <http://cleanup_database.pl>cleanup_database.pl was not verbose. It was totally silent on version upgrade, only advised:
koha@hardy:/usr/share/koha/bin/cronjobs$ ./<http://cleanup_database.pl>cleanup_database.pl --zebraqueue -v Zebraqueue purge triggered for 30 days.
131575 records were deleted. Done with zebraqueue purge.
Yes. I was operating as user=koha to run <http://cleanup_database.pl>cleanup_database.pl. The fact is that the Koha version went from 3.8.5 to 3.8.10 without my permission.
Yes. user=koha has the permissions to upgrade versions, but why does <http://cleanup_database.pl>cleanup_database.pl (specifically the '--zebraqueue -v' option) upgrade versions at the same time?
I truly appreciate your reply. But your suggestion that I "manually" did one of the three points you raised is untrue. Did the version upgrade happen? Yes. Did user=koka have the rights? Yes. Was I given any warning? No. Is there any reason why <http://cleanup_database.pl>cleanup_database.pl should have anything to do with upgrading versions? That is my question. It did it. It's reproducible on my sandbox (and I'd be interested if others can confirm/deny.)
Best -- Paul
--- Maritime heritage and history, preservation and conservation, research and education through the written word and the arts. <<http://NavalMarineArchive.com>http://NavalMarineArchive.com> and <<http://UltraMarine.ca>http://UltraMarine.ca>
_______________________________________________ Koha-devel mailing list
<mailto:Koha-devel@lists.koha-community.org>Koha-devel@lists.koha-community.org
http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : <http://www.koha-community.org/>http://www.koha-community.org/ git : <http://git.koha-community.org/>http://git.koha-community.org/ bugs : <http://bugs.koha-community.org/>http://bugs.koha-community.org/
Koha-devel mailing list <mailto:Koha-devel@lists.koha-community.org>Koha-devel@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : <http://www.koha-community.org/>http://www.koha-community.org/ git : <http://git.koha-community.org/>http://git.koha-community.org/ bugs : <http://bugs.koha-community.org/>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 do 02-05-2013 om 10:24 [-0400]:
Many thanks. I've got a major exhibition opening Saturday (and our annual dinner) but will get back to this early next week. Not sure what you mean by "screencast" so will assume that the complete CLI readout will be OK ...
http://lmgtfy.com/?q=define:screencast There is also the 'script' command. -- Robin Sheat Catalyst IT Ltd. ✆ +64 4 803 2204 GPG: 5957 6D23 8B16 EFAB FEF8 7175 14D3 6485 A99C EB6D
On 2013-05-3, at 2:24 AM, Paul wrote:
Good morning all,
Many thanks. I've got a major exhibition opening Saturday (and our annual dinner) but will get back to this early next week. Not sure what you mean by "screencast" so will assume that the complete CLI readout will be OK ...
Best - Paul
ftw, here's a quick test that proves your bug is impossible... 1/ prove your Koha codebase is 3.8.5 $ grep '3.08.05' ./kohaversion.pl |wc -l 1 2/ run script $ ./misc/cronjobs/cleanup_database.pl --zebraqueue 3/ prove your Koha codebase is 3.8.5 $ grep '3.08.05' ./kohaversion.pl |wc -l 1
At 06:41 PM 4/30/2013 -0400, Ian Walls wrote:
Paul,
You mentioned earlier in this thread that you could reproduce this issue now that you've restored. Would it be possible for you to create a screencast of what steps you're taking and what your output is for each of those steps? When you're performing the commandline operations, what directory are you in? What are you KOHA_CONF and PERL5LIB variables? Is your KOHA_CONF appropriate for the paths of your current version of the software, and does it point to the right iteration of your database?
Chris, Jared and Mason are right; the code simply cannot upgrade the database without running installer/data/mysql/updatedatabase.pl, which is not invoked in misc/cronjobs/cleanup_database.pl. The prototypical way to do this update is through the web installer; if the system detects that your codebase version is greater than your database version, it will take you to the update page in the staff client. You then login with the username/password that MySQL has for your koha database, and the updates are performed. It's also possible to run this manually on the commandline; is there any chance you have any configured triggers in place to invoke this command?
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.
Cheers,
-Ian
On Tue, Apr 30, 2013 at 6:20 PM, Chris Cormack <chris@bigballofwax.co.nz> wrote: There is no way, no way at all that running cleanup_database.pl did the upgrade. It didn't. The only way you would get the webpage telling you your db needed updating is because the code is different to the db. This means your Koha was pointing to the 3.8.10 code. Not the 3.8.5 one.
This can only happen if you untarred the code over top of your 3.8.5, or ran make upgrade, or edited your koha-conf.xml and apache config to point at the new code.
None of this was caused by you running cleanup_database.pl, That is a red herring.
So by you logging into the web installer and telling it to update your db, you updated your db, you untarring the 3.8.10 and somehow switching your koha site to use that (one of the ways above) you were running 3.8.10 which triggered the screen telling you you needed to upgrade your db to match.
None of this was automatic and I repeat none of this was caused by cleanup_database.pl.
This will also be my last message on this subject, but I can not leave the thread with the assertion that somehow running cleanup_database.pl downloaded a tarball, untarred it, ran make upgrade, and then logged into your koha installer page with the db user and clicked update database. It didn't.
If you really didn't do it yourself, then yes, the only other conclusion is you were/are hacked by someone who likes to upgrade Koha
Chris
On 1 May 2013 10:10, Paul <paul.a@aandc.org> wrote:
At 06:44 AM 5/1/2013 +1200, Mason James wrote: [snip]
lol, no Paul - i do not 'misunderstand' anything here
I'm not laughing, I'm "a little worried."
hmmm, your 'automatic upgrade' was caused by...
 - you manually pointing your 3.8.5 Koha to a 3.8.10 codebase, (then forgetting you did that)
No. (and despite my advancing years, not only is my memory way above average, but I keep notes of everything I do. On this particular box, I did a wget for the tarball to /home/paul/, tar xvfz'ed to /home/paul/, and cp'ed the .gz to / with the unfulfilled intention of upgrading, all on 23 Feb this year.)
 - you manually logging-in as the Koha database user at the install/upgrade page
No. I was logged in as user=koha to run './cleanup_database.pl --zebraqueue -v', *not* at any "install" page.
 - you manually clicking 'upgrade'
No. Or rather, upgrade what?
For an upgrade 3.8.5 ==> 3.8.10, categorically "No."
After running './cleanup_database.pl --zebraqueue -v', neither the OPAC nor the staff/8080 interface was available. My only way forward was a "staff/8080" login as user=koha and agree to "Web installer › Step 3: update your database" -- note *database*, nothing about version.
Did i miss anything??
Yes. Using '-v' with cleanup_database.pl was not verbose. It was totally silent on version upgrade, only advised:
koha@hardy:/usr/share/koha/bin/cronjobs$ ./cleanup_database.pl --zebraqueue -v Zebraqueue purge triggered for 30 days.
131575 records were deleted. Done with zebraqueue purge.
Yes. I was operating as user=koha to run cleanup_database.pl. The fact is that the Koha version went from 3.8.5 to 3.8.10 without my permission.
Yes. user=koha has the permissions to upgrade versions, but why does cleanup_database.pl (specifically the '--zebraqueue -v' option) upgrade versions at the same time?
I truly appreciate your reply. But your suggestion that I "manually" did one of the three points you raised is untrue. Did the version upgrade happen? Yes. Did user=koka have the rights? Yes. Was I given any warning? No. Is there any reason why cleanup_database.pl should have anything to do with upgrading versions? That is my question. It did it. It's reproducible on my sandbox (and I'd be interested if others can confirm/deny.)
Best -- Paul
--- Maritime heritage and history, preservation and conservation, research and education through the written word and the arts. <http://NavalMarineArchive.com> and <http://UltraMarine.ca>
_______________________________________________ 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/
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> _______________________________________________ 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/
Mason James
ftw, here's a quick test that proves your bug is impossible...
Hey, be nice! I'm sure we've all had bugs reported that we can't reproduce because of some combination of things on the particular user's system. I don't see how this could be one, but you never know... Equally, be nice when reporting such Heisenbugs... Thanks, -- MJ Ray (slef), member of www.software.coop, a for-more-than-profit co-op. http://koha-community.org supporter, web and library systems developer. In My Opinion Only: see http://mjr.towers.org.uk/email.html Available for hire (including development) at http://www.software.coop/
On 2013-05-4, at 12:48 AM, MJ Ray wrote:
Mason James
ftw, here's a quick test that proves your bug is impossible...
Hey, be nice!
huh?, what is 'not nice' about describing a test, that proves a bug is impossible?
I'm sure we've all had bugs reported that we can't reproduce because of some combination of things on the particular user's system. I don't see how this could be one, but you never know...
Equally, be nice when reporting such Heisenbugs...
Thanks, -- MJ Ray (slef), member of www.software.coop, a for-more-than-profit co-op.
huh?, what is 'not nice' about describing a test, that proves a bug is impossible?
It doesn't "prove" it's impossible. It just shows you're not seeing that bug and suggests a way to confirm/reject the bug elsewhere. Proofs are sort of an interesting concept in programming and are almost never used. This exchange was a bad reminder of the time there was some strange MacOS X perl maths bug which caused a particular added-by-request-of-a-now-gone-koha-developer HTML::Template feature to fail. That developer insisted the bug was impossible, that his new template feature was brilliant and that it should be used on almost every Koha page. He was generally quite scathing about how stupid we were for suggesting such a bug existed, especially in private. It wasn't nice, or necessary. I agree that automatic upgrade bug seems unlikely, but impossible? Nope. Regards, -- MJ Ray (slef), member of www.software.coop, a for-more-than-profit co-op. http://koha-community.org supporter, web and library systems developer. In My Opinion Only: see http://mjr.towers.org.uk/email.html Available for hire (including development) at http://www.software.coop/
participants (4)
-
Mason James -
MJ Ray -
Paul -
Robin Sheat