[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