[Dachs-support] Serving different authorities from the same DaCHS server

Markus Demleitner msdemlei at ari.uni-heidelberg.de
Tue May 11 11:18:47 CEST 2021


Hi Yannick,

On Tue, May 11, 2021 at 10:38:29AM +0200, Yannick Roehlly wrote:
> Is it possible to serve data from different VO authorities from a
> single DaCHS instance?

Yes, though you'll have to manage the identifiers of the non-primary
authority manually (at least for now; I'm open to ideas on
streamlining things).  For the record (and perhaps later inclusion to
the documentation, let me discuss how you can do that, and I'd
recommend doing that over what I think you are planning right now).

What is in [ivoa]authority is the primary authority, which is
used to compute the identifier meta item.
You can, however, override this in your RD, typically
in a service, table, or resRec element (though it could is in
resource as well):

  <service...>
    <meta name="identifier">ivo://auth.example/something/unique</meta>
  </service>

DaCHS will not let you publish this, though, until you claim the
authority.  You do that in the registry service declared in the
userconfig.  Unless you've already overridden it, see

http://docs.g-vo.org/DaCHS/tutorial.html#the-userconfig-rd

Once you've put it into your /var/gavo/etc/userconfig.rd , you'll see
something like

  <meta name="managedAuthority">\getConfig{ivoa}{authority}</meta>

-- this is for the primary authority.  Add

  <meta name="managedAuthority">auth.example</meta>

elements for all your authorities.  That tells the registry engine
it's ok for it to serve records from these authorities.  Don't forget
to dachs pub //services after you've changed this.

That's still not quite enough, though, because authorities in the VO
have a bit of extra metadata, and you have to create a resource
record to reflect those (and announce to the rest of the VO that the
authority belongs to you).  The best way to do that is to have an RD
somewhere and publish it; see
http://svn.ari.uni-heidelberg.de/svn/gavo/hdinputs/tutreg/gavo_edu_auth.rd
for an example.

> We plan to have one DaCHS installation where we set up different
> services.  In the EuroVO registry, we set up different authorities
> and add to them services pointing to the corresponding service on
> this single DaCHS instance (each service being associated to only
> one authority).
> 
> Is this OK?

Well, you *can* do it like that and fetch the resource records from
the service info.  But I wouldn't, because the records at EuroVO need
to be updated manually, and you'll almost certainly forget to do that
at some point; also, you're already running a publishing registry (or
so I think), and so spreading the effort seems creating work that
seems a bit dispensable.

If you still do it like that, just never run dachs pub on the
respective RDs and you'll be fine.

A word of warning: In case you decide to follow my advice and manage
the authorities yourself, and if the authorities already exist in
EuroVO, you'll have to migrate the authorities, which then needs
to be synchronised with the EuroVO registry.  Authority migrations
have been done before, but not very often, so if you decide to go
this way, holler and I'll try to moderate.

> Regarding DaCHS, how can I deal with different meta informations?
> For now, I use the defaultmeta.txt and, for instance, DaCHS uses
> the publisherID defined in it.  But if I have several publisherID,
> is it possible to define it in the RD file for each resource?

Yes.  You can override every piece of metadata in every level of the
inheritance hierarchy:
http://docs.g-vo.org/DaCHS/ref.html#meta-inheritance

The only possible pitfall is that metadata on different levels will
not mix; for instance, if there is a contact.name on the service
level, it will shadow any contact meta in the RD or in defaultmeta.
That sounds trivial, but it means that, for instance,
a global contact.address will not be visible for the service.

       -- Markus


More information about the Dachs-support mailing list