GitLab installation on Fedora 16 (with gitolite)

20gru/1135

GitLab installation on Fedora 16 (with gitolite)

This is updated version of my tutorial for GitLab 2.1. Old version can be found here

GitLab is a wonderful piece of software made by these guys and I'd like to try and install it on Fedora 16 system, as it is most recent Fedora OS at the time I am writnig this. I will base my tutorial on on found here by Déja. Also on my way to successful install I've stumbled upon this description, so I might have gain some experience from it too.

GitLab is Ruby on Rails application and it takes some experience to get it all working because of many, many, many dependencies and packages it needs. It's nothing like simple PHP on Apache installation. But it works and it's worth it, I assure you :)

Let's begin! (by the way: I perform all as root user - again: test environment)

small edit: For people who only want this to work and not necessarily wish to know how and why, I have prepared easy installation scripts in here

another EDIT: GitLab is under heavy development and now it's stable version is 2.1. This means that my guide might be not entirely accurate. Please be cautious. I'll update it soon.

First of all: I am working on virtual machine with brand new and fresh Fedora 16 installed. Minimal installation, just to make sure nothing messes with GitLab. Consider this a test environment.
Once you have your OS ready, update it with yum update and also install some packages you will need on the way:
```
yum install make openssh-clients gcc libxml2 libxml2-devel \
libxslt libxslt-devel python-devel
```
Check what version of ruby is available via yum. GitLab needs at least version 1.9.2
```
yum info ruby
```
on mine it says that the only available version for me is 1.8.7.357 so I have to get it somewhere else.
Using RVM to install Ruby.

EDIT: I have switched to ruby 1.9.3p0 - it works and starts a lot faster, you can use it instead of 1.9.2-p290 in this guide.

I will use RVM, which stands for Ruby Version Manager - brilliant tool, which you can use to install and manage your Ruby with ease. Let's check it out, shall we? (you can install Ruby any way you want - I'll just do this RVM way)

Notice use of --with-openssl switch - without that passenger will complain about Ruby OpenSSL support and won't compile in next step.
```
sudo bash -s stable < <(curl -sk https://raw.github.com/wayneeseguin/rvm/master/binscripts/rvm-installer)

source /etc/profile.d/rvm.sh

rvm install ruby-1.9.2-p290 --with-openssl

rvm use ruby-1.9.2-p290 --default
```
Done. Just like that we have operational Ruby 1.9.2-p290. No RPMs, no going back in time.. nice, huh? :)
Good. Small (nice) surprise: our RPM installed ruby gems for us, so now we only have to get rails gem.
first, just to make sure everything is up to date, execute:
```
rvm all do gem update --system
```
now install rails with:
```
rvm all do gem install rails
```
Now we will install apache2 as a webserver and Passenger for ruby apps deployment. I know that most GitLab tutorials use nginx but I really like apache ;)
```
yum install -y httpd
```
```
rvm all do gem install passenger
```
as I mentioned: I use apache, so I will need passenger module for it:
first some required packages:
```
yum install -y gcc-c++ curl-devel openssl-devel zlib-devel \
httpd-devel apr-devel apr-util-devel
```
an then use
```
passenger-install-apache2-module
```
in order to install it.it gives you 2 information on how to proceed with apache configuration:
- add following lines to /etc/httpd/conf/httpd.conf (at the very end):
```
LoadModule passenger_module /usr/lib/ruby/gems/1.9.1/gems/passenger-3.0.11/ext/apache2/mod_passenger.so
PassengerRoot /usr/lib/ruby/gems/1.9.1/gems/passenger-3.0.11
PassengerRuby /usr/bin/ruby
```
- and then create file named default.conf (or gitlab.conf, or something other you like) in /etc/httpd/conf.d/ containing these lines (remember to change to fit your environment):
```
<VirtualHost *:80>
ServerName www.yourhost.com
DocumentRoot /somewhere/public
<Directory /somewhere/public>
AllowOverride all
Options -MultiViews
</Directory>
</VirtualHost>
```
  (don't worry, we'll come back to this one later)
Now it is time for gitolite. I won't use gitosis because it is not actively developed any more and I found that new GitLab works better with gitolite.install it with
```
yum install -y gitolite
```
now, wasn't that quick? :)
Now we will need to create new gitolite server configuration and in order to do that we have to generate SSH key-pair. But first things first.
To get us started we will create git user with
```
adduser -r -m --shell /bin/bash \
 --comment 'git version control' git
mkdir /home/git/.ssh
chown git:git -R /home/git/.ssh
```
Now we have to create SSH keys pair for him:
```
ssh-keygen -q -o -N '' -t rsa -f /home/git/.ssh/id_rsa
```
To initialize Gitolite we need to first edit it's default configuration file and change default permissions and then initialize it by using git user:
```
sed -i 's/0077/0007/g' /usr/share/gitolite/conf/example.gitolite.rc

su - git -c "gl-setup -q /home/git/.ssh/id_rsa.pub"
```
as mentioned here
Just to make sure that git user has all necessary access rights to his own home directory after we have added SSH keys for him:
```
chown git:git -R /home/git/
```
OK, time for next requirements: python Pip, I will go with method from original post and NOT use yum for that.
```
curl http://python-distribute.org/distribute_setup.py | python
```
and then
```
easy_install pip
```
Database. We need it. We have it already - it was installed on the way as a dependency. Just to make sure check if you have SQLite at list version 3.6 with:
```
yum info sqlite
```
I have 3.7.7.1. All we need is SQLite development package, get it with:
```
yum install -y sqlite-devel
```
And now the main event! GitLabHQ!

I like install web apps in /var/www so we will go there and git clone GitLab:
```
cd /var/www

git clone git://github.com/gitlabhq/gitlabhq.git

cd gitlabhq/
```
we need to use pip to install some python dependencies:
```
pip install pygments
```
and bundler gem so it can later on do most of the work for us:
```
rvm all do gem install bundler
```
you will need one more dependency for bundle install
```
yum install -y libicu-devel
```
finally (remember to be in GitLab directory):
```
bundle install
```
(go get yourself a coffee or other treat - it takes a while)
Redis installation. More about Redis here
```
yum install -y redis
```
and start it with:
```
service redis start
```

Preparing config files.

copy database and gitlab config files from example to working copies:

cp config/gitlab.yml.example config/gitlab.yml
cp config/database.yml.example config/database.yml

DB setup:
And now database setup and import:
```
RAILS_ENV=production rake db:setup
RAILS_ENV=production rake db:seed_fu
```
TIP: if you get errors here, check if you don't have 2 versions of rake installed (I had somehow): 0.8.7 and 0.9.2. If you do, remove older with:
```
gem uninstall rake
```
and choose appropriate version. If you still have problems try:
```
gem install rake
```
-> don't know why, but if it installs again same version of rake, it works.

Apache virtual host configuration should look something like this (I told you, we will get back to that):file: /etc/httpd/conf.d/gitlab.conf

<VirtualHost *:80>
ServerName www.yourhost.com
DocumentRoot /var/www/gitlabhq/public
<Directory /var/www/gitlabhq/public>
AllowOverride all
Options -MultiViews
</Directory>
</VirtualHost>

enable apache user, co you can su into this account:

usermod -s /bin/bash -d /var/www/ apache

prepare SSH key for him (actually use one created for git user)

mkdir /var/www/.ssh

cp -f /home/git/.ssh/id_rsa /var/www/.ssh/ && chown apache:apache /var/www/.ssh/id_rsa && chmod 600 /var/www/.ssh/id_rsa

add localhost to apache user known_hosts with:

ssh-keyscan localhost >> /var/www/.ssh/known_hosts

also give him permissions to his own home directory with:

chown -R apache:apache /var/www/

add apache user to git group with:
```
usermod -a -G git apache
```
check if repositories directory has correct permissions, it should be 770. You can set it with
```
chmod 770 /home/git/repositories/
```
double check your firewall (for example iptables) if it allows connections on port 80 to your server.
important: Apache won't be able o start with SELinux set to "enforcing". Please set it to permissive.
start apache server with:
```
service httpd start
```
Now it all should work. Fingers crossed.. go to http://www.yourhost.com
Now you should be able to log in using these credentials:

user: admin@local.host
pass: 5iveL!fe

and you're in :)

It wasn't so hard, wasn't it? ;)

Troubleshooting:

I get error 500 when I enter particular project and try to get into it's "Admin" section. Don't know how to fix it yet.To fix it, check if repositories directory has correct permissions, it should be 770. You can set it with
```
chmod 770 /home/git/repositories
```
also set this:
```
chmod 770 /home/git
```
If Passenger insists, that we don't have or he can't see grit library (gem actually, as far as I know) even though we have it.

https://github.com/gitlabhq/grit.git (at master) is not checked out. Please run `bundle install` (Bundler::GitError)

Only resolution to this problem I have found is to (as root) change /usr/local/rvm/gems/ruby-1.9.3-p0/gems ownership to apache user with:
```
chown apache:root -R /usr/local/rvm/gems/ruby-1.9.3-p0/gems
```
I know that is not great resolution but it worked for me. If you'll happen to know better way - please let me know, so I can update this tutorial and my knowledge of course ;)

Edit

I found another solution (instead of changing permissions): after first
```
bundle install
```
edit Gemfile and in lines containing "git:" remove everything after first comma, for example:
```
gem "grit", :git => "https://github.com/gitlabhq/grit.git"
```
should be
```
gem "grit"
```
and so on.

then do again
```
bundle install
```
and now passenger shouldn't complain any more.

Be Sociable, Share!

Tagged as: Fedora, git, php, strony www Dodaj komentarz

Komentarze (35) Trackbacks (0) ( subskrybuj komentarze w tej wiadomości )

Andreas
grudzień 21st, 2011 - 23:00

Wish this was easy to install, don’t know how many hours i spent trying to get gitlab to work before i gave up :/

( REPLY )
- Piotrek
  grudzień 21st, 2011 - 23:25
  
  Hi!
  Have you tried doing it following my tutorial or have you just tried to install it on your own and it took so much time? Maybe I can help somehow? :)
  
  ( REPLY )
ZogG
styczeń 2nd, 2012 - 16:39

get this error on bundle install http://pastebin.com/ZBDCeeVp
have centos5

yum list installed |grep sqlite
python-sqlite.x86_64 1.1.7-1.2.1 installed
ruby-sqlite3.x86_64 1.1.0-6.el5 installed
sqlite.i386 3.3.6-2 installed
sqlite.x86_64 3.3.6-2 installed
sqlite.i386 3.3.6-5 installed
sqlite.x86_64 3.3.6-5 installed
sqlite-devel.i386 3.3.6-5 installed
sqlite-devel.x86_64 3.3.6-5 installed

( REPLY )
- Piotrek
  styczeń 3rd, 2012 - 13:20
  
  I don’t have access to Centos box right now, but I’m guessing it might have something to do with either x64 arch not working with sqlite-devel – maybe you have it with wrong architecture installed?
  
  On the other hand this might help: http://stackoverflow.com/questions/6853046/error-installing-sqlite3-gem-via-bundler
  
  ( REPLY )
  - ZogG
    styczeń 11th, 2012 - 11:25
    
    solved that, i was missing something. but now the problem is that i have permission denied when i try to deploy the ssh keys from web
    
    ( REPLY )
    - Piotrek
      styczeń 13th, 2012 - 11:42
      
      Hi,
      Please see my comment below for Narcis’s question. The one with checklist ;)
      
      Piotrek
      
      ( REPLY )
sungwpark
styczeń 5th, 2012 - 14:11

I’ve done everything on this page.
but I can’t see anything when I access the server via browser besides 403 error.

I’ve found there’s no index.html in gitlabhq/public so I made dummy and I don’t see 403 anymore. but all I can see is dummy page that I made.

what should I do more to see that „Git Lab web interface”?

( REPLY )
- Piotrek
  styczeń 6th, 2012 - 17:56
  
  I’m not sure what you set-up is, but there shouldn’t be any index.html in public directory. Can you please try posting your Apache error and access log right after you get 403 error? Only lines corresponding needed.
  Also please double check you Apache virtualhost configuration. You know: paths and all.
  
  ( REPLY )
Narcis
styczeń 6th, 2012 - 16:21

Hi!

First of all, thank you for tutorial. Now, everything is working but I can’t add ssh key, I can’t add projects. Can you please advise me on how to continue?

Thank you!

( REPLY )
- Piotrek
  styczeń 6th, 2012 - 18:31
  
  Hi,
  Please check following things:
  1. is your Apache user has localhost added in his .ssh/known_hosts
  2. does your Apache user can log into gitolite account without password (his private key is working with public key added to gitolite user authorized_keys via gitolite)
  3. does directory /var/lib/gitolite/repositories/ have 770 permissions?
  4. is Apache user in gitolite group?
  
  I’ll think of something else as soon as you’ll check if those things worked or not :)
  
  ( REPLY )
  - Narcis
    styczeń 9th, 2012 - 10:03
    
    Hi Piotrek,
    
    Yes, all 4 points are accomplished.
    As apache:
    -bash-4.1$ ssh gitolite@localhost
    PTY allocation request failed on channel 0
    the gitolite config gives you the following access:el6
    R W gitolite-admin
    @R_ @W_ testing
    Connection to localhost closed.
    
    I don’t understand why adding a ssh key is required and also, I can’t find a proper documentation about gitolite.conf where I think it might also be a problem.
    
    Thank you for your help!
    Narcis
    
    ( REPLY )
    - Piotrek
      styczeń 9th, 2012 - 10:22
      
      Hi,
      SSH key is needed because this is how any user is authenticating with gitolite. All actions like adding SSH key or repository via GitLab interface rely on this authentication, so Apache user has to have ability to connect without password. Adding ‘localhost’ to known_hosts prevents SSH to ask to accept this host permanently – you can see how it works every time you try to connect to any host for the first time. You just have to do it once.
      
      Please check if your configuration in /var/www/gitlabhq/config/gitlab.yml is correct: please check hostname, git user (gitolite) and path to repositories. If you have typed there other hostname then ‘localhost’, for example my-domain.com – you should su – to apache user and SSH to this host too. Same thing as I described earlier with accepting new host to known_hosts.
      
      Also you might want to check log files right after trying to add SSH key via GitLab:
      - apache error log
      - /var/www/gitlabhq/log/production.log
      
      Please note, that apache user with his SSH key has to have admin rights (RW) for gitolite-admin repo in order to manage access by adding SSH keys and repositories entries in gitolite.conf
      
      As for gitolite.conf documentation, please try here: http://sitaramc.github.com/gitolite/conf.html
      
      Please let me know if it helped :)
      
      Piotrek
      
      ( REPLY )
cmihai
styczeń 10th, 2012 - 09:07

Hi, and thanks for your tutorial. I faced the same issue as Narcis and managed to fix it by cleaning /tmp/git* (there was a lock file owned by a different user than apache). See https://groups.google.com/group/gitlabhq/browse_thread/thread/4b21eef9a2e72c25 for details.

My installation was on RHEL 6.1 x86_64, but the concept is similar.

Is there a way to turn on „verbose” logging for gitlab? production.log just spits out rails log files. There seems to be no „ruby” log file. error_log isn’t much help either.

( REPLY )
- Piotrek
  styczeń 10th, 2012 - 09:17
  
  Hi,
  Your resolution to Narcis problem might actually work :) thanks for sharing :)
  
  As for logs.. I didn’t have to increase debugging, but try changing config.log_level to :debug (simply uncommenting) in file: /var/www/gitlabhq/config/environments/production.rb
  
  If it won’t work please ask about it on GitLab page here: https://github.com/gitlabhq/gitlabhq
  
  Best regards,
  Piotrek
  
  ( REPLY )
MikeS
styczeń 11th, 2012 - 16:19

Thank you!!!

( REPLY )
ZogG
styczeń 18th, 2012 - 18:45

ok, i have it working and kicking, but the problem is that when i use
„admin_uri: gitolite@localhost:gitolite-admin”
i get error that there is no git repo, but when i change to
„admin_uri: gitolite@localhost:repositories/gitolite-admin”
it does work, but i can publish anything =[

( REPLY )
- Piotrek
  styczeń 23rd, 2012 - 22:28
  
  Hi,
  Sorry for late response – I had a lot to take care of :/ Did you have any luck with your problem?
  
  By publish you mean create a new repository or push files to one?
  
  Also, I have trouble reproducing this error so I might need some additional info from you. I don’t really know where to start :/
  
  Can you add SSH key? Are your paths same in file system and in config? This might seem stupid question, but typos happen’ to good people, you know ;)
  
  Regards,
  Piotrek
  
  ( REPLY )
  - ZogG
    styczeń 29th, 2012 - 09:00
    
    solved it by adding command=”…..” to authorized keys for apache,
    now i have the problem that after any git command i need to make chmod 770 on repositores directory, the last thing to solve =[
    
    ( REPLY )
    - ZogG
      styczeń 29th, 2012 - 09:20
      
      solved it, you need to set umask in gitolite config to 0027, so it would have permissions to read for new files to the users from same group \o/
      
      ( REPLY )
      - Piotrek
        luty 7th, 2012 - 20:50
        
        Great to hear that – thanks for info :)
zghot
styczeń 23rd, 2012 - 18:06

Hi,

I’ve got error while executing the following step

RAILS_ENV=production rake db:setup

error:
rake aborted!
Connection refused – Unable to connect to Redis on 127.0.0.1:6379

( REPLY )
- Piotrek
  styczeń 23rd, 2012 - 22:22
  
  Hi,
  Sorry to say that, but right now I don’t really know how to help you… You see, when you clone from github, you are cloning bleeding edge, newest compilation. This means, that there might be some bugs or it might be messed up completely. I have to update my guide to cover new stable version 2.1 (stable).
  
  Sorry for that.
  
  Right now please look at update guide from 2.0 (my guide) to 2.1 (with Redis) in here: https://github.com/gitlabhq/gitlabhq/wiki/From-2.0-to-2.1
  
  I’ll update my guide really soon, promise ;)
  
  Please
  
  Piotrek
  
  ( REPLY )
zghot
styczeń 26th, 2012 - 10:43

Thank you very much. You’re awesome !

My gitlabhq is successfully installed on freshly installed Fedora 16 and Ruby 1.3.9-p0 (using rvm ’cause I couldn’t find the its spec)

Only one more thing I had to do to make it works is to install git („yum install git”) at the beginning.

( REPLY )
Ajit
styczeń 28th, 2012 - 16:26

any help
Forbidden

You don’t have permission to access / on this server.

Additionally, a 404 Not Found error was encountered while trying to use an ErrorDocument to handle the request.
Apache/2.2.15 (CentOS) Server at 192.168.1.12 Port 80

( REPLY )
- Piotrek
  luty 7th, 2012 - 20:50
  
  Hi,
  It sounds like you have some problem with Apache virtualhost configuration, maybe something misspelled in directory path? On the other hand you might be pointing your webroot (/) to either non-exiting folder, folder with permissions not allowing apache user to access it or your virtualhost configuration is point on wrong directory – I mean, not „public” in GitLab folder.
  
  Please see what is showing in apache logs (access/error) for your virtualhost – maybe you’ll find a clue there.
  
  Piotrek
  
  ( REPLY )
moonie
luty 7th, 2012 - 17:26

I’m getting a 404 when trying to add a project, it works sometimes and sometimes it doesn’t. Seems to be related to files in /tmp. I’ve installed using the new ruby and followed this how-to to the letter.

( REPLY )
- Piotrek
  luty 7th, 2012 - 20:45
  
  Hi,
  It might sound obvious, but try clearing /tmp folder. It worked for me and I think someone on GitLab support forum as well. Also please check your apache logs for this 404 error and see if there is any info about what exactly is causing it. It might help to check GitLab production log also.
  
  Piotrek
  
  ( REPLY )
???
luty 10th, 2012 - 19:39

I’m see this error in the apache error log and can’t figure out what I need to do. I have rerun bunlde install and bundle update and it makes no difference.

Exception PhusionPassenger::UnknownError in PhusionPassenger::Rack::ApplicationSpawner (https://github.com/gitlabhq/gitolite-client.git (at master) is not checked out. Please run `bundle install` (Bundler::GitError)) (process 1895, thread #):

( REPLY )
- Piotrek
  luty 10th, 2012 - 23:05
  
  Hi. This is what worked for me: in your GitLab directory find file named Gemfile and edit it. Search for lines which have reference to package download path and duplicate them, comment out original and delete this reference from copy so it will look like all other package entries. There is one for git/grit and 2 or 3 more. You can disable them one by one to see which are problematic.
  
  Good luck :)
  
  Piotrek
  
  ( REPLY )
Ashwin
luty 25th, 2012 - 18:14

Hi Piotrek,

you have made a wonderful work here. Installation went fine.

When I try to create a new project I am having this error:

Application cant get access to your gitolite system.
1. Check ‘config/gitlab.yml’ for correct settings.
2. Make sure web server user has access to gitolite. Setup tutorial
3. Try:
sudo chmod -R 770 /home/git/repositories/
sudo chown -R git:git /home/git/repositories/

I do not understand how to proceed here. Any thoughts?
I am running Fedora 15.

( REPLY )
Piotrek
luty 25th, 2012 - 22:58

Hi,
Check your file gitlab.yml, which is located in (according to my tutorial) in /var/www/gitabhq/config directory. There is line saying: host: localhost
In my installation it works for me, but you may have to change ‘localhost’ to your_hostname.

Directory /home/git/repositories has to be accessible by Apache user, who should be in ‘git’ system group. To make it accessible you have to set directory permissions, so they will allow that. This is what chmod does. Chown just makes sure that this directory (and subdirectories) are owned by git user and his group.

Application (GitLab) is run by Apache user, so you have to make sure that this user can log in via SSH to git user account with SSH key. To check it, please log in as Apache user or if you are root:
su – apache
and try command: ssh git@localhost or ssh git@{your_hostname}

If it succeeds and does not prompt for password, then it is working correctly and I would have to have more details to help you.

I hope you’ll get it working in no time :)

Best Regards,
Piotrek

( REPLY )
VL
marzec 20th, 2012 - 23:27

Would you mind having a look at this page http://66.84.10.89/

after more than 20 hours I still cant figure out what’s the problem.

I’ve tried both your solutions with giving rights to apache and „edit Gemfile and in lines containing „git:” remove everything after first comma, for example:” but it dont make any difference.

Thanks

( REPLY )
Harish Pillay
kwiecień 6th, 2012 - 16:54

Thanks for writing this up. I started with installing gitosis and that is working just fine.

As I am also working with openshift.redhat.com, they use ruby and I am concerned that in pulling in the version of ruby that you’ve described here for gitlab, I don’t want to have to worry about the newer version not working with openshift.

I will experiment with this anyway, and report back here (and on my blog).

Thanks for documenting this.

Harish

( REPLY )
Daniel Craig Jallits
maj 10th, 2012 - 07:28

Has anyone ever encountered „uninitialized constant Linguist::BlobHelper”. I am doing this on a Media Temple DV4 box which is CentOS 5.

I did a Google search and someone else is having this same problem within the last 24 hours, but they just posted their error anonymously in pastebin. You can see their post here: http://pastebin.com/SKrqnEC3

( REPLY )
Daniel Craig Jallits
maj 10th, 2012 - 16:51

I may also be worth mentioning that if you are doing this in an environment that uses Plesk Panel the only directory and its contents that need chown apache:apache is the /var/www/gitlabhq directory. Otherwise, if you follow these instructions all your Plesk controlled virtual hosts will loose their Plesk assigned owner:group permissions.

( REPLY )

wasil.org Abandon the search for Truth; settle for a good fantasy