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 <[email protected]> >> 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 <[email protected]> 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 >> > [email protected] >> > 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 >> [email protected] >> 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 > [email protected] > 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 [email protected] 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/
