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


Navigation

    Cloudron Forum

    • Register
    • Login
    • Search
    • Categories
    • Recent
    • Tags
    • Popular

    Add custom gitlab.yml support

    GitLab
    3
    6
    73
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • N
      nj last edited by 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.

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

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

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

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

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

      girish 1 Reply Last reply Reply Quote 3
      • marcusquinn
        marcusquinn last edited by

        Nice, agreed 👍

        1 Reply Last reply Reply Quote 0
        • girish
          girish Staff @nj last edited by

          @nj Excellent suggestions, thanks. I have fixed 1 and 2.

          I think 3,4 already work out of the box but the reason it doesn't work is because of the way yml inheritance works. If you merge two yml files, they if you have two same sections, then the second section ends up overriding everything. What I mean is:

          foo:
             bar: 10
             baz: 5
          
          ... later ...
          
          foo:
              baz: 10
          

          With the above in a yml, I think foo.bar is not 10 as one would expect (and thus you are getting these localhost defaults). Just my hunch, let me verify this though. This is the reason why you had to copy/paste the entire block for fixing 5.

          N 1 Reply Last reply Reply Quote 0
          • girish
            girish Staff last edited by

            Right, the yaml inheritance does not work from the second level (like in gitlab's yml).

            foo: &base
                x:
                    bar: 34
                    baz: 22
            
            foo2:
                <<: *base
                x:
                    bar: 45
            
            1 Reply Last reply Reply Quote 0
            • N
              nj @girish last edited by 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).

              girish 1 Reply Last reply Reply Quote 0
              • girish
                girish Staff @nj last edited by

                @nj This whole inheritance thing is not ideal 😕 I don't like it that you have to copy/paste this whole ldap block. I will rework the package to have the whole gitlab.yml editable via the file manager. That seems more sustainable and puts the onus on us (the packagers) instead of the user (you) to figure out all this yaml complexity.

                1 Reply Last reply Reply Quote 1
                • First post
                  Last post