On Wed, Jun 30, 2021 at 8:28 AM Alex Bennée <alex.ben...@linaro.org> wrote: > > > Cleber Rosa <cr...@redhat.com> writes: > > > To run basic jobs on custom runners, the environment needs to be > > properly set up. The most common requirement is having the right > > packages installed. > > > > The playbook introduced here covers the QEMU's project s390x and > > aarch64 machines. At the time this is being proposed, those machines > > have already had this playbook applied to them. > > > > Signed-off-by: Cleber Rosa <cr...@redhat.com> > > --- > > docs/devel/ci.rst | 40 +++++++++ > > scripts/ci/setup/.gitignore | 2 + > > scripts/ci/setup/build-environment.yml | 116 +++++++++++++++++++++++++ > > scripts/ci/setup/inventory.template | 1 + > > 4 files changed, 159 insertions(+) > > create mode 100644 scripts/ci/setup/.gitignore > > create mode 100644 scripts/ci/setup/build-environment.yml > > create mode 100644 scripts/ci/setup/inventory.template > > > > diff --git a/docs/devel/ci.rst b/docs/devel/ci.rst > > index 064ffa9988..bfedbb1025 100644 > > --- a/docs/devel/ci.rst > > +++ b/docs/devel/ci.rst > > @@ -30,3 +30,43 @@ The GitLab CI jobs definition for the custom runners are > > located under:: > > Custom runners entail custom machines. To see a list of the machines > > currently deployed in the QEMU GitLab CI and their maintainers, please > > refer to the QEMU `wiki <https://wiki.qemu.org/AdminContacts>`__. > > + > > +Machine Setup Howto > > +------------------- > > + > > +For all Linux based systems, the setup can be mostly automated by the > > +execution of two Ansible playbooks. Create an ``inventory`` file > > +under ``scripts/ci/setup``, such as this:: > > + > > + fully.qualified.domain > > + other.machine.hostname > > + > > +You may need to set some variables in the inventory file itself. One > > +very common need is to tell Ansible to use a Python 3 interpreter on > > +those hosts. This would look like:: > > + > > + fully.qualified.domain ansible_python_interpreter=/usr/bin/python3 > > + other.machine.hostname ansible_python_interpreter=/usr/bin/python3 > > I was able to put root@foo for the machines I had in my .ssh/config > > > + > > +Build environment > > +~~~~~~~~~~~~~~~~~ > > + > > +The ``scripts/ci/setup/build-environment.yml`` Ansible playbook will > > +set up machines with the environment needed to perform builds and run > > +QEMU tests. This playbook consists on the installation of various > > +required packages (and a general package update while at it). It > > +currently covers a number of different Linux distributions, but it can > > +be expanded to cover other systems. > > + > > +The minimum required version of Ansible successfully tested in this > > +playbook is 2.8.0 (a version check is embedded within the playbook > > +itself). To run the playbook, execute:: > > + > > + cd scripts/ci/setup > > + ansible-playbook -i inventory build-environment.yml > > + > > +Please note that most of the tasks in the playbook require superuser > > +privileges, such as those from the ``root`` account or those obtained > > +by ``sudo``. If necessary, please refer to ``ansible-playbook`` > > +options such as ``--become``, ``--become-method``, ``--become-user`` > > +and ``--ask-become-pass``. > > If the above works maybe worth mentioning here because just having root > ssh is probably the easiest way to manage a box.
If the host is internet-facing, there are lots of recommendations to disable root access using ssh (eg. https://www.redhat.com/sysadmin/administering-remote-systems). There are also recommendations from NIST and SANS. So, to avoid an unintended creation of an attack vector in the custom runners, I would personally prefer to let just the ansible tricks in the documentation than mentioning it is possible (and maybe easier) to enable root access thru ssh.
