HOWTO: Install Gitlab on FreeBSD

Thanks a lot for the link. It works like a charm. When implemented into a jail(8), just do not forget to set allow.sysvipc for the PostgreSQL database.

--- Update ---
Well, I had just a small issue. I had to edit the /home/git/gitlab-shell/config.yml and replace /home by /usr/home since gitlab-shell does not like symlink.
 
  • Thanks
Reactions: Oko
Thanks for the links. Up to point 6 everything works fine. But when I try to install gitlab shell rake aborts with these errors:
Code:
rake aborted!
Psych::SyntaxError: (<unknown>): did not find expected key while parsing a block mapping at line 18 column 3
/usr/home/git/gitlab/vendor/bundle/ruby/2.1/gems/settingslogic-2.0.9/lib/settingslogic.rb:103:in `initialize'
/usr/home/git/gitlab/vendor/bundle/ruby/2.1/gems/settingslogic-2.0.9/lib/settingslogic.rb:60:in `new'
/usr/home/git/gitlab/vendor/bundle/ruby/2.1/gems/settingslogic-2.0.9/lib/settingslogic.rb:60:in `instance'
/usr/home/git/gitlab/vendor/bundle/ruby/2.1/gems/settingslogic-2.0.9/lib/settingslogic.rb:37:in `[]'
/usr/home/git/gitlab/config/initializers/1_settings.rb:57:in `<top (required)>'
/usr/home/git/gitlab/vendor/bundle/ruby/2.1/gems/activesupport-4.1.1/lib/active_support/dependencies.rb:241:in `load'
/usr/home/git/gitlab/vendor/bundle/ruby/2.1/gems/activesupport-4.1.1/lib/active_support/dependencies.rb:241:in `block in load'
/usr/home/git/gitlab/vendor/bundle/ruby/2.1/gems/activesupport-4.1.1/lib/active_support/dependencies.rb:232:in `load_dependency'
/usr/home/git/gitlab/vendor/bundle/ruby/2.1/gems/activesupport-4.1.1/lib/active_support/dependencies.rb:241:in `load'
/usr/home/git/gitlab/vendor/bundle/ruby/2.1/gems/railties-4.1.1/lib/rails/engine.rb:648:in `block in load_config_initializer'
/usr/home/git/gitlab/vendor/bundle/ruby/2.1/gems/activesupport-4.1.1/lib/active_support/notifications.rb:161:in `instrument'
/usr/home/git/gitlab/vendor/bundle/ruby/2.1/gems/railties-4.1.1/lib/rails/engine.rb:647:in `load_config_initializer'
/usr/home/git/gitlab/vendor/bundle/ruby/2.1/gems/railties-4.1.1/lib/rails/engine.rb:612:in `block (2 levels) in <class:Engine>'
/usr/home/git/gitlab/vendor/bundle/ruby/2.1/gems/railties-4.1.1/lib/rails/engine.rb:611:in `each'
/usr/home/git/gitlab/vendor/bundle/ruby/2.1/gems/railties-4.1.1/lib/rails/engine.rb:611:in `block in <class:Engine>'
/usr/home/git/gitlab/vendor/bundle/ruby/2.1/gems/railties-4.1.1/lib/rails/initializable.rb:30:in `instance_exec'
/usr/home/git/gitlab/vendor/bundle/ruby/2.1/gems/railties-4.1.1/lib/rails/initializable.rb:30:in `run'
/usr/home/git/gitlab/vendor/bundle/ruby/2.1/gems/railties-4.1.1/lib/rails/initializable.rb:55:in `block in run_initializers'
/usr/home/git/gitlab/vendor/bundle/ruby/2.1/gems/railties-4.1.1/lib/rails/initializable.rb:44:in `each'
/usr/home/git/gitlab/vendor/bundle/ruby/2.1/gems/railties-4.1.1/lib/rails/initializable.rb:44:in `tsort_each_child'
/usr/home/git/gitlab/vendor/bundle/ruby/2.1/gems/railties-4.1.1/lib/rails/initializable.rb:54:in `run_initializers'
/usr/home/git/gitlab/vendor/bundle/ruby/2.1/gems/railties-4.1.1/lib/rails/application.rb:288:in `initialize!'
/usr/home/git/gitlab/vendor/bundle/ruby/2.1/gems/railties-4.1.1/lib/rails/railtie.rb:194:in `public_send'
/usr/home/git/gitlab/vendor/bundle/ruby/2.1/gems/railties-4.1.1/lib/rails/railtie.rb:194:in `method_missing'
/usr/home/git/gitlab/config/environment.rb:5:in `<top (required)>'
/usr/home/git/gitlab/vendor/bundle/ruby/2.1/gems/activesupport-4.1.1/lib/active_support/dependencies.rb:247:in `require'
/usr/home/git/gitlab/vendor/bundle/ruby/2.1/gems/activesupport-4.1.1/lib/active_support/dependencies.rb:247:in `block in require'
/usr/home/git/gitlab/vendor/bundle/ruby/2.1/gems/activesupport-4.1.1/lib/active_support/dependencies.rb:232:in `load_dependency'
/usr/home/git/gitlab/vendor/bundle/ruby/2.1/gems/activesupport-4.1.1/lib/active_support/dependencies.rb:247:in `require'
/usr/home/git/gitlab/vendor/bundle/ruby/2.1/gems/railties-4.1.1/lib/rails/application.rb:264:in `require_environment!'
/usr/home/git/gitlab/vendor/bundle/ruby/2.1/gems/railties-4.1.1/lib/rails/application.rb:367:in `block in run_tasks_blocks'
Tasks: TOP => gitlab:shell:install => environment
Unfortunately I have no idea about Ruby or Rake or what happens there. So any help would be welcome.

Edit: Found the problem. Seems there was something wrong in config/gitlab.yml. I copied again from config/gitlab.yml.example and re-entered my config (IMHO the same way iI did before...). Now it seems to work.
 
  • Thanks
Reactions: Oko
Hello everyone,

please notice, that GitLab is coming into the ports. After some months of works, there is finally a PR:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=202468

As you can see there is a massive number of dependencies - this will take a while for the committers.

But its usable and there is an documentation:
https://github.com/t-zuehlsdorff/gitlabhq/blob/master/doc/install/installation-freebsd.md

Many configuration is already done by the port, therefore there are less steps to go. :)

Feel free to give it a try and report.

Greetings,
Torsten
 
I was playing with this whole day but I am not even close to have everything working as I want to. Few questions. I was following

https://github.com/gitlabhq/gitlab-recipes/blob/master/install/freebsd/freebsd-10.md

and

of course


https://blog.assemblyco.de/installing-gitlab-on-freebsd-10/

Seemingly installation went without a glitch but this is what I get when I try to start GitLab daemon

Code:
root@gitlab:~ # service gitlab status
The GitLab Unicorn web server with pid 87843 is running.
The GitLab Sidekiq job dispatcher with pid 87928 is running.
The gitlab-workhorse is not running.
GitLab and all its components are up and running.

Apparently workhorse is failing because it can't find PID file

Code:
root@gitlab:/home/git/gitlab/log # more /home/git/gitlab/log/gitlab-workhorse.log
/usr/local/etc/rc.d/gitlab: /home/git/gitlab/bin/daemon_with_pidfile: not found

unicorn.stderr.log is also revealing
Code:
E, [2016-01-13T01:28:01.631943 #86647] ERROR -- : 192.168.6.21:8080 failed to set accept_filter=httpready (#<Errno::ENOENT: No such file or directory - setsockopt(2)>)

I am guessing the above error is because the workhorse is not running. I am practically clueless about most of the stuff required to run GitLab (Sidekiq, Unicorn, Nginx, Ruby) with perhaps the exception of Nginx.


As a side question is there a nice way to handle
Code:
jail -m jid=3 allow.sysviPostgreSQLpc=1
in order to run PostgreSQL in the jail. In particularly what to do about running multiple PostgreSQL in different jails? I stumbled upon

https://www.textplain.net/tutorials/2015/running-postgresql-in-freebsd-jails/

which seems to describe an "easy" solution.
 
Does anyone have experience integrating GitLab with LDAP? I am not sure what would be the best ways to enable access to repos.
 
Apologies that I don't have more time to flesh this out, but I installed GitLab in a 10.2-RELEASE jail last week (with PostgreSQL and Nginx, no LDAP I'm afraid).

I copied the commands into a gist as I executed them, here:
https://gist.github.com/forquare/b9be67873d6dd6b1d2a6

I then write a new RC script here:
https://gist.github.com/forquare/d352c58c0f1ec3021fe7

And modified the official Gitlab rc script and placed it in /usr/local/bin, you can find my modified script here:
https://gist.github.com/forquare/178c42f67198ef49285c

I think the only thing that my copy & pasted commands miss out is using those two modifications.

Hope it's of some help and not too incoherent…

Ben
 
Just a quick update on my side. I was too busy too look again to see what is wrong with my GitLab installation. I played one night with Gogs on DragonFly and had no problems compiling it and configuring it in 5 minutes. Installing it on FreeBSD 10.2 was surprisingly non-trivial and compilation failed but this work-in-progress package

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=205283#c34

worked for me. Anyhow the only thing we are missing on Gogs is continuous integration services. Most posts on the Internet mentioned the lack of Wiki, Code Review, and Snippets on Gogs but all those things are now integrated. Seeing the number of GitLab refugees who are switching to Gogs I am sure integration services will be added. I don't want anything else to be added. Gogs is very simple and much lighter than GitLab and completely sufficient for our core team of 20 developers. Gogs configuration files are trivial to read. My only complaint so far is spotty documentation (typical Linux stuff).
 
According to PR 202468 linked to above by Thorny, no, not yet.
This is currently true, sadly. The maintainer did not find time and in the meantime big changes make the old work improper.

But this month there is a working version back in the PR and a new committer is already taking care of it. Today half of the left dependencies were committed and i think the rest will comes relatively fast :)
 
I am working my way through https://gitlab.com/gitlab-org/gitlab-recipes/blob/master/install/freebsd/freebsd-10.md trying to get gitlab-ce installed in a jail with postgresql sitting outisde the jail, on the host.

I started gitlab with service gitlab start but gitlab-workhorse would never start. The error I would see is:

Code:
/home/git/gitlab/bin/daemon_with_pidfile:25:in `exec': No such file or directory - /home/git/gitlab/../gitlab-workhorse/gitlab-workhorse (Errno::ENOENT)
        from /home/git/gitlab/bin/daemon_with_pidfile:25:in `main'
        from /home/git/gitlab/bin/daemon_with_pidfile:33:in `<main>'

I'm still working on it.
 
I am working my way through https://gitlab.com/gitlab-org/gitlab-recipes/blob/master/install/freebsd/freebsd-10.md trying to get gitlab-ce installed in a jail with postgresql sitting outisde the jail, on the host.

I started gitlab with service gitlab start but gitlab-workhorse would never start. The error I would see is:

Code:
/home/git/gitlab/bin/daemon_with_pidfile:25:in `exec': No such file or directory - /home/git/gitlab/../gitlab-workhorse/gitlab-workhorse (Errno::ENOENT)
        from /home/git/gitlab/bin/daemon_with_pidfile:25:in `main'
        from /home/git/gitlab/bin/daemon_with_pidfile:33:in `<main>'

I'm still working on it.
The reason is, that the recipe you are following is written for an older version of GitLab. Gitlab-Workhorse is introduced later and must be installed seperatly. Many things have changed between the recipe and the current GitLab version.

You can save the trouble by using the shar in the PR: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=202468
Just one dependency is left (with a working patch). It also contains a pointer to a working documentation to get GitLab up. We try to bring GitLab into the tree within the next two days; right before the next quarterly branch ;) Hopefully this works. But even not: there is already everything done :) Have a look!
 
Any idea how complex is to keep this port in sync with actual GitLab version?
Port has version 8.5.5, GitLab already has 8.6.4.
 
Any idea how complex is to keep this port in sync with actual GitLab version?
Port has version 8.5.5, GitLab already has 8.6.4.
Of course - it took me nearly a year to get gitlab into the portstree - so i have a fair good inside of the work. At the moment it is fairly easy, as you maybe can read from the already linked PR.
8.5.5 is in the tree, because we tried to get it into the quarterly branch and decide to not go with 8.6, because of the needed QA cycles and just one day left.
 
Of course - it took me nearly a year to get gitlab into the portstree - so i have a fair good inside of the work. At the moment it is fairly easy, as you maybe can read from the already linked PR.
8.5.5 is in the tree, because we tried to get it into the quarterly branch and decide to not go with 8.6, because of the needed QA cycles and just one day left.

Sounds really good.
Is there anything how I can help/contribute to this port?
 
Is there anything how I can help/contribute to this port?
Install it and test the heck out of it in a real world situation. Report any issues and/or errors.

I'm going to do the same, I was waiting for it to appear in the ports tree :)
 
Testing is what is currently needed most! Especially because of the current switch to Ruby 2.2 in the Portstree.
Links to Bugzilla was already posted.
 
The reason is, that the recipe you are following is written for an older version of GitLab. Gitlab-Workhorse is introduced later and must be installed seperatly. Many things have changed between the recipe and the current GitLab version.

You can save the trouble by using the shar in the PR: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=202468
Just one dependency is left (with a working patch). It also contains a pointer to a working documentation to get GitLab up. We try to bring GitLab into the tree within the next two days; right before the next quarterly branch ;) Hopefully this works. But even not: there is already everything done :) Have a look!

Thanks! I did find this other guide which I was going to try out: https://project.altservice.com/issues/679

The port is cool.
 
The other guide seems more fine, but has some issues. Beside installing unnecessary software and steps, it installs all rubygems with gems and ignores pkg. This is fine, if you know what this means: there is no security warning with broken gems, there is no central update via pkg and it did not honor gems, which needs software to be installed.

The port has currently some small issues. Sometimes it is broken because gems are too up to date. But at least you have no security issues ;) Therefore an update is much much easier.

Both ways have their pro and cons. If you have the possibility just try which fits you best!
 
Back
Top