You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
# Ansible Playbook for setting up a proxmox cluster with some debian and (LXC) container VMs, some tasmota IOT devices, and some Openwrt Access Points and Routers with VLAN separation of the SSIDs on each of the radios
1
+
# Ansible Playbook for Proxmox, Debian (LXC) Containers, VMs, Physical nodes, Tasmota IOT, OpenWRT Routers and Access Points
2
2
3
-
A couple of [Ansible](http://docs.ansible.com/) playbooks which runs a series of configuration steps to set up an SOE based on Debian, in order to provide a solid foundation for subsequent actions.
3
+
## Introduction
4
+
5
+
### What are we?
6
+
7
+
We're a couple of [Ansible](http://docs.ansible.com/) playbooks which
8
+
runs a series of configuration steps to set up a SOE based on Debian,
9
+
in order to provide a solid foundation for subsequent actions outside
10
+
the control of these playbooks. We can provide optional ***(partial)
11
+
configuration of a Proxmox cluster, manage Debian (LXC) containers,
12
+
VMs, and physical hardware (including some hardware management),
13
+
configuration of Tasmota IOT devices, and some OpenWRT Access Points
14
+
and Routers configurable with VLAN separation of the SSIDs on each of
15
+
the radios***.
4
16
5
17
It borrows heavily from the work of: [Luke Harvey](https://github.com/lukeharvey), [Bryan Kennedy](https://plusbryan.com/my-first-5-minutes-on-a-server-or-essential-security-for-linux-servers), [Ryan Eschinger](http://ryaneschinger.com/blog/securing-a-server-with-ansible/), [Ashley Rich](https://github.com/A5hleyRich/wordpress-ansible), and [Digital Ocean](https://www.digitalocean.com/community/tutorials/initial-server-setup-with-ubuntu-14-04)
6
18
7
19
It will perform the following:
8
-
* Create a new ansible "super user" with with root privileges and public key authentication on your proxmox and debian machines as well as the containers
* Create a new Ansible "super user" with with root privileges and public key authentication on your Proxmox and Debian machines as well as the containers
9
22
* Set root user credentials, and a primary user credentials, ssh keys, sudoers to root
10
23
* Implement several SSH hardening techniques
11
24
* Configure the timezone and enable time synchronization
12
25
* Modify the hostname and hosts file
13
26
* Install the admin's account with some nice .bashrc settings
14
27
* Install a package baseline appropriate for laptops, desktops, virtualisation hosts, containers, as appropriate
15
-
* Override some of debian's more annoying defaults
16
-
* Manage tasmota settings on your IOT devices
17
-
* Manage openwrt settings on your openwrt devices, including installing VLANs 10,30,40,70 and configuring radios on them
18
-
19
-
# What can we automate, what point-and-drool do we still need to do?
20
-
For physical boxes, VMs and LXC containers, I take the vanilla debian
28
+
* Override some of Debian's more annoying defaults per my opinionated opinion
29
+
* Manage Tasmota settings on your IOT devices
30
+
* Manage OpenWRT settings on your OpenWRT devices, including installing VLANs 10,30,40,70 and configuring radios on them
31
+
32
+
## What aren't we?
33
+
34
+
This playbook does not deploy Proxmox from scratch. It also doesn't
35
+
require Proxmox - but I find it very helpful. It can convert an
36
+
existing Proxmox cluster into being managed like any of our other
37
+
Debian SOE's (as far as our SOE interaction is concerned - user
38
+
accounts, keys, SOE configuration, backups, parts of networking;
39
+
however our playbooks don't do Proxmox management on the Proxmox
40
+
cluster). Likewise, we don't rely on any aspect of that (I do it,
41
+
because I want my helpful tools to also be used on my Proxmox
42
+
cluster). It doesn't deploy new VMs/CTs via Proxmox yet - you still
43
+
need to deploy them some other means, or manually. We also don't
44
+
preclude you doing management outside these playbooks. And of course,
45
+
not practicing what I preach, I don't have a properly thought out dev
46
+
environment nor have any automated testing infrastructure, because I
47
+
ain't doing anything important here. It doesn't manage every aspect
48
+
of machines - plenty of my machines can be redeployed from scratch and
49
+
will come up identically because their OS settings are managed via
50
+
these plays, and I have otherwise bind mounted their data into their
51
+
LXC containers, but someone had to populate that data and application
52
+
configuration in the first place. And the Proxmox cluster, Ceph
53
+
installation and configuration get managed the Proxmox way. But Ceph
54
+
secrets distribution and mounting on clients? We can manage that here.
55
+
56
+
While it can manage OpenWRT installations, it similarly isn't going to
57
+
deploy OpenWRT from scratch (although we can now apply a sysconfig
58
+
update and keep your firmware versions encoded into our config!), and
59
+
you'll want to set up initial networking, switching, wifi radio, etc
60
+
at initial installation time, but we come along and install our
61
+
packages and configs then tweak those UCI settings per our config.
62
+
63
+
Similarly story for Tasmota - very few of my devices have had their
64
+
GPIOs programmed through these playbooks, for example. But every time
65
+
I shift an AP around, I update the relevant primary/failover SSID of
66
+
all my Tasmota devices. It wouldn't be much work to arrange firmware
67
+
to be patched like in the OpenWRT playbook either (makes me more
68
+
nervous, but is it any harder to open up a bricked 240v smart plug
69
+
with triangle security screws vs a bricked TP-Link Archer D7 v1 held
70
+
together with fragile plastic clips?).
71
+
72
+
We are not DRY - many configs have to be specified all over the place.
73
+
Sorry.
74
+
75
+
## What can we automate, what point-and-drool do we still need to do?
76
+
77
+
For physical boxes, VMs and LXC containers (both provided through
78
+
Proxmox in my case), I rely on the machine being deployed the
79
+
traditional manual way (haven't yet automated talking to the Proxmox
80
+
API, even though the Proxmox boxes themselves are managed in this
81
+
playbook like any other Debian box). We take this vanilla Debian
21
82
install where I've just clicked through the install ISO steps in a
22
-
fairly braindead fashion (our playbooks goes and fixes a bunch of
23
-
things asked in install anyway), apply bootstrap.yml first, then
24
-
initial_server_config.yml to bring the configuration up to my SOE and
25
-
upon any further update to my config or after the machine is patched.
26
-
I don't automate the entire playbook being played because I still have
27
-
far too many pets and manual changes that need checking, and the
28
-
playbook is quite slow to run all the way through, so I'm frequently
29
-
using `--diff`, `--check` and `--tags` to limit the scope of changes
30
-
to what I'm currently concerned with. It would be easy to email
31
-
myself an output of `--check --diff initial_server_config.yml` every
32
-
night, but I get enough email as-is.
33
-
34
-
For OpenWRT APs and tasmota configurations however, we still rely on
83
+
fairly braindead fashion (I haven't setup Debian fully-automated, nor
84
+
preseed or anything like that; our playbooks goes and then fixes a
85
+
bunch of things asked in install anyway), apply bootstrap.yml first,
86
+
then initial_server_config.yml to bring the configuration up to my SOE
87
+
and upon any further update to my config or after the machine is
88
+
patched. I don't automate the entire playbook being regularly played
89
+
or setup automated drift-detection, because I still have far too many
90
+
pets and manual changes that need checking, and the playbook is quite
91
+
slow to run all the way through, so I'm frequently using `--diff`,
92
+
`--check` and `--tags` to limit the scope of changes to what I'm
93
+
currently concerned with. It would be easy to email myself an output
94
+
of `--check --diff initial_server_config.yml` every night, but I get
95
+
enough email as-is.
96
+
97
+
For OpenWRT APs and Tasmota configurations however, we still rely on
35
98
some manual configuration for a new device from scratch before
36
99
applying these playbooks - but it does make it easier to wholesale
37
100
change all of your SSIDs for example. For upgrades however, we can
38
101
automate all of the tasks needed to bring your device back into
39
102
compliance with your config without any manual configuration. I apply
40
-
it routinely after any minor upgrade of the openwrt device, perhaps
103
+
it routinely after any minor upgrade of the OpenWRT device, perhaps
41
104
checking with `--diff``--check` first if I'm a little nervous. I do
42
105
test on my VMs first (sometimes I'm even sensible enough to test on
43
106
one of my virtualised APs before I test it on my internet gateway),
44
107
and take a snapshot manually beforehand. For major upgrades, it
45
108
hasn't broken majorly for me yet, but my planning tends to be a little
46
-
more careful around these events. For setting up a new openwrt AP, my
109
+
more careful around these events. For setting up a new OpenWRT AP, my
47
110
manual configuration tends to be limited to setting switch vlan
48
111
tagging information in /etc/config/network, and assigning radio0 and
49
112
radio1 consistently with my other devices, before letting
50
113
uci_config.yml loose on VLAN and network definitions and what SSIDs
51
114
we've assigned to which radios. This sometimes involves swapping
52
115
radio0 and radio1 pci/hardware devices in /etc/config/wireless.
53
116
54
-
##Requirements
117
+
# Requirements
55
118
56
-
*[Ansible](http://docs.ansible.com/ansible/intro_installation.html) installed locally on your machine
57
-
* You probably want to install `ansible-mitogen` (and `python3-mitogen`) on your ansible server too, for my ansible.cfg sets `strategy = mitogen_linear` to greatly accelerate the playbook (it works with that setting disabled if you can't install migoten, but mitogen has never created any detectable problems for me). I have only tested this from a debian machine (debian 11,12).
119
+
*[Ansible](http://docs.ansible.com/ansible/intro_installation.html) installed locally on your machine to run the playbooks. Tested on Debian's Ansible from Debian 10 (Buster) to Debian 12 (Bookworm)
120
+
* You probably want to install `ansible-mitogen` (and `python3-mitogen`) on your Ansible server too, for my ansible.cfg sets `strategy = mitogen_linear` to greatly accelerate the playbook (it works with that setting disabled if you can't install migoten, but mitogen has never created any detectable problems for me). I have only tested this from a Debian machine (Debian 11,12).
58
121
* Ideally, you'd create a gpg encrypted file in misc/vault-password.gpg, and verify it can be read with: misc/get-vault-pass.sh
59
-
*Openwrt plays rely on [ansible-openwrt](https://github.com/gekmihesg/ansible-openwrt), which is published as a [galaxy collection](https://galaxy.ansible.com/ui/repo/published/nn708/openwrt/).
60
-
* Tasmota plays rely on [ansible-tasmota](https://github.com/tobias-richter/ansible-tasmota), which is available through [ansible galaxy](https://galaxy.ansible.com/ui/standalone/roles/tobias_richter/tasmota/), but which [I've modified](https://github.com/spacelama/ansible-tasmota) to allow for and transparently recovers from the tasmota device spontaneously rebooting after certain configurations are applied.
122
+
*OpenWRT plays rely on [ansible-openwrt](https://github.com/gekmihesg/ansible-openwrt), which is published as a [galaxy collection](https://galaxy.ansible.com/ui/repo/published/nn708/openwrt/).
123
+
* Tasmota plays rely on [ansible-tasmota](https://github.com/tobias-richter/ansible-tasmota), which is available through [ansible galaxy](https://galaxy.ansible.com/ui/standalone/roles/tobias_richter/tasmota/), but which [I've modified](https://github.com/spacelama/ansible-tasmota) to allow for and transparently recovers from the Tasmota device spontaneously rebooting after certain configurations are applied.
0 commit comments