I tried running the user module against my RHEL5 hosts, and discovered
it uses Python's spwd (shadow password) module, which is only
available on Python 2.5+.
Is Python 2.4 compatibility on managed nodes a design goal?
If so:
Unfortunately it doesn't seem like there's a separate 2.4-compatible
spwd module. However, a cursory examination of the user module
suggests we may be able to get away without spwd. We seem to only use
the password (hash) from it, and only then as a default for user_mod()
when the user doesn't provide one. I would assume usermod(8) keeps
your password if you don't give it a new one, but I also assume
somebody went out of their way to use spwd for a reason.
If not:
It would be great for newbs like myself to have step-by-step
instructions for installing Python 2.6+ and getting Ansible to use
it. I noticed modules are still hard-coded to /usr/bin/python, and
I'm not sure everyone can just change that to 2.6.
I tried running the user module against my RHEL5 hosts, and discovered
it uses Python’s spwd (shadow password) module, which is only
available on Python 2.5+.
Anything like that should be guarded in a try/except and the relevant parts of the code not supported without
that module should not be run.
In other words:
HAS_FOO=True
try:
import foo
except:
HAS_FOO=False
if HAS_FOO:
some logic …
Is Python 2.4 compatibility on managed nodes a design goal?
If so:
Unfortunately it doesn’t seem like there’s a separate 2.4-compatible
spwd module. However, a cursory examination of the user module
suggests we may be able to get away without spwd. We seem to only use
the password (hash) from it, and only then as a default for user_mod()
when the user doesn’t provide one. I would assume usermod(8) keeps
your password if you don’t give it a new one, but I also assume
somebody went out of their way to use spwd for a reason.
try “git blame” to see who. Perhaps not.
If not:
It would be great for newbs like myself to have step-by-step
instructions for installing Python 2.6+ and getting Ansible to use
it. I noticed modules are still hard-coded to /usr/bin/python, and
I’m not sure everyone can just change that to 2.6.
First part doesn’t apply, needs to support python 2.4 on the nodes.
modules using /usr/bin/python should probably be changed to use env.
I tried running the user module against my RHEL5 hosts, and discovered
it uses Python’s spwd (shadow password) module, which is only
available on Python 2.5+.
Anything like that should be guarded in a try/except and the relevant parts of the code not supported without
that module should not be run.
In other words:
HAS_FOO=True
try:
import foo
except:
HAS_FOO=False
if HAS_FOO:
some logic …
That would work.
Is Python 2.4 compatibility on managed nodes a design goal?
If so:
Unfortunately it doesn’t seem like there’s a separate 2.4-compatible
spwd module. However, a cursory examination of the user module
suggests we may be able to get away without spwd. We seem to only use
the password (hash) from it, and only then as a default for user_mod()
when the user doesn’t provide one. I would assume usermod(8) keeps
your password if you don’t give it a new one, but I also assume
somebody went out of their way to use spwd for a reason.
try “git blame” to see who. Perhaps not.
Probably me. The reason it is there is to check whether to change the password to the new encrypted string. If hashed strings is the same, then the password does not need to be changed.
Without spwd, it will be difficult to make password change(s) idempotent. We could just change the password regardless of whether it is different.
sf