Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Adds package builds for Focal #5465

Merged
merged 7 commits into from
Sep 3, 2020
Merged

Adds package builds for Focal #5465

merged 7 commits into from
Sep 3, 2020

Conversation

kushaldas
Copy link
Contributor

@kushaldas kushaldas commented Aug 24, 2020

Status

Ready for review

Description of Changes

Fixes #5449

This PR contains the changes required for securedrop-app-code and ossec packages
to be built on Ubuntu Focal. This requires #5458 to be merged first, so that I can rebase.

Testing

  • make build-debs-focal should create all the related packages for Focal
  • make build-debs builds packages for Xenial.

Deployment

Any special considerations for deployment? Consider both:

  1. Upgrading existing production instances.
  2. New installs.

Checklist

If you made changes to the server application code:

  • Linting (make lint) and tests (make test) pass in the development container

If you made changes to securedrop-admin:

  • Linting and tests (make -C admin test) pass in the admin development container

If you made changes to the system configuration:

If you made non-trivial code changes:

  • I have written a test plan and validated it for this PR

If you made changes to documentation:

  • Doc linting (make docs-lint) passed locally

If you added or updated a code dependency:

Choose one of the following:

  • I have performed a diff review and pasted the contents to the packaging wiki
  • I would like someone else to do the diff review

@eloquence eloquence changed the title Adds pakcage builds for Focal Adds package builds for Focal Aug 24, 2020
@kushaldas kushaldas force-pushed the focal_package_build branch from 1f458c9 to 1b4f03b Compare August 24, 2020 16:06
@redshiftzero redshiftzero mentioned this pull request Aug 24, 2020
53 tasks
Copy link
Contributor

@conorsch conorsch left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

First pass on visual review, requesting some cleanup between the various build directories. Much of the work here is intentionally copy/pasted from the xenial dirs, and I appreciate the your caution in avoiding breaking xenial-specific logic, @kushaldas. See in-line for opportunities to consolidate, or if not, at least document explicitly what's different and why it's different under focal.

Although I should have suggested it in #5444, the "make build-debs-focal" target is skipping all tests, even though the tests are present (but failing). We should either fix the packaging tests to get them passing, or else update the makefile target to include the "notest" string for clarity.

override_dh_virtualenv:
dh_virtualenv \
--python=/usr/bin/python3.8 \
--extra-pip-arg "--verbose" \
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The only changes I can find in the rules file between xenial & focal are:

  1. python3.5 vs. python3.8
  2. xenial contains --setuptools, whereas focal does not

Ideally we'd have this file templated so the rest is the same, but for now, can you add a comment explaining why setuptools is required for xenial but not for focal?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I will add the setuptools, that was a mistake. Also, I will try to make it a template.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I did and then remembered why i don't need it. By default it will install latest setuptools and with --setuptools flag we can now specify a specific version.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

By default it will install

Does "it" refer to the dh-virtualenv package? Even if the --setuptools flag is truly not required for the build process—and I agree, it doesn't appear to be—we still have an entire file duplicated except for this one flag, so a comment should be added to explain why it's not necessary.

Homepage: https://securedrop.org
Build-Depends: debhelper (>= 9), dh-python, python3-all, python3-setuptools, dh-systemd, dh-virtualenv
Standards-Version: 3.9.8
X-Python3-Version: >= 3.8
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is the X-Python3-Version field actually required? A quick glance at the dh-virtualenv source indicates it's not really used anywhere.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Removed.

Architecture: amd64
Conflicts: libapache2-mod-wsgi,supervisor
Replaces: libapache2-mod-wsgi,supervisor
Depends: ${dist:Depends}, ${misc:Depends}, ${python3:Depends}, apache2, apparmor-utils, coreutils, gnupg2, haveged, libapache2-mod-xsendfile, libpython3.8, paxctld, python3, redis-server, securedrop-config, securedrop-keyring, sqlite3
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The "Depends" line differs only in 3.5 -> 3.8 for the python packages. Can we not use the same name "python3" for both? I realize you'd have to touch xenial files to make this work. What do you think would be easiest to maintain for the remainder of the LTS window?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LTS releases are not supposed to upgrade Python version. That is why I wanted to go this (easy) way.

Conflicts: securedrop-ossec-server
Description: Installs the securedrop pre-configured OSSEC agent
This package installs an OSSEC agent pre-configured for the
SecureDrop app server.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Solid approach to multi-distro support. 👍 However, elsewhere in the diff I see that install_files/securedrop-ossec-agent/DEBIAN/control → ...s/build-ossec-deb-pkg/files/control-focal. Given thecontrol.j2introduction here, it apepars thatbuild-ossec-deb-pkg/files/control-focal` is no longer necessary, and should be removed.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@conorsch These are two different packages :) ossec-agent and securedrop-ossec-agent.


-- SecureDrop Team <[email protected]> Tue, 12 May 2020 18:37:42 +0000

securedrop-app-code (1.2.2+xenial) xenial; urgency=medium
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Focal changelog should not include historical xenial versions. Remove those, and start with the current/latest version for the focal history. (We did the same when moving from trusty to xenial.)

@kushaldas kushaldas force-pushed the focal_package_build branch from 771ac3c to aaf9dcc Compare August 26, 2020 13:23
@rmol
Copy link
Contributor

rmol commented Aug 26, 2020

It would run a higher risk of breaking the existing Xenial packaging, of course, but would it be possible (or worth the effort) to isolate all the release-specific differences (package dependency lists, paths, whatever) into variable files, and have those included at a single point, instead of sprinkling the "if focal" throughout?

Copy link
Contributor

@emkll emkll left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks @kushaldas , I agree with what others have said here, and I am pleased to report the packages are now built successfully 🎉

As mentioned by a previous reviewer in #5465 (review), this will not run the testinfra tests for packages, which can be useful to guard against regressions when doing packaging logic changes. When running the focal builder with tests (build-debs.sh test focal), I am observing 22 failing tests.

We should address as part of this PR, or file a follow-up ticket (and track it in the epic). I would lean towards addressing the tests here to both ease review and prevent future regressions.

@kushaldas kushaldas force-pushed the focal_package_build branch from aaf9dcc to 1b28043 Compare August 27, 2020 12:39
@kushaldas
Copy link
Contributor Author

It would run a higher risk of breaking the existing Xenial packaging, of course, but would it be possible (or worth the effort) to isolate all the release-specific differences (package dependency lists, paths, whatever) into variable files, and have those included at a single point, instead of sprinkling the "if focal" throughout?

I am not sure, also the plan was to keep as minimal change as possible for this PR.

@@ -1,5 +1,5 @@
---
build_ossec_deb_pkg_dependencies: ['libevent1-dev','libpcre2-dev']
build_ossec_deb_pkg_dependencies: ['libevent-dev','libpcre2-dev']
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why is this dependency changed?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

+1, if we don't have to change this dependency, let's not. @kushaldas can you check whether the libevent1-dev is sufficient for both platforms? If not, can you provide documentation that libevent-dev is correct for both?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This has to updated based on Focal or Xenial.

@kushaldas kushaldas force-pushed the focal_package_build branch from 1b28043 to 57fca68 Compare August 27, 2020 17:06
Depends: ${dist:Depends}, ${misc:Depends}, ${python3:Depends}, apache2, apparmor-utils, coreutils, gnupg2, haveged, libapache2-mod-xsendfile, libpython3.5, paxctld, python3 (>= 3.5), python3 (<< 3.6), redis-server, securedrop-config, securedrop-keyring, sqlite3
{% endif %}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Much improved! As discussed today in tech meeting, can we further consolidate the dependencies for libpython3.8 -> libpython3 for both platforms? Maybe that's not possible, but if it is, it'd greatly simplify the logic in play.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It seems this can not be done.

# apt install libpython3  
Reading package lists... Done
Building dependency tree       
Reading state information... Done
E: Unable to locate package libpython3

@@ -6,7 +6,11 @@ Homepage: https://securedrop.org
Package: securedrop-ossec-server
Version: 3.6.0+1.6.0~rc1
Architecture: amd64
{% if securedrop_build_focal_support %}
Depends: libevent-2.1.7,libpcre2-8-0,ossec-server,securedrop-keyring,securedrop-config
{% else %}
Depends: libevent-1.4-2,libpcre2-8-0,ossec-server,securedrop-keyring,securedrop-config
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As above, perhaps we can standardize on a single libevent metapackage that would work well. Can you check whether that's possible and add if so?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

# apt install libevent    
Reading package lists... Done
Building dependency tree       
Reading state information... Done
E: Unable to locate package libevent

This is also not possible due to package naming.

@conorsch
Copy link
Contributor

Only very small changes remain, mostly cleaning up package names and preferring cross-distribution metapackage names where possible. It may not be possible everywhere, but let's reduce the number of times we're forced to say if/else in the build logic.

As mentioned by a previous reviewer in #5465 (review), this will not run the testinfra tests for packages, which can be useful to guard against regressions when doing packaging logic changes. When running the focal builder with tests (build-debs.sh test focal), I am observing 22 failing tests.

I took the liberty of re-enabling the tests, since recent changes by @kushaldas resulted in all of them passing for me locally. I noticed an apparently-unrelated test flake on the staging (xenial) job in CI, so bounced.

After a few more package renames if possible, I think this is good to merge—then the next big item will be creating the staging env to use these new packages.

@conorsch
Copy link
Contributor

conorsch commented Sep 3, 2020

I plan to re-review this tomorrow, although it'd be grand to get #5477 in first, so we can be sure there are no regressions with the Xenial build logic.

kushaldas and others added 6 commits September 3, 2020 16:55
With different dependencies for Xenial and Focal
securedrop-app-code control file is now a template. We don't
need --setuptools in rules file as by default virtualenv will
install the latest setuptools.

Also clean changelog for Focal. We are using single usr.sbin.apache2
for both distribution. Updates the tests var as we rebased against
develop.
The testinfra suite for packages is fully passing for focal packages,
but the test suite was being skipped. Updated the package build targets
to be a bit more explicit about platforms.
libevent1-dev and libevent are two different package, libevent1
is being used in Xenial and libevent (which is the version 2) is
being used in Focal.
The latest virtualenv in Focal needs `--setuptools version` in the
command line, where as the old verison on Xenial will work with
just `--setuptools`. This commit also uses the same build system
from Xenial in Focal for building the securedrop-app-code package.
The test suite for validating deb packages was duplicated between Xenial
& Focal. That's going to run a risk of tests only being updated in a
single location, as was done in #5477. We have the ability to customize
behavior of the tests via env vars, so let's keep the same test suite
for now.
@conorsch conorsch self-requested a review September 3, 2020 22:51
Copy link
Contributor

@conorsch conorsch left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks great! The separation between distros is well done here. I suspect we may want to use platform-specific vars in the Ansible logic as continue to drive toward full Focal support, but that's best addressed as part of #5468 anyway.

I made one more change, de-duplicating the packaging tests between Xenial & Focal, to include the new tests we added in #5477. Both packaging targets and all the corresponding tests are passing for me locally, will merge once CI passes.

@conorsch conorsch merged commit 6013c5e into develop Sep 3, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Updating control & debian packaging files for Focal builds of securedrop-app-code and ossec packages
5 participants