database migration questions

Jaromir Talir jaromir.talir at nic.cz
Fri Aug 26 17:31:05 CEST 2016


On Tue, 2016-08-23 at 23:10 +0200, Piotr Przybył wrote:
> On 23/08/16 19:26, Jaromir Talir wrote:
> > 
> > On Tue, 2016-08-23 at 16:23 +0200, Piotr Przybył wrote:
> > > 
> > > Hello cz.nic Team
> > > 
> > > I have a few questions related to database migration of FRED if
> > > you
> > > don't mind.
> > > 
> > > ====
> > > 
> > > When trying to download the latest sources from https://fred.nic.
> > > cz/p
> > > age/2904/download/#source I've
> > > realised, that they're not available. E.g. the latest migration
> > > scripts are available in
> > > fred-db*deb, but the tarball is not a corresponding one.
> > > 
> > > Could you please try to release latest sources in tarballs?
> > The last version I've uploaded on the website is 2.23. We have
> > released
> > small upgrades 2.24 and 2.25 but there is an issue with building
> > them
> > on Fedora 24 so I'v postponed next website update to 2.26 that will
> > be
> > available for recent Fedora system. I believe this will be
> > available
> > next week and I'll do website update immediately after that.
> What I had in mind precisely was that the page lists e.g.
> https://fred.nic.cz/files/fred/sources/fred-db-2.21.6.tar.gz, which
> doesn't contain
> notification_queue for instance. I discovered the SQL upgrade script
> installed by the package, but
> can't see it in sources tarball.

Yes, you are right. The reason is that deb packages in archive are
always newer than those published on the website. I believe this will
be in sync at the end of next week.

> > > 
> > > ====
> > > 
> > > Could you briefly describe what's the purpose of tables:
> > > 
> > >  contact_address
> > >  contact_address_history
> > > 
> > > As far I can tell after analysing the sources, these tables are
> > > populated by a functionality called
> > > from MojeID ( =your special NIC registrar to keep domain contacts
> > > defined at central level, not each
> > > registrar's level).
> > > 
> > There is a concept of single address in FRED. In our mojeID
> > registrar
> > we have a concept of multiple addresses (mail address, permanent
> > address,...). We decided to move this concept down into FRED and
> > implemented multiple addresses in FRED database. The next step was
> > supposed to be propagate this multiple address manipulation into
> > EPP
> > but this was postponed for a while. I believe we will get to his
> > soon.
> I believe this can make a fair usage in case of a registrar. E.g. you
> create an invoice with address
> A, print it and mail to address B. However, I'm not convinced that
> this makes sense in case of a
> registry which sends nothing at all and the only address is supposed
> to be "the legal address". I
> understand your situation and efforts with MojeId, I'm only wondering
> if other registries will
> utilise that. (Although 1 is still a valid case of having N choices.)
> 
> When it comes to changes addresses it might be nice for some to make
> the street not obligatory
> field, because there are countries in which the street address can be
> missing and it's perfectly
> fine. ;-)

Actually there is a meaning for registry. We send snail mail letter
with information about expiration some time before actual deleting
expired domain. Those letters are generated in PDF form regularly in
FRED. Those letters are now sent to "mailing" address and not "legal"
address if those two addresses differs.  

> > 
> > > 
> > > ====
> > > 
> > > What are the following tables for? Or: How the checks of contacts
> > > are
> > > working? Is is something
> > > related to checking if a contact's address fields are valid?
> > > 
> > >  contact_check
> > >  contact_check_history
> > >  contact_check_message_map
> > >  contact_check_object_state_request_map
> > >  contact_check_poll_message_map
> > >  contact_test_result
> > >  contact_test_result_history
> > >  contact_testsuite_map
> > >  enum_contact_check_status
> > >  enum_contact_check_status_localization
> > >  enum_contact_test
> > >  enum_contact_test_localization
> > >  enum_contact_test_status
> > >  enum_contact_test_status_localization
> > >  enum_contact_testsuite
> > >  enum_contact_testsuite_localization
> > That would be loooong explanation :) I believe this will be part of
> > new
> > documentation that Lena is working on. I talked about this briefly
> > during ICANN Techday 
> >  https://fred.nic.cz/files/fred/FRED-Validation.pdf slide 12,13
> > (selective contact validation). 
> So my guess that this is for contact/address validation was right. ;-
> )
> I'm not aware of the law you must obey/implement in your system.
> This seems to be like a policy forcing every contact to be nice and
> valid for all domains, even if
> they're not causing any trouble (like having sites which might be
> illegal in any part) and BEFORE
> they cause trouble.
> Are you forced to do that? Maybe you're not allowed to assume that
> each registrant/admin is honest
> and peaceful "until proven guilty", or even "accused"?

I guess that everybody want's to have correct data in system.
Incorrectness cause us troubles when we want to reach registrants. We
have registration rules where we say that contact data inserted into
registry should be correct.  So while we cannot easily enforce
correctness on input, we decided to check validity of data that we
already have in registry. 

Jaromir

> > 
> > 
> > > 
> > > ====
> > > 
> > > There's a table notification_queue. I can't find any usage of it
> > > (maybe because not all tarballs are
> > > up to date). What is it for?
> > I was going to mention this in mail summarizing changes in FRED-
> > 2.24,
> > 2.25 and 2.26. There is a new concept of asynchronous notification
> > in
> > FRED-2.25. In previous versions when registrar issued EPP command
> > that
> > involved sending notification email to registrant, EPP command was
> > waiting for notification subsystem to create this email.
> > Asynchronous
> > notification means that there is only small record in
> > notification_queue table that notification should be send and
> > asynchronous script will create this email in separate process. The
> > advantage is greater speed of EPP and stability because when
> > subsystem
> > for notification email creation is not available EPP is not locked.
> Oh yes, this makes a perfect sense.
> 
> > 
> > 
> > > 
> > > Do you replicate this table using Slony? (Because it has neither
> > > primary nor unique key.)
> > We are not using Slony anymore, we have changed to internal
> > streaming
> > replication about 4 years ago. Maybe that's why we missed to add
> > primary key. I'll ask my colleagues to add this primary key.
> > 
> 
> Thank you for your answers.
> 
> Best regards
> Piotr
> 
> _______________________________________________
> fred-users mailing list
> fred-users at lists.nic.cz
> https://lists.nic.cz/cgi-bin/mailman/listinfo/fred-users
-- 
Jaromir Talir
Technicky partner / Technical Fellow
-------------------------------------------
CZ.NIC, z.s.p.o.  --    .cz domain registry
Milesovska 5, 130 00 Praha 3, Czech Republic
mailto:jaromir.talir at nic.cz  http://nic.cz/
sip:jaromir.talir at nic.cz tel:+420.222745107
mob:+420.739632712       fax:+420.222745112
-------------------------------------------




More information about the fred-users mailing list