-
Notifications
You must be signed in to change notification settings - Fork 583
Description
I am really not sure if this is a bug in the Ansible module locale_gen.py, or if it is a bug in this role's configure.yml
Introduction
I am trying to create a database with collate C.UTF-8, which fails in the configure.yml. I am using Ubuntu, but I think this applies to Debian as well. This fails with the error "The locales you've entered is not available on your system.", see below.
- name: PostgreSQL | Ensure the locale for lc_collate and lc_ctype is generated | Debian
become: yes
locale_gen: name="{{ item }}" state=present
with_items:
- "{{ postgresql_locale }}"
- "{{ postgresql_ctype }}"
when: ansible_os_family == "Debian"
Possible fix:
when: ansible_os_family == "Debian" && item != "C.UTF-8"
How to reproduce
To check this on Ubuntu, create a playbook with a construct that mimics configure.yml, you can call it collate_check.yml
---
- hosts: all
tasks:
- name: PostgreSQL | Ensure the locale for lc_collate and lc_ctype is generated | Debian
become: yes
locale_gen: name="{{ item }}" state=present
with_items:
- "{{ postgresql_locale }}"
- "{{ postgresql_ctype }}"
vars:
- postgresql_locale: "C.UTF-8"
- postgresql_ctype: "C.UTF-8"
- Run it:
$ ansible-playbook -i my_inventory collate_check.yml -l myUbuntuHost
PLAY [all] ************************************************************************************************************************************************************************************************
TASK [Gathering Facts] ************************************************************************************************************************************************************************************
ok: [myUbuntuHost]
TASK [PostgreSQL | Ensure the locale for lc_collate and lc_ctype is generated | Debian] *******************************************************************************************************************
failed: [myUbuntuHost] (item=C.UTF-8) => {"changed": false, "item": "C.UTF-8", "msg": "The locales you've entered is not available on your system."}
failed: [myUbuntuHost] (item=C.UTF-8) => {"changed": false, "item": "C.UTF-8", "msg": "The locales you've entered is not available on your system."}
PLAY RECAP ************************************************************************************************************************************************************************************************
myUbuntuHost : ok=1 changed=0 unreachable=0 failed=1
Ansible plugin locale_gen.py
This is the section where it goes wrong in locale_gen.py
def is_available(name, ubuntuMode):
"""Check if the given locale is available on the system. This is done by
checking either :
* if the locale is present in /etc/locales.gen
* or if the locale is present in /usr/share/i18n/SUPPORTED"""
if ubuntuMode:
__regexp = r'^(?P<locale>\S+_\S+) (?P<charset>\S+)\s*$'
__locales_available = '/usr/share/i18n/SUPPORTED'
else:
__regexp = r'^#{0,1}\s*(?P<locale>\S+_\S+) (?P<charset>\S+)\s*$'
__locales_available = '/etc/locale.gen'
re_compiled = re.compile(__regexp)
fd = open(__locales_available, 'r')
for line in fd:
result = re_compiled.match(line)
if result and result.group('locale') == name:
return True
fd.close()
return False
The offending statement there is the regex, which is matching for something with an undescrore "_", which C.UTF-8 does not have.
Random thoughts
C.UTF-8 is installed more or less always, no? If it is, we can just ignore that check for C.UTF-8, since it seems to be tricky to get hold of the maintainer of locale_gen.py
In Ubuntu 18.04 LTS (at least) /etc/locale.gen will be created when you reconfigure locales, so it will more or less always be there. But it has been discussed in the Ansible community.
- locale_gen fails to generate a locale on Ubuntu if locale.gen exists ansible/ansible-modules-extras#425
- locale_gen fails to generate a locale on Ubuntu if locale.gen exists ansible/ansible#29200
The bugs above is mainly pointing to that locale_gen.py does not enter "ubuntuMode" if the file /etc/locale.gen exists, which is not really an issue in "our" case. Both regexps above will give us the same problem. It will not find "C.UTF-8", even if it is in the file.