Category: Linux

Chef Workstation 설치 – Part 3

chef workstation 은 knife 를 설정면 하면된다. 다시말해서 별다른 패키지가 필요없고 특정 시스템 계정사용자에게 knife 를 사용할 수 있도록 설정만하면 그게 바로 workstation 이 되는 것이다.

하지만 별도의 시스템에 workstation 을 설치하고자 할 경우에 knife 명령어가 없다. 그렇다고 chef server 패키지를 설치할려고 하니 불필요한 서비스들이 너무 많은게 문제다. 이럴때는 chef develoment kit 를 설치하면 된다.

chef development kit 은 말그대로 chef 관련 개발을 위한 kit 을 제공하는 것으로 이는 chef workstation 환경을 기반으로 한다. 따라서 chef development kit 패키지를 설치하면 chef workstation 구성을 위한 chef 관련 명령어들이 당연히 들어 있게 되는 것이다.

chef development kit 역시 chef 홈페이지에서 다운로드 가능하다. 레드햇과 우분투 배포판 패키지가 준비되어 있어 패키지를 다운받아 설치하면 된다.

이제 chef 명령어를 이용해서 알맞은 환경을 조성할 수 있도록 다음과 같이 해준다.

앞에서 chef 서버 설치하면서 만들어놓은 자격증명 파일을 복사해 와야 한다. scp 를 이용하던 ftp 를 이용하던 어떻게든 복사하면 되는데, 중요한 것은 복사할 디렉토리가 chef 저장소 디렉토리이다. 이것은 자동으로 생성되는 것이 아니기 때문에 다음과 같이 수동으로 생성해주자.

위 디렉토리에 chef 서버 설치할때 만든 자격증명 파일을 복사 넣는다.

이제 knife.rb 파일을 작성한다. 이 파일 역시 ~/chef-repo/.chef 디렉토리 작성한다. 주요한 파일 내용은 다음과 같다.

이것을 기반으로 환경에 맞게 변경을 하면 다음과 같다.

이렇게 한 후에 다음과 같이 테스트 해본다.

위 에러 메시지는  chef  서버의 SSL 인증서가 없어서 나는 오류다. 오류가 나왔지만 위 메시지만으로 chef 서버와 통신은 성공했다는 것을 알 수 있다. 이제부터는 knife  명령어로 chef  서버와 명령어를 주고받을 수 있다. SSL 인증서가 없다고 하니 chef 서버로부터 받아오자

다시 다음과 같이 나오면 정상적으로 작동하는 것이다.

 

Chef 서버 설치하기 – Part 2

이번 시간에는 Chef 서버를 설치해보도록 한다. 설치에 앞서 Chef 서버를 설치할 서버들에 대한 정보는 다음과 같다.

  • 배포판: Ubuntu 14.04.2 LTS
  • CPU: 1 core
  • RAM: 1024

여기서 중요한 것은 배포판이다. 최근들어 많은 배포판들이 init 에서 systemd 로 바꾸는 추세다. 우분투(Ubuntu)에 경우 systemd 를 도입할 생각이 없다라고 했었지만 14.10 에서 이를 뒤집어 systemd 를 도입했다. init 과 systemd 는 서버 프로그램 시작과 종료하는 방법만 다른게 아니기 때문에 이를 구분하는 것은 매우 중요하다. 여기서 설치할 14.04 는 현재 init 을 따른다.

Download

다운로드는 chef 홈페이지에서 무료로 다운로드 할 수 있다. 그런데, 약간 실망스러운게 다운로드를 하기 위해서는 여기저기 단계를 거쳐야 한다는 것이다. 무료로 다운로드 되는 링크가 바로 나오지 않고 hosted, primium 과 같은 상품을 먼저 전시하고 링크를 찾아 클릭해야만 무료 다운로드 링크가 나오는 구조다.

무료 chef 다운로드
무료 chef 다운로드

우선 서버를 설치해야 하기 때문에 Chef Server 를 다운로드 받는다. Chef Server 는 레드햇 배포판 계열과 우분투 계열은 패키지를 제공한다. 단, 제공되는 배포판 버전은 제한적일 수 있다. 우리는 우분투 14.04 배포판에서 설치할 것이고 지금 현재 Chef 홈페이지에서는 다행이도 이 배포판 버전에 패키지를 제공한다.

Installation

설치는 여러가지 방법이 있는데 여기서는 dpkg 명령어를 이용해 패키지를 설치한다. 이렇게하면 Standard 형식으로 설치가 된다.

설치는 간단하다. 하지만 여기서 끝나는 것이 아니라 이제 시작이다.

Setting

설치가 끝나다면 이제 chef 가 동작하기 위해서 설정을 해준다. chef 서버의 설정은 ‘chef-server-ctl 명령어를 이용해 거의 모든것을 할 수가 있다. Standard 형식의 설치이기 때문에 다음과 같이 해준다.

chef 서버는 다양한 서비스들이 필요하다. 이러한 것을 일일이 다하기보다는 chef 자체의 기능인 자동화 기능을 이용할 수 있는데 그것은 다음과 같다.

과정을 유심히 보면 nginx 웹서버도 설치된것을 알 수 있다.

여기서 잠깐 chef-server-ctl 는 그야말로 chef server 를 컨트롤하기위한 명령어이기 때문에 서버의 상태뿐만 아니라 각종 서비스들에 대한 설정을 변경할 수 있다. 여기서 간단히 알아보도록 하자.

상태보기

서비스 내리기

nginx 서비스를 내린 예지다. 서비스를 올릴려면 start 옵션을 주면 된다.

서비스 로그들 보기

서비스 로그들도 다음과 같이 한번에 볼 수 있다.

chef 이기 때문에 관련 서비스들 관리도 chef 로 한다.

현재 설정들 보기

각 서비스들에 설정상태를 보여준다.

간단하게 chef-server-ctl 에 대해서 알아봤다.

여기까지만 해도 사실 chef server 설치는 끝난다. 하지만 chef server 를 운영하기 위한 계정을 만들어야 할 필요가 있다.  chef-server 를 매니징할 수 있는 서버는 chef workstation 이라는 점이다. chef client 에 chef server 를 매니징 할 수는 없다. chef 로 무엇을 하기위한 관련된 모든 것은 chef workstation 에서 이루어진다고 보면 맞다.  따라서 chef server 에 접근할 수 있는 것도 오직 chef workstation 으로 한정된다.

이를 위해 다음과 같은 추가 작업이 필요하다.

  1. 관리자 계정 생성
  2. 관리자 조직 생성

관리자 계정 생성

조직 생성

위에 sbhyun.pem 와 systemv.pem 은 chef server 에 연결위한 자격증명서다. chef workstation 은 chef server 와 연결해 작업을 수행하는데, 이때 chef server 가 과연 올바른 chef workstation 연결인지를 판별하기 위해서 필요한 것이 바로 이 자격증명 파일이다. 따라서 이 자격증명 파일은 chef workstation 에 복사해주어야 한다.

따라서 이 자격증명 파일은 꼭 잘 간수해야 한다.

다음시간에는 chef workstation 설치에 대해서 알아보자.

Chef 에 대해서 – Part 1

OC_Chef_Logo

서버환경이 분산화되면서 수많은 서버들을 관리해야 문제가 생긴다. 대략 1,000대 서버에 Apache 웹서버 설정을 변경하고 그것을 적용하라고 한다면 단시간내에 어떻게 할 것인가와 같은 문제들이다.

프로그램을 개발하고 그것을 서버에서 돌리기위해서는 기본적인 인프라 관리가 필수인데 최근에 글로벌 서비스가 많아지면서 분산된 대랭의 서버들을 어떻게 다룰것인가 하는 문제대한 해답으로 Chef, Puppet 과 같은 인프라스트럭쳐 자동화 프로그램들이 등장했다.

이 문서는 Chef 에 대한 기초적인 내용을 다룬다. 범위는 다음과 같다.

  • Chef 에 대해서
  • 설치
  • 레시피, 쿡북 작성
  • 다양한 예제들.

Chef 에 대해 

Chef 는 서버나 애플리케이션을 쉽게 배포하기 위한 시스템이나 클라우드 인프라 자동화 프레임워크이다. 여기서 중요한 것이 프레임워크(Framework) 라는 사실이다.

시스템이나 애플리케이션을 배포한다는 개념을 단순하게만 봤을때 그냥 관련 파일들을 배포하면 된다. 하지만 대량의 시스템은 다양한 변수들이 존재하고 이러한 변수들을 모두 수용하고 조작하기 위해서는 프로그래밍만한 방법도 없다.

Chef 는 Ruby 로 작성되었다. 따라서 Chef 를 확장하거나 커스터마이징을 하고 싶다면 Ruby 를 잘 알아야 한다. 특히나 특정 조건에 한해 특정 시스템이나 애플리케이션에만 적용되도록 무언가를 만들고 싶을때 Ruby 프로그래밍 지식은 많은 도움이 된다.

Chef 서버 구성도
Chef 서버 구성도

Chef 의 서버 구성은 다음과 같다.

Chef 는 이와같이 Server, Workstation, Client(Node) 로 나뉜다.  Client 는 Chef 에서는 Node 라 불리며 자동화를 시킬 서버 혹은 클라우드 시스템이다. Server 는 Chef 의 모든 것이다. 배포할 Node 목록과 이 Node 들에 대한 정책을 적용할 Rule, 각종 설정내용을 저장하는 저장소, 손쉽게 Node 를 추가하고 정책들을 적용하기 위한 웹 매니저 등을 포함한다. 물론 모든 작업은 Command-line 으로 가능하다. Workstation 은 배포할 애플리케이션에 대한 설정이나 명령어들을 만드는 서버다. Chef 에 이렇게 Node 적용하기 위한 것을 레시피(Recipe) 라고 부르며 레시피 묶음을 쿡북(Cookbook) 이라고 부른다.

당연한 이야기지만 위 서버들이 모두 필요한 것은 아니다. 단일 서버에 Chef 구성이 모두 포함될 수 있다. 아니면,  Server 와 Workstation 을 한 서버에서 모두 구성할 수 있다.

Chef 구성도
Chef 구성도. (출처:Chef 문서)

이러한 개념들은 다음과 같이 Chef 구성도로 나타낼 수 있다.  Chef 를 가지고 할 수 있는 주요한  것들을 나열해 보면 다음과 같다.

  1. 시스템에 명령어 보내고 출력값을 받기
  2. 각종 프로그램 설정 파일들 배포하기
  3. 서비스 프로그램 정지, 시작, 재시작하기
  4. 각종프로그램 설치 – 패키지 설치 or 컴파일 설치

서버나 클라우드 시스템을 다룰때에 대부분은 위 네가지 경우로 수렴된다. Chef 를 이용해 위와같은 작업을 할 경우에는, 첫째로 시스템을 등록하고(이걸 Node라 부른다) 두번째로 레시피를 작성한다. 셋째로 그 레시피를 쿡북에 반영시키고 넷째로 Node 에 명령어를 보내면 Node 는 쿡북을 다운받아 그것을 실행 시켜준다.

그래서 Chef 서버가 모두 구성되고 나서부터 대부분의 작업은 Workstation 에서 다 이루어진다고 보면 된다.

물론 인프라 관리 자동화 프로그램으로 Chef 만 있는 것이 아니다. Puppet 도 나름 꽤 유명하다. 하지만 내가 보기에 Chef 만큼이나 쉽고 간단한 것은 없는 것 같다. 용어들도 마치 시스템 관리를 요리에 빗대어 놓은것도 재미와함께 이해력을 높여준다. 실제로 Workstation 에서 뭔가를 할때에 쓰이는 도구가 나이프(knife)다. 요리를 할때 칼질은 기본이지!!

Chef 에 대해서 간단히 알아봤다. Chef 구성도를 보면 참 많은 것들이 눈에 들어오는데, 지금은 몰라도 된다. 왜냐하면 나도 모르니까. 차차 알아가면 될 문제이니 너무 서둘을 필요는 없을듯 싶다.

다음 시간에는 Chef Server 설치에 대해서 알아보자.

snmpd 로 인해 발생한 시스템 접속 불가 문제

제가 운영하는 시스템에는 snmpd 가 기본으로 서비스되고 있습니다. 각종 시스템의 상태를 파악하기 위해서 snmpd 를 활용하는 거지요. 그런데, 얼마전에 이 snmpd  때문에 아주 큰 문제가 된 일이 있었습니다.

이 문서는 그것이 무엇이며 왜 발생했고 어떻게 처리하는지에 대한 문서 입니다.

snmpd

snmpd 는 국제표준으로 IT기기에 각종 상태들을 네트워크를 통해서 제공할 수 있도록 설게된 SNMP를 제공하는 데몬이다. 수 많은 서버에 기본으로 탑재되어 있어 별다른 노력없이 사용이 가능하다.

리눅스 플랫폼에서 snmpd 를 사용하는데 있어 현재 인자값 사용에 문제가 있다. 인자값의 잘못된 사용으로 인해서 리눅스 전체 시스템에 미치는 영향은 치명적이다 못해 시스템을 재부팅한다하더라도 콘솔접속이 되지 않는한 문제를 해결될 수 없다.

Problems

대부분의 리눅스는 많은 배포판을 이룬다. 내가 테스트한 배포판은 Ubuntu 12.0.4 LTS 와 CentOS 6, 7 이다. 여기서는 Ubuntu 배포판을 기반으로 내용을 전개할 것이다. snmpd 의 문제만 체크하면 되는 것이기에 기타 하드웨어 스펙과 배포판에 설치된 각종 라이브러리등은 중요하지 않아 기술하지 않는다.

이제 문제에 접근해보자. Ubuntu 에서 snmpd 를 설치하면 다음과 같은 파일이 설치된다.

파일내용
/etc/default/snmpdsnmpd 의 init 파일에서 사용되는 snmpd 데몬 실행 옵션
/etc/init.d/snmpdsnmpd 데몬 init 스크립트

주목해야할 파일은 ‘/etc/default/snmpd’ 파일이며 이 파일에서 주목해야할 내용은 다음과 같다.

snmpd 데몬의 기본 운영을 바꾸기 위해서는 ‘/etc/default/snmpd’ 파일에서 위 내용을 편집하면 된다.

그럼, 거두절미하고 문제를 재현해보자. 미리 경고하지만 이는 반드시 콘솔접속이 되는 테스트 서버에서 해야한다. 오직 리모트로만 접속할 수 있는 서버이고 이 문제를 재현했다면 영원히 그 서버에 접속할 방법은 없다.

옵션을 다음과 같이 바꾼다.

자세히 보지 않으면 뭐가 바뀌었는지 알수 없게 된다. ‘-Lf’ 를 빠졌다. 이렇게 바꾸고 snmpd 를 재시작하면 문제가 재현된다.

증상

snmpd 를 재시작한 터미널에서는 별다른 증상을 알 수가 없다. 이제 다른 터미널을 열고 snmpd 를 재시작한 서버에 접속해보자. 아마 다음과 같이 나올 것이다.

root 계정이던 일반 계정이든 아무 상관이 없다. 바로 이게 문제다. 아무것도 접속할 수 없다.

콘솔에서 접속해도 다음과 같은 증상이 나온다.

원인분석

원인은 ‘/etc/default/snmpd’ 에서 정의한 snmpd 의 시작 옵션에 있다. snmpd 는 다음과 같이 커맨드라인에서 시작할 수 있다.

문제는 snmpd 에서 옵션은 반드시 ‘-L’, ‘-a’ 등과 같이 – 로 시작한다. 이것이 없이 그냥 값을 주게되면 그것은 바로 [LISTENING ADDRESSES] 가 된다. 여기서 중요한 것이 [LISTENING ADDRESSES]는 어떤값들이 올수 있느냐인데 이는 snmpd 맨페이지(man)를 통해서 확인할 수 있다.

결론만 말하면 <transport-address> 없이 그냥 문자열을 주게되면 snmpd 는 그것을 Unix Domain Socket 으로 인식하게 된다. 위 맨페이지에서 마지막에 나온 설명이 이것을 말해준다.

문제가 된 옵션을 다시보면

‘/dev/null’ 은 snmpd 에서 Unix Domain Socket 으로 인식하게 된다.

/dev/null

/dev/null 은 major 1, Minor 3 값을 가지는 Char device 파일이다. 이 파일은 특수한 장치 파일인데, 실제로는 없는 존재하지 않는 커널에서 제공하는 장치파일로서 Input/Output 을 empty 화시켜준다.

이 파일들은 아주 많은 프로그램에서 사용되지는데 대표적인 것으로 sshd 가 있다.

위에서 아래쪽을 보면 TYPE 이 CHR 이며 DVICE 1,3 나오는 ‘/dev/null’ 이 보인다.

그런데, 이것을 위에 문제처럼 snmpd 의 Unix Domain Socket 으로 하게되면 /dev/null 는 더 이상 장치파일이 아닌 소켓 파일로 변경되어 이 장치를 사용하는 모든 프로그램에 문제가 발생하게 된다. 다음과 같이 이전에 장치파일이 아닌 그냥 일반파일로 변경된것을 알 수 있다.

그리고 netstat 로 보면 snmpd 가 /dev/null 을 Unix Domain Socket 으로 사용하고 있다는 것이 보인다.

해결방법

가장 좋은 방법은 아직 연결이 유지되고 있는 터미널에서 ‘/etc/default/snmpd’ 의 옵션을 고쳐주는 것이다. 그리고 반드시 재부팅을 해줘야 한다.

그런데, 재부팅을 해서는 안되는 서버라면 어떻게 해야 할까?

첫째, ‘/etc/default/snmpd’ 에서 옵션을 변경하고 snmpd 를 정지시킨다. 재시작해줘도 /dev/null 파일이 장치로 복구가 안된다.

둘째, /dev/null Unix Domain Socket 파일을 삭제한다. 더이상 장치 파일이 아니기 때문에 과감히 삭제한다.

셋째, /dev/null 파일을 다시 만들어 준다.

위와같이 장치파일을 생성해주자 마자 바로 sshd 가 복구된다.

문제의 핵심

문제는 /dev/null 를 Domain Unix Socket 이던 무엇이던간에 프로그램에서 파일이 속성을 변경되도록 했다는데 있다. 애초에 snmpd 인자로 /dev/null 을 주었던게 문제였고 그 이전에 오타발생이 문제였다.

비단 snmpd 만 인자값으로 Unix Domain Socket 을 사용한다고 생각하지 않는다. 리눅스에는 수많은 프로그램들이 존재하고 snmpd 와 같이 옵션으로 Unix Domain Socket 을 받는 경우도 분명 존재한다. 그것도 하필이면 /dev/null 를 준다면 똑같은 문제가 발생할 수 있다.

위의 snmpd 문제로 영향받는 프로그램들

위 문제(snmpd 로 발생되는 문제) 로 영향받는 프로그램들은 /dev/null 장치를 사용하는 프로그램이라면 다 영향을 받는다.

  • sshd
  • nginx ← 동작에는 문제가 없어 보이지만 재시작하면 다음과 같이 나오면서 시작되지 않는다.

  • proftpd ← 재시작하면 다음과 같이 나오면서 시작이되지만 정상적으로 동작이 되지 않는다.

  • Tomcat ← 재시작하면 다음과 같이 나오면서 시작되지만 접속하면 아무것도 안된다. 이것은 아마도 bash 이 오류를 내면서 톰캣 시작시 세팅되는 환경변수들이 셋업되지 않았기 때문인것으로 보인다.

/dev/null 이 없어짐으로 인해서 bash 가 제대로 동작하지 않아 쉘스크립트로 작성된 대부분의 init 스크립트가 제대로 동작하지 못해 대부분의 프로그램들에 문제가 발생한다.

CentOS 6,7

운이 좋게도 CentOS 7 은 배포판 패키징으로 옵션 설정이 없다.

CentOS 에서는 ‘/etc/sysconfig/snmpd’ 에 옵션 설정을 할 수 있다.

여기서 CentOS 7 에서 상태가 심각했다. CentOS 7 에서는 Init System 이 systemd 로 변경되었다. 사실 systemd 는 Init System 프로그램을 넘어서 CentOS 7 배포판의 중추신경계역활을 하게됨에 따라 지대한 영향을 미친다.

이에 따라서 systemd를 제어하는 systemctl 명령어로 그 어떤 것도 실행되지 않았다. 거기다 /dev/null 를 새로 생성하더라도 systemd 가 복구되지 않았다. 무조건 재부팅이 요구된다.

CentOS 6 에서는 ubuntu 처럼 다음과 같이 옵션이 나온다.

역시 옵션은 ‘/etc/sysconfig/snmpd’ 에서 설정할 수 있으며 주석으로 다음과 같이 되어 있다.

CentOS 6과 7의 차이

아마도 개인적인 추측인데, CentOS 7 로 넘어오면서 기본 옵션이 변경된데에는 systemd 의 도입때문으로 보인다. systemd 의 도입으로 각 데몬 프로그램들은 systemd 가 상태, 로깅들을 담당하게 되어 이전 CentOS 6 과는 다르게 각 데몬 프로그램들 각자가 로깅을 할 필요가 없게 되었다.

최종결론

어찌되었든 /dev/null 파일을 삭제하거나 일반파일로 바꾸거나 해서는 안된다. 그렇게되면 sshd 는 접속을 거부할 것이다. 혹시나 다른 방법으로 슈퍼유저인 root 로 커맨드를 날릴 수 있다면 당황하지 말고 다음과 같이하면 적어도 sshd 는 돌아온다.

그리고 ubuntu 에서 ‘/etc/default/snmpd’ 를 수정할때는 오타 를 항상 조심해야 한다.

SSH 포트 포워딩.

많은 IT 종사자들은 회사 보안 때문에 특정 서버에 포트를 오직 SSH 와 서비스를 위한 포트만을 열어둔 경우가 많다. 그런데 서버를 관리하다보면 특정 서비스 체크를 위한 매니징 서비스에 접속을 해야하는 경우가 발생한다. 이럴 경우 사내 보안팀에 매니징 서비스 접속을 위해서 포트를 개방해 줄것을 요구할 수 있지만 이럴때에 SSH 의 포트 포워딩(Port Forwarding)을 이용하면 쉽게 해결 할 수 있다.

SSH 포트 포워딩에도 다음과 같이 세가지 종류가 있다.

  • Local Port Forwarding
  • Remote Port Forwarding
  • Dynamic Port Forwarding

SSH 포트 포워딩은 SSH 서버를 Gateway 나 Proxy 서버처럼 활용해 외부 접속을 하는 것이여서 터널링(Tunneling)이라고 부르기도 한다. 각 포트 포워딩 설명을 예제상황을 가정해 설명하도록 하겠다.

192.168.96.6 서버에는 Tomcat 서버가 가동중이고 Web 접속 포트는 8180 이며 서버 상태를 체크하기 위한 JMX 가 활성화 되어 있고 이 포트는 8190 이다.

현재 이 서버는 테스트 서버여서 자체 방화벽으로 22번 포트만 개방되어 있고 Web 접속 포트와 JMX 포트가 개방되어 있지 않다.

접속하고자 하는 사용자의 PC는 리눅스를 사용한다.

위 말을 도식화 하면 다음과 같다.

Local Port Forwarding 상황

Local Port Forwarding

접속은 SSH 포트인 22번만 열려있고 Tomcat 관련 포트는 리눅스 서버의 로컬 방화벽으로 막혀 있는 상황이라고 가정하자.

이제 Tomcat 서비스에 접속을 하고 싶다면 어떻게 해야하는 걸까? 이럴때 사용하는 것이 바로 Local Port Forwarding 이다. 형식은 다음과 같다.

ssh 의 ‘-L’ 옵션이 바로 Local Port Forwarding 을 하도록 해주는 것이다. <local port> 는 접속하는 클라이언트에서 사용할 포트이며 <Remote Server> 는 접속할 서버(여기서는 192.168.96.6) 를 Gateway 로 이용해 접속할 서버, <Remote Port>는 Remote Server 의 포트이다.

여기서 한가지 주목해야할 것이 [SSH 서버] 는 Gateway 역활을 할 뿐이라는 사실이다. 예를 들어 [SSH 서버] 에서는 외부로 모든 접속이 가능하다라고 가정했을때에 yahoo.com 의 80 포트로 Local Port Forwarding 은 다음과 같다.

위와같이 한후에 클라이언트 PC(여기서는 왼쪽에 있는 컴퓨터)에서 웹 브라우져를 켜고 주소창에 ‘http://localhost:10030’ 이라고 하면 yahoo.com 이 열리게 된다.

다시 가정한 상황으로 돌아오면 Gateway 서버(여기서는 192.168.96.6서버) 외부가 아닌 그 자체의 서비스들을 포워딩할 것이기에 다음과 같이 하면 된다.

이렇게 한 후에 웹 브라우져를 실행하고 주소창에 ‘http://localhost:10030’ 이라고 입력하면 192.168.96.6 서버의 Tomcat 서버 포트인 8180 에 연결되고 톰캣 페이지가 보이게 된다.

Local Port Forwarding 이기 때문에 웹 브라우져에서의 접속 서버명은 항상 localhost 가 된다.

Remote Port Forwarding 

이것은 필자가 아직 다루어보지 못했기에 설명을 생략한다.

Dynamic Port Forwarding

이 포워딩은 접속하는 서버를 SOCKS Proxy 서버로 동작하도록 한다. Local Port Forwarding 에서 접속하는 서버는 Gateway 서버로 동작을 했지만 이 포워딩은 접속하는 서버를 Proxy 서버로 그것도 SOCKS 동작하게 한다.

Proxy 서버이기 때문에 클라이언트에서 접속할때에는 항상 실제 접속을 하는 서버와 포트를 사용하면 된다.

JDK 1.7 이상부터는 JMC(Java Mission Control) 이 함께 설치된다. 이걸 이용하면 Java 애플리케이션의 각종 정보를 볼 수 있는데, 물론 JMX 에 접속도 가능하다. 위 예제 상황에서 Dynamic Port Forwarding 을 이용해 접속해보자.

사용방법은 간단하다.

위와같이 하게되면 192.168.96.6 서버가 포트 10030 으로 Proxy 서버로 역활을 하게된다. 이제 클라이언트에서 JMC 를 구동하고 다음과 같이 Network 설정을 해준다.

JMC Socks Network 설정

그리고 나서 JMX 접속 서버와 포트는 실제 접속을 하기 위한 192.168.96.6 과 8190 으로 해주면 접속이 이루어진다.

JMC 접속 완료

디바이스를 이용한 화면전송

리눅스에 접속되어 있는 상태에서 상대방에게 화면을 전송하고 싶다면 디바이스를 이용한 화면전송 을 이용하면 됩니다. 방법은 아주 간단합니다.

우선 텔넷이나 ssh로 두분이 같은 시스템에 접속 합니다.

저의 디바이스(가상 터미널)명을 찾아야 합니다.
#tty 이 명령어를 입력하시면 다음과 같은 가상터미널이 나타납니다.

그럼, 함께 접속된 상대방의 디바이스(가상터미널)명을 또 찾아야 합니다.
#w 이 명령어를 입력하시고 고객이 잡고 있는 가상터미널을 찾거나
만일 어떤 가상 터미널을 잡고 있는지 잘 모르겠으면 고객에게
tty 명령어를 입력하여 나타나게 되는 가상터미널 번호를 알아
내시면 됨니다. 예) /dev/pts/2 이 나타났다고 가정 하구요.

그럼, 제가 접속한 화면에서 아래와 같은 명령어를 입력하시면 같은 시스템
에 접속된 상대방의 화면이 저의 제어권으로 넘어 오게 됨니다.

자주 사용하지는 않아도 아주 가끔 사용하는 것이오니 참고 하시라구 장황
하게 몇자 적습니다.

그리고, 종료 하실려면 exit 입력하시면 됨니다.

Proxy 서버 개념

Forward Proxy

forward proxy
Forward proxy

포워드 프락시(Forward Proxy)는 클라이언트가 타켓서버(목표서버)의 주소를 받아서 타켓서버로 연결을 시켜준다. 클라이언트는 타켓서버의 주소를 요청하면 프락시 서버는 뒷단에 타켓서버의 주소를 가진 서버에 연결을 포워딩 한다. 프락시 서버는 타켓서버의 주소를 가지고 있지 않다.

Reverse Proxy

Reverse Proxy
Reverse Proxy

리버스 프락시(Reverse Proxy)는 타켓서버의 주소가 아닌 프락시 서버가 타켓서버의 주소를 가지고 있고 프락시 서버가 이를 받아서 뒷단에 실제 타켓 서버로 연결을 시켜준다. 그러니까 타켓서버의 주소를 프락시서버가 가지고 있어야 하며 클라이언트는 타켓서버의 주소로 요청을 하면 프락시 서버가 응답을 하게 된다.

High Availability – Cold, Warm, Hot

이글은 다음의 내용을 번역한 것입니다.

클러스터링(Clustering) 은 소프트웨어, 하드웨어, 데이터 이중화 도입이 필요한 어떤 서비스에 대해 고가용성(High Availability) 구현을 위한 가장 일반적인 기술이다. 실패한 클러스터링 소프트웨어에서는 즉각적으로 관리자 개입이 필요없이 대기(standby) 시스템에 애플리케이션이 시작된다. 소프트웨어 이중화의 타입에 따라서 고가용성이 제공되어질 클러스터들은 다음과 같은 설정들로 구성되어질 수 있다.

  • Cold Standby: 보조 노드는 다른 동일한 기존 시스템의 백업처럼 동작 한다. 이 보조 노드는 처음으로 기존 노드가 고장이 발생했을때만 설치되어지고 구성되어진다. 그리고 나서, 기존 노드가 실패할때에 보조 노도는 켜지고 마지막으로 실패된 컨포넌트가 시작되기 이전 데이터로 복구되어진다. 기존 시스템의 데이터는 스토리지 시스템으로 백업되어질 수 있고 필요할때마다 보조 시스템으로 복구되어질 수 있다. 이것은 일반적으로 몇 시간의 복구 시간을 제공 한다.
  • Warm Standby: 소프트웨어 컨포넌트는 보조 노드에 설치되어지고 활용되어진다. 보조 노드는 켜지고 운영된다. 기존 노드가 실패할때에 이러한 소프트웨어 컨포넌트들은 보조 노드에서 시작되어진다. 이 과장은 일반적으로 클러스터 매니저를 사용해 자동화된다. 데이터는 정기적으로 공유 디스크나 디스크 기반 리플레케이션을 사용해 보조 노드 시스템에 미러(mirror) 된다. 이것은 일반적으로 몇분의 복구 시간을 제공한다.
  • Hot Standby: 소프트웨어 컨포넌트들은 기존 노드와 보조 노드 양쪽 모두에 설치되어지고 활용되어 진다. 보조 시스템의 소프트웨어 컨포넌트들은 켜져 있지만 데이터를 처리하거나 요청을 처리하지 않는다. 데이터는 거의 실시간으로 미러(mirror) 되고 양쪽 시스템은 동일한 데이터를 갖는다. 데이터 리플리케이션은 전형적으로 소프트웨어의 기능을 통해서 이루어진다. 이것은 일반적으로 몇초의 복구 시간을 제공한다.
  • Active-Active (Load Balanced): 이 방법에서는 기본과 보조 시스템들은 Active 이고 병령로 요청을 처리중이다. 데이터 리플레케이션은 소프트웨어 기능을 통해서 행해지고 양방향이 될 수 있다. 이것은 일반적으로 순간적 복구 시간을 제공 한다.

 

SNMP Extend

snmpd 는 시스템의 자원들에 대해서 SNMP 프로토콜을 통해서 볼 수 있는 기능을 제공 한다. 그런데, 알고 싶은 자원들에 대한 목록들을 조회하기 위해 MIB 값들이 할당되어 있으며 자주 사용되는 운영체제, 라우터, 스위치 같은 장비들에 대한 MIB 값들을 미리 할당되어 전 세계적으로 표준으로 재정해 사용하고 있다.

그런데, 표준으로 재정된 MIB 값외에 사용자가 필요한 자원들을 조회하기 위한 MIB 값을 등록해야 하는데 이때 사용하는 것이 SNMP Extend 를 사용하면 된다.

SNMP Extend 는 ‘.1.3.6.1.4.1.2021.8.10’ 같은 MIB 에 조회하고자하는 값들을 등록하면 된다.

예를들면 다음과 같다.

이렇게 하면 ‘.1.3.6.1.4.1.2021.8.10.101’ 를 뿌리로하는 MIB 를 조회하면 iostate 으로 조회된 값이 등록되어 SNMP 프로토콜을 이용해서 원격에서도 조회가 가능하다.

테스트를 해보면 snmpwalk 명령어를 이용해서 다음과 같이 해보자

‘-v 1’ 은 snmpd 의 version 1 을 지정해주는 것이다. 만일 이게 안된다면 ‘-v2c’ 로 지정해서 해보자

이렇게해서 무언가 나온다면 정상이다.

만일 ‘Timeout’ 에러 메시지를 만단다면 다음과 같이 퍼미션을 조정해주자.

흥미롭게도 snmpd 는 /etc/hosts.allow, /etc/hosts.deny 두개의 파일을 참조하는데, 퍼미션이 없다면 ‘Timeout’ 이 오류를 내다.

HyperText Transfer Protocol

HyperText Transfer Protocol 은 인터넷 미디어를 전송하기 위한 규약이다. 인터넷 미디어라는 단어를 쓰기는 했지만, 요즘에는 인터넷을 통해서 못하는게 없을 정도로 인터넷 미디어를 규정하는 매체의 경계는 없다. 따라서 “인터넷 미디어를 전송하기 위한 규약”은 구시대적인 정의이며 차라리 “인터넷을 이용한 웹을 사용할 경우에 쓰이게되는 규약” 정도가 더 잘 맞는듯 하다.

HyperText 는 텍스트를 가지는 노드사이에 지역적인 링크(이걸 HyperLink라 한다)를 사용하는 구조적 텍스트를 말한다. 쉽게 말해서 웹사이트에서 링크를 클릭하면서 텍스트를 불러오는 텍스트 구조를 말하는 것이다.

History

Tim Berners-Lee
Tim Berners-Lee

1989년 CERN (유럽 입자 물리학 연구소) 에 근무하던  Tim Berners-Lee 는 각국에서 온 연구원들과 수많은 논문들을 컴퓨터를 이용해 공유할 방법을 궁리하고 있었다. 박사들의 논문들은 간단한 텍스트와 수식이 전부였는데, 이것을 컴퓨터로 표현하기 위한 손쉬운 방법을 궁리했는데, 그건 프로그래머 수준의 교육을 받은자가 아닌 어떤 규칙성만 알면 손쉽게 만들수 있도록 하는데 초점이 있었다.

여러가지 가능성을 연구하던중에 마크업(MarkUp)  언어로 간단한 규칙만으로 논문들을 공유할 수 있도록 HTML 을 만들어낸다.

문제는 주석이였다. 각종 논문에는 글의 중간중간에 어려운 단어의 해석을 위해서 주석을 붙이곤 했고 논문에 뒷부분에는 참고문헌들을 나열하여 추가적으로 필요한 자료들을 찾아보도록 되어 있었다.

어떻게하면 이러한 수많은 정보들을 손쉽게 접근할 수 있을까라는 생각 끝에 HyperLink 라는 개념이 나오고 이러한  HyperLink 를 포함하는 구조적인 텍스트로서 HTML 이 만들어졌으며 이를 전송하기위한 프로토콜로서 HTTP 를 만들어낸다.

Tim Berners-Lee 는 HTML, HTTP, 그리고 이것을 이용할 오늘날의 웹 브라우저를 만들어냈다. 그것도 1990년대 일이였으며 이렇게해서 제작한 것을 CERN 연구소에서 1991년 8월 6일날 첫번째 웹 문서가 온라인에 게재된다. 이때 이용한 HTTP 의 버전이 바로 0.9 버전이다.

그가 만든 HTML, HTTP 웹 브라우저는 로열티도 없는 무료였으며 많은 회사들이 이에 관심을 가지고 웹(web)의 발전에 기여하도록 만든다. 이러한 그의 노력은 World Wide Web 이라는 단어를 세상에 알리는 계기가 되면서 1994년에 W3C (World Wide Web Consortium) 이 창립되게 이른다.

HTTP 버전.

  • 1991년 HTTP 0.9
  • 1996년 HTTP 1.0
  • 1999년 HTTP 1.1

HTTP 특징.

HTTP 의 가장 큰 특징은 다음과 같다.

  1. 클라이언트(Client) 로부터 요청이 있어야만 한다.
  2. 모든 필요한 HyperText 를 서버가 클라이언트로 전송이 끝나면 서버와의 연결은 해제된다.

HTTP 은 클라이언트가 서버로 연결을 이루고 필요한 HyperText 를 전송받고 연결을 해제하는 세가지 방법으로 동작한다. 필요한 HyperText 를 다 전송하고 나면 연결을 해제한다는 것, 즉 연결지향이 아닌 비연결지향이라고 해서 “Connectionless Protocol” 이라고도 한다.

클라이언트가 서버로 연결을 요청해야만 무언가를 할 수 있다는 것도 중요한데, 이는 서버가 클라이언트를 먼저 연결 요청을 할 수 없다는 것이다.

또, HTTP 는 TV 방송처럼 서버에서 동작하는 것을 보기위한 TV 같은 것이 아니라 서버에서 필요한 자원들을 전부 다운로드 받아서 클라이언트의 웹 브라우저에서 플레이를 해주는 것이다.

따라서 웹(Web)이라는 것은  HTTP 는 서버로부터 HTML 을 구성하는 자원들을 모두 클라이언트에 모두 가지고 와서 클라이언트가 웹 브라우저를 이용해서 보여주는 것이다.

HTTP 구조.

HTTP 는 HTML 을 전송하기 위한 프로토콜이다. 이것을 만들었을 당시에 대상이 연구 논문이였다는 점을 감안하면 최대한 단순한 구조로 만들어져있다는 건 놀라운 일이 아니다.

HTTP 는 Header 와 Body 로 구분되어진다.

Structure of a request message
Structure of a request message.(http://www.icodeguru.com/dotnet/core.c.sharp.and.dot.net/0131472275/ch17lev1sec1.html)

Header 에는 메소드(Method), URI, HTTP 프로토콜과 버전을 비롯한 각종 정보들을 포함하고 Body 에는 클라이언트가 서버에 요청할 내용이 들어간다. 메소드가 GET 일 경우에 QueryString 의 경우가 바로 Body 다.

HTTP 구조에서 Header 들어가는 내용은 HTTP 버전별로 차이가 있다. 주요한 차이는 다음과 같다.

분류HTTP 1.0HTTP 1.1
Pragma지원미지원
Cache-Control미지원지원
Transfer-Encoding미지원지원
Content-Language미지원지원
Connection미지원지원
Accept미지원지원
Accept-Charset미지원지원
Accept-Encoding미지원지원
Accept-Language미지원지원
Host미지원지원
GET지원지원
POST지원지원
HEAD지원지원
OPTIONS미지원지원
PUT미지원지원
DELETE미지원지원
TRACE미지원지원

HTTP 1.0 과 HTTP 1.1 이 가장 큰 차이점이라면 바로 Connection 헤더이며 이 값이 Keep-Alive 를 지원 여부이다. HTTP 1.1 은 Keep-Alive 를 지원해 다수 접속의 요청과 연결을 줄이고 한번의 연결로 다수의 데이터를 전송받을 수 있게 해준다.

이러한 HTTP 는 웹을 보여주는 웹 브라우저와 서버간의 통신이며 기본적으로 메타데이터를, 이는 텍스트 데이터여서 사람이 눈으로 읽을 수 있다, 주고받는 것이여서 이것을 캡쳐해서 볼 수 있다.

HTTP 통신 들여다 보기.

HTTP 통신은 웹 브라우저와 서버간의 통신으로 이를 들여다 볼 수 있다. 여기서는 Telnet 을 통해서 서버에 요청을 보내고 받아보는 방법을 소개한다.

이것은 브라우저가 해야하는 것을 Telnet 이 대신하는 것이라고 보면 되며 실제 웹 브라워져와 서버와의 통신이 어떻게 이루어지는지를 극명하게 보여주는 실제 예라 할 수 있다.

먼저 Telnet 을 이용해서 서버에 다음과 같이 접속을 한다.

linux.systemv.pe.kr 를 했지만 아무 웹 사이트나 상관이 없다. 중요한 것은  “직접입력”,”Enter 쳐준다” 같이 직접 해준 것이다. 이 부분이 바로 웹 브라우져가 웹 서버에 요청을 하는 아주 간단한 방법이다.  위 방법에는 body 가 없다. 그런데도 서버로의 요청이 전달되고 응답도 정상으로 나온다.

응답은 정확하게 Header 와 Body 로 나뉘어 나온다.  주목해야 하는 것은 바로 Header 이다.

응답 Header 는 HTTP 버전과 함께 HTTP 응답 코드로부터 시작한다. 그리고 응답하는 컨텐츠가 어떤 타입인지, 텍스트 인지 그림파일인지 아니면 바이너리 파일인지등, 을 명시하고 있으며 body 의 길이도 보여주고 있으며 현재 연결 상태가 어떤것인지도 나타내고 있다.

Telnet 말고 다른 툴들도 있는데, 여기서 몇개를 소개한다.

Internet Explorer 11 개발자 도구

Windows 운영체제에서 가장 많이 사용하는 Internet Explorer 11 에는 개발자 도구라는 것이 있다. 정확하게는 웹 개발자 도구인데, 단축키 F12 이며 이것을 누르면 브라우져 아래에서 창이 올라온다.

IE11의 개발자 도구
IE11의 개발자 도구

여기에서 “네트워크” 메뉴를 클릭하면 위 화면과 같은 상태가 된다. 이제 왼쪽에 초록색 플레이 단추를 누르고 주소창에 웹 사이트 주소를 입력해서 엔터를 쳐보자.

IE11 개발자도구 네트워크 요약
IE11 개발자도구 네트워크 요약

그러면 위와 같이 웹 브라우저가 입력한 웹 사이트로부터 내려받은 웹 컨텐츠들에 대한 정보와함께 보여준다. 내려받은 웹 컨텐츠의 정보로는 유형, 받은 용량, 받는데 걸린 시간등이다.

이제 위 내려받은 컨텐츠중에 하나를 클릭하고 왼쪽에 ‘자세히’를 클릭하면 아래와 같이 HTTP 정보가 나온다.

IE11 개발자도구 네트워크 상세 정보
IE11 개발자도구 네트워크 상세 정보

아주 보기 편하도록 각각 필요한 정보들을 분류하고 내용들을 잘 보여준다. 이쯤되면 유료 소프트웨어 못지 않다.

Safari

Safari 웹 브라우저에서도  IE11 과 같은 툴을 제공한다. Safari 를 실행하고 “웹 속성보기”혹은 마우스 오른쪽 버튼을 클릭해 요소검사를 실행하면 아래쪽에 IE11 과같이 창이 올라온다.

Safari HTTP 보기
Safari HTTP 보기

여기서 왼쪽에 “타임라인” 클릭하고 페이지를 다시 한번 릴로드 하거나 주소창에 웹 사이트 주소를 입력하고 엔터를 친다. 그러면 타임라인에 시간들이 그려지고 왼쪽에 컨텐츠들이 나오며 그것을 클릭하고 오른쪽에 “리소스” 를 클릭하면 이 컨텐츠의 상세한 정보가 나오면서 HTTP 이 내용을 볼 수 있다.

FireFox

FireFox 웹 브라우저에도 “요소검사” 를 통해서 각 웹 컨텐츠별로 HTTP 의 내용을 아래와 같이 살펴볼 수 있다. “네트워크” 탭을 클릭한 후에 주소창에 웹 사이트 주소를 입력해 엔터를 치면 왼쪽에 웹 사이트의 컨텐츠들이 표시되며 클릭을하면 HTTP의 상세한 정보를 보여준다.

Firefox HTTP 분석
Firefox HTTP 분석

 

Fiddler

Fiddler 는 Web Debugger 이며 독립된 소프트웨어 이다. 무료여서 누구나 사용할 수 있다. 설치를한 후에 실행을 하면 곧바로 HTTP 들을 캡쳐하기 시작하며 어떤 웹 브라우져를 사용하던지간에 HTTP를 캡쳐해준다.

Fiddler
Fiddler

전송된 컨텐츠에 대해서 매우 상세한 정보를 보여주는 전문적인 툴이다.

HTTP 프로토콜이 무엇인지부터해서 이것을 눈으로 직접확인해 볼수 있는 방법까지 간단하게 살펴봤다. 위 내용이 전부가 아니며 아주 기초적인 내용에 불과할 뿐이라는 사실을 상기할 필요가 있다. HTTP 는 아주 간단하지만 위에서 기술한 것보다 훨씬 다양하고 체계적인 내용들이 다수 포함되어 있다.

웹 개발자이거나 웹 서버를 다루는 사람이라면 이러한 툴들을 가까이하는 것이 좋다. 주로 보안 쿠키를 검사하거나 보이지 않은 헤더의 변조가능성등을 살펴봐야하는 때에는 이러한 방법들이 기초적인 추적의 실마리를 제공할 수도 있다.