Building export scripts for nictool

[sjbauer]

Are there any preferred methods for building the scripts for exporting the data from nictool to a given server/service?  The reason I ask this is that it appears that many of the export scripts all take different routes for exporting the data.

There is a php script that exports the data for bind by going directly against the database, the export for tinydns appears to also go directly against the dns, and it appears that a person could use the API to build the export tool as well.  Is there a preferred method going forward that would compatibility with the system over time?

Also, is there any spot in the database where a person can check the version of the database schema?  (I haven't found anything by greping the sql files).

Thanks!

Steve

[matt]

Steve, so glad you asked!

The existing export scripts are a cobbled together mess, created by a variety of developers over numerous years to scratch the itch at the time, using the tools that provided the least resistance. The c++ exports that compile against the MySQL libs were useful in 2002 when CPUs were slow and it took a long time to dump 250,000 zones worth of data using DBI. Today, an all perl solution would be  simpler, smarter, and could perform just as well.

I'm not sure that exporting via the API would scale well. There aren't many NicTool sites with hundreds of thousands of domains, but quick exports is a feature I don't want to give away.

I thing the right approach to future proofing the export routines is to create a NicTool::Export class that makes it easy to write export scripts. The export class should contain logic that supports full dumps (IE, dump all the zone data for nsX) as well as incremental dumps (dump all zones on nsX with changes since 'timestamp'). With the export class handling all the database interaction, maintenance of export scripts in the future is done solely for the sake of the DNS server. Maintenance of the export class is the sole export related place to edit when schemes changes are made.

There is no place in the database for storing the schema version. Adding one is a darned good idea!

[matt]

The answer to your last question:

Code Select Expand

DROP TABLE IF EXISTS nt_options;
CREATE TABLE nt_options (
  option_id int(11) unsigned NOT NULL auto_increment,
  option_name varchar(64) NOT NULL default '',
  option_value text NOT NULL,
  PRIMARY KEY  (`option_id`),
  UNIQUE KEY `option_name` (`option_name`)
) DEFAULT CHARSET=utf8 COLLATE=utf8_bin;

INSERT INTO `nt_options` VALUES (1,'db_version','2.10');


[matt]

And the answer to your first question:

https://github.com/msimerson/NicTool/blob/master/server/lib/NicToolServer/Export.pm