- Welcome to The Network People Support Forums.
Recent posts
#21
NicTool / Re: Question about nsd export
Last post by phantasm - October 06, 2015, 03:48:25 AMHello
I can't find how to export to NSD in proper way , when i run nt_export.pl it has update named.conf.nictool for BIND and NSD can't
load this configuration !!!!
I can't find how to export to NSD in proper way , when i run nt_export.pl it has update named.conf.nictool for BIND and NSD can't
load this configuration !!!!
#22
NicTool / Re: Is there any way to do int...
Last post by jrcarlsen - October 06, 2015, 02:58:36 AMThe ASCII representation works well when you only have a handful of internationalized domain names. Being located in Asia, we are seeing it being used more and more, and it does make it slower to manage when you have to go somewhere else to get the entries translated.
Anyway, I appreciated the feedback and I'll see if I can find a good way to work around it.
Anyway, I appreciated the feedback and I'll see if I can find a good way to work around it.
#23
NicTool / Re: Is there any way to do int...
Last post by matt - September 24, 2015, 12:11:46 PMSince NicTool 2.28 (2014.10.08), NicTool allows DNS names to be any ASCII printable character, which basically means that NicTool does support IDN, it just doesn't "help" you in any way.
It would be good to integrate something like https://www.npmjs.com/package/punycode into NicTool client so that when an IDN value is entered, it gets automatically converted to its ASCII representation.
It would be good to integrate something like https://www.npmjs.com/package/punycode into NicTool client so that when an IDN value is entered, it gets automatically converted to its ASCII representation.
#24
NicTool / Re: Is there any way to do int...
Last post by rainer_d - September 23, 2015, 01:53:03 AMCan't you just use the ASCII-representation?
We use that all the time. Even with an older version of NicTool.
It would be nice if the Web-Interface supported converting IDNs to their ASCII-representation, semi-automatically. But for us, that's not a deal-breaker.
We use that all the time. Even with an older version of NicTool.
It would be nice if the Web-Interface supported converting IDNs to their ASCII-representation, semi-automatically. But for us, that's not a deal-breaker.
#25
NicTool / Is there any way to do interna...
Last post by jrcarlsen - September 21, 2015, 05:05:54 AMWe are setting up a new DNS infrastructure based on NicTool, it looks like IDN is not supported is there any work around that works?
#26
Installation Issues / Re: Sentry v1.02 Installation ...
Last post by matt - July 23, 2015, 09:55:07 AMI have since released sentry 1.03, which rewrites the shebang at install time, with the full path to whichever version of perl is running it when you install.
#27
Installation Issues / Sentry v1.02 Installation Prob...
Last post by Ron Wingfield - July 12, 2015, 12:19:38 PMI'm trying to install sentry v1.02 into /usr/local/var/db/sentry. The OS is FreeBSD 10.1-RELEASE and Perl v5.22.0. I've downloaded sentry.pl, diff'ed it for local mods, set my $root_dir = '/usr/local/var/db/sentry'; and as simply instructed, run:
I've had the previous version of Sentry running successfully (I was very pleased with the performance!), but I upgraded the Perl version to 5.22 (deleted all old versions) -- after that upgrade, sentry quit capturing and black-listing abusers. For those of you reading this, Matt Simerson explained via eMail, that he has made some changes that involved path issues and now utilizes the /usr/bin/env utility . . .which is why I'm attempting to install the latest version of sentry.
*** Edits ***
Can anyone . . suggest what might (or might not) be in play here?
Well . . .my post on the FreeBSD Forum, /usr/bin/env perl - Failure when invoked by hosts.allow spawn rule describes what I have learned about the FreeBSD port of Perl 5.2+. In fact, there is not a problem with Sentry, per se, but rather with the interaction of the /usr/bin/env utility and (I think) the spawned or execl'd process (i.e., parent forks, spawns child, parent forgets about child and continues, child does it's thing and dies.) It's thing, of course, is invocation of the sentry.pl Perl script.
Problem is . . .I think, is that the env's path to ./perl is lost during the spawned fork. And, as far as I can tell, the failed call just drops off into the ether . . .no complaint, no error message, no log entry . . .just solid gone. Consequently, the sentry.pl script is never executed.
To resolve the problem (as least for now - I'm waiting on suggestions from the FreeBSD community) I had to hard-code the path to perl in the sentry.pl script to , i.e., #!/usr/local/bin/perl, rather than use #!/usr/bin/env perl.
Code Select
root@alpha:/usr/local/var/db/sentry # perl sentry.plI've had the previous version of Sentry running successfully (I was very pleased with the performance!), but I upgraded the Perl version to 5.22 (deleted all old versions) -- after that upgrade, sentry quit capturing and black-listing abusers. For those of you reading this, Matt Simerson explained via eMail, that he has made some changes that involved path issues and now utilizes the /usr/bin/env utility . . .which is why I'm attempting to install the latest version of sentry.
*** Edits ***
Can anyone . . suggest what might (or might not) be in play here?
Well . . .my post on the FreeBSD Forum, /usr/bin/env perl - Failure when invoked by hosts.allow spawn rule describes what I have learned about the FreeBSD port of Perl 5.2+. In fact, there is not a problem with Sentry, per se, but rather with the interaction of the /usr/bin/env utility and (I think) the spawned or execl'd process (i.e., parent forks, spawns child, parent forgets about child and continues, child does it's thing and dies.) It's thing, of course, is invocation of the sentry.pl Perl script.
Problem is . . .I think, is that the env's path to ./perl is lost during the spawned fork. And, as far as I can tell, the failed call just drops off into the ether . . .no complaint, no error message, no log entry . . .just solid gone. Consequently, the sentry.pl script is never executed.
To resolve the problem (as least for now - I'm waiting on suggestions from the FreeBSD community) I had to hard-code the path to perl in the sentry.pl script to , i.e., #!/usr/local/bin/perl, rather than use #!/usr/bin/env perl.
#28
NicTool / Re: Importing Zones etc from B...
Last post by matt - July 07, 2015, 10:00:23 AMnt_import.pl is included with NicTool and does a fine job of importing zone flies (extensively tested with 100's of thousands of zones).
Matt
Matt
#29
NicTool / Re: Importing Zones etc from B...
Last post by MHammett - June 07, 2015, 07:22:37 AMI see this thread is over 10 years old now. Is this still the preferred method for importing BIND zones? I have a system (IXP Manager) that outputs BIND zone files. My goal is to get these into a nictool managed environment.
#30
NicTool / Re: default zone record search...
Last post by matt - June 04, 2015, 02:31:38 PMThe search interface desperately needs a UI overhaul, with AJAX controls that let apply filters and see the results in Near Real Time. In the mean time, you'll have to hack on the .cgi files in NicToolClient to accomplish it.