Control: tags 912210 + confirmed
Control: found 912210 2.7.2-2~bpo9+1
Control: found 912210 2.7.3-1

On Mon 2018-10-29 10:35:10 +0000, Peter Palfrader wrote:
> | Configuration file '/etc/knot/knot.conf'
> |  ==> Modified (by you or by a script) since installation.
> |  ==> Package distributor has shipped an updated version.
> |    What would you like to do about it ?  Your options are:
> |     Y or I  : install the package maintainer's version
> |     N or O  : keep your currently-installed version
> |       D     : show the differences between the versions
> |       Z     : start a shell to examine the situation
> |  The default action is to keep your current version.
> | *** knot.conf (Y/I/N/O/D/Z) [default=N] ? y
> | Installing new version of config file /etc/knot/knot.conf ...
> | Traceback (most recent call last):
> |   File "/usr/lib/knot/get_kaspdb", line 9, in <module>
> |     conf = yaml.load(open(conf_file, 'r'))
> |   File "/usr/lib/python3/dist-packages/yaml/__init__.py", line 72, in load
> |     return loader.get_single_data()
> |   File "/usr/lib/python3/dist-packages/yaml/constructor.py", line 35, in 
> get_single_data
> |     node = self.get_single_node()
> |   File "/usr/lib/python3/dist-packages/yaml/composer.py", line 36, in 
> get_single_node
> |     document = self.compose_document()
> |   File "/usr/lib/python3/dist-packages/yaml/composer.py", line 55, in 
> compose_document
> |     node = self.compose_node(None, None)
> |   File "/usr/lib/python3/dist-packages/yaml/composer.py", line 84, in 
> compose_node
> |     node = self.compose_mapping_node(anchor)
> |   File "/usr/lib/python3/dist-packages/yaml/composer.py", line 133, in 
> compose_mapping_node
> |     item_value = self.compose_node(node, item_key)
> |   File "/usr/lib/python3/dist-packages/yaml/composer.py", line 84, in 
> compose_node
> |     node = self.compose_mapping_node(anchor)
> |   File "/usr/lib/python3/dist-packages/yaml/composer.py", line 133, in 
> compose_mapping_node
> |     item_value = self.compose_node(node, item_key)
> |   File "/usr/lib/python3/dist-packages/yaml/composer.py", line 82, in 
> compose_node
> |     node = self.compose_sequence_node(anchor)
> |   File "/usr/lib/python3/dist-packages/yaml/composer.py", line 110, in 
> compose_sequence_node
> |     while not self.check_event(SequenceEndEvent):
> |   File "/usr/lib/python3/dist-packages/yaml/parser.py", line 98, in 
> check_event
> |     self.current_event = self.state()
> |   File "/usr/lib/python3/dist-packages/yaml/parser.py", line 495, in 
> parse_flow_sequence_entry
> |     return self.parse_flow_node()
> |   File "/usr/lib/python3/dist-packages/yaml/parser.py", line 268, in 
> parse_flow_node
> |     return self.parse_node()
> |   File "/usr/lib/python3/dist-packages/yaml/parser.py", line 371, in 
> parse_node
> |     token.start_mark)
> | yaml.parser.ParserError: while parsing a flow node
> | expected the node content, but found ':'
> |   in "/etc/knot/knot.conf", line 7, column 29
> | Processing triggers for libc-bin (2.24-11+deb9u3) ...
> | root@kearsarge:~# 
>
> |     listen: [ 127.0.0.1@53, ::1@53 ]
> 7:29                          ^
>
> My /etc/knot/knot.conf is attached.  Only the last line is a local 
> modification.

I can confirm that i'm seeing this if knot 2.4.0-3+deb9u1 is installed
on debian stable, and then upgraded to 2.7.2-2~bpo9+1.  This is a bug in
how /usr/lib/knot/get_kaspdb interacts with the default knot.conf, in
particular because the quoted listen: string above does not appear to be
valid yaml (it fails in the ruby yaml interpreter as well).

This makes it difficult to extract information about databases that
might need to be migrated.

One fix is to convert the above back to:

  listen:
    - 127.0.0.1@53
    - ::1@53

or, possibly, to wrap ::1@53 in quotes (i haven't tested whether knot
will accept that yet).

But of course changing the defaults won't prevent the same problem
happening based on local administrator configurations, so the script in
use is bound to fail in some contexts.  (also, i think the "include"
directive won't translate into yaml either)

so i'm a bit stuck about how to maintain this part of the upgrade
process cleanly.  i note that upstream has stopped shipping these
migration scripts already, but i think they'll be necessary for the
stretch → buster transition :(

   --dkg

Reply via email to