Migrating existing config to version: 2 can cause issues
#2852
Comments
|
Ok second server. Postal upgraded. We are listening on * port 587: Postal still running A new issue though -- getting a handshake failure: This is new so will proceed with the config change and hope that fixes it |
|
Trying to load certificates from Config: |
|
Had to set |
|
I can now confirm my original issue. Using my original config (albeit with tls disabled now), the SMTP server is listening on When I update the config to Note there also seems to be a difference in that with Original (Postal 2.3 config): general:
use_ip_pools: true
maximum_delivery_attempts: 20
suppression_list_removal_delay: 1
maximum_hold_expiry_days: 1
web:
host: server.example.com
protocol: https
web_server:
bind_address: 127.0.0.1
port: 5000
smtp_server:
port: 587
tls_enabled: false
tls_certificate_path: /config/certs/fullchain.pem
tls_private_key_path: /config/certs/privkey.pem
logging:
stdout: true
main_db:
host: 127.0.0.1
username: root
password: <password>
database: postal
pool_size: 10
message_db:
host: 127.0.0.1
username: root
password: <password>
prefix: postal
rabbitmq:
host: 127.0.0.1
username: postal
password: <password>
vhost: postal
dns:
mx_records:
- mx.server.example.com
smtp_server_hostname: server.example.com
spf_include: spf.server.example.com
return_path: rp.server.example.com
route_domain: routes.server.example.com
smtp:
host: server.example.com
port: 587
username: <username>
password: <password>
from_name: <From_name>
from_address: server@example.com
workers:
quantity: 30
threads: 12
rails:
secret_key: <secret_key>New (Postal v3) config: version: 2
postal:
web_hostname: server.example.com
web_protocol: https
smtp_hostname: server.example.com
use_ip_pools: true
default_maximum_delivery_attempts: 20
default_suppression_list_automatic_removal_days: 1
smtp_server:
default_port: 587
default_bind_address: '*'
tls_enabled: false
tls_certificate_path: /config/certs/fullchain.pem
tls_private_key_path: /config/certs/privkey.pem
logging:
enabled: true
main_db:
host: 127.0.0.1
username: root
password: <password>
pool_size: 10
message_db:
host: 127.0.0.1
username: root
password: <password>
dns:
mx_records:
- mx.server.example.com
smtp_server_hostname: server.example.com
spf_include: spf.server.example.com
return_path: rp.server.example.com
route_domain: routes.server.example.com
smtp:
host: server.example.com
port: 587
username: <username>
password: <password>
from_name: <From name>
from_address: server@example.com
rails:
secret_key: <secret_key> |
|
Okay... another new issue. Under DNS configuration: Return Path
Where is it getting |
The v2 configuration has a default to listen on 127.0.0.1 so this needs to be changed Either we should change this default or document this. I'm leaning towards changing the default.
The HELO should use
This was renamed from
This is an interesting one. The container sets 4 environment variables which will always override what is in the configuration file. These are all variables which relate to the path where files exist. At present, it is not possible to set these in the config file. To change them, you would need to change your I think the most useful thing I can do is make a guide on the key changes between v1 and v2 configuration to help with migrations. Broadly the main things are:
I'll get this transferred to the docs site shortly. Did I missing anything? |
This is the same behaviour as when using v1 configuration. Unlike the web server which is proxied, most people are going to need this so having the default remain seems like the easiest path for upgrades. see #2852
Yeah I think this will catch fewer people out, hopefully.
Yeah looks like this one was my bad and accounts for the inconsistency when I migrated the config the second time.
Does it make sense for now for me to copy the the cert and key to match the env var names?
Great!
Don't think so. Thanks for everything. It was quiet here for a while which made me a little nervous as I was about to move two business critical servers over to Postal but the momentum recently is really impressive and it's very much appreciated. Thank you. |
Yes
Not a problem! Quite a few new updates coming soon around authentication and the API too. |
|
On my Postal 2.3.2 server, I have fail2ban configured on the host to watch the smtp logs and ban repeat evil hitting the server. I have this set up with the following v1 config: (and I also have the directory …which results in postal logs being written to Is it possible to achieve the same behavior in the v2 configuration (iow, will |
Describe the bug
I just updated our smallest production server to Postal v3. Everything went fine, but I wanted to implement the new config format.
I re-wrote the config comparing to the new defaults, taking care to ensure all existing settings were updated to the correct parent key/name.
After doing so, Postal was no longer accepting SMTP connections:
Telnet was also falling over:
Nothing appeared to be out of the ordinary.
It seemed like the SMTP server was listening (Firewall forwards port 25 to 587):
Luckily I have two servers, one of which I hadn't upgraded yet. Which is when I realised that the exact listening parameters were different on my other Postal server:
I had to add:
To my config before I could get a response back on port 587.
I also had to explicitly define
helo_hostnameas without that being defined, the HELO hostname was defaulting topostal.example.com:I'm not sure why it was defaulting to that versus whichever sensible default that v2 may have been using.
I am about to repeat the process on the other server and I will report back if the same thing happens again, but I will be better placed to fix it more quickly this time and I'll provide any details either way in a subsequent comment along with existing/new config files.
The text was updated successfully, but these errors were encountered: