- Koha-devel - lists.koha-community.org

Move .tt files out of "htdocs" and into separate "tt" or "templates" directory
by dcook＠prosentient.com.au 18 Aug '20

18 Aug '20

Hi all, We should move all the .tt files out of the /usr/share/koha/intranet/htdocs and /usr/share/koha/opac/htdocs directories and put them somewhere private like /usr/share/koha/tt or /usr/share/koha/templates. At the moment, Apache is serving these files to anyone who asks for them, and it really shouldn't. Having these files in the "htdocs" directories also makes it harder to manage actual static assets that are served to Koha users. I've opened a Bugzilla report for it: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26140 This early in the release cycle, it could be great to get this done, so that we have a chance to work out any kinks before November. What do people think? David Cook Systems Librarian Prosentient Systems 72/330 Wattle St Ultimo, NSW 2007 Australia Office: 02 9212 0899 Online: 02 8005 0595

2 2

Time to translate: string freeze for 19.05.x has begun
by Victor Grousset/tuxayo 17 Aug '20

17 Aug '20

Hi, saluton, hola, bonjour, String freeze will be into effect tomorrow 18 August 2020 for the 19.05.x maintenance branch. (as well as for the other branches) The 19.05.14 release is scheduled for Monday 25 August 2020. Which means it's the right time to head over to the translation platform: https://translate.koha-community.org/projects/ Important reminder: if you add or change a translation in version 19.05, then you must also copy it to 19.11 and 20.05. Otherwise your work will be lost when upgrading to these next versions or the future ones. Happy translating, -- Victor Grousset/tuxayo

1 0

String freeze for 19.11.x
by Aleisha Amohia 17 Aug '20

17 Aug '20

Hi all, String freeze will go into effect end of on Tuesday 18 August 2020 for the 19.11.x maintenance branch. 19.11.09 release scheduled for Tuesday 25 August 2020. Thanks -- Aleisha Amohia (she/her) Koha Developer Catalyst IT - Expert Open Source Solutions

1 0

Call for news: August 2020 Koha Newsletter
by Koha Newsletter 14 Aug '20

14 Aug '20

I'm collecting news for the August newsletter. Send anything noteworthy to: k o h a news AT gmail dot com News criteria: --------------------------- ** For events **: - Please include dates for past events. If I can't find dates I may not add it. - Announcements for future events with dates T.B.A. are fine ...Eg., Kohacon - For past events , **** one month back is the cut-off ****. * News items can be of any length. * Images are fine * Anything and everything Koha. * Submit by the 26th of the month. If you are working on an interesting project or development related to Koha, please let me know and I'll include it in the development section. Thank you! -- Chad Roseburg Editor, Koha Community Newsletter

1 0

Assigning TCP ports to per-instance Koha services (e.g. koha-sip)
by dcook＠prosentient.com.au 13 Aug '20

13 Aug '20

Hi all, I've noticed that "koha-sip" will copy /etc/koha/SIPconfig.xml into /etc/koha/sites/${name}/SIPconfig.xml, but it retains the default port of 6001. Obviously, only 1 service can bind to port 6001 inside the same network namespace, so that's only going to work once, and any following "koha-sip --enable" will need manual intervention after. Is this a convention that we should expect for all current and future per-instance Koha services using TCP ports? Or should we be thinking about ways of dynamically allocating free ports? I suppose that most multi-Koha installations will have a vendor/service provider who can easily configure backend systems, whereas many organisations without technical expertise are more likely to run only 1 Koha instance (and thus benefit from single hard-coded defaults). So maybe just hard-coding a default into a per-instance Koha service makes sense? Or having an option on CLI scripts like koha-sip to define a port (to ease things for vendors) while leaving the default for users with less complex requirements? Just curious what people think. David Cook Software Engineer Prosentient Systems 72/330 Wattle St Ultimo, NSW 2007 Australia Office: 02 9212 0899 Online: 02 8005 0595

3 3

z39.50 INIT 1020 error
by Monica Benavides 11 Aug '20

11 Aug '20

Has anyone encountered an INIT 1020 error when using z39.50? If so, what was causing the error and how did you fix it? <zs:diagnostics xmlns:diag="http://www.loc.gov/zing/srw/diagnostic/"> <diag:diagnostioc> <diag:uri>info:srw/diagnostic/l/2</diag:uri> <diag:details> session_shared: target closed connection during init </diag:details> <diag:message>System temporarily unavailable</diag:message> </diag:diagnostic> </zs:diagnostics> This is all I know regarding the description of the error. 2.2. Init Number Description Recommended display 1020 Init/AC: System temporarily unavailable System temporarily available (ref. 1020) Code Meaning Addinfo 1020 Init/AC: System temporarily unavailable when it's expected back up -- *Monica Benavides* *Library Assistant/Testing Center Coordinator* –––––––––––––––––––––––––––––––––––––––––––––––––––– *Rocky Mountain University of Health Professions* 122 East 1700 South, Building 3, Provo, Utah 84606 Direct: 385.375.8772 *|* Campus: 801.375.5125 –––––––––––––––––––––––––––––––––––––––––––––––––––– *Stay connected, learn more!* Blog <https://rmuohp.edu/about-the-university/university-news/> | Facebook <https://www.facebook.com/RMUoHP> | Twitter <https://twitter.com/rmuohp> | YouTube <https://www.youtube.com/user/TheRMUoHP> | rm.edu

1 0

Maintenance of the mailing list server
by Jonathan Druart 11 Aug '20

11 Aug '20

Hello devs, I have been in touch with Biblibre's sysop, Laurent. We are planning an upgrade of the mailing list server (move), in order to fix the problems we are facing for several months. It will make all the mailing lists listed there unavailable: https://lists.koha-community.org/cgi-bin/mailman/listinfo (all Koha MLs but the general one koha(a)lists.katipo.co.nz) It will be done on August 11th (Tuesday) starting at 7 UTC (for about 1 or 2 hours). I will send an update message when it is finished. Cheers, Jonathan

2 2

Public vs Private/Admin API
by dcook＠prosentient.com.au 11 Aug '20

11 Aug '20

Hi all, I've been thinking a little about API security. When I look at http://localhost:8081/api/v1/.html, I see every API route we define in Koha. Do we really want all of these APIs to be accessible to any API consumer? In many cases, I imagine we only want Staff Interface users (or approved third-party tools) using a lot of these API routes. At the moment, if someone cracks the password of an admin user on the OPAC, they'd then be able to access admin APIs via the OPAC site. That seems suboptimal to me. In theory, breaching the OPAC should have a small blast radius that only affects one user. In practice, if someone breaches the OPAC with an admin user, the blast radius can still be large. Based on https://www.keycloak.org/docs/latest/server_admin/index.html#admin-endpoints -and-console, it could be good to have separate admin API and public API interfaces, which can then be configured and protected differently. I suppose a person could IP restrict the API at the moment and just allow public access to /api/v1/public/ routes. I suppose I just wonder about having more restrictive defaults, although in the Keycloak case the defaults are permissive. Anyway, just sharing my thoughts on this one. David Cook Software Engineer Prosentient Systems 72/330 Wattle St Ultimo, NSW 2007 Australia Office: 02 9212 0899 Online: 02 8005 0595

1 0

Best practices for using Koha APIs server-side by Koha
by dcook＠prosentient.com.au 10 Aug '20

10 Aug '20

Hi all, I mostly see Koha APIs being used client-side by Koha using cookie authentication. I know we have OAuth2 and Basic Auth that can be tied to a Koha user, and used by a third-party system, which is great. However, what about when we have server-side Koha components that want to use Koha APIs? (I suppose you could set up a user for that component, but it could always be deleted by an overzealous librarian.) Or should we only be using a Message Broker (like RabbitMQ) for passing messages among Koha server-side components? (That would require more of a service oriented architecture of course, which we don't have in place, while we do have a HTTP API in place.) What are your thoughts? David Cook Systems Librarian Prosentient Systems 72/330 Wattle St Ultimo, NSW 2007 Australia Office: 02 9212 0899 Online: 02 8005 0595

2 3

Upgrading Debian 8 to Debian 9 breaks Koha 18.05 (also couldn't install Koha 20.05 on Ubuntu 18.04)
by dcook＠prosentient.com.au 07 Aug '20

07 Aug '20

Hi all, Since Debian 8 is EOL, it's past time to upgrade to Debian 9 (at least). However, upgrading from Debian 8 to Debian 9 uninstalls Koha 18.05. Worse, when I try to re-install Koha, I get the following errors now (although I didn't a month ago on a similar server): The following packages have unmet dependencies: koha-common : Depends: libhttp-oai-perl (< 4.0) but 4.03-2 is to be installed or libhttp-oai-3.27-perl but it is not installable Depends: libmojolicious-plugin-openapi-perl but it is not installable Depends: libpdf-fromhtml-perl but it is not installable Depends: libtemplate-plugin-htmltotext-perl but it is not installable E: Unable to correct problems, you have held broken packages. (Also, last time we tried to install Koha 20.05 on Ubuntu 18.04, we encountered the problem with https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25886.) What's going on with the Koha packaging these days? David Cook Systems Librarian Prosentient Systems 72/330 Wattle St Ultimo, NSW 2007 Australia Office: 02 9212 0899 Online: 02 8005 0595

2 1