Paul, Over the last few days, I've looked into the cron "problem" that I raised
the other day and just to be sure, I've just reformatted and installed the whole server+Koha again, using 3.6.7's INSTALL.ubuntu, Tomas' Wiki page and my own notes.
Choose one set of instructions and follow them. INSTALL.ubuntu has instructions for installing on Ubuntu 9.04, which hasn't been supported for a while, so I would ignore anything it says.
I created the user koha by: $ sudo adduser koha but did not use either of the following: $ sudo adduser koha sudo [to give sudo rights] $ sudo adduser koha adm [to give full admin rights]
This gives rise to user=koha not being able to use crontab -e, as can be seen:
paul@server2:/$ su koha Password: koha@server2:/$ crontab -e crontabs/koha/: fdopen: Permission denied koha@server2:/$ sudo crontab -e [sudo] password for koha: koha is not in the sudoers file. This incident will be reported. koha@server2:/$
You should be doing su - in order to get a login shell, same as with *BSD and RPM-based distros. However, moving on: However, using a normal sudo account for crontab -e, use vi, add:
KOHA_CONF=/etc/koha/koha-conf.**xml KOHAPATH=/usr/share/koha PERL5LIB=$KOHAPATH/lib * * * * * koha $KOHAPATH/bin/migration_tools/**rebuild_zebra.pl<http://rebuild_zebra.pl>-a -b -z 2>&1 > /dev/null
makes a fully functional cron for incrementing Zebra, albeit in /var/spool/cron/crontab/ with root:root ownership. All that remains to be done is to rename the koha file in /etc/cron.d to koha.old (or plain remove it.) [N.B. the job is quasi-instantaneous, so running every minute is imperceptible as overhead.]
The ownership of the file doesn't matter. What matters is that you shouldn't have this configured in two different crontabs, which you currently do. This may cause problems.
ALSO, I've had to relook at how to do a complete Zebra re-index, given the permissions to user=koha. The following is fully functional:
$ su koha $ cd usr/share/koha $ KOHA_CONF=/etc/koha/koha-conf.**xml PERL5LIB=/usr/share/koha/lib ./bin/migration_tools/rebuild_**zebra.pl <http://rebuild_zebra.pl> -a -r -v $ KOHA_CONF=/etc/koha/koha-conf.**xml PERL5LIB=/usr/share/koha/lib ./bin/migration_tools/rebuild_**zebra.pl <http://rebuild_zebra.pl> -b -r -v -x
[N.B. This differs from the Wiki Appendix C., which relies on user=koha having sudo rights.]
There is a typo in Appendix C. It should not say "sudo." I have fixed this.
All of this could possibly be avoided by giving user=koha sudo rights [$ sudo adduser koha sudo], but I am for various reasons loath to do so. The solution outlined above works, and I have not yet found a specific user=koha task that fails.
I see no reason why koha should have sudo rights. Aside from one typo, I see nothing on the wiki that implies that the user should be in sudoers. I don't install from the tarball because the packages are better in every way, but back when I did, I still didn't give my koha user sudo rights. That kind of misses the point of having an unprivileged user. Regards, Jared -- Jared Camins-Esakov Bibliographer, C & P Bibliography Services, LLC (phone) +1 (917) 727-3445 (e-mail) jcamins@cpbibliography.com (web) http://www.cpbibliography.com/