머가필요해

Git 계정 관리에 대해서 알아보면서 이미 한 번 SSH Public Key에 대해서 살펴보았었다.
   - http://whatwant.tistory.com/395


이번에는 예전에 살펴보지 못한 부분들에 대해서 알아보고자 한다.


1. Server : ssh daemon 설정

   - 만약 Git Server에서 Public Key로 접속하는 것을 막아버리고 싶으면 어떻게 해야 힐까?
   - [ /etc/ssh/sshd_config ] 파일을 살펴보면 된다.


   - 그 외에도 다양한 설정들을 살펴볼 수 있고, 손 볼 수 있다.


2. Client : RSA vs DSA

   - SSH Public Key 파일을 생성할 때 보통 RSA 타입을 사용했다.
   - [ ssh-keygen ] 명령어를 보면 DSA 타입에 대해서도 나온다.
   - RSA는 무엇이고 DSA는 무엇일까?

   ※ 아래 내용은 위키피디아(http://ko.wikipedia.org/)의 내용을 많이 참고하고 있습니다.

   ① RSA
      - 1977년 로널드 라이베스트, 아디 샤미르, 레오널드 애들먼의 연구에 의해 체계화 된 공개키 암호시스템이다.
      - (Ron Rivest), (Adi Shamir), (Leonard Adleman) 3명 연구원의 이름 앞글자로 RSA 이름이 지어졌다.
      - 1983년에 발명자들이 소속되어 있던 MIT에 의해 미국에 특허로 등록되었고, 2000년 9월 21일에 그 특허가 만료되었다.
      - RSA 암호체계의 안정성은 큰 숫자를 소인수분해하는 것이 어렵다는 것에 기반을 두고 있다.

   ② DSA (Digital Signature Algorithm)
      - RSA와 마찬가지로 비대칭형 암호화 방식이다.
      - ElGamal 알고리즘을 이용하여 NIST(미국립표준기술연구소)에서 개발한 전자 서명방식이다.
      - 나중에 DSS(Digital Signature Standard)로 이름이 변경된다.
      - 보통 웹인증서에서 사용하는 방식이다.

   - 암호화 속도는 비슷하지만, 키 생성은 DSA가 빠르고 검증속도는 RSA가 빠르다.
   - RSA는 원문을 개인키로 암호화 해야 서명이 가능하지만, DSA는 그렇지 않다.
   - DSA는 전자서명 여부에 따라 예/아니오로 간단하게 사용한다.

   - 개인적으로 궁금한 것은 DSA가 RSA 보다 더 좋은 것인지 확인하고 싶었다.
   - 결론적으로는 뭐 그냥 그렇다. 그냥 RSA를 사용하게 하는 것이 무난하다는 판단이다.


3. SSH Public Key 활용하기

   - A 라는 사용자가 [ssh-keygen -t rsa ] 명령으로 [ id_rsa / id_rsa.pub ] 파일을 생성했다고 해보자.
   - 다른 PC에서 SSH Public Key를 이용해서 ssh 접속을 하고자 한다면 어떻게 할까?!

   - Key 파일을 생성한 PC 에서 인증을 위해 사용할 Public Key를 등록해야 한다.
   - [ cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys ]
   - cp가 아니고 뒤에 첨부하는 식으로 처리한 이유는, 여러개의 Public Key를 등록하는 경우도 있기 때문이다.

   - 참고로 각 파일에 필요한 권한은 다음과 같다.



4. 두 대의 PC에서 개발

   - 개발 PC 한 대에서 Key 파일을 하나 생성한 후 Git Server에 등록을 했다고 해보자.
   - 만약 노트북을 한 대 받아서 그곳에서도 개발을 해야한다면 어떻게 해야할까?

   - 가장 손 쉬운 방법은 노트북에서도 Key 파일을 하나 생성해서 추가로 Git Server에 등록을 하는 것이다.
   - 그런데, 추가 등록하지 않고 기존에 생성한 Key 파일을 재활용할 수 있는 방법은 없을까?

   ① Copy

      - [ ssh-keygen -t rsa ] 명령으로 Key 파일을 생성하면,
        [ ~/.ssh/ ] 디렉토리 밑에 id_rsa, id_rsa.pub 파일이 생성된다.
      - 유저에게 필요한 파일은 [ id_rsa ]이고, 서버에 등록을 할 것은 [ id_rsa.pub ] 파일이다.

      - 그런데 이 유저가 다른 PC에서 서버에 접근을 하려고 하는 순간 고민이 생긴다.
      - 전에 사용하던 PC에서는 편하게 Public Key로 인증을 했는데, 이 PC에서는 인증이 안되는 것이다.

      - 사실 정말 간단히 모든 것이 해결된다.
      - 기존 PC에서 생성한 [ id_rsa ] 파일을 [ ~/.ssh/ ] 디렉토리 밑으로 복사해 놓으면 끝이다.

      - 그런데, 이 새로운 PC에 이미 생성해서 사용하고 있는 [ id_rsa ] 파일이 있으면 어떻게 해야할까?

   ② Multi Key

      - Public Key 파일을 관리하기 위해서 별도 설정을 할 수 있다.
      - [ ~/.ssh/config ] 파일에 원하는 내용을 넣으면 되는 것이다.


   - 'user2'라는 계정에서 'chani'라는 계정으로 Public Key를 이용해서 SSH 접속을 하고 싶은 상황이라고 해보자.
   - 그런데, 'user2'라는 계정에서 이미 Public Key를 생성했기 때문에 id_rsa 파일이 존재하고 있다.
   - 'chani' 계정의 id_rsa 파일을 그대로 복사해올 수가 없어서 'chani'라는 이름으로 바꾸어서 복사를 한 상황이다.


   - 이 상황에서 chani 계정으로 SSH 접속을 시도하면 Public Key를 인식하지 못하고 패스워드를 물어본다.

   - 지금 필요한 것은 [ chani@127.0.0.1 ] 접속을 할 때에 id_rsa 파일이 아니라
     chani 라는 이름으로 복사한 Key 파일을 사용하도록 알려주는 것이다.

   - [ ~/.ssh/config ] 파일을 수정해보자. (없으면 생성하면 된다)


   - 위와 같이 작성한 후 [ ssh chani@127.0.0.1 ] 실행하면 접속이 될 것이다.

   - 조금 더 체계적으로 config 파일을 작성하면 다음과 같이 할 수도 있다.


   - 조금 불편한 점은 위와 같이 설정한다고 해서 localhost와 127.0.0.1 둘 모두 사용할 수 있는 것은 아니다.

   - 여기에서 중요한 점은 특정 서버에 접속할 때에 사용할 특정 Key 파일을 지정할 수 있다는 것이다.



이번에는 여기까지~

블로그의 포스트들을 살펴보다가 예전에 스크립만 해놓은 것 중 하나를 발견하게 되었다.
버전 관리 도구의 브랜치를 3D로 보여주는 도구에 대한 포스팅이 바로 그것인데...


   □ Mono Success Story: Plastic
      - http://tirania.org/blog/archive/2006/Sep-05-2.html

3D 예찬론자는 아니지만, 아... 정말 아름답다 !!!

해당 포스팅을 보면 알겠지만, 2006년도 당시에 저 도구는 시중에서 구할 수 있는 것이 아니었다.
그래서 그냥 저런 View를 제공하기 위해서 개발을 하는 곳이 있구나....라는 생각만 할 뿐이었다.

그러다가 또 하나의 아티클을 발견하게 되었다.

   □ LDRA and Codice Software launch Agile development framework
      - http://johndayautomotivelectronics.com/ldra-and-codice-software-launch-agile-development-framework/

어?! 예전에 비해서 상당히 더 세련되어진 모습으로 등장을 했다 !!!
그냥 시험삼아서 개발을 했던 것이 아니라 계속 이어지고 있었던 것이다.


그래서 계속 알아본 결과.... 예쁜 인터페이스로 유명한 plasticscm (http://www.plasticscm.com/) 에서
제공해주고 있는 기능 중 하나라는 것을 확인할 수 있었다.

게임패드를 이용한 3D Version Tree 인터페이스를 한 번 구경해보도록 하자.

소스코드의 변경 없이, 즉 아무런 내용 없이 그냥 commit을 하나 만들고 싶을 때에 사용할 수 있는 옵션이 있다. 사실 정말 아무런 쓸모없는 팁이라고 할 수도 있겠지만, 때로는 정말 유용할 수도 있는 팁이다.

이런 것이 왜 필요할까 싶기도 하겠지만, 무언가 기록을 남기고 싶을 때 사용하면 유용할 수도 있다. 하지만, 그런 용도로 사용하기 위한 tag 기능이 있는데, 왜 이러한 짓을 하나 싶기도 하다.


사실 필자의 경우에는 root commit을 만들 때 정말 유용하게 사용한다.

repository를 이제 막 생성했을 경우에 empty repository에서는 local에도 아무런 branch가 없고 remote에도 아무런 branch가 없는 정말 삭막한... 말 그대로 깡통 저장소 상태이다.

보통은 이때에 root commit을 만들기 위해서
뜬금없이 readme.txt 같은 텍스트 파일 하나 만들어서 "initial commit"이라고 생성을 하곤 한다.

나중에 괜히 지저분하게 다시 쓸데없는 파일을 삭제하는 commit도 생성이 되고.... 좀 마음에 들지 않는 부분이다.

이럴 때에 empty commit을 사용할 수 있으면... 정말 깔끔해질 수 있다 !!!


별 것도 아닌 내용이긴 하지만,
지금도 많은 개발자들을 위해 애쓰고 있는 개발 환경... 인프라 업무 담당자들을 위해서 짧은 팁 하나 남겨본다 ^^

최근 commit에서 무엇이 변경되었는지 확인하고 싶을 때 간단하게 사용할 수 있는 명령어로 [ git diff ]가 있다.

사실 변경사항을 확인하기 위해서는 전문적인 diff 도구들을 사용하는 것이 좋다.
[ config merge.tool ] 설정을 할 때에 언급되었던 도구들의 UI가 제일 예쁘다.

하지만, GIT의 특성상 가장 편리한 인터페이스가 Cmmand Line Interface이기 때문에
Consol 환경에서 바로 변경 사항을 확인할 수 있는 방법은 잘 알아두는 것이 좋다.


더 재미있는 옵션도 있다.


그러면 삭제된 내역이 있는 경우에는 어떻게 나올까?

GIT을 사용하다 보면 자주 사용하는 명령어 중 하나가 바로 [ git log ]이다.

commit list를 보기 위한 목적도 있지만, 현재 HEAD가 어디에 있는지 브랜치 상황은 어떤지 등도 확인할 수가 있다. 물론 가장 큰 이유는 언제 어떤 commit이 들어왔는지 확인하는 것이다.

문제는 git log 명령에 대한 출력 결과에 정말 다양한 취향이 존재하며, 이를 만족시키기 위해 다양한 옵션과 함께 자유롭게 결과 형식을 꾸밀 수 있는 pretty-format을 지원하고 있다.

많이 아는 사람은 입맛에 맞게 꾸미면 되지만, 일반적인 사용자들은 너무 많은 옵션을 어떻게 사용해야 할지 어렵기만 할 뿐이다.


개인적으로 가장 자주 사용하는 옵션은 아래와 같다.

출력 결과는 아래와 같다. 아래에 표시는 안했지만, 색도 입혀져 있다.

일반적으로는 위와 같은 출력만으로도 대부분의 상황은 해결이 된다. commit list도 보여주고 있고 브랜치의 모습도 그래프 형식으로 보여주고 있으며 commit comments도 잘 보여주고 있다. 거기에다가 HEAD의 위치나 브랜치의 위치도 잘 보여주고 있다.

하지만, 개인적으로 조금 부족한 부분이 있어서 아쉬움이 좀 남았다. 그래서 이런 저런 방안을 찾던 중 git log에서도 지원을 하고 있는 pretty-format에 대해서 알아보았다.

그러던 중 웹에서 몇 몇 훌륭한 예시들을 보게 되었고, 개인적인 입맛에 맞게 살짝 변형을 해보았다.

앞에서 사용한 것과 조금 차이가 있다. 일단 날짜가 나오고 commiter 계정 정보도 나온다. 물론 앞에서 사용했던 옵션에서 보여주고 있는 정보들은 여전히 나오고 있다.

그런데, 여전히 문제가 하나 있다. log를 확인하고 싶을 때마다 저 옵션을 계속 입력할 수는 없다. 저걸 외워서 하겠다라는 사람이 있으면 대단한 것이 아니라 무식한 것이다.

그래서 사용할 수 있는 방법이 바로 alias를 활용하는 것이다. 한 번 살펴보자.

사용법은 간단하고도 유용하다.

일반 명령어처럼 사용할 수가 있다. 더불어 뒤에 옵션도 추가로 사용할 수 있다.


위 샘플을 가지고 각자 취향에 맞는 log 옵션을 찾아보길 권한다. 정말 한 번 고생을 해 놓으면 정말 편리하다 !!!

이제는 어느정도 안정화가 된 것으로 보이는 GIT이지만,
아직도 종종 업데이트가 올라온다.

실제 업무에 이러한 도구를 도입할 때에 문제 중 하나가 이러한 업데이트이다.
버전 間 차이점이 많으면 사용 버전끼리의 충돌 이슈가 발생할 수 있기 때문이다.

그래서 실무에서는 사용할 버전을 하나 정해놓고 모두 해당 버전을 사용하게 가이드하곤 한다.

그리고 새로운 버전이 올라오면 해당 버전을 반영할 필요가 있을지 먼저 검증을 하고,
필요한 기능이 있다면 예전 버전과의 호환성 검증을 한 이후에 배포를 해야한다.

 

Git 1.8.1.3 Release Notes =========================  Fixes since v1.8.1.2 --------------------   * The attribute mechanism didn't allow limiting attributes to be    applied to only a single directory itself with "path/" like the    exclude mechanism does.  The fix for this in 1.8.1.2 had    performance degradations.   * Command line completion code was inadvertently made incompatible with    older versions of bash by using a newer array notation.   * Scripts to test bash completion was inherently flaky as it was    affected by whatever random things the user may have on $PATH.   * A fix was added to the build procedure to work around buggy    versions of ccache broke the auto-generation of dependencies, which    unfortunately is still relevant because some people use ancient    distros.   * We used to stuff "user@" and then append what we read from    /etc/mailname to come up with a default e-mail ident, but a bug    lost the "user@" part.   * "git am" did not parse datestamp correctly from Hg generated patch,    when it is run in a locale outside C (or en).   * Attempt to "branch --edit-description" an existing branch, while    being on a detached HEAD, errored out.   * "git cherry-pick" did not replay a root commit to an unborn branch.   * We forgot to close the file descriptor reading from "gpg" output,    killing "git log --show-signature" on a long history.   * "git rebase --preserve-merges" lost empty merges in recent versions    of Git.   * Rebasing the history of superproject with change in the submodule    has been broken since v1.7.12.   * A failure to push due to non-ff while on an unborn branch    dereferenced a NULL pointer when showing an error message.  Also contains various documentation fixes.

 

뭔가 많이 고쳐진 것이면 바람직하게 보여야 하는데... 아직도 고칠 것이 많은가~하는 불안감도 살짝 있다는...