MediaWiki Extension – Wiki2LaTeX

위키의 활용 용도 중 하나가, 특정 규정집 작성이다 보니, 입력한 문서들을 책과 같은 문서로 만들어 주는 기능이 필요하게 되었다.

일반적으로 책이나, 논문들은 pdf파일로 주로 작성되고 공유되기 때문에, 위키 페이지를 pdf파일로 만들어 주는 Pdf Export, Pdf Book, Wiki2LaTeX 등의 extension들을 찾게 되었다.

Pdf Export, Pdf Book extension은 문서 변환에 htmldoc 명령어를 사용하는데, htmldoc은 한글을 지원해 주지 않는다. 따라서 LaTeX 기반의 pdflatex 명령어를 사용하는 Wiki2LaTeX extension을 사용하기로 하였고, Wiki2LaTeX extension을 설치하고 사용하면서 발생한 문제들에 대해 정리해 본다.

설명

위키내의 각 문서를 LaTeX 문서로 변환한 뒤, LaTeX 어플리케이션을 이용하여 pdf 문서로 만들 수 있게 해준다. linux 명령어는 pdflatex을 이용하며, 이는 w2lConfig.php에서 변경할 수 있다.

Extension 위치

 http://www.mediawiki.org/wiki/Extension:Wiki2LaTeX

준비작업

LaTeX의 설치

LaTeX을 이용하기 때문에 관련 어플리케이션을 설치해야 한다. 필자는 현재 계속적으로 유지되고 있는 texlive를 설치했다.

apt-get install texlive-full

or

apt-get install texlive

# 필요한 패키지들은 따로 설치

일단, 풀버전을 설치했는데, 풀버전의 사이즈는 거의 600mb정도되며, 사용하지 않는 패키지들도 많으니, texlive 패키지만 설치하고, 사용하면서 필요한 패키지만 따로 설치하는 것이 좋다.

설정하면서

한글(utf-8 인코딩)  문서의 적용

linux에서 개발 시, 가장 어려운 문제중의 하나가 바로 한글 문제이다. LaTeX에서는 다양한 한글 관련 패키지들이 존재한다. kotex, cjk 패키지들이 바로 그것들이다. 필자의 블로그에서는 kotex을 설치하여 한글을 이용했지만, w2l에서는 cjk 패키지에 대한 언급이 많아서 cjk를 설치하였다. cjk를 설치하며 utf-8 인코딩의 한글 문서 변환까지 많은 우여곡절이 있었는데, 내용이 너무 길어서 따로 포스팅하였다. http://nineye.net/blog/archives/1340 를 참고하자.

http protocol의 한글 파일명의 사용

w2l에서는 다운받는 pdf 문서의 파일명칭에 페이지 제목을 사용한다. 따라서 페이지 제목에 한글이 포함되는 경우도 고려했어야 했는데, w2l은 한글을 고려하지 않았다.  …/extension/w2l/w2lSendFile.php 파일을 열어서 다음 부분을

$title = addslashes( $_GET['title'] );

다음과 같이 수정하자.

$title = addslashes(iconv("UTF-8", "EUC-KR", $_GET['title']));

http protocol에서는 파일명을 euc-kr 인코딩으로 처리하는 것 같다. 따라서 utf-8 인코딩의 페이지 제목을 euc-kr 인코딩으로 변환하여 파일명칭으로 넘기니 정상적으로 동작한다.

가끔 pdf 파일을 전송 받지 못하는 문제

해당 페이지의 pdf 문서 변환 후, 다음 페이지에서 pdf문서 링크를 클릭하면 w2lSendFile.php 페이지가 동작하는데, 이때 가끔 pdf문서의 전송이 되지 않을 때가 있다. 시간이 없어서 원인은 아직 찾지 못하였으며, 일단 다음의 코드로 변경하니 실패 확률은 줄었다.

header("Content-Type: ".$mime_type);
// Es wird downloaded.pdf benannt
header('Content-Disposition: attachment; filename="'.$title.'.'.$fmt.'"');

위의 코드 앞에, 다음을 붙여 넣자.

## nineye edit
#
# add checking
    if (!is_file($file_loc)) {
        header('HTTP/1.0 404 Not Found');
    }
    if (!is_readable($file_loc)) {
        header('HTTP/1.0 403 Forbidden');
    }

    $stat = @stat($file_loc);
    $etag = sprintf('%x-%x-%x', $stat['ino'], $stat['size'], $stat['mtime'] * 1000000);

    header('Expires: ');
    header('Cache-Control: ');
    header('Pragma: ');

    if(isset($_SERVER['HTTP_IF_NONE_MATCH'])
        && $_SERVER['HTTP_IF_NONE_MATCH'] == $etag) {
        header('Etag: "' . $etag . '"');
        header('HTTP/1.0 304 Not Modified');
    } elseif(isset($_SERVER['HTTP_IF_MODIFIED_SINCE'])
        && strtotime($_SERVER['HTTP_IF_MODIFIED_SINCE'])
            >= $stat['mtime']) {
        header('Last-Modified: ' . date('r', $stat['mtime']));
        header('HTTP/1.0 304 Not Modified');
    }

    header('Last-Modified: ' . date('r', $stat['mtime']));
    header('Etag: "' . $etag . '"');
    header('Accept-Ranges: bytes');
    header('Content-Length:' . $stat['size']);

# end edit

혹시 http protocol의 내용의 내용에 정보가 부족하여서 문제가 생길까.. 하여 더 많은 페이지 정보를 넣어봤다. 확실히 실패할 확률은 많이 줄어들긴 했지만 아직 문제가 있는 것으로 보아, 정답은 아닌 것 같다.

평가

안정성

한글 지원 문제와 파일 전송 문제를 제외하고는 문제가 없었다. 하지만 문제를 해결하기 위해 소스를 보다보니, 생각외로 오류 처리 코드가 많지 않아 잠재적인 위험도가 높은 것 같다.

기능

한 페이지의 위키 문서를 처리하기에는 알맞은 것 같지만, 다중 문서를 함께 처리하는 기능이 없다. 관련된 문서를 책처럼 만드는 기능이 필요할 것 같은데 없어서 아쉽다. 참고로 PdfBook, Book extension 들이 이를 지원하지만, htmldoc 명령어를 기반으로 하기때문에 한글이 지원되지 않는 문제가 있다.

html페이지의 변환은 약간 부족한 감이 있다. 단순한 페이지는 깨끗하게 변환하는 것 같지만, 약간 복잡한 페이지는 매끄럽게 변환하지 못한다. 전체적으로는 쓸만하게 변환하는 것 같다.

지원

현재 개발되고 있는 최근 버전이 2009년 7월 2일자인 것으로 봐서는 계속 개발 중인 것 같다. 다국어의 지원은 지켜봐야 할 일 같다.

LaTeX에 unicode와 cjk 패키지 적용하기

회사에서 정보 공유의 목적으로 MediaWiki를 이용하여 위키를 만들게 되었는데, 업무를 목적으로 하다보니, 입력되는 위키 페이지들을 보고용으로 쉽게 만들 수 있게 하는 기능이 필요하게 되었다. 따라서 그 기능을 지원하기 위해, w2l이라는 MediaWiki extension을 설치하게 되었고, w2l을 이용하기 위해 기본적으로 세팅해야 하는 내용들 중, 폰트와 관련된 부분을 보기로 한다.

w2l extension은 LaTeX 기반이며, pdflatex명령어를 통해 “위키문서 => LaTeX코드 => pdf문서”로 만드는 extension이다. 즉, w2l extension을 이용하려면 해당 서버에서 LaTeX을 지원해 주어야 하는 것이다.

필자가 MediaWiki를 설치한 서버에는 texlive LaTeX package가 이미 설치되어 있었으며, 영문 문서를 테스트 했을 때는 아무런 문제가 없었다. 하지만 linux가 항상 그렇지만, 한글 문서를 적용하려고 하니 여러 가지 문제가 발생하였고, 문제의 근간이 된 폰트 문제에 대해 쓰고자 한다.

우선, 적용하고자 하는 서버에 LaTeX이 설치되어 있지 않다면 설치하자. 필자는 현재까지 계속 지원되고 있는 texlive를 설치하였다.

 
# Debian의 apt-get을 통한 설치(필자의 환경은 이것인데, 다른 환경은 구글링을 통해...ㅋㅋ)
# LaTeX 기본 설치(texlive tool + 기본 포맷 package)
$ apt-get install texlive
# LaTeX  풀 설치(약 700MB 정도된다. ㅡㅡ;;; 기본으로만 설치하고 필요한 package만 따로 설치해도 된다.)
$ apt-get install texlive-full

1 LaTeX에 한글은 어떻게 적용할까?

LaTeX 에 있어서의 변환 툴은 그저 껍데기에 지나지 않고, 실질적으로는 LaTeX문서를 다양하게 표현하는 package가 더욱 중요하다. LaTeX은 이러한 다양한 문서 표현에 대해, 사용자들이 직접 문서 표현 포맷을 작성하고, 이 포맷을 package로 공유하게 함으로써, 현재의 LaTeX은, 표현하지 못하는 문서의 모습은 거의 없을만큼 방대해 졌다. 하지만 너무 방대해 지고, 전 세계의 사용자들이 각각 package를 제작하다보니, package들 끼리의 관계가 너무 복잡하게 얽혀있어서 소위 삽질을 많이 하게 된다.  필자도 한글을 적용하면서 삽질을 많이 하였고, 다시 삽질을 하지 않기 위해 한글 적용 문제를 정리해 보고자 하는 것이다.

LaTeX에서의 한글 적용은 다양한 package들이 존재하는데, kotex, cjk(chinese, japanese, korean – 우리나라가 맨 마지막에 나와서 기분 나쁘지만 뭐, 알파벳 순서니… ㅡㅡ;;;)등이 그것들이다. kotex은 국내에서는 많이 알려졌는데, 세계적으로는 아시아권(한국, 중국, 일본) 언어를 지원하는 cjk package가 더욱 알려져있으며, 이 package에 대한 지원도 잘 되고 있어서, cjk package를 선택하기로 했다.

# cjk package는 각 언어별로 따로 설치할 수 있다. "latex-cjk-해당언어"의 명칭으로 package가 제공된다. 필자는 귀찮고 문제 생길까봐 다 설치했다.
$ apt-get install latex-cjk-all
# fontforge로 cjk 관련 폰트를 생성할 때, 폰트 스크립트가 필요하다. 이는 latex-cjk-common package에 들어 있으니, 없으면 설치하자.

자, cjk가 설치되었으니, pdflatex명령을 통해 한글 tex문서를 변환해 본다. 아마… 잘 안될 것이다. 변환이 잘 된다면 성공이고, 이후의 과정은 무시해도 된다. 필자의 경우 utf-8 인코딩으로 저장된 tex문서를 변환해야 해서, unicode font를 설치해야 했고, byte단위의 한글 인코딩 문서라면 잘 변환될 수도 있을 것 같다. 아래 과정은 tex문서가 utf-8로 인코딩된 문서라 가정하고,  utf-8문서를 다룰 수 있는 unicode font의 설치에 관련된 내용이니, 다른 문제로 고민한다면 아래 내용을 읽지 않아도 된다.

2 LaTeX에서는 어떻게 unicode를 지원할까?

pdflatex명령을 통해 생성되는 ~.log 파일에 “!Undefined control symbol ~어쩌구~ <문서내의 한글 내용> ~어쩌구~” 라는 에러 메세지가 있다면, 한글을 변환하는 cjk package는 정상적이지만, utf-8 인코딩 tex문서내의 한글 변환에 사용되는 폰트가 정상적이지 않은 것이다. 이 글에서는 이 경우의 오류만 다루기 때문에 다른 종류의 오류라면 구글링을 통해 찾아보기 바란다. 

우선, LaTeX package들이 설치되는 곳에 truetype폰트가 설치되어 있는지 확인해 보자. 위치는 필자의 경우, /usr/share/texmf/fonts/truetype/ 이었다. 일단 여기 font가 설치되어 있다면 unicode를 지원하는 font인지 확인해 보자. unicode를 지원하는 폰트라면 LaTeX cjk package가 사용가능한 font인지 해당 font정보를 확인해 보도록 하자. 만약 cjk package에서 적용하지 못하는 font이거나, unicode를 지원하는 font가 없다면 Bitstream의 Cyberbit font를 설치하자.

잠깐 Cyberbit font에 대해서 설명하면, 이 font는 Bitstream사가 보유한, 비영리적인 목적으로 사용할 때는 공짜인 font이다. 그리고 이 font는 전 세계에서 큰 비중을 차지하는 unicode 입력 리스트들에 대해 지원을 하는, 역사적으로 가장 널리 알려진 font중 하나이다. 이 font에 대한 상세 내용은, Bitstream사의 홈페이지(www.bitstream.com)에 가보면 어딨는지 잘 모르겠고, Wikipedia의 설명(http://en.wikipedia.org/wiki/Bitstream_Cyberbit)을 참고하자.

3 unicode를 표현하기 위한 cyberbit font를 설치해 보자.

Cyberbit font를 LaTeX내에 설치해 주는 package가 존재한다면, 그 package를 통해서 쉽게 설치할 수 있겠지만, 아쉽게도 아직 없나보다. 따라서 수동으로 설치하는 방법을 따라 설치하였다. 다음의 순서에 따라 cyberbit font를 LaTeX내에 설치해 보자. 참고로 설치하는 위치는 필자의 환경 기준으로 쓰며, 만약 설치 장소가 /usr/share/~ 가 아니면 환경에 맞게 설치한다.

1. cyberbit font의 복사

1. 여기를 클릭해서, cyberbit font를 받자.

2. 압축을 해제하면 Cyberbit.ttf가 나오는데 이를 cyberbit.ttf로 이름을 변환해서(LaTeX에서는 대소문자를 구분한다.) /usr/share/fonts/truetype/bitstream/ 위치에 넣자.

3. 이렇게 설치한 font를 LaTeX에서도 사용할 수 있게 링크를 걸어준다.

$ mkdir -p /usr/share/texmf/fonts/truetype/bitstream/cyberbit/
$ ln -s /usr/share/fonts/truetype/bitstream/cyberbit.ttf /usr/share/texmf/fonts/truetype/bitstream/cyberbit/cyberbit.ttf

2. LaTeX 문서의 변환에 이용되는 파일들의 설치

 - fontforge tool을 이용하여, LaTeX typesetting 시스템에 사용되는 파일 포맷인 .tfm(http://en.wikipedia.org/wiki/TeX_font_metric 참고)과, uuencoding에 사용되는 파일 포맷인 .enc(http://en.wikipedia.org/wiki/Uuencoding 참고)와,  PostScript에 이용되는 파일 포맷인 .pfb(http://en.wikipedia.org/wiki/PostScript_fonts)파일을 설치

1. fontforge가 설치되어 있지 않다면 설치한다.

$ apt-get install fontforge

2. 앞에서 latex-cjk-common package를 설치했으면, /usr/share/latex-cjk-common/utils/subfonts/ 위치에 cjk용 폰트 스크립트인 subfonts.pe 파일이 있다. 이를 작업 디렉토리에 복사하자.

3. fontforge에서 사용하는 unicode 폰트 형판(?) 파일(http://en.wikipedia.org/wiki/FontForge 참고)인 Unicode.sfd를 작업 디렉토리에 복사한다. 보통 freetype1-tools(현재는 freetype2-demos로 명칭이 변경된 듯 하다. 정확한 설명이 없음) package를 설치하면 /usr/share/texmf/fonts/sfd/ 위치에 있다고 하지만 필자의 경우 없었다. 따라서 여기에서 다운 받아서 위의 위치에 넣었다.

4. 이제 fontforge를 이용해서, 작업 디렉토리에 .tfm, .enc, .pfb 파일들을 생성한다. 이 작업은 시간이 많이 소요된다. 필자의 경우 한 4~5시간 정도? ㅡㅡ;;;

# 작업 디렉토리에서 실행
$ fontforge -script subfonts.pe cyberbit.ttf cyberbit /usr/share/texmf/fonts/sfd/Unicode.sfd

5. 파일들이 생성됐으면, LaTeX문서를 PostScript로 변환 시, 사용하는 .map 파일을 생성한다. 이는 .pfb파일로부터 다음의 스크립트를 통해 생성한다.

# 작업 디렉토리에서 실행
for i in *.pfb
do
echo "$(basename $i .pfb) $(basename $i .pfb) <$i" >> cyberbit.map
done

6. 이제 생성된 파일들을 다음의 위치에 넣는다.

• .afm ==> /usr/share/texmf/fonts/afm/cyberbit/
• .tfm ==> /usr/share/texmf/fonts/tfm/cyberbit/
• .pfb ==> /usr/share/texmf/fonts/type1/cyberbit/
• .map ==> /usr/share/texmf/fonts/map/dvips/cyberbit/

7. texmf 디렉토리 내의 구조가 변경되었으므로 “texhash”나 “mktexlsr” 명령을 root권한으로 실행하여 ls-R을 다시 구성한다.

3. 20cyberbit.cfg 파일의 추가

 - /etc/texmf/updmap.d/ 위치에 20cyberbit.cfg 파일을 다음과 같은 내용으로 편집하여 추가한다.

######
# 20cyberbit.cfg
Map cyberbit.map
######

4. cyberbit.map파일의 적용

 - 다음과 같은 명령을 실행하여, cyberbit.map font map 파일을 적용한다. 이 때 주의할 점은 작업 디렉토리내의 cyberbit.map 파일로 적용되지 않기 위해, 작업 디렉토리 내의 cyberbit.map 파일을 삭제하고 실행한다.

$ update-updmap -c /etc/texmf/updmap.d/
$ updmap-sys

5. c70song.fd파일의 생성

 - /usr/share/texmf/tex/latex/CJK/UTF8/의 위치에 c70song.fd 파일이 있는지 확인하고, 있으면 삭제하고 다음의 내용으로 c70song.fd 파일을 생성한다.

%%%%%%
% This is the file c70song.fd of the CJK package
%   for using Asian logographs (Chinese/Japanese/Korean) with LaTeX2e
%
% created by Werner Lemberg <wl@gnu.org>
%
% Version 4.6.0 (11-Aug-2005)

\def\fileversion{4.6.0}
\def\filedate{2005/08/11}
\ProvidesFile{c70song.fd}[\filedate\space\fileversion]

% character set: Unicode U+0080 - U+FFFD
% font encoding: Unicode

\DeclareFontFamily{C70}{song}{\hyphenchar \font\m@ne}

\DeclareFontShape{C70}{song}{m}{n}{<-> CJK * cyberbit}{}
\DeclareFontShape{C70}{song}{bx}{n}{<-> CJKb * cyberbit}{\CJKbold}

\endinput
%%%%%%

6. ls-R의 재 구성

 - root 권한으로 “texhash” 명령어를 다시 실행한다.

자, 이제 다 되었다. 위에서 테스트 한 LaTeX 소스 파일로 다시 테스트 해 보자. 필자의 경우 오류 없이 한글이 변환되었다. 드디어~ MediaWiki 한글 페이지를 pdf문서로 만들 수 있다~!!! 언제나 생각하는 것이지만 정말 linux에서는 어떤 프로젝트든지, 한글을 적용하는 것은 삽질이다. ㅡㅡ;;;

MediaWiki의 설치

회사에서, 연구소간 공유할 수 있는 위키를 만들게 되어서, 전세계적으로 가장 널리 알려진 Wikipedia의 근간이 된 MediaWiki를 설치하면서 수행한 일들을 정리한다.

문서의 순서는 필자가 MediaWiki를 설치하면서 수행한 일들을 시간 순서대로 나열 할 것이다. 참고로 MediaWiki의 홈페이지는 http://www.mediawiki.org 이다.
 

환경 

OS : Linux Cent-OS 64

php 버전 : 5.1.6

mysql 버전 : Ver 14.12 Distrib 5.0.45

GD 버전 : bundled (2.0.28 compatible)

MediaWiki 버전 : 1.15.1

설치 권한 : 사용자 user1으로 설치

MediaWiki 소스 설치 위치 : /home/user1/www/wiki 아래에 설치 (아파치 설정에서 사용자의 홈디렉토리 위치를 public_html에서 www로 바꾼 경우)

MediaWiki DB 설치 위치 : mysql database “mediawiki” 에 설치한다. 그리고 mysql의 user1 계정에 권한을 준다.

Install

1. MediaWiki 홈페이지에서 다운로드 받는다.

http://www.mediawiki.org/wiki/Download 페이지를 띄워서 Latest releae 버전을 다운로드 받는다. 다운 받은 MediaWiki 압축 파일을 설치할 위치(/home/user1/www/)에 업로드 한다.

2. 압축된 MediaWiki 파일을 원하는 위치에 압축 해제한다.

# mediawiki-1.15.1.tar.gz 가 /home/user1/www/ 에 있을 경우
tar xvzf mediawiki-1.15.1.tar.gz
mv mediawiki-1.15.1 wiki

3. MediaWiki 설정 전, 준비 작업을 한다.

1) mysql DB에 MediaWiki가 사용 할 정보를 만든다.

# MediaWiki 데이터를 담을 database를 만든다.
mysql> create database mediawiki;
# 생성한 "mediawiki" database에 grant ~ on 사이의 권한을 user1에게 부여한다.
# user1이 mysql 에 등록되어 있지 않은 경우, user1을 생성한 후 권한을 부여한다.
# user1이 mysql에 등록되어 있는 경우, 권한을 부여한다.
mysql> grant create, select, insert, update, delete, alter, lock tables on mediawiki.* to 'user1'@'localhost' identified by 'password';
# MediaWiki에서 사용 할 DB가 다른 서버에 위치 할 경우, 위의 명령에서 'localhost' 를 해당 서버의 주소로 바꿔준다.

2) config 디렉토리 설정

MediaWiki를 웹페이지에서 설정하기 위해, /home/user1/www/wiki/config 디렉토리에, others에게 쓰기 권한을 부여한다. 쓰기 권한을 부여하지 않았다면, “Can’t write config file, aborting”의 오류 메세지가 설정 페이지에 나타난다.

cd /home/user1/www/wiki
chmod 757 config

4. http://yourdomain/~user1/wiki/config/ 에 접속해서 MediaWiki를 설정한다.

1) 환경 체크 (Checking environment)

서버의 환경을 체크하여, MediaWiki를 설치할 수 있는 지 체크한다. MediaWiki가 정상적으로 동작하지 못할 수도 있는 환경이면 붉은 색 글자로 에러를 표시하나, 비정상적인 부분이 없다면 위와 같이 “You can install MediaWiki”를 표시한다. 참고로, Warnning이 뜰때도 있는데, 이는, MediaWiki의 메인 기능은 정상적으로 이용 가능하지만, 추가적인 기능은 이용할 수 없을지도 모른다는 것이다. 예를 들면, GD library가 설치되어 있지 않으면 다양한 이미지 변환 기능을 사용할 수 없다. 이럴 때 Warnnig이 뜬다. 서버의 관리자라면 MediaWiki가 필요로 하는 기능들을 서버에 다 설치하여 Warnning이 없도록 만든 후, 다시 환경 체크를 해서 정상적으로 통과 시키자.

2) 사이트 설정 (Site config)

 - Wiki name : 위키의 명칭을 적는다. 이 명칭은 위키내에서 네임스페이스로도 사용되므로 되도록이면 짧고 공백없이 명명하도록 한다.

- Contact e-mail : 위키를 관리할 사람의 이메일이다.

- Language : 위키에서 표시할 언어이다. MediaWiki가 영문을 베이스로 하다보니, 영문을 선택하면 전체적으로 깔끔하지만, 한국어를 선택하면 좀 지저분해 보인다. 영문을 선택하더라도 한국어를 입력은 할 수 있다. 한국어를 선택하려면 “ko – 한국어”를 선택한다. 그리고 여기서 “en – English”를 선택해서 설치하고 나중에 위키 사용자 설정에서 다시 한국어로 바꾸지는 말자. 그러면 이상하게 꼬일 가능성이 많다. 예를 들면, 영문에서의 대문의 명칭은 “Main”이며, 한국어에서 대문의 명칭은 “대문”이다. 언어를 나중에 바꾸면 “대문”을 클릭해도 해당페이지가 없다고 나온다. 왜냐면 대문 페이지는 “Main”의 명칭으로 만들어져 있기 때문이다. 이런 문제가 페이지 명칭, 네임스페이스 명칭, 특수 페이지 명칭 등에 걸쳐 상당히 많이 존재한다.

- Copyright / license : 라이센스를 어떻게 표시할거냐는 건데… 필자는 그냥 “No license metadata”를 선택했다.

- Admin username, Password, Password confirm : 관리자로 사용 할 정보이다.

- Object caching : php에서 어떤 툴을 이용하여 object caching을 할 것이냐는 것인데, 이는 eAccelerator나 Turck MMCache등이 서버에 설치되어 있어야 한다. MediaWiki 설정 페이지에서는 이런 툴들이 설치되어 있는지 자동으로 감지해 주고 표시해 준다. 필자의 서버는 설치가 되어 있지 않기때문에 표시가 되지 않았다. 없으면 그냥 No caching을 선택해 주고, 있으면 있는 툴을 선택해 주자. 참고로 설명에 나와 있듯이, DBA는 No caching보다 더 느려서 테스트 용도로만 사용하니 선택하지 말자.

3) 이메일 설정 (E-mail, e-mail notification and authentication setup)

- E-mail features (global) : 모든 이메일 기능을 사용 가능하게 할 것인지, 아니면 사용 불가능하게 할 것인지 선택한다. 일반적인 설정은, 사용자끼리의 이메일은 그다지 많지 않고, 이메일 공지가 부하가 크기 때문에, 이 항목과 사용자끼리의 이메일은 활성화 시키고 이메일 공지는 비활성화 시키는 것으로 설정한다.

- User-to-user e-mail : 사용자끼리 이메일을 주고 받을 수 있게 할 것인지.

- E-mail notification about changes : 각종 토론 페이지나 주시 항목들의 변경을 이메일 공지로 알릴 것인지 선택.

- E-mail address authentications : 사용자 등록을 할 때, 이메일 인증을 하게 할 것인지 선택

 4) 데이터베이스 설정 (Database config)

 - Database type : 사용할 데이터베이스를 선택한다. 선택되는 데이터베이스는 서버에 설치되어 있어야 한다.

- Database host : 데이터베이스 접근 위치를 선택한다. 위키와 데이터베이스가 같은 서버에 있으면 “localhost”를 사용하고, 다른 서버에 있으면 데이터베이스가 있는 서버 도메인이나 IP주소를 적는다.

- Database name : 3.1) 단계에서 생성한 데이터베이스 명칭을 적어준다. 이 예제에서는 “mediawiki”라고 이름 지었다.

- DB 사용자 정보 : 3.1) 단계에서 “mediawiki” 데이터베이스로의 접근 권한을 준, 사용자 정보를 입력한다. 이 예제에서는 username – “user1″, password – “password” 였다.

- Superuser 정보 : 3.1) 단계에서 수동으로 데이터베이스를 만들어 주지 않았다면 이 설정으로 자동으로 만들게 할 수 있다. mysql서버에서 데이터베이스를 만들 수 있는 높은 권한을 가진 사용자 정보를 입력하자. 그정도의 권한이 없으면 3.1) 단계에서처럼 관리자에게 요청하여 수동으로 만들자.

- Database table prefix : MediaWiki에서 사용할 DB 테이블들의 접두어를 정한다. 필자의 경우는 “nmw_” (nineye media wiki) 라고 붙였다.

- Storage Engine : MyISAM은 디폴트 storage engine이며, 트랜젝션을 지원하지 않는다. InnoDB는 트랜젝션을 지원한다. 즉, MyISAM은 속도가 빠른 대신, 충돌이 발생할 가능성이 많기 때문에 위키를 혼자 사용할 때만 선택할 수 있다. InnoDB는 여러 사람이 위키를 동시에 이용해도 충돌이 발생하지 않는 대신, 속도가 느리다. 위키의 목적에 따라 설정하자. 단, MyISAM을 선택할 때는 반드시 혼자만 편집 가능하다는 것을 전제로 해야 한다.

- Database character set : 데이터베이스에서 사용할 문자 코드를 선택한다. 아래 설명에 보면 binary mode가 더 효율적이라고는 하는데, 필자는 귀찮아서 그냥 utf-8을 선택했다.

 5) Install MediaWiki 버튼을 눌러서 설정을 적용 시킨다.

설명대로 설정을 했다면 위와 같이 “Installation successful!”이 뜰 것이다. 만약 에러가 발생하면 에러메세지를 읽고, 지시에 따라 다시 설정하자.
그리고 위 페이지에서 시키는 대로, config/LocalSettings.php 파일을 상위 디렉토리로 이동시키고 “chmod 600 LocalSettings.php”로 접근 권한을 설정해 주자. 이는, LocalSettings.php는 아파치가 생성한 파일이므로, 아파치를 제외한 그 누구도 이 파일에 접근하지 못하게 한다. 왜냐면 이 파일에는 위키를 설정한 사용자 정보가 암호까지 그대로 저장되어 있기 때문이다. 참고로 위처럼 권한을 변경하려면 관리자 권한이 있어야 한다.

5. http://yourdomain/~user1/wiki/ 로 접속하면 설치된 위키가 뜬다.

Extention

여기에서는 필자가 설치해 본 extention들을 적는다. 설명까지하면 너무 길기 때문에 간략하게 소개만 하고, 내용이 많은 경우 따로 링크를 건다.

• LiquidThreads

각 문서의 토론 페이지에서, 댓글 형식으로 글을 달 수 있게 함

• IssueTracker

맨티스와 비슷한 이슈 추적기이며, 문서 마다 이슈를 추적할 수 있게 되어 있고, 아주 심플하게 구성되어 있음

• SyntaxHighlight_GeSHi

WordPress의 SyntxHighlight와 같은 역할을 하며, 각종 코드를 코드 표현 방식에 맞게 표현해 줌

• Wiki2LaTeX

http://nineye.net/blog/archives/1355 여기 참조

결론

결론적으로는, MediaWiki 자체에는 문제가 거의 없었는데, extension들을 설치하다 보니 문제가 많았다. 우선, MediaWiki에서는, 등록된 각 extension들에 대해 사용자가 정확히 인지를 하지 못한다는 단점이 있었다. wordpress 사이트에서는 plugin들을 인기도에 따라서 정렬을 하고, 각 plugin들에 대해, 정해진 포맷대로 명확하게 설명을 해놓게 해서, plugin 사용자들이 뛰어난 기능의, 문제없는 plugin을 쉽게 선택할 수 있었다. 하지만 MediaWiki에서는 아무리 뒤져봐도 좋은 품질의 extension대로 정리해 놓은 곳이 없었다.
사용자들이 직접 만드는 plugin이나 extension에게 가장 중요한 것은 그것들의 품질이다. 품질을 평가하는 시스템이 없다면 사용자들은 수많은 plugin들을 설치해서 사용하기전까지는 어떤 plugin이 가장 좋은 지 알 수 없다. 이런 기본적인 부분도 소홀히 한 MediaWiki가 이해가 되지 않았다.
어쨌든 MediaWiki 자체는 정말 뛰어난 위키 툴인 것 같다.