Information Gathering Tasks
With this playbook, you will gather information from a PAN-OS next-generation firewall. The tasks in this playbook are useful both on their own in order to gather data, but also to use the data to feed into other tasks or other playbooks.
Assumptions
This tutorial/guide assumes:
- you have a working installation of Ansible with the PAN-OS collection installed (see example instructions here)
- you have working connectivity to the firewall and/or Panorama
- you have administrative credentials capable of performing the relevant operations on the firewall and/or Panorama
Important - Work in a Lab Environment First
With all of the tutorials and guides presented on this website, please ensure that you attempt the tasks in a lab or a similar safe and non-production environment first. In public cloud scenarios, this should be a non-production cloud account which contains no production assets or data. Confirm the tasks behave as expected and perform the operations you require, before using them in production or other live environments.
The "system info" playbook
This playbook gathers a number of system information items from a PAN-OS next-generation firewall.
- Create a file called
get-system-info.yml
and paste in the following content:
---
- name: Gather system info
hosts: "firewall"
connection: local
vars:
device:
ip_address: "{{ ip_address }}"
username: "{{ username }}"
password: "{{ password }}"
collections:
- paloaltonetworks.panos
tasks:
- name: Gather facts for device
paloaltonetworks.panos.panos_facts:
provider: "{{ device }}"
- name: Display information
ansible.builtin.debug:
msg:
- "Hostname: {{ ansible_facts['net_hostname'] }}"
- "Serial: {{ ansible_facts['net_serial'] }}"
- "Model: {{ ansible_facts['net_model'] }}"
- "Version: {{ ansible_facts['net_version'] }}"
- "Uptime: {{ ansible_facts['net_uptime'] }}"
- "HA Enabled: {{ ansible_facts['net_ha_enabled'] }}"
- "HA Type: {{ ansible_facts['net_ha_localmode'] }}"
- "HA Status: {{ ansible_facts['net_ha_localstate'] }}"
- "Multi-VSYS: {{ ansible_facts['net_multivsys'] }}"
- "{{ ansible_facts['net_session_usage'] }} out of {{ ansible_facts['net_session_max'] }} sessions in use"
- Execute the playbook with the following command:
ansible-playbook -i inventory.txt --ask-vault-pass get-system-info.yml
- The output should be something similar to this:
PLAY [firewall] ********************************************************************************************
TASK [Gathering Facts] *************************************************************************************
ok: [firewall]
TASK [Gather facts for device] *****************************************************************************
ok: [firewall]
TASK [Display information] *********************************************************************************
ok: [firewall] => {
"msg": [
"Hostname: firewall",
"Serial: 0011223344556778899",
"Model: PA-VM",
"Version: 10.1.7",
"Uptime: 8 days, 0:56:41",
"HA Enabled: True",
"HA Type: Active-Passive",
"HA Status: active",
"Multi-VSYS: off",
"12530 out of 256000 sessions in use"
]
}
PLAY RECAP *************************************************************************************************
firewall : ok=3 changed=0 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0
Closing notes
- Tasks do not have to be divided into playbook files as has been described in this tutorial. All the tasks could have been placed in a single playbook, or equally the tasks could have been divided into more playbooks than those used in the tutorial. The structure of your playbooks is something to consider as you operationalize Ansible within your organization.
- If you used the setup instructions listed here, you were using a static inventory file, and local PAN-OS credentials encrypted on disk with
ansible-vault
. This is very suitable for a learning tutorial, but these approaches may not be suitable for production, and are also something to consider as you operationalize Ansible within your organization. - Almost all values for tasks were defined within the playbooks; names of configuration items, IP addresses, and more. This is very suitable for a learning tutorial, but this approach does not scale well in production, and using variables instead is something to consider as you operationalize Ansible within your organization.