418b1b81b1
Use 'set -e' to let the script fail when any command fails. This allows us to remove the "command || exit 1" constructs. |
||
---|---|---|
.. | ||
conf | ||
missing-sources | ||
patches | ||
po | ||
source | ||
tests | ||
adduser.sh | ||
changelog | ||
compat | ||
config | ||
control | ||
copyright | ||
gitlab-check.sh | ||
gitlab.docs | ||
gitlab.gitlab-mailroom.service | ||
gitlab.gitlab-sidekiq.service | ||
gitlab.gitlab-unicorn.service | ||
gitlab.gitlab-workhorse.service | ||
gitlab.init | ||
gitlab.links | ||
gitlab.lintian-overrides | ||
gitlab.service | ||
gitlab.templates | ||
gitlab.triggers | ||
grantpriv.sh | ||
install | ||
maintscript | ||
postinst | ||
postrm | ||
rake-tasks.sh | ||
README.Debian | ||
ruby-gitlab-ce.git.docs | ||
rules | ||
upstream-file-count-check.sh | ||
watch |
Debian specific changes in gitlab ================================= 1. Redis connection: redis-server package in debian follows upstream default and listens on tcp port 6379. So gitlab package in debian is configured to use tcp sockets. gitlab developers recommend using unix sockets. You can change to using unix sockets by changing the following configuration files. /etc/redis/redis.conf and /etc/gitlab/resque.yml 2. wiki backend: debian package uses gollum-rugged_adapter whereas gitlab upstream still use gollum-grit_adapter. grit is no longer maintained and grit developers recommend switching to rugged. gollum-lib developers have announced their intention to switch to rugged_adapter by default and this is in progress. 3. default paths: debian package has changed some default values for paths which you can see at /etc/gitlab/gitlab-debian.conf 4. database: gitlab package configures postgresql database with peer authentication. 5. gem versions: some gem dependency requirements are relaxed to work with their packaged version in debian. You can find the list of gems required by gitlab and their corresponding package versions in debian at http://debian.fosscommunity.in/status/?appname=gitlab&sort=satisfied 6. vendored js files: some embedded javascript files in vendor/assets/javascripts are replaced by their packaged version. 7. root directory of rails is read only (/usr/share/gitlab); following symbolic links are added to enable write access to gitlab app > config -> /etc/gitlab > Gemfile.lock -> /var/lib/gitlab/Gemfile.lock > log -> /var/log/gitlab > builds -> /var/log/gitlab/builds > tmp -> /run/gitlab > /run/gitlab/cache -> var/lib/gitlab/cache > public -> /var/lib/gitlab/public > shared -> /var/lib/gitlab/shared > db -> /var/lib/gitlab/db > /usr/share/gitlab/.secret -> /var/lib/gitlab/.secret 8. ssl certificates: This package tries to use letsencrypt package to obtain ssl certificates, if it is installed (via Recommends). If letsencrypt is not required, you can copy ssl certificate and key to /etc/gitlab/ssl as gitlab.crt and gitlab.key. If letsencrypt option is selected, symbolic links are added for certificates obtained using letsencrypt to /etc/gitlab/ssl. 9. exim compatibility issue: If you use exim as your mta, then see https://github.com/gitlabhq/gitlabhq/issues/4866#issuecomment-145784636 Useful diagnostics ================== Upstream documentation will instruct to run commands like the following: $ sudo -u gitlab -H bundle exec rake XXX RAILS_ENV=production Where XXX is something like "db:migrate", "gitlab:check" or "gitlab:env:info". In Debian, the rake command has to be called by the gitlab user from app home directory /usr/share/gitlab and with the environment variables from /etc/gitlab/gitlab-debian.conf set. So above command could be run like: # su gitlab $ cd /usr/share/gitlab $ export $(cat /etc/gitlab/gitlab-debian.conf) $ rake XXX RAILS_ENV=production One useful command to run in this environment is: $ rake gitlab:check RAILS_ENV=production Which will output helpful diagnostics about the state of your system including how to fix possible problems. Another one is: $ rake gitlab:env:info RAILS_ENV=production To see service status with systemd, you can use: $ systemctl status gitlab.target $ systemctl status gitlab-unicorn.service -l $ systemctl status gitlab-sidekiq.service -l $ systemctl status gitlab-workhorse.service -l $ journalctl -xn It is advised to attach the output of above commands to bugreports. Migrating from non-Debian gitlab ================================ 0. Backup everything you don't want to loose like: - the postgresql database used by your gitlab instance - the repositories/ directory - the public/uploads/ directory - your .ssh/authorized_keys 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. Copy your old public/uploads/ directory to /var/lib/gitlab/public/uploads/ 4. Copy your old .ssh/authorized_keys to /var/lib/gitlab/.ssh/authorized_keys 5. Start gitlab using `systemctl start gitlab.target` 6. Check the status of your installation using gitlab:check (see section above). The output of that command will tell you the necessary remaining fixes. You might be told to run: $ sudo chmod -R ug+rwX,o-rwx /var/lib/gitlab/repositories/ $ sudo -u gitlab -H /usr/share/gitlab-shell/bin/create-hooks $ sudo -u gitlab -H bundle exec rake db:migrate RAILS_ENV=production See the last section of how to execute the db:migrate command. Resetting admin password without web interface ============================================== # su gitlab $ cd /usr/share/gitlab $ export $(cat /etc/gitlab/gitlab-debian.conf) $ rails console production irb(main):001:0> user = User.where(admin: true).first irb(main):002:0> user.password = 'secret_pass' irb(main):003:0> user.password_confirmation = 'secret_pass' irb(main):004:0> user.save!