You can check the collection with the ansible-galaxy command again:
ansible-galaxy collection list check_point.mgmt
If the collection is installed, it will return the location on disk where the collection is installed and the version of the collection:
# /home/dtoler/ansible/collections/ansible_collections
Collection Version
---------------- -------
check_point.mgmt 6.2.1
You can verify the path for your Ansible collections path with the command "ansible --version". This will load the default ansible configuration file from the default search path (/etc/ansible, your home directory, or the current local directory):
$ ansible --version
ansible [core 2.16.3]
config file = /home/dtoler/ansible/ansible.cfg
configured module search path = ['/home/dtoler/ansible/library']
ansible python module location = /usr/lib/python3.12/site-packages/ansible
ansible collection location = /home/dtoler/ansible/collections
executable location = /usr/bin/ansible
python version = 3.12.3 (main, Jun 19 2024, 10:06:03) [GCC 8.5.0 20210514 (Red Hat 8.5.0-22)] (/usr/bin/python3.12)
jinja version = 3.1.2
libyaml = True
To feed data to Ansible, there are 2 ways that are "best": YAML format, or JSON format. Ansible can work with either format equally. If you are writing the data manually yourself, then you will want to use YAML because it is easier to type and has less rules about how to structure the content. However, if you are pulling the data from another source (such as with an API, or something generated programmatically), then most likely JSON will be the format to use.
You can use a CSV exported from Excel, but this could result in more work than necessary, especially if the ordering of the fields change. YAML and JSON don't require your fields to be in a specific order.
The first thing you need to do, when starting with Ansible, is to start thinking of your data source as some type of "object" that you can describe in a consistent way. For example, if you want to add many host objects, you will describe the host objects as a "list of items". If you want to assign these hosts to a specific group, you can add that to the host object description. This is how to do it with YAML:
host_objects:
- name: Host1
ipv4_address: 192.0.2.1
color: orange
comments: This is the Host1 object
groups:
- group1
- group2
- name: Host2
ipv4_address: 192.0.2.2
color: forest green
comments: This is another object
groups:
- group2
- group3
You can save this YAML list object in a separate file, such as "vars_hosts.yml".
You can write your playbook to be generic, so that it acts as a template. The playbook will always do the same thing every time, but the content will be loaded from the separate YAML variables file.
- name: Add hosts to management server
hosts: cpmgmt01 # change this to your MDS domain or your mgmt server
gather_facts: false
connection: httpapi
vars:
install_policy: true # change this to false to skip policy install
policy_package: 'YOUR POLICY PACKAGE NAME' # Change this to your policy package; such as Standard
ansible_network_os: check_point.mgmt.checkpoint
ansible_api_key: "your API key string" # use the API key if your administrator has one
# ansible_user: YOUR_SMARTCONSOLE_USERNAME # use this instead of api key
# ansible_password: YOUR_SMARTCONSOLE_PASSWORD # use this instead of api key
vars_files:
- vars_hosts.yml # THIS is the external variables file that has your host objects defined
tasks:
- name: Add host objects
check_point.mgmt.cp_mgmt_host:
name: "{{ item.name }}"
ipv4_addres: "{{ item.ipv4_address | default(omit) }}"
ipv6_address: "{{ item.ipv6_address |default(omit) }}"
color: "{{ item.color | default(omit) }}"
comments: "{{ item.comments | default(omit) }}"
groups: "{{ item.groups |default(omit) }}"
loop: "{{ host_objects |default([]) }}"
loop_control:
label: "{{ item.name }}"
- name: Publish
check_point.mgmt.cp_mgmt_publish:
wait_for_task: true
- name: Install Policy
check_point.mgmt.cp_mgmt_install_policy:
policy_package: "{{ policy_package }}"
policy_targets: "{{ policy_targets |default(omit) }}"
access: true
install_on_all_cluster_members_or_fail: true
wait_for_task: true
wait_for_task_timeout: 5 # minutes
when: install_policy |default(false)
This playbook will read the vars_hosts.yml file containing your host objects and their properties. The "host_objects" list will be used by the Check Point "mgmt" collection "cp_mgmt_host" module. I used it in a loop to iterate through each list item and add, or edit, a host object with the given properties. I used the "default(omit)" filter many times so that if those properties aren't present, those will be removed when the Ansible module is used. This lets you have missing values, but prevent the playbook from failing.
At the end, I use the Publish module to save changes to the management server database. I also added a call to the "install policy" module. I used a "when" condition so that you can disable this module with a variable at the top. There's a variable named "install_policy" and I wrote it to be 'true', but you can change it to 'false', and this will skip the policy installation at the end. You can review the changes in SmartConsole first, if you'd like, before automatically installing the policy.
If you used JSON, instead, that's ok so long as your host_objects list has the same properties:
{
"host_objects": [
{
"name": "Host1",
"ipv4_address": "192.0.2.1",
"color": "orange",
"comments": "This is the Host1 object",
"groups": [
"group1",
"group2"
]
},
{
"name": "Host2",
"ipv4_address": "192.0.2.2",
"color": "forest green",
"comments": "This is another object",
"groups": [
"group2",
"group3"
]
}
]
}
In this example, both the YAML and the JSON format are the exact same, just in different syntax. Ansible can read both without issue.
If your data source is some other format, such as CSV... ouch. Again, you can force CSV to work, but it's not pretty. Many people do it, so it's not always "wrong", but it certainly is not "best". You will have to do extra work somewhere to get it into some format you can use easily with Ansible.
I hope this helps get you closer to your goal!
