useful to wider audience, and for reference purposes.

Roles cover different aspects of infrastructure, such as mail servers, web

servers, web applications etc. The roles are mainly well-suited for smaller

installations.

At the moment, the roles have been written for and tested against **Ansible

1.9.x**.

Roles should work for the most part with **Ansible 2.0.x** and **Ansible

2.1.x**, but due to bugs in those releases they should not be used for

production purposes. Roles are kept forward-compatible as much as possible until

* Inability to use dynamic name handlers (handlers that include variables in

  their name).

* Referencing non-existing handlers does not produce error.

* Referencing non-existing tags does not produce error.

Why were these roles created?

-----------------------------

For a long time I have had a couple of Internet-facing servers where I hosted

all the IT infrastructure I needed for my day-to-day life.

# -- Options for HTML output ----------------------------------------------

# The theme to use for HTML and HTML Help pages.  See the documentation for

# a list of builtin themes.

# Theme options are theme-specific and customize the look and feel of a theme

# further.  For a list of options available for each theme, see the

# documentation.

#html_theme_options = {}

Majic Ansible Roles documentation

=================================

Majic Ansible Roles is a collection of Ansible roles that are used on regular

basis for deployment and maintenance of Majic infrastructure.

At the moment, the roles have been written for and tested against **Ansible

1.9.x**.

Roles should work for the most part with **Ansible 2.0.x** and **Ansible

2.1.x**, but due to bugs in those releases they should not be used for

production purposes. Roles are kept forward-compatible as much as possible until

**preseed_timezone** (string, optional, ``Europe/Stockholm``)

  Timezone that should be used when calculating server time. It is assumed that

  the local hardware clock is set to UTC.

Examples

~~~~~~~~

Here is an example configuration for a preseed file that sets some global

defaults to be used for all servers, and then overrides it for one server:

**ansible_key** (string, optional, ``{{ lookup('file', '~/.ssh/id_rsa.pub') }}``)

  SSH public key that should be deployed to authorized_keys truststore for

  operating system user ``ansible``.

Examples

~~~~~~~~

Since the role is meant to be used just after the server has been installed, and

using the ``root`` account, it is probably going to be invoked from a separate

playbook.

  Optional identifier appended to regular Bash prompt, useful for visually

  identifying distinct environments. For example, if set to ``test``, resulting

  prompt will be similar to ``admin@web[test]:~$``. Setting affects Bash shells

  *only*.

Examples

~~~~~~~~

Here is an example configuration for setting-up some common users, groups, and

packages on all servers:

    Name of configuration option.

  **value** (string, mandatory)

    Value for configuration option.

Examples

~~~~~~~~

Here is an example configuration for setting some common LDAP client options:

.. code-block:: yaml

  cipher specification that should also include what TLS protocol versions

  should be used. Value should be compatible with OpenLDAP server option

  ``olcTLSCipherSuite``. Default value allows only TLSv1.2 and strong PFS

  ciphers.

Examples

~~~~~~~~

Here is an example configuration for setting-up LDAP server:

.. code-block:: yaml

**xmpp_tls_key** (string, optional, ``{{ lookup('file', tls_private_key_dir + '/' + fqdn + '_xmpp.key') }}``)

  Private key used for TLS for XMPP service. The file will be stored in

  directory ``/etc/ssl/private/`` under name ``{{ ansible_fqdn }}_xmpp.key``.

Examples

~~~~~~~~

Here is an example configuration for setting-up XMPP server using Prosody:

.. code-block:: yaml

  List of networks from which mail relaying is allowed even without

  authentication. Each item in the list is a string defining a network. The

  format must be compatible with Postfix ``mynetworks`` setting (for example:

  ``192.168.1.0/24``, ``myhost.example.com`` etc).

Examples

~~~~~~~~

Here is an example configuration for setting-up XMPP server using Prosody:

.. code-block:: yaml

**smtp_relay_truststore** (string, optional, ``{{ lookup('file', tls_certificate_dir + '/truststore.pem') }}``)

  X.509 certificate chain used for issuing certificate for the SMTP relay

  service. The file will be stored in location

  ``/etc/ssl/certs/smtp_relay_truststore.pem``

Examples

~~~~~~~~

Here is an example configuration for setting-up the mail forwarder:

.. code-block:: yaml

  TLS ciphers to enable on the web server. This should be an OpenSSL-compatible

  cipher specification. Value should be compatible with Nginx configuration

  option ``ssl_ciphers``. Default value allows only TLSv1.2 and strong PFS

  ciphers.

Examples

~~~~~~~~

Here is an example configuration for setting-up web server:

.. code-block:: yaml

**website_mail_recipients** (string, optional, ``root``)

  Space-separated list of e-mails or local users to which the mails, sent to

  either the website admin or website user, should be forwarded to. Forwarding

  is configured via ``~/.forward`` configuration file.

Examples

~~~~~~~~

Here is an example configuration for setting-up two (base) PHP websites (for

running *ownCloud* and *The Bug Genie* applications):

  ``use_paste`` option is enabled, the value should be equal to filename of the

  Python Paste ini file, located in the ``code`` sub-directory. It should be

  noted that in either case the value should be specsified relative to the

  ``code`` sub-directory. I.e. don't use full paths.

Examples

~~~~~~~~

Here is an example configuration for setting-up a (base) WSGI website (for

running a bare Django project):

~~~~~~~~~~

**db_root_password** (string, mandatory)

  Password for the *root* database user.

Examples

~~~~~~~~

Here is an example configuration for setting-up the database server:

.. code-block:: yaml

  Name of the database that should be created.

**db_password** (string, mandatory)

  Password for the database user.

Examples

~~~~~~~~

Here is an example configuration for creating a single database (for some

website):

    ssh-keygen -f backup_server_dsa_key -N '' -t dsa

    ssh-keygen -f backup_server_rsa_key -N '' -t rsa

    ssh-keygen -f backup_server_ed25519_key -N '' -t ed25519

    ssh-keygen -f backup_server_ecdsa_key -N '' -t ecdsa

Examples

~~~~~~~~

Here is an example configuration for setting-up the backup server role:

.. code-block:: yaml

  Port on the backup server to connect to for accessing the SFTP service.

**backup_ssh_key** (string, mandatory)

  SSH private key for logging-in into the backup server.

Examples

~~~~~~~~

Here is an example configuration for setting-up the role (take note that lookup

plugin is quite useful here for fetching key values from some local directory):

**backup_patterns** (list, optional, ``[]``)

  List of globbing patterns defining which files or directories should be

  backed-up.

Examples

~~~~~~~~

Here is an example configuration for setting-up the role:

.. code-block:: yaml

---

- name: Clean-up GnuPG keyring for import of new keys

  shell: rm -f /etc/duply/main/gnupg/*

- name: Import private keys

- name: Import public keys

  when: backup_additional_encryption_keys

---

- name: Install backup software

  apt: name="{{ item }}" state=installed

  with_items:

    - duplicity

    - duply

  notify:

    - Clean-up GnuPG keyring for import of new keys

    - Import private keys

    - Import public keys

- name: Extract encryption key identifier (Duplicty requires key ID in hexadecimal format)

  register: backup_encryption_key_id

  changed_when: False

  failed_when: backup_encryption_key_id.stdout == ""

- name: Extract additional encryption keys identifiers (Duplicty requires key ID in hexadecimal format)

  register: backup_additional_encryption_keys_ids

  when: backup_additional_encryption_keys

  changed_when: False

  failed_when: backup_additional_encryption_keys_ids.stdout == ""

- name: Deploy private SSH key for logging-in into backup server

# GnuPG keys that should be used for encryption. Normally the encryption key is

# not available locally.

GPG_KEYS_ENC='{{ backup_encryption_key_id.stdout }}{% if backup_additional_encryption_keys %},{{ backup_additional_encryption_keys_ids.stdout }}{% endif %}'

# GnuPG key used for signing.

# Trust all keys available in the GnuPG keyring.

GPG_OPTS="--homedir /etc/duply/main/gnupg/ --trust-model always"

# Destination where the backups are stored at.

TARGET='sftp://{{ backup_client_username }}@{{ backup_server }}:{{ backup_server_port }}//{{ backup_server_destination }}'

# Base directory to backup (root). File selection is done via include/exclude

# patterns.

SOURCE='/'

# Maximum age for preserving old backups. Used when running the "purge"

DUPL_PARAMS="$DUPL_PARAMS --use-agent"

# Use the pexepct backend for Duplicity so we can pass in all the

# ssh-options. Use dedicated known hosts and identity file when connecting over

# SFTP. Using -oLogLevel=ERROR makes output a bit less verbose. This is mainly

# to avoid output from sftp telling us it added IP address to known_hosts.

DUPL_PARAMS="$DUPL_PARAMS --ssh-backend pexpect --ssh-options='-oLogLevel=ERROR -oUserKnownHostsFile=/dev/null -oGlobalKnownHostsFile=/etc/duply/main/ssh/known_hosts -oIdentityFile=/etc/duply/main/ssh/identity'"

# By default we exclude everything, and then include only specific patterns.