We Keep Coding

winrm not found error for ansible-packer provisioning

I am using gitlab for deployment and Packer for image automation and ansible for configuration management for creating windows image.
when I am trying to call ansible provisioner from packer it is throwing below error:
<default> Attempting python interpreter discovery
[WARNING]: Unhandled error in Python interpreter discovery for host default:
Using module file /usr/lib/python3.9/site-packages/ansible/modules/command.py
winrm or requests is not installed: No module named 'winrm'
Pipelining is enabled.
fatal: [default]: FAILED! => {
"msg": "winrm or requests is not installed: No module named 'winrm'"
also I am getting below ansible configs in output :
ansible-playbook 2.10.5
config file = None
configured module search path = ['/root/.ansible/plugins/modules', '/usr/share/ansible/plugins/modules']
ansible python module location = /usr/lib/python3.9/site-packages/ansible
executable location = /usr/bin/ansible-playbook
python version = 3.9.5 (default, Nov 24 2021, 21:19:13)
No config file found; using defaults
setting up inventory plugins
setting up inventory plugins
host_list declined parsing /tmp/packer-provisioner-ansible87uu7yu as it did not pass its verify_file() method
script declined parsing /tmp/packer-provisioner-ansible87uu7yu as it did not pass its verify_file() method
Can someone please suggest where it is getting stuck.. since I am already using winrm.ps1 for winrm installation before this ansible runs.. but it is still failing..
also .. I am not sure if ansible is failing for python or winrm

Launching postgres fixture with pytest fails due to LC_ALL cannot change locale error

I have been scratching my head for few hours as I can't figure how to debug the following problem.
Context
I am using pytest and pytest-postgresql on a project, to learn TDD.
pytest-postgres enables me to use a fixture that implements a postgresql database in the /tmp directory on a socket.
This used to work well, and is explained in:
the docs https://pypi.org/project/pytest-postgresql/
this article: 
https://medium.com/#geoffreykoh/fun-with-fixtures-for-database-applications-8253eaf1a6d.
The problem
A sample test which use that fixture produces the following error:
> raise CalledProcessError(retcode, process.args,
output=stdout, stderr=stderr)
E subprocess.CalledProcessError: Command '['/usr/bin/pg_ctl',
'initdb', '--pgdata', '/tmp/postgresqldata.12836',
'-o', '--username=postgres --auth=trust']' returned non-zero exit status 1.
/usr/lib/python3.8/subprocess.py:512: CalledProcessError
/usr/lib/python3.8/subprocess.py:512: CalledProcessError
---------------------------- Captured stderr setup -----------------------------
sh: warning: setlocale: LC_ALL: cannot change locale (C.UTF-8)
sh: warning: setlocale: LC_ALL: cannot change locale (C.UTF-8)
sh: warning: setlocale: LC_ALL: cannot change locale (C.UTF-8)
initdb: error: invalid locale settings; check LANG and LC_* environment variables
pg_ctl: database system initialization failed
=========================== short test summary info ============================
ERROR tests/adapters/test_orm.py::test_sample - subprocess.CalledProcessError...
=============================== 1 error in 0.11s ===============================
What I have tried
resetting locale
reinstall postgres
reinstall pytest-postgres
reinstall psycopg2-binary
I also launched a similar command directly from the shell
It does not trigger such an error:
(myproject) [john#linuxbox ~/myproject]$ initdb --pgdata /tmp/postgresqldata.123450 --username=postgres --auth=trust
The files belonging to this database system will be owned by user "john".
This user must also own the server process.
The database cluster will be initialized with locales
COLLATE: fr_FR.UTF-8
CTYPE: fr_FR.UTF-8
MESSAGES: en_US.UTF-8
MONETARY: fr_FR.UTF-8
NUMERIC: fr_FR.UTF-8
TIME: fr_FR.UTF-8
The default database encoding has accordingly been set to "UTF8".
The default text search configuration will be set to "french".
Data page checksums are disabled.
creating directory /tmp/postgresqldata.123450 ... ok
creating subdirectories ... ok
selecting dynamic shared memory implementation ... posix
selecting default max_connections ... 100
selecting default shared_buffers ... 128MB
selecting default time zone ... Europe/Paris
creating configuration files ... ok
running bootstrap script ... ok
performing post-bootstrap initialization ... ok
syncing data to disk ... ok
Success. You can now start the database server using:
pg_ctl -D /tmp/postgresqldata.123450 -l logfile start
Questions:
Are the two commands below equivalent ?
from pytest:
Command '['/usr/bin/pg_ctl', 'initdb', '--pgdata', '/tmp/postgresqldata.12836',
'-o', '--username=postgres --auth=trust']'
from the shell:
initdb --pgdata /tmp/postgresqldata.123450 --username=postgres --auth=trust
any idea of where should I look next to solve this ?
Thanks!
Edit 1
Thanks a lot for your comments.
output of $ locale -a
C
en_US.utf8
fr_FR.utf8
POSIX
pytest-postgresql is on 2.5.1:
(myproject) [john#linuxbox ~/myproject]$ cat Pipfile.lock | grep pytest-postgresql -A 6
"pytest-postgresql": {
"hashes": [
"sha256:e2a998c85cd7e917c593292182e523d620018887fadde733c932a70c3825b8bd"
],
"index": "pypi",
"version": "==2.5.1"
},
I'm on Archlinux and use postgres 12.4.
Edit 2
I think I found the reason, I could reproduce the error from the shell.
following the archwiki, I did this:
[postgres#linuxbox ~]$ initdb --locale=C.UTF-8 -E UTF-8 -D /var/lib/postgres/data
The files belonging to this database system will be owned by user "postgres".
This user must also own the server process.
initdb: invalid locale name "C.UTF-8"
It seems C.UTF-8 is Debian specific, hence the error on Archlinux.
This issue seems closely related:
https://github.com/ClearcodeHQ/pytest-postgresql/issues/338

uWSGI will not run in mixed Python environment in order to operate correctly with nginx and run Django app

Environment: Ubuntu 16.04 (with system Python at 2.7.12) running in Vagrant/Virtualbox on Windows 10 host
Python Setup: System python verified by doing python -V with no virtualenv's activated. Python 3.5 is also installed, and I've done pipenv --three to create the virtualenv for this project. Doing python -V within the activated virtualenv (pipenv shell to activate) shows Python 3.5.2.
Additional Background: I'm developing a Wagtail 2 app. Wagtail 2 requires Django 2 which, of course, requires Python 3. I have other Django apps on this machine that were developed in Django 1.11/Python 2.7 and are served by Apache. We are moving to Django 2/Python 3 for development going forward and are moving to nginx/uWSGI for serving the apps.
I have gone through many tutorials/many iterations. All Vagrant port mapping is set up fine with nginx serving media/static files and passing requests upstream to the Django app on a unix socket, but this is giving a 502 Gateway not found error because uWSGI will not run correctly. Therefore, right now I'm simply running the following from the command line to try to get uWSGI to run: uwsgi --ini /etc/uwsgi/sites/my_site.com.ini. This file contains:
[uwsgi]
uid = www-data
gid = www-data
plugin = python35
# Django-related settings
# the base directory (full path)
chdir=/var/sites/my_site
# Django's wsgi file
wsgi-file = my_site.wsgi
# the virtualenv (full path)
virtualenv=/root/.local/share/virtualenvs/my_site-gmmiTMID
# process-related settings
# master
master = True
# maximum number of worker processes
processes = 10
# the socket (use the full path to be safe)
socket = /tmp/my_site.sock
# clear environment on exit
vacuum = True
I've tried installing uWSGI in the following ways:
system-wide with pip install uwsgi as well as pip3 install uwsgi
using apt-get install uwsgi uwsgi-plugin-python3
I've ensured that only one install is in place at a time by uninstalling any previous uwsgi installs. The latter install method places uwsgi-core in usr/bin and also places in usr/bin shortcuts to uwsgi, uwsgi_python3, and uwsgi_python35.
In the .ini file I've also tried plugin = python3. I've also tried from the command line:
uwsgi_python3 --ini /etc/uwsgi/sites/my_site.com.ini
uwsgi_python35 --ini /etc/uwsgi/sites/my_site.com.ini
I've tried executing the uwsgi ... .ini commands from both within the activated virtual environment and with the virtualenv deactivated. Each of the three command line uwsgi ... .ini executions (uwsgi ..., uwsgi_python3 ... and uwsgi_python35 ...) DO cause the .ini file to be executed, but each time I'm getting the following error (the last two lines of the following statements):
[uwsgi] implicit plugin requested python35
[uWSGI] getting INI configuration from /etc/uwsgi/sites/my_site.com.ini
*** Starting uWSGI 2.0.12-debian (64bit) on [Wed Mar 7 03:54:44 2018] ***
compiled with version: 5.4.0 20160609 on 31 August 2017 21:02:04
os: Linux-4.4.0-116-generic #140-Ubuntu SMP Mon Feb 12 21:23:04 UTC 2018
nodename: vagrant-ubuntu-trusty-64
machine: x86_64
clock source: unix
pcre jit disabled
detected number of CPU cores: 2
current working directory: /vagrant/my_site
detected binary path: /usr/bin/uwsgi-core
setgid() to 33
setuid() to 33
chdir() to /var/sites/my_site
your processes number limit is 7743
your memory page size is 4096 bytes
detected max file descriptor number: 1024
lock engine: pthread robust mutexes
thunder lock: disabled (you can enable it with --thunder-lock)
uwsgi socket 0 bound to UNIX address /tmp/my_site.sock fd 3
Python version: 3.5.2 (default, Nov 23 2017, 16:37:01) [GCC 5.4.0 20160609]
Set PythonHome to /root/.local/share/virtualenvs/my_site-gmmiTMID
Fatal Python error: Py_Initialize: Unable to get the locale encoding
ImportError: No module named 'encodings'
If I go into the Python command line within the activated virtualenv and do import encodings, it imports fine (no message - just comes back to command line). A search for this particular error has turned up nothing of use. Any idea why the ImportError: No module named 'encodings' is coming up?
UPDATE - PROBLEM STILL OCCURRING
I'm using pipenv, and it stores individual virtualenvs in the /home/username/.local/share/virtualenvs folder. Though I was able to start uWSGI from the command line by executing the uWSGI config file as the vagrant user (see comment below), I have still not been able start the service with /home/vagrant/.local/share/virtualenvs/my_venv in the uWSGI config file. I tried adding the vagrant user to the www-data group and adding the www-data user to the vagrant group. I also put both read and execute permission for the world on the whole path (including the individual venv), but the uWSGI service will still not start.
A HACKISH WORKAROUND
I did finally get the uWSGI service to start by copying the venv to /opt/virtualenvs/my_venv. I was then able to start the service with sudo service uwsgi start. Ownership of that whole path is root:root.
STILL LOOKING FOR A SOLUTION...
This solution is not optimal since I am now executing from a virtualenv that will have to be updated when the default virtualenv is updated since this location is not the default for pipenv, so I'm still looking for answers. Perhaps it is a Ubuntu permissions error, but I just can't find the problem.

It might be the problem with your virtual environment. Try the following
rm -rf /root/.local/share/virtualenvs/my_site-gmmiTMID
virtualenv -p python3 /root/.local/share/virtualenvs/my_site-gmmiTMID
source /root/.local/share/virtualenvs/my_site-gmmiTMID/bin/activate
pip install -r requirements.txt
and in uwsgi conf try to change
virtualenv=/root/.local/share/virtualenvs/my_site-gmmiTMID
to
home=/root/.local/share/virtualenvs/my_site-gmmiTMID
Reference:
http://uwsgi-docs.readthedocs.io/en/latest/Options.html#virtualenv

when cloudera manage agent installing, No module named cmf.alternatives error occured

I am installing cloudera cluster for first time.
On the Cluster Installing page, Show some messages like:
Installation failed. Failed to receive heartbeat from agent.
Ensure that the host's hostname is configured properly.
Ensure that port 7182 is accessible on the Cloudera Manager server (check firewall rules).
Ensure that ports 9000 and 9001 are free on the host being added.
Check agent logs in /var/log/cloudera-scm-agent/ on the host being added (some of the logs can be found in the installation details).
Then in the log file, I found:
[21/Oct/2014 05:29:54 +0000] 9155 MainThread agent ERROR Failed to connect to previous supervisor.
.....
SystemExit: 2
In the /var/log/cloudera-scm-agent/cloudera-scm-agent.out file, I found:
[21/Oct/2014 11:29:15 +0000] 1658 MainThread agent INFO Logging to /var/log/cloudera-scm-agent/cloudera-scm-agent.log
Error: could not find config file /var/run/cloudera-scm-agent/supervisor/supervisord.conf
For help, use /usr/lib64/cmf/agent/src/cmf/agent.py -h
....
Session terminated, killing shell... ...killed.
And I run : /usr/lib64/cmf/agent/src/cmf/agent.py -h
The System tell me :
/usr/lib64/cmf/agent/src/cmf/agent.py:24: DeprecationWarning: the sha module is deprecated; use the hashlib module instead
import sha
Traceback (most recent call last):
File "/usr/lib64/cmf/agent/src/cmf/agent.py", line 40, in <module>
import cmf.alternatives
ImportError: No module named cmf.alternatives
My ENV is: centos 6.5, Python 2.6.6, Cloudera manage server is 5.2
So, I want to know which module/modules would be installed to fix this error.
Or How to config to use the cmf module in the installion?
And where I can find a doc which describe the python for the cloudera?
Thank a lot.

Hi you can simply follow the instructions, replace sha with hashlib and try again.
...
# import sha
import hashlib
# and use hashlib.sha1 instead of sha.sha in the following code
hashlib.sha1(...)
...

Installing uwsgi with plugins using 'pip'

I installed uwsgi using pip install uwsgi.
When I run uwsgi, I get a couple of errors. The command I'm running is uwsgi --master --emperor /etc/uwsgi/apps-enabled --die-on-term --uid www-data --gid www-data.
It appears that I'm missing the http and python plugins:
[uWSGI] getting INI configuration from component_tracking_test.ini
open("./http_plugin.so"): No such file or directory [core/utils.c line 3347]
!!! UNABLE to load uWSGI plugin: ./http_plugin.so: cannot open shared object file: No such file or directory !!!
open("./python_plugin.so"): No such file or directory [core/utils.c line 3347]
!!! UNABLE to load uWSGI plugin: ./python_plugin.so: cannot open shared object file: No such file or directory !!!
[emperor] removed uwsgi instance component_tracking_test.ini
How do I install the required plugins given that I have installed uwsgi via pip?

When I add "--binary-path /usr/local/bin/uwsgi" (change path to your wsgi bin) to the command, the error went away.
from the docu
binary-path
Argument: string
Force binary path.
If you do not have uWSGI in the system path you can force its path with this option to
permit the reloading system and the Emperor to easily find the binary to execute.

I just had a similar problem and the reason was that I was running sudo uwsgi, not realizing that sudo won't respect the PATH and will launch the system-wide uwsgi. See this answer.