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 <[email protected]> wrote: > > On Tue, Aug 22, 2023 at 11:39 PM Grant Taylor via NANOG <[email protected]> > 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
