[Koha-devel] Cataloguing authorities 3.6/3.8
Paul
paul at aandc.org
Sat Sep 29 23:54:04 CEST 2012
Hi Tomas,
Follow up: just finished brand new install 12.04.1 LTS plus Koha 3.8.4
(restore of the production sql dump) on the sandbox, absolutely identical
to the production server, except Koha is "out-of-the box" with no
customization at all. The "Current problems" (see below for the production
server) are identical, EXCEPT:
Records exported: 17765
====================
REINDEXING zebra
====================
17:31:07-29/09 zebraidx(2632) [warn] Missing attribute 'type' in attribute info
17:31:07-29/09 zebraidx(2632) [warn] Unknown register type:
17:32:00-29/09 zebraidx(2632) [warn] isamb: Inconsistent register (2)
zebraidx: isamb.c:1102: insert_leaf: Assertion `*lookahead_mode' failed.
17:32:00-29/09 zebraidx(2637) [warn] previous transaction didn't reach commit
====================
CLEANING
====================
Note -- same number of biblios found, but zebra can no longer find
biblionumbers above 17765, whereas the production server CAN find [OPAC and
staff client] 'biblionumber:18099' so it's the three new 'warns' (the other
two are consistent with the production server):
17:32:00-29/09 zebraidx(2632) [warn] isamb: Inconsistent register (2)
zebraidx: isamb.c:1102: insert_leaf: Assertion `*lookahead_mode' failed.
17:32:00-29/09 zebraidx(2637) [warn] previous transaction didn't reach commit
that are "novel."
Any suggestions, thoughts?
Many thanks - Paul
At 06:19 PM 9/26/2012 -0300, Tomas Cohen Arazi wrote:
>Paul, count on me To solve those issues in time.
>How do you deploy Koha on your server?
>Regards
>To+
[snip]
Tomas -- many, many thanks (I'm just back from 2 days conferencing); we
have as a precautionary measure stopped our cataloguers from using Koha.
I use tarballs (specifically koha-3.08.04.tar.gz, 48,836,564 bytes, dated
21 August 2012) on Ubuntu 12.04.01 LTS installed from ISO, update, upgrade,
clean, mysql, apache2, etc. Koha dependencies using apt-get only (no
cspan), make test (no errors), make install, restore the db (from Koha
3.6.1), wait for the staff-client to do its magic and get from 'About Koha'
in production:
Koha version: 3.08.04.000
OS version ('uname -a'): Linux nelson 3.2.0-31-generic #50-Ubuntu SMP Sun
Sep 16 03:16:45 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux
Perl interpreter: /usr/bin/perl
Perl version: 5.014002
Perl @INC: /usr/share/koha/lib
/etc/perl
/usr/local/lib/perl/5.14.2
/usr/local/share/perl/5.14.2
/usr/lib/perl5
/usr/share/perl5
/usr/lib/perl/5.14
/usr/share/perl/5.14
/usr/local/lib/site_perl
.
MySQL version: mysql Ver 14.14 Distrib 5.5.24, for debian-linux-gnu
(x86_64) using readline 6.2
Apache version: Server version: Apache/2.2.22 (Ubuntu)
Zebra version: Zebra 2.0.44 (C) 1994-2010, Index Data ApS Zebra is free
software, covered by the GNU General Public License, and you are welcome to
change it and/or distribute copies of it under certain conditions. SHA1 ID:
419ad759807269fdfa379799a051ed3a551c6541 Using ICU
Customization (probably irrelevant) limited to CSS, images and one template
(search tab order) and perl mods to barcodes and control numbers (proven on
3.6.1, fully functional on 3.8.4, designed for serial continuity with other
of our internal systems -- if you want the details, I can supply, but
nothing touches the logic flow of Koha.)
Current problems:
a) "Authority" searches (all variations including "author", "subject", with
far reaching implications) is not functional. I believe that this is a
known bug (8071) which refers to 4 files. I have tried on our sandbox a
straight replacement of these four with no changes, and am currently
totally rebuilding it from scratch for further testing.
b) Re-indexing (zebra incremental) has become weird/problematic: the cron
runs, but does nothing for NEW records; it does update MODIFICATIONS to the
3.6.1 db entries. Replicating it manually as user 'koha' requires inserting
'perl' for the instruction to work (i.e
koha at nelson:/usr/share/koha/bin/migration_tools$ perl rebuild_zebra.pl -b
-v -x ) but gives strange results:
Records exported: 17765
====================
REINDEXING zebra
====================
15:38:46-28/09 zebraidx(5988) [warn] Missing attribute 'type' in attribute info
15:38:46-28/09 zebraidx(5988) [warn] Unknown register type:
====================
CLEANING
====================
17765 is the number of records in the 3.6.1 "imported" db. Since then we
have added records up to biblionumber:18099 which get indexed (despite the
message above) but *only* with the manual "perl" instruction. Cron doesn't
touch them. I cannot get rebuild_zebra to report 18099 (even as root), but
it indexes them anyway. And the authorities are always at "zero" whatever
I do.
Is the user-list Barry Cannon email (Wed, 26 Sep 2012 15:25:21 +0100)
relevant? He seems to be having the same problem (upgrade to 3.8) and
saying something about DOM v. grs1 (I have no clue what he's referring to.)
Gory details:
koha at nelson:/$ printenv | grep koha
PERL5LIB=/usr/share/koha/lib
USER=koha
MAIL=/var/mail/koha
KOHAPATH=/usr/share/koha
KOHA_CONF=/etc/koha/koha-conf.xml
HOME=/home/koha
LOGNAME=koha
koha at nelson:/$ crontab -l
KOHA_CONF=/etc/koha/koha-conf.xml
KOHAPATH=/usr/share/koha
PERL5LIB=$KOHAPATH/lib
*/1 * * * * koha $KOHA_PATH/bin/migration_tools/rebuild_zebra.pl -b -a -z
&> /dev/null
paul at nelson:/var/log$ sudo cat syslog | grep CRON
Sep 28 15:41:01 nelson CRON[5277]: (koha) CMD (koha
$KOHA_PATH/bin/migration_tools/rebuild_zebra.pl -b -a -z &> /dev/null)
On staff-client after entering new biblio ==> "Items for Arctic fever :
(Record #18099)"
OPAC (and staff-client) search 'biblionumber:18099' ==> No results found!
koha at nelson:/usr/share/koha$ rebuild_zebra.pl -b -a -z
rebuild_zebra.pl: command not found
koha at nelson:/usr/share/koha$ cd bin/migration_tools
koha at nelson:/usr/share/koha/bin/migration_tools$ rebuild_zebra.pl -b -a -z
rebuild_zebra.pl: command not found
koha at nelson:/usr/share/koha/bin/migration_tools$ perl rebuild_zebra.pl -b -a -z
^^^^
14:53:18-28/09 zebraidx(5514) [warn] Missing attribute 'type' in attribute info
14:53:19-28/09 zebraidx(5514) [warn] Unknown register type:
NOW ... OPAC and staff client find 'biblionumber:18099' and 'Arctic fever :
, the search for the Northwest Passage /'
BUT ... in 'authority search' ==> Wilkinson, Douglas Details 0
biblio(s) Delete
yet we have six books by this author. What are "Missing attribute 'type'"
and "Unknown register type"? What were the changes in sql data structure
from 3.6 to 3.8? Can I save our cataloguers' work and 'back-import' into
3.6.1?
As I said, I'm rebuilding the sandbox *identically* to the production
server. What would you suggest as tests leading to the cleanest repair of
our production box?
Many tnx - paul
>El sep 26, 2012 4:43 p.m., "Paul"
><<mailto:paul.a at aandc.org>paul.a at aandc.org> escribió:
>Mark,
>I truly appreciate you reply. I don't top post, so plz see below
>At 12:42 AM 9/27/2012 +0800, Mark Tompsett wrote:
>Greetings,
>Anyway, I'm about to start a complete new install (o/s + 3.8.4) on the
>sandbox to test how I can "fix" the production server
>
>
>This would be a great opportunity to do a packages or git installation.
>You only have to get the data from the live machine:
>$ Â mysqldump -u {the user name} -p {the koha database name} > PleaseTryIt.sql
>
>
>I back up every day at 3.00am, and can do a "specific" without problem.
>
>And transfer the data into the instance database, or git database before
>doing the web install.
>A git install is similar to a tarball install (you still get to name your
>database whatever you'd like, and still have those nasty long building
>sequences), and if you search bugzilla for patches, you can see if your
>problem has already been fixed with a patch that someone else provided.
>
>
>Maybe our library is unique? Â We like to have functional IT, never touch
>it (security concerns excepted), and review every couple of years. We
>started Koha in 2011 (3.4.x?) and settled with 3.6.1 as soon as it came
>out. We had a fully functional, adapted to our requirements, system. I
>made the decision to "upgrade" to 3.8.[4 at the time] because we were in
>our two year cycle to upgrade four servers and 29 workstations from Ubuntu
>10.04 LTS to 12.04 LTS.
>
>I am now under serious pressure from our Board for my "incompetence" in
>breaking a system that met our charity's needs.
>
>While I am *personally* fully prepared to try and be part of a community
>developing a great system, this cannot spill over into my $dayjob keeping
>a charity's databases of more than 650,000 items "up and running."
>
>I am currently PO'd at myself for not doing enough QA -- and this denotes
>no disrespect for all the people involved with QA within the Koha
>community, although I have to admit I was a bit surprised by someone
>mentioning that all versions of 3.8 have this glitch concerning indexing
>authorities. We use open licence/GPL Ubuntu, OpenOffice, Apache, Sendmail,
>Mysql, perl, php, various java, etc, and while they all have their ups and
>downs I don't remember a "sort of step backwards" like this.
>
>If it is, then you can apply the patch on the live system (after testing
>on your sandbox) -- without you having to figure out how to do it yourself.
>
>
>Sorry -- I'm responsible and need to "figure out how to do it." Â Not
>necessarily down the last detail, but at least enough to feel comfortable
>and responsible with what I'm doing. I'm not fully up to date with all
>coding today, but after more than half a century involvement in IT I can
>certainly "understand it" even if I can't "write it."
>
>BTW, more problems were fixed in 3.8.5, and a packages installation on
>your sandbox would be good practice for doing an upgrade from tarball to
>packages in live. Upgrades become so much easier, and the down time is
>mostly reindexing.
>
>
>Again, sorry, but I'm not looking for practice. I'm under severe pressure
>to *fix* Koha. My boss doesn't understand "sandboxes" -- she listens to
>cataloguers' complaints, hears that our coordination with other
>institutions is broken, and yells at me.
>
>Just trying to suggest something to save you headaches in the future, like
>the one you are having now because you said you wanted the headaches and
>didn't want to try the suggestion before.
>
>
>Mark - I truly appreciate and understand your pov. Â Over the last 18
>months Koha has been good to us, and I would like this to continue. I
>developed a number of "customizations", a few purely cosmetic, but mostly
>rewriting control number and barcode perl scripts to coordinate with half
>a million other "items" that we hold in other databases, and to coordinate
>our "authorities" (and biblios) with other Canadian national institutions
>... it *was* working before 3.8 ... and all I need to do is get back on track.
>
>If I have to back track to 3.6.1, I don't know how to convert 3.8
>biblio/items back to 3.6 and I'll "be responsible" for telling the
>cataloguers to redo [currently] about 600 entries, increasing by about 80
>every day. Â I'm getting a tad desperate to avoid this.
>
>Thanks for your help, time and consideration.
>
>Best regards
>Paul
>
>_______________________________________________
>Koha-devel mailing list
><mailto:Koha-devel at lists.koha-community.org>Koha-devel at 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/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/koha-devel/attachments/20120929/5d0c480d/attachment.htm>
More information about the Koha-devel
mailing list