On Oct 30, 2012, at 8:46 PM, Phillip Koebbe wrote:
> On Oct 30, 2012, at 3:38 PM, Lance.Haig wrote:
>> On 30/10/2012 20:09, Phillip Koebbe wrote:
>>> On Tuesday, October 30, 2012 12:16:27 PM UTC-5, Phillip Koebbe wrote:
>>> We are currently using gitlab 2.6 and gitolite 2 with SQLite. I'm working on a procedure to install 3.0 fresh on a new server and "migrate" the database and repositories from the 2.6 installation on the old server. I have 3.0 installed and the gitlab:app:status rake task reports everything is fine. I can log in and create users, projects, etc. It is at this point that I'm not sure exactly what I need to do. Up to now, I've tried a couple of approaches:
>>> 1)
>>> - Copy database
>>> - Migrate
>>> - Copy repositories
>>> - Copy git/.ssh/authorized_keys
>>> + This was problematic because the command line changed and had to be updated
>>> - Copy /home/git/.gitolite/keydir/*
>>> - Copy /home/git/.gitolite/conf/*
>>> There were some permission changes that had to be made, but eventually the status task reported that everything was fine. But when I logged in as a user and tried to change something simple (like the default branch of a repo), I kept getting errors trying to update the gitolite-admin repository. I can't remember what the errors were now, though.
>>> 2)
>>> - Copy database
>>> - Migrate
>>> - Copy repositories
>>> - Follow the instructions to update gitolite as found here: https://github.com/gitlabhq/gitlabhq/wiki/Update-gitolite
>>> When I run the update_keys rake task, I get an error that I'm unable to push to the gitolite-admin repo:
>>> remote: ENV GL_RC not set
>>> remote: BEGIN failed--compilation aborted at hooks/update line 20.
>>> remote: error: hook declined to update refs/heads/master
>>> To git@localhost:gitolite-admin
>>> ! [remote rejected] master -> master (hook declined)
>>> error: failed to push some refs to 'git@localhost:gitolite-admin'
>>> rake aborted!
>>> unable to push gitolite-admin repo
>>> I had to copy the gl-conf from the new gitolite-admin repo to the old one to even get this far.
>>> Should it be possible to do what I'm trying to do? If so, what are the appropriate steps? I looked around but couldn't find any documentation regarding this process, but if I missed it, pointers to it are very much appreciated.
>>> Thanks.
>>> -- Phillip
>>> I got it working (I think) by not using the gitolite-admin repository from the old installation. So the steps were essentially:
>>> Copy and migrate the database
>>> Copy the repositories
>>> Replace the old gitolite-admin repo with the new one
>>> Follow steps 4 and 5 from the instructions for updating gitolite
>>> There may have been some permissions things as well. Anyway, I compared the new installation to the old in side by side browser windows and everything looks correct.
>>> Now I'm really curious about the gitolite-admin repo. What is its purpose and will anything break by starting with a "blank" one from the fresh gitlab 3 install?
>>> I'm still interested in a "proper" way of doing this, so if anyone has any insight, I'd be grateful for the input.
>>> Thanks,
>>> Phillip
>> I am interested in this as well as I want to migrate mine as well.
>> I have an original gitlab installation that has been upgraded over time and I keep having issues when upgrading so I want to start fresh.
>> Lance
> Lance et al,
> As far as I can tell, I have it working correctly. I'm actually pretty new to GitLab, so I'm not entirely sure. But what I see looks good. Here are the steps I followed:
> - Install GitLab 3.0.3 following the instructions on the wiki [1]
> - Stop the service if it's running
> - Might need to delete /home/gitlab/gitlab/tmp/pids/resque_worker.pid. If you get errors starting the service at the end of the process, look to see if this file exists.
> - Copy and migrate the database. Keep in mind that I'm using SQLite. If you are using MySQL, dump/restore instead of copy.
> - Back up /home/git/repositories (those created by the v3 installation)
> - Copy /home/git/repositories from the old installation
> - sudo chmod 0775 /home/git/repositories /home/git/repositories/*
> - Replace old /home/git/repositories/gitolite-admin.git with that from the v3 installation
> - As the gitlab user (sudo su - gitlab) in ~/gitlab
> - bundle exec rake gitlab:gitolite:update_keys RAILS_ENV=production
> - bundle exec rake gitlab:gitolite:update_repos RAILS_ENV=production
> - sudo cp /home/gitlab/gitlab/lib/hooks/post-receive /home/git/.gitolite/hooks/common/post-receive
> - sudo chown git:git /home/git/.gitolite/hooks/common/post-receive
> - As the gitlab user (sudo su - gitlab) in ~/gitlab
> - bundle exec rake gitlab:app:status RAILS_ENV=production
> - Start the service
> I had problems with the step of updating keys because one of the SSH keys in the database had a space in it and only about half of the keys were getting updated. Once I took care of that, all the keys got updated and I was able to create a project, clone, push, etc. I've been working on this process for a couple of weeks now (creating a Chef cookbook to install and update), and I'm really happy I figured this out. I hope this helps you, too.
> -- Phillip
> [1] https://github.com/gitlabhq/gitlabhq/blob/stable/doc/installation.md
Lance et al,
Here is the script I created to automate everything but the copying of the old database and repositories. It expects the database file and repositories to be in specific locations with specific names, and will exit if they are not. I've run this a number of times today in a vagrant with great success.
-- Phillip
===================================================================
#! /bin/bash
V2_DB_FILE=/home/gitlab/gitlab/db/production.sqlite3.v2
V2_REPO_DIR=/home/git/repositories.v2
V3_DB_FILE=/home/gitlab/gitlab/db/production.sqlite3
V3_REPO_DIR=/home/git/repositories
V3_REPO_DIR_BACKUP=/home/git/repositories.v3
# Make sure the database file and repositories exist
if [ ! -f $V2_DB_FILE ];
then
echo -e "\nV2 database file not found at $V2_DB_FILE!\n"
exit 1
fi
if [ ! -d $V2_REPO_DIR ];
then
echo -e "\nV2 repositories not found at $V2_REPO_DIR!\n"
exit 1
fi
# Stop service
sudo /etc/init.d/gitlab stop
# This file really should get deleted when the services are stopped, but for some reason
# it doesn't, so delete it manually
sudo rm /home/gitlab/gitlab/tmp/pids/resque_worker.pid
# Rename the database file and run migrations
echo -e "\nMigrating the database...\n"
sudo rm $V3_DB_FILE # this is the one created by the v3 installation
sudo mv $V2_DB_FILE $V3_DB_FILE
sudo chown gitlab:gitlab $V3_DB_FILE # just to make sure
sudo -i -u gitlab bash -c 'cd /home/gitlab/gitlab && RAILS_ENV=production bundle exec rake db:migrate'
# backup the repositories created in the v3 installation
echo -e "\nMoving repositories around...\n"
sudo mv $V3_REPO_DIR $V3_REPO_DIR_BACKUP
sudo mv $V2_REPO_DIR $V3_REPO_DIR
sudo rm -rf $V3_REPO_DIR/gitolite-admin.git
sudo cp -r $V3_REPO_DIR_BACKUP/gitolite-admin.git $V3_REPO_DIR/
sudo chown -R git:git $V3_REPO_DIR
sudo chmod -R 0775 $V3_REPO_DIR
# Run the rake tasks to update the keys and repos
echo -e "\nUpdating SSH keys...\n"
sudo -i -u gitlab bash -c 'cd /home/gitlab/gitlab && RAILS_ENV=production bundle exec rake gitlab:gitolite:update_keys'
echo -e "\nUpdating repositories...\n"
sudo -i -u gitlab bash -c 'cd /home/gitlab/gitlab && RAILS_ENV=production bundle exec rake gitlab:gitolite:update_repos'
# Make sure the hooks are correct
echo -e "\nMaking sure hooks are correct...\n"
sudo cp /home/gitlab/gitlab/lib/hooks/post-receive /home/git/.gitolite/hooks/common/post-receive
sudo chown git:git /home/git/.gitolite/hooks/common/post-receive
# Sanity check
echo -e "\nChecking application status...\n"
sudo -i -u gitlab bash -c 'cd /home/gitlab/gitlab && RAILS_ENV=production bundle exec rake gitlab:app:status'
# Restart the service
sudo /etc/init.d/gitlab start
echo -e "\nMigration process complete. Please verify that everything works as expected.\n"
