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

How to get CAS based Single Sign On working?
by Koustubha Kale 25 May '15

25 May '15

Hi All, I have a situation where we have a main website based on Joomla. This Joomla site uses CAS to authenticate users. We would like users ( who have already logged in to the Joomla site via CAS) to be able to follow a link to Koha site and be logged in automatically ( e.g. Single Sign On ). I have got simple CAS ( not proxy CAS ) working with Koha ( version 3.2.6 ) using the same CAS server as used by Joomla site. Still when I login to Joomla site with CAS, and then go to Koha and click on login and follow the CAS login link, I am asked to fill up CAS login information again. How can this be avoided by using CAS SSO? I have read through http://wiki.koha-community.org/wiki/SSO_CAS_improvements and am confused by the statement "Note: simple sso cas support (no proxy) has been done already by biblibre, is in testing and should be released in Koha 3.2" in there. Does this statement mean that SSO is possible with simple CAS? If yes how to set it up? If not, I have also read through bugs 6012, 5630 and the CAS Proxy examples. Frankly I haven't been able to figure out how I can achieve the above required functionality based on all the reading. Any help is much appreciated.. Another related query is, Is it possible to automatically create users in Koha once they have authenticated with CAS? Regards, Koustubha Kale Anant Corporation Contact Details : Address : 103, Armaan Residency, R. W Sawant Road, Nr. Golden Dyes Naka, Thane (w), Maharashtra, India, Pin : 400601. TeleFax : +91-22-21720108, +91-22-21720109 Mobile : +919820715876 Website : http://www.anantcorp.com Blog : http://www.anantcorp.com/blog/?author=2

3 3

koha-3.00.00 make fails
by Rick Welykochy 28 Dec '13

28 Dec '13

Hi all, I have downloaded http://download.koha.org/koha-3.00.00.tar.gz and began installing it on Debian/etch (in a Linux vserver environment). 0. FINE: cd koha-3.00.00 1. FINE: perl Makefile.PL 2. FAIL: make : : : Manifying blib/man3/C4::UploadedFile.3pm Manifying blib/man3/C4::BackgroundJob.3pm Manifying blib/man3/opac::opac-dictionary.3pm Manifying blib/man3/serials::member-search.3pm /usr/bin/perl "-Iblib/arch" "-Iblib/lib" fix-perl-path.PL blib /usr/bin/perl "-Iblib/arch" "-Iblib/lib" rewrite-config.PL blib/KOHA_CONF_DIR/koha-conf.xml Bad arg length for Socket::inet_ntoa, length is 0, should be 4 at rewrite-config.PL line 67. make: *** [blib/KOHA_CONF_DIR/koha-conf.xml] Error 255 Any ideas what went wrong and how to fix? Aside: there were a couple of other problems with this "out of the box" debian based install of Koha 3.0 which had to be fixed along the way, e.g. seven missing perl modules and libgd not found. I'll report on the entire process from unpacking to a running Koha/3.00.00 once I get to the end. cheers rickw -- ________________________________________________________________ Rick Welykochy || Praxis Services || Internet Driving Instructor The manual said Windows XP/SP2 or better so I installed Linux.

4 5

Koha-index-daemon
by Partha Mukhopadhyay 01 Aug '13

01 Aug '13

3 4

Fedora packages // including PLACK support
by Nicholas van Rheede van Oudtshoorn 24 Jul '13

24 Jul '13

Hello all! For those that are interested, I've made a repository (the RPM version of a PPA :-) ) to install all of the requirements for koha 3.10 - including those needed to get plack up and running. The repo can be added by running: sudo wget " http://download.opensuse.org/repositories/home:/vanoudt/Fedora_17/home:vano…" -O /etc/yum.repos.d/koha.repo A Fedora 18 repo should also be available soon. (I'm running f18, the repo just isn't live yet). Also attached are some systemd service files. Simply copy them into /lib/sytemd/system, copy koha.env into /etc/koha and then enable them using systemctl enable kohazebra.service systemctl enable kohaopac.service systemctl enable kohaopac.service As for plack - WOW! This stuff is amazing. I've made some modifications to the psgi files so that they run using a normal installation from source, and also so that they redirect from an empty URL to the main opac/intranet page. I've attached the psgi files here (install them in /usr/share/koha/psgi ) if anyone is interested! A great new release! Hope these ramblings of mine are of some use to someone! Nicholas van Oudtshoorn Perth Bible College library.pbc.wa.edu.au

3 2

Re: [Koha-devel] RFC: Plugins QA
by Paul 10 Jul '13

10 Jul '13

At 07:17 AM 6/1/2013 -0700, BWS Johnson wrote: >Salvete! > >Tarballs, packages, gits (including vendors), stables, latest, bugs and >patches, wikis (various), tools, reports, live-DVDs, mailing lists, chat, >maybe more, and now plug-ins? Could we please look at what the >"open source" world is doing? Apache, SendMail, Perl, PostFix, >FireFox, Debian, Ubuntu, OpenOffice, LibreOffice ... are fairly stable >with an established security update capability. Even Java and MySQL are >simplifying. > > > I'm all for giving our developers the flexibility to deliver their > code in whatever form they have time to wrap it in. I might _like_ them > to do things my way, but I'm not paying them, and I never have. Agreed -- 100%. My concern is with the "final product", not the means of getting there. > What do you consider instable or insecure in particular? This thread started questioning the need for QA for plugins, *potentially* insecure. The instability issue is part perception/communication, part superb enthusiasm on the community/development side. But the fact remains that on 14 September 2012, we went live with Koha 3.8.4 which was the "cat's whiskers" just eight months ago. 3.8 is now "old stable", 3.10 is "stable" and 3.12 "development" is advertized (Wiki) equally prominently. And the Wiki continues: "If you're unsure what you want, go for the stable version. If you want to be a bit more conservative, go for the most recent old-stables release. Note that both of these are still very much a work in progress: they won't work perfectly just yet." There is, for a newcomer reading the Wiki, no "working perfectly" LTS (long term stable) release. My *opinion* is that we need (cf Ubuntu) a five year cycle -- 2 years "stable+security", 2 years continuing support, 1 year buffer zone -- this could be seen as maturity in the open-source world. > Many of those projects are quite large, so in my light, afford their > respective projects the ability to do things that we as a smaller project > might not be able to manage. I truly believe that Koha is no longer a "smaller project", but you make a valid point. > Many thanks to Robin and anyone else that helped with the packages. I > had whinged for ages that I'd love to just have an apt-get command. Agreed 100% -- although I have never used the packages. > >I had a "rather important" librarian from Quebec drop in, out >of the blue, yesterday to talk about Koha. Her group (37 libraries) had >previously been burned by a trial commercial implementation of Koha (no >need to quote names), so they're using Opals, but "liked the >idea" of Koha. First question: "stability?" > I am stymied by this. Completely, utterly flabbergasted. First, > whatever trash LibLime were selling wasn't Koha. I was somewhat careful not to quote names ;=} -- you could be right in your assumption, but at my age "my memory fails me ..." >Second, OPALS? As in >http://www.mediaflex.net/showcase.jsp?record_id=52 Yup. "OPALS, an open source ILS for school libraries and districts developed and supported by Media Flex earned top rankings in Company Satisfaction, Product Support, and Company Loyalty." See <http://www.librarytechnology.org/perceptions2012.pl> > One of the questions I posed to my students was "Is OPALS truly open > source if you have to beg for the code and a demo?" In terms of feature > comparison and breadth of adoption, it's not even close. It's well known > I've a soft spot in the granite thing that's meant to be my heart when it > comes to Koha, but I freely admit when I think we get beat. That is most > certainly not the case with Koha, and I wish them the best of luck > getting a consortium up and running in a multilingual capacity with that heap. I respect your opinion (but see Marshall Breeding's survey above.) If I knew more about Opals, I might well agree. > >I know that a number of you will ... whatever ... Paul's a pain in the >neck, doesn't understand, does his own thing, but the bottom line is that ><http://opac.navalmarinearchive.com/> >is fully functional and is intrinsically Koha. It's (reasonably) secure >(without https) and meets the needs of our users and librarians. It runs >itself with minimal ( < 1 hour/week statistically ) intervention by IT >personnel. > > So what's the problem? I'm truly sorry, but I just don't understand > why you're ranting here. Getting Koha recognized as a major player. I'm convinced. I'm keen on persuading other institutions. I'll do my utmost. I just see the lack of a solid LTS release as a difficulty. This thread subject concerns "plugins QA", and my first para mentions [other open-source as] "fairly stable with an established security update capability"; looking at e.g. Firefox plugins, Mozilla says (FAQs) "Unless clearly marked otherwise, add-ons available from this gallery have been checked and approved by Mozilla's team of editors and are safe to install. We recommend that you only install approved add-ons." Mea culpa if I 'pirated' this thread to *stability* rather than *QA*, but they are closely intertwined. > >There are very few institutions that have "happiness" in the >form of unlimited budgets and unlimited IT departments. I'm personally >intrigued by the creativity of the Koha community, so try and follow >what's happening -- which is magnificent -- but doubt that your average >library has the same passion. > > I think most of the discussions we have are important, and I really > love having the longer term steering and strategic types of conversations. I hope (and genuinely believe) that we're not the only two participants here interested in "steering and strategic types of conversations" and also hope that my thoughts on stability (QA, maturity, reputation) might strike chords with others. It's not criticism, perhaps more my dream of the next "small step" for library systems. In my 50+ years of code development, I can honestly say that end-user credibility is very closely related to stability, and that within "stable" the differentiation between security and enhancement must be crystal clear (and separately optional from an upgrade pov.) "It works as promised" is a huge compliment. The old saying "if it doesn't work, use a bigger hammer; if that fails, rtfm" is dubious management. Thanks for your thoughts and best regards, Paul >It's been a long time since I had to interact with proprietary vendors, >and I don't relish the thought of ever being charged with that again. I >think that a lot of the development done at least gives a nod to small >libraries. More often than no, folks bend over backwards for small >libraries. I get quite prickly if I sense that things *aren't* moving that >way. This is a big tent system, there's plenty of room for everyone's >individual take. :) > > >Cheers, >Brooke >_______________________________________________ >Koha-devel mailing list >Koha-devel(a)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/ --- Maritime heritage and history, preservation and conservation, research and education through the written word and the arts. <http://NavalMarineArchive.com> and <http://UltraMarine.ca>

8 12

June 2013 Koha Community Newsletter has been published
by Daniel Grobani 28 Jun '13

28 Jun '13

Hi, The June 2013 edition of the Koha Community Newsletter has been posted to http://koha-community.org/koha-community-newsletter-june-2013/. Cheers, Daniel Grobani Koha Community Newsletter Editor

1 0

RFC: Convergence
by Tomas Cohen Arazi 28 Jun '13

28 Jun '13

I've been thinking and sharing with some an idea I want to share with all of you. Since I stepped into Koha's world I've been focused (sometimes obsessively, I should admit) on the user POV. Specifically on the ways to deploy, maintain and finally use koha. We are now encouraging people to use the packages, and the way of using/deploying Koha has been slowly diverging from the tarball/git and packages setup. Also, the QA process itself takes both approaches appart. Think of the tarball installing DOM as default and packages not even supporting it as an example of what I mean. Think of memcached support, and so on. Once something is pushed, there has to be a 'packages version' for that: twice the work for everyone! We have reached a point at which we have a really nice set of daily maintainance tools: the koha-* scripts, and a sound install schema that supports multiple instances. Or a single default one if we built a 'koha' package that automates its creation, which I think is WIP right now. My proposal is that koha-* commands shouldn't be Debian (.deb) specific. And make the install schema used for packages the default/standard on git/tarball install. The same should happen to multiple instances setups. Both the users and devs should benefit from such a move. Thanks for your constructive comments on the subject! Regards To+ P.S. I belive this is a mid/long term discussion, I'm no way trying to make any sudden move. I just belive this is the way to have the time for a needed planification.

3 5

zebra / adding a search
by Samuel Desseaux 27 Jun '13

27 Jun '13

Hi, My colleagues would like to make some searchs based on the following field (940$a). How can i add it in Zebra and can i add this search in the search options (with a jquery for example)? Many thanks Samuel

1 0

QA: Language material in install/mysql/data
by Marcel de Rooy 26 Jun '13

26 Jun '13

Hi QA team, TM and RM, and other devs: A question on patches dealing with language dependent files in subdirs of installer/data/mysql, including sample notices, frameworks and lots of smaller stuff. With 9 language folders here, it seems to me that we should not demand developers to edit files in all these subdirectories too. Note also that lots of things there need to be translated too. Currently, there are already lots of differences between those language folders; in some language folders system prefs e.g. get specific values. And I suspect that some are being maintained more actively than others. A good improvement recently was the approach for systempreferences. They are inserted with the general sysprefs.sql in the root folder, and optionally updated by a translation in the language folder. So the pref comes always in, translation depending on others. (I think we should extend that approach to the other files now: insert in English, only update translatable things in the other languages. Example: only update name, title and content for a notice, only liblibrarian and libopac for frameworks, etc. ) For some folders there are already 'informal' maintainers. Couldn't we just formalize that someone can step forward to maintain such a folder and let devs just propose changes to the general files and/or the en-folder ? In QA we would no longer allow a patch to make changes in the other languages. Thanks for considering this. Marcel PS I wrote a patch myself recently with a sample notice (only for English). I do not like to add this English in all the language files. I was looking now at bug 9921 too; I think it should not touch all these frameworks. Lots of other examples can easily be found on BZ.

3 3

git-bz update required
by Galen Charlton 25 Jun '13

25 Jun '13

Hi, Just a heads-up for users of git-bz: as a consequence of a recent Bugzilla upgrade, in order to use git-bz to attach patches, it's necessary to use the "fishsoup" branch. Details can be found here: http://wiki.koha-community.org/wiki/Git_bz_configuration#As_of_June_2013.E2… Regards, Galen -- Galen Charlton Manager of Implementation Equinox Software, Inc. / The Open Source Experts email: gmc(a)esilibrary.com direct: +1 770-709-5581 cell: +1 404-984-4366 skype: gmcharlt web: http://www.esilibrary.com/ Supporting Koha and Evergreen: http://koha-community.org & http://evergreen-ils.org

2 1