From rickard at opendnssec.org  Thu Nov  1 12:26:52 2012
From: rickard at opendnssec.org (Rickard Bellgrim)
Date: Thu, 1 Nov 2012 13:26:52 +0100
Subject: [Opendnssec-develop] Re: SoftHSMv2 and IPC
In-Reply-To: <CAKFiofmYdwLD_qEVe6Z0b0_o2XFJ89ZdC3ZoU4LbVwtoOxGmjA@mail.gmail.com>
References: <CAKFiofmYdwLD_qEVe6Z0b0_o2XFJ89ZdC3ZoU4LbVwtoOxGmjA@mail.gmail.com>
Message-ID: <CAKFiofkHmzsa1-4HtuHkb-BWW5jkk=e6=mHYW1047Gk8bHzCiQ@mail.gmail.com>

Solaris also have a limit of 14 characters, but it does not enforce
it. When reviewing the current core dump, it appears that this may be
the cause of it.

// Rickard

On Tue, Oct 30, 2012 at 4:28 PM, Rickard Bellgrim
<rickard at opendnssec.org> wrote:
> Hi
>
> I have been looking at the issues on Inter-Process Communication in
> SoftHSMv2. The current issue is that OpenBSD does not implement POSIX
> Semaphores and NetBSD has a maximum length of 14 characters on the
> names of the named semaphores. I tried to convert it over to System V
> semaphores, but then we have an issue that we hit the maximum number
> of semaphores and that there is no good equivalent to sem_unlink().
>
> Currently there is one semaphore per object. Maybe we should re-design
> IPC part of SoftHSMv2?
>
> // Rickard


From rickard at opendnssec.org  Thu Nov  1 12:45:40 2012
From: rickard at opendnssec.org (Rickard Bellgrim)
Date: Thu, 1 Nov 2012 13:45:40 +0100
Subject: [Opendnssec-develop] Re: SoftHSMv2 and IPC
In-Reply-To: <CAKFiofkHmzsa1-4HtuHkb-BWW5jkk=e6=mHYW1047Gk8bHzCiQ@mail.gmail.com>
References: <CAKFiofmYdwLD_qEVe6Z0b0_o2XFJ89ZdC3ZoU4LbVwtoOxGmjA@mail.gmail.com>
	<CAKFiofkHmzsa1-4HtuHkb-BWW5jkk=e6=mHYW1047Gk8bHzCiQ@mail.gmail.com>
Message-ID: <CAKFiof=jbhPggUCLq5ODb-MPN+jn40qNS4b0ooYb2g8T-MgWgA@mail.gmail.com>

Moving the discussion to:
https://issues.opendnssec.org/browse/SOFTHSM-37

On Thu, Nov 1, 2012 at 1:26 PM, Rickard Bellgrim <rickard at opendnssec.org> wrote:
> Solaris also have a limit of 14 characters, but it does not enforce
> it. When reviewing the current core dump, it appears that this may be
> the cause of it.
>
> // Rickard
>
> On Tue, Oct 30, 2012 at 4:28 PM, Rickard Bellgrim
> <rickard at opendnssec.org> wrote:
>> Hi
>>
>> I have been looking at the issues on Inter-Process Communication in
>> SoftHSMv2. The current issue is that OpenBSD does not implement POSIX
>> Semaphores and NetBSD has a maximum length of 14 characters on the
>> names of the named semaphores. I tried to convert it over to System V
>> semaphores, but then we have an issue that we hit the maximum number
>> of semaphores and that there is no good equivalent to sem_unlink().
>>
>> Currently there is one semaphore per object. Maybe we should re-design
>> IPC part of SoftHSMv2?
>>
>> // Rickard


From jerry at opendnssec.org  Thu Nov  1 14:36:09 2012
From: jerry at opendnssec.org (=?iso-8859-1?Q?Jerry_Lundstr=F6m?=)
Date: Thu, 1 Nov 2012 15:36:09 +0100
Subject: [Opendnssec-develop] Jenkins jobs disabled
Message-ID: <4D2E19BB-FD68-40CB-B81F-2253B0A7100E@opendnssec.org>

Hi,

I've disabled all Jenkins jobs because I've found a small bug in test framework regarding checking if paths are already added.

Working on a fix and will enable Jenkins when done.

--
Jerry Lundstr?m - OpenDNSSEC Developer
http://www.opendnssec.org/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 495 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.opendnssec.org/pipermail/opendnssec-develop/attachments/20121101/74188941/attachment.bin>

From jerry at opendnssec.org  Thu Nov  1 15:26:13 2012
From: jerry at opendnssec.org (=?iso-8859-1?Q?Jerry_Lundstr=F6m?=)
Date: Thu, 1 Nov 2012 16:26:13 +0100
Subject: [Opendnssec-develop] Re: Jenkins jobs disabled
In-Reply-To: <4D2E19BB-FD68-40CB-B81F-2253B0A7100E@opendnssec.org>
References: <4D2E19BB-FD68-40CB-B81F-2253B0A7100E@opendnssec.org>
Message-ID: <6BF5A002-C7DF-4255-ACDD-53D844B541A5@opendnssec.org>

On Nov 1, 2012, at 15:36 , Jerry Lundstr?m wrote:

> Working on a fix and will enable Jenkins when done.


Jobs are enabled again.

--
Jerry Lundstr?m - OpenDNSSEC Developer
http://www.opendnssec.org/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 495 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.opendnssec.org/pipermail/opendnssec-develop/attachments/20121101/0a35f646/attachment.bin>

From jerry at opendnssec.org  Fri Nov  2 08:14:29 2012
From: jerry at opendnssec.org (=?ISO-8859-1?Q?Jerry_Lundstr=F6m?=)
Date: Fri, 2 Nov 2012 09:14:29 +0100
Subject: [Opendnssec-develop] About versioning...
Message-ID: <-5919980780371499503@unknownmsgid>

Found this http://semver.org/ .

/Jerry


From sara at sinodun.com  Fri Nov  2 10:37:47 2012
From: sara at sinodun.com (Sara Dickinson)
Date: Fri, 2 Nov 2012 10:37:47 +0000
Subject: [Opendnssec-develop] Fwd: Re: [Unbound-users] DNSSEC validation
	failure of .nl TLD
In-Reply-To: <50911991.9040801@nlnetlabs.nl>
References: <50910B90.8020507@sidn.nl> <50911991.9040801@nlnetlabs.nl>
Message-ID: <2D08E631-7EAF-4DB6-A396-A3E005F497CA@sinodun.com>


On 31 Oct 2012, at 12:29, Matthijs Mekking wrote:

> The statement of SIDN is in Dutch. Here is a public version:
> 
> http://www.miek.nl/blog/archives/2012/10/31/dnssec_storing_28_oktober_2012/index.html
> 
> Marco also sent an explanation to unbound-users, see below. It looks
> like an operator error also occurred.
> 
> SUPPORT-41 is also created with respect to this incident.
> 
> Best regards,
>  Matthijs
> 

So this looks like a mystery hang of the enforcer during a NotifyCommand from the logs? 

Sion - I have assigned the issue to you for a first peruse. 

Thanks

Sara.




From sara at sinodun.com  Fri Nov  2 10:49:22 2012
From: sara at sinodun.com (Sara Dickinson)
Date: Fri, 2 Nov 2012 10:49:22 +0000
Subject: [Opendnssec-develop] testing dns adapters document
In-Reply-To: <CAGTFMNYE7JBY8yCp6vci-GjH_2VTGJkimTqE_Swoy69yuUP3ww@mail.gmail.com>
References: <508FD7E4.7060801@nlnetlabs.nl>
	<9F12FBC9-F0EC-4A04-99E2-5B9E89718E2C@sinodun.com>
	<5090FF7B.5090508@nlnetlabs.nl>
	<1EE1E1D4-5D2B-49D2-B216-633CD80A723C@sinodun.com>
	<CAGTFMNYE7JBY8yCp6vci-GjH_2VTGJkimTqE_Swoy69yuUP3ww@mail.gmail.com>
Message-ID: <EC168CED-3963-4E18-A619-FA58BA2297D2@sinodun.com>


On 31 Oct 2012, at 13:32, Jerry Lundstr?m wrote:

> On Wed, Oct 31, 2012 at 1:42 PM, Sara Dickinson <sara at sinodun.com> wrote:
>> Jerry - could you help out with setting up BIND and validns (or similar) for this work?
> 
> If, who that will write the test, makes it so a normal user can start
> BIND in the background and get the IXFR/AXFR to tests and then
> shutdown BIND for each test as we do with OpenDNSSEC then we can
> probably run it on most of the platforms if not all.
> 
> So it is best if someone start trying this locally and when we have
> something that runs we can look at what we need to do on each
> platform.

In the interests of getting 1.4 tested and shipped asap do you think you could pitch in and have a go at writing the actual test too? I'm sure Matthijs could outline in an email what he had in mind. Thanks

Sara.


> 
> -- 
> Jerry Lundstr?m - OpenDNSSEC Developer
> http://www.opendnssec.org/



From matthijs at nlnetlabs.nl  Fri Nov  2 10:49:21 2012
From: matthijs at nlnetlabs.nl (Matthijs Mekking)
Date: Fri, 02 Nov 2012 11:49:21 +0100
Subject: [Opendnssec-develop] Fwd: Re: [Unbound-users] DNSSEC validation
	failure of .nl TLD
In-Reply-To: <2D08E631-7EAF-4DB6-A396-A3E005F497CA@sinodun.com>
References: <50910B90.8020507@sidn.nl> <50911991.9040801@nlnetlabs.nl>
	<2D08E631-7EAF-4DB6-A396-A3E005F497CA@sinodun.com>
Message-ID: <5093A531.3090609@nlnetlabs.nl>

On 11/02/2012 11:37 AM, Sara Dickinson wrote:
>
> On 31 Oct 2012, at 12:29, Matthijs Mekking wrote:
>
>> The statement of SIDN is in Dutch. Here is a public version:
>>
>> http://www.miek.nl/blog/archives/2012/10/31/dnssec_storing_28_oktober_2012/index.html
>>
>> Marco also sent an explanation to unbound-users, see below. It looks
>> like an operator error also occurred.
>>
>> SUPPORT-41 is also created with respect to this incident.
>>
>> Best regards,
>>   Matthijs
>>
>
> So this looks like a mystery hang of the enforcer during a NotifyCommand from the logs?

Given that they have created SUPPORT-41, it looks like that has 
something to do with it. However, the statement of SIDN claims that 
there was a crash.


>
> Sion - I have assigned the issue to you for a first peruse.
>
> Thanks
>
> Sara.
>
>
> _______________________________________________
> Opendnssec-develop mailing list
> Opendnssec-develop at lists.opendnssec.org
> https://lists.opendnssec.org/mailman/listinfo/opendnssec-develop
>



From sion at nominet.org.uk  Fri Nov  2 10:51:26 2012
From: sion at nominet.org.uk (=?ISO-8859-1?Q?Si=F4n_Lloyd?=)
Date: Fri, 2 Nov 2012 10:51:26 +0000
Subject: [Opendnssec-develop] Fwd: Re: [Unbound-users] DNSSEC validation
	failure of .nl TLD
In-Reply-To: <5093A531.3090609@nlnetlabs.nl>
References: <50910B90.8020507@sidn.nl> <50911991.9040801@nlnetlabs.nl>
	<2D08E631-7EAF-4DB6-A396-A3E005F497CA@sinodun.com>
	<5093A531.3090609@nlnetlabs.nl>
Message-ID: <5093A5AE.10103@nominet.org.uk>

On 02/11/12 10:49, Matthijs Mekking wrote:
> On 11/02/2012 11:37 AM, Sara Dickinson wrote:
>>
>> On 31 Oct 2012, at 12:29, Matthijs Mekking wrote:
>>
>>> The statement of SIDN is in Dutch. Here is a public version:
>>>
>>> http://www.miek.nl/blog/archives/2012/10/31/dnssec_storing_28_oktober_2012/index.html 
>>>
>>>
>>> Marco also sent an explanation to unbound-users, see below. It looks
>>> like an operator error also occurred.
>>>
>>> SUPPORT-41 is also created with respect to this incident.
>>>
>>> Best regards,
>>>   Matthijs
>>>
>>
>> So this looks like a mystery hang of the enforcer during a 
>> NotifyCommand from the logs?
>
> Given that they have created SUPPORT-41, it looks like that has 
> something to do with it. However, the statement of SIDN claims that 
> there was a crash.

I wonder if it just stopped logging; because if it stopped working 
completely then the key would never have been promoted.

But I need to look more closely at the report.

Sion


From jerry at opendnssec.org  Fri Nov  2 11:00:02 2012
From: jerry at opendnssec.org (=?iso-8859-1?Q?Jerry_Lundstr=F6m?=)
Date: Fri, 2 Nov 2012 12:00:02 +0100
Subject: [Opendnssec-develop] testing dns adapters document
In-Reply-To: <EC168CED-3963-4E18-A619-FA58BA2297D2@sinodun.com>
References: <508FD7E4.7060801@nlnetlabs.nl>
	<9F12FBC9-F0EC-4A04-99E2-5B9E89718E2C@sinodun.com>
	<5090FF7B.5090508@nlnetlabs.nl>
	<1EE1E1D4-5D2B-49D2-B216-633CD80A723C@sinodun.com>
	<CAGTFMNYE7JBY8yCp6vci-GjH_2VTGJkimTqE_Swoy69yuUP3ww@mail.gmail.com>
	<EC168CED-3963-4E18-A619-FA58BA2297D2@sinodun.com>
Message-ID: <0D4056AF-5915-4EF8-A0ED-CD01BC0CA52B@opendnssec.org>

On Nov 2, 2012, at 11:49 , Sara Dickinson wrote:

> In the interests of getting 1.4 tested and shipped asap do you think you could pitch in and have a go at writing the actual test too? I'm sure Matthijs could outline in an email what he had in mind. Thanks


Create an issue (Sara?) and outline what needs to be tested in steps (Matthijs?) and I can look at it and see if its doable before I go on holiday.

--
Jerry Lundstr?m - OpenDNSSEC Developer
http://www.opendnssec.org/



From sara at sinodun.com  Fri Nov  2 11:48:09 2012
From: sara at sinodun.com (Sara Dickinson)
Date: Fri, 2 Nov 2012 11:48:09 +0000
Subject: [Opendnssec-develop] testing dns adapters document
In-Reply-To: <0D4056AF-5915-4EF8-A0ED-CD01BC0CA52B@opendnssec.org>
References: <508FD7E4.7060801@nlnetlabs.nl>
	<9F12FBC9-F0EC-4A04-99E2-5B9E89718E2C@sinodun.com>
	<5090FF7B.5090508@nlnetlabs.nl>
	<1EE1E1D4-5D2B-49D2-B216-633CD80A723C@sinodun.com>
	<CAGTFMNYE7JBY8yCp6vci-GjH_2VTGJkimTqE_Swoy69yuUP3ww@mail.gmail.com>
	<EC168CED-3963-4E18-A619-FA58BA2297D2@sinodun.com>
	<0D4056AF-5915-4EF8-A0ED-CD01BC0CA52B@opendnssec.org>
Message-ID: <C0E8D3EE-0D9C-4D6E-8596-AAD777439623@sinodun.com>


On 2 Nov 2012, at 11:00, Jerry Lundstr?m wrote:

> On Nov 2, 2012, at 11:49 , Sara Dickinson wrote:
> 
>> In the interests of getting 1.4 tested and shipped asap do you think you could pitch in and have a go at writing the actual test too? I'm sure Matthijs could outline in an email what he had in mind. Thanks
> 
> 
> Create an issue (Sara?) and outline what needs to be tested in steps (Matthijs?) and I can look at it and see if its doable 

Grand - how about we use https://issues.opendnssec.org/browse/OPENDNSSEC-143?

>  before I go on holiday.


John (Dickinson) has offered to be on hand to look after jenkins if needed while you are away (he has a logon to jenkins, but isn't sure if he has access to the individual machines?).  I can admin JIRA and look after the SUPPORT project and Jakob can do the release engineering side of things if needed. Can you think of anything else we need to have backup access for?

Sara.

> 
> --
> Jerry Lundstr?m - OpenDNSSEC Developer
> http://www.opendnssec.org/
> 



From matthijs at nlnetlabs.nl  Fri Nov  2 11:49:58 2012
From: matthijs at nlnetlabs.nl (Matthijs Mekking)
Date: Fri, 02 Nov 2012 12:49:58 +0100
Subject: [Opendnssec-develop] testing dns adapters document
In-Reply-To: <0D4056AF-5915-4EF8-A0ED-CD01BC0CA52B@opendnssec.org>
References: <508FD7E4.7060801@nlnetlabs.nl>
	<9F12FBC9-F0EC-4A04-99E2-5B9E89718E2C@sinodun.com>
	<5090FF7B.5090508@nlnetlabs.nl>
	<1EE1E1D4-5D2B-49D2-B216-633CD80A723C@sinodun.com>
	<CAGTFMNYE7JBY8yCp6vci-GjH_2VTGJkimTqE_Swoy69yuUP3ww@mail.gmail.com>
	<EC168CED-3963-4E18-A619-FA58BA2297D2@sinodun.com>
	<0D4056AF-5915-4EF8-A0ED-CD01BC0CA52B@opendnssec.org>
Message-ID: <5093B366.10603@nlnetlabs.nl>

On 11/02/2012 12:00 PM, Jerry Lundstr?m wrote:
> On Nov 2, 2012, at 11:49 , Sara Dickinson wrote:
>
>> In the interests of getting 1.4 tested and shipped asap do you think you could pitch in and have a go at writing the actual test too? I'm sure Matthijs could outline in an email what he had in mind. Thanks
>
>
> Create an issue (Sara?) and outline what needs to be tested in steps (Matthijs?) and I can look at it and see if its doable before I go on holiday.

I try to start this work next Tuesday (having a day off on Monday)

>
> --
> Jerry Lundstr?m - OpenDNSSEC Developer
> http://www.opendnssec.org/
>
>



From jerry at opendnssec.org  Fri Nov  2 12:05:53 2012
From: jerry at opendnssec.org (=?ISO-8859-1?Q?Jerry_Lundstr=F6m?=)
Date: Fri, 2 Nov 2012 13:05:53 +0100
Subject: [Opendnssec-develop] testing dns adapters document
In-Reply-To: <C0E8D3EE-0D9C-4D6E-8596-AAD777439623@sinodun.com>
References: <508FD7E4.7060801@nlnetlabs.nl>
	<9F12FBC9-F0EC-4A04-99E2-5B9E89718E2C@sinodun.com>
	<5090FF7B.5090508@nlnetlabs.nl>
	<1EE1E1D4-5D2B-49D2-B216-633CD80A723C@sinodun.com>
	<CAGTFMNYE7JBY8yCp6vci-GjH_2VTGJkimTqE_Swoy69yuUP3ww@mail.gmail.com>
	<EC168CED-3963-4E18-A619-FA58BA2297D2@sinodun.com>
	<0D4056AF-5915-4EF8-A0ED-CD01BC0CA52B@opendnssec.org>
	<C0E8D3EE-0D9C-4D6E-8596-AAD777439623@sinodun.com>
Message-ID: <4117535909811790131@unknownmsgid>

On 2 nov 2012, at 12:48, Sara Dickinson <sara at sinodun.com> wrote:

>
> On 2 Nov 2012, at 11:00, Jerry Lundstr?m wrote:
>
>> On Nov 2, 2012, at 11:49 , Sara Dickinson wrote:
>>
>>> In the interests of getting 1.4 tested and shipped asap do you think you could pitch in and have a go at writing the actual test too? I'm sure Matthijs could outline in an email what he had in mind. Thanks
>>
>>
>> Create an issue (Sara?) and outline what needs to be tested in steps (Matthijs?) and I can look at it and see if its doable
>
> Grand - how about we use https://issues.opendnssec.org/browse/OPENDNSSEC-143?

No, that issue is another issue.

For the adapters we dont know if we need validns, that is something
you have added.

Validating the zone affects all tests, much bigger the dns adapters.

We agreed on using 1.3 auditor to validate 1.4 zone and that has been done.

>
>> before I go on holiday.
>
>
> John (Dickinson) has offered to be on hand to look after jenkins if needed while you are away (he has a logon to jenkins, but isn't sure if he has access to the individual machines?).  I can admin JIRA and look after the SUPPORT project and Jakob can do the release engineering side of things if needed. Can you think of anything else we need to have backup access for?

I have already planned to do all this next week.

>
> Sara.
>
>>
>> --
>> Jerry Lundstr?m - OpenDNSSEC Developer
>> http://www.opendnssec.org/
>>
>


From rick at openfortress.nl  Fri Nov  2 13:04:12 2012
From: rick at openfortress.nl (Rick van Rein)
Date: Fri, 2 Nov 2012 13:04:12 +0000
Subject: [Opendnssec-develop] Meeting notes of 2012-10-30
Message-ID: <20121102130412.GA5929@newphantom.local>

Hello all,

I have just finished the meeting notes for last Tuesday,

https://wiki.opendnssec.org/display/OpenDNSSEC/2012-10-30+Meeting+Notes

Sorry it took me a while to write them.  I hope the suspence hasn't been too hard to endure ;-)


Cheers,
 -Rick


From rick at openfortress.nl  Fri Nov  2 14:36:20 2012
From: rick at openfortress.nl (Rick van Rein)
Date: Fri, 2 Nov 2012 14:36:20 +0000
Subject: [Opendnssec-develop] Making ODS immune for localtime changes
Message-ID: <20121102143620.GB6208@newphantom.local>

Hello,

When I asked whether OpenDNSSEC was immune for time warps such as the change
between summer time and winter time, I did not get a conclusive answer.  I've
always been weary about the plethory of time-related functions in the UNIX API,
and expect others are too, so I decided to dive into it.  Please expand or
correct as you see fit.


First, aside from neutral time interval types, the types that matter are
time_t and struct tm.  The first is seconds-since-epoch, and is UTC-only,
the latter can hold timezone-specific information.  So, anything that maps
from time_t to struct tm is suspicious.  I made a list of all the functions
related to time that I could find in the UNIX API, and ended up with

asctime                 NEUTRAL
asctime_r               NEUTRAL
ctime                   BAD
ctime_r                 BAD
difftime                GOOD
gettimeofday            BAD
gmtime                  GOOD
gmtime_r                GOOD
localtime               BAD
localtime_r             BAD
mktime                  SILLY
settimeofday            BAD
strftime                NEUTRAL
strptime                NEUTRAL
time                    GOOD
timegm                  GOOD
timelocal               BAD
tzset                   BAD
utimes                  UNRELATED
utime                   UNRELATED

I scored them as
 * BAD if a function introduces time zone information
 * GOOD if a function does not introduce time zone information
 * SILLY if it does not sound like we'd want to use it in OpenDNSSEC
 * NEUTRAL if they did nothing with time zone information
 * UNRELATED if the function deals with other things than absolute time

After doing this, I did a grep for BAD and SILLY functions:

/usr/local/src/opendnssec-1.4.0b1# rgrep '\<ctime\|ctime_r\|gettimeofday\|localtime\|localtime_r\|mktime\|settimeofday\|timelocal\|tzset\>' * | grep '[^:]*\.c:'
enforcer/test/cunit/test_datetime.c:    (void) localtime_r(&curtime, &time1);
enforcer/test/cunit/test_datetime.c:    (void) localtime_r(&curtime, &time2);
enforcer/test/cunit/test_datetime.c:    (void) localtime_r(&curtime, &time1);
enforcer/test/cunit/test_datetime.c:    (void) localtime_r(&curtime, &time2);
enforcer/ksm/datetime.c:    ptr = localtime_r(&curtime, datetime);
enforcer/ksm/datetime.c:                t1 = mktime(&tm1);
enforcer/ksm/datetime.c:                t2 = mktime(&tm2);
enforcer/enforcerd/enforcer.c:  if (gettimeofday(&tv, NULL)) {
enforcer/enforcerd/enforcer.c:    if (gettimeofday(&tv, NULL)) {
libhsm/src/bin/hsmspeed.c:    gettimeofday(&start, NULL);
libhsm/src/bin/hsmspeed.c:    gettimeofday(&end, NULL);
signer/src/wire/netio.c: * Retrieve the current time (using gettimeofday(2)).
signer/src/wire/netio.c:        if (gettimeofday(&current_timeval, NULL) == -1) {
signer/src/wire/netio.c:                "gettimeofday() failed (%s)", netio_str,
signer/src/shared/duration.c:    tmp = localtime(&t);
signer/src/shared/duration.c:        ods_log_error("[%s] time_datestamp: localtime() failed", duration_str);
signer/src/shared/locks.c:#include <sys/time.h> /* gettimeofday() */
signer/src/shared/locks.c:#include <time.h> /* gettimeofday() */
signer/src/shared/locks.c:    if (gettimeofday(&tv, NULL) != 0) {
signer/src/shared/log.c:    (void) ctime_r(&now, nowstr);
signer/src/scheduler/task.c:        strtime = ctime(&task->when);
signer/src/scheduler/task.c:        strtime = ctime(&task->when);
signer/src/scheduler/task.c:        strtime = ctime(&task->when);
signer/src/daemon/engine.c:    tzset(); /* for portability */
signer/src/daemon/cmdhandler.c:    strtime = ctime(&now);

Note that I did not incorporate dependent libraries, but I could if this
is thought useful.



If we wanted to clear out our timezone-dependency completely, then the
following (fairly straightforward) replacements would have to be made:


localtime -> gmtime
localtime_r -> gmtime_r
	Trivial, literal replacements.

ctime (t) -> asctime (gmtime (t))
ctime_r (t, b) -> asctime_r (gmtime (t), b)
	Trivial, literal replacements.

mktime -> ???
	enforcer/ksm/datetime.c: Used to differentiate time in DtDateDiff()
		which is harmless if we can rest assured that such times
		are always in UTC.  With the changes above, this should be
		the case, right?

tzset -> ???
	I hope we can drop it if we stick to UTC.

gettimeofday -> ???
	libhsm/src/bin/hsmspeed.c: You'd be silly to speed test accross time warps!
	signer/src/wire/netio.c: Harmless, used for difference of times
	signer/src/shared/locks.c / enforcer/enforcerd/enforcer.c:
		Is the alternate clock_gettime() not omnipresent?
		The time is used for a wait, and might cause hickups when time
		warps at an unhandy time in the functions ods_thread_wait() or
		enforcer_worker_timed_dequeue() -- I cannot tell if this could never
		lead to trouble?  (IOW, what happens if either of these functions
		waits 1h too long, or 1h too short?)


As you can guess, I'd like to propose making OpenDNSSEC independent of timezone
by making the above amendments.  The InceptionOffset will often catch any time
warps due to changes of summer/winter time, but its actual purpose will not be
fulfilled, or be fulfilled with 1h less impact, at time warps.  Also, with the
InceptionOffset less than 1h bad things could happen, like a prepublished ZSK
getting published too late for its new signatures to be accepted by validators.

Note that a similar thing might happen too if an admin was to correct the time
zone setting of a machine running OpenDNSSEC.  Although I'll admit not having
traced the uses of localtime to potential clashes, it can easily be avoided;
scripts around OpenDNSSEC would be a very good reason to do so, I think.

I always setup servers to run in UTC, but I know that not everybody does that.
And I'll frankly admit that I've not considered time warps when planning our
architecture; it might be that others miss it too.  So... I'd prefer OpenDNSSEC
to avoid that users can shoot themselves in the foot on this one :)



I hope this is helpful,


Cheers,
 -Rick
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 274 bytes
Desc: Digital signature
URL: <http://lists.opendnssec.org/pipermail/opendnssec-develop/attachments/20121102/93758d03/attachment.bin>

From sion at nominet.org.uk  Mon Nov  5 10:44:02 2012
From: sion at nominet.org.uk (=?ISO-8859-1?Q?Si=F4n_Lloyd?=)
Date: Mon, 5 Nov 2012 10:44:02 +0000
Subject: [Opendnssec-develop] Making ODS immune for localtime changes
In-Reply-To: <20121102143620.GB6208@newphantom.local>
References: <20121102143620.GB6208@newphantom.local>
Message-ID: <50979872.9030604@nominet.org.uk>

It is certainly helpful, thank you.

This is worth looking at closely. One worry for me would be pushing 
these changes out as we will then switch people from local time to UTC 
which for most folks will be more than the one hour summer-time switch.

Also note that InceptionOffset should not interfere with keys being 
introduced; but maybe we should at least recommend that the publish 
safety is at least one hour to cover DST (this is the supplied default)?

Sion

On 02/11/12 14:36, Rick van Rein wrote:
> Hello,
>
> When I asked whether OpenDNSSEC was immune for time warps such as the change
> between summer time and winter time, I did not get a conclusive answer.  I've
> always been weary about the plethory of time-related functions in the UNIX API,
> and expect others are too, so I decided to dive into it.  Please expand or
> correct as you see fit.
>
>
> First, aside from neutral time interval types, the types that matter are
> time_t and struct tm.  The first is seconds-since-epoch, and is UTC-only,
> the latter can hold timezone-specific information.  So, anything that maps
> from time_t to struct tm is suspicious.  I made a list of all the functions
> related to time that I could find in the UNIX API, and ended up with
>
> asctime                 NEUTRAL
> asctime_r               NEUTRAL
> ctime                   BAD
> ctime_r                 BAD
> difftime                GOOD
> gettimeofday            BAD
> gmtime                  GOOD
> gmtime_r                GOOD
> localtime               BAD
> localtime_r             BAD
> mktime                  SILLY
> settimeofday            BAD
> strftime                NEUTRAL
> strptime                NEUTRAL
> time                    GOOD
> timegm                  GOOD
> timelocal               BAD
> tzset                   BAD
> utimes                  UNRELATED
> utime                   UNRELATED
>
> I scored them as
>   * BAD if a function introduces time zone information
>   * GOOD if a function does not introduce time zone information
>   * SILLY if it does not sound like we'd want to use it in OpenDNSSEC
>   * NEUTRAL if they did nothing with time zone information
>   * UNRELATED if the function deals with other things than absolute time
>
> After doing this, I did a grep for BAD and SILLY functions:
>
> /usr/local/src/opendnssec-1.4.0b1# rgrep '\<ctime\|ctime_r\|gettimeofday\|localtime\|localtime_r\|mktime\|settimeofday\|timelocal\|tzset\>' * | grep '[^:]*\.c:'
> enforcer/test/cunit/test_datetime.c:    (void) localtime_r(&curtime, &time1);
> enforcer/test/cunit/test_datetime.c:    (void) localtime_r(&curtime, &time2);
> enforcer/test/cunit/test_datetime.c:    (void) localtime_r(&curtime, &time1);
> enforcer/test/cunit/test_datetime.c:    (void) localtime_r(&curtime, &time2);
> enforcer/ksm/datetime.c:    ptr = localtime_r(&curtime, datetime);
> enforcer/ksm/datetime.c:                t1 = mktime(&tm1);
> enforcer/ksm/datetime.c:                t2 = mktime(&tm2);
> enforcer/enforcerd/enforcer.c:  if (gettimeofday(&tv, NULL)) {
> enforcer/enforcerd/enforcer.c:    if (gettimeofday(&tv, NULL)) {
> libhsm/src/bin/hsmspeed.c:    gettimeofday(&start, NULL);
> libhsm/src/bin/hsmspeed.c:    gettimeofday(&end, NULL);
> signer/src/wire/netio.c: * Retrieve the current time (using gettimeofday(2)).
> signer/src/wire/netio.c:        if (gettimeofday(&current_timeval, NULL) == -1) {
> signer/src/wire/netio.c:                "gettimeofday() failed (%s)", netio_str,
> signer/src/shared/duration.c:    tmp = localtime(&t);
> signer/src/shared/duration.c:        ods_log_error("[%s] time_datestamp: localtime() failed", duration_str);
> signer/src/shared/locks.c:#include <sys/time.h> /* gettimeofday() */
> signer/src/shared/locks.c:#include <time.h> /* gettimeofday() */
> signer/src/shared/locks.c:    if (gettimeofday(&tv, NULL) != 0) {
> signer/src/shared/log.c:    (void) ctime_r(&now, nowstr);
> signer/src/scheduler/task.c:        strtime = ctime(&task->when);
> signer/src/scheduler/task.c:        strtime = ctime(&task->when);
> signer/src/scheduler/task.c:        strtime = ctime(&task->when);
> signer/src/daemon/engine.c:    tzset(); /* for portability */
> signer/src/daemon/cmdhandler.c:    strtime = ctime(&now);
>
> Note that I did not incorporate dependent libraries, but I could if this
> is thought useful.
>
>
>
> If we wanted to clear out our timezone-dependency completely, then the
> following (fairly straightforward) replacements would have to be made:
>
>
> localtime -> gmtime
> localtime_r -> gmtime_r
> 	Trivial, literal replacements.
>
> ctime (t) -> asctime (gmtime (t))
> ctime_r (t, b) -> asctime_r (gmtime (t), b)
> 	Trivial, literal replacements.
>
> mktime -> ???
> 	enforcer/ksm/datetime.c: Used to differentiate time in DtDateDiff()
> 		which is harmless if we can rest assured that such times
> 		are always in UTC.  With the changes above, this should be
> 		the case, right?
>
> tzset -> ???
> 	I hope we can drop it if we stick to UTC.
>
> gettimeofday -> ???
> 	libhsm/src/bin/hsmspeed.c: You'd be silly to speed test accross time warps!
> 	signer/src/wire/netio.c: Harmless, used for difference of times
> 	signer/src/shared/locks.c / enforcer/enforcerd/enforcer.c:
> 		Is the alternate clock_gettime() not omnipresent?
> 		The time is used for a wait, and might cause hickups when time
> 		warps at an unhandy time in the functions ods_thread_wait() or
> 		enforcer_worker_timed_dequeue() -- I cannot tell if this could never
> 		lead to trouble?  (IOW, what happens if either of these functions
> 		waits 1h too long, or 1h too short?)
>
>
> As you can guess, I'd like to propose making OpenDNSSEC independent of timezone
> by making the above amendments.  The InceptionOffset will often catch any time
> warps due to changes of summer/winter time, but its actual purpose will not be
> fulfilled, or be fulfilled with 1h less impact, at time warps.  Also, with the
> InceptionOffset less than 1h bad things could happen, like a prepublished ZSK
> getting published too late for its new signatures to be accepted by validators.
>
> Note that a similar thing might happen too if an admin was to correct the time
> zone setting of a machine running OpenDNSSEC.  Although I'll admit not having
> traced the uses of localtime to potential clashes, it can easily be avoided;
> scripts around OpenDNSSEC would be a very good reason to do so, I think.
>
> I always setup servers to run in UTC, but I know that not everybody does that.
> And I'll frankly admit that I've not considered time warps when planning our
> architecture; it might be that others miss it too.  So... I'd prefer OpenDNSSEC
> to avoid that users can shoot themselves in the foot on this one :)
>
>
>
> I hope this is helpful,
>
>
> Cheers,
>   -Rick
>
>
> _______________________________________________
> Opendnssec-develop mailing list
> Opendnssec-develop at lists.opendnssec.org
> https://lists.opendnssec.org/mailman/listinfo/opendnssec-develop

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opendnssec.org/pipermail/opendnssec-develop/attachments/20121105/0d1ff147/attachment.htm>

From rick at openfortress.nl  Mon Nov  5 11:14:03 2012
From: rick at openfortress.nl (Rick van Rein)
Date: Mon, 5 Nov 2012 11:14:03 +0000
Subject: [Opendnssec-develop] Making ODS immune for localtime changes
In-Reply-To: <50979872.9030604@nominet.org.uk>
References: <20121102143620.GB6208@newphantom.local>
	<50979872.9030604@nominet.org.uk>
Message-ID: <20121105111403.GC17027@newphantom.local>

Hi Sion / others,

Thanks for thinking along:

> This is worth looking at closely. One worry for me would be pushing
> these changes out as we will then switch people from local time to
> UTC which for most folks will be more than the one hour summer-time
> switch.

Yes, I share that concern for one half of the globe.  We may have to
play a Phileas Fogg on them; preparing the database with time zones
on the safe side of UTC: "UTC-23h" or "UTC+23h" (not sure which),
and so on.

Alternatively, we could ensure that 2.0 resolves those issues by
not depending on timestamping, but on actual feedback from the
surrounding world.

> Also note that InceptionOffset should not interfere with keys being
> introduced; but maybe we should at least recommend that the publish
> safety is at least one hour to cover DST (this is the supplied
> default)?

Both variables would need our thinking through I suppose.  Setting them
to 1h + the actually wished-for variance sounds to me like a workaround,
but not an actual solution.  It's weird to have to set such variables
to a high value just because there *may* be a time shift every now and
then, and be delayed because of it throughout the rest of the year.


Cheers,
 -Rick


From sara at sinodun.com  Mon Nov  5 11:40:57 2012
From: sara at sinodun.com (Sara Dickinson)
Date: Mon, 5 Nov 2012 11:40:57 +0000
Subject: [Opendnssec-develop] Making ODS immune for localtime changes
In-Reply-To: <20121105111403.GC17027@newphantom.local>
References: <20121102143620.GB6208@newphantom.local>
	<50979872.9030604@nominet.org.uk>
	<20121105111403.GC17027@newphantom.local>
Message-ID: <D14076E1-7CFE-4527-B317-2B73E389B2D1@sinodun.com>


On 5 Nov 2012, at 11:14, Rick van Rein wrote:

> Hi Sion / others,
> 
> Thanks for thinking along:
> 
>> This is worth looking at closely. One worry for me would be pushing
>> these changes out as we will then switch people from local time to
>> UTC which for most folks will be more than the one hour summer-time
>> switch.
> 
> Yes, I share that concern for one half of the globe.  We may have to
> play a Phileas Fogg on them; preparing the database with time zones
> on the safe side of UTC: "UTC-23h" or "UTC+23h" (not sure which),
> and so on.
> 
> Alternatively, we could ensure that 2.0 resolves those issues by
> not depending on timestamping, but on actual feedback from the
> surrounding world.

I've opened a JIRA issue to review the position in 2.0:

https://issues.opendnssec.org/browse/OPENDNSSEC-347


> 
>> Also note that InceptionOffset should not interfere with keys being
>> introduced; but maybe we should at least recommend that the publish
>> safety is at least one hour to cover DST (this is the supplied
>> default)?
> 
> Both variables would need our thinking through I suppose.  Setting them
> to 1h + the actually wished-for variance sounds to me like a workaround,
> but not an actual solution.  It's weird to have to set such variables
> to a high value just because there *may* be a time shift every now and
> then, and be delayed because of it throughout the rest of the year.
> 
> 
> Cheers,
> -Rick
> _______________________________________________
> Opendnssec-develop mailing list
> Opendnssec-develop at lists.opendnssec.org
> https://lists.opendnssec.org/mailman/listinfo/opendnssec-develop



From jerry at opendnssec.org  Mon Nov  5 11:51:15 2012
From: jerry at opendnssec.org (=?iso-8859-1?Q?Jerry_Lundstr=F6m?=)
Date: Mon, 5 Nov 2012 12:51:15 +0100
Subject: [Opendnssec-develop] Making ODS immune for localtime changes
In-Reply-To: <20121105111403.GC17027@newphantom.local>
References: <20121102143620.GB6208@newphantom.local>
	<50979872.9030604@nominet.org.uk>
	<20121105111403.GC17027@newphantom.local>
Message-ID: <3580E2AE-AC21-4BD4-8190-0267BFC53D29@opendnssec.org>

First off, very good work Rick!! Kudos!

On Nov 5, 2012, at 12:14 , Rick van Rein wrote:

>> This is worth looking at closely. One worry for me would be pushing
>> these changes out as we will then switch people from local time to
>> UTC which for most folks will be more than the one hour summer-time
>> switch.
> 
> Yes, I share that concern for one half of the globe.  We may have to
> play a Phileas Fogg on them; preparing the database with time zones
> on the safe side of UTC: "UTC-23h" or "UTC+23h" (not sure which),
> and so on.

I don't think we need "push" UTC on people, if we work by UTC in the database and the time calculations which its not affected by summer time then we could easily display the times in logs and command line output using the current timezone the system has configured.

>> Also note that InceptionOffset should not interfere with keys being
>> introduced; but maybe we should at least recommend that the publish
>> safety is at least one hour to cover DST (this is the supplied
>> default)?
> 
> Both variables would need our thinking through I suppose.  Setting them
> to 1h + the actually wished-for variance sounds to me like a workaround,
> but not an actual solution.  It's weird to have to set such variables
> to a high value just because there *may* be a time shift every now and
> then, and be delayed because of it throughout the rest of the year.

I agree with Rick here, it sounds like a workaround and I would really like to see a solution instead. We should not assume anything and we should be able to handle a system timezone change large then 1h.

/Jerry

--
Jerry Lundstr?m - OpenDNSSEC Developer
http://www.opendnssec.org/



From jerry at opendnssec.org  Mon Nov  5 14:12:32 2012
From: jerry at opendnssec.org (=?iso-8859-1?Q?Jerry_Lundstr=F6m?=)
Date: Mon, 5 Nov 2012 15:12:32 +0100
Subject: [Opendnssec-develop] =?windows-1252?q?Benchmarking_hardware_at_S?=
 =?windows-1252?q?URFnet_on_the_way_=85_so_what_OS=3F?=
Message-ID: <37A7CC79-3A8B-45FC-AFB6-CDBEAA596357@opendnssec.org>

Hi,

Just received word that our benchmarking hardware is racked and ready to be installed.

What OS do people think we should have?

Ubuntu/Debian - Easy and free.
Red Hat - What most of our users use.

Throw your 2c in please!

/Jerry

--
Jerry Lundstr?m - OpenDNSSEC Developer
http://www.opendnssec.org/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 495 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.opendnssec.org/pipermail/opendnssec-develop/attachments/20121105/268d05f9/attachment.bin>

From matthijs at nlnetlabs.nl  Mon Nov  5 16:18:23 2012
From: matthijs at nlnetlabs.nl (Matthijs Mekking)
Date: Mon, 05 Nov 2012 17:18:23 +0100
Subject: =?windows-1252?Q?Re=3A_=5BOpendnssec-develop=5D_Benchmarking?=
	=?windows-1252?Q?_hardware_at_SURFnet_on_the_way_=85_so_?=
	=?windows-1252?Q?what_OS=3F?=
In-Reply-To: <37A7CC79-3A8B-45FC-AFB6-CDBEAA596357@opendnssec.org>
References: <37A7CC79-3A8B-45FC-AFB6-CDBEAA596357@opendnssec.org>
Message-ID: <5097E6CF.80206@nlnetlabs.nl>

On 11/05/2012 03:12 PM, Jerry Lundstr?m wrote:
> Hi,
>
> Just received word that our benchmarking hardware is racked and ready to be installed.
>
> What OS do people think we should have?
>
> Ubuntu/Debian - Easy and free.
> Red Hat - What most of our users use.

Red Hat, because for benchmarking I think you want to be as close to the 
expectations of the users and then I think that argument weights more 
than the easy and free one.

Fedora might be a good alternative.

>
> Throw your 2c in please!
>
> /Jerry
>
> --
> Jerry Lundstr?m - OpenDNSSEC Developer
> http://www.opendnssec.org/
>
>
>
> _______________________________________________
> Opendnssec-develop mailing list
> Opendnssec-develop at lists.opendnssec.org
> https://lists.opendnssec.org/mailman/listinfo/opendnssec-develop
>



From jakob at kirei.se  Mon Nov  5 18:37:58 2012
From: jakob at kirei.se (Jakob Schlyter)
Date: Mon, 5 Nov 2012 19:37:58 +0100
Subject: =?windows-1252?Q?Re=3A_=5BOpendnssec-develop=5D_Benchmarking_har?=
	=?windows-1252?Q?dware_at_SURFnet_on_the_way_=85_so_what_OS=3F?=
In-Reply-To: <5097E6CF.80206@nlnetlabs.nl>
References: <37A7CC79-3A8B-45FC-AFB6-CDBEAA596357@opendnssec.org>
	<5097E6CF.80206@nlnetlabs.nl>
Message-ID: <930793FD-91BD-41E2-9B9D-346ADB4E6DFE@kirei.se>

On 5 nov 2012, at 17:18, Matthijs Mekking <matthijs at nlnetlabs.nl> wrote:

> Red Hat, because for benchmarking I think you want to be as close to the expectations of the users and then I think that argument weights more than the easy and free one.
> 
> Fedora might be a good alternative.

+1


	jakob



From sion at nominet.org.uk  Tue Nov  6 09:11:59 2012
From: sion at nominet.org.uk (=?windows-1252?Q?Si=F4n_Lloyd?=)
Date: Tue, 6 Nov 2012 09:11:59 +0000
Subject: =?windows-1252?Q?Re=3A_=5BOpendnssec-develop=5D_Benchmarking?=
	=?windows-1252?Q?_hardware_at_SURFnet_on_the_way_=85_so_?=
	=?windows-1252?Q?what_OS=3F?=
In-Reply-To: <930793FD-91BD-41E2-9B9D-346ADB4E6DFE@kirei.se>
References: <37A7CC79-3A8B-45FC-AFB6-CDBEAA596357@opendnssec.org>
	<5097E6CF.80206@nlnetlabs.nl>
	<930793FD-91BD-41E2-9B9D-346ADB4E6DFE@kirei.se>
Message-ID: <5098D45F.1030505@nominet.org.uk>

On 05/11/12 18:37, Jakob Schlyter wrote:
> On 5 nov 2012, at 17:18, Matthijs Mekking <matthijs at nlnetlabs.nl> wrote:
>
>> Red Hat, because for benchmarking I think you want to be as close to the expectations of the users and then I think that argument weights more than the easy and free one.
>>
>> Fedora might be a good alternative.
> +1
>
>

Wouldn't it be slightly odd to use an OS that we do not have in Jenkins? 
Even if it is from the same family.

I'd say RedHat or Centos.

Sion

(Not quite 2c due to the exchange rate and commission.)


From Roland.vanRijswijk at surfnet.nl  Tue Nov  6 12:34:19 2012
From: Roland.vanRijswijk at surfnet.nl (Roland van Rijswijk - Deij)
Date: Tue, 6 Nov 2012 13:34:19 +0100
Subject: =?windows-1252?Q?Re=3A_=5BOpendnssec-develop=5D_Benchmarking_har?=
	=?windows-1252?Q?dware_at_SURFnet_on_the_way_=85_so_what_OS=3F?=
In-Reply-To: <5098D45F.1030505@nominet.org.uk>
References: <37A7CC79-3A8B-45FC-AFB6-CDBEAA596357@opendnssec.org>
	<5097E6CF.80206@nlnetlabs.nl>
	<930793FD-91BD-41E2-9B9D-346ADB4E6DFE@kirei.se>
	<5098D45F.1030505@nominet.org.uk>
Message-ID: <B39B6A30-CE53-4918-A745-F674970BAE60@surfnet.nl>


On 6 nov. 2012, at 10:11, Si?n Lloyd <sion at nominet.org.uk> wrote:

> On 05/11/12 18:37, Jakob Schlyter wrote:
>> On 5 nov 2012, at 17:18, Matthijs Mekking <matthijs at nlnetlabs.nl> wrote:
>> 
>>> Red Hat, because for benchmarking I think you want to be as close to the expectations of the users and then I think that argument weights more than the easy and free one.
>>> 
>>> Fedora might be a good alternative.
>> +1
>> 
>> 
> 
> Wouldn't it be slightly odd to use an OS that we do not have in Jenkins? Even if it is from the same family.
> 
> I'd say RedHat or Centos.


+1

We can supply a Red Hat licence so don't worry about cost

Cheers,

Roland

-- Roland M. van Rijswijk - Deij
-- SURFnet bv
-- w: http://www.surfnet.nl/en/
-- t: +31-30-2305388
-- e: roland.vanrijswijk at surfnet.nl



From Roland.vanRijswijk at surfnet.nl  Tue Nov  6 12:45:47 2012
From: Roland.vanRijswijk at surfnet.nl (Roland van Rijswijk - Deij)
Date: Tue, 6 Nov 2012 13:45:47 +0100
Subject: [Opendnssec-develop] SoftHSMv2 and IPC
In-Reply-To: <CAGTFMNa=bd2TsUKmS=0Q6-3cW_OyYHkiWz_HPetBSkA1FRSeLg@mail.gmail.com>
References: <CAKFiofmYdwLD_qEVe6Z0b0_o2XFJ89ZdC3ZoU4LbVwtoOxGmjA@mail.gmail.com>
	<CAGTFMNbSgBmaXCF3Yyy+_cyDfqB70UGzxJVcMfJLbvxQ4VG=vw@mail.gmail.com>
	<CAKFiof=ETyKGMNu2vPxtOtPC_EqnT9BdrAVP_NZBdhufwbdH0w@mail.gmail.com>
	<CAGTFMNa=bd2TsUKmS=0Q6-3cW_OyYHkiWz_HPetBSkA1FRSeLg@mail.gmail.com>
Message-ID: <A2F05C4D-E7F8-46F9-B5AF-3CDCA1C28586@surfnet.nl>

Hi Jerry,

On 31 okt. 2012, at 08:42, Jerry Lundstr?m <jerry at opendnssec.org> wrote:

> On Tue, Oct 30, 2012 at 10:19 PM, Rickard Bellgrim
> <rickard at opendnssec.org> wrote:
>>> Why do we have a semaphore per object?
>> 
>> For synchronizing changes between processes. There is a memory layer
>> and file layer. To minimize the number of semaphore, it would be
>> better to re-design this part.
> 
> I've been looking at the code and from what I can see it uses
> semaphores as a type of revision for the object tokens and files to
> know when to reread them from disk, please correct me if I'm wrong.

That is correct. This is my fault/doing, I opted for this as it seemed to be the most platform independent way of achieving simple and carefree IPC triggers. To improve the performance of SoftHSM v2 all data is kept in memory and only re-read from disk when necessary. This means there needed to be a way to trigger all running processes when an object is created or changed.

> Since we have a file per key (I assume) then there is another
> limitation that you must be aware of, the number of files in a
> directory is limited depending on the file system used. This is why
> most file based backends like this split the first part of the files
> names into 2-3 levels of directories to increase the number of files
> it can have.

There is a file per PKCS #11 object and a directory per token.

> The use of semaphores here is very strange in my view but it could work.

It is the simplest (i.e. most lightweight) way I could think of to do the inter-process signalling. But if it isn't available on some platforms (as you mentioned in an earlier e-mail) it might be better to replace this.

> There is one thing that came to mind, if instead of using semaphore
> you use the first bytes of the file and a revision marker then this
> type of object store could be used on a network based file system
> (NFS) running two active setups. Then put Lim (or similar) on top and
> you have a redundant network based (H)SM with REST/SOAP/* APIs.

I considered that when writing the code, but that meant IOPs which turned out to be much more expensive (in terms of cycles/delay) than the semaphore.

> I also noticed that in ObjectFile::commitTransaction it releases the
> mutex for the object, releases the transaction lock and puts it out of
> transaction before storing the object. And in store() it does not lock
> the mutex before checking if its in transaction. This can lead to
> another thread/process starting an transaction after store() checked
> that and alter information of the ObjectFile as it is storing it.
> commitTransaction should not release the mutex, it should be locked
> during the store().
> 
> And I see a lot of mutexes, transaction locks and locks on the files
> itself all in different orders which will eventually lead to dead
> locks.


Hmm? that may require some inspection.

Cheers,

Roland

-- Roland M. van Rijswijk - Deij
-- SURFnet bv
-- w: http://www.surfnet.nl/en/
-- t: +31-30-2305388
-- e: roland.vanrijswijk at surfnet.nl



From Roland.vanRijswijk at surfnet.nl  Tue Nov  6 12:48:37 2012
From: Roland.vanRijswijk at surfnet.nl (Roland van Rijswijk - Deij)
Date: Tue, 6 Nov 2012 13:48:37 +0100
Subject: [Opendnssec-develop] SoftHSM performance
In-Reply-To: <CAKFiofnXqJqmcn3gHHCP8KrZ5zm5M04uUj=_+SmVWCrgWK4-Zw@mail.gmail.com>
References: <CAKFiofnXqJqmcn3gHHCP8KrZ5zm5M04uUj=_+SmVWCrgWK4-Zw@mail.gmail.com>
Message-ID: <A8E61E17-6666-4CA4-BB68-BDD50A6FD2BB@surfnet.nl>

Hi,

On 25 okt. 2012, at 16:11, Rickard Bellgrim <rickard at opendnssec.org> wrote:

> I have compared the performance between SoftHSMv1 and SoftHSMv2
> (OpenSSL and Botan).
> 
> SoftHSMv2 OpenSSL:
> ods-hsmspeed -r SoftHSM -i 50000 -s 1024 -t 1
> 1032.66 sig/s
> 
> SoftHSMv2 Botan:
> ods-hsmspeed -r SoftHSM -i 10000 -s 1024 -t 1
> 236.15 sig/s
> 
> SoftHSMv1:
> ods-hsmspeed -r SoftHSM -i 50000 -s 1024 -t 1
> 1376.68 sig/s
> 
> SoftHSMv2 is currently having some threading issues. Thus not possible
> to do multi-threaded tests.
> 
> The negative with Botan is the overhead when e.g. creating the RSA C++
> object. SoftHSMv1 utilizes an object cache, so that the Botan key
> objects does not need to be recreated all of the time. Is that
> something we want for SoftHSMv2? E.g. an 1-key cache?


To add to that: I would generally expect SoftHSM v2 to perform at about the same level or a little worse than SoftHSM v1. A reason for it performing a bit worse is that SoftHSM v2 keeps all sensitive data encrypted in memory and does "just-in-time" decryption to minimise the time that sensitive data is in memory in the clear. The implementation of that is quite strict, if speed is an absolute requirement we could consider adding a configure-time option for disabling the in-memory encryption (but that would sort-of defy the purpose of SoftHSM v2).

Cheers,

Roland

-- Roland M. van Rijswijk - Deij
-- SURFnet bv
-- w: http://www.surfnet.nl/en/
-- t: +31-30-2305388
-- e: roland.vanrijswijk at surfnet.nl



From matthijs at nlnetlabs.nl  Tue Nov  6 13:16:03 2012
From: matthijs at nlnetlabs.nl (Matthijs Mekking)
Date: Tue, 06 Nov 2012 14:16:03 +0100
Subject: =?windows-1252?Q?Re=3A_=5BOpendnssec-develop=5D_Benchmarking?=
	=?windows-1252?Q?_hardware_at_SURFnet_on_the_way_=85_so_?=
	=?windows-1252?Q?what_OS=3F?=
In-Reply-To: <B39B6A30-CE53-4918-A745-F674970BAE60@surfnet.nl>
References: <37A7CC79-3A8B-45FC-AFB6-CDBEAA596357@opendnssec.org>
	<5097E6CF.80206@nlnetlabs.nl>
	<930793FD-91BD-41E2-9B9D-346ADB4E6DFE@kirei.se>
	<5098D45F.1030505@nominet.org.uk>
	<B39B6A30-CE53-4918-A745-F674970BAE60@surfnet.nl>
Message-ID: <50990D93.4050308@nlnetlabs.nl>

On 11/06/2012 01:34 PM, Roland van Rijswijk - Deij wrote:
> 
> On 6 nov. 2012, at 10:11, Si?n Lloyd <sion at nominet.org.uk> wrote:
> 
>> On 05/11/12 18:37, Jakob Schlyter wrote:
>>> On 5 nov 2012, at 17:18, Matthijs Mekking <matthijs at nlnetlabs.nl> wrote:
>>>
>>>> Red Hat, because for benchmarking I think you want to be as close to the expectations of the users and then I think that argument weights more than the easy and free one.
>>>>
>>>> Fedora might be a good alternative.
>>> +1
>>>
>>>
>>
>> Wouldn't it be slightly odd to use an OS that we do not have in Jenkins? Even if it is from the same family.
>>
>> I'd say RedHat or Centos.
> 
> 
> +1
> 
> We can supply a Red Hat licence so don't worry about cost

Then +1 for RHEL

> 
> Cheers,
> 
> Roland
> 
> -- Roland M. van Rijswijk - Deij
> -- SURFnet bv
> -- w: http://www.surfnet.nl/en/
> -- t: +31-30-2305388
> -- e: roland.vanrijswijk at surfnet.nl
> 
> _______________________________________________
> Opendnssec-develop mailing list
> Opendnssec-develop at lists.opendnssec.org
> https://lists.opendnssec.org/mailman/listinfo/opendnssec-develop
> 


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 551 bytes
Desc: OpenPGP digital signature
URL: <http://lists.opendnssec.org/pipermail/opendnssec-develop/attachments/20121106/d7cfc296/attachment.bin>

From jerry at opendnssec.org  Wed Nov  7 08:00:16 2012
From: jerry at opendnssec.org (=?ISO-8859-1?Q?Jerry_Lundstr=F6m?=)
Date: Wed, 7 Nov 2012 09:00:16 +0100
Subject: [Opendnssec-develop] Test platform access
Message-ID: <CAGTFMNbvw4ZUNTMceDh_GBCTrwo0VjF6aFXnjx52DaZgPxsejg@mail.gmail.com>

Hi,

Yesterday I noticed that the script to sync ssh-keys to the test
platforms was not working well.

I fixed some but there is still problem with 2 of them (NetBSD and
Solaris if I remember correctly) and I will look at that today.

/Jerry

-- 
Jerry Lundstr?m - OpenDNSSEC Developer
http://www.opendnssec.org/


From jerry at opendnssec.org  Wed Nov  7 08:02:30 2012
From: jerry at opendnssec.org (=?ISO-8859-1?Q?Jerry_Lundstr=F6m?=)
Date: Wed, 7 Nov 2012 09:02:30 +0100
Subject: [Opendnssec-develop] All Jenkins jobs disabled 13:00 CET and
	forward, maintenance work on platforms
Message-ID: <CAGTFMNbPNbEwD+agxtP42jsLtyDFY5R1KRXqRbUsW6_hvQZV8g@mail.gmail.com>

Hi,

As subject says, doing distribution updates on all platforms and it
will take a while.

/Jerry

-- 
Jerry Lundstr?m - OpenDNSSEC Developer
http://www.opendnssec.org/


From jerry at opendnssec.org  Wed Nov  7 08:37:37 2012
From: jerry at opendnssec.org (=?ISO-8859-1?Q?Jerry_Lundstr=F6m?=)
Date: Wed, 7 Nov 2012 09:37:37 +0100
Subject: [Opendnssec-develop] Off on holiday 14 nov to 9 dec, hand off list
Message-ID: <CAGTFMNYmFiwNr5T6_DR0v4+Nc3iZ3JaRMEJmnhyMvmAONp2fbA@mail.gmail.com>

Hi,

Here is the list of stuff others will take while I am away.

Jenkins and Test VMs - Sion
Sion will have full access to all VMs and I am working on documenting
some trouble shooting instructions in case something goes wrong. We
won't really go into how to setup new jobs or how to add code to the
test framework.

Building releases - Jakob
He's done it before so he probably can do it again :)

SVN / OpenDNSSEC server - Patrik
Patrik has the same access as me to the new OpenDNSSEC server at .SE
and we will document internally how its setup. So in case of an
emergency regarding the SVN, Patrik is the one to call while I am
away. We will have to wait with the Coverity setup until I am back.

JIRA - Sara
Sara will be managing JIRA, will see to it that she has all the access
needed in case something happens with the user access etc.

If I have missed anything please tell me.

And its not like I won't have internet access, so I'll just be an email away.
/Jerry

-- 
Jerry Lundstr?m - OpenDNSSEC Developer
http://www.opendnssec.org/


From sara at sinodun.com  Wed Nov  7 11:34:33 2012
From: sara at sinodun.com (Sara Dickinson)
Date: Wed, 7 Nov 2012 11:34:33 +0000
Subject: =?windows-1252?Q?Re=3A_=5BOpendnssec-develop=5D_Benchmarking_har?=
	=?windows-1252?Q?dware_at_SURFnet_on_the_way_=85_so_what_OS=3F?=
In-Reply-To: <50990D93.4050308@nlnetlabs.nl>
References: <37A7CC79-3A8B-45FC-AFB6-CDBEAA596357@opendnssec.org>
	<5097E6CF.80206@nlnetlabs.nl>
	<930793FD-91BD-41E2-9B9D-346ADB4E6DFE@kirei.se>
	<5098D45F.1030505@nominet.org.uk>
	<B39B6A30-CE53-4918-A745-F674970BAE60@surfnet.nl>
	<50990D93.4050308@nlnetlabs.nl>
Message-ID: <C5221B6F-05A5-4E92-898E-0B7ABD0727C6@sinodun.com>


On 6 Nov 2012, at 13:16, Matthijs Mekking wrote:

> Then +1 for RHEL

+1

Sara.


From jerry at opendnssec.org  Wed Nov  7 11:42:06 2012
From: jerry at opendnssec.org (=?ISO-8859-1?Q?Jerry_Lundstr=F6m?=)
Date: Wed, 7 Nov 2012 12:42:06 +0100
Subject: =?windows-1252?Q?Re=3A_=5BOpendnssec=2Ddevelop=5D_Benchmarking_hardware_at_SU?=
	=?windows-1252?Q?RFnet_on_the_way_=85_so_what_OS=3F?=
In-Reply-To: <C5221B6F-05A5-4E92-898E-0B7ABD0727C6@sinodun.com>
References: <37A7CC79-3A8B-45FC-AFB6-CDBEAA596357@opendnssec.org>
	<5097E6CF.80206@nlnetlabs.nl>
	<930793FD-91BD-41E2-9B9D-346ADB4E6DFE@kirei.se>
	<5098D45F.1030505@nominet.org.uk>
	<B39B6A30-CE53-4918-A745-F674970BAE60@surfnet.nl>
	<50990D93.4050308@nlnetlabs.nl>
	<C5221B6F-05A5-4E92-898E-0B7ABD0727C6@sinodun.com>
Message-ID: <-5253875230320058768@unknownmsgid>

Majority has spoken, RHEL it is.

/Jerry


From matthijs at nlnetlabs.nl  Wed Nov  7 12:02:48 2012
From: matthijs at nlnetlabs.nl (Matthijs Mekking)
Date: Wed, 07 Nov 2012 13:02:48 +0100
Subject: =?windows-1252?Q?Re=3A_=5BOpendnssec-develop=5D_Benchmarking?=
	=?windows-1252?Q?_hardware_at_SURFnet_on_the_way_=85_so_?=
	=?windows-1252?Q?what_OS=3F?=
In-Reply-To: <-5253875230320058768@unknownmsgid>
References: <37A7CC79-3A8B-45FC-AFB6-CDBEAA596357@opendnssec.org>
	<5097E6CF.80206@nlnetlabs.nl>
	<930793FD-91BD-41E2-9B9D-346ADB4E6DFE@kirei.se>
	<5098D45F.1030505@nominet.org.uk>
	<B39B6A30-CE53-4918-A745-F674970BAE60@surfnet.nl>
	<50990D93.4050308@nlnetlabs.nl>
	<C5221B6F-05A5-4E92-898E-0B7ABD0727C6@sinodun.com>
	<-5253875230320058768@unknownmsgid>
Message-ID: <509A4DE8.8080608@nlnetlabs.nl>

Ya gotta love democracy :)

On 11/07/2012 12:42 PM, Jerry Lundstr?m wrote:
> Majority has spoken, RHEL it is.
> 
> /Jerry
> _______________________________________________
> Opendnssec-develop mailing list
> Opendnssec-develop at lists.opendnssec.org
> https://lists.opendnssec.org/mailman/listinfo/opendnssec-develop
> 


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 551 bytes
Desc: OpenPGP digital signature
URL: <http://lists.opendnssec.org/pipermail/opendnssec-develop/attachments/20121107/e8220571/attachment.bin>

From jerry at opendnssec.org  Wed Nov  7 15:50:37 2012
From: jerry at opendnssec.org (=?iso-8859-1?Q?Jerry_Lundstr=F6m?=)
Date: Wed, 7 Nov 2012 16:50:37 +0100
Subject: [Opendnssec-develop] Re: svn.opendnssec.org down
In-Reply-To: <-6864534731609728086@unknownmsgid>
References: <8A5A57CA-B9AA-420F-A785-8BA1D08B80CA@opendnssec.org>
	<DC21CB8F-DC5E-4041-83DB-504F5FC657EB@opendnssec.org>
	<-6864534731609728086@unknownmsgid>
Message-ID: <8D569407-CA05-4B01-B02F-8C6D91216789@opendnssec.org>

Downtime for SVN tomorrow (8 nov) from 10:00 CET up to 12:00 CET.

We will finally be getting IPv6 on all hosts and the downtime is for KVM host to be reconfigured and verified it works on reboot.

On Oct 18, 2012, at 12:46 , Jerry Lundstr?m wrote:

> There will be a short downtime tomorrow friday for svn.opendnssec.org
> and dist.opendnssec.org during the day. This is to try and enable
> IPv6.
> 
> I will send an email shortly before the downtime and it will be very
> short (~15min).


--
Jerry Lundstr?m - OpenDNSSEC Developer
http://www.opendnssec.org/



From jerry at opendnssec.org  Wed Nov  7 16:22:24 2012
From: jerry at opendnssec.org (=?ISO-8859-1?Q?Jerry_Lundstr=F6m?=)
Date: Wed, 7 Nov 2012 17:22:24 +0100
Subject: [Opendnssec-develop] Re: All Jenkins jobs disabled 13:00 CET and
 forward, maintenance work on platforms
In-Reply-To: <CAGTFMNbPNbEwD+agxtP42jsLtyDFY5R1KRXqRbUsW6_hvQZV8g@mail.gmail.com>
References: <CAGTFMNbPNbEwD+agxtP42jsLtyDFY5R1KRXqRbUsW6_hvQZV8g@mail.gmail.com>
Message-ID: <7129895388348818832@unknownmsgid>

All but FreeBSD are up to date, they will probably take most of the night.

/Jerry

On 7 nov 2012, at 09:02, "Jerry Lundstr?m" <jerry at opendnssec.org> wrote:

> Hi,
>
> As subject says, doing distribution updates on all platforms and it
> will take a while.
>
> /Jerry
>
> --
> Jerry Lundstr?m - OpenDNSSEC Developer
> http://www.opendnssec.org/


From jerry at opendnssec.org  Thu Nov  8 07:32:20 2012
From: jerry at opendnssec.org (=?ISO-8859-1?Q?Jerry_Lundstr=F6m?=)
Date: Thu, 8 Nov 2012 08:32:20 +0100
Subject: [Opendnssec-develop] Re: All Jenkins jobs disabled 13:00 CET and
 forward, maintenance work on platforms
In-Reply-To: <7129895388348818832@unknownmsgid>
References: <CAGTFMNbPNbEwD+agxtP42jsLtyDFY5R1KRXqRbUsW6_hvQZV8g@mail.gmail.com>
	<7129895388348818832@unknownmsgid>
Message-ID: <CAGTFMNb+htSHtQbcsmaXatorDK942Upp-2tV3_nscVjQfmbUSw@mail.gmail.com>

FreeBSD done, Jenkins back up!

-- 
Jerry Lundstr?m - OpenDNSSEC Developer
http://www.opendnssec.org/


From jerry at opendnssec.org  Thu Nov  8 09:27:18 2012
From: jerry at opendnssec.org (=?iso-8859-1?Q?Jerry_Lundstr=F6m?=)
Date: Thu, 8 Nov 2012 10:27:18 +0100
Subject: [Opendnssec-develop] Re: svn.opendnssec.org down
In-Reply-To: <8D569407-CA05-4B01-B02F-8C6D91216789@opendnssec.org>
References: <8A5A57CA-B9AA-420F-A785-8BA1D08B80CA@opendnssec.org>
	<DC21CB8F-DC5E-4041-83DB-504F5FC657EB@opendnssec.org>
	<-6864534731609728086@unknownmsgid>
	<8D569407-CA05-4B01-B02F-8C6D91216789@opendnssec.org>
Message-ID: <2E0322A9-7954-485A-91EC-57A4CF655957@opendnssec.org>

svn.opendnssec.org and dist.opendnssec.org will now be taken down for an hour or so.

--
Jerry Lundstr?m - OpenDNSSEC Developer
http://www.opendnssec.org/



From jerry at opendnssec.org  Thu Nov  8 10:40:45 2012
From: jerry at opendnssec.org (=?ISO-8859-1?Q?Jerry_Lundstr=F6m?=)
Date: Thu, 8 Nov 2012 11:40:45 +0100
Subject: [Opendnssec-develop] Re: svn.opendnssec.org down
In-Reply-To: <2E0322A9-7954-485A-91EC-57A4CF655957@opendnssec.org>
References: <8A5A57CA-B9AA-420F-A785-8BA1D08B80CA@opendnssec.org>
	<DC21CB8F-DC5E-4041-83DB-504F5FC657EB@opendnssec.org>
	<-6864534731609728086@unknownmsgid>
	<8D569407-CA05-4B01-B02F-8C6D91216789@opendnssec.org>
	<2E0322A9-7954-485A-91EC-57A4CF655957@opendnssec.org>
Message-ID: <5911461835518768229@unknownmsgid>

Might have to extend downtime an hour or two.

/Jerry

On 8 nov 2012, at 10:27, "Jerry Lundstr?m" <jerry at opendnssec.org> wrote:

> svn.opendnssec.org and dist.opendnssec.org will now be taken down for an hour or so.
>
> --
> Jerry Lundstr?m - OpenDNSSEC Developer
> http://www.opendnssec.org/
>


From jerry at opendnssec.org  Thu Nov  8 12:45:41 2012
From: jerry at opendnssec.org (=?iso-8859-1?Q?Jerry_Lundstr=F6m?=)
Date: Thu, 8 Nov 2012 13:45:41 +0100
Subject: [Opendnssec-develop] Re: svn.opendnssec.org down
In-Reply-To: <5911461835518768229@unknownmsgid>
References: <8A5A57CA-B9AA-420F-A785-8BA1D08B80CA@opendnssec.org>
	<DC21CB8F-DC5E-4041-83DB-504F5FC657EB@opendnssec.org>
	<-6864534731609728086@unknownmsgid>
	<8D569407-CA05-4B01-B02F-8C6D91216789@opendnssec.org>
	<2E0322A9-7954-485A-91EC-57A4CF655957@opendnssec.org>
	<5911461835518768229@unknownmsgid>
Message-ID: <CBAF4978-3038-45C9-97E4-05DED35824A0@opendnssec.org>

Coming back up now.

On Nov 8, 2012, at 11:40 , Jerry Lundstr?m wrote:

> Might have to extend downtime an hour or two.
> 
> On 8 nov 2012, at 10:27, "Jerry Lundstr?m" <jerry at opendnssec.org> wrote:
> 
>> svn.opendnssec.org and dist.opendnssec.org will now be taken down for an hour or so.


--
Jerry Lundstr?m - OpenDNSSEC Developer
http://www.opendnssec.org/



From sara at sinodun.com  Fri Nov  9 10:08:38 2012
From: sara at sinodun.com (Sara Dickinson)
Date: Fri, 9 Nov 2012 10:08:38 +0000
Subject: [Opendnssec-develop] RE: 1.3.11 release
Message-ID: <61629749-36C3-4452-A3BB-2432C5A4E34B@sinodun.com>

Hi All, 

As far as I can see in JIRA we have closed all the issues that were agreed on in the last meeting for a 1.3.11 release. Shall we go ahead with the release or does anyone want to nominate any other issues for inclusion? 

Sara.




From sara at sinodun.com  Fri Nov  9 16:43:09 2012
From: sara at sinodun.com (Sara Dickinson)
Date: Fri, 9 Nov 2012 16:43:09 +0000
Subject: [Opendnssec-develop] RE: Team Meeting - Monday 12th Nov @ 14.00 CET
Message-ID: <E4CCDC44-AF62-4269-9CC3-4DD9684E812F@sinodun.com>

Hi All, 

We have a scheduled team meeting Monday:

Date:      Monday 12 November 2012
Time:      14:00-15:00 CET, 13:00-14:00 GMT
Method:  Google+
Agenda:  http://wiki.opendnssec.org/display/OpenDNSSEC/2012-11-12+agenda

Sara.






From matthijs at nlnetlabs.nl  Mon Nov 12 15:30:17 2012
From: matthijs at nlnetlabs.nl (Matthijs Mekking)
Date: Mon, 12 Nov 2012 16:30:17 +0100
Subject: [Opendnssec-develop] Minutes 2012-11-12
Message-ID: <50A11609.8030602@nlnetlabs.nl>

Here they are.

https://wiki.opendnssec.org/display/OpenDNSSEC/2012-11-12+Minutes

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 551 bytes
Desc: OpenPGP digital signature
URL: <http://lists.opendnssec.org/pipermail/opendnssec-develop/attachments/20121112/f0ff4aa0/attachment.bin>

From jerry at opendnssec.org  Tue Nov 13 13:10:57 2012
From: jerry at opendnssec.org (=?iso-8859-1?Q?Jerry_Lundstr=F6m?=)
Date: Tue, 13 Nov 2012 14:10:57 +0100
Subject: [Opendnssec-develop] OpenDNSSEC 1.3.11 tar-ball up
Message-ID: <C51351BD-D5D8-43A0-8F8E-8FB0B0C379EB@opendnssec.org>

Tared, signed, done.

--
Jerry Lundstr?m - OpenDNSSEC Developer
http://www.opendnssec.org/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 495 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.opendnssec.org/pipermail/opendnssec-develop/attachments/20121113/44da7eac/attachment.bin>

From sion at nominet.org.uk  Wed Nov 14 13:39:57 2012
From: sion at nominet.org.uk (=?ISO-8859-1?Q?Si=F4n_Lloyd?=)
Date: Wed, 14 Nov 2012 13:39:57 +0000
Subject: [Opendnssec-develop] Jenkins
Message-ID: <50A39F2D.7020504@nominet.org.uk>

It looks like Jerrys "dead mans handle" script has done its job and
thrown jenkins into confusion as soon as he has left...

A couple of the builds had stalled, which had everything else queueing
behind them, so I killed them off and we'll see if it recovers...

My troubleshooting notes are limited to:

https://wiki.opendnssec.org/display/OpenDNSSEC/Jenkins

so I may have a few false starts as I try to fix it.

Sion


From sara at sinodun.com  Fri Nov 16 11:11:17 2012
From: sara at sinodun.com (Sara Dickinson)
Date: Fri, 16 Nov 2012 11:11:17 +0000
Subject: [Opendnssec-develop] RE: 1.3.11 release problems
Message-ID: <A5422A55-35F7-430E-A033-4BBDAE9609EC@sinodun.com>

Hi All, 

I wanted to summarise a couple of issue that have been found with the 1.3.11 release which mean we need to look at doing another release to address them. 

Firstly, Jaap Akkerhuis found a problem on FreeBSD (although it affects most linux systems) which causes ./configure to fail in the new checks that were added to exclude ldns versions 1.6.14 and 1.6.15.  We have a patch (see SUPPORT-40) for this which has been applied to trunk and 1.3. 

Secondly it seems that 1.3 will not build against ldns 1.6.16 on platforms that do not have strlcpy/cat because of missing LIBCOMPAT definitions in a couple of Makefiles. This has also been fixed in the 1.3 branch. The 1.3 jenkins tests are now running against ldns 1.6.16 and passing on all platforms.

The upshot is that I propose we do a further 1.3 release next week to address both these issues. At the moment I am suggesting we do a 1.3.12 release, with a release candidate first, followed by a full release. 

I have generated two actions from this:
- review if we should do release candidates for all bug fix release from now on in the next team meeting
- review what version(s) of ldns we use in jenkins (OPENDNSSEC-351)

If you have any other issues that you would like to nominate for this release or comments on the above please let me know asap.

Regards

Sara.

From matthijs at nlnetlabs.nl  Mon Nov 19 10:29:02 2012
From: matthijs at nlnetlabs.nl (Matthijs Mekking)
Date: Mon, 19 Nov 2012 11:29:02 +0100
Subject: [Opendnssec-develop] RE: 1.3.11 release problems
In-Reply-To: <A5422A55-35F7-430E-A033-4BBDAE9609EC@sinodun.com>
References: <A5422A55-35F7-430E-A033-4BBDAE9609EC@sinodun.com>
Message-ID: <50AA09EE.1090106@nlnetlabs.nl>

On 11/16/2012 12:11 PM, Sara Dickinson wrote:
> Hi All,
> 
> I wanted to summarise a couple of issue that have been found with the
> 1.3.11 release which mean we need to look at doing another release to
> address them.
> 
> Firstly, Jaap Akkerhuis found a problem on FreeBSD (although it
> affects most linux systems) which causes ./configure to fail in the
> new checks that were added to exclude ldns versions 1.6.14 and
> 1.6.15.  We have a patch (see SUPPORT-40) for this which has been
> applied to trunk and 1.3.

To avoid confusion, the corresponding issue is SUPPORT-42, not SUPPORT-40.

> Secondly it seems that 1.3 will not build against ldns 1.6.16 on
> platforms that do not have strlcpy/cat because of missing LIBCOMPAT
> definitions in a couple of Makefiles. This has also been fixed in the
> 1.3 branch. The 1.3 jenkins tests are now running against ldns 1.6.16
> and passing on all platforms.
> 
> The upshot is that I propose we do a further 1.3 release next week to
> address both these issues. At the moment I am suggesting we do a
> 1.3.12 release, with a release candidate first, followed by a full
> release.
> 
> I have generated two actions from this: - review if we should do
> release candidates for all bug fix release from now on in the next
> team meeting - review what version(s) of ldns we use in jenkins
> (OPENDNSSEC-351)
> 
> If you have any other issues that you would like to nominate for this
> release or comments on the above please let me know asap.
> 
> Regards
> 
> Sara._______________________________________________ 
> Opendnssec-develop mailing list 
> Opendnssec-develop at lists.opendnssec.org 
> https://lists.opendnssec.org/mailman/listinfo/opendnssec-develop
> 


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 551 bytes
Desc: OpenPGP digital signature
URL: <http://lists.opendnssec.org/pipermail/opendnssec-develop/attachments/20121119/86bf1c3f/attachment.bin>

From sara at sinodun.com  Mon Nov 19 11:02:35 2012
From: sara at sinodun.com (Sara Dickinson)
Date: Mon, 19 Nov 2012 11:02:35 +0000
Subject: [Opendnssec-develop] RE: 1.3.11 release problems
In-Reply-To: <50AA09EE.1090106@nlnetlabs.nl>
References: <A5422A55-35F7-430E-A033-4BBDAE9609EC@sinodun.com>
	<50AA09EE.1090106@nlnetlabs.nl>
Message-ID: <EB240E87-BAF6-4926-A86A-877F12593393@sinodun.com>


On 19 Nov 2012, at 10:29, Matthijs Mekking wrote:

> On 11/16/2012 12:11 PM, Sara Dickinson wrote:
>> Hi All,
>> 
>> I wanted to summarise a couple of issue that have been found with the
>> 1.3.11 release which mean we need to look at doing another release to
>> address them.
>> 
>> Firstly, Jaap Akkerhuis found a problem on FreeBSD (although it
>> affects most linux systems) which causes ./configure to fail in the
>> new checks that were added to exclude ldns versions 1.6.14 and
>> 1.6.15. We have a patch (see SUPPORT-40) for this which has been
>> applied to trunk and 1.3.
> 
> To avoid confusion, the corresponding issue is SUPPORT-42, not SUPPORT-40.

Indeed - thanks! More details on when precisely when the problem is seen in the issue. 

> The 1.3 jenkins tests are now running against ldns 1.6.16
> and passing on all platforms.

Trunk and enforcer-ng branch jenkins tests are also building against 1.6.16 for now. 

Sara.

> 
> _______________________________________________
> Opendnssec-develop mailing list
> Opendnssec-develop at lists.opendnssec.org
> https://lists.opendnssec.org/mailman/listinfo/opendnssec-develop



From rickard at opendnssec.org  Wed Nov 21 10:28:34 2012
From: rickard at opendnssec.org (Rickard Bellgrim)
Date: Wed, 21 Nov 2012 11:28:34 +0100
Subject: [Opendnssec-develop] Release SoftHSM 1.3.4
Message-ID: <CAKFiofnOx_n35TGG5e84XNvvXcirQQM6s920e_sL-fJbSn+xmg@mail.gmail.com>

Hi

SoftHSM is ready for release of version 1.3.4. All that is missing is
the release date in the NEWS-file. There are no more issues to be
resolved and the two new features were added some time ago. Also,
Jenkins is happy with softhsm-trunk.

// Rickard


From sara at sinodun.com  Wed Nov 21 13:16:05 2012
From: sara at sinodun.com (Sara Dickinson)
Date: Wed, 21 Nov 2012 13:16:05 +0000
Subject: [Opendnssec-develop] Release SoftHSM 1.3.4
In-Reply-To: <CAKFiofnOx_n35TGG5e84XNvvXcirQQM6s920e_sL-fJbSn+xmg@mail.gmail.com>
References: <CAKFiofnOx_n35TGG5e84XNvvXcirQQM6s920e_sL-fJbSn+xmg@mail.gmail.com>
Message-ID: <368A0984-A7D5-4D26-8338-EA351C08AF64@sinodun.com>

Hi Rickard, 

Thanks for the mail. Jerry is on vacation at the moment and Jakob is quite busy with the latest training course so we'll get to this as soon as we can!

Sara.


On 21 Nov 2012, at 10:28, Rickard Bellgrim wrote:

> Hi
> 
> SoftHSM is ready for release of version 1.3.4. All that is missing is
> the release date in the NEWS-file. There are no more issues to be
> resolved and the two new features were added some time ago. Also,
> Jenkins is happy with softhsm-trunk.
> 
> // Rickard
> _______________________________________________
> Opendnssec-develop mailing list
> Opendnssec-develop at lists.opendnssec.org
> https://lists.opendnssec.org/mailman/listinfo/opendnssec-develop



From jakob at kirei.se  Sat Nov 24 21:06:40 2012
From: jakob at kirei.se (Jakob Schlyter)
Date: Sat, 24 Nov 2012 22:06:40 +0100
Subject: [Opendnssec-develop] Release SoftHSM 1.3.4
In-Reply-To: <368A0984-A7D5-4D26-8338-EA351C08AF64@sinodun.com>
References: <CAKFiofnOx_n35TGG5e84XNvvXcirQQM6s920e_sL-fJbSn+xmg@mail.gmail.com>
	<368A0984-A7D5-4D26-8338-EA351C08AF64@sinodun.com>
Message-ID: <2B00A523-21CB-4CF0-AB8D-F94A4792EB70@kirei.se>

On 21 nov 2012, at 14:16, Sara Dickinson <sara at sinodun.com> wrote:

> Thanks for the mail. Jerry is on vacation at the moment and Jakob is quite busy with the latest training course so we'll get to this as soon as we can!

Done.

	jakob



From sara at sinodun.com  Mon Nov 26 09:01:30 2012
From: sara at sinodun.com (Sara Dickinson)
Date: Mon, 26 Nov 2012 09:01:30 +0000
Subject: [Opendnssec-develop] RE: Team Meeting - Tuesday 27th Nov @ 14.00 CET
References: <E4CCDC44-AF62-4269-9CC3-4DD9684E812F@sinodun.com>
Message-ID: <E30A2A73-3F25-441F-A62A-0764C00A2CD6@sinodun.com>

Hi All, 

We have a scheduled team meeting tomorrow:

Date:      Tuesday 27 November 2012
Time:      14:00-15:00 CET, 13:00-14:00 GMT
Method:  Google+
Agenda:  https://wiki.opendnssec.org/display/OpenDNSSEC/2012-11-27+agenda

Sara.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opendnssec.org/pipermail/opendnssec-develop/attachments/20121126/417a70b8/attachment.htm>

From sara at sinodun.com  Mon Nov 26 11:46:09 2012
From: sara at sinodun.com (Sara Dickinson)
Date: Mon, 26 Nov 2012 11:46:09 +0000
Subject: [Opendnssec-develop] RE: Versioning and version support
Message-ID: <2F5E77E6-B22F-4D38-A95A-6E18200F0CB7@sinodun.com>

All, 

Following some recent discussions on version support and how we use version numbers I have put this email together to try to summarise some of the points raised. 


Version numbering
----------------------------

We currently use a version numbering system based on the following (and direction from the board about what functionality they would like to see in what release): 

Releases are numbered using the following scheme: <name>-<major>.<minor>.<patch>

	? <name> - The name of the software, e.g. opendnssec or softhsm.
	? <major> - Indicate changes in the overall system design.
	? <minor> - Indicate changes in the components.
	? <patch> - Indicate bug fixes.

As a result we often include fixes in 'patch' releases that include extensions (and sometimes changes) to the command utilities and/or log output. This is quite different from the version numbering system used by some other applications which choose to follow an API compatibility based approach e.g. http://semver.org/

Question) Do we as a development team think we should move to an API compatibility based approach for version numbering? 

* We would have to consider what we would define as our 'API (the scheme above assumes that there is a clear, well documented API)'. Command line utilities/database schema/logs/zone content/etc. (This may make much more sense once we have a formal API in future so perhaps we should consider this from 2.x onwards?).
* This would increase the frequency at which our minor and major versions changed (I think)
* We would have to review how we write the roadmap and refer to future releases since version numbers would not be guaranteed (e.g. we could use names not numbers to label releases with specific content).
* If we decide to recommend this then we should run it past the board (and users) before adopting the new process.
* Alternatively we could retain our current scheme but clarify in the process wiki that <patch> releases contain minor updates and bug fixes (we already do this in the NEWS file).



Version support
------------------------
[The following probably depends on what we plan to do with version numbering so it is here for reference at the moment]

In practice we support only the current minor version.  Should we support the current and previous minor version from 1.4 onwards?

+ better support for users who stay on 1.3
- more overhead (more branches to patch, test and release)
- less incentive for users to upgrade to 1.4

We also used to say the following on the wiki "The oldest supported release will get deprecated 6 months after a new release has been introduced e.g. v1.4 will deprecate v1.1. However a released version will be maintained at a minimum of 12 months."




Comments welcomed!

Sara.

From sion at nominet.org.uk  Mon Nov 26 13:35:58 2012
From: sion at nominet.org.uk (=?windows-1252?Q?Si=F4n_Lloyd?=)
Date: Mon, 26 Nov 2012 13:35:58 +0000
Subject: [Opendnssec-develop] RE: Versioning and version support
In-Reply-To: <2F5E77E6-B22F-4D38-A95A-6E18200F0CB7@sinodun.com>
References: <2F5E77E6-B22F-4D38-A95A-6E18200F0CB7@sinodun.com>
Message-ID: <50B3703E.6040902@nominet.org.uk>

I think that this would be good, note however the text for major version
number says "Major version X (X.y.z | X > 0) MUST be incremented if any
backwards incompatible changes are introduced to the public API."

So that doesn't preclude enforcer-ng being 2.0 even if the API didn't
change at all if I read it correctly? It also means new functionality
doesn't have to bump the major version.

Sion

On 26/11/12 11:46, Sara Dickinson wrote:
> All, 
>
> Following some recent discussions on version support and how we use version numbers I have put this email together to try to summarise some of the points raised. 
>
>
> Version numbering
> ----------------------------
>
> We currently use a version numbering system based on the following (and direction from the board about what functionality they would like to see in what release): 
>
> Releases are numbered using the following scheme: <name>-<major>.<minor>.<patch>
>
> 	? <name> - The name of the software, e.g. opendnssec or softhsm.
> 	? <major> - Indicate changes in the overall system design.
> 	? <minor> - Indicate changes in the components.
> 	? <patch> - Indicate bug fixes.
>
> As a result we often include fixes in 'patch' releases that include extensions (and sometimes changes) to the command utilities and/or log output. This is quite different from the version numbering system used by some other applications which choose to follow an API compatibility based approach e.g. http://semver.org/
>
> Question) Do we as a development team think we should move to an API compatibility based approach for version numbering? 
>
> * We would have to consider what we would define as our 'API (the scheme above assumes that there is a clear, well documented API)'. Command line utilities/database schema/logs/zone content/etc. (This may make much more sense once we have a formal API in future so perhaps we should consider this from 2.x onwards?).
> * This would increase the frequency at which our minor and major versions changed (I think)
> * We would have to review how we write the roadmap and refer to future releases since version numbers would not be guaranteed (e.g. we could use names not numbers to label releases with specific content).
> * If we decide to recommend this then we should run it past the board (and users) before adopting the new process.
> * Alternatively we could retain our current scheme but clarify in the process wiki that <patch> releases contain minor updates and bug fixes (we already do this in the NEWS file).
>
>
>
> Version support
> ------------------------
> [The following probably depends on what we plan to do with version numbering so it is here for reference at the moment]
>
> In practice we support only the current minor version.  Should we support the current and previous minor version from 1.4 onwards?
>
> + better support for users who stay on 1.3
> - more overhead (more branches to patch, test and release)
> - less incentive for users to upgrade to 1.4
>
> We also used to say the following on the wiki "The oldest supported release will get deprecated 6 months after a new release has been introduced e.g. v1.4 will deprecate v1.1. However a released version will be maintained at a minimum of 12 months."
>
>
>
>
> Comments welcomed!
>
> Sara._______________________________________________
> Opendnssec-develop mailing list
> Opendnssec-develop at lists.opendnssec.org
> https://lists.opendnssec.org/mailman/listinfo/opendnssec-develop



From sara at sinodun.com  Mon Nov 26 14:02:31 2012
From: sara at sinodun.com (Sara Dickinson)
Date: Mon, 26 Nov 2012 14:02:31 +0000
Subject: [Opendnssec-develop] RE: 1.3.12 release candidate
Message-ID: <F168587B-17DC-4962-BA43-036F349B9685@sinodun.com>

All, 

This is to make you aware that two build issues relating to ldns have been found with 1.3.11 and as a result we are making a 1.3.12 release candidate available this week (details below). We plan a full release next week (assuming no further issues are found). 


OpenDNSSEC 1.3.12rc
------------------------------------

Version 1.3.12rc of OpenDNSSEC is now available. This is a release candidate for testing purposes.


* SUPPORT-42: ./configure fails on FreeBSD (or if ldns is not installed in a 
  directory in the default search path of the complier).
* OpenDNSSEC does not compile against ldns 1.6.16 on platforms that rely on
  the OpenDNSSEC implementation of strlcpy/cat 

Download the tarball from: 
http://dist.opendnssec.org/source/testing/opendnssec-1.3.12rc1.tar.gz

Sara.




From sara at sinodun.com  Mon Nov 26 14:05:34 2012
From: sara at sinodun.com (Sara Dickinson)
Date: Mon, 26 Nov 2012 14:05:34 +0000
Subject: Fwd: [Opendnssec-develop] RE: 1.3.12 release candidate
References: <F168587B-17DC-4962-BA43-036F349B9685@sinodun.com>
Message-ID: <624F002A-AC0C-4D9A-BF4B-F3EB03F92DE5@sinodun.com>

All, 

Since we have a release candidate issued please refrain from submitting routine code into the 1.3.12 branch until the full release is done. If you have a high priority issue that you believe warrants the re-issue of the release candidate please email the developers list first so this can be agreed.

Sara.

Begin forwarded message:

> From: Sara Dickinson <sara at sinodun.com>
> Date: 26 November 2012 14:02:31 GMT
> To: opendnssec-maintainers at lists.opendnssec.org
> Cc: "opendnssec-develop at lists.opendnssec.org Dev" <Opendnssec-develop at lists.opendnssec.org>
> Subject: [Opendnssec-develop] RE: 1.3.12 release candidate
> 
> All, 
> 
> This is to make you aware that two build issues relating to ldns have been found with 1.3.11 and as a result we are making a 1.3.12 release candidate available this week (details below). We plan a full release next week (assuming no further issues are found). 
> 
> 
> OpenDNSSEC 1.3.12rc
> ------------------------------------
> 
> Version 1.3.12rc of OpenDNSSEC is now available. This is a release candidate for testing purposes.
> 
> 
> * SUPPORT-42: ./configure fails on FreeBSD (or if ldns is not installed in a 
>  directory in the default search path of the complier).
> * OpenDNSSEC does not compile against ldns 1.6.16 on platforms that rely on
>  the OpenDNSSEC implementation of strlcpy/cat 
> 
> Download the tarball from: 
> http://dist.opendnssec.org/source/testing/opendnssec-1.3.12rc1.tar.gz
> 
> Sara.
> 
> 
> _______________________________________________
> Opendnssec-develop mailing list
> Opendnssec-develop at lists.opendnssec.org
> https://lists.opendnssec.org/mailman/listinfo/opendnssec-develop



From sara at sinodun.com  Mon Nov 26 15:03:12 2012
From: sara at sinodun.com (Sara Dickinson)
Date: Mon, 26 Nov 2012 15:03:12 +0000
Subject: [Opendnssec-develop] RE: Regression testing update
Message-ID: <C55D5AA3-B7D1-4C44-8075-71B288A725DB@sinodun.com>

Hi All, 

So I have been having another look lately at the regression tests and how we could manage them better as we add more tests. (They are currently a mixture of imported scripts with a numeric naming convention and new tests added by us.) My plan is to do the following things:

- come up with a new naming convention for the test scripts
- come up with a way to track what is currently tested (including bug fixes)
- review which tests should be smoke/daily/weekly
- re-vamp the Test Coverage wiki page to more clearly see what tests still need adding

I've had a go at the first two so am looking for some feedback before moving any further.... More details on both the following suggestions are on the wiki page: https://wiki.opendnssec.org/display/OpenDNSSEC/Test+case+policy

Naming
-------------
My idea for naming is to split the names into 3 parts (based on the area tested - see the wiki). These parts would be separated by dashes, with word separated by underscores within the 3 parts. So for example we might have:

enforcer-keys-check_backup_required_works
signer-adaptors-many_dns_updates
general-repository-opendnssecXXX

I thought this was easier than using than a numbering system and since we currently run all the tests regardless of any failures then the ordering within the directory doesn't really matter (at the moment anyway). We could alternatively use a directory structure along these lines but I'm not convinced that having to always drill down further to the test scripts ultimately makes life easier...? Please let me know if you can think of improvements or alternatives to this. 

Tracking
-------------
On the tracking side of things I took the approach that the most reliable way to track things is to have a way to grab information directly from the tests rather than try to have a separate document that needs updating and so is likely to get out of date. I have written a small script that grabs info from the comments in the test scripts and generates a CSV file as output. It needs more work and really should be incorporated into the framework if we decide to adopt this approach - at the moment it is just to generate feedback. An example excel spreadsheet generated from the information extracted (including new suggested names for the existing tests) is attached to the wiki page for people to review. 

This does rely on the comments in the tests being accurate and up to date but that seems a good idea anyway!  Please try this out and let me know if you think this approach makes sense. 

Sara.



From Roland.vanRijswijk at surfnet.nl  Tue Nov 27 08:54:16 2012
From: Roland.vanRijswijk at surfnet.nl (Roland van Rijswijk - Deij)
Date: Tue, 27 Nov 2012 09:54:16 +0100
Subject: [Opendnssec-develop] Network problems affecting JIRA & Confluence
	Wiki
Message-ID: <50B47FB8.6010307@surfnet.nl>

Hi all,

SURFnet's NOC has been working on upgrading our core network routers.
Unfortunately, they are experiencing serious issues, meaning the upgrade
will have to be rolled back. I have seen some Nagios warnings from the
OpenDNSSEC JIRA & Confluence instances this morning; you may experience
intermittent failures when accessing these systems. We expect the
rollback to be complete before the end of the day.

My apologies for the inconvenience.

Cheers,

Roland

-- 
-- Roland M. van Rijswijk - Deij
-- SURFnet bv
-- w: http://www.surfnet.nl/en/
-- t: +31-30-2305388
-- e: roland.vanrijswijk at surfnet.nl


From sara at sinodun.com  Tue Nov 27 12:03:38 2012
From: sara at sinodun.com (Sara Dickinson)
Date: Tue, 27 Nov 2012 12:03:38 +0000
Subject: [Opendnssec-develop] Team meeting today
Message-ID: <FF28E117-B9DB-41B5-A3F7-0A9B40CAE129@sinodun.com>

All,

Sorry for the late notice but i am sick today and so wont make the meeting. I will reschedule for later this week asap. 

Sara. 

Sent from my iPhone

From sara at sinodun.com  Thu Nov 29 10:34:01 2012
From: sara at sinodun.com (Sara (Sinodun))
Date: Thu, 29 Nov 2012 10:34:01 +0000
Subject: [Opendnssec-develop] Re: Team meeting today
In-Reply-To: <FF28E117-B9DB-41B5-A3F7-0A9B40CAE129@sinodun.com>
References: <FF28E117-B9DB-41B5-A3F7-0A9B40CAE129@sinodun.com>
Message-ID: <0A4B297B-DCD3-4324-A9CA-83C350B5DC5F@sinodun.com>

Hi All, 

Thanks for the get well wishes - unfortunately I am still sick today. If you feel the need please schedule a meeting this week without me otherwise I suggest we meet Monday 3rd  at 14:00 CET if everyone can make that (alternative date Tuesday 4th at same time).

Sara.


On 27 Nov 2012, at 12:03, Sara Dickinson wrote:

> All,
> 
> Sorry for the late notice but i am sick today and so wont make the meeting. I will reschedule for later this week asap. 
> 
> Sara. 
> 
> Sent from my iPhone




From sion at nominet.org.uk  Thu Nov 29 10:47:55 2012
From: sion at nominet.org.uk (=?ISO-8859-1?Q?Si=F4n_Lloyd?=)
Date: Thu, 29 Nov 2012 10:47:55 +0000
Subject: [Opendnssec-develop] Re: Team meeting today
In-Reply-To: <0A4B297B-DCD3-4324-A9CA-83C350B5DC5F@sinodun.com>
References: <FF28E117-B9DB-41B5-A3F7-0A9B40CAE129@sinodun.com>
	<0A4B297B-DCD3-4324-A9CA-83C350B5DC5F@sinodun.com>
Message-ID: <50B73D5B.7010209@nominet.org.uk>

On 29/11/12 10:34, Sara (Sinodun) wrote:
> Hi All, 
>
> Thanks for the get well wishes - unfortunately I am still sick today. If you feel the need please schedule a meeting this week without me otherwise I suggest we meet Monday 3rd  at 14:00 CET if everyone can make that (alternative date Tuesday 4th at same time).
>
> Sara.

I don't think that there is anything so urgent it can't wait.

Monday or Tuesday works for me... Although with any luck you'll miss out
on my comedy Barry White voice which I've had all week.

Sion

>
> On 27 Nov 2012, at 12:03, Sara Dickinson wrote:
>
>> All,
>>
>> Sorry for the late notice but i am sick today and so wont make the meeting. I will reschedule for later this week asap. 
>>
>> Sara. 
>>
>> Sent from my iPhone
>
> _______________________________________________
> Opendnssec-develop mailing list
> Opendnssec-develop at lists.opendnssec.org
> https://lists.opendnssec.org/mailman/listinfo/opendnssec-develop



From matthijs at nlnetlabs.nl  Thu Nov 29 12:57:48 2012
From: matthijs at nlnetlabs.nl (Matthijs Mekking)
Date: Thu, 29 Nov 2012 13:57:48 +0100
Subject: [Opendnssec-develop] Re: Team meeting today
In-Reply-To: <0A4B297B-DCD3-4324-A9CA-83C350B5DC5F@sinodun.com>
References: <FF28E117-B9DB-41B5-A3F7-0A9B40CAE129@sinodun.com>
	<0A4B297B-DCD3-4324-A9CA-83C350B5DC5F@sinodun.com>
Message-ID: <507a4f95-4e6c-49b9-a6fa-ed00a5997d12@email.android.com>

I wont be able to do 4 dec

"Sara (Sinodun)" <sara at sinodun.com> schreef:

>Hi All, 
>
>Thanks for the get well wishes - unfortunately I am still sick today.
>If you feel the need please schedule a meeting this week without me
>otherwise I suggest we meet Monday 3rd  at 14:00 CET if everyone can
>make that (alternative date Tuesday 4th at same time).
>
>Sara.
>
>
>On 27 Nov 2012, at 12:03, Sara Dickinson wrote:
>
>> All,
>> 
>> Sorry for the late notice but i am sick today and so wont make the
>meeting. I will reschedule for later this week asap. 
>> 
>> Sara. 
>> 
>> Sent from my iPhone
>
>
>_______________________________________________
>Opendnssec-develop mailing list
>Opendnssec-develop at lists.opendnssec.org
>https://lists.opendnssec.org/mailman/listinfo/opendnssec-develop

-- 
Verzonden van mijn Android telefoon met K-9 Mail.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opendnssec.org/pipermail/opendnssec-develop/attachments/20121129/b1b652f8/attachment.htm>

From nick.vandenheuvel at sidn.nl  Thu Nov 29 14:06:48 2012
From: nick.vandenheuvel at sidn.nl (Nick van den Heuvel)
Date: Thu, 29 Nov 2012 14:06:48 +0000
Subject: [Opendnssec-develop] Re: Team meeting today
In-Reply-To: <507a4f95-4e6c-49b9-a6fa-ed00a5997d12@email.android.com>
References: <FF28E117-B9DB-41B5-A3F7-0A9B40CAE129@sinodun.com>
	<0A4B297B-DCD3-4324-A9CA-83C350B5DC5F@sinodun.com>
	<507a4f95-4e6c-49b9-a6fa-ed00a5997d12@email.android.com>
Message-ID: <8379DE00FDBE1B4F95522D088EC260DD1FBF4724@kambx2.SIDN.local>

Me neither

Van: opendnssec-develop-bounces at lists.opendnssec.org [mailto:opendnssec-develop-bounces at lists.opendnssec.org] Namens Matthijs Mekking
Verzonden: donderdag 29 november 2012 13:58
Aan: Sara (Sinodun); Opd Dev
Onderwerp: Re: [Opendnssec-develop] Re: Team meeting today

I wont be able to do 4 dec
"Sara (Sinodun)" <sara at sinodun.com<mailto:sara at sinodun.com>> schreef:

Hi All,

Thanks for the get well wishes - unfortunately I am still sick today. If you feel the need please schedule a meeting this week without me otherwise I suggest we meet Monday 3rd  at 14:00 CET if everyone can make that (alternative date Tuesday 4th at same time).

Sara.


On 27 Nov 2012, at 12:03, Sara Dickinson wrote:

All,

Sorry for the late notice but i am sick today and so wont make the meeting. I will reschedule for later this week asap.

Sara.

Sent from my iPhone



________________________________

Opendnssec-develop mailing list
Opendnssec-develop at lists.opendnssec.org<mailto:Opendnssec-develop at lists.opendnssec.org>
https://lists.opendnssec.org/mailman/listinfo/opendnssec-develop

--
Verzonden van mijn Android telefoon met K-9 Mail.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opendnssec.org/pipermail/opendnssec-develop/attachments/20121129/006bfc90/attachment.htm>

From yuri at nlnetlabs.nl  Fri Nov 30 08:42:21 2012
From: yuri at nlnetlabs.nl (Yuri Schaeffer)
Date: Fri, 30 Nov 2012 09:42:21 +0100
Subject: [Opendnssec-develop] Re: Team meeting today
In-Reply-To: <0A4B297B-DCD3-4324-A9CA-83C350B5DC5F@sinodun.com>
References: <FF28E117-B9DB-41B5-A3F7-0A9B40CAE129@sinodun.com>
	<0A4B297B-DCD3-4324-A9CA-83C350B5DC5F@sinodun.com>
Message-ID: <50B8716D.9000104@nlnetlabs.nl>

> I suggest we meet Monday 3rd  at 14:00 CET if everyone can
> make that (alternative date Tuesday 4th at same time).

Monday and Tuesday are fine.


From jad at sinodun.com  Fri Nov 30 12:51:23 2012
From: jad at sinodun.com (John Dickinson)
Date: Fri, 30 Nov 2012 12:51:23 +0000
Subject: [Opendnssec-develop] jenkins down
Message-ID: <10D7A46D-D177-41C5-99C5-2929110EDBF8@sinodun.com>

Hi,

The jenkins server is down due to a power outage on parts of the business park we are on. 

I already have plans in the works to move it to a different link but I hope the power will be restored sooner than it will take me to implement those plans. If the outage persists I will move it at the weekend so that it is available on Monday.

Sorry about this. Let me know if you need urgent access and I will try to move it today.

John


---
jad at sinodun.com

http://sinodun.com

Sinodun Internet Technologies Ltd.
Stables 4, Suite 11,
Howbery Park,
Wallingford,
Oxfordshire,
OX10 8BA,
U.K.

+44 (0)1491 834957