diff --git a/docs/usage.rst b/docs/usage.rst index 6301e8851849cbcba26a94a09d9975eef53957ed..f9658368dd45d304455928d518366655dff0e90b 100644 --- a/docs/usage.rst +++ b/docs/usage.rst @@ -666,7 +666,7 @@ one up first. This includes both the LDAP *server* and *client* configuration. tls_private_key_dir: "~/mysite/tls/" tls_certificate_dir: "~/mysite/tls/" ca_certificates: - "truststore": "{{ lookup('file', '~/mysite/tls/truststore.pem') }}" + truststore: "{{ lookup('file', '~/mysite/tls/truststore.pem') }}" 8. And now, for the finishing touch, just run the playbooks again:: @@ -748,13 +748,13 @@ role. # Don't forget, the passwords here must match with passwords specified # under options mail_ldap_postfix_password/mail_ldap_dovecot_password. ldap_server_consumers: - - name: postfix - password: postfix - - name: dovecot - password: dovecot + - name: postfix + password: postfix + - name: dovecot + password: dovecot ldap_server_groups: - - name: mail + - name: mail 4. Ok, so now our SMTP and IMAP service can log-in into the LDAP server to look-up the mail server information. We have also defined the mail group for @@ -774,41 +774,41 @@ role. :: ldap_entries: - # Create first a couple of user entries. Don't forget to set the - # "mail" attribute for them. - - dn: uid=johndoe,ou=people,dc=example,dc=com - attributes: - objectClass: - - inetOrgPerson - uid: johndoe - cn: John Doe - sn: Doe - userPassword: johndoe - mail: john.doe@example.com - - dn: uid=janedoe,ou=people,dc=example,dc=com - attributes: - objectClass: - - inetOrgPerson - uid: janedoe - cn: Jane Doe - sn: Doe - userPassword: janedoe - mail: jane.doe@example.com - - # Let's register our domain in LDAP directory. - - dn: dc=example.com,ou=domains,ou=mail,ou=services,dc=example,dc=com - attributes: - objectClass: dNSDomain - dc: "example.com" + # Create first a couple of user entries. Don't forget to set the + # "mail" attribute for them. + - dn: uid=johndoe,ou=people,dc=example,dc=com + attributes: + objectClass: + - inetOrgPerson + uid: johndoe + cn: John Doe + sn: Doe + userPassword: johndoe + mail: john.doe@example.com + - dn: uid=janedoe,ou=people,dc=example,dc=com + attributes: + objectClass: + - inetOrgPerson + uid: janedoe + cn: Jane Doe + sn: Doe + userPassword: janedoe + mail: jane.doe@example.com + + # Let's register our domain in LDAP directory. + - dn: dc=example.com,ou=domains,ou=mail,ou=services,dc=example,dc=com + attributes: + objectClass: dNSDomain + dc: "example.com" # Finally, for the lolz, let's also add the standard postmaster alias # for our domain. This one will also receive any undeliverable bounced # mails. - - dn: cn=postmaster@example.com,ou=aliases,ou=mail,ou=services,dc=example,dc=com - attributes: - objectClass: nisMailAlias - cn: postmaster@example.com - rfc822MailMember: john.doe@example.com + - dn: cn=postmaster@example.com,ou=aliases,ou=mail,ou=services,dc=example,dc=com + attributes: + objectClass: nisMailAlias + cn: postmaster@example.com + rfc822MailMember: john.doe@example.com 5. Once again, before we apply the configuration, we must make sure the necessary TLS private keys and certificates are available. In this particular @@ -930,7 +930,7 @@ external addresses on those two servers goes through our anti-virus scanner. # First, let's make sure any mails directed to localhost root account get # forwarded to one of our mail users as well. local_mail_aliases: - root: root john.doe@example.com + root: root john.doe@example.com # Now signal the local SMTP to relay any non-local mails via our # communications server. Don't forget to specify your own IP address (or @@ -953,8 +953,8 @@ external addresses on those two servers goes through our anti-virus scanner. # here.Beware the IP spoofing, though! Don't forget to change the bellow # IP for your server ;) smtp_allow_relay_from: - - 10.32.64.20 - - 10.32.64.23 + - 10.32.64.20 + - 10.32.64.23 4. Let's apply the changes:: @@ -1004,12 +1004,12 @@ role. # Set one of the users to also be an XMPP administrator. xmpp_administrators: - - john.doe@example.com + - john.doe@example.com # Unfortunately, XMPP can't look-up domains via LDAP, so we need to be # explicit here. xmpp_domains: - - example.com + - example.com # Simply point the XMPP server to base DN of LDAP server, and let it use # specific directory structure it expects. @@ -1035,17 +1035,17 @@ role. # passwords. Keep in mind password for prosody user must match with # password specified under xmpp_ldap_password. ldap_server_consumers: - - name: postfix - password: postfix - - name: dovecot - password: dovecot - - name: prosody - password: prosody + - name: postfix + password: postfix + - name: dovecot + password: dovecot + - name: prosody + password: prosody # And simply append a new group here... ldap_server_groups: - - name: mail - - name: xmpp + - name: mail + - name: xmpp 4. Do you know what comes next? Yes! Create some more TLS private keys and certificates, this time for our XMPP server ;) @@ -1345,38 +1345,38 @@ Before we start, here is a couple of useful pointers regarding the --- dependencies: - # Ok, so this role helps us set-up Nginx virtual host for serving our - # app. - - role: php_website - # Our virtual host will for PHP website will respond to this name. - fqdn: tbg.example.com - # Some additional packages are required in order to deploy and use TBG. - packages: - - php-gd - - php-curl - - php-mbstring - - php-xml - - git - - php-mysql - - expect - # Set-up URL rewriting. This is based on public/.htaccess file from - # TBG. - php_rewrite_urls: - - ^(.*)$ /index.php?url=$1 - # We don't necessarily need this, but in case you have a policy on - # uid/gid usage, this is useful. Take note that below value is used - # for both the dedicated uid and gid for application user. - uid: 2000 - admin_uid: 3000 - # And this role sets up a new dedicated database for our web - # application. - - role: database - # This is both the database name, _and_ name of the database user - # that will be granted full privileges on the database. - db_name: tbg - # This will be the password of our user 'tbg' for accessing the - # database. Take note the user can only login from localhost. - db_password: tbg + # Ok, so this role helps us set-up Nginx virtual host for serving our + # app. + - role: php_website + # Our virtual host will for PHP website will respond to this name. + fqdn: tbg.example.com + # Some additional packages are required in order to deploy and use TBG. + packages: + - php-gd + - php-curl + - php-mbstring + - php-xml + - git + - php-mysql + - expect + # Set-up URL rewriting. This is based on public/.htaccess file from + # TBG. + php_rewrite_urls: + - ^(.*)$ /index.php?url=$1 + # We don't necessarily need this, but in case you have a policy on + # uid/gid usage, this is useful. Take note that below value is used + # for both the dedicated uid and gid for application user. + uid: 2000 + admin_uid: 3000 + # And this role sets up a new dedicated database for our web + # application. + - role: database + # This is both the database name, _and_ name of the database user + # that will be granted full privileges on the database. + db_name: tbg + # This will be the password of our user 'tbg' for accessing the + # database. Take note the user can only login from localhost. + db_password: tbg 3. Now for my favourite part again - creating private keys and certificates! Why? Because the ``php_website`` role requires a private key/certificate @@ -1664,47 +1664,47 @@ on the safe side: --- dependencies: - - role: wsgi_website - fqdn: wiki.example.com - # In many cases you need to have some development packages available - # in order to build Python packages installed via pip - packages: - - build-essential - - python-dev - - libjpeg-dev - - libzip-dev - - libtiff-dev - - libfreetype6-dev - - liblcms2-dev - - libwebp-dev - - libopenjp2-7-dev - - libmariadb-client-lgpl-dev - - libmariadb-client-lgpl-dev-compat - # Here we specify that anything accessing our website with "/static/" - # URL should be treated as request to a static file, to be served - # directly by Nginx instead of the WSGI server. - static_locations: - - /static/ - # Again, not mandatory, but it is good to have some sort of policy - # for assigning UIDs. - uid: 2001 - admin_uid: 3001 - # These are additional packages that should be installed in the - # virtual environment. - virtualenv_packages: - - pillow - - django==1.8.13 - - wiki - - MySQL-python - # This is the name of the WSGI application to - # serve. wiki_example_com.wsgi will be the Python "module" that is - # accesed, while application is the object instantiated within it (the - # application itself). The module is referenced relative to the code - # directory (in our case /var/www/wiki.example.com/code/). - wsgi_application: wiki_example_com.wsgi:application - - role: database - db_name: wiki - db_password: wiki + - role: wsgi_website + fqdn: wiki.example.com + # In many cases you need to have some development packages available + # in order to build Python packages installed via pip + packages: + - build-essential + - python-dev + - libjpeg-dev + - libzip-dev + - libtiff-dev + - libfreetype6-dev + - liblcms2-dev + - libwebp-dev + - libopenjp2-7-dev + - libmariadb-client-lgpl-dev + - libmariadb-client-lgpl-dev-compat + # Here we specify that anything accessing our website with "/static/" + # URL should be treated as request to a static file, to be served + # directly by Nginx instead of the WSGI server. + static_locations: + - /static/ + # Again, not mandatory, but it is good to have some sort of policy + # for assigning UIDs. + uid: 2001 + admin_uid: 3001 + # These are additional packages that should be installed in the + # virtual environment. + virtualenv_packages: + - pillow + - django==1.8.13 + - wiki + - MySQL-python + # This is the name of the WSGI application to + # serve. wiki_example_com.wsgi will be the Python "module" that is + # accesed, while application is the object instantiated within it (the + # application itself). The module is referenced relative to the code + # directory (in our case /var/www/wiki.example.com/code/). + wsgi_application: wiki_example_com.wsgi:application + - role: database + db_name: wiki + db_password: wiki 3. Let's create a dedicated private key/certificate pair for the wiki website: