Evergreen Indiana Annual Conference

Thanks to everyone who attended the annual conference last week and to those who presented! Each individual’s willingness to participate, mentor, teach and ask makes us a stronger group together.

Please take a moment to fill out the survey below so we can improve next year’s conference:

https://www.surveymonkey.com/s/7RFGJRM

Presentations from the annual conference can be found at the URL below along with the State of Evergreen presentation given by the Evergreen Indiana Director, Wendy Knapp, which includes the results of the development survey:

http://blog.evergreen.lib.in.us/?event=evergreen-indiana-annual-meeting

Just a reminder that several of the presentations given at the conference can be scheduled right now with your regional coordinator! Contact information and areas of the state covered by each regional coordinator can be found here: http://www.in.gov/library/pdo.htm

• Evergreen Indiana – Holds class: Holds and searching in Evergreen. This class is offered each month at ISL, quarterly out in the field and, since it is a new class offering, by request from member libraries until December 2013. We have had such a positive response and high number of requests that we have integrated the class into our core Evergreen Indiana curriculum which includes Basic Circulation, Basic Cataloging and Admin/Reports. Beginning in 2014, the Evergreen Indiana – Holds class will not be available by request from member libraries but will continue to be offered each month at ISL and quarterly throughout the year out in the field. Integrating this new class into the regularly scheduled Evergreen classes will ensure that it is consistently available and that the location is flexible since it is offered in either central Indiana or in one of the four regions of the state.

• Dealing with difficult patrons

• Cleaning up the patron database: Will be offered as a webinar this fall by the Circulation Committee.

• Explicit Content: Reports presentation. Self-paced advanced reports class available through WebJunction Indiana: http://www.in.gov/library/files/Accessing_the_Reporting_and_Admin_Overview_Self-Paced_Tutorial.pdf

Well, I've just been informed that I'm a liar, or misspoke if you prefer.

I didn't know when I made the previous post that we are actually still using 1,000 as our MaxRequestsPerChild setting. I guess I misunderstood what I was being told last week, and I certainly did not bother to check our configuration before making the previous blog post.

I apologize for any confusion this may have caused. However, the general observation that you may have to experiment with your Apache settings before you find the right combination for your server and its usage patterns still stands. You can't always expect the defaults to work right out of the box.

Another update to share with you what MVLC is doing with our Apache configuration for Evergreen.

We found last week with the MaxMemFree setting at 16 and MaxRequestsPerChild at 1,000 that we were getting more texts from our monitoring software about the load being high on our Evergreen server. We thought this might have to do with more frequent turnover among the Apache child processes, so we adjusted MaxRequestsPerChild back up to 10,000. However, during overnight monitoring, we discovered that this made the situation worse, or at least put us back where we were before trying all of these changes.

In the end, we have set MaxRequestsPerChild to 5,000 while leaving MaxMemFree at 16. We&aposve been running this configuration for several days, including over the weekend, and things seem to have really settled down on our server. You may have to experiment with the settings to find something that works for you if you think you are having this issue.

Membership Business Meeting, May 9

Evergreen Indiana by-laws recommend that one representative from each library attend the annual business meeting which is taking place during the Evergreen Indiana Annual Conference on Thursday, May 9. Below members can find the draft agenda and membership minutes from the meeting last year. One copy per table will be provided so feel free to bring a copy of your own.

Register for the Evergreen Indiana Annual Conference by 4:30pm today (May 7)!

• Draft agenda for May 9
• Minutes from last membership meeting, April 27, 2012

Submit library card or item barcode orders

Just a reminder that you may place item and patron barcode orders beginning Monday, May 6 until Friday, May 10. The library will contact Amanda Marcengill at Creative DataProducts via email (amarcengill@creativedataproducts.com) or telephone (864-662-1310) with the following information:

• Item barcodes or patron library cards? If patron library cards, green or blue?
• Quantity (There is a minimum order of 500 for both item barcodes and patron library cards).
• Beginning barcode number.
• Library name, contact email and telephone number.

Email hold notification

The Circulation Committee reviewed the email hold notification and made changes to the statement highlighted in bold below to further explain the possible fee that might be assessed by their checkout library.

“The item you requested is available for pickup from the Library. Please pick up the item within 7 days.

According to your checkout library policy, a fee may be assessed if you do not pick up your item within 7 days.
Contact the Circulation Desk with any questions or requests.”

Thomas just told me that he changed another Apache configuration variable that seems to have helped things. He set the MaxMemFree directive to 16 in our mpm_prefork configuration section. This setting also limits the memory that an individual Apache process can consume before releasing the memory back to the operating system.

I thought we'd share this in case anyone else is bumping their heads against memory issues with Apache.

TL;DR: We've had trouble with the memory consumption of Apache processes on our Evergreen server since we did our latest update on April 14, 2013. Along the way to figuring this out we've had a few minor detours and fixed another bug. Our breakthrough came when one of us realized that the longer Apache processes run the more memory they were using. We have made changes to our Apache configuration as a mitigation strategy. Basically, we have lowered our MaxRequestsPerChild from 10,000 down to 1,000. This appears to have helped, but only time will tell.

Read on for the gory details....

Since we updated our Evergreen installation on Sunday, April 14, 2013, we've had trouble with what now appear to be memory leaks on the server, specifically involving Apache or some module that we load into it, perhaps Evergreen mod_perl code.

The first time we noticed that we had a problem was when memcached crashed on Tuesday the 16th. We restarted the memcached service, and it crashed again in a day or two. This time, we found a message in the logs indicating that the server's operating system had shut memcached down because the operating system was out of memory. We moved the memcached service to another server, and all seemed well for a few more days.

As the following work week began, we got calls of problems with Evergreen. We checked the server and it seemed busy. We also found a message in the operating system logs warning of a possible SYN flood attack on port 80, the port used by the web server for plain text traffic. We also counted a high number of connections to the server on this and related ports.

We restarted the web server software, and the situation immediately improved. We kept an eye on the server for the rest of the week and restarted services as necessary. At this point, it looked like an attack from outside the network, but we never saw that message about the SYN flood in the logs again. Perhaps the attack, or the appearance of an attack, was a one-time thing. In the end it turned out not to be the cause of our troubles.

The problems occurred again on the morning of Monday, the 29th. This time there were several OpenSRF Listener processes using up 100% of CPU. (With a multicore system it is possible to have several processes using 100% of a CPU.) We restarted Evergreen and related services on the server, and the situation immediately improved. We kept an eye on the number of connections and the processes on the server for the rest of the day, and everything seemed all right from that point of view.

Our problem struck again on Tuesday morning just before 9:00 am. This time, we were watching as it happened, and let it unfold. As the connection count skyrocketed, we also took a look at where the connections were coming from and what state they were in. It turns out what we saw looked like the opposite of a SYN flood. The majority of the HTTP connections were from the server to itself, and they were in a CLOSE_WAIT state. A large number of connections in this state often points to a problem, particularly when your server is talking to itself.

We spent the rest of Tuesday tracking down the source of these connections in the Evergreen source code. It turns out that when Evergreen goes to request a book jacket image, table of contents, or other added content, it first makes a connection to itself at a special URL to run the code to do the retrieval from the added content provider, Syndetics in our case. This extra step makes it easy for the Evergreen server to cache the information of popular titles, so it only has to ask Syndetics for the covers, etc., once rather than every time a patron brings up a record. After the information is retrieved from the cache or over the network from the added content provider, the content is read from the connection to the local server and served up via the TPAC. These connections were not being reused. A new one was created for every added content request. They were also not being shut down, so they were just dangling, kind of like a phone being left off the hook.

"Ah ha!" We thought we had found our smoking gun. These dangling connections must be responsible for the server's memory exhaustion. We figured that they had to be keeping the Apache processes running longer than necessary, and the connections were likely eating up memory themselves for buffers and other things that they need to operate. We made a code branch that added a shut down of the connections when the data was done being retrieved. We put that into production on Tuesday night about 9:30 and expected things to be fixed on Wednesday.

Well, things appeared to be fixed on Wednesday, or at least improved. As far as the CLOSE_WAIT connections were concerned we had orders of magnitude fewer. Instead of thousands we had about 70. We took another look at the code, though, and realized that we could get rid of even more by moving where the shut down happened.

As it turned out, we were missing those connections that didn't return any added content because there was none to retrieve. We made that change and restarted Apache. This change got us down to having only around 10 (and often less) of those broken connections.

Not too long after that, we got some reports of new errors with Evergreen. We took a closer look and realized we needed a "fix for the fix to the fix." We put that in place, restarted Apache again, and it was smooth sailing for the rest of the day.

As always, we shared these fixes with the community, and they have been added into the master branch and are in the 2.4.0 release.

We found out just before 9:00 am on Thursday morning, when the server ran out of memory, and all the swap was in use, that fixing the problem with open connections did not solve our actual problem. After rebooting the Evergreen server, we set about monitoring processes again with an eye out for anything interesting that turned up.

It tuns out that sorting the processes in top by the amount of memory they are using revealed a very interesting feature of our running Evergreen system. This showed an almost linear correlation between how much CPU time (i.e. how long it had run) an Apache had and the amount of memory it consumed. The highest consumers of memory on the system were those Apache processes that had been running the longest. This explained why restarting the Apache processes on the server would free up so much memory, and it gave us a hint at a mitigation strategy that would work.

We checked our Apache configuration and that revealed we were starting 150 listeners with a minimum spare servers of 50 and a maximum spare servers of 100. What we saw at startup was the 150 being started and 50 or so of them shutting down almost instantly. So, we adjusted the StartServers value down to 100. This should reduce process churn at start up time, and it makes sense to have the number of servers that you start set to one of your spare servers values.

We also saw that our Apache listeners were configured to handle 10,000 requests before shutting down (MaxRequestsPerChild). Since it looked like we could save our system by recycling or shutting down the long running Apache processes more frequently, we decided to lower this setting by an order of magnitude. We dropped it from 10,000 down to 1,000. This change would, in theory, cause the Apache processes to shut down long before they had managed to consume hundreds of megabytes of memory.

Monitoring of the system since making the changes has shown the above assumption to be correct. There are times when the Apache processes use more memory, but they seem to get shutdown before the situation gets out of hand. This, of course, does not actually fix the problem of the high memory use, but it does mitigate the effects and is relatively pain free. There is, after all, a slight increase in the load on the server as Apache processes are shut down and started more frequently, but that is still far less than the load spikes as the system runs out of memory and grinds to a screeching halt. Time will tell if this has really alleviated our situation, but so far "Signs point to yes."

I just finished chairing the organizing committee for the International Evergreen conference in Vancouver. It’s been more than a year of planning and a labour of love. From our own evaluation and from participant feedback we put on a really excellent conference. Now that I’m caught up on sleep here’s some of my thoughts.

Why this was an awesome organizing experience for me

• great community – the Evergreen community is awesome. People are kind, hardworking and have a DIY get ‘er done kinda attitude. I don’t write code, so can’t make that kind of contribution to the project, but I am good at event planning. While I’m sure I could organize an event for a group of people I didn’t know, it’s easier and more fulfilling to do this for a community of people I care deeply about. One of my first jobs out of library school was doing training and support for the Sitka Evergreen installation in BC. I learned a lot and this experience helped me get interesting library technology jobs. I feel grateful for the skills I built and to the people who mentored me. On a personal level it feels good to be able to contribute something back to the Evergreen community.
• great organizing team – This was the second conference that we’ve organized together. I have a lot of respect and admiration for these folks: Anita Cocchia (BCELN), Caroline Daniels (KPU), Mark Ellis (RPL), Mark Jordan (SFU), Paul Joseph (UBC) and Shirley Lew (VCC). While Ben Hyman (BC Libraries Coop) wasn’t on the organizing committee he did a stellar job of communicating with and buffering us from the Evergreen Oversight Board and the Software Freedom Conservancy. We all work hard and trust each other. I’ve learned a bunch of soft and hard skills from this group. I enjoyed our group dynamic and loved working together. We were comfortable asking questions and challenging each other. There were a bunch of times i felt like, as a group, we came up with a way better decision than any one of us as individuals would have.

Things that didn’t cost anything and added value

• We had an amazing team of volunteers who did live note taking as well as helping out stream the technical track. These folks were super enthusiastic and committed. The live notes are written documentation of the conference that makes it easier for everyone to write reports afterwards. One of the participants said “The team of note-takers was awesome.  It let me focus on how any given session could affect my work, without worrying that I’d miss something important as I chased down random thoughts.” For me they function as a quick summary of a video, and I’ll likely scan the notes of the sessions that I missed to figure out which videos I want to watch. Many thanks to Kimberly Garmoe, Eka Grguric, Mary Jinglewski, Jonathan Kift, Jonathan Schatz, and David Waddell.
• No-host lunches were a great way to get people outside the building to see a little bit of Vancouver. They also were a way to create a structured opportunity to socialise in small groups. From an organizing perspective it wasn’t a lot of work. We created a map of places that are nearby the venue with tasty food that can accommodate 8 people, found locals who were willing to lead the groups, and put out signup sheets (7 people plus a leader). We made sure we identified places for vegetarians and gluten free folks. According to participant feedback the no-host lunches were a big hit. Also, we had a really tight budget, so this allowed us to provide something for lunch without actually having to pay for it. We did this for the Access conference, but didn’t organize it enough and it was a bit chaotic. With a bit more forethought this time things went much more smoothly.

Live note taking and no-host lunches are ideas that can be adapted to any kind of conference or event, not just an open source library software event.

This was the first time that the conference proceedings were streamed. It was expensive to pay for AV for the main track, but I think is important and should be a requirement of future conferences. There were a total of 183 people watching the live stream from the United States, Canada, Czech Republic, Japan, Mexico, Finland and the UK. As Mark, Shirley and Ben from the BC Library Coop were willing to figure out a DIY streaming solution for the tech track, we were able to also do this for next to no money. It was awesome to hear from someone watching in Mexico (a CS Masters student who is implementing Evergreen for two university libraries) via Twitter. Thank you to Sam Mills for volunteering to edit the video from the main track and to Mark Jordan for getting it up on the Internet Archive.

Welcome Covington-Veedersburg Public Library!

Covington-Veedersburg Public Library in Fountain County, Indiana went live on Evergreen Indiana on April 30, 2013. With the addition of Covington-Veedersburg Public Library, Evergreen Indiana now serves a population of 981,929 Hoosiers statewide!

Contact information has been added to the Circulation Support Contact List and Shortnames List (previously referred to as Abbreviations) documents posted on the Staff Training Documents website.

Circulation Support Contact List

Member Library Shortnames

Evergreen Indiana Annual Meeting

Need to learn more about the Evergreen reports module? If you are thinking, “Doesn’t everyone?” consider attending the Evergreen Indiana Annual Meeting for the sessions below:

11:00-11:50 Session 2
• Weeding and collection turnover, putting Evergreen to work, Alexis Caudell, Mitchell Community Public Library

3:00-3:50 Session 3
• Explicit content: Getting what you want out of Evergreen reports with minimum (well, less) cursing, Jason Boyer, Jackson County Public Library

In order to get the most out of these short sessions, you will need to have a basic understanding of the reports module. Here are some resources available if you need a reports refresher:

• Basic reports documentation
• Self-paced WebJunction advanced reports training

Changes to Circulation Procedures

The circulation committee approved a small addition to the circulation procedures at their March 19, 2013 meeting. Please see the addition in bold and underlined below and at the following link:

• valid U.S. or other Government issued Identification (e.g., passport, military identification, permanent resident card issued by Department of Homeland Security or Immigration Services)

At Equinox, Technical Support for Koha and Evergreen is a core service. Providing quality support services is vitally important for our customers; it has an immense impact on their experience with the software, and further, affects how they perform their jobs and serve their patrons/students/customers.

Providing the highest quality support services is also vitally important for Equinox. Technical Support is our largest division. Even if an Equinox employee does not work directly in Support, they certainly play a role in supporting our support folks — from trainers to developers to sysadmins. Equinox Support is able to pull in whatever company resources they require to get the job done for the customer. It’s a company priority.

Equinox management constantly monitors Support’s performance via a customer satisfaction survey that is issued when a ticket is resolved. One of the survey ratings is an overall grade for how Equinox handled the incident. There are five grades to choose from: Excellent, Good, Average, Poor, and Very Poor. We have received over one hundred responses to the satisfaction survey so far this year, and without exception, every customer rated their experience as Excellent.

We have worked tirelessly to improve our support procedures and have the absolute best, most knowledgeable experts on staff. We’re awfully proud of our Support team. Congratulations, and keep it up!

If you’re a library looking for a support company for your ILS, give us a call.

Annual Conference

Has your library or staff been curious about the new Evergreen Indiana Holds class but not been able to attend one of the sessions offered at ISL or schedule one with your regional coordinator? Two sessions at the EI Annual Conference will discuss search strategy and holds in Evergreen with examples from member libraries!

10:00-10:50 Session 1
• Searching the Evergreen catalog (1 TLEU): Jill Stange, Indiana State Library & Carly Schull, Westfield Washington Public Library

3:00-3:50 Session 3
• Holds in Evergreen Indiana (1 TLEU): Shauna Borger, Indiana State Library

More information about sessions and presenters here!

Register for the Evergreen Indiana Annual Conference today!

Development Survey

Don’t miss your chance to weigh-in on prioritizing our development requests for the coming year! Fill out the survey below by Tuesday, April 30.

https://www.surveymonkey.com/s/EvergreenDevelopments

Upcoming Events

Friday, April 26 – Tuesday, April 30
• Modified cataloging freeze in place.

Monday, April 29
• Spring 2013 Cataloging Webinar. Register here!

Tuesday, April 30
• Covington-Veedersburg Public Library joins the consortium as the 102nd member!
• Development survey closes.

Friday, May 3
• Executive Committee ballots due!

Back in November the Evergreen community was discussing the desire for a mobile catalogue, and expressed a strong opinion that the right way forward would be to teach the current catalogue to be mobile-friendly by applying principles of responsive design. In fact, I stated:

Almost all of this can be achieved via CSS, possibly with some changes to the underlying HTML (e.g. tables to divs or whatever so that "Place Hold" appears under the bib info instead of way over to the right).

I have this bad habit of talking more than doing. So when I saw the Beanstalk mobile catalogue resurrected again at the Evergreen 2013 lightning talks, it bugged me that I still hadn't put any effort into a proof of concept of what was possible with CSS media queries. Thus, today, on the last day of my holidays, I spent a few hours trying things out on our development server and came up with this rough branch to work towards making the exact same HTML that we serve up for desktops provide an experience similar to that of the Beanstalk generation of catalogues for mobile, just via CSS.

As you can see from the commits, I made one change to the HTML to define a viewport, and added one set of CSS rules wrapped in a media query; in essence:

...
<head>
...
<meta content="initial-scale=1.0,width=device-width" name="viewport">
<style>
@media only screen and (max-width: 600px) {
    #header {
        padding: 0px;
        margin: 0px;
    }
    .facet_sidebar {
        display: none;
    }
    ...
}
</style>
<head>
...

Results and trade-offs

Here are a few example URLs from our test server (which is slow, and might get wiped any day, so test them quickly if you have a mobile device around!):

• Search results - sacrificed facets, per-item actions, and the language picker
• Record details - sacrificed per-item actions, flattened the item table vertically

In general, I removed a lot of the frippery from the header, while trying to retain the most valuable pieces. However, some bits are broken: Another Search doesn't actually let you do another search because the search bar is totally hidden. Other bits haven't been touched (Advanced search is still overwhelming, and My Account, while functional, could be much prettier.

What I've done so far is oriented towards our 2.3-ish lightly customized Laurentian skin (we force full details in search results, for example) but the principles should be applicable to an out-of-the-box Evergreen catalogue. In working through some of the challenges, I've determined that I was pretty much on target back in November; with a few HTML tweaks that would improve the layout for desktops as well, we could keep the per-item actions and facets around, but just move them to a different location.

Less talk, more action

So who's with me? What we have to gain is a single set of HTML to support for TPAC, and a single set of CSS, all available from the same URL, rather than trying to maintain overlays and monkeying about with mobile-vs-desktop URLs and the like. Feel free to dig in and start pushing branches with improvements over my rough attempts and let's make this thing happen for Evergreen 2.5.

With thanks to Firefox...

I would be remiss if I did not mention the marvellous Responsive Design View introduced in Firefox 15, along with the Style Editor; together, these tools (built into Firefox) made my developing and testing work so much easier.

If you want to live on the cutting edge of Firefox, you want Aurora - go and get it

Evergreen Indiana Annual Meeting

Registration is now available for the Evergreen Indiana Annual Conference in Indianapolis, Indiana on Thursday, May 9. We have a wonderful slate of programs and presenters including hot topics such as reports, patron record management, searching and holds. There is even an Evergreen Jeopardy session during which you will have the opportunity to win bookmarks, t-shirts, chocolate and more!

• Where: Caribbean Cove and Conference Center (3850 DePauw Blv., Indianapolis, IN)
• When: Thursday, May 9. Registration opens at 8am. Conference begins at 9am.
• Registration: $35 per person which includes breakfast, lunch and an afternoon snack. Checks can be made out to the Indiana State Library and mailed to the Indiana State Library, Business Office, presented on the day of the conference or mailed up to 30 days after the conference. Please email the Evergreen Indiana Coordinator (sborger@library.in.gov) if you require an invoice for payment.

Register for the Evergreen Indiana Annual Conference here!

Program of Events available here!

UPDATED Evergreen Indiana Executive Committee ballot

It’s election time for the Executive Committee! One ballot from each member library should be mailed back to ISL by Friday, May 3, 2013.

IMPORTANT NOTE: Brian Dawson and Sam Mitchell were labeled incorrectly in the previous ballot sent out in early April. Brian Dawson at Spencer County Public Library is a Class C nominee and Sam Mitchell at Hamilton North Public Library is a Class B nominee.

Please fill out a new ballot if you had chosen either one of those candidates in their incorrect public library class.

Thank you to all candidates on the ballot!

1. Class A nominees (July 1, 2013 – June 30, 2016)

Choose one:
• Kyle Qurazzo, Computer Services Technician, Shelby County Public Library

2. Class B nominees (July 1, 2013 – June 30, 2016)

Choose one:
• Jonathan Gaskell, Director Fulton County Public Library
• Mary Hartman, Director Peabody Public Library
• Scott Tracey, Computer and Reference Assistant, West Lafayette Public Library
• Sam Mitchel, Director Hamilton North Public Library

3. Class C nominees (July 1, 2013 – June 30, 2016)

Choose one:
• Brian Dawson, Director of Technology, Spencer County Public Library
• Margi Bontrager, Director Greentown Public Library
• Ruth Frasur, Director Hagerstown Jefferson Township Public Library

Membership News

Covington Veedersburg Public Library in Covington, Indiana will be joining Evergreen Indiana on Tuesday, April 30. A modified cataloging freeze will be in place from Friday, April 26 (8PM) to Tuesday, April 30 (2PM). An announcement will be sent to the cataloging listserv as soon as it is okay to resume normal cataloging activities.

During a modified catalog freeze. . .

DO NOT import, edit, delete or create new bibliographic records.

DO attach holdings and edit holdings.

On behalf of the Evergreen contributors, the 2.3.x release maintainer (Bill Erickson), the 2.2.x release maintainer (Lebbeous Fogle-Weekley), and the 2.1.x release maintainer, (Dan Scott), we are pleased to announce the release of Evergreen 2.3.6, 2.2.8, and 2.1.6.

Links to downloads and documentation can be found at

http://evergreen-ils.org/downloads.php.

The 2.3.6 and 2.2.8 releases also contains bugfixes not related to security.

THESE RELEASES CONTAIN SECURITY UPDATES. We strongly recommend that you upgrade as soon as possible.

• The pcrud, cstore, and rstore services are susceptible to an SQL injection attack.  Any user can potentially make arbitrary SQL run on the Evergreen database.

More information about the security updates and other bugfixes can be found in the ChangeLogs:

• 2.3.6
• 2.2.8
• 2.1.6

If you don’t wish to upgrade Evergreen outright to the latest version, sites running 2.1, 2.2, or 2.3 releases today can get the benefit of the security updates by following these steps:

• Download the 2.1.6, 2.2.8, or 2.3.6 release tarball; whichever belongs to the release series you’re currently running.
• Extract the tarball.

Updating the C libs 

1. In the source directory, run ./configure --prefix=/openils --sysconf=/openils/conf && make to build the libraries
2. Install the chrpath tool (aptitude install chrpath on Debian / Ubuntu systems)
3. Run chrpath -d Open-ILS/src/c-apps/.libs/oils_cstore.so to enable the library to link to the appropriate location.
4. Copy your existing oils_cstore.so library to a safe location; for example, cp /openils/lib/oils_cstore.so /openils/oils_cstore.so.20121026
5. Copy your new oils_cstore.so library into place: cp Open-ILS/src/c-apps/.libs/oils_cstore.so /openils/lib/
6. VERY IMPORTANT: Repeat the preceding three steps substituting “pcrud” everywhere “cstore” was mentioned. Repeat them again substituting “rstore” everywhere “cstore” wass mentioned.
7. As the root user, run ldconfig to refresh your dynamic linking cache.

To perform the chrpath and copy actions, you can run the following commands as the root user:

for i in cstore pcrud rstore
  do chrpath -d Open-ILS/src/c-apps/.libs/oils_$i.so
  cp /openils/lib/oils_$i.so /openils/lib/oils_$i.so.20130417
  cp Open-ILS/src/c-apps/.libs/oils_$i.so /openils/lib/
done
ldconfig

Note that /openils/lib/oils_cstore.so is normally a symbolic link to oils_cstore.so.2.0.0. When applying this procedure, make sure that the final result has all versions of the file name oils_cstore.so[.*] pointing to the same shared object. The same layout is true for pcrud and rstore.

Finally, restart all Evergreen services and Apache.

Please also note that these hot-fix instructions assume that you have installed the previous security releases.  If you have not, you should instead follow the instructions in the previous security release announcement using the tarballs being released today, including installing the latest stable version of OpenSRF (2.1.2).

MassLNC invites developers and vendors to submit quotes for enhancements to Evergreen billing and handling of lost, long overdue & claims returned items. Project requirements are available at http://masslnc.cwmars.org/node/2762. Prospective vendors may submit quotes for one, all or any number of projects identified in the requirements.

MassLNC has posted repsonses to questions it received for the upcoming software performance evaluation. These questions and responses are available at http://masslnc.cwmars.org/node/2781. 

Proposals are due to MassLNC by 11:59 (EDT) Wednesday, April 24, 2013 and should be e-mailed to Kathy Lussier at klussier@masslnc.org.

In a nutshell: a mobile registration app for Evergreen (initially imagined for Android though an iOS version would be cool).  The features list includes a password screen to protect the app, and the dual ability to edit accounts on the fly.  To be clear this is not a project that SCLENDS or York County has decided to take up but I was asked to imagine what such an application could do.  I’m trying to balance the original inspiration with robust functionality but I have to admit, once you go this far it’s tempting to add features like checkin or checkout though that might also be over reaching.  I’m posting this purely in case anyone is interested.  Ultimately this is a pretty simple app and has a lot of overlap with web based solutions that others have already done.

Use cases that drove these decisions:  I manage circulation and outreach departments.  With circulation we have frequent issues with lines backing up because patron registration takes a long time compared to normal checkouts.  This is made worse by things like summer reading program hikes in activity.  We could send people elsewhere to register but they still need a lot of assistance and the layout of our building is ... well, designed for a different age of the world.  So, mobility is better but not crucial.  However, mobility is all-important for outreach.  My outreach staff go out to events like festivals, walk lines and the ability to deliver services like register patrons with a table and a mobile hotspot are extremely attractive.  Finally, I can buy a decent Android tablet event with a pen and security devices substantially less than a desktop and usb tablet.

Requirement: We have to be able to store signatures.  This is a hold up for many library boards and in fact would be nice in Evergreen itself (upon demand).  

Proposal: To do this we add a column to the actor.usr table called signature.  This would handle the storage of the actual signature.  Alternatively we could work around and use the photograph field but that would interfere with anyone who uses that field for that function.  We might be able to save either binary data of the image there or the array for a bitmap or a mathematical value of the signature curve.  (This part of the idea was inspired by a lightning talk at the conference which nicely paralleled a lot of my own thinking.)

So, let’s break this down by workflow and screen:

When I run the app the screen I am greeted with will depend upon if this is the first time I have run the app.  If it is, then the first screen I see upon initial load of the app is the password screen. The purpose of the password is to prevent patrons from accessing the settings screen when they are using the app and therefore potentially messing up any settings.  Thereafter when the app is loaded it will go to the logon screen.

First time you load the app:

Logon Screen, this is the default you see after the first time, the Settings Password Screen:

[image not loading]

Settings Screen:

After logging in a registration screen is loaded.  The settings can be accessed from there and other screens.  There are actually two registration screens - one simple self-registration screen where staffs still have to intervene to finalize the record and a more full featured one meant for staff mobility. 

Self-Registration Screen:

The self-registration screen is pretty straight forward but you will notice that it lacks a few critical things and makes some assumptions.  Required fields should be marked by some kind of symbol or background filled in color, which is based on what is required in the database.  Note that I’ve tried to make this reflect some core Evergreen conventions not be SCLENDS specific but I have moved away from the staff client registration screen in a few places where I think it makes more sense for this purpose.

● When the record goes into the actor.usr from here it will leave the password blank or make it the last four digits of their PIN number if you’ve set that option.  

● Juvenile is calculated based on birthdate.

● Parent/Guardian should only be set by staff so it’s missing.

● Internet Access level should only be set by staff so it’s missing.

● Profile Permission group should only be set by staff so it’s missing but it will default based on settings.

● Privilege Expiration date should only be set by staff so it’s missing but it will be default based on settings.

● Barred and collections exempt default to null, not set.

● Active defaults to FALSE, so that they have to have staff activate their account.

● Claimed return, claimed never checked out, alert message are all null on self registration.

● Hold behind the circ desk defaults to null.

● Valid address and statistical categories are for staff interface only.

 The planned workflow included that the patron would hit submit at the end of entering their information and a new screen would come up that would present the actor.usr id, entered name, phone number and email address.  When the submit button was hit it inserted a new actor.usr record that was automatically marked as invalid and without a barcode.  The password would be left blank.  The staff member would use the name, id, phone number or email address to access the patron record that has now been inserted into the database.  Based on library procedure they might go directly to the record via the user id or they might search based on name or email to find inclusion in a group or merging if it is a duplicate.  Since it is a self-registration some options are restricted from the app user.  The user name will be left blank until staff adds the barcode.  At that same time the password can be added along with a corrected patron profile group.

Then the staff member marks the account valid and adds a barcode to give the patron their barcode.  Using the options screen there is an option to set the machine to staff mode and there would be a barcode scanner to immediately attach a barcode and to override some default behaviors of the self-registration.

The staff registration screen is quite different and gives direct access to everything.  It is also used when editing a record:

Staff Registration/Editing Screen: 

---------------------------------------

As we mentioned during the developers’ update at the Evergreen Conference, for Evergreen 2.5 we will be reviving the roadmap.  The roadmap will serve as a list of major features that are expected to be released in 2.5.

Since 2.5 is due to be released in September, please add your feature to the roadmap only if you expect that it will be code-complete and publicly available for review by early August at the latest.

For now, the roadmap will live on the wiki at

http://evergreen-ils.org/dokuwiki/doku.php?id=faqs:evergreen_roadmap:2.5

Please add only features that you are committed to work on or that you are committed to funding very soon — the roadmap isn’t meant to be a wishlist or a way of seeking co-sponsorship for potential projects.

To request an account on the wiki, please email docs AT evergreen-ils.org.  Although the roadmap will be continually updated during the 2.5 release cycle, please consider May 1st as a deadline for the first cut.

The Evergreen 2013 conference has come and gone and we want to hear what you thought about the conference so we can help next year’s organizers in planning an even better conference experience for you. Tell us what you liked, disliked, best food and favourite made-in BC TV show. Thanks for participating in the conference and visiting our lovely city!

All the best, courtesy of your superstar Evergreen 2013 Organizing Committee:

• Tara Robertson (Chair), CILS
• Anita Cocchia, BCELN
• Caroline Daniels, KPU
• Mark Ellis, RPL
• Mark Jordan, SFU
• Paul Joseph, UBC
• Shirley Lew, VCC

Feel like getting Irish tonight? Need a pint or two of the best Guinness in Vancouver? Meet up with Sharon and Kevin in the hotel lobby at 6:45pm for an excursion to the best little Irish pub in Vancouver, the Irish Heather.

Follow along as we provide you access to all the tweets, streaming video and live notes on the Evergreen 2013 LIVE page. Enjoy.

Many thanks, one thousand in fact, to our generous door prize sponsors:

• Speck http://www.speckproducts.com/
• DAVIDsTEA http://www.davidstea.com/
• Capilano Suspension Bridge http://www.capbridge.com/
• Equinox software for copies of the Unshelved books
• BC Libraries Cooperative for copies of The Golden Spruce

Update 2013-04-18: Now with video of the presentation, thanks to the awesome #egcon2013 volunteers!

I've been attending the Evergreen 2013 Conference in beautiful Vancouver. This morning, I was honoured to be able to give a presentation on some of the work I've been doing on implementing linked data via schema.org in Evergreen. I think I did a good job of explaining the potential value of linked data and arguing for improving Evergreen's schema.org publishing ninja skills.

My slides, with a reasonable number of useful speaker notes to provide context, are available in LibreOffice format.[1]

In addition, the amazing organizers of the conference also streamed most[2] of the talk and the recording will be available on the conference web site in a week or two.

Footnotes

1. I felt pretty dirty not using HTML5 + RDFa Lite to actually mark the whole thing up; there was some question close to the time of the conference as to whether anything but PPT or perhaps PDF would be an acceptable format... a concern that was subsequently removed, but a little too late to be worthwhile changing course.
2. The room was standing-room only (well, sitting-on-the-floor-room only), and one of the organizers accidentally sat on and unplugged the Ethernet cable, so something like ten minutes were lost. Heh!

Registration Desk will be open at 4:30pm at the Welcome Reception tonight at Delta Suites, Manhattan Restaurant, 2nd floor. Reception starts at 5:30-7:00pm. See you tonight!

This feature is available in Evergreen version 2.4.

Summary

This feature enables you to hide specific org units from patron view in the OPAC. Org units that have not inherited this setting will display in patron-facing dropdowns.

To enable Org Unit Hiding in TPAC:

1) Click Admin → Local Administration → Library Settings Editor → Org Unit Hiding Depth. Note: This setting is inherited.

2) Enter a value of 0, 1, or 2 as appropriate. Values are described in the setting description. To view the setting description, click the Edit link in the first column on the Library Settings interface.

3) Click Update Setting.

Author: Sally Fortin, Athenaeum Educational Services

This feature is available in Evergreen version 2.4.

Abstract

MARC Import Remove Fields allows staff to configure MARC tags to be automatically removed from bibliographic records when they are imported into Evergreen. This feature allows specific MARC tags to be removed from records that are imported through three different interfaces:

• Cataloging → Import Record from Z39.50
• Cataloging → MARC Batch Import/Export
• Acquisitions → Load MARC Order Records

Table of Contents

• Create a MARC Import Remove Fields profile
• Import Options
• Permissions to use this Feature

Create a MARC Import Remove Fields profile

To create a MARC Import Remove Fields profile, go to Admin → Server Administration → MARC Import Remove Fields.

1. Click New Field Group.
2. Assign the Field Group a Label. This label will appear in the import interfaces.
3. Assign an Org Unit Owner.
4. Check the box next to Always Apply if you want Evergreen to apply this Remove Fields profile to all MARC records that are imported through the three affected interfaces. If you do not select Always Apply, staff will have the option to choose which Remove Fields profile to use when importing records.
5. Click Save.
6. The profile that you created will now appear in the list of MARC Import Remove Fields.
7. Click on the hyperlinked ID number. This will bring you into the Remove Fields profile to configure the MARC tags to be removed.
8. Click New Field.
9. In the Field, enter the MARC tag to be removed.
10. Click Save.
11. Add New Fields until you have configured all the tags needed for this profile.
12. Click Return to Groups to go back to the list of Remove Field profiles.

Import Options

The Label for each of the MARC Import Remove Fields profiles will appear on the three affected import screens. To select a profile, check the box next to the desired Label before importing the records.

Cataloging → Import Record from Z39.50

 

Cataloging → MARC Batch Import/Export

 

Acquisitions → Load MARC Order Records

 

Permissions to use this Feature

The following permissions are required to use this feature:

• CREATE_IMPORT_TRASH_FIELD
• UPDATE_IMPORT_TRASH_FIELD
• DELETE_IMPORT_TRASH_FIELD  

Author: Angela Kilsdonk, Equinox Software

This feature is available in Evergreen version 2.4.

Abstract

Best-Hold Selection Sort Order allows libraries to configure customized rules for Evergreen to use to select the best hold to fill at opportunistic capture. When a copy is captured for a hold upon check-in, Evergreen evaluates the holds in the system that the item could fill. Evergreen uses a set of rules, or a Best-Hold Selection Sort Order, to determine the best hold to fill with the item. In previous version of Evergreen, there were two sets of rules for Evergreen to use to determine the best hold to fulfill: Traditional and FIFO (First In, First Out). Traditional uses Org Unit Proximity to identify the nearest hold to fill. FIFO follows a strict order of first-in, first-out rules. This feature allows new, custom Best-Hold Selection Sort Orders to be created. Existing Best-Hold Selection Sort Orders can also be modified.

Table of Contents

• Preconfigured Best-Hold Orders
• Create a new Best-Hold Selection Sort Order
• Edit an existing Best-Hold Selection Sort Order
• Set your library’s Best-Hold Selection Sort Order
• Permissions to use this Feature

Preconfigured Best-Hold Orders

Evergreen comes with six preconfigured Best-Hold Selection Sort Orders to choose from:

• Traditional
• Traditional with Holds-go-home
• Traditional with Holds-always-go-home
• FIFO
• FIFO with Holds-go-home
• FIFO with Holds-always-go-home

The Holds-go-home and Holds-always-go-home options allow libraries to determine how long they want to allow items to transit outside of the item’s home library, before it must return to its home library to fulfill any holds that are to be picked up there. Libraries can set this time limit in the library setting Holds: Max foreign-circulation time. The Library Settings Editor can be found under Admin → Local Administration → Library Settings Editor.

Create a New Best-Hold Selection Sort Order

To create a new Best-Hold Selection Sort Order, go to Admin → Server Administration → Best-Hold Selection Sort Order.

1. Click Create New.
2. Assign your Best-Hold Selection Sort Order a Name.
3. Next, use the Move Up and Move Down buttons to arrange the fields in the order that you would like Evergreen to check when looking for the best hold to fill with a copy at opportunistic capture.
4. Click Save Changes to create your custom Best-Hold Selection Sort Order.

Edit an Existing Best-Hold Selection Sort Order

To edit an existing Best-Hold Selection Sort Order, go to Admin → Server Administration → Best-Hold Selection Sort Order.

1. Click Edit Existing.
2. Choose the Best-Hold Selection Sort Order that you would like to edit from the drop down menu.
3. Next, use the Move Up and Move Down buttons to arrange the fields in the new order that you would like Evergreen to check when looking for the best hold to fill with a copy at opportunistic capture.
4. Click Save Changes to save your edits.

Choosing the Best-Hold Selection Sort Order

The Best-Hold Selection Sort Order can be set for an Org Unit in the Library Settings Editor.

To select the Best-Hold Selection Sort Order that your Org Unit will use:

1. Go to Admin → Local Administration → Library Settings Editor.
2. Locate the setting Holds: Best-hold selection sort order, and click Edit.
3. Choose the Context org unit for this setting.
4. Select the Best-hold selection sort order, or Value, from the drop down menu.
5. Click Update Setting.

Permissions to use this Feature

To administer the custom Best-Hold Selection Sort Order interface, you need the following permission:

• ADMIN_HOLD_CAPTURE_SORT

Author: Angela Kilsdonk, Equinox Software

---

2.4 Org Unit Proximity Adustments

This feature is available in Evergreen version 2.4.

Org Unit Proximity Adjustments

Org Unit Proximity Adjustments allow libraries to indicate lending preferences for holds between libraries in an Evergreen consortium. When a hold is placed in Evergreen, the hold targeter looks for copies that can fill the hold. One factor that the hold targeter uses to choose the best copy to fill the hold is the distance, or proximity, between the capturing library and the pickup library for the request. The proximity is based on the number of steps through the org tree that it takes to get from one org unit to another.

Org Unit Proximity between BR1 and BR4 = 4

Org Unit Proximity Adjustments allow libraries to customize the distances between org units, which provides more control over which libraries are looked at when targeting copies to fill a hold. Evergreen can also be configured to take Org Unit Proximity Adjustments into account during opportunistic capture through the creation of a custom Best-Hold Selection Sort Order. See documentation here for more information on Best-Hold Selection Sort Order.

An Org Unit Proximity Adjustment can be created to tell Evergreen which libraries to look at first for copies to fill a hold or which library to look at last. This may be useful for accounting for true transit costs or physical distances between libraries. It can also be used to identify libraries that have special lending agreements or preferences. Org Unit Proximity Adjustments can be created for all holds between two org units, or they can be created for holds on specific Copy Locations and Circulation Modifiers.

Absolute and Relative Adjustments

Two types of proximity adjustments can be created in Evergreen: Absolute adjustments and Relative adjustments.

Absolute proximity adjustments allow you to replace the default proximity distance between two org units. An absolute adjustment could be made to tell the hold targeter to look at a specific library or library system first to find an item to fill a hold, before looking elsewhere in the consortium.

Relative proximity adjustments allows the proximity between org units to be treated as closer or farther from one another than the default distance. A relative proximity adjustment could be used to identify a library that has limited hours or slow transit times to tell the hold targeter to look at that library last for copies to fill a hold.

Create an Org Unit Proximity Adjustment

To create an Org Unit Proximity Adjustment between two libraries:

1. In the Admin menu choose Server Administration → Org Unit Proximity Adjustments.
2. Click New OU Proximity Adjustment.
3. Choose an Item Circ Lib from the drop down menu.
4. Choose a Hold Request Lib from the drop down menu.
5. If this proximity adjustment applies to a specific copy location, select the appropriate Copy Location from the drop down menu.
6. If this proximity adjustment applies to a specific material type, select the appropriate Circ Modifier from the drop down menu.
7. If this is an Absolute proximity adjustment, check the box next to Absolute adjustment? If you leave the box blank, a relative proximity adjustment will be applied.
8. Enter the Proximity Adjustment between the Item Circulating Library and the Request Library.
9. Click Save.

This will create a one-way proximity adjustment between Org Units. In this example this adjustment will apply to items requested at by a patron BR4 and filled at BR1. To create the reciprocal proximity adjustment, for items requested at BR1 and filled at BR4, create a second proximity adjustment between the two Org Units.

Permissions to use this Feature

To create Org Unit Proximity Adjustments, you will need the following permission:

• ADMIN_PROXIMITY_ADJUSTMENT

Author: Angela Kilsdonk, Equinox Software

This feature is available in Evergreen version 2.4.

In Evergreen version 2.4, when a title is added to a list in the TPAC, a local call number will be displayed in the list to assist patrons in locating the physical item. Evergreen will look at the following locations to identify the most relevant call number to display in the list:

1. Physical location – the physical library location where the search takes place
2. Preferred library – the Preferred Search Location, which is set in patron OPAC account Search and History Preferences, or the patron’s Home Library
3. Search library – the search library or org unit that is selected in the OPAC search interface

The call number that is displayed will be the most relevant call number to the searcher. If the patron is searching at the library, Evergreen will display a call number from that library location. If the patron is not searching at a library, but is logged in to their OPAC account, Evergreen will display a call number from their Home Library or Preferred Search Location. If the patron is not searching at the library and is not signed in to their OPAC account, then Evergreen will display a call number from the org unit, or library, that they choose to search in the OPAC search interface.

The local call number and associated library location will appear in the list:

Author: Angela Kilsdonk, Equinox Software

2.5 Evergreen Integration with PV Supa GoodStuff RFID Reader

This feature is available in Evergreen version 2.5.

Summary

This feature enables the Evergreen staff client to “talk” to the PV Supa Goodstuff RFID reader so that libraries can utilize PV Supa Goodstuff’s RFID technology when checking items in and out.

Administration

To use PV Supa Goodstuff, you must add code to the Admin module that Evergreen can use to identify the reader.

1) Click Admin → Workstation Admin → Server Add-ons.

2) Enter the code, pv_supa_goodstuff, to identify PV Supa Goodstuff in the Active Server Add-Ons field.

3) Click Update Active Add-Ons.

4) Look at the next field, Add-on Preferences. Enter information in the GoodStuff tab.

5) Check the Enabled check box to enable this add-on.

6) Enter the IP/Hostname of the hardware.

7) Enter the port.

8) Click Update.

Using RFID at the Circulation Desk

RFID functionality is available in the Circulation module via the check-out interface, the check-out function in the patron account, and the check-in interface.

From the Check-Out interface (F1):

1) Check the RFID checkbox if your library cards have embedded RFID chips that Evergreen can use to retrieve the patron barcode. RFID check boxes appear only if appropriate code words have been added in the Server Add-Ons.

2) Place the patron’s library card and/or item(s) on the PV Supa Goodstuff Reader. Evergreen will take you to the patron’s account. If item(s) with RFID chips have also been placed on the reader, and the corresponding checkbox is checked, then Evergreen will scan the item(s) into the patron’s account.

Note	RFID check boxes are sticky, so if you have checked an RFID box once, then it will continue to be checked when you re-open the interface.

Note

If you do not use RFID chips to retrieve patrons’ accounts, then leave the RFID box unchecked. You can scan a patron barcode with a barcode scanner, and Evergreen will retrieve the patron data without using the RFID feature. From the patron’s account, Evergreen can check out items using the RFID reader. See the next section for details.

3) Click Done to complete the transaction, or close the window.

From the Check-Out tab in a patron’s record:

1) Open a patron’s record, and stack the item(s) to be checked out on the RFID reader. To retrieve item data using the RFID chips embedded in the item barcodes, click the RFID check box at the bottom of the patron account. When this box is checked, Evergreen will read the item(s) that are stacked on the RFID reader, check out the item(s), and disable the security bits.

2) Click Done to complete the transaction, or close the window.

Note

Evergreen pop-up messages, such as an Alert Message or Item Already Circulating may appear during transactions. Two new dialogs specific to PV Supa Goodstuff may also appear. One dialog, Incomplete Sets, allows you to continue checking out an incomplete set, such as a CD collection, or you can ask the hardware to rescan the RFID tags to look again for a full set. The second dialog allows you to manually attempt to set or unset the security bit on an item if the automatic attempt failed.

From the Check In interface:

1) Click the RFID check box.

2) Place the items on the PV Supa Goodstuff Reader.

3) Evergreen will tell the reader to check in the item(s) and enable the security bits. The item(s) appear in a list on the screen.

Author: Sally Fortin, Athenaeum Educational Services

The next few days promise to be busy.  Tuesday morning, my first stop is Sea-Tac to pick up a couple other conference attendees who are flying in from the East Coast.  After a stop for lunch, it’s a straight shot up I-5 and BC-99 to Vancouver.

Wednesday morning I’ll be bouncing around among the IG and committee meetings, and making a particular point of joining the Web Team and the Cataloging Working Group meetings.  I plan to spend most of the afternoon at the hackfest.

Thursday looks to be mostly sessions, but you may also find me distributing Evergreen t-shirts.

On Friday, I’ll be part of two presentations.  At noon, I’ll be talking about data quality and Evergreen, and at 2:30 I’ll be joining Rogan Hamby and Robin Johnson to talk about how networking affects Evergreen.

Saturday Friday morning I’ll be joining the other members of the Evergreen Oversight Board (and, I hope, other interested community members!) for our business meeting.  Later Saturday morning the Oversight Board will give an update to the conference.

And other than that?  I’m looking forward to attending the keynotes and catching some sessions.  But most of all, I’m looking forward to seeing friends old and new.

Update 9 April 2013: The Evergreen Oversight Board meeting was rescheduled to 8 a.m. on Friday.

We’re excited to see you in Vancouver for Evergreen 2013. Here’s some last minute details about the conference:

Getting from the airport to the hotel

We’ve updated the website to include local travel info.

The easiest way into town is the Canada Line, it’s quick (30 minutes) and cheap ($7.75-$8.75 depending on the time of day).

Frugal tip: Read more about buying a book of 10 fare saver tickets on Trip Advisor.

Also: the airport is beautiful.

No host lunches

On Thursday we’ve picked a bunch of places to go for lunch and have local volunteers to lead groups. If you are the type of person who likes to plan ahead, take a look at the Thursday Lunch Map.

UrbanSpoon – filter to Downtown and/or Gastown neighbourhoods, and Yelp are good places to check for reviews for places to eat and drink. Fans of microbrew should definately check out The Alibi Room.

Twitter

Shirley and I will be on the @egcon2013 Twitter account, so let us know if you have any questions about Vancouver let us know.

Safe travels!

Tara and the Evergreen 2013 Organizing Committee

Does your project, service, or product interact with Evergreen in some automated fashion?  If so, we’d like to hear from you.

I’m using the phrase “automated fashion” very broadly.  There are many ways to receive data from an Evergreen system, update data in an Evergreen database, or make transactions happen.  A few of these ways include:

• XML-RPC calls to invoke Evergreen service methods
• SIP2 to perform patron and circulation requests
• Z39.50, unAPI, and OpenSearch to retrieve catalog data
• MARC exports and imports
• Screen-scraping (although if you’re screen-scraping Evergreen, we may be able to suggest a better way to do it)
• Interacting with the Evergreen staff client
• Direct database access
• And others

Some of the things we’d like to know include:

• The name of your service or product
• What it does for an Evergreen library
• How it is accessing Evergreen
• Whether there are specific APIs or entry points that your application depends on
• If there are things that Evergreen could be doing to make your life easier

We want to hear from everybody, whether you are a consortium that has integrated Evergreen with other software, an Evergreen support group,  a vendor providing products or services to libraries, or a member of a free software project whose software talks with Evergreen.  If you work for an Evergreen library and know that Evergreen works with another service, we want to hear from you too, even if you don’t know how Evergreen is doing the talking.

Why do we want to know?  Our reasons include:

• Finding out which entry points we should be particularly careful about changing as Evergreen gets enhanced.
• See if there are things we could be doing better to encourage more people and applications to participate in the Evergreen ecosystem.
• (Maybe) putting together a list of third-party services that interact with Evergreen.

To respond, please comment on this post.

Evergreen Indiana Development Survey

The current project development queue for Evergreen Indiana includes the payment pilot and the mobile OPAC. In an attempt to establish a formal process to solicit and prioritize other development requests that have come from the community, ISL and the Executive Committee have created the survey below. We invite all staff members in the Evergreen Indiana community to fill out the survey and provide feedback by Tuesday, April 30. The results will be discussed at the Evergreen Indiana Annual Meeting on May 9, 2013 and announced in the Weekly Update blog.

Thank you for your continued support, cooperation and feedback!

https://www.surveymonkey.com/s/EvergreenDevelopments

Meetings

Executive Committee meets on Tuesday, April 9 @ Hussey Mayfield Memorial Public Library.

• Draft agenda

Upcoming classes

2013 Spring EI Cataloging Roundtable – RDA

• Register here!

The Massachusetts Library Network (MassLNC) is seeking a consultant or multiple consultants to perform a software performance evaluation of the Evergreen Integrated Library System. The full project description is available at http://masslnc.cwmars.org/sites/masslnc.cwmars.org/files/Evergreen software performance review final.pdf.

As Evergreen is built with PostgreSQL at the core, the following PostgreSQL news announcement should be of concern to Evergreen administrators:

Upcoming PostgreSQL Security Release: April 4, 2013
Posted on 2013-03-28

The PostgreSQL Global Development Group will be releasing a security update for all supported versions on Thursday April 4th, 2013. This release will include a fix for a high-exposure security vulnerability. All users are strongly urged to apply the update as soon as it is available.

We are providing this advance notice so that users may schedule an update of their production systems on or shortly after April 4th.

As always, update releases only require installation of packages and a database system restart. You do not need to dump/restore or use pg_upgrade for this update release.

Please be prepared to update to the security release. While a typical Evergreen configuration does not expose PostgreSQL to public access, the nature of this announcement is unusual for PostgreSQL and suggests that the vulnerability may be particularly concerning.

Evergreen 2013 in Vancouver is sold out!!! Thanks to the community for all your interest and support. More announcements coming soon.

Changes to Evergreen Indiana Membership By-Laws

In an effort to streamline and invigorate committee participation, several changes to the By-Laws have been proposed by the Executive Committee and will be voted on at the membership meeting on May 9.

• Evergreen Indiana Membership By-Laws with proposed edits

Page 4: The Indiana State and Historical Board has adopted a policy to allow electronic participation in meetings. As such, the Evergreen Indiana Executive Committee and interested subcommittees have proposed an addition of these guidelines to the by-laws.

Page 5: The Circulation and OPAC Committees have had an extensive overlap in discussion and action points in the past and it has been suggested that the two committees combine to create the Patron Services Committee. Also, the OverDrive Committee is being renamed to the eContent Committee so that the focus of the committee is open to any and all consortium-wide eContent opportunities and discounts, such as our recent opportunity with Freegal.

As always, feedback on the proposed changes may be directed to a member of any of the committees, a regional coordinator or the Evergreen Indiana Coordinator (sborger@library.in.gov)!

Evergreen eContent listserv

In order to provide better communication and support among our member libraries who are participating in some of the eContent consortium opportunities, such as OverDrive and Freegal, the OverDrive (soon to be eContent) Committee has created a listserv to which interested parties may subscribe. This has been added to the list of member listservs on the Member Resources website (bottom of page).

To subscribe, please send an email to evergreen_econtent@lists.in.gov.

Hi all,

Evergreen 2.2.7 has been released.  This release contains a number of bugfixes since the last release back in February.  See this page for links to the source code, staff client, release notes, changelog and more.

The bugfixes covered in this release address (in no particular order) SIP interoperability; added content from Syndetics; user interface issues in the staff client, the OPAC, and the staff translations interface; TCN maintenance; serials; patron retrieval by inactive barcode; hold shelf; authorities management; Z39.50 searches; MARC export; the XML-RPC API; and dependencies for installing Evergreen on the most recent Long-Term Support release of Ubuntu.

Thanks as always to all the contributors of the Evergreen community!

Spring 2013 Circulation Class – Billing in Evergreen

Thank you to those who hosted and attended the Spring 2013 Circulation Class – Billing in Evergreen last week. For those who missed the live webinar, the recording can be found on the Staff Training Documents website, along with the presentation and a link at the end of the presentation to a survey monkey quiz staff will need to complete and submit in order to receive 1 TLEU.

NOTE: A detailed description of the payment pilot begins at about 29 minutes into the recording. We hope to expand the payment pilot to include all libraries in late 2013 so it’s a good idea to become familiar with it now!

Spring 2013 Circulation Class – Billing in Evergreen

Presentation and quiz for LEU

New library joining!

Covington-Veedersburg Public Library in Fountain County will be joining Evergreen on Tuesday, April 30. Modified cataloging freeze will begin on Saturday, April 27 (beginning of business day) – Tuesday, April 30 (late afternoon). An announcement will be sent to the listservs as soon as it is okay to resume normal cataloging activities.

During a modified catalog freeze. . .

DO NOT import, edit, delete or create new bibliographic records.
DO attach holdings and edit holdings.

Circulation Support and Abbreviation lists

Peru Public Library contact information has been added to the Evergreen Indiana Circulation Support Contact List and Library Abbreviation lists which are available on the Staff Training Documents website > Circulation Module:

Circulation Support Contact List
Abbreviation List

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.

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.

The first (and likely only, barring major bugs) beta release of Evergreen 2.4 is now available for download and testing.  This marks the official feature-freeze point for the 2.4 series of Evergreen.  Notable features include:

• Significant TPAC enhancements
• Streamlined and enhanced Acquisitions functionality
• Expanded options for the configuration of Holds and Circulations

The full set of upcoming features are listed in the release notes, and the complete list  of source code changes since the release of 2.3 is available in the git change log.

The OpenSRF 2.2.0 or later is recommended for use with Evergreen 2.4.  OpenSRF 2.2 is in alpha now, with release expected at approximately the same time as Evergreen 2.4.0.  All testers of the Evergreen 2.4 beta are encouraged to test with OpenSRF 2.2.0, as there are significant performance enhancements and bug fixes associated with Evergreen’s new features.

Thanks to all who helped make this release possible.

OpenSRF 2.2.0-alpha is now available for download and testing.  This is a relatively small enhancement and bugfix release, and includes the following major changes:

1. Support for Apache 2.4, Debian Wheezy, and Fedora 18.
2. Elimination of CPU spikes caused by use of the MultiSession module.  This is particularly relevant for Evergreen as TPac uses MultiSession when fetching bib records for display in search results.
3. Support for graceful reload of Perl services via SIGHUP, which allows the log level to be changed on the fly.  This can also be used to politely clean up after memory leaks.

For a complete list of the changes, please consult the release notes and change log.

Links to the installation tarball, release notes, and installation instructions can be found on the OpenSRF downloads page.

We are considering having 2.2.0 be the recommended OpenSRF version for Evergreen 2.4.  Consequently, testers of the Evergreen 2.4 beta are encouraged to test the OpenSRF alpha as well.  In addition, because of the changes to MultiSession, we are particularly interested in test results from a variety of platforms, particularly ones that use virtualization.

Upgrading

We’d like to begin talking about a plan for upgrading to the next version of Evergreen. As suggested by the Executive Committee, we are looking at weekends in August for our upgrade window. We propose to upgrade on Friday, August 9 to Sunday, August 11. More details will be forthcoming.

Also, with regards to getting staff prepared, ISL will be making a test server available in the coming months with the version of Evergreen to which we will be upgrading. At that time, ISL staff and our committees will organize learning opportunities (webinars, onsite demos, presentations, etc.) to get staff ready for the new version.

Evergreen Indiana Annual Meeting – Save the Date

The Evergreen Indiana Annual Meeting will be held on Thursday, May 9 in central Indiana (location: tbd). Cost is also TBD but registration should be available on the WebJunction Calendar soon!

Draft schedule:

8-9am Registration

9:30-10am Welcome

10-10:50 1st Sessions

a. Evergreen self-check users tell all – Scott Tracey, West Lafayette Public Library

b. RDA and You: How RDA will affect non-catalogers – Sarah Childs, Hussey-Mayfield Memorial Public Library

c. Searching the Evergreen catalog – Jill Stange, Indiana State Library

11-11:50 2nd Sessions

a. Updates and new features in the eIndiana Digital OverDrive Consortium – Montie Manning, Alexandria-Monroe Public Library

b. Cleaning up the patron database – Shauna Borger, Indiana State Library

c. Dealing with difficult patrons and enforcing Evergreen policy – Bill Anderson, Indiana State Library

12-1pm Lunch and business meeting

1-1:50pm Evergreen Jeopardy – Test your Evergreen knowledge! – Hosted by ISL staff and Ray Rainier, Peabody Public Library

2-2:50pm Subcommittee meetings / Presentation by the attendees of the 2013 Evergreen International Conference

3-3:50pm 3rd Sessions

a. Explicit Content: Getting what you want out of Evergreen Reports with minimum (well, less) cursing – Jason Boyer, Jackson County Public Library

b. Holds in Evergreen – Shauna Borger, Indiana State Library

c. Weeding and collection turnover, putting Evergreen to work – Alexis Caudell, Mitchell Community Public Library

Trainings

Advanced Cataloging trainings have been scheduled for the end of the month.

Part 1, Tuesday, March 26
Part 2, Wednesday, March 27

Meetings

Circulation Committee is meeting on Tuesday, March 19.
• Draft agenda

Both Koha and Evergreen use memcached to cache user sessions and data that would be expensive to continually fetch and refetch from the database. For example, Koha uses memcached to cache MARC frameworks, while Evergreen caches search results, bibliographic added content, search suggestions, and other data.

Even though the data that gets cached is transitory, at times it can be useful to look at it. For example, you may need to check to see if some stale data is present in the cache, or you may want to capture some statistics about user sessions that would otherwise be lost when the cache expires.

The library libMemcached include several command-line utilities for interrogating a memcached server. We’ll look at memcdump and memccat.

memcdump prints a list of keys that are (or were, since the data may have expired) stored in a memcached server. Here’s an example of the sorts of keys you might see in an Evergreen system:

memcdump --servers 127.0.0.1:11211
oils_AS_21a5dc5cd2aa42ee7c0ecc239dcb25b5
ac.toc.html.0531301990
open-ils.search_9fd0c6c3553e6979fc63aa634a78b362_facets
open-ils.search_9fd0c6c3553e6979fc63aa634a78b362
oils_auth_8682b1017b7b27035576fecbfc7715c4

The --servers 127.0.0.1:11211 bit tells memcdump to check memcached running on the local server.

A list of keys, however, doesn’t tell you much. To see the value that’s stored under that key, use memccat. Here’s an example of looking at a user session record in Koha (assuming you’ve set the SessionStorage system preference to use memcached):

memccat --servers 127.0.0.1:11211 KOHA78c879b9942dee326710ce8e046acede
---
_SESSION_ATIME: '1363060711'
_SESSION_CTIME: '1363060711'
_SESSION_ID: 78c879b9942dee326710ce8e046acede
_SESSION_REMOTE_ADDR: 192.168.1.16
branch: CPL
branchname: Centerville
cardnumber: cat
emailaddress: ''
firstname: ''
flags: 1
id: cat
ip: 192.168.1.16
lasttime: '1363060711'
number: 51
surname: cat

And here’s an example of an Evergreen user session cached object:

memccat --servers 127.0.0.1:11211 oils_auth_8682b1017b7b27035576fecbfc7715c4
{"authtime":420,"userobj":{"__c":"au","__p":[null,null,null,null,null,null,null,null,null,"186",null,"t",null,"f",119284,38997,0,0,"2011-05-31T11:17:16-0400","0.00","1-888-555-1234","1923-01-01T00:00:00-0500","user@example.org",null,"2015-10-29T00:00:00-0400","User","Test",186,654440,3,null,null,null,"1358890660.7173220299.6945940294",119284,"f",1,null,"",null,null,10,null,1,null,"t",654440,"user",null,"f","2013-01-22T16:37:40-0500",null,"f"]}}

We’ll let the YAMLites and JSONistas square off outside, and take a look at a final example. This is an excerpt a cached catalog search result in Evergreen:

memccat --servers 127.0.0.1:11211 open-ils.search_4b81a8a59544e8c7e9fdcda357d7b05f
{"0":{"summary":{"checked":630,"visible":"546","excluded":84,"deleted":0,"total":630,"complex_query":1},"results":[["74093"],["130197"], ...., ["880940"],["574457"]]}}

There are other tools that let you manipulate the cache, including memcrm to remove keys and memccp to load key/value pairs into memcached.

For a complete list of the command-line tools provided by libMemcached, check out its documentation. To install them on Debian or Ubuntu, run apt-get install libmemcached-tools. Note that the Debian package renames the tools from ‘memdump’ to ‘memcdump’, ‘memcat’ to ‘memccat’, etc., to avoid a naming conflict with another package.

A very important factor in getting good performance from your Evergreen system, particularly catalog searches, is making sure that your database server’s filesystem cache is hot. In particular, if the PostgreSQL files that make up the indexes on tables in the metabib schema are already cached in memory, the database won’t have to go to disk to scan them. This is nice even if you uses solid-state drives, as RAM is still faster than SSDs.

Back in 2008, Dan Scott described a way to heat up the cache. If your database is small enough (or your server is big enough) that the whole thing can fit in memory, heating up the cache can be as simple as:

cd /var/lib/postgresql/9.1/main/base/
cat * > /dev/null

If you don’t have nearly that much RAM, you can use queries on the pg_class table to figure out the filenames of the indexes and tables you want to cache.

Time marches on, however, and I’m happy to see that there’s a patch by Robert Haas working its way through the PostgreSQL review process that will introduce a function called pg_prewarm. This function lets you pull a relation into the OS cache by name.

For example, to load all indexes on the metabib.keyword_field_entry table into the OS cache, you could run:

SELECT pg_prewarm(schemaname || '.' || indexname,
                  'main',
                  'prefetch',
                  NULL, NULL)
FROM pg_indexes
WHERE schemaname = 'metabib'
AND   tablename = 'keyword_field_entry';

Some nice things about this include:

1. It encourages virtuous laziness by combining a query specifying the relations to cache with the act of caching them.
2. It makes it easy for a DBA to warm the cache without requiring shell access to the database server.
3. If your server has limited RAM, it gives you more control. For example, you could write cronjobs that cache the tables used for hold re-targeting at night, then cache the indexes used for catalog search in the morning after the hold targeter has finished.

With any luck, pg_prewarm will show up as a contrib in 9.3, but for the adventurous, the current version of the patch can be found attached to this post on psql-hackers. This blog post by Raghavendra includes a nice step-by-step guide for installing it.

<style> code { font-weight: bold; color: darkblue; } pre { color: darkgreen; font-weight: bold; } </style>

Cap fines at item price setting

The Executive Committee recently approved a setting which staff will see live in the system on Thursday, March 7. The “Cap Overdue Fines at Item Price” setting will cap overdue fees at the cost of the item IF the item costs less than $10. Lost and damaged fees are not affected by this setting.

Example 1: Item cost is entered as $5.00. Item is 40 days overdue. With the Cap Overdue Fines at Item Price setting turned on, the overdue fees associated with that item will cap at $5.00.

Example 2: Item cost has not been entered so the default cost will be $10.00. Item is 40 days overdue. The overdue fees associated with the item will cap at $10.00 (as has always been the case).

Hold Notifications Updates

As was requested by the Circulation Committee, the email notification for patrons has been updated to include our hold pickup policy and that some libraries charge a fine for not picking up holds.

“The item you requested is available for pickup from the Library. Please pick up the item within 7 days. A fee may be assessed if you do not pick up your item within 7 days.

Contact the Circulation Desk to check out the item.”

The phone hold notification will soon repeat the library name at the end of the message so that if the message gets cut off at the beginning, patrons will have a second opportunity to hear the library name.

Order item barcodes and library cards

Just a reminder that you may place item and patron barcode orders beginning Monday, March 4 until Friday, March 8. The library will contact Creative DataProducts directly to place their order. Eventually, the vendor hopes to have an online ordering system but currently you will need to contact Amanda Marcengill at Creative DataProducts via email (amarcengill@creativedataproducts.com) or telephone (864-662-1310) with the following information:

• Item barcodes or patron library cards? If patron library cards, green or blue?
• Quantity (There is a minimum order of 500 for both item barcodes and patron library cards).
• Beginning barcode number.
• Library name, contact email and telephone number.

Meetings

Cataloging Committee will be meeting on Wednesday, March 5, 10AM at Hussey Mayfield Memorial Public Library.

• Draft Agenda

Many teeth were gnashed and garments rent, but (as of last Friday) there is now available, for your downloading pleasure, the first alpha release of Evergreen 2.4.  The web site will be updated shortly, and when it is you will see a new column for 2.4 on the downloads page at http://evergreen-ils.org/<wbr></wbr>downloads.php.

In the mean time the important files can be had from the following locations:

 

Thanks to everyone who has worked on this release.  There is a lot of great stuff in here.

Thanks also go specifically to Ben Shum, who put together an alpha version of the 2.4 release notes.  I’m not incorporating it into the alpha branch, since features are still being added until beta, but if you want to see what is in the alpha1 cut (and has had at least some simple release notes treatment) you can find that at: http://git.evergreen-ils.<wbr></wbr>org/?p=working/Evergreen.git;<wbr></wbr>a=blob_plain;f=docs/RELEASE_<wbr></wbr>NOTES_2_4.txt;hb=<wbr></wbr>9abccb6caaff8d7f93b1f55b773266<wbr></wbr>9bb6aaefd2

Welcome Peru Public Library!

Please join me in welcoming Peru Public Library (Miami County) as our 101st member! We are now serving 975,246 library patrons across the state of Indiana! Check ISL’s facebook page for photos of migration day at Peru Public Library!

New Members for Executive Committee

The Evergreen Indiana Executive Committee is looking for new members. The Executive Committee is responsible for reviewing and enforcing policy and EC members are expected to take on a leadership and mentoring role in the EI community. EC members meet every other month in central Indiana and time commitment usually does not exceed 30 hours annually. Membership terms are three years (July 2013-July 2016) and one representative from Class A, B and C each will be chosen.

If you are interested in serving, please contact Nick Schenkel (nick@wlaf.lib.in.us) and Montie Manning (mmanning@alex.lib.in.us).

Upcoming Training Opportunities

• Tuesday, March 12: Spring 2013 Evergreen Circulation Class (WEBINAR), 10-11AM
• Wednesday, March 13: Evergreen Indiana Holds Class (ISL), 10AM-NOON
• Thursday, March 28: Spring 2013 eIndiana OverDrive Training Class (WEBINAR), 10-11AM

Jackson County is hosting the Evergreen Indiana training classes for the month of March. All interested staff members are welcome to register on the WebJunction Calendar and attend.

• Friday, March 22: Evergreen Indiana Basic Cataloging, 9AM-NOON
• Friday, March 22: Evergreen Indiana Admin/Reports, 1-3PM
• Thursday, March 28: Evergreen Indiana Circulation Class, 9AM-1PM

Meetings

Minutes from the December 14, 2012 Executive Committee meeting were approved at the February 12, 2013 meeting.

Next EC meeting is Tuesday, April 9 @ Hussey Mayfield Memorial Public Library.

Hi all,

Evergreen 2.2.6 has been released. This release contains
a number of bugfixes since the last release back in January. See
this page for links to the source code, staff client, release notes,
changelog and more: http://evergreen-ils.org/downloads.php

The bugfixes covered in this release address (in no particular order)
serials, the TPAC, vandelay (MARC record import/export), hold rules,
documentation, the staff client, and more.

Thanks as always to all the contributors of the Evergreen community!

Mobile OPAC task force

Many staff in the Evergreen Indiana consortium and in other Evergreen consortia internationally have expressed a strong desire for a high functioning mobile OPAC. As many of our community members have stated, the OPAC is the face of the consortium to patrons and we want a fun mobile product with high usability that has the potential to drive usage back to our libraries. Since the mobile OPAC is high on our list of development priories, the Evergreen Indiana Executive Committee recommends putting together a task force of 5-7 Evergreen staff members who will be responsible for collaborating with the Evergreen Indiana helpdesk to create an RFQ. The task force is expected to require a commitment of 10-15 hours over a span of several weeks. Meetings will mostly be conducted over the phone and email. Once we are confident that the RFQ describes what our patrons desire in a mobile OPAC, we will solicit bids from various companies to begin the development process. The task force will most likely also be called upon to test and provide feedback once we receive a test product.

Please contact Adam Bowling, adbowling@library.in.gov, if you are interested in participating or have any questions.

Freegal opportunity

The Evergreen Indiana consortium is offering a consortial discount for interested members who would like to purchase Freegal, a downloadable music service for library patrons. Freegal provides library patrons with access to millions of songs which are DRM-Free mp3 files that are compatible with most devices. There are no holds queues with Freegal as the service allows simultaneous access to files and those who sign up for the service automatically have access to the full catalog of music.

As has been approved by the Evergreen Indiana Executive Committee, a sales rep from Freegal will be contacting Evergreen Indiana library directors later this week with their quote for pricing and the opportunity for each to take advantage of a demo of Freegal.

More information here: http://libraryideas.com/freegal.html

eIndiana OverDrive Consortium

The eIndiana OverDrive Committee voted to increase the checkout limit for the consortium from 3 to 5. This went into effect on February 13, 2013.

Also, Content Reserve upgraded on February 14, 2013 and has a new look! Trainings are available here: 30-minute recorded training (view anytime, anywhere), User reference guide (an overview of features and functionality).

WHAT: Evergreen Indiana member libraries are invited to attend the annual business meeting and all day conference for Evergreen users.

WHEN: May 9, 2013

WHERE: TBD

SCHEDULE:

8-9am Registration
9:30-10am Welcome
10-10:50 1st Sessions
11-11:50 2nd Sessions
12-1pm Lunch and business meeting
1-1:50pm Evergreen Jeopardy
2-2:50pm Subcommittee meetings / Presentation by the attendees of the 2013 Evergreen International Conference
3-3:50pm 3rd Sessions

Bibliomation and MassLNC are sponsoring development of search enhancements in Evergreen Open Source ILS.  Equinox Software will be spearheading the development project.  Ultimately, the goal of this development project is to make the following browse functions available in the catalog: alphabetical author, title and subject browse.  In order to make this functionality possible, the following enhancements will need to be made:  improvements to QueryParser and MARC-standard inter-authority linking.  Improvements will be made to the QueryParser framework and the Evergreen QueryParser driver to allow new search syntax.  Next, Equinox developers will implement MARC-standard inter-authority linking, similar to the development of bibliographic-authority linking, in order to support the see-from and see-also components.  Finally, with this infrastructure in place, Equinox developers will be able to develop an integrated bibliographic and in-use authority browse interface.  The browse axes will be configurable.  This new development will build upon the browse capability already in place.  Additional authority-related information will be extracted and stored in order to automatically provide authority-enhanced term matching. Browse sorting and display will be based on separate values, so that initial articles may or may not be displayed, per the configurations of the global setting per class (title, author, subject).

It is anticipated that the coding for this project will be completed by the end of March 2013 and submitted to launchpad for Evergreen Community review and approval.  Once the code has been reviewed and approved, it will be eligible for inclusion in the next major release of Evergreen.  Thank you to Bibliomation and MassLNC for sponsoring this development.

Three years ago I was asked to create and deliver a two-day course introducing SQL to Evergreen users. Things went well and I was able to share the resulting materials with the Evergreen and PostgreSQL community. Perhaps one of my happiest moments at the Evergreen conference last year was when one of the participants in that course, told me that many of his fellow participants were still successfully writing SQL queries and getting work done. Huzzah!

Time goes by and another group, OHIONET, was running into difficulties getting started with PostgreSQL and Evergreen. They asked me if I would be willing to give the same sort of training I had given a few years back. "Sure", I said, thinking it would be a great opportunity to polish the materials and add some updates to cover new features in PostgreSQL and Evergreen. We also opted to skip the travel and do an entirely virtual training session via Google Hangouts, which worked out rather nicely (but that's a different story).

As it turned out, I probably ended up putting about four days worth of effort (crammed into lots of late nights, weekends, and vacation days) into overhauling the instruction materials. But the results were worth it, in my opinion; I'm rather proud of the content, and while I believe it stands up on its own, the guidance that I was able to provide during the live instruction sessions was well-received by the participants.

Thus, I am pleased to be able to offer to the broader community the latest version of the Introduction to SQL for Evergreen Administrators, under a Creative Commons Attribution-ShareAlike 3.0 (Unported) license.

• Reference documentation--30 pages introducing SQL with examples drawn from the Evergreen schema: (HTML) (PDF) (ePub) (AsciiDoc)
• Presentation: (LibreOffice Impress) (PDF)
• Solutions to exercises: (Day 1) (Day 2)

So, a huge thanks to OHIONET for giving me the impetus to overhaul this material, and for giving me a chance to introduce them to the wonders of SQL with PostgreSQL, and to the inner workings of the Evergreen schema. It was a blast! And thanks for agreeing to let me share these materials with the broader community.

Looks like we haven't had much to say here at MVLC since October, but that's because we've been too busy doing lots of things to get around to making blog entries.

I just wanted to take a minute to let everyone know that the software for managing authority updates with Backstage Library Works got a little code update today. A command line option was added that allows you to just download the new files from Backstage's server. This is good if you want to download the files before the weekend and wait until next week to process them, or if you just don't feel like loading the authority and bibliographic updates right away.

As always, the code is here:

http://git.mvlcstaff.org/?p=jason/backstage.git;a=summary

BC Libraries Cooperative (BCLC) and MassLNC have teamed up to sponsor some Acquisitions (Acq) enhancements in Evergreen Open Source ILS.  This project encompasses the following development:

1.  a server-side Acq batch update API to be used with the Purchase Order (PO) interface for updating line items and associated copies without having to click into the Acq copies screen;

2.  a PO detailed view which will provide an option to expand (some/all) line items within a PO line item list to display the list of associated copies for the line item, including fields like owning library, fund, circulation modifier, copy location, etc.;

3.  new defaults and settings (org, provider, sticky) to include a default number of Acq copies and Acq/Vandelay default options;

4.  PO and selection list UI repairs and enhancements including:

• avoid double activation POs,

• disable invoice and cancel options for pending POs,

• rearrange actions drop-down to better suit the current state of the PO/PL and provide more batch operations across sets of line items,

• allow for disabling the zero-copy checkbox,

• disable/allow batch updater operations depending on PO state,

• disable new charges for activated POs,

• replace Shelving Location with Copy Location; and

• #INVOICED field is automatically populated with the number of copies available to be invoiced and the PAID field automatically updates to match the BILL field;

5.  Additional distribution formula fields including:  fund code, circulation modifier, collection code; and last but not least,

6.  ISBN (identifier) entry / selection for line items.  This will provide staff with the ability to select from existing ISBNs and enter new ISBNs for line items to be used as the primary identifier for the line item order.  Adding new ISBNs will cause the ISBN to be added to the linked bibliographic record.  Staff will also have the ability to add/select UPC and ISSN values in the same manner.

It is anticipated that the coding will be completed by the end of June 2013 and submitted to launchpad for Evergreen Community review and approval.  Once the code has been reviewed and approved, it will be eligible for inclusion in the next major release of Evergreen.  Thank you to BCLC and MassLNC for sponsoring this development.

Alexander Street Press, publisher of award-winning online collections and videos for scholarly research, teaching and learning, has partnered with Equinox Software to sponsor the following enhancements in Evergreen Open Source ILS.  There are two parts to this development project:  1)  new functionality related to the export of bibliographic records and 2)  new functionality related to the overlay of existing records via Z39.50.

1)  New functionality related to the export of bibliographic records:

For the first part, new functionality related to the export of bibliographic records, this development has two sub-parts:  1)  development of record-temporal bibliographic search enhancements and 2)  MARC21 feed output.

You may be asking yourself right now, “And just what are record-temporal bibliographic search enhancements?”  Good question.  So, currently in Evergreen one can sort bibliographic records by creation and edit date, but temporal search is not possible on any field other than the MARC Date1 and Date2 fields.  In order to support time-sensitive record discovery, enhancements to QueryParser are needed.  (QueryParser is a powerful infrastructure for building search dialects.)  The QueryParser enhancements will include new filter options to support filtering on create and edit dates and a new modifier will be defined to allow the search of deleted records, instead of live and active records.  The QueryParser enhancements will not affect the underlying database structure.

Regarding the second part, MARC21 feed output, Evergreen currently supports a wide variety of plain text, JSON and XML feed formats, all available via the OpenSearch interface.  Evergreen also supports the export of records as MARC21 through Vandelay and other interfaces.  However, there is no way to retrieve search results as a MARC21 record set.  This development will rectify that by creating a feed output module to convert search results to MARC21.

2)  New functionality related to the overlay of existing records via Z39.50:

The development of new functionality related to the overlay of existing records via Z39.50 is also comprised of 2 sub-parts:  1)  federated Z39.50 search from record set and 2)  federated Z39.50 match and overlay.

For the first part, federated Z39.50 search from record set, to locate bibliographic records that are of a higher quality than existing catalog records, Evergreen currently supports manual searching of remote Z39.50 servers.  Though any search may span multiple Z39 servers, only one search may be performed at a time.  Any records found via a Z39 search then must be manually imported into the catalog or overlayed over an existing catalog record at the discretion of the staff.  All aspects of locating and importing records via Z39 require staff intervention to complete.  This development includes several enhancements to improve and automate the process of locating bibliographic records via Z39 that match existing catalog records.  Specifically, each staff-accessible record bucket interface (bucket, bookbags) will get a new action called “Locate Remote Matches via Z39.50″.  When clicked, the user will be presented with a dialog which contains several choices, including which Z39 servers to include in the search and which match points to use (the union of all configured match point for all selected Z servers).  When the search is submitted, a series of parallel Z39 searches is fired off.  The user will be able to see the progress of the search as it proceeds.

For the second part of the development, federated Z39.50 match and overlay, when the Federated Z39.50 search from record set process completes, an interface showing the newly created Vandelay queue is opened in a new staff client tab instead of showing the existing Z39.50 result list.  In the Vandelay queue interface, records are grouped by which existing record they match against and will overlay.  From here, the user can perform all of the standard pre-record and batch overlay actions.  Before any overlay occurs, the user may wish to perform updates on the queued records.  Manual updates are already supported.  To support automated updates, there will be development to provide a Vandelay queue export action which exports a Vandelay queue as a MARC21 (.mrc) file.  The user can then update the file via some external mechanism and re-load the records into Vandelay for final merging.  This approach would require the addition of a match-bucket selector in the upload interface, to ensure the re-imported records only match against the original source records.

It is anticipated that the coding for this project will be completed by the end of March 2013 and submitted to launchpad for Evergreen Community review and approval.  Once the code has been reviewed and approved, it will be eligible for inclusion in the next major release of Evergreen.  Thank you to Alexander Street Press for sponsoring this development.

We’ve seen what Websockets are and how their persistent connections could provide considerable speed benefits and reduction of network traffic.  In this post, I’ll introduce some proof of concept code so that we can bring the discussion out of the world of theory and into the world of practice.

All of the code I’m discussing today lives in the OpenSRF working repository.

http://git.evergreen-ils.org/?p=working/OpenSRF.git;a=shortlog;h=refs/heads/collab/berick/websockets

What do we need to start experimenting with Websockets in Evergreen?

1. An OpenSRF Websocket gateway

2. An OpenSRF Javascript Websocket client library

1. The Gateway

First, a little history…

The code library to use for the server gateway was a point of debate when we discussed this at the developer’s meeting in September.  One option is to create the Websocket gateway using Apache.  There are a number of reasons to take this approach, but Apache uses a lot of RAM, which is a problem when managing large numbers of long-lived connections.  An alternative solution is to use a standalone Websocket server library, like libwebsockets [http://git.warmcat.com/cgi-bin/cgit/libwebsockets/].  The hope of a standalone server is that it will have a much smaller memory footprint.

Coming into this, I had a strong preference for using Apache.  Every Evergreen administrator knows Apache and my fear was that adding a new technology stack to the existing mix of technology used by Evergreen would inhibit adoption.  Also, Apache has been around forever, it’s stable, and comes with a number of goodies out of the box, like access control, request/environment inspection/munging, data compression tools, etc.,

Finally, in regard to comparing Apache to Libwebsockets specifically, Libwebsockets does not operate as a forking server.  It was developed, I presume, mainly to support threaded applications.  However, the OpenSRF C library is not thread safe, nor would a single (per brick) process be sufficient to relay messages to/from all connected clients without congestion. To use libwebsockets, we’d have to implement a forking / process management layer.  I was not particularly interested in tackling this bit of code just for my proof of concept experiments.

Though I was eager to use Apache for the gateway, I had a hard time convincing myself it was worth it if Apache required too much RAM to be a viable option in the long run.  To tackle this problem, I considered ways to reduce the amount of RAM Apache used out of the box and ultimately decided to try running Apache with no modules loaded and no services running.  It turns out, Apache by itself is very lightweight.  After some experimentation, I was able to get a Websocket gateway running successfully on Apache with only 3 modules loaded: mime, SSL, and mod_websocket.

For comparison, how does the trimmed down Apache stack up to a single-process Libwebsockets implementation?  The image below shows memory information for both implementations.  What you are seeing is the baseline footprint.  Neither implementation (at this point) has been taught to communicate over OpenSRF.  They only have enough code to understand Websockets.

 

(RSS is in kilobytes)

Libwebsockets beats the Apache baseline memory usage by 92K.  However, as I mentioned before, libwebsockets does not have any process control built in, so that would require the addition of a decent chunk of new code and memory consumption from inter-process communications (pipes, etc.), which is already accounted for in Apache.  Even from a memory perspective, if Apache doesn’t win outright (and I think it might), it at least ties libwebsockets, and probably any other websockets library.

In case you’re wondering, the last Apache entry in the screenshot, with the higher memory footprint, is the parent process, which requires more RAM to manage open pipes to all of its child processes, etc.

This was all I needed to continue developing the gateway code for Apache.  To take advantage of the reduced memory footprint created by disabling all of those Apache modules, we have to run a secondary, trimmed-down Apache instance to host the Websocket gateway.  Otherwise, each Websocket connection (i.e. Apache process) would be sitting atop 30+ Apache modules and a large pile of RAM.  Running a secondary Apache instance is not exactly ideal, but it seems that hosting a Websocket gateway is going to require running some other process, regardless.  Running a secondary instance of a service for which we already have a solid grasp seems like the lesser of evils.  Also, running a secondary Apache instance is apparently not that uncommon.  (For example, Debian includes a script to automate the setup).  For reference, here are my current install notes:

http://git.evergreen-ils.org/?p=working/OpenSRF.git;a=blob;f=README.websockets;h=c9f2391d40857e8764ad162ec8afa3e92ce7df8e;hb=HEAD

Now that we have a baseline, let’s add support for OpenSRF communication.  The addition of OpenSRF and its dependencies (e.g. libxml2) is a fixed cost incurred regardless of the underlying technology.

What is the RAM picture after Apache is taught how to handle OpenSRF websockets requests?

This screenshot shows the memory consumption of a set of trimmed down Apache websocket processes alongside a set of regular Evergreen Apache processes.  All processes shown at this point have handled several requests, so we are seeing their operating RAM levels, not the RAM usage at startup.The websocket processes use less than 1/15th the RAM of a regular Evergreen process.

As an aside, we should consider reviewing the default Apache modules used for Evergreen.  There may be some room to remove a few modules and regain some memory.

For a websocket gateway, we’re still talking about needing more RAM, right?  Not necessarily.  Managing API traffic through a separate set of processes means it would no longer necessary to use the 50+MB Apache processes to handle translator requests.  (Or, at least, it would be much less common).  Those large processes would be limited to more traditional web activities like serving files and generating web content (e.g. TPAC).  At any given time, many, if not most, of the active Apache processes today are handing translator requests.  Eliminating those processes opens up more RAM space for running the websocket Apache instance.

As a data point, if the average websocket process consumes 4MB of RAM, one thousand staff connections would require roughly 4G of RAM.  Of course, a sane admin would add a good bit of overflow RAM, but you get the idea.

2. The Client

Javascript already supports Websockets, so this code simply needs to be able to open a Websocket connection, send OpenSRF requests over the connection, then translate Websocket responses into OpenSRF responses (and potentially other types of out-of-band messages, like broadcasts) and pass them back to the caller.

http://git.evergreen-ils.org/?p=working/OpenSRF.git;a=commit;h=aab6f533c8b63ae19c49df0661bb0ec35c58bf5e

The API is practically identical to the existing XMLHttpRequest/Translator API.

var ses = new OpenSRF.ClientSession('open-ils.actor');
ses.request({
    method : 'opensrf.system.echo',
    params : ['hello', 'world'],
    onresponse : function(r) {
        var result = r.recv().content();
        alert(result);
    },
    oncomplete : function() {
        // all responses received
    }
}).send();

The only real difference is that all requests are required to be asynchronous, so onresponse/oncomplete handlers are required for receiving responses.

It’s important to note that because Websockets are always asynchronous, we cannot simply replace the Evergreen communication layer with Websockets.  There are numerous instances of synchronous communication used in Evergreen today and each would have to be modified to work properly in a fully asynchronous environment.

Experimenting With the Code

I’ve set up a few tests and so far it’s all very promising.  I can successfully communicate with the Evergreen server, manage sets of open conversations among multiple services, and manage stateful/connected sessions.  To be clear, though, the code, installer process, and documentation as they exist today are alpha quality at best.  I have not attempted to integrate the code into the staff client in any meaningful way, so it only works today in the browser.  Much testing and smoothing is required before we could leverage the code, but that doesn’t mean it can’t be installed and run by some adventurous coders.

I look forward to testing the code more in the coming days and creating some benchmark scripts for comparing Websockets to XMLHttpRequest in the context of Evergreen and OpenSRF.  When I have data to share, I may post an epilogue to this series.  As always, feel free to ping me in IRC (berick), here, or the Evergreen developer mailing list if you have any questions about the code or my approach to Websockets in general.

Development Queue

Development for a few software features is on the horizon for Evergreen Indiana. Requesting development on features for Evergreen often depends on collaboration and mobilization from the local community as well as from the international community. However, committee discussions and member requests have brought several development requests to the top of the priority list for Evergreen Indiana. Those items are listed below. We appreciate everyone’s patience and cooperation in working through this process!

• Copy notes: Viewable in the OPAC – In process
• Payment pilot daily reconciliation reports – Next in the development request queue. It is important to get these reports perfected before we expand the payment program to all libraries in the consortium.
• Mobile OPAC. The Executive Committee is aware that many libraries in EI are interested in an app which patrons can use to search the catalog, log into their account and place holds.

Meetings

OverDrive Committee is meeting on February 12 @ Hussey Mayfield Memorial Public Library.
• Draft agenda

Executive Committee is meeting on February 12 @ Hussey Mayfield Memorial Public Library.
• Draft agenda

Minutes from the September 27, 2012 OPAC Committee were approved on January 24, 2013.

Our Social Committee has worked hard to make sure there is as much time for socializing as conferencing. To start thing off, we will be having an Opening Reception in a fabulous room in the hotel on Wednesday evening. Thursday night is the big social event of the conference where we booked the Steamworks Brew Pub Uber Lounge in historic Gastown for an evening of hearty appetizers, craft beers, and ocean views. Friday night is your chance to explore many restaurant and pub offerings in Vancouver.

All these details, and suggestions of places to see and eat in Vancouver, are described on our Social Events page. See you in April!

Did you visit our site between Jan 21-29? Unfortunately our site was hacked. If you visited the site during this period, we recommend you use an anti-malware program to scan your machine for malicious software. If you’re unusure when you last visited the site, scan your machine anyway to be on the safe side!

The site is cleaned up and safe to visit now. Thank you, Robin!