> I recommend that you downgrade to MySQL 5.5, or better install on top of
> Ubuntu LTS/Debian Wheeze. I recommend Ubuntu 12.04 Server. And follow the
> official instructions [2].
>
> [1] http://dev.mysql.com/doc/refman/5.6/en/upgrading-from-previous-series.html
> [2] http://wiki.koha-community.org/wiki/Koha_on_ubuntu_-_packages
I have (finally) gotten Koha up and running. The bottom is this: 1) I needed to
use MySQL version 5.5, and 2) I needed to edit koha-conf.xml to correctly
configure zebrasrv.
Here is a more detailed description:
1. I’m running an older version of the Linux operating system -
RHEL 5 — and its software has been installed using a huge mixture
of locally compiled source files and yum.
2. The Koha installation process did not like my mysql client
because it throws an error to STDOUT when passwords are passed on
the command line.
3. After many (many) other attempted work arounds, I downgraded
MySQL to version 5.5. I was using version 5.6. After this, the
Web-based installation process went without a hitch. (Whew!)
4. I could now do bulk imports using the Web interface, and I
could search remote Z39.50 servers to add bibliographic records
to my catalog. But I could not search nor find things in the
catalog. Searches against zebrasrv always returned error #109.
Moreover, I could not use the command line application
(bulkmarcimport.pl) to do… bulk imports.
5. Taking a closer look at koha-conf.xml I saw that some of the
paths were not correct. For example, my biblios index was not
located in /var/lib/koha/zebradb/ but rather /etc/koha/zebradb/.
I changed them accordingly. Unfortunately, zebrasrv still
returned error #109. After rooting around on the Web I discovered
an additional path I needed to configure. Specifically, I
needed to edit files like zebra-biblios.cfg and configure
modulePath to point to my locally compiled idzebra modules. [1]
(They are in /usr/local/lib/idzebra-2.0/modules, not
/usr/lib/idzebra-2.0/modules.)
6. After restarting zebrasrv, I was able to do everything. Add
records. Index records. Find records. (Double whew!)
Library catalogs (OPACs, “discovery systems”, whatever you want to call them)
are not simple applications/systems. They are a mixture of VERY specialized
inventory lists, various types of people with various skill and authorities,
indexing, and circulation, etc. Then we — as librarians — add things like
messages of the day, record exporting, browsable lists, visualizations, etc.
that complicate the whole thing. It is simply not possible to create a library
catalog in the “Unix way”. [2] At the same time, I’ve been advocating open
source software for quite a while, and I understand the meaning of “free” in
this context. I’m not complaining. Really.
That said, my next step is to discover and turn on all the ways Koha can expose
its bibliographic and authority content to the ‘Net. The things like Z39.50,
SRU, and OAI-PMH come to mind. The ultimate goal is to discover the feasibility
of exposing bibliographic and authority content in YAF — “linked data”. [3, 4]
I’m very impressed with the Koha community. It is large and international in
scope. If all Koha implementations were to make their content available as
linked data, then the whole would so much greater than the sum of its parts.
But right now I need to rest. (Whew, again!) Thank you for your patience.
[1] zebra configuration -
http://stackoverflow.com/questions/23928040/koha-3-14-zebra-search-is-not-working
[2] Unix Way - http://en.wikipedia.org/wiki/Unix_philosophy
[3] YAF - Yet Another Format
[4] linked data - http://en.wikipedia.org/wiki/Linked_data
—
Eric Lease Morgan
_______________________________________________
Koha mailing list http://koha-community.org
[email protected]
http://lists.katipo.co.nz/mailman/listinfo/koha
