Package installs should not use latest.

[Maxxranger]

Dear all,

I get this advise by use the very nice lint feature of ansible-navigator

I already consulted the docs about ansible.builtin.dnf

Wat kind of data need to be used add the key/value "state:"

CLI:

[student@workstation playbook-review]$ ansible-navigator lint internet.yml -m stdout
package-latest: Package installs should not use latest.
internet.yml:6 Task/Handler: Install Software

 
Snippet:

  tasks:
    - name: Install Software
      ansible.builtin.dnf:
        name:
          - firewalld
          - httpd
          - mariadb-server
          - php
          - php-mysqlnd
        state: latest

Best regards,
Bert

[Travis]

@Maxxranger -

I'm not sure I 100% understand your question, but I think I know what you are asking. You want a playbook to install a package and ensure that it is present, but you don't want it to update to the "latest" version.

So if you want to make sure something is installed, in state you would have state: present this would install the package if it isn't there, but would leave the package alone if it was already installed. However, if you have state: latest what it does is install if it isn't there, but if it is there it will upgrade if upgrade is available.

What will happen though, without a version specified for a package, when installing it will always install the latest package available in the repository, so if the package needs to be installed, it will pull the latest package and the required dependencies.

[Chetan_Tiwary_]

@Travis from your last paragraph, I am able to deduce this summary for learners :

"If you do not specify a version for a package and you use an install state (e.g., present), the package manager will install whatever version is available in the repository at that time, and will pull required dependencies. However, it may not necessarily upgrade that package to newer versions in future unless you explicitly ask (e.g., by using state: latest or specifying version constraints). Because you didn’t fix the version, you are susceptible to installing a later version than you expect at installation time, and you may introduce changes if repository versions bump"

[Travis]

@Chetan_Tiwary_ -

You're 100% correct as I didn't fully explain the how/why things worked, but yes - what happens is when it is present it will ensure the package is installed and if not it installs it. When it installs the package it installs the latest version available in the repository that the system is subscribed. At time that the playbook is run, it might be version 5 if it is run today. Three months from now, the playbook is run on the same system and it is already installed so version 5 is what exists, however, a new system is also added to the inventory which doesn't have the application installed and it installs version 8 because that is now the latest version in the repository.

If the playbook instead used latest, if the package wasn't there, again, it would install the latest version on the second system, however, the first system that had it installed three months prior had already installed version 5, but since it is slatest it automatically upgrades the package to the "latest" which would now make it version 8.

You need to be very careful on how you choose to author playbooks with installations. One of the thing I did when I was in consulting and working on operational systems was to use "latest" in the playbooks because we had the systems subscribed to a Red Hat Satellite server. Pairing both Ansible and Satellite allowed for us to use latest and control updates. This allowed us to push out updates in a DEV/TEST environment and let them be tested for a while and then push and promote the content views to the correct lifecycle environment. So Satellite controlled the versions and what was available as the "latest" package. 

[Chetan_Tiwary_]

Thanks for confirming @Travis !

[TravellingKiwi]

Ah.
Now here in lies the part that most sites don't do. Actual management of what gets installed. aka. Patch Clusters

If you just rely on a single ever updating repo, you will indeed get what you describe. Different servers getting different versions of software. A real nightmare. I would suggest that any site that does this really doesn't care about having different versions installed, so it's a moot point anyway.

However if you care, and manage it correctly, you'll use a concept of 'Patch Clusters'. A point in time snapshot of all the packages that are current for your servers. Some sites will create these monthly. With Satellite you can use Content Views to do this. Or you can externalise it and make it a concept for more than just your RedHat Servers.

A server gets assigned to a particular patch cluster. Install the 'latest' and it'll get the exact same version as any other server that's also assigned to that patch cluster
At patching time, you simply update the patch cluster for the server, have a process that now updates to the particular repos, and update all. 
Scheduling, (i.e. do non-prod before prod etc) and implementation of how are left as an exercise for the brave or people with lots of time on their hands. As is the automation

[Chetan_Tiwary_]

@TravellingKiwi agree, Whenever you snapshot a software repository for patch management, enforce a clear process for urgent updates bcz snapshots can block critical security patches if not updated. If systems use “latest” but still point to outdated repo snapshots, you risk inconsistent versions. Strictly standardize repository assignments across all hosts and log package states so you always know which patch cluster a server belongs to. In containerized and cloud setups, prioritize image immutability rather than patching running systems.

[Chetan_Tiwary_]

@Maxxranger You are right about potential issues in production environment when using state:latest bcz it can affect the stability and cause unnecessary unknown changes in your system.

Using state:present is preferred to ensure the automation remains idempotent and predictable.

https://ansible.readthedocs.io/projects/lint/rules/package-latest/ 

[Maxxranger]

When will that also bieng repport by use of "ansible-navigator"?

1.
ansible-navigator run \
> -m stdout playbook.yml --syntax-check

2.
ansible-navigator run \
> -m stdout playbook.yml --check

[Travis]

@Maxxranger -

Not sure what you are trying to ask here. What I can tell you is --syntax-check will check the YAML formatting of the playbook and that is it. The --check is usually for smoke testing a playbook. Generally it will run through the tasks and modules and let you know what would be changed and done if actually run. However, some modules have the "check" mode stuff turned off or don't support so it could actually execute things and make changes when assuming that it is a check only.