얼마전 W3C 의 HTML validator 가 0.8.1 로 업데이트 되었습니다. 기존의 0.7 대와는 많은 것이 달라졌습니다. 그래서 KLDP 의 open service 중의 하나인 http://validator.kldp.org 도 0.8.1 로 업데이트 하기 위해 준비중이었는데..
결정적으로 0.7 대까지 되던 localization 이 0.8 에서는 안되는 문제가 있더군요. 빡세게 번역을 했는데, 한글 출력이 되지 않는 안습의 상황이 발생하고 있습니다.
고쳐볼까 하고 코드를 살짝 둘러봤는데, 쉬운 문제가 아닌 것 같은 느낌이 들어 일단 포기하고 W3C 버그리스트를 살펴보니 0.9 milestone 에서 처리하려는 듯한 글만 찾을 수 있었습니다.
이걸 업데이트 해야 하는지 말아야 하는지 갈등이군요. 현재 영문으로 출력되는 것은 http://opens.kldp.org 에서 확인을 할 수는 있습니다. (아직 전체적인 정상 작동 여부는 확인을 안했습니다만..)
Go! Bbuwoo
뭘 이런걸..
57 Entries : Results for Tech/프로그래밍
- Posted
- Filed under Tech/프로그래밍
- Response
- You can track responses via RSS / ATOM feed
- Posted
- Filed under Tech/프로그래밍
검색을 하다보니 rrdtool 1.3 beta 가 나왔더군요. rrdtool 의 frontend 이 rrdexec 는 여전히 rrdtool 1.2 에서 사용을 할 수가 없고, rrdtool php extension 역시 아무도 1.2 용으로 개발을 하지 않더군요. 그래서 간만에 rrdtool 1.2 를 지원하도록 두 프로그램을 업데이트 해 보았습니다.
rrdtool php extension 의 경우에는 ob stream 을 지원하기 위하여, embeded library 를 만들어야 하는데, 기존에 1.0 에서 어느정도 수정을 했는지를 까먹은지라 1.2 용 embeded library 를 제작하는데 고생좀 했습니다. T.T
뭐, 덕분에 이제 php 용 rrdtool extension 이 드디어 하나 출현하게 되었습니다. (아니면 제가 찾지를 못해서 삽질을 한 것일 수도.. --;)
더불어, rrdexec 도 rrdtool 1.2 하에서 빌드가 될 수 있도록 수정을 했습니다. 하지만, 아직 rrdtool 1.2 의 개선된 기능을 사용할 정도로 업데이트가 되지는 못했습니다. 그냥 rrdtool 1.0 에서 제공하는 기능 정도만 현재 사용이 가능하며, rrdtool 1.2 로 빌드만 가능할 뿐입니다. (multibyte font 라든지, 개선된 graph 옵션을 아직 지원하지 못합니다.)
일단, 초석으로 rrdtool 1.2 에서 빌드가 가능하게만 해 놓은 상태이며, rrdexec 는 rrdtool 1.2 의 개선 사항을 반영하여 정식으로 릴리즈 할 계획 입니다.
현재 mod_rrd 와 rrdexec 의 개선 사항은 CVS 에만 반영이 되어 있습니다.
http://cvs.oops.org/index.cgi/rrdexec/
http://cvs.oops.org/index.cgi/mod_rrd/?cvsroot=OOPS-PHP
rrdtool php extension 의 경우에는 ob stream 을 지원하기 위하여, embeded library 를 만들어야 하는데, 기존에 1.0 에서 어느정도 수정을 했는지를 까먹은지라 1.2 용 embeded library 를 제작하는데 고생좀 했습니다. T.T
뭐, 덕분에 이제 php 용 rrdtool extension 이 드디어 하나 출현하게 되었습니다. (아니면 제가 찾지를 못해서 삽질을 한 것일 수도.. --;)
더불어, rrdexec 도 rrdtool 1.2 하에서 빌드가 될 수 있도록 수정을 했습니다. 하지만, 아직 rrdtool 1.2 의 개선된 기능을 사용할 정도로 업데이트가 되지는 못했습니다. 그냥 rrdtool 1.0 에서 제공하는 기능 정도만 현재 사용이 가능하며, rrdtool 1.2 로 빌드만 가능할 뿐입니다. (multibyte font 라든지, 개선된 graph 옵션을 아직 지원하지 못합니다.)
일단, 초석으로 rrdtool 1.2 에서 빌드가 가능하게만 해 놓은 상태이며, rrdexec 는 rrdtool 1.2 의 개선 사항을 반영하여 정식으로 릴리즈 할 계획 입니다.
현재 mod_rrd 와 rrdexec 의 개선 사항은 CVS 에만 반영이 되어 있습니다.
http://cvs.oops.org/index.cgi/rrdexec/
http://cvs.oops.org/index.cgi/mod_rrd/?cvsroot=OOPS-PHP
- Response
- You can track responses via RSS / ATOM feed
- Posted
- Filed under Tech/프로그래밍
며칠전에 IE7 과 mod_url 문제 수정 이라는 글에서 IE7 에서 한글 URI 를 사용할 경우 mod_url 과의 충돌로 무한 루프가 발생하는 문제를 수정하여 포스팅을 했었습니다.
그 과정에서, 301 로 재접속을 시킬때, IE7 의 재변환을 막기 위하여 url encoding 을 하여 문제를 해결했는데, 그 해결을 위해 사용했던 코드가 php raw_url_encode 함수를 수정하여 처리를 했습니다. 그런데, PHP license 와 Apache license 가 충돌이 나는 이유로 어떻게 할까 고심을 하다가 완전히 새로 작성을 하게 되었습니다.
apache 는 URL 에 대하여 다음의 구조체를 가집니다.
위에 나열된 변수들이 URL 과 관련되었으며, filename 은 system 상의 경로를 가지고 있습니다. 그래서 이것을 이용하여
와 같이 처리되도록 변경이 되었습니다. 딱 1가지 경우만 빼고는 재접속을 하지 않게 되는 변경이 된것입니다. 다만, 4번 과정에서 재접속을 해야 하는데, 이 경우는 다음과 같습니다.
서버에서 다음과 같이 Alias 가 결려 있을 경우입니다.
이 설정과 같이, Alias 이름에 한글이 들어가 있으면 apache 구조체의 filename 변수에 실제 경로 부분에는 EUC-KR 이 그리고 URI 에 해당 되는 부분에는 UTF-8 이 들어가기 때문에 iconv 에서 실패를 하게 됩니다. Alias 가 해석되는 과정에서 이게 섞이게 되는데, 이 경우는 재전송을 통하여 EUC-KR 로 들어오게 하는 방법외에는 없더군요 --;
뭐 하여튼, 이런 구조로 완전히 재설계가 되었습니다. :-)
문제는, 이 수정 사항을 KLDP.NET 의 공식 mod_url 에 반영을 해야 하는데, 패치 주고받고 하면서 하기가 상당히 귀찮네요. 코드도 완전히 바뀌었고, 그냥 mod_url2 로 fork 를 할까도 살짝 고민중입니다. ^^;
어쨌든.. apache1/2 용 모듈 2개 모두 현재 재작성이 되었고, apaceh2 용 모듈은 실제 테스트는 아직 해 보지 못했습니다. 다만 apache 2.2 의 소스를 참고하여 API 는 맞추어 놓았습니다.
재작성된 mod_url 은 http://cvs.oops.org/index.cgi/mod_url/?cvsroot=OOPS-Apache 에서 apache 1 용은 1.17, apache 2 용은1.10 을 받으시면 됩니다.
그 과정에서, 301 로 재접속을 시킬때, IE7 의 재변환을 막기 위하여 url encoding 을 하여 문제를 해결했는데, 그 해결을 위해 사용했던 코드가 php raw_url_encode 함수를 수정하여 처리를 했습니다. 그런데, PHP license 와 Apache license 가 충돌이 나는 이유로 어떻게 할까 고심을 하다가 완전히 새로 작성을 하게 되었습니다.
apache 는 URL 에 대하여 다음의 구조체를 가집니다.
struct request_rec {
..
char *filename;
char *path_info;
char *uri;
struct stat finfo;
char *unparsed_uri;
uri_components parsed_uri;
..
}위에 나열된 변수들이 URL 과 관련되었으며, filename 은 system 상의 경로를 가지고 있습니다. 그래서 이것을 이용하여
- uri 를 iconv 로 convert 를 함
- uri convert 가 실패하면, 그냥 file not found 로 전송
- filename 을 convert 함.
- filename convert 를 실패하면 301 로 변환된 URI 를 이용한 주소로 재접속 하도록 함.
- convert 된 filename 이 시스템상이 있는지 확인
- 있으면 정상 출력 없으면 file not found
와 같이 처리되도록 변경이 되었습니다. 딱 1가지 경우만 빼고는 재접속을 하지 않게 되는 변경이 된것입니다. 다만, 4번 과정에서 재접속을 해야 하는데, 이 경우는 다음과 같습니다.
서버에서 다음과 같이 Alias 가 결려 있을 경우입니다.
Alias /xxx/한글/ /home/httpd/html/한글/이 설정과 같이, Alias 이름에 한글이 들어가 있으면 apache 구조체의 filename 변수에 실제 경로 부분에는 EUC-KR 이 그리고 URI 에 해당 되는 부분에는 UTF-8 이 들어가기 때문에 iconv 에서 실패를 하게 됩니다. Alias 가 해석되는 과정에서 이게 섞이게 되는데, 이 경우는 재전송을 통하여 EUC-KR 로 들어오게 하는 방법외에는 없더군요 --;
뭐 하여튼, 이런 구조로 완전히 재설계가 되었습니다. :-)
문제는, 이 수정 사항을 KLDP.NET 의 공식 mod_url 에 반영을 해야 하는데, 패치 주고받고 하면서 하기가 상당히 귀찮네요. 코드도 완전히 바뀌었고, 그냥 mod_url2 로 fork 를 할까도 살짝 고민중입니다. ^^;
어쨌든.. apache1/2 용 모듈 2개 모두 현재 재작성이 되었고, apaceh2 용 모듈은 실제 테스트는 아직 해 보지 못했습니다. 다만 apache 2.2 의 소스를 참고하여 API 는 맞추어 놓았습니다.
재작성된 mod_url 은 http://cvs.oops.org/index.cgi/mod_url/?cvsroot=OOPS-Apache 에서 apache 1 용은 1.17, apache 2 용은
- Response
- You can track responses via RSS / ATOM feed
Comments List
-
김정균
-
kldp.net 버전과 oops.org 버전이 merge 가 되었습니다. 제가 kldp.net 의 mod_url 의 개발자로 등록이 되어 정식 배포처는 http://modurl.kldp.net 을 이용하세요.
-
LeCieL
-
수정하지 않은 modurl의 문제입니다.
worker 에 그냥 기존에 있던거 올리고나서 돌린게 답니다;;
apache php 가 아닙니다. 미디어 전송 전용서버이므로
apache만 달랑 올라가있습니다.
돌고있는 모듈은 몇안되고 redurl이 여기에 있다가 부하 폭주시 워커의 줄사망이 있었습니다.
전송트래픽은 초당 400메가정도 됩니다. 커넥션은 폴링되고 있지만 약 4만개정도 사용하고 있구요
워커모듈에 별도로 돌고있는것은 메모리 캐시 모듈입니다.
지금버전을 테스트하기에는 실제 서버라 힘들듯합니다. -
-
김정균
-
일단은 어떻게 수정을 하셨는지 코드를 공개를 하지 않으셨기 때문에 mod_url 이 문제인지 아니면 수정한 부분이 문제인지는 저로서는 판단을 할 수 없고, mod_url (IE7 문제 수정전의 코드) 와 현재 제가 새로 수정한 부분을 worker 모델에서 2일동안
echo "한글.txt" > ./uri.txt
while [ 1 ]; do
ab -c 100 1000 http://localhost/test/$(iconv EUC-KR UTF-8 ./uri.txt)
done
rm -f ./uri.txt
와 같이 돌리고 있는데 별 문제 없는 것 같습니다. 한번 테스트 해 줘 보시죠. (음 Apache 2 thread safety issues 문서를 보니 race condition 하게 발생하기 때문에 thread safe 하다고 보장은 못하겠군요. 그래서 이 멘트 남깁니다. ^^)
그리고 apache + php 환경은 worker model 로는 별로 적합하지 않다고 생각이 됩니다만.. 일단 php extension 들이 thread safe 를 보장하지 못하고, apache 와 php 를 build 하기 위한 library 들이 thread safe 를 보장하지 못하는데 mod_url 이 아니라 다른 무엇이 문제가 될 수도 있을 테지요.
그리고, 수정한 일본의 모듈은 아마 mod_encoding 이 아닐까 예상합니다 :-) 이 모듈 역시 예전에 회자가 되어 어느정도 코드는 본 것입니다. 실제로 mod_url 역시 hooking first 로 처리를 해 보려고 했으나 완벽한 지원이 어려워 그냥 hooking last 로 처리한 것이고요. 그리고 수정된 mod_url 은 기존의 mod_url 코드와는 다릅니다. 현재 박 원규님과 메일을 주고 받고 있는데, 만약 받아들여지지 않는다면 혼동을 피하기 위해서 mod_url2 정도로 fork 할 듯 싶습니다.
-
-
LeCieL
-
수고가 많으시네요 ;;
그런데 redurl (modurl) 말고 일본에서 사용하던 뭐더라;; 저는 그걸 기반으로 작업했답니다.
일단 패치할 시간이 거의 없었고;; ie7 나온지 하루이틀안에 해결봐야해서 ㅎㅎ;;
그런데 성능적인 문제 (1대의 미디어 서버)를 감안한 경우 first hook 에 charset detection 이 들어가는것이
압도적인 차이를 준다고 생각합니다.
(물론 last 로 후킹하여 전처리 다 하고 매 컨버저닝마다 파일이 있는지 체크하는것도 좋습니다
그러나 워커모듈에서는 요러다 에러하나 나면 줄사탕인지라 ;
제가 패치한건 일반서버는 아예 이 모듈을 내려버렸고 (급한관계로),
컨텐츠 전송서버만 first hook 으로 강제 변환하도록 설정하였습니다. 아마도 그 일본에서 만든 modurl같은녀석을
여기저기 뜯어고쳤던듯합니다;; -
-
김정균
-
redurl(mod_url) 은 요청하신 페이지가 존재하면 작동하지 않습니다. 즉, 해당 페이지가 존재하지 않을 경우에만 작동합니다. 이는 httpd.conf 에서 error log level 을 debug 로 맞추어 놓고선 error log 를 보시면 확인하실 수 있습니다.
hooking 을 전처리로 할 때의 문제는, 무조건 바꾸기 때문에 file system 에 정말 utf8 로 인코딩된 파일이름이 존재하고 있을 경우 찾을 수가 없습니다. 또한, Alias 와 같은 URL 을 처리할 수 없습니다. 저도 전처리로 하려고 했으나 이 부분 때문에 결국에는 LAST 로 처리한 것입니다.
그리고, worker model 은 솔직히 뭐라고 말은 못하겠습니다. 일단 mod_url 자체가 thread safe 한지 보장을 하지 못하기 때문에 worker model 에서 사용을 하라고 권장 자체를 못하기 때문입니다. :-)
-
- Posted
- Filed under Tech/프로그래밍
IE7 에서 mod_url 이 설정되어 있는 서버로 한글 주소를 전송할 경우 encoding 이 맞으면 (즉, mod_url 이 작동할 일이 없으면..) 문제가 없지만, 맞지 않을 경우에는 무한 루프에 빠지게 되는 문제가 있습니다. 즉 예를 들어서, 다음의 조건에 해당될 경우 입니다.
이 조건에서, IE7 이 http://domain.com/한글.html 을 전송을 하면 실제로는
과 같이 "한글" 이 utf8 로 인코딩 되어 전송이 됩니다. (위에서는 편의상 urlencoding 을 했습니다. euc-kr 의 경우 인코딩을 하면 4byte 이지만, utf8 의 경우 6byte 가 되는 것으로 구분을 하기 위함입니다.)
그리고, 서버에서는 mod_url 이
이 성공을 하기 때문에
을 브라우저에게 전송하게 됩니다. IE6 의 경우 이렇게 전달된 주소를 그대로 이용하기 때문에 문제가 없었는데, IE7 부터는 이 주소의 "한글" 을 다시 UTF8 로 만들어 재전송하기 때문에 무한루프에 빠지게 되는 겁니다. 그래서 이를 해결하기 위해서 return 하는 Location 의 주소를 RFC1738에 의거하여 URL encoding 하여 브라우저로 전송해 주는 방법을 사용할 수 있습니다.
이를 해결하기 위해서는 다음 URL 을 참조 하시기 바랍니다.
KLDP.net mod_url project
OOPS.org mod_url CVS tree
- IE7 이 URL 의 utf8로 전송한다. (기본값임)
- 서버측의 mod_url 이 다음과 같이 설정이 되어 있다.
CheckURL on ServerEncoding EUC-KR ClientEncoding UTF-8
이 조건에서, IE7 이 http://domain.com/한글.html 을 전송을 하면 실제로는
http://domain.com/%ED%95%9C%EA%B8%80.html
과 같이 "한글" 이 utf8 로 인코딩 되어 전송이 됩니다. (위에서는 편의상 urlencoding 을 했습니다. euc-kr 의 경우 인코딩을 하면 4byte 이지만, utf8 의 경우 6byte 가 되는 것으로 구분을 하기 위함입니다.)
그리고, 서버에서는 mod_url 이
iconv ("UTF-8", "EUC-KR", "%ED%95%9C%EA%B8%80");
이 성공을 하기 때문에
HTTP/1.1 301 Moved Permanently
Location: http://domain.com/한글.html
을 브라우저에게 전송하게 됩니다. IE6 의 경우 이렇게 전달된 주소를 그대로 이용하기 때문에 문제가 없었는데, IE7 부터는 이 주소의 "한글" 을 다시 UTF8 로 만들어 재전송하기 때문에 무한루프에 빠지게 되는 겁니다. 그래서 이를 해결하기 위해서 return 하는 Location 의 주소를 RFC1738에 의거하여 URL encoding 하여 브라우저로 전송해 주는 방법을 사용할 수 있습니다.
HTTP/1.1 301 Moved Permanently
Location: http://domain.com/%C7%D1%B1%DB.html
이를 해결하기 위해서는 다음 URL 을 참조 하시기 바랍니다.
KLDP.net mod_url project
OOPS.org mod_url CVS tree
- Response
- You can track responses via RSS / ATOM feed
Trackbacks List
-
IE7 과 mod_url 문제 수정 2번째
-
- Tracked from Go! Bbuwoo
- Delete
며칠전에 IE7 과 mod_url 문제 수정 이라는 글에서 IE7 에서 한글 URI 를 사용할 경우 mod_url 과의 충돌로 무한 루프가 발생하는 문제를 수정하여 포스팅을 했었습니다. 그 과정에서, 301 로 재접속을 시킬때, IE7 의 재변환을 막기 위하여 url encoding 을 하여 문제를 해결했는데, 그 해결을 위해 사용했던 코드가 php raw_url_encode 함수를 수정하여 처리를 했습니다. 그런데, PHP license 와 Apa..
- Posted
- Filed under Tech/프로그래밍
cygwin 용 패키지 3개를 빌드해 보았습니다. 물론 예전 부터 사용하던 거였지만. 이번에 Cygwin package 로 이쁘게 가다음어 cygwin 용 source package 와 binary package 로 묶어 공개를 합니다.
1. hanterm-xf 2.0.5-177
2. rxvt 2.7.10
3. check-utils
여러가지 checking 를 편하게 하기 위한 utility 로 필자의 자작 패키지입니다. 다음의 checking tool 을 제공합니다.
공개된 버전의 수정 사항은 다음과 같습니다.
위의 Cygwin 용 패키지들은 ftp://mirror.oops.org/pub/Cigwin/packages 에서 source package 와 binary package 를 받을 수 있습니다. 참고로 ftp client 로 접속을 하셔야 합니다.
1. hanterm-xf 2.0.5-177
- 2.0.6-177?
- hanterm-xf 홈페이지의 최신 버전은 2.0.6-177 과 동일합니다. - utf8 패치
- .Xdefault 에 "Hanterm*hangulCode: 2" 라고 지정하면 UTF8 이 기본 모드가 됩니다. - cygwin 용 runtime batch file 추가
- /usr/X11R6/bin/hanterm-xf.bat 을 단축 아이콘으로 만들어 사용하면 됩니다.
2. rxvt 2.7.10
- rxvt 기본 패키지에서 한글을 지원하도록 patch 하여 리빌드 되었습니다.
- Netj.org 참조하십시오.
3. check-utils
여러가지 checking 를 편하게 하기 위한 utility 로 필자의 자작 패키지입니다. 다음의 checking tool 을 제공합니다.
- chkbandwidth: 서버의 실시간 network 대역폭 사용량 체크
- chkdownload: http protocol 을 이용하여 download 속도 체크. (DISK I/O 배제)
- httpwatch: 80번 포트 체크 프로그램
- rtspcheck: Windows Media Server 9 의 포트 체크 프로그램
공개된 버전의 수정 사항은 다음과 같습니다.
- 이전 버전에서 cygwin 의 iconv 를 지원하지 못하여 rtspcheck 사용못하던 문제 해결
- 한국어 메시지 출력 지원
위의 Cygwin 용 패키지들은 ftp://mirror.oops.org/pub/Cigwin/packages 에서 source package 와 binary package 를 받을 수 있습니다. 참고로 ftp client 로 접속을 하셔야 합니다.
- Tag check-utils, CYGWiN, hanterm, rxvt
- Response
- You can track responses via RSS / ATOM feed
- Posted
- Filed under Tech/프로그래밍
Happy
New Year!
이제 2006 년도 대략 5시간이 조금 안되게 남았습니다. 얼마전 포스팅한대로 신년 선물로 OOPS Firewall 6.0.0 을 릴리즈 하게 되었습니다. 닥질의 연속이기는 했지만.. T.T
6.0.0 에서의 변경 사항은
- inbound 와 outbound 설정의 확실한 구분
OUTPUT table 을 제어하여 inbound 설정이 outbound 설정에 영향을 미치는 부분을 처리 - random 한 host 의 IP 를 처리하기 위해 source 와 destination 을 구분하지 않던 부분을 처리
- Bridge mode 제어 기능 추가
- Interface 설정이 WAN 1개 Local 1개 까지만 제한이 되던 문제 해결
(이전 버전과의 호환성 문제가 남게 됨. (처리 가능할까???)
입니다. 새로이 interface.conf, bridge.conf, application.conf 가 추가 되었으며, masq.conf 의 MASQ_DEVICE,
MASQ_CLIENT_DEVICE 옵션은 interface.conf 의 MASQUERADE_WAN, MASQUERADE_LOC 로 대체 되었으며, forward.conf 의 FORWARD_MASTER 옵션은 삭제 되었습니다.
최대한 5.0.0 의 설정을 사용할 수 있도록 되어 있으나, 새로 설치 후 꼭 ineterface.conf 설정은 해 주시는 것이 좋으며, masq.conf 와 forward.conf 의 device 설정 옵션은 제거해 주시면 되겠습니다.
다만, 아직 확실하게 파악이 되지 않은 부분으로..
- Bridge client 로 서버를 운영할 경우 서비스가 제대로 되는지 확인 못함
- Bridge server 에서의 ftp outbound 시에 passive 시에 지연현상 발생
정도가 있습니다. 이는 서비스 구성 환경을 못만든 부분과, 제 네트워크의 문제일 수도 있으나 다른 곳에서의 확인이 불가능한 경우입니다.
- Tag firewall, iptables, oops-firewall, 방화벽
- Response
- You can track responses via RSS / ATOM feed
- Posted
- Filed under Tech/프로그래밍
http://jigsaw.w3.org/css-validator 가 드디어 업데이트 되었습니다. 그동안 http://css-validator.kldp.org 가 개발 버전으로 운영되어 오다 보니 디자인이 달라서 이거 뭐에요 하는 질문을 많이 받았었는데, 이제 디자인도 동일해진 관계로 이런 질문은 더이상 오지 않을 듯 싶군요.
한국어 버전을 사용하면 좋은 점은 일단 한글 폰트가 들어가 있을 때 에러가 발생하지 않는 다는 점과 속도가 빠르다는 점이죠. 아직까지 http://jigsaw.w3.org/css-validator 에서 검사를 하시던 분들은 http://css-validator.kldp.org 로 이전하시기 바랍니다. ^^;
또한, 한국어 서비스만 가능하던 것에서, multi language 서비스가 가능하도록 기능이 추가 되었습니다. 외국에 페이지 검사도 유용하게 사용할 수 있을 겁니다.
한국어 버전을 사용하면 좋은 점은 일단 한글 폰트가 들어가 있을 때 에러가 발생하지 않는 다는 점과 속도가 빠르다는 점이죠. 아직까지 http://jigsaw.w3.org/css-validator 에서 검사를 하시던 분들은 http://css-validator.kldp.org 로 이전하시기 바랍니다. ^^;
또한, 한국어 서비스만 가능하던 것에서, multi language 서비스가 가능하도록 기능이 추가 되었습니다. 외국에 페이지 검사도 유용하게 사용할 수 있을 겁니다.
- Response
- You can track responses via RSS / ATOM feed
- Posted
- Filed under Tech/프로그래밍
현재 안녕 리눅스와 Redhat, Debian 등에서 설치하시는 많은 유저들이 사용하시는 oops-firewall 은 v5 대까지 개발이 되어 있습니다. 솔직히 v1 에서 v2 로 갈때와 v2 에서 v3 으로 갈 때는 ruleset 의 변경등 많은 변화가 있었지만 v3 에서 v5 까지는 ruleset 의 변화라기 보다는 내부 코드의 변경 즉, iptables rule set 을 만드는 parse 의 변경 사항이 많았던 것이 사실입니다. 즉, 대략 4여년 정도는 기능상의 발전이 없었다는 얘기입니다.
올해 남은 휴가를 연말에 몰아쓰면서, 크리스마스 기념으로 (jsboard 를 개발할 때 부터 크리스마스 마다 이벤트(?) 같은 것을 하기는 했습니다만..) oops-firewall v6 를 내 놓으려고 열심히 노력을 했습니다...만 결국에는 크리스 마스가 지나버리고 말았습니다. T.T 아무래도 신년 기념으로 해야 하지 않을까 싶은데, 개발 환경상의 제약 때문에 그것도 기약하기가 힘들것 같군요 :-)
v6 에서는 강화 되는 부분은 다음과 같습니다.
또한, 시간이 나면, 현재 Masq mode 에서 forward rule 에서는 filtering 을 하지 않는 문제도 같이 처리를 할까 생각 중입니다만 이 부분은 다음 버전으로 넘어갈 확률이 높을 듯 싶고요. (제가 별로 사용하지 않는 기능이기에 ㅋㅋ)
하여튼 크리스마스 선물로 드리려던 계획은 물거품이 되었고, 신년 선물로 제공해 드릴까 하지만, 일정상 불가능 할 것 같기도 하고.. 그래도 내년 1월 안에는 모습을 보일 수는 있지 않을까 생각이 됩니다. 그래도 제가 공개해 놓은 프로그램들 중에는 jsboard 가 가장 알려져 있지만 사용률은 아마 oops-firewall 이 가장 많을 듯 싶은데..
- v1 2000.08
kernel 2.2 ipchains - v2 2001.03
kernel 2.4 iptables - v3 2001.10
ruleset 강화
close all port
inbound 와 outbound 설정 구분
session state 제어 - v4 2003.06
i18N support
module 제어 기능 추가 - v5 2005.12
코드 재작성
filter order 변경
올해 남은 휴가를 연말에 몰아쓰면서, 크리스마스 기념으로 (jsboard 를 개발할 때 부터 크리스마스 마다 이벤트(?) 같은 것을 하기는 했습니다만..) oops-firewall v6 를 내 놓으려고 열심히 노력을 했습니다...만 결국에는 크리스 마스가 지나버리고 말았습니다. T.T 아무래도 신년 기념으로 해야 하지 않을까 싶은데, 개발 환경상의 제약 때문에 그것도 기약하기가 힘들것 같군요 :-)
v6 에서는 강화 되는 부분은 다음과 같습니다.
- inbound 와 outbound 설정의 확실한 구분
OUTPUT table 을 제어하여 inbound 설정이 outbound 설정에 영향을 미치는 부분을 처리 - random 한 host 의 IP 를 처리하기 위해 source 와 destination 을 구분하지 않던 부분을 처리
- Bridge mode 제어 기능 추가
- Interface 설정이 WAN 1개 Local 1개 까지만 제한이 되던 문제 해결
(이전 버전과의 호환성 문제가 남게 됨. (처리 가능할까???)
또한, 시간이 나면, 현재 Masq mode 에서 forward rule 에서는 filtering 을 하지 않는 문제도 같이 처리를 할까 생각 중입니다만 이 부분은 다음 버전으로 넘어갈 확률이 높을 듯 싶고요. (제가 별로 사용하지 않는 기능이기에 ㅋㅋ)
하여튼 크리스마스 선물로 드리려던 계획은 물거품이 되었고, 신년 선물로 제공해 드릴까 하지만, 일정상 불가능 할 것 같기도 하고.. 그래도 내년 1월 안에는 모습을 보일 수는 있지 않을까 생각이 됩니다. 그래도 제가 공개해 놓은 프로그램들 중에는 jsboard 가 가장 알려져 있지만 사용률은 아마 oops-firewall 이 가장 많을 듯 싶은데..
- Tag firewall, iptables, oops-firewall, 방화벽
- Response
- You can track responses via RSS / ATOM feed
Trackbacks List
-
OOPS Firewall v6.0.0 release
-
- Tracked from Go! Bbuwoo
- Delete
Happy New Year! 이제 2006 년도 대략 5시간이 조금 안되게 남았습니다. 얼마전 포스팅한대로 신년 선물로 OOPS Firewall 6.0.0 을 릴리즈 하게 되었습니다. 닥질의 연속이기는 했지만.. T.T 6.0.0 에서의 변경 사항은 inbound 와 outbound 설정의 확실한 구분 OUTPUT table 을 제어하여 inbound 설정이 outbound 설정에 영향을 미치는 부분을 처리 random 한 host 의 IP 를 처리..
- Posted
- Filed under Tech/프로그래밍
http://banner.kldp.org
그래서 이참에 그래 한국에 빠르게 사용할 수 있도록 설치를 해 보자고 해서, KLDP 의 open service server 에 설치를 하기 시작했습니다. 아 그런데 소스 코드를 받아서 보니, 이거 engine 만 공개를 해 놓은 것이더군요. (정확히는 PHP class file 하나..) Frontend 를 생으로 만들어야 하는 노가다.. (Frontend 를 만들려면 또 class 와 ajax java script 들을 분석해야 하는 암울함 T.T)
결국에는 디자인을 배껴와서 어떻게 해 보자 하다가 결국에는 동일하게 작동(내부적으로는 다르겠지만..)하고 동일하게 보이도록 UI 를 만드는데 성공을 했습니다.
http://banner.kldp.org 에서 이용하실 수 있으며, 혹시 설치를 원하시는 분들은 http://banner.kldp.org/source/BrilliantButtonMaker-ko.tar.gz 에서 받으실 수 있습니다. 웹 경로에 압축을 해제 하시고, README-ko 파일을 참고하여 사용하시면 됩니다.
- Response
- You can track responses via RSS / ATOM feed
Comments List
-
-
김정균
-
font 가 silkscreen 일 경우에만 공백 문자가 처리됩니다. 나머지 font 에서는 모두 %20 으로 처리되더군요. 이건 gd 로 넘어갈때의 문제인듯 싶습니다.
저도 현재는 local 에서 실행할 수 있도록 하는데만 신경을 쓴지라..^^; 앞으로 해야 할일이 한글 font 사용할 수 있도록 하는 것과 %20 문제를 처리해야 하는 문제는 해야할 일입니다. (이건 원 site 도 동일한 문제를 가지고 있습니다.)
현재로서는 font 를 silkscreen 으로 하는 것 외에는 대안이 없습니다. 아니면 띄어쓰기를 하지 말든지..
-
- Posted
- Filed under Tech/프로그래밍
한 2달은 지난일이지만, 공유하는 것도 괜찮을 듯 해서 작성합니다.
회사에서 Game 의 version.ini 다운로드시에 cache 의 문제로 웹서버에서 강제로 NoCache header 를 출력하도록 한 적이 있습니다.
위와 같이 lighttpd 에서 설정을 한 후에, test 까지 마치고 귀가를 했었는데, 새벽에 난리가 나고 말았습니다. 새벽부터 전화가 불같이 오더군요. 직감적으로 어제 설정한 no-cache 가 문제가 된것 같아서 일단, 설정을 rollback 하고나니 역시나 문제가 해결이 되었습니다.
문제 해결후, 출근을 해서 장애 리포트도 작성할 겸 도대체 왜 문제가 되었는지 검증을 하던 중, 황당함에 어쩔 수 없는 사실을 발견하게 됩니다. IE 또는 WinInet API 로 다운로드를 받을 경우, ini 확장자가 no-cache header 를 받을 경우 WinInet API 차원에서 좌측과 같은 에러 메세지를 출력을 하는 겁니다.
다른 browser 에서는 모두 정상적으로 받아지는데 왜 IE 에서만 이런 문제가 발생할까 고민을 하고 검색을 하다가, 로그를 봐도 200 코드 반환을 했고, 믿을 수가 없어서 packet dump 를 떠 보았는데, 서버측에서도 정상적으로 파일 내용을 보내고 있었고, 심지어는 client 에서도 파일을 받았음에도 불구하고 IE (WinInet API) 만 유독 이런 처리를 하는 것으로 보아서, WinInet 자체적으로 이런 짓거리를 한다고 밖에 단정할 수 없겠더군요. --; 그래서 설정 값을 하나씩 제거하면서 테스트를 해 본바, no-cache 값이 들어갈 경우에만 발생을 하고 있었습니다.
MSDN 의 WinInet 의 Cache 관련 문서를 찾아봐도 이런 언급은 없었는데, 검색을 하다가 http://support.microsoft.com/kb/323308 문서를 발견하게 됩니다. 물론 상관은 없지만 HTTPS protocol 에서의 WinInet API 의 이상 작동에 관한 기술 문서더군요. 순간.. 버그가 또 있었구나.. 하는 암울한 생각만.. T.T 결국에는 장애 리포트만 쓰고선, 다음 부터는 꼭 IE 에서 테스트 하자는 결의만 다지고 허탈함을 달랠길이 없더군요.
혹시라도, Game 관련 회사의 Download Server 를 운영하신다면, Cache-Control header 에 no-cache 를 출력해서 저같은 경우를 당하지 말기를 바라면서 포스팅을 해 봅니다.
회사에서 Game 의 version.ini 다운로드시에 cache 의 문제로 웹서버에서 강제로 NoCache header 를 출력하도록 한 적이 있습니다.
setenv.add-response-header = (
"Expires" => "Thu, 01 Jan 1970 00:00:00 GMT",
"Cache-Control" => "no-store, no-cache, must-revalidate, post-check=0, pre-check=0",
"Pragma" => "no-cache"
)
위와 같이 lighttpd 에서 설정을 한 후에, test 까지 마치고 귀가를 했었는데, 새벽에 난리가 나고 말았습니다. 새벽부터 전화가 불같이 오더군요. 직감적으로 어제 설정한 no-cache 가 문제가 된것 같아서 일단, 설정을 rollback 하고나니 역시나 문제가 해결이 되었습니다.
황당한 에러메시지
다른 browser 에서는 모두 정상적으로 받아지는데 왜 IE 에서만 이런 문제가 발생할까 고민을 하고 검색을 하다가, 로그를 봐도 200 코드 반환을 했고, 믿을 수가 없어서 packet dump 를 떠 보았는데, 서버측에서도 정상적으로 파일 내용을 보내고 있었고, 심지어는 client 에서도 파일을 받았음에도 불구하고 IE (WinInet API) 만 유독 이런 처리를 하는 것으로 보아서, WinInet 자체적으로 이런 짓거리를 한다고 밖에 단정할 수 없겠더군요. --; 그래서 설정 값을 하나씩 제거하면서 테스트를 해 본바, no-cache 값이 들어갈 경우에만 발생을 하고 있었습니다.
MSDN 의 WinInet 의 Cache 관련 문서를 찾아봐도 이런 언급은 없었는데, 검색을 하다가 http://support.microsoft.com/kb/323308 문서를 발견하게 됩니다. 물론 상관은 없지만 HTTPS protocol 에서의 WinInet API 의 이상 작동에 관한 기술 문서더군요. 순간.. 버그가 또 있었구나.. 하는 암울한 생각만.. T.T 결국에는 장애 리포트만 쓰고선, 다음 부터는 꼭 IE 에서 테스트 하자는 결의만 다지고 허탈함을 달랠길이 없더군요.
혹시라도, Game 관련 회사의 Download Server 를 운영하신다면, Cache-Control header 에 no-cache 를 출력해서 저같은 경우를 당하지 말기를 바라면서 포스팅을 해 봅니다.
- Tag Cache-Control, Download, no-cache, version.ini, WinInet
- Response
- You can track responses via RSS / ATOM feed
Comments List
한글 출력 문제를 드디어 해결을 했습니다. :-) css-validator 와 비슷한 문제이더군요. cgi-bin/check 를 다음과 같이 수정함으로 해결이 가능 합니다.
@@ -972,7 +972,7 @@ $template->param(file_source => &source(
# $T->param(file_outline => &outline($File)) if $T->param('opt_show_outline');
# transcode output from perl's internal to utf-8 and output
-print Encode::encode('UTF-8', $template->output);
+print Encode::encode('ISO-8859-1', $template->output);
#
# Get rid of $File object and exit.