[Opendnssec-user] Date of next transition: now
Berry A.W. van Halderen
berry at nlnetlabs.nl
Mon Jan 22 13:44:23 UTC 2018
On 01/22/2018 02:39 PM, Gerhard Schmidt wrote:
> Am 08.01.2018 um 15:57 schrieb Gerhard Schmidt:
>> Am 08.01.2018 um 15:48 schrieb Yuri Schaeffer:
>>>> All worker threads idle.
>>>> There is 1 task scheduled.
>>>> It is now Mon Jan 8 14:01:54 2018 (1515416514 seconds since epoch)
>>>> Next task scheduled Wed Mar 28 15:49:26 2018 (1522244966 seconds since
>>>> epoch)
>>>> On Wed Mar 28 15:49:26 2018 I will resalt zone default
>>>
>>> At this point I do not know how this have happened but the problem is
>>> clear. The enforce tasks for the zones are no longer scheduled. I
>>> believe you can do 'ods-enforcer enforce --all' to get them back in the
>>> queue. Alternatively restarting ods-enforcerd will work as well.
>>>
>>> In normal operation this will only happen when the enforcer concludes no
>>> more (automated) work needs to be done for a zone -ever-. This means
>>> zones are only re-evaluated on user input. This should only be possible
>>> if you configured manual rollover for both KSK and ZSK. In that case the
>>> timestamp thing is a fluke (which we need to address). Can that be the case?
>>>
>>> //Yuri
>>>
>>
>> after restart i got this from eds-enforcer queue.
>>
>> All worker threads idle.
>> There are 15 tasks scheduled.
>> It is now Mon Jan 8 14:31:58 2018 (1515418318 seconds since epoch)
>> Next task scheduled Mon Jan 22 14:13:19 2018 (1516626799 seconds since
>> epoch)
>> On Mon Jan 22 14:13:19 2018 I will enforce zone augusta.de
>> On Wed Mar 28 15:49:26 2018 I will resalt zone default
>>
>> ods-enforcer key list reports now
>>
>> Keys:
>> Zone: Keytype: State: Date of next transition:
>> augusta.de KSK active 2018-01-22 14:13:19
>> augusta.de ZSK retire 2018-01-22 14:13:19
>> augusta.de ZSK active 2018-01-22 14:13:19
>>
>> but after that time there will be now again. Done this twice sine end
>> november 2017.
>>
>> they all user default profile with
>>
>> <KSK>
>> <Algorithm length="4096">10</Algorithm>
>> <Lifetime>P5Y</Lifetime>
>> <Repository>SoftHSM</Repository>
>> </KSK>
>>
>> <ZSK>
>> <Algorithm length="1024">10</Algorithm>
>> <Lifetime>P90D</Lifetime>
>> <Repository>SoftHSM</Repository>
>> </ZSK>
>
> HI again,
>
> i pinpointed the problem in the logs.
>
> Jan 22 14:13:19 inga ods-enforcerd: DB prepare SQL SELECT zone.id,
> zone.rev, zone.policyId, zone.name, zone.signconfNeedsWriting,
> zone.signconfPath, zone.nextChange, zone.ttlEndDs, zone.ttlEndDk,
> zone.ttlEndRs, zone.rollKskNow, zone.rollZskNow, zone.rollCskNow,
> zone.inputAdapterType, zone.inputAdapterUri, zone.outputAdapterType,
> zone.outputAdapterUri, zone.nextKskRoll, zone.nextZskRoll,
> zone.nextCskRoll FROM zone WHERE zone.name = ?
> Jan 22 14:13:19 inga ods-enforcerd: DB prepare Err 2006: MySQL server
> has gone away
> Jan 22 14:13:19 inga ods-enforcerd: [enforce_task] Could not find zone
> augusta.de in database
> Jan 22 14:13:19 inga kernel: Jan 22 14:13:19 inga ods-enforcerd:
> [enforce_task] Could not find zone augusta.de in database
>
> MySQL doesn't keep the connection living for week. After 28800 seconds
> of inactivity the connection is closed. So OpenDNSSec should close the
> connection an reopen in before it's needed or do a query at least every
> 28800 seconds or retry the select with a new connection if the open one
> failed.
Great, if that is indeed the problem, and I find it very believable.
The normal way would be to perform a query every once in a while to keep
the connection alive, but we might need to consider to perform such a
query before a enforce task runs because of the current set-up.
Thank you very much for sifting through the logs.
\Berry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://lists.opendnssec.org/pipermail/opendnssec-user/attachments/20180122/db27aeec/attachment.bin>
More information about the Opendnssec-user
mailing list