Look at buildout for doing reproducible builds.
> Would you recommend creating a system user for the django project and use
> daemon mode?
Both are good ideas.
> What type of user and what privileges does it need?
Normal user. If by privileges you mean what file system access, that
is going to depend on what your application needs to access.
At least the WSGI script file and the directories down to that
location must be accessible to Apache user. All other files need only
be accessible to the user that daemon mode process runs as.
> Can I set ORACLE_HOME, LD_LIBRARY_PATH, PATH=$ORACLE_HOME/bin:$PATH for this
> user?
Doing that would have no effect as Apache doesn't inherit them.
Ideally the .so for cx_Oracle would be built such that LD_RUN_PATH was
used to embed the library directory into the .so so that
LD_LIBRARY_PATH not needed at run time. The ORACLE_HOME then need only
be set in WSGI script file. If that isn't possible, LD_LIBRARY_PATH
may need to be set in Apache envvars file, same directory as Apache
executable. If you Linux distribution doesn't have that file, then
needs to be set in Apache startup scripts. This is assuming the Oracle
libraries not in standard library search directories for system.
> Would you use a virtualenv for cx_Oracle?
Always a good idea to use virtualenv if don't want to trust what is in
system Python site-packages. See:
http://code.google.com/p/modwsgi/wiki/VirtualEnvironments
> Can I somehow put the python2.6 inside the virtualenv so it will portable to
> other servers?
No. A virtualenv references an separate Python installation, cannot contain one.
You can use buildout however to automatically install a Python
installation just for your application setup. Apache is though bound
to that Python via mod_wsgi, so maybe buildout should install your
Apache and any other required bits as well.
Graham
Ideally the .so for cx_Oracle would be built such that LD_RUN_PATH was
used to embed the library directory into the .so so that
LD_LIBRARY_PATH not needed at run time.
The ORACLE_HOME then need only
be set in WSGI script file.
If that isn't possible, LD_LIBRARY_PATH
may need to be set in Apache envvars file, same directory as Apache
executable. If you Linux distribution doesn't have that file, then
needs to be set in Apache startup scripts. This is assuming the Oracle
libraries not in standard library search directories for system.
--
You received this message because you are subscribed to the Google Groups "modwsgi" group.
To post to this group, send email to mod...@googlegroups.com.
To unsubscribe from this group, send email to modwsgi+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/modwsgi?hl=en.
Looks to be right syntax.
> How do I use LD_LIBRARY_PATH so it'll be embedded in the .so?
> $ export LD_RUN_PATH=/usr/lib/oracle/11.2/client/lib
> $ python setup.py build
> $ python setup.py install
That is what LD_RUN_PATH is for.
The difference is that LD_LIBRARY_PATH is used at run time when
invoking a program. The LD_RUN_PATH is used by linker at compile time
to embed that path in the application and/or .so file such that
LD_LIBRARY_PATH isn't needed at run time.
Did you make sure you removed the 'build' directory before building it
again in case old files still there and so didn't actually get
rebuilt?
So long as you don't have LD_LIBRARY_PATH set at the time, you can use
the 'ldd' command to list library dependencies of a .so file and see
which library directories they resolve to and whether found or not.
You can therefore use that to validate the compilation occurred
correctly and LD_RUN_PATH was used.
I believe that on a Linux box you can also use:
objdump -p blah.so
to dump out what the RPATH encoded into a .so file is as well.
>> The ORACLE_HOME then need only
>> be set in WSGI script file.
>
> Do you mean using os.environ inside my django project .wsgi file?
> does it matter where in the django.wsgi script I'm putting it?
> os.environ["ORACLE_HOME"] = "/usr/lib/oracle/11.2/client"
Before your import any modules that may cause Oracle Python wrappers
to be imported.
Graham