adfinis / ansible-roles

This Git repository is deprecated, there is a Git repository per role.

ANSIBLE ROLES

This repository is deprecated. There is a repository per role on our GitHub page and those are also available via Ansible Galaxy.

Ansible roles to manage your infrastructure in an automated and reproducible way.

FEATURES

The goal of this repository is to provide a fully blown Ansible roles set to manage your infrastructure in an automated fashion whilst providing full reproducibility.

All roles support at least the following distributions:

• Debian 7 & 8 & 9
• Ubuntu 14.04 & 16.04
• Centos 6 & 7

In addition the roles take care of the necessary SELinux configuration if required.

REQUIREMENTS

In order to use the roles please make sure to fulfill the following requirements:

• FQDN configured on the target host
• Ansible 2.0+ is used

INSTALLATION

Below the required steps to include the roles into your playbooks and projects:

1. Create a project directory (git repository with playbooks, roles, group_vars and/or host_vars)
2. Add this repository as a git submodule (git submodule add https://github.com/adfinis-sygroup/ansible-roles.git adfinis-roles)
3. Configure Ansible to use the additional roles path

[defaults]
ansible_managed     = Warning: File is managed by Ansible [https://github.com/adfinis-sygroup/ansible-roles.git]
retry_files_enabled = False
hostfile            = ./hosts
roles_path          = ./adfinis-roles

4. Create your own project specific roles in the directory roles, Ansible will use both directories (with precedence of roles).

ROLES

Currently the repository features the following roles:

Role	Description
ansible	install base packages and Ansible related packages
console	manage standard tools, bashrc and vimrc
grub	install and configure grub
hostname	set system hostname
hwraid	hardware raid controller management tools
hw_vm_tools	install hardware and virtual machine tools, like guest tools for virtual machine hypervisors
ipmi	Manage IPMI devices
iptables	install iptables persistent services and configure iptables rules
mariadb	manage a mariadb server and client (if mariadb is not available, mysql will be installed instead)
motd	set the MOTD
network	manage network interfaces and IP addresses and routes
nginx	install and manage nginx
nodejs	install nodejs on a server
ntp	manage ntp client and server
pkg_mirror	manage system package sources
pki	PKI related stuff, like generate certificates and diffie-hellman parameters
postfix	manage postfix to send and receive email
rpcbind	manage rpcbind package and service
rsyslog	install and configure rsyslog
snmp	manage snmp server and client
ssh	manage ssh server and client
telegraf	install telegraf and create configurations
upgrade	install dist upgrades
users	manage POSIX users and groups

CONTRIBUTIONS

Contributions are more than welcome! Please feel free to open new issues or pull requests.

We have some contribution rules:

• Each change, regardless if it's a new role, a bug fix, a feature request, or another change, must be a merge request and another person must review it.
• The language is English, in the documentation, for pull requests, issues and also commit messages.
• Each role is listed in the README.
• Each role must have a meta information file ($ROLE/meta/main.yml).
• We use multiple features, like issue-tracker, pull-request, labels for requests and issues.
• The continuous integration must pass.

DEVELOPEMENT ENVIRONMENT

To setup the development environment you should clone the repository ansible-guide.

git clone https://github.com/adfinis-sygroup/ansible-guide.git
cd ansible-guide
git submodule update --init

There is a vagrant box for each supported distribution. vagrant up will start all boxes one by one and will automatically provision those with Ansible. To restart a provisioning task, you can use vagrant provision <distribution>.

CONTINUOUS INTEGRATION

The continuous integration (CI) will do some checks, like

• yaml syntax check
• Ansible syntax check
• Ansible linting (for best current practice and some additional checks)

LICENSE

GNU GENERAL PUBLIC LICENSE Version 3

See the LICENSE file.

ansible-roles's Issues

Multirepo vs. monorepo

As discussed already we should consider moving to a multi repo setup and then publish all roles on ansible-galaxy.

Pros:

• ansible-galaxy integration
• easier integration for other projects (allows cherry picking)
• higher possibility for contributions

Cons:

• We'll need some glue code to do testing and deployments
• Some kind of versioning has to be in place and consistent, otherwise it gets messy (at the moment enforced by using HEAD)

@hairmare / @keachi please post your views as well, especially procs and cons...

Props to @hairmare for making this a hot topic! 🌶️

role auth

Create a role auth to configure PAM and to enable some security features like /etc/security/access.conf.

Invalid meta platform CentOS7

I've just played around with Galaxy and I wasn't able to import a role with the following platform:

   platforms:
   - name: CentOS
       versions:
         - 7

It said: Invalid platform: CentOS-7 (skipping)

I think the platform for CentOS/RHEL has to be EL.

role network not writing correct interfaces files on debian 9

On (at least) Debian 9, this role writes a not working DNS configuration, since the /etc/resolv.conf is managed by systemd and changes by the role are overwritten. The fix is, that the DNS settings need to be written into the /etc/networking/interfaces.d/ files instead of /etc/resolv.conf.

Things to take into account:

• The role must be idempotent. So it might have to take the OS version into consideration.
• The same fix will probably affect RedHat too, so it has to be fixed there also.

Helpful Link and hint: https://wiki.ubuntuusers.de/interfaces/

    [..]
    dns-nameservers 10.2.4.1 95.128.34.42
    dns-search adfinis-sygroup.ch

role kvm hostsystem

Create a role to install virsh, kvm, qemu and make a base setup as a host system.

Refactor console role

As hinted in my review of #46 I feel the console role is in the need of an overhaul. It covers way to many concerns that should be covered by individual roles.

I propose we keep this role and trim it down so it only contains stuff related to the actual console/shell and not heaps of console tools. This way it can be used out of the box to install different kinds of opinionated setups.

At the very least I feel like the vim stuff would warrant its own "editor" role due to stuff like
https://github.com/adfinis-sygroup/ansible-roles/blob/aa46eb8d44ed0f49d697eb77d62d5128cfc58e1e/console/vars/RedHat.yml#L55-L56
https://github.com/adfinis-sygroup/ansible-roles/blob/aa46eb8d44ed0f49d697eb77d62d5128cfc58e1e/console/vars/RedHat.yml#L61-L65

I might also make sense to split out parts that install end user tooling into multiple other roles (ie. mail, selinux stuff, at, ...).

In the end I'd also like to be able to use the console role in scenarios where I just need a sanely configured console/shell and not much more.

Ansible 2.5 features

Ansible 2.5 was released a few weeks ago and we should check which new features should be integrated into the current roles:

https://github.com/ansible/ansible/blob/devel/CHANGELOG.md#25-kashmir---march-2018-estimated

hwraid and Debian 9/stretch support

ISSUE TYPE

• Bug Report

COMPONENT NAME

Role hwraid

ANSIBLE VERSION

ansible 2.3.1.0
  config file = /etc/ansible/ansible.cfg
  configured module search path = Default w/o overrides
  python version = 2.7.13 (default, Jul  2 2017, 22:24:59) [GCC 7.1.1 20170621]

CONFIGURATION

Nothing special.

OS / ENVIRONMENT

• Management Host: Arch Linux
• Target Host: Debian 9/stretch

SUMMARY

The role hwraid does not support Debian 9/stretch, because the upstream repositories doesn't support that yet.

STEPS TO REPRODUCE

- hosts: all
  roles:
    - hwraid

EXPECTED RESULTS

• On a HP server the packages hpacucli and hpssacli should be installed.
• On a IBM server the package megacli should be installed.

ACTUAL RESULTS

The task add the hp apt repository or add the hwraid.le-vert.net apt repository fails.

Add README.md files per role

The default of documenting individual roles with a markdown file is considered a best-practice and we should consider closing addressing this.

The ansible-galaxy commands init creates a default README that can be used as a basis to creating our own template. This template can then be used as an input to ansible-galaxy init --role-skeleton=/path/to/skeleton role_name (it's jinja2) enabling us to ensure consistant use of READMEs.

We might also want to consider letting the update docs probot help us remember to keep the docs up to date.

Test roles for supported Ansible version

According to the README we support Ansible 2.0+ but more and more tasks are being integrated that could break compatibility as newer roles are being used.

The CI should check all roles if their compatible with the supported Ansible version(s). In addition we need to discuss if Ansible 2.3+ or 2.4+ should be required and what that might impact (e.g. no longer executable on older OS, etc.).

role security

add a role security which contains tasks for CVE related stuff (e.g. blacklisting some kernel modules).

• CVE-2017-6074 - blacklist kernel module dccp