Ansible Collection - bloodymage.autonomy

Description
Installation
Usage
Features and Advantages
Similar Projects
Sources
Contributing
License

Description

This collection is a set of ansible playbooks that you can use to build and maintain your own personal self-hosted services. Initial services are:

Certificate Authorities (Internal and ACME)
An SSH Certificate Authority
DNS (Bind9 / CloudFlare)
Identity Management (Samba Active Directory)
Email (Postfix and Dovecot)
Address Book and Calendars (Nextcloud)
Cloud Storage (Nextcloud)
File server (Samba / NFS)

For access to these services, a focus on centralized user management with a goal of single sign on across all services. Eventually I will add smart card capabilities to minimize password requirements.

For single signon, I use native SSO capabilities where possible, keycloak Identity Provider native SSO doesn't work.

There are three reasons I had with creating this with this project.

I wanted to learn how to use Ansible
I wanted to better control my data.
I wanted a way to quickly and easily rebuild my network if absolutely necessary.

So far, each server is configured without using docker containers or any other group packages, for example: dovecot and postfix vs iRedMail. I chose this route to learn as much as possible about each service and it's requirements.

Some smaller goals that I have for this project is minimizing the variables I have to define in my inventory. For each role, having sensible defaults which can be modified at runtime based on other configuration settings. For example if you are using smart cards, enable smart card required settings. These basic options can be set via inventories. In addition, I have set it up to simplify password management for various services by using ansible's passwordstore lookup to generate and save any passwords necessary.

Another overall goal, is minimizing impact to the complete system if one piece fails. This is why Samba uses Bind9 as it's DNS server rather than it's own internal DNS server.

Installation

Ansible Galaxy

TBD

Github

mkdir -p ~/.ansible/collections/ansible_collections/bloodymage
cd ~/.ansible/collections/ansible_collections/bloodymage
git clone https://github.com/bloodymage/ansible-collection-autonomy autonomy

Usage

Create GPG

Create a GPG key for the user that will be using ansible and the collection playbooks.

Create your inventory.

Create your inventory. Set variables according to Variables. Again, most variables are designed to be optional. For the network zone it expects a naming scheme along the lines of: "zone.example.com"

For example, your internal network will be internal.example.com, and a dmz zone would be dmz.example.com, and each host will be named host.internal.example.com. See docs/INVENTORY.md for more information.

First run:

ansible-playbook bloodymage/autonomy/playbooks/ansible.yml

ansible-playbook bloodymage/autonomy/playbooks/control.yml --tags ansible

Both of the above will install all the necessary dependencies that this collection requires to run ansible. It will also configure your ~/.ansible.cfg. If you wish to reconfigure your ~/.ansible.cfg you can run either of the above again.

After ansible is configured, from then on you run:

ansible-playbook bloodymage/autonomy/playbooks/site.yml

This will create your site.

Any host that you wish to be accessible from the outside world, will use letsencrypt for certs, otherwise it will use internal certificate authority certs.

Roles (Full list)

Identity Management

Samba

Realm Users

Email

Dovecot

Postfix

Groupware (Calendar and Contacts)

Nextcloud

Cloud Storage / File sync / Fileserver

Nextcloud

Samba

Variables

This section provides the bare minimum listing of variables that need to be defined. For the full listing see docs/VARIABLES.md. Note: This is still in early development. Some of the variable descriptions and requirements listed below pertain more to how it is planned to eventually work, than how it works right now.

Global Variables

Decisions

autonomy_realm_identity_management_system: ""

Options:

"" (Not set)
samba
openldap (planned for the future)
freeipa (planned for the future)

So far, this collection has really only been tested with this variable set to samba. You must set it yourself. Things can, and most likely will go wrong if it's not set to samba.

Network structure

autonomy_root_domain: "example.com"

This next variable, I hope to eliminate one day. To do so, I need to set the values based on the zone group_vars. For now, it may seem redundant, but it is required.

within each dictionary, the 'samba_domain' variable is semi-optional, if undefined it defaults to 'no'. It needs to be set to yes if you have a samba domain in that zone.

The 'type' variable, and the 'autonomy_zone_type' variable below it have the following options:

internal
dmz
public

autonomy_zones:
  - name: "internal"
    type: "internal"
    domain: "internal.{{ autonomy_root_domain }}"
    samba_domain: yes
  - name: "dmz"
    type: "dmz"
    domain: "dmz.{{ autonomy_root_domain }}"
  - name: "example"
    type: "public"
    domain: "{{ autonomy_root_domain }}"

For each zone, you'll need to set the following group variables:

autonomy_zone_type: "internal"
autonomy_zone_name: "internal"

These are required to match the 'name' and 'type' set in the autonomy_zones listing.

For Public Zones it's recommended you also add:

autonomy_root_domain: "{{ autonomy_zone_name }}.com" or .net, .org, etc
autonomy_domain: "{{ autonomy_root_domain }}"

Users

users:
  - username: bob          (mandatory)
    id_number: 1000        (mandatory)

Domain Users

domain_users:
  - given_name: Bob        (Mandatory)
    id_number: 10000       (Mandatory)
    username: bob          (optional)
    surname: bobsurname    (optional)
    middle_name: bobmid    (optional)
    password:              (optional)

For domain users, if the username is not defined, then it will be created based on other defined variables (given_name, surname if available, middle_name if available, and a random number. If password is defined, the defined password will be used, otherwise a password will be generated (see Passwords)

Role variables

Each role's variables are defined in their README.md file.

Passwords

Passwords are managed through the use of Password Store. To view the passwords in the password store type: "pass ..."

If you wish to manually generate your passwords, the following passwords can be defined in your vault:

keycloak_admin_password
keycloak_keystore_password
ownca_root_password
ownca_intermediate_password
ownca_component_password
ownca_identity_password
ownca_codesign_password
samba_administrator_password

For more information see: Password Storage

Post run configuration.

Not everything is configured via ansible. There are a few things that can't be done (yet, hopefully?) that you will need to configure manually yourself.

Features and Advantages

Identity Management

This collection can use a Samba domain for identity management. This way you can have one password for all services:

Login
Email
Nextcloud (Calendars, Cloud Storage)
File Servers

Planned modifications will be single sign on, through use of Kerberos and Keycloak. This partially works now, email single sign on in linux for clients that support GSSAPI currently works. Keycloak and nextcloud can be configured (through their web interface) to use single sign on as well. The tweaks that are necessary involve windows email clients (Thunderbird works, Outlook does not) and configuring keycloak and nextcloud through their CLI via ansbile.

A note on Samba and DNS: While Samba provides it's own internal DNS server, this setup has opted to use Bind9 DNS instead, and configure Samba DCs to use Bind9. This is decision was made to minimize the impact to the various network services the event of the Samba DC process crashing. In that case only the Samba DC service is lost, DNS will still work.

Certificate Authority

This collection will maintain an internal certificate authority. It will also configure the browsers to recognize your certificate authority. So all internal sites are verified. In addition this allows you to use smart cards authentication within active directory.

For sites that are publicly available, the site will use an acme ca (Let's encrypt, etc).

Password Storage

By default, all passwords default variables are set to "password." When a password is encountered that is set to "password," a password will be generated using password_store, and the generated password will be used. This creates the following advantages:

You do not need to generate your passwords yourself.
You can create backups, and distribute the passwords via git/gpg (Add specific user gpg keys to any folder you wish to grant access. )

Not yet implemented advantages:

If you believe multiple passwords may be compromised, you can easily force a regeneration of all passwords. Plan is to add a tags for password regeneration. Currently, you can use the password store itself to modify the password(s).

DNS

This collection uses bind9 for internal dns, including internal access of public zones.

For public access of public zones, it uses cloudflare dns. Cloudflare DNS can configure MX, SPF (TXT), DMARC, and DKIM records for mail services, and will update them automatically.

Role structure

Each role is built with the idea of do one thing, and do it well. So there will be many more roles than other projects might have. The advantage is that you don't have to run every role every time. Each role can be selected individually by using '--tag' with the role's name, for example '--tag dovecot' will run the dovecot role. If you wish to run all roles related to email servers, you would run the playbook 'mailservers.yml'

Similar Projects

Each of these projects are excellent projects, they didn't quite meet my needs.

Again, I wanted to actually learn how to use ansible.
I am in a mixed linux/windows environment. So, I wanted a Samba AD Domain, which none provide.
I wanted smart card support, which none provided.

Ansible Based

Debops (DebOps Github Repo)

Your Debian-based data center in a box.

The DebOps project is a set of Free and Open Source tools that let users bootstrap and manage an IT infrastructure based on Debian or Ubuntu operating systems. Ansible is used as the main configuration management platform. DebOps provides a collection of Ansible roles that manage various services, as well as a set of Ansible playbooks that tie them together in a highly integrated environment.

Sovereign

Sovereign is a set of ansible playbooks to build and maintain your own private servers:

email
calendar
contacts
file sync
IRC bouncer
VPN
and more.

Homebox

A set of Ansible scripts to setup a secure email and personal files server.

Project	Autonomy	DebOps	Sovereign	HomeBox
Uses Ansible	Yes	Yes	Yes	No
Email	Dovecot Postfix	Dovecot Postfix
Identity Management	Active Directory (Samba)	LDAP (OpenLDAP)
Groupware	Nextcloud	Nextcloud? Owncloud	OwnCloud
Cloud Storage	Nextcloud	Nextcloud? Owncloud	OwnCloud
Certificate Authority	Internal Let's Encrypt
DNS	Bind9
Operating System Support	Linux	Linux	Linux
Distribution Support	Debian	Debian	Debian
Smart Card Support	Yes*
License	MIT	GPLv3	GPLv3	GPLv3
Website	https://github.com/bloodymage/ansible-collection-autonomy	https://debops.org	https://github.com/sovereign/sovereign	https://github.com/progmaticltd/homebox

Smart Card Support is still buggy

Non-Ansible Based

FreedomBox

FreedomBox is a private server for non-experts: it lets you install and configure server applications with only a few clicks. It runs on cheap hardware of your choice, uses your internet connection and power, and is under your control.

HomelabOS

Your offline-first privacy-centric personal data center.

Includes over 100 services you can easily self-host.

Yunohost

YunoHost is an operating system aiming for the simplest administration of a server, and therefore democratize self-hosting, while making sure it stays reliable, secure, ethical and lightweight. It is a copylefted libre software project maintained exclusively by volunteers. Technically, it can be seen as a distribution based on Debian GNU/Linux and can be installed on many kinds of hardware.

Related Projects

Hearthminion

The Hearthminion ansible collection expands on this collection adding in new features relating to home automation and entertainment.

Home Assistant
MythTV
RetroPie

References and inspiration

Contributing

How to Contribute

License

MIT

Author Information

G Derber gd.github@bloodymage.org

bloodymage / ansible-collection-autonomy

readme

Ansible Collection - bloodymage.autonomy

Description

Installation

Ansible Galaxy

Github

Usage

Create GPG

Create your inventory.

Roles (Full list)

Identity Management

Email

Groupware (Calendar and Contacts)

Cloud Storage / File sync / Fileserver

Global Variables

Decisions

Network structure

Users

Domain Users

Role variables

Passwords

Post run configuration.

Features and Advantages

Identity Management

Certificate Authority

Password Storage

DNS

Role structure

Similar Projects

Ansible Based

Debops (DebOps Github Repo)

Non-Ansible Based

Related Projects

References and inspiration

Contributing

License

Author Information