[unisog] Library Management Systems

Sylvain Robitaille syl at alcor.concordia.ca
Tue Aug 23 21:21:03 GMT 2005


On Tue, 23 Aug 2005, Brian Friday wrote:

> 1) Do you have Millennium on your own hardware or that supplied by
>    Innovative Interfaces?

We've always had the III software on computer systems managed in our own
department.   So far, (as long as I've been here), these have always
been DEC/Compaq Alpha systems, with the current system being a dual
processor DS25.

> 2) Manpower hours dedicated to system administration duties of the
>    Millennium software/hardware?

Usually very little: we manage the OS, and they manage their software.
Very likely staff in our library spends more time managing this system
(at the application software level) than we do.

> 3) Size of the collection served by Millennium?

Unknown; I don't work in the library, but it is a university library, so
I'm sure it isn't "small".

> 4) How has Innovative Interfaces support and patching been?

I don't deal with them very much.  Only when we need to upgrade the OS
and/or hardware has there been any need for our group to coordinate with
them.  The library staff deal with them for application support,
patching, upgrades, etc.  When upgrades take place they usually need an
operator present to switch tapes, but nothing more.

> 5) How has Innovative Interfaces networking requirements been?
> (flexible, willing to be secure?)

Very inflexible, that way.  It's taken years of our repeated demands
just to get them to use Ssh to login (they do insist on having a uid 0
account, and they were telnetting in to use it), but even with that
they've been trying to overwrite our own Ssh installation with theirs.

It took a lot of work to convince them to let us use TCP_Wrappers for
access control and logging (they have their own "wrapper" binary, with a
very odd access control syntax, and hidden log file).  In fact, they
never "let us", claiming that it wouldn't work.  We've just gone ahead
and wrapped their wrappers with TCP_Wrappers, though we've had to put in
more than a few "reminders" in /etc/inetd.conf to ensure that they don't
remove the double-wrapping.  I don't think that has helped, though, as I
expect that they're using scripts to make whatever changes they make,
and so never see our notes.

Every once in a while we need to remind them that we're managing the
system, and they're managing the software.

I've asked them for a description of which of their binaries require
setuid 0 permissions (there are a lot of them that have it), why that's
required, and how they handle ensuring that the elevated privilege is
given up once it's no longer needed.  I ultimately had to give up on
that, though, as I basically got a "we wouldn't tell you even if we
knew" sort of response (that's not a direct quote;  I'm sure _someone_
there knows, but certainly not anyone I was able to contact).

Every time the software is upgraded, though, we remove the setuid 0 bit
from shell scripts that end up with it ...

I could go on, but I'm sure people get the picture.  For the most
part, our library staff swear by III, while we sysadmins swear at
III, wishing that the library staff would take a serious look at koha
(http://www.koha.org/)

> 6) Have you found their sales reps to understate or overstate the
>    capabilities of their hardware software packages?

I have no idea;  this package was sold to our library.  I do know that
our library staff have often (prior to our getting the DS25) asked about
performance of the system, claiming that it was sluggish.  We were never
able to find anything at the system level to confirm these claims (in
fact this system has often been one of our fastest, from our point of
view), and had to propose that there must be a bottleneeck in the
application.

-- 
----------------------------------------------------------------------
Sylvain Robitaille                              syl at alcor.concordia.ca

Systems analyst                                   Concordia University
Instructional & Information Technology        Montreal, Quebec, Canada
----------------------------------------------------------------------



More information about the unisog mailing list