Zitat von Paul Wouters <[email protected]>:
On Mon, 18 Jul 2011, [email protected] wrote:
I thought that one have to explicit set --with-ldns-builtin to get
this behavior??
That was the case after I managed to accidentally ship a version of unbound
in Fedora that used a linked ldns because the build env didnt have ldns-devel
installed. So yes it does, but it caused problems in the past, and makes
maintainers nervous.
Also, not every unbound requires a new ldns.
But it is no error to use latest unbound with latest ldns, no?
But where do you draw the line? Do you also recompile libevent every yime you
recompile unbound? If not, why are you doing so for ldns but not libevent?
If unbound HAS to use a certain new minimal version of ldns, that is you HAVE
to upgrade, then its ./configure should catch it for you and alert
you to upgrade.
From my point of view libevent is more kernel related, while libldns
as said was and is not used on any of my systems beside from unbound,
but as always YMMV.
And of course, people use ldns and ldns-python without unbound.
For sure, but many people use unbound without anything other using
ldns so an option to simply built unbound with static linked ldns
would be nice to have. A normal update from source with unbound was
far below an hour, with 1.4.12 i#m struggling since two days :-(
Why did it take 2 days?
wget http://www.nlnetlabs.nl/downloads/ldns-1.6.10.tar.gz
tar zxf ldns-1.6.10.tar.gz
cd ldns-1.6.10
./configure --disable-rpath --disable-static --with-sha2 --with-pyldns
make
make doc
make install
make install-doc
ldconfig
One system (dev) had by accident installed libldns (but no dev-header)
from OS distribution. After fiddling around to get unbound compile
with a downloaded libldns i end up with a version finally using the
old OS provided. On the second system compiling it the same way worked
but starting unbound failed because of missing libldns. Next system
with Ubuntu 8.04 LTS has libldns installed in version 1.2.1 and it
took some hours to find out that it was not needed so can be replaced.
I choose to use unbound from source in the first place because it was
really easy to compile and run on nearly any system, but with this
split it isn't any more IMHO.
note that your old method also introduces problems
1) if your other app wants to use ldns (or ldns-python or drill)
which ldns is
it using?
The OS provided because this will be installed from the packages i guess
2) where are the ldns headers to compile against? If you find them
are those the
system ldns ones or the ones used by unbound?
As said it were the one from source, but more of an accident.
3) if there is an ldns issue in version 1.6.X, how are you going to find out
which ldns version unbound uses? (sometimes it even shipped
non-full-release
code of ldns inside the unbound tar ball)
If it is shipped with unbound there will be a new unbound "release" in
this case, no?
4) how would a less knowledgable sysadmin who did not compile the
unbound on a
system ever know there is a vulnerable ldns statically linked
into some binaries?
It does not know today either at least on Ubuntu because its coming
from "universe" which has no support guarantie for security updates.
This was an additional reason why i compile unbound from source.
It is really much better from a sysadmin point of view to clearly
separate the two.
Are there at least security notifications on the unbound list or do i
have to subscribe to yet-another-list?
It might be a little more work sometimes, but it is for the best :)
It is your project and your decision, so nothing more to say from my
point of view.
Many Thanks
Andreas
_______________________________________________
Unbound-users mailing list
[email protected]
http://unbound.nlnetlabs.nl/mailman/listinfo/unbound-users
