Feature #12277: Run our own email (IMAP/POP3/SMTP) server for automated tests run on lizard

Feature #12277

Run our own email (IMAP/POP3/SMTP) server for automated tests run on lizard

Added by intrigeri 2017-03-02 08:25:26 . Updated 2019-06-02 14:42:54 .

Status:

Needs Validation

Priority:

Normal

Assignee:

anonym

Category:

Continuous Integration

Target version:

2020

Start date:

2017-03-02

Due date:

% Done:

40%

Feature Branch:

test/11890-local-email-server

Type of work:

Sysadmin

Blueprint:

Starter:

Affected tool:

Email Client

Deliverable for:

Description

See Bug #11890#note-17 and Bug #11890#note-18 for more detailed specs.

Subtasks

Related issues

Related to Tails - Bug #11890: Checking credentials in Thunderbird autoconfig wizard sometimes fails in the test suite

In Progress

2016-10-31

History

#1 Updated by intrigeri 2017-03-02 08:26:22

Assignee changed from intrigeri to anonym
QA Check set to Info Needed

anonym, how urgent is that? Can it wait until the 3.1 or 3.2 cycle? I’m really not sure I can commit to anything better.

#2 Updated by intrigeri 2017-03-02 08:26:44

blocks Bug #11890: Checking credentials in Thunderbird autoconfig wizard sometimes fails in the test suite added

#3 Updated by anonym 2017-03-02 08:39:01

Assignee changed from anonym to intrigeri
QA Check deleted (~~Info Needed~~)

intrigeri wrote:
> anonym, how urgent is that?

Considering it’s not the last source of problems on Jenkins, not very.

> Can it wait until the 3.1 or 3.2 cycle? I’m really not sure I can commit to anything better.

Absolutely! I let you set the target version.

#4 Updated by intrigeri 2017-03-02 09:10:43

Target version set to Tails_3.2

#5 Updated by intrigeri 2017-09-14 13:26:24

Description updated

#6 Updated by intrigeri 2017-09-14 17:10:56

Some implementation ideas to start with, as notes to myself and also to groente who expressed interest in this topic:

Just like we have tails::tester::support::sftp and tails::tester::support::ssh classes, we would create a tails::tester::support::email class (that can possibly itself include tails::tester::support::email::dovecot and tails::tester::support::postfix if it gets too big or badly structured).
We can apply this new class on misc.lizard: it currently runs Postfix (like all our systems) that only listens on port 127.0.0.1:25. We could run another Postfix instance that listens on 127.0.0.2:587 (for the test suite trying to send email).
In Stretch, the Postfix systemd integration has multi-instance support which makes it easy to isolate that 2nd Postfix instance from the one we already have. See tails::whisperback::relay for an example.
Regarding imaps/pop3s, I would expect that the default dovecot configuration will do something very close to what we want. I would use the passwd-file driver for userdb and passdb, pointing to /etc/dovecot/userdb, but YMMV :)
I’m not sure what we should do about X.509 certificates. The easiest solution might be to use the snakeoil auto-generated keypair + cert, add support to our test suite for importing an arbitrary cert into the Thunderbird, and use that on isotesterN.lizard. Suggestions welcome!

#7 Updated by intrigeri 2017-09-26 05:35:55

Target version changed from Tails_3.2 to Tails_3.3

#8 Updated by intrigeri 2017-10-22 13:16:17

Subject changed from Run our own email (IMAP/POP3/SMTP) server for automated tests to Run our own email (IMAP/POP3/SMTP) server for automated tests run on lizard

#9 Updated by intrigeri 2017-10-22 14:57:39

intrigeri wrote:
> * We can apply this new class on misc.lizard: […]

To reduce coupling, we could instead run these support servers (Dovecot + Postfix + HTTPS for autoconfig) on each isotester that needs them. This would ease development/testing: I can enable this on my local isotester to start with, without having to rely on external stuff like misc.lizard. This also avoids having to do anything special wrt. DNS and firewalling, and has other advantages, see below. Resources needed should be negligible compared to our isotesters’ specs.

Now, I realize this starts to look like ~~Feature #6300~~, without the “framework” part: my goal here is to keep it simple and avoid adding too much complexity before we actually know what needs to be generic. And to start with I want to use system-managed services, not throw away ones that the test suite would set up and run itself.

I have a doubt wrt. the email account management: either we set it up via Puppet on the server side and hard-code it in the test suite config specific to each isotester (also deployed via Puppet). Or we generate both the account and the corresponding test suite config dynamically (e.g. at boot or in some test suite wrapper). The latter requires more work but avoids adding more hardcoded bits everywhere around the place. I’ll see.

> * I’m not sure what we should do about X.509 certificates. The easiest solution might be to use the snakeoil auto-generated keypair + cert, add support to our test suite for importing an arbitrary cert into the Thunderbird, and use that on isotesterN.lizard. Suggestions welcome!

Wrt. generating & using the snakeoil keypair on the server side:

it’s generated in the postinst script of the ssl-cert package
Postfix/Stretch uses it by default;
dovecot uses it by default since 1:2.2.31-1; too bad it’s not in Stretch nor stretch-backports, but it shouldn’t be too hard to steal the corresponding glue code/config until we upgrade isotesters to Buster.

Wrt. installing the cert into ThunderBird:

Start Thunderbird, cancel the wizard, close Thunderbird => cert8.db is created; use certutil -A (https://access.redhat.com/documentation/en-US/Red_Hat_Certificate_System/8.0/html/Admin_Guide/Managing_the_Certificate_Database.html#Installing_Certificates_Using_certutil) to add the snakeoil certificate to Thunderbird’s NSS database; then run the actual tests.
If the support email servers run on the isotester itself, no specific test suite config is needed: we can always import the SSL snakeoil cert into Thunderbird if it exists on the host system, regardless of whether we’re going to use it or not (i.e. regardless of whether we have config that tells the test suite to use an email address hosted by the setup this ticket is about). Otherwise we need to hardcode misc.lizard’s cert in puppet-tails_secrets_jenkins.git, which is always sad as it would add yet another reason why it’s painful to reinstall our systems from scratch (granted, it’s a small one, but they do add up).

anonym, if I do the services management part for isotesters, would you add the corresponding test suite bits? It should be limited to importing /etc/ssl/certs/ssl-cert-snakeoil.pem into Thunderbird, if this file exists, in the 3 affected scenarios. And it can be done without waiting for me, as we could very well start doing it now and it should not break anything, it’ll just be useless until I do my part. If you agree please file a dedicated ticket about it :)

#10 Updated by intrigeri 2017-10-23 05:37:50

Status changed from Confirmed to In Progress
% Done changed from 0 to 10

Made good progress: basic Postfix set up, Dovecot works (tested locally with Mutt over imaps), both using the snakeoil cert+key. Next step are local email delivery via Dovecot LDA, SASL authentication (using Dovecot) for Postfix, and serving a Thunderbird autoconfig file over HTTPS.

groente, feel free to look at the Puppet code (and the config files/templates it uses) if you wish. If you want to work on some of the next steps, please tell me which ones; this class is pretty much self-contained so it should be rather easy to work on in a local throw-away VM.

#11 Updated by intrigeri 2017-11-06 16:17:23

Target version changed from Tails_3.3 to Tails_3.5

I had to take over some work so let’s postpone this.

#12 Updated by intrigeri 2017-12-09 18:14:44

Assignee changed from intrigeri to anonym
% Done changed from 10 to 20
QA Check set to Ready for QA

intrigeri wrote:
> Made good progress: basic Postfix set up, Dovecot works (tested locally with Mutt over imaps), both using the snakeoil cert+key. Next step are local email delivery via Dovecot LDA, SASL authentication (using Dovecot) for Postfix, and serving a Thunderbird autoconfig file over HTTPS.

All this is done and deployed on all isotesters. I’ve tested authenticated email delivery (to the test mailbox), IMAP, and fetching the autoconfig file over HTTPS. At this point the best way to validate this setup further is to try and use it in the test suite:

import the snakeoil certificate as documented in a previous comment
when running the test suite on a system that has this email setup running, edit the thunderbird.yml test suite config file (that all isotesters get from test-suite-shared-secrets.git) and set:
- address: test@FQDN (e.g. test@isotester1.lizard)
- password: test

The 2nd step could be done e.g. in https://git-tails.immerda.ch/puppet-tails/tree/files/jenkins/slaves/isotesters/wrap_test_suite. I can do it myself at any time, but I’d rather wait for the 1st step to be done and deployed on all active branches first. The corresponding tests are disabled on Jenkins (Bug #11890) so it’ll be easy to test this on a single branch, i.e. the one where anonym will have done the 1st step.

#13 Updated by intrigeri 2017-12-10 07:44:21

Feature Branch set to test/12277-local-email-server

#14 Updated by intrigeri 2017-12-10 08:04:42

Feature Branch changed from test/12277-local-email-server to test/11890-local-email-server

#15 Updated by intrigeri 2017-12-10 08:15:45

Assignee changed from anonym to intrigeri
QA Check changed from Ready for QA to Dev Needed

Actually, forget what I wrote yesterday. I’ll finish setting up the infra bits and then I’ll sum up on Bug #11890 what I expect anonym to do on his side. Let’s not use Feature #12277 to discuss any change needed in the test suite itself.