Category: HowTo

Rate Limiting with NGINX and NGINX Plus

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

아주 유용한 것중에 하나지만 종종 잘못 이해하고 잘못 설정하게되는 NGINX 기능이 속도 제한(rate limiting) 이다. 이것은 주어진 특정한 시간동안 HTTP 요청양을 제한할 수 있도록 한다. 하나의 요청은 웹사이트의 홈페이지를 위한 GET 요청이나 로그인 폼에 POST 요청이다.

속도 제한은 보안 목적을 위해서 사용되어 질 수 있는데, 에를들어 부르트 포스 패스워드 추정 공격의 속도를 낮출 수 있다. 이것은 실제 사용자에 대해 들어오는 요청 비율을 일반적인 값으로 제한하고 (로깅을 통해) 대상 URL을 식별함으로써 DDos 공격으로부터 보호하는데 도움이 될 수 있다. 더 일반적으로, 동시에 아주 많은 사용자 요청으로 인해 압도되어지는 업스트림 애플리케이션 서버를 보호하는데 사용되어진다.

이 블로그에서는 NGINX의 속도 제한의 기본사항과 더블어 고급 설정에 대해서 다룬다. 속도 제한은 NGINX Plus 에 같은 방법으로 동작한다.

NGINX 속도 제한은 어떻게 작동하나

NGINX 속도 제한은 leaky bucket algorithm 을 사용하는데, 이것은 대역폭이 제한된 상황에서 버스트를 다루기 위해 패킷 교환 컴퓨터 네트워크와 통신에 널리 사용된다. 비유를 하자면, 물이 상단에서 부어지고 바닥에서 물이 줄줄 세는 양동이와 같다. 물을 붓는 속도가 양동이에서 새는 속도를 초과하면 물통이 넘치게 된다. 이것을 요청처리로 다시 보면, 물은 클라이언트로부터 요청으로 볼수 있고 양동이는 FIFO 스케줄링 알고리즘에 따라 처리를 기다리는 요청에 대한 큐로 볼 수 있다. 새는 물은 서버에 의해서 처리하기 위한 버퍼에 존재하는 요청으로 볼수 있고 물통이 넘치는 것은 폐기되고 결코 서비스될 수 없는 요청으로 볼 수 있다.

기본적인 속도 제한 설정하기

속도 제한은 두개의 메인 지시문으로 설정되는데, 다음의 예제처럼 limit_req_zonelimit_req 이다.

limit_req_zone 은 속도 제한에 대한 파라메터를 정의하고 limit_req 는 나타나는 컨텍스트 내에(예를들어, /login/ 에 대한 모든 요청) 속도 제한을 활성화 한다.

limit_req_zone 지시문은 일반적으로 http 블럭에 정의하는데, 여러 컨텍스트에서 사용할 수 있다. 이것은 다음과 같이 세개의 파라메터를 가진다.

  • Key – 제한이 적용되는 요청 특징을 정의한다. 위 예에서 NGINX 변수 $binary_remote_addr 은 클라이언트 IP 주소의 이진 표현을 보유한다. 이것은 각각의 유니크한 IP 주소를 세걔의 파라메터로 정의한 요청 속도로 제한 한다. (우리가 이 변수를 사용하는 이유는 일반 문자열로 표현되는 클라이언트 IP 주소 $remote_addr 변수보다 적은 공간을 가지기 때문이다.)
  • Zone – 각 IP 주소에 상태를 저장하는 사용되는 공유 메모리 존과 어떻게 요청이 제한된 URL 에 접근하는지에 대해 정의한다. 공유 메모리에 정보를 유지하는 다는 것은 NGINX 워크 프로세스들 사이에 공유될 수 있다는 뜻이다. 이 정의는 두 파트를 가진다: 존 이름은 zone= 키워드로 구별되어지고 크기는 콜론(:) 뒤에 온다. 약 16,000 IP 주소에 대한 상태정보는 1 메가 크기를 가지며 위 예제에서는 약 160,000 주소를 저장할 수 있다. 만약 NGINX 가 새로운 엔트리(IP 주소) 를 추가할 필요가 있을때 스토리지가 꽉 찼다면, 가장 오래된 엔트리를 제거 한다. 여유 공간이 새로운 레코드를 수용하기에 충분하지 않는다면, NGINX 는 503 (Service Temporarily Unavailable) 코드 상태를 리턴 한다. 게다가, 메모리 고갈을 방지하기 위해서는 NGINX 가 새로운 엔트리를 만들때마다 이전 60초 동안 사용되지 않은 항목을 최대 2개까지 제거해야 한다.
  • Rate – 최대 요청 속도 지정. 위 예제에서, 속도는 초당 10 요청을 초과할 수 없다. NGINX 는 실제로 요청을 밀리초(millisecond) 초 단위로 추적하므로 이 제한은 100 밀리초(ms) 마다 1개 요청에 해당 한다. 이 예제에서 버스트를 허용하지 않았기 때문에 이전에 허용 된 요청 이후 100ms 미만에 도착하면 요청이 거부 된다.

limit_req_zone 지시문은 속도 제한과 공유 메모리 존에 대한 파라메터를 정의하지만 실제로 요청 속도를 제한하지 않는다. 요청 속도를 제한하기 위해서는 특정한 location 이나 server 블럭에 limit_req 지시문을 포함하는 제한 적용이 필요하다. 위 예제에서는 /login/ 에 대한 요청 속도를 제한하고 있다.

그래서 이제 각각의 유니크한 IP 주소는 /login/ 에 대해 초당 10 요청으로 제한되고, 좀 더 정확하게, 이전 요청의 100ms 안에 /login/ URL 에 대한 요청을 할 수 없다.

버스트 핸들링

위 예제에서, 서로 100ms 이내에 2개의 요청을 받으면 어떻게 되나? 두번째 요청에 대해 NGINX 는 클라이언트에 503 상태 코드를 리턴 한다. 아마도 이것은 우리가 원하는게 아닐 수도 있는데, 애플리케이션은 실제로는 버스티(bursty, 폭발적인) 경향이 있다. 대신 우리는 초과 요청을 버퍼하길 원하고 적시에 서비스를 원한다. 여기서 업데이트 된 구성에서와 같이 limit_req burst 파라메터를 사용 하다.

burst 파라메터는 얼마나 많은 요청을 존에서 지정한 속도를 초과해 클라이언트가 만들 수 있는지를 정의한다. (위 예제 mylimit 존에서, 속도 제한은 초당 10 요청 혹은 100ms 당 1개 다) 이전요청 이후에 100ms 보다 조금 빠르게 도착한 요청은 쿠에 넣는데 여기서 우리는 큐 크기를 20으로 지정했다.

만약 21 요청이 주어진 IP 주소로 동시에 도착한다면, NGINX 은 첫번째를 즉각 upstream 서버 그룹에 포워드하고 나머지는 20개는 대기열에 넣는다. 그런 다음 100ms 마다 큐된 요청을 포워드하고 들어오는 요청이 큐된 요청 개수가 20개가 넘어가게 될때에만 클라이언트에 503 을 리턴 한다.

No Delay 를 가지는 큐

burst 를 가지는 설정은 트래픽 흐름을 부드럽게 만들지만, 사이트가 느려져 보일 수 있기 때문에 그렇게 실용적이 않다. 우리의 예제에서, 큐에 20번째 패킷은 포워드되기 위해 2초를 기다리는데 이 시점에서 이에 대한 응답은 클라이언트에게 더 이상 유용하지 않을 수 있다. 이 상황을 해결하기 위해서는 burst 파라메터와 함께 nodelay 파라메터를 추가해야 한다.

nodelay 파라메터를 사용하면, NGINX 는 여전히 burst 파라메터에 따라 큐에 슬랏을 할당하고 설정된 속도 제한 부여하지만, 큐된 요청의 포워딩 간격을 두지 않는다. 대신, 요청이 아주 순간에 들어오면, NGINX 는 큐에 슬롯이 활용할 수 있는 한 즉시 포워드 된다. 이것은 “taken” 으로 슬롯을 표시하고(mark) 적절한 시간이 경과 할 때까지 다른 요청에 의해서 사용하도록 해제하지 않는다. (위 예제에서, 100ms 지난후)

이전과 마찬가지로, 20 슬롯 큐가 비어있고 21 요청이 주어진 IP 주소로부터 동시에 들어온다고 가정해 보자. NGINX 는 모든 21번째 요청을 즉각 포워드 하고 큐에 20 번 슬롯을 “taken” 으로 표시하고 나면 100ms 마다 1개 슬롯을 해제하게 된다. (만약 25개의 요청이 있다면, NGINX 는 그들중에 21번째를 즉각 포워드 하고 20번 슬롯을 “taken” 으로 표시하고 나머지 4개의 요청은 503 상태로 거절한다.)

이제 첫번째 요청 세트가 포워드된 이후 101ms 에 또 다른 20개의 요청이 동시에 도착한다고 생각해보자. 큐에서 오직 1 슬롯만이 해제된 상태다. 그래서 NGINX 는 1개 요청을 포워드 하고 다른 19개의 요청은 503 상태로 거절 한다. 대신 20개의 새로운 요청 전에 501ms 가 지났다면 5 개의 슬롯이 해제 된 상태이고 NGINX 는 즉각 5개의 요청을 포워드 하고 15개를 거절 한다.

이런 효과는 초당 10개의 속도 제한과 동일하다. nodelay 옵션은 요청들 사이에 허용되는 시간 간격을 제한하지 않고 속도 제한을 적용할경우에 유용하다.

Note: 대부분, 우리는 limit_req 지시문에 burst nodelay 파라메터를 포함하길 권장한다.

두단계 속도 제한

NGINX Plus R17 이나 NGINX 오픈 소스 1.15.7 에서, 전형적인 웹 브라우저 요청 패턴을 수용하기 위해 요청 버스트를 허용하도록 NGINX 를 설정할 수 있고, 추가적인 과도한 요청을 최대한 지점까지 제한하며 그 이상으로 추가적인 과도한 요청은 거부 된다. 두 단계 속도 제한은 limit_req 지시문에 delay 파라메터로 활성화 된다.

두 단계 속도 제한을 설명하기 위해, 여기서는 초당 5개 요청으로 속도를 제한함으로써 웹 사이트를 보호하도록 NGINX 를 설정한다. 웹사이트는 일반적으로 한 페이지당 4-6 리소스를 가지며 12 리소를 넘지 않는다. 이 설정은 최대 12 요청을 허용 하며 첫 8 요청은 지연(delay) 없이 처리 된다. 지연(delay) 는 5 r/s 한도를 적용하기 위해 8개 과도한 요청 이후에 추가 된다. 12개 과도한 요청 이후에, 모든 추가된 요청은 거부된다.

delay 파라메터는 정의된 속도 제한을 준수하기 위해 버스트 크기 내에서 과도한 요청을 조절(delayed) 하는 지점을 정의한다. 이 구성을 사용하면, 8r/s 에서 지속적인 요청 스트림을 만드는 클라이언트는 다음과 같은 동작을 경험하게 된다.

Illustration of rate‑limiting behavior with rate=5r/s burst=12 delay=8

첫 8 요청은 (delay 값) delay 없이 NGINX Plus 에 의해서 프록시 된다. 그 다음 4개 요청은 (burst – delay) 정의된 5 r/s 속도를 넘지 않도록 지연(delay) 된다. 그 다음 3개 요청은 거부되는데, 전체 버스트 크기를 넘어섰기 때문이다. 후속 요청은 지연된다.

고급 구성 예제

NGINX 의 다른 기능과 함께 기본적인 속도 제한 설정과 조합해, 아주 미묘하게 트래픽을 제한을 구현 할 수 있다.

Allowlisting

이 예제는 “allowlist” 에 없는 모든 요청에 대한 속도 제한을 어떻게 하는 보여준다. (역, allowlist 에 있는 IP 는 속도 제한을 하지 않는다.)

이 예제는 geo map 지시문을 사용해 구성했다. geo 블럭은 allowlist 에 IP 주소에 대해서 $limit 변수에 0의 값을 할당했고 다른 모든 것에는 1 의 값을 할당 했다. 그리고 나서 우리는 그러한 값을 키(key) 로 바꾸기 위해서 map 사용하는데, 그것은:

  • 만약 $limit0 이면, $limit_key 는 빈 문자열(empty string) 이 설정 된다.
  • 만약 $limit 1 이면, $limit_key 는 클라이언트의 IP 주소를 바이너리 포맷으로 설정 된다.

이 두가지를 조합해보면, $limit_key 는 허용된 IP 주소에 대해서는 빈 문자열로 설정되고, 그렇지 않으면 클라이언트 IP 주소가 설정 된다. limit_req_zone 지시문에 첫번째 파라메터가 빈 문자열이면, 제한이 적용되지 않는데, 허용된 IP 주소들 (10.0.0.0/8 과 192.168.0.0/24 서브넷) 은 제한이 걸리지 않는다. (역, 10.0.0.0/8 과 192.168.0.0/24 값은 0 이다) 다른 모든 IP 주소들은 초당 5 요청으로 제한이 걸린다.

limit_req 지시문은 제한을 / location 에 적용하고 지연 없는 포워딩으로 설정된 제한을 초과하여 최대 10패킷이 허용된다.

location 에 다중 limit_req 지시문 포함하기

하나의 location 에 다중 limit_req 지시문을 포함할 수 있다. 주어진 요청과 매칭되는 모든 제한은 적용되는데, meaing the most restrictive one is used.(가장 제한적인 것이 사용된다는 뜻이다.). 예를들어, 하나 이상의 지시문이 지연을 부과하는 경우 가장 긴 지연이 사용된다. 비슷하게, 설사 다른 지시분이 그것을 허용한다고 하더라도 어떤 지시문에 효과가 있다면 요청들은 거부 된다.

이전 예제를 확장해, 우리는 허용목록에 IP 주소들에 속도 제한을 적용할 수 있다.

허용된 목록에 IP 주소들은 첫번째 속도 제한(req_zone) 에 걸리지 않지만 두번째(req_zone_wl) 에 걸리며 초당 15 요청으로 제한된다. 허용목록에 없는 IP 주소드른 양쪽 모두 속도 제한에 걸리는데, 훨씬 제한적인 설정인 초당 5 요청이 적용 된다.

연관 기능 설정하기

Logging

기본적으로, NGINX 는 속도 제한으로 지연되거나 드랍된 요청을 기록한다. 다음과 같다.

로그 엔트리에 포함된 필드는 다음과 같다.

  • 2015/06/13 04:20:00 – 로그 엔트리에 기록된 날짜와 시간
  • [error] – 심각 수준
  • 120315#0 – NGINX 워커의 프로세스 ID 와 쓰레드 ID 인데 # 로 구분 된다.
  • *32086 – 속도가 제한된 프록시된 연결 ID
  • limiting requests – 로그 엔트리 기록이 속도 제한(rate limit) 라는 지시자
  • excess –
  • zone – 부과 된 속도 제한을 정의한 zone
  • client – 요청을 생성한 클라이언 IP 주소
  • server – 서버의 IP 주소 혹은 호스트이름
  • request – 클라이언트 의해서 생성한 실제 HTTP 요청
  • host – HTTP 헤더의 Host 값

기본적으로, 위 예제에서 [error] 를 본것처럼 NGINX 는 error 수준에서 거부된 요청들이 기록된다. (지연된 요청들은 한단계 낮은 수준으로, 기본적으로 warn, 기록된다. 로깅 수준을 바꾸기 위해, limit_req_log_level 지시문을 사용해라. 여기서, 우리는 거부된 요청은 warn 수준에서 기록되도록 지정했다.

클라이언트에 Error 코드 전송하기

기본적으로 NGINX 는 클라이언트가 속도 제한을 초과했을때에 503 (Service Temporarily Unavailable) 상태 코드를 응답한다. 다른 상태 코드를 지정하고 싶다면 limit_req_status 지시문을 사용해라.

특정 Location 에 모든 요청 거부하기

만약 특정 URL 에 대한 모든 요청들을 거부하기 원한다면, 단지 제한을 하는 말고, deny all 지시문을 포함한 location 블럭을 설정한다.

결론

우리는 HTTP 요청에 대해 서로 다른 location 에 요청 속도를 지정하고 burst와 nodelay 파라메터와 같은 속도 제한에 대한 추가적인 기능 설정등의 NGINX 와 NGINX Plus 가 제공하는 속도 제한에 많은 기능을 알아봤다. 우리는 또한 거부된 요청과 지연된 요청을 어떻게 기록하는지 설명했고, 허용되거나 거부된 클라이언트 IP 주소들에 대해 서로 다른 제한을 적용하는 등의 고급 설정에 대해서도 알아 봤다.

systemd unit 편집기 바꾸기

systemd 는 이제 리눅스 시스템의 뼈대가 되는 기본운영 방법이 되었다. 기존에는 System V Init 이였지만 RHEL 7, Ubuntu 16.04부터 기본 시스템운영 프로그램이 되었다.

systemd 는 ‘ctl’ 로 끝나는 명령어들의 집합으로 제어가 가능하다. systemctl, journalctl, timedatectl, hostnamectl, loginctl 이 대표적이다. systemctl 의 경우에는 systemd unit 파일들에 대한 제어와 설정이 가능하다. systemd unit 파일은 기존의 Systemv V init Script 를 대체하는 것으로 일종의 시스템 데몬 프로그램들이라고 보면 된다. 시스템이 시작될때에 자동으로 시작되게 한다거나 종료하게 한다거나 하는것들을 가능하게 한다.

unit 파일은 텍스트 파일이기 때문에 언제든지 파일을 열어서 편한대로 편집이 가능한데, systemctl 명령어는 이런 unit 파일에 대한 편집기능을 제공 한다. unit 파일이 있는 곳으로 가서 텍스트 편집기를 열 필요가 없이 systemctl edit –full 명령어를 이용하면 가능하다.

문제는 systemctl edit — full 명령어를 입력했을 때에 실행되는 에디터가 nano 로 열리는 경우가 많은데, 이것을 바꿀 수 있다.

다음의 내용은 다음의 링크 내용을 정리한 것이다.

SYSTEMD_EDITOR 환경변수 설정

제일 쉬운 방법은 SYSTEMD_EDITOR 환경변수 설정이다. 대부분 Bash 를 사용하기 때문에 이것을 다음과 같이 쉘 환경변수로 설정 해준다.

매번 로그인 할때마다 입력하기 귀찮으면 ~/.bashrc 파일에 추가해주면 로그인할때마다 자동 적용된다.

만일 일반계정으로 로그인을 하고 sudo systemctl edit –full 명령어를 이용한다면 /etc/sudoers 파일에 다음을 추가해 줘야 한다.

sudo 를 실행하는 계정에 있는 환경 변수인 SYSTEMD_EDITOR 를 유지하라는 뜻이다.

update-alternatives 로 기본 에디터 변경

update-alternatives 는 alternative 가 가능한 여러 명령어들을 바꿔 주는 기능을 한다. 이것은 매우 유용한데, 예를들어 Python3 관련 버전이 여려개일 경우에 python3 에 기본 버전을 시스템적으로 지정해 줄 수 있다. update-alternatives –list 명령어를 입력하면 현재 등록된 대체가능한 명령어들이 보인다.

리눅스에서 편집기는 editor 라는 명령어로 되어 있고, 정확하게는 심볼릭 링크다, 이것을 update-alternatives 명령어로 바꿔주면 된다.

위에 내용을 보면 기본 에디터로 nano 가 설정되었다고 나온다. 이것을 바꿔주면 시스템적으로 기본 에디터가 변경되게 된다.

EDITOR 환경변수 지정

실행할때에마다 EDITOR 환경변수를 다음과 같이 지정해주면 된다.

Yum 패키지 충돌 발생시 쓸 수 있는 명령어

최근에 CentOS 8 에서 Kubernetes 를 테스트하던 중에 패키지 업데이트가 되지 않는 일이 발생 했다. 아직 Kubernetes 는 CentOS 8 배포판을 정식으로 지원하지 않아 CentOS 7 배포판의 패키지를 사용해야 하는 상황이다.

그런데, yum 명령어로 업데이트를 할려고 보니 오류가 발생 했다. 이럴 경우에 다음과 같은 명령어를 사용해서 의존성을 체크해 볼 수 있다.

위와같은 명령어를 이용하면 패키지 의존성에 대한 내용을 풀어서 볼 수 있다.

참고: kubeadm and kubelet 1.15 fail to install on centos 7 after patches released today#92242

Generic WebHook Trigger 설정

Jenkins 에서 Github 나 GitLab 와 연동하기 위해서 Generic WebHook Trigger 플러그인을 많이 사용한다. 검색을 해보면 사용법이 아주 많이 나오는데, 특정 브랜치(Branch) 에만 작동되게 하기 위해서 Execute Shell 를 활용하는 사례를 볼 수 있다.

하지만 Generic WebHook Trigger 플러그인 설정에서 그냥 특정 브랜치만 반응하도록 할 수 있다.

Post content parameters in Generic WebHook Trigger
Post content parameters in Generic WebHook Trigger

제일 먼저 Post content parameters 에서 Variable 에 “ref”, Expression 에는 “$.ref” 를 적어주고 JSONPath 를 선택해 준다.

이것은 Github나 GitLab 가 jenkins 를 호출할때에 JSON 포맷으로 관련 데이터를 넘겨주게 된다. JSON 포맷이기 때문에 이 포맷에서 특정 값을 가지고 오기 위해 정규표현식을 사용할 수 있는데, “$.ref” 는 “refs/heads/master” 식의 값을 가지고 오게 된다. 그리고 이러한 값은 이 플러그인에서 $ref 라는 변수에 할당되게 된다.

대부분 이렇게 설정을 한 후에 Execute Shell 를 사용하는데, 그럴 필요가 없이 추가적인 설정을 다음과 같이 하면 된다.

Optional filter in Generic WebHook Trigger
Optional filter in Generic WebHook Trigger

Generic WebHook Trigger 플러그인 설정에서 좀 더 아래로 내려보면 “Optional filter” 이 있는데 여기에 Expression 에 브랜치를 “refs/heads/master” 라고 적어준다. 그리고 Text 에는 앞에서 설정한 변수명인 $ref 를 적어준다.

이렇게 하면 master 브랜치만을 체크해 이 플러그인이 작동되게 된다. 다른 브랜치에만 반응하도록 하기 위해서는 “refs/heads/[브랜치 이름]” 으로 적어 놓으면 된다.

굳이 Execute Shell 을 이용하지 않아도 된다.

letsencrypt 인증서 발급/갱신

letencrypt 는 무료로 발급 받을 수 있는 도메인 인증서이다. 도메인 인증서는 서버와 클라이언트간에 HTTP 통신을 암호화하는데 필요한 것이다. 원래는 돈을 주고 구매해야 하지만 letsencrypt 는 무료로 사용할 수 있게 해준다.

대부분의 발급 절차를 서버의 CLI 를 통해서 이루어진다. 따라서 서버가 있어야 하며 터미널 접속이 가능해야 한다. 또, Python 을 필요로 한다. 인증서를 발급 받기위해서 프로그램을 사용하는데 이것이 Python 을 필요로 한다.

certbot 설치

certbot 은 letsencrypt 인증서를 발급받기 위한 CLI 명령어 세트다. 다음과 같이 다운로드 할 수 있다.

복제된 디렉토리에는 letsencrypt 인증서를 위한 모든 내용이 포함되어 있다.

주도메인, 멀티도메인

발급 받기전에 한가지 생각해봐야 할게 있다. 인증서는 주도메인 인증서와 멀티도메인 인증서로 크게 나뉜다. 예를들면 다음과 같다.

  • systemv.pe.kr – 주도메인 인증서
  • *.systemv.pe.kr – 멀티도메인 인증서

많은 사람들이 실수하는 것이 멀티도메인 인증서를 발급받고 systemv.pe.kr 도메인으로 접속할려고 한다는 것이다. 멀티도메인 인증서의 *. 이것이 주도메인을 포함하지 않는다. 따라서 반드시 따로 도메인 인증서를 발급 받아야 한다.

수동 도메인 인증서 발급

도메인 인증서를 발급 받를때에 해줘야 하는 거이 Validation 이다. 이것이 실제로 인증서를 사용 가능한 발급요청인지를 체크한다. 이 체크를 위한 방법은 두가지가 있다.

  1. DNS TXT 레코드를 이용.
  2. HTTP 를 이용한 특정 디렉토리에 파일 접근.

멀티 도메인 인증서를 발급 받을때는 DNS TXT 레코드를 이용하는 방법이 좋다. 주도메인(단일도메인) 을 발급 받을때는 HTTP 를 이용한 파일 접근으로 유요한 요청인지를 인증하면 된다.

발급을 위해서 시스템의 슈퍼유저 계정으로 실행 한다.

위와같이 특정 디렉토리에 외부에서 접근 가능한 파일을 작성해 위에서 출력한 데이터를 작성하고 저장한다. 이렇게 한 후에 진행을 하면 Letsencrypt 에서 파일에 접근해 유요한 요청인지를 확인하고 인증서를 발급해 준다.

멀티도메인처럼 하나의 인증서로 여러 도메인을 인증하기 위해선 DNS TXT 레코드 인증을 이용하는 것이 편하다.

위와같이 하면 화면에 TXT 레코드를 입력하라는 메시지가 나온다. 그것을 다음과 같이 DNS 에 입력해 준다.

_acme-challenge.systemv.pe.kr 도메인으로 하는 TXT 를 입력해 주는 것이다. 그리고 반드시 DNS 서버를 재시작해 적용해 준다.

정상적으로 발급이 되었다면 /etc/letsencrypt/live 디렉토리에 도메인으로 디렉토리가 생성되고 인증서가 발급된다.

2022-02 내용추가

Lets Encrypt 관련해 내용이 변경되었다. 인증서를 적용하기 위한 절차는 다음과 같다.

letsencrypt 업데이트

git 로 소스를 복제했다면 시간이 지남에 따라 최신 소스가 달라진다. 다음과 같이 최신판으로 업데이트를 해준다.

한번에 멀티 도메인 인증서 발급

나는 DNS 서버를 별도로 운영하고 있다. 따라서 DNS TXT 필드를 이용해서 인증서 설정이 가능하다. 다음과 같이 하면 된다.

대상 도메인에 대해서, 위 경우에는 두개(systemv.pe.kr, *.systemv.pe.kr), DNS TXT 를 발급해 준다. 그러면 그것을 zone 파일에서 DNS TXT 에 적용해주고 DNS 서버를 재시작 해준다.

그리고 letsencrypt 의 Verify 를 해주면 적용 된다.

2023.01 변경사항

이제는 letencrypt-auto 스크립트도 더 이상 이용할 수 없다.

위와같이 메시지를 내면서 실행되지 않는다. 검색을 해보면 snapd 를 설치해서 실행하는 방법을 소개하고 있지만, snapd 를 설치한다고 하더라도 letencrypt-auto 스크립트를 사용하는 것은 아니다.

letencrypt-auto 대신에 certbot 명령어를 이용하면 된다. 이 명령어를 이용하기 위해서는 Python 을 이용해서 설치를 해줘야 하는데 letencrypt 를 git 클론하면 들어있다. 설치하고 실행을 하면 의존성 패키지가 없다는 메시지가 나오는데 함께 설치해주면 된다. 20.04 LTS, Python 3.8 에서 정상적으로 동작했다.

자동갱신 스크립트를 이용해서 3개월에 한번 자동으로 갱신되도록 할 수 있지만, 개인적으로 갱신 알람 메일이 오고 그것을 확인하고 수동으로 하는 방법을 선호하는데, 자동갱신을 하게 되면 이래저래 관련 명령어를 까먹게 되어서 자동갱신을 하진 않았다.

VIM, Yaml 문법 적용

이 문서는 VIM, Yaml 문법 적용에 관한 것이다.

YAML 은 각종 설정파일에서 자주 쓰인다. Kubernetes 에서는 manifest 파일로 쓰이고 있는데, VIM 을 이용해 Yaml 을 편집할때에 간단하게 사용할 수 있는 방법을 소개한다.

간단하게 .vimrc 파일에 다음과 같이 입력해주면 된다.

내용을 보면 금방 이해가 될 것이다.

virsh 를 통해 Ubuntu 20.04 에 console 로 접속하는 방법

KVM 가상화 시스템에서 virsh 를 통해 Ubuntu Guest OS에 Console 로 접속하는 방법은 다양한데 대부분 grub 부팅 옵션을 손보는 것이 였다. 하지만 Ubuntu 20.04 로 넘어오면서 이 방법이 훨씬 간단해 졌다.

먼저 Ubuntu 20.04 Guest 에 접속한 후에 다음과 같이 입력 하면 끝난다.

이렇게 한 후에 KVM 시스템에서 console 접속을 하면 접속이 잘된다.

이 방법은 18.04 에서도 가능하다.

VSCode 폰트 변경하기

VSCode 폰트(font) 변경하기에 대해서 알아본다. 환경도 윈도우즈가 아닌 리눅스(Linux) 에서 VSCode 폰트 변경이다. 리눅스 환경에서 폰트변경은 뭐든 쉬운 일이 아니다.

폰트(font) 알기 – fc-list

리눅스에서 폰트는 fc-list 명령어를 통해서 알 수 있다.

결과를 보면 다음과 같은 정보를 보여준다.

  1. 설치된 폰트 파일(전체 경로 포함)
  2. 폰트 이름.
  3. 스타일. 스타일은 Regular, Bold, Italic 등이다.

옵션없이 실행하자 설치된 모든 폰트들을 보여준다. 이 명령어에는 필터 기능을 제공한다.

‘:’ 를 기준으로 필터를 줄 수 있다. 필터는 ‘:’ 를 기준으로 연달아 적어주면 되는데 위의 예제는 언어가 ko 인 것만을 보여주도록 옵션을 줬다. 하지만 결과를 보면 중국어, 홍콩, 일본등도 함께 출련된다. 이것은 CJK 폰트의 특성이다. CJK 는 중국어,일본어,한국어만을 따로 모아 놓은 폰트를 말한다.

다음과 같은 필터를 사용할 수 있다.

  1. fc-list : family
  2. fc-list : lang=ko family
  3. fc-list : family style
  4. fc-list –format=”%{family[0]}\n” | sort | uniq

위 보기에서 2번째 명령어를 통해서 한글을 지원하는 폰트를 알아낸다. 나는 “Noto Sans Mono CJK KR” 를 선택했다.

VSCode 폰트 변경

리눅스용 VSCode 는 설정을 열기위한 단축키를 제공하는데, Shift + Ctl + P 를 누르면 된다. 여기서 ‘설정열기(JSON)’ 선택해 자신만의 설정을 커스터마이징 할 수 있다. 폰트 변경은 다음과 같이 했다.

폰트 이름에 공백(Space) 가 들어간 경우에 홑따옴표(‘) 로 감싸준다. 새로운 폰트 이름을 적자마자 바로 적용된다.

Oracle Linux 8 UEK 커널 설치

Oracle Linux 는 UEK(Unbreakable Enterprise Kernel) 라고 해서 커널을 제공 한다. Oracle 은 이를통해 최신의 커널을 제공하고 자신들만의 퍼포먼스 패치를 더해서 고성능을 낼수 있도록 했다. Oracle Linux 8 에서 UEK 커널을 설치해 보자.

Yum Repository 확인

Oracle Linux 8 에는 uek 를 위한 yum repository 가 추가되어 있다. 다음과 같이 확인이 가능하다.

‘ol8_UEKR6’ 가 uek 를 위한 저장소(repository) 이다. 이제 다음과 같이 어떤 버전의 uek 커널이 있는지 다음과 같이 체크해보자.

현재 시점에서 5.4 버전의 uek 커널이 있음을 알 수 있다.

시스템 커널 유지 개수

yum 은 자동으로 패키지를 설치해주고 더 이상 필요없는 패키지는 삭제해주며, 의존성도 함께 해결해준다. 커널의 경우에는 버전마다 설치가 되는데 이렇게 되면 아주 많은 커널이 설치가되어서 부팅시 많은 커널들이 보이게 된다.

이런문제를 해소하기 위해서 yum 은 같은 패키지의 경우에 다양한 버전에 한해서 몇개까지 유지할지 개수를 제한하는데 이것이 ‘installonly_limit’ 이다. 이는 다음과 같이 /etc/yum.conf 파일에 저장된다.

초기값은 3 인데, uek 를 설치하게되면 기본 커널도 삭제될 가능성도 있기 때문에 이것을 5로 교체해준다.

설치

설치는 yum 명령어를 이용해 간단히 다음과 같이 설치 할 수 있다.

자동으로 uek 의 최신 버전을 다운로드 받아 설치해 준다. 재부팅을하면 uek 커널로 올라올 것이다.

Grafana admin password reset

Grafana 는 Time series 데이터베이스에 내용을 그래프로 그려주는 유명한 웹 프로그램이다. 아주 유용한 프로그램으로 인기가 높다.

그런데, 이것을 사용하다가 admin 패스워드를 잊어버렸다면 어떻게 해야할까? 공식 메뉴얼에는 다음과 같이 하라고 나와 있다.

하지만 이렇게 해도 되지 않는다. 이럴때는 다음과 같이 하면 된다.

위 내용은 admin 계정의 패스워드를 ‘admin’ 으로 초기화 시키는 것이다. Grafana 에 접속해 초기화 패스워드를 입력하면 새로운 패스워드를 지정하라는 프로세스를 타게 된다.