에 대한 고민을 하고 있다. 그러면서 우연히 찾게 된 글. 아직 잘 모르지만 참고할만 할 듯 하다. Felix's Node.js Convincing the boss guide
Chrome에서 flash 충돌 문제
환장한다. Chrome을 쓰다 보면 페이지가 무한 로딩되며 반응이 없다가 "플러그인(Shockwave Flash)이 응답하지 않습니다"라는 문구가 나타나는 현상이 종종 발생한다. 처음에는 그냥 reboot을 했다. 브라우저 때문에 말이다. 그러면 문제가 해결되는 것처럼 보였다.
하지만 그런 현상이 반복되면서 짜증이 나더니 '사람들은 대체 왜 flash를 페이지에 넣어두는걸까?' 라는 생각까지 하게 되었는데, 더이상 그냥 둘 수는 없어서 원인을 알아봤다.
우선 동일한 문제가 Firefox에서는 발생하지 않는다. (IE는 비교하고 싶지 않다) 많은 사람들이 얘기하고 있는 원인은 Chrome 내장 flash plugin과 Windows에 있는 flash가 충돌을 일으키기 때문이라는데 정확한지는 알 수 없다. 하지만 그들의 말대로 Chrome 설정에서 내장 flash plugin은 사용하지 않게 바꿔두었더니 문제는 사라져버렸다.
Gerrit을 쓰면서도 느꼈던 거지만 Google이 한다고 해서 또는 Google에서 만들어진 거라고 해서 문제가 없는 것은 아닌 것 같다. 그러므로 맹신은 금물.
참고로 경험해보니 Chrome 설정을 바꾼다 하더라도 어느 순간 원복된다. (왜?) 어떤 사람은 아예 내장 plugin 파일을 지우기도 했다고.
SSH에서 사용하는 key 선택하기
이리저리 하다보니 ssh에서 사용할 key를 여러쌍 생성하게 되었다. 이 때 필요에 따라 key를 선택해서 사용해야 한다. (매번 새로 생성하고 복원하고 할 수는 없으니까) 단순히 ssh command를 사용해도 되는 상황이라면 i 옵션을 사용한다. (identity file) 예를 들어 /home/id_dsa 라는 경로와 이름으로 private key가 존재하고 있고, test 계정으로 example.com 서버에 접속하려 한다면, [bash] ssh -i /home/id_dsa -l test example.com [/bash]
이렇게 key를 선택적으로 사용하지만 고정적으로 사용해야 할 때, 예를 들어서 GIT 저장소에 접근할 때 ssh로 해야 하고 일반적이지 않은 key(~/.ssh/id_rsa가 아닌)를 사용해야 한다면 ~/.ssh/config 파일을 수정해서 이용할 수도 있다. config 파일에 아래와 같은 내용을 추가한다. [bash] Host example.com IdentityFile /home/id_dsa [/bash]
끝.
Node.js 익히는 중
널뛰듯 장르를 넘나드는 업무 속에서 뭐라도 하나 지속적으로 하자는 생각에 Node.js를 공부하고 있다. 이틀.
다른 시간은 쓰기가 어려워서 점심시간에 말이다.
비동기식 이벤트를 이용하기 때문에 뭐가 좋고 나쁘고 이런 얘기들은 아직 체감되진 않는다.
아직 대규모 요청을 처리하거나 해본 적이 없기 때문에.
정말 신기했던건 다음 몇 줄로 브라우저에서 request가 들어올 때 마다
Hello World를 찍어 보여줄 수 있었다는 것이다.
웹서버를 돌리지도 않았고 단지 node.js 설치와 몇 줄 써주고 실행한게 전부였을 뿐이다.
var http = require("http");
http.createServer(function(request, response) {
response.writeHead(200, {"Content-Type" : "text/plain"});
response.write("Hello World"); response.end();
}).listen(8888);
이걸 익혀서 Jenkins job 상태를 보여주는 서비스를 만드는 것을 목표로 하기로 했다.
기간은 2주 정도. 물론 점심시간만.
설치는 official page에서 간단하게 가능하고
보고 있는 자료는 누군가 친절하게 번역해 놓은 node beginner page.
Eclipse plugin도 있는데 아래 주소를 추가하면 Node Project / File 생성이 가능하다.
Jenkins job status 확인
Jenkins monitoring을 매일 해야하는데 열어야 하는 페이지가 많다면 어떻게 해야 하는가?
상당히 귀찮다. 단순 반복이기도 하고.
특별히 문제가 있는 경우는 별로 없지만 그래야 안심이 되어서 매일 아침마다 하고 있는 상황이다.
한 눈에 파악할 수 있는 monitoring page를 간단하게라도 만들어볼까 하는 생각에 우선 각 서버들에 퍼져있는 job의 status 확인이 가능한지 알아봤다. (RSS도 되는데 없을리가...)
아래의 주소를 curl이나 wget으로 실행하면 xml 형태의 data가 날라오게 되고 마지막을 xml 대신 json으로 변경하면 json 형태로도 data를 받을 수 있다.
http://{your_ip}/job/{your_job}/api/xml
나의 경우엔 job에 대한 여러 정보 중에서 마지막 job에 대한 것만 필요하기 때문에 아래와 같은 url을 던졌다.
http://{your_ip}/job/{your_job}/lastBuild/api/xml
위에 대한 결과로 아래와 유사한 형태의 xml data를 확인할 수 있다.
<freeStyleProject>
<displayName>{your_job_display_name}</displayName>
<name>{your_job_name}</name>
<url>{your_job_url}</url>
<buildable>true</buildable>
<color>grey</color>
<inQueue>false</inQueue>
<keepDependencies>false</keepDependencies>
<nextBuildNumber>1</nextBuildNumber>
<concurrentBuild>false</concurrentBuild>
<scm></scm>
</freeStyleProject>
이제 xml이나 json으로 된 재료는 있으니 어떻게 요리하느냐가 남았는데, 재미있을 듯 하다.
시간과 여유를 낼 수 있느냐가 문제.
Gerrit의 문제점들
Gerrit을 처음부터 설정해 사용하면서 느끼는 문제점들이 몇가지 있다.
1. 사용자 추가
Gerrit 설정시 로그인과 관련해서 지원하는 몇 가지 방법이 있다.
그 중 OpenID와 LDAP을 가장 많이 쓸 것이라고 생각하는데 우리네 환경에서는 OpenID를 사용하기가 힘들다. (보안 이슈)
그래서 AD 서버와 LDAP으로 연결해서 쓰고는 있는데 이것 이외에 UI 조작으로 사용자 계정 추가를 할 수 있는 방법이 없다.
Command line 으로는 사용자 계정을 추가할 수 있는데 이것도 문제가 좀 많다. (뒤에 언급)
2. 사용자 삭제
UI 상에 사용자 계정 추가가 없기 때문에 삭제 역시 없다.
3. Command Line Interface
먼저 계정 생성 command인 create-account.
생성은 된다. 하지만 생성이 제대로 되었는지 response가 없다.
무반응이면 제대로 되었나보다 생각하면 되는데 password 설정이 안된다.
http-password 라는 옵션이 있어서 거기에 password를 넣으면 되나 싶었는데 로그인하면 되질 않는다. (이것은 로그를 충분히 확인해볼 필요가 있겠다 싶은데 아직은 로그 확인 전)
create-account의 옵션 중에 있는 group은 공백을 인식하지 못하는 것으로 보인다.
큰따옴표로도 묶어봤으나 여전히 인식이 안된다.
add-ssh-key 옵션이 있는데 인자로 파일명을 주면 안된다.
지금까지 확인한 바로는 stdin만 먹는 것으로 보인다.
멋진 사용자 계정 삭제 command.
유감스럽게도 없다.
여기저기 찾아보면 inactive로 만들라고 권고하는 것 같은데 inactive는 로그인만 못하게 막는 것이지 계정을 지우는게 아니기 때문에 만약 짜증 나는 계정 foo를 삭제하고 다시 만들려고 해도 안된다. foo2 등의 이름으로 다시 만들 수 밖에.
이해 안되는 set-account.
계정 삭제가 안되니 이리저리 다시 세팅해서 계정을 쓰려고 했는데 재미있는 사실을 발견했다.
바로 add-ssh-key와 delete-ssh-key 옵션에서 문제를 발견했는데 이미 추가한 ssh-key를 지우려고 편하게 delete-ssh-key ALL (ALL은 제공하는 값이다. 해당 계정의 모든 ssh key를 지우라는)을 입력했는데 역시나 response 없이 command가 실행되었다. 그래서 문제없겠거니 생각하고 add-ssh-key로 새로운 ssh key를 추가했는데 역시나 no response. 제대로 설정 되었는지 확인하려고 ssh key 삭제 전에 잘 되던 저장소 clone을 해봤더니 public key 문제로 불가. ssh key를 다시 만들고 별 쇼를 다 해봐도 안된다. 또 다른 계정 xxx2 등으로 또 만들어서 쓸 수 밖에.
4. 관리자 계정
왜 그런건지 모르겠지만 갑자기 오늘 오전부터 관리자로 설정되어 있던 내 계정이 관리자가 아닌 걸로 인식을 하고 있었다.
도저히 알 수가 없어서 db를 다시 만들어서 설정했다.
결론
현재까지의 상태들을 종합하면 gerrit은 계정관리 부분이 취약하다. 뭔가 대단히 불편한데, 불편한 건 이해하고 넘어가더라도 원인을 파악할 수 있는 수단이 거의 없어서 해결할 방법을 찾기가 힘들다.
참고로 이 모든 현상이 만들어지고 있는 gerrit의 버전은 무려 2.5.1이다. 1.0도 아니고 1.5도 아니다.
구글 내부적으로 쓰는거라 그런건지도 모르겠지만, made by Google 이라고 맹신해서는 안된다는 걸 느낀다.