Code

How to use Django with mod_python
<<!
>>!!
mod_python에서 장고 운영하기
<<!!
=================================

>>!
Apache_ with `mod_python`_ currently is the preferred setup for using Django
on a production server.
<<!
>>!!
Apache_ with `mod_python`_은 제품 서버(production server)에서 장고를 사용하기 위해 
현재 가장 선호되는 설정입니다..
<<!!

>>!
mod_python is similar to `mod_perl`_ : It embeds Python within Apache and loads
Python code into memory when the server starts. Code stays in memory throughout
the life of an Apache process, which leads to significant performance gains over
other server arrangements.
<<!
>>!!
mod_python은 `mod_perl`_과 유사합니다 : 아파치 내에서 파이썬을 임베딩하고, 
아파치가 시작할때 파이썬 코드를 코드를 메모리에 로드합니다. 
코드는 아파치 프로세스가 살아있는 동안 메모리에 남아 있으며, 
이는 다른 서버구성보다 주목할만한 성능 향상을 이끌어 냅니다.
<<!!

>>!
Django requires Apache 2.x and mod_python 3.x, and you should use Apache's
`prefork MPM`_, as opposed to the `worker MPM`_.
<<!
>>!!
장고는 아파치 2.x 와 mod_python 3.x 를 필요로 하며, 
반드시 `worker MPM`_에 대비되는 `prefork MPM`_ 아파치를 사용해야 합니다.
<<!!

>>!
You may also be interested in `How to use Django with FastCGI, SCGI or AJP`_
(which also covers SCGI and AJP).
<<!
>>!!
`FastCGI, SCGI 또는 AJP 에서 장고 운영하기`_도 살펴보세요.
(SCGI와 AJP 또한 다룹니다).
<<!!

.. _Apache: http://httpd.apache.org/
.. _mod_python: http://www.modpython.org/
.. _mod_perl: http://perl.apache.org/
.. _prefork MPM: http://httpd.apache.org/docs/2.2/mod/prefork.html
.. _worker MPM: http://httpd.apache.org/docs/2.2/mod/worker.html
>>!
.. _How to use Django with FastCGI, SCGI or AJP: ../fastcgi/
<<!
>>!!
.. _FastCGI, SCGI 또는 AJP에서 장고 운영하기: ../fastcgi/
<<!!

>>!
Basic configuration
<<!
>>!!
기본 설정
<<!!
===================

>>!
To configure Django with mod_python, first make sure you have Apache installed,
with the mod_python module activated.
<<!
>>!!
mod_python에서 장고를 설정하기 위해서, 먼저 여러분은 mod_python 모듈이 활성화된 
아파치가 설치되어 있어야 합니다,
<<!!

>>!
Then edit your ``httpd.conf`` file and add the following::
<<!
>>!!
그리고 나서 여러분의 ``httpd.conf`` 파일을 열어서 다음을 추가하십시오::
<<!!

    <Location "/mysite/">
        SetHandler python-program
        PythonHandler django.core.handlers.modpython
        SetEnv DJANGO_SETTINGS_MODULE mysite.settings
        PythonDebug On
    </Location>

>>!
...and replace ``mysite.settings`` with the Python import path to your Django
project's settings file.
<<!
>>!!
...그리고 ``mysite.settings``를 여러분의 장고 프로젝트의 설정 파일에 대한 파이썬 경로로 대체하십시오.
<<!!

>>!
This tells Apache: "Use mod_python for any URL at or under '/mysite/', using the
Django mod_python handler." It passes the value of ``DJANGO_SETTINGS_MODULE``
so mod_python knows which settings to use.
<<!
>>!!
이는 아파치에게 지시를 합니다: "장고 mod_python 핸들러를 사용하여, 
'/mysite/' 이하의 어떠한 URL에 대해서든 mod_python을 사용하라." 
``DJANGO_SETTINGS_MODULE``의 값을 전달하여
mod_python은 어떤 설정을 사용해야 하는지 알게 됩니다.
(mod_python은 어떤 설정을 사용해야 하는지 ``DJANGO_SETTINGS_MODULE``의 값으로 알수 있습니다.)
<<!!

>>!
Note that we're using the ``<Location>`` directive, not the ``<Directory>``
directive. The latter is used for pointing at places on your filesystem,
whereas ``<Location>`` points at places in the URL structure of a Web site.
``<Directory>`` would be meaningless here.
<<!
>>!!
``<Directory>`` 지시자가 아니라, ``<Location>`` 지시자가 사용되고 있는 것을 주의하십시오. 
전자는 여러분의 파일시스템상의 위치를 가리키는데 반해, 
``<Location>``은 웹사이트의 URL 구조상의 위치를 가리킵니다.
여기서는 ``<Directory>`` 가 의미 없습니다.
<<!!

>>!
Also, if your Django project is not on the default ``PYTHONPATH`` for your
computer, you'll have to tell mod_python where your project can be found:
<<!
>>!!
또한, 만약  여러분의 장고 프로젝트가 컴퓨터의 기본  ``PYTHONPATH``상에 없다면, 
여러분의 프로젝트를 어디서 찾아야 하는지를 mod_python에게 알려줘야 합니다. 
<<!!

.. parsed-literal::

    <Location "/mysite/">
        SetHandler python-program
        PythonHandler django.core.handlers.modpython
        SetEnv DJANGO_SETTINGS_MODULE mysite.settings
        PythonDebug On
        **PythonPath "['/path/to/project'] + sys.path"**
    </Location>

>>!
The value you use for ``PythonPath`` should include the parent directories of
all the modules you are going to import in your application. It should also
include the parent directory of the ``DJANGO_SETTINGS_MODULE`` location. This
is exactly the same situation as setting the Python path for interactive
usage. Whenever you try to import something, Python will run through all the
directories in ``sys.path`` in turn, from first to last, and try to import
from each directory until one succeeds.
<<!
>>!!
여러분이 사용하는 ``PythonPath`` 값은 여러분의 어플리케이션에서 import 하려고 하는 
모든 모듈들의 부모 디렉토리를 꼭 포함해야 합니다. 또한  
``DJANGO_SETTINGS_MODULE`` location 의 부모 디렉토리를 포함해야 합니다. 
이는 바로 파이썬을 대화형으로 사용할때 
path를 설정하는 것과 똑같은 상황입니다. 
여러분이 무언가를 import 하려 할때마다, 파이썬은 import 가 성공할 때까지 
``sys.path`` 안의 모든 디렉토리를 처음부터 끝까지 차례로 시도해 봅니다.
<<!!
 
>>!
An example might make this clearer. Suppose
you have some applications under ``/usr/local/django-apps/`` (for example,
``/usr/local/django-apps/weblog/`` and so forth), your settings file is at
``/var/www/mysite/settings.py`` and you have specified
``DJANGO_SETTINGS_MODULE`` as in the above example. In this case, you would
need to write your ``PythonPath`` directive as::
<<!
>>!!
예제를 보면 확실해 집니다. 가령
``/usr/local/django-apps/`` 디렉토리 아래에 여러분의 어떤 어플리케이션
(``/usr/local/django-apps/weblog/`` 같은)이 있고, 여러분의 설정 파일은 
``/var/www/mysite/settings.py`` 이라서 여러분은 ``DJANGO_SETTINGS_MODULE`` 를 
위의 예제처럼 설정했습니다. 이 경우, 여러분은 ``PythonPath`` 지시자를 
아래와 같이 작성할 필요가 있습니다::
<<!!

	PythonPath "['/usr/local/django-apps/', '/var/www'] + sys.path"

>>!
With this path, ``import weblog`` and ``import mysite.settings`` will both
work. If you had ``import blogroll`` in your code somewhere and ``blogroll``
lived under the ``weblog/`` directory, you would *also* need to add
``/usr/local/django-apps/weblog/`` to your ``PythonPath``. Remember: the
**parent directories** of anything you import directly must be on the Python
path.
<<!
>>!!
이 path 에서, ``import weblog`` 와 ``import mysite.settings`` 둘 다 작동합니다. 만약 여러분의 
코드 어딘가에 ``import blogroll``가 있고 ``blogroll``이 ``weblog/`` 디렉토리 
아래에 위치하고 있다면, 여러분은 *또한* ``/usr/local/django-apps/weblog/`` 를 
``PythonPath`` 안에 넣어야 합니다. 
기억하십시오:여러분이 작접 import 하려고 하는 
모든 것들의 **부모 디렉토리**는 반드시 파이썬 path 상에 있어야 합니다.
<<!!

.. note::
    
>>!		
    If you're using Windows, we still recommended that you use forward
    slashes in the pathnames, even though Windows normally uses the backslash
    character as its native separator. Apache knows how to convert from the
    forward slash format to the native format, so this approach is portable and
    easier to read. (It avoids tricky problems with having to double-escape
    backslashes.)
<<!
>>!!
    만약 여러분이 Windows를 사용중이라면, 일반적으로 Windows는 역슬래시 문자(\)를 
    운영체제의 경로 구분자로 사용하지만, 우리는 여전히 슬래시(/)를 경로에 사용할 것을 
    추천합니다. 아파치는 슬래시 포맷을 어떻게 운영체제 포맷으로 변경할지 알기 때문에,
    이 방식이 간편하고(portable) 더 읽기 쉽습니다. 
		(이는 이중-이스케이프 역슬래시(\\) 문제를 
    피하는 꽁수입니다.)
<<!!

>>!
    This is valid even on a Windows system::
<<!
>>!!
    Windows 시스템상에서 이것 역시 유효합니다::
<<!!

        PythonPath "['c:/path/to/project'] + sys.path"

>>!
You can also add directives such as ``PythonAutoReload Off`` for performance.
See the `mod_python documentation`_ for a full list of options.
<<!
>>!!
여러분은 또한 ``PythonAutoReload Off`` 지시자를 성능을 위해 추가할 수 있습니다.
전체 옵션들은 `mod_python 문서`_에서 볼 수 있습니다.
<<!!

>>!
Note that you should set ``PythonDebug Off`` on a production server. If you
leave ``PythonDebug On``, your users would see ugly (and revealing) Python
tracebacks if something goes wrong within mod_python.
<<!
>>!!
여러분은 제품 서버(production server)상에서는 반드시 ``PythonDebug Off``로 설정해야 합니다. 
``PythonDebug On`` 인채로 두면, 만약 mod_python 안에서 뭔가 잘못 되었을때 
 여러분의 사용자들은 보기흉한(그리고 적나라한) 파이썬 traceback 들을 보게 될것입니다. 
 <<!!

>>!
Restart Apache, and any request to /mysite/ or below will be served by Django.
Note that Django's URLconfs won't trim the "/mysite/" -- they get passed the
full URL.
<<!
>>!!
아파치를 재 시작하면, /mysite/ 또는 그 아래의 어떠한 요청에 대해서도 장고가 처리를 합니다. 
장고의 URLconf는 "/mysite/" 를 trim 하지 않음을 주의 하십시오 -- full URL이 전달됩니다.
  
<<!!

>>!
When deploying Django sites on mod_python, you'll need to restart Apache each
time you make changes to your Python code.
<<!
>>!!
장고를 mod_python으로 운용할때, 여러분의 파이썬 코드를 변경할때마다 
아파치를 재 시작할 필요가 있습니다.
<<!!

>>!
Multiple Django installations on the same Apache
<<!
>>!!
한 아파치상에서 장고 다중 설치
<<!!
================================================

>>!
It's entirely possible to run multiple Django installations on the same Apache
instance. Just use ``VirtualHost`` for that, like so::
<<!
>>!!
한 아파치 인스턴스 상에서 다중 설치된 장고를 실행 시킬 수 있습니다. 바로 VirtualHost 를 
아래와 같이 사용합니다::
<<!!

    NameVirtualHost *

    <VirtualHost *>
        ServerName www.example.com
        # ...
        SetEnv DJANGO_SETTINGS_MODULE mysite.settings
    </VirtualHost>

    <VirtualHost *>
        ServerName www2.example.com
        # ...
        SetEnv DJANGO_SETTINGS_MODULE mysite.other_settings
    </VirtualHost>

>>!
If you need to put two Django installations within the same ``VirtualHost``,
you'll need to take a special precaution to ensure mod_python's cache doesn't
mess things up. Use the ``PythonInterpreter`` directive to give different
``<Location>`` directives separate interpreters::
<<!
>>!!
만약 여러분이 같은 ``VirtualHost``에서 두개의 장고를 설치할 필요가 있다면, 
여러분은 mod_python의 캐시가 꼬이지 않도록 하기 위한 특별한 예방책이 필요합니다. 
``PythonInterpreter`` 지시자를 사용하여 각기 다른 ``<Location>`` 지시자들이 인터프리터를 
분리하도록 하십시오::
<<!!

    <VirtualHost *>
        ServerName www.example.com
        # ...
        <Location "/something">
            SetEnv DJANGO_SETTINGS_MODULE mysite.settings
            PythonInterpreter mysite
        </Location>

        <Location "/otherthing">
            SetEnv DJANGO_SETTINGS_MODULE mysite.other_settings
            PythonInterpreter othersite
        </Location>
    </VirtualHost>

>>!
The values of ``PythonInterpreter`` don't really matter, as long as they're
different between the two ``Location`` blocks.
<<!
>>!!
각기 다른 두개의 ``Location`` 블럭 안에 있는 한, ``PythonInterpreter`` 의 값은 
전혀 문제되지 않습니다.
<<!!

>>!
Running a development server with mod_python
<<!
>>!!
mod_python에서 개발 서버(developement server) 실행하기
<<!!
============================================

>>!
If you use mod_python for your development server, you can avoid the hassle of
having to restart the server each time you make code changes. Just set
``MaxRequestsPerChild 1`` in your ``httpd.conf`` file to force Apache to reload
everything for each request. But don't do that on a production server, or we'll
revoke your Django privileges.
<<!
>>!!
만약 여러분이 개발 서버(developement server)에서 mod_python을 사용한다면, 
여러분은 코드를 바꿀때마다 아파치를 재시작 해야하는 불편함을 피할 수 있습니다. 
바로 ``httpd.conf`` 파일에 ``MaxRequestsPerChild 1``을 설정하여 매 요청마다 강제로 아파치가 모든것을 리로드 하도록 합니다. 
하지만 제품 서버(production server) 상에서는 이렇게 하지 마십시오. 그렇지 않으면,
여러분의 장고 권한들을 재호출합니다.
<<!!

>>!
If you're the type of programmer who debugs using scattered ``print``
statements, note that ``print`` statements have no effect in mod_python; they
don't appear in the Apache log, as one might expect. If you have the need to
print debugging information in a mod_python setup, either do this::
<<!
>>!!
만약 여러분이 여기저기 흩어진 ``print`` 문을 사용하여 디버깅하는 프로그래머 부류라면, 
mod_python 에서 ``print`` 문은 아무 효과가 없음을 주의 하십시오; 혹시 기대했을지 모를, 
아파치 로그에도 보이지 않습니다. 만약 mod_python 환경에서 
디버깅 정보를 꼭 찍어야 할 필요가 있다면, 이렇게 하십시오::
<<!!

>>!
    assert False, the_value_i_want_to_see
<<!
>>!!
    assert False, 내가 알고 싶은 값
<<!!

>>!
Or add the debugging information to the template of your page.
<<!
>>!!
혹은 디버깅 정보를 여러분 페이지의 템플릿에 추가 하십시오.
<<!!

>>!
.. _mod_python documentation: http://modpython.org/live/current/doc-html/directives.html
<<!
>>!!
.. _mod_python 문서: http://modpython.org/live/current/doc-html/directives.html
<<!!

>>!
Serving media files
<<!
>>!!
미디어 파일 처리하기
<<!!
===================

>>!
Django doesn't serve media files itself; it leaves that job to whichever Web
server you choose.
<<!
>>!!
장고 자체는 미디어 파일들을 처리하지 않습니다; 장고는 그 작업을 여러분이 선택한 
웹 서버에게 남깁니다.
<<!!

>>!
We recommend using a separate Web server -- i.e., one that's not also running
Django -- for serving media. Here are some good choices:
<<!
>>!!
우리는 분리된 웹서버 — 바꿔말하면, 장고를 실행하지 않는  — 미디어 처리를 위한 
웹서버를 사용할것을 추천합니다. 여기 몇가지 좋은 선택이 있습니다:
<<!!

* lighttpd_
* TUX_
* A stripped-down version of Apache_

>>!
If, however, you have no option but to serve media files on the same Apache
``VirtualHost`` as Django, here's how you can turn off mod_python for a
particular part of the site::
<<!
>>!!
그렇지만, 만약 여러분이 선택의 여지가 없고 
장고가 실행되는 동일 아파치 ``VirtualHost`` 상에서 미디어 파일들을 처리해야 한다면, 
사이트 특정 부분의 mod_python 을 끄는 방법이 있습니다::
<<!!

    <Location "/media">
        SetHandler None
    </Location>

>>!
Just change ``Location`` to the root URL of your media files. You can also use
``<LocationMatch>`` to match a regular expression.
<<!
>>!!
바로 ``Location``을 미디어 파일들의 루트 URL로 변경하십시오. 
여러분은 정규 표현식으로 매치하기 위해 ``<LocationMatch>``를 사용할 수도 있습니다.
<<!!

>>!
This example sets up Django at the site root but explicitly disables Django for
the ``media`` subdirectory and any URL that ends with ``.jpg``, ``.gif`` or
``.png``::
<<!
>>!!
이 예는 사이트 루트에 장고를 설정하지만 ``media`` 서브디렉토리와 
``.jpg``, ``.gif`` 또는 ``.png``로 끝나는 URL은 장고를 불가능하게 하는 
설정을 합니다::
<<!!

    <Location "/">
        SetHandler python-program
        PythonHandler django.core.handlers.modpython
        SetEnv DJANGO_SETTINGS_MODULE mysite.settings
    </Location>

    <Location "/media">
        SetHandler None
    </Location>

    <LocationMatch "\.(jpg|gif|png)$">
        SetHandler None
    </LocationMatch>


.. _lighttpd: http://www.lighttpd.net/
.. _TUX: http://en.wikipedia.org/wiki/TUX_web_server
.. _Apache: http://httpd.apache.org/

>>!
Serving the admin files
<<!
>>!!
admin 파일들 처리하기
<<!!
=======================

>>!
Note that the Django development server automagically serves admin media files,
but this is not the case when you use any other server arrangement. You're
responsible for setting up Apache, or whichever media server you're using, to
serve the admin files.
<<!
>>!!
장고 개발 서버는 자동으로 admin media 파일들을 처리합니다만, 다른 서버구성을 
사용할 경우는 이에 해당하지 않음을 주의 하십시오. admin 파일들을 처리하기 위해, 
아파치, 또는 여러분이 사용중인 어떠한 미디어 서버에 대한 설정을 
여러분이 해야 합니다.
<<!!

>>!
The admin files live in (``django/contrib/admin/media``) of the Django
distribution.
<<!
>>!!
admin 파일은 장고 배포판의 (``django/contrib/admin/media``) 에 
위치합니다.
<<!!

>>!
Here are two recommended approaches:
<<!
>>!!
여기 두가지 추천 방법이 있습니다:
<<!!

>>!
    1. Create a symbolic link to the admin media files from within your
       document root. This way, all of your Django-related files -- code
       **and** templates -- stay in one place, and you'll still be able to
       ``svn update`` your code to get the latest admin templates, if they
       change.
    2. Or, copy the admin media files so that they live within your Apache
       document root.
<<!
>>!!
    1. 여러분의 document root 내에 admin media 파일들에 대한 심볼릭 링크를 만듭니다. 
       이 경우, 여러분의 모든 장고 관련 파일들 -- 코드 **그리고** 템플릿들 -— 은 
       한 장소에 있게되며, 여러분은 여전히 변경된 최신의 
			 admin 템플릿들을 얻기 위해, 
       ``svn update``를 할 수 있습니다.
    2. 또는, 여러분의 아파치 document root 안에
	 	admin media 파일들을 복사합니다.
<<!!

>>!
Using eggs with mod_python
<<!
>>!!
mod_python에서 eggs 사용하기
<<!!
==========================

>>!
If you installed Django from a Python egg_ or are using eggs in your Django
project, some extra configuration is required. Create an extra file in your
project (or somewhere else) that contains something like the following::
<<!
>>!!
만약 Python egg_에서 장고를 설치했거나 장고 프로젝트에 egg를 사용 중이라면, 
추가 설정이 필요합니다. 여러분의 프로젝트(또는 어딘가에)에 아래와 같은 내용을 포함하는 
별도의 파일을 생성하십시오::
<<!!

    import os
    os.environ['PYTHON_EGG_CACHE'] = '/some/directory'

>>!
Here, ``/some/directory`` is a directory that the Apache webserver process can
write to. It will be used as the location for any unpacking of code the eggs
need to do.
<<!
>>!!
여기, ``/some/directory`` 는 아파치 웹서버 프로세스가 
쓰기를 하는 디렉토리입니다. 
egg가 필요로 하는 코드들의 압축을 푸는 위치로 사용됩니다.
<<!!

>>!
Then you have to tell mod_python to import this file before doing anything
else. This is done using the PythonImport_ directive to mod_python. You need
to ensure that you have specified the ``PythonInterpreter`` directive to
mod_python as described above__ (you need to do this even if you aren't
serving multiple installations in this case). Then add the ``PythonImport``
line in the main server configuration (i.e., outside the ``Location`` or
``VirtualHost`` sections). For example::
<<!
>>!!
그리고나서 여러분은 mod_python에게 다른 무엇보다도 먼저
이 파일을 import 할것을 지시해야 합니다.
이는 mod_python에 PythonImport_ 지시자를 사용하면 됩니다.
여러분은 mod_python에 위__에서 설명한대로
``PythonInterpreter`` 지시자를 
명시해둬야 합니다
(여러분은 이 경우 다중 설치를 사용 하지 않더라도 이것을 해야 합니다). 그리고 나서 ``PythonImport`` 줄을 메인 서버 설정에 추가 하십시오(즉, ``Location`` 또는 ``VirtualHost`` 섹션의 바깥). 예를 들어::
<<!!

    PythonInterpreter my_django
    PythonImport /path/to/my/project/file.py my_django

>>!
Note that you can use an absolute path here (or a normal dotted import path),
as described in the `mod_python manual`_. We use an absolute path in the
above example because if any Python path modifications are required to access
your project, they will not have been done at the time the ``PythonImport``
line is processed.
<<!
>>!!
여러분은 `mod_python 매뉴얼`_에서 설명한 대로 
절대 경로(또는 일반적인 도트 import 경로)를 사용할 수 있습니다. 우리는 여러분의 
프로젝트에 접근 하기 위해 파이썬 path 수정이 필요할 수도 있는데, 
``PythonImport`` 라인이 처리되는 시점에서는 이것이 아직  완료가 되지 않았기 때문에 
위의 예제에서 우리는 절대 경로를 사용했습니다.
<<!!

.. _Egg: http://peak.telecommunity.com/DevCenter/PythonEggs
.. _PythonImport: http://www.modpython.org/live/current/doc-html/dir-other-pimp.html
>>!
.. _mod_python manual: PythonImport_
__ `Multiple Django installations on the same Apache`_
<<!
>>!!
.. _mod_python 매뉴얼: PythonImport_
__ `한 아파치 상에서 장고 다중 설치`_
<<!!

>>!
Error handling
<<!
>>!!
에러 처리
<<!!
==============

>>!
When you use Apache/mod_python, errors will be caught by Django -- in other
words, they won't propagate to the Apache level and won't appear in the Apache
``error_log``.
<<!
>>!!
여러분이 아파치/mod_python을 사용할 때, 에러는 장고에 의해 잡힙니다  -- 다른 말로, 
에러를 아파치 레벨에 전파 하지 않으며, 아파치 ``error_log`` 에도 
나타나지 않습니다.
<<!!

>>!
The exception for this is if something is really wonky in your Django setup. In
that case, you'll see an "Internal Server Error" page in your browser and the
full Python traceback in your Apache ``error_log`` file. The ``error_log``
traceback is spread over multiple lines. (Yes, this is ugly and rather hard to
read, but it's how mod_python does things.)
<<!
>>!!
이에 대한 예외는 여러분의 장고 프로그램에서 무언가 정말 있을 수 없는 일이 
발생한 경우입니다. 이 경우, 여러분은 브라우저에서 "Internal Server Error" 페이지를 
보게 될 것이며 full Python traceback 이 아파치 ``error_log`` 파일에 남겨집니다. 
``error_log`` traceback은 여러줄에 걸쳐 출력됩니다. (예, 이것은 
보기 흉하고 읽기도 어렵습니다만, 이게 mod_python 이 처리하는 방식입니다.)
<<!!

>>!
If you get a segmentation fault
<<!
>>!!
segment fault 가 났다면
<<!!
===============================

>>!
If Apache causes a segmentation fault, there are two probable causes, neither
of which has to do with Django itself.
<<!
>>!!
만약 아파치가 segment fault 를 낸다면, 두가지 예상 원인이 있는데, 
둘다 장고 자체의 문제가 아닙니다. 
<<!!

>>!
    1. It may be because your Python code is importing the "pyexpat" module,
       which may conflict with the version embedded in Apache. For full
       information, see `Expat Causing Apache Crash`_.
    2. It may be because you're running mod_python and mod_php in the same
       Apache instance, with MySQL as your database backend. In some cases,
       this causes a known mod_python issue due to version conflicts in PHP and
       the Python MySQL backend. There's full information in the
       `mod_python FAQ entry`_.
<<!
>>!!
    1. 여러분의 파이썬 코드가 아파치에 임베딩된 버전과 
      충돌나는 "pyexpat" 모듈을 임포팅 하고 있기 때문일 수 있습니다. 
      전체 정보는 `Expat Causing Apache Crash`_ 를 보십시오.
    2. 여러분이 데이터베이스 후단부로 MySQL을 사용하여 mod_python과 mod_php를 
      동일 아파치 인스턴스에서 실행중이기 때문일 수 있습니다. 어떤 경우, 
      이는 PHP와 Python의 MySQL 후단부에서의 버전 충돌에 의한 것으로 알려진 
      mod_python 이슈를 일으킵니다. 
			`mod_python FAQ entry`_에 전체 정보가 있습니다.
<<!!
      
>>!
If you continue to have problems setting up mod_python, a good thing to do is
get a barebones mod_python site working, without the Django framework. This is
an easy way to isolate mod_python-specific problems. `Getting mod_python Working`_
details this procedure.
<<!
>>!!
만약 여러분에게 mod_python 설정 문제가 계속된다면, 
장고 프레임워크 없이, mod_python 기본 사이트가 잘 작동하도록 하십시오. 
이는 mod_python 에 한정된 문제를 고립시키는 쉬운 방법입니다. 
`Getting mod_python Working`_에 이 절차가 자세하게 있습니다.
<<!!

>>!
The next step should be to edit your test code and add an import of any
Django-specific code you're using -- your views, your models, your URLconf,
your RSS configuration, etc. Put these imports in your test handler function
and access your test URL in a browser. If this causes a crash, you've confirmed
it's the importing of Django code that causes the problem. Gradually reduce the
set of imports until it stops crashing, so as to find the specific module that
causes the problem. Drop down further into modules and look into their imports,
as necessary.
<<!
>>!!
다음 단계는 테스트 코드를 열어서 여러분이 사용하는 장고 관련 코드 — 
view, model, URLconf, RSS 설정 따위 등에 대한 모든 import 들을 추가 하십시오. 
이들 import들을 여러분의 테스트 핸들러 함수에 넣고 브라우저에서 
여러분의 테스트 URL에 접속하십시오. 만약 이것이 문제를 발생시킨다면, 
import 한 장고 코드들이 문제를 일으키는 것임이 확인된 것입니다. 크래시가 
멈출때까지 import 를 점차적으로 줄여나가서, 문제를 말생시키는 
특정 모듈을 찾습니다. 필요하다면 해당 모듈 안으로 더 들어가 
그 곳의 import 들을 조사합니다.
<<!!

.. _Expat Causing Apache Crash: http://www.dscpl.com.au/articles/modpython-006.html
.. _mod_python FAQ entry: http://modpython.org/FAQ/faqw.py?req=show&file=faq02.013.htp
.. _Getting mod_python Working: http://www.dscpl.com.au/articles/modpython-001.html
Last modified 6 years ago Last modified on 04/06/08 21:52:35