Skip to content

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

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.

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

Unable to get container working #52

Closed
sdooweloc opened this issue Jan 16, 2023 · 10 comments
Closed

Unable to get container working #52

sdooweloc opened this issue Jan 16, 2023 · 10 comments
Labels
question Further information is requested

Comments

@sdooweloc
Copy link

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 YoRyan added the question Further information is requested label Jan 16, 2023
@YoRyan
Copy link
Owner

YoRyan commented Jan 16, 2023

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.

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

@YoRyan
Copy link
Owner

YoRyan commented Jan 16, 2023

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.

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

@sdooweloc
Copy link
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

@YoRyan
Copy link
Owner

YoRyan commented Jan 16, 2023

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.

@sdooweloc
Copy link
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=...)

@YoRyan
Copy link
Owner

YoRyan commented Jan 16, 2023

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

@sdooweloc
Copy link
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

@YoRyan
Copy link
Owner

YoRyan commented Jan 16, 2023

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.

@YoRyan YoRyan closed this as completed Jan 16, 2023
Repository owner locked and limited conversation to collaborators Jan 17, 2023
@YoRyan YoRyan converted this issue into discussion #55 Jan 17, 2023

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

Labels
question Further information is requested
Projects
None yet
Development

No branches or pull requests

2 participants