Re: [Koha] How to measure and improve Koha performance for our

[dcook]

Hi Mike,

Great to see another Australian library using Koha!

Regarding performance, I'd say the answer is "it depends". 

It looks like you're running Debian Buster (based on your Apache response), so 
I'm guessing you used the Debian packages to install Koha? I thought that new 
instances created this way used Plack out of the box, but I think I might be 
mistaken...

If you enable Plack/Starman, page loads and search times will be faster, 
because the application code is run in persistent processes that use 
pre-loading and caching of code. However, that comes at a cost. In practice, I 
find each Plack/Starman process reserves about 200-500MB RAM over its lifetime 
(default 50 requests before it's recycled if I recall correctly), and the 
default Koha configuration uses 2 Plack/Starman processes. Depending on 
expected usage, you may want more/fewer Plack/Starman processes. (Note that 
those processes are shared across the Staff Interface and the OPAC.) Overall, 
enabling Plack is the best way to improve Koha performance. At some point in 
the future, we hope to get rid of CGI support for Koha, but that's a long 
story. (Note that static assets like Javascript, CSS, images, etc are still 
served by Apache when Plack/Starman is enabled as Apache is much more efficient 
at serving those files.) (Another thing to note is startup for Plack/Starman 
processes are CPU resource heavy as a lot of work goes into setting up and 
verifying the REST API.)

I think Memcached might technically be optional, but you'll want to keep it for 
performance. Without it, performance would certainly degrade.

Overall, I'd say the more CPUs the better, especially if you're running your 
database on the same server. 

In terms of metrics, you can use third-party log analyzers (for the Apache 
logs) and web analytics (eg Google Analytics) to get an overview of how the 
application is performing overall. For more targeted analysis, I tend to just 
use the Developer Tools in the browser. For instance, I see your OPAC is taking 
about 4 seconds to serve the homepage. I tried one of the instances I manage 
(on a high specced server using Plack) and it took 333ms. There are other tools 
you can use for profiling the application, but that's a something you might 
want to explore with the "koha-devel" list instead. 

More reading: https://lists.katipo.co.nz/public/koha/2020-December/055598.html

I haven't used Linode so I can't really comment on its features, but other 
platforms like AWS make it very easy to switch between different CPU and RAM 
sizes. 

I'd say your first step is to enable Plack (on your test instance), and just 
manually compare similar web requests (like loading the home page, performing 
the same catalogue search). You should already have the RAM to handle it. I 
could see you getting into strife only having 1 CPU, as that 1 CPU would have a 
lot of work to do, but that's where the log analysis / web analytics can help 
you see real life usage. 

I hope that helps. Feel free to send more questions. 

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

-Original Message-
Date: Fri, 14 Jan 2022 16:04:11 +1100
From: Mike Lake 
To: Koha 
Subject: [Koha] How to measure and improve Koha performance for our
instance?
Message-ID: 
Content-Type: text/plain; charset=US-ASCII; format=flowed

Hi all

We have a production library setup at https://opac.caves.org.au and its now 
ready for users to use. We also have a test instance that can be used for 
testing. I'm wanting to know the options for measuring and improving the 
performance - just basic load and search time that users perceive.

Currently we are running on a Linode instance with 1 CPU and 2 GB RAM. 
Yes it's a small library :-) Looking at Linode Longview it shows we have not 
hit more than 7% CPU usage and it usually sits at 1% CPU and 670 MB mem when 
idle. During a query cpu goes to 100% for a short period and mem to ~ 1 GB.

I see in htop that several memcache threads are running. That's now installed 
automatically with Koha? The wiki seems to suggest that its optional. And there 
is plack mentioned in the wiki. Should we be running plack?

I can double our Linode instance to 2 CPUs and 4 GB RAM but that's possibly an 
irreversible change (and double the $) so wish to leave that until I know it 
would make a significant difference. And how could I quantify that performance 
increase?

Thanks

--
Mike


___

Koha mailing list  http://koha-community.org
Koha@lists.katipo.co.nz
Unsubscribe: https://lists.katipo.co.nz/mailman/listinfo/koha

Re: [Koha] Koha with Centos7

[dcook]

Hey Russel,

If you have to use Centos7, you might consider using Docker to run Koha in a 
Debian or Ubuntu container, since Docker should be available in Centos7. While 
running Koha in Docker isn't officially supported by the community, it is a 
potential solution. You would need to be skilled with Docker to know how to set 
it up on your own though. 

Just thought I'd share that in any case. 

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

-Original Message-
Message: 3
Date: Mon, 22 Nov 2021 21:45:54 +0200
From: "Russel G. P. Shihepo" 
To: Michael Kuhn 
Cc: koha@lists.katipo.co.nz
Subject: Re: [Koha] Koha with Centos7
Message-ID:

Content-Type: text/plain; charset="UTF-8"

Hi

Thank you very much, this was helpful.

Regards
Russel



___

Koha mailing list  http://koha-community.org
Koha@lists.katipo.co.nz
Unsubscribe: https://lists.katipo.co.nz/mailman/listinfo/koha

Re: [Koha] Searching databases from the Koha Library Catalogue

[dcook]

Hi Lizelle,

Thanks for reaching out. 

That's a big question, and there are a lot of different answers, depending on 
your situation.

One option is to get your database vendor to supply you with MARC records that 
you can import into your Koha. 

Depending on who provides your database content, they might provide a 
"discovery layer" that provides access to their database content (both EBSCO 
and Ovid do this), and then you can set up your Koha's OAI-PMH server to export 
MARC records, so that the database vendor can import your records into their 
search system. (There is also a Koha Plugin which lets you search EBSCO's EDS 
system from Koha itself.)

There are other more self-service "discovery layers" out there as well (like 
VuFind and Blacklight and Aspen Discovery) where you import the MARC records 
from Koha and those database providers. 

Koha also has integrations with services like OverDrive which can show results 
in the search results itself.

Depending on your situation, there might be some other potential solutions too. 

I hope that helps. Feel free to get in touch if you need more help.

Cheers,

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

-Original Message-

Message: 1
Date: Thu, 22 Jul 2021 10:43:19 +0800 (AWST)
From: "L. Smith" 
To: Koha , Koha
,  kohasupport 
Subject: [Koha] Searching databases from the Koha Library Catalogue
(OPAC)
Message-ID:
<80326687.6566.1626921799410.javamail.zim...@sheridan.edu.au>
Content-Type: text/plain; charset=utf-8

Good morning, 

I need some assistance please. 

How can we make the Koha Library Catalogue (OPAC) searchable for our staff and 
students so that all database content (purchased) can be retrieved/accessed? 

Thank you for your assistance. 

Best wishes, 





Lizelle Smith 

BA, AdvDipTour, DipLib, AALIA DCP 

Director of Library and Information Services 




Suite 18, 7 Aberdeen Street, Perth WA 6000 

PO Box D178 Perth BC 6849 



T: [ callto:+61 8 6222 4222 | +61 8 6222 4222 ] 

E: lsm...@sheridan.edu.au l W: [ http://www.sheridan.edu.au/ | 
www.sheridan.edu.au ] 



CRICOS No: 03391M. This email and any attachments may be confidential. If you 
are not the intended recipient, please inform the sender by reply email and 
delete all copies of this message . 



___

Koha mailing list  http://koha-community.org
Koha@lists.katipo.co.nz
Unsubscribe: https://lists.katipo.co.nz/mailman/listinfo/koha

Re: [Koha] Koha Concurrent and Simultaneous Use of Records

[dcook]

Hi Charles,

 

No worries. I wish you well with your cloud migration.

 

David Cook

Software Engineer

Prosentient Systems

Suite 7.03

6a Glen St

Milsons Point NSW 2061

Australia

 

Office: 02 9212 0899

Online: 02 8005 0595

 

From: Charles Kelley  
Sent: Friday, 9 July 2021 11:33 AM
To: dc...@prosentient.com.au
Cc: Discussion Group Koha 
Subject: Re: [Koha] Koha Concurrent and Simultaneous Use of Records

 

Hi, David!

 

In our latest exchange, on 9 July 2021 at 9:42 [JST], I received from you:

 

Koha uses the "The ever popular do-nothing-approach".

In theory, this is problematic and certainly bothers me, but in practice I 
think it's fairly rare that two staff members are working on the same record at 
the same time. Locking and lock timeouts come with a lot of complexity, and I 
think the majority of libraries would actually prefer risk accidental 
overwrites rather than lock contention and session timeouts.

I would love to see a locking feature added, but I don't know if it's anyone's 
priority at the moment. 

 

It's disappointing that there doesn't seem to be a locking feature in Koha. 
At least in practice, simultaneous use of records is rare or less frequent in 
my library. But there was an incident last week when a locking feature would 
have been useful, it occurred to me in retrospect. I too thought of locking 
timeouts. After all, I wouldn't want a record to be locked after hours and 
hours of disuse.

 

I guess I'll be filing another feature request if such a request is not 
already on file.

 

Thanks for the response.


-- 

 

気を付けて。 /ki wo tukete/ = Take care.

 

-- Charles.

 

Charles Kelley, MLS

PSC 704 Box 1029

APO AP 96338

 

Charles Kelley
Tsukimino 1-Chome 5-2

Tsukimino Gaadenia #210

Yamato-shi, Kanagawa-ken

〒242-0002 JAPAN

 

+1-301-741-7122 [US cell]

+81-80-4356-2178 [JPN cell]

 

mnogoja...@aol.com   [h]

cmkelley...@gmail.com   [p]


linkedin.com/in/cmkelleymls  

Meeting Your Information Needs. Virtually.

___

Koha mailing list  http://koha-community.org
Koha@lists.katipo.co.nz
Unsubscribe: https://lists.katipo.co.nz/mailman/listinfo/koha

Re: [Koha] Koha Concurrent and Simultaneous Use of Records

[dcook]

Hi Charles,

Koha uses the "The ever popular do-nothing-approach".

In theory, this is problematic and certainly bothers me, but in practice I 
think it's fairly rare that two staff members are working on the same record at 
the same time. Locking and lock timeouts come with a lot of complexity, and I 
think the majority of libraries would actually prefer risk accidental 
overwrites rather than lock contention and session timeouts.

I would love to see a locking feature added, but I don't know if it's anyone's 
priority at the moment. 

David Cook
Software Engineer
Prosentient Systems
Suite 7.03
6a Glen St
Milsons Point NSW 2061
Australia

Office: 02 9212 0899
Online: 02 8005 0595

-Original Message-
Date: Fri, 9 Jul 2021 07:23:55 +0900
From: Charles Kelley 
To: Discussion Group Koha 
Subject: [Koha] Koha Concurrent and Simultaneous Use of Records
Message-ID:

Content-Type: text/plain; charset="UTF-8"

Hi, all!

My library is preparing to migrate our Koha ILSA to the cloud. For reasons 
I shan't bore everyone with, I have a question about simultaneous and 
concurrent use of records: What happens if two or more parties try to access a 
bib. record or patron record at the same time?

In my experience with other ILSs, there are several ways to handle such 
simultaneous use:

   - To lock the record when the first record accesses and queue up the
   rest for access in succession.
  - Party 1 works on the record and finishes -- the record is released.
  Every other party is blocked until the record is released.
  - Party 2 then works on the record and finishes -- the record is
  released. Every other party is blocked until the record is released.
  - Party 3 then works on the record and finishes -- the record is
  released. Every other party is blocked until the record is released.


   - To timestamp changes and then incorporate the changes based on the
   timestamp of the changes in a queued batch operation. A risk of data
   corruption.


   - The ever popular do-nothing-approach: to let multiple parties work on
   the same record simultaneously in real time, incorporating changes as they
   are submitted in real; another risk of data corruption.

So if I may repeat my question: How does Koha handle simultaneous use of 
records?

Many thanks, everyone!

-- 

気を付けて。 /ki wo tukete/ = Take care.

-- Charles.

Charles Kelley, MLS
PSC 704 Box 1029
APO AP 96338

Charles Kelley
Tsukimino 1-Chome 5-2
Tsukimino Gaadenia #210
Yamato-shi, Kanagawa-ken
〒242-0002 JAPAN

+1-301-741-7122 [US cell]
+81-80-4356-2178 [JPN cell]

mnogoja...@aol.com [h]
cmkelley...@gmail.com [p]

linkedin.com/in/cmkelleymls 
Meeting Your Information Needs. Virtually.



___

Koha mailing list  http://koha-community.org
Koha@lists.katipo.co.nz
Unsubscribe: https://lists.katipo.co.nz/mailman/listinfo/koha

Re: [Koha] Authority records vie OAI-PMH

[dcook]

Hi Michal,

At the moment, Koha only provides MARC bibliographic records via OAI-PMH, but I 
am intrigued by the prospect of providing authority records. 

I think we'd probably have to provide a new endpoint for that though, as I 
don't think we could make the current endpoint backwards compatible for 
existing users.

David Cook
Software Engineer
Prosentient Systems
Suite 7.03
6a Glen St
Milsons Point NSW 2061
Australia

Office: 02 9212 0899
Online: 02 8005 0595

-Original Message-
Date: Mon, 28 Jun 2021 22:31:57 +0200
From: "Mike D." 
To: koha 
Subject:
Message-ID:

Content-Type: text/plain; charset="UTF-8"

Greetings to the community,
I would like to ask if Koha can also issue authority records via the OAI
set. I have searched the documentation but everywhere it only mentions
biblio records? Does anyone have experience with this?

Thank you for the information

Michal



___

Koha mailing list  http://koha-community.org
Koha@lists.katipo.co.nz
Unsubscribe: https://lists.katipo.co.nz/mailman/listinfo/koha

Re: [Koha] Identifying Records with Non-Roman Characters

[dcook]

Hi Charles,

I'm not 100% sure what you're asking here. Are you asking to find all records 
where there is a 245 title that isn't Romanized? 

You could try something like this:
SELECT *
  FROM biblio
 WHERE title <> CONVERT(title USING latin1);

I've tried that out on one of my multilingual libraries and it had some decent 
results. 

However, it's worth noting that it isn't a perfect solution. There are certain 
characters (I've noticed a particular hyphen) that won't have a latin1 
equivalent, but they'd still be "Roman" (like hyphen which is made of the 
hexadecimal bytes E2 80 90, but is not to be confused with hyphen-minus which 
is ASCII and represented by the byte 2D). Other examples are emoji and other 
symbols like ↔️.  

You could then tweak the query or do a visual scan through to filter out any 
results that are irrelevant.

Anyway, I hope that helps you advance your work.

David Cook
Software Engineer
Prosentient Systems
Suite 7.03
6a Glen St
Milsons Point NSW 2061
Australia

Office: 02 9212 0899
Online: 02 8005 0595

-Original Message-
Date: Mon, 7 Jun 2021 09:53:24 +0900
From: Charles Kelley 
To: Discussion Group Koha 
Subject: [Koha] Identifying Records with Non-Roman Characters
Message-ID:

Content-Type: text/plain; charset="UTF-8"

Hello, all!

Our catalog has 8766 records that lack the 880 field for non-Roman titles. 
Examples:

=245  10$aВеликая отецественная война 1941-1945 /$cВ. И. Чуйков
=246  11$a Velikaia otechestvennaia voina 1941-1945

=245  10$a英汉常用物理学小词典 /$cYing Li, Lian Wei
=246  11$aYing-Han changyong wulixue xiaocidian

Of those, a significant portion is in Cyrillic, CJK, Greek, etc. Is there a 
way in either Koha or MarcEdit to isolate said records? The problem is to turn 
the 245 into 880, turn the 246 into 245 fields and then pair the resulting 880 
and the new 245 into something like

=880  10$6245-45/(N$aВеликая отецественная война 1941-1945 /$cВ. И. Чуйков.
=245  10$6880-45$aVelikaia otechestvennaia voina, 1941-1945.

=880  10$6245-45/[dollar]1$a英汉常用物理学小词典 /$cYing Li, Lian Wei.
=245  10$6880-45$aYing-Han changyong wulixue xiaocidian.

The indicators are easy to fix after the 245 and 880 fields are 
reconstructed. The 245 $c subfield can be copied from the 880 $c subfield.
I'm just trying to automate the process as much as possible and thereby avoid 
the painstaking manual corrections if they can be avoided.

This is an interim step. Eventually the catalog will have to be recataloged 
from scratch, I think.

Many thanks, all!

-- 

気を付けて。 /ki wo tukete/ = Take care.

-- Charles.

Charles Kelley, MLS
PSC 704 Box 1029
APO AP 96338

Charles Kelley
Tsukimino 1-Chome 5-2
Tsukimino Gaadenia #210
Yamato-shi, Kanagawa-ken
〒242-0002 JAPAN

+1-301-741-7122 [US cell]
+81-80-4356-2178 [JPN cell]

mnogoja...@aol.com [h]
cmkelley...@gmail.com [p]

linkedin.com/in/cmkelleymls 
Meeting Your Information Needs. Virtually.


___

Koha mailing list  http://koha-community.org
Koha@lists.katipo.co.nz
Unsubscribe: https://lists.katipo.co.nz/mailman/listinfo/koha

Re: [Koha] Koha API - Authentication Failure

[dcook]

That KohaRest driver looks interesting!

I haven't dug into it too deeply, but how do you handle the user/patron 
authentication? Do you have the user log into VuFind and at that point you use 
the backend confidential client user to validate it via your plugin API 
endpoint? Have you thought about using SSO between VuFind and Koha? I suppose 
even then you'd still have to do a user lookup against Koha unless there is an 
attribute/claim containing their borrowernumber... 

I'd love to see the core REST API replace the ILS-DI API for discovery 
services...

David Cook
Software Engineer
Prosentient Systems
Suite 7.03
6a Glen St
Milsons Point NSW 2061
Australia

Office: 02 9212 0899
Online: 02 8005 0595

-Original Message-
Date: Wed, 19 May 2021 11:49:48 +0300
From: Ere Maijala 
To: koha@lists.katipo.co.nz
Subject: Re: [Koha] Koha API - Authentication Failure
Message-ID: <82f7fb00-a4da-fcaa-3431-3fe58d12f...@helsinki.fi>
Content-Type: text/plain; charset=utf-8; format=flowed

My documented steps to make sure OAuth2 is working are here:

https://github.com/vufind-org/vufind/blob/dev/config/vufind/KohaRest.ini#L20

This may be useful for you. I suppose it would make sense to document this 
properly in Koha wiki as well, I just haven't had time...

Best,
Ere

Aswin Unnikrishnan kirjoitti 17.5.2021 klo 20.53:
> Thanks for pointing that out Stephen, I will have to look into that, 
> it might be the issue here.
> 
> Tomas, I am not exactly sure if we have plack running or not.  Plack 
> seems to be enabled, but plack logs are all empty. the logs are all at 
> intranet-error.log and opac-error.log
> 
> I will try out the apache CGIPass method as Stephen suggested and get 
> back if it works.
> 
> Thanks,
> Aswin
> 
> On Mon, May 17, 2021, 9:02 PM Tomas Cohen Arazi 
> wrote:
> 
>> Are you running Plack?
>>
>> El lun, 17 may 2021 a las 11:53, Aswin Unnikrishnan (<
>> aswinunn...@gmail.com>) escribió:
>>
>>> Thanks Stephen, Tomas for the quick response.
>>>
>>> Aswin - are you using the correct URL to call your custom endpoint. 
>>> It
 should be under the contrib namespace e.g.

>>>
>>> The app i am making is not part of koha, its a seperate web app 
>>> which makes calls to /api/v1/ end points of the koha server.
>>>
>>> Does the user (owner of the id/secret pair) have privileged access 
>>> to
 Koha? Remember it needs to have permissions to enter the staff 
 interface (the 'catalogue' permission) in order to access routes 
 (other than those in the /api/v1/public namespace).

>>> Yes, the user has permission set to access all librarian functions, 
>>> I also tried accessing the api end point via browser after logging 
>>> in to the staff portal with this user, and im getting the correct response.
>>>
>>> Im also not able to access api/v1/.html from the browser, it gives a 
>>> 403 Error page. I checked the error logs and found this
>>>
>>> [authz_core:error] [pid 25846]  AH01630: client denied by server
 configuration: /usr/share/koha/api/v1/.html

>>>
>>>
>>> Is there any logging systems in place which could give more info 
>>> regarding the authorization failure error? or any idea whats wrong?
>>>
>>> Thanks,
>>> Aswin
>>>
>>>
>>> On Mon, 17 May 2021 at 19:13, Tomas Cohen Arazi 
>>> 
>>> wrote:
>>>
 Does the user (owner of the id/secret pair) have privileged access 
 to Koha? Remember it needs to have permissions to enter the staff 
 interface (the 'catalogue' permission) in order to access routes 
 (other than those in the /api/v1/public namespace).

 BTW: All routes also have some required permissions you should take 
 a look at. Specific ones.

 Kind regards

 El lun, 17 may 2021 a las 9:40, Aswin Unnikrishnan (<
 aswinunn...@gmail.com>) escribió:

> Hi,
>
> I wanted to build an app that uses the koha API, and so i was 
> testing it out, but I keep getting "Authentication Failure" error 
> whichever end point I try to access.
> The steps i did are
>
> 1. Got the client_id / secret from koha 2. Sent a POST request to 
> api/v1/oauth/token with required parameters and got  an 
> "access_token" returned 3. Added the token to my authorization 
> header with header-prefix "Bearer"
> 4. Sent a GET request to different end points, but getting the 
> same 401 Unauthorized error code with error : Authentication 
> failure
>
> However if i access one of the public end points like 
> /api/v1/biblios/{biblio_id} i can get a response
>
> If anyone has any idea why this is happening, please  let me know.
>
> Thanks in advance,
> Aswin
> ___
>
> Koha mailing list  http://koha-community.org 
> Koha@lists.katipo.co.nz
> Unsubscribe: https://lists.katipo.co.nz/mailman/listinfo/koha
>


 --
 Tomás Cohen Arazi
 Theke Solutions (http://theke.io)
 ✆ +54 9351 

Re: [Koha] Status of ElasticSearch - 2021 version

[dcook]

Hi Tom,

I can't really speak to Elasticsearch with Koha, as I still just use Zebra. I 
imagine Ere in Finland or someone from Bywater in the USA might be the best to 
comment on Elasticsearch.

However, I'm curious what OS you are using. Debian/Ubuntu is typically the best 
option in terms of community support, but I also run Koha on OpenSUSE, and have 
run it on all kinds of other Linux-based OSes. 

David Cook
Software Engineer
Prosentient Systems
Suite 7.03
6a Glen St
Milsons Point NSW 2061
Australia

Office: 02 9212 0899
Online: 02 8005 0595

-Original Message-
Date: Mon, 22 Feb 2021 14:47:38 -0500
From: Tom Hanstra 
To: Koha Community 
Subject: [Koha] Status of ElasticSearch - 2021 version
Message-ID:

Content-Type: text/plain; charset="UTF-8"

Last year I checked in on the status of ElasticSearch with Koha and got the
distinct impression that it was still quite a work in progress.

Almost a year has passed and I'm not sure if much has changed. As late as
October, 2020, I see messages suggesting "Stay with Zebra for now".  But I
also see some messages about sites who claim to have successfully moved to
ElasticSearch. It is just unclear if they are using it for everything or if
there is some hybrid of using both in place.

The Wiki is of little help. Along with being completely Debian-centric (I'm
not using Debian), it is a couple of versions behind. So, again, signs that
ElasticSearch is still not mainstream.

So, who actually uses ElasticSearch in production at this point?  I'm
interested in doing so if it can speed things up as well as work fully with
both Authorities and Bibs. But if it is still not there, I can continue
with Zebra.

Thanks,
Tom

-- 
*Tom Hanstra*
*Sr. Systems Administrator*
hans...@nd.edu



___

Koha mailing list  http://koha-community.org
Koha@lists.katipo.co.nz
Unsubscribe: https://lists.katipo.co.nz/mailman/listinfo/koha

Re: [Koha] Koha resource requirements

[dcook]

Hi Barry,

 

I think that all sounds reasonable. If you haven’t done so already, would you 
consider requesting a wiki account via 
https://wiki.koha-community.org/wiki/Special:RequestAccount, so that you can 
add those notes as you’ve suggested? It should be low effort (in comparison to 
all the work you’ve done so far!) and would be a valuable contribution to Koha 
that would likely help many others. 

 

Cheers,

 

David Cook

Software Engineer

Prosentient Systems

Suite 7.03

6a Glen St

Milsons Point NSW 2061

Australia

 

Office: 02 9212 0899

Online: 02 8005 0595

 

From: Barry Callahan  
Sent: Friday, 18 December 2020 7:37 AM
To: dc...@prosentient.com.au
Cc: koha@lists.katipo.co.nz
Subject: RE: [Koha] Koha resource requirements

 

Thanks for that, David.

 

Your comment about swap is well-taken. If the initial micro instance had had at 
least a Gig of swap enabled, instead of locking up hard, it would have crawled 
along, swapping processes in and out of RAM, and given me a chance to stop the 
Koha instance and recover the system. (For giggles, I tested it.) 

 

As a second point of reference, I followed the instructions at 
https://wiki.koha-community.org/wiki/Debian to install the current stable 
release (20.05) on a fresh install of Ubuntu 20.04.1. I have not made any 
changes to config files not otherwise indicated in those instructions. Using 
the smem utility reveals the following memory usage at idle (using the numbers 
in the PSS column):

 

* Approximately 850MB used by applications owned by the koha instance's userid. 
That includes just shy of 250MB for each of the two starman plack workers.

* memcache and rabbitmq (which were both installed as dependencies of the 
koha-common package) combine to use approx 100MB total.

* mysqld is using 500MB. I'm sure I can tune it down, but as a base install, 
straight from the distro's repo, it's a useful datapoint. 

* apache's only using ~8MB.

 

As much as I think that the Requirements section on the download page really 
should say something about the memory needs of the system, I agree that it 
could be a bit difficult to succinctly describe the memory requirements of all 
of the moving parts in such a way that fits into the page. On the other hand, 
since the Debian installation walkthrough linked above is written from the 
assumption that the reader is starting from a virgin system, I think adding a 
section to the top of  that page would be a much easier mark to hit. Perhaps 
something along the lines of:

 



Some notes on memory usage:

 

These instructions assume you are starting from scratch, on a fresh server, 
with none of the prerequisites already installed.

Koha is big, and it is built on top of a stack of other software that is also 
big. As a result, the memory requirements to run it are going to be significant.

You must ensure that the target machine has adequate free memory available to 
run Koha before you begin.

 

Following these instructions will result in an instance of Koha and the 
necessary support software which together consume between 850MB - 1GB of memory 
at idle.

If you are installing the MySQL server on the same machine as Koha, assume it 
is going to need another 350MB - 500MB of RAM.

 

 

Note that there are many opportunities to tune the configurations of MySQL and 
Koha to reduce their memory consumption, but those optimizations and their 
consequences are outside of the scope of this document.



 

 

 

 

-Original message-
From: dc...@prosentient.com.au  
Sent: Wednesday, December 16 2020, 8:41 pm
To: Barry Callahan
Cc: koha@lists.katipo.co.nz  
Subject: RE: [Koha] Koha resource requirements
 

Hi Barry,
 
I think that it is reasonable to expect some minimum requirements to be listed, 
but it is easier said than done, since Koha is a large multi-component system.
 
Personally, I tend to run many Koha instances on high powered servers with 
external database servers, so it's rare for me to be thinking about the 
requirements for just 1 Koha. 
 
Typically, I only run 1 Koha instance for development and testing, and I use 
the koha-testing-docker (https://gitlab.com/koha-community/koha-testing-docker) 
setup for that. Looking at that, I'm seeing probably around ˜1.25GB of RAM used 
for an idle system, although that includes components like a Z3950 responder 
and SIP server that you won't need. Since it's a Dockerized environment, that's 
on top of whatever the OS and other installed software is needing. 
 
In my observations, I typically notice that a Starman "Plack" worker will take 
up about 200-500MB of RAM in its lifetime (mine right now are at 234 and 284 so 
I'd budget another 500MB). By default, you have 2 configured. If you wanted to 
shave off more memory, you could downgrade to just 1 Starman "Plack" worker. 
 
Looking at a server I do have with only 1 Koha 

Re: [Koha] Koha resource requirements

[dcook]

Hi Barry,

I think that it is reasonable to expect some minimum requirements to be listed, 
but it is easier said than done, since Koha is a large multi-component system.

Personally, I tend to run many Koha instances on high powered servers with 
external database servers, so it's rare for me to be thinking about the 
requirements for just 1 Koha. 

Typically, I only run 1 Koha instance for development and testing, and I use 
the koha-testing-docker (https://gitlab.com/koha-community/koha-testing-docker) 
setup for that. Looking at that, I'm seeing probably around ~1.25GB of RAM used 
for an idle system, although that includes components like a Z3950 responder 
and SIP server that you won't need. Since it's a Dockerized environment, that's 
on top of whatever the OS and other installed software is needing. 

In my observations, I typically notice that a Starman "Plack" worker will take 
up about 200-500MB of RAM in its lifetime (mine right now are at 234 and 284 so 
I'd budget another 500MB). By default, you have 2 configured. If you wanted to 
shave off more memory, you could downgrade to just 1 Starman "Plack" worker. 

Looking at a server I do have with only 1 Koha instance... MySQL is using 
357MB, Koha's Starman/Plack workers are 246MB and 190MB. The indexing daemon is 
171MB. So that adds up to just under 1GB. Add in a bit more for Apache, 
Memcached, Zebra search engine, et cetera and you're probably up to 1-1.25GB. 

But that's just a snapshot around lunch time near Christmas holidays. 
Ultimately, your mileage may vary. If you add some swap space, which I know 
isn't included by default on AWS, you might have a smoother experience as well 
as that would help soak up some unexpected memory spikes. 

I don't have access to update the Downloads page to add some minimum 
requirements, but I think perhaps that someone should. 

Regarding CPU, I'd say minimum 4 CPU between all the various different Koha 
subcomponents for any serious usage, but you could get away with less. My 
koha-testing-docker uses 2 CPUs and it manages fine for me as a single user. 

David Cook
Software Engineer
Prosentient Systems
Suite 7.03
6a Glen St
Milsons Point NSW 2061
Australia

Office: 02 9212 0899
Online: 02 8005 0595

-Original Message-
Date: Wed, 16 Dec 2020 16:01:03 +
From: Barry Callahan 
To: koha@lists.katipo.co.nz 
Subject: [Koha] Koha resource requirements
Message-ID:

<010001766c48916c-b5c8c8db-d977-4dd9-adb1-83a6c5f2ae77-000...@email.amazonses.com>

Content-Type: text/plain; charset=UTF-8

I recently started playing with Koha to see if it would help my wife and I 
manage our home library.

 
Before I began, I reviewed the requirements listed on the download page ( 
https://koha-community.org/download-koha/ ) and the instructions for installing 
using the official .deb packages. One thing I thought was very conspicuously 
lacking was any mention of resource requirements. Naively, I assumed that meant 
that the requirements for running Koha would only be minimally greater than 
those required for a LAMPP stack serving a similar amount of traffic.

 
Needless to say, an Amazon EC2 micro instance, which only has 1GB of RAM 
allocated to it is incapable of creating and enabling a single Koha library 
instance. Attempting to do so with no swap enabled immediately resulted in a 
crashed system.

 
I resized the instance to small, with 2GB of RAM, and was able to boot the 
system and log in, but top showed a peak memory usage of ~1.9GB. On seeing 
that, I resized the server again to a medium instance with 4GB of RAM. After 
populating the database and adding a couple users and a few dozen items to it, 
the server is sitting at 1.5GB of RAM in use (not including cache) at idle. 
Admittedly, that includes the 500MB allocated to the local MySQL server, but 
still. I think I could probably be safe scaling back to a small instance if I 
moved the database to a remote server, which is my plan.

 
I'd like to suggest updating the requirements section on the download page to 
include some information on the resources used by the koha-plack stack. At a 
minimum, some information about how much koha+plack would add to the memory 
footprint of an existing LAMP stack at idle would have saved me a fair bit of 
grief. Some information on how RAM usage and CPU load can be expected to scale 
with the number of active library instances and concurrent users would be nice, 
too, but less important than the base numbers, I think.



___

Koha mailing list  http://koha-community.org
Koha@lists.katipo.co.nz
Unsubscribe: https://lists.katipo.co.nz/mailman/listinfo/koha

Re: [Koha] Red Hat 8, installing dependencies

[dcook]

Hi Tasha,

It's great to hear that you're trying to install Koha! However, if I were you, 
I wouldn't bother with that old wiki page, as it's probably going to confuse 
more than help.

Typically, the Koha community supports Koha installations on Debian and Ubuntu 
operating systems, but there are some of us who run Koha on openSUSE, Red Hat, 
Fedora, etc. We are rare though. Wherever possible, it's best to use 
Debian/Ubuntu as you'll get the best, supported experience that way, but I know 
in a corporate environment that you're often limited to only using Red Hat 
Enterprise Linux. Part of the reason your email stood out to me is that I am in 
the process of migrating a non-Koha Perl application from RHEL 6 to RHEL 8, so 
I'm already in this headspace.

In all honesty, if I were you, I'd try to find a vendor that is willing - for a 
fee - to install Koha on your local RHEL 8 system. You can find more 
information at https://koha-community.org/support/paid-support/. We have 
installed Koha on RHEL for libraries with restricted corporate environments 
like you describe. I am sure there are vendors in Canada and the USA who have 
done it too who could help you out. Feel free to email me separately about that 
if you want to discuss that further.

--

If you are committed to doing it yourself without paid help, then it's 
important to think about Koha as a multi-component system: Linux OS, Apache 
httpd web server, MySQL database, Perl application, Zebra indexing engine. 

You've already got your Linux OS (RHEL 8), and you'll be able to use the Apache 
httpd web server and MySQL database from the Red Hat repositories. The 
difficulty will be with the Perl application (Koha proper) and Zebra. 

Looking at https://www.indexdata.com/resources/software/zebra/, there is a 
"Redhat" download option, but it does not look like the RHEL packages have been 
maintained. You could contact Indexdata to get them to publish new packages for 
RHEL 8. Alternatively, it looks like they do provide some for CentOS 8, which 
is *currently*  compatible with RHEL 8: 
http://ftp.indexdata.dk/pub/zebra/redhat/centos/8/README. I haven't used that 
but that would be my first step *before* trying to build Zebra from source. 

As for the Perl application (Koha proper), it's easier than ever to install 
dependencies thanks to the "cpanfile" provided with Koha. It provides a list of 
~180 Perl dependencies, which you can install using a tool called "cpanminus" 
(https://metacpan.org/pod/App::cpanminus). Unfortunately for you, these 
dependencies need to be fetched over the Internet from the "CPAN" 
(Comprehensive Perl Archive Network). However, perhaps you'd be able to talk to 
your IT about setting up a local offline mirror of CPAN. You can use the 
"minicpan" tool for that: 
https://metacpan.org/pod/distribution/CPAN-Mini/bin/minicpan. I have used that 
tool before in restricted corporate environments for Perl applications. 

Now that sounds easier than it actually is. You mentioned that you had some 
trouble installing some packages like "ImageMagick-devel". You need "*-devel" 
packages when you're building code from course (like you'd be doing using 
"cpanminus" and the "cpanfile" via "minicpan"), as they provide interfaces to 
lower level software tools (e.g. "ImageMagic" without the -devel). Typically, 
you discover which "-devel" packages you need when particular Perl dependencies 
fail to install. 

If you're successful with all of this, then there is the task of setting up a 
Zebra "service" and Koha "cronjobs". 

This also all assumes that you're not use SELinux security on RHEL 8 as well. 
That is a layer of complexity that is too difficult to explain in this space.

--

Alternatively, you could try running Docker containers - since Docker should be 
available in RHEL 8, or Virtual Machines on your RHEL 8 machine, and have those 
containers or virtual machines run Koha on Debian/Ubuntu. But that adds a 
different layer of complexity.

--

Hopefully that was helpfully comprehensive rather than terrifyingly 
comprehensive ; ). For years, I have been thinking of putting together RPM 
packages that could be installed on Red Hat or openSUSE, but it would require 
more resources than I have available, so I've been in the gradual process of 
switching to only using Debian/Ubuntu for Koha wherever possible. 

But I appreciate that you might not have that option. Due to your limitations, 
I think your best bet is to get a paid support vendor to help you, but you can 
also try what I've suggested and try working through it here. You probably 
won't be able to receive much more than general assistance, since the majority 
of people use Debian/Ubuntu, but you can always try.

Bon courage!

David Cook
Software Engineer
Prosentient Systems
Suite 7.03
6a Glen St
Milsons Point NSW 2061
Australia

Office: 02 9212 0899
Online: 02 8005 0595

-Original Message-
Date: Sat, 12 Dec 2020 21:37:08 +
From: "Bales (US), Tasha R" 
To: 

Re: [Koha] Koha Digest, Vol 182, Issue 10

[dcook]

Hi Peter,

Without rewriting the Koha code, it's impossible to authority control 2 
subfields in a field. There's a few reasons why. 

First, there is only one "9" subfield available for the linkage to the 
authority record. 

Second, Koha is hard-coded to authority control only the "a" subfield. I have 
gotten it to work with the 260$b but only if there is no authority control on 
260$a. 

Ultimately, it can't really done without rewriting some core parts of Koha. 

My suggestion would be to use "Authorized Value Lists" instead of authorities 
for the 260$a and 260$b instead, although I imagine that the customer won't 
like that. 

Someone else might have other ideas but that's my 2 cents.

David Cook
Software Engineer
Prosentient Systems
Suite 7.03
6a Glen St
Milsons Point NSW 2061
Australia

Office: 02 9212 0899
Online: 02 8005 0595

-Original Message-
Date: Thu, 10 Dec 2020 00:16:32 +0100
From: Peter Korsten 
To: koha 
Subject: [Koha] Authority controlled fields for publisher
Message-ID:

Content-Type: text/plain; charset="UTF-8"

Hi,

The topic has been asked before, but not exactly in the specific circumstances 
that I'm facing.

My company (essentially, yours truly) is installing Koha for a customer, and 
migrating data. They insist on having fields 260$a and 260$b to be authority 
controlled. I solved that by modifying the BKS framework, setting 260$a to be a 
GEOGR_NAME and 260$b a CORPO_NAME. So far, so good.

The trouble starts when you try the little icon to look up an authority record. 
If I click on that icon for 260$b (name of the publisher) and choose an 
existing one, the value instead ends up in 260$a.

Now I don't think that this is a bug in Koha, but I do think that I'm not 
understanding this facility entirely, and the documentation doesn't seem to 
address this issue either. I'm aware that field 260 is supposed to contain 
transcribed data, and we've pointed this out to the customer, but this is what 
they want.

Could somebody please enlighten me, whether I've taken the correct approach?

Thanks,

- Peter




___

Koha mailing list  http://koha-community.org
Koha@lists.katipo.co.nz
Unsubscribe: https://lists.katipo.co.nz/mailman/listinfo/koha

Re: [Koha] [Koha-devel] Happy Advent

[dcook]

Sounds great, Martin!

 

David Cook

Software Engineer

Prosentient Systems

72/330 Wattle St

Ultimo, NSW 2007

Australia

 

Office: 02 9212 0899

Online: 02 8005 0595

 

From: Koha-devel  On Behalf Of 
Renvoize, Martin
Sent: Tuesday, 1 December 2020 10:14 PM
To: Koha Devel ; Koha 

Subject: [Koha-devel] Happy Advent

 

Hi All, 

 

As a long term follower of the perl advent   
calendar series, it's been on my mind for a few years now to emulate it for the 
Koha world..

 

As such, I've badgered a few devs for a bit of help and low and behold.. I'm 
proud to announce our very own: https://koha-community.gitlab.io/KohaAdvent

 

Many thanks to my "volunteers" helping to bring this together at the last 
minute and especially Tomas for writing the first article to get us underway.

 

The theme will be plugins, integrations and api's from the perspective of 
development.

 

Have a great xmas everyone,

 



 


Martin Renvoize, MPhys (Hons)

  


Development Team Manager

Community Release Manager (19.11, 20.05)



Phone: +44 (0) 1483 378728

Mobile: +44 (0) 7725 985 636


Email:   martin.renvo...@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 mailing list  http://koha-community.org
Koha@lists.katipo.co.nz
Unsubscribe: https://lists.katipo.co.nz/mailman/listinfo/koha

Re: [Koha] koha script wiki

[dcook]

I am concerned about adding backend scripts to the wiki. There's no reliable 
way to ensure those scripts would be correct, and it would be trivial for 
someone to inject malicious code into the scripts and have unsuspecting users 
run things which could damage/compromise their backend systems by copy/pasting 
and executing.

I fear that people would see it on the wiki and take that as an endorsement of 
those scripts. 

David Cook
Software Engineer
Prosentient Systems
72/330 Wattle St
Ultimo, NSW 2007
Australia

Office: 02 9212 0899
Online: 02 8005 0595

-Original Message-
Date: Sun, 8 Nov 2020 08:15:40 +
From: "Renvoize, Martin" 
To: rogan.ha...@gmail.com
Cc: Koha 
Subject: Re: [Koha] koha script wiki
Message-ID:

Content-Type: text/plain; charset="UTF-8"

By all means feel free to add a page to the wiki...

I do wonder, however, why don't you submit useful scripts to the project via 
bugzilla instead..? That way they would benefit from the many eyes of our 
signoff and quality assurance process, get documented as part of the standard 
documentation processes and be more accessible to end users?

Just some thoughts,




___

Koha mailing list  http://koha-community.org
Koha@lists.katipo.co.nz
Unsubscribe: https://lists.katipo.co.nz/mailman/listinfo/koha

Re: [Koha] Add 999$c to Zebra index

[dcook]

I have a fair number of libraries using EDS (in Australia), and EBSCO doesn't 
use Z39.50 for any of them.

EBSCO harvests the records using OAI-PMH and then they use the ILS-DI API for 
the RTA (Real Time Availability). I think Wolters Kluwer's Ovid does the same 
thing. 

Joel, if "find @attr 1=12 59" is failing, I'd say it's either an 
implementation-specific indexing or searching issue. I can assure you that 
999$c is indexed as "Local-Number" by default. I use it all the time and have 
for years. 

David Cook
Software Engineer
Prosentient Systems
72/330 Wattle St
Ultimo, NSW 2007
Australia

Office: 02 9212 0899
Online: 02 8005 0595

-Original Message-
Date: Fri, 23 Oct 2020 09:10:18 -0300
From: Tomas Cohen Arazi 
To: Michael Sutherland 
Cc: koha 
Subject: Re: [Koha] Add 999$c to Zebra index
Message-ID:

Content-Type: text/plain; charset="UTF-8"

I believe EDS uses Z39.50 to query item statuses, real-time.

El vie., 23 oct. 2020 a las 8:47, Michael Sutherland ()
escribió:

> Joel,
>
> Since Koha is OAI-PMH compliant, you could have EBSCO harvest the 
> catalog and ingest it into EDS.  Then everything in your catalog will 
> be searchable in EDS.  When Virginia Tech was using EDS, I had it done 
> this way.  Are you hosted or have you installed Koha on your own? I 
> suggest speaking to your EBSCO implementation team for EDS; feel free 
> to mention us if you think it will help.
>
> Also, another suggestion; you might think about switching to Elastic 
> Search because you can map what MARC tags are searchable such as the 
> 999$c for the biblionumber.
>
> Best,
> Michael
> _
> *Michael J. Sutherland*
> University Libraries
> Virginia Tech
> sudrl...@vt.edu | 540.231.9669 <+15402319669>
>
>
>
> On Thu, Oct 22, 2020 at 4:19 PM Coehoorn, Joel  wrote:
>
> > This is EBSCO Discovery. The service is connecting successfully, but 
> > then getting now no results back from this query:
> >
> > find @attr 1=12 59
> >
> > They see:
> >
> > Received SearchResponse.
> > Search was a bloomin' failure.
> > Number of hits: 0, setno 1
> > Resultset status: none
> > records returned: 0
> >
> > I honestly have no idea what that means, but they're telling me it 
> > indicates 999$c is not indexed. How else could I address this?
> >
> > Joel Coehoorn
> > Director of Information Technology
> > 402.363.5603
> > *jcoeho...@york.edu *
> >
> > *Please contact helpd...@york.edu  for technical
> > assistance.*
> >
> >
> > The mission of York College is to transform lives through 
> > Christ-centered education and to equip students for lifelong service 
> > to God, family, and society
> >
> >
> > On Thu, Oct 22, 2020 at 3:11 PM Katrin Fischer 
> >  >
> > wrote:
> >
> > > Hi Joel,
> > >
> > > the biblionumber should already be indexed, the index name is 
> > > local-number. You can also see this in the default matching rules 
> > > Koha is installed with.
> > >
> > > Katrin
> > >
> > > On 22.10.20 22:03, Coehoorn, Joel wrote:
> > > > Does anyone have a step-by-step guide for adding the 
> > > > biblionumber to
> > the
> > > > zebra index? I need it to set up integration with a discovery
> service,
> > so
> > > > the discovery search can include both our Koha catalog holding 
> > > > and
> our
> > > > subscribed online resources that are not in Koha.
> > > >
> > > > I've seen this link:
> > > >
> > > > https://wiki.koha-community.org/wiki/How_to_add_new_zebra_index
> > > >
> > > > But it's not clear on whether or why to use index_data_field vs 
> > > > index_sub_fields, how to pick the right attribute number, and 
> > > > other
> > > things
> > > > like that, and I can't find any more complete documentation.
> > > >
> > > > Joel Coehoorn
> > > > Director of Information Technology
> > > > 402.363.5603
> > > > *jcoeho...@york.edu *
> > > >
> > > > *Please contact helpd...@york.edu  for 
> > > > technical
> > > > assistance.*
> > > >
> > > >
> > > > The mission of York College is to transform lives through 
> > > > Christ-centered education and to equip students for lifelong 
> > > > service
> to
> > > > God, family, and society
> > > > ___
> > > >
> > > > Koha mailing list  http://koha-community.org 
> > > > Koha@lists.katipo.co.nz
> > > > Unsubscribe: https://lists.katipo.co.nz/mailman/listinfo/koha
> > > ___
> > >
> > > Koha mailing list  http://koha-community.org 
> > > Koha@lists.katipo.co.nz
> > > Unsubscribe: https://lists.katipo.co.nz/mailman/listinfo/koha
> > >
> > ___
> >
> > Koha mailing list  http://koha-community.org Koha@lists.katipo.co.nz
> > Unsubscribe: https://lists.katipo.co.nz/mailman/listinfo/koha
> >
> ___
>
> Koha mailing list  http://koha-community.org Koha@lists.katipo.co.nz
> Unsubscribe: https://lists.katipo.co.nz/mailman/listinfo/koha
>

Re: [Koha] Embed Local video files like YouTube

[dcook]

Hi Vinod,

 

Koha, at least as of 19.11, has the capacity to handle non-YouTube media. I 
won’t give you remote support here, but perhaps someone else can or perhaps you 
can engage a support provider. 

 

David Cook

Systems Librarian

Prosentient Systems

72/330 Wattle St

Ultimo, NSW 2007

Australia

 

Office: 02 9212 0899

Online: 02 8005 0595

 

From: vinod mishra  
Sent: Thursday, 30 July 2020 4:38 AM
To: dc...@prosentient.com.au
Cc: Koha 
Subject: Re: [Koha] Embed Local video files like YouTube

 

Hello David

 

We have videos on Intranet and in MP4 format, but it seems current provision is 
for YouTube only and it fetches/embed the video nicely in Koha but not mine on 
Intranet.

 

Please suggest. 



With Regards,

Vinod Kumar Mishra,
Assistant Librarian,
Biju Patnaik Central Library (BPCL),
NIT Rourkela,
Sundergadh-769008,
Odisha,
India.
Mob:91+9439420860

ORCID ID: http://orcid.org/-0003-4666-7874

 

"Spiritual relationship is far more precious than physical. Physical 
relationship divorced from spiritual is body without soul" -- Mahatma Gandhi

 

 

On Wed, Jul 29, 2020 at 6:19 AM mailto:dc...@prosentient.com.au> > wrote:

Hi Vinod,

I haven't played with the HTML5 Media in Koha, but I've been curious about it, 
so I decided to take a look after reading your email.

Looking at the code, it appears that you can embed other videos and not just 
Youtube videos. You'll need to use the system preferences HTML5MediaEnabled and 
HTML5MediaExtensions, and make sure your 856$u has a valid URL to the video. 
You may need to transcode your video if it's in a format that doesn't work with 
HTML Video.  

It also depends on what you mean by "Local server". Is this the same server 
that is running Koha? Is it a separate file server? So long your server 
provides the video over HTTP(S) in a way that is accessible to your users, I 
think that you should be fine. 

David Cook
Systems Librarian
Prosentient Systems
72/330 Wattle St
Ultimo, NSW 2007
Australia

Office: 02 9212 0899
Online: 02 8005 0595

-Original Message-
Date: Tue, 28 Jul 2020 16:54:51 +0530
From: vinod mishra mailto:mishrav...@gmail.com> >
To: Koha mailto:Koha@lists.katipo.co.nz> >
Subject: [Koha] Embed Local video files like YouTube
Message-ID:
mailto:cagluwiqd7dvcvgtgmvbwld5u2jdfgtxmqe7neep-v6msarn...@mail.gmail.com> >
Content-Type: text/plain; charset="UTF-8"

Hello
As we have an option to activate YouTube online video embed feature within 
Koha, similarly i wish to embed lecture videos kept in Local server. Please let 
me know how we can make it possible like YouTube videos?

Thanking You

With Regards,

Vinod Kumar Mishra,
Assistant Librarian,
Biju Patnaik Central Library (BPCL),
NIT Rourkela,
Sundergadh-769008,
Odisha,
India.
Mob:91+9439420860
ORCID ID: http://orcid.org/-0003-4666-7874

*"Spiritual relationship is far more precious than physical. Physical 
relationship divorced from spiritual is body without soul" -- Mahatma
Gandhi*



signature.asc
Description: PGP signature
___

Koha mailing list  http://koha-community.org
Koha@lists.katipo.co.nz
Unsubscribe: https://lists.katipo.co.nz/mailman/listinfo/koha

Re: [Koha] Embed Local video files like YouTube

[dcook]

Hi Vinod,

I haven't played with the HTML5 Media in Koha, but I've been curious about it, 
so I decided to take a look after reading your email.

Looking at the code, it appears that you can embed other videos and not just 
Youtube videos. You'll need to use the system preferences HTML5MediaEnabled and 
HTML5MediaExtensions, and make sure your 856$u has a valid URL to the video. 
You may need to transcode your video if it's in a format that doesn't work with 
HTML Video.  

It also depends on what you mean by "Local server". Is this the same server 
that is running Koha? Is it a separate file server? So long your server 
provides the video over HTTP(S) in a way that is accessible to your users, I 
think that you should be fine. 

David Cook
Systems Librarian
Prosentient Systems
72/330 Wattle St
Ultimo, NSW 2007
Australia

Office: 02 9212 0899
Online: 02 8005 0595

-Original Message-
Date: Tue, 28 Jul 2020 16:54:51 +0530
From: vinod mishra 
To: Koha 
Subject: [Koha] Embed Local video files like YouTube
Message-ID:

Content-Type: text/plain; charset="UTF-8"

Hello
As we have an option to activate YouTube online video embed feature within 
Koha, similarly i wish to embed lecture videos kept in Local server. Please let 
me know how we can make it possible like YouTube videos?

Thanking You

With Regards,

Vinod Kumar Mishra,
Assistant Librarian,
Biju Patnaik Central Library (BPCL),
NIT Rourkela,
Sundergadh-769008,
Odisha,
India.
Mob:91+9439420860
ORCID ID: http://orcid.org/-0003-4666-7874

*"Spiritual relationship is far more precious than physical. Physical 
relationship divorced from spiritual is body without soul" -- Mahatma
Gandhi*



signature.asc
Description: PGP signature
___

Koha mailing list  http://koha-community.org
Koha@lists.katipo.co.nz
Unsubscribe: https://lists.katipo.co.nz/mailman/listinfo/koha

Re: [Koha] Chromium-based Microsoft Edge browser and Koha

[dcook]

Hi Lari,

It's a good question. I have the Chromium-based Edge, and it's what I use for 
testing. I've been referring clients away from IE 11 and to Edge (where they 
can't use Chrome/Firefox), and I haven't heard any complaints about Edge yet.

David Cook
Systems Librarian
Prosentient Systems
72/330 Wattle St
Ultimo, NSW 2007
Australia

Office: 02 9212 0899
Online: 02 8005 0595

-Original Message-
Date: Tue, 7 Jul 2020 23:37:11 +0300
From: Lari Taskula 
To: koha@lists.katipo.co.nz
Subject: [Koha] Chromium-based Microsoft Edge browser and Koha
Message-ID: <314e88e0-f0b5-81d2-0450-744865ab9...@hypernova.fi>
Content-Type: text/plain; charset="utf-8"

Hey Koha community,

Are there any Koha users with the new Microsoft Edge Chromium-based
browser? As a Chromium-based browser my guess is that it works with
Koha, but I would like to have some feedback from those who've actually
used it.

Edge has been Chromium-based since version 79 (released January 15,
2020), so if you are using Edge and are not sure if it's the new
Chromium-based one, please check your browser's version.

I know Koha documentation recommends Chrome and Firefox, but some
instances are starting to ask for Chromium Edge support. Hence this
question.

Thanks for your time,

-- 
Lari Taskula
CEO, Hypernova Oy
+358449857337
PL 16
80101 Joensuu, Finland




signature.asc
Description: PGP signature
___

Koha mailing list  http://koha-community.org
Koha@lists.katipo.co.nz
Unsubscribe: https://lists.katipo.co.nz/mailman/listinfo/koha

Re: [Koha] Problem with coverflow plugin, Koha 20.05

[dcook]

The issue is that the coverflow plugin doesn't have a "tool" or "report" 
method, so it won't appear in the Tools or Report modules by default. 

You'll notice that /cgi-bin/koha/tools/tools-home.pl takes you to 
/cgi-bin/koha/plugins/plugins-home.pl?method=tool, and 
/cgi-bin/koha/reports/reports-home.pl takes you to 
/cgi-bin/koha/plugins/plugins-home.pl?method=report. 

If you go to /cgi-bin/koha/plugins/plugins-home.pl or click "View plugins by 
class" and choose "View all plugins", then you'll see the plugin in the list. 

I'd argue that the "Administration" module should probably have a "Plugin" page 
that by default shows all plugins, as this can be confusing. I know I was 
confused about it until I figured out that it was just a "view" issue a few 
weeks ago.

David Cook
Systems Librarian
Prosentient Systems
72/330 Wattle St
Ultimo, NSW 2007
Australia

Office: 02 9212 0899
Online: 02 8005 0595

-Original Message-
From: Koha  On Behalf Of 
koha-requ...@lists.katipo.co.nz
Sent: Monday, 6 July 2020 10:00 AM
To: koha@lists.katipo.co.nz
Subject: Koha Digest, Vol 177, Issue 6

Send Koha mailing list submissions to
koha@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-requ...@lists.katipo.co.nz

You can reach the person managing the list at
koha-ow...@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. Re: Problem with coverflow plugin, Koha 20.05 (vinod mishra)
   2. Re: Problem with coverflow plugin, Koha 20.05 (Alvaro Cornejo)
   3. Re: Problem with coverflow plugin, Koha 20.05 (vinod mishra)
   4. Re: Problem with coverflow plugin, Koha 20.05 (Pavlo Bobesiuk)
   5. Re: Problem with coverflow plugin, Koha 20.05 (Tomas Cohen Arazi)


--

Message: 1
Date: Sun, 5 Jul 2020 18:47:01 +0530
From: vinod mishra 
To: Pavlo Bobesiuk 
Cc: "koha@lists.katipo.co.nz" 
Subject: Re: [Koha] Problem with coverflow plugin, Koha 20.05
Message-ID:

Content-Type: text/plain; charset="UTF-8"

Hi
I observed after uploading in Koha it disappeared from the installed plugin 
list automatically. I checked in Koha 20.05 and debian 10.

With Regards,

Vinod Kumar Mishra,
Assistant Librarian,
Biju Patnaik Central Library (BPCL),
NIT Rourkela,
Sundergadh-769008,
Odisha,
India.
Mob:91+9439420860
ORCID ID: http://orcid.org/-0003-4666-7874

*"Spiritual relationship is far more precious than physical. Physical 
relationship divorced from spiritual is body without soul" -- Mahatma
Gandhi*


On Sat, Jul 4, 2020 at 3:15 PM Pavlo Bobesiuk  wrote:

> Hi!  after updating koha to version 20.05 i noticed that coverflow 
> plugin doesn't work.
>  Has anyone had the same problem and how did solve it?
> Pavlo.
> --
> З повагою
> Павло Бобесюк=))
> ___
>
> Koha mailing list  http://koha-community.org Koha@lists.katipo.co.nz
> Unsubscribe: https://lists.katipo.co.nz/mailman/listinfo/koha
>


--

Message: 2
Date: Sun, 5 Jul 2020 11:21:15 -0500
From: Alvaro Cornejo 
To: vinod mishra 
Cc: "koha@lists.katipo.co.nz" , Pavlo
Bobesiuk 
Subject: Re: [Koha] Problem with coverflow plugin, Koha 20.05
Message-ID:

Content-Type: text/plain; charset="UTF-8"

Hi

Have you tried to reintall it after upgrade?

I had a similar issue on 17.05 and reinstalling the plugging it worked.
Note that eventhough I reinstall it. It kept original configuration. I had to 
just enable it.

Regards,

Alvaro
||
 Stay safe / Cuídate/  Reste sécurisé
*7* Switch off as you go / Apaga lo que no usas /  Débranchez au fur et à 
mesure.
 *q *Recycle always / Recicla siempre / Recyclez toujours  P Print only if 
absolutely necessary / Imprime solo si es necesario / Imprimez seulement si 
nécessaire


Le dim. 5 juil. 2020 à 08:18, vinod mishra  a écrit :

> Hi
> I observed after uploading in Koha it disappeared from the installed 
> plugin list automatically. I checked in Koha 20.05 and debian 10.
>
> With Regards,
>
> Vinod Kumar Mishra,
> Assistant Librarian,
> Biju Patnaik Central Library (BPCL),
> NIT Rourkela,
> Sundergadh-769008,
> Odisha,
> India.
> Mob:91+9439420860
> ORCID ID: http://orcid.org/-0003-4666-7874
>
> *"Spiritual relationship is far more precious than physical. Physical 
> relationship divorced from spiritual is body without soul" -- Mahatma
> Gandhi*
>
>
> On Sat, Jul 4, 2020 at 3:15 PM Pavlo Bobesiuk  wrote:
>
> > Hi!  after updating koha to version 20.05 i noticed that coverflow 
> > plugin doesn't work.
> >  Has anyone had the same problem and how did solve it?
> > Pavlo.
> > --
> > З повагою
> > Павло Бобесюк=))
> > 

Re: [Koha] [Koha-devel] Plack down due to "GET http://swagger.io/v2/schema.json == Connect timeout"

[dcook]

Thanks, Mason!

I think Mason has released a newer version now 3.23+dfsg-1+koha1, which was 
needed for newer versions of Ubuntu, which used newer versions of 
libjson-validator-perl than 3.06.

So the fix now should just be:

apt-get update
apt-get install libjson-validator-perl

David Cook
Systems Librarian
Prosentient Systems
72/330 Wattle St
Ultimo, NSW 2007
Australia

Office: 02 9212 0899
Online: 02 8005 0595

-Original Message-
From: Koha-devel  On Behalf Of 
Mason James
Sent: Wednesday, 1 July 2020 1:32 PM
To: 'Koha Devel' ; koha@lists.katipo.co.nz
Subject: Re: [Koha-devel] Plack down due to "GET 
http://swagger.io/v2/schema.json == Connect timeout"


On 1/07/20 2:39 pm, dc...@prosentient.com.au wrote:
>
> Hi all,
>
> As some people have noticed, http://swagger.io/v2/schema.json is 
> currently unavailable, and this is causing new instances of Plack 
> workers to crash. (New instances can be created by starting Plack or 
> by long-running workers to reach their end of life number of 
> requests.)
>
> The issue is detailed at length in 
> https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23653.
>
> I think the solution will be for Mason to a libjson-validator-perl package 
> which contains a cached version of that file.
>

hi Folks
i've updated the 'libjson-validator-perl' package to include the cache dir

to update the package...
$ sudo apt update
$ sudo apt install libjson-validator-perl

run the following command, and confirm the result...
$ apt-cache policy  libjson-validator-perl
libjson-validator-perl:
   Installed: 3.06+dfsg-1+koha1
   Candidate: 3.06+dfsg-1+koha1
...

cheers, Mason
___
Koha-devel mailing list
koha-de...@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/



signature.asc
Description: PGP signature
___

Koha mailing list  http://koha-community.org
Koha@lists.katipo.co.nz
Unsubscribe: https://lists.katipo.co.nz/mailman/listinfo/koha

Re: [Koha] Koha as Doc Man System

[dcook]

You would need to clarify what you mean by "docs management system". 

If you're referring to a system as described by 
https://en.wikipedia.org/wiki/Document_management_system, then I would say no. 
Koha isn't a records management system nor is it a digital library. 

Koha is an integrated library system / library management system, which works 
by storing and indexing metadata about resources (e.g. books, DVDs, journal 
articles, et cetera). It doesn't store the resources themselves. There is some 
basic capacity to store arbitrary files in Koha, but not as sophisticated as 
you'd find in a document/record management system or digital asset management 
system. 

Of course, Koha is open source, so a person could always build document 
management functionality into Koha. 

But I would say it's not viable at present without work.

David Cook
Systems Librarian
Prosentient Systems
72/330 Wattle St
Ultimo, NSW 2007
Australia

Office: 02 9212 0899
Online: 02 8005 0595

-Original Message-
Date: Tue, 21 Apr 2020 14:51:23 + (UTC)
From: Esmael Wan 
To: koha@lists.katipo.co.nz
Subject: [Koha] Koha as Doc Man System
Message-ID: <1058923143.197341.1587480683...@mail.yahoo.com>
Content-Type: text/plain; charset=UTF-8

Is it viable to consider Koha as a docs management system ?
Regards
Akla Esmael





signature.asc
Description: PGP signature
___

Koha mailing list  http://koha-community.org
Koha@lists.katipo.co.nz
Unsubscribe: https://lists.katipo.co.nz/mailman/listinfo/koha

Re: [Koha] Is Koha plugin system safe?

[dcook]

Hi Michal,

I would say that the plugin system (like many plugin systems) is risky. As 
Jonathan indicates, plugins are not reviewed by the Koha Community, so we can 
make no guarantees regarding safety/security of individual plugins. Since the 
plugins are third-party code, they could contain anything. That said, I doubt 
that you'd find any/many malicious Koha plugins in the wild. You're more likely 
to find Koha plugins that just have accidental security vulnerabilities. For 
instance, I have found some that have SQL injection vulnerabilities, which I 
wouldn't recommend using (although I say that personally and not as a member of 
the Koha Community - I'm not reviewing any plugins at a community level). 

In terms of safety, you're *probably* more likely to find accidental problems 
rather than malicious ones, although practically speaking you could encounter 
either. 

There is a fledgling conversation about adding signature (ie author 
verification) for plugins 
(https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24632). With this 
verification, you could set up Koha to only use plugins from a trusted provider 
(like Prosentient Systems, PTFS Europe, ByWater Solutions, BibLibre, EBSCO, 
etc.) . 

That wouldn't keep you safe from accidental security vulnerabilities, but it 
would keep you safe from malicious plugins. 

The trade-off with plugins is that you get new functionality quicker but it's 
not as rigorously reviewed as the Koha codebase. 

David Cook
Systems Librarian
Prosentient Systems
72/330 Wattle St
Ultimo, NSW 2007
Australia

Office: 02 9212 0899
Online: 02 8005 0595

-Original Message-
Date: Thu, 16 Apr 2020 03:28:34 -0700 (MST)
From: Michał Dudzik 
To: koha@lists.katipo.co.nz
Subject: [Koha] Is Koha plugin system safe?
Message-ID: <1587032914820-0.p...@n5.nabble.com>
Content-Type: text/plain; charset=us-ascii

The koha plug-in system enables easy system expansion with an additional 
non-standard function.
I have received several queries from librarians about the security of the 
plug-in system.
Personally, I have not observed any problems, so I would like to ask if using 
the plug-in system is safe?

Regards,
Michal




--
Sent from: http://koha.1045719.n5.nabble.com/Koha-general-f3047918.html


--

Message: 2
Date: Thu, 16 Apr 2020 12:54:23 +0200
From: Jonathan Druart 
To: Michał Dudzik 
Cc: koha 
Subject: Re: [Koha] Is Koha plugin system safe?
Message-ID:

Content-Type: text/plain; charset="UTF-8"

Hi Michal,

It depends on the plugin :)
A plugin can do almost everything it wants, so you should only install plugins 
you really trust.
And you should give the permissions to manage them to librarians you really 
trust as well.

I should add that plugins are almost never reviewed (by the QA team for 
instance), so they could potentially contain security issues.

Regards,
Jonathan

Le jeu. 16 avr. 2020 à 12:28, Michał Dudzik  a écrit :
>
> The koha plug-in system enables easy system expansion with an 
> additional non-standard function.
> I have received several queries from librarians about the security of 
> the plug-in system.
> Personally, I have not observed any problems, so I would like to ask 
> if using the plug-in system is safe?
>
> Regards,
> Michal
>



signature.asc
Description: PGP signature
___

Koha mailing list  http://koha-community.org
Koha@lists.katipo.co.nz
Unsubscribe: https://lists.katipo.co.nz/mailman/listinfo/koha

Re: [Koha] Taking patron images out of db into a directory

[dcook]

Recently, I've been re-thinking the scalability of Koha, so it's interesting to 
hear about this from you, Mengu, as the person who I think runs the biggest 
Koha installation in the world. 

Originally, I thought putting images in the database was a bad idea, but it is 
an easy way to provide that image data over a network to multiple nodes and is 
part of an established community-supported application backup strategy. 

But fetching arbitrary blobs from a database could be slow and it could inflate 
Koha's metadata/transaction database. Storing image data in the database seems 
convenient - especially for small implementations - but is more problematic for 
large implementations.

The probable solution to me for a large implementation is a network file share 
or object storage (e.g. AWS S3, Ceph, Minio, OpenStack Swift, etc). But that 
puts more of a burden on system administrators to make sure things are backed 
up. Not a problem for large implementations but it would be for small 
implementations.

The ultimate solution to me would be a standard API (Koha::UploadedFiles I 
presume) in Koha with different storage backends. This is a common approach 
used by other FOSS systems. You can have drivers for database storage, file 
system storage, object storage - and you can choose the driver best suited to 
your situation with the default option being the most convenient for small 
implementations (ie probably database storage). 

Recently, we've locally provided an object storage integration to provide 
people with a robust low-cost method for storing documents in Koha, which seems 
to be working well.

Using a caching layer would be nice too, so loading the same page 2 times 
doesn't equal 2 high cost trips to the data storage. I've been using the IIIF 
Image Server Loris backed by Fedora Commons backed by AWS S3 and caching makes 
a world of difference for end users. 

Anyway, that's my 2 cents. Ideally, the work done on this would be generalized, 
so that it could be used for things like biblio images, documents, etc. (I 
suppose storing URIs might be a useful way to do it. That way you could use 
file:///local/disk, file:///network/disk, s3://mybucket... maybe mysql://..)

(I'd be interested too to hear about optimizations people have for serving 
image data. Starman won't perform this task as well as Nginx or Apache, but I 
think we need to have this data behind an authorization layer, which currently 
means Perl. But that's really a completely different discussion.)

We might also want to move this from koha to koha-devel listserv?

David Cook
Systems Librarian
Prosentient Systems
72/330 Wattle St
Ultimo, NSW 2007
Australia

Office: 02 9212 0899
Online: 02 8005 0595

-Original Message-
Date: Thu, 9 Apr 2020 17:40:17 +0300
From: Mengu Yazicioglu 
To: Koha 
Subject: [Koha] Taking patron images out of db into a directory
Message-ID: 
Content-Type: text/plain; charset=utf-8; format=flowed

Hi all,

We'd like to write a patch to move patron images out of db into a directory in 
the server.

By this change, we'd like to satisfy following.

1. The size of database backup will be decreased, by this way one may store db 
backups more.

2. Database performance will increase

3. It will be possible to put patron images in different disk in the server

4. Easily put images gathered from other systems like (university system, 
personnel system, etc)

What is your idea?

--
Mengü Yazıcıoğlu
Devinim Yazılım Eğitim Danışmanlık
Reşit Galip Cad. No: 29/6
Çankaya/ANKARA

Tel: (312) 446 86 68
Cep: (532) 701 90 27




signature.asc
Description: PGP signature
___

Koha mailing list  http://koha-community.org
Koha@lists.katipo.co.nz
Unsubscribe: https://lists.katipo.co.nz/mailman/listinfo/koha

Re: [Koha] multiple Koha zebra problem

[dcook]

Hi George, 

 

I’m glad that my email helped!

 

It does feel strange, but that’s the way SysV scripts work. Think about it like 
a shebang at the top of a script. While it starts with a #, it is still parsed 
by computers as more than just a comment.

 

David Cook

Systems Librarian

Prosentient Systems

72/330 Wattle St

Ultimo, NSW 2007

Australia

 

Office: 02 9212 0899

Direct: 02 8005 0595

 

From: George Mikuchadze  
Sent: Friday, 13 March 2020 4:11 PM
To: dc...@prosentient.com.au
Subject: Re: [Koha] multiple Koha zebra problem

 

Many thanks for your reply,

I updated this line (very strange because the line is a comment in the script) 
and it started without any problem!

 

George Mikuchadze

 

On Fri, Mar 13, 2020 at 3:26 AM mailto:dc...@prosentient.com.au> > wrote:

Hi George,

I notice that you didn't answer Katrin's questions. Answering those questions 
is really important, or we can't really help you very well. 

Now, it sounds to me like you've installed Koha from either a "git clone" or a 
tarball, and that you're running multiple Koha instances from multiple Koha 
codebases, which may or may not be running the same version. 

I'm guessing that you copied "misc/bin/koha-zebra-ctl.sh" to 
/etc/init.d/koha-zebra-daemon, /etc/init.d/koha1-zebra-daemon, etc. 

However, it sounds like you haven't updated the following line within that file:
# Provides:  koha-zebra-daemon

You'll need to update that to match the filename. That's why you're getting 
that error. I think Ubuntu 14.04 used upstart as an init system while Ubuntu 
16.04 should be using systemd. Systemd can be pretty strict when it comes to 
interpreting SysV style scripts like "misc/bin/koha-zebra-ctl.sh", so that's 
probably where the difference lies. 

Now, if you're only running 1 version of Koha (ie 3.22.21), I'd highly 
recommend that you don't use git/tarball installations, and instead switch to 
using Debian packages. It will make your life much easier (and it'll make it 
easier for you to get support from the Koha Community). 

Cheers,

David Cook
Systems Librarian
Prosentient Systems
72/330 Wattle St
Ultimo, NSW 2007
Australia

Office: 02 9212 0899
Direct: 02 8005 0595

-Original Message-
Date: Thu, 12 Mar 2020 12:11:08 +0400
From: George Mikuchadze mailto:gmikucha...@gmail.com> >
To: koha@lists.katipo.co.nz  , 
katrin.fischer...@web.de  ,  Irakli
Garibashvili mailto:i...@hotmail.com> >
Subject: [Koha] multiple Koha zebra problem
Message-ID:
mailto:cajr6acbhjt3xbntvb_unejw%2b5cuo9qu7jwfdatskrxpbewd...@mail.gmail.com> >
Content-Type: text/plain; charset="UTF-8"

Dear Katrin,
Many thanks for Your reply. The problem is the following:
We use multiple koha-s (with the same number of zebra daemons), now we want to 
install koha v3.22.21 on ubuntu 16.04. When I activate koha-zebra-daemon for 
the second instance of koha (koha1), I get the error:
--
$ sudo update-rc.d koha1-zebra-daemon defaults
insserv: script koha1-zebra-daemon: service koha-zebra-daemon already provided!
insserv: exiting now!
update-rc.d: error: insserv rejected the script header
---
Here is the content of koha1-zebra-daemon:
...
.the same as for instance of koha, koha2, 
koha3...
USER=koha
GROUP=koha
DBNAME=koha1
NAME=koha-zebra-ctl.$DBNAME
LOGDIR=/var/log/koha1
ERRLOG=$LOGDIR/koha-zebradaemon.err
STDOUT=$LOGDIR/koha-zebradaemon.log
OUTPUT=$LOGDIR/koha-zebradaemon-output.log
KOHA_CONF=/etc/koha1/koha-conf.xml
RUNDIR=/var/run/koha1/zebradb
LOCKDIR=/var/lock/koha1/zebradb
# you may need to change this depending on where zebrasrv is installed 
ZEBRASRV=/usr/bin/zebrasrv ZEBRAOPTIONS="-v none,fatal,warn"

.the same as for instance of koha, koha2, koha3...

The main strange is the following: it (the same version of koha and zebra) 
works without any problem on Ubuntu 14.04!

Thanks in advance

George Mikuchadze





signature.asc
Description: PGP signature
___

Koha mailing list  http://koha-community.org
Koha@lists.katipo.co.nz
Unsubscribe: https://lists.katipo.co.nz/mailman/listinfo/koha

Re: [Koha] multiple Koha zebra problem

[dcook]

Hi George,

I notice that you didn't answer Katrin's questions. Answering those questions 
is really important, or we can't really help you very well. 

Now, it sounds to me like you've installed Koha from either a "git clone" or a 
tarball, and that you're running multiple Koha instances from multiple Koha 
codebases, which may or may not be running the same version. 

I'm guessing that you copied "misc/bin/koha-zebra-ctl.sh" to 
/etc/init.d/koha-zebra-daemon, /etc/init.d/koha1-zebra-daemon, etc. 

However, it sounds like you haven't updated the following line within that file:
# Provides:  koha-zebra-daemon

You'll need to update that to match the filename. That's why you're getting 
that error. I think Ubuntu 14.04 used upstart as an init system while Ubuntu 
16.04 should be using systemd. Systemd can be pretty strict when it comes to 
interpreting SysV style scripts like "misc/bin/koha-zebra-ctl.sh", so that's 
probably where the difference lies. 

Now, if you're only running 1 version of Koha (ie 3.22.21), I'd highly 
recommend that you don't use git/tarball installations, and instead switch to 
using Debian packages. It will make your life much easier (and it'll make it 
easier for you to get support from the Koha Community). 

Cheers,

David Cook
Systems Librarian
Prosentient Systems
72/330 Wattle St
Ultimo, NSW 2007
Australia

Office: 02 9212 0899
Direct: 02 8005 0595

-Original Message-
Date: Thu, 12 Mar 2020 12:11:08 +0400
From: George Mikuchadze 
To: koha@lists.katipo.co.nz, katrin.fischer...@web.de,  Irakli
Garibashvili 
Subject: [Koha] multiple Koha zebra problem
Message-ID:

Content-Type: text/plain; charset="UTF-8"

Dear Katrin,
Many thanks for Your reply. The problem is the following:
We use multiple koha-s (with the same number of zebra daemons), now we want to 
install koha v3.22.21 on ubuntu 16.04. When I activate koha-zebra-daemon for 
the second instance of koha (koha1), I get the error:
--
$ sudo update-rc.d koha1-zebra-daemon defaults
insserv: script koha1-zebra-daemon: service koha-zebra-daemon already provided!
insserv: exiting now!
update-rc.d: error: insserv rejected the script header
---
Here is the content of koha1-zebra-daemon:
...
.the same as for instance of koha, koha2, 
koha3...
USER=koha
GROUP=koha
DBNAME=koha1
NAME=koha-zebra-ctl.$DBNAME
LOGDIR=/var/log/koha1
ERRLOG=$LOGDIR/koha-zebradaemon.err
STDOUT=$LOGDIR/koha-zebradaemon.log
OUTPUT=$LOGDIR/koha-zebradaemon-output.log
KOHA_CONF=/etc/koha1/koha-conf.xml
RUNDIR=/var/run/koha1/zebradb
LOCKDIR=/var/lock/koha1/zebradb
# you may need to change this depending on where zebrasrv is installed 
ZEBRASRV=/usr/bin/zebrasrv ZEBRAOPTIONS="-v none,fatal,warn"

.the same as for instance of koha, koha2, koha3...

The main strange is the following: it (the same version of koha and zebra) 
works without any problem on Ubuntu 14.04!

Thanks in advance

George Mikuchadze




signature.asc
Description: PGP signature
___

Koha mailing list  http://koha-community.org
Koha@lists.katipo.co.nz
Unsubscribe: https://lists.katipo.co.nz/mailman/listinfo/koha

Re: [Koha] need help with accessing koha from outside via

[dcook]

Hi Alvaro,

I think that you misunderstand the netstat output there.

"tcp6   0  0 :::80 :::*  LISTEN  1113/apache2" means that 
it's using a TCP socket that supports both IPv4 and IPv6. 

 Heinz:
1. Remove the entries from /etc/hosts
2. Do "nslookup something.dnshome.de"
3. Confirm that the output of the above command matches your current home IP 
address
4. Ensure that your Apache configuration for the OPAC has either a ServerName 
or ServerAlias directive matching something.dnshome.de
5. Reload/restart Apache to be on the safe side
6. That should be it

That said, I'd be careful exposing a test version of Koha to the Internet, 
especially if you're not familiar with Koha or Apache. 

David Cook
Systems Librarian
Prosentient Systems
72/330 Wattle St
Ultimo, NSW 2007
Australia

Office: 02 9212 0899
Direct: 02 8005 0595

-Original Message-
Date: Thu, 6 Feb 2020 15:44:17 -0500
From: Alvaro Cornejo 
To: Heinz-Jürgen Oertel 
Cc: koha 
Subject: Re: [Koha] need help with accessing koha from outside via
DynDNS
Message-ID:

Content-Type: text/plain; charset="UTF-8"

Hi Heinz

Usually this issue means Apache is receiving a call for a site that does
"not exist" so it shows its default page.

Check that your koha site is enabled (sudo a2ensite bibliotthek.conf)

As per

tcp6   0  0 :::80 :::*  LISTEN  1113/apache2

Seems apache is not listening to tcp4 and also port 8080 is not enabled
either.

You should have in your apache port file
Listen 80
Listen 8080

In some cases, there are conflict with IPV6. If you do not use it you can
disable it by:
Listen 0.0.0.0:80
Listen 0.0.0.0:8080

After doing those changes, you need to restart apache

sudo service apache2 restart

Regards,

Alvaro


|-|
Envíe y Reciba Datos y mensajes de Texto (SMS) hacia y desde cualquier
celular y Nextel
en el Perú, México y en mas de 180 paises. Use aplicaciones 2 vias via SMS
y GPRS online
  Visitenos en www.perusms.com


Le jeu. 6 févr. 2020 à 08:51, Heinz-Jürgen Oertel  a
écrit :

> Am Donnerstag, 6. Februar 2020, 13:49:38 CET schrieb Mark Alexander:
> > Excerpts from Heinz-Jürgen Oertel's message of 2020-02-06 13:32:34 +0100:
> > > I can reach my network vi   something.dnshome.de
> > > With a port forwarding 80 -> 80 in the network router I can reach the
> test
> > > page of the apache server.
> > > How  can I reach the koha server
> >
> > It's possible that Koha is listening on a port other than 80.  This is
> > controlled by the VirtualHost line(s) in your Koha installation's
> > configuration file in /etc/apache2/sites-available/INSTANCE.conf, where
> > INSTANCE is the name of your Koha instance.
> >
> > You can see what ports are in use with this command:
> >
> > netstat -pn --tcp --listen | grep apache
>
>
> tcp6   0  0 :::80 :::*  LISTEN  1113/apache2
>
> That means, Apache is listening at 80, that is correct, but could not be
> all
>
> From the local site, where i have to entries in /etc/hosts
> 192.168.2.138   bibliothek.x.de
> 192.168.2.138   bibliothek-intra..de
>
> I only can call koha  with one of these symbolic names.
> If I put
> http://192.168.2.138
> in the browser URL field, I too reach the Apache test page
>
> Regards
>  Heinz
>
>
> ___
> Koha mailing list  http://koha-community.org
> Koha@lists.katipo.co.nz
> https://lists.katipo.co.nz/mailman/listinfo/koha
>




signature.asc
Description: PGP signature
___
Koha mailing list  http://koha-community.org
Koha@lists.katipo.co.nz
https://lists.katipo.co.nz/mailman/listinfo/koha

[Koha] External Independent Security Audit of Koha

[dcook]

Hi all,

 

Fred King's email about using Koha in a Protected Health network reminded me
of a question I wanted to pose around the world. Has anyone commissioned an
external independent security audit of Koha? That is to say, a security
audit from someone other than a Koha support vendor? 

 

If so, would they be willing to share the results with other Koha libraries?
For instance, in Fred's case, he could refer his IT department to those
results, so they could use it in their risk management analysis. (Of course,
I think it would be important to note that security depends a lot on the
implementation itself, the version of the Koha software, and so on. So one
security audit report would not cover all implementations world-wide, but it
could be a useful starting point.)

 

I know that I've had IT departments interested in these third-party external
independent security audits, so I imagine this is actually a common request
that a lot of Koha users around the world are probably facing. 

 

David Cook

Systems Librarian

Prosentient Systems

72/330 Wattle St

Ultimo, NSW 2007

Australia

 

Office: 02 9212 0899

Direct: 02 8005 0595

 



signature.asc
Description: PGP signature
___
Koha mailing list  http://koha-community.org
Koha@lists.katipo.co.nz
https://lists.katipo.co.nz/mailman/listinfo/koha

Re: [Koha] icuchain vs charmap

[dcook]

Hi Alvaro,

I'm sure the folk at Theke would be able to provide a solid recommendation 
(https://theke.io/). 

I mostly support English libraries and they use the CHR (ie charmap 
word-phrase-utf.chr) indexing. However, libraries I support with French and 
Arabic use ICU (ie icuchain words-icu.xml) indexing. I think the most 
appropriate choice for you will probably be ICU, but I'll defer to those who 
support Spanish language libraries. 

In any case, if you do change that Zebra configuration, you will need to 
re-index your Koha data before search will work properly.

Hope that helps.

David Cook
Systems Librarian
Prosentient Systems
72/330 Wattle St
Ultimo, NSW 2007
Australia

Office: 02 9212 0899
Direct: 02 8005 0595

-Original Message-

Date: Wed, 15 Jan 2020 17:14:16 -0500
From: Alvaro Cornejo 
To: Koha 
Subject: [Koha] icuchain vs charmap
Message-ID:

Content-Type: text/plain; charset="UTF-8"

Hi

I have a doubt about which kind of index to use in koha for a mostly
spanish library.

I read some suggestions about changing

charmap word-phrase-utf.chr

with

icuchain words-icu.xml

on the default zebradb config but have no a clear idea

Regards,

Alvaro
|-|
Envíe y Reciba Datos y mensajes de Texto (SMS) hacia y desde cualquier
celular y Nextel
en el Perú, México y en mas de 180 paises. Use aplicaciones 2 vias via SMS
y GPRS online
  Visitenos en www.perusms.com



signature.asc
Description: PGP signature
___
Koha mailing list  http://koha-community.org
Koha@lists.katipo.co.nz
https://lists.katipo.co.nz/mailman/listinfo/koha

Re: [Koha] How to make the Koha/Zebra search ignore hyphens?

[dcook]

Hi Katrin, 

I actually did create a transliterate rule which was able to convert the input 
from "Sinti-Swing" to "SintiSwing Sinti Swing" which created "sintiswing", 
"sinti", and "swing" as tokens. However, I think the ICU chain file gets used 
for both indexing and searching, so while it would work for indexing, it 
wouldn't work for searching, as you'd get hits for irrelevant results. 

The only other thing I can think of is perhaps modifying 
biblio-zebra-indexdefs.xsl to send the input data twice. Once with the hyphen 
and once without the hyphen. That would be hugely laborious though I think. (I 
just noticed we have a chopPunctuation template in biblio-zebra-indexdefs.xsl 
which I don't think actually gets used.)

I did notice something interesting today when I was looking at ICU: 
http://userguide.icu-project.org/boundaryanalysis. Observe the following:

Line break:
|Parlez-|vous |français ?|

Word break:
|Parlez|-|vous| |français| |?|

At the moment, we use line break in ICU. I suppose there isn't a huge 
difference between the two. But I thought it was interesting. I hadn't really 
thought about it before. 

It feels like there should be a way of having "Mont-Royal" be indexed as 
"MontRoyal" as well as "Mont" and "Royal". Currently, they're indexed as "Mont" 
and "Royal", retrieving relevant "Mont-Royal" only records would require using 
an exact match phrase search to require the proximity of "Mont Royal" in order 
to get a hit. It would be nice for "Mont-Royal" to retrieve "MontRoyal" while 
"Royal" would retrieve indexed "Royal" records. 

I wonder what Lucene-based search engines like Solr and Elasticsearch do 
there...

David Cook
Systems Librarian
Prosentient Systems
72/330 Wattle St
Ultimo, NSW 2007
Australia

Office: 02 9212 0899
Direct: 02 8005 0595

-Original Message-

Date: Tue, 24 Sep 2019 21:55:07 +0200
From: Katrin Fischer 
To: koha@lists.katipo.co.nz
Subject: Re: [Koha] How to make the Koha/Zebra search ignore hyphens?
Message-ID: 
Content-Type: text/plain; charset=utf-8; format=flowed

Hi Michael,

we looked into this ages ago and it didn't seem possible to achieve both
- treating hyphen (-) as a space and not a space at the same time. Maybe
we missed something - If there is a solution, I'd be interested in a
how-to! :)

Katrin




signature.asc
Description: PGP signature
___
Koha mailing list  http://koha-community.org
Koha@lists.katipo.co.nz
https://lists.katipo.co.nz/mailman/listinfo/koha

Re: [Koha] How to make the Koha/Zebra search ignore hyphens?

[dcook]

Hi Michael,

Your experience suggests to me that you're using Zebra 2.0.59 (which is the 
package available in the official Debian repositories). There is a bug in that 
version which causes hyphens to cause an incorrect truncation so that 
"Sinti-Swing" becomes "Sinti". If you use the Indexdata Debian repository and 
upgrade to the latest version of Zebra (or any version higher than 2.0.59 such 
as 2.0.60), you shouldn't have that problem anymore. (Debian doesn’t have an 
active maintainer for idzebra-2.0 if I recall correctly, so it's never going to 
be fixed in Debian, unless someone new steps forward. I've thought about doing 
it, but I have enough responsibilities already, and the workaround here is 
fairly trivial. That said, we as a community should probably do more with the 
Koha instructions to warn about this problem...)

I warned in my original email that you will have to modify words-icu.xml and 
phrases-icu.xml to get the behaviour that you're wanting as well.  You'll want 
to add a "transliterate" or "transform" rule before the "tokenize" rule to 
remove the hyphens. I don't know the exact rule you'll need, so you'll have to 
experiment a bit. You can read more about that at 
https://software.indexdata.com/yaz/doc/yaz-icu.html. 

If you upgrade your Zebra and modify your ICU chain files, I think you should 
be able to achieve the behaviour you're wanting. 

Take the time to fully read the documentation at 
https://software.indexdata.com/yaz/doc/yaz-icu.html, as you can use yaz-icu to 
test the ICU configuration directly without having to reindex Zebra every time. 
Note that you may have to install yaz-icu as I don't know that it's installed 
by default on Debian when you install idzebra. (I rarely use Debian/Ubuntu for 
Koha, so my exact experiences can be a bit different.)

Actually, I'm going to do a little test myself.

Standard words-icu.xml:
echo "Sinti-Swing" | yaz-icu -c words-icu.xml
1 1 'sinti' 'Sinti'
2 1 'swing' 'Swing'
See that there are two separate tokens there. 

Using the following words-icu.xml with a transform rule before the tokenize 
rule:

  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  


echo "Sinti-Swing" | yaz-icu -c words-icu.xml
1 1 'sintiswing' 'SintiSwing'
echo "Sintiswing" | yaz-icu -c words-icu.xml
1 1 'sintiswing' 'Sintiswing'

Now you can see that there's just 1 token. 

If I were you, I'd experiment a bit, as I naively wrote that transform rule 
without thinking too much. There might be cases where you don't want to remove 
the hyphen. For example, a French search for "Mont-Royal" might want it to be 
normalized as "mont royal" and tokenized into "mont" and "royal", so that 
keyword searches for "mont" or "royal" will still match the record. 

Note that the transliterate rules are very powerful. For example, you could 
replace that transform rule I added with one of the following:



echo "Sinti-Swing" | yaz-icu -c words-icu.xml
1 1 'sintiswing' 'SintiSwing'

Take a look at  which already 
exists to remove hyphens when they follow a number. 

What I'm trying to say is that the ICU rules are very powerful, but you have to 
be careful with how you use them. While it's trivial to fix the Sinti-Swing 
example, creating that "fix" might actually "break" something else. I think it 
comes down to trade-offs, and that's something that you'll have to think about 
as you're configuring your ICU rules.

Remember that this file is used both at index time *and* search time (as far as 
I know). Rules that might make sense at index time might not make sense at 
search time. I'm not familiar with hyphen usage in German, so I wouldn't really 
know what would make sense. 

Anyway, I hope that's more helpful!

David Cook
Systems Librarian
Prosentient Systems
72/330 Wattle St
Ultimo, NSW 2007
Australia

Office: 02 9212 0899
Direct: 02 8005 0595

-Original Message-
From: Michael Kuhn  
Sent: Thursday, 26 September 2019 4:59 AM
To: dc...@prosentient.com.au; koha@lists.katipo.co.nz
Subject: Re: [Koha] How to make the Koha/Zebra search ignore hyphens?

Hi David

 > I'm glad that I got you a bit further on your journey. It's a shame  > about 
 > having to use the CHR indexing. You can find more information  > here at 
 > https://software.indexdata.com/zebra/doc/character-map-files.html.
 >
 > After reading through that, I'm thinking perhaps that CHR indexing  > can't 
 > help you.

Thanks for your assessment!

 > You could ask Indexdata for more information, but I'm guessing it  > can't 
 > be done with CHR. It should be doable with ICU though.

So I tried to change the Koha-Standard CHR to ICU according to 
https://wiki.koha-community.org/wiki/ICU_chains_configuration, just using the 
original configuration of "words-icu.xml" and "phrases-icu.xml", then 
restarting Zebra and reindexing. But getting a very unexpected result: Now a 
catalog search

* for "Sintiswing" shows 1 hit

* for "Sinti-Swing" shows 4'222 hits, the hyphen seems to be ignored completely 
and 

Re: [Koha] How to make the Koha/Zebra search ignore hyphens?

[dcook]

Hi Michael, 

I'm glad that I got you a bit further on your journey. It's a shame about 
having to use the CHR indexing. You can find more information here at 
https://software.indexdata.com/zebra/doc/character-map-files.html. 

After reading through that, I'm thinking perhaps that CHR indexing can't help 
you. 

You could ask Indexdata for more information, but I'm guessing it can't be done 
with CHR. It should be doable with ICU though. 

David Cook
Systems Librarian
Prosentient Systems
72/330 Wattle St
Ultimo, NSW 2007
Australia

Office: 02 9212 0899
Direct: 02 8005 0595

-Original Message-
From: Michael Kuhn  
Sent: Wednesday, 25 September 2019 4:47 AM
To: dc...@prosentient.com.au; koha@lists.katipo.co.nz
Subject: Re: [Koha] How to make the Koha/Zebra search ignore hyphens?

Hi David

Many thanks for your reply and the hints!

After a standard installation of Koha 18.11 the CHR indexing is used, thus the 
configuration is done in file "word-phrase-utf.chr".

A catalog search
* for "Sintiswing" shows 1 hit
* for "Sinti-Swing" shows 18 hits, the hyphen is used as a breaking character, 
so any record containing "Sinti-Swing" or "Sinti" and "Swing" 
is found, but not "Sintiswing"

I changed the following line, omitting the hyphen (between comma and dot):

space
{\001-\040}!"#$%&'\()*+,./:;<=>?@\[\\]^_`\{|}~’{\x88-\x89}{\x98-\x9C}¡¿«»

After a Zebra reindexing a catalog search
* for "Sintiswing" shows 1 hit
* for "Sinti-Swing" now shows only 8 hits, the hyphen is no more used as a 
breaking character, so any record containing "Sinti Swing" or "Sinti-Swing" is 
found, but not "Sintiswing"

I also tried to add "map (-) @" but this leads to the original results.

In short: My change of configuration didn't lead to the desired result... If 
searching for "Sintiswing" also "Sinti-Swing" should be found, and vice versa. 
This is not the case.

Since I couldn't find any documentation about CHR indexing - does anyone know 
where to find out more about the CHR way of indexing?

Best wishes: Michael
--
Geschäftsführer · Diplombibliothekar BBS, Informatiker eidg. Fachausweis Admin 
Kuhn GmbH · Pappelstrasse 20 · 4123 Allschwil · Schweiz T 0041 (0)61 261 55 61 
· E m...@adminkuhn.ch · W www.adminkuhn.ch



Am 19.09.19 um 03:29 schrieb dc...@prosentient.com.au:
> Hi Michael,
> 
> That's really interesting. I assume that you're using ICU indexing?
> 
> You could update "phrases-icu.xml" and "words-icu.xml" to strip out hyphens. 
> You would need to re-index all your records afterwards though.
> 
> I haven't actually tested that particular change, but just taking a little 
> look with both ICU and CHR and it looks like hyphens are used to tokenize. 
> Currently, when you search "Tee-Ei", you're actually searching for "Tee" and 
> "Ei".
> 
> If you're using ICU, you could add a transform rule before the tokenize rule 
> to remove the hyphen. This would prevent it from tokenizing and then "Tee-Ei" 
> and "Teeei" should retrieve the same records.
> 
> Beware also that this is a universal change. You might want to check to see 
> if there are hyphens that shouldn't be removed. If so, you may need to make a 
> more complex rule to try to just capture the desired cases.
> 
> If you're using CHR, you can take a look at word-phrase-utf.chr and remove - 
> from the "Breaking characters" section. You may or may not also need to map 
> it. I'm less familiar with CHR indexing.
> 
> Anyway, I hope that helps.
> 
> David Cook
> Systems Librarian
> Prosentient Systems
> 72/330 Wattle St
> Ultimo, NSW 2007
> Australia
> 
> Office: 02 9212 0899
> Direct: 02 8005 0595
> 
> -Original Message-
> 
> Date: Wed, 18 Sep 2019 22:46:15 +0200
> From: 
> To: "Koha : access" 
> Subject: [Koha] How to make the Koha/Zebra search ignore hyphens?
> Message-ID: <5b63f3b4-76c1-c1f8-f35a-6a33e3b0a...@adminkuhn.ch>
> Content-Type: text/plain; charset=utf-8; format=flowed
> 
> Hi
> 
> We have found that, at least in German, there are words or combinations
> of words that can be written in different ways, and both are correct and
> are meaning the same, e. g.
> 
> * Ultraschallmessgerät = Ultraschall-Messgerät
> * Sintiswing = Sinti-Swing
> * Teeei = Tee-Ei
> * Haftpflichtversicherungsgesellschaft =
> Haftpflicht-Versicherungsgesellschaft
> 
> This is a general concept in German, so it makes no sense to add a "used
> for/see from:" in the authority data. Anyway, such words can exist
> everywhere in the bibliographic record, not only in fields linked to
> authority fields.
> 
> Now the question: is there a way how to teach Koha (or Zebra) to look
> for the second term also when the first term is searched, and vice
> versa? Or shorter: Just to ignore the hyphens? Using the standard
> configuration Koha will not find the second term if the first one is
> searched, and vice bversa.
> 
> We would appreciate any hint or tip!
> 
> Best wishes: Michael
> 





signature.asc
Description: PGP signature

Re: [Koha] How to make the Koha/Zebra search ignore hyphens?

[dcook]

Hi Michael,

That's really interesting. I assume that you're using ICU indexing? 

You could update "phrases-icu.xml" and "words-icu.xml" to strip out hyphens. 
You would need to re-index all your records afterwards though.

I haven't actually tested that particular change, but just taking a little look 
with both ICU and CHR and it looks like hyphens are used to tokenize. 
Currently, when you search "Tee-Ei", you're actually searching for "Tee" and 
"Ei". 

If you're using ICU, you could add a transform rule before the tokenize rule to 
remove the hyphen. This would prevent it from tokenizing and then "Tee-Ei" and 
"Teeei" should retrieve the same records. 

Beware also that this is a universal change. You might want to check to see if 
there are hyphens that shouldn't be removed. If so, you may need to make a more 
complex rule to try to just capture the desired cases. 

If you're using CHR, you can take a look at word-phrase-utf.chr and remove - 
from the "Breaking characters" section. You may or may not also need to map it. 
I'm less familiar with CHR indexing. 

Anyway, I hope that helps. 

David Cook
Systems Librarian
Prosentient Systems
72/330 Wattle St
Ultimo, NSW 2007
Australia

Office: 02 9212 0899
Direct: 02 8005 0595

-Original Message-

Date: Wed, 18 Sep 2019 22:46:15 +0200
From:   
To: "Koha : access" 
Subject: [Koha] How to make the Koha/Zebra search ignore hyphens?
Message-ID: <5b63f3b4-76c1-c1f8-f35a-6a33e3b0a...@adminkuhn.ch>
Content-Type: text/plain; charset=utf-8; format=flowed

Hi

We have found that, at least in German, there are words or combinations 
of words that can be written in different ways, and both are correct and 
are meaning the same, e. g.

* Ultraschallmessgerät = Ultraschall-Messgerät
* Sintiswing = Sinti-Swing
* Teeei = Tee-Ei
* Haftpflichtversicherungsgesellschaft = 
Haftpflicht-Versicherungsgesellschaft

This is a general concept in German, so it makes no sense to add a "used 
for/see from:" in the authority data. Anyway, such words can exist 
everywhere in the bibliographic record, not only in fields linked to 
authority fields.

Now the question: is there a way how to teach Koha (or Zebra) to look 
for the second term also when the first term is searched, and vice 
versa? Or shorter: Just to ignore the hyphens? Using the standard 
configuration Koha will not find the second term if the first one is 
searched, and vice bversa.

We would appreciate any hint or tip!

Best wishes: Michael
-- 
Geschäftsführer · Diplombibliothekar BBS, Informatiker eidg. Fachausweis
Admin Kuhn GmbH · Pappelstrasse 20 · 4123 Allschwil · Schweiz
T 0041 (0)61 261 55 61 · E m...@adminkuhn.ch · W www.adminkuhn.ch


--

Subject: Digest Footer

___
Koha mailing list
Koha@lists.katipo.co.nz
https://lists.katipo.co.nz/mailman/listinfo/koha


--

End of Koha Digest, Vol 167, Issue 15
*



signature.asc
Description: PGP signature
___
Koha mailing list  http://koha-community.org
Koha@lists.katipo.co.nz
https://lists.katipo.co.nz/mailman/listinfo/koha

Re: [Koha] [Koha-devel] Problems searching callnumbers with Koha and ICU

[dcook]

HI again, Mason,

I just remembered a little trick that you might find useful.

Try the following: 
echo "PZ 7 .W663 1984" | yaz-icu -x -c /path/to/phrases-icu.xml
echo "PZ 7 .W663 1984" | yaz-icu -x -c /path/to/words-icu.xml

That should show you how the string is normalized and tokenized for indexing
with ICU. 

You should see the same thing when you're using yaz-client, but this can be
a bit more convenient I reckon.

David Cook
Systems Librarian
Prosentient Systems
72/330 Wattle St
Ultimo, NSW 2007
Australia

Office: 02 9212 0899
Direct: 02 8005 0595

-Original Message-
From: koha-devel-boun...@lists.koha-community.org
 On Behalf Of
dc...@prosentient.com.au
Sent: Wednesday, 10 July 2019 5:05 PM
To: 'Mason James' ; koha@lists.katipo.co.nz;
koha-de...@lists.koha-community.org
Subject: Re: [Koha-devel] Problems searching callnumbers with Koha and ICU

Hi Mason,

Can you tell us what version of Zebra you're running? And what is your exact
query? 

According to https://packages.debian.org/stretch/idzebra-2.0, you're
probably running Zebra 2.0.59, unless you're pulling packages from
Indexdata's APT repository. 

I discovered a ICU bug in Zebra 2.0.59 back in February 2015, which could
very well be impacting you now. At the time, I thought it was just an issue
when hyphens were used in search terms, but I've had the same problem with
spaces lately when using "se,phr,ext" (which uses the phrase register rather
than the word register) with Zebra 2.0.59 on Debian. 

I think most people using ICU are using Zebra from Indexdata's APT
repositories. I had an issue with that recently but I'm going to revisit it
soon. 

I have a few other ICU related questions that I have asked Indexdata, but so
far I haven't heard back. That's mostly about how normalization and
tokenization is done at search time vs index time, as I don't think the
documentation is clear about that. 

(For instance, https://software.indexdata.com/zebra/doc/icuchain-files.html
says " The ICU chain files defines a chain of rules which specify the
conversion process to be carried out for each record string for indexing.
Both searching and sorting is based on the sort normalization that ICU
provides. This means that scan and sort will return terms in the sort order
given by ICU." Which to me sounds like different rules are used for indexing
and searching/sorting, which is consistent with my testing. I think
search/sort uses default ICU settings while indexing uses custom settings
and we replace apostrophes with a space when indexing in the word register
but search replaces apostrophes with nothing which creates tokenization
issues that don't match up, but I digress...)

Relevant reading:
1. Look for ZEB-664 in https://software.indexdata.com/zebra/doc/NEWS
2. Robin opened a bug report in Debian but it never went anywhere:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=777515;msg=5
3.
https://github.com/indexdata/idzebra/commit/704fd190292cb771df94553b0ed6f9f4
b71660a6
4. https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16581

David Cook
Systems Librarian
Prosentient Systems
72/330 Wattle St
Ultimo, NSW 2007
Australia

Office: 02 9212 0899
Direct: 02 8005 0595

-Original Message-
From: koha-devel-boun...@lists.koha-community.org
 On Behalf Of Mason James
Sent: Wednesday, 10 July 2019 3:54 PM
To: koha@lists.katipo.co.nz; koha-de...@lists.koha-community.org
Subject: [Koha-devel] Problems searching callnumbers with Koha and ICU

Hi Folks
Has anyone hit a problem searching callnumbers with Koha and ICU -
specifically callnumbers with SPACE ' ' characters?
An example problematic callnumber is 'PZ 7 .W663 1984'
 
Or, has anyone had *success* searching callnumbers with ICU? :) Either way,
I'd be curious to hear from you

I tested on Koha 18.05.12 and Debian 9.8


Cheers, Mason
___
Koha-devel mailing list
koha-de...@lists.koha-community.org
http://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/




signature.asc
Description: PGP signature
___
Koha mailing list  http://koha-community.org
Koha@lists.katipo.co.nz
https://lists.katipo.co.nz/mailman/listinfo/koha

Re: [Koha] [Koha-devel] Problems searching callnumbers with Koha and ICU

[dcook]

Hi Mason,

Can you tell us what version of Zebra you're running? And what is your exact
query? 

According to https://packages.debian.org/stretch/idzebra-2.0, you're
probably running Zebra 2.0.59, unless you're pulling packages from
Indexdata's APT repository. 

I discovered a ICU bug in Zebra 2.0.59 back in February 2015, which could
very well be impacting you now. At the time, I thought it was just an issue
when hyphens were used in search terms, but I've had the same problem with
spaces lately when using "se,phr,ext" (which uses the phrase register rather
than the word register) with Zebra 2.0.59 on Debian. 

I think most people using ICU are using Zebra from Indexdata's APT
repositories. I had an issue with that recently but I'm going to revisit it
soon. 

I have a few other ICU related questions that I have asked Indexdata, but so
far I haven't heard back. That's mostly about how normalization and
tokenization is done at search time vs index time, as I don't think the
documentation is clear about that. 

(For instance, https://software.indexdata.com/zebra/doc/icuchain-files.html
says " The ICU chain files defines a chain of rules which specify the
conversion process to be carried out for each record string for indexing.
Both searching and sorting is based on the sort normalization that ICU
provides. This means that scan and sort will return terms in the sort order
given by ICU." Which to me sounds like different rules are used for indexing
and searching/sorting, which is consistent with my testing. I think
search/sort uses default ICU settings while indexing uses custom settings
and we replace apostrophes with a space when indexing in the word register
but search replaces apostrophes with nothing which creates tokenization
issues that don't match up, but I digress...)

Relevant reading:
1. Look for ZEB-664 in https://software.indexdata.com/zebra/doc/NEWS
2. Robin opened a bug report in Debian but it never went anywhere:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=777515;msg=5 
3.
https://github.com/indexdata/idzebra/commit/704fd190292cb771df94553b0ed6f9f4
b71660a6
4. https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16581

David Cook
Systems Librarian
Prosentient Systems
72/330 Wattle St
Ultimo, NSW 2007
Australia

Office: 02 9212 0899
Direct: 02 8005 0595

-Original Message-
From: koha-devel-boun...@lists.koha-community.org
 On Behalf Of Mason James
Sent: Wednesday, 10 July 2019 3:54 PM
To: koha@lists.katipo.co.nz; koha-de...@lists.koha-community.org
Subject: [Koha-devel] Problems searching callnumbers with Koha and ICU

Hi Folks
Has anyone hit a problem searching callnumbers with Koha and ICU -
specifically callnumbers with SPACE ' ' characters?
An example problematic callnumber is 'PZ 7 .W663 1984'
 
Or, has anyone had *success* searching callnumbers with ICU? :) Either way,
I'd be curious to hear from you

I tested on Koha 18.05.12 and Debian 9.8


Cheers, Mason
___
Koha-devel mailing list
koha-de...@lists.koha-community.org
http://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/



signature.asc
Description: PGP signature
___
Koha mailing list  http://koha-community.org
Koha@lists.katipo.co.nz
https://lists.katipo.co.nz/mailman/listinfo/koha

Re: [Koha] [Koha-devel] New OPAC design

[dcook]

It's 11am April 2nd in Australia and... yep. Yep. Yep. Fridolin is a wizard. 

David Cook
Systems Librarian
Prosentient Systems
72/330 Wattle St
Ultimo, NSW 2007
Australia

Office: 02 9212 0899
Direct: 02 8005 0595

-Original Message-
From: koha-devel-boun...@lists.koha-community.org 
 On Behalf Of Paul Poulain
Sent: Monday, 1 April 2019 10:57 PM
To: koha-de...@lists.koha-community.org; koha@lists.katipo.co.nz
Subject: [Koha-devel] New OPAC design

Kia ora, hoping you're all enjoying the new month starting,

We (BibLibre) think that the default OPAC layout is not adapted to the youngest 
audience. That's why we've decided to create a new design for the OPAC, that 
will be soon submitted for inclusion in Koha 19.05. We really hope you'll enjoy 
this new design.

We have set it on our demo instance, you can have a look here : 
https://demo.biblibre.com/

PS: our customers will have this design automatically set during the next 
update.

--
Paul Poulain, Associé-gérant / co-owner
BibLibre, Services en logiciels libres pour les bibliothèques BibLibre, Open 
Source software and services for libraries

___
Koha-devel mailing list
koha-de...@lists.koha-community.org
http://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/



signature.asc
Description: PGP signature
___
Koha mailing list  http://koha-community.org
Koha@lists.katipo.co.nz
https://lists.katipo.co.nz/mailman/listinfo/koha