From matthijs at NLnetLabs.nl Mon Nov 1 12:51:34 2010 From: matthijs at NLnetLabs.nl (Matthijs Mekking) Date: Mon, 01 Nov 2010 13:51:34 +0100 Subject: [Opendnssec-develop] ods-signer and many zones Message-ID: <4CCEB7D6.3080702@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, When having let's say 5000 zones, the output of ods-signer zones and ods-signer queue is kind of large and imo does not make much sense. Would it be a good idea to limit the output for these functions to let's say the first 100 items? Best regards, Matthijs -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJMzrfVAAoJEA8yVCPsQCW5MRYIANXW+X+lqH+iyFW3Fx5N49Of V7v/azgm0fS8XuGzsmOPuGSo8cr0xjml4LLxTcnCUGyudkZB7ur3t2lrFBCizfRY t6oUSx5D35A6wy+mj+8gy2+E6b2N8GMu356Dv/iAEjExbLWW4Q/RJdyW8n6NlOOf tEJj2d9SXX41vd0TtWpsSN1Od7YChampG+JMhqYUxlwoG3Wi3mP8iCMiZ5eCRfYh nFyNuRnmZtXO+wJxVGEuc6f7/C6myhnNANbQyND7lqzL4Sq1pTmSTGAC0t9F04KP f2DsbqasSM4I+TRadRRQroAD+KQLH84R926IMIhjfSEpW01tY7FTchVkT3N1Mow= =e4yr -----END PGP SIGNATURE----- From owner-dnssec-trac at kirei.se Tue Nov 2 08:18:26 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Tue, 02 Nov 2010 08:18:26 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #190: Auditor does not handle case correctly In-Reply-To: <077.b6efec6ceaccc4547ba0dc59436222ae@kirei.se> References: <077.b6efec6ceaccc4547ba0dc59436222ae@kirei.se> Message-ID: <086.8591c7e2f468fc960400f8611efa5b72@kirei.se> #190: Auditor does not handle case correctly -----------------------------------------------------+---------------------- Reporter: Marc Dequ?nes (Duck) | Owner: alex Type: defect | Status: assigned Priority: major | Component: Auditor Version: trunk | Keywords: -----------------------------------------------------+---------------------- Changes (by alex): * status: new => assigned Comment: Could you please tell me the version of dnsruby you are running, and provide the original unsigned zone file which caused the issue? -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Tue Nov 2 08:20:12 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Tue, 02 Nov 2010 08:20:12 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #189: Auditor fails to validate CERT RR In-Reply-To: <077.57a2bee7d0dd82b46fbbefd933ac0af1@kirei.se> References: <077.57a2bee7d0dd82b46fbbefd933ac0af1@kirei.se> Message-ID: <086.7194a9f02935c2fcfd109b6a2b2b9ed1@kirei.se> #189: Auditor fails to validate CERT RR -----------------------------------------------------+---------------------- Reporter: Marc Dequ?nes (Duck) | Owner: alex Type: defect | Status: new Priority: critical | Component: Auditor Version: trunk | Keywords: -----------------------------------------------------+---------------------- Comment(by alex): Could you please confirm the version of dnsruby you are using, and send me the unsigned zone file which causes the problem? -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Tue Nov 2 10:51:12 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Tue, 02 Nov 2010 10:51:12 -0000 Subject: [Opendnssec-develop] [OpenDNSSEC] #191: Signer does not log when a zone can't be signed due to errors Message-ID: <044.6ddc588d29ff1e39c0776becf6c789f8@kirei.se> #191: Signer does not log when a zone can't be signed due to errors -------------------+-------------------------------------------------------- Reporter: roland | Owner: mm Type: defect | Status: new Priority: major | Component: Signer Version: 1.1.1 | Keywords: signer,logging -------------------+-------------------------------------------------------- Today, we experienced a synchronisation problem with our HSMs (we have two that operate in high availability mode). The result of this is that some keys cannot be found. The signer reports this in the logs: Nov 2 00:45:12 rivest ods-signerd: create_dnskey stderr: Unable to find key with id 42abf624e0ad28c4f50f6e8f64734054 Nov 2 00:45:12 rivest ods-signerd: Error: could not find key 42abf624e0ad28c4f50f6e8f64734054 Nov 2 00:45:12 rivest zone_reader: SSL cipher list set to AES256-SHA ... Nov 2 00:45:13 rivest ods-signerd: stderr from zone_reader: could not find key 42abf624e0ad28c4f50f6e8f64734054 Nov 2 00:45:13 rivest ods-signerd: stderr from zone_reader: error creating DNSKEYs for zone 'surfnet.nl' Nov 2 00:45:13 rivest ods-signerd: stderr from zone_reader: Error, unable to publish DNSKEYs for zone surfnet.nl Nov 2 00:45:13 rivest ods-signerd: Nseccing failed ... The end result is that the signer cannot output a new signed zone. We only noticed this problem because our monitoring picked up that signatures were not being refreshed. It would be very helpful if the signer could *explicitly* log that it was unable to output a new signed zone rather than just reporting intermediate error messages like "Nseccing failed" Thanks in advance! Cheers, Roland. -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Tue Nov 2 10:52:25 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Tue, 02 Nov 2010 10:52:25 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #191: Signer does not log when a zone can't be signed due to errors In-Reply-To: <044.6ddc588d29ff1e39c0776becf6c789f8@kirei.se> References: <044.6ddc588d29ff1e39c0776becf6c789f8@kirei.se> Message-ID: <053.40c010f13bd003dbeaa5ed4a6169d1d4@kirei.se> #191: Signer does not log when a zone can't be signed due to errors -------------------+-------------------------------------------------------- Reporter: roland | Owner: matthijs Type: defect | Status: assigned Priority: major | Component: Signer Version: 1.1.1 | Keywords: signer,logging -------------------+-------------------------------------------------------- Changes (by roland): * owner: mm => matthijs * status: new => assigned -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Tue Nov 2 12:54:45 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Tue, 02 Nov 2010 12:54:45 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #191: Signer does not log when a zone can't be signed due to errors In-Reply-To: <044.6ddc588d29ff1e39c0776becf6c789f8@kirei.se> References: <044.6ddc588d29ff1e39c0776becf6c789f8@kirei.se> Message-ID: <053.6ce26890f3da0f1bb886e9c8be6c4bdd@kirei.se> #191: Signer does not log when a zone can't be signed due to errors ---------------------------+------------------------------------------------ Reporter: roland | Owner: matthijs Type: defect | Status: closed Priority: major | Component: Signer Version: 1.1.1 | Resolution: fixed Keywords: signer,logging | ---------------------------+------------------------------------------------ Changes (by matthijs): * status: assigned => closed * resolution: => fixed Comment: fixed in branch 1.1.1 -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Tue Nov 2 14:26:00 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Tue, 02 Nov 2010 14:26:00 -0000 Subject: [Opendnssec-develop] [OpenDNSSEC] #192: Minor feature: key label logging upon HSM deletion Message-ID: <045.f1bef3ee2517c2ccc719ef1b1e1cdb6f@kirei.se> #192: Minor feature: key label logging upon HSM deletion ------------------------+--------------------------------------------------- Reporter: vanrein | Owner: sion Type: enhancement | Status: new Priority: trivial | Component: Enforcer Version: | Keywords: ------------------------+--------------------------------------------------- While debugging, we noticed a place where a bit more logged information would have been useful. Perhaps it can be added? When keys are created, their label is reported in the logs; when they are destroyed, they are not. Is it straightforward to add such information? It helps in tracking when what was done to whom. Cheers, -Rick -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Wed Nov 3 02:43:18 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Wed, 03 Nov 2010 02:43:18 -0000 Subject: [Opendnssec-develop] [OpenDNSSEC] #193: KsmPolicyPopulateSMFromIds doesn't handle well 'unlimited' capacity Message-ID: <078.66b2587e6306d44fb401ae36e8208513@kirei.se> #193: KsmPolicyPopulateSMFromIds doesn't handle well 'unlimited' capacity -----------------------------------------------------+---------------------- Reporter: Sebastian Castro | Owner: matthijs Type: defect | Status: new Priority: minor | Component: Signer Version: trunk | Keywords: -----------------------------------------------------+---------------------- When you have a repository with unlimited capacity, it's saved in the KASP with a '' value in the 'capacity' column. By the time KsmPolicyPopulateSMFromIds tries to read that value, gets a random integer. If you are unlucky to get a value lower than the current number of keys you have, you'll see the 'Repository is full' message. I tried setting the capacity directly in the kasp.db to a value big enough and the message is gone. For debugging purposes, I added the current count and capacity values to the error message. -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Wed Nov 3 07:44:08 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Wed, 03 Nov 2010 07:44:08 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #189: Auditor fails to validate CERT RR In-Reply-To: <077.57a2bee7d0dd82b46fbbefd933ac0af1@kirei.se> References: <077.57a2bee7d0dd82b46fbbefd933ac0af1@kirei.se> Message-ID: <086.efc63f697ebf88b72763c0dbe871e153@kirei.se> #189: Auditor fails to validate CERT RR -----------------------------------------------------+---------------------- Reporter: Marc Dequ?nes (Duck) | Owner: alex Type: defect | Status: new Priority: critical | Component: Auditor Version: trunk | Keywords: -----------------------------------------------------+---------------------- Comment(by rb): I also get this problem if you forget to remove the extra spaces in the rdata. If you get the CERT RR using this command, then you have to remember to remote the extra spaces in the base64 blob. -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Wed Nov 3 08:24:11 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Wed, 03 Nov 2010 08:24:11 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #189: Auditor fails to validate CERT RR In-Reply-To: <077.57a2bee7d0dd82b46fbbefd933ac0af1@kirei.se> References: <077.57a2bee7d0dd82b46fbbefd933ac0af1@kirei.se> Message-ID: <086.73a3feba0d354f4f510071e9e56a081c@kirei.se> #189: Auditor fails to validate CERT RR -----------------------------------------------------+---------------------- Reporter: Marc Dequ?nes (Duck) | Owner: alex Type: defect | Status: new Priority: critical | Component: Auditor Version: trunk | Keywords: -----------------------------------------------------+---------------------- Comment(by rb): So it is not a bug, but rather a malformed RR in the unsigned zone. Do you agree Marc? -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Wed Nov 3 08:36:23 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Wed, 03 Nov 2010 08:36:23 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #189: Auditor fails to validate CERT RR In-Reply-To: <077.57a2bee7d0dd82b46fbbefd933ac0af1@kirei.se> References: <077.57a2bee7d0dd82b46fbbefd933ac0af1@kirei.se> Message-ID: <086.22f969d362d77524352a68579b23f596@kirei.se> #189: Auditor fails to validate CERT RR -----------------------------------------------------+---------------------- Reporter: Marc Dequ?nes (Duck) | Owner: alex Type: defect | Status: new Priority: critical | Component: Auditor Version: trunk | Keywords: -----------------------------------------------------+---------------------- Comment(by rb): ok, after some more discussions we do agree that the auditor also should accept extra spaces in base64 blobs. according to rfc 4398, section 2.2: The CRL portion is represented in base 64 and may be divided into any number of white-space-seperated substrings, down to single base-64 digits -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Wed Nov 3 12:09:55 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Wed, 03 Nov 2010 12:09:55 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #189: Auditor fails to validate CERT RR In-Reply-To: <077.57a2bee7d0dd82b46fbbefd933ac0af1@kirei.se> References: <077.57a2bee7d0dd82b46fbbefd933ac0af1@kirei.se> Message-ID: <086.2e4f6fff7ae99563247117854a164753@kirei.se> #189: Auditor fails to validate CERT RR -----------------------------------------------------+---------------------- Reporter: Marc Dequ?nes (Duck) | Owner: alex Type: defect | Status: new Priority: critical | Component: Auditor Version: trunk | Keywords: -----------------------------------------------------+---------------------- Comment(by Marc Dequ?nes (Duck) ): I use dnsruby 1.49. I can confirm the CERT is split over several lines, making it easier to read. I found this was a common way to format this long RR in Bind, but didn't realize it was sent split to the client. Thanks for your work on the issue. -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Wed Nov 3 12:21:35 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Wed, 03 Nov 2010 12:21:35 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #190: Auditor does not handle case correctly In-Reply-To: <077.b6efec6ceaccc4547ba0dc59436222ae@kirei.se> References: <077.b6efec6ceaccc4547ba0dc59436222ae@kirei.se> Message-ID: <086.994584599ea07c85071a20bab9950d13@kirei.se> #190: Auditor does not handle case correctly -----------------------------------------------------+---------------------- Reporter: Marc Dequ?nes (Duck) | Owner: alex Type: defect | Status: assigned Priority: major | Component: Auditor Version: trunk | Keywords: -----------------------------------------------------+---------------------- Comment(by Marc Dequ?nes (Duck) ): I use dnsruby 1.49. Attached is the unmodified zone i used for my first try (from a backup). The zone name i used with ''ods-ksmutil zone add'' was '''F.1.8.0.8.A.7.0.1.0.0.2.IP6.ARPA''' (from the shell history). Regards. -- Ticket URL: OpenDNSSEC OpenDNSSEC From rickard.bellgrim at iis.se Wed Nov 3 15:36:35 2010 From: rickard.bellgrim at iis.se (Rickard Bellgrim) Date: Wed, 3 Nov 2010 16:36:35 +0100 Subject: [Opendnssec-develop] Meeting tomorrow Message-ID: Hi We have a short meeting about a new beta release tomorrow. Date: Thursday 4 November Time: 14:00-14:30 CEST, 13:00-13:30 BST Agenda: http://trac.opendnssec.org/wiki/Meetings/Agenda/2010-11-04 // Rickard From owner-dnssec-trac at kirei.se Thu Nov 4 12:28:44 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Thu, 04 Nov 2010 12:28:44 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #193: KsmPolicyPopulateSMFromIds doesn't handle well 'unlimited' capacity In-Reply-To: <078.66b2587e6306d44fb401ae36e8208513@kirei.se> References: <078.66b2587e6306d44fb401ae36e8208513@kirei.se> Message-ID: <087.69fbb185a2132a5177847d1d2b1ac9c5@kirei.se> #193: KsmPolicyPopulateSMFromIds doesn't handle well 'unlimited' capacity -----------------------------------------------------+---------------------- Reporter: Sebastian Castro | Owner: matthijs Type: defect | Status: closed Priority: minor | Component: Signer Version: trunk | Resolution: fixed Keywords: | -----------------------------------------------------+---------------------- Changes (by rb): * status: new => closed * resolution: => fixed Comment: Thanks, fixed in r4165. The feedback-patch does not add so much extra value to the message. If it is full then it is full (but it would help in debugging purpose if the function is not working as it should). However, we will keep in mind for v1.3 that the user might want to get a notice before the HSM is full. -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Fri Nov 5 01:41:08 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Fri, 05 Nov 2010 01:41:08 -0000 Subject: [Opendnssec-develop] [OpenDNSSEC] #194: ods-ksmutil generates more keys than needed Message-ID: <078.e34b0906e161f4380c634f72c27ec0ff@kirei.se> #194: ods-ksmutil generates more keys than needed -----------------------------------------------------+---------------------- Reporter: Sebastian Castro | Owner: matthijs Type: defect | Status: new Priority: minor | Component: Signer Version: trunk | Keywords: -----------------------------------------------------+---------------------- In the attached file you will find two runs of 'ods-ksmutil key generate'. During the first, creates 3 KSK and 5 ZSK which is fine. The second run, 10 seconds later, generates the same number of keys. The issues seems to be in KsmKeyPairCreate: the keys are added to the keypairs table, but not the dnssseckeys table with state GENERATE, leading to be seen with 'empty' status in KEYDATA_VIEW. When cmd_genkeys tries to find the number of keys in the pool (via KsmKeyCountStillGood), it can't find them because they don't match the condition, forcing the generation of keys. Also monitoring the status of KEYDATA_VIEW entries for an specific policy, I noticed it went from 'empty' to status=2 (PUBLISH) when a key was used for incoming ZSK during normal processing. -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Fri Nov 5 10:44:36 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Fri, 05 Nov 2010 10:44:36 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #194: ods-ksmutil generates more keys than needed In-Reply-To: <078.e34b0906e161f4380c634f72c27ec0ff@kirei.se> References: <078.e34b0906e161f4380c634f72c27ec0ff@kirei.se> Message-ID: <087.12710058c66b2dd571a4fbe44aef8830@kirei.se> #194: ods-ksmutil generates more keys than needed -----------------------------------------------------+---------------------- Reporter: Sebastian Castro | Owner: sion Type: defect | Status: assigned Priority: minor | Component: Enforcer Version: trunk | Keywords: -----------------------------------------------------+---------------------- Changes (by sion): * owner: matthijs => sion * status: new => assigned * component: Signer => Enforcer -- Ticket URL: OpenDNSSEC OpenDNSSEC From rickard.bellgrim at iis.se Fri Nov 5 11:42:50 2010 From: rickard.bellgrim at iis.se (Rickard Bellgrim) Date: Fri, 5 Nov 2010 12:42:50 +0100 Subject: [Opendnssec-develop] Doodle: Next OpenDNSSEC meeting Message-ID: Hi When should we have the next telephone meeting? Please vote here: http://www.doodle.com/gi24uest2eqcz2kr There will be a decision for a b2 or rc1 during next week. But that will be through email. // Rickard From owner-dnssec-trac at kirei.se Fri Nov 5 14:32:15 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Fri, 05 Nov 2010 14:32:15 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #194: ods-ksmutil generates more keys than needed In-Reply-To: <078.e34b0906e161f4380c634f72c27ec0ff@kirei.se> References: <078.e34b0906e161f4380c634f72c27ec0ff@kirei.se> Message-ID: <087.34cbc1103e04a01485252838a2861187@kirei.se> #194: ods-ksmutil generates more keys than needed -----------------------------------------------------+---------------------- Reporter: Sebastian Castro | Owner: sion Type: defect | Status: closed Priority: minor | Component: Enforcer Version: trunk | Resolution: fixed Keywords: | -----------------------------------------------------+---------------------- Changes (by sion): * status: assigned => closed * resolution: => fixed Comment: Thank you. This issue should have been fixed in r4170. -- Ticket URL: OpenDNSSEC OpenDNSSEC From matthijs at NLnetLabs.nl Mon Nov 8 12:04:10 2010 From: matthijs at NLnetLabs.nl (Matthijs Mekking) Date: Mon, 08 Nov 2010 13:04:10 +0100 Subject: [Opendnssec-develop] dependency on sqlite 3.4.2 ? Message-ID: <4CD7E73A.4080603@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, Our dependency list says that sqlite 3.3.9 or greater is required, but the configure wants to have 3.4.2. Bump it in the documentation or lower it in the m4 file? Best regards, Matthijs -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJM1+c5AAoJEA8yVCPsQCW5/g0H/RTljw5Q6NK9iQl10lSWtBs+ N0JJjQrM1WsABDHW5bKwkKHUBKtvVo/N8nYYEpTl2LrA1Hu7qAcJxispf5owYUsB IcGokcR5L/jYPzJK/CjkEPGDcufyzcNgLzKHhXkat91jlQOFtaBQG0WrcIglVysZ BeiFP1lVEzEztHNwEgDFv/F5XYsqXiJCTHlE2b7M8E1y2i3Pn0H9CriSOqY3b3qi Rquy0s1Z7TpiEktKRYQL2rRce8eO6IvUBNra4g8DGazFpzx1RIbhN8ieRupnuHkM wRrxpJr8Sq6VJHv5y1iftpdJn8rgxo6j8ArphufysPQB2P+eDI0NWGCo/QBnstY= =Ehtf -----END PGP SIGNATURE----- From sion at nominet.org.uk Mon Nov 8 14:43:40 2010 From: sion at nominet.org.uk (Sion Lloyd) Date: Mon, 8 Nov 2010 14:43:40 +0000 Subject: [Opendnssec-develop] dependency on sqlite 3.4.2 ? In-Reply-To: <4CD7E73A.4080603@nlnetlabs.nl> References: <4CD7E73A.4080603@nlnetlabs.nl> Message-ID: <201011081443.40160.sion@nominet.org.uk> > Our dependency list says that sqlite 3.3.9 or greater is required, but > the configure wants to have 3.4.2. Bump it in the documentation or lower > it in the m4 file? 3.3.9 has the last API change that we need (as far as I can tell) but there are bug fixes in later versions that look important. Release 3.4.2 doesn't seem to have any fixes of particular interest for us... I can't think why it is the version specified. (Except maybe it is the the oldest version on any of our supported platforms?) SO... 3.3.9 is the oldest version that libksm will build against, but it is not a version that I would recommend using. I'm not sure what all that means for your question. Maybe we drop the version in the m4 but recommend using a newer version? Sion From owner-dnssec-trac at kirei.se Mon Nov 8 22:56:19 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Mon, 08 Nov 2010 22:56:19 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #187: signer In-Reply-To: <070.0e6c42ef7b6045265b3978f2dc1aaf96@kirei.se> References: <070.0e6c42ef7b6045265b3978f2dc1aaf96@kirei.se> Message-ID: <079.9a6665bb250ced6be72dceae9be77f5b@kirei.se> #187: signer ---------------------------------------------+------------------------------ Reporter: Tom Hendrikx | Owner: matthijs Type: defect | Status: reopened Priority: major | Component: Signer Version: trunk | Resolution: Keywords: | ---------------------------------------------+------------------------------ Changes (by Tom Hendrikx ): * status: closed => reopened * resolution: fixed => Comment: I just tested this, and it seems that 'ods-signer running' does not return when the result successful. It does print 'Engine running', but does not exit. This does not happen when the result is unsuccessful. -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Tue Nov 9 08:47:32 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Tue, 09 Nov 2010 08:47:32 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #187: signer In-Reply-To: <070.0e6c42ef7b6045265b3978f2dc1aaf96@kirei.se> References: <070.0e6c42ef7b6045265b3978f2dc1aaf96@kirei.se> Message-ID: <079.4f33c8ef66e06581994087f3b6083fb5@kirei.se> #187: signer ---------------------------------------------+------------------------------ Reporter: Tom Hendrikx | Owner: matthijs Type: defect | Status: closed Priority: major | Component: Signer Version: trunk | Resolution: fixed Keywords: | ---------------------------------------------+------------------------------ Changes (by matthijs): * status: reopened => closed * resolution: => fixed Comment: ods-signer would never exit with r4172, fixed in r4173. -- Ticket URL: OpenDNSSEC OpenDNSSEC From rickard.bellgrim at iis.se Tue Nov 9 09:10:04 2010 From: rickard.bellgrim at iis.se (Rickard Bellgrim) Date: Tue, 9 Nov 2010 10:10:04 +0100 Subject: [Opendnssec-develop] Next release Message-ID: Hi Previous meeting stated that we should do a release early this week. We have some stuff left in the PivotalTracker. Sion will not be available tomorrow and Alex has been off due to illness. So, should we do a release of b2 today or later. Or wait to e.g. Friday to get an RC1? // Rickard From matthijs at NLnetLabs.nl Tue Nov 9 09:18:10 2010 From: matthijs at NLnetLabs.nl (Matthijs Mekking) Date: Tue, 09 Nov 2010 10:18:10 +0100 Subject: [Opendnssec-develop] Next release In-Reply-To: References: Message-ID: <4CD911D2.7060800@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, We also stated that there were few changes made that a new beta was not required. Therefore, I would say wait until the pivotal stories are finished (and accepted) and do a rc1 later. Best regards, Matthijs On 11/09/2010 10:10 AM, Rickard Bellgrim wrote: > Hi > > Previous meeting stated that we should do a release early this week. > > We have some stuff left in the PivotalTracker. Sion will not be available tomorrow and Alex has been off due to illness. > > So, should we do a release of b2 today or later. Or wait to e.g. Friday to get an RC1? > > // Rickard > > _______________________________________________ > Opendnssec-develop mailing list > Opendnssec-develop at lists.opendnssec.org > https://lists.opendnssec.org/mailman/listinfo/opendnssec-develop > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJM2RHRAAoJEA8yVCPsQCW5d7QH/1sb7ngYZRpEQj67jeOnv6c8 E+ZhGWUMkUCebQRcl/prAWFZ5iUpKaNFMaoZyZI9brg0xoi5LppeTOyccMhmniWR CB3vDqIf0q8D6C8Z3o0hHNzpqa2iEZAE/E/PrvrSefoCUNjpzL5CLXzcY3MIuwln RMMHuV0xV8xFExAT7zFbVKT4ABIEQhZ/rlyJzG8SWqVLlFQCWGLzXKeUyJF7+dBH RDjWdvFG3CaSA8yBYQUbgABfIFDC4mNGf7Z6tx/rhzgb2+0GCyjUx5CVPpVr4q38 vScVDfUlA2TxpcBlryTp0KRCjg+/kR/zyymjb8OYLUc9HPYVOdM7oZB/dABX1kI= =MlEk -----END PGP SIGNATURE----- From AlexD at nominet.org.uk Tue Nov 9 09:17:09 2010 From: AlexD at nominet.org.uk (Alex Dalitz) Date: Tue, 9 Nov 2010 09:17:09 +0000 Subject: [Opendnssec-develop] Next release In-Reply-To: References: Message-ID: <521CA3EC-09DC-434D-AC34-59F981C862D5@nominet.org.uk> Hi - > Previous meeting stated that we should do a release early this week. > > We have some stuff left in the PivotalTracker. Sion will not be available tomorrow and Alex has been off due to illness. > > So, should we do a release of b2 today or later. Or wait to e.g. Friday to get an RC1? Many apologies for the delay in fixing my pivotal issues. I am back at work again today and will prioritise these issues. I'd certainly hope to be able to fix them all by Friday. Thanks, Alex. From rickard.bellgrim at iis.se Tue Nov 9 09:35:56 2010 From: rickard.bellgrim at iis.se (Rickard Bellgrim) Date: Tue, 9 Nov 2010 10:35:56 +0100 Subject: [Opendnssec-develop] Next release In-Reply-To: References: Message-ID: Ok, lets go for this: On 9 nov 2010, at 17.10, Rickard Bellgrim wrote: > Or wait to e.g. Friday to get an RC1? From AlexD at nominet.org.uk Tue Nov 9 10:53:10 2010 From: AlexD at nominet.org.uk (Alex Dalitz) Date: Tue, 9 Nov 2010 10:53:10 +0000 Subject: [Opendnssec-develop] Fwd: [Opendnssec-user] Issues when signing ip6.arpa record References: <20101109104652.322e4672@headshop.heanet.ie> Message-ID: Hi - This is Pivotal 6042043. I can't reproduce the problem, and Rob thinks his install may be incorrect. Should we wait for him to re-test, or should we close the issue with regard to the potential RC/beta release? Thanks, Alex. Begin forwarded message: From: Rob Gallagher > Date: 9 November 2010 10:46:52 GMT To: Alex Dalitz > Subject: Re: [Opendnssec-user] Issues when signing ip6.arpa record Hi Alex, On Tue, 9 Nov 2010 10:15:45 +0000 Alex Dalitz > wrote: Sorry for the delay in response. I've tried signing the zone you sent with the svn trunk of dnsruby and opendnssec, and I don't get the errors you report. Would you please be able to test with the trunk revisions? Thanks for looking into this. I think our OpenDNSSEC environment wasn't installed properly (failed upgrade from 1.1.0 to 1.2.0), so I'm going to try a clean install of the trunk versions later this week. rg -- Rob Gallagher | Public Key: 0x1DD13A78 HEAnet Limited, Ireland's Education and Research Network 1st Floor, 5 George's Dock, IFSC, Dublin 1. Registered in Ireland, no 275301 T: (+353-1) 6609040 F: (+353-1) 6603666 WWW: http://www.heanet.ie/ HEAnet National Networking Conference, 10-12 November 2010 - Registration is now open at: http://www.heanet.ie/conferences/2010/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From owner-dnssec-trac at kirei.se Wed Nov 10 02:07:52 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Wed, 10 Nov 2010 02:07:52 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #189: Auditor fails to validate CERT RR In-Reply-To: <077.57a2bee7d0dd82b46fbbefd933ac0af1@kirei.se> References: <077.57a2bee7d0dd82b46fbbefd933ac0af1@kirei.se> Message-ID: <086.16bc76e8fb6365f1b780ca0b92dd625d@kirei.se> #189: Auditor fails to validate CERT RR -----------------------------------------------------+---------------------- Reporter: Marc Dequ?nes (Duck) | Owner: alex Type: defect | Status: closed Priority: critical | Component: Auditor Version: trunk | Resolution: fixed Keywords: | -----------------------------------------------------+---------------------- Changes (by rb): * status: new => closed * resolution: => fixed Comment: This has now been fixed in dnsruby svn r444. Will be included in the next dnsruby release. -- Ticket URL: OpenDNSSEC OpenDNSSEC From rickard.bellgrim at iis.se Wed Nov 10 02:30:00 2010 From: rickard.bellgrim at iis.se (Rickard Bellgrim) Date: Wed, 10 Nov 2010 03:30:00 +0100 Subject: [Opendnssec-develop] Character case of domain names Message-ID: Hi We have the ticket about case handling in the Auditor: http://trac.opendnssec.org/ticket/190 Currently the signer make upper case to lower case of domain names, which the Auditor cannot follow. Alex is currently working on fixing this after some discussion with me and Matthijs. But after reading the draft of rfc3597bis, I see a text which is also included in the original rfc3597: "servers MUST also exactly preserve the RDATA of RRs of known type, except for changes due to compression or decompression where allowed by section 4 of this memo. In particular, the character case of domain names that are not subject to compression MUST be preserved." This mean that the signer need to preserve the case of domain names, right? // Rickard From patrik.wallstrom at iis.se Wed Nov 10 03:43:58 2010 From: patrik.wallstrom at iis.se (=?iso-8859-1?Q?Patrik_Wallstr=F6m?=) Date: Wed, 10 Nov 2010 04:43:58 +0100 Subject: [Opendnssec-develop] Character case of domain names In-Reply-To: References: Message-ID: <8D74B633-C0D4-4EB6-BE94-D57681E4BF88@iis.se> On Nov 10, 2010, at 10:30 AM, Rickard Bellgrim wrote: > > Hi > > We have the ticket about case handling in the Auditor: > http://trac.opendnssec.org/ticket/190 > > Currently the signer make upper case to lower case of domain names, which the Auditor cannot follow. Alex is currently working on fixing this after some discussion with me and Matthijs. > > But after reading the draft of rfc3597bis, I see a text which is also included in the original rfc3597: > "servers MUST also exactly preserve the RDATA of RRs of known type, except for changes due to compression or decompression where allowed by section 4 of this memo. In particular, the character case of domain names that are not subject to compression MUST be preserved." > > This mean that the signer need to preserve the case of domain names, right? This is mainly a DNS protocol issue, but I think we should do the right thing and not mess with the case on the labels. Just not to surprise any of parties, be it other implementations of auditors or other tools and users. -- 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 matthijs at NLnetLabs.nl Wed Nov 10 06:39:50 2010 From: matthijs at NLnetLabs.nl (Matthijs Mekking) Date: Wed, 10 Nov 2010 07:39:50 +0100 Subject: [Opendnssec-develop] Character case of domain names In-Reply-To: References: Message-ID: <4CDA3E36.3050902@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I think you are right, but note this only reflects RDATA (not owner name). Matthijs On 11/10/2010 03:30 AM, Rickard Bellgrim wrote: > Hi > > We have the ticket about case handling in the Auditor: > http://trac.opendnssec.org/ticket/190 > > Currently the signer make upper case to lower case of domain names, which the Auditor cannot follow. Alex is currently working on fixing this after some discussion with me and Matthijs. > > But after reading the draft of rfc3597bis, I see a text which is also included in the original rfc3597: > "servers MUST also exactly preserve the RDATA of RRs of known type, except for changes due to compression or decompression where allowed by section 4 of this memo. In particular, the character case of domain names that are not subject to compression MUST be preserved." > > This mean that the signer need to preserve the case of domain names, right? > > // Rickard > > _______________________________________________ > Opendnssec-develop mailing list > Opendnssec-develop at lists.opendnssec.org > https://lists.opendnssec.org/mailman/listinfo/opendnssec-develop > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJM2j42AAoJEA8yVCPsQCW5Iu4H/1XzrckQjMGlketvp9WoPHYm IkPLTDOUhDRILcTPT21ahAq4KqX6p1R97FFhAO3kZAywTgfWHRZApYz5M7ctJsgY TvXdl+fgJkC8ma1fBhEpK2EU+DGWkk1wE3q6WiKoK2RYcWSizAlfnvEILFAKzPuX lmFw4peGF0vAfVUTqgZBm+7/xtCorZwFbVkTUcHtv1Ghg3yTfLmwN4n+jOSgjzrF /pokYQ8xOG/jhLEnd22T1YFWUDWxLaYxujh4Uo8URpYejX37Zs/1zOlCgEuSe4gy lT7hdrH85nH7Lf462LojteLrH1ZFAKaRuZDR/+sALDHfj+cxuUqhoFWrTlraN3Q= =JOn0 -----END PGP SIGNATURE----- From rickard.bellgrim at iis.se Wed Nov 10 10:01:43 2010 From: rickard.bellgrim at iis.se (Rickard Bellgrim) Date: Wed, 10 Nov 2010 11:01:43 +0100 Subject: [Opendnssec-develop] Character case of domain names In-Reply-To: <4CDA3E36.3050902@nlnetlabs.nl> References: <4CDA3E36.3050902@nlnetlabs.nl> Message-ID: <48F206A5-D874-42A2-94E0-3ED26BDB8ED7@iis.se> On 10 nov 2010, at 14.39, Matthijs Mekking wrote: > I think you are right, but note this only reflects RDATA (not owner name). Ahh, ok. So there is no RFC that say that you should preserve the case of the owner name? // Rickard From matthijs at NLnetLabs.nl Wed Nov 10 11:35:23 2010 From: matthijs at NLnetLabs.nl (Matthijs Mekking) Date: Wed, 10 Nov 2010 12:35:23 +0100 Subject: [Opendnssec-develop] Character case of domain names In-Reply-To: <48F206A5-D874-42A2-94E0-3ED26BDB8ED7@iis.se> References: <4CDA3E36.3050902@nlnetlabs.nl> <48F206A5-D874-42A2-94E0-3ED26BDB8ED7@iis.se> Message-ID: <4CDA837B.4080305@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I haven't found yet ;) On 11/10/2010 11:01 AM, Rickard Bellgrim wrote: > > On 10 nov 2010, at 14.39, Matthijs Mekking wrote: > >> I think you are right, but note this only reflects RDATA (not owner name). > > Ahh, ok. > > So there is no RFC that say that you should preserve the case of the owner name? > > // Rickard > > _______________________________________________ > Opendnssec-develop mailing list > Opendnssec-develop at lists.opendnssec.org > https://lists.opendnssec.org/mailman/listinfo/opendnssec-develop > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJM2oN7AAoJEA8yVCPsQCW5vN8H/3igqM5S6/WuvupPWCOMlUi/ /6JdivaEqxmzkqXAGrcpoXVANsxETHYusdLcsXQ0hHDJEI5LQXJlEk0D8AMYDUbM 5lR9KTK1zlCD/XCOfPrJOsljDGa/k9WHskxQqEsBgAIBFC0yV55FatytEglIyXJ4 9JZpTRh+8PZCCk67Xd1bdAfNcog1fjlye3MLRmPxfqnBdfYLX8xwZIxTRQyzVWYi IebtKJaRAlveRiZsW4WlWYfsOld3+Tda2rVG+MwjhEhOtvlx7/vvgzHFXfPESJYw Djf/9BZvrJXt0Ju6qlTswhgfV5xw/SZIxX075iZu+7/cUxJy8cpPzNKmHQJHmKg= =V06w -----END PGP SIGNATURE----- From owner-dnssec-trac at kirei.se Thu Nov 11 03:53:14 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Thu, 11 Nov 2010 03:53:14 -0000 Subject: [Opendnssec-develop] [OpenDNSSEC] #195: Robust handling of external command calls Message-ID: <078.f2f5827705866b97a9d32663151b3f42@kirei.se> #195: Robust handling of external command calls -----------------------------------------------------+---------------------- Reporter: Sebastian Castro | Owner: sion Type: defect | Status: new Priority: minor | Component: Enforcer Version: trunk | Keywords: -----------------------------------------------------+---------------------- If an external command like DelegationSignerSubmitCommand or NotifyCommand fails in a way that goes unnoticed for popen, currently OpenDNSSEC can't detect it. Attached you will find a C code that tries to popen a perl script, which contains a syntax error. Neither popen nor fprintf detect the error, only at pclose a SIGPIPE signal is sent. This means the failure goes under the radar. -- Ticket URL: OpenDNSSEC OpenDNSSEC From rickard.bellgrim at iis.se Thu Nov 11 14:56:27 2010 From: rickard.bellgrim at iis.se (Rickard Bellgrim) Date: Thu, 11 Nov 2010 15:56:27 +0100 Subject: [Opendnssec-develop] [OpenDNSSEC] #195: Robust handling of external command calls In-Reply-To: <078.f2f5827705866b97a9d32663151b3f42@kirei.se> References: <078.f2f5827705866b97a9d32663151b3f42@kirei.se> Message-ID: Any ideas on this one? On 11 nov 2010, at 11.53, OpenDNSSEC wrote: > #195: Robust handling of external command calls > -----------------------------------------------------+---------------------- > Reporter: Sebastian Castro | Owner: sion > Type: defect | Status: new > Priority: minor | Component: Enforcer > Version: trunk | Keywords: > -----------------------------------------------------+---------------------- > If an external command like DelegationSignerSubmitCommand or NotifyCommand > fails in a way that goes unnoticed for popen, currently OpenDNSSEC can't > detect it. > > Attached you will find a C code that tries to popen a perl script, which > contains a syntax error. Neither popen nor fprintf detect the error, only > at pclose a SIGPIPE signal is sent. This means the failure goes under the > radar. > > -- > Ticket URL: > OpenDNSSEC > OpenDNSSEC > From rickard.bellgrim at iis.se Thu Nov 11 16:22:09 2010 From: rickard.bellgrim at iis.se (Rickard Bellgrim) Date: Thu, 11 Nov 2010 17:22:09 +0100 Subject: [Opendnssec-develop] Next release In-Reply-To: References: Message-ID: <043DD0DA-BCC8-4BF8-9BD9-6E376170CA31@iis.se> Hi I am going back from China tomorrow. Will thus not have time to do any testing, or release management. Could you perhaps agree with each other regarding a potential release? And if we have solved the issues? // Rickard On 9 nov 2010, at 17.35, Rickard Bellgrim wrote: > Ok, lets go for this: > > On 9 nov 2010, at 17.10, Rickard Bellgrim wrote: > >> Or wait to e.g. Friday to get an RC1? > From sion at nominet.org.uk Fri Nov 12 08:56:25 2010 From: sion at nominet.org.uk (Sion Lloyd) Date: Fri, 12 Nov 2010 08:56:25 +0000 Subject: [Opendnssec-develop] Next release In-Reply-To: <043DD0DA-BCC8-4BF8-9BD9-6E376170CA31@iis.se> References: <043DD0DA-BCC8-4BF8-9BD9-6E376170CA31@iis.se> Message-ID: <201011120856.26020.sion@nominet.org.uk> On Thursday 11 Nov 2010 4:22:09 pm Rickard Bellgrim wrote: > Hi > > I am going back from China tomorrow. Will thus not have time to do any > testing, or release management. Could you perhaps agree with each other > regarding a potential release? And if we have solved the issues? According to pivotal we have 3 stories to accept, one to finish and one to start... I'm not sure how much work there is left to do to finish those stories? I don't think that we can tag a release with pivotal as it is now though. Sion > On 9 nov 2010, at 17.35, Rickard Bellgrim wrote: > > Ok, lets go for this: > > > > On 9 nov 2010, at 17.10, Rickard Bellgrim wrote: > >> Or wait to e.g. Friday to get an RC1? From AlexD at nominet.org.uk Fri Nov 12 09:08:43 2010 From: AlexD at nominet.org.uk (Alex Dalitz) Date: Fri, 12 Nov 2010 09:08:43 +0000 Subject: [Opendnssec-develop] Next release In-Reply-To: <201011120856.26020.sion@nominet.org.uk> References: <043DD0DA-BCC8-4BF8-9BD9-6E376170CA31@iis.se> <201011120856.26020.sion@nominet.org.uk> Message-ID: <7071B821-5361-4C65-A31D-1D53C3023492@nominet.org.uk> >> I am going back from China tomorrow. Will thus not have time to do any >> testing, or release management. Could you perhaps agree with each other >> regarding a potential release? And if we have solved the issues? > > According to pivotal we have 3 stories to accept, one to finish and one to > start... I'm not sure how much work there is left to do to finish those > stories? I don't think that we can tag a release with pivotal as it is now > though. Well, it might *look* like 5 stories, but actually, there is only one issue left to resolve (which I hope to be able to speak to Matthijs about soon). Once the issue of case has been resolved, I shall release a new dnsruby library, and there will be nothing left in Pivotal. HTH, Alex. From AlexD at nominet.org.uk Fri Nov 12 09:33:58 2010 From: AlexD at nominet.org.uk (Alex Dalitz) Date: Fri, 12 Nov 2010 09:33:58 +0000 Subject: [Opendnssec-develop] Build warnings on OSX Message-ID: Hi - Is this just me? alexs-macbook-pro-2:OpenDNSSEC alex$ svn up At revision 4184. alexs-macbook-pro-2:OpenDNSSEC alex$ sh autogen.sh Creating auditor/version.m4 Creating plugins/eppclient/version.m4 Running autoreconf configure.ac:228: warning: AC_LANG_CONFTEST: no AC_LANG_SOURCE call detected in body ../../lib/autoconf/lang.m4:194: AC_LANG_CONFTEST is expanded from... ../../lib/autoconf/general.m4:2662: _AC_LINK_IFELSE is expanded from... ../../lib/autoconf/general.m4:2679: AC_LINK_IFELSE is expanded from... ../../lib/m4sugar/m4sh.m4:606: AS_IF is expanded from... ../../lib/autoconf/general.m4:2032: AC_CACHE_VAL is expanded from... ../../lib/autoconf/general.m4:2053: AC_CACHE_CHECK is expanded from... m4/acx_libcurl.m4:62: LIBCURL_CHECK_CONFIG is expanded from... configure.ac:228: the top level configure.ac:228: warning: AC_LANG_CONFTEST: no AC_LANG_SOURCE call detected in body ../../lib/autoconf/lang.m4:194: AC_LANG_CONFTEST is expanded from... ../../lib/autoconf/general.m4:2662: _AC_LINK_IFELSE is expanded from... ../../lib/autoconf/general.m4:2679: AC_LINK_IFELSE is expanded from... ../../lib/m4sugar/m4sh.m4:606: AS_IF is expanded from... ../../lib/autoconf/general.m4:2032: AC_CACHE_VAL is expanded from... ../../lib/autoconf/general.m4:2053: AC_CACHE_CHECK is expanded from... m4/acx_libcurl.m4:62: LIBCURL_CHECK_CONFIG is expanded from... configure.ac:228: the top level configure.ac:48: warning: AC_LANG_CONFTEST: no AC_LANG_SOURCE call detected in body ../../lib/autoconf/lang.m4:194: AC_LANG_CONFTEST is expanded from... ../../lib/autoconf/general.m4:2662: _AC_LINK_IFELSE is expanded from... ../../lib/autoconf/general.m4:2679: AC_LINK_IFELSE is expanded from... ../../lib/m4sugar/m4sh.m4:606: AS_IF is expanded from... ../../lib/autoconf/general.m4:2032: AC_CACHE_VAL is expanded from... ../../lib/autoconf/general.m4:2053: AC_CACHE_CHECK is expanded from... m4/acx_libcurl.m4:62: LIBCURL_CHECK_CONFIG is expanded from... configure.ac:48: the top level configure.ac:48: warning: AC_LANG_CONFTEST: no AC_LANG_SOURCE call detected in body ../../lib/autoconf/lang.m4:194: AC_LANG_CONFTEST is expanded from... ../../lib/autoconf/general.m4:2662: _AC_LINK_IFELSE is expanded from... ../../lib/autoconf/general.m4:2679: AC_LINK_IFELSE is expanded from... ../../lib/m4sugar/m4sh.m4:606: AS_IF is expanded from... ../../lib/autoconf/general.m4:2032: AC_CACHE_VAL is expanded from... ../../lib/autoconf/general.m4:2053: AC_CACHE_CHECK is expanded from... m4/acx_libcurl.m4:62: LIBCURL_CHECK_CONFIG is expanded from... configure.ac:48: the top level configure.ac:48: warning: AC_LANG_CONFTEST: no AC_LANG_SOURCE call detected in body ../../lib/autoconf/lang.m4:194: AC_LANG_CONFTEST is expanded from... ../../lib/autoconf/general.m4:2662: _AC_LINK_IFELSE is expanded from... ../../lib/autoconf/general.m4:2679: AC_LINK_IFELSE is expanded from... ../../lib/m4sugar/m4sh.m4:606: AS_IF is expanded from... ../../lib/autoconf/general.m4:2032: AC_CACHE_VAL is expanded from... ../../lib/autoconf/general.m4:2053: AC_CACHE_CHECK is expanded from... m4/acx_libcurl.m4:62: LIBCURL_CHECK_CONFIG is expanded from... configure.ac:48: the top level configure.ac:48: warning: AC_LANG_CONFTEST: no AC_LANG_SOURCE call detected in body ../../lib/autoconf/lang.m4:194: AC_LANG_CONFTEST is expanded from... ../../lib/autoconf/general.m4:2662: _AC_LINK_IFELSE is expanded from... ../../lib/autoconf/general.m4:2679: AC_LINK_IFELSE is expanded from... ../../lib/m4sugar/m4sh.m4:606: AS_IF is expanded from... ../../lib/autoconf/general.m4:2032: AC_CACHE_VAL is expanded from... ../../lib/autoconf/general.m4:2053: AC_CACHE_CHECK is expanded from... m4/acx_libcurl.m4:62: LIBCURL_CHECK_CONFIG is expanded from... configure.ac:48: the top level configure.ac:48: warning: AC_LANG_CONFTEST: no AC_LANG_SOURCE call detected in body ../../lib/autoconf/lang.m4:194: AC_LANG_CONFTEST is expanded from... ../../lib/autoconf/general.m4:2662: _AC_LINK_IFELSE is expanded from... ../../lib/autoconf/general.m4:2679: AC_LINK_IFELSE is expanded from... ../../lib/m4sugar/m4sh.m4:606: AS_IF is expanded from... ../../lib/autoconf/general.m4:2032: AC_CACHE_VAL is expanded from... ../../lib/autoconf/general.m4:2053: AC_CACHE_CHECK is expanded from... m4/acx_libcurl.m4:62: LIBCURL_CHECK_CONFIG is expanded from... configure.ac:48: the top level glibtoolize: putting auxiliary files in `.'. glibtoolize: copying file `./ltmain.sh' glibtoolize: putting macros in AC_CONFIG_MACRO_DIR, `m4'. glibtoolize: copying file `m4/libtool.m4' glibtoolize: copying file `m4/ltoptions.m4' glibtoolize: copying file `m4/ltsugar.m4' glibtoolize: copying file `m4/ltversion.m4' glibtoolize: copying file `m4/lt~obsolete.m4' glibtoolize: `AC_PROG_RANLIB' is rendered obsolete by `LT_INIT' configure.ac:228: warning: AC_LANG_CONFTEST: no AC_LANG_SOURCE call detected in body ../../lib/autoconf/lang.m4:194: AC_LANG_CONFTEST is expanded from... ../../lib/autoconf/general.m4:2662: _AC_LINK_IFELSE is expanded from... ../../lib/autoconf/general.m4:2679: AC_LINK_IFELSE is expanded from... ../../lib/m4sugar/m4sh.m4:606: AS_IF is expanded from... ../../lib/autoconf/general.m4:2032: AC_CACHE_VAL is expanded from... ../../lib/autoconf/general.m4:2053: AC_CACHE_CHECK is expanded from... m4/acx_libcurl.m4:62: LIBCURL_CHECK_CONFIG is expanded from... configure.ac:228: the top level configure.ac:228: warning: AC_LANG_CONFTEST: no AC_LANG_SOURCE call detected in body ../../lib/autoconf/lang.m4:194: AC_LANG_CONFTEST is expanded from... ../../lib/autoconf/general.m4:2662: _AC_LINK_IFELSE is expanded from... ../../lib/autoconf/general.m4:2679: AC_LINK_IFELSE is expanded from... ../../lib/m4sugar/m4sh.m4:606: AS_IF is expanded from... ../../lib/autoconf/general.m4:2032: AC_CACHE_VAL is expanded from... ../../lib/autoconf/general.m4:2053: AC_CACHE_CHECK is expanded from... m4/acx_libcurl.m4:62: LIBCURL_CHECK_CONFIG is expanded from... configure.ac:228: the top level configure.ac:228: warning: AC_LANG_CONFTEST: no AC_LANG_SOURCE call detected in body ../../lib/autoconf/lang.m4:194: AC_LANG_CONFTEST is expanded from... ../../lib/autoconf/general.m4:2662: _AC_LINK_IFELSE is expanded from... ../../lib/autoconf/general.m4:2679: AC_LINK_IFELSE is expanded from... ../../lib/m4sugar/m4sh.m4:606: AS_IF is expanded from... ../../lib/autoconf/general.m4:2032: AC_CACHE_VAL is expanded from... ../../lib/autoconf/general.m4:2053: AC_CACHE_CHECK is expanded from... m4/acx_libcurl.m4:62: LIBCURL_CHECK_CONFIG is expanded from... configure.ac:228: the top level configure.ac:228: warning: AC_LANG_CONFTEST: no AC_LANG_SOURCE call detected in body ../../lib/autoconf/lang.m4:194: AC_LANG_CONFTEST is expanded from... ../../lib/autoconf/general.m4:2662: _AC_LINK_IFELSE is expanded from... ../../lib/autoconf/general.m4:2679: AC_LINK_IFELSE is expanded from... ../../lib/m4sugar/m4sh.m4:606: AS_IF is expanded from... ../../lib/autoconf/general.m4:2032: AC_CACHE_VAL is expanded from... ../../lib/autoconf/general.m4:2053: AC_CACHE_CHECK is expanded from... m4/acx_libcurl.m4:62: LIBCURL_CHECK_CONFIG is expanded from... configure.ac:228: the top level a Thanks, Alex. From matthijs at NLnetLabs.nl Fri Nov 12 10:09:48 2010 From: matthijs at NLnetLabs.nl (Matthijs Mekking) Date: Fri, 12 Nov 2010 11:09:48 +0100 Subject: [Opendnssec-develop] Next release In-Reply-To: <7071B821-5361-4C65-A31D-1D53C3023492@nominet.org.uk> References: <043DD0DA-BCC8-4BF8-9BD9-6E376170CA31@iis.se> <201011120856.26020.sion@nominet.org.uk> <7071B821-5361-4C65-A31D-1D53C3023492@nominet.org.uk> Message-ID: <4CDD126C.2040305@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Two left: - - Up dnsruby version to include fix for RP bug - - Issues when signing ip6.arpa record First is five minutes work for Alex, second is almost certainly an invalid story. So, I think we are ready to do a RC1 (once the two minor stories are accepted). Matthijs On 11/12/2010 10:08 AM, Alex Dalitz wrote: >>> I am going back from China tomorrow. Will thus not have time to do any >>> testing, or release management. Could you perhaps agree with each other >>> regarding a potential release? And if we have solved the issues? >> >> According to pivotal we have 3 stories to accept, one to finish and one to >> start... I'm not sure how much work there is left to do to finish those >> stories? I don't think that we can tag a release with pivotal as it is now >> though. > > Well, it might *look* like 5 stories, but actually, there is only one issue left to resolve (which I hope to be able to speak to Matthijs about soon). > > Once the issue of case has been resolved, I shall release a new dnsruby library, and there will be nothing left in Pivotal. > > HTH, > > > 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.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJM3RJsAAoJEA8yVCPsQCW51K0H/j1IN670sDtBp+SrYGI0c50Z rTjo6WbtLeSfznhnp1UqKf7fqk4Gq/K1GsSWLvEnKlr7uk8h4F8/9Ure/9fwjZgJ mb5eQgh3gol2u7VfaGP0qoJQeIq8Hf1tuZbynY3UapnLa6eALJ60wmkWXN/ijc8z pPwiVVOug+QYoaWw5ZCgVgW4IW8e5KvoNwUss9HZRlep5EuWK9ivqcS9eXb58Fah d1KlqQRffYazzcXhsJ2KNHC2RzMeRWYIfitZyRfyan+7fXr5fbR6xJc8D/1EpKpC tydd387sbNKWkNwJbOjJIPltzsNGCNalqxufvRZNqJ03/zhaBzAflNmqxXBDTVo= =zzWf -----END PGP SIGNATURE----- From AlexD at nominet.org.uk Fri Nov 12 10:14:51 2010 From: AlexD at nominet.org.uk (Alex Dalitz) Date: Fri, 12 Nov 2010 10:14:51 +0000 Subject: [Opendnssec-develop] Next release In-Reply-To: <7071B821-5361-4C65-A31D-1D53C3023492@nominet.org.uk> References: <043DD0DA-BCC8-4BF8-9BD9-6E376170CA31@iis.se> <201011120856.26020.sion@nominet.org.uk> <7071B821-5361-4C65-A31D-1D53C3023492@nominet.org.uk> Message-ID: <4E054874-3B8A-4B23-B318-374D847CB19B@nominet.org.uk> Hi - >>> I am going back from China tomorrow. Will thus not have time to do any >>> testing, or release management. Could you perhaps agree with each other >>> regarding a potential release? And if we have solved the issues? >> >> According to pivotal we have 3 stories to accept, one to finish and one to >> start... I'm not sure how much work there is left to do to finish those >> stories? I don't think that we can tag a release with pivotal as it is now >> though. > > Well, it might *look* like 5 stories, but actually, there is only one issue left to resolve (which I hope to be able to speak to Matthijs about soon). > > Once the issue of case has been resolved, I shall release a new dnsruby library, and there will be nothing left in Pivotal. All Pivotal stories have now been resolved, with the exception of : o new dnsruby release o problems resolving ip6.arpa I can release dnsruby now. I've already upped the required version in ODS to the new version of 1.51. ip6.arpa problems are apprently because the reported failed to install the new version of ODS correctly. It has not been reproduced. I think we are in a good position for a beta/rc1 release. Alex. From jakob at kirei.se Fri Nov 12 10:25:20 2010 From: jakob at kirei.se (Jakob Schlyter) Date: Fri, 12 Nov 2010 11:25:20 +0100 Subject: [Opendnssec-develop] Next release In-Reply-To: <4E054874-3B8A-4B23-B318-374D847CB19B@nominet.org.uk> References: <043DD0DA-BCC8-4BF8-9BD9-6E376170CA31@iis.se> <201011120856.26020.sion@nominet.org.uk> <7071B821-5361-4C65-A31D-1D53C3023492@nominet.org.uk> <4E054874-3B8A-4B23-B318-374D847CB19B@nominet.org.uk> Message-ID: <39AA06CD-6E4C-4D58-A09B-5B0967E21FCE@kirei.se> On 12 nov 2010, at 11.14, Alex Dalitz wrote: > I think we are in a good position for a beta/rc1 release. given the number of recent changes, I'd recommend we release as beta. jakob From AlexD at nominet.org.uk Fri Nov 12 10:31:12 2010 From: AlexD at nominet.org.uk (Alex Dalitz) Date: Fri, 12 Nov 2010 10:31:12 +0000 Subject: [Opendnssec-develop] Next release In-Reply-To: <39AA06CD-6E4C-4D58-A09B-5B0967E21FCE@kirei.se> References: <043DD0DA-BCC8-4BF8-9BD9-6E376170CA31@iis.se> <201011120856.26020.sion@nominet.org.uk> <7071B821-5361-4C65-A31D-1D53C3023492@nominet.org.uk> <4E054874-3B8A-4B23-B318-374D847CB19B@nominet.org.uk> <39AA06CD-6E4C-4D58-A09B-5B0967E21FCE@kirei.se> Message-ID: <1D0801F9-53E3-4C3D-9ED7-E10D9B8D1147@nominet.org.uk> > given the number of recent changes, I'd recommend we release as beta. Sounds good to me. Alex. From matthijs at NLnetLabs.nl Fri Nov 12 10:36:53 2010 From: matthijs at NLnetLabs.nl (Matthijs Mekking) Date: Fri, 12 Nov 2010 11:36:53 +0100 Subject: [Opendnssec-develop] Next release In-Reply-To: <39AA06CD-6E4C-4D58-A09B-5B0967E21FCE@kirei.se> References: <043DD0DA-BCC8-4BF8-9BD9-6E376170CA31@iis.se> <201011120856.26020.sion@nominet.org.uk> <7071B821-5361-4C65-A31D-1D53C3023492@nominet.org.uk> <4E054874-3B8A-4B23-B318-374D847CB19B@nominet.org.uk> <39AA06CD-6E4C-4D58-A09B-5B0967E21FCE@kirei.se> Message-ID: <4CDD18C5.1060600@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 It looks like the number of changes is high, but imo they are all minor fixes. So, because no major issues were encountered, I think we can do a RC. Best regards, Matthijs On 11/12/2010 11:25 AM, Jakob Schlyter wrote: > On 12 nov 2010, at 11.14, Alex Dalitz wrote: > >> I think we are in a good position for a beta/rc1 release. > > given the number of recent changes, I'd recommend we release as beta. > > jakob > > _______________________________________________ > Opendnssec-develop mailing list > Opendnssec-develop at lists.opendnssec.org > https://lists.opendnssec.org/mailman/listinfo/opendnssec-develop -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJM3RjFAAoJEA8yVCPsQCW5Ue0H/A0ttMVKargqRMqSKwVZxxk8 SVFbjNZH6URV5tLSiElNJvq+hn2c6wf/Ad3yjSYKLdm97CzVUAsZeFzsJpl4kol9 tCfu5IxbNQKTzM5bvYovBLxA9LAVGwqcxFdBZx1+SPv78cDGU3Bfop5e028qnZoM ec3ydlXqWtjlTAwcuNsX+/bvQq5gaIzNgQVMpjBlj6EcVIugAsI+eYyMKNKcRpZ3 +MRucAoenMIX0s7Bgwscv+09d8KglX/aUhDWIuhkRuN0HwXUpe/yUxy/gPSFewvy 1G/h9DRZ1PjWScS28oG7xoiVcLyzyhC7DLUoucNfguae852akMUmFuBVNZkpl8U= =fxcy -----END PGP SIGNATURE----- From sion at nominet.org.uk Fri Nov 12 11:05:08 2010 From: sion at nominet.org.uk (Sion Lloyd) Date: Fri, 12 Nov 2010 11:05:08 +0000 Subject: [Opendnssec-develop] Next release In-Reply-To: <4CDD18C5.1060600@nlnetlabs.nl> References: <39AA06CD-6E4C-4D58-A09B-5B0967E21FCE@kirei.se> <4CDD18C5.1060600@nlnetlabs.nl> Message-ID: <201011121105.08766.sion@nominet.org.uk> On Friday 12 Nov 2010 10:36:53 am Matthijs Mekking wrote: > It looks like the number of changes is high, but imo they are all minor > fixes. So, because no major issues were encountered, I think we can do a > RC. > > Best regards, > > Matthijs > > On 11/12/2010 11:25 AM, Jakob Schlyter wrote: > > On 12 nov 2010, at 11.14, Alex Dalitz wrote: > >> I think we are in a good position for a beta/rc1 release. > > > > given the number of recent changes, I'd recommend we release as beta. I do not have a strong feeling one way or the other. We have said in the past that if pivotal is clear then we will call it RC1. If that changes because we had bug reports come in yesterday then it has to be a beta. Sion From AlexD at nominet.org.uk Fri Nov 12 15:46:30 2010 From: AlexD at nominet.org.uk (Alex Dalitz) Date: Fri, 12 Nov 2010 15:46:30 +0000 Subject: [Opendnssec-develop] Next release In-Reply-To: <39AA06CD-6E4C-4D58-A09B-5B0967E21FCE@kirei.se> References: <043DD0DA-BCC8-4BF8-9BD9-6E376170CA31@iis.se> <201011120856.26020.sion@nominet.org.uk> <7071B821-5361-4C65-A31D-1D53C3023492@nominet.org.uk> <4E054874-3B8A-4B23-B318-374D847CB19B@nominet.org.uk> <39AA06CD-6E4C-4D58-A09B-5B0967E21FCE@kirei.se> Message-ID: > given the number of recent changes, I'd recommend we release as beta. Well, I think we should release *something* today. If there's no positive consensus for a release candidate, then can we please push out a beta? Thanks, Alex. From yuri at NLnetLabs.nl Mon Nov 15 11:46:28 2010 From: yuri at NLnetLabs.nl (Yuri Schaeffer) Date: Mon, 15 Nov 2010 12:46:28 +0100 Subject: [Opendnssec-develop] Formal Key Transitions for Enforcer Message-ID: <4CE11D94.5070103@nlnetlabs.nl> Hi all, Attached [1] you will find a formal write up of key transitions. It uses a cache-centered approach. I took the idea to unravel the key states as Matthijs proposed and generalized it a bit more. This system tries to maintain a valid DNSSEC configuration while moving keys towards a goal. Algorithm/policy/etc rollovers are only implicit. Note that this is a work in progress, it represents the current state in my head, which changes every day. At this point an implementation would roll the keys as quick as possible without the zone going bogus. Additional constraints for different types of rollovers are not yet introduced, but will be. some features: - Policy, key store, etc rollovers are nothing special - Can interrupt a rollover safely at any point in time to start a new rollover. - Hard rollovers (e.g. going to a single key AND change algorithm) are not special cases and _should_ just work (absolutely untested at this point though). - easy to parallelize, there is no strict connection between policy and state. Ren? is currently writing test code to see if this could work in practice. If so, it might form a basis for an Enforcer implementation. //yuri [1] Hope nobody minds me posting binaries to the list... -- Yuri Schaeffer NLnet Labs http://www.nlnetlabs.nl -------------- next part -------------- A non-text attachment was scrubbed... Name: key_states.tar.gz Type: application/x-gzip Size: 215272 bytes Desc: not available URL: From rickard.bellgrim at iis.se Mon Nov 15 12:07:34 2010 From: rickard.bellgrim at iis.se (Rickard Bellgrim) Date: Mon, 15 Nov 2010 13:07:34 +0100 Subject: [Opendnssec-develop] Doodle: Next OpenDNSSEC meeting In-Reply-To: References: Message-ID: On 5 nov 2010, at 12.42, Rickard Bellgrim wrote: > Hi > > When should we have the next telephone meeting? > > Please vote here: > http://www.doodle.com/gi24uest2eqcz2kr Is it only Jakob, Sion, Alex and me who want to have a telephone meeting? // Rickard From rickard.bellgrim at iis.se Mon Nov 15 12:11:47 2010 From: rickard.bellgrim at iis.se (Rickard Bellgrim) Date: Mon, 15 Nov 2010 13:11:47 +0100 Subject: [Opendnssec-develop] Next release In-Reply-To: References: <043DD0DA-BCC8-4BF8-9BD9-6E376170CA31@iis.se> <201011120856.26020.sion@nominet.org.uk> <7071B821-5361-4C65-A31D-1D53C3023492@nominet.org.uk> <4E054874-3B8A-4B23-B318-374D847CB19B@nominet.org.uk> <39AA06CD-6E4C-4D58-A09B-5B0967E21FCE@kirei.se> Message-ID: <5EE3C93C-FA53-4529-BCA4-91411D3BE0E7@iis.se> On 12 nov 2010, at 16.46, Alex Dalitz wrote: > Well, I think we should release *something* today. If there's no positive consensus for a release candidate, then can we please push out a beta? I haven't had the chance yet to have a look on the latest changes. I can do some last tests after 16.30. But it feels like we can have a release today / tomorrow. Jakob wants to have a beta2. Others are aiming for rc1. I also agree that the changes that we have done are minor, and should not stop a rc1. Any other thoughts? // Rickard From jakob at kirei.se Mon Nov 15 12:19:36 2010 From: jakob at kirei.se (Jakob Schlyter) Date: Mon, 15 Nov 2010 13:19:36 +0100 Subject: [Opendnssec-develop] Next release In-Reply-To: <5EE3C93C-FA53-4529-BCA4-91411D3BE0E7@iis.se> References: <043DD0DA-BCC8-4BF8-9BD9-6E376170CA31@iis.se> <201011120856.26020.sion@nominet.org.uk> <7071B821-5361-4C65-A31D-1D53C3023492@nominet.org.uk> <4E054874-3B8A-4B23-B318-374D847CB19B@nominet.org.uk> <39AA06CD-6E4C-4D58-A09B-5B0967E21FCE@kirei.se> <5EE3C93C-FA53-4529-BCA4-91411D3BE0E7@iis.se> Message-ID: <95415F97-D0C1-41E8-8A5C-D2B1572CC1B4@kirei.se> On 15 nov 2010, at 13.11, Rickard Bellgrim wrote: > Jakob wants to have a beta2. Others are aiming for rc1. I also agree that the changes that we have done are minor, and should not stop a rc1. Any other thoughts? if I'm the only one thinking about beta2, I will not make any fuzz and we can do rc1. j From matthijs at NLnetLabs.nl Mon Nov 15 13:32:11 2010 From: matthijs at NLnetLabs.nl (Matthijs Mekking) Date: Mon, 15 Nov 2010 14:32:11 +0100 Subject: [Opendnssec-develop] Doodle: Next OpenDNSSEC meeting In-Reply-To: References: Message-ID: <4CE1365B.6010908@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Sorry, I totally have missed the doodle. Filled in now. On 11/15/2010 01:07 PM, Rickard Bellgrim wrote: > > On 5 nov 2010, at 12.42, Rickard Bellgrim wrote: > >> Hi >> >> When should we have the next telephone meeting? >> >> Please vote here: >> http://www.doodle.com/gi24uest2eqcz2kr > > Is it only Jakob, Sion, Alex and me who want to have a telephone meeting? > > // Rickard > _______________________________________________ > Opendnssec-develop mailing list > Opendnssec-develop at lists.opendnssec.org > https://lists.opendnssec.org/mailman/listinfo/opendnssec-develop > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJM4TZbAAoJEA8yVCPsQCW5T/0H/jdkk36KuItetvfqsoHZSBgg qZHQWzQxvgVOWV7/1YUcQQh7Mbk3AjDolSNOsdrhOEGj2zbUnH+bVazKkprE9XH6 xfpWZ2fCKmUPv63dRhCQHDxe83GzAgVf7yVLxcFi3HxaoFJh8Gmv8pcGNWFJmUkE EPLnTXmx2CbjQz2RM4RexroBRg874M5ARU2iXOTdHBzVFzScAlZBbUexKqovLxeW Vw81xkrB6Y0dqz1st+jVyZrF3RuuPI7NKK7SgeYn9vZ1Rc5jDbXKTuu6hFj5oM1j QEXA86wk6odKnDFTZV22EtEqF01Z8vaTUyRJkcRXXtoyi+FVNIQ2t5z/iU9tYKo= =UeRo -----END PGP SIGNATURE----- From rickard.bellgrim at iis.se Mon Nov 15 15:08:20 2010 From: rickard.bellgrim at iis.se (Rickard Bellgrim) Date: Mon, 15 Nov 2010 16:08:20 +0100 Subject: [Opendnssec-develop] Enforcer Design Message-ID: <932DA7D7-E235-44FD-9B88-3C4E41A60A90@iis.se> Hi You have probably seen the document from Yuri where he describe how state changes could be done in the Enforcer. Yuri and Ren? will continue with this work, but will also create an overview of the design. Thus making it possible to make an estimate on the work effort needed to develop Enforcer v1.3. There are some separate telephone meetings coming up regarding the Enforcer Design (December 2 11:00-12:30 CET). It is separate from the regular OpenDNSSEC meetings because it is all about the design ideas, current progress, and not about the OpenDNSSEC development. You are welcome to attend if you feel the need. Just send an email to Roland, and he will give you the contact details. Don't worry, the ideas will be presented to you once it has been discussed and tested some more. // Rickard From rickard.bellgrim at iis.se Mon Nov 15 15:38:28 2010 From: rickard.bellgrim at iis.se (Rickard Bellgrim) Date: Mon, 15 Nov 2010 16:38:28 +0100 Subject: [Opendnssec-develop] Doodle: Next OpenDNSSEC meeting In-Reply-To: References: Message-ID: <9EF44DCD-CD43-4068-A0F1-5FB6D8BD72C0@iis.se> Hi We will have the next telephone meeting on Friday, 14:00-15:00 CET. // Rickard On 15 nov 2010, at 13.07, Rickard Bellgrim wrote: When should we have the next telephone meeting? Please vote here: http://www.doodle.com/gi24uest2eqcz2kr Is it only Jakob, Sion, Alex and me who want to have a telephone meeting? -------------- next part -------------- An HTML attachment was scrubbed... URL: From owner-dnssec-trac at kirei.se Mon Nov 15 16:16:17 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Mon, 15 Nov 2010 16:16:17 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #190: Auditor does not handle case correctly In-Reply-To: <077.b6efec6ceaccc4547ba0dc59436222ae@kirei.se> References: <077.b6efec6ceaccc4547ba0dc59436222ae@kirei.se> Message-ID: <086.6a04f162b6181560213917166a356aa5@kirei.se> #190: Auditor does not handle case correctly -----------------------------------------------------+---------------------- Reporter: Marc Dequ?nes (Duck) | Owner: alex Type: defect | Status: closed Priority: major | Component: Auditor Version: trunk | Resolution: fixed Keywords: | -----------------------------------------------------+---------------------- Changes (by rb): * status: assigned => closed * resolution: => fixed Comment: Thanks, now fixed in trunk -- Ticket URL: OpenDNSSEC OpenDNSSEC From rickard.bellgrim at iis.se Tue Nov 16 07:07:50 2010 From: rickard.bellgrim at iis.se (Rickard Bellgrim) Date: Tue, 16 Nov 2010 08:07:50 +0100 Subject: [Opendnssec-develop] Enforcer Design In-Reply-To: <932DA7D7-E235-44FD-9B88-3C4E41A60A90@iis.se> References: <932DA7D7-E235-44FD-9B88-3C4E41A60A90@iis.se> Message-ID: <87572D97-C4DA-4023-9DFA-C4E19929B44F@iis.se> The meeting time has change to December 1 (Wednesday), 11:00-12:30 CET. On 15 nov 2010, at 16.08, Rickard Bellgrim wrote: > There are some separate telephone meetings coming up regarding the Enforcer Design (December 2 11:00-12:30 CET). It is separate from the regular OpenDNSSEC meetings because it is all about the design ideas, current progress, and not about the OpenDNSSEC development. You are welcome to attend if you feel the need. Just send an email to Roland, and he will give you the contact details. From rickard.bellgrim at iis.se Tue Nov 16 07:19:28 2010 From: rickard.bellgrim at iis.se (Rickard Bellgrim) Date: Tue, 16 Nov 2010 08:19:28 +0100 Subject: [Opendnssec-develop] Sessions with network HSM:s Message-ID: <30C9FF79-DCFF-4633-8B6D-4ED5BAEF911E@iis.se> Hi SIDN is having some problems with their HSM, because it closes a session if it has been idle for too long time. E.g. key generation every third month. We have also seen this during the evaluations of the HSMs. It is Utimaco and SafeNet who close their session/TCP-connection if it has been idle for too long. But AEP and Thales can have its session open without any disruption. Utimaco recommended us having a heartbeat mechanism for keeping the session alive. Is this the correct way to go? Or should the HSM vendor make sure to implement a heartbeat mechanism in their own library? // Rickard From rick at openfortress.nl Tue Nov 16 08:07:10 2010 From: rick at openfortress.nl (Rick van Rein) Date: Tue, 16 Nov 2010 08:07:10 +0000 Subject: [Opendnssec-develop] Sessions with network HSM:s In-Reply-To: <30C9FF79-DCFF-4633-8B6D-4ED5BAEF911E@iis.se> References: <30C9FF79-DCFF-4633-8B6D-4ED5BAEF911E@iis.se> Message-ID: <20101116080710.GB31240@phantom.vanrein.org> Hello, > SIDN is having some problems with their HSM, because it closes a session if it has been idle for too long time. E.g. key generation every third month. Linux can do keepalives on TCP connections through sysctl, but even in a world dominated by NAT this may not be wise to assume in general. net.ipv4.tcp_keepalive_time = 7200 net.ipv4.tcp_keepalive_probes = 9 net.ipv4.tcp_keepalive_intvl = 75 There also is an SO_KEEPALIVE according to http://www.mkssoftware.com/docs/man3/setsockopt.3.asp and/or an option in looking like #define TCP_KEEPIDLE 4 /* Start keeplives after this period */ but I don't know how general these are. It might be improper to dictate the user's choice of OS/HSM combination. What is the problem in reopening the connection if it died? There is an explicit PIN in the configuration, and if access to that has been given up by lowering rights (I don't know if that is done yet) then we could have the PIN agent that we discussed long ago and that somehow has disappeared since then. That is a general solution, and I still think it is a proper design. I sent example code that can even validate that only the right programs can access the PIN, which is possible with SysV mechanisms. Detection of closed sockets is trivial from the error return values, like ECONNRESET on Linux (and probably other OS's too). > Utimaco recommended us having a heartbeat mechanism for keeping the session alive. > > Is this the correct way to go? Or should the HSM vendor make sure to implement a heartbeat mechanism in their own library? Why not just reconnect a lost connection? That solves such HSM problems and, at the same time, network disruptions. We have a redundany layer underneath PKCS #11 doing this for us, so I hadn't noticed this problem on our SafeNet HSMs. Cheers, -Rick From rick at openfortress.nl Tue Nov 16 08:09:53 2010 From: rick at openfortress.nl (Rick van Rein) Date: Tue, 16 Nov 2010 08:09:53 +0000 Subject: [Opendnssec-develop] Sessions with network HSM:s In-Reply-To: <20101116080710.GB31240@phantom.vanrein.org> References: <30C9FF79-DCFF-4633-8B6D-4ED5BAEF911E@iis.se> <20101116080710.GB31240@phantom.vanrein.org> Message-ID: <20101116080953.GC31240@phantom.vanrein.org> Oh, What I forgot to add: TCP keepalives are packets that add 0 bytes to the TCP connection. It may not even be safe to assume that an HSM will see that as an update to their connection. If anything, then HSMs are more rigorous inspectors of networking traffic :) -Rick From jakob at kirei.se Tue Nov 16 08:20:26 2010 From: jakob at kirei.se (Jakob Schlyter) Date: Tue, 16 Nov 2010 09:20:26 +0100 Subject: [Opendnssec-develop] Sessions with network HSM:s In-Reply-To: <30C9FF79-DCFF-4633-8B6D-4ED5BAEF911E@iis.se> References: <30C9FF79-DCFF-4633-8B6D-4ED5BAEF911E@iis.se> Message-ID: <58D9F52E-364B-4CEB-9059-184DE935ED02@kirei.se> On 16 nov 2010, at 08.19, Rickard Bellgrim wrote: > SIDN is having some problems with their HSM, because it closes a session if it has been idle for too long time. E.g. key generation every third month. > > We have also seen this during the evaluations of the HSMs. It is Utimaco and SafeNet who close their session/TCP-connection if it has been idle for too long. But AEP and Thales can have its session open without any disruption. > > Utimaco recommended us having a heartbeat mechanism for keeping the session alive. > > Is this the correct way to go? Or should the HSM vendor make sure to implement a heartbeat mechanism in their own library? Should we have the enforcer "ping" libhsm every once in a while? If so, we might want to implement a hsm_ping() function just to make sure the connection is alive. jakob From rickard.bellgrim at iis.se Tue Nov 16 08:42:22 2010 From: rickard.bellgrim at iis.se (Rickard Bellgrim) Date: Tue, 16 Nov 2010 09:42:22 +0100 Subject: [Opendnssec-develop] Sessions with network HSM:s In-Reply-To: <58D9F52E-364B-4CEB-9059-184DE935ED02@kirei.se> References: <30C9FF79-DCFF-4633-8B6D-4ED5BAEF911E@iis.se> <58D9F52E-364B-4CEB-9059-184DE935ED02@kirei.se> Message-ID: <096E0F20-5F9B-4C72-845E-20C9A66693D0@iis.se> On 16 nov 2010, at 09.20, Jakob Schlyter wrote: > Should we have the enforcer "ping" libhsm every once in a while? If so, we might want to implement a hsm_ping() function just to make sure the connection is alive. Or have a separate thread in libhsm taking care of the ping? // Rickard From rickard.bellgrim at iis.se Tue Nov 16 09:21:20 2010 From: rickard.bellgrim at iis.se (Rickard Bellgrim) Date: Tue, 16 Nov 2010 10:21:20 +0100 Subject: [Opendnssec-develop] Next release In-Reply-To: <5EE3C93C-FA53-4529-BCA4-91411D3BE0E7@iis.se> References: <043DD0DA-BCC8-4BF8-9BD9-6E376170CA31@iis.se> <201011120856.26020.sion@nominet.org.uk> <7071B821-5361-4C65-A31D-1D53C3023492@nominet.org.uk> <4E054874-3B8A-4B23-B318-374D847CB19B@nominet.org.uk> <39AA06CD-6E4C-4D58-A09B-5B0967E21FCE@kirei.se> <5EE3C93C-FA53-4529-BCA4-91411D3BE0E7@iis.se> Message-ID: <0E84E707-776A-4077-BCEC-B9A4CEC48EFE@iis.se> Hi Are we ready to do a release today? Only thing I can find is this: http://trac.opendnssec.org/ticket/195 Can this be saved for later? // Rickard On 15 nov 2010, at 13.11, Rickard Bellgrim wrote: > But it feels like we can have a release today / tomorrow. From sion at nominet.org.uk Tue Nov 16 09:36:29 2010 From: sion at nominet.org.uk (Sion Lloyd) Date: Tue, 16 Nov 2010 09:36:29 +0000 Subject: [Opendnssec-develop] Next release In-Reply-To: <0E84E707-776A-4077-BCEC-B9A4CEC48EFE@iis.se> References: <5EE3C93C-FA53-4529-BCA4-91411D3BE0E7@iis.se> <0E84E707-776A-4077-BCEC-B9A4CEC48EFE@iis.se> Message-ID: <201011160936.29836.sion@nominet.org.uk> On Tuesday 16 Nov 2010 9:21:20 am Rickard Bellgrim wrote: > Hi > > Are we ready to do a release today? > > Only thing I can find is this: > http://trac.opendnssec.org/ticket/195 > > Can this be saved for later? We could leave a known issue saying that external commands need to log enough information for the user to tell if it worked? Sion From antoin.verschuren at sidn.nl Tue Nov 16 09:41:10 2010 From: antoin.verschuren at sidn.nl (Antoin Verschuren) Date: Tue, 16 Nov 2010 10:41:10 +0100 Subject: [Opendnssec-develop] Sessions with network HSM:s In-Reply-To: <20101116080710.GB31240@phantom.vanrein.org> References: <30C9FF79-DCFF-4633-8B6D-4ED5BAEF911E@iis.se> <20101116080710.GB31240@phantom.vanrein.org> Message-ID: <4CE251B6.4070802@sidn.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 16-11-10 09:07, Rick van Rein wrote: > > What is the problem in reopening the connection if it died? According to the SafeNet documentation, this is I think the way to go. It not only solves the issue when the connection simply timed out, but can also recover network glitches. The network glitches don't need to be between the enforcer and the HSM. We use HSM's in a pool, and when one of the connections between the HSM's is lost, it will also give an error back to the enforcer, refusing to accept the command, and then restoring the connection between the HSM's using autorecovery. Reissuing the command by the enforcer a little bit later is better than simply dying: - --- ORIGINAL DOCUMENTATION: --- Ch11 - HA Implementing HA If you use the Luna SA HA feature then the calls to the Luna SAs are load-balanced. The session handle that the application receives when it opens a session is a virtual one and is managed by the HA code in the library. The actual sessions with the HSM are established by the HA code in the library and hidden from the application and will come and go as necessary to fulfill application level requests. Before the introduction of HA AutoRecovery, bringing a failed/lost group member back into the group (recovery) was a manual procedure. The Administration & Maintenance section contains a general description of the how the HA AutoRecovery function works, in practice. For every PKCS11 call, the HA recover logic will check to see if we need to perform auto recovery to a disconnected appliance. If there is a disconnected appliance then it will try to reconnect to that appliance before it proceeds with the current PKCS11 call. The HA recovery logic is designed in such a way that it will only try to reconnection to an appliance every X secs and N number of times where X and N are configurable via the "VTL" utility. The following is the pseudo code of the HA logic if (disconnected_member > 0 and recover_attempt_count < N and time_now - last_recover_attempt > X) then performance auto recovery set last_recover_attempt equal to time_now if (recovery failed) then increment recover_attempt_count by 1 else decrement disconnected_member by 1 reset recover_attempt_count to 0 end if end if The HA auto recovery design runs within a pkcs11 call. The responsiveness of recovering a disconnected member is greatly influenced by the frequency of PKCS11 calls from the user application. Although the logic shows that it will attempt to recover a disconnected client in X secs, in reality, it will not run until the user application makes the next PKCS11 call. How Does Your Software Know That a Member Has Failed? When an HA Group member first fails, the HA status for the group shows "device error" for the failed member. All subsequent calls return "token not present", until the member (HSM Partition or PKI token) is returned to service. Here is an example of two such calls using CKDemo: Enter your choice : 52 Slots available: slot#1 - LunaNet Slot slot#2 - LunaNet Slot slot#3 - HA Virtual Card Slot Select a slot: 3 HA group 1599447001 status: HSM 599447001 - CKR_DEVICE_ERROR HSM 78665001 - CKR_OK Status: Doing great, no errors (CKR_OK) Enter your choice : 52 Slots available: slot#1 - LunaNet Slot slot#2 - LunaNet Slot slot#3 - HA Virtual Card Slot Select a slot: 3 HA group 1599447001 status: HSM 599447001 - CKR_TOKEN_NOT_PRESENT HSM 78665001 - CKR_OK Status: Doing great, no errors (CKR_OK) - --- End of ORIGINAL DOCUMENTATION --- > Why not just reconnect a lost connection? That solves such HSM problems and, > at the same time, network disruptions. We have a redundany layer underneath > PKCS #11 doing this for us, so I hadn't noticed this problem on our SafeNet > HSMs. The reason why you probably don't see this often is because you maintain more signatures. We only have one KSK that only changes once every 5 years, or surprise rollovers, and one ZSK changing every 3 months. Roland told me he had seen the CKR_TOKEN_NOT_PRESENT error once, probably that was also due to a lost connection because of a network glitch between more HSM's in a pool. - -- Antoin Verschuren Technical Policy Advisor SIDN Utrechtseweg 310, PO Box 5022, 6802 EA Arnhem, The Netherlands P: +31 26 3525500 F: +31 26 3525505 M: +31 6 23368970 mailto:antoin.verschuren at sidn.nl xmpp:antoin at jabber.sidn.nl http://www.sidn.nl/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQEcBAEBAgAGBQJM4lGvAAoJEDqHrM883Agn0dQH/RRAy7Wttpot2Ca1DX1Oqc+2 1vXtIR0DQRYcJjPAOIk3EtCTtPArOYh1LXw1G7FtgE4crEPQpk5MmBhsBf63a9BJ AqVN7lUm6m7nHmk61O8DdoAIKZCLzLLDLVd0P6vumbT5c8CAWJpg6GW1LVpx7Wgu vrFK7EC1bHMopqL/nZbabFY/4H9e/wg075AdBmqyX4XOXfnufUffhWURoF3KAijz MwIv0rhc6lHAze/YdCsLwJxAvfNcGIMq4kDhIaJMWSeBLKW3nHgqYA2XFGczljsG nM8gAAIEYw5fXTkFwdGysffoeITsOJIKKJMKssnc+lHucjolS3TtliIvMVJIgqU= =8vqH -----END PGP SIGNATURE----- From Roland.vanRijswijk at surfnet.nl Tue Nov 16 09:52:09 2010 From: Roland.vanRijswijk at surfnet.nl (Roland van Rijswijk) Date: Tue, 16 Nov 2010 10:52:09 +0100 Subject: [Opendnssec-develop] Sessions with network HSM:s In-Reply-To: <4CE251B6.4070802@sidn.nl> References: <30C9FF79-DCFF-4633-8B6D-4ED5BAEF911E@iis.se> <20101116080710.GB31240@phantom.vanrein.org> <4CE251B6.4070802@sidn.nl> Message-ID: <5AFD9095-00B0-44A4-A5AB-80B3ABB5C843@surfnet.nl> Short answer to a long & detailed (thanks for the info) story: I agree with Antoin, OpenDNSSEC should deal in a graceful way with this error rather than just terminating the Enforcer. A back-off and retry is warranted here, also keeping in mind the wish of some users to have offline repositories (which will also lead to CKR_TOKEN_NOT_PRESENT). Just my 2 cents ;-) Cheers, Roland On 16 nov 2010, at 10:41, Antoin Verschuren wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 16-11-10 09:07, Rick van Rein wrote: >> >> What is the problem in reopening the connection if it died? > > According to the SafeNet documentation, this is I think the way to go. > It not only solves the issue when the connection simply timed out, but > can also recover network glitches. > The network glitches don't need to be between the enforcer and the HSM. > We use HSM's in a pool, and when one of the connections between the > HSM's is lost, it will also give an error back to the enforcer, refusing > to accept the command, and then restoring the connection between the > HSM's using autorecovery. Reissuing the command by the enforcer a little > bit later is better than simply dying: > > - --- ORIGINAL DOCUMENTATION: --- > Ch11 - HA > > Implementing HA > > If you use the Luna SA HA feature then the calls to the Luna SAs are > load-balanced. The session handle that the application receives when it > opens a session is a virtual one and is managed by the HA code in the > library. The actual sessions with the HSM are established by the HA code > in the library and hidden from the application and will come and go as > necessary to fulfill application level requests. > > Before the introduction of HA AutoRecovery, bringing a failed/lost group > member back into the group (recovery) was a manual procedure. > > The Administration & Maintenance section contains a general description > of the how the HA AutoRecovery function works, in practice. > > For every PKCS11 call, the HA recover logic will check to see if we need > to perform auto recovery to a disconnected appliance. If there is a > disconnected appliance then it will try to reconnect to that appliance > before it proceeds with the current PKCS11 call. > > The HA recovery logic is designed in such a way that it will only try to > reconnection to an appliance every X secs and N number of times where X > and N are configurable via the "VTL" utility. The following is the > pseudo code of the HA logic > > if (disconnected_member > 0 and recover_attempt_count < N and time_now - > last_recover_attempt > X) then > performance auto recovery > set last_recover_attempt equal to time_now > if (recovery failed) then > increment recover_attempt_count by 1 > else > decrement disconnected_member by 1 > reset recover_attempt_count to 0 > end if > end if > > The HA auto recovery design runs within a pkcs11 call. The > responsiveness of recovering a disconnected member is greatly influenced > by the frequency of PKCS11 calls from the user application. Although the > logic shows that it will attempt to recover a disconnected client in X > secs, in reality, it will not run until the user application makes the > next PKCS11 call. > > How Does Your Software Know That a Member Has Failed? > > When an HA Group member first fails, the HA status for the group shows > "device error" for the failed member. All subsequent calls return "token > not present", until the member (HSM Partition or PKI token) is returned > to service. > > Here is an example of two such calls using CKDemo: > > Enter your choice : 52 > > Slots available: > slot#1 - LunaNet Slot > > slot#2 - LunaNet Slot > > slot#3 - HA Virtual Card Slot > > Select a slot: 3 > > HA group 1599447001 status: > > HSM 599447001 - CKR_DEVICE_ERROR > HSM 78665001 - CKR_OK > Status: Doing great, no errors (CKR_OK) > > > > Enter your choice : 52 > > Slots available: > slot#1 - LunaNet Slot > slot#2 - LunaNet Slot > slot#3 - HA Virtual Card Slot > > Select a slot: 3 > > HA group 1599447001 status: > > HSM 599447001 - CKR_TOKEN_NOT_PRESENT > HSM 78665001 - CKR_OK > Status: Doing great, no errors (CKR_OK) > - --- End of ORIGINAL DOCUMENTATION --- > > >> Why not just reconnect a lost connection? That solves such HSM problems and, >> at the same time, network disruptions. We have a redundany layer underneath >> PKCS #11 doing this for us, so I hadn't noticed this problem on our SafeNet >> HSMs. > > The reason why you probably don't see this often is because you maintain > more signatures. We only have one KSK that only changes once every 5 > years, or surprise rollovers, and one ZSK changing every 3 months. > Roland told me he had seen the CKR_TOKEN_NOT_PRESENT error once, > probably that was also due to a lost connection because of a network > glitch between more HSM's in a pool. > > - -- > Antoin Verschuren > > Technical Policy Advisor SIDN > Utrechtseweg 310, PO Box 5022, 6802 EA Arnhem, The Netherlands > > P: +31 26 3525500 F: +31 26 3525505 M: +31 6 23368970 > mailto:antoin.verschuren at sidn.nl xmpp:antoin at jabber.sidn.nl > http://www.sidn.nl/ > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.10 (GNU/Linux) > > iQEcBAEBAgAGBQJM4lGvAAoJEDqHrM883Agn0dQH/RRAy7Wttpot2Ca1DX1Oqc+2 > 1vXtIR0DQRYcJjPAOIk3EtCTtPArOYh1LXw1G7FtgE4crEPQpk5MmBhsBf63a9BJ > AqVN7lUm6m7nHmk61O8DdoAIKZCLzLLDLVd0P6vumbT5c8CAWJpg6GW1LVpx7Wgu > vrFK7EC1bHMopqL/nZbabFY/4H9e/wg075AdBmqyX4XOXfnufUffhWURoF3KAijz > MwIv0rhc6lHAze/YdCsLwJxAvfNcGIMq4kDhIaJMWSeBLKW3nHgqYA2XFGczljsG > nM8gAAIEYw5fXTkFwdGysffoeITsOJIKKJMKssnc+lHucjolS3TtliIvMVJIgqU= > =8vqH > -----END PGP SIGNATURE----- > _______________________________________________ > Opendnssec-develop mailing list > Opendnssec-develop at lists.opendnssec.org > https://lists.opendnssec.org/mailman/listinfo/opendnssec-develop -- Roland M. van Rijswijk -- SURFnet Middleware Services -- t: +31-30-2305388 -- e: roland.vanrijswijk at surfnet.nl From rickard.bellgrim at iis.se Tue Nov 16 09:53:10 2010 From: rickard.bellgrim at iis.se (Rickard Bellgrim) Date: Tue, 16 Nov 2010 10:53:10 +0100 Subject: [Opendnssec-develop] Next release In-Reply-To: <201011160936.29836.sion@nominet.org.uk> References: <5EE3C93C-FA53-4529-BCA4-91411D3BE0E7@iis.se> <0E84E707-776A-4077-BCEC-B9A4CEC48EFE@iis.se> <201011160936.29836.sion@nominet.org.uk> Message-ID: <677B2785-DF0F-47EC-BFBE-E43E032BC30B@iis.se> On 16 nov 2010, at 10.36, Sion Lloyd wrote: > We could leave a known issue saying that external commands need to log enough > information for the user to tell if it worked? Yes, that is a good solution. Could you do this? And also add a section in the NEWS-file on how to migrate the database from v1.1.3 to v1.2? Just so that we have a summery. // Rickard From rickard.bellgrim at iis.se Tue Nov 16 12:17:33 2010 From: rickard.bellgrim at iis.se (Rickard Bellgrim) Date: Tue, 16 Nov 2010 13:17:33 +0100 Subject: [Opendnssec-develop] Next release In-Reply-To: <0E84E707-776A-4077-BCEC-B9A4CEC48EFE@iis.se> References: <043DD0DA-BCC8-4BF8-9BD9-6E376170CA31@iis.se> <201011120856.26020.sion@nominet.org.uk> <7071B821-5361-4C65-A31D-1D53C3023492@nominet.org.uk> <4E054874-3B8A-4B23-B318-374D847CB19B@nominet.org.uk> <39AA06CD-6E4C-4D58-A09B-5B0967E21FCE@kirei.se> <5EE3C93C-FA53-4529-BCA4-91411D3BE0E7@iis.se> <0E84E707-776A-4077-BCEC-B9A4CEC48EFE@iis.se> Message-ID: <954FDAE3-5B68-466F-81EE-B91B5061B632@iis.se> On 16 nov 2010, at 10.21, Rickard Bellgrim wrote: > Are we ready to do a release today? NEWS, KNOWN_ISSUES, and the documentation is now update to date. // Rickard From rickard.bellgrim at iis.se Tue Nov 16 13:03:27 2010 From: rickard.bellgrim at iis.se (Rickard Bellgrim) Date: Tue, 16 Nov 2010 14:03:27 +0100 Subject: [Opendnssec-develop] Next release In-Reply-To: <954FDAE3-5B68-466F-81EE-B91B5061B632@iis.se> References: <043DD0DA-BCC8-4BF8-9BD9-6E376170CA31@iis.se> <201011120856.26020.sion@nominet.org.uk> <7071B821-5361-4C65-A31D-1D53C3023492@nominet.org.uk> <4E054874-3B8A-4B23-B318-374D847CB19B@nominet.org.uk> <39AA06CD-6E4C-4D58-A09B-5B0967E21FCE@kirei.se> <5EE3C93C-FA53-4529-BCA4-91411D3BE0E7@iis.se> <0E84E707-776A-4077-BCEC-B9A4CEC48EFE@iis.se> <954FDAE3-5B68-466F-81EE-B91B5061B632@iis.se> Message-ID: <500865CA-B310-4E07-9139-48572882CC5C@iis.se> Jakob, could you perhaps do a test build on Solaris, tag a release, and upload a tarball of rc1? On 16 nov 2010, at 13.17, Rickard Bellgrim wrote: > > On 16 nov 2010, at 10.21, Rickard Bellgrim wrote: > >> Are we ready to do a release today? > > NEWS, KNOWN_ISSUES, and the documentation is now update to date. > > // Rickard > From owner-dnssec-trac at kirei.se Wed Nov 17 21:59:31 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Wed, 17 Nov 2010 21:59:31 -0000 Subject: [Opendnssec-develop] [OpenDNSSEC] #196: Broken Links on Website Message-ID: <056.50feb4b21f19b0d799e9ea6ac97e230d@kirei.se> #196: Broken Links on Website -------------------------------+-------------------------------------------- Reporter: dnssec@? | Owner: rb Type: defect | Status: new Priority: major | Component: Unknown Version: trunk | Keywords: Website, Broken Links -------------------------------+-------------------------------------------- Hi All, FYI, Under the current documentation section of the opendnssec.org website (http://www.opendnssec.org/documentation/using-opendnssec/) there are broken links with file://wiki/signer etc links. Regards, Dave -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Thu Nov 18 07:34:48 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Thu, 18 Nov 2010 07:34:48 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #196: Broken Links on Website In-Reply-To: <056.50feb4b21f19b0d799e9ea6ac97e230d@kirei.se> References: <056.50feb4b21f19b0d799e9ea6ac97e230d@kirei.se> Message-ID: <065.a85b45a20c6e67c60f4935d8d38a26c9@kirei.se> #196: Broken Links on Website ----------------------------------+----------------------------------------- Reporter: dnssec@? | Owner: rb Type: defect | Status: closed Priority: major | Component: Unknown Version: trunk | Resolution: fixed Keywords: Website, Broken Links | ----------------------------------+----------------------------------------- Changes (by rb): * status: new => closed * resolution: => fixed Comment: Thanks, my bad. Forgot to remove that section when generating the page. -- Ticket URL: OpenDNSSEC OpenDNSSEC From rickard.bellgrim at iis.se Thu Nov 18 08:04:48 2010 From: rickard.bellgrim at iis.se (Rickard Bellgrim) Date: Thu, 18 Nov 2010 09:04:48 +0100 Subject: [Opendnssec-develop] Doodle: Next OpenDNSSEC meeting In-Reply-To: <9EF44DCD-CD43-4068-A0F1-5FB6D8BD72C0@iis.se> References: <9EF44DCD-CD43-4068-A0F1-5FB6D8BD72C0@iis.se> Message-ID: On 15 nov 2010, at 16.38, Rickard Bellgrim wrote: > We will have the next telephone meeting on Friday, 14:00-15:00 CET. And you can find the draft agenda here: http://trac.opendnssec.org/wiki/Meetings/Agenda/2010-11-19 // Rickard From rick at openfortress.nl Fri Nov 19 13:53:38 2010 From: rick at openfortress.nl (Rick van Rein) Date: Fri, 19 Nov 2010 13:53:38 +0000 Subject: [Opendnssec-develop] Meeting notes 2010-11-19 are ready Message-ID: <20101119135338.GC18824@phantom.vanrein.org> Hello, I just posted the meeting notes to today's OpenDNSSEC meeting on the website, http://trac.opendnssec.org/wiki/Meetings/Minutes/2010-11-19 Cheers, -Rick From rickard.bellgrim at iis.se Mon Nov 22 10:09:33 2010 From: rickard.bellgrim at iis.se (Rickard Bellgrim) Date: Mon, 22 Nov 2010 11:09:33 +0100 Subject: [Opendnssec-develop] Files included in zone file Message-ID: <35440871-347B-4EB4-9EB8-03F278F654B8@iis.se> Hi Should the Auditor be able to handle included zone files ($INCLUDE statements)? Or is it a known issue? Because currently it ignores this statement in the example.com.unsorted file. // Rickard From owner-dnssec-trac at kirei.se Mon Nov 22 23:43:44 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Mon, 22 Nov 2010 23:43:44 -0000 Subject: [Opendnssec-develop] [OpenDNSSEC] #197: Double-free issue Message-ID: <078.3790de63e382f1ce0ce91ddce4707bda@kirei.se> #197: Double-free issue -----------------------------------------------------+---------------------- Reporter: Sebastian Castro | Owner: rb Type: defect | Status: new Priority: minor | Component: Unknown Version: trunk | Keywords: double free memory allocation -----------------------------------------------------+---------------------- While working on a PoC code to display the list of keys available (in GENERATE state) for a zone, I found a double-free issue. The case was produced when a query to the KASP returned no rows. In the attached code, within the ListAvailableKeys function, if no rows are returned there is no call to DbString(row, 0, &key_id), meaning no mem allocation for key_id. Later on, you try to free that memory using DbStringFree. The glibc on Debian complains about this. I'm not completely sure about the right approach for fixing this. -- Ticket URL: OpenDNSSEC OpenDNSSEC From AlexD at nominet.org.uk Tue Nov 23 07:55:18 2010 From: AlexD at nominet.org.uk (Alex Dalitz) Date: Tue, 23 Nov 2010 07:55:18 +0000 Subject: [Opendnssec-develop] Files included in zone file In-Reply-To: <35440871-347B-4EB4-9EB8-03F278F654B8@iis.se> References: <35440871-347B-4EB4-9EB8-03F278F654B8@iis.se> Message-ID: > Should the Auditor be able to handle included zone files ($INCLUDE statements)? Or is it a known issue? > > Because currently it ignores this statement in the example.com.unsorted file. ISTR a discussion last year in which we decided that we would not support $INCLUDE statements. So : "no", the auditor does not handle included zone files. Do we wish to change this behaviour? Thanks, Alex. From owner-dnssec-trac at kirei.se Tue Nov 23 08:44:18 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Tue, 23 Nov 2010 08:44:18 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #26: Signer (or communicated) gets very slow with many zones In-Reply-To: <043.3e06d24187eff497c818ae327e7a67e4@kirei.se> References: <043.3e06d24187eff497c818ae327e7a67e4@kirei.se> Message-ID: <052.9ae731ad51fc5041ced2d5e6e54fea28@kirei.se> #26: Signer (or communicated) gets very slow with many zones -------------------+-------------------------------------------------------- Reporter: pawal | Owner: rb Type: defect | Status: closed Priority: major | Component: Unknown Version: | Resolution: fixed Keywords: | -------------------+-------------------------------------------------------- Changes (by pawal): * status: new => closed * resolution: => fixed -- Ticket URL: OpenDNSSEC OpenDNSSEC From matthijs at NLnetLabs.nl Tue Nov 23 10:00:21 2010 From: matthijs at NLnetLabs.nl (Matthijs Mekking) Date: Tue, 23 Nov 2010 11:00:21 +0100 Subject: [Opendnssec-develop] Files included in zone file In-Reply-To: References: <35440871-347B-4EB4-9EB8-03F278F654B8@iis.se> Message-ID: <4CEB90B5.5050702@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 We could at least make it a known issue. The auditor will now always fail if the unsigned zone does include $INCLUDE statements. I recall the reason not to read include files is that we cannot guarantee that they are atomic. After the signer reads in the zone and before the audit, the include files could have been edited. Best regards, Matthijs On 11/23/2010 08:55 AM, Alex Dalitz wrote: >> Should the Auditor be able to handle included zone files ($INCLUDE statements)? Or is it a known issue? >> >> Because currently it ignores this statement in the example.com.unsorted file. > > ISTR a discussion last year in which we decided that we would not support $INCLUDE statements. > > So : "no", the auditor does not handle included zone files. > > Do we wish to change this behaviour? > > 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.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJM65C1AAoJEA8yVCPsQCW5VQkIAJ0NwOVCE9GpUn4KjUMumMFs Q7V9xlPSdoiuX0JDZXxFdtltUZKPz1Q07gBK/qxlILCFEWk8C9IQFxQc+HLmNDIp 1dR/+6gi1shQLpIaCAML3Qqun06C0tXb1lStXZsN8WhMj+ZajILwwK3opIe7vIdb 73sgKlo3QjesA9HijR7XpD9R9Ym+vkm6W/nL2uHw0uDdw/4mD9w9gKD2N9mNwY9z c1tvAFVcQ08mjuV3mgthj7TkEtmQtKtnxZ+6Q9LittBv5BxcsVhVNmV5tqECfT6Q /qV5c0iP5n2ddbv5gvmxaKAiW2Mcq0o4J4F+zFzv/SZMVEogLKvww83n1sSFTV0= =17vl -----END PGP SIGNATURE----- From owner-dnssec-trac at kirei.se Tue Nov 23 10:46:19 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Tue, 23 Nov 2010 10:46:19 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #142: Need A Notifier After Enforcer Runs In-Reply-To: <056.1411376a887a8188a643f26f526b9740@kirei.se> References: <056.1411376a887a8188a643f26f526b9740@kirei.se> Message-ID: <065.eff41f63785fe8a02921a20979307992@kirei.se> #142: Need A Notifier After Enforcer Runs -------------------------------+-------------------------------------------- Reporter: sunil.kakita@? | Owner: rb Type: enhancement | Status: closed Priority: major | Component: Unknown Version: trunk | Resolution: worksforme Keywords: | -------------------------------+-------------------------------------------- Changes (by rb): * status: accepted => closed * resolution: => worksforme -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Tue Nov 23 11:58:36 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Tue, 23 Nov 2010 11:58:36 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #197: Double-free issue In-Reply-To: <078.3790de63e382f1ce0ce91ddce4707bda@kirei.se> References: <078.3790de63e382f1ce0ce91ddce4707bda@kirei.se> Message-ID: <087.01092e930d643cdcfa0345097f4379d9@kirei.se> #197: Double-free issue -----------------------------------------------------+---------------------- Reporter: Sebastian Castro | Owner: rb Type: defect | Status: new Priority: minor | Component: Unknown Version: trunk | Keywords: double free memory allocation -----------------------------------------------------+---------------------- Comment(by rb): We have now added an extra check for NULL in the macro code for freeing a pointer: r4211 -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Tue Nov 23 14:58:08 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Tue, 23 Nov 2010 14:58:08 -0000 Subject: [Opendnssec-develop] [OpenDNSSEC] #198: zone updates ignored? Message-ID: <059.89d942b926b7441bc26dfd7bc4b25600@kirei.se> #198: zone updates ignored? ----------------------------------+----------------------------------------- Reporter: matthijs@? | Owner: matthijs Type: defect | Status: new Priority: minor | Component: Signer Version: 1.1.1 | Keywords: ----------------------------------+----------------------------------------- Zone updates seem to get ignored, because signatures and serial are being refreshed and updated. However, no ods-signer sign zone command is given. But the signer should not pick up the input serial when resigning. That could have changed in the meantime. Instead, the signer should store the input serial and access it when needed. Only when reading the unsigned zone again, the input serial shall be updated. -- Ticket URL: OpenDNSSEC OpenDNSSEC From rickard.bellgrim at iis.se Wed Nov 24 10:19:44 2010 From: rickard.bellgrim at iis.se (Rickard Bellgrim) Date: Wed, 24 Nov 2010 11:19:44 +0100 Subject: [Opendnssec-develop] v1.2.0rc2 Message-ID: <0474A605-E90A-4E45-8679-5B8039A64A3D@iis.se> Hi Are we ready for a rc2? Any issue that needs to be fixed? // Rickard From matthijs at NLnetLabs.nl Wed Nov 24 10:43:22 2010 From: matthijs at NLnetLabs.nl (Matthijs Mekking) Date: Wed, 24 Nov 2010 11:43:22 +0100 Subject: [Opendnssec-develop] v1.2.0rc2 In-Reply-To: <0474A605-E90A-4E45-8679-5B8039A64A3D@iis.se> References: <0474A605-E90A-4E45-8679-5B8039A64A3D@iis.se> Message-ID: <4CECEC4A.8050808@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I see that my chore is finished, so I have no outstanding issues anymore. Thus, imo yes. Matthijs On 11/24/2010 11:19 AM, Rickard Bellgrim wrote: > Hi > > Are we ready for a rc2? Any issue that needs to be fixed? > > // Rickard > > _______________________________________________ > Opendnssec-develop mailing list > Opendnssec-develop at lists.opendnssec.org > https://lists.opendnssec.org/mailman/listinfo/opendnssec-develop > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJM7OxKAAoJEA8yVCPsQCW5/c0IAI98/Kx3Tsb6unW3YbUv/9Xw FeD5LejMJz/lt6oiWimUGmlMUwANFeC0SNO89qSjpEojPmEUqGVU6lEIGVAdMZpB WDtoZseyCrtkyDxVO/5cNmYwCiaLRtrBuflp1mDJBxLdn5gYGjLUbPJuASVL39Gj jsMaBvzOSMmTKAkWuIS3xv2wY27tTkHuyVKBK7K4D7NhBJ6/xr91HQyrgYFVJTJ4 3EjSU3XiP4HTB0S7JBZYIwGAVUIbf4m+dEdnFSw4jLZFl5Jgqeb3tB1/Z9ijvV5m 8/1QHTO7k94zt55t9stPKU9HdYPkeUp1cZWwkQ3cq2v8j7utUEb7eoaYnzO6bIM= =Y9sr -----END PGP SIGNATURE----- From rickard.bellgrim at iis.se Wed Nov 24 12:11:17 2010 From: rickard.bellgrim at iis.se (Rickard Bellgrim) Date: Wed, 24 Nov 2010 13:11:17 +0100 Subject: [Opendnssec-develop] v1.2.0rc2 In-Reply-To: <4CECEC4A.8050808@nlnetlabs.nl> References: <0474A605-E90A-4E45-8679-5B8039A64A3D@iis.se> <4CECEC4A.8050808@nlnetlabs.nl> Message-ID: <2127BC71-0D40-4FB9-A1F2-920928F371CD@iis.se> On 24 nov 2010, at 11.43, Matthijs Mekking wrote: > I see that my chore is finished, so I have no outstanding issues > anymore. Thus, imo yes. Yeah, we have no outstanding issues. Except those in KNOWN_ISSUES. I have prepared trunk for a release. The changes between rc1 and rc2 have been tested. And all test zones are working. Now it is your turn, Jakob. // Rickard From owner-dnssec-trac at kirei.se Thu Nov 25 02:45:26 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Thu, 25 Nov 2010 02:45:26 -0000 Subject: [Opendnssec-develop] [OpenDNSSEC] #199: Issues when removing a zone from signing Message-ID: <078.5703655714a16bc038f6e8e422d99276@kirei.se> #199: Issues when removing a zone from signing -----------------------------------------------------+---------------------- Reporter: Sebastian Castro | Owner: sion Type: defect | Status: new Priority: minor | Component: Enforcer Version: trunk | Keywords: -----------------------------------------------------+---------------------- There are two issues to note, one minor and the other more important. In the attached file you will find a script of activities involving the srs.net.nz zone in a testing environment. The minor issue is when you try to delete a zone a warning is printed: "ERROR: error executing SQL - no such column: STATE". For context see the file attached. The more relevant issue is when you try to add for signing a zone that has been previously deleted. The KSK follow the normal flow, but the ZSK don't progress. -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Thu Nov 25 03:10:31 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Thu, 25 Nov 2010 03:10:31 -0000 Subject: [Opendnssec-develop] [OpenDNSSEC] #200: Log when a KSK has been rolled over Message-ID: <078.cb551d53671d99abad86ac8e95e60460@kirei.se> #200: Log when a KSK has been rolled over -----------------------------------------------------+---------------------- Reporter: Sebastian Castro | Owner: sion Type: enhancement | Status: new Priority: trivial | Component: Enforcer Version: trunk | Keywords: -----------------------------------------------------+---------------------- This a feature/bug-fixing request. Currently OpenDNSSEC records in the log when a ZSK is rolled over "ZSK has been rolled over for ". Although the current code for the message is generic for ZSK/KSK, actually it doesn't get executed during a KSK rollover because the condition in enforcer/ksm/ksm_request.c:454, so the message needs to go somewhere else. I think putting the message when the transition from KEYPUBLISH/READY to ACTIVE happens could be an option. -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Fri Nov 26 01:42:22 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Fri, 26 Nov 2010 01:42:22 -0000 Subject: [Opendnssec-develop] [OpenDNSSEC] #201: Auditor fails with INCLUDE statements Message-ID: <078.b9122f53d255b2ed4a59edd9afd1dba8@kirei.se> #201: Auditor fails with INCLUDE statements -----------------------------------------------------+---------------------- Reporter: Sebastian Castro | Owner: sion Type: defect | Status: new Priority: minor | Component: Enforcer Version: trunk | Keywords: -----------------------------------------------------+---------------------- If you use INCLUDE statements in the input zone, the auditor fails to check a signed zone with messages like "RRset included in Output that was not present in Input". If you delete the INCLUDEs it works perfectly. -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Fri Nov 26 07:57:33 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Fri, 26 Nov 2010 07:57:33 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #201: Auditor fails with INCLUDE statements In-Reply-To: <078.b9122f53d255b2ed4a59edd9afd1dba8@kirei.se> References: <078.b9122f53d255b2ed4a59edd9afd1dba8@kirei.se> Message-ID: <087.72237d36d5c6d640ef71bf0d54707e79@kirei.se> #201: Auditor fails with INCLUDE statements -----------------------------------------------------+---------------------- Reporter: Sebastian Castro | Owner: rb Type: defect | Status: accepted Priority: minor | Component: Enforcer Version: trunk | Keywords: -----------------------------------------------------+---------------------- Changes (by rb): * owner: sion => rb * status: new => accepted Comment: Yeah, we have it as a known issue: r4210 -- Ticket URL: OpenDNSSEC OpenDNSSEC From matthijs at NLnetLabs.nl Fri Nov 26 11:59:03 2010 From: matthijs at NLnetLabs.nl (Matthijs Mekking) Date: Fri, 26 Nov 2010 12:59:03 +0100 Subject: [Opendnssec-develop] Fwd: opendnssec1.2.0rc2 probleempje (revision 4225) Message-ID: <4CEFA107.6000307@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 - -------- Original Message -------- Subject: opendnssec1.2.0rc2 probleempje (revision 4225) Date: Thu, 25 Nov 2010 22:44:03 +0100 From: Jaap Akkerhuis To: Matthijs Mekking Compilen van daemon_util.c faalt: gcc -DHAVE_CONFIG_H -I. -I../../common -I../../common -I../../common - -I./../ksm/include -I./../ksm/include -I./../../libhsm/src - -I./../../libhsm/src -I/usr/local/include/libxml2 -I/usr/local/include - -I/usr/local/include -g -O2 -pedantic -Wall -Wextra -D_THREAD_SAFE - -pthread -MT daemon_util.o -MD -MP -MF .deps/daemon_util.Tpo -c -o daemon_util.o daemon_util.c In file included from ./../ksm/include/ksm/database.h:77, from daemon_util.c:70: /usr/local/include/sqlite3.h:252: warning: ISO C90 does not support 'long long' /usr/local/include/sqlite3.h:253: warning: ISO C90 does not support 'long long' daemon_util.c: In function 'log_msg': daemon_util.c:266: warning: implicit declaration of function 'vsyslog' daemon_util.c: In function 'get_lite_lock': daemon_util.c:986: error: storage size of 'tv' isn't known daemon_util.c:1005: warning: implicit declaration of function 'select' daemon_util.c:986: warning: unused variable 'tv' *** Error code 1 Stop in /home/jaap/svn/src/opendnssec/trunk/OpenDNSSEC/enforcer/common. *** Error code 1 Stop in /home/jaap/svn/src/opendnssec/trunk/OpenDNSSEC/enforcer. *** Error code 1 Stop in /home/jaap/svn/src/opendnssec/trunk/OpenDNSSEC. De definitie van timeval zit normaal in sys/time.h en/of sys/select.h en geen van beiden is #included voorzover ik kan zien. jaap -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJM76EGAAoJEA8yVCPsQCW5Zk8H/31vLZvEdOM8f59FHmBeAHDM YPEOecZIwEkx73TYaPNDwS/SPGu9qLQMlP4jeJgiyZAjP0Z1eS/Fdus5c9nadTd8 aGttRlwGnyac3cNZsaqAf83DTxcgTp2i4K7CHGd15qERIakFxeV31dPSLMmDR8Ic LlpFHISNcNAKWK63Dk09IQEO9dgbUuuRdxk82W83CIjem0hOb3pg+5sy6tV/RAvv WGiwavXYZZ+mPAZwtqzP04gBJKmWsOoMNymk/0Uik5f6sqlXhtotzfms5ftasN3K 1tIfoN+fSzOEj9wx/4qhUgC5kW+wA9otPXmUD0ULFhTPCokaSJhkLZWJhmQCHto= =iXVQ -----END PGP SIGNATURE----- From owner-dnssec-trac at kirei.se Fri Nov 26 12:18:53 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Fri, 26 Nov 2010 12:18:53 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #199: Issues when removing a zone from signing In-Reply-To: <078.5703655714a16bc038f6e8e422d99276@kirei.se> References: <078.5703655714a16bc038f6e8e422d99276@kirei.se> Message-ID: <087.e550b2b20f66903c2a39fa99f933a45a@kirei.se> #199: Issues when removing a zone from signing -----------------------------------------------------+---------------------- Reporter: Sebastian Castro | Owner: rb Type: defect | Status: accepted Priority: minor | Component: Enforcer Version: trunk | Keywords: -----------------------------------------------------+---------------------- Changes (by rb): * owner: sion => rb * status: new => accepted Comment: Thanks, should be fixed in r4226 -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Tue Nov 30 09:41:17 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Tue, 30 Nov 2010 09:41:17 -0000 Subject: [Opendnssec-develop] [OpenDNSSEC] #202: ods-control stop hangs while stopping enforcer Message-ID: <078.0bc6f38db41e3ffc127e60161e82a2d6@kirei.se> #202: ods-control stop hangs while stopping enforcer -----------------------------------------------------+---------------------- Reporter: Gilles Massen | Owner: sion Type: defect | Status: new Priority: major | Component: Enforcer Version: | Keywords: -----------------------------------------------------+---------------------- "ods-control stop" always hangs with "Stopping enforcer". While looking at ods-control, it appears that the kill -TERM `cat ...enforcerd.pid` stopps the process, but enforcerd fails to remove enforcerd.pid. As result ods-control hangs in a while loop. This is on a OpenSuse 11.3. Privileges of signer and enforcer are non-root (but the user has all permissions on pid and containing directory). -- Ticket URL: OpenDNSSEC OpenDNSSEC From rickard.bellgrim at iis.se Tue Nov 30 13:34:52 2010 From: rickard.bellgrim at iis.se (Rickard Bellgrim) Date: Tue, 30 Nov 2010 14:34:52 +0100 Subject: [Opendnssec-develop] Meeting 20101201 Message-ID: <82B565DF-2592-4120-9F88-5DE6F35075ED@iis.se> Hi We have a meeting tomorrow. Date: Wednesday 1 December Time: 14:00-15:00 CET, 13:00-14:00 GMT Agenda: http://trac.opendnssec.org/wiki/Meetings/Agenda/2010-12-01 // Rickard