3 posts tagged with "config"

Git을 사용하면서 여러명의 사용자가 하나의 저장소에 push를 할 때 종종 오류와 함께 push가 안되는 상황이 발생한다.

(fatal: failed to write object 와 같은 오류가 발생하는 경우임)

원인은 push할 원격 저장소(.git)의 objects에 파일을 써야 하는데 권한이 없기 때문인데

이미 objects를 A라는 사람의 이름으로 생성을 했는데 B라는 사용자가 같은 파일에 대한 쓰기를 시도(A가 이전에 만든 파일을 수정해서 push)하게 되고

이 때 objects의 파일들이 group이나 others에 대한 쓰기 권한이 없는 상태인 경우이다.

Linux에서 umask를 적절히 변경해서 사용하고 있고 사용자에 대한 기본그룹이 사용자 계정이 아닌 공통으로 사용하는 그룹으로 지정되어 있다면 문제가 없다.

이와 관련한 git의 config가 있는데 바로 core.sharedRepository이다. (참조 : http://git-scm.com/docs/git-config)

옵션에 대한 값은 group (true), all (world, everybody), umask (false) 까지 제공되는데 group이나 true로 했을 경우 저장소 내에 파일 생성시 그룹 쓰기 권한을 세팅하게 되고, all은 모든 사용자가 읽기 가능 + 그룹쓰기 권한, umask나 false로 설정시 umask 값에 따라서 권한 설정을 하게 된다. Default는 umask (false).

 

이 옵션을 설정하지 않았다 하더라도 umask와 기본 그룹 설정만 하면 되니 별 문제가 없는게 일반적인데 가끔 신규 서버 구축시 기본그룹 설정을 잊어버렸다면 써먹을만 하다.

git 자체가 사용자 관리에 대한 제대로 된 기능이 없다보니 그래도 가장 좋은 방법은 사용자 관리가 손쉬운 다른 tool을 함께 사용하는 방법이라고 본다.

GIT 설정을 따로 할 일이 별로 없었는데 repo까지 사용하는 환경에서 자동화 하다보니 필요해졌고, 공식 페이지가 진리라 따로 부연할 꺼리도 없지만 이번에 사용해 본 설정만이라도 정리해보기로 했다. 최소한 이런 설정을 어떤 경우에 사용할 수 있는지라도 설명이 될 수 있을 것 같다.

1. 상황

언급했듯이 repo를 사용하는 환경이다. repo에 대해서 간단히 설명하자면, 여러개의 GIT 저장소를 가지고 빌드를 하거나 개발을 할 때 편의를 제공하기 위해 Google에서 만든 툴로 AOSP (Android Open Source Project)에서 사용되고 있다. Python으로 개발된 script의 모음이고 manifest 내부를 보면 어느 저장소를 어느 경로에 갖다 두는지에 대한 내용들이 주를 이루고 있다.

repo 이외에 Gerrit도 사용하고 있다. Gerrit은 역시 AOSP에서 사용되는 Code Review 툴로 code review 이외에 다른 기능을 위해 사용하는 것도 가능하다. (예를 들면 코드 검증, review 만을 위해서가 아니고)

저장소를 Gerrit에 연결하기 위해서는 Gerrit project로 등록을 해야 하는데, 등록이 되면 저장소 별로 따로 사용자 인증에 필요한 절차를 수행할 필요 없이 Gerrit에서 관리가 가능해진다.

이 부분도 Gerrit의 장점이라고 할 수 있다. GIT을 쓰면서 제일 불편한 것중 하나가 사용자 인증과 관리니까. 또 그래서 여러가지 툴들도 꽤 등장했다. Gitblit, Gitlab, 등등. 서비스에서도 그런 기능을 제공하기도 한다. 많이 쓰고 있는 github이 그 예가 될 것이고.

Gerrit 설정이 갑자기 바뀌면서 repo init을 할 때 command 형태를 변경해야만 했는데 (계정과 gerrit의 port를 추가해야 했다. 일반적으로 별도 설정없이 Gerrit을 그대로 쓰면 계정과 port 정보를 꼭 넣어줘야 하는데 이곳 환경에서는 최초에 없어도 되었었지만, 추가해야 하는 형태로 다시 변경되었음), 문제는 init을 하더라도 manifest 파일에는 계정과 port 정보가 빠져있는 형태의 대표 url만 기록되는 곳에서 발생했다. repo sync 이전에 manifest 파일을 열어서 fetch url 부분을 수정해야만 했다.

2. 조치

원래 나와 같은 위치에 있는 사람들에겐, 대다수가 권한과 정보에 대해서 상당히 인색한 편이다. 아쉬울게 없다. 나만의 해결책을 만들어서 보고하고 마음에 들지 않으면 이슈로 제기하면 되니까. 그래서 처음엔 script를 만들었다. manifest 파일을 수정하는 script. 처음엔 만족스러웠지만 사실 manifest를 수정한다는건 (자동이든 수동이든) 부담도 있고 비효율적이다. 결국은 GIT config를 변경해서 script를 사용하지 않고도 문제를 해결할 수 있었다.

3. GIT config의 종류

Gerrit / repo 모두 GIT을 사용하기 때문에 GIT 설정만으로도 위의 문제를 해결하는게 가능한데, 우선 GIT의 설정은 크게 세 가지로 나뉜다.

local, global, system 설정이 그것인데 각각 저장소 대상 개별 설정, 사용자 대상 설정, 전체 사용자(시스템) 대상 설정을 의미한다.

git config 명령에 option으로 설정 범위를 선택하는게 가능한데 설정된 내용은 각각 $GIT_DIR/config, ~/.gitconfig, $(prefix)/etc/gitconfig 파일에 기록된다.

그러므로 config 명령을 사용하기 싫으면 각각의 파일을 직접 수정해도 무방하다.

4. GIT url insteadof 설정

아래와 같은 형태의 설정을 하면 GIT으로 요청하는 모든 url 중에 해당되는 url을 대체하는게 가능하다

url.<base>.insteadOf (당연히 대소문자 구분)

예를 들어, http://test.com에 대한 요청을 ssh://test@test.com:29418 로 변경하고자 한다면 이렇게 설정하기만 하면 간단히 정리된다.

git config --global url.ssh://test@test.com:29418.insteadOf http://test.com

 

이렇게 해결.

그런데 설정 형식이 조금 못생겼다는 생각을 지울수가 없다. 마침표를 왜 넣지? 다른 방법도 있었을텐데.

이리저리 하다보니 ssh에서 사용할 key를 여러쌍 생성하게 되었다. 이 때 필요에 따라 key를 선택해서 사용해야 한다. (매번 새로 생성하고 복원하고 할 수는 없으니까) 단순히 ssh command를 사용해도 되는 상황이라면 i 옵션을 사용한다. (identity file) 예를 들어 /home/id_dsa 라는 경로와 이름으로 private key가 존재하고 있고, test 계정으로 example.com 서버에 접속하려 한다면, [bash] ssh -i /home/id_dsa -l test example.com [/bash]

이렇게 key를 선택적으로 사용하지만 고정적으로 사용해야 할 때, 예를 들어서 GIT 저장소에 접근할 때 ssh로 해야 하고 일반적이지 않은 key(~/.ssh/id_rsa가 아닌)를 사용해야 한다면 ~/.ssh/config 파일을 수정해서 이용할 수도 있다. config 파일에 아래와 같은 내용을 추가한다. [bash] Host example.com IdentityFile /home/id_dsa [/bash]

끝.