git 를 사용하다 보면 local 저장소에서 실수로 파일을 삭제하는 실수를 저지를 수 있다. 이때 파일을 되살린다고 ‘git pull’ 이나 ‘git fetch’를 해봐도 나오는 메시지는 최신판(Already up-to-date)라는 것이다.
이를 이용하는 경우에 어떻게 해야하나?
먼저 삭제한 디렉토리로 이동한다. 그리고 다음과 같이 입력을하면 삭제한 파일 목록을 얻을 수 있다.
|
1 |
]$ git ls-files -d |
사실 삭제된 파일은 다시 checkout 받으면 된다. 다음과 같이 말이다.
|
1 |
]$ git checkout a.py |
리눅스를 잘 다루는 사람이라면 이것을 한번에 할수 있다.
|
1 |
]$ git ls-files -d | xargs git checkout -- |
앞에서 chef 운영을 위한 server와 workstation 을 설치했다. 이제 chef 를 가지고 관리를 할 대상인 서버에 chef client 를 설치하는 방법에 대해서 설명한다.
chef 에서 관리해야할 대상 서버를 Node혹은 Client 라고 부른다. 이러한 서버들은 chef server와 통신을 통해서 각종 작업을 수행하는데, 이 역활을 담당하기는게 바로 chef-client 이다.
chef client 설치는 서버에 직접 들어가서 프로그램을 설치하고 관련 파일을 업데이트하는 작업을 통해서도 할 수 있지만 Chef 스럽게 workstation에서 knife 명령어를 이용해서 간단히 Chef Client 를 설치할 수 있다. 이뿐 아니라 설치와함께 이 서버를 Chef Servr 에 관리대상 서버로 등록해준다.
설치에 앞서 Chef Client 가 될 서버에서 Chef Server 에 호스트네임과 IP를 다음과 같이 등록해준다.
|
1 |
192.168.96.24 chefserver |
Chef Client 설치는 Chef Workstation 에서 다음과 같이 명령어로 진행한다.
|
1 |
knife bootstrap 192.168.96.6 -N test2 -x orion -P password --sudo --use-sudo-password |
이 한줄이면 아무것도 없는 서버에 Chef Client 가 설치되고 Chef Server 에 Node로 등록된다.
아무 위에처럼하면 Chef-client 가 설치가 되어도 Chef Server 와 통신문제를 겪게 된다. 다음과 같은 오류 메시지를 받게 될 것이다.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 |
Starting Chef Client, version 12.4.0 Creating a new client identity for test2 using the validator key. ================================================================================ Chef encountered an error attempting to create the client "test2" ================================================================================ Authentication Error: --------------------- Failed to authenticate to the chef server (http 401). Server Response: ---------------- Failed to authenticate as 'systemv'. Ensure that your node_name and client key are correct. Relevant Config Settings: ------------------------- chef_server_url "https://chefserver/organizations/systemv" validation_client_name "systemv" validation_key "/etc/chef/validation.pem" If these settings are correct, your validation_key may be invalid. Running handlers: [2015-06-26T00:22:06+09:00] ERROR: Running exception handlers Running handlers complete [2015-06-26T00:22:06+09:00] ERROR: Exception handlers complete Chef Client failed. 0 resources updated in 5.729573691 seconds [2015-06-26T00:22:06+09:00] FATAL: Stacktrace dumped to /var/chef/cache/chef-stacktrace.out [2015-06-26T00:22:06+09:00] ERROR: 401 "Unauthorized" [2015-06-26T00:22:06+09:00] FATAL: Chef::Exceptions::ChildConvergeError: Chef run process exited unsuccessfully (exit code 1) |
핵심은 인증키인 validation_key 가 맞지 않다는 것이다.
Chef Workstation 에서 Chef Client 설치 명령어를 수행하면 Chef Client 에 접속해 Chef Client 최신버전은 chef-12.4.0-1 버전을 더운받아서 설치하고 Chef Client 설정파일들이 /etc/chef 디렉토리에 모인다.
|
1 2 3 4 5 6 |
[root@test2 chef]# ls -lh 합계 12K -rw------- 1 root root 1.7K 6월 26 21:35 validation.pem -rw-r--r-- 1 root root 187 6월 26 21:35 client.rb -rw-r--r-- 1 root root 16 6월 26 21:35 first-boot.json drwxr-xr-x 2 root root 27 6월 26 21:35 trusted_certs |
그중에 validation.pem 파일이 맞지 않다는 것이다.
Chef Server 는 Chef Client 와 통신을 위해서 공개키/비밀키 기반으로 한다. Chef Server 는 공개키를 각 Chef Client 에 제공하고 Chef Client 는 비밀키를 Chef Server 에 보낸다. 그러면 통신을 할때에 이것을 가지고 인증을 한다.
하지만 chef-12.1 이상 버전부터는 이 키, 더 정확하게는 validation.pem 이 필요없게 되었다. 이에 대한 내용은 다음 링크에서 확인할 수 있다.
결국에는 Chef Workstation 이 가지고 있는 공개키를 삭제하면 된다는 것이다.
|
1 |
~/chef-repo/.chef$ rm -f systemv.pem |
그리고 난 후에 방금 실패했던 Chef Client 에서 /etc/chef 디렉토리를 삭제한다.
|
1 |
rm -rf /etc/chef |
Chef Workstation 에서 다시 한번 bootstrap 명령어를 주면 Chef Client가 다음과 같이 설치되고 Node 로 등록된다.
|
1 2 3 4 5 6 7 8 9 10 11 |
192.168.96.6 Starting first Chef Client run... 192.168.96.6 Starting Chef Client, version 12.4.0 192.168.96.6 resolving cookbooks for run list: [] 192.168.96.6 Synchronizing Cookbooks: 192.168.96.6 Compiling Cookbooks... 192.168.96.6 [2015-06-26T21:35:53+09:00] WARN: Node test2 has an empty run list. 192.168.96.6 Converging 0 resources 192.168.96.6 192.168.96.6 Running handlers: 192.168.96.6 Running handlers complete 192.168.96.6 Chef Client finished, 0/0 resources updated in 12.848701442 seconds |
|
1 2 3 4 5 |
]$ knife node list test2 ]$ knife client list systemv-validator test2 |
Chef Workstation 에서 등록 확인.
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 홈페이지에서 다운로드 가능하다. 레드햇과 우분투 배포판 패키지가 준비되어 있어 패키지를 다운받아 설치하면 된다.
|
1 2 3 4 5 6 7 |
dpkg -i chefdk_0.6.2-1_amd64.deb Selecting previously unselected package chefdk. (데이터베이스 읽는중 ...현재 301009개의 파일과 디렉터리가 설치되어 있습니다.) Preparing to unpack chefdk_0.6.2-1_amd64.deb ... Unpacking chefdk (0.6.2-1) ... chefdk (0.6.2-1) 설정하는 중입니다 ... Thank you for installing Chef Development Kit! |
이제 chef 명령어를 이용해서 알맞은 환경을 조성할 수 있도록 다음과 같이 해준다.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 |
]# chef verify Running verification for component 'berkshelf' Running verification for component 'test-kitchen' Running verification for component 'chef-client' Running verification for component 'chef-dk' Running verification for component 'chefspec' Running verification for component 'rubocop' Running verification for component 'fauxhai' Running verification for component 'knife-spork' Running verification for component 'kitchen-vagrant' Running verification for component 'package installation' Running verification for component 'openssl' .............. --------------------------------------------- Verification of component 'rubocop' succeeded. Verification of component 'knife-spork' succeeded. Verification of component 'openssl' succeeded. Verification of component 'berkshelf' succeeded. Verification of component 'chef-client' succeeded. Verification of component 'fauxhai' succeeded. Verification of component 'test-kitchen' succeeded. Verification of component 'kitchen-vagrant' succeeded. Verification of component 'chef-dk' succeeded. Verification of component 'chefspec' succeeded. Verification of component 'package installation' succeeded. |
앞에서 chef 서버 설치하면서 만들어놓은 자격증명 파일을 복사해 와야 한다. scp 를 이용하던 ftp 를 이용하던 어떻게든 복사하면 되는데, 중요한 것은 복사할 디렉토리가 chef 저장소 디렉토리이다. 이것은 자동으로 생성되는 것이 아니기 때문에 다음과 같이 수동으로 생성해주자.
|
1 |
mkdir ~/chef-repo/.chef |
위 디렉토리에 chef 서버 설치할때 만든 자격증명 파일을 복사 넣는다.
이제 knife.rb 파일을 작성한다. 이 파일 역시 ~/chef-repo/.chef 디렉토리 작성한다. 주요한 파일 내용은 다음과 같다.
|
1 2 3 4 5 6 7 8 9 10 |
current_dir = File.dirname(__FILE__) log_level :info log_location STDOUT node_name "name_for_workstation" client_key "#{current_dir}/name_of_user_key" validation_client_name "organization_validator_name" validation_key "#{current_dir}/organization_validator_key" chef_server_url "https://server_domain_or_IP/organizations/organization_name" syntax_check_cache_path "#{ENV['HOME']}/.chef/syntaxcache" cookbook_path ["#{current_dir}/../cookbooks"] |
이것을 기반으로 환경에 맞게 변경을 하면 다음과 같다.
|
1 2 3 4 5 6 7 8 9 10 |
current_dir = File.dirname(__FILE__) log_level :info log_location STDOUT node_name "sbhyun" client_key "#{current_dir}/sbhyun.pem" validation_client_name "systemv" validation_key "#{current_dir}/systemv.pem" chef_server_url "https://chefserver/organizations/systemv" syntax_check_cache_path "#{ENV['HOME']}/.chef/syntaxcache" cookbook_path ["#{current_dir}/../cookbooks"] |
이렇게 한 후에 다음과 같이 테스트 해본다.
|
1 2 3 4 5 6 7 8 9 |
]$ cd ~/chef-repo ]$ knife client list ERROR: SSL Validation failure connecting to host: sbhyun - SSL_connect returned=1 errno=0 state=SSLv3 read server certificate B: certificate verify failed ERROR: Could not establish a secure connection to the server. Use `knife ssl check` to troubleshoot your SSL configuration. If your Chef Server uses a self-signed certificate, you can use `knife ssl fetch` to make knife trust the server's certificates. Original Exception: OpenSSL::SSL::SSLError: SSL_connect returned=1 errno=0 state=SSLv3 read server certificate B: certificate verify failed |
위 에러 메시지는 chef 서버의 SSL 인증서가 없어서 나는 오류다. 오류가 나왔지만 위 메시지만으로 chef 서버와 통신은 성공했다는 것을 알 수 있다. 이제부터는 knife 명령어로 chef 서버와 명령어를 주고받을 수 있다. SSL 인증서가 없다고 하니 chef 서버로부터 받아오자
|
1 2 3 4 5 6 7 8 |
]$ knife ssl fetch WARNING: Certificates from sbhyun will be fetched and placed in your trusted_cert directory (/home/sbhyun/chef-repo/.chef/trusted_certs). Knife has no means to verify these are the correct certificates. You should verify the authenticity of these certificates after downloading. Adding certificate for chefserver in /home/sbhyun/chef-repo/.chef/trusted_certs/chefserver.crt |
다시 다음과 같이 나오면 정상적으로 작동하는 것이다.
|
1 2 |
]$ knife client list systemv-validator |
이번 시간에는 Chef 서버를 설치해보도록 한다. 설치에 앞서 Chef 서버를 설치할 서버들에 대한 정보는 다음과 같다.
여기서 중요한 것은 배포판이다. 최근들어 많은 배포판들이 init 에서 systemd 로 바꾸는 추세다. 우분투(Ubuntu)에 경우 systemd 를 도입할 생각이 없다라고 했었지만 14.10 에서 이를 뒤집어 systemd 를 도입했다. init 과 systemd 는 서버 프로그램 시작과 종료하는 방법만 다른게 아니기 때문에 이를 구분하는 것은 매우 중요하다. 여기서 설치할 14.04 는 현재 init 을 따른다.
다운로드는 chef 홈페이지에서 무료로 다운로드 할 수 있다. 그런데, 약간 실망스러운게 다운로드를 하기 위해서는 여기저기 단계를 거쳐야 한다는 것이다. 무료로 다운로드 되는 링크가 바로 나오지 않고 hosted, primium 과 같은 상품을 먼저 전시하고 링크를 찾아 클릭해야만 무료 다운로드 링크가 나오는 구조다.
우선 서버를 설치해야 하기 때문에 Chef Server 를 다운로드 받는다. Chef Server 는 레드햇 배포판 계열과 우분투 계열은 패키지를 제공한다. 단, 제공되는 배포판 버전은 제한적일 수 있다. 우리는 우분투 14.04 배포판에서 설치할 것이고 지금 현재 Chef 홈페이지에서는 다행이도 이 배포판 버전에 패키지를 제공한다.
설치는 여러가지 방법이 있는데 여기서는 dpkg 명령어를 이용해 패키지를 설치한다. 이렇게하면 Standard 형식으로 설치가 된다.
|
1 2 3 4 5 6 |
dpkg -i chef-server-core_12.1.0-1_amd64.deb Selecting previously unselected package chef-server-core. (데이터베이스 읽는중 ...현재 55970개의 파일과 디렉터리가 설치되어 있습니다.) Preparing to unpack chef-server-core_12.1.0-1_amd64.deb ... Unpacking chef-server-core (12.1.0-1) ... chef-server-core (12.1.0-1) 설정하는 중입니다 ... |
설치는 간단하다. 하지만 여기서 끝나는 것이 아니라 이제 시작이다.
Setting
설치가 끝나다면 이제 chef 가 동작하기 위해서 설정을 해준다. chef 서버의 설정은 ‘chef-server-ctl 명령어를 이용해 거의 모든것을 할 수가 있다. Standard 형식의 설치이기 때문에 다음과 같이 해준다.
chef 서버는 다양한 서비스들이 필요하다. 이러한 것을 일일이 다하기보다는 chef 자체의 기능인 자동화 기능을 이용할 수 있는데 그것은 다음과 같다.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 |
chef-server-ctl reconfigure .... .... Recipe: private-chef::partybus * execute[set initial migration level] action run - execute cd /opt/opscode/embedded/service/partybus && ./bin/partybus init * ruby_block[migration-level file sanity check] action run (skipped due to not_if) Recipe: private-chef::opscode-chef-mover * execute[restart_opscode-chef-mover_log_service] action run - execute /opt/opscode/embedded/bin/sv restart /opt/opscode/sv/opscode-chef-mover/log Recipe: private-chef::redis_lb * execute[restart_redis_lb_log_service] action run - execute /opt/opscode/embedded/bin/sv restart /opt/opscode/sv/redis_lb/log Recipe: <Dynamically Defined Resource> * service[nginx] action restart - restart service service[nginx] Recipe: private-chef::nginx * execute[restart_nginx_log_service] action run - execute /opt/opscode/embedded/bin/sv restart /opt/opscode/sv/nginx/log |
과정을 유심히 보면 nginx 웹서버도 설치된것을 알 수 있다.
여기서 잠깐 chef-server-ctl 는 그야말로 chef server 를 컨트롤하기위한 명령어이기 때문에 서버의 상태뿐만 아니라 각종 서비스들에 대한 설정을 변경할 수 있다. 여기서 간단히 알아보도록 하자.
|
1 2 3 4 5 6 7 8 9 10 11 12 |
chef-server-ctl status run: bookshelf: (pid 4220) 443s; run: log: (pid 4265) 442s run: nginx: (pid 4435) 436s; run: log: (pid 4466) 436s run: oc_bifrost: (pid 3982) 451s; run: log: (pid 4021) 450s run: oc_id: (pid 4028) 449s; run: log: (pid 4034) 449s run: opscode-erchef: (pid 4343) 440s; run: log: (pid 4327) 441s run: opscode-expander: (pid 4126) 445s; run: log: (pid 4204) 444s run: opscode-expander-reindexer: (pid 4171) 444s; run: log: (pid 4211) 443s run: opscode-solr4: (pid 4073) 447s; run: log: (pid 4107) 446s run: postgresql: (pid 3963) 451s; run: log: (pid 3969) 451s run: rabbitmq: (pid 1507) 586s; run: log: (pid 3932) 456s run: redis_lb: (pid 3891) 463s; run: log: (pid 4428) 437s |
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
root@chefserver:~# chef-server-ctl stop nginx ok: down: nginx: 0s, normally up root@chefserver:~# chef-server-ctl status run: bookshelf: (pid 4220) 513s; run: log: (pid 4265) 512s down: nginx: 7s, normally up; run: log: (pid 4466) 506s run: oc_bifrost: (pid 3982) 521s; run: log: (pid 4021) 520s run: oc_id: (pid 4028) 519s; run: log: (pid 4034) 519s run: opscode-erchef: (pid 4343) 510s; run: log: (pid 4327) 511s run: opscode-expander: (pid 4126) 515s; run: log: (pid 4204) 514s run: opscode-expander-reindexer: (pid 4171) 514s; run: log: (pid 4211) 513s run: opscode-solr4: (pid 4073) 517s; run: log: (pid 4107) 516s run: postgresql: (pid 3963) 521s; run: log: (pid 3969) 521s run: rabbitmq: (pid 1507) 656s; run: log: (pid 3932) 526s run: redis_lb: (pid 3891) 533s; run: log: (pid 4428) 507s |
nginx 서비스를 내린 예지다. 서비스를 올릴려면 start 옵션을 주면 된다.
서비스 로그들도 다음과 같이 한번에 볼 수 있다.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 |
root@chefserver:~# chef-server-ctl tail nginx ==> /var/log/opscode/nginx/internal-chef.access.log <== ==> /var/log/opscode/nginx/internal-chef.error.log <== ==> /var/log/opscode/nginx/internal-authz.error.log <== ==> /var/log/opscode/nginx/internal-authz.access.log <== ==> /var/log/opscode/nginx/rewrite-port-80.log <== ==> /var/log/opscode/nginx/current <== ==> /var/log/opscode/nginx/error.log <== ==> /var/log/opscode/nginx/access.log <== root@chefserver:~# chef-server-ctl tail rabbitmq 2015-06-21_08:11:05.27723 2015-06-21_08:11:05.27741 RabbitMQ 3.3.4. Copyright (C) 2007-2014 GoPivotal, Inc. 2015-06-21_08:11:05.27741 ## ## Licensed under the MPL. See http://www.rabbitmq.com/ 2015-06-21_08:11:05.27741 ## ## 2015-06-21_08:11:05.27742 ########## Logs: /var/opt/opscode/rabbitmq/log/rabbit@localhost.log 2015-06-21_08:11:05.27742 ###### ## /var/opt/opscode/rabbitmq/log/rabbit@localhost-sasl.log 2015-06-21_08:11:05.27742 ########## 2015-06-21_08:11:05.27743 Starting broker... completed with 0 plugins. |
chef 이기 때문에 관련 서비스들 관리도 chef 로 한다.
|
1 |
root@chefserver:~# chef-server-ctl show-config |
각 서비스들에 설정상태를 보여준다.
간단하게 chef-server-ctl 에 대해서 알아봤다.
여기까지만 해도 사실 chef server 설치는 끝난다. 하지만 chef server 를 운영하기 위한 계정을 만들어야 할 필요가 있다. chef-server 를 매니징할 수 있는 서버는 chef workstation 이라는 점이다. chef client 에 chef server 를 매니징 할 수는 없다. chef 로 무엇을 하기위한 관련된 모든 것은 chef workstation 에서 이루어진다고 보면 맞다. 따라서 chef server 에 접근할 수 있는 것도 오직 chef workstation 으로 한정된다.
이를 위해 다음과 같은 추가 작업이 필요하다.
|
1 2 |
# chef-server-ctl user-create user_name first_name last_name email password --filename FILE_NAME chef-server-ctl user-create sbhyun sb hyun excellion203@yahoo.com 123456 --filename sbhyun.pem |
|
1 2 |
#chef-server-ctl org-create short_name full_organization_name --association_user user_name --filename FILE_NAME chef-server-ctl org-create systemv systemv.pe.kr --association_user sbhyun --filename systemv.pem |
위에 sbhyun.pem 와 systemv.pem 은 chef server 에 연결위한 자격증명서다. chef workstation 은 chef server 와 연결해 작업을 수행하는데, 이때 chef server 가 과연 올바른 chef workstation 연결인지를 판별하기 위해서 필요한 것이 바로 이 자격증명 파일이다. 따라서 이 자격증명 파일은 chef workstation 에 복사해주어야 한다.
따라서 이 자격증명 파일은 꼭 잘 간수해야 한다.
다음시간에는 chef workstation 설치에 대해서 알아보자.
서버환경이 분산화되면서 수많은 서버들을 관리해야 문제가 생긴다. 대략 1,000대 서버에 Apache 웹서버 설정을 변경하고 그것을 적용하라고 한다면 단시간내에 어떻게 할 것인가와 같은 문제들이다.
프로그램을 개발하고 그것을 서버에서 돌리기위해서는 기본적인 인프라 관리가 필수인데 최근에 글로벌 서비스가 많아지면서 분산된 대랭의 서버들을 어떻게 다룰것인가 하는 문제대한 해답으로 Chef, Puppet 과 같은 인프라스트럭쳐 자동화 프로그램들이 등장했다.
이 문서는 Chef 에 대한 기초적인 내용을 다룬다. 범위는 다음과 같다.
Chef 는 서버나 애플리케이션을 쉽게 배포하기 위한 시스템이나 클라우드 인프라 자동화 프레임워크이다. 여기서 중요한 것이 프레임워크(Framework) 라는 사실이다.
시스템이나 애플리케이션을 배포한다는 개념을 단순하게만 봤을때 그냥 관련 파일들을 배포하면 된다. 하지만 대량의 시스템은 다양한 변수들이 존재하고 이러한 변수들을 모두 수용하고 조작하기 위해서는 프로그래밍만한 방법도 없다.
Chef 는 Ruby 로 작성되었다. 따라서 Chef 를 확장하거나 커스터마이징을 하고 싶다면 Ruby 를 잘 알아야 한다. 특히나 특정 조건에 한해 특정 시스템이나 애플리케이션에만 적용되도록 무언가를 만들고 싶을때 Ruby 프로그래밍 지식은 많은 도움이 된다.
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 를 이용해 위와같은 작업을 할 경우에는, 첫째로 시스템을 등록하고(이걸 Node라 부른다) 두번째로 레시피를 작성한다. 셋째로 그 레시피를 쿡북에 반영시키고 넷째로 Node 에 명령어를 보내면 Node 는 쿡북을 다운받아 그것을 실행 시켜준다.
그래서 Chef 서버가 모두 구성되고 나서부터 대부분의 작업은 Workstation 에서 다 이루어진다고 보면 된다.
물론 인프라 관리 자동화 프로그램으로 Chef 만 있는 것이 아니다. Puppet 도 나름 꽤 유명하다. 하지만 내가 보기에 Chef 만큼이나 쉽고 간단한 것은 없는 것 같다. 용어들도 마치 시스템 관리를 요리에 빗대어 놓은것도 재미와함께 이해력을 높여준다. 실제로 Workstation 에서 뭔가를 할때에 쓰이는 도구가 나이프(knife)다. 요리를 할때 칼질은 기본이지!!
Chef 에 대해서 간단히 알아봤다. Chef 구성도를 보면 참 많은 것들이 눈에 들어오는데, 지금은 몰라도 된다. 왜냐하면 나도 모르니까. 차차 알아가면 될 문제이니 너무 서둘을 필요는 없을듯 싶다.
다음 시간에는 Chef Server 설치에 대해서 알아보자.
제가 운영하는 시스템에는 snmpd 가 기본으로 서비스되고 있습니다. 각종 시스템의 상태를 파악하기 위해서 snmpd 를 활용하는 거지요. 그런데, 얼마전에 이 snmpd 때문에 아주 큰 문제가 된 일이 있었습니다.
이 문서는 그것이 무엇이며 왜 발생했고 어떻게 처리하는지에 대한 문서 입니다.
snmpd 는 국제표준으로 IT기기에 각종 상태들을 네트워크를 통해서 제공할 수 있도록 설게된 SNMP를 제공하는 데몬이다. 수 많은 서버에 기본으로 탑재되어 있어 별다른 노력없이 사용이 가능하다.
리눅스 플랫폼에서 snmpd 를 사용하는데 있어 현재 인자값 사용에 문제가 있다. 인자값의 잘못된 사용으로 인해서 리눅스 전체 시스템에 미치는 영향은 치명적이다 못해 시스템을 재부팅한다하더라도 콘솔접속이 되지 않는한 문제를 해결될 수 없다.
대부분의 리눅스는 많은 배포판을 이룬다. 내가 테스트한 배포판은 Ubuntu 12.0.4 LTS 와 CentOS 6, 7 이다. 여기서는 Ubuntu 배포판을 기반으로 내용을 전개할 것이다. snmpd 의 문제만 체크하면 되는 것이기에 기타 하드웨어 스펙과 배포판에 설치된 각종 라이브러리등은 중요하지 않아 기술하지 않는다.
이제 문제에 접근해보자. Ubuntu 에서 snmpd 를 설치하면 다음과 같은 파일이 설치된다.
| 파일 | 내용 |
|---|---|
| /etc/default/snmpd | snmpd 의 init 파일에서 사용되는 snmpd 데몬 실행 옵션 |
| /etc/init.d/snmpd | snmpd 데몬 init 스크립트 |
주목해야할 파일은 ‘/etc/default/snmpd’ 파일이며 이 파일에서 주목해야할 내용은 다음과 같다.
|
1 |
SNMPDOPTS='-Lsd -Lf /dev/null -u snmp -g snmp -I -smux -p /var/run/snmpd.pid' |
snmpd 데몬의 기본 운영을 바꾸기 위해서는 ‘/etc/default/snmpd’ 파일에서 위 내용을 편집하면 된다.
그럼, 거두절미하고 문제를 재현해보자. 미리 경고하지만 이는 반드시 콘솔접속이 되는 테스트 서버에서 해야한다. 오직 리모트로만 접속할 수 있는 서버이고 이 문제를 재현했다면 영원히 그 서버에 접속할 방법은 없다.
옵션을 다음과 같이 바꾼다.
|
1 2 |
- SNMPDOPTS='-Lsd -Lf /dev/null -u snmp -g snmp -I -smux -p /var/run/snmpd.pid' + SNMPDOPTS='-Lsd /dev/null -u snmp -g snmp -I -smux -p /var/run/snmpd.pid' |
자세히 보지 않으면 뭐가 바뀌었는지 알수 없게 된다. ‘-Lf’ 를 빠졌다. 이렇게 바꾸고 snmpd 를 재시작하면 문제가 재현된다.
|
1 2 |
service snmpd restart * Restarting network management services: |
snmpd 를 재시작한 터미널에서는 별다른 증상을 알 수가 없다. 이제 다른 터미널을 열고 snmpd 를 재시작한 서버에 접속해보자. 아마 다음과 같이 나올 것이다.
|
1 2 |
]$ ssh root@192.168.96.17 ssh_exchange_identification: read: Connection reset by peer |
root 계정이던 일반 계정이든 아무 상관이 없다. 바로 이게 문제다. 아무것도 접속할 수 없다.
콘솔에서 접속해도 다음과 같은 증상이 나온다.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 |
ubuntu login: root password: -bash: /dev/null: No such device or address <-- 이게 무수히 나오고 -bash: /dev/null: No such device or address -bash: /dev/null: No such device or address -bash: /dev/null: No such device or address -bash: /dev/null: No such device or address root@ubuntu:~# cd / [탭을 누르면] -bash: /dev/null: No such device or address bash: _upvars: `-a2': invalid number specifier -bash: /dev/null: No such device or address -bash: /dev/null: No such device or address -bash: /dev/null: No such device or address -bash: /dev/null: No such device or address |
원인은 ‘/etc/default/snmpd’ 에서 정의한 snmpd 의 시작 옵션에 있다. snmpd 는 다음과 같이 커맨드라인에서 시작할 수 있다.
|
1 |
snmpd [OPTIONS] [LISTENING ADDRESSES] |
문제는 snmpd 에서 옵션은 반드시 ‘-L’, ‘-a’ 등과 같이 – 로 시작한다. 이것이 없이 그냥 값을 주게되면 그것은 바로 [LISTENING ADDRESSES] 가 된다. 여기서 중요한 것이 [LISTENING ADDRESSES]는 어떤값들이 올수 있느냐인데 이는 snmpd 맨페이지(man)를 통해서 확인할 수 있다.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 |
[<transport-specifier>:]<transport-address> At its simplest, a listening address may consist only of a port number, in which case snmpd listens on that UDP port on all IPv4 interfaces. Oth- erwise, the <transport-address> part of the specification is parsed according to the following table: <transport-specifier> <transport-address> format udp (default) hostname[:port] or IPv4-address[:port] tcp hostname[:port] or IPv4-address[:port] unix pathname ipx [network]:node[/port] aal5pvc or pvc [interface.][VPI.]VCI udp6 or udpv6 or udpipv6 hostname[:port] or IPv6-address[:port] tcp6 or tcpv6 or tcpipv6 hostname[:port] or IPv6-address[:port] Note that <transport-specifier> strings are case-insensitive so that, for example, "tcp" and "TCP" are equivalent. Here are some examples, along with their interpretation: 127.0.0.1:161 listen on UDP port 161, but only on the loopback interface. This prevents snmpd being queried remotely. The port speci- fication ":161" is not strictly necessary since that is the default SNMP port. TCP:1161 listen on TCP port 1161 on all IPv4 interfaces. ipx:/40000 listen on IPX port 40000 on all IPX interfaces. unix:/tmp/local-agent listen on the Unix domain socket /tmp/local-agent. /tmp/local-agent is identical to the previous specification, since the Unix domain is assumed if the first character of the <transport-address> is '/'. |
결론만 말하면 <transport-address> 없이 그냥 문자열을 주게되면 snmpd 는 그것을 Unix Domain Socket 으로 인식하게 된다. 위 맨페이지에서 마지막에 나온 설명이 이것을 말해준다.
문제가 된 옵션을 다시보면
|
1 |
SNMPDOPTS='-Lsd /dev/null -u snmp -g snmp -I -smux -p /var/run/snmpd.pid' |
‘/dev/null’ 은 snmpd 에서 Unix Domain Socket 으로 인식하게 된다.
/dev/null 은 major 1, Minor 3 값을 가지는 Char device 파일이다. 이 파일은 특수한 장치 파일인데, 실제로는 없는 존재하지 않는 커널에서 제공하는 장치파일로서 Input/Output 을 empty 화시켜준다.
|
1 2 |
ls -lh /dev/null crw-rw-rw- 1 root root 1, 3 Apr 27 22:43 /dev/null |
이 파일들은 아주 많은 프로그램에서 사용되지는데 대표적인 것으로 sshd 가 있다.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 |
root@ubuntu:~# lsof -p 1014 COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME sshd 1014 root cwd DIR 8,1 4096 2 / sshd 1014 root rtd DIR 8,1 4096 2 / sshd 1014 root txt REG 8,1 517112 2103671 /usr/sbin/sshd sshd 1014 root mem REG 8,1 52120 1835042 /lib/x86_64-linux-gnu/libnss_files-2.15.so sshd 1014 root mem REG 8,1 47680 1835036 /lib/x86_64-linux-gnu/libnss_nis-2.15.so sshd 1014 root mem REG 8,1 35680 1835044 /lib/x86_64-linux-gnu/libnss_compat-2.15.so sshd 1014 root mem REG 8,1 105288 1835043 /lib/x86_64-linux-gnu/libresolv-2.15.so sshd 1014 root mem REG 8,1 14360 1835328 /lib/x86_64-linux-gnu/libkeyutils.so.1.4 sshd 1014 root mem REG 8,1 31200 2098198 /usr/lib/x86_64-linux-gnu/libkrb5support.so.0.1 sshd 1014 root mem REG 8,1 158168 2098187 /usr/lib/x86_64-linux-gnu/libk5crypto.so.3.1 sshd 1014 root mem REG 8,1 14768 1835050 /lib/x86_64-linux-gnu/libdl-2.15.so sshd 1014 root mem REG 8,1 97248 1835041 /lib/x86_64-linux-gnu/libnsl-2.15.so sshd 1014 root mem REG 8,1 1811128 1835037 /lib/x86_64-linux-gnu/libc-2.15.so sshd 1014 root mem REG 8,1 14696 1835113 /lib/x86_64-linux-gnu/libcom_err.so.2.1 sshd 1014 root mem REG 8,1 844648 2098194 /usr/lib/x86_64-linux-gnu/libkrb5.so.3.3 sshd 1014 root mem REG 8,1 252720 2098190 /usr/lib/x86_64-linux-gnu/libgssapi_krb5.so.2.2 sshd 1014 root mem REG 8,1 43288 1835047 /lib/x86_64-linux-gnu/libcrypt-2.15.so sshd 1014 root mem REG 8,1 92720 1835237 /lib/x86_64-linux-gnu/libz.so.1.2.3.4 sshd 1014 root mem REG 8,1 10632 1835035 /lib/x86_64-linux-gnu/libutil-2.15.so sshd 1014 root mem REG 8,1 1930648 1835040 /lib/x86_64-linux-gnu/libcrypto.so.1.0.0 sshd 1014 root mem REG 8,1 135366 1835038 /lib/x86_64-linux-gnu/libpthread-2.15.so sshd 1014 root mem REG 8,1 121936 1835071 /lib/x86_64-linux-gnu/libselinux.so.1 sshd 1014 root mem REG 8,1 55744 1835091 /lib/x86_64-linux-gnu/libpam.so.0.83.0 sshd 1014 root mem REG 8,1 36432 1839207 /lib/x86_64-linux-gnu/libwrap.so.0.7.6 sshd 1014 root mem REG 8,1 149280 1835048 /lib/x86_64-linux-gnu/ld-2.15.so sshd 1014 root 0u CHR 1,3 0t0 5862 /dev/null sshd 1014 root 1u CHR 1,3 0t0 5862 /dev/null sshd 1014 root 2u CHR 1,3 0t0 5862 /dev/null sshd 1014 root 3u IPv6 9762 0t0 TCP *:ssh (LISTEN) sshd 1014 root 4u IPv4 9766 0t0 TCP *:ssh (LISTEN) root@ubuntu:~# |
위에서 아래쪽을 보면 TYPE 이 CHR 이며 DVICE 1,3 나오는 ‘/dev/null’ 이 보인다.
그런데, 이것을 위에 문제처럼 snmpd 의 Unix Domain Socket 으로 하게되면 /dev/null 는 더 이상 장치파일이 아닌 소켓 파일로 변경되어 이 장치를 사용하는 모든 프로그램에 문제가 발생하게 된다. 다음과 같이 이전에 장치파일이 아닌 그냥 일반파일로 변경된것을 알 수 있다.
|
1 2 |
]# ls -lh /dev/null srwxr-xr-x 1 root root 0 Apr 27 22:57 /dev/null |
그리고 netstat 로 보면 snmpd 가 /dev/null 을 Unix Domain Socket 으로 사용하고 있다는 것이 보인다.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 |
root@ubuntu:~# netstat -lpn Active Internet connections (only servers) Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name tcp 0 0 0.0.0.0:6379 0.0.0.0:* LISTEN 1259/redis-server * tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 1127/sshd tcp6 0 0 :::6379 :::* LISTEN 1259/redis-server * tcp6 0 0 :::22 :::* LISTEN 1127/sshd udp 0 0 0.0.0.0:44581 0.0.0.0:* 1886/snmpd udp 0 0 0.0.0.0:68 0.0.0.0:* 1091/dhclient3 udp 0 0 127.0.0.1:161 0.0.0.0:* 1886/snmpd Active UNIX domain sockets (only servers) Proto RefCnt Flags Type State I-Node PID/Program name Path unix 2 [ ACC ] STREAM LISTENING 7856 1/init @/com/ubuntu/upstart unix 2 [ ACC ] STREAM LISTENING 10843 1270/acpid /var/run/acpid.socket unix 2 [ ACC ] STREAM LISTENING 13934 1886/snmpd /var/agentx/master unix 2 [ ACC ] STREAM LISTENING 13931 1886/snmpd /dev/null unix 2 [ ACC ] SEQPACKET LISTENING 8070 671/udevd /run/udev/control unix 2 [ ACC ] STREAM LISTENING 8189 797/dbus-daemon /var/run/dbus/system_bus_socket |
가장 좋은 방법은 아직 연결이 유지되고 있는 터미널에서 ‘/etc/default/snmpd’ 의 옵션을 고쳐주는 것이다. 그리고 반드시 재부팅을 해줘야 한다.
그런데, 재부팅을 해서는 안되는 서버라면 어떻게 해야 할까?
첫째, ‘/etc/default/snmpd’ 에서 옵션을 변경하고 snmpd 를 정지시킨다. 재시작해줘도 /dev/null 파일이 장치로 복구가 안된다.
둘째, /dev/null Unix Domain Socket 파일을 삭제한다. 더이상 장치 파일이 아니기 때문에 과감히 삭제한다.
|
1 |
sudo rm -f /dev/null |
셋째, /dev/null 파일을 다시 만들어 준다.
|
1 |
sudo mknod -m 666 /dev/null c 1 3 |
위와같이 장치파일을 생성해주자 마자 바로 sshd 가 복구된다.
문제는 /dev/null 를 Domain Unix Socket 이던 무엇이던간에 프로그램에서 파일이 속성을 변경되도록 했다는데 있다. 애초에 snmpd 인자로 /dev/null 을 주었던게 문제였고 그 이전에 오타발생이 문제였다.
비단 snmpd 만 인자값으로 Unix Domain Socket 을 사용한다고 생각하지 않는다. 리눅스에는 수많은 프로그램들이 존재하고 snmpd 와 같이 옵션으로 Unix Domain Socket 을 받는 경우도 분명 존재한다. 그것도 하필이면 /dev/null 를 준다면 똑같은 문제가 발생할 수 있다.
위 문제(snmpd 로 발생되는 문제) 로 영향받는 프로그램들은 /dev/null 장치를 사용하는 프로그램이라면 다 영향을 받는다.
|
1 2 3 4 5 6 |
root@ubuntu:~# service nginx restart Restarting nginx: /etc/init.d/nginx: 30: /etc/init.d/nginx: cannot create /dev/null: No such device or address nginx: the configuration file /etc/nginx/nginx.conf syntax is ok nginx: configuration file /etc/nginx/nginx.conf test is successful nginx. root@ubuntu:~# nginx: [emerg] open("/dev/null") failed (6: No such device or address) |
|
1 2 3 4 5 6 7 8 9 10 |
root@ubuntu:~# service proftpd restart /etc/init.d/proftpd: 198: /etc/init.d/proftpd: cannot create /dev/null: No such device or address * Stopping ftp server proftpd ...done. /etc/init.d/proftpd: 198: /etc/init.d/proftpd: cannot create /dev/null: No such device or address * Starting ftp server proftpd ubuntu proftpd[5135]: mod_tls/2.4.3: compiled using OpenSSL version 'OpenSSL 1.0.0e 6 Sep 2011' headers, but linked to OpenSSL version 'OpenSSL 1.0.1 14 Mar 2012' library ubuntu proftpd[5135]: mod_sftp/0.9.8: compiled using OpenSSL version 'OpenSSL 1.0.0e 6 Sep 2011' headers, but linked to OpenSSL version 'OpenSSL 1.0.1 14 Mar 2012' library ubuntu proftpd[5135]: mod_tls_memcache/0.1: notice: unable to register 'memcache' SSL session cache: Memcache support not enabled ...done. |
|
1 2 3 4 5 6 7 8 |
[root@localhost instance1]# ./start.sh /opt/tomcat-7/bin/setclasspath.sh: line 35: /dev/null: 허가 거부 Using CATALINA_BASE: /home/instance1 Using CATALINA_HOME: /opt/tomcat-7 Using CATALINA_TMPDIR: /home/instance1/temp Using JRE_HOME: /usr Using CLASSPATH: /opt/tomcat-7/bin/bootstrap.jar:/opt/tomcat-7/bin/tomcat-juli.jar Tomcat started. |
/dev/null 이 없어짐으로 인해서 bash 가 제대로 동작하지 않아 쉘스크립트로 작성된 대부분의 init 스크립트가 제대로 동작하지 못해 대부분의 프로그램들에 문제가 발생한다.
운이 좋게도 CentOS 7 은 배포판 패키징으로 옵션 설정이 없다.
|
1 2 |
[root@localhost ~]# ps aux | grep snmpd root 1063 0.3 0.1 222992 10660 ? Ss 23:40 0:00 /usr/sbin/snmpd -LS0-6d -f |
CentOS 에서는 ‘/etc/sysconfig/snmpd’ 에 옵션 설정을 할 수 있다.
|
1 2 3 |
]# vim /etc/sysconfig/snmpd OPTIONS="-Lsd /dev/null" ]# systemctl snmpd restart |
여기서 CentOS 7 에서 상태가 심각했다. CentOS 7 에서는 Init System 이 systemd 로 변경되었다. 사실 systemd 는 Init System 프로그램을 넘어서 CentOS 7 배포판의 중추신경계역활을 하게됨에 따라 지대한 영향을 미친다.
이에 따라서 systemd를 제어하는 systemctl 명령어로 그 어떤 것도 실행되지 않았다. 거기다 /dev/null 를 새로 생성하더라도 systemd 가 복구되지 않았다. 무조건 재부팅이 요구된다.
CentOS 6 에서는 ubuntu 처럼 다음과 같이 옵션이 나온다.
|
1 2 3 |
[root@localhost ~]# ps aux | grep snmp root 2296 0.0 0.0 199560 4188 ? S 00:31 0:00 /usr/sbin/snmpd -LS0-6d -Lf /dev/null -p /var/run/snmpd.pid root 2299 0.0 0.0 107408 892 pts/0 S+ 00:31 0:00 grep snmp |
역시 옵션은 ‘/etc/sysconfig/snmpd’ 에서 설정할 수 있으며 주석으로 다음과 같이 되어 있다.
|
1 |
# OPTIONS="-LS0-6d -Lf /dev/null -p /var/run/snmpd.pid" |
아마도 개인적인 추측인데, CentOS 7 로 넘어오면서 기본 옵션이 변경된데에는 systemd 의 도입때문으로 보인다. systemd 의 도입으로 각 데몬 프로그램들은 systemd 가 상태, 로깅들을 담당하게 되어 이전 CentOS 6 과는 다르게 각 데몬 프로그램들 각자가 로깅을 할 필요가 없게 되었다.
어찌되었든 /dev/null 파일을 삭제하거나 일반파일로 바꾸거나 해서는 안된다. 그렇게되면 sshd 는 접속을 거부할 것이다. 혹시나 다른 방법으로 슈퍼유저인 root 로 커맨드를 날릴 수 있다면 당황하지 말고 다음과 같이하면 적어도 sshd 는 돌아온다.
|
1 2 |
]$ sudo rm -f /dev/null ]$ sudo mknod -m 666 /dev/null c 1 3 |
그리고 ubuntu 에서 ‘/etc/default/snmpd’ 를 수정할때는 오타 를 항상 조심해야 한다.
많은 IT 종사자들은 회사 보안 때문에 특정 서버에 포트를 오직 SSH 와 서비스를 위한 포트만을 열어둔 경우가 많다. 그런데 서버를 관리하다보면 특정 서비스 체크를 위한 매니징 서비스에 접속을 해야하는 경우가 발생한다. 이럴 경우 사내 보안팀에 매니징 서비스 접속을 위해서 포트를 개방해 줄것을 요구할 수 있지만 이럴때에 SSH 의 포트 포워딩(Port Forwarding)을 이용하면 쉽게 해결 할 수 있다.
SSH 포트 포워딩에도 다음과 같이 세가지 종류가 있다.
SSH 포트 포워딩은 SSH 서버를 Gateway 나 Proxy 서버처럼 활용해 외부 접속을 하는 것이여서 터널링(Tunneling)이라고 부르기도 한다. 각 포트 포워딩 설명을 예제상황을 가정해 설명하도록 하겠다.
192.168.96.6 서버에는 Tomcat 서버가 가동중이고 Web 접속 포트는 8180 이며 서버 상태를 체크하기 위한 JMX 가 활성화 되어 있고 이 포트는 8190 이다.
현재 이 서버는 테스트 서버여서 자체 방화벽으로 22번 포트만 개방되어 있고 Web 접속 포트와 JMX 포트가 개방되어 있지 않다.
접속하고자 하는 사용자의 PC는 리눅스를 사용한다.
위 말을 도식화 하면 다음과 같다.
접속은 SSH 포트인 22번만 열려있고 Tomcat 관련 포트는 리눅스 서버의 로컬 방화벽으로 막혀 있는 상황이라고 가정하자.
이제 Tomcat 서비스에 접속을 하고 싶다면 어떻게 해야하는 걸까? 이럴때 사용하는 것이 바로 Local Port Forwarding 이다. 형식은 다음과 같다.
|
1 |
ssh -L <local port>:<Remote Server>:<Remote Port> [SSH 서버] |
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 은 다음과 같다.
|
1 |
ssh -L 10030:yahoo.com:80 root@192.168.96.6 |
위와같이 한후에 클라이언트 PC(여기서는 왼쪽에 있는 컴퓨터)에서 웹 브라우져를 켜고 주소창에 ‘http://localhost:10030’ 이라고 하면 yahoo.com 이 열리게 된다.
다시 가정한 상황으로 돌아오면 Gateway 서버(여기서는 192.168.96.6서버) 외부가 아닌 그 자체의 서비스들을 포워딩할 것이기에 다음과 같이 하면 된다.
|
1 |
ssh -L 10030:localhost:8180 root@192.168.96.6 |
이렇게 한 후에 웹 브라우져를 실행하고 주소창에 ‘http://localhost:10030’ 이라고 입력하면 192.168.96.6 서버의 Tomcat 서버 포트인 8180 에 연결되고 톰캣 페이지가 보이게 된다.
Local Port Forwarding 이기 때문에 웹 브라우져에서의 접속 서버명은 항상 localhost 가 된다.
이것은 필자가 아직 다루어보지 못했기에 설명을 생략한다.
이 포워딩은 접속하는 서버를 SOCKS Proxy 서버로 동작하도록 한다. Local Port Forwarding 에서 접속하는 서버는 Gateway 서버로 동작을 했지만 이 포워딩은 접속하는 서버를 Proxy 서버로 그것도 SOCKS 동작하게 한다.
Proxy 서버이기 때문에 클라이언트에서 접속할때에는 항상 실제 접속을 하는 서버와 포트를 사용하면 된다.
JDK 1.7 이상부터는 JMC(Java Mission Control) 이 함께 설치된다. 이걸 이용하면 Java 애플리케이션의 각종 정보를 볼 수 있는데, 물론 JMX 에 접속도 가능하다. 위 예제 상황에서 Dynamic Port Forwarding 을 이용해 접속해보자.
사용방법은 간단하다.
|
1 |
ssh -D 10030 root@192.168.96.6 |
위와같이 하게되면 192.168.96.6 서버가 포트 10030 으로 Proxy 서버로 역활을 하게된다. 이제 클라이언트에서 JMC 를 구동하고 다음과 같이 Network 설정을 해준다.
그리고 나서 JMX 접속 서버와 포트는 실제 접속을 하기 위한 192.168.96.6 과 8190 으로 해주면 접속이 이루어진다.
리눅스에 접속되어 있는 상태에서 상대방에게 화면을 전송하고 싶다면 디바이스를 이용한 화면전송 을 이용하면 됩니다. 방법은 아주 간단합니다.
우선 텔넷이나 ssh로 두분이 같은 시스템에 접속 합니다.
저의 디바이스(가상 터미널)명을 찾아야 합니다.
#tty 이 명령어를 입력하시면 다음과 같은 가상터미널이 나타납니다.
|
1 2 |
]$ tty /dev/pts/1 |
그럼, 함께 접속된 상대방의 디바이스(가상터미널)명을 또 찾아야 합니다.
#w 이 명령어를 입력하시고 고객이 잡고 있는 가상터미널을 찾거나
만일 어떤 가상 터미널을 잡고 있는지 잘 모르겠으면 고객에게
tty 명령어를 입력하여 나타나게 되는 가상터미널 번호를 알아
내시면 됨니다. 예) /dev/pts/2 이 나타났다고 가정 하구요.
그럼, 제가 접속한 화면에서 아래와 같은 명령어를 입력하시면 같은 시스템
에 접속된 상대방의 화면이 저의 제어권으로 넘어 오게 됨니다.
|
1 |
#script -a | tee /dev/pts/2 |
자주 사용하지는 않아도 아주 가끔 사용하는 것이오니 참고 하시라구 장황
하게 몇자 적습니다.
그리고, 종료 하실려면 exit 입력하시면 됨니다.
포워드 프락시(Forward Proxy)는 클라이언트가 타켓서버(목표서버)의 주소를 받아서 타켓서버로 연결을 시켜준다. 클라이언트는 타켓서버의 주소를 요청하면 프락시 서버는 뒷단에 타켓서버의 주소를 가진 서버에 연결을 포워딩 한다. 프락시 서버는 타켓서버의 주소를 가지고 있지 않다.
리버스 프락시(Reverse Proxy)는 타켓서버의 주소가 아닌 프락시 서버가 타켓서버의 주소를 가지고 있고 프락시 서버가 이를 받아서 뒷단에 실제 타켓 서버로 연결을 시켜준다. 그러니까 타켓서버의 주소를 프락시서버가 가지고 있어야 하며 클라이언트는 타켓서버의 주소로 요청을 하면 프락시 서버가 응답을 하게 된다.
이글은 다음의 내용을 번역한 것입니다.
클러스터링(Clustering) 은 소프트웨어, 하드웨어, 데이터 이중화 도입이 필요한 어떤 서비스에 대해 고가용성(High Availability) 구현을 위한 가장 일반적인 기술이다. 실패한 클러스터링 소프트웨어에서는 즉각적으로 관리자 개입이 필요없이 대기(standby) 시스템에 애플리케이션이 시작된다. 소프트웨어 이중화의 타입에 따라서 고가용성이 제공되어질 클러스터들은 다음과 같은 설정들로 구성되어질 수 있다.