alternatives: should always change the link from auto to manual mode - never ported over to community.general

[life5ign]

Summary

This issue never got ported over, as far as I can tell; I can confirm that the alternatives module still doesn't set the mode to "manual, at least not when the alternative was already set to the correct path"

Please see original issue, as well as my new writeup, in which I confirm the issue is still present.

ansible/ansible#66598

Issue Type

Bug Report

Component Name

alternatives

Ansible Version

$ ansible --version
ansible [core 2.14.3]
  config file = /home/bryant/src/api_guys/ansible-deploy-vst/config/machines/localhost_owsus_aws.ansible.cfg
  configured module search path = ['/home/bryant/.ansible/plugins/modules', '/usr/share/ansible/plugins/modules']
  ansible python module location = /home/bryant/.pyenv/versions/3.10.0/envs/ansible-deploy-vst/lib/python3.10/site-packages/ansible
  ansible collection location = /home/bryant/.ansible/collections:/usr/share/ansible/collections
  executable location = /home/bryant/.pyenv/versions/ansible-deploy-vst/bin/ansible
  python version = 3.10.0 (default, Nov  2 2021, 13:53:11) [GCC 9.3.0] (/home/bryant/.pyenv/versions/3.10.0/envs/ansible-deploy-vst/bin/python3.10)
  jinja version = 3.1.2
  libyaml = False

Community.general Version

$ ansible-galaxy collection list community.general

# /home/bryant/.ansible/collections/ansible_collections
Collection        Version
----------------- -------
community.general 7.1.0  

# /home/bryant/.pyenv/versions/3.10.0/envs/ansible/lib/python3.10/site-packages/ansible_collections
Collection        Version
----------------- -------
community.general 6.4.0  

and, I'm using the updated version 7.1.0, which I just updated

ansible-config dump | grep COLLECTIONS                                                                                                                                    
COLLECTIONS_ON_ANSIBLE_VERSION_MISMATCH(default) = warning
COLLECTIONS_PATHS(default) = ['/home/bryant/.ansible/collections', '/usr/share/ansible/collections']
COLLECTIONS_SCAN_SYS_PATH(default) = True

Configuration

$ ansible-config dump --only-changed
ANSIBLE_FORCE_COLOR(/home/bryant/src/api_guys/ansible-deploy-vst/config/machines/localhost_owsus_aws.ansible.cfg) = True
CACHE_PLUGIN(/home/bryant/src/api_guys/ansible-deploy-vst/config/machines/localhost_owsus_aws.ansible.cfg) = jsonfile
CACHE_PLUGIN_CONNECTION(/home/bryant/src/api_guys/ansible-deploy-vst/config/machines/localhost_owsus_aws.ansible.cfg) = ~/.ansible/fact_cache
CACHE_PLUGIN_TIMEOUT(/home/bryant/src/api_guys/ansible-deploy-vst/config/machines/localhost_owsus_aws.ansible.cfg) = 86400
CALLBACKS_ENABLED(/home/bryant/src/api_guys/ansible-deploy-vst/config/machines/localhost_owsus_aws.ansible.cfg) = ['ansible.posix.profile_tasks']
CONFIG_FILE() = /home/bryant/src/api_guys/ansible-deploy-vst/config/machines/localhost_owsus_aws.ansible.cfg
DEFAULT_PRIVATE_KEY_FILE(/home/bryant/src/api_guys/ansible-deploy-vst/config/machines/localhost_owsus_aws.ansible.cfg) = /home/bryant/.ssh/ansible-control-node_rsa
DEFAULT_REMOTE_USER(/home/bryant/src/api_guys/ansible-deploy-vst/config/machines/localhost_owsus_aws.ansible.cfg) = ubuntu
DEFAULT_ROLES_PATH(/home/bryant/src/api_guys/ansible-deploy-vst/config/machines/localhost_owsus_aws.ansible.cfg) = ['/home/bryant/.ansible/roles', '/home/bryant/src/api_guys/ansible-deploy-vst/roles']
DEFAULT_STDOUT_CALLBACK(/home/bryant/src/api_guys/ansible-deploy-vst/config/machines/localhost_owsus_aws.ansible.cfg) = debug
DEFAULT_TIMEOUT(/home/bryant/src/api_guys/ansible-deploy-vst/config/machines/localhost_owsus_aws.ansible.cfg) = 10
DEFAULT_VAULT_IDENTITY(/home/bryant/src/api_guys/ansible-deploy-vst/config/machines/localhost_owsus_aws.ansible.cfg) = prod
DEFAULT_VAULT_PASSWORD_FILE(/home/bryant/src/api_guys/ansible-deploy-vst/config/machines/localhost_owsus_aws.ansible.cfg) = /home/bryant/src/api_guys/ansible-deploy-vst/vault_pass_from_env.sh
HOST_KEY_CHECKING(/home/bryant/src/api_guys/ansible-deploy-vst/config/machines/localhost_owsus_aws.ansible.cfg) = False
TRANSFORM_INVALID_GROUP_CHARS(/home/bryant/src/api_guys/ansible-deploy-vst/config/machines/localhost_owsus_aws.ansible.cfg) = always

OS / Environment

Ubuntu 22.04 LTS

Steps to Reproduce

- name: Configure php-fpm
  tags: php_fpm
  block:
    - name: Update alternatives for php-fpm
      community.general.alternatives:
        name: "{{ item.name }}"
        path: "{{ item.path }}"
        # this is the default, but we want to be very explicit: select this executable:
        state: selected
        # not needed, since we're no longer in auto mode
        # priority: "{{ item.priority }}"
      loop:
        # the socket that apache proxies requests to with fcgi
        - { name: php-fpm.sock, path: "/run/php/php{{ php_version }}-fpm.sock" }

Expected Results

I expect the mode to be "manual" on the server

Actual Results

but it is still "auto":

bryant@ip-172-31-3-109:~$ update-alternatives --get-selections | grep php
php                            auto     /usr/bin/php8.1
php-fpm.sock                   auto     /run/php/php8.1-fpm.sock

Code of Conduct

• I agree to follow the Ansible Code of Conduct

[ansibullbot]

Files identified in the description:

• plugins/modules/alternatives.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 @mulby
click here for bot help

[russoz]

Hi @life5ign thanks for your ticket (again). A couple of comments:

• The module documentation does not seem to be promising to set the mode to manual, so this is not a bug, but a feature request.
• Forcefully imposing one specific behaviour to all users in a module is something that must be supported with compelling arguments. Is it possible that some uses might not want to have the mode set to auto?

[life5ign]

Hello @russoz , thanks for the reply; the way I see it: if I'm selecting path for the command, it implies that it's manual, so it's contradictory for it to remain in auto mode, subject to change by the system; if I declare I want a state, ansible should ensure that the the system can't just change it to something else.

from man update-alternatives:

   Each link group is, at any given time, in one of two modes: automatic or manual.  When a group is in automatic mode, the alternatives system will automatically
   decide, as packages are installed and removed, whether and how to update the links.  In manual mode, the alternatives system will retain the choice of the
   administrator and avoid changing the links (except when something is broken).

   Link groups are in automatic mode when they are first introduced to the system.  If the system administrator makes changes to the system's automatic settings,
   this will be noticed the next time update-alternatives is run on the changed link's group, and the group will automatically be switched to manual mode.

This is why I consider it a bug that when I, as the admin, am specifying a certain file (the program) to be referred to by a name, ansible doesn't make this happen fully, in that it lets that name remain open to be changed to point to a different file, upon an upgrade, e.g. If I were setting this on the CLI, namely pointing a name to a given file, it would be set in manual mode; it would not be automatic at that point.

[russoz]

Hello @russoz , thanks for the reply; the way I see it: if I'm selecting path for the command, it implies that it's manual, so it's contradictory for it to remain in auto mode, subject to change by the system; if I declare I want a state, ansible should ensure that the the system can't just change it to something else.

Exactly my point: that is your understanding. I am not a regular user of alternatives (neither command nor module), so I cannot vouch for that, so whilst I appreciate the rationale you presented, I cannot help wonder that there might be other users out there who do not expect ansible to be forever responsible for the link group once it touches it.

The fact that the module author(s) thought of the auto/manual setting and did not decide to turn the link groups automatically into manual tells me that there was a different set of expectations to them.

from man update-alternatives:

   Each link group is, at any given time, in one of two modes: automatic or manual.  When a group is in automatic mode, the alternatives system will automatically
   decide, as packages are installed and removed, whether and how to update the links.  In manual mode, the alternatives system will retain the choice of the
   administrator and avoid changing the links (except when something is broken).

   Link groups are in automatic mode when they are first introduced to the system.  If the system administrator makes changes to the system's automatic settings,

I might be splitting hairs here, but assuming the wording is accurate and that the devil is int he details, I need to ask: by linking a group to one specific target (that might or might not be the same already in place), does that change "the system's automatic settings"? The sentence from the manual does not (update: I missed the negation the first time around) seem to necessarily indicate that updating the links should turn the group manual.

this will be noticed the next time update-alternatives is run on the changed link's group, and the group will automatically be switched to manual mode.

This is why I consider it a bug that when I, as the admin, am specifying a certain file (the program) to be referred to by a name, ansible doesn't make this happen fully, in that it lets that name remain open to be changed to point to a different file, upon an upgrade, e.g. If I were setting this on the CLI, namely pointing a name to a given file, it would be set in manual mode; it would not be automatic at that point.

We have two different states related to a link group: the target of the link(s) and the mode. Maybe what the module is missing is a parameter mode to allow admins to determine that behaviour.

[life5ign]

@russoz ok, thank you for explaining that my thoughts and beliefs are mine, that wasn't clear before. But we are on github, and I'm just an ansible user who is trying to be helpful to the community by copying this (call it whatever you want, I actually don't really care what it's called) over from a stale thread that I encountered. I don't have the time to go much into this, but it seems that you might?

I read the first and last sentences of your post, and I do think mode is necessary.

[russoz]

Not sure when I would be able to work on that, but this ticket clearly needs to be in the backlog.

[felixfontein]

Have you tried state=selected? state=present means "I don't care whether it's auto or not", while state=selected means "I want to have it selected, but not as auto".

[felixfontein]

Hmm, I see you mentioned state: selected in the issue description. So your report has nothing to do with the issue in ansible/ansible#66598 except a similar description, since the module in ansible/ansible never supported state=selected but only state=present (and the issue was asking to change the behavior of what state=present is).

In any case, if state=selected results in auto, then this is very likely a bug in the module.

[life5ign]

I'm turning off email notifications for this thread due to the extra attitude and rudeness brought to the table by the last two users who responded. Hopefully the ansible team can make up for this with more friendly people somehow. So no, I won't be seeing any replies below.

[felixfontein]

I'm sorry that you perceive our comments as rude. We try to triage issues to figure out what are actually bugs, what are wishes/feature requests, and what are user support questions. As the discussion in this issue shows this isn't usually so clear.

[russoz]

Apologies for giving you that impression, it was never the intention. That being said, as Felix has put it, we usually try to focus on the technical issue.

As to the issue at hand, I am glad we agreed on a way to move forward, despite your reservations with the language. And I meant what I wrote that this must be in the collection's backlog. Personally, I have been working on different modules lately and I cannot spare more bandwidth to add another one t this time, but hopefully will be able to do so in a not so distant future.

[russoz]

The param state was first introduced in 4.8.0. The reference I can find is #4576

[russoz]

Or the PR #4557

[russoz]

Actually, that state param PR came from a reported issue #4543 which seemed to point, in a first quick glance, to the problems caused by setting the alternatives mode to manual. But I definitely need to read it more carefully and run a couple of tests before drawing any conclusions.

[feyst]

Heey,
I'm running into the same problem as described above. The default for all alternatives seems to be automatic mode so there is currently no way using Ansible to set a specific version as active.
Much appreciation here if you could consider to fix the bug / build the feature.

[ttrafford]

In any case, if state=selected results in auto, then this is very likely a bug in the module.

The problem is that state=selected will be true if the alternative has already selected automatically. In that case no change is made and "auto" is still in force.

If, later in my play, another package which provides the same alternative (with a higher priority) is installed it will then become selected (still on auto).

Running the same play a second time results in community.general.alternatives changing the alternative, and at that point it will be set to "manual".

This breaks idempotency. Either a user will rely on the priority and state=present, or they will expect a specific alternative to be selected. The module needs to check not just the value of the link, but also make sure it is set to manual in the latter case to know if an update is required.