발생한지 꽤나 된 이슈이다. 반년은 넘은 것 같다.집에서 도커 데스크탑을 실행할 때 갑자기 발생하기 시작했다. 에러 내용은.. initializing backend: retrieving system info: retrieving system version: exec: "sw_vers": executable file not found in $PATHinitializing app: getting system info: retrieving system version: exec: "sw_vers": executable file not found in $PATH라고 한다. 당시에 구글링해도.. 딱히 도움이 되는 정보가 없었다. 임시 해결책은.. 위의 경로에 가서 도커를.. 실행시키는 것이다. ./com.docke..

스마트폰 개발도 꽤 했고..컴퓨터 조립도 자주하는데 기억력이 붕어인 것 같아 간단히 다시 정리해보자. x86은.. 그냥 예전 인텔 cpu라고 보면 될 것 같고(정확히는 아키텍쳐겠지만..)x64, amd64는 요즘 나오는 인텔이나 AMD의 cpu.. arm64는 퀄컴에서만 제공하는 지는 모르겠으나..내가 스마트폰 개발할 때 퀄컴에서 만든..안드로이드 모바일용 cpu.. (스냅드래곤?)좀 더 찾아보니 iOS에서 쓰이는 칩들도 arm64 아키텍쳐라고 한다.심지어 애플 실리콘 M칩들도 그러니 음.. 그래서 arm64가 인프라에서 인기가 많은 것 아닐까? 참고:https://m.blog.naver.com/cjs0308cjs/223242935705https://velog.io/@wltjd3459/iOS-C..

키클락이 오픈소스이고 좋은데 단점이.. 기본적으로? 인피니스팬이라는 메모리에 세션이 저장되다보니 재시작을 하게 되면 사용자들의 로그인이 다 풀리게 된다.최근 들어서 25 버전부터? db에 세션을 저장하는 기능을 지원한다.(persistent-user-sessions라는 키클락 기능) 문제는.. 이전 버전에는 세션 관련 정보들이 메모리에 있어서 끌 수가 없다는 것이다. 키클락 오픈소스를 다운받아서 이리저리 분석해본 결과키클락 admin rest api로 각 렐름의.. 세션 정보들을 받아와서이 것을 토대로 db에 들어갈 쿼리 문을 만들면 된다.OFFLINE_USER_SESSIONOFFLINE_CLIENT_SESSION에 넣어주면 된다.(내용이 좀 길어져서 자세한 부분은 생략) 왜 키클락에서는 손쉬운 마이그레..

키클락의 경우 세션매니져로 서버에 접속하여 docker attach 등을 하면.. 콘트롤+C 를 누르면 도커가 종료되어 버린다. 그래서 콘트롤 + P, Q를 눌러서 빠져나오려고 했으나 크롬에서 해버리면.. 크롬이 종료되버린다. 어쨋든 attach로 하여 로그를 보고.. 키클락 컨테이너를 종료시키기는 싫어서 탭을 닫았다.그러면 그냥 백그라운드로 잘 돌아갈 것이라고 생각했었는데 세션 매니저가 종료되는 시점에 키클락 도커 컨테이너도 동시에 죽는 현상을 발견했다. docker inspect에서 129 종료 시그널을 볼 수 있고리눅스로 보면(128 + 1) No    Name         Default Action       Description1     SIGHUP       terminate process ..

그냥 맥 터미널에서는 zsh을 깔고 oh-my-zsh도 설치하여 보기가 편한데 인텔리제이의 터미널에서는 이상하게도 zsh이 적용되지 않았다. 인텔리제이 Settings에서 기본 쉘을 zsh로 했음에도 이상하게 bash가 계속 기본 쉘로 지정이 되었다. chsh -s /bin/zsh 명령어도 소용이 없었다. 노트북 재부팅도 소용이 없었다. 뭔가 버그가 있었던 것 같다. 인텔리제이에서 환경변수를 확인해보고 SHELL이 zsh로 적용된 것을 확인하고.. 딱히 어떤 값을 수정하지는 않았는데 갑자기 인텔리제이에서 echo "$SHELL" 로 확인했을 경우 zsh이 나와서 인텔리제이의 터미널을 껐다가 키니.. zsh이 적용이 됐다.. 뭐 이런 신기한 버그가 다 있을까?

보통 통신이 안될 때 어딘가 방화벽 설정이 잘못됐다거나 서버에서 듣고 있지않다거나 둘 중에 문제가 있는 것 같다. 그래서 aws에서 route53부터 시작해서 해당 서버까지 보안그룹 문제가 없는지 확인도 하고.. 문제가 되는 서버에서 아래의 netstat 명령어를 써서 서버는 문제가 없는지 확인한다. 이런저런 다른 것을 하다보니 이 명령어 옵션도 긴가민가해서.. 아무래도 기록으로 남겨둬야 겠다. netstat -nltp : LISTEN 중인 포트 정보 표시 참고: https://cafe24.zendesk.com/hc/ko/articles/9801441063449-LINUX-netstat-%EB%AA%85%EB%A0%B9%EC%96%B4-%EC%83%81%EC%84%B8-%EC%84%A4%EB%AA%85

https://community.spiceworks.com/topic/2128911-nslookup-giving-multiple-ip-for-same-name 위의 링크를 참조함 Multiple A records for a single host lookup is commonly known as round-robin DNS.It is a feature It is related to high-availability and load-sharing Be advised early on that round-robin DNS is at best a mixed-bag. For more information, please consult the following resources: http://www.zytrax.com/..

보통 서비스 게이트웨이(api 게이트웨이)를 이야기할 때 단일 서버로 많이 가정하는 것 같다. 그런 곳도 많을 것 같고.. 하지만 단일 서버로 구성하면 SPOF(Single Point Of Failure)이 되기 때문에 대규모 트래픽 처리에 문제가 있지 않을까? 그래서 오랜만에 다시 책을 읽었더니 아래와 같은 내용을 발견했다. 스프링 마이크로서비스 코딩 공작소에서 내용 펌(p.203) 잠깐, 서비스 케이트웨이가 단일 장애 지점이나 잠재적 병목 지점은 아닐까? 4장 초반부에 유레카를 소개할 때 집중화된 로드 밸런서가 단일 장애 지점과 서비스의 병목점이 될 가능성이 있다고 이야기했다. 서비스 게이트웨이를 올바르게 구현하지 않는다면 동일한 위험 부담이 있다. 서비스 게이트웨이를 구현할 때는 다음을 염두에 두기..

그래들을 사용하다보면 라이브러리가 어떤 디펜던시에 의해 생겼는지 알기가 어려워서 곤란한 적이 많았다. 인터넷 검색 중에 그 방법을 찾았다~!! 아래와 같이 사용하면 된다! ./gradlew dependencyInsight --dependency "junit:junit" --configuration "testCompileClasspath" 위의 예제는 테스트 환경에서 junit 라이브러리가 어디서 가져오고 있는지를 알아내는 명령어다. 나는 Junit5를 사용하려고 하는데 Junit4가 포함되어 있어서 그 원인을 찾고 싶었다. 결과는 아래와 같은 형식으로 나온다. Starting a Gradle Daemon, 1 incompatible Daemon could not be reused, use --status..

echo -ne password123 | base64 echo 옵션으로 -ne를 주고 인코딩할 값을 입력하고 파이프로 base64로 주면 된다. echo -n 옵션은 에코 결과값을 개행하지 않겠다는, 1줄로 표시하겠다는 것이고 -e 옵션은 \t 과 같은 \ 와 사용되는 특수문자?를 인식하겠다는 말이다.

Mattermost 설치 중 sudo docker compose -f docker-compose.yml -f docker-compose.without-nginx.yml up -d 를 사용하라는 부분이 있어서 사용을 했더니 unknown shorthand flag: 'f' in -fSee 'docker --help'. 에러가 발생했다. 도커와 도커 컴포즈 2버전을 써서 생긴 문제인지는 잘 모르겠으나 docker compose 대신 docker-compose 명령어를 사용하면 된다. sudo docker-compose -f docker-compose.yml -f docker-compose.without-nginx.yml up -d

◆ Stateful Firewall과 Stateless Firewall ​ Stateful Firewall과 Stateless Firewall은 일반적으로 Network Firewall로 분류되어 IP 주소와 Port 번호를 기반으로 트래픽을 제어합니다. 그러나, 두 방화벽의 작동 방식은 전혀 다릅니다. Stateful Firewall은 트래픽의 허용 여부를 패킷의 상태와 맥락에 따라 판단하고 Stateless Firewall은 오로지 사용자가 사전에 정의한 정책에 의해서만 판단합니다. ​ 예를 들어, Stateful Firewall은 80번 포트에 대한 요청(Request)이 허용된 경우, 해당 요청과 관련된 응답(Response)은 사용자가 명시적으로 설정하지 않아도 허용합니다. 반면, Statele..

접속하고자하는 클라이언트 서버(src)에서 ssh-keygen으로 개인키, 공개키 생성을 한 후 공개키를 접속하고자하는 리모트 서버(dst)의 특정 유저 계정의 .ssh 폴더에 authorized_keys 파일을 만들 후 공개키들을 한 줄씩 추가하면 된다. 리모트 서버의 .ssh 폴더의 authorized_keys에 클라이언트 서버의 공개키를 넣는다는 것이 의미하는 것 자체가 이 클라이언트 서버의 접속을 허용하겠다라는 것이다. 이 동작을 하려면 리모트 서버에 대한 접근 권한이 있어야 하니깐. ssh와 sftp는 동일하게 포트 22번을 사용한다. (클라이언트 서버): $ssh @ (클라이언트 서버): $ssh ssh-user@ip-1-2-3-4 (클라이언트 서버) $sftp sftp-user@ip-1-2..

음.. 로드밸런서를 통해 목적지에 도달한 request.. 그리고 그 이후에 response가 어떻게 클라이언트로 돌아가게 되는지 궁금했는데 로드밸런서가 바로 ip 위치를 담아서.. request를 보내는 것 같다. ㅎㅎ;; 신기하네. DSR(Dynamic Source Routing protocol) - 서버에서 유저에게 돌아갈 때 로드밸런서는 네트워크 스위치를 거치지 않고 바로 클라이언트로 찾아갈 수 있게 클라이언트 IP를 전달해 줍니다. ​ [출처] 로드밸런서(Load Balancer)란 무엇인가?|작성자 rlagnlwls0127

https://repost.aws/ko/knowledge-center/route53-private-hosted-zone Route 53 프라이빗 호스팅 영역을 다른 AWS 계정의 VPC와 연결 Amazon Route 53 프라이빗 호스팅 영역을 다른 AWS 계정에 속한 Virtual Private Cloud(VPC)와 연결하고 싶습니다. repost.aws AWS CLI로만 연결이 가능하고 연결된 것은 AWS Route53의 프라이빗 도메인의 호스팅 세부영역에서 확인 가능하다. --- 0 Amazon Route 53 프라이빗 호스팅 영역을 다른 AWS 계정에 속한 Virtual Private Cloud(VPC)와 연결하고 싶습니다. 해결 방법 다음 해결 방법에서는 다음 옵션 중 하나를 사용하여 명령을 ..

좀 된일이라 기억이 잘 나지 않는데.. 기억을 되살려거 기록으로 남겨 놓으려고 한다. 일단 시간이 없어서 답변 받은 것만 남기고 나중에 상황을 다시 정리해보자. 서버간 통신은 내부통신으로 외부접근용 ALB를 타지않기때문에 EC2에 SG로 오픈해줘야 합니다. 도메인으로 호출을 위해서는 기존 ALB가 아닌 private ALB를 생성해야하고, 도메인또한 내부호출용 도메인을 새로 따서 할당해 주어야 합니다. 서버간 접근은 현재 내부ip(10.x대역)로 해야하고 도메인으로 호출이 필요할경우 별도 내부lb와 내부도메인을 따서 진행해야합니다.

case 문을 if문으로 실행하면 flyway 마이그레이션이 되는데 https://dev-handbook.tistory.com/90 [MariaDB] MariaDB 10.1, 10.2 시퀀스 기능 구현 cafe24에 포팅 작업을 하면서 DB는 MariaDB로 알고 비교적 최근 버전의 안정화 버전을 사용을 해서 포팅 작업을 진행했습니다. 원래는 포팅 하려는 시스템의 환경과 소프트웨어의 버전을 정확하게 dev-handbook.tistory.com 위의 링크대로 routine의 top과 bottom에 DELIMITER // // DELIMITER ; 위 처럼 넣어주니 잘 동작한다. flyway의 문제가 아니라 mariadb의 문제인가? 흠.. 둘의 호환성 문제인가.. ㅎㅎ

VPC ->Transit Gateway -> Transit Gateway 라우팅 테이블 에서 서로 연결이 되어있는지 확인을 해보자.

아래와 같습니다. -- 현재 연결된 커넥션 수 show status like 'threads_connected'; -- 허용하는 최대 커넥션 수 show variables like 'max_connections';

인증키 준비하기(***.pem 파일) 적당한 경로로 옮기고 파일 접근권한 강화하기 chmod 600 ***.pem emr 접속하기 (여기서 ip주소는 aws emr 에서 보이는 마스터 주소) ssh -i hadoop@10.10.10.10 아래의 명령어를 치면서 변경한 스크립트 이름 뜰 때까지 반복하기(더 효율적인 방법이 있을텐데 흠) yarn application -list 해당 스크립트가 실행 완료된 다음에 아래 과정에서 로그를 떠야 제대로 된 로그가 보임(스크립트 실행 완료에는 시간이 어느 정도 걸림) 로그 보기 앞서 구한 Application-Id를 이용해서 파일로 만들고 vim 등의 툴로 내용을 보자. yarn logs -applicationId= > 그리고 vim 내에서 /를 누르고 검색할 단어..