General

Understanding records in Koha

Throughout the years, I’ve found several open source ILS and most of them try to water down the way librarians have catalogued resources for years. Yes, we all agree ISO 2709 is obsolete, but MARC has proven to be very complete, and most of the efforts out there (Dublin Core, etc.) try to reduce the expression level a librarian can have. If your beef is with ISO 2709, there’s MARC-XML if you want something that is easier to debug in terms of encoding, etc.

That said, Koha faces a challenge: it needs to balance the expressiveness of MARC with the rigidness of SQL. It also needs to balance the convenience of SQL with the potential shortcomings of their database of choice (MySQL) with large collections (over a couple thousand records) and particularly with searching and indexing.

Koha’s approach to solve this problem is to incorporate Zebra to the mix. Zebra is a very elegant, but very difficult to understand piece of Danish open source software that is very good at indexing and searching resources that can come from, say, MARC. It runs as a separate process (not part of the Web stack) and it can also be enabled as a Z39.50 server (Koha itself is a Z39.50 consumer, courtesy of Perl)

The purpose of this post is to help readers navigate how records are managed in Koha and avoid frustrations when deploying Koha instances and migrating existing records.

Koha has a very simple workflow for cataloguing new resources, either from Z39.50, from a MARC (ISO 2709 or XML) file or from scratch. It has templates for cataloguing, it has the Z39.50 and MARC capabilities, and it has authorities. The use case of starting a library from scratch in Koha is actually a very solid one.

But all of the libraries I’ve worked with in the last 7 years already have a collection. This collection might be ISIS, Documanager, another SQL database or even a spreadsheet. Few of them have MARC files, and even if they had (i.e., vendors provide them), they still want ETLs to be applied (normalization, Z39.50 validations, etc.) that require processing.

So, how do we incorporate records massively into Koha? There are two methods, MARC import or fiddling with SQL directly, but only one answer: MARC import.

See, MARC can potentially have hundreds of fields and subfields, and we don’t necessarily know beforehand which ones are catalogued by the librarians, by other libraries’ librarians or even by the publisher. Trying to water it down by removing the fields we don’t “want” is simply denying a full fidelity experience for patrons.

But, in the other hand, MySQL is not designed to accommodate a random, variable number of columns. So Koha takes the most used attributes (like title or author) and “burns” them into SQL. For multivalued attributes, like subjects or items, it uses additional tables. And then it takes the MARC-XML and shoves it on a entire field.

Whoa. So what happens if a conservatorium is making heavy use of 383b (Opus number) and then want to search massively for this field/subfield combination? Well, you can’t just tell Koha to wait until MySQL loads all the XMLs in memory, blows them up and traverse them – it’s just not gonna happen within timeout.

At this point you must have figured out that the obvious solution is to drop the SQL database and go with a document-oriented database. If someone just wants to catalog 14 field/subfields and eventually a super detailed librarian comes in and starts doing 150, you would be fine.

Because right now, without that, it’s Zebra that kicks in. It behaves more like an object storage and it’s very good at searching and indexing (and it serves as Z39.50 server, which is nice) but it’s a process running separately and management can sometimes be harsh.

Earlier we discussed the use case where Koha excels: creating records from scratch. Does this mean that Koha won’t work for an existing collection? No. It just means the workflows are a tad more complicated.

I write my own Perl code to migrate records (some scripts available here, on the move to GitHub), and the output is always MARC. In the past I’ve done ISO 2709, yes, but I only do MARC-XML now. Although it can potentially use up more disk space, and it could be a bit more slow to load, it has a quick benefit for us non-English speakers: it allows to solve encoding issues faster (with the binary, I had to do hexadecimal sed’s and other weird things and it messed up with headers, etc.)

Sometimes I do one record per file (depending on the I/O reality I have to face) but you can do several at a time: a “collection” in just one file, that tends to use up more RAM but also makes it more difficult to pinpoint and solve problems with specific records. I use the bulkmarcimport tool. I make sure the holdings (field 942 in Koha unless you change it) are there before loading, otherwise I really mess up the DB. And my trial/error process usually involves using mysql’s dump and restore facilities and removing the content of the /var/lib/koha/zebradb directory, effectively starting from scratch.

Koha requires indexing, and it can be very frustrating to learn that after you import all your records, you still can’t find anything on the OPAC. Most distro packages for Koha have a helper script called koha-rebuild-zebra which helps you in the process. Actually, in my experience deploying large Koha installations, most of the management and operational issues have something to do with indexing. APT packages for Koha will install a cron task to rebuild Zebra, pointing at the extreme importance (dependency) on this process.

Since Koha now works with instance names (a combination of Zebra installations, MySQL databases and template files) you can rebuild using something like:

koha-rebuild-zebra -b -v -f mybiblio

Feel free to review how that script works and what other (Perl) scripts it calls. It’s fun and useful to understand how old pieces of Koha fit a generally new paradigm. That said, it’s time to embrace cloud patterns and practices for open source ILS – imagine using a bus topic for selective information dissemination or circulation, and an abstract document-oriented cloud storage for the catalogue, with extensive object caching for searches. And to do it all without VMs, which are usually a management nightmare for understaffed libraries.

Standard
General

Koha with no barcodes

Traditionally, Koha 3 depends on the items (we call them existencias in spanish) having a barcode in order to uniquely identify each item. Circulation, for example, requires the librarian to scan the barcode of an item in order to circulate it.At times, this proves inconvenient since lots of biblios (titles, or títulos in spanish) have the same barcode printed on each item (usually the ISBN number) forcing the library to print new unique barcodes (Koha has a nice barcode generator) for each one of the items in existence.However, it’s usually not feasible to relabel all items with new barcodes, especially if you have millions of items nationwide. So, I thought of an easy patch to Koha that allows to circulate items based on the item number, and not the barcode.First of all, you should set the barcode number for each item equal to the item number for those items where you don’t have any barcode recorded. These is best accomplished after loading MARC records on the database using the MySQL console:

UPDATE items SET barcode = itemnumber; -- optionally using something like WHERE barcode = ''

On my case, for over 1.1 million items, it took some 3 minutes 6 seconds to complete. There’s a drawback, however, because you need to run this periodically as you add more items, but it’s not something your DBA can’t automate. At this point you can circulate items using items number, and you can print barcodes with that number, but it’s still not easy for the librarian to either remember the item number or look it up before circulating.You can apply an easy patch on line 44 of the modules/catalogue/moredetail.tmpl file of the Intranet, providing a new link on the Items tab of a biblio to start the borrowing workflow for a specific item:

<!-- TMPL_UNLESS NAME="issue" -->[Circulate item ]<!-- /TMPL_UNLESS -->

Of course, circ/circulation.pl on the Intranet also needs a small patch to store the barcode number on the session and then reusing it when the borrower is selected, near line 111:

my $barcode;if ( $session->param('barcode') ) {  $barcode = $session->param('barcode');  $session->clear('barcode');} elsif ( $query->param('barcode') ) {  $barcode = $query->param('barcode') || '';  $session->param('barcode', $barcode);}$barcode =~  s/^s*|s*$//g; # remove leading/trailing whitespace...

Restart your Web server and that’s it. You can now search for a biblio, go to the Items tab, select an item to be circulated, select a borrower, and the item is circulated. For retus, search for the user and go to the end of the page, you can see all items on circulation, fines and retu options. The workflow changes a little bit, but it’s the easiest way I’ve devised to operate a Koha ILS when barcodes are absent or outside your control.

Standard
General

Considerations for migrating CDS/ISIS databases to fully MARC-based ILSs

CDS/ISIS is an obsolete information storage and retrieval system (and also an information storage format) for computers designed some 30 years ago, filling a need for libraries around the world. For several years UNESCO unfortunately invested time and money supporting it and freely (as in free beer, but as proprietary software) distributing it to several countries. Altogether, CDS/ISIS is now responsible for the overall underdevelopment of technology for libraries, especially in Latin America. Sadly, since UNESCO now seems reluctant to continue draining resources, there is an effort in LatAm to open-source CDS/ISIS-related technologies and bring them to the Web. Fair enough, but this doesn’t change the fact that CDS/ISIS is dead.

So, since it’s already dead, we’ll need to retrieve and migrate our records in CDS/ISIS databases and move them to less ancient systems. Talk about safeguarding our heritage. MARC is an equally ancient format designed by Library of Congress that is actually the standard (ISO 2709) for storing bibliographic records (CDS/ISIS never was) and the flavour we use in LatAm, MARC21, is a binary storage format. But of course we do have MARC-XML which is widespread in Integrated Library Systems, both proprietary and open source. In Koha3 we use MySQL to store MARC-XML when representing a bibliographic records. Specialized open source software such as Zebra allows us to efficiently index and search MARC-XML data.

Perl is the natural language of choice for migrating this kind of data, and there’re libraries for both ISIS (Biblio::ISIS) and MARC (MARC::*) which are already available in Debian, BTW. The following are some caveats I’ve found when migrating data from ISIS to MARC-XML:

  • “Indexing”. Records in CDS/ISIS are referred to using the MFN (master file number) which is a sequential integer asigned by CDS/ISIS; this is useless since end users (patrons) won’t search the catalogue using the MFN, and librarians would like to refer to a single item using a call number. In MARC you don’t have a unique number to refer to records. The whole logic of the MARC::* modules eases understanding, you create an object -your record- containing objects -fields- which you dump in the screen or in a file, all cat’ed together. MARC is a format. Indexing is not the format’s issue.
  • Encoding. Given an MFN, Biblio::Isis throws you a hash. With little manipulation, this hash can be used to create a MARC::Record. So, if librarians have been using MARC fields and subfields in their CDS/ISIS database, migration can be of little logic (search for isis2marc in Google) — however in my scenarios encoding is always a problem. I’d like to cite two of these scenarios: one having a source encoding of cp-850, requiring me to disassemble and then reassemble the whole data structure of Biblio::Isis to create a properly utf-8 encoded record; and the other one having binary garbage coming from a mainframe, where vocals with tilde (spanish) were preceded by a hex 0x82, except for n with tilde, preceded by a hex 0x84 (ibm437) and I preferred to use sed before running my code.
  • Holdings. CDS/ISIS doesn’t implement any logic about your holdings (also called items, or existencias in most spanish-speaking countries) but it might store information about them such as location and number of items. You’re forced to implement custom logic here, since not only your source is picky regarding holdings, but your target will, too. Nowadays, ILSs are expected to be tweakable regarding which MARC field is used for holdings. Koha does use the 952 field.
  • Data quality. In the broadest sense of the term, you’d like to delete multiple space characters, maybe even build a thesaurus, skip undesirable subfields (indicators, subfields under 10) and such. You’ll need custom logic and also disassemble Biblio::Isis data structures. Data::Dumper proves noteworthy for this.

Such procedures are not specifically CPU- or RAM-intensive (I can migrate tenths of MBs of data in my laptop in under two minutes while having a full-fledged desktop running), but they are not instantaneous. With a migration logic which is quite profuse, goes deep inside Biblio::Isis, does decoding/encoding, queries exteal hashes and so, I roughly get a 390 records per second performance. But this is blazingly fast when compared with the time a mode ILS takes to bulk import a huge amount of records (Koha’s bulkmarcimport.pl gives me some 15 records/second) or when comparing with a state of the art indexer such as Zebra (similar times)

Standard
General

Using arrays instead of hashes in MARC::Field constructor

Whenever you’re creating a MARC field using Perl’s excelent MARC::Field module, you can always use an array instead of a hash in order to specify subfield/data pairs. This is useful since some field/subfield combinations in MARC are repeatable, and the POD leads you to writing hashes for storing subfield/data pairs before creating the field. For example, the POD says:

my $field = MARC::Field->new(     245, '1', '0',     'a' => 'Raccoons and ripe co / ',     'c' => 'Jim Aosky.');

But this is also valid and works:

my @array = ('a', 'Raccoons and ripe co /', 'c', 'Jim Aosky.', 'k', 'typescript, 'k', 'diaries');my $field = MARC::Field->new ( 245 , '1', '0', @array );
Standard
General

Biblioteca Nacional de Venezuela evalúa implementar Sistemas Integrados de Gestión Bibliotecaria bajo software libre y estándares abiertos

Durante el año 2008, la Biblioteca Nacional de Venezuela (BNV) ha realizado un inédito e importante acercamiento al software libre y de estándares abiertos al evaluar y decidir implementar pruebas del Sistema Integrado de Gestión Bibliotecaria Koha, el más famoso y maduro software libre para gestión de bibliotecas.A partir de Febrero 2008, la BNV contactó a Biblio Venezuela, un grupo de asesores en Información y Documentación con experiencia a nivel nacional en la implementación de software libre para bibliotecas, centros de información y documentación y archivos, solicitando el apoyo técnico ad-honorem para la revisión a profundidad del sistema Koha.La BNV maneja más de dos millones de registros y el Sistema Nacional de Bibliotecas Públicas, un volumen considerable para cualquier sistema de información. En el caso de Koha, las pruebas realizadas a nivel mundial indican la posibilidad de manejar más de cinco millones de registros en hardware económico y obtener tiempos de respuesta inferiores a los quince segundos.Así mismo, la BNV utiliza el antiguo sistema propietario NOTIS, cuyo acceso para el público no presenta elementos de usabilidad y dificulta las consultas por sus características antiguas de conexión, por lo que los procesos de implementación de cualquier SIGB deben contemplar la migración de los datos y el acceso inclusivo.Biblio Venezuela ha trabajado cuatro meses en el apoyo a la BNV, incluyendo una demostración completa y levantamiento de requerimientos con el personal de Procesos Técnicos, encontrando que muchas de las necesidades de la BNV podían ser desarrolladas y liberadas a la comunidad como software libre y de estándares abiertos, en concordancia con las Políticas de Estado en materia de Tecnologías de la Información y el Decreto Presidencial 3390.Así mismo se implementó una prueba de concepto del sistema Koha 3, con las base de datos Zebra y MySQL, para cargar más de 70 mil registros simulados en hardware previamente adquirido por la BNV, así como un gran trabajo de imagen gráfica obteniendo resultados ampliamente positivos.

Standard
General

Venezuela’s National Library evaluated, decided to deploy the Koha Integrated Library System

On the first half of 2008, Venezuela’s National Library (BNV) evaluated the Koha ILS and other FLOSS-based ILSs, together with a proprietary ILS, and decided to deploy Koha in two phases for the Library’s catalogue, which includes more than two million records, and the National Public Library System.The evaluation was made by the Information Technology Office, and starting February 2008, three independent Koha consultants were asked for technical help in order to evaluate Koha strengths and shortcomings, and possible development/improvement plans, as well as an important migration plan from the legacy NOTIS system. Circulation, acquisitions and patrons weren’t regarded as critical modules of the ILS, while Cataloguing, Authorities and Serials were given special attention.Ailé Filippi and Mariana González, licensed librarians, deployed a full Koha demonstration and worked for two months with the BNV librarians in order to establish the desired functionality level. BNV librarians wanted a new input system for MARC records which allow them to manually input all fields and subfields, and a very particular notation for holdings which allows to specify the specific Public Library where the item is held.On the other hand, José Miguel Parrella Romero, an IT consultant, worked with BNV’s IT Office in order to recommend and install the latest Koha3 snapshot, and configured a working proof of concept using Zebra for more than 70 thousand simulated records. BNV staff export data from NOTIS and use a proprietary tool to convert those records to an ISIS database, so it was necessary to write a computer program which migrates those records to MARC.

Standard
General

Implementando Koha sobre Debian

Koha es un ILS (Sistema Integrado de Bibliotecas) de estándares abiertos que es distribuído bajo la Licencia Pública General GNU (GPL). Koha es desarrollado por una comunidad de programadores y bibliotecarios de todas partes del Mundo y su diseño es ajeno a cualquier intención comercial o corporativa. Koha le permite al bibliotecario manejar la mayoría de los procedimientos administrativos de una Biblioteca, y además proveer a los visitantes con un catálogo público para la consulta de ejemplares y circulación. Koha es una solución compatible con el Decreto Presidencial 3390 que provee al bibliotecario de herramientas automatizadas para la mayoría de los procedimientos administrativos, cumpliendo con todos los estándares inteacionales sobre el tema. Mejor aún, cualquier bibliotecario puede participar en el desarrollo de Koha. Koha es un sistema basado en la Web, y como tal produce salidas compatibles con la especificación XHTML 1.0 y CSS de la World Wide Web Consortium (W3C), garantizando su operatividad a través de cientos de navegadores Web, plataformas, sistemas operativos y dispositivos no convencionales. Usted puede acceder a un sistema Koha a través de su teléfono celular, de su navegador en MacOS X o desde la comodidad de su televisor con acceso a Inteet.Flexible Koha es basado en la Web, por lo que pueden utilizarse dummy terminales (terminales sin disco duro ni hardware especializado) para las consultas y el manejo de la biblioteca. Mejor aun: el bibliotecario puede administrar la biblioteca remotamente, utilizando un teléfono móvil o un asistente personal. En el diseño de Koha se contemplan dos modelos de bases de datos: las bases de datos lineales en texto ASCII y las bases de datos relacionales. Koha utiliza una base de datos relacional (MySQL) como soporte de sus transacciones, pero puede trabajar con bases de datos en texto plano, por ejemplo para la importación y exportación de registros MARC. Koha puede crecer tanto como la base de datos relacional lo permita, y eso es mucho. La mayoría de los demás sistemas integrados de bibliotecas existentes tienen graves limitaciones en cuanto a rendimiento cuando se manejan con un alto número de transacciones. La Librería Pública de Nelsonville (EEUU) cuenta con 250.000 ejemplares y 600.000 ejemplares circulantes por año, y se maneja cómodamente utilizando Koha.Koha maneja un catálogo público (OPAC), un sistema completo de manejo para el bibliotecario (Intranet), un rastreo de ejemplares en circulación y un sistema de adquisiciones y presupuesto. En el sistema Intranet se pueden manejar ramas de la biblioteca, autoridades, adquisiciones y circulación. Koha maneja un vasto repertorio de Informes, Reportes y Estadísticas favorecidas por el uso de una base de datos relacional. Koha puede ser instalado en varios sistemas operativos con menor o mayor grado de dificultad. Existen paquetes para instalar Koha en Windows y tutoriales para la instalación de Koha en MacOS X. En este ejemplo se instala Koha sobre Debian GNU/Linux, un sistema operativo de amplio uso a nivel mundial, que tiene disponibles casi 20 mil paquetes de software completamente libre (compatible con el Decreto 3390) para su instalación de forma sencilla a través del sistema de paquetes APT.Debian Instalar Koha sobre un sistema Debian tiene muchísimas ventajas. Para empezar, Katipo, una compañía que financia partes del desarrollo de Koha, y uno de los más grandes usuarios, usa y da soporte a Koha sobre Debian. En segundo lugar, Debian es un sistema operativo con una amplia base de usuarios y desarrolladores en Venezuela y otras partes de Hispanoamérica, y es un sistema estable, que cumple y desarrolla estándares inteacionales, con el mayor crecimiento en uso en servidores y con certificaciones inteacionales por parte de diversas organizaciones. Se utilizó Debian Sarge. Inicialmente se hizo una limpieza del sistema, dejando un sistema básico de unos 98 MB., aproximadamente, sobre el cual se empezó a instalar los prerequisitos de Koha.Servidor Web Al ser un sistema basado en la Web, Koha necesita un servidor Web que atienda las peticiones de los navegadores. Koha recomienda el servidor Web de la Fundación Apache. En esta experiencia se utilizó la última versión disponible en Debian Sarge (2.0.54). Sobre este servidor Web se pueden hacer muchas mejoras para el rendimiento y la seguridad de Koha, como por ejemplo utilizar mod_security para reducir el riesgo de ataques al sistema, aislar el servidor en una jaula de software, utilizar mod_perl para acelerar el funcionamiento de Koha, etc.Apache es un servidor Web de alto rendimiento, utilizado en la mayoría de los sitios Web de Inteet, y correctamente configurado provee estabilidad y seguridad a las aplicaciones que se ejecutan sobre él. Se pueden utilizar otros servidores Web. Es notable el caso de Cherokee, un servidor Web minimalista que está en la capacidad de servir un ILS con Koha. Se puede utilizar para implementaciones donde el hardware sea muy limitado.Base de datos Koha utiliza preferentemente la base de datos MySQL. En la actualidad, Koha no soporta el último rediseño de MySQL (rama 5.x), por lo que hay que utilizar la última versión disponible de MySQL 4.x (4.1.11). MySQL contempla muchas funciones para la optimización de las consultas y la seguridad de la base de datos. Por ejemplo, en Debian la base de datos por defecto no se hace disponible a través de Inteet, sino que se mantiene para consultas locales. MySQL 4.1 ha sido removido de las nuevas versiones de Debian, por lo que es necesario mantenerse utilizando la versión estable (Sarge) o instalar MySQL 4.1 manualmente en las versiones nuevas. MySQL 5.0 introduce cambios radicales en la base de datos (como por ejemplo, la reinterpretación de muchos de los querys y la distinción de nuevas palabras reservadas) que el equipo de Koha actualmente evalúa. Se espera soporte completo para MySQL 5.0 en la próxima versión de Koha.

# aptitude update

# aptitude install mysql-server-4.1

Es conveniente activar una clave para el administrador de la base de datos. Dependiendo de la versión de Debian y la configuración del framework de configuración (Debconf), puede que ya la haya configurado. Si no, basta usar mysqladmin para hacerlo: mysqladmin password Yaz YAZ es un set de herramientas para programadores que deseen conectar sus aplicaciones utilizando Z39.50, un protocolo ISO para el intercambio de información entre ordenadores. Fue diseñado en 1988 y ha recibido varias mejoras, siendo la última y más importante en 1997. Koha requiere una versión reciente de YAZ que no estaba disponible en Debian en el momento de esta instalación. Por este motivo, nos dirigimos a la página Web de los desarrolladores de YAZ para descargar el código fuente y construir un paquete Debian a partir de la última versión disponible (2.1.38).Afortunadament
e los desarrolladores de YAZ tienen el código fuente preparado para la construcción del paquete binario, por lo que el trabajo se reduce a:

$ wget http://ftp.indexdata.dk/pub/yaz/yaz-2.1.38.tar.gz

$ tar xzf yaz-2.1.38.tar.gz && cd yaz-2.1.38/

# debuild (o bien dpkg-buildpackage o debian/rules binary)

Perl Koha está escrito en Perl, un lenguaje de scripting ampliamente utilizado en varias partes del Mundo. En Venezuela existe un grupo de apoyo, llamado Perl Mongers Venezuela, con subequipos en Caracas y en Maracay. Perl es uno de los lenguajes de programación sobre el que se ha escrito más documentación, y tiene el apoyo de grandes editoriales del ramo de la informática, como Anaya/O'Reilly.Perl es un sistema omni-presente en los sistemas de hoy en día. Existen intérpretes para muchos sistemas operativos y arquitecturas de hardware, y viene distribuido de manera estándar en MacOS X y en Debian GNU/Linux. La funcionalidad de Perl se extiende mediante módulos y paquetes, disponibles públicamente en CPAN (Red del Archivo Completo de Perl). En este inmenso repositorio se pueden encontrar librerías para generar PDF, calcular la transformada de Fourier o analizar el genoma humano.Los requerimientos de Koha son un poco más terrenales. Algunos módulos ya están disponibles en Debian, por lo que se recomienda utilizarlos. Otros hay que descargarlos de CPAN. En este caso se tienen tres opciones:

  1. Descargar
    cada módulo y sus dependencias desde los mirrors de CPAN,
    descomprimirlos y correr perl
    Makefile.PL && make && make test && make
    install
  2. Utilizar la
    consola de CPAN para instalar "automágicamente" los
    módulos y sus dependencias perl
    -MCPAN -e "install ”, o bien
    utilizando las herramientas de CPAN: cpan
    -i
  3. Generar
    paquetes Debian que se integren con el sistema APT utilizando
    dh-make-perl. El ayudante se
    descarga los módulos de CPAN, los compila y prepara un
    paquete Debian que podemos instalar en el sistema para integrarlo a
    nuestro árbol de paquetes.

Elegimos la última opción por ser la que ofrece el mejor control sobre el software instalado. Para esto se utilizó el comando dh-make-perl de la siguiente forma: dh-make-perl --notest --install --cpan '', para construir paquetes para los módulos: Locale::PO, MARC::Charset, MARC::Record, MARC::XML, Net::Z3950::ZOOM, WWW, GD::Barcode, Data::Random y PDF::Reuse::Barcode. Los archivos generados fueron:

  • liblocale-po-perl_0.16-1_all.deb
  • libmarc-charset-perl_0.95-1_all.deb
  • libmarc-record-perl_1.38-1_all.deb
  • libmarc-xml-perl_0.83-1_all.deb
  • libnet-z3950-zoom-perl_1.11-1_i386.deb
  • libwww-perl_5.805-1_all.deb
  • libdata-random-perl_0.05-1_all.deb
  • libgd-barcode-perl_1.15-1_all.deb
  • libpdf-reuse-barcode-perl_0.05-1_all.deb

Los módulos necesarios que ya estaban disponibles en Debian son:

  • libclass-accessor-perl
  • libdate-manip-perl
  • libevent-perl
  • libhtml-template-perl
  • libxml-sax-perl
  • libdate-calc-perl
  • libxml-simple-perl

Otros módulos requeridos por Koha son instalados como dependencias de MySQL (como DBI y DBD::MySQL) o como dependencias de los módulos anteriormente nombrados.

# dh-make-perl --notest --install --cpan Locale::PO (repetir para los otros ocho módulos)

# aptitude update

# aptitude install libclass-accesor-perl libdate-manip-perl libevent-perl libhtml-template-perl libxml-sax-perl libdate-calc-perl libxml-simple-perl

Si está instalando Koha en otra distribución de GNU/Linux (o en una versión más nueva de Debian), verifique si su distribución ya ofrece versiones pre-empaquetadas de estos módulos, para ahorrarse el tiempo de implementación de la solución empaquetando algo ya hecho. Por ejemplo, en Debian Etch muchos paquetes del namespace MARC ya están empaquetados.PDF::API2 El generador de códigos de barras de Koha funciona preferentemente con la versión 0.3r77 de PDF::API2. Las versiones actuales de PDF::API2 han cambiado la API haciendo que el generador de códigos de barras de Koha falle silenciosamente. Utilizando Backpan, el archivo histórico de CPAN, podemos descargar la versión 0.3r77 e instalarla manualmente:

# wget http://backpan.cpan.org/modules/by-module/PDF/AREIBENS/PDF-API2-0.3r77.tar.gz

# tar xzf PDF-API2-0.3r77.tar.gz && cd PDF-API2-0.3r77/

# perl Makefile.PL && make && make test && make install

Instalación La versión más reciente de Koha es la 2.2.6, disponible en Savannah. Koha es liberado con un instalador (escrito en Perl) basado en la línea de comandos. Al ejecutarlo, nos saluda y nos informa que todos los módulos de Perl requeridos han sido instalados. De haber faltado alguno, probablemente yo me esté equivocando en este tutorial, o bien de verdad falta uno. Es conveniente que, si no está instalando 2.2.6, lea los Release Notes primero para evitar tener problemas por ignorar lo obvio. Koha preguntará entonces las rutas donde se desean instalar los scripts y los templates de OPAC e Intranet. Se recomienda instalar bajo /usr/local, para tener un control del software instalado fuera del sistema de manejo de paquetes APT. Dependiendo de nuestro grado de apego a la última versión de FHS, puede que queramos instalar en otra parte.Luego hay que introducir los datos de la base de datos. Podemos inventaos un nombre de la base de datos y un nombre de usuario con su clave, luego se nos preguntará la clave del administrador de la base de datos que debemos conocer de 2.2. Luego se nos da la oportunidad de seleccionar el formato MARC con el cual deseamos instalar (en nuestro caso, el MARC21 en inglés) y de importar sets predefinidos de datos (en forma de dumps SQL). Koha genera un archivo compatible con Apache (1.3, 2.0) que debemos incluír en la configuración del servidor Web. En mi caso descubrí que era necesario modificar un poco el archivo generado, pues no había match en los VirtualHosts. Con tirar el archivo generado en /etc/apache2/conf.d o /etc/apache2/sites-enabled y reiniciar Apache2 es suficiente. Koha hará otras preguntas más triviales, incluyendo el correo del administrador, el nombre del sitio, etc.

# wget http://download.savannah.nongnu.org/releases/koha/koha-2.2.6.tar.gz

# tar xzf koha-2.2.6.tar.gz

# cd koha-2.2.6/

# perl installer.pl

Usando Koha Koha está instalado y listo para ser usado en este momento. Nuestro servidor Web debe poder servir las páginas de OPAC y de la Intranet, y podemos entrar al sistema con el usuario y la clave de la base de datos, o crear nuevos usuarios de la Biblioteca. Podemos modificar algunos parámetros operativos bajo "Parameters" en la Intranet, incluyendo el nombre de la Biblioteca, las ramas, las impresoras, los logos, el generador de códigos de barras, etc.Traducciones Koha es liberado con un archivo .po con líneas traducidas del inglés al castellano (en sus localizaciones de España y Argentina). Koha se distribuye con un script ayudante, tmpl_process3.pl, que convierte de .po a .tmpl y viceversa. Los archivos .tmpl son los templates utilizados por Koha, que está desarrollado con una metodología similar-a-MVC: separa la presentación del contenido (usando XHTML, CSS y Javascript) del procesamiento de los datos (utilizando Perl y módulos de CPAN) de la fuente de datos (una base de datos relacional o plana, registros MARC o datos del protocolo Z.3950). Los archivos .tmpl son parte de la presentación del contenido, pues carecen de código en Perl. Para cada carpeta de OPAC se corre el script con el archivo .po como entrada y el directorio de salida. Con una línea de bash podemos automatizar el procedimiento, tomando en cuenta que tenemos una lista de los directorios del OPAC guardada en Koha-dirs.txt:# for part in `cat ~/Koha-dir.txt`; do tmpl_process3.pl install -s po/default_intranet_es_AR.po -i /usr/local/Koha/intranet/htdocs/intranet-tmpl/default/en/$part -o /usr/local/Koha/intranet/htdocs/intranet-tmpl/default/es/$part; done

Standard