- Koha - lists.katipo.co.nz

Documentation Drop-in Sessions 2024
by philip.orr＠lmscloud.de 02 Feb '24

02 Feb '24

Hello, Online Koha Documentation workshops are back again! Aude Charillon (Documentation manager + PTFS Europe) and I are organising the 2024 series. We would like to hold one event every two months starting in February. The aims are: * for new Documenters to learn to edit the Manual and/or get help; * for experienced Documenters to have time set aside to document, ask questions and chat with others. * So far we have thought the workshops as informal drop-ins. What we do and how we organised ourselves on the day (e.g., split rooms) will depend on who turns up. To provide you with a chance to take part in these events, we would like to know what dates and times would work best for you. Please let us know by filling in this poll by 9th February: https://framadate.org/dcoTP8q6Ru7xXplw I am aware none of the proposed times are particularly convenient for people in Oceania. If you are in that area (or any other timezone where its not convenient) and wanted to take part, please leave a comment on the poll with an indication of your timezone so we may take it into account for future workshops! As usual, please contact me if you have any comments or questions. Thanks and hope to see you in the meetings Philip Orr [krimsonkharne on Koha-IRC] -- Philip Orr LMSCloud GmbH Office Bad Münstereifel Project management, Training, Support T +49 7121 144154 e philip.orr(a)lmscloud.de <mailto:philip.orr@lmscloud.de> w <http://www.lmscloud.de/> www.lmscloud.de

1 0

Prevent specific MARC field from being duplicated?
by Bales (US), Tasha R 02 Feb '24

02 Feb '24

Hello, I have not yet found the answer to this question. We are still running 21.05, but plan to upgrade soon (unsure to what release). When duplicating a bibliographic record, is it possible to NOT duplicate a specific MARC field from the source record? In particular, I'd like to avoid duplicating action notes that are in the 583 field. We use dated action notes, and we duplicate lots of records, and information in source records that is not applicable to target records is being saved to them by mistake. Our use of the field is as follows: 583$a has a default value. 583$c uses the dateaccessioned.pl plugin to enable a date picker/calendar. Is there a way to "block" certain fields from being duplicated? Although we could train staff to delete that field with every duplication, I'd prefer to avoid human error and the additional keystrokes. Thanks in advance for all ideas. If a JavaScript/jQuery solution is possible, maybe that would work, but I'm not sure how to make it happen. Tasha Bales

2 2

Re: [Koha] Koha Login Error
by Rudy Hinojosa 02 Feb '24

02 Feb '24

I noticed this too, right after upgrading from 23.05.07 to 23.11. 500 error after logging in. plack logs are not conclusive, but syslog showed this: 2024-02-02 1:08:57 54 [Warning] Aborted connection 54 to db: 'koha_xxxx' user: 'koha_xxxx' host: 'localhost' (Got an error reading communication packets) Running Ubuntu latest LTS, and mariadb. Reverting back to 23.05.07 for now on a production system. Rudy E. Hinojosa CEO/President, Lightwave Library Toll Free: 888-503-1727 (tel:TollFree:888-503-1727) lightwavelibrary.com (https://lightwavelibrary.com) rudy.hinojosa(a)lightwavelibrary.com (mailto:rudy.hinojosa@lightwavelibrary.com) P.O. Box 484, Liberty Hill, Texas 78642 (https://maps.google.com/?q=P.O.%20Box%20484,%20Liberty%20Hill,%20Texas%2078…) Life After Solutions LLC DBA: Lightwave Library On Feb 1 2024, at 5:00 pm, koha-request(a)lists.katipo.co.nz wrote: > Send Koha mailing list submissions to > koha(a)lists.katipo.co.nz > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.katipo.co.nz/mailman/listinfo/koha > or, via email, send a message with subject or body 'help' to > koha-request(a)lists.katipo.co.nz > > You can reach the person managing the list at > koha-owner(a)lists.katipo.co.nz > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Koha digest..." > > > Today's Topics: > 1. Feb. 2024 possibility of Koha list delivery problems for > Gmail, etc. (Thomas Dukleth) > 2. Re: Koha login error (Magnus Enger) > 3. The Terrific Every-Other-Thursday Training Video | > Restricting Circulation | 411 (BRANNON, CHRISTOPHER) > > > ---------------------------------------------------------------------- > Message: 1 > Date: Thu, 1 Feb 2024 02:53:23 -0000 > From: "Thomas Dukleth" <kohalist(a)agogme.com> > To: koha(a)lists.katipo.co.nz > Subject: [Koha] Feb. 2024 possibility of Koha list delivery problems > for Gmail, etc. > Message-ID: > <8dc9e682cd7649325de9ce90c259d17f.squirrel(a)wmail.agogme.com> > Content-Type: text/plain;charset=utf-8 > > There is the possibility that users of large email services, such as > Gmail, Yahoo, etc. may have problems receiving some email sometime in > February for lack of correct implementation of anti-spam authentication > protocols. > > 1. Adequate Corrections Mostly Prepared But Extra Caution for the Koha > General Mailing List. > > The Koha mailing lists should have all been corrected in a way which may > be adequate while people work on setting up a new system for the mailing > lists. However, the Koha general mailing is lagging behind good response > perhaps in the hope that another party to take over the list would have > taken over already, or perhaps it was partly fixed but someone forgot to > update the serial number and I had omitted the serial number from my > previous instructions. > > The new email delivery policy at large email providers, such as Gmail etc. > could include some subscribers to the Koha general mailing list affecting > their ability to receive email from sources not properly authenticated. > The new policy has distinct rules for both large volume senders which > could possibly be the mailing list with enough Gmail subscribers but the > Koha general mailing list may need to meet the large volume sender > requirement with DMARC support so that what is missing from the small > volume sender requirement continues to be given a pass. > > > 2. Related Issue for Koha Installations. > If mail servers for systems sending notices etc. to patrons do not have > all the expected configuration, patron recipients using Gmail, etc. may > also be affected but probably would have had problems previously. It > would be prudent to confirm that the mail server sending messages is > reaching Gmail, etc. users without problem by having SPF and DMARC > settings in the DNS and applies DKIM signatures to messages. > > > 3. Effect of February Changes for Gmail, etc. Mailing List Subscribers. > We do not know what will happen if anything but people should be prepared > for the possibility of a disruption in receiving some email at large > providers, such as Gmail, etc. which might not appear in the spam box or > anywhere. If mailing list messages appear in the spam box, a filter can > be added by people in their Gmail, etc. settings. If messages stop > arriving even and do not even appear in the spam box the server sending > email for the mailing list will need more configuration. > > Sending messages to the list will continue to work as will the mailing > list archives which can be read while we set up a new system. If you are > unlucky enough to confirm that no mailing list messages are arriving for > you not even in your spam box and yet they appear in the mailing list > archive you may report that the issue affects this mailing list system > which they use, Gmail etc. in > https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34927 . The > mailing list would be shown to need more server configuration while people > work on setting up a new system. Meanwhile, you might also try at least > temporarily resubscribing to the mailing list from a different email > provider with less strict authentication policies for delivering messages. > > Mailing lists are not the primary target of the new stricter policies for > Gmail, etc. but they are included. > > Mailing list messages would have failed long ago for Gmail, etc. except > that we have the advantage of having authentication attached to messages > from the original author forwarded via the mailing list. They mostly > carry the DKIM signature from the original author. Gmail has not recently > been validating DKIM signatures which would fail when sent from the > mailing list because of small changes when the message is resent by the > mailing list with the mailing list footer, etc. Also, Gmail has recently > been passing messages with SPF and DMARC records in the originating server > DNS and no DKIM signatures. > > Relying on authentication from the original author as opposed to the > mailing list forwarder is not correct for DMARC and DKIM and might now > fail unless mailing lists are treated a little more leniently at least > initially. Library of Congress run mailing lists which I examined a few > days ago did not have DMARC mitigation for correct From header attribution > as from the author via the mailing list address but did have a DMARC DNS > record which is currently missing for the Koha general mailing list. > Email originating from governments may have their own special rules for > delivery at Gmail, etc. > > In my current testing, new subscription confirmation messages for the Koha > general list do not appear in the Gmail, not even in the spam box. > However, mailing list message delivery to Gmail etc. may continue to have > a free pass from the authentication of the original author's message. > > The need for DMARC support authenticating the mailing list as the actual > originator of messages on the mailing list as opposed to the message > author has been raised previously and it has been tested on the Koha-devel > mailing list and may now be implemented on all the Koha mailing lists > except for the general list. > > > 4. Please be Nice to the People Who Gave Koha to the World. > The Koha general mailing list is a special problem only because Katipo for > which we are all grateful for giving Koha to the world no longer has the > capacity to actively maintain the Koha general mailing list which has been > fine as the existing configuration was good for a very long time and did > not seriously require maintenance until recently. Even though DMARC > support is a trivial matter of changing three lines and (maybe updating a > DNS serial number for 4 lines), it has not happened for Katipo in the past > few months since I have raised the issue. > > It may be possible that people assisting Rachel Hamilton-Williams are not > certain where DNS is configured for lists.katipo.co.nz to update that > record for DMARC support. DNS configuration could be at the domain > registrar, some intermediate service, some VPS hosting provider, or on the > very system which runs the katipo.co.nz server or lists.katipo.co.nz > server. > > If using BIND for DNS line to add would be: > _dmarc.lists.katipo.co.nz. IN TXT "v=DMARC1; p=none" > or the equivalent in some other system where the leading underscore is > needed and the policy is "p=none" matches the DNS configuration for the > the BibLibre managed Koha mailing lists such as the Koha-devel list. If > using BIND, the zone file where lists.katipo.co.nz is configured would > need a serial number update. The BIND9 daemon would also restart. Maybe > a change was made without a serial number update or daemon restart. > There are two equally trivial Mailman configuration changes also needed > but a DNS update for DMARC comes first. > > I have sent messages but response discussion was only about having another > party take over running the mailing list for more active maintenance which > would necessarily take time and the Koha community is pursuing a new > system which takes time. > > > 5. New System Fixes Everything Except New Problems. > Please be patient. > People are working on setting up, configuring, testing etc. a new system > which can give people email for doing everything and a message forum for > people who prefer forums instead of email which is important because > mailing list engagement is declining everywhere. People need time from > the other more pressing tasks of every day to work on all that is > necessary for a fully working system. > > I have weeks of research into various issues for configuration, bugs, some > tests etc. If we rush things we may have much unhappiness with any of a > variety of common problems: from email not working properly;posts mangled; > message lists jumbled where distinctive content is difficult to find; > database backups silently corrupted and not restoring after a software > update; contented list readers having their accounts deleted after a time; > etc. People need to take time to do things reasonably well so that > unpleasant surprises are minimised. > > I expect that it may take several weeks to a few months for a new system > to be well setup, configured, tested, reconfigured, and retested before we > should have confidence in a new system informed by the problems which > other people had before us. Meanwhile, fixing DMARC on Mailman 2.1 which > we are running is trivial by comparison. > > > 6. Reference. > See the message I posted on the Koha-devel mailing list about prospective > delivery problems especially the prospect for the Koha general mailing > list, "[Koha-devel] Feb. 2024 prospects of Koha lists delivery problems > for Gmail, etc." - > https://lists.koha-community.org/pipermail/koha-devel/2023-November/048441.… > . [I resolved the ARC permissions problem mentioned in the message by > having the startup script change the permissions but with DMARC Gmail has > been satisfied in my testing even when DKIM and ARC are not present.] > > Please report verified mailing list receipt problems in "Bug 34927 - > Adding DMARC compatibility to mailing lists" - > https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34927 . [Once > someone has reported that mailing list X messages are not being accepted > by subscribers using big service Y , not even in the spam box, we do not > need the same information again. Not every user of some big mail service > may have the same experience because such large services do not tend to > implement changes worldwide all at the same time.] > > > Thomas Dukleth > Agogme > 109 E 9th Street, 3D > New York, NY 10003 > USA > http://www.agogme.com > +1 212-674-3783 > > > > ------------------------------ > Message: 2 > Date: Thu, 1 Feb 2024 08:28:58 +0100 > From: Magnus Enger <magnus(a)libriotech.no> > To: koha(a)lists.katipo.co.nz > Subject: Re: [Koha] Koha login error > Message-ID: <0e0c1c30-52c8-4ed2-a8e3-7a6a29d6b4e5(a)libriotech.no> > Content-Type: text/plain; charset=UTF-8; format=flowed > > Hi! > Den 31.01.2024 22:09, skrev MASTeR Library: > > Dear sri, koha when logging in the following error is coming what should be > > done to fix this. > > n error has occurred!*Error 500*This message may have been caused by any of > > the following reasons: > > When there is a "500 error" you cannot tell from just looking at the > interface what the real problem is. You, or someone else with access to > the server Koha is running on, need to log on to the server and look at > the logs, preferably "live" while the error is being triggered. > > The way I do this is to run this: > sudo tail -f /var/log/koha/<instancename>/plack*.log > ...while I trigger the error. The logs will hopefully give more details > about what is happening. > > Hope that helps! > Magnus > > > ------------------------------ > Message: 3 > Date: Thu, 1 Feb 2024 16:05:47 +0000 > From: "BRANNON, CHRISTOPHER" <CBRANNON(a)cdalibrary.org> > To: " (koha(a)lists.katipo.co.nz)" <koha(a)lists.katipo.co.nz> > Subject: [Koha] The Terrific Every-Other-Thursday Training Video | > Restricting Circulation | 411 > Message-ID: > <LV2PR19MB58622E61BE2451D9E0F66D80A4432(a)LV2PR19MB5862.namprd19.prod.outlook.com> > > Content-Type: text/plain; charset="us-ascii" > Not all accounts are created equal. Some have a special purpose, and need to be treated differently. Particularly in ways that Koha itself does not give us options for. Until now. George will walk us through some jQuery adjustments that will allow you to limit checkouts to particular borrower categories based on the library you are logged in as. This may be an important feature to some, but I think George just likes the power. > https://youtu.be/hbVWaXBHNmQ > Sincerely, > Christopher Brannon > koha-US Admin > > > ------------------------------ > Subject: Digest Footer > _______________________________________________ > Koha mailing list > Koha(a)lists.katipo.co.nz > https://lists.katipo.co.nz/mailman/listinfo/koha > > > ------------------------------ > End of Koha Digest, Vol 220, Issue 2 > ************************************ >

1 0

The Terrific Every-Other-Thursday Training Video | Restricting Circulation | 411
by BRANNON, CHRISTOPHER 01 Feb '24

01 Feb '24

Not all accounts are created equal. Some have a special purpose, and need to be treated differently. Particularly in ways that Koha itself does not give us options for. Until now. George will walk us through some jQuery adjustments that will allow you to limit checkouts to particular borrower categories based on the library you are logged in as. This may be an important feature to some, but I think George just likes the power. https://youtu.be/hbVWaXBHNmQ Sincerely, Christopher Brannon koha-US Admin

1 0

Koha login error
by MASTeR Library 01 Feb '24

01 Feb '24

Dear sri, koha when logging in the following error is coming what should be done to fix this. n error has occurred!*Error 500*This message may have been caused by any of the following reasons: - You made use of an external link to an item that is no longer available - You followed an outdated link e.g. from a search engine or a bookmark - You tried to access a page that needs authentication - An internal link in the client is broken and the page does not exist What's next? - Use top menu bar to navigate to another part of Koha. - To report a broken link or any other issue, please contact the Koha administrator. Send email <masterlibrary%40mamcet.com>

2 1

Feb. 2024 possibility of Koha list delivery problems for Gmail, etc.
by Thomas Dukleth 01 Feb '24

01 Feb '24

There is the possibility that users of large email services, such as Gmail, Yahoo, etc. may have problems receiving some email sometime in February for lack of correct implementation of anti-spam authentication protocols. 1. Adequate Corrections Mostly Prepared But Extra Caution for the Koha General Mailing List. The Koha mailing lists should have all been corrected in a way which may be adequate while people work on setting up a new system for the mailing lists. However, the Koha general mailing is lagging behind good response perhaps in the hope that another party to take over the list would have taken over already, or perhaps it was partly fixed but someone forgot to update the serial number and I had omitted the serial number from my previous instructions. The new email delivery policy at large email providers, such as Gmail etc. could include some subscribers to the Koha general mailing list affecting their ability to receive email from sources not properly authenticated. The new policy has distinct rules for both large volume senders which could possibly be the mailing list with enough Gmail subscribers but the Koha general mailing list may need to meet the large volume sender requirement with DMARC support so that what is missing from the small volume sender requirement continues to be given a pass. 2. Related Issue for Koha Installations. If mail servers for systems sending notices etc. to patrons do not have all the expected configuration, patron recipients using Gmail, etc. may also be affected but probably would have had problems previously. It would be prudent to confirm that the mail server sending messages is reaching Gmail, etc. users without problem by having SPF and DMARC settings in the DNS and applies DKIM signatures to messages. 3. Effect of February Changes for Gmail, etc. Mailing List Subscribers. We do not know what will happen if anything but people should be prepared for the possibility of a disruption in receiving some email at large providers, such as Gmail, etc. which might not appear in the spam box or anywhere. If mailing list messages appear in the spam box, a filter can be added by people in their Gmail, etc. settings. If messages stop arriving even and do not even appear in the spam box the server sending email for the mailing list will need more configuration. Sending messages to the list will continue to work as will the mailing list archives which can be read while we set up a new system. If you are unlucky enough to confirm that no mailing list messages are arriving for you not even in your spam box and yet they appear in the mailing list archive you may report that the issue affects this mailing list system which they use, Gmail etc. in https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34927 . The mailing list would be shown to need more server configuration while people work on setting up a new system. Meanwhile, you might also try at least temporarily resubscribing to the mailing list from a different email provider with less strict authentication policies for delivering messages. Mailing lists are not the primary target of the new stricter policies for Gmail, etc. but they are included. Mailing list messages would have failed long ago for Gmail, etc. except that we have the advantage of having authentication attached to messages from the original author forwarded via the mailing list. They mostly carry the DKIM signature from the original author. Gmail has not recently been validating DKIM signatures which would fail when sent from the mailing list because of small changes when the message is resent by the mailing list with the mailing list footer, etc. Also, Gmail has recently been passing messages with SPF and DMARC records in the originating server DNS and no DKIM signatures. Relying on authentication from the original author as opposed to the mailing list forwarder is not correct for DMARC and DKIM and might now fail unless mailing lists are treated a little more leniently at least initially. Library of Congress run mailing lists which I examined a few days ago did not have DMARC mitigation for correct From header attribution as from the author via the mailing list address but did have a DMARC DNS record which is currently missing for the Koha general mailing list. Email originating from governments may have their own special rules for delivery at Gmail, etc. In my current testing, new subscription confirmation messages for the Koha general list do not appear in the Gmail, not even in the spam box. However, mailing list message delivery to Gmail etc. may continue to have a free pass from the authentication of the original author's message. The need for DMARC support authenticating the mailing list as the actual originator of messages on the mailing list as opposed to the message author has been raised previously and it has been tested on the Koha-devel mailing list and may now be implemented on all the Koha mailing lists except for the general list. 4. Please be Nice to the People Who Gave Koha to the World. The Koha general mailing list is a special problem only because Katipo for which we are all grateful for giving Koha to the world no longer has the capacity to actively maintain the Koha general mailing list which has been fine as the existing configuration was good for a very long time and did not seriously require maintenance until recently. Even though DMARC support is a trivial matter of changing three lines and (maybe updating a DNS serial number for 4 lines), it has not happened for Katipo in the past few months since I have raised the issue. It may be possible that people assisting Rachel Hamilton-Williams are not certain where DNS is configured for lists.katipo.co.nz to update that record for DMARC support. DNS configuration could be at the domain registrar, some intermediate service, some VPS hosting provider, or on the very system which runs the katipo.co.nz server or lists.katipo.co.nz server. If using BIND for DNS line to add would be: _dmarc.lists.katipo.co.nz. IN TXT "v=DMARC1; p=none" or the equivalent in some other system where the leading underscore is needed and the policy is "p=none" matches the DNS configuration for the the BibLibre managed Koha mailing lists such as the Koha-devel list. If using BIND, the zone file where lists.katipo.co.nz is configured would need a serial number update. The BIND9 daemon would also restart. Maybe a change was made without a serial number update or daemon restart. There are two equally trivial Mailman configuration changes also needed but a DNS update for DMARC comes first. I have sent messages but response discussion was only about having another party take over running the mailing list for more active maintenance which would necessarily take time and the Koha community is pursuing a new system which takes time. 5. New System Fixes Everything Except New Problems. Please be patient. People are working on setting up, configuring, testing etc. a new system which can give people email for doing everything and a message forum for people who prefer forums instead of email which is important because mailing list engagement is declining everywhere. People need time from the other more pressing tasks of every day to work on all that is necessary for a fully working system. I have weeks of research into various issues for configuration, bugs, some tests etc. If we rush things we may have much unhappiness with any of a variety of common problems: from email not working properly;posts mangled; message lists jumbled where distinctive content is difficult to find; database backups silently corrupted and not restoring after a software update; contented list readers having their accounts deleted after a time; etc. People need to take time to do things reasonably well so that unpleasant surprises are minimised. I expect that it may take several weeks to a few months for a new system to be well setup, configured, tested, reconfigured, and retested before we should have confidence in a new system informed by the problems which other people had before us. Meanwhile, fixing DMARC on Mailman 2.1 which we are running is trivial by comparison. 6. Reference. See the message I posted on the Koha-devel mailing list about prospective delivery problems especially the prospect for the Koha general mailing list, "[Koha-devel] Feb. 2024 prospects of Koha lists delivery problems for Gmail, etc." - https://lists.koha-community.org/pipermail/koha-devel/2023-November/048441.… . [I resolved the ARC permissions problem mentioned in the message by having the startup script change the permissions but with DMARC Gmail has been satisfied in my testing even when DKIM and ARC are not present.] Please report verified mailing list receipt problems in "Bug 34927 - Adding DMARC compatibility to mailing lists" - https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34927 . [Once someone has reported that mailing list X messages are not being accepted by subscribers using big service Y , not even in the spam box, we do not need the same information again. Not every user of some big mail service may have the same experience because such large services do not tend to implement changes worldwide all at the same time.] Thomas Dukleth Agogme 109 E 9th Street, 3D New York, NY 10003 USA http://www.agogme.com +1 212-674-3783

1 0

Unable to hide login screen on Koha OPAC
by bongiwe＠uks.co.za 31 Jan '24

31 Jan '24

Hi I would like to make our KOHA OPAC open to the public without them having to login. I have edited the OPACUserJS entry and put in the following string, $("#login").hide(); The login screen is still there after saving this. What could I be doing wrong? Kind regards, Bongiwe Shongwe

3 2

koha-US February 2024 Events & Meetings
by Kristi Krueger 29 Jan '24

29 Jan '24

Hello! koha-US online meetings and events are free and open to all. See our calendar for a full list: http://koha-us.org/calendar/. For Google Calendar users, add our events calendar to your list for easy access to meeting times and links: https://calendar.google.com/calendar/u/1?cid=a29oYS11cy5vcmdfZG1xb2pkczE5Zn… *Meetings* General Meeting - Wednesday, February 07 @ 8:30a PT / 11:30a ET / 15:30 UTC Board Meeting - Wednesday, February 14 @ 8:30a PT / 11:30a ET / 15:30 UTC *Special Interest Groups* Cataloging - Thursday, February 01 @ 8:00a PT / 11:00a ET / 15:00 UTC System Administration - Tuesday, February 13 @ 8:00a PT / 11:00a ET / 15:00 UTC Circulation - Thursday, February 8 @ 8:00a PT / 11:00a ET / 15:00 UTC Acquisitions - Tuesday, February 20 @ 9:00a PT / 12:00p ET / 16:00 UTC Web Development - Thursday, February 15 @ 10:00a PT / 1:00p ET / 17:00 UTC Consortia - Thursday, February 22 @ 9:00a PT / 12:00p ET / 16:00 UTC Demonstration Instance - on hiatus Visit http://koha-us.org/special-interest-groups/ to learn more and sign up for topic-specific mailing lists. Most meetings and events are recorded and made available at https://www.youtube.com/kohaus Kristi Krueger koha-US Secretary secretary(a)koha-US.org

1 0

TLS MySQL Connection Without Mutual Authentication
by Schetnan, Richard Reed 29 Jan '24

29 Jan '24

Hello, We've successfully connected our Koha site (version 22.11.12.000) to an Azure Database for MySQL flexible server without TLS encryption, but we've been unable to connect to the Azure MySQL database with TLS encryption enabled and required. The reason for this appears to be that Koha seems to require mutual TLS, which is not supported by the Azure MySQL database. According to the Microsoft documentation (https://learn.microsoft.com/en-us/azure/mysql/flexible-server/how-to-connec…) TLS clients use a public SSL CA certificate to allow for encrypted communication, and clients are authenticated at the server by usernames and passwords. This all works great from the MySQL command line interface. But in Koha, the koha-conf.xml configuration file calls for a CA certificate and also for client and client key certificates for client authentication with mutual TLS. This works for a local MySQL database but not for a remote Azure MySQL database because the Azure MySQL database does not provide a way to configure the CA certificate, server public key certificate, and server private key, which must be configured correctly for mutual TLS to work . Is there a way to connect to a remote MySQL database with TLS through the use of a CA certificate for encryption and username and password for authentication and without mutual TLS (that is, without the use of certificates and keys for authentication)? If not, can we put in a bug fix to enable and allow that functionality? Thanks! Richard

1 0

Koha Community Newsletter: January 2024
by Koha Newsletter 29 Jan '24

29 Jan '24

The Koha Community Newsletter for January 2024 is here: https://koha-community.org/koha-community-newsletter-january-2024/ 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