Skip to content

ChatMail destroys existing nginx site configurations #562

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Open
trollkotze opened this issue Apr 23, 2025 · 6 comments · May be fixed by #568
Open

ChatMail destroys existing nginx site configurations #562

trollkotze opened this issue Apr 23, 2025 · 6 comments · May be fixed by #568

Comments

@trollkotze
Copy link

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.
@trollkotze
Copy link
Author

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?

@trollkotze
Copy link
Author

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.

@trollkotze
Copy link
Author

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.

@link2xt
Copy link
Contributor

link2xt commented Apr 23, 2025

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).

@trollkotze
Copy link
Author

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?

@missytake missytake linked a pull request Apr 28, 2025 that will close this issue
Open
@missytake
Copy link
Contributor

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 :)

@severin-lemaignan severin-lemaignan mentioned this issue May 12, 2025
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

cmdeploy: exit if a necessary port is occupied by an unexpected process chatmail/relay
3 participants
@trollkotze @link2xt @missytake