General

Official Install Documentation

Repositories

1. use the repositories from devel:languages:ruby and home:darix:apps
2. zypper in –from home:darix:apps redis gitlab-ce gitlab-shell

config redis:

See also: /usr/share/doc/packages/redis/README.SUSE

$ cd /etc/redis
$ cp default.conf.example gitlab.conf
$ vi gitlab.conf

* daemonize no
* pidfile /var/run/redis/gitlab.pid
* logfile /var/log/redis/gitlab.log
* dir /var/lib/redis/gitlab/

$ install -d -m 0750 -o redis -g redis /var/lib/redis/gitlab/
$ chown root:redis gitlab.conf
$ sc start redis@gitlab
$ sc enable redis@gitlab

GitLab Shell

1. cd /usr/share/gitlab/shell/; cp config.yml{.example,}
2. set up redis socket matching /etc/redis/gitlab.conf
3. maybe enable audit_usernames (but see warning)

config rails app

1. cd /srv/www/vhosts/gitlab-ce/
2. configure database.yml (based on postgresql example)
3. cp config/gitlab.yml.{example,}

• host, port, https, email_from in gitlab section
• optionally ldap settings

4. cp config/resque.yml.{example,}

• adapt socket for redis. should match /etc/redis/gitlab.conf

5. export RAILS_ENV="${RAILS_ENV:=production}"
6. gitlab-ce-update
7. rake db:seed_fu
8. check for new files which are now owned by root:root (e.g. .gitlab_shell_secret) they should be owned by root:gitlab with permissions u=rw,g=r,o=
9. make sure you have the symlink .gitlab_shell_secret /srv/www/vhosts/gitlab-ce/.gitlab_shell_secret
10. Configure git for gitlab user as seen in official docs
11. sc start gitlab-ce-unicorn gitlab-ce-sidekiq gitlab-workhorse
12. sc enable gitlab-ce-unicorn gitlab-ce-sidekiq gitlab-workhorse

Testing things

1. ssh access

ssh -T gitlab@gitlab.suse.de
Welcome to GitLab, $yourusername!

…

A long time a go a coworker documented the ssh forwarding with xinetd trick that i showed him. We use it heavily on our virtualisation cluster for openSUSE. Of course it gets annoying if you have to pass the port parameter to each invocation of ssh or scp. Especially since ssh and scp are so nicely consistent for that. ;)

As the title already implies, ssh has a config file which we can use. It allows us to basically set every setting that can also pass via command line argument and all that per host.

…

Taking ruby packaging to the next level

Table of Content

1. TL;DR
2. Where we started
3. The basics
4. One step at a time
5. Rocks on the road
6. “Job done right?” “Well almost.”
7. Whats left?

TL;DR

• we are going back to versioned ruby packages with a new naming scheme.
• one spec file to rule them all. (one spec file to build a rubygem for all interpreters)
• macro based buildrequires. %{rubygem rails:4.1 >= 4.1.4}
• gem2rpm.yml as configuration file for gem2rpm. no more manual editing of spec files.
• with the config spec files can always be regenerated without losing things.

Where we started

A long time ago we started with the support for building for multiple ruby versions, actually MRI versions, at the same time. The ruby base package was in good shape in that regard. But we had one open issue - building rubygems for multiple ruby versions. This issue was hanging for awhile so we went and reverted to a single ruby version packaged for openSUSE again.

…

README.SUSE

So it seems you installed the discourse package that we provide for openSUSE/SUSE.

Preparing PostgreSQL

$ zypper in postgresql-server postgresql-server

$ su - postgres

$ createuser -P discourse

$ createdb -O discourse discourse

Add the required postgresql extensions to the DB. We extract those at build time from the migrations. If you run migrations with a normal postgresql user, you can not add extensions during the migrations. That’s why we add them here.

…