# Python 2.4 compatibility and the user module

**URL:** <https://forum.ansible.com/t/python-2-4-compatibility-and-the-user-module/11514>\
**Category:** Ansible Project\
**Created:** [May 8, 2012, 4:03pm UTC](https://forum.ansible.com/t/python-2-4-compatibility-and-the-user-module/11514 "2012-05-08T16:03:21Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![John\_Kleint](https://avatars.discourse-cdn.com/v4/letter/j/df705f/32.png) [@John\_Kleint](https://forum.ansible.com/u/John_Kleint)\
**Post date:** [May 8, 2012, 4:03pm UTC](https://forum.ansible.com/t/python-2-4-compatibility-and-the-user-module/11514/1 "2012-05-08T16:03:21Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![Michael\_DeHaan](https://avatars.discourse-cdn.com/v4/letter/m/c4cdca/32.png) [@Michael\_DeHaan](https://forum.ansible.com/u/Michael_DeHaan)\
**Post date:** [May 8, 2012, 4:32pm UTC](https://forum.ansible.com/t/python-2-4-compatibility-and-the-user-module/11514/2 "2012-05-08T16:32:02Z")

</div>

> 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.

---

<div class="post-metadata">

**Author:** ![Stephen\_Fromm](https://avatars.discourse-cdn.com/v4/letter/s/bbce88/32.png) [@Stephen\_Fromm](https://forum.ansible.com/u/Stephen_Fromm)\
**Post date:** [May 8, 2012, 5:18pm UTC](https://forum.ansible.com/t/python-2-4-compatibility-and-the-user-module/11514/3 "2012-05-08T17:18:21Z")

</div>

> > 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