Sympl issueshttps://gitlab.com/sympl.io/sympl/-/issues2021-05-14T14:44:13Zhttps://gitlab.com/sympl.io/sympl/-/issues/202Apache should support the PROXY protocol2021-05-14T14:44:13ZPaul CammishApache should support the PROXY protocolTo support reverse proxies passing through the originating source IP (for things like diagnostic logging, anti abuse and so on) Sympl should ideally support the PROXY protocol.
See https://www.haproxy.org/download/1.8/doc/proxy-protocol...To support reverse proxies passing through the originating source IP (for things like diagnostic logging, anti abuse and so on) Sympl should ideally support the PROXY protocol.
See https://www.haproxy.org/download/1.8/doc/proxy-protocol.txt and mod_remoteip.
This may have to be a per-IP configuration looking at the Apache docs, or an overall system configuration. It would be nice however if it could be transparently configured.Future Planshttps://gitlab.com/sympl.io/sympl/-/issues/257Sympl should automatically update it's configuration near-instantly2020-01-28T13:33:20ZPaul CammishSympl should automatically update it's configuration near-instantlyWhen changes are made, typically it can take up to an hour to a day for everything to have run.
It would be nice if Sympl used [incrond](https://linux.die.net/man/8/incrond) (currently used by sympl-firewall) to detect changes to the co...When changes are made, typically it can take up to an hour to a day for everything to have run.
It would be nice if Sympl used [incrond](https://linux.die.net/man/8/incrond) (currently used by sympl-firewall) to detect changes to the configuration and update as needed, adding to incrond's config where needed as domains are added/removed.
This would make configuration practically instant, so would need some kind of logging/admin notification so you can see what's actually going on.Future Planshttps://gitlab.com/sympl.io/sympl/-/issues/218sympl-all-crontabs.c should be rewritten in something more portable2019-07-17T15:48:41ZPaul Cammishsympl-all-crontabs.c should be rewritten in something more portable```text
* A wrapper script which will do some simple permission and file-presence
* checks, then launch the sympl-crontab command for each domain which
* is present.
*
* The way this script works is pretty simple:
*
* 1. Iterate over e...```text
* A wrapper script which will do some simple permission and file-presence
* checks, then launch the sympl-crontab command for each domain which
* is present.
*
* The way this script works is pretty simple:
*
* 1. Iterate over every entry beneath /srv
* - Ignoring dotfiles.
* - Ignoring entries that do not contain /srv/$name/config/crontab
*
* 2. Once a valid entry has been found ensure that the owner of
* /srv/$name and /srv/$name/config/crontab matches.
*
* 3. Invoke our ruby wrapper as the appropriate user, via /bin/su.
```
This should really be rewritten in something more portable (to ease install on non-amd64 platforms), or simply use bash instead as there's nothing particularly fancy here.Future Planshttps://gitlab.com/sympl.io/sympl/-/issues/207There are no build tests for webmail2019-05-28T11:23:23ZPaul CammishThere are no build tests for webmailThere aren't currently any tests to ensure webmail (ie: roundcube) is functional.
This is less of an issue at the moment as IMAP is tested, so this can be put off for now.
We should however create a test to ensure webmail can be logged...There aren't currently any tests to ensure webmail (ie: roundcube) is functional.
This is less of an issue at the moment as IMAP is tested, so this can be put off for now.
We should however create a test to ensure webmail can be logged into (via cURLing the local site, etc.Future Planshttps://gitlab.com/sympl.io/sympl/-/issues/203`symbiosis-test` fails the first antivirus test, but only on first run2019-06-07T10:53:05ZPaul Cammish`symbiosis-test` fails the first antivirus test, but only on first runIt's unclear why this is the case - it doesn't appear to be related to timing, or load or anything similar, but in the first ever run on a machine, the first antivirus test fails as the test mail is apparently let through.
```
=========...It's unclear why this is the case - it doesn't appear to be related to timing, or load or anything similar, but in the first ever run on a machine, the first antivirus test fails as the test mail is apparently let through.
```
===============================================================================
Failure: test_acl_check_antivirus(Exim4ConfigTest)
/etc/symbiosis/test.d/tc_exim4.rb:280:in `block in do_acl_script'
/etc/symbiosis/test.d/tc_exim4.rb:263:in `open'
/etc/symbiosis/test.d/tc_exim4.rb:263:in `do_acl_script'
/etc/symbiosis/test.d/tc_exim4.rb:410:in `test_acl_check_antivirus'
407:
408: FileUtils.touch(File.join(config_dir, "antivirus"))
409: # OK the file is there now, so reject (as per default)
=> 410: do_acl_script('exim4_acl_tests/antivirus_reject')
411:
412: # OK, now the file contains "tag" so accept, and tag
413: File.open(File.join(config_dir, "antivirus"),"w+"){|fh| fh.puts("tag my mail")}
ACL test failed after line 21 of exim4_acl_tests/antivirus_reject (OK id=1hTyWz-0000UI-BT)
<550> expected but was
<250>
diff:
? 550
? 2
===============================================================================
```
On every subsequent run it's fine, and there's no sign of a change caused by the first run.
As a workaround, it's now running twice, and discarding the first run silently.
Commit https://gitlab.mythic-beasts.com/sympl/sympl_stretch/commit/46a6e141f63e2c2ed025e530c7577ee2d97f07e5
Job [#2785](https://gitlab.mythic-beasts.com/sympl/sympl_stretch/-/jobs/2785) failed for 9480193f15793d90448b10ee278404beba37c304Future Planshttps://gitlab.com/sympl.io/sympl/-/issues/200There should be a simpler way of selecting the default site2019-04-22T17:53:40ZPaul CammishThere should be a simpler way of selecting the default siteThis would replace the zz-mass-hosting configuration (which can cause odd issues with subdomains as it matches more than it needs) and replace the need for `/srv/$(hostname)` and simply set the SSL certs to the default site for things li...This would replace the zz-mass-hosting configuration (which can cause odd issues with subdomains as it matches more than it needs) and replace the need for `/srv/$(hostname)` and simply set the SSL certs to the default site for things like FTP, and use a simple Apache redirect to handle it properly.
Something like a symlink of `/srv/default_site` -> `/srv/example.com` would do the job, although this change would need to be detected and the relevant services reloaded/restarted as needed.Future Planshttps://gitlab.com/sympl.io/sympl/-/issues/196Symbiosis: Using `/srv/<domains/mailboxes/<user>/forward` with an external de...2019-06-20T15:02:39ZPaul CammishSymbiosis: Using `/srv/<domains/mailboxes/<user>/forward` with an external destinations fails SPF and DKIM checksImported from https://www.github.com/BytemarkHosting/symbiosis/issues/54
As `/srv/<domains/mailboxes/<user>/forward` simply relays the mail, it often causes SPF and DKIM signed mail to fail. This is particularly bad as the more importan...Imported from https://www.github.com/BytemarkHosting/symbiosis/issues/54
As `/srv/<domains/mailboxes/<user>/forward` simply relays the mail, it often causes SPF and DKIM signed mail to fail. This is particularly bad as the more important the mail (banks etc) the more tight their SPK/DKIM will be, and the destination mail server may simply drop invalid mail, or in many cases (see [SNDS](https://wiki2.bytemark.co.uk/Microsoft_Smart_Network_Data_Service)) simply flag all mail coming in that route as spam.
This can be worked around by using a basic Sieve filter (created in a mail client or Roundcube, etc) instead of a basic forward, which generates a header in the final mailbox like this:
```
Delivered-To: under100words@example.net
Received: by 10.157.19.41 with SMTP id f38csp1124363ote;
Fri, 24 Mar 2017 02:25:49 -0700 (PDT)
X-Received: by 10.28.157.150 with SMTP id g144mr1955711wme.89.1490347549347;
Fri, 24 Mar 2017 02:25:49 -0700 (PDT)
Return-Path: <admin@carth.ebonhawk.example.uk0.bigv.io>
Received: from carth.ebonhawk.example.uk0.bigv.io (under100words.com. [2001:41c8:51:7a3::163])
by mx.google.com with ESMTPS id x4si1960991wmx.113.2017.03.24.02.25.48
for <under100words@example.net>
(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
Fri, 24 Mar 2017 02:25:49 -0700 (PDT)
Received-SPF: neutral (google.com: 2001:41c8:51:7a3::163 is neither permitted nor denied by best guess record for domain of admin@carth.ebonhawk.example.uk0.bigv.io) client-ip=2001:41c8:51:7a3::163;
Authentication-Results: mx.google.com;
dkim=pass header.i=@bytemark.co.uk;
spf=neutral (google.com: 2001:41c8:51:7a3::163 is neither permitted nor denied by best guess record for domain of admin@carth.ebonhawk.example.uk0.bigv.io) smtp.mailfrom=admin@carth.ebonhawk.example.uk0.bigv.io;
dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=bytemark.co.uk
Received: from admin by carth.ebonhawk.example.uk0.bigv.io with local (Exim 4.84_2) (envelope-from <admin@carth.ebonhawk.example.uk0.bigv.io>) id 1crLTg-0006yS-L8 for under100words@example.net; Fri, 24 Mar 2017 09:25:48 +0000
X-Sieve: Pigeonhole Sieve 0.4.2
X-Sieve-Redirected-From: nobody@under100words.com
Received: from yrk.mx.bytemark.co.uk ([2001:41c9:0:1019::81:84]) by carth.ebonhawk.example.uk0.bigv.io with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from <paul.cammish@bytemark.co.uk>) id 1crLTf-0006yJ-0J for nobody@under100words.com; Fri, 24 Mar 2017 09:25:48 +0000
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bytemark.co.uk; s=20131115; h=Content-Type:MIME-Version:Date:Message-ID:Subject:From:To; bh=0UTMmBvQCD1aDtGQ0LM/wKwl+36AyMeb9pEvAf/Lve8=; b=jCmTawHtj3wZvPA+DnmtoyYpJYmznfAbAR2ZZkF0WmkbB9MD0BdivSofH1ww4DoYM3tH3BtjFt02Bn0NpKpNeNX74c8l5lVQ6QB2uVc2dDBVhma/MLbceDvrjAsOXGnomgWIFPZNLzOAcXF/mS+5ctw7nRGg44nxxlXMKAymbzTvzOGiiyA0rX2DgKhrn3SDhBNNC2dW8AsiZ6lqs9jZz99bqJlMwzhGz709MfPfzdvnIKsnt9sBc/hL+KAu0lUH1l0ySSNeLqyU6CTU91B3ULnVkQoX9EMh6Rim3430thOQ0VAfon9kp3l7lVbaXfDOkcK2PLxRBYSqnmD5uVR3dQ==;
Received: from ratatoskr.bytemark.co.uk ([2001:41c9:0:1017::48] helo=ratatoskr.dh.bytemark.co.uk) by yrk.mx.bytemark.co.uk with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from <paul.cammish@bytemark.co.uk>) id 1crLTe-0006jU-Kd for nobody@under100words.com; Fri, 24 Mar 2017 09:25:46 +0000
Received: from [2001:41c8:3:1::186] by ratatoskr.dh.bytemark.co.uk with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from <paul.cammish@bytemark.co.uk>) id 1crLTe-0005hF-I3 for nobody@under100words.com; Fri, 24 Mar 2017 09:25:46 +0000
To: nobody@under100words.com
From: Paul <paul@example.co.uk>
Subject: Test forward
Organization: Bytemark Hosting
Message-ID: <bdf891dd-fb0c-f7ca-3f89-7d7a00ff49ee@bytemark.co.uk>
Date: Fri, 24 Mar 2017 09:25:44 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="1kPfKMM3kgqtkMjBuqBIR3uSp4MpjjNV9"
Sender: Symbiosis Administrator <admin@carth.ebonhawk.example.uk0.bigv.io>
```
This works with a simple sieve rule like:
```
# rule:[Redirect all mail.]
if true
{
redirect "under100words@example.net";
stop;
}
```
It would be great if the forward file generated the relevant sieve rule, and massively improve deliverability.Future Planshttps://gitlab.com/sympl.io/sympl/-/issues/182Symbiosis: symbiosis-firewall 99-reject file is blank by default2019-04-15T09:14:34ZPaul CammishSymbiosis: symbiosis-firewall 99-reject file is blank by defaultImported from https://www.github.com/BytemarkHosting/symbiosis/issues/137
Symbiosis' firewall contains a `/etc/symbiosis/firewall/incoming.d/99-reject` rule by default, which will block connections from `0.0.0.0/0` (anywhere).
If we a...Imported from https://www.github.com/BytemarkHosting/symbiosis/issues/137
Symbiosis' firewall contains a `/etc/symbiosis/firewall/incoming.d/99-reject` rule by default, which will block connections from `0.0.0.0/0` (anywhere).
If we add an IP to this 99-reject file, connections will only be blocked from this IP and allowed from everywhere else, which isn't usually what we want to happen.
It would be safer if the 99-reject file contained `0.0.0.0/0` by default to avoid allowing more through the firewall than what was intended. This could still be removed from the file if needed.Future Planshttps://gitlab.com/sympl.io/sympl/-/issues/175Symbiosis: Some thoughts about Symbiosis firewall management2019-04-17T20:20:11ZPaul CammishSymbiosis: Some thoughts about Symbiosis firewall managementImported from https://www.github.com/BytemarkHosting/symbiosis/issues/136
The Symbiosis firewall seems to work well, but I have issues with it, which may be caused by my lack of understanding of the nuances of ruby, I guess. Mostly I w...Imported from https://www.github.com/BytemarkHosting/symbiosis/issues/136
The Symbiosis firewall seems to work well, but I have issues with it, which may be caused by my lack of understanding of the nuances of ruby, I guess. Mostly I want to stop the bots that relentlessly look for logins and passwords, while at present I think that Exim is doing a reasonable job of keeping spam out.
This attempts to explain my understanding of what is happening, so please bear with me - and maybe you wlll see if I have it wrong.
**What's there**
I am interested in improving the action of /usr/sbin/symbiosis-firewall-blacklist which runs every 15 minutes (or so) and is responsible for creating and deleting files in /etc/symbiosis/firewall/blacklist.d. The files are named for IP addresses (and have .auto) appended to them when created by the script. IP files can be created here to put into the firewall, and are ignored by the system. The files contain port numbers, 'all' or be empty (which implies 'all') - the port numbers are loaded into iptables and block attempts to connect from the named IP to the appropriate port.
The symbiosis-firewall-blacklist script has two distinct phases:
1) It creates a list of candidate IPs (and ports) using the files in /etc/symbiosis/firewall/patterns.d to scan log files. Once it has a list of candidates it creates the files in blacklist.d.
2) It then looks for files to delete.
So let's look at phase 1:
Each file in the patterns.d directory contains the name of a log file. This file is scanned looking for a regular expression match to find likely candidates for blocking. The script uses an sqlite3 database (in /var/lib/symbiosis/firewall-blacklist-logtail.db) to remember where it was in the file the last time it looked at that file. (I suspect that this is the cause of some people's uncertainty about this system. If you add a pattern which you've found in a log file, then it won't be activated until the problem happens again and re-appears in the log file so it can be seen.) However doing this makes sense for efficiency reasons.
The script uses pattern.rb to scan the log file. When matches are found it creates a two dimensional hash
`results[ip][port] = hit (actual code is results[ip.to_s][port] += 1)`
so for each port in the pattern.d file, the ip is awarded a single hit. My guess is that this method was used because different pattern files may locate the same bad IP and may also repeat ports. However it means that total hit counts are multiplied by the number of ports in the matched pattern file.
So it's found some lines in a logfile matching the regular expression. Now it wants to decide if any of these entries are worthy of being blacklisted.
This happens if any of the hit counts are greater than 20 (by default), or the value supplied by the -a (--block-after). While it's doing this, it's summing all the hits for the ip and writes them to another sqlite3 database (/var/lib/symbiosis/firewall-blacklist-count.db) along with the IP and a timestamp.
It now looks to see if this IP has been really bad, and is worth blocking completely. It creates a sum of the hits recorded for this IP in the last 24 hours and if this is over 100 (default) or the value determined from -b (--block-all-after) then this IP is set up to be blocked completely for all ports.
So now if it has some candidates, it will create files with the ip address as the names and attach .auto.
Phase 2 is reasonably simple. It looks for the modification time of the file, and if it's expired it's removed.
**Thoughts**
The Phase 1 algorithm really needs improving and I would say that this is really an urgently needed change. In many cases the system is not reactive enough - and I see that people are using other systems because it's not good enough.
When looking for candidates, the system only 'knows' about the matches it has found in the current slice of the log file that it's inspecting for that pass. For my site, this is typically 3 or 6. My system is not busy so not a lot happens every 15 minutes. The window for selecting candidates is much too small - and is essentially avoidable by delaying attacks.
Second, the system completely ignores the history that it has carefully stored away in the sqlite3 file. Mostly I find that these robots come back from the same IP address often several days later. The system should make much better use of the history that it has gathered.
Third, the current system will theoretically generate port specific matches in iptables. But it's not clear how often this will happen, and frankly I don't care, I'd be happy to completely block every bad site from everything. As an aside it would be good if the code making the firewall understood about 'multiport dports' to make less lines in the filters.
The current selection code is:
```
results.each do |ip, ports|
#
# tot up on a per-ip basis
#
total_for_ip = 0
ports.each do |port, hits|
total_for_ip += hits
blacklist[ip] << port if hits > @block_after
end
#
# Record our count
#
@count_db.set_count_for(ip, total_for_ip, timestamp)
#
# Get the hits for the last 24 hours
#
total_for_ip = @count_db.get_count_for(ip, timestamp - 86400)
#
# If an IP has exceeded the number of matches, block it from all ports.
#
if total_for_ip > @block_all_after
blacklist[ip] = %w(all)
end
end
```
I am no ruby programmer - so this is a syntactic guess but maybe this will be an improvement - without changing patterns.rb.
If you want to correct the syntax for me please do.
```
results.each do |ip, ports|
#
# get history for this ip for the last day
# and this ought to be a parameter to the script
# because I'd like to change this
# (@block_period defaults to 1 I think)
#
historysecs = timestamp - 3600*@block_period
past_for_ip = @count_db.get_count_for(ip, historysecs)
#
# tot up on a per-ip basis
#
total_for_ip = 0
ports.each do |port, hits|
total_for_ip += hits
# notice change here to include history
blacklist[ip] << port if hits + past_for_ip > @block_after
end
#
# Record our count
#
@count_db.set_count_for(ip, total_for_ip, timestamp)
#
# Get the hits for the some period, which can also be the epoch
# and again should be a parameter - block_all_period can perhap default to 3
#
historysecs = 0
if @block_all_period > 0
historysecs = timestamp - 3600*@block_all_period
end
total_for_ip = @count_db.get_count_for(ip, historysecs)
#
# If an IP has exceeded the number of matches, block it from all ports.
#
if total_for_ip > @block_all_after
blacklist[ip] = %w(all)
end
end
```
So this:
a) includes the history for some period when working out the bad guys
b) includes the history for some longer period when evaluating really bad guys
c) Now has an extra lookup for each ip,
This may cause problems if this hits ip addresses that should be in use. There are no tools for removing good guys from the history file. Maybe this can be supplied as a small tool. Perhaps when an address is placed in the whitelist directory, the address should be removed from the blacklist database if it's there.Future Planshttps://gitlab.com/sympl.io/sympl/-/issues/173Symbiosis: Simple database creator2020-09-15T21:31:03ZPaul CammishSymbiosis: Simple database creatorImported from https://www.github.com/BytemarkHosting/symbiosis/issues/46
A typical usage scenario for Symbiosis is a user creating a new site, then uploading a PHP webapp and expecting it to work.
The problem is, once they've uploaded ...Imported from https://www.github.com/BytemarkHosting/symbiosis/issues/46
A typical usage scenario for Symbiosis is a user creating a new site, then uploading a PHP webapp and expecting it to work.
The problem is, once they've uploaded the PHP content, they need to create a MySQL database, which can only currently be done over the command-line or PHPMyadmin.
An interesting feature would allow a user to create a "database" file in the /srv/domain.tld/config directory, containing a user and password. Symbiosis would detect the presence of this file, and if a database named after the domain didn't already exist, would create a new database, and GRANT the right permissions to it allowing local access with the username/password in the file. The user could then install say, Wordpress with *only* SFTP.Future Planshttps://gitlab.com/sympl.io/sympl/-/issues/165Symbiosis: Publish CAA (DNS TXT) records to improve security2019-04-14T20:59:45ZPaul CammishSymbiosis: Publish CAA (DNS TXT) records to improve securityImported from https://www.github.com/BytemarkHosting/symbiosis/issues/134
Certification Authority Authorization (CAA), specified in RFC 6844 in 2013, is a proposal to improve the strength of the PKI ecosystem with a new control to restr...Imported from https://www.github.com/BytemarkHosting/symbiosis/issues/134
Certification Authority Authorization (CAA), specified in RFC 6844 in 2013, is a proposal to improve the strength of the PKI ecosystem with a new control to restrict which CAs can issue certificates for a particular domain name. It prevents bad people obtaining certificates from rogue or sloppy certification authorities.
It's a simple DNS text record to say, for example:
`example.org. CAA 128 issue "letsencrypt.org"`
At minimum, we could publish this record for a domain that's protected by a LetsEncrypt certificate.
https://blog.qualys.com/ssllabs/2017/03/13/caa-mandated-by-cabrowser-forumFuture Planshttps://gitlab.com/sympl.io/sympl/-/issues/163Symbiosis: PHP 7.1/7.2 support2020-09-15T21:33:38ZPaul CammishSymbiosis: PHP 7.1/7.2 supportImported from https://www.github.com/BytemarkHosting/symbiosis/issues/128
(https://forum.bytemark.co.uk/t/symbiosis-stretch-update/2848/30)
PHP7.0's EOL is 3/12/18, which is a little short, given that PHP7.2 is only 'officially' availa...Imported from https://www.github.com/BytemarkHosting/symbiosis/issues/128
(https://forum.bytemark.co.uk/t/symbiosis-stretch-update/2848/30)
PHP7.0's EOL is 3/12/18, which is a little short, given that PHP7.2 is only 'officially' available in Buster, and PHP7.1 in Sid.
We already run 7.1 and 7.2 in containers (Systemd-nspawn, Docker) for some customers using Symbiosis, but the setup procedure is mostly manual.
Ideally we'd want to be able to create a file e.g. `/srv/domain.com/config/php` containing `7.1<` or `7.2` to automatically use the appropriate Apache template for that domain.Future Planshttps://gitlab.com/sympl.io/sympl/-/issues/153Symbiosis: Migration assistant2019-04-14T20:37:18ZPaul CammishSymbiosis: Migration assistantImported from https://www.github.com/BytemarkHosting/symbiosis/issues/60
We spend a lot of time helping customers with migrations, or advising that they migrate to avoid a dist-upgrade.
It would be nice if Symbiosis Stretch included a ...Imported from https://www.github.com/BytemarkHosting/symbiosis/issues/60
We spend a lot of time helping customers with migrations, or advising that they migrate to avoid a dist-upgrade.
It would be nice if Symbiosis Stretch included a script to migrate all domains from Symbiosis Jessie (and maybe Wheezy). Something based on this migration guide would be useful. https://forum.bytemark.co.uk/t/the-symbiosis-migration-guide/2172
It should do as much of that as possible, and carry suitable health warnings, perhaps.
Future Planshttps://gitlab.com/sympl.io/sympl/-/issues/144Symbiosis: If an SSL cert is automatically disabled, Symbiosis won't use auto...2019-07-17T15:53:24ZPaul CammishSymbiosis: If an SSL cert is automatically disabled, Symbiosis won't use automatically it again if it becomes validImported from https://www.github.com/BytemarkHosting/symbiosis/issues/111
For example, if I have a site (https://under100words.com) and manually disable Let's Encrypt by placing `false` in `/srv/under100words.com/config/ssl-provider` an...Imported from https://www.github.com/BytemarkHosting/symbiosis/issues/111
For example, if I have a site (https://under100words.com) and manually disable Let's Encrypt by placing `false` in `/srv/under100words.com/config/ssl-provider` and moving the `config/ssl directory` out of the way, `symbiosis-httpd-configure` will disable the specific SSL cert for the site, swapping it to self-signed.
This is fine, and to be expected, however it does this by removing the relevant symlink from `/etc/apache2/sites-enabled`, which has the effect of flagging the site as "manually disabled", dropping it back to mass hosting, if configured.
Restoring the SSL configuration (removing `ssl-provider` and restoring `config/ssl`) then re-running `symbiosis-httpd-configure --verbose` you get:
```
# symbiosis-httpd-configure --verbose
[ . . . ]
Domain: under100words.com
Current SSL set 1: signed by /C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3, expires 2018-02-20 13:36:22 UTC
This site has SSL enabled, and is using the host's primary IPs -- continuing with SNI.
SSL is enabled -- using SSL template
Adding to configurations
[ . . . ]
Configuration: under100words.com.conf
Configuration is up-to date.
!! Configuration has been manually disabled.
```
So, it's still thinking that the site was manually disabled, so even if it managed to create the individual config as there are valid SSL certs, it's not being symlinked.
A manual workaround is to run `symbiosis-httpd-configure` for the specific site:
```
# symbiosis-httpd-configure --verbose under100words.com
Domain: under100words.com
Current SSL set 1: signed by /C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3, expires 2018-02-20 13:36:22 UTC
This site has SSL enabled, and is using the host's primary IPs -- continuing with SNI.
SSL is enabled -- using SSL template
Adding to configurations
Configuration: under100words.com.conf
Configuration is up-to date.
Enabling configuration.
Reloading Apache
```
This instead enables the config anyway, and things work normally again.Future Planshttps://gitlab.com/sympl.io/sympl/-/issues/139Symbiosis: Event bus for configuration changes2019-04-14T20:18:28ZPaul CammishSymbiosis: Event bus for configuration changesImported from https://www.github.com/BytemarkHosting/symbiosis/issues/45
A common problem in developing Symbiosis functionality is the difficulty in detecting configuration changes. Currently Symbiosis is configured using SFTP, but has ...Imported from https://www.github.com/BytemarkHosting/symbiosis/issues/45
A common problem in developing Symbiosis functionality is the difficulty in detecting configuration changes. Currently Symbiosis is configured using SFTP, but has no hooks into that system, so it's always going to be somewhat hobbled.
It would be good to have some sort of event bus to detect configuration changes, and act upon them at the time. This removes the need for polling which is wasteful and not very timely in some cases. Using a more event based approach would make configuration changes more or less instant, and maybe more reliable too.
One way of achieving this would be to have hooks into the SFTP subsystem. OpenSSH doesn't seem to have them, others do, ie https://www.npmjs.com/package/ssh
Whilst not advocating the addition of node into the stack, it would be good to have this functionality somehow, so it's open for debate.Future Planshttps://gitlab.com/sympl.io/sympl/-/issues/123Symbiosis: Ability to add an email attachment file extension black/whitelist2019-04-17T20:27:02ZPaul CammishSymbiosis: Ability to add an email attachment file extension black/whitelistImported from https://www.github.com/BytemarkHosting/symbiosis/issues/41
Would be nice to be able to block certain attachments to email, in addition to the usual antivirus scanningImported from https://www.github.com/BytemarkHosting/symbiosis/issues/41
Would be nice to be able to block certain attachments to email, in addition to the usual antivirus scanningFuture Planshttps://gitlab.com/sympl.io/sympl/-/issues/122Symbiosis: `symbiosis-configure-ips` doesn't remove IPs it added once they ar...2019-06-06T11:08:42ZPaul CammishSymbiosis: `symbiosis-configure-ips` doesn't remove IPs it added once they are removed from /srv/*/config/ipImported from https://www.github.com/BytemarkHosting/symbiosis/issues/59
If an IP has been added to a machine via `/srv/*/config/ip`, then if removed, it won't be removed from the configuration until next reboot when it won't be re-adde...Imported from https://www.github.com/BytemarkHosting/symbiosis/issues/59
If an IP has been added to a machine via `/srv/*/config/ip`, then if removed, it won't be removed from the configuration until next reboot when it won't be re-added.
This is likely as it can't be determined that Symbiosis added the IP, so we should probably either:
1. Make it clear in the docs that removing an IP will need a reboot or manual change via `ip`.
2. Automatically remove any IPs not set somewhere in `/srv/*/config/ip` when running symbiosis-configure-ips.
3. Provide a `--force` switch (like the other Symbiosis apps) to make the config match what symbiosis-configure-ips is trying to do.
Future Planshttps://gitlab.com/sympl.io/sympl/-/issues/15monit requires outside library which is not packaged2019-06-07T11:00:55ZPaul Cammishmonit requires outside library which is not packagedThe source repo is included in the repo here, but this is sub-optimal.
This should probably be replaced with something like https://mmonit.com/monit/, or simply replaced with a more maintainable alternative, as it's not that complex.The source repo is included in the repo here, but this is sub-optimal.
This should probably be replaced with something like https://mmonit.com/monit/, or simply replaced with a more maintainable alternative, as it's not that complex.Future Planshttps://gitlab.com/sympl.io/sympl/-/issues/12Add local DNS server with ability to allow AXFR to slaves2020-04-23T19:38:17ZPaul CammishAdd local DNS server with ability to allow AXFR to slavesFor sympl to work standalone, it needs an integrated DNS server. The should be automatically updated by the various DNS related operations, and provide for AXFR requests to be allowed to enable external servers to provide DNS for domains...For sympl to work standalone, it needs an integrated DNS server. The should be automatically updated by the various DNS related operations, and provide for AXFR requests to be allowed to enable external servers to provide DNS for domains hosted within sympl
Patrick Cherry has implemented something already, which might be a useful starting point:
https://gitlab.com/patch0/djbdns/wikis/homeFuture Plans