On Feb 17, 2:37 pm, Jd <[email protected]> wrote: > Nope.. that does not work. > I am familiar with Apache, modules.. in general and to some level > inner working. If you tell me a bit more about how it works.. I can > try to dig some more. > > * the wsgi script needs to be owned by apache user right ?
No. The directories down to the WSGI script file have to be searchable by Apache user. Having at least o+x for permissions on directories is generally enough so long as you are happy with any user accessing directories. You only technically need o+rx, ie., 'r' as well, if you have configured Apache in such a way that you want to use Apache's support for generating directory listings. If using WSGIScriptAlias, you wouldn't, so at least o+x on directories is sufficient. This just ensures that another user, ie., Apache user, can actually stat the file. If using embedded mode or daemon mode and it is running as Apache user, the WSGI script file must be readable by Apache user. This is because that user is executing code for Python interpreter and so needs to be able to read it. Same goes for any other files your application uses. If using daemon mode and running as special user, only that special user has to be able to read the WSGI script file, ie., would have to be group readable or writable. Whatever it is, it doesn't matter who it is owned by, only matters who can read it. > * The conf file that goes under the conf.d also needs to be owned by > apache user. No. That file is read when Apache is running as root so really doesn't matter. You would not though want to make it owned by Apache user however, as that means any web application code, also running as Apache user could modify it and change your Apache configuration. > * What about tg2env directory ? > * What about application directory ? Doesn't matter who it is owned by, only matters who can access directories and read files. I don't know if application directory has special requirements. If it needs to be writable by application, then it will. > * Any other assumptions.. about path..etc. You didn't address the point in my email as to whether you have any special environment variables defined in the user environment when doing stuff from command line. When run under Apache/mod_wsgi, it does not inherit the user environment. Thus if you have PYTHONPATH, PYTHONHOME, PYTHONEXECUTBLE, PYTHON_EGG_CACHE or other special environment variables related to Python set and running from command line was dependent on that, things may not work under Apache. Other things that can screw things up is if you fiddled things to create a writable Python egg cache in home directory for the Apache user and it has out of date code in it. > * Any clue why the sys.path printed shows paste.. but the app fails.. > any other way to debug this ? > ----------- Well, have you actually put TG aside and gone back to a hello world WSGI program, making sure that works, and then try and point it at a virtual environment per instructions at: http://code.google.com/p/modwsgi/wiki/VirtualEnvironments Install Paste/PasteDeploy in that virtual environment and then add a single 'import' line for paste.deploy in the WSGI script file, to validate that at least works. In other words, take it back to the simplest setup you can and validate it works first. Graham > I have a setup that works as a non-root user. > The tg2env and the application both are under this user. and > everything works fine. > > Now, > a. What I tried was to copy this and change ownership to apache. I did > modify the .pth file and fixed the path specific to the app. This is > getting in to the problems that I have put details in the pastebin. > > There are two other options > b. Setup so that global apache .. points to the working environment. > (There were more chances of user permission problem... hence I chose > to go with a. > > c. Setup up private apache (as non-root) user and then try to wire > this up. > > Has anyone tried these.. or any of the option look better? > > Thanks in advance > /Jd > > On Feb 15, 3:16 pm, Graham Dumpleton <[email protected]> > wrote: > > > > > Try changing options to WSGIDaemonProcess from: > > > user=apache group=apache > > > to user/group for your own account from which you were doing command > > line validation that everything was okay. > > > If this works, it shows it is potentially a permissions problem for > > the Apache user. > > > If it doesn't work, then it is the paths setup in WSGI script file or > > when doing stuff from own account it perhaps works because of > > inheriting PYTHONPATH or some other Python environment variable from > > user environment. > > > Graham > > > On Feb 15, 9:36 am, Jd <[email protected]> wrote: > > > > Un-commenting the reordering section did not help. > > > > Any other pointers. > > > Note : The sys.path printed seems correct... contains the Paste stuff. > > > > /Jd > > > > On Feb 11, 9:28 pm, Graham Dumpleton <[email protected]> > > > wrote: > > > > > On Feb 12, 2:07 pm, Lukasz Szybalski <[email protected]> wrote: > > > > > > On Thu, Feb 11, 2010 at 8:02 PM, Graham Dumpleton > > > > > > <[email protected]> wrote: > > > > > > > On Feb 12, 11:18 am, Lukasz Szybalski <[email protected]> wrote: > > > > > >> On Thu, Feb 11, 2010 at 6:10 PM, Jd <[email protected]> wrote: > > > > > >> > After spending lot of hours and making progress through number of > > > > > >> > errors... I am stuck.. and need some help. > > > > > > >> > The error I am getting is. > > > > > > >> >http://pastebin.com/f74f5c15e > > > > > > >> > Here is my apache conf file. > > > > > > >> >http://pastebin.com/m56ca2a55 > > > > > > >> > Here is wsgi script. > > > > > > >> >http://pastebin.com/m27cdd87e > > > > > > >> > Any help is appreciated. > > > > > >> > Thanks > > > > > > >> Try uncommenting the above code that is in your config code. > > > > > >> Lucas > > > > > > >> # > > > > > >> #Move just added item to the front of the python system path. > > > > > >> # > > > > > >> #Not needed if modwsgi>=3.0. Uncomment next 6 lines. > > > > > >> # > > > > > >> ###new_sys_path = [] > > > > > >> # > > > > > >> ###for item in list(sys.path): > > > > > >> # > > > > > >> ### if item not in prev_sys_path: > > > > > >> # > > > > > >> ### new_sys_path.append(item) > > > > > >> # > > > > > >> ### sys.path.remove(item) > > > > > >> # > > > > > >> ###sys.path[:0] = new_sys_path > > > > > > > That code is indeed still needed if using mod_wsgi 3.0. > > > > > > > The reordering of sys.path from mod_wsgi 2.4 onwards only relates to > > > > > > when WSGIPythonPath directive or 'python-path' option for > > > > > > WSGIDaemonProcess are used and not where sys.path is being > > > > > > explicitly > > > > > > updated in WSGI script file using site.addsitedir(). > > > > > > > If the above is from some template somewhere in generated script > > > > > > file > > > > > > or documentation, it should be changed as the comment is plain > > > > > > wrong. > > > > > > Which comment is wrong? Is it the "Not needed if modwsgi>=3.0" or? > > > > > Correct, just the comment: > > > > > "Not needed if modwsgi>=3.0" > > > > > is wrong. > > > > > That reordering code is always needed regardless of mod_wsgi version > > > > when using site.addsitedir() to update sys.path, so that section of > > > > code should never be commented out. > > > > > Graham -- You received this message because you are subscribed to the Google Groups "TurboGears" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/turbogears?hl=en.
