Cloudron Forum

@rnphil said in Issue with Default CRON Configuration for FreeScout App:

After removing our CRON command to run the schedule

Cloudron packages always configure the required cron in the package itself. So, if you find something like this, usually it's a package bug . The cron section of the app is meant for your own custom cron jobs (and not for things which the app needs).

@timconsidine said in Docker Error 500 - Unable to pull image on same instance:

box:docker pullImage: will pull docker.domain.uk/cloudron-ocular:v1. auth: no

Is that auth: no significant ?

2FA note aside, this still seems wrong. It should say auth: yes. The docker.domain.uk (from docker.domain.uk/cloudron-ocular:v1) must match the server address you put in Private Docker Registry UI.

@timconsidine your setup seems correct. The 2FA aspect is indeed interesting! Maybe you put password into Private Docker Registry before you enabled 2FA? After you enabled 2FA, just the password is not enough to authenticate. So, you have to generate an App Password from your profile and use that in the Private Docker Registry settings.

@jdaviescoates the plugin doesn't support setting the button name unfortunately. we have to raise issues for these upstream. For example, in the OIDC settings dialog which you posted earlier, you can see that the name comes from the provider type and there is no explicit label configuration. If you open a bug report upstream, please link here.

@rnphil We use FreeScout for our email support and it seems to work fine. Can you tell us what is the issue you are facing? Is FreeScout not fetching mails?

Now about the technical stuff... AFAICT, the configuration is correct:

• There is a supervisor process running in background. https://git.cloudron.io/packages/freescout-app/-/blob/master/supervisor/artisan-queue.conf?ref_type=heads . This runs php artisan schedule:run and is the background queue . You can see this with supervisorctl status in web terminal of FreeScout.

• The cron job runs with php artisan schedule:run --no-interaction .

@jdaviescoates there is a checkbox in the UI to enable it . I forget the exact text but it's inside the OIDC app settings.

@firmansi said in Nextcloud OIDC integration:

@girish I have updated to the latest version and nothing appears in env | grep CLOUDRON_OIDC

So, I think you have installed nextcloud without Cloudron user management to start with. In that case, this change won't affect you at all. Just to double check: If you go into the app configuration -> Access Control, I guess you see Dashboard Visibility instead of User Management, correct?

@humptydumpty Custom app should be easy to build just using the API (which is now motsly documented by now) - https://docs.cloudron.io/api.html . I think the ldap itself is not interesting , but having a single set of users using all cloudron is quite nice for users (who probably don't know much about cloudron).

@jdaviescoates I have published a new package with groups disabled. Can you please check?

@avatar1024 OIDC Group Sync has to be configured by the package installer just like LDAP Group Sync. Cloudron only exposes groups but does not provision the app (it's not possible for Cloudron to know what group should be what).

@firmansi we can't support both LDAP and OIDC in the long run. But on platform level, we already decided to switch to OIDC for all apps. This is more secure and auditable. I think you can probably wait for the upgrade anyway till all the issues are ironed out. Most of the apps that support OIDC have already been switched to OIDC from LDAP.

@jdaviescoates thanks for the detailed investigation! Right, this is a bug that the package is enabling OIDC groups. New package coming with it disabled.

@firmansi OIDC should be automatically automatic configured. Can you restart the app and check the logs? In the log you should see ==> Disabling LDAP and then ==> Ensure OIDC settings . Do you see these messages?

Can you also open a web terminal and run env | grep CLOUDRON_OIDC ? Do you see a bunch of variables?

Well, I am confused. For me, it works out of the box. See this comment from @nebulon - https://forum.cloudron.io/post/55637

• GNUPGHOME is already to /app/data/gnupg
• Just put your keys in above directory
• curl https://gitea.domain.com/api/v1/signing-key.gpg works
• Create empty repo.

@jaschaezra said in Need help to enable autosign:

Update: Gitea does not get the signing key

Did a quick test. Setting GNUPGHOME env var makes it work. You can use CLI tool for this cloudron env set GPGHOME=/app/data/appdata/home/.gnupg . But I think we should set this in the package itself.

@firmansi are you able to login as nextcloud admin? If so, if you go to App -> OIDC , is it configured and enabled?

Also, are you using Cloudron with OIDC integration to start with? Does a fresh install of NC (for testing) have the button?

@chris I mentioned elsewhere but mulit-host was on our radar but we haven't been able to justify implementing these features as we haven't found customers who would be willing to pay $ for complex features like these. If you are in the enterprise/medium business bracket and willing to work with us here, please contact us on support@cloudron.io. Our current business users simply set up multiple instances of Cloudron with a central LDAP and it gives them multihost already.

@stoccafisso the issue is not related to Cloudron. It seems rocket.chat is filling up the logs (specifically, it seems apps inside rocket.chat are putting lots of logs). See https://forum.cloudron.io/post/100242 for the setting, it's inside rocket.chat

@andreasdueren it's picked up for me by default.

@andreasdueren hide_login_form that will prevent admins from logging in, no? social_login_auto_redirect depends on that choice, I guess. Maybe something for the docs?

We have published a new major version of the nextcloud package that migrates ldap login to oidc login. It is also marked as unstable. I recommend waiting a bit before you update away sensitive instances.

Please report any bugs/issues here.