뭘 이런걸..

Filed under Tech/프로그래밍
요즘 슬슬 CVS를 SVN으로 옮겨 보려고 하고 있다. 괜찮은 svn interface가 뭐가 있난 찾다 보니 websvn이라는 놈이 깔끔하고 괜찮아 보였다. 다른 web interface들은 기존에 사용하던 cvsweb의 기능 중 지원하지 못하는 것들이 많아 좀 불편해 보였는데, 이 놈은 기존 사용하던 기능을 대부분 지원 하는 듯 하다.

그런데, 내가 주로 많이 사용하던 기능 중 diff시에 raw text를 출력해 주는 unified diff가 없다는 것이 꽤 답답했다. 웹에서 확인을 하고 mouse로 확 긁어서 붙이는 행위를 가끔 하는데, 이 놈이 이게 없는 것이다. 뭐 그래서 만들었다.

필요한 사람은 잘 사용하시도록.. (국내에서도 websvn 꽤 사용하는 듯..)

이 글을 올리는 이유는 patch를 제출하려고 했더니.. 첨부 파일이 없어서.. --;

Websvn Unified diff patch file

2011/04/14 21:26 2011/04/14 21:26
Filed under Tech/프로그래밍
출처: http://forums.parallax.com/showthread.php?114807-Fast-Faster-Fastest-Code-Integer-division

page 없어질 까봐 스크랩 함.

Hi All,

A code or algorithm must be correct. When it is, after some debugging, we can make a compromise between its code size and speed. There is always a compromise, but sometimes it does not matter. When either speed or size is a factor, there are methods to boost performance. There might be a 'Small, Smaller, Smallest' flavor of coding for a given language/hardware combination, but in this kind of thread I am looking for very fast codes. As, we have these days the luxury of more and more code space, but of time, we don't.

Even when divide hardware is available, it is quite common to find that divide instructions take more than twice as long as multiply instructions. When division and multiplication are done by software, dividing is usually slower than multiplying, too. However, we can improve speed by noticing, that many integer division operations found in real programs involves division by a constant. When we know the numbers we are dividing by in advance, we can substitute the divisions with multiplications and with some bit shifts.

When the constant to divide by is a power of two, we can shift the number to be divided to the right by the exponent, and that will complete division

(some_integer/constant(=2^N)) = some_integer >> N

This bit shift is only one operation, four ticks with the Propeller. Can we do something similar when the constant is not a power of two? Yes. The·basic idea is to approximate the ratio (1/constant) by another rational number (numerator/denominator) with a power of two as the denominator. Instead of dividing, we can then multiply by the numerator, and shift by the exponent in the denominator. In case of 10, for example, the (1/10) ratio can be substituted with· (205/2048). The (some_integer/10) division can be calculated with a multiplication (some_integer*205), then the product is shifted right 11 bits to get the result of the division by 10. In short notation

(some_integer/10) = (some_integer*205) >> 11

To divide with 100, the rational number (41/4096) works nicely

(some_integer/100) = (some_integer*41) >> 12

For 1000 we can realize that it is 8*125. So, if we first shift 'some_integer' to the right by 3, we only need to divide the result by 125. When (1/125) is approximated as (67109/2^23)=(67109/8388608), then the simple formula

(some_integer/1000) = ((some_integer >> 3)*67109) >> 23

works for integers up to almost 400_000 with high accuracy.

To figure out the (numerator/denominator(=2^N)) approximation for an arbitrary (1/constant) factor, first we have to fix the required relative accuracy of the division. When 1% relative accuracy is adequate for the application
- we multiply the constant with 100.
- Then we find the smallest power of two, that is bigger than the product.·For (1/2009), 262144 is that, so the denominator is 2^18.
- Then, we·obtain the numerator by dividing 2^18 by the constant 2009. That gives 130.48. After rounding to the nearest integer, we have··the·rational approximation·of (1/2009) as (130/2^18).·

It goes, in short

(some_integer/2009) = (some_integer*130) >> 18

Or, doing an evident simplification, it is

(some_integer/2009) = (some_integer*65) >> 17

For a ten times better relative accuracy of 0.1%, the formula is

(some_integer/2009) = (some_integer*1044) >> 21

After simplification, it is

(some_integer/2009) = (some_integer*261) >> 19

The previous simplications decrease the numerator and are useful, since the (some_integer*numerator) product has to be smaller than 2^32, to avoid overflow with the 32-bit multiplication.· 2009 is an odd number. For even constants we can shift out the power of two factor from their primes, before the division. So, to divide with 2010 at 0.1% accuracy, one can use

(some_integer/2010) = ((some_integer >> 1)*1043) >> 20

The initial right shift for an even constant increases the range of validity of the algorithm at the cost of an additional operation.I wonder wether all these beat unrolled division?

We have just substituted a division by a multiplication, but elimination of multiply instructions is itself desirable. For example, according to the Pentium instruction timings, the base time for a 32-bit integer add or subtract on that processor (discounting operand fetch and other overhead) is 1 clock cycle, and both can sometimes be paired with other instructions for concurrent execution. In contrast, a 32-bit multiply takes 10 cycles and a divide takes 41 cycles, and neither can be paired. Clearly, these instructions should be avoided wherever possible.

In case of multiplication with a constant we may ask, that
- Can we can do faster integer multiplication with a constant with only· bit shifts and additions? (The answer is probably: yes. And remember, numerators were contants...)
- Can the (1/constant) ratio be calculated even faster with only bit shifts and additions?

I think the answer for the 2nd. question answers the 3rd, too.··

Trespassing the Regime of Fixed-point math (or not?)...
Fixed-point representations, in which the point is implicitly placed between any bits of the binary representation of a number, have been used since the dawn of the computer age. In the PC world fixed-point arithmetic has become a lost art among programmers. Since the introduction of the 486 CPU, a fast floating-point processor is an integrated part of the CPU, and therefore there is rarely a need to work with fixed-point numbers anymore. In embedded applications fixed-point arithmetic has still its places, and there is no excuse to use inefficient or imprecise methods with those limited resources. Moving away from integer arithmetic to fixed-point numbers is one step forward to close the gap between the speed of integer math and the ease of use of floating point arithmetic.

When fixed-point numbers are used, all arithmetic operations use integer arithmetic, and this leads to a considerable performance advantage. This comes from that a binary fixed point number is, for all purposes, an integer number. You simply cannot tell the difference by looking at it, and neither can the machine level math functions. For those math functions, the numbers are just integers. That's the beauty of it: you use the same machine level functions you would for integer math, plus a little bit of housekeeping for the point at multiplications and divisions. (John Von Neumann said once, that a competent programmer never needs floating point hardware because he should always be able to keep the point in his head. Well, his words are just remembered by others, he never wrote them down...)

With fixed-point arithmetic we can choose the precision of the numbers, because we can distribute bit usage between fractional and integer parts of a fixed number in any way we like. So, we can adapt a very fast code to very different accuracy demands.

In fixed-point, the simple integer division is the worst basic operation, because it loses precision the most. To somewhat remedy that, we can use multiplication by the reciprocal of that number (1/number) instead. To whet your appetite for fast and effective fixed point ASM code, I show a way to divide by 10 with faster, more efficiently and·more accurately, than·with the discussed acceleration method.

quotient = ((some_fixpoint >> 1) + some_fixpoint) >> 1 quotient = ((quotient >> 4) + quotient) quotient = ((quotient >> 8) + quotient) quotient = ((quotient >> 16) + quotient) >> 3 where 'some_fixpoint' can be any unsigned 32-bit number.

To make it even faster

quotient = ((some_fixpoint >> 1) + some_fixpoint) >> 1 quotient = ((quotient >> 4) + quotient) quotient = ((quotient >> 8) + quotient) >> 3 but 'some_fixpoint' here should be less (in integer format) than 534_890.

If you know other tricks or methods to speed up integer or fixed-point division or multiplication, let us know, too. SPIN or PASM test codes to check, improve or maybe to bust these ideas, are welcome.



Post Edited (cessnapilot) : 7/29/2009 7:10:30 PM GMT
2011/02/17 16:40 2011/02/17 16:40

A % B == 0인 게 알려져 있을 때 A / B를 곱셈 한 번(+ B가 짝수일 경우 시프트 한 번)으로 계산하는 방법은 알려져 있습니다(Z/(B)Z에 대한 B의 역수를 구해서 곱하면 됩니다). A가 임의의 숫자라면 A % B를 먼저 구해서 (A - A % B) / B를 구하는 방법을 쓸 수는 있는데, 이 경우에는 B가 작은 경우가 아니면 그다지 간단한 편은 아닙니다. Hackers' Delight 같은 책도 찾아 보세요.


감사합니다. 요즘에 개발로 보직을 변경해서.. 이제껏 좀 깊이 파고 들어가고 있습니다. 다만 스스로 찾아서 하려니 쉽지 않네요. 좋은 정보 감사합니다.

Filed under Tech/프로그래밍
문서의 Charset 을 detecting 하는 library 로는 IBM 이 지원하는 International Components for Unicode (ICU Project) 의 ICU library 와 Mozilla Browser 에서 이용하는 Universal Chardet library 가 있습니다.

ICU 의 경우에는 charset detect 가 포함된지 꽤 되었음에도 불구하고, php 5.3 부터 기본 포함되는 intl extension 에는 이 기능이 들어가지 않고 있습니다. 그 외에도 pecl 이나 pear 의 icu library 관련 패키지들에도 이상하게 이 부분만 들어가지 않고 있군요.

그리고 좀 더 안습인 것은, Mozilla 의 Universal Chardet 의 경우에는 C#, java, python, ruby (python chardet 을 porting 했음) 등등이 지원하고 있음에도 불구하고, PHP 나 별도의 c/c++ library 로는 제공되지 않고 있습니다.

Mozilla Universal Charset
Nchardet for C#
jchardet for Java
chardet for python
rchardet for ruby (python clone
Encode-Detect-1.01 > Encode::Detect::Detector for perl

mozilla code 에 c++ 로 지원하고 있으니 이걸 포팅하면 되겠지 하고 쉽게 생각을 했는데, xpcom 구조를 알기 전에는 쉽게 뗄 수 있을 놈이 아니더군요.

이렇듯 저렇듯.. 나오기만 2여년을 기다리다가.. 귀찮아서 mod_chardet 이라는 php extension 으로 하나 만들어 보고 말았습니다. 일단 mod_chardet 은 기본은 ICU library 의 Charset detect 기능을 이용하고, 옵션으로 python chardet 이 설치가 되어 있으면 Python C API를 이용하여 python chardet 을 사용할 수 있도록 설계를 했습니다. Mozilla Universal chardet 이 PHP 만 없다는 것도 좀 그렇다는 생각이 들었고..

일단, ICU 와 Universal Chardet 의 성능 비교도 해 볼겸해서 돌려 보았는데, 역시 ICU 보다는 Universal Chardet 이 detect 능력이 좋더군요. 그리고 ICU 에서 detect 할 수 있는 charset 보다 Universal chardet 이 좀 더 많이 지원하는 까닭도 있었고요.

일단, python chardet homepage 에 있는 자료가 오래된 까닭에 다음의 환경에서 해당 자료를 다시 분석해 보았습니다. 테스트 환경으로는 다음과 같습니다.

Python 2.5
Python Chardet 1.0.1
PHP 5.2.6
ICU library 4.0.1

Python Chardet result:
google.cn {'confidence': 0.98999999999999999, 'encoding': 'GB2312'}
yahoo.jp {'confidence': 0.98999999999999999, 'encoding': 'utf-8'}
amazon.co.jp {'confidence': 1, 'encoding': 'SHIFT_JIS'}
pravda.ru {'confidence': 0.93312187961594417, 'encoding': 'windows-1251'}
auction.co.kr {'confidence': 0.56471064895612277, 'encoding': 'ISO-8859-2'}
haaretz.co.il {'confidence': 0.98999999999999999, 'encoding': 'windows-1255'}
www.nectec.or.th {'confidence': 0.77645629965698426, 'encoding': 'TIS-620'}
feedparser.org {'confidence': 0.98999999999999999, 'encoding': 'utf-8'}

python-chardet 1.0.1 의 경우, 홈페이지 자료와는 약간 다른 결과가 나오더군요. 일단 python chardet homepage 의 정보가 변경이 되었을 수도 있고, chardet 이 업데이트 되면서 결과가 달라질 수도 있겠지만, 일단 이 결과에서 auction 이 예전에는 제대로 EUC-KR로 판단이 되었는데, 지금 환경에서는 다른 결과를 보여 주고 있습니다.

다음은 mod_chardet 의 결과 입니다.

PHP mod_chardet result:

google.cn (7121)
ICU : Encoding -> GB18030 Confidence -> 100
MOZ : Encoding -> GB2312 Confidence -> 98
yahoo.jp (30367)
ICU : Encoding -> UTF-8 Confidence -> 100
MOZ : Encoding -> utf-8 Confidence -> 98
amazon.co.jp (166082)
ICU : Encoding -> Shift_JIS Confidence -> 100
MOZ : Encoding -> SHIFT_JIS Confidence -> 100
pravda.ru (97826)
ICU : Encoding -> ISO-8859-1 Confidence -> 28
MOZ : Encoding -> windows-1251 Confidence -> 93
auction.co.kr (101330)
ICU : Encoding -> EUC-KR Confidence -> 100
MOZ : Encoding -> ISO-8859-2 Confidence -> 56
haaretz.co.il (174179)
ICU : Encoding -> ISO-8859-1 Confidence -> 32
MOZ : Encoding -> windows-1255 Confidence -> 98
www.nectec.or.th (41527)
ICU : Encoding -> ISO-8859-1 Confidence -> 37
MOZ : Encoding -> TIS-620 Confidence -> 77
feedparser.org (28443)
ICU : Encoding -> UTF-8 Confidence -> 100
MOZ : Encoding -> utf-8 Confidence -> 98

18.33 Sec

보시다 시피, CJK / UTF-8 / ASCII 를 제외한 다른 1byte 권의 언어들에 대해서는 Universal chardet 이 ICU chardet 보다 월등히 detecting 을 잘 하고 있습니다. 다만 안습인 것은, mod_charset 의 Universal chardet 이 Python C API 를 이용해서 python 을 호출하다 보니, ICU 보다 성능이 굉장히 많이 떨어집니다. 실제로 위의 결과를 Universal chadet 체크를 하지 않는다면, 대략 0.04초 정도에 결과가 나옵니디만, Universal chardet detecting 을 시키니 거의 20초 가까운 결과치가 나옵니다.

대략 테스트를 해 보니 문자열이 3K 정도가 넘어가면 Python C API 로 호출한 결과가 상당히 늦어지는 결과를 보이더군요. 대략 1K 이내의 경우에 어느정도 비슷한 속도가 나옵니다.

또한, 짧은 문자열에 대해서도 ICU 보다 Universal chardet 이 성능이 조금 더 좋더군요. 그래도 한글 기준으로 테스트를 했을 때, 한글 10글자 정도는 받아야지 왠만한 confidence 가 나오게 됩니다.

다음의 결과는 web page 에서 html code 를 삭제하고 나온 결과 입니다. 다음의 코드가 사용이 되었습니다.

$buf = preg_replace ('/<[^>]*>/', '', $buf);

보통 웹 페이지의 경우, <>로 쌓여져 있는 코드들은 대부분 ASCII 이기 때문에 확률적 판단을 하는 chardet 에 부정적인 영향을 줄것이라 생각을 하고 한번 시도를 해 보았습니다.

PHP mod_chardet result:

google.cn (2781)
ICU : Encoding -> GB18030 Confidence -> 100
MOZ : Encoding -> GB2312 Confidence -> 98
yahoo.jp (3561)
ICU : Encoding -> UTF-8 Confidence -> 100
MOZ : Encoding -> utf-8 Confidence -> 98
amazon.co.jp (30739)
ICU : Encoding -> Shift_JIS Confidence -> 100
MOZ : Encoding -> SHIFT_JIS Confidence -> 100
pravda.ru (15728)
ICU : Encoding -> windows-1251 Confidence -> 28
MOZ : Encoding -> windows-1251 Confidence -> 94
auction.co.kr (36084)
ICU : Encoding -> EUC-KR Confidence -> 100
MOZ : Encoding -> ISO-8859-2 Confidence -> 27
haaretz.co.il (44570)
ICU : Encoding -> ISO-8859-8-I Confidence -> 23
MOZ : Encoding -> windows-1255 Confidence -> 98
www.nectec.or.th (10425)
ICU : Encoding -> EUC-JP Confidence -> 64
MOZ : Encoding -> TIS-620 Confidence -> 76
feedparser.org (5854)
ICU : Encoding -> UTF-8 Confidence -> 100
MOZ : Encoding -> utf-8 Confidence -> 98

4.86 Sec

이렇게 detecting 을 하니 ICU의 결과가 조금 좋아졌으며 (하지만 오판하는 경우도 생겼군요), 텍스트 양이 줄면서 Python C API를 사용하는 Univiersal chardet 의 성능이 대략 5초 정도로 시간이 절약 되었습니다.

뭐 어쨌든 두가지 기능을 다 지원을 하고, PHP 에서도 Universal chardet 을 지원할 수 있다는 점에 일단은 만족을 하고, posting 과 함께 mod_chardet 을 공개합니다.

그리고 혹시나 단순히 euc-kr / utf-8 만 판단을 해야 한다면, chardet 은 overhead 일 경우가 많습니다. 이럴 경우에는 차라리 pear KSC5601에 있는 is_utf8 method 를 사용하시는 것이 훨씬 경제적/성능적 효과가 좋습니다. 물론 제가 만들어 놓은 것입니다 ^^;

코드는 http://cvs.oops.org/index.php?cvsroot=PHP-Module 에서 받으실 수 있으며, 소스 안의 test.php 를 참조 하시면 사용하시는데 별 무리는 없을 겁니다.
2009/02/19 05:12 2009/02/19 05:12

정균님 안녕하세요.

요 모듈 아직도 서포트 받을 수 있는지 궁금하네요 ^^

libtool 버전이 2.2.6으로 올라가면서 CDPATH관련 에러두 나구요. --tag를 찾네요

/home/sangjins/mod_chardet/php_chardet.h:104: error: expected specifier-qualifier-list before 'UErrorCode'
/home/sangjins/mod_chardet/php_chardet.c: In function 'zif_chardet_detect':
/home/sangjins/mod_chardet/php_chardet.c:375: error: duplicate case value
/home/sangjins/mod_chardet/php_chardet.c:367: error: previously used here
/home/sangjins/mod_chardet/php_chardet.c:392: error: 'CharDetObj' has no member named 'status'
/home/sangjins/mod_chardet/php_chardet.c: In function 'chardet_obj_init':
/home/sangjins/mod_chardet/php_chardet.c:422: error: 'CharDetObj' has no member named 'status'
/home/sangjins/mod_chardet/php_chardet.c: In function 'moz_chardet':
/home/sangjins/mod_chardet/php_chardet.c:442: error: 'CharDetObj' has no member named 'status'
/home/sangjins/mod_chardet/php_chardet.c:448: error: 'CharDetObj' has no member named 'status'
의 에러도 나네요; 잘 사용하다가 재설치 하려니 이런 문제가 발생했습니다;

바쁘신데 이거 실례가 되지 않을런지.. ㅜㅜ


libtool 과는 상관이 없습니다. ICU library가 지원되지 않을 경우에 처리 버그가 존재하고 있었네요. 이 버그 수정해서 0.0.3으로 release해 놓았으니, 0.0.3으로 해 보시기 바랍니다.

Ubuntu 9.04 의 기본 패키지들과 libchardet 1.0.1 로 build할 때 문제없이 되었습니다. ^^;


그렇군요. 그럼 라이브러리로 빌드하지 말고 그냥 소스를 직접 기존 프로젝트에 넣어버려야겠네요.
이래저래 신경써주셔서 감사합니다.


제 짧은 소견으로는 배포가 문제라면 귀찮게 소스 관리를 하시느니, 정적으로 link 시키는 것이 더 편하지 않을까 싶습니다. MPL 은 GPL 이나 LGPL 처럼 과격하지 않으니, static link 하시거나 dynamic link 하신 후에, MPL 라이센스 파일 하나 넣어 주시는 것으로 끝이 납니다. 전반적으로 GPL/LGPL로 배포를 하고 싶으시다면, 특정 부분에 call 을 MPL call 을 사용하신다고 명기를 하시면 될 것 같습니다. MPL은 다른 라이센스와 결합하는데 크게 지장이 없는 라이센스이니까요.


아...그렇게해도 되는군요. GPL과 MPL이 호환이 안된다고 해서, 문제가 될줄 알았습니다. 감사합니다.


그런거였군요. 감사합니다.
방금 다운 받아서 확인해보았는데, 라이센스가 MPL이더군요.
본래 소스는 MPL/GPL/LGPL중에 선택가능하게 되있던거 같은데, GPL로도 이용가능하게 배포하실 생각은 없으신가요...?


제가 개발하는 코드들은 대부분 필요에 의해서 제작을 하는 것입니다. 그렇기 때문에 순수하게 제가 처음부터 설계/코딩을 하는 경우 보다는 비슷한 것을 찾아서 제가 사용하기 편하도록 수정/개발을 하는 경우가 많습니다.

그러다 보니, 항상 license가 문제가 골치거리가 되는데, 가장 좋은 방법은 원 코드의 license 를 유지하는 것이 가장 편한 방법이더군요. 그리고 libcharset 의 원형이 Mozilla Universal Charset Detector 이기는 하지만, 저는 이 코드를 Perl Moudle 에서 친절하게 잘 분리해 놓은 것을 C wrapper 를 만들어서 c/c++ library 로 둔갑을 시켜 놓은 것입니다. 그리고 해당 Perl Module 이 license를 MPL로 해 놓아서 저 역시 이를 승계한 것이고요.

다만, Universal Chardet code 를 보면 MPL/GPL2/LGPL2.1 중에 하나를 선택할 수 있도록 되어 있습니다. 그리고, 저와 Perl module 개발자가 추가한 코드에서 이 문구는 역시 포함이 되어 있기 때문에 재배포를 하시고 싶고, license 를 변경하고 싶다면 저작권에 위배되지 않도록 결정을 하시면 될 것 같습니다.

저도 나름 살짝 고민했다가 GPL보다 MPL이 더 자유롭지 않을까 생각해서 MPL로 그냥 고민없이 승계를 했습니다.


libchardet을 쓰고 싶어서 다운 받으려고 했더니 사용자 이름과 암호를 요구하네요... 특정 그룹에게만 공개된 자료인가요...?


browser 로 접속하지 마시고 ftp client 로 접속 하시면 됩니다.


감사합니다!! libchardet으로 하니 에러도없이 바로 작동하는군요~

잘 사용하겠습니다 (__) 감사합니다


mod_chardet 0.0.2 로 업데이트 했습니다. Python C API로 지원하던 mozilla universal charset detect mode 를 제거하고, libchardet 을 만들어서 C++로 지원하도록 변경했습니다. 속도가 캡빵 빨라졌습니다. :-) python-chardet 보다 정확도가 조금 더 좋습니다.

ftp://ftp.oops.org/pub/oops/php/extensions/mod_chardet 에서 받으실 수 있습니다.

http://cvs.oops.org/?cvsroot=PHP-Module&module=mod_chardet&file=README,v&rev=1.3 를 참조해서 빌드 하실 수 있습니다.

이 버전은 libchardet 이 기본 모드로 지원되며, CHARDET_ICU mode 로 ICU chardet mode 를 사용할 수 있으며, 개발시의 debug mode로 CHARDET_PY (default option 아님) 를 이용할 수 있습니다.


안녕하세요 ^^

개발해주신 모듈 설치에 성공하였습니다.

다만 온라인 용으로 사용시의 예제가 필요한데 혹시 제작해주실 수 있으신지요..



source 안에 있는 test.php 와 http://cvs.oops.org/?cvsroot=PHP-Module&module=mod_chardet&file=Reference,v&rev=1.1 를 참조하시면 될 것 같습니다. test.php 역시 제일 첫라인을 제외하면 web에서 그대로 사용하실 수 있습니다.


"mozilla code 에 c++ 로 지원하고 있으니 이걸 포팅하면 되겠지 하고 쉽게 생각을 했는데, xpcom 구조를 알기 전에는 쉽게 뗄 수 있을 놈이 아니더군요." 라고 적어 놓았는데, Perl 모듈을 보니 가져다 사용하고 있더군요. 그래도 libchardet 을 c/c++ 용 library 로 만들어 보았습니다. mod_chardet 의 python c api 를 굳이 이용할 필요가 없어 졌네요. :-)

조만간 업데이트를 하겠습니다.

Filed under Tech/프로그래밍
요즘 하는 일이 Linux Server 들에 대하여 Active Directory 와 인증 통합을 하는 작업을 하고 있습니다. 물론 kerberos 나 ldap 을 이용해서 Linux Server들의 인증을 하는 것은 아니고, Windows 2003 R2 에 Server For Unix 의 NIS password entry 를 받아와서 Linux NIS server 를 운영하게 하는데, 이 과정에서 AD 정도 변경이 실시간으로 Linux NIS Server 로 반영이 되게 하기 위해서 관리 tool 을 만들고 있습니다.

이 과정에서 PHP Ldap API를 이용하여 Active Directory 를 관리하는데, 다른 정보를 변경하는 것은 별 무리가 없으나, Active Directory 의 Password 를 변경할 경우, AD에서 ldap ssl 로 연결을 할 경우에만 Password 변경이 가능 합니다. 이 부분 때문에 엄청난 삽질을 하게 되었습니다. 뭐 기본적으로 ldap 에 대한 지식이 별로 없었던 것이 삽질의 가장 주된 원인이기는 했지만, 검색에 걸린 대부분의 문서들이 ldap 에 대한 지식이 있다는 가정하에 설명을 하다보니 미치고 환장하겠더군요 ^^;

각설하고, 여기에서는 Active Directory 의 Password 변경이 가능하도록 PHP에서 Ldap SSL 로 연결하는 것에 대한 설명을 하고자 합니다.

기본적인 전제 조건으로는, Windows 2003 에 Active Directory Domain controller 가 구성이 되어 있고, 이 서버에서 Ldap SSL (ldaps://) connection 이 가능하도록 설정이 되어 있다는 가정하에 설명을 하도록 하겠습니다. Domain controller 에 Ldap SSL 을 설정하는 것은 googling 으로 쉽게 찾을 수 있으므로.. 생략 하도록 하겠습니다.

1. Client 에서 사용할 CACERT 인증서 생성

Domain controller 에서 사용되는 인증서를 "DER로 인코딩된 X.509 바이너리(.CER)" 로 export 를 합니다. export 한 CA 인증서를 Unix 서버로 이동한 후에, 다음의 명령으로 .pem file 로 전환을 합니다.

shell> openssl x509 -in cacert.cer -inform DER -out cacert.pem -outform PEM

2. PHP Ldap Extension 확인

phpinfo() 함수를 이용해서, ldap extension 이 지원되는지와, ldap 에서 SASL 지원이 되는지를 확인 합니다.

LDAP Support => enabled
RCS Version => $Id: ldap.c,v 2008/05/04 21:19:17 colder Exp $
Total Links => 0/unlimited
API Version => 3001
Vendor Name => OpenLDAP
Vendor Version => 20327
SASL Support => Enabled

3. Coding

Active Directory 에서 AD Password 는 unicodePwd 라는 entry 에 UTF16 형식의 plain text 를 입력을 해 주면 됩니다. 이 의미는 abcd 를 입력하려면 'a\000b\000c\000d\000' 과 같이 입력을 하면 된다는 의미 입니다.

간단하게 코드의 예를 들자면 다음과 같이 생성할 수 있습니다. (단 주의할 것은 ASCII 범위 밖의 문자열을 입력하시면 안됩니다.)

function make_ad_passwd ($pass) {
$pass = '"' . $pass . '"';
$len = strlen ($pass);

for ( $i=0; $i<$len; $i++ )
$newpass .= $pass[$i] . "\000";

return $newpass;

그럼, AD password 함수를 변경하는 코드의 예를 보도록 하겠습니다. 이 코드에서 중요한 것은, 또는 다른 문서에 나오지 않는 내용은, unicodePwd entry 를 변경하기 위해서는 ldap ssl 연결을 사용해야 한다는 것이고, 또 하나는 SSL 연결을 위한 인증서 설정 입니다.

# SSL 로 접속을 해야 하기 때문에 ldaps:// protocol 을 사용한다.
$host = "ldaps://ad.domain.controller.com";
# ldaps 의 기본 포트는 636 을 사용한다.
$port = "636";
# 인증서 설정
$certfile = '/some/path/cacert.pem';
# default DN
$defaultdn = 'domain_manager@DOMAIN.NAME.COM';
$accesspw = 'password_of_domain_manager';
# 관리 OU
$ou = "OU=Users,DS=DOMAIN,DS=NAME,DS=com"

$username = $argv[1];
$userpass = $argv[2] ? $argv[2] : 'abcd';

if ( ! $username ) {
echo "ERROR: You must input changed username on argv[1]\n";
exit 1;

# system 의 ldap 설정을 건드리지 않고 하기 위해서 다음의 환경 변수를 설정한다.
putenv ('LDAPTLS_REQCERT=never');
putenv ("LDAPTLS_CACERT={$certfile}");

$ldap = ldap_connect ($host, $port);

if ( $ldap === false ) {
echo "ERROR: connect failed to $host\n";
exit 1;

$bind = @ldap_bind ($ldap, $defaultdn, $accesspw);
if ( $bind === false ) {
echo ldap_error ($ldap) . "\n";
exit 1;

$filter = "(samaccountname={$username})";
$result = ldap_search ($ldap, $ou, $filter);
ldap_sort ($ldap, $result, 'sn');
$info = ldap_get_entries ($ldap, $result);

for ( $i=0; $i<$info['count']; $i++ ) {
echo "You are changing the password for " .
$info[$i]['givenname'][0] . ", " .
$info[$i]['sn'][0] . " (" .
$info[$i]['samaccountname'][0] .
") to {$userpass}\n";

$userdata['unicodePwd'] = make_ad_passwd ($userpass);
$result = ldap_mod_replace ($ldap, $info[$i]['distinguishedname'][0], $userdata);

if ( $result === false )
echo "There was a problem changing your password, please call IT for help\n";
echo "Your password han been changed!\n";
@ldap_close ($ldap);
2009/01/28 21:50 2009/01/28 21:50

필자님의 조언 너무 감사합니다.

제가 공부해야 할 부분이 너무 많은것 같지만 필자님 덕에 하나하나 발전하고 있습니다.

혹시 궁금한 점이 있으면 부담없이 여쭈어 보겠습니다. ^^;


담변 감사합니다.

SFU 3.0를 간단히 테스트해보았습니다. 테스트하면서 글을 읽으니 많이 도움이 되고 있습니다.

그런데 필자님의 글에 다른 의문이 하나 더 생겼습니다.
password sync 이 부분인데요 Windows AD의 유저, 패스워드를 어떤 식으로 Linux하고 동기화 시키는지 잘 모르겠습니다.

예로 생성파일을 user id로 정했다면 UFS를 통해 유저의 ID를 리눅스 시스템 인지하는 것은 어느정도 알겠는데 passwd 부분에서 어떻게 동기화를 시키는지 궁금합니다.
그러므로 사용자의 AD암호만 변경하면 실제로 서비스를 하는 Linux NIS까지 암호가 변경이 이해가 잘 가지 않습니다.

자꾸 귀찮게하는것 같습니다. 아직 많이 부족하여 자꾸 질문을 드리게 됩니다.
조언 기다리겠습니다.




너무 대단한 작업으로 생각 하시는 것 같습니다. :-) sync 는 간단하게 Linux NIS 에서 ypcat 으로 AD의 NIS entry 를 가져와서 파싱하여 Linux NIS entry 를 새로 생성하는 것 뿐입니다. 즉 AD의 NIS entry 에서는 userid/passwd field 만 사용하고, 나머지 정보는 Linux NIS 서버에서 알아서 취급을 한다는 의미입니다.

현재는, ypcat 을 사용하지 않고, Linux NIS 서버에서 LDAP 으로 AD의 SFU entry 들을 가져와서 NIS entry 를 만들고 있습니다. ^^;


안녕하세여.. 지금 LDAP을 공부하고 있는데 궁금한 점이 있어 여쭈어 보려합니다.

Windows AD군과 Linux LDAP 연동인지를 알고 싶습니다.

글에 보면 Windows 2003 R2에 있는 Unix passwd entry 받아와서 Linux NIS server

로 운영하신다하셨는데 아직 제가 부족해 이해가 좀 힘드네요


Windows 2003R2 부터는 MS 예전에 application 으로 제공해 오던 Service For Unix (SFU) 를 service 로 제공합니다. 그래서 SFU에 있는 NIS를 이용해서 AD에서 NIS service 를 할 수 있습니다. 그런데 SFU의 NIS의 문제가 AD entry 에 multibyte 문자가 존재할 경우 예를 들어 CN 값을 한글 이름으로 지정할 경우, 관리툴에서 Unix Attribute tab 의 활성화가 되지 않습니다. 그래서 power shell 로 CN부분을 id와 동일하게 넣고선, Linux 에서 AD의 nis entry 를 받아와서 CN부분을 LDAP으로 값을 가져와서 복구시킨 후에 Linux NIS 에 entry 를 생성하는 방식을 사용한 것입니다. 즉, AD의 NIS는 password sync 를 위해서만 사용을 하고, Linux NIS가 실제 NIS 서비스를 하는 셈이 되는 것이죠.

이렇게 구성하면 사용자 입장에서는 AD의 암호만 변경을 하면 NIS까지 같이 변경이 되니 2군데 암호를 변경할 필요가 없게 되는 것이고요. 그리고 이렇게 이원화를 해 놓으면, OU별로 별도의 NIS entry 를 구분할 수 있는 점이 이런 설계를 가져오게 된 것입니다. 즉, 이 문서에서의 LDAP은, Linux NIS 에서 AD에서 가져온 entry 를 복구하기 위하여 사용을 하는 꽁수 때문에 작성이 된 것입니다.

Filed under Tech/프로그래밍
오랜만에 JSBoard 와의 조우를 하고 있습니다. 회사일 때문에 JSBoard는 이제 거의 뒷전으로 밀린 상태였는데 (안녕 리눅스도 회사일에 밀리는 판국에 JSBoard 야 더 할말이 없겠죠 ^^) 제가 관리해 주고 있는 서버의 계정에서 방치된 JSBoard의 스팸을 보니 갑자기 오기가 나더군요.

어떤 게시판이라도 방치를 해 놓으면 어쩔 수 없겠지만, JSBoard 야 하물며 요즘의 스팸 attack 에는 제대로 대응을 할 수 있는 기능이 없으니 더 하겠죠. 이 문제 때문에 제 주위에도 JSBoard 사용을 포기하신 분들을 꽤 많이 봐 왔음에도 불구하고 직접 보니 확 다가 오네요 :-)

JSBoard .. 분명 제게서는 이미 관심사에서 멀어진 작품이기는 합니다. 더 이상 개발의 이슈도 없었고, 웹 프로그래밍이 제 주 전공 분야가 아니다 보니, 다른 프로젝트로 전환을 하지 못해 어떻게 보면 시대에 뒤떨어진 작품이 되고 말았습니다.

JSBoard last release

위의 이미지 같은 안습에, 마지막 릴리즈도 2년전이니.. 한 때는 정말 나름 웹을 풍미하던 프로그램이 이제는 그저 명맥만 유지하는 모습을 보이고 있는 것 같습니다. 그래도 나름 제가 만든 프로그램이라는 책임하에 보안버그 fix 와 아래 로그와 같이 release 는 되고 있지 않았지만 개발은 꾸준히 명맥을 이어오고는 있습니다.

JSBoard 2 Changelog

JSBoard 2 외에 JSBoard 2.1 tree 도 계속 진행 중이지만 아직 생각해둔 기능들을 미처 추가를 하지 못해서 release 는 까마득 하고.. (그래도 기능 추가 외에는 JSBoard 2 만큼의 안전성은 가지고 있다고 생각 됩니다.)

그래서 모처럼 JSBoard 에 시간 투자를 해 보았습니다. 우선적으로 스팸에 어느정도는 항거해 보고자, 먼저 Captcha image 를 지원하도록 수정을 했으며, 몇몇 스팸 관련 기능을 수정하였고, 예전의 JSBoard christmas release 를 올해 한번 해 보려고 시간을 조금씩 투자를 해 보려고 합니다.

올 12월 25일에는 JSBoard 2.0.14 를 기다리는 사람은 없겠지만 한번 release 해 볼까 합니다. ^^;
2008/12/05 01:42 2008/12/05 01:42

JSBoard 오랜만에(?) 새 릴리즈 메일을 받고 감회(?)가 새롭더군요.
지금은 XE로 몽땅 이전한 상태라 JSBoard는 한구석에서 그동안 쌓였던 글들을
보관만 해주고 있습니다. 그녀석도 업그레이드 해줘야 겠네요 ^^
한해 마무리 잘하시고 건강하세요. :)


흐.. 겨우 시간 맞춰서 등록을 했습니다. 마눌님가 아기의 공습을 피해서 겨우겨우 시간을 맞추었네요. 2008년에도 어김없이 Christmas version 을 릴리즈 했습니다.


기대해 볼께요~~ ^^

Filed under Tech/프로그래밍
얼마전 우연히 RoundCube Webmail 이라는 걸 알게 되어 0.10statble 버전을 설치해 보았습니다. 일단 설치해 본 결과 상당히 깔끔하다는 인상을 받았는데.. stable 이라는 버전에 맞지않게 버그들도 좀 보이더군요.

기타 등등 각설하고, 일단 가장 큰 문제는 한글이 깨지는 문제가 있다는 것입니다. 물론 잘 나오는 메일도 있겠지만, 이런 문제가 발생하는 것은, 메일의 헤더나 multi-part 의 header 에 charset 이 지정되지 않았을 경우, RoundCube 가 charset 을 US-ASCII 로 강제 하는데서 발생하는 문제입니다. 더 정확히는 RoundCube 가 US-ASCII 로 처리하는 것이 아니라 imap server 가 그렇게 처리하게 됩니다. (이건 wu-imap 에서의 문제입니다. 다른 imapd 에서는 어떨지 모르곘군요.)

wu-imap package 를 사용하시는 분들이나 charset 이 지정되지 않은 경우 메일이 깨지면 다음의 patch 를 해 보시기 바랍니다.

0.1 patch file

0.1.1 patch file

patch file 을 잘 보시면 main.inc.php 에

$rcmail_config['default_charset'] = 'euc-kr';

와 같이 지정하는 것이 있습니다. 이걸 지정해야 charset 이 없을 경우 기본 charset 으로 처리하게 됩니다.
2008/10/01 02:26 2008/10/01 02:26

이 쓰레드가 여기까지나 진행이 되었네요... ^^
예전 포스팅한 글을 보고 다람쥐를 내리고 RoundCube를 올렸었는데..
한글등 여러 문제로 사용하지 않고 있었는데요..

날로 먹는 기분이네요.. 고생해주신 덕분에 감사히 잘 사용토록 하겠습니다.


답변 감사드립니다..

귀중한 시간을 빼앗은것 같아 대단히 죄송합니다.

제출한 patch를 적용해보니 문제 없이 잘되네요...
많은 도움 얻어 갑니다.


여기 저기 찾아가며, 설치는 했는데 여러가지 문제가 많네요...
그래서 도움 좀 구하고자 합니다...

현재 설치 버젼은 trunk-r1993 입니다.

문제1. roundcubemail에서 메일을 보내고 Outlook Express에서 회신을 하게 되면...
회신 내용이 roundcubemail에서 깨져 보이네요..(헤더 정보를 보면 UTF-8로 보내서 UTF-8로 받는데...그리고 MS-Outlook에서 회신하게 되면 roundcubemail에서 깨져 보이지 않습니다. Outlook Express만의 문제인것 같습니다만...)

문제2. 최신 버젼은 아래와 같이 main.inc.php 파일에 설정하는 부분이 있습니다.
0, 1번 설정에 대해서는 파일첨부하여 보낼시 한글파일명이 깨집니다.
그리고 2번 설정에 대해서는 긴파일명(한글)에 대해서 깨집니다.

// Encoding of long/non-ascii attachment names:
// 0 - Full RFC 2231 compatible
// 1 - RFC 2047 for 'name' and RFC 2231 for 'filename' parameter (Thunderbird's default)
// 2 - Full 2047 compatible
$rcmail_config['mime_param_folding'] = '설정번호'

위 2문제로 낑낑대고 있는데...잘안되네요. 도움좀 부탁드립니다.


첫번째 OE 가 보낸 메일을 못 읽는 것은 UTF8 BOM 때문입니다. 보통 Unix 군에서는 UTF8 BOM을 사용하지 않는 것을 권장하고 있는데, MS의 몇몇 application (특히 notepad) 들이 BOM code 를 사용하고 있습니다. 여기서 OE가 UTF-8 encoding 을 할 때 BOM code 를 넣는 것 같군요. 일단 BOM code 제거를 하니 제대로 출력이 되는 것을 확인했습니다.

그리고 두번째 문제도 수정을 하기는 했습니다만, 패치를 받아 줄지는 모르겠군요. 딱히 버그라고 할 수도 없고, RFC2047에 보면 encoding 된 문자열이 75byte 가 넘지 않아야 한다고 되어 있어, roundcube 에서는 75자가 넘어갈 경우 그냥 뒤를 버려 버리므로서 발생하는 문제입니다. rfc2047에 의거하면, 75자가 넘을 경우, carrage return, new line, space를 이용해서 그 이후의 string 을 연결하면 된다고 되어 있어, 이렇게 수정해서 패치를 제공하기는 했습니다만.. 받아 들여줄지는 저도 보장은 못하겠습니다. :-)

일단, 두가지 문제에 대해서 patch는 제출한 상태이니 기다려 보시기 바랍니다.

오늘 하루 꼬박 날라갔군요. 앞으로는 더 이상 roundcube 문제 해결에 관여하지 않을 생각 입니다. roundcube 의 code 가 엄청나게 복잡한 관계로 문제가 되는 부분을 찾는데 걸리는 시간이 대부분이다 보니 회사에서의 눈치가 장난이 아닙니다. 제가 roundcube 를 굳이 사용하는 입장도 아닌 상황에서 무상 지원은 쉽지 않을 것 같습니다.

그리고 더 중요한 것은 끝이 없어요 T.T 저는 봉이 아니랍니다. ^^


http://trac.roundcube.net/ticket/1484961 에서 거부당했던 패치의 ticket 이 다시 열렸습니다. 0.2 에서 해당 내용이 많이 반영이 되었는데, 아직 좀 부족한 편입니다.

일단, charset 에 상관없이 charset 이 잘못 출력될 수 있는 버그 2개에 대한 패치를 제공한 상태이며, 여전히 body 에 charset이 지정되지 않았을 경우, IMAPD 가 US-ASCII나 X-UNKNOWN을 리턴해서 발생하는 부분은 여전히 고쳐지지 않았습니다. 그래서 패치를 다시 제출한 상태인데, 잘 받아들여질지는 모르겠군요.

다만, 해당 ticket 에 제시된 이미지들이 좀 낯뜨거운 이미지들이군요.. ^^; sample 제출을 잘 못한듯.. ㅋㅋ


Message body 에 charset 이 지정되지 않았을 경우가 문제가 되고 있네요. 개발자들이 사용하는 imapd 인 Courier의 경우에는 charset 이 지정되어 있지 않을 경우 NIL을 return 하기 때문에 제대로 보이는데, Cyrus-imapd 나 Wu-imapd 의 경우에는 US-ASCII 나 X-UNKNOWN을 return 하기 때문에 깨지는 문제가 발생하는데, 이 부분에 대한 조율이 쉽지 않네요. 쩝.. 0.2 에서는 이 문제가 해결이 되어 나올지 쉽지 않은 문제인것 같습니다.

문제가 하도 많아서.. SSL 모드시에 헤더 출력 부분은 현재 무시된 상태이고, 리스팅에서도 CHARSET을 가진 제목이 있을 경우 다음 나오는 제목이 CHARSET이 없을 경우 이전의 CHARSET 이 유지되는 문제도 있는데 역시 묻히고 있는 듯한 기분이 ^^;

안되는 영어로 하려니 저도 힘들고.. 보는 사람도 힘들지 않을까 예상 됩니다. ㅋㅋ


답변 감사합니다.
덕분에 메일부분은 잘 정리 된듯합니다.
많은 지식을 얻어 갑니다. ^_^

앞전에 적으신 "안녕리눅스 틈새 시장노린다~" 라는 글에 많은 도움 얻었습니다.
이번엔 freeradius + pptpd(poptop) + mysql + dialup_admin 연동하고 OpenWRT(DD-WRT)를 이용하여 공유기를 VPN장비로 사용 할 수 있도록 할 예정입니다.

목표는 공인아이피 대역을 공유기로 내려주고 공유기에서 각 할당된 공인아이피를 클라이언트로 재분배 하도록 할예정입니다.

제가 지식이 부족해서 많은 도움 부탁드리겠습니다. ^_^


전달 받은 내용대로 소스를 수정하니, 문제는 해결되었습니다.
전달해 주신 내용을 천천히 읽어 보니...

예전에 제가 해결하지 못한 imap server charset 문제로 결론을....

예전에 vpopmail + procmail 연동을 해서 "한글"로 차단을 하여 사용을 하였습니다.
아래와 같이 캐릭터 셋을 강제로 변환해서 적용하면 roundcube 웹메일에서 한글로 된 제목 캐릭터가 모조리 다 깨져어요.ㅡㅡ;

뭐 스팸으로 버리지 못했다면 제목을 원복을 해야 하는데...ㅎㅎ

결론은 imap default charset이 있다면 해결 될수 있었다는 답이 나왔는데...

제 느낌으로는 소스 수정으로 procmail 부분까지 해결 될듯 한데요???? 맞는지..?? ^_^

여튼 고생 많으셨습니다.
- 감사합니다 - (_ _);;

[root@ns etc]# cat procmailrc
VIRTUALHOME=`/home/vpopmail/bin/vuserinfo -d $EXT@$HOST`

:0 Efhw
|formail -c | /usr/bin/hcode -dk -m

:0 Efhw
|formail -c | /usr/bin/hcode -dk -m

:0 Efhw
|formail -c | /usr/bin/hcode -dk -m

:0 Efhw
|formail -c | /usr/bin/hcode -dk -m

:0 BfHw
|formail -c | /usr/bin/hcode -dk -m

*^Subject: .*(\{광|\[광|\(광|포르노|포X노|광고|광\ 고|홍보|광-고|성인|최저이자|기록\ 안남아요|대출|광1고|廣告|sex|SEX|porno)

*^Subject: .*대박


이건 procmail 의 변환 문제와는 별개 입니다. header 에 charset 이 정의 되어 있느냐 안되어 있느냐의 문제이기 때문입니다. 정의가 되어 있다면 수정하지 않은 roundcubemail 이 잘 처리하고 있기 때문입니다. 문제가 되는 것은 charset 이 정의 되어 있지 않은 메일까지 처리를 하려고 하다 보니 이런 문제가 발생을 하는 것이죠.

원래, MUA를 이용해서 정상적으로 메일을 보내는 경우는 거의 깨지지 않을 겁니다. 다만 스팸이나 웹에서 메일 발송 처리를 하는 것들 중에서 메일 파트 구성을 자기 멋대로 하는 경우가 문제가 발생되는 것이죠.

그래서 그냥 지금 imapd 에 default charset 을 지정하여 무조건 US-ASCII가 나오지 않도록 수정을 해 보고 있기는 합니다. 다른 imapd 는 써 본적이 없어서 고치지는 않겠지만 ^^;


흠.. roundcubemail 개발자와 bug tracking 을 하다가 좀 안습인 상황인 것을 발견했군요.

일단, 메일을 보낼 때 charset 을 정의해서 보내지 않은 메일을 제대로 뿌려주지 않아도 된다면 (Default charset 을 사용하지 않아도 되는 경우죠. 위의 02번 패치를 적용하지 않아도 된다면..) 03번 패치가 필요 없습니다. 03번 패치를 하지 않아도 roundcubemail 이 잘 처리를 해 준다는 의미입니다.

하지만, charset 이 정의되지 않은 메일 (Imap server 는 이 경우 US-ASCII를 return 합니다. 그래서 깨지는 거죠.) 을 US-ASCII 대신 default charset 으로 처리할 경우, 다른 영역에서 같이 사용하는 부분에 영향을 미치게 되어 더 수정을 하게 되는 것이죠.

프로그래밍 적으로는 위의 패치를 다 적용해서 제대로 하는 것이 맞겠지만, 실제로는 IMAP 서버가 default charset 을 지정해서 없을 경우 US-ASCII 대신 DEFAULT CHARSET 으로 return 해 줄 수 있다면.. 더 좋은 방법일 듯 싶습니다.

즉, 제가 roundcubemail 이 수정한 부분 때문에 영향을 받아서 계속 고치고 있느니 IMAP Server 를 수정하는 것이 더 간단한 일이 되어 버리게 되네요 쩝..

이런 안습인 상황이 나오다니 T.T


정말 이번 패치를 적용하고 여러가지 테스트를 해보니 다운로드가 잘됩니다. ^_^
정말 감사합니다.

패치를 적용하고 나서 아래와 같은 새로운 문제가 생겼습니다.(_ _);;

## 한글 메일폴더가 깨지는 현상 ##

## 설정 화면엔 한글이 정상적으로 출력 됩니다. ##


음.. 함수를 정말 재활용 많이 하는 군요. --; 마지막 패치에 약간 수정을 해야 할 것 같군요.

roundcubemail/program/include/rcube_shared.inc 의 576라인에서

if ( preg_match('/MSIE/', $_SERVER['HTTP_USER_AGENT'])) {


if ( $_GET['_download'] && preg_match('/MSIE/', $_SERVER['HTTP_USER_AGENT'])) {

와 같이 수정해 주십시오.

본문의 패치들은 이 변경사항을 반영하여 다시 올려 놓았습니다.


일단 환경은 CentOS4.6에서 기본적인 APM을 사용하고 있습니다.
최근에 제작된 패치로 웹 메일서버를 재설치 하였습니다.
메일환경은 qmail+vpopmail+dovecot+mysql 로 설치 되어 있습니다.

패치 2개를 실행 후...

$rcmail_config['locale_string'] = 'kr';
$rcmail_config['default_charset'] = 'euc-kr';

이부분만 처리하면 한글부분은 깔끔하게 해결됩니다.(첨부파일 링크 제외)

첨부파일 링크를 해서 메일 확인을 누르고 다운을 받기위해 링크를 클릭하면 아래와
같은 화면이 나옵니다. mod_url은 모듈은 내렸습니다.

## 캡쳐화면 링크해 보냅니다. ##
http://www.zosel.net/cp1.jpg // 페이지 표시 할수 없음
http://www.zosel.net/cp2.jpg // 에러 메세지 나옴

번거롭지만 꼭 좀 부탁 드리겠습니다.


패치 올렸습니다. roundcubemail-0.1.1-UGLY-IE.patch 파일을 받으시면 됩니다. 이 문제는 오로지 IE에서만 발생하는 UGLY-IE 패치입니다. 이건 제작자 탓하기는 좀 그런데, 이 패치에 포함된 SSL관련 패치는 제작자가 좀 무심했었듯.. 이건 리포팅하면 받아질 것 같군요.


oops님, 이번에 만들어 주신 파일 패치를 적용하였는데...
한글 첨부가 되지 않네요.~
(첨부는 되지만, 다운로드 링크 활성화 되지 않습니다.)

## 아래 결과 ##
[root@ns html]# patch -p0 < roundcubemail-0.1.1-multibyte-attach.patch
patching file roundcubemail-0.1.1/program/include/rcube_imap.inc
patching file roundcubemail-0.1.1/program/include/rcube_shared.inc
patching file roundcubemail-0.1.1/program/lib/Mail/mime.php
patching file roundcubemail-0.1.1/program/lib/Mail/mimePart.php
patching file roundcubemail-0.1.1/program/lib/imap.inc
patching file roundcubemail-0.1.1/program/lib/is_utf8.class.php

## 위 적용 완료 후 한글 첨부파일을 웹메일로 보내고 받기함 //
한글 첨부에 링크가 활성화 되지 않음.
원인이 뭘까요?


일단 어떻게 안되는지를 보여 주셔야 할 것 같고요. (제가 인지하지 못한 부분일 수도 있으니까요.

그리고, config/main.inc.php 에서

$rcmail_config['locale_string'] = 'kr';
$rcmail_config['default_charset'] = 'euc-kr';

두가지 설정이 되어 있나요?

그리고, mod_url 설정 되어 있으면, rcube 에서는 off 시키도록 하세요. UTF8 로 오는 메시지가 변경되면 서버에서는 UTF8로 인코딩 하고 실제 넘어온 것은 EUC-KR이 되면 엉뚱한 문제가 발생할 수 있습니다.


너무 고생 많으셨습니다.
저도 손꼽아 기다리고 있었답니다. ^_^
이글 보는 즉시 바로 적용해 볼려고 합니다. ^^
수고 많으셨습니다.
그리고 감사합니다.


너무고생하셨습니다. 감사드립니다~

낼출근하면 언능적용해봐야겠네요~^^


좀 삽질 하느라 오래 걸렸습니다. patch는 지난주에 만들었는데, UTF8 체크하는 부분을 만들다 라이센스 문제로, 아에 KSC5601 이라는 pear package 까지 만들어 버렸습니다. KSC5601 <-> Unicode (UCS4/NCR) <-> UTF8 을 통합적으로 관리할 수 있도록 하며, 예전에 만들어 놓았던 꾸질한 것들의 성능도 상당히 개선 시켰습니다.

이런 딴짓하느라 좀 오래 걸렸고, 오늘 마침 테스트 하다가, 이 패치 때문에, 첨부 이미지가 출력이 되지 않는 버그까지 잡아서 올립니다.

수정하면서 코드를 보다 보니, 열심히 만들었구나 하는 생각은 드는데, multibyte 관련 지원은 거의 없다고 보는 편이 맞을 것 같더군요. 아니 웹/메일상에서의 multibyte 관련 지식이 거의 없는 듯 싶은 느낌이 들었습니다.


예~ 감사합니다.
roundcube mail 이 고객쪽에 제공될 웹메일이라...^_^
이부분만 해결되면 한글 유저들에게 정말 유익한 웹메일이 될 것 같습니다.
항상 힘써 주셔서 다시 한번 감사 말씀 드립니다.


오늘도 혹시나 하는 맘에 들어 왔습니다.
아~ 수정한 것 같다고 하니, 한편으로 마음이 편안해 집니다.
수정패치는 언제 나오나요. 수정된 파일만 전달 받았으면 하는데...
혹시 가능 하다면 부탁 드리겠습니다.


다음주 내로는 나올 겁니다. UTF-8 관련 처리하는 부분의 코드가 라이센스가 걸려 배포하기가 좀 그래서 아예 새로 작성하고 있습니다. :-)

Filed under Tech/프로그래밍
상용 프로그램을 판매하는 아니, 무언가를 판매하는 회사에는 C/S 조직이 있기 마련입니다. 후진국이나 작은 회사가 아니고서는 customer 의 반응을 무시한다는 것은 곧 자멸하는 것과 마찬가지이기 때문입니다. (덕분에 제 아내도 C/S로 얼마동안 밥벌이 하기도 했습니다.)

제가 오픈소스 활동을 하면서 느낀점은 대부분의 오픈소스 개발자들에게 이 개념이 전혀 없다는 것입니다. 물론 회사에서 개발자가 C/S 개념을 가질 필요는 없을 수도 있습니다. 하지만 오픈 소스의 경우 프로젝트 리더가 곧 CEO와 마찬가지 이기 때문에 결국에는 개발자가 C/S 개념을 가져야 할 수도 있다고 생각합니다.

제가 오픈 소스 활동을 하는 이유는 이상적인 취미나 재미를 위해서는 절대 아닙니다. 제가 밥벌어 먹는데 상당히 중요한 역할을 하기 때문에 오픈소스 활동을 유지하고 있습니다. 하지만 저 말고도 시작은 이상적인 취미나 재미를 위해서 일지 모르겠지만, 그 프로젝트를 5년이상 유지하는 개발자의 경우 이상적인 부분말고 분명히 저와 같이 물질적인 보상 때문에 유지하는 경우가 더 많을 거라 생각 합니다. 그 물질적인 보상이 직접적이지는 않더라도 말이죠.

그렇다면 프로젝트의 산물은 회사의 Product 와 같은 개념이 됩니다. Product 를 더 많이 팔아 이윤을 남기기 위해서, 또는 내 프로젝트의 산물이 널리 사용해 져서 내 name value 가 높아져 내 연봉에 도움이 되게 하기 위해서는 결국에는 사용자는 customer 가 되게 됩니다. 이 customer 의 feed back 을 아주 중요하게 생각해야 한다는 것이죠.

하지만, 대부분의 open source 개발자들은 하잖은 일부 유저들이 올린 패치나 의견을 아주 더러운 기분이 들게끔 하면서 거부를 합니다. 비록 그들이 무시하지 않았다고 항변을 하더라도, 권위적이고 아주 귀찮다는 듯이 또는 표준이나 규약을 핑계삼아.. 너무나 뻔히 보이는 거부 핑계를 대는 것이죠. nateon 이 리눅스용 client 지원 요청에 대응하는 것과 비슷하겠지만 그래도 nateon 의 답변은 아주 정중하죠 ^^

제가 개발을 잘하는 것은 아니지만, 나름대로 필요한 것은 만들어 사용할 수 있는 능력이 되고, 또한 이렇게 만든 것을 open 하여 공유를 하고 있는 입장에서, 다른 개발자들의 행태를 보면 좀 이해를 할 수가 없습니다.

제가 생각하기에는 가장 중요한 것은 조화입니다. 하지만 대부분의 개발자들은 조화 보다는 제약을 좋아하는 것 같습니다. 더군다나 그 제약이라는 것에 대하여 제가 받은 느낌들은 대부분 거절을 하기 위한 핑계로 보인다는 것이고요. (그래서 저는 개인적으로 RMS를 좋아하지 않습니다. 제게는 꼭 파쇼처럼 보이거든요)

어떠한 의견이 제시되면, 왜 이런 의견이 제시가 되었을까? 난 이해가 되지 않지만 이런 의견이 제시가 되었다면 문제가 있는 것이 아닐까? 라는 진행이 되는 곳을 한번도 만나보지 못했다는 것이 이해가 되지를 않는 군요.

제목은 거창하게 적었습니다만.. 결국에는 푸념이 되고 마는..

이 글은 제가 패치를 제출한 어떤 프로젝트의 개발자와 설전을 하다가 관점의 차이를 인정하지 않는 짜증나는 개발자 때문에 적는 글입니다. 모든 개발자가 다 그렇지는 않을거라 믿습니다. :-)
2008/04/20 05:37 2008/04/20 05:37

c/s의 개념을 오픈소스 개발자들이 갖는 것은 상당히 어려운 일일 것 같습니다. 일반적인 개발자들도 그렇고요.

대체로 프로젝트 초기 단계에서는 외부로부터의 기능추가/수정 요청이나 패치에 대해 매우 환영하고 수용적이지만 시간이 갈수록 어느정도 프로젝트가 안정화되고 뭔가를 추가하는 것보다는 더이상 뺄 것이 없는 상태를 지향하게 된다면 보수적으로 바뀔 수밖에 없습니다. 그시점을 좀더 넘어간다면 외부로부터의 input이 귀찮을(?) 수도 있는 것이지요.

결국엔 어떻게 접근하느냐의 문제로 귀결되겠지만 사람과 사람사이의 문제가 아닐까 합니다. 오픈소스 프로젝트 개발자들에게 조금더 개방적이고 수용적인 자세를 기대하는 것은 자연스러운 일이라고 생각하지만 그것이 must가 되어야 하는 것은 아니기 때문에 오픈소스라고 해서 특별히 다른 잣대를 댈 필요는 없다는 것이죠... ㅎㅎ


그걸 잘 알기 때문에 다른 오픈소스에의 참여가 망설여 진다는 것이죠. 참여해서 내가 해야할 일 보다 다른 무언가를 더 노력해야 한다는 것이 과연 가치있는 일을 하는 것인가 나 자신에게 반문을 하는 것입니다. 다만 그 작업이 별로 가치있을 것 같지 않다는 생각이 더 우세하니 문제겠죠. ^^

Filed under Tech/프로그래밍
이전에 포스팅한 CVS Web Interface 를 드디어 공개합니다. 아마 초기 버전이라 버그가 숭숭 나올것 같기는 한데.. 그래도 :-) 다음은.. OOPS-CVSd 의 README 파일의 일부입니다.

$Id: README,v 1.2 2007/11/07 07:50:04 oops Exp $ OOPS-CVSd Copyright @ 김정균 All right reserved sinse 1997 OOPS CVSd는 CVS 저장소의 웹 인터페이스이며, 웹에서 CVS 저장소의 상황을 손쉽게 확 인 할 수 있습니다. 이 프로그램은 FreeBSD 프로젝트 중의 하나이자 Web CVS 프로그램 중에서 가장 대표적인 cvsweb (http://www.freebsd.org/projects/cvsweb.html)의 기능 을 충실하게 지원하고자 했으며, cvsweb이 지원하지 못하는 아쉬운 기능들을 추가하고 한국어 환경에 최적화를 한 프로그램입니다. 1. 지원 세부 사항 1. CVS server 1.1 / 1.2 2. Repository 2-1. Remote Repository 1. rlist ( 1.2.8 부터 지원됩니다. 안녕 리눅스의 cvs 1.11 에서도 가능) 2. rlog 2-2. Local Repository 1. co, rlog, rcsdiff, cvs 명령이 필요 (rcs package 와 cvs package 가 설 치되어 있어야 합니다. Remote Repository를 사용시 rlog보다 rlist가 성능이 더 좋으나 cvs 저장소에서 의 지원 여부 문제 때문에 rlist를 지원하지 않는 저장소에는 rlog를 사용하십시 오. 3. 속도 개선 대부분의 CVS 웹인터페이스들이 정렬을 위하여 데이터를 배열로 생성화는 과정에 서 속도가 저하되는 문제가 있습니다. 이 증상들은 revision 수가 많아질수록 더 욱 심해지게 되는데 CVSd에서는 이런증상을 최소화 하기 위하여 line by line 파 싱을 하여 속도의 개선을 상당히 높였습니다. 4. 언어셋 문제 CVSd는 저장소에 저장되어 있는 소스의 언어셋과 CVSd의 언어셋을 적절하게 설정 을 할 수 있도록 설계가 되어 있습니다. 가령 예를 들어 CVSd의 언어셋은 EUC-KR 인데 (UTF8이 아닌 이유는 제가 아직 EUC-KR을 사용하기 때문입니다. ^^) 저장소 소스의 문서가 UTF-8일 경우, 이를 깨지지 않도록 내부적으로 변환을 할 수가 있 습니다. 이를 위해서는 php-iconv extension이 지원이 되어야 합니다. 또한 UTF8 사용시 commit을 할 때, cvs log 가 UTF8과 EUC-KR이 혼재가 되는 경우가 많습니 다. 이는 의도하지 않은 환경상의 차이일 수 있는데, 이 경우, 한글에 대해서는 CVSd가 직접 체크를 해서 보정을 할 수 있습니다. (아마 EUC-JP까지는 같이 사용 을 할 수 있을거라 예상합니다만.. 확인은 못해 보았습니다.) 5. 웹브라우저 Free CVSd는 XHTML 1.0과 CSS 2.0의 W3C표준을 지원하며 자바 스크립트 사용을 자제하 여 어떤 브라우저라도 기본 기능을 이용할 수 있도록 되어 있습니다. (몇몇 에러 처리시에 자바 스크립트 alert이 이용되기는 합니다만, 기본 기능 사용에는 문제 가 없습니다.) 또한 skin을 지원하며 저장소 별로 스킨을 다르게 설정할 수 있습 니다. 6. 다중 언어 지원 GNU Gettext를 이용하여 다중 언어를 지원합니다. php gettext extension이 없을 경우에는 pure php code를 이용하여 PO파일을 파싱하여 지원을 하기는 하지만 성 능상 gettext extension을 사용하는 것이 좋습니다. 2. 사용 환경 1. 필요 패키지 웹서버 php >= 5.0 php iconv extension php gettext extension rcs package (co, rlog, rcsdiff command) cvs package
2007/11/07 20:20 2007/11/07 20:20
Filed under Tech/프로그래밍
요즘은 대세가 Subversion 인가요? 하지만 구관이 명관이라는 말처럼 제게는 Subversion 이 그리 와닿지가 않습니다. 일단 설치하고 셋팅하는 것이 너무 빡세고 새로운 것을 받아들여야 하는 것이 예전처럼 그리 와닿지가 않는군요. :-)

뭐 하여튼.. 그래서 전 CVS 를 사용하고 있다고 말을 하고 있습니다. CVS를 사용하다 보면 CVS Web UI 자주 사용하게 됩니다. 로그나 diff 같은 것을 보기가 상당히 편하게 되어 있으니까요. (Subversion 에서도 사용할 수 있는 Web UI가 있죠. 어쩌면 이런 부분에서는 Subversion 이 더 잘 되어 있습니다.) 그런데, 이 CVS Web UI의 속도가 느리고, local repository 밖에 다룰수 없다는 것이 상당히 불만이었습니다. 그래서 그냥 내가 만들어 버려.. 하고 생각한지 2년만에 틈틈히 손을 대기 시작했고, 드디어 어느정도의 성과물이 나왔습니다.

일단 새로 개발한 것의 특징은 원격 repository 를 지원하기 위하여, local rcs tool 을 이용한 것이 아니라 CVS protocol 을 hacking 하여 구현했다는 점입니다. 즉, anonymous 나 cvs account 권한이 있으면 서로 다른 repository 를 이 Web UI 에서 함께 관리할 수 있다는 점이 가장 큰 차이입니다. 이 기능은 CVS 1.2 의 rls 를 이용하거나 rls를 지원하지 않는 경우에는 따로 cvsdserver 라는 directory listing 을 해 주는 inet daemon 을 이용하여 처리를 하도록 되어 있습니다.

두번째로는, 속도의 향상에 있습니다. 기존의 Web UI 들이 모두 파싱을 하여 배열로 만들어서 이 배열을 정렬하든지 등등으로 관리를 하는데, 제가 만든 것은 네트워크 전송이 들어오는 족족 처리를 하도록 하여 속도의 향상을 시켰습니다. 다만, 이 부분 때문에 일부 자각하기는 힘든 기능들을 포기할 수 밖에 없었습니다. 일단 기본적인 기능은 FreeBSD 에서 배포하는 CVS Web을 기준으로 하였습니다.


사용을 하는데는 무리가 없을 정도.. 즉 세상에 꺼낼 정도는 만들어 졌습니다만.. 몇가지 처리사항을 더 하여 내 놓으려고 합니다. 일단, local repository 에 대하여 CVS protocol 을 탈 필요가 없기 때문에, 이를 처리하는 루틴이 들어가야 할 것입니다. 조만간.. 만날 수 있지 않을까 싶습니다. 다만.. 가장 큰 작업은 이를 어떻게 문서화를 하느냐가 아닐까 싶군요 ^^;
2007/10/30 22:39 2007/10/30 22:39
Filed under Tech/프로그래밍
얼마전 어느분이 제게 CVS 에 rls 가 지원되도록 요청을 해 주셨습니다. CVS 1.2 로 업데이트를 하면 간단하게 해결이 되지만, CVS 1.2 가 아직 stable 이 아닌 관계로 별로 업데이트를 하고 싶지 않더군요. 그래서 1.12.13 의 rls 기능을 CVS 1.11 에 백포팅을 해 보았습니다.

strftime 관련하여서 m4 파일의 수정 문제가 귀찮아서 그냥 오리지날 strftime 을 사용하도록 변경한 것 외에는 거의 동일할 것 같습니다.

패치 파일을 첨부하니 관심 있으신 분들은 사용해 보시기 바랍니다. 이 패치파일은 RHEL 5 의 cvs 1.11.22-5 에 패치를 한 것이니 다른 버전에서는 참고하여 수정을 하시면 될 듯 싶습니다.

2007/10/21 05:09 2007/10/21 05:09