Project

General

Profile

Feature #12277

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

Added by intrigeri 10 months ago. Updated 3 days ago.

Status:
In Progress
Priority:
Normal
Assignee:
Category:
Continuous Integration
Target version:
Start date:
03/02/2017
Due date:
% Done:

40%

QA Check:
Ready for QA
Feature Branch:
test/11890-local-email-server
Type of work:
Sysadmin
Blueprint:
Starter:
Affected tool:
Email Client

Description

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


Related issues

Related to Tails - Bug #11890: Checking credentials in Icedove autoconfig wizard sometimes fails in the test suite In Progress 10/31/2016

Associated revisions

Revision 535f2358 (diff)
Added by intrigeri 6 days ago

Test suite: complete the switch from Icedove to Thunderbird namespace in configuration (refs: #12277)

We've added the Thunderbird test suite config back in May to
test-suite-shared-secrets.git, by now everyone should have it.

Revision 239b2bc2 (diff)
Added by anonym 4 days ago

Test suite: import isotesters' snakoil SSL cert into Thunderbird.

Each isotester runs an email sever using its snakeoil certificate, so
we have to import it to prevent the certificate warning prompt.

Note: this will likely also be useful for #9519, if we ever make the
test suite itself host the email server for this feature.

Refs: #12277

History

#1 Updated by intrigeri 10 months ago

  • 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 10 months ago

  • Blocks Bug #11890: Checking credentials in Icedove autoconfig wizard sometimes fails in the test suite added

#3 Updated by anonym 10 months ago

  • 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 10 months ago

  • Target version set to Tails_3.2

#5 Updated by intrigeri 3 months ago

  • Description updated (diff)

#6 Updated by intrigeri 3 months ago

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 3 months ago

  • Target version changed from Tails_3.2 to Tails_3.3

#8 Updated by intrigeri about 2 months ago

  • 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 about 2 months ago

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 #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 about 2 months ago

  • 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 about 1 month ago

  • 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 6 days ago

  • 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:

  1. import the snakeoil certificate as documented in a previous comment
  2. 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:

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 (#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 6 days ago

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

#14 Updated by intrigeri 6 days ago

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

#15 Updated by intrigeri 6 days ago

  • 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 #11890 what I expect anonym to do on his side. Let's not use #12277 to discuss any change needed in the test suite itself.

#16 Updated by intrigeri 5 days ago

  • Blocks deleted (Bug #11890: Checking credentials in Icedove autoconfig wizard sometimes fails in the test suite)

#17 Updated by intrigeri 5 days ago

  • Related to Bug #11890: Checking credentials in Icedove autoconfig wizard sometimes fails in the test suite added

#18 Updated by intrigeri 5 days ago

  • Assignee changed from intrigeri to anonym
  • % Done changed from 20 to 30
  • QA Check changed from Dev Needed to Ready for QA

#19 Updated by anonym 4 days ago

  • Assignee changed from anonym to intrigeri
  • % Done changed from 30 to 40

#20 Updated by intrigeri 3 days ago

  • Assignee changed from intrigeri to anonym

The only known infra issue so far has resolved itself by waiting.
But there might be other issues.

Also available in: Atom PDF