Error syntax error while loading yaml ansible

SUMMARY

Syntax Error while loading YAML

ISSUE TYPE

• Bug Report

COMPONENT NAME

macos and python3.8

ANSIBLE VERSION

ansible --version
ansible 2.9.7
  config file = /private/etc/ansible/ansible.cfg
  configured module search path = ['/Users/admin/.ansible/plugins/modules', '/usr/share/ansible/plugins/modules']
  ansible python module location = /Library/Frameworks/Python.framework/Versions/3.8/lib/python3.8/site-packages/ansible
  executable location = /usr/local/bin/ansible
  python version = 3.8.0 (v3.8.0:fa919fdf25, Oct 14 2019, 10:23:27) [Clang 6.0 (clang-600.0.57)]

CONFIGURATION

OS / ENVIRONMENT

macos

STEPS TO REPRODUCE

my inventory file:

$ cat /etc/ansible/hosts
[webserver]
172.16.0.[1:253]

[dbserver]
[a:z].example.org

ok:

$ ansible 'dbserver' --list-hosts
  hosts (26):
    a.example.org
    b.example.org
    c.example.org
    d.example.org
    e.example.org
    f.example.org
    g.example.org
    h.example.org
    i.example.org
    j.example.org
    k.example.org
    l.example.org
    m.example.org
    n.example.org
    o.example.org
    p.example.org
    q.example.org
    r.example.org
    s.example.org
    t.example.org
    u.example.org
    v.example.org
    w.example.org
    x.example.org
    y.example.org
    z.example.org

but, when i have an yml file:

all:
  children:
    webserver:
      hosts:
        172.16.0.[1:253]:
    dbserver:
      hosts:
        [a:z].example.org:

error:

 $ ansible -i hosts.yml 'dbserver' --list-hosts
[WARNING]:  * Failed to parse /private/etc/ansible/hosts.yml with auto plugin: Syntax Error while loading YAML.   expected <block end>, but found '<scalar>'
The error appears to be in '/private/etc/ansible/hosts.yml': line 8, column 14, but may be elsewhere in the file depending on the exact syntax problem.  The
offending line appears to be:        hosts:         [a:z].example.org:              ^ here
[WARNING]:  * Failed to parse /private/etc/ansible/hosts.yml with yaml plugin: Syntax Error while loading YAML.   expected <block end>, but found '<scalar>'
The error appears to be in '/private/etc/ansible/hosts.yml': line 8, column 14, but may be elsewhere in the file depending on the exact syntax problem.  The
offending line appears to be:        hosts:         [a:z].example.org:              ^ here
[WARNING]:  * Failed to parse /private/etc/ansible/hosts.yml with ini plugin: Invalid host pattern 'all:' supplied, ending in ':' is not allowed, this
character is reserved to provide a port.
[WARNING]: Unable to parse /private/etc/ansible/hosts.yml as an inventory source
[WARNING]: No inventory was parsed, only implicit localhost is available
[WARNING]: provided hosts list is empty, only localhost is available. Note that the implicit localhost does not match 'all'
[WARNING]: Could not match supplied host pattern, ignoring: dbserver

If you are reading this tutorial, chances are you use Ansible for automation in your daily workloads. But as with all software, Ansible can occasionally have issues. Worry not, though. Command-line options and Ansible debug can help!

In this tutorial, you’ll learn to troubleshoot playbooks, resolving any potential issues as quickly as possible, so you can get back to automating.

Read on and smoothly run your playbooks without messing things up!

Prerequisites

This tutorial will be a hands-on demonstration. If you’d like to follow along, be sure you have the following.

• An Ansible control node with Ansible installed.

• A managed node or host that the control node can access via SSH. Here’s a guide in starting SSH with Powershell.

• Python 3.x is installed on both the control node and the managed node (host).

• An inventory file set up and populated with hostnames or IP addresses of your managed host.

Troubleshooting Using the Command-Line Options

Running into errors when executing your playbooks can be a pain. Naturally, you’d need a way to troubleshoot and debug your playbooks to avoid messing things up. Luckily, Ansible lets you troubleshoot playbooks by appending options in the ansible-playbook command.

By default, Ansible has a built-in syntax checker called --syntax-check. This syntax checker is a great way to catch mistakes in your YML files before running your playbooks.

To demonstrate how the syntax checker works:

1. Create a YAML file (playbook) in your current working directory on your control node using your preferred text editor and populate the following code. You can name the file as you like, but for this tutorial, the file is named create_user.yml.

The code below runs a task to create a user named ata on your managed node.

---
- name: Ansible Create user
  hosts: all
  become: true

  tasks: # Runs a task to create a user named 'ata'
   - name: Create ata user
     user:
        name: ata
        state: present

2. Next, open your terminal, and run the following command to test the create_user.yml playbook for syntax errors (--syntax-check).

The syntax checker parses the YAML file and looks for any potential errors without running any of your playbook tasks.

ansible-playbook --syntax-check create_user.yml

If your playbook passes the syntax check without errors, you’ll see the name of your playbook (create_user.yml) as in the following screenshot. But if there are errors in your playbook, you’ll see an error message and the line number where the error occurred explicitly (step four).

3. Open the create_user.yml file in a text editor and add a line that says “This is an error!!!” at the bottom to cause a syntax error, then save and close the file.

4. Now, rerun the below command to perform a --syntax-check on your playbook (create_user.yml).

ansible-playbook --syntax-check create_user.yml

As you can see below, the syntax checker caught the error and displayed the message Syntax Error while loading YAML, followed by the line number where the error occurred (12).

5. Go back to the create_user.yml file and remove the random line you added to cause an error. Save the changes you made and close the file.

6. Next, rerun the below command to perform a --syntax-check to ensure there are no more errors in your playbook (create_user.yml).

ansible-playbook --syntax-check create_user.yml

7. Run the below command to perform a dry run (--check) on your playbook (create_user.yml).

Performing a dry run is a great way to test your playbook for errors before running it on live systems. A dry run lets you simulate running a playbook without changing any data or taking any action on the hosts.

ansible-playbook --check create_user.yml

Note that not all modules support the –check flag. For example, modules that change data or the system do not support the –check flag.

Tasks using modules that support the –check flag shows the output of running the task on target hosts and any changes made if the module were executed.

8. After the dry run, execute the below command to connect to one of the hosts via ssh to verify no changes are made on the managed hosts. Replace root and 159.223.233.161 with your managed host’s actual username and IP address.

9. Now, run the tail command below to check if the user ata was created in the /etc/passwd file.

You’ll see that no ata user was created after the dry run, as shown below since the dry run only checked for errors without actually running the playbook.

10. Finally, run logout to leave the managed host.

Enabling Playbook Debugger to Start When Running a Playbook

You’ve seen that troubleshooting playbooks using options in the ansible-playbook command works like a charm. But apart from those options, Ansible also has the built-in playbook debugger.

The Ansible playbook debugger is a powerful tool that allows you to step through your playbook and see the results of each task as they execute.

1. Run the below command to create a config file called ansible.cfg in your home directory (the root directory in this example). This file contains configuration options for the playbook debugger.

ansible-config init --disabled > ansible.cfg

2. Next, open the ansible.cfg file in a text editor and add the enable_task_debugger = True line under the defaults section, as shown below. This setting enables the playbook debugger to start automatically when you run the playbook. Save the changes and close the file.

Once the playbook debugger is enabled, any failed or unreachable task will begin the inline debugger interaction prompt.

3. Run the below command to ensure that you are using the correct config file, which should be ansible.cfg in your home directory, as shown below.

Troubleshooting with the Ansible Debug

Since you’ve set the playbook debugger to start whenever you run a playbook, you can now put the debugger keyword anywhere in a playbook. Doing so enables task debugging, such as playbooks, roles, blocks, or even individual tasks.

The debugger keyword supports five values, including the most commonly used value (on_failed) when debugging a play:

To troubleshoot a playbook with Ansible debug:

1. Create a debugger_demo.yml playbook in your favorite editor, and populate the following code. Save the changes and close the playbook.

The code below installs a package called does_not_exist on the managed host using yum. But since the package doesn’t exist in the yum repository, the task will fail and invoke the debugger.

---
- name: Debugger demo
  hosts: all
	# Enable debugging for a task.
  debugger: on_failed # Invokes the debugger if the task fails
  vars: # Set a variable to hold the package name
    - pkg_name: does_not_exist 
  tasks:
   - name: Install a package # Installs the package the pkg_name variable holds
     yum: 
      name: "{{ pkg_name }}" 
      state: present

2. Next, run the below command to execute the playbook (debugger_demo.yml).

ansible-playbook debugger_demo.yml

The task fails since the debugger_demo.yml playbook tries to install a package that doesn’t exist, as shown below. You’ll also notice an inline debugger prompt.

Once you invoke the debugger, you will have access to many debugger arguments/commands that help you step through the playbook, as shown below.

3. Run the below command to inspect what task argument values (task.args) are used during task execution.

In the output below, you can see the task is using the default values for the name and state arguments. These default values are defined in the vars section of the debugger_demo.yml playbook. Notice the package name (does_not_exist) with a state of present.

4. Now, run the following command to update the state argument to a package (bash) that exists in the managed host’s repository.

At this point, you have a new inline value for the task.args[‘name’] argument(bash). You’re no longer using the variable defined in the vars section of the playbook.

5. Rerun the command below to inspect task argument values and verify the changes.

Below, the bash package is now being used as the value for the task argument.

6. Finally, run the redo debugger argument to restart the playbook and rerun the entire play.

This time, the task runs, as shown below. Notice that you get an ok status since the Bash package exists in the managed host’s repository.

Conclusion

Debugging playbooks can be a challenge, but Ansible provides tools to make the process easier. And in this article, you’ve learned how to use the command-line options and the Ansible debugger to help you step through your playbook and troubleshoot issues.

You also learned to get around the debugger’s arguments/commands to inspect and modify task arguments during playbook execution. At this point, you already have a fully functional Ansible environment and the knowledge required to start debugging your automation.

Why not try the Ansible debugger on some of your playbooks to Ansible debug network automation? You’ll find the Ansible debugger is an invaluable tool for troubleshooting issues and understanding the behavior of your automation.

Software system issues are parts and parcels of all software systems no matter how robust or efficient the system is. What this article will provide are basic troubleshooting tips for some common and frequently-occurring Ansible server configuration errors. Note that some error messages may not seem to point directly to the root cause—such errors may need a deeper investigation.

Overview

Ansible is a simple, yet effective open-source tool for deploying, managing, and combining multi-node software deployment. It also manages changes in the execution and configuration management of a system. Ansible is generally seen useful and some would even say that it’s better than other similar tools. However, the unexpected always happens and errors occur. Ansible configuration issues have been described below, first by identifying the root cause followed by troubleshooting tips to possibly address the problem. But before this section, let us have a look at some of the prerequisites of Ansible Configuration.

Prerequisites:

These are the prerequisites for running Ansible on your machine properly. Knowledge of these prerequisites is important for identifying solutions to the problems or issues, which might arise at any point of time.

• Note that Ansible can be installed in only one machine, and from this (also known as the Control Machine) it can manage multiple machines via the SSH protocol.
• The Control Machine needs to have Python 2.6 or 2.7 installed. As for the required OS, Debian, Red Hat, OS X, CentOS, or any of the Berkeley Software Distribution (BSD) are supported. Windows is not supported.
• Note that the Central Machine communicates with other machines via SSH. Usually, it uses sftp. If sftp is not available, you can use scp in Ansible.cfg.

Time to review common errors in Ansible configuration!

Want to Learn Python? Get Python Training

Fixing Issues with Ansible Configuration

Issue 1

The system throws an error message related to space issues in a command when you are trying to copy a script to the Oracle production servers then add the script to chkconfig (which means the system is auto-starting). The error message could look like the one below:

ERROR: Syntax Error while loading YAML script, ppili.yml

Note: The error may actually appear before this position: line 4, column 12

   - name: Copying ppili script
    copy: src=/ds1/scripts/ppili dest=/etc/init.d/ppili owner=root group=rootuser  

Root cause: As can be seen from the error message, the root cause is the indentation of – name.

Troubleshooting: You just need to address the indentation issue in the – hosts section. You could do that by entering either one of the following commands in the command line:

- hosts: oracle.com
  gather_facts: False
  su: yes
  su_user: rootuser
  tasks:
    - shell: russell	

Or

ansible-playbook --su --su-user=root --ask-su-pass playbook.yml

Issue 2

The system fails to find the required Python modules. In such case, the error message could look something like this:

failed: [somehost] => {"failed": true, "parsed": false}
invalid output was: Error: ansible requires a json module, none found!

Root cause: The system was unable to locate the required Python modules.

Troubleshooting: You just need to install the Python module with the help of the Raw module. You could use the following command:

ansible -m raw -a "yum -y install python-simplejson"

Issue 3

Host file issues or machine shut down. The error message in such a case could look like the one below:

fatal: [websrvr01] => {'msg': 'FAILED: [Errno -2] Name or service not known', 'failed': True}

Root cause: You could have committed a typo in the host file or someone has shut the server down.

Troubleshooting: Verify if the server has been shut down and also check the DNS name of the host file.

Issue 4

Login issues because of incorrect SSH keys

Root cause: This is a common issue. You are either passing the wrong keys or the key that you are passing have not been added to the SSH agent, if you have been using one.

Troubleshooting: First find out the SSH keys that have been added to the SSH agent already. To do that, you could use the command $ ssh-add –l and see an output like the one below:

2049 06:c9:5c:14:de:83:00:94:ec:15:e5:c9:4e:86:4f:a6 /Usersroot/speters/devroot/projectsroot/devops/ansible/keys/ansible (RSA)
2044 dd:3b:b8:2e:85:04:06:e9:ab:ff:a8:0a:c0:04:6e:d6 /Usersroot/speters/.vagrant.d/insecure_private_key (RSA)

Tip: If there are keys that you use frequently, think of making aliases for them and add them to a custom .ssh/config so they are automatically known to Ansible.

Need help? Ask an Ansible Expert now

Issue 5

Login issues due to missing key.

Root cause: If a user wants to access the host with a key pair, the user’s public key must be available in the server so that the connection is authenticated. In the case of SSH connection, the key must be made available in the .ssh/authorized_keys location. Any deviation from this practice will lead to an error.

Troubleshooting: To add the key to the .ssh/authorized_keys location, use the following command:

cd ~user
cat newkey.pub >> .ssh/authorized_keys

Alternatively, you can use the command ssh-copy-id from your local machine.

Note that adding keys manually can be a tedious and error-prone method. You should ideally aim to automate the task with the help of Ansible Role.

Issue 6

SSH agent is not running. It may be difficult to immediately identify the cause because Ansible will provide a generic failure message.

Root cause: Failing SSH agent may be the cause behind many generic error messages.

Troubleshooting: Verify that the SSH agent is running. To do that, use the following command:

export | grep SSH
SSH_AGENT_PID=14543
SSH_AUTH_SOCK=/tmp/ssh-U4z3bbdQJiqx/agent.14543
SSH_CLIENT='192.168.10.26 59808 11'
SSH_CONNECTION='192.169.10.26 59112 10.0.32.108 22'
SSH_TTY=/dev/pts/0

Issue 7

Unknown failures

Root cause: Ansible, for all its reputation of being a robust system, can also experience unknown, unidentified errors.

Troubleshooting: You can use the debug logging feature of Ansible, which is an extremely useful and effective way to find difficult-to-spot errors. When you use debug logging, it will show you the users and the scripts that are being executed.

Issue 8

Sudo failure

Root cause: You have changed the host name of the target host but have not changed the local host entry. Sudo looks up the host and tries to match the hostname with the entries done in the hosts. In case of a mismatch, you are going to get an error message.

Troubleshooting: In case you have recently changed the name of the host, verify first that after you have changed the host name of the target, you have also changed the localhost entry in /etc/hosts.

Issue 9

When you are executing an Ansible playbook, the control machine throws an error that the Ansible for Junos Operating System module is not a legal parameter. The error message could look like the one below:

ERROR: junos_install_config is not a legal parameter in an Ansible task or handler

Root cause: The Ansible control machine is unable to find the Ansible for Junos OS modules.

Troubleshooting: First, you need to download Ansible for Junos OS modules from the Ansible website. To download, use the command ansible-galaxy install command, and specify Juniper.junos. The command could look the one below:

 [root@ansible-cm]# ansible-galaxy install Juniper.junos

To enable the Playbook so that it can access and reference the installed modules, include the Juniper.junos role in the playbook play. The command could look something the one below:

---- name: Get Device Facts
  hosts: hostname
  roles:
  - Juniper.junos
  connection: local

Conclusion:

You need to note that the error messages may be ambiguous and misleading at times. What is stated in the error message may not always reflect what is wrong (although these messages are always good starting points). Even in the case of error messages described above, they may vary depending on a lot of factors. The good thing about cracking problems is that when you troubleshoot a number of issues, you gain the experience which you can use to fix other concerns. However, you will be able to prevent a lot of issues if:

• you keep the host name and the host entries synced,
• have the required version of Python installed; and
• have the SSH agent updated and coordinated.

These three steps ensure that a lot of possible Ansible configuration issues can be prevented right from the start.

Other tutorials you might be interested in:

• Deploying a Ruby Application with Ansible
• Wrapping a LAMP project into Vagrant with Ansible
• Automating Network Mastering Scenarios for Amazon VPC with Ansible

Author’s Bio:

Kaushik Pal has more than 16 years of experience as a technical architect and software consultant in enterprise application and product development. He has interest in new technology and innovation, along with technical writing. His main focus is web architecture, web technologies, Java/J2EE, Open source, big data, cloud, and mobile technologies.You can find more of his work at www.techalpine.com and you can email him at techalpineit@gmail.com or kaushikkpal@gmail.com