Posts made by staypath

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

I'm running my Cloudron on a hosted server, and not on my home network. I'm using the OpenVPN app to route all of my web traffic through my Cloudron instance. It seems like it would also be useful to install the AdGuard app and update the dnsmasq configuration in OpenVPN to use the AdGuard DNS server. Would that be possible with the way the OpenVPN and AdGuard apps are deployed in Cloudron?

@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 I'd like to ask - besides Nextcloud and Collabora/OnlyOffice, what Cloudron apps depend on being able to reach other apps on the same host?

@girish I ran some tcpdump sessions. When the container pings the public IPv4 of the host, the host responds to the ICMP packet, but it is responding to the private IP of the container (172.18.0.x). The packet doesn't seem to know how to get back to the container from the host.

@girish Thanks for the response! Restart of Unbound had no effect. Actually, the problem seems to be independent of DNS. I also cannot complete a curl request directly to the external IP of my host machine from inside the Nextcloud container. I can, however, complete a curl request from the host itself to the host's external IP. The problem only occurs when traffic originates from inside a container.

@girish Similar problem here with a new Cloudron installation on a dedicated server with a public IPv4. The Nextcloud container cannot access the host's external IP (loopback issue?), thus it cannot reach the Collabora container by DNS name. I do not have access to update any routing settings external to my host server. Is there a similar internal DNS trick with Unbound I could try? Thanks!

Curl from within my Nextcloud container works with external hosts...

root@1971ddba-1e76-495e-b0f7-40ab4a544caf:/app/code# curl -v yahoo.com
* Rebuilt URL to: yahoo.com/
*   Trying 98.137.11.164...
* TCP_NODELAY set
* Connected to yahoo.com (98.137.11.164) port 80 (#0)
> GET / HTTP/1.1
> Host: yahoo.com
> User-Agent: curl/7.58.0
> Accept: */*
> 
< HTTP/1.1 301 Moved Permanently
< Date: Wed, 03 Feb 2021 21:33:41 GMT
< Connection: keep-alive
< Server: ATS
< Cache-Control: no-store, no-cache
< Content-Type: text/html
< Content-Language: en
< X-Frame-Options: SAMEORIGIN
< Location: https://yahoo.com/
< Content-Length: 8
< 
* Connection #0 to host yahoo.com left intact

But not when trying to connect to my Collabora container:

root@1971ddba-1e76-495e-b0f7-40ab4a544caf:/app/code# curl -v collab.mydomain.com
* Rebuilt URL to: collab.mydomain.com/
*   Trying 131.xxx.xxx.xxx...
* TCP_NODELAY set