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

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

Use DateTime::Format::Strptime in Koha::DateUtils
by dcook＠prosentient.com.au 06 Aug '20

06 Aug '20

Hi all, I needed to parse a string into a DateTime object, so I decided to take a look at Koha::DateUtils, and I was surprised to see that we're parsing dates the hard way. We really should look at using DateTime::Format::Strptime instead. I use it in other Perl projects, and it makes life much easier. David Cook Systems Librarian Prosentient Systems 72/330 Wattle St Ultimo, NSW 2007 Australia Office: 02 9212 0899 Online: 02 8005 0595

2 1

New 'configurations' table (26129)
by Tomas Cohen Arazi 05 Aug '20

05 Aug '20

TL;DR; This email is for getting some feedback about a new table I'm proposing to add that implements a pattern I'm seeing more and more often as required: global, and per-library, per-item type and per-category settings. It can be easily extended with new constraints as well. Hi all, I wanted to highlight bug 26129 [1] which proposes to add a new table, for storing configuration entries. It differs from the systempreferences table basically on the ability to set values with per-library, per-item type and per-category basis, as well as default catch-all. It is the result of noticing that the smtp_servers table I was going to add on bug 22343 [2], could be easily generalized and could become useful. If someone is willing to do it, we could migrate systempreferences into this new table, but that definitely deserves more thinking. The SMTP configuration page won't live in the sysprefs page, and so a way to differentiate them could be added. One sample use of this configurations table, could be moving z39.50 servers there. [1] https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26129 [2] https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22343 -- Tomás Cohen Arazi Theke Solutions (http://theke.io) ✆ +54 9351 3513384 GPG: B2F3C15F

5 8