Sympl issueshttps://gitlab.com/sympl.io/sympl/-/issues2019-10-30T09:16:52Zhttps://gitlab.com/sympl.io/sympl/-/issues/201`sympl-ssl` does not support Let's Encrypt v2 API2019-10-30T09:16:52ZPaul Cammish`sympl-ssl` does not support Let's Encrypt v2 APIAt present, as it's using an old Ruby library, `symbiosis-ssl` does not support the updated version of the Let's Encrypt API, meaning that as per [this notice](https://community.letsencrypt.org/t/end-of-life-plan-for-acmev1/88430), it wi...At present, as it's using an old Ruby library, `symbiosis-ssl` does not support the updated version of the Let's Encrypt API, meaning that as per [this notice](https://community.letsencrypt.org/t/end-of-life-plan-for-acmev1/88430), it will begin to stop working in November of 2019 for new installs, and through the next year, slowly stop working.
With this in mind, it would make sense to refactor this element of Sympl into a wrapper around existing Let's Encrypt tools, such as certbot or acmetool, rather than using a third party library, retaining the existing generation of self-signed certs and general cert management.Paul CammishPaul Cammish2019-10-31https://gitlab.com/sympl.io/sympl/-/issues/219Administrative user should be named something unique / permissions tidyup2019-06-09T23:34:46ZPaul CammishAdministrative user should be named something unique / permissions tidyupAs is, Symbiosis has an 'admin' user which is used for most functions, and (in theory) some level of security, although this is weakly enforced, and there is a possibility of a name collision.
A better alternative would probably be to h...As is, Symbiosis has an 'admin' user which is used for most functions, and (in theory) some level of security, although this is weakly enforced, and there is a possibility of a name collision.
A better alternative would probably be to have a user called 'sympl' or similar which would own the configs, files and so on, and then it would be safe to chown/chmod items in the config directory to prevent access to things which should be secure.
This looks to be a fairly simple change, and would go with giving the user a proper home directory (/home/sympl) rather than forcing them to use /srv, which becomes untidy quickly, and gives us the opportunity to pre-populate some basic settings (prompt, etc) for ease of use.Sympl v9.0 (for Debian Stretch)Paul CammishPaul Cammishhttps://gitlab.com/sympl.io/sympl/-/issues/233An installer script would be nice...2019-06-20T22:41:04ZPaul CammishAn installer script would be nice...This would allow us to run a single command which would install Sympl and set the relevant option so the user is not prompted at all.
This would also be able to point the user to documentation and make them aware of things like the `sym...This would allow us to run a single command which would install Sympl and set the relevant option so the user is not prompted at all.
This would also be able to point the user to documentation and make them aware of things like the `sympl` user using the `root` users password (which may not be secure) and/or force them to set a new one and include the root users authorized keys file.Sympl v9.0 (for Debian Stretch)Paul CammishPaul Cammishhttps://gitlab.com/sympl.io/sympl/-/issues/209Build tests should check upgrading from a current install2019-06-11T12:02:28ZPaul CammishBuild tests should check upgrading from a current installThis should prevent an upgrade breaking all the versions.This should prevent an upgrade breaking all the versions.Sympl v9.0 (for Debian Stretch)Paul CammishPaul Cammishhttps://gitlab.com/sympl.io/sympl/-/issues/243Buster: zz-mass-hosting doesn't appear to work.2019-08-16T17:54:56ZPaul CammishBuster: zz-mass-hosting doesn't appear to work.On boot, it's sending traffic to /var/www/html, and then after reconfiguring it seems to be only sending traffic to /srv/$localhost/public/htdocs.
It may be due to changes in the newer Apache breaking dynamic vhost configurations in gen...On boot, it's sending traffic to /var/www/html, and then after reconfiguring it seems to be only sending traffic to /srv/$localhost/public/htdocs.
It may be due to changes in the newer Apache breaking dynamic vhost configurations in general, or something else like the custom module not working right any more.Backloghttps://gitlab.com/sympl.io/sympl/-/issues/212Finish SNI for Support Exim and Dovecot2019-06-20T13:23:25ZPaul CammishFinish SNI for Support Exim and DovecotIt's possible to do this in Symbiosis with some changes, and a legacy branch included the change for Exim, however, the dovecot change will need a little more work.
https://docs.bytemark.co.uk/article/enabling-sni-for-exim-on-symbiosis/...It's possible to do this in Symbiosis with some changes, and a legacy branch included the change for Exim, however, the dovecot change will need a little more work.
https://docs.bytemark.co.uk/article/enabling-sni-for-exim-on-symbiosis/
https://docs.bytemark.co.uk/article/enabling-sni-for-dovecot-on-symbiosis/Sympl v9.0 (for Debian Stretch)https://gitlab.com/sympl.io/sympl/-/issues/252GitLab CI Improvements2019-07-09T18:44:33ZPaul CammishGitLab CI ImprovementsWhat should be happening is the runner should strategically install the previous version (if it exists) from the relevant public repo, then install the version from the local repo. Instead, theres a common race condition meaning the publ...What should be happening is the runner should strategically install the previous version (if it exists) from the relevant public repo, then install the version from the local repo. Instead, theres a common race condition meaning the public versions are the same as the newly pushed versions.
We should also have separate upgrade tests from the stable and the testing branches, so we can be certain that we won't break stable before deploying, but we can also pre-download the dependency packages needed in the images to save time and bandwidth, negating the need for a separate image.
* [x] Versions older than the local repo installed for upgrade tests.
* [x] Upgrade tests for stable and testing.
* [x] Pre-downloaded packages in clean install.
* [x] CI tidyup, ideally both major branches from the same version.
* [x] Tests for mangled changelog entries in the build CIFuture PlansPaul CammishPaul Cammishhttps://gitlab.com/sympl.io/sympl/-/issues/263LetsEncrypt certificates not renewed early enough2019-09-08T15:13:43ZPaul CammishLetsEncrypt certificates not renewed early enough# Summary
LetsEncrypt certificates are not renewed a month before expiry (as recommended). This causes warning emails to be received from LetsEncrypt.
# Steps to reproduce
Enable LetsEncrypt certificates for a domain. Wait 60 days.
...# Summary
LetsEncrypt certificates are not renewed a month before expiry (as recommended). This causes warning emails to be received from LetsEncrypt.
# Steps to reproduce
Enable LetsEncrypt certificates for a domain. Wait 60 days.
# What is the current bug behavior?
Certificates are not renewed until 2 weeks before expiry, causing a warning.email to be received
# What is the expected correct behavior?
Certificate should be removed 30 days before expiry.
See: https://letsencrypt.org/docs/integration-guide/
for more info.
/cc @kelduumPaul CammishPaul Cammishhttps://gitlab.com/sympl.io/sympl/-/issues/214Packages needed to be renamed2019-05-31T17:05:57ZPaul CammishPackages needed to be renamedbytemark-symbiosis, symbiosis-* packages needed to be renamed to match the new sympl naming.
bytemark-symbiosis -> sympl-core
symbiosis-* -> sympl-*bytemark-symbiosis, symbiosis-* packages needed to be renamed to match the new sympl naming.
bytemark-symbiosis -> sympl-core
symbiosis-* -> sympl-*Rebranding Symbiosis to SymplPaul CammishPaul Cammishhttps://gitlab.com/sympl.io/sympl/-/issues/210Packages should be published in a repo2019-06-08T22:06:25ZPaul CammishPackages should be published in a repoThis will include properly signed packages, via the Mythic Beasts repo.This will include properly signed packages, via the Mythic Beasts repo.Sympl v9.0 (for Debian Stretch)Paul CammishPaul Cammishhttps://gitlab.com/sympl.io/sympl/-/issues/127Symbiosis: admin' user should be added to the 'www-data' group for compatibility2019-06-20T13:21:53ZPaul CammishSymbiosis: admin' user should be added to the 'www-data' group for compatibilityImported from https://www.github.com/BytemarkHosting/symbiosis/issues/115
In quite a few cases where web apps update themselves, such as WordPress, the updaters check that specific files and directories are owned by the user Apache is r...Imported from https://www.github.com/BytemarkHosting/symbiosis/issues/115
In quite a few cases where web apps update themselves, such as WordPress, the updaters check that specific files and directories are owned by the user Apache is running as, and fail if they don't match.
By adding the `admin` user to the `www-data` group, and setting ownership to be www-data:www-data, both the web app and Symbiosis FTP users can update files and directories as needed without stepping on each others toes too much.
Note that this will often require the group to be set to www-data also (and sometimes rw permissions set for the group), but this prevents web app installs from arguing with the admin permissions, and allows the admin user (ie: the user used with FTP) to overwrite files as needed.Sympl v9.0 (for Debian Stretch)https://gitlab.com/sympl.io/sympl/-/issues/142Symbiosis: Frequently used packages aren't installed by default2019-06-20T13:42:39ZPaul CammishSymbiosis: Frequently used packages aren't installed by defaultImported from https://www.github.com/BytemarkHosting/symbiosis/issues/120
There are a number of packages which are typically installed manually on a newly created Symbiosis server as a first priority, since they're used so often. The fo...Imported from https://www.github.com/BytemarkHosting/symbiosis/issues/120
There are a number of packages which are typically installed manually on a newly created Symbiosis server as a first priority, since they're used so often. The following packages are sure bets to be installed in most cases:
`curl, iotop, less, lsof, psmisc, rsync, screen, smartmontools, telnet, vim, wget, htop, mtr-tiny, xfsprogs, tree, dnsutils`
It would be useful if we could add these packages as a Symbiosis dependency to ensure they're installed automatically.Sympl v9.0 (for Debian Stretch)https://gitlab.com/sympl.io/sympl/-/issues/143Symbiosis: I want SSL only without HSTS2020-07-11T06:36:30ZPaul CammishSymbiosis: I want SSL only without HSTSImported from https://www.github.com/BytemarkHosting/symbiosis/issues/66
I want a back-out path from ssl-only. Currently, if I deploy SSL only HSTS headers get issued, which mean I have no way to back out if I have problems with certifi...Imported from https://www.github.com/BytemarkHosting/symbiosis/issues/66
I want a back-out path from ssl-only. Currently, if I deploy SSL only HSTS headers get issued, which mean I have no way to back out if I have problems with certificate renewal or spot a problem with the way the SSL site renders
So, maybe I could make a file `config/ssl-only-no-sts` to get ssl throughout the site, and when I'm confident that I can commit to this configuration, then deploy STS.Sympl v9.0 (for Debian Stretch)https://gitlab.com/sympl.io/sympl/-/issues/147Symbiosis: It's too easy to break Exim by changing ssl certificate ownership.2019-06-20T13:19:51ZPaul CammishSymbiosis: It's too easy to break Exim by changing ssl certificate ownership.Imported from https://www.github.com/BytemarkHosting/symbiosis/issues/47
Pretty much everything in /srv/ is owned by admin:admin, so it's tempting to run something like "chown -R admin:admin /srv". The problem is that Exim certificates ...Imported from https://www.github.com/BytemarkHosting/symbiosis/issues/47
Pretty much everything in /srv/ is owned by admin:admin, so it's tempting to run something like "chown -R admin:admin /srv". The problem is that Exim certificates lie in /srv/<HOSTNAME>/config/ssl/sets and Debian-exim (the user that runs Exim) is not a member of the admin group, so this is an awkward fact to learn and remember.
It might be better if the certificates were managed in /etc/ssl - from where they are currently, and tortuously symlinked.
Alternatively, if issue 38 https://gitlab.bytemark.co.uk/open-source/symbiosis/issues/38 is implemented, then I've made a suggestion for managing these certs.Sympl v9.0 (for Debian Stretch)https://gitlab.com/sympl.io/sympl/-/issues/157Symbiosis: Mysql user of admin with admin password for mysql access2019-06-20T13:21:36ZPaul CammishSymbiosis: Mysql user of admin with admin password for mysql accessImported from https://www.github.com/BytemarkHosting/symbiosis/issues/61
Just had a customer who processed a migration from symb6 to symb8 and managed to overwrite the mysql db in the process.
Wondered if there might be some traction i...Imported from https://www.github.com/BytemarkHosting/symbiosis/issues/61
Just had a customer who processed a migration from symb6 to symb8 and managed to overwrite the mysql db in the process.
Wondered if there might be some traction in having an admin user with the admin password as a mysql user that we can control access for a little more, no access to the mysql folder for example...
Sympl v9.0 (for Debian Stretch)https://gitlab.com/sympl.io/sympl/-/issues/169Symbiosis: Replace the default site .html file with some Symbiosis documentation2019-06-20T13:22:59ZPaul CammishSymbiosis: Replace the default site .html file with some Symbiosis documentationImported from https://www.github.com/BytemarkHosting/symbiosis/issues/63
@jamielinux's good idea;
Replace:
![screen_shot_2017-05-31_at_16 33 05](https://user-images.githubusercontent.com/317667/27084986-c99e5000-5045-11e7-9256-bd9f52c...Imported from https://www.github.com/BytemarkHosting/symbiosis/issues/63
@jamielinux's good idea;
Replace:
![screen_shot_2017-05-31_at_16 33 05](https://user-images.githubusercontent.com/317667/27084986-c99e5000-5045-11e7-9256-bd9f52cab638.png)
With help documentation in some form. Maybe full, maybe single page
Would a high level view of the steps required to setup a standard website work?Sympl v9.0 (for Debian Stretch)https://gitlab.com/sympl.io/sympl/-/issues/170Symbiosis: Request: Write mysql root credentials to /root/.my.cnf when imaging.2019-06-09T23:33:49ZPaul CammishSymbiosis: Request: Write mysql root credentials to /root/.my.cnf when imaging.Imported from https://www.github.com/BytemarkHosting/symbiosis/issues/56
(Note: This may be something for imager, or Stretch, but applied to Symbiosis *images* only)
It's never clear that the `root`, `admin` and mysql `root@localhost` ...Imported from https://www.github.com/BytemarkHosting/symbiosis/issues/56
(Note: This may be something for imager, or Stretch, but applied to Symbiosis *images* only)
It's never clear that the `root`, `admin` and mysql `root@localhost` users all have the same password in a newly imaged machine, which leads to users likely changing the root/admin passwords like they should, and not making note of the `root@localhost` password we set for mysql.
Simply writing the below to `/root/.my.cnf` (with relevant permissions) would make password recovery simpler, and allow the user to log in directly.
```config
[client]
user=root
password="<example>"
```
There's a small outside risk to this, by keeping it in `/root` would negate most of this, and make things simpler for users.Sympl v9.0 (for Debian Stretch)Paul CammishPaul Cammishhttps://gitlab.com/sympl.io/sympl/-/issues/172Symbiosis: Run-parts when SSL certificates are updated2019-06-20T17:51:21ZPaul CammishSymbiosis: Run-parts when SSL certificates are updatedImported from https://www.github.com/BytemarkHosting/symbiosis/issues/62
Similar to other tools for Lets Encrypt, could Symbiosis do a run-parts on a certain directory if it exists (e.g /etc/symbiosis/ssl-update.d) to allow other servic...Imported from https://www.github.com/BytemarkHosting/symbiosis/issues/62
Similar to other tools for Lets Encrypt, could Symbiosis do a run-parts on a certain directory if it exists (e.g /etc/symbiosis/ssl-update.d) to allow other services to act on an automated SSL renewal?
I'm thinking this could hook into HAProxy, but could be useful for mail and stuff too.
Ideally environment variables would be passed to the hook in the same style as https://github.com/hlandau/acme/blob/master/_doc/SCHEMA.md#hooksSympl v9.0 (for Debian Stretch)https://gitlab.com/sympl.io/sympl/-/issues/221Symbiosis: symbiosis-httpd-logger is run where it's not really needed2019-06-20T13:24:05ZPaul CammishSymbiosis: symbiosis-httpd-logger is run where it's not really neededThe HTTP and HTTPS templates for sites both run the symbiosis-httpd-logger process (aka sypl-web-logger) which does little other than write logs owned by the admin user.
This is useful for the zz-mass-hosting configuration, as it then w...The HTTP and HTTPS templates for sites both run the symbiosis-httpd-logger process (aka sypl-web-logger) which does little other than write logs owned by the admin user.
This is useful for the zz-mass-hosting configuration, as it then writes logs to the relevant locations, but it's wasted resources when you have a lot of sites running.
If #219 happens, then the templates should just write the files directly via the normal apache method.Sympl v9.0 (for Debian Stretch)https://gitlab.com/sympl.io/sympl/-/issues/186Symbiosis: Testing in gitlab2019-04-22T17:57:10ZPaul CammishSymbiosis: Testing in gitlabImported from https://www.github.com/BytemarkHosting/symbiosis/issues/53
At the moment the install / dist-upgrade / upgrade tests get weirdly-far in gitlab-ci then fails. Here's a quick summary of how the tests used to work on maker2 (a...Imported from https://www.github.com/BytemarkHosting/symbiosis/issues/53
At the moment the install / dist-upgrade / upgrade tests get weirdly-far in gitlab-ci then fails. Here's a quick summary of how the tests used to work on maker2 (as I understand it), and then later I'll go into detail on why the tests fail in gitlab-ci
The Current Situation
================
1. autotest sets up a VM using schroot magic i don't fully understand
2. the VM boots up with systemd and all that jazz, uses DHCP & SLAAC to configure its networking, and automatically runs all the scripts in the autotest folder, keeping all the output as a log file. Once done, it shuts down
3. autotest cracks open the VM's filesystem and reads the logfile. Somehow it detects failures and fails if there was a failure then it exits with a nonzero error code so that maker2 knows
Some Feelings About The Current Situation
===============================
Patrick said something about autotest using the console to talk to the tests, and something else much scarier about the VM sshing into the host to run something.
This doesn't work on gitlab-ci, and is also kinda hacky, for a few reasons.
* the scripts in the autotest folder aren't particularly focussed. In addition to actually running tests, they do these and probably others:
* add an admin user
* install all the packages needed by symbiosis from a big list of packages
* install symbiosis
* opening up the filesystem of the VM so you can prod it is pretty gross
On the plus side it works, and it would only take a bit of effort to port the whole schroot setup over to gitlab-ci (but would have to run using a shell runner)
Why the tests fail in gitlab-ci
=====================
When gitlab-ci runs a container it starts bash in the context of the container. Effectively, bash is PID 1 for the container. There's no init-system to talk to to get stuff going. I believe the apt-get install step for some packages starts them using /etc/init.d (probably something about the package detecting a lack of systemd and putting a proper sysvinit script in) which would explain why a lot of the tests actually succeed. BUT SOME OF THEM FAIL, and we should really be doing a much more realistic test than running our symbiosis full-system tests in a docker container that isn't a full symbiosis system.
With that in mind:
A More Realistic Test Proposal
======================
We're still going to want to run symbiosis in a VM, I think. To do a realistic full-install / dist-upgrade test we need to have a realistic system, which the docker container environment isn't. We need a systemd to talk to so we can schedule restarts, that sort of thing.
We will need some test-specific configurations (particularly repo URLs) too. And we'll need to be able to orchestrate the testing and fail the build when the tests fail.
We could create an image prior to the testing which would have a user account with passwordless sudo and a .ssh/authorized_keys . The private key would be kept in the [secret variables](https://gitlab.bytemark.co.uk/open-source/symbiosis/settings/ci_cd) section of the project on gitlab, and so would be presented to the gitlab-ci script as an env var.
In the gitlab-ci script we'd start the VM with qemu, as we do for bytemark/bytemark-packer-templates, then use ansible to copy over the tests, install the symbiosis packages, and run the tests. We could write our ansible playbook so that it captures the logs and copies them back to the runner and have the gitlab-ci script spit the logs out, then exit with ansible's exit code.
This would make our test output more readable and shorter, not be quite as weird the current autotest setup on maker2, probably not require also running a DHCP server.
The work we'd need to do:
* add an ansible layer to docker-images/layers
* rewrite the `autotest/` scripts as ansible playbooks
* make a base VM image with the necessary networking & ssh setup
Thoughts @pcherry , @jcarter ?Testing SuitePaul CammishPaul Cammish