<html>
<body>
Good morning all,<br><br>
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 ...<br><br>
Best - Paul<br><br>
At 06:41 PM 4/30/2013 -0400, Ian Walls wrote:<br>
<blockquote type=cite class=cite cite>Paul,<br><br>
<br>
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?<br><br>
Chris, Jared and Mason are right; the code simply cannot upgrade the
database without running
installer/data/mysql/<a href="http://updatedatabase.pl">updatedatabase.pl</a>,
which is not invoked in
misc/cronjobs/<a href="http://cleanup_database.pl">cleanup_database.pl</a>.Â
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?<br><br>
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.<br><br>
Cheers,<br><br>
<br>
-Ian<br><br>
<br>
On Tue, Apr 30, 2013 at 6:20 PM, Chris Cormack
<<a href="mailto:chris@bigballofwax.co.nz">chris@bigballofwax.co.nz</a>>
wrote:<br>
<dl>
<dd>There is no way, no way at all that running
<a href="http://cleanup_database.pl">cleanup_database.pl</a> did<br>
<dd>the upgrade. It didn't.<br>
<dd>The only way you would get the webpage telling you your db
needed<br>
<dd>updating is because the code is different to the db.<br>
<dd>This means your Koha was pointing to the 3.8.10 code. Not the 3.8.5
one.<br><br>
<dd>This can only happen if you untarred the code over top of your
3.8.5,<br>
<dd>or ran make upgrade, or edited your koha-conf.xml and apache config
to<br>
<dd>point at the new code.<br><br>
<dd>None of this was caused by you running
<a href="http://cleanup_database.pl">cleanup_database.pl</a>, That is
a<br>
<dd>red herring.<br><br>
<dd>So by you logging into the web installer and telling it to update
your<br>
<dd>db, you updated your db, you untarring the 3.8.10 and somehow<br>
<dd>switching your koha site to use that (one of the ways above) you
were<br>
<dd>running 3.8.10 which triggered the screen telling you you needed
to<br>
<dd>upgrade your db to match.<br><br>
<dd>None of this was automatic and I repeat none of this was caused
by<br>
<dd><a href="http://cleanup_database.pl">cleanup_database.pl</a>.<br><br>
<dd>This will also be my last message on this subject, but I can not
leave<br>
<dd>the thread with the assertion that somehow running
<a href="http://cleanup_database.pl">cleanup_database.pl</a><br>
<dd>downloaded a tarball, untarred it, ran make upgrade, and then
logged<br>
<dd>into your koha installer page with the db user and clicked
update<br>
<dd>database. It didn't.<br><br>
<dd>If you really didn't do it yourself, then yes, the only other<br>
<dd>conclusion is you were/are hacked by someone who likes to upgrade
Koha<br>
<font color="#888888"><br>
<dd>Chris<br>
</font><br>
<dd>On 1 May 2013 10:10, Paul
<<a href="mailto:paul.a@aandc.org">paul.a@aandc.org</a>>
wrote:<br>
<dd>> At 06:44 AM 5/1/2013 +1200, Mason James wrote:<br>
<dd>> [snip]<br>
<dd>><br>
<dd>>> lol, no Paul - i do not 'misunderstand' anything here<br>
<dd>><br>
<dd>><br>
<dd>> I'm not laughing, I'm "a little worried."<br>
<dd>><br>
<dd>><br>
<dd>>> hmmm, your 'automatic upgrade' was caused by...<br>
<dd>>><br>
<dd>>> Â - you manually pointing your 3.8.5 Koha to a 3.8.10
codebase, (then<br>
<dd>>> forgetting you did that)<br>
<dd>><br>
<dd>><br>
<dd>> No. (and despite my advancing years, not only is my memory way
above<br>
<dd>> average, but I keep notes of everything I do. On this particular
box, I did<br>
<dd>> a wget for the tarball to /home/paul/, tar xvfz'ed to
/home/paul/, and cp'ed<br>
<dd>> the .gz to / with the unfulfilled intention of upgrading, all on
23 Feb this<br>
<dd>> year.)<br>
<dd>><br>
<dd>><br>
<dd>>> Â - you manually logging-in as the Koha database user
at the<br>
<dd>>> install/upgrade page<br>
<dd>><br>
<dd>><br>
<dd>> No. I was logged in as user=koha to run
'./<a href="http://cleanup_database.pl">cleanup_database.pl</a>
--zebraqueue<br>
<dd>> -v', *not* at any "install" page.<br>
<dd>><br>
<dd>><br>
<dd>>> Â - you manually clicking 'upgrade'<br>
<dd>><br>
<dd>><br>
<dd>> No. Or rather, upgrade what?<br>
<dd>><br>
<dd>> For an upgrade 3.8.5 ==> 3.8.10, categorically
"No."<br>
<dd>><br>
<dd>> After running
'./<a href="http://cleanup_database.pl">cleanup_database.pl</a>
--zebraqueue -v', neither the OPAC nor<br>
<dd>> the staff/8080 interface was available. My only way forward was
a<br>
<dd>> "staff/8080" login as user=koha and agree to "Web
installer › Step 3: update<br>
<dd>> your database" -- note *database*, nothing about
version.<br>
<dd>><br>
<dd>>> Did i miss anything??<br>
<dd>><br>
<dd>><br>
<dd>> Yes. Using '-v' with
<a href="http://cleanup_database.pl">cleanup_database.pl</a> was not
verbose. It was totally<br>
<dd>> silent on version upgrade, only advised:<br>
<dd>><br>
<dd>> koha@hardy:/usr/share/koha/bin/cronjobs$
./<a href="http://cleanup_database.pl">cleanup_database.pl</a>
--zebraqueue<br>
<dd>> -v<br>
<dd>> Zebraqueue purge triggered for 30 days.<br>
<dd>><br>
<dd>> 131575 records were deleted.<br>
<dd>> Done with zebraqueue purge.<br>
<dd>><br>
<dd>> Yes. I was operating as user=koha to run
<a href="http://cleanup_database.pl">cleanup_database.pl</a>. The fact
is<br>
<dd>> that the Koha version went from 3.8.5 to 3.8.10 without my
permission.<br>
<dd>><br>
<dd>> Yes. user=koha has the permissions to upgrade versions, but why
does<br>
<dd>> <a href="http://cleanup_database.pl">cleanup_database.pl</a>
(specifically the '--zebraqueue -v' option) upgrade<br>
<dd>> versions at the same time?<br>
<dd>><br>
<dd>> I truly appreciate your reply. But your suggestion that I "manually" did one<br>
<dd>> of the three points you raised is untrue. Did the version upgrade happen?<br>
<dd>> Yes. Did user=koka have the rights? Yes. Was I given any warning? No. Is<br>
<dd>> there any reason why <a href="http://cleanup_database.pl">cleanup_database.pl</a> should have anything to do with<br>
<dd>> upgrading versions? That is my question. It did it. It's reproducible on my<br>
<dd>> sandbox (and I'd be interested if others can confirm/deny.)<br>
<dd>><br>
<dd>> Best -- Paul<br>
<dd>><br>
<dd>><br>
<dd>> ---<br>
<dd>> Maritime heritage and history, preservation and conservation,<br>
<dd>> research and education through the written word and the arts.<br>
<dd>> <<a href="http://NavalMarineArchive.com">http://NavalMarineArchive.com</a>> and <<a href="http://UltraMarine.ca">http://UltraMarine.ca</a>><br>
<dd>><br>
<dd>> _______________________________________________<br>
<dd>> Koha-devel mailing list<br>
<dd>> <a href="mailto:Koha-devel@lists.koha-community.org">Koha-devel@lists.koha-community.org</a><br>
<dd>> <a href="http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel" eudora="autourl">http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel</a><br>
<dd>> website : <a href="http://www.koha-community.org/">http://www.koha-community.org/</a><br>
<dd>> git : <a href="http://git.koha-community.org/">http://git.koha-community.org/</a><br>
<dd>> bugs : <a href="http://bugs.koha-community.org/">http://bugs.koha-community.org/</a><br>
<dd>_______________________________________________<br>
<dd>Koha-devel mailing list<br>
<dd><a href="mailto:Koha-devel@lists.koha-community.org">Koha-devel@lists.koha-community.org</a><br>
<dd><a href="http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel" eudora="autourl">http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel</a><br>
<dd>website : <a href="http://www.koha-community.org/">http://www.koha-community.org/</a><br>
<dd>git : <a href="http://git.koha-community.org/">http://git.koha-community.org/</a><br>
<dd>bugs : <a href="http://bugs.koha-community.org/">http://bugs.koha-community.org/</a><br>
<br>
</dl></blockquote>
<x-sigsep><p></x-sigsep>
---<br>
Maritime heritage and history, preservation and conservation, <br>
research and education through the written word and the arts.<br>
<<a href="http://navalmarinearchive.com/" eudora="autourl">http://NavalMarineArchive.com</a>> and <<a href="http://ultramarine.ca/" eudora="autourl">http://UltraMarine.ca</a>><br>
</body>
</html>