Re: [Koha-devel] Help! Plugin's API endpoint validation failing only on customer server
Have you looked at opac/svc/overdrive_proxy ? It doesn't do a POST, but it
does do some external api calls.
On Thu, Sep 9, 2021 at 8:52 AM Isherwood, Andrew <
andrew.isherw...@ptfs-europe.com> wrote:
> Hi
>
> I've been banging my head against this one for a few hours now, so I'm
> hoping someone can help!
>
> I've developed a Koha ILL backend for RapidILL for a customer. Part of
> the development was to create a plugin that provides Koha Rest API
> endpoints that effectively proxies to the RapidILL SOAP API.
> Everything works perfectly on my development server running
> koha-testing-docker
>
> However, on the customer's Koha instance, all API calls to the plugin
> fail validation with the following error:
>
> {
> "errors": [
> {
> "message": "Expected object - got null.",
> "path": "/body"
> }
> ],
> "status": 400
> }
>
> I'm pretty confident that my plugin and the requests I'm making to it
> are correct since everything works perfectly on my dev server, however
> the API spec is here
>
> https://github.com/PTFS-Europe/koha-plugin-rapidill/blob/main/Koha/Plugin/Com/PTFSEurope/RapidILL/openapi.json
>
> and a sample request body is:
>
> {
> "requestId": "17900139",
> "updateAction": "Cancel",
> "metadata": {
> "UpdateComment": "TEST PLEASE CANCEL REQUEST"
> }
> }
>
> The most annoying thing is that I've had this problem a few times
> before in the past and it's always come down to module dependency
> versions, though this time, I'm not sure this is the problem. I've
> aligned versions of the following modules on the customer's server to
> match the versions on my koha-testing-docker, these have been the
> problematic modules in the past. But still no luck:
>
> JSON - 2.90
> JSON::Validator - 3.14
> Mojolicious - 8.12
> Mojolicious::Plugin::OpenAPI - 2.16
>
> In an attempt to narrow it down, I've been trying to find somewhere
> else in Koha where a POST API call is made, but haven't found one, any
> idea?
>
> Does anyone have any suggestions where else I could try?
>
> Many thanks
> Andrew
> ---
> Andrew Isherwood
> Senior Software Engineer
>
> Email: andrew.isherw...@ptfs-europe.com
> www.ptfs-europe.com
>
> Registered in the United Kingdom No. 06416372 VAT Reg No. 925 7211 30
> The information contained in this email message may be privileged,
> confidential and protected from disclosure. If you are not the
> intended recipient, any dissemination, distribution or copying is
> strictly prohibited. If you think that you have received this email
> message in error, please email the sender at i...@ptfs-europe.com
> ___
> Koha-devel mailing list
> Koha-devel@lists.koha-community.org
> https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
> website : https://www.koha-community.org/
> git : https://git.koha-community.org/
> bugs : https://bugs.koha-community.org/
>
--
Michael Hafen
Washington County School District Technology Department
Systems Analyst
___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : https://www.koha-community.org/
git : https://git.koha-community.org/
bugs : https://bugs.koha-community.org/
Re: [Koha-devel] Best practices for using Koha APIs server-side by Koha
You've got me there, I wasn't even thinking about third-party services like OAI-PMH. My comment about avoiding auth is only really feasible for first-party or locally developed cli scripts. (I could say second-party there, but that's just silly.) Third-party services definitely need to authen, and probably authiz too. A message broker would be handy for that, where you probably have one set of credentials that are shared by any services talking on that queue. oAuth can do that too, but you'd have to build a way for the client id and secret to be stored by both services in lieu of a username and password. Which seems basically the same to me as having a username and password. On the one hand we'd have to build a connector between the message broker and the Koha api's. On the other hand we'd have to build oAuth access token handling into the existing api's. (where the appropriate api's already exist.) On Sun, Aug 9, 2020 at 7:00 PM wrote: > Hi Michael, > > > > Another case where a Koha to Koha API would be useful is in the use of > additional service (or microservices). At the moment, the SIP server is > closely coupled with Koha, but it could just as easily be a separate > component that used HTTP APIs (rather than internal Perl APIs) to work with > Koha. > > > > You could argue that you could avoid auth (although I don’t understand > your interpretation of MCV in this case), but that would be out of > convenience rather than security. You could argue that you just protect the > edges of your host (via a firewall for instance), but what about if that > service isn’t running on the same host? Then you need to open a hole in > that firewall. Then how do you protect that hole? Just using IP addresses > isn’t going to work very well. You’ll want to have authentication and > authorization, especially when your application is part of a larger > multi-vendor cloud ecosystem for instance. > > > > The particular use case I have in mind is for a OAI-PMH harvester service. > There could be 1 OAI-PMH harvester servicing many Koha instances. It could > be running in its own local Docker container or its own local virtual > machine or even as a remote Internet service controlled by a different > organisation. It’s only relation to Koha is in terms of accepting JSON > serialized harvesting requests and sending MARCXML records for Koha to > import. > > > > For integrating the services, we could use point-to-point (P2P) > communication via the HTTP APIs. That’s pretty much the only option we have > at the moment. However, Koha will be adding RabbitMQ as a Message Broker > (for a hub-and-spoke model), so Koha and the other services could have > their own credentials to authenticate against the Message Broker, and use > it for communication. Both models have their pros and cons. > > > > My current plan is to use > https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26170 to > provide more stable Koha users and > https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25905 to > provide an OAI-PMH ingestion endpoint to Koha. Then I’ll implement the > OAI-PMH harvester separate from Koha (with a Koha plugin initially to send > OAI-PMH harvesting requests to the OAI-PMH harvester service), which sends > downloaded records to the Koha API for the Koha that requested the harvest. > This approach will have some friction though. I’ll have to add a Koha user, > share the Koha user credentials to the OAI-PMH service, register the Koha > instance in the OAI-PMH service, and share the OAI-PMH credentials with > Koha. That process could be unnecessary using a Message Broker. Another > option would be to set up single sign on (SSO) with P2P where Koha and the > OAI-PMH service delegate AuthN (and even potentially AuthZ) to an identity > provider. That would make things smoother but also more complicated. > > > > If I wanted to more tightly integrate with Koha, I suppose I could create > a koha-oaipmh CLI tool which automates the user creation and credential > sharing I suppose. > > > > The other benefit of using the Message Broker is that you don’t have to > manage IP addresses and ports. I should look at the koha-sip tool again, > but I don’t know how it handles setting up different ports for each > different Koha instance. > > > > In any case, I’m keen to get input from others on system design. On one > hand, I’d like something that easily works for everyone, and on the other > hand I’d like something that works really well. > > > > David Cook > > Systems Librarian > > Prosentient Systems > > 72/330 Wattle St > > Ultimo, NSW 2007 > > Australia > > > > Office: 02 9212 0899 > > Online: 02 8005 0595 > > > > *From:* Michae
Re: [Koha-devel] Best practices for using Koha APIs server-side by Koha
Maybe I'm lacking in imagination, but I can only think of two cases where a
Koha to Koha api would be useful: scheduled tasks (cron, et. all), and
command line scripts. I think in both of these cases it's feasible to
avoid auth entirely since it is basically jumping right into Koha at the
control level (assuming an MCV approach). As someone who has a deployment
of Koha heavily dependent on IndependentBranches mode, I find I have to
watch for %userenv{branch}, but that's for rare cases in which branch can't
be taken from the data being operated on. The only other thing I can think
of would be something like notices wanting to take a user's preferred
language, and pull a language specific template (do we even do that at this
point?).
Please enlighten me on your use cases, I'm probably missing something.
On Fri, Aug 7, 2020 at 5:09 AM wrote:
> 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
>
>
> ___
> Koha-devel mailing list
> Koha-devel@lists.koha-community.org
> https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
> website : http://www.koha-community.org/
> git : http://git.koha-community.org/
> bugs : http://bugs.koha-community.org/
>
--
Michael Hafen
Washington County School District Technology Department
Systems Analyst
___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/
Re: [Koha-devel] ModBiblio function error
Well, unless your script tries to update the zebra index after changing the biblio, as opposed to adding the record to the zebraqueue table, then I don't know where that error comes from. Zebra index updates are usually handled by another process reading from the zebraqueue table I think. So that shouldn't be throwing an error in your script. On Thu, Jul 30, 2020 at 1:13 PM Stephen Graham wrote: > Oh yes, sorry, forgot to say - we use Zebra not elasticsearch. > > > > Stephen > > > > *From:* Michael Hafen (TECH) > *Sent:* 30 July 2020 20:08 > *To:* Stephen Graham > *Cc:* koha-devel > *Subject:* Re: [Koha-devel] ModBiblio function error > > > > I don't know. I don't use authorities either, and my Koha is set to > "allow" authorities. I'm not sure what side-effects changing that setting > will have. > > Related, it seems that your search engine (elasticsearch) doesn't have a > database for authorities. I thought the default was for it to have one, > but I could be wrong about that. You can try not allowing automatic > authorities, or you can add a database for authorities. I'd recommend the > latter unless this isn't a production server. > > > > On Thu, Jul 30, 2020 at 12:54 PM Stephen Graham > wrote: > > Thanks for the reply Michael. We did have the BiblioAddsAuthorities sys > pref set to allow. I changed to don’t allow, and now my script doesn’t > generate the error. Hm…. We are not using authorities so I guess it’s > OK keep this set to “don’t allow”? > > > > Stephen > > > > *From:* Michael Hafen (TECH) > *Sent:* 30 July 2020 18:56 > *To:* Stephen Graham > *Cc:* koha-devel > *Subject:* Re: [Koha-devel] ModBiblio function error > > > > I did a quick look over the code. > > > > If your searchengine is set to Elasticsearch, then when ModZebra() is > called it tries to index the record in the background at that time (at > least that's the way it reads to me, I could be wrong). > > Also if you have the BiblioAddsAuthorities preference set, then ModBiblio > calls BiblioAutoLink() to update authorities links, which will create an > authority record if the AutoCreateAuthorities preference is set, which > calls AuthorityMarc::AddAuthority(), which calls ModZebra(). > > > > The error to me looks like it's trying to contact the search engine to > add/update an authority record, and can't find it. But you have to have a > lot of system preferences set just so to get that far. So I'm not sure > that's what's happening. > > > > On Thu, Jul 30, 2020 at 4:46 AM Stephen Graham > wrote: > > Hi All – I have a script which uses the ModBiblio function (i.e. > https://perldoc.koha-community.org/19.11.x/C4/Biblio.html#ModBiblio). I > haven’t used the script for a while, and we’ve upgraded to 19.11 since I > ran it last. Running the script today and I’m getting the following “error”: > > > > oAuth error: Database unavailable (109) authorities Bib-1 > > > > I’m seeing this 4-5 times for each bibilo I’ve updated. The update does > work. The record looks fine in staff/OPAC, it’s findable etc. I’ve only > updated 10 records on our test server, and before I update any more I’m > just wondering why I’m getting this message and it will have an adverse > effect on our indexing/database if I just ignore and update the reamining > 6000+ records? > > > > Any advice would be most welcome! > > > > Cheers, Stephen > > > > -- > > Stephen Graham > > Library Technology Consultant > > Content and Collections Team > > Library and Computing Services > > University of Hertfordshire > > Tel: 01707 286111 > > Ext: 77751 > > Email: s.grah...@herts.ac.uk > > > > ___ > Koha-devel mailing list > Koha-devel@lists.koha-community.org > https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel > website : http://www.koha-community.org/ > git : http://git.koha-community.org/ > bugs : http://bugs.koha-community.org/ > > > > -- > > Michael Hafen > > Washington County School District Technology Department > > Systems Analyst > > > > -- > > Michael Hafen > > Washington County School District Technology Department > > Systems Analyst > -- Michael Hafen Washington County School District Technology Department Systems Analyst ___ Koha-devel mailing list Koha-devel@lists.koha-community.org https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
Re: [Koha-devel] ModBiblio function error
I don't know. I don't use authorities either, and my Koha is set to "allow" authorities. I'm not sure what side-effects changing that setting will have. Related, it seems that your search engine (elasticsearch) doesn't have a database for authorities. I thought the default was for it to have one, but I could be wrong about that. You can try not allowing automatic authorities, or you can add a database for authorities. I'd recommend the latter unless this isn't a production server. On Thu, Jul 30, 2020 at 12:54 PM Stephen Graham wrote: > Thanks for the reply Michael. We did have the BiblioAddsAuthorities sys > pref set to allow. I changed to don’t allow, and now my script doesn’t > generate the error. Hm…. We are not using authorities so I guess it’s > OK keep this set to “don’t allow”? > > > > Stephen > > > > *From:* Michael Hafen (TECH) > *Sent:* 30 July 2020 18:56 > *To:* Stephen Graham > *Cc:* koha-devel > *Subject:* Re: [Koha-devel] ModBiblio function error > > > > I did a quick look over the code. > > > > If your searchengine is set to Elasticsearch, then when ModZebra() is > called it tries to index the record in the background at that time (at > least that's the way it reads to me, I could be wrong). > > Also if you have the BiblioAddsAuthorities preference set, then ModBiblio > calls BiblioAutoLink() to update authorities links, which will create an > authority record if the AutoCreateAuthorities preference is set, which > calls AuthorityMarc::AddAuthority(), which calls ModZebra(). > > > > The error to me looks like it's trying to contact the search engine to > add/update an authority record, and can't find it. But you have to have a > lot of system preferences set just so to get that far. So I'm not sure > that's what's happening. > > > > On Thu, Jul 30, 2020 at 4:46 AM Stephen Graham > wrote: > > Hi All – I have a script which uses the ModBiblio function (i.e. > https://perldoc.koha-community.org/19.11.x/C4/Biblio.html#ModBiblio). I > haven’t used the script for a while, and we’ve upgraded to 19.11 since I > ran it last. Running the script today and I’m getting the following “error”: > > > > oAuth error: Database unavailable (109) authorities Bib-1 > > > > I’m seeing this 4-5 times for each bibilo I’ve updated. The update does > work. The record looks fine in staff/OPAC, it’s findable etc. I’ve only > updated 10 records on our test server, and before I update any more I’m > just wondering why I’m getting this message and it will have an adverse > effect on our indexing/database if I just ignore and update the reamining > 6000+ records? > > > > Any advice would be most welcome! > > > > Cheers, Stephen > > > > -- > > Stephen Graham > > Library Technology Consultant > > Content and Collections Team > > Library and Computing Services > > University of Hertfordshire > > Tel: 01707 286111 > > Ext: 77751 > > Email: s.grah...@herts.ac.uk > > > > ___ > Koha-devel mailing list > Koha-devel@lists.koha-community.org > https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel > website : http://www.koha-community.org/ > git : http://git.koha-community.org/ > bugs : http://bugs.koha-community.org/ > > > > -- > > Michael Hafen > > Washington County School District Technology Department > > Systems Analyst > -- Michael Hafen Washington County School District Technology Department Systems Analyst ___ Koha-devel mailing list Koha-devel@lists.koha-community.org https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
Re: [Koha-devel] ModBiblio function error
I did a quick look over the code. If your searchengine is set to Elasticsearch, then when ModZebra() is called it tries to index the record in the background at that time (at least that's the way it reads to me, I could be wrong). Also if you have the BiblioAddsAuthorities preference set, then ModBiblio calls BiblioAutoLink() to update authorities links, which will create an authority record if the AutoCreateAuthorities preference is set, which calls AuthorityMarc::AddAuthority(), which calls ModZebra(). The error to me looks like it's trying to contact the search engine to add/update an authority record, and can't find it. But you have to have a lot of system preferences set just so to get that far. So I'm not sure that's what's happening. On Thu, Jul 30, 2020 at 4:46 AM Stephen Graham wrote: > Hi All – I have a script which uses the ModBiblio function (i.e. > https://perldoc.koha-community.org/19.11.x/C4/Biblio.html#ModBiblio). I > haven’t used the script for a while, and we’ve upgraded to 19.11 since I > ran it last. Running the script today and I’m getting the following “error”: > > > > oAuth error: Database unavailable (109) authorities Bib-1 > > > > I’m seeing this 4-5 times for each bibilo I’ve updated. The update does > work. The record looks fine in staff/OPAC, it’s findable etc. I’ve only > updated 10 records on our test server, and before I update any more I’m > just wondering why I’m getting this message and it will have an adverse > effect on our indexing/database if I just ignore and update the reamining > 6000+ records? > > > > Any advice would be most welcome! > > > > Cheers, Stephen > > > > -- > > Stephen Graham > > Library Technology Consultant > > Content and Collections Team > > Library and Computing Services > > University of Hertfordshire > > Tel: 01707 286111 > > Ext: 77751 > > Email: s.grah...@herts.ac.uk > > > ___ > Koha-devel mailing list > Koha-devel@lists.koha-community.org > https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel > website : http://www.koha-community.org/ > git : http://git.koha-community.org/ > bugs : http://bugs.koha-community.org/ > -- Michael Hafen Washington County School District Technology Department Systems Analyst ___ Koha-devel mailing list Koha-devel@lists.koha-community.org https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
Re: [Koha-devel] Alerting users to breaking changes / backwards incompatibility
What about the upgrade offering to add a news entry to the staff interface? I'm all for using existing functions :) On Wed, May 27, 2020 at 6:23 PM wrote: > Oh great. I don’t think I’ve seen that? > > > > David Cook > > Systems Librarian > > Prosentient Systems > > 72/330 Wattle St > > Ultimo, NSW 2007 > > Australia > > > > Office: 02 9212 0899 > > Online: 02 8005 0595 > > > > *From:* Tomas Cohen Arazi > *Sent:* Thursday, 28 May 2020 9:53 AM > *To:* David Cook > *Cc:* koha-devel > *Subject:* Re: [Koha-devel] Alerting users to breaking changes / > backwards incompatibility > > > > We already do something similar with the biblio_metadata table. > > > > El mié., 27 de mayo de 2020 20:35, escribió: > > Hi all, > > > > I was just thinking how a lot of SQL reports will return unexpected > results when we merge the deleted* tables with their live/active > counterparts. > > > > What do people think about a modal popup in the reports (on a per user > basis) alerting them to how they may need to update their reports following > an upgrade which changes reporting behaviour? > > I’m not 100% sure how we’d do it, but it’s something we could re-use > through much of the Koha staff client. > > > > Or maybe we could raise a flag in the borrower row during an upgrade, and > when they log into the staff client, they’re presented with a “You need to > know…” kind of page. After all, users aren’t going to be reading release > notes, and sysadmins doing upgrades aren’t necessarily going to do the best > job communicating to every single staff user about what they need to know > in an upgrade. > > > > But that’s easier said than done too, especially when you’re upgrading > past multiple versions. > > > > Anyway, just putting it out there. As you can see, I haven’t thought about > it too deeply yet. > > > > David Cook > > Systems Librarian > > Prosentient Systems > > 72/330 Wattle St > > Ultimo, NSW 2007 > > Australia > > > > Office: 02 9212 0899 > > Online: 02 8005 0595 > > > > ___ > Koha-devel mailing list > Koha-devel@lists.koha-community.org > https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel > website : http://www.koha-community.org/ > git : http://git.koha-community.org/ > bugs : http://bugs.koha-community.org/ > > ___ > Koha-devel mailing list > Koha-devel@lists.koha-community.org > https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel > website : http://www.koha-community.org/ > git : http://git.koha-community.org/ > bugs : http://bugs.koha-community.org/ > -- Michael Hafen Washington County School District Technology Department Systems Analyst ___ Koha-devel mailing list Koha-devel@lists.koha-community.org https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
Re: [Koha-devel] problem with sudo a2enmod mpm_itk
Well, I don't understand your server then, I guess. We will need to know which linux distribution you are using, and how you have installed Koha. I'm a little behind on Koha too, so maybe some of the others could speak to how important having mpm_itk enabled is. I suppose it's for making the server more secure, and you can do without it if necessary, but I could be wrong about that. On Tue, Apr 21, 2020 at 4:46 PM Christian Calle Jahuira < christian...@gmail.com> wrote: > > 134/5000 > Thank you > Correctly install #apt install libapache2-mpm-itk > > and the error continues > > ERROR: Module mpm_itk does not exist! > > thanks. > > > El mar., 21 abr. 2020 a las 18:36, Michael Hafen (TECH) (< > michael.ha...@washk12.org>) escribió: > >> Installing the itk module package should solve that problem. A command >> like `apt install libapache2-mpm-itk` should do the trick. >> >> On Tue, Apr 21, 2020 at 4:25 PM Christian Calle Jahuira < >> christian...@gmail.com> wrote: >> >>> >>> Hello >>> >>> Friends, I encountered the following error while executing: >>> >>> # sudo koha-create --create-db biblio >>> >>> I execute >>> >>> #sudo a2enmod mpm_itk >>> >>> ERROR: Module mpm_itk does not exist! >>> >>> Can anybody help me. >>> >>> Thank you.. >>> >>> >>> -- >>> Christian Jhonny Calle Jahuira >>> Consultor de Sistemas de Informacion >>> Ingeniero de Sistemas - Bibliotecologia >>> Email: christian...@gmail.com >>> Cel: 61131611 >>> ___ >>> Koha-devel mailing list >>> Koha-devel@lists.koha-community.org >>> https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel >>> website : http://www.koha-community.org/ >>> git : http://git.koha-community.org/ >>> bugs : http://bugs.koha-community.org/ >>> >> >> >> -- >> Michael Hafen >> Washington County School District Technology Department >> Systems Analyst >> >> > > -- > Christian Jhonny Calle Jahuira > Consultor de Sistemas de Informacion > Ingeniero de Sistemas - Bibliotecologia > Email: christian...@gmail.com > Cel: 61115844 > -- Michael Hafen Washington County School District Technology Department Systems Analyst ___ Koha-devel mailing list Koha-devel@lists.koha-community.org https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
Re: [Koha-devel] problem with sudo a2enmod mpm_itk
Installing the itk module package should solve that problem. A command like `apt install libapache2-mpm-itk` should do the trick. On Tue, Apr 21, 2020 at 4:25 PM Christian Calle Jahuira < christian...@gmail.com> wrote: > > Hello > > Friends, I encountered the following error while executing: > > # sudo koha-create --create-db biblio > > I execute > > #sudo a2enmod mpm_itk > > ERROR: Module mpm_itk does not exist! > > Can anybody help me. > > Thank you.. > > > -- > Christian Jhonny Calle Jahuira > Consultor de Sistemas de Informacion > Ingeniero de Sistemas - Bibliotecologia > Email: christian...@gmail.com > Cel: 61131611 > ___ > Koha-devel mailing list > Koha-devel@lists.koha-community.org > https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel > website : http://www.koha-community.org/ > git : http://git.koha-community.org/ > bugs : http://bugs.koha-community.org/ > -- Michael Hafen Washington County School District Technology Department Systems Analyst ___ Koha-devel mailing list Koha-devel@lists.koha-community.org https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
