Cloudron Forum

just had the same issue and wanted to add something here as a documentation:

If both Grafana and Prometheus are running as a cloudron-app, you can add Prometheus as a data-source in Grafana by inputting http://<PROMETHEUS-SERVICE-UUID>:9090 in the URL-field where PROMETHEUS-SERVICE-UUID can be found form the prometheus container either by looking up its installation location in the Storage-Tab or by connecting via terminal and copying the hostname.

Cheers,
Jan

@girish and @nebulon thanks a lot (as always, I really love the amount of support you provide!)

Effectively everything was already documented here, and I just had to connect the dots.

What worked for me:

1. Login to the Cloudron-Server via SSH
2. Create this file sudo touch /etc/unbound/unbound.conf.d/cloudron-local.conf
3. Edit the file with this content sudo nano /etc/unbound/unbound.conf.d/cloudron-local.conf:

server:
        # Local zone definitions
        local-zone: "<YOUR_DOMAIN_HERE>." typetransparent
        local-data: "<YOUR_SUB_DOMAIN_HERE>.<YOUR_DOMAIN_HERE>. IN A <YOUR_STATIC_IP_HERE>"

so for example:

server:
        # Local zone definitions
        local-zone: "example.com." typetransparent
        local-data: "my.example.com. IN A 10.10.0.3"

4. Reboot the system

This should hopefully also fix this for other Apps that need to resolve this.

UPDATE: Damn... this fixed the immediate issue but after some more dabbling, I found that this had some side-effects where other Apps seem to have trouble connecting properly... Will work on this some more and update you if I find a workable solution.

@girish any news on this? As in Europe we currently have this ongoing war between Ukrain and Russia with a hight amount of cyber-attacks in circulation, it would be great to bump up the available security measures as much as possible

If you would be going to create a tunable security-setting here, it would also be really great if you could give the option to select which TLS-Versions should be supported and maybe set a sensible default to support 1.1, 1.2 and 1.3.

Also, do you know if Cloudron uses a Version of NGINX that already supports QUIC protocol rather than TCP to transport HTTP?

Would also be glad to lend a hand if you need support with getting this to work.

@BrutalBirdie said in TLS Cert exporter to enable up-front Firewall deep-packet-inspection:

acme.sh

Thanks for the hint. There is an ansible-module for this which is exactly how I will try to approach this.
If I found a workable solution, I'll come back to the forum and give you an update. Should I forget and someone else is interested, feel free to prompt me

Thanks for your quick responses and cudos to the great Coudron forum and staff, its really a joy to see how good your support is!

@fbartels is there a way to easily or "automatically" track all installed cloudron apps with Prometheus? As in: Do Cloudron-Apps come with a node_exporter installed and configured?

If not is there a best practice to start connecting Cloudron-Apps metrics into Prometheus?

Thanks and best Regard,
Jan

Having the same issue here and since I'd like to use BookStack for co-authoring in my business in an ongoing project this is critical for me. Current work-a-round is to install bookstack outside of Cloudron and use other authentication mechanisms but I'd love to have it working

Any information on how to resolve this?

Problem-Description:
BookStack fails on login attempt when trying to "Login with Cloudron" and returns this error:
OIDC Discovery Error: HTTP request failed during discovery with error: cURL error 60: SSL certificate problem: self-signed certificate (see https://curl.haxx.se/libcurl/c/libcurl-errors.html) for https://[MY-DOMAIN-AND-SUBDOMAIN]/openid/.well-known/openid-configuration

Expected behavior:

• Login should succede or give alternative login method with local authentication mechanism of BookStack

Actual behavior:

• Login fails with described error message.

What I have tried so far:

• Loaded Backup of earlier installs when App was working but similar behavior now
• curl -v https://[MY-DOMAIN-AND-SUBDOMAIN]/.well-known/openid-configuration yields the expected result
• Ensured that IPv4 and IPv6 (Public) are detected by Cloudron, renewed all DNS-Entries and renewed all Certs
• In Cloudron Under Settings > Networking added my local Network as trusted IP-range
• Rebootet all participating systems (Cloudron, Proxmox, pfSense, WIFI-AP)
• Created a blank new BookStack instance. Identical issue when trying to do first-login via OIDC

On the setup and last known changes:

• Operating Cloudron inside a VM on my local Proxmox in my home-network
• Have fixed IPv4 from my ISP which is forwarded to Cloudron instance
• Installed a pfSense last week so: Internet (ISP) => Modem (ISP) in bridged Mode => pfSense => Internal Network with Cloudron being one of them

To me it looks like there is a static(?) cert missing in the BookStack App.

Any advise on how to proceed? Thank you in advance!

Jan

tl;dr:
Has anybody got a working setup for using pGina for Win10 Authentication/Authorization with the Cloudron built-in LDAP-Server?

Hi everybody,

I am currently trying to generate a setup for a client where he can have his primary user-management in Cloudron as he will mostly use the Web-Services anyway. The client now requested that the Login for his Windows10 machines should also use the same login.

One Google-Search (and 2 ChatGPT prompts) later I found that there is the pGina Project which allows to do just that.

After following some Tutorials and tinkering around with the setup, I can get my machine to Authenticate to the LDAP Server correctly:

However the Authorization part does not work currently:

If in the Authorization Rule-Set, I set Default to allow, it will allow access without checking if my given user is part of the Group, that I care about as specified in the rule-set below. Which is not the behavior I want to have.

I can check with other tools like JXplorer that the User I am testing actually is in the group I care about:

Did anybody try something similar and succeed here? Would love to get your insights on this

Best regards,
Jan

@girish as a quick fix this would help aslong as the contents still are encrypted

@girish since it worked with my other NAS, I am pretty confident now that it is rather a Permission-Issue on the TrueNAS-Side which I dont understand well enough as of yet.

Thanks for the link!

Ok, after same more debugging with @girish it turned out that this solution works as intended.

My Email-Services stopped working which was due to a change in local name resolution. Restarting the Email-Server and updating some configurations in my Firewall solved the issue.

@girish thanks for the suggestion. I know about this approach but my goals are:

• Have short-lived certificates with a well established and protected renewal-mechanism in order to minimize potential damage (exposure time) from leaked certificates (threat model)
• Have a way to bring automation into the stack to comply with some corporate policies so certificates can be "made known" to other systems such as firewalls (need for automation to reduce manual efforts)

For now I'll try to generate the certs in an external Certbot-workflow and distribute them to Cloudron just like other endpoints. This will outsource the renewal process from these systems.

@DanTheMan did you have success? Trying to do the same thing now. My approach will be:

1. Set up a Container with Authelia (cloud also be a VM) in my private network alongside the Cloudron VM as in the same sub-net or vLAN
2. Adapt Authelias Config accordingly, I want it to utilize a LDAP Backend and for starters integrating the one that Cloudron offers.
3. Let Cloudron do the Cert-handling and expose Authelia via Cloudron-App-Proxy
4. Adapt the Nginx-Config for the Cloudron Apps, I want to protect to require the SSO flow Authelia offers.

How did you approach the issue? Did you do things differently?

Hello Cloudron-Team,

It would be great to have a feature that allows for the export of the Lets!Encrypt Certificates, sounds strange but below is why this would be great.

Feature Description:
Have an API-Endpoint or Workflow that can trigger a Webhook or direct export of the Let’s Encrypt/Certbot Certificates to remote Systems especially Firewalls.

Use Case:
When using Cloudron in networks of industrial clients they usually want to secure ALL traffic through a central firewall. To allow for the deep-packet-inspection capabilities and the corresponding protection level the firewall needs to have access to the certificates used for the TLS-channels, else it can only see that there is encrypted traffic happening. Since Let's Encrypt/Certbot is cyclically renewing the certificates an automated way/workflow of "informing" upstream systems of new certificates would reduce manual efforts.

Expected Behavior:
When a certificate is initially issued OR when it is renewed by Certbot as a post-processing step there should be the possibility to configure a Webhook that recieves this certificate along some meta-data on the application for use in upstream systems, mainly Firewalls.

Is there some way to achieve this at this point already or would this be a new feature?

Best regards and keep up the good work Cloudron and the Comunity are really great,
Jan Macenka

Same issues here. I tracked it down somewhat in the Log-Files while restoring to some older backuped versions.

In App-Version v1.16.4 things seemed to be working v1.17 seems to be boroken. However even in v1.16.4 there was this behavior in the logs:

In the more extensive log-files there was this:

And in an earlier version, I found this:

To me this looks like there were some breaking-changes in how LDAP is handled or how required resources are loaded.

@nebulon could you look into that? If required, shoot me a message and I can give access to my instance for further review.

My current "quick fix" is to restore to a backup of at v1.16.4 and disable automatic updates, though this should only be a short-term work-a-round.

Unfortunately I am experiencing the same bug currently... having a backup of my metrics would be kind of important to me.

@BrutalBirdie any know work-a-rounds?