Managing audio settings on Mac devices can be repetitive, especially when switching between different microphones for calls, recordings, or meetings. Siri Shortcuts provides a powerful way to automate this process.
The year of 2023 I think may have had some of the biggest leaps in the Network Automation capabilities that are being delivered by some of the best in the business. With Nautobot’s Golden Config App adding the ability to complete configuration remediation and Ansible release Event Driven Ansible, there are a couple of powerful tools to help you with your Network Automation. And all with a great new conference addition specific to Network Automation.
In my home environment I am leveraging Nautobot as my source of truth. This is for the network, which is probably not all that interesting in my home environment, and my virtual machines. Why am I tracking my virtual machines in Nautobot? Simple, to help automate them. I think that this is a clever methodology to help use tags and to get automation working within the environment. This same type of thing may be applicable to your network environment as well.
As part of my journey of using my Debian based Dev Workstation, as well as my studies towards completion of the DevNet Expert, I wanted to get up and running with the DevNet Workstation example that would help to become familiar with the environment that would be found at the live exam. There were a few small quirks along the way, so I thought I would go ahead and create a post about how to get started.
Within Nautobot there are many ways to be able to get the Nautobot environment running. Environment variables are used quite a bit in the Docker environment following best practice principles set forth in the 12 Factor App. The use of environment variables is helpful for working through the various stages of an application to production. The installation instructions leverage a single environment variable NAUTOBOT_ROOT and that is set in the SystemD files shown below:
One observation lately is that Python is moving along quickly with new versions and new EOLs. Along with needing to make these updates, the applications that Python uses will also need to be moving along. Nautobot is my favorite, and in my opinion the best SOT platform available in the open source ecosystem today. So let’s dive into the updating of the Python version.
For this post, I’ve created a new Rocky 8 Virtual Machine to be the host. See the note below for the reasoning. This will start off with a Nautobot install from the Nautobot docs. I won’t dive into all of that, assume that is the starting point with a fresh Nautobot application.
In my previous post I wrote about a workstation that I was working on building. It took an incredibly long time to get up and into a stable environment. But I have finally accomplished stability (hoping to not jinx it here with the post). I went through a fair bit of troubleshooting to get to this point.
The symptom that was having instability was that the system would freeze randomly. There was not a particular application or otherwise that would be point me to an application that was causing the failures. The system would just freeze overnight or at the start of getting into the desktop UI.
Here I’m going to dive into what I’m planning to build out for my next desktop here in 2023. Prime Day is nearly upon us, and I’m anticipating (but do not know for sure) that prices on some of the gear that I’m looking for will be available at a good price. I’m also looking to build out a bigger system in order to run some intense VMs up coming.
One of Nautobot’s primary functions is to serve as an IPAM solution. Within that realm, the application needs to provide a method to get at IP address data for a device, quickly and easily. In this post I will review three prominent methods to get an IP address from Nautobot. It will demonstrate getting the address via:
Each method I will demonstrate how to get the IP address for Loopback0 on the device bre01-edge-01 within the demo instance of Nautobot. This device has 62 interfaces, so being able to filter down to which interface IP address we are looking for makes sense.
In this post I’m going to dive into a bit more on the Nautobot custom validators. This is a powerful validation tool that will allow for you to write your own validation capability, including in this demonstration on how to complete a validation against a remote API endpoint. The custom validators are a part of the Nautobot App extension capability. This allows for custom code to be written to validate data upon the clean() method being called, which is used in the majority of API calls and form inputs of Nautobot.
With Nautobot, one of the things that came up was how to work with secrets. Nautobot itself is not the place to maintain secrets, as it is not a vault. There may be some good cryptographic libraries out to handle this, but by its nature, that is not the intent. So Nautobot has written methods to be able to retrieve secrets from proper vault sources and be able to leverage them. These can be tricky to get set up however. I had struggled for a while myself. So now that I have it working, I thought it would be a good time to have a quick personal blog about it.
Today I was working to demonstrate how to get started with Nautobot Jobs within the Jobs root of Nautobot. This is not a pattern that I develop often, as I am typically developing Jobs within a plugin as my development standard. More to come on that later. During this case, the ask was to build a Job that would connect to a network device. I had a few troubles that I didn’t want to have to work through on a call that had limited time and that was a screen share. So I am taking to working on this via a blog post to share, and hopefully will be helpful for others as well.
One of the great things about building an enterprise system, is being able to get systems to work cohesively amongst themselves to bring a complete solution. One of the workflows that is often required in a static IP address environment is the need to provide static IP addresses to hosts on a network segment. When using an IPAM (IP Address Management) solution such as Nautobot, the APIs and SDKs/modules made available for use in automation workflows is paramount to having the cohesion to make a seamless IT system.
One of the features that I find myself using periodically that I think is underrated as far as using GraphQL is its ability to alias return keys in the response. This can be extremely helpful for developers writing applications, as it allows them to have the API response with the keys they are looking for. I have found this feature particularly useful when working on applications like Meraki and Nautobot together. In Nautobot a place is typically defined as the key site. In the Meraki world this is commonly set up as a network. Without GraphQL’s alias feature, the developer would need to translate this data over.
One of my favorite things to do as I get started with writing a piece of automation or code, is to lay out the design with pseudo code in the form of comments. I will do this with both Python and Ansible automations, and is a great way to get started on writing your automation or code. What pseudo code does for you is to layout the process at which you wish to accomplish a particular goal. And from there, you write the code that corresponds to the plain English wording of what is being done. By starting with pseudo code, you are starting with the process first. Then working on getting to the details of the code as you go.
This is a topic that I’m fairly opinionated on as of late is looking at what should be maintained within an inventory and the strategy of how to set up the inventory.
For the case of this blog post, I am going to use the term playbook to represent the automation being run. This is yes an Ansible term, but also apply this as your automation run that is using Nornir or any other automation framework.