'Daily/Prog'에 해당하는 글 117건

io 도메인

Daily/Prog 2022. 1. 24. 00:27

얼마전 도메인이 세개 정도 필요해서 간만에 쇼핑 좀 했다. example.com / example.net 나머지 하나는 뭘로 선택할까... 하다가 구글 검색에 자주 보이는 io 도메인으로 결정했다. 대충 뭐 IT 기술 관련 도메인으로 많이 사용하는 줄로 알고 있긴 했는데 가격이...

 

io_domain

 

AWS 기준으로 닷컴이 $12 인데 io 도메인이 $71 라니... 구글이 $60 로 나오는데 그렇다 해도 .com 의 5배.

 

어이가 좀 없긴 했는데 궁금하기도 하여 검색을 좀 해봤다.

 

.io 도메인은 기술기반 스타트업들이나 블록체인 프로젝트에 많이 사용한다. 원래 영국령 인도양식민지(British Indian Ocean Territory)의 국가코드 톱 레벨 도메인으로 한국의 .kr 도메인과 같지만 .io 도메인은 국가 제한이 없는 누구나 사용이 가능할 수 있는 도메인 중 하나이다. 데이터 입출력을 뜻하는 Input/Output 으로도 해석하며 IT 기술기반 업계에서 많이 쓴다고 하는데 그냥 갖다 붙인 느낌... 어쨌든 한참을 그런 업계에서 애용하고 있다니 원한다면 .io 든 .dev 든 사면 되겠지만 가격이 왜 이 모양인지... 비싼 이유를 좀 찾아보려 했으나 해당 글도 별로 없는거 같고 찾고 싶지도 않아졌음. 보아하니 유행 살짝 타니까 돈 좀 벌어볼라고 세계적으로 가격단합 중인거 같은데... 비쌀땐 안사면 됨. 도메인은 .com 이 짱이지...ㅋ


WRITTEN BY
손가락귀신
정신 못차리면, 벌 받는다.

트랙백  0 , 댓글  0개가 달렸습니다.
secret

Received-SPF: none

Daily/Prog 2021. 12. 28. 21:24

장애


메일 이상 작동 접수,

 

  • Google Workspace Email 에서 @example.com 끼리는 메일이 주고 받아짐.
  • 다른 도메인에서 @example.com 으로의 메일도 잘 받아짐.
  • @example.com 에서 다른 도메인으로 메일을 발송하면 누구는 받아지고, 누구는 안받아지고, 누구는 스팸함에... 복불복임.ㅋ

 

테스트로 받아진 메일 원문을 보니, 첫줄부터 힌트를...

 

Received-SPF: none (kakao.com: domain of gabriel@example.com does not designate permitted sender hosts)

 

SPF: none - 발신 도메인이 SPF(Sender Policy Framework) 레코드를 설치하지 않았거나 제공된 발신자 정보에서 해당 도메인 정보를 구할 수 없음. SPF 확인 장치가 메일의 위조여부를 판정할 수 없음.

 

결국 DNS 서버에 SPF 세팅이 잘못됐을 것이라 추측하고 설정 확인.

 

SPF "v=spf1 include:_spf.google.com ~all"

 

구글에서 하라는 대로 잘되어 있는 것 같아서, 도메인이나 ip 를 추가해 줘야하나... 했는데,

 

https://aws.amazon.com/ko/premiumsupport/knowledge-center/route53-spf-record/

 

Route 53의 SPF 레코드 문제 해결

Internet Explorer에 대한 AWS 지원이 07/31/2022에 종료됩니다. 지원되는 브라우저는 Chrome, Firefox, Edge 및 Safari입니다. 자세히 알아보기

aws.amazon.com

 

* 요점
대부분의 메일 공급자에서는 SPF 레코드가 2014년 4월에 더 이상 사용되지 않으므로 SPF 구성이 적용되지 않습니다. 자세한 내용은 Internet Engineering Task Force(IETF) 웹 사이트에서 RFC 7208을 참조하십시오. SPF 레코드 대신 적용 가능한 값이 포함된 TXT 레코드를 만드는 것이 좋습니다.

 

 

해결


 

TXT "v=spf1 include:_spf.google.com ~all"

 

레코드 유형을 TXT 로 추가하여 해결...

 

Received-SPF: pass (kakao.com: domain of gabriel@example.com designates 123.123.123.123 as permitted sender)

 

하는 김에 DMARC 설정 추가하고, DKIM 은 관리자 권한 있으면 추가, 그리고 테스트 ㄱㄱ

 

 

Check MX: MX 및 SPF 레코드 확인

 

toolbox.googleapps.com

 

checkmx

 

 

또 하나,,, 테스트 한답시고 test1, test2, test3 이 따위로 메일 반복해서 보내면,

 

Delivery failed: gabriel@kakao.com
10.61.236.127 failed after I sent the message.
Remote host said[Response Message]: 554 5.7.1 DAS41 209.85.210.193: Your mail is blocked automatically by anti-spam system. (E04)
STEP: DATA SEND

 

이렇게 반송 메일 수신 가능...ㅋㅋ

 

 


WRITTEN BY
손가락귀신
정신 못차리면, 벌 받는다.

트랙백  0 , 댓글  0개가 달렸습니다.
secret

Exclude log4j2

Daily/Prog 2021. 12. 17. 20:59

log4j

 

ECR 에서 log4j2 사용중인 이미지들 깜빡하고 있었는데 AWS 에서 친절히 메일이 왔다.

 

You are receiving this communication because your account has container images stored in Amazon Elastic Container Registry (ECR). While not all container images are impacted by this CVE, your images may be affected if they are using Java with Apache Log4j in certain configurations. Amazon Inspector scans container images stored in Amazon ECR for software vulnerabilities to generate Package Vulnerability findings and is able to detect this issue in container images. You can turn on enhanced scanning from ECR [2] or enable Inspector from Inspector console to discover this issue in your images[3].

 

계정에 Amazon Elastic Container Registry(ECR)에 저장된 컨테이너 이미지가 있기 때문에 이 통신을 수신하게 되었습니다. 모든 컨테이너 이미지가 이 CVE의 영향을 받는 것은 아니지만 특정 구성에서 Apache Log4j와 함께 Java를 사용하는 경우 이미지가 영향을 받을 수 있습니다. Amazon Inspector는 Amazon ECR에 저장된 컨테이너 이미지에서 소프트웨어 취약성을 스캔하여 패키지 취약성 결과를 생성하고 컨테이너 이미지에서 이 문제를 감지할 수 있습니다. ECR[2]에서 향상된 스캔을 켜거나 Inspector 콘솔에서 Inspector를 활성화하여 이미지에서 이 문제를 발견할 수 있습니다[3].

 

log4j2 취약점이 추가로 계속 발생하고 있다. 2.15 에서 2.16 버전으로 업데이트...

확인하기도 귀찮다. 자꾸 신경쓰이게 하지 말고, logback 쓰고 log4j2 는 그냥 꼬죠.

 

// build.gradle
configurations {
    implementation.exclude group: "org.apache.logging.log4j"
}

 


WRITTEN BY
손가락귀신
정신 못차리면, 벌 받는다.

트랙백  0 , 댓글  0개가 달렸습니다.
secret

finalizers

Daily/Prog 2021. 12. 12. 03:17

EKS 에서 ingress 와 loadbalancer 를 생성했는데 pending 상태라 살펴보니 자격증명 실패 에러가 발생했다.

 

$ kubectl describe ingress my-ingress
Warning FailedBuildModel  32m (x9 over 47m)  ingress  (combined from similar events): Failed build model due to WebIdentityErr: failed to retrieve credentials
caused by: InvalidIdentityToken: Incorrect token audience
status code: 400, request id: 4599a6da-7a29-4d82-baf7-d546e7811234

 

확인하고 삭제하려는데 삭제가 안된다.ㅋ 강제 삭제(--force --grace-period=0)도 안된다; 시간이 한참 지나도 프롬프트가 멈춰버림.

 

$ kubectl describe svc my-nlb
...
Normal   DeletedLoadBalancer  40m  service-controller  Deleted load balancer
Warning  FailedDeployModel    38m  service             Failed deploy model due to WebIdentityErr: failed to retrieve credentials
Warning  ClusterIPNotAllocated  75s (x5 over 37m)  ipallocator-repair-controller    Cluster IP [IPv4]:172.20.23.140 is not allocated; repairing
Warning  PortNotAllocated       75s (x5 over 37m)  portallocator-repair-controller  Port 32083 is not allocated; repairing

 

권한은 없는데 복구 의지가 강해서 그런건지, 안죽고 계속 살아나려고 발버둥 치는 느낌. 다른 서비스들과 결합이 되어 있는건지... 클러스터를 거의 초기화 수준으로 다른 모든 리소스를 다 지웠는데도 삭제가 안되는 생명줄 긴 로드 밸런서들. 구글님 덕에 겨우 찾아 삭제했다.

 

$ kubectl patch service/<your_service> --type json --patch='[ { "op": "remove", "path": "/metadata/finalizers" } ]'
$ kubectl patch ingress <your_ingress> -n <your_ns> -p '{"metadata":{"finalizers":[]}}' --type=merge

 

finalizers 는 리소스를 완전히 삭제하기 전에 특정 조건이 충족될 때까지 대기하게 한다. 삭제가 완료되면 대상에서 관련 finalizers 를 삭제하는데, 위처럼 metadata.finalizers 필드를 비워주면 Kubernetes 는 삭제가 완료된 것으로 인식하게 된다.

 


WRITTEN BY
손가락귀신
정신 못차리면, 벌 받는다.

트랙백  0 , 댓글  0개가 달렸습니다.
secret

EKS Fargate limit

Daily/Prog 2021. 12. 7. 21:23

3년만인가. 드디어 ECS 에서 EKS 로 넘어왔다. 그 때도 ECS 보다는 조금 더 핫했던 쿠버네티스를 써보고 싶었지만 아마 아시아 리전에는 없었던 것으로 기억한다. 그리하여 이래저래 문서들 보고 헤딩하며 클러스터를 만들었는데 무언가 deployment 가 이상 작동을 하는 듯 했다. 안그래도 헤딩 중인데 되는 것 같기도 하고 안되는거 같기도 하고, 한참 삽질 끝에 Fargate 노드가 2개 까지만 만들어지는 현상을 발견했다. 이벤트 로그 메시지:

 

"Your AWS account has reached the limit on the number of Fargate pods it can run concurrently"
당신의 AWS 계정이 동시에 실행할 수 있는 Fargate 포드 수 제한에 도달했습니다.

 

 

내 계정은 이제 막 새로 판지 얼마 안된 새삥인데, 계정에도 뭔 종류가 있나. 뭔 업그레이드를 해야 하나 싶었다. 일단 구글에서는 저 메시지로 검색된 결과가 거의 없었다. 그나마 증상이 유사한 글에서, 몇몇 제한이 있는 리전이 있어서 리전을 바꾸던지 EC2 를 써야 한다는 글을 보았다. 우선 리전에서 fargate 할당량 체크를 했다.

 

[Service Quotas] - [Fargate On-Demand resource count]
사용률 4% / 적용된 할당량 값 50 / AWS 기본 할당량 값 1,000

 

 

개널널. 아직 48개 더 만들 수 있는데 나한테 왜그러는지... 혹시나 해서 도쿄 리전에도 만들어 봤으니 똑같은 메시지. 어쩔 수 없이 [지원센터] 찬스를 이용했다. 간결하게 물었다.

 

Q. eks 를 사용중이다. Fargate Pod 수가 2가 되면 더 이상 Pod 를 추가할 수 없다.

 

그랬더니 답변이 정말 개허접스럽게 왔다.

 

A. Fargate 동시 작업 제한 문제가 발생하지 않도록 EC2 인스턴스를 시작하시겠습니까?

 

 

ㅋㅋㅋ Basic 이라고 답변을 이딴 식으로 하면 돼, 안돼? Fargate 써볼라고 하는 사람한테 할 소리? 장사 안하겠다는건데 진짜 수준 개실망. Basic 은 기술문의도 막혀있네. 우와~ 처음 알았음. 답변도 거의 반나절 걸리고 내가 진짜 웬만하면 저기 글 안올리는데 이거 너무 이상해서 올렸더니만 역시나네. 사실 내 질문은 저기서 끝나지 않았음. '이것도 안된다. 저것도 안된다.' 그랬더니 그 때부터는 모든 질문을 기술팀에 넘겼다며 답변이 오는대로 바로 전달하겠다는 말을 남겼고, 난 며칠동안 답변이 오기전 그 모든 현상들을 해결했다.

 

사실 위 문제의 해결은 그들이 할당량을 100 으로 늘리자마자 해결됐다. 이걸로 해결된게 더 어이가 없다. 이 할당량은 리전에서 생성할 수 있는 Farget 의 최대치인데 기존에도 널널했는데 이제서 됐다는게 이상하다. 위에 나타난 에러는 내 AWS 계정의 제한을 얘기했다. 그들이 내 계정의 제한을 풀어준 것이라면 이해가 가겠지만... 또, 신규 계정의 fargate 제한이 2라면 그것도 말이 안된다. 이에 대해 구체적으로도 문의를 했지만, 과다 청구를 막기 위한 제한이니 안될 경우  할당량 증가 요청을 하라는 ㄱ소리... 불이익을 받지 않기 위해 별 다섯개를 투척하긴 했다만... 

 

내 결론은 Fargate 적용된 할당량 기본값은 2임. 화면에 보여진 50은 아마도 버그일 것임. 아니면 x < 50 ? 50 이던가. 그래서 할당량 값을 새로 업데이트만 시켜줘도 50 이상의 값이 설정되는 것임. 아마 나 역시 51로만 업데이트 했어도 됐을 것임. 이것이 바로 내 소설이다. 만약 이런 문제가 발생하면 바로 할당량 요청 ㄱㄱ

 

 

service-quotas

 


WRITTEN BY
손가락귀신
정신 못차리면, 벌 받는다.

트랙백  0 , 댓글  0개가 달렸습니다.
secret