5 Lis
2018
5 Lis
'18
14:17
Hi,
I'm trying to spin a nice transaction model around libknot, intended for
better automation, as attached. I'm running into problems.
First and foremost, a lack of understanding what should go into what
fields when doing other commands than in the "stats" demos. Are there
more advanced explanations of what goes into what fields? I tried
looking into knotc, but it is rather long. Perhaps there is a log
somewhere with the stuff going into knotd?
Secondly, the model by which transactions abort is not always logical.
Like a commit() that fails but does not turn into an abort() when
semantic errors are found. I will run zone-check beforehand, to ensure
that this does not happen.
Thirdly, I found that the library freezes when supplied with unknown
commands or apparently funny data...
>> import knotcontrol
>> kc = knotcontrol.KnotControl()
>> kc = knotcontrol.KnotControl ()
>> kc.knot (cmd='stats')
KnotControl send {'cmd':
'stats'}
KnotControl recv {'server': {'zone-count': ['1']}}
{'server': {'zone-count': ['1']}}
>> kc.knot
(cmd='zone-stats',item='vanrein.org')
KnotControl send
{'item': 'vanrein.org', 'cmd': 'zone-stats'}
KnotControl recv {}
{}
>> kc.knot
(cmd='zone-recv',item='vanrein.org')
KnotControl send
{'item': 'vanrein.org', 'cmd': 'zone-recv'}
...and at this point it freezes, even to ^C -- before and after this
sequence, "kdig @localhost vanrein.org soa" worked to query the zone in
Knot DNS.
Sorry to be testing this early :-S but I'm eager to use it this way.
-Rick
5 Lis
5 Lis
15:49
Rick,
On 2018-11-05 14:17, Rick van Rein wrote:
I expect this is rather unusual situation depending on the sanity of
input parameters.ss
Hi,
I'm trying to spin a nice transaction model around libknot, intended
for
better automation, as attached. I'm running into problems.
First and foremost, a lack of understanding what should go into what
fields when doing other commands than in the "stats" demos. Are there
more advanced explanations of what goes into what fields? I tried
looking into knotc, but it is rather long. Perhaps there is a log
somewhere with the stuff going into knotd?
Unfortunately, there is no documentation for that yet. The statistics
part is the most complicated command and has an extra function
`receive_stats`
(see python/stats_http.py).
Secondly, the model by which transactions abort is not
always logical.
Like a commit() that fails but does not turn into an abort() when
semantic errors are found. I will run zone-check beforehand, to ensure
that this does not happen.
The idea of failed commit, which doesn't abort automatically, is that
you have a chance to fix the error. For manual changes it's very
convenient :-)
Zone-check checks a zone file only! So it doesn't check dynamic zone
contents.
Maybe I don't understand the non logical model?
Thirdly, I found that the library freezes when supplied with unknown
commands or apparently funny data...
It's possible. If the input is seriously malformed, the server doesn't
respond. Why would you call an unsupported command?
>> import
knotcontrol
>> kc = knotcontrol.KnotControl()
>> kc = knotcontrol.KnotControl ()
>> kc.knot (cmd='stats')
KnotControl send {'cmd':
'stats'}
KnotControl recv {'server': {'zone-count': ['1']}}
{'server': {'zone-count': ['1']}}
>> kc.knot
(cmd='zone-stats',item='vanrein.org')
KnotControl send
{'item': 'vanrein.org', 'cmd': 'zone-stats'}
KnotControl recv {}
{}
>> kc.knot
(cmd='zone-recv',item='vanrein.org')
KnotControl send
{'item': 'vanrein.org', 'cmd': 'zone-recv'}
...and at this point it freezes, even to ^C -- before and after this
sequence, "kdig @localhost vanrein.org soa" worked to query the zone in
Knot DNS.
Sorry to be testing this early :-S but I'm eager to use it this way.
Daniel
-Rick
16:06
On 2018-11-05 15:49, daniel.salzman(a)nic.cz wrote:
Rick,
On 2018-11-05 14:17, Rick van Rein wrote:
I have realized that it's true just for conf-commit. In the case of
failed zone-commit,
the transaction is aborted.
Hi,
I'm trying to spin a nice transaction model around libknot, intended
for
better automation, as attached. I'm running into problems.
First and foremost, a lack of understanding what should go into what
fields when doing other commands than in the "stats" demos. Are there
more advanced explanations of what goes into what fields? I tried
looking into knotc, but it is rather long. Perhaps there is a log
somewhere with the stuff going into knotd?
Unfortunately, there is no documentation for that yet. The statistics
part is the most complicated command and has an extra function
`receive_stats`
(see python/stats_http.py).
Secondly, the model by which transactions abort
is not always logical.
Like a commit() that fails but does not turn into an abort() when
semantic errors are found. I will run zone-check beforehand, to
ensure
that this does not happen.
The idea of failed commit, which doesn't abort automatically, is that
you have a chance to fix the error. For manual changes it's very
convenient :-) Zone-check checks a zone file only! So it doesn't
check dynamic zone
contents.
Maybe I don't understand the non logical model?
I expect this is rather unusual situation depending on the sanity of
input parameters.ss
Thirdly, I found that the library freezes when supplied with unknown
commands or apparently funny data...
It's possible. If the input is seriously malformed, the server doesn't
respond. Why would you call an unsupported command?
>>
import knotcontrol
>> kc = knotcontrol.KnotControl()
>> kc = knotcontrol.KnotControl ()
>> kc.knot (cmd='stats')
KnotControl send {'cmd':
'stats'}
KnotControl recv {'server': {'zone-count': ['1']}}
{'server': {'zone-count': ['1']}}
>> kc.knot
(cmd='zone-stats',item='vanrein.org')
KnotControl send
{'item': 'vanrein.org', 'cmd': 'zone-stats'}
KnotControl recv {}
{}
>> kc.knot
(cmd='zone-recv',item='vanrein.org')
KnotControl send
{'item': 'vanrein.org', 'cmd': 'zone-recv'}
...and at this point it freezes, even to ^C -- before and after this
sequence, "kdig @localhost vanrein.org soa" worked to query the zone
in
Knot DNS.
Sorry to be testing this early :-S but I'm eager to use it this way.
Daniel
>
> -Rick
2155
days inactive
2155
days old
2 comments
2 participants
participants (2)
-
daniel.salzman＠nic.cz -
Rick van Rein