Sympl issueshttps://gitlab.com/sympl.io/sympl/-/issues2019-07-17T15:53:24Zhttps://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/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/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/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/166Symbiosis: reject-www-data rule unintentionally removed from ip6tables when f...2019-06-07T14:36:07ZPaul CammishSymbiosis: reject-www-data rule unintentionally removed from ip6tables when file contains only IPv4 addressesImported from https://www.github.com/BytemarkHosting/symbiosis/issues/76
When an IPv4 address is added to the reject-www-data rule, the rule is removed from ip6tables.
1. Run `ip6tables -L -v -n` and notice the reject-www-data table is...Imported from https://www.github.com/BytemarkHosting/symbiosis/issues/76
When an IPv4 address is added to the reject-www-data rule, the rule is removed from ip6tables.
1. Run `ip6tables -L -v -n` and notice the reject-www-data table is present
2. Add 10.0.0.1 to `/etc/symbiosis/firewall/outgoing.d/50-reject-www-data`
3. Run `ip6tables -L -v -n` and notice the reject-www-data table is *no longer* presentBackloghttps://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/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/176Symbiosis: SSL symlinks broken on hostname change2019-07-17T15:54:09ZPaul CammishSymbiosis: SSL symlinks broken on hostname changeImported from https://www.github.com/BytemarkHosting/symbiosis/issues/42
When the hostname of a system running Symbiosis is changed the symbolic links for the self signed certificates in <code>/etc/ssl</code> are broken.
The symbolic l...Imported from https://www.github.com/BytemarkHosting/symbiosis/issues/42
When the hostname of a system running Symbiosis is changed the symbolic links for the self signed certificates in <code>/etc/ssl</code> are broken.
The symbolic links in <code>/etc/ssl</code> continue to point at <code>/srv/original-server-name/...</code>.
This then prevents the Apache service from starting as the SSL files are missing/invalid.Backloghttps://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/184Symbiosis: symbiosis-httpd-configure breaks when no certificates are available.2019-06-07T14:36:24ZPaul CammishSymbiosis: symbiosis-httpd-configure breaks when no certificates are available.Imported from https://www.github.com/BytemarkHosting/symbiosis/issues/112
symbiosis-httpd-configure breaks when no certificates are available.
Steps to reproduce:
1. Spin up a new Symbiosis 8 server at panel.bytemark.co.uk
2. remove t...Imported from https://www.github.com/BytemarkHosting/symbiosis/issues/112
symbiosis-httpd-configure breaks when no certificates are available.
Steps to reproduce:
1. Spin up a new Symbiosis 8 server at panel.bytemark.co.uk
2. remove the contents of /etc/ss
3. run "symbiosis-httpd-configure --force --verbose"
4. run "apachectl restart"
Expected behaviour:
* Apache restarts.
Observed behaviour:
* Apache fails to restart. An error message like "Failed to configure at least one certificate and key for symbiosis.foo.bar.uk0.bigv.io:443"
Workaround:
* remove /etc/apache2/sites-enabled/zz-mass-hosting.ssl.conf - Apache will now start, until symbiosis-httpd-configure is run again.
Suggested fix:
* Symbiosis-httpd-configure should test for the presence of some certificate before proceeding to enable zz-mass-hosting.ssl.confBackloghttps://gitlab.com/sympl.io/sympl/-/issues/189Symbiosis: Update dns.rb to make default dmarc policy safer2019-06-07T14:36:29ZPaul CammishSymbiosis: Update dns.rb to make default dmarc policy saferImported from https://www.github.com/BytemarkHosting/symbiosis/issues/130
The current dmarc policy is dangerous, in that it says to quarantine 100% of unaligned email from the main domain (but oddly not subdomains). This policy is much ...Imported from https://www.github.com/BytemarkHosting/symbiosis/issues/130
The current dmarc policy is dangerous, in that it says to quarantine 100% of unaligned email from the main domain (but oddly not subdomains). This policy is much safer for an initial dmarc policy, as recommended for example, by Google at https://support.google.com/a/answer/2466563?hl=en&ref_topic=2759254Backloghttps://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/227Sympl parser2019-07-05T12:19:35ZPaul CammishSympl parserA basic version of the Sympl parser should be created, covering the most common things:
Creating domains, sites, mailboxes, ftp accounts, etc.
This can then be used in the new documentation, and expanded on further.A basic version of the Sympl parser should be created, covering the most common things:
Creating domains, sites, mailboxes, ftp accounts, etc.
This can then be used in the new documentation, and expanded on further.BacklogPaul CammishPaul Cammishhttps://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/288sympl-core: Man page broken for sympl-ssl2020-04-20T11:37:33ZPaul Cammishsympl-core: Man page broken for sympl-sslThis is likely as the sympl-ssl man pages are built from the ruby normally, which currently has a wrapper to fix IPv6 support.
This should be fixed soon if possible, otherwise it will be fixed as part of issue #278.This is likely as the sympl-ssl man pages are built from the ruby normally, which currently has a wrapper to fix IPv6 support.
This should be fixed soon if possible, otherwise it will be fixed as part of issue #278.https://gitlab.com/sympl.io/sympl/-/issues/311sympl-core: MOTD refers to v9.0 and v10.02021-04-13T11:38:10ZPaul Cammishsympl-core: MOTD refers to v9.0 and v10.0Since switching to continuous releases, we should remove the '.0' references on the MOTDSince switching to continuous releases, we should remove the '.0' references on the MOTDhttps://gitlab.com/sympl.io/sympl/-/issues/262sympl-firewall v10.0 uses iptables-legacy2019-08-16T17:52:37ZPaul Cammishsympl-firewall v10.0 uses iptables-legacyBuster has migrated to nftables, so Sympl should move in that direction also.
It's mostly compatible at the moment, however it does throw warnings when using the now default `iptables` in Buster.
Workround in sympl/sympl!124 to swap to...Buster has migrated to nftables, so Sympl should move in that direction also.
It's mostly compatible at the moment, however it does throw warnings when using the now default `iptables` in Buster.
Workround in sympl/sympl!124 to swap to `iptables-legacy`, but this should be investigated futher.https://gitlab.com/sympl.io/sympl/-/issues/301sympl-firewall: "Another app is currently holding the xtables lock"2020-09-17T13:30:58ZPaul Cammishsympl-firewall: "Another app is currently holding the xtables lock"One user was reporting emails like this, coming from `/usr/sbin/sympl-firewall` and `/usr/sbin/sympl-firewall-blacklist` on two hosts.
```text
From: Cron Daemon <root@hostname.fqdn>
Date: Mon, 14 Sep 2020 at 19:00
Subject: Cron <root@ho...One user was reporting emails like this, coming from `/usr/sbin/sympl-firewall` and `/usr/sbin/sympl-firewall-blacklist` on two hosts.
```text
From: Cron Daemon <root@hostname.fqdn>
Date: Mon, 14 Sep 2020 at 19:00
Subject: Cron <root@hostname> [ -x /usr/sbin/sympl-firewall ] &&
/usr/sbin/sympl-firewall
To: <root@hostname.fqdn>
Another app is currently holding the xtables lock. Perhaps you want to use
the -w option?
sympl-firewall: Firewall script failed.
sympl-firewall: Flushing /sbin/iptables rules and chains.
sympl-firewall: Flushing /sbin/ip6tables rules and chains.
sympl-firewall: Restoring old iptables rules and chains.
sympl-firewall: Restoring old ip6tables rules and chains.
sympl-firewall: Left firewall script in
/tmp/user/0/sympl-firewall-20200914-1505-1srb1j3-saved for inspection.
```
The direct cause is unclear at the moment, and they don't happen all the time (once a day or so, apparently), so it may simply be a race condition.https://gitlab.com/sympl.io/sympl/-/issues/320sympl-firewall: does not play nicely with iptables-persistent2021-12-06T19:55:39ZPaul Cammishsympl-firewall: does not play nicely with iptables-persistentYou can get in an odd state if you don't have any v4 DNS resolvers and have iptables-persistent installed, where it will eventually fail to bring up the IPv6 address on the server, after timing out, and sympl-fireall will fail in an odd ...You can get in an odd state if you don't have any v4 DNS resolvers and have iptables-persistent installed, where it will eventually fail to bring up the IPv6 address on the server, after timing out, and sympl-fireall will fail in an odd was, meaning the server acts unusually.
Adding iptables-persistent (and friends) to the conflicts list should prevent this.