This allows the password to contain single quotes and should make it safe to
use randomly generated passwords (provided passwords can be represented in the
connection encoding).
- .rst now supresses default if none is set (looks better in HTML)
- .rst now handles empty options list
- Fixed postgresql_user and mysql_user because YAML contained colons
- docs for facter
If I create a database from scratch and assign permissions by doing:
- name: ensure database is created
action: postgresql_db db=$dbname
- name: ensure django user has access
action: postgresql_user db=$dbname user=$dbuser priv=ALL password=$dbpassword
Then it fails with the error:
File "/tmp/ansible-1347048449.32-29998829936529/postgresql_user", line 565, in <module>
main()
File "/tmp/ansible-1347048449.32-29998829936529/postgresql_user", line 273, in main
changed = grant_privileges(cursor, user, privs) or changed
File "/tmp/ansible-1347048449.32-29998829936529/postgresql_user", line 174, in grant_privileges
changed = grant_func(cursor, user, name, privilege)\
File "/tmp/ansible-1347048449.32-29998829936529/postgresql_user", line 132, in grant_database_privilege
prev_priv = get_database_privileges(cursor, user, db)
File "/tmp/ansible-1347048449.32-29998829936529/postgresql_user", line 118, in get_database_privileges
r = re.search('%s=(C?T?c?)/[a-z]+\,?' % user, datacl)
File "/usr/lib/python2.7/re.py", line 142, in search
return _compile(pattern, flags).search(string)
TypeError: expected string or buffer
This fix fixes the problem by not executing the regex if the
db query on pg_database returns None.
Use a different method to query for current
privileges at the table and database level.
This method is more robust if newer privileges
are added in future versions and also supports the
ALL wildcard.
fail_on_user option can be used to ignore silently
if the user cannot be removed because of remaining
privilege dependencies to other objects in the
database. By default it will fail, so that this new
behavior won't surprise unsuspecting users.
The postgresql_user module has several drawbacks:
* No granularity for privileges
* PostgreSQL semantics force working on one
database at time, at least for Tables. Which
means that a single call can't remove all the
privileges for a user, and a user can't be
removed until all the privileges are removed,
forcing a module failure with no way to
work around the issue.
Changes:
* Added the ability to specify granular privileges
for database and tables within the database
* Report if user was removed, and add an option to
disable failing if user is not removed.
passwd -> password
loginpass -> login_password
loginuser -> login_user
loginhost -> login_host
Add an example playbook that shows how to use the modules.
These modules are based on the mysql_db and mysql_user modules.
Currently, the postgresql_user module can only grant all permissions
on a database, fine-grained access has not been implemented yet.
