이 문제의 상황을 정리해 보면 GitLabHQ는 Github와 동일하게 저장소에 대한 접근권한을 인증받기 위해서 SSH 키를 등록합니다. 사용자 계정에 SSH키를 등록하기 전에는 문제없이 프로젝트를 생성할 수 있지만 SSH키를 등록하고 나면 프로젝트 생성 후에 완료페이지 대신에 404페이지가 나오면서 프로젝트 생성에 실패합니다. 실제 내부를 보면 Gitolite의 저장소는 생성되고 Gitolite의 설정파일(Gitolite가 설증을 관리하는 gitolite-admin저장소의 conf/gitolite.conf 파일)에 저장소에 대한 접근권한도 설정되지만 GitLabHQ의 데이터베이스에는 기록이 되지 않아서 프로젝트 리스트에 나타나지 않습니다. 그리고 SSH키를 등록하기 전에 생성한 프로젝트에 접근하면 500에러가 발생합니다.(SSH키를 등록하기 전에는 해당 저장소의 git설정을 하는 안내페이지가 나타납니다.)
이 문제의 원인을 파악하기 위해서 수없이 삽질을 한 끝에 원인은 알아냈습니다. Gitolite 저장소가 생기는 위치인 /home/git/repositories를 보면 새로 생성한 .git 저장소 디렉토리의 권한이 770이 아닌 700으로 생성되었습니다. GItLabHQ의 구조상 git이라는 계정으로 gitolite를 관리하고 git그룹의 현재 사용자 계정을 추가하고 /home/git/repositories의 권한은 770으로 주어 그룹계정으로 저장소 디렉토리의 권한을 가지는 구조로 되어 있습니다. 하지만 새로 생긴 저장소가 700으로 생성되기 때문에 접근권한이 없어서 오류가 생긴 것입니다. SSH키를 등록하기 전에는 GitLabHQ의 디비에만 들어가고 실제 저장소는 생성하지 않기 때문에 이상없이 동작하지만 SSH키를 등록하면 저장소를 생성하면서 마찬가지로 700으로 만들기 때문에 500에러가 발생한 것입니다.
원인은 알아냈지만 해결책을 알지 못해서 오류인줄 알고 GItLabHQ의 저장소에 이슈를 등록했더니 Dani님이 답변을 달아주셨습니다.(덕분에 해결!!)
git 계정의 홈디렉토리에서 /home/git/.gitolite.rc파일을 보면 다음과 같은 부분이 있습니다.
# ------------------------------------------------------------------------------
# most often used/changed variables
# ------------------------------------------------------------------------------
$GL_WILDREPOS = 0;
$PROJECTS_LIST = $ENV{HOME} . "/projects.list";
# $WEB_INTERFACE = "gitweb";
# $GITWEB_URI_ESCAPE = 0;
$REPO_UMASK = 0077;
마지막의 $REPO_UMASK의 값이 0077 (기본값)로 되어 있어서 저장소 디렉토리의 권한이 700으로 생성된 것입니다. $REPO_UMASK의 값을 0007로 변경하면 오류없이 프로젝트를 수정할 수 있습니다.
Gitosis나 Gitolite는 사용자가 특정 유저 (여기선 git)으로 접근하는 것을 기준으로 하고 있습니다. 퍼미션을 770으로 하여 해당 문제를 피해갈 수 있겠지만 그렇게 할 경우 이 도구를 ACL로서 사용한 의미가 없어집니다.프로젝트별 권한을 기준으로 관리할 수 없죠. 그리고 Dvcs를 파일 시스템의 그룹에 의존해서 관리하는 것은 리포지토리를 망가뜨릴 수 있습니다. 그룹에 속한 사람 중 누군가 700으로 오브젝트 파일을 생성하게 되고 이 파일들을 변경할 수 없다는 것울 발견하는 것은 오랜 후가 됩니다. 특히 GIT과 같이 새로 파일을 만들고 변경하지 않는 시스템에선 다른 사용자가 새로 만든 디렉토리가 변경할 때가 되어서야 문제가 발견되죠. 저는 사용자를 신뢰해야하는 시스템을 쓰고 싶지않아서 사용자는 모두 git아이디를 쓰면서 rsa로 누군지 확인하는 Gitosis/gitolite의 일반적인 용례를 따르겠습니다.
그건 Gitosis나 Gitolite의 기준으로 봤을 때 그런 것 아닌가요?
GItLabHQ는 Rails를 통해서 Gitolite를 관리하기 때문에 Rails를 구동시키는 계정이 Gitolite의 저장소를 핸들링 할 수 있어야 합니다. 770으로 문제를 피해간다기 보다는 GitLabHQ의 구성상 웹이 Gitolite에 접근하기 위해서는 그룹계정에 포함시켜서 그룹권한으로 관리하도록 되어 있습니다.
물론 각 사용자는 RSA를 사용하지만 그 전체관리는 레일즈를 구동시킨 계정이 하는 것이지요.
이렇게 했을 때도 말씀하시는 문제가 발생한다면 이건 GitLabHQ의 접근이 잘못되었다고 밖에 볼 수 없을 듯 한데요.
아. 사용자들은 git나 gitlite아이디로 로그인하는 것인가요? 770은 순수하게 GitLab를 위해서 쓰는 것이지요?
저는 770으로 해두고 사용자들도 각자 "리눅스" 계정을 쓰는 것으로 오해를 했습니다. 제가 잘못생각했네요.
GitLabHQ가 목록이나 리포지토리를 읽을 수 있어야 할테니 권한이 있어야 겠네요. 저는 이런 경우에 같은 사용자로 웹 앱을 켜는 방식을 사용하고 있긴 한데요. 이런 경우에는 그룹을 이용하는 방법이 나쁘지는 않은 것 같습니다.
예 사용자들은 SSH로 로그인합니다.
이렇게 하면 안되는건가 했는데 다행이네요 ㅎ