공룡호가 사는 세상 이야기

맘에드는 아티클이다. 명령행 기교와 연산자를 익히면 유닉스가 정말 가깝게 느껴진다.
일단 시스템에 문제가 생기거나 점검을 수행할 때, 프로세스를 확인하는 것은 흔한 일이다.
시스템의 퍼포먼스가 떨어졌다던가. I/O가 느려졌다던가.
이유를 찾기 위해선 어떤 프로세스가 CPU나 DISK를 얼마나 점유하고 있는지 찾고,
평소에 그렇지 않은데, 지금 그러한 이유가 무엇인지 찾아나가는 순서로 진행된다.
프로세스를 확인 해 보자.

# ps -ef
     UID     PID    PPID   C    STIME    TTY  TIME CMD
    root       1       0   0   Jul 27      -  0:05 /etc/init
    root   53442  151674   0   Jul 27      -  0:00 /usr/sbin/syslogd
    root   57426       1   0   Jul 27      -  0:00 /usr/lib/errdemon
    root   61510       1   0   Jul 27      - 23:55 /usr/sbin/syncd 60
    root   65634       1   0   Jul 27      -  0:00 /usr/ccs/bin/shlap64
    root   86102       1   0   Jul 27      -  0:00 /usr/lib/methods/ssa_daemon -l ssa0
                                                .
                                            (중략)
                                                .
    root  315646  151674   0   Jul 27      -  0:00 /usr/sbin/lpd
    root  319664       1   0   Jul 27      -  0:00 /usr/atria/etc/albd_server
    root  340144  168018   0 12:34:56      -  0:00 rpc.ttdbserver 100083 1
    root  376846  168018   0   Jul 30      -  0:00 rlogind
 cormany  409708  569522   0 19:29:27  pts/1  0:00 -ksh
    root  569522  168018   0 19:29:26      -  0:00 rlogind
 cormany  733188  409708   3 19:30:34  pts/1  0:00 ps -ef
    root  749668  168018   0   Jul 30      -  0:00 rlogind

실행중인 프로세스만 가지고는 상세한 정보를 알기가 어렵다. 기교를 조금 부려보자.
# ps -ef | grep -E "rpc|ksh" | grep -vE "grep|rpc.ttdbserver" |
   awk -v _MAX_PID=200000 '{if ($2 > _MAX_PID) {print "PID for
   process",$8,"is greater than", _MAX_PID}}'

PID for process /usr/sbin/rpc.statd is greater than 200000
PID for process /usr/sbin/rpc.lockd is greater than 200000
PID for process -ksh is greater than 200000

같은 명령어에서 파생된 결과지만 결과의 질은 달라진다. 내가 원하는 정보를 보다 효율적으로 손쉽게 접해보자.

원문 : http://www.ibm.com/developerworks/kr/library/au-spunix_clitricks/

지난 달 Part 3 에서는 grep, sed, awk 와 같은 명령행 도구의 필터들을 소개했었다. Part 4 에서는 셸 스크립트 기교에 대해서 소개한다. 셸 명령 실행, 산술연산/진법변환, 대화형 셸 스크립트의 기본이 되는 인라인 입력이나 키보드 입력, 루프 등에 대해서 다룬다. 본 셸이 기본 조건이긴 하나 배시 셸도 관계없다.

거두절미하고 아주 짧은 셸 코드 하나를 보자.
for i in ??; { mv $i $i.ppm; }

위 코드는 현재 디렉토리의 파일 이름이 정확히 2글자인 모든 파일의 확장자를 .ppm 으로 변경한다.
i는 파일이며 ??는 파일의 글자 수이다. 루프 내는 for문의 조건이 만족되는 경우 $i를 $i.ppm으로 변경하는 간단한 코드이다. 하나 더 보자.

#!/bin/sh
# baseconv: 진법을 변환하는 간단한 스크립트
#
NUMBER=1
while [ $NUMBER ]; do
    read -p "Input base: " IN
    read -p "Output base: " OUT
    read -p "Number: " NUMBER
    bc -ql <<- EOF
  obase=$OUT
  ibase=$IN
  $NUMBER
  EOF
done

위 코드는 숫자를 입력 진법에서 출력 진법으로 변환한다. 간단하다. 튜토리얼에 모두 설명된 부분.
이번 튜토리얼은 일전에 몇 번 소개되었던 셸 스크립트 관련 아티클에 비해 자세하다. 일전의 아티클을 먼저 읽어 보는 것도 좋을 것 같다. 셸 스크립트의 강력함은 말로 다 할 수 없다. 배워봅시다.~
유용한 인라인 셸 코드들도 존재하니 많은 참고가 되겠다.

원문 : http://www.ibm.com/developerworks/kr/library/tutorial/au-unixtips4/index.html


XML은 이제 선택이 아니라 필수가 되어가고 있다.
구조적인 문서와 데이터를 교환하기 위한 통신 형식으로 충분한 계획/설계 없이 개발 중에 즉흥적으로 선택하는 경우가 많다. 올바른 XML 형식의 설계가 선행되어야, 통신에 참여하는 모든 이들의 요구를 만족시킬 수 있다. 한 개의 XML 스키마를 유지보수 하는 일은 상대적으로 간단하다. 그러나 수백 개 조직에 영향을 미치는 변화는 엄청난 충격이 될 수 있다. 이번 아티클에서는 이 충격을 관리하고 최소화 하는 두 가지 논제에 대해 다룬다.

원문 : http://www.ibm.com/developerworks/kr/library/x-extensxml.html

 

개발자들의 수다

IBM developerWorks에서 독자, 필자, 리뷰블로거 등이 함께하는 즐거운 이야기 장을 마련합니다. 이름하여, ‘개발자들의 수다’ 입니다.
이 행사는 '현장에서 참여자들이 토론 주제를 정해서 실시간으로 자유로이 이합집산하면서 토론을 진행'하는 OST(Open Space Technology) 형식으로 진행할 예정입니다.
정해진 아젠다 없이, 현장에서 함께 얘기 나눌만한 주제를 정하거나 건의해서 독자, 필자, 리뷰블로거들이 편안하게 생각을 나누고 그 과정에서 서로 영감을 받을 수 있는 행사입니다.
개발자로서의 진로, 고민이나 기술 및 트렌드에 대한 난상 토론 등 어떤 내용이어도 무방합니다.
독자, 필자, 리뷰블로거가 한자리에 모일 수 있는 올해 처음이자 마지막으로 열리는 이번 행사에서 개발자들의 수다가 활발하게 이뤄지도록 많은 분들의 참석을 기대합니다.

  • 일 시: 11월 8일 토요일 오후 2:00~6:00
  • 장 소: 도곡동 군인공제회관 23층 온디맨드홀 (약도 참고)
  • 참가 신청
    참가 신청은 전자우편(dWkorea@kr.ibm.com)으로 해주시고, 신청시 이름, 소속, 연락처 등을 적어서 보내주시기 바랍니다.
    장소 관계상 참가 신청은 선착순 200명으로 한정하니, 빠른 신청을 부탁드립니다.
  • 그 동안 developerWorks에 기고하였던 김도형, 김석준, 김승권, 김영후, 김창준, 박재호, 송치형, 이영석, 박찬욱, 서광열, 이준하, 지형준, 권용호, 안영회 씨 등 다양한 분야의 전문가들이 참석할 예정입니다.
  • 수다 예고편
    "개발자들의 스타트업과 창업", "나는 어떤 일을 잘 할 수 있는가?", "오픈소스에 대한 나의 생각", "개발자들의 제태크", "개발자와의 연애, 불가능한가?", "여성개발자의 커리어패스", "개발자와 QA, 친해지길 바래" 등 이외에도 참가자들이 즉석에서 주제를 제안할 수 있습니다.
  • 관련기사: 한국IBM, "개발자들끼리 수다 떱시다"
  • * 행사페이지 바로 가기

앞으로 가젯(=위젯?)이 웹에서 상당한 비중을 차지할 수 있다. 아직은 그 미래가 불확실 한 것은 사실이나, 가젯이 가지고 있는 많은 매력들이 그렇게 될 가능성이 충분하다는 것을 시사하고 있다.
아직은 시장이 크지 않지만, 국내 포털에서도 위젯을 개발할 수 있는 환경을 제공하고 있다. 사실 DAUM의 위젯뱅크는 구글의 그것을 그대로 가져와서 사용했다. 아직, 많은 숙제들을 안고 있긴 하지만, 많은 이들이 여기에 관심을 내보이고 있는 데에는 나름의 이유가 있다. 가젯? 위젯? 그게 뭐냐고? 그것의 정의를 일러주면 아! 하고 이해할 수 있을 것 같은가. 그것이 무엇인지, 어떤 이유로 누구를 이롭게 하는지에 대한 막연한 궁금증 들은 일단 만들어 보면 대부분 이해할 수 있지 않을까.

 MLB Batting Stats

구글 차트 API, 구글 스프레드시트 API, 구글 가젯 API, 이 3가지 API를 통하여, 메이저리그 야구 팀의 최신 타율을 표시하는 재미있는 야구 핵을 구현한다. 예제는 파이썬으로 진행된다.
특히나 스프레드시트 API는 정말로 유용하다. 길어질 수 있는 코드를 작성해야 하는 수고를 덜어준다.
구글 가젯 만들기에 관련된 article을 몇몇개 리뷰했었는데, 이것이 조금 어렵다고 느끼는 분들은 그 중 가장 쉬웠던 것을 찾아 먼저 하는 것도 좋겠다. 우측 위에서 '가젯'이라 검색하면 될거다. 아마도.

가젯이 할 수 있는 일은 상당히 많다. 내가 필요한 것은 다른 누군가에게도 필요하지 않을까.
이번 주말에는 간단한 가젯을 구상하고, 개발하는 것도 좋은 일이다.
부쩍 차가워진 날씨에, 따뜻한 블랙커피도 함께.

링크 : http://www.ibm.com/developerworks/kr/library/wa-googlecode1/

요즘 괜찮은 아티클이 많이 올라온다.
셸 스크립트. 유닉스의 꽃이라 해도 과언이 아닐 정도로 필요하고, 유용하고, 멋지다.
예전에 도스(DOS)를 이용해 본 사람이라면, 확장자가 'bat'로 되어 있는 batch 파일을 알고 있을 것이다. 스크립트라는 말에서 느낄 수 있듯, 프로그램 언어와 배치파일 사이에 있는 정도라고 이해하면 되겠다.
도스를 몰라도 상관없다. 순차적으로 어떠한 일을 해야 하는데, 그 일이 단순한 반복 작업을 계속해야 한다면, 이를 미리 정의 해 두고, 자동적으로 실행하고 싶다는 생각은 누구나 할 것이다. 비슷하다고 생각하면 이해가 쉽다.

프로그램을 조금 해 보신 분들이라면 syntax만 파악하셔도 될 것 같다. 프로그램 언어를 배우면 가장 먼저 배우게 되는 변수, 표준 입/출력/오류, 함수, if-else, case문 등의 분기분 차례로 튜토리얼이 진행되는데, 평소 셸 스크립트를 한번 공부해보고 싶었거나, 유닉스에 대해 이제 조금 뭔가 알아갈 것 같다. 하시는 분들에게 권한다.

유닉스를 만지면 언젠가는 부딪혀야 하는 셸 스크립트. 잘하든 못하든 일단 다룰 줄은 알아야 될 것이다.
그 기본이 되는 아주 기초적인 문법부터 시작하고 있으며, 생각보다 자세하다.
유의해서 보아야 할 것이 있다면 오류처리 부분. 내가 생각하는 대로 늘 스크립트가 작동할 것이라는 생각은 하지말도록 하자.
1~2시간만 시간을 투자한다면 아래 코드를 이해하고 작성할 수 있게 될 것이다.'

$vi my_second_script.ksh
#!/bin/ksh
###################################################
# 작성자: Jason Thomas
# 목적: 이 스크립트는 첫 스크립트를 개발하는 방법을 보여주기 위해 작성했다.
# 2008년 5월 1일
###################################################

# 변수 정의
HOME="/home/jthomas" # 간단한 홈 디렉터리
DATE=$(date +%H%M) # 콘 셸 명령인 date를 수행한 결과를 DATE에 저장한다.
HOSTNAME=$(hostname) # HOSTNAME은 hostname 명령을 수행한 결과를 저장한다.

##################
function if_error
##################
{
if [[ $? -ne 0 ]]; then # 함수에 전달하는 오류 코드를 점검한다.
    print "$1" # if rc > 0이면 오류 메시지를 출력하고 끝낸다.
exit $?
fi
}
if [[ -e /tmp/file ]]; then  # 먼저 파일이 존재하는지 살펴본다.
   rm -f /tmp/file # 파일 삭제
   if_error "Error: Failed removing file /tmp/file"
else
   print "/tmp/file doesn't exist"
fi

if [[ -e /tmp/test ]]; then
     mkdir /tmp/test # 디렉터리 test 생성
     if_error "Error: Failed trying to create directory /tmp/test"
else
     print "Directory exists, no need to create directory"
fi

case $TIME in
                 "2200")
                  rm -f /tmp/file1
                        ;;
                  "2300")
                  rm -f /tmp/file1
                        ;;
# 스크립트 끝
esac

결론에서도 말하고 있듯, 스크립트 헤더를 작성하고, 변수를 정의한 다음, 오류를 점검하는 순서로 배우도록 하자.
진짜, 익숙해지면 모든 작업을 스크립트로 하려고 들게 된다-_-

링크: http://www.ibm.com/developerworks/kr/library/au-kornshellscripting/

유닉스는 어렵다. 쉽지 않은 게 사실이다.
혹자는 말한다. 알고 보면 유닉스도 쉽다고? 그런데 모르는걸 어쩌나.
일단 텍스트 기반에, 명령어를 모르면 어디서 시작해야 할 지 조차 알 수가 없다.
언젠가 부터, 정말 쉬운 유닉스 강좌를 한번 해보고 싶다는 생각을 했다.
dW 연재는 튜토리얼 4편으로 나뉘며, 사용자 관점에서 기본적인 유닉스 사용법을 소개한다.
유닉스 계정만 하나 있으면 되니, 접속 할 서버가 없다면, VMWARE나 Virtual Box에 유닉스 하나 얹어놓고, 조금씩 따라 해 보자.

먼저 가장 많이 쓰는 명령어들 부터. ls, cd, pwd, mkdir, rmdir, 디렉토리 구조.
파일에 관계된 touch, cp, mv, rm,  소유권/권한에 관계된  chown, chgrp, chmod,
여러 파일을 한꺼번에 다루는 와일드 카드와 재귀(사실 별건 없다 -R 옵션으로 반복 작업을 자동화 하는 것 뿐)
압축에 관계된 tar, gzip,  파일시스템과 파일 크기에 관련된 df, du, /dev, mount, umount
입력과 출력에 관계된 stdin, stdout, redirection, cat, more, head, tail, grep, 파이프 연산자 까지.

사실 위에 것들만 다 알아도, 기본적인 유닉스 운영에는 큰 무리가 없을 정도로 중요하고 많은 비중을 차지하는 것들이다. 하지만, 조금 아쉬운 부분은, 파일시스템에 대한 설명이 조금 약하다 싶다.
윈도우 파일 시스템에 익숙해져 있는 이들이 df 명령어에 대한 간략한 설명과 다음 결과값으로, 어떻게 이해를 할 것인가.

$ df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/sda1             7.9G  3.7G  3.9G  50% /
none                  3.9G     0  3.9G   0% /dev/shm
/dev/sda3              24G   20G  1.9G  92% /export


/dev/sda1이 총 7.9G 이고 그 중, 3.7G를 사용하고 있고 3.9G가 남아있다는 것은 알겠다.
그런데, 대체 /dev/sda1 은 무엇인지, / 과 Mounted on은 무엇인지에 대한 설명이 없다.
파일시스템에 대한 사전지식이 없는 이들이 이해하기에는 다소 무리가 있다 싶지만, 의욕있는 분들은 알아서 검색을 통해서 난관(?)을 헤쳐가시리라 믿는다. 그래도 이해가 어렵거나, 궁금한 것이 많아서 미치겠다 하시는 분들은 메일 또는 댓글을 통해 질문을 주시면 성실히 답변을!

총 4편이 연재될 것이고 다음 편 부터는 vi나 shell을 사용하는 기교와 팁을 다룬다고 하는데,
어려워 질 수록 더 자세한 설명이 필요한 것은 당연하다. Part 1에서 아쉬웠던 부분이 좀 더 보완되었으면 하는 바램이다.

링크 : http://www.ibm.com/developerworks/kr/library/tutorial/au-dw-au-unixtips1-i.html
원문 : http://www.ibm.com/developerworks/edu/au-dw-au-unixtips1-i.html

프로젝트 문서화는 소프트웨어 제품을 내 놓을 때, 종종 필요악이 됩니다.
참 맞는 말이다. 개발 할 시간도 없는데 언제 문서까지 만들고 있을까... 실제로, 학부생 때, 프로젝트를 진행 하면서, 중간 보고 때 마다 진척 상황를 문서화 해야 하는 사실이 너무나 귀찮고 어려웠다. 왜 하는 지도 몰랐었던 때가 있었는데, 얼마 후, 코드가 모두 담겨 있는 USB 메모리 스틱을 분실했다. 물론, 백업을 해 두지 않은 잘못이 크긴 하지만, 절망적이었다. 6개월 간의 코드를 분실했다고 생각해 보라.
형식도, 정형화도 되어 있지 않은 내 나름대로의 문서였지만, 나는 그 간의 문서들을 기초로 다시금 코드를 작성했고, 기간은 한 달도 채 걸리지 않았다. 그러나 여전히 필요악인 건 사실인..가(?)

문서화는 중요하다. 진행 중인 프로젝트의 팀원이 변경 되거나, 통채로 중지했다 다시 시작하거나, 실수로 데이터를 유실했을 여러가지 경우에 대해서 문서는 정말 중요한 수단이 된다. 그러나, 개발 할 시간도 부족한데, 일일이 문서를 만드는 것을 좋아 할 개발자가 어디있겠는가.. 비슷한 맥락에서 다음 내용을 보자.

내 경험에 비춰봤을 때, 두 개의 핵심 문제 때문에 소프트웨어 개발 문서화가 병들고 있다. 첫 번째는 아무도 그것을 읽지 않을 것이라는 가능성 때문이다. 두 번째로 흔한 문제는 문서 작성 시기가 거의 대부분 지연된다는 것이다.

그러면 문서작성을 자동화 하는 것을 생각해 볼 수 있다. 코드가 작성될 때 마다, 버튼 한 번으로 문서를 작성할 수 있다면, 그것을 항상 최신 상태로 유지함으로써 프로젝트에 참여한 모든 인원들 그리고 사용자 까지도 더 유용하게 만들 수 있다.
과연, 어떻게 그것을 자동화 할 수 있을까? dW에서 그 해답을 찾아보는건?

원문보기
http://www.ibm.com/developerworks/kr/library/j-ap06108/

유닉스에서 셸이란 명령줄이라고도 하는데, 운영체제 상에서 다양한 운영체제 기능과 서비스를 구현하는 인터페이스를 제공하는 프로그램이다. 사용자와 운영체제의 내부(커널) 사이의 인터페이스를 감싸는 층이라는 의미에서 셸 이라는 이름이 붙여졌다. 셸은 그 종류가 다양한데, 그 종류별로 세부적인 기능의 차이들이 조금씩 존재한다. 또한, 셸 스크립트 문법도 조금씩 다른데, 사용자 별로 자신에게 익숙한 셸이 하나씩은 있기 마련이다.

dW에서 소개하고 있는 배시(bash) 셸은 거의 모든 유닉스기반에서 활용 가능한데, 이번 튜토리얼에서는 배시 셸에 대한 간략한 역사, 주요 기능을 다루며, 유닉스 파일시스템, 디렉토리와 파일 조작방법 등을 설명하고 있다.

  • 배시 개괄
  • 배시에서 명령 행 프롬프트로 작업하기
  • 배시에서 파일과 디렉터리 다루기
  • 배시 개인화하기
  • 배시 작업 제어

이 튜토리얼을 읽기 위한 시스템 요구 사항은 없다. 단지 글을 읽고 배시를 익히면 된다. 하지만 이 튜토리얼을 최대로 활용하려면 튜토리얼이 제공하는 기법을 시도할 필요가 있다. 이렇게 하려면 버전 2.05 이상인 동작하는 배시 셸이 필요하다. 컴퓨터에 설치된 배시 셸 버전을 모른다면, 배시 셸 홈 페이지를 방문해 필요한 정보를 얻기 바란다.

원문 보기
http://www.ibm.com/developerworks/kr/library/tutorial/au-dw-au-bash-i.html

NIS(Network Information Service)는 유닉스, 리눅스 사이에서 시스템 파일 등을 NIS map 형태로 도메인에 참가하고 있는 이들끼리 공유하는 서비스이다. 방법은 NFS, automounter 등이 있다. 유닉스와 리눅스는 비슷하나, 두 시스템을 통합하는 과정을 어렵게 하는 몇 가지 중요한 차이점이 있다.
아직도 NIS가 무엇인지, NIS로 둘을 통합하는 것이 과연 어떤 의미를 지니는지 잘 모를 것이라 생각한다.

좀 더 자세히 이야기 해 보자. 최초 SUN에서 처음 개발되어 현재는 거의 모든 UNIX 시스템에서 사용되는 대표적인 통합 서비스이다. 기본 개념은 서버에 저장된 /etc 환경파일 정보를 유닉스 클라이언트들이 공유하는 서비스이다. 보통은 윈도우즈의 도메인 개념과 비슷한데, 서버에 저장된 사용자들은 클라이언트에서도 로그인 및 서비스를 이용할 수 있다는 의미가 된다.
유닉스 서버와 워크 스테이션들이 단일한 공간에 많이(10대 이상) 설치되어 있는 경우, NIS를 이용하면 편리하나, 실제로 많이 쓰이지는 않는다. 그래서 연구기관이나 학교같은 실습 장비가 많은 곳에 주로 사용되기도 한다.
이제, 조금 감이 오는지?

이러한 NIS를 이용하여, 유닉스, 리눅스간 통합에 대해서 dW에서 다루고 있다. 구조는 다음과 같다.

NIS 마스터와 슬레이브 구조

이를테면, 사용자가 암호를 변경할 때, 사용자가 NIS 데이터베이스에 직접 변경을 가하면 NIS 마스터로 변경 내역이 전해지며, 데이터베이스를 갱신하고 슬레이브 서버에 변경 내역을 전파하게 된다. NIS 데이터베이스에 변경이 일어나면 변경이 일어난 시점에서 슬레이브 서버로 자동으로 전파되며, yppush 명령을 사용하여 수동전파가 가능하다. 그럼, NIS 구성에 대해서 알아보자. NIS는 무엇보다 OS나 머신에 무관하게 파일시스템을 통해 각자의 파일과 자원을 계속 사용할 수 있다는 점이다.

자세한 내용과 구성방법 등에 대해서는 아래에서 확인하자.
http://www.ibm.com/developerworks/kr/library/au-linuxtogether/index.html