Discussion:
[Opendnssec-user] opendnssec 2.0.0 released but no announcement?
Paul Wouters
2016-07-07 08:40:32 UTC
Permalink
I was notified there is now opendnssec-2.0.0 but I have not seen any
announcement of this yet?

It seems to have been correctly PGP signed 20 hours ago, so I think it
is a legitimate release? :)

Paul
Yuri Schaeffer
2016-07-07 08:54:05 UTC
Permalink
Hi Paul,

Yes it was released. I'm working on putting it up on www.opendnssec.org.
Everything should be sorted out during today.

//Yuri
Post by Paul Wouters
I was notified there is now opendnssec-2.0.0 but I have not seen any
announcement of this yet?
It seems to have been correctly PGP signed 20 hours ago, so I think it
is a legitimate release? :)
Paul
_______________________________________________
Opendnssec-user mailing list
https://lists.opendnssec.org/mailman/listinfo/opendnssec-user
Paul Wouters
2016-07-07 09:20:14 UTC
Permalink
Post by Yuri Schaeffer
Yes it was released. I'm working on putting it up on www.opendnssec.org.
Everything should be sorted out during today.
Thanks! Looking at preparing a package update, I noticed a few things:

A new directory /var/opendnssec/enforcer is needed? It tries chdir()
in there and failed for me. If this is just a rundir with no other
requirements, the better default location would be /var/run/ and it
should either use /var/run/<packagename>/ or /var/run/<service name>.
I also see this as a string in ods-signerd. It might just be that I
haven't found the appropriate configure option to tweak these.
Why isnt it using the already existing /var/run/opendnssec/ ?

I also noticed /var/opendnssec/tmp got renamed to /var/opendnssec/signer
in conf.xml. I am a little worried because this is specified in
conf.xml but also seems hardcoded in ods-enforcerd if I run strings on
ods-enforcerd. I haven't found yet where this gets configured or set
during build, so this might be perfectly fine.

And ods-signerd seems to want to bind to 0.0.0.0:53 for me, so on a
combination DNS server + opendnssec server that is not using XFR (like
my own nohats.ca setup), this will fail to start at all. I might need
to disable that feature in our standard configuration file, and let
users set it specifically to some IP if they want this. Possibly, a
better default would have been something on loopback?

Paul
Yuri Schaeffer
2016-07-08 08:21:51 UTC
Permalink
Hi Paul,

Thanks for your feedback.
Post by Paul Wouters
A new directory /var/opendnssec/enforcer is needed? It tries chdir()
in there and failed for me. If this is just a rundir with no other
requirements, the better default location would be /var/run/ and it
should either use /var/run/<packagename>/ or /var/run/<service name>.
I also see this as a string in ods-signerd. It might just be that I
haven't found the appropriate configure option to tweak these.
Why isnt it using the already existing /var/run/opendnssec/ ?
It's not entirely just a rundir. Therefore has no place in /var/run.
Admittedly the file locations and directory structure could use some
cleanup. There is an issue for this in our tracker and we will address
this in some future release.
Post by Paul Wouters
I also noticed /var/opendnssec/tmp got renamed to /var/opendnssec/signer
in conf.xml. I am a little worried because this is specified in
conf.xml but also seems hardcoded in ods-enforcerd if I run strings on
ods-enforcerd. I haven't found yet where this gets configured or set
during build, so this might be perfectly fine.
You did find the default value for that path. Both the signer and the
enforcer read the value from the conf.xml. All should be well.
Post by Paul Wouters
And ods-signerd seems to want to bind to 0.0.0.0:53 for me, so on a
combination DNS server + opendnssec server that is not using XFR (like
my own nohats.ca setup), this will fail to start at all. I might need
to disable that feature in our standard configuration file, and let
users set it specifically to some IP if they want this. Possibly, a
better default would have been something on loopback?
The signer has an optional <listener> section which your can
remove/change. This should be no different than earlier releases of the
1.4 branch.

Best regards,
Yuri

Loading...