Hi,
Quoting Pirate Praveen (2016-02-11 16:58:56)
> You can use,
>
> systemctl start gitlab.target
>
> as init script has problems with systemd. The installation is complete otherwise.
>
> I added systemd unit files already and I will add a check for systemd to fix the bug.
thanks, that worked as a temporary workaround!
> You'll need to run them as gitlab user and export all variables defined in /etc/gitlab/gitlab-debian.conf
thanks, this was *very* valuable knowledge as without it I would probably be
stuck by now. So I tried this out in practice now and indeed the right steps to
take seem to be:
1. Rename your old database to gitlab_production and set the user gitlab as
its owner and the owner of all its tables, sequences and views
2. Copy your old repository directory to /var/lib/gitlab/repositories/
3. Start gitlab using the above systemctl command
4. Check its status via:
$ su gitlab
$ cd
$ export $(cat /etc/gitlab/gitlab-debian.conf | xargs)
$ rake gitlab:check RAILS_ENV=production
5. The output of above command then will tell you all remaining things to take
care of, like running:
$ sudo chmod -R ug+rwX,o-rwx /var/lib/gitlab/repositories/
or
$ sudo -u gitlab -H /usr/share/gitlab-shell/bin/create-hooks
or
$ sudo -u gitlab -H bundle exec rake db:migrate RAILS_ENV=production
This is extremely helpful!
Some general notes:
- it seems to not be necessary to use the "bundle exec" prefix
- but it is absolutely necessary to be in the home directory of the gitlab
user (/var/lib/gitlab) as the gitlab user when executing the "rake" commands
- exporting the environment variables from /etc/gitlab/gitlab-debian.conf is
mandatory as well and there'll be error messages without it
But this was surprisingly painless in the end! My gitlab instance seems to be
up and running again :)
Thanks!
cheers, josch
Attachment:
signature.asc
Description: signature