Skip to content

Development Environment

Kenny Rachuonyo edited this page May 23, 2021 · 13 revisions

If you’re doing any serious hacking on Sovereign, you’ll want to set up a local virtual machine and use our included test suite. It sure beats mucking around with your actual server.

Setup

You’ll need to install VirtualBox and Vagrant. If you’ve never used Vagrant, you might be interested in reading the Getting Started documentation.

Launching the VM

From within the Sovereign repo, run

$ vagrant up
Bringing machine 'default' up with 'virtualbox' provider...
[default] Importing base box 'box-cutter/debian76'...
…
[default] Running provisioner: ansible...
…
(get a coffee)
…

The first time you run this, it will download a ~300MB VM image called debian76.box. You can generate this yourself if you prefer. It is a plain vanilla Debian 7.6 64bit box made with veewee.

When vagrant up finishes, you will have a fully installed Sovereign instance running in a VM. To ssh to it, run

$ vagrant ssh
Linux vagrant 3.2.0-4-amd64 #1 SMP Debian 3.2.65-1+deb7u2 x86_64 

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
You have mail.
Last login: Sun Nov 10 06:24:55 2013 from 10.0.2.2
vagrant@sovereign:~$

Testing

Add these to your /etc/hosts file:

172.16.100.2 cloud.sovereign.local
172.16.100.2 git.sovereign.local
172.16.100.2 mail.sovereign.local
172.16.100.2 newebe.sovereign.local
172.16.100.2 news.sovereign.local
172.16.100.2 sovereign.local
172.16.100.2 www.sovereign.local
172.16.100.2 autoconfig.sovereign.local
172.16.100.2 read.sovereign.local

Now you can navigate to the services running on the VM by accessing URLs such as https://mail.sovereign.local.

When you configure for deployment, you will use a self-signed certificate. When generating it, use *.sovereign.local for the FQDN. You can take defaults for all other fields.

Running the Test Suite

The test suite performs checks by connecting to the running services on the VM. Run it from outside the VM.

The tests are written in python and require a couple dependencies:

$ pip install requests nose

Then, run them with nosetests:

$ nosetests -v
ZNC is accepting encrypted logins ... ok
IMAP without SSL is NOT available ... ok
POP3 without SSL is NOT available ... ok
Connects with POP3S and asserts the existance of an email, then deletes it ... ok
Email sent from an MTA is delivered ... ok
Email sent from an MTA via SMTP+TLS has X-DSPAM and TLS headers ... ok
Email sent from an MTA via SMTP+TLS is delivered ... ok
Email sent from an MUA via SMTPS is delivered ... ok
Email sent to address with delimiter is delivered ... ok
Email sent from an MUA has DKIM and TLS headers ... ok
SMTPS with no authentication is rejected ... ok
SSH is responding with its banner ... ok
Blog is redirecting to https ... ok
ownCloud is redirecting to https and displaying login page ... ok
selfoss is redirecting to https and displaying login page ... ok
Webmail is redirecting to https and displaying login page ... ok
ZNC web interface is displaying login page ... ok
test_zpush_http_unauthorized (tests.WebTests) ... ok
test_zpush_https (tests.WebTests) ... ok
Prosody is listening on 5222 for clients and requiring TLS ... ok
Prosody is listening on 5269 for servers ... ok

----------------------------------------------------------------------
Ran 21 tests in 178.979s

OK

Rerunning Ansible

As you make changes to your playbook, you can rerun it against the VM:

$ vagrant provision

You can edit the Vagrantfile if you want to enable extra verbosity, run specific tags, etc.