mysql 이 4.0 에서 4.1, 5.0 으로 올라가는 과정에서 이전 버젼과 호환되지 않는 점이 몇 가지 생겨버려서 예전부터 업데이트를 미뤄왔는데… 이제 mysql 4.1, 5.0 버젼대도 충분히 안정화된 듯 싶고, 5.0 에서 새로 생긴 기능들을 써보고 싶은 욕심들이 생겨서 요번 방학이 가기 전에 업데이트를 하기로 마음을 먹었다.

우선 호환성에 문제가 되는 문제점은 크게 아래와 같이 2가지로 볼 수 있다.

1. Password()

password() 가 리턴하는 hashed string 의 길이가 길어졌다. 때문에 4.0 버젼에서 만들어진 hashed string 을 비밀번호로 사용하는 경우 old_password() 를 사용해서 비교해야 한다.

2. Encoding

예전에는 시스템 전체가 하나의 특정한 인코딩 (default: latin1) 을 사용한다는 전제를 두고 동작했지만 이제는 System, Database, Table, Column, Client 에서 사용하는 Encoding 을 전부 따로 설정하는게 가능해졌다.

물론 시스템 전체가 그냥 utf-8 이라던지 euc-kr 을 사용한다면 문제는 간단해지지만 상황은 그렇지 않다는 점이 문제!

우선 문제 상황을 체크해봐야겠기에 사용자 계정을 살짝 살펴봤다. 사용되고 있는 툴들은 zero board, wordpress, punbb, phpbb, soojung, mint, dansunboard(?) 정도였다. 다른 툴들은 md5 나 자체 hashing algorithm 을 사용해서 password 로 사용하고 있었기 때문에 mysql password 함수가 동작하는게 달라졌다고 해도 영향을 받지 않겠지만, zero board 의 경우엔 로그인이 안되는 문제가 발생할 듯…

Encoding 관련해서 mysql manual 을 열심히 읽어 보니 아래와 같이 정리할 수 있을 듯…

• client 보낸 데이타를 server 는 character_set_client 라고 생각
• client 가 보낸 데이타를 server 측에선 character_set_connection 으로 변환
• server 에서 client 로 데이타를 보낼 때는 character_set_results 를 이용

간단하게 client 에서 받은 건 character_set_client 에서 character_set_connection 으로 변환되고, 변환된 데이타는 database, table, column 별로 설정해놓은 character set 으로 다시 변환되어 저장되며 server 에서 client 로 데이타가 전송될 때는 character_set_results 를 이용한다.

뭐하튼 위에 열거된 프로그램들 중 deute 님이 사용하시는 단순보드(?) 와 zero board 를 제외하고는 전부 UTF-8 을 사용하고 있는 듯 싶으니 별로 신경 쓸 일은 없을 듯 하고… 그건 default client, result, connection character set 을 UTF-8 로 세팅하게 되더라도 zero board 와 단순보드 말고는 아무 것도 문제를 일으키지 않는 다는 얘기!!! 그렇다면 zeroboard 의 password 비교 부분과 connect 패치하는 걸로 DB migration 이 한 방에 가능해질 듯…-_-v

우선 테스트를 해봐야 겠기에 Virtual PC 를 설치하고 unfix 와 비슷한 환경을 구축하려고 해봤는데 가상머신이 돌고 있는 윈도우를 리붓 시켜 버리는 문제가 발생!! 역시 가상머신 하면 vmware 인가보다. 빌드해놓은 건 아까우니 tar.gz 로 묶어서 vmware 로 옮기니 테스트 환경은 완성!

우선 환경은 갖춰 놨으니 금토일 살살살 테스트를 해보고 다들 자고 있을 시간이나 사용자가 적은 아침 에 mysql 을 5.0 대 최신 버젼으로 업그레이드 해야겠다! 꺄홋!

참고:
http://mysql.com/doc/refman/5.0/en/application-password-use.html
http://mysql.com/doc/refman/5.0/en/charset.html

p.s) 다들 제로보드 패치들을 하도 안하길래 직접 제로보드 버젼별로 다 받아서 diff 뜨고 패치까지 적용해놨음… 패치파일들 필요하신 분은 아래 URL 로 가시기 바랍니다~

흠 제로보드를 받아서 풀어보니 줄바꿈 관련해서 어떤건 DOS 형식이고 어떤건 unix 형식이길래 dos2unix 를 통해 전부 unix 형식으로 통일 시켜놓고 diff 를 뜬 거라 DOS 형식으로 올려놓은 분들은 패치하다가 실패할 수도 있습니다 -_-;; (old_password 와 encoding 설정하는 패치도 잘 찾아보면 있습니다.)

http://mytears.org/resources/tmp/

사실 unfix 는 나 혼자 쓰는 서버가 아니고… 파일이름등을 unicode 로 관리할 경우 ms 윈도우와의 궁합이 그다지 좋지 않기 때문에… utf-8 환경을 갖추는 게 망설여지는게 사실이었다.

얼마 전 젠투 한국 사용자그룹의 유리님의 개인 portage-overlay 리스트를 보다가 proftpd 의 charset conversion 패치를 발견했다. 원 출처는 일본 쪽인 듯 싶은데, 이 패치를 적용하면 client 에서 사용하는 charset 과 server에서 사용하는 charset 을 설정하는게 가능해진다.

http://home.h01.itscom.net/para/sof…are/misc/proftpd-iconv/index-e.html

만약 중간에 charset conversion 에 실패했다거나 한 경우 어떻게 처리를 하나 봤더니, 변환에 실패한 글자를 ‘?’ 로 바꿔버리고 있었다. out_buffer size 를 in_buffer size 의 세 배 크기로 할당하고 중간에 에러가 발생하면 무조건 변환이 실패한 것으로 생각하기 때문에 한 글자를 표현하는데 3바이트보다 더 많은 바이트 수가 필요하다면 (ucs2 로는 표현 못하는 글자를 사용하는 경우), 버퍼 오버플로의 희생양이 될 수도 있을 듯 싶다. 그래도 원하는 코드를 삽입하는 건 힘들고 그저 segmentation error 를 부를 뿐이겠지만 찝찝한 건 사실이므로 에러가 발생할 경우 errno 를 참고하도록 패치를 해야겠다.

근데 실제 적용을 해보니 Directory 나 .ftpaccess 를 통한 지역 설정이 허용되지 않는다. 내가 사용하는 폴더들에 한해서 저 패치의 영향을 받게 하는게 목적이었기 때문에 결국 패치를 해버렸다. proftpd 개발자 문서는 서버가 다운되었었는지 참고를 할 수가 없었고, 그나마 미러링 된 곳도 찾을 수가 없어서 한참 헤매긴 했지만!! 결국!! 내가 원하는 데로 패치 성공 -_-v

패치파일:
http://mytears.org/resources/mysrc/c/patches/mod_codeconv.patch

mod_autoindex 도 몇 일전에 charset 을 설정해줄 수 있도록 패치했고, 그 외에는 이미 다 준비가 되어 있었기 때문에 누군가 mod_autoindex 의 새로운 테마만 만들어준다면 바로 utf-8 환경으로 넘어갈 수 있을 듯 싶다.

FTP 관련해선 RFC2640 에 있는 것을 구현하는 것이 옳다고 생각하지만 중간 단계로써 mod_codeconv 도 나름의 의미가 있을 듯 싶다.

p.s) 위의 사이트에 나와있는 메일 주소로 패치파일을 보내주려 했지만 메일주소가 죽어있네요.