dotlottie 다운로드 안되는 문제 (feat. AWS amplify)

 로컬서버에서 dotlottie 파일을 저장하고 사용해보면 잘 작동한다.

하지만 실제로 AWS amplify에 배포를 했을때, .lottie 파일이 다운로드 되지 않는다.

네트워크 탭을 살펴보면 index.html 을 리턴할 뿐이다.

찾아보니

AWS amplify 에서 rewrite / redirect 설정에 lottie라는 확장자를 예외로 처리해줘야 한다.

살펴보면, json, pdf, css 등등 이미 예외처리되어 있는 여러 확장자들이 보이는데

이 확장자 끝에 lottie를 추가해주자.

그다음 재배포 해주면 끝

AWS Cloud watch "insufficient data" 문제

 AWS에서 cloud watch metric에는 크게 2종류의 데이터 수집 방법이 있다.

• period-driven metric
• event-driven metric

Period-driven metric

말 그대로 특정 interval 마다 데이터를 수집하는 방식이다. 

대표적으로는 cpu utilization같은것이 있다.

이런 겅우에는 매순간 데이터를 측정하기 때문에 현재상태가 정상인지 비정상인지 판단하는 기준이 간단하다.

Event-driven metirc

특정 이벤트가 일어날때만 데이터가 수집된다.

대표적으로 ELB_5XX_count 같은것이 있다.

실제로 500번대 에러가 나지 않는다면 데이터가 수집되지 않는다. 

그럼 이 값이 0이 될것 같지만 그렇지 않다.

이럴 경우 "insufficient data" 라는 상태가 되는데, 실제로 데이터가 수집되지 않았기 때문이다.

Missing Data

missing data라는 옵션이 있는데 이는 데이터가 수집되지 않을 경우를 의미한다.

ELB_5XX_Count Metric의 경우 데이터가 수집되지 않으면 실제로 정상이라고 해석할 수 있는 옵션을 제공한다. "not breaching" 옵션을 선택하자.

CPU Utilization metric 의 경우 데이터가 수집되지 않는다는것은 인스턴스가 죽어있을 화률이 높다. 그러므로 "Breaching" 옵션을 선택하자.

기본값은 "Missing". 그 전 상태 유지가 된다.

출처

- https://repost.aws/knowledge-center/cloudwatch-alarm-insufficient-data-state

- https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html#alarms-and-missing-data

PostgreSQL 타임존 영구변경 쿼리

PostgreSQL 타임존 영구변경을 찾다보면

항상 conf 파일을 수정하라고 한다.

AWS - RDS에서 conf 변경을 할 수 있지만

좀더 쉬운 방법이 있다.

Choose a timezone from:

SELECT * FROM pg_timezone_names;

And set as below given example:

ALTER DATABASE postgres SET timezone TO 'Europe/Berlin'; 

Use your DB name in place of postgres in above statement.

출처: https://stackoverflow.com/questions/6663765/postgres-default-timezone 

우분투 20.04 openvpn 서버 구축

참고자료: https://dejavuqa.tistory.com/243

나는 aws ec2로 구축했는데 잘 작동했다.

위의 링크로가면 상세한 설명과 사진까지 완벽 그 자체

너무 감사합니다.

몇가지 문제점. 

sudo 명령어로 실행할때 ~ 폴더는 /root가 된다는 사실

마지막 .sh 파일을 작성할때 ~ 부분을 /home/someid 이런식으로 바꿔줘야 한다.

다음에 필요할때 또 보려고 보관용으로 쓰는 블로그

--------------------------------

추가

우분투에서 부팅시(네트워크 재연결시) 자동으로 (re)connect하는 방법

/etc/default/openvpn 파일안에서 

AUTOSTART="all" 항목의 주석을 제거하면 된다.

그 뒤에 

systemctl daemon-reload

를 해주고

/etc/openvpn 폴더아래에 .ovpn 파일을 확장자를 .conf로 바꿔서 넣어두면 된다.

출처: https://askubuntu.com/questions/464264/starting-openvpn-client-automatically-at-boot

---------------------------------

추가.

현재 접속중인 client list를 보고, disconnect를 하고 싶을때가 있다.

일단 현재 접속중인 client list를 보는 방법은 2가지가 있는데,

그중에 쉬운것은

/var/log/openvpn/openvpn-status.log 파일을 들여다보면 현재 접속중인 client list들이 나와있다.

두번째 방법은 openvpn에서 자체적으로 제공하는 management 프로그램을 이용하는 방법인데

openvpn server.conf에 들어가서 맨 밑에 

management localhost 7505

이렇게 한줄을 추가한다. 맨 마지막 숫자는 포트를 의미하는데 다른 숫자를 써도 상관없다.

그다음 openvpn@server.service 를 재시작해준다.

systemctl restart openvpn@server.service

재시작이 되면 localhost 7505 로 telnet 접속을 할 수 있게 된다.

telnet localhost 7505

그다음 help를 입력하면 여러가지 커맨드가 나오는데 

접속중인 client list를 확인하는 status 커맨드

client 연결을 해제할 수 있는 kill 커맨드 등의 설명이 나온다.

매번 telnet을 이용해서 접속하기가 귀찮으니

당연히 이걸 웹으로 제공하는 openvpn-monitor 라는것이 있다.

하지만 aws에서 이걸이용해서 접속하기엔 보안문제와 또다른 웹서버를 돌린다는 문제등으로 인해 설치가 조금 꺼려진다.

다른 컴퓨터에서 웹서버를 설치하고 이 openvpn 서버로 telnet 접속을 할 수 있는 방법을 찾아보면 좋을듯 하다.

AWS에서 클러스터 구성후 (DMZ) iptables 포트포워딩, 라우팅을 이용한 접속서버 만들기

AWS에서 spark 클러스터를 만들어서 실습을 많이 했다.

spark, hadoop 클러스터의 특성상 많은 포트를 사용하는데, 하나하나 하기가 귀찮아서
모든 포트를 개방했다.

그것때문인지는 모르겠는데 너무 많이 자동 봇들의 공격이 들어온다.

ssh 포트를 바꾸는 걸로는 부족했다.



그래서 클러스터는 내부망으로 외부에서 접근불가하게 iptables를 설정해두고

외부에서 접근할수 있는 인스턴스를 하나 두고 거길 거쳐서 통과하게 하려고 했다.

클러스터에는 주피터노트북등 기타 서비스를 구동시키려고 했기때문에 포트포워딩이라는 것으로 검색해보다가 아래의 좋은 링크를 발견



출처: http://blog.naver.com/PostView.nhn?blogId=alice_k106&logNo=221305928714&parentCategoryNo=&categoryNo=22&viewDate=&isShowPopularPosts=false&from=postView

우분투 iptables -L 명령어가 느릴경우. (AWS 라이트세일)

AWS 인스턴스를 사용하다보면 static IP를 받아서 사용할 때가 있다.

그런경우 여러 자동봇으로부터 공격을 받는다. 

보통 iptables 를 이용해서 방화벽 설정을 많이한다.

iptables 사용법이 궁금하다면 나의 다른 포스트를 보시길 바란다. 링크

iptables를 이용해서 필요한 포트와 접근할수 아이피만 허용하고 나머지는 다 닫아버렸다.

그런데 문제점이 생겼다.

• iptables -L 명령어를 통해 현재 방화벽 룰 리스트를 불러올때 오래걸린다
• 인스턴스를 재부팅 했을 때 ssh 접속거부가 10분정도 계속된다. 

문제점을 구글 검색해봤을때 53번 포트 udp를 열어둬라, nameserver 세팅을 주의깊게 봐라, nameserver lookup 문제다. nameserver 로 8.8.8.8를 등록해라(구글네임서버) 등등 여러 방법이 있었지만 다 안되었다.

마지막으로 /etc/resolv.conf 파일을 보니 네임서버가 127.0.0.53 으로 세팅되어있었다.

그래서 혹시나하는 마음에 

iptables -I INPUT -s 127.0.0.0/8 -j ACCEPT

명령어로 로컬호스트 관련아이피를 허용해주니

따단! 해결

이유와 원리는 모르겠다. 묻지마라.

아시는분은 댓글로 알려주십시오. 감사합니다.

[AWS] 메일서버 spf, dmarc, dkim 쉬운정리

네이버, 다음 같은 국내 포털은
spf, dmarc, dkim 레코드가 잘 되어있지 않더라도 메일을 수신해준다

하지만 해외메일서버는 좀 다르다.

spf, dmarc, dkim 레코드가 없으면 아에 블락처리를 해버린다.
이런 레코드들이 잘 갖추어져 있다하더라도 스팸함으로 들어가버리기 다반수
스팸처리 안되려면 reverse DNS를 해야하는것 같은데 ISP나 AWS에서는 답장을 안해준다...

어쨋든 스팸함으로 들어가든 말든, 블락처리라도 당하지말자. 할수있는데까지 해보자

spf, dmarc, dkim 순서대로 발전해왔지만, 중요한건 셋다 해야한다는것.
여러 어려운 문법들이 존재하지만, 여기서는 개인 메일서버를 운영한다고 생각하고 기본만 주입한다. 자세한 뜻을 다루는 포스팅들도 있으니 검색해보길


시작전 주의할점

같은 도메인을 쓰는데
메일서버를 웹서버와 다른 컴퓨터에 각각 구축하고싶은 사람이 있을것이다.

예시.
웹서버 ip : 1.1.1.1
메일서버 ip: 2.2.2.2

DNS 작성법
your-domain.com                     A          1.1.1.1
your-domain.com                   MX        10 mail.your-domain.com
mail.your-domain.com             A          2.2.2.2
your-domain.com                   TXT       "v=spf1   `~!@~#$~@$~@"
_dmarc.your-domain.com      TXT       "DMARC !@#!@#~#~#"
dkim._domainkey.your-domain.com      TXT       "!@#$@!#%!"

호스트네임에 주의해야함..

1. spf레코드

DNS로 가서 TXT레코드를 작성한다.
your-domain.com   TXT   "v=spf1 ip4:123.123.123.123 ~all"
123.123.123.123 을 자기 ip로 바꾸는것 정도는 안다고 생각한다

여기서 확인가능

2. dmarc레코드

DNS로 가서 TXT레코드를 작성한다

_dmarc.your-domain.com      TXT      "v=DMARC1; p=quarantine"

여기서 확인가능

3. dkim 레코드

이것은 조금 복잡다. 

이분의 블로그가 정말 설명을 잘해주셨다. 

덧붙이고 싶은것은 

Selector를 mail로 하셨는데 자기마음대로 이름을 지정해줘도 된다. 만약 바꾼다면 블로그에 나오는 mail을 모두 바꾼이름으로 변경해야한다.

Socket은 unix소켓방법으로 해보니 잘 안되더라. 이분의 블로그대로 tcp소켓을 이용하는것이 잘된다.

DNS에서 TXT레코드를 작성해야할때, 조심해서 잘 해야한다. 긴 문장이 세개의 큰따움표 구간으로 나뉘어 있는데 

각 구간사이에 줄나눔이 있으면 안되고 스페이스 하나만 존재해야한다.

예시) "foo" "boo" "too"     이런식으로

"foo"\n"boo"\n"too" 이런식이 되면 안된다. 말로하니 어려운데.... 잘 생각해보길

여기서 확인가능

ec2 ssh 키없이 접속하는 방법

/etc/ssh/sshd_config 파일에
PasswordAuthentication 항목이 no인데 이것을 yes로 바꾼다.

sshd 서비스 재시작
sudo service ssh restart
또는
sudo service sshd restart



ubuntu아이디는 공격당하기 쉬운 아이디 이기 때문에
새로운 사용자를 만들고 그 사용자에게 sudoers 권한을 주고
그 사용자로 접속하는 방법이 좋다.
ubuntu 아이디에 패스워드를 처음부터 넣지 말자.