WiFi Security Protocol

security에는 크게 암호화 기법과, 인증 기법이 있으며 이를 잘 파악해야 할듯..

WEP(Wired Equivalent Privacy)

- WEP-40: 24bit 의 IV(Initialization Vector)와 40bit으로 구성된 key를 사용(so called WEP-40)

     40 bits are used for encryption

- WEP-104: 24 bit의 IV와 104 bit으로 구성된 key사용

- Authentication(2가지 인증 방식)

  .Open System Authentication

사실상 인증 작업을 필요로 하지 않는 association 기법

client가 right key를 가지고 있기만 하다면 association 가능

  .Shared Key Authentication

1) client가 AP에게 인증요청을 보내고

2) AP가 clear-text challenge를 send back to client.

3) client가 AP로부터 받은 challenge text를 configured WEP key를 이용하여 암호화하고

    이를 다시 인증요청에 포함하여 AP에 재전송

4) AP는 받은 것을 해독하여, 처음에 보낸 clear challenge text와 비교해보고

    그 결과에 따라 positive or negative response를 send back한다.

- Encryption: RC4 key stream XORed with plaintext.

WPA(WiFi Protected Access)

- WEP방식에서 발견된 여러가지 security weakness를 보완하기 위해 등장

- Authentication

  .PSK(Pre-Shared Key)

  .EAP(Extensible Authentication Protocol)

- Encryption

   암호화 기법으로 TKIP(Temporal Key Integrity Protocol)을 사용하며...

   The TKIP encryption algorithm is stronger than the one used by WEP

WPA2

- WPA를 보완

- WPA2-Personal과 WPA2-Enterprise의 두 종류가 있음

- Authenticatoin

  .WPA2-Personal에서는 PSK방식을 사용

   "Pre-shared key mode (PSK, also known as Personal mode) is designed for home and

      small office networks that don't require the complexity of an 802.1X authentication server."

    .WPA2-Enterprise에서는 EAP방식을 사용

- Encryption

   암호화 기법으로는 CCMP althorithm사용

   (AES based algorithm으로, 혹자는 AES를 WPA2의 encryption algorithm이라 하기도 함)

            AES: Advanced Encryption Standard

암호화 방식에 따라..(2010.08.04)

 - stream cipher

   1) WEP

   2) TKIP - enhanced than WEP

 - Block cipher

   AES - one of CCMP(?), 이건 위에 언급한 내용이랑 좀 다른데....?????

WiFi Protected Setup

this is from Wikipedia

 - PBC stands for 'Push Button Configuration'.

Wi-Fi Protected Setup (WPS) is a standard for easy and secure establishment of a wireless home network, created by the Wi-Fi Alliance and officially launched on January 8, 2007.

The standard achieves its goal by putting much emphasis into usability and security, and the concept is implemented through four usage models that enable a user to establish a home network. So, to add a new device to the Network the user can have up to the following four choices:

1. PIN method, in which a PIN (Personal Identification Number) has to be read from either a sticker on the new wireless client device (STA) or a display, if there is one, and entered at the "representant" of the Network, either the wireless access point (AP) or a Registrar of the Network, cf below the Protocol Architecture.

   This is the mandatory baseline model, every Wi-Fi Protected Setup certified product must support it.

2. PBC method, in which the user simply has to push a button, either an actual or virtual one, on both the AP (or a Registrar of the Network) and the new wireless client device (STA).

   Support of this model is mandatory for APs and optional for STAs.

3. NFC method, in which the user simply has to bring the new STA close to the AP or Registrar of the Network to allow near field communicationbetween the devices. NFC Forum compliant RFID tags can also be used.

   Support of this model is optional.

4. USB Method, in which the user uses a USB flash drive to transfer data between the new STA and the AP or Registrar of the Network.

   Support of this model is optional.

The last two models are usually referred as out-of-band methods as there is a transfer of information by another channel than the Wi-Fi channel itself.

Note that only the first three models (PIN/PBC/NFC) are currently covered by the Wi-Fi Protected Setup Certification and there is so far no intention to certify the USB method.

This page addresses the common scenario involving an Infrastructure Network. The support of ad hoc networks (IBSS) are not supported by WPS.

Protocol Architecture

The WPS protocol defines three types of devices in a network:

• Registrar: A device with the authority to issue and revoke credentials to a network. A Registrar may be integrated into an AP, or it may be separate from the AP.
• Enrollee: A device seeking to join a wireless LAN network.
• Authenticator: An AP functioning as a proxy between a Registrar and an Enrollee.

The WPS standard defines three basic scenarios that involve these components:

1. AP with internal registrar capabilities configures an Enrollee STA. In this case, the session will run on the wireless medium as a series ofEAP request/response messages, ending with the AP disassociating from the STA and waiting for the STA to reconnect with its new configuration (handed to it by the AP just before).
2. Registrar STA configures the AP as an Enrollee. This case is subdivided in two aspects: first the session could occur on both a wired or wireless medium, and second the AP could already be configured by the time the Registrar found it. In the case of a wired connection between the devices, the protocol runs over UPnP, and both devices will have to support UPnP for that purpose. When running over UPnP, a shortened version of the protocol is run (only 2 messages) as no authentication is required other than that of the joined wired medium. In the case of a wireless medium, the session of the protocol is very similar to the internal registrar scenario, just with opposite roles. As to the configuration state of the AP, the registrar is expected to ask the user whether to reconfigure the AP or keep its current settings, and can decide to reconfigure it even if the AP describes itself as configured. Multiple registrars should have the ability to connect to the AP.
3. Registrar STA configures Enrollee STA. In this case the AP stands in the middle and acts as an Authenticator, meaning it only proxies the relevant messages from side to side.

It should be noted that UPnP is regarded to only apply to a wired medium, while actually it applies to any interface that an IP connection can be set up on. Meaning that after manually setting up a wireless connection, the UPnP can be used over the wireless medium in the same manner as with the wired.

Protocol Structure

The WPS protocol itself consists as a series of EAP message exchanges that are triggered by a user action annge of descriptive information that should precede that user's action.

The descriptive information is transferred through a new IE that's added to the Beacon, Probe Response and optionally to the Probe Request and Association Request/Response messages. Other than purely informative TLVs, those IEs will also hold the possible, and the

After the identification of the device's capabilities on both ends, a human trigger is to initiate the actual session of the protocol. The session consists of 8 messages, that are followed in the case of a successful session by a message to indicate the protocol is done. The exact stream of messages may change when configuring different kinds of devices (AP or STA) or using different physical media (wired or wireless).

GCC

GCC

GNU Compiler Collection

원래 GNU C Compiler의 의미였으나, 이후 C++, Java, Fotran등을 모두 compile할 수 있을 정도로

  커져서 'Compiler Collection'의 의미로 바뀜.

Compile 과정

전처리기 → Compile → Assembler → Linker

(source code) → → → → →  (executive file)

-전처리기: C pre processor

       source file의 주석 제거 및 define을 치환하는 기능등을 함.

-C compiler: 전처리기를 거친 source file을 assembly file로 변환

-Assembler: assembly file을 object file로 변환

-Linker: Object file들을 묶어서 실행 file로 변환

Options

-o: 출력 file 명을 지정할 때 사용

-c: Linking 과정은 진행하지 않고, *.o file인 object file까지만 생성함.

-o1~o3: 최적화 수준을 지정함. 숫자가 클수록 높은 수준의 최적화가 이루어짐

-g: debugging 을 위한 정보를 compile하면서 생성하게 됨.

Ex)

만들고자 하는 program은 main.c, read.c, write.c로 구성되어 있고,

모두 io.h라는 header file을 사용한다고 가정하면...

아래의 순서로 진행하면 됨.

%gcc -c main.c

%gcc -c read.c

%gcc -c write.c

%gcc -o test main.o read.o write.o

이 과정은 compile하고자 하는 file이 세개뿐이라서 간단하나,

100개가 넘어가는 등, file수가 많아지면, compile에 어려움. → use "make" utility.!!

etc: 통합개발환경(IDE: Integrated Development Environment)

예를 들어 MS Visual Studio 같은 것을 말한다.

즉, program개발에 필요한 모든 기능(editor, compiler, linker, debugger, ...)을 통합적으로 합쳐서

만들어 놓은 것을 말함.

이 반대의 개념으로는 "개별 개발 환경"이 있고,

Linux system에서 vi editor, gcc compiler 등으로 구분되어져 있는 개발 환경이 그 예임.

일요일 오후

오전에는..

경운이와 나란히 교회를 다녀왔다..

언젠가 지나가는 말로 자기는 큰 교회를 다니고 싶은데 자기 동네에는 마땅한 교회가 없는 것 같다고 한다..

그럼 우리 교회로 오라..는 내 권유에 너도 교회를 다니냐며 화들짝 놀랜다..ㅡ,.ㅡ

500번의 인연에서 점심을 함께 하고

집에 돌아와 누워 아이폰을 만지작 거리다 꿀같은 낮잠도 자고..

깨어보니 5시 가량..

간만에 된장남 놀이를 해보기로 하고

이번에 읽기로 마음 먹은

'여행의 기술'을 꿰어차고 집을 나선다.

지층 카페에 들어서서

주문한 마끼아또를 들고 한쪽 구석에 자리를 잡았다..

나는 이런 것이 처음인지라

흘러나오는 음악이며..

옆에서 재잘거리는 학생들이며..

처음에는 책에 몰입이 잘 되지 않다가..

보통botton의 흡입력 때문인지,

이제 내가 분위기에 어느정도 적응을 한 탓인지, 다시 보통botton의 맛깔나고 재치넘치는 글을 어렵지 않게 섭취할 수 있었다.

첫 chapter는..

'기대에 대하여'라는 작은 제목이 붙어 있었는데, 본문의 내용을 인용하여 서문에 붙어 있는 짤막한 글귀가 내 눈을 사로 잡았다..

여행할 장소에 대한 조언은 어디에나 널려있지만, 우리가 가야 하는 이유와 가는 방법에 대한 이야기는 듣기 힘들다. 하지만 실제로 여행의 기술은 그렇게 간단하지도 않고 또 그렇게 사소하지도 않은 수많은 문제들과 자연스럽게 연결된다.

읽어 내려가기가 수월하지 않지만,

기대가 되는 책이고..

다 읽은 후에는 그 여운을 여기에 또 남겨봐야 하겠다..

정기연습-축복의 길

2010.04.17 방배동 연습실

다음주에 있을 홍석이네랑, 시원이네 커플 축가해준답시고

연습시간에 미리 축가 연습하는 시간을 잠깐 가졌었다.

내가 찍은거라

절묘한 화음대신 베이스인 내 목소리가 유독 크게 녹음되어 버려 안타깝지만..

어떤 이들은 이제 좀 지겹다고도 하지만..

난 아직도 저 화음이 꽤나 좋다..

그나저나 이번 달에 결혼식이 무려 8개..

ㅎㄷㄷ

Beacon, WiFi

What the hell is a Beacon?

명사

1.(안전 운행을 유도하는) 신호등[불빛]  Belisha beacon

a navigation beacon

운행 신호등

He was a beacon of hope for the younger generation.

그는 젊은 세대에게 희망의 불빛이었다.

2.(배・비행기의 위치 확인을 돕는) 무선 송신소

3.(과거 신호용으로 피워 올리던) 봉화

Network 규격에서 Tx와 Rx사이의 미리 약속된, 알고 있는 신호를 의미한다.

즉, Tx에서 보내는 data를 Rx에서 이미 알고 있으므로 동기화 및 channel estimation등의 용도로 사용된다.

Beacon은 AP에서 전송되는 신호이다.

AP의 존재와 지원능력(SSID, Signal strength, 사용가능한 datarate..)을

주변 무선기기에 주기적으로 알려준다.(broadcasting)

무선 client는 이 beacon을 받아서 AP와 시간을 동기화 시키고

Power save mode로 동작할 수 있도록 해준다.

Beacon Interval 은 AP가 beacon message를 전송하는 interval을 의미한다.

퀴즈쇼

김영하 장편소설이라고 한다.

지난 생일 영이가 "읽어봐, 재밌어"라며 건네 준 책.

미루고 미루다,

출퇴근길에.. 자기전에 틈틈히 읽으며

꼬박 한달이 걸린것 같다..

한 대학원생이, 아니 대학원 졸업생이 인터넷 채팅방의 일종인 퀴즈방에서 또래의 여자를 만나 사랑하게 되고, 그러는 와중에 편의점 아르바이트, 단칸방 고시원 생활을 거치며 88만원 세대의 비극도 겪어 보고, 자신의 장기를 살려 티비 퀴즈쇼에도 나가게 된다. 그를 계기로 그는 '회사'라 불리우는 전문 퀴즈풀이 집단에 몸담게 되고 어쩌고 저쩌고..

'따뜻하고 촉촉하고 달콤했다....우리는 그대로 오래 있었다'로 맺으며 happy ending의 뉘앙스로 마무리 된다.

책 후반부에는 '..김영하 식의 답변이자 뛰어난 성장소설..'이네 어쩌네 하며 평론이 이어지지만,

나는 퀴즈쇼가 비유하는바가 무엇인지, 이 시대를 살아가는 젊은이의 자화상이 어떻다며 블라블라하는 따위의 고찰은 하기 싫었다.

그냥 가볍게 읽으며..

그때마다 잠시 이 지치고 찌들고 재미 없는 일상을 탈출할 기회를 얻었으면..

내겐 그걸로 되었다..

멋진 장면이 하나 있긴 했다..

그녀는 휴대폰을 손에 들고 있었다.

"네 것도 꺼내봐"

나는 주머니에서 휴대폰을 꺼냈다.

아, 이제 번호를 주고 받을 차례로구나.

언젠가부터 인간과 인간이 만나면 명함을 주고 받는 것이 아니라

외계인과 교신하듯 휴대폰을 마주 겨누고 신호를 주고 받는 풍습이 생겼다.

"전원을 꺼"

그녀가 말했다.

"왜? 번호 따는거 아니었어?"

"함 꺼봐"

나는 그녀가 시키는 대로 전원을 껐다. 그녀의 휴대폰도 피릿, 소리를 내며 꺼졌다.

"자, 이제 우리는 존재하지 않는거야"

Boot Loader

Boot Loader

- Boot Code와 Startup Code를 합쳐서 Boot Loader라 칭하며

- "crt0.s" 라는 assembly file 이 Startup Code이며 Boot Code 또한 여기에 같이 담겨있다.

Booting Procedure

- Boot Code를 통한 Hardware setting

- Startup Code 실행

- main()함수로 분기하여 program 실행

Boot Code & Startup Code

PC에서 program의 시작점은 어디인가? main()??

main()도 함수인데 누군가에 의해 호출되야 작동이 되지 않겠는가라는 의문.

또한 C program에서 사용하는 stack이나 heap, static memory등은 누가 만들어 주는가?

이러한 과정 즉,

전원이 들어오고 HW 초기화,

C program이 작동되기 위한 준비과정을 해주는 코드가 바로 Boot Code와 Startup Code이다.

 1. Boot Code

1)Entry Point 지정:

  - entry point는 프로그램의 시작을 알리는 역할을 한다. 즉, 가장 먼저 시작되는 포인트를 정함.

2)Exception Vector 설정(예외처리벡터)

  - ARM의 경우, 예외 처리벡터는 보통 ROM의 시작주소인 0x0번지에 위치한다.

  - 예외 처리 벡터는 예외가 발생했을 때, 예외를 처리하는 코드들이 있는 테이블이다.

  - 각 예외에 할당한 메모리는 4byte이므로 명령어 하나로 예외처리를 해야함.

  - 그래서 벡터에는 실제 핸들러가 있는 위치로 분기하는 분기명령으로 이루어져 있음.

  3)System clock 설정: system에서 사용되는 clock을 설정한다.

4)Memory 초기화: system에서 사용되는 ROM이나 RAM등의 메모리에 필요한 설정을 해주는 과정

 2. Startup Code

1)Interrupt Disable

2)RW_DATA ROM에서 RAM으로 복사

3)ZI 영역 Clear

4)Mode별 Stack생성

5)Heap생성

6)Interrupt Enable

7)main()호출

Linux Kernel Compile

Linux System에서 가장 중요한 Kernel을 직접 컴파일하고 실행시켜 봄으로써 익숙해지도록 해보자..

Linux Kernel은 여러가지 버전이 있으며 가장 최신 것을 사용하되,

내가 접한 문서에서는 "2.4.16"을 바탕으로 설명하고 있음..

1. LXR (Linux Cross Reference).

-리눅스 소스코드의 모든 함수/변수/정의 등에 대한 cross ref를 온라인으로 제공(http://lxr.linux.no)

 예를 들면, visual studio에서 특정 변수를 click하면 그 변수가 정의된 소스코드를 보여주는 것과

   비슷한 것 같다.

 소스코드를 분석할때, 보통은 grep을 사용해 찾아본다고 함.

 하지만 너무 힘들고 일이 많아지는 단점이 있으므로 LXR을 사용하는 것이 유익하다.

2. 소스코드 얻기

-Linux Kernel Source Code는 http://www.kernel.org 에서 구할 수 있음.

 각 버전별로 구분되어 있으며, 이중 원하는 버전의 완전한 코드를 받는다.

 gz, bz2 의 두가지 타입으로 압축되어 제공되며, 둘중 어느것을 사용해도 무방.

3. 소스코드 풀기

-Kernel Compile을 위해서는 root권한을 가져야함. (root 혹은 su로 login)

-보통 kernel은 /usr/src 밑에 위치

-압축된 kernel의 소스코드는 모두 linux란 이름의 directory로 시작하므로

   usr/src에 linux란 link나 directory가 있을시 덮어쓰게 되므로 주의.

>>cd /usr/src

   rm -f linux

   tar xvjf somewhere/linux-2.4.16.tar.bz2 // 압축풀기

   mv linux linux-2.4.16.tar.bz2 // A를 B로 옮김(혹은 rename)

   ln -s linux-2.4.16 linux // symbolic link. 심볼만(파일의 경로) 가리킴

// windows의 단축아이콘과 같은 개념

// -s 옵션이 없으면 hard link

// link [링크할대상] [링크파일명]

4. Compile 준비 (tool version확인)

>>make mrproper //소스코드를 처음 깔았을 때와 같은 상태로 돌려주는..

    cd /usr/src/linux/Documentation

    vi Changes //이 document에는 현재 kernel을 compile하기 위해 필요한 tool들의

           //version정보가 들어있음.

//각 tool들의 버전을 확인하는 방법은 [명령어] --version이라 치면됨.

//ex) gcc --version

make --version

5. Kernel 설정

-다음과 같은 방법이 있음

  1)고전적인 방법

  2)text 기반의 menu를 이용하는 방법

  3)x-window상에서 GUI를 이용하는 방법

-menuconfig 방법

 >>make config

     make menuconfig

     make xconfig

-kernel 설정이 끝나면 /usr/src/linux/.config 이 만들어 진다.

6. Kernel Compile

-다음의 순서대로 진행

>>make dep  //source file과 header와의 의존성을 검사

    make modules //설정에서 module로 선택한 것들을 *.o 의 형태로 만들어 준다.

    make bzImage //kernel자체를 만들어준다.

    make modules_install //만들어진 module을 /lib/modules/2.4.16에 설치

            //설치와 함께 depmod를 실행해 module간의 의존성도 만들어주는 역할

7. Kernel test 및 설치

-Compile이 끝났으면 Kernel이 제대로 동작하는지 확인한 후 기본 커널로 설치해 사용.

-2가지 test방법:

  1) 플로피 디스크 사용

make zdisk를 사용해 만들어진 kernel을 floppy에 담는다.

복사가 끝난 후 floppy를 이용해 부팅해 보고 정상동작하는지 확인.

  2) LILO 사용(LInux LOader: Linux를 위한 boot loader)

/etc/lilo.conf 를 수정(문서 참조)

새로 부팅 후 LILO에 test라고 입력하여 새로 만든 커널을 실험한다.

-Kernel의 설치

  Kernel image와 map file을 복사하고 lilo.conf를 수정하면 된다.

  복사할 file: ~ means '/usr/src/linux'

  1) ~arch/i386/boot/bzImage

  2) ~/system.map

Linux basic commands

기본 명령어s

cd

디렉토리를 변경할 때 사용.

예 : [test@host2]$ cd 이동할 디렉토리 명.

ls

디렉토리의 화일들을 보여줌.

예 : [test@host2]$ ls <옵션>

<옵션>

-al : Hidden속성의 파일 표시(a옵션),파일의 종류, 사용권한등 자세한 정보표시(l옵션)

-aC : 도스의 dir /w명령과 같이 한 줄에 여러 개의 정보를 표시(C옵션)

-R : 도스의 dir/s 명령과 같이 서브디렉토리의 모든 명령어를 보여주는 옵션(R옵션)

passwd

자신의 계정의 암호를 변경할 때 사용.

예 : [test@host2]$ passwd 변경할 ID.

New Unix Password : 암호 입력

Retype new Unix Password : 암호 재입력

pwd

자신의 홈디렉토리를 확인할 때 사용.

예 : [test@host2]$ pwd

/www/home/test

cp

파일이나 디렉토리 복사시 사용.

예 : [test@host2]$ cp <복사할 파일명> <복사되어 생성될 파일명>

mv

move라는 도스명령어와 같은 것으로 파일을 다른곳으로 옮겨주는 명령어입니다.

cp명령어는 복사를 하기 때문에 원본파일은 그대로 존재하면서 또다른 파일을 생성해 주지만 mv는 원본파일이 다른곳으로 대체되어 버립니다.

따라서 mv라는 명령어의 용도는 파일이나 디렉토리의 이름을 바꾸는 용도로 많이 사용됩니다.

mv의 사용형식과 예를 들어보면 다음과 같습니다.

mv 옵션 원본파일(디렉토리) 목적파일(디렉토리)

<옵션>

-b : 삭제하기전에 백업본을 만들 수 있습니다.(backup)

-f : 목적디렉토리에 동일한 파일이 있더라도 overwrite합니다.(force)

     즉, overwrite여부를 확인하지 않고 바로 덮어쓰게 됩니다.

-i : 목적디렉토리에 동일한 파일이있을 경우에는 overwrite여부를 확인합니다.(interactive)

rm

파일이나 디렉토리를 삭제할 때 사용.

예 : [test@host2]$ rm <옵션> <삭제할 파일이나 디렉토리명>

<옵션>

-f: 삭제여부를 묻지않고 바로 삭제해 버립니다.(force)

-i: 삭제여부를 확인하게 됩니다.(interactive)

-r, -R: 서브디렉토리가 있을 경우에도 모두 삭제해 버립니다.(recursive)

mkdir

디렉토리를 생성할 때 사용.

예 : [test@host2]$ mkdir <생성할 디렉토리명>

rmdir

디렉토리를 삭제할 때 사용.

예 : [test@host2]$ rmdir <삭제할 디렉토리명>

du

자기 계정의 디스크 사용량을 볼 때 사용.

디렉토리를 삭제할 때 사용.

예 : [test@host2]$ du <옵션> <사용자아이디>

<옵션>

-s : 전체 사용량을 간략히 표시

-h : 용량단위로 표시하여 좀 더 알기 쉬움.

cat

concatenate의 약자로서 텍스트형식으로 된 파일의 내용을 볼 수 있는 명령어입니다.

예 : [test@host2]$ cat <옵션> <파일명>

<옵션>

-b : 행번호를 앞에 붙여서 출력. (빈행은 번호를 붙이지 않습니다.)

-n : 행번호를 앞에 붙여서 출력. (빈행도 번호를 붙입니다.)

tar

여러개의 파일을 묶거나 풀 때 사용.

예 : [test@host2]$ tar cvf 압축파일.tar 압축대상파일 및 디렉토리 : 압축할때

        [test@host2]$ tar xvf 압축파일.tar : 풀 때

<옵션>

-c : tar 파일을 생성할 때

-d : tar 파일과 해당 파일시스템간의 차이점을 확인하고자 할 때 사용.

-r : tar 파일에 다른 파일들을 추가하고자 할 때 사용.

-t : tar 파일의 내용을 확인하고자 할 때 사용.

-f : tar 파일을 사용할 때 반드시 사용.

-p : tar 파일을 생성할 때 당시의 퍼미션을 그대로 하여 풀어줄 때 사용.

-v : 묶을 때나 풀어줄 때 파일들의 내용을 자세하게 보려고 할 때 사용.

-Z : compress로 압축파일 사용할 때 압축이나 해제까지 한번에 할 때 사용.

-z : gzip과 관련하여 압축이나 해제를 한꺼번에 할 때 사용

head

이 명령어는 파일의 내용을 처음부터 몇행까지만 보고자 할 때에 사용합니다.

다음과 같은 형식으로 사용됩니다.

head 파일명 : 아무런 옵션없이 사용하시면 처음부터 10행까지만을 보여줍니다.

head -n 파일명 : 파일의 첫행부터 n행까지만을 보여줍니다.

이에 대한 예를 보이면 다음과 같습니다.

[yourid@nice ~/logs]$ head  access_log

168.126.62.78 - - [14/Sep/1999:17:34:07 +0900] "GET /server-status?refresh=1 HTTP/1.1" 200 1515

168.126.62.78 - - [14/Sep/1999:17:34:09 +0900] "GET /server-status?refresh=1 HTTP/1.1" 200 1525

168.126.62.78 - - [14/Sep/1999:17:34:10 +0900] "GET /server-status?refresh=1 HTTP/1.1" 200 1525

168.126.62.78 - - [14/Sep/1999:17:34:11 +0900] "GET /server-status?refresh=1 HTTP/1.1" 200 1525

168.126.62.78 - - [14/Sep/1999:17:34:12 +0900] "GET /server-status?refresh=1 HTTP/1.1" 200 1525

168.126.62.78 - - [14/Sep/1999:17:34:13 +0900] "GET /server-status?refresh=1 HTTP/1.1" 200 1525

168.126.62.78 - - [14/Sep/1999:17:34:14 +0900] "GET /server-status?refresh=1 HTTP/1.1" 200 1525

168.126.62.78 - - [14/Sep/1999:17:34:15 +0900] "GET /server-status?refresh=1 HTTP/1.1" 200 1525

168.126.62.78 - - [14/Sep/1999:17:34:16 +0900] "GET /server-status?refresh=1 HTTP/1.1" 200 1525

168.126.62.78 - - [14/Sep/1999:17:34:17 +0900] "GET /server-status?refresh=1 HTTP/1.1" 200 1526

[yourid@nice ~/logs]$ head  -5 access_log

168.126.62.78 - - [14/Sep/1999:17:34:07 +0900] "GET /server-status?refresh=1 HTTP/1.1" 200 1515

168.126.62.78 - - [14/Sep/1999:17:34:09 +0900] "GET /server-status?refresh=1 HTTP/1.1" 200 1525

168.126.62.78 - - [14/Sep/1999:17:34:10 +0900] "GET /server-status?refresh=1 HTTP/1.1" 200 1525

168.126.62.78 - - [14/Sep/1999:17:34:11 +0900] "GET /server-status?refresh=1 HTTP/1.1" 200 1525

168.126.62.78 - - [14/Sep/1999:17:34:12 +0900] "GET /server-status?refresh=1 HTTP/1.1" 200 1525

tail

이 명령어는 바로앞의 head라는 명령어와는 상반되는 것이며 파일의 내용을 맨 마지막부터 몇행까지 보고자 할 때에 사용합니다.

이런 tail이라는 명령어의 주용도는 계속 추가되는 파일의 내용을 모니터링하면서 내용을 확인하고자 할경우에 매우 유용하게 활용됩니다.

tail 파일명 : 아무런 옵션없이 사용하시면 마지막부터 10행까지만을 보여줍니다.

tail -n 파일명 : 파일의 마지막행부터 n행까지만을 보여줍니다.

[yourid@nice ~/logs]$ tail  access_log

210.219.170.93 - - [06/Dec/1999:19:02:41 +0900] "GET /cgi-bin/home.cgi HTTP/1.1" 404 - "http://www.m

210.219.170.93 - - [06/Dec/1999:19:02:48 +0900] "GET /logo.html HTTP/1.1" 404 - "http://www.manualan

210.117.112.49 - - [07/Dec/1999:02:04:34 +0900] "GET / HTTP/1.0" 200 513 "http://dir1.naver.com/sear

210.117.112.49 - - [07/Dec/1999:02:04:34 +0900] "GET /logo.html HTTP/1.0" 404 - "http://dir1.naver.c

210.117.112.49 - - [07/Dec/1999:02:04:34 +0900] "GET /cgi-bin/menu.cgi HTTP/1.0" 404 - "http://dir1.

210.117.112.49 - - [07/Dec/1999:02:04:37 +0900] "GET /cgi-bin/home.cgi HTTP/1.0" 404 - "http://dir1.

210.221.2.125 - - [07/Dec/1999:02:29:20 +0900] "GET / HTTP/1.0" 200 513 "http://search.simmani.com/c

210.221.2.125 - - [07/Dec/1999:02:29:20 +0900] "GET /cgi-bin/menu.cgi HTTP/1.0" 404 - "http://www.ma

210.221.2.125 - - [07/Dec/1999:02:29:20 +0900] "GET /logo.html HTTP/1.0" 404 - "http://www.manualand

210.221.2.125 - - [07/Dec/1999:02:29:20 +0900] "GET /cgi-bin/home.cgi HTTP/1.0" 404 - "http://www.ma

[yourid@nice ~/logs]$ tail -5  access_log

210.117.112.49 - - [07/Dec/1999:02:04:37 +0900] "GET /cgi-bin/home.cgi HTTP/1.0" 404 - "http://dir1.

210.221.2.125 - - [07/Dec/1999:02:29:20 +0900] "GET / HTTP/1.0" 200 513 "http://search.simmani.com/c

210.221.2.125 - - [07/Dec/1999:02:29:20 +0900] "GET /cgi-bin/menu.cgi HTTP/1.0" 404 - "http://www.ma

210.221.2.125 - - [07/Dec/1999:02:29:20 +0900] "GET /logo.html HTTP/1.0" 404 - "http://www.manualand

210.221.2.125 - - [07/Dec/1999:02:29:20 +0900] "GET /cgi-bin/home.cgi HTTP/1.0" 404 - "http://www.ma

tail 이라는 명령어는 위의 두 경우 보다도 다음과 같은 용도로 많이 사용됩니다.

[yourid@nice ~/logs]$ tail -f  error_log

[Tue Dec 7 02:04:34 1999] [error] [client 210.117.112.49] File does not exist: /home/yourid/public_

[Tue Dec 7 02:04:34 1999] [error] [client 210.117.112.49] File does not exist: /home/yourid/public_

[Tue Dec 7 02:04:37 1999] [error] [client 210.117.112.49] File does not exist: /home/yourid/public_

[Tue Dec 7 02:04:37 1999] [error] [client 210.117.112.49] File does not exist: /home/yourid/public_

[Tue Dec 7 02:29:20 1999] [error] [client 210.221.2.125] File does not exist: /home/yourid/public_h

[Tue Dec 7 02:29:20 1999] [error] [client 210.221.2.125] File does not exist: /home/yourid/public_h

[Tue Dec 7 02:29:20 1999] [error] [client 210.221.2.125] File does not exist: /home/yourid/public_h

[Tue Dec 7 02:29:20 1999] [error] [client 210.221.2.125] File does not exist: /home/yourid/public_h

[Tue Dec 7 02:29:20 1999] [error] [client 210.221.2.125] File does not exist: /home/yourid/public_h

[Tue Dec 7 02:29:20 1999] [error] [client 210.221.2.125] File does not exist: /home/yourid/public_h

f라는 옵션을 사용하면 계속적으로 추가되는 파일의 내용을 실시간으로 모니터링하면서 보실 수 있습니다.

따라서 어떤 파일의 내용, 특히 에러파일의 내용이나 로그파일의 내용을 확인하고자 할 때 가장 유용하게 사용됩니다.

grep

지정된 file내의 특정문자나 단어를 검색하는 명령어

예) %grep <option> <찾을문자> <대상file>

    %grep -i hello /etc/test   → test file에서 hello라는 문자를 대소문자 구분없이 검색하여 출력

<options>

-v: 지정한 패턴과 일치하지 않는 것들을 보여준다.

-n: 일치하는 라인의 결과와 그 파일에서의 결과 라인이 몇 번째 라인인지 출력

-i: 대 소문자의 구별을 하지 않음

-c: 일치하는 라인의 수를 보여준다.

-C num: 일치하는 문자가 포함된 라인과, 지정한 num 라인만큼의 위와 아래라인을 보여준다.

        default는 두줄. ex) grep -C 5 hello /etc/test

-A num: 일치하는 문자가 포함된 라인과, 지정한 num 라인만큼의 아래라인을 보여준다.

Android

1. What is Android?

 Mobile Device를 위한 Software stack이다.

  → 운영체제(Linux)와 Middleware, 핵심 Application을 포함하고 있음

2. Android SDK

 Android platform상의 application을 개발하기 위해 필요한 도구 및 API제공

 JAVA Programming 언어 사용

3. Android Architecture

4. Feature & its Components

 1) Application(built-in)

  - E-mail client, SMS service, Calendar, Map, Browser, Contacts등의

    핵심 application을 탑재하고 있으며, 모든 application은 Java로 작성되어 있음.

 2) Application Framework

  - 개발자는 Android에 이미 탑재된 핵심 application에 사용된 것과 동일한 Framework API에

    완벽하게 접근할 수 있음. → Applicaiton의 재사용과 교체가 가능.

 3) Dalvik Virtual Machine: Mobile device를 위해 최적화된 JAVA based Virtual Machine.

 4) Integrated browser : Webkit engine based Web Browser.

 5) Optimized Graphics: 2D graphic library 및 OpenGL ES 1.0 기반의 3D graphic engine library제공

 6) SQLite: SQ Lite 기반의 Database engine 제공

 7) Media Support: 다양한 audio, video 및 image format 지원

 8) GSM 통신모뎀, Bluetooth, EDGE, 3G, WiFi, GPS등을 지원

 9) Libraries: 다양한 Android System Component에서 사용되는 C/C++ Library들을 포함하고 있다.

    이런 기능들은 Android Application Framework를 통하여 개발자에게 제공됨.

    Java와 interface를 하기 위해 존재

  -System C Library - 표준 C system library

  -Media Library - Audio & Video의 재생 및 녹화 관리

  -Surface Manager - Graphic Layer관리

  -LibWebCore - Web Browser engine

  -SGL - 2D graphics engine의 하단을 구성함

  -3D Library -OpenGL ES 1.0 API기반으로 구현되었음.

  -FreeType -Bitmap 및 vector font rendering engine

  -SQLite -모든 app에서 사용할수 있는 강력하며 경량화된 관계형 DB엔진.

 10)유용한 개발 환경

  -Debugging을 위한 Eclipse IDE기반의 Device Emulator를 지원

  -메모리 및 성능 프로파일링 기능 지원

  -Eclipse IDE에 기반한 x86 기반의 Cross개발환경 지원

  -Eclipse, Emulator, Target Device로 구성 (아래 그림)

한우리 주말연습 / 2010.03.27

Sanctus / Nelson Mass

 

Rock이나 Jazz mass도 물론 좋았지만

조금은 더 클래식한 느낌의 Nelson Mass가 내 귀엔..

캔디..

특히 각 파트의 화음이 절묘하게 어우러지며

crescendo e diminuendo 로 시작되는 첫 부분이 나는 얼마나 짜릿한지 모른다..

이제 처음 연습해 본것이라

많이들 입에 안 익었지만..

곧 멋진 화음을 만들어 낼수 있으리라 기대해 본다..

한우리 주말연습 / 2010.03.27

빛이없는 어둠 속에서도 찾을수 있는

아주작은 몸짓 하나라도 느낄수 있는

소리없는 침묵으로도 말할수 있는

마주치는 눈빛 하나로도 다 알수 있는

바람부는 벌판에서도 외롭지 않은

마주잡은 손끝하나로 너무 충분한

기나긴 겨울밤에도 춥지 않은

타오르는 가슴 하나로 너무 충분한

우리는 연인

이렇게 이렇게 우리는 연인

가사가 어쩌면 이렇게도 주옥 같은지 모르겠다..

우리는

우리는 빛이없는 어둠 속에서도 찾을수 있는

우리는 아주작은 몸짓 하나라도 느낄수 있는

우리는..

우리는 소리없는 침묵으로도 말할수 있는

우리는 마주치는 눈빛 하나로 모두 알수 있는

우리는..

우리는 연인

기나긴 하 세월을 기다리어 우리는 만났다

천둥치는 운명처럼 우리는 만났다

오오 바로 이순간 우리는 하나다

이렇게 이렇게 이렇게 우리는 연인

우리는 바람부는 벌판에서도 외롭지 않은

우리는 마주잡은 손끝하나로 너무 충분한

우리는..

우리는 기나긴 겨울밤에도 춥지 않은

우리는 타오르는 가슴 하나로 너무 충분한

우리는..

우리는 연인

수없이 많은 날들을 우리는 함께 지냈다

생명처럼 소중한 빛을 함께 지녔다

오오 바로 이순간 우리는 하나다

이렇게 이렇게 이렇게 우리는 연인

아아..