October 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

making facets editable ?
by Mathieu Saby 09 Nov '12

09 Nov '12

Hello Currently, facets are defined in perl code. This is not good for unimarc libraries : a recent improvement is specific to Marc21 and could not been transposed in Unimarc, because the information is not encoded in the same field in all unimarc libraries. I'm referring to http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=4255 "Add item type to facet list" : there is no universal Unimarc field for "item type" :-( The solution could be a system preference for this peculiar facet. But if a development is needed I would prefer a more generic one, to make all facets fully editable, so that each library could define its own facets matching the (sub)fields of its choice, without editing perl files. Do you think it would be a good idea ? I think there is 2 way for doing this : - create a configuration file (yaml ?) - create a (big) syspref Which choice would be the best regarding performances (and other criteria I did not think of...) ? Regards, Mathieu Saby Rennes 2 University -- Mathieu Saby Service d'Informatique Documentaire Service Commun de Documentation Université Rennes 2 Téléphone : 02 99 14 12 65 Courriel : mathieu.saby(a)univ-rennes2.fr

4 4

Some thoughts from QA team
by Paul Poulain 05 Nov '12

05 Nov '12

Hi koha-devel, The 3.10 and 3.12 QA teams ( Mason, Jonathan, Marcel & me, with the freshly elected Travis, Katrin -and Jared as RM-) have had a discussion about QA process and would like to propose the 2 following things: * Create a QA specific mailing list (qa(a)lists.koha-community.org ?) This list would be used for QA related discussions. We had some private discussions in the last months (mostly about koha-qa.pl tool = should we add this, remove that,...), and think it's better to have a public mailing list. [ One thing that worried us is "should we let anyone subscribe to the list or moderate list subscriptions to avoid non-QA threads". Not a big deal, but if you've an opinion... ] * Change the priority flag use on bugzilla. Currently, this flag is not really used by anyone. We would like to change it's content to the following values, to reflect the complexity of a patch: 1- trivial patch template/doc only 2- trivial patch - minor Perl code 3- low risk of side-effect 4- medium risk of side effect, but don't underestimate it 5- High risk of side effect, be very careful ! We would also add a wiki page explaining how to choose the value. The value can be set by anyone (patch submitter, sign-offer, QA team, RM), and will just be a helper when someone want to pick up a patch for testing or QAing. Comments welcomed. -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08

16 21

RSS and SMS overdues cronjob
by Jared Camins-Esakov 05 Nov '12

05 Nov '12

Hello. As they currently stand, the cron jobs at misc/cronjobs/smsoverdues.pl and misc/cronjobs/rss/rss.pl will not work on an out-of-the-box Koha installation, as they require an obsolete templating system. I am wondering if anyone still uses these cron jobs, or whether they are obsolete legacy scripts that should just be removed at this point. So, are you using either of these scripts? Do you know anyone else who does? 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/

4 4

QA Re: FIX in qa-tools
by Mason James 02 Nov '12

02 Nov '12

On 2012-10-25, at 1:40 AM, Jonathan Druart wrote: > Hi Mason, > > I did not rebase my qa-tools repo and I found a bug in the check of perlcritic. > So I fixed it and ... I was not able to push, I was not up-to-date :) > > In fact you already tried to fix it in the commit "fixed perlcritic test". > But It is not the good way: > # If the tested file is deleted in the commit, we return 0 > return 0 unless -e $self->path; > > # If the tested file is newly created int the commit, (ie: nothing existing to compare too), we call Perl::Critic, not Test::Perl::Critic::Progressive > unless (-e $self->path) { > > if the path does not exist, the routine returns 0 and does not execute the second unless statement. (and print a warning launching tests: An error occured : Can't use string ("0") as an ARRAY ref while "strict refs" in use at t/Perl.t line 72.). > > I think my last commit ("add a new flag "new_file" to mark a file if it is a newly created") fixes correctly the problem but... be careful :) > > Jonathan heya Jonathan thanks for this, ill do some testing then push your changes up to the kc.rg github repo https://github.com/Koha-Community/koha-qa-tools

5 8