cloudwatch log 매트릭 경보 생성 – log monitoring

오늘의 주제는 인스턴스에서 발생하는 로그를 cloudwatch 로 전송하여 사용하는 법을 포스팅 할거다.

먼저 역할에 정책부터 생성해 보자. 사용하는 정책은 아래와 같다.

{
“Version”: “2012-10-17”,
“Statement”: [
{
“Effect”: “Allow”,
“Action”: [
“logs:CreateLogGroup”,
“logs:CreateLogStream”,
“logs:PutLogEvents”,
“logs:DescribeLogStreams”
],
“Resource”: [
“arn:aws:logs:*:*:*”
]
}
]
}

역할을 인스턴스에 부여하고 인스턴스 내부에서 패키지를 설치해야 한다.

나는 이미 이전에 테스트로 설치해 뒀다.

설치로그이다.

Nov 18 17:17:19 Installed: aws-cli-plugin-cloudwatch-logs-1.4.4-1.amzn2.0.1.noarch
Nov 18 17:17:20 Installed: awslogs-1.1.4-3.amzn2.noarch

실제 설치방법은 yum install 이나 wget 으로 받아 실행하는 방법이 있다.

# yum install awslogs -y

or

# curl https://s3.amazonaws.com/aws-cloudwatch/downloads/latest/awslogs-agent-setup.py -O
# python ./awslogs-agent-setup.py –region ap-northeast-2

리전지정 옵션을 넣어주는게 좋다 그렇지 않으면 따로 지정해야 한다.

# vi /etc/awslogs/awscli.conf
[plugins]
cwlogs = cwlogs
[default]
region = ap-northeast-2

그리고 cloudwatch 로 전송할 로그를 지정한다.

# vi /etc/awslogs/awslogs.conf
[/var/log/messages]
datetime_format = %b %d %H:%M:%S
file = /var/log/messages
buffer_duration = 5000
log_stream_name = test
initial_position = end_of_file
log_group_name = linuxer-blog-WG

테스트를 위해 /var/log/messages 를 cloudwatch 로 전송하는 로그이다.

log_stream_name = test
initial_position = end_of_file
log_group_name = linuxer-blog-WG

세개의 옵션이 중요하다. end_of_file 은 뒤부터 추가되는 로그를 watch 로 전송한다.

amazon linux 2 는 systemctl 명령어로 서비스를 시작한다

# systemctl restart awslogsd

설정대로 로그가 올라 오는게 보인다.

중요한 부분은 이벤트 만료시점을 지정해서 로그로 전송된 용량이 과하게 쌓이지 않도록 해야한다.

로그 그룹을 체크하면 지표 필터 생성 버튼이 활성화 되고 지표를 생성한다.

지표는 대충 만들어 볼까한다.

HealthCheck 라는 이름으로 패턴을 설정했다. 보면 샘플로그에서 일치하는 패턴이 보인다. 그리고 지표를 할당한다.

지표생성은 커스텀 매트릭으로 비용이 발생할수 있으니 조심하도록 하자.

생성된 지표를 확인하면 위와같다. 그럼 지표를 확인해보자.

커스텀메트릭이 정상적으로 만들어진걸 확인할수 있다.

그래프도 잘생성 됬는지 보면 잘 올라오는게 보인다. 그럼 실제 로그가 발생해서 그래프가 생성됬는지 확인해보자.

로그가 올라와서 매트릭이 생성된것을 확인할수 있다. 그럼이제 경보를 생성해 보자.

뭔가 훅지나간거 같겠지만 빠진부분은 sns 설정 뿐이다. SNS는 주제를 만들고 구독을 생성하고 구독으로 watch 에서 sns를 추가하면 된다.

경보생성하는 방법은 따로 자세하게 설명하겠다. 블로깅이 시리즈 물이 될 기미가 보인다.

그래프처럼 임계치를 지나서 경보상태로 변경됬다가 정상으로 업데이트가 되는 과정이 보인다 정상적으로 지표로 경보가 작동하는것 까지 확인 되었다.

오늘의 목표인 로그전송으로 지표생성 후 경보 생성까지 완료되었다.

이케이스는 tomcat log로 지표를 생성하거나 어플리케이션에서 에러가 발생한 로그 경보를 생성시키는 등으로 사용할 수 있다.

자세하게 만들고 싶었는데 흐름만 구성한거 같아 좀 찜찜한 부분은 차차 보강하겠다.

읽어주셔 감사하다!

서울-도쿄 리전간 레이턴시 줄이기-실패경험담

페이스북 AKUG에서 다음과 같은 포스팅을 봤다.

https://aws.amazon.com/ko/about-aws/whats-new/2019/10/aws-global-accelerator-supports-ec2-instance-endpoints/?fbclid=IwAR2spSZzdtmHMDVqYwEpZS8W5pEs86t7SMNArZ2fyT81M55QDoDA1dqKuy4

처음엔 아무생각이 없었으나 급 아이디어가 떠올랐다.

EC2 엔드포인트를 지원하면 리전간의 레이턴시를 줄일수 있지 않을까? 그러니까..궁금증은 오픈카톡에서 시작된거였다.

한국과 도쿄리전 간의 레이턴시를 20ms 로 줄일수 있는지가 관건이었다.

AWS Global Accelerator는 TCP/UDP를 지원한다. 그렇다면 OPENVPN을 TCP로 셋팅해서 인스턴스의 앞단에 AWS Global Accelerator 둔다면 과연 빨라질까?

그런 궁금증이었다.

엣지로케이션을 이용하여 라우팅 최적화라고 생각하면 가장 간단하다.

테스트 방식은 총4가지였다

openvpn-도쿄리전(인스턴스) -프라이빗 IP 22 port tcping

openvpn-가속기-도쿄리전(인스턴스) -프라이빗 IP 22 port tcping

openvpn-한국리전(인스턴스)-vpc 피어링-도쿄리전- 프라이빗 IP 22 port tcping

openvpn-가속기- 한국리전(인스턴스)-vpc 피어링-도쿄리전- 프라이빗 IP 22 port tcping

AWS Global Accelerator 셋팅은 아주 간단하다.

Accelerator 를 생성하고 Listeners ID 를 생성할떄 region 을 지정하고 Endpoint groups 을 인스턴스 ID로 설정하면 status 를 업데이트 한다. ALL healthy 로 보이면 정상적으로 연결된것이다.

생성된 Accelerator 은 총3개의 endpoint 를 가진다. IP 두개와 DNS 하나이다.

그럼 테스트로 넘어간다.

가속기를 쓰지않고 도쿄리전의 인스턴스에 openvpn 으로 연결하여 프라이빗 IP로 22번 포트로 tcping 을 테스트 하였다. 총 100회의 tcping 의 time 을 확인할 계획이다.

172.31.26.253에 대한 Ping 통계:
패킷: 보냄 = 10, 받음 = 10, 손실 = 0 (0% 손실),
왕복 시간(밀리초):
최소 = 34ms, 최대 = 35ms, 평균 = 34ms

C:>tcping.exe -n 100 172.31.26.253 22

Ping statistics for 172.31.26.253:22
100 probes sent.
100 successful, 0 failed. (0.00% fail)
Approximate trip times in milli-seconds:
Minimum = 43.180ms, Maximum = 81.995ms, Average = 64.100ms

가속기를 사용하지 않은 값으로 icmp 34ms / tcping 64ms 가 나온다.

172.31.26.253에 대한 Ping 통계:
패킷: 보냄 = 10, 받음 = 10, 손실 = 0 (0% 손실),
왕복 시간(밀리초):
최소 = 34ms, 최대 = 35ms, 평균 = 34ms

Ping statistics for 172.31.26.253:22
100 probes sent.
100 successful, 0 failed. (0.00% fail)
Approximate trip times in milli-seconds:
Minimum = 43.065ms, Maximum = 78.722ms, Average = 61.323ms

평균 icmp 34ms / tcping 61ms 정도 확인할수 있었다.

tcping은 속도가 늘어지는 감이 있어서 ping 까지 체크해 보았다.

ping 로는 유효한 내용을 확인할수 없었다. openvpn 으로 접속하여 1194포트로 ping 를 확인하므로 실제 전송은 tcp로 이루어진다.

구성에 대해서 간략하게 설명하고 다음테스트를 진행하려고한다.

피어링은 신청하고 수락하는 단계를 거쳐서 허용된다.

피어링으로 끝이 아니라 두개의 VPC에서 라우팅을 설정해줘야 한다.

현재 서울 172.29.0.0/24 -> pcx 도쿄 172.31.0.0/20 -> pcx 로 라우팅 테이블을 설정 하였다. 테스트는 인스턴스 내부에서 ping 으로 확인하면된다.

사실 이때쯤 테스트가 잘못된것을 알았다.

— 172.29.0.110 ping statistics —
22 packets transmitted, 22 received, 0% packet loss, time 21036ms
rtt min/avg/max/mdev = 33.540/33.606/33.679/0.244 ms

vpc 피어링으로 묶은 속도의 평균이 33.5ms 였다.

망내 속도는 두 리전간의 피어링이 제일 빠를거라 생각했기 때문이다.
그래도 포기하지 않고 유효한 데이터를 쌓기위해 테스트를 진행했다.

이즈음 site to site vpn 셋팅이 가물가물 기억이 안나서 좀 이것저것 봤다.

다음 테스트구성은 서울리전 인스턴스에 openvpn으로 연결하고 vpc peering 으로 도쿄 리전과 연결한다. 그리고 ping / tcping 22 번 테스트를 한다.

172.29.0.110에 대한 Ping 통계:
패킷: 보냄 = 10, 받음 = 10, 손실 = 0 (0% 손실),
왕복 시간(밀리초):
최소 = 39ms, 최대 = 40ms, 평균 = 39ms

Ping statistics for 172.29.0.110:22
100 probes sent.
100 successful, 0 failed. (0.00% fail)
Approximate trip times in milli-seconds:
Minimum = 45.206ms, Maximum = 79.891ms, Average = 60.589ms

Accelerator 를 사용하지 않은 결과로 icmp 39 / tcping 22 60ms 이다.
ICMP는 늘어지는데 TCP는 빨라지는 결과가 나왔다. 뭐지..

그래서 한번더 했다.

Ping statistics for 172.29.0.110:22
100 probes sent.
100 successful, 0 failed. (0.00% fail)
Approximate trip times in milli-seconds:
Minimum = 46.106ms, Maximum = 85.099ms, Average = 64.571ms

늘어지네… 39/ 60 / 64

172.29.0.110에 대한 Ping 통계:
패킷: 보냄 = 10, 받음 = 10, 손실 = 0 (0% 손실),
왕복 시간(밀리초):
최소 = 40ms, 최대 = 41ms, 평균 = 40ms

Ping statistics for 172.29.0.110:22
100 probes sent.
100 successful, 0 failed. (0.00% fail)
Approximate trip times in milli-seconds:
Minimum = 46.406ms, Maximum = 78.911ms, Average = 65.489ms

Ping statistics for 172.29.0.110:22
100 probes sent.
100 successful, 0 failed. (0.00% fail)
Approximate trip times in milli-seconds:
Minimum = 45.652ms, Maximum = 81.980ms, Average = 66.764ms

40 / 65 /66 시간이 지날수록 속도가 느려졌다. 왜지? Accelerator 가 가까운 거리에선 라우팅을 한번 더 들어가게 되는건 아닐까 하는 생각이 들었다.

실제론 엣지를 타게되지만 전송거리가 더 먼건 아닐까…
그런 생각이 들어서 결국 오레곤 리전에 셋팅을 했다. 이젠 근성이다.

10.0.0.227에 대한 Ping 통계:
패킷: 보냄 = 10, 받음 = 10, 손실 = 0 (0% 손실),
왕복 시간(밀리초):
최소 = 136ms, 최대 = 193ms, 평균 = 141ms

Ping statistics for 10.0.0.227:22
100 probes sent.
100 successful, 0 failed. (0.00% fail)
Approximate trip times in milli-seconds:
Minimum = 145.219ms, Maximum = 283.356ms, Average = 168.073ms

141 / 168 역시 오레곤은 멀다. 그럼 Accelerator 를 사용해 본다.

10.0.0.227에 대한 Ping 통계:
패킷: 보냄 = 10, 받음 = 10, 손실 = 0 (0% 손실),
왕복 시간(밀리초):
최소 = 126ms, 최대 = 127ms, 평균 = 126ms

Ping statistics for 10.0.0.227:22
100 probes sent.
100 successful, 0 failed. (0.00% fail)
Approximate trip times in milli-seconds:
Minimum = 132.458ms, Maximum = 224.706ms, Average = 154.244ms

126 / 154 드디어 Accelerator 를 사용했을때 유효한 결과가 보인다.

한국에서 거리가 먼~오레곤 정도 되어야..속도가 오르는게 확인이 된다.

물론 라우팅이 꼬일대로 꼬인 지역에선 Accelerator가 매우큰 도움이 될것이다.

하지만..여기서 끝내기엔 너무 아쉬웠다. 하.

또 한국리전에 최근에 적용된 기능이 생각났다.

https://aws.amazon.com/ko/about-aws/whats-new/2019/10/aws-client-vpn-now-available-seoul-canada-central-stockholm-northern-california-regions/?fbclid=IwAR3wIXq6EsYCxAV7FN05mDsmVc_mkQH1EzwVF-wUN8EpxTGB1f1zUiZ0_s8

이 테스트는 다음을 기약해야 할것같다..
ㅜㅜ실패의 충격이 크다.

하지만 얻게된 aws의 내부 망에 대한 추측이다.

서울 리전과 도쿄리전은 라우팅이 복잡해서 지연이 있는게 아니라 실제 회선이 지연이 있어서 발생하는 레이턴시다. 그래서 이 레이턴시를 줄이기 위해선 라우팅 최적화나 다른 시도가 필요한게 아니라 회선의 질적인 상향이 필요하다는게 내 결론이다.

오늘의 우승 구성은 ” openvpn-가속기-도쿄리전(인스턴스) -프라이빗 IP 22 port tcping ” 이다.

오늘은 도쿄에 테스트 했으니까 사요나라!

centos8 rdate의 행방

지금까지 rdate로 시간동기화를 강제로 맞췄다.

ntp를 써도 됬지만 centos5에서 적응한 방식이라 레거시에서 벗어날수 없었다.

ansible 테스트중에 알게됬다.

rdate 가 설치되지 않았다.

TASK [rdate] *
fatal: [13.125.94.121]: FAILED! => {“changed”: false, “failures”: [“rdate 일치하는 패키지 없음”], “msg”: “Failed to install some of the specified packages”, “rc”: 1, “results”: []}
…ignoring

centos8 은 4점대 커널이다. centos7은 3점대고.

이커널 차이에서 오는 가장 큰차이점은 ntp 가 기본이냐, chronyd가 기본이냐다.

centos8 부턴 chronyd 기본지원이므로 이전과 같이 불편하게 설정하지 않아도 될것같다.

[root@ip-172-31-45-50] ~# uname -a
Linux ip-172-31-45-50.ap-northeast-2.compute.internal 4.18.0-80.7.1.el8_0.x86_64 #1 SMP Sat Aug 3 15:14:00 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
[root@ip-172-31-45-50] ~# rpm -qa | grep chronyd
[root@ip-172-31-45-50] ~# rpm -qa | grep chrony
chrony-3.3-3.el8.x86_64

ansible role file module error

ansible 테스트중에 지속적으로 file 모듈에서 에러가 발생했다.

SSH password:

ERROR! ‘file’ is not a valid attribute for a Play
The error appears to be in ‘/etc/ansible/roles/locale.yml’: line 9, column 3, but may
be elsewhere in the file depending on the exact syntax problem.
The offending line appears to be:

file:
^ here


become: true
become_user: root
hosts: all
name: rdate
tasks: ~
file:
group: users
mode: 493
owner: tomcatadm
path: /opt/oracle
state: present
name: “create a directory for apache tomcat”

yml 형식도 ok 그런데 file 모듈에서 에러가 발생한다.
그냥 권한 바꾸는 간단한 건데 여기에서 오랫동안 막혀있었다.

# ansible all -m file -a ‘dest=/home/test state=file mode=755’ -k

SUCCESS => {
“ansible_facts”: {
“discovered_interpreter_python”: “/usr/bin/python”
},
“changed”: false,
“gid”: 1000,
“group”: “centos”,
“mode”: “0755”,
“owner”: “centos”,
“path”: “/home/test”,
“size”: 0,
“state”: “file”,
“uid”: 1000
}

file 모듈 문제일까 싶어서 ansible 명령어로 테스트 해보니 정상. 왜지?

그냥 배열 정리 잘해주니까 된다..

빡치네..


become: true
become_user: root
hosts: all
name: rdate
tasks:
– name: test
file:
mode: 766
path: /home/test
state: file

modsecurity-2.9.3 컴파일 에러

centos7 / apache 2.4.36 / mod_security 에러 발생시 해결.

https://forum.directadmin.com/showthread.php?t=56837

In file included from modsecurity.h:49:0,
from apache2_config.c:17:
msc_remote_rules.h:54:9: error: unknown type name ‘apr_crypto_key_t’
apr_crypto_key_t **apr_key,
msc_remote_rules.h:55:9: error: unknown type name ‘apr_crypto_t’
apr_crypto_t *f,
make[2]: *** [mod_security2_la-apache2_config.lo] Error 1
make[2]: Leaving directory /usr/local/src/modsecurity-2.9.3/apache2′
make[1]: *** [all] Error 2
make[1]: Leaving directory /usr/local/src/modsecurity-2.9.3/apache2′
make: *** [all-recursive] Error 1

처음에 진행한 config

#  ./configure –with-apxs=/usr/local/apache/bin/apxs

apr 관련 에러가 발생한다.

이경우엔 apache 에서 사용하는 apr 이 apr_crypto_key_t 를 지원하지 않는것이다. 라고 생각했는데 아니었다 apr이 지정안되서 그냥 안되는거였다.

#./apachectl -V
Server version: Apache/2.2.34 (Unix)
Server built: Dec 6 2018 13:55:09
Server’s Module Magic Number: 20051115:43
Server loaded: APR 1.5.2, APR-Util 1.5.4
Compiled using: APR 1.5.2, APR-Util 1.5.4

사실 그냥하면 될줄알았는데 아니더라…그래서 명시를 해준다.

# ./configure –with-apxs=/usr/local/apache/bin/apxs –with-apr=/usr/local/apache/bin/apr-1-config –with-apu=/usr/local/apache/bin/apu-1-config

잘되었다.

;;

허무하네

/usr/local/modsecurity
[root@localhost modsecurity]# ll
합계 0
drwxr-xr-x 2 root root 70 10월 4 16:11 bin
drwxr-xr-x 2 root root 30 10월 4 16:11 lib

#ll /usr/local/modsecurity/lib/mod_security2.so
-rwxr-xr-x 1 root root 2490512 10월 4 16:11 /usr/local/modsecurity/lib/mod_security2.so

잘된다.

route53 에서 한글 도메인 사용법. 부제 – 장난으로 리눅서.com 구매한 이야기

흔히들 한글도메인을 많이 사용한다.
처음 한글도메인을 사용하시는분들이 겪게 되는 이야기다.

route53에서 한글 도메인 구입은되는데 hosted zone 생성은 안된다고 한다.

간단하다 모든 네임서버는 한글을 인식할수 없다.

그런데 우리는 한글도메인을 사용한다. 사용할때 필요한것이 퓨니코드다.

퓨니코드(Punycode)는 유니코드 문자열을 호스트 이름에서 허용된 문자만으로 인코딩하는 방법으로, RFC 3492에 기술되어 있다. 퓨니코드는 유니코드가 지원하는 모든 언어로 국제화 도메인을 쓸 수 있게 한 IDNA의 일부로, 변환은 전적으로 웹 브라우저와 같은 클라이언트에서 이루어진다.

뭐그렇단다.

그래서 퓨니코드로 인코딩된 문자열로 hosted zone 을 생성하면 사용할수 있다.

갑자기 든 의문이다. 퓨니코드 서브도메인은 생성이 가능할까?

도전해 본다.

https://후이즈검색.한국/idnconv/index.jsp

에서 변환가능하다.

리눅서.linuxer.name 를 변환하면 xn--pd1b38litg.linuxer.name 가 된다.

퓨니코드로 변환된 서브도메인으로 접속시에 잘된다.

결론. 한글서브도메인 route53에서 사용가능하다. 그럼 혹시 com 도메인도 퓨니코드로 변환해서 등록이 가능하지 않을까?

xn--pd1b38litg.com 으로 검색이 되고 구매까지 이어진다.

크래딧으로는 도메인을 구매할수 없다.

등록대기중 뜨고.

결제도 되구..
엥? 진짜? 리눅스.com 생성되는거야??????????????????????

리얼리? 농담인데;;;;;;;;;;;;

자동으로 hosted zone 도 생성됬고…….돌이킬수 없게 됬다.

나는 장난으로 리눅서.com을 가지게 되었다…

1년시한부로..

당연히 될건 알았는데 사고나니 좀 웃기기도 하고 그렇다.

리눅서.com 출격합니다.

acm도 잘추가되고!

웹사이트도 잘열리고!

감사합니다.

ssh putty로 접근시 로그인창이 늦게 뜨는 증상.

putty로 ssh 접근시에 로그인이 느리다는 의뢰인이 있었다.

보통이경우엔 UseDNS no 나 GSSAPI Authentication 인증으로 인하여 느려지게 된다. GSSAPI 관련 문제의 경우엔 보통 secure 로그에 GSSAPI 에러가 남게된다. 그래서 보통 접근은 DNS -> GSSAPI 순으로 하게되는데 제일먼저 /etc/resolv.conf 에 nameserver 설정을 변경하고 그다음은 sshd_config 에서 UseDNS no 설정을 추가하게 된다.

일단 하나로 UseDNS no 옵션도 GSSAPI도 아니라 일단 하나로 DNS인 210.220.163.82를 알려주었다.

그러던중 이상한걸 발견했다. sesure 로그에서 질문인의 IP가 222.222.222.1인것.

베이징 IP다.

222.222.222.1은 베이징의 공인IP로 퍼블릭으로 연결되는 설정이 있는 VM의 경우 route로인해 첫번째 문제가 발생하고 vm에서 dns 확인하면서 ssh 접속이 느려지는 문제가 발생한다, 그렇기에 우리는 네트워크에 정해진 규약을 사용해야 한다.

10.0.0.0 ~ 10.255.255.255
172.16.0.0 ~ 172.31.255.255
192.168.0.0 ~ 192.168.255.255
사설 IP 대역을 사용하지 않아서 ssh 접속이 느려졌다.

사설 IP사용은 이유가 있다.

오늘 포스팅 주제를 선물해주신 신난 어피치님 매우 감사드린다!

file swap 만들기

더미파일 생성

#dd if=/dev/zero of=/root/swapfile bs=1024 count=2000000
1580109+0 records in
1580109+0 records out
1618031616 bytes (1.6 GB) copied, 23.3556 s, 69.3 MB/s

생성된 파일 확인

#ll /root/swapfile
total 1580112
-rw-r–r– 1 root root 1618031616 Sep 7 20:24 swapfile

swapfile 에 권한 생성

#chmod 600 /root/swapfile

swap 생성

#mkswap /root/swapfile
Setting up swapspace version 1, size = 1.5 GiB (1618026496 bytes)
no label, UUID=89d2f092-7fee-4fa2-854a-77a914e79367

swap 마운트

#swapon /root/swapfile
#free -m
total used free shared buff/cache available
Mem: 983 136 75 18 771 669
Swap: 1543 0 1543

swap 자동 마운트 rc.local 하단에 추가

#vi /etc/rc.local
swapon /root/swapfile

ubuntu 16.04 pam 패스워드 유효성 제한 libpam-pwquality 설정 포함

패스워드 유효성 검증

로그인 실패 5 계정 잠금 5분
#vi /etc/pam.d/common-auth
16번째줄 삽입
auth required pam_tally2.so file=/var/log/tallylog deny=5 even_deny_root unlock_time=300

#vi /etc/pam.d/common-account
16 줄에 삽입
account required pam_tally2.so

패스워드 만료 모듈 설치
#apt-get -y install libpam-pwquality

패스워드 만료 모듈의 경우에는 사용자를 새로 만들때만 영향을 줍니다.
따라서 기존유저에 적용시에는 명령어로 지정해주어야 합니다.

패스워드 사용가능 최대 기간
#chage -m (days) (user)

PASS_MAX_DAYS 180

패스워드 사용가능 최소 기간
#chage -m (days) (user)

PASS_MIN_DAYS 2

패스워드 만료전 경고 일수
#chage -W (days) (user)

PASS_WARN_AGE 7

패스워드 사용시간 제한

#vi /etc/login.defs
PASS_MAX_DAYS 180

#vi /etc/pam.d/common-password
password requisite pam_pwquality.so retry=3 minlen=10 minclass=3
password [success=1 default=ignore] pam_unix.so obscure use_authtok try_first_pass sha512 remember=2

remember=2 2회 동안 동일한 비밀번호 생성 금지
minlen=10 비밀번호 길이 생성 제한 10자 이상으로
minclass=3 새비밀번호에 필요한 문자 클래스 수 제한 (종류 ⇒ 대문자 / 소문자 / 숫자 / 기타)

참조 URL
https://www.server-world.info/en/note?os=Ubuntu_16.04&p=password

isms 기준에 맞춘 ubuntu 16.04 ssh 패스워드 유효성 설정입니다.

apache http1.1 aws alb htt2 enable error

safari 계열의 브라우저에서 내 블로그가 정상적으로 열리지 않았다.
여러번 시도해야 열렸고, 한번에 열리지 않았다.

이원인을 찾기위해서 로그분석부터 부단한 노력을했으나, 한동안 해결할수 없었다.

그런데 어제 오픈카톡방의 박주혁 님께서 safari에서 정상적으로 열리지 않는다는 스크린샷을 올려주셨다.

인증문제가 아닐까 생각했지만 인증문제는 아니었고 이문제를 해결하기 위해선 내 웹서버의 설정을 설명해야 한다.

amazon linux에서는 httpd-2.4.39-1.amzn2.0.1.x86_64이 기본으로 설치되는 apache 이다. 그리고 php는 여러가지 버전을 repo로 지원하고 있는데
amazon-linux-extras 명령어로 사용가능한 repo를 확인할수 있다.

일단 이부분에서 내가 old한 엔지니어라는 사실을 알았다.
나는 apache-php 연동은 반드시 module로 연동을 한다.
그런데 amazon linux는 amazon-linux-extras install php7.3 명령어를 사용하면 module로 설치하는 것이 아닌 php-fpm 방식으로 php가 설치된다.

그렇기에 나는 몇가지 old한 설정을 추가하였다.

apache 는 온프레미스에서 의례 사용하던 방식인 prefrok 방식으로 설정하였고, php는 fpm이 아닌 module로 셋팅하였다.

여기서 문제가 발생한것이다.
아래 URL에서 발췌한 내용이다.
HTTP/2 is supported in all multi-processing modules that come with httpd. However, if you use the prefork mpm, there will be severe restrictions.

https://httpd.apache.org/docs/trunk/howto/http2.html

http2 를 사용하려면 prefork를 사용하기 어렵다.
그런데 필자는 prefork 를 사용하였기 때문에 정상적으로 호환이 되지 않은 것이다.

aws alb(http2) – apache (prefork)강제로 http2사용

aws의 ALB는 http2를 기본으로 enable하게 되어있기때문에 정상적인 커넥션이 불가능했던것이다.

일단 급하게 ALB에서 http2를 껏다.

그리고 오늘 mpm을 event로 돌리고 http2를 강제로 사용하게 했던 설정을 빼고 php-fpm으로 웹사이트를 사용할수 있게 변경하였다.
이후엔 정상적으로 사이트가 동작했으며, 간헐적으로 열리지 않는 증상은 사라졌다.

이글을 빌어 다시한번 박주혁님께 감사를 드린다.

앓던 이가 빠진기분이다.

유레카!