Cloudron Forum

Yes, problem solveld. Thank you!

Are there any insights or resulutions to this? Also am trying (for the 3rd time) to transfer a NextCloud-backup from a Public-Cloud Server to an on-prem instance at a client. Backup Size about 300 GB. The transfer initiates just fine but after a while just seems to get "stuck" at "64M@0MBps" Download speed for hours even though I can test that the connection exists and even run some small load-tests to check that transfer is possible.

Is there some way to restart the import in append mode? After all it tried to import via rsync form a Backup. However if I restart the import it starts over again ignoring all the progress/downloads made before.

And advise here how to get the situation un-stuck?

At this point I'd even be ok with manually rsync-ing the contents of the App to the new system and then just rebuilding the App there from scratch.

@robi I have. In one of the latest update the reference to the support@ email must have been removed an now advise is to check the FAQ or go to this forum:

Hi support-team,

I wanted to login to my cloudron.io account but my credentials especially the 2FA-TOTP (which are saved in my Bitwarden-Instance and have not changed for ages) are not accepted.

I want to extend a subscription but currently cant login. Please reach out to me so we can resolve this issue

Best regards,
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

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 answered you in direct chat. If we have results that are of public interest, we can publish it here afterwards

@girish when trying to use Roundcube (Email), it states that "Verbindung zum Speicherserver fehlgeschlagen" (Connection to storage server failed). Also when I try to go to Cloudron-Web-UI > Settings > Email, I always get a re-direct to the /#/apps path.

I disabled the /etc/unbound/unbound.conf.d/cloudron-local.conf file but same result.

Any advise where to debug this?

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

@nebulon ok, this seems to be a NAT Reflection aka hairpinning issue. When trying to run the curl -v https://[MY-DOMAIN-AND-SUBDOMAIN]/.well-known/openid-configuration inside the BookStack Container, I can see that it tries to reach out to the public IPv4.

Apparently this can be fixed by either configuring NAT Reflection or Split DNS but I wonder if we could fix it by adding a loobkack entry in /etc/resolve.con or /etc/hosts that points to the IP or Cloudron-Host directly to also make this work in private-network setups without "additional networking acrobatics" . Apparently these are mounted as read-only on the container. Can you advise on where to edit this?

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

@scooke yes but everything else workes fine and I really like operating a self-hosted email-server. Also I noticed that once I manually click the "Re-Sync Email-DNS" button, Emails start to stream in again... So even putting this on a cron-job to be done each hour would be a workable solution for me in order to keep my setup

@necrevistonnezr the reboot is not necessary due to an IP change. Sometimes the ISP just gets "stuck" with low bandwith and almost no connectivity... Only thing that seems to help is either rebooting the Router or using its "Re-Connect" feature:

In germany the ISP Vodafone is know for a rather variable service quality. But in my area they are the only provider serving via fiber-optic cable with 50 Mbps Up-Link which I want to have for runningn my services.

Hi @nebulon yes, the dyn-dns feature is active does this also contain the re-sync of the Email DNS config?

Dear Cloudron-Team,

I am operating my Cloudron instance on own hardware in a home-lab setup. Occasionally my ISPs connection "gets bad" and I need to re-connect the router. Theoretically I should have a static IPv4 but I was notified that my Email-Server was unreachable (and that is very troublesome to me!) especially after I had to do such a reboot.

I figured out that if I go to the Email-Settings and perform the re-configure DNS Settings

then go to the Domain&Certificate Section and do a re-sync of DNS Settings, I am reachable again

Now I automated the connection speed monitoring and can trigger a reboot of the router automatically through a Webhook and would like to know if there is a way to also trigger those two functions somehow though an API?

Would be great to hear from you

Thanks,
Jan

I did not finaly figure out what it was but was able to revert back to a backup-state that worked.
Ended up just creating a new Grafana App and manually transfered all settings. Not it appears to be working fine.
So probably I screwed up somewhere but it does not seem to be a bigger Application issue.

@nebulon I re-created the local admin-user and set it to disabled. Re-ran the upgrade to version v1.17 and the first login afterwards worked. However for some reason the login started failing only some time after the update, so I'll check it over the next days.

Thanks for the ad-hoc debugging! I deactivated remote SSH access again.

Update:

After checking the User-Management, the Permission system appears to have changed because I get notifications of insufficient rights:

Also my Organisations seem to be gone or at the least I lack the rights to view them.

@girish as a fist measure, I changed the password for admin/admin, later I gave Server-Admin Priviledges to my primary LDAP profile and deleted the admin-user as I viewed it only as a potential security-risk. Is there a need to keep this local user around?
Also I activated Support-Access inkl. SSH access, should you want to dig around some more.

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.

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