Add metadata to all md files

docs/ansible/roles/packetbeat/index.md

+---
+title: Ansible Role Packetbeat
+repo: https://gitlab.lakedrops.com/ansible/roles/packetbeat
+issues: https://gitlab.lakedrops.com/ansible/roles/packetbeat/-/issues
+tags:
+- ansible
+---
 # Packetbeat
 
 https://www.elastic.co/guide/en/beats/packetbeat/7.4/packetbeat-getting-started.html

docs/ansible/roles/php/index.md

+---
+title: Ansible Role PHP
+repo: https://gitlab.lakedrops.com/ansible/roles/php
+issues: https://gitlab.lakedrops.com/ansible/roles/php/-/issues
+tags:
+- ansible
+---
 # Updating PHP Version
 
 ```

docs/ansible/roles/serverdensity/index.md

+---
+title: Ansible Role ServerDensity
+repo: https://gitlab.lakedrops.com/ansible/roles/serverdensity
+issues: https://gitlab.lakedrops.com/ansible/roles/serverdensity/-/issues
+tags:
+- ansible
+---
 # Ansible role to install and configure Server Density Agent
 
 [Server Density] is a monitoring solution which requires a simple Python based agent and is highly configurable. This Ansible role installs and confgures that agent and supports several options like plugin installation and inventory synchronisation with your Server density dashboard.

docs/ansible/roles/spideroak/index.md

+---
+title: Ansible Role SpiderOak
+repo: https://gitlab.lakedrops.com/ansible/roles/spideroak
+issues: https://gitlab.lakedrops.com/ansible/roles/spideroak/-/issues
+tags:
+- ansible
+---
 # SpiderOak ONE
 
 - [Support](https://spideroak.support/hc/en-us)

docs/ansible/roles/user-management/index.md

+---
+title: Ansible Role User Management
+repo: https://gitlab.lakedrops.com/ansible/roles/user-management
+issues: https://gitlab.lakedrops.com/ansible/roles/user-management/-/issues
+tags:
+- ansible
+---
 ansible-user-management
 =======================
 

docs/ansible/roles/vpn/index.md

+---
+title: Ansible Role VPN
+repo: https://gitlab.lakedrops.com/ansible/roles/vpn
+issues: https://gitlab.lakedrops.com/ansible/roles/vpn/-/issues
+tags:
+- ansible
+---
 # VPN with strongSwan
 
 Sources:

docs/ansible/roles/zammad/index.md

+---
+title: Ansible Role Zammad
+repo: https://gitlab.lakedrops.com/ansible/roles/zammad
+issues: https://gitlab.lakedrops.com/ansible/roles/zammad/-/issues
+tags:
+- ansible
+---
 # Zammad
 
 ATTENTION: Zammad requires ElasticSearch 5.6.x

docs/ansible/wiki/attacks.md

+---
+title: Ansible Wiki Attacks
+tags:
+- ansible
+---
 # Attack Vectors
 
 In the context of responsible risk assesment we have to think about how the server farm can be attacked from outside, what the consequences would be and how we can protect ourselves from such attacks.

docs/ansible/wiki/backup/backup-google.md

+---
+title: Ansible Wiki Backup Google
+tags:
+- ansible
+---
 # Backup to Google Cloud
 
 If your inventory has the variable `gcloud_sync` defined, then Google Cloud backup tools will be installed and configured automatically.

docs/ansible/wiki/backup/backup-spideroak.md

+---
+title: Ansible Wiki Backup SpiderOak
+tags:
+- ansible
+---
 # Backup to SpiderOak
 
 If your inventory has the variables `spideroak_username` and `spideroak_password` defined, then SpiderOak will be installed and configured automatically.

docs/ansible/wiki/backup/backup.md

+---
+title: Ansible Wiki Backup
+tags:
+- ansible
+---
 # Backing up data
 
 As described in the [introduction](backup/introduction) we are focusing on databases and customer files only when it comes to backups. So we have to maintain a list of directories containing customer files that should be backed up and we have to produce regular database dumps that then also can be backed up like customer files too.

docs/ansible/wiki/backup/introduction.md

+---
+title: Ansible Wiki Backup Intro
+tags:
+- ansible
+---
 # Introduction to Backup and Restore
 
 - [Introduction](backup/introduction)

docs/ansible/wiki/backup/restore-google.md

+---
+title: Ansible Wiki Restore Google
+tags:
+- ansible
+---
 # Restore from Google Cloud
 
 For each of the directories you want to restore, call the sequence of these commands:

docs/ansible/wiki/backup/restore-spideroak.md

+---
+title: Ansible Wiki Restore SpideOak
+tags:
+- ansible
+---
 # Restore from SpiderOak
 
 First, you have to stop the SpiderOak service:

docs/ansible/wiki/backup/restore.md

+---
+title: Ansible Wiki Restore
+tags:
+- ansible
+---
 # Restore Data from Backups
 
 Should you ever have to rebuild a host, you will then also have to restore data from backups. The host itself should be built with Ansible like it was built originally and afterwards you then pull the data from the backups. At that time, all the tools and credentials will already be available on that host so that you can simply call the respective commands, from either of these off-site facilities:

docs/ansible/wiki/configure-crontabs.md

+---
+title: Ansible Wiki Crontabs
+tags:
+- ansible
+---
 # Roles which are setting Crontabs
 
 ## Common

docs/ansible/wiki/desaster-recovery.md

+---
+title: Ansible Wiki Desaster Recovery
+tags:
+- ansible
+---
 # Desaster Recovery
 
 This is something that a lot of traditional IT admins are looking for because they alway had to have a plan to keep their company's hardware, software and network up and running. That included the requirement for a plan on how to react if one of the components failed or crashed.

docs/ansible/wiki/drupal-apache-update.md

+---
+title: Ansible Wiki Drupal Apache Update
+tags:
+- ansible
+---
 To update Drupal's apache configuration - optionally with basic auth, letsencrypt, etc. - you should use the command
 
 ```

docs/ansible/wiki/drupal-deployment.md

+---
+title: Ansible Wiki Drupal Deployment
+tags:
+- ansible
+---
 # Drupal deployment
 
 ## Adding a new site

docs/ansible/wiki/drush-fetch-aliases.md

+---
+title: Ansible Wiki Drush Fetch Aliases
+tags:
+- ansible
+---
 Hosts that have drush installed will have comprehensive and always-up-to-date drush alias files and they ar build such that they can be used locally as well so that drush can access the remote hosts easily.
 
 To update your local host with the latest alias definitions, simply run this script: