Using the ‘register’ clause and ‘debug’ module in Ansible to display specific dictionary keys

register:

  • Used to register variables defined in a module when it is invoked in a task
  • The registered data is stored in JSON format
  • The value of the variables set using the register clause is always a dictionary, but the specific keys of the dictionary are different, depending on the module that was invoked.
  • Every module will have a different dictionary of variables that it will try to gather from the host.
  • Below example shows the three dictionary values that were registered when using backup parameter in ios_config module.
ok: [coresw03] => {
"result": {
"backup_path": "/etc/ansible/roles/cisco_ios/backup/coresw03_config.2019-04-28@13:40:06",
"changed": false,
"failed": false
}
}

debug:
  msg:

  • Used to display the variables registered using the register clause.
  • The registered variable is referenced within {{ }} when using the msg parameter.
  • This can be used along with a regular message string to provide more context to the variable’s specific dictionary key that was registered.
  • To reference only a specific key in the dictionary append the registered variable with the dictionary key that you want to display;
{{ result.backup_path }}
  • The msg paramter supports array, so you can reference multiple keys in the same task;
msg:
- "Backup path is {{ result.backup_path }}"
- "Changed: {{ result.changed }}"

debug:
  var:

  • Used to display the variables registered using the register clause.
  • Outputs the variable in raw format and cannot provide any context to the variable’s specific dictionary key that was registered.
  • To reference only a specific key in the dictionary append the registered value with the dictionary key that you want to display;
result.backup_path
  • The var parameter doesn’t support array. So you cannot reference multiple keys in the same task.

Note:

debug: var and debug: msg are mutually exclusive and cannot be used together in the same task. But they can be used in separate tasks under the same play.

 

Continue reading

Advertisements

Ansible – IOError: [Errno 13] Permission denied:

After spending more than year learning Ansible and Python and doing nothing about it, I have been getting my hands dirty with Ansible yet again. Only this time it will be more aligned to a real world project.

So recently I was testing a playbook to backup Cisco IOS config and used the ios_config module to run a backup and schedule it using Ansible tower.

Just a simple playbook, nothing fancy:

- name: IOS Config Backup
hosts: coresw03
connection: network_cli
gather_facts: no

tasks:
- name: Start Backup
ios_config:
backup: yes

And here’s how the job was configured in Ansible tower:

The ios_config module attempts to write backup file in the backup folder in the playbook root directory. If the directory does not exist, it is created. Because my Ansible tower was installed/setup using the root account (which is required to install Ansible tower) my default project directory was
/var/lib/awx/projects, which is only accessible via root.

Ansible tower was not able to access this directory when executing the playbook and encountered the below error;

The full traceback is:
Traceback (most recent call last):
File "/usr/lib/python2.7/dist-packages/ansible/executor/task_executor.py", line 140, in run
res = self._execute()
File "/usr/lib/python2.7/dist-packages/ansible/executor/task_executor.py", line 612, in _execute
result = self._handler.run(task_vars=variables)
File "/usr/lib/python2.7/dist-packages/ansible/plugins/action/ios_config.py", line 52, in run
result['backup'])
File "/usr/lib/python2.7/dist-packages/ansible/plugins/action/ios_config.py", line 78, in _write_backup
open(filename, 'w').write(contents)
IOError: [Errno 13] Permission denied: u'/var/lib/awx/projects/backup/backup/coresw03_config.2019-04-20@12:29:30'

To solve this problem, I changed the permissions to 1777 for the directory where the backup config was being saved by the ios_config module

chmod
1777 /var/lib/awx/projects/backup/backup

Alternatively, a much simpler option is to store the playbooks in a directory that is less restricted and has the correct permissions. :)

Advanced grep filters for F5 logs

Grep X number of lines after matching pattern is found

[root@ltm02:Active:Standalone] config # zless /var/log/ltm* | grep -A 2 "16:03:23" -n
230:May  3 16:03:23 ltm02 notice bigd[5171]: 01060001:5: Service detected UP for ::ffff:172.16.4.10:80 monitor /Common/site1-http-mon.
231-May  3 16:03:24 ltm02 notice bigd[5171]: 01060001:5: Service detected UP for ::ffff:172.16.4.20:80 monitor /Common/site1-http-mon.
232-May  3 16:03:24 ltm02 notice mcpd[4647]: 01070727:5: Pool /Common/site1.dc1.networkology.net member /Common/172.16.4.10:80 monitor status up. [ /Common/site1-http-mon: up ]  [ was down for 3hrs:25mins:55sec ]

The above example greps 2 lines after the matching pattern “16:03:23” is found. Continue reading

Troubleshooting SSL handshake in F5 BIG-IP LTM – Part 1 (SSL/TLS Protocol Mismatch)

How to identify if there is an SSL/TLS protocol mismatch between Client and F5 LTM?

1.  Check the protocol version used by the client in wireshark captures under the “Client Hello” packetprotocol mismatch wireshark capture

2.  Check the SSL/TLS protocol version supported by the LTM for a particular VIP

  • Run curl checks if possible from a remote server
curl -Ik https://site1.dc1.networkology.net --sslv2
curl -Ik https://site1.dc1.networkology.net --sslv3
curl -Ik https://site1.dc1.networkology.net --tlsv1
curl -Ik https://site1.dc1.networkology.net --tlsv1.0
curl -Ik https://site1.dc1.networkology.net --tlsv1.1
curl -Ik https://site1.dc1.networkology.net --tlsv1.2
  • Check if any protocol is negated in ciphers under client-ssl profile;

Continue reading

F5 iRules – Unconditionally redirect based on host header content and close initial connection #0

when HTTP_REQUEST {
 if { [string tolower [HTTP::host]] equals "site2.lab.com" }
 {
       HTTP::respond 302 noserver -reset Connection close Location http://site3.lab.com }
}

With the above iRule, the initial connection to site2.lab.com is closed when the redirect message is sent to the client. Check out the below output from curl which validates the same.

Continue reading