Category: HowTo

UBUNTU 14.04 KVM 게스트에 콘솔 접속하기

KVM 가상화를 사용하고 있고 게스트로 Ubuntu14.04 를 사용하고 있다면 콘솔 접속을 위해서는 다음과 같이 해주어야 한다.

ttyS0 터미널 설정

KVM 게스트인 Ubuntu14.04 에 콘솔로 접속하기 위해서는 게스트 Ubuntu14.04 에 ttyS0 터미널로 접속을 해야 한다. 그런데 Ubuntu 14.04 에는 ttyS0 터미널 설정이 되어 있지 않아 이를 설정을 해야 한다.

/etc/init/ttyS0.conf 파일을 다음과 같이 생성한다.

 

그리고 다음과 같이 /etc/securetty 파일에 ttyS0 를 추가 해준다.

 

/etc/default/grub 편집

이제 grub 에서 ttyS0 이 콘솔 접속이 되도록 다음과 같이 편접해 준다.

위와같이 편접을 한 후에 grub 을 다시 시작해 줍니다.

 

위와같이 설정을 하고 재부팅을 한 후에 KVM 콘솔 접속을 하면 아주 잘 됩니다.

 

Creative Commons License
UBUNTU 14.04 KVM 게스트에 콘솔 접속하기 by Voyager of Linux is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.

KVM에 Bridge Network 설정

CentOS 6 에는 가상화로 KVM만 지원합니다. Xen은 빼버렸습니다. 가상화로 KVM을 하게되면 사용할 수 있게됩니다. 그런데, KVM을 활성화하게 되면 virbr0 라는 가상의 이더넷이 생성이되는데 이것이 NAT로 동작하게 됩니다. 그러니까 KVM의 게스트들은 virbr0 의 NAT를 이용해서 인터넷을 하게 되는 것입니다.

그런데 제가 집에서 사용하는 인터넷 사용환경은 공유기를 이용해서 각 피시에서 private ip 주소를 할당해서 사용합니다. 그래서 KVM의 게스트들도 직접 공유기로 부터 private ip 주소를 할당 받기를 원했습니다. 그렇게 하기위해서는 virbr0 를 NAT를 정지시키고 br0 을 만들어서 eth0와 br0를 Bridged 시키면 됩니다.

이 문서는 이것을 설명한 것입니다.

처음 KVM을 설치해서 보면 다음과 같이 나옵니다. NAT로 동작하고 있다는 증거입니다.

Bridged 로 바꿔보겠습니다. 절차는 다음과 같습니다.

  1. virbr0 를 지웁니다.
  2. eth0 에 dhcp 기능을 지우고 br0 로 Bridged 한다.
  3. br0 만드는데, dhcp 로 아이피를 새로 받도록 한다. TYPE 를 Bridged 로 해준다.

Virbr0 를 지운다. 

버추얼쉘(virsh) 명령어를 이용해 네트워크 리스트를 봅니다.

버추얼 네트워크 이름이 ‘default’로 나오네요. 이것을 지우겠습니다.

eth0 의 dhcp 를 지우고 br0 로 Bridged 한다.

다음과 같이 합니다.

br0 를 만든다.

다음과 같이 합니다.

위과정을 거치면 설정은 끝납니다. 한가지 더 있는데, 리눅스의 NetworkManager 데몬을 꺼주고 network 서비스를 다시 올려줍니다.

이제 virt-manager 로 KVM 게스트를 설치할 다음과 같이 이더넷을 설정해 주면 됩니다.

Virt-Manager 에서 Br0 설정

 

Creative Commons License
KVM에 Bridge Network 설정 by Voyager of Linux is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.

Ubuntu 16.04 KVM 게스트에 콘솔 접속하기

KVM 가상화를 사용하고 있고 게스트로 Ubuntu16.04 를 사용하고 있다면 콘솔 접속을 위해서는 Grub2 설정을 다음과 같이 해주면 된다.

위와같이 해주고 다음과 같이 grub 을 갱신해준다.

 

Creative Commons License
Ubuntu 16.04 KVM 게스트에 콘솔 접속하기 by Voyager of Linux is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.

[AWS] Private Subnet 으로 서비스 구성하기.

AWS 는 전 세계적으로 가장 인기있는 Cloud Platform 이다. Web Console을 이용해서 원하는 자원을 구성하고 컴퓨터, 네트워크, 저장소등을 실시간으로 생성할 수 있으며 네트워킹 구성도 실시간으로 구성이 가능하다.

그래서 많은 IT 업체들이 AWS 클라우드를 사용하고 있다. 특히나 전 세계를 대상으로 인터넷 서비스를 하려는 업체들은 AWS 를 통해서 막대한 IT 인프라 구축비용 절감하고 있다.

오늘은 AWS 클라우드를 이용해서 가장 많은 구성이며 기본적인 구성인 Web Service 를 Private Subnet 을 이용해 구성해보도록 하겠다.

이 포스트는 AWS 클라우드에 대해서 어느정도 기초지식을 갖추고 있다고 가정하고 쓰여졌다. AWS 클라우드를 사용하기 위해서는 기본적인 개념들이 존재하는데, 예를들어 VPC, ELB, Security Group, Route Table, InterGateWay 등에 대해서 모두 알고 있다라고 가정한다.

목표

내가 목표로하는 전체적인 시스템 구성은 다음과 같다.

Private Subnet 서비스 구성도

위 구성도에서 눈여겨 봐야할 포인트는 다음과 같다.

  • 외부 인터넷과 연결을 위해서 반드시 Public Subnet 이 한개는 있어야 한다.
  • 서비스를 제공할 인스턴스들은 Private Subnet 에 있어야 한다.
  • Private Subnet 에 있는 인스턴스들에서 외부와의 인터넷 통신은 Public Subnet 에 있는 NAT 서버를 통해서 한다.
  • Private Subnet 에 Web Service 인스턴스들은 ELB(Elastic Load Balancer) 를 통해서 하며 ELB는 반드시 Public Subnet 에 있어야 한다.

 

VPC 생성하기

AWS 서비스에 가입하면 각 Region 마다 기본적인 사항들이 자동으로 생성된다. 그중에 VPC도 다음과 같이 기본으로 생성이 된다. Tokyo Region은 다음과 같다.

  • VPC CIDR: 172.31.0.0/16
  • Route table: rtb-ef0bcd8a
  • Network ACL: acl-3cef2859
  • Subnet: subnet-55d41722
  • Subnet Type: Public

Default VPC 은 인터넷과 자동으로 연결된 거대한 하나의 Public Subnet 기도 하다. 하지만 나는 이 Public Subnet 을 사용하지 않고 새롭게 VPC을 생성할 것이다. VPC 의 생성에서 고려해야할 사항은 얼마만큼의 IP 대역을 사용할 것인가에 있다.

Web Service VPC 생성
Web Service VPC 생성

Subnet 생성하기

이제 서브넷을 생성해야 한다. 중요한 것은 Public Subnet 1개와 Private Subnet 1개는 반드시 있어야 한다.

여기서 중요한 것도 IP 대역이다. 한 서브넷에 얼마만큼의 IP 대역을 쓸것인가 하는 것이다. 나는 다음과 같이 할당 했다.

  • Public Subnet: 10.31.0.0/22 – 1018 개 IP 대역, AZ: ap-northeast-1b, Name: JumpSubnet(NAT)
  • Private Subnet: 10.31.4.0/22 – 1018 개 IP 대역, AZ: ap-northeast-1b, Name: WebSubnet

여기서 한가지 Public Subnet, Private Subnet 을 구분하는 설정값은 존재하지 않는다. AWS 에서 이 둘의 구분은 Internet Gateway 와 연결이 되어진 네트워크이냐 아니냐에 따라 달라진다. Internet Gateway 에 연결되었다면 Public, 그렇지 않으면 Private 이라는 개념이다. 그럼 이러한 연결 설정은 어디서 하는가?

Subnet 에 대해서 Internet Gateway 연결을 하거나 기타 네트워크 경로 설정은 Route Table 에서 하기 된다.  Route Table 에서 생설할때에 고려해야 할 사항은 다음과 같다.

  • 어느 서브넷과 연결시킬 것인가?
  • 어떤 외부세계와 연결시킬 것인가?

Route Table 이 존재하면 수정을하고 없으면 생성을 하면 된다.

Public Subnet

Public 서스넷 Route Table 서브넷 연결
Public 서스넷 Route Table 서브넷 연결
Public 서스넷 Route Table 라우팅 테이블
Public 서스넷 Route Table 라우팅 테이블

Public Subnet 을 위한 Route Table 은 위와같이 연결할 서브넷과 라우팅 테이블을 정의해주면 된다. 여기서 핵심은 라우팅 테이블에서 Internet Gateway 연결을 해줘야한다. 위 화면에서 igw-98de5cfd 가 바로 그것이다.

Internet Gateway 가 연결되어 있다면 그것이 Public Subnet 이 된다.

Private Subnet

Private 서스넷 Route Table 서브넷 연결
Private 서스넷 Route Table 서브넷 연결
Private 서스넷 Route Table 라우팅 테이블
Private 서스넷 Route Table 라우팅 테이블

Private Subnet 을 위한 서브넷 연결과 라우팅 테이블은 위와 같습니다. 라이팅 테이블을 보면 Internet Gateway 연결이 없다. 그래서 이 라우팅 테이블과 연결된 Subnet 은 Private Subnet 이 된다.

Private Subnet 은 외부 인터넷과 연결이 안되기 때문에 Private Subnet 인스턴스에 접속하고 제어하고 Private Subnet 의 인스턴스들이 인터넷연결을 위한 NAT 인스턴스가 필요하다.

Security Group 생성

Security Group 은 인터넷 방화벽이라고 생각하면 편하다. Security Group 은 인스턴스마다 할당할 수 있다. Security Group 에도 NAT를 위한 것과 NAT 에 의존해야할 인스턴스를 위한 것 두개를 만든다.

Security Group 을 생성할대는 Inbound 프로토콜, 포트 와 Outbound 프로토콜, 포트 를 생각해야 한다.

NAT Security Group

Outbound 는 “All Traffic” 으로 제약을 풀어줘도 된다. 보안상 외부로의 접속을 차단해야할 상황이라면 설정을 해야하면 된다.

Inbound 접속 제한을 해야함으로 다음과 같이 설정해준다.

NAT 를 위한 Security Group
NAT 를 위한 Security Group

중요한 사항은 80, 443, ICMP 에 대한 NAT 접속은 Private Subnet 으로부터 받는걸로 설정을 해야 한다는 것이다.

NAT 의존하는 인스턴스를 위한 Security Group

Outbound 는 “All Traffic” 으로 제약을 풀어줘도 된다. 물론 보안상 문제가 된다면 제한을 걸고 싶은 포트를 지정해주면 된다.

NAT 에 의존하는 인스턴를 위한 Security Group
NAT 에 의존하는 인스턴를 위한 Security Group

SSH 서비스 접속포트는 NAT 서버 주소를 지정해준다. HTTP, HTTPS, ICMP 는 모든 영역에서 접속을 허용하도록 한다. 왜 이렇게 하냐하면 HTTP, HTTPS 는 AWS 의 Public ELB 를 통해서 외부로 서비스를 해야하는데 Public ELB -> private subnet 인스턴스에 접속이 이루어져야 하기 때문인데 문제는 접속할 IP를 알수가 없다. 그래서 접속하는 주소지를 모두 열어준다.

NAT Instance 생성

NAT Instance 가 필요한 이유는 다음과 같다.

  • Private Subnet 에 있는 인스턴스들을 제어하기 위해
  • Private Subnet 에 있는 인스턴스들이 인터넷을 하기 위해.

Private Subnet 에 있는 인스턴스들이 인터넷이 되어야 하는 이유는 OS 및 각종 소프트웨어의 자동 업데이트 때문이다. 보안 업데이트를 하기위해서는 업데이트 프로그램을 다운로드해야하는데 대부분 인터넷을 통해서 다운로드가 된다. 따라서 Private Subnet 도 인터넷이 되어야 한다.

또다른 이유는 AWS 의 S3 와 같은 외부 서비스를 이용하기 위해서다. S3 저장소는 HTTP 주소를 통해서 자원에 접근할 수 있도록 해주는데, 이를 Private Subnet 에서 이용하기 위해서는 인터넷이 되어야 한다.

NAT Instance 는 외부에서 연결을 해야함으로 EIP를 할당해준다. EIP가 없더라도 Public Ip를 할당해줘야 한다. 그리고 Subnet 은 Public Subnet 과 연결해 준다.

  • Instance: EC2 Linux System
  • Subnet: JumpSubnet(NAT)
  • Seucrity Group: NAT 를 위해 생성한 Security Group
  • EIP, Public IP 할당

중요한 것은 반드시 Public Subnet 에 인스턴스를 생성해 준다.

Private Subnet Route Table 조작

이제 앞에서 Private Subent 의 Route Table 을 조작할 때다. Private Subnet 의 Route Table 은 Local 외에 모든 연결을 NAT Instance 로 가게 설정 한다.

Private Subnet 을 위한 라우팅 테이블 조작
Private Subnet 을 위한 라우팅 테이블 조작

위와 같이 두번째 타켓으로 NAT 인스턴스를 지정해 준다. 그러면 이 라이팅에 연결된 Subnet 들은 외부와 통신을 위해서 NAT 인스턴스를 통해서 이루어지게 된다.

NAT 인스턴스 마스커레이딩 설정

지금까지의 내용은 인터넷을 찾아보면 나온다. 하지만 여기까지만 하면 절대로 Private Subnet 에 인스턴스에서 인터넷이 될수가 없다. 지금까지의 작업은 Network 단에서의 작업이였다. Security Group은 인스턴스단에서 이루어진 방화벽 작업일뿐 패킷의 경로를 조작해주는 것은 아니였다.

그런데, 이 모든 것을 다한다고 하더라도 OS에서 패킷의 경로를 원하는대로 조작해주지 않으면 Private Subnet 에 인스턴스들로부터 온 패킷과 받는 패킷들은 전송되지 않는다.

NAT 라는 것을 간단하게 설명하자면 우리가 가정에서 많이 쓰는 공유기와 같은 기능을 한다. 외부의 공인아이피를 가지고 내부의 사설 아이피를 할당해서 인터넷이 되게하는 것이 공유기의 역활인데, NAT 도 똑같다.

공유기가 없던 시절에 리눅스를 이용해서 공유기를 만들었었는데, 리눅스에 네트워크 카드를 두개 끼우고 하나는 외부망에 하나는 내부망에 연결하고 내부망에 허브를 두고 서로 통신이되도록 리눅스에서 설정을 해줬었다. 이 설정을 마스커레이딩(MASQUERADE) 이라 불렀다.

먼저 리눅스 커널에서 패킷을 포워딩 하도록 다음과 같이 설정해 준다.

그리고 iptables 에 nat 체인에 마스커레이딩 설정을 해준다.

Private 인스턴스 접속

Private 인스턴스를 접속하기 위해서는 다음과 같은 절차를 따른다.

  • 먼저 NAT 서버에 SSH 접속을 한다.
  • NAT 서버에서 Private 인스턴스로 접속을 한다.

Private 인스턴스에 접속한 후에 OS 업데이트 명령을 쳐보고 잘된다면 설정이 제대로 된 것이다.

ELB  설정.

Elastic Load Balancer 는 여러개의 서버들을 한대 묶어서 분산을 시켜주는 역활을 한다. 기존의 L4 스위치와 같은 역활을 하는 것인데 설정을 하게되면 ELB 접속을 위한 도메인이 생성된다. 이 도메인은 Amazon 에서 자동할당된 것으로 이것을 바꾸고 싶다면 DNS 서버에서 CNAME 으로 도메인을 등록하면 된다.

한가지 ELB의 제약 조건이 있는데, 그것은 반드시 Internet Gateway 와 연결되어야 한다. 이 말을 바꿔서 말하면 ELB는 반드시 Public Subnet 에 위치해야 한다는 뜻이다.

결국 ELB 때문이라도 반드시 하나의 Public Subnet 이 있어야 한다는 결론이 나온다.

ELB 설정
ELB 설정

위 그림을 보면 JumpSubnet(NAT)가 보이는데, 이게 바로 Public Subnet 이다. 반드시 1개의 Public Subnet 을 포함한다면 나머지 서브넷은 Private 이여도 상관이 없고 Private Subnet 에 있는 인스턴스들도 ELB를 통해서 서비스를 할 수 있게 된다.

ELB 에서 뒷단의 인스턴스들을 선택하기 위해서는 먼저 Subnet 을 반드시 선택해줘야 한다.

Private Subnet 의 인스턴스가 선택된 상태
Private Subnet 의 인스턴스가 선택된 상태

위와 같이 Private Subnet 의 인스턴스를 선택할 수 있다. ELB의 경우 대부분 HTTP 80 을 Inbound 로 받기 때문에 Private Subnet 안에 설치한 인스턴스에 웹서버를 올리기 되면 ELB를 통해서 서비스를 제공할 수 있게 된다.

 

이것으로 간단하게 Private Subnet 으로 서비스 구성하기 에 대해 간단하게 정리해 봤다.

Creative Commons License
[AWS] Private Subnet 으로 서비스 구성하기. by Voyager of Linux is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.

가상 Guest 이미지 마운팅

가상 Guest OS의 이미지를 마운트하는 법을 설명합니다. 이미지 마운트에는 두가지 방법이 있습니다.

첫번째방법

1.Guest OS 이미지에 파티션으로부터 디바이스 맵(Device Map)을 생성합니다.

2.볼륨(Volume) 그룹을 스캔합니다.

이렇게 볼륨이 잡히면 이 방법은 유효합니다. 그렇지 않으면 두번째 방법을 사용해야 합니다.

3.볼륨(volume) 그룹의 속성을 바꿉니다.

볼륨의 상태를 확인합니다.

4.이제 볼륨을 마운팅하면 됩니다.


이렇게 마운트가 되면 마운트 포인터(Mount Point)를 통해서 접근할 수 있습니다. 언마운트(Umount)는 다음과 같이 합니다.

5.언마운트(Unmount) 합니다.

6.볼륨속성을 바꿉니다.

7.디바이스 맵을 지웁니다.

두번째 방법

두번째 방법은 위의 첫번째 방법 2번째에서 오류가 날경우에 사용하면 됩니다. 즉, 볼륨을 스캔했는데 볼륨이 없다면 바로 마운팅하는 것입니다.

1.Guest OS 이미지에 파티션으로부터 디바이스 맵(Device Map)을 생성합니다.

2.볼륨 그룹을 스캔합니다.

이렇게 볼륨 그룹이 없다고 나옵니다.

3.그냥 마운트를 하면 됩니다.

4.Unmount 는 다음과 같이 합니다.

 

Creative Commons License
가상 Guest 이미지 마운팅 by Voyager of Linux is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.

CentOS 7 Systemd 이해하기

CentOS 7로 배포판 버전이 바뀌면서 가장 크게 바뀐것이 Systemd 입니다. 기존의 볼수 없었던 서비스 하나일뿐이라고 생각할 수 있지만 Systemd 는 단지 서비스 하나의 문제가 아닙니다.

Linux 의 기본 뼈대 프로세스

Linux는 운영체제 입니다. 전원을 넣고 부팅이 되는 과정에서 시스템을 초기화하고 기타 서비스들을 위한 환경을 조성하고 그들을 시작시켜주는 일을 하는 초기화 프로세스가 필요합니다.

CentOS 6 까지는 Sys V 라고해서 init 프로세스가 이것을 담당했습니다. 커널이 메모리에 로딩되면 가장 먼저 실행되는 프로세스로 init 프로세스를 실행시킵니다. 이 프로세스는 init 스크립트, init 설정등을 기반으로 RunLevel 이나 각 서비스별 실행 스크립트를 실행시키는 겁니다.

CentOS 7 로 올라오면서 Sys V 의 init 프로세스를 버리고 Systemd 로 바꾼 겁니다. 이는 Linux 의 기본 뼈대 프로세스를 바꾼 것으로 매우 큰 변화라고 할만 합니다. Systemd 는 기준의 Sys V init 보다 훨씬 많은 기능을 제공 합니다.

  1. 시스템 부팅 프로세스
  2. Service Management
  3. cgroup 을 이용한 프로세스 자원관리
  4. 서비스 프로세스 관리

흔히들 Daemon 프로그램들을 위한 로깅, 자원할당, 부팅관리등 Systemd 로 모두 할 수 있습니다.

주요한 명령어들

Systemd 를 위한 주요한 명령어들은 다음과 같습니다.

  1. systemctl
  2. systemd-analyze
  3. systemd-cgls
  4. systemd-cgtop
  5. systemd-loginctl

현재 작동하고 있는 서비스들 목록은 다음과 같이 확인 가능 합니다.

위 목록은 현재 동작중인 서비스들만 보여주는데, 모든 서비스들을 보고 싶다면 다음과 같습니다.

서비스 활성화, 비활성화, 시작, 정지, 재시작

부팅시에 서비스를 시작하도록 하기위 해서는 다음과 같이 해줍니다.

서비스 비활성화, 시작, 중지, 재시작, 릴로드는 다음과 같습니다.

서비스가 활성화, 실행중인지 다음과 같이 질의를 할 수 있습니다.

서비스 및 설정 파악

서비스에 대한 systemd 설정에 대한 모든 정보를 다음과 같이 확인할 수 있습니다.

각 서비스들은 서로간의 의존관계를 가지고 있습니다. 이는 다음과 같은 명령어로 확인이 가능합니다.

특정 서비스에 대한 의존성을 알고 싶다면 서비스명을 주면 됩니다.

Systemd 자체를 재시작하기 위해서는 다음과 같이 합니다.

Unit File 편집

다음과 같이 Unit file 출력도 지원합니다.

Systemd 는 기본적으로 /usr/lib/system 디렉토리에 Unit File 을 보관합니다. 그런데, 커스터마이징 하기위해서 이 파일들을 직접 편집하기 보다는 /etc/systemd/system/ntpd.service.d 처럼 커스터마이징 하고 싶은 서비스의 디렉토리를 만들고 .conf 로 끝나는 설정파일을 만들어서 바꾸고자하는 설정을 넣으면 됩니다. 만일 이러한 과정이 귀찮다면 단순하게 다음과 같이 함으로써 자동으로 알아서 커스터마이징 설정파일을 만들어줍니다.

위 명령어는 다음을 수행 합니다.

  1. /etc/systemd/system/ntpd.service.d 디렉토리 생성
  2. 시스템에 등록된 기본 편집기(대부분 VIM)을 연다.
  3. 내용을 입력하고 저장하면 1에서 생성한 디렉토리에 override.conf 파일을 생성하고 내용을 읽는다. (여기서 systemctl daemon-reload 는 불필요)

만일 /usr/lib/system/system/ntpd.service Unit File 자체를 편집하고 싶다면 –full 옵션을 주면 됩니다.

부팅 상태 분석

Systemd 의 주요한 임무는 부팅 과정을 관리하고 정보를 제공하는 것입니다. 부팅 시간 정보는 다음과 같이 확인할 수 있습니다.

총 1분 28초 정도 부팅하는데 걸렸다는 걸 알수 있습니다.

부팅과정에 각 서비스별 초기화하는데 걸린 시간은 다음과 같이 확인할 수 있습니다.

초기화하는데 걸린 시간을 기준으로 정렬해서 정보를 보여줍니다. kdump.service 가 1분 4초정도의 시간을 소비했습니다.

이러한 분석은 다음과 같이 html 파일로 덤프해서 볼 수도 있습니다.

plot.html 은 다음과 같습니다.

systemd-analyze plot

부팅시에 시간이 많이 걸리는 서비스들에 대해서 빨강색으로 표시해줍니다. 이 정보는 부팅과정에서 소비되는 시간을 측정해서 개선점을 찾게 도와줍니다.

시간을 많이 잡아먹는 서비스들을 트리형태로 엮어서(chain)로 볼수도 있습니다.

MariaDB 서비스에 대해서 엮여서 시간을 많이 소모하는 하는 서비스들을 보여 줍니다.

특정 서비스에 대해서 critical-chain 을 보고 싶다면 인수로 서비스명을 주면 됩니다.

서비스 실행을 실패한 서비스들은 다음과 같이 체크 가능 합니다.

타겟바꾸기

Systemd 에서 타겟(Target)은 동시에 서비스들을 시작하는걸 허용하기 위한 그룹 메커니즘입니다. 이는 Sys V 에 Run Level 과 비슷합니다. Sys V 에서는 init 명령어를 통해서 Run Level 를 바꿀 수 있었는데, Systemd 는 타겟을 바꿀 수 있습니다.

이 타겟에 따라서 부팅시 시작되는 서비스들이 달라집니다. 기본 값은 muti-user.target 입니다. 기본 값은 다음과 같이 바꿀 수 있습니다.

 

Creative Commons License
CentOS 7 Systemd 이해하기 by Voyager of Linux is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.

KVM Ubuntu 가상머신에 콘솔 접속하기

Ubuntu 를 KVM 가상머신으로 설치를 했다면 콘솔 접속을 해보면 안됩니다. 지난번에 CentOS6/7 배포판에서의 가상머신 콘솔접속에 대해서 다루어 었는데, Ubuntu 는 이들과 조금 다르기에 포스팅 해봅니다.

이 글은 ubuntu 14.04 를 대상으로 합니다.

처음 Ubuntu 를 KVM 가상머신으로 설치를 했다면 SSH 나 Virt-manager 나 vnc 를 이용해서 접속을 해야만 합니다. 그래야 콘솔접속을 위한 설정을 해볼 수 있습니다.

GRUB 설정

공통 Grub 설정은 /etc/default/grub 에 있습니다. 다음과 같이 설정을 해줍니다.

그리고 다음과 같이 업데이트를 해줍니다.

Serial 콘솔 만들기

다음과 같이 Serial 콘솔을 만들어 줍니다.

그리고 ttyS0.conf 파일을 다음과 같은 부분을 편집해 줍니다.

위와같이 수정해주고 리붓을 해줍니다.

테스트

Ubuntu 가상머신을 재부팅한 후에 호스트 서버에서 다음과 같이 콘솔 접속을 해봅니다. 그러면 다음과 같이 나오면 성공 입니다.

Enter 를 여러번 쳐주면 나옵니다.

 

Creative Commons License
KVM Ubuntu 가상머신에 콘솔 접속하기 by Voyager of Linux is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.

가상 머신에 콘솔 접속하기

CentOS 6/7 혹은 RHEL 6/7 은 KVM 가상화를 지원 합니다. 가상화를 위한 네트워크를 설정하고 가상화 패키지를 설치하면 이제 가상 머신, 게스트 OS 를 설치할 수 있게 됩니다. 그런데, 맨 처음에 게스트 OS 를 설치하고 나면 더구나 DHCP 로 IP를 할당 받는다면 설치가 끝나고 나서 할당된 IP를 모르기 때문에 바로 접속을 할 수가 없습니다.

그래서 virt-manager 를 이용해서 게시트OS 화면에 접속하고 로그인을 하고 IP를 확인한 후에 SSH를 이용해서 외부에서 접속이 가능해 집니다. 하지만 이것말고 호스트 OS 터미널에서 게스트 OS로 virsh 명령어를 이용해서 접속할 수 있는데 이것이 가상 머신에 콘솔 접속하기 입니다.

virsh 명령어

virsh 명령어는 호스트OS에서 게스트OS(가상머신)을 관리하기 위한 명령어 입니다.

가상머신 이름이 나오는데, 이를 이용해서 다음과 같이 직접 게스트OS에 접속이 가능합니다.

하지만 게스트OS에 접속이 안됩니다.

게스트OS Grub 설정 변경

이를위해서 게스트OS에 Grub 에 옵션으로 다음과 같이 ‘console=ttyS0’ 을 추가해 줍니다.

하지만 이렇게 하나하나 다 하기보다는 다음과같은 명령어를 이용하면 편합니다.

CentOS6/RHEL6 의 경우 – grubby

grubby 는 각종 옵션들을 쉽게 설정할 수 있게 해줍니다. 위의 경우에 다음과 같이 할 수 있습니다.

CentOS6/RHEL6 에는 이렇게만 하고 서버를 재시작해줍니다.

CentOS7/RHEL7 의 경우 – /etc/default/grub 편집

CentOS7/RHEL7 의 경우에는 grub2 를 채택하고 있고 공통적인 옵션들은 ‘/etc/default/grub’ 파일에 있습니다. 이 파일을 편집해 줍니다.

이렇게 하고 grub2 를 다음과 같이 갱신해 줍니다.

위와같이 하고 난후에 가상머신을 재시작해줍니다.

접속 테스트

가상머신을 재시작한 후에 호스트OS에서 다음과 같이 접속을 해봅니다.

명령어를 입력해주고 Enter 를 두번 쳐주면 접속 로그인이 나옵니다. Console 접속을 해제하기 위해서는 Ctl+] 를 입력하시면 됩니다.

 

Creative Commons License
가상 머신에 콘솔 접속하기 by Voyager of Linux is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.

Nginx 설정.

이 문서는 Nginx  설정에 대한 문서 입니다. 계속적으로 업데이트가 됩니다.

요청 메소드 제한

요청 메소드는 GET, HEAD, POST, PUT, DELETE 등이 있다. 문제는 대부분 웹 서비스는 GET, HEAD, POST 만 필요로한다는 것이다. Nginx 에서 이를 다음과 같이 제한 할 수 있다.

GZIP 설정

 

Creative Commons License
Nginx 설정. by Voyager of Linux is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.

DNS amplification DDos attacks (DNS 증폭 DDos 공격)

최근에 관리하는 서버에 트래픽이 몰리는 현상이 발생했다. 웹 서비스 트래픽도 아니기에 뭔가 싶어 봤더니 53 포트를 통한 input 트래픽이였다. 그래서 ngrep 으로 53 포트를 모니터링 하니 대략 다음과 같이 나왔다.

뭔가 자꾸 DNS 서버에 쿼리(Query)를 보내고 있었고 이로 인해서 트래픽이 발생하는게 분명했다.

DNS amplification DDos attacks (DNS 증폭 DDos 공격)

‘DNS amplification DDos Attacks’ 는 DNS 증폭 DDos 공격으로 불리운다. 왜 ‘증폭’ 일까?

DDos 는 대량의 트래픽이 필요하다. 초당 수십 Gbps 를 유발시켜야 하는데 이렇게 할려면 많은 장비가 필요하다. 그러다보니 DDos 공격을 개인이 한다는 건 무리가 있다. 그런데, DNS 서버는 이런 많은 장비 없이도 대량의 트래픽을 유발시킬 수 있는 구조적인 면을 안고 있다.

DNS 는 인터넷을 위해서는 반드시 존재해야만 하는 서버다. 인터넷 전화번호부 라고도 불리우는 서버로 인간의 주로 사용하는 도메인을 컴퓨터가 알아볼수 있는 IP 주소로 변환한다. 브라우저 주소창에 도메인을 입력하면 DNS 서버에 그 도메인의 IP 주소를 질의(Query) 한 후에 받은 IP를 가지고 실제 서버에 접속하는 구조다.

이렇게 DNS 는 질의(Query)를 받아 응답한다. 그런데, DNS 에 보낼 수 있는 질의(Query)는 다양하며 그중에서 재귀적 질의(Recursive Query) 가 문제가 된다. 재귀적 쿼리는 DNS 서버가 보유한 도메인 리스트에 질의한 내용이 없을 경우 이를 다른 DNS 서버에 질의하는 것을 말한다.

예를들어 DNS-A 이라는 DNS 서버에 naver.com 을 질의했다면 DNS-A 서버는 먼저 자신의 도메인 리스트에 naver.com 이 있는지 찾게 된다. 없다면 최상의 DNS 서버인 ROOT-DNS 서버에 DNS-A 서버가 naver.com 서버의 IP가 무엇인지 질의하게 된다. ROOT-DNS 서버는 naver.com 주소의 TLD(Top Level Domain) 인 .com DNS 서버에 물어보라고 DNS-A 서버에 알려주고 다시 DNS-A 서버는 .com TLD 서버에 질의한다. .com TLD 서버는 naver.com 네임서버에게 물어보라고 응답하고 DNS-A 서버는 드디어 naver.com 을 가진 DNS 서버에 IP를 요청하고 이를 받아서 클라이언트에게 응답하는 것으로 임무는 종료 된다.

  • OS에 설정된 DNS-A 서버에 naver.com 의 IP를 요청한다.
  • DNS-A 서버는 자신의 도메인 리스트나 도메인 캐쉬에서 naver.com IP를 찾는다. 있다면 응답하고 끝나게되고 없다면 다음으로 진행.
  • DNS-A 서버에 naver.com 이 없음을 알게된 서버는 최상의 DNS 서버은 ROOT-DNS 에 naver.com IP를 질의한다.
  • ROOT-DNS 는 naver.com 의 TLD (Top Level Domain) 인 .com DNS 에 물어보라고 DNS-A 에게 알려준다.
  • .com DNS 서버는 naver.com 도메인의 DNS 서버에게 물어보라고 DNS-A 에게 알려준다.
  • 마침내 DNS-A 서버는 naver.com 도메인의 DNS 서버에 IP가 뭐냐고 질의한다.

여기에 질의 내용을 ‘ANY’ 로 할 경우에는 응답하는 양이 많아진다. 도메인의 DNS 구성에는 MX, A, TXT, CNAME 등 다양하다. 질의할때에는 어떤 타입을 원하는지를 정할 수 있게 되는데, ANY 타입의 질의는 도메인이 가지고 있는 모든 정보를 원하게 된다.

결국 재귀적 질의와 ANY 타입의 질의를 결합해 초당 수백건의 도메인 질의를 보내게 되면 DNS 서버는 이 질의에 응하게되고 수십Gbps 의 응답 트래픽을 발생시키게 된다. 이것이 바로 ‘DNS 증폭 DDos 공격’ 이다.

이 공격은 대부분 DNS 의 잘못된 설정 탓이다. BIND 9 의 경우에는 재귀적 질의를 맞음으로써 간단하게 해결할 수 있다.

BIND 9 의 기본 설정은 ‘recursion yes’ 임으로 이를 바꿈으써 ‘DNS 증폭 DDos 공격’을 막을 수 있다. 이 공격을 막았을 경우 로그는 다음과 같이 쌓인다.

 

Creative Commons License
DNS amplification DDos attacks (DNS 증폭 DDos 공격) by Voyager of Linux is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.