On 03/12/2014 04:28 PM, Petr Spacek wrote:
On 12.3.2014 14:07, Ludwig Krispenz wrote:
On 03/12/2014 01:09 PM, Petr Spacek wrote:
On 12.3.2014 12:12, Ludwig Krispenz wrote:
On 03/11/2014 11:33 AM, Petr Spacek wrote:
On 10.3.2014 12:08, Martin Kosek wrote:
On 03/10/2014 11:49 AM, Petr Spacek
On 12.3.2014 14:07, Ludwig Krispenz wrote:
On 03/12/2014 01:09 PM, Petr Spacek wrote:
On 12.3.2014 12:12, Ludwig Krispenz wrote:
On 03/11/2014 11:33 AM, Petr Spacek wrote:
On 10.3.2014 12:08, Martin Kosek wrote:
On 03/10/2014 11:49 AM, Petr Spacek wrote:
On 7.3.2014 17:33, Dmitri Pal wrote:
On 03/12/2014 01:09 PM, Petr Spacek wrote:
On 12.3.2014 12:12, Ludwig Krispenz wrote:
On 03/11/2014 11:33 AM, Petr Spacek wrote:
On 10.3.2014 12:08, Martin Kosek wrote:
On 03/10/2014 11:49 AM, Petr Spacek wrote:
On 7.3.2014 17:33, Dmitri Pal wrote:
I do not think it is the right architectura
On 12.3.2014 12:12, Ludwig Krispenz wrote:
On 03/11/2014 11:33 AM, Petr Spacek wrote:
On 10.3.2014 12:08, Martin Kosek wrote:
On 03/10/2014 11:49 AM, Petr Spacek wrote:
On 7.3.2014 17:33, Dmitri Pal wrote:
I do not think it is the right architectural approach to try to fix a
specific
use case
On 03/11/2014 11:33 AM, Petr Spacek wrote:
On 10.3.2014 12:08, Martin Kosek wrote:
On 03/10/2014 11:49 AM, Petr Spacek wrote:
On 7.3.2014 17:33, Dmitri Pal wrote:
I do not think it is the right architectural approach to try to fix
a specific
use case with one off solution while we already kno
On 11.3.2014 21:19, Martin Kosek wrote:
On 03/11/2014 07:40 PM, Simo Sorce wrote:
On Tue, 2014-03-11 at 11:33 +0100, Petr Spacek wrote:
Yesterday we have agreed that DNSSEC support is not going to depend on Vault
...
- walk through cn=masters,cn=ipa,cn=etc,dc=ipa,dc=example and check if there
On 03/11/2014 07:40 PM, Simo Sorce wrote:
On Tue, 2014-03-11 at 11:33 +0100, Petr Spacek wrote:
Yesterday we have agreed that DNSSEC support is not going to depend on Vault
...
- walk through cn=masters,cn=ipa,cn=etc,dc=ipa,dc=example and check if there
are any other replicas with DNSSECKeyImp
On Tue, 2014-03-11 at 14:40 -0400, Simo Sorce wrote:
> The *only* thing we really need to do IMO is that if a DNS server
> finds
> out it's key for a zone are expired then it shuts down itself and
> makes
> itself unavailable so clients will start falling over to another DNS
> server and the admin
On Tue, 2014-03-11 at 11:33 +0100, Petr Spacek wrote:
> Yesterday we have agreed that DNSSEC support is not going to depend on Vault
> from the beginning and that we can migrate to Vault later.
>
> Here I'm proposing safe upgrade path from non-vault to Vault solution.
>
> After all, it seems rel
On 03/11/2014 07:53 AM, Petr Spacek wrote:
On 11.3.2014 12:21, Martin Kosek wrote:
On 03/11/2014 11:33 AM, Petr Spacek wrote:
On 10.3.2014 12:08, Martin Kosek wrote:
On 03/10/2014 11:49 AM, Petr Spacek wrote:
On 7.3.2014 17:33, Dmitri Pal wrote:
I do not think it is the right architectural ap
On 11.3.2014 12:21, Martin Kosek wrote:
On 03/11/2014 11:33 AM, Petr Spacek wrote:
On 10.3.2014 12:08, Martin Kosek wrote:
On 03/10/2014 11:49 AM, Petr Spacek wrote:
On 7.3.2014 17:33, Dmitri Pal wrote:
I do not think it is the right architectural approach to try to fix a specific
use case wi
On 03/11/2014 11:33 AM, Petr Spacek wrote:
> On 10.3.2014 12:08, Martin Kosek wrote:
>> On 03/10/2014 11:49 AM, Petr Spacek wrote:
>>> On 7.3.2014 17:33, Dmitri Pal wrote:
I do not think it is the right architectural approach to try to fix a
specific
use case with one off solution w
On 10.3.2014 12:08, Martin Kosek wrote:
On 03/10/2014 11:49 AM, Petr Spacek wrote:
On 7.3.2014 17:33, Dmitri Pal wrote:
I do not think it is the right architectural approach to try to fix a specific
use case with one off solution while we already know that we need a key storage.
I would rather
13 matches
Mail list logo
