damienfrancois / slufl2 Goto Github PK

The case I had problems with was with the "ç" (e.g. from Damien's lastname: François):

Processing item 'dfr' (1/53)
{'cn': ['Damien Fran\xc3\xa7ois'],
...
 'sn': ['Fran\xc3\xa7ois'],
...
 'uid': ['dfr'],
...}
  Notify CP3 Support when a CP3 user creates or renews its CECI account.

PLAY [localhost] *******************************************************************************************************************************************************************************************

TASK [Gathering Facts] *************************************************************************************************************************************************************************************
ok: [localhost]

TASK [search for user's ceci username in cp3 members database] *********************************************************************************************************************************************
changed: [localhost]

TASK [send email] ******************************************************************************************************************************************************************************************
fatal: [localhost]: FAILED! => {"failed": true, "msg": "the field 'args' has an invalid value ([]), and could not be converted to an dict. Error was: 'ascii' codec can't decode byte 0xc3 in position 11: ordinal not in range(128)\n\nThe error appears to have been in '/etc/slufld.conf.d/send_notification.yml': line 11, column 7, but may\nbe elsewhere in the file depending on the exact syntax problem.\n\nThe offending line appears to be:\n\n      register: query_result_ceci_username\n    - name: send email\n      ^ here\n"}
	to retry, use: --limit @/etc/slufld.conf.d/send_notification.retry

PLAY RECAP *************************************************************************************************************************************************************************************************
localhost                  : ok=2    changed=1    unreachable=0    failed=1   

I solved this by adding the following line:

entry['cn'][0] = entry['cn'][0].decode('utf-8')

before the loop over the playbooks.

Currently the daemon sleeptime is reinitialized to the value written in the config file after successfully running each playbook for each user. If we want to keep the same behaviour as in the original version of slufl, the reinitialization should happen after successfully running all playbooks for all users.

At CP3 we upgraded Ansible in the machine running slufll2 to version 2.9.10. The Ansible python API, being for internal use only, has changed in a non-backward compatible way. I have created a ansiblev2.9 branch in my fork of this project with the needed modifications to make slufl2 work with Ansible 2.9: https://github.com/AndresTanasijczuk/slufl2/tree/ansiblev2.9
I think the modifications are needed for Ansible 2.7 already.

I wanted to create a pull request, but since I think that the idea would be to create a new branch, I can not make the pull request to a new branch. I am running the slufld script from my new branch at CP3 and I can confirm that it works.

The function daemonize (https://github.com/damienfrancois/slufl2/blob/master/slufld#L68) was written from scratch following a C recipe. We should replace it with a more up-to-date solution.

References:

• https://pypi.python.org/pypi/python-daemon/
• https://www.python.org/dev/peps/pep-3143/

Would it be possible to support Python3?

thanks,

Olivier

The slufl2 package comes with a TestCustom.yml playbook and a secret.yml vault file used by that playbook. If one doesn't know the password to decrypt secret.yml and if one doesn't move away TestCustom.yml from /etc/slufld.conf.d/, slufld will break when trying to run TestCustom.yml, because it can not decrypt the secret.yml file.
When I install slufl2, I cleanup the /etc/slufld.conf.d/ directory in order to remove these files. But for some reason these files appeared again in my installation and slufld was broken for more than 2 months without me noticing it until a user complained today that his key was not updated. One possible solution would be to move away TestCustom.yml into, for example, a /etc/slufld.conf.d/test subdirectory.

• List options
• Detail behaviour

Hi,

I tried to run slufl but have encountered difficulties in running it with the latest Ansible 2.4.
I'm not sure for which exact Ansible version slufl was built, but in the most recent version, Ansible 2.4, a lot of things changed in the sytax of ansible python modules, mainly the Inventory, Variable and CLI submodules.
Here is the changelog and a link to a porting guide:

Ansible 2.4 changelog
Ansible 2.4 porting guide

Keep in mind that the porting guide is meant for porting from 2.3 to 2.4, so there is most likely more work to be done.

I want to run a playbook containing a secret password.
I am used to encrypt secret passwords with ansible-vault and provide the encryption password when running the ansible-playbook command with the --ask-vault-password option.
Here we do not want to be prompted for a password.
The other option is to put the encryption password in a protected file and use the --vault-password-file=/path/to/file option.
With the API, that can be done using the following code in the build_playbook_options function:

    vault_password_file = os.environ.get('ANSIBLE_VAULT_PASSWORD_FILE')
    if not vault_password_file and os.path.isfile('/etc/slufld.conf.d/vault/.vault_pass.txt'):
        vault_password_file = '/etc/slufld.conf.d/vault/.vault_pass.txt'
    if vault_password_file:
        try:
            with open(vault_password_file, 'r') as fd:
                loader.set_vault_password(fd.read().splitlines()[0])
        except IOError:
            logging.critical('FATAL: Can not open vault file %s' % vault_password_file)
            raise

That worked for me.

Currently the daemon statefile is updated after successfully running each playbook (for each user entry). If we want to keep the same behaviour as in the original version of slufl, then the update of the daemon statefile should happen after all playbooks have ran successfully (for each user entry).