You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

546 lines
17 KiB

Using Enough
* The ```` credentials for a ``Public cloud`` project at `OVH
<>`__. No other OpenStack
provider is supported.
* The ``Public cloud`` project has a `Private network
Enough is based on `Ansible <>`__, `OpenStack
<>`__ and `Debian GNU/Linux
<>`__. Debian GNU/Linux based virtual machines
are created on an OpenStack tenant and provisioned with Ansible
Each service adds more components such as `Let's encrypt
<>`__, `Docker <>`__ or
`Snap <>`__. And they also implement concepts
such as `Virtual Private Network
<>`__, `Reverse
Proxy <>`__ or `Certificate
Authority <>`__.
If all goes well, Enough can be used even if the user knows nothing
more than what is in this guide. When something goes wrong, fixing the
problem or understanding the cause will require intimate knowledge
about all of the above. If that happens, it is best to start a
`discussion in the forum
<>`__ and ask for help.
* `Install Docker <>`__.
* Copy ```` in ``~/.enough/`` and edit
to replace ``$OS_PASSWORD_INPUT`` with the actual password.
* Add the ``enough`` CLI to ``~/.bashrc``:
.. code::
eval "$(docker run --rm enoughcommunity/enough:latest install)"
* Verify that it works:
.. code::
enough --version
.. _bind_create:
Create the DNS name server
Assuming the domain name (```` for example) is registered,
it must be delegated to a dedicated name server before any service can
be created by Enough:
.. code::
enough --domain service create bind
Upon successfull completion, a machine named ``bind-host`` exists and
its public IP must be used as a `GLUE record
.. code::
$ enough --domain openstack server list
| ID | Name | Status | Networks | Image | Flavor |
| 2b9a1bda-c2c0 | bind-host | ACTIVE | Ext-Net= | Debian 10 | s1-2 |
To verify the DNS running at bind-host works as expected:
.. code::
$ dig @ip-of-the-bind-host
$ enough --domain ssh bind-host
It can then be used to instruct the `registrar
<>`__ of
```` to delegate all domain name resolutions to this
IP. The exact method for performing this DNS delegation depends on the
registrar (`Gandi
is different from `OVH
<>`__, etc.). But it needs
to be done only once.
.. note::
It will take time for the delegation to be effective.
It can be as quick as one hour but delays from 24h to 72h are not uncommon.
To verify the delegation is effective:
.. code::
getent hosts
Create or update a service
The following services are available:
* :doc:`bind <services/bind>` for `DNS server <>`__ at ````
* :doc:`icinga <services/monitoring>` for `monitoring <>`__ at ````.
* :doc:`postfix <services/postfix>` for `SMTP server <>`__ at ````.
* :doc:`OpenVPN <services/VPN>`, for `VPN <>`__ at ````
* :doc:`wazuh <services/ids>` for `Intrusion Detection System <>`__ at ````.
* :doc:`chat <services/mattermost>`, for `instant messaging <>`__ at ````
* :doc:`cloud <services/nextcloud>`, for `file sharing <>`__ at ````
* ``forum``, for `discussions and mailing lists <>`__ at ````
* ``packages``, a `static web service <>`__ at ````
* ``pad``, for `collaborative note taking <>`__ at ````
* :doc:`Weblate <services/weblate>`, for `online translations <>`__ at ````
* :doc:`WordPress <services/wordpress>`, for `CMS <>`__ at ````
* :doc:`openedX <services/openedx>`, for `MOOC platform <>`__ at ````
* ``website``, for `static websites <>`__ at ````
* ``wekan``, for `kanban <>`__ at ````
* :doc:`gitlab <services/gitlab>`, for `software development <>`__ at ````
* ``api``, for :doc:`Enough development <community/contribute>` at ````
* :doc:`Jitsi <services/jitsi>`, for `video conferencing <>`__ at ````
As an example, the cloud service can be created as follows:
.. code::
enough --domain service create cloud
.. note::
If the command fails, because of a network failure or any other reason,
it is safe to run it again. It is idempotent.
When it completes successfully, it is possible to login
```` with user ``admin`` and password
Restore a service
Stateless services such as :doc:`bind <services/bind>` do not need
backup: they can be rebuilt from scratch if the machine hosting them
fails. For instance, if `bind-host` is lost:
.. code::
$ enough --domain host create bind-host
$ enough --domain playbook
However, most services such as :doc:`file sharing <services/nextcloud>`
and :doc:`translations <services/weblate>` rely on persistent
information that are located in a encrypted volume attached to the
machine. A daily :doc:`backup <services/backup>` is made in case a
file is inadvertendly lost.
Infrastructure services and access
By default all hosts are connected to two networks: one with a public
IP and the other with a private IP. This can be changed by setting the
`openstack_network` variable in
`~/.enough/`, using
`this example
The default can also be changed for a given host (for instance
`weblate-host`) by setting the desired value in the
`~/.enough/` file.
.. _user_guide_vpn:
A VPN can optionally be installed for clients to access hosts that do
not have public IPs.
A host with a public IP must be chosen to deploy the VPN. For instance
`bind-host` by adding the following to `~/.enough/`:
.. code::
It can then be created with:
.. code::
enough --domain service create openvpn
The certificates for clients to connect to the VPN will be created
from the list in the `openvpn_active_clients` variable in
using `this example
For each name in the `openvpn_active_clients` list, a `.tar.gz` file will be created in the
`~/.enough/` directory. For instance, for
.. code::
- loic
The file `~/.enough/` will be
created and contains OpenVPN credentials. The specific instructions
to use them depends on the client.
By default certificates are obtained from `Let's Encrypt
<>`__. But if a host is not publicly
accessible, it can be configured to obtain a certificate from a
certificate authority dedicated to the Enough instance. The default
for `certificate_authority` should be set in
`~/.enough/`, using `this example <>`__.
The default can also be changed for a given host (for instance
`weblate-host`) by setting the desired value in the
`~/.enough/` file.
.. _attached_volumes:
Attached volumes
A volume can be created and attached to the host. It can be resized at
a later time, when more space is needed. For instance, before creating
`weblate-host`, the desired volume size and name can be set in the
file like so:
.. code::
- name: weblate-volume
size: 10
Encrypting and Mounting
The volume can then be encrypted, formatted and mounted by specifying
the mount point in the `encrypted_device_mount_point` variable like so:
.. code::
- name: weblate-volume
size: 10
encrypted_device_mount_point: /srv
By default `Docker <>`__ or `Snap
<>`__ will be set to reside in the
`encrypted_device_mount_point` directory so that the data it contains
is encrypted. It can be disabled with the
`encrypted_volume_for_docker` and `encrypted_volume_for_snap`
variables like so:
.. code::
- name: weblate-volume
size: 10
encrypted_device_mount_point: /srv
encrypted_volume_for_docker: false
encrypted_volume_for_snap: false
The following services are always available:
* :doc:`bind <services/bind>` for `DNS server <>`__ at ````
* `security groups <>`__ for :ref:`firewall <firewall>`.
Background tasks
* :doc:`Volumes and hosts backups <services/backup>`.
* `Unattended upgrades <>`__.
* Tracking changes in `/etc/ for each machine <>`__.
The `SSH public keys <>`__ found in
files matching ``authorized_keys_globs`` are installed on every machine.
.. code::
- ssh_keys/
- ssh_keys/
.. _restore_service_from_backup:
Restore a service from a backup
To restore the volume attached to a service from a designated backup:
.. code::
$ enough --domain openstack volume snapshot list
| 6b75f34e | 2020-04-12-cloud-volume | None | available | 100 |
$ enough --domain backup restore 2020-04-12-cloud-volume
In this example, the restoration is done as follows:
* The :doc:`cloud service <services/nextcloud>` is created, if it does not
already exist.
* The machine (``cloud-host``) attached to the volume (``cloud-volume``) is
stopped. The volume is detached and deleted.
* A new volume ``cloud-volume`` is created from the
``2020-04-12-cloud-volume`` backup and attached to ``cloud-host``.
* The machine (``cloud-host``) is restarted.
Create a clone of a service from a backup
It is convenient to create a clone of an existing service based on a
backup for:
* testing and experimenting without disrupting production
* verify an upgrade won't loose any data
* teaching
* etc.
.. code::
$ enough --domain openstack volume snapshot list
| 6b75f34e | 2020-04-12-cloud-volume | None | available | 100 |
$ enough --domain backup restore \
--target-domain \
Once the service is cloned, it will be available at
````. In this example, the
cloning is done as follows:
* A dedicated OpenStack region is used to restore the backup
.. note::
The OpenStack region where the backup is restored is in the
`clone` section of the `~/.enough/`
file and it can be modified if the default is not suitable.
* A volume is created from the ``2020-04-12-cloud-volume`` snapshot
* The :doc:`cloud service <services/nextcloud>` is created (in the
region dedicated to restoring the backup) as well as all the
services it depends on, if they do not already exist. Including the
:doc:`DNS server <services/bind>`.
* The ```` domain is delegated to the
:doc:`DNS server <services/bind>` located in the
OpenStack region where the backup was restored
so that ```` resolves
to the newly created :doc:`cloud service <services/nextcloud>`.
It is possible restore the service step by step with the following commands:
.. code::
$ enough --domain backup clone volume \
--target-domain 2020-07-29-cloud-volume
$ enough --domain service create cloud
$ enough --domain backup restore 2020-07-29-cloud-volume
Restoring a service that requires a VPN
If the service restored in a clone requires a VPN (that is if it runs
on an private IP), a new VPN must be setup before the user can access
If the service is cloned with:
.. code::
$ enough --domain backup restore \
--target-domain \
The credentials to connect to the VPN of the clone are found in the
`~/.enough/` directory (for instance
.. note::
Although the `loic.tar.gz` file has the same name as in the
original, it will connect to a the VPN server in the clone. Care
must be taken to **not** override credentials that existed before
the cloning operation.
The subnet of internal network of the clone is hardcoded in
.. code:
openstack_internal_network_prefix: ""
openstack_internal_network_cidr: ""
Low level commands
The following are not useful if only relying on the ``service``
command above. They can however be helpful to run Ansible or OpenStack
Adding hosts
The hosts (OpenStack virtual machines) are created automatically when
a service is provided. It is however possible to create a new host or
destroy an existing one.
The first step is to edit ``~/.enough/`` and
add the name of the new host:
.. code::
Creating a new host:
.. code::
enough --domain host create my-host
SSH to a host:
.. code::
enough --domain ssh my-host
Removing hosts
Every host is known to ``icinga``, ``bind`` and ``wazuh`` and it
should be deleted from these services before being removed.
* Add the host to the ``deleted-hosts`` group in ``~/.enough/``:
.. code::
* Run the playbook:
.. code::
enough --domain playbook
* Physically delete the host
.. code::
enough --domain host delete my-host
Running openstack
The `openstack <>`__
CLI can be used as follows:
.. code::
$ enough --domain openstack -- help
Which is exactly equivalent to:
.. code::
$ OS_CLIENT_CONFIG_FILE=~/.enough/ \
openstack --os-cloud production help
Running ansible-playbook
The `ansible-playbook <>`__
CLI can be used as follows:
.. code::
$ enough --domain playbook -- --limit localhost,icinga-host \
--private-key ~/.enough/ \
It implicitly uses the following inventories (via multiple
**--inventory** options), in order (the last inventory listed has
* ~/.enough/
* `built in Enough inventory <>`__