카테고리 보관물: 테크놀러지/Linux

우분투 그놈 환경에서 리듬박스와 EasyTAG의 조합

우분투를 그냥 설치하게 되면 자동적으로 그놈 데스크탑 매니저 환경으로 부팅된다. 그놈은 오래되었고 많은 발전을 거듭한 데스크탑 매니저이므로 일반적인 사용에는 전혀 무리가 없다. (좀 더 가벼운 데스크탑 매니저를 원한다면 Fluxbox나 Xfce를, 무겁더라도 멋진(?) 걸 원한다면 KDE가 적당할 것이다.)

아무튼 그놈에는 기본적인 오디오 플레이어로 리듬박스를 사용할 수가 있다. 아마록이나 기타 등등의 강력한(?) 플레이어보다는 지원하는 기능이 적어도, 나는 아이팟도 없고 무거운건 딱 질색이라 리듬박스 정도가 적당했다. 그런데 문제는 ID(2|3) tag였다. ID tag란 (내가 아는 한) 음원 파일에 곡 정보를 삽입하는 일종의 표준 방식이다. 예를 들어, I_don’t_know_what_this_file_is.mp3 라는 mp3 파일이 있다고 할 때 이런 파일명만 가지고는 해당 곡이 어떤 곡인지, 누가 부른 노래인지, 그 곡이 포함된 앨범명은 어떤지, 장르는 뭔지 등등의 정보를 알아낼 수는 없다. 때문에 파일 안에 그러한 메타 데이터를 포함시키는 것이다.  윈도우즈를 쓸 때는 ID tag에 대해서 별로 신경쓰지도 않았고, 한글 인코딩에도 문제가 없었다. (대부분의 mp3 파일들이 윈도우즈를 통해 교환된다는 사실로 두고 볼 때, 영어야 상관 없어고 한글은 죄다 CP949 등의 방식으로 인코딩 되었기 때문이다.) 그런데 UTF-8로 한글을 (혹은 다른 언어의 글자들을) 인코딩하는 우분투 리눅스를 쓰기 시작하자, 리듬박스가 UTF-8로 인코딩 되지 않은 한글 ID tag들을 무지막지하게 깨진 글자로 표현하기 시작했다.

전엔 별 신경쓰지 않았는데, 특히 리눅스용 오디오 플레이어들은 음원 파일들을 ID tag를 기준으로 정리한다. (물론 윈도우즈용 플레이어들도 그런 방식을 지원했는데, 당시에는 그 기능들을 쓰지 않았다.) 때문에 영어 파일들은 상관 없었지만 한글 파일들을 찾거나 앨범 단위로 정리할 때 문제가 발생했다. 그래서 ID tag를 정리하기로 마음먹었다.

일일이 수작업으로 리듬박스의 파일정보 창을 통해 태그들을 수정하는건 미친짓이다. (나는 1만곡 가까이 파일들을 갖고 있기 때문이다.) 그래서 적당한 ID tag 수정 프로그램이 없을까 하고 찾아보다가 EasyTAG를 발견하게 되었다.

리듬박스는 그놈 환경이라면 기본적으로 깔려 있으므로 EasyTAG만 깔면 된다. 어렵지 않다.

‘프로그램 -> 추가/제거’ 에 들어가서 검색창에 ‘EasyTAG’를 치면 프로그램이 뜬다. 설치에 체크를 해주고 적용 버튼을 누르면 자동으로 설치된다.

나는 기본적으로 디렉토리 단위로 앨범을 관리하고 있어서 ID tag들을 수정하는데 편리했다.

ID tag 일괄 수정 방법
1. ID tag를 수정하길 원하는 앨범 디렉토리에 들어가 파일들을 전체 선택한다.

2. 마우스 오른쪽 버튼을 클릭하면 CDDB Search Files… 라는 메뉴가 있는데 클릭한다. 해당 곡 정보들을 기준으로 CDDB라는 온라인 앨범 데이터베이스에 접속해 매치되는 앨범 정보를 통째로 가져온다. (단, 어떤 앨범 정보들은 없거나 (대부분 한국 앨범들은 없다.), 결과가 부정확한 경우가 있으니 적용 전에 앨범 데이터를 확인해본다.) 적용하길 원하는 데이터를 선택하면 오른쪽 창에 곡 정보가 뜨고 밑에 Apply를 클릭해서 실제 파일에 적용한다.

3. 파일에 적용된 ID tag들을 확인한다. EasyTAG의 태그 정보 Form들 옆에 보면 조그만 동그라미가 있는데, 이걸 클릭하면 해당 Form에 기록된 정보가 선택된 파일에 일괄 적용된다. Artist나 Year, Genre등은 앨범 내 곡들이 모두 같으므로 만약 CDDB에서 가져온 정보가 맘에 들지 않는다면 이걸로 수정해도 된다.

4. 수정이 다 되었으면 파일 선택 창에서 Ctrl + S를 눌러 ID tag 정보를 기록한다. 또한 ID tag 정보를 바탕으로 파일명을 변환할 수 있는 여러가지 형식들을 지원하므로 이 기능을 이용하면 모든 파일을 예쁘게 일괄적으로 rename할 수 있다.


ID tag를 시간 날때마다 조금씩 수정하고 있다. 은근히 중독성 있는 일과다. -_-;;

제발 APM 컴파일 하지 마세요

십만년 전 도큐멘트를 보고 아직도 힘들게 APM을 컴파일 해서 사용하는 사람들이 정말 많다.

난 정보란 오래되고 가치가 떨어지거나 현재 상황에 비추어 잘못된 내용을 담고 있다면 자연적으로 도태되어야 한다고 생각한다. 그런데 한국에선 이게 반대다. 새로운 정보들에 대한 Needs는 계속 늘어나는데, 그것에 비해서 정보 생산량이 턱없이 낮기 때문이다. 그래서 사람들은 여전히 십만년 전 정보를 계속 여기저기로 퍼뜨린다. 검색엔진은 해당 검색키워드에 매치되는 페이지가 많은 오래된 정보를 여전히 검색상위 순위로 밀어 올릴 수 밖에 없다.

꽤 오래전에, (리눅스 타임으로 오래전이란 말) 나는 릴리즈 명이 hoary인 우분투 배포판에 설치된 리듬박스라는 음악 플레이어에서 mp3 파일을 실행하는 법을 정리해서 모 커뮤니티에 올린 적이 있다. mp3 파일은 라이센스 때문에 리눅스에서 그저 플레이어를 설치했다고 해서 그냥 플레이 할 수는 없다. 그래서 약간의 편법(?)을 동원해야 할 필요가 있었던 것이다. 그런데 몇년 전 그 문서가 여전히 여기저기로 퍼날라지고 있다. (각종 검색엔진에서 “우분투, 그놈, 리듬박스, 효리, mp3” 등의 키워드로 검색하면 내가 쓴 글이 여기저기에 날라져 있는걸 확인할 수 있다.) 예를 들어서, 이제는 예전의 복잡한 방법 대신에 최신 버전의 우분투에선 ubuntu-restricted-extra 패키지만 인스톨하면 된다. 그런대도 사람들은 예전 내 문서를 보고 삽질을 반복하고 있다. (일일이 퍼 날라진 글까지 내가 수정할 수는 없어서 최근에 원본글만 수정을 했다. http://kldp.org/node/49400)

아무튼 APM(Apache + PHP + MySQL)에 대한 이야기다.

대체 각종 배포판들에 패키지 관리 개념이 도입된지가 언제인가? 그런데도 사람들은 수백만년 전의 APM 컴파일 문서들을 보고 삽질을 계속한다. 데비안이나 우분투를 사용한다면 시냅틱(GUI)이나 apt-get을 이용하고, 레드햇이라면 yum을, 젠투라면 emerge, 수세라면 yast를 쓰길 진심으로 바란다. 이런 대중적인 배포판 외에 다른 것을 사용중이라면, 뭔진 잘 모르겠지만 아무튼 패키지 관리자가 분명 있을 것이다. 리눅스 프로그램 설치의 가장 고질적인 단점인 의존관계를 명쾌하게 해결해 주는 것은 패키지 관리 밖에는 없다.

가끔 (아니 사실은 상당히 빈번하게) 질답게시판에 한참을 스크롤해야 하는 컴파일 메시지들을 붙여 놓고 딱 한줄로 ‘이런 에러가 났는데 어떻게 하죠?’라고 질문하는 사람들이 있다. 장담하건데 문제를 해결해 줄 수 있는 답변을 얻을 확률은 없다. 왜 그런 에러가 났는지는 정말 아무도 모를 일이다. 라이브러리에 걸린 심볼릭 링크 하나가 잘못되어서 그럴 수도 있고, 컴파일러 버전이 낮아서 일 수도 있고, 환경변수가 잘못 지정 되어 있을 수도 있고, 심지어는 다운로드 한 소스가 컴파일 오류를 가지고 있는 잘못된 리비전 일 수도 있다.

정말로 최신의 APM이 필요하다면 컴파일 밖에는 방법이 없다. 패키지 리스트에 올라오는 버전은 항상 최신 버전보다 낮기 때문이다. 그럴 경우에 문제가 발생한다면 마지막 라인의 오류 메시지를 잘 봐라. 전부 다는 아니지만, 대개의 경우 마지막 라인의 오류 메세지는 문제 해결에 대한 중요한 단서를 제공 할 것이다. (gcc 버전이 4.0 이상이어야 한다던가…)

그러나 이제 막 웹을 공부해 볼 요량으로 APM을 설치하는 사람들에게 최신버전의 APM이 무슨 소용이란 말인가? 의미 없는 설치과정에 심력을 쏟기보다는, 패키지 설치 후에 남는 시간으로 남은 설겆이나 하는게 훨씬 유용할 것이다. 이 경우 어머니에게 귀여움을 듬뿍 받을 수 있다.

colinux (cooperative linux) 관련

예전에 colinux를 설치해서 잘 쓰다가, 이 이쁜 프로그램이 너무 만족스러워서 포스팅을 했더니 그 뒤로 꽤 많은 사람들이 해당 글을 보기 위해 접속하고 있다. 아마도 프로그램 설치 방법에 관한 내용을 기대하고 들어 왔을 것 같다. 하지만 예전에 썼던 글에는 설치방법은 적지를 않았다. 실망이 많았을 것이다.

그 글을 쓰고 난지도 한참이 지났고, 한동안 colinux를 잊고 있다가 다시 필요해져서 http://colinux.org 를 찾았다. 버젼은 꽤 업데이트가 되었고 현재 0.7.1이 beta 0.6.4가 stable인 상태다. stable을 받아서 설치하고 나니, 공포의 블루스크린이 뜨기 시작한다. 이걸 어쩐담… wiki를 살펴보니 부팅 옵션을 변경해주면 나아질 수도 있다고 해서 그렇게 했는데도 블루 스크린이 여전하다. 문제가 계속 심각해져서 일단 서비스를 내려놓고 검색을 좀 더 하기 시작했다. 아니나 다를까 stable인 주제에 winxp에서 자주 그런 문제가 발생한다고 한다. beta버젼에서는 블루 스크린에 대한 많은 버그가 수정되었다고 해서 새로운 버젼으로 다시 설치를 했다. (※ 설치하고자 하는 분이 있다면 stable말고 beta를 설치하세요. 0.8.0이 가장 최근 스냅샷이긴 하지만 저는 0.7.1 rc4를 설치했습니다.) 별 무리 없이 잘 실행중이다.

그리고 루트 이미지도 그렇다. 내가 예전에 colinux에서 데비안을 돌릴때는 stable이 우디(3.0)여서 아무 생각없이 우디 버젼의 stable 데비안 이미지를 가져다 설치했더니 패키지 레포지트리 가운데 몇개가 죽어있고 (backports), 그나마도 무슨 문제인지 apt-get update시에 패키지를 제대로 merge하지 못하고 중간에 에러가 나버린다. 몇 번을 새로 다운로드 받아서 해봐도 안되어서 살펴보니 어느덧 stable이 이치(4.0)로 바뀌어 있었고, 그래서 이미지도 이치 버젼의 것으로 새로 다운받아 적용해봤더니 아주 잘 되고 있다. 게다가 apm도 다 최신버젼이다 (apache2, php5, mysql5). 아주 흐뭇하다. (※ 다른 배포판 쪽은 잘 모르겠지만, 데비안 계열을 이용하려면 3.0 이미지보다 4.0 이미지를 이용하세요.)

네트워킹 설정 (WinPCAP)

그리고 colinux를 설치하면서 가장 애먹이는 부분이 네트워킹 설정 부분이다. 나의 경우는 공유기를 사용하고 있으며 colinux를 마치 가상의 다른 물리적 머신으로 전제하고 작업해야 하므로 winpcap을 이용한 브릿지 방식의 네트워킹을 사용하고 있다. 이 경우 colinux는 winpcap을 통해 공유기에서 직접 ip를 받아온다. 공유기를 사용하는 유저라면 이 방법이 접근이 용이하므로 가장 유용할 듯 하다. 단 데비안을 막 부팅한 상태라면 /etc/network/interfaces 파일이 수정되지 않은 상태이므로 이 부분을 변경해야 한다. 디폴트로 nano가 깔려 있으므로,

kirrie@debian:~$nano /etc/network/interfaces

한 뒤에 편집창에서 static으로 잡혀 있는 설정을 dhcp로 변경한다. (특별한 라우터 구성이 아닌 다음에야 최근의 거의 모든 공유기는 dhcp를 통해 ip를 받아온다. 그런데 사실 준비된 ip가 다 사용중이지 않은 뒤에야 static으로 남은 ip를 잡았다고 동작하지 않을 이유가 없는데, 뭔가 모르게 잘 안되어서 그냥 dhcp로 ip를 공유기로부터 가져오기로 했다.) 아무튼 아래와 같이 변경한다.

auto lo
iface lo inet loopback

auto eth0
iface eth0 inet dhcp

줄 앞에 #가 붙으면 해당 줄은 모두 주석처리되어 아무런 효력이 없다. 그러므로 주석 해제된 줄이 위와 같이 되도록 수정하면 된다. 나머지 부분은 삭제해도 좋고, 혹시 모를때를 대비해서 그냥 주석처리를 해놓는 것도 좋다.

정상적으로 수정했고 잘 저장했다면 네트워크 인터페이스를 재시동한다.

kirrie@debian:~$ifdown eth0

kirrie@debian:~$ifup eth0

ifdown은 해당 인터페이스를 내리 (종료) 라는 명령이고 ifup은 올리 (실행) 라는 명령이다. 모든게 정상적이라면 dhcp-client가 열심히 ip를 공유기로부터 받아오려고 사정사정 하는게 보일 것이다. (나는 지금 네트워킹 부분을 데비안 환경에 맞춰 설명하고 있다. 다른 배포판에서는 조금 다른 형태일수도 있다. 하지만 나는 다른 배포판을 안써본지가 억만년은 넘었으므로 패스.)

ifup eth0 명령 후에 몇 줄이 지나가고 다시 프롬프트가 뜨면 이제 다 설정이 잘 되었는지 확인해본다.

kirrie@debian:~$ping www.google.com

모든게 다 잘됐다면 colinux는 구글에다가 핑패킷을 날리고 있을 것이다.

네트워킹 설정이 끝났으면 이제 apt의 소스리스트를 업데이트하고 필요한 어플리케이션을 설치한다.

—>

처음엔 그냥 설치 잘 했다, 정도를 쓰려고 했는데 쓰다보니 이야기가 조금 길어졌다. 혹시 colinux를 설치하다가 문제가 발생했거나 하신 분이 이 글을 보고 있다면, 일단 먼저 자신의 문제가 어디서 발생한 것인지 잠시 생각해보고 wiki를 통해 해답을 찾아보길 바란다. 그래도 안된다면 kirrie_at_gmail_dot_com 으로 문의해주시면 최대한 도움을 주도록 노력하겠다.

다음엔 colinux를 가지고 할 수 있는 다른 여러가지 삽질(?)들을 소개할까 한다.

coLinux, 윈도우 서비스로 돌아가는 작고 쓸만한 리눅스

내가 리눅스를 좋아하는 이유는, 그 안에 무한한 삽질의 가능성이 존재하기 때문이다. 체계적이고 상세하게 기술되어 있는 방대한 Document들을 찬찬히 읽어 내려가는 기쁨과 수많은 포럼 및 메일링 리스트에서 실시간으로 이루어지는 열정적인 논쟁들을 엿보는 재미는 그 어떤 여가생활보다도 충만한 에너지를 충전시켜준다.

가능하다면 불법 소프트웨어 사용자의 딱지를 떼고 자유와 열정이 살아 숨쉬는 리눅스의 세계로 풍덩 빠져버리고 싶은 욕망이 시시때때로 고개를 들지만, 현실적으로 일과 관계된 소프트웨어들이 죄다 윈도우에서만 돌아가는 상황이라 무작정 윈도우를 버리는 것도 쉽지만은 않았다.

아니면 VirtualMachine류의 어플리케이션을 이용해서 리눅스를 에뮬레이트해 쓸 수도 있었다. 그러나 경험상, 그런 식으로 돌아가는 리눅스를 진지하게 써본 기억이 없다.

그러는 와중에 이놈을 발견하고야 말았다. coLinux(Cooperative Linux). 적은 용량의 프로그램 하나만 설치하면, 윈도우에서 서비스형태로 거의 완벽한 리눅스를 체험해 볼 수 있다. 물론 하드웨어 지원이나, X시스템의 부재 등의 단점이 존재한다. 차지하는 자원도 굉장히 적고 실행해 본 결과 colinux-daemon과 네트워크 사용을 위한 colinux-bridge-daemon이 각각 4메가바이트의 메모리만을 사용한다. 이미지(not picture) 형태의 파일시스템을 사용하므로 원한다면 physical partition을 사용할 수도 있다. 새로운 시스템의 형성이나 복제가 매우 간편하다. 필요하다면 그때그때 전세계 수많은 coLinux 사용자들이 미리 생성해 놓은 이미지를 가지고 다른 리눅스 배포판을 체험해 볼 수도 있다.

내 경우엔, 윈도우용 APM을 대체할 개발서버가 필요했다. critical한 문제는 아니지만, APM은 윈도우와 리눅스 사이에 미세한 환경의 변화가 있다. PHP의 경우 윈도우에선 제대로 지원되지 않는 함수도 있다. 그렇다고 본 서버에서 직접 개발을 하는 것도 여러가지 이유로 굉장히 불편하거니와, 혹시라도 있을 보안상의 문제도 마음에 걸렸기 때문에 반드시 로컬에서 접근 가능한 리눅스 서버가 필요했다.

두 말 할 필요도 없이 이 경우 coLinux가 가장 나은 대안 같아 보인다. 어차피 서버로 사용할 리눅스기 때문에 단점인 완벽하지 못한 하드웨어 에뮬레이션이나 X의 미지원등은 전혀 문제가 되지 않거나 오히려 반갑기까지 했다. X는 서버의 적!

내가 생각하는 개발 서버로의 coLinux활용도는 다음과 같다.

1. 로컬 네트워크가 존재하는 상황 (공유기나 라우터 등) 에서 coLinux는 bridge 방식으로 네트워크에 접속하여 하나의 독립된 개체로 인식된다.

2. 본 서버와 같은 환경을 구축한다. 현재 데비안 sarge로 설정해 두었다.

3. coLinux는 네트워크 상에서 독립된 개체이므로 삼바를 이용해서 쉽게 파티션에 접근할 수 있다.

4. 맘껏 일을 한다.

5. 개발이 종료되면, 본 서버에서 rsync를 이용해 완료된 작업을 간단하게 긁어간다.

6. 런칭!

+ 혹시라도 X가 필요하다면, ssh X11포워딩이나 vnc를 이용해서 X 어플리케이션을 실행 할 수도 있다.

+ 간단한 설정 파일을 가지고 원하는 만큼의 파티션을 지정해서 사용할 수 있다. 물론 각각의 파티션은 이미지 파일로써 존재해야만 한다.