This role will setup a lot of different stuff of your system. I use it on all my servers. It's tested on :
Here's the minimum variables you should set
# A list of trusted IP. Will have accesso to the SSH service of all the servers for example trusted_ip: - 10.11.12.13 - 10.8.0.0/16 # Unix groups whose members will have sudo access. The group must already exists, it won't be created (it can be a group from LDAP or AD for example) system_admin_groups: - admins # Email address which will receive system email, those addressed to root@yourserver system_admin_email: server-mailbox@example.org # Some roles which uses a database will try to read mysql_server or pg_server (or fallback to localhost if not defined) # If you have a host dedicated to database, you can set it mysql_server: maria.fws.fr pg_server: postgres.fws.fr mysql_admin_pass: "{{ vault_mysql_admin_pass }}" pg_admin_pass: "{{ vault_pg_admin_pass }}" # System timezone system_tz: 'Europe/Paris'
Of course, there are a lot more variables available. You can look in roles/common/defaults. Some other roles can be pulled in as a dependency if some specific variables are set. For example, if you set the following :
ad_auth: True samba_domain: acme samba_realm: acme.com ad_admin_pass: "{{ vault_samba_dc_admin_pass }}" ad_access_filter: DOM:FWS.FR:(&(objectCategory=person)(objectClass=user)(primaryGroupId=513)(memberOf:1.2.840.113556.1.4.1941:=CN=Role_Unix,OU=Roles,DC=acme,DC=com))
Then the sssd_ad_auth role will be pulled in, and your server will be joined to the domain during the playbook (and in this example, users will only be accepted if they are a direct or indirect member of the group CN=Role_Unix,OU=Roles,DC=acme,DC=com)
You can check roles/common/meta/main.yml to see which roles will be pulled in as dependency