Cloudron Forum

Repo has been updated to include the following:

• split the Dockerfile into Dockerfile.cloudron and start.sh to match Cloudron app standards
• built-in LDAP auth

I've tested backup,restore and package upgrade.

https://github.com/jsonsmth/node-red-docker-cloudron

Thanks!

I'm a long-time Node-RED user. I was able to get a custom app packaged for Cloudron. So far, so good...

Here's a working config sample for Digital Ocean Spaces. Add the following entries in the env.sh and restart the Typebot app:

export S3_ACCESS_KEY=<YOUR DO ACCESS KEY>
export S3_SECRET_KEY=<YOUR DO SECRET KEY>
export S3_BUCKET=<YOUR BUCKET NAME>
export S3_ENDPOINT=nyc3.digitaloceanspaces.com
export S3_REGION=US
export S3_PORT=443

@girish Ok, I understand a bit more about the Cloudron build process now. I have updated my Dockerfile.cloudron and moved the repo here:

https://github.com/jsonsmth/node-red-docker-cloudron

The updated build process stores all app code in /app/code and only the user-specific data (including user node_modules) in /app/data.

There are basically two apps in one with Typebot. There's the "builder" app which is the admin interface used to create and manage bot flow (this has the auth tied to it), and the "viewer" app, which is where published bots can be viewed by the public. I don't think you can add auth to the viewer URLs.

I have updated the repo here with built-in LDAP auth:

https://github.com/jsonsmth/node-red-docker-cloudron

I just went into Digital Ocean and configured the CORS policy as it states. There's a gui for that:

Then I had to configure the ACL using s3cmd. It was tedious, but once done it just works forever.

@baptistearno Man, this is so great. Looks like a lot of work was put in. Awesome job, and thanks for the effort!

@robi Cloudron customizations are in the docker-custom folder

https://github.com/jsonsmth/node-red-docker

Feedback is welcome as this is my first foray into Cloudron app customization.

@nebulon Yes, that fixed it for me.

@girish Also, I think we're following along with the recommended method for preserving user data within the app:

https://github.com/jsonsmth/node-red-docker-cloudron#managing-user-data

@Aizat Thanks for mentioning this awesome software! Someone has pinged the author about creating a Cloudron app. Hopefully it will happen...

https://github.com/baptisteArno/typebot.io/issues/30

Here's a similar idea that has the hardware part mostly figured out:

https://wiki.debian.org/FreedomBox

https://wiki.debian.org/FreedomBox/Hardware

@nebulon One minor issue when using the OpenAI integration in Typebot on Cloudron. It was covered in the Typebot issues on Github, but might be worth noting here as well. I had to manually change the value in the .encryption_secret file.

@girish Yes. Any new "plugins" installed are node modules that would be installed in /app/data/data/node_modules

I installed a couple of Node-RED modules (plugins), took a backup of the app in Cloudron, cloned the app from backup, etc... and all seemed to work well. Anything I'm missing? Thanks!

@girish Thank you for the recommendation. I have tried on another bare metal server running Docker and I am able to access the external host IP from the Docker container. This is clearly a network issue with the host where I have Cloudron installed.

@staypath Continuing my conversation with myself

Posting this here in case anyone else comes across this with the same question: I found that configuring fail2ban to use systemd was the trick:

[sshd]

port    = ssh
#logpath = %(sshd_log)s
#backend = %(sshd_backend)s
backend = systemd
enabled = true
maxretry = 1
bantime = 14d

Strangely, once I logged in using Incognito Mode, I was then able to login using non-incognito mode without needing to clear the cache at all.

Been a while since I built the Docker version of Node-RED for Cloudron, but it worked with Cloudron LDAP auth when I built it. My method had a single admin user that can access all Node-RED flows, so there's no concept of permissions. That works fine for me, but might not for others. I'd be willing to revisit and update my method to the latest Node-RED version to make sure everything still functions within Cloudron from a backup/restore perspective and with LDAP auth. I know @hendrikvl recommended using the npm approach vs. Docker approach, so it really depends on your needs.

I had a similar problem recently. Here's what I had to do in order to be able to programmatically update DNS records for a domain in Google Cloud DNS:

1. verify domain ownership: https://cloud.google.com/endpoints/docs/openapi/verify-domain-name. I did this by inputting a special DNS TXT record into DNS for the domain.

2. in my case, I was using a Google Cloud Service Account with Terraform (not Cloudron) to modify DNS records in Google Cloud DNS, so in additional to verifying domain ownership, I had to actually add the Service Account I created as a verified owner of the domain as well.

After doing these two things, I was able to programmatically update DNS records for the domain using the Service Account.

So, assuming you've created a Service Account at Google, given it the "DNS Administrator" role, and added the Service Account email as a verified owner of the domain, you should be good to go. I just tested it with my Cloudron and it all worked. I'm attaching a screenshot of the Google domain verification screen showing where I added the Service Account as a domain owner. Hope this helps.