Re: [PATCH v7 2/4] Jobs based on custom runners: build environment docs and playbook

["Alex Bennée" <alex.bennee@linaro.org>]

Willian Rampazzo <wrampazz@redhat.com> writes:

> On Wed, Jun 30, 2021 at 8:28 AM Alex Bennée <alex.bennee@linaro.org> wrote:
>>
>>
>> Cleber Rosa <crosa@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 <crosa@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.

I agree you don't want remote password based authentication. I use
key-based authentication because it seems easier to log in directly as
root than to keep trusting my user password to the remote console to
gain sudo privileges. Anyway either way I'm happy.

-- 
Alex Bennée