ansible deployment bugs

[il-steffen]

Still a few issues with current deploy playbook. It works fine for normal fresh install but can be buggy when doing partial flows or upgrading existing install:

• missing the Makefile in remote mode, and actually the deploy recipies are not useful in this mode. Maybe it is fine to consider remote install only for automated deployments?
• partial execution due to existing files or using tags is not reliable, e.g. check_hardware or grub_menuentry_ids can be undefined. Maybe we have to encode these using set_fact or define a separate role to depend on?
• playbook should check HW capabilities before anything else. kernel install and grub update should depend on uname -a output, not /dev/kvm ioctl support.

[Wenzel]

• you are correct that the remote deployment still needs to reworked in terms of which workflow we want to enable in the end. The goal is not to enable another developer environment, if you want that, you can git clone on a server and make deploy kafl locally by yourself. The goal is to easily deploy kafl on an arbitrary amount of servers, and "trigger" a distributed campaign launch, from the host.
• the sole purpose of check_hardware tag is to be skipped during the CI. Can you describe the problem you faced ?
• I agree, however I wasn't able to reflect that in the intellabs.kafl collections. The hardware checks are implemented in the top-level fuzzer role, which depend on everything else. But the all the components are installed before the fuzzer role executes, and then it starts it's pre_tasks which finally checks the hardware. One solution could be use a dedicated role for that, and make it depend on every other component, so that it always executes first. (like the workaround I used for https://github.com/IntelLabs/kAFL/pull/81 and the default_vars_only role.

[il-steffen]

I didn't want to say it, but since you started with pre_role I was wondering if refactoring the roles based on action/type would make sense: pre-checks, clone/fetch, build, install, post-checks. Advantage is that it will probably work better to manage and execute individual stages this way. git repo management can easily be updated to perform update and status checks on all repos and we don't need several roles that just clone a repo. Disadvantage is that not everything is nicely separate, for instance qemu build dependencies are specific to that component and best encapsulated together with it.

• pre_checks - hardware, basic requiremetns
• clone/fetch - repo management and other download tasks
• build - we actually only have qemu, kafl and radamsa right now? host kernel is separate/optional
• install - kernel install, grub update, /dev/kvm group fix
• post_checks - check the KVM ioctls here and maybe a more intelligent reboot trigger?