December 2012 - 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

3.6.1 upgrade to 3.8.5 and bug 8071
by Paul 06 Jun '13

06 Jun '13

In my continuing quest to upgrade 3.6.1 to 3.8.x without loss of functionality (specifically authorities, generally zebra) I have now upgraded my sandbox (db fully synchronized with the production box) to 3.8.5 along the lines of "bug 8071 blocker" ... however in 3.8.5: Results 1 to 20 of 424 Summary Used in Delete World War, 1914-1918 Details 0 biblio(s) Delete World War, 1914-1918 Aerial operations. Details 0 biblio(s) Delete / ... / in 3.6.1: World War, 1914-1918 Details 5 biblio(s) World War, 1914-1918 Aerial operations. Details 16 biblio(s) / ... / So, are authorities during the upgrade still broken? Is it my db? I did do a "test" during the upgrade: paul@server:/koha-3.08.05$ sudo make test / ... / Test Summary Report ------------------- t/Barcodes_ValueBuilder.t (Wstat: 512 Tests: 0 Failed: 0) Non-zero exit status: 2 Parse errors: Bad plan. You planned 10 tests but ran 0. Files=89, Tests=8155, 15 wallclock secs ( 0.72 usr 0.13 sys + 13.75 cusr 0.86 csys = 15.46 CPU) Result: FAIL Failed 1/89 test programs. 0/8155 subtests failed. make: *** [test_dynamic] Error 255 but decided (despite that) to try: paul@server:/koha-3.08.05$ sudo make upgrade No errors reported From web interface: Update report : Upgrade to 3.08.04.001 done (Bug 8657 - Default sort by call number does not work. Correcting system preference value.) Upgrade to 3.08.04.002 done. (Bug 8002: Update patron attribute types table from varchar(1) to varchar(10) category_code) Warning to Koha System Administrators: If you use borrower attributes defined by borrower categories, you have to check your configuration. A bug may have removed your attribute links to borrower categories. Please check, and fix it if necessary.Upgrade to 3.08.05.000 (3.8.5 release) done So ... is 3.8.x repairable? What am I missing? thanks - Paul

3 7

Use rfid with Koha
by mohsin 15 Feb '13

15 Feb '13

Dear Friends I am very much new to koha and need to implement Rfid reader for circulation .First i install Koha on Ubanto. The first problem is how to access koha from windows IE. As its shows " IT works ....." message. When i try to run sudo command it ask for password which i dont know. Second what i am planing is to add rfid reader on widws based terminal as all the drivers and dll are complied in C#. Have somebody this this directly in koha. Help seeker

4 4

Re: [Koha-devel] koha-zebra-daemon not starting
by Paul 24 Jan '13

24 Jan '13

I've tried to keep this to a minimum, there is a 'conclusion' further down: At 11:47 AM 8/20/2012 -0300, Tomas and Barry wrote: >On Sun, Aug 19, 2012 at 4:36 PM, Paul <paul.a(a)aandc.org> wrote: > > Koha 3.8.3 on Ubuntu 12.04 LTS server (new install, full upgrade) >[snip] > > But neither OPAC nor staff search functions are operational. > > > > The only anomaly that I've found so far is that > > /etc/init.d/koha-zebra-daemon when run from the command line reports > failure > > at line 73 (and does not create any error logs), but ps aux reports the > > daemon as running (well, "S+" -- sleep forground.) > > > > Anyone got any thoughts please? > >You need to answer what method r u using for install. Pls see my earlier email [Mon, 20 Aug 2012 09:48:19 -0400] >If using >tarball, then you might be running the zebra daemon using de 'koha' >user and 'koha' group. Do they exist? If this was the case, then this >should create the missing dir: > >mkdir -p /var/lock/koha/zebradb/biblios/ ; chown -R koha:koha >/var/lock/koha/zebradb/ Yes - tarball, but the dir was already (correctly) there: paul@server:/var/lock/koha/zebradb$ ls -l total 0 drwxr-xr-x 2 koha koha 40 Aug 20 11:33 authorities drwxr-xr-x 2 koha koha 40 Aug 20 11:33 biblios >Also (just in case): >chown -R koha:koha /var/log/koha Again, correctly there: paul@server:/var/log$ ls -l | grep koha drwxr-xr-x 2 koha koha 4096 Aug 19 11:19 koha >Also, every time you run rebuild_zebra.pl you should do it like: > >su - koha -c "KOHA_CONF=/etc/koha/koha-conf.xml >PERL5LIB=/usr/share/koha/lib >/usr/share/koha/bin/migration_tools/rebuild_zebra.pl -b -r -v -x" What's the '-c'? (I don't think I've ever used this construct) and I don't think there's any difference, but I 'su koha' first, then 'cd usr/share/koha', then KOHA_CONF=/etc/koha/koha-conf.xml PERL5LIB=/usr/share/koha/lib ./bin/migration_tools/rebuild_zebra.pl -a -r -v and KOHA_CONF=/etc/koha/koha-conf.xml PERL5LIB=/usr/share/koha/lib ./bin/migration_tools/rebuild_zebra.pl -b -r -v -x and Barry Cannon wrote: >Shouldn't running "zebrasrv -f /etc/koha/koha-conf.xml" (or whatever your >path is) as the index owner give you a good indication of what is going on >(it should at least get you pointed in the right direction as it should >dump out the error to console) Interesting !!! or ;=} -- I tried that: koha@server:/$ zebrasrv -f /etc/koha/koha-conf.xml 11:51:06-20/08 [log] zebra_start 2.0.44 419ad759807269fdfa379799a051ed3a551c6541 11:51:06-20/08 [log] config /etc/koha/zebradb/zebra-biblios-dom.cfg 11:51:06-20/08 [log] Loaded filter module /usr/lib/idzebra-2.0/modules/mod-grs-xml.so [snip more filters for zebra-biblios-dom and zebra-authorities-dom 11:51:06-20/08 [server] Adding dynamic listener on unix:/var/run/koha/zebradb/bibliosocket id=1 11:51:06-20/08 [server] Adding dynamic listener on unix:/var/run/koha/zebradb/authoritysocket id=2 at which point that terminal just hangs on an ongoing op, but shows that the sockets were not previously opened. So, re-indexing again: for authorities: 25901................................ Records exported: 25933 ==================== REINDEXING zebra ==================== skipping biblios ==================== CLEANING ==================== and for biblios: 37301...........................................................................37401.................... Records exported: 37417 ==================== REINDEXING zebra ==================== 12:04:12-20/08 zebraidx(2841) [warn] Unknown register type: ==================== CLEANING ==================== Which corresponds to the ps aux | grep koha during the re-indexing: koha 2738 0.0 0.1 119084 4212 pts/2 S+ 12:01 0:00 su - koha -c KOHA_CONF=/etc/koha/koha-conf.xml PERL5LIB=/usr/share/koha/lib /usr/share/koha/bin/migration_tools/rebuild_zebra.pl -b -r -v -x koha 2747 73.8 1.4 259028 56272 pts/2 S+ 12:01 2:07 /usr/bin/perl /usr/share/koha/bin/migration_tools/rebuild_zebra.pl -b -r -v -x koha 2841 96.1 1.6 233556 64240 pts/2 Rl+ 12:04 0:27 zebraidx -c /etc/koha/zebradb/zebra-biblios-dom.cfg -v none,fatal,warn -g marcxml -d biblios update /tmp/q2UPWJgDrk/biblio and now we've got the search in OPAC and staff-admin finding the 37301 biblios. And I still don't know what the "[warn] Unknown register type: " might mean. Some hangover from 3.6.1 to 3.8.3? BUT ... the incremental cron (shows up in /var/log/syslog as working every 1 minute), does _NOT_ add new records. Conclusion: I'll keep going at this (half an hour here and there, it's our "tourist season", busiest time of the year) but somewhere, can't remember, there's something about Ubuntu 12.04 not renewing sockets, .LOKs, etc on reboot. Maybe I'm way off track, but it's the best avenue I have at the moment. Thoughts, please? Best - Paul

6 17

"Damaged" values
by Paul 09 Jan '13

09 Jan '13

In our "Authorized values" > "Damaged", we have added a term "Normal wear" to the Koha defaults 0, 1 and 2: 0 Not damaged Not damaged 1 Damaged Some damage noted 2 Unknown Condition not stated 3 Normal wear Normal wear However, in both staff interface and OPAC, "normal wear" items are appearing as damaged I assume (maybe incorrectly) that the value of "damaged" is read by detail.pl starting line 196: if ($item->{damaged}) { $item->{itemdamagedloop} = GetAuthorisedValues($authvalcode_items_damaged, $item->{damaged}) if $authvalcode_items_damaged; } and then passed to detail.tt start line 310: [% IF ( itemloo.damaged ) %] [% IF ( itemloo.itemdamagedloop ) %] [% FOREACH itemdamagedloo IN itemloo.itemdamagedloop %] [% IF ( itemdamagedloo.selected ) %] <span class="dmg">[% itemdamagedloo.lib %]</span> [% END %] [% END %] [% ELSE %] <span class="dmg">Damaged</span> [% END %] [% END %] I have no experience with this type of 'loo' and 'loop' coding, but it seems to me that "normal wear" is not being picked up, and therefore the ELSE default "Damaged" is being used. Could some kind person please point me to the logic of these loops? Either a brief explanation here (preferred) or a pointer to a tutorial (I have googled with no success.) Or is there something more intrinsic|relevant to the use of authorized values for "damaged"? Bugs [3637] and 5797 may be germane. Many thanks, Paul --- Maritime heritage and history, preservation and conservation, research and education through the written word and the arts. <http://UltraMarine.ca>, <http://AandC.org> and <http://MarDoc.ca>

2 2

using new templates for exporting basketgroups in pdf
by Mathieu Saby 04 Jan '13

04 Jan '13

Hello Our library has created a new templates for exporting basketgroups in pdf (translated in french, and showing fields more usefull for us in the tables than "layout2pages" and "layout3pages"). Of course, we could name this template "layout3pages", and replace the standard template. But I think it would be "cleaner" to add this give this new template a name of his own, so it won't be altered when our Koha is updated. The problem is some code in /acqui/basketgroup.pl prevents us to do that. The only 2 valid templates for exporting basketgroups in pdf are be "layout2pages" and "layout3pages". And we want to edit perl files as less as possible. http://git.koha-community.org/gitweb/?p=koha.git;a=blob;f=acqui/basketgroup… 188 if ($pdfformat eq 'pdfformat::layout3pages' || $pdfformat eq 'pdfformat::layout2pages'){ 189 eval { 190 eval "require $pdfformat"; 191 import $pdfformat; 192 }; 193 if ($@){ 194 } 195 } 196 else { 197 print $input->header; 198 print $input->start_html; # FIXME Should do a nicer page 199 print "<h1>Invalid PDF Format set</h1>"; 200 print "Please go to the systempreferences and set a valid pdfformat"; 201 exit; 202 } This code was added by this Chris Cormack's commit : "Bug 6679 Fix scripts in admin & acqui to pass Perl::Critic" http://git.koha-community.org/gitweb/?p=koha.git;a=commit;h=7cdea5de355e853… added So, here is my question : Is this "security" in code really necessary ? And if it is, is there a way to make it more flexible ? Regards, M. Saby Rennes 2 University -- Mathieu Saby Service d'Informatique Documentaire Service Commun de la Documentation Université Rennes 2 Téléphone : 02 99 14 12 65 Courriel : mathieu.saby(a)univ-rennes2.fr

2 3

Database updates
by Jared Camins-Esakov 02 Jan '13

02 Jan '13

Hello. I just pushed bug 7167, which changes the way database updates work. I wrote up instructions for database updates at http://wiki.koha-community.org/wiki/Database_updates#Using_the_new_update_p… Please be sure to read those instructions and follow them in the future. Regards, Jared -- Jared Camins-Esakov Bibliographer, C & P Bibliography Services, LLC (phone) +1 (917) 727-3445 (e-mail) jcamins(a)cpbibliography.com (web) http://www.cpbibliography.com/

5 9

Require only core modules for Makefile.PL? (was Re: Database updates)
by Galen Charlton 29 Dec '12

29 Dec '12

Hi, On Thu, Dec 27, 2012 at 9:03 AM, Jared Camins-Esakov < jcamins(a)cpbibliography.com> wrote: > Additionally, you will need to install File::Find::Rule > ... before one can run perl Makefile.PL to do a new installation. I don't think that (in this case, indirectly) requiring a non-core Perl module to run the first step of the installation after unpacking the tarball is a good idea. I've opened bug 9328 to discuss the specifics, but I think there's a minor coding principle to discuss: should we have an explicit requirement that only core modules be necessary to start the installation? [1] http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9328 Regards, Galen -- Galen Charlton Director 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

5 4

Help with Zebra search with Unicode
by Quoc Uy 29 Dec '12

29 Dec '12

After install koha packages and I found that search is not working on Other languages ( my language is Unicode). I just can't search for books... and found out on internet some one said that i need to enable some ICU option in zebra indexer. Can some one tell me exactly what i have to do? Thanks!

2 1