geerlingguy / docker-centos7-ansible Goto Github PK

One of my roles cannot (re)start a service unless the filesystem package is updated first.

I'm not sure why or what effect this has exactly, but the latest version of the filesystem package fixes it, and the service can then successfully be (re)started.

Here are the Travis tests (before, after) that show the problem, and the repo is here.

As of this point, the included version of ansible is 2.10.5. There are newer 3.x and 4.x packaged versions available to get 2.11+. There are also updates available for other dependencies as well. Merging #14 might kill two birds with one stone here.

In my small role https://github.com/stefangweichinger/ansible-rclone I use your images to run molecule tests.

In this issue stefangweichinger/ansible-rclone#80 and the resulting PR stefangweichinger/ansible-rclone#82 I added a check script template:

https://github.com/stefangweichinger/ansible-rclone/blob/master/templates/etc/ansible/facts.d/rclone.fact.j2

It should check if the binary exists and report back the variable "ansible_facts.ansible_local.rclone.installed".

In the ansible/molecule runs that variable is always "false" for the centos7 instances (at the 2nd run, sure, when the binary is there already), but when I login to the same instance and run the fact-script the variable is "true":

[root@instance-centos7 /]# /etc/ansible/facts.d/rclone.fact 
{
    "configured": true, 
    "installed": true, 
    "installed_version": "1.54.1"
}

Do you know the reason, did you see such a behavior as well?

I also tested your tag "python3", same behavior.

Maybe you have an idea here, thanks.

Currently any systemd operation fails on this image.
The issue is probably linked to this one
ansible/ansible#71528

There seems to be some changes on systemd-side which had some follow-up changes in Ansible, but even after updating to 2.10.4 the error persists. I can only assume that the additional modifications to make systemd work inside a container have to be adjusted...

Hello, I am getting this error while running
https://github.com/VladDm93/postgresql/actions/runs/3510277043/jobs/5884722508

fatal: [postgresql-12]: FAILED! => {"changed": false, "cmd": "/bin/systemctl", "msg": "Failed to get D-Bus connection: No such file or directory", "rc": 1, "stderr": "Failed to get D-Bus connection: No such file or directory\n", "stderr_lines": ["Failed to get D-Bus connection: No such file or directory"], "stdout": "", "stdout_lines": []}

I was getting similar errors before on others images such as .

geerlingguy/docker-centos8-ansible:latest
geerlingguy/docker-debian10-ansible:latest
geerlingguy/docker-ubuntu1804-ansible:latest
geerlingguy/docker-ubuntu2004-ansible:latest

I was able to fix those errors thanks to replies on this issue
geerlingguy/docker-debian11-ansible#4

but for some reason centos7 version keeps getting errors.

Leveraging geerlingguy/docker-centos7-ansible:python3, my Molecule test was failing as pip couldn't be found in the environment. After a little searching, it appears there is a pathing issue in the container:

In the latest tag, which uses Python 2, pip is correctly linked:

One thing to note is the python3 tag was pushed 2 years ago whereas the latest tag was last pushed 4 months ago. https://hub.docker.com/r/geerlingguy/docker-centos7-ansible/tags

https://github.com/geerlingguy/docker-centos7-ansible/blob/master/Dockerfile#L29 was added within the last 10 months, which installs/updates pip, and likely fixes the path resolution as a side effect. I believe the fix would be to pin a python3 tag with the existing Dockerfile (supplanting python3 for python2). Not sure how that was done 2 years ago, I only see latest in CI, so not sure what PR to suggest.

To resolve the error in geerlingguy/docker-centos7-ansible:python3 as tagged today, I ran python3 -m pip install -U pip inside the container and pip was then properly linked.

I recently switched this image to Python 3 by default... and while 95% of the stuff I do in Ansible works great on Python 3 (and 100% of it on Ubuntu or CentOS 8 at this point), apparently the yum module does not support Python 3 at all.

So builds of certain projects started failing :(

See, for example: ansible/ansible#67699

I saw this is also in the centos systemd instructions but Im not sure what it actually does?

It seems that Python 2.7 and CentOS 7 are hitting the end of the line...

Step 8/13 : RUN pip install $pip_packages
 ---> Running in 5a8dbe28274c
DEPRECATION: Python 2.7 reached the end of its life on January 1st, 2020. Please upgrade your Python as Python 2.7 is no longer maintained. pip 21.0 will drop support for Python 2.7 in January 2021. More details about Python 2 support in pip can be found at https://pip.pypa.io/en/latest/development/release-process/#python-2-support pip 21.0 will remove support for this functionality.
Collecting ansible
  Downloading ansible-4.10.0.tar.gz (36.8 MB)
    ERROR: Command errored out with exit status 1:
     command: /usr/bin/python -c 'import sys, setuptools, tokenize; sys.argv[0] = '"'"'/tmp/pip-install-SIuPkY/ansible/setup.py'"'"'; __file__='"'"'/tmp/pip-install-SIuPkY/ansible/setup.py'"'"';f=getattr(tokenize, '"'"'open'"'"', open)(__file__);code=f.read().replace('"'"'\r\n'"'"', '"'"'\n'"'"');f.close();exec(compile(code, __file__, '"'"'exec'"'"'))' egg_info --egg-base /tmp/pip-pip-egg-info-SgmwmG
         cwd: /tmp/pip-install-SIuPkY/ansible/
    Complete output (5 lines):
    /usr/lib64/python2.7/distutils/dist.py:267: UserWarning: Unknown distribution option: 'project_urls'
      warnings.warn(msg)
    /usr/lib64/python2.7/distutils/dist.py:267: UserWarning: Unknown distribution option: 'python_requires'
      warnings.warn(msg)
    error in ansible setup command: 'install_requires' must be a string or list of strings containing valid project/version requirement specifiers
    ----------------------------------------
ERROR: Command errored out with exit status 1: python setup.py egg_info Check the logs for full command output.

I think the easiest path forward would be to stick to an older Ansible release on CentOS 7. I tried upgrading to Python 3 in the past but that broke oh-so-many things relating to package management, and as Red Hat seems to have divested itself of supporting CentOS for the use cases I have for it (I've moved on to Rocky/Alma Linux), I don't know if I care to try hacking together a way to run Ansible in CentOS 7 anymore, besides locking in older versions and maybe ending active maintenance on this particular image.

Hello @geerlingguy,

Thanks for this container !

I notice that when running docker-centos7-ansible like this:

docker run --detach --privileged  geerlingguy/docker-centos7-ansible:latest

/var/run/nologin is present and prevents SSH login. Is it voluntary ?

Hi,

I'm working with docker-centos7-ansible and docker-ubuntu1604-ansible for testing my roles. It's fantastic!

I use "import_tasks" on ansible yml file. This works fine on ubuntu container but on centos container fails.
Ubuntu image is build with ansible 2.4 version and centos image is build wiht ansible 2.3.

I built Centos image from Dockerfile and works fine because the image was created with ansible 2.4.

I don't know what is the best practice for update the image...
I should fork your project and management my own image?
We can trigger periodically a build for the image?

See: geerlingguy/docker-ubuntu1804-ansible#4

Basically, maintain latest as-is, but add a testing branch which includes Ansible plus:

• yamllint
• ansible-lint
• flake8
• testinfra
• molecule

Hey, first of all great image.
I had some trouble getting it to work, ansible could not connect to the remote host per ssh.
After i installed openssh-clients with yum it worked.
Is the error on my side or should we add the ssh clients lib in the dockerfiles yum install section?
greetings

Same as all my other image repos... just haven't had the time yet to get them all updated. Might help with #12 for those running into this issue.

I have been using this image from dockerhub ( https://hub.docker.com/r/geerlingguy/docker-centos7-ansible ) extensively for molecule testing.
I recently upgraded to an m1 with arm64.
Using the same image with rest of the things kept same as before, I hit multiple issues.
One of them was
"stderr": "qemu: uncaught target signal 6 (Aborted) - core dumped", "stderr_lines": [ "qemu: uncaught target signal 6 (Aborted) - core dumped" ], "stdout": "[0.019s][warning][os,container] Duplicate cpuset controllers detected. Picking /sys/fs/cgroup/cpuset, skipping /sys/fs/cgroup/cpuset.\n#\n# A fatal error has been detected by the Java Runtime Environment:\n#\n# SIGSEGV (0xb) at pc=0x000000401e955282, pid=41174, tid=41211\n#\n# JRE version: OpenJDK Runtime Environment (Red_Hat-11.0.16.0.8-1.el7_9) (11.0.16+8) (build 11.0.16+8-LTS)\n# Java VM: OpenJDK 64-Bit Server VM (Red_Hat-11.0.16.0.8-1.el7_9) (11.0.16+8-LTS, mixed mode, sharing, tiered, compressed oops, g1 gc, linux-amd64)\n# Problematic frame:\n# J 207 c1 java.util.HashMap.afterNodeInsertion(Z)V [email protected] (1 bytes) @ 0x000000401e955282 [0x000000401e955240+0x0000000000000042]\n#\n# No core dump will be written. Core dumps have been disabled. To enable core dumping, try \"ulimit -c unlimited\" before starting Java again\n#\n# An error report file with more information is saved as:\n# //hs_err_pid41174.log\nCompiled method (c1) 1368 88 3 java.util.HashMap::putVal (300 bytes)\n total in heap [0x000000401e921690,0x000000401e923040] = 6576\n relocation [0x000000401e921808,0x000000401e921948] = 320\n main code [0x000000401e921960,0x000000401e922b00] = 4512\n stub code [0x000000401e922b00,0x000000401e922bd0] = 208\n metadata [0x000000401e922bd0,0x000000401e922bd8] = 8\n scopes data [0x000000401e922bd8,0x000000401e922df0] = 536\n scopes pcs [0x000000401e922df0,0x000000401e922fd0] = 480\n dependencies [0x000000401e922fd0,0x000000401e922fd8] = 8\n nul chk table [0x000000401e922fd8,0x000000401e923040] = 104\nCompiled method (c1) 1372 88 3 java.util.HashMap::putVal (300 bytes)\n total in heap [0x000000401e921690,0x000000401e923040] = 6576\n relocation [0x000000401e921808,0x000000401e921948] = 320\n main code [0x000000401e921960,0x000000401e922b00] = 4512\n stub code [0x000000401e922b00,0x000000401e922bd0] = 208\n metadata [0x000000401e922bd0,0x000000401e922bd8] = 8\n scopes data [0x000000401e922bd8,0x000000401e922df0] = 536\n scopes pcs [0x000000401e922df0,0x000000401e922fd0] = 480\n dependencies [0x000000401e922fd0,0x000000401e922fd8] = 8\n nul chk table [0x000000401e922fd8,0x000000401e923040] = 104\nCould not load hsdis-amd64.so; library not loadable; PrintAssembly is disabled\n#\n# If you would like to submit a bug report, please visit:\n# https://bugzilla.redhat.com/enter_bug.cgi?product=Red%20Hat%20Enterprise%20Linux%207&component=java-11-openjdk\n#"

Having arm64 architecture support for this image (and the other docker ansible images) will be very useful. It'll bypass qemu so hopefully this issue will be gone too.