Not working with Debian 9

[laukaichung]

The role doesn't work in Debian 9.
It will complain about the kernel requiring some patch when aa-enforce profiles

- cache read/write disabled /sys/kernel/security/apparmor/features interface file missing
(kernel needs apparmor 2.4 compatibility patch)

I've followed these instructions to get apparmor to work manually after the installation

This step sudo grub-mkconfig -o /boot/grub/grub.cfg may be crucial for Debian 9 to work

$ sudo apt install -y apparmor apparmor-utils \
       apparmor-profiles apparmor-profiles-extra
$ sudo systemctl enable apparmor
$ . /etc/default/grub
$ V="${GRUB_CMDLINE_LINUX} apparmor=1 security=apparmor"
$ sudo sed -e "s/^GRUB_CMDLINE_LINUX=.*/GRUB_CMDLINE_LINUX=\"${V}\"/g" \
       -i /etc/default/grub
$ sudo grub-mkconfig -o /boot/grub/grub.cfg
$ sudo reboot

$ for p in /etc/apparmor.d/*; do sudo aa-enforce "${p}"; done
$ sudo systemctl reload apparmor

[drybjed]

There's the debops.grub role which can be used to configure boot options, but I don't think that it should be used as a dependency of debops.apparmor (when the old role is integrated with the rest of DebOps). Setting up AppArmor will probably always involve a reboot of the system to enable the functionality in the kernel.

I wonder... apparmor and apparmor-utils packages are the userspace tools. What happens when you enable AppArmor in the kernel options without installing them? I haven't checked but I think that system runs as normal and the required AppArmor interface in the kernel is exposed in /sys/, installing the userspace tools lets you use AppArmor without the need for a reboot. At least, I think that's what would happen, heven't checked yet.

If that's the case, I think that AppArmor support would need to be separated into two steps:

• enable the support via debops.grub role, there could even be a boolean variable in the role that does this, and reboot the host
• run the debops.apparmor role to configure the userspace tools

[laukaichung]

@drybjed

Do I need to explicitly run debops service/apparmor -l myserver for any of the roles from debops-contrib?

Running debops doesn't seem to install apparmor.

My fresh server comes with libapparmor1

#dpkg -l | grep apparmor

ii  libapparmor1:amd64             2.11.0-3                       amd64       

Make a soft link to the main debops playbook directory

ln -s contrib/apparmor.yml ./local/debops/ansible/playbooks/service/apparmor.yml

inventory/hosts

[debops_all_hosts]
myserver ansible_host={{ip}}

[debops_service_apparmor:children]
debops_all_hosts

After running

#debops bootstrap --limit myserver --user root --ask-pass -c paramiko
#debops

the apparmor and apparmor-utils are nowhere to be seen. My server still only has libapparmor1:amd64

I need to run debops service/apparmor -l myserver in order to have apparmor installed.

[drybjed]

Short answer: yes, you need to run them separately at the moment.

As to why, it's a bit complicated. In the beginning, DebOps (which wasn't called DebOps at the time) was being developed in a single git repository with tests performed on Travis-CI. Unfortunately, at the time the number of roles (around 60) and length of the playbook meant that tests on Travis approached the 20 minute timeout limit, so I had to find another way to test the roles. To fix that issue I decided to split the roles into their own git repositories in the debops organization on GitHub, which allowed for testing each role separately on Travis-CI.

Unfortunately another problem quickly arose, where adding roles from other users without any help from the project maintainers was impossible - you had to create a new repository, tell me about it, then add my account to that repository and give it over so that I could add it to the debops organization as well as to the debops-playbooks repository. Keep in mind that Ansible stops execution of the playbook if the roles are missing, so it always was an "all or nothing" deal, roles needed to be integrated in this fashion before they could be added to the main playbook, otherwise Ansible wouldn't work.

Another tidbit to remember is that the debops-playbooks repository was supposed to be read only so that you could get updates; to integrate your roles in the main playbook you would need to mess with the repository code. I think that this was a design mistake on my part, since Ansible can use multiple playbooks together by chaining them, having the script handle the playbook that way (skip the missing ones, include a set of defaults, etc.) would be a better solution for this. Hindsight, I guess.

To make all this process somewhat bearable, I created the debops-contrib organization on GitHub, so that people that wanted to maintain their own roles for DebOps could be added there. Now, they could create git repositories for their roles directly in that organization and maintain them separately from the main DebOps roles. My plan was to, after the main project stabilizes a bit, migrate the roles from debops-contrib to main organization to be integrated with the rest of the project. I think that during this period I integrated just a few roles that way, @ypid's debops.cryptsetup among them.

And here we are, a few years later. The project still hasn't really had a 'stable' release, and in the meantime I decided to completely redesign the development model. Now, DebOps is back again in a single git monorepo, and I'm working on the new test infrastructure based on Debian Stretch, GitLab CI, Vagrant, LXC and KVM - it's coming along nicely, but there are still a few corner cases I need to fix before releasing it. At the moment I try not to do any drastic changes to the roles and playbooks, since there are no tests to ensure they work correctly - the accasional changes you see are small fixes so that roles work in the new test environment. When testing is ready, the work on Ansible roles will resume in earnest.

As for the debops-contrib roles - because everything is now in a single repository, it's very easy to include them in the main project. You just fork the DebOps monorepo, create a new branch and add your new roles. When they are ready, you can just submit a PR against the monorepo to be included in the main project. Or, if you don't want to share, just rebase your separate branch on the main project branch.

As you can see in the monorepo ansible/roles/ directory, some of the debops-contrib roles are already added in, debops-contrib.apparmor among them. However they are still not included in the main playbook, due to above reasons (lack of testing, and me being busy with writing the test infrastructure at the moment). I want to integrate them with the rest of the project at some point, so stay tuned. :-)

Edit(ypid): Fix small typo.

[ypid]

Hey @stonecold123

The role works nicely for me on Debian 8 and 9. I am not sure why it does not work for you. The commands you mentioned are basically the same as done by the role.