| 먼저 설치형 텍스트큐브 1.7.7 버전에서 저장 오류가 나오는 문제를 살펴보겠다. 텍스트큐브 1.7.7을 사용하다 보면 FTP프로그램 등으로 폴더의 권한설정을 제대로 했는데도 불구하고 관리자 화면에서 스킨편집을 하거나 또는 글을 쓴 다음 저장을 하려면 권한이 없다는 알림창이 뜨는 경우가 있다. 아니면 30초 정도 흐른 뒤 오류창이 뜨고 그대로 계속 놔두면 다시 30초 흐른 뒤 오류창이 뜨는 걸 무한반복 하기도 한다. 그것은 .htaccess 라는 파일이 원인으로서 설치형 텍스트큐브 공식사이트의 공지에 그 해결법이 나와있다. 1.7.7 사용자는 자신의 서버에 접속하여 .htaccess 파일을 보도록 한다. RewriteBase / RewriteCond %{REQUEST_FILENAME} -f RewriteRule ^(cache)+/+(.+[^/])\.(cache|xml|txt|log)$ - [NC,F,L] RewriteCond %{REQUEST_FILENAME} -d RewriteRule ^(.+[^/])$ $1/ [L] RewriteCond %{REQUEST_FILENAME} !-f RewriteRule ^(thumbnail)/([0-9]+/.+)$ cache/$1/$2 [L] RewriteRule ^(.*)$ rewrite.php [L,QSA] 위와 같은 것을 아래처럼 고친다. RewriteBase / RewriteRule ^(thumbnail)/([0-9]+/.+)$ cache/$1/$2 [L] RewriteCond %{REQUEST_FILENAME} -f RewriteRule ^(cache)+/+(.+[^/])\.(cache|xml|txt|log)$ - [NC,F,L] RewriteCond %{REQUEST_FILENAME} -d RewriteRule ^(.+[^/])$ $1/ [L] RewriteCond %{REQUEST_FILENAME} !-f RewriteRule ^(.*)$ rewrite.php [L,QSA] 본래 이것은 1.7.1 때 있었던 버그라고 공지에 나와있으나 어찌 된 건지 2009년 4월 이후에 텍스트큐브 1.7.7 버전을 받은 사람이라도 그 버그를 겪을 수 있다. 내 생각에는 아마도 개발자들이 1.7.8을 테스트 하느라 그 이전 버전에는 신경 쓸 여력이 없기 때문으로 보인다. 더군다나 .htaccess 파일의 경우에는 처음부터 생성되어 있는 파일이 아니라 서버에 업로드를 한 후 checkup을 하며 생성되는 파일이기 때문에 개발자들이 그것을 확인하기는 힘들었을 수 있다고 본다. 때문에 .htaccess파일의 오류에 대해서 만큼은 개발자들이 대처하기 어려웠을 것이다. 버그가 하나도 없는 것을 처음부터 올려놓아주면 고맙긴 하겠지만 사용자들이 스스로의 지식을 쌓아올리거나 내성을 기르기 위해서는 완벽한 파일을 내려받기만 하는 것 보다 포럼과 공지를 직접 찾아봐야 할 필요성이 어느 정도 있다고 보기에 경험을 쌓게 해준 개발진에게 오히려 나는 감사하게 생각한다. 구글로 넘어가서 그런지도 모르지만.. 담당자가 빠졌나? ;) 잘 모르지만 어찌됐건 조금 고생했다. 이제는 업로드의 문제를 살펴보자. 서버를 직접 돌리는 사람을 제외하고 일반적으로 본다면 호스팅 업체에서 제공하는 웹서버 경로를 통하거나 또는 FTP 프로그램으로 접속하는 경우가 있을 것이다. 웹서버를 이용해서 업로드 한 파일은 웹서버 아이디의 권한으로 지정되고 따로 프로그램을 사용하여 올리면 그 프로그램 아이디 권한으로 지정이 되기 때문에 권한 변경이 안 되거나 삭제가 안 되는 문제가 생기곤 한다. 다만 프로그램에서 접속하는 것보다 호스팅 업체 제공의 웹서버 쪽이 권한이 더 높기 때문에, FTP프로그램에서 삭제가 되지 않는 파일은 호스팅 업체의 웹서버로 접근하여 삭제하면 된다. 그런데 업로드나 서버의 파일을 내려받기할 경우 상황이 조금 틀리다. 일반적으로 호스팅 업체의 서버에는 최대 전송량이 정해져 있다. 최대 수용할 수 있는 트래픽을 말하는 것이 아니라 다운로드/업로드 때 패킷의 최대 제한치를 말한다. 특히 기업홈페이지를 대상으로 하는 호스팅 업체 보다는 개인 홈페이지(블로그) 등을 주로 상대하는 호스팅 업체의 품질이 안 좋다고 생각되는데 그것은 단순히 나의 경험에서 우러나온 추측이다. 이처럼 서비스 하는 곳마다 다 틀리기 때문에 확정지어 말하기는 힘들지만 평범한, 또는 약간 서비스 질이 안 좋은 호스팅 업체를 사용하면 가령 다운로드 때 80KB/s 제한, 업로드 때 30KB/s 10MB/h 제한 같은 괴상망측한 제한들이 걸려 있다. 그런데 여기서 말하는 호스팅업체의 패킷제한(대역폭)이라는 것은 일반적인 인터넷회선의 이용제한과는 조금 다르다. 그 보다 높은 속도로 다운로드를 하거나 서버에 업로드를 할 때 자신의 인터넷회선 만큼 비정규적으로 더 좋은 속도를 낼 수 있는데, 그 경우 십중팔구 서버에 과부하가 걸리게 될 것이다. 인터넷의 경우처럼 본래부터 성능 좋은 서버에서 제한을 거는 것이 아니라 애초부터 그 정도의 능력밖에 못내는 장비로 서버호스팅을 하고 있다는 얘기다. 결국 트래픽은 널널한데도 불구하고 한동안 아무것도 안 되는 맛이 간 상태가 되어버린다. 이때는 탓할 게 아무것도 없다. 단지 그런 호스팅 업체를 택한 스스로를 원망할 수밖에 없는 노릇이다. 그렇다고 아직 남아있는 호스팅 서비스 기간을 놔둔 채 다른 곳을 선택하기도 어정쩡하다. 그럴 땐 그 호스팅 업체의 서버에 맞는 전송속도로 다운로드와 업로드를 해야한다. FTP프로그램 마다 업로드 속도가 틀린데, 어떤이는 속도가 잘 나오는 프로그램이 있으니 그걸 쓰라고 권유한다. 하지만 앞서 설명한, 애초부터 부족한 능력을 지닌 서버장비로 인해 생기는 문제 같은 것이 있기 때문에 전송 속도가 빠르게 나온다고 해서 무조건 좋은 프로그램인가 아닌가는 사용자마다 다르게 받아드려야 한다. 서버에 과부하를 주지 않으면서 속도가 잘 나오게 만드는 프로그램이 가장 좋은 것이고 그런 프로그램은 있을 수가 없다는 점을 알아야 한다. 잘 알려져있고 쉽게 작동시킬 수 있는 프로그램이라도 전송속도를 정할 수 있는 프로그램은 많지 않다. 만약 FTP프로그램을 이용해서 서버에 파일을 업로드 하던 중 프로그램이 멈추는 등 오류가 난다면 그것은 서버에서 정해진 전송 속도를 넘어버려서 서버 쪽에서 자동적으로 닫아버리거나 업로드 명령을 뒤로 미뤄버리게끔 신호를 보냈을 가능성이 크다. 그 같은 문제점 때문에 나의 경우에는 전송속도를 정할 수 없는 간이 FTP클라이언트는 사용하지 않고 filezilla 를 주로 사용한다. filezilla는 무료이고 다국어를 지원하므로 한글 인터페이스로 할 수 있다. 그 외에 전송되는 파일갯수도 설정가능하다. 당연한 기능 같겠지만 대부분의 간이 FTP클라이언트에는 없는 기능이다. 누누히 설명 하지만 간이 FTP클라이언트는 말 그대로 간단해서 편리하겠지만, 호스팅 서비스를 받는 사람의 입장에서는 어떤 프로그램을 쓰느냐에 따라 스트레스를 받고 안 받고의 차이가 정해질 걸로 보인다. |
"로그한다" 분류의 다른 글
| 블로그 시작하자 - 적절한 타협점 찾기 3 (0) | 2007/05/15 |
| 블로그 시작하자 - 적절한 타협점 찾기 2 (0) | 2007/05/12 |
| 블로그 시작하자 - 적절한 타협점 찾기 1 (0) | 2007/05/06 |
Trackback URL : http://byecrazy.com/trackback/142
-
텍스트큐브 1.7.7 ~ 1.9 리뷰 + 니들웍스/TNF 리더 신정규님 인터뷰
Tracked from lunamoth 4th 2011/09/22 02:26
텍스트큐브 1.7.6 이후로 배포판에 대한 변경 사항 리뷰 글을 오랫동안 쓰지 못했는데, 정리 차원에서 1.7 트리, 1.8 트리의 각각의 안정 버전 배포판 별로 사용자로서 중요한 변경, 추가 사항을 짧게 요약 정리해봤습니다. 기존에 텍스트큐브를 사용하고 계신 분들이 간단히 업데이트 내용을 추적하는 데 도움이 되었으면 합니다. 아울러 텍스트큐브 소식이 궁금하신 분들을 위해서 텍스트큐브 개발을 진행 중인 니들웍스/태터네트워크재단의 리더이신 신정규님과...
당신의 의견을 작성해 주세요.