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

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

SIP2 Error 20.05
by Humberto Blanco Castillo 07 Aug '20

07 Aug '20

Hi, I configure SIP2 , and the service load well *root@srvcbkohac01:/var/log/koha/catalogo# netstat -an | grep ":8023"tcp 0 0 0.0.0.0:8023 <http://0.0.0.0:8023> 0.0.0.0:* LISTEN root@srvcbkohac01:/var/log/koha/catalogo# netstat -an | grep ":6001"tcp 0 0 0.0.0.0:6001 <http://0.0.0.0:6001> 0.0.0.0:* LISTEN root@srvcbkohac01:/var/log/koha/catalogo# koha-sip --status catalogo[ ok ] SIP server running for catalogo:.* My selfchek machines are not connecting to SIP server. And if i want to try do telnet localhost 6001 the server open an closes the connection inmediately *root@srvcbkohac01:/var/log/koha/catalogo# telnet localhost 6001Trying 127.0.0.1...Connected to localhost.Escape character is '^]'.Connection closed by foreign host.* cannot permit any command. My server is Debian "Debian GNU/Linux 10 (buster)", and the firewall its not enabled. My server params an port are the following, those are working fine inkoha version 3.22: *<server-params min_servers='10' min_spare_servers='5' log_file='Sys::Syslog' syslog_ident='koha_sip' syslog_facility='local6' ipv='4' /> <listeners> <service port="8023/tcp" transport="telnet" protocol="SIP/2.00" timeout="120" /> <service port="6001/tcp" transport="RAW" protocol="SIP/2.00" client_timeout="600" timeout="600" />* Really appreciate if have any idea ... Humberto -- Cordialmente, Humberto Blanco

2 1

An idea for consolidating staff interface header search forms
by Owen Leonard 07 Aug '20

07 Aug '20

I'm playing around with the idea of eliminating all the many search form include files (serials-search.inc, cat-search.inc, checking-search.inc, etc.) and replacing them with a single template which can be processed in different ways. For instance, in the circulation-home.tt template, "[% INCLUDE 'circ-search.inc' %]" would be replaced with "[% PROCESS header_searches.inc searches="circulation_searches" %]" In header_searches.inc (see https://gitlab.com/snippets/1994424) an array of search forms and their labels would be output according to the "searches" variable passed to the include file for processing. Unfortunately this doesn't appear to be translatable, but Bug 20988 might make it possible. Does this sound like a worthwhile pursuit? A sensible way to leverage Template toolkit's functionality? Thanks, -- Owen -- Web Developer Athens County Public Libraries (740) 737-6006 https://www.myacpl.org

4 10

Current state of unit testing
by dcook＠prosentient.com.au 06 Aug '20

06 Aug '20

Hi all, I gave Test::DBIx::Class a try tonight, as it seems super awesome, but unfortunately encountered the following error due to C4::Biblio::_koha_add_biblio() using a MySQLism in its SQL: C4::Biblio::_koha_add_biblio(): DBI Exception: DBD::SQLite::db prepare failed: near "SET": syntax error at /kohadevbox/koha/C4/Biblio.pm line 219 That makes me think my only option is to turn off Autocommit and rollback my testing work. Does anyone else have a better alternative for unit tests in Koha? David Cook Systems Librarian Prosentient Systems 72/330 Wattle St Ultimo, NSW 2007 Australia Office: 02 9212 0899 Online: 02 8005 0595

1 0