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) jcam...@cpbibliography.com (web) http://www.cpbibliography.com/
_______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/