nt_export_djb.pl patch

[LogicX]

the script seemingly chooses between a local ENV file called TINYDNS_DATA_DIR -- or tries to get the dir from the data path you set for a nameserver -- alas, it gets the server name instead?

http://mschroll.com/projects/nt_export_djb.pl.diff" target="_blank">small patch to fix it.

In other news, I neglected to mention that I modified the code to begin with to make it actually execute.  Here's http://mschroll.com/projects/nt_export_djb_LogicX_code_fix.pl.diff" target="_blank">that patch.

[matt]

Perhaps you need to alter your settings instead of altering the code?

[LogicX]

I do have those things set appropriately.
As best I could tell -- $ns->name is ns1.cadillac ---
and it should be $ns->datadir (the nice dir you have set)

atleast thats what kept occuring -- it would randomly write to and create a directory called datadir-ns2.imcc.ca for me, and put things in there from wherever I ran the script.

once I changed that variable, it then read the full path to the root folder, and put the correct things inside there.

[matt]

Maybe it wasn't "randomly" creating that directory and files, but purposefully creating them. Imagine running Nictool on one server, but tinydns is running on a different server. Since you will likely have more than one DNS server, and you will not be running NicToolServer on both of them, it is "normally" the case that the directory in which the data.cdb file needs to end up is not local on the box. Thus you don't want to write the export there immediately, but into a temporary datadir, and later in the export process you'll rsync it into place.

Matt

[LogicX]

okay -- good call.

So how can we best make the script support both situations?
both a local situation, and an rsync situation?
how about if the datadir is hostname@/path/
format -- then it creates only the data-ns.blah.com, and rsyncs
otherwise, it uses the full path?

(note, I haven't looked at the rsync portion of the code yet -- but likely will be having to implement this in the next 24 hours)

[matt]

LogicX wrote on Tue, 07 December 2004 17:22

okay -- good call. So how can we best make the script support both situations? both a local situation, and an rsync situation? how about if the datadir is hostname@/path/ format -- then it creates only the data-ns.blah.com, and rsyncs otherwise, it uses the full path? (note, I haven't looked at the rsync portion of the code yet -- but likely will be having to implement this in the next 24 hours)

Where on earth could if find the hostname to rsync to? Duh <smacks self in forehead>. What's this name field here?  Perhaps we could use that to determine the hostname? Oh wait, we already did.

Your idea, while sound, is not as flexible as the current implementation. For example, my nictool export processes do not run as the same uid/gid as the tinydns process. Thus, they do not have write permissions to tinydns directory. Thus, even if the tinydns instance was local, nictool still couldn't write to the data directory. This is A Good Thing.

Perhaps we could temper our enthusiasm for changing things until we understand them a bit better?

[LogicX]

matt wrote on Tue, 07 December 2004 17:29

LogicX wrote on Tue, 07 December 2004 17:22 okay -- good call. So how can we best make the script support both situations? both a local situation, and an rsync situation? how about if the datadir is hostname@/path/ format -- then it creates only the data-ns.blah.com, and rsyncs otherwise, it uses the full path? (note, I haven't looked at the rsync portion of the code yet -- but likely will be having to implement this in the next 24 hours) Where on earth could if find the hostname to rsync to? Duh <smacks self in forehead>. What's this name field here?  Perhaps we could use that to determine the hostname? Oh wait, we already did. Your idea, while sound, is not as flexible as the current implementation. For example, my nictool export processes do not run as the same uid/gid as the tinydns process. Thus, they do not have write permissions to tinydns directory. Thus, even if the tinydns instance was local, nictool still couldn't write to the data directory. This is A Good Thing. Perhaps we could temper our enthusiasm for changing things until we understand them a bit better?

hmm, well I don't believe thats going to work for me -- I don't run ssh on the same IP I do DNS -- so if my DNS is listed as name ns1.LogicX.net, and it tries to rsync to that address, the ssh will be rejected.

Sorry Matt, I'm not trying to be annoying, I'm just really excited by what you've got here -- it has the potential to relieve.. hours and hours of lame DNS management for much more powerful Database driven management -- I'm just very eager to hack away at the code until it does exactly the things I need.

Okay, so I see what you're saying about the export vs. the tinydns being able to run as separate users -- so then it would be safe to say that you suggest going the rsync route even on a local machine?



I'm working on what I've got here -- I've read a LOT of the documentation on nictool.com, in the various directories, and a lot of the code and READMEs, so I'm trying my best to grasp the entire schemantic of processes here that makes up the nictool solution

I'd love to help document things more, and submit back code changes, with your blessing of course.

[matt]

Hey, don't get me wrong, I'm all about having some other motivated folks using and helping evolve the software, but you can't just go willy nilly changing things because it suits your fancy. There's lots of other people using the code and when you make changes, you have to consider how others have implemented it and how what you're altering will impact them.

For example, I have six DNS servers I manage from my one NicTool installation. Only one of them runs locally on the box, so do I give a flip about whether it writes the file locally or rsync's it to the local server? It makes no difference to me, as I have to set up rsync for all the rest of the servers. This way is actually better too, as it enforces privilege separation.

I understand your point too, having it write locally would be convenient, but using one update mechanism (rsync) versus many (local file writes, rsync, something else) is more complex. Is it really that hard to run ssh on your DNS server's IP?  After all, it's way easier to secure SSHd than named-xfer.

Matt

[Nick Cockinos]

When you create a new name server, are the directorys created as specified (e.g. /usr/local/tinydns/ns1.example.com/), or is it necessary to run install.pl from /usr/local/www/NicToolServer/sys/djb/nameserver manually?

Nick