OpenReg for .NA

[Michael Koehne]

Moin Joe & Eberhard & OpenReg list,

> >  - does someone have turnkey OpenReg start/stop scripts for Debian ?
> We don't.

  postgreSQL is stopped before OpenReg is killed when I shutdown the 
  system. Is a normal sigterm ok to stop the OpenReg tasks or does the
  OpenReg system need some special shutdown command for msgbus.

  Whats the recommended way to start stop OpenReg ?

  1: direct /etc/inittab lines with stdout/stderr redirection to logfiles.
     crontab start of regular tasks
  2: /etc/init.d/openreg start/stop script
  3: semimanual start using screen / stop with sigterm on shutdown
   ( thats what I'm doing right now - but that looks not necessary,
     as the tasks dont read any human input from stdin - it worked
     to run the test, but does'nt look perfect ;)

> >  - does someone have some script line for write-zone&rndc combo ?
> We don't.
  perhaps someone on the list ?

  is write-zone+rndc the right way to publish zones, or should I better
  use write-zone as an example to develop some home grown bind update
  interface for OpenReg.

> >  - are there already some parsers for a RIPE like mailbot to XML/EPP ?
> Not to my knowledge.

  question to Eberhard :
  does the existing .na registry offer a mailbot interface ?

> >  - whats the recommended way to add zonecheck to OpenReg ?
> Not sure what you mean by that. If you want to check the existence of 
> an object, then the EPP check command may do what you want.

  idea is to integrate the zonecheck tool into OpenReg or into
  the web interface, to ensure that domains are connected when
  they are created.

> >  - howto extend OpenReg (e.g. i'm missing zone-c) to map existing 
> >data ?
> 
> Not sure what "zone-c" is. The schema used in OpenReg is based on the 
> various EPP DTDs. Introducing additional elements will involve 
> extensions to various EPP request and response documents, and hence 
> will require changes to the XML parser, the xaction module, the 
> database module and the schema. It will also require changes to EPP 
> clients.
> 
> You might consider migrating your data to the EPP-derived schema rather 
> than making extensions; this may prove simpler in the long run.

  I dont know if Namibia's name regirstry is more like US or like DE.

  In germany we have 'zone-c': The contact who is admininstrating the
  name servers of the zone. This does not not need to be the same handle
  as the tech-c or the admin-c. Modern entry's also have a mnt-c, who
  is allowed to change the record. The mnt-c becomes a registrant, if
  I map my german thinking to OpenReg, but the contact of the name
  server maintainer of the zone is lost, or did I miss the point ?

  So we might need to extend OpenReg to match local preconditions.
  Thats more a question to Eberhard, to collect those preconditions
  where Namibia differs from US. We might have the luck, that there
  are'nt any difference, so NA registry looks like .ORG and not like .DE.

> I'm not sure what you mean by this. OpenReg is designed to operate as a 
> "thick" registry; all metadata is stored in the registry as well as the 
> data required to build the zone. In general EPP is the interface 
> between the registry and registrars, and between the registry and the 
> public (via whois). There should never be a time that views of the 
> database need to be directly exported to external organisations.

> I am concerned that you think that such direct interaction is required. 
> Why do you need it?

  *hm* yes - one could do everything by EPP - but this would generate
  a lot of EPP/XML transactions to the OpenReg server. So my idea is
  to reduce those EPP/XML transactions by using EPP mainly for controller
  and read only postgreSQL for views. So in MVC (model view controller)
  user interface paradigma :

     web interface                                web interface
   controller view                     controller               view
      |        ^        replication       |                       ^
      v        |         extension        v                       |
   XML/EPP postgreSQL                  XML/EPP postgreSQL -> postgreSQL
   OpenReg	model                  OpenReg      model   replication

> I was not aware that we were talking about either of those things :-)
> We already run slave for .na. Running some kind of hot-standby registry 
> for NA would be a non-trivial exercise (or at least, one which would 
> need to be specified very carefully).

  warm standby would be easier as I'm using User Mode Linux - so a linux
  kernel is just a task and a device becomes a file, e.g. :

  bakunin:/opt/uml $ du morenga/morenga.*.img witbooi/witbooi.*.img
  282648  morenga/morenga.root.img
  38036   morenga/morenga.swap.img
  79968   morenga/morenga.work.img
  179608  witbooi/witbooi.root.img
  11852   witbooi/witbooi.swap.img
  bakunin:/opt/uml $ 

  so migration of systems becomes easier, as a cold backup is easy.
  Running rsync of non-database parts by crontab, and dbmirror from
  postgreSQL/contrib would make this copy a warm backup.

  But ISC::DB::Replication is flaged in the docs as half implemented
  half broken, iirc - I dont know if the docs or the code are wrong.
" Using a replication other than "none" is not supposed at this time. "
  [ lib/ISC/SRS/DB.pm ]

  so my advice : strip the replication code, to simplify OpenReg
  source (less features = less bugs) and delegate replication to
  dbmirror or rserver.

Bye Michael
-- 
  mailto:kraehe at copyleft.de             UNA:+.? 'CED+2+:::Linux:2.4.22'UNZ+1'
  http://www.xml-edifact.org/           CETERUM CENSEO WINDOWS ESSE DELENDAM