# HOWTO: Install Gitlab on FreeBSD



## rodrigc@ (Mar 19, 2015)

Charles Newey posted an excellent blog entry for setting up Gitlab on FreeBSD:

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

For anyone who has set up Gitlab, please update this thread with setup and tuning information.


----------



## hukadan (Mar 28, 2015)

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.


----------



## Derjan (May 13, 2015)

Thanks for the links. Up to point 6 everything works fine. But when I try to install gitlab shell rake aborts with these errors:
	
	



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


----------



## Thorny (Sep 12, 2015)

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


----------



## Oko (Jan 12, 2016)

Is this in ports? I see bunch of Gitlab related ports

https://www.freebsd.org/cgi/ports.cgi?query=gitlab&stype=all

Also that how-to on GitLab website has few minor problems starting with the fact that one has to setup PostgreSQL before it can run. Also adding few sentences how to run this in jail would be nice as PostgreSQL requires some attention to run in the Jail.


----------



## protocelt (Jan 12, 2016)

Oko said:


> Is this in ports? I see bunch of Gitlab related ports


According to PR 202468 linked to above by Thorny, no, not yet.


----------



## Oko (Jan 13, 2016)

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


```
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


```
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

```
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 

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


----------



## Oko (Jan 13, 2016)

Does anyone have experience integrating GitLab with LDAP? I am not sure what would be the best ways to enable access to repos.


----------



## forquare (Jan 13, 2016)

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


----------



## Oko (Feb 17, 2016)

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


----------



## Thorny (Mar 14, 2016)

protocelt said:


> 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


----------



## manas (Mar 24, 2016)

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:


```
/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.


----------



## Thorny (Mar 30, 2016)

manas said:


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


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!


----------



## Thorny (Apr 1, 2016)

Heads up, GitLab hits the portstree yesterday! 
http://www.freshports.org/www/gitlab


----------



## miks (Apr 5, 2016)

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.


----------



## acheron (Apr 6, 2016)

See PR 208511


----------



## Thorny (Apr 6, 2016)

miks said:


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


----------



## miks (Apr 6, 2016)

Thorny said:


> 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?


----------



## SirDice (Apr 6, 2016)

miks said:


> 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


----------



## miks (Apr 6, 2016)

Where I need to report any issue? I guess it's not here, in forum.


----------



## acheron (Apr 6, 2016)

In bugzilla: https://bugs.freebsd.org/bugzilla/
Have a look at this documentation: https://www.freebsd.org/doc/en/articles/problem-reports/article.html


----------



## Thorny (Apr 6, 2016)

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.


----------



## manas (Apr 6, 2016)

Thorny said:


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


----------



## Thorny (Apr 7, 2016)

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!


----------



## miks (Apr 9, 2016)

I can't get gitlab to start on boot (in jail).
When digged little, it's seems more general problem:

https://forums.freebsd.org/threads/34852/
https://forums.freebsd.org/threads/33053/
https://forums.freebsd.org/threads/54631/

With rc_debug="YES" rc_info="YES" gitlab does not show up in logs.
But it's in `service -e` and `rcorder /etc/rc.d/* /usr/local/etc/rc.d/*`.

Any ideas why is that?


----------



## forquare (Apr 10, 2016)

miks said:


> I can't get gitlab to start on boot (in jail).



Is this the ports version or have you manually installed Gitlab?


----------



## miks (Apr 10, 2016)

I have tried with booth. And it's doesn't matter as rc.d/gitlab is same. Problem is -  script is not called at all.
If I don't add any REQUIRE statements, its called and fails to start because mysql is not started yet.
REQUIRE: LOGIN or any other statement (mysql for example) make rc.d/gitlab disappear.


----------



## matunixe (Apr 10, 2016)

Hello mates,

Thank you very much for the effort for providing this Gitlab port. I have a lot of problems to manage with it but I expect the last version would correct this (I see a lot of issues on the projects Github page).
Very impatient to test the 8.6.5 !


----------



## Thorny (Apr 11, 2016)

Like mentioned in the PR 208511 this could be through a dependency on redis. If Redis is not started, GitLab won't start.

Also GitLab has various logfiles, but all are placed in:
/usr/local/www/gitlab/log/

Can you examine the output and create a new PR for this issue?

Thank you very much for the Feedback!


----------



## Thorny (Apr 11, 2016)

miks said:


> I have tried with booth. And it's doesn't matter as rc.d/gitlab is same. Problem is -  script is not called at all.


Before i forget: this is not true. The GitLab script provied by the port is not the same like installing from the source. The source file has some problems with switching users and is therefore modified. Also it assumes other pathes than the port provide, which can lead to other errors.


----------



## miks (Apr 13, 2016)

I can confirm that patched gitlab init script (https://bugs.freebsd.org/bugzilla/attachment.cgi?id=169275) is starting gitlab on boot. Even on my non-port gitlab install (I only needed to change gitlab directory).


----------

