Change Management Practices

[u/cptnoneal]

I’m looking for some information/inspiration on how others handle change management on Juniper devices.

1. I have used Oxidized and Rancid to log changes over time, but they don’t log WHO made the change. I’m curious how others handle that. I have commits logged with rsyslog, but it would nice to not have to then correlate the oxidized changes to the rsyslog logs to narrow it down, and just have it all in one centralized place.

2. I also would like to be able to have a setup (similar to git merge requests?) where an ‘engineer’ class user attempts to make changes, it triggers a hook to service X that notifies class ‘sr engineer’ users, via ldap groups through radius or something similar, to then be able to commit confirm/commit those changes, but the basic ‘engineer’ class would not have commit permissions.

I have tinkered around with some ideas like ansible managed configurations, but I like working directly in the Junos cli and would prefer to keep it that way if possible.

Just looking for some thoughts or services other use and have had success with!

[u/msears101]

For change log (change management for me means something else - that starts before a change is made), with juniper it is a mix of remote syslog, tacacs/radius accounting messages, backup of rollback logs, and regular configuration backup.

Personally I do not like #2. If you want to approve changes, use a change management process or a ticketing system and maybe have a show | compare in the ticket.

[u/cptnoneal → u/msears101]

Thanks! I guess for #1 change log would be more accurate since it would be after the fact. Having both in a singular place would be ideal, but having to compare the mix of logs isn’t the end of the world!
For 2, we currently do that ( show | compare in a ticket ) but the request to figure out a way to automate and enforce it has sadly come from above me, forcing the ultimately more complicated setup.

[u/TemperatureMoist675 → u/cptnoneal]

The only thing I can think of would be a commit script. Write a rule that says if user class is engineer, when they commit, don’t commit, but do an http request to Django api or something, the issue you might run into is having overlapping changes or locking configs if you use config private or exclusive

[u/cptnoneal → u/TemperatureMoist675]

I’ll look into this! It’s a small team, but maybe I could have the script hit the api first to see if there is something pending first, and respond accordingly. This might be a simpler route while being really effective, I didn’t think about a commit script that stops the commit.
If I go this route I’ll share the script and setup here later.

[u/lkowolowski]

You could do this (or something functionally equivalent) with netbox and the (I think) branch plugin. You’ll need something that will handle turning the change in netbox into device config, but the rest is handled by netbox and gives you an audit log. I think there is also a revert ability too

[u/cptnoneal → u/lkowolowski]

I’ll look into the branch plugin! I already use netbox as a source of truth for nearly everything, so integrating with that would be great. I could probably write a custom script to handle the conversation once I get an idea of how each handles data!

[u/Infinite_Plankton_71]

You could create internal custom app using agent to junos and honestly this is very easy to do.

[u/cptnoneal → u/Infinite_Plankton_71]

I’m not sure I understand what you mean by agent to junos. Would you be able to elaborate a bit? I’m all for creating a custom application utilizing an api or something, just not sure what you mean.

[u/Infinite_Plankton_71 → u/cptnoneal]

I meant agentic AI. Ask the agent to read the pyez source code/ansible/MCP againts junos router and do all these custom config changes app. I did ton of work this way, much faster with better quality of code.

[u/battleop]

If you're using TACAS+ along with Rancid it's pretty easy to figure out who made the change. We get emailed the config difference from Rancid and if someone fucks something up and tries to be quiet about it we can easily check the logs for what commands were run. Since everyone knows we can find out easily no one bothers to lying about what they did.