Issues installing 2.22

[jwest]

Help

Our existing dns management tool is dying, so we're trying to get nictool up and running fairly urgently and running in to issues I'm hoping someone can shed light on.

1) The create_tables.pl script is broken - only if your dbhost isn't on the same machine as nictool server. It puts in the dbhost for the grant, which doesn't give access for the rest of the script. It also should probably have the default nictool db password null so it prompts for one, otherwise it forces a documented password as the dbuser pw. I hardcoded the grant dbhost to make sure it puts in the right host, but....

2) After the above change, create_tables.pl runs and all lines give a cheery "done" except one....

importing contents of 08_nt_zone.sql .. Warning: Using a password on the command line interface can be insecure.
ERROR 1071 (42000) at line 75: Specified key was too long; max key length is 767 bytes
FAILED(256)

When looking at 08_nt_zone.sql, it would appear this is the culprit:

CREATE TABLE nt_zone_record(
    nt_zone_record_id   INT UNSIGNED AUTO_INCREMENT NOT NULL,
    nt_zone_id          INT UNSIGNED NOT NULL,
    name                VARCHAR(255) NOT NULL,
    ttl                 INT UNSIGNED NOT NULL DEFAULT 0,
    description         VARCHAR(255),
    type_id             SMALLINT(2) UNSIGNED NOT NULL,
    address             VARCHAR(512) NOT NULL,
    weight              SMALLINT UNSIGNED,
    priority            SMALLINT UNSIGNED,
    other               VARCHAR(255),
    location            VARCHAR(2) DEFAULT NULL,
    timestamp           timestamp NULL DEFAULT NULL,
    deleted             TINYINT(1) UNSIGNED DEFAULT 0 NOT NULL,
    PRIMARY KEY (`nt_zone_record_id`),
    KEY `nt_zone_record_idx1` (`name`),
    KEY `nt_zone_record_idx2` (`address`),
    KEY `nt_zone_record_idx3` (`nt_zone_id`),
    KEY `nt_zone_record_idx4` (`deleted`)
    /* CONSTRAINT `nt_zone_record_ibfk_1` FOREIGN KEY (`nt_zone_id`) REFERENCES `nt_zone` (`nt_zone_id`) ON DELETE CASCADE ON UPDATE CASCADE */
) DEFAULT CHARSET=utf8 COLLATE=utf8_bin;

This I am not sure how to fix. Any advice?

Environment: FreeBSD 10, apache22, MySQL 5.6, nictool 2.22 (downloaded yesterday)

Thanks in advance for any help!

[jwest]

Yes, I know it's not the best form to reply to your own question.... but I suspect I have found the answer.

I'm guessing that nictool's schema assumes a myisam storage engine, where max key length is 1000 (innodb is 767). I tested create_tables.pl with 08_xxxx changed to specify "ENGINE=MYISAM" and it does import fine. I think I'll blow away the db and change mysqld's default storage engine to myisam.

It would be nice to be able to use innodb for all it's benefits, but I'll just blow away the nictool db & user, change the default storage engine to myisam, re-run create_tables.pl and be done with it

J

[matt]

Interesting.

Code Select Expand

mysql> show create table nt_zone_record\G
*************************** 1. row ***************************
       Table: nt_zone_record
Create Table: CREATE TABLE `nt_zone_record` (
  `nt_zone_record_id` int(10) unsigned NOT NULL AUTO_INCREMENT,
  `nt_zone_id` int(10) unsigned NOT NULL DEFAULT '0',
  `name` varchar(255) CHARACTER SET utf8 NOT NULL DEFAULT '',
  `ttl` int(10) unsigned NOT NULL DEFAULT '0',
  `description` varchar(255) CHARACTER SET utf8 DEFAULT NULL,
  `type_id` smallint(2) unsigned NOT NULL,
  `address` varchar(512) COLLATE utf8_bin NOT NULL DEFAULT '',
  `weight` smallint(5) unsigned DEFAULT '0',
  `priority` smallint(5) unsigned DEFAULT '0',
  `other` smallint(5) unsigned DEFAULT '0',
  `location` varchar(2) CHARACTER SET utf8 DEFAULT NULL,
  `timestamp` timestamp NULL DEFAULT NULL,
  `deleted` tinyint(1) unsigned NOT NULL DEFAULT '0',
  PRIMARY KEY (`nt_zone_record_id`),
  KEY `nt_zone_record_idx1` (`name`),
  KEY `nt_zone_record_idx2` (`address`(255)),
  KEY `nt_zone_record_idx3` (`nt_zone_id`),
  KEY `nt_zone_record_idx4` (`deleted`)
) ENGINE=InnoDB AUTO_INCREMENT=6982 DEFAULT CHARSET=utf8 COLLATE=utf8_bin

Mine is running on MySQL 5.5 and with InnoDB tables as you can see.  When I have time, I'll try a fresh NicTool install and see if I can't replicate this issue.

[jwest]

Odd. I'm using MySQL 5.6.14. The default dbengine in MySQL changed from myisam to innodb as of 5.5. But given your show table example is innodb... not sure what is going on. My import of 08_xxxx definitely failed on max key size, until I changed the table to myisam.

One additional question (but first, thanks a TON to whoever wrote up zone2nic.pl  ) .....

I'm following the online docs about exporting nictool zones to tinydns. I get pretty much all of it, one exception: The example shows on the nictool server configuring/enabling both tinydns as well as axfrdns in item #1. Can I assume that's just a typical example and tinydns is all that is needed (and really not tinydns but just setuidgid from that package) for the export process or is axfrdns really used by one of the nictool export scripts and must be configured too (ie. my nictools server isn't a dns server). Just want to be sure before I proceed.

Thanks again for all the help folks! Great to see the support level here!

Best,

J

[matt]

tinydns = UDP only. axfrdns = TCP only. 

Axfrdns isn't only for zone transfers. If you have any large DNS records (think DKIM keys, or large SPF records) that don't fit into a UDP packet, those get retried as TCP, so you definitely want axfrdns running.

[jwest]

Thanks a ton matt... just to doublecheck... my nictoolserver is only an apache host, not a dns server (nor db server). I was hoping to not install djbdns on it at all (just on the other machines that are nameservers). But it looks like when you set up exports from nictoolserver (on the nictoolserver) to the nameservers, djbdns has to be installed (as does tinydns and axfrdns) on the nictoolserver host as well. Odd, I thought that nictools exports went by rsync - not using axfrdns and/or tinydns. Hokay - proceeding. Thanks!

[matt]

Thanks a ton matt... just to doublecheck... my nictoolserver is only an apache host, not a dns server (nor db server). I was hoping to not install djbdns on it at all (just on the other machines that are nameservers). But it looks like when you set up exports from nictoolserver (on the nictoolserver) to the nameservers, djbdns has to be installed (as does tinydns and axfrdns) on the nictoolserver host as well.

If you are exporting to tinydns servers, then you do need djbdns installed on the NicTool server, but you don't need tinydns or axfrdns running on it.

Odd, I thought that nictools exports went by rsync - not using axfrdns and/or tinydns. Hokay - proceeding. Thanks!

Yes, the DNS data is 'pushed' out to the remote DNS servers with rsync. But, when using tinydns, this is done by building the 'data.cdb' file on the NicTool server and then pushing that file (via rsync) to the remote servers which *do* run tinydns and axfrdns.

[jwest]

Hopefully this will be my last question, thanks for the help thus far. I suspect my final issue is due to my lack of understanding of djbdns - I'm new not only to nictool but to tinydns as well (bind convert). I'm having trouble understanding a few things with regards to setting up exports from nictool to tinydns. I suspect most people have issues with the ssh key setup, but that's easy/OldHat to me. I think my confusion revolves around not understanding which host (nictool host vs. nameserver host) certain steps are to be done on.

I followed the excellent notes Matt crafted with regards to setting up djbdns on FreeBSD. Our nameservers are up and running with tinydns just fine. These notes point to using /usr/local/tinydns in your tinydns-conf command. Got that, makes sense, works.

However, the notes for setting up exports point to using /usr/local/tinydns/nsX (where nsX is your nameserver, ex: ns1, ns2, etc.). I am not sure if that is just on the nictools server (so that the data.cbd's for each nameserver are kept in separate folders) or if the ..../ns1 should be done on both the nictools and target nameservers. If the nsX subdirectory is just set up on the nictools server to keep the nameserver directories separate - then when defining nameservers inside nictools are the log and data directories specified as to the local directory structure (ie. /usr/local/tinydns/nsX) or the remote directory structure (ie. /usr/local/tinydns)?

Another point of confusion - the FreeBSD port of nictools automagically creates your tinydns user - and does so with a home directory of /nonexistent. That makes it pretty impossible to "su - tinydns" to do the ssh-keygen. Do I need to change the home directory (and probably shell) for those automatically created uid/gid's? I certainly know how to do that, just hesitating because I'm not sure if nictool is supposed to be set up that way.

Lastly - the "export nictool data to djbdns" document suggests using a "nictool" user for exports. But the run script created appears to hardcode "nt_nictool_export" or somesuch. Do I need to change the export user equate in the run script or is there something in the code that will "figure out" to use nictool user? I saw something in the code that attempts to figure this out - but the run script seems to be hard coded.

Sorry for all the questions, and sincerely appreciate any understanding that can be imparted.

Best,

J

[jwest]

I *think* I've muddled through the export setup process, my zones exported to all nameservers and those servers are responding to the queries with correct answers. I went the route of .../nictool/ns1 etc on the nictool server and just ..../tinydns on the nameservers. That appeared to be right "right way" in any case.

I do appear to have a mildly urgent issue though. Through the nictool client I can add/remove nameservers, and add/remove zones. However, I can not add RR's to a zone that was imported, nor can I add RR records to a new zone that I create. The web interface just reports "Failed to complete request". httpd-error.log reports:

DBD::mysql::st execute failed: Incorrect integer value: '' for column 'weight' at row 1 at /usr/local/lib/perl5/site_perl/5.16/DBIx/Simple.pm line 172.
exec_query called by NicToolServer::Zone::Record, 39
        INSERT INTO nt_zone_record(nt_zone_id, name, ttl, description, type_id, address, weight, priority, other) VALUES(??)
        13, test, 86400, , 1, 199.188.211.142, , ,
DBI error: Incorrect integer value: '' for column 'weight' at row 1 at /usr/local/lib/perl5/site_perl/5.16/NicToolServer.pm line 1586.
Client error: 600: : ModPerl::ROOT::ModPerl::Registry::u1_www_nictool_client_htdocs_zone_2ecgi:/u1/www/nictool/client/htdocs/zone.cgi:845 at /u1/www/nictool/client/lib/NicToolClient.pm line 1307.

The above error seems to reference "weight", but I was adding an A record, not an MX record. Previously to the above error I did try to add a MX record, but there wasn't any field to enter the weight :\

Any thoughts to get me running folks? Thanks in advance!

[matt]

A note on the MySQL 5.6 install error, 'Specified key was too long; max key length is 767 bytes'

MySQL is complaining about this column declaration:

Code Select Expand

address             VARCHAR(512) NOT NULL

Address is 512 chars long because of long DKIM signatures and SPF records. But it can also contain utf8 encoded IDN host names, and since utf8 chars can take up to 4 bytes each, a VARCHAR(512) could be up to 2048 bytes long. So MySQL throws an exception. Two things are required to work around this:

1. Use NicTool 2.23 (it sets ROWTYPE=COMPRESSED)
2. Edit your my.cnf and set:

Code Select Expand

[mysqld]
innodb_large_prefix=true
innodb_file_format=barracuda
innodb_file_per_table=true

[jwest]

That's awesome matt, makes good sense and I can implement that. Thanks!

Anyone have ideas on what is hopefully the list issue I'm having before going live with nictools? See below....

Through the nictool client I can add/remove nameservers, and add/remove zones. However, I can not add RR's to a zone that was imported, nor can I add RR records to a new zone that I create. The web interface just reports "Failed to complete request". httpd-error.log reports:

DBD::mysql::st execute failed: Incorrect integer value: '' for column 'weight' at row 1 at /usr/local/lib/perl5/site_perl/5.16/DBIx/Simple.pm line 172.
exec_query called by NicToolServer::Zone::Record, 39
        INSERT INTO nt_zone_record(nt_zone_id, name, ttl, description, type_id, address, weight, priority, other) VALUES(??)
        13, test, 86400, , 1, 199.188.211.142, , ,
DBI error: Incorrect integer value: '' for column 'weight' at row 1 at /usr/local/lib/perl5/site_perl/5.16/NicToolServer.pm line 1586.
Client error: 600: : ModPerl::ROOT::ModPerl::Registry::u1_www_nictool_client_htdocs_zone_2ecgi:/u1/www/nictool/client/htdocs/zone.cgi:845 at /u1/www/nictool/client/lib/NicToolClient.pm line 1307.

The above error seems to reference "weight", but I was adding an A record, not an MX record. Previously to the above error I did try to add a MX record, but there wasn't any field to enter the weight :\

Any thoughts to get me running folks? Thanks in advance!

[matt]

I think if you update to 2.23 it'll resolve the issue for you. I think this may have been fixed in commit a7bc4f7958641fdf7a716849df6d6e9a7199ade5.

Matt

[jwest]

the update again assumes your dbserver is localhost, not a huge deal.
upgrade script fails:

applying v 2.16 SQL updates
ALTER TABLE nt_perm ADD column usable_ns VARCHAR(50) AFTER self_write;
DBD::mysql::st execute failed: Duplicate column name 'usable_ns' at /usr/local/lib/perl5/site_perl/5.16/DBIx/Simple.pm line 172, <STDIN> line 1.
at sql/upgrade.pl line 59.

I think I'll just blow it all away and start over with 2.23.

[jwest]

Blew away 2.22, did a fresh install of 2.23.... sql/create_tables.pl gives:

Otherwise, hit return to continue...

DBD::mysql::db do failed: Table 'nictool.nt_user' doesn't exist at sql/create_tables.pl line 95, <STDIN> line 10.
DBD::mysql::db do failed: Table 'nictool.nt_user_log' doesn't exist at sql/create_tables.pl line 98, <STDIN> line 10.
DBD::mysql::db do failed: Table 'nictool.nt_user_global_log' doesn't exist at sql/create_tables.pl line 102, <STDIN> line 10.

Bug or did I do something wrong?