Open baby-gnu opened 2 years ago
This could be related: https://github.com/saltstack/salt/issues/61131 I would recommend you use the same crypto library on your master and minions. Since you're using Windows, I would recommend sticking with pycryptodome since m2crypto is tricky to install on Windows.
That's quite unfortunate since m2crypto
was the solution for the unreadable master.pem
key.
So, in some situation it's better to have m2crypto
and in other it should be pycryptodome
.
The solution is not simple to avoid manual intervention on all faulty minions :thinking:
Description
On some minions, the service can't start and the logs are filled with:
This is not systematic.
Setup
This is a normal installation of the minion for windows without doing anything special.
Steps to Reproduce the behavior
Expected behavior
The service should start correctly without any error in the logs
Screenshots
Here are some logs:
Versions Report
salt --versions-report
```yaml Salt Version: Salt: 3004.1 Dependency Versions: cffi: 1.14.6 cherrypy: 18.6.1 dateutil: 2.8.1 docker-py: Not Installed gitdb: 4.0.7 gitpython: Not Installed Jinja2: 2.10.1 libgit2: Not Installed M2Crypto: Not Installed Mako: 1.1.4 msgpack: 0.6.2 msgpack-pure: Not Installed mysql-python: Not Installed pycparser: 2.20 pycrypto: Not Installed pycryptodome: 3.10.1 pygit2: Not Installed Python: 3.8.8 (tags/v3.8.8:024d805, Feb 19 2021, 13:18:16) [MSC v.1928 64 bit (AMD64)] python-gnupg: 0.4.7 PyYAML: 5.4.1 PyZMQ: 19.0.0 smmap: 4.0.0 timelib: 0.2.4 Tornado: 4.5.3 ZMQ: 4.3.2 System Versions: dist: locale: cp1252 machine: AMD64 release: 10 system: Windows version: 10 10.0.19041 SP0 Multiprocessor Free ```Additional context
I had the same issue on the master some time ago and found that it was caused by some checks in pycrtodome.
According to the source M2Crypto seems the prefered one and may be installed instead of pycrptodome, right?
Other reports were closed because it's hard to reproduce what cause the pycrotodome to reject the generated key:
40889