Thank you, will try this one :) That’s 100% as it’ll only be a specific user that’ll do the updates etc.

On Aug 29, hvjunk wrote: DebOps configures Ansible to look for roles in multiple places, in this order: - project directory, 'ansible/roles/' - project directory, 'roles/' - the '${install-path}/playbooks/roles/' directory Similarly, the 'debops' script looks up the first argument as a potential playbook in multiple directories, in this order: - the project directory, 'ansible/playbooks/' - the project directory, 'playbooks/' - the '${install-path}/playbooks/' directory When you have the "base" DebOps deployed in ${install-path}, and you put a role in say, your project directory/roles/, the role in the project directory will "mask" the ${install-path} version. What I'm usually doing is I fork a DebOps role on GitHub to my own profile, then clone that fork to '~/src/github.com/drybjed/ansible-<role>/' and symlink it in my development environment project directory/roles/debops.<role>/debops.<role>/. Additionally, in the role's git repository add the original DebOps role repository as upstream, so it's easy to pull new changes to your fork. That way the role I'm working on masks the upstream one, and any roles that use a given role as a dependency will automatically use it as well. This is not true for Ansible playbooks, but all you need to do to test a new playbook is specify it's name with the 'debops <playbook>' command (as the first argument), and it will be executed by ansible-playbooks. So, no need to mess with a local .debops.cfg file, and you can have separate environments for production, that use the global DebOps roles, and development, that have their own separate set. Cheers, Maciej