Sympl issueshttps://gitlab.com/sympl.io/sympl/-/issues2019-04-14T21:31:36Zhttps://gitlab.com/sympl.io/sympl/-/issues/162Symbiosis: PHP 'upload_max_filesize' and 'post_max_size' values default perha...2019-04-14T21:31:36ZPaul CammishSymbiosis: PHP 'upload_max_filesize' and 'post_max_size' values default perhaps too lowImported from https://www.github.com/BytemarkHosting/symbiosis/issues/123
The default values of `2M` for `upload_max_filesize` and `8M` for `post_max_size` are fairly conservative, and can be fairly limiting as larger uploads have becom...Imported from https://www.github.com/BytemarkHosting/symbiosis/issues/123
The default values of `2M` for `upload_max_filesize` and `8M` for `post_max_size` are fairly conservative, and can be fairly limiting as larger uploads have become more common etc.
These two variables are often manually increased straight off the bat with a new Symbiosis install, so it would be useful to set these to a higher default value from the get go.https://gitlab.com/sympl.io/sympl/-/issues/164Symbiosis: Plaintext FTP should be disabled by default2019-04-17T20:30:58ZPaul CammishSymbiosis: Plaintext FTP should be disabled by defaultImported from https://www.github.com/BytemarkHosting/symbiosis/issues/50
`/etc/pure-ftpd/conf/TLS` currently appears to be set to 1 which means "Accept both normal sessions and SSL/TLS ones." - my opinion would be that for the next rele...Imported from https://www.github.com/BytemarkHosting/symbiosis/issues/50
`/etc/pure-ftpd/conf/TLS` currently appears to be set to 1 which means "Accept both normal sessions and SSL/TLS ones." - my opinion would be that for the next release, we should change this to 2, or even 3. Options are below.
```
-Y tls behavior
-Y 0 (default) disables SSL/TLS security mechanisms.
-Y 1 Accept both normal sessions and SSL/TLS ones.
-Y 2 refuses connections that aren't using SSL/TLS security
mechanisms, including anonymous ones.
-Y 3 refuses connections that aren't using SSL/TLS security
mechanisms, and refuse cleartext data channels as well.
The server must have been compiled with SSL/TLS support and a
valid certificate must be in place to accept encrypted sessions.
```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/171Symbiosis: Roundcube sieve breaks following dist-upgrade from Symbiosis Jessi...2019-06-07T10:51:35ZPaul CammishSymbiosis: Roundcube sieve breaks following dist-upgrade from Symbiosis Jessie to StretchImported from https://www.github.com/BytemarkHosting/symbiosis/issues/118
Roundcube returns an `Unable to connect to managesieve server` warning when attempting to access the `Filters` or `Vacation` setting. This is due to a change in t...Imported from https://www.github.com/BytemarkHosting/symbiosis/issues/118
Roundcube returns an `Unable to connect to managesieve server` warning when attempting to access the `Filters` or `Vacation` setting. This is due to a change in the sieve directory structure when moving from Jessie to Stretch.
In Symbiosis Jessie, the structure is as follows:
<pre>
root@symbiosis2:/usr/share/roundcube# ls -al /srv/symbiosis2.default.aladlow.uk0.bigv.io/mailboxes/root/
total 24
drwxr-sr-x 4 admin admin 4096 May 11 11:31 .
drwxr-sr-x 4 admin admin 4096 May 17 12:57 ..
drwx--S--- 9 admin admin 4096 May 27 16:05 Maildir
-rw-r--r-- 1 admin admin 105 May 27 12:51 password
lrwxrwxrwx 1 admin admin 23 May 11 11:30 sieve -> sieve.d/roundcube.sieve
drwx--S--- 3 admin admin 4096 May 11 11:30 sieve.d
</pre>
And in Symbiosis Stretch:
<pre>
root@symbiosis2:/usr/share/roundcube# ls -al /srv/symbiosis2.default.aladlow.uk0.bigv.io/mailboxes/root/
total 20
drwxr-sr-x 4 admin admin 4096 May 27 16:08 .
drwxr-sr-x 4 admin admin 4096 May 17 12:57 ..
lrwxrwxrwx 1 admin admin 21 May 27 16:08 .dovecot.sieve -> sieve/roundcube.sieve
drwx--S--- 9 admin admin 4096 May 27 16:05 Maildir
-rw-r--r-- 1 admin admin 105 May 27 12:51 password
drwx--S--- 3 admin admin 4096 May 27 16:08 sieve
</pre>
To resolve this, the `sieve.d` directory should be renamed to `sieve`, and the `sieve` symlink to `.dovecot.sieve`.Sympl v9.0 (for Debian Stretch)https://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/174Symbiosis: Skel missing file references2019-06-20T13:24:53ZPaul CammishSymbiosis: Skel missing file referencesImported from https://www.github.com/BytemarkHosting/symbiosis/issues/135
When a new domain directory is created within `/srv/`, Symbiosis Stretch will create appropriate `config`, and `public` sub-directories.
The `/srv/domain.com/pu...Imported from https://www.github.com/BytemarkHosting/symbiosis/issues/135
When a new domain directory is created within `/srv/`, Symbiosis Stretch will create appropriate `config`, and `public` sub-directories.
The `/srv/domain.com/public/htdocs/index.html` file generated refers to incorrect file paths, as it looks for `/bytemark/bytemark.css` and `/bytemark/bytemark.png`, but the `bytemark/` directory doesn't exist.
Additionally, the index points to the Jessie Symbiosis docs, where they should be for Stretch.Sympl v9.0 (for Debian Stretch)https://gitlab.com/sympl.io/sympl/-/issues/177Symbiosis: Stats default to On2019-04-14T21:25:48ZPaul CammishSymbiosis: Stats default to OnImported from https://www.github.com/BytemarkHosting/symbiosis/issues/51
I strongly believe Stats should be disabled OR the stats http page be password protected by default.Imported from https://www.github.com/BytemarkHosting/symbiosis/issues/51
I strongly believe Stats should be disabled OR the stats http page be password protected by default.https://gitlab.com/sympl.io/sympl/-/issues/178Symbiosis: Stretch - Cron warning emails generated by backup2l2019-04-14T21:05:19ZPaul CammishSymbiosis: Stretch - Cron warning emails generated by backup2lImported from https://www.github.com/BytemarkHosting/symbiosis/issues/127
When the cron script `/etc/cron.daily/zz-backup2l` runs, it generates the following warning message:
> WARNING:
>
> Volume is or was locked by another instance ...Imported from https://www.github.com/BytemarkHosting/symbiosis/issues/127
When the cron script `/etc/cron.daily/zz-backup2l` runs, it generates the following warning message:
> WARNING:
>
> Volume is or was locked by another instance of 'backup2l'.
>
> It appears that another instance of 'backup2l' is or was running concurrently.
> This should not happen, but cannot be avoided completely with the present
> implementation of locking in 'backup2l'. I am sorry!
>
> The following steps should bring everything back into order:
> 1. Stop all instances of 'backup2l'.
> 2. Remove the lock file '/var/backups/localhost/all.lock' manually.
> 3. Re-run the backup.
> 4. Unmount the backup device (if desired).`
A new backup is created despite this warning message, but it could be a cause for concern.https://gitlab.com/sympl.io/sympl/-/issues/179Symbiosis: Symbiosis monit failure emails in Stretch2019-04-14T21:37:56ZPaul CammishSymbiosis: Symbiosis monit failure emails in StretchImported from https://www.github.com/BytemarkHosting/symbiosis/issues/129
The symbiosis-monit script will return an exit code of 75 for a few reasons: if it's been disabled, if the machine is still booting, if the load is higher than th...Imported from https://www.github.com/BytemarkHosting/symbiosis/issues/129
The symbiosis-monit script will return an exit code of 75 for a few reasons: if it's been disabled, if the machine is still booting, if the load is higher than the number of CPU cores, or if dpkg is running:
<pre>root@jessie:~# grep -c processor /proc/cpuinfo
root@jessie:~# cat /proc/loadavg
4.00 4.00 3.87 5/130 5696
root@jessie:~# /usr/sbin/symbiosis-monit -t email /etc/symbiosis/monit.d -a
root@jessie:~# echo $?
75
</pre>
In Symbiosis Stretch, this will be printed to syslog:
<pre>upgrade2 systemd[1]: symbiosis-monit.service: Main process exited, code=exited, status=75/n/a
upgrade2 systemd[1]: symbiosis-monit.service: Unit entered failed state.
upgrade2 systemd[1]: symbiosis-monit.service: Failed with result 'exit-code'.
</pre>
And also as an email:
<pre>Subject: Symbiosis monitor detected service failure
root : TTY=unknown ; PWD=/ ; USER=nobody ; COMMAND=/usr/bin/tee /var/tmp/symbiosis-monit.cursor
pam_unix(sudo:session): session opened for user nobody by (uid=0)
Started Symbiosis monitor.
symbiosis-monit.service: Main process exited, code=exited, status=75/n/a
symbiosis-monit.service: Unit entered failed state.
symbiosis-monit.service: Triggering OnFailure= dependencies.
symbiosis-monit.service: Failed with result 'exit-code'.</pre>
Server load will frequently rise above the number of CPU cores on busy servers, generating a large amount of emails. Printing to syslog is useful if there are problems with the `symbiosis-monit` service itself, but we should probably only send a failure email when an individual test has failed (e.g. `apache2`), rather than the entire service.https://gitlab.com/sympl.io/sympl/-/issues/180Symbiosis: symbiosis-email cron.d entry points to incorrect binary2019-04-16T22:28:40ZPaul CammishSymbiosis: symbiosis-email cron.d entry points to incorrect binaryImported from https://www.github.com/BytemarkHosting/symbiosis/issues/72
`/usr/sbin/symbiosis-encrypt-mailpass` should be `/usr/sbin/symbiosis-email-encrypt-passwords`.
```
@hourly root [ -x /usr/sbin/symbiosis-encrypt-mailpass ] && /...Imported from https://www.github.com/BytemarkHosting/symbiosis/issues/72
`/usr/sbin/symbiosis-encrypt-mailpass` should be `/usr/sbin/symbiosis-email-encrypt-passwords`.
```
@hourly root [ -x /usr/sbin/symbiosis-encrypt-mailpass ] && /usr/sbin/symbiosis-encrypt-mailpass
```https://gitlab.com/sympl.io/sympl/-/issues/181Symbiosis: symbiosis-email-encrypt-passwords --verbose command is not recognised2020-08-22T16:07:25ZPaul CammishSymbiosis: symbiosis-email-encrypt-passwords --verbose command is not recognisedImported from https://www.github.com/BytemarkHosting/symbiosis/issues/65
Using Symbiosis Wheezy.
I need to encrypt a users email account password. Although I remember the password file for a user usually is updated with an encrypted ve...Imported from https://www.github.com/BytemarkHosting/symbiosis/issues/65
Using Symbiosis Wheezy.
I need to encrypt a users email account password. Although I remember the password file for a user usually is updated with an encrypted version of same password this doesnt appear to be working for me at the moment.
I tried the below command from /srv as admin user
symbiosis-email-encrypt-passwords --verbose
but just get
-bash: symbiosis-email: command not foundhttps://gitlab.com/sympl.io/sympl/-/issues/183Symbiosis: symbiosis-httpd-configure --diff-only option2019-04-17T20:05:54ZPaul CammishSymbiosis: symbiosis-httpd-configure --diff-only optionImported from https://www.github.com/BytemarkHosting/symbiosis/issues/48
Sometimes the configuration has been manually edited but it'd be nice to go back to the factory one, however the only way to see what would change other than check...Imported from https://www.github.com/BytemarkHosting/symbiosis/issues/48
Sometimes the configuration has been manually edited but it'd be nice to go back to the factory one, however the only way to see what would change other than checking manually, is to move the old hand-edited configuration out of the way, and then to run the symbiosis-httpd-configure (which reloads the site) and then compare the changes afterwards.
Would be nice if you could ask symbiosis-httpd-configure just to give you a diff of what would change if you asked it to take over the config for a particular site.https://gitlab.com/sympl.io/sympl/-/issues/185Symbiosis: symbiosis-ssl can generate SSL config for sites that have no certi...2019-04-17T20:11:54ZPaul CammishSymbiosis: symbiosis-ssl can generate SSL config for sites that have no certificateImported from https://www.github.com/BytemarkHosting/symbiosis/issues/44
symbiosis-ssl can generate SSL config for sites that have no certificate returned by Lets Encrypt. This can lead to invalid configuration, and Apache being unable ...Imported from https://www.github.com/BytemarkHosting/symbiosis/issues/44
symbiosis-ssl can generate SSL config for sites that have no certificate returned by Lets Encrypt. This can lead to invalid configuration, and Apache being unable to re-start.
This has been observed both in terms of missing certs that were never returned successfully from Lets Encrypt, or where symbiosis-ssl didn't have permission to write the certificate, but still wrote the SSL config.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 Cammishhttps://gitlab.com/sympl.io/sympl/-/issues/187Symbiosis: testing sites don't get DocumentRoot set2019-04-14T21:44:45ZPaul CammishSymbiosis: testing sites don't get DocumentRoot setImported from https://www.github.com/BytemarkHosting/symbiosis/issues/43
testing sites - e.g. example.com.testing.server.group.user.uk0.bigv.io don't have DocumentRoot set. Not being set by mod_rewriteImported from https://www.github.com/BytemarkHosting/symbiosis/issues/43
testing sites - e.g. example.com.testing.server.group.user.uk0.bigv.io don't have DocumentRoot set. Not being set by mod_rewritehttps://gitlab.com/sympl.io/sympl/-/issues/197Publish packages properly ;)2019-06-07T10:49:35ZPaul CammishPublish packages properly ;)The installation instructions smell a little -- getting a proper repo might be a nice touch.
You might find [Bintray](https://bintray.com/signup/oss) one way of doing it. I came across it for TV headend.The installation instructions smell a little -- getting a proper repo might be a nice touch.
You might find [Bintray](https://bintray.com/signup/oss) one way of doing it. I came across it for TV headend.Sympl v9.0 (for Debian Stretch)https://gitlab.com/sympl.io/sympl/-/issues/198Warning during installation about gcc not being found2019-06-07T10:51:32ZPaul CammishWarning during installation about gcc not being foundDuring install, I see the following:
```
Setting up symbiosis-common (2018:0616) ...
sent invalidate(passwd) request, exiting
sent invalidate(group) request, exiting
sent invalidate(passwd) request, exiting
sent invalidate(passwd) reque...During install, I see the following:
```
Setting up symbiosis-common (2018:0616) ...
sent invalidate(passwd) request, exiting
sent invalidate(group) request, exiting
sent invalidate(passwd) request, exiting
sent invalidate(passwd) request, exiting
sent invalidate(group) request, exiting
sent invalidate(group) request, exiting
Shadow passwords are now on.
Adding 'admin' account
Adding user `admin' ...
sent invalidate(passwd) request, exiting
sent invalidate(group) request, exiting
Adding new group `admin' (1001) ...
sent invalidate(passwd) request, exiting
sent invalidate(group) request, exiting
sent invalidate(group) request, exiting
sent invalidate(passwd) request, exiting
sent invalidate(group) request, exiting
Adding new user `admin' (1001) with group `admin' ...
sent invalidate(passwd) request, exiting
sent invalidate(group) request, exiting
sent invalidate(passwd) request, exiting
sent invalidate(group) request, exiting
sent invalidate(passwd) request, exiting
sent invalidate(group) request, exiting
Not creating home directory `/srv'.
sent invalidate(passwd) request, exiting
sent invalidate(group) request, exiting
sent invalidate(passwd) request, exiting
sent invalidate(passwd) request, exiting
sent invalidate(group) request, exiting
sent invalidate(passwd) request, exiting
sent invalidate(passwd) request, exiting
sent invalidate(group) request, exiting
sent invalidate(passwd) request, exiting
sent invalidate(passwd) request, exiting
sent invalidate(group) request, exiting
sent invalidate(passwd) request, exiting
sent invalidate(group) request, exiting
Adding user `admin' to group `adm' ...
sent invalidate(passwd) request, exiting
sent invalidate(group) request, exiting
Adding user admin to group adm
sent invalidate(passwd) request, exiting
sent invalidate(group) request, exiting
sent invalidate(group) request, exiting
sent invalidate(passwd) request, exiting
sent invalidate(group) request, exiting
Done.
Adding user `admin' to group `www-data' ...
sent invalidate(passwd) request, exiting
sent invalidate(group) request, exiting
Adding user admin to group www-data
sent invalidate(passwd) request, exiting
sent invalidate(group) request, exiting
sent invalidate(group) request, exiting
sent invalidate(passwd) request, exiting
sent invalidate(group) request, exiting
Done.
sh: 1: gcc: not found
/usr/lib/ruby/2.3.0/rubygems/core_ext/kernel_require.rb:55:in `require': cannot load such file -- faraday (LoadError)
from /usr/lib/ruby/2.3.0/rubygems/core_ext/kernel_require.rb:55:in `require'
from /usr/lib/ruby/vendor_ruby/acme-client.rb:3:in `<top (required)>'
from /usr/lib/ruby/2.3.0/rubygems/core_ext/kernel_require.rb:55:in `require'
from /usr/lib/ruby/2.3.0/rubygems/core_ext/kernel_require.rb:55:in `require'
from /usr/lib/ruby/vendor_ruby/symbiosis/ssl/letsencrypt.rb:6:in `<top (required)>'
from /usr/lib/ruby/2.3.0/rubygems/core_ext/kernel_require.rb:55:in `require'
from /usr/lib/ruby/2.3.0/rubygems/core_ext/kernel_require.rb:55:in `require'
from /usr/bin/symbiosis-ssl:161:in `<main>'
W: SSL certificate generation failed. Retrying with a self-signed certificate...
sh: 1: gcc: not found
/usr/lib/ruby/2.3.0/rubygems/core_ext/kernel_require.rb:55:in `require': cannot load such file -- faraday (LoadError)
from /usr/lib/ruby/2.3.0/rubygems/core_ext/kernel_require.rb:55:in `require'
from /usr/lib/ruby/vendor_ruby/acme-client.rb:3:in `<top (required)>'
from /usr/lib/ruby/2.3.0/rubygems/core_ext/kernel_require.rb:55:in `require'
from /usr/lib/ruby/2.3.0/rubygems/core_ext/kernel_require.rb:55:in `require'
from /usr/lib/ruby/vendor_ruby/symbiosis/ssl/letsencrypt.rb:6:in `<top (required)>'
from /usr/lib/ruby/2.3.0/rubygems/core_ext/kernel_require.rb:55:in `require'
from /usr/lib/ruby/2.3.0/rubygems/core_ext/kernel_require.rb:55:in `require'
from /usr/bin/symbiosis-ssl:161:in `<main>'
sh: 1: gcc: not found
/usr/lib/ruby/2.3.0/rubygems/core_ext/kernel_require.rb:55:in `require': cannot load such file -- faraday (LoadError)
from /usr/lib/ruby/2.3.0/rubygems/core_ext/kernel_require.rb:55:in `require'
from /usr/lib/ruby/vendor_ruby/acme-client.rb:3:in `<top (required)>'
from /usr/lib/ruby/2.3.0/rubygems/core_ext/kernel_require.rb:55:in `require'
from /usr/lib/ruby/2.3.0/rubygems/core_ext/kernel_require.rb:55:in `require'
from /usr/lib/ruby/vendor_ruby/symbiosis/ssl/letsencrypt.rb:6:in `<top (required)>'
from /usr/lib/ruby/2.3.0/rubygems/core_ext/kernel_require.rb:55:in `require'
from /usr/lib/ruby/2.3.0/rubygems/core_ext/kernel_require.rb:55:in `require'
from /usr/bin/symbiosis-ssl:161:in `<main>'
Created symlink /etc/systemd/system/multi-user.target.wants/symbiosis-skel.path → /lib/systemd/system/symbiosis-skel.path.
symbiosis-skel.service is a disabled or a static unit, not starting it.
```
Installation seems to continue and succeed.Sympl v9.0 (for Debian Stretch)Paul CammishPaul Cammishhttps://gitlab.com/sympl.io/sympl/-/issues/199symbiosis-ssl reports `Failed: signature type 'none' in JWS header is not sup...2019-06-07T10:51:28ZPaul Cammishsymbiosis-ssl reports `Failed: signature type 'none' in JWS header is not supported` when trying to get cert.As mentioned in #198
```
* Examining certificates for example.domain
No valid certificate sets found.
Fetching a new certificate from LetsEncrypt.
!! Failed: signature type 'none' in JWS header is not supported,...As mentioned in #198
```
* Examining certificates for example.domain
No valid certificate sets found.
Fetching a new certificate from LetsEncrypt.
!! Failed: signature type 'none' in JWS header is not supported, expected one of RS256, ES256, ES384 or ES512
* Examining certificates for localhost.localdomain
Current SSL set 0: self-signed for /CN=localhost.localdomain, expires 2020-04-15 16:32:06 UTC
```
Possible dependency or other issueSympl v9.0 (for Debian Stretch)Paul CammishPaul Cammishhttps://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-31