Unable to get container working #55

sdooweloc · 2023-01-16T19:04:09Z

sdooweloc
Jan 16, 2023

Hey all. I am at a loss here. Trying to get mailrise working in a container with traefik and cannot for the life of me figure it out.
The container reports as running but has 0 logs when I run docker logs mailrise
I tried looking in the container but dont see any place that would define a log file or anything internally.
When I try to send a test email from for example gitea to mailrise.my.domain:465 gitea just hangs and nothing ever comes through. I have provided my configs below if anyone can offer assistance please.

If I have missed a file or something that would be useful for troubleshooting please let me know. I love the concept of this app and want to get it working and will do whatever needed to help that process happen.

Docker-compose.yml

networks:
  proxy:
    external: true

services:
  mailrise:
    image: yoryan/mailrise
    container_name: mailrise
    restart: unless-stopped
    networks:
      - proxy
    volumes:
      - /mnt/docker/mailrise/mailrise.conf:/etc/mailrise.conf:ro
    labels:
      traefik.tcp.routers.mailrise.rule: "HostSNI(`*`)"
      traefik.tcp.routers.mailrise.tls: "true"
      traefik.tcp.routers.mailrise.certresolver: "cloudflare"
      traefik.tcp.routers.mailrise.tls.domains[0].main: "mailrise.my.domain"
      traefik.tcp.routers.mailrise.tls.domains[0].sans: ""
      traefik.tcp.routers.mailrise.entrypoints: "mailsecure"
      traefik.docker.network: "proxy"

mailrise.conf

configs:

  crowdsec:
    urls:
      - discord://ID/key    
   

  gitea:
    urls:
      - discord://ID/KEY


smtp:
  auth:
    basic:
      username: password
      AzureDiamond: hunter2

traefik.yml

...
entryPoints:
  http:
    address: ":80"
    http:
      middlewares:
        - crowdsec-bouncer@file
      redirections:
        entryPoint:
          to: https
          scheme: https
  https:
    address: ":443"
  mailsecure:
    address: ":465"
...
certificatesResolvers:
  cloudflare:
    acme:
      email: myemail 
      storage: acme.json
      dnsChallenge:
        provider: cloudflare
        resolvers:
          - "1.1.1.1:53"
          - "1.0.0.1:53"
...

YoRyan · 2023-01-16T20:14:36Z

YoRyan
Jan 16, 2023
Maintainer

First things first, see if Mailrise works without the Traefik wrapper. If you want extra logging pass -v or -vv. The full command needs to include the path to the configuration, so you should be using e.g. -v /etc/mailrise.conf.

Once you've confirmed Mailrise is doing its thing, you can turn your attention to your Traefik and Compose configurations. The Traefik Dashboard will show you whether you've connected your routers and services correctly. As for Compose, you seem to be using an unmanaged proxy network, which could possibly cause connectivity issues between the containers. Is that network handing out IP addresses?

I'll caution that I am not really a Traefik expert; the config I have in the Readme is what works for me.

0 replies

sdooweloc · 2023-01-16T20:19:03Z

sdooweloc
Jan 16, 2023
Author

What command are you referring to? The docker compose doesnt include a command in your templates and running it just uses docker-compose up -d so I am not sure where you are wanting me to pass the -v and config location.

The proxy network is what everything that is behind traefik is on and no other containers have any issues being on it. I have an entire media stack, gitea, portainer, and more all on that network with IPs and connectivity with my external machine and each other.

0 replies

YoRyan · 2023-01-16T20:23:35Z

YoRyan
Jan 16, 2023
Maintainer

I'm referring to the command-line arguments passed to the container. In Compose, you set these with the command field.

services:
  mailrise:
    image: yoryan/mailrise
    container_name: mailrise
    command: -vv /etc/mailrise.conf
    restart: unless-stopped
    networks:
      - proxy
    volumes:
      - /mnt/docker/mailrise/mailrise.conf:/etc/mailrise.conf:ro
    labels:
      traefik.tcp.routers.mailrise.rule: "HostSNI(`*`)"
      traefik.tcp.routers.mailrise.tls: "true"
      traefik.tcp.routers.mailrise.certresolver: "cloudflare"
      traefik.tcp.routers.mailrise.tls.domains[0].main: "mailrise.my.domain"
      traefik.tcp.routers.mailrise.tls.domains[0].sans: ""
      traefik.tcp.routers.mailrise.entrypoints: "mailsecure"
      traefik.docker.network: "proxy"

Also see if you can get any services to reach Mailrise directly (by IP address), without going through Traefik.

0 replies

sdooweloc · 2023-01-16T20:34:16Z

sdooweloc
Jan 16, 2023
Author

Okay. Commented out all the labels and added in the command flag but left it on the proxy network since that is what everything else is on anyway.

Finally getting logs now though realistically not many logs

[2023-01-16 20:28:52] DEBUG:apprise:Loading raw configuration: urls:
- discord://ID/KEY

[2023-01-16 20:28:52] DEBUG:apprise:Loading raw configuration: urls:
- discord://ID/KEY

[2023-01-16 20:28:52] INFO:mailrise.skeleton:Loaded configuration with 2 recipient(s)
[2023-01-16 20:28:52] DEBUG:mailrise.skeleton:Arguments for aiosmtpd: authenticator=Basic(2), auth_required=True, auth_require_tls=False, tls_context=None, ssl_context=None, require_starttls=False
[2023-01-16 20:28:52] DEBUG:asyncio:Using selector: EpollSelector

Not sure really how best to get services to reach Mailrise in this state since the gitea method I was testing with requires TLS to be enabled and I am not passing any keys or anything into the container currently.

0 replies

sdooweloc · 2023-01-16T20:43:08Z

sdooweloc
Jan 16, 2023
Author

Also tried running with the extra flags with the labels uncommented and got the same log result just different timestamp.

so that leads me to believe that something is up with the way it is interfacing with traefik but as you can see from the stuff I posted originally I just added in the flags and such you mention (other than changing resolver to cloudflare and specifying the network) so unless there is something else in your traefik setup that I am missing I dont know what could be going on.

In my traefik dashboard I am not seeing anything in the TCP section for routers which confirms the theory it isnt interfacing properly

0 replies

YoRyan · 2023-01-16T20:44:15Z

YoRyan
Jan 16, 2023
Maintainer

The last user who had a similar problem (#47) needed to add the traefik.enable label as he was running with exposedByDefault set to false.

0 replies

sdooweloc · 2023-01-16T20:52:07Z

sdooweloc
Jan 16, 2023
Author

The last user who had a similar problem (#47) needed to add the traefik.enable label as he was running with exposedByDefault set to false.

Okay some progress now. That got me the TCP Router and Service in the Traefik dashboard.
however when I send an email it still isnt playing nice.
logs below but not sure what is going wrong as its just info debug and wrnings no errors.

[2023-01-16 20:48:08] DEBUG:asyncio:Using selector: EpollSelector
/home/mailrise/.local/lib/python3.11/site-packages/aiosmtpd/smtp.py:372: UserWarning: Requiring AUTH while not requiring TLS can lead to security vulnerabilities!
  warn("Requiring AUTH while not requiring TLS "
[2023-01-16 20:48:41] WARNING:mail.log:auth_required == True but auth_require_tls == False
[2023-01-16 20:48:41] INFO:mail.log:Available AUTH mechanisms: LOGIN(builtin) PLAIN(builtin)
[2023-01-16 20:48:41] INFO:mail.log:Peer: ('172.18.0.2', 38844)
[2023-01-16 20:48:41] INFO:mail.log:('172.18.0.2', 38844) handling connection
[2023-01-16 20:48:41] DEBUG:mail.log:('172.18.0.2', 38844) << b'220 43bde50a2853 Mailrise 0.0.post1.dev1+gb1941ce'
[2023-01-16 20:48:41] DEBUG:mail.log:_handle_client readline: b'EHLO 843f8798da96\r\n'
[2023-01-16 20:48:41] INFO:mail.log:('172.18.0.2', 38844) >> b'EHLO 843f8798da96'
[2023-01-16 20:48:41] DEBUG:mail.log:('172.18.0.2', 38844) << b'250-43bde50a2853'
[2023-01-16 20:48:41] DEBUG:mail.log:('172.18.0.2', 38844) << b'250-SIZE 33554432'
[2023-01-16 20:48:41] DEBUG:mail.log:('172.18.0.2', 38844) << b'250-8BITMIME'
[2023-01-16 20:48:41] DEBUG:mail.log:('172.18.0.2', 38844) << b'250-SMTPUTF8'
[2023-01-16 20:48:41] DEBUG:mail.log:('172.18.0.2', 38844) << b'250-AUTH LOGIN PLAIN'
[2023-01-16 20:48:41] DEBUG:mail.log:('172.18.0.2', 38844) << b'250 HELP'
[2023-01-16 20:48:41] DEBUG:mail.log:_handle_client readline: b'AUTH PLAIN ********\r\n'
[2023-01-16 20:48:41] INFO:mail.log:('172.18.0.2', 38844) >> b'AUTH PLAIN ********'
[2023-01-16 20:48:41] DEBUG:mail.log:Using builtin auth_ hook for 'PLAIN'
[2023-01-16 20:48:41] DEBUG:mail.log:auth_PLAIN returned AuthResult(success=False, handled=True, message=None, auth_data=...)

0 replies

YoRyan · 2023-01-16T20:53:51Z

YoRyan
Jan 16, 2023
Maintainer

That last line indicates your client provided an incorrect username/password combo.

0 replies

sdooweloc · 2023-01-16T20:58:10Z

sdooweloc
Jan 16, 2023
Author

Okay. Yep I do see the typo there now that it is actually hitting something.
fixed the typo and got a DC ping so looking good

Is the complete log silence by default intentional? I have never seen a docker container log absolutely nothing to the stdout for docker logs and or things like Loki to pick up on. Makes troubleshooting if the container is actually even doing anything nearly impossible

0 replies

YoRyan · 2023-01-16T21:06:44Z

YoRyan
Jan 16, 2023
Maintainer

Is the complete log silence by default intentional? I have never seen a docker container log absolutely nothing to the stdout for docker logs and or things like Loki to pick up on. Makes troubleshooting if the container is actually even doing anything nearly impossible

The default logging level for a Python app is warnings or errors only. You're right that most other Docker images use the "info" level. I could certainly change the default behavior.

0 replies

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Unable to get container working #55

{{title}}

Replies: 10 comments

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

Select a reply

Unable to get container working #55

sdooweloc Jan 16, 2023

Replies: 10 comments

YoRyan Jan 16, 2023 Maintainer

sdooweloc Jan 16, 2023 Author

YoRyan Jan 16, 2023 Maintainer

sdooweloc Jan 16, 2023 Author

sdooweloc Jan 16, 2023 Author

YoRyan Jan 16, 2023 Maintainer

sdooweloc Jan 16, 2023 Author

YoRyan Jan 16, 2023 Maintainer

sdooweloc Jan 16, 2023 Author

YoRyan Jan 16, 2023 Maintainer

sdooweloc
Jan 16, 2023

YoRyan
Jan 16, 2023
Maintainer

sdooweloc
Jan 16, 2023
Author

YoRyan
Jan 16, 2023
Maintainer

sdooweloc
Jan 16, 2023
Author

sdooweloc
Jan 16, 2023
Author

YoRyan
Jan 16, 2023
Maintainer

sdooweloc
Jan 16, 2023
Author

YoRyan
Jan 16, 2023
Maintainer

sdooweloc
Jan 16, 2023
Author

YoRyan
Jan 16, 2023
Maintainer