조금은 잡스러울 수 있는 부분들에 대해서 알아보자.


1. uncommit

   - 'patch branch'를 생성하고, 그냥 'master branch'에서 파일을 수정한 다음에,
   - commit 하지 않고 'patch branch'로 checkout을 하면...
   - 좀 전에 'master branch'에서 수정한 파일의 내용이 어떻게 될까!?

   - 결론은 변경된 내용이 그대로 'patch branch'에서도 유지가 되어 있다.
   - 위 스크린샷에서 보면, checkout을 한 뒤 나오는 메시지를 보면 [ M    readme.txt ]라는 내용이 보일 것이다.

   - 이는 변경된 파일 내용을 유지하지 않을 경우 그 변경된 내역을 저장할 방법이 없기 때문으로 보인다.
   - 파일의 변경된 사항은 commit 단위로만 기억하는 Git이라는 것을 잘 알고 있어야겠다.



2. conflict

   - branch를 만들어서 각각 다른 부분들을 수정을 했다면, merge에 문제가 없으나,
   - 같은 부분을 서로 수정을 했다면 merge에 문제가 발생을 한다.

$ git branch patch  $ nano ./merge.txt  $ git commit -a -m "modify 1st line in master br"

   - 'patch branch'를 만들어 놓고,
   - 'master branch'에서 'merge.txt'라는 파일의 1번째 줄을 수정하고 commit 한다.

$ git checkout patch  $ nano ./merge.txt  $ git commit -a -m "modify 1st line in patch br"

   - 'patch branch'로 checkout을 한 후 'merge.txt' 파일을 수정 후 commit 한다.
   - 'master branch' 때와 마찬가지로 1번째 줄을 수정한 것이다.

$ git checkout master  $ git merge patch  $ git status

   - 'master branch'로 다시 checkout을 한 뒤에 [ git merge patch ]를 해보자.
   - 충돌이 난 것을 볼 수 있을 것이다 (같은 줄을 각자 수정을 했으니...)

   - 충돌이 난 것을 다시 한 번 보기 위해서는 [ git status ]를 해보면 된다.

$ git mergetool

   - 머지 도구를 활용하기 위해서는 [ git mergetool ]이라고 실행하면 된다.
   - 나의 경우에는 'meld'를 사용한다고 설정을 해놓아서 기본 도구로 (meld)가 보인다.

   - 'meld'의 실행화면이다.
   - 왼쪽이 'master branch'의 파일 내용이고, 오른쪽이 'patch branch' 파일의 내용이다.

   - 수정한 내역이 있으면 위와 같은 화면이 나온다.
   - 저장하고 빠져나오자.

   - 'meld'를 빠져나오면 위 스크린샷과 같이 이상한 파일이 하나 생긴다. "merge.txt.orig"
   - 그 내용을 살펴보면 위와 같이 뭐가 어떻게 충돌이 나는지를 보여준다.

   - 뭐 별 문제가 없다면 그냥 삭제하면 된다.

   - 이제는 merge를 할 때에 충돌이 난 부분을 해결을 했으니, commit을 하면 된다.

   - 그런데, 위 스크린샷을 보면 상당히 특이한 것을 확인할 수 있다.
   - commit 하나만 했을 뿐인데, log를 보면 1개가 아닌 2개의 log가 추가된 것을 볼 수 있다.
   - 즉, patch branch에서 작성한 commit이 자동으로 따라 붙어버린 것이다.




여기까지 해서 conflict 해결하는 것까지 살펴보았다.
이제 자야겠다. 일자가 바뀌었다.
눈알이 빡~빡~

Ubuntu 10.04 64bit를 사용하는 Server에서 Redmine을 패키지로 설치하여 사용하는데...

금일 갑작스레 Redmine이 뜨지를 않는 것이다.
웹으로 접속을 하면 아래와 같은 화면만 보여졌다.



Ubuntu에서 패키지로 제공하는 버전은 Redmine 0.9.3 이다.


대체 뭔일인가 싶어서 아파치의 에러메시지를 살펴보니 아래와 같았다.

$ cat /var/log/apache2/error.log

위 에러에 대해서 검색을 해보니 아래와 같은 내용을 확인할 수 있었다.

   - http://serverfault.com/questions/366406/redmine-suddenly-stopped-working-how-to-troubleshoot

물론 위 사이트에서 친절하게도 문제를 해결할 수 있는 방법도 알려주었다.

   - http://www.redmine.org/projects/redmine/repository/revisions/8909/diff/trunk/app/models/setting.rb



정리를 하자면,
Ubuntu에서 보안 문제로 인해서 Ruby를 업데이트를 해버렸는데 이로 인해서 Redmine이 에러를 내뿜는 것이다.

이게 문제가 되는 부분이 바로 저 위 에러메시지에서 알려주는 바와 같이 "setting.rb" 파일이다!
그러므로 즉, 이 파일만 수정을 해주면 해결이 가능하다.

$ sudo nano /usr/share/redmine/app/models/setting.rb

여기까지...

또 다시 간만에 작성하는 Git 이야기...^^

branch의 경우 설명하는 글들을 읽어도 알기 힘든 부분들이 많다.



오늘 살펴보고자 하는 것은 지난 번 포스팅한 내용 중,
merge를 하게 되면 마지막 commit을 한 내용을 그대로 가져온다고 했었다는 내용에 대해서다.


Git의 branch를 그냥 막 사용한다면 모르겠지만,
하나 하나 그 내용을 분석이 필요하다고 하면 아래 내용을 잘 따라와보면 도움이 될 것이다.



1. 준비

   - 지금 branch를 활용한 작업을 하기 전에 준비를 하자.

$ git branch -a

   - [ git branch -a ] 명령을 통해 모든 branch 상태에 대해서 알아보자.
   - [ * ] 표시가 되어있는 branch가 지금 현재 작업을 하고 있는 branch이다.


2. branch & commit

   - branch를 하나 만들고, 'master branch'에서 commit을 하나 해보자. 

$ git branch patch1  $ nano ./readme.txt  $ git commit -a -m "nano readme.txt in master br"

   - "A" 시점에서 'patch1 branch'를 생성을 하고,
   - 'master branch'에서 파일 수정 후 commit을 해서 "B" 시점으로 갔다.
   - 그래서 'master branch'는 지금 현재 "B" 위치에 있는 것이다.


3. checkout & commit

   - 작업하고 있는 branch를 바꿔보자.

$ git checkout patch1

   - [ git checkout patch1 ]을 통해 작업하고 있는 branch를 변경했다.

$ nano ./readme1.txt  $ git commit -a -m "nano readme1.txt in patch1 br"

   - 'readme1.txt' 파일을 수정 후 commit 하자.

   - commit을 추가로 한 번 더 해보자.

$ nano ./readme1.txt  $ git commit -a -m "1 more, nano readme1.txt in patch1 br"

   - 'patch1 branch'에서 commit 2건을 추가한 것이다.



4. checkout & merge

   - 각 branch 別 상황을 좀 살펴보자.

$ git branch -a  $ git log -2  $ git checkout master  $ git log -2

   - 'patch1 branch'의 log들과 'master branch'의 log들을 잘 살펴보기 바란다.

   - 이제 merge를 실행해 보자.

$ git merge patch1  $ git log -4

   - 위 그림과 스크린샷을 잘 봐야 한다!!! 많은 것들이 녹아 있다.

   - "E" 지점(commit)은 별도로 만든 것이 아니라 'merge'로 만들어진 것이다.
   - 그래서 log를 보면 "Merge branch 'patch1'"이 보일 것이다.

   - 그런데, 또 하나 특이한 것은 'patch1'에서 이루어진 commit까지 모두 따라왔다.
   - 그러면, 'patch1 branch'를 지워버리면 어떻게 될까?

$ git branch -d patch1

   - 'patch1 branch'를 그냥 지워버리면 어떻게 될까?!
   - 위에서 보는 바와 같이 그냥 'branch'만 지워지고 변화는 없다.


   - branch를 지운다고 하여도 그 branch에서 작업을 했던 commit들은 지워지지 않는다는 말 같은데...
   - merge가 되었다면 의미가 있지만, merge가 없는 상태에서 branch를 지웠다면...
   - 의미 없는 commit들이 그냥 살아있다는 말이 되는데...
   - 이 부분에 대해서는 꼭 한 번 깊이있게 살펴볼 예정이다. 개인적으로 관심있는 부분이라서....^^



여하튼, 이번 포스팅에서 확인을 한 것은,
branch에서 만든 commit들이 merge 후에도 계속 따라온다는 것이다.

commit 하나 하나에 더욱 더 신경을 써야 한다는 결론이 나온다.

리눅스를 일반 데스크탑처럼, 워크스테이션으로 사용하더라도,
왠지 리눅스를 사용한다고 하면 Server라는 이미지를 버리기가 힘들다.

그리고 리눅스를 사용하다보면 종종 서버의 역할을 사용하게 되기도 한다.



뭐, 서론이 길었고... 리눅스를 사용하다보면 종종 내 리눅스의 상태를 모니터링하고 싶다는 욕구가 든다.
또 왠지 모니터링 화면을 보면 대단히 있어보이기도 하고....^^

그런데, 서버 어드민에 대한 학습을 하였거나 리눅스에 대해서 그 내부를 공부를 했거나 하였다면 모르겠지만,
그렇지 않다면, 모니터링 도구를 설치하는 것부터 많은 벽에 부딪치게 된다.



그런데, Ubuntu에서 재미있고, 편하게 사용할 수 있는 도구를 제공해주고 있다!
그 이름은 바로 "Munin" !!!

공식 사이트
   - http://munin-monitoring.org/

 Ubuntu의 Munin 소개
   - https://help.ubuntu.com/11.10/serverguide/C/munin.html



1. Install

   - 모니터링 도구로 Munin을 사용하는 이유는 바로 Ubuntu에서 패키지로 제공을 해주기 때문이다!!!

$ sudo apt-get install munin munin-node

   - Munin은 두 가지로 구성되어 있다. Server 역할의 munin과 Client의 minin-node
   - Server의 역할은 munin-node로부터 정보를 얻어와서 웹페이지로 뿌려주는 것이다.

   - Client의 역할을 하는 munin-node는 클라이언트라고 보기보다는 이름 그대로 node라고 해야할 것 같다.
   - 모니터링을 하려는 대상에 심어놓는 모듈이라고 생각하면 될 것 같다.

   - 지금은 하나의 PC에 대해서 모니터링을 하면서 그곳에서 바로 웹으로 결과를 보여줄 것이다.
   - 그래서 하나의 PC에서 munin, munin-node 두가지를 모두 다 설치해버렸다.


2. munin

   - Server의 역할을 하는 munin의 환경 설정을 해보자.

$ sudo nano /etc/munin/munin.conf

[localhost.localdomain]       address 127.0.0.1       use_node_name yes

   - 지금은 자신이 설치된 PC의 것만 모니터링을 할 것이기 때문에 초기값을 그대로 사용해도 된다.

   - 즉, 여기서 설정하는 것은 어떤 node들을 모니터링할 것인가를 적어주는 부분이다.


3. munin-node

   - 여기에서 설정할 것은 누구한테 자신의 정보를 줄 것인지를 알려주어야 한다.

$ sudo nano /etc/munin/munin-node.conf

allow ^127\.0\.0\.1$

   - node에서 Server로 정보를 보내주는 것이 아니라,
     Server가 정보를 내놓으라고 하면 node가 허용한 IP에 대해서만 응답을 하는 방식으로 이해하면 된다.

   - munin과 마찬가지로 기본값으로 그냥 사용하면 된다.




여기부터가 조금 생각을 해야하는 부분인데,
기본적으로 Munin은 Apache2 기반으로 운용이 된다.

그런데, 만약 nginx와 같은 다른 웹서버를 이미 사용을 하고 있다면?!
(내 블로그를 좋아하시는 분들이라면, 이미 Redmine을 사용하실 것이고 그러면.... Nginx를 사용할 것이고....
그러면 일반적인 방법으로 적용이 안될 것이고...

아래 부분은 전체를 한 번 다 살펴보고 나서 다시 셋팅하기를 바란다.

시행착오는 제가 미리 할테니,
여러분은 그걸 보고 올바른 길로만 걸어가시기를... ^^

(리눅스에서 설치같은거 하다가 실패하고 삭제하고 하면 왠지 지저분해지는 것 같잖아요 ^^)





4. apache

   - 모니터링 결과를 웹으로 보여주기 위해서 apache 설정을 해주어야 한다.

$ sudo nano /etc/munin/apache.conf

   - 뭐 딱히 수정할 것은 없다.
   - 물론 특정 IP에만 모니터링을 허용한다던지, 다른 무언가를 원한다면 알아서 수정하면 된다 ^^


5. error

   - 일반적인 경우라면 위와 같이 바로 munin을 사용할 수 있겠지만...

$ sudo service munin-node restart  $ sudo service apache2 restart

   - 그런데, '머가필요해' 본인의 경우에는 apache2가 설치되어있지 않아서 서비스가 구동이 안된다.
   - 그러면, 설치하면 되겠지!?

$ sudo apt-get install apache2

   - 그런데 !!!

   - 위를 보면 빨간 글씨로 [fail]이 보인다.
   - 80번 포트를 이미 다른 놈이 사용하고 있어서 구동하지 못하겠다고 앙알거리는 것이다.


6. munin-nginx-ubuntu

   - Munin을 Nginx 환경에서 구동하기 위해서는 조금 귀찮지만 몇 몇 과정을 거쳐야 한다.
   - https://github.com/jnstq/munin-nginx-ubuntu


7. Nginx

   - Munin을 위해서 필요한 사항들이 있는데, 확인을 해보고 없으면 nginx를 다시 컴파일 해야 한다.

$ /opt/nginx/sbin/nginx -V

   - [--with-http_stub_status_module] 옵션이 보인다면 무관하지만, 없다면 Nginx를 다시 컴파일 해야 한다.


   - PCRE Library가 필요하니 다운로드 받자.
   - ftp://ftp.csx.cam.ac.uk/pub/software/programming/pcre/

 

$ wget ftp://ftp.csx.cam.ac.uk/pub/software/programming/pcre/pcre-8.30.tar.gz  $ tar zxvf ./pcre-8.30.tar.gz

   - Nginx를 다시 컴파일 하기 위해서 source를 다운로드 받아야 한다.
   - http://nginx.org/en/

$ wget http://nginx.org/download/nginx-1.1.19.tar.gz  $ tar zxvf ./nginx-1.1.19.tar.gz

   - 이제 Recompiling을 진행하여보자.

$ cd ./nginx-1.1.19/  $ /opt/nginx/sbin/nginx -V  $ ./configure --prefix=/opt/nginx --with-http_ssl_module --with-cc-opt=-Wno-error --add-module=/srv/install/redmine/passenger/passenger-3.0.11/ext/nginx --with-pcre=../pcre-8.30/ --with-http_stub_status_module  $ make  $ sudo make install

   - ./configure 뒤의 옵션을 참조하기 위해서 [/opt/nginx/sbin/nginx -V]를 확인했다.
   - 그대로 복사해서 사용하고 뒤에 2가지만 추가하면 된다.
   - [ --with-pcre=../pcre-8.30/ --with-http_stub_status_module ]

   - 잘 설치되었는지 확인해보려면 nginx를 재시작하고 서비스 되고 있던 redmine이 잘 보이면 OK

$ sudo /etc/init.d/nginx restart

   -그런데, 내가 잘 이해하지 못한 것이 있는지, 이렇게 restart를 해도 정말 restart가 안되는 것으로 보이기도...
   - process 추적을 해보던지 분석을 해야하지만, 귀찮아서 일단 스탑! ^^

   - nginx의 환경 파일을 다시 한 번 손 보자.

$ sudo nano /opt/nginx/conf/nginx.conf

server {         listen  8000;         server_name localhost:8000;         location / {             root /var/cache/munin/www;         }     }

   - 8000 번 포트를 사용하기 위해 위와 같은 내용을 추가한다.

$ sudo /etc/init.d/nginx restart

   - 위와 같이 재시작을 하면 되어야 하는데...
   - 뭔가 안된다. 그럴 때엔 확실히 검증하기 위해서.... 재시작!!!... Ubuntu 를 통채로 재시작~!!!

   - 잘 된다~!!!
   - [ nginx restart ] 이 놈이 잘 적용이 안되는 것 같다.
   - 우분투의 재시작으로 적용이 가능하니 일단은 패스~

   - 특별히 뭔가를 하지 않아도 알아서 정보를 차근차근 모은다. 그냥 보면 된다 ^^

   - 주어진 데이타들을 분석하는 것은 각자의 몫~!!!




여기까지~^^

WindowsXP 등의 윈도우즈 계열이 Guest인 경우,
공유폴더를 설정하게 되면 별다른 작업 없이 네트워크 환경으로 접근하여 사용할 수가 있다.

그런데, Ubuntu와 같은 리눅스가 Guest인 경우,
VirtualBox의 공유 폴더에 대해서 검색을 하게 되면 매뉴얼하게 mount를 해줘야 한다고 나온다.

환경 설정으로 걸어놓고 상시로 mount 되도록 해도 되고,
아니면 스크립트로 하나 만들어 놓고 사용해도 되고, 뭐 다양하고 편하게 알아서 하면 되지만,
공유폴더를 사용하겠다라고 하면 자동으로 등록이 되도록 하는 것에 대해서 알아보자!

   - https://www.virtualbox.org/manual/ch04.html#sf_mount_auto



   - [장치] → [공유 폴더] 선택

   - 'Guest'와 공유하고 싶은 폴더를 고르고,
   - 공유할 때 어떤 이름으로 할 것인지 정해주고,
   - "자동 마운트"를 선택해주고,
   - "항상 사용하기"를 선택하여주면 된다.

   - 별도의 mount 작업 없이 자동으로 설정이 되기를 바라는 것이
      이번 포스팅의 목적이므로 "자동 마운트"를 선택해야 한다.

   - 이번에만 잠깐 공유를 하고 싶은 경우에는 "자동 마운트"를 포기해야 한다.
      본래에는 임시로 사용하는 경우에도 '자동 마운트'를 지원되어야 하는 것이 맞는 것 같은데,
      실제로 테스트를 계속 해보는데 안된다. 즉, 그래서 "항상 사용하기"를 선택해주어야만 한다.

   - 설정을 했으면 Guest에서 공유 폴더가 접근이 가능한지 확인을 해야하는데...

$ cd /media  $ ls -al

   - 그냥 바로 확인을 하면, 위와 같이 보이지 않을 것이다. 즉, 아무것도 없을 것이다.
   - 재부팅을 해주어야 '자동 마운트' 기능을 제공해준다.

   - 설정을 할 때에 '폴더 이름'에 기재된 이름으로 공유가 되어야 하는데, "자동 마운트"를 사용할 경우에
      그 이름 앞에 "sf_"가 붙는다.


뭐 여하튼, Guest 안에서 "mount -F vboxsf 블라 블라"와 같은 명령어를 입력하지 않아도
자동으로 마운트 되어서 그냥 바로 사용할 수 있도록 VirtualBox가 기능을 제공해주고 있다.


공유 폴더도 쉽게 사용을 해보자~!!

Git Branch에 대해서 계속 살펴보자.


1. git checkout -b

$ git checkout -b hotfix

   - 브랜치를 만들고 새로 만든 브랜치로 작업 영역을 변경하기 위해서는 2단계의 과정을 거쳐야 한다.
      . [ git branch 블라블라 ] + [ git checkout 블라블라 ]

   - 이걸 한 묶음으로 처리하기 위해서는 아래와 같이 하면 된다.
      . [ git checkout -b 블라블라 ]


2. commit

   - 현재 어느 브랜치에서 작업을 하고 있는지 확인을 하고... [ git branch ]
   - 파일을 하나 수정 후 commit을 하자. [ git commit -a -m "블라블라" ]

   - 지금 긴급히 수정할 꺼리가 있어서 hotfix를 한다고 가정을 해보는 것이다.


3. merge

$ git branch  $ git checkout master  $ git merge hotfix

   - 변경 사항을 가지고 올 브랜치로 checkout을 먼저 하고선, [ git checkout master ]
   - 어느 브랜치의 것을 가지고 와서 merge를 할지 명령을 하면 된다. [ git merge hotfix ]

   - 여기서 궁금한 것은 merge를 한 것은 알겠는데, 파일만 합친 것인지...?!

   - merge를 한 이후 [ git log ]를 해보면, 본래 없던 commit이 추가되어 있는 것이 보일 것이다.
   - 즉, 위의 경우는 "hotfix" 브랜치의 마지막 commit을 "master" 브랜치로 복사해버린 것이다.



4. delete

$ git branch -d hotfix

   - 용도가 없는 branch를 지울 때엔 '-d' 옵션을 이용하면 된다.




브랜치에 대해서 공부를 하려면 꼭 나타나는 '머지 (merge)'다.
일단 가볍게 맛만 보는 정도에서 마무리 짓겠다.


앞으로도 몇 번 더 포스팅하면서 더 알아보도록 하겠다.

최근(?) 형상관리 도구에서 가장 중요한 기능 중의 하나가 바로 "브랜치 (branch)"이다.

개발 과정에서 '브랜치'를 활용하여 다양한 프로세스를 적용하게 되는데,
상당수의 형상관리 도구에서 '브랜치'를 사용하기 위해서는 많은 비용이 소요되곤 한다.

반면, Git의 특징 또는 장점으로 종종 언급되는 것이 바로 비교적 쉽고, 가볍게 '브랜치'를 사용할 수 있다는 것이다.

그러면, 이제 그 '브랜치'에 대해서 알아보아야 하는데,
많은 참고 자료들을 보면 좀 어렵게 설명이 되어 있어서 그 본질을 꽤뚫어보기가 쉽지는 않다.

하지만, 우리 사랑하는 "Git"에 대해서 알기 위해서는 꼭 넘어가야만 하는 산이기에,
차근차근 하나씩 알아나가보자.


1. branch 만들기, 현황 확인하기

$ git branch  $ git branch anotherbr

현재 repository의 branch 현황을 확인 하기 위해서는 [ git branch ]라고만 하면 된다.

repository를 생성하고 사용하게 되면, 기본적으로 git이 만들어주는 branch가 바로 "master"이다.
즉, branch 관련한 아무런 작업을 하지 않았다면, 그냥 'master' 브랜치에서 작업을 하고 있는 것이다.

그리고 위 스크린샷에서 보는 바와 같이, 현재 작업하고 있는 branch를 알려주는 표시는 "*"이다.


그러면, 새로 branch는 어떻게 만들까? [ git branch 블라블라 ]와 같이 하면 된다!

생성한 이후 [ git branch ]를 통해서 현황을 보면 위와 같이 나타날 것이다.



2. 일단 나는 master

$ git branch  $ nano ./readme.txt  $ git add ./readme.txt  $ git commit -m "modify readme.txt"  $ git push

repository에 있는 파일 하나를 수정하여 커밋하고, push를 해보자.
위 스크린샷을 보면 현재 어떤 branch에서 작업을 한 것인지 보일 것이다.



3. 나는 지금 어디에?

$ git branch  $ git checkout anotherbr

현재 작업하고 있는 branch를 변경하는 명령어는 [ git checkout 블라블라 ]이다.

위 스크린샷에서 보는 바와 같이 변경 후 [ git branch ]를 해보면 "*"가 변경되어 있는 것이 보일 것이다.

더불어서 좀 전에 'master branch'에서 작업한 파일을 확인해 보면... 뭔가 다른 것을 확인할 수 있을 것이다.



4. HEAD

현재 작업하고 있는 branch를 가리키는 포인터의 이름은 "HEAD"이다.

위의 작업들을 한 번 다시 곱씹어보자.

아무런 작업도 하지 않은 현재의 상태를 보면, C까지 작업을 한 상황에서 현재 사용중은 branch는 'master'다.
물론 당연히 'HEAD'는 'master'를 가리키고 있다.

[ git branch anotherbr ]를 이용해서 branch를 새로 만들었을 경우는 위와 같다.
똑같은 곳을 'master'와 'anotherbr'이 가리키고 있지만, 'HEAD'는 여전히 'master'를 가리키고 있다.

파일 수정작업을 하고 commit을 하였다면, 'master'는 추가로 작업한 모습을 새로 가리키고 되고
현재 작업하고 있는 branch를 가리키는 HEAD는 'master'를 가리키고 있다.

좀 전에 만든 'anotherbr' 브랜치는 여전히 좀 전과 같은 곳을 가리키고 있다.

[ git checkout anotherbr ] 명령어를 쳐서 작업 브랜치를 변경하겠다라고 하면,
'HEAD'는 이제 'anotherbr' 브랜치를 가리키게 된다.

직전에 변경한 파일 내역은 'master' 브랜치에서 이루어진 작업이므로 'anotherbr' 브랜치는 모르는 일이다.





오늘은 일단 여기까지 하고,
branch에 대해서 한 동안 계속 알아나가 보도록 하자~!!