I wanted to be able to configure unbound along these lines:
trusted-keys-file: /etc/unbound/keys.d/*.key
[...]
include: /etc/unbound/conf.d/*.conf
I was a little confused about configlexer.c vs configlexer.lex, so I
just patched both of them. Note that the patch behaves the same as
my other old glob patch that ignores rather then fails an empty glob
(which Wouter rejected
The idea is that people should be able to drop in key files and
stub-zone / forward-zone statements in a directory, without needing
to modify unbound.conf itself. This is to better facilitate corporate
non-public zones. As we are looking at rolling out unbound on every
system, it is more important that the stock unbound.conf would not need
to be modified for everyone.
[ Quoting <paul@nohats.ca> in "[Unbound-users] Patch: wildcard for..." ]
I was a little confused about configlexer.c vs configlexer.lex, so I
Looks like configlexer.c is generated from the .lex file. My guess is
that it is included to avoid having to run bison (or whatever) when
people build it from source. (But I'm just guessing here).
The idea is that people should be able to drop in key files and
stub-zone / forward-zone statements in a directory, without needing
to modify unbound.conf itself. This is to better facilitate corporate
non-public zones. As we are looking at rolling out unbound on every
system, it is more important that the stock unbound.conf would not need
to be modified for everyone.
+1 to ".d" style configuration. but i think your patch is missing an
update to doc/unbound.conf.5.in
The split between conf.d and local.d is required because the current
unbound.conf parser cannot take local-data: statements outside of
the server: section. It would be nice if these could be merged, as
the difference might not be very obvious to end users.
but i think your patch is missing an update to doc/unbound.conf.5.in
--- unbound-1.4.18-orig/doc/unbound.conf.5.in 2012-08-02
03:26:14.000000000 -0400
+++ unbound-1.4.18/doc/unbound.conf.5.in 2012-09-26
13:31:33.651165651 -0400
@@ -71,7 +71,7 @@
.P
Files can be included using the
.B include:
-directive. It can appear anywhere, and takes a single filename as an argument.
+directive. It can appear anywhere, and accepts wildcards as an argument.
Processing continues as if the text from the included file was copied into
the config file at that point. If also using chroot, using full path names
for the included files works, relative pathnames for the included names work
Both patches work. I have built Unbound 1.4.18 on CentOS 6.3 and it
works. Thank you for this.
I use Unbound in a (very) dynamic environment. I use
unbound-control(8) to load zones and data when clients connect to the
network. I plan to save the local zones and local data to files so in
case I restart Unbound or if it crashes some how I have (quite) the
latest information. I plan to write a cron script to do this job on
each Unbound machine.
Do you think it would be useful if Unbound could do this by itself?
For example, whenever local-data gets inserted Unbound could dump it
to the disk. Maybe that's too expensive in terms of resources and
could slow down Unbound. Maybe an unbound-control(8) command that
takes the file name as an argument and dumps local data in that file.
Of course I can use unbound-control list_local_data and redirect the
output to a file on disk. But when I update a remote Unbound server
that's not so easy. Yes, I can use an ssh connection and run
unbound-control, but that's not so nice :).
For me, in my particular use case this would be very useful. Please
share your thoughts on this.
Both patches work. I have built Unbound 1.4.18 on CentOS 6.3 and it
works. Thank you for this.
Good, you can give karma to the upcoming unbound packages
I use Unbound in a (very) dynamic environment. I use
unbound-control(8) to load zones and data when clients connect to the
network. I plan to save the local zones and local data to files so in
case I restart Unbound or if it crashes some how I have (quite) the
latest information. I plan to write a cron script to do this job on
each Unbound machine.
You have to be careful with this, as some data is pushed into unbound on
demand. For instance, with openswan when you connect your VPN, the DNS
entries for the DOMAIN received by XAUTH is added to unbound using
unbound-control. It is also removed and flushed when the VPN tunnel goes
down. This kind of data should not be permanently added.
Of course I can use unbound-control list_local_data and redirect the
output to a file on disk. But when I update a remote Unbound server
that's not so easy. Yes, I can use an ssh connection and run
unbound-control, but that's not so nice :).
This is why I added /etc/unbound/local.d/ You should be able to populate
that directory using puppet or something similar.
I also added /etc/unbound/conf.d/ and /etc/unbound/keys.d/ where you can
put files in to be read by unbound on startup.
Both patches work. I have built Unbound 1.4.18 on CentOS 6.3 and
it works. Thank you for this.
Good, you can give karma to the upcoming unbound packages
I use Unbound in a (very) dynamic environment. I use
unbound-control(8) to load zones and data when clients connect to
the network. I plan to save the local zones and local data to
files so in case I restart Unbound or if it crashes some how I
have (quite) the latest information. I plan to write a cron
script to do this job on each Unbound machine.
You have to be careful with this, as some data is pushed into
unbound on demand. For instance, with openswan when you connect
your VPN, the DNS entries for the DOMAIN received by XAUTH is added
to unbound using unbound-control. It is also removed and flushed
when the VPN tunnel goes down. This kind of data should not be
permanently added.
The lexer file has a makefile rule to update the .c file for the
parser, but if you do not have flex/bison installed it then uses the
file that we shipped.
Of course I can use unbound-control list_local_data and redirect
the output to a file on disk. But when I update a remote Unbound
server that's not so easy. Yes, I can use an ssh connection and
run unbound-control, but that's not so nice :).
This is why I added /etc/unbound/local.d/ You should be able to
populate that directory using puppet or something similar.
I also added /etc/unbound/conf.d/ and /etc/unbound/keys.d/ where
you can put files in to be read by unbound on startup.
Thank you very much for the patch, I have applied it to svn trunk.
Small modification, call glob_free() on a glob error (to remove
partial glob results).
>
>> Both patches work. I have built Unbound 1.4.18 on CentOS 6.3 and
>> it works. Thank you for this.
>
> Good, you can give karma to the upcoming unbound packages
>
>> I use Unbound in a (very) dynamic environment. I use
>> unbound-control(8) to load zones and data when clients connect to
>> the network. I plan to save the local zones and local data to
>> files so in case I restart Unbound or if it crashes some how I
>> have (quite) the latest information. I plan to write a cron
>> script to do this job on each Unbound machine.
>
> You have to be careful with this, as some data is pushed into
> unbound on demand. For instance, with openswan when you connect
> your VPN, the DNS entries for the DOMAIN received by XAUTH is added
> to unbound using unbound-control. It is also removed and flushed
> when the VPN tunnel goes down. This kind of data should not be
> permanently added.
The lexer file has a makefile rule to update the .c file for the
parser, but if you do not have flex/bison installed it then uses the
file that we shipped.
>> Of course I can use unbound-control list_local_data and redirect
>> the output to a file on disk. But when I update a remote Unbound
>> server that's not so easy. Yes, I can use an ssh connection and
>> run unbound-control, but that's not so nice :).
>
> This is why I added /etc/unbound/local.d/ You should be able to
> populate that directory using puppet or something similar.
>
> I also added /etc/unbound/conf.d/ and /etc/unbound/keys.d/ where
> you can put files in to be read by unbound on startup.
Thank you very much for the patch, I have applied it to svn trunk.
Small modification, call glob_free() on a glob error (to remove
partial glob results).
Best regards,
Wouter
hi,
i've tried to add similar functionality to the unbound debian package by
adding this line to our default config:
include: "/etc/unbound/conf.d/*.conf"
and shipping an empty /etc/unbound/conf.d directory in the package for
users to place local config. unfortunately, without any filename
matches, glob() returns GLOB_NOMATCH and this causes config file parsing
to fail:
/etc/unbound/unbound.conf:17: error: cannot open include file '/etc/unbound/conf.d/*.conf': No such file or directory
read /etc/unbound/unbound.conf failed: 1 errors in configuration file
this goes away if i put at least one file that matches the glob into
that directory, but i don't want to have to ship a dummy empty
"do-not-remove.conf" file in the conf.d directory in order to get the
config to parse correctly (what if the user removes it?). could this
feature be updated so that a lack of glob matches is treated as
"success, but no files included" rather than failure to parse the
config? (possibly made contingent on the existence of the directory of
the dirname() of the wildcarded include: parameter.)
What I did was put commented out examples (example.com.conf,
example.comf.key) in those directories. Without those, the users will
have a hard time figuring out the syntax anyway.
eg I have example.com.conf:
# Example of an override of the "public DNS tree" with an "internal view"
# override, for example to add an internal-only corporate DNS zone.
>this goes away if i put at least one file that matches the glob into
>that directory, but i don't want to have to ship a dummy empty
>"do-not-remove.conf" file in the conf.d directory in order to get the
>config to parse correctly (what if the user removes it?). could this
>feature be updated so that a lack of glob matches is treated as
>"success, but no files included" rather than failure to parse the
>config? (possibly made contingent on the existence of the directory of
>the dirname() of the wildcarded include: parameter.)
What I did was put commented out examples (example.com.conf,
example.comf.key) in those directories. Without those, the users will
have a hard time figuring out the syntax anyway.
eg I have example.com.conf:
yes, that's exactly what i don't want to do. i just want a completely
empty /etc/unbound/conf.d directory to work, so i can simply put
something like this at the end of the default debian unbound.conf:
# Additional local configuration of unbound can be performed by creating
# files whose names end in ".conf" in the /etc/unbound/conf.d directory.
# See the the unbound.conf(5) man page for details about the "include:"
# directive.
include: "/etc/unbound/conf.d/*.conf"
and the users won't have any problem figuring out the syntax... ".d"
config directories are well-understood. after all, they're the ones
asking for the feature:
this goes away if i put at least one file that matches the glob
into that directory, but i don't want to have to ship a dummy
empty "do-not-remove.conf" file in the conf.d directory in
order to get the config to parse correctly (what if the user
removes it?). could this feature be updated so that a lack of
glob matches is treated as "success, but no files included"
rather than failure to parse the config? (possibly made
contingent on the existence of the directory of the dirname()
of the wildcarded include: parameter.)
What I did was put commented out examples (example.com.conf,
example.comf.key) in those directories. Without those, the users
will have a hard time figuring out the syntax anyway.
eg I have example.com.conf:
yes, that's exactly what i don't want to do. i just want a
completely empty /etc/unbound/conf.d directory to work, so i can
simply put something like this at the end of the default debian
unbound.conf:
# Additional local configuration of unbound can be performed by
creating # files whose names end in ".conf" in the
/etc/unbound/conf.d directory. # See the the unbound.conf(5) man
page for details about the "include:" # directive. include:
"/etc/unbound/conf.d/*.conf"
and the users won't have any problem figuring out the syntax...
".d" config directories are well-understood. after all, they're
the ones asking for the feature:
Makes sense, the patch is very simple, and should not make trouble for
Paul, right? It is also part of svn , if you want to use it right
away, this is the patch:
This is the patch:
- --- util/configlexer.lex (revision 2882)
+++ util/configlexer.lex (working copy)
@@ -107,6 +107,8 @@
if(r) {
/* some error */
globfree(&g);
+ if(r == GLOB_NOMATCH)
+ return; /* no matches for pattern */
config_start_include(filename); /* let
original deal with it */
return;
}
Makes sense, the patch is very simple, and should not make trouble for
Paul, right? It is also part of svn , if you want to use it right
away, this is the patch:
This is the patch:
--- util/configlexer.lex (revision 2882)
+++ util/configlexer.lex (working copy)
@@ -107,6 +107,8 @@
if(r) {
/* some error */
globfree(&g);
+ if(r == GLOB_NOMATCH)
+ return; /* no matches for pattern */
config_start_include(filename); /* let
original deal with it */
return;
}
hi, wouter:
thanks, this will make some debian users very happy. i'll test it when
i get a chance.
