<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"><html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body>A new request with request id 8266 has been created by koha-devel-request@lists.koha-community.org. Short info on the request is : <br><br>Title : Koha-devel Digest, Vol 200, Issue 28<br>Category : <br>Description : <div>Send Koha-devel mailing list submissions to<br> koha-devel@lists.koha-community.org<br><br>To subscribe or unsubscribe via the World Wide Web, visit<br> https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel<br>or, via email, send a message with subject or body 'help' to<br> koha-devel-request@lists.koha-community.org<br><br>You can reach the person managing the list at<br> koha-devel-owner@lists.koha-community.org<br><br>When replying, please edit your Subject line so it is more specific<br>than "Re: Contents of Koha-devel digest..."<br><br><br>Today's Topics:<br><br> 1. Koha Community Newsletter: July 2022 (Koha Newsletter)<br> 2. Re: QA for Bug 30988 - Add generic OpenIDConnect client<br> implementation (dcook@prosentient.com.au)<br> 3. Re: Thoughts on retiring libapache2-mpm-itk? (Fridolin SOMERS)<br> 4. Re: Debian 9 LTS EOL (Tomas Cohen Arazi)<br><br><br>----------------------------------------------------------------------<br><br>Message: 1<br>Date: Thu, 28 Jul 2022 13:00:13 +0200<br>From: Koha Newsletter <kohanews@gmail.com><br>To: koha <koha@lists.katipo.co.nz>, koha-devel<br> <koha-devel@lists.koha-community.org><br>Subject: [Koha-devel] Koha Community Newsletter: July 2022<br>Message-ID:<br> <CAEqgz_=fty8vhvTx7atWD8hCAa_q-s4LdKYYQRowSu+paNQFEQ@mail.gmail.com><br>Content-Type: text/plain; charset="utf-8"<br><br>The Koha Community Newsletter for July 2022 is here:<br><br>https://koha-community.org/koha-community-newsletter-july-2022/<br><br>Many thanks to everyone who submitted articles and news to this newsletter!<br><br>Please feel free to email me with any corrections or suggestions.<br>--<br>Michael Kuhn<br>Editor, Koha Community Newsletter<br>-------------- next part --------------<br>An HTML attachment was scrubbed...<br>URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20220728/fcb013f4/attachment-0001.htm><br><br>------------------------------<br><br>Message: 2<br>Date: Thu, 28 Jul 2022 17:03:43 +1000<br>From: <dcook@prosentient.com.au><br>To: "'Tomas Cohen Arazi'" <tomascohen@gmail.com>, "'Martin Renvoize'"<br> <martin.renvoize@ptfs-europe.com><br>Cc: "'Koha Devel'" <koha-devel@lists.koha-community.org><br>Subject: Re: [Koha-devel] QA for Bug 30988 - Add generic OpenIDConnect<br> client implementation<br>Message-ID: <087501d8a250$38557e40$a9007ac0$@prosentient.com.au><br>Content-Type: text/plain; charset="utf-8"<br><br>Btw, I also have thoughts on how to use Keycloak to provide SSO for the Koha REST API as well: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25796. <br><br> <br><br>In theory, it would allow SSO authenticated users to use the REST API from other SSO authenticated apps outside of Koha. <br><br> <br><br>I work on a large project which has a lot of different services (from multiple different vendors) and they all use Keycloak for SSO and a Kong API Gateway does a number of checks on the JWT that the services pass around. The services still have to do their own token checks too, but it’s a really slick way of handling authentication across a wide number of services using a central identity provider. <br><br> <br><br>It also means you wouldn’t have to give a 3rd party a staff-level Koha API user. They’d be able to leverage the user’s SSO session to access APIs that the user is authorized for at the Koha level. (That would mean adding more “public” API endpoints but I think that’s a good thing.)<br><br> <br><br>Discovery layers would also be able to make great use of this. <br><br> <br><br>David Cook<br><br>Senior Software Engineer<br><br>Prosentient Systems<br><br>Suite 7.03<br><br>6a Glen St<br><br>Milsons Point NSW 2061<br><br>Australia<br><br> <br><br>Office: 02 9212 0899<br><br>Online: 02 8005 0595<br><br> <br><br>From: dcook@prosentient.com.au <dcook@prosentient.com.au> <br>Sent: Monday, 25 July 2022 11:27 AM<br>To: 'Tomas Cohen Arazi' <tomascohen@gmail.com>; 'Martin Renvoize' <martin.renvoize@ptfs-europe.com><br>Cc: 'Koha Devel' <koha-devel@lists.koha-community.org><br>Subject: RE: [Koha-devel] QA for Bug 30988 - Add generic OpenIDConnect client implementation<br><br> <br><br>Hi Tomas,<br><br> <br><br>I thought that you were working on an OpenID Connect implementation, but then I started to doubt my memory. I suppose the takeaway is that I should never doubt myself haha. <br><br> <br><br>Yeah Bug 30988 is basically a copy of Bug 10988 (the Google version). I have never liked Bug 10988, but it’s hard to argue with something in production, and I’m tired of maintaining my own local OpenID Connect implementation these last 8 years. <br><br> <br><br>Of course, there are times where I think about writing a Koha plugin to do it instead. Locally, I’ve implemented it as a sort of built-in plugin using these hooks https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24539. Those hooks could always be changed to support the Koha Plugin system though. <br><br> <br><br>Anyway, please CC me into your implementation when you submit it. <br><br> <br><br>David Cook<br><br>Senior Software Engineer<br><br>Prosentient Systems<br><br>Suite 7.03<br><br>6a Glen St<br><br>Milsons Point NSW 2061<br><br>Australia<br><br> <br><br>Office: 02 9212 0899<br><br>Online: 02 8005 0595<br><br> <br><br>From: Tomas Cohen Arazi <tomascohen@gmail.com <mailto:tomascohen@gmail.com> > <br>Sent: Sunday, 24 July 2022 4:47 AM<br>To: David Cook <dcook@prosentient.com.au <mailto:dcook@prosentient.com.au> ><br>Cc: Koha Devel <koha-devel@lists.koha-community.org <mailto:koha-devel@lists.koha-community.org> ><br>Subject: Re: [Koha-devel] QA for Bug 30988 - Add generic OpenIDConnect client implementation<br><br> <br><br>Hi, David. I meant to answer your first email. I'm submitting (immediately) an alternative implementation I've been working on but failed to wrap up sooner.<br><br> <br><br>I've read the one you pointed and if fairly similar to the google oaidc implementation for OPAC, so it is correct.<br><br> <br><br>My plan is to do it for staff as well, using libraries.<br><br> <br><br>El vie, 22 jul 2022 7:03, <dcook@prosentient.com.au <mailto:dcook@prosentient.com.au> > escribió:<br><br>Hi all,<br><br> <br><br>Just wondering if anyone has time to QA “Bug 30988 - Add generic OpenIDConnect client implementation”. It would be great to get this additional authentication option into Koha as it would really round out Koha’s AuthN offerings.<br><br> <br><br>I could do some testing for bugs of the QAer’s choice if that helps. <br><br> <br><br>David Cook<br><br>Senior Software Engineer<br><br>Prosentient Systems<br><br>Suite 7.03<br><br>6a Glen St<br><br>Milsons Point NSW 2061<br><br>Australia<br><br> <br><br>Office: 02 9212 0899<br><br>Online: 02 8005 0595<br><br> <br><br>_______________________________________________<br>Koha-devel mailing list<br>Koha-devel@lists.koha-community.org <mailto:Koha-devel@lists.koha-community.org> <br>https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel<br>website : https://www.koha-community.org/<br>git : https://git.koha-community.org/<br>bugs : https://bugs.koha-community.org/<br><br>-------------- next part --------------<br>An HTML attachment was scrubbed...<br>URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20220728/e925d98c/attachment-0001.htm><br><br>------------------------------<br><br>Message: 3<br>Date: Tue, 26 Jul 2022 23:36:20 -1000<br>From: Fridolin SOMERS <fridolin.somers@biblibre.com><br>To: 'Koha Devel' <koha-devel@lists.koha-community.org><br>Subject: Re: [Koha-devel] Thoughts on retiring libapache2-mpm-itk?<br>Message-ID: <3d6b7e0d-bbef-e695-69c2-54b76e0e8442@biblibre.com><br>Content-Type: text/plain; charset=UTF-8; format=flowed<br><br>Hi David,<br><br>We simply have one Koha per system, using LXD containers.<br><br>nginx and starman are in this container and are run by www-data user.<br>Since cronjobs are run by a "koha" user we had some file permissions <br>issues that we patched in our fork.<br><br>For a few customers we have Apache, running with MPM Event.<br><br>Best regards,<br><br>Le 25/07/2022 à 16:05, dcook@prosentient.com.au a écrit :<br>> Hi all,<br>> <br>> I was looking at BibLibre’s ERM sandbox, and I noticed that the Nginx <br>> reverse proxy was using HTTP/2. It got me thinking about Apache httpd <br>> and HTTP/2.<br>> <br>> Apparently, Apache has an optional mod_http2 module, but it is said to <br>> work better with mpm_event and mpm_worker than mpm_prefork.<br>> <br>> But because we use mpm_itk (in order to declare “AssignUserID <br>> kohadev-koha kohadev-koha” per VirtualHost) we’re tied to using <br>> mpm_prefork.<br>> <br>> Yet… Koha mostly runs in Starman these days. We don’t necessarily get <br>> that much benefit from AssignUserID anymore. The main problem would be <br>> permissions for the CGI scripts that we don’t proxy. So maybe we wait <br>> until after we’re proxying everything through Apache and Apache is just <br>> a reverse proxy to Starman and a static asset server. Because at that <br>> point… there’s no reason it couldn’t just run under the “www-data” user.<br>> <br>> I mean we could try testing mod_http2 with mpm_prefork anyway I suppose. <br>> And there’s always the old “if it ain’t broke, don’t fix it”.<br>> <br>> I suppose I just think it’s funny that HTTP/3 exists (although it’s not <br>> widely supported on FOSS servers yet) but we haven’t even moved from <br>> HTTP/1.1 to HTTP/2.<br>> <br>> Frido, curious if you have any comments on HTTP/2 since I’m guessing you <br>> set up that Nginx reverse proxy?<br>> <br>> David Cook<br>> <br>> Senior Software Engineer<br>> <br>> Prosentient Systems<br>> <br>> Suite 7.03<br>> <br>> 6a Glen St<br>> <br>> Milsons Point NSW 2061<br>> <br>> Australia<br>> <br>> Office: 02 9212 0899<br>> <br>> Online: 02 8005 0595<br>> <br><br>-- <br>Fridolin SOMERS <fridolin.somers@biblibre.com><br>Software and system maintainer 🦄<br>BibLibre, France<br><br><br>------------------------------<br><br>Message: 4<br>Date: Wed, 27 Jul 2022 21:02:46 -0300<br>From: Tomas Cohen Arazi <tomascohen@gmail.com><br>To: David Cook <dcook@prosentient.com.au><br>Cc: Koha Devel <koha-devel@lists.koha-community.org><br>Subject: Re: [Koha-devel] Debian 9 LTS EOL<br>Message-ID:<br> <CABZfb=VOPwWn26+i-M2Ak3C_-LMWH0zrXtLeXoNKZKYMZXcFtw@mail.gmail.com><br>Content-Type: text/plain; charset="utf-8"<br><br>On Jenkins, which is what the dashboard pulls that info from, the 18.04<br>task is run only so stable branches know in advance if backports could<br>break support. I actually removed the 18.04 from the 'Suported' panel for<br>master in Jenkins.<br><br>We should discuss actions on this. I think before the 22.05 release we<br>decided to drop support for older distros, but as Mason managed to have all<br>packaging sorted (new Mojolicious, etc) we mistakenly kept the 'support'.<br><br><br>El mié, 27 jul 2022 20:35, <dcook@prosentient.com.au> escribió:<br><br>> That’s good to know!<br>><br>><br>><br>> Looking at https://dashboard.koha-community.org/, it looks like we still<br>> have CI running for Debian 8 and Debian 9 as well as Ubuntu 16 and Ubuntu<br>> 18. Perhaps those should all be retired?<br>><br>><br>><br>> I suppose we could drop Debian 8 and Ubuntu 18.04 off<br>> https://wiki.koha-community.org/wiki/System_requirements_and_recommendations<br>> in any case since they’re not “recommendations” anymore? Actually the wiki<br>> looks pretty outdated/inconsistent with the dashboard…<br>><br>><br>><br>> David Cook<br>><br>> Senior Software Engineer<br>><br>> Prosentient Systems<br>><br>> Suite 7.03<br>><br>> 6a Glen St<br>><br>> Milsons Point NSW 2061<br>><br>> Australia<br>><br>><br>><br>> Office: 02 9212 0899<br>><br>> Online: 02 8005 0595<br>><br>><br>><br>> *From:* Tomas Cohen Arazi <tomascohen@gmail.com><br>> *Sent:* Wednesday, 27 July 2022 11:36 PM<br>> *To:* David Cook <dcook@prosentient.com.au><br>> *Cc:* Koha Devel <koha-devel@lists.koha-community.org><br>> *Subject:* Re: [Koha-devel] Debian 9 LTS EOL<br>><br>><br>><br>> I'm pretty sure we don't support Debian 9 anymore. And Ubuntu 18.04 is in<br>> the same situation.<br>><br>><br>><br>> Using those old MariaDB and MySQL versions is problematic and thus<br>> discouraged.<br>><br>><br>><br>> El mié, 27 jul 2022 2:15, <dcook@prosentient.com.au> escribió:<br>><br>> Hi all,<br>><br>><br>><br>> While commenting on Bug 28267, I decided to review what versions of Debian<br>> we support, and I noticed that Debian 9 (Stretch) actually met it’s LTS EOL<br>> on 2022-06-30, so it probably makes sense for us to drop support for it at<br>> some point in the near future too.<br>><br>><br>><br>> Debian 10 (Buster) will be regular EOL in the next couple of months, and<br>> then it will get a LTS period of another couple extra years. (Interesting<br>> to note that Debian LTS isn’t actually handled by the Debian Security team<br>> but rather a separate group of volunteers.)<br>><br>><br>><br>> It looks like Ubuntu 18.04 will end its “standard support” in April 2023,<br>> so we nearly have 1 more year on it.<br>><br>><br>><br>> It looks like Debian 9 (Stretch) and Ubuntu 18.04 (Bionic) both have<br>> MariaDB 10.1.x, so I suppose we can’t drop support for that DB version<br>> until both OSes are no longer supported.<br>><br>><br>><br>><br>> https://wiki.koha-community.org/wiki/System_requirements_and_recommendations<br>><br>> https://wiki.debian.org/LTS<br>><br>> https://wiki.debian.org/DebianReleases<br>><br>> https://wiki.ubuntu.com/Releases<br>><br>><br>><br>> David Cook<br>><br>> Senior Software Engineer<br>><br>> Prosentient Systems<br>><br>> Suite 7.03<br>><br>> 6a Glen St<br>><br>> Milsons Point NSW 2061<br>><br>> Australia<br>><br>><br>><br>> Office: 02 9212 0899<br>><br>> Online: 02 8005 0595<br>><br>><br>><br>> _______________________________________________<br>> Koha-devel mailing list<br>> Koha-devel@lists.koha-community.org<br>> https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel<br>> website : https://www.koha-community.org/<br>> git : https://git.koha-community.org/<br>> bugs : https://bugs.koha-community.org/<br>><br>><br>-------------- next part --------------<br>An HTML attachment was scrubbed...<br>URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20220727/9b475148/attachment.htm><br><br>------------------------------<br><br>Subject: Digest Footer<br><br>_______________________________________________<br>Koha-devel mailing list<br>Koha-devel@lists.koha-community.org<br>https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel<br>website : https://www.koha-community.org/<br>git : https://git.koha-community.org/<br>bugs : https://bugs.koha-community.org/<br><br><br>------------------------------<br><br>End of Koha-devel Digest, Vol 200, Issue 28<br>*******************************************<br></div><br><br>NOTE: You are receiving this mail because, the Requester/Technician wanted you to get notified on this request creation.<br></body></html>