From AlexD at nominet.org.uk Wed May 2 09:07:09 2012 From: AlexD at nominet.org.uk (Alex Dalitz) Date: Wed, 2 May 2012 09:07:09 +0000 Subject: [Opendnssec-develop] Re: Jenkins build status emails In-Reply-To: References: Message-ID: <5122EA11-0596-462A-B34C-195B02801430@nominet.org.uk> Hi - I think it's great that we have a new automated build and test system. However, if I could offer one suggestion for a better user experience, it would be to tune the emails that are sent in the event of a broken build. AIUI, the standard practice for this sort of thing is to send the "failed" email _only_ to those who have made a commit to the relevant source repository since the last successful build (and, of course, those who specifically request to receive all build emails). Would it be possible to make this change, please? Thanks, Alex. On 26 Apr 2012, at 11:03, Jerry Lundstr?m wrote: > On Apr 26, 2012, at 11:42 , Jerry Lundstr?m wrote: >> Jenkins will send emails on every failed build to the commits list and the committers. If the build is fixed it will send one email about that then nothing until the next failed build. There will be one email per failed node. > > > Forgot one thing, the test-* parts won't be sent to the committers, just the commits list. > > -- > Jerry Lundstr?m - OpenDNSSEC Developer > http://www.opendnssec.org/ > > > _______________________________________________ > Opendnssec-develop mailing list > Opendnssec-develop at lists.opendnssec.org > https://lists.opendnssec.org/mailman/listinfo/opendnssec-develop From jerry at opendnssec.org Wed May 2 09:17:53 2012 From: jerry at opendnssec.org (=?iso-8859-1?Q?Jerry_Lundstr=F6m?=) Date: Wed, 2 May 2012 11:17:53 +0200 Subject: [Opendnssec-develop] Jenkins build status emails In-Reply-To: <5122EA11-0596-462A-B34C-195B02801430@nominet.org.uk> References: <5122EA11-0596-462A-B34C-195B02801430@nominet.org.uk> Message-ID: On May 2, 2012, at 11:07 , Alex Dalitz wrote: > I think it's great that we have a new automated build and test system. > > However, if I could offer one suggestion for a better user experience, it would be to tune the emails that are sent in the event of a broken build. > > AIUI, the standard practice for this sort of thing is to send the "failed" email _only_ to those who have made a commit to the relevant source repository since the last successful build (and, of course, those who specifically request to receive all build emails). > > Would it be possible to make this change, please? Sure, we'll set up a separate list for Jenkins build mails. Sion, can you fix? Just to point out, I asked about this some time ago just because I knew it would be a bit spammy :) People was happy with commit list. -- Jerry Lundstr?m - OpenDNSSEC Developer http://www.opendnssec.org/ From AlexD at nominet.org.uk Wed May 2 09:23:07 2012 From: AlexD at nominet.org.uk (Alex Dalitz) Date: Wed, 2 May 2012 09:23:07 +0000 Subject: [Opendnssec-develop] Jenkins build status emails In-Reply-To: References: <5122EA11-0596-462A-B34C-195B02801430@nominet.org.uk> Message-ID: <85C13280-3A44-44A2-B30A-32B832D41630@nominet.org.uk> I think it's great that we have a new automated build and test system. However, if I could offer one suggestion for a better user experience, it would be to tune the emails that are sent in the event of a broken build. AIUI, the standard practice for this sort of thing is to send the "failed" email _only_ to those who have made a commit to the relevant source repository since the last successful build (and, of course, those who specifically request to receive all build emails). Would it be possible to make this change, please? Sure, we'll set up a separate list for Jenkins build mails. Sion, can you fix? That isn't quite what I meant. Most of the automated build/test systems I've used over the last 10 years have had the capability to email only those who have made a commit since the last successful build. It doesn't make much sense to email _everybody_ (even those who have had nothing to do with the reasons the build broke since it last succeeded) - this leads to a situation where people tend to ignore all the build emails. Which kind of defeats the point of having them... I note that this is possible from the following page : https://wiki.jenkins-ci.org/display/JENKINS/Email-ext+plugin Thanks, Alex. Just to point out, I asked about this some time ago just because I knew it would be a bit spammy :) People was happy with commit list. -- Jerry Lundstr?m - OpenDNSSEC Developer http://www.opendnssec.org/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From jerry at opendnssec.org Wed May 2 09:29:42 2012 From: jerry at opendnssec.org (=?iso-8859-1?Q?Jerry_Lundstr=F6m?=) Date: Wed, 2 May 2012 11:29:42 +0200 Subject: [Opendnssec-develop] Jenkins build status emails In-Reply-To: <85C13280-3A44-44A2-B30A-32B832D41630@nominet.org.uk> References: <5122EA11-0596-462A-B34C-195B02801430@nominet.org.uk> <85C13280-3A44-44A2-B30A-32B832D41630@nominet.org.uk> Message-ID: <23DCB269-D375-4C95-A24B-9C69C1FAF572@opendnssec.org> On May 2, 2012, at 11:23 , Alex Dalitz wrote: > Most of the automated build/test systems I've used over the last 10 years have had the capability to email only those who have made a commit since the last successful build. It doesn't make much sense to email _everybody_ (even those who have had nothing to do with the reasons the build broke since it last succeeded) - this leads to a situation where people tend to ignore all the build emails. Which kind of defeats the point of having them... Its already set up that way for build-*. test-* does not generate emails to committers because of the problems with random failing tests and that we have a few tests that always fails because we are working on the fix. And I really want all emails! :) and maybe someone else does, so a separate list is the solution for that. -- Jerry Lundstr?m - OpenDNSSEC Developer http://www.opendnssec.org/ From AlexD at nominet.org.uk Wed May 2 09:36:54 2012 From: AlexD at nominet.org.uk (Alex Dalitz) Date: Wed, 2 May 2012 09:36:54 +0000 Subject: [Opendnssec-develop] Jenkins build status emails In-Reply-To: <23DCB269-D375-4C95-A24B-9C69C1FAF572@opendnssec.org> References: <5122EA11-0596-462A-B34C-195B02801430@nominet.org.uk> <85C13280-3A44-44A2-B30A-32B832D41630@nominet.org.uk> <23DCB269-D375-4C95-A24B-9C69C1FAF572@opendnssec.org> Message-ID: <78C07868-DD65-4BD0-90EB-B7038FCC1576@nominet.org.uk> > And I really want all emails! :) and maybe someone else does, so a separate list is the solution for that. Perhaps you could configure Jenkins to send the test-* emails only to you (and those who particularly want spammed)? [yes, I know I can set up a filter to prevent the spambot from annoying me - but this seems slightly unnecessary] Thanks, Alex. From jerry at opendnssec.org Wed May 2 11:56:46 2012 From: jerry at opendnssec.org (=?iso-8859-1?Q?Jerry_Lundstr=F6m?=) Date: Wed, 2 May 2012 13:56:46 +0200 Subject: [Opendnssec-develop] Jenkins build status emails In-Reply-To: <78C07868-DD65-4BD0-90EB-B7038FCC1576@nominet.org.uk> References: <5122EA11-0596-462A-B34C-195B02801430@nominet.org.uk> <85C13280-3A44-44A2-B30A-32B832D41630@nominet.org.uk> <23DCB269-D375-4C95-A24B-9C69C1FAF572@opendnssec.org> <78C07868-DD65-4BD0-90EB-B7038FCC1576@nominet.org.uk> Message-ID: <06B2F2A9-1A2A-4262-9882-9E83DECBE6A6@opendnssec.org> On May 2, 2012, at 11:36 , Alex Dalitz wrote: >> And I really want all emails! :) and maybe someone else does, so a separate list is the solution for that. > > Perhaps you could configure Jenkins to send the test-* emails only to you (and those who particularly want spammed)? Its so much easier to manage a real mailing list then configuring every job on every change. -- Jerry Lundstr?m - OpenDNSSEC Developer http://www.opendnssec.org/ From jerry at opendnssec.org Wed May 2 12:53:01 2012 From: jerry at opendnssec.org (=?iso-8859-1?Q?Jerry_Lundstr=F6m?=) Date: Wed, 2 May 2012 14:53:01 +0200 Subject: [Opendnssec-develop] Jenkins build status emails In-Reply-To: <06B2F2A9-1A2A-4262-9882-9E83DECBE6A6@opendnssec.org> References: <5122EA11-0596-462A-B34C-195B02801430@nominet.org.uk> <85C13280-3A44-44A2-B30A-32B832D41630@nominet.org.uk> <23DCB269-D375-4C95-A24B-9C69C1FAF572@opendnssec.org> <78C07868-DD65-4BD0-90EB-B7038FCC1576@nominet.org.uk> <06B2F2A9-1A2A-4262-9882-9E83DECBE6A6@opendnssec.org> Message-ID: <05417E34-A450-4187-B0BF-662AB47190F7@opendnssec.org> On May 2, 2012, at 13:56 , Jerry Lundstr?m wrote: > On May 2, 2012, at 11:36 , Alex Dalitz wrote: >>> And I really want all emails! :) and maybe someone else does, so a separate list is the solution for that. >> >> Perhaps you could configure Jenkins to send the test-* emails only to you (and those who particularly want spammed)? > > Its so much easier to manage a real mailing list then configuring every job on every change. There are many different views about this, just talked some with Sion on jabber and he thought it could be a case that the suite is not mature yet and it might be more accepted once it "stable". But if you look at the tests that a randomly failing on some platforms it could be the software itself that is buggy, we don't know. I don't think there are many that checks the Jenkins web interface and if we stop sending test-* emails then even less will know that they fail. Lets bring this up on our next tele conference (next week), until then its left as is. Rickard, could you add this to the agenda? Thanks Jerry -- Jerry Lundstr?m - OpenDNSSEC Developer http://www.opendnssec.org/ From rickard at opendnssec.org Wed May 2 14:27:23 2012 From: rickard at opendnssec.org (Rickard Bellgrim) Date: Wed, 2 May 2012 16:27:23 +0200 Subject: [Opendnssec-develop] Jenkins build status emails In-Reply-To: <05417E34-A450-4187-B0BF-662AB47190F7@opendnssec.org> References: <5122EA11-0596-462A-B34C-195B02801430@nominet.org.uk> <85C13280-3A44-44A2-B30A-32B832D41630@nominet.org.uk> <23DCB269-D375-4C95-A24B-9C69C1FAF572@opendnssec.org> <78C07868-DD65-4BD0-90EB-B7038FCC1576@nominet.org.uk> <06B2F2A9-1A2A-4262-9882-9E83DECBE6A6@opendnssec.org> <05417E34-A450-4187-B0BF-662AB47190F7@opendnssec.org> Message-ID: > Rickard, could you add this to the agenda? ACK From rickard at opendnssec.org Wed May 2 14:49:27 2012 From: rickard at opendnssec.org (Rickard Bellgrim) Date: Wed, 2 May 2012 16:49:27 +0200 Subject: [Opendnssec-develop] Meeting 20120508 Message-ID: Hi We have telephone meeting next week. Date: Tuesday 8 May Time: 15:00-16:00 CEST, 14:00-15:00 BST Agenda: https://wiki.opendnssec.org/display/OpenDNSSEC/2012-05-08+Agenda // Rickard From Roland.vanRijswijk at surfnet.nl Tue May 8 12:17:18 2012 From: Roland.vanRijswijk at surfnet.nl (Roland van Rijswijk) Date: Tue, 8 May 2012 14:17:18 +0200 Subject: [Opendnssec-develop] Enforcer NG meeting minutes 2012-05-08 Message-ID: Hi guys, Here are the minutes for today's short Enforcer NG call: https://wiki.opendnssec.org/display/OpenDNSSEC/2012-05-08+-+Enforcer+NG+teleconference Highlight: nearly ready for an alpha version, to be released when Yuri & Rickard have finished testing and the code has been committed. Cheers, Roland -- Roland M. van Rijswijk -- SURFnet Middleware Services -- t: +31-30-2305388 -- e: roland.vanrijswijk at surfnet.nl From jerry at opendnssec.org Wed May 9 10:54:19 2012 From: jerry at opendnssec.org (=?ISO-8859-1?Q?Jerry_Lundstr=F6m?=) Date: Wed, 9 May 2012 12:54:19 +0200 Subject: [Opendnssec-develop] openbsd down and diabled in builds/tests Message-ID: Hi, Will have to reinstall openbsd tomorrow and see if I can get it working again. /Jerry From rickard at opendnssec.org Wed May 9 12:05:19 2012 From: rickard at opendnssec.org (Rickard Bellgrim) Date: Wed, 9 May 2012 14:05:19 +0200 Subject: [Opendnssec-develop] SoftHSM 1.3.3 Message-ID: Hi SoftHSM 1.3.3 is now ready for release. Jakob, you just need to set the date in the NEWS-file. // Rickard From rickard at opendnssec.org Wed May 9 13:00:39 2012 From: rickard at opendnssec.org (Rickard Bellgrim) Date: Wed, 9 May 2012 15:00:39 +0200 Subject: [Opendnssec-develop] OpenDNSSEC 1.3.8 Message-ID: Hi OpenDNSSEC 1.3.8 is ready for release. Jakob, you just need to add the correct release date in the NEWS-file. // Rickard From matthijs at nlnetlabs.nl Wed May 9 13:51:03 2012 From: matthijs at nlnetlabs.nl (Matthijs Mekking) Date: Wed, 09 May 2012 15:51:03 +0200 Subject: [Opendnssec-develop] Release Management Process Message-ID: <4FAA7647.8040909@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, I have updated the release check list at: https://wiki.opendnssec.org/display/OpenDNSSE/Release+Management+Process Basically, steps 2 - 4 have been added: Step 2: I guess it is sane to check if jenkins does not have any tests complaining before doing the release. Step 3: Code review is part of NLnet Labs release process, it might be sane to do that too for OpenDNSSEC. Step 4: The release candidate to the maintainers step. Furthermore, I have made the release check list a bit more detailed. Best regards, Matthijs -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJPqnZHAAoJEA8yVCPsQCW57DIH/3WzhCTzf+Ax9oQD7wqD7vjE WqpwxdWUJA/Wu5932Gu0MoNIvI9rbOflvFc7psMskFVq3/cPeStUR1s1OlKIXoh6 ESNXczenWMNymJQuxtzKI4SVNApBwyCxECXIBERTnRnwg7gzxFJ7kNJo8uUijSkU z/uUh0R6Av+K4tTZjZ7g8s5Mwvc1yVFuljtnuJxdk3yz8ShbKxm6mB0eevFfh984 AFV6m40XDZQAp4DBQ/c+LcUFpXbPDB70soCdtZSXFSL1RePhZVpfN5zHngQtQH+P m98rna1pzqMSABkbLOAw+1AQT1JRMM7UszPzn0AD86I7RsDK7vDaKEIe41lOrwY= =/+6P -----END PGP SIGNATURE----- From matthijs at nlnetlabs.nl Wed May 9 13:52:25 2012 From: matthijs at nlnetlabs.nl (Matthijs Mekking) Date: Wed, 09 May 2012 15:52:25 +0200 Subject: [Opendnssec-develop] Release Management Process In-Reply-To: <4FAA7647.8040909@nlnetlabs.nl> References: <4FAA7647.8040909@nlnetlabs.nl> Message-ID: <4FAA7699.7040807@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 05/09/2012 03:51 PM, Matthijs Mekking wrote: > Hi, > > I have updated the release check list at: > > https://wiki.opendnssec.org/display/OpenDNSSE/Release+Management+Process That > should be: https://wiki.opendnssec.org/display/OpenDNSSEC/Release+Management+Process > > Basically, steps 2 - 4 have been added: > > Step 2: I guess it is sane to check if jenkins does not have any > tests complaining before doing the release. > > Step 3: Code review is part of NLnet Labs release process, it might > be sane to do that too for OpenDNSSEC. > > Step 4: The release candidate to the maintainers step. > > Furthermore, I have made the release check list a bit more > detailed. > > Best regards, Matthijs > _______________________________________________ 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/ iQEcBAEBAgAGBQJPqnaZAAoJEA8yVCPsQCW5dPwIANpRcN/4R1pLwGYzbjDIoif9 5BJJNSVllANHVSta/0lYJOmy78JiBUZ5tdbD4xmjJLVQbbj80cog7cmxt1qfKwJp /3SgQy7g8GiYIwXenskb3hNJ2s3sPsnsZ341aE/1IjA7HPuqyzvGp6Tcefw2gUN9 uDoZ/70us+qpbOUNW+owbQ/DdDIcfUgcD+ccTdLPwMWILIQE1Xz1SSsCqQqf7vOL wquDpxeQNPZMvA2dwzqftO5XgacPTDutLqmhlk807X9jdIO1fyMd3PuHqJNCc+Ge 6ziMOQ6gsUzDreQ/Iwf5HQbgUBdG16Lauu0F8ZI9IGyW2UVBg+QirLmLZNkBnrU= =CriR -----END PGP SIGNATURE----- From jakob at kirei.se Wed May 9 18:47:56 2012 From: jakob at kirei.se (Jakob Schlyter) Date: Wed, 9 May 2012 20:47:56 +0200 Subject: [Opendnssec-develop] SoftHSM 1.3.3 In-Reply-To: References: Message-ID: On 9 maj 2012, at 14:05, Rickard Bellgrim wrote: > SoftHSM 1.3.3 is now ready for release. Jakob, you just need to set > the date in the NEWS-file. Ready! j From jakob at kirei.se Wed May 9 18:54:03 2012 From: jakob at kirei.se (Jakob Schlyter) Date: Wed, 9 May 2012 20:54:03 +0200 Subject: [Opendnssec-develop] OpenDNSSEC 1.3.8 In-Reply-To: References: Message-ID: On 9 maj 2012, at 15:00, Rickard Bellgrim wrote: > OpenDNSSEC 1.3.8 is ready for release. Jakob, you just need to add the > correct release date in the NEWS-file. done. j From jerry at opendnssec.org Thu May 10 14:42:33 2012 From: jerry at opendnssec.org (=?iso-8859-1?Q?Jerry_Lundstr=F6m?=) Date: Thu, 10 May 2012 16:42:33 +0200 Subject: [Opendnssec-develop] Re: openbsd down and diabled in builds/tests In-Reply-To: References: Message-ID: <03396DF4-CD4D-4A87-BEFC-80B96DABFE26@opendnssec.org> On May 9, 2012, at 12:54 , Jerry Lundstr?m wrote: > Will have to reinstall openbsd tomorrow and see if I can get it working again. After a reinstall to 5.1 and 5 hours of compiling Java 1.6 its back and working! -- Jerry Lundstr?m - OpenDNSSEC Developer http://www.opendnssec.org/ From sara at sinodun.com Thu May 10 19:36:20 2012 From: sara at sinodun.com (Sara (Sinodun)) Date: Thu, 10 May 2012 20:36:20 +0100 Subject: [Opendnssec-develop] RE: Jenkins master server outage 11th & 12th May Message-ID: All, Due to planned maintenance work at the business park where our offices are located we will be without power from the evening of Friday 11th May until sometime in the afternoon of Saturday 12th May. As a result the jenkins master server will be offline for this period. We will send an email on the 12th when it is back online. Apologies for any inconvenience this causes. Regards Sara. From rick at openfortress.nl Thu May 10 22:49:46 2012 From: rick at openfortress.nl (Rick van Rein) Date: Thu, 10 May 2012 22:49:46 +0000 Subject: [Opendnssec-develop] Feature proposal: Stop Enforcer action on given zone Message-ID: <20120510224946.GA9666@newphantom.local> Hello, Over the past few years, I've seen OpenDNSSEC lock up in curious ways -- not in the last place because I tend to treat software harshly while testing, in a hope to learn about its behaviour in exceptional cases, and help the project forward. When trying to wheeze out of tight spots, the approach usually comes down to shutting down the Enforcer and acting directly upon the Signer. The reason is always the same -- spontaneous actions by the Enforcer are disruptive to testing and recovery procedures, especially because they complicate those actions. Still, while doing this is a Good Idea (tm) for challenged zones, it may at the same time disrupt the proper functioning of other zones, notably on adding and removing them, or rolling their keys within a time slot that is tight for whatever reason. The solution is simple and probably very usable to the admin: An ability to block the progress of the Enforcer completely on a given zone. That very specifically includes blocks on writing out SignConf files and working on the keys in the HSM (need to think through ShareKeys policies though). If all of y'all agree that this is useful, I suppose this could be turned into a feature request. It's just my bilateral tuppence. Cheers, -Rick From jerry at opendnssec.org Fri May 11 07:43:30 2012 From: jerry at opendnssec.org (=?ISO-8859-1?Q?Jerry_Lundstr=F6m?=) Date: Fri, 11 May 2012 09:43:30 +0200 Subject: [Opendnssec-develop] Feature proposal: Stop Enforcer action on given zone In-Reply-To: <20120510224946.GA9666@newphantom.local> References: <20120510224946.GA9666@newphantom.local> Message-ID: Hi Rick, Interesting proposal... On Fri, May 11, 2012 at 12:49 AM, Rick van Rein wrote: > > When trying to wheeze out of tight spots, the approach usually comes down to > shutting down the Enforcer and acting directly upon the Signer. ?The reason is > always the same -- spontaneous actions by the Enforcer are disruptive to testing > and recovery procedures, especially because they complicate those actions. Could you give us some examples/scenarios here? To me it sounds like a miss in the procedure if you leave the Enforcer running. /Jerry From sion at nominet.org.uk Fri May 11 08:05:49 2012 From: sion at nominet.org.uk (=?ISO-8859-1?Q?Si=F4n_Lloyd?=) Date: Fri, 11 May 2012 09:05:49 +0100 Subject: [Opendnssec-develop] Feature proposal: Stop Enforcer action on given zone In-Reply-To: References: <20120510224946.GA9666@newphantom.local> Message-ID: <4FACC85D.7070808@nominet.org.uk> On 11/05/12 08:43, Jerry Lundstr?m wrote: > Hi Rick, > > Interesting proposal... > > On Fri, May 11, 2012 at 12:49 AM, Rick van Rein wrote: >> When trying to wheeze out of tight spots, the approach usually comes down to >> shutting down the Enforcer and acting directly upon the Signer. The reason is >> always the same -- spontaneous actions by the Enforcer are disruptive to testing >> and recovery procedures, especially because they complicate those actions. > Could you give us some examples/scenarios here? > > To me it sounds like a miss in the procedure if you leave the Enforcer running. > So you are proposing something along the lines of "ksmutil zone freeze -z " which stops the enforcer from changing keys? This should be okay, you may see some extra complaints when you unfreeze, say if a key has been in use long past its retirement date. There may be questions on whether we need to reset any timers also, for instance would we believe that a key has been published for 5 days if the zone was frozen for most of that time? Sion From rick at openfortress.nl Fri May 11 08:18:49 2012 From: rick at openfortress.nl (Rick van Rein) Date: Fri, 11 May 2012 08:18:49 +0000 Subject: [Opendnssec-develop] Feature proposal: Stop Enforcer action on given zone In-Reply-To: References: <20120510224946.GA9666@newphantom.local> Message-ID: <20120511081848.GH11554@newphantom.local> Hello, > Interesting proposal... It's a personal itch... and I'm sure more experienced the same. > Could you give us some examples/scenarios here? Sure, here's a mistake that I made (thanks go to Roland for helping to debunk it): I imported ZKT keys into OpenDNSSEC last month, and did not pay enough attention to the destination policy's different keys. (Yes, I will add a note to the HOWTO that I wrote.) So now the zone is trying to roll to RSASHA256 keys where I used RSASHA1 before. The system is not stopping me from doing this, but Unbound is killing the subjected domains. The first step is a quickfix -- getting the domain back up by editing the .signconf manually. This is only reliable while ods-enforcer is stopped. I didn't have time to really fix the solution immediately; moreover, I tend to want to think about the best way a bit. At the same time, I was rolling out a new ENUM domain for a customer, and needed to roll it through OpenDNSSEC. This required an active Enforcer. As you can tell, I'm forever experimenting. Downtime is an occupational hazard, but I think it is useful because it can support other users who end up in trouble just as well. > To me it sounds like a miss in the procedure if you leave the Enforcer running. Yes, from the perspective of the zone being recovered. But not from the perspective of that new domain being added. It could be useful to be able to switch the Enforcer on or off for those separately. At least, that is what I learnt from this. Cheers, -Rick From jerry at opendnssec.org Fri May 11 10:18:08 2012 From: jerry at opendnssec.org (=?ISO-8859-1?Q?Jerry_Lundstr=F6m?=) Date: Fri, 11 May 2012 12:18:08 +0200 Subject: [Opendnssec-develop] Test platform freebsd 9 amd64 ods-enforcerd 1.3 core dump Message-ID: Hi, I need a few pair of fresh eyes, mines bleeding... We got one issue left on the test platform, the 1.3 branch ods-enforcerd core dumps on 5 tests when exiting ... BUT! Heres the funny part, it works on trunk... and I can't really find any difference between them. I have run trunk with 1.3's softhsm, no difference. 1.3 with trunk's softhsm, nada change. I copied libhsm from trunk to 1.3, still core dump. The test is 10-110 and it sets repository capacity to 1 and expect failure. http://svn.opendnssec.org/branches/OpenDNSSEC-1.3/testing/test-cases.d/10-110-odscc10t110/ 1.3 core dumps on softhsms 2nd CloseSession that unloads the module. There are many strange things with SQLite on FreeBSD amd64 but the damn strange thing is that it work on trunk.... WHY??? Help? :) If you need access send a ssh pubkey to me and username, if you already sent pubkey just ping me for an account. May 11 12:01:54 freebsd64-ods06 kernel: May 11 12:01:54 freebsd64-ods06 ods-enforcerd: Repository SoftHSM is full, cannot create more ZSKs for policy default May 11 12:01:54 freebsd64-ods06 ods-enforcerd: Purging keys... May 11 12:01:54 freebsd64-ods06 ods-enforcerd: zonelist filename set to /home/jenkins/workspace/root/test/etc/opendnssec/zonelist.xml. May 11 12:01:54 freebsd64-ods06 ods-enforcerd: Zone ods found. May 11 12:01:55 freebsd64-ods06 ods-enforcerd: Policy for ods set to default. May 11 12:01:55 freebsd64-ods06 ods-enforcerd: Config will be output to /home/jenkins/workspace/root/test/var/opendnssec/signconf/ods.xml. May 11 12:01:55 freebsd64-ods06 ods-enforcerd: Not enough keys to satisfy zsk policy for zone: ods May 11 12:01:55 freebsd64-ods06 ods-enforcerd: ods-enforcerd will create some more keys on its next run May 11 12:01:55 freebsd64-ods06 ods-enforcerd: Error allocating zsks to zone ods May 11 12:01:55 freebsd64-ods06 kernel: May 11 12:01:55 freebsd64-ods06 ods-enforcerd: Error allocating zsks to zone ods May 11 12:01:55 freebsd64-ods06 ods-enforcerd: Disconnecting from Database... May 11 12:01:55 freebsd64-ods06 ods-enforcerd: Sleeping for 3600 seconds. May 11 12:01:56 freebsd64-ods06 ods-enforcerd: Received SIGTERM, exiting... May 11 12:01:56 freebsd64-ods06 ods-enforcerd: SoftHSM: C_CloseSession: Calling May 11 12:01:56 freebsd64-ods06 ods-enforcerd: SoftHSM: C_CloseSession: OK May 11 12:01:56 freebsd64-ods06 ods-enforcerd: SoftHSM: C_Logout: Calling May 11 12:01:56 freebsd64-ods06 ods-enforcerd: SoftHSM: C_Logout: OK May 11 12:01:56 freebsd64-ods06 ods-enforcerd: SoftHSM: C_CloseSession: Calling May 11 12:01:57 freebsd64-ods06 kernel: pid 28320 (ods-enforcerd), uid 1002: exited on signal 11 (core dumped) #0 0x0000000801e36400 in _pthread_mutex_init_calloc_cb () from /lib/libc.so.7 [New Thread 802407400 (LWP 100105/)] [New LWP 100113] (gdb) bt #0 0x0000000801e36400 in _pthread_mutex_init_calloc_cb () from /lib/libc.so.7 #1 0x0000000801e3ead5 in free () from /lib/libc.so.7 #2 0x000000080130307e in sqlite3HashClear () from /usr/local/lib/libsqlite3.so.8 #3 0x000000080130ec60 in sqlite3SchemaClear () from /usr/local/lib/libsqlite3.so.8 #4 0x0000000801310c25 in sqlite3ResetInternalSchema () from /usr/local/lib/libsqlite3.so.8 #5 0x0000000801337522 in sqlite3_close () from /usr/local/lib/libsqlite3.so.8 #6 0x000000080211e38d in ~SoftDatabase (this=0x80257d160) at ../../../src/lib/SoftDatabase.cpp:105 #7 0x000000080211af6a in ~SoftSession (this=0x802418300) at ../../../src/lib/SoftSession.cpp:109 #8 0x000000080211a3a9 in SoftHSMInternal::closeSession (this=0x802503600, hSession=Variable "hSession" is not available. ) at ../../../src/lib/SoftHSMInternal.cpp:180 #9 0x000000000041b42e in hsm_session_close () #10 0x000000000041b4ff in hsm_ctx_close () #11 0x000000000041dff5 in hsm_close () #12 0x0000000000404b98 in server_main () #13 0x000000000040967b in main () From jerry at opendnssec.org Sun May 13 09:27:09 2012 From: jerry at opendnssec.org (=?ISO-8859-1?Q?Jerry_Lundstr=F6m?=) Date: Sun, 13 May 2012 11:27:09 +0200 Subject: [Opendnssec-develop] RE: Jenkins master server outage 11th & 12th May In-Reply-To: References: Message-ID: Hi Sara, I see that the Jenkins server isn't up yet, didn't go that well? On Thu, May 10, 2012 at 9:36 PM, Sara (Sinodun) wrote: > All, > > Due to planned maintenance work at the business park where our offices are located we will be without power from the evening of Friday 11th May until sometime in the afternoon of Saturday 12th May. As a result the jenkins master server will be offline for this period. We will send an email on the 12th when it is back online. From sara at sinodun.com Sun May 13 17:26:38 2012 From: sara at sinodun.com (Sara (Sinodun)) Date: Sun, 13 May 2012 18:26:38 +0100 Subject: Fwd: [Opendnssec-develop] RE: Jenkins master server outage 11th & 12th May References: <8F8A354C-DB24-4DD1-B061-5BB36EDC5759@sinodun.com> Message-ID: <96F1E980-9DF6-4FEB-9E92-92E5C5337A7E@sinodun.com> All, The power has only just been turned back on the - the outage was much longer than expected. Everything should be up and running now. Regards Sara. On 13 May 2012, at 10:27, Jerry Lundstr?m wrote: > Hi Sara, > > I see that the Jenkins server isn't up yet, didn't go that well? > > On Thu, May 10, 2012 at 9:36 PM, Sara (Sinodun) wrote: >> All, >> >> Due to planned maintenance work at the business park where our offices are located we will be without power from the evening of Friday 11th May until sometime in the afternoon of Saturday 12th May. As a result the jenkins master server will be offline for this period. We will send an email on the 12th when it is back online. From jakob at kirei.se Mon May 14 08:52:32 2012 From: jakob at kirei.se (Jakob Schlyter) Date: Mon, 14 May 2012 10:52:32 +0200 Subject: [Opendnssec-develop] default OpenDNSSEC username/group Message-ID: <6249C9CD-1B02-4714-836E-8CDDE1839B39@kirei.se> The default OpenDNSSEC username/group is "opendnssec", although it has been reported [1] that there are still systems around that do not support usernames longer than 8 characters. Should we change to "ods" and let package maintainers deal with any local changes? jakob [1] https://issues.opendnssec.org/browse/OPENDNSSEC-70 From sion at nominet.org.uk Mon May 14 09:05:54 2012 From: sion at nominet.org.uk (=?ISO-8859-1?Q?Si=F4n_Lloyd?=) Date: Mon, 14 May 2012 10:05:54 +0100 Subject: [Opendnssec-develop] Re: [Opendnssec-maintainers] default OpenDNSSEC username/group In-Reply-To: <6249C9CD-1B02-4714-836E-8CDDE1839B39@kirei.se> References: <6249C9CD-1B02-4714-836E-8CDDE1839B39@kirei.se> Message-ID: <4FB0CAF2.9070703@nominet.org.uk> On 14/05/12 09:52, Jakob Schlyter wrote: > The default OpenDNSSEC username/group is "opendnssec", although it has been reported [1] that there are still systems around that do not support usernames longer than 8 characters. Should we change to "ods" and let package maintainers deal with any local changes? > > jakob Do we know which systems and whether they are still on our list of supported OSs? (I notice that the original ticket is nearly 2 years old.) Sion From jerry at opendnssec.org Mon May 14 09:08:49 2012 From: jerry at opendnssec.org (=?iso-8859-1?Q?Jerry_Lundstr=F6m?=) Date: Mon, 14 May 2012 11:08:49 +0200 Subject: [Opendnssec-develop] ticket# in commit messages In-Reply-To: References: <2772CE68-6DE1-4D54-B2AD-ED76A0029148@kirei.se> <4F9019B0.7050909@nlnetlabs.nl> <965DBA9B-66F4-4ADF-AF94-31CEB8ECDD66@kirei.se> <52112936-A510-46FA-B1B4-7A5CAB03E7B3@surfnet.nl> Message-ID: Looks like I've got FishEye to understand JIRA and visa versa. There is a Source tab inside the issues now and you can see the issues in FishEye's activities. -- Jerry Lundstr?m - OpenDNSSEC Developer http://www.opendnssec.org/ From ondrej at sury.org Mon May 14 09:38:23 2012 From: ondrej at sury.org (=?UTF-8?B?T25kxZllaiBTdXLDvQ==?=) Date: Mon, 14 May 2012 11:38:23 +0200 Subject: [Opendnssec-develop] Re: [Opendnssec-maintainers] default OpenDNSSEC username/group In-Reply-To: <6249C9CD-1B02-4714-836E-8CDDE1839B39@kirei.se> References: <6249C9CD-1B02-4714-836E-8CDDE1839B39@kirei.se> Message-ID: I would keep the 'opendnssec' and let package maintainer and users of obscure system to deal with it. O. On Mon, May 14, 2012 at 10:52 AM, Jakob Schlyter wrote: > The default OpenDNSSEC username/group is "opendnssec", although it has been reported [1] that there are still systems around that do not support usernames longer than 8 characters. Should we change to "ods" and let package maintainers deal with any local changes? > > ? ? ? ?jakob > > > > [1] https://issues.opendnssec.org/browse/OPENDNSSEC-70 > > _______________________________________________ > Opendnssec-maintainers mailing list > Opendnssec-maintainers at lists.opendnssec.org > https://lists.opendnssec.org/mailman/listinfo/opendnssec-maintainers -- ?Ond?ej Sur? From olaf at NLnetLabs.nl Mon May 14 11:19:13 2012 From: olaf at NLnetLabs.nl (Olaf Kolkman) Date: Mon, 14 May 2012 13:19:13 +0200 Subject: [Opendnssec-develop] [Opendnssec-maintainers] default OpenDNSSEC username/group In-Reply-To: References: <6249C9CD-1B02-4714-836E-8CDDE1839B39@kirei.se> Message-ID: On May 14, 2012, at 11:38 AM, Ond?ej Sur? wrote: > I would keep the 'opendnssec' and let package maintainer and users of > obscure system to deal with it. +1 NLnet Labs Olaf M. Kolkman www.NLnetLabs.nl olaf at NLnetLabs.nl Science Park 400, 1098 XH Amsterdam, The Netherlands -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 841 bytes Desc: Message signed with OpenPGP using GPGMail URL: From rickard at opendnssec.org Mon May 14 12:00:41 2012 From: rickard at opendnssec.org (Rickard Bellgrim) Date: Mon, 14 May 2012 14:00:41 +0200 Subject: [Opendnssec-develop] Re: openbsd down and diabled in builds/tests In-Reply-To: <03396DF4-CD4D-4A87-BEFC-80B96DABFE26@opendnssec.org> References: <03396DF4-CD4D-4A87-BEFC-80B96DABFE26@opendnssec.org> Message-ID: On Thu, May 10, 2012 at 4:42 PM, Jerry Lundstr?m wrote: > On May 9, 2012, at 12:54 , Jerry Lundstr?m wrote: >> Will have to reinstall openbsd tomorrow and see if I can get it working again. > > > After a reinstall to 5.1 and 5 hours of compiling Java 1.6 its back and working! Nice! // Rickard From rickard at opendnssec.org Mon May 14 12:34:54 2012 From: rickard at opendnssec.org (Rickard Bellgrim) Date: Mon, 14 May 2012 14:34:54 +0200 Subject: [Opendnssec-develop] Feature proposal: Stop Enforcer action on given zone In-Reply-To: <4FACC85D.7070808@nominet.org.uk> References: <20120510224946.GA9666@newphantom.local> <4FACC85D.7070808@nominet.org.uk> Message-ID: >> Interesting proposal... Rick, I think it would be a good idea to create a story about this. Just so that we can keep track of it. > There may be questions on whether we need to reset any timers also, for > instance would we believe that a key has been published for 5 days if > the zone was frozen for most of that time? The Enforcer would only set the time for the next event, right? I believe we never can miss a state change because of this. If there is a state change, than any action would have been written to the signconf before the zone was frozen. // Rickard From rick at openfortress.nl Mon May 14 12:49:03 2012 From: rick at openfortress.nl (Rick van Rein) Date: Mon, 14 May 2012 12:49:03 +0000 Subject: [Opendnssec-develop] Meeting notes 2012-05-08 Message-ID: <20120514124903.GA30147@newphantom.local> Lady and Gentlemen, I placed the meeting notes of last week online; a bit later than usual, sorry about that. As always, please jump in and improve it as needed. https://wiki.opendnssec.org/display/OpenDNSSEC/Minutes+2012-05-08 Best wishes, -Rick From jerry at opendnssec.org Mon May 14 13:25:13 2012 From: jerry at opendnssec.org (=?iso-8859-1?Q?Jerry_Lundstr=F6m?=) Date: Mon, 14 May 2012 15:25:13 +0200 Subject: [Opendnssec-develop] OpenDNSSEC-1.3-multithread-enforcerd Message-ID: <74233C98-8561-4A05-9591-62B10E0A64AD@opendnssec.org> Hi, I'm done with the multithreading enforcer and it's a big improvement. Test with 1000 zones, without workers, ods-enforcerd -1: First run: 1 min 35 secs Second run: 57 secs Test with 1000 zones, with 8 threads on 4 cores, ods-enforcerd -1: First run: 19 secs Second run: 11 secs Now I would like some help with testing if everything is going okay, running the signer and maybe auditing everything for a while. Can anyone help? Cheers, Jerry svn checkout http://svn.opendnssec.org/home/jerry/OpenDNSSEC-1.3-multithread-enforcerd cd OpenDNSSEC-1.3-multithread-enforcerd sh autogen.sh ./configure --with-database-backend=mysql --enable-enforcer-workers make make install specify number of worker threads in conf.xml -> Enforcer -> WorkerThreads. -- Jerry Lundstr?m - OpenDNSSEC Developer http://www.opendnssec.org/ From jerry at opendnssec.org Mon May 14 13:33:15 2012 From: jerry at opendnssec.org (=?iso-8859-1?Q?Jerry_Lundstr=F6m?=) Date: Mon, 14 May 2012 15:33:15 +0200 Subject: [Opendnssec-develop] code review needed: KsmParameterCollectionCache() Message-ID: Hi, As me and Pawal have been testing 50.000 zones I noticed that KsmParameterCollection() gets called a lot in do_communication(), for each zones processed it was called a few times and each time it did ~20 sql calls. Even if it will hit the SQL cache 99.9% of the time it still takes times to make the queries and send them, SQL backend need to parse them and so on. This patch makes a cache of the latest KSM_PARCOLL fetched and will just memcpy() it if its the same policy fetch again. It reduces the load in the SQL backend and my tests shows some 20-30% performance gain. Can someone else review the change and the surrounding code before I commit it? And if you don't like the change please comment. http://svn.opendnssec.org/home/jerry/opendnssec-1.3.8-ksmparametercollectioncache.diff /Jerry -- Jerry Lundstr?m - OpenDNSSEC Developer http://www.opendnssec.org/ From jerry at opendnssec.org Tue May 15 12:46:28 2012 From: jerry at opendnssec.org (=?iso-8859-1?Q?Jerry_Lundstr=F6m?=) Date: Tue, 15 May 2012 14:46:28 +0200 Subject: [Opendnssec-develop] =?iso-8859-1?q?Fwd=3A_=5BOpendnssec-commits?= =?iso-8859-1?q?=5D_test-opendnssec-1=2E3_=BB_freebsd64-ods06_-_Build_=23_?= =?iso-8859-1?q?93_-_Fixed!?= References: <1565353714.3.1337085861662.JavaMail.jenkins@opendnssec.sinodun.com> Message-ID: <6EC4609C-7F17-4EA7-92C6-26F958F370A3@opendnssec.org> !!! :) I received a new ports package for sqlite 3.7.12 by Pavel Volkov and it seems to have fixed the problem. Begin forwarded message: > > From: jenkins at opendnssec.org > Subject: [Opendnssec-commits] test-opendnssec-1.3 ? freebsd64-ods06 - Build # 93 - Fixed! > Date: May 15, 2012 14:44:15 GMT+02:00 > To: opendnssec-commits at lists.opendnssec.org > > test-opendnssec-1.3 ? freebsd64-ods06 - Build # 93 - Fixed: > > Check console output at https://jenkins.opendnssec.org/job/test-opendnssec-1.3/./label=freebsd64-ods06/93/ to view the results. > > BUILD LOG: > ##### 1/32 00-start-and-stop ... OK > ##### 2/32 10-010-odscc10t10 ... OK > ##### 3/32 10-020-odscc10t20 ... OK > ##### 4/32 10-030-odscc10t30 ... OK > ##### 5/32 10-040-odscc10t40 ... OK > ##### 6/32 10-050-odscc10t50 ... OK > ##### 7/32 10-060-odscc10t60 ... OK > ##### 8/32 10-070-odscc10t70 ... OK > ##### 9/32 10-080-odscc10t80 ... OK > ##### 10/32 10-090-odscc10t90 ... OK > ##### 11/32 10-100-odscc10t100 ... OK > ##### 12/32 10-110-odscc10t110 ... OK > ##### 13/32 10-120-odscc10t120 ... OK > ##### 14/32 10-130-odscc10t130 ... OK > ##### 15/32 10-150-odscc10t150 ... OK > ##### 16/32 10-160-odscc10t160 ... OK > ##### 17/32 20-010-odscc20t10 ... OK > ##### 18/32 20-020-odscc20t20 ... OK > ##### 19/32 20-030-odscc20t30 ... OK > ##### 20/32 20-040-odscc20t40 ... OK > ##### 21/32 20-050-odscc20t50 ... OK > ##### 22/32 30-030-odscc30t30 ... OK > ##### 23/32 30-040-odscc30t40 ... OK > ##### 24/32 40-010-odscc40t10 ... OK > ##### 25/32 40-040-odscc40t40 ... OK > ##### 26/32 40-060-odscc40t60 ... OK > ##### 27/32 40-080-odscc40t80 ... OK > ##### 28/32 40-100-odscc40t100 ... OK > ##### 29/32 50-030-odscc50t30 ... OK > ##### 30/32 50-040-odscc50t40 ... OK > ##### 31/32 50-050-odscc50t50 ... OK > ##### 32/32 50-060-odscc50t60 ... OK > > _______________________________________________ > Opendnssec-commits mailing list > Opendnssec-commits at lists.opendnssec.org > https://lists.opendnssec.org/mailman/listinfo/opendnssec-commits -- Jerry Lundstr?m - OpenDNSSEC Developer http://www.opendnssec.org/ From ondrej at sury.org Thu May 17 10:27:17 2012 From: ondrej at sury.org (=?UTF-8?B?T25kxZllaiBTdXLDvQ==?=) Date: Thu, 17 May 2012 12:27:17 +0200 Subject: [Opendnssec-develop] OpenDNSSEC 1.4.0a2? Message-ID: Hi, is there an ETA for alpha2? I feel that trunk now has many bugfixes, so it might be a good idea, just to pack whatever is in trunk and release it as alpha2, so the fixes get to the early testers. O. -- ?Ond?ej Sur? From matthijs at nlnetlabs.nl Fri May 18 07:32:43 2012 From: matthijs at nlnetlabs.nl (Matthijs Mekking) Date: Fri, 18 May 2012 09:32:43 +0200 Subject: [Opendnssec-develop] OpenDNSSEC 1.4.0a2? In-Reply-To: References: Message-ID: <4FB5FB1B.6050201@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Ondrej, We usually decide on the release of a new version on our regularly teleconferences. The next is Tuesday, 22 May. I assume we will make a decision then. I am all in favor of doing a new release. However, we might do a beta1, since there will be no feature changes for 1.4.0. Best regards, Matthijs On 05/17/2012 12:27 PM, Ond?ej Sur? wrote: > Hi, > > is there an ETA for alpha2? I feel that trunk now has many > bugfixes, so it might be a good idea, just to pack whatever is in > trunk and release it as alpha2, so the fixes get to the early > testers. > > O. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJPtfsYAAoJEA8yVCPsQCW53j8IAKbQbYHrao16MAQ/ujG16siI klIMva4giTOC9THoyRi+Wjym4wXSavurw3dqqY81RY4f8jeJCAC9eeBO+UStPeqe KfcIRYfqmMR/SiZ/T034o43UsZEORt//yTqHULUYJ4Ygn71bqpYhE3opzHMVcO9o DjCsLV1l4wA0izyt5mP6z+4gHp4aPhwVamsOYG/TpjehkcMOclhh7zJI1JIBhsXm y6LJ+udy+tM9z5ZG7aRwWj6nlthEr0M0MRXs1AmMMCafFWUWfx18zNWwM0hKQq78 1Ilira4X/xTw9SjKQJfjxVNqOYpJmTMBd758n89/5WIvMgR9EmbwSOxdtr56grM= =OT2C -----END PGP SIGNATURE----- From jerry at opendnssec.org Mon May 21 05:18:17 2012 From: jerry at opendnssec.org (=?ISO-8859-1?Q?Jerry_Lundstr=F6m?=) Date: Mon, 21 May 2012 07:18:17 +0200 Subject: [Opendnssec-develop] Away on holiday, back 4th jun Message-ID: <8488543054466269437@unknownmsgid> Will check emails from time to time. Cheers! Jerry From rickard at opendnssec.org Mon May 21 14:19:01 2012 From: rickard at opendnssec.org (Rickard Bellgrim) Date: Mon, 21 May 2012 16:19:01 +0200 Subject: [Opendnssec-develop] Meeting 2012-05-22 Message-ID: Hi We have a scheduled meeting tomorrow. Date: Tuesday 22 May Time: 14:00-15:00 CEST, 13:00-14:00 BST The agenda can be found here: https://wiki.opendnssec.org/display/OpenDNSSEC/2012-05-22+Agenda // Rickard From sara at sinodun.com Tue May 22 16:57:51 2012 From: sara at sinodun.com (Sara Dickinson) Date: Tue, 22 May 2012 17:57:51 +0100 Subject: [Opendnssec-develop] Meeting 2012-05-22 minutes In-Reply-To: References: Message-ID: <6818ADF9-52E3-4728-A0D9-6BDAA625CA82@sinodun.com> Hi, Minutes from the meeting today are available: https://wiki.opendnssec.org/display/OpenDNSSEC/2012-05-22+Minutes Please check and correct as required! Action points summary: Patrik: Conduct a survey on the user's list, perhaps with voting. (What platforms are the users using?). [Rolled over from last meeting] Sion: Do additional testing on the multi-threaded enforcer patch. Rickard/Jakob: Go ahead with alpha 2 release of 1.4. Matthijs: Ensure that all user reported issues fixed or under investigation in 1.4 are tracked with a Jira issue. Rickard: Set up a wiki page where people can record there availability to help with scheduling meetings. Sara: Produce agenda and chair the next team meeting. Sara. On 21 May 2012, at 15:19, Rickard Bellgrim wrote: > Hi > > We have a scheduled meeting tomorrow. > > Date: Tuesday 22 May > Time: 14:00-15:00 CEST, 13:00-14:00 BST > > The agenda can be found here: > https://wiki.opendnssec.org/display/OpenDNSSEC/2012-05-22+Agenda > > // Rickard > _______________________________________________ > Opendnssec-develop mailing list > Opendnssec-develop at lists.opendnssec.org > https://lists.opendnssec.org/mailman/listinfo/opendnssec-develop -------------- next part -------------- An HTML attachment was scrubbed... URL: From jerry at opendnssec.org Tue May 22 19:51:54 2012 From: jerry at opendnssec.org (=?ISO-8859-1?Q?Jerry_Lundstr=F6m?=) Date: Tue, 22 May 2012 15:51:54 -0400 Subject: [Opendnssec-develop] Meeting 2012-05-22 minutes In-Reply-To: <6818ADF9-52E3-4728-A0D9-6BDAA625CA82@sinodun.com> References: <6818ADF9-52E3-4728-A0D9-6BDAA625CA82@sinodun.com> Message-ID: <5877282039927088055@unknownmsgid> 1. *Next meeting *Since several people could not make the 5th May next meeting will be in 3 weeks on 12th May at the normal time of 14:00 CEST.* * I can't fix this remote but I guess you mean June :) /Jerry On 22 maj 2012, at 12:57, Sara Dickinson wrote: Hi, Minutes from the meeting today are available: https://wiki.opendnssec.org/display/OpenDNSSEC/2012-05-22+Minutes Please check and correct as required! Action points summary: *Patrik: *Conduct a survey on the user's list, perhaps with voting. (What platforms are the users using?). [Rolled over from last meeting] *Sion: *Do additional testing on the multi-threaded enforcer patch. *Rickard/Jakob*: Go ahead with alpha 2 release of 1.4. *Matthijs:* Ensure that all user reported issues fixed or under investigation in 1.4 are tracked with a Jira issue. *Rickard*: Set up a wiki page where people can record there availability to help with scheduling meetings. *Sara*: Produce agenda and chair the next team meeting. Sara. On 21 May 2012, at 15:19, Rickard Bellgrim wrote: Hi We have a scheduled meeting tomorrow. Date: Tuesday 22 May Time: 14:00-15:00 CEST, 13:00-14:00 BST The agenda can be found here: https://wiki.opendnssec.org/display/OpenDNSSEC/2012-05-22+Agenda // 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthijs at nlnetlabs.nl Tue May 22 20:35:10 2012 From: matthijs at nlnetlabs.nl (Matthijs Mekking) Date: Tue, 22 May 2012 22:35:10 +0200 Subject: [Opendnssec-develop] Meeting 2012-05-22 minutes In-Reply-To: <6818ADF9-52E3-4728-A0D9-6BDAA625CA82@sinodun.com> References: <6818ADF9-52E3-4728-A0D9-6BDAA625CA82@sinodun.com> Message-ID: <4FBBF87E.1060702@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Sara, On the topic of 'Can we release OpenDNSSEC 1.4.0', you noted: Agreed that the next release should be alpha 2 rather than a beta. Reasons were that quite a lot of functionality has changed since the alpha 1 and there are still some open issues that should be fixed for a beta. Also the enforcer patch may be pushed to 1.4. There has not been a lot of functionality changes since the alpha 1. In That is why we argued if we could do a beta 1 release. Nevertheless, the enforcer patch may be pushed to 1.4 and that's the reason why we decided on an alpha 2 release rather than a beta, since that is considered new functionality. At least that is how I interpreted it. Best regards, Matthijs On 05/22/2012 06:57 PM, Sara Dickinson wrote: > Hi, > > Minutes from the meeting today are available: > > https://wiki.opendnssec.org/display/OpenDNSSEC/2012-05-22+Minutes > > Please check and correct as required! > > Action points summary: > > **Patrik:* *Conduct a survey on the user's list, perhaps with > voting. (What platforms are the users using?). [Rolled over from > last meeting] *Sion: *Do additional testing on the multi-threaded > enforcer patch. *Rickard/Jakob*: Go ahead with alpha 2 release of > 1.4. *Matthijs:* Ensure that all user reported issues fixed or > under investigation in 1.4 are tracked with a Jira issue. > *Rickard*: Set up a wiki page where people can record there > availability to help with scheduling meetings. *Sara*: Produce > agenda and chair the next team meeting. > > Sara. > > > On 21 May 2012, at 15:19, Rickard Bellgrim wrote: > >> Hi >> >> We have a scheduled meeting tomorrow. >> >> Date: Tuesday 22 May Time: 14:00-15:00 CEST, 13:00-14:00 BST >> >> The agenda can be found here: >> https://wiki.opendnssec.org/display/OpenDNSSEC/2012-05-22+Agenda >> >> // 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 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJPu/h6AAoJEA8yVCPsQCW59FQIAKuA7zkGfBrpgrdrEJS6zZXd jKk4pNGidubhMhj7s8XwnmhQID7PWIMDQkqAPv0+ziaQeDwJMK/FwZd1rh2edON1 VU2lYPF6AxQ/IKAX39yXglduiZUrtP4h0x9gNKWAiTPYUfBDzuq7Z/vrUajnTGdM KkwP4E9kkftzbH9qpUu3A5Qe20KqIeKheANOoydcd00NXsn+D50bkxrRLlOEsjTP 2uD04IgI9l5SJ17eulzrn+RtmLstS2WZrHm0bqvYjETrDud5BQXOalB5M43ap85V uKdWbJxpXUnb+cOfCdom0w1rw2+F8ViTfX34LagCmYDfcjh9lMX4Cm5yoxP5DIo= =oNnk -----END PGP SIGNATURE----- From AlexD at nominet.org.uk Wed May 23 08:20:18 2012 From: AlexD at nominet.org.uk (Alex Dalitz) Date: Wed, 23 May 2012 08:20:18 +0000 Subject: [Opendnssec-develop] Re: [Opendnssec-user] Key has gone straight to active use .. In-Reply-To: <4FBC9BF2.2050401@nlnetlabs.nl> References: <20120518133405.GD23146@dot.freshdot.net> <4FB9FA34.4000003@nlnetlabs.nl> <20120522083713.GG25088@dot.freshdot.net> <4FBC9BF2.2050401@nlnetlabs.nl> Message-ID: On 23 May 2012, at 09:12, Matthijs Mekking wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > It would be nice if the auditor had a 'clear state' command (e.g. > remove all files related to a particular zone from the auditor working > directory 'tracker'). > I note that this feature would not help the reported problem. Clearing the state would mean that the auditor loses all history of a zone - which would cause problems, rather than obviate problems. Thanks, Alex. From matthijs at nlnetlabs.nl Wed May 23 08:50:35 2012 From: matthijs at nlnetlabs.nl (Matthijs Mekking) Date: Wed, 23 May 2012 10:50:35 +0200 Subject: [Opendnssec-develop] Re: [Opendnssec-user] Key has gone straight to active use .. In-Reply-To: References: <20120518133405.GD23146@dot.freshdot.net> <4FB9FA34.4000003@nlnetlabs.nl> <20120522083713.GG25088@dot.freshdot.net> <4FBC9BF2.2050401@nlnetlabs.nl> Message-ID: <4FBCA4DB.3080802@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 05/23/2012 10:20 AM, Alex Dalitz wrote: > > On 23 May 2012, at 09:12, Matthijs Mekking wrote: > >> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >> >> It would be nice if the auditor had a 'clear state' command >> (e.g. remove all files related to a particular zone from the >> auditor working directory 'tracker'). >> > > I note that this feature would not help the reported problem. > Clearing the state would mean that the auditor loses all history of > a zone - which would cause problems, rather than obviate problems. rm -rf tracker was how we fixed the issue for secret-wg.org. After that, the zone was published and the auditor did not raise problems anymore. Best regards, Matthijs > > Thanks, > > > Alex. > > _______________________________________________ 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/ iQEcBAEBAgAGBQJPvKTbAAoJEA8yVCPsQCW5Ab4IAMOeC4IJ0b2jZnUTBMdWKM03 HLRnaQRZ7+Iy6sF2AXFZsUbVi5ivTru1tnEQEQMHYkGCQER34MUHe6ZHecemM42I e8giJRNJmEHUf6pfGdeauODj1rG9xKVL5DLnE4r1U2nn7T3HLbt1g3G/STzlIdUx HCiBsLoT8eOhyyh99IRj1Iv2Mnri3TvmQwCNnD4gQ8KaeDgv2C6/vx2ISsn/uvB6 iSfKvc/+Lzb0szgUGhksJBFDiG0Pj9YKwwz9R2sKMUdu3iJkiypp1WdFxIl2rLsY Mm7Xm4cKcXztDAkvW7rLqWpNEySBvdysZJCIt2FyuOTfoKpX0ax81o9DQVv83ko= =YXlq -----END PGP SIGNATURE----- From matthijs at nlnetlabs.nl Wed May 23 09:02:49 2012 From: matthijs at nlnetlabs.nl (Matthijs Mekking) Date: Wed, 23 May 2012 11:02:49 +0200 Subject: [Opendnssec-develop] Meeting 2012-05-22 minutes In-Reply-To: <6818ADF9-52E3-4728-A0D9-6BDAA625CA82@sinodun.com> References: <6818ADF9-52E3-4728-A0D9-6BDAA625CA82@sinodun.com> Message-ID: <4FBCA7B9.4080000@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 05/22/2012 06:57 PM, Sara Dickinson wrote: > *Matthijs:* Ensure that all user reported issues fixed or under > investigation in 1.4 are tracked with a Jira issue. I have added all reports from the user list related to 1.4 in the issue tracker. I wanted to add new versions 1.4.0a2 and 1.4.0b1, but I could not find where, or maybe I am unprivileged. Sion, I created an issue for the report (OPENDNSSEC-266) with the subject: opendnssec-1.4.0a1 does not run DelegationSignerSubmitCommand? Please feel free to close it if you think this is a non-issue. Best regards, Matthijs -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJPvKe5AAoJEA8yVCPsQCW52MQH/A5ChFYX57pBOhz6Qa5bM1oL fldqXbjniC/utVQrbmbanT/aZeJZIm9NfalSmyyMGiFqiZg4BMXQcrAv7reRu2Sm l2+6DbKkRzNXdIg57JZQ0CKUUyBg4PgCaffTDrdUe+KcGrxO3NlirjOkLaYS1TAg aQ/vJPmrtnoqS2xPK686+VvPU+SKG4EQ65GsG4o7WafhseFUpH6TnAEoN/9s0X5O Sb1KGA9TFta4FjxT2yWMJ6iAYWi6vwE5+HGKoZiDkPyvdDzY15Gc6N/SwvrPDIO8 AthIYOhpOlhu+5PmLbJNZxftavbfrkaSCOSKwDKVhX9+7TV0toPjqWRYzTRJU8k= =mYha -----END PGP SIGNATURE----- From rickard at opendnssec.org Thu May 24 10:34:21 2012 From: rickard at opendnssec.org (Rickard Bellgrim) Date: Thu, 24 May 2012 12:34:21 +0200 Subject: [Opendnssec-develop] Meeting 2012-05-22 minutes In-Reply-To: <4FBCA7B9.4080000@nlnetlabs.nl> References: <6818ADF9-52E3-4728-A0D9-6BDAA625CA82@sinodun.com> <4FBCA7B9.4080000@nlnetlabs.nl> Message-ID: > I have added all reports from the user list related to 1.4 in the > issue tracker. I wanted to add new versions 1.4.0a2 and 1.4.0b1, but I > could not find where, or maybe I am unprivileged. Fixed From rickard at opendnssec.org Thu May 24 10:45:04 2012 From: rickard at opendnssec.org (Rickard Bellgrim) Date: Thu, 24 May 2012 12:45:04 +0200 Subject: [Opendnssec-develop] OpenDNSSEC 1.4.0a2 Message-ID: Hi Jakob, you can proceed with releasing 1.4.0a2 // Rickard From matthijs at nlnetlabs.nl Thu May 24 12:46:14 2012 From: matthijs at nlnetlabs.nl (Matthijs Mekking) Date: Thu, 24 May 2012 14:46:14 +0200 Subject: [Opendnssec-develop] OpenDNSSEC 1.4.0a2 In-Reply-To: References: Message-ID: <4FBE2D96.4030204@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Maybe we can sneak in one more fix into the alpha 2: * Sign NOTIFY OK response with TSIG if configured. Best regards, Matthijs On 05/24/2012 12:45 PM, Rickard Bellgrim wrote: > Hi > > Jakob, you can proceed with releasing 1.4.0a2 > > // 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/ iQEcBAEBAgAGBQJPvi2WAAoJEA8yVCPsQCW574IH/RHgf7ucQdVPyHjcdTFnIEQy NkXH7xU7uRjn9ysBdnsCkFAF5ZrwTZIKmfsgsIJ8vnN+cxLOwOoUeTabEKuwgQlX NyhI0oP53WSV+WEiaTqOPk6h53PyGOinmCCq79g6e4hchRFr5HnBa3344WCFZs/N Vci54SV1Nue1E0EQ9HtEjfrrcQVl16vH153Qstp/kvltitr8kIsTSsTkXIyA5KMs fVsfw/Wwo+ONlPZC772lxRf/pP5cx8m86JhG0RTLPZUSTlLSoWNKnJt4X9hDzEg3 OAKnyHX07FEZwNZZ/Z0Rby06gxdanb678qeAL6O4K2GrHPkVaApJ2QTxkqRyBVk= =6O2C -----END PGP SIGNATURE----- From matthijs at nlnetlabs.nl Thu May 24 13:24:52 2012 From: matthijs at nlnetlabs.nl (Matthijs Mekking) Date: Thu, 24 May 2012 15:24:52 +0200 Subject: [Opendnssec-develop] OpenDNSSEC 1.4.0a2 In-Reply-To: <4FBE2D96.4030204@nlnetlabs.nl> References: <4FBE2D96.4030204@nlnetlabs.nl> Message-ID: <4FBE36A4.2040703@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Done. On 05/24/2012 02:46 PM, Matthijs Mekking wrote: > Maybe we can sneak in one more fix into the alpha 2: > > * Sign NOTIFY OK response with TSIG if configured. > > Best regards, Matthijs > > On 05/24/2012 12:45 PM, Rickard Bellgrim wrote: >> Hi > >> Jakob, you can proceed with releasing 1.4.0a2 > >> // 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 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJPvjakAAoJEA8yVCPsQCW5iV4IAJAG0ZrTx4p3WLpvaqtiQzSc 5G1txuKopN/5e72Cr2dYfZt5FFjsCvscZindbeWGa6HuohKGx8aLo5L1vnohOJt1 vhAtHnjKv5Lpb1NG9Ljlv7A9Qm+NyeIvuIXF+sdMIoOZ88ce4VlSXr8NiUF0whwu VDPKdziQ1GRsMxxXCmo6ot/S18A2z4HscyD6IBbLvI7I9U0mDDig1q/5pCKR8ahx l0h2BDFdXH5iHmYw5sVnaOalnnG+v8lWfSLgv0wTshKnYF6xBq0oRMM1d8JSj4Zb YDBvBHerJevTI3a/dICRYCDH78/MMjgsiNwchHiJa+3RWhIyYrwMZVVv9urt8k8= =RtKE -----END PGP SIGNATURE----- From jakob at kirei.se Thu May 24 16:38:18 2012 From: jakob at kirei.se (Jakob Schlyter) Date: Thu, 24 May 2012 18:38:18 +0200 Subject: [Opendnssec-develop] OpenDNSSEC 1.4.0a2 In-Reply-To: References: Message-ID: On 24 maj 2012, at 12:45, Rickard Bellgrim wrote: > Jakob, you can proceed with releasing 1.4.0a2 tagged! j From rickard at opendnssec.org Fri May 25 06:22:13 2012 From: rickard at opendnssec.org (Rickard Bellgrim) Date: Fri, 25 May 2012 08:22:13 +0200 Subject: [Opendnssec-develop] OpenDNSSEC 1.4.0a2 In-Reply-To: References: Message-ID: On Thu, May 24, 2012 at 6:38 PM, Jakob Schlyter wrote: > On 24 maj 2012, at 12:45, Rickard Bellgrim wrote: > >> Jakob, you can proceed with releasing 1.4.0a2 > > tagged! Thanks... But I did not find the tarball (there was one for 1.4.0a1) From rickard at opendnssec.org Tue May 29 06:06:51 2012 From: rickard at opendnssec.org (Rickard Bellgrim) Date: Tue, 29 May 2012 08:06:51 +0200 Subject: [Opendnssec-develop] OpenDNSSEC 1.4.0a2 In-Reply-To: References: Message-ID: > Thanks... But I did not find the tarball (there was one for 1.4.0a1) Ping From jakob at kirei.se Tue May 29 07:13:38 2012 From: jakob at kirei.se (Jakob Schlyter) Date: Tue, 29 May 2012 09:13:38 +0200 Subject: [Opendnssec-develop] OpenDNSSEC 1.4.0a2 In-Reply-To: References: Message-ID: <56EB0F18-2793-4552-AD7F-FA127977EAE6@kirei.se> http://www.opendnssec.org/files/source/testing/opendnssec-1.4.0a2.tar.gz sorry for the delay, kind of missed we did tar-balls of alphas. j From rickard at opendnssec.org Tue May 29 07:38:11 2012 From: rickard at opendnssec.org (Rickard Bellgrim) Date: Tue, 29 May 2012 09:38:11 +0200 Subject: [Opendnssec-develop] OpenDNSSEC 1.4.0a2 In-Reply-To: <56EB0F18-2793-4552-AD7F-FA127977EAE6@kirei.se> References: <56EB0F18-2793-4552-AD7F-FA127977EAE6@kirei.se> Message-ID: On Tue, May 29, 2012 at 9:13 AM, Jakob Schlyter wrote: > http://www.opendnssec.org/files/source/testing/opendnssec-1.4.0a2.tar.gz > > sorry for the delay, kind of missed we did tar-balls of alphas. No problem. I now checked the release process and could not find any clear distinction between the alpha releases and the final releases w.r.t tarballs. Perhaps we need to clarify that? // Rickard From rick at openfortress.nl Tue May 29 10:59:40 2012 From: rick at openfortress.nl (Rick van Rein) Date: Tue, 29 May 2012 10:59:40 +0000 Subject: [Opendnssec-develop] Proposal: View-based Maintenance Support Message-ID: <20120529105939.GB15435@newphantom.local> Hello, A while back I proposed an approach to views [1] in OpenDNSSEC that was appreciated. I'd like to add a few ideas that I think would make OpenDNSSEC much easier to handle for admins, without adding a lot of complexity to it. It's a set, so this is a somewhat long email. [1] by identifying a zone with zone name + custom view label instead of just by zone name. ** Experimenting in Zone Views The basic idea that I had, was that views might be useful to experiment with difficult (manual) zone changes. For instance, to practice a key rollover procedure and see where things (could) go wrong. Anything outside the usual line of action is very hard with OpenDNSSEC, and scary to do on live data. Experimenting in a view could solve this, if a view is setup as a test environment. It is possible to define a test zone, but nothing beats being able to do it with the same zone and data as is used "live". ** Views as a Rollback Option It would be tremendously useful if there was a rollback operation for difficult manual changes to OpenDNSSEC. But some operations are hard or impossible to reverse, notably the removal of keys from a zone. (I've reversed such things in MySQL, but that is not how it should be.) If the previous version of a zone is retained in another view, then it should take little effort to conduct a rollback; notably, it would not require any involvement from OpenDNSSEC, the admin can resort to simple zone file references in his name server configuration; even if that has a risk of temporarily going bogus, it may still be pleasant to know to have as an emergency break. ** Operation: Forking or Splitting Zone Views To support this more flexible style of manamgent, OpenDNSSEC should support a "fork" operation that basically clones a zone into that same zone with another view label. After that, two views exist that start off with the same key information. I think "split" might be a better name than "fork", to mirror the proposed "merge" below. Technicalities that I would expect here deal with sharing key state when it develops, or splitting the management at the time of the view split, basically appear as if a copy of a key is made. There are probably use cases for both approaches, so that the user may be forced to choose. This may even be useful at a per-key level? ** Operations: Freezing and Defrosting a Zone View I've proposed operations to freeze and unfreeze/defrost Enforcer operation on individual zones, while staying active on others. With views added, I suppose it would be useful to perform such operations not on an entire zone, but on individual views as well. When splitting views, this state would be copied along with the rest. One useful application of this is to first freeze a zone or view, then to split off another view, defrost and develop the public one and keep the other frozen as a rollback option. Another useful application could be to first freeze a zone or view, then to split off another view, develop the _private_ view and when it passes all tests, migrate what is public to that new view, and then defrost the whole thing. The previous public one could be kept kept for some time as a rollback option, and deleted when the admin is happy and feeling secure. ** NG Operation: Migrating between Zone Views When views are split for management reasons, it is also useful to have means of reuniting them. Something that I would expect to be possible with the self-controlling manners of Enforcer NG is to say "I know you are now acting according to view A, but I want you to migrate into the situation of view B". The Enforcer NG could then start to drop keys and introduce new ones in their place. Its internal logic would keep it from going bogus. This could be useful to do complex things such as policy changes, including those needed to stay up to pace with secure algorithm preferences. Rather than doing this live, one could setup a test environment, run it against whatever caches one would be interested in, perhaps have the auditor take a stab at it, and so on. When all looked well, one could ask the Enforcer NG to migrate to the new situation, and it would gracefully adopt the new policy, no matter what had been changed in the new policy. ** Operation: Merging Zone Views This is arguably the most difficult part. But as shown above, useful scenarios also exist without it. So this could be a future addition even if the rest was already implemented. In both the old and new Enforcer, it would be pleasant to have some way of merging one view into another one. The whole procedure would probably fall apart in these three stages: 1. Introduce RRSIGs with DNSKEYs that introduce new algorithms 2. Introduce new DNSKEYs 3. Introduce RRSIGs for the rest of the DNSKEYs Note that it does not matter that the signer produces different RRSIGs for different views; as long as the same keys sign for the same data, the independently made RRSIG could even replace each other without breaking a thing. But they won't if views are the basis for merging. Also note that this adds keys, but does not remove older material; that would be done through (manually initiated?) key rollovers. Signing the same data may in some cases be important? But when merging zones, I can think of no reason why you would want to use different data sources [2]. So a check on matching zone origins, as would naturally arise from a zone split, would seem to be a warranted precondition. [2] Although I'm still puzzled about secure zone transfers. I hope this is useful! Cheers, -Rick -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 274 bytes Desc: Digital signature URL: From sara at sinodun.com Tue May 29 11:07:18 2012 From: sara at sinodun.com (Sara Dickinson) Date: Tue, 29 May 2012 12:07:18 +0100 Subject: [Opendnssec-develop] OpenDNSSEC 1.4.0a2 In-Reply-To: References: <56EB0F18-2793-4552-AD7F-FA127977EAE6@kirei.se> Message-ID: Hi, My thoughts would be that since producing tarballs isn't a great overhead then the benefit of making is easier for users to test the alpha makes it worth doing? Other comments on the updated Release process: - I would like to see the code review at the top of the list - in fact it could be argued this should be part of the development/pre-release process, not the release process since it is the responsibility of the developers not the person doing the release - Are any code integrity tools run regularly e.g. Coverity? It seems like this should be done before a major and probably a minor release after code review updates. - Given the above it should be clear exactly who does what. We could define a "Release Manager" role. - I think it the process could clarify more between minor/major/patch releases (e.g. in terms of documentation and package maintenance) - Step 6. Seems like it would be better if a single person did all the announce updates - seems to make sense that this is the Project Manager? IMHO it would also be nice to have a release criteria defined e.g. no open blocker/critical bugs and all open major bugs have workarounds. Any thoughts on this? I can take a pass at updating the process after some feedback on the above..... One more thought on the Release Engineering process defined in step 5 - could steps 4,5 and 6 of this be automated in a Jenkins job that is run manually? Sara. On 29 May 2012, at 08:38, Rickard Bellgrim wrote: > On Tue, May 29, 2012 at 9:13 AM, Jakob Schlyter wrote: >> http://www.opendnssec.org/files/source/testing/opendnssec-1.4.0a2.tar.gz >> >> sorry for the delay, kind of missed we did tar-balls of alphas. > > No problem. I now checked the release process and could not find any > clear distinction between the alpha releases and the final releases > w.r.t tarballs. Perhaps we need to clarify that? > > // 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 May 29 12:21:32 2012 From: jerry at opendnssec.org (=?ISO-8859-1?Q?Jerry_Lundstr=F6m?=) Date: Tue, 29 May 2012 08:21:32 -0400 Subject: [Opendnssec-develop] OpenDNSSEC 1.4.0a2 In-Reply-To: References: <56EB0F18-2793-4552-AD7F-FA127977EAE6@kirei.se> Message-ID: <4438385824100448327@unknownmsgid> Hi, On 29 maj 2012, at 07:07, Sara Dickinson wrote: > One more thought on the Release Engineering process defined in step 5 - could steps 4,5 and 6 of this be automated in a Jenkins job that is run manually? No, the nodes are not enough secure for this and they should not have any important function so they can be reinstalled. The tar balls should be uploaded by individuals for tracking and not by a robot that many people will have access to. Also the release process page needs an update since Jakob addad a make release script that should be run so anyone making a release has the right options to configure. /Jerry From sion at nominet.org.uk Tue May 29 12:37:25 2012 From: sion at nominet.org.uk (=?ISO-8859-1?Q?Si=F4n_Lloyd?=) Date: Tue, 29 May 2012 13:37:25 +0100 Subject: [Opendnssec-develop] OpenDNSSEC 1.4.0a2 In-Reply-To: References: <56EB0F18-2793-4552-AD7F-FA127977EAE6@kirei.se> Message-ID: <4FC4C305.8040604@nominet.org.uk> On 29/05/12 12:07, Sara Dickinson wrote: > - Are any code integrity tools run regularly e.g. Coverity? It seems like this should be done before a major and probably a minor release after code review updates. > We used to run the code through coverity prevent on the nominet licence. I'm not sure if we still have it covered; I'll see if I can find out. Sion From matthijs at nlnetlabs.nl Wed May 30 07:32:04 2012 From: matthijs at nlnetlabs.nl (Matthijs Mekking) Date: Wed, 30 May 2012 09:32:04 +0200 Subject: [Opendnssec-develop] Re: Adapter configuration In-Reply-To: <4FBF8116.2000900@nic.cz> References: <4FBF8116.2000900@nic.cz> Message-ID: <4FC5CCF4.30801@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Dan, [cc'ing the OpenDNSSEC Developers] On 05/25/2012 02:54 PM, Daniel Salzman wrote: > Hi Matthijs, > > I'm playing with ods again. It would be nice if: - Peer element > needn't contain Prefix if Key is present. I agree it would be nice to have ACL just on TSIG key. > - It doesn't depend on the order of items (Port after Key in > Remote). I agree, but I am not likely to change. This makes the XML file structure complicated, and comparing to other configuration files it is no different: order of items is important. We would like to have a different way to configure stuff, instead of using your favorite text editor. > - ods-kaspcheck can check adapter files. I agree, that might be useful too. > > Btw the link to OpenDNSSEC-1.4.0a2 doesn't work. I believe that has been fixed a couple of days ago. Best regards, Matthijs > > Regards, Dan -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJPxcz0AAoJEA8yVCPsQCW57TMH/Aze+j79YlU8XTEjKw50oPed JQVBoTxjDq6+5TMaBSEScNjwelUvaiXOunIXLaDhlz4FU2G0Hyz8HYidQdAMIW5O aZkSLz2uEys4Sgxl+IviZAMHusVlhHBHw8Zdy6XsIq7NVey9crFyf6PqVG04pqsf 5cB5mDgJvq7nJVEu3aL9v0bshRMneeaSwkSIqj/+wC7tCtVaf56kZj/EPy18FWD2 amR2TjwKw00Q7kKCoIiB/tBjNNA7YrQUQzlk4CXARi1WuVsRjjObM9TLq0Xag74n o2buLzX4JKFqMlTtjgh3Goq/66yU57umjwGLASobRZHCwnXUkPYOyS1opggX4qs= =x8f7 -----END PGP SIGNATURE----- From matthijs at nlnetlabs.nl Wed May 30 07:56:42 2012 From: matthijs at nlnetlabs.nl (Matthijs Mekking) Date: Wed, 30 May 2012 09:56:42 +0200 Subject: [Opendnssec-develop] OpenDNSSEC 1.4.0a2 In-Reply-To: References: <56EB0F18-2793-4552-AD7F-FA127977EAE6@kirei.se> Message-ID: <4FC5D2BA.8060603@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 05/29/2012 01:07 PM, Sara Dickinson wrote: > Hi, > > My thoughts would be that since producing tarballs isn't a great > overhead then the benefit of making is easier for users to test the > alpha makes it worth doing? I agree. > Other comments on the updated Release process: > > - I would like to see the code review at the top of the list - in > fact it could be argued this should be part of the > development/pre-release process, not the release process since it > is the responsibility of the developers not the person doing the > release The argument that the code review is at step 3 is that documentation updates and testing can resolve in more code changes, that need to be reviewed then again. Also, the release process is not targeted at just the person doing the release. The steps makes sure that all actions have been taken before making the tarball public. So if for example Jerry is sending out a release candidate, he should make sure that code reviews have been done. How exactly we want to do that, I don't know. We could assign one developer to a piece of code (enforcer, signer, libhsm), or we could have a couple of developers look at the whole source (multi coverage). At labs, we have two developers do the code review before doing the release, two others than the main developer. Usually it saves a lot of work if you track the commit messages too. > - Are any code integrity tools run regularly e.g. Coverity? It > seems like this should be done before a major and probably a minor > release after code review updates. I like to see Coverity or something similar to be part of the release process. > - Given the above it should be clear exactly who does what. We > could define a "Release Manager" role. Yes. > - I think it the process could clarify more between > minor/major/patch releases (e.g. in terms of documentation and > package maintenance) I don't think any of the steps could be skipped, even not for the patch releases. > - Step 6. Seems like it would be better if a single person did all > the announce updates - seems to make sense that this is the Project > Manager? Seems logical to me. > IMHO it would also be nice to have a release criteria defined e.g. > no open blocker/critical bugs and all open major bugs have > workarounds. Any thoughts on this? Usually there is a feature freeze. I guess there can also be a bug report freeze. You don't accept new bug reports if you have decided on a release? I'd rather like to stick with our two week telephone conference call and decide on 'Can we release?'. Best regards, Matthijs > I can take a pass at updating the process after some feedback on > the above..... > > One more thought on the Release Engineering process defined in step > 5 - could steps 4,5 and 6 of this be automated in a Jenkins job > that is run manually? > > Sara. > > On 29 May 2012, at 08:38, Rickard Bellgrim wrote: > >> On Tue, May 29, 2012 at 9:13 AM, Jakob Schlyter >> wrote: >>> http://www.opendnssec.org/files/source/testing/opendnssec-1.4.0a2.tar.gz >>> >>> >>> sorry for the delay, kind of missed we did tar-balls of alphas. >> >> No problem. I now checked the release process and could not find >> any clear distinction between the alpha releases and the final >> releases w.r.t tarballs. Perhaps we need to clarify that? >> >> // 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 > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJPxdK6AAoJEA8yVCPsQCW5qHYH/RNXmRqKNaExuAk/DXHJwWQx MlRZ8thte7Ag+6vdlo+s7ntuCD8yIH0AtC+86CVyFX9OSDb4tAHq1x1AsnG8kyGL lCgMKHGYzm3u871ApTseCNt1o7vSD372Q4nRu056ZtsYK3zpPATNL74maeh0gTfT 4okxbu8CWMkb37+2ftGxjnRAU011ey9LwcRZ+hqA53mmr6osBx5GOnBuhNct+MyW I4eSVETdPbBh1JcdzoveHhjJt4YZZpIhjb+e6ddTbkKywgMTjOGmXouMfVfkFKzi 1A/WT7UncGKGq4+aIK0WivP9jdGesrnKCYBCkbgCLfxwZ51c8dKollqF2QWXjZc= =vF/i -----END PGP SIGNATURE----- From sara at sinodun.com Wed May 30 10:37:29 2012 From: sara at sinodun.com (Sara Dickinson) Date: Wed, 30 May 2012 11:37:29 +0100 Subject: [Opendnssec-develop] OpenDNSSEC 1.4.0a2 In-Reply-To: <4FC5D2BA.8060603@nlnetlabs.nl> References: <56EB0F18-2793-4552-AD7F-FA127977EAE6@kirei.se> <4FC5D2BA.8060603@nlnetlabs.nl> Message-ID: <44FBDB47-8FAC-4B1C-9259-0104FF4E8D82@sinodun.com> Jerry, Sion, Matthijs - thanks for the comments. > >> Other comments on the updated Release process: >> >> - I would like to see the code review at the top of the list - in >> fact it could be argued this should be part of the >> development/pre-release process, not the release process since it >> is the responsibility of the developers not the person doing the >> release > > The argument that the code review is at step 3 is that documentation > updates and testing can resolve in more code changes, that need to be > reviewed then again. > > Also, the release process is not targeted at just the person doing the > release. The steps makes sure that all actions have been taken before > making the tarball public. So if for example Jerry is sending out a > release candidate, he should make sure that code reviews have been > done. OK - I think I misunderstood. I had assumed that all the updating of the documentation content and developer testing was complete before the 'Release Process' began and the process described what happened after a team meeting had given the release go ahead (also see below) - purely the mechanics of a release. So I had interpreted Step 1 as simply a sanity check and updates of the wiki/PDF/NEWS sections and Step 2 as simply a sanity check to ensure that the the specific revision used for the release passes all the tests. > How exactly we want to do that, I don't know. We could assign > one developer to a piece of code (enforcer, signer, libhsm), or we > could have a couple of developers look at the whole source (multi > coverage). This is something we should probably talk about in a team meeting. > >> - Are any code integrity tools run regularly e.g. Coverity? It >> seems like this should be done before a major and probably a minor >> release after code review updates. > > I like to see Coverity or something similar to be part of the release > process. I'll take an action to follow this up. > >> - I think it the process could clarify more between >> minor/major/patch releases (e.g. in terms of documentation and >> package maintenance) > > I don't think any of the steps could be skipped, even not for the > patch releases. A minor point but IFAIK a new wiki version (i.e. moving the DOCSTRUNK space to DOCS) is only done on major versions. This is what the first sentence of Step 1 describes. Also are release candidates created for all versions even patches now - I didn't realise this? > >> IMHO it would also be nice to have a release criteria defined e.g. >> no open blocker/critical bugs and all open major bugs have >> workarounds. Any thoughts on this? > > Usually there is a feature freeze. I guess there can also be a bug > report freeze. You don't accept new bug reports if you have decided on > a release? > > I'd rather like to stick with our two week telephone conference call > and decide on 'Can we release?'. Absolutely - I really meant a checklist that could be used in that meeting in addition to the team agreement. For example - 'is everyone done updating the documentation?' 'is everyone done with all their testing'......which is why I think code review should be considered here. So this part of the process would be the team responsibility. I've put a slightly modified version here for review which might clear things up: https://wiki.opendnssec.org/display/OpenDNSSEC/Copy+of+Release+Management+Process Don't know how this compares to NLNet Labs? From matthijs at nlnetlabs.nl Wed May 30 10:52:30 2012 From: matthijs at nlnetlabs.nl (Matthijs Mekking) Date: Wed, 30 May 2012 12:52:30 +0200 Subject: [Opendnssec-develop] OpenDNSSEC 1.4.0a2 In-Reply-To: <44FBDB47-8FAC-4B1C-9259-0104FF4E8D82@sinodun.com> References: <56EB0F18-2793-4552-AD7F-FA127977EAE6@kirei.se> <4FC5D2BA.8060603@nlnetlabs.nl> <44FBDB47-8FAC-4B1C-9259-0104FF4E8D82@sinodun.com> Message-ID: <4FC5FBEE.8030303@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 05/30/2012 12:37 PM, Sara Dickinson wrote: > Jerry, Sion, Matthijs - thanks for the comments. >> >>> Other comments on the updated Release process: >>> >>> - I would like to see the code review at the top of the list - >>> in fact it could be argued this should be part of the >>> development/pre-release process, not the release process since >>> it is the responsibility of the developers not the person doing >>> the release >> >> The argument that the code review is at step 3 is that >> documentation updates and testing can resolve in more code >> changes, that need to be reviewed then again. >> >> Also, the release process is not targeted at just the person >> doing the release. The steps makes sure that all actions have >> been taken before making the tarball public. So if for example >> Jerry is sending out a release candidate, he should make sure >> that code reviews have been done. > > OK - I think I misunderstood. I had assumed that all the updating > of the documentation content and developer testing was complete > before the 'Release Process' began and the process described what > happened after a team meeting had given the release go ahead (also > see below) - purely the mechanics of a release. > > So I had interpreted Step 1 as simply a sanity check and updates of > the wiki/PDF/NEWS sections and Step 2 as simply a sanity check to > ensure that the the specific revision used for the release passes > all the tests. > > >> How exactly we want to do that, I don't know. We could assign one >> developer to a piece of code (enforcer, signer, libhsm), or we >> could have a couple of developers look at the whole source >> (multi coverage). > > This is something we should probably talk about in a team meeting. > >> >>> - Are any code integrity tools run regularly e.g. Coverity? It >>> seems like this should be done before a major and probably a >>> minor release after code review updates. >> >> I like to see Coverity or something similar to be part of the >> release process. > > I'll take an action to follow this up. > >> >>> - I think it the process could clarify more between >>> minor/major/patch releases (e.g. in terms of documentation and >>> package maintenance) >> >> I don't think any of the steps could be skipped, even not for >> the patch releases. > > A minor point but IFAIK a new wiki version (i.e. moving the > DOCSTRUNK space to DOCS) is only done on major versions. This is > what the first sentence of Step 1 describes. Also are release > candidates created for all versions even patches now - I didn't > realise this? To my understanding, from 1.4.0 we want to have release candidates for every release, even patches. It is true that not all steps require the same actions, like for the example you mentioned: a new wiki version is created only on major versions, but the manual pages, README and NEWS files, etc. will need updates for all versions. > >> >>> IMHO it would also be nice to have a release criteria defined >>> e.g. no open blocker/critical bugs and all open major bugs >>> have workarounds. Any thoughts on this? >> >> Usually there is a feature freeze. I guess there can also be a >> bug report freeze. You don't accept new bug reports if you have >> decided on a release? >> >> I'd rather like to stick with our two week telephone conference >> call and decide on 'Can we release?'. > > Absolutely - I really meant a checklist that could be used in that > meeting in addition to the team agreement. For example - 'is > everyone done updating the documentation?' 'is everyone done with > all their testing'......which is why I think code review should be > considered here. So this part of the process would be the team > responsibility. Yes, that makes sense. > > I've put a slightly modified version here for review which might > clear things up: > > https://wiki.opendnssec.org/display/OpenDNSSEC/Copy+of+Release+Management+Process > > Don't know how this compares to NLNet Labs? The first release process I posted was a copy of our release process documentation, and edited it to make it suitable for OpenDNSSEC. I think your copy is also comparable. "Iterate around these steps": If in the release check list something does not satisfy, and this results in code changes, we should jump back to step 3. We also have guidelines if we have to deal with a critical security vulnerability (we issue a CERT ID and don't do rc's). Overall, this copied version looks good to me. Best regards, Matthijs > > > _______________________________________________ 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/ iQEcBAEBAgAGBQJPxfvoAAoJEA8yVCPsQCW52+4H/3ADQATzh1jlcnG80NHOyVR9 /j7KmcQT4b2XrNZaomJstIUgW1wXD25eX0rKsEUupJKVvs+spkRP3wvYZ2+hggrX S+EPZpQYSALfUXqxigCm99qFB0fslvHZaVA0JCuLUD2IBpCJc8shiNB/Hdvwj4FJ TPFcpgqGk06Z/RXj3tkNUfp/q2IZVX4+hde2kihvtwEDKC/P5uqaYMPEmGOfU7h6 EaVUGrLRx3Ig01Vs04ZHH/i8+rVsWHaI9tqk2c4FPZ7RhU1EVEaLgRFLKci+UUTH M7bNUPySHWOR3yblVli3jNBXNKhnZOyWugcN+hU7+PwjjLLzDf8h1H+QaAOueBg= =OBwC -----END PGP SIGNATURE----- From sion at nominet.org.uk Wed May 30 13:07:38 2012 From: sion at nominet.org.uk (=?ISO-8859-1?Q?Si=F4n_Lloyd?=) Date: Wed, 30 May 2012 14:07:38 +0100 Subject: [Opendnssec-develop] OpenDNSSEC 1.4.0a2 In-Reply-To: <44FBDB47-8FAC-4B1C-9259-0104FF4E8D82@sinodun.com> References: <56EB0F18-2793-4552-AD7F-FA127977EAE6@kirei.se> <4FC5D2BA.8060603@nlnetlabs.nl> <44FBDB47-8FAC-4B1C-9259-0104FF4E8D82@sinodun.com> Message-ID: <4FC61B9A.2050507@nominet.org.uk> On 30/05/12 11:37, Sara Dickinson wrote: > Jerry, Sion, Matthijs - thanks for the comments. > >>> - Are any code integrity tools run regularly e.g. Coverity? It >>> seems like this should be done before a major and probably a minor >>> release after code review updates. >> I like to see Coverity or something similar to be part of the release >> process. > I'll take an action to follow this up. > > We still have a license by the looks of things. In previous iterations I have run it and sent reports out (as best as I can), this is not really ideal. My understanding is that we could run it somewhere that everyone could connect to (it has a web-based front-end) as our license covers lines of code. But this is based on memories of a conversation with a salesman a few years ago now so I'd like to check before saying for certain. Also, the version we have a license for (5.X) does not run on the 3.X linux kernel, so it no longer runs on my desktop. I'll try to find out about whether we are covered for newer versions. Sion From sara at sinodun.com Thu May 31 10:14:50 2012 From: sara at sinodun.com (Sara Dickinson) Date: Thu, 31 May 2012 11:14:50 +0100 Subject: [Opendnssec-develop] Release Management Process In-Reply-To: <4FAA7699.7040807@nlnetlabs.nl> References: <4FAA7647.8040909@nlnetlabs.nl> <4FAA7699.7040807@nlnetlabs.nl> Message-ID: <3B4D175A-9F6E-48E7-9238-3AFCA377730B@sinodun.com> Hi All, I've now put an update version with a separate Release Check List and Release Process on the main page for further review: https://wiki.opendnssec.org/display/OpenDNSSEC/Release+Management+Process Regards Sara. On 9 May 2012, at 14:52, Matthijs Mekking wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 05/09/2012 03:51 PM, Matthijs Mekking wrote: >> Hi, >> >> I have updated the release check list at: >> >> https://wiki.opendnssec.org/display/OpenDNSSE/Release+Management+Process > > That >> > should be: > > https://wiki.opendnssec.org/display/OpenDNSSEC/Release+Management+Process > >> >> Basically, steps 2 - 4 have been added: >> >> Step 2: I guess it is sane to check if jenkins does not have any >> tests complaining before doing the release. >> >> Step 3: Code review is part of NLnet Labs release process, it might >> be sane to do that too for OpenDNSSEC. >> >> Step 4: The release candidate to the maintainers step. >> >> Furthermore, I have made the release check list a bit more >> detailed. >> >> Best regards, Matthijs >> _______________________________________________ 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/ > > iQEcBAEBAgAGBQJPqnaZAAoJEA8yVCPsQCW5dPwIANpRcN/4R1pLwGYzbjDIoif9 > 5BJJNSVllANHVSta/0lYJOmy78JiBUZ5tdbD4xmjJLVQbbj80cog7cmxt1qfKwJp > /3SgQy7g8GiYIwXenskb3hNJ2s3sPsnsZ341aE/1IjA7HPuqyzvGp6Tcefw2gUN9 > uDoZ/70us+qpbOUNW+owbQ/DdDIcfUgcD+ccTdLPwMWILIQE1Xz1SSsCqQqf7vOL > wquDpxeQNPZMvA2dwzqftO5XgacPTDutLqmhlk807X9jdIO1fyMd3PuHqJNCc+Ge > 6ziMOQ6gsUzDreQ/Iwf5HQbgUBdG16Lauu0F8ZI9IGyW2UVBg+QirLmLZNkBnrU= > =CriR > -----END PGP SIGNATURE----- > _______________________________________________ > Opendnssec-develop mailing list > Opendnssec-develop at lists.opendnssec.org > https://lists.opendnssec.org/mailman/listinfo/opendnssec-develop From sara at sinodun.com Thu May 31 10:26:21 2012 From: sara at sinodun.com (Sara Dickinson) Date: Thu, 31 May 2012 11:26:21 +0100 Subject: [Opendnssec-develop] Re: Adapter configuration In-Reply-To: <4FC5CCF4.30801@nlnetlabs.nl> References: <4FBF8116.2000900@nic.cz> <4FC5CCF4.30801@nlnetlabs.nl> Message-ID: <15FA2570-A647-4243-8133-2B3E0F5AA51D@sinodun.com> On 30 May 2012, at 08:32, Matthijs Mekking wrote: >> - ods-kaspcheck can check adapter files. > > I agree, that might be useful too. +1 But would this make it more of an 'ods-configcheck' tool i.e. more general than just kasp? Have their been any thoughts of doing this (since it is being re-written in 1.4)? Then it could be extended in future to include the other xml files.