{"id":9488,"date":"2025-02-06T01:05:00","date_gmt":"2025-02-06T06:05:00","guid":{"rendered":"https:\/\/www.both.org\/?p=9488"},"modified":"2025-02-06T06:11:56","modified_gmt":"2025-02-06T11:11:56","slug":"fixing-ansible-playbooks","status":"publish","type":"post","link":"https:\/\/www.both.org\/?p=9488","title":{"rendered":"Fixing Ansible playbooks"},"content":{"rendered":"
\r\n
\r\n \r\n <\/i>\r\n <\/a>\r\n <\/span>\r\n<\/div><\/div>\n

I’ve been using Ansible<\/a> for several years to perform different tasks on my many physical and virtual hosts. It’s an excellent tool for defining the state to be set on a number of computers. <\/p>\n\n\n\n

I have several playbooks I use frequently, one of which I use to perform post-installation personalization and configuration of physical and virtual Linux hosts. This PostInstall.yml playbook has worked well for several years. Until recently when it began throwing errors.<\/p>\n\n\n\n

The problem<\/h2>\n\n\n\n

The first time I would run it on a host, it would work as it should. But, if after a few weeks of testing and research on that host, I would run the playbook again to restore the configuration items in the playbook to their desired state, it would fail with this error.<\/p>\n\n\n\n

TASK [Install command line tools] ****************************************************\nfatal: [testvm1]: FAILED! => {\"changed\": false, \"failures\": [\"Packages for argument 'task' available, but not installed.\"], \"msg\": \"Failed to install some of the specified packages\", \"rc\": 1}<\/code><\/pre>\n\n\n\n
I inspected the failing task, reproduced here in part, but could find no problems with the structure or syntax.<\/p>\n\n\n\n
# Install command line tools\n- name: Install command line tools\n  dnf:\n    name:\n      - apcupsd\n      - atop\n      - bc\n      - clamav\n      - ddrescue\n<SNIP>\n      - whois\n    state: latest<\/code><\/pre>\n\n\n\n
I tried a number of different things to resolve the problem and none of them worked. Thinking that one of the packages was causing the problem,I even tried installing all of the packages using DNF on the command line. They all installed correctly with no problems.<\/p>\n\n\n\n
I’d been searching the Internet for clues and found one indication that this problem is due to an issue between DNF5 and the fact that the python3-libdnf5 package should be installed by default, but was not on the new installations. Installing that did not resolve the problem. <\/p>\n\n\n\n
Further research led me to a new (to me) tool.<\/p>\n\n\n\n
ansible-lint<\/h2>\n\n\n\n
The ansible-lint<\/a> tool, like most lint-style tools, is designed to promote best practices in syntax, tool usage, and structure. I installed it easily as it it’s in the Fedora repo.<\/p>\n\n\n\n
# dnf -y install python3-ansible-lint<\/strong><\/code><\/pre>\n\n\n\n
I immediately ran this tool against my playbook and it reported over 200 errors. Some were simple format errors that didn’t seem to effect the results, but were egregious offenses against the strict YAML formatting, such as improper indentation, trailing spaces, and more. Other failures turned out to be the ones causing my problem. <\/p>\n\n\n\n
I’ve only included a small bit of the output from this command here, but it gives you a good idea of what you’ll see in the output data stream. I used the –nocolor option to eliminate all the escape characters that contaminate the data, and the -p option to make the data stream easier to read. I’m using the original version of my file here with all its errors.  The revised version doesn’t have the “X-” prepending it. <\/p>\n\n\n\n
$ ansible-lint --nocolor -p X-PostInstall.yml 2&> ansible.log\n<SNIP>\nX-PostInstall.yml:150: fqcn[action-core]: Use FQCN for builtin module actions (copy).\nX-PostInstall.yml:154: yaml[octal-values]: Forbidden implicit octal value \"0774\"\nX-PostInstall.yml:158: yaml[indentation]: Wrong indentation: expected 8 but found 10\nX-PostInstall.yml:168: fqcn[action-core]: Use FQCN for builtin module actions (systemd).\nX-PostInstall.yml:172: yaml[trailing-spaces]: Trailing spaces\nX-PostInstall.yml:172: yaml[truthy]: Truthy value should be one of\nX-PostInstall.yml:173: yaml[truthy]: Truthy value should be one of\nX-PostInstall.yml:175: fqcn[action-core]: Use FQCN for builtin module actions (systemd).\nX-PostInstall.yml:179: yaml[trailing-spaces]: Trailing spaces\nX-PostInstall.yml:179: yaml[truthy]: Truthy value should be one of\nX-PostInstall.yml:180: yaml[truthy]: Truthy value should be one of\nX-PostInstall.yml:183: fqcn[action-core]: Use FQCN for builtin module actions (systemd).\nX-PostInstall.yml:187: yaml[truthy]: Truthy value should be one of\nX-PostInstall.yml:188: yaml[truthy]: Truthy value should be one of\nX-PostInstall.yml:203: fqcn[action-core]: Use FQCN for builtin module actions (copy).\nX-PostInstall.yml:203: risky-octal: `mode: 644` should have a string value with leading zero `mode: \"01204\"` or use symbolic mode.\nX-PostInstall.yml:207: yaml[colons]: Too many spaces after colon\nX-PostInstall.yml:207: yaml[trailing-spaces]: Trailing spaces\nX-PostInstall.yml:212: fqcn[action-core]: Use FQCN for builtin module actions (command).\nX-PostInstall.yml:212: no-changed-when: Commands should not change things if nothing needs doing.\nX-PostInstall.yml:217: fqcn[action-core]: Use FQCN for builtin module actions (systemd).\nX-PostInstall.yml:221: yaml[truthy]: Truthy value should be one of\nX-PostInstall.yml:228: fqcn[action-core]: Use FQCN for builtin module actions (systemd).\nX-PostInstall.yml:232: yaml[truthy]: Truthy value should be one of\nX-PostInstall.yml:233: yaml[truthy]: Truthy value should be one of\nX-PostInstall.yml:235: fqcn[action-core]: Use FQCN for builtin module actions (systemd).\nX-PostInstall.yml:239: yaml[truthy]: Truthy value should be one of\nX-PostInstall.yml:240: yaml[truthy]: Truthy value should be one of\nX-PostInstall.yml:249: fqcn[action-core]: Use FQCN for builtin module actions (copy).\nX-PostInstall.yml:249: risky-octal: `mode: 644` should have a string value with leading zero `mode: \"01204\"` or use symbolic mode.\nX-PostInstall.yml:253: yaml[colons]: Too many spaces after colon\nX-PostInstall.yml:257: fqcn[action-core]: Use FQCN for builtin module actions (copy).\nX-PostInstall.yml:257: risky-octal: `mode: 754` should have a string value with leading zero `mode: \"01362\"` or use symbolic mode.\nX-PostInstall.yml:261: yaml[colons]: Too many spaces after colon\n<SNIP>\nX-PostInstall.yml:1066: fqcn[action-core]: Use FQCN for builtin module actions (reboot).\nX-PostInstall.yml:1066: yaml[trailing-spaces]: Trailing spaces\nRead documentation for instructions on how to ignore specific rule violations.\n\nRule Violation Summary\ncount tag                     profile    rule associated tags\n    1 load-failure[not-found] min        core, unskippable\n    1 no-free-form            basic      syntax, risk\n    1 name[missing]           basic      idiom\n    5 var-naming[pattern]     basic      idiom\n    6 yaml[colons]            basic      formatting, yaml\n    1 yaml[comments]          basic      formatting, yaml\n    7 yaml[indentation]       basic      formatting, yaml\n    1 yaml[octal-values]      basic      formatting, yaml\n   39 yaml[trailing-spaces]   basic      formatting, yaml\n   28 yaml[truthy]            basic      formatting, yaml\n   12 name[casing]            moderate   idiom\n   16 package-latest          safety     idempotency\n    5 risky-octal             safety     formatting\n    7 no-changed-when         shared     command-shell, idempotency\n   67 fqcn[action-core]       production formatting\n\nFailed: 217 failure(s), 0 warning(s) on 2 files.\n                                              <\/code><\/pre>\n\n\n\n
The acronym FQCN stands for “fully qualified command name.” These messages are telling us to use the long Ansible commands such as ansible.builtin.copy instead of just copy. Without the -p option, we get more explicit descriptions that even indicate what we need to do to fix the error. The line numbers, 180, 183, and 187, allowed me to zero in on the errors very quickly.<\/p>\n\n\n\n
yaml[truthy]: Truthy value should be one of [false, true]\nX-PostInstall.yml:180\n\nfqcn[action-core]: Use FQCN for builtin module actions (systemd).\nX-PostInstall.yml:183 Use `ansible.builtin.systemd` or `ansible.legacy.systemd` instead.\n\nyaml[truthy]: Truthy value should be one of [false, true]\nX-PostInstall.yml:187<\/code><\/pre>\n\n\n\n
The “Truthy” errors are due to my use of “yes” or “no” instead of “true” or “false” in some of the logic variables and comparison tests. Because there are a lot of similar errors of each of the different types listed, I can use Vim<\/strong> or sed<\/a><\/strong> regular expressions to fix all like errors at once rather than dealing with them one at a time. <\/p>\n\n\n\n
The error that was causing the problem I encountered was when I used state: latest<\/strong> when installing new packages. I switched to state: present<\/strong>, added skip_broken: true<\/strong> to each task, and used the FQCN, ansible.builtin.dnf<\/strong>:. It now works perfectly both for new installs and old installs that needed a reset to the beginning state. The task now looks like this..<\/p>\n\n\n\n
# Install command line tools\n- name: Install command line tools\n  ansible.builtin.dnf:\n    name:\n      - apcupsd\n      - atop\n      - bc\n      - clamav\n      - ddrescue\n<SNIP>\n      - whois\n    state: present\n    skip_broken: true<\/code><\/pre>\n\n\n\n
Final comments<\/h2>\n\n\n\n
After fixing the problem — and many of the less critical errors — there were still many errors left in my playbook. I’m still working my way through all of them to ensure they’re all fixed and can’t cause future issues.<\/p>\n\n\n\n
The ansible-lint tool is easy to use and can find those pesky issues that can’t be easily seen by the mark I Eyeball. It also helped me learn to code my playbooks using syntax like FQCN for commands rather than short names, and using the present state rather than latest. It’s those cool little things that I needed to know that helped the most.<\/p>\n\n\n\n
Be sure to read the ansible-lint documentation becuase it has some interesting options including one that can allegedly fix many of the errors it encounters. I say “allegedly” because I haven’t yet tried this option. <\/p>\n\n\n\n
\n\n\n\n
Resources<\/h2>\n\n\n\n
I wrote the following articles here on Both.org to help you get started with Ansible if you haven’t already. <\/p>\n\n\n\n
    \n
  1. Ansible #1: My first day using Ansible<\/a><\/li>\n\n\n\n
  2. Ansible #2 How to create an Ansible Playbook<\/a><\/li>\n\n\n\n
  3. Ansible #3: Finishing our Ansible playbook to manage workstation and server updates<\/a><\/li>\n<\/ol>\n\n\n\n
    Here’s some articles to get you started with regular expressions (REGEX).<\/p>\n\n\n\n
      \n
    1. Regular Expressions #1: Introduction<\/a><\/li>\n\n\n\n
    2. Regular Expressions #2: An example<\/a><\/li>\n\n\n\n
    3. Regular Expressions #3: grep \u2014 Data flow and building blocks<\/a><\/li>\n\n\n\n
    4. Regular Expressions #4: Pulling it all together<\/a><\/li>\n<\/ol>\n\n\n\n
      <\/p>\n","protected":false},"excerpt":{"rendered":"
      I’ve been using Ansible for several years to perform different tasks on my many physical and virtual hosts.<\/p>\n","protected":false},"author":2,"featured_media":2813,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_lmt_disableupdate":"","_lmt_disable":"","footnotes":""},"categories":[295,5,158],"tags":[296,702,701],"class_list":["post-9488","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-ansible","category-linux","category-open-source","tag-ansible","tag-ansible-lint","tag-yaml"],"modified_by":"David Both","_links":{"self":[{"href":"https:\/\/www.both.org\/index.php?rest_route=\/wp\/v2\/posts\/9488","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.both.org\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.both.org\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.both.org\/index.php?rest_route=\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/www.both.org\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=9488"}],"version-history":[{"count":28,"href":"https:\/\/www.both.org\/index.php?rest_route=\/wp\/v2\/posts\/9488\/revisions"}],"predecessor-version":[{"id":9524,"href":"https:\/\/www.both.org\/index.php?rest_route=\/wp\/v2\/posts\/9488\/revisions\/9524"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.both.org\/index.php?rest_route=\/wp\/v2\/media\/2813"}],"wp:attachment":[{"href":"https:\/\/www.both.org\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=9488"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.both.org\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=9488"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.both.org\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=9488"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}