Hi !

Thanks for your awesome module ! It works really nice and my only problem is how to manage Gitlab upgrade proccess ? Right now I have version 8.12.6 on my server. Version 8.13 is released and I want to upgrade my installation.

Any chance that i can do it with help of this module or should i do it manually ?

Hi,

On Debian Wheezy (7) after installing the error on each puppet run:

Error: Execution of '/usr/sbin/update-rc.d gitlab-runsvdir defaults' returned 1: update-rc.d: error: unable to read /etc/init.d/gitlab-runsvdir

I have tried purging the package and running from scratch with the same result. The file /etc/init.d/gitlab-runsvdir does not exist.

Hiera data:

gitlab::external_url: 'http://gitlab.XXXX'
gitlab::gitlab_rails:
time_zone: 'UTC'
gitlab_email_enabled: false
gitlab_default_theme: 4
gitlab_email_display_name: 'Gitlab'
gitlab_email_from: 'github@XXXX'
gitlab::sidekiq:
shutdown_timeout: 5

Class call:

class { '::gitlab':
external_url => 'http://gitlab.XXXX',
}

Please let me know if you need any more info.

Thanks

You seem to have two parameters, rails and gitlab_rails. I expected to use gitlab_rails, but looking at the template it uses rails. This is confusing. I expect rails should be deprecated in favour of gitlab_rails.

Not an error but just wanted to make note:

==> gitlab: Notice: /Stage[main]/Gitlab::Config/Exec[gitlab_reconfigure]/returns: /sbin/init: unrecognized option '--version'
==> gitlab: Notice: /Stage[main]/Gitlab::Config/Exec[gitlab_reconfigure]/returns: -.mount                                                                                   loaded active mounted   /
==> gitlab: Notice: /Stage[main]/Gitlab::Config/Exec[gitlab_reconfigure]/returns: gitlab Reconfigured!
==> gitlab: Notice: /Stage[main]/Gitlab::Config/Exec[gitlab_reconfigure]: Triggered 'refresh' from 1 events

The format of the LDAP parameters in gitlab.rb which are generated by Puppet using this module are incorrect.

Correct format as shown in the docu and the example gitlab.rb file :
( The following example is of the puppetrun deleting the right format within the original gitlab.rb: )
-# gitlab_rails['ldap_servers'] = YAML.load <<-'EOS' # remember to close this block with 'EOS' below
-# main: # 'main' is the GitLab 'provider ID' of this LDAP server
-# label: 'LDAP'
-# host: '_your_ldap_server'
-# port: 389
-# uid: 'sAMAccountName'
-# method: 'plain' # "tls" or "ssl" or "plain"
-# bind_dn: '_the_full_dn_of_the_user_you_will_bind_with'
-# password: '_the_password_of_the_bind_user'
-# active_directory: true
-# allow_username_or_email_login: false
-# block_auto_created_users: false
-# base: ''
-# user_filter: ''
-# attributes:
-# username: ['uid', 'userid', 'sAMAccountName']
-# email: ['mail', 'email', 'userPrincipalName']
-# name: 'cn'
-# first_name: 'givenName'
-# last_name: 'sn'
-# ## EE only
-# group_base: ''
-# admin_group: ''
-# sync_ssh_keys: false
-#
-# secondary: # 'secondary' is the GitLab 'provider ID' of second LDAP server
-# label: 'LDAP'
-# host: '_your_ldap_server'
-# port: 389
-# uid: 'sAMAccountName'
-# method: 'plain' # "tls" or "ssl" or "plain"
-# bind_dn: '_the_full_dn_of_the_user_you_will_bind_with'
-# password: '_the_password_of_the_bind_user'
-# active_directory: true
-# allow_username_or_email_login: false
-# block_auto_created_users: false
-# base: ''
-# user_filter: ''
-# attributes:
-# username: ['uid', 'userid', 'sAMAccountName']
-# email: ['mail', 'email', 'userPrincipalName']
-# name: 'cn'
-# first_name: 'givenName'
-# last_name: 'sn'
-# ## EE only
-# group_base: ''
-# admin_group: ''
-# sync_ssh_keys: false
-# EOS

Wrong format as stored in gitlab.rb after the puppetrun:
+gitlab_rails['ldap_servers'] = {"active_directory"=>true, "base"=>"DC=com", "bind_dn"=>"", "host"=>"ldap.com", "label"=>"LDAP", "method"=>"plain", "password"=>"Ikwilkaas1", "port"=>389, "user_filter"=>"OU=Amsterdam,DC=com"}

Puppet should store the configuration as the

$var = YAML.load <<-'EOS'
...
 var: arg
...
EOS

Error: Could not enable gitlab-runsvdir: Execution of '/sbin/chkconfig --add gitlab-runsvdir' returned 1: service gitlab-runsvdir does not support chkconfig
Error: /Stage[main]/Gitlab::Service/Service[gitlab-runsvdir]/enable: change from false to true failed: Could not enable gitlab-runsvdir: Execution of '/sbin/chkconfig --add gitlab-runsvdir' returned 1: service gitlab-runsvdir does not support chkconfig

It seems that this is enabled by default on CentOS 6, is this correct?

Until now I was using the deprecated spruder gitlab module ... and configuring ldap was rather simple there. can someone give me an example how to configure ldap for gitlap in the vshn module ?
thanks in advance

Although Amazon Linux is based on RHEL, they're using different release naming schema than RHEL and therefor this module seems incompatible for Amazon AMI.

I think, OS selection case should be modified as includes Amazon Linux $::operatingsystemmajrelease value.

Here is an example facter output from an Amazon AMI:

operatingsystem => Amazon
operatingsystemmajrelease => 2015
operatingsystemrelease => 2015.09

Sample dump at http://pastebin.com/v3J98Az2

Basically, the http secret, cert and internal key, plus all the mattermost salts and keys, all get removed with every puppet run and immediately new ones are generated and added by the reconfigure, which was triggered by the fact the file was edited. this seems to me like a serious bug, the entire omnibus should not need to rerun and restart on every run.
Also, does that mean mattermost is getting installed? should I be able to access it? it's not linked in the gitlab UI and I don't see any service that looks like it's related getting started.

On at least Red Hat Enterprise Linux Server release 6.7 (Santiago): The baseurl in /etc/yum.repos.d/gitlab_official.repo exands to:
https://packages.gitlab.com/gitlab/gitlab-ce/el/6Server/x86_64/repodata/repomd.xml - which is incorrect.
It should expand to:
https://packages.gitlab.com/gitlab/gitlab-ce/el/6/x86_64/repodata/repomd.xml

Tested on v1.7.0

I didn't change the version number in the metadata.json, which means that the new additions from #76 will not propagate (especially when my local metadata.json says "version": "1.8.0-1" :)

since this is a private gitlab on a publicly hosted machine (out on AWS) I want SSL out of the box, so I thought I'd go with a module that will use Let's Encrypt to create my certificates. however there's a chicken and egg here - nginx won't run till I create the certs and the certs can't be created without a working webserver (that will also serve files from the disk), so unless I'm missing something...?

in order to automate this, I'd have to patch this module and make a PR. I'll happily do it on a less busy week. for now I'd love it if there's a shortcut solution that I'm missing (or I'll just manually bootstrap the first cert and fix this in June)

Thanks in advance!

Currently the default setting for concurrent is 4 for gitlab-runner.

There doesn't see to be a way from within the module to set it.

Because there's no template to manage, not sure of the best way to send a PR.

Thoughts?

Add manifests to install and configure Gitlab CI multi runner: https://gitlab.com/gitlab-org/gitlab-ci-multi-runner

After integrating CI into Gitlab there are maybe some deprecated config parameters in gitlab.rb -> clean this up

Got my gitlab on /, and I want it on a diffrerent partition, say /data. going over the code I don't see a way to pass that parameter to the omnibus. I'd move and symlink it, but gitlab would not run on a path with any part of the path being a symlink.

On that matter, can I get the entire /var/opt/gitlab move into /opt/gitlab/githome or any random path as needed?

Hi there,

I was just wondering if this module is able to configure gitlab such that it uses SMTP for a mail server rather than postfix?

I can't see where gitlab_rails is pulling values from, I just want to be able to implement the instructions here: https://gitlab.com/gitlab-org/omnibus-gitlab/blob/master/doc/settings/smtp.md

I've tried passing the following as a gitlab_rails entry as per the readme:

{
    'smtp_enable' => true,
    'smtp_address' => 'mail.example.internal',
    'smtp_port' => 25,
    'smtp_domain' => example.net,
    'gitlab_email_from' => '[email protected]',
    'gitlab_email_reply_to' => '[email protected]',
  },

But puppet returns that it's a string and not a hash. I don't understand why it has said that as this is the same as

{
    'webhook_timeout' => 10,
    'gitlab_default_theme' => 2,
  },

which is in the readme.

Have I missed something?

Cheers

Alex

Could not find option how to add "registry_external_url" to gitlab.rb config.

  class { 'gitlab':
    external_url => "https://git-ig.cz.avg.com",
    registry_external_url => "https://git-ig.cz.avg.com:4567",
...
  }

with Hiera

• ignored:

gitlab:
  registry_external_url: "https://git-ig.cz.avg.com:4567"

This affect rails hash, but of course is not valid for gitlab setup

gitlab::gitlab_rails:
  webhook_timeout: 10
  gitlab_default_theme: 2
  registry_external_url: "https://git-ig.cz.avg.com:4567"
 ...

creates:

gitlab_rails['registry_external_url'] = 'https://git-ig.cz.avg.com:4567'

Expected result:

• /etc/gitlab/gitlab.rb

external_url 'https://git-ig.cz.avg.com'
registry_external_url "https://git-ig.cz.avg.com:4567"

############################
# gitlab.yml configuration #
############################

gitlab_rails['gitlab_default_theme'] = 2
...

Config

• 1.8.0 puppet module version
• centos 7, latest Gitlab CE

Tried to use common.yaml to put the gitlab::gitlab_rails ldap settings as described and they didn't work.
Not one value was populated into gitlab.rb

Is this still working as documented in README?

---
gitlab::gitlab_rails:
  ldap_enabled: true
  ldap_servers:
    myldapserver:
      label: 'Company LDAP'
      host: 'ldap.company.tld'
      port: 389
      uid: 'uid'
      method: 'plain' # "tls" or "ssl" or "plain"
      bind_dn: 'MYBINDDN'
      password: 'MYBINDPW'
      active_directory: false
      allow_username_or_email_login: false
      block_auto_created_users: false
      base: 'MYBASEDN'
      group_base: 'MYGROUPBASE'
      user_filter: ''

Also can you provide detail of how to use the puppet config where hiera doesn't work to load the ldap configuration?

After adding an ldap_server to my gitlab hiera config every couple puppet run will trigger a reconfig. Looking into it the puppet output is shwoing a change in the gitlab.rb file. But the diff only shows a difference in the way the ldap_server hash is written to the file.

--- /etc/gitlab/gitlab.rb   2016-01-06 16:11:16.191974903 -0800
+++ /tmp/puppet-file20160106-23945-3txlqb   2016-01-06 16:20:42.223501596 -0800
@@ -21,7 +21,7 @@
 gitlab_rails['gitlab_email_display_name'] = ' Gitlab'
 gitlab_rails['gitlab_email_enabled'] = true
 gitlab_rails['ldap_enabled'] = true
-gitlab_rails['ldap_servers'] = {"myldapserver"=>{"host"=>"ldap.", "block_auto_created_users"=>false, "uid"=>"sAMAccountName", "active_directory"=>true, "label"=>"LDAP", "password"=>"", "bind_dn"=>"cn=", "base"=>"dc=", "allow_username_or_email_login"=>false, "method"=>"plain", "port"=>389}}
+gitlab_rails['ldap_servers'] = {"myldapserver"=>{"password"=>"", "block_auto_created_users"=>false, "uid"=>"sAMAccountName", "bind_dn"=>"cn=", "base"=>"dc=", "method"=>"plain", "allow_username_or_email_login"=>false, "port"=>389, "label"=>"LDAP", "host"=>"ldap.", "active_directory"=>true}}
 gitlab_rails['time_zone'] = 'america/los_angeles'

*removed content, but you can see the keys are in a different order.

Gitlab has progressed a lot in the last months. The file templates/gitlab.rb.erb needs to be revised and aligned to the template found in Omnibus.

I believe the issue is how this is being read in vs actually merging the data because hiera works fine.

Hi,
Using vshn/gitlab v1.5.0 on CentOS 7 with gitlab-ce 7.14.1 omnibus package it seems that the gitlab-runsvdir systemd service is not running, and /usr/bin/gitlab-ctl seems not able to start the gitlab services without having it running. As gitlab-runsvdir systemd service is not enabled gitlab also does not start automatically on boot.

root@sources ~ # /usr/bin/gitlab-ctl status
fail: ci-redis: runsv not running
fail: ci-sidekiq: runsv not running
fail: ci-unicorn: runsv not running
fail: logrotate: runsv not running
fail: nginx: runsv not running
fail: postgresql: runsv not running
fail: redis: runsv not running
fail: sidekiq: runsv not running
fail: unicorn: runsv not running
root@sources ~ # /usr/bin/gitlab-ctl start
fail: ci-redis: runsv not running
fail: ci-sidekiq: runsv not running
fail: ci-unicorn: runsv not running
fail: logrotate: runsv not running
fail: nginx: runsv not running
fail: postgresql: runsv not running
fail: redis: runsv not running
fail: sidekiq: runsv not running
fail: unicorn: runsv not running
root@sources ~ # systemctl status gitlab-runsvdir.service                                                                                                      
gitlab-runsvdir.service - GitLab Runit supervision process
   Loaded: loaded (/usr/lib/systemd/system/gitlab-runsvdir.service; disabled)
   Active: inactive (dead)

root@sources ~ # systemctl enable gitlab-runsvdir.service                                                                                                      
ln -s '/usr/lib/systemd/system/gitlab-runsvdir.service' '/etc/systemd/system/basic.target.wants/gitlab-runsvdir.service'
root@sources ~ # /usr/bin/gitlab-ctl start                                                                                                                     
fail: ci-redis: runsv not running
fail: ci-sidekiq: runsv not running
fail: ci-unicorn: runsv not running
fail: logrotate: runsv not running
fail: nginx: runsv not running
fail: postgresql: runsv not running
fail: redis: runsv not running
fail: sidekiq: runsv not running
fail: unicorn: runsv not running
root@sources ~ # systemctl start gitlab-runsvdir.service                                                                                                       
root@sources ~ # /usr/bin/gitlab-ctl status                                                                                                                    
run: ci-redis: (pid 1533) 4s; run: log: (pid 1530) 4s
run: ci-sidekiq: (pid 1537) 4s; run: log: (pid 1534) 4s
run: ci-unicorn: (pid 1547) 4s; run: log: (pid 1541) 4s
run: logrotate: (pid 1544) 4s; run: log: (pid 1539) 4s
run: nginx: (pid 1536) 4s; run: log: (pid 1532) 4s
run: postgresql: (pid 1545) 4s; run: log: (pid 1542) 4s
run: redis: (pid 1535) 4s; run: log: (pid 1531) 4s
run: sidekiq: (pid 1540) 4s; run: log: (pid 1538) 4s
run: unicorn: (pid 1546) 4s; run: log: (pid 1543) 4s

It looks like that the service is explicitely disabled in manifest/params.pp and is using custom start/stop commands directly calling /usr/bin/gitlab-ctl that seems not to be working without the systemd service, is this the expected result am I the only having a problem with this configuration?

Enabling and starting the service manually does fix the problems, gitlab-ctl will be able to restart the services and gitlab will run on boot as expected.

Best,
Baptiste

Some strange issues with Puppet 4.5.3 and Rspec-Puppet:

Failures:

  1) gitlab supported operating systems gitlab class without any parameters on Debian (Jessie) should contain Class[gitlab::install] that comes before gitlab::config

     Failure/Error: it { is_expected.to contain_class('gitlab::install').that_comes_before('gitlab::config') }



     ArgumentError:

       No title provided and "gitlab::config" is not a valid resource reference

     # /home/travis/.rvm/gems/ruby-2.3.0/gems/puppet-4.5.3/lib/puppet/resource.rb:544:in `extract_type_and_title'

     # /home/travis/.rvm/gems/ruby-2.3.0/gems/puppet-4.5.3/lib/puppet/resource.rb:529:in `type_and_title'

     # /home/travis/.rvm/gems/ruby-2.3.0/gems/puppet-4.5.3/lib/puppet/resource/catalog.rb:353:in `resource'

     # /home/travis/.rvm/gems/ruby-2.3.0/bundler/gems/rspec-puppet-79d5373dcbfa/lib/rspec-puppet/matchers/create_generic.rb:204:in `block in check_befores'

     # /home/travis/.rvm/gems/ruby-2.3.0/bundler/gems/rspec-puppet-79d5373dcbfa/lib/rspec-puppet/matchers/create_generic.rb:203:in `each'

     # /home/travis/.rvm/gems/ruby-2.3.0/bundler/gems/rspec-puppet-79d5373dcbfa/lib/rspec-puppet/matchers/create_generic.rb:203:in `check_befores'

     # /home/travis/.rvm/gems/ruby-2.3.0/bundler/gems/rspec-puppet-79d5373dcbfa/lib/rspec-puppet/matchers/create_generic.rb:99:in `matches?'

     # ./spec/classes/init_spec.rb:17:in `block (4 levels) in <top (required)>'

  2) gitlab supported operating systems gitlab class without any parameters on Debian (Jessie) should contain Class[gitlab::service] that subscribes to gitlab::config

     Failure/Error: it { is_expected.to contain_class('gitlab::service').that_subscribes_to('gitlab::config') }



     ArgumentError:

       No title provided and "gitlab::config" is not a valid resource reference

     # /home/travis/.rvm/gems/ruby-2.3.0/gems/puppet-4.5.3/lib/puppet/resource.rb:544:in `extract_type_and_title'

     # /home/travis/.rvm/gems/ruby-2.3.0/gems/puppet-4.5.3/lib/puppet/resource.rb:529:in `type_and_title'

     # /home/travis/.rvm/gems/ruby-2.3.0/gems/puppet-4.5.3/lib/puppet/resource/catalog.rb:353:in `resource'

     # /home/travis/.rvm/gems/ruby-2.3.0/bundler/gems/rspec-puppet-79d5373dcbfa/lib/rspec-puppet/matchers/create_generic.rb:228:in `block in check_subscribes'

     # /home/travis/.rvm/gems/ruby-2.3.0/bundler/gems/rspec-puppet-79d5373dcbfa/lib/rspec-puppet/matchers/create_generic.rb:227:in `each'

     # /home/travis/.rvm/gems/ruby-2.3.0/bundler/gems/rspec-puppet-79d5373dcbfa/lib/rspec-puppet/matchers/create_generic.rb:227:in `check_subscribes'

     # /home/travis/.rvm/gems/ruby-2.3.0/bundler/gems/rspec-puppet-79d5373dcbfa/lib/rspec-puppet/matchers/create_generic.rb:102:in `matches?'

     # ./spec/classes/init_spec.rb:19:in `block (4 levels) in <top (required)>'

  3) gitlab supported operating systems gitlab class without any parameters on RedHat (CentOS) should contain Class[gitlab::install] that comes before gitlab::config

     Failure/Error: it { is_expected.to contain_class('gitlab::install').that_comes_before('gitlab::config') }



     ArgumentError:

       No title provided and "gitlab::config" is not a valid resource reference

     # /home/travis/.rvm/gems/ruby-2.3.0/gems/puppet-4.5.3/lib/puppet/resource.rb:544:in `extract_type_and_title'

     # /home/travis/.rvm/gems/ruby-2.3.0/gems/puppet-4.5.3/lib/puppet/resource.rb:529:in `type_and_title'

     # /home/travis/.rvm/gems/ruby-2.3.0/gems/puppet-4.5.3/lib/puppet/resource/catalog.rb:353:in `resource'

     # /home/travis/.rvm/gems/ruby-2.3.0/bundler/gems/rspec-puppet-79d5373dcbfa/lib/rspec-puppet/matchers/create_generic.rb:204:in `block in check_befores'

     # /home/travis/.rvm/gems/ruby-2.3.0/bundler/gems/rspec-puppet-79d5373dcbfa/lib/rspec-puppet/matchers/create_generic.rb:203:in `each'

     # /home/travis/.rvm/gems/ruby-2.3.0/bundler/gems/rspec-puppet-79d5373dcbfa/lib/rspec-puppet/matchers/create_generic.rb:203:in `check_befores'

     # /home/travis/.rvm/gems/ruby-2.3.0/bundler/gems/rspec-puppet-79d5373dcbfa/lib/rspec-puppet/matchers/create_generic.rb:99:in `matches?'

     # ./spec/classes/init_spec.rb:53:in `block (4 levels) in <top (required)>'

  4) gitlab supported operating systems gitlab class without any parameters on RedHat (CentOS) should contain Class[gitlab::service] that subscribes to gitlab::config

     Failure/Error: it { is_expected.to contain_class('gitlab::service').that_subscribes_to('gitlab::config') }



     ArgumentError:

       No title provided and "gitlab::config" is not a valid resource reference

     # /home/travis/.rvm/gems/ruby-2.3.0/gems/puppet-4.5.3/lib/puppet/resource.rb:544:in `extract_type_and_title'

     # /home/travis/.rvm/gems/ruby-2.3.0/gems/puppet-4.5.3/lib/puppet/resource.rb:529:in `type_and_title'

     # /home/travis/.rvm/gems/ruby-2.3.0/gems/puppet-4.5.3/lib/puppet/resource/catalog.rb:353:in `resource'

     # /home/travis/.rvm/gems/ruby-2.3.0/bundler/gems/rspec-puppet-79d5373dcbfa/lib/rspec-puppet/matchers/create_generic.rb:228:in `block in check_subscribes'

     # /home/travis/.rvm/gems/ruby-2.3.0/bundler/gems/rspec-puppet-79d5373dcbfa/lib/rspec-puppet/matchers/create_generic.rb:227:in `each'

     # /home/travis/.rvm/gems/ruby-2.3.0/bundler/gems/rspec-puppet-79d5373dcbfa/lib/rspec-puppet/matchers/create_generic.rb:227:in `check_subscribes'

     # /home/travis/.rvm/gems/ruby-2.3.0/bundler/gems/rspec-puppet-79d5373dcbfa/lib/rspec-puppet/matchers/create_generic.rb:102:in `matches?'

     # ./spec/classes/init_spec.rb:55:in `block (4 levels) in <top (required)>'

Finished in 16.74 seconds (files took 1 second to load)

44 examples, 4 failures

Failed examples:

rspec ./spec/classes/init_spec.rb:17 # gitlab supported operating systems gitlab class without any parameters on Debian (Jessie) should contain Class[gitlab::install] that comes before gitlab::config

rspec ./spec/classes/init_spec.rb:19 # gitlab supported operating systems gitlab class without any parameters on Debian (Jessie) should contain Class[gitlab::service] that subscribes to gitlab::config

rspec ./spec/classes/init_spec.rb:53 # gitlab supported operating systems gitlab class without any parameters on RedHat (CentOS) should contain Class[gitlab::install] that comes before gitlab::config

rspec ./spec/classes/init_spec.rb:55 # gitlab supported operating systems gitlab class without any parameters on RedHat (CentOS) should contain Class[gitlab::service] that subscribes to gitlab::config

Add support for the new feature: Docker registry. See http://docs.gitlab.com/ce/administration/container_registry.html#container-registry-domain-configuration

I'm having some issues with this module on RHEL (not CentOS, real RHEL).

This module defines the repo baseurl as https://packages.gitlab.com/gitlab/gitlab-ce/el/$releasever/$basearch

However, on real RHEL, that evaluates as https://packages.gitlab.com/gitlab/gitlab-ce/el/7Server/x86_64/, however https://packages.gitlab.com/gitlab/gitlab-ce/el/7Server/x86_64/repodata/repomd.xml is 404.

It seems to me that when calculating the repository URL on RedHat-based systems, the module should probably just use the OS major release in Puppet, instead of relying on $releasever in yum.

I'm looking for more information on how to configure the embedded NGINX instance that comes with the GitLab Omnibus package. I can see that there's an option for providing a hash of configuration options, but I can't find anything on what options are supported and the exact data structure for the hash. My most immediate interest is configuring HTTPS.

Thanks!

@tobru I'm the author of the spuder/puppet-gitlab puppet module as mentioned here:

https://about.gitlab.com/installation/

Because of the new onibus packaging. my puppet module is currently broken.

I was planning on rewriting it, however it appears that you have already rewritten puppet gitlab to work with the new package cloud repos.

I'm evaluating if I want to deprecate my module, and instead refer people to your module. What are your thoughts on referring people to your module?

Can this be confirmed as working or not?

Every hiera directive for gitlab.rb I need works for me except
gitlab::registry_external_url: 'somedomain.com:4567'
and
gitlab::registry_nginx:
ssl_certificate: '/etc/gitlab/ssl/somedomain.com.crt'
ssl_certificate_key: '/etc/gitlab/ssl/somedomain.com.key'

Before I keep on digging with my local instance I need to know that it does actually work.

thanks.

When using CentOS, xz-utils is incorrect. It should just be xz.

The way that YAML generation is done in the gitlab.rb template runs into a big flaw when it comes to Omniauth - SAML data in particular;

A manifest like;

# ...
  class { '::gitlab':
    gitlab_rails => {
      'omniauth_enabled'                                    => $_saml_enabled,
      'omniauth_providers'                                  => [
        {
          'name'  => 'saml',
          'label' => '<Company ID>',
          'args'  => {
            'allowed_clock_drift'            => 5,
            'assertion_customer_service_url' => "${external_url}/users/auth/saml/callback",
            'idp_cert_fingerprint'           => '00:01:02:03:04:05:06:07:08:09:0A:0B:0C:0D:0E:0F:10:11:12:13',
            'idp_sso_target_url'             => '<ADFS endpoint>',
            'issuer'                         => $external_url,
            'name_identifier_format'         => 'urn:oasis:names:tc:SAML:2.0:nameid-format:persistent',
          },
        },
      ],
    },
  }

Will generate ruby code alike the following:

# gitlab.rb

#...
gitlab_rails["omniauth_providers"] => [
  {
    "args" => {
      "allowed_clock_drift" => "5",
      "assertion_consumer_service_url" => "<external url>/users/auth/saml/callback",
      "idp_cert_fingerprint" => "00:01:02:03:04:05:06:07:08:09:0A:0B:0C:0D:0E:0F:10:11:12:13",
      "idp_sso_target_url" => "<ADFS endpoint>",
      "issuer" => "<external url>",
      "name_identifier_format" => "urn:oasis:names:tc:SAML:2.0:nameid-format:persistent"
    },
    "label" => "<Company ID>",
    "name" => "saml"
  }
]

Causing OmniAuth SAML to fail its authentication attempt when trying to use the allowed_clock_drift string value as a numeral.

Reading into the compiled catalog reveals that Puppet is actually sending the value as a string literal. In fact, all numerals are strings in the catalog.

One possible way to prevent this could be to hard-code certain keys as guaranteed plain numerals in the template, might also not be a problem with newer Puppet versions.

Hiera Code:

gitlab::gitlab_rails:
  omniauth_enabled: true
  omniauth_allow_single_sign_on: false
  block_auto_created_users: true
  omniauth_providers:
    - name: "github"
      app_id: "9a6161e2354332d5b5f5"
      app_secret: "ec032383e83fb59205a381f3ac9ec98a9a2bb486"
      url: "https://github.com/"
      args:
       scope: "user:email"

The result in /etc/gitlab/gitlab.rb

gitlab_rails['omniauth_providers'] = ["{"name"=>"github", "app_id"=>"9a6161e2354332d5b5f5", "app_secret"=>"ec032383e83fb59205a381f3ac9ec98a9a2bb486", "url"=>"https://github.com/", "args"=>{"scope"=>"user:email"}}"]

The quote in the Array is not needed.

Excerpt from https://about.gitlab.com/2015/07/22/gitlab-7-13-released/:

GitLab CI now uses symmetric encryption to share ‘secure variables’ (provided by your users) in the SQL database. Symmetric encryption needs a secret key, which GitLab CI will generate for you when you install / upgrade to 7.13.

The key is called db_key_base and can be found in /etc/gitlab/gitlab-secrets.json (in Omnibus packages) or config/secrets.yml (in installations from source). If you lose this secret key during a backup restore or a server migration, your users will lose their ‘secure variables’.

Don’t store the secret key in the same place as your database backups. If you do, somebody who steals your backup also gets your users' secure variables.

If you use configuration management (Chef, Puppet etc.) you should store the secret key securely in your configuration management system. This way, your CI server uses the correct DB secret key after a server rebuild.

Hi,

I just did a fresh install of Gitlab on RHEL 6.5 / Puppet 3.8.1 using the module, and I'm getting a 500 error when trying to access /users/sign_in (see below). I found a lot of references to this type of error for upgrades / database migrations, but less for new installations. I'm assuming that the "projects" table would be a default (since I don't have any data that I've added to gitlab yet)?

I'll keep digging, but I thought it was worth asking in case you've seen this error before after an install.

The production.log file says:

Started GET "/users/sign_in" for 127.0.0.1 at 2015-10-27 17:20:15 -0400
Processing by SessionsController#new as HTML
PG::UndefinedTable: ERROR: relation "projects" does not exist
LINE 5: WHERE a.attrelid = '"projects"'::regclass
^
: SELECT a.attname, format_type(a.atttypid, a.atttypmod),
pg_get_expr(d.adbin, d.adrelid), a.attnotnull, a.atttypid, a.atttypmod
FROM pg_attribute a LEFT JOIN pg_attrdef d
ON a.attrelid = d.adrelid AND a.attnum = d.adnum
WHERE a.attrelid = '"projects"'::regclass
AND a.attnum > 0 AND NOT a.attisdropped
ORDER BY a.attnum

Completed 500 Internal Server Error in 15ms (ActiveRecord: 9.7ms)

When I tried to troubleshoot by running gitlab-ci-rake commands, it complained about not being able to load files under /opt/gitlab/etc/gitlab-ci - that directory does not appear to exist.

[root@linvm2346 gitlab-rails]# gitlab-ci-rake db:migrate:status
/usr/bin/gitlab-ci-rake error: could not load /opt/gitlab/etc/gitlab-ci/gitlab-ci-rc
Either you are not allowed to read the file, or it does not exist yet.
You can generate it with: sudo gitlab-ctl reconfigure

[root@linvm2346 gitlab-rails]# cd /opt/gitlab/etc
[root@linvm2346 etc]# ls -la
total 48
drwxrwxr-x 3 root root 4096 Oct 27 17:01 .
drwxrwxr-x 9 root root 4096 Oct 27 17:01 ..
drwx------ 3 git root 4096 Oct 27 17:01 gitlab-rails
-rw-rw-r-- 1 root root 35191 Oct 27 08:43 gitlab.rb.template

I tried running gitlab-ctl reconfigure by hand to look for errors, etc., but there weren't any obvious issues (and it still didn't create the gitlab-ci directory).

Will there be Version support in the module?
Currently latest works but see few caveats:

1. if someone wants to lock to a particular version and not update
2. with a version parameter you can update on next puppet run, now you have to do a full "update" at the system level

I didn't see support for oauth configuration and backup providers in your wiki on puppetforge, if it's already supported, my apologies, but I did not find it.

In omnibus this was deprecated but using puppet manually configuring options via UI probably isn't the best solution:

7.9.0

DEPRECATION: 'gitlab_signup_enabled', 'gitlab_signin_enabled', 'gitlab_default_projects_limit', 'gravatar_enabled' are deprecated, settings can be changed in admin section of GitLab UI

Their is an unfortunate use case scenario where one would want to install the package, repo etc, however not manage the service/config file.

So it's partially managed by puppet.

Currently, the service management by puppet is configurable however the config file management is not.

Would be useful if the config file management was optional/configurable.

It looks like a several pull requests have been merged in since the last release. Any chance a new release can be published?

Gitlab 8.5.5
Module 1.8.0 release

On a fresh provision:

==> gitlab: Error: /Stage[main]/Gitlab::Service/Service[gitlab-runsvdir]: Failed to call refresh: Could not restart Service[gitlab-runsvdir]: Execution of '/usr/bin/gitlab-ctl restart' returned 1: ok: run: gitlab-workhorse: (pid 7493) 1s
==> gitlab: ok: run: logrotate: (pid 7499) 0s
==> gitlab: timeout: down: nginx: 0s, normally up, want up
==> gitlab: ok: run: postgresql: (pid 7573) 0s
==> gitlab: ok: run: redis: (pid 7582) 1s
==> gitlab: ok: run: sidekiq: (pid 7594) 0s
==> gitlab: ok: run: unicorn: (pid 7599) 0s
==> gitlab: Error: /Stage[main]/Gitlab::Service/Service[gitlab-runsvdir]: Could not restart Service[gitlab-runsvdir]: Execution of '/usr/bin/gitlab-ctl restart' returned 1: ok: run: gitlab-workhorse: (pid 7493) 1s
==> gitlab: ok: run: logrotate: (pid 7499) 0s
==> gitlab: timeout: down: nginx: 0s, normally up, want up
==> gitlab: ok: run: postgresql: (pid 7573) 0s
==> gitlab: ok: run: redis: (pid 7582) 1s
==> gitlab: ok: run: sidekiq: (pid 7594) 0s
==> gitlab: ok: run: unicorn: (pid 7599) 0s

Second provision is okay

GitLab 8.0 introduced gitlab-workhorse(https://gitlab.com/gitlab-org/gitlab-workhorse/blob/master/README.md) for HTTP requests, so there are gitlab_workhorse[] configurations available for gitlab.rb. Would be nice if this could be managed by the module.

Version 7.14 of Gitlab now supports Mattermost (http://doc.gitlab.com/omnibus/gitlab-mattermost/). A new parameter must be specified in /etc/gitlab/gitlab.rb:

mattermost_external_url 'http://mattermost.example.com'

This parameter should be added to the template and the init module. Maybe a hash of parameters would be nice so it could handle future new parameters.

At least on RHEL, as you use a single yumrepo resource with the same name for 2 different repos, when upgrading from CE to EE edition the Yum repo is not being updated and upgrade does not happen until you manually remove the old repo and do a yum clean.

I think it would be enough to add edition to yumrepo resource name but unfortunately I don't have time to create a PR right now, sorry.

reference: https://github.com/puppetlabs/puppetlabs-stdlib
and example of replacement: https://github.com/puppetlabs/puppetlabs-ntp/blob/master/manifests/init.pp#L17-L28

Add beaker acceptance tests to Travis

Basic tests to make sure standard install works 👍

To fetch packages from https sources the package apt-transport-https must be installed on the system (at least on Debian jessie).

This module should be made compatibile with more recent version of the apt module to play nice with other module. (eg. if you "puppet module install puppetlabs-postgresql" before this you'll get an error due to an incompatible apt module being installed)

See https://gitlab.com/gitlab-org/omnibus-gitlab/blob/master/files/gitlab-config-template/gitlab.rb.template#L735

We were running spuder's gitlab module, and really want to leap to this module, but we are running puppet enterprise 3.6.2. Upgrading is on the roadmap, but not in the immediate future. Is it possible that the module is compatible with 3.6.2, but untested? Or did you use some 3.7-specific functionality (which is what I'm guessing).

For Debian (instead of Ubuntu) location in init.pp is wrong

it should be

location => "https://packages.gitlab.com/gitlab/gitlab-${edition}/debian/",