썰렁한 엔지니어

이 글을 읽기 위해서는 공용서버에서 github, bitbucket 사용하기(1)을 읽어야한다. GIT 사용자 정보 포워딩 공용장비에 로그인할 때 git 사용자 정보도 매번 설정하는 것도 귀찮을 때가 있다. 물론 자신의 계정이 있다면 .gitconfig에 설정하여 사용하게 된다. 그러나 공용계정을 사용하는 경우라면, 환경변수로 GIT_AUTHOR_NAME, GIT_AUTHOR_EMAIL 을 설정하여 사용해야한다. 환경변수 설정조차 공용 계정이므로 쉽지 않을 수 있다. 이 때는 이 두 변수를 PC에서 설정하고 ssh 접속할 때 전달 할 수 있도록 설정하면 된다. 서버에서는 받을 준비를 해야하므로 다음과 같이 설정한다. /etc/ssh/sshd_config 에서 AcceptEnv GIT_* 한 줄을 추가한다..

만약 맥 사용자라면 ssh-agent 편을 먼저 읽는 것이 좋다. Ssh 로 git repository 사용 서버에 접속 할 때 비밀번호 없이 인증하기 위해서는 공개키 방법을 사용하며, 조금 더 나아가서는 ssh-agent/ssh-add 조합으로 공개키를 사용한다. 공개키를 사용해 왔다면 ssh-agent / ssh-add 조합은 어려운 것이 아니다. github, bitbucket에 계정이 있고, 현재 사용중인 계정의 공개키를 서비스에 등록하였다면, ssh access git repository 편에서 소개한 대로 다음과 같이 접근가능하다. $ ssh git@github.com PTY allocation request failed on channel 0 Hi coolengineer! You've suc..

git repository 서비스를 제공하는 bitbucket, github, gitlab 등은 ssh key를 등록하여 사용한다. 내 ssh-keygen으로 생성한 비밀키/공개키 쌍 중에서 공개키에 해당하는 ~/.ssh/id_rsa.pub 파일의 내용을 복사해서 등록하는 방식이다. 그리고 ssh 로 해당서비스를 접근할 때, 사용자 이름을 git 으로 하면, 서비스에 가입한 ID를 화면에 출력하고 바로 접속을 끊는다. 아래 예에서는 "exampleuser" 로 가입했을 때 나오는 모습이다. $ ssh git@bitbucket.org PTY allocation request failed on channel 0 logged in as exampleuser You can use git or hg to conn..

ssh-keygen 서버에 접속하여 개발하는 사람들은 하나의 서버만 접속하는 일은 별로 없다. 또한 서버를 여러 단계를 거쳐 접속하는 경우도 많다. ssh (혹은 rsh 시절부터) 기반의 접속은 다음과 같은 편리함/불편함의 역사를 가지고 기능이 추가되어 왔다. 매번 비밀번호를 입력하는 것이 귀찮다. -> 인증된 서버에서 접속하는 것을 허락해 주시오 (.rhosts, .shosts) 인증된 서버가 취약하면 같이 취약하다 -> 인증된 사용자임을 증명(공개키)하면 접속을 허락해 주시오 (ssh-keygen) 인증된 사용자의 디렉토리의 비밀키 탈취가 가능하다. -> 비밀키를 passphrase를 넣어서 생성하시오 (ssh-keygen) passphrase 를 매번 입력하는 것이 귀찮다(1번!) -> 개인키 캐시..

시계 부품 중에서 엔진에 해당하는 "무브먼트"라는게 있다. (movement라니 이름이 너무 평범해서 마음엔 안들지만) 웬만해서는 분해를 해도 이것만큼은 안건드리는데, 이 부품을 억지로 분해 했다가는 그 안에 있는 톱니들이 와장창 제자리를 잃고 다시 조립하는것은 쉬운일이 아니기 때문이다. 그런데, 벽걸이나 탁상 시계는 건전지 가는 것 정도만 하다가, 시계바늘이 뭔가 정확히 12시에 만나지 않는다거나 알람을 1시에 맞췄는데 2시에 울린다거나 하는 정도가 되면 앞 유리 면을 열어야하는 정도의 분해는 해야한다. 시계 바늘이라는 것은 단지 중앙에 나와 있는 동심원 3개에 고정되어 있는 것이고, 바늘을 뽑고 다시 각도를 맞춰서 다시 꽂을 수 있으므로 이 정도만 알아도 일상을 살아가는데, 큰(?) 도움이 된다. 오..

법률이 제정되고 시행령, 시행규칙이 만들어지듯이 프로그램의 운영관점에서 보면, 법률은 프로그램과 같고, 시행규칙은 설정파일과 같다. 법률과 달리 소프트웨어에서는 시행규칙에 들어가야할 것이 프로그램에 들어가는 일이 많다. 운영 중에서 조정해야하는 시행규칙을 지원하는 프로그램 수정보다, 프로그램내에서 로직으로 바로 해결하면 간단하기 때문이다. 또, 설정 값으로 빼는 것이 굳이 이번 한 번만을 위한 것인데, 조금 거추장스러운 추상화 아닌가 싶기도 하다. 문제는 한참 뒤에 나타난다. 전체적인 프로그램의 추상화 레벨이 마구 섞여 있는 코드를 마주할 때 느끼는 가독성의 문제. 만약 추상화 단계가 다른 코드를 불가피하게 작성해야할 때는, 변명이라도 잘 써 놓을 수 있다면 좋겠다. 나중에라도 쉽게 고치게. -End-

도메인 소유기록을 찾아 보려고 domain history로 검색해 보니, whois 자료를 다 모아서 API로 제공하는 곳이 있더라, 많더라. 난 단지 도메인 한 개 알아 보고 싶었다만... https://whoisrequest.com/ Whois Search, Domain History, Reverse IP/NS Lookups and more Lookup IP, CIDR, ASN or Domain whoisrequest.com 이 사이트에서는 소유자는 공개하지 않고 누군가 사용했는지만 확인해 볼 수가 있다. 그나마 하나 찾아서 메모차 적어 둔다. 둘째 딸 낳고서 이름으로 도메인을 하나 2년간 구매하고, 만료시점에 4년을 더 연장을 해서 총 6년을 보유하고 있다가 어떤 이유에서인지, 연장을 안했다. 그리..

서버를 만들고, 여러 테스트하는 것 중에 영구 접속이 끊어지는 상황을 재현하는 것은 쉽지 않을 수 있다. 디버거를 이용하여 간단히 종료시켜 보는 법을 알아 본다. python으로 돌고 있는 데몬(pid 11688)이 있다고 하고, 데몬의 DB 접속은 영구 접속에 해당하는데, 이 접속을 강제로 종료시키는 것을 가정한다. $ lsof -n -p 11688 COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME python 11688 pynoos cwd DIR 202,3 80 1636949 /misc/django_projects/app/broadcast python 11688 pynoos rtd DIR 202,3 4096 128 / python 11688 pynoos txt..

django로 만든 웹 서버가 메모리 릭이 있는 것 같아서, 임시로 클라이언트 요청 수에 제한을 걸고 새로 실행되도록 설정했다. 임시가 길어져 1년이 돼가는 동안 잊고 있다가 개발자의 자존심을 건드는 설정인지라 다시 봐야했다. 이 글은 메모리 릭을 잡았다는 것이 아니다. 서버들 중 적당히 스왑을 사용하고 있는 녀석을 골라서 들어갔다. gunicorn 들 중에 제일 pid가 큰 것을 골라낸 후, 해당 PID 에 strace 를 걸어서 GET/POST와 URL PATH에 해당하는 것만 출력하도록 awk 파이프 질을 했다. 동시에 "ps -efl" 로 해당 PID만 골라낸 다음 awk로 적당히 메모리 사용량 부분만 출력한다. 대략 512 개의 요청만 하면 사라지는 gunicorn의 PID이므로, 위 두 작업을..

늪, 사람은 뭔가에 빠지기 마련이다. 하다 못해 게으름에 빠지기도 한다. 그 순간조차 그 상태를 유지하고 싶다. 너무 오래 머물면 안될 것을 알면서도 계속 유지하다가 적응하게 된다. 늪을 나오기 위해, 용기란 것이 가끔 필요한 것임에도, 그 생각이 드는 순간조차 그 속에서 뭔가 더 할 수 있을 것 같은 생각이 동시에 든다. 이것은 늪 속에서 주기적으로 엄습하는 목소리와의 결말 없는 전쟁같은 것이다. 늪, 이 점성 고형물이 꿀인지 진흙인지는 상관이 없다. 결국엔 그것외엔 할 수 없는 것이 그 안에서 사는 모습이다. 새로운 것을 추구하자, 죽기 전에 꼭 해야할 일을 시작하자, 돈을 많이 벌어야지 하고 싶은 것만 할 수 없지 않느냐. 이런 고민은 30대에 끝날 줄 알았지만, 지금보니 늙어서 죽는다고 해도 계속..