Question: I am noticing some errors in the koha-zebradaemon-output.log file. When new records are added it takes a bit longer to index than we think they should. Running rebuild zebra is often faster. Zebra ends up indexing and search works, but I am concerned about the errors. Any ideas?
Answer: Rebuild_zebra.pl -r deletes all of the files in the Zebra db directories (such as reci-0.mf) and then recreates them. Thus, permissions will be lost, and the files will be owned by the user who ran rebuild_zebra.pl. If one rebuilds the zebra indexes as root, the daemons, which typically run under the user Koha, will not be able to update the indexes. Thus, it's important then that the zebra rebuilds are put in the cronjob file of the user Koha, and not root. Also important is that other users, such as root, don't manually execute rebuilds.
If one desires that another user be able to execute rebuild_zebra.pl, he should be given the permission to execute 'sudo -u Koha .../rebuild_zebra.pl,' (if you want to do this, you also have to edit the sudoers file to pass the PERL5LIB variable with the env_keep option as by default sudo strips away almost all environment variables). Or, as root user, one can use a simple 'su koha' and then the rebuild_zebra.pl command.
I've also tried to set the sticky bit on rebuild_zebra.pl, but for whatever reason it didn't seem to work due to some problem with the PERL5LIB variable that I wasn't able to figure. That seems to me the easiest thing to do, if anybody has any idea how to make it work. If it worked and were the default, I think it would help folks to avoid a great deal of the problems that come up with zebra.
Question: Could someone tell me the exact steps I need to take to configure Zebra to expose my Koha 3 db as a public Z39.50 service?
Answer: Edit the KOHA_CONF file that your Koha is using. Uncomment the publicserver line like:
<!-- <listen id="publicserver" >tcp:@:9999</listen> -->
to be:
<listen id="publicserver" >tcp:@:9999</listen>
Then restart zebasrv and connect on the port specified (9999).
Question: When editing an item, the new shelving location I created is not showing up by default in the items where I assigned it to.
Answer: This is because you created the new shelving location with a code value of 0 (zero) Just FYI the system interprets authorized values of 0 as equaling a null so when you edit a record in cataloging where the authorized value in a field was assigned where the code was 0, the value displays as null in the item editor (or MARC editor) instead of the value the library meant it to be.
Question: Why would I want to define authorized values for MARC tags?
Answer: Authorized Values create a 'controlled vocabulary' for your staff. As an example, let us assume that your Koha installation is used by several libraries, and you use MARC 21. You might want to restrict the 850a MARC subfield to the institution codes for just those libraries. In that case, you could define an authorized values category (perhaps called "INST") and enter the institution codes as the authorized values for that category.
Koha automatically sets up authorized value categories for your item types and branch codes, and you can link these authorized values to MARC subfields when you set up your MARC tag structure.
Question: Is there a periodic job that can be run to cull old sessions from the table? We don't want to backup all the useless session data every night.
Answer: You can run cleanup database cron job.
Or just before doing a backup command (mysqldump), you can truncate session table:
mysql -u<kohauser -p<password <koha-db-name -e 'TRUNCATE TABLE sessions'