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

test, please ignore
by Didier Gautheron 02 Aug '22

02 Aug '22

Hi Delivery speed test.

1 0

Staff interface redesign is ready to be tested
by Julian Maurice 31 Jul '22

31 Jul '22

Hi all, After 5 months of work, the new staff interface is finally there! As it changes a lot of pages, we will need a lot of eyes to hunt down bugs. So if you want to help, you can go to bug 30952 right now and start testing! https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30952 -- Julian Maurice BibLibre

7 11

Koha Community Newsletter: July 2022
by Koha Newsletter 28 Jul '22

28 Jul '22

The Koha Community Newsletter for July 2022 is here: https://koha-community.org/koha-community-newsletter-july-2022/ Many thanks to everyone who submitted articles and news to this newsletter! Please feel free to email me with any corrections or suggestions. -- Michael Kuhn Editor, Koha Community Newsletter

1 0

QA for Bug 30988 - Add generic OpenIDConnect client implementation
by dcook＠prosentient.com.au 28 Jul '22

28 Jul '22

Hi all, 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. I could do some testing for bugs of the QAer's choice if that helps. David Cook Senior Software Engineer Prosentient Systems Suite 7.03 6a Glen St Milsons Point NSW 2061 Australia Office: 02 9212 0899 Online: 02 8005 0595

2 3

Debian 9 LTS EOL
by dcook＠prosentient.com.au 28 Jul '22

28 Jul '22

Hi all, While commenting on Bug 28267, I decided to review what versions of Debian we support, and I noticed that Debian 9 (Stretch) actually met it's LTS EOL on 2022-06-30, so it probably makes sense for us to drop support for it at some point in the near future too. Debian 10 (Buster) will be regular EOL in the next couple of months, and then it will get a LTS period of another couple extra years. (Interesting to note that Debian LTS isn't actually handled by the Debian Security team but rather a separate group of volunteers.) It looks like Ubuntu 18.04 will end its "standard support" in April 2023, so we nearly have 1 more year on it. It looks like Debian 9 (Stretch) and Ubuntu 18.04 (Bionic) both have MariaDB 10.1.x, so I suppose we can't drop support for that DB version until both OSes are no longer supported. https://wiki.koha-community.org/wiki/System_requirements_and_recommendations https://wiki.debian.org/LTS https://wiki.debian.org/DebianReleases https://wiki.ubuntu.com/Releases David Cook Senior Software Engineer Prosentient Systems Suite 7.03 6a Glen St Milsons Point NSW 2061 Australia Office: 02 9212 0899 Online: 02 8005 0595

2 4

Koha packages are available 🎁
by Mason James 27 Jul '22

27 Jul '22

kia ora community, the latest Koha packages are available an installation guide is below... https://wiki.koha-community.org/wiki/Koha_on_Debian cheers, Mason

1 0

Thoughts on retiring libapache2-mpm-itk?
by dcook＠prosentient.com.au 27 Jul '22

27 Jul '22

Hi all, I was looking at BibLibre's ERM sandbox, and I noticed that the Nginx reverse proxy was using HTTP/2. It got me thinking about Apache httpd and HTTP/2. Apparently, Apache has an optional mod_http2 module, but it is said to work better with mpm_event and mpm_worker than mpm_prefork. But because we use mpm_itk (in order to declare "AssignUserID kohadev-koha kohadev-koha" per VirtualHost) we're tied to using mpm_prefork. Yet. Koha mostly runs in Starman these days. We don't necessarily get that much benefit from AssignUserID anymore. The main problem would be permissions for the CGI scripts that we don't proxy. So maybe we wait until after we're proxying everything through Apache and Apache is just a reverse proxy to Starman and a static asset server. Because at that point. there's no reason it couldn't just run under the "www-data" user. I mean we could try testing mod_http2 with mpm_prefork anyway I suppose. And there's always the old "if it ain't broke, don't fix it". I suppose I just think it's funny that HTTP/3 exists (although it's not widely supported on FOSS servers yet) but we haven't even moved from HTTP/1.1 to HTTP/2. Frido, curious if you have any comments on HTTP/2 since I'm guessing you set up that Nginx reverse proxy? David Cook Senior Software Engineer Prosentient Systems Suite 7.03 6a Glen St Milsons Point NSW 2061 Australia Office: 02 9212 0899 Online: 02 8005 0595

3 3

Re: [Koha-devel] Thoughts on retiring libapache2-mpm-itk?
by dcook＠prosentient.com.au 26 Jul '22

26 Jul '22

What would be insecure about making the Starman/Plack sockets writeable by www-data? It wouldn’t be any different from using TCP sockets (instead of Unix sockets) which is common or a reverse proxy. David Cook Senior Software Engineer Prosentient Systems Suite 7.03 6a Glen St Milsons Point NSW 2061 Australia Office: 02 9212 0899 Online: 02 8005 0595 From: Tomas Cohen Arazi <tomascohen(a)theke.io> Sent: Tuesday, 26 July 2022 1:10 PM To: Chris Cormack <chris(a)bigballofwax.co.nz> Cc: David Cook <dcook(a)prosentient.com.au>; Koha Devel <koha-devel(a)lists.koha-community.org> Subject: Re: [Koha-devel] Thoughts on retiring libapache2-mpm-itk? > Yet… Koha mostly runs in Starman these days. We don’t necessarily get that much benefit from AssignUserID anymore. The main problem would be permissions for the CGI scripts that we don’t proxy. So maybe we wait until after we’re proxying everything through Apache and Apache is just a reverse proxy to Starman and a static asset server. Because at that point… there’s no reason it couldn’t just run under the “www-data” user. > > That's not entirely true, plack runs on a unix socket as a user, with potentially multiple sites on a single server. So having only the right apache sites being able to talk to the right sockets by them both being the same user is a very important thing. +1 Being able to have a secure deployment out of the box is a thing we shouldn't loose!

1 0

Long-term support version of Koha (bug 31008)
by David Nind 21 Jul '22

21 Jul '22

At the Development IRC meeting on 8 June 2022 the issue of having a long-term support version of Koha (Koha LTS) was discussed. (It has been discussed and proposed in the past.) Summary ======= General agreement was reached that: 1. A long-term support (LTS) version of Koha would be for 2.5 to 3 years 2. We would start with oldstable (which is now 21.11) 3. There would be an LTS maintainer role for each cycle (there is no expectation that this is the same person for up to three years - it is preferable that it is someone different each cycle) 4. The mandate for the LTS version would cover: . security fixes . things that are broken (such as APIs (external), dependencies (such as Elasticsearch), etc), and . essential back ports only, once past oldoldstable 5. It would be an irregular release - only when something is needed once past oldoldstable 6. We would inform the Koha Community about the LTS version of Koha, what it is, and what it means for support (including updates to the website, mailing list, manual section on supported versions, etc) Next steps ======== Your feedback is welcome on the proposed LTS version of Koha. Feel free to provide this however you wish, including replying to this email, IRC, and on bug 31008. It will then be discussed again, and the approach confirmed at the next available Development IRC Meeting (ideally this would have been the 22 June 2022 meeting, but I've just sent this email!). References ========= [1] Bug 31008: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31008 [2] 8 June 2022 Development IRC meeting: . Minutes: https://meetings.koha-community.org/2022/development_irc_meeting_8_june_202… . Log: https://meetings.koha-community.org/2022/development_irc_meeting_8_june_202… David Nind | david(a)davidnind.com New Zealand m. +64 21 0537 847

3 2

Updating SCSS lint process to use stylelint
by Owen Leonard 21 Jul '22

21 Jul '22

Hi all, Back when we switched from LESS to SCSS in the OPAC (Bug 20427) I added a linting configuration, .scss-lint.yml. I've always configured my editor to automatically lint SCSS using this configuration. I don't know if anyone else does this too. In VS Code I was using scss-lint for this, but it's now deprecated. They suggest stylelint instead: https://stylelint.io. I'd like to propose replacing .scss-lint.yml with .stylelintrc.json, transferring most of the same rules. It could be left up to the individual to install the dependencies, or I could update package.json. One nice thing about stylelint is that it has a "--fix" feature for some simple rules. This could be build into our gulp tasks. Has anyone else been linting SCSS? If so, does anyone have opinions about how our current rule set is working? -- Owen -- Web Developer Athens County Public Libraries (740) 737-6006 https://www.myacpl.org

6 6