Cloudron Forum

Fresh install.

Dec 25 22:50:44 ==> Creating directories
Dec 25 22:50:44 ==> Initialise database
Dec 25 22:50:44 panic: registerHooks: too many open files
Dec 25 22:50:44 2024-12-25T17:20:44Z
Dec 25 22:50:44 goroutine 1 [running]:
Dec 25 22:50:44 github.com/pocketbase/pocketbase/plugins/jsvm.MustRegister(...)
Dec 25 22:50:44 /home/runner/work/pocketbase/pocketbase/plugins/jsvm/jsvm.go:106
Dec 25 22:50:44 main.main()
Dec 25 22:50:44 /home/runner/work/pocketbase/pocketbase/examples/base/main.go:96 +0x6ce
Dec 25 22:50:46 => Waiting for app to come up
Dec 25 22:50:47 => Waiting for app to come up
Dec 25 22:50:48 => Waiting for app to come up
Dec 25 22:50:49 => Waiting for app to come up
Dec 25 22:50:50 => Healtheck error: Error: connect ECONNREFUSED 172.18.16.223:8090
Dec 25 22:50:50 => Waiting for app to come up
Dec 25 22:50:51 => Waiting for app to come up
Dec 25 22:50:52 => Waiting for app to come up
Dec 25 22:50:53 => Waiting for app to come up
Dec 25 22:50:54 => Waiting for app to come up
Dec 25 22:50:55 => Waiting for app to come up
Dec 25 22:50:56 => Waiting for app to come up
Dec 25 22:50:57 => Waiting for app to come up
Dec 25 22:50:58 => Waiting for app to come up
Dec 25 22:50:59 => Waiting for app to come up
Dec 25 22:51:00 => Healtheck error: Error: connect ECONNREFUSED 172.18.16.223:8090
Dec 25 22:51:00 => Waiting for app to come up
Dec 25 22:51:01 => Waiting for app to come up
Dec 25 22:51:02 => Waiting for app to come up
Dec 25 22:51:03 => Waiting for app to come up
Dec 25 22:51:04 => Waiting for app to come up
Dec 25 22:51:05 => Waiting for app to come up
Dec 25 22:51:06 => Waiting for app to come up
Dec 25 22:51:07 => Waiting for app to come up
Dec 25 22:51:08 => Waiting for app to come up
Dec 25 22:51:09 => Waiting for app to come up
Dec 25 22:51:10 => Healtheck error: Error: connect ECONNREFUSED 172.18.16.223:8090
Dec 25 22:51:10 => Waiting for app to come up
Dec 25 22:51:12 => Waiting for app to come up
Dec 25 22:51:13 => Waiting for app to come up
Dec 25 22:51:14 => Waiting for app to come up
Dec 25 22:51:15 => Waiting for app to come up
Dec 25 22:51:16 => Waiting for app to come up
Dec 25 22:51:17 => Waiting for app to come up
Dec 25 22:51:18 => Waiting for app to come up
Dec 25 22:51:19 => Waiting for app to come up
Dec 25 22:51:20 => Waiting for app to come up
Dec 25 22:51:20 => Healtheck error: Error: connect ECONNREFUSED 172.18.16.223:8090
Dec 25 22:51:21 => Waiting for app to come up
Dec 25 22:51:22 => Waiting for app to come up
Dec 25 22:51:23 => Waiting for app to come up
Dec 25 22:51:24 => Waiting for app to come up
Dec 25 22:51:25 => Waiting for app to come up
Dec 25 22:51:26 => Waiting for app to come up
Dec 25 22:51:27 => Waiting for app to come up
Dec 25 22:51:28 => Waiting for app to come up

And for now, should i simply delete those .conf files?

Yeah, that works.

A new (Directus) app that i cloned from an existing one, has seemingly become stuck in an unresponsive (502 Error) state.

The logs show:

[no timestamp]  [warn] conflicting server name "<my-app-domain>" on 0.0.0.0:80, ignored
[no timestamp]  [warn] conflicting server name "<my-app-domain>" on [::]:80, ignored
[no timestamp]  [warn] conflicting server name "<my-app-domain>" on 0.0.0.0:443, ignored
[no timestamp]  [warn] conflicting server name "<my-app-domain>" on [::]:443, ignored

How to resolve this issue?

Note:

• Domain's been configured using a Wildcard config
• Domain has no pending propagation (IPv4 & IPv6 addresses are correctly pointed)
• Tried "Sync DNS" > restart app already
• Have already uninstalled and reinstalled once

---

Update:
I have again uninstalled the app.
Upon inspecting /etc/nginx/applications/, i can now see 2 orphan configs (for the uninstalled apps) for the concerned <my-app-domain>, which should be the cause of this issue.

Is this a bug then (orphaned nginx configs persisting) ?

And for now, should i simply delete those .conf files?

Re: Directus - Package Updates

Kindly update the package to the latest release: https://github.com/directus/directus/releases/tag/v11.2.1

@nebulon

I don't think this is a strictly "SMTP" related issue. Even for auth, the Cloudron configured email should work just fine.

---

Update:

Yes, confirmed that the issue is that the Typebot instance is not aware of the available SMTP settings at all.

Example, the following defaults in the "env.sh" have been able to get my Typebot instance going properly now:

export SMTP_USERNAME="$CLOUDRON_MAIL_SMTP_USERNAME"
export SMTP_PASSWORD="$CLOUDRON_MAIL_SMTP_PASSWORD"
export SMTP_HOST="$CLOUDRON_MAIL_SMTP_SERVER"
export SMTP_PORT="$CLOUDRON_MAIL_SMTP_PORT"
export NEXT_PUBLIC_SMTP_FROM="$CLOUDRON_MAIL_FROM_DISPLAY_NAME <$CLOUDRON_MAIL_FROM>"
export SMTP_SECURE="false"
export SMTP_AUTH_DISABLED="false"

---

Recommendation: have the above config set by default, particularly in the cases where the admin selects "User Management by app", when installing the app.

Re: Mattermost - Package Updates v10.0

In case anyone missed it, v10+ includes some 'significant breaking changes'. An ongoing discussion:

https://www.reddit.com/r/Mattermost/s/tFxPzzRrIa

@nebulon said in Native (email) Auth doesn't seem to work out-of-box:

have you tried any of the others mentioned at https://docs.typebot.io/self-hosting/configuration ?

@nebulon Nope, as my current use-case requires the use of email based auth only.

@nebulon

So, is the current Typebot app package not functional right now?

@nebulon said in SSL certificate failing:

So Cloudron only issues certificates for domains which are used by any app. This is also since often Cloudron is used on domains which are not exclusively used by that Cloudron.

@nebulon said in SSL certificate failing:

I understand this is a bit annoying and maybe unexpected if that domain is exclusively used for that Cloudron, but we can't assume that.

See ->

@nebulon What do you mean?

The pointing of a domain and all of its subdomains, in this manner, implies precisely this, that the domain is managed exclusively by Cloudron.

@nebulon

• No, I don't have any app installed on the root domain
• The root domain points to the Cloudron instance. The certificate is now expired.
  So, irrespective of the existence of any apps on it, a valid certificate is indeed required for it (which is also why Cloudron issued it one, on the occasion of first install, right?)
• The well known locations work off the root domain, e.g. the Matrix server (https://domainX/.well-known/matrix/server), and which is now failing in my case (which is what pushed me down this unfortunate rabbit hole)

@joseph

The concerned domain, let's call it "domainX".

• My cloudron instance is accessed with the url : https://my.domainX
• There are a whole bunch of apps (*.domainX) in use

---

@joseph said in SSL certificate failing:

In the logs, it will tell you why it wasn't renewed and also the expiry of the certificate.

There's no mention of a certificate renewal attempt for just "domainX" in those very logs, only for all the apps using it with *.domainX

---

The original certificate for domainX was issued by/via Cloudron itself (if i'm not mistaken?), as seen below, so, i'm not sure what you mean here.

@nebulon

This is the sign up page ->

@nebulon
Just did a fresh install again, which resulted in the same issue:

@nebulon

I tried overwriting the SMTP related settings when the default was not functioning at all.

Hi @nebulon

I've tried the manual renewal process multiple times already.

Also, upon inspecting the logs, i found that the certificate for the 'root domain' is not being renewed to begin with!

Could that be the issue/bug here?

The certificate for my main domain (configured in Cloudron using Wildcard DNS) has expired and is not refreshing.

How to resolve this?

I tried setting up Typebot on my Cloudron instance yesterday, but couldn't get the native Email auth to work.

Keep seeing the "Set up one of the Auth Providers" message.

Configured the following env variables:

ADMIN_EMAIL
SMTP_USERNAME		SMTP username
SMTP_PASSWORD		SMTP password
SMTP_HOST		SMTP host. (i.e. smtp.host.com)
SMTP_PORT	25	SMTP port
NEXT_PUBLIC_SMTP_FROM		From name and email (i.e. 'Typebot Notifications' <notifications@host.com>)
SMTP_SECURE	false	If true the connection will use TLS when connecting to server. If false (the default) then TLS is used if server supports the STARTTLS extension. In most cases set this value to true if you are connecting to port 465. For port 587 or 25 keep it false
SMTP_AUTH_DISABLED	false	To disable the authentication by email but still use the provided config for notifications

Then also tried setting these when the above didn't work:

DATABASE_URL *		The database URL
ENCRYPTION_SECRET *		A 256-bit key used to encrypt sensitive data. It is strongly recommended to generate a new one. The secret should be the same between builder and viewer.
NEXTAUTH_URL *		The builder base URL. Should be the publicly accessible URL (i.e. https://typebot.domain.com)
NEXT_PUBLIC_VIEWER_URL *		The viewer base URL. Should be the publicly accessible URL (i.e. https://bot.domain.com)

Seems like i'm missing something here.

Kindly advise!

@nebulon Thanks! Got it working finally

I think i'm missing something obvious here, but i'm unable to find the method of creating a password for the first user.

The docs (https://docs.cloudron.io/apps/synapse/tion) don't mention anything regarding creating the password either

And i did try the Cloudron admin password, unsuccessfully.

@girish Thanks for the quick resolution!