Re: JunOS config yacc grammar?

[Christopher Morrow <morrowc.lists () gmail com>]

On Tue, Aug 22, 2023 at 11:39 PM Grant Taylor via NANOG <nanog () nanog org> wrote:
> On 8/21/23 7:09 PM, Diogo Montagner wrote:
> > I would first try to understand what you are trying to achieve. JUNOS is
> > very flexible on this front and I am wondering why you think yacc is the
> > right way to achieve what you are trying to do.
>
> Drive by comment:
>
> Perhaps the OP is trying to parse a (pile of) config file(s) downstream
> of the generation thereof and has no ability to alter their generation.

this is a common problem (or is common when I look at things, perhaps
I'm looking wrongly, but...)
I'd love to have something that parsed all of my device type configs
and output the results into a
'database' that i could then ask questions of like:
  "Hey, what NTP servers are configured on all devices?"
  "Hey, which devices have this <access-list/firewall/user> configured on them?"

There are a host of other things I could ask those are but 2 simple
examples, and YES I can
grep/sed/awk|sort|uniq|sort-rn my way to success for the 2 examples I
provided... but really
that's NOT the way I want to do this, and I do really have a bunch of
other questions I'd
like to ask, regularly, to solve rollout-of-new-feature / compliance /
legal / troubleshooting / etc
questions.

In looking around there are examples of some of this, in a way, the
most common thing
I end up looking at, and getting sad about, is some java monstrosity
(who's name escapes me)
but has shown up in a few nanog presentations over the years... it
makes me sad because it's
not super useful  in my world :( 'hard to use' is probably the best
way to describe it.

One note about XML and Juniper, the schema changes by OS version, it
changes quite a bit :(
You CAN parse through it reasonably well with python lxml.Etree,
because (I think) python's parse
is VERY forgiving. If you attempt this path with golang :( you will be
sad, very sad :( because
the go->xml world is very 'build a struct of structs that mirrors the
xml tree' and 'changes at every
OS version' means now you have a LOT of versions of that :(
maintenance gets back to saku's
comment about feature velocity :(

I do see:
   https://pypi.org/project/juniper-nxpy/

which may be useful to you as well Lyndon.
(I'd also point to tftp as not being the super best option from a
security and reliability perspective,
but if that's what you've got that's what you've got... you COULD have
the switch cronjobs curl/post
to an https destination with little hard work, and a gain in
reliabilty/security)

-chris