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

Re: [Koha-devel] zebraqueue_daemon questions
by Michael Hafen 26 Sep '08

26 Sep '08

Thanks for the reply. On Fri, 2008-09-26 at 10:50 +0200, Henri-Damien LAURENT wrote: > Michael Hafen a écrit : > > 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`? > > > It is usual agreed that rebuild_zebra.pl -b -a -z should be used rather > than zebraqueue_daemon.pl > My 2 cts.

1 0

claiming DB numbers for acquisition module
by Paul POULAIN 26 Sep '08

26 Sep '08

Hello, We are claiming numbers for acquisition module on the wiki page http://wiki.koha.org/doku.php?id=en:development:dbrevs However, for instance, this dev is done over the 3.0.x branch. We plan to move the dev to head in a few time, but the SAN-OP idea is to start using the new module in january, so that will be over 3.0.x But nevermind. the problem is for DB number claiming atm : we claim (& use the numbers we claim) DB numbers, but for instance, we don't commit. Do you think : - we can continue, the missing numbers will be added when we will move our job to head (at the price of head having 3.01.00.010 and LATER having 3.01.00.007 for example. But in alpha stage of 3.1, I don't think it's a problem) - we use a temporary number scheme, just for internal (BibLibre SAN-OP) use, and when we submit the stuff to HEAD, we claim & use the numbers. that would require only a few changes for us, just change the numbers in updatedatabase.pl before submitting. Writing it, I think the later is the best solution, so, unless you don't agree : - we will use it - we free the numbers we claimed (005 -> 009) -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc NOUVEAU TELEPHONE : 04 91 81 35 08

3 3

How-to add content
by Krishnan Mani 26 Sep '08

26 Sep '08

Hello, Koha has the couple of system preferences: OpacMainUserBlock: to insert content into the body of the OPAC "home" page OpacNav: to insert content into the sidebar (usually links) I want to add some static content (a few .html pages) and links to the same from the sidebar, such that these are displayed in the same place as OpacMainUserBlock without navigating away from the OPAC screen What's the recommended way to do this? i understand that at the very least, i will have to create and house the static content inside DocumentRoot for Koha. For the moment, i am using a single locale, so i am not worried about making sure that this content will be picked up regardless of template and locale chosen from the SystemPreferences. Thanks and regards, krishnan mani Pune, India Add more friends to your messenger and enjoy! Go to http://in.messenger.yahoo.com/invite/

1 0

Opac - Link Authority - Biblio
by Rodríguez, José L. 26 Sep '08

26 Sep '08

I cannot solve the problem of linking auhorities and bibliographics records. In the opac when I browse by subjects, the authority records gets «0 biblios». I add this link Authority http://www.bibliotecahispanica.es:8080/cgi-bin/koha/opac-authoritiesdetail.… Biblio http://www.bibliotecahispanica.es:8080/cgi-bin/koha/opac-detail.pl?biblionu… 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? ********************************************************************** ########################################### 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

Syspref translation
by Jesse Weaver 26 Sep '08

26 Sep '08

I have a small favor to ask of any french-speaker on the list; could you translate the following syspref description? "If ON, allows renewal limits to be overridden on the circulation screen" Thanks, -- Jesse Weaver Software Developer, LibLime

2 1

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