Merge pull request #4344 from zenmonkeykstop/4342-fix-qubes-staging-t…

…arget

update qubes staging Makefile target to use Xenial by default

devops/scripts/create-staging-env

@@ -27,9 +27,11 @@ fi
 if [[ -n "${VAGRANT_DEFAULT_PROVIDER:-}" ]] ; then
     securedrop_vm_provider="${VAGRANT_DEFAULT_PROVIDER}"
 # Check whether it appears we're running in Qubes, in which case the standard Vagrant
-# logic will not work at all, due to lack of nested virt support.
+# logic will not work at all, due to lack of nested virt support. The Qubes staging
+# environment uses Xenial template VMs only, so we also suppress the platform suffix.
 elif printenv | grep -q ^QUBES_ ; then
     securedrop_vm_provider="qubes"
+    securedrop_platform_suffix="" 
 elif [[ "${OSTYPE:-}" == "linux-gnu" ]]; then
     # Default to Libvirt for Linux users, which works well with Tails VM virtualization.
     securedrop_vm_provider="libvirt"

docs/development/qubes_staging.rst

@@ -99,6 +99,21 @@ Edit ``/etc/sudoers`` using ``visudo`` to make the sudo group line look like
 
    %sudo    ALL=(ALL) NOPASSWD: ALL
 
+
+Finally, update the machine's Grub configuration to use a consistent Ethernet device
+name across kernel versions. Edit the file ``/etc/default/grub``, changing the line:
+
+.. code:: sh
+
+   GRUB_CMDLINE_LINUX=""
+
+to
+
+.. code:: sh
+
+   GRUB_CMDLINE_LINUX="net.ifnames=0 biosdevname=0"
+
+
 When initial configuration is done, run ``qvm-shutdown sd-staging-base`` to shut it down.
 
 Clone VMs
@@ -139,7 +154,7 @@ Edit ``/etc/hosts`` on each host to include the hostname and IP for itself.
 Use ``sd-app`` and ``sd-mon``, omitting the ``-base`` suffix, since the cloned VMs
 will not have the suffix.
 
-Finally, on each host edit ``/etc/hostname`` to reflect the machine's name.
+Next, on each host edit ``/etc/hostname`` to reflect the machine's name.
 Again, omit the ``-base`` suffix.
 
 Halt each machine, then restart each from ``dom0``. The prompt in each console
@@ -224,7 +239,7 @@ Once finished, build the Debian packages for installation on the staging VMs.
 
 .. code::
 
-   make build-debs-xenial
+   make build-debs
 
 The ``.deb`` files will be available in ``build/``.
 
@@ -286,13 +301,6 @@ message ``RUNNING HANDLER [common : Wait for server to come back.]`` you must
 start the VMs again manually from ``dom0`` with the command 
 ``qvm-start sd-app && qvm-start sd-mon``.
 
-.. note::
-
- When you run ``make staging`` for the first time, after the installation of the 
- grsec kernel the ``eth0`` interfaces on ``sd-app`` and ``sd-mon`` may be 
- renamed to ``ens5``. In this case, you will need to update ``/etc/networking/interfaces``
- accordingly, restart the VMs, and run ``make staging`` again.
-
 The ``make staging`` command invokes the ``qubes-staging`` Molecule scenario. 
 You can also run constituent Molecule actions directly, rather than using
 the Makefile target: 
@@ -313,4 +321,9 @@ the Makefile target:
 That's it. You should now have a running, configured SecureDrop staging instance
 running on your Qubes machine. For day-to-day operation, you should run
 ``sd-dev`` in order to make code changes, and use the Molecule commands above
-to provision staging VMs on-demand.
+to provision staging VMs on-demand. To remove the staging instance, use the Molecule command:
+
+.. code:: sh
+
+   molecule destroy -s qubes-staging
+

molecule/qubes-staging/qubes-vars.yml

@@ -1,9 +1,8 @@
 ---
 # Support dynamic lookups for Qubes host IPs. The staging vars
 # in the Ansible config still assume hardcoded Vagrant-only IPs.
-primary_network_iface: eth0
-app_ip: "{{ hostvars['app-staging']['ansible_'+primary_network_iface].ipv4.address }}"
-monitor_ip: "{{ hostvars['mon-staging']['ansible_'+primary_network_iface].ipv4.address }}"
+app_ip: "{{ hostvars['app-staging']['ansible_default_ipv4'].address }}"
+monitor_ip: "{{ hostvars['mon-staging']['ansible_default_ipv4'].address }}"
 
 # Use hardcoded username from the manual VM provisioning step.
 ssh_users: sdadmin