Difference between revisions of "GitLab"

From ArchWiki
Jump to navigation Jump to search
m (Default username has changed to 'root')
Line 37: Line 37:
  
 
===Basic configuration===
 
===Basic configuration===
Open {{ic|/etc/webapps/gitlab/shell.yml}} and set {{ic|gitlab_url:}} to the url where you intend to host GitLab (note the 'http://' and trailing slash). For example, if you will host GitLab at 'yourdomain.com', then it would look like this:
+
Open {{ic|/etc/webapps/gitlab-shell/shell.yml}} and set {{ic|gitlab_url:}} to the url where you intend to host GitLab (note the 'http://' and trailing slash). For example, if you will host GitLab at 'yourdomain.com', then it would look like this:
  
{{hc|/etc/webapps/gitlab/shell.yml|2=
+
{{hc|/etc/webapps/gitlab-shell/shell.yml|2=
 
# GitLab user. git by default
 
# GitLab user. git by default
 
user: gitlab
 
user: gitlab

Revision as of 18:45, 25 October 2014

From GitLab's homepage:

GitLab offers git repository management, code reviews, issue tracking, activity feeds and wikis. Enterprises install GitLab on-premise and connect it with LDAP and Active Directory servers for secure authentication and authorization. A single GitLab server can handle more than 25,000 users but it is also possible to create a high availability setup with multiple active servers.

A demo is available at their site: GitLab demo.

Installation

Note: If you want to use RVM refer to the article Gitlab#Running GitLab with rvm before starting with the installation
Note: This article covers installing and configuring GitLab without HTTPS at first. If needed, see #Advanced Configuration to set up SSL

Install the gitlabAUR package from the AUR.

If you are planning to host GitLab on the same machine as its database, you need to install a database backend before installing gitlabAUR:

In order to receive mail notifications, a mail server must be installed and configured. See the following for more information:

Configuration

Notes Before Configuring

The gitlabAUR package installs GitLab's files in a manner that more closely follows standard Linux conventions rather than installing everything in /home/git as you are told to do by GitLab's official install guide.

After you have installed gitlab from AUR, the config file /etc/webapps/gitlab/shell.yml corresponds to the file /home/git/gitlab-shell/config.yml that is mentioned in GitLab's official install guide when installing gitlab-shell. The config file /etc/webapps/gitlab/gitlab.yml corresponds to the file /home/git/gitlab/config/gitlab.yml that is mentioned in GitLab's official install guide when configuring GitLab.

Another key difference between gitlab from AUR and the GitLab install guide is that GitLab from AUR uses the gitlab user with /var/lib/gitlab as the home folder instead of the git user with /home/git as the home folder. This keeps the /home area clean so it contains only real user homes.

Tip: If you are familiar with the Arch Build System you can edit the PKGBUILD and relevant files to change gitlab's home directory to a place of your liking.

Basic configuration

Open /etc/webapps/gitlab-shell/shell.yml and set gitlab_url: to the url where you intend to host GitLab (note the 'http://' and trailing slash). For example, if you will host GitLab at 'yourdomain.com', then it would look like this:

/etc/webapps/gitlab-shell/shell.yml
# GitLab user. git by default
user: gitlab

# Url to gitlab instance. Used for api calls. Should end with a slash.
# Default: http://localhost:8080/
# You only have to change the default if you have configured Unicorn
# to listen on a custom port, or if you have configured Unicorn to
# only listen on a Unix domain socket.
gitlab_url: "http://localhost:8080/" # <<-- right here

http_settings:
#  user: someone
#  password: somepass
...

You can leave the gitlab_url with default value if you will host gitlab and the web server on the same host.

Open /etc/webapps/gitlab/gitlab.yml and edit where needed. In the gitlab: section set host: (replacing localhost) to 'yourdomain.com', your fully qualified domin name (no 'http://' or trailing slash). port: can be confusing. This is not the port that the gitlab server (unicorn) runs on; it's the port that users will initially access through in their browser. Basically, if you intend for users to visit 'yourdomain.com' in their browser, without appending a port number to the domain name, leave port: as 80. If you intend your users to type something like 'yourdomain.com:3425' into their browsers, then you'd set port: to 3425 (You will also have to configure your server (apache, nginx, etc) to listen on that port). Those are the minimal changes needed for a working GitLab install. The adventurous may read on in the comment and customize as needed. For example:

/etc/webapps/gitlab/gitlab.yml
...
  ## GitLab settings
  gitlab:
    ## Web server settings
    host: yourdomain.com
    port: 80
    https: false
...

Further configuration

Database backend

A Database backend will be required before Gitlab can be run. Currently GitLab supports MariaDB and PostgreSQL. By default, GitLab assumes you will use MySQL. Extra work is needed if you plan to use PostgreSQL.

Note: Do not forget to replace your_username_here and your_password_here with your chosen values in the following examples.

MariaDB

To set up MySQL (MariaDB) you need to create a database called gitlabhq_production along with a user who has full priviledges to the database. You might do it via command line as in the following example.

mysql -u root -p
mysql> CREATE DATABASE IF NOT EXISTS `gitlabhq_production`;
mysql> CREATE USER 'your_username_here'@'localhost' IDENTIFIED BY 'your_password_here';
mysql> GRANT SELECT, LOCK TABLES, INSERT, UPDATE, DELETE, CREATE, DROP, INDEX, ALTER ON `gitlabhq_production`.* TO 'your_username_here'@'localhost';
mysql> \q

Now try connecting to the new database with the new user to verify you did it correctly:

mysql -u your_username_here -p -D gitlabhq_production

Next you will need to open /etc/webapps/gitlab/database.yml and set username: and password: for the gitlabhq_production database to your_username_here and your_password_here, respectively. You need not worry about the info for the gitlabhq_development and gitlan_test databases, as those are not required for our purposes (unless you are feeling adventurous at your own risk). For example:

/etc/webapps/gitlab/database.yml
#
# PRODUCTION
#
production:
  adapter: mysql2
  encoding: utf8
  reconnect: false
  database: gitlabhq_production
  pool: 10
  username: your_username_here
  password: "your_password_here"
  # host: localhost
  # socket: /tmp/mysql.sock
...

It should not be set as world readable, e.g. only processes running under the gitlab user can read/write to it. This can be done by running the following commands:

# chmod 600 /etc/webapps/gitlab/database.yml
# chown gitlab:gitlab /etc/webapps/gitlab/database.yml

For more info and other ways to create/manage MySQL databases, see the MariaDB documentation, the GitLab official (generic) install guide, and phpMyAdmin.

PostgreSQL

Login to PostgreSQL and create the gitlabhq_production database with along with it's user. Remember to change your_username_here and your_password_here to the real values:

# psql -d template1
template1=# CREATE USER your_username_here WITH PASSWORD 'your_password_here';
template1=# CREATE DATABASE gitlabhq_production OWNER your_username_here;
template1=# \q

Try connecting to the new database with the new user to verify it works:

# psql -d gitlabhq_production

Copy the PostgreSQL template file before configuring it (overwriting the default MySQL configuration file):

# cp /usr/share/doc/gitlab/database.yml.postgresql /etc/webapps/gitlab/database.yml

Open the new /etc/webapps/gitlab/database.yml and set the values for username: and password:. For example:

/etc/webapps/gitlab/database.yml
#
# PRODUCTION
#
production:
  adapter: postgresql
  encoding: unicode
  database: gitlabhq_production
  pool: 10
  username: your_username_here
  password: "your_password_here"
  # host: localhost
  # port: 5432
  # socket: /tmp/postgresql.sock
...

For our purposes (unless you know what you are doing), you do not need to worry about configuring the other databases listed in /etc/webapps/gitlab/database.yml. We only need to set up the production database to get GitLab working.

Finally, open /usr/lib/systemd/system/gitlab.target change all instances of mysql.service to postgresql.service. For example:

Tango-inaccurate.pngThe factual accuracy of this article or section is disputed.Tango-inaccurate.png

Reason: See systemd#Editing provided unit files for the correct way. (Discuss in Talk:GitLab#)
/usr/lib/systemd/system/gitlab.target
...
[Unit]
Description=GitLab - Self Hosted Git Management
Requires=redis.service postgresql.service
After=redis.service postgresql.service syslog.target network.target

[Install]
WantedBy=multi-user.target

Firewall

If you want to give direct access to your Gitlab installation through a iptables firewall you have to the following ACCEPT rule. Change "your_gitlab_port" to your chosen port from above (here we give access to all clients within 192.168.1.0/24 network):

# iptables -A tcp_inbound -p TCP -s 192.168.1.0/24 --destination-port your_gitlab_port -j ACCEPT

If you are behind a router, do not forget to forward this port to the running GitLab server host, too.

Satellites access

The folder satellites should have the following permissions set:

# chmod 750 /var/lib/gitlab/satellites

Initialize Gitlab database

Start the Redis server before we create the database:

# systemctl start redis
# systemctl enable redis

Then, initialize the database and activate advanced features:

# cd /usr/share/webapps/gitlab
# sudo -u gitlab bundle exec rake gitlab:setup RAILS_ENV=production

Finally, Compile assets.(If you didn't do it,you won't receive data on user/sign_in pages)

# cd /usr/share/webapps/gitlab
# sudo -u gitlab -H bundle exec rake assets:precompile RAILS_ENV=production

Configure Git User

# cd /usr/share/webapps/gitlab
# sudo -u gitlab -H git config --global user.name  "GitLab"
# sudo -u gitlab -H git config --global user.email "example@example.com"

This must match the user and email_from defined in /usr/share/webapps/gitlab/config/gitlab.yml

Adjust modifier bits

(The gitlab check won't pass if the user and group ownership isn't configured properly)

# chmod -R ug+rwX,o-rwx /path/to/repos/
# chmod -R ug-s /path/to/repos
# find /path/to/repos/ -type d -print0 | xargs -0 chmod g+s

Start and test GitLab

With the following commands we check if the steps we followed so far are configured properly.

$ cd /usr/share/webapps/gitlab
$ sudo -u gitlab bundle exec rake gitlab:env:info RAILS_ENV=production
$ sudo -u gitlab bundle exec rake gitlab:check RAILS_ENV=production
Note: These gitlab:env:info and gitlab:check commands will show a fatal error related to git. This is OK.
$ sudo -u gitlab bundle exec rake gitlab:env:info RAILS_ENV=production
fatal: Not a git repository (or any of the parent directories): .git

System information
System:		Arch Linux
Current User:	git
Using RVM:	yes
RVM Version:	1.20.3
Ruby Version:	2.0.0p0
Gem Version:	2.0.0
Bundler Version:1.3.5
Rake Version:	10.0.4

GitLab information
Version:	5.2.0.pre
Revision:
Directory:	/home/git/gitlab
DB Adapter:	mysql2
URL:		http://gitlab.arch
HTTP Clone URL:	http://gitlab.arch/some-project.git
SSH Clone URL:	git@gitlab.arch:some-project.git
Using LDAP:	no
Using Omniauth:	no

GitLab Shell
Version:	1.4.0
Repositories:	/home/git/repositories/
Hooks:		/home/git/gitlab-shell/hooks/
Git:		/usr/bin/git
Note: gitlab:check will complain about missing initscripts. This is nothing to worry about, as systemd service files are used instead (which GitLab does not recognize).
$ sudo -u gitlab bundle exec rake gitlab:check RAILS_ENV=production
fatal: Not a git repository (or any of the parent directories): .git
Checking Environment ...

Git configured for gitlab user? ... yes
Has python2? ... yes
python2 is supported version? ... yes

Checking Environment ... Finished

Checking GitLab Shell ...

GitLab Shell version >= 1.7.9 ? ... OK (1.8.0)
Repo base directory exists? ... yes
Repo base directory is a symlink? ... no
Repo base owned by gitlab:gitlab? ... yes
Repo base access is drwxrws---? ... yes
update hook up-to-date? ... yes
update hooks in repos are links: ... can't check, you have no projects
Running /srv/gitlab/gitlab-shell/bin/check
Check GitLab API access: OK
Check directories and files:
        /srv/gitlab/repositories: OK
        /srv/gitlab/.ssh/authorized_keys: OK
Test redis-cli executable: redis-cli 2.8.4
Send ping to redis server: PONG
gitlab-shell self-check successful

Checking GitLab Shell ... Finished

Checking Sidekiq ...

Running? ... yes
Number of Sidekiq processes ... 1

Checking Sidekiq ... Finished

Checking LDAP ...

LDAP is disabled in config/gitlab.yml

Checking LDAP ... Finished

Checking GitLab ...

Database config exists? ... yes
Database is SQLite ... no
All migrations up? ... fatal: Not a git repository (or any of the parent directories): .git
yes
GitLab config exists? ... yes
GitLab config outdated? ... no
Log directory writable? ... yes
Tmp directory writable? ... yes
Init script exists? ... no
  Try fixing it:
  Install the init script
  For more information see:
  doc/install/installation.md in section "Install Init Script"
  Please fix the error above and rerun the checks.
Init script up-to-date? ... can't check because of previous errors
projects have namespace: ... can't check, you have no projects
Projects have satellites? ... can't check, you have no projects
Redis version >= 2.0.0? ... yes
Your git bin path is "/usr/bin/git"
Git version >= 1.7.10 ? ... yes (1.8.5)

Checking GitLab ... Finished

Make systemd see your new daemon unit files:

$ systemctl daemon-reload

After starting the database backend (in this case MySQL), we can start GitLab with its webserver (Unicorn):

$ systemctl start redis mysqld gitlab-sidekiq gitlab-unicorn

Replace mysqld with postgresql in the above command if you are using PostgreSQL.

To automatically launch GitLab at startup, run:

$ systemctl enable gitlab.target gitlab-sidekiq gitlab-unicorn

Now test your GitLab instance by visiting http://localhost:8080 or http://yourdomain.com and login with the default credentials:

username: root
password: 5iveL!fe
Note: If your browser runs not on the machine where gitlab is running, modify your unicorn.rb in order to be able to test your setup without the use of a proxy. The corresponding line looks like this:
listen "127.0.0.1:8080, :tcp_nopush => true

you should replace that with:

listen "examle.yourhost.com:8080, :tcp_nopush => true

GitLab should now be up and running.

Advanced Configuration

HTTPS/SSL

Change GitLab configs

Modify /etc/webapps/gitlab/shell.yml so the url to your GitLab site starts with https://. Modify /etc/webapps/gitlab/gitlab.yml so that https: setting is set to true.

Configure HTTPS server of choice

Apache
Node.js

You can easily set up an http proxy on port 443 to proxy traffic to the GitLab application on port 8080 using http-master for Node.js. After you have creates your domain's OpenSSL keys and have gotten you CA certificate (or self signed it), then go to https://github.com/CodeCharmLtd/http-master to learn how easy it is to proxy requests to GitLab using HTTPS. http-master is built on top of node-http-proxy.

Web server configuration

If you want to integrate Gitlab into a running web server instead of using its build-in http server Unicorn, then follow these instructions.

Nginx and unicorn

Install nginx from the official repositories.

Nginx gitlab configuration needs to be copied to nginx configuration directories.

If you installed GitLab from AUR, do:

# cp /usr/share/webapps/gitlab/lib/support/nginx/gitlab /etc/nginx/sites-available

Then edit /etc/nginx/sites-available/gitlab and change all path starting from /home/git/gitlab to /usr/share/webapps/gitlab (there are three occurences) and change the proxy_pass setting to the url you set in /etc/webapps/gitlab/shell.yml, e.g. (for default setting)

   proxy_pass http://localhost:8080;

If you did not use AUR, you need to copy /lib/support/nginx/gitlab to /etc/nginx/sites-available/.

Run these commands to setup nginx:

# ln -s /etc/nginx/sites-available/gitlab /etc/nginx/sites-enabled/gitlab

Edit /etc/nginx/sites-enabled/gitlab and change YOUR_SERVER_IP and YOUR_SERVER_FQDN to the IP address and fully-qualified domain name of the host serving Gitlab.

Make sure the following line exists at the end of the http block in /etc/nginx/nginx.conf:

include sites-enabled/*;

Restart gitlab.target, resque.service and nginx.service.

Apache and unicorn

Install apache from the official repositories.

Configure Unicorn
Note: If the default path is not /home/git for your installation, change the below path accordingly

As the official installation guide instructs, copy the unicorn configuration file:

# sudo -u git -H cp /home/git/gitlab/config/unicorn.rb.example /home/git/gitlab/config/unicorn.rb

Now edit config/unicorn.rb and add a listening port by uncommenting the following line:

listen "127.0.0.1:8080"
Tip: You can set a custom port if you want. Just remember to also include it in Apache's virtual host. See below.
Create a virtual host for Gitlab

Create a configuration file for Gitlab’s virtual host and insert the lines below adjusted accordingly. For the ssl section see LAMP#SSL. If you do not need it, remove it. Notice that the SSL virtual host needs a specific IP instead of generic. Also if you set a custom port for Unicorn, do not forget to set it at the BalanceMember line.

You can use these examples to get you started.

Enable host and start unicorn

Enable your Gitlab virtual host and reload Apache:

/etc/httpd/conf/httpd.conf
 Include /etc/httpd/conf/extra/gitlab.conf

Finally start unicorn:

# systemctl start gitlab-unicorn

Redis

Using a Redis setup different from default (e.g. different address, port, unix socket) requires the environment variable REDIS_URL to be set accordingly for unicorn. This can be achieved by extending the systemd service file. Create a file /etc/systemd/system/gitlab-unicorn.service.d/redis.conf that injects the REDIS_URL environment variable:

[Service]
Environment=REDIS_URL=unix:///run/gitlab/redis.sock

Useful Tips

Fix Rake Warning

When running rake tasks for the gitlab project, this error will occur: fatal: Not a git repository (or any of the parent directories): .git. This is a bug in bundler, and it can be safely ignored. However, if you want to git rid of the error, the following method can be used:

# cd /usr/share/webapps/gitlab
# sudo -u gitlab git init
# sudo -u gitlab git commit -m "initial commit" --allow-empty

Hook into /var

# mkdir -m700 /var/log/gitlab /var/tmp/gitlab
# chown gitlab:gitlab /var/log/gitlab /var/tmp/gitlab
# sudo -u gitlab -i
# cd ~/gitlab
# d=log; mv $d/* /var/$d/gitlab; rm -f $d/.gitkeep; rm -r $d && ln -s /var/$d/gitlab $d
# d=tmp; mv $d/* /var/$d/gitlab; rm -f $d/.gitkeep; rm -r $d && ln -s /var/$d/gitlab $d

Hidden options

Go to Gitlab's home directory:

# cd /usr/share/webapps/gitlab

and run:

# rake -T | grep gitlab
rake gitlab:app:check                         # GITLAB | Check the configuration of the GitLab Rails app
rake gitlab:backup:create                     # GITLAB | Create a backup of the GitLab system
rake gitlab:backup:restore                    # GITLAB | Restore a previously created backup
rake gitlab:check                             # GITLAB | Check the configuration of GitLab and its environment
rake gitlab:cleanup:block_removed_ldap_users  # GITLAB | Cleanup | Block users that have been removed in LDAP
rake gitlab:cleanup:dirs                      # GITLAB | Cleanup | Clean namespaces
rake gitlab:cleanup:repos                     # GITLAB | Cleanup | Clean repositories
rake gitlab:env:check                         # GITLAB | Check the configuration of the environment
rake gitlab:env:info                          # GITLAB | Show information about GitLab and its environment
rake gitlab:generate_docs                     # GITLAB | Generate sdocs for project
rake gitlab:gitlab_shell:check                # GITLAB | Check the configuration of GitLab Shell
rake gitlab:import:all_users_to_all_groups    # GITLAB | Add all users to all groups (admin users are added as owners)
rake gitlab:import:all_users_to_all_projects  # GITLAB | Add all users to all projects (admin users are added as masters)
rake gitlab:import:repos                      # GITLAB | Import bare repositories from gitlab_shell -> repos_path into GitLab project instance
rake gitlab:import:user_to_groups[email]      # GITLAB | Add a specific user to all groups (as a developer)
rake gitlab:import:user_to_projects[email]    # GITLAB | Add a specific user to all projects (as a developer)
rake gitlab:satellites:create                 # GITLAB | Create satellite repos
rake gitlab:setup                             # GITLAB | Setup production application
rake gitlab:shell:build_missing_projects      # GITLAB | Build missing projects
rake gitlab:shell:install[tag,repo]           # GITLAB | Install or upgrade gitlab-shell
rake gitlab:shell:setup                       # GITLAB | Setup gitlab-shell
rake gitlab:sidekiq:check                     # GITLAB | Check the configuration of Sidekiq
rake gitlab:test                              # GITLAB | Run all tests
rake gitlab:web_hook:add                      # GITLAB | Adds a web hook to the projects
rake gitlab:web_hook:list                     # GITLAB | List web hooks
rake gitlab:web_hook:rm                       # GITLAB | Remove a web hook from the projects
rake setup                                    # GITLAB | Setup gitlab db

Backup and restore

Create a backup of the gitlab system:

# sudo -u gitlab -H rake RAILS_ENV=production gitlab:backup:create

Restore the previously created backup file /home/gitlab/gitlab/tmp/backups/20130125_11h35_1359131740_gitlab_backup.tar:

# sudo -u gitlab -H rake RAILS_ENV=production gitlab:backup:restore BACKUP=/home/gitlab/gitlab/tmp/backups/20130125_11h35_1359131740
Note: Backup folder is set in config/gitlab.yml. GitLab backup and restore is documented here.

Migrate from sqlite to mysql

Get latest code as described in #Update_Gitlab. Save data.

# cd /home/gitlab/gitlab
# sudo -u gitlab bundle exec rake db:data:dump RAILS_ENV=production

Follow #Mysql instructions and then setup the database.

# sudo -u gitlab bundle exec rake db:setup RAILS_ENV=production

Finally restore old data.

# sudo -u gitlab bundle exec rake db:data:load RAILS_ENV=production

Running GitLab with rvm

To run gitlab with rvm first you have to set up an rvm:

 curl -L https://get.rvm.io | bash -s stable --ruby=1.9.3
Note: Version 1.9.3 is currently recommended to avoid some compatibility issues.

For the complete installation you will want to be the final user (e.g. git) so make sure to switch to this user and activate your rvm:

 su - git
 source "$HOME/.rvm/scripts/rvm"

Then continue with the installation instructions from above. However, the systemd scripts will not work this way, because the environment for the rvm is not activated. The recommendation here is to create to separate shell scripts for puma and sidekiq to activate the environment and then start the service:

gitlab.sh
#!/bin/sh
source `/home/git/.rvm/bin/rvm 1.9.3 do rvm env --path`
RAILS_ENV=production bundle exec puma -C "/home/git/gitlab/config/puma.rb"
sidekiq.sh
#!/bin/sh
source `/home/git/.rvm/bin/rvm 1.9.3 do rvm env --path`
case $1 in
    start)
        bundle exec rake sidekiq:start RAILS_ENV=production
        ;;
    stop)
        bundle exec rake sidekiq:stop RAILS_ENV=production
        ;;
    *)
        echo "Usage $0 {start|stop}"
esac

Then modify the above systemd files so they use these scripts. Modify the given lines:

gitlab.service
ExecStart=/home/git/bin/gitlab.sh
sidekiq.service
ExecStart=/home/git/bin/sidekiq.sh start
ExecStop=/home/git/bin/sidekiq.sh stop

Troubleshooting

Sometimes things may not work as expected. Be sure to visit the Trouble Shooting Guide.

HTTPS is not green (gravatar not using https)

Redis caches gravatar images, so if you have visited your GitLab with http, then enabled https, gravatar will load up the non-secure images. You can clear the cache by doing

cd /usr/share/webapps/gitlab; bundle exec rake cache:clear

as the gitlab user.

See also