You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hi, First off, many thanks to @egberts for this effort.
I am using version 0.99.3 of bind9_parser and have the need to use the parser functionality in a REST API environment. I am running into a problem with using the code in dump-named-conf.py.
I have a web server that serves a GET parse_named API which basically calls the main in dump-named-conf.py (that comes with the distribution) with the named.conf file argument and returns a dictionary. All works as expected, except when there is a include statement like include "tsig.key"; in named.conf
In this case, the first time the main in dump-named-conf.py is called the file tsig.key is correctly loaded. But since this is a REST API it can be called multiple times. During a second API call, dump-named-conf tries to load sig.ke ...two characters are stripped from the include filename. The third call tries to load ig.k ...two more characters are stripped from the filename. And so on, until we get to a zero-length string in subsequent calls. (It remains at zero-length).
I see that the include filename is extracted from toks.include_filepath in the function read_include_contents. I see that during the first call that value is fine and in subsequent calls we have the character-stripping issue. To debug, I examined st and locn arguments passed to read_include_contents as well. In all cases those arguments are identical across calls: st always has all the contents of the filename and locn always shows the same location. So, no issue with st or locn ...only with toks.include_filepath.
So, I am assuming this has to do something with the pyparsing grammar...perhaps it is getting messed up on subsequent calls after the first one. I am not familiar with pyparsing except for the very basics. So any help provided here would be much appreciated.
Is there a way I can initialize the pyparsing engine every time the API is called? That might be a simple fix. I tried adding the following to process_entire_file_content without luck in my attempt to re-initialize the parser:
I am attaching the file conf_parser_bug.txt which is basically dump-named-conf.py with the main renamed to conf_parser_main. This file is placed in a local subdirectory and the GET API simply calls conf_parser_main with the filename. GIT won't allow me to upload .py extension so I had to rename it to .txt.
This is a very helpful parser and I'd love to continue using it, and hopefully help in the dev in the future once I am familiar with it.
Thanks, in advance, to any advice/support/fix provided here.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
Hi, First off, many thanks to @egberts for this effort.
I am using version 0.99.3 of bind9_parser and have the need to use the parser functionality in a REST API environment. I am running into a problem with using the code in dump-named-conf.py.
I have a web server that serves a GET
parse_named
API which basically calls the main indump-named-conf.py
(that comes with the distribution) with the named.conf file argument and returns a dictionary. All works as expected, except when there is a include statement likeinclude "tsig.key";
in named.confIn this case, the first time the main in
dump-named-conf.py
is called the filetsig.key
is correctly loaded. But since this is a REST API it can be called multiple times. During a second API call,dump-named-conf
tries to loadsig.ke
...two characters are stripped from the include filename. The third call tries to loadig.k
...two more characters are stripped from the filename. And so on, until we get to a zero-length string in subsequent calls. (It remains at zero-length).I see that the include filename is extracted from
toks.include_filepath
in the functionread_include_contents
. I see that during the first call that value is fine and in subsequent calls we have the character-stripping issue. To debug, I examinedst
andlocn
arguments passed toread_include_contents
as well. In all cases those arguments are identical across calls:st
always has all the contents of the filename andlocn
always shows the same location. So, no issue withst
orlocn
...only withtoks.include_filepath
.So, I am assuming this has to do something with the pyparsing grammar...perhaps it is getting messed up on subsequent calls after the first one. I am not familiar with pyparsing except for the very basics. So any help provided here would be much appreciated.
Is there a way I can initialize the pyparsing engine every time the API is called? That might be a simple fix. I tried adding the following to
process_entire_file_content
without luck in my attempt to re-initialize the parser:I am attaching the file
conf_parser_bug.txt
which is basicallydump-named-conf.py
with the main renamed toconf_parser_main
. This file is placed in a local subdirectory and the GET API simply callsconf_parser_main
with thefilename
. GIT won't allow me to upload .py extension so I had to rename it to .txt.This is a very helpful parser and I'd love to continue using it, and hopefully help in the dev in the future once I am familiar with it.
Thanks, in advance, to any advice/support/fix provided here.
conf_parser_bug.txt
Beta Was this translation helpful? Give feedback.
All reactions