입니다. 새로이 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 설정 옵션은 제거해 주시면 되겠습니다.

다만, 아직 확실하게 파악이 되지 않은 부분으로..



정도가 있습니다. 이는 서비스 구성 환경을 못만든 부분과, 제 네트워크의 문제일 수도 있으나 다른 곳에서의 확인이 불가능한 경우입니다.

http://jigsaw.w3.org/css-validator 가 드디어 업데이트 되었습니다. 그동안 http://css-validator.kldp.org 가 개발 버전으로 운영되어 오다 보니 디자인이 달라서 이거 뭐에요 하는 질문을 많이 받았었는데, 이제 디자인도 동일해진 관계로 이런 질문은 더이상 오지 않을 듯 싶군요.

한국어 버전을 사용하면 좋은 점은 일단 한글 폰트가 들어가 있을 때 에러가 발생하지 않는 다는 점과 속도가 빠르다는 점이죠. 아직까지 http://jigsaw.w3.org/css-validator 에서 검사를 하시던 분들은 http://css-validator.kldp.org 로 이전하시기 바랍니다. ^^;

또한, 한국어 서비스만 가능하던 것에서, multi language 서비스가 가능하도록 기능이 추가 되었습니다. 외국에 페이지 검사도 유용하게 사용할 수 있을 겁니다.

현재 안녕 리눅스와 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 이 가장 많을 듯 싶은데..

80x15 size 의 배너를 만들어 주는 Brilliant Button Maker 는 꽤 유명한 사이트 입니다. 필자도 AnNyung Linux 의 banner 와 W3C validator 의 banner 를 만들기 위해 이용을 했었습니다. 최근 W3C validator 를 업데이트 하고선, 배너를 좀 다양하게 지원을 하려고 접속을 했다가 속도가 너무 느려서 혹시 코드를 공개를 했나 살펴보니 역시 공개가 되어 있더군요.

그래서 이참에 그래 한국에 빠르게 사용할 수 있도록 설치를 해 보자고 해서, 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 파일을 참고하여 사용하시면 됩니다.

배포되는 압축 파일은 Brilliant Button Maker 의 저자에게 현재 배포 허가 메일을 보내놓은 상태인데, 저자의 답장에 따라 배포가 중지될 수도 있습니다.

한 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 를 출력해서 저같은 경우를 당하지 말기를 바라면서 포스팅을 해 봅니다.