Egregoros · Phoenix Framework

Post

Remote status

Context

feld

@dvl was just setting up a fresh nsnotifyd and noticed that the nsnotify2git requires dig but the package doesn't depend on bind-tools

edit: and maybe I guess it should depend on git, idk...

dch

@dch@bsd.network remote

@feld @dvl It which git flavour? By leaving it off you can pick git-lite or a larger flavour

Dan Langille

@dvl@bsd.network remote

@dch @feld I'm using git-lite in my nsnotify instance.

There are no dependencies with nsnotifyd.

I'm using a custom script which updates a subversion repo: /usr/local/sbin/dns-notify

Looking here, we could add a nsnotifyd@git flavor to install git... (or git-lite?) and bind-tools

Perhaps nsnotifyd@git and nsnotifyd@git-lite

[20:24 nsnotify dvl /usr/local/bin] % grep svn nsnotify*

[20:24 nsnotify dvl /usr/local/bin] % grep git nsnotify*
nsnotify2git: git commit -q -m "$zone IN SOA $serial" $zone
nsnotify2git:logger -p daemon.notice -t nsnotify2git -s

[20:24 nsnotify dvl /usr/local/bin] % grep dig nsnotify*
nsnotify2git: dig +noall +answer +onesoa +multiline $master $zone axfr >$zone

feld

@feld@friedcheese.us remote

@dvl @dch I used to have a custom script for committing to a Fossil repo

anyway, I've found a bug in nsnotifyd. Very annoying. Running in debug mode I see this happen when a NOTIFY comes through:

nsnotifyd 37606 - - feld.me IN SOA ? Host name lookup failure

Host name lookup failure? What the heck????

running under truss so I can see what it's doing:

2765: socket(PF_INET,SOCK_DGRAM|SOCK_CLOEXEC,0) = 5 (0x5)
2765: connect(5,{ AF_INET 127.0.0.1:53 },16) = 0 (0x0)
2765: sendto(5,"|\M-]\0\0\0\^A\0\0\0\0\0\^A\^Eet"...,38,0,NULL,0) = 38 (0x26)
2765: poll({ 5/POLLRDNORM },1,3000) = 1 (0x1)
2765: recvfrom(5,0x8210e31f0,512,0,0x8210e2720,0x8210e271c) ERR#61 'Connection refused'
2765: close(5) = 0 (0x0)

Why is it trying to connect to 127.0.0.1:53 ? There's nothing running there. (but the NOTIFY does come from 127.0.0.1 because I'm listening with nsnotifyd on 127.0.0.1)

my powerdns is not listening on 127.0.0.1 intentionally as there was a local_unbound on there

even if I pass -s to specify the server that should be used for SOA refresh checks, doesn't change behavior...

I must be the only person that has ever tried to use it in this specific type of configuration.

feld

@feld@friedcheese.us remote

@dvl @dch yeah confirmed in the code, it's "correct" by some definitions of correct :)

* In response to a notify: Make a non-recursive query using the * server that notified us. RFC 1996 paragraph 3.11.

Dan Langille

@dvl@bsd.network remote

@feld @dch So nsnotifyd is sending itself a NOTIFY?

feld

@feld@friedcheese.us remote

@dvl @dch when nsnotifyd gets a NOTIFY, it tries to query the server that notified it to check the SOA of the domain it was notified about

But if you put nsnotifyd on localhost, and your DNS server is on the same host but is *not* listening on localhost, the NOTIFY appears to come from localhost... so it queries 127.0.0.1:53 and fails, then doesn't do an AXFR

Replying to @feld@friedcheese.us

Dan Langille

@dvl@bsd.network remote

@feld @dch AHH, same host, I see. I put nsnotifyd in a jail: nsnotify.

Replies

Replying to @dvl@bsd.network

feld

@feld@friedcheese.us remote

@dvl @dch I considered it but a different jail seemed heavy for such a tiny program. Especially as we can now start using service-jails. I really need to start investigating what is required to make the rc scripts Do The Right Thing so I can have these "service-jails" for lightweight apps which I'm not afraid to run on the host itself. Or just toss them all in a single jail and allow nested jails.

Replying to @feld@friedcheese.us

Dan Langille

@dvl@bsd.network remote

@feld @dch

I did like the service jails when I first read of them, however I have not used one yet.

Even though it's running just a tiny program, the jail puts it all "over there", contained, and easily moved.

What if nsnotifyd was listening on 127.1.0.10, for example? ... No, that's still the same host so it'll do the same thing.

Replying to @dvl@bsd.network

feld

@feld@friedcheese.us remote

@dvl @dch Personally I think everything should be in a service jail by default which essentially gets us the same experience as "cgroups" on Linux where we can be certain that when you stop a service all of its related PIDs (children, forks, etc) are correctly cleaned up as the jail is torn down. Simplifies a lot and we don't even need systemd.