RIPE Database dbupdate

Announcement date: 24 April, 2003

The Database Group at the RIPE NCC has been working on restructuring the dbupdate program. This is the part of the RIPE Whois server that processes update requests from users.

Benefits

The main goal has been to improve the acknowledgement messages that users receive from the RIPE Database and provide clearer error reporting and authorisation information. We have also been able to make the software easier to maintain and modify. This will reduce the time spent fixing bugs and adding new features.

Improvements include:

• A summary of results at the top of the acknowledgement, followed by a more detailed report.
• In the detailed report, failed updates appear at the beginning followed by successful updates. Anything not recognised as an object is listed at the end.
• Detailed authorisation information for each update, documenting which objects were checked. If the update was successful, the maintainers that allowed the update to be authorised correctly are listed. If the update failed, the maintainers for which authorisation is required are listed.
• Per-class information messages (allowing results to point the user to more specific help, e.g. IN-ADDR.ARPA help for failed domain objects).
• More accurate recognition of what an 'object' is, reducing the number of error messages reported on textual paragraphs within the update message.
• The subject line of an acknowledgement will only say "FAILED" if an error has been found. A 'No Operation' or a blank update message will be classed as "SUCCEEDED".
• Acknowledgement and notification messages use three dashes to seperate each 'section' relating to an object.

A page further explaining the new acknowledgements can be found here

The restructuring modified significant amounts of code. Therefore the testbed used for dbupdate was expanded to include comprehensive testing for all features of the program. The testbed is easy to run, and an entire regression test will be run when new features are added. When bugs are discovered, a new test can be quickly added to ensure that the fix was correct.

Another benefit of the new code is that it will be much easier for operators using the RIPE Whois server to adapt the software to match their own requirements. For example, organisations with different rules regarding authorising object updates can now write a plug-in to implement those rules, without having to look through any other code. The testbed will also be released, allowing custom changes to be tested with the same framework as the RIPE software.

Service Roll-out

The new dbupdate messages have a different format. Therefore a phased approach to introducing the new server has been taken. For a period we will use the new dbupdate in parallel with the old one. This will allow people using automated tools time to update their software.

PRE-MIGRATION
Before the new dbupdate was available.

auto-dbm-old@ripe.net	DOES NOT EXIST
auto-dbm@ripe.net	--> old dbupdate
auto-dbm-new@ripe.net	DOES NOT EXIST

DAY-X, Wednesday, 23 April, 2003
The new dbupdate is available but must be requested specifically.

auto-dbm-old@ripe.net	--> old dbupdate
auto-dbm@ripe.net	--> old dbupdate
auto-dbm-new@ripe.net	--> new dbupdate

DAY-Y, Wednesday, 7 May, 2003
The new dbupdate is the default but the old dbupdate may be requested specifically.

auto-dbm-old@ripe.net	--> old dbupdate
auto-dbm@ripe.net	--> new dbupdate
auto-dbm-new@ripe.net	--> new dbupdate

DAY-Z (POST-MIGRATION), Wednesday, 4 June, 2003
The old dbupdate is no longer available.

auto-dbm-old@ripe.net	DOES NOT EXIST
auto-dbm@ripe.net	--> new dbupdate
auto-dbm-new@ripe.net	DOES NOT EXIST

The Future

Once the new dbupdate is available, incremental changes to the software will be relatively easy to perform. The Database Group expects to produce a number of incremental improvements over the forthcoming months.

A new public release of the source code will be made available shortly.