Category Archives: F/OSS

Securing Z39.50 traffic from Koha and Evergreen Z39.50 servers using YAZ and TLS

There’s often more than way to search a library catalog; or to put it another way, not all users come in via the front door.  For example, ensuring that your public catalog supports HTTPS can help prevent bad actors from snooping on patron’s searches — but if one of your users happens to use a tool that searches your catalog over Z39.50, by default they have less protection.

Consider this extract from a tcpdump of a Z39.50 session:

No, MARC is not a cipher; it just isn’t.

How to improve this state of affairs? There was some discussion back in 2000 of bundling SSL or TLS into the Z39.50 protocol, although it doesn’t seem like it went anywhere. Of course, SSH tunnels and stunnel are options, but it turns out that there can be an easier way.

As is usually the case with anything involving Z39.50, we can thank the folks at IndexData for being on top of things: it turns out that TLS support is easily enabled in YAZ. Here’s how this can be applied to Evergreen and Koha.

The first step is to create an SSL certificate; a self-signed one probably suffices. The certificate and its private key should be concatenated into a single PEM file, like this:


Evergreen’s Z39.50 server can be told to require SSL via a <listen> element in /openils/conf/oils_yaz.xml, like this:

To supply the path to the certificate, a change to will do the trick:

For Koha, a <listen> element should be added to koha-conf.xml, e.g.,

zebrasrv will also need to know how to find the SSL certificate:

And with that, we can test: yaz-client ssl:localhost:4210/CONS or yaz-client ssl:localhost:4210/biblios. Et voila!

Of course, not every Z39.50 client will know how to use TLS… but lots will, as YAZ is the basis for many of them.

Conservation of enthusiasm

One of the tightropes I must walk on as the current release manager for Koha is held taut by the tension between the necessity of maintaining boundaries with the code and the necessity of acknowledging that the code is not the first concern.

Boundaries matter. Not all code is equal: some is better, some is worse, none is perfect. Some code belongs in Koha. Some code belongs in Koha for lack of a better alternative at the time. Some code does not belong in Koha. Some code will stand the test of time; some code will test our time and energy for years.

The code is not primary. It is no great insight to point out that the code does not write itself; it certainly does not document itself nor pay its own way. Nor does it get to partake in that moment of fleeting joy when things just work, when the code gets out of the way of the librarian and the patron.

What is primary? People and their energy.

Enthusiasm is boundless. It has kept some folks working on Koha for years, beyond the impetus of mere paycheck or even approbation.

Enthusiasm is limited. Anybody volunteering passion for a free software project has a question to answer: is there something better to do with my time? If the answer turns into “no”… well, there are many ways in this world to contribute to happiness, personal or shared.

Caviling can be costly — possibly, beyond measure. One “RTFM” can eliminate an entire manual’s worth of help down the road.

On the other hand, the impulse to tweak, to provide feedback, to tune a new idea, can come from the best of intentions. Passion is not enough by itself; experience matters, can guide new effort.

It’s a tightrope we all walk. But the people must come first.

My meditation: what ways of interacting among ourselves conserves enthusiasm, and thereby grows it? And how do we avoid destroying it needlessly?

Sharing is for curmudgeons, too

Dalek egg frontal view

CC-BY photo by Nancy Sims

It’s always neat to find out that somebody whose work you follow in one context has done something interesting in a completely different field.  Nancy Sims, who is an attorney and the Copyright Program Librarian at the University of Minnesota Libraries, writes the Copyright Librarian blog.  As I found out on Friday when I read her her post On releasing an image to the wilds…, she also decorates eggs… elaborately.  Take a look at our friend on the right, and if you’re a Whovian like me, take another moment to squee.

She posted her photos of the Dalek egg on Flickr under a Creative Commons Attribution license, and the images went viral.  As you might expect, the photos get a spike in interest, including reblogs, around Easter every year. Sometimes the images get attributed properly, sometimes they do not. And sometimes Sims gets requests for permission to use the photos, including one, amusingly enough from the BBC.

Of course, one of the points of the Creative Commons licenses is that you don’t have to ask permission to make use of CC-licensed content as long as you follow the terms of the particular variant that the creator applied. As Sims wrote:

[…] I hate it when people ask for permission to use things that already carry a CC-license sufficient to the purpose.

Further, in her response to the BBC, request, she says:

I am a big fan of Creative Commons licenses, and would like to see them used more (when appropriate) by everyone!

This circles back to the title of my post: Sharing is for curmudgeons, too.  To be clear, I’m not using the word “curmudgeon” to refer to anybody in particular. You may be a curmudgeon most of the time, never, or only just in the morning before caffeine appears. You may simply want to get stuff done quickly, with the least amount of interaction required.

Free and open licenses are perfect for curmudgeons. Why? No need to ask for permission. Need an image of a pristine lawn for your website? You can grab a CC-BY image, put it up with attribution, and never ask permission. Need to tweak your webserver’s software? If it’s free software, you can just go get the source code and modify it — and never ask for permission.

It works in the other direction. If you’ve written a useful little utility for yourself, you can slap on a free software license and publish it on Gitorious… then forget about it. If somebody else finds it useful, great — and they don’t need to bother you about it if they want to fix a bug or enhance it!

Free software licenses help promote community, which is important for any project that is larger in scope than a single person. If we can all see and talk about the code, we can made it better faster. But free and open licenses also reduce friction, and that’s where the curmudgeons of the world come in — often great things come from somebody working alone in her figurative garage.

Curmudgeons of the world — unite! Or not, it’s your choice.

A pause to reflect

Libraries are sneaky, crafty places.  If you walk into one, things may never look the same when you walk out.

Libraries are dangerous places.  If you open your mind in one, you may be forever changed.

And, more mundanely, university libraries are places that employ a lot of work-study students.  I was one of them at Ganser Library at Millersville University.  Although I’ve always been a bookish lad, when I started as a reference shelver at Ganser I wasn’t thinking of the job as anything more than a way to pay the rent while I pursued a degree in mathematics.  And, of course, there were decidedly limits to how much fascination I found filing updated pages in a set of the loose-leaf CCH tax codes.  While some of the cases I skimmed were interesting, I can safely say that a career in tax accountancy was not in my future, either then or now.

Did I mention that libraries are crafty?  Naturally, much of the blame for that attaches to the librarians. As time passed, I ended up working in just about every department of the library, from circulation to serials to systems, as if there were a plot to have me learn to love every nook and cranny of that building and the folks who made it live.  By the time I graduated, math degree in hand, I had accepted a job with an ILS vendor, directly on the strength of the work I had done to help the library migrate to the (at the time) hot new ILS.

While writing this post, it has hit me hard how much I owe an incredible debt of gratitude to my mentors at Ganser.  To name some of them, Scott Anderson, Krista Higham, Barbara Hunsberger, Sally Levit, Marilyn Parrish, Elaine Pease, Leo Shelley, Marjorie Warmkessel, and David Zubatsky have each taught me much, professionally and personally.  To be counted among them as a member of the library profession is an honor.

Today I have an opportunity to toot my horn a bit, having been named one of the “Movers and Shakers” this year by Library Journal.  I am grateful for the recognition, as well as the opportunity to sneak a penguin into the pages of LJ.

Original image by Larry Ewing

Original image by Larry Ewing

Why a penguin? In part, simply because that’s how my whimsy runs. But there’s also a serious side to my choice, and I’m happy that the photographer and editors ran with it. Tux the penguin is a symbol of the open source Linux project, and moreover is a symbol that the Linux community rallies behind. Why have I emphasized community? Because it’s the strength of the library open source communities, particularly those of the Koha and Evergreen projects, that inspire me from day to day. Not that it’s all sunshine and kittens — any strong community will have its share of disappointments and conflicts. However, I deeply believe that open source software is a necessary part of librarians (I use that term broadly) building their own tools with which to share knowledge (and I use that term very broadly) with the wider communities we serve.

The recognition that LJ has given me for my work for Koha and Evergreen is very flattering, but for me it is at heart an opportunity to reflect, and to thank the many friends and mentors in libraryland I have met over the years.

Thanks, and may the work we share ever continue.

Thanks for the tip

I wasn’t one of the people viscerally affected by Google’s announcement of the forthcoming shutdown of Google Reader, since so far I’ve relied on a combination of standalone RSS clients and antediluvian hit-the-refresh-button-repeatedly habits.  I am dinosaur: hear me roar!

However, the announcement prompted me to take another look at RSS readers.  Nowadays, I rotate among my PC, phone, tablet, and laptop frequently, so going back to a purely standalone reader like NetNewsWire wasn’t appealing.  The online services like NewsBlur would fit my needs better than a standalone reader (and I’m willing, even happy, to pay for the hope of longevity), but suffer from two disadvantages.  They’re not open source, and as a consequence, it’s hard to dig through their guts.  And I like digging!

I first found out about Tiny Tiny RSS from one of Ed Corrado’s tweets, and like a lot of people, visited the website and saw… a whole lotta nothing at first.  Google really ought to give their open source competitors a little more warning of service cancellation announcements so that they can beef up their web hosting in advance!

Fortunately, I persevered and installed it.  Tiny Tiny RSS, which is primarily written and maintained by Andrew Dolgov, is a web-based feed reader that you can install on your web server.  It’s licensed under version 2 of the GPL.  Installation is very simple if you have a VPS, and looks fairly easy to install on shared hosting as long as it provides MySQL or PostgreSQL databases.  Once you have it running, you can easy import an OPML file or manually subscribe to feeds.  The web interface for reading and managing feeds is clean and responsive. It also has an API and there are at least two Android clients. I couldn’t find an iOS client, but I suspect that somebody will scratch that itch soon.

So far, I’m quite happy with it.  Thanks, Ed!  Thanks, Andrew and all of the the other contributors!

Embracing politics

“It’s just politics.”

This is a common enough phrase, and the usual implication of it is dismissive: if it’s just politics, it’s not about anything really important. It’s grandstanding, it’s just more sound and fury, it’s a sausage factory. At best, it’s the domain of the politicians; let them worry about it. There’s a long post in me about how the attitude behind “it’s just politics” contributes to poor participation in democracy and bad policymaking.

This is not that post.

The inspiration for the post before you was somebody making a comment to more or less that effect the other day in regards to the past and ongoing controversy regarding Koha, its licensing, its trademarks, and its forks. My position on the matter should come as no surprise. If you want Koha, go to If you’re a librarian using it, please contribute back where you can and participate in the Koha community. If you’re a vendor supporting, implementing, or hacking it, know that it is not just yours, you should give back, obey both the letter and the spirit of the GPL, be a good community member, and don’t worry: you can do all that and still make money! Look Ma! No monopoly!

But dragging myself back on topic, one thing to clear up first: this post is not about the comment that inspired it. I am going after a generality here, not any particular throwaway comment.

What can “it’s just politics” mean when talking about a dispute concerning an open source project and its licensing? Quite a few things:

  1. (Re)opening this can of worms is going to derail any discussion of the software itself for weeks. This can be a very real concern: disputes about the license or the direction of the project can take years to resolve, can become very acrimonious, and frankly can be terribly boring. I, for one, personally don’t find license disputes inherently interesting, and I strongly suspect that most participants in F/OSS projects don’t either. But bitter experience has shown me that sometimes it is necessary to participate anyway and not leave it just to the language lawyers. What can make resolving disputes even more difficult is that email and IRC as communication media have weaknesses that can exacerbate conflict.
  2. Less talk, more code! What doesn’t get done if you’ve just spent an hour fisking the latest volley in the GPL2+ vs. AGPL3 debate? There’s an opportunity cost — that hour wasn’t spent writing some code, or testing, or proofreading the latest documentation edits. That opportunity cost can compound — if you don’t get the kudos for the results of that fisking and miss the warm feeling you get seeing a longstanding bug get closed because of your patch, you may end up disengaging.
  3. Can’t we all get along? It can be very unpleasant being in the middle of an important dispute. While I do think that the Koha community has come out of this stronger than ever, I also mourn the opportunities for human connection and friendships that have been permanently sundered as a result of the conflict.
  4. Newbie here. What is going on?!? It can be very disorienting checking out the mailing list of a F/OSS project you’re considering using only to find that everybody apparently hates each other. It can be even worse if you find yourself making an innocent statement that gets interpreted as firmly putting yourself in one camp or another. Tying this back to the previous point, is the Koha community stronger? Yes. Has it also developed a few shibboleths that cause project regulars to sometimes come down a little too hard on new members of the community? Unfortunately, yes.
  5. From the point of view of an external observer, it’s hard to make sense of what’s going on. It’s all too easy to lose the thread of what’s is being disputed, and the definitive histories of the war tend to come out only after the last bodies have been buried. On the other hand, particularly if you’re an external observer who has some external or self-imposed reason to make judgements about the dispute, do your research: a snap conclusion will almost certainly be the wrong one, or at least lack important nuance.
  6. The noise is getting in the way of figuring out if this software is useful. Fair enough — and if you’re a librarian evaluating ILSs, obviously a key part of your decision should be based on the answer to the following question: will a given ILS solve my problem, either now or in the the realistically foreseeable future. But read on, since that isn’t the only question to be answered.

The outcome of a big dispute in a F/OSS project can be positive, but there’s no question that it can be tremendously messy and painful. But just like in the realm of the elephants, donkeys, and greens, politics informs policy. And policy consequences matter. And there’s no royal road to success:

  • Software doesn’t write itself. People are always involved, and unless you’ve just fired-and-forgotten some code into the wild, any F/OSS project worth thinking about involves more than just one person.
  • The invisible hand is still here. The economics of a F/OSS project may not be based on cash money (though there’s a place for both money and passion), but the fundamental economic problem of resource allocation and human motivation is inescapable.
  • Communities don’t build themselves, and they certainly don’t maintain themselves without effort. In the case of library-related F/OSS projects, there are special considerations: both the library profession and F/OSS hackerdom value sharing. However, there are significant differences in the ways that libraries and hackers tend to communicate and collaborate, and those differences can’t be negotiated without a lot of communication.
  • Regardless of whether you fall more on the “F” side or the “OS” side of the divide in the acronym, F/OSS works for a combination of baldly pragmatic and ethical reasons. But as the very structure of the “F/OSS” acronym implies, there’s are many disagreements and differences of emphasis among F/OSS contributors and users.

What’s missing from these bullet points? The One True Path to Open Source Success. Why is it missing? Because it doesn’t exist: free software has been around long enough that there’s a good body of recommendations on how to do it well, but there’s no consensus.

And if there’s no consensus, then what? It has to be found — or created — or not found, leading to a hopefully amicable parting of the ways. But that can’t happen without discussion, conflict, and resolution. While it certainly isn’t necessary for everybody to participate in every single debate, (constructive!) engagement with the discussion can be a valuable contribution in its own right. If you can help improve how the discussion takes place, even better.

If you or your institution has a stake in the outcome, participating is part of both the duty and promise of F/OSS for libraries: owning our tools, without which our collections will just gather dust.

Put another way, politics, in its broadest and most noble meaning, can’t be avoided, even if engaging means spending some time away from the code. You may as well embrace it.

By the way, I suspect that if you did get manage to get software to write itself, you still couldn’t escape politics. I doubt that an artificial intelligence creative enough to code can be built without incorporating a sufficient degree of complexity that it would be able to avoid all moments of indecision. AI politics may well end up looking rather bizarre to humans, but they’d still be faced with the basic political problem of resolving conflict and allocating resources.