Cloudron Forum

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.

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

@nebulon Yes, that fixed it for me.

@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.

Thanks. Any way to implement the temporary mitigations for the latest alert here? https://www.metabase.com/blog/security-advisory-h2

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

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.

@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

@d19dotca works well for contacts on iOS and Android. I don't use it for calendars.

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

https://wiki.debian.org/FreedomBox

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

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 have updated the repo here with built-in LDAP auth:

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

@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

@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.

@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!

@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.

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

@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

@staypath Sorry. I should have dug into the setup scripts more before asking. I found this entry in /home/yellowtent/box/setup/start.sh, which disables journald logging to syslog. I assume this is what is preventing SSHD logs from being sent to /var/log/auth.log. Is there any danger in re-enabling journald forwarding to syslog?

echo "==> Configuring journald"
sed -e "s/^#SystemMaxUse=.*$/SystemMaxUse=100M/" \
    -e "s/^#ForwardToSyslog=.*$/ForwardToSyslog=no/" \
    -i /etc/systemd/journald.conf

Otherwise, what are recommendations for using fail2ban to protect against SSH login attempts on the server?

@nebulon Found this thread and wanted to raise this issue again. I noticed the same - /var/log/auth.log is empty after a fresh Cloudron installation on a dedicated Ubuntu 20.04 server. I also followed the docs and enabled fail2ban for handling invalid SSH login attempts. However, fail2ban by default reads login attempts from /var/log/auth.log. Is there some setting during the installation of Cloudron that disables SSHD logging to /var/log/auth.log? If so, why? Thanks.

Also, to clarify, SSHD logs were going to /var/log/auth.log prior to installing Cloudron.