[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[handle-dev] Hi Jane,
Hi Jane,
Seeking a robust handle environment at National Library of NZ leads us to install handle servers on two host (tainui and fred)
Our dns entry handle.natlib.govt.nz resolves to tainui. (tainui CNAME handle.natlib.govt.nz , fred CNAME bogus.natlib.govt.nz)
If we want to change the handle server from tainui to fred we can do so by altering the dns entries so that the handle.natlib.govt.nz resolves to fred. (tainui CNAME bogus.natlib.govt.nz , fred CNAME handle.natlib.govt.nz)
The question therefore becomes : how do we keep the handle databases in sync between the two hosts ? In other words is there a file or files that we can ftp between servers such that the contents are the same on both of the hosts ?
This of course assumes that there is not a master/secondary handle server heirarchy reflected on the hosts, that we take it upon ourselves to ensure administration of handles occurs on the correct host , and that the replication follows.
Regards, Lockie
V V DBA
V V National Library of New Zealand
\ / Ph 0064 4 4743134 x 8720
< .. >___ Mobile 0064 21 648044
U } Fax 0064 4 474 3140
yyyy Pager dba.pager@natlib.govt.nz
--------------------------------------------------
_______________________________________________
handle-dev mailing list
handle-dev@cnri.reston.va.us
http://www.cnri.reston.va.us/mailman/listinfo/handle-dev
From handle-dev-admin@cnri.reston.va.us Wed Jan 29 14:59:13 2003
Return-Path: <handle-dev-admin@cnri.reston.va.us>
Received: from www1 by www1.cnri.reston.va.us (SMI-8.6/SMI-SVR4)
id OAA26794; Wed, 29 Jan 2003 14:56:59 -0500
Received: from cnri.reston.va.us by www1.cnri.reston.va.us (SMI-8.6/SMI-SVR4)
id OAA26765; Wed, 29 Jan 2003 14:56:56 -0500
Received: from abyssus.doit.wisc.edu (abyssus.doit.wisc.edu [128.104.19.201])
by cnri.reston.va.us (8.11.6+Sun/8.11.3) with ESMTP id h0TJvDN14219
for <handle-dev@cnri.reston.va.us>; Wed, 29 Jan 2003 14:57:13 -0500 (EST)
Received: from abyssus.doit.wisc.edu (msimpson@localhost)
by abyssus.doit.wisc.edu (8.11.6/8.11.6) with ESMTP id h0TJx9F32524
for <handle-dev@cnri.reston.va.us>; Wed, 29 Jan 2003 13:59:10 -0600
Message-Id: <200301291959.h0TJx9F32524@abyssus.doit.wisc.edu>
X-Mailer: exmh version 2.4 06/23/2000 with nmh-1.0.4
To: handle-dev@cnri.reston.va.us
Subject: Re: [handle-dev] Hi Jane,
In-Reply-To: Your message of "Fri, 24 Jan 2003 14:19:38 +1300."
<se314c26.033@gwia.natlib.govt.nz>
Reply-to: mike.simpson@doit.wisc.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Wed, 29 Jan 2003 13:59:09 -0600
From: Mike Simpson <msimpson@abyssus.doit.wisc.edu>
Sender: handle-dev-admin@cnri.reston.va.us
Errors-To: handle-dev-admin@cnri.reston.va.us
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Handle System Developers' Mailing List <handle-dev.cnri.reston.va.us>
X-BeenThere: handle-dev@cnri.reston.va.us
content-length: 5782
Lockie et al. --
I'm in the process of trying to set up something similar for the
UW-Madison Libraries handle servers ... replication and automated
failover in the case of the primary server going down. I'm trying to
make sense of the documentation and what I see in the naming
authority handle, and I admit I'm getting stuck. Hopefully others on
this list will have already solved this problem ...
We have a primary server ("handle-1") living at IP 144.92.161.72,
ports 2641 (tcp, udp) and 2652 (http), serving the 0.NA/1711 naming
authority. I want to replicate and failover to a mirror server
("handle-2") living at IP 144.92.161.73 (same port assignments as the
primary).
From looking primarily at Section 10 ("Replication") in the
Administration Manual, and various other bits and pieces, it looks
like two things have to happen:
(a) setup the mirror server and get replication authentication
established. To do this, run the "Simple Setup" as detailed in the
INSTALL file. Answer "n" to the "Will this be a primary server?"
question, then enter the IP and port number of the primary server
when prompted (i.e. for us, 144.92.161.72:2641). The setup program
prompts for a server key (which we don't encrypt, since we have to do
unattended restarts), skips prompting for an administrative key (only
relevant for primary servers), and the prompts for a "replication
authentication" key.
-> question #1: If I choose to encrypt the replication
authentication key, will I need to enter the password at server
startup, or otherwise periodically? I.e. is it more like the
server key, or more like the administrative key?
The program finishes by telling you to email the sitebndl.zip file to
CNRI. They use it to update the HS_SITE information in the 0.NA
handle, I'm guessing (see below).
Then you have to modify the config.dct file in various ways. The
instructions in the Admin Manual seem a little vague to me. You need
to modify "server_admins" ...
-> question #2: What value do I put there? The same as in the
primary, i.e. for us "300:0.NA/1711"?
and "this_server_id" ...
-> question #3: The manual says that you must modify this "if more
than 1 server in HS_SITE". Does a mirror server, running on a
seperate host at a seperate IP, wind up as another entry in a
single HS_SITE record, or as a seperate HS_SITE record entirely?
Do I need to change this number so that it's different from the
primary?
and "replication_authentication" ...
-> question #4: What goes here? The manual doesn't say. The setup
program, for me, filled in "privatekey:300:0.NA/1711". Is this
correct?
Then, the manual says you have to modify the config.dct for the
primary server. These directions are even less clear to me:
-> question #5: I'm supposed to "Add the replication public key
value(`replpub.bin') to the handle specified in
replication_authentication.". My primary doesn't have any
value set for "replication_authentication". And do I need to
copy "replpub.bin" over to the primary server directory?
-> question #6: Then I need to "Add that handle to the primary
server's replication_admins group in its `config.dct' file."
What handle is "that handle"?
-> question #7: There's a step that needs to be done "ONLY if
mirror servers are under the same HS_SITE". Same question as
#3 above; also, the proceeding line in the manual states that
"The `txnsrcsv.bin' file is the `siteinfo.bin' file from the
primary server." Does that mean I have to copy the primary's
"siteinfo.bin" into place under the mirror as "txnsrcsv.bin"?
(b) Once all the above is ready, then we go to what has to happen at the
0.NA (CNRI) end. This is more or less black magic to me, but from
looking at our naming authority handle (0.NA/1711) it looks like
a second HS_SITE record has to be created. I.e. the existing HS_SITE
record has a yes/no value for "Primary Site" for the record as a
whole, although it looks like you could have multiple servers all
participating as your "primary site". From the "Handle System
Namespace and Service Definition", section 3.2.2, it looks like a
"service site" (HS_SITE?) can be one or more server instances running
on one or more hosts; the "<PrimaryMask>" field of the HS_SITE
record specifies whether or not a given HS_SITE is a "primary" (as
opposed to mirror?) as well as whether or not there are multiple
primary sites. Here, "primary" seems to mean "able to do handle
administration tasks".
-> question #8: So for a plain ol' replicated mirror of the 1711
naming authority, does CNRI wind up adding another HS_SITE record
to the 0.NA/1711 handle, with the "<PrimaryMask>" field zeroed
out ("this service site is not a primary, nor are there multiple
primaries under this naming authority")?
This seems to match up with what's defined in the "Handle System
Protocol (ver 2.1) Specification", sections 3.1.2 and 3.1.3. I'm
probably missing it, but I couldn't find anything specified for
client behavior when the primary server is down, under section 3.2.3.
My assumption would be that a "well-behaved" client would pull all of
the HS_SITE records for a given NA, try the first one, then try the
next if the primary is down, etc. Although I can't find that defined
in the protocol document (but I've only scanned it so far, haven't
read the whole thing as of yet).
Anyway ... anyone done this? Am I on the right track, or completely
round the bend? :)
-mgs
_______________________________________________
handle-dev mailing list
handle-dev@cnri.reston.va.us
http://www.cnri.reston.va.us/mailman/listinfo/handle-dev
From handle-dev-admin@cnri.reston.va.us Wed Mar 26 07:39:06 2003
Return-Path: <handle-dev-admin@cnri.reston.va.us>
Received: from www1 by www1.cnri.reston.va.us (SMI-8.6/SMI-SVR4)
id HAA15182; Wed, 26 Mar 2003 07:33:25 -0500
Received: from ns.cnri.reston.va.us by www1.cnri.reston.va.us (SMI-8.6/SMI-SVR4)
id HAA15164; Wed, 26 Mar 2003 07:33:17 -0500
Received: from elslonexc001.epress.co.uk ([194.128.151.2])
by ns.cnri.reston.va.us with esmtp (Exim 4.12)
id 18yA6O-0002NU-00
for handle-dev@cnri.reston.va.us; Wed, 26 Mar 2003 07:33:56 -0500
Received: by elslonexc001.epress.co.uk with Internet Mail Service (5.5.2653.19)
id <HTWA1R7Z>; Wed, 26 Mar 2003 12:33:03 -0000
Message-ID: <54A600C436EA694581B93E4BD4D4788A06B7383B@elslonexc004.wins.epress.co.uk>
From: "Hammond, Tony (ELSLON)" <T.Hammond@elsevier.com>
To: "'handle-dev@cnri.reston.va.us'" <handle-dev@cnri.reston.va.us>
Date: Wed, 26 Mar 2003 12:33:07 -0000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
charset="iso-8859-1"
Subject: [handle-dev] OpenHandle
Sender: handle-dev-admin@cnri.reston.va.us
Errors-To: handle-dev-admin@cnri.reston.va.us
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Handle System Developers' Mailing List <handle-dev.cnri.reston.va.us>
X-BeenThere: handle-dev@cnri.reston.va.us
content-length: 2218
For something different - an OpenHandle servlet:
http://hdl.handle.net/1014/open
You should be able to try any legitimate handle, eg
* for Elsevier handle service (1014)
1014/oboe
1014/yads
1014/1
* for DOI handle service (10)
10.1006/geno
10.1016/S0888-7543(03)00007-7
10.1000/240
* for Global handle service (0) - the most interesting
0.serv/10
0.na/10
(service and naming authority handles for DOI)
Tony
A few rough edges here and there but anyway. What is it?
* A simple declarative means for a user to interact with handle
* Uses the ANSI/NISO OpenURL Framework to query handle and
receive back a structured XML response. (OpenURL drafts posted
at <http://library.caltech.edu/openurl/Public_Comments.htm>)
* Alternate responses could include resolution to stored URI,
service referral, etc
* OpenURL Framework allows contextual information to be bundled along
with the query/response messaging
* An RDF schema (using OWL) is defined for the ContextObject Format
of the OpenURL Framework
* A handle is given as an OpenURL Referent Identifier - the full
handle record is then returned as Referent Private Data
* An RDF Schema is defined for a handle record - supports the
predefined handle types HS_ADMIN, HS_SITE, HS_SERV, HS_PRIMARY,
HS_ALIAS, HS_VLIST
* Service data is passsed up as ServiceType Identifiers (for service
directives - eg authoritative query, etc) or as ServiceType
Metadata (service filtering - on index/type), and is passed back
as ServiceType Private Data (service messages)
* Controversial point - handle references are given compactly in
handle URIref form - eg <hdl://0.NA/1006#index 0> indicates
the handle value at index 200 for the handle 0.NA/1006
* Handle URIref form is how a handle client would address into a
handle resource - suggest that an alternate means of filtering
handle values is to use a fragment identifier syntax, eg
<#index=2;type=url> to return values of type URL at index 2
* In sum - Resource Description Framework over OpenURL Framework
_______________________________________________
handle-dev mailing list
handle-dev@cnri.reston.va.us
http://www.cnri.reston.va.us/mailman/listinfo/handle-dev