IRC channel Guidelines and F.A.Q.

First and foremost is the #gitlab channel on freenode motto.

Have a question? Don't ask to ask! Just ask, and wait to see if anyone answers.

That being said please review How To Ask Questions The Smart Way by Eric S. Raymond. Our IRC community is open, friendly, and helpful. This community is not operated by GitLab staff but by users of GitLab just like you. Some guidelines follow.

• We treat each other with respect as peers and ask you to do the same.
• Some members hang out in this channel 24x7 which means there can be significant delays (usually no more than 24 hours) before you see an answer to your question. If that is the case please be patient and come back to your chat client later.
• When sharing logs or version information about your installation be sure to use an online paste service and providing a link so other channel users can review your information. It is recommended that you edit your pastes to remove personal information.
• If you have a registered nickname with freenode then we can use MemoServ to contact you if you log out before your issue can be addressed. Be aware that this will not always be the case. Hanging out in the channel will be your most reliable form of getting help.

Frequently Asked Questions

Have issues with the GitLab channel?

Contact one of the community managers who hang out in the channel: newton, dblessing, sag47.

My GitLab installation isn't working!

If you're having trouble visualizing the overall architecture of GitLab then see the GitLab Architectural Overview doc.

gitlabhq provides rake tasks with which you can provide users in the IRC channel with version information and run a quick check on your configuration to ensure it is configured properly within the application. See maintenance rake tasks. In a nutshell we ask that you do the following.

sudo -i -u git
cd gitlab
bundle exec rake gitlab:env:info RAILS_ENV=production
bundle exec rake gitlab:check RAILS_ENV=production

Make sure that all tasks in the check pass. If you have trouble then paste the output of gitlab:env:info and gitlab:check to a paste site and link us in the channel so we may look it over. It is recommended to remove any sensitive information from these tasks or logs that you post should you feel the need. While security through obscurity is not a method to rely on you don't want to give out LDAP users or the name of your server. Such things should be edited before posting unless you otherwise are not concerned.

Check your permissions in addition to the gitlab check

The following command will find any files or directories not owned by the git user. If the result of the following command is no output then it ran successfully.

find /home/git \( ! -uid $(id -u git) -a ! -gid $(id -g git) \)

If files are found by the above command then some of your files have incorrect permissions. To correct the issue run the following command.

find /home/git \( ! -uid $(id -u git) -a ! -gid $(id -g git) \) -exec chown git\: {} \;

What are common locations for GitLab logs?

Note: ~git/ is shorthand for /home/git.

gitlabhq (includes unicorn and sidekiq logs)

• ~git/gitlab/log/ contains application.log, production.log, sidekiq.log, unicorn.stdout.log, githost.log, satellites.log, and unicorn.stderr.log normally.

gitlab-shell

• ~git/gitlab-shell/gitlab-shell.log

ssh

• /var/log/auth.log auth log (on Ubuntu).
• /var/log/secure auth log (on RHEL/CentOS).

nginx

• /var/log/nginx/ contains error and access logs.

Apache httpd

• Explanation of apache logs.
• /var/log/apache2/ contains error and output logs (on Ubuntu).
• /var/log/httpd/ contains error and output logs (on RHEL/CentOS).

redis

• /var/log/redis/redis.log there are also logrotated logs there.

clone over ssh asks for git password

There's likely an issue with the permissions on ~git/.ssh/authorized_keys. See OpenSSH F.A.Q. 3.14. In a nutshell assuming you set up GitLab with default settings you should set/have the following permissions.

chmod go-w /home/git /home/git/.ssh
chmod 600 /home/git/.ssh/authorized_keys
chown git\: $HOME/.ssh/authorized_keys

You can test your GitLab ssh connection with the following commands and output.

$ ssh [email protected]
PTY allocation request failed on channel 0
Welcome to GitLab, Sample User!
Connection to gitlab.example.com closed.

If you get a Welcome to GitLab, Anonymous! message then it is likely because you manually modified authorized_keys for the git user. You should only add SSH keys through the GitLab web interface. In Ubuntu users have experienced the Welcome to GitLab, Anonymous! by having multiple versions of ruby installed. To check for multiple versions of ruby run the following one liner.

echo "$PATH" | tr ':' '\n' | sort -u | while read x;do [ -f "$x/ruby" ] && ( echo -n "$x/ruby - ";$x/ruby --version );done

It is recommended to attempt to remove versions other than what is intended.

There are times when Welcome to GitLab, Anonymous! is not an error. When deploy keys are used ssh to gitlab will respond with Welcome to GitLab, Anonymous!. This is actually intended because it's a readonly anonymous deploy key.

Since you're on the topic of hacking SSH it is recommended to implement sag47's solution for denying passwords over SSH and giving users a friendly message as to what they did wrong.

There is also an issue with keys being out of sync for unknown reasons. One can check authorized_keys against MySQL.

select id,user_id,title from gitlab.keys;

There is a rake task to fix that.

bundle exec rake gitlab:env:info RAILS_ENV=production

SSH connection closes immediately with no message

If you have a shell set other than bash then gitlab-shell will not work either. Check /etc/passwd and see what shell the git user is using. If not bash then run the following command.

usermod -s /bin/bash git

Can I run multiple instances of GitLab on the same server?

Yes, some steps are required to do so.

• Each instance must be in a different user. This way each instance can manage authorized_keys.
• Must have separate databases. MySQL/Postgres database must be different for each server.
• Must have separate queues. Connect to redis on each server in different keyspaces using connection strings like, redis://localhost:6379/0 and redis://localhost:6379/1. In this is lightly documented in redis SELECT and redis.conf (search for databases).
• The repositories locations gitlab-satellites must be different between the two instances.
• Other than that Apache and nginx both support multiple virtual hosts and server name indication for SSL.

See GitLab Architecture Overview for a more thorough description of GitLab and the processes it uses.