From sion at nominet.org.uk Mon Oct 3 08:16:34 2011 From: sion at nominet.org.uk (=?UTF-8?B?U2nDtG4gTGxveWQ=?=) Date: Mon, 3 Oct 2011 09:16:34 +0100 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #262: Possible race condition causing CPU-bound loop in signerd? In-Reply-To: References: <056.e2e409b68e66b5e253aa981539dcf486@kirei.se> <071.95e6f7d3790ab20828dc8a58b19ab27d@kirei.se> Message-ID: <4E896F62.4000107@nominet.org.uk> Sorry about the delay in the two emails that have just appeared in this thread, they were stuck in the moderation queue and I have been away. Sion From matthijs at NLnetLabs.nl Mon Oct 3 09:23:19 2011 From: matthijs at NLnetLabs.nl (Matthijs Mekking) Date: Mon, 03 Oct 2011 11:23:19 +0200 Subject: [Opendnssec-develop] Re: Signer does not update TTL on RRs unless there is change in RDATA In-Reply-To: References: Message-ID: <4E897F07.6070709@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 09/30/2011 04:33 PM, Jerry Lundstr?m wrote: > Hi, > > Patrik reported this problem today and its very easy to replicate in > 1.3.2, just change the $TTL and issue a resign of the zone. Since there > is no RDATA change the TTL does not get changed in the signed zone. Hm yes: for the sake of comparing RRs, checking the TTL values should be omitted. > This is because util_dnssec_rrs_compare() uses ldns_rr_compare_wire() > and that only checks for changes in RDATA. > > Before I commit this fix that I've tested, I wanted to check if this can > break anything else? This indeed sets the new TTL on the RRs in the signed zone, but not yet the RRSIG TTL and the Original TTL field. Although it is the same RR, a new signature should be created as well (3.1.8.1. Signature Calculation [RFC4034]). > I can't see if this is a problem in trunk since it seems that most of > the rr/rrset code has been changed. As far as I can see it, it also applies to trunk. > /Jerry > > Index: branches/OpenDNSSEC-1.3/signer/src/signer/rrset.c > =================================================================== > --- branches/OpenDNSSEC-1.3/signer/src/signer/rrset.c(revision 5654) > +++ branches/OpenDNSSEC-1.3/signer/src/signer/rrset.c(working copy) > @@ -474,6 +474,9 @@ > > current = current->next; > } else { /* equal RRs */ > + /* TTL is not compared in util_dnssec_rrs_compare() so we copy > it */ > + ldns_rr_set_ttl(current->rr, ldns_rr_ttl(pending->rr)); > + > /* remove pending RR */ > if (!prev) { > rrset->add = pending->next; > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJOiX8GAAoJEA8yVCPsQCW5IdgH/RZAmnrO/7QxWXclRV8+GCvd uJL3TezitPMMOdghcA851nSBe3JZ+0vJWcMmTZ3ca+Rear1U8oGSU1L5q2Oel0wB fW7Gx91sguxV8V+7MNyyAJuvToFKr1FB2gFl3vAPJ16Boj4vkgzWafAVTrhHIKk+ VA+ss/QXJTV2W6QgGilsTraQPhlFjJpsxrDkO8fshCpQBv3nwewTn/kH3AqHqxxs rqYYmveNDkyXtfgrDK6zCVi/NA/iK4vXrUlNvyY0N+XHcw3X1ipJLFXxYIoE049N ZlAxxHDiQAgYl/3FPnSCvXHvXZ6SYv70sg7I1HAVeXBNRyr7JoOCikYlpWihoOw= =gYWg -----END PGP SIGNATURE----- From jerry at opendnssec.org Mon Oct 3 12:40:23 2011 From: jerry at opendnssec.org (Jerry =?ISO-8859-1?B?THVuZHN0cvZt?=) Date: Mon, 03 Oct 2011 14:40:23 +0200 Subject: [Opendnssec-develop] Supported build dependency for libraries etc Message-ID: Hi, We got a few dependencies for OpenDNSSEC/SoftHSM and now that we are getting the build farm ready I would like for us to decide if we are going to support distributions (and their own packages of our dependencies) or if we are going to support specific versions of our dependencies? This will impact how we set up the build farm environment, just update the dist or build the library our self. /Jerry -------------- next part -------------- An HTML attachment was scrubbed... URL: From jad at sinodun.com Tue Oct 4 11:37:31 2011 From: jad at sinodun.com (John Dickinson) Date: Tue, 4 Oct 2011 12:37:31 +0100 Subject: [Opendnssec-develop] Supported build dependency for libraries etc In-Reply-To: References: Message-ID: <3DEC21FF-D942-49E7-8880-2BFC05963B6E@sinodun.com> On 3 Oct 2011, at 13:40, Jerry Lundstr?m wrote: > Hi, > > We got a few dependencies for OpenDNSSEC/SoftHSM and now that we are getting the build farm ready I would like for us to decide if we are going to support distributions (and their own packages of our dependencies) or if we are going to support specific versions of our dependencies? > > This will impact how we set up the build farm environment, just update the dist or build the library our self. > > /Jerry > _______________________________________________ > Opendnssec-develop mailing list > Opendnssec-develop at lists.opendnssec.org > https://lists.opendnssec.org/mailman/listinfo/opendnssec-develop The dependancies fall into 3 camps: 1: ruby dnsruby ldns libxml2 botan cunit cucumber 2: things like gcc, gnu autotools and various compatibility libraries depending on OS. 3: SoftHSM. My initial thoughts are that anything where we support multiple versions (e.g. if we supported ruby18 and ruby19 and jruby) or if the version changes often then we should have jenkins install it. At the moment there are only single versions of group 1 listed in the documentation and I have no feel for how much this list changes. group 2 should use distribution defaults. SoftHSM is currently built from trunk on every run of the build/test tree. Do we need to support older versions? WDYT? John (PS, multiple ruby support should be easy to do with rvm) --- jad at sinodun.com Sinodun Internet Technologies Ltd. Stables 4, Suite 11, Howbery Park, Wallingford, Oxfordshire, OX10 8BA, U.K. +44 (0)1491 834957 From jerry at opendnssec.org Tue Oct 4 12:50:19 2011 From: jerry at opendnssec.org (=?ISO-8859-1?Q?Jerry_Lundstr=F6m?=) Date: Tue, 4 Oct 2011 14:50:19 +0200 Subject: [Opendnssec-develop] Supported build dependency for libraries etc In-Reply-To: <3DEC21FF-D942-49E7-8880-2BFC05963B6E@sinodun.com> References: <3DEC21FF-D942-49E7-8880-2BFC05963B6E@sinodun.com> Message-ID: On Tue, Oct 4, 2011 at 1:37 PM, John Dickinson wrote: > My initial thoughts are that anything where we support multiple versions > (e.g. if we supported ruby18 and ruby19 and jruby) or if the version changes > often then we should have jenkins install it. At the moment there are only > single versions of group 1 listed in the documentation and I have no feel > for how much this list changes. > The first group is the interesting one. We can support specific/minimum version or we can say we support ubuntu 10.04 and then we have to rely on the versions in that dist. A vote perhaps, +specific or +dist ? > group 2 should use distribution defaults. > Agreed, this would just be too much work. > SoftHSM is currently built from trunk on every run of the build/test tree. > Do we need to support older versions? > Right now SoftHSM is tied to the OpenDNSSEC project so I don't think we need to worry here but we want to set up tests for it also. /Jerry -------------- next part -------------- An HTML attachment was scrubbed... URL: From rickard at opendnssec.org Tue Oct 4 13:02:17 2011 From: rickard at opendnssec.org (Rickard Bellgrim) Date: Tue, 4 Oct 2011 15:02:17 +0200 Subject: [Opendnssec-develop] Supported build dependency for libraries etc In-Reply-To: References: <3DEC21FF-D942-49E7-8880-2BFC05963B6E@sinodun.com> Message-ID: > The first group is the interesting one. We can support specific/minimum > version or we can say we support ubuntu 10.04 and then we have to rely on > the versions in that dist. We usually require the latest dnsruby and ldns version. For the other packages, we should use functions that are available in the different package systems. >> SoftHSM is currently built from trunk on every run of the build/test tree. >> Do we need to support older versions? > > Right now SoftHSM is tied to the OpenDNSSEC project so I don't think we need > to worry here but we want to set up tests for it also. SoftHSM has never been branched like OpenDNSSEC. All maintenance is done in trunk. // Rickard From rickard at opendnssec.org Tue Oct 4 13:13:00 2011 From: rickard at opendnssec.org (Rickard Bellgrim) Date: Tue, 4 Oct 2011 15:13:00 +0200 Subject: [Opendnssec-develop] Meeting 20111005 Message-ID: Hi We have a meeting tomorrow. You can find the agenda here: http://trac.opendnssec.org/wiki/Meetings/Agenda/2011-10-05 Please add any topics you would like to bring up. // Rickard From sion at nominet.org.uk Wed Oct 5 07:40:14 2011 From: sion at nominet.org.uk (=?ISO-8859-1?Q?Si=F4n_Lloyd?=) Date: Wed, 5 Oct 2011 08:40:14 +0100 Subject: [Opendnssec-develop] Supported build dependency for libraries etc In-Reply-To: References: <3DEC21FF-D942-49E7-8880-2BFC05963B6E@sinodun.com> Message-ID: <4E8C09DE.3020907@nominet.org.uk> On 04/10/11 13:50, Jerry Lundstr?m wrote: > On Tue, Oct 4, 2011 at 1:37 PM, John Dickinson > wrote: > > My initial thoughts are that anything where we support multiple > versions (e.g. if we supported ruby18 and ruby19 and jruby) or if > the version changes often then we should have jenkins install it. > At the moment there are only single versions of group 1 listed in > the documentation and I have no feel for how much this list changes. > > > The first group is the interesting one. We can support > specific/minimum version or we can say we support ubuntu 10.04 and > then we have to rely on the versions in that dist. > > A vote perhaps, +specific or +dist ? > The one time I can recall this being an issue was with sqlite on redhat/centos, where the version reported is not always the actual version installed... It would be more friendly to support a distribution; unless we have compelling reasons to use newer or non-standard libraries. So maybe we would need the ability to turn features off (e.g. --no-gost) where they would not be available on the vanilla distribution? Of course this wouldn't help the test environment. Sion -------------- next part -------------- An HTML attachment was scrubbed... URL: From patrik.wallstrom at iis.se Wed Oct 5 13:22:48 2011 From: patrik.wallstrom at iis.se (=?iso-8859-1?Q?Patrik_Wallstr=F6m?=) Date: Wed, 5 Oct 2011 15:22:48 +0200 Subject: [Opendnssec-develop] minutes from telephone meeting 2011-10-05 Message-ID: http://trac.opendnssec.org/wiki/Meetings/Minutes/2001-10-05 -- Patrik Wallstr?m Project Manager, R&D .SE (Stiftelsen f?r Internetinfrastruktur) E-mail: patrik.wallstrom at iis.se Web: http://www.iis.se/ From patrik.wallstrom at iis.se Wed Oct 5 13:26:05 2011 From: patrik.wallstrom at iis.se (=?iso-8859-1?Q?Patrik_Wallstr=F6m?=) Date: Wed, 5 Oct 2011 15:26:05 +0200 Subject: [Opendnssec-develop] Re: minutes from telephone meeting 2011-10-05 In-Reply-To: References: Message-ID: <12B61638-8E43-4D1F-BE69-C9B2833BA826@iis.se> On Oct 5, 2011, at 3:22 PM, Patrik Wallstr?m wrote: > http://trac.opendnssec.org/wiki/Meetings/Minutes/2001-10-05 Sorry, correct link (and date) is: http://trac.opendnssec.org/wiki/Meetings/Minutes/2011-10-05 -- Patrik Wallstr?m Project Manager, R&D .SE (Stiftelsen f?r Internetinfrastruktur) E-mail: patrik.wallstrom at iis.se Web: http://www.iis.se/ From jerry at opendnssec.org Wed Oct 5 14:03:35 2011 From: jerry at opendnssec.org (Jerry =?ISO-8859-1?B?THVuZHN0cvZt?=) Date: Wed, 05 Oct 2011 16:03:35 +0200 Subject: [Opendnssec-develop] Moving from Pivotal to Green Hopper (JIRA) Message-ID: Hi, As we talked about at the minutes meeting, can we move from Pivotal to Green Hopper? (+1/-1) Reason for this is to have all the issues in the same planning tool, to be able to tie commits to issues and lots more. /Jerry -------------- next part -------------- An HTML attachment was scrubbed... URL: From jerry at opendnssec.org Wed Oct 5 14:06:40 2011 From: jerry at opendnssec.org (Jerry =?ISO-8859-1?B?THVuZHN0cvZt?=) Date: Wed, 05 Oct 2011 16:06:40 +0200 Subject: [Opendnssec-develop] Current status for JIRA Message-ID: Hi, Our JIRA installations is not really ready yet to be used so please don't make issues/stories unless you have to. It will be ready once we decide about Pivotal vs Green Hopper and have imported all existing stories. /Jerry -------------- next part -------------- An HTML attachment was scrubbed... URL: From rickard at opendnssec.org Wed Oct 5 14:50:00 2011 From: rickard at opendnssec.org (Rickard Bellgrim) Date: Wed, 5 Oct 2011 16:50:00 +0200 Subject: [Opendnssec-develop] Moving from Pivotal to Green Hopper (JIRA) In-Reply-To: References: Message-ID: > As we talked about at the minutes meeting, can we move from Pivotal to Green > Hopper? (+1/-1) +1 // Rickard From paul at xelerance.com Wed Oct 5 22:08:49 2011 From: paul at xelerance.com (Paul Wouters) Date: Wed, 5 Oct 2011 18:08:49 -0400 (EDT) Subject: [Opendnssec-develop] packaging questions about softhsm In-Reply-To: <4923C2E4-27BB-423E-A968-308FCCA82E9E@kirei.se> References: <6F0BC411-BCE8-4FA2-8C86-3BC7D34311F8@iis.se> <5501223D-6A2A-4CAD-8AFA-6C41D3EC96F8@iis.se> <4923C2E4-27BB-423E-A968-308FCCA82E9E@kirei.se> Message-ID: On Thu, 10 Mar 2011, Jakob Schlyter wrote: > Subject: Re: [Opendnssec-develop] packaging questions about softhsm > > On 7 mar 2011, at 09.57, Rickard Bellgrim wrote: > >>> If it is a module and not a shared library, then it should not be installed in /usr/lib* ? >>> Perhaps a better place would be /usr/lib/softhsm/ ? >> >> Yes, perhaps. What do you think Jakob? > > Yes, much better. Unfortunately, version 1.3.0 did not fix this issue yet. For the softhsm package under review for fedora/rhel/centos, I've changed the location passed by configure to be /usr/lib{64}/softhsm/ to prevent the system from treating it has a shared library. See: https://bugzilla.redhat.com/show_bug.cgi?id=711895 Paul From sion at nominet.org.uk Thu Oct 6 08:26:29 2011 From: sion at nominet.org.uk (=?ISO-8859-1?Q?Si=F4n_Lloyd?=) Date: Thu, 6 Oct 2011 09:26:29 +0100 Subject: [Opendnssec-develop] Moving from Pivotal to Green Hopper (JIRA) In-Reply-To: References: Message-ID: <4E8D6635.8040207@nominet.org.uk> On 05/10/11 15:50, Rickard Bellgrim wrote: >> As we talked about at the minutes meeting, can we move from Pivotal to Green >> Hopper? (+1/-1) > +1 > I can't see the video, so am slightly in the dark. However I'm sure that it is up to the job and it has an impressive list of users... so... +1 From jakob at kirei.se Thu Oct 6 09:23:24 2011 From: jakob at kirei.se (Jakob Schlyter) Date: Thu, 6 Oct 2011 11:23:24 +0200 Subject: [Opendnssec-develop] Moving from Pivotal to Green Hopper (JIRA) In-Reply-To: References: Message-ID: On 5 okt 2011, at 16:03, Jerry Lundstr?m wrote: > As we talked about at the minutes meeting, can we move from Pivotal to Green Hopper? (+1/-1) Sure. jakob From matthijs at NLnetLabs.nl Thu Oct 6 09:30:34 2011 From: matthijs at NLnetLabs.nl (Matthijs Mekking) Date: Thu, 06 Oct 2011 11:30:34 +0200 Subject: [Opendnssec-develop] Moving from Pivotal to Green Hopper (JIRA) In-Reply-To: References: Message-ID: <4E8D753A.2090607@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Looks good: +1 On 10/05/2011 04:03 PM, Jerry Lundstr?m wrote: > Hi, > > As we talked about at the minutes meeting, can we move from Pivotal to > Green Hopper? (+1/-1) > > Reason for this is to have all the issues in the same planning tool, to > be able to tie commits to issues and lots more. > > /Jerry > > > > _______________________________________________ > 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.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJOjXU5AAoJEA8yVCPsQCW5NgcH/jxL3NhBobDYHcO+0RknLItS w/zZRn0U1bJysXt9V5x1MyXqTXNADwv4yhkuzy/0LJ7Q1OIqzvxRA1XIf5xIzHrg WCr8isrrbZW9c7hBLkAOdtTkQ27BJ6rPPD0N8SfeA+OP4m9a208xMrQmwZuXB0h6 7P5gZGD0a0Hs5E3IrritxWW3kA/BXrRyCVWBuFzpieaX/50LsHE7HrFYATVn2ttK sBD4ApR8WLAEbFoGJY8d5OwHdcZSHQBarTZCvb2EzKze2LcHlAkvOXSzI/Trb4z+ wEMqGukChILTalpngG4Y5LSo7v+nDD0Ya+dDU3rhRoWH5RCDtcK2w7WtOKzsffA= =VPus -----END PGP SIGNATURE----- From sara at sinodun.com Thu Oct 6 12:03:24 2011 From: sara at sinodun.com (Sara Dickinson) Date: Thu, 6 Oct 2011 13:03:24 +0100 Subject: [Opendnssec-develop] RE: Documentation Message-ID: Hi All, As a follow up to the call yesterday here is a link to the Confluence OpenDNSSEC v1.3.0 page: https://wiki.opendnssec.org/display/ODSDOC130/OpenDNSSEC+Documentation+v1.3.0 This will eventually replace the TRAC site. I am still in the process of fixing up the content so this is a work in progress.... There will shortly be a new page for the 'current' documentation. The aim is to have one current space for documentation and to archive release snapshots in a similar manner to how Confluence manage their own documentation: - http://confluence.atlassian.com/display/DOC - http://confluence.atlassian.com/display/CONF35 - http://confluence.atlassian.com/display/CONF34 In the meantime please share any thoughts you have about the documentation content, structure and process. Also, if you have any updates to make to the documentation in the near future then please let me know and I can incorporate them into the new pages. Sara. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jakob at kirei.se Thu Oct 6 12:08:32 2011 From: jakob at kirei.se (Jakob Schlyter) Date: Thu, 6 Oct 2011 14:08:32 +0200 Subject: [Opendnssec-develop] RE: Documentation In-Reply-To: References: Message-ID: <5CA0A0CD-C199-4E3A-A238-955BC1DF93CA@kirei.se> Nice work Sara! My only comment so far is that we'll do one documentation space per minor release, e.g. 1.3, 1.4, 1.5 - not per patch level. jakob From nick.vandenheuvel at sidn.nl Fri Oct 7 07:31:42 2011 From: nick.vandenheuvel at sidn.nl (Nick van den Heuvel) Date: Fri, 7 Oct 2011 07:31:42 +0000 Subject: [Opendnssec-develop] Moving from Pivotal to Green Hopper (JIRA) In-Reply-To: References: Message-ID: <8379DE00FDBE1B4F95522D088EC260DD035CFF@kambx2.SIDN.local> I just took a look at Greenhopper on youtube and it looks pretty good! So you have my blessing :) -----Original Message----- From: opendnssec-develop-bounces at lists.opendnssec.org [mailto:opendnssec-develop-bounces at lists.opendnssec.org] On Behalf Of Jakob Schlyter Sent: donderdag 6 oktober 2011 11:23 To: Jerry Lundstr?m Cc: opendnssec-develop at lists.opendnssec.org Subject: Re: [Opendnssec-develop] Moving from Pivotal to Green Hopper (JIRA) On 5 okt 2011, at 16:03, Jerry Lundstr?m wrote: > As we talked about at the minutes meeting, can we move from Pivotal to Green Hopper? (+1/-1) Sure. jakob _______________________________________________ Opendnssec-develop mailing list Opendnssec-develop at lists.opendnssec.org https://lists.opendnssec.org/mailman/listinfo/opendnssec-develop From rickard at opendnssec.org Mon Oct 10 07:08:36 2011 From: rickard at opendnssec.org (Rickard Bellgrim) Date: Mon, 10 Oct 2011 09:08:36 +0200 Subject: [Opendnssec-develop] packaging questions about softhsm In-Reply-To: References: <6F0BC411-BCE8-4FA2-8C86-3BC7D34311F8@iis.se> <5501223D-6A2A-4CAD-8AFA-6C41D3EC96F8@iis.se> <4923C2E4-27BB-423E-A968-308FCCA82E9E@kirei.se> Message-ID: > Unfortunately, version 1.3.0 did not fix this issue yet. > > For the softhsm package under review for fedora/rhel/centos, I've changed > the location passed by configure to be /usr/lib{64}/softhsm/ to prevent > the system from treating it has a shared library. > > See: https://bugzilla.redhat.com/show_bug.cgi?id=711895 I will create a ticket for this and make sure that it is included in the next release. // Rickard From yuri at NLnetLabs.nl Mon Oct 10 08:56:37 2011 From: yuri at NLnetLabs.nl (Yuri Schaeffer) Date: Mon, 10 Oct 2011 10:56:37 +0200 Subject: [Opendnssec-develop] Automatic introduction of manual keys. Message-ID: <4E92B345.7010008@nlnetlabs.nl> Nick noticed a difference between the two enforcer implementations which I like to get your opinion about. Importing an unsigned zone, split key, with on the KSK: Enforcer: Generate both keys and introduce them in the zone. This is not considered a rollover. Enforcer NG: Introduce only the ZSK. Wait for user signal to introduce the KSK. This is a rollover like any other. Personally I like the new behavior, as it feels more consistent. The user asks not to do any automatic stuff with the KSK, so we don't. It is possible to implement the old behavior by either: A) ignore manual flag if there is no KSK* B) ignore manual flag if there is no KSK* for this algorithm. * same for other type of keys C) or maybe: As long as the zone is not properly signed ignore ManualRollover flag. I think the solutions A,B,C all have some unexpected behavior for the user in some situations. So I suggest to leave it as is. -- Yuri Schaeffer NLnet Labs http://www.nlnetlabs.nl From matthijs at NLnetLabs.nl Mon Oct 10 09:07:30 2011 From: matthijs at NLnetLabs.nl (Matthijs Mekking) Date: Mon, 10 Oct 2011 11:07:30 +0200 Subject: [Opendnssec-develop] Automatic introduction of manual keys. In-Reply-To: <4E92B345.7010008@nlnetlabs.nl> References: <4E92B345.7010008@nlnetlabs.nl> Message-ID: <4E92B5D2.2090004@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 10/10/2011 10:56 AM, Yuri Schaeffer wrote: > Nick noticed a difference between the two enforcer implementations which > I like to get your opinion about. > > Importing an unsigned zone, split key, with on the KSK: > > Enforcer: > Generate both keys and introduce them in the zone. This is not > considered a rollover. > > Enforcer NG: > Introduce only the ZSK. Wait for user signal to introduce the KSK. This > is a rollover like any other. > > > Personally I like the new behavior, as it feels more consistent. The > user asks not to do any automatic stuff with the KSK, so we don't. The user asks us not to do any automatic KSK rollover. You can argue if introducing the KSK is a rollover. I prefer to have the KSK introduced automatically, just like the current enforcer does. > It is possible to implement the old behavior by either: > A) ignore manual flag if there is no KSK* > B) ignore manual flag if there is no KSK* for this algorithm. > * same for other type of keys > > C) or maybe: As long as the zone is not properly signed ignore > ManualRollover flag. Option A) is how the current enforcer would work. Option B) is the same, except it takes into account algorithm rollover (which is actually a change of the KASP). What do you mean with properly? Properly in the sense of DNSSEC of properly according to the KASP? > > I think the solutions A,B,C all have some unexpected behavior for the > user in some situations. So I suggest to leave it as is. I would like to see on of the solutions implemented. Best regards, Matthijs -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJOkrXSAAoJEA8yVCPsQCW5Nt8IAKy+R0znV4gKjX4oDv/y0L0b pz9COsLz+N6tcDaLilnsvabDRFnHuuQS7FKQUiL67O3WnKuHdd6XHcXQoc87E91N wCmNNlyDpq9WfmmdKVuZaAvsZo2QhrAwM0H5oup+tTxnlGghmsMgff3fblF51jVl 2S6cvs3HzC2RA7MLJndbNzfce9Lf1lY5ip4186Az0qpuexjOpkJen6Q2eS6vvu/6 /HpBVTJJoEd0bYzVRGvcdqZf9S+GzWVzLzkicp+O7+YHR0r7eEDMhvpLq6Ry+o7j sY7g8uVMxpzn7byTwu60nAoECUuBxLHfJ7ArpjNSZbc5LdVRSKza6eStYVe9Jas= =Yt1P -----END PGP SIGNATURE----- From yuri at NLnetLabs.nl Mon Oct 10 09:09:59 2011 From: yuri at NLnetLabs.nl (Yuri Schaeffer) Date: Mon, 10 Oct 2011 11:09:59 +0200 Subject: [Opendnssec-develop] EnfNG 2nd Alpha Message-ID: <4E92B667.7050009@nlnetlabs.nl> We decided we'd have another alpha release as soon as we could configure the rollover strategies. It was easier to implement than anticipated. I've tested it last week and it seems to work just fine. Should we give it another go? -- Yuri Schaeffer NLnet Labs http://www.nlnetlabs.nl From matthijs at NLnetLabs.nl Mon Oct 10 09:47:09 2011 From: matthijs at NLnetLabs.nl (Matthijs Mekking) Date: Mon, 10 Oct 2011 11:47:09 +0200 Subject: [Opendnssec-develop] Automatic introduction of manual keys. In-Reply-To: <4E92B8EC.7080603@nlnetlabs.nl> References: <4E92B345.7010008@nlnetlabs.nl> <4E92B5D2.2090004@nlnetlabs.nl> <4E92B8EC.7080603@nlnetlabs.nl> Message-ID: <4E92BF1D.70102@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 10/10/2011 11:20 AM, Yuri Schaeffer wrote: >>> C) or maybe: As long as the zone is not properly signed ignore >>> ManualRollover flag. > >> What do you mean with properly? Properly in the sense of DNSSEC of >> properly according to the KASP? > > In the sense of DNSSEC. > > My thoughts about this strategy: User indicated manual RollOver but our > first and foremost priority is make sure the zone is secure. > > However when the user forgets to submit the DS to the parent (or forgets > to tell the enfocer he did so), the enforcer might roll the KSK when > configured lifetime is due. This might not be a problem because it is an > internal affair for the Enforcer but is unexpected from a user point of > view. > Then I would prefer option A/B. Best regards, Matthijs -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJOkr8dAAoJEA8yVCPsQCW5bx0H/1R2lr7qmBSsAxEvstgs9R5o BrlNuaqbUTaxi8kd9LBfE2vBxkNv0ZkmhpED5WcJOsLp5IFYZVqo9HfjRTd0PNWO 4PzQCvGsyGQMELr/wE53H7DktMPibmH+sVk9dTyvudr6m/SNQwvW+8ayVSX6wBzY dzvWpmM8yjDEto9MKP0zKb9UMBHz2bD7+n9Rc8YuDCGphExdng9EUL95eXyo+Q8q WUJZfsS9c0N9ej0rPrdSNgXMZa3ATBpxpoN+SXqefUBJNvMwYwxI6fQWyfuNEf0d zwKE5mXe6p6mTTp2loyABuPWccOYF61YA5JJGVOZOgpJg3L71YxbkOR2Z1FagIw= =Q7JD -----END PGP SIGNATURE----- From sion at nominet.org.uk Mon Oct 10 10:49:17 2011 From: sion at nominet.org.uk (=?ISO-8859-1?Q?Si=F4n_Lloyd?=) Date: Mon, 10 Oct 2011 11:49:17 +0100 Subject: [Opendnssec-develop] Automatic introduction of manual keys. In-Reply-To: <4E92BF1D.70102@nlnetlabs.nl> References: <4E92B345.7010008@nlnetlabs.nl> <4E92B5D2.2090004@nlnetlabs.nl> <4E92B8EC.7080603@nlnetlabs.nl> <4E92BF1D.70102@nlnetlabs.nl> Message-ID: <4E92CDAD.5080000@nominet.org.uk> On 10/10/11 10:47, Matthijs Mekking wrote: > Then I would prefer option A/B. > I agree. Although you could argue that this is a rollover; I think that by asking for the zone to be signed the user has agreed to the KSK being introduced. Sion From jakob at kirei.se Mon Oct 10 12:00:48 2011 From: jakob at kirei.se (Jakob Schlyter) Date: Mon, 10 Oct 2011 14:00:48 +0200 Subject: [Opendnssec-develop] EnfNG 2nd Alpha In-Reply-To: <4E92B667.7050009@nlnetlabs.nl> References: <4E92B667.7050009@nlnetlabs.nl> Message-ID: On 10 okt 2011, at 11:09, Yuri Schaeffer wrote: > Should we give it another go? Release early, release often! Just say the magic word. j From yuri at NLnetLabs.nl Mon Oct 10 12:36:18 2011 From: yuri at NLnetLabs.nl (Yuri Schaeffer) Date: Mon, 10 Oct 2011 14:36:18 +0200 Subject: [Opendnssec-develop] EnfNG 2nd Alpha In-Reply-To: References: <4E92B667.7050009@nlnetlabs.nl> Message-ID: <4E92E6C2.3040403@nlnetlabs.nl> > Release early, release often! Just say the magic word. Magic word? hmm... Go-Go-Gadget-Release? Changes since first alpha release: - Support for RollOverType in kasp.xml - Fixed concurrency related crashes. - Automatically retract never submitted DS records. - Schedule the purging of keys. Alpha 2 introduces the KskRollType, ZskRollType, and CskRollType elements in kasp.xml for use in the KSK, ZSK and CSK sections. Valid values are: [ KskDoubleRRset | KskDoubleDS | KskDoubleSignature | ZskDoubleSignature | ZskPrePublication | ZskDoubleRRsig | CskDoubleRRset | CskSingleSignature | CskDoubleDS | CskDoubleSignature | CskPrePublication ] These values correspond directly with the rollover types described in the Internet Draft: draft-mekking-dnsop-dnssec-key-timing-bis-02 The various Rollover Types influence the traffic to your zone and the speed of a rollover. The enforcer uses them as a strong hint, in case of a conflict (for example ZskPrePublication is impossible during a algorithm rollover) these hints are relaxed. -- Yuri Schaeffer NLnet Labs http://www.nlnetlabs.nl From jad at sinodun.com Tue Oct 11 11:31:43 2011 From: jad at sinodun.com (John Dickinson) Date: Tue, 11 Oct 2011 12:31:43 +0100 Subject: [Opendnssec-develop] Automatic introduction of manual keys. In-Reply-To: <4E92CDAD.5080000@nominet.org.uk> References: <4E92B345.7010008@nlnetlabs.nl> <4E92B5D2.2090004@nlnetlabs.nl> <4E92B8EC.7080603@nlnetlabs.nl> <4E92BF1D.70102@nlnetlabs.nl> <4E92CDAD.5080000@nominet.org.uk> Message-ID: <9BA1E6A9-00FB-42EA-AA9D-54B01A44D8B1@sinodun.com> On 10 Oct 2011, at 11:49, Si?n Lloyd wrote: > On 10/10/11 10:47, Matthijs Mekking wrote: >> Then I would prefer option A/B. >> > > I agree. > > Although you could argue that this is a rollover; I think that by asking for the zone to be signed the user has agreed to the KSK being introduced. +1 --- jad at sinodun.com Sinodun Internet Technologies Ltd. Stables 4, Suite 11, Howbery Park, Wallingford, Oxfordshire, OX10 8BA, U.K. +44 (0)1491 834957 From nick.vandenheuvel at sidn.nl Tue Oct 11 11:40:12 2011 From: nick.vandenheuvel at sidn.nl (Nick van den Heuvel) Date: Tue, 11 Oct 2011 11:40:12 +0000 Subject: [Opendnssec-develop] Automatic introduction of manual keys. In-Reply-To: <4E92BF1D.70102@nlnetlabs.nl> References: <4E92B345.7010008@nlnetlabs.nl> <4E92B5D2.2090004@nlnetlabs.nl> <4E92B8EC.7080603@nlnetlabs.nl> <4E92BF1D.70102@nlnetlabs.nl> Message-ID: <8379DE00FDBE1B4F95522D088EC260DD128BF1@kambx2.SIDN.local> >Then I would prefer option A/B. +1 Met vriendelijke groet, Nick van den Heuvel Test analist SIDN | Utrechtseweg 310 | 6802 EA | Postbus 5022 | 6802 EA | ARNHEM T +31 (0)26 352 55 93 | F +31 (0)26 352 55 05 | jabber: nick.vandenheuvel at jabber.sidn.nl nick.vandenheuvel at sidn.nl | www.sidn.nl SIDN heeft een nieuw domein! Vanaf 31 oktober zijn wij gevestigd op een nieuw adres: Meander 501, 6825 MD Arnhem. Het postadres en de telefoonnummers blijven ongewijzigd. SIDN has a new domain! From 31 October, our office address will be: Meander 501, 6825 MD Arnhem, The Netherlands. Our postal address and phone numbers remain unchanged. From rickard at opendnssec.org Tue Oct 11 11:58:03 2011 From: rickard at opendnssec.org (Rickard Bellgrim) Date: Tue, 11 Oct 2011 13:58:03 +0200 Subject: [Opendnssec-develop] EnfNG 2nd Alpha In-Reply-To: <4E92E6C2.3040403@nlnetlabs.nl> References: <4E92B667.7050009@nlnetlabs.nl> <4E92E6C2.3040403@nlnetlabs.nl> Message-ID: Please add these changes to the NEWS file, if it has not been done yet. Then it is just for Jakob to make the release. I am a little bit occupied the coming days, maybe someone else can update the WordPress and send an announce to the list? // Rickard On Mon, Oct 10, 2011 at 2:36 PM, Yuri Schaeffer wrote: >> Release early, release often! Just say the magic word. > > Magic word? hmm... > Go-Go-Gadget-Release? > > > Changes since first alpha release: > > - Support for RollOverType in kasp.xml > - Fixed concurrency related crashes. > - Automatically retract never submitted DS records. > - Schedule the purging of keys. > > Alpha 2 introduces the KskRollType, ZskRollType, and CskRollType > elements in kasp.xml for use in the KSK, ZSK and CSK sections. > Valid values are: > > [ KskDoubleRRset | KskDoubleDS | KskDoubleSignature | > ZskDoubleSignature | ZskPrePublication | ZskDoubleRRsig | > CskDoubleRRset | CskSingleSignature | CskDoubleDS | > CskDoubleSignature | CskPrePublication ] > > These values correspond directly with the rollover types described > in the Internet Draft: draft-mekking-dnsop-dnssec-key-timing-bis-02 > The various Rollover Types influence the traffic to your zone and the > speed of a rollover. The enforcer uses them as a strong hint, in > case of a conflict (for example ZskPrePublication is impossible > during a algorithm rollover) these hints are relaxed. > > > -- > Yuri Schaeffer > NLnet Labs > http://www.nlnetlabs.nl > _______________________________________________ > Opendnssec-develop mailing list > Opendnssec-develop at lists.opendnssec.org > https://lists.opendnssec.org/mailman/listinfo/opendnssec-develop > From jad at sinodun.com Tue Oct 11 12:28:03 2011 From: jad at sinodun.com (John Dickinson) Date: Tue, 11 Oct 2011 13:28:03 +0100 Subject: [Opendnssec-develop] Re: [Opendnssec-otr] softhsm In-Reply-To: <1CF2995B-3372-40E5-935E-421628C7392C@sinodun.com> References: <1CF2995B-3372-40E5-935E-421628C7392C@sinodun.com> Message-ID: <19F76555-F788-4BFC-A66C-EDB14007A35D@sinodun.com> Moved to the correct list? This occurs (I think) because sqllite drags a -L/usr/local/lib along with it (regardless of where the sqlite lib actually is) and In the src Makefile.am libsofthsm_la_LIBADD= @BOTAN_LIBS@ @SQLITE3_LIBS@ where as in the softhsm Makefile.am you have softhsm_LDADD = @SQLITE3_LIBS@ @BOTAN_LIBS@ I think at the very least we should make the order the same, or improve the m4 file for sqlite. I would like a second opinion before making any change. John On 11 Oct 2011, at 12:27, John Dickinson wrote: > Hi, > > On redhat the softhsm binary seems to link to a different version of the botan library than libsofhsm. > > > [jenkins at redhat1 bin]$ ldd /opt/jenkins/workspace/root/trunk/bin/softhsm > linux-vdso.so.1 => (0x00007fff40bc0000) > libsqlite3.so.0 => /usr/lib64/libsqlite3.so.0 (0x0000003b5be00000) > libbotan-1.8.2.so => not found > librt.so.1 => /lib64/librt.so.1 (0x0000003b5c200000) > libdl.so.2 => /lib64/libdl.so.2 (0x0000003b5ae00000) > libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x0000003b5f200000) > libm.so.6 => /lib64/libm.so.6 (0x0000003b5ba00000) > libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x0000003b5ce00000) > libc.so.6 => /lib64/libc.so.6 (0x0000003b5b200000) > libpthread.so.0 => /lib64/libpthread.so.0 (0x0000003b5b600000) > /lib64/ld-linux-x86-64.so.2 (0x0000003b5aa00000) > [jenkins at redhat1 bin]$ ldd /opt/jenkins/workspace/root/trunk/lib/libsofthsm.so > linux-vdso.so.1 => (0x00007fff2b310000) > libbotan-1.8.13.so => not found > libsqlite3.so.0 => /usr/lib64/libsqlite3.so.0 (0x00007f28469a3000) > librt.so.1 => /lib64/librt.so.1 (0x00007f284679b000) > libdl.so.2 => /lib64/libdl.so.2 (0x00007f2846597000) > libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x00007f2846290000) > libm.so.6 => /lib64/libm.so.6 (0x00007f284600c000) > libc.so.6 => /lib64/libc.so.6 (0x00007f2845c7d000) > libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f2845a66000) > libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f284584a000) > /lib64/ld-linux-x86-64.so.2 (0x0000003b5aa00000) > > > The softhsm build can be found here > > https://jenkins.opendnssec.org/job/Build_SoftHSM_trunk/label=redhat1/36/console > > Any ideas? (I know removing one of the two botans would be good but I do not have root access to this server. > John > --- > jad at sinodun.com > Sinodun Internet Technologies Ltd. > Stables 4, Suite 11, > Howbery Park, > Wallingford, > Oxfordshire, > OX10 8BA, > U.K. > > +44 (0)1491 834957 > > _______________________________________________ > Opendnssec-otr mailing list > Opendnssec-otr at lists.opendnssec.org > https://lists.opendnssec.org/mailman/listinfo/opendnssec-otr --- jad at sinodun.com Sinodun Internet Technologies Ltd. Stables 4, Suite 11, Howbery Park, Wallingford, Oxfordshire, OX10 8BA, U.K. +44 (0)1491 834957 From yuri at NLnetLabs.nl Tue Oct 11 12:54:41 2011 From: yuri at NLnetLabs.nl (Yuri Schaeffer) Date: Tue, 11 Oct 2011 14:54:41 +0200 Subject: [Opendnssec-develop] EnfNG 2nd Alpha In-Reply-To: References: <4E92B667.7050009@nlnetlabs.nl> <4E92E6C2.3040403@nlnetlabs.nl> Message-ID: <4E943C91.8000209@nlnetlabs.nl> On 10/11/11 13:58, Rickard Bellgrim wrote: > Please add these changes to the NEWS file, if it has not been done yet. Done. I did not include the follow text. I thought it might be useful to accompany the release announcement. >> Alpha 2 introduces the KskRollType, ZskRollType, and CskRollType >> elements in kasp.xml for use in the KSK, ZSK and CSK sections. >> Valid values are: >> >> [ KskDoubleRRset | KskDoubleDS | KskDoubleSignature | >> ZskDoubleSignature | ZskPrePublication | ZskDoubleRRsig | >> CskDoubleRRset | CskSingleSignature | CskDoubleDS | >> CskDoubleSignature | CskPrePublication ] >> >> These values correspond directly with the rollover types described >> in the Internet Draft: draft-mekking-dnsop-dnssec-key-timing-bis-02 >> The various Rollover Types influence the traffic to your zone and the >> speed of a rollover. The enforcer uses them as a strong hint, in >> case of a conflict (for example ZskPrePublication is impossible >> during a algorithm rollover) these hints are relaxed. -- Yuri Schaeffer NLnet Labs http://www.nlnetlabs.nl From yuri at NLnetLabs.nl Tue Oct 11 13:49:06 2011 From: yuri at NLnetLabs.nl (Yuri Schaeffer) Date: Tue, 11 Oct 2011 15:49:06 +0200 Subject: [Opendnssec-develop] Automatic introduction of manual keys. In-Reply-To: <4E92CDAD.5080000@nominet.org.uk> References: <4E92B345.7010008@nlnetlabs.nl> <4E92B5D2.2090004@nlnetlabs.nl> <4E92B8EC.7080603@nlnetlabs.nl> <4E92BF1D.70102@nlnetlabs.nl> <4E92CDAD.5080000@nominet.org.uk> Message-ID: <4E944952.8010405@nlnetlabs.nl> >> Then I would prefer option A/B. > Although you could argue that this is a rollover; I think that by asking > for the zone to be signed the user has agreed to the KSK being introduced. I did implement option B. If the enforcer finds a key entry in the kasp for algorithm X and X is not yet used in the zone, it will introduce that key. Regardless of the Manual flag. If the user changes the algorithm (from unsigned to X or Y to X) the enforcer assumes signing with X must be done *now*. Also, this will work as expected when signing with multiple keys simultaneously. -- Yuri Schaeffer NLnet Labs http://www.nlnetlabs.nl From rickard at opendnssec.org Tue Oct 18 13:18:26 2011 From: rickard at opendnssec.org (Rickard Bellgrim) Date: Tue, 18 Oct 2011 15:18:26 +0200 Subject: [Opendnssec-develop] Supported build dependency for libraries etc In-Reply-To: References: <3DEC21FF-D942-49E7-8880-2BFC05963B6E@sinodun.com> Message-ID: To summarize this... We depend on packages that should be available in all distributions: sqlite, libxml2, (mysql) We have the build / configure specific packages like autoconf, automake, gcc, etc. Those should also be available in all distributions. The packages that are special for OpenDNSSEC are ldns and dnsruby. Botan for SoftHSM. I think it would be reasonable to just have the latest version installed in the test system, unless there are a major API change. You could have the argument that having old version helps us to detect if the developer has started to use new functions. But our main goal is to run the test scripts and our secondary goal is to see if the system builds. We do also say that we support current version of OpenDNSSEC and the two previous minor releases. So currently we have to run the test system for 1.1, 1.2, 1.3, and trunk. Have we agreed on how to treat the build scripts for these four different versions? // Rickard From rickard at opendnssec.org Tue Oct 18 13:26:29 2011 From: rickard at opendnssec.org (Rickard Bellgrim) Date: Tue, 18 Oct 2011 15:26:29 +0200 Subject: [Opendnssec-develop] Meeting 20111019 Message-ID: Hi We have a meeting tomorrow. Agenda: http://trac.opendnssec.org/wiki/Meetings/Agenda/2011-10-19 Please add any topics you would like to discuss. // Rickard From jad at sinodun.com Tue Oct 18 13:33:54 2011 From: jad at sinodun.com (John Dickinson) Date: Tue, 18 Oct 2011 14:33:54 +0100 Subject: [Opendnssec-develop] Supported build dependency for libraries etc In-Reply-To: References: <3DEC21FF-D942-49E7-8880-2BFC05963B6E@sinodun.com> Message-ID: <39CE0374-BD85-4C66-B83B-5F02B18C96E3@sinodun.com> On 18 Oct 2011, at 14:18, Rickard Bellgrim wrote: > To summarize this... > > We depend on packages that should be available in all distributions: > sqlite, libxml2, (mysql) > > We have the build / configure specific packages like autoconf, > automake, gcc, etc. Those should also be available in all > distributions. > > The packages that are special for OpenDNSSEC are ldns and dnsruby. > Botan for SoftHSM. I think it would be reasonable to just have the > latest version installed in the test system, unless there are a major > API change. You could have the argument that having old version helps > us to detect if the developer has started to use new functions. But > our main goal is to run the test scripts and our secondary goal is to > see if the system builds. A couple of comments 1. The SoftHSM configure.ac file contains specific checks for botan >= 1.10 and 1.8 suggesting to me that we need multiple Botans in each test 2. LDNS configure has --disable-gost. By default this would require OpenSSL >= 1.0.0. We should be able to test this. Again this would potentially add two LDNS versions (with and without gost) as well as the system and non-system OpenSSL (I think most system are still shipping with OpenSSL < 1.0.0. > > We do also say that we support current version of OpenDNSSEC and the > two previous minor releases. So currently we have to run the test > system for 1.1, 1.2, 1.3, and trunk. Have we agreed on how to treat > the build scripts for these four different versions? > > // Rickard --- jad at sinodun.com Sinodun Internet Technologies Ltd. Stables 4, Suite 11, Howbery Park, Wallingford, Oxfordshire, OX10 8BA, U.K. +44 (0)1491 834957 From nick.vandenheuvel at sidn.nl Tue Oct 18 13:53:50 2011 From: nick.vandenheuvel at sidn.nl (Nick van den Heuvel) Date: Tue, 18 Oct 2011 13:53:50 +0000 Subject: [Opendnssec-develop] Supported build dependency for libraries etc In-Reply-To: References: <3DEC21FF-D942-49E7-8880-2BFC05963B6E@sinodun.com> Message-ID: <8379DE00FDBE1B4F95522D088EC260DD12B108@kambx2.SIDN.local> --------------------------------------- The packages that are special for OpenDNSSEC are ldns and dnsruby. Botan for SoftHSM. I think it would be reasonable to just have the latest version installed in the test system, unless there are a major API change. You could have the argument that having old version helps us to detect if the developer has started to use new functions. But our main goal is to run the test scripts and our secondary goal is to see if the system builds. ---------------------------------------- Why not publish a list with the versions of supporting software which we used to test the release (attached to the release notes)? I do have some of these version included in my test report. --------------------------------------- We do also say that we support current version of OpenDNSSEC and the two previous minor releases. So currently we have to run the test system for 1.1, 1.2, 1.3, and trunk. Have we agreed on how to treat the build scripts for these four different versions? --------------------------------------- Not yet. Also depends on the patch released. Met vriendelijke groet, Nick van den Heuvel Test analist SIDN | Utrechtseweg 310 | 6802 EA | Postbus 5022 | 6802 EA | ARNHEM T +31 (0)26 352 55 93 | F +31 (0)26 352 55 05 | jabber: nick.vandenheuvel at jabber.sidn.nl nick.vandenheuvel at sidn.nl | www.sidn.nl SIDN heeft een nieuw domein! Vanaf 31 oktober zijn wij gevestigd op een nieuw adres: Meander 501, 6825 MD Arnhem. Het postadres en de telefoonnummers blijven ongewijzigd. SIDN has a new domain! From 31 October, our office address will be: Meander 501, 6825 MD Arnhem, The Netherlands. Our postal address and phone numbers remain unchanged. -----Original Message----- From: opendnssec-develop-bounces at lists.opendnssec.org [mailto:opendnssec-develop-bounces at lists.opendnssec.org] On Behalf Of Rickard Bellgrim Sent: dinsdag 18 oktober 2011 15:18 To: Jerry Lundstr?m Cc: opendnssec-develop at lists.opendnssec.org Subject: Re: [Opendnssec-develop] Supported build dependency for libraries etc To summarize this... We depend on packages that should be available in all distributions: sqlite, libxml2, (mysql) We have the build / configure specific packages like autoconf, automake, gcc, etc. Those should also be available in all distributions. The packages that are special for OpenDNSSEC are ldns and dnsruby. Botan for SoftHSM. I think it would be reasonable to just have the latest version installed in the test system, unless there are a major API change. You could have the argument that having old version helps us to detect if the developer has started to use new functions. But our main goal is to run the test scripts and our secondary goal is to see if the system builds. We do also say that we support current version of OpenDNSSEC and the two previous minor releases. So currently we have to run the test system for 1.1, 1.2, 1.3, and trunk. Have we agreed on how to treat the build scripts for these four different versions? // Rickard _______________________________________________ Opendnssec-develop mailing list Opendnssec-develop at lists.opendnssec.org https://lists.opendnssec.org/mailman/listinfo/opendnssec-develop From jerry at opendnssec.org Tue Oct 18 13:57:15 2011 From: jerry at opendnssec.org (Jerry =?ISO-8859-1?B?THVuZHN0cvZt?=) Date: Tue, 18 Oct 2011 15:57:15 +0200 Subject: [Opendnssec-develop] Supported build dependency for libraries etc In-Reply-To: <39CE0374-BD85-4C66-B83B-5F02B18C96E3@sinodun.com> Message-ID: Hi, In my and John discussions how to build this we have come up with a couple of solutions and here they are. A note on B is that you could use jenkins version matrix as described in A for the major branch name to minimize the job count but you wont as easily see what breaks. /Jerry -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: SolutionA.txt URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: SolutionB.txt URL: From jad at sinodun.com Tue Oct 18 14:49:23 2011 From: jad at sinodun.com (John Dickinson) Date: Tue, 18 Oct 2011 15:49:23 +0100 Subject: [Opendnssec-develop] Server with 16Gb memory Message-ID: <84C95EFE-4FD4-438E-8EFD-C7CDF157338E@sinodun.com> Hi, Would a test machine with 16Gb of ram be of use in testing with large or many zones? I am happy to donate machine time to the OpenDNSSEC project if it would. John --- jad at sinodun.com Sinodun Internet Technologies Ltd. Stables 4, Suite 11, Howbery Park, Wallingford, Oxfordshire, OX10 8BA, U.K. +44 (0)1491 834957 From rickard at opendnssec.org Wed Oct 19 06:40:17 2011 From: rickard at opendnssec.org (Rickard Bellgrim) Date: Wed, 19 Oct 2011 08:40:17 +0200 Subject: [Opendnssec-develop] Enforcer NG 50.000 zones Message-ID: Hi I was planning to run a 50.000-zones-test with Enforcer NG, but I noticed that we did not have the "zone add"-command. Has it been dropped or just not implemented yet? // Rickard From yuri at nlnetlabs.nl Wed Oct 19 07:49:41 2011 From: yuri at nlnetlabs.nl (Yuri Schaeffer) Date: Wed, 19 Oct 2011 09:49:41 +0200 Subject: [Opendnssec-develop] Enforcer NG 50.000 zones In-Reply-To: References: Message-ID: <4E9E8115.9040904@nlnetlabs.nl> > I was planning to run a 50.000-zones-test with Enforcer NG, but I > noticed that we did not have the "zone add"-command. Has it been > dropped or just not implemented yet? IIRC we marked it as future in one of the teleconfs. //yuri From rickard at opendnssec.org Wed Oct 19 07:52:49 2011 From: rickard at opendnssec.org (Rickard Bellgrim) Date: Wed, 19 Oct 2011 09:52:49 +0200 Subject: [Opendnssec-develop] Enforcer NG 50.000 zones In-Reply-To: <4E9E8115.9040904@nlnetlabs.nl> References: <4E9E8115.9040904@nlnetlabs.nl> Message-ID: >> I was planning to run a 50.000-zones-test with Enforcer NG, but I noticed >> that we did not have the "zone add"-command. Has it been dropped or just not >> implemented yet? > > IIRC we marked it as future in one of the teleconfs. Yes, right. So, to test this, you need to create a zonelist.xml with 50.000 zones. Import it. See how the system handles this. Try adding some more zones in the zonelist and see if this can be quickly picked up by the Enforcer. // Rickard From rickard at opendnssec.org Wed Oct 19 09:37:16 2011 From: rickard at opendnssec.org (Rickard Bellgrim) Date: Wed, 19 Oct 2011 11:37:16 +0200 Subject: [Opendnssec-develop] Enforcer NG 50.000 zones In-Reply-To: References: <4E9E8115.9040904@nlnetlabs.nl> Message-ID: > So, to test this, you need to create a zonelist.xml with 50.000 zones. > Import it. See how the system handles this. Try adding some more zones > in the zonelist and see if this can be quickly picked up by the > Enforcer. Got some problems testing this. 1. Created the zonelist 2. Start and setup the Enforcer 3. "ods-enforcer enforce" to start enforcing. 4. Got an error. ... Next update for zone 41649small.ods scheduled at Wed Oct 19 09:21:00 2011 Next update for zone 41650small.ods scheduled at Wed Oct 19 09:21:00 2011 Next update for zone 41651small.ods scheduled at Wed Oct 19 09:21:00 2011 terminate called after throwing an instance of 'std::length_error' what(): basic_string::_S_create // Rickard From nick.vandenheuvel at sidn.nl Wed Oct 19 09:44:51 2011 From: nick.vandenheuvel at sidn.nl (Nick van den Heuvel) Date: Wed, 19 Oct 2011 09:44:51 +0000 Subject: [Opendnssec-develop] Enforcer NG 50.000 zones In-Reply-To: References: <4E9E8115.9040904@nlnetlabs.nl> Message-ID: <8379DE00FDBE1B4F95522D088EC260DD12BABB@kambx2.SIDN.local> Hi Rickard, I hereby send the missing zonefiles. Regards, Nick Met vriendelijke groet, Nick van den Heuvel Test analist SIDN | Utrechtseweg 310 | 6802 EA | Postbus 5022 | 6802 EA | ARNHEM T +31 (0)26 352 55 93 | F +31 (0)26 352 55 05 | jabber: nick.vandenheuvel at jabber.sidn.nl nick.vandenheuvel at sidn.nl | www.sidn.nl SIDN heeft een nieuw domein! Vanaf 31 oktober zijn wij gevestigd op een nieuw adres: Meander 501, 6825 MD Arnhem. Het postadres en de telefoonnummers blijven ongewijzigd. SIDN has a new domain! From 31 October, our office address will be: Meander 501, 6825 MD Arnhem, The Netherlands. Our postal address and phone numbers remain unchanged. -----Original Message----- From: opendnssec-develop-bounces at lists.opendnssec.org [mailto:opendnssec-develop-bounces at lists.opendnssec.org] On Behalf Of Rickard Bellgrim Sent: woensdag 19 oktober 2011 11:37 To: Yuri Schaeffer Cc: opendnssec-develop at lists.opendnssec.org Subject: Re: [Opendnssec-develop] Enforcer NG 50.000 zones > So, to test this, you need to create a zonelist.xml with 50.000 zones. > Import it. See how the system handles this. Try adding some more zones > in the zonelist and see if this can be quickly picked up by the > Enforcer. Got some problems testing this. 1. Created the zonelist 2. Start and setup the Enforcer 3. "ods-enforcer enforce" to start enforcing. 4. Got an error. ... Next update for zone 41649small.ods scheduled at Wed Oct 19 09:21:00 2011 Next update for zone 41650small.ods scheduled at Wed Oct 19 09:21:00 2011 Next update for zone 41651small.ods scheduled at Wed Oct 19 09:21:00 2011 terminate called after throwing an instance of 'std::length_error' what(): basic_string::_S_create // Rickard _______________________________________________ Opendnssec-develop mailing list Opendnssec-develop at lists.opendnssec.org https://lists.opendnssec.org/mailman/listinfo/opendnssec-develop -------------- next part -------------- A non-text attachment was scrubbed... Name: missing zones.zip Type: application/x-zip-compressed Size: 17114 bytes Desc: missing zones.zip URL: From yuri at nlnetlabs.nl Wed Oct 19 10:50:40 2011 From: yuri at nlnetlabs.nl (Yuri Schaeffer) Date: Wed, 19 Oct 2011 12:50:40 +0200 Subject: [Opendnssec-develop] Enforcer NG 50.000 zones In-Reply-To: References: <4E9E8115.9040904@nlnetlabs.nl> Message-ID: <4E9EAB80.6050300@nlnetlabs.nl> > Got some problems testing this. > > 1. Created the zonelist > 2. Start and setup the Enforcer > 3. "ods-enforcer enforce" to start enforcing. > 4. Got an error. I'm not seeing the same behaviour. I see other problems, but no crashes. A quick 50.000 test: - enforce command returned in 4 seconds. Note: not enough keys available, so 49.996 zones did not introduce any keys. (with excessive logging at took 10 seconds) - adding zone 50.001 and run update zonelist: 3 seconds the bad: - keys are being reused - the enforcer does not do its best to generate enough keys - return times are waaaay in to the future. //yuri From rickard at opendnssec.org Wed Oct 19 11:06:31 2011 From: rickard at opendnssec.org (Rickard Bellgrim) Date: Wed, 19 Oct 2011 13:06:31 +0200 Subject: [Opendnssec-develop] Enforcer NG 50.000 zones In-Reply-To: <4E9EAB80.6050300@nlnetlabs.nl> References: <4E9E8115.9040904@nlnetlabs.nl> <4E9EAB80.6050300@nlnetlabs.nl> Message-ID: > the bad: > - keys are being reused But you need shared keys to minimize the key generation time and make the key store smaller. // Rickard From yuri at nlnetlabs.nl Wed Oct 19 11:19:17 2011 From: yuri at nlnetlabs.nl (Yuri Schaeffer) Date: Wed, 19 Oct 2011 13:19:17 +0200 Subject: [Opendnssec-develop] Enforcer NG 50.000 zones In-Reply-To: References: <4E9E8115.9040904@nlnetlabs.nl> <4E9EAB80.6050300@nlnetlabs.nl> Message-ID: <4E9EB235.4080602@nlnetlabs.nl> > But you need shared keys to minimize the key generation time and make > the key store smaller. Well yes, but I did not configure my policy to do so. //yuri From sara at sinodun.com Wed Oct 19 12:37:31 2011 From: sara at sinodun.com (Sara Dickinson) Date: Wed, 19 Oct 2011 13:37:31 +0100 Subject: Fwd: [Opendnssec-develop] Meeting 20111019 References: Message-ID: <49B99C00-64A9-445D-90AF-903C5D106206@sinodun.com> Hi All, The confluence version of the existing 1.3 documentation is now live (i.e. linked from the Wordpress site) here: https://wiki.opendnssec.org/display/DOCS I've been working on a copy of this documentation to re-organise and add to it and this is available for review here: https://wiki.opendnssec.org/display/ODSDOC140 it is labelled as 1.4 for now but the content has not changed compared to the 1.3 docs. Feedback on this or proof reading would be greatly appreciated! (The SoftHSM docs are not split out yet while I work out the best way to cross-reference the documentation) The new process for updating the Confluence docs is here: http://trac.opendnssec.org/wiki/DevelopmentProcessConf again - feedback is welcomed. Regards Sara. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jakob at kirei.se Wed Oct 19 12:39:16 2011 From: jakob at kirei.se (Jakob Schlyter) Date: Wed, 19 Oct 2011 14:39:16 +0200 Subject: [Opendnssec-develop] Meeting 20111019 In-Reply-To: <49B99C00-64A9-445D-90AF-903C5D106206@sinodun.com> References: <49B99C00-64A9-445D-90AF-903C5D106206@sinodun.com> Message-ID: <6908B0DB-0C41-43A0-BBB2-7FF5546FE541@kirei.se> On 19 okt 2011, at 14:37, Sara Dickinson wrote: > The new process for updating the Confluence docs is here: > > http://trac.opendnssec.org/wiki/DevelopmentProcessConf IMHO, we can move this to Confluence as well; just put it somewhere in https://wiki.opendnssec.org/display/OpenDNSSEC/ for now. jakob From matthijs at NLnetLabs.nl Wed Oct 19 12:53:45 2011 From: matthijs at NLnetLabs.nl (Matthijs Mekking) Date: Wed, 19 Oct 2011 14:53:45 +0200 Subject: [Opendnssec-develop] Meeting 20111019 In-Reply-To: References: Message-ID: <4E9EC859.6040400@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Minutes http://trac.opendnssec.org/wiki/Meetings/Minutes/2011-10-19 On 10/18/2011 03:26 PM, Rickard Bellgrim wrote: > Hi > > We have a meeting tomorrow. > > Agenda: > http://trac.opendnssec.org/wiki/Meetings/Agenda/2011-10-19 > > Please add any topics you would like to discuss. > > // 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.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJOnshYAAoJEA8yVCPsQCW5mOcH/0SNBkBjmm5ECNnNBc2z2ydL E60XXIdYsS/wZlVDNVSV4lgj5ivZ9VPfD7oAS1HpovdxCV2d1d0h7F8CbhwVKGCc NLSlJg2l9bH/yOTLGD/AuVGtSwyrXGLJp+waavP1z8OCBPYFjasqm1kg1kZYxQxe Asts5vXrM6AEmD/5kKuT9N37YVIN9rMbOPonvhC3c8D/irVqcyaGzGQpAV+0hNO/ qX0pXTxbhrT9atOlSFt9c4U6wsToORecOTFu5MYnWVve0YJ63eE1jL4nHaawD8ew b238fPEo4+DUYooB1jKFfwiO9renm7qgHgKEx7LwyrjT4yt2Xm/sSjYvwlIjg7o= =aX7w -----END PGP SIGNATURE----- From rickard at opendnssec.org Wed Oct 19 12:54:01 2011 From: rickard at opendnssec.org (Rickard Bellgrim) Date: Wed, 19 Oct 2011 14:54:01 +0200 Subject: [Opendnssec-develop] Meeting 20111019 In-Reply-To: <6908B0DB-0C41-43A0-BBB2-7FF5546FE541@kirei.se> References: <49B99C00-64A9-445D-90AF-903C5D106206@sinodun.com> <6908B0DB-0C41-43A0-BBB2-7FF5546FE541@kirei.se> Message-ID: >> The new process for updating the Confluence docs is here: >> >> http://trac.opendnssec.org/wiki/DevelopmentProcessConf > > IMHO, we can move this to Confluence as well; just put it somewhere in https://wiki.opendnssec.org/display/OpenDNSSEC/ for now. Maybe we should open a new work space called e.g. "project" where we can have our processes, project documentation, agendas, meeting notes, etc. // Rickard From matthijs at NLnetLabs.nl Wed Oct 19 13:00:15 2011 From: matthijs at NLnetLabs.nl (Matthijs Mekking) Date: Wed, 19 Oct 2011 15:00:15 +0200 Subject: [Opendnssec-develop] A NotifyCommand script blocks, what to do? Message-ID: <4E9EC9DF.3080303@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 This is a follow-up from today's meeting AOB. The case: OpenDNSSEC has a configured to notify a name server. The configured script never terminates and the associated worker and zone are being blocked and will be forever in the [write] task. Is this what we want (let the worker wait until the notify command is terminated)? Or do we want the signer daemon to fork off the notify command script and continue its process regardless of the result of the notify command script? In the latter case, you will get fresh signed zone files, but we don't know if they are ever picked up by the name server. Best regards, Matthijs -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJOnsnfAAoJEA8yVCPsQCW5NhkIAM80gMgHKFCQv/DIajc/iZ5B hoRoU8DfQD7cbtRKy3GFyPCrOFTQJ7/GWDTIEvqivSsq8GoUxEwfbm1tBNl/YuA6 xNUJpxuzr2QF3okfqG8VmB/WIQ4hkSuJPCpPQelSIvtZ1Je9GeNv7bl5CRD/mgrv A0yEfziszyK+gcM6GGfhzDFW/+aT/CtZIh/O8scU8pNvAL4o+hxC9PVGoH13qzAd wmTLyslxj+L526IzZgiLuH//mxpLvh4/NdZanh7WsJZ6+B+NNqjRzQZInXzTKMY7 UDLlhpufxShY1EYNvFnlGOiLEQ8HMwp3LDNb8CZl6IXR2CLEMMGkwiRBnBS/R64= =DdhV -----END PGP SIGNATURE----- From yuri at nlnetlabs.nl Wed Oct 19 14:14:52 2011 From: yuri at nlnetlabs.nl (Yuri Schaeffer) Date: Wed, 19 Oct 2011 16:14:52 +0200 Subject: [Opendnssec-develop] A NotifyCommand script blocks, what to do? In-Reply-To: <4E9EC9DF.3080303@nlnetlabs.nl> References: <4E9EC9DF.3080303@nlnetlabs.nl> Message-ID: <4E9EDB5C.9040705@nlnetlabs.nl> > Is this what we want (let the worker wait until the notify command is > terminated)? Or do we want the signer daemon to fork off the notify > command script and continue its process regardless of the result of the > notify command script? In the latter case, you will get fresh signed > zone files, but we don't know if they are ever picked up by the name server. Neither sound very compelling, although I'm unsure what you currently do when a notify fails. Would it be possible to fork off the script and let the fork schedule a task upon completion for a worker to pickup, read and act upon the status? Having the workers block for a long time does not seem to be a good idea to me. //yuri From jad at sinodun.com Wed Oct 19 14:49:42 2011 From: jad at sinodun.com (John Dickinson) Date: Wed, 19 Oct 2011 15:49:42 +0100 Subject: [Opendnssec-develop] A NotifyCommand script blocks, what to do? In-Reply-To: <4E9EDB5C.9040705@nlnetlabs.nl> References: <4E9EC9DF.3080303@nlnetlabs.nl> <4E9EDB5C.9040705@nlnetlabs.nl> Message-ID: <29F61A98-418D-44AD-B291-08C95179E40F@sinodun.com> What do name servers do? Do they really wait for the notify response or do they get on with better things and let the secondary decide if and when it will get the xfr? How about it tries a few (5?) times and then carries on. John On 19 Oct 2011, at 15:14, Yuri Schaeffer wrote: >> Is this what we want (let the worker wait until the notify command is >> terminated)? Or do we want the signer daemon to fork off the notify >> command script and continue its process regardless of the result of the >> notify command script? In the latter case, you will get fresh signed >> zone files, but we don't know if they are ever picked up by the name server. > > Neither sound very compelling, although I'm unsure what you currently do when a notify fails. > > Would it be possible to fork off the script and let the fork schedule a task upon completion for a worker to pickup, read and act upon the status? > > Having the workers block for a long time does not seem to be a good idea to me. > > //yuri > _______________________________________________ > Opendnssec-develop mailing list > Opendnssec-develop at lists.opendnssec.org > https://lists.opendnssec.org/mailman/listinfo/opendnssec-develop --- jad at sinodun.com Sinodun Internet Technologies Ltd. Stables 4, Suite 11, Howbery Park, Wallingford, Oxfordshire, OX10 8BA, U.K. +44 (0)1491 834957 From nick.vandenheuvel at sidn.nl Wed Oct 19 15:06:49 2011 From: nick.vandenheuvel at sidn.nl (Nick van den Heuvel) Date: Wed, 19 Oct 2011 15:06:49 +0000 Subject: [Opendnssec-develop] A NotifyCommand script blocks, what to do? In-Reply-To: <29F61A98-418D-44AD-B291-08C95179E40F@sinodun.com> References: <4E9EC9DF.3080303@nlnetlabs.nl> <4E9EDB5C.9040705@nlnetlabs.nl> <29F61A98-418D-44AD-B291-08C95179E40F@sinodun.com> Message-ID: <8379DE00FDBE1B4F95522D088EC260DD138619@kambx2.SIDN.local> To my information, nameservers indeed wait till they get a notify that a new zonefile is ready. Regards, Nick Met vriendelijke groet, Nick van den Heuvel Test analist SIDN | Utrechtseweg 310 | 6802 EA | Postbus 5022 | 6802 EA | ARNHEM T +31 (0)26 352 55 93 | F +31 (0)26 352 55 05 | jabber: nick.vandenheuvel at jabber.sidn.nl nick.vandenheuvel at sidn.nl | www.sidn.nl SIDN heeft een nieuw domein! Vanaf 31 oktober zijn wij gevestigd op een nieuw adres: Meander 501, 6825 MD Arnhem. Het postadres en de telefoonnummers blijven ongewijzigd. SIDN has a new domain! From 31 October, our office address will be: Meander 501, 6825 MD Arnhem, The Netherlands. Our postal address and phone numbers remain unchanged. -----Original Message----- From: opendnssec-develop-bounces at lists.opendnssec.org [mailto:opendnssec-develop-bounces at lists.opendnssec.org] On Behalf Of John Dickinson Sent: woensdag 19 oktober 2011 16:50 To: opendnssec-develop at lists.opendnssec.org Subject: Re: [Opendnssec-develop] A NotifyCommand script blocks, what to do? What do name servers do? Do they really wait for the notify response or do they get on with better things and let the secondary decide if and when it will get the xfr? How about it tries a few (5?) times and then carries on. John On 19 Oct 2011, at 15:14, Yuri Schaeffer wrote: >> Is this what we want (let the worker wait until the notify command is >> terminated)? Or do we want the signer daemon to fork off the notify >> command script and continue its process regardless of the result of the >> notify command script? In the latter case, you will get fresh signed >> zone files, but we don't know if they are ever picked up by the name server. > > Neither sound very compelling, although I'm unsure what you currently do when a notify fails. > > Would it be possible to fork off the script and let the fork schedule a task upon completion for a worker to pickup, read and act upon the status? > > Having the workers block for a long time does not seem to be a good idea to me. > > //yuri > _______________________________________________ > Opendnssec-develop mailing list > Opendnssec-develop at lists.opendnssec.org > https://lists.opendnssec.org/mailman/listinfo/opendnssec-develop --- jad at sinodun.com Sinodun Internet Technologies Ltd. Stables 4, Suite 11, Howbery Park, Wallingford, Oxfordshire, OX10 8BA, U.K. +44 (0)1491 834957 _______________________________________________ Opendnssec-develop mailing list Opendnssec-develop at lists.opendnssec.org https://lists.opendnssec.org/mailman/listinfo/opendnssec-develop From jad at sinodun.com Wed Oct 19 15:12:12 2011 From: jad at sinodun.com (John Dickinson) Date: Wed, 19 Oct 2011 16:12:12 +0100 Subject: [Opendnssec-develop] A NotifyCommand script blocks, what to do? In-Reply-To: <8379DE00FDBE1B4F95522D088EC260DD138619@kambx2.SIDN.local> References: <4E9EC9DF.3080303@nlnetlabs.nl> <4E9EDB5C.9040705@nlnetlabs.nl> <29F61A98-418D-44AD-B291-08C95179E40F@sinodun.com> <8379DE00FDBE1B4F95522D088EC260DD138619@kambx2.SIDN.local> Message-ID: <674FFF0B-2DA3-45D7-ADF6-6971F9015D26@sinodun.com> Hi, Sorry, to be clearer, I mean the notify sending name server. John On 19 Oct 2011, at 16:06, Nick van den Heuvel wrote: > To my information, nameservers indeed wait till they get a notify that a new zonefile is ready. > > Regards, > Nick > > Met vriendelijke groet, > > Nick van den Heuvel > Test analist > > SIDN | Utrechtseweg 310 | 6802 EA | Postbus 5022 | 6802 EA | ARNHEM > T +31 (0)26 352 55 93 | F +31 (0)26 352 55 05 | jabber: nick.vandenheuvel at jabber.sidn.nl > nick.vandenheuvel at sidn.nl | www.sidn.nl > > > SIDN heeft een nieuw domein! Vanaf 31 oktober zijn wij gevestigd op een nieuw adres: > Meander 501, 6825 MD Arnhem. > Het postadres en de telefoonnummers blijven ongewijzigd. > > SIDN has a new domain! From 31 October, our office address will be: > Meander 501, 6825 MD Arnhem, The Netherlands. > Our postal address and phone numbers remain unchanged. > > > > -----Original Message----- > From: opendnssec-develop-bounces at lists.opendnssec.org [mailto:opendnssec-develop-bounces at lists.opendnssec.org] On Behalf Of John Dickinson > Sent: woensdag 19 oktober 2011 16:50 > To: opendnssec-develop at lists.opendnssec.org > Subject: Re: [Opendnssec-develop] A NotifyCommand script blocks, what to do? > > What do name servers do? Do they really wait for the notify response or do they get on with better things and let the secondary decide if and when it will get the xfr? > > How about it tries a few (5?) times and then carries on. > > John > On 19 Oct 2011, at 15:14, Yuri Schaeffer wrote: > >>> Is this what we want (let the worker wait until the notify command is >>> terminated)? Or do we want the signer daemon to fork off the notify >>> command script and continue its process regardless of the result of the >>> notify command script? In the latter case, you will get fresh signed >>> zone files, but we don't know if they are ever picked up by the name server. >> >> Neither sound very compelling, although I'm unsure what you currently do when a notify fails. >> >> Would it be possible to fork off the script and let the fork schedule a task upon completion for a worker to pickup, read and act upon the status? >> >> Having the workers block for a long time does not seem to be a good idea to me. >> >> //yuri >> _______________________________________________ >> Opendnssec-develop mailing list >> Opendnssec-develop at lists.opendnssec.org >> https://lists.opendnssec.org/mailman/listinfo/opendnssec-develop > > --- > jad at sinodun.com > Sinodun Internet Technologies Ltd. > Stables 4, Suite 11, > Howbery Park, > Wallingford, > Oxfordshire, > OX10 8BA, > U.K. > > +44 (0)1491 834957 > > _______________________________________________ > Opendnssec-develop mailing list > Opendnssec-develop at lists.opendnssec.org > https://lists.opendnssec.org/mailman/listinfo/opendnssec-develop --- jad at sinodun.com Sinodun Internet Technologies Ltd. Stables 4, Suite 11, Howbery Park, Wallingford, Oxfordshire, OX10 8BA, U.K. +44 (0)1491 834957 From sara at sinodun.com Thu Oct 20 11:44:44 2011 From: sara at sinodun.com (Sara Dickinson) Date: Thu, 20 Oct 2011 12:44:44 +0100 Subject: [Opendnssec-develop] Meeting 20111019 In-Reply-To: References: <49B99C00-64A9-445D-90AF-903C5D106206@sinodun.com> <6908B0DB-0C41-43A0-BBB2-7FF5546FE541@kirei.se> Message-ID: <794B2230-8D8A-422E-9274-FEDF97354F5B@sinodun.com> OK - I think that answers my next question which was shall I now go ahead and set up the other spaces in Confluence.... *Apart from meeting agenda/minutes etc pages is anyone currently updating any pages on the TRAC wiki area or planning to do so this week or next week? Please let me know if you are or if there is anything you want to remain in TRAC wiki for some reason.* Otherwise tomorrow I will start migrating useful/active wiki content to Confluence and then archiving the TRAC wiki area for now (i.e add a banner redirecting users to Confluence and freeze the pages to updates). Sara. On 19 Oct 2011, at 13:54, Rickard Bellgrim wrote: >>> The new process for updating the Confluence docs is here: >>> >>> http://trac.opendnssec.org/wiki/DevelopmentProcessConf >> >> IMHO, we can move this to Confluence as well; just put it somewhere in https://wiki.opendnssec.org/display/OpenDNSSEC/ for now. > > Maybe we should open a new work space called e.g. "project" where we > can have our processes, project documentation, agendas, meeting notes, > etc. > > // Rickard From rickard at opendnssec.org Thu Oct 20 11:53:08 2011 From: rickard at opendnssec.org (Rickard Bellgrim) Date: Thu, 20 Oct 2011 13:53:08 +0200 Subject: [Opendnssec-develop] A NotifyCommand script blocks, what to do? In-Reply-To: <4E9EC9DF.3080303@nlnetlabs.nl> References: <4E9EC9DF.3080303@nlnetlabs.nl> Message-ID: > Is this what we want (let the worker wait until the notify command is > terminated)? Or do we want the signer daemon to fork off the notify > command script and continue its process regardless of the result of the > notify command script? In the latter case, you will get fresh signed > zone files, but we don't know if they are ever picked up by the name server. I think that we should wait until the script returns. Forking off processes, it that case, would just leave us with dead processes hanging around. The script should have some time outs. // Rickard From rickard at opendnssec.org Thu Oct 20 11:58:22 2011 From: rickard at opendnssec.org (Rickard Bellgrim) Date: Thu, 20 Oct 2011 13:58:22 +0200 Subject: [Opendnssec-develop] Automatic introduction of manual keys. In-Reply-To: <4E92B345.7010008@nlnetlabs.nl> References: <4E92B345.7010008@nlnetlabs.nl> Message-ID: > Enforcer: > Generate both keys and introduce them in the zone. This is not > considered a rollover. > > Enforcer NG: > Introduce only the ZSK. Wait for user signal to introduce the KSK. This > is a rollover like any other. > > Personally I like the new behavior, as it feels more consistent. The > user asks not to do any automatic stuff with the KSK, so we don't. The ManualRollover stops us from making a key retired. But it does not stop us from introducing a new key. We want to minimize the waiting time for the user by doing as much as possible before the user decides to retire the old key and make the new one active. // Rickard From jakob at kirei.se Thu Oct 20 12:08:17 2011 From: jakob at kirei.se (Jakob Schlyter) Date: Thu, 20 Oct 2011 14:08:17 +0200 Subject: [Opendnssec-develop] Meeting 20111019 In-Reply-To: References: <49B99C00-64A9-445D-90AF-903C5D106206@sinodun.com> <6908B0DB-0C41-43A0-BBB2-7FF5546FE541@kirei.se> Message-ID: On 19 okt 2011, at 14:54, Rickard Bellgrim wrote: > Maybe we should open a new work space called e.g. "project" where we > can have our processes, project documentation, agendas, meeting notes, > etc. That seems reasonable. Or just just the existing OPENDNSSEC space (where I've put the OAB and HSM info for now). jakob -- Jakob Schlyter Kirei AB - http://www.kirei.se/ From jakob at kirei.se Thu Oct 20 12:08:45 2011 From: jakob at kirei.se (Jakob Schlyter) Date: Thu, 20 Oct 2011 14:08:45 +0200 Subject: [Opendnssec-develop] Meeting 20111019 In-Reply-To: <794B2230-8D8A-422E-9274-FEDF97354F5B@sinodun.com> References: <49B99C00-64A9-445D-90AF-903C5D106206@sinodun.com> <6908B0DB-0C41-43A0-BBB2-7FF5546FE541@kirei.se> <794B2230-8D8A-422E-9274-FEDF97354F5B@sinodun.com> Message-ID: <567240A4-A72C-4591-A933-6DBFFEC25F5F@kirei.se> On 20 okt 2011, at 13:44, Sara Dickinson wrote: > Otherwise tomorrow I will start migrating useful/active wiki content to Confluence and then archiving the TRAC wiki area for now (i.e add a banner redirecting users to Confluence and freeze the pages to updates). Yes, please. jakob From rickard at opendnssec.org Thu Oct 20 12:14:02 2011 From: rickard at opendnssec.org (Rickard Bellgrim) Date: Thu, 20 Oct 2011 14:14:02 +0200 Subject: [Opendnssec-develop] Re: [Opendnssec-otr] softhsm In-Reply-To: <19F76555-F788-4BFC-A66C-EDB14007A35D@sinodun.com> References: <1CF2995B-3372-40E5-935E-421628C7392C@sinodun.com> <19F76555-F788-4BFC-A66C-EDB14007A35D@sinodun.com> Message-ID: >> ? ? ? libbotan-1.8.2.so => not found >> ? ? ? libbotan-1.8.13.so => not found This is probably not the problem, but the library for Botan 1.8.13 should be named libbotan-1.8.2.so. Jack got some complaints that he change the library name for each release. The (library) version number should be after the .so suffix. So as of version 1.8.2 he froze the library name. Version 1.10.X is called libbotan-1.10.so. He then probably forgot that for this release. Is this what is mixing up the library linking? From rickard at opendnssec.org Thu Oct 20 12:34:38 2011 From: rickard at opendnssec.org (Rickard Bellgrim) Date: Thu, 20 Oct 2011 14:34:38 +0200 Subject: [Opendnssec-develop] Re: [Opendnssec-otr] softhsm In-Reply-To: <19F76555-F788-4BFC-A66C-EDB14007A35D@sinodun.com> References: <1CF2995B-3372-40E5-935E-421628C7392C@sinodun.com> <19F76555-F788-4BFC-A66C-EDB14007A35D@sinodun.com> Message-ID: > I think at the very least we should make the order the same, or improve the m4 file for sqlite. I would like a second opinion before making any change. The changes look good. // Rickard From jad at sinodun.com Thu Oct 20 12:35:15 2011 From: jad at sinodun.com (John Dickinson) Date: Thu, 20 Oct 2011 13:35:15 +0100 Subject: [Opendnssec-develop] [Opendnssec-otr] softhsm In-Reply-To: References: <1CF2995B-3372-40E5-935E-421628C7392C@sinodun.com> <19F76555-F788-4BFC-A66C-EDB14007A35D@sinodun.com> Message-ID: There were actually both versions installed and because of the different ordering of the @botan_libs@ and @sqlite3_libs@ in the two Makefile.am's one ended up linking against the botan in /usr/local/lib and the other against the fakeroot/lib I had specified in the configure. The /usr/local/lib was only used at all because --with-sqlite3 defaulted to /usr/local if not specified even though sqlite3 was not in /usr/local. (i.e. the @sqlite3_libs@ contained -L/usr/local/lib -lsqlite3 but sqlite3 was in /usr/lib and could be found by configure without being specified using --with-sqlite3). As you know the ordering of -L's is important and in one case it was causing the incorrect botan to be linked. the ldd command shows them as not found because neither location was in ld.conf (or whatever redhat uses). John On 20 Oct 2011, at 13:14, Rickard Bellgrim wrote: >>> libbotan-1.8.2.so => not found >>> libbotan-1.8.13.so => not found > > This is probably not the problem, but the library for Botan 1.8.13 > should be named libbotan-1.8.2.so. Jack got some complaints that he > change the library name for each release. The (library) version number > should be after the .so suffix. So as of version 1.8.2 he froze the > library name. Version 1.10.X is called libbotan-1.10.so. > > He then probably forgot that for this release. Is this what is mixing > up the library linking? --- jad at sinodun.com Sinodun Internet Technologies Ltd. Stables 4, Suite 11, Howbery Park, Wallingford, Oxfordshire, OX10 8BA, U.K. +44 (0)1491 834957 From matthijs at NLnetLabs.nl Fri Oct 21 07:56:37 2011 From: matthijs at NLnetLabs.nl (Matthijs Mekking) Date: Fri, 21 Oct 2011 09:56:37 +0200 Subject: [Opendnssec-develop] A NotifyCommand script blocks, what to do? In-Reply-To: References: <4E9EC9DF.3080303@nlnetlabs.nl> Message-ID: <4EA125B5.7080700@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 10/20/2011 01:53 PM, Rickard Bellgrim wrote: >> Is this what we want (let the worker wait until the notify command is >> terminated)? Or do we want the signer daemon to fork off the notify >> command script and continue its process regardless of the result of the >> notify command script? In the latter case, you will get fresh signed >> zone files, but we don't know if they are ever picked up by the name server. > > I think that we should wait until the script returns. Forking off > processes, it that case, would just leave us with dead processes > hanging around. The script should have some time outs. Note that we do not have control of the scripts. > > // Rickard -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJOoSW0AAoJEA8yVCPsQCW5XWkH/2V1wpWyjtKjVeCE2e9nnuFS +khEfD4qpvuIG33QclFhc7U/WZY3rzdrUM1gXnDFG0pBvOWfQAnsabtboksf0kov SkYJstTNN/BZsLETzdXth4Dz7muZjNIq+fF0lx5cj400NEYaplZrpySX6oyxGJHs yNAZj91JjffNsxD9u2aXPZXTCOK+RTZ5XBViH9Ys3lzNSfNz9xKJCPTX8QqGjjTy YCOo3e6m1+u4B79ZQU0OcvEKZ1o+ZoWlagAjCzdZZTBAwS2tR8bU2yXF7e+ZWqXA p7m9HhQMpp1uT5tt9/fIONB4kpCfSTCHlQQIAM08XNpOcwEEcATyw41O6i5FBhc= =a5i9 -----END PGP SIGNATURE----- From jerry at opendnssec.org Fri Oct 21 11:33:17 2011 From: jerry at opendnssec.org (Jerry =?ISO-8859-1?B?THVuZHN0cvZt?=) Date: Fri, 21 Oct 2011 13:33:17 +0200 Subject: [Opendnssec-develop] Moving to JIRA next week Message-ID: Hi, I will be setting up JIRA for usage next week and wanted to run the setup by you all for comments and thoughts around it. There will be two project categories, Development and Support. In Development we will have the projects OpenDNSSEC and SoftHSM. For the Support category we will have the corresponding projects with " Support" added. The default workflow will be used for all project at the start, later there might be change to the support workflows but for development the default JIRA workflow with the added Green Hopper (Agile) stuff will do. There will be simplified issue dialogs for the support part so its easier for users to submit issues. I also want to enable creating issues via email, if we get too many spams we can always block it (and I mean many more then the 1-2 per month we have today). As for issues types there are many now with the Agile way so we might slim it down later and the support part won't get the Agile stuff, for that there will just be Bug, Feature Request and Support. Why have separate development and support projects you might ask? Reason behind this is that its very hard/impossible to control who gets to create what kind of issues or what kind of fields need to be filled depending on the user. There really isn't any good solution for this, the "best" I have seen is client side java script hacks that blocks the user. I believe it will be easier to maintain the development projects by separating the support part so it does not clog up Green Hopper. Comments/thoughts? /Jerry -------------- next part -------------- An HTML attachment was scrubbed... URL: From rickard at opendnssec.org Fri Oct 21 11:45:21 2011 From: rickard at opendnssec.org (Rickard Bellgrim) Date: Fri, 21 Oct 2011 13:45:21 +0200 Subject: [Opendnssec-develop] Moving to JIRA next week In-Reply-To: References: Message-ID: > I also want to enable creating issues via email, > if we get too many spams we can always block it (and I mean many more then > the 1-2 per month we have today). Some systems require you to be a registered user before your are allowed to send an email. Or is it completely open in this case? > Comments/thoughts? Well done! // Rickard From jerry at opendnssec.org Fri Oct 21 11:51:19 2011 From: jerry at opendnssec.org (Jerry =?ISO-8859-1?B?THVuZHN0cvZt?=) Date: Fri, 21 Oct 2011 13:51:19 +0200 Subject: [Opendnssec-develop] Moving to JIRA next week In-Reply-To: Message-ID: On 2011-10-21 13.45, Rickard Bellgrim wrote: >Some systems require you to be a registered user before your are >allowed to send an email. Or is it completely open in this case? I want this to be completely open for starters, if it can be done :) Most request tracking systems can create users on the fly or handle it with just the email but JIRA isn't really that kind of tool, I just feel it would be a shame if we couldn't handle issues via email also. /Jerry From jakob at kirei.se Fri Oct 21 12:34:08 2011 From: jakob at kirei.se (Jakob Schlyter) Date: Fri, 21 Oct 2011 14:34:08 +0200 Subject: [Opendnssec-develop] Moving to JIRA next week In-Reply-To: References: Message-ID: <50F57EA4-4BFA-47E0-A061-473FAF6522A9@kirei.se> On 21 okt 2011, at 13:33, Jerry Lundstr?m wrote: > There will be simplified issue dialogs for the support part so its easier for users to submit issues. I also want to enable creating issues via email, if we get too many spams we can always block it (and I mean many more then the 1-2 per month we have today). Given that we use the quite efficient spam-filter at Google, I think this workable. > Comments/thoughts? Nice work! jakob From yuri at nlnetlabs.nl Fri Oct 21 12:41:28 2011 From: yuri at nlnetlabs.nl (Yuri Schaeffer) Date: Fri, 21 Oct 2011 14:41:28 +0200 Subject: [Opendnssec-develop] Automatic introduction of manual keys. In-Reply-To: References: <4E92B345.7010008@nlnetlabs.nl> Message-ID: <4EA16878.709@nlnetlabs.nl> > The ManualRollover stops us from making a key retired. But it does not > stop us from introducing a new key. We want to minimize the waiting > time for the user by doing as much as possible before the user decides > to retire the old key and make the new one active. So what you are suggesting is the following?: 1) key A reached lifetime, generate new key B 2) Intro key B, but hold DS ... wait for user input 3) Switch DS key A and B 4) outro key A This seems really awkward to me, especially since the DS switch currently is a manual process anyway. What about manual ZSK's? What parts will be introduced before the user gives the command? I might be missing the point of manual keys. //yuri From jad at sinodun.com Fri Oct 21 14:29:17 2011 From: jad at sinodun.com (John Dickinson) Date: Fri, 21 Oct 2011 15:29:17 +0100 Subject: [Opendnssec-develop] A NotifyCommand script blocks, what to do? In-Reply-To: <4EA125B5.7080700@nlnetlabs.nl> References: <4E9EC9DF.3080303@nlnetlabs.nl> <4EA125B5.7080700@nlnetlabs.nl> Message-ID: <2ECD9389-F28C-44A9-9514-CA6AB6B032A0@sinodun.com> On 21 Oct 2011, at 08:56, Matthijs Mekking wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 10/20/2011 01:53 PM, Rickard Bellgrim wrote: >>> Is this what we want (let the worker wait until the notify command is >>> terminated)? Or do we want the signer daemon to fork off the notify >>> command script and continue its process regardless of the result of the >>> notify command script? In the latter case, you will get fresh signed >>> zone files, but we don't know if they are ever picked up by the name server. >> >> I think that we should wait until the script returns. Forking off >> processes, it that case, would just leave us with dead processes >> hanging around. The script should have some time outs. > > Note that we do not have control of the scripts. Could we require the user to specify a timeout for the script? John --- jad at sinodun.com Sinodun Internet Technologies Ltd. Stables 4, Suite 11, Howbery Park, Wallingford, Oxfordshire, OX10 8BA, U.K. +44 (0)1491 834957 From rickard at opendnssec.org Fri Oct 21 15:08:35 2011 From: rickard at opendnssec.org (Rickard Bellgrim) Date: Fri, 21 Oct 2011 17:08:35 +0200 Subject: [Opendnssec-develop] Automatic introduction of manual keys. In-Reply-To: <4EA16878.709@nlnetlabs.nl> References: <4E92B345.7010008@nlnetlabs.nl> <4EA16878.709@nlnetlabs.nl> Message-ID: > So what you are suggesting is the following?: > > 1) key A reached lifetime, generate new key B > 2) Intro key B, but hold DS > > ... wait for user input > > 3) Switch DS key A and B > 4) outro key A > > This seems really awkward to me, especially since the DS switch currently is > a manual process anyway. Yes, that is the current behavior of the Enforcer. But we actually only recommend manual rollover for ZSK. There is no point of doing it for the KSK since we are anyways waiting for the DS. > What about manual ZSK's? What parts will be introduced before the user gives > the command? In the case of Pre-publish ZSK rollover, it would be ok to pre-publish the new ZSK. But then wait for the user to give the rollover command. // Rickard From jad at sinodun.com Sat Oct 22 18:05:14 2011 From: jad at sinodun.com (John Dickinson) Date: Sat, 22 Oct 2011 19:05:14 +0100 Subject: [Opendnssec-develop] Supported build dependency for libraries etc In-Reply-To: <8379DE00FDBE1B4F95522D088EC260DD12B108@kambx2.SIDN.local> References: <3DEC21FF-D942-49E7-8880-2BFC05963B6E@sinodun.com> <8379DE00FDBE1B4F95522D088EC260DD12B108@kambx2.SIDN.local> Message-ID: <7683AD3C-BE6B-4B15-823C-5EABBE36ABE4@sinodun.com> One other "dependancy" I have come across during my testing is building OpenDNSSEC with either sqlite3 or mysql. John On 18 Oct 2011, at 14:53, Nick van den Heuvel wrote: > --------------------------------------- > The packages that are special for OpenDNSSEC are ldns and dnsruby. > Botan for SoftHSM. I think it would be reasonable to just have the latest version installed in the test system, unless there are a major API change. You could have the argument that having old version helps us to detect if the developer has started to use new functions. But our main goal is to run the test scripts and our secondary goal is to see if the system builds. > ---------------------------------------- > Why not publish a list with the versions of supporting software which we used to test the release (attached to the release notes)? I do have some of these version included in my test report. > > > > --------------------------------------- > We do also say that we support current version of OpenDNSSEC and the two previous minor releases. So currently we have to run the test system for 1.1, 1.2, 1.3, and trunk. Have we agreed on how to treat the build scripts for these four different versions? > --------------------------------------- > > Not yet. Also depends on the patch released. > > Met vriendelijke groet, > > Nick van den Heuvel > Test analist > > SIDN | Utrechtseweg 310 | 6802 EA | Postbus 5022 | 6802 EA | ARNHEM > T +31 (0)26 352 55 93 | F +31 (0)26 352 55 05 | jabber: nick.vandenheuvel at jabber.sidn.nl > nick.vandenheuvel at sidn.nl | www.sidn.nl > > > SIDN heeft een nieuw domein! Vanaf 31 oktober zijn wij gevestigd op een nieuw adres: > Meander 501, 6825 MD Arnhem. > Het postadres en de telefoonnummers blijven ongewijzigd. > > SIDN has a new domain! From 31 October, our office address will be: > Meander 501, 6825 MD Arnhem, The Netherlands. > Our postal address and phone numbers remain unchanged. > > > > -----Original Message----- > From: opendnssec-develop-bounces at lists.opendnssec.org [mailto:opendnssec-develop-bounces at lists.opendnssec.org] On Behalf Of Rickard Bellgrim > Sent: dinsdag 18 oktober 2011 15:18 > To: Jerry Lundstr?m > Cc: opendnssec-develop at lists.opendnssec.org > Subject: Re: [Opendnssec-develop] Supported build dependency for libraries etc > > To summarize this... > > We depend on packages that should be available in all distributions: > sqlite, libxml2, (mysql) > > We have the build / configure specific packages like autoconf, > automake, gcc, etc. Those should also be available in all > distributions. > > The packages that are special for OpenDNSSEC are ldns and dnsruby. > Botan for SoftHSM. I think it would be reasonable to just have the > latest version installed in the test system, unless there are a major > API change. You could have the argument that having old version helps > us to detect if the developer has started to use new functions. But > our main goal is to run the test scripts and our secondary goal is to > see if the system builds. > > We do also say that we support current version of OpenDNSSEC and the > two previous minor releases. So currently we have to run the test > system for 1.1, 1.2, 1.3, and trunk. Have we agreed on how to treat > the build scripts for these four different versions? > > // Rickard > _______________________________________________ > Opendnssec-develop mailing list > Opendnssec-develop at lists.opendnssec.org > https://lists.opendnssec.org/mailman/listinfo/opendnssec-develop > _______________________________________________ > Opendnssec-develop mailing list > Opendnssec-develop at lists.opendnssec.org > https://lists.opendnssec.org/mailman/listinfo/opendnssec-develop --- jad at sinodun.com Sinodun Internet Technologies Ltd. Stables 4, Suite 11, Howbery Park, Wallingford, Oxfordshire, OX10 8BA, U.K. +44 (0)1491 834957 From owner-dnssec-trac at kirei.se Sun Oct 23 13:12:20 2011 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Sun, 23 Oct 2011 13:12:20 -0000 Subject: [Opendnssec-develop] [OpenDNSSEC] #263: Real Estate in The Oaks Club of Osprey Florida Message-ID: <047.fd785d84ee4dec9beeb67c751cbf0c4a@kirei.se> #263: Real Estate in The Oaks Club of Osprey Florida ----------------------+----------------------------------------------------- Reporter: wissybamg | Owner: alex Type: defect | Status: new Priority: blocker | Component: Auditor Version: trunk | ----------------------+----------------------------------------------------- Which leads me nether near my previous query. happened headed for dip! In today's artificial world therapist wrap is measured to be the height packaging data. In a position that all on your working party can entry anytime, from everywhere without the hassles of maintaining all the servers and databases yourself. However, this amount of the bid is and super simple. There are a extensive mixture of sources meant for this print of paraphernalia. Take registrations online, mail instinctive emails to be a result up and divide up reports digitally through a web association. You [http://www.dubaidingoes.com/DVD_BOX_SETS/BAYWATCH__INCLUDES_REUNION_MOVIE____THE_COMPLETE_TV_SERIES_ON_DVD baywatch ] also give birth to to to have toys similar structure blocks, puzzles, and that. Too often, estate and business succession planning is done with an eyeball for the tax and financial aspects only, ignoring the very important contact of family dynamics - maybe because minion asked the business owner exclusively what he or she wanted to happen. And in this container, you might bring to an end up opting for the cheapest company chastely because you want to prevent as much money as on the cards. (1 Quarter = 3 months)Accounts should constantly make a recording sacrifices and profits in the restaurant cost mass. By far away, Threadless has sent an paradigm so as to is laudable of subsequent. Many people then sorrow the need to sell, as the property with no going back represents what they in the beginning envisioned - but someone else gets the do good to of that rate and labour! If you don't do this you will find that many parents won't feel like to pay you for time that they undergo off, you may finish up with sick children at your home, or you may bottom up not human being paid on time every week. Then, when looking at the P2P manage, the first prosecution it took was to cut out guzzle the supplier vile massively. Here are a link of substance on the way to take into account. Even if this means more time off, bendable schedules, job allotment, teaching and other expenses that end a simple model: happiness. -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Sun Oct 23 16:10:38 2011 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Sun, 23 Oct 2011 16:10:38 -0000 Subject: [Opendnssec-develop] [OpenDNSSEC] #264: The Best Bond Fund - What Are the Best Bond Funds For 2010 & Beyond? Message-ID: <046.deeda0f8f6f5ebefd6c76bf85e446b25@kirei.se> #264: The Best Bond Fund - What Are the Best Bond Funds For 2010 & Beyond? ---------------------+------------------------------------------------------ Reporter: smyowybs | Owner: alex Type: defect | Status: new Priority: blocker | Component: Auditor Version: trunk | ---------------------+------------------------------------------------------ In other hand baggage, you may have to get in touch with some more people or they may dedicate you some cell phone number to phone up for more information. The equivalent is desired for your moment in time useless looking at your question. What are the data rudiments do you at this time have for each supplier and what events are needed to proactively accumulate the lingering data? Whether you're preliminary a in mint condition business or already in an conventional business, you need to realize the basics of workforce' compensation insurance. Again, for the duration of that stage I wrote - after that not anything to boot! Don't rely on mention cards - gloomy customers won't waste away their time inside them elsewhere. The co-op now Eureka CA is worsenhipg, as a result was individual I went to in Ventura CA. Criteria you would ponder:Sources of patron complaints. So, assent to's make the differing and focus our sales prospecting tricks resting on the A customers. Both Slatwall or Gridwall can certainly be alive cleaned with gentle filter (pursue guidelines! The region's chief airport is Southampton Airport, which besides has a rail situate accompanying it. Implementing the six systems of customer attraction, customer meeting, customer service, customer maintenance, side liability, and financial exposure will achieve this goal. I am staying at a less significant bar kindly of funky and cool inn at this point in San Francisco. They shaped moreover lived their fictional stories to shored [http://www.pin- nip.com/DVD_BOX_SETS/DANCING_WITH_THE_STARS___THE_COMPLETE_TV_SERIES_ON_DVD dancing with the stars season ] their egos, other than not their relationships. This strength look as if scary, but can be to a certain extent up-front. I appreciate, it sounds posh after that strenuous? -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Sun Oct 23 20:16:55 2011 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Sun, 23 Oct 2011 20:16:55 -0000 Subject: [Opendnssec-develop] [OpenDNSSEC] #265: Relocating to Palos Verdes and the South Bay Part 1 - The Beach Cities Message-ID: <054.534e44e1d4233703bc581de33e8cabf2@kirei.se> #265: Relocating to Palos Verdes and the South Bay Part 1 - The Beach Cities -----------------------------+---------------------------------------------- Reporter: stevenceuybppens | Owner: alex Type: defect | Status: new Priority: blocker | Component: Auditor Version: trunk | -----------------------------+---------------------------------------------- It can exhibit right where a business clue is in the sales development at any known time. Thousands of previous laborers are at the moment retraining pro responsibility jobs. Through this card system you can become more intense relationship with your to be had and new customers and spread around your storeroom or label conveniently. The focus of motion changes throughout the process from road sign cash, terminating contracts and limits on spending while trying to live in the emergency part is very different to funding marketing activities, new processes, training and other efficiency related initiatives during a stabilisation time. Running business involves keeping a spy on on competition as well as harmony the socio, economic and following natural world in which you are functioning and how these can have an effect on your business. To place it an added way, micro businesses on their own do not characterize sufficient profit for lenders to divide up with us. other than not a portion surprisingly! Is the scanner robust? The very fact that they are looking to get linked with Korean counterparts is a defensible qualifications of the attribute of sports car parts manufactured in Korea. If you possess a duplicate piece of equipment, manage copies of all instructions. Moreover, they are also available in large numbers so no matter how substantial an incident is you will have no intention to anxiety about the food. And fin vogueally, stay sensible in your high-quality. However, you be obliged to air comfortable in your clothing or your metaphors will radio show a stiff and unnatural stare. It is pretty genuine that the once a year discussion of a company will be attended by all and sundry in the company. Pelican manufactures belongings that are large enough to hem in computers and mobile tool boxes and small enough to carry a reminiscence card. Surprisingly, English was not completely as popular in the launch of this motherland's memoirs, as one might [http://www.hair-hair-hair.com thailand hair transplant] presume. Metaprograms: This is a method of analyzing how associates feel. Out-of-the-package approaches - many companies and organizations alike are establishment to pay more attention to "manageable skills", chiefly at older levels. ??? We'd approximating this delivered a week previously very last Monday wish. If you come about to run an online custom, you can wear and tear them for Dropshipping as brim. This is an of use manner headed for market your firm. Being capable to rent is also a major improvement if your business is serial or if you only need climate- proscribed containers for some projects and not for others. Any Venture capital safe expects a high rate of yield relation to the risk they are taking in financing your partnership on an equity basis - in fact traditionally, as the article acknowledged, the venture capitalists are looking for a 5 times return. NFO measures after that journey elsewhere. -- Ticket URL: OpenDNSSEC OpenDNSSEC From jad at sinodun.com Mon Oct 24 10:20:30 2011 From: jad at sinodun.com (John Dickinson) Date: Mon, 24 Oct 2011 11:20:30 +0100 Subject: [Opendnssec-develop] Supported build dependency for libraries etc In-Reply-To: <7683AD3C-BE6B-4B15-823C-5EABBE36ABE4@sinodun.com> References: <3DEC21FF-D942-49E7-8880-2BFC05963B6E@sinodun.com> <8379DE00FDBE1B4F95522D088EC260DD12B108@kambx2.SIDN.local> <7683AD3C-BE6B-4B15-823C-5EABBE36ABE4@sinodun.com> Message-ID: There is the following list of systems that we claim to have tested on https://wiki.opendnssec.org/display/ODSDOC140/Installation#Installation-Platformsupport Is this up to date? We don't have many of these in the build servers. (I could potentially supply them on my ESXi server.) John On 22 Oct 2011, at 19:05, John Dickinson wrote: > One other "dependancy" I have come across during my testing is building OpenDNSSEC with either sqlite3 or mysql. > > John > > On 18 Oct 2011, at 14:53, Nick van den Heuvel wrote: > >> --------------------------------------- >> The packages that are special for OpenDNSSEC are ldns and dnsruby. >> Botan for SoftHSM. I think it would be reasonable to just have the latest version installed in the test system, unless there are a major API change. You could have the argument that having old version helps us to detect if the developer has started to use new functions. But our main goal is to run the test scripts and our secondary goal is to see if the system builds. >> ---------------------------------------- >> Why not publish a list with the versions of supporting software which we used to test the release (attached to the release notes)? I do have some of these version included in my test report. >> >> >> >> --------------------------------------- >> We do also say that we support current version of OpenDNSSEC and the two previous minor releases. So currently we have to run the test system for 1.1, 1.2, 1.3, and trunk. Have we agreed on how to treat the build scripts for these four different versions? >> --------------------------------------- >> >> Not yet. Also depends on the patch released. >> >> Met vriendelijke groet, >> >> Nick van den Heuvel >> Test analist >> >> SIDN | Utrechtseweg 310 | 6802 EA | Postbus 5022 | 6802 EA | ARNHEM >> T +31 (0)26 352 55 93 | F +31 (0)26 352 55 05 | jabber: nick.vandenheuvel at jabber.sidn.nl >> nick.vandenheuvel at sidn.nl | www.sidn.nl >> >> >> SIDN heeft een nieuw domein! Vanaf 31 oktober zijn wij gevestigd op een nieuw adres: >> Meander 501, 6825 MD Arnhem. >> Het postadres en de telefoonnummers blijven ongewijzigd. >> >> SIDN has a new domain! From 31 October, our office address will be: >> Meander 501, 6825 MD Arnhem, The Netherlands. >> Our postal address and phone numbers remain unchanged. >> >> >> >> -----Original Message----- >> From: opendnssec-develop-bounces at lists.opendnssec.org [mailto:opendnssec-develop-bounces at lists.opendnssec.org] On Behalf Of Rickard Bellgrim >> Sent: dinsdag 18 oktober 2011 15:18 >> To: Jerry Lundstr?m >> Cc: opendnssec-develop at lists.opendnssec.org >> Subject: Re: [Opendnssec-develop] Supported build dependency for libraries etc >> >> To summarize this... >> >> We depend on packages that should be available in all distributions: >> sqlite, libxml2, (mysql) >> >> We have the build / configure specific packages like autoconf, >> automake, gcc, etc. Those should also be available in all >> distributions. >> >> The packages that are special for OpenDNSSEC are ldns and dnsruby. >> Botan for SoftHSM. I think it would be reasonable to just have the >> latest version installed in the test system, unless there are a major >> API change. You could have the argument that having old version helps >> us to detect if the developer has started to use new functions. But >> our main goal is to run the test scripts and our secondary goal is to >> see if the system builds. >> >> We do also say that we support current version of OpenDNSSEC and the >> two previous minor releases. So currently we have to run the test >> system for 1.1, 1.2, 1.3, and trunk. Have we agreed on how to treat >> the build scripts for these four different versions? >> >> // Rickard >> _______________________________________________ >> Opendnssec-develop mailing list >> Opendnssec-develop at lists.opendnssec.org >> https://lists.opendnssec.org/mailman/listinfo/opendnssec-develop >> _______________________________________________ >> Opendnssec-develop mailing list >> Opendnssec-develop at lists.opendnssec.org >> https://lists.opendnssec.org/mailman/listinfo/opendnssec-develop > > --- > jad at sinodun.com > Sinodun Internet Technologies Ltd. > Stables 4, Suite 11, > Howbery Park, > Wallingford, > Oxfordshire, > OX10 8BA, > U.K. > > +44 (0)1491 834957 > > _______________________________________________ > Opendnssec-develop mailing list > Opendnssec-develop at lists.opendnssec.org > https://lists.opendnssec.org/mailman/listinfo/opendnssec-develop --- jad at sinodun.com Sinodun Internet Technologies Ltd. Stables 4, Suite 11, Howbery Park, Wallingford, Oxfordshire, OX10 8BA, U.K. +44 (0)1491 834957 From jakob at kirei.se Mon Oct 24 10:50:50 2011 From: jakob at kirei.se (Jakob Schlyter) Date: Mon, 24 Oct 2011 12:50:50 +0200 Subject: [Opendnssec-develop] version-mania 2.0 Message-ID: Given the rather large change that the Enforcer NG will introduce, I suggest we call OpenDNSSEC with the new enforcer 2.0. Reasonable? jakob From sion at nominet.org.uk Mon Oct 24 11:35:23 2011 From: sion at nominet.org.uk (=?ISO-8859-1?Q?Si=F4n_Lloyd?=) Date: Mon, 24 Oct 2011 12:35:23 +0100 Subject: [Opendnssec-develop] Supported build dependency for libraries etc In-Reply-To: References: <3DEC21FF-D942-49E7-8880-2BFC05963B6E@sinodun.com> <8379DE00FDBE1B4F95522D088EC260DD12B108@kambx2.SIDN.local> <7683AD3C-BE6B-4B15-823C-5EABBE36ABE4@sinodun.com> Message-ID: <4EA54D7B.6000001@nominet.org.uk> On 24/10/11 11:20, John Dickinson wrote: > There is the following list of systems that we claim to have tested on > > https://wiki.opendnssec.org/display/ODSDOC140/Installation#Installation-Platformsupport > > Is this up to date? We don't have many of these in the build servers. (I could potentially supply them on my ESXi server.) Was there any response to the use of Solaris question sent to the users list? Sion From rick at openfortress.nl Mon Oct 24 12:08:53 2011 From: rick at openfortress.nl (Rick van Rein) Date: Mon, 24 Oct 2011 12:08:53 +0000 Subject: [Opendnssec-develop] version-mania 2.0 In-Reply-To: References: Message-ID: <20111024120853.GA2823@phantom.vanrein.org> Hi, > Given the rather large change that the Enforcer NG will introduce, I suggest we call OpenDNSSEC with the new enforcer 2.0. Reasonable? Makes sense to me. It also makes people embrace for possible changes in behaviour, which is warranted. -Rick From rickard at opendnssec.org Mon Oct 24 12:34:40 2011 From: rickard at opendnssec.org (Rickard Bellgrim) Date: Mon, 24 Oct 2011 14:34:40 +0200 Subject: [Opendnssec-develop] Supported build dependency for libraries etc In-Reply-To: References: <3DEC21FF-D942-49E7-8880-2BFC05963B6E@sinodun.com> <8379DE00FDBE1B4F95522D088EC260DD12B108@kambx2.SIDN.local> <7683AD3C-BE6B-4B15-823C-5EABBE36ABE4@sinodun.com> Message-ID: > There is the following list of systems that we claim to have tested on > > https://wiki.opendnssec.org/display/ODSDOC140/Installation#Installation-Platformsupport > > Is this up to date? We don't have many of these in the build servers. (I could potentially supply them on my ESXi server.) We decided this some year ago. It was some platforms that we had available within the project. We had to make sure that it worked on those platforms. // Rickard From rickard at opendnssec.org Mon Oct 24 12:35:58 2011 From: rickard at opendnssec.org (Rickard Bellgrim) Date: Mon, 24 Oct 2011 14:35:58 +0200 Subject: [Opendnssec-develop] Supported build dependency for libraries etc In-Reply-To: <4EA54D7B.6000001@nominet.org.uk> References: <3DEC21FF-D942-49E7-8880-2BFC05963B6E@sinodun.com> <8379DE00FDBE1B4F95522D088EC260DD12B108@kambx2.SIDN.local> <7683AD3C-BE6B-4B15-823C-5EABBE36ABE4@sinodun.com> <4EA54D7B.6000001@nominet.org.uk> Message-ID: > Was there any response to the use of Solaris question sent to the users > list? No response on the user's list. Maybe Jerry got a reply directly to him? // Rickard From rickard at opendnssec.org Mon Oct 24 12:38:13 2011 From: rickard at opendnssec.org (Rickard Bellgrim) Date: Mon, 24 Oct 2011 14:38:13 +0200 Subject: [Opendnssec-develop] version-mania 2.0 In-Reply-To: <20111024120853.GA2823@phantom.vanrein.org> References: <20111024120853.GA2823@phantom.vanrein.org> Message-ID: >> Given the rather large change that the Enforcer NG will introduce, I suggest we call OpenDNSSEC with the new enforcer 2.0. Reasonable? > > Makes sense to me. ?It also makes people embrace for > possible changes in behaviour, which is warranted. +1 From jerry at opendnssec.org Mon Oct 24 12:54:05 2011 From: jerry at opendnssec.org (Jerry =?ISO-8859-1?B?THVuZHN0cvZt?=) Date: Mon, 24 Oct 2011 14:54:05 +0200 Subject: [Opendnssec-develop] Supported build dependency for libraries etc In-Reply-To: Message-ID: On 2011-10-24 14.35, Rickard Bellgrim wrote: >No response on the user's list. Maybe Jerry got a reply directly to him? Nothing, but it hasn't been that long. /Jerry From jad at sinodun.com Mon Oct 24 13:08:59 2011 From: jad at sinodun.com (John Dickinson) Date: Mon, 24 Oct 2011 14:08:59 +0100 Subject: [Opendnssec-develop] Supported build dependency for libraries etc In-Reply-To: References: <3DEC21FF-D942-49E7-8880-2BFC05963B6E@sinodun.com> <8379DE00FDBE1B4F95522D088EC260DD12B108@kambx2.SIDN.local> <7683AD3C-BE6B-4B15-823C-5EABBE36ABE4@sinodun.com> Message-ID: <6EA8D47B-745F-49E2-8728-8B09C2537310@sinodun.com> On 24 Oct 2011, at 13:34, Rickard Bellgrim wrote: >> There is the following list of systems that we claim to have tested on >> >> https://wiki.opendnssec.org/display/ODSDOC140/Installation#Installation-Platformsupport >> >> Is this up to date? We don't have many of these in the build servers. (I could potentially supply them on my ESXi server.) > > We decided this some year ago. It was some platforms that we had > available within the project. We had to make sure that it worked on > those platforms. But should they be part of the jenkins test suite? I guess not all of them but some maybe? John > // Rickard --- jad at sinodun.com Sinodun Internet Technologies Ltd. Stables 4, Suite 11, Howbery Park, Wallingford, Oxfordshire, OX10 8BA, U.K. +44 (0)1491 834957 From rickard at opendnssec.org Mon Oct 24 13:20:46 2011 From: rickard at opendnssec.org (Rickard Bellgrim) Date: Mon, 24 Oct 2011 15:20:46 +0200 Subject: [Opendnssec-develop] Supported build dependency for libraries etc In-Reply-To: <6EA8D47B-745F-49E2-8728-8B09C2537310@sinodun.com> References: <3DEC21FF-D942-49E7-8880-2BFC05963B6E@sinodun.com> <8379DE00FDBE1B4F95522D088EC260DD12B108@kambx2.SIDN.local> <7683AD3C-BE6B-4B15-823C-5EABBE36ABE4@sinodun.com> <6EA8D47B-745F-49E2-8728-8B09C2537310@sinodun.com> Message-ID: >>> https://wiki.opendnssec.org/display/ODSDOC140/Installation#Installation-Platformsupport >>> >>> Is this up to date? We don't have many of these in the build servers. (I could potentially supply them on my ESXi server.) >> >> We decided this some year ago. It was some platforms that we had >> available within the project. We had to make sure that it worked on >> those platforms. > > But should they be part of the jenkins test suite? I guess not all of them but some ?maybe? So, yes, maybe we should change that list to reflect what we have in the build farm. // Rickard From owner-dnssec-trac at kirei.se Mon Oct 24 13:33:27 2011 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Mon, 24 Oct 2011 13:33:27 -0000 Subject: [Opendnssec-develop] =?utf-8?q?=5BOpenDNSSEC=5D_=23263=3A_Ubuntu?= =?utf-8?q?_pakkage_dpkgopendnssec-enforcer-mysql_broken_=C3=A2=5E=C3=88?= =?utf-8?b?XsOSbWFpbnRzY3JpcHTDol7DiF7DkmhlbHBlcg==?= Message-ID: <050.f87d69e20a1058133bf07b108e670c75@kirei.se> #263: Ubuntu pakkage dpkgopendnssec-enforcer-mysql broken ?^?^?maintscript?^?^?helper -------------------------+-------------------------------------------------- Reporter: bas@? | Owner: sion Type: defect | Status: new Priority: trivial | Component: Enforcer Version: 1.3.0 | Keywords: -------------------------+-------------------------------------------------- In the files opendnssec-enforcer-mysql.postinst opendnssec-enforcer-mysql.postrm opendnssec-enforcer-mysql.preinst it seems there has been used a wrong Carracter set. in the file it states "dpkg?^?^?maintscript?^?^?helper" it must be "dpkg- maintscript-helper" -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Mon Oct 24 13:35:37 2011 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Mon, 24 Oct 2011 13:35:37 -0000 Subject: [Opendnssec-develop] =?utf-8?b?UmU6IFtPcGVuRE5TU0VDXSAjMjYzOiBV?= =?utf-8?q?buntu_pakkage_dpkgopendnssec-enforcer-mysql_broken_=C3=A2=5E?= =?utf-8?b?w4hew5JtYWludHNjcmlwdMOiXsOIXsOSaGVscGVy?= In-Reply-To: <050.f87d69e20a1058133bf07b108e670c75@kirei.se> References: <050.f87d69e20a1058133bf07b108e670c75@kirei.se> Message-ID: <065.11c7cfda910911769565d2e68134a1c6@kirei.se> #263: Ubuntu pakkage dpkgopendnssec-enforcer-mysql broken ?^?^?maintscript?^?^?helper -------------------------+-------------------------------------------------- Reporter: bas@? | Owner: sion Type: defect | Status: new Priority: trivial | Component: Enforcer Version: 1.3.0 | Resolution: Keywords: | -------------------------+-------------------------------------------------- Comment (by bas@?): Can some please rebuild the deb files for ubuntu 10.04 64-bit -- Ticket URL: OpenDNSSEC OpenDNSSEC From yuri at NLnetLabs.nl Mon Oct 24 13:55:25 2011 From: yuri at NLnetLabs.nl (Yuri Schaeffer) Date: Mon, 24 Oct 2011 15:55:25 +0200 Subject: [Opendnssec-develop] version-mania 2.0 In-Reply-To: <20111024120853.GA2823@phantom.vanrein.org> References: <20111024120853.GA2823@phantom.vanrein.org> Message-ID: <4EA56E4D.8070905@nlnetlabs.nl> On 10/24/11 14:08, Rick van Rein wrote: > It also makes people embrace for > possible changes in behaviour, which is warranted. Good point. +1 However -not saying the enforcerNG is production ready- aren't there features that where 'promised' for 2.0 but potentially won't make it to that release? (I personally could not care less...) -- Yuri Schaeffer NLnet Labs http://www.nlnetlabs.nl From jerry at opendnssec.org Mon Oct 24 14:12:27 2011 From: jerry at opendnssec.org (Jerry =?ISO-8859-1?B?THVuZHN0cvZt?=) Date: Mon, 24 Oct 2011 16:12:27 +0200 Subject: [Opendnssec-develop] version-mania 2.0 In-Reply-To: <4EA56E4D.8070905@nlnetlabs.nl> Message-ID: On 2011-10-24 15.55, Yuri Schaeffer wrote: >On 10/24/11 14:08, Rick van Rein wrote: >> It also makes people embrace for >> possible changes in behaviour, which is warranted. > >Good point. +1 >However -not saying the enforcerNG is production ready- aren't there >features that where 'promised' for 2.0 but potentially won't make it to >that release? >(I personally could not care less...) It's funny how a jump in the major part of the version number makes people think its more special when it might really not be. There was some configure management system, I think, that jumped from 0.6 to 2.0 in one release last year just to make it more "production ready" and not to talk about the "omg a new major release"-Firefox. But anyway, the enforcer-ng things are a big change and indeed valid for a big push but the adapters are almost as big when regard to the features it brings. I think its time to revise the road map / release plan (which according to; we should already have released adapters). /Jerry From matthijs at NLnetLabs.nl Mon Oct 24 14:24:39 2011 From: matthijs at NLnetLabs.nl (Matthijs Mekking) Date: Mon, 24 Oct 2011 16:24:39 +0200 Subject: [Opendnssec-develop] version-mania 2.0 In-Reply-To: References: Message-ID: <4EA57527.9090902@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 10/24/2011 04:12 PM, Jerry Lundstr?m wrote: > On 2011-10-24 15.55, Yuri Schaeffer wrote: > >> On 10/24/11 14:08, Rick van Rein wrote: >>> It also makes people embrace for >>> possible changes in behaviour, which is warranted. >> >> Good point. +1 >> However -not saying the enforcerNG is production ready- aren't there >> features that where 'promised' for 2.0 but potentially won't make it to >> that release? >> (I personally could not care less...) > > It's funny how a jump in the major part of the version number makes people > think its more special when it might really not be. There was some > configure management system, I think, that jumped from 0.6 to 2.0 in one > release last year just to make it more "production ready" and not to talk > about the "omg a new major release"-Firefox. > > But anyway, the enforcer-ng things are a big change and indeed valid for a > big push but the adapters are almost as big when regard to the features it > brings. > > I think its time to revise the road map / release plan (which according > to; we should already have released adapters). Definitely. I think it is a good point to add to the Stockholm agenda. Matthijs > > /Jerry > > > _______________________________________________ > 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.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJOpXUmAAoJEA8yVCPsQCW59hcH/18QL9AkYxB3GjODOiXft2Kq h1/53p0dbk0O+ZImLrRLkBbz2NlIBUgo8N01Ab04JOzNvl+C75omhSK7qoY9xf59 tjAIjZg0ib0e/mPWjroRm/BYBwRXfhPlb6GlhmiocIQ5VT/jnv0r2VT13mmkLm9p BOKVeIhJdR6YzH8MwyDAIJes5NJ5vca4G0pG3BkJLGZYzIaI/n+3EsnH26Ew5viv kNyisKNdcsgkHirI+iB2paRDRBwiQ+DqQUi8J3Sqkwe9w1Q4yi2RMh1AMu+zCbYZ OFxsUw07PYW0aYF59/MdKAw27C/BYDAsgUxx928Zj3V64qxkG4bTnwIv21H2OQQ= =yOLW -----END PGP SIGNATURE----- From jakob at kirei.se Mon Oct 24 19:04:23 2011 From: jakob at kirei.se (Jakob Schlyter) Date: Mon, 24 Oct 2011 21:04:23 +0200 Subject: [Opendnssec-develop] Supported build dependency for libraries etc In-Reply-To: References: <3DEC21FF-D942-49E7-8880-2BFC05963B6E@sinodun.com> <8379DE00FDBE1B4F95522D088EC260DD12B108@kambx2.SIDN.local> <7683AD3C-BE6B-4B15-823C-5EABBE36ABE4@sinodun.com> <6EA8D47B-745F-49E2-8728-8B09C2537310@sinodun.com> Message-ID: <1FFE780B-E3F5-471A-AAC8-A2AE6B2F15BB@kirei.se> On 24 okt 2011, at 15:20, Rickard Bellgrim wrote: >>>> https://wiki.opendnssec.org/display/ODSDOC140/Installation#Installation-Platformsupport >>>> >>>> Is this up to date? We don't have many of these in the build servers. (I could potentially supply them on my ESXi server.) >>> >>> We decided this some year ago. It was some platforms that we had >>> available within the project. We had to make sure that it worked on >>> those platforms. >> >> But should they be part of the jenkins test suite? I guess not all of them but some maybe? > > So, yes, maybe we should change that list to reflect what we have in > the build farm. Or perhaps list what systems we do regression testing on, and what systems we intend to test from time to time? j From owner-dnssec-trac at kirei.se Mon Oct 24 23:27:40 2011 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Mon, 24 Oct 2011 23:27:40 -0000 Subject: [Opendnssec-develop] [OpenDNSSEC] #264: What Does A Buttonwood Tree Have To Do With the New York Stock Exchange? Message-ID: <048.ca1d66c58b112aad79ab5ed2f2c98386@kirei.se> #264: What Does A Buttonwood Tree Have To Do With the New York Stock Exchange? -----------------------+---------------------------------------------------- Reporter: lybordbyte | Owner: alex Type: defect | Status: new Priority: blocker | Component: Auditor Version: trunk | -----------------------+---------------------------------------------------- Aggressively amass rancid debts23. like confirmed before you have to have people on your players who tension about how the company is rising. If the guests are development in their own van, make really they have moral tips. Though this example outlay other truthful than a the same one, Merrill claims that Google enjoys productivity gains. The private is to put together your industry from the secret outdated. I aim, the sender probably did suffer you out someplace and belief you'd honestly want to receive their statistics. This company would not be a very fair range for a small business, if not that business has a lot of money to fritter and wishes something "Top of the Line". For you to gain instant managerial momentum you must get on in three ideologies:* You must have some egocentricity* You must keep in mind moments do not return* You must hold the issue and make an immediate change If you keep these in mind throughout the day your jumble will lead to order. The refer to of the Eastern financier at the rear the chart and the banker's own reputation insured confidence. ), contracts management (like-thinkered the size and scope and payment terms of the work to be performed ), change management (what happens if you change your be careful, or you are unnatural to change your mind by sudden circumstances). "We plan to abuse this new flexibility to multiply our competitive business," said Potter, "offering part discounts and enter into pricing. When a company elementary begins looking into the method of ERP implementation, their first examine is often in next of kin to how much the manner will cost. When selecting PPE, consider the [http://gregnieh.n7mm.org/ticket/31 amazing race] and intensity of the ardor and the form of splashes that may take place in the bureau. You receive as a result a lot en route for offer. Basically, there right doesn't look like to be an adequate amount time for the whole lot we need and aspire to do. Most emergencies aren't certainly emergencies. -- Ticket URL: OpenDNSSEC OpenDNSSEC From jad at sinodun.com Tue Oct 25 11:32:25 2011 From: jad at sinodun.com (John Dickinson) Date: Tue, 25 Oct 2011 12:32:25 +0100 Subject: [Opendnssec-develop] bugs Message-ID: <6C645BF1-2822-4A42-A6DA-24A2E1FFCD06@sinodun.com> Hi, I am doing some testing and finding the odd little bug (ksmutil usage output is incorrect). Is the new issues site up and running or could someone give me a higher level of access to pivotal tracker. Thanks John --- jad at sinodun.com Sinodun Internet Technologies Ltd. Stables 4, Suite 11, Howbery Park, Wallingford, Oxfordshire, OX10 8BA, U.K. +44 (0)1491 834957 From jakob at kirei.se Tue Oct 25 11:39:41 2011 From: jakob at kirei.se (Jakob Schlyter) Date: Tue, 25 Oct 2011 13:39:41 +0200 Subject: [Opendnssec-develop] bugs In-Reply-To: <6C645BF1-2822-4A42-A6DA-24A2E1FFCD06@sinodun.com> References: <6C645BF1-2822-4A42-A6DA-24A2E1FFCD06@sinodun.com> Message-ID: On 25 okt 2011, at 13:32, John Dickinson wrote: > I am doing some testing and finding the odd little bug (ksmutil usage output is incorrect). Is the new issues site up and running or could someone give me a higher level of access to pivotal tracker. Done. j From Roland.vanRijswijk at surfnet.nl Tue Oct 25 11:46:47 2011 From: Roland.vanRijswijk at surfnet.nl (Roland van Rijswijk) Date: Tue, 25 Oct 2011 13:46:47 +0200 Subject: [Opendnssec-develop] version-mania 2.0 In-Reply-To: References: Message-ID: <6AAF07C2-7744-4A3C-9EAC-3E473BFF0E8E@surfnet.nl> On 24 okt 2011, at 12:50, Jakob Schlyter wrote: > Given the rather large change that the Enforcer NG will introduce, I suggest we call OpenDNSSEC with the new enforcer 2.0. Reasonable? +1 This is major brain surgery going on :-) Cheers, Roland -- Roland M. van Rijswijk -- SURFnet Middleware Services -- t: +31-30-2305388 -- e: roland.vanrijswijk at surfnet.nl From owner-dnssec-trac at kirei.se Tue Oct 25 13:27:31 2011 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Tue, 25 Oct 2011 13:27:31 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #262: Possible race condition causing CPU-bound loop in signerd? In-Reply-To: <056.e2e409b68e66b5e253aa981539dcf486@kirei.se> References: <056.e2e409b68e66b5e253aa981539dcf486@kirei.se> Message-ID: <071.801229234ac1d7e85e7bf84262ceebfd@kirei.se> #262: Possible race condition causing CPU-bound loop in signerd? -------------------------------+-------------------------------------------- Reporter: goeran@? | Owner: matthijs Type: defect | Status: accepted Priority: major | Component: Signer Version: 1.3.0 | Resolution: Keywords: CPU-bound loop | -------------------------------+-------------------------------------------- Comment (by matthijs): Hi, I had the time to take a look at the strace. If I am correct, you have configured 8 worker threads and 2 signer threads. I see that all 8 threads are putting RRsets in the sign queue, so there are 8 zones in parallel being signed at the moment. The strace shows that 7 of them are waiting on a lock on q_lock, one of them is releasing the lock on q_lock. So probably, that is going alright. All 8 workers have a lock on zone_lock (zone_lock is different in all of these cases, because each zone has it's own zone_lock). The command handler has received an update command for the zone "chalmers.eu", so it requires the zone_lock for that zone. Probably, one of the workers currently has that zone_lock. The two drudger threads are sleeping. That is kind of strange. They should have get a broadcast signal as soon as the threshold of 1 queuing RRset has been reached: if (count == 0 && q->count == 1) { lock_basic_broadcast(&q->q_threshold); ods_log_deeebug("[%s] threshold %u reached, notify drudgers", fifoq_str, q->count); } Given this reasoning, my analysis is that the RRset queue is full, so the workers cannot queue the whole zone for signing. Because of that, they cannot finish their job and release their zone_lock. You notice, because a ods-signer update command is requiring a zone_lock that is being resigned at the moment. That is my best guess. If someone has any other insights, please provide them. In the meantime, I will investigate if and how this scenario is possible. -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Wed Oct 26 05:07:44 2011 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Wed, 26 Oct 2011 05:07:44 -0000 Subject: [Opendnssec-develop] [OpenDNSSEC] #264: Is Working From Home Right For You? Message-ID: <052.bd18577f08720b51ddcd29fa87f04ca5@kirei.se> #264: Is Working From Home Right For You? ---------------------------+------------------------------------------------ Reporter: corinabotoybiu | Owner: alex Type: defect | Status: new Priority: blocker | Component: Auditor Version: trunk | ---------------------------+------------------------------------------------ Therefore many broadly plug working and hang on for a buyer to befall beside. This is an important uncertainty to have over as choosing who you can rely unto with your marker draft is important. If you recognize them positively, that would survive prudent to perform. STALL ERASERSStanding Room OnlyAt times, personal methods are needed to help personnel cut into out of their inferior way of life. I started doing some examine and rendition every piece I could find about where to find work in non long- established spaces. Ftaking part ind available what your competitors are expenditure resting on media in the equivalent markets. Start as well as open to attractive stitch mean. Assuming you [http://bugs.syncleus.com/trac.cgi/sporkie/ticket/6215 in the heat of the night full episode] received an agenda in move forward, precisely consider what materials you should take with you, any information you have that would be important to the dialogue and make remarks of any points you might make at the seminar. Think: is it Business Appropriate? BELIEVE at home YOURSELF. Get en route for distinguish these publications - browse the bookstor elsees or your ballet company's collection. He recently wrote a chunk touting "junction" as the new CIO exhortation, a term that replaces the previous hum-song of "alignment. Hear also capture the memorandum. There is nothing shoddier than a website that is claiming to be management a money making business being irresponsible and not scheming the selling and supplying of products in as trained behavior as an offline business. Well, becaspend they use these tools to learning with, to inquiries with, to mix with and they are a quantity of their everyday lives. Factoring, bill of lading factoring, or the books receivable financing means selling your company's invoices at a disregard to a finance company for pressing headquarters. Incidentally, I did have a business plan (for my Integrated Fish Farm) startup that I took weeks to meticulously practice, going out to research a variety of aspects, and getting guidelines from banks towards securing evenhandedness investment under the insignificant Medium Enterprises Investment Scheme(SMEIS). -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Wed Oct 26 05:20:54 2011 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Wed, 26 Oct 2011 05:20:54 -0000 Subject: [Opendnssec-develop] [OpenDNSSEC] #265: Five Things You Can Do to Ensure You Provide Great Customer Service Message-ID: <046.61e97fd1334ed9c6887c6823b08e65fd@kirei.se> #265: Five Things You Can Do to Ensure You Provide Great Customer Service ---------------------+------------------------------------------------------ Reporter: sanybdst | Owner: alex Type: defect | Status: new Priority: blocker | Component: Auditor Version: trunk | ---------------------+------------------------------------------------------ When we shrink being paid cheery in days our eyesight is not as decent as it was when we were twenty. These artists and the employment [http://trac.mi.fu-berlin.de/viper/newticket in the heat of the night season 1 complete] their verbalization talents are ever-present in many unlike facets of our day after day lives. But, I sincerely didn't hardship somebody on the way to say to me. Where it becomes difficult is when you are costs a assortment of time on these odd jobs and not getting enough clients to hire someone to make easier. __ Are you serene along with citizens starting supplementary cultures? Have you all the time dreamed of opening your own home business but lacked the nerve to crack and assemble it a actuality? This truly makes the lot safer designed for in cooperation you and the supplier you hire. Whenever you obtain an email on your corporate email ma??tre d', your mails are unthinkingly pressed to your mobile gadget even if you are not in office. " The ownership has requested this review to spot problem areas in peacefulness to start and proceedings plan for 2004. What muscle. The PCI is requiring enterprises that want to last compliant credit card to downgrade the danger of exposure of credit card and financial data. UCC filings linger functioning for a lowest amount of five days, but they can be extensive. Remember as these strategies develop in your sense each month, I never said it would be easy, however I am saying, it "can" be done with help AND velocity with the properly energy going in the right government. Whilst these may bear out not to be classic in any true sense as an "approved" ability as the designation of a TA they do give a good idea of the notion behind such an organisation. Here is an case in point urge statement:"majestic 28, 2010 - Seattle, WA - Wyyzzk, Inc. In additive many of the ample hard disk encryption products provide a way to improve access by using an offline Challenge-Response system. -- Ticket URL: OpenDNSSEC OpenDNSSEC From nick.vandenheuvel at sidn.nl Thu Oct 27 08:13:06 2011 From: nick.vandenheuvel at sidn.nl (Nick van den Heuvel) Date: Thu, 27 Oct 2011 08:13:06 +0000 Subject: [Opendnssec-develop] version-mania 2.0 In-Reply-To: References: <20111024120853.GA2823@phantom.vanrein.org> Message-ID: <8379DE00FDBE1B4F95522D088EC260DD140F1F@kambx2.SIDN.local> +1 Met vriendelijke groet, Nick van den Heuvel Test analist SIDN | Utrechtseweg 310 | 6802 EA | Postbus 5022 | 6802 EA | ARNHEM T +31 (0)26 352 55 93 | F +31 (0)26 352 55 05 | jabber: nick.vandenheuvel at jabber.sidn.nl nick.vandenheuvel at sidn.nl | www.sidn.nl SIDN heeft een nieuw domein! Vanaf 31 oktober zijn wij gevestigd op een nieuw adres: Meander 501, 6825 MD Arnhem. Het postadres en de telefoonnummers blijven ongewijzigd. SIDN has a new domain! From 31 October, our office address will be: Meander 501, 6825 MD Arnhem, The Netherlands. Our postal address and phone numbers remain unchanged. -----Original Message----- From: opendnssec-develop-bounces at lists.opendnssec.org [mailto:opendnssec-develop-bounces at lists.opendnssec.org] On Behalf Of Rickard Bellgrim Sent: maandag 24 oktober 2011 14:38 To: Rick van Rein Cc: opendnssec-develop at lists.opendnssec.org Subject: Re: [Opendnssec-develop] version-mania 2.0 >> Given the rather large change that the Enforcer NG will introduce, I suggest we call OpenDNSSEC with the new enforcer 2.0. Reasonable? > > Makes sense to me. ?It also makes people embrace for > possible changes in behaviour, which is warranted. +1 _______________________________________________ Opendnssec-develop mailing list Opendnssec-develop at lists.opendnssec.org https://lists.opendnssec.org/mailman/listinfo/opendnssec-develop From Roland.vanRijswijk at surfnet.nl Thu Oct 27 11:00:11 2011 From: Roland.vanRijswijk at surfnet.nl (Roland van Rijswijk) Date: Thu, 27 Oct 2011 13:00:11 +0200 Subject: [Opendnssec-develop] Enforcer NG telecon today at 14:00h CEST Message-ID: Hi guys, We have an Enforcer NG telecon scheduled for today at 14:00h CEST, here are the conference details: Dial-in to +31-30-2040323 Conference PIN: 030003 Here is the suggested agenda: - Feedback on the alpha - State of development - Testing - AOB Cheers, Roland -- Roland M. van Rijswijk -- SURFnet Middleware Services -- t: +31-30-2305388 -- e: roland.vanrijswijk at surfnet.nl From Roland.vanRijswijk at surfnet.nl Thu Oct 27 12:50:22 2011 From: Roland.vanRijswijk at surfnet.nl (Roland van Rijswijk) Date: Thu, 27 Oct 2011 14:50:22 +0200 Subject: [Opendnssec-develop] 2011-10-27 Enforcer NG telecon meeting minutes Message-ID: Hi all, You can find today's Enforcer NG telecon minutes on the Wiki: https://wiki.opendnssec.org/display/OpenDNSSEC/2011-10-27+Enforcer+NG+-+Minutes Special note to Yuri: you have been assigned an action item ;-) Cheers, Roland -- Roland M. van Rijswijk -- SURFnet Middleware Services -- t: +31-30-2305388 -- e: roland.vanrijswijk at surfnet.nl From jerry at opendnssec.org Thu Oct 27 14:06:25 2011 From: jerry at opendnssec.org (Jerry =?ISO-8859-1?B?THVuZHN0cvZt?=) Date: Thu, 27 Oct 2011 16:06:25 +0200 Subject: [Opendnssec-develop] Moving to JIRA next week In-Reply-To: <50F57EA4-4BFA-47E0-A061-473FAF6522A9@kirei.se> Message-ID: So I have mostly finished setting up JIRA but ran into a snag with the pivotal importer, that just got fixed, so its taken a while. Hopefully we can start using it next week. /Jerry From owner-dnssec-trac at kirei.se Fri Oct 28 10:00:04 2011 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Fri, 28 Oct 2011 10:00:04 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #262: Possible race condition causing CPU-bound loop in signerd? In-Reply-To: <056.e2e409b68e66b5e253aa981539dcf486@kirei.se> References: <056.e2e409b68e66b5e253aa981539dcf486@kirei.se> Message-ID: <071.1a56e1f49ebc562b8f5d2ba606f5f47d@kirei.se> #262: Possible race condition causing CPU-bound loop in signerd? -------------------------------+-------------------------------------------- Reporter: goeran@? | Owner: matthijs Type: defect | Status: accepted Priority: major | Component: Signer Version: 1.3.0 | Resolution: Keywords: CPU-bound loop | -------------------------------+-------------------------------------------- Comment (by matthijs): Hi, In the OpenDNSSEC-1.3 branch, revision 5821, I have added a mechanism that sends out an additional broadcast message to the drudgers, if the queue is full, but no items are removed anymore. http://trac.opendnssec.org/changeset/5821/branches/OpenDNSSEC-1.3/signer/src Could you try that patch? -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Fri Oct 28 12:33:03 2011 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Fri, 28 Oct 2011 12:33:03 -0000 Subject: [Opendnssec-develop] [OpenDNSSEC] #264: general contractors miami fl Message-ID: <047.8e0d917f72c66aa7917fff33b5539c89@kirei.se> #264: general contractors miami fl ----------------------+----------------------------------------------------- Reporter: anonymous | Owner: matthijs Type: defect | Status: new Priority: major | Component: Signer Version: 1.2.0 | Keywords: general contractors miami fl ----------------------+----------------------------------------------------- [http://leo-roofing-contractors.com south florida roofers] Do you have a spam problem on this website; I also am a blogger, and I was curious about your situation; we have created some nice methods and we are looking to trade methods with others, why not shoot me an email if interested. -- Ticket URL: OpenDNSSEC OpenDNSSEC From goeran at chalmers.se Fri Oct 28 14:28:44 2011 From: goeran at chalmers.se (=?ISO-8859-1?Q?G=F6ran_Bengtson?=) Date: Fri, 28 Oct 2011 16:28:44 +0200 (CEST) Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #262: Possible race condition causing CPU-bound loop in signerd? In-Reply-To: <071.1a56e1f49ebc562b8f5d2ba606f5f47d@kirei.se> References: <056.e2e409b68e66b5e253aa981539dcf486@kirei.se> <071.1a56e1f49ebc562b8f5d2ba606f5f47d@kirei.se> Message-ID: On Fri, 28 Oct 2011, OpenDNSSEC wrote: > From: OpenDNSSEC > Cc: "opendnssec-develop at lists.opendnssec.org" > > Message-ID: <071.1a56e1f49ebc562b8f5d2ba606f5f47d at kirei.se> > Date: Fri, 28 Oct 2011 12:00:04 +0200 > Subject: Re: [OpenDNSSEC] #262: Possible race condition causing CPU-bound loop > in signerd? > > #262: Possible race condition causing CPU-bound loop in signerd? > -------------------------------+-------------------------------------------- > Reporter: goeran@? | Owner: matthijs > Type: defect | Status: accepted > Priority: major | Component: Signer > Version: 1.3.0 | Resolution: > Keywords: CPU-bound loop | > -------------------------------+-------------------------------------------- > > Comment (by matthijs): > > Hi, > > In the OpenDNSSEC-1.3 branch, revision 5821, I have added a mechanism that > sends out an additional broadcast message to the drudgers, if the queue is > full, but no items are removed anymore. > > http://trac.opendnssec.org/changeset/5821/branches/OpenDNSSEC-1.3/signer/src > > Could you try that patch? I've installed the 5821 revision from the OpenDNSSEC-1.3 branch (or should I use 1.3.2 release with only this patch?). Comment below: I must add that since my last input in this case, ODS has been running without problem since October 4th. Rev. 5664 from the 1.3-branch. That the problem comes and goes with irregular intervals has always been the case. We did one small change in the environment on October 4th. We changed the NTPconfig to disallow time to step. The system is a VMWare guest so the "load-balancer" in VMware (DRS) may move the guest from one host to another, an operation that is "almost" transparent to the guest, but the clock often drops some fraction of a second causing ntp with to original config to step the clock 0.1s or so. However, we don't think this was the cause since logs indicate that the VMware load-balancer started to move the guest after it got stuck in the CPU-loop. I've now change the ntp config back to its previous version. More interesting is that after starting the Rev. 5821 code a ods-signer sign --all entries in the log (attached below) indicate that your added code actually was triggered.... / G?ran Bengtson ITService N?t Chalmers > > -- > Ticket URL: > OpenDNSSEC > OpenDNSSEC log file after restart with the new code: Oct 28 15:59:51 ns-test ods-enforcerd: HSM opened successfully. Oct 28 15:59:51 ns-test ods-enforcerd: Reading config "/usr/local/etc/opendnssec/conf.xml" Oct 28 15:59:51 ns-test ods-enforcerd: Reading config schema "/usr/local/share/opendnssec/conf.rng" Oct 28 15:59:51 ns-test ods-enforcerd: Communication Interval: 3600 Oct 28 15:59:51 ns-test ods-enforcerd: Using command: /usr/local/bin/ds-submit to submit DS records Oct 28 15:59:51 ns-test ods-enforcerd: SQLite database set to: /var/opendnssec/kasp.db Oct 28 15:59:51 ns-test ods-enforcerd: Log User set to: local4 Oct 28 15:59:51 ns-test ods-enforcerd: Switched log facility to: local4 Oct 28 15:59:51 ns-test ods-enforcerd: Connecting to Database... Oct 28 15:59:51 ns-test ods-enforcerd: Policy default found. Oct 28 15:59:51 ns-test ods-enforcerd: Key sharing is Off. Oct 28 15:59:51 ns-test ods-enforcerd: Purging keys... Oct 28 15:59:51 ns-test ods-enforcerd: Policy itsnat found. Oct 28 15:59:51 ns-test ods-enforcerd: Key sharing is Off. Oct 28 15:59:51 ns-test ods-enforcerd: Purging keys... Oct 28 15:59:51 ns-test ods-enforcerd: Policy csnet found. Oct 28 15:59:51 ns-test ods-enforcerd: Key sharing is Off. Oct 28 15:59:51 ns-test ods-enforcerd: Purging keys... Oct 28 15:59:51 ns-test ods-enforcerd: zonelist filename set to /usr/local/etc/opendnssec/zonelist.xml. Oct 28 15:59:51 ns-test ods-enforcerd: Zone itsnat.se found. Oct 28 15:59:51 ns-test ods-enforcerd: Policy for itsnat.se set to itsnat. Oct 28 15:59:51 ns-test ods-enforcerd: Policy itsnat found in DB. Oct 28 15:59:51 ns-test ods-enforcerd: Config will be output to /var/opendnssec/signconf/itsnat.se.xml. Oct 28 15:59:51 ns-test ods-enforcerd: No change to: /var/opendnssec/signconf/itsnat.se.xml Oct 28 15:59:51 ns-test ods-enforcerd: Zone chalmers.se found. Oct 28 15:59:51 ns-test ods-enforcerd: Policy for chalmers.se set to default. Oct 28 15:59:51 ns-test ods-enforcerd: Policy default found in DB. Oct 28 15:59:51 ns-test ods-enforcerd: Config will be output to /var/opendnssec/signconf/chalmers.se.xml. Oct 28 15:59:51 ns-test ods-enforcerd: No change to: /var/opendnssec/signconf/chalmers.se.xml Oct 28 15:59:51 ns-test ods-enforcerd: Zone chalmers.eu found. Oct 28 15:59:51 ns-test ods-enforcerd: Policy for chalmers.eu set to default. Oct 28 15:59:51 ns-test ods-enforcerd: Config will be output to /var/opendnssec/signconf/chalmers.eu.xml. Oct 28 15:59:51 ns-test ods-enforcerd: No change to: /var/opendnssec/signconf/chalmers.eu.xml Oct 28 15:59:51 ns-test ods-enforcerd: Zone 16.129.in-addr.arpa found. Oct 28 15:59:51 ns-test ods-enforcerd: Policy for 16.129.in-addr.arpa set to default. Oct 28 15:59:51 ns-test ods-enforcerd: Config will be output to /var/opendnssec/signconf/16.129.in-addr.arpa.xml. Oct 28 15:59:51 ns-test ods-enforcerd: No change to: /var/opendnssec/signconf/16.129.in-addr.arpa.xml Oct 28 15:59:51 ns-test ods-enforcerd: Zone 50.5.192.in-addr.arpa found. Oct 28 15:59:51 ns-test ods-enforcerd: Policy for 50.5.192.in-addr.arpa set to csnet. Oct 28 15:59:51 ns-test ods-enforcerd: Policy csnet found in DB. Oct 28 15:59:51 ns-test ods-enforcerd: Config will be output to /var/opendnssec/signconf/50.5.192.in-addr.arpa.xml. Oct 28 15:59:51 ns-test ods-enforcerd: No change to: /var/opendnssec/signconf/50.5.192.in-addr.arpa.xml Oct 28 15:59:51 ns-test ods-enforcerd: Zone gbg.sunet.se found. Oct 28 15:59:51 ns-test ods-enforcerd: Policy for gbg.sunet.se set to default. Oct 28 15:59:51 ns-test ods-enforcerd: Policy default found in DB. Oct 28 15:59:51 ns-test ods-enforcerd: Config will be output to /var/opendnssec/signconf/gbg.sunet.se.xml. Oct 28 15:59:51 ns-test ods-enforcerd: No change to: /var/opendnssec/signconf/gbg.sunet.se.xml Oct 28 15:59:51 ns-test ods-enforcerd: Zone 2.0.0.0.0.b.6.0.1.0.0.2.ip6.arpa found. Oct 28 15:59:51 ns-test ods-enforcerd: Policy for 2.0.0.0.0.b.6.0.1.0.0.2.ip6.arpa set to default. Oct 28 15:59:51 ns-test ods-enforcerd: Config will be output to /var/opendnssec/signconf/2.0.0.0.0.b.6.0.1.0.0.2.ip6.arpa.xml. Oct 28 15:59:51 ns-test ods-enforcerd: No change to: /var/opendnssec/signconf/2.0.0.0.0.b.6.0.1.0.0.2.ip6.arpa.xml Oct 28 15:59:51 ns-test ods-enforcerd: Zone 224.36.192.in-addr.arpa found. Oct 28 15:59:51 ns-test ods-enforcerd: Policy for 224.36.192.in-addr.arpa set to default. Oct 28 15:59:51 ns-test ods-enforcerd: Config will be output to /var/opendnssec/signconf/224.36.192.in-addr.arpa.xml. Oct 28 15:59:51 ns-test ods-enforcerd: No change to: /var/opendnssec/signconf/224.36.192.in-addr.arpa.xml Oct 28 15:59:51 ns-test ods-enforcerd: Zone 225.36.192.in-addr.arpa found. Oct 28 15:59:51 ns-test ods-enforcerd: Policy for 225.36.192.in-addr.arpa set to default. Oct 28 15:59:51 ns-test ods-enforcerd: Config will be output to /var/opendnssec/signconf/225.36.192.in-addr.arpa.xml. Oct 28 15:59:51 ns-test ods-enforcerd: No change to: /var/opendnssec/signconf/225.36.192.in-addr.arpa.xml Oct 28 15:59:51 ns-test ods-enforcerd: Zone 120.36.192.in-addr.arpa found. Oct 28 15:59:51 ns-test ods-enforcerd: Policy for 120.36.192.in-addr.arpa set to default. Oct 28 15:59:51 ns-test ods-enforcerd: Config will be output to /var/opendnssec/signconf/120.36.192.in-addr.arpa.xml. Oct 28 15:59:51 ns-test ods-enforcerd: No change to: /var/opendnssec/signconf/120.36.192.in-addr.arpa.xml Oct 28 15:59:51 ns-test ods-enforcerd: Disconnecting from Database... Oct 28 15:59:51 ns-test ods-enforcerd: Sleeping for 3600 seconds. Oct 28 15:59:52 ns-test ods-signerd: zone fetcher started Oct 28 15:59:52 ns-test ods-signerd: [engine] signer started Oct 28 15:59:52 ns-test ods-signerd: zone fetcher zone itsnat.se is already up to date, serial is 2011102805 Oct 28 15:59:52 ns-test ods-signerd: zone fetcher zone chalmers.se is already up to date, serial is 2011102805 Oct 28 15:59:52 ns-test ods-signerd: zone fetcher zone chalmers.eu is already up to date, serial is 2011063005 Oct 28 15:59:52 ns-test ods-signerd: zone fetcher zone 16.129.in-addr.arpa is already up to date, serial is 2011102805 Oct 28 15:59:52 ns-test ods-signerd: zone fetcher zone 50.5.192.in-addr.arpa is already up to date, serial is 2011070712 Oct 28 15:59:52 ns-test ods-signerd: zone fetcher zone gbg.sunet.se is already up to date, serial is 2011051814 Oct 28 15:59:52 ns-test ods-signerd: zone fetcher zone 2.0.0.0.0.b.6.0.1.0.0.2.ip6.arpa is already up to date, serial is 2011101801 Oct 28 15:59:52 ns-test ods-signerd: zone fetcher zone 224.36.192.in-addr.arpa is already up to date, serial is 2011051814 Oct 28 15:59:52 ns-test ods-signerd: zone fetcher zone 225.36.192.in-addr.arpa is already up to date, serial is 2011051814 Oct 28 15:59:52 ns-test ods-signerd: zone fetcher zone 120.36.192.in-addr.arpa is already up to date, serial is 2011071301 Oct 28 16:00:14 ns-test ods-auditor[7556]: Auditor started Oct 28 16:00:14 ns-test ods-auditor[7556]: Auditor starting on 50.5.192.in-addr.arpa Oct 28 16:00:14 ns-test ods-auditor[7556]: Auditing 50.5.192.in-addr.arpa zone : NSEC3 SIGNED Oct 28 16:00:47 ns-test ods-auditor[7556]: SOA differs : from 2011070712 to 2011102815 Oct 28 16:00:48 ns-test ods-auditor[7556]: Finished auditing 50.5.192.in-addr.arpa zone Oct 28 16:00:48 ns-test my-reload[7572]: Start processing 50.5.192.in-addr.arpa Oct 28 16:00:48 ns-test my-reload[7572]: End processing 50.5.192.in-addr.arpa Oct 28 16:00:48 ns-test ods-signerd: [STATS] 50.5.192.in-addr.arpa RR[count=0 time=0(sec)] NSEC3[count=0 time=0(sec)] RRSIG[new=7 reused=511 time=0(sec) avg=0(sig/sec)] AUDIT[time=34(sec)] TOTAL[time=34(sec)] Oct 28 16:02:39 ns-test ods-auditor[7602]: Auditor started Oct 28 16:02:39 ns-test ods-auditor[7602]: Auditor starting on 225.36.192.in-addr.arpa Oct 28 16:02:39 ns-test ods-auditor[7602]: Auditing 225.36.192.in-addr.arpa zone : NSEC3 SIGNED Oct 28 16:03:12 ns-test ods-auditor[7602]: SOA differs : from 2011051814 to 2011102815 Oct 28 16:03:12 ns-test ods-auditor[7602]: Finished auditing 225.36.192.in-addr.arpa zone Oct 28 16:03:12 ns-test my-reload[7612]: Start processing 225.36.192.in-addr.arpa Oct 28 16:03:12 ns-test my-reload[7612]: End processing 225.36.192.in-addr.arpa Oct 28 16:03:12 ns-test ods-signerd: [STATS] 225.36.192.in-addr.arpa RR[count=0 time=0(sec)] NSEC3[count=0 time=0(sec)] RRSIG[new=2 reused=515 time=0(sec) avg=0(sig/sec)] AUDIT[time=33(sec)] TOTAL[time=33(sec)] Oct 28 16:06:19 ns-test ods-auditor[7640]: Auditor started Oct 28 16:06:19 ns-test ods-auditor[7640]: Auditor starting on 224.36.192.in-addr.arpa Oct 28 16:06:19 ns-test ods-auditor[7640]: Auditing 224.36.192.in-addr.arpa zone : NSEC3 SIGNED Oct 28 16:06:20 ns-test ods-auditor[7642]: Auditor started Oct 28 16:06:22 ns-test ods-signerd: [fifo] max cap reached, but drudgers seem to be on hold, notify drudgers again Oct 28 16:06:24 ns-test last message repeated 32208 times Oct 28 16:06:24 ns-test ods-auditor[7644]: Auditor started Oct 28 16:06:24 ns-test ods-signerd: [fifo] max cap reached, but drudgers seem to be on hold, notify drudgers again Oct 28 16:06:24 ns-test last message repeated 11316 times Oct 28 16:06:24 ns-test ods-auditor[7651]: Auditor started Oct 28 16:06:24 ns-test ods-signerd: [fifo] max cap reached, but drudgers seem to be on hold, notify drudgers again Oct 28 16:06:24 ns-test last message repeated 13 times Oct 28 16:06:24 ns-test ods-auditor[7644]: Auditor starting on 120.36.192.in-addr.arpa Oct 28 16:06:24 ns-test ods-signerd: [fifo] max cap reached, but drudgers seem to be on hold, notify drudgers again Oct 28 16:06:24 ns-test last message repeated 13 times Oct 28 16:06:24 ns-test ods-auditor[7644]: Auditing 120.36.192.in-addr.arpa zone : NSEC3 SIGNED Oct 28 16:06:24 ns-test ods-signerd: [fifo] max cap reached, but drudgers seem to be on hold, notify drudgers again Oct 28 16:06:25 ns-test last message repeated 11558 times Oct 28 16:06:24 ns-test ods-auditor[7646]: Auditor started Oct 28 16:06:25 ns-test ods-signerd: [fifo] max cap reached, but drudgers seem to be on hold, notify drudgers again Oct 28 16:06:25 ns-test last message repeated 4986 times Oct 28 16:06:25 ns-test ods-auditor[7646]: Auditor starting on gbg.sunet.se Oct 28 16:06:25 ns-test ods-signerd: [fifo] max cap reached, but drudgers seem to be on hold, notify drudgers again Oct 28 16:06:25 ns-test last message repeated 15 times Oct 28 16:06:25 ns-test ods-auditor[7646]: Auditing gbg.sunet.se zone : NSEC3 SIGNED Oct 28 16:06:25 ns-test ods-signerd: [fifo] max cap reached, but drudgers seem to be on hold, notify drudgers again Oct 28 16:06:26 ns-test last message repeated 2376 times Oct 28 16:06:26 ns-test ods-auditor[7651]: Auditor starting on 2.0.0.0.0.b.6.0.1.0.0.2.ip6.arpa Oct 28 16:06:26 ns-test ods-signerd: [fifo] max cap reached, but drudgers seem to be on hold, notify drudgers again Oct 28 16:06:26 ns-test last message repeated 78 times Oct 28 16:06:26 ns-test ods-auditor[7646]: SOA differs : from 2011051814 to 2011102801 Oct 28 16:06:26 ns-test ods-signerd: [fifo] max cap reached, but drudgers seem to be on hold, notify drudgers again Oct 28 16:06:26 ns-test last message repeated 993 times Oct 28 16:06:26 ns-test ods-auditor[7651]: Auditing 2.0.0.0.0.b.6.0.1.0.0.2.ip6.arpa zone : NSEC3 SIGNED Oct 28 16:06:26 ns-test ods-signerd: [fifo] max cap reached, but drudgers seem to be on hold, notify drudgers again Oct 28 16:06:26 ns-test last message repeated 2935 times Oct 28 16:06:26 ns-test ods-auditor[7646]: Finished auditing gbg.sunet.se zone Oct 28 16:06:26 ns-test ods-signerd: [fifo] max cap reached, but drudgers seem to be on hold, notify drudgers again Oct 28 16:06:26 ns-test last message repeated 7910 times Oct 28 16:06:26 ns-test ods-auditor[7642]: Auditor starting on chalmers.eu Oct 28 16:06:26 ns-test ods-signerd: [fifo] max cap reached, but drudgers seem to be on hold, notify drudgers again Oct 28 16:06:26 ns-test last message repeated 13 times Oct 28 16:06:26 ns-test ods-auditor[7642]: Auditing chalmers.eu zone : NSEC3 SIGNED Oct 28 16:06:26 ns-test ods-signerd: [fifo] max cap reached, but drudgers seem to be on hold, notify drudgers again Oct 28 16:06:27 ns-test last message repeated 22362 times Oct 28 16:06:27 ns-test ods-auditor[7642]: SOA differs : from 2011063005 to 2011102801 Oct 28 16:06:27 ns-test ods-signerd: [fifo] max cap reached, but drudgers seem to be on hold, notify drudgers again Oct 28 16:06:27 ns-test last message repeated 1371 times Oct 28 16:06:27 ns-test ods-auditor[7642]: Finished auditing chalmers.eu zone Oct 28 16:06:27 ns-test ods-signerd: [fifo] max cap reached, but drudgers seem to be on hold, notify drudgers again Oct 28 16:06:28 ns-test last message repeated 222 times Oct 28 16:06:28 ns-test my-reload[7676]: Start processing chalmers.eu Oct 28 16:06:28 ns-test ods-signerd: [fifo] max cap reached, but drudgers seem to be on hold, notify drudgers again Oct 28 16:06:29 ns-test last message repeated 9290 times Oct 28 16:06:29 ns-test ods-auditor[7644]: SOA differs : from 2011071301 to 2011102803 Oct 28 16:06:29 ns-test ods-signerd: [fifo] max cap reached, but drudgers seem to be on hold, notify drudgers again Oct 28 16:06:29 ns-test last message repeated 133 times Oct 28 16:06:30 ns-test ods-auditor[7644]: Finished auditing 120.36.192.in-addr.arpa zone Oct 28 16:06:30 ns-test my-reload[7692]: Start processing gbg.sunet.se Oct 28 16:06:30 ns-test ods-auditor[7701]: Auditor started Oct 28 16:06:30 ns-test my-reload[7676]: End processing chalmers.eu Oct 28 16:06:30 ns-test ods-signerd: [STATS] chalmers.eu RR[count=10 time=0(sec)] NSEC3[count=0 time=0(sec)] RRSIG[new=1 reused=8 time=0(sec) avg=0(sig/sec)] AUDIT[time=8(sec)] TOTAL[time=11(sec)] Oct 28 16:06:30 ns-test my-reload[7709]: Start processing 120.36.192.in-addr.arpa Oct 28 16:06:31 ns-test ods-auditor[7701]: Auditor starting on itsnat.se Oct 28 16:06:31 ns-test ods-auditor[7701]: Auditing itsnat.se zone : NSEC3 SIGNED Oct 28 16:06:31 ns-test ods-auditor[7745]: Auditor started Oct 28 16:06:31 ns-test ods-auditor[7745]: Auditor starting on 50.5.192.in-addr.arpa Oct 28 16:06:31 ns-test ods-auditor[7745]: Auditing 50.5.192.in-addr.arpa zone : NSEC3 SIGNED Oct 28 16:06:34 ns-test my-reload[7692]: End processing gbg.sunet.se Oct 28 16:06:34 ns-test ods-signerd: [STATS] gbg.sunet.se RR[count=14 time=0(sec)] NSEC3[count=0 time=0(sec)] RRSIG[new=1 reused=12 time=0(sec) avg=0(sig/sec)] AUDIT[time=8(sec)] TOTAL[time=15(sec)] Oct 28 16:06:34 ns-test my-reload[7709]: End processing 120.36.192.in-addr.arpa Oct 28 16:06:34 ns-test ods-signerd: [STATS] 120.36.192.in-addr.arpa RR[count=15 time=0(sec)] NSEC3[count=0 time=0(sec)] RRSIG[new=1 reused=22 time=0(sec) avg=0(sig/sec)] AUDIT[time=11(sec)] TOTAL[time=15(sec)] Oct 28 16:06:34 ns-test ods-auditor[7757]: Auditor started Oct 28 16:06:34 ns-test ods-auditor[7755]: Auditor started Oct 28 16:06:34 ns-test ods-auditor[7755]: Auditor starting on 16.129.in-addr.arpa Oct 28 16:06:34 ns-test ods-auditor[7755]: Auditing 16.129.in-addr.arpa zone : NSEC3 SIGNED Oct 28 16:06:35 ns-test ods-auditor[7757]: Auditor starting on chalmers.se Oct 28 16:06:35 ns-test ods-auditor[7757]: Auditing chalmers.se zone : NSEC3 SIGNED Oct 28 16:06:36 ns-test ods-auditor[7771]: Auditor started Oct 28 16:06:37 ns-test ods-auditor[7771]: Auditor starting on 225.36.192.in-addr.arpa Oct 28 16:06:37 ns-test ods-auditor[7771]: Auditing 225.36.192.in-addr.arpa zone : NSEC3 SIGNED Oct 28 16:08:33 ns-test ods-auditor[7771]: SOA differs : from 2011051814 to 2011102816 Oct 28 16:08:34 ns-test ods-auditor[7771]: Finished auditing 225.36.192.in-addr.arpa zone Oct 28 16:08:35 ns-test my-reload[7794]: Start processing 225.36.192.in-addr.arpa Oct 28 16:08:39 ns-test my-reload[7794]: End processing 225.36.192.in-addr.arpa Oct 28 16:08:39 ns-test ods-signerd: [STATS] 225.36.192.in-addr.arpa RR[count=260 time=1(sec)] NSEC3[count=0 time=0(sec)] RRSIG[new=1 reused=516 time=0(sec) avg=0(sig/sec)] AUDIT[time=120(sec)] TOTAL[time=125(sec)] Oct 28 16:08:42 ns-test ods-auditor[7640]: SOA differs : from 2011051814 to 2011102816 Oct 28 16:08:42 ns-test ods-auditor[7640]: Finished auditing 224.36.192.in-addr.arpa zone Oct 28 16:08:42 ns-test my-reload[7821]: Start processing 224.36.192.in-addr.arpa Oct 28 16:08:43 ns-test my-reload[7821]: End processing 224.36.192.in-addr.arpa Oct 28 16:08:43 ns-test ods-auditor[7745]: SOA differs : from 2011070712 to 2011102816 Oct 28 16:08:43 ns-test ods-signerd: [STATS] 224.36.192.in-addr.arpa RR[count=259 time=0(sec)] NSEC3[count=0 time=0(sec)] RRSIG[new=6 reused=506 time=0(sec) avg=0(sig/sec)] AUDIT[time=143(sec)] TOTAL[time=144(sec)] Oct 28 16:08:44 ns-test ods-auditor[7745]: Finished auditing 50.5.192.in-addr.arpa zone Oct 28 16:08:45 ns-test my-reload[7848]: Start processing 50.5.192.in-addr.arpa Oct 28 16:08:47 ns-test my-reload[7848]: End processing 50.5.192.in-addr.arpa Oct 28 16:08:47 ns-test ods-signerd: [STATS] 50.5.192.in-addr.arpa RR[count=261 time=0(sec)] NSEC3[count=0 time=0(sec)] RRSIG[new=1 reused=517 time=0(sec) avg=0(sig/sec)] AUDIT[time=134(sec)] TOTAL[time=137(sec)] Oct 28 16:09:48 ns-test ods-auditor[7651]: SOA differs : from 2011101801 to 2011102815 Oct 28 16:09:48 ns-test ods-auditor[7651]: Finished auditing 2.0.0.0.0.b.6.0.1.0.0.2.ip6.arpa zone Oct 28 16:09:49 ns-test my-reload[7879]: Start processing 2.0.0.0.0.b.6.0.1.0.0.2.ip6.arpa Oct 28 16:09:50 ns-test my-reload[7879]: End processing 2.0.0.0.0.b.6.0.1.0.0.2.ip6.arpa Oct 28 16:09:50 ns-test ods-signerd: [STATS] 2.0.0.0.0.b.6.0.1.0.0.2.ip6.arpa RR[count=152 time=1(sec)] NSEC3[count=0 time=0(sec)] RRSIG[new=5 reused=1428 time=0(sec) avg=0(sig/sec)] AUDIT[time=208(sec)] TOTAL[time=211(sec)] Oct 28 16:10:06 ns-test ods-auditor[7757]: SOA differs : from 2011102805 to 2011102817 Oct 28 16:10:09 ns-test ods-auditor[7757]: Finished auditing chalmers.se zone Oct 28 16:10:16 ns-test my-reload[7955]: Start processing chalmers.se Oct 28 16:10:17 ns-test my-reload[7955]: End processing chalmers.se Oct 28 16:10:17 ns-test ods-signerd: [STATS] chalmers.se RR[count=37083 time=2(sec)] NSEC3[count=0 time=0(sec)] RRSIG[new=300 reused=72056 time=6(sec) avg=50(sig/sec)] AUDIT[time=215(sec)] TOTAL[time=237(sec)] Oct 28 16:10:28 ns-test ods-auditor[7701]: SOA differs : from 2011102805 to 2011102819 Oct 28 16:10:29 ns-test ods-auditor[7701]: Finished auditing itsnat.se zone Oct 28 16:10:35 ns-test my-reload[7982]: Start processing itsnat.se Oct 28 16:10:36 ns-test my-reload[7982]: End processing itsnat.se Oct 28 16:10:36 ns-test ods-signerd: [STATS] itsnat.se RR[count=37055 time=2(sec)] NSEC3[count=0 time=0(sec)] RRSIG[new=354 reused=71988 time=3(sec) avg=118(sig/sec)] AUDIT[time=240(sec)] TOTAL[time=257(sec)] Oct 28 16:11:16 ns-test ods-auditor[7755]: SOA differs : from 2011102805 to 2011102817 Oct 28 16:11:18 ns-test ods-auditor[7755]: Finished auditing 16.129.in-addr.arpa zone Oct 28 16:11:23 ns-test my-reload[8015]: Start processing 16.129.in-addr.arpa Oct 28 16:11:24 ns-test my-reload[8015]: End processing 16.129.in-addr.arpa Oct 28 16:11:24 ns-test ods-signerd: [STATS] 16.129.in-addr.arpa RR[count=32960 time=6(sec)] NSEC3[count=0 time=1(sec)] RRSIG[new=237 reused=65922 time=2(sec) avg=118(sig/sec)] AUDIT[time=284(sec)] TOTAL[time=304(sec)] From sion at nominet.org.uk Sat Oct 29 10:07:27 2011 From: sion at nominet.org.uk (=?ISO-8859-1?Q?Si=F4n_Lloyd?=) Date: Sat, 29 Oct 2011 11:07:27 +0100 Subject: [Opendnssec-develop] Supported build dependency for libraries etc In-Reply-To: References: Message-ID: <4EABD05F.2070707@nominet.org.uk> On 18/10/11 14:57, Jerry Lundstr?m wrote: > Hi, > > In my and John discussions how to build this we have come up with a couple > of solutions and here they are. > > A note on B is that you could use jenkins version matrix as described in A > for the major branch name to minimize the job count but you wont as easily > see what breaks. > > /Jerry > > > > > _______________________________________________ > Opendnssec-develop mailing list > Opendnssec-develop at lists.opendnssec.org > https://lists.opendnssec.org/mailman/listinfo/opendnssec-develop While option A gives a slightly daunting matrix of jobs: https://jenkins.opendnssec.org/job/Dummy_Build_OpenDNSSEC/ Being able to see that, e.g. all sqlite builds failed, in one place is quite nice. So provided that the maintenance of this option is not an issue then it gets my vote. Sion -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthijs at NLnetLabs.nl Sat Oct 29 11:48:29 2011 From: matthijs at NLnetLabs.nl (Matthijs Mekking) Date: Sat, 29 Oct 2011 13:48:29 +0200 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #262: Possible race condition causing CPU-bound loop in signerd? In-Reply-To: References: <056.e2e409b68e66b5e253aa981539dcf486@kirei.se> <071.1a56e1f49ebc562b8f5d2ba606f5f47d@kirei.se> Message-ID: <4EABE80D.40308@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I would have expected that the code would be executed: queuing RRsets is a faster operation than fetching and signing them. Perhaps the number of tries should be higher before the additional broadcast is done, and perhaps it should be a verbose message instead of a warning... Best regards, Matthijs On 10/28/2011 04:28 PM, G?ran Bengtson wrote: > On Fri, 28 Oct 2011, OpenDNSSEC wrote: > >> From: OpenDNSSEC >> Cc: "opendnssec-develop at lists.opendnssec.org" >> >> Message-ID: <071.1a56e1f49ebc562b8f5d2ba606f5f47d at kirei.se> >> Date: Fri, 28 Oct 2011 12:00:04 +0200 >> Subject: Re: [OpenDNSSEC] #262: Possible race condition causing >> CPU-bound loop >> in signerd? >> >> #262: Possible race condition causing CPU-bound loop in signerd? >> -------------------------------+-------------------------------------------- >> >> Reporter: goeran@? | Owner: matthijs >> Type: defect | Status: accepted >> Priority: major | Component: Signer >> Version: 1.3.0 | Resolution: >> Keywords: CPU-bound loop | >> -------------------------------+-------------------------------------------- >> >> >> Comment (by matthijs): >> >> Hi, >> >> In the OpenDNSSEC-1.3 branch, revision 5821, I have added a mechanism >> that >> sends out an additional broadcast message to the drudgers, if the >> queue is >> full, but no items are removed anymore. >> >> http://trac.opendnssec.org/changeset/5821/branches/OpenDNSSEC-1.3/signer/src >> >> >> Could you try that patch? > > I've installed the 5821 revision from the OpenDNSSEC-1.3 branch (or should > I use 1.3.2 release with only this patch?). > > Comment below: > > I must add that since my last input in this case, ODS has been running > without problem since October 4th. Rev. 5664 from the 1.3-branch. > That the problem comes and goes with irregular intervals has always > been the case. We did one small change in the environment on > October 4th. We changed the NTPconfig to disallow time to step. > The system is a VMWare guest so the "load-balancer" in VMware (DRS) may > move the guest from one host to another, an operation that is "almost" > transparent to the guest, but the clock often drops some fraction of a > second causing ntp with to original config to step the clock 0.1s or > so. However, we don't think this was the cause since logs indicate > that the VMware load-balancer started to move the guest after it > got stuck in the CPU-loop. I've now change the ntp config back to > its previous version. > > More interesting is that after starting the Rev. 5821 code a > ods-signer sign --all entries in the log (attached below) > indicate that your added code actually was triggered.... > > / G?ran Bengtson > ITService N?t > Chalmers > >> >> -- >> Ticket URL: >> OpenDNSSEC >> OpenDNSSEC > > log file after restart with the new code: > > Oct 28 15:59:51 ns-test ods-enforcerd: HSM opened successfully. > Oct 28 15:59:51 ns-test ods-enforcerd: Reading config > "/usr/local/etc/opendnssec/conf.xml" > Oct 28 15:59:51 ns-test ods-enforcerd: Reading config schema > "/usr/local/share/opendnssec/conf.rng" > Oct 28 15:59:51 ns-test ods-enforcerd: Communication Interval: 3600 > Oct 28 15:59:51 ns-test ods-enforcerd: Using command: > /usr/local/bin/ds-submit to submit DS records > Oct 28 15:59:51 ns-test ods-enforcerd: SQLite database set to: > /var/opendnssec/kasp.db > Oct 28 15:59:51 ns-test ods-enforcerd: Log User set to: local4 > Oct 28 15:59:51 ns-test ods-enforcerd: Switched log facility to: local4 > Oct 28 15:59:51 ns-test ods-enforcerd: Connecting to Database... > Oct 28 15:59:51 ns-test ods-enforcerd: Policy default found. > Oct 28 15:59:51 ns-test ods-enforcerd: Key sharing is Off. > Oct 28 15:59:51 ns-test ods-enforcerd: Purging keys... > Oct 28 15:59:51 ns-test ods-enforcerd: Policy itsnat found. > Oct 28 15:59:51 ns-test ods-enforcerd: Key sharing is Off. > Oct 28 15:59:51 ns-test ods-enforcerd: Purging keys... > Oct 28 15:59:51 ns-test ods-enforcerd: Policy csnet found. > Oct 28 15:59:51 ns-test ods-enforcerd: Key sharing is Off. > Oct 28 15:59:51 ns-test ods-enforcerd: Purging keys... > Oct 28 15:59:51 ns-test ods-enforcerd: zonelist filename set to > /usr/local/etc/opendnssec/zonelist.xml. > Oct 28 15:59:51 ns-test ods-enforcerd: Zone itsnat.se found. > Oct 28 15:59:51 ns-test ods-enforcerd: Policy for itsnat.se set to itsnat. > Oct 28 15:59:51 ns-test ods-enforcerd: Policy itsnat found in DB. > Oct 28 15:59:51 ns-test ods-enforcerd: Config will be output to > /var/opendnssec/signconf/itsnat.se.xml. > Oct 28 15:59:51 ns-test ods-enforcerd: No change to: > /var/opendnssec/signconf/itsnat.se.xml > Oct 28 15:59:51 ns-test ods-enforcerd: Zone chalmers.se found. > Oct 28 15:59:51 ns-test ods-enforcerd: Policy for chalmers.se set to > default. > Oct 28 15:59:51 ns-test ods-enforcerd: Policy default found in DB. > Oct 28 15:59:51 ns-test ods-enforcerd: Config will be output to > /var/opendnssec/signconf/chalmers.se.xml. > Oct 28 15:59:51 ns-test ods-enforcerd: No change to: > /var/opendnssec/signconf/chalmers.se.xml > Oct 28 15:59:51 ns-test ods-enforcerd: Zone chalmers.eu found. > Oct 28 15:59:51 ns-test ods-enforcerd: Policy for chalmers.eu set to > default. > Oct 28 15:59:51 ns-test ods-enforcerd: Config will be output to > /var/opendnssec/signconf/chalmers.eu.xml. > Oct 28 15:59:51 ns-test ods-enforcerd: No change to: > /var/opendnssec/signconf/chalmers.eu.xml > Oct 28 15:59:51 ns-test ods-enforcerd: Zone 16.129.in-addr.arpa found. > Oct 28 15:59:51 ns-test ods-enforcerd: Policy for 16.129.in-addr.arpa > set to default. > Oct 28 15:59:51 ns-test ods-enforcerd: Config will be output to > /var/opendnssec/signconf/16.129.in-addr.arpa.xml. > Oct 28 15:59:51 ns-test ods-enforcerd: No change to: > /var/opendnssec/signconf/16.129.in-addr.arpa.xml > Oct 28 15:59:51 ns-test ods-enforcerd: Zone 50.5.192.in-addr.arpa found. > Oct 28 15:59:51 ns-test ods-enforcerd: Policy for 50.5.192.in-addr.arpa > set to csnet. > Oct 28 15:59:51 ns-test ods-enforcerd: Policy csnet found in DB. > Oct 28 15:59:51 ns-test ods-enforcerd: Config will be output to > /var/opendnssec/signconf/50.5.192.in-addr.arpa.xml. > Oct 28 15:59:51 ns-test ods-enforcerd: No change to: > /var/opendnssec/signconf/50.5.192.in-addr.arpa.xml > Oct 28 15:59:51 ns-test ods-enforcerd: Zone gbg.sunet.se found. > Oct 28 15:59:51 ns-test ods-enforcerd: Policy for gbg.sunet.se set to > default. > Oct 28 15:59:51 ns-test ods-enforcerd: Policy default found in DB. > Oct 28 15:59:51 ns-test ods-enforcerd: Config will be output to > /var/opendnssec/signconf/gbg.sunet.se.xml. > Oct 28 15:59:51 ns-test ods-enforcerd: No change to: > /var/opendnssec/signconf/gbg.sunet.se.xml > Oct 28 15:59:51 ns-test ods-enforcerd: Zone > 2.0.0.0.0.b.6.0.1.0.0.2.ip6.arpa found. > Oct 28 15:59:51 ns-test ods-enforcerd: Policy for > 2.0.0.0.0.b.6.0.1.0.0.2.ip6.arpa set to default. > Oct 28 15:59:51 ns-test ods-enforcerd: Config will be output to > /var/opendnssec/signconf/2.0.0.0.0.b.6.0.1.0.0.2.ip6.arpa.xml. > Oct 28 15:59:51 ns-test ods-enforcerd: No change to: > /var/opendnssec/signconf/2.0.0.0.0.b.6.0.1.0.0.2.ip6.arpa.xml > Oct 28 15:59:51 ns-test ods-enforcerd: Zone 224.36.192.in-addr.arpa found. > Oct 28 15:59:51 ns-test ods-enforcerd: Policy for > 224.36.192.in-addr.arpa set to default. > Oct 28 15:59:51 ns-test ods-enforcerd: Config will be output to > /var/opendnssec/signconf/224.36.192.in-addr.arpa.xml. > Oct 28 15:59:51 ns-test ods-enforcerd: No change to: > /var/opendnssec/signconf/224.36.192.in-addr.arpa.xml > Oct 28 15:59:51 ns-test ods-enforcerd: Zone 225.36.192.in-addr.arpa found. > Oct 28 15:59:51 ns-test ods-enforcerd: Policy for > 225.36.192.in-addr.arpa set to default. > Oct 28 15:59:51 ns-test ods-enforcerd: Config will be output to > /var/opendnssec/signconf/225.36.192.in-addr.arpa.xml. > Oct 28 15:59:51 ns-test ods-enforcerd: No change to: > /var/opendnssec/signconf/225.36.192.in-addr.arpa.xml > Oct 28 15:59:51 ns-test ods-enforcerd: Zone 120.36.192.in-addr.arpa found. > Oct 28 15:59:51 ns-test ods-enforcerd: Policy for > 120.36.192.in-addr.arpa set to default. > Oct 28 15:59:51 ns-test ods-enforcerd: Config will be output to > /var/opendnssec/signconf/120.36.192.in-addr.arpa.xml. > Oct 28 15:59:51 ns-test ods-enforcerd: No change to: > /var/opendnssec/signconf/120.36.192.in-addr.arpa.xml > Oct 28 15:59:51 ns-test ods-enforcerd: Disconnecting from Database... > Oct 28 15:59:51 ns-test ods-enforcerd: Sleeping for 3600 seconds. > Oct 28 15:59:52 ns-test ods-signerd: zone fetcher started > Oct 28 15:59:52 ns-test ods-signerd: [engine] signer started > Oct 28 15:59:52 ns-test ods-signerd: zone fetcher zone itsnat.se is > already up to date, serial is 2011102805 > Oct 28 15:59:52 ns-test ods-signerd: zone fetcher zone chalmers.se is > already up to date, serial is 2011102805 > Oct 28 15:59:52 ns-test ods-signerd: zone fetcher zone chalmers.eu is > already up to date, serial is 2011063005 > Oct 28 15:59:52 ns-test ods-signerd: zone fetcher zone > 16.129.in-addr.arpa is already up to date, serial is 2011102805 > Oct 28 15:59:52 ns-test ods-signerd: zone fetcher zone > 50.5.192.in-addr.arpa is already up to date, serial is 2011070712 > Oct 28 15:59:52 ns-test ods-signerd: zone fetcher zone gbg.sunet.se is > already up to date, serial is 2011051814 > Oct 28 15:59:52 ns-test ods-signerd: zone fetcher zone > 2.0.0.0.0.b.6.0.1.0.0.2.ip6.arpa is already up to date, serial is > 2011101801 > Oct 28 15:59:52 ns-test ods-signerd: zone fetcher zone > 224.36.192.in-addr.arpa is already up to date, serial is 2011051814 > Oct 28 15:59:52 ns-test ods-signerd: zone fetcher zone > 225.36.192.in-addr.arpa is already up to date, serial is 2011051814 > Oct 28 15:59:52 ns-test ods-signerd: zone fetcher zone > 120.36.192.in-addr.arpa is already up to date, serial is 2011071301 > Oct 28 16:00:14 ns-test ods-auditor[7556]: Auditor started > Oct 28 16:00:14 ns-test ods-auditor[7556]: Auditor starting on > 50.5.192.in-addr.arpa > Oct 28 16:00:14 ns-test ods-auditor[7556]: Auditing > 50.5.192.in-addr.arpa zone : NSEC3 SIGNED > Oct 28 16:00:47 ns-test ods-auditor[7556]: SOA differs : from 2011070712 > to 2011102815 > Oct 28 16:00:48 ns-test ods-auditor[7556]: Finished auditing > 50.5.192.in-addr.arpa zone > Oct 28 16:00:48 ns-test my-reload[7572]: Start processing > 50.5.192.in-addr.arpa > Oct 28 16:00:48 ns-test my-reload[7572]: End processing > 50.5.192.in-addr.arpa > Oct 28 16:00:48 ns-test ods-signerd: [STATS] 50.5.192.in-addr.arpa > RR[count=0 time=0(sec)] NSEC3[count=0 time=0(sec)] RRSIG[new=7 > reused=511 time=0(sec) avg=0(sig/sec)] AUDIT[time=34(sec)] > TOTAL[time=34(sec)] Oct 28 16:02:39 ns-test ods-auditor[7602]: Auditor > started > Oct 28 16:02:39 ns-test ods-auditor[7602]: Auditor starting on > 225.36.192.in-addr.arpa > Oct 28 16:02:39 ns-test ods-auditor[7602]: Auditing > 225.36.192.in-addr.arpa zone : NSEC3 SIGNED > Oct 28 16:03:12 ns-test ods-auditor[7602]: SOA differs : from 2011051814 > to 2011102815 > Oct 28 16:03:12 ns-test ods-auditor[7602]: Finished auditing > 225.36.192.in-addr.arpa zone > Oct 28 16:03:12 ns-test my-reload[7612]: Start processing > 225.36.192.in-addr.arpa > Oct 28 16:03:12 ns-test my-reload[7612]: End processing > 225.36.192.in-addr.arpa > Oct 28 16:03:12 ns-test ods-signerd: [STATS] 225.36.192.in-addr.arpa > RR[count=0 time=0(sec)] NSEC3[count=0 time=0(sec)] RRSIG[new=2 > reused=515 time=0(sec) avg=0(sig/sec)] AUDIT[time=33(sec)] > TOTAL[time=33(sec)] Oct 28 16:06:19 ns-test ods-auditor[7640]: Auditor > started > Oct 28 16:06:19 ns-test ods-auditor[7640]: Auditor starting on > 224.36.192.in-addr.arpa > Oct 28 16:06:19 ns-test ods-auditor[7640]: Auditing > 224.36.192.in-addr.arpa zone : NSEC3 SIGNED > Oct 28 16:06:20 ns-test ods-auditor[7642]: Auditor started > Oct 28 16:06:22 ns-test ods-signerd: [fifo] max cap reached, but > drudgers seem to be on hold, notify drudgers again > Oct 28 16:06:24 ns-test last message repeated 32208 times > Oct 28 16:06:24 ns-test ods-auditor[7644]: Auditor started > Oct 28 16:06:24 ns-test ods-signerd: [fifo] max cap reached, but > drudgers seem to be on hold, notify drudgers again > Oct 28 16:06:24 ns-test last message repeated 11316 times > Oct 28 16:06:24 ns-test ods-auditor[7651]: Auditor started > Oct 28 16:06:24 ns-test ods-signerd: [fifo] max cap reached, but > drudgers seem to be on hold, notify drudgers again > Oct 28 16:06:24 ns-test last message repeated 13 times > Oct 28 16:06:24 ns-test ods-auditor[7644]: Auditor starting on > 120.36.192.in-addr.arpa > Oct 28 16:06:24 ns-test ods-signerd: [fifo] max cap reached, but > drudgers seem to be on hold, notify drudgers again > Oct 28 16:06:24 ns-test last message repeated 13 times > Oct 28 16:06:24 ns-test ods-auditor[7644]: Auditing > 120.36.192.in-addr.arpa zone : NSEC3 SIGNED > Oct 28 16:06:24 ns-test ods-signerd: [fifo] max cap reached, but > drudgers seem to be on hold, notify drudgers again > Oct 28 16:06:25 ns-test last message repeated 11558 times > Oct 28 16:06:24 ns-test ods-auditor[7646]: Auditor started > Oct 28 16:06:25 ns-test ods-signerd: [fifo] max cap reached, but > drudgers seem to be on hold, notify drudgers again > Oct 28 16:06:25 ns-test last message repeated 4986 times > Oct 28 16:06:25 ns-test ods-auditor[7646]: Auditor starting on gbg.sunet.se > Oct 28 16:06:25 ns-test ods-signerd: [fifo] max cap reached, but > drudgers seem to be on hold, notify drudgers again > Oct 28 16:06:25 ns-test last message repeated 15 times > Oct 28 16:06:25 ns-test ods-auditor[7646]: Auditing gbg.sunet.se zone : > NSEC3 SIGNED > Oct 28 16:06:25 ns-test ods-signerd: [fifo] max cap reached, but > drudgers seem to be on hold, notify drudgers again > Oct 28 16:06:26 ns-test last message repeated 2376 times > Oct 28 16:06:26 ns-test ods-auditor[7651]: Auditor starting on > 2.0.0.0.0.b.6.0.1.0.0.2.ip6.arpa > Oct 28 16:06:26 ns-test ods-signerd: [fifo] max cap reached, but > drudgers seem to be on hold, notify drudgers again > Oct 28 16:06:26 ns-test last message repeated 78 times > Oct 28 16:06:26 ns-test ods-auditor[7646]: SOA differs : from 2011051814 > to 2011102801 > Oct 28 16:06:26 ns-test ods-signerd: [fifo] max cap reached, but > drudgers seem to be on hold, notify drudgers again > Oct 28 16:06:26 ns-test last message repeated 993 times > Oct 28 16:06:26 ns-test ods-auditor[7651]: Auditing > 2.0.0.0.0.b.6.0.1.0.0.2.ip6.arpa zone : NSEC3 SIGNED > Oct 28 16:06:26 ns-test ods-signerd: [fifo] max cap reached, but > drudgers seem to be on hold, notify drudgers again > Oct 28 16:06:26 ns-test last message repeated 2935 times > Oct 28 16:06:26 ns-test ods-auditor[7646]: Finished auditing > gbg.sunet.se zone > Oct 28 16:06:26 ns-test ods-signerd: [fifo] max cap reached, but > drudgers seem to be on hold, notify drudgers again > Oct 28 16:06:26 ns-test last message repeated 7910 times > Oct 28 16:06:26 ns-test ods-auditor[7642]: Auditor starting on chalmers.eu > Oct 28 16:06:26 ns-test ods-signerd: [fifo] max cap reached, but > drudgers seem to be on hold, notify drudgers again > Oct 28 16:06:26 ns-test last message repeated 13 times > Oct 28 16:06:26 ns-test ods-auditor[7642]: Auditing chalmers.eu zone : > NSEC3 SIGNED > Oct 28 16:06:26 ns-test ods-signerd: [fifo] max cap reached, but > drudgers seem to be on hold, notify drudgers again > Oct 28 16:06:27 ns-test last message repeated 22362 times > Oct 28 16:06:27 ns-test ods-auditor[7642]: SOA differs : from 2011063005 > to 2011102801 > Oct 28 16:06:27 ns-test ods-signerd: [fifo] max cap reached, but > drudgers seem to be on hold, notify drudgers again > Oct 28 16:06:27 ns-test last message repeated 1371 times > Oct 28 16:06:27 ns-test ods-auditor[7642]: Finished auditing chalmers.eu > zone > Oct 28 16:06:27 ns-test ods-signerd: [fifo] max cap reached, but > drudgers seem to be on hold, notify drudgers again > Oct 28 16:06:28 ns-test last message repeated 222 times > Oct 28 16:06:28 ns-test my-reload[7676]: Start processing chalmers.eu > Oct 28 16:06:28 ns-test ods-signerd: [fifo] max cap reached, but > drudgers seem to be on hold, notify drudgers again > Oct 28 16:06:29 ns-test last message repeated 9290 times > Oct 28 16:06:29 ns-test ods-auditor[7644]: SOA differs : from 2011071301 > to 2011102803 > Oct 28 16:06:29 ns-test ods-signerd: [fifo] max cap reached, but > drudgers seem to be on hold, notify drudgers again > Oct 28 16:06:29 ns-test last message repeated 133 times > Oct 28 16:06:30 ns-test ods-auditor[7644]: Finished auditing > 120.36.192.in-addr.arpa zone > Oct 28 16:06:30 ns-test my-reload[7692]: Start processing gbg.sunet.se > Oct 28 16:06:30 ns-test ods-auditor[7701]: Auditor started > Oct 28 16:06:30 ns-test my-reload[7676]: End processing chalmers.eu > Oct 28 16:06:30 ns-test ods-signerd: [STATS] chalmers.eu RR[count=10 > time=0(sec)] NSEC3[count=0 time=0(sec)] RRSIG[new=1 reused=8 time=0(sec) > avg=0(sig/sec)] AUDIT[time=8(sec)] TOTAL[time=11(sec)] Oct 28 16:06:30 > ns-test my-reload[7709]: Start processing 120.36.192.in-addr.arpa > Oct 28 16:06:31 ns-test ods-auditor[7701]: Auditor starting on itsnat.se > Oct 28 16:06:31 ns-test ods-auditor[7701]: Auditing itsnat.se zone : > NSEC3 SIGNED > Oct 28 16:06:31 ns-test ods-auditor[7745]: Auditor started > Oct 28 16:06:31 ns-test ods-auditor[7745]: Auditor starting on > 50.5.192.in-addr.arpa > Oct 28 16:06:31 ns-test ods-auditor[7745]: Auditing > 50.5.192.in-addr.arpa zone : NSEC3 SIGNED > Oct 28 16:06:34 ns-test my-reload[7692]: End processing gbg.sunet.se > Oct 28 16:06:34 ns-test ods-signerd: [STATS] gbg.sunet.se RR[count=14 > time=0(sec)] NSEC3[count=0 time=0(sec)] RRSIG[new=1 reused=12 > time=0(sec) avg=0(sig/sec)] AUDIT[time=8(sec)] TOTAL[time=15(sec)] Oct > 28 16:06:34 ns-test my-reload[7709]: End processing 120.36.192.in-addr.arpa > Oct 28 16:06:34 ns-test ods-signerd: [STATS] 120.36.192.in-addr.arpa > RR[count=15 time=0(sec)] NSEC3[count=0 time=0(sec)] RRSIG[new=1 > reused=22 time=0(sec) avg=0(sig/sec)] AUDIT[time=11(sec)] > TOTAL[time=15(sec)] Oct 28 16:06:34 ns-test ods-auditor[7757]: Auditor > started > Oct 28 16:06:34 ns-test ods-auditor[7755]: Auditor started > Oct 28 16:06:34 ns-test ods-auditor[7755]: Auditor starting on > 16.129.in-addr.arpa > Oct 28 16:06:34 ns-test ods-auditor[7755]: Auditing 16.129.in-addr.arpa > zone : NSEC3 SIGNED > Oct 28 16:06:35 ns-test ods-auditor[7757]: Auditor starting on chalmers.se > Oct 28 16:06:35 ns-test ods-auditor[7757]: Auditing chalmers.se zone : > NSEC3 SIGNED > Oct 28 16:06:36 ns-test ods-auditor[7771]: Auditor started > Oct 28 16:06:37 ns-test ods-auditor[7771]: Auditor starting on > 225.36.192.in-addr.arpa > Oct 28 16:06:37 ns-test ods-auditor[7771]: Auditing > 225.36.192.in-addr.arpa zone : NSEC3 SIGNED > Oct 28 16:08:33 ns-test ods-auditor[7771]: SOA differs : from 2011051814 > to 2011102816 > Oct 28 16:08:34 ns-test ods-auditor[7771]: Finished auditing > 225.36.192.in-addr.arpa zone > Oct 28 16:08:35 ns-test my-reload[7794]: Start processing > 225.36.192.in-addr.arpa > Oct 28 16:08:39 ns-test my-reload[7794]: End processing > 225.36.192.in-addr.arpa > Oct 28 16:08:39 ns-test ods-signerd: [STATS] 225.36.192.in-addr.arpa > RR[count=260 time=1(sec)] NSEC3[count=0 time=0(sec)] RRSIG[new=1 > reused=516 time=0(sec) avg=0(sig/sec)] AUDIT[time=120(sec)] > TOTAL[time=125(sec)] Oct 28 16:08:42 ns-test ods-auditor[7640]: SOA > differs : from 2011051814 to 2011102816 > Oct 28 16:08:42 ns-test ods-auditor[7640]: Finished auditing > 224.36.192.in-addr.arpa zone > Oct 28 16:08:42 ns-test my-reload[7821]: Start processing > 224.36.192.in-addr.arpa > Oct 28 16:08:43 ns-test my-reload[7821]: End processing > 224.36.192.in-addr.arpa > Oct 28 16:08:43 ns-test ods-auditor[7745]: SOA differs : from 2011070712 > to 2011102816 > Oct 28 16:08:43 ns-test ods-signerd: [STATS] 224.36.192.in-addr.arpa > RR[count=259 time=0(sec)] NSEC3[count=0 time=0(sec)] RRSIG[new=6 > reused=506 time=0(sec) avg=0(sig/sec)] AUDIT[time=143(sec)] > TOTAL[time=144(sec)] Oct 28 16:08:44 ns-test ods-auditor[7745]: Finished > auditing 50.5.192.in-addr.arpa zone > Oct 28 16:08:45 ns-test my-reload[7848]: Start processing > 50.5.192.in-addr.arpa > Oct 28 16:08:47 ns-test my-reload[7848]: End processing > 50.5.192.in-addr.arpa > Oct 28 16:08:47 ns-test ods-signerd: [STATS] 50.5.192.in-addr.arpa > RR[count=261 time=0(sec)] NSEC3[count=0 time=0(sec)] RRSIG[new=1 > reused=517 time=0(sec) avg=0(sig/sec)] AUDIT[time=134(sec)] > TOTAL[time=137(sec)] Oct 28 16:09:48 ns-test ods-auditor[7651]: SOA > differs : from 2011101801 to 2011102815 > Oct 28 16:09:48 ns-test ods-auditor[7651]: Finished auditing > 2.0.0.0.0.b.6.0.1.0.0.2.ip6.arpa zone > Oct 28 16:09:49 ns-test my-reload[7879]: Start processing > 2.0.0.0.0.b.6.0.1.0.0.2.ip6.arpa > Oct 28 16:09:50 ns-test my-reload[7879]: End processing > 2.0.0.0.0.b.6.0.1.0.0.2.ip6.arpa > Oct 28 16:09:50 ns-test ods-signerd: [STATS] > 2.0.0.0.0.b.6.0.1.0.0.2.ip6.arpa RR[count=152 time=1(sec)] NSEC3[count=0 > time=0(sec)] RRSIG[new=5 reused=1428 time=0(sec) avg=0(sig/sec)] > AUDIT[time=208(sec)] TOTAL[time=211(sec)] Oct 28 16:10:06 ns-test > ods-auditor[7757]: SOA differs : from 2011102805 to 2011102817 > Oct 28 16:10:09 ns-test ods-auditor[7757]: Finished auditing chalmers.se > zone > Oct 28 16:10:16 ns-test my-reload[7955]: Start processing chalmers.se > Oct 28 16:10:17 ns-test my-reload[7955]: End processing chalmers.se > Oct 28 16:10:17 ns-test ods-signerd: [STATS] chalmers.se RR[count=37083 > time=2(sec)] NSEC3[count=0 time=0(sec)] RRSIG[new=300 reused=72056 > time=6(sec) avg=50(sig/sec)] AUDIT[time=215(sec)] TOTAL[time=237(sec)] > Oct 28 16:10:28 ns-test ods-auditor[7701]: SOA differs : from 2011102805 > to 2011102819 > Oct 28 16:10:29 ns-test ods-auditor[7701]: Finished auditing itsnat.se zone > Oct 28 16:10:35 ns-test my-reload[7982]: Start processing itsnat.se > Oct 28 16:10:36 ns-test my-reload[7982]: End processing itsnat.se > Oct 28 16:10:36 ns-test ods-signerd: [STATS] itsnat.se RR[count=37055 > time=2(sec)] NSEC3[count=0 time=0(sec)] RRSIG[new=354 reused=71988 > time=3(sec) avg=118(sig/sec)] AUDIT[time=240(sec)] TOTAL[time=257(sec)] > Oct 28 16:11:16 ns-test ods-auditor[7755]: SOA differs : from 2011102805 > to 2011102817 > Oct 28 16:11:18 ns-test ods-auditor[7755]: Finished auditing > 16.129.in-addr.arpa zone > Oct 28 16:11:23 ns-test my-reload[8015]: Start processing > 16.129.in-addr.arpa > Oct 28 16:11:24 ns-test my-reload[8015]: End processing 16.129.in-addr.arpa > Oct 28 16:11:24 ns-test ods-signerd: [STATS] 16.129.in-addr.arpa > RR[count=32960 time=6(sec)] NSEC3[count=0 time=1(sec)] RRSIG[new=237 > reused=65922 time=2(sec) avg=118(sig/sec)] AUDIT[time=284(sec)] > TOTAL[time=304(sec)] > > > > _______________________________________________ > 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.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJOq+gMAAoJEA8yVCPsQCW51BEIAMIszTHZA4ZsTRxutw2wvtmD /OJLS8UxOEyDkWOr79HBk1KFPK8nsl5S3IFv4ElE0/xpbmt/8SlN46TjBHVRIbqE b6gLB+osPzhA4HePWuSuHpsGPmSj444nNKVIh/OjHXVQHhRHvoeNlocLsDCrZMPo QvgN/J3h+KzDR6F5HdOigexg9aqOoBzU4HXpftd7hlevLhH6hFm7E/2zz+PEM1Sk 9LVVDGyJhs5eDIOGwQY760l2qBfUa/Rt78iOPjUHWn6QcfX2wDsujNJQJi1gCjqM 3X2ibIG3J8b7ZPT3WSN2Ap/pbS3Egd0bZ7/dS9OyjRdyTvbVV3TpXYwhsNcDqkg= =tEjn -----END PGP SIGNATURE----- From jerry at opendnssec.org Sat Oct 29 13:09:51 2011 From: jerry at opendnssec.org (Jerry =?ISO-8859-1?B?THVuZHN0cvZt?=) Date: Sat, 29 Oct 2011 15:09:51 +0200 Subject: [Opendnssec-develop] Moving to JIRA "next week" Message-ID: On 2011-10-27 16.06, Jerry Lundstr?m wrote: >So I have mostly finished setting up JIRA but ran into a snag with the >pivotal importer, that just got fixed, so its taken a while. I have now tested the pivotal importer and there are some stuff that we need to decide/vote on. But first some background on how the import process work. It will import all issues from pivotal into a JIRA project that has a special PT Workflow Scheme to support the issue states that pivotal has. We have the majority of issues as Accepted that really isn't a "closed" status in JIRA so the statistics is a bit of as its showing 600+ open issues. The iteration that PT has will be mapped as versions in JIRA. Users will be mapped as "Firstname Lastname" if they don't already exist but I tend to contact all the users that don't already exists in JIRA that need to exist for the import so they them self can create the user, choice user id and such things. 1. History If we want to keep all the history the best solution is to keep them in a "OpenDNSSEC Pivotal History" project, not changing the iteration/version or the statuses. Do we want the history in JIRA? +1/-1 2. IceBox The IceBox is a status in PT that are used for all the issues that haven't been assigned to an iteration. JIRA does not have this, you have the future issues all unassigned instead. Also the fake releases we have in the IceBox (Nice to have, More then nice to have etc) is also something that doesn't exist in JIRA. Solution A: There is a labeling system in JIRA that we could use for tagging issues in different ways but its free texted so there might be a bit of a problem keeping it constant and we need to create filters to easily find them. Solution B: We could use fake versions to group up issues like "Nice to have". Solution C: Be a little more strict on how we keep issues and actually assign them right away to a version so we don't have "Nice to have" laying around for years (there are some from 2009 in PT today). +A/+B/+C? 3. Statuses Here is my suggested status mapping: PT JIRA Closed -> Closed Not Yet Started -> Open Finished -> Closed Delivered -> Resolved Accepted -> Closed Rejected -> Closed Comments on the status mapping? I hope that is all :) /Jerry From jakob at kirei.se Sat Oct 29 13:31:52 2011 From: jakob at kirei.se (Jakob Schlyter) Date: Sat, 29 Oct 2011 15:31:52 +0200 Subject: [Opendnssec-develop] Moving to JIRA "next week" In-Reply-To: References: Message-ID: <5EAF66F4-6220-4A88-9445-CE1DCC0EDD3A@kirei.se> On 29 okt 2011, at 15:09, Jerry Lundstr?m wrote: > Do we want the history in JIRA? +1/-1 As long as we keep Pivotal Around, I'd say -1. > 2. IceBox > The IceBox is a status in PT that are used for all the issues that haven't > been assigned to an iteration. JIRA does not have this, you have the > future issues all unassigned instead. Also the fake releases we have in > the IceBox (Nice to have, More then nice to have etc) is also something > that doesn't exist in JIRA. > > Solution A: > There is a labeling system in JIRA that we could use for tagging issues in > different ways but its free texted so there might be a bit of a problem > keeping it constant and we need to create filters to easily find them. > > Solution B: > We could use fake versions to group up issues like "Nice to have". > > Solution C: > Be a little more strict on how we keep issues and actually assign them > right away to a version so we don't have "Nice to have" laying around for > years (there are some from 2009 in PT today). > > +A/+B/+C? C. > 3. Statuses > Here is my suggested status mapping: > PT JIRA > Closed -> Closed > Not Yet Started -> Open > Finished -> Closed > Delivered -> Resolved > Accepted -> Closed > Rejected -> Closed > > Comments on the status mapping? Works for me. Would it be an option to manually add stuff we will continue work on to JIRA, and just let the leftovers in Pivotal (setting everyone except me & jerry to Viewers) ? jakob From jerry at opendnssec.org Sat Oct 29 14:15:21 2011 From: jerry at opendnssec.org (Jerry =?ISO-8859-1?B?THVuZHN0cvZt?=) Date: Sat, 29 Oct 2011 16:15:21 +0200 Subject: [Opendnssec-develop] Moving to JIRA "next week" In-Reply-To: <5EAF66F4-6220-4A88-9445-CE1DCC0EDD3A@kirei.se> Message-ID: On 2011-10-29 15.31, Jakob Schlyter wrote: >As long as we keep Pivotal Around, I'd say -1. There is a point of keeping the history in the same JIRA if we want to keep it, when you search for something you get a hit on the old stuff also. And its one less site to manage. >Would it be an option to manually add stuff we will continue work on to >JIRA, and just let the leftovers in Pivotal (setting everyone except me & >jerry to Viewers) ? That can also be an option if your willing copy everything manually. :) But what I was thinking was to move the issues we want to keep to the real projects in JIRA once imported and convert all the necessary statuses and fields. Depending on what we decide on 2 it will be more or less easy. /Jerry From sion at nominet.org.uk Sun Oct 30 12:12:11 2011 From: sion at nominet.org.uk (=?ISO-8859-1?Q?Si=F4n_Lloyd?=) Date: Sun, 30 Oct 2011 12:12:11 +0000 Subject: [Opendnssec-develop] Moving to JIRA "next week" In-Reply-To: References: Message-ID: <4EAD3F1B.7020108@nominet.org.uk> On 29/10/11 14:09, Jerry Lundstr?m wrote: > On 2011-10-27 16.06, Jerry Lundstr?m wrote: > > 1. History > If we want to keep all the history the best solution is to keep them in a > "OpenDNSSEC Pivotal History" project, not changing the iteration/version > or the statuses. > > Do we want the history in JIRA? +1/-1 +1 if it is easy; I think that we could live without it though if it looks like a lot of work. > 2. IceBox > > +A/+B/+C? B looks like our current "solution"; if people are happy with that then we can stick with it. If not then +C. My only worry about C is that we will have items that just keep slipping from one release to the next, but we can cross that bridge if and when we come to it. > 3. Statuses > Here is my suggested status mapping: > PT JIRA > Closed -> Closed > Not Yet Started -> Open > Finished -> Closed > Delivered -> Resolved > Accepted -> Closed > Rejected -> Closed > > Comments on the status mapping? > Shouldn't rejected go back to open? I thought that it meant that the fix was rejected and had to be redone. Sion From jerry at opendnssec.org Sun Oct 30 12:26:31 2011 From: jerry at opendnssec.org (Jerry =?ISO-8859-1?B?THVuZHN0cvZt?=) Date: Sun, 30 Oct 2011 13:26:31 +0100 Subject: [Opendnssec-develop] Moving to JIRA "next week" In-Reply-To: <4EAD3F1B.7020108@nominet.org.uk> Message-ID: On 2011-10-30 13.12, Si?n Lloyd wrote: >> 2. IceBox >B looks like our current "solution"; if people are happy with that then >we can stick with it. If not then +C. My only worry about C is that we >will have items that just keep slipping from one release to the next, >but we can cross that bridge if and when we come to it. That is a problem we will likely have with any solution, its nice to have nice-to-have but if they are never made why do we keep them? >> 3. Statuses >Shouldn't rejected go back to open? I thought that it meant that the fix >was rejected and had to be redone. Ah okay, if it was used like that of course it should be mapped to Open. /Jerry From rickard at opendnssec.org Mon Oct 31 08:45:38 2011 From: rickard at opendnssec.org (Rickard Bellgrim) Date: Mon, 31 Oct 2011 09:45:38 +0100 Subject: [Opendnssec-develop] Moving to JIRA "next week" In-Reply-To: References: Message-ID: > Do we want the history in JIRA? +1/-1 -1 I can live without the history. > Solution B: > We could use fake versions to group up issues like "Nice to have". > > Solution C: > Be a little more strict on how we keep issues and actually assign them > right away to a version so we don't have "Nice to have" laying around for > years (there are some from 2009 in PT today). +B (or +C) It is good to write down ideas somewhere. The question is if Jira / Pivotal is the best place to store them. If we have them in Jira, then users can see them e.g. under the "future release"-release. And then maybe push for a particular feature and makes us to include it in a real release. > Comments on the status mapping? Agree with Sion. // Rickard From jerry at opendnssec.org Mon Oct 31 10:32:36 2011 From: jerry at opendnssec.org (Jerry =?ISO-8859-1?B?THVuZHN0cvZt?=) Date: Mon, 31 Oct 2011 11:32:36 +0100 Subject: [Opendnssec-develop] Moving to JIRA "next week" In-Reply-To: Message-ID: On 2011-10-31 09.45, Rickard Bellgrim wrote: >It is good to write down ideas somewhere. The question is if Jira / >Pivotal is the best place to store them. If we have them in Jira, then >users can see them e.g. under the "future release"-release. And then >maybe push for a particular feature and makes us to include it in a >real release. There is built in voting on issues that we could use for prioritizing new features and we could tag them like that. /Jerry From sara at sinodun.com Mon Oct 31 12:10:49 2011 From: sara at sinodun.com (Sara Dickinson) Date: Mon, 31 Oct 2011 13:10:49 +0100 Subject: [Opendnssec-develop] RE: Documentation Message-ID: fyi - I have pushed the 'revamped' docs out to the main site: https://wiki.opendnssec.org/display/DOCS and there is now a separate SoftHSM page https://wiki.opendnssec.org/display/SoftHSMDOCS So please go ahead and make any documentation changes for the next release to these sites using 'hidden' pages as outlined in the documentation process: https://wiki.opendnssec.org/display/OpenDNSSEC/Document+Management+Process Sara.