Good to read you could setup everything according to your needs!
Maybe some information to add as you asked yourself if this may have been LE rate limits related and there were more some comments about it earlier:
If ACME/LE rate limits are a cause of error, the error message states such. It would look like something along the following lines:
…
Response Code: 429
Response: {‘type’: ‘urn:ietf:params:acme:error:rateLimited’, ‘detail’: ‘Error creating new order :: too many failed authorizations recently: see Rate Limits - Let's Encrypt’, ‘status’: 429}
…
You would also not need to take a week off, just hitting it at an early stage, especially if early connectivity or DNS setup is still brittle, the limits are not that harsh:
There is a Failed Validation limit of 5 failures per account, per hostname, per hour.
So this would set you on an extended coffee-break with a walk to a good bakery for some nice cake. Or to read the link about LE rate-limits given in the error message.
Some more commands to test for connectivity on the host and also from within the container:
$ docker exec seatable /bin/sh -c 'curl -IvsS "$SEATABLE_SERVER_HOSTNAME"/' | head -1
* Trying 127.0.0.1...
...
HTTP/1.1 502 Bad Gateway
The same curl command can also be run on the host.:
$ curl -IvsS seatable.example.com | head -1
* Trying ...
...
HTTP/1.1 502 Bad Gateway
In both cases I would expect that they give a 502 as long as nginx.conf is not there (which is fine. This is the default and is before Nginx has been fully configured, e.g. before LE ran through. Nginx then runs in a limited mode to allow ACME Tiny to do the LE HTTP challenge/response).
Depending on DNS resolution for the hostname, the second curl command may have revealed that the WAN IP was still propagating and/or iptables not being configured to allow access on the ports, but that would be more clear when accessing from a remote host, as when the routing is only on the host, it would only check the connectivity into the container which is normally not an issue (but perhaps a good test in trouble-shooting).
DNS can be especially tricky as it is cached at multiple places. Curl can help here by requesting with the hostname but also tell curl which IP to use, so you can test for e.g. the firewall configuration before DNS propagation went through, e.g. for port 80 and 443 (HTTP/HTTPS). It is the --resolve <host:port:addr> argument (there is more info on the curl blog):
$ curl -IvsS --resolve seatable.example.com:80:1.2.3.4 seatable.example.com | head -1
* Added seatable.example.com:80:1.2.3.4 to DNS cache
* Hostname seatable.example.com was found in DNS cache
* Trying 1.2.3.4:80...
* TCP_NODELAY set
* connect to 1.2.3.4 port 80 failed: Network is unreachable
* Failed to connect to seatable.example.com port 80: Network is unreachable
* Closing connection 0
curl: (7) Failed to connect to seatable.example.com port 80: Network is unreachable
Just in case this is helpful for future visitors.
Have fun with your new SeaTable setup. And welcome again to the SeaTable forums!
