Building a Library Network from Scratch:
Eric & Veronica's Excellent Adventure


by Eric Sisler and Veronica Smith

This article has been republished in its entirety from the October 2000 issue of Computers in Libraries magazine with the permission of Information Today, Inc., 143 Old Marlton Pike, Medford, NJ 08055. 609/654-6266.

Our mission was to design a network for two different libraries that were going to move into the same building. It was a long ride, and there was never a dull moment!

A library no longer operates with just an online catalog. There are many other products and services that library patrons and employees are demanding. As a result, library automation staff must support much more than just the catalog. It must face a myriad of different hardware, software, and networking issues.

In this article we will discuss how our library's automation staff dealt with the challenges of providing support during the initial planning and construction of College Hill Library, located in Westminster, Colorado. This unique library, which opened in April of 1998, is a joint-use facility that's shared by Front Range Community College (FRCC) and Westminster Public Library (WPL). The library, which resides on the FRCC campus, serves a population of 70,000, has a collection of 188,000 items, and circulated 885,000 items in 1999.

We make up the two-member Automation Services (AS) department for the library system, which includes the College Hill Library and the 76th Avenue branch. We are responsible for all computer-related technology at both facilities, including hardware, software, servers, and network equipment. We work closely with both the city and college Information Technology (IT) departments to ensure smooth working operations between the library and these two agencies.

Combining the Two Libraries

So, how did a public library and a community college library come to be in the same building? In 1996, the city of Westminster and FRCC were each planning new facilities that would likely be located within a mile of each other. Administrators from both agencies decided they could build a nicer library together than either could build alone. This newly proposed facility would not come together without difficulties, though. For starters, the public library used Dynix and cataloged in Dewey while the college library used CARL and cataloged in Library of Congress (LC).

Selecting Dynix for our library automation needs was a reasonably easy decision, although each staff obviously preferred the system it was already using. The city owned the server that ran Dynix, so it paid only for the software. Adding FRCC was simply a matter of adding additional accounts and migrating the data. The college library didn't have its own server, and migrating the city's data to CARL would have been far too costly.

Although the automation system problem was solved by migrating the college to Dynix, the Dewey/LC issue proved insurmountable. Instead of trying to force one cataloging scheme to fit into the other, which would include reclassifying an entire collection, the consensus was to leave them separate. So rather than think of it as one library with two classification schemes, we think of it as two libraries sharing the same building with open access to all patrons. Since the building was to have two floors, separating the collections was logical.

Constructing the Network

Since we would be moving into a new building, we had to do everything from scratch. The new College Hill Library was to be 76,000 square feet. It was being built as two stories high and also quite long, which presented some problems when we were designing the network. A single span of Ethernet cable should run no more than 300 feet, so we knew we would have to split the building into multiple zones. What we didn't want was to waste space or duplicate equipment. Here are some of the initial ideas:

  1. We could have a main data closet at one end of the building feeding remote hubs in the ceiling, using repeaters when the distance became too great. We decided this would create maintenance and troubleshooting problems for both the repeaters and the hubs because the ceiling is 20 feet high in some areas.

  2. We could have a main data closet in the middle of the building on each floor feeding remote hubs located in small cabinets mounted near the ceiling in storage closets. We liked the cabinet idea since it provided security and ease of access, but decided two main closets would be a waste of space.

Eventually we settled on having a single main data closet located on the second floor in the middle of the building. The main data closet houses several hubs, a core switch, router, CSU/DSU, and a pair of Linux servers. The router and CSU/DSU provide access to the library's dedicated T-1 data circuit, which connects us to Westminster's City Hall, our Dynix server, and ultimately the Internet. Each of the remote zones has its own cabinet/hub combo, and each is linked to the main closet by fiber optic cable. Since fiber allows insanely fast data transmission, it's easy for us to upgrade the network gear without having to replace the links from the remote closets to the main closet. Each closet has three pairs of fiber between it and the main closet to allow for future expansion of the network. We have standard CAT-5 copper wiring running from the closets to the data jacks.

"The city and the college each had concerns about patrons accessing sensitive data on their respective LANs. ... so it made sense for us to have our own separate LAN."

The network at College Hill Library is a combination shared (dumb hub) and switched environment, all 10 Megabit. We toyed with the idea of 100 Megabit but felt it was a bit too expensive at the time. Although College Hill Library is located on the FRCC campus, it is a network unto itself, separate from both the college and city networks. Though it might have seemed obvious for the library to join the college's LAN, we chose not to for several reasons. The city and the college each had concerns about patrons accessing sensitive data on their respective LANs. Additionally, Automation Services would be providing the library's network support, so it made sense for us to have our own separate LAN.

Providing Network Services

As the building was taking shape, Eric began experimenting with Linux, and ultimately recommended it for our server operating system (OS). Since every dollar we spent on the server OS meant one less dollar for other technology needs, Linux's low, low price was certainly attractive, but there were other factors. Choosing Linux provided the opportunity to use it as a learning tool for UNIX, which is what our Dynix server runs. It also meant that we wouldn't have to become proficient in two operating systems. Neither of us had a great deal of experience with server operating systems of any kind, and we weren't interested in trying to become experts on two at once-we had enough to do already!

Initially, our needs for technology beyond the catalog were pretty limited. All of the services we wanted to provide, plus a veritable plethora that we might want to investigate later, were available "out of the box" with Linux. Other products, such as NT or Netware, didn't provide all of the same services. And the few services that were available often came as add-ons, which of course meant additional costs. So Linux was the logical choice. So, what kind of services do we provide at the library using Linux? Virtually everything except the catalog. A complete discussion of all the things we use Linux for could be an article all by itself. You can read more about it by visiting

Setting Up the Computers

Once plans for the network were underway, we began to look at our PC needs. Windows 95 was the order of the day for software, but what about hardware? At the time, the public library was using the city's standard of Compaq, while the college library had a mishmash of computer equipment. Since the public library was already using uniform equipment that we were familiar with, we chose Compaq for the new library. Keeping the brand name consistent over time is no small task because we must work with two agencies to purchase these computers. Each agency naturally has its own purchasing regulations, preferred vendors, and fiscal years, not to mention that one is a municipality and the other is a state agency.

As many large institutions have migrated to Microsoft applications for the sake of uniformity and compatibility, so have the city, the community college, and the library. Adding to the basics of Windows 95 and Office, we also provided Internet browsers and staff e-mail on library computers. In preparation for opening the new library, we loaded both Internet Explorer and Netscape onto all staff machines and asked the staff which browser they liked best. The overwhelming majority liked Netscape, so that became the standard. Staff computers still have both browsers installed, in the event that a Web page is incompatible with Netscape.

E-mail was quite a mess at first. There were all kinds of e-mail programs running around: Eudora, Outlook Express, an outdated Data General e-mail system, and Netscape. We soon discovered that we could not support all of the different programs and maintain our sanity at the same time!

In 1999, the city changed its e-mail from the Data General system to the Outlook client and Exchange server, providing accounts for all employees at or above supervisory level. At that point, we felt our lives would be much simpler if we switched all city employees over to using Outlook, whether they had an Exchange account or not. We would provide e-mail for those without an Exchange account. Meanwhile, most FRCC employees had been using Eudora. However, in the fall of 1999, FRCC also decided to move to Outlook/Exchange. Even though FRCC is still in varying stages of implementation today, we already moved all library employees to Outlook as part of the Y2K software updates so they would be ready for the college's new e-mail system.

"E-mail was quite a mess at first. There were all kinds of e-mail programs...."

Providing Public Access

One of the most amazing changes for us over the past few years is that library technology doesn't just consist of a text-based catalog anymore. The catalog has become just one piece of what we offer to our patrons.

Prior to the merger, Westminster Public Library had had a text-based catalog and FRCC had had a few PACs that used the graphical front end from CARL, called Everybody's Catalog. That all changed in 1998 when AS introduced the graphical version of Dynix, called PAC for Windows (P4W). This new front end allowed us to unify the products that were available as well as to customize the look of the products being provided. No longer did we have PAC PCs for just the catalog and stand-alone stations for electronic reference products. All of these products were joined into one uniform system with icons pointing the way to different resources.

PAC for Windows also gave us a much better way to administer the look of every PAC computer. P4W uses a configuration file that is copied from the server anytime a PC is booted. Changing what a particular computer has access to is as easy as changing that PC's login script.

We created two configuration files-one for the PAC-only machines and one for Internet/staff machines. The PAC-only file allows access to the catalog, bestseller lists, and patron information. The Internet/staff file allows access to this same information, but also has icons directing patrons to available electronic reference resources, whether on CD-ROM or a commercial Internet database.

Allowing Web Adventures Beyond the Basic Catalog

Electronic reference products have grown at an incredible rate over the past 2 years. Prior to College Hill, each separate library had owned just a few stand-alone CD-ROM products. Now there are over 15 different electronic products available, offered mostly over the Web.

Deciding which products to provide and which agency would purchase each product was quite a challenge. Initially, a committee was formed to look at print vs. electronic offerings and their associated costs. Most of the products recommended were no longer available in CD-ROM format, so we opted for the Web versions. Although they were sometimes less reliable, the Web formats were easier to administer and provided more current information. Veronica continues to work with a joint reference staff group to evaluate existing products and decide on necessary changes. It is still a struggle to keep a balance between what the library needs and what the budget will support.

Dueling Cataloging Tools

Although the goal of all library staff members was to operate as one unit for the public, the two Technical Services (TS) departments have remained two separate entities out of necessity. Not only are the two vastly different in size and function, but their sources for bibliographic records and their classification schemes are different as well.

FRCC uses OCLC for bibliographic data, Midwest Library Services for acquisitions, and it catalogs in graphical mode using LC classification. WPL uses Bibliofile with ITS.MARC access on the Web from TLC, Dynix's acquisitions module, and it catalogs in text mode using Dewey classification. There are also different spine label printing programs with different types of printers and printer setups for the labels.

Over time, these operational differences have posed quite a challenge for AS. Each difference translates into additional support needs for tech services staff. We must be versed in two different types of technical services processes and procedures, including specialized software and hardware.

Providing Resources for Kids

Once the new library was built, we spent some time trying to decide what we would do with children's CD-ROM games. The branch library had one computer with an old CD-ROM changer on it, and although it was slow and clunky, it was one of the most heavily used computers. After investigating some different products, we finally decided to purchase Nakamichi 5-disc internal changers to supplement the regular drive, giving us a total of six drives to work with.

"One of the most effective ways we have found to deal with the challenge of being a two-person automation team with way too much to do is through constant communication."

From Eric's past experience of pulling pink barrettes and golf pencils out of the old CD-ROM changer, we decided that protection and childproofing were necessary. We scoured the Internet and found ByteBoxes. A ByteBox is a plexiglass box, complete with filters and a fan, that houses the CPU portion of the computer workstation. Yes, we have to change the filters quarterly, but it beats losing our computer games and digging foreign objects out of the CD and floppy drives!

Securing the Equipment

Libraries are in a unique situation as far as security is concerned. We must strike a balance between usability and security. Too little protection invites problems and too much makes it impossible to get work done.

At the physical level, we put the servers and network gear in locked closets with limited staff access. We installed locks over the floppy and CD-ROM drives on all public PCs and gave keys to staff members so they could allow patrons to download files to disks when necessary.

We secured Windows 95 using a combination of WinSelect, registry settings, and configuration files copied from the server during boot up. Originally we used Fortres 101, but soon discovered it didn't work and play well with our graphical catalog application.

Securing the servers was a matter of configuring the services to run properly, disabling unused services, and running Linux's IP firewalling tools (ipfwadm or ipchains). We also set up a firewall between us and the college that could provide FRCC staff with access to the college's financial system. This firewall would serve double duty, allowing us to re-route our traffic through the college's Internet connection in the event that our T-1 circuit was down.

Exciting Adventures in Maintenance and Support

A few weeks before opening College Hill, AS staff installed 103 new PCs throughout the building, bringing the total number of supported PCs to 114. With this many PCs to set up and maintain, installing software on each one individually was simply not feasible. But by keeping the brand consistent and placing the same model in similar roles, we were able to use drive-imaging software like Ghost and ImageCast to build software images which were then distributed to each PC. This saved a great deal of time and ensured that each PC would at least start out with the same configuration. This way, we knew that if a PC got trashed it could be restored to working order in only a few minutes. We highly recommend this method for any library with a lot of PCs to maintain.

To provide evening and weekend support, one of us must be on call during business hours in the event of system trouble. We each carry a pager, trading on-call duty every 2 weeks. But since we've engineered our network and servers so well, on-call duty is generally pretty uneventful.

We remotely administer our servers from the command line using Secure Shell (ssh). This is a secure replacement for telnet that encrypts the entire data stream including user name/password authentication and all session data. This provides safe administration from across the hall or across town. We are also able to remotely administer our client PCs by using WinVNC. This saves a great deal of walking around the building or driving to the branch. It's also great for freaking staff out the first time they see us do it. It's almost like having your car drive itself.

Planning for the Future

Planning for the automation needs of a complex new library can be somewhat daunting. Even now that we have overcome the hurdles that a new library can bring, we find it difficult at times to keep up with the day-to-day operations and to plan for the future at the same time.

One of the most effective ways we have found to deal with the challenge of being a two-person automation team with way too much to do is through constant communication. We work with diverse IT groups from two other institutions, a myriad of vendors, seven different internal library groups, and every individual staff member, all while trying to keep the ultimate customer, our patrons, in mind. Without effective communication, juggling all our tasks would be impossible.

Another challenge we face is in trying to determine whose project takes precedence. Invariably, we will have a schedule of projects to work on and then we'll get a phone call about a computer that is down and we'll have to reshuffle our priorities. Trying to keep up with all of the new technology has been described as akin to driving with one foot on the brake and one foot on the gas at the same time. We can't move ahead too fast because it takes time to test and implement each new piece of technology. Other times we just don't have the manpower or time to implement technology fast enough for staff to be satisfied. It's like being caught between a CPU and a hard drive!

Eric Sisler is the library computer technician and Veronica Smith is the library automation coordinator, both at Westminster Public Library in Westminster, Colorado. Sisler is largely self-educated in the ways of computers and has worked for the library for 15-plus years in a variety of positions. He is currently responsible for the care and feeding of three Linux servers, one HP-UX server, assorted network gear, and far too many client PCs. His e-mail address is Smith holds an M.L.S. from Emporia State University in Emporia, Kansas. She has worked in various technical services departments for the last 16 years. She is currently responsible for planning and coordinating technology-related projects. Her e-mail address is