Yonghwan's Blog

얼마 전부터 작은 오픈소스 프로젝트를 하나 (업무로써) 진행하고 있는데^[각주:1], 공부도 할 겸, 프로젝트의 웹 부분을 Django 프레임웍을 사용하여 작성하고 있다. django는 뭐랄까... 아쉽게도 ruby on rails를 처음 접했을 때 만큼의 감동은 없는데, 나름대로 단순한 면도 있고 쓸만 하다는 느낌이다. (MVC 관점이 좀 애매하기는 하다.)

그러던 어느 날, 문제가 생겼다! 그것도 하필 중간 점검을 코앞에 두고 말이다.^[각주:2] (항상 "밀려 하는 숙제" 스타일이 문제다.) 잘 동작할 것으로 예상했던 부분이 안돌아 가는데, 곰곰히 생각해보니... nested request! 이것이 문제였다. 문제의 부분은 사용자-시스템 간의 요청 처리 내부에 시스템-시스템 간의 요청이 하나의 단계로써 포함되어 있었던 것이다. 다시 말해서, 사용자의 요청(ㄱ)을 완료하기 위해서는 내부적으로 또 하나의 웹 요청(ㄴ)이 발생하게 되는데, 그것(ㄴ)이 처리 지연에 빠지는 현상이 발생했다. 처리 지연에 빠지는 이유는 바로 앞 선 요청(ㄱ)에 의하여, 이 요청의 수행이 끝날 때 까지 웹서버의 동작이 Blocking 되어 있었던 것. 데드락이다. (ㄱ)은  (ㄴ)의 수행이 필요한데 (ㄴ)이 수행되기 위해서는 (ㄱ)이 먼저 끝나줘야 하는 것. ... 지금껏 잘 사용해오던 django의 내장 (test용) 서버가 다중 요청을 지원하지 않는 것이다. (이 부분은 좀 더 확인이 필요하다.)

사실, 처음부터 내 잘못이다. django의 문서를 보면 명시적으로, "이 기능은 실무 환경을 위한 것이 아니에요. 우린 웹 개발 프레임웍을 만드는 중이지 웹서버는 관심이 없답니다."라고 말하고 있다. 어쨌든, 다음의 연결은 이와 관련하여 django를 다른 전문 웹서버와 연결하는 방식을 설명하고 있다. (이 부분도 rails에 비해서 좀 떨어지게 느껴지는, 또는 낯설은 부분 중 하나다.)

관심있는 구성 중 하나는 경량 웹서버인 nginx를 이용하는 방법. 다음은 우분투 문서 중, byteflow blog 엔진 설치, 그 중 django(FastCGI) + nginx 구성의 설명이다.

byteflow blog engine - Ubuntu Wiki

Byteflow is a blog engine, written on Python, using Django. Why should you choose it over competitors? It has very clean codebase and developers, which are struggling to keep it so. It has a lot of cool features, which you can't get in other blog engines or will get with difficulty (consider feed by union of tags, eh?).

# Ubuntu + nginx + FastCGI installation guide on Ubuntu wiki
# Debian + apache2 + mod_python. Installation and setup guides by Oleg Leschinsky.
# lighttpd + fastcgi installation guide from Benjamin Smith
# Installing byteflow on dreamhost by William Stearns
# ByteFlow on CentOS 5 with Apache, mod_wsgi and MySQL by Michal Ludvig

django 공식 문서. 일단은 공식 문서의 apache+django(fastcgi mode) 방식을 적용하여 문제(다중 요청 처리)를 해결했다. 이렇게 단순 간단한 것을... 처음엔 원인을 떠올리지 못하고 심지어는 별도 Job Queuing 모듈까지 만들었다는...

Django’s chock-full of shortcuts to make web developer’s lives easier, but all those tools are of no use if you can’t easily deploy your sites. Since Django’s inception, ease of deployment has been a major goal. There’s a number of good ways to easily deploy Django:

교훈:

• "밀린 숙제 방법론"을 버려라
  
• "실전을 통한 학습"은 허상이다.
  
• 문서와 저자의 의도를 받아들여라.
  
• 뭔가 분명히 있다. 만들기 전에 다시 한 번.
  

예전엔 기본이었던것 같은데, 이젠 설정을 따로 해야 하는 것이 되어버렸다. telnet://localhost 이런거 말이다. 그것도 꽤 복잡해졌다.

URL에 telnet://hostname을 입력하면 나타나는 경고창 (firefox)

요즘 진행하고 있는 프로젝트 중 하나에서 이 기능을 사용한다. 그래서 간만에 들여다봤다.

* IE7, 활성화하기와 프로그램 지정하기

IE7에서는 아래의 레지스트리 설정(enable-telnet-ie7.reg)을 통하여 telnet 프로토콜 처리를 활성화할 수 있다. 활성화가 되면 기본 처리기인 windows 내장 telnet 프로그램과 연결된다. 그런데 이 기본 telnet 프로그램이라는 것이 그다지 이쁜 녀석은 아니라서 뭔가 다른 설정으로 들 바꿔 쓰게 되는데, 그 작업 역시 레지스트리 설정을 이용하여 할 수 있다. (telnet-handler-putty.reg; 이 설정은 Windows용 공개소프트웨어 터미널 에뮬레이터인 putty를 예로 하였다. 원래대로 돌리려면 telnet-handler-default.reg)

enable-telnet-ie7.reg

telnet-handler-default.reg

telnet-handler-putty.reg

* FF3, 프로토콜 처리기 설정하기

이게... 좀 복잡해졌다. 예전엔 about:config 에서 끝났던 것 같은데... 아무튼, 깔끔한 방법이 없다.

첫번째로 사용 가능한 방법은, 먼저 about:config로 가서(브라우져의 Location 입력 부분에 이렇게 써넣으라는 얘기) "protocol" 등으로 필터링을 해본다. 그러면 몇몇 보기가 나오는데, 그와 유사하게 "network.protocol-handler.app.telnet"라는 문자열 키를 하나 만들고 저장한다. (이상한 일인데, 여기서 값으로 뭔가를 입력하는 것이 무의미하다. 어떤 의미에서 무의미한지 궁금하다면 telnet을 처리하기를 원하는 프로그램을 이 곳에 써 넣어보면 된다.)

그리고 이런 식으로 시험해본다.

(프로토콜 처리기로 지정한 것이 있다면) 지정한 프로그램이 뜨기를 기대했건만,

그런데 이게 왠 대화상자? 헨들러를 지정했음에도 다시 어떤 것을 쓰겠냐고 묻는다. 그래서 "아... 어떤건지는 알겠는데 계속 쓸건지를 묻나?" 하고 "...기억합니다."에 표시하고 "확인"을 누르면 아무런 동작도 이루어지지 않았다. 그래서,

이렇게, 대화상자에서 "실행 프로그램 선택"을 이용하여 아까 입력한 그 프로그램을 다시 지정하면 이번엔 정상적으로, 그리고 반복적으로 해당 프로그램을 외부 프로토콜 처리기로 쓸 수 있게 된다.

좀 이상하지만 더 깊이 따지지는 않겠음.

그런데 어떤 프로그램을 지정할 것인가? 다음의 python 스크립트는 이를 위한 예이다.

#!/usr/bin/python

import sys
import os

try:
    url = sys.argv[1]
    argument = url.split('/')[2].split('@').pop().replace(':', ' ')
except:
    print "url parsing error."
    quit()

command = "xterm -e telnet %s" % argument
os.system(command)

telnet-url.py

어쨌든, 이렇게 하면 IE7과 FF3에서 telnet://localhost 링크를 사용할 수 있게 된다.