[Koha-devel] Koha on Ubuntu LTS

[Jared Camins-Esakov]

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 at server2:/$ su koha
> Password:
> koha at server2:/$ crontab -e
> crontabs/koha/: fdopen: Permission denied
> koha at server2:/$ sudo crontab -e
> [sudo] password for koha:
> koha is not in the sudoers file.  This incident will be reported.
> koha at 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 at cpbibliography.com
(web) http://www.cpbibliography.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/koha-devel/attachments/20120730/a5896be1/attachment.htm>