This week I Learned 11

주영택·2020년 3월 16일

TIL

This Week What I Learned

목록 보기

9/50

Find 와 명령어 조합

find 명령은 파일을 찾아주는 것 외에 찾아낸 파일에 대해 추가로 명령을 실행해주는 기능을 가지고 있다.

-exec 옵션으로 사용 가능하고 fd 의 경우는 -x 와 -X 를 통해 수행할 수 있다.

빈 서브 디렉토리를 찾아서 삭제하기

-exec 옵션을 사용해도 되지만 GNU 버전의 find 에는 빈 폴더를 찾아주거나 검색된 대상을 삭제해주는 옵션도 있다.

$ find . -type d -empty -delete

자주 쓰는 alias

# find empty directories
alias find-empty='find . -type d -empty'

# fine empty/zero sized files
alias find-zero='find . -type f -empty'

# delete all empty directories!
alias find-empty-delete='find-empty -delete'

node_modules 폴더만 찾아서 삭제하기

$ find . -name 'node_modules' -type d -exec rm -rf '{}' +

마지막에 붙은 + 연산자는 다음 링크를 참조하자.

이제는 상식적인 선에서 이해하기 힘든건 구려보인다...

구글 클라우드 서비스 한국 리전

총 3 개의 리전이 생성되는데 A, B, C 로 구분하면.

A: 경기권 (아마도 안양이나 과천)
B: 세종권 (오창 IDC 가 있으니 그 쯤 아닐까...)
C: 경남권 (부산)

리전 이동 관련

구글 클라우드 서비스는 Cross Region 레플리케이션 이라고 불리는 데이터베이스 레플리케이션 서비스를 준비하고 있는 걸로 보인다.

WAS 를 먼저 옮기고 DB 를 replication 할지 또는 반대로 할지 시뮬레이션 해 볼 수 있으면 좋겠다. 아니면 서버 내리고 둘 다 처리할지...

데브 서버, 스테이징 서버의 WAS 를 한국 리전으로 이동
한국 WAS ←→ 일본 DB 와 접속 상태 확인

이 정도 먼저 시행 해본다.

Nginx 프록시 서버 세팅 주의

구글 SAML Bearer 토큰 인증 과정 중 프록시 서버 세팅을 잘못하게 되면 인증이 두 번 호출되고 처음 인증은 실패, 그 다음은 성공으로 동시에 진행되면서 결국 SSO 실패하는 경우가 발생하는데 한 시간 정도 삽질하면서 추적.

verify: {
  issuer: 'https://accounts.google.com/o/saml2?idpid=C03v6vgo9',
 ...
  getAssertionXml: [Function (anonymous)],
  getAssertion: [Function (anonymous)],
  getSamlResponseXml: [Function (anonymous)]
} +52ms
staff already connected!

위 처럼 구글을 통한 SSO 가 정상으로 끝났지만 인증 토큰을 검수하는 과정에서 invalid 발생한다.

500 error Error: invalid token
    at verify (/shared/auth/bearer.js:99:9)
    at Immediate.<anonymous> (/shared/auth/bearer.js:110:5)
    at processImmediate (internal/timers.js:456:21) {
  method: 'GET',
  path: '/auth/tokens',

지금 서비스는 토큰 생성을 접속한 기기의 IP 와 agent 정보 일부를 사용하는데 이 데이터가 접속 토큰을 발행한 정보와 일치하지 않는 경우가 생긴다.

{
  token: '72e57a9b2f554e69e4bfd992e460170f507fb10',
  data: '::1\n' +
    'Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:74.0) Gecko/20100101 Firefox/74.0'
}

같은 호출 다른 내용

{
  token: '72e57a9b2f554e69e4bfd992e460170f507fb10',
  data: '::ffff:127.0.0.1\n' +
    'Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:74.0) Gecko/20100101 Firefox/74.0'
}

여기까지 오니 '아, 프록시 문제구나...' 싶더라.

proxy_set_header host $host;
proxy_set_header x-real-ip $remote_addr;
proxy_set_header x-forwarded-for $proxy_add_x_forwarded_for;
proxy_set_header x-forwarded-proto $scheme;

MySQL 타임존 세팅이 안된 경우

맥에서 brew 로 설치한 mysql 서버는 타임존 세팅이 되어있지 않은 문제가 있다.

$ cat /usr/local/etc/my.cnf
# Default Homebrew MySQL server config
[mysqld]
# Only allow connections from localhost
bind-address = 127.0.0.1
mysqlx-bind-address = 127.0.0.1
default-time-zone='+00:00'

타임존을 UTC 로 넣어주면 적당히 작동한다. 물론 재실행 해주어야 적용된다.