[win] terminal rdp session hang troubleshooting in AWS

서비스 운영 중인 장비에서, 서버 접속이 되지 않는 다는 연락을 받게 되었습니다.

어떤 부분에서 연결이 안되는지 파악해보니,  기존 vpn 연결이 끊어지고, 접속중이던 mssql 서버로 터미널 접속이 되지 않아 문의가 온 상황입니다.

 

다행이 서비스 영향성을 파악해보니 디비와의 연결이나 서비스에는 이상이 없었습니다.

(이때는 약간 안정)

 

터미널 세션이 active state로 리미트에 걸려있을 것으로 예상하고 상태를 확인하려 하니,

콘솔 접속은 불가능하고 저역시 리모트 접속은 불가능한 상황입니다. (AWS windows)

 

부랴부랴 139,445 포트를 열고, sysinternals 를 받아서 psexec 를 실행해봅니다.

PsExec.exe \\1.2.3.4 /accepteula /h /u 관리자계정 /p 암호 cmd /c “query session”

 

역시 실행결과 session이 active state로 2개 꽉차있는 상황이었고, reset session [session ID] 으로 단순하게 해결될 거라 생각했습니다만, 리셋이나 테스크 중지가 먹히지 않는 상황이었습니다.

2년만에 윈도우 서버로 접속을..(?)  하다보니, 이때부턴 긴장이 되기 시작하더군요.ㅎㅎ

 

sc stop termservice 명령을 하면 dependent 로 인해 서비스 중지가 되지 않습니다.

 

net stop termservice /yes 명령을 통해서 관련 서비스를 포함해서 중지하려하니 또 문제가 생깁니다.  stop_pending 상태로 터미널 서비스가 멈춰있네요.

 

sc queryex termservice  명령을 통해 해당 pid를 찾아서

taskkill /f /pid [termservice PID] 로 중지하고 나서 다시 재시작 한 후에야

세션이 정상적으로 성립되었습니다.

 

rdp hang 의 상세한 원인을 찾으려면 이제부터 고생 시작일 것 같네요.

 

우선은 저와 비슷한 상황을 겪으신 분들이 계시다면 해당 포스트가 도움이 되길 바라며,  포스팅 합니다.

 

오랜만이라 매우 긴장되었습니다.   😥

 

Ansible

ansible 은 python으로 개발된 오픈소스 관리도구로 ssh 를 이용해 리모트 호스트에 대한 관리가 가능합니다.

지금도 활발 하게 개발되고 있으며, 다양한 플랫폼을 지원합니다..

해당 툴을 이용해 자동화 관리 및 배포 등을 진행하는 방법에 대한 부분을 해당 카테고리에 조금씩 정리해 나갈 예정입니다.

 

설치 방법 :

https://github.com/ansible/ansible 에서 소스를 다운받아 설치 또는

http://releases.ansible.com/ansible/ansible-latest.tar.gz 를 다운받아 설치

 

기본적으로 pip 를 통해서 지원됩니다.

# pip install ansible 

 

Mac 에서는 pip를 통해서 설치해도되고,

# brew install ansible 

home-brew 로 설치해도 됩니다. (12/21 현재 2.2.0 버전)

 

Ansible Structure & playbook 관련 사항은 점차 업데이트될 예정입니다.

기본적인 설정은 YAML 방식을 이용하기 때문에 해당 부분에 대한 사전 지식을 알고 있으면 도움이 됩니다.

YAML wikipedia : https://en.wikipedia.org.wiki/YAML

[etc] Nginx Origin URI into proxy pass

톰켓 proxypass 시에 header 에 Original URI 전달하기.

헤더값에 original URI 정보 입력하는  테스트 ..


톰켓과 같은 어플리케이션 서버 앞에 일반적으로 nginx 를 이용한 리저브 프록시 형태의 서비스를 이용하는데 있어, 
다음과 같이 커스텀한 헤더나 혹은 Extend 헤더를 추가함으로 was에서 들어오는 request 에 대한 형태를 판단 할 수 있습니다.


관련해서 proxy backend   넘겨줄  X-Original-URI 말고 X-forwarded-URI 로도 넘겨주는 방법(동일?) 선택하면 될듯합니다.

nginx 설정

header  X-Original-URI

location / {
proxy_set_header X-Original-URI $request_uri;
            proxy_pass http://127.0.0.1:8080/;
        }


         location /testuri/ {
          proxy_set_header X-Original-URI $request_uri;
            proxy_pass http://127.0.0.1:8080/;
        }

테스트를 위해 nginx 의 로케이션이 상이한 두개의 경우에도 동일하게 톰켓의 루트 ( / ) 로 프록시 되도록 설정을 해두었다. 
위와 같은 경우 was 의 access 로그를 확인하게 되면 웹서버의 "/$uri" 및 "/testuri/$uri" 는 동일하게 패싱된다. 

이런 경우 실제 nginx로 포함되는 request_uri를 프록시 과정에 X-Origin-URI 헤더로 셋업하여 전달해준다. 

이후 java 설정에서 아래와 같이 헤더정보를 가져오게 되면 

request.getHeader("X-Original-URI");  

실제로 들어오는 요청에 대한 값을 판단 할 수 있게된다.


실제 패킷 분석 시 헤더 결과 

(톰켓으로 넘어가는 loopback 8080 캡쳐 : # tcpdump i lo qexX port 8080)

get http://test.hongstalk.com/ 

09:54:56.618161 00:00:00:00:00:00 (oui Ethernet) > 00:00:00:00:00:00 (oui Ethernet), IPv4, length 623: localhost.47502 > localhost.webcache: tcp 557

        0x0000:  4500 0261 210a 4000 4006 198b 7f00 0001  E..a!.@.@.......

        0x0010:  7f00 0001 b98e 1f90 7f44 b41a 86a9 4ace  .........D....J.

        0x0020:  8018 0200 0056 0000 0101 080a 4fc9 9511  .....V......O...

        0x0030:  4fc9 9511 4745 5420 2f20 4854 5450 2f31  O...GET./.HTTP/1

        0x0040:  2e30 0d0a 582d 4f72 6967 696e 616c 2d55  .0..X-Original-U

        0x0050:  5249 3a20 2f0d 0a48 6f73 743a 2031 3237  RI:./..Host:.127



get http://test.hongstalk.com/testuri

09:58:54.909510 00:00:00:00:00:00 (oui Ethernet) > 00:00:00:00:00:00 (oui Ethernet), IPv4, length 543: localhost.47504 > localhost.webcache: tcp 477

        0x0000:  4500 0211 f02b 4000 4006 4ab9 7f00 0001  E....+@.@.J.....

        0x0010:  7f00 0001 b990 1f90 59d0 c7ce 9d52 e649  ........Y....R.I

        0x0020:  8018 0200 0006 0000 0101 080a 4fcd 37e4  ............O.7.

        0x0030:  4fcd 37e4 4745 5420 2f20 4854 5450 2f31  O.7.GET./.HTTP/1

        0x0040:  2e30 0d0a 582d 4f72 6967 696e 616c 2d55  .0..X-Original-U

        0x0050:  5249 3a20 2f74 6573 7475 7269 0d0a 486f  RI:./testuri..Ho

테스트 과정에서 볼 수 있듯이, 루프백 어뎁터를 통해 실제 톰켓 으로 GET 을 통해서 / 에대한 요청이 들어오는건 두 요청이 모두 동일하지만,  X-origin-URI 헤더를 추가함으로써, 실제 웹 서버로 어떤 request 를 통해 접근하는지를 판단 할 수 있다.

[etc] 자주 사용하는 redis cli command 정리

SCAN 0 COUNT 100 MATCH *

# 100개 제한 읽어오기. Keys * 보다 효율적임..

 

DEBUG OBJECT 키

# 해당 정보의 사이즈 lru , expire 정보등을 읽어옴

 

SETEX 키 시간 키밸류

# expire time을 걸어 아이템을 set 한다.

# setex hong 60 sungho 라고 입력하면, 60초간 hong이라는 키가 저장된다.

 

 

SLOWLOG GET

# get 으로 시작하는 카운트 중 시간이 오개걸리는 값을 반환한다..

# 일반적으로 겟 명령어에서 슬로우 로그가 발생하는 경우 해당 키값의 데이터가 용량이 가장 큰 (메모리를 많이 잡아먹는) 키 값이다..

# 레디스 운영 시 OOM redis Out Of Memory 같은 경우, 해당 키 또는 리스트의 값이 너무 큰 (보통 팝 과정 없이  잘못 쌓이는 push LIST에서 발생한다. )

# GET , RESET, LEN  등을 확인 할 수 있다.

 

Lpush, Lpop, Rpush , Rpop

# push 는 데이터를 입력하며, Left, Right로 데이터를 입력한다.

# pop 은 데이터를 읽는 개념이 아닌, 가져간다는 표현으로 pop을 통해 꺼내어진 데이터는 해당 데이터테이블에서 삭제된다.

# Lrange 명령을 통해서 대상이 지정된 범위의 리스트를 읽어온다. 0 은 시작점을 의미하고, -1 은 리스트의 끝 (오른쪽 마지막) 을 의미하므로, 모든 리스트에 저장된 데이터를 확인 할 때 사용한다.

# 모든 리스트에서 데이터를 꺼내어 쓰면, 데이터가 없다는 의미의 nil 을 표시한다.

# 예시 )

Rpush hong A B C

 

LRANGE hong 0 -1

“A”

“B”

“C”

 

Rpop hong

“C”

 

Rpop hong

“B”

 

Rpop hong

“A”

 

Rpop hong

(nil)

 

 

Redis-cli -h HOSTNAME –stat

# 레디스의 key count, memory Usage, clinet, blocked, requests, connections 정보를 알려줌..

 

Redis-cli -h HOSTNAME -c ‘keys hong*” | xargs redis-cli -h HOSTNAME DEL

# hong으로 시작하는 모든 키를 검색하여, 한번에 지우는 방법..

[linux] Iptables & Filter logging

리눅스 패키지중 강력한 네트워크 패킷 필터링 도구인 iptables의 간단한 내용을 정리합니다..

제가 사용하는 개인서버에서는 아래와 같은 설정만을 이용합니다.

iptables 명령어를 이용하거나,  system-config-firewall   또는 스크립트를 생성하여 이용하기도합니다만

/etc/sysconfig/iptables 에 룰을 직접 지정하여 사용하는 것이 편할 수 도 있습니다.

 

아래 처럼 제가 사용하고 있는 샘플을 보시면, 개인 vpn 에 대해서는 모두 허용하고 그 외 모든 인터페이스에서

접근하는 패킷에 대해서는 INPUT Chain 에서 차단합니다.

 

해당 서버가 프록시, 메일, vpn, db 등으로 꾹꾹 눌러담아 사용하다보니 외부에서 의도적으로 접속하는 경우가 있는데요.

해당 부분에 대해서는 과도한 접근 시도를 확인하면, DROPLOG 라는 체인을 별도로 만들어서 해당 체인으로 점프 시킨 후 로그를 확인 하거나, 패킷을 드랍 시키는 용도로 사용하고 있습니다.

 

생성 시킨 로그는 별도 커스텀 로그로 생성하여 관리 할 수도 있는데 관련해서는 syslog 설정에 별도로 추가하여,  제가 따로 명시한 로그 프리픽스인 [Firewall] 을 필터로 /var/log/firewall.log 등으로 커스텀하게 생성할 수 있습니다.

생성 시 아래와 같은 형태로 로그를 남겨 필터링 할 수 있습니다.

아래 예시에서는 로그 프리픽스를 iptables denied 와 iptables VPN으로 생성하여 모니터링 한 예입니다.

 

방화벽 로그

[255434.143314] iptables denied: IN=eth0 OUT= MAC=06:3e:a8:fd:1b:86:06:dc:04:XX:XX:XX:XX SRC=1.2.3.4 DST=10.10.10.100 LEN=52 TOS=0x00 PREC=0x00 TTL=107 ID=19009 DF PROTO=TCP SPT=58139 DPT=25 WINDOW=8192 RES=0x00 SYN URGP=0 

 

[255982.927075] iptables VPN: IN=sunghovpn OUT= MAC= SRC=192.168.192.6 DST=10.10.10.100 LEN=64 TOS=0x00 PREC=0x00 TTL=64 ID=43356 DF PROTO=TCP SPT=51934 DPT=22 WINDOW=65535 RES=0x00 SYN URGP=0 

 

 

방화벽 설정

[root@mail ~]# cat /etc/sysconfig/iptables

# Firewall configuration written by system-config-firewall

# Manual customization of this file is not recommended.

*filter

:INPUT ACCEPT [0:0]

:FORWARD ACCEPT [0:0]

:OUTPUT ACCEPT [0:0]

-A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

-A INPUT -p icmp -j ACCEPT

-A INPUT -i lo -j ACCEPT

# LOG to VPN

# IF YOU NEED MONITORING , THIS OPTION ENABLE

#-A INPUT -m limit --limit 5/min -s 192.168.192.0/24 -j LOG --log-prefix "[Firewall] VPN: " --log-level 6

# BAN IP LIST

##############################################

# create RULE

-N DROPLOG 

# Input Drop IP rule

-A INPUT -s 185.125.6.105/32 -j DROPLOG

-A INPUT -s 50.243.196.29/32 -j DROPLOG

-A INPUT -s 120.92.233.86/32 -j DROPLOG

-A INPUT -s 197.14.14.150/32 -j DROPLOG

-A INPUT -s 203.198.207.61/32 -j DROPLOG

# Drop RULES logging and Drop

# IF YOU NEED DROP PACKET MONITORING, THIS OPTION ENABLE

#-A DROPLOG -m limit --limit 5/min -j LOG --log-prefix "[Firewall] Drop: " --log-level 6

-A DROPLOG -j DROP

##############################################

# FTP 

-A INPUT -m state --state NEW -m tcp -p tcp --dport 20 -j ACCEPT

-A INPUT -m state --state NEW -m tcp -p tcp --dport 21 -j ACCEPT

# manage console with private key

-A INPUT -m state --state NEW -m tcp -p tcp --dport 22 -j ACCEPT

# SMTP mail server 

-A INPUT -m state --state NEW -m tcp -p tcp --dport 25 -j ACCEPT

# sungho POP3 port

-A INPUT -m state --state NEW -m tcp -p tcp --dport 110 -j ACCEPT

# sungho IMAP port 

-A INPUT -m state --state NEW -m tcp -p tcp --dport 143 -j ACCEPT

# sungho IMAPS port 

-A INPUT -m state --state NEW -m tcp -p tcp --dport 993 -j ACCEPT

# VPN for sungho

-A INPUT -m state --state NEW -m tcp -p tcp --dport 1234 -j ACCEPT

# Proxy for sungho

-A INPUT -m state --state NEW -m tcp -p tcp --dport 3333 -j ACCEPT

# Database sunghoDB

-A INPUT -m state --state NEW -m tcp -p tcp --dport 3306 -s 10.10.10.0/24 -j ACCEPT

-A INPUT -m state --state NEW -m tcp -p tcp --dport 3306 -s 192.168.192.0/24 -j ACCEPT

# FTP data transfer (Passive )

-A INPUT -m state --state NEW -m tcp -p tcp --dport 50020 -j ACCEPT

# Forward for interface

-A FORWARD -i sunghovpn -o eth0 -j ACCEPT

-A FORWARD -i eth0 -o sunghovpn -j ACCEPT

-A FORWARD -i sunghovpn -j ACCEPT

-A INPUT -i sunghovpn -j ACCEPT

 

# Another Input All deny with host not accepts message

-A INPUT -j REJECT --reject-with icmp-host-prohibited

COMMIT

 

 

 

1) 테이블(tables)

우선 iptables에는 테이블이라는 광범위한 범주가 있는데, 이 테이블은 filter, nat, mangle, raw 같은 4개의 테이블로 구성되며, 이중에서 우리에게 필요한 것은 필터링 규칙을 세우는 filter 테이블이다.

2) 체인(chain)

iptables에는 filter 테이블에 미리 정의된 세가지의 체인이 존재하는데 이는 INPUT, OUTPUT, FORWARD 이다. 이 체인들은 어떠한 네트워크 트래픽(IP 패킷)에 대하여 정해진 규칙들을 수행한다.

가령 들어오는 패킷(INPUT)에 대하여 허용(ACCEPT)할 것인지, 거부(REJECT)할 것인지, 버릴(DROP)것인지를 결정한다.

  • INPUT : 호스트 컴퓨터를 향한 모든 패킷
  • OUTPUT : 호스트 컴퓨터에서 발생하는 모든 패킷
  • FORWARD : 호스트 컴퓨터가 목적지가 아닌 모든 패킷, 즉 라우터로 사용되는 호스트 컴퓨터를 통과하는 패킷

3) 매치(match)

iptables에서 패킷을 처리할때 만족해야 하는 조건을 가리킨다. 즉, 이 조건을 만족시키는 패킷들만 규칙을 적용한다.

  • –source (-s) : 출발지 IP주소나 네트워크와의 매칭
  • –destination (-d) : 목적지 ip주소나 네트워크와의 매칭
  • –protocol (-p) : 특정 프로토콜과의 매칭
  • –in-interface (i) : 입력 인테페이스
  • –out-interface (-o) : 출력 인터페이스
  • –state : 연결 상태와의 매칭
  • –string : 애플리케이션 계층 데이터 바이트 순서와의 매칭
  • –comment : 커널 메모리 내의 규칙과 연계되는 최대 256바이트 주석
  • –syn (-y) : SYN 패킷을 허용하지 않는다.
  • –fragment (-f) : 두 번째 이후의 조각에 대해서 규칙을 명시한다.
  • –table (-t) : 처리될 테이블
  • –jump (-j) : 규칙에 맞는 패킷을 어떻게 처리할 것인가를 명시한다.
  • –match (-m) : 특정 모듈과의 매치

4) 타겟(target)

iptables는 패킷이 규칙과 일치할 때 동작을 취하는 타겟을 지원한다.

  • ACCEPT : 패킷을 받아들인다.
  • DROP : 패킷을 버린다(패킷이 전송된 적이 없던 것처럼).
  • REJECT : 패킷을 버리고 이와 동시에 적절한 응답 패킷을 전송한다.
  • LOG : 패킷을 syslog에 기록한다.
  • RETURN : 호출 체인 내에서 패킷 처리를 계속한다.

REJECT는 서비스에 접속하려는 사용자의 액세스를 거부하고 connection refused라는 오류 메시지를 보여주는 반면 DROP은 말 그대로 telnet 사용자에게 어떠한 경고 메시지도 보여주지 않은 채 패킷을 드롭한다. 관리자의 재량껏 이러한 규칙을 사용할 수 있지만 사용자가 혼란스러워하며 계속해서 접속을 시도하는 것을 방지하려면 REJECT를 사용하는 것이 좋다.

5) 연결 추적(Connection Tracking)

iptables는 연결 추적(connection tracking)이라는 방법을 사용하여 내부 네트워크 상 서비스 연결 상태에 따라서 그 연결을 감시하고 제한할 수 있게 해준다. 연결 추적 방식은 연결 상태를 표에 저장하기 때문에, 다음과 같은 연결 상태에 따라서 시스템 관리자가 연결을 허용하거나 거부할 수 있다.

  • NEW : 새로운 연결을 요청하는 패킷, 예, HTTP 요청
  • ESTABLISHED : 기존 연결의 일부인 패킷
  • RELATED : 기존 연결에 속하지만 새로운 연결을 요청하는 패킷, 예를 들면 접속 포트가 20인 수동 FTP의 경우 전송 포트는 사용되지 않은 1024 이상의 어느 포트라도 사용 가능하다.
  • INVALID : 연결 추적표에서 어디 연결에도 속하지 않은 패킷

상태에 기반(stateful)한 iptables 연결 추적 기능은 어느 네트워크 프로토콜에서나 사용 가능하다. UDP와 같이 상태를 저장하지 않는 (stateless) 프로토콜에서도 사용할 수 있다.

6) 명령어(commond)

  • -A (–append) : 새로운 규칙을 추가한다.
  • -D (–delete) : 규칙을 삭제한다.
  • -C (–check) : 패킷을 테스트한다.
  • -R (–replace) : 새로운 규칙으로 교체한다.
  • -I (–insert) : 새로운 규칙을 삽입한다.
  • -L (–list) : 규칙을 출력한다.
  • -F (–flush) : chain으로부터 규칙을 모두 삭제한다.
  • -Z (–zero) : 모든 chain의 패킷과 바이트 카운터 값을 0으로 만든다.
  • -N (–new) : 새로운 chain을 만든다.
  • -X (–delete-chain) : chain을 삭제한다.
  • -P (–policy) : 기본정책을 변경한다.

7) 기본 동작

  1. 패킷에 대한 동작은 위에서 부터 차례로 각 규칙에 대해 검사하고, 그 규칙과 일치하는 패킷에 대하여 타겟에 지정한 ACCEPT, DROP등을 수행한다.
  2. 규칙이 일치하고 작업이 수행되면, 그 패킷은 해당 규칙의 결과에 따리 처리하고 체인에서 추가 규칙을 무시한다.
  3. 패킷이 체인의 모든 규칙과 매치하지 않아 규칙의 바닥에 도달하면 정해진 기본정책(policy)이 수행된다.
  4. 기본 정책은 policy ACCEPT , policy DROP 으로 설정할 수 있다.

일반적으로 기본정책은 모든 패킷에 대해 DROP을 설정하고 특별히 지정된 포트와 IP주소등에 대해 ACCEPT를 수행하게 만든다.

 

 

[linux] Mailx 를 이용한 HTML 폼 전송.

지난번 글에는 mailx를 이용하여 파일을 첨부하여 전달하는 방법에 대해 공유 드렸습니다.

관련 링크 : http://blog.hongstalk.com/?p=310

 

이번에는 mailx 를 이용한 HTML 컨텐츠 타입의 폼을 생성하여 전송하는 방법에 대해 공유 합니다.

방법은 subject , 제목을 입력 할때 subject header 밑에 content-type을 명시하는 방법을 사용합니다.

 

커멘드는 아래와 같습니다.

mail -S smtp=localhost:25 -s "$(echo -e 'HI TEST\nContent-type: text/html')" -r noreply@jinstalk.com nic2hong@jinstalk.com < hong.html

위의 부분에 hong.html 에는 테스트를 위해 적당한 내용을 작성합니다.

<html>

<head> sungho </head>

<body>

<h1><center>Sungho TEST</center></h1>

<br>

<br>

<font color=red>This is</font> Sparta.

</body>

</html>

 

위와 같은 형태로 하실때 주의 하실 점은

-s 뒤에 “$( 부분에 echo -e 옵션입니다. \n을 통해서 줄 바꿈을 적용하기 위해서는 해당 옵션을 꼭 넣어주세요.

 

발송이 완료 되면 다음과 같은 형태로 메일이 날아갑니다.

아래 부분은 실제 HTML 타입으로 날아간 메일의 해더 순서에 주목해주시면 됩니다.

(제목 바로 밑에 컨텐츠 타입 : 하이퍼텍스트 명시되어 있는 부분이 echo 를 통해서 추가된 헤더입니다. )

[etc] URL encode & decode

browser 에서 문자열이 encode 되어 들어가는 명칭에 대한 부분입니다.

추후에도 찾기 쉽게 정리해둡니다.

html 등의 소스에서 잘못된 값이 들어가는 경우 (주로 스페이스) 등이 발생하는 경우 확인하기 편리합니다~

참고로 아래 사이트에서는 실제 인코드&디코드 결과를 바로 확인 가능하니 즐겨찾기 등을 해두시면 수월합니다.

http://www.url-encode-decode.com/

 

Character From Windows-1252 From UTF-8
space %20 %20
! %21 %21
%22 %22
# %23 %23
$ %24 %24
% %25 %25
& %26 %26
%27 %27
( %28 %28
) %29 %29
* %2A %2A
+ %2B %2B
, %2C %2C
%2D %2D
. %2E %2E
/ %2F %2F
0 %30 %30
1 %31 %31
2 %32 %32
3 %33 %33
4 %34 %34
5 %35 %35
6 %36 %36
7 %37 %37
8 %38 %38
9 %39 %39
: %3A %3A
; %3B %3B
< %3C %3C
= %3D %3D
> %3E %3E
? %3F %3F
@ %40 %40
A %41 %41
B %42 %42
C %43 %43
D %44 %44
E %45 %45
F %46 %46
G %47 %47
H %48 %48
I %49 %49
J %4A %4A
K %4B %4B
L %4C %4C
M %4D %4D
N %4E %4E
O %4F %4F
P %50 %50
Q %51 %51
R %52 %52
S %53 %53
T %54 %54
U %55 %55
V %56 %56
W %57 %57
X %58 %58
Y %59 %59
Z %5A %5A
[ %5B %5B
\ %5C %5C
] %5D %5D
^ %5E %5E
_ %5F %5F
` %60 %60
a %61 %61
b %62 %62
c %63 %63
d %64 %64
e %65 %65
f %66 %66
g %67 %67
h %68 %68
i %69 %69
j %6A %6A
k %6B %6B
l %6C %6C
m %6D %6D
n %6E %6E
o %6F %6F
p %70 %70
q %71 %71
r %72 %72
s %73 %73
t %74 %74
u %75 %75
v %76 %76
w %77 %77
x %78 %78
y %79 %79
z %7A %7A
{ %7B %7B
| %7C %7C
} %7D %7D
~ %7E %7E
%7F %7F
` %80 %E2%82%AC
 %81 %81
%82 %E2%80%9A
ƒ %83 %C6%92
%84 %E2%80%9E
%85 %E2%80%A6
%86 %E2%80%A0
%87 %E2%80%A1
ˆ %88 %CB%86
%89 %E2%80%B0
Š %8A %C5%A0
%8B %E2%80%B9
Π%8C %C5%92
 %8D %C5%8D
Ž %8E %C5%BD
 %8F %8F
 %90 %C2%90
%91 %E2%80%98
%92 %E2%80%99
%93 %E2%80%9C
%94 %E2%80%9D
%95 %E2%80%A2
%96 %E2%80%93
%97 %E2%80%94
˜ %98 %CB%9C
%99 %E2%84
š %9A %C5%A1
%9B %E2%80
œ %9C %C5%93
 %9D %9D
ž %9E %C5%BE
Ÿ %9F %C5%B8
%A0 %C2%A0
¡ %A1 %C2%A1
¢ %A2 %C2%A2
£ %A3 %C2%A3
¤ %A4 %C2%A4
¥ %A5 %C2%A5
¦ %A6 %C2%A6
§ %A7 %C2%A7
¨ %A8 %C2%A8
© %A9 %C2%A9
ª %AA %C2%AA
« %AB %C2%AB
¬ %AC %C2%AC
%AD %C2%AD
® %AE %C2%AE
¯ %AF %C2%AF
° %B0 %C2%B0
± %B1 %C2%B1
² %B2 %C2%B2
³ %B3 %C2%B3
´ %B4 %C2%B4
µ %B5 %C2%B5
%B6 %C2%B6
· %B7 %C2%B7
¸ %B8 %C2%B8
¹ %B9 %C2%B9
º %BA %C2%BA
» %BB %C2%BB
¼ %BC %C2%BC
½ %BD %C2%BD
¾ %BE %C2%BE
¿ %BF %C2%BF
À %C0 %C3%80
Á %C1 %C3%81
 %C2 %C3%82
à %C3 %C3%83
Ä %C4 %C3%84
Å %C5 %C3%85
Æ %C6 %C3%86
Ç %C7 %C3%87
È %C8 %C3%88
É %C9 %C3%89
Ê %CA %C3%8A
Ë %CB %C3%8B
Ì %CC %C3%8C
Í %CD %C3%8D
Î %CE %C3%8E
Ï %CF %C3%8F
Ð %D0 %C3%90
Ñ %D1 %C3%91
Ò %D2 %C3%92
Ó %D3 %C3%93
Ô %D4 %C3%94
Õ %D5 %C3%95
Ö %D6 %C3%96
× %D7 %C3%97
Ø %D8 %C3%98
Ù %D9 %C3%99
Ú %DA %C3%9A
Û %DB %C3%9B
Ü %DC %C3%9C
Ý %DD %C3%9D
Þ %DE %C3%9E
ß %DF %C3%9F
à %E0 %C3%A0
á %E1 %C3%A1
â %E2 %C3%A2
ã %E3 %C3%A3
ä %E4 %C3%A4
å %E5 %C3%A5
æ %E6 %C3%A6
ç %E7 %C3%A7
è %E8 %C3%A8
é %E9 %C3%A9
ê %EA %C3%AA
ë %EB %C3%AB
ì %EC %C3%AC
í %ED %C3%AD
î %EE %C3%AE
ï %EF %C3%AF
ð %F0 %C3%B0
ñ %F1 %C3%B1
ò %F2 %C3%B2
ó %F3 %C3%B3
ô %F4 %C3%B4
õ %F5 %C3%B5
ö %F6 %C3%B6
÷ %F7 %C3%B7
ø %F8 %C3%B8
ù %F9 %C3%B9
ú %FA %C3%BA
û %FB %C3%BB
ü %FC %C3%BC
ý %FD %C3%BD
þ %FE %C3%BE
ÿ %FF %C3%BF

[AWS] 보유중인 route53 호스트 정보를 기반으로 레코드 정보 읽어오기

AWS 에서, ELB 나 클라우드프론트 등 제공되는 서비스의 영역에서,

고정된 EIP가 아닌 경우 해당 호스트에 매핑되어 있는, 아이피 정보는 생각보다 빈번하게 변경됩니다.

 

관련하여, 아래와 같이 보유중인 호스트존 정보를 읽고, 해당 레코드 타입의 도메인의 아이피를 업데이트 할 수 있는 방법을 정리합니다.

해당 스크립트는 awscli를 이용합니다.

코드 관련 에디터툴을 적절한 것을 아직 찾지 못해 보기가 불편한점 양해부탁드립니다. ^^;;;

#!/bin/bash

# SCL python27 project enable

source /opt/rh/python27/enable

 

#qury all HOSTZONEID

ZONEIDS=`aws –profile dnsview route53 list-hosted-zones-by-name –query “HostedZones[].Id” –output text`

 

for ZONEID in ${ZONEIDS[@]}

do

if [ “$ZONEID” != “/hostedzone/Z2NKR4123123123” ];

then

#============ QUERY FOR ALL HOSTZONE ID in OUR ACCOUNT ===================

#A record domain query

afqdn=`aws –profile dnsview route53 list-resource-record-sets –hosted-zone-id ${ZONEID} –output text –query “ResourceRecordSets[?Type==’A’].Name”`

for domain in ${afqdn[@]}

do

ips=`dig +short $domain`;

echo -e “$domain \t(Type A)”;

for ip in ${ips[@]}

do

echo -e “\t$ip”;

done

done

#CNAME record domain query

cfqdn=`aws –profile dnsview route53 list-resource-record-sets –hosted-zone-id ${ZONEID} –output text –query “ResourceRecordSets[?Type==’CNAME’].Name”`

# Unset Variable

unset domain;

unset ips;

unset ip;

for domain in ${cfqdn[@]}

do

ips=`dig +short $domain`;

echo -e “$domain \t(Type CNAME)”;

for ip in ${ips[@]}

do

echo -e “\t$ip”;

done

done

#============ QUERY FOR ALL HOSTZONE ID in OUR ACCOUNT ===================

else

echo -e “\n”;

fi

done

[etc] ElasticSearch – cloud-aws Plugin

엘라스틱 서치 운영에 있어, 클러스터링 할 노드들에 대한 ping & discover 관련하여 매우 유용한 플러그인이 존재합니다.

기존 기 배포된 인스턴스에 올리는 형태가 아닌 자동화를 생각하신다면 해당 플러그인이 매우 유용하게 사용될 것입니다.

제 경우는 Ansible이란 툴을 이용해서 배포 및 형상관리를 진행하고 있는데요,

아래와 같은 방법을 통해서 클라우드 환경에 클러스터 노드를 구축합니다.

아래는 샘플입니다.

<pre><code>

# {{ ansible_managed }}

cluster.name: 클러스터명

node.name: {{ ansible_hostname }}

node.master: true

node.data: true

network.host: 0.0.0.0

bootstrap.mlockall: true

discovery.zen.ping_interval: 5s

discovery.zen.ping_timeout: 30s

discovery.zen.ping_retries: 3

# cloud-aws by hong

plugin.mandatory: “cloud-aws”

cloud.aws.region: “ap-northeast-1”

cloud.aws.access_key: “액세스키”

cloud.aws.secret_key: “시크릿키”

discovery.zen.ping.multicast.enabled: false

discovery.type: “ec2”

discovery.ec2.groups: “시큐리티그룹명”

discovery.ec2.host_type: “private_ip”

discovery.ec2.ping_timeout: “30s”

discovery.ec2.availability_zones: [“ap-northeast-1a”, “ap-northeast-1c”]

</code></pre>

 

위의 설정중 눈여겨 볼 부분은 # 주석의 cloud-aws 부분입니다.

해당 기능을 사용하는데 있어, 백업 & 리스토어 기능을 사용하기 위해서는 s3 권한을

자동 디스커버 관련 권한은 ec2-describe관련 권한이 필요합니다.

해당 IAM 키를 생성하실때 아래와 같은 폴리시를 이용하시면 됩니다.

{

“Version”: “2012-10-17”,

“Statement”: [

{

“Effect”: “Allow”,

“Action”: “s3:*”,

“Resource”: [

“arn:aws:s3:::버킷명”,

“arn:aws:s3:::버킷명/*”

]

},

{

“Effect”: “Allow”,

“Action”: “EC2:Describe*”,

“Resource”: “*”

}

]

}

 

해당 기능을 이용하여 ElasticSearch 데이터를 백업 복구 할 수 있으며 S3를 이용하기에 리전간 마이그레이션에도 이용할 수 있습니다.

주목할 만한 점은, discover옵션 중 discover.ec2.groups 지시자를 통해 동일한 Security Group을 사용하는 인스턴스에 discover가 가능하기 때문에, 고정된 아이피를 사용하지 않는 환경에서도 적절히 사용할 수 있다는 점입니다.

 

추가 옵션 설정등은 추후 정리하도록 하겠습니다~