Cloudron Forum

nj

I once added an wildcard A Record for *.mydomain that pointed to my box. It would show the message You found a Cloudron out in the wild! message whenever I tried to open a non-existent subdomain, like foobarbaz.mydomain.

Non-existent app:

File /home/yellowtent/box/dashboard/dist/splash.html
Message: You found a Cloudron out in the wild!
To test, point foobarbaz.yourdomain to the box and visit the url.

Non-responding app:

File /home/yellowtent/boxdata/custom_pages/app_not_responding.html
Message: ...app is not responding...
To test, stop the app and visit the url.

I am not sure if those files will be replaced during upgrade, but I have the following content in both of those files.

<html>
<head><title>404 Not Found</title></head>
<body>
<center><h1>404 Not Found</h1></center>
<hr><center>nginx</center>
<!-- no such app / app not working -->
</body>
</html>

It would be cool to be able to add a custom file app_not_installed.html alongside app_not_responding.html.

nj

Re: I am missing (real) SSO

I onboarded my entire team to Cloudron; signed up, mailboxes set up, 2FA enabled, and more. Then I realized that the 2FA setting enabled on Cloudron is useless for other apps. Some apps don't have a 2FA option yet; for example, Taiga, which we use to manage all the projects. Also, Bookstack, where all our internal docs go, supports 2FA.

I have understood how Cloudron works, and that this topic has already been discussed in the forum. I started looking for ways to leverage 2FA settings of Cloudron to protect access to other apps. I have thought of a possible solution.

After researching for a while I discovered a solution. Cloudron itself has an active directory server. We could have the users append/prepend the 2FA token with their password every time they log in; the Cloudron LDAP server would see if 2FA is enabled on the account, and if enabled, it will extract the password & 2FA code from the password input and perform authentication. This is pretty trivial because the Cloudron login page has an optional 2FA token field, and the token is only looked required if the user has enabled 2FA.

One of the service offerings I came across has a simple but complete description of this method of using 2FA with LDAP with a dynamic password. https://www.protectimus.com/blog/active-directory-two-factor-authentication/.

This feature is absolutely necessary for me, and I believe there are other people like me. Do you think we could pull this off?

nj

Re: Swagger Editor - define REST api

I have been using Postman with my team for developing and publishing APIs for our services, but the costs are adding up pretty quickly ($15/user/month), and still no support for SSO.

I am moving to Swagger Editor, Swagger Codegen & Swagger UI, but it would be great if I could install it inside my Cloudron instance instead of paying for another server.

I noticed that your documentation makes use of Swagger, so I am sure it would be fairly easy to add support for the same.

Please don't forget to upvote if you think it's a good idea.

nj

The comment thread on this post seems to have diverted from the original topic. I would like to comment on @marcusquinn's request for 2FA for LDAP apps. As @girish has said, we have had a long discussion about it, and the team couldn't come up with a one-size-fits-all solution. I was expecting the PASSWORD;TOTP feature in version 6 too. Here's my understanding and proposed solution:

1. Apps that have their own 2FA system, like Gogs, Gitlab, Wiki.JS, etc.
NOTE: I have used this trick in quite a few apps to save myself from having dozens of 2FA secrets. I simply replace the app's mfa_secret value with the secret from Cloudron (Hint: while setting up 2FA on your Cloudron account, select to enter code manually, and write the displayed secret in a piece of paper so you can copy it elsewhere).

Cloudron has access to the database so Cloudron could automate this process:

enabling 2FA for that user in the app by authenticating as that user.
replacing the TOTP secret in the app with the TOTP secret from the Cloudron user account.

The 2FA code from Cloudron will also work on the app, so no need to have per-app 2FA codes. But this approach has downsides:

The maintainer of this feature needs to keep things updated when the app's database schema changes!
The apps usually create a new account when the user logs in using LDAP. For the above approach to work, Cloudron should make those changes before the user's account is created on the app.

I have only done this with my own account because it's quite time consuming to replace the TOTP Secret for all users of my Cloudron instance; a script would certainly help.

2. Apps that do note have native support for 2FA
Proposed solutions:

Cloudron adds a feature to support PASSWORD;TOTP as password, and validate TOTP by extracting it from the input. For this to work, all users must be informed. I wish password managers and authenticator apps had a feature to make it easier to auto-fill 2FA codes as well...
can't think of another way, will add if I can come up with something

Enabling 2FA for all apps is an important feature for some users like me, because of compliance reasons & a bit of paranoia. I can't trust everyone to not fall for phishing attacks, so I really wish Cloudron team kept this feature in priority. For the time being, I'm enabling 2FA in per-app basis, and avoiding apps that don't have 2FA built in.

nj

After around a year of using Cloudron, I have installed many apps, and now the admin interface needs scrolling. I have a really wide screen but the layout won't adjust to fill the available space (4 cols only).

If only there was a way to fit more items on the screen it would be easier. For now, supporting upto 6 or 8 rows would do.

PS: The design of the App Store would do too.

nj

Gitlab supports adding custom gitlab.yml file (add to the Home of File Manager in the Cloudron dashboard). I am sharing a few custom configurations which I think are really important.

Adding the IP address of the reverse proxy 172.18.0.1 will show the real IP address of the client in Gitlab's logs. The IP address set using X-Forwarded-For by the reverse proxy. For that purpose production/gitlab/trusted_proxies parameter can be set.
For compliance reasons, we cannot allow users to change their username in the Gitlab instance. A setting is not available in the Admin area to prevent users from changing their usernames, but a custom flag production/gitlab/username_changing_enabled can be set.
While configuring 2FA with current default Gitlab installation in gitlab.example.com, the account name in authenticator apps will be shown as localhost:someone@gilab.example.com. To fix this, we can add the production/gitlab/host parameter. After this fix, authenticator apps will show the gitlab instance's domain name instead of localhost.
Current default Gitlab installation wills show the git-clone URL as ssh://git@localhost:port/user/repo. To fix this, we should add a custom production/gitlab/ssh_host parameter.
I would like to have my brand name set on the Branding -> Cloudron Name from my dashboard on Gitlab's LDAP log-in page instead of Cloudron. Simply changing the LDAP server's label production/ldap/servers/main/label did not work. So I simply copied the entire production/ldap configuration block.

Here is my custom gitlab.yml file, that fixes all the above issues.

production:
  <<: *base

  gitlab:
    host: gitlab.mydomain
    ssh_host: gitlab.mydomain
    trusted_proxies:
      - 172.18.0.1
      
    username_changing_enabled: false


  ldap:
    enabled: true
    prevent_ldap_sign_in: false
    servers:
      main:
        label: 'My Domain Login'
        host: '172.18.0.1'
        port: 3002
        uid: 'username'
        bind_dn: 'cn=**************************,ou=apps,dc=cloudron'
        password: '****************************'
        encryption: 'plain'
        verify_certificates: false
        ca_file: ''
        ssl_version: ''
        timeout: 10
        smartcard_auth: false
        active_directory: false
        allow_username_or_email_login: false
        block_auto_created_users: false
        base: 'ou=users,dc=cloudron'
        user_filter: ''
        group_base: ''
        admin_group: ''
        external_groups: []
        sync_ssh_keys: false
        attributes:
          username: ['username']
          email:    ['mail']
          name:       'displayname'
          first_name: 'givenName'
          last_name:  'sn'
        lowercase_usernames: false

In my opinion, Gitlab Cloudron package could add the custom file gitlab.yml to the file manager home by default, and set the the above fields in that file instead of modifying the default config file.

nj

I am starting a new topic to keep the discussion to the point. Previous discussions are linked at the bottom of this post. This is to request Cloudron to support inline TOTP code with LDAP Password in the form password;2FCODE.

;TLDR User Stories

Admin can choose to opt-in for password:2fcode feature from Settings.
During authentication, Cloudron checks for the setting, and if enabled, splits password and 2fcode.
Cloudron performs authentication based on password and the 2fa code.

The last discussion with @girish ended with him mentioning that there's some standardization going on in the field of 2FA in custom fields of LDAP. Out of curiosity, I looked at the roadmaps of many open source projects and found that very few have any plans to standardize or even support TOTP secret through LDAP fields. I have no hopes of any standardization in the near future that Cloudron can look forward to.

I am serious about security, and mandate everyone in my team to enable 2FA whenever possible. We're also using more and more new apps, and I'm seeing mandatory 2FA in individual apps a lot of trouble to go through.

I already have 13 different entries for individual apps' 2FA codes, and the list is growing. Then there are the recovery codes of all apps written on dozens of pieces of paper - The situation is the same across the team, and it's only going to be worse when we stop using apps.

Please do something about it! Pretty, please?

More discussion on this topic:
https://forum.cloudron.io/topic/3285/2fa-for-all-ldap-apps/39
https://forum.cloudron.io/topic/2433/the-real-sso-with/1
https://forum.cloudron.io/topic/1972/i-am-missing-real-sso/1

nj

I'm in for this too. I haven't packaged an app yet, but only because of lack of confidence. It would be awesome to see someone do it, and later be able to help others do the same!

nj

@girish after giving some more thoughts, I don't see a reason to go through all the apps to see if they support 2FA? This only makes stuff more complicated. Even if the app supports 2FA, the Cloudron 2FA will make it redundant; so we can skip that. If someone would like to skip Cloudron 2FA they're free to use the app's own 2FA if it supports.

There could be a choice of ["Use Cloudron 2FA / Let the app handle it"] just like the choice of user management. If the first option is selected, TOTP is checked, otherwise it is not.

nj

@fbartels The repo seems to have gone, or is it a private repo? I was looking to package Drone, and found this thread.

nj

I think I am a little too paranoid here. Once I had to recover data deleted from the Gitea instance a month before. Since then I have this backup strategy:

Frequency: 01:00 AM daily
Retention: 7 daily, 4 weekly, 12 monthly
Method: Full snapshot (not incremental)

At all times I use around 23x180GB = ~4TB space only for backup.

nj

I am starting a new topic to keep the discussion to the point. Previous discussions are linked at the bottom of this post. This is to request Cloudron to support inline TOTP code with LDAP Password in the form password;2FCODE.

;TLDR User Stories

Admin can choose to opt-in for password:2fcode feature from Settings.
During authentication, Cloudron checks for the setting, and if enabled, splits password and 2fcode.
Cloudron performs authentication based on password and the 2fa code.

The last discussion with @girish ended with him mentioning that there's some standardization going on in the field of 2FA in custom fields of LDAP. Out of curiosity, I looked at the roadmaps of many open source projects and found that very few have any plans to standardize or even support TOTP secret through LDAP fields. I have no hopes of any standardization in the near future that Cloudron can look forward to.

I am serious about security, and mandate everyone in my team to enable 2FA whenever possible. We're also using more and more new apps, and I'm seeing mandatory 2FA in individual apps a lot of trouble to go through.

I already have 13 different entries for individual apps' 2FA codes, and the list is growing. Then there are the recovery codes of all apps written on dozens of pieces of paper - The situation is the same across the team, and it's only going to be worse when we stop using apps.

Please do something about it! Pretty, please?

More discussion on this topic:
https://forum.cloudron.io/topic/3285/2fa-for-all-ldap-apps/39
https://forum.cloudron.io/topic/2433/the-real-sso-with/1
https://forum.cloudron.io/topic/1972/i-am-missing-real-sso/1

nj

I just installed Phabricator with default settings and it kept stuck at Starting... The logs had the following error messages.

...
Applying patch "phabricator:20190523.myisam.01.documentfield.sql" to host "mysql:3306"...
Jan 03 17:15:51 [2021-01-03 11:30:51] EXCEPTION: (AphrontQueryException) #1064: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '6e4076d2768e4621_search.search_documentfield' at line 1 at [<phabricator>/src/infrastructure/storage/connection/mysql/AphrontBaseMySQLDatabaseConnection.php:386]
Jan 03 17:15:51 arcanist(), phabricator()
...

nj

I have come across these problem after installing Matomo.

After first-time logging in with admin:changeme, I opened the personal settings page. I changed the default email admin@server.local to admin@mydomain. Then, I tried to change the default password, which told me that LDAP users cannot change their passwords. Maybe because admin conflicts with existing LDAP user. Problem: **I could continue to log in with admin:changme as well as with admin:MyLDAPpassworld.
The file manager runs into a problem while trying to view/edit matomo.js. The issue repeats with all all *.js files. Other files with different extention, like php.ini are good to view/edit.
This is a minor one - new version is available - 4.1.0.

nj

Today I enforced 2FA for everyone on Nextcloud; unfortunately, nobody was able to log in. Cloudron's Nextcloud package does not come with support for 2FA with TOTP, which requires a separate Nextcloud app. Cloudron developers don't recommend manually installing and updating Nextcloud apps, so I think this app should be included by default, like other apps. Please enlighten me if I'm missing something here.

Here's the app: https://apps.nextcloud.com/apps/twofactor_totp

nj

@fbartels The repo seems to have gone, or is it a private repo? I was looking to package Drone, and found this thread.

nj

I once added an wildcard A Record for *.mydomain that pointed to my box. It would show the message You found a Cloudron out in the wild! message whenever I tried to open a non-existent subdomain, like foobarbaz.mydomain.

Non-existent app:

File /home/yellowtent/box/dashboard/dist/splash.html
Message: You found a Cloudron out in the wild!
To test, point foobarbaz.yourdomain to the box and visit the url.

Non-responding app:

File /home/yellowtent/boxdata/custom_pages/app_not_responding.html
Message: ...app is not responding...
To test, stop the app and visit the url.

I am not sure if those files will be replaced during upgrade, but I have the following content in both of those files.

<html>
<head><title>404 Not Found</title></head>
<body>
<center><h1>404 Not Found</h1></center>
<hr><center>nginx</center>
<!-- no such app / app not working -->
</body>
</html>

It would be cool to be able to add a custom file app_not_installed.html alongside app_not_responding.html.

nj

I removed the custom gitlab.yml file and restarted Gitlab. Like you said, the clone URL as well as the authenticator app correctly show the url.

I had to add the custom config to set other flags; in that case you must also add host and ssh_host options, otherwise the host name in clone URL and authenticator app will default to localhost (above issues 3, 4).

nj

Gitlab supports adding custom gitlab.yml file (add to the Home of File Manager in the Cloudron dashboard). I am sharing a few custom configurations which I think are really important.

Adding the IP address of the reverse proxy 172.18.0.1 will show the real IP address of the client in Gitlab's logs. The IP address set using X-Forwarded-For by the reverse proxy. For that purpose production/gitlab/trusted_proxies parameter can be set.
For compliance reasons, we cannot allow users to change their username in the Gitlab instance. A setting is not available in the Admin area to prevent users from changing their usernames, but a custom flag production/gitlab/username_changing_enabled can be set.
While configuring 2FA with current default Gitlab installation in gitlab.example.com, the account name in authenticator apps will be shown as localhost:someone@gilab.example.com. To fix this, we can add the production/gitlab/host parameter. After this fix, authenticator apps will show the gitlab instance's domain name instead of localhost.
Current default Gitlab installation wills show the git-clone URL as ssh://git@localhost:port/user/repo. To fix this, we should add a custom production/gitlab/ssh_host parameter.
I would like to have my brand name set on the Branding -> Cloudron Name from my dashboard on Gitlab's LDAP log-in page instead of Cloudron. Simply changing the LDAP server's label production/ldap/servers/main/label did not work. So I simply copied the entire production/ldap configuration block.

Here is my custom gitlab.yml file, that fixes all the above issues.

production:
  <<: *base

  gitlab:
    host: gitlab.mydomain
    ssh_host: gitlab.mydomain
    trusted_proxies:
      - 172.18.0.1
      
    username_changing_enabled: false


  ldap:
    enabled: true
    prevent_ldap_sign_in: false
    servers:
      main:
        label: 'My Domain Login'
        host: '172.18.0.1'
        port: 3002
        uid: 'username'
        bind_dn: 'cn=**************************,ou=apps,dc=cloudron'
        password: '****************************'
        encryption: 'plain'
        verify_certificates: false
        ca_file: ''
        ssl_version: ''
        timeout: 10
        smartcard_auth: false
        active_directory: false
        allow_username_or_email_login: false
        block_auto_created_users: false
        base: 'ou=users,dc=cloudron'
        user_filter: ''
        group_base: ''
        admin_group: ''
        external_groups: []
        sync_ssh_keys: false
        attributes:
          username: ['username']
          email:    ['mail']
          name:       'displayname'
          first_name: 'givenName'
          last_name:  'sn'
        lowercase_usernames: false

In my opinion, Gitlab Cloudron package could add the custom file gitlab.yml to the file manager home by default, and set the the above fields in that file instead of modifying the default config file.

nj

I could not fork the repo to make changes so sent a Pull Request instead.

Cloudron makes it easy to run web apps like WordPress, Nextcloud, GitLab on your server. Find out more or install now.

nj

@nj

Best posts made by nj

Latest posts made by nj