Configuration Management

Configuration Management provides a complete workflow for backing up, viewing, comparing, templating, and deploying network device configurations — all from the WhiteOwl UI. Under the hood, WhiteOwl uses Ansible to communicate with devices and Jinja2 templating to generate configurations dynamically. The page is organized into four tabs: Config History, Execute, Jobs, and Templates.

Supported Devices

Configuration Management currently supports the following vendors:

Vendor	Ansible Network OS	Notes
Cisco IOS / IOS-XE	ios	Routers and switches (ISR, ASR, Catalyst, etc.). Requires enable password for privileged EXEC mode.
Cisco NX-OS	nxos	Nexus data center switches.
Cisco IOS XR	iosxr	Service provider and carrier-grade routers.
Arista EOS	eos	Arista switches. Uses eAPI or SSH.
Juniper Junos	junos	Juniper routers and switches.
Fortinet FortiGate	fortios	FortiGate firewalls.
Palo Alto PAN-OS	panos	Palo Alto next-generation firewalls.
MikroTik RouterOS	routeros	MikroTik routers and switches.
HP / Aruba ProCurve	procurve	HP and Aruba network switches.
pfSense	pfsense	pfSense open-source firewall/router.

WhiteOwl automatically determines the network OS based on the device vendor when executing configuration jobs.

Prerequisites: Device Credentials

Before using Configuration Management, SSH credentials must be configured for each target device. Credentials are managed under Settings → Devices. For each device:

1. Navigate to Settings in the sidebar.
2. Open the Devices section.
3. Locate the device and click the edit/settings icon next to it.
4. Enter the following credentials:
   • SSH Username — The username for SSH access (e.g., admin).
   • SSH Password — The password for SSH authentication.
   • Enable Password — The enable/privileged EXEC password (required for Cisco IOS devices that use enable mode).

Credentials are stored encrypted in the database. WhiteOwl retrieves them at execution time and passes them to Ansible securely.

Credentials Required

Configuration jobs will fail if SSH credentials are not configured for the target device. Ensure all devices you plan to manage have valid credentials before executing templates.

---

Config History

The Config History tab displays a table of all device configuration backups collected by WhiteOwl. Configurations are retrieved via Ansible (show running-config or equivalent) and stored for viewing, comparison, and auditing.

Refreshing Configurations

• Refresh All Configs — Click this button to trigger a bulk configuration backup across all managed devices. WhiteOwl runs Ansible against each device to pull the current running configuration.
• Reload View — Refreshes the table display without re-fetching configurations from devices.

Filters

Filter	Description
Device	Filter to a specific device (e.g., cisco-router1.eve-ng). Defaults to All Devices.
Type	Filter by configuration type (e.g., manual). Defaults to All Types.
Job	Filter by the job that triggered the backup. Defaults to All Jobs.
Clear	Resets all filters to defaults.

Config History Table

Column	Description
Device	The device hostname.
Type	How the configuration was retrieved (e.g., manual for on-demand refresh).
Job	The job name associated with this backup, if any.
Changed By	How the backup was triggered (e.g., Bulk Refresh).
Date	Timestamp of when the configuration was captured.
Size	File size of the stored configuration (e.g., 7.1 KB).
Actions	View (👁️) — Opens the full configuration text in a viewer. Download (⬇️) — Downloads the configuration as a text file.

---

Execute

The Execute tab is where you deploy configurations to devices. The workflow involves selecting a template, choosing target devices, filling in template variables, and executing the job.

Execution Workflow

1. Select Template — Choose a previously created Jinja2 template from the dropdown.
2. Select Devices — Check the boxes next to one or more target devices. Devices can be filtered by site, vendor, or model.
3. Fill Variables — If the template contains Jinja2 variables (e.g., {{ interface_name }}, {{ vlan_id }}), a form appears to provide values for each variable.
4. Job Settings — Name the job and optionally enable Dry Run mode.
5. Preview — Review the rendered configuration that will be pushed to each device.
6. Execute — Deploy the configuration via Ansible.

Dry Run Mode

When Dry Run is enabled, Ansible runs in --check mode — it connects to each device and validates the configuration but does not apply any changes. This is useful for verifying connectivity, credential validity, and template correctness before making real changes.

Always Dry Run First

It's strongly recommended to run every new template in Dry Run mode first to verify the generated configuration is correct and that WhiteOwl can successfully connect to all target devices.

---

Jobs

The Jobs tab shows the history and results of all executed configuration jobs. Each job entry displays:

• Job Name — The name given to the job at execution time (e.g., add local logging).
• Template Used — The template that was executed (e.g., enable_logging_cisco).
• Device Count — Number of devices targeted (e.g., 4 devices).
• Timestamp — When the job was executed.
• Status Summary — Success and failure counts (e.g., ✅ 3 ❌ 1) with an overall status badge:

Badge	Meaning
success	All devices completed successfully.
partial	Some devices succeeded, some failed.
failed	All devices failed.

Per-Device Results

Expand a job to see results for each individual device:

• Device hostname and IP — The target device.
• Status icon — ✅ Green checkmark for success, ❌ Red circle for failure, 🟡 Yellow for warnings.
• Completed timestamp — When the device finished processing.
• View output — Expand to see the raw Ansible output for this device, including any errors or warnings.
• View generated config — Expand to see the rendered Jinja2 configuration that was pushed to this device.

This per-device detail is essential for troubleshooting partial failures — for example, identifying that a device failed because of an authentication error while others succeeded.

---

Templates

The Templates tab is where you create and manage reusable Jinja2 configuration templates.

Starter Templates

When creating a new template, WhiteOwl can automatically pre-populate the template body based on your selected vendor and type combination. If the template body is empty and you select a supported vendor/type pair, the starter is applied automatically. For existing templates with content, click Load starter template to apply it manually (you will be prompted to confirm, as this will overwrite the current content).

Starter templates are available for the following combinations:

Vendor	Available Starters
Cisco IOS / IOS-XE	NetFlow, SNMP, Logging, Interface Config
Cisco NX-OS	NetFlow
Cisco IOS XR	NetFlow
Arista EOS	NetFlow, Interface Config
Juniper JunOS	NetFlow, SNMP
Fortinet FortiGate	NetFlow
Palo Alto PAN-OS	NetFlow
MikroTik RouterOS	NetFlow
HP / Aruba ProCurve	NetFlow

Starter templates include pre-built Jinja2 content with sensible defaults and a matching variable schema — variables such as collector_ip, collector_port, sample_rate, source_interface, and interfaces are wired up automatically so the Execute tab immediately renders the correct input form.

Creating a Template

Click New Template to open the template builder:

Field	Description
Name	A descriptive name for the template (e.g., Enable NetFlow Export, Access Port Config).
Vendor	The target vendor: Cisco, Arista, or Juniper. This determines the Ansible network OS used during execution.
Description	Optional description of what the template does.
Template Type	The category of configuration. Available types: NetFlow / sFlow, Interface Config, Routing, ACL, VLAN, SNMP, Logging, Full Config.
Template (Jinja2)	The configuration template body using Jinja2 syntax.

Jinja2 Syntax

Templates use Jinja2 templating syntax. Variables are enclosed in double curly braces and are populated at execution time via the variable form in the Execute tab.

Simple variable substitution:

interface {{ interface_name }}
 description {{ description }}
 switchport mode access
 switchport access vlan {{ vlan_id }}

Conditionals:

interface {{ interface_name }}
 switchport mode {{ mode }}
{% if mode == 'access' %}
 switchport access vlan {{ access_vlan }}
{% else %}
 switchport trunk allowed vlan {{ trunk_vlans }}
{% endif %}

Loops:

{% for vlan in vlans %}
vlan {{ vlan.id }}
 name {{ vlan.name }}
{% endfor %}

Static configuration (no variables):

Templates don't have to use variables. You can create static templates for standardized configurations that are applied identically across all devices:

flow record EXPORT
 match ipv4 dscp
 match ipv4 destination address
 match ipv4 destination mask
 match ipv4 source address
 match ipv4 source mask
 match ipv4 protocol
 match ipv4 tos

Template Examples

Template Name	Vendor	Use Case
NetFlow Export	Cisco IOS, NX-OS, IOS XR, Arista, Juniper, Fortinet, Palo Alto, MikroTik, HP	Configure flow export to a NetFlow/IPFIX collector.
Interface Config	Cisco IOS, Arista	Configure interface descriptions, IP addressing, and sampling.
SNMP Community	Cisco IOS, Juniper	Set SNMP community strings for monitoring.
Logging / Syslog	Cisco IOS	Configure remote syslog server and logging levels.
Access Port Config	Cisco / Arista	Configure an access port with VLAN assignment.
Full Config	Any	Complete device configuration baseline.

---

How It Works Under the Hood

When you execute a configuration job, WhiteOwl performs the following steps:

1. Renders the template — Jinja2 variables are substituted with the values you provided to produce the final device configuration.
2. Retrieves credentials — SSH username, password, and enable password are decrypted from the database for each target device.
3. Executes Ansible — WhiteOwl runs an Ansible playbook targeting each device. The playbook connects via SSH, enters privileged mode (if required), and applies the configuration.
4. Captures output — Ansible stdout and stderr are captured and stored per-device for review in the Jobs tab.
5. Backs up configuration — Before applying changes, WhiteOwl automatically backs up the device's current running configuration to Config History.

Ansible runs with ANSIBLE_HOST_KEY_CHECKING=False to avoid SSH key verification issues in lab and dynamic environments. In production, you may want to manage known hosts separately.