[debops] Philosophical design usage of debops
drybjed at drybjed.net
Tue Sep 8 19:09:06 CEST 2015
On Sep 08, Hendrik Visage wrote:
>> Just a heads up - 'debops.docker' role relies on DebOps-managed environment, for
>> example 'debops.core' role variables are used to mange common directory paths
>> and facts about nameserver/search configuration in /etc/resolv.conf are used
>> to configure Docker; 'debops.pki' environment is used to handle variables.
>> Above playbook would work fine if you apply it on a host that already has been
>> configured by DebOps, but you might get issues otherwise.
> So I first have to run debops's debops.bootstrap role before I attempt
> the debops.docker, correct?
The ideal way everything is written for would be this:
- start with a minimal Debian install, preferably just base netinst + SSH;
I usually don't install anything extra in the d-i, reboot the host and
install 'openssh-server' without recommended packages. On Debian Jessie you
might want to go and enable password root login at this time, and set a root
password. Oh, and don't create a normal user account during installation.
- if it's a clean OS install, add it to Ansible inventory and run:
debops bootstrap -l host -u root -k
This will prepare the installed system to be managed by Ansible / DebOps.
You will get an user account, your SSH keys will be installed on the root
and user account. When this playbook is finished, the host should be in
a state it is if it has been preseeded or generated by LXC template,
- After above steps are done, run command:
debops -l host
This should run the main 'common.yml' DebOps playbook and additional
playbooks which are enabled by adding a host to specific Ansible groups. For
example, if you would want to setup Docker on that host, just add it to
[debops_docker] host group.
If you don't want to do all this and want just the essentials, after you setup
your SSH connection and sudo access on the host, you need to run at least
'debops.core' role to setup a base set of Ansible custom facts DebOps roles
expect. If you want to install 'debops.docker' role, it will pull with it
'debops.etc_services' and 'debops.ferm'. They don't have their own
dependencies but first one will manage '/etc/services' and the second one will
manage the firewall which is pretty restrictive - expect to be locked out.
To avoid being locked out, you might want to use 'debops.sshd' role to setup
SSH server configuration and additional iptables / tcpwrappers rules. Which
would also require setting up SSH keys correctly because by default
'debops.sshd' disables password authentication. So, you can use 'debops.users'
to setup an user account and its keys. SSHd role will also use 'debops.ferm'
and 'debops.tcpwrappers' to manage these services, as well as
'debops.apt_preferences' to install 'openssh*' packages from Debian Jessie, in
case you are doing this all on Wheezy.
So, that's basically it. The rest of the common roles are basically either
flufff that installs some useful CLI applications like htop, or network
configuration, because on a server you most likely want bridges anyway for
your containers / VMs, Postfix as SMTP server to communicate with you in
a reasonable manner, package upgrades to keep the system up to date, and
I guess that's basically it.
I would suggest that if you haven't, you should check what the default DebOps
playbook sets up for you. You might come to like it. :-) You might ask, why
all this is needed - DebOps is geared towards production use, which means
a higher security measures in place - reasonable firewall, TCP wrappers just
in case, enforcing harder passwords if necessary, etc. Common playbook is here
to provide a base OS configuration ready for production use, no matter what
the environment - hardware system, OpenVZ, LXC, Docker, KVM, Virtualbox,
VMWare, what have you. By using it you can be sure that other DebOps roles
will work, since they are written with this environment in mind. If it's not
there, they may break.
>> OK, I see the issue. Support for 'ferm' was disabled so it was not installed,
>> but without it patch cannot be applied because the init script is missing.
>> Good catch, I'm going to move the patch-related tasks to separate file and add
>> a condition on it to only do the patching if 'ferm' is enabled.
> I might enable the ferm stuff a tad laters, but these specifics I are
> all behind firewalls, and I actually need sshguard rather than ferm :s
The issue with ferm is already fixed in the GitHub repository (it's not yet
tagged on Ansible Galaxy). There's no sshguard, but there's fail2ban role if
you're into that. However, default debops.sshd role sets up OpenSSH server
reasonably protected, with a limiter in the firewall. You should check it out;
I find that if a host shouldn't be publicly accessible (like a GitLab server
for example), adding a set of hosts to the sshd_whitelist variable is usually
enough to protect it without fail2ban getting in the way.
More information about the debops-users