이전에는 제대로 접속이 되었고 지금도 Firefox 에서는 제대로 접속이 되고 있는 것을 보니 IE8 의 문제인가 싶었는데 다른 컴퓨터에 설치된 IE8 로 접속을 해보니 제대로 접속이 되었다. 그렇다면 내가 사용하고 있는 컴퓨터의 IE8 버전에만 한정되어 나타나는 문제구나 싶었는데, 집에서 사용하고 있는 컴퓨터도 마찬가지였다.

대체 어디가 문제인가 고민하던 중에 Webknight 의 로그 파일을 확인했는데

BLOCKED: Header 'User-Agent:' too long ;

이라는 에러메시지가 나와 있었다. 저 에러 메시지로 검색해보니 Webknight Config 프로그램에서 Request Limits 의 Max Headers 항목중 User-Agent 키 값을 256 에서 1024 로 변경해 주는 해결 방법으로 처리할 수 있었다.

말하자면 IE8 의 User-Agent 정보가 너무 길어서 WebKnight 가 블럭 처리했다는 것인데 왜 이런 일이 발생하는 지 모르겠다. IE8에 설치한 확장 기능이나 Windows Live 관련 프로그램의 설치로 인해 문제가 발생하지 않았나 짐작하고 있는데, 일단은 User-Agent 값을 변경해 주는게 가장 빠른 처리 방법일 듯 싶다.

필코 마제스터치 104키 클릭형 키보드로 체리스위치의 청색축을 사용한 물건인데, 클릭형 이어서 소리가 상당히 크다. 개인적으로는 넌클릭보다 클릭을 선호해서 좋아하긴 하지만 사무실에서 타이핑 작업에 사용하기는 힘들 것 같다. 나에게 이 키보드를 준 친구도 그 소리 때문에 사무실에서 사용하기 힘들어서 집에다 가져다 놓았다는데, 잠시 타이핑 해보니 이해가 간다. 키보드를 가지고 서울에 올라와서 지난주에 키 스킨과 칼라 키 캡을 Iomania 에서 구입해서 교체했는데 키 캡 네 개 교환한 것으로 키보드가 많이 달라 보여서 신기했다. 원래는 ESC키만 바꿀 생각이었는데 예전에 사용하던 키보드들이 WASD 키 각인이 금방 지워지는 것을 떠올리고는 같이 주문했다. 여유가 좀 있었다면 이중 사출 키 캡을 질렀을 지도 모르지만 배보다 배꼽이 더 커질 것 같아서 그렇게는 못하겠더라. 또, 키 스킨을 씌우니 소음이 확 줄어들기는 하지만 사각사각하는 느낌이 확 줄어들고 손가락에 힘도 많이 들어가서 사용하지 않을 때 덮개로 사용하기로 했다. 소음 감소용으로 사용하기에는 씌우고 나서의 느낌이 확 줄어들어서 효용이 있을지 모르겠다. 

위의 사진은 키 스킨을 주문할 때 같이 주문했던 키 캡 리무버인데 사용해보니 이게 생각했던 것 보다 훨씬 편리해서 놀랐다. 힘도 적게 들어가고 키 캡 제거할 때 핀이 부러지거나 하는 일도 없을 것 같아서 써보고 잘 샀구나 생각하는 물건이다. 구조가 굉장히 단순하기 때문에 손재주가 있는 분들이라면 쉽게 자작할 수도 있을 것 같다. 가늘고 탄성 좋은 철사와 마트에서 파는 에폭시 퍼티 정도만 있으면 만들 수 있을 것 같은데.

사각사각하는 기계식 키보드를 오랜만에 써보니 타이핑이 즐거워지긴 했는데, 타이핑 할 일이 많지 않아 일단은 연결해서 PC 옆에 놓아두고 있다. 나중에 긴 문서를 작성할 때가 기다려진다.

http://www.mediawiki.org/wiki/Manual:Upgrading 에 나와있는 업그레이드 방법을 살펴보면서 순서대로 진행했는데 대충 요약해 보자면 백업 후에, 새로운 파일을 받아서 덮어씌우고 업데이트 스크립트를 실행시키는 순서입니다. 백업은 최근에 한 것이 있기 때문에 패스하고 바로 두 번째 순서부터 진행했는데

새버전의 파일을 다운로드 해 미디어위키가 설치된 곳에 업로드 한 뒤에 위의 명령어를 쳐주면 기존 디렉토리에 새로운 파일 압축을 해제하면서 파일 업데이트 해줍니다.

그 다음에는 /maintenance 디렉토리로 이동하여

라고 업데이트 스크립트를 실행시켜 주시면 업데이트가 끝나게 됩니다. php가 path 환경 에 설정되지 않은 경우도 있으니 이런 경우에는 php 실행파일의 절대경로를 넣어주시면 되고요.

이런 형태가 되겠네요. 이러한 과정을 마치고 깔끔하게 업데이트가 끝나면 참 좋겠지만 제 경우에는 마지막 업데이트 스크립트를 실행시키는 과정에서 에러가 발생했습니다. 예전에 설치했던 Syntax highlight 익스텐션 때문에 발생하는 에러였는데 $languagesPath 에 나와있는 경로가 올바르지 않다는 에러였습니다.

Warning: opendir(/extensions/geshi/geshi): failed to open dir: No such file or directory in /extensions/GeshiCodeTag.php on line 63

ERROR: Invalid directory path – [extensions/geshi/geshi], Modify the value of $languagesPath'

이런 에러메시지가 나타난 경우에는 /extensions/GeshiCodeTag.php 파일을 열어서 13번째 라인의 경로를 절대경로로 바꾸어 주시면 해결됩니다.

그 외에도

No superuser credentials could be found. Please provide the details of a user with appropriate permissions to update the database. See AdminSettings.sample for more details.

와 같은 에러메시지가 나올 경우도 있는데 미디어 위키 사이트에서는 데이터 베이스의 접근 권한을 확인하라고 나와있습니다. 그런데 실제로는 메인디렉토리에 AdminSettings.php 파일이 존재하지 않아서 발생하는 경우도 있으니 이런 경우에는 이 파일을 작성해 주시면 문제가 해결됩니다.

워드프레스의 업데이트 보다는 가끔 하는 일이라서 언젠가 정리해 놓아야겠다고 생각했는데 이제서야 하게 되네요.

뭐 벼락 같은 일이라고 하기에도 소소하지만, 어제 오후 2시에 무슨 생각이었는지 예전에 설치해 놓았던 Adlogger 의 테이블들을 지워야겠다고 생각하고 phpmyadmin으로 작업을 하다 데이터 베이스 전체를 드랍 해버리는 정말 멍청한 짓을 저질러 버린 것이다. 내가 무슨 일을 저질렀는지 알아차린 순간, 뒤통수를 망치로 세게 맞은 느낌과 함께 멍하게 브라우저 리프레시 버튼만 누르고 있는 나를 발견할 수 있었다.

가장 최근의 백업이 지난해 6월이지만 그 사이 블로그가 닫혀져 있는 상태여서 그것으로 복원하면 되겠다 싶었는데, 최근에 올렸던 글들이 아쉬워서 혹시 방법이 있을까 하고 찾아보았는데 2가지 정도의 방법이 있었다.

하나는 mysql 의 데이터 베이스 파일이 저장되는 var 폴더에서 지워진 파일들을 복구하는 것이었고, 다른 하나는 mysql 의 바이너리 로그를 이용해 복원하는 방법이었는데 처음의 방법은 하드디스크를 umount 하고 작업을 해야 하는데 파티션 분할을 어떻게 했는지 그것이 되지 않아 제대로 실행을 할 수가 없었다. 두 번째 방법은 바이너리 로그를 Sql 파일로 변환해 복구하는 작업까지는 진행했지만 이제 어디서 꼬였는지 제대로 살려지지 않아서 결국 2시간 정도 작업하다 포기하고 말았다. ( 나는 실패한 방법이지만 이런 재난을 당했을 때 충분히 시도해볼 만한 작업들이다.)

그래서 결국에는 구글이 수집한 cache 된 페이지들과 블로그에 글을 올릴 때 사용한 Live Writer 에 저장된 글들을 가지고 작년 데이터에 다시 글을 작성하는 방법으로 복구를 했다. 덕분에 그 사이 댓글 남겨주신 분들의 데이터가 날아갔는데 기억나는 것들은 일일히 직접 입력해 살려놓았다.

대충 살아 난 것 같아, 백업을 하고 나서 보니 이번에는 slimstat 의 지금까지의 누적 히트수에 조금 문제가 있었다. 바이너리 로그를 복원하면서 뭔가 문제가 생긴듯한데 380만 정도여야 하는 히트수가 660만이 넘어가 있었다. 대충 계산해 보니 그 이후의 히트수를 합해 400만도 넘어갔고 잘못된 데이터가 남아있는 것도 마음에 들지 않아 결국에는 이 데이터도 초기화 해 버렸다.

날벼락 맞은 덕분에 이것저것 새로 정비를 했지만, 다신 이런 멍청한 짓을 저지르지 않도록 기도라도 해야겠다. 마음 같아선 Crontab 에 매일 백업을 하도록 예약 작업이라도 지정해놓고 싶지만 그건 좀 힘들것 같고 뭔가 또 다른 백업 방법을 찾아보아야 할 것 같다.

예를 들면 현재 월드 오브 워크래프트의 새로운 공격대 던전인 얼음왕관 성채에 가기 위해선 일정 정도의 DPS (Damage per Second)를 낼 수 있어야 하고 그러한 조건을 만족시키기 위해서는 상위의 아이템들을 보유하고 있어야 하는 것이다. 80레벨이라는 레벨의 한계에 다다르게 되면 그 이후는 결국 아이템을 어떤 계획으로 파밍하고 세팅하느냐에 따라 캐릭터의 능력이 조율 되는 것이다.

이러한 아이템 세팅 및 파밍을 도와주는 프로그램이 있는데 그게 바로 지금 소개할 Rawr 이다.

다운로드 링크

현재 2.3.5 버전까지 나와 있는 Rawr 은 자신의 캐릭터 정보를 전투정보실에서 불러와 아이템 구성을 보여주고, 현재 상태에서 기대할 수 있는 DPS 및 TPS (Threat per Second) 등을 보여주고 마법 부여 및 보석장착을 통해 얻을 수 있는 최적화된 세팅 정보를 얻을 수 있을 뿐 아니라 아이템 교체 후 얻을 수 있는 변화들을 미리 체크해 볼 수 있어서 사용자의 아이템 파밍 계획을 세우는데 도움을 준다.

예를 들어 내 비전법사의 경우, 최근에 서리문장을 모아 Tier 10 의 장갑을 교환했다. 이전에 사용하던 Tier 9 – 1 의 장갑에 비해 대부분의 수치가 상승했으나 가속이 적중으로 바뀐 장갑인데, 이 장갑을 장착하자 기존의 DPS 가 하락했다.

위의 이미지 들을 보면 5345 – 5195 로 DPS가 하락한 것을 알 수 있다. 이것은 실제로 대도시의 허수아비를 상대로 한 테스트에서도 비슷한 결과를 내는데, 새로 교체한 장갑이 아이템 레벨이 높긴 하지만 가속이 적중으로 바뀌어 적중이 오버되고, 가속이 떨어져 발생하는 결과라고 할 수 있다. 더구나 Tier 9 4세트의 효과가 장갑을 교체함으로 인해서 사라지므로 Tier 10 2세트 이상을 바꾸기 전까지는 DPS의 상승을 바랄 수 없다는 이야기가 된다. 재미있는 것은 위의 이미지에 나온 상태에서 바지를 Tier 10 으로 바꾸었을 경우에는 DPS가 5500 대로 증가한다. 결국 Tier 10 2세트이상을 맞추기 전에는 Tier 9 4 세트가 낫다는 결과가 된다. 이렇듯 여러 아이템들을 바꾸어가며 실제 상층치를 예상할 수 있기 때문에 장신구 교체로 인한 이득을 계산하는데도 편리하고 마법 부여 및 보석장착으로 최대한의 효과를 얻을 수 있도록 도와준다.

기본적으로 영문버전의 프로그램이어서 기본 사용에 어려움을 겪을 수 있지만, 아이템의 경우는 전정실에서 캐시 정보를 업데이트해 가지고 올 수 있기 때문에 간단히 아이템 교체를 통한 DPS 변화 만을 체크해 보는 정도라면 유용하게 사용할 수 있다. (캐시 업데이트에 시간이 많이 걸린다.)

보석의 세팅에 따라 얻을 수 있는 최고 DPS 및 아이템의 업그레이드 계획도 낼 수 있으니 어떤 방식으로 아이템을 세팅해야 할 지 고민하시는 분들이라면 한 번 사용해 볼 만한 프로그램인 것 같다.

자세한 사용법은 아래의 링크를 참조 하시길

Rawr 기본 설명서

내 경우 잠시 사용해 보니 비전 법사의 DPS 예측 수치가 크게 다르지 않게 나오는 것 같았다.

원래 예전 데이터 베이스의 바이너리 파일을 그대로 복사해서 가지고 있었기 때문에 새로 구축한 서버에 그 파일들을 옮기면 작업이 완료될 것 이라고 생각했는데 어디선가 문제가 발생한 모양이었다. 바이너리 파일을 그대로 복사하여 복원하는 방법은 이미 Vmware에 설치 한 CentOS 에서 테스트 해서 이상이 없는지 확인을 했었기 때문에 별 문제 없을 거라고 확신하고 있었는데 문제가 발생하니 좀 난감했다.

처음에 시도했던 방법은 현재의 데이터 베이스를 지우고 백업했던 sql 파일로 복원하는 것이었는데 이게 제대로 작업이 되지 않았다.

Specified key was too long; max key length is 1000 bytes

라는 에러메시지와 함께 복구 작업이 진행되지 않아 - -force 옵션을 주고 강제로 복원을 시도했는데 누락되는 테이블이 있었다.

결국 sql 문을 수정해야 할 것 같아 살펴보다 CentOS 쪽에 살려놓은 데이터 베이스에서 mediawiki 의 InnoDB 타입으로 된 테이블을 복구하는 작업에서 문제가 발생한다는 것을 알았다. 그래서 혹시나 하고 서버에 설치된 mysql이 InnoDB 를 지원하는 지 확인해보니 지원이 되지 않는 상태였다.

서버를 설치했던 후배에게 연락을 해서 InnoDB를 일부러 뺐는지 확인을 한 뒤에 my.cnf 파일에 주석처리 된 관련 설정들을 다시 풀고 mysql 을 재시작 했는데, 에러 때문에 시작에 문제가 있었다. InnoDB 관련 옵션들을 찾을 수 없다고 하는 메시지 였는데 일부러 InnoDB를 빼지 않았을텐데 왜 이런 메시지가 발생하는지 알 수 없어 검색해보니 5.0.X 버전과 5.1.X 버전과의 차이 때문인 것 같았다.

이전 버전에서는 따로 옵션을 주지 않으면 기본으로 포함되는 것으로 알고 있었는데, 5.1.X 버전부터는 –with-plugins=innobase 옵션을 추가해주고 컴파일 해줘야 InnoDB가 활성화 된다는 것이었다. 다시 mysql 을 컴파일하니 sql 파일 복원에 나타나던 에러메시지가 나타나지 않았다. 처음에는 5.0.X 버전에서 상위 버전으로 데이터를 이전하면서 발생하는 문제인 줄 알았는데 InnoDB의 문제를 해결하고 나니 –default-character-set 정도의 옵션만 주의해주면 별 다른 문제 없이 이전이 가능했다.

innoDB를 사용하지 않는다면 버전차이가 있다고 해도 큰 이상은 없는 것 같고. mediawiki 처럼 innoDB를 사용하는 툴의 경우에는 mysql에 설정이 어떻게 되어 있는지 확인해 보고 작업을 진행하는 것이 올바른 순서인 것 같다. 짧지 않는 시간동안의 이런저런 시도로 결국 에러는 잡았지만 어제 새로 작성한 포스트도 있고 복구에 사용한 백업 파일에 누락된 내용들이 있어서 가지고 있는 백업본들을 이리저리 짜깁기 해서 데이터들을 복구하느라 시간은 생각보다 많이 걸렸다. phpmyadmin 이라도 깔려있었기에 그나마 빨리 끝날 수 있었던 것 같다.

원래는 4주년 기념 포스트 공개 예약을 해두고 있었는데 해가 바뀌고 나서야 4주년 기념 포스트를 공개하게 되는 군요. 절망클럽이 잠들어 있는 사이 다른 블로그에 간간히 올렸던 포스트들을 몇 가지 추려 이 곳으로 옮겨오는 작업도 해야 할 것 같습니다.

그나마 다행인 것은 이런 저런 백업 덕분에 이전과 거의 동일하게 복구가 가능했다는 점인 것 같습니다. 데이터 베이스를 백업 하지 못해서 조금 걱정했는데 그것도 나중에 고장한 하드디스크를 연결해 온라인에서 var 디렉터리 아래의 파일들을 복사하는 것으로 백업을 했고요.

이번 일을 겪으면서 새삼 느낀 점인데, 모든 일이 다 그렇겠지만 서버 관리 쪽에서 경험이라는 부분이 매우 중요한 것 같습니다. 발생한 문제에 대해 대처하는 방법도 경험이 있는 것과 없는 것에는 큰 차이가 있으니까요. 어쨌든 절망클럽도 복구했으니 매일은 아니더라도 자주 글 좀 올려야겠습니다.

워드프레스 기반의 블로그에 설치하면 아이폰이나 터치에서 최적화된 페이지를 볼 수 있도록 도와주는 플러그 인인데, 막상 활성화 하고 나니 이게 제대로 동작하는지 확인할 길이 없었다. 주변에 아이팟 터치라도 가지고 있는 사람이 있으면 좋으련만, 그렇지 못해서 브라우저 에뮬레이션으로 확인할 방법을 찾던 중에 Safari 에서 간단하게 확인할 수 있는 방법을 찾았다.

위의 이미지가 바로 사파리에서 본 블로그의 모습인데, WPtouch 플러그인이 활성화된 상태라 저렇게 나오고, 아래에 있는 모바일 테마 버튼을 끄면 원래의 테마 모양대로 보여준다.

확인한 사파리 버전은 4 버전으로 방법은 간단하다.

메뉴의 편집 > 기본설정 > 고급 탭에서 개발자 모드를 켜준 뒤에, 사용자 에이전트를 iphone 용 모바일 사파리로 바꾸어 주면 된다. 모바일 테마를 끈 경우 다시 모바일 테마 상태로 보고 싶다면 사파리를 닫고 다시 실행시키면 되니 참고 하시길.

  윈도우즈용 사파리에서 확인한 화면이니 궁금하신 분들은 사파리 한 번 깔아보시는 것도 괜찮을 것 같다.

블리자드의 온라인 게임 World of Warcraft (이하 WoW 혹은 와우) 의 특징 중 하나로 Addon 즉, 외부 인터페이스 라는 것을 이용해 사용자가 자신의 인터페이스를 커스터마이징 할 수 있다는 점을 들 수 있다. 매크로 지원과 함께 이 외부 인터페이스는 기본 제공되는 형태의 인터페이스의 확장 및 변경을 통해 사용자에게 여러 편의를 제공했다. 또한 그 중 유용한 애드온 들은 따로 묶여 패키지로 배포 되기도 했다.

그런데 이러한 외부 인터페이스가 WoW의 업데이트로 인해 에러가 발생하거나 출력에 문제가 생기게 되면 해당 애드온이 업데이트 될 때까지 기다리거나 때에 따라선 삭제해야 하는 문제도 함께 가지고 있었으며, 많은 애드온이 포함된 패키지를 사용할 경우 시스템 리소스를 많이 차지하게 되어 저성능의 PC 에서는 게임의 실행 속도가 저하는 문제도 함께 가지고 있었다.

이러한 문제 때문에 나도 처음에는 하늘아리 같이 패키지로 묶인 애드온 프로그램들을 사용하다가, 나중에 Wow ace Updater 라는 프로그램을 알게되어 마음에 드는 애드온들만 선택해 설치해서 사용하곤 했었다. 그러다 최근에 다시 와우를 시작하면서 이 애드온 업데이터가 생각이나 실행했더니 현재는 Curse Client 라는 것으로 바뀌어 있었다.

Curse Client 는 이전 WoW Ace 에서 제공하던 애드온의 설치 및 업데이트 기능에서 발전하여 자체 계정을 이용한 애드온 설치 정보 프로필의 공유 기능 및 커스텀 UI 패키지를 만들 수 있는 기능들을 제공한다.

프로필 공유 기능은 Curse Client 만 설치해 놓았다면 어느 PC 에서나 자신이 집에 세팅한 UI 정보를 가져와 설치할 수 있도록 해주기 때문에 여러 곳에서 게임을 플레이 하는 사람에게는 외부 인터페이스 설정을 간편하게 해준다.

단점이 있다면 Beta 버전을 이용하는 관계로 Client 자체의 업데이트가 잦고 속도가 느리다는 점 정도를 들 수 있을 것 같다.

현재 Curse Client로 Combucter 나 Decursive, Jpack 같은 애드온 들을 설치해서 쓰고 있는데 수 많은 애드온 중에 마음에 드는 것을 골라 사용해 보는 재미도 있고 자신만의 애드온 설정을 할 수 있다는 장점도 있는 것 같다.

자신만의 애드온이나 패키지와 달리 가벼운 애드온 들을 이용해 보고 싶은 분들이라면 사용해 보시면 좋을 것 같다.

다큐멘터리 형식을 빌려 시작되는 영화 디스트릭트 9은 기존 외계인이 등장하는 SF 영화와는 많이 다르다. 외계인의 등장 후 그 존재로부터 비롯된 공포와 호기심은 이제 일상과 처치 곤란한 불청객에 대한 불만으로 변해 버린 상태다. 이전의 영화에서 과학적으로 우월하여 우리를 지배하려 하거나 아니면 우리와 친구가 되려던 외계인들과는 달리 외계인 프런들은 전혀 쓸모 없이 귀찮고 해를 끼치는 존재로 등장한다. 자신과 다른 사람에 대한 차별의 대상이 외계인 난민인 프런으로 바뀌었을 뿐이다.

주인공 비커스 조차 그들을 조롱하고 하찮게 대한다. 하지만 그가 외계물질로 인해 유전형질에 변화를 겪게 되면서 상황은 뒤바뀌게 된다. 외계인들만 이용할 수 있었기 때문에 지금까지 쓸모 없었던 외계 무기들을 비커스가 사용할 수 있게 되면서 그의 존재 자체가 하나의 중요한 실험체이자 자원이 되어 버린 것이다. 하지만 이 사건으로 인해 비커스는 아내와 떨어지게 되고 MNU로 부터 쫓기는 신세가 되고 만다.

디스트릭트 9은 초반에 외계인의 등장과 습성 등 관객이 알아야 할 정보들을 풀어 놓느라 다소 지루하게 전개된다. 게다가 비커스가 프런들을 대하는 방식들도 곱게 보이지 않는다. 하지만 중반 이 후 비커스의 몸이 변화하는 순간부터 이야기는 숨 쉴새 없이 관객을 몰아간다.

지금 지구 어디에선가는 벌어지고 있을지 모를 사건들을 외계인 난민에 빗대어 이야기 하고 있는 이 영화는 너무나 인간적이어서 그 약점과 단점들도 고스란히 가지고 있는 주인공 비커스를 통해 인간에 대해 이야기하고 있다.

독특한 소재와 구성 그리고 생각해 볼 주제를 가진 SF 영화를 오래간 만에 본 것 같다. 특수효과도 좋았고 특히 마지막에 등장했던 전투 메카닉은 모형으로도 인기가 있지 않을까 생각이 들더라.