openbsd_pkg: failed in get_package_state(): Can't find inst:nmap

[ivomarino]

Summary

Fails to install packages. It's OK only for packages which have already been installed. Issue happens on OpenBSD 7.5 but also from 7.3 onwards.

Issue Type

Bug Report

Component Name

openbsd_pkg

Ansible Version

CFG_ANSIBLE_PACKAGE="ansible-core"
CFG_ANSIBLE_VERSION="2.16.6"

Community.general Version

$ ansible-galaxy collection list community.general

Collection        Version
----------------- -------
community.general 7.0.1

Configuration

$ ansible-config dump --only-changed
CONFIG_FILE() = None
PAGER(env: PAGER) = less

OS / Environment

Ansible machine: Darwin Kernel Version 23.4.0: Fri Mar 15 00:19:22 PDT 2024; root:xnu-10063.101.17~1/RELEASE_ARM64_T8112 arm64

Target: OpenBSD 7.5

Steps to Reproduce

- hosts: openbsd
  post_tasks:
    - name: openbsd_pkg
      community.general.openbsd_pkg: name=nmap state=latest
      tags: [ 'packages' ]

Expected Results

Install nmap, it fails with any other package also. OK only for packages which have already been installed. Issue happens on OpenBSD 7.5 but also from 7.3 onwards.

Actual Results

TASK [openbsd_pkg] *****************************************************************************************************************************************
fatal: [controller]: FAILED! => {"changed": false, "msg": "failed in get_package_state(): Can't find inst:nmap\n"}

Code of Conduct

• [X] I agree to follow the Ansible Code of Conduct

[ansibullbot]

Files identified in the description: None

If these files are incorrect, please update the component name section of the description or use the !component bot command.

click here for bot help

[ansibullbot]

Files identified in the description:

• plugins/modules/openbsd_pkg.py

If these files are incorrect, please update the component name section of the description or use the !component bot command.

click here for bot help

[ansibullbot]

cc @JoergFiedler @MacLemon @bcoca @dch @eest @jasperla @mekanix @opoplawski @overhacked @tuxillo click here for bot help

[eest]

Hello,

I tried to reproduce this on a freshly installed OpenBSD 7.5 (amd64) but am not able to, maybe there is something else going on at your machine?

This is what i have:

$ cat inventory.ini
[all:vars]
ansible_user=root
[openbsd]
192.168.10.109

... and:

$ cat playbook.yaml
- hosts: openbsd
  post_tasks:
    - name: openbsd_pkg
      community.general.openbsd_pkg: name=nmap state=latest
      tags: [ 'packages' ]

First attempt, the package is installed:

 ansible-playbook -i inventory.ini playbook.yaml

PLAY [openbsd] *******************************************************************************************************************************************************************************************

TASK [Gathering Facts] ***********************************************************************************************************************************************************************************
[WARNING]: Platform openbsd on host 192.168.10.109 is using the discovered Python interpreter at /usr/local/bin/python3.11, but future installation of another Python interpreter could change the
meaning of that path. See https://docs.ansible.com/ansible-core/2.16/reference_appendices/interpreter_discovery.html for more information.
ok: [192.168.10.109]

TASK [openbsd_pkg] ***************************************************************************************************************************************************************************************
changed: [192.168.10.109]

PLAY RECAP ***********************************************************************************************************************************************************************************************
192.168.10.109             : ok=2    changed=1    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0

Second attempt, no change:

ansible-playbook -i inventory.ini playbook.yaml

PLAY [openbsd] *******************************************************************************************************************************************************************************************

TASK [Gathering Facts] ***********************************************************************************************************************************************************************************
[WARNING]: Platform openbsd on host 192.168.10.109 is using the discovered Python interpreter at /usr/local/bin/python3.11, but future installation of another Python interpreter could change the
meaning of that path. See https://docs.ansible.com/ansible-core/2.16/reference_appendices/interpreter_discovery.html for more information.
ok: [192.168.10.109]

TASK [openbsd_pkg] ***************************************************************************************************************************************************************************************
ok: [192.168.10.109]

PLAY RECAP ***********************************************************************************************************************************************************************************************
192.168.10.109             : ok=2    changed=0    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0

Some more info from the macOS machine i run the test from:

ansible-galaxy collection list community.general

# /opt/homebrew/Cellar/ansible/9.4.0/libexec/lib/python3.12/site-packages/ansible_collections
Collection        Version
----------------- -------
community.general 8.5.0

ansible-config dump --only-changed
CONFIG_FILE() = None
EDITOR(env: EDITOR) = nvim
PAGER(env: PAGER) = less

[devongarde]

For what it's worth, I have the same problem (but for git). I'm running Ansible [core 2.15.4] on an OpenBSD 7.4 VM attempting to install git on a fresh OpenBSD 7.5 VM. Let me know if you want config / version info, etc..

[ivomarino]

As a workaround for now I run shell via ansible like this:

conf_shell: 
  - { cmd: 'pkg_add -I sudo bash zsh vim--no_x11 tree rsync-- mtr-- uptimed git curl wget htop ccze ncdu gnuwatch vnstat' }

- name: shell
  ansible.builtin.shell: '{{ item.cmd|default("") }}'
  args: '{{ item.args|default({}) }}'
  delegate_to: '{{ item.delegate_to|default(inventory_hostname) }}'
  loop: '{{ conf_shell|default([]) }}'
  tags: [ 'post', 'shell' ]

[renatoram]

It looks like pkg_info behavior changed at some point, making the openbsd_pkg.py code stop working properly.

In short: the stdout/stderr outputs of "pkg_info inst:PKGNAME" changed.

Given these scenarios:

• PKG1 is installed
• PKG2 is not installed

On OpenBSD 7.2

# pkg_info -Iq inst:PKG1 ; echo $?     
PKG1-5.2.5p2
0

As expected.

For a package that is NOT installed:

# pkg_info -Iq inst:PKG2 ; echo $?
1

No stdout or stderr, RC=1

On OpenBSD 7.5 instead

# pkg_info -Iq inst:PKG1 ; echo $?     
PKG1-5.2.5p2
0

As expected.

BUT for a package that is NOT installed:

# pkg_info -Iq inst:PKG2 ; echo $?
Can't find inst:PKG2
1

Note: "Can't find inst:PKG2" is the stderr output. THIS breaks the module, because the code assumes stderr to be always empty (if stderr -> module.fail_json) save for failing states.

The module code doesn't seem to look at the rc value at all. A combination of looking at the rc value and looking for the string "Can't find inst:PKGNAME" should be able to reliably tell if PKGNAME is installed.

[eest]

Note: "Can't find inst:PKG2" is the stderr output. THIS breaks the module, because the code assumes stderr to be always empty (if stderr -> module.fail_json) save for failing states.

Thank you for investigating the issue! If this indeed is the reason some people are having problems then please make sure you are running the latest openbsd_pkg code as this specific issue was fixed in https://github.com/ansible-collections/community.general/pull/6785 a while back.

That is probably the reason I was not able to reproduce it above.

[renatoram]

Will try, thanks. We tried looking at the module code but were probably checking the wrong branch.

[eest]

Given the previous helpful debugging of @renatoram (thanks!) and no further input from other reporters I think we can close this as fixed by the mentioned PR.

resolved_by_pr 6785