Run our own email (IMAP/POP3/SMTP) server for automated tests run on lizard
|Related to Tails - Bug #11890: Checking credentials in Thunderbird autoconfig wizard sometimes fails in the test suite||In Progress||2016-10-31|
#3 Updated by anonym 2017-03-02 08:39:01
- Assignee changed from anonym to intrigeri
- QA Check deleted (
> 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.
#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::sshclasses, we would create a
tails::tester::support::emailclass (that can possibly itself include
tails::tester::support::postfixif 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::relayfor 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
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!
#9 Updated by intrigeri 2017-10-22 14:57:39
> * 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
- 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.dbis 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.
#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
> 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.ymltest suite config file (that all isotesters get from test-suite-shared-secrets.git) and set:
- address: test@FQDN (e.g. email@example.com)
- 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.
#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.