JunOS config yacc grammar?

Thu Aug 24 15:25:20 UTC 2023

FWIW, I find the config archival on-commit to be a very useful feature. I use it with SCP. Sadly, neither J nor C support doing this with an SSH private key on the router, you have to use a password. J at least encrypts the password if you do it right (…”URL” password “plain-text”). Cisco does not encrypt this password in the config (perhaps they do in more recent releases. All my C hardware is ancient. 

C will do it on “write”. Not quite as good as “on-commit”, but since C lacks commit, is what it is. 

YMMV. 

Owen

> On Aug 24, 2023, at 07:11, Christopher Morrow <morrowc.lists at gmail.com> wrote:
> 
> On Tue, Aug 22, 2023 at 11:39 PM Grant Taylor via NANOG <nanog at 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