걱정이 이래저래 많았는데 다행히 꽤 괜찮은 점수로 합격해서 후기를 남기고자 한다. 바우처 만료1회차 응시 때는 무선랜 환경의 스터디룸에서 시험을 보았다가 30분도 안 되어 튕겨버리는 바람에 낭패를 보았다.다행히 지라 티켓을 올려 취소했으나 이후로 흐지부지 미뤄 바우처 만료일 마지막 날에 응시했다.이번에 떨어지면 아예 만료되는 건 아닌가 하고 걱정했는데 1회차 시험을 취소할 수 없는 당일이 되고 나니 바우처 일정이 한 주 자동으로 밀렸다.아마도 기회 2회를 전부 소진하지 않으면 자동으로 1주일 정도는 미뤄주는 모양이다(물론 1회차를 응시한 후의 2회차를 볼 때의 전제).다행히 시험은 바로 붙어서 두 번이나 볼 일은 없었다. 1회차 시험 환경나는 두 번 다 스터디룸에서 응시했는데, 1회차 때 막연히 적당한 ..
https://docs.gitlab.com/runner/install/linux-repository.html [Install GitLab Runner using the official GitLab repositories | GitLab다음 절차에 맞춰 세팅한 후, 깃랩 project > CI/CD > Runners에 들어가 token을 받아 세팅해준다.해당 에이전트가 설치된 서버의 'Gitlab-Runner' 사용자는 ssh 등의 키를 갖고 있지 않으므로다음 설정을 추가해 ssh key를 사용할 수 있도록 만들어준다.before_script:- eval $(ssh-agent)- echo "${SSH_KEY_SECRET_8}" | ssh-add -- mkdir -p ~/.ssh또한 다음 명령어를 추가해 g..
server { server_name test.test.co.kr; listen 80; proxy_read_timeout 3600000; proxy_send_timeout 3600000; location / { # proxy_set_header Host $host; # proxy_redirect http://localhost:3000 http://test.test.co.kr; proxy_pass http://localhost:3000; proxy_set_header Host "http://test.test.co.kr"; ..
맨 페이지는 cd와 같은 쉘 내장 명령어에 대한 매뉴얼은 제공하지 않음.npm과 같이 외부에서 제공하는 소프트웨어의 경우도 마찬가지임맨 페이지에서 대괄호는 Optional을 상징> type npm npm is /home/octavesop/.nvm/versions/node/v18.14.0/bin/npmtype 명령어는 특정 명령어의 위치를 알려준다.alias인 경우 alias라고 출력해줌> which clear/usr/bin/clearwhich 명령어도 마찬가지긴 함help 명령어를 쓰면 cd, pwd, echo와 같은 쉘 빌트인 명령어들의 도움말도 확인해볼 수 있음 윈도우 체제에서는 물리적 / 논리적으로 드라이브가 분리되어있음. ex) C드라이브, D드라이브...그러나 ..
ssh ssh -t는 해당 쉘에 직접 접속해 명령어를 입력하는 대신 매개변수로 커맨드를 실행하는 방법이다. 다음과 같이 사용할 수 있다. $ ssh test@test.com -t "npm install" 그러나 막상 명령을 실행해보면 제대로 동작하지 않을 것이다. command not found 오류가 뜨게 되는데, 막상 직접 접속해서 사용할 때는 해당 문제가 발생하지 않는다. 왜 발생하는가 단순히 말하자면, 이는 .bashrc의 실행 여부와 환경 변수인 PATH의 문제에 의해 발생한다. ssh -t 명령어를 실행할 때, 사용자의 권한은 ssh 키나 패스워드를 통해 검증되나 실제로 로그인 세션은 발생하지 않는다. 때문에 원격 접속과는 달리 빠르고 편리하게 명령어를 실행하는 것이 가능해지므로, 주로 크론잡..
> sudo vim ~/.bashrc 마지막 줄에 다음 명령어를 추가한다. export HISTTIMEFORMAT="%Y-%m-%d %H:%M:%S " 적용되지 않았다면 한 번 로그아웃하고 다시 접속하자. 적용 시 이전의 명령어는 적용된 시간으로 표기되며, 이후 명령어부터는 입력된 시간값이 추가되어 출력된다.
$ sudo usermod -aG docker $USER $ sudo su - $USER $ groups $USER
배포 환경이 여의치 않은 경우 종종 연결 확인을 위해 일단 로컬로 붙여보자고 제안하는 경우가 있다. 어째 이럴 때마다 로그인이 종종 발목을 잡는데, 대개는 credentials 내지는 cookie 세팅이 원인이다. cookie 설정인 secure나 samesite 등은 독립된 성질이 아니라는 점이 더욱 그런 것 같다. 이 기회에 기록을 좀 해두어야겠다. secure 쿠키를 암호화된 방식으로 보낼 것인지에 대한 인자이다. 이 암호화는 SSL 계층을 통해 진행되므로, https 방식으로 통신하지 않으면 true로 설정했더라도 적용되지 않는다. 또한 sameSite=none은 secure가 true일 때만 적용된다. httpOnly 브라우저 단에서 쿠키에 접속하는 것을 제한하기 위한 설정이다. true로 설정..
