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

adding ldap auth method
by Marc Chantreux 25 Sep '08

25 Sep '08

hello Koha developpers, Biblibre guys had a meeting today about the ldap authentication in koha because we're unable to use it against an Active Directory server. So we read the code and the wiki, focusing on the "Bind-as-Auth vs. $ldap->compare()" part. As former ldap administrator, i'm a bit surprised about it because i think that on many servers, the default acl makes the password readable only from administrator and self objects. It make sense if you think that another configuration can be compared to storing encrypted passwords in /etc/passwd , making them wide readable (remember john? ;-)). Another security issue against the compare method is that it doesn't respect the auth acl written by the local administrator. As site admin, i would be disapointed to see an account i've disabled using koha anyway. Leaving the security issues, there is a large range of encryptions schemes and the DSE informations about them are mandatory, we have to be carrefull about schemes like {method}cypher forms, and so on. Imagine how hard it could be to write a reliable code. I can be wrong but i think that it's just impossible for AD as the encryption scheme isn't documented. The wiki seems to tell that i'm not the first to come asking to change the auth method. As the module author must have his reasons to use one method, you can see that we have reasons to use the other. So it seems it would be usefull to add a way to choose between those methods (for instance via xpath //ldap/authmethod), keeping the current one as default. regards biblibre guys

2 1

BibLibre news
by Paul POULAIN 25 Sep '08

25 Sep '08

Hello Koha-dev, BibLibre is happy to announce 2 new ppl boarding the team : - Laurence Lefaucheur, that arrives on oct, 1st. She's a librarian, and will work on some contracts, plus probably French doc. - Nahuel Angelineti, that arrives on oct, 6th, that will work full time on Koha support for our customers first, and the community second. I hope that, after emptying the list of request from our customers, he will be able to dedicate some time (half time ?) to work on bugs.koha.org BibLibre will then be 8 persons, 1 to hire. We are also happy to announce that we have hired Mason James for 3 months to work with us on acquisition module (half time), with John Soros. We are very happy to see our team grow rapidly, and expect the Koha community will benefit of this growing as well. -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc NOUVEAU TELEPHONE : 04 91 81 35 08

1 0

RFC [ Koha 3.2 ] : Barcode prefixes in Consortial Environment
by Ryan Higgins 25 Sep '08

25 Sep '08

* Synopsis: This rfc describes changes made to core Koha to enable multiple libraries with potentially overlapping item and patron barcodes to merge their collections and patrons into a single Koha database. * Details: Libraries with overlapping barcodes (items and patrons) currently must rebarcode their collections in order to coexist in a single Koha installation. This RFC outlines proposed modifications to Koha's functionality to allow libraries to merge collections into a single Koha instance, decreasing overall maintenance overhead and giving them access to Koha's resource sharing features. This work encompasses: (1) auto-insertion of institution-code prefixes to inputs on circulation functions and cataloging; (2) addition of system-wide barcode length definitions; (3) extension of autobarcode calculation to use ranges defined by those prefixes and string lengths; (4) addition of jacket-sleeve barcode image printing, allowing materials to circulate between libraries. Two collections with overlapping barcode sets may be merged into a single Koha database by defining a system-wide barcode length and a branch-level prefix. It is assumed that the incoming data will be prefixed and padded prior to import so that the imported items & patrons fit this schema. When a patron or item barcode is scanned that is shorter than the defined system lengths (system preferences), Koha will add the prefix and pad as necessary based on the transaction branch location. If a scanned barcode is equal to or greater than the system-wide length, Koha will make no modifications. This allows sites to engage in long-term rebarcoding projects, eventually allowing them to turn off this feature. Since Koha must know the transaction location in order to determine which item is scanned, transfers between libraries cannot be allowed without affixing a temporary full-length barcode to an item. The existing hold-transfer slip is extended to allow printing of the full system barcode on a jacket sleeve, thus allowing materials to circulate between different libraries. The sleeve is only required for items with 'short' barcodes. Scanners work as expected within a local library, scanning the local short barcode and translating it to the prefixed, full-length system barcode. Full text at: http://wiki.koha.org/doku.php?id=en:development:rfcs3.2:rfc32_barcode_prefi… Comments welcome. -- Ryan Higgins LibLime * Open-Source Solutions for Libraries Featuring KohaZOOM ILS 888-564-2457 x704

1 0

Link between bibliographic and authority records
by Rodríguez, José L. 25 Sep '08

25 Sep '08

Hi all, I can't create the links between a bibliographic and authority record . When I'm cataloguing in the bibliographic editor I make a query to the authority file, and I'm adding the entry. But at the opac, when I search by subject this authority, I find it but with no associated record. I've tested Administration > Authority Types, and Marc Bibliographic Framework and they are correct. My koha version is 3.00.00.107, nozebra Can anybody give me any suggestion? Thanks in advance ########################################### This message has been scanned by F-Secure Anti-Virus for Microsoft Exchange. For more information, connect to http://www.f-secure.com/

1 0

[RFC] Using Log4perl to extend and improve logging and debugging
by Andrew Moore 24 Sep '08

24 Sep '08

NOTE: This is an RFC patch. I don't expect it to be directly applied to your system, and please don't apply it to the main Koha repository! Here is an example of how we can use Log4perl to extend (and hopefully improve) our current logging methods. I'm hopeful that this does a few things for us: * This will help us separate our application errors from apache errors by letting us easily redirect our errors to other files. * This will help us debug things by letting us increase the level of warnings from some parts of the application while ignoring other parts. Since you can configure it to handle messages from different parts of your application differently, you can inspect only certain parts more closely. For instance, if you would like to log more information about all opac seraches in order to let you investigate that more closely, you can edit the configuration file to write all of those types of messages to a different file. * This will let us separate out debugging types of messages from error messages. I would like for Koha to tell me of rather important errors that should be investigated differently from how it tells me of debugging messages. You can configure really bad ones to go to email to your support team, and the rather mundane to be written to a file. * and maybe more! I've included a few examples in this patch. One is in C4::Members where I instantiate a Log4perl object and use it to record some information when a function is called. The object knows that it's in the C4::Members "category", so you can handle that information differently in the log4perl configuration file if you like. Another is a use from one of the opac scripts, opac-search.pl. It shows how you might log search queries to a separate place. Since we have a lot of calls to 'warn' scattered about our code, I incuded a __WARN__ handler in C4::Debug that catches all calls to warn and runs them through log4perl. Ideally, this is not necessary, but it's a way for us to transition to using log4perl from the state we're in now. Finally, I've included an example configuration file that shows how you might separate out messages from different parts of your application into different places. You can also send these messages through email, syslog, or other files. I'm interested in discussion about whether extending the way we do logging is necessary yet, and if so if this seems like a good direction. I know that this can be improved and doesn't solve all of our problems, so please let me know how you might improve this approach, or of another one you would prefer. --- C4/Debug.pm | 49 +++++++++++++++++++++++++++++++++++++++++++++---- C4/Members.pm | 13 +++++++++++++ log4perl.conf | 38 ++++++++++++++++++++++++++++++++++++++ opac/opac-search.pl | 5 +++++ 4 files changed, 101 insertions(+), 4 deletions(-) create mode 100644 log4perl.conf diff --git a/C4/Debug.pm b/C4/Debug.pm index 357764a..f54df40 100644 --- a/C4/Debug.pm +++ b/C4/Debug.pm @@ -21,6 +21,7 @@ use strict; use warnings; use Exporter; +use Log::Log4perl qw(:easy); # use CGI; use vars qw($VERSION @ISA @EXPORT $debug $cgi_debug); @@ -34,6 +35,22 @@ BEGIN { # %EXPORT_TAGS = ( all=>[qw($debug $cgi_debug)], ); } +=head2 BEGIN block for log4perl + +Log4perl is initialzed in a BEGIN block to make sure it's available +for other BEGIN blocks. + +Perhaps it's not necessary to have this in a BEGIN block in the final +code. + +The config file is hardcoded right now. That's not necessary. + +=cut + +BEGIN { + Log::Log4perl->init( '/home/acm/koha/dev/log4perl.conf' ); +} + BEGIN { # this stuff needs a begin block too, since dependencies might alter their compilations # for example, adding DataDumper @@ -65,10 +82,34 @@ BEGIN { } } -# sub import { -# print STDERR __PACKAGE__ . " (Debug) import @_\n"; -# C4::Debug->export_to_level(1, @_); -# } +=head2 __WARN__ handler + +this overrides calls to C<warn> so that they don't get written to +STDOUT, but instead get run through Log4perl + +=cut + +$SIG{__WARN__} = sub { + local $Log::Log4perl::caller_depth = $Log::Log4perl::caller_depth + 1; + my $logger = logger(); + $logger->warn( @_ ); +}; + +=head2 logger + +this function returns a logging object. It's not strictly necessary +since you can call many of the Log4perl methods as class methods just +fine. But, it shows one example of how we can set the logger category +to make the messages wind be treated differently based on whether they +are in the opac or staff interface. + +=cut + +sub logger { + my $class = shift; + my $log_category = shift || 'opac'; + my $logger = Log::Log4perl->get_logger($log_category); +} 1; __END__ diff --git a/C4/Members.pm b/C4/Members.pm index 7df9424..fde3001 100644 --- a/C4/Members.pm +++ b/C4/Members.pm @@ -31,6 +31,12 @@ use C4::Biblio; our ($VERSION,@ISA,@EXPORT,@EXPORT_OK,$debug); +# initialize a log4perl object to be used throughout this module. We +# give it a category of C4::Members. This lets us call methods on it +# with the logging separated out into different places from the rest +# of the application, if we want. +our $logger = Log::Log4perl->get_logger( __PACKAGE__ ); + BEGIN { $VERSION = 3.02; $debug = $ENV{DEBUG} || 0; @@ -2060,6 +2066,13 @@ sub DebarMember { return unless defined $borrowernumber; return unless $borrowernumber =~ /^\d+$/; + # Here's an example of using the logger object. You can call + # 'debug' 'info', 'warn', 'error', or 'fatal' on it to send + # messages with different levels of priority. They may get treated + # differently (or ignored entirely) depending on your + # configuration. + $logger->info( "debarring borrower $borrowernumber" ); + return ModMember( borrowernumber => $borrowernumber, debarred => 1 ); diff --git a/log4perl.conf b/log4perl.conf new file mode 100644 index 0000000..de90960 --- /dev/null +++ b/log4perl.conf @@ -0,0 +1,38 @@ +# Where do we write the log files? +# Eventually, this will use a __VARIABLE__ so that the installer writes the right value in at install time. +log_file_root = /home/acm/koha/run/var/log + +# by default all log information can go to a default file, but only at ERROR level (or more severe) +log4perl.logger = ERROR, FileAppenderDefault + +log4perl.appender.FileAppenderDefault = Log::Log4perl::Appender::File +log4perl.appender.FileAppenderDefault.filename = ${log_file_root}/koha.log +log4perl.appender.FileAppenderDefault.layout = Log::Log4perl::Layout::SimpleLayout + +# opac activity can be directed to a separate file +log4perl.logger.opac = WARN, FileAppenderOpac + +log4perl.appender.FileAppenderOpac = Log::Log4perl::Appender::File +log4perl.appender.FileAppenderOpac.filename = ${log_file_root}/koha-opac.log +log4perl.appender.FileAppenderOpac.layout = Log::Log4perl::Layout::SimpleLayout + +# staff interface activity +log4perl.logger.staff = WARN, FileAppenderStaff + +log4perl.appender.FileAppenderStaff = Log::Log4perl::Appender::File +log4perl.appender.FileAppenderStaff.filename = ${log_file_root}/koha-staff.log +log4perl.appender.FileAppenderStaff.layout = Log::Log4perl::Layout::SimpleLayout + +# cronjobs and other activity may be directed to another file or handler +log4perl.logger.cron = WARN, FileAppenderCron + +log4perl.appender.FileAppenderCron = Log::Log4perl::Appender::File +log4perl.appender.FileAppenderCron.filename = ${log_file_root}/koha-cron.log +log4perl.appender.FileAppenderCron.layout = Log::Log4perl::Layout::SimpleLayout + +# In order to facilitate debugging OPAC search, perhaps we want log them at DEBUG level to the same OPAC file. +log4perl.logger.opac.search = DEBUG, FileAppenderOpac + +# Or, maybe right now we don't want to log any search strings because they're annoying while we're researching something else. +# log4perl.logger.opac.search = OFF, FileAppenderOpac + diff --git a/opac/opac-search.pl b/opac/opac-search.pl index 5f50861..2aa0be8 100755 --- a/opac/opac-search.pl +++ b/opac/opac-search.pl @@ -45,6 +45,11 @@ elsif ($build_grouped_results) { } elsif ((@params>=1) || ($cgi->param("q")) || ($cgi->param('multibranchlimit')) || ($cgi->param('limit-yr')) ) { $template_name = 'opac-results.tmpl'; + + # In this example, we're trying to log each search query. Since I want to be + # able to separate them apart from other logging, let's give them a different log + # category. And, it's pretty verbose, so let's send them at the "debug" level. + C4::Debug->logger('opac.search')->debug( 'searched for: ' . $cgi->param('q') ); } else { $template_name = 'opac-advsearch.tmpl'; -- 1.5.6

3 2

Invalid MARC for whatever reason
by MJ Ray 18 Sep '08

18 Sep '08

Has anyone ideas on the best approach to making Koha recover gracefully if it finds invalid MARC generated from its database? I'm still stumped by http://bugs.koha.org/cgi-bin/bugzilla/show_bug.cgi?id=2283 Thanks, -- MJ Ray (slef) Webmaster for hire, statistician and online shop builder for a small worker cooperative http://www.ttllp.co.uk/ http://mjr.towers.org.uk/ (Notice http://mjr.towers.org.uk/email.html) tel:+44-844-4437-237

1 0

zebraqueue_daemon questions
by Michael Hafen 18 Sep '08

18 Sep '08

Hello list, I remember some time ago zebraqueue_daemon.pl was offered to handle the zebra updates. Last time I looked through the INSTALL file though it isn't mentioned. Is this script now deprecated? The real question now... I am running it at present, and it seems to use more and more RAM as it goes. I don't have the time now to dig into it and figure out why. Is this a bug to be addressed, or should I stop using zebraqueue_daemon.pl in favor of cron'd call to `rebuild_zebra.pl -b -a -z`? Thanks.

1 0

ISBN conversions and matching
by dschust1＠tx.rr.com 18 Sep '08

18 Sep '08

Does Koha have the ability to build on the fly the new 13 digit ISBN's? We have hundreds of thoughsands of records with 10 digit ISBN's and if we are using that as our primary match point - new records are coming in with 13 digit ISBN's - will the index/matching algorithm compare both or create a new record for the 13 digit? Which means we would have to figure out a way to merge the records...??? David Schuster

2 1

debian.packages to update ?
by Zeno Tajoli 16 Sep '08

16 Sep '08

Hi to all, the two last modules request by Koha are GD and Email::Date. For GD I installed two packages: libgd2-xpm-dev libgd-gd2-perl For Email::Date I installed libemail-data-perl I read the file ../install_misc/debian.packages but those packages are not present. I think we need to update this file. Bye Zeno Tajoli Zeno Tajoli CILEA - Segrate (MI) tajoliAT_SPAM_no_prendiATcilea.it (Indirizzo mascherato anti-spam; sostituisci quanto tra AT con @)

1 0

Summary of community meeting on #koha
by Galen Charlton 12 Sep '08

12 Sep '08

Hi, A number of Koha developers and users met today on #koha to discuss various project issues. Several project positions were voted on and are now filled: 3.2 Release Manager - Galen Charlton, LibLime Translation Manager - Chris Cormack, Catalyst Documentation Manager - Nicole Engard, LibLime 3.0 Release Maintainer - Henri-Damien Laurent, BibLibre Since Chris was not present for the meeting, I ask him to formally confirm that he's still wants to be Translation Manager. The position of QA manager for 3.2 remains open. The two candidates are Frédéric Demians (Tamil) and Joshua Ferraro (LibLime). Due to the absence of both candidates during all or part of the meeting and a debate about the responsibilities of the QA manager position, no decision has been made, and the discussion should be continued on the koha-devel mailing list. Several announcements were made: * I will set up gitosis on git.koha.org to allow Henri-Damien to push patches to the 3.0.x branch. * Henri-Damien announced that minor revisions of 3.0.x will be packaged and released every two months. * I announced a date of 10 October 2008 for the developers to complete review of the RFCs for 3.2. I will also send out another schedule proposal for the 3.2 development cycle. Various issues were raised that should be discussed on the mailing lists: * Coding standards for 3.2. * Moving the Koha manual from Google Sites once www.koha.org is running Plone. * Policies for ensuring that more patches are reviewed and tested. The full log of the meeting is at http://koha.org/cgi-bin/logs.pl?recall=recall&saved_query=2008-09-12%20meet… or equivalently, http://koha.org/cgi-bin/logs.pl?look=plain&startdate=2008091212:00:37&endda… Regards, Galen -- Galen Charlton VP, Research & Development, LibLime galen.charlton(a)liblime.com p: 1-888-564-2457 x709 skype: gmcharlt

2 1