From owner-dnssec-trac at kirei.se Mon Aug 2 18:30:55 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Mon, 02 Aug 2010 18:30:55 -0000 Subject: [Opendnssec-develop] [OpenDNSSEC] #164: rfc1982 notimp in auditor? Message-ID: <061.513972913cee7babe275dbb0cbc05d74@kirei.se> #164: rfc1982 notimp in auditor? ------------------------------------+--------------------------------------- Reporter: robert@? | Owner: alex Type: defect | Status: new Priority: major | Component: Auditor Version: trunk | Keywords: ------------------------------------+--------------------------------------- I tried rolling serials first from YYYYMMDDnn to +2^31-86400 and then to time(). However, then auditor had a problem with that. To make it more fun it seems to complain about a "random" serial number (not any of the latest in the series) from when I last did any sysadmin on the signer-machine. I "solved" this by editing $PREFIX/var/opendnssec/tmp/tracker/dk I'm running trunk rev 3585. -- Ticket URL: OpenDNSSEC OpenDNSSEC From marco.davids at sidn.nl Tue Aug 3 09:05:20 2010 From: marco.davids at sidn.nl (Marco Davids (SIDN)) Date: Tue, 3 Aug 2010 11:05:20 +0200 Subject: [Opendnssec-develop] TTL of NSEC3PARAM record? Message-ID: <4C57DBD0.5060701@sidn.nl> (re-post from opendnssec-users list - sorry for the duplicates) Hi, Can anyone tell me if and how I can influence the TTL of the NSEC3PARAM record? OpenDNSSEC sets it to 3600 seconds. Why? Is this an LDNS default perhaps? If this cannot be changed, would it be an idea to make in configurable? Thanks. Regards, -- Marco From roy at nominet.org.uk Tue Aug 3 09:11:57 2010 From: roy at nominet.org.uk (Roy Arends) Date: Tue, 3 Aug 2010 09:11:57 +0000 Subject: [Opendnssec-develop] TTL of NSEC3PARAM record? In-Reply-To: <4C57DBD0.5060701@sidn.nl> References: <4C57DBD0.5060701@sidn.nl> Message-ID: <7BF80BAD-0BEE-4DC3-AE8F-FD1035268CBB@nominet.org.uk> On Aug 3, 2010, at 10:05 AM, Marco Davids (SIDN) wrote: > (re-post from opendnssec-users list - sorry for the duplicates) > > Hi, > > Can anyone tell me if and how I can influence the TTL of the NSEC3PARAM > record? > > OpenDNSSEC sets it to 3600 seconds. Why? Is this an LDNS default > perhaps? If this cannot be changed, would it be an idea to make in > configurable? Marco, I do not know if this is configurable or not, but I do have some insights on the purpose of this record. This record is there to indicate to other authoritative nameservers what parameters it should use to find the appropriate NSEC3 records to build a response. The NSEC3-param record has no utility in resolvers, validators, caches, etc. Hence, the TTL can be an arbitrary value that should not have an impact in processing. Hope this helps. Apologies for not been able to directly answer the question. Roy From owner-dnssec-trac at kirei.se Tue Aug 3 09:56:07 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Tue, 03 Aug 2010 09:56:07 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #164: rfc1982 notimp in auditor? In-Reply-To: <061.513972913cee7babe275dbb0cbc05d74@kirei.se> References: <061.513972913cee7babe275dbb0cbc05d74@kirei.se> Message-ID: <070.fb00bef962e8537a94dbb0502bfc6281@kirei.se> #164: rfc1982 notimp in auditor? ------------------------------------+--------------------------------------- Reporter: robert@? | Owner: alex Type: defect | Status: new Priority: major | Component: Auditor Version: trunk | Keywords: ------------------------------------+--------------------------------------- Comment(by alex): Hi - Could you please include the output from the auditor? Are you running the auditor automatically, or is it only run manually? Thanks, Alex. -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Tue Aug 3 12:17:41 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Tue, 03 Aug 2010 12:17:41 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #164: rfc1982 notimp in auditor? In-Reply-To: <061.513972913cee7babe275dbb0cbc05d74@kirei.se> References: <061.513972913cee7babe275dbb0cbc05d74@kirei.se> Message-ID: <070.ab9235206e06b397c591344170ad3ece@kirei.se> #164: rfc1982 notimp in auditor? ------------------------------------+--------------------------------------- Reporter: robert@? | Owner: alex Type: defect | Status: closed Priority: major | Component: Auditor Version: trunk | Resolution: fixed Keywords: | ------------------------------------+--------------------------------------- Changes (by alex): * status: new => closed * resolution: => fixed Comment: Hi - This should be fixed in svn r3640. Please let me know if you still have any issues. Thanks for the bug report! Alex. -- Ticket URL: OpenDNSSEC OpenDNSSEC From rickard.bellgrim at iis.se Wed Aug 4 07:08:12 2010 From: rickard.bellgrim at iis.se (Rickard Bellgrim) Date: Wed, 4 Aug 2010 09:08:12 +0200 Subject: [Opendnssec-develop] Next OpenDNSSEC meeting Message-ID: <887DE3F8-9F8F-4943-B7C6-4A3C71279734@iis.se> Hi We suggested that we should have the next telephone meeting on 11 August 2010, 14-15 CEST, 13-14 BST. // Rickard From owner-dnssec-trac at kirei.se Wed Aug 4 07:15:24 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Wed, 04 Aug 2010 07:15:24 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #157: Desire ManualKeyGeneration per key-type and/or policy In-Reply-To: <061.17b2100ee642e29fa4aaa8797e3982ba@kirei.se> References: <061.17b2100ee642e29fa4aaa8797e3982ba@kirei.se> Message-ID: <070.86f2ef36251606eb0a7c23a0c7b6a5c7@kirei.se> #157: Desire ManualKeyGeneration per key-type and/or policy ------------------------------------+--------------------------------------- Reporter: robert@? | Owner: sion Type: enhancement | Status: new Priority: minor | Component: Enforcer Version: trunk | Keywords: ManualKeyGeneration ------------------------------------+--------------------------------------- Comment(by rb): Yes, currently the ManualKeyGeneration can only be set for the system and not individual zones/policies/key types. Could you describe your use case a little bit more? E.g. that you have the .dk zone where you generate keys for ten years, and then want to sign other zones using the same system. But these zones can have their keys generated on the fly. If you forget that you need new keys after 10 years then the ManualKeyGeneration will stop OpenDNSSEC to automatically generate new ones for you. The ManualKeyGeneration can be skipped if you make sure to remember that you need to take some actions after e.g. 9 years. It would be cleaner to have the ManualKeyGeneration on another level. But what level would that be? Zone / Policy / Key type / Repository ? -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Wed Aug 4 09:25:29 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Wed, 04 Aug 2010 09:25:29 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #163: Support for importing bind private keys v1.3 In-Reply-To: <054.ff75bb7132b29a4ac0c11554e6f9119e@kirei.se> References: <054.ff75bb7132b29a4ac0c11554e6f9119e@kirei.se> Message-ID: <063.fc6beecc49c1cabac17a4af18f27bbaa@kirei.se> #163: Support for importing bind private keys v1.3 -----------------------------+---------------------------------------------- Reporter: ruben@? | Owner: rb Type: enhancement | Status: closed Priority: minor | Component: SoftHSM Version: trunk | Resolution: fixed Keywords: | -----------------------------+---------------------------------------------- Changes (by rb): * status: accepted => closed * resolution: => fixed Comment: The code is now included in r3642 -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Wed Aug 4 14:13:43 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Wed, 04 Aug 2010 14:13:43 -0000 Subject: [Opendnssec-develop] [OpenDNSSEC] #165: Patch: Incrementing SOA in the signer engine Message-ID: <045.cba97411d28ff551e27408ffcb86a134@kirei.se> #165: Patch: Incrementing SOA in the signer engine --------------------+------------------------------------------------------- Reporter: vanrein | Owner: matthijs Type: defect | Status: new Priority: major | Component: Signer Version: 1.1.1 | Keywords: --------------------+------------------------------------------------------- When we decide to sign a domain, it stops being published directly, and instead goes through OpenDNSSEC. If this happens, several of the SOA numbering disciplines for the signer use a SOA value that is not higher than the value for the unsigned zone. As a result, the authoritative name servers don't pick up on the fact that OpenDNSSEC signed the zone. The attached patch fixes the SOA numbering discipline in such a way that the outgoing SOA will always be more than the incoming, to circumvent this problem. A similar problem exists when going back from signed to unsigned, but that cannot be resolved in OpenDNSSEC. -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Wed Aug 4 14:35:04 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Wed, 04 Aug 2010 14:35:04 -0000 Subject: [Opendnssec-develop] [OpenDNSSEC] #166: Patch: Correct exit value from signer Message-ID: <045.4a0e969cce61c7287fef89d2d3a07f33@kirei.se> #166: Patch: Correct exit value from signer --------------------+------------------------------------------------------- Reporter: vanrein | Owner: matthijs Type: defect | Status: new Priority: trivial | Component: Signer Version: 1.1.1 | Keywords: --------------------+------------------------------------------------------- The zone_fetcher can kick the signer, and when it does, it invariably (and usually incorrectly) reports "zone fetcher could not kick the signer engine to sign zone". This is only a slight irregularity, and it is easily fixed with the patch attached. The patch ensures the correct return value from ods-signer. -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Wed Aug 4 14:45:11 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Wed, 04 Aug 2010 14:45:11 -0000 Subject: [Opendnssec-develop] [OpenDNSSEC] #167: Patch: Zone Fetcher processes updated zonelist.xml Message-ID: <045.173c8a383d3f715c598dd948614b04a3@kirei.se> #167: Patch: Zone Fetcher processes updated zonelist.xml --------------------+------------------------------------------------------- Reporter: vanrein | Owner: matthijs Type: defect | Status: new Priority: major | Component: Unknown Version: 1.1.1 | Keywords: --------------------+------------------------------------------------------- The zone_fetcher utility does not yet support changes to the zonelist.xml file. The attached patch makes it able to do so, if sent a SIGUSR1. The SIGUSR1 signal would normally be sent from the signer, after it has processed an "update" or "update XXX" command. That has also been added in this patch. The rest is up to the KASP Enforcer, which already invokes update on the signer. To be able to handle very long lists of zones, recursive code for freeing zonelists has also been replaced with a linked-list alternative. -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Wed Aug 4 14:48:27 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Wed, 04 Aug 2010 14:48:27 -0000 Subject: [Opendnssec-develop] [OpenDNSSEC] #168: Patch: ods-control with tightened control Message-ID: <045.2ab21e01d5a4fa83260cc4026b7a8205@kirei.se> #168: Patch: ods-control with tightened control ------------------------+--------------------------------------------------- Reporter: vanrein | Owner: rb Type: enhancement | Status: new Priority: minor | Component: Unknown Version: 1.1.1 | Keywords: ------------------------+--------------------------------------------------- The script ods-control can cause problems if it is used to start/stop OpenDNSSEC too quickly. Also, it is a suitable place for enforcer subcommands start/stop/notify. The attached patch makes that update. We propose its inclusion in forthcoming versions of OpenDNSSEC. -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Thu Aug 5 12:34:57 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Thu, 05 Aug 2010 12:34:57 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #165: Patch: Incrementing SOA in the signer engine In-Reply-To: <045.cba97411d28ff551e27408ffcb86a134@kirei.se> References: <045.cba97411d28ff551e27408ffcb86a134@kirei.se> Message-ID: <054.66d365bcc03037f905d0d5afc4225d1f@kirei.se> #165: Patch: Incrementing SOA in the signer engine --------------------+------------------------------------------------------- Reporter: vanrein | Owner: matthijs Type: defect | Status: closed Priority: major | Component: Signer Version: 1.1.1 | Resolution: fixed Keywords: | --------------------+------------------------------------------------------- Changes (by matthijs): * status: new => closed * resolution: => fixed Comment: I understand the problem, it is there once you switch to OpenDNSSEC. So, it's a one-time problem. I acknowledge it is an issue, but I also think it has a side effect. It can screw up the soa serial policy. The output serial cannot be guaranteed to be unixtime, counter or datecounter anymore, because the input serial is an arbitrary value. Not sure if this side effect is a problem for other (future) users. Technically, it doesn't break anything. Policy wise, it may. Nevertheless, I think it is more important that it does not break technically when you switch to OpenDNSSEC, so I have applied the patch in r3650. Thanks! -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Thu Aug 5 12:55:27 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Thu, 05 Aug 2010 12:55:27 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #166: Patch: Correct exit value from signer In-Reply-To: <045.4a0e969cce61c7287fef89d2d3a07f33@kirei.se> References: <045.4a0e969cce61c7287fef89d2d3a07f33@kirei.se> Message-ID: <054.6fec4e63003dc019a87311f2a49342bf@kirei.se> #166: Patch: Correct exit value from signer --------------------+------------------------------------------------------- Reporter: vanrein | Owner: matthijs Type: defect | Status: new Priority: trivial | Component: Signer Version: 1.1.1 | Keywords: --------------------+------------------------------------------------------- Comment(by matthijs): shouldn't the raise in the patch be 'pass'? (like in Engine.py.in) -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Thu Aug 5 14:05:08 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Thu, 05 Aug 2010 14:05:08 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #167: Patch: Zone Fetcher processes updated zonelist.xml In-Reply-To: <045.173c8a383d3f715c598dd948614b04a3@kirei.se> References: <045.173c8a383d3f715c598dd948614b04a3@kirei.se> Message-ID: <054.3e3aa34e76c9960f647655e174dfc406@kirei.se> #167: Patch: Zone Fetcher processes updated zonelist.xml --------------------+------------------------------------------------------- Reporter: vanrein | Owner: matthijs Type: defect | Status: closed Priority: major | Component: Unknown Version: 1.1.1 | Resolution: fixed Keywords: | --------------------+------------------------------------------------------- Changes (by matthijs): * status: new => closed * resolution: => fixed -- Ticket URL: OpenDNSSEC OpenDNSSEC From rick at goldmoney.com Thu Aug 5 13:02:09 2010 From: rick at goldmoney.com (Rick van Rein) Date: Thu, 5 Aug 2010 13:02:09 +0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #166: Patch: Correct exit value from signer In-Reply-To: <054.6fec4e63003dc019a87311f2a49342bf@kirei.se> References: <045.4a0e969cce61c7287fef89d2d3a07f33@kirei.se> <054.6fec4e63003dc019a87311f2a49342bf@kirei.se> Message-ID: <20100805130209.GC29352@phantom.vanrein.org> Hi Matthijs, > shouldn't the raise in the patch be 'pass'? (like in Engine.py.in) No, I don't think so. Whatever you threw using System.exit() in the try-clause should go out to the next layer. try: ... System.exit (0) # should exit with code 0 ... System.exit (123) # should exit with code 123 ... except... Using raise, you will repeat whatever exception was thrown inside. If you would pass, you would exit normally, which would turn all try-clause exits into OK -- including exit(123) above. -Rick From owner-dnssec-trac at kirei.se Fri Aug 6 10:04:49 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Fri, 06 Aug 2010 10:04:49 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #166: Patch: Correct exit value from signer In-Reply-To: <045.4a0e969cce61c7287fef89d2d3a07f33@kirei.se> References: <045.4a0e969cce61c7287fef89d2d3a07f33@kirei.se> Message-ID: <054.e8fa9613cbd12147453bbef2c2cb5446@kirei.se> #166: Patch: Correct exit value from signer --------------------+------------------------------------------------------- Reporter: vanrein | Owner: matthijs Type: defect | Status: closed Priority: trivial | Component: Signer Version: 1.1.1 | Resolution: fixed Keywords: | --------------------+------------------------------------------------------- Changes (by matthijs): * status: new => closed * resolution: => fixed -- Ticket URL: OpenDNSSEC OpenDNSSEC From sion at nominet.org.uk Mon Aug 9 09:07:08 2010 From: sion at nominet.org.uk (Sion Lloyd) Date: Mon, 9 Aug 2010 10:07:08 +0100 Subject: [Opendnssec-develop] Next OpenDNSSEC meeting In-Reply-To: <887DE3F8-9F8F-4943-B7C6-4A3C71279734@iis.se> References: <887DE3F8-9F8F-4943-B7C6-4A3C71279734@iis.se> Message-ID: <201008091007.08194.sion@nominet.org.uk> On Wednesday 04 Aug 2010 8:08:12 am Rickard Bellgrim wrote: > Hi > > We suggested that we should have the next telephone meeting on 11 August > 2010, 14-15 CEST, 13-14 BST. I can make that. From jakob at kirei.se Mon Aug 9 09:51:34 2010 From: jakob at kirei.se (Jakob Schlyter) Date: Mon, 9 Aug 2010 11:51:34 +0200 Subject: [Opendnssec-develop] hello doxygen Message-ID: I've just committed basic support for generating source code documentation using Doxygen (http://www.stack.nl/~dimitri/doxygen/) for the entire tree (previously this was only used within libhsm). When writing comments in the code (e.g., for documenting function prototypes, data structures etc.), please consider using Doxygen syntax - examples can be found in libhsm/src/libhsm.{h,c}. jakob From rickard.bellgrim at iis.se Mon Aug 9 13:44:38 2010 From: rickard.bellgrim at iis.se (Rickard Bellgrim) Date: Mon, 9 Aug 2010 15:44:38 +0200 Subject: [Opendnssec-develop] Next OpenDNSSEC meeting In-Reply-To: <887DE3F8-9F8F-4943-B7C6-4A3C71279734@iis.se> References: <887DE3F8-9F8F-4943-B7C6-4A3C71279734@iis.se> Message-ID: On 4 aug 2010, at 09.08, Rickard Bellgrim wrote: > We suggested that we should have the next telephone meeting on 11 August 2010, 14-15 CEST, 13-14 BST. And you can find the draft agenda here: http://trac.opendnssec.org/wiki/Meetings/Agenda/2010-08-11 Please any topics you have. // Rickard From owner-dnssec-trac at kirei.se Tue Aug 10 12:40:00 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Tue, 10 Aug 2010 12:40:00 -0000 Subject: [Opendnssec-develop] [OpenDNSSEC] #169: Don't include pregenerated config.h Message-ID: <053.d286813ecf47a7bc16e7a5961fcdb6ee@kirei.se> #169: Don't include pregenerated config.h ----------------------------+----------------------------------------------- Reporter: ondrej@? | Owner: rb Type: enhancement | Status: new Priority: minor | Component: Unknown Version: trunk | Keywords: ----------------------------+----------------------------------------------- They are not needed (because configure generates them anyway) and they break out-of-dir builds. (Pregenerated config.h gets included instead of generated one.) Applies to all components. -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Tue Aug 10 12:42:46 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Tue, 10 Aug 2010 12:42:46 -0000 Subject: [Opendnssec-develop] [OpenDNSSEC] #170: ods-signer man page section is wrong Message-ID: <065.3daf192fa4e16a95d1a910cc168ea7e6@kirei.se> #170: ods-signer man page section is wrong ------------------------------------------+--------------------------------- Reporter: Ond?ej Sur? | Owner: rb Type: defect | Status: new Priority: trivial | Component: Unknown Version: trunk | Keywords: ------------------------------------------+--------------------------------- {{{ --- a/signer/signer_engine/ods-signer.8.in +++ b/signer/signer_engine/ods-signer.8.in @@ -1,4 +1,4 @@ -.TH "ods-signer" "1" "February 2010" "OpenDNSSEC" "OpenDNSSEC ods-signer" +.TH "ods-signer" "8" "February 2010" "OpenDNSSEC" "OpenDNSSEC ods-signer" .\" $Id: ods-signer.8.in 3101 2010-03-29 11:01:49Z matthijs $ .SH "NAME" .B ods\-signer }}} -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Tue Aug 10 12:44:53 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Tue, 10 Aug 2010 12:44:53 -0000 Subject: [Opendnssec-develop] [OpenDNSSEC] #171: Fail build on failed regression test (conf/) Message-ID: <065.112af8e8b8547d96f5afa74f03003fc6@kirei.se> #171: Fail build on failed regression test (conf/) ------------------------------------------+--------------------------------- Reporter: Ond?ej Sur? | Owner: rb Type: defect | Status: new Priority: major | Component: Unknown Version: trunk | Keywords: ------------------------------------------+--------------------------------- Regression tests doesn't fail when individual test fails, attached patch fixes that. {{{ --- a/conf/Makefile.am +++ b/conf/Makefile.am @@ -42,7 +42,7 @@ check: $(RNG) @for i in ${XML}; do \ ${XMLLINT} --noout --relaxng \ `basename $$i .xml`.rng \ - $(top_builddir)/$$i; \ + $(top_builddir)/$$i || exit $?; \ done @test -x ${XSLTPROC} || \ (echo "xsltproc is required for regression tests"; false) }}} -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Tue Aug 10 12:53:16 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Tue, 10 Aug 2010 12:53:16 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #169: Don't include pregenerated config.h In-Reply-To: <053.d286813ecf47a7bc16e7a5961fcdb6ee@kirei.se> References: <053.d286813ecf47a7bc16e7a5961fcdb6ee@kirei.se> Message-ID: <062.4cfa336e6af31f84ea591c939e70178e@kirei.se> #169: Don't include pregenerated config.h ----------------------------+----------------------------------------------- Reporter: ondrej@? | Owner: rb Type: enhancement | Status: accepted Priority: minor | Component: Unknown Version: trunk | Keywords: ----------------------------+----------------------------------------------- Changes (by rb): * status: new => accepted Comment: Yes, it shouldn't be include. v1.2 have merged the configure scripts and no makefile is including the config.h, so no problem there. This should probably be fixed in v1.1 branch. -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Tue Aug 10 12:59:16 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Tue, 10 Aug 2010 12:59:16 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #171: Fail build on failed regression test (conf/) In-Reply-To: <065.112af8e8b8547d96f5afa74f03003fc6@kirei.se> References: <065.112af8e8b8547d96f5afa74f03003fc6@kirei.se> Message-ID: <074.a5994cada23ff0b71b615ca50704a779@kirei.se> #171: Fail build on failed regression test (conf/) ------------------------------------------+--------------------------------- Reporter: Ond?ej Sur? | Owner: jakob Type: defect | Status: assigned Priority: major | Component: Unknown Version: trunk | Keywords: ------------------------------------------+--------------------------------- Changes (by jakob): * owner: rb => jakob * status: new => assigned -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Tue Aug 10 13:01:30 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Tue, 10 Aug 2010 13:01:30 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #171: Fail build on failed regression test (conf/) In-Reply-To: <065.112af8e8b8547d96f5afa74f03003fc6@kirei.se> References: <065.112af8e8b8547d96f5afa74f03003fc6@kirei.se> Message-ID: <074.dc2a81380f5ebcdf8ab96523772e9590@kirei.se> #171: Fail build on failed regression test (conf/) ------------------------------------------+--------------------------------- Reporter: Ond?ej Sur? | Owner: jakob Type: defect | Status: closed Priority: major | Component: Unknown Version: trunk | Resolution: fixed Keywords: | ------------------------------------------+--------------------------------- Changes (by jakob): * status: assigned => closed * resolution: => fixed Comment: thanks, fixed in r3708. -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Tue Aug 10 13:04:06 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Tue, 10 Aug 2010 13:04:06 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #170: ods-signer man page section is wrong In-Reply-To: <065.3daf192fa4e16a95d1a910cc168ea7e6@kirei.se> References: <065.3daf192fa4e16a95d1a910cc168ea7e6@kirei.se> Message-ID: <074.8e39c1a69e82c2227d61456380a5ad81@kirei.se> #170: ods-signer man page section is wrong ------------------------------------------+--------------------------------- Reporter: Ond?ej Sur? | Owner: rb Type: defect | Status: closed Priority: trivial | Component: Unknown Version: trunk | Resolution: fixed Keywords: | ------------------------------------------+--------------------------------- Changes (by rb): * status: new => closed * resolution: => fixed Comment: Thanks, fixed in r3709 -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Tue Aug 10 13:19:40 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Tue, 10 Aug 2010 13:19:40 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #169: Don't include pregenerated config.h In-Reply-To: <053.d286813ecf47a7bc16e7a5961fcdb6ee@kirei.se> References: <053.d286813ecf47a7bc16e7a5961fcdb6ee@kirei.se> Message-ID: <062.1695a05171fc6f4c6071f2b7139b0605@kirei.se> #169: Don't include pregenerated config.h ----------------------------+----------------------------------------------- Reporter: ondrej@? | Owner: rb Type: enhancement | Status: closed Priority: minor | Component: Unknown Version: trunk | Resolution: fixed Keywords: | ----------------------------+----------------------------------------------- Changes (by rb): * status: accepted => closed * resolution: => fixed Comment: Thanks, fixed in r3710 -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Tue Aug 10 14:04:17 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Tue, 10 Aug 2010 14:04:17 -0000 Subject: [Opendnssec-develop] [OpenDNSSEC] #172: Yet another error in man page Message-ID: <065.7fe0304d29b386fd20afd0b644912eb4@kirei.se> #172: Yet another error in man page ------------------------------------------+--------------------------------- Reporter: Ond?ej Sur? | Owner: rb Type: defect | Status: new Priority: minor | Component: Unknown Version: trunk | Keywords: ------------------------------------------+--------------------------------- The line cannot start with dot. Rewritten paragraph so it doesn't use .B, but \fB \fR. {{{ --- a/tools/ods-timing.5.in +++ b/tools/ods-timing.5.in @@ -18,15 +18,12 @@ notably for periods. These descriptions for the duration of a month and a year, as these periods would be allowed to vary if ISO 8601 were strictly adhered to. .PP -Durations are represented by the format -.B P[n]Y[n]M[n]DT[n]H[n]M[n]S -. In these representations, the -.B [n] -is replaced by the value for each of the date and time elements that follow the -.B [n] -. Leading zeros are not required. The capital letters \fBP\fR, \fBY\fR, -\fBM\fR, \fBW\fR, \fBD\fR, \fBT\fR, \fBH\fR, \fBM\fR and \fBS\fR -are designators for each of the date and time elements and are not replaced. +Durations are represented by the format \fBP[n]Y[n]M[n]DT[n]H[n]M[n]S\fR. +In these representations, the \fB[n]\fR is replaced by the value for each +of the date and time elements that follow the \fB[n]\fR. Leading zeros are +not required. The capital letters \fBP\fR, \fBY\fR, \fBM\fR, \fBW\fR, +\fBD\fR, \fBT\fR, \fBH\fR, \fBM\fR and \fBS\fR are designators for each of +the date and time elements and are not replaced. .TP .B P is the duration designator (historically called "period") placed at the start of the duration representation. }}} -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Tue Aug 10 14:08:53 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Tue, 10 Aug 2010 14:08:53 -0000 Subject: [Opendnssec-develop] [OpenDNSSEC] #173: LI is from HTML :) Message-ID: <065.9cffa184823a3c18049927d99acffe30@kirei.se> #173: LI is from HTML :) ------------------------------------------+--------------------------------- Reporter: Ond?ej Sur? | Owner: sion Type: defect | Status: new Priority: major | Component: Enforcer Version: trunk | Keywords: ------------------------------------------+--------------------------------- .LI is not known to groff, hence the whole numbered part is not included in the man page. Renumbered manually to steps 1..4: {{{ --- a/enforcer/utils/ods-ksmutil.1.in +++ b/enforcer/utils/ods-ksmutil.1.in @@ -250,11 +250,15 @@ This is a necessary step for repositorie Note that the KASP Enforcer may take the initiative to generate keys after the backup has started and before the backup is done. In the current version of OpenDNSSEC, it is therefore needed to stop the KASP Enforcer to be assured -that all keys are backed up. The sequence would therefore be -.LI Issue \fBods-control ksm stop\fR -.LI Make a backup of the repository -.LI Issue \fBods-ksmutil backup done\fR -.LI Issue \fBods-control ksm start\fR +that all keys are backed up. The sequence would therefore be: +.br +1. Issue \fBods-control ksm stop\fR +.br +2. Make a backup of the repository +.br +3. Issue \fBods-ksmutil backup done\fR +.br +4. Issue \fBods-control ksm start\fR .TP .B database backup [\-\-output|\-o output] Make a copy of the database of the KASP Enforcer (if using sqlite). }}} -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Wed Aug 11 06:38:55 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Wed, 11 Aug 2010 06:38:55 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #172: Yet another error in man page In-Reply-To: <065.7fe0304d29b386fd20afd0b644912eb4@kirei.se> References: <065.7fe0304d29b386fd20afd0b644912eb4@kirei.se> Message-ID: <074.47075f2b38acd83985204710f79f55f0@kirei.se> #172: Yet another error in man page ------------------------------------------+--------------------------------- Reporter: Ond?ej Sur? | Owner: rb Type: defect | Status: closed Priority: minor | Component: Unknown Version: trunk | Resolution: fixed Keywords: | ------------------------------------------+--------------------------------- Changes (by rb): * status: new => closed * resolution: => fixed Comment: Thanks, fixed in r3719 -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Wed Aug 11 07:11:24 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Wed, 11 Aug 2010 07:11:24 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #173: LI is from HTML :) In-Reply-To: <065.9cffa184823a3c18049927d99acffe30@kirei.se> References: <065.9cffa184823a3c18049927d99acffe30@kirei.se> Message-ID: <074.9cdd7a95804dc842153e474ff86cbc2d@kirei.se> #173: LI is from HTML :) ------------------------------------------+--------------------------------- Reporter: Ond?ej Sur? | Owner: sion Type: defect | Status: closed Priority: major | Component: Enforcer Version: trunk | Resolution: fixed Keywords: | ------------------------------------------+--------------------------------- Changes (by rb): * status: new => closed * resolution: => fixed Comment: Thanks, fixed in r3720 -- Ticket URL: OpenDNSSEC OpenDNSSEC From AlexD at nominet.org.uk Wed Aug 11 09:37:46 2010 From: AlexD at nominet.org.uk (Alex Dalitz) Date: Wed, 11 Aug 2010 09:37:46 +0000 Subject: [Opendnssec-develop] Build problems Message-ID: <041D505F-B34C-4E99-8089-754784534EEE@nominet.org.uk> Hi - I'm having lots of problems building and testing OpenDNSSEC. I get lots of warning from building libhsm : gcc -DHAVE_CONFIG_H -I. -I/Users/alex/.hudson/jobs/OpenDNSSEC/workspace/src/libhsm/src -I../../common -I/Users/alex/.hudson/jobs/OpenDNSSEC/workspace/src/common -I../../common -I/Users/alex/.hudson/jobs/OpenDNSSEC/workspace/src/libhsm/src/cryptoki_compat -I/usr/local/include -I/opt/local/include/libxml2 -g -O2 -pedantic -Wall -Wextra -D_THREAD_SAFE -MT libhsm.o -MD -MP -MF .deps/libhsm.Tpo -c -o libhsm.o /Users/alex/.hudson/jobs/OpenDNSSEC/workspace/src/libhsm/src/libhsm.c /Users/alex/.hudson/jobs/OpenDNSSEC/workspace/src/libhsm/src/libhsm.c: In function ???hsm_pkcs11_check_error???: /Users/alex/.hudson/jobs/OpenDNSSEC/workspace/src/libhsm/src/libhsm.c:244: warning: implicit declaration of function ???strlcpy??? /Users/alex/.hudson/jobs/OpenDNSSEC/workspace/src/libhsm/src/libhsm.c: In function ???hsm_pkcs11_load_functions???: /Users/alex/.hudson/jobs/OpenDNSSEC/workspace/src/libhsm/src/libhsm.c:297: warning: ISO C forbids conversion of object pointer to function pointer type /Users/alex/.hudson/jobs/OpenDNSSEC/workspace/src/libhsm/src/libhsm.c:319: warning: passing argument 1 of ???pGetFunctionList??? from incompatible pointer type /Users/alex/.hudson/jobs/OpenDNSSEC/workspace/src/libhsm/src/libhsm.c: In function ???hsm_get_key_algorithm???: /Users/alex/.hudson/jobs/OpenDNSSEC/workspace/src/libhsm/src/libhsm.c:759: warning: initializer element is not computable at load time /Users/alex/.hudson/jobs/OpenDNSSEC/workspace/src/libhsm/src/libhsm.c:759: warning: initializer element is not computable at load time /Users/alex/.hudson/jobs/OpenDNSSEC/workspace/src/libhsm/src/libhsm.c: In function ???hsm_get_key_size_rsa???: /Users/alex/.hudson/jobs/OpenDNSSEC/workspace/src/libhsm/src/libhsm.c:800: warning: initializer element is not computable at load time /Users/alex/.hudson/jobs/OpenDNSSEC/workspace/src/libhsm/src/libhsm.c:800: warning: initializer element is not computable at load time /Users/alex/.hudson/jobs/OpenDNSSEC/workspace/src/libhsm/src/libhsm.c: In function ???hsm_find_object_handle_for_id???: /Users/alex/.hudson/jobs/OpenDNSSEC/workspace/src/libhsm/src/libhsm.c:865: warning: initializer element is not computable at load time /Users/alex/.hudson/jobs/OpenDNSSEC/workspace/src/libhsm/src/libhsm.c:865: warning: initializer element is not computable at load time /Users/alex/.hudson/jobs/OpenDNSSEC/workspace/src/libhsm/src/libhsm.c:866: warning: initializer element is not computable at load time /Users/alex/.hudson/jobs/OpenDNSSEC/workspace/src/libhsm/src/libhsm.c:866: warning: initializer element is not computable at load time /Users/alex/.hudson/jobs/OpenDNSSEC/workspace/src/libhsm/src/libhsm.c:866: warning: initializer element is not computable at load time /Users/alex/.hudson/jobs/OpenDNSSEC/workspace/src/libhsm/src/libhsm.c: In function ???hsm_get_id_for_object???: /Users/alex/.hudson/jobs/OpenDNSSEC/workspace/src/libhsm/src/libhsm.c:956: warning: initializer element is not computable at load time /Users/alex/.hudson/jobs/OpenDNSSEC/workspace/src/libhsm/src/libhsm.c:956: warning: initializer element is not computable at load time /Users/alex/.hudson/jobs/OpenDNSSEC/workspace/src/libhsm/src/libhsm.c: In function ???hsm_list_keys_session_internal???: /Users/alex/.hudson/jobs/OpenDNSSEC/workspace/src/libhsm/src/libhsm.c:1045: warning: initializer element is not computable at load time /Users/alex/.hudson/jobs/OpenDNSSEC/workspace/src/libhsm/src/libhsm.c:1045: warning: initializer element is not computable at load time /Users/alex/.hudson/jobs/OpenDNSSEC/workspace/src/libhsm/src/libhsm.c:1052: warning: ISO C90 forbids variable-size array ???object??? /Users/alex/.hudson/jobs/OpenDNSSEC/workspace/src/libhsm/src/libhsm.c: In function ???hsm_prompt_pin???: /Users/alex/.hudson/jobs/OpenDNSSEC/workspace/src/libhsm/src/libhsm.c:1797: warning: implicit declaration of function ???getpass??? /Users/alex/.hudson/jobs/OpenDNSSEC/workspace/src/libhsm/src/libhsm.c:1797: warning: assignment makes pointer from integer without a cast /Users/alex/.hudson/jobs/OpenDNSSEC/workspace/src/libhsm/src/libhsm.c: In function ???hsm_generate_rsa_key???: /Users/alex/.hudson/jobs/OpenDNSSEC/workspace/src/libhsm/src/libhsm.c:1980: warning: initializer element is not computable at load time /Users/alex/.hudson/jobs/OpenDNSSEC/workspace/src/libhsm/src/libhsm.c:1980: warning: initializer element is not computable at load time /Users/alex/.hudson/jobs/OpenDNSSEC/workspace/src/libhsm/src/libhsm.c:1980: warning: initializer element is not computable at load time /Users/alex/.hudson/jobs/OpenDNSSEC/workspace/src/libhsm/src/libhsm.c:1981: warning: initializer element is not computable at load time /Users/alex/.hudson/jobs/OpenDNSSEC/workspace/src/libhsm/src/libhsm.c:1981: warning: initializer element is not computable at load time /Users/alex/.hudson/jobs/OpenDNSSEC/workspace/src/libhsm/src/libhsm.c:1982: warning: initializer element is not computable at load time /Users/alex/.hudson/jobs/OpenDNSSEC/workspace/src/libhsm/src/libhsm.c:1982: warning: initializer element is not computable at load time /Users/alex/.hudson/jobs/OpenDNSSEC/workspace/src/libhsm/src/libhsm.c:1983: warning: initializer element is not computable at load time /Users/alex/.hudson/jobs/OpenDNSSEC/workspace/src/libhsm/src/libhsm.c:1983: warning: initializer element is not computable at load time /Users/alex/.hudson/jobs/OpenDNSSEC/workspace/src/libhsm/src/libhsm.c:1984: warning: initializer element is not computable at load time /Users/alex/.hudson/jobs/OpenDNSSEC/workspace/src/libhsm/src/libhsm.c:1984: warning: initializer element is not computable at load time /Users/alex/.hudson/jobs/OpenDNSSEC/workspace/src/libhsm/src/libhsm.c:1985: warning: initializer element is not computable at load time /Users/alex/.hudson/jobs/OpenDNSSEC/workspace/src/libhsm/src/libhsm.c:1985: warning: initializer element is not computable at load time /Users/alex/.hudson/jobs/OpenDNSSEC/workspace/src/libhsm/src/libhsm.c:1986: warning: initializer element is not computable at load time /Users/alex/.hudson/jobs/OpenDNSSEC/workspace/src/libhsm/src/libhsm.c:1986: warning: initializer element is not computable at load time /Users/alex/.hudson/jobs/OpenDNSSEC/workspace/src/libhsm/src/libhsm.c:1987: warning: initializer element is not computable at load time /Users/alex/.hudson/jobs/OpenDNSSEC/workspace/src/libhsm/src/libhsm.c:1987: warning: initializer element is not computable at load time /Users/alex/.hudson/jobs/OpenDNSSEC/workspace/src/libhsm/src/libhsm.c:1988: warning: initializer element is not computable at load time /Users/alex/.hudson/jobs/OpenDNSSEC/workspace/src/libhsm/src/libhsm.c:1988: warning: initializer element is not computable at load time /Users/alex/.hudson/jobs/OpenDNSSEC/workspace/src/libhsm/src/libhsm.c:1979: warning: ISO C90 forbids mixed declarations and code /Users/alex/.hudson/jobs/OpenDNSSEC/workspace/src/libhsm/src/libhsm.c:1992: warning: initializer element is not computable at load time /Users/alex/.hudson/jobs/OpenDNSSEC/workspace/src/libhsm/src/libhsm.c:1992: warning: initializer element is not computable at load time /Users/alex/.hudson/jobs/OpenDNSSEC/workspace/src/libhsm/src/libhsm.c:1992: warning: initializer element is not computable at load time /Users/alex/.hudson/jobs/OpenDNSSEC/workspace/src/libhsm/src/libhsm.c:1993: warning: initializer element is not computable at load time /Users/alex/.hudson/jobs/OpenDNSSEC/workspace/src/libhsm/src/libhsm.c:1993: warning: initializer element is not computable at load time /Users/alex/.hudson/jobs/OpenDNSSEC/workspace/src/libhsm/src/libhsm.c:1994: warning: initializer element is not computable at load time /Users/alex/.hudson/jobs/OpenDNSSEC/workspace/src/libhsm/src/libhsm.c:1994: warning: initializer element is not computable at load time /Users/alex/.hudson/jobs/OpenDNSSEC/workspace/src/libhsm/src/libhsm.c:1995: warning: initializer element is not computable at load time /Users/alex/.hudson/jobs/OpenDNSSEC/workspace/src/libhsm/src/libhsm.c:1995: warning: initializer element is not computable at load time /Users/alex/.hudson/jobs/OpenDNSSEC/workspace/src/libhsm/src/libhsm.c:1996: warning: initializer element is not computable at load time /Users/alex/.hudson/jobs/OpenDNSSEC/workspace/src/libhsm/src/libhsm.c:1996: warning: initializer element is not computable at load time /Users/alex/.hudson/jobs/OpenDNSSEC/workspace/src/libhsm/src/libhsm.c:1997: warning: initializer element is not computable at load time /Users/alex/.hudson/jobs/OpenDNSSEC/workspace/src/libhsm/src/libhsm.c:1997: warning: initializer element is not computable at load time /Users/alex/.hudson/jobs/OpenDNSSEC/workspace/src/libhsm/src/libhsm.c:1998: warning: initializer element is not computable at load time /Users/alex/.hudson/jobs/OpenDNSSEC/workspace/src/libhsm/src/libhsm.c:1998: warning: initializer element is not computable at load time /Users/alex/.hudson/jobs/OpenDNSSEC/workspace/src/libhsm/src/libhsm.c:1999: warning: initializer element is not computable at load time /Users/alex/.hudson/jobs/OpenDNSSEC/workspace/src/libhsm/src/libhsm.c:1999: warning: initializer element is not computable at load time /Users/alex/.hudson/jobs/OpenDNSSEC/workspace/src/libhsm/src/libhsm.c:2000: warning: initializer element is not computable at load time /Users/alex/.hudson/jobs/OpenDNSSEC/workspace/src/libhsm/src/libhsm.c:2000: warning: initializer element is not computable at load time /Users/alex/.hudson/jobs/OpenDNSSEC/workspace/src/libhsm/src/libhsm.c:2001: warning: initializer element is not computable at load time /Users/alex/.hudson/jobs/OpenDNSSEC/workspace/src/libhsm/src/libhsm.c:2001: warning: initializer element is not computable at load time Additionally, the enforcer tests all fail - however, the unit test system tells me that it has PASSed and all is OK : SQL error near line 91: no such table: keypairs SQL error near line 92: no such table: keypairs SQL error near line 93: no such table: keypairs SQL error near line 94: no such table: keypairs SQL error near line 95: no such table: keypairs SQL error near line 96: no such table: keypairs SQL error near line 97: no such table: keypairs WARNING - Suite initialization failed for KsmImport. --Run Summary: Type Total Ran Passed Failed suites 18 8 n/a 10 tests 78 46 46 0 asserts 726 726 726 0 PASS: test ============= 1 test passed ============= Anyone have any idea what is going on here, please? Thanks! Alex. From jakob at kirei.se Wed Aug 11 09:38:46 2010 From: jakob at kirei.se (Jakob Schlyter) Date: Wed, 11 Aug 2010 11:38:46 +0200 Subject: [Opendnssec-develop] Build problems In-Reply-To: <041D505F-B34C-4E99-8089-754784534EEE@nominet.org.uk> References: <041D505F-B34C-4E99-8089-754784534EEE@nominet.org.uk> Message-ID: what operating system? jakob From AlexD at nominet.org.uk Wed Aug 11 09:52:22 2010 From: AlexD at nominet.org.uk (Alex Dalitz) Date: Wed, 11 Aug 2010 09:52:22 +0000 Subject: [Opendnssec-develop] Build problems In-Reply-To: References: <041D505F-B34C-4E99-8089-754784534EEE@nominet.org.uk> Message-ID: <84401D26-4563-4F9B-ACB2-C1EF43D33751@nominet.org.uk> > what operating system? I sent errors from OSX. Sion is also having failures with Ubuntu. Alex. From rickard.bellgrim at iis.se Wed Aug 11 09:59:39 2010 From: rickard.bellgrim at iis.se (Rickard Bellgrim) Date: Wed, 11 Aug 2010 11:59:39 +0200 Subject: [Opendnssec-develop] Build problems In-Reply-To: <041D505F-B34C-4E99-8089-754784534EEE@nominet.org.uk> References: <041D505F-B34C-4E99-8089-754784534EEE@nominet.org.uk> Message-ID: On 11 aug 2010, at 11.37, Alex Dalitz wrote: > /Users/alex/.hudson/jobs/OpenDNSSEC/workspace/src/libhsm/src/libhsm.c:1996: warning: initializer element is not computable at load time The warnings in libhsm is because C99 was disabled. The code needs to be rewritten in order to support C90. // Rickard From jakob at kirei.se Wed Aug 11 10:21:24 2010 From: jakob at kirei.se (Jakob Schlyter) Date: Wed, 11 Aug 2010 12:21:24 +0200 Subject: [Opendnssec-develop] Build problems In-Reply-To: References: <041D505F-B34C-4E99-8089-754784534EEE@nominet.org.uk> Message-ID: <4FF72789-2FED-4104-AFF9-9897F1A702E0@kirei.se> On 11 aug 2010, at 11.59, Rickard Bellgrim wrote: > The warnings in libhsm is because C99 was disabled. The code needs to be rewritten in order to support C90. I've re-enabled C99 for now. j From rick at openfortress.nl Wed Aug 11 13:13:51 2010 From: rick at openfortress.nl (Rick van Rein) Date: Wed, 11 Aug 2010 13:13:51 +0000 Subject: [Opendnssec-develop] Overview of 1.1.1 problems Message-ID: <20100811131351.GA8990@phantom.vanrein.org> Hello, As requested in today's phone meeting, here is a list of the issues that SURFnet ran into with OpenDNSSEC 1.1.1. We supplied patches for every new problem. "incsoa" When we decide to sign a domain, we insert OpenDNSSEC in the path between the hidden master (the domain editor) and the public authoritatives. Doing this for an already-published domain means that the SOA serial number must always be incremented by the signer. The current code does not do that. It is a bit of a matter of taste if/how this should be done in general, or if perhaps this should be an option, or... Anyhow, what we supplied as a patch is in Trac #165 "async ods-control" The use of asynchronous commands got us into trouble when we tried to implement a thorough key backup procedure based on stopping the KASP enforcer. We propose a synchronising variation to replace it. Trac #168 (to be reviewed before inclusion in 1.1.2) "pidfile" A known bug in 1.1.1 that really confuses users is the overlap in PID-file between enforcer daemon and zone_fetcher. "LDNS" The zone_fetcher can freeze if the communication with its master runs into a bug in LDNS. The recent release of LDNS resolves this issue, will be made a dependency for OpenDNSSEC 1.1.2. "ods-signer exit" Minor, but ods-signer does not report success if it succeeded. Trac #166 solves this minor issue. "2-phase key backup" Presented in Trac #161. "zone_fetcher notify" The zone_fetcher in 1.1.1 will not reload the zonelist.xml file when the signer is sent an update command. This meant that changing lists of zones could not be handled. Trac #167 resolves this. "policy pruning" This one is more a proposal of an improvement than a patch that can go into the branch without further discussion; we merely made a stab at a possible user interface by adding a command "ods-ksmutil policy prune" to remove policies that have no zones attached. Trac #151 contains the corresponding patch. It felt really good to be useful and supply code for a change ;-) Cheers, -Rick From rick at openfortress.nl Wed Aug 11 13:47:09 2010 From: rick at openfortress.nl (Rick van Rein) Date: Wed, 11 Aug 2010 13:47:09 +0000 Subject: [Opendnssec-develop] Meeting notes 2010-08-11 Message-ID: <20100811134709.GB8990@phantom.vanrein.org> Hello, I have published the notes of today's meeting, http://trac.opendnssec.org/wiki/Meetings/Minutes/2010-08-11 One remark I didn't want to add there: The suggested "make doc" for building documentation in the root may be confusing -- it sounds like building end-user documentation. Perhaps another general name would be better? Cheers, -Rick From rickard.bellgrim at iis.se Wed Aug 11 13:55:23 2010 From: rickard.bellgrim at iis.se (Rickard Bellgrim) Date: Wed, 11 Aug 2010 15:55:23 +0200 Subject: [Opendnssec-develop] Performance In-Reply-To: <4E7D1B82-8A21-43C6-98BC-659C5BFD8090@iis.se> References: <4E7D1B82-8A21-43C6-98BC-659C5BFD8090@iis.se> Message-ID: <52EB5931-A75C-4921-958C-E21421888FAB@iis.se> Here is a comparison between v1.1 and v1.2 with the .se-zone On 10 mar 2010, at 12.08, Rickard Bellgrim wrote: > V1.1: > > start > 00:00 > quicksorter > 00:05 > zone_reader > 01:01 > signer (1540 rr/sec) > 10:42 > finalizer > 10:51 v1.2 The total time was around 16 minutes. And some stats: [STATS] se RR[count=2167209 time=52(sec)) NSEC[count=926590 time=9(sec)] RRSIG[new=930497 reused=0 time=898(sec) avg=1036(sig/sec)] If you summarize the time in the stats, do you get the actual time or is there some other parts that also takes time? The time to sort and nsec is equal between the versions. But the signing is slower. // Rickard From matthijs at NLnetLabs.nl Wed Aug 11 14:09:54 2010 From: matthijs at NLnetLabs.nl (Matthijs Mekking) Date: Wed, 11 Aug 2010 16:09:54 +0200 Subject: [Opendnssec-develop] Performance In-Reply-To: <52EB5931-A75C-4921-958C-E21421888FAB@iis.se> References: <4E7D1B82-8A21-43C6-98BC-659C5BFD8090@iis.se> <52EB5931-A75C-4921-958C-E21421888FAB@iis.se> Message-ID: <4C62AF32.9030007@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, The summarized times in STATS are the actual times. There are for example some extra actions between sort and nsec which are not measured. Time for the threaded signer, I see... Matthijs On 08/11/2010 03:55 PM, Rickard Bellgrim wrote: > Here is a comparison between v1.1 and v1.2 with the .se-zone > > On 10 mar 2010, at 12.08, Rickard Bellgrim wrote: > >> V1.1: >> >> start >> 00:00 >> quicksorter >> 00:05 >> zone_reader >> 01:01 >> signer (1540 rr/sec) >> 10:42 >> finalizer >> 10:51 > > v1.2 > > The total time was around 16 minutes. > > And some stats: > [STATS] se RR[count=2167209 time=52(sec)) NSEC[count=926590 time=9(sec)] RRSIG[new=930497 reused=0 time=898(sec) avg=1036(sig/sec)] > > If you summarize the time in the stats, do you get the actual time or is there some other parts that also takes time? > > The time to sort and nsec is equal between the versions. But the signing is slower. > > // Rickard_______________________________________________ > Opendnssec-develop mailing list > Opendnssec-develop at lists.opendnssec.org > https://lists.opendnssec.org/mailman/listinfo/opendnssec-develop > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJMYq8yAAoJEA8yVCPsQCW5XW0H/25k39mJMFBF5iOnTZ528fdR PFCAfnVyP5YiqXNHZ7tIus+eZUfS7rMICyz4IEtMEXYaZIQBtstVCsRUf9DcuZxv fc0mc8WVSnepER/LFM35gwm9fKp/WxeD7zfV2Qy/suN51ScFRmfxnwvMdYTuSGme 3+OGO2beQNotPMAd017h7a+tgdBd2kOZaDgD5cACGybV+HWvq89IBsPdXSIuGgZC 9FBd+oZmjkZDtbszX4LlkRubJ4HFVAQKWFaaRj96YiPjrSmS4RLL2hJj3Dp5r/G7 mqCnOTuo3XrVQuzxuiVC73DZMxr6SjSsiI1qTP2B6bMdK7KsD5FQYFD4KyMZnj4= =+Z8V -----END PGP SIGNATURE----- From rickard.bellgrim at iis.se Thu Aug 12 08:31:32 2010 From: rickard.bellgrim at iis.se (Rickard Bellgrim) Date: Thu, 12 Aug 2010 10:31:32 +0200 Subject: [Opendnssec-develop] Performance In-Reply-To: <52EB5931-A75C-4921-958C-E21421888FAB@iis.se> References: <4E7D1B82-8A21-43C6-98BC-659C5BFD8090@iis.se> <52EB5931-A75C-4921-958C-E21421888FAB@iis.se> Message-ID: On 11 aug 2010, at 15.55, Rickard Bellgrim wrote: > But the signing is slower. No worries. There is already a suggestion on how to speed up the signing. And some comparison between NSEC, NSEC3, and NSEC with opt-out. (using the .se zone) ** NSEC ** [STATS] se RR[count=2167209 time=52(sec)) NSEC[count=926590 time=9(sec)] RRSIG[new=930497 reused=0 time=898(sec) avg=1036(sig/sec)] Real time: 17:08 Time from stats: 15:59 Diff: 1:09 ** NSEC3 ** [STATS] se RR[count=2167209 time=52(sec)) NSEC3[count=926631 time=31(sec)] RRSIG[new=930539 reused=0 time=909(sec) avg=1023(sig/sec)] Real time: 17:13 Time from stats: 16:32 Diff: 41s ** NSEC3 Opt-out ** [STATS] se RR[count=2167209 time=52(sec)) NSEC3[count=3883 time=5(sec)] RRSIG[new=7791 reused=0 time=8(sec) avg=973(sig/sec)] Real time: 1:48 Time from stats: 1:05 Diff: 43s Conclusion: * Really fast with NSEC3 opt-out. * And that we probably want to have one extra field with the total time. Since there is a big difference between the time in the stats and the actual time. // Rickard From AlexD at nominet.org.uk Fri Aug 13 10:29:26 2010 From: AlexD at nominet.org.uk (Alex Dalitz) Date: Fri, 13 Aug 2010 10:29:26 +0000 Subject: [Opendnssec-develop] Policy changes Message-ID: <280208CE-D840-4FFF-B2DE-20A781D4426E@nominet.org.uk> Hi - I have committed (to trunk) what I think is required for the auditor to handle changes in policy. It seems to work, as best as I can automate the testing (and with manual testing so far). However, I'm having a hard time working out how to automate this to catch all issues - it could be some time before any proper automated tests are available. So, can I please ask anyone, who is interested to have this working, please to try making changes to your policy, and see how the signer and auditor handle these? I'd be very grateful for any reports, successful or otherwise! Thanks, Alex. From sion at nominet.org.uk Mon Aug 16 09:59:26 2010 From: sion at nominet.org.uk (Sion Lloyd) Date: Mon, 16 Aug 2010 10:59:26 +0100 Subject: [Opendnssec-develop] Purge keys Message-ID: <201008161059.27008.sion@nominet.org.uk> Morning. I'm reworking the purge keys code to cope with the new key sharing. I'm wondering if anyone has views on the following... If a key has been in the dead state for long enough on zone "A", but is yet to be used by zone "B" on the policy, should we purge it? My thought is that we should, because we are trying to save space on the HSM and there must be enough keys without this one to keep zone "A" happy. Can anyone think of a use-case for purge where this would not be appropriate? Cheers, Sion From rickard.bellgrim at iis.se Mon Aug 16 10:25:51 2010 From: rickard.bellgrim at iis.se (Rickard Bellgrim) Date: Mon, 16 Aug 2010 12:25:51 +0200 Subject: [Opendnssec-develop] OpenDNSSEC 1.1.2 Message-ID: <896AA9E2-14C3-40A3-9D17-7D5F7E359241@iis.se> Hi We only had to fix the ods-control script before we could release v1.1.2. Do we have any status on this one? // Rickard From rickard.bellgrim at iis.se Mon Aug 16 13:26:47 2010 From: rickard.bellgrim at iis.se (Rickard Bellgrim) Date: Mon, 16 Aug 2010 15:26:47 +0200 Subject: [Opendnssec-develop] OpenDNSSEC 1.1.2 In-Reply-To: <896AA9E2-14C3-40A3-9D17-7D5F7E359241@iis.se> References: <896AA9E2-14C3-40A3-9D17-7D5F7E359241@iis.se> Message-ID: On 16 aug 2010, at 12.25, Rickard Bellgrim wrote: > We only had to fix the ods-control script before we could release v1.1.2. Do we have any status on this one? I think this patch is what we had in mind during the last meeting. Was it something that we should include? Or save for 1.2? http://trac.opendnssec.org/attachment/ticket/168/opendnssec-1.1.1-odscontrol_synchronous.patch // Rickard From rick at openfortress.nl Mon Aug 16 13:44:44 2010 From: rick at openfortress.nl (Rick van Rein) Date: Mon, 16 Aug 2010 13:44:44 +0000 Subject: [Opendnssec-develop] OpenDNSSEC 1.1.2 In-Reply-To: References: <896AA9E2-14C3-40A3-9D17-7D5F7E359241@iis.se> Message-ID: <20100816134444.GA10442@phantom.vanrein.org> Hi Rickard/others, > > We only had to fix the ods-control script before we could release v1.1.2. Do we have any status on this one? > > > I think this patch is what we had in mind during the last meeting. Was it something that we should include? Or save for 1.2? > > http://trac.opendnssec.org/attachment/ticket/168/opendnssec-1.1.1-odscontrol_synchronous.patch Since 1.1.2 is primarily "for SURFnet" and since SURFnet uses this... it'd be nice to include. I'd have hoped it was part of 1.1.1 already. But it is going to be useful for others as well: I think it helps Real People to avoid running into Real Problems, such as stopping and restarting KASP too quickly in sequency -- something the Enforcer daemon doesn't handle well (*) That's the sort of concurrency trouble you'd like to shield your users from :) (*) What happens is that the dying Enforcer cleans up after receiving a kill, and if the new Enforcer has already written out its PID file then this may actually get deleted by the old Enforcer, leading to surprising messages such as not being able to chown the PID file. It's one of those places where we had to be developers in order to be able to operate OpenDNSSEC -- which hinders our target audience. We've used it for some time, and only got into trouble while the PID file was overwritten by the zone_fetcher. Other than that, it's made us think "why does it block? oh wait, over here I've done this-and-that" and by doing so has helped us to develop a more solid understanding of how to operate OpenDNSSEC. So please include it :) Cheers, -Rick From rick at openfortress.nl Mon Aug 16 14:00:22 2010 From: rick at openfortress.nl (Rick van Rein) Date: Mon, 16 Aug 2010 14:00:22 +0000 Subject: [Opendnssec-develop] OpenDNSSEC 1.1.2 In-Reply-To: References: <896AA9E2-14C3-40A3-9D17-7D5F7E359241@iis.se> Message-ID: <20100816140022.GA10567@phantom.vanrein.org> Rickard, > I think this patch is what we had in mind during the last meeting. > > http://trac.opendnssec.org/attachment/ticket/168/opendnssec-1.1.1-odscontrol_synchronous.patch I just added the patch for the manpage (I usually include that in the same patch as the code, but I forgot it this time). The patch set under #168 is now complete. Questions -> you know how to reach me! -Rick From sion at nominet.org.uk Tue Aug 17 10:45:48 2010 From: sion at nominet.org.uk (Sion Lloyd) Date: Tue, 17 Aug 2010 11:45:48 +0100 Subject: [Opendnssec-develop] Key rollover Message-ID: <201008171145.48610.sion@nominet.org.uk> Morning. I'm looking at what needs to happen when we do an emergency rollover of a key combined with proper key sharing. This is more complicated than before because the key could be in any state on various zones; whereas before we knew that it would be active (or you wouldn't be rolling it). If the key is active we need to make sure that a successor key is ready before we retire the current key. Is it always true that for any other state we can move the key straight to dead? Are there any cases where we need to post-publish the key? Cheers, Sion From rickard.bellgrim at iis.se Tue Aug 17 11:50:24 2010 From: rickard.bellgrim at iis.se (Rickard Bellgrim) Date: Tue, 17 Aug 2010 13:50:24 +0200 Subject: [Opendnssec-develop] Purge keys In-Reply-To: <201008161059.27008.sion@nominet.org.uk> References: <201008161059.27008.sion@nominet.org.uk> Message-ID: On 16 aug 2010, at 11.59, Sion Lloyd wrote: > If a key has been in the dead state for long enough on zone "A", but is yet to > be used by zone "B" on the policy, should we purge it? If the key is yet to be used by zone "B" and we remove it, won't we just create a new key in the HSM to replace it? Thus not saving any space. > My thought is that we should, because we are trying to save space on the HSM > and there must be enough keys without this one to keep zone "A" happy. Would zone "B" be happy? > Can anyone think of a use-case for purge where this would not be appropriate? Keys should only be removed if they are completely dead. // Rickard From sion at nominet.org.uk Tue Aug 17 12:49:58 2010 From: sion at nominet.org.uk (Sion Lloyd) Date: Tue, 17 Aug 2010 13:49:58 +0100 Subject: [Opendnssec-develop] Purge keys In-Reply-To: References: <201008161059.27008.sion@nominet.org.uk> Message-ID: <201008171349.58777.sion@nominet.org.uk> On Tuesday 17 Aug 2010 12:50:24 pm Rickard Bellgrim wrote: > On 16 aug 2010, at 11.59, Sion Lloyd wrote: > > If a key has been in the dead state for long enough on zone "A", but is > > yet to be used by zone "B" on the policy, should we purge it? > > If the key is yet to be used by zone "B" and we remove it, won't we just > create a new key in the HSM to replace it? Thus not saving any space. If it has moved into the dead state on zone A a new key must have been created to satisfy the policy for zone A. > > My thought is that we should, because we are trying to save space on the > > HSM and there must be enough keys without this one to keep zone "A" > > happy. > > Would zone "B" be happy? Yes. It would never see this particular key, but that should not be an issue. I think that I will leave it as it is currently, where a key will only be purged if all of its instances are in the dead state. This is the easiest thing to do and can always be revisited later. Sion From owner-dnssec-trac at kirei.se Wed Aug 18 08:36:30 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Wed, 18 Aug 2010 08:36:30 -0000 Subject: [Opendnssec-develop] [OpenDNSSEC] #174: Error with SoftHSM installation prefix Message-ID: <088.f26c565e92cb9598c5eaca1ef01ef9f4@kirei.se> #174: Error with SoftHSM installation prefix ---------------------------------------------------------------+------------ Reporter: Paul van Brouwershaven | Owner: rb Type: defect | Status: new Priority: major | Component: SoftHSM Version: trunk | Keywords: ---------------------------------------------------------------+------------ {{{ ./configure --program-prefix=/opt/softhsm --with-botan=/opt/botan }}} Tries to install SoftHSM in "'''/usr/local/bin//opt/softhsmsofthsm'''" {{{ make[3]: Nothing to be done for `install-data-am'. make[3]: Leaving directory `/home/username/install/softhsm-1.1.4/src/lib' make[2]: Leaving directory `/home/username/install/softhsm-1.1.4/src/lib' Making install in bin make[2]: Entering directory `/home/username/install/softhsm-1.1.4/src/bin' make[3]: Entering directory `/home/username/install/softhsm-1.1.4/src/bin' test -z "/usr/local/bin" || /bin/mkdir -p "/usr/local/bin" /bin/sh ../../libtool --mode=install /usr/bin/install -c 'softhsm' '/usr/local/bin//opt/softhsmsofthsm' libtool: install: /usr/bin/install -c softhsm /usr/local/bin//opt/softhsmsofthsm /usr/bin/install: cannot create regular file `/usr/local/bin//opt/softhsmsofthsm': No such file or directory make[3]: *** [install-binPROGRAMS] Error 1 make[3]: Leaving directory `/home/username/install/softhsm-1.1.4/src/bin' make[2]: *** [install-am] Error 2 make[2]: Leaving directory `/home/username/install/softhsm-1.1.4/src/bin' make[1]: *** [install-recursive] Error 1 make[1]: Leaving directory `/home/username/install/softhsm-1.1.4/src' make: *** [install-recursive] Error 1 }}} -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Wed Aug 18 09:03:40 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Wed, 18 Aug 2010 09:03:40 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #174: Error with SoftHSM installation prefix In-Reply-To: <088.f26c565e92cb9598c5eaca1ef01ef9f4@kirei.se> References: <088.f26c565e92cb9598c5eaca1ef01ef9f4@kirei.se> Message-ID: <097.04bbcef09d7f1d30b81c736fa9a7f43a@kirei.se> #174: Error with SoftHSM installation prefix ---------------------------------------------------------------+------------ Reporter: Paul van Brouwershaven | Owner: rb Type: defect | Status: new Priority: major | Component: SoftHSM Version: trunk | Keywords: ---------------------------------------------------------------+------------ Comment(by Paul van Brouwershaven ): Sorry found the problem, it's --prefix instead of --program-prefix Ticket can be closed -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Wed Aug 18 14:35:06 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Wed, 18 Aug 2010 14:35:06 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #174: Error with SoftHSM installation prefix In-Reply-To: <088.f26c565e92cb9598c5eaca1ef01ef9f4@kirei.se> References: <088.f26c565e92cb9598c5eaca1ef01ef9f4@kirei.se> Message-ID: <097.095a0c09a2a4dfa9ae7fc60d9869ce29@kirei.se> #174: Error with SoftHSM installation prefix ---------------------------------------------------------------+------------ Reporter: Paul van Brouwershaven | Owner: rb Type: defect | Status: closed Priority: major | Component: SoftHSM Version: trunk | Resolution: invalid Keywords: | ---------------------------------------------------------------+------------ Changes (by matthijs): * status: new => closed * resolution: => invalid -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Thu Aug 19 00:29:03 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Thu, 19 Aug 2010 00:29:03 -0000 Subject: [Opendnssec-develop] [OpenDNSSEC] #175: RolloverNotification tag not documented Message-ID: <059.939b29f44407406e20678b6a3d809be7@kirei.se> #175: RolloverNotification tag not documented ----------------------------------+----------------------------------------- Reporter: sebastian@? | Owner: sion Type: defect | Status: new Priority: minor | Component: Enforcer Version: 1.1.1 | Keywords: ----------------------------------+----------------------------------------- In the documentation page you include a paragraph saying ---- This will appear in your logs at a time prior to the rollover as configured in conf.xml (the Enforcer/RolloverNotification tag). ---- but the details of the tag are not included in that page or the XML documentation in the trac site. A read to the XMLSchema gives you a hint the tag is expected to be a duration. Would a RolloverNotificationCommand be useful as well? -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Fri Aug 20 06:52:13 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Fri, 20 Aug 2010 06:52:13 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #168: Patch: ods-control with tightened control In-Reply-To: <045.2ab21e01d5a4fa83260cc4026b7a8205@kirei.se> References: <045.2ab21e01d5a4fa83260cc4026b7a8205@kirei.se> Message-ID: <054.81fc70dce22f57f8b133680b4d2f9dd4@kirei.se> #168: Patch: ods-control with tightened control ------------------------+--------------------------------------------------- Reporter: vanrein | Owner: rb Type: enhancement | Status: closed Priority: minor | Component: Unknown Version: 1.1.1 | Resolution: fixed Keywords: | ------------------------+--------------------------------------------------- Changes (by rb): * status: new => closed * resolution: => fixed Comment: Fixed in r3763 -- Ticket URL: OpenDNSSEC OpenDNSSEC From rickard.bellgrim at iis.se Fri Aug 20 07:04:02 2010 From: rickard.bellgrim at iis.se (Rickard Bellgrim) Date: Fri, 20 Aug 2010 09:04:02 +0200 Subject: [Opendnssec-develop] OpenDNSSEC 1.1.2 In-Reply-To: <896AA9E2-14C3-40A3-9D17-7D5F7E359241@iis.se> References: <896AA9E2-14C3-40A3-9D17-7D5F7E359241@iis.se> Message-ID: On 16 aug 2010, at 12.25, Rickard Bellgrim wrote: > We only had to fix the ods-control script before we could release v1.1.2. Do we have any status on this one? It is committed to branch and trunk. One more question, should we increase the required version of ldns to 1.6.6? http://trac.opendnssec.org/browser/branches/OpenDNSSEC-1.1/configure.ac#L24 http://trac.opendnssec.org/browser/branches/OpenDNSSEC-1.1/signer/configure.ac#L47 http://trac.opendnssec.org/browser/branches/OpenDNSSEC-1.1/libhsm/configure.ac#L63 http://trac.opendnssec.org/browser/branches/OpenDNSSEC-1.1/enforcer/configure.ac#L88 http://trac.opendnssec.org/browser/branches/OpenDNSSEC-1.1/plugins/eppclient/configure.ac#L46 Is there someone who also can test the OpenDNSSEC 1.1.2 before we release it? // Rickard From AlexD at nominet.org.uk Fri Aug 20 07:18:34 2010 From: AlexD at nominet.org.uk (Alex Dalitz) Date: Fri, 20 Aug 2010 07:18:34 +0000 Subject: [Opendnssec-develop] OpenDNSSEC 1.1.2 In-Reply-To: References: <896AA9E2-14C3-40A3-9D17-7D5F7E359241@iis.se> Message-ID: > One more question, should we increase the required version of ldns to 1.6.6? I fixed a minor bug in dnsruby as well (Matthijs noticed that the zone reader was sometimes chopping the last character of a heavily-escaped TXT record). It might be an idea to make a new release with this in and bump the required version for ODS. Alex. From rick at openfortress.nl Fri Aug 20 07:43:47 2010 From: rick at openfortress.nl (Rick van Rein) Date: Fri, 20 Aug 2010 07:43:47 +0000 Subject: [Opendnssec-develop] OpenDNSSEC 1.1.2 In-Reply-To: References: <896AA9E2-14C3-40A3-9D17-7D5F7E359241@iis.se> Message-ID: <20100820074347.GB20386@phantom.vanrein.org> Hi Rickard, > > We only had to fix the ods-control script before we could release v1.1.2. Do we have any status on this one? > > It is committed to branch and trunk. Thanks. > One more question, should we increase the required version of ldns to 1.6.6? Yes, indeed. Without it, the zone_fetcher is at risk of freezing if it gets into a troublesome situation. LDNS 1.6.6 is the way to go. -Rick From owner-dnssec-trac at kirei.se Fri Aug 20 09:04:53 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Fri, 20 Aug 2010 09:04:53 -0000 Subject: [Opendnssec-develop] [OpenDNSSEC] #176: Error in /etc/init.d/opendnssec-signer on ubuntu Message-ID: <051.a7225fe2ce1a982c9bb9bb770d47b771@kirei.se> #176: Error in /etc/init.d/opendnssec-signer on ubuntu --------------------------+------------------------------------------------- Reporter: pbw@? | Owner: rb Type: defect | Status: new Priority: minor | Component: Unknown Version: trunk | Keywords: --------------------------+------------------------------------------------- service opendnssec-signer status always returns "not running". The problem occurs because the pid file is stored in /var/run/opendnssec,rather than /var/run. Easiest way to fix it seems to be to change the call to status_of_proc in the status) case from status_of_proc "$DAEMON" "$NAME" && exit 0 || exit $? to status_of_proc -p $PIDFILE "$DAEMON" "$NAME" && exit 0 || exit $? A similar fix should be applied to /etc/init.d/opendnssec-enforcer, althohg it manages to work in spite of the pid file not being found, because the named $DAEMON is still running when the status check is made. This is not the case for the singer. -- Ticket URL: OpenDNSSEC OpenDNSSEC From rickard.bellgrim at iis.se Mon Aug 23 06:43:53 2010 From: rickard.bellgrim at iis.se (Rickard Bellgrim) Date: Mon, 23 Aug 2010 08:43:53 +0200 Subject: [Opendnssec-develop] Meeting 2010-08-24 Message-ID: <470A8617-7D01-40DE-948C-AB4EB8579954@iis.se> Hi Next meeting is tomorrow. The draft agenda can be found here: http://trac.opendnssec.org/wiki/Meetings/Agenda/2010-08-24 Please add any topics you might have. // Rickard From jakob at kirei.se Mon Aug 23 11:30:27 2010 From: jakob at kirei.se (Jakob Schlyter) Date: Mon, 23 Aug 2010 13:30:27 +0200 Subject: [Opendnssec-develop] socket for command and control? Message-ID: hi, how much work would it take to add a socket command and control interface to the enforcer and the signer engine? it would be good if we could get rid of the pid-files for version 1.2. jakob From sion at nominet.org.uk Mon Aug 23 12:11:42 2010 From: sion at nominet.org.uk (Sion Lloyd) Date: Mon, 23 Aug 2010 13:11:42 +0100 Subject: [Opendnssec-develop] socket for command and control? In-Reply-To: References: Message-ID: <201008231311.42722.sion@nominet.org.uk> > how much work would it take to add a socket command and control interface > to the enforcer and the signer engine? it would be good if we could get > rid of the pid-files for version 1.2. I've never written code for this, but from a position of no experience it doesn't seem like it should be too hard... Matthijs: have you ever done this in c? I guess that we only need one of us to write it and add it to the common code? Sion From matthijs at NLnetLabs.nl Tue Aug 24 09:01:11 2010 From: matthijs at NLnetLabs.nl (Matthijs Mekking) Date: Tue, 24 Aug 2010 11:01:11 +0200 Subject: [Opendnssec-develop] socket for command and control? In-Reply-To: <201008231311.42722.sion@nominet.org.uk> References: <201008231311.42722.sion@nominet.org.uk> Message-ID: <4C738A57.9000901@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, The signer engine already works with a such a control interface: ods-signer. I think you can copy most of the code, though I do include my internal logging and malloc header files. The client side is implemented in signer/src/ods-signer.c. The server side is covered by signer/src/daemon/cmdhandler.{c,h}. The latter does depend on some more signer engine specific code, but merely to be able to execute the commands, rather than handling them. I think it would be good to keep the pidfiles, but don't rely on them for starting and stopping services. Best regards, Matthijs On 08/23/2010 02:11 PM, Sion Lloyd wrote: >> how much work would it take to add a socket command and control interface >> to the enforcer and the signer engine? it would be good if we could get >> rid of the pid-files for version 1.2. > > I've never written code for this, but from a position of no experience it > doesn't seem like it should be too hard... > > Matthijs: have you ever done this in c? I guess that we only need one of us to > write it and add it to the common code? > > Sion > _______________________________________________ > Opendnssec-develop mailing list > Opendnssec-develop at lists.opendnssec.org > https://lists.opendnssec.org/mailman/listinfo/opendnssec-develop -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJMc4pXAAoJEA8yVCPsQCW5FuAIAMGWCNyms59RWdsRQxK/Bbul QOCMCme9aB1SlHX4lAyRI7SLdxW8Tm9+eEjuwtuVS7EGxjeoLiaupKq/qgVO0yvo Bfa7TA8pKxENUfXoPJ0XrcQPy7whMrXbnkrUNMF7LdsSmhQoCw8BSAgzoIWmGR8W tO8jJbrhWjdC9ANBqdCYCEbxhCxwHI/L2caCUJ9kNGEO2rpALssw0V7XqoFCAC9w R+G3hOrCd8ynmHptzRSqfc2UKGDCS+cjSkJcrkWrbJmwu18DVG9TJLdt5+7MtkYN zqhbWmZH7w0oLsW41lmBmwk511F8Xwd0pzgXweT76oBheis912jlLIuiTLj0T7A= =XFAd -----END PGP SIGNATURE----- From jakob at kirei.se Tue Aug 24 10:58:27 2010 From: jakob at kirei.se (Jakob Schlyter) Date: Tue, 24 Aug 2010 12:58:27 +0200 Subject: [Opendnssec-develop] socket for command and control? In-Reply-To: <4C738A57.9000901@nlnetlabs.nl> References: <201008231311.42722.sion@nominet.org.uk> <4C738A57.9000901@nlnetlabs.nl> Message-ID: On 24 aug 2010, at 11.01, Matthijs Mekking wrote: > I think it would be good to keep the pidfiles, but don't rely on them > for starting and stopping services. what use do you see for them? I'd like to remove them, I see no good coming from them. jakob From AlexD at nominet.org.uk Tue Aug 24 13:00:49 2010 From: AlexD at nominet.org.uk (Alex Dalitz) Date: Tue, 24 Aug 2010 13:00:49 +0000 Subject: [Opendnssec-develop] Minutes Message-ID: <75EEDB59-42E4-4CA5-B0C0-950FE2D21272@nominet.org.uk> Hi - Here are the minutes. Sorry about errors - haven't done this before... http://trac.opendnssec.org/wiki/Meetings/Minutes/2010-08-24 Please let me know of / fix any issues. Thanks, Alex. From rick at openfortress.nl Tue Aug 24 13:15:26 2010 From: rick at openfortress.nl (Rick van Rein) Date: Tue, 24 Aug 2010 13:15:26 +0000 Subject: [Opendnssec-develop] Key shananigans in 1.1.[12] Message-ID: <20100824131526.GB10262@phantom.vanrein.org> Hey Sion, Thanks for willing to help with this problem. Our database contains keys that are generated and backed up, so we know that our patch of the backup mechanisms is not the root of the problem. It would appear that the key publication logic needs a hint of some sort. Any suggestion how we could accomplish that? mysql> select id,policy_id,size,state,generate,backup,publish,ready from keypairs where policy_id=24; +-----+-----------+------+-------+---------------------+---------------------+---------------------+---------------------+ | id | policy_id | size | state | generate | backup | publish | ready | +-----+-----------+------+-------+---------------------+---------------------+---------------------+---------------------+ | 163 | 24 | 2048 | 6 | 2010-08-04 12:30:04 | 2010-08-04 12:31:00 | 2010-08-04 12:31:01 | 2010-08-05 02:45:02 | | 164 | 24 | 1024 | 6 | 2010-08-04 12:30:04 | 2010-08-04 12:31:00 | 2010-08-04 12:31:01 | NULL | | 165 | 24 | 1024 | 6 | 2010-08-04 12:30:04 | 2010-08-04 12:31:00 | 2010-08-04 12:31:01 | 2010-08-05 02:45:02 | | 184 | 24 | 2048 | 1 | 2010-08-23 13:45:59 | 2010-08-23 17:05:23 | NULL | NULL | | 185 | 24 | 1024 | 1 | 2010-08-23 13:45:59 | 2010-08-23 17:05:23 | NULL | NULL | | 186 | 24 | 1024 | 1 | 2010-08-23 13:45:59 | 2010-08-23 17:05:23 | NULL | NULL | +-----+-----------+------+-------+---------------------+---------------------+---------------------+---------------------+ Thanks, -Rick From rick at openfortress.nl Tue Aug 24 13:52:35 2010 From: rick at openfortress.nl (Rick van Rein) Date: Tue, 24 Aug 2010 13:52:35 +0000 Subject: [Opendnssec-develop] Re: Key shananigans in 1.1.[12] In-Reply-To: <20100824131526.GB10262@phantom.vanrein.org> References: <20100824131526.GB10262@phantom.vanrein.org> Message-ID: <20100824135235.GD10262@phantom.vanrein.org> Sion, I'm tracing KsmKeyGetUnallocated in ksm/ksm_key.c and repeating its query, select * from KEYDATA_VIEW where policy_id=24 and securitymodule_id=2 and size=1024 and algorithm=7 and state=1 and zone_id=143; This would yield two keys. But in KsmKeyGetUnallocated the requirement ends with ... and zone_id=NULL; 1. Why is "NULL" used here and not the zone? 2. "select NULL=NULL" never yields a positive reply, it should be "select NULL is NULL" (but I may be misreading your SQL-generators). Does that help? As for the direct cause: We traced this down to our web-developer accidentally removing all zones and re-creating them. Still, if the above is the problem, it seems important to resolve it as it would likely pop up sometime. Thanks, -Rick From sion at nominet.org.uk Tue Aug 24 13:54:22 2010 From: sion at nominet.org.uk (Sion Lloyd) Date: Tue, 24 Aug 2010 14:54:22 +0100 Subject: [Opendnssec-develop] Re: Key shananigans in 1.1.[12] In-Reply-To: <20100824131526.GB10262@phantom.vanrein.org> References: <20100824131526.GB10262@phantom.vanrein.org> Message-ID: <201008241454.22212.sion@nominet.org.uk> On Tuesday 24 Aug 2010 2:15:26 pm Rick van Rein wrote: > Hey Sion, > > Thanks for willing to help with this problem. No problem. When i've seen this before the cause was that in order to speed things up I used some logic that is not quite true when zones have been added after the initial setup. i will have to look through my notes to find the exact cause, and my notes are in a mess because I have moved desks :( The previous solution was to generate lots of keys, this fixes one issue, but the problem is not actually a lack of keys, it is a fault in assigning those keys to zones. I'll have a deeper look. Sion From AlexD at nominet.org.uk Tue Aug 24 14:07:27 2010 From: AlexD at nominet.org.uk (Alex Dalitz) Date: Tue, 24 Aug 2010 14:07:27 +0000 Subject: [Opendnssec-develop] Re: Key shananigans in 1.1.[12] In-Reply-To: <20100824135235.GD10262@phantom.vanrein.org> References: <20100824131526.GB10262@phantom.vanrein.org> <20100824135235.GD10262@phantom.vanrein.org> Message-ID: <63752963-3910-4CB1-9ADC-746EC602A7FF@nominet.org.uk> > As for the direct cause: We traced this down to our web-developer accidentally removing all > zones and re-creating them. I have experienced this error through this route several times. Alex. From rick at openfortress.nl Tue Aug 24 14:47:48 2010 From: rick at openfortress.nl (Rick van Rein) Date: Tue, 24 Aug 2010 14:47:48 +0000 Subject: [Opendnssec-develop] Re: Key shananigans in 1.1.[12] In-Reply-To: <63752963-3910-4CB1-9ADC-746EC602A7FF@nominet.org.uk> References: <20100824131526.GB10262@phantom.vanrein.org> <20100824135235.GD10262@phantom.vanrein.org> <63752963-3910-4CB1-9ADC-746EC602A7FF@nominet.org.uk> Message-ID: <20100824144748.GB12556@phantom.vanrein.org> Hi all, > > As for the direct cause: We traced this down to our web-developer accidentally removing all > > zones and re-creating them. > > I have experienced this error through this route several times. That's interesting -- is the cause of this error 1. Dropping all zones, or 2. Dropping some zones? Anyone with experience to separate this out? Thanks, -Rick From AlexD at nominet.org.uk Tue Aug 24 14:49:46 2010 From: AlexD at nominet.org.uk (Alex Dalitz) Date: Tue, 24 Aug 2010 14:49:46 +0000 Subject: [Opendnssec-develop] Re: Key shananigans in 1.1.[12] In-Reply-To: <20100824144748.GB12556@phantom.vanrein.org> References: <20100824131526.GB10262@phantom.vanrein.org> <20100824135235.GD10262@phantom.vanrein.org> <63752963-3910-4CB1-9ADC-746EC602A7FF@nominet.org.uk> <20100824144748.GB12556@phantom.vanrein.org> Message-ID: <4B3BE64A-3CCE-49D2-875E-25F6C3CE2157@nominet.org.uk> >>> As for the direct cause: We traced this down to our web-developer accidentally removing all >>> zones and re-creating them. >> >> I have experienced this error through this route several times. > > > That's interesting -- is the cause of this error > > 1. Dropping all zones, or > 2. Dropping some zones? Dropping some zones. I'm not sure I have ever dropped all zones. Normally, I remove a single zone, and then try to add it again. This often causes this error for me. HTH, Alex. From owner-dnssec-trac at kirei.se Wed Aug 25 01:06:26 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Wed, 25 Aug 2010 01:06:26 -0000 Subject: [Opendnssec-develop] [OpenDNSSEC] #177: ods-control stucks if enforcer is dead Message-ID: <059.51e1c6c7f1497a515487a34ffeb43187@kirei.se> #177: ods-control stucks if enforcer is dead ----------------------------------+----------------------------------------- Reporter: sebastian@? | Owner: sion Type: defect | Status: new Priority: minor | Component: Enforcer Version: trunk | Keywords: ----------------------------------+----------------------------------------- If enforcer doesn't die gracefully, the command 'ods-control stop' will enter a loop and never leave waiting the enforcer_pid_file to be deleted. Please find attached a patch that solves this issue. -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Wed Aug 25 07:23:55 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Wed, 25 Aug 2010 07:23:55 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #177: ods-control stucks if enforcer is dead In-Reply-To: <059.51e1c6c7f1497a515487a34ffeb43187@kirei.se> References: <059.51e1c6c7f1497a515487a34ffeb43187@kirei.se> Message-ID: <068.73764afe8a6d64e7f00260ddf868f21e@kirei.se> #177: ods-control stucks if enforcer is dead ----------------------------------+----------------------------------------- Reporter: sebastian@? | Owner: sion Type: defect | Status: new Priority: minor | Component: Enforcer Version: trunk | Keywords: ----------------------------------+----------------------------------------- Comment(by vanrein): Hello Sebastian, We realise that the PID logic has its limitations, and you seem to have run into an example where it takes refining to make it behave well. We are heading towards a command channel for the enforcer to replace this sort of problem. Meanwhile, there is an advantage to knowing that something goes wrong (getting stuck raises your attention) but if this is a problem to you, you could maybe use ps in the loop, to ensure that the Enforcer is actually alive and well. Sounds like a recipe for race conditions, though. More importantly, did you actually encounter this problem? We've been running this ods-control version for weeks without running into it. If your enforcer dies, that would make a very interesting bug report. What you are reporting here is more a symptom than the actual problem itself, right? Cheers, -Rick -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Wed Aug 25 21:42:02 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Wed, 25 Aug 2010 21:42:02 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #177: ods-control stucks if enforcer is dead In-Reply-To: <059.51e1c6c7f1497a515487a34ffeb43187@kirei.se> References: <059.51e1c6c7f1497a515487a34ffeb43187@kirei.se> Message-ID: <068.b226db8be3c5f3fb7ab73c8f57082dc7@kirei.se> #177: ods-control stucks if enforcer is dead ----------------------------------+----------------------------------------- Reporter: sebastian@? | Owner: sion Type: defect | Status: new Priority: minor | Component: Enforcer Version: trunk | Keywords: ----------------------------------+----------------------------------------- Comment(by sebastian@?): Hello Rick, I'm aware the PID has some limitations, but there is also some use cases (Ondrej described them well in the mailing list). In some cases, like a unattended shutdown, being stuck will cause a pain not attention. I felt tempted to loop on the PID and check if it was running or not, the problem is the flags available for ps varies from SO. In Linux is easy to use ps -p PID, but doesn't work that way in Solaris or FreeBSD. I actually encountered the problem: I upgraded from 1.1.0 to the trunk version (that seems to be 1.1.2 now) and forgot to migrate the KASP DB. Enforcerd complained with "ERROR: database version number incompatible with software; require 2, found 1. Please run the migration scripts" and left the PID file behind. So I tripped on the problem and tested a way to go around it, it worked in my case. cheers, Sebastian -- Ticket URL: OpenDNSSEC OpenDNSSEC From rickard.bellgrim at iis.se Thu Aug 26 08:23:48 2010 From: rickard.bellgrim at iis.se (Rickard Bellgrim) Date: Thu, 26 Aug 2010 10:23:48 +0200 Subject: [Opendnssec-develop] Performance In-Reply-To: References: <4E7D1B82-8A21-43C6-98BC-659C5BFD8090@iis.se> <52EB5931-A75C-4921-958C-E21421888FAB@iis.se> Message-ID: On 12 aug 2010, at 10.31, Rickard Bellgrim wrote: > [STATS] se RR[count=2167209 time=52(sec)) NSEC[count=926590 time=9(sec)] RRSIG[new=930497 reused=0 time=898(sec) avg=1036(sig/sec)] The Signer Engine is now so fast that we are reaching the limit of what you can get from a single threaded application: [STATS] se RR[count=2167209 time=52(sec)) NSEC[count=926590 time=8(sec)] RRSIG[new=930497 reused=0 time=406(sec) avg=2291(sig/sec)] TOTAL[time=501(sec)] The Sun SCA600 is limited to around 2500 sig/sec with the ods-hsmspeed and one thread. // Rickard From sion at nominet.org.uk Thu Aug 26 08:50:02 2010 From: sion at nominet.org.uk (Sion Lloyd) Date: Thu, 26 Aug 2010 09:50:02 +0100 Subject: [Opendnssec-develop] Pivotal stories Message-ID: <201008260950.02895.sion@nominet.org.uk> Hi, I'd just like to check that I remember the pivotal stories correctly before I assign points to them... ksmutil zone add/delete without implicit export This is just a facility to do the database stuff but not update zonelist.xml right? ksmutil policy import/export literally just an alias so that "ods-ksmutil policy import" does the same job as "ods-ksmutil update kasp"? Or should it take a policy name as an argument so that you can just import a single policy from kasp.xml? ksmutil zonelist import/export I think that these are just aliases for existing commands to be consistent? Does this agree with what you think we discussed at the codesprint? Sion From jakob at kirei.se Thu Aug 26 09:04:08 2010 From: jakob at kirei.se (Jakob Schlyter) Date: Thu, 26 Aug 2010 11:04:08 +0200 Subject: [Opendnssec-develop] Pivotal stories In-Reply-To: <201008260950.02895.sion@nominet.org.uk> References: <201008260950.02895.sion@nominet.org.uk> Message-ID: <3C2E5B66-78A4-477B-8B46-550E703E8C20@kirei.se> On 26 aug 2010, at 10.50, Sion Lloyd wrote: > ksmutil zone add/delete without implicit export > This is just a facility to do the database stuff but not update > zonelist.xml right? yes. > ksmutil policy import/export > literally just an alias so that "ods-ksmutil policy import" does the same > job as "ods-ksmutil update kasp"? Or should it take a policy name as an > argument so that you can just import a single policy from kasp.xml? I think we can start of with importing/exporting all policies at once. > ksmutil zonelist import/export > I think that these are just aliases for existing commands to be > consistent? yes, I believe so. jakob From owner-dnssec-trac at kirei.se Thu Aug 26 11:14:09 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Thu, 26 Aug 2010 11:14:09 -0000 Subject: [Opendnssec-develop] [OpenDNSSEC] #178: Specifications of time/duration divert from specifications Message-ID: <047.6032d9898b2f707547664df144c5ac76@kirei.se> #178: Specifications of time/duration divert from specifications ----------------------+----------------------------------------------------- Reporter: anonymous | Owner: sion Type: defect | Status: new Priority: trivial | Component: Enforcer Version: trunk | Keywords: ----------------------+----------------------------------------------------- The ISO-format for the specification of timing allows combinations of a number of factors, P3Y6M4DT12H30M5S whereas the DtXMLIntervalSeconds function contains no loop and can only select single time factors, P4Y -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Thu Aug 26 11:24:10 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Thu, 26 Aug 2010 11:24:10 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #178: Specifications of time/duration divert from specifications In-Reply-To: <047.6032d9898b2f707547664df144c5ac76@kirei.se> References: <047.6032d9898b2f707547664df144c5ac76@kirei.se> Message-ID: <056.7e69d4cbf8f9051a281373fb39de4e84@kirei.se> #178: Specifications of time/duration divert from specifications ----------------------+----------------------------------------------------- Reporter: anonymous | Owner: sion Type: defect | Status: accepted Priority: trivial | Component: Enforcer Version: trunk | Keywords: ----------------------+----------------------------------------------------- Changes (by sion): * status: new => accepted Comment: Thank you. This is a known issue and is on our work list. We are hoping to get this fixed for v1.2 -- Ticket URL: OpenDNSSEC OpenDNSSEC From sion at nominet.org.uk Fri Aug 27 07:23:50 2010 From: sion at nominet.org.uk (Sion Lloyd) Date: Fri, 27 Aug 2010 08:23:50 +0100 Subject: [Opendnssec-develop] Bug fixes Message-ID: <201008270823.50795.sion@nominet.org.uk> I have a number of bug fixes to make in trunk, see pivotal for details. Does anyone think that any of these are serious enough that they need patching back into the 1.1 branch? I wasn't going to, but if there is going to be a 1.1.3 then maybe it is worthwhile? Something to talk about next Wednesday maybe. Sion From owner-dnssec-trac at kirei.se Fri Aug 27 15:40:57 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Fri, 27 Aug 2010 15:40:57 -0000 Subject: [Opendnssec-develop] [OpenDNSSEC] #179: Auditor problem with srv records and hypens Message-ID: <077.927b5a6fb972cd2aea5c0b1df8e88eb4@kirei.se> #179: Auditor problem with srv records and hypens ------------------------------------------------------+--------------------- Reporter: P?sztor J?nos | Owner: alex Type: defect | Status: new Priority: critical | Component: Auditor Version: 1.1.1 | Keywords: ------------------------------------------------------+--------------------- Hi! I've installed OpenDNSSEC 1.1.1, ldns 1.6.6 from source, every other dependency from the lenny repositories. I've tried to sign my zone with the default policy, and the auditing has failed. I've isolated the problem, and made an example.com zone where you could reproduce the problem. Here is the zone: {{{ $TTL 1d @ 2560 IN SOA ns.example.com. (hostmaster.example.com. 2010082201 7200 300 1048576 2560) @ IN NS ns ns A 145.23.12.65 a A 156.123.123.123 b A 156.123.123.123 c A 156.123.123.123 hypen-hypen A 145.23.12.65 i A 156.123.123.123 j A 156.123.123.123 k A 156.123.123.123 nk A 156.123.123.123 _sip._udp.niif-deverto 86400 IN SRV 10 10 5060 deverto2.example2.com. _sip._udp.niif-deverto 86400 IN SRV 10 20 5060 deverto1.example2.com. _sip._udp.niif-deverto 86400 IN SRV 20 0 5060 deverto2.example2.com. nv A 156.123.123.123 }}} And here is the error message: {{{ Aug 27 17:20:10 iszt ods-auditor[2905]: Auditor started Aug 27 17:20:10 iszt ods-auditor[2905]: Auditor starting on example.com Aug 27 17:20:10 iszt ods-auditor[2905]: SOA differs : from 2010082201 to 2010082700 Aug 27 17:20:10 iszt ods-auditor[2905]: Auditing example.com zone : NSEC3 SIGNED Aug 27 17:20:10 iszt ods-auditor[2905]: Can't find NSEC3 for empty nonterminal niif-deverto.example.com (should be nu9ts1ij799r0lgfgbp9n39hlt1tkk0m.example.com) Aug 27 17:20:10 iszt ods-auditor[2905]: Finished auditing example.com zone }}} If you set 1 in conf.xml (8 thread is too much noise in syslog) and the auditing is failed, and you've got another zones in OpenDNSSEC, they won't be signed! From syslog {{{ Aug 27 17:20:10 iszt ods-signerd: Auditor result: 3 Aug 27 17:20:10 iszt ods-signerd: worker 1 acquiring lock Aug 27 17:20:10 iszt ods-signerd: worker 1 acquired lock Aug 27 17:20:10 iszt ods-signerd: no task for worker 1, sleep for 7195.82540584 Aug 27 17:20:10 iszt ods-signerd: worker 1 released lock by going to wait (for ttime) }}} -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Fri Aug 27 16:05:52 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Fri, 27 Aug 2010 16:05:52 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #179: Auditor problem with srv records and hypens In-Reply-To: <077.927b5a6fb972cd2aea5c0b1df8e88eb4@kirei.se> References: <077.927b5a6fb972cd2aea5c0b1df8e88eb4@kirei.se> Message-ID: <086.4de8311c125bf6d99170d7c89bd53e2d@kirei.se> #179: Auditor problem with srv records and hypens ------------------------------------------------------+--------------------- Reporter: P?sztor J?nos | Owner: alex Type: defect | Status: new Priority: critical | Component: Auditor Version: 1.1.1 | Keywords: ------------------------------------------------------+--------------------- Comment(by P?sztor J?nos ): Sorry, i've just noticed that there is 1.1.2 and the empty nonterminals problem get fixed! -- Ticket URL: OpenDNSSEC OpenDNSSEC From rickard.bellgrim at iis.se Tue Aug 31 12:30:34 2010 From: rickard.bellgrim at iis.se (Rickard Bellgrim) Date: Tue, 31 Aug 2010 14:30:34 +0200 Subject: [Opendnssec-develop] Default InceptionOffset Message-ID: Hi We have one hour as the default inception offset in kasp.xml, but the ods-kaspcheck gives as warning if it is greater than 10 minutes. Should we change the default value or the requirements of the ods-kaspcheck? // Rickard From sion at nominet.org.uk Tue Aug 31 13:44:28 2010 From: sion at nominet.org.uk (Sion Lloyd) Date: Tue, 31 Aug 2010 14:44:28 +0100 Subject: [Opendnssec-develop] trunk/utils directory Message-ID: <201008311444.28857.sion@nominet.org.uk> Hi there. I'm not sure if I am doing the right thing, I just want to check. I want to add a #define ODS_SE_KASPCHECK to config.h to check for the existance of, and run, ods-kaspcheck as per pivotal story 3998557. So what I did was edit trunk/utils/m4/opendnssec_common.m4 and then run make install which copies that file into the OpenDNSSEC directory... See svn status and diff below. Is this right? I assume that acx_cunit.m4 apparently changing has nothing to do with me and I won't commit it. Cheers, Sion sion at sion:~/temp/opendnssec/trunk$ svn status -q M hsmbully/m4/acx_cunit.m4 M utils/m4/opendnssec_common.m4 M OpenDNSSEC/m4/opendnssec_common.m4 M OpenDNSSEC/plugins/eppclient/m4/opendnssec_common.m4 M OpenDNSSEC/auditor/m4/opendnssec_common.m4 sion at sion:~/temp/opendnssec/trunk$ svn diff utils/m4/opendnssec_common.m4 Index: utils/m4/opendnssec_common.m4 =================================================================== --- utils/m4/opendnssec_common.m4 (revision 3830) +++ utils/m4/opendnssec_common.m4 (working copy) @@ -60,6 +60,7 @@ OPENDNSSEC_SIGNER_SOCKET=$OPENDNSSEC_PID_DIR/engine.sock OPENDNSSEC_SIGNER_ENGINE=$OPENDNSSEC_SBIN_DIR/ods-signerd OPENDNSSEC_SIGNER_AUDITOR=$OPENDNSSEC_BIN_DIR/ods-auditor +OPENDNSSEC_SIGNER_KASPCHECK=$OPENDNSSEC_BIN_DIR/ods-kaspcheck OPENDNSSEC_SIGNER_CLI=$OPENDNSSEC_SBIN_DIR/ods-signer AC_SUBST([OPENDNSSEC_SIGNER_SOCKET]) @@ -79,5 +80,6 @@ AC_DEFINE_UNQUOTED(ODS_SE_ENGINE, ["$OPENDNSSEC_SIGNER_ENGINE -vvv"], [Path to the OpenDNSSEC signer engine binary]) AC_DEFINE_UNQUOTED(ODS_SE_CLI, ["$OPENDNSSEC_SIGNER_CLI"], [Path to the OpenDNSSEC signer client binary]) AC_DEFINE_UNQUOTED(ODS_SE_AUDITOR, ["$OPENDNSSEC_SIGNER_AUDITOR"], [Path to the OpenDNSSEC auditor binary]) +AC_DEFINE_UNQUOTED(ODS_SE_KASPCHECK, ["$OPENDNSSEC_SIGNER_KASPCHECK"], [Path to the OpenDNSSEC kaspcheck binary]) ]) From rickard.bellgrim at iis.se Tue Aug 31 14:12:58 2010 From: rickard.bellgrim at iis.se (Rickard Bellgrim) Date: Tue, 31 Aug 2010 16:12:58 +0200 Subject: [Opendnssec-develop] ACX_LDNS and ldns-config Message-ID: Hi A colleague of mine is trying to install OpenDNSSEC on Red Hat. He is using some of the packages from Tim, e.g. the ldns package, but installing OpenDNSSEC from source (wants to enable the eppclient). The configure script complains if he does not have the openssl headers installed. This is what the config.log says: configure:4164: checking what are the ldns libs configure:4167: result: -L/usr/lib64 -lnsl -lcrypto -L/usr/lib64/python2.4 -L/usr/lib64 -lpython2.4 -lcrypto -lldns configure:4189: checking for ldns_rr_new in -lldns configure:4214: gcc -o conftest -g -O2 -I/usr/include conftest.c -lldns -L/usr/lib64 -lnsl -lcrypto -L/usr/lib64/python2.4 -L/usr/lib64 -lpython2.4 -lcrypto -lldns >&5 /usr/bin/ld: cannot find -lcrypto collect2: ld returned 1 exit status Libcrypto is installed but it is really strange that the problem gets fixed when he installs the openssl headers. My ldns-config only give me this (no lcrypto) and not the long strings as above: $ ldns-config --libs -L/usr/local/lib -lldns $ ldns-config --cflags -I/usr/local/include What could be the problem here? // Rickard