On Thu, 22 Sep 2011, Dan Williams wrote: >> You properly talk to it via unbound-control, which uses SSL certs between >> it and the daemon. No need to re-write config files or send it weirdo >> signals. > > Ok, this part mystifies me. I assume it just has a TCP socket listening > that you talk to it on? Otherwise there's no point to using SSL on a > localhost where the socket would ideally be root-protected anyway. > Which would be a lot simpler for programmatic control. I'm a bit > concerned about fragility here, since if we require SSL certs to talk to > the daemon on localhost, that means you need to have a whole bunch of > other stuff set up (CA certificates, point the helper to the CA > certificates, somehow generating the client/server certificates when > unbound is installed, etc) before things will work, which typically > shouldn't be necessary talking to a local machine with both processes > running as root.
On first startup, the unbound init script generates all the certs for unbound-control to talk to unbound. See: yum install unbound service unbound start Then you can do things like: [paul@bofh paul]$ sudo unbound-control status version: 1.4.12 verbosity: 1 threads: 2 modules: 2 [ validator iterator ] uptime: 92870 seconds unbound (pid 2148) is running... and: [paul@bofh paul]$ sudo unbound-control forward off (using root hints) [paul@bofh paul]$ sudo unbound-control forward 193.110.157.136 193.110.157.2 ok [paul@bofh paul]$ sudo unbound-control forward 193.110.157.2 193.110.157.136 [paul@bofh paul]$ sudo unbound-control forward off ok > Ideally we can send all the information to unbound in *one* request (to > reduce possible race conditions) and get back meaningful status/error Let's clarify things a bit here. unbound should only be fed "known working" DNS resolvers. Currently, dnssec-triggerd is performing that check. If these DNS servers are broken, dnssec-triggerd checks if it can talk to the auth servers directly. Then it is ready to reconfigure unbound to: 1) use the resolvers (unbound-control forward 1.2.3.4 5.6.7.8) 2) use the auth servers directly (unbound-control forward off) 3) block unbound from doing any new lookups (unbound-control forward 127.0.0.127) 4) go insecure (prob implemented using 1) plus unbound-control set_option val-permissive-mode: yes) So either the NM plugin takes over that core from dnssec-triggerd, or it outsources this ti dnssec-triggerd. If the latter, then it talks to dnssec-triggerd in a similar way as you talk to unbound. Via a dnssec-triggerd-control command, which uses certs that are also generating on first service start of dnssec-triggerd > information too. That's often the problem with running helper binaries, > in that screen-scraping is a horrible, horrible way to return error > information. Ideally the helper binary returns a nice fine-grained exit > value and hopefully prints out well-formatted error messages to stderr? The output is pretty terse and simple? Not sure if unbound-control or dnssec-triggerd-control use nice different exit codes for failures, and if not, if Wouter would like to implement that :) Paul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
