Steps to set up public-key based login into a vagrant managed kohadevbox VM
What is kohadevbox?
As the README.md at https://gitlab.com/koha-community/kohadevbox says – “Create a development environment for the Koha ILS project. It uses Vagrant and Ansible to set up a VirtualBox.” Basically it automates the long and somewhat complex process of manually setting up a development system for #kohails.
From the website – PuTTY is an SSH and telnet client, developed originally by Simon Tatham for the Windows platform. PuTTY is open source software that is available with source code and is developed and supported by a group of volunteers. It is our go-to tool on Windows for accessing physical Koha boxes or VMs via SSH.
Vagrant sets up SSH service on the VM to use public-key authentication. Therefore our PuTTY instance needs to know the private key that Vagrant had setup inside the VM, in order to login into it. As many posts in Stackoverflow indicates, this is a point where many people get stuck. Usually they try with %USERPROFILE%\.vagrant.d\insecure_private_key and that typically fails.
Steps for kohadevbox
Using git-bash go to the directory where you had cloned kohadevbox. Be default it will be %USERPROFILE%/git/kohadevbox if you have simply followed the instructions from kohadevbox README.md file. In our case, it was %USERPROFILE%/gitdev/kohadevbox as we had changed it.
Run the command
You should see something like this:
The line to note in the output is IdentityFile. That’s the private key you need to grab and feed to PuTTYGen for it to convert it into a PuTTY compatible .ppk format private key.
NOTE: This path to the key is going to be different for different users, so do not attempt to copy-paste what you see here, instead use your own IdentityFile value.
Now we convert the vagrant_private_key from IdentityFile and save it as a .ppk file.
And lastly we import it into PuTTY like this and we are good to go!
Finally we are logged in into the VM
NOTES: The versions of software used – (a) PuTTY.exe – 0.71 (b) Vagrant – 2.2.7 (c) Git Bash – 2.25.0 (d) VirtualBox – 6.1.2
Fixing the issue of checked out items barcodes’ not showing up for patrons logged into the Koha OPAC.
Earlier this morning, Pranab Roy who manages the Library at the Karnavati University‘s UnitedWorld School of Business‘s Kolkata campus popped up on WhatsApp with a question – “Sir, why is Koha not showing the barcode / accession number of a borrowed document when an user logs in into their own account via the OPAC?”
This is what he meant. And this is actually the expected behaviour, with Koha doing exactly what it was asked to do. I could understand his confusion since the OPAC search’s details view showed the barcode quite nicely, then why not for the users themselves?
A bit of backstory
Karnavati University Libraries had shifted to L2C2 Technologies‘ cloud platform from a pre-existing Koha instance maintained by a 3rd party. As such the system had quite a few issues. While we had fixed a larger number of these during the initial on-boarding stage, some of these are getting ironed out only now as the librarians hit these “bumps on the road”. Pranab’s problem was one such.
The option to display the barcodes for a logged-in OPAC user’s checkouts (issues) is driven by the SHOW_BARCODE patron attribute. In Koha, patron attributes or more correctly ExtendedPatronAttributes are library-defined custom fields that can be applied to patron records e.g. voter / aadhaar card number, registration number etc.
SHOW_BARCODE is a boolean variable that is defined as either Yes or No. and it is loaded into Koha usually during the web-installer phase of Koha’s installation from the optional SQL dump file: /usr/share/koha/intranet/cgi-bin/installer/data/mysql/en/optional/patron_atributes.sql in Debian package based installations. The tiny file contains a single SQL INSERT statement:
INSERT INTO `borrower_attribute_types` (`code`, `description`, `repeatable`, `unique_id`, `opac_display`, `staff_searchable`, `authorised_value_category`) VALUES (‘SHOW_BCODE’, ‘Show barcode on the summary screen items listings’, 0, 0, 1, 0, ‘YES_NO’);
In the case of Karnavati University this optional patron attribute was not imported during the *original* installation done by the 3rd party support provider at the time. And without “SHOW_BARCODE” being set, Koha had no way of displaying the barcodes of checked out books to patrons logged in via the OPAC.
In the end, the following two lines followed by enabling the ExtendedPatronAttributes system preference cleared off the issue for Karnavati: $ cd /usr/share/koha/intranet/cgi-bin/installer/data/mysql/en/optional $ mysql -uroot -p koha_karnavati < patron_atributes.sql.
A memcached restart later (to be safe rather than sorry) the OPAC started showing the barcodes to logged-in patrons.
This is part of the series of blog posts on how to extract your data from a Koha system where you unable to access the DB directly, but where you have “superlibrarian” access. In this part, we talk about extracting the patron images stored inside the patronimage table in your Koha database.
You should be comfortable using the GNU/Linux command line
A Linux system with cURL and LibreOffice installed
Superlibrarian userid and password of your Koha instance
Use the Koha Reports module to download the list of the borrowernumbers of patrons having their image in the db
Remove the header line and save it as a text file, with one borrowernumber per line
Use cURL to get the CGISESSID cookie using the authentication SVC API call
Execute the BASH script, passing the authenticated session id and the file holding the list of borrowernumbers as command line parameters
Use the Koha Reports module to generate the IDLINK.txt batch patron image uploader file
Patron images in Koha are stored in the patronimage table of the database. The table has following schema:
the borrowernumber of the patron this image is attached to (borrowers.borrowernumber)
the format of the image (png, jpg, etc)
A blob is a “binary large object” which means it is not a text field. The contents won’t make any sense if we used the report module to SELECT imagefile FROM patronimage. This brings cURL into the picture.
The patron image is served on the OPAC / staff client using the patronimage.pl Perl script using an URL like this: http://<your_instance>/cgi-bin/koha/members/patronimage.pl?borrowernumber=<borrowernumber>.
But before we can run cURL on this URL, we must do one more thing. We need our BASH script to login using our superlibrarian userid and password using Koha authentication web service API call.
We need to do this for two reasons: (a) login into our Koha instance with superlibrarian access and (b) get hold of the CGISESSID cookie.
Putting it all together
A simple SQL report as given below with fetch us the borrowernumber of patrons with their image stored in the DB.
SELECT borrowernumber FROM patronimage
We will download the result as Open Document spreadsheet.
Next we copy and save the list of patron borrowernumbers into a text file (let’s call it list-of-pix.txt), with one borrowernumber per line.
Lets put together our small BASH script. We shall call it get_pix.sh.
while read LINE
do curl -b CGISESSID=$1 -o ./patronimages/$LINE.png http://<your_instance>/cgi-bin/koha/members/patronimage.pl?borrowernumber=$LINE
done < $2
NOTE: <your_instance> need to be changed with **your** actual server URL.
Make the script executable by running chmod a+x get_pix.sh.
And we shall see the patron images getting downloaded.
Once the patron images have all been downloaded to patronimages folder created by the get_pix.sh script, its time to generate the IDLINK.txt file, which we will place in the aforementioned patronimages folder. Again, we shall turn to Koha's Reports module with this small SQL script:
SELECT CONCAT(borrowers.cardnumber,", ", patronimage.borrowernumber, ".png") AS 'IDLINK'
LEFT JOIN borrowers ON patronimage.borrowernumber=borrowers.borrowernumber
This will generate our listing for the IDLINK.txt. If you are not sure about what IDLINK.txt does, please read up from here.
Download the report as Open Document Spreadsheet, remove the header line and copy the rest into a text file and save it as IDLINK.txt in the patronimages folder.
Zip up the patronimages folder as mentioned here and we have the patron images ready for a batch upload.
In case you are wondering about the context of this song, ever since NECOPAC z39.50 service went live last month, the most repeated common question coming from LIS students and professionals on FB has been – “What does ‘Z’ stand for in z39.50?”.
For some, it is a question that popped up in their head when encountering z39.50 search in Koha. For others, especially from West Bengal, India, apparently this is a question that is being asked at the currently on-going interview for WBHRB.
Some wondered that it perhaps stood for the company that started z39.50, while others had no idea.
So what is z39.50?
In very simple terms Z39.50 is a communications protocol for searching and retrieving information from a bibliographic information database over a TCP/IP computer network. It is covered by ANSI/NISO standard Z39.50, and ISO standard 23950:1998. The standard is maintained by US Library of Congress.
Cataloguers mostly encounter z39.50 when they attempt to do copy cataloging. Copy cataloging is a process of fetching and editing a pre-existing bibliographic record from a z39.50 server instead of creating a completely new record from scratch. Thus helping to save time, effort and therefore money, while bringing in a certain standard in cataloging quality.
Ok! Just tell me what “Z” stand for!
Asking what “Z” represents is actually asking the wrong question. The correct question to ask is “What does Z39 stand for?“.
The short answer
On its own, Z39 simply refers to the American National Standards Committee Z39. By itself “Z” has no special meaning. In the present context, Z39 refers to NISO standards related to publishing, bibliographic and library applications in the United States of America, all of which start with “ANSI/NISO Z39.”.
Towards the end of this post a few example NISO standards have been listed.
The long answer
To understand we have to look back at the history of standardization process as it happened in the United States of America during the last century.
Exactly 100 years back in 1918, 5 engineering organisations and 3 federal organisations came together to form the American Engineering Standards Committee (AESC). In 1928, AESC re-organised to form the American Standards Association (ASA). In 1966, ASA became the USA Standards Institute, followed by a further transformation in 1969 to become the American National Standards Institute or ANSI as we know it today.
The centenary video from ANSI describes the journey of standardization in United States and its global impact.
It was during the ASA years that formal standardization of librarianship started to take shape.
In 1935 Carolyn F. Ulrich of New York Public Library led the initiative to create a standard for arrangement of periodicals that became known as Z29.1-1935.
In 1937, prompted by various library associations, ASA appointed Ulrich to represent ASA on International Standards Association’s (ISA) Committee 46 – an international committee on documentation.
This further led to the organisation of a national committee on library standards in June of 1939. The committee was simply named as “Committee Z39” and was tasked with setting up
“Standards for [library] concepts, definitions, terminology, letters and signs, practices, methods, supplies and equipment.”
Over time it came to be known as the “American National Standards Committee Z39“. In 1984, it changed its name and structure to become the National Information Standards Organization (NISO). NISO today continues to develop, maintain and publish technical standards related to publishing, bibliographic and library applications in the United States of America as an ANSI accredited SDO (standards designator organization). All NISO standards all start with “ANSI/NISO Z39.” (read as zee or zed thirty nine dot).
To cut a long story short, z39.50 is simply the 50th NISO approved standard