relay ChatMail destroys existing nginx site configurations

Instead of overwriting /etc/nginx/nginx.conf, why not add configs in /etc/nginx/sites-available and symlink them as is common?

This is just bad and reckless. How do I get my old nginx.conf back? There is no backup.

There is not even a warning about it. Not that I have seen.

Apr 23 '25 14:04 trollkotze

And even after I restore nginx.conf from the apt package default, nginx is not working anymore. What is actually going on here? And how do I just undo all the destruction that installing ChatMail has wrought?

Apr 23 '25 14:04 trollkotze

Okay, seems like the main left over problem was the that acme redirect service added by chatmail for the web interface. No idea what that is for.

  systemctl disable acmetool-redirector.service
  systemctl stop acmetool-redirector.service
  systemctl enable nginx.service
  systemctl start nginx.service
  reboot

I don't know why but reboot was necessary because I could not start nginx.service since it was "inactive", whatever that means.

After that all the nginx hosted sites work normally again.

After that it seems chatmail continues to work, apart from the fact that the web page is gone. But then one can simply add something under /etc/nginx/sites/available -> /etc/nginx/sites-enabled to make one's own onboarding web page.

Only issue I still had here was that I had to remove the CAA DNS record that was recommended during the chatmail installation, because it would not let me generate a new certificate with certbot for that domain.

Apr 23 '25 15:04 trollkotze

Then add this (from chatmail's overwritten nginx.conf) to the site config you individually created under sites-available:

		# Old URL for compatibility with e.g. printed QR codes.
		#
		# Copy-paste instead of redirect to /new
		# because Delta Chat core does not follow redirects.
		#
		# Redirects are only for browsers.
		location /cgi-bin/newemail.py {
			if ($request_method = GET) {
				return 301 dcaccount:https://chat.sangham.net/new;
			}

			fastcgi_pass unix:/run/fcgiwrap.socket;
			include /etc/nginx/fastcgi_params;
			fastcgi_param SCRIPT_FILENAME /usr/lib/cgi-bin/newemail.py;
		}

                # Proxy to iroh-relay service.
                location /relay {
                        proxy_pass http://127.0.0.1:3340;
                        proxy_http_version 1.1;

                        # Upgrade header is normally set to "iroh derp http" or "websocket".
                        proxy_set_header Upgrade $http_upgrade;
                        proxy_set_header Connection "upgrade";
                }

		location /relay/probe {
                        proxy_pass http://127.0.0.1:3340;
                        proxy_http_version 1.1;
		}

		location /generate_204 {
                        proxy_pass http://127.0.0.1:3340;
                        proxy_http_version 1.1;
		}

(no idea about the /metrics route, though)

And a minimal onboarding page with working account sign-up link could then look like this:

<html>
  <head>
    <title>Welcome to chat.domain.com</title>
  </head>
  <body>
    <a href="DCACCOUNT:https://chat.domain.com/new">Get a chat.domain.com profile</a>
  </body>
</html>

Seems to work fine. No idea what all the other stuff from chatmail's nginx.conf is for.

Apr 23 '25 16:04 trollkotze

Instead of overwriting /etc/nginx/nginx.conf, why not add configs in /etc/nginx/sites-available and symlink them as is common?

Configuration is not really composable like this. If you already have websites on port 443, appending stream server also listening on port 443 will not work. Besides that, sites-available with symlinks in sites-enabed is specific to Debian configuration and will make porting to other distributions and operating systems more difficult.

There is not even a warning about it. Not that I have seen.

Then in probably should be added to the readme. Generally we expect that chatmail server is installed on a dedicated (virtual) machine. Otherwise it is possible that you already have an SMTP server such as Exim or IMAP server on your machine.

And even after I restore nginx.conf from the apt package default, nginx is not working anymore.

This was indeed likely due to acmetool listening on port 80. acmetool is running in the redirector mode to get TLS certificates from Let's Encrypt. It redirects all HTTP requests from port 80 to port 443 and answers to ACME challenges.

Only issue I still had here was that I had to remove the CAA DNS record that was recommended during the chatmail installation, because it would not let me generate a new certificate with certbot for that domain.

chatmail setup uses acmetool to get TLS certificates. This is documented in the readme. Both acmetool and certbot cannot be used at the same time.

Seems to work fine. No idea what all the other stuff from chatmail's nginx.conf is for.

stream configuration is used to multiplex SMTP, IMAP and HTTPS on port 443 so users can connect to the server even from networks that only allow HTTP(S).

Apr 23 '25 17:04 link2xt

Thank you for all the explanations, @link2xt !

stream configuration is used to multiplex SMTP, IMAP and HTTPS on port 443 so users can connect to the server even from networks that only allow HTTP(S).

So this means everything should work without it, except for people who are in such a network?

chatmail setup uses acmetool to get TLS certificates. This is documented in the readme. Both acmetool and certbot cannot be used at the same time.

As I mentioned, I added a TLS certificate with certbot for the web interface, and everything else seems to be still working. Is the acmetool-managed TLS certificate still required if I don't use the above-mentioned HTTPS multiplexing and simply use certbot for the web interface as I do now? So far it seems to work with acmetool disabled. I just wonder if there will be any issues when the originally issued acmetool-managed certificate expires.

And otherwise: How to completely and cleanly uninstall chatmail? It would be nice if there was a script for that. I haven't seen one. Just disabling and then removing the systemd services that were created? Would that be all?

Apr 24 '25 22:04 trollkotze

Thank you for all the explanations, @link2xt !

stream configuration is used to multiplex SMTP, IMAP and HTTPS on port 443 so users can connect to the server even from networks that only allow HTTP(S).

So this means everything should work without it, except for people who are in such a network?

Exactly :) some networks block SMTP ports for example, we don't let that stop us as long as port 443 works.

As I mentioned, I added a TLS certificate with certbot for the web interface, and everything else seems to be still working. Is the acmetool-managed TLS certificate still required if I don't use the above-mentioned HTTPS multiplexing and simply use certbot for the web interface as I do now? So far it seems to work with acmetool disabled. I just wonder if there will be any issues when the originally issued acmetool-managed certificate expires.

As long as you re-enable the certbot renewal cronjob and disable the acmetool one it should be fine.

And otherwise: How to completely and cleanly uninstall chatmail? It would be nice if there was a script for that. I haven't seen one. Just disabling and then removing the systemd services that were created? Would that be all?

As the recommended way to install chatmail relays is to use a completely new server, the recommended way is to remove the whole server... but in cases like yours, manually disabling the services and then removing /home/vmail to get rid of the user data should be more or less enough. You might want to keep or remove /var/lib/acme or /etc/dkimkeys, too.

I created a PR which ensures that all ports we need are free or occupied by processes we installed ourselves :)

Apr 28 '25 13:04 missytake

You could just make a copy of your nginx.conf before you deploy/update the server. But a hint before would be great too ;D

When using sites-enabled & sites-available you can move the server section https://github.com/chatmail/relay/blob/6cede707acbd652a3aeb52ca17dfa8afc57e88ee/cmdeploy/src/cmdeploy/nginx/nginx.conf.j2#L47 to your sites-available\chatmail.domain

Your ssl certificates etc. above and it should work.

        ssl_certificate /var/lib/acme/live/chatmail.domain/fullchain;
        ssl_certificate_key /var/lib/acme/live/chatmail.domain/privkey;
        include ssl/ssl-options.conf;

server {
        listen 127.0.0.1:8443 ssl default_server;

Maybe in chatmail.ini backup_nginx = yes by default.

Also fail2ban = yes would be good. Do you have already configs for fail2ban?

May 26 '25 09:05 Dan-Sun

Including configs from sites-enabled/* should be possible indeed, admins just need to make sure the pages they have there listen on port 8443. But we can document that somewhere. This would avoid merge conflicts for people who like custom nginx configs.

Only problem would be that it might silently misconfigure a working nginx config, so maybe we should make including sites-enabled optional with a config option.

Also, we need to unlink /etc/nginx/sites-enabled/default when we include the directory, so we don't include the default debian nginx config.

Jul 29 '25 16:07 missytake