- Koha - lists.katipo.co.nz

Re: [Koha] MySQL database server, dedicated vs virtual
by Paul A 05 Dec '16

05 Dec '16

At 02:02 PM 12/4/2016 +0000, Marcel de Rooy wrote: >Please note: >Staying at Koha 3.8 is not recommended. The current release (16.11 == >3.26) is already 9(!) release cycles behind.. >And I would not advise others to do so. Marcel -- I don't know how you could read my comments as a "recommendation" or "advice" to stay with Koha 3.8.24. I mentioned, in response to RG's post "... was about 60-80% slower... ", that we had done some lengthy analysis of search speed (which I carried out with the assistance of the the Koha community and openly made available) and made the disappointing decision to remain with that version, under our specific circumstances. And I concluded with "YMMV" which stands for "your mileage might vary." Perhaps I should have been clearer: Koha was our indisputable choice for an OPAC (3.4.x) back in 2011; we are not a lending library, so the undoubted enhancements for lending libraries are irrelevant to our needs; the corollary is that if such enhancements have negative effects on our requirements, we very definitely look at them (sandbox level) but will not use them in production (i.e. on the public web interface.) Our production servers are all Ubuntu LTS based: this is a two to five year cycle; we do not have the budget or necessary volunteer hours to review monthly or bi-monthly changes (except security concerns); our overriding concern is total, hands-off stability; I have no idea if we are the only Koha-based library that uses a similar LTS approach. Koha 3.8.24 was released 5/29/2014, corresponding to the Ubuntu 14 LTS cycle. We recently upgraded two of our production servers to Ubuntu 16 LTS for other databases, but unless I am mistaken Koha 16.11 does not install (or at least not easily in our experience, and we have tried) on that o/s. So we maintained an additional, dedicated 14 server (with three years remaining Ubuntu support to 2019) for the OPAC when we followed the Ubuntu cycle. Again, this was disappointing, and again this represents only our very specific needs. So, when I say "your mileage might vary" I mean exactly that -- we probably are atypical of many Koha users, but are extremely happy and proud of our Koha OPAC -- so, if it wasn't clear, let me state that our analysis of search speed is *not* any sort of recommendation. Best regards -- Paul >Marcel > > >________________________________ >Van: Koha <koha-bounces(a)lists.katipo.co.nz> namens Paul A ><paul.a(a)navalmarinearchive.com> >Verzonden: vrijdag 2 december 2016 21:53 >Aan: koha >Onderwerp: Re: [Koha] MySQL database server, dedicated vs virtual > >Roger, > >We also looked into the "search performance" last year. We are not a >lending library, so cataloguing and OPAC are our primary concerns. Please >see <http://navalmarinearchive.com/z_koha/> for the detailed tech analysis >and conclusions. > >You mention below that "Koha does not benefit a lot from multiple CPU cores >since each CGI request is typically processed by one CPU except for the >Zebra searches and database queries which run as separate processes." > >I talked to Intel about CPU core cross-threading as it was a very obvious, >high-load, show-stopper with Zebra. The Zebra author never replied to my >queries. Intel were not optimistic, as kernel (and software) were not their >bailliwick. I do not know if Plack or Elastic have worked around this. > >These are hardware (perhaps software usage of core capability), not Koha, >restrictions. Tweaking memcached can have appreciable benefits. But the >bottom line remains that if a single CPU core hits 101-104%, search >functions descend into the "swimming upstream in treacle" world. > >We made the very conscious (but disappointing) decision to stay with Koha >3.8.24 based on our test results. I do spend quite some time testing later >versions at "sandbox" level, but have not been able to reproduce "older" >search speed. > >YMMV -- Paul >Production: Koha 3.8.24 on 14.04.2 LTS (GNU/Linux 3.13.0-43-generic >x86_64), 8-core I7 processors, 64 Gigs RAM, all SSD drives. > > > > >At 06:47 PM 12/2/2016 +0100, Roger Grossmann wrote: > > >Hi Tobias, > > > >a few month ago we did comparisons measuring the Koha-OPAC-Search > >performance with plack and memcached enabled using version 3.22. > >Our tests were not scientifically organised. We wanted to gather > >experience running Koha in different environments. We used the same MySQL > >database and Koha version in all environments. We did two types of OPAC > >searches on a limited collection of about 50.000 titles: an 'a*'-search of > >the complete word index and some special searches with fixed title search > >terms. > >We tested the following environments: > > > >1) Full Koha installation on a cloud provider hosted VM (the performance > >of VMs of the specific hoster were high ranked in published comparisons): > >Debian 8 on a cloud hosted system with virtual 2CPUs, 8 GB RAM, 256 SSD > >2) Full Koha installation on a physical server: Debian 8 on a well > >equipped physical machine with 64 GB RAM, 4 processors, 250 GB SSD > >3) Full Koha installation on a kvm-VM on a physical server: Debian 8 on a > >well equipped machine with 64 GB RAM, 4 core CPUs, kvm VM with Debian 8 > >4) Koha running on a physical machine like 2) and 3) with a separate > >physical DB Server. Koha and DB server were connected through a 1 GB > network. > > > >Our findings were the following: > >No wonder, environment 2 was the fastest. Running Koha on a physical > >server with the database on the same machine brings optimal performance. > >As a surprise, environment 3 had a performance closed to environment 2 > >with a difference of max. 5% performance loss. The kvm virtualiser seems > >to add very little overhead. Advantages of environment 3 are beside the > >high performance that it is possible to copy and save the VM doing updates > >and so on. We did not test running multiple kvm-VMs on the same host. > >Rather than running instances in separate VMs, Koha's concept of managing > >instances makes the use of one host very efficient. Running multiple > >instances in one machine requires less maintenance than running multiple > >VMs each with one Koha instance. > >Environment 1 was about 60-80% slower than environment 2. We got varying > >results probably depending on the load of the provider based environment. > >Server requests in environment 4 took double the time of environment 1. It > >seemed that the network latency and transmission of data between DB Server > >and Koha is a bottleneck here. > > > >We can recommend option 3. It brings an optimum of performance with the > >flexibility of a virtualised environment. For a single Koha instance you > >probably do not need more than 2 CPUs cores. Typically you can improve the > >database performance with an optimised database configuration > >(specifically the page buffer if you have enough RAM). So using >=16 GB > >RAM should be well equipped from my perspective. > >Key parameters to speed up Koha were in our tests the hard disk speed (use > >SSDs) and CPU speed. Koha does not benefit a lot from multiple CPU cores > >since each CGI request is typically processed by one CPU except for the > >Zebra searches and database queries which run as separate processes. > >Additional CPU cores can be useful if the load is high on the server when > >processing many parallel requests. > > > >Doing searches, the Zebra indexer impacts the speed very much. In our > >tests Zebra took about 50% or more of the request time. I assume that the > >planned change to Elasticsearch will result in performance improvements in > >the future. > > > >Best regards, > >Roger > > > >-- > >LMSCloud GmbH > >Roger GroÃmann - GeschÃÂ¤ftsfÃÂ¼hrer > >Konrad-Zuse-Platz 8 - D-81829 MÃÂ¼nchen > >e roger.grossmann(a)lmscloud.de > >w www.lmscloud.de<http://www.lmscloud.de> > > > > > Am 01.12.2016 um 18:03 schrieb tobias carlsson > > <tobias.carlsson(a)bitlabbet.se>: > > > > > > > > > > > > Hi! > > > > > > I'm currently working with a Koha implementation in a public library in > > > southern Sweden. Our installation (it's not live yet) is currently on a > > > virtual machine running Ubuntu Server 14.04 LTS and the version of Koha > > > is 3.22. The MySQL database also resides on the same virtual server. > > > > > > I've tried some at home - on a Koha test server running under Debian > > > with the MySQL database on a machine running Ubuntu Server 14.04 (with a > > > Core i3 4170 @3,7 GHz (stock), with a quite slow Western Digital Red. > > > The difference between running on "bare metal" and virtual seem rather > > > striking. Is there anyone out there who have moved from virtual running > > > databases to physical? What can you tell us about this? > > > > > > I know that a database server should run with good I/O performance and a > > > fast CPU and lots of RAM and so on, but since I'm a librarian, not an > > > engineer (that sounded familiar...), I have limited experience of > > > dealing with servers in a large scale and I'm no expert on databases. > > > > > > I'm aware of database optimizations and the use of plack and memcached, > > > but running the database on a "bare metal" server with a high clock, > > > made me start thinking of how we should deal with the database. It seems > > > to me that many libraries use virtual servers for everything, even > > > databases and that it's common to run Koha and server on the same > > > (virtual) instance. > > > > > > Please share your experiences and thoughts about this. > > > > > > Best regards, > > > > > > Tobias Carlsson > > > Systems Librarian and IT Technician > > > > > > Currently working with Koha at Vaggeryds bibliotek (Vaggeryd public > > > library) in Sweden. > > > Working as a Systems Librarian at Gislaveds bibliotek. > > > > > > > > > _______________________________________________ > > > Koha mailing list http://koha-community.org > > > Koha(a)lists.katipo.co.nz > > > https://lists.katipo.co.nz/mailman/listinfo/koha > >Koha --Discussion list for the Koha Library >system<https://lists.katipo.co.nz/mailman/listinfo/koha> >lists.katipo.co.nz >To see the collection of prior postings to the list, visit the Koha >Archives. Using the Koha Mailing List: To post a message to all the list ... > > > > > > >_______________________________________________ > >Koha mailing list http://koha-community.org > >Official Website of Koha Library Software<http://koha-community.org/> >koha-community.org >Koha Library Software The world's first free and open source library >system Koha is a fully featured, scalable library management system. >Development is sponsored by ... > > > > >Koha(a)lists.katipo.co.nz > >https://lists.katipo.co.nz/mailman/listinfo/koha > >Koha --Discussion list for the Koha Library >system<https://lists.katipo.co.nz/mailman/listinfo/koha> >lists.katipo.co.nz >To see the collection of prior postings to the list, visit the Koha >Archives. Using the Koha Mailing List: To post a message to all the list ... > > > > >--- >Maritime heritage and history, preservation and conservation, >research and education through the written word and the arts. ><http://NavalMarineArchive.com> and <http://UltraMarine.ca> > >Canadian Society of Marine Artists<http://ultramarine.ca/> >ultramarine.ca >The Canadian Society of Marine Artists is a not-for-profit non-profit >administered by the Naval Marine Archive and is dedicated to Canadian >maritime art promotion ... > > > >[http://navalmarinearchive.com/ims/victory_2015.jpg]<http://navalmarinearchive.com/> > >Naval Marine Archive - The Canadian Collection<http://navalmarinearchive.com/> >navalmarinearchive.com >Naval Marine Archive - The Canadian Collection is a non-profit Canadian >charity dedicated to maritime history, conservation, marine research, >nautical education ... > > > > >_______________________________________________ >Koha mailing list http://koha-community.org > >Official Website of Koha Library Software<http://koha-community.org/> >koha-community.org >Koha Library Software The world's first free and open source library >system Koha is a fully featured, scalable library management system. >Development is sponsored by ... > > > >Koha(a)lists.katipo.co.nz >https://lists.katipo.co.nz/mailman/listinfo/koha > >Koha --Discussion list for the Koha Library >system<https://lists.katipo.co.nz/mailman/listinfo/koha> >lists.katipo.co.nz >To see the collection of prior postings to the list, visit the Koha >Archives. Using the Koha Mailing List: To post a message to all the list ... > > > >_______________________________________________ >Koha mailing list http://koha-community.org >Koha(a)lists.katipo.co.nz >https://lists.katipo.co.nz/mailman/listinfo/koha --- Maritime heritage and history, preservation and conservation, research and education through the written word and the arts. <http://NavalMarineArchive.com> and <http://UltraMarine.ca>

3 2

New opac detail view for records
by Pedro Amorim 05 Dec '16

05 Dec '16

Hello all, I'm just about to start diving into the core and figure out how the three different opac detail views are implemented (normal, marc and ISBD) so I can implement my own custom detail view and add a fourth one. However, and before I start doing so, I was wondering if anyone has done/attempted this before or at least if someone has some knowledge on what template files should I start and how to go about it. Thanks as always, Pedro Amorim

4 7

Re: [Koha] MySQL database server, dedicated vs virtual
by Paul A 05 Dec '16

05 Dec '16

At 04:56 PM 12/5/2016 +0000, Jonathan Druart wrote: >Paul, >Hum sounds like I already answered you the same things a few months ago... I'll reply off-list to Jonathan as it could possibly only create on-list noise... P.

1 0

Re: [Koha] What is the point of the Undo Import into catalogue feature?
by Paul A 05 Dec '16

05 Dec '16

At 01:28 PM 12/5/2016 +0000, Raymund Delahunty wrote: >I ran repeated tests for up to 48 hours or more. I think the indexes were >partly updated- 7K out of 13K "remained". I have two files to deal with >tomorrow (3K, and 30K small MARC records- bibs and items). I am tempted to >try the Undo again to see if it works. I am asking our support company >PTFS Europe about any issues there might be with the zebra indexer. If it >goes wrong again I'll ask for another index rebuild, and give up on the >Undo feature. I would agree with what François wrote re: Zebra. Just adding that the normal Koha "incremental" cron job appears to be bullet-proof for additions, and is normally totally reliable for "admin/staff" adds, deletes, edits, etc. We run it every minute and it's a matter of milliseconds. However, we have had times where a complete (bibs *and* auths) re-index was required, but by the time the cataloguers told me "what they had done" I could not reproduce it. So I now have a weekly cron job for a complete re-index. Although it looks "long" on an SSH screen, the actual down-time of the Zebra server is just a few seconds, so our cataloguers have been told to call me if in doubt, and I do it manually. I'm sure PTFS can sort this out for you. Paul >Ray Delahunty. > > >-----Original Message----- >From: Koha [mailto:koha-bounces@lists.katipo.co.nz] On Behalf Of Francois >Charbonnier >Sent: 05 December 2016 13:14 >To: koha(a)lists.katipo.co.nz >Subject: Re: [Koha] What is the point of the Undo Import into catalogue >feature? > >Hi, > >Have you waited long enough for zebra to re-index your catalogue ? To me, >what you are describing is not faulty. Once you reverted an imported >batch, it takes time to zebra to remove the records from the indexes. >Especially if you work with large files. > >If you waited long enough and the indexes never got updated, I would say >it's faulty, yes. But it you reverted the import and search for records >right away, I would say it's just zebra that hasn't been able to reindex >everything... > > >FranÃ§ois Charbonnier,

1 0

What's on in koha-devel #8
by Jonathan Druart 05 Dec '16

05 Dec '16

Hello librarians and developers, Koha 16.11 and its Debian packages have now been released [1]. As Mirko noted Debian Wheezy is no longer supported and Debian packages won't be provided for 3.22 [2]. I should also added that some important bugs have been reported recently and it may be better to wait for the 16.11.1 version to be released before upgrading [3, 4, 5]. Note that if you database password contain Unicode characters, you should also wait for bug 17720 (CSRF token is not generated correctly). = Refactoring = == Move to the Koha namespace == We keep on moving the C4::Members module code to the Koha namespace and a few subroutine of C4::Circulation are going to be moved as well [6]. == Remove the biblioitems.marcxml field == I have been asking for help on bug 17196 (Move marcxml out of the biblioitems table) for months now and this will certainly be my last attempt to get attention on it. As we are at the beginning of the release we should focus on it to get it pushed soon. That way we will have time to catch and fix bugs if we find some. == Rewrite of the upload feature = A month ago Marcel started to refactor the upload section [7]. This is the groundwork to start improvements in this area. Once this is pushed we will be able to add new features, so please test! = Template Toolkit syntax for notices = Kyle started a discussion some months ago [8] to switch from our home-made syntax for notices to the Template Toolkit syntax. That would bring us a lot of flexibility to write the notices. But to do so, we need a plan! We already started to support this syntax (inside 16.11) but then we have to decide what to do next. Currently the plan would be to replace the default syntax (bug 15278), then reveal in the editor that you can use this new syntax (bug 15277) and finally add documentation to help people writing/porting their own notices (bug 15276). We need to get opinions to know how we could move forward. Kyle is going to start a new topic on the Koha mailing list for that. Stay tuned! = Standardize our EXPORT = A bit more technically, I would need developer's attention on bug 17600 (Standardize the EXPORT). At the end of the last release, very bad bugs appeared at the last minute because of our circular dependencies and the way we export subroutines from routines. Everything is (quickly) explained on that bug and a patchset has been submitted for discussion. If you are aware of how we could fix that cleanly, please jump into the discussion. The next general IRC meeting is on December 7th, 14 UTC. https://wiki.koha-community.org/wiki/General_IRC_meeting_7_December_2016 The next dev IRC meeting is on December 14th, 13 UTC. https://wiki.koha-community.org/wiki/Development_IRC_meeting_14_December_20… Hope to see your there! Cheers, Jonathan [1] https://koha-community.org/koha-16-11-released-2 [2] http://lists.koha-community.org/pipermail/koha-devel/2016-November/043330.h… [3] Bug 17676 - Default COLLATE for marc_subfield_structure is not set [4] Bug 17344 - Can't set guarantor in quick add brief form [5] Bug 17709 - Article request broken [6] Bug 17677 - Move C4::Circulation code to the Koha namespace [7] Bug 17501 - Koha Objects for uploaded files [8] http://lists.koha-community.org/pipermail/koha-devel/2016-February/042316.h…

1 0

What is the point of the Undo Import into catalogue feature?
by Raymund Delahunty 05 Dec '16

05 Dec '16

We regularly import large files of MARC records into our Koha (16.05) database which have to be deleted at a later date… sometimes months later, and sometimes maybe 30,000 records. I have been using the Undo import (sort-of “unstage”) as I found this functionality astoundingly useful. It automated a task, reducing a tedious job to a couple of keystrokes. However I was dismayed to find that after a recent “Undo” of 13,000 records our database was left over 7,000 “phantom records”- they didn’t exist but the indexing had failed to remove all traces of them We were advised to use the batch record deletion tool, as the Undo feature wasn’t designed to be used in the way I was using it. “… it is meant to unstage records nearer to the point in time of being added”. (And what’s the point of that?) We had to have our database re-indexed to resolve the problem. Is there any point in the Undo feature if the indexer can’t cope? I hate to think what other dross I had left behind in earlier “Undos”! Ray Delahunty University of the Arts London This email and any attachments are intended solely for the addressee and may contain confidential information. If you are not the intended recipient of this email and/or its attachments you must not take any action based upon them and you must not copy or show them to anyone. Please send the email back to us and immediately and permanently delete it and its attachments. Where this email is unrelated to the business of University of the Arts London or of any of its group companies the opinions expressed in it are the opinions of the sender and do not necessarily constitute those of University of the Arts London (or the relevant group company). Where the sender's signature indicates that the email is sent on behalf of London Artscom Limited the following also applies: London Artscom Limited is a company registered in England and Wales under company number 02361261. Registered Office: University of the Arts London, 272 High Holborn, London WC1V 7EY

5 7

MySQL database server, dedicated vs virtual
by tobias carlsson 04 Dec '16

04 Dec '16

Hi! I'm currently working with a Koha implementation in a public library in southern Sweden. Our installation (it's not live yet) is currently on a virtual machine running Ubuntu Server 14.04 LTS and the version of Koha is 3.22. The MySQL database also resides on the same virtual server. I've tried some at home - on a Koha test server running under Debian with the MySQL database on a machine running Ubuntu Server 14.04 (with a Core i3 4170 @3,7 GHz (stock), with a quite slow Western Digital Red. The difference between running on "bare metal" and virtual seem rather striking. Is there anyone out there who have moved from virtual running databases to physical? What can you tell us about this? I know that a database server should run with good I/O performance and a fast CPU and lots of RAM and so on, but since I'm a librarian, not an engineer (that sounded familiar...), I have limited experience of dealing with servers in a large scale and I'm no expert on databases. I'm aware of database optimizations and the use of plack and memcached, but running the database on a "bare metal" server with a high clock, made me start thinking of how we should deal with the database. It seems to me that many libraries use virtual servers for everything, even databases and that it's common to run Koha and server on the same (virtual) instance. Please share your experiences and thoughts about this. Best regards, Tobias Carlsson Systems Librarian and IT Technician Currently working with Koha at Vaggeryds bibliotek (Vaggeryd public library) in Sweden. Working as a Systems Librarian at Gislaveds bibliotek.

5 4

Manual koha 16.11 broken link
by Hugo Agud 02 Dec '16

02 Dec '16

Dear all We're trying to read manual' s koha 16.11, but it seems it is broken and we can't access it. not: https://koha-community.org/documentation/ not: http://translate.koha-community.org/manual/master/en/pdf/Koha-16.11-koha-ma… not: http://manual.koha-community.org/16.11/en/ If anybody have downloaded or it has a functional link, I will thanks if you are able to share it with me or fix the link. Thanks you in advance Kindest Regards Hugo -- *Hugo Agud - Orex Digital * *www.orex.es <http://www.orex.es>* <http://www.orex.es/> [image: www.orex.es/koha] <http://www.orex.es/koha> [image: www.orex.es/vufind] <http://www.orex.es/vufind> <http://www.orex.es/omeka> Director Calle Sant Joaquin,117, 2º-3ª · 08922 Santa Coloma de Gramanet - Tel: 933 856 138 hagud(a)orex.es · http://www.orex.es/ No imprima este mensaje a no ser que sea necesario. Una tonelada de papel implica la tala de 15 árboles y el consumo de 250.000 litros de agua. Aviso de confidencialidad Este mensaje contiene información que puede ser CONFIDENCIAL y/o de USO RESTRINGIDO. Si usted no es el receptor deseado del mensaje (ni está autorizado a recibirlo por el remitente), no está autorizado a copiar, reenviar o divulgar el mensaje o su contenido. Si ha recibido este mensaje por error, por favor, notifíquenoslo inmediatamente y bórrelo de su sistema.

5 6

Re: [Koha] SIP2 Authentication
by Chris Cormack 01 Dec '16

01 Dec '16

Are you seeing anything in the syslog (on the server) you should see the sip server starting etc. You installed with packages eh? And enabled SIP that way? Chris On 2 December 2016 6:53:11 AM NZDT, TOM BARBER <TOM.BARBER(a)adtran.com> wrote: >Hmm. I don’t see an entry in the syslog for the attempt. >I can see the interaction via Packet Capture. >Does the logging have to be enabled somewhere else to send that to >syslog? > > >regards, >tom > >From: Chris Cormack [mailto:chrisc@catalyst.net.nz] >Sent: Thursday, December 01, 2016 11:29 AM >To: TOM BARBER >Cc: Koha >Subject: Re: [Koha] SIP2 Authentication > >It worked for me when I tested it yesterday. > >What is the exact message you are seeing in the syslog when it fails? > >Chris >On 2 December 2016 5:53:10 AM NZDT, TOM BARBER ><TOM.BARBER(a)adtran.com<mailto:TOM.BARBER@adtran.com>> wrote: > >Thank you sir. I have initiated contact there. >Does anyone know if SIP2 auth has been tested and verified in release >16.11? > >regards, >tom > >From: Barton Chittenden [mailto:barton@bywatersolutions.com] >Sent: Thursday, December 01, 2016 10:34 AM >To: Christopher Davis >Cc: TOM BARBER; Koha >Subject: Re: [Koha] SIP2 Authentication > >Tom, > >You can talk to Kyle Hall on the #koha irc channel on OFTC > >You can connect via the web here: > >http://webchat.oftc.net/?channels=koha > >or there are instructions for connecting via an IRC client here: >https://koha-community.org/get-involved/irc/ > >Kyle's nick on irc is khall > >I'll make sure that he sees thiis email thread as well. > > >On Thu, Dec 1, 2016 at 10:48 AM, Christopher Davis > ><cgdavis(a)uintah.utah.gov<mailto:cgdavis@uintah.utah.gov<mailto:cgdavis@uintah.utah.gov%3cmailto:cgdavis@uintah.utah.gov>>> >wrote: >Tom, > >We are running Koha version 3.22.08.000. > >All the best, > >Christopher Davis, MLS >Systems & E-Services Librarian >Uintah County Library >cgdavis(a)uintah.utah.gov<mailto:cgdavis@uintah.utah.gov<mailto:cgdavis@uintah.utah.gov%3cmailto:cgdavis@uintah.utah.gov>> >(435) 789-0091 ext.261<tel:%28435%29%20789-0091%20ext.261> >uintahlibrary.org<http://uintahlibrary.org><http://uintahlibrary.org> >basinlibraries.org<http://basinlibraries.org><http://basinlibraries.org> >facebook.com/uintahcountylibrary<http://facebook.com/uintahcountylibrary<facebook.com/uintahcountylibrary%3chttp:/facebook.com/uintahcountylibrary>> >instagram.com/uintahcountylibrary<http://instagram.com/uintahcountylibrary<instagram.com/uintahcountylibrary%3chttp:/instagram.com/uintahcountylibrary>> > >On Wed, Nov 30, 2016 at 3:36 PM, TOM BARBER ><TOM.BARBER(a)adtran.com<mailto:TOM.BARBER@adtran.com<mailto:TOM.BARBER@adtran.com%3cmailto:TOM.BARBER@adtran.com>>> >wrote: > > Thank you. I will see if I can find contact info on him. >Are you running the latest 16.11 build? I am wondering if there is a >bug in it. > > regards, > tom > > -----Original Message----- >From: Christopher Davis >[mailto:cgdavis@uintah.utah.gov<mailto:cgdavis@uintah.utah.gov><mailto:cgdavis@uintah.utah.gov%3cmailto:cgdavis@uintah.utah.gov%3e>] > Sent: Wednesday, November 30, 2016 3:42 PM > To: TOM BARBER > Cc: Koha > Subject: Re: [Koha] SIP2 Authentication > > TomB, > >The person who you want to talk to about SIP2 issues is Kyle Hall. He >has helped my institution > >through our SIP-related issues and comes recommended by others as a >specialist with SIP. > > All the best, > > Christopher Davis, MLS > Systems & E-Services Librarian > Uintah County Library >cgdavis(a)uintah.utah.gov<mailto:cgdavis@uintah.utah.gov<mailto:cgdavis@uintah.utah.gov%3cmailto:cgdavis@uintah.utah.gov>> > (435) 789-0091 ext.261<tel:%28435%29%20789-0091%20ext.261> > uintahlibrary.org<http://uintahlibrary.org><http://uintahlibrary.org> >basinlibraries.org<http://basinlibraries.org><http://basinlibraries.org> >facebook.com/uintahcountylibrary<http://facebook.com/uintahcountylibrary<facebook.com/uintahcountylibrary%3chttp:/facebook.com/uintahcountylibrary>> >instagram.com/uintahcountylibrary<http://instagram.com/uintahcountylibrary<instagram.com/uintahcountylibrary%3chttp:/instagram.com/uintahcountylibrary>> > > >On Wed, Nov 30, 2016 at 1:51 PM, TomB ><tom.barber(a)adtran.com<mailto:tom.barber@adtran.com<mailto:tom.barber@adtran.com%3cmailto:tom.barber@adtran.com>>> >wrote: > > I am working on a wireless controller that supports SIP2 auth - I am > running Koha Version 16.11.00.000 > > I have tried to follow the SIP 2 Guide here: > https://wiki.koha-community.org/wiki/Koha_SIP2_server_setup > > But the best I can tell - it is extremely out of date. > Long story short - I can't get SIP 2 to function in this build. I am > sure it's a syntax problem somewhere but I can't see it. > > I have users set up in a Library, I have matched those users in the > SIPconfig.xml file. > Is the "institution -id" the same as the Library Code? > It appears that some of the naming convention has changed and the > SIPConfig.xml still uses the older terminology. > > Is there a SIP2 master out there that could yell at me and tell me how > to make this thing work? > > Thanks, > TomB > > > > -- > View this message in context: > http://koha.1045719.n5.nabble.com/SIP2-Authentication-tp5912467.html >Sent from the Koha-general mailing list archive at >Nabble.com<http://Nabble.com>. > >________________________________ > >Koha mailing list http://koha-community.org >Koha(a)lists.katipo.co.nz<mailto:Koha@lists.katipo.co.nz<mailto:Koha@lists.katipo.co.nz%3cmailto:Koha@lists.katipo.co.nz>> > https://lists.katipo.co.nz/mailman/listinfo/koha > > > >________________________________ > >Koha mailing list http://koha-community.org >Koha(a)lists.katipo.co.nz<mailto:Koha@lists.katipo.co.nz<mailto:Koha@lists.katipo.co.nz%3cmailto:Koha@lists.katipo.co.nz>> >https://lists.katipo.co.nz/mailman/listinfo/koha > >________________________________ > >Koha mailing list http://koha-community.org >Koha(a)lists.katipo.co.nz<mailto:Koha@lists.katipo.co.nz> >https://lists.katipo.co.nz/mailman/listinfo/koha > >-- >Sent from my Android device with K-9 Mail. Please excuse my brevity. -- Sent from my Android device with K-9 Mail. Please excuse my brevity.

3 2

SIP2 Authentication
by TomB 01 Dec '16

01 Dec '16

I am working on a wireless controller that supports SIP2 auth - I am running Koha Version 16.11.00.000 I have tried to follow the SIP 2 Guide here: https://wiki.koha-community.org/wiki/Koha_SIP2_server_setup But the best I can tell - it is extremely out of date. Long story short - I can't get SIP 2 to function in this build. I am sure it's a syntax problem somewhere but I can't see it. I have users set up in a Library, I have matched those users in the SIPconfig.xml file. Is the "institution -id" the same as the Library Code? It appears that some of the naming convention has changed and the SIPConfig.xml still uses the older terminology. Is there a SIP2 master out there that could yell at me and tell me how to make this thing work? Thanks, TomB -- View this message in context: http://koha.1045719.n5.nabble.com/SIP2-Authentication-tp5912467.html Sent from the Koha-general mailing list archive at Nabble.com.

5 6