Cloudron Forum

• Title: Supertokens on Cloudron - Open Source User Authentication

• Main Page: https://supertokens.com
• Git: https://github.com/supertokens/supertokens-core
• Licence: Apache 2.0, but excludes ee/ sub-directory (enterprise edition)
• Docker: Yes
• Demo:

• Summary: Supertokens provides a backend for user authentication, to permit your users to use any authentication mechanism for an account (passkeys, SSO, magic links, etc.).

• Notes: It seems like a very nice alternative to clerk, permitting freedom on the front-end by providing an API, but taking away the hassle of the different authentication methods for user management.

• Alternative to / Libhunt link: https://clerk.com

• Title: keygen on Cloudron - software & licensing API

• Main Page: https://keygen.sh
• Git: https://github.com/keygen-sh/keygen-api
• Licence: FCL-1.0-ALv2
• Docker: Yes
• Demo: https://app.keygen.sh

• Summary: Keygen enables commercial/proprietary software products with the implementation of licensing, by providing license key generation, license key validation (offline), and more.

• Notes: This may be admittedly a bit of a nice app, but seemingly attractive for anyone software product business that's not SaSS but providing software distributions of any kind.

• Alternative to / Libhunt link: Haven't found any open source alternative.

Thank you!

Thanks

I've noticed that the docker image for cal.com is rather big:

docker image ls
REPOSITORY                                TAG                         IMAGE ID       CREATED         SIZE
cloudron/com.cal.cloudronapp              202410300519450000          5e16a79c3c9a   2 weeks ago     15GB

The very latest seems even bigger with 22.4GB.

Compared to other apps this seems big, and it's almost double of what the upstream docker image is:

calcom/cal.com                                     latest      307203a992f4   9 hours ago   7.68GB

I understand that they're not derived from each other. A quick glance at the upstream docker file suggests that they're using multiple stages.

To those who are also running this app: What's the size of your image?

Same here, with the latest update it works now. Thank you folks for updating the cloudron app!! (You don’t realize how dependent you’ve become on a feature until it is gone

@Benoit we ran into exactly the same issue with our installation. I couldn’t find anything yet, but suspect that it’s upgrade related (happens not in new installations). Hoping the next upstream MM version fixes it.

@girish The MX record resolves to an ISPs server (Strato): smtpin.rzone.de But I don't know if this is particular timeout is domain specific or applies to all of strato. I'm worried it might be the former, at least protocol wise at the point of the delay the recipient domain is known and the server could apply domain specific settings for the backoff/delay.

@girish Hi! Quick follow-up on this: I ran into this again (as I'm now using the unmodified pristine config) and it appears that I also do need connect_timeout=300. I still get exactly the same behavior: Backoff after 64, backoff after 128 and then third time it works.

@robi I measured again and it look 30-50 seconds. With the default pool_timeout of 50 that should suffice, yet when I tried multiple times with the defaults it never succeeded. It's possible that it was always close.

I have tried to reach out to their IT support, because at first I thought it's a bug on their end. Their response was that they don't see anything wrong on their end. It's also a prospective business customer/partner, so my interest in the ability to exchange emails with them outweighs theirs for sure at this stage. Consequently I'd rather apply generous timeouts than ask their IT to make changes

I'm starting to learn to read the logs

When the delivery failed this was in the log when establishing the connection:

[core] [outbound] acquired socket XXX for outbound::25:A.B.C.D:undefined:50

and when it worked

[core] [outbound] acquired socket XXX for outbound::25:A.B.C.D:undefined:300

The 50 points indeed towards the pool_timeout.

Thanks a lot for your help and looking forward to the next release!

@nebulon Thanks for the pointer! I dug a little and copied across outbound.ini and added connect_timeout=300 and pool_timeout=300. Haraka indeed appears to reload after editing, according to the logs.

Let's see if this helps.

Do you know by chance how to re-try delivery of queued messages when they're already in exponential backoff? I tried -c /run/haraka --qunstick but that didn't quite work (produce a socket error about connecting to port 2525 of ::0

Edit: I emptied the queue manually and tried sending an email new. Now I'm getting somewhere, a back off from the SMTP server (Upstream error: 451 Temporary local problem, please try again!), first after 64 seconds, then again after 128 seconds. The third time it worked and it was delivered, so standard "grey listing" after that.

It might be worth bumping the defaults in Cloudron for Haraka on this.

I guess the manual changes I've done to the config file are lost on the next update?

Hi!

We noticed a situation where we're trying to send an email to somebody but mail delivery fails. I debugged this by looking into the mail logs and tried to reproduce the problem myself via telnet to port 25. I think I've succeeded diagnosing the issue that points towards something that I'm wondering if it is configurable in Cloudron:

The delivery starts by establishing a connection, delivering EHLO, MAIL TO and RCPT TO. After the RCPT to the server takes a long time until it responds with "250 OK" - a step that I think is deliberate.

With Cloudron's attempt at delivering the mail, it diagnoses socket timeout waiting on rcpt. Eventually after a few days of trying a bounce is generated.

If I try to establish the connection the same server from the same host "by hand" via telnet I can "reproduce" the situation and after rcpt to it does indeed sit a long time there, but eventually "250 OK" is generated.

So I'm wondering if there's a way to configure that rcpt timeout in Cloudron?