[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Handle-info] Handle server mirror replication howto - questions



Responses below.

On 2012-12-13, at 09:25 , Eric Auer wrote:
> We'd ... like to start replication of Handles between your and our HS.
> How do we do this? I'm guessing you are using the Handle System's
> mechanisms for replication - so if I send our siteinfo.bin to you, can
> you add us to the replication as well..? Does this enable replication
> automatically or do we have to do something beyond that?
> And how does this work with the different prefixes? Our Handle Server
> is currently homed for OURPREFIX - can it carry other prefixes as well
> or do we need separate installations (I guess not...)

A single server can carry many prefixes.

However, as currently implemented, handle server replication assumes that the servers in a replication group will be identical.  There is no provision for a server replicating from several sources of distinct handles.  Is there demand for such a feature?

> As far as I remember, there was something about the config files on
> both sides, public keys and the root "nameserver" of HS for those
> prefixes that are to get mirrored? Looking at some etc. notes here,
> I see for the config.dct of the mirror:
> ... in the server_config section of the main { } section ...:


The mirror just needs to have this one key in its server_config:

> "replication_authentication" = "privatekey:301:0.NA/OURPREFIX"


This means that the mirror will authenticate to the primary as 301:0.NA/OURPREFIX.  That handle value should have a public key (which is also stored, unused, at replpub.bin).  The file replpriv.bin holds the private key used for the authentication.

> Also there are replpriv.bin and replpub.bin files and the sitebndl.zip
> contains replpub.bin, replid.txt, siteinfo.bin and contactdata.dct,
> all probably gathered by the Handle System install tool? The text file
> is apparently not really used, says: "300:0.NA/YOUR_NAMING_AUTHORITY".

Only replpriv.bin and siteinfo.bin are actually needed by the mirror handle server.

The mirror will also need a txnsrvsv.bin file.  This file is the siteinfo.bin of the primary server, and is used by the mirror to locate and authenticate the primary.

> The mirror also has the to-be-mirrored prefix homed, but that can be
> done with the usual tools and methods provided for homing, I assume?

In fact, which prefixes are homed will be determined by the primary server and replicated to the mirror.  No action is required.

> On the server side, I see the following in config.dct:

What is needed on the primary side is the "replication_admins" key.  It must contain the handle value reference used as the "replication_authentication" of the mirror.  So:

"replication_admins" = (
"301:0.NA/OURPREFIX"
)

The originally posted config snippet had 300:0.NA/OURPREFIX instead, so the mirror would be forbidden to replicate.

> So apparently owning the private key for the 300:0.NA/OURPREFIX public
> key stored in the root 'name' server (naming authority) grants rights
> to 1. admin the server 2. receive data for mirroring and 3. dump all
> data for backup purposes, but this could also be split into different
> accounts? In particular, you will often have a separation between admin
> and mirror credentials, so mirrors can only 'login' to mirror data...

Yes, server_admins and replication_admins (and backup_admins) can all be separate identities.

Best,
Robert
_______________________________________________
Handle-Info mailing list
Handle-Info@cnri.reston.va.us
http://www.handle.net/mailman/listinfo/handle-info