[Trac] Re: - Slow configuration using mod_wsgi
On Aug 6, 9:29 am, Josh Godsiff j...@oxideinteractive.com.au wrote: On 6/8/2010 9:23 AM, mark ardiente wrote: Hi, [snip] Regrads, Mark Try setting it up so that static files are served up by Apache, instead of having to go through a whole Trac request. It might not solve your issues, but it certainly results in /some/ speed improvements. It can be done relatively easily using the trac-admin 'deploy' command an Apache's 'AliasMatch' directive. Not sure about using AliasMatch. Procedure should be same as for CGI as documented in: http://trac.edgewall.org/wiki/TracCgi#MappingStaticResources Ie., believe it should only need Alias directive. Overall I would be concerned about SQLlite being used over better database such as PostgreSQL. Graham -- You received this message because you are subscribed to the Google Groups Trac Users group. To post to this group, send email to trac-us...@googlegroups.com. To unsubscribe from this group, send email to trac-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/trac-users?hl=en.
[Trac] Re: mod_wsgi - Apache processes an unlimited increase
On Jul 28, 11:12 pm, Agustin Henze t...@sluc.org.ar wrote: El mar, 27-07-2010 a las 16:03 -0700, Graham Dumpleton escribió: Please better define 'apache proccesses an unlimited increase'. Apache processes start to grow without limits[0]. Okay, so the number of processes grows, rather than the amount of memory used by a process. That is what I wanted to clarify. The configuration of the VH is: WSGIDaemonProcess trac user=www-data group=www-data processes=1 threads=1 maximum-requests=1000 display-name=wsgi-trac Do you have WSGIProcessGroup and WSGIApplicationGroup directives in your configuration as well? Post the more complete configuration. As is, your graph suggests classic problem of running stuff in embedded mode with prefork MPM. That is, chance you aren't delegating Trac to daemon process group properly. See: http://blog.dscpl.com.au/2009/03/load-spikes-and-excessive-memory-usage.html Even if daemon mode used, your use of a single process with single thread is a bad idea. This is because you can only handle one request at a time. If for some reason a request blocks or takes a really long time, then no other requests can be handled at the same time. What will happen then if using prefork MPM is that Apache will create more and more Apache server child processes to accept the pending requests, but they will all block waiting to be able to proxy to daemon process. Since for prefork MPM the default is 150 processes, you can see as many as that number of processes created as requests arrive. As such, if any extensions are thread safe (Trac core is already), then you should run more than a single thread. If code is still blocking or taking a long time, those additional threads will still be able to handle requests. If those all threads get stuck in same way, then still can have same issue. if you are not using PHP, you should also change to worker MPM. BTW, what version of mod_wsgi are you using? Graham Before the actualization from 0.11.7 to 0.12, works with the same configuration and didn't happen. I can't reproduce the error and doesn't happen very often. But the problem is that when it happens, trac is out of service. [0]http://www.imageno.com/w5wxdsofudqbpic.html -- TiN signature.asc 1KViewDownload -- You received this message because you are subscribed to the Google Groups Trac Users group. To post to this group, send email to trac-us...@googlegroups.com. To unsubscribe from this group, send email to trac-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/trac-users?hl=en.
[Trac] Re: Trac performance - 200K+ tickets
On Jul 14, 3:11 am, Lukasz Szybalski szybal...@gmail.com wrote: On Jul 13, 11:53 am, Noah Kantrowitz n...@coderanger.net wrote: Might help if you gave the full command line, stack trace, etc etc. The screen is from a top command, trac is installed via modwsgi with apache2. In which case the Trac instances themselves would show as 'apache' or 'httpd'. If using daemon mode you could use display-name option to WSGIDaemonProcess to override name of process and then 'ps' and 'htop' (but not 'top' AFAIK) will show that new name. Thus you can be more confident of which are the Trac processes. 'Top' command gives me below pid, how can I find out what program is the pid running? It seem like each process is calling some python code that then takes a lot of cpu to run, but I'm not sure where to go from here. Look in the /proc file system for directory corresponding to the process ID. There are various files in there including some which show process environment, command line etc etc. That presumes your UNIX variant has /proc file system. Also look at parent child PID relationships using 'ps' and see if these are a process spawned off the Trac processes for some reason. Graham --Noah On Jul 13, 2010, at 9:50 AM, Lukasz Szybalski wrote: Hello, Would anybody be able to help me figure out what are these python processes, are they part of trac, and what exactly they are doing taking over 60% of my cpu? Thanks, Lucas Tasks: 131 total, 13 running, 118 sleeping, 0 stopped, 0 zombie Cpu(s): 60.1%us, 13.1%sy, 0.7%ni, 26.1%id, 0.0%wa, 0.0%hi, 0.1%si, 0.0%st Mem: 1535568k total, 1413748k used, 121820k free, 45180k buffers Swap: 1466360k total, 68k used, 1466292k free, 520472k cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 27335 unique 20 0 51936 20m 1740 R 20 1.4 0:00.12 python 27330 unique 20 0 51420 20m 1740 R 16 1.3 0:00.24 python 27337 unique 20 0 46384 15m 1740 R 16 1.0 0:00.10 python 27326 unique 20 0 35032 4424 1740 R 13 0.3 0:00.24 python 27329 unique 20 0 51936 20m 1740 R 13 1.4 0:00.22 python 27331 unique 20 0 51936 20m 1740 R 13 1.4 0:00.14 python 27332 unique 20 0 51936 20m 1740 R 13 1.4 0:00.16 python 27333 unique 20 0 51936 20m 1740 R 13 1.4 0:00.16 python 27338 unique 20 0 44352 13m 1740 R 13 0.9 0:00.08 python 27336 unique 20 0 40620 9740 1740 R 10 0.6 0:00.06 python 27339 unique 20 0 32920 4156 1720 R 7 0.3 0:00.04 python -- You received this message because you are subscribed to the Google Groups Trac Users group. To post to this group, send email to trac-us...@googlegroups.com. To unsubscribe from this group, send email to trac-users+unsubscr...@googlegroups.com . For more options, visit this group athttp://groups.google.com/group/trac-users?hl=en . -- You received this message because you are subscribed to the Google Groups Trac Users group. To post to this group, send email to trac-us...@googlegroups.com. To unsubscribe from this group, send email to trac-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/trac-users?hl=en.
[Trac] Re: Trac performance - 200K+ tickets
On Jul 14, 7:38 am, Lukasz Szybalski szybal...@gmail.com wrote: On Jul 13, 3:51 pm, Graham Dumpleton graham.dumple...@gmail.com wrote: On Jul 14, 3:11 am, Lukasz Szybalski szybal...@gmail.com wrote: On Jul 13, 11:53 am, Noah Kantrowitz n...@coderanger.net wrote: Might help if you gave the full command line, stack trace, etc etc. The screen is from a top command, trac is installed via modwsgi with apache2. In which case the Trac instances themselves would show as 'apache' or 'httpd'. If using daemon mode you could use display-name option to WSGIDaemonProcess to override name of process and then 'ps' and 'htop' (but not 'top' AFAIK) will show that new name. Thus you can be more confident of which are the Trac processes. 'Top' command gives me below pid, how can I find out what program is the pid running? It seem like each process is calling some python code that then takes a lot of cpu to run, but I'm not sure where to go from here. Look in the /proc file system for directory corresponding to the process ID. There are various files in there including some which show process environment, command line etc etc. That presumes your UNIX variant has /proc file system. Also look at parent child PID relationships using 'ps' and see if these are a process spawned off the Trac processes for some reason. ok. So if this was started from modwsgi as part of trac apache2 installation the process user would be www-data in my case. ? Correct? Actually, I wasn't thinking of the user the process runs as but the process name itself. That is, mod_wsgi process don't show as 'python'. But yes, if you haven't overridden the user that Trac runs as using 'user' option to WSGIDaemonProcess, then it would be running as Apache user and so would any processes spawned from them. Since the user name is different this might be some other process (import2trac, conversion programs that I use to import tickets in) which are run by that users cron. Sounds like a more logical cause. Graham I'll look into this deeper tomorrow. Thanks, Lucas -- You received this message because you are subscribed to the Google Groups Trac Users group. To post to this group, send email to trac-us...@googlegroups.com. To unsubscribe from this group, send email to trac-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/trac-users?hl=en.
[Trac] Re: ImportError: No module named trac
On Jun 29, 1:50 am, Noah Kantrowitz n...@coderanger.net wrote: 1) mod_python is a deprecated deployment option. The project has been mothballed by its creators in favor ofmod_wsgi. You should really switch to a new deployment option (probablymod_wsgi). It isn't really true to say that mod_python was mothballed in favour of mod_wsgi. The mod_wsgi package is certainly an alternative, but mod_python was mothballed because no one was interested in working on mod_python. :-) Graham 2) You probably need a PythonPath in there which indicates where the Trac code is installed. PythonPath ['/path/to/site-packages'] + sys.path --Noah On Jun 27, 2010, at 1:01 PM, Fernando N Filho wrote: Hello there, I recently tried to upgrade my Trac Version from 0.11 to 0.12. But I now receive the following error onhttp://trac.potterish.com/: Mod_python error: PythonHandler trac.web.modpython_frontend Traceback (most recent call last): File /usr/lib64/python2.4/site-packages/mod_python/apache.py, line 287, in HandlerDispatch log=debug) File /usr/lib64/python2.4/site-packages/mod_python/apache.py, line 461, in import_module f, p, d = imp.find_module(parts[i], path) ImportError: No module named trac My .htaccess is configured the following way: SetHandler mod_python PythonInterpreter main_interpreter PythonHandler trac.web.modpython_frontend PythonOption PYTHON_EGG_CACHE /var/www/vhosts/potterish.com/ subdomains/trac/httpdocs/editores/db PythonOption TracEnvParentDir /var/www/vhosts/potterish.com/ subdomains/trac/httpdocs PythonOption TracUriRoot / PythonDebug on I looked on the Trac website and saw this had something to do with the Apache Path, but don't know how to fix it, does anybody have an idea of whats going on? Thanks! -- You received this message because you are subscribed to the Google Groups Trac Users group. To post to this group, send email to trac-us...@googlegroups.com. To unsubscribe from this group, send email to trac-users+unsubscr...@googlegroups.com . For more options, visit this group athttp://groups.google.com/group/trac-users?hl=en . -- You received this message because you are subscribed to the Google Groups Trac Users group. To post to this group, send email to trac-us...@googlegroups.com. To unsubscribe from this group, send email to trac-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/trac-users?hl=en.
[Trac] Re: How To: Have Apache Load a VirtualEnv for Trac
On Jun 23, 3:48 am, Chris ch...@reemergemedia.com wrote:
On Jun 10, 9:45 pm, Graham Dumpleton graham.dumple...@gmail.com
wrote:
Try using mod_wsgi instead. Much easier to set up for virtual
environments. See:
http://code.google.com/p/modwsgi/wiki/IntegrationWithTrac
http://code.google.com/p/modwsgi/wiki/VirtualEnvironments
Graham
Graham
I was able to get both Trac 0.11.7 and Trac 0.12 running, but, 0.11 is
using mod_python and 0.12 is using mod_wsgi. I'm on Windows and
couldn't get WSGIDaemonProcess to work because as you know, it doesn't
work. I had this configuration using mod_wsgi but when accessing the
Trac 0.11 sites I was informed to upgrade their Trac database.
WSGIScriptAlias /trac12 F:/virtualenvs/trac12/Scripts/trac12.wsgi
Location /trac12
WSGIApplicationGroup %{GLOBAL}
Order deny,allow
Allow from all
/Location
WSGIScriptAlias /trac11 F:/virtualenvs/trac11/Scripts/trac11.wsgi
Location /trac11
WSGIApplicationGroup %{GLOBAL}
Order deny,allow
Allow from all
/Location
You cant mix different virtual environments in same Python interpreter
(mod_wsgi application group). If you are using third party C extension
modules that only work in main Python interpreter, eg, subversion
bindings, then on Windows you are out of luck as you would in that
case have no choice but to use daemon mode, which as you know is only
available on UNIX with Apache 2.X.
Graham
--
You received this message because you are subscribed to the Google Groups Trac
Users group.
To post to this group, send email to trac-us...@googlegroups.com.
To unsubscribe from this group, send email to
trac-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/trac-users?hl=en.
[Trac] Re: How To: Have Apache Load a VirtualEnv for Trac
Try using mod_wsgi instead. Much easier to set up for virtual
environments. See:
http://code.google.com/p/modwsgi/wiki/IntegrationWithTrac
http://code.google.com/p/modwsgi/wiki/VirtualEnvironments
Graham
On Jun 11, 12:19 am, Chris ch...@reemergemedia.com wrote:
Apparently RTFM'ing isn't helping and there's more to it than what's
stated in Trac's Alternative Frontends post (http://trac.edgewall.org/
wiki/TracDev/AlternativeFrontends). In Apache I'm using the PythonPath
directive.
PythonPath ['F:/PythonConfig/t12/Scripts'] + sys.path
Removing sys.path produces a 500 internal server error. So I went
through the Apache error log and pulled what seems to be the locations
Python is being referenced to and replaced them as such, but am
receiving the below error now.
PythonPath ['F:/PythonConfig/t12/Scripts','F:/PythonConfig/t12/
Lib','F:/PythonConfig/t12/Lib/site-packages','C:/WINDOWS/system32/
python25.zip','C:/Program Files/Python25/DLLs','C:/Program Files/
Apache Software Foundation/Apache2.2/bin']
---
[Thu Jun 10 09:53:26 2010] [error] mod_python (pid=6072,
interpreter='server2.com', phase='PythonHandler', handler='v12'):
Application error
[Thu Jun 10 09:53:26 2010] [error] ServerName: 'server2.com'
[Thu Jun 10 09:53:26 2010] [error] DocumentRoot: 'C:/Program Files/
Apache Software Foundation/Apache2.2/htdocs'
[Thu Jun 10 09:53:26 2010] [error] URI: '/t12/'
[Thu Jun 10 09:53:26 2010] [error] Location: '/t12'
[Thu Jun 10 09:53:26 2010] [error] Directory: None
[Thu Jun 10 09:53:26 2010] [error] Filename: 'C:/Program Files/Apache
Software Foundation/Apache2.2/htdocs/t1000'
[Thu Jun 10 09:53:26 2010] [error] PathInfo: '/'
[Thu Jun 10 09:53:26 2010] [error] Traceback (most recent call last):
[Thu Jun 10 09:53:26 2010] [error] File C:\\Program Files\\Python25\
\lib\\site-packages\\mod_python\\importer.py, line 1537, in
HandlerDispatch\n default=default_handler, arg=req,
silent=hlist.silent)
[Thu Jun 10 09:53:26 2010] [error] File C:\\Program Files\\Python25\
\lib\\site-packages\\mod_python\\importer.py, line 1202, in
_process_target\n module = import_module(module_name, path=path)
[Thu Jun 10 09:53:26 2010] [error] File C:\\Program Files\\Python25\
\lib\\site-packages\\mod_python\\importer.py, line 304, in
import_module\n return __import__(module_name, {}, {}, ['*'])
[Thu Jun 10 09:53:26 2010] [error] File F:/PythonConfig/t12/Scripts\
\v12.py, line 8, in module\n from trac.web.modpython_frontend
import handler
[Thu Jun 10 09:53:26 2010] [error] ImportError: No module named
trac.web.modpython_frontend
--
You received this message because you are subscribed to the Google Groups Trac
Users group.
To post to this group, send email to trac-us...@googlegroups.com.
To unsubscribe from this group, send email to
trac-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/trac-users?hl=en.
[Trac] Re: mod_python vs. wsgi
On Feb 18, 6:29 pm, Roger Oberholtzer roger.oberholt...@gmail.com wrote: On Wed, 2010-02-17 at 14:40 -0800, Graham Dumpleton wrote: Have you read: http://code.google.com/p/modwsgi/wiki/IntegrationWithTrac I have read it now. Thanks for the pointer. It will help. Of course, mod_python is currently working great. I understand that it is no longer maintained. But, as they say, if it ain't broken... You do know that mod_python leaks memory in parent Apache process. If you do a large number of Apache restarts (not stop/start), all the Apache processes will gradually grow in memory size. The mod_python has various other bugs in it as well, but in the main most people wouldn't notice or encounter them. If you do change to mod_wsgi, ensure you disable mod_python from the Apache installation because mod_python will keep causing this memory problem even if not actually used. Whether you use mod_python or mod_wsgi embedded mode, just make sure you don't use Apache prefork MPM. See: http://blog.dscpl.com.au/2009/03/load-spikes-and-excessive-memory-usage.html Graham -- You received this message because you are subscribed to the Google Groups Trac Users group. To post to this group, send email to trac-us...@googlegroups.com. To unsubscribe from this group, send email to trac-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/trac-users?hl=en.
[Trac] Re: mod_python vs. wsgi
Have you read: http://code.google.com/p/modwsgi/wiki/IntegrationWithTrac Graham On Feb 17, 8:57 pm, Roger Oberholtzer roger.oberholt...@gmail.com wrote: On Tue, 2010-02-16 at 15:32 -0800, Graham Dumpleton wrote: On Feb 17, 7:23 am, Mariano Absatz el.b...@gmail.com wrote: Hi there, if I'm to install 0.11 on an apache server, which is the recommended method? mod_python or wsgi? The mod_python package hasn't seen any active development in a few years. It has various known issues and problems which are unlikely to be fixed, the worst being memory leaks. It has undesirable behaviour for large Python web applications when you can only use prefork MPM with Apache. Even if using worker MPM with Apache you need to be careful. On this latter issue, have a read of: http://blog.dscpl.com.au/2009/03/load-spikes-and-excessive-memory-usa... Is there a performance advantage for one or another? The mod_wsgi package has lower memory overhead and performs better. http://code.google.com/p/modwsgi/wiki/PerformanceEstimates In general the preferred method for hosting is now mod_wsgi. Now some will say I am biased having written mod_wsgi, but I also worked on mod_python for a while as well, so understand both very well. :-) Is there a migration document for converting from mod_python to mod_wsgi? For example, if I have a trac configured like this for mod_python, what would the equivalent be for mod_wsgi? Location /MyTrac SetHandler mod_python PythonInterpreter main_interpreter PythonHandler trac.web.modpython_frontend PythonOption TracEnv /vol1/trac/MyTrac PythonOption TracUriRoot /MyTrac AuthType Basic AuthName RSofT AuthUserFile /vol1/trac/access/MyTrac/.htpasswd Require valid-user /Location -- Roger Oberholtzer OPQ Systems / Ramböll RST Ramböll Sverige AB Krukmakargatan 21 P.O. Box 17009 SE-104 62 Stockholm, Sweden Office: Int +46 10-615 60 20 Mobile: Int +46 70-815 1696 -- Roger Oberholtzer -- You received this message because you are subscribed to the Google Groups Trac Users group. To post to this group, send email to trac-us...@googlegroups.com. To unsubscribe from this group, send email to trac-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/trac-users?hl=en.
[Trac] Re: mod_python vs. wsgi
On Feb 17, 7:23 am, Mariano Absatz el.b...@gmail.com wrote: Hi there, if I'm to install 0.11 on an apache server, which is the recommended method? mod_python or wsgi? The mod_python package hasn't seen any active development in a few years. It has various known issues and problems which are unlikely to be fixed, the worst being memory leaks. It has undesirable behaviour for large Python web applications when you can only use prefork MPM with Apache. Even if using worker MPM with Apache you need to be careful. On this latter issue, have a read of: http://blog.dscpl.com.au/2009/03/load-spikes-and-excessive-memory-usage.html Is there a performance advantage for one or another? The mod_wsgi package has lower memory overhead and performs better. http://code.google.com/p/modwsgi/wiki/PerformanceEstimates In general the preferred method for hosting is now mod_wsgi. Now some will say I am biased having written mod_wsgi, but I also worked on mod_python for a while as well, so understand both very well. :-) Graham -- You received this message because you are subscribed to the Google Groups Trac Users group. To post to this group, send email to trac-us...@googlegroups.com. To unsubscribe from this group, send email to trac-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/trac-users?hl=en.
[Trac] Re: Error 500 when trying to run Trac on Apache with mod_python.
If you must use mod_python, then use an up to date version. Version 3.2.8 is old, broken and may not work with modern Python web packages which expect you to be using version 3.3.X. Better still use mod_wsgi. Graham On Jan 21, 10:24 am, Fork ti.vel...@gmail.com wrote: I am very very new to this. I am trying to configure Trac 0.11 to run on Apache 2.2.3 on CentOS 5.4 with mod_python 3.2.8 using PostgreSQL 8.1 and SVN (path is /srv/ svn/test). I've managed to create a trac environment on /srv/trac/testTrac. All good. it runs with tracd. My problem now lies with Apache and mod_python, I am not sure how to configure them correctly. I have managed to change the document root in apache to /srv. I have added the following to the end of the httpd.conf file. Location /trac SetHandler mod_python PythonInterpreter main_interpreter PythonHandler trac.web.modpython_frontend PythonOption TracEnv /srv/trac/testeTrac/ PythonOption TracUriRoot /trac /Location But all i get by browsing to localhost/trac is a 500 error. Can someone help me? -- You received this message because you are subscribed to the Google Groups Trac Users group. To post to this group, send email to trac-us...@googlegroups.com. To unsubscribe from this group, send email to trac-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/trac-users?hl=en.
[Trac] Re: mod_wsgi + multiple projects - works well, but unclear about a few things
On Nov 3, 12:48 am, Bartosz Broda bartosz.br...@gmail.com wrote:
I looked there, but the only relevant thing I found concerning
multiple instances of Trac was to run all of the instances in one
python interpreter. But to tell the truth I didn't have enough time to
read modwsgi wiki in depth :(
Huh, it actually talks about it being preferable to use daemon mode
and run different Trac instances in their own process groups for
various reasons. That is, the opposite of what you are talking about.
Sorry, I was trying to set up the Trac as fast as possible, because
other matters were more important at the moment :(.
It is certainly a bad idea to to run multiple Trac instances in same
interpreter where not the same code base, different versions of
plugins, or dependent modules or where need distinct Python egg cache
directories for projects. Also should be avoided if relying on
os.environ for setting Trac location.
Only one thing is different among the configurations: a svn
repository. Probably that caused all the problems...
Different subversion repositories I don't think would be the issue.
Normally Trac would handle that fine.
Looking at your configuration again, the mistake is that you are
using:
WSGIScriptAlias /trac/PROJECT /var/trac/PROJECT/eggs/cgi-bin/
trac.wsgi
Directory /var/trac/PROJECT/htdocs
WSGIApplicationGroup %{GLOBAL}
Order deny,allow
Allow from all
/Directory
There are two issues with this.
The first is that the WSGIApplicationGroup directive isn't being used
in the first place so you aren't even using the main interpreter and
thus will definitely have Python subversion wrappers breaking
unpredictably. It would also have caused a separate copy in memory for
each Trac, using much more memory and bloating out Apache sizes. This
could cause whole system to slow down.
The reason it isn't being used is because the path for Directory
doesn't match where the WSGI script file is. It should have been:
WSGIScriptAlias /trac/PROJECT /var/trac/PROJECT/eggs/cgi-bin/
trac.wsgi
Directory /var/trac/PROJECT/eggs/cgi-bin
WSGIApplicationGroup %{GLOBAL}
Order deny,allow
Allow from all
/Directory
Note that have changed path for Directory directive.
The second issue is how Apache is even able to serve up the WSGI file
from that location given that there is no Allow directive for that
directory because of Directory not matching. Looks like the security
of your Apache installation is lax in some other area in allowing
access to parts of the file system it shouldn't without being
specific.
The Python egg cache is a particular problem in your code as you
change it on every request and that could screw up badly on a
multithreaded configuration.
So, that particular auto generated trac.wsgi from trac-admin is
actually a bit dangerous. Normally one should not be setting Python
egg cache directory like that. It should be set once only.
Thanks for pointing that out. I will try to adjust my configuration
accordingly.
I would suggest you use the configuration on mod_wsgi site of:
WSGIDaemonProcess sites user=trac group=trac processes=3 threads=25
python-eggs=/var/trac/eggs
WSGIScriptAlias /trac /var/trac/apache/trac.wsgi
Directory /var/trac/apache
WSGIProcessGroup sites
WSGIApplicationGroup %{GLOBAL}
SetEnv trac.env_parent_dir /var/trac
Order deny,allow
Allow from all
/Directory
That is, a single WSGI script file rather than many. With that single
WSGI script file being in /var/trac/apache.
Also, a single Python eggs directory specifed by python-eggs option to
WSGIDaemonProcess and at /var/trac/eggs.
Make sure eggs directory exists and writable to user that daemon
process runs as or that Apache runs as. Drop the user/group options
and/or set them appropriately depending on what user you want to run
Trac as. If options left off, then will run as Apache user.
Note that have used trac.env_parent_dir method for configuration so
that Trac knows that location is parent directory of many Trac sites.
So, read up in Trac documentation about what that is all about.
Maybe that info should be posted onhttp://trac.edgewall.org/wiki/TracModWSGI
too?
There are more than ample configurations in what is on the mod_wsgi
site.
Do you think that bad performance could be caused by this egg cache
misconfiguration? As I told before - mod_python seems to work way
faster then mod_wsgi.
In summary your problems are:
1. WSGIApplicationGroup was being ignored because Directory path
didn't match where WSGI script file was installed. This would cause
subversion errors.
2. Lax security in Apache to allow WSGI script file in that location
to work without specific Allow directory.
3. Because of (1), separate interpreter used for each Trac and so lots
more memory. Plus you were using embedded mode, so will encounter
problems described in:
http://blog.dscpl.com.au/2009/03/load-spikes-and-excessive-memory-usage.html
That is
[Trac] Re: mod_wsgi + multiple projects - works well, but unclear about a few things
On Oct 30, 6:33 pm, Bartosz Broda bartosz.br...@gmail.com wrote: Hello Graham, I was reporting the problem with instance.__dict__ not accessible in restricted mode inhttp://trac.edgewall.org/ticket/3371#comment:73. I cannot investigate the issue in more details at the moment, as I have a few deadlines approaching. I will try to mirror the configuration in VM environment in next week. If the errors will still occur, then I will be able to provide the vm image for further inspection. Perhaps I did something wrong during the configuration ofmod_wsgifor use with Trac (I followed this guide:http://trac.edgewall.org/wiki/TracModWSGI, but I might have miss some details). So you never looked at the following? http://code.google.com/p/modwsgi/wiki/IntegrationWithTrac PS. In the meantime I can provide some details concerning my configuration - what further info do you need? The Apache configuration related to mod_wsgi would be best starting point. Graham --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Trac Users group. To post to this group, send email to trac-users@googlegroups.com To unsubscribe from this group, send email to trac-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/trac-users?hl=en -~--~~~~--~~--~--~---
[Trac] Re: mod_wsgi + multiple projects - works well, but unclear about a few things
On Oct 29, 7:00 pm, Leho Kraav lkoogliz...@gmail.com wrote:
hi all wsgi gurus
my goal was to get several isolated trac no-site-packages virtualenvs
running under mod_wsgi: 0.11 virtualenv for bunch of live projets,
0.12-dev1 for project dev1 and 0.12-dev2 for project dev2. but i am
somewhat unclear regarding ApplicationGroups and ProcessGroups - some
setup guides did it one way, some the other. so i also seem to have a
mix in my config file. what about having both dev1 and dev2 both in
ApplicationGroup %{SERVER}%, should they be in separate AG, or does
separate PGs take care of that? perhaps someone could tell me if
there's something to be fixed here:
For Trac, due to limitations in Python wrappers for subversion, you
must use:
WSGIApplicationGroup %{GLOBAL}
So, if using subversion you don't have a choice and if need separation
must use daemon process groups instead.
/etc/apache2/modules.d/70_mod_wsgi.conf:
IfDefine WSGI
LoadModule wsgi_module modules/mod_wsgi.so
WSGIDaemonProcess dev1 user=leho group=apache threads=25 python-path=/
secure/trac/virtual-0.12-dev1/lib/python2.5/site-packages:/secure/trac/
virtual-0.12-dev1/bin
WSGIScriptAlias /project/dev1 /secure/trac/virtual-0.12-dev1/bin/
virtual-0.12-dev1.wsgi
Location /projekt/dev1
WSGIReloadMechanism Process
Delete WSGIReloadMechanism directive. This is default for mod_wsgi 2.X
and will not even have choice in mod_wsgi 3.X. You should not be using
mod_wsgi 1.X.
WSGIProcessGroup dev1
WSGIApplicationGroup %{SERVER}
Use:
WSGIApplicationGroup %{GLOBAL}
to avoid subversion issues.
SetEnv trac.locale et_EE.UTF-8
/Location
WSGIDaemonProcess dev2 user=leho group=apache threads=25 python-path=/
secure/trac/virtual-0.12-dev2/lib/python2.5/site-packages:/secure/trac/
virtual-0.12-dev2/bin
WSGIScriptAlias /project/dev2 /secure/trac/virtual-0.12-dev2/bin/
virtual-0.12-dev2.wsgi
Location /projekt/dev2
WSGIReloadMechanism Process
Delete WSGIReloadMechanism directive. This is default for mod_wsgi 2.X
and will not even have choice in mod_wsgi 3.X. You should not be using
mod_wsgi 1.X.
WSGIProcessGroup dev2
WSGIApplicationGroup %{SERVER}
Use:
WSGIApplicationGroup %{GLOBAL}
to avoid subversion issues.
SetEnv trac.locale et_EE.UTF-8
/Location
WSGIScriptAlias /project /secure/trac/virtual-0.11/bin/
virtual-0.11.wsgi
Directory /secure/trac/virtual-0.11/bin
WSGIApplicationGroup %{GLOBAL}
SetEnv trac.locale et_EE.UTF-8
SetEnv trac.env_index_template /secure/home/httpd/htdocs/project/
index.html
/Directory
This one will run in embedded mode. Especially if using prefork MPM,
bad idea to use embedded mode. Better off delegating this one to its
own daemon process group as well.
Graham
/IfDefine
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups Trac
Users group.
To post to this group, send email to trac-users@googlegroups.com
To unsubscribe from this group, send email to
trac-users+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/trac-users?hl=en
-~--~~~~--~~--~--~---
[Trac] Re: mod_wsgi + multiple projects - works well, but unclear about a few things
On Oct 29, 9:20 pm, Christian Boos cb...@neuf.fr wrote:
Hello Graham,
Graham Dumpleton wrote:
On Oct 29, 7:00 pm, Leho Kraav lkoogliz...@gmail.com wrote:
hi all wsgi gurus
my goal was to get several isolated trac no-site-packages virtualenvs
running undermod_wsgi: 0.11 virtualenv for bunch of live projets,
0.12-dev1 for project dev1 and 0.12-dev2 for project dev2. but i am
somewhat unclear regarding ApplicationGroups and ProcessGroups - some
setup guides did it one way, some the other. so i also seem to have a
mix in my config file. what about having both dev1 and dev2 both in
ApplicationGroup %{SERVER}%, should they be in separate AG, or does
separate PGs take care of that? perhaps someone could tell me if
there's something to be fixed here:
For Trac, due to limitations in Python wrappers for subversion, you
must use:
WSGIApplicationGroup %{GLOBAL}
So, if using subversion you don't have a choice and if need separation
must use daemon process groups instead.
Speaking of that, I'm not sure if you've seen that someone recently
reported the instance.__dict__ not accessible in restricted mode issue
withmod_wsgi2.5, despite his use of WSGIApplicationGroup %{GLOBAL}
(seehttp://trac.edgewall.org/ticket/3371#comment:73).
As we don't see the whole configuration he was using, it might be that
the WSGIApplicationGroup directive was wrongly applied. OTOH, he
reported success with a similar setup using mod_python, so it's a bit
troubling. Are you aware of situations where that RuntimeError could
still occur withmod_wsgi2.5 even when WSGIApplicationGroup %{GLOBAL}
is used?
Would need to see their full configuration to be sure. I would suspect
they must have missed something as know of no issues in this area.
The only way to absolutely verify that running in correct interpreter
is to use a WSGI wrapper such as described in:
http://code.google.com/p/modwsgi/wiki/DebuggingTechniques#Tracking_Request_and_Response
to capture values of:
mod_wsgi.process_group
mod_wsgi.application_group
as received by Trac.
If running in main interpreter, then mod_wsgi.application_group will
be an empty string. Ie., this is what %{GLOBAL} equates to.
Graham
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups Trac
Users group.
To post to this group, send email to trac-users@googlegroups.com
To unsubscribe from this group, send email to
trac-users+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/trac-users?hl=en
-~--~~~~--~~--~--~---
[Trac] Re: wsgi 2.6 and multiple projects
Why are you using both os.environ and SetEnv at same time? You
shouldn't do that. Use just SetEnv and make sure you are setting the
correct variables. At the moment you are setting trac.env_parent_dir
for both when you should be using trac.env_path for one in line with
what os.environ variables you were trying to use.
For why you are having problems when using os.environ read:
http://code.google.com/p/modwsgi/wiki/ApplicationIssues#Application_Environment_Variables
where it explicitly mentions Trac as an example of variable leakage.
Also read:
http://code.google.com/p/modwsgi/wiki/IntegrationWithTrac
where it suggests you use separate daemon process groups and not
embedded mode if distinct instances, especially where they may have no
common set of plugins etc. At the moment you are mixing two instances
in one interpreter of process and that may cause other conflicts in
addition to your current problem where plugin sets and dependencies
are different.
Graham
On Oct 27, 9:44 pm, chris henders...@gmail.com wrote:
I am having trouble setting up wgsi with multiple projects.
I have multiple projects underhttp://trac.company.com/ims/trac
(/var/sites/ims/trac/{math,compsci,hr} directories) - so when I browse
tohttp://trac.company.com/ims/trac,
I get a listing of all the projects from where I click on individual
project's trac page or I can browse to the project's page directly
(eg.http://trac.company.com/ims/trac/compsci)
I also have another project under /var/sites/hass/trac (http://
trac.company.com/hass/trac/) so when I browse to that URL I land on
HASS' trac page directly (because there's only one project here)
The issue: when I visithttp://trac.company.com/ims/and
thenhttp://trac.company.com/hass/trac/and then go
back tohttp://trac.company.com/ims/and refresh my browser, I get the
page fromhttp://trac.company.com/hass/trac/. So I must be doing
something wrong.
Here is my configuration details:
/etc/http/conf.d/trac.conf:
WSGIScriptAlias /ims/trac /var/sites/ims/trac/ims.wsgi
Directory /var/sites/ims/trac/
WSGIApplicationGroup %{GLOBAL}
SetEnv trac.env_parent_dir /var/sites/ims/trac/
Order allow,deny
Allow from all
/Directory
WSGIScriptAlias /hass/trac /var/sites/hass/trac/hass.wsgi
Directory /var/sites/hass/trac/
WSGIApplicationGroup %{GLOBAL}
SetEnv trac.env_parent_dir /var/sites/hass/trac/
Order allow,deny
Allow from all
/Directory
/var/sites/ims/trac/ims.wsgi file:
#!/usr/bin/python
import os
os.environ['TRAC_ENV_PARENT_DIR'] = '/var/sites/ims/trac/'
os.environ['PYTHON_EGG_CACHE'] = '/tmp/imseggs/'
import trac.web.main
application = trac.web.main.dispatch_request
/var/sites/hass/trac/hass.wsgi file:
#!/usr/bin/python
import os
os.environ['TRAC_ENV_DIR'] = '/var/sites/hass/trac/'
os.environ['PYTHON_EGG_CACHE'] = '/tmp/hasseggs/'
import trac.web.main
application = trac.web.main.dispatch_request
I have done my Google search and read the archive regarding this but I
am not too clear.
-mod_wsgiwas compiled from source and is version 2.6
- Everything is running over HTTP (plain-text)
- Everything is UID:GID apache:apache
- All .wsgi scripts are set to 755 permission
- I have LDAP authentication but that part is working just fine.
- I am planning to add more projects under /var/sites/ but need to
solve this issue first.
Thanks for help.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups Trac
Users group.
To post to this group, send email to trac-users@googlegroups.com
To unsubscribe from this group, send email to
trac-users+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/trac-users?hl=en
-~--~~~~--~~--~--~---
[Trac] Re: wsgi 2.6 and multiple projects
Whoops, not variable leakage as not using different interpreters.
Problem is that is the same interpreter and os.environ is process
global and only set once so interfere. Same solution, use SetEnv.
Still better to use daemon mode if can.
Graham
On Oct 28, 6:45 am, Graham Dumpleton graham.dumple...@gmail.com
wrote:
Why are you using both os.environ and SetEnv at same time? You
shouldn't do that. Use just SetEnv and make sure you are setting the
correct variables. At the moment you are setting trac.env_parent_dir
for both when you should be using trac.env_path for one in line with
what os.environ variables you were trying to use.
For why you are having problems when using os.environ read:
http://code.google.com/p/modwsgi/wiki/ApplicationIssues#Application_E...
where it explicitly mentions Trac as an example of variable leakage.
Also read:
http://code.google.com/p/modwsgi/wiki/IntegrationWithTrac
where it suggests you use separate daemon process groups and not
embedded mode if distinct instances, especially where they may have no
common set of plugins etc. At the moment you are mixing two instances
in one interpreter of process and that may cause other conflicts in
addition to your current problem where plugin sets and dependencies
are different.
Graham
On Oct 27, 9:44 pm, chris henders...@gmail.com wrote:
I am having trouble setting up wgsi with multiple projects.
I have multiple projects underhttp://trac.company.com/ims/trac
(/var/sites/ims/trac/{math,compsci,hr} directories) - so when I browse
tohttp://trac.company.com/ims/trac,
I get a listing of all the projects from where I click on individual
project's trac page or I can browse to the project's page directly
(eg.http://trac.company.com/ims/trac/compsci)
I also have another project under /var/sites/hass/trac (http://
trac.company.com/hass/trac/) so when I browse to that URL I land on
HASS' trac page directly (because there's only one project here)
The issue: when I
visithttp://trac.company.com/ims/andthenhttp://trac.company.com/hass/trac/andthen
go
back tohttp://trac.company.com/ims/andrefresh my browser, I get the
page fromhttp://trac.company.com/hass/trac/. So I must be doing
something wrong.
Here is my configuration details:
/etc/http/conf.d/trac.conf:
WSGIScriptAlias /ims/trac /var/sites/ims/trac/ims.wsgi
Directory /var/sites/ims/trac/
WSGIApplicationGroup %{GLOBAL}
SetEnv trac.env_parent_dir /var/sites/ims/trac/
Order allow,deny
Allow from all
/Directory
WSGIScriptAlias /hass/trac /var/sites/hass/trac/hass.wsgi
Directory /var/sites/hass/trac/
WSGIApplicationGroup %{GLOBAL}
SetEnv trac.env_parent_dir /var/sites/hass/trac/
Order allow,deny
Allow from all
/Directory
/var/sites/ims/trac/ims.wsgi file:
#!/usr/bin/python
import os
os.environ['TRAC_ENV_PARENT_DIR'] = '/var/sites/ims/trac/'
os.environ['PYTHON_EGG_CACHE'] = '/tmp/imseggs/'
import trac.web.main
application = trac.web.main.dispatch_request
/var/sites/hass/trac/hass.wsgi file:
#!/usr/bin/python
import os
os.environ['TRAC_ENV_DIR'] = '/var/sites/hass/trac/'
os.environ['PYTHON_EGG_CACHE'] = '/tmp/hasseggs/'
import trac.web.main
application = trac.web.main.dispatch_request
I have done my Google search and read the archive regarding this but I
am not too clear.
-mod_wsgiwas compiled from source and is version 2.6
- Everything is running over HTTP (plain-text)
- Everything is UID:GID apache:apache
- All .wsgi scripts are set to 755 permission
- I have LDAP authentication but that part is working just fine.
- I am planning to add more projects under /var/sites/ but need to
solve this issue first.
Thanks for help.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups Trac
Users group.
To post to this group, send email to trac-users@googlegroups.com
To unsubscribe from this group, send email to
trac-users+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/trac-users?hl=en
-~--~~~~--~~--~--~---
[Trac] Re: On Windows, Apache crashes when I attempt to access trac
On Sep 24, 4:11 pm, Cooke, Mark mark.co...@siemens.com wrote:
Hello,
I cannot seem to get TRAC to work under Apache.
First of all, I can access subversion through apache w/o any problems.
Other discussion that I found seen to indicate that I may have a
version mismatch been the Apache and Python.
I have installed the following:
-- python 2.5 installed with python-2.5.msi
-- apache with apache_2.2.13-win32-x86-openssl-0.9.8k.msi
-- mod_python with mod_python-3.3.1.win32-py2.5-Apache2.2.exe
Graham Dumpleton has been trying to persuade everyone on the mod_python
list to move to mod_wsgi for ages, it is generally faster and most
importantly actively developed (mod_python seems pretty dead now). So I
used mod_wsgi to run trac (before I was asked not to use apache) with no
problems. Here's what I had in my httpd.conf:
Probably make no difference in this case as my guess would be that a
mismatch is occurring as he says, but between version of subversion
used by mod_svn and what Python subversion wrappers were compiled
against or require.
If it if something like that and isn't resolved, changing to mod_wsgi
will not matter.
Graham
LoadModule wsgi_module modules/mod_wsgi.so
...and...
#
=== #
# ==
Trac === #
#
=== #
#
# Trac is accessed using WSGI...
#
WSGIScriptAlias /trac D:/TRAC/apache/trac.wsgi
Directory D:/TRAC/apache
WSGIApplicationGroup %{GLOBAL}
Order deny,allow
Allow from all
/Directory
...and trac.wsgi (nice and simple but stripped of comments)...
import sys
sys.stdout = sys.stderr
import os
os.environ['TRAC_ENV_PARENT_DIR'] = 'd:/TRAC/sites'
os.environ['PYTHON_EGG_CACHE'] = 'd:/TRAC/eggs'
import trac.web.main
application = trac.web.main.dispatch_request
...to serve all trac environments stored under 'd:/TRAC/sites'. Hope
this helps.
~ Mark C
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups Trac
Users group.
To post to this group, send email to trac-users@googlegroups.com
To unsubscribe from this group, send email to
trac-users+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/trac-users?hl=en
-~--~~~~--~~--~--~---
[Trac] Re: On Windows, Apache crashes when I attempt to access trac
On Sep 24, 5:15 pm, Graham Dumpleton graham.dumple...@gmail.com
wrote:
On Sep 24, 4:11 pm, Cooke, Mark mark.co...@siemens.com wrote:
Hello,
I cannot seem to get TRAC to work under Apache.
First of all, I can access subversion through apache w/o any problems.
Other discussion that I found seen to indicate that I may have a
version mismatch been the Apache and Python.
I have installed the following:
-- python 2.5 installed with python-2.5.msi
-- apache with apache_2.2.13-win32-x86-openssl-0.9.8k.msi
-- mod_python with mod_python-3.3.1.win32-py2.5-Apache2.2.exe
Graham Dumpleton has been trying to persuade everyone on the mod_python
list to move to mod_wsgi for ages, it is generally faster and most
importantly actively developed (mod_python seems pretty dead now). So I
used mod_wsgi to run trac (before I was asked not to use apache) with no
problems. Here's what I had in my httpd.conf:
Probably make no difference in this case as my guess would be that a
mismatch is occurring as he says, but between version of subversion
used by mod_svn and what Python subversion wrappers were compiled
against or require.
If it if something like that and isn't resolved, changing to mod_wsgi
will not matter.
Actually, I guess the way to validate whether that is the issue, is to
ensure that the mod_dav_svn module is disabled in Apache and then
test.
Graham
Graham
LoadModule wsgi_module modules/mod_wsgi.so
...and...
#
=== #
# ==
Trac === #
#
=== #
#
# Trac is accessed using WSGI...
#
WSGIScriptAlias /trac D:/TRAC/apache/trac.wsgi
Directory D:/TRAC/apache
WSGIApplicationGroup %{GLOBAL}
Order deny,allow
Allow from all
/Directory
...and trac.wsgi (nice and simple but stripped of comments)...
import sys
sys.stdout = sys.stderr
import os
os.environ['TRAC_ENV_PARENT_DIR'] = 'd:/TRAC/sites'
os.environ['PYTHON_EGG_CACHE'] = 'd:/TRAC/eggs'
import trac.web.main
application = trac.web.main.dispatch_request
...to serve all trac environments stored under 'd:/TRAC/sites'. Hope
this helps.
~ Mark C
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups Trac
Users group.
To post to this group, send email to trac-users@googlegroups.com
To unsubscribe from this group, send email to
trac-users+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/trac-users?hl=en
-~--~~~~--~~--~--~---
[Trac] Re: Is it possible to host trac 0.10 and 0.11 environments on the same server?
On Aug 27, 4:17 pm, Álvaro J. Iradier alvaro.irad...@polartech.es wrote: I use Trac 0.10 and 0.11 with mod_python, as described here: https://devel.airadier.com/default/blog/modpythonvirtualenvironments Virtual environment use for mod_wsgi described at: http://code.google.com/p/modwsgi/wiki/VirtualEnvironments As long as virtual environments used correctly, then no need to have separate Python/Apache/mod_wsgi installations. Only time you would is if you needed to use a different version of Python. Graham Greets. On Wed, Aug 26, 2009 at 8:31 PM, dtdils...@gmail.com wrote: Hi, Currently we have bunch of trac 0.10 projects. Before upgrading all our existing projects to 0.11, we would to like to set up a new trac 0.11 project on the same host. Do you guys think it's doable or advisable? Thanks, - dt -- Álvaro J. Iradier Muro Departamento de Desarrollo alvaro.irad...@polartech.es Polar Technologies T +34 976 527 952 F +34 976 466 125www.polartech.es Antes de imprimir este mensaje, por favor, compruebe que es verdaderamente necesario. El medioambiente es cosa de todos. AVISO LEGAL Este mensaje, y en su caso, cualquier fichero anexo al mismo, puede contener información confidencial, siendo para uso exclusivo del destinatario, quedando prohibida su divulgación, copia o distribución a terceros sin la autorización expresa del remitente. Si Vd. ha recibido este mensaje erróneamente, se ruega lo notifique al remitente y proceda a su borrado. Gracias por su colaboración. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Trac Users group. To post to this group, send email to trac-users@googlegroups.com To unsubscribe from this group, send email to trac-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/trac-users?hl=en -~--~~~~--~~--~--~---
[Trac] Re: Mod_Python vs mod_wsgi
On Jul 27, 9:39 pm, Greg Troxel g...@ir.bbn.com wrote: After looking into the most current version of mod_python, I found that there is little to no support for it - development seems to have stopped about 1 1/2 years ago. The last active developer has suggested that users move to mod_wsgi. Reference: http://code.google.com/p/modwsgi/ The message can be found at: http://modpython.org/pipermail/mod_python/2009-July/026279.html I would appreciate comments. I am running trac on about 5 boxes, NetBSD 4 or 5, i386 or amd64, apache 2.2.x. Most are running mod_wsgi and perhaps one or two mod_python. My plan is to make them all run mod_wsgi. I suspect that mod_python leaks memory into apache, even the master process, but I can't quite prove that. Yes, mod_python has a problem in it whereby it doesn't destroy the interpreter properly in Apache parent process resulting in all the memory in use by the interpreter being leaked. See: https://issues.apache.org/jira/browse/MODPYTHON-235 In mod_wsgi, it does destroy the interpreter properly and so doesn't suffer the same problem. That said, the Python interpreter itself, even when destroyed, does leak a small amount of memory depending on which version of Python you are using. End result is that for mod_wsgi, you still may see Apache parent process grow in memory usage if you do a lot of restarts or graceful restart, rather than complete stop/start. mod_wsgi is slightly tricky to set up in that you need to install a small script but once you get it working it is entirely reliable, so this is in my view not a worry. Although some like that mod_python can just refer to a installed Python module, that it does this is a PITA. This is because it is completely contrary to the Apache resource model and as a result the SCRIPT_NAME value which identifies where an application is mounted is usually never correct for mod_python. As a result, applications when using mod_python usually have to provide a way of fudging things by telling the application manually where it is mounted. So I recommend that you use mod_wsgi. Graham presumably would have said that too, but I'm disinterested :-) As much as I would like to see mod_python vanish, I am not that blatant about telling people that mod_python is a stinking pile of cow turd and that mod_wsgi is much sweeter smelling. :-) Graham --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Trac Users group. To post to this group, send email to trac-users@googlegroups.com To unsubscribe from this group, send email to trac-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/trac-users?hl=en -~--~~~~--~~--~--~---
[Trac] Re: Mod_Python vs mod_wsgi
On Jul 27, 12:37 pm, ray ray.jos...@cdicorp.com wrote: After looking into the most current version of mod_python, I found that there is little to no support for it - development seems to have stopped about 1 1/2 years ago. The last active developer has suggested that users move to mod_wsgi. Reference:http://code.google.com/p/modwsgi/ The message can be found at:http://modpython.org/pipermail/mod_python/2009-July/026279.html I would appreciate comments. Development on mod_python effectively stopped 2 1/2 years ago, not 1 1/2.. Quoting time of last release from mod_python site: Feb-14-2007 3.3.1 is out and available on the download page. There may have been a few commits in repository since then, but only because I got sick of answering questions as to why last release wouldn't build on latest APR versions and MacOS X. I wouldn't construe those commits as being an indication of active development. :-) Graham --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Trac Users group. To post to this group, send email to trac-users@googlegroups.com To unsubscribe from this group, send email to trac-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/trac-users?hl=en -~--~~~~--~~--~--~---
[Trac] Re: Requirements to run apps using TracWsgi ?
On Jul 24, 5:48 am, Leonardo Santagada santag...@gmail.com wrote: On Thu, Jul 23, 2009 at 3:26 PM, Olemis Lang ole...@gmail.com wrote: On Thu, Jul 23, 2009 at 1:06 PM, Leonardo Santagadasantag...@gmail.com wrote: On Thu, Jul 23, 2009 at 2:45 PM, Olemis Lang ole...@gmail.com wrote: Hello ! I'd like to try TracWsgi plugin but there's something I dont understand : - Does it work with any HTTP server ? Yes. Theres mod_wsgi for apache and ngix and FastCGI for those http servers and others So this means that I cannot use Trac on top of `mod_python` and then run the WSGI app on top of Trac. Isn't it? I forgot to mention something here . I want to run an app inside Trac URL space, not Trac using PasteDeploy script ... ;) Here I'd like to know something. How does it work ? The two alternatives I have in mind are the following : - The plugin acts as a wrapper and uses the Trac web context to «rewrite» the WSGI environment used to run the «inner» app . - The hosted app is run by the app server directly. Which one is correct ? With my eyes closed I thought it was the first one and in this case I supposed that only trac.ini had to be modified, but I'm not sure. A ! I assume that I need PasteDeploy . Is it correct ? - I mean, suppose I've installed and setup Trac already : The only thing I need to do in order to run a WSGI app is to modify `trac.ini` by including PasteDeploy config options ? Should I do anything else ? configure your http server for serving a wsgi app. Well is it when Trac is deployed using PasteDeploy, or when the plugin is used to run WSGI apps inside Trac, or both ? (yes I didnt say what I wanted to do before :-/ ) I never used this plugin in particular, but if I read the documentation corretly it does two thing, serve trac as a wsgi app (which can be done without a plugin) and permits wsgi apps to be served in the same urlspace as trac. Probably its easy to find in the code how it does this, my guess would be that it redirect requests from trac otherwise it wouldn't need to be a trac plugin, but I'm only guessing. Not sure the original poster is clear enough about what he wants to do. If all he wants to do is mount two distinct WSGI applications, ie., Trac and something else, at different mount points of the same server, then he can use mod_wsgi. Eg. WSGIScriptAlias /inner /some/path/inner.wsgi WSGIScriptAlias / /some/path/trac.wsgi When doing this, mod_wsgi will ensure that WSGI environment is correct for the respective mount points. If he wants to actually have the Trac application modify the WSGI request environment or request content stream on the way in, or have the Trac application modify response headers of response content stream on the way out, or use a form based authentication mechanism in Trac to control access to the inner application, then he would need to use a form of object composition. So, what is it? Graham --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Trac Users group. To post to this group, send email to trac-users@googlegroups.com To unsubscribe from this group, send email to trac-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/trac-users?hl=en -~--~~~~--~~--~--~---
[Trac] Re: Is it possible to use different versions of a plugin in multi-project environment?
On Jun 8, 6:32 pm, Christian Boos cb...@neuf.fr wrote: Sneha wrote: Hi All, We are working on multi-project Trac environment. we have modified a plugin to suit a project's requirement. Is it possible to install this modified version of the plugin for a certain project and use the default (unmodified) version of the same plugin in all other? Not unless the modified plugin also uses a modified package name (i.e. if the source lived in tracpluginsomething/, rename that folder to tracpluginmysomething/ and update the setup.py file accordingly). Or refactor the change you did so that it only gets activated when some option is selected in trac.ini, and turn this on/off in the different environments. Or use mod_wsgi daemon mode and delegate each project to a different process group. This exact case is described in mod_wsgi documentation for Trac integration. See: http://code.google.com/p/modwsgi/wiki/IntegrationWithTrac Graham Hope this helps! -- Christian We are using easy-install --always-unzip command to install plugins for all projects. Thanks, Sneha --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Trac Users group. To post to this group, send email to trac-users@googlegroups.com To unsubscribe from this group, send email to trac-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/trac-users?hl=en -~--~~~~--~~--~--~---
[Trac] Re: Problem with Trac+Wsgi+Svn
On May 22, 9:25 am, turkanis turka...@coderage.com wrote:
I have four trac installations that I would like to switch from
mod_python to mod_wsgi.
With my first configuration attempt, I occasionally get the error
instance.__dict__ not accessible in restricted mode.
You have to run them all in the first interpreter, you are only doing
that for one. Read the documentation as it explains what you need to
do to host multiple sites.
http://code.google.com/p/modwsgi/wiki/IntegrationWithTrac
Graham
It appears to be the same problem referenced
here:http://www.mail-archive.com/trac-users@googlegroups.com/msg12346.html.
I haven't been able to find any info on the resolution of that
problem. My apache configuration and trac.wsgi are listed below.
Any help would be greatly appreciated.
--
trac.conf:
WSGIDaemonProcess tracs threads=10 maximum-requests=500
Directory /var/trac/wsgi
WSGIProcessGroup tracs
WSGIApplicationGroup %{GLOBAL}
Order deny,allow
Allow from all
/Directory
VirtualHost *:80
ServerName trac..net
SetEnv trac.env_path /var/trac/projects/trac..net
WSGIScriptAlias / /var/trac/trac.wsgi
Directory /var/trac/projects/trac..net/htdocs
AllowOverride None
/Directory
Location /login
AuthType Basic
AuthName
AuthUserFile /var/trac/projects/trac..net.passwd
Require valid-user
/Location
/VirtualHost
VirtualHost *:80
ServerName trac..com
SetEnv trac.env_path /var/trac/projects/trac..com
WSGIScriptAlias / /var/trac/trac.wsgi
Directory /var/trac/projects/trac..com/htdocs
AllowOverride None
/Directory
Location /login
AuthType Basic
AuthName
AuthUserFile /var/trac/projects/trac..com.passwd
Require valid-user
/Location
/VirtualHost
VirtualHost *:80
ServerName trac..com
SetEnv trac.env_path /var/trac/projects/trac..com
WSGIScriptAlias / /var/trac/trac.wsgi
Directory /var/trac/projects/trac..com/htdocs
AllowOverride None
/Directory
Location /login
AuthType Basic
AuthName
AuthUserFile /var/trac/projects/trac..com.passwd
Require valid-user
/Location
/VirtualHost
VirtualHost *:80
ServerName trac..net
SetEnv trac.env_path /var/trac/projects/trac..net
WSGIScriptAlias / /var/trac/trac.wsgi
Directory /var/trac/projects/trac..net/htdocs
AllowOverride None
/Directory
Location /login
AuthType Basic
AuthName
AuthUserFile /var/trac/projects/trac..net.passwd
Require valid-user
/Location
/VirtualHost
--
trac.wsgi:
import os
os.environ['PYTHON_EGG_CACHE'] = '/var/trac/egg-cache'
import trac.web.main
application = trac.web.main.dispatch_request
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups Trac
Users group.
To post to this group, send email to trac-users@googlegroups.com
To unsubscribe from this group, send email to
trac-users+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/trac-users?hl=en
-~--~~~~--~~--~--~---
[Trac] Re: TracError: The user www-data requires read _and_ write permission
Or use Apache/mod_wsgi in daemon mode and have the daemon process run as the actual user who owns the stuff and not the Apache user. Graham On May 17, 4:32 am, Ariel Balter ar...@arielbalter.com wrote: as root: chmod -R 755 /var/trac optionally: chown -R www-data:www-data /var/trac rstackhouse wrote: I am trying to get a Trac install up and running on Ubuntu. Currently, I am getting the following error: TracError: The user www-data requires read _and_ write permission to the database file /var/trac/myproject/db/trac.db and the directory it is located in. Any assistance would be greatly appreciated. Thanks, Robert -- /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ Ariel I Balter, Ph.D. Postdoc Biological Monitoring/Modeling Fundamental and Computational Sciences Directorate Pacific Northwest National Laboratory Mail: PO Box 999, MS P7-58,Richland, WA 99352 Shipping: 790 6th Street, MS P7-58, Richland, WA 99354 Tel: 509-376-7605 Cell: 509-713-0087 ariel.bal...@pnl.govwww.arielbalter.comwww.pnl.gov ariel.vcf 1KViewDownload --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Trac Users group. To post to this group, send email to trac-users@googlegroups.com To unsubscribe from this group, send email to trac-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/trac-users?hl=en -~--~~~~--~~--~--~---
[Trac] Re: No content for /chrome files when running under mod_wsgi
Upgrade to mod_wsgi 2.4 or turn KeepAlive off in Apache. See:
http://code.google.com/p/modwsgi/issues/detail?id=132can=1start=100
At least it sounds like that problem.
The advice in:
http://trac.edgewall.org/wiki/TracModWSGI
about version to use should really be changed from 2.3 to 2.4.
I'll try and do this later if get a chance and if no one else has got
there before me.
Graham
On Apr 15, 3:06 am, Kamil Kisiel kamil.kis...@gmail.com wrote:
I'm trying to run Trac 0.11.4 on Apache 2.2.10 withmod_wsgi2.3 on
openSUSE 11.1
The site itself works fine, however hardly any of the stylesheets or
images from /chrome/ are served to the browser. The only ones that
seem to make it are /chrome/common/trac.css and /chrome/common/
dots.gif
For the remainder of the /chrome/ content the browser gets the headers
correctly, but the response is blank. I tested this with Firebug.
Using debug logging in trac, there are no obvious failures. Every
request returns a message like:
2009-04-14 10:00:36,792 Trac[main] DEBUG: Dispatching Request GET u'/
chrome/common/topbar_gradient.png'
2009-04-14 10:00:36,805 Trac[main] DEBUG: Dispatching Request GET u'/
chrome/common/topbar_gradient2.png'
In the apache logs, every request has HTTP code 200, so all looks good
from that end as well.
As a test, I ran the same site under tracd and everything works
perfectly with that setup, so there is obviously something wrong when
running under wsgi.
Here's a copy of my virtual host configuration which I took from our
current trac server which is running on Gentoo under fcgi, and
modified it for use on the new openSUSE server with wsgi. Domain names
have been anonymized to protect the innocent ;)
VirtualHost *:80
ServerName trac2.lan.foo.com
ServerAlias trac2 trac2.lan
# Logging
LogLevel warn
ErrorLog /var/log/apache2/trac.lan.foo.com-error_log
CustomLog /var/log/apache2/trac.lan.foo.com-access_log combined
# Rewrite all other domains to trac.lan.foo.com
RewriteEngine on
RewriteCond %{HTTP_HOST} !^trac2\.lan\.zfoo\.com
RewriteRule ^(.*)http://trac2.lan.foo.com$1[L,R=301]
DocumentRoot /srv/www/vhosts/trac.lan.foo.com/htdocs/
ErrorDocument 500 Don't panic. Have a beer. Call your parents. The
server has encountered a temporary error. Wait a minute, reload the
page, and everything should be fine. If not, then tell someone.
WSGIScriptAlias / /srv/www/vhosts/trac.lan.foo.com/cgi-bin/trac.wsgi
Directory /srv/www/vhosts/trac.lan.foo.com/cgi-bin/
#WSGIApplicationGroup %{GLOBAL}
AllowOverride None
Order allow,deny
Allow from all
/Directory
# Require LDAP authentication
Location /login
AuthType basic
AuthName foo
AuthBasicProvider ldap
AuthLDAPURL ldap://ldapurl
AuthzLDAPAuthoritative on
AuthLDAPGroupAttribute memberUid
AuthLDAPGroupAttributeIsDN off
Require valid-user
/Location
/VirtualHost
I'm pretty much at a loss now as to how to further debug this problem.
None of the logs seem to indicate any issues and everything runs well
under tracd. Any insight would be much appreciated.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups Trac
Users group.
To post to this group, send email to trac-users@googlegroups.com
To unsubscribe from this group, send email to
trac-users+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/trac-users?hl=en
-~--~~~~--~~--~--~---
[Trac] Re: Error accessing trac for the first time
On Mar 31, 10:44 pm, BA brend...@gmail.com wrote: Hello: I am receiving this error in the Apache log file when I try to accesshttp://localhost/trac/ mod_wsgi(pid=1212): Target WSGI script 'C:/projects/cbs/wsgi/ cbs.wsgi' cannot be loaded as Python module.mod_wsgi(pid=1212): Exception occurred processing WSGI script 'C:/ projects/cbs/wsgi/cbs.wsgi'. Traceback (most recent call last): File C:/projects/cbs/wsgi/cbs.wsgi, line 6, in module import trac.web.main File c:\\python\\python26\\lib\\site-packages\\Trac-0.11.3-py2.6.egg \\trac\\web\\__init__.py, line 12, in module from trac.web.api import * File c:\\python\\python26\\lib\\site-packages\\Trac-0.11.3-py2.6.egg \\trac\\web\\api.py, line 17, in module from BaseHTTPServer import BaseHTTPRequestHandler File C:\\python\\python26\\lib\\BaseHTTPServer.py, line 75, in module import socket # For gethostbyaddr() File C:\\python\\python26\\lib\\socket.py, line 46, in module import _socket ImportError: DLL load failed: The specified module could not be found. Trac works when I use the standalone server (tracd). I'm using: Python 2.6 (latest) PostgreSQL 8.3 (latest) psycopg2mod_wsgi(which seems to work when I use the example script, apache seems to be configured correctly) Apache 2.2 (latest) Can anybody give me a hand? In your WSGI hello world example script add: import socket Then you will find it probably fails. Then replace that with: import sys print sys.stderr, sys.path Look in the Apache error log for what sys.path is dumped out as. Then search your system for file called '_socket.so'. Presuming that is Python modules still have .so extension on Windows, can't remember. If that directory isn't in sys.path, then likely that your Python module search path is screwed, possibly because of broken Windows registry entries. Post results of what you get for sys.path and where the _socket extension module is located. Graham --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Trac Users group. To post to this group, send email to trac-users@googlegroups.com To unsubscribe from this group, send email to trac-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/trac-users?hl=en -~--~~~~--~~--~--~---
[Trac] Re: segmentation fault and ticket 2611
On Feb 19, 2:10 am, George Nychis gnyc...@cmu.edu wrote: Sorry, I had tried PythonInterpreter main_interpreter and it didn't help, as I mentioned in my e-mail. So, I tried switching to trac which is when I posted to the mailing list. I have a mod_python version after 3.2.8, which the comment suggested in comment 1. As for the second comment, I'm not using mod_wsgi, and it said the solution is the same as PythonInterpreter main_interpreter ... I suggest mod_wsgi as mod_python still has other bugs in it related to Python GIL which mod_wsgi doesn't. It is also much easier to isolate the problem with mod_wsgi because you can use daemon mode to delegate Trac to a process of its own, allowing debuggers to be more easily attached and capture where crash is occuring. Anyway, it is quite possible it isn't even that issue as there are various other issues that can cause Trac to crash. For one, have you even checked the expat incompatibility problem. Or the problem caused by svn module for Apache being built and/or using different version of svn libraries to Python svn libraries. And have you ensure you aren't running PHP in same Apache instance. For the expat issue see: http://code.google.com/p/modwsgi/wiki/IssuesWithExpatLibrary http://www.dscpl.com.au/wiki/ModPython/Articles/ExpatCausingApacheCrash Graham - George Graham Dumpleton wrote: You don't even follow the advice in that ticket. You have: PythonInterpreter trac You must use: PythonInterpreter main_interpreter Go read the two references linked from last comment in that ticket. Graham On Feb 18, 8:43 am, George Nychis gnyc...@cmu.edu wrote: sorry for the bump, still having issues with this. George Nychis wrote: Hi all, I am having the following error: http://trac.edgewall.org/ticket/2611 I tried adding PythonInterpreter main_interpreter which is suggested by users in the ticket, however, I am still getting the segfault. Here is my full configuration, line 333 is where the related config starts: http://pastebin.com/f7ab11ddb A little bit about what I'm using: Apache/2.2.6 (FreeBSD) mod_ssl/2.2.6 OpenSSL/0.9.8g DAV/2 SVN/1.4.4 PHP/5.2.5 with Suhosin-Patch mod_python/3.3.1 Python/2.5.1 I'd greatly appreciate any suggestions. Thanks! George --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Trac Users group. To post to this group, send email to trac-users@googlegroups.com To unsubscribe from this group, send email to trac-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/trac-users?hl=en -~--~~~~--~~--~--~---
[Trac] Re: client denied by server configuration in Apache error log
On Feb 21, 7:09 am, Schindler, Nathan nathan.schind...@guidancesoftware.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 -Original Message- From: trac-users@googlegroups.com [mailto:trac-us...@googlegroups.com] On Behalf Of Nate Sent: Thursday, February 19, 2009 12:30 PM To: Trac Users Subject: [Trac] client denied by server configuration in Apache error log We have Apache (2.2.3 on RHEL5) slightly hardened - in httpd.conf, Deny from all is specified within Directory /var/www/html. This is overridden in the Apache config file for Trac with Allow from all within Location /projects, where all of our Trac projects reside. When a user hits the site, a line similar to the following is logged: [date] [error] [client client IP] client denied by server configuration: /var/www/html/project, referer: https://server/projects/project/ Nothing in the project config or Apache config point to /var/www/html or have a path relative to the web root that doesn't include / projects/. The rendered page source also doesn't include any apparent incorrect links. This seems related tohttp://lists.edgewall.com/archive/trac/2005- June/003277.html Anyone have any idea what's causing these log entries? Thanks in advance, Nate -Original Message- From: trac-users@googlegroups.com [mailto:trac-us...@googlegroups.com] On Behalf Of Noah Kantrowitz Sent: Friday, February 20, 2009 11:41 AM To: trac-users@googlegroups.com Subject: [Trac] Re: client denied by server configuration in Apache error log Apache still does a directory ACL check on $DOC_ROOT + $REQ_PATH as if the request was going to go the filesystem, even if it ends up being captured later on by another handler. Just point docroot at an empty folder somewhere (not the trac env!) and then make a Directory block that grants Allow to all. --Noah Thanks, but I'm still a little unclear. If that's the case, why don't I see similar log entries from requests to Subversion? It's configured essentially the same way as Trac, with Location directives pointing to /repos/repo name (relative to the Apache docroot). Since Apache errors aren't logged when hitting Subversion with the same Location Allow restrictions in place as Trac, I suspected Trac javascripts or possibly mod_python. It is the way that mod_python is inserted into Apache processing. Use mod_wsgi and you will not have this problem as it works by using an actual file as entry point, where as mod_python tries to do it with Location directives which doesn't circumvent normal URL matching rules properly. Graham --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Trac Users group. To post to this group, send email to trac-users@googlegroups.com To unsubscribe from this group, send email to trac-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/trac-users?hl=en -~--~~~~--~~--~--~---
[Trac] Re: Connection Interrupted - Subversion integration on Windows 2k3 with Apache and mod_python
On Feb 21, 8:57 am, JaceTheAce jace.mi...@gmail.com wrote: JaceTheAce wrote: Here is the output from Apache's error.log: [Fri Feb 20 09:38:07 2009] [notice] Parent: child process exited with status 3221225477 -- Restarting. [Fri Feb 20 09:38:07 2009] [notice] Apache/2.2.8 (Win32) DAV/2 mod_auth_sspi/1.0.4 mod_ssl/2.2.8 OpenSSL/0.9.8g SVN/1.5.5 configured -- resuming normal operations [Fri Feb 20 09:38:07 2009] [notice] Server built: Jul 28 2008 20:01:54 [Fri Feb 20 09:38:07 2009] [notice] Parent: Created child process 4856 [Fri Feb 20 09:38:08 2009] [warn] Init: Session Cache is not configured [hint: SSLSessionCache] [Fri Feb 20 09:38:08 2009] [error] python_init: Python version mismatch, expected '2.5', found '2.5.4'. [Fri Feb 20 09:38:08 2009] [error] python_init: Python executable found 'C:\\Program Files\\Subversion\\httpd\\bin\\httpd.exe'. [Fri Feb 20 09:38:08 2009] [error] python_init: Python path being used 'C:\\WINDOWS\\system32\\python25.zip;C:\\Program Files\\Python\\Lib;C:\\Program Files\\Python\\DLLs;C:\\Program Files\\Python\\Lib\\lib-tk;;C:\\Program Files\\Subversion\\httpd\\bin'. [Fri Feb 20 09:38:08 2009] [notice] mod_python: Creating 8 session mutexes based on 0 max processes and 250 max threads. [Fri Feb 20 09:38:09 2009] [notice] Child 4856: Child process is running [Fri Feb 20 09:38:09 2009] [notice] Child 4856: Acquired the start mutex. [Fri Feb 20 09:38:09 2009] [notice] Child 4856: Starting 250 worker threads. [Fri Feb 20 09:38:09 2009] [notice] Child 4856: Starting thread to listen on port 443. [Fri Feb 20 09:38:09 2009] [notice] Child 4856: Starting thread to listen on port 81. [Fri Feb 20 09:38:09 2009] [notice] Child 4856: Starting thread to listen on port 80. [Fri Feb 20 09:38:09 2009] [error] [client XX.X.X.XXX] (OS 87)The parameter is incorrect. : authentication failure for /: user unknown, reason: cannot generate context I solved the issue. I was using mod_python compiled against Apache 2.0, but needed the mod_python compiled against Apache 2.2. The filename for each of these is identical so it's a subtle oversight. Once I installed the correct mod_python it fixed my issue. I hope this helps others who might have this problem. The mod_python installers for different Apache versions do not use identical paths. Presuming you got them from the correct place. See: http://apache.mirror.aussiehq.net.au/httpd/modpython/win/3.3.1/ Graham --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Trac Users group. To post to this group, send email to trac-users@googlegroups.com To unsubscribe from this group, send email to trac-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/trac-users?hl=en -~--~~~~--~~--~--~---
[Trac] Re: segmentation fault and ticket 2611
You don't even follow the advice in that ticket. You have: PythonInterpreter trac You must use: PythonInterpreter main_interpreter Go read the two references linked from last comment in that ticket. Graham On Feb 18, 8:43 am, George Nychis gnyc...@cmu.edu wrote: sorry for the bump, still having issues with this. George Nychis wrote: Hi all, I am having the following error: http://trac.edgewall.org/ticket/2611 I tried adding PythonInterpreter main_interpreter which is suggested by users in the ticket, however, I am still getting the segfault. Here is my full configuration, line 333 is where the related config starts: http://pastebin.com/f7ab11ddb A little bit about what I'm using: Apache/2.2.6 (FreeBSD) mod_ssl/2.2.6 OpenSSL/0.9.8g DAV/2 SVN/1.4.4 PHP/5.2.5 with Suhosin-Patch mod_python/3.3.1 Python/2.5.1 I'd greatly appreciate any suggestions. Thanks! George --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Trac Users group. To post to this group, send email to trac-users@googlegroups.com To unsubscribe from this group, send email to trac-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/trac-users?hl=en -~--~~~~--~~--~--~---
[Trac] Re: Two trac versions, one box
On Feb 11, 1:52 am, Flatfender flatfen...@gmail.com wrote: On Tue, Feb 10, 2009 at 5:26 AM, Eirik Schwenke eirik.schwe...@nsd.uib.no wrote: Oliver Marshall skrev 10. feb. 2009 09:58: Hi chaps, Is it possible to run two versions of Trac on one server? We are using a normal Trac install at the moment with SVN. However we are working on a new product for some clients which is based on a highly modified version of Trac. Currently we are looking at a separate box each, though this is only because the tech's don't know if (how) we can run both versions on one server. The current Trac setup is more than enough to handle all the requests so I'm keen to save some budget and get the one box working for it's dinner. Anyone know whether this is possible at all ? If the system now is able to run a newer version of trac (ie you have a reasonably up to date python available) -- there shouldn't be a problem. You have a couple of options, depending on how much separation you want/need between the to instances. You might want to look at: http://trac.edgewall.org/wiki/TracDev/DevelopmentEnvironmentSetup for a general overview of how to use trac and python's virtualenv together. It's a great way to set up test-environments for trac, without creating problems for your regular installs. If you want more separation than this, you might look at runnig a chroot or a vserver/jail if your server is a linux or *bsd box. Personally I'm a great fan of Debian, and the combination of cdebootstrap and the schroot or vserver packages is a great way to run certain packages from eg. sid/unstable on a server running mainly etch/stable code. Hope this helps to get you started. I would think you could use two different virtual hosts with apache and then usemod_wsgiand have your wrapper scripts point to each separate trac install. It doesn't have to be two virtual hosts, mod_wsgi separates based on WSGI application mount point. Either way, you would be much better of delegating each instance to separate daemon process and separate virtual environment so no risk of interference, especially if different versions of C extension modules used. For further details see: http://code.google.com/p/modwsgi/wiki/IntegrationWithTrac http://code.google.com/p/modwsgi/wiki/VirtualEnvironments Graham --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Trac Users group. To post to this group, send email to trac-users@googlegroups.com To unsubscribe from this group, send email to trac-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/trac-users?hl=en -~--~~~~--~~--~--~---
[Trac] Re: PyString_FromString: Assertion `str != ((void *)0)' failed.
Came across a post somewhere in last few days suggesting that this error can also arise due to the infamous expat version mismatch problem. You would though mean you would have had to be using Python 2.4 or older as expat issues shouldn't exist in Python 2.5 as Python correctly namespace prefixes expat code in those latter versions. The expat problem is described in: http://code.google.com/p/modwsgi/wiki/IssuesWithExpatLibrary Normally one just gets a crash, but feasible that it might cause some sort of run time exception instead depending on how incompatible the expat versions are. Graham On Feb 7, 8:41 am, wooD wood.har...@gmail.com wrote: Sorry for the slow response to your questions. I gave up on the xampp install and used the default webserver and put it on a different port. This took about 10 minutes and actually works better for the environment by separating the development tools from the development server which will help when moving development code to a production environment. I still don't know how to fix the problem I was seeing in the xampp install, but using a different server fixed the problem for me. Wood On Jan 27, 6:01 pm, Graham Dumpleton graham.dumple...@gmail.com wrote: On Jan 28, 4:27 am, wooD wood.har...@gmail.com wrote: Yes, hello world worked. The instructions on that site are a little unclear, but I figured it out. I put the specified code in /home/trac/wsgi/hello.wsgi I added this to the apache config, just above my current trac config. WSGIScriptAlias /whello /home/trac/wsgi/hello.wsgi Then connected to my server.http://10.0.0.4/whello It generated the simple Hello World! text on the browser. This is the error log output. [Tue Jan 27 09:21:49 2009] [debug] proxy_util.c(1967): proxy: initialized single connection worker 0 in child 30683 for (*) [Tue Jan 27 09:21:49 2009] [info] mod_wsgi (pid=30683): Attach interpreter ''. [Tue Jan 27 09:22:21 2009] [info] mod_wsgi (pid=30679): Create interpreter 'localhost|/whello'. [Tue Jan 27 09:22:21 2009] [info] [client 32.97.110.54] mod_wsgi (pid=30679, process='', application='localhost|/whello'): Loading WSGI script '/home/trac/wsgi/hello.wsgi'. [Tue Jan 27 09:22:21 2009] [error] [client 32.97.110.54] File does not exist: /opt/lampp/htdocs/favicon.ico [Tue Jan 27 09:22:22 2009] [debug] proxy_util.c(1854): proxy: grabbed scoreboard slot 0 in child 30689 for worker proxy:reverse [Tue Jan 27 09:22:22 2009] [debug] proxy_util.c(1873): proxy: worker proxy:reverse already initialized [Tue Jan 27 09:22:22 2009] [debug] proxy_util.c(1967): proxy: initialized single connection worker 0 in child 30689 for (*) [Tue Jan 27 09:22:22 2009] [info] mod_wsgi (pid=30689): Attach interpreter ''. [Tue Jan 27 09:22:24 2009] [error] [client 32.97.110.54] File does not exist: /opt/lampp/htdocs/favicon.ico Next thing to work out then is at what point the error occurs when using Trac. That is, when WSGI script file first being imported, or when request being handled. To do this, add at start of WSGI script file for Trac: import sys print sys.stderr, START and at end: print sys.stderr, END Also wrap the application object in the WSGI script file with first bit of code from: http://code.google.com/p/modwsgi/wiki/DebuggingTechniques#Tracking_Re... When used together, should get in Apache error log messages about process of importing WSGI script file and handling of request. If END doesn't show up in Apache error log, then error during import. BTW, what database are you using and are you point Trac at subversion repository instance. Also, are you running PHP in same web server. If you are trying disabling it. Graham --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Trac Users group. To post to this group, send email to trac-users@googlegroups.com To unsubscribe from this group, send email to trac-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/trac-users?hl=en -~--~~~~--~~--~--~---
[Trac] Re: PyString_FromString: Assertion `str != ((void *)0)' failed.
On Jan 28, 4:27 am, wooD wood.har...@gmail.com wrote: Yes, hello world worked. The instructions on that site are a little unclear, but I figured it out. I put the specified code in /home/trac/wsgi/hello.wsgi I added this to the apache config, just above my current trac config. WSGIScriptAlias /whello /home/trac/wsgi/hello.wsgi Then connected to my server.http://10.0.0.4/whello It generated the simple Hello World! text on the browser. This is the error log output. [Tue Jan 27 09:21:49 2009] [debug] proxy_util.c(1967): proxy: initialized single connection worker 0 in child 30683 for (*) [Tue Jan 27 09:21:49 2009] [info] mod_wsgi (pid=30683): Attach interpreter ''. [Tue Jan 27 09:22:21 2009] [info] mod_wsgi (pid=30679): Create interpreter 'localhost|/whello'. [Tue Jan 27 09:22:21 2009] [info] [client 32.97.110.54] mod_wsgi (pid=30679, process='', application='localhost|/whello'): Loading WSGI script '/home/trac/wsgi/hello.wsgi'. [Tue Jan 27 09:22:21 2009] [error] [client 32.97.110.54] File does not exist: /opt/lampp/htdocs/favicon.ico [Tue Jan 27 09:22:22 2009] [debug] proxy_util.c(1854): proxy: grabbed scoreboard slot 0 in child 30689 for worker proxy:reverse [Tue Jan 27 09:22:22 2009] [debug] proxy_util.c(1873): proxy: worker proxy:reverse already initialized [Tue Jan 27 09:22:22 2009] [debug] proxy_util.c(1967): proxy: initialized single connection worker 0 in child 30689 for (*) [Tue Jan 27 09:22:22 2009] [info] mod_wsgi (pid=30689): Attach interpreter ''. [Tue Jan 27 09:22:24 2009] [error] [client 32.97.110.54] File does not exist: /opt/lampp/htdocs/favicon.ico Next thing to work out then is at what point the error occurs when using Trac. That is, when WSGI script file first being imported, or when request being handled. To do this, add at start of WSGI script file for Trac: import sys print sys.stderr, START and at end: print sys.stderr, END Also wrap the application object in the WSGI script file with first bit of code from: http://code.google.com/p/modwsgi/wiki/DebuggingTechniques#Tracking_Request_and_Response When used together, should get in Apache error log messages about process of importing WSGI script file and handling of request. If END doesn't show up in Apache error log, then error during import. BTW, what database are you using and are you point Trac at subversion repository instance. Also, are you running PHP in same web server. If you are trying disabling it. Graham --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Trac Users group. To post to this group, send email to trac-users@googlegroups.com To unsubscribe from this group, send email to trac-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/trac-users?hl=en -~--~~~~--~~--~--~---
[Trac] Re: PyString_FromString: Assertion `str != ((void *)0)' failed.
On Jan 26, 3:43 pm, wooD wood.har...@gmail.com wrote: Oh, I realized there was more information in the log. httpd: Objects/stringobject.c:107: PyString_FromString: Assertion `str != ((void *)0)' failed. This is likely due to one of the bugs in mod_python with the way it reads request content. Normally this is a very infrequent occurrence, so if you are getting this all the time am a bit surprised. Can you use mod_wsgi instead of mod_python? I really don't want to have to debug problems with mod_python as can be a PITA. Graham On Jan 25, 5:48 pm, wooD wood.har...@gmail.com wrote: # Trac configuration LoadModule python_module modules/mod_python.so Location /mpinfo SetHandler mod_python PythonInterpreter main_interpreter PythonHandler mod_python.testhandler /Location Location /projects/rt SetHandler mod_python PythonInterpreter main_interpreter PythonHandler trac.web.modpython_frontend PythonOption TracEnv /home/trac/rt #PythonOption TracUriRoot /projects/rt /Location On Jan 24, 6:13 pm, Graham Dumpleton graham.dumple...@gmail.com wrote: Post snippet of Apache configuration showing how you configured mod_python to pass stuff to Trac. Have you set PythonInterpreter in that configuration? Graham On Jan 24, 11:44 am, wooD wood.har...@gmail.com wrote: I'm trying to install trac for a friend and have already gotten subversion working on this machine. I also have trac working using the tracd server, but when I run it under apache I have a specific problem in the apache log when I try to connect to the trac url. PyString_FromString: Assertion `str != ((void *)0)' failed. I did a simple setup (so far) with no authentication and using SqlLite (the default db). There is something special with this install. This machine already hosts an apache server with an application running on it using XAMPP (lampp) [2007-09-24] XAMPP for Linux 1.6.8a That version of XAMPP/apache doesn't includemod_pythonor FastCGI, so I improvised and that may be where the problem lies. I went to the host and installedmod_python(mod_python-3.3.1-7.i38) and simply copied this to the modules directory on the XAMPP directory and hoped for the best. Everything works with the /mpinfo test (I can include that output if requested) so I figured it should also work with the trac install. In looking at the apache/XAMPP error log I see the error PyString_FromString: Assertion `str != ((void *)0)' failed. And a blank page is generated. Any ideas? Crazy work around ideas welcome, but based on the current situation and a bad decision before I stumbled along to use XAMPP instead of just building a custom apache or using the default distro apache (Fedore 2.6.26.3-29.fc9.i686 #1 SMP Wed Sep 3 03:42:27 EDT 2008 i686 i686 i386 GNU/Linux), I need to find a way to make it work with the current XAMPP install. Thanks, wooD --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Trac Users group. To post to this group, send email to trac-users@googlegroups.com To unsubscribe from this group, send email to trac-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/trac-users?hl=en -~--~~~~--~~--~--~---
[Trac] Re: PyString_FromString: Assertion `str != ((void *)0)' failed.
Does a hello world program even work?
http://code.google.com/p/modwsgi/wiki/QuickConfigurationGuide
If this works, then possibly a problem with some third party C
extension module for Python that you are using.
Graham
On Jan 27, 6:47 am, wooD wood.har...@gmail.com wrote:
I got through the wsgi install. Had to first install http-devel
package.
It looks like I'm now getting a similar error.
[Mon Jan 26 11:40:14 2009] [debug] proxy_util.c(1967): proxy:
initialized single connection worker 0 in child 10461 for (*)
[Mon Jan 26 11:40:14 2009] [info] mod_wsgi (pid=10461): Attach
interpreter ''.
[Mon Jan 26 11:40:16 2009] [info] mod_wsgi (pid=10457): Create
interpreter 'localhost|/trac'.
[Mon Jan 26 11:40:16 2009] [info] [client 32.97.110.54] mod_wsgi
(pid=10457, process='', application='localhost|/trac'): Loading WSGI
script '/home/trac/wsgi/trac.wsgi'.
httpd: Objects/stringobject.c:107: PyString_FromString: Assertion
`str != ((void *)0)' failed.
Again, the mod_wsgi.so file was copied from /usr/lib/httpd/modules/
mod_wsgi.so into the modules directory in my xampp modules directory.
This is the file /home/trac/wsgi/trac.wsgi (directory and file owned
by apache)
import os
os.environ['TRAC_ENV'] = '/home/trac/rt'
os.environ['PYTHON_EGG_CACHE'] = '/home/trac/rt/eggs'
import trac.web.main
application = trac.web.main.dispatch_request
This is the apache conf settings.
# Trac wsgi configuration
LoadModule wsgi_module modules/mod_wsgi.so
#AddModule mod_wsgi.c - this was specified in the quick install, but
caused problems on apache startup so I commented it out.
WSGIScriptAlias /trac /home/trac/wsgi/trac.wsgi
Directory /home/trac/rt/apache
WSGIApplicationGroup %{GLOBAL}
Order deny,allow
Allow from all
/Directory
On Jan 26, 10:22 am, wooD wood.har...@gmail.com wrote:
I started the mod_wsgi install, but only had a few minutes. It looks
like the xampp apache is causing more problems in that I pointed to
it's apxs (/opt/lampp/bin/apxs) and then the configure could not find
build/config_vars.mk which doesn't exist because this isn't a
buildable version of apache which is the root of all the problems
I've been having.
I'll look at it again later, but I think I'm going to have to build a
second apache server and use that on a different port for the svn and
trac stuff. At least I'm leaning towards moving in that direction.
Thanks,
Wood
On Jan 26, 4:29 am, Graham Dumpleton graham.dumple...@gmail.com
wrote:
On Jan 26, 3:43 pm, wooD wood.har...@gmail.com wrote:
Oh, I realized there was more information in the log.
httpd: Objects/stringobject.c:107: PyString_FromString: Assertion
`str != ((void *)0)' failed.
This is likely due to one of the bugs in mod_python with the way it
reads request content. Normally this is a very infrequent occurrence,
so if you are getting this all the time am a bit surprised.
Can you use mod_wsgi instead of mod_python? I really don't want to
have to debug problems with mod_python as can be a PITA.
Graham
On Jan 25, 5:48 pm, wooD wood.har...@gmail.com wrote:
# Trac configuration
LoadModule python_module modules/mod_python.so
Location /mpinfo
SetHandler mod_python
PythonInterpreter main_interpreter
PythonHandler mod_python.testhandler
/Location
Location /projects/rt
SetHandler mod_python
PythonInterpreter main_interpreter
PythonHandler trac.web.modpython_frontend
PythonOption TracEnv /home/trac/rt
#PythonOption TracUriRoot /projects/rt
/Location
On Jan 24, 6:13 pm, Graham Dumpleton graham.dumple...@gmail.com
wrote:
Post snippet of Apache configuration showing how you configured
mod_python to pass stuff to Trac.
Have you set PythonInterpreter in that configuration?
Graham
On Jan 24, 11:44 am, wooD wood.har...@gmail.com wrote:
I'm trying to install trac for a friend and have already gotten
subversion working on this machine. I also have trac working
using
the tracd server, but when I run it under apache I have a specific
problem in the apache log when I try to connect to the trac url.
PyString_FromString: Assertion `str != ((void *)0)' failed.
I did a simple setup (so far) with no authentication and using
SqlLite
(the default db).
There is something special with this install. This machine already
hosts an apache server with an application running on it using
XAMPP
(lampp)
[2007-09-24] XAMPP for Linux 1.6.8a
That version of XAMPP/apache doesn't includemod_pythonor FastCGI,
so
I improvised and that may be where the problem lies. I went to the
host and installedmod_python(mod_python-3.3.1-7.i38) and simply
copied this to the modules directory on the XAMPP directory and
hoped
for the best
[Trac] Re: Setting Trac Locale with mod_wsgi
I should have spotted it earlier. The following is wrong: Directory /var/www/project/trac/ It should be: Directory /var/www/project/ Because it was wrong you weren't even running in daemon mode but still in embedded mode. BTW, the mod_wsgi documentation says to put the WSGI script file in a special subdirectory of its own, not in the parent directory to the Trac instance. A subdirectory is used so that you are not telling Apache that it could technically serve up files from your Trac instance. A misconfiguration of your server could at the moment technically allow people to download your Trac instance data because of security on the file system being too loose. Graham On Jan 24, 5:57 pm, Andrea Tomasini tumm...@gmail.com wrote: On 23 Jan, 2009, at 10:41 , Graham Dumpleton wrote: On Jan 23, 4:37 am, Andrea Tomasini tumm...@gmail.com wrote: On 22 Jan, 2009, at 16:02 , Graham Dumpleton wrote: Use of SetEnv is mentioned in: http://code.google.com/p/modwsgi/wiki/IntegrationWithTrac Any page on the Trac wiki isn't going to mention all different possible ways that mod_wsgi can be configured. I figured it out, that's where I copied the configuration from... Trying using first recipe in section at: http://code.google.com/p/modwsgi/wiki/DebuggingTechniques#Tracking_Re... to wrap Trac application and verify what environment is being passed to Trac. If the correct environment is being passed, then something must be going wrong in Trac. I tried it out... and beside logging a _lot_ there is actually no trac or TRAC variable in there... even if the SetEnv is set in the Directory section of the apache config. What version of Trac are you using? Trac 0.11.2.1 Apache+mod_wsgi+python2.5 on debian lenny :-) Thanks for your help Graham ANdreaT --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Trac Users group. To post to this group, send email to trac-users@googlegroups.com To unsubscribe from this group, send email to trac-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/trac-users?hl=en -~--~~~~--~~--~--~---
[Trac] Re: Setting Trac Locale with mod_wsgi
On Jan 25, 4:15 am, Andrea Tomasini tumm...@gmail.com wrote: On 24 Jan, 2009, at 15:36 , Graham Dumpleton wrote: Hi Graham :-) I should have spotted it earlier. The following is wrong: Directory /var/www/project/trac/ It should be: Directory /var/www/project/ Because it was wrong you weren't even running in daemon mode but still in embedded mode. Well this was it, now it works, also the locale settings ;-) BTW, the mod_wsgi documentation says to put the WSGI script file in a special subdirectory of its own, not in the parent directory to the Trac instance. A subdirectory is used so that you are not telling Apache that it could technically serve up files from your Trac instance. A misconfiguration of your server could at the moment technically allow people to download your Trac instance data because of security on the file system being too loose. Fixed also this... thanks ;-) Except that since you have Trac instance under /var/www/ then still potentially exposed. You shouldn't put the Trac instance anywhere under Apache document root. It was only that you wrongly had it there in the first place that the WSGI script was even half working. If it was elsewhere and that path to Directory directive was wrong, you would have got forbidden access as WSGI script file hadn't been marked as being usable by Apache. Graham --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Trac Users group. To post to this group, send email to trac-users@googlegroups.com To unsubscribe from this group, send email to trac-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/trac-users?hl=en -~--~~~~--~~--~--~---
[Trac] Re: PyString_FromString: Assertion `str != ((void *)0)' failed.
Post snippet of Apache configuration showing how you configured mod_python to pass stuff to Trac. Have you set PythonInterpreter in that configuration? Graham On Jan 24, 11:44 am, wooD wood.har...@gmail.com wrote: I'm trying to install trac for a friend and have already gotten subversion working on this machine. I also have trac working using the tracd server, but when I run it under apache I have a specific problem in the apache log when I try to connect to the trac url. PyString_FromString: Assertion `str != ((void *)0)' failed. I did a simple setup (so far) with no authentication and using SqlLite (the default db). There is something special with this install. This machine already hosts an apache server with an application running on it using XAMPP (lampp) [2007-09-24] XAMPP for Linux 1.6.8a That version of XAMPP/apache doesn't includemod_pythonor FastCGI, so I improvised and that may be where the problem lies. I went to the host and installedmod_python(mod_python-3.3.1-7.i38) and simply copied this to the modules directory on the XAMPP directory and hoped for the best. Everything works with the /mpinfo test (I can include that output if requested) so I figured it should also work with the trac install. In looking at the apache/XAMPP error log I see the error PyString_FromString: Assertion `str != ((void *)0)' failed. And a blank page is generated. Any ideas? Crazy work around ideas welcome, but based on the current situation and a bad decision before I stumbled along to use XAMPP instead of just building a custom apache or using the default distro apache (Fedore 2.6.26.3-29.fc9.i686 #1 SMP Wed Sep 3 03:42:27 EDT 2008 i686 i686 i386 GNU/Linux), I need to find a way to make it work with the current XAMPP install. Thanks, wooD --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Trac Users group. To post to this group, send email to trac-users@googlegroups.com To unsubscribe from this group, send email to trac-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/trac-users?hl=en -~--~~~~--~~--~--~---
[Trac] Re: Setting Trac Locale with mod_wsgi
On Jan 23, 4:37 am, Andrea Tomasini tumm...@gmail.com wrote: On 22 Jan, 2009, at 16:02 , Graham Dumpleton wrote: And what happens if you don't have a trailing slash on: SetEnv trac.env_path /var/www/project/trac/ and leave out TRAC_ENV os.environ setting? Same... same error, without slash and removing all the os.environ from the WSGI script. I have also noticed that in the Trac wiki page for wsgi is not at all mentioned to set environment variables for WSGI using the mod_env (SetEnv directive). Is this something new that requires a specific version of mod_wsgi? I am running debian lenny with mod_wsgi 2.3.* Use of SetEnv is mentioned in: http://code.google.com/p/modwsgi/wiki/IntegrationWithTrac Any page on the Trac wiki isn't going to mention all different possible ways that mod_wsgi can be configured. The mod_wsgi wiki also mentions use of SetEnv in: http://code.google.com/p/modwsgi/wiki/IntegrationWithTrac Trying using first recipe in section at: http://code.google.com/p/modwsgi/wiki/DebuggingTechniques#Tracking_Request_and_Response to wrap Trac application and verify what environment is being passed to Trac. If the correct environment is being passed, then something must be going wrong in Trac. What version of Trac are you using? Graham --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Trac Users group. To post to this group, send email to trac-users@googlegroups.com To unsubscribe from this group, send email to trac-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/trac-users?hl=en -~--~~~~--~~--~--~---
[Trac] Re: Setting Trac Locale with mod_wsgi
On Jan 21, 10:34 pm, Andrea Tomasini tumm...@gmail.com wrote:
Hi there,
I am having problem in passing the right locale to trac using
mod_wsgi, with mod_python it used to work with a PythonOption
directive in the apache configuration, with mod_wsgi, I tried to use
the following:
SetEnv trac.locale en_US.UTF-8
but doesn't seem to have any effect. It also looks like the wsgi
script needs to be loaded with explicit os.environ settings to work.
My actual configuration:
# Define WSGI parameters
WSGIDaemonProcess wsgi-project user=www-data group=www-data threads=25
WSGIScriptAlias / /var/www/project/trac.wsgi
Directory /var/www/project/trac/
WSGIProcessGroup wsgi-project
WSGIApplicationGroup %{GLOBAL}
SetEnv trac.env_path /var/www/project/trac/
SetEnv trac.locale en_US.UTF-8
Order deny,allow
Allow from all
/Directory
and the wsgi script contains:
import os
os.environ['TRAC_ENV'] = '/var/www/project/trac'
os.environ['PYTHON_EGG_CACHE'] = '/var/cache/python'
import trac.web.main
application = trac.web.main.dispatch_request
Looks like without the os.environ apache raises a 500 Internal Error,
and the log sais that Trac needs to have the environment variables set.
I would like to use only one of the two way, and have it working :-)
Ideas?
Can you post the exact error messages from the log.
Graham
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups Trac
Users group.
To post to this group, send email to trac-users@googlegroups.com
To unsubscribe from this group, send email to
trac-users+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/trac-users?hl=en
-~--~~~~--~~--~--~---
[Trac] Re: Trac + pure html pages in single site (and/or suppress Trac webpages features)
On Dec 17, 6:21 am, dmitrey dmitrey.kros...@scipy.org wrote: Hi all, can anyone explain how to do the following: - have a site (for example mysite.org); -www.mysite.orgis a pure html page (because all those Trac issues index by date, download in other formats are not appropriate for the site start page); - pages mysite.org/entry1, mysite.org/entry2, ... etc are Trac wiki pages If hosting with Apache/mod_wsgi and Trac is mounted at root of web site, you can still define: AliasMatch ^/$ /some/path/site-static.html with appropriate exposing of directory containing static file, and the AliasMatch should take precedence for just root URL access and not route it to Trac. What hosting mechanism are you using? Graham --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Trac Users group. To post to this group, send email to trac-users@googlegroups.com To unsubscribe from this group, send email to trac-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/trac-users?hl=en -~--~~~~--~~--~--~---
[Trac] Re: Upgrade to 0.11 on Mac advise needed!
On Nov 21, 9:16 pm, Emmanuel Blot [EMAIL PROTECTED] wrote: Just be aware that Leopard ships with a more than usable Apache 2.2.X, Python 2.5.1 and subversion. AFAIR, it ships with a 1.4.x SVN version. Hopefully, it's quite easy to rebuild SVN 1.5.x (1.5.4) on Leopard. And the feature in the newer version that you must have is? Graham --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Trac Users group. To post to this group, send email to trac-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/trac-users?hl=en -~--~~~~--~~--~--~---
[Trac] Re: Problem setting up track with Apache 2.2
On Nov 19, 10:19 pm, Hendrik Maryns [EMAIL PROTECTED] wrote: On Nov 19, 5:22 am, Graham Dumpleton [EMAIL PROTECTED] wrote: Did you actually look in the Apache error log file to see if there was any useful information? Nope, I am pretty new to Apache as well. Where can I find those? Depends on where/how you have Apache installed. You can try running 'httpd -V'. For Apache 2.2 this will dump out, amongst other stuff: -D HTTPD_ROOT=/usr/local/apache-2.2.4 -D DEFAULT_ERRORLOG=logs/error_log Join the paths together and hopefully you have your error log file. Try setting: PythonDebug On That way any mod_python/Python error will show in browser rather than Apache error log. Ah great. As I had already thought tonight, the problem is a ‘permission denied’, because the trac directory is root-owned. And indeed simply changing its owner to wwwrun solved the issue. Thanks! H. P.S. Is there some way to follow this group in a proper mail/news reader, such as via Gmane? I’d rather not get all the mails but view it in a usenet-like fashion. Have you tried: http://groups.google.com/group/trac-users Graham --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Trac Users group. To post to this group, send email to trac-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/trac-users?hl=en -~--~~~~--~~--~--~---
[Trac] Re: Problem setting up track with Apache 2.2
Did you actually look in the Apache error log file to see if there was any useful information? Try setting: PythonDebug On That way any mod_python/Python error will show in browser rather than Apache error log. Graham On Nov 19, 4:34 am, Hendrik Maryns [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, I am following the instructions athttp://trac.edgewall.org/wiki/TracInstall. My system is openSUSE 11.0, freshly installed, with Apache 2.2.8. The Trac installation is supposed to be here:http://tcl.sfs.uni-tuebingen.de/MonaSearch/trac, but as you can see, you get a 500 error. I put the following in a file which is included in httpd.conf: # Trac configuration added by Hendrik # 18.11.8 # Map the Trac CGI into /MonaSearch/trac/ # ScriptAliasMatch ^/MonaSearch/trac(.*) /cgi-bin/trac.cgi$1 Location /MonaSearch/trac SetHandler mod_python PythonInterpreter main_interpreter PythonHandler trac.web.modpython_frontend PythonOption TracEnv /home/server/svn/trac # PythonOption TracUriRoot /MonaSearch/trac # PythonOption PYTHON_EGG_CACHE /home/server/svn/trac/egg-cache /Location mod_python seems to be installed correctly, since I the test on the TracInstall page worked. What could be going wrong here? Also, the first line is commented out since I didn’t find a file called trac.cgi anywhere, and I obviously had to change the path from the Windows path in the FAQ. I did trac-admin . initenv in /home/server/svn/trac, I suppose that is the directory it is supposed to point at (I find TracInstall not very clear on this point). Please ask for more information, if needed. TIA. H. - -- Hendrik Maryns Herrenberger Straße 40 D-72070 Tübingen +49707143783http://tcl.sfs.uni-tuebingen.de/~hendrik/ =www.lieverleven.be Hier kan iedereen wat van leren. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with SUSE -http://enigmail.mozdev.org iEYEARECAAYFAkki/LQACgkQBGFP0CTku6PvvwCfaWOpUDa3L4WjOctxB4Lo8DvH ylEAoK1oNOu+JvYiOjm9WiM4w8dsriBn =HbCR -END PGP SIGNATURE- --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Trac Users group. To post to this group, send email to trac-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/trac-users?hl=en -~--~~~~--~~--~--~---
[Trac] Re: add authentication to wsgi?
On Nov 8, 11:12 am, Neal Becker [EMAIL PROTECTED] wrote: How do I add trac auth to wsgi? And what do you mean by this? Will save us having to guess from number of possibilities as to what you might mean. Graham --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Trac Users group. To post to this group, send email to trac-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/trac-users?hl=en -~--~~~~--~~--~--~---
[Trac] Re: issue w/ Apache+mod_wsgi+svn and multiple Trac instances
On Nov 4, 6:16 am, Antti Kaihola [EMAIL PROTECTED] wrote:
I'm having the
RuntimeError: instance.__dict__ not accessible in restricted mode
problem mentioned in the FAQ and the TracSubversion wiki page.
However, this is onmod_wsgiinstead of mod_python. The software
versions are:
* Debian 4.0 Etch
* Apache 2.2.3
* Python 2.4.4
* Subversion 1.4.2
I'm running
* Trac instance tracmain with multiple Trac sites
* Trac instance tracsingle with a single Trac site
(which is one of the sites in instance tracmain)
At first both Trac instances work fine, but after some time one of them
starts to fail with the runtime error.
Things I've tried:
* removing authentication directives temporarily from the Apache
settings
* mpm-prefork and mpm-worker
* same and different application group (also %{GLOBAL} for both)
* same and different process group
* same and different egg cache directory
After every change to the settings I always first stop then start
Apache. Nothing I've tried has made the problem go away yet.
I'm running out of ideas after reading through and trying all the
tricks mentioned in related Trac tickets,mod_wsgidocumentation and
mailing list messages.
Here is my configuration:
/etc/apache2/sites-available/tracmain
VirtualHost *
ServerName trac.mydomain.com
WSGIDaemonProcess trac user=www-data group=www-data threads=25
WSGIScriptAlias / /var/lib/trac/apache/tracmain/trac.wsgi
Directory /var/lib/trac/apache/tracmain/trac.wsgi
Make it the directory the file is in, not the file itself.
Graham
WSGIProcessGroup trac
WSGIApplicationGroup %{GLOBAL}
Order deny,allow
Allow from all
/Directory
Location /*/login
AuthType Basic
AuthName Main Trac site
AuthUserFile /var/lib/trac/users.htpasswd
Require valid-user
/Location
LogLevel warn
CustomLog /var/log/apache2/tracmain.access.log combined
ServerSignature On
/VirtualHost
/etc/apache2/sites-available/tracsingle
VirtualHost *
ServerName tracsingle.mydomain.com
WSGIDaemonProcess tracsingle user=www-data group=www-data threads=25
WSGIScriptAlias / /var/lib/trac/apache/tracsingle/trac.wsgi
Directory /var/lib/trac/apache/tracsingle/trac.wsgi
WSGIProcessGroup trac
WSGIApplicationGroup %{GLOBAL}
Order deny,allow
Allow from all
/Directory
Location /login
AuthType Basic
AuthName Trac Site
AuthUserFile /var/lib/trac/users.htpasswd
Require valid-user
/Location
LogLevel warn
CustomLog /var/log/apache2/tracsingle.access.log combined
ServerSignature On
/VirtualHost
/var/lib/trac/apache/tracmain/trac.wsgi
import sys
sys.stdout = sys.stderr
import os
os.environ['PYTHON_EGG_CACHE'] = '/var/lib/trac/.python-eggs/tracmain'
import trac.web.main
def application(environ, start_response):
environ['trac.env_parent_dir'] = '/var/lib/trac'
return trac.web.main.dispatch_request(environ, start_response)
/var/lib/trac/apache/tracsingle/trac.wsgi
import sys
sys.stdout = sys.stderr
import os
os.environ['PYTHON_EGG_CACHE'] = '/var/lib/trac/.python-eggs/tracsingle'
import trac.web.main
def application(environ, start_response):
environ['trac.env_path'] = '/var/lib/trac/tracsingle'
return trac.web.main.dispatch_request(environ, start_response)
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups Trac
Users group.
To post to this group, send email to trac-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/trac-users?hl=en
-~--~~~~--~~--~--~---
[Trac] Re: issue w/ Apache+mod_wsgi+svn and multiple Trac instances
More comments below.
On Nov 4, 8:16 am, Graham Dumpleton [EMAIL PROTECTED]
wrote:
On Nov 4, 6:16 am, Antti Kaihola [EMAIL PROTECTED] wrote:
I'm having the
RuntimeError: instance.__dict__ not accessible in restricted mode
problem mentioned in the FAQ and the TracSubversion wiki page.
However, this is onmod_wsgiinstead of mod_python. The software
versions are:
* Debian 4.0 Etch
* Apache 2.2.3
* Python 2.4.4
* Subversion 1.4.2
I'm running
* Trac instance tracmain with multiple Trac sites
* Trac instance tracsingle with a single Trac site
(which is one of the sites in instance tracmain)
At first both Trac instances work fine, but after some time one of them
starts to fail with the runtime error.
Things I've tried:
* removing authentication directives temporarily from the Apache
settings
* mpm-prefork and mpm-worker
* same and different application group (also %{GLOBAL} for both)
* same and different process group
* same and different egg cache directory
After every change to the settings I always first stop then start
Apache. Nothing I've tried has made the problem go away yet.
I'm running out of ideas after reading through and trying all the
tricks mentioned in related Trac tickets,mod_wsgidocumentation and
mailing list messages.
Here is my configuration:
/etc/apache2/sites-available/tracmain
VirtualHost *
ServerName trac.mydomain.com
WSGIDaemonProcess trac user=www-data group=www-data threads=25
WSGIScriptAlias / /var/lib/trac/apache/tracmain/trac.wsgi
Directory /var/lib/trac/apache/tracmain/trac.wsgi
Make it the directory the file is in, not the file itself.
Graham
WSGIProcessGroup trac
WSGIApplicationGroup %{GLOBAL}
Order deny,allow
Allow from all
/Directory
Location /*/login
AuthType Basic
AuthName Main Trac site
AuthUserFile /var/lib/trac/users.htpasswd
Require valid-user
/Location
LogLevel warn
CustomLog /var/log/apache2/tracmain.access.log combined
ServerSignature On
/VirtualHost
/etc/apache2/sites-available/tracsingle
VirtualHost *
ServerName tracsingle.mydomain.com
WSGIDaemonProcess tracsingle user=www-data group=www-data threads=25
WSGIScriptAlias / /var/lib/trac/apache/tracsingle/trac.wsgi
Directory /var/lib/trac/apache/tracsingle/trac.wsgi
Same again here.
WSGIProcessGroup trac
You meant 'tracsingle' not 'trac' for WSGIProcessGroup here, else not
in separate daemon process.
Graham
WSGIApplicationGroup %{GLOBAL}
Order deny,allow
Allow from all
/Directory
Location /login
AuthType Basic
AuthName Trac Site
AuthUserFile /var/lib/trac/users.htpasswd
Require valid-user
/Location
LogLevel warn
CustomLog /var/log/apache2/tracsingle.access.log combined
ServerSignature On
/VirtualHost
/var/lib/trac/apache/tracmain/trac.wsgi
import sys
sys.stdout = sys.stderr
import os
os.environ['PYTHON_EGG_CACHE'] = '/var/lib/trac/.python-eggs/tracmain'
import trac.web.main
def application(environ, start_response):
environ['trac.env_parent_dir'] = '/var/lib/trac'
return trac.web.main.dispatch_request(environ, start_response)
/var/lib/trac/apache/tracsingle/trac.wsgi
import sys
sys.stdout = sys.stderr
import os
os.environ['PYTHON_EGG_CACHE'] = '/var/lib/trac/.python-eggs/tracsingle'
import trac.web.main
def application(environ, start_response):
environ['trac.env_path'] = '/var/lib/trac/tracsingle'
return trac.web.main.dispatch_request(environ, start_response)
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups Trac
Users group.
To post to this group, send email to trac-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/trac-users?hl=en
-~--~~~~--~~--~--~---
[Trac] Re: No response from Trac 0.11.1 - Windows2000svr - Apache2.2.10 - SVN1.5.3
On Oct 28, 9:53 am, Felix Collins [EMAIL PROTECTED] wrote: Does anyone have any ideas about how to get debug information out of python running under mod_python ormod_wsgi? I'm still as stuck as I was in the previous post. I have tried running undermod_wsgiand get the same problem so it seem to be a crash of the python interpreter before it can log anything. See: http://code.google.com/p/modwsgi/wiki/DebuggingTechniques Also have a look though: http://code.google.com/p/modwsgi/wiki/ApplicationIssues as it describes a range of common problems that can occur, some of which can cause crashes. Graham --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Trac Users group. To post to this group, send email to trac-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/trac-users?hl=en -~--~~~~--~~--~--~---
[Trac] Re: Is Trac multi-threaded ?
On Oct 23, 6:58 am, Noah Kantrowitz [EMAIL PROTECTED] wrote: No, Python in general does not benefit from parallelism very much. Trac is also not generally very CPU intensive. Postgres, on the other hand, can very much take advantage of that so if you see your postgres workers using the entire CPU it might help. True, with the caveat that depending on what web hosting mechanism you use, multiple cores can still be harnessed by a Trac instance. In particular, Apache on UNIX is a multiprocess web server and if you use mod_python or mod_wsgi your Trac instance is actually running across multiple processes, so requests which end up being served by different processes can quite happily run at the same time on different CPUs or cores. If you configure FASTCGI appropriately, you can get the same benefits there as well. Also, in Apache all the network I/O handling is done at C code level by Apache with the GIL unlocked. Thus the actual I/O for concurrent requests in the same process can quite happily be running on different CPUs or cores. For more on how the GIL is not a being a problem as people make out when using Apache, see: http://blog.dscpl.com.au/2007/07/web-hosting-landscape-and-modwsgi.html Graham -Original Message- From: trac-users@googlegroups.com [mailto:[EMAIL PROTECTED] On Behalf Of TJ Yang Sent: Wednesday, October 22, 2008 12:24 PM To: Trac Users Subject: [Trac] Is Trac multi-threaded ? Will Multi-core CPU help Trac run faster ? or should I ask if Trac's python code multi-threaded ? tj --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Trac Users group. To post to this group, send email to trac-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/trac-users?hl=en -~--~~~~--~~--~--~---
[Trac] Re: AccountManager woes
Doubt that version of mod_wsgi here is the problem if they had the problem with tracd as well. If it was just mod_wsgi and AccountManager uses sessions/cookies, then would be asking what version of Python is being used. Debian broke md5 stuff in some versions in as much as if PHP mhash is loaded at same time, can cause problems like what is being see. See: http://code.google.com/p/modwsgi/wiki/ApplicationIssues#Python_MD5_Hash_Module_Conflict Since though tracd affected, then would have to be something in Trac or Trac setup itself. Graham On Oct 1, 1:50 am, Eric Shubert [EMAIL PROTECTED] wrote: Robert C Corsaro wrote: I setup AccountManager trunk with Trac-0.11-stable from svn. It seems to be authenticated alright, but when it's done it I'm still not logged in. I know it's authing because if I provide the wrong user/pass, I get an error. If I log in with proper user/pass, I still have the login link at the top of the page and no permission. I've tried several auth stores to no avail. I'm running it viamod_wsgi, but had the same problem with tracd. This is a very vanilla setup. Is there something else I should use other then trunk? Can I use AccountManager with Trac-0.11-stable? Is this some redirect issue? * Trac-0.11-stable from svn * AccountManager trunk from trac-hacks svn *mod_wsgi-2.1 * apache-2.2.9-r1 Have you visitedhttp://trac.edgewall.org/wiki/TracModWSGI?It says: Important note: Please use either version 1.3 or 2.3 or later ofmod_wsgi. Version 2.0 has problems with downloading attachments (see #7205). No warning about logins though. FWIW I'm running trac-0.11.1-1.el5.rf with the latest AccountManager trunk (r3857) with no problems. I'm running mod_python though, with httpd-2.2.3-11.el5_1.centos.3. I know that's not much help, but I hope it points you in the right direction. -- -Eric 'shubes' --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Trac Users group. To post to this group, send email to trac-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/trac-users?hl=en -~--~~~~--~~--~--~---
[Trac] Re: internal server error
On Sep 5, 7:42 am, rjcarr [EMAIL PROTECTED] wrote: I have an existing (and fully functional) 0.10.4 database that I'm migrating to a new server running 0.10.5. The setup of the old and new server should be identical ... it isn't that complicated. The new server is Fedora 9 (the old server is Fedora 7). The new server is using httpd and subversion from the install DVD. I installed trac with yum (which also installed python-clearsilver). The httpd server is run as apache. Subversion is served through apache and works fine (both from svn clients and web browsing the files). Trac is served through apache using mod_python. Here's the entry: Location /trac SetHandler mod_python PythonInterpreter main_interpreter PythonHandler trac.web.modpython_frontend PythonOption TracEnvParentDir /var/www/trac PythonOption TracUriRoot /trac /Location I was sure to set all the permissions in that /var/www/trac folder to apache. I also made sure the SELinux tags were set appropriately. When I browse to the correct page, I get this: Internal Server Error 500 Internal Server Error (The user username requires read _and_ write permission to the database file /var/www/trac/admin/db/trac.db and the directory it is located in.) Where 'username' is the name of the user that is logged into the server and started apache. Yes, that is strange ... it isn't apache but the user that logged into the server, before switching to root, to start apache. Probably because you restarted Apache using: sudo /usr/sbin/apachectl start or similar, instead of: sudo -H /usr/sbin/apachectl start If you don't use -H option to sudo it will inherit parts of user environment for user who rang sudo. This can actually cause a lot of problems at times because things might appear to work, but when box reboots and Apache started as root, without those parts of the user environment application may fail. If I log in as root to start apache the username is root. Strangely, I get the same error, even though root should have permission to everything. However, just to test I did what it asked and made root the owner of all the files and gave everyone write permission and got the same error, so I think it is a misleading error and something else is going wrong. The error is still misleading as Apache will switch to run as Apache user. In doing that though, some parts of the environment may still reflect that Apache was originally started as root. Any file permissions must be such that Apache user has read/write access as appropriate, not root. What you may be better off doing is run Apache/mod_wsgi rather than mod_python. For that you can use daemon mode of mod_wsgi and have daemon process running Trac run as non root, not Apache user, ie., normal user account. This can make it easier as you don't have to keep changing file permissions but can leave them all as user used to setup Trac instance in the first place. Graham Checking the apache logs there is nothing that is interesting from what I can tell, but I'd be happy to share. I am completely stumped. I first thought it was because I was trying to use a migrated database so I tried to upgrade the database, and it said: Database is up to date, no upgrade necessary. I then thought it was just the environment in some other way, so I created a new environment with initenv and got the same exact error. I then thought it could be a problem with accessing the database (since I didn't install sqlite) but in doing a trac-admin list I was able to get the right contents out. So ... I have no idea what to do. I've been using trac for years and this is the first time I've had a serious problem. My last resort, if I get no help, is to go back to using 0.10.4 (assuming that is the problem), but I'd like to avoid doing that. I can't upgrade to 0.11 at the moment, so that isn't an option either. Thanks, any advice is helpful. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Trac Users group. To post to this group, send email to trac-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/trac-users?hl=en -~--~~~~--~~--~--~---
[Trac] Re: internal server error
On Sep 5, 12:12 pm, Robert J. Carr [EMAIL PROTECTED] wrote: Hey Graham- Thanks so much for the response. Here are some notes: Probably because you restarted Apache using: sudo /usr/sbin/apachectl start or similar, instead of: sudo -H /usr/sbin/apachectl start Neither, I always use /etc/init.d/httpd start|stop and always as root (not sudo). Anything enlightening with this new information? But how do you become root? Which command, whether it be apachectl or init.d script is not the issue here. problems at times because things might appear to work, but when box reboots and Apache started as root, without those parts of the user environment application may fail. That's exactly why I always use /etc/init.d because that's what is used when the system starts. As I said, it will not make a difference, if you were to go: sudo /etc/init.d/httpd start you would have exactly the same problem. So we get back to how you become root. If the way you become root means that proper root shell distinct from user is created there is no way that it can inherit identity of original user in environment in some way. So, you may not use 'sudo', but if you use 'su' without '-l' flag same issues may arise. Depending on system used there may possibly be other ways of becoming root. Whatever is used, it must perform a full login or have the same effect. As to your SELinux configuration problems, maybe you can learn something from: http://www.packtpub.com/article/selinux-secured-web-hosting-python-based-web-applications Graham --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Trac Users group. To post to this group, send email to trac-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/trac-users?hl=en -~--~~~~--~~--~--~---
[Trac] Re: installing Subversion SWIG bindings in a virtualenv?
On Aug 27, 9:57 am, Olaf Meeuwissen [EMAIL PROTECTED] wrote:
Graham Dumpleton [EMAIL PROTECTED] writes:
In the WSGI script file, add:
import sys
print sys.stderr, str(sys.path)
This will cause value of sys.path to be logged to Apache error log. Go
through what is dumped out to just make sure that .pth files contents
added correctly and that all the other directories added look
reasonable and refer to your virtual environment.
Thanks for the tip. Did that and here is what ends up in my Apache
error log:
[Wed Aug 27 08:45:58 2008] [error]
['/path/to/WSGIHome/lib/python2.5/site-packages/setuptools-0.6c8-py2.5.egg' ,
'/path/to/WSGIHome/lib/python2.5/site-packages/Pygments-0.10-py2.5.egg',
'/path/to/WSGIHome/lib/python2.5/site-packages/pytz-2008c-py2.5.egg',
'/path/to/SandBox/lib/python2.5/site-packages/setuptools-0.6c8-py2.5.egg',
'/path/to/SandBox/lib/python2.5/site-packages/pysqlite-2.4.1-py2.5-linux-i6
86.egg',
'/path/to/SandBox/lib/python2.5/site-packages/Trac-0.11.1-py2.5.egg',
'/path/to/SandBox/lib/python2.5/site-packages/Genshi-0.5.1-py2.5-linux-i686
.egg', '/path/to/WSGIHome/lib/python2.5',
'/path/to/WSGIHome/lib/python2.5/plat-linux2',
'/path/to/WSGIHome/lib/python2.5/lib-tk',
'/path/to/WSGIHome/lib/python2.5/lib-dynload', '/usr/lib/python2.5',
'/usr/lib/python2.5/lib-tk', '/path/to/WSGIHome/lib/python2.5/site-packages',
'/path/to/SandBox/lib/python2.5/site-packages',
'/usr/share/python-support/python-subversion']
My WSGIPythonHome is set to /path/to/WSGIHome which is a symlink
pointing to a --no-site-packages virtualenv. I use the symlink so I
can switch easily between virtualenvs w/ and w/o site packages. The
/path/to/SandBox is another no-site-packages virtualenv and here's
where I added a python-subversion.pth with the contents shown by the
last element of the sys.path.
How in your configuration are you getting:
/path/to/SandBox/lib/python2.5/site-packages
added to sys.path?
If this contains .pth files you can't just use:
sys.path.append()
as that doesn't result in .pth files being parsed with content added
to sys.path in the process.
So, post exact details of the following.
1. Version of mod_wsgi.
2. What WSGIPythonHome and WSGIPythonPath are set to in Apache
configuration.
3. Whether you are using WSGIDaemonProcess or WSGIProcessGroup and if
so what they are set to.
4. What 'ls -las' output is on your sandbox site packages directory.
5. The contents of the .pth files in that sandbox site packages
directory.
6. What your WSGI script file is doing in respect of manipulations of
sys.path or calls to site.addsitedir().
Graham
Still, I get an error message in the browser and the following in my
trac.log:
2008-08-27 08:45:57,961 Trac[svn_fs] INFO: Failed to load Subversion
bindings
Traceback (most recent call last):
File
/path/to/SandBox/lib/python2.5/site-packages/Trac-0.11.1-py2.5.egg/trac/ve
rsioncontrol/svn_fs.py, line 253, in __init__
_import_svn()
File
/path/to/SandBox/lib/python2.5/site-packages/Trac-0.11.1-py2.5.egg/trac/ve
rsioncontrol/svn_fs.py, line 69, in _import_svn
from svn import fs, repos, core, delta
File /usr/share/python-support/python-subversion/svn/fs.py, line 19, in
module
from libsvn.fs import *
File /usr/share/python-support/python-subversion/libsvn/fs.py, line 7,
in module
import _fs
ImportError: No module named _fs
I'm clueless. Anyone have any ideas?
Graham
On Aug 26, 9:38 am, Olaf Meeuwissen [EMAIL PROTECTED] wrote:
Sorry, meant to get back to this earlier but work got in the way.
osimons [EMAIL PROTECTED] writes:
On Aug 21, 5:02 am, Olaf Meeuwissen [EMAIL PROTECTED] wrote:
Is there an easy way to install the Subversion SWIG bindings in a
virtualenv, or two?
Install the Subversion bindings against your correct main Python as
usual,
That would be `apt-get install python-subversion` in my case. Note
that this package installs the *.py files and the native .so libs in
different places.
*.py in /usr/share/python-support/python-subversion/{svn,libsvn}
*.so in /usr/lib/python-support/python-subversion/python2.[45]/libsvn
The libsvn_swig_py2.[45] .so's are in /usr/lib/.
and in each virtualenv sitepackages derived from this Python
add a .pth file that points to location of svn libraries.
Like,
$ echo /opt/local/lib/svn-python2.4 /path/to/my/virutalenv/lib/
python2.4/site-packages/svn-python.pth
Did that.
$ cat /path/to/virtualenv/lib/python2.5/site-packages/svn-python.pth
/usr/lib/python-support/python-subversion/python2.5
/usr/lib/python-support/python-subversion
/usr/share/python-support/python-subversion
Restarted apache2 and fired up a new browser for good measure.
(My /opt/local/lib/svn-python2.4 contains the directories 'svn' and
'libsvn')
Unfortunately, that didn't work.
Here's (what I think
[Trac] Re: installing Subversion SWIG bindings in a virtualenv?
On Aug 27, 2:54 pm, Olaf Meeuwissen [EMAIL PROTECTED] wrote:
Graham Dumpleton [EMAIL PROTECTED] writes:
On Aug 27, 9:57 am, Olaf Meeuwissen [EMAIL PROTECTED] wrote:
Graham Dumpleton [EMAIL PROTECTED] writes:
In the WSGI script file, add:
import sys
print sys.stderr, str(sys.path)
This will cause value of sys.path to be logged to Apache error log. Go
through what is dumped out to just make sure that .pth files contents
added correctly and that all the other directories added look
reasonable and refer to your virtual environment.
Thanks for the tip. Did that and here is what ends up in my Apache
error log:
[Wed Aug 27 08:45:58 2008] [error]
['/path/to/WSGIHome/lib/python2.5/site-packages/setuptools-0.6c8-py2.5.egg'
,
'/path/to/WSGIHome/lib/python2.5/site-packages/Pygments-0.10-py2.5.egg',
'/path/to/WSGIHome/lib/python2.5/site-packages/pytz-2008c-py2.5.egg',
'/path/to/SandBox/lib/python2.5/site-packages/setuptools-0.6c8-py2.5.egg',
'/path/to/SandBox/lib/python2.5/site-packages/pysqlite-2.4.1-py2.5-linux-i6
86.egg',
'/path/to/SandBox/lib/python2.5/site-packages/Trac-0.11.1-py2.5.egg',
'/path/to/SandBox/lib/python2.5/site-packages/Genshi-0.5.1-py2.5-linux-i686
.egg', '/path/to/WSGIHome/lib/python2.5',
'/path/to/WSGIHome/lib/python2.5/plat-linux2',
'/path/to/WSGIHome/lib/python2.5/lib-tk',
'/path/to/WSGIHome/lib/python2.5/lib-dynload', '/usr/lib/python2.5',
'/usr/lib/python2.5/lib-tk',
'/path/to/WSGIHome/lib/python2.5/site-packages',
'/path/to/SandBox/lib/python2.5/site-packages',
'/usr/share/python-support/python-subversion']
My WSGIPythonHome is set to /path/to/WSGIHome which is a symlink
pointing to a --no-site-packages virtualenv. I use the symlink so I
can switch easily between virtualenvs w/ and w/o site packages. The
/path/to/SandBox is another no-site-packages virtualenv and here's
where I added a python-subversion.pth with the contents shown by the
last element of the sys.path.
How in your configuration are you getting:
/path/to/SandBox/lib/python2.5/site-packages
added to sys.path?
The same way as /path/to/WSGIHome/lib/python2.5/site-packages, I'd
presume. That is, I have no clue, really. I think virtualenv and/or
easy_install automagically take care of that.
If this contains .pth files you can't just use:
sys.path.append()
as that doesn't result in .pth files being parsed with content added
to sys.path in the process.
The /path/to/SandBox/lib/python2.5/site-packages directory contains a
.pth file with the following contents:
/usr/share/python-support/python-subversion
You previously indicated locations as:
*.py in /usr/share/python-support/python-subversion/{svn,libsvn}
*.so in /usr/lib/python-support/python-subversion/python2.[45]/
libsvn
And that you had:
$ cat /path/to/virtualenv/lib/python2.5/site-packages/svn-
python.pth
/usr/lib/python-support/python-subversion/python2.5
/usr/lib/python-support/python-subversion
/usr/share/python-support/python-subversion
Shouldn't the directory containing the .so files, ie.,
/usr/lib/python-support/python-subversion/python2.5
still be in the .pth file? You now only have:
/usr/share/python-support/python-subversion
which would mean only .py files would be found.
Yes/No?
Graham
so it seems to get added allright.
So, post exact details of the following.
1. Version of mod_wsgi.
$ dpkg-query -W libapache2-mod-wsgi
libapache2-mod-wsgi 2.1-2
$
2. What WSGIPythonHome and WSGIPythonPath are set to in Apache
configuration.
$ grep -r WSGIPythonHome /etc/apache2/sites-enabled/
/etc/apache2/sites-enabled/WSGIHome:WSGIPythonHome /path/to/WSGIHome
$ grep -r WSGIPythonPath /etc/apache2/sites-enabled/
$
3. Whether you are using WSGIDaemonProcess or WSGIProcessGroup and if
so what they are set to.
$ grep -A3 WSGIDaemonProcess /etc/apache2/sites-enabled/SandBox
WSGIDaemonProcess SandBox user=olaf group=olaf \
threads=15 maximum-requests=1 \
python-path=/path/to/SandBox/lib/python2.5/site-packages
$ grep WSGIProcessGroup /etc/apache2/sites-enabled/SandBox
WSGIProcessGroup SandBox
$
4. What 'ls -las' output is on your sandbox site packages directory.
$ ls -las /path/to/SandBox/lib/python2.5/site-packages/
total 356
4 drwxr-xr-x 5 olaf olaf 4096 2008-08-27 08:25 .
4 drwxr-xr-x 4 olaf olaf 4096 2008-08-21 16:25 ..
4 drwxr-xr-x 4 olaf olaf 4096 2008-08-21 16:26
Genshi-0.5.1-py2.5-linux-i686.egg
4 drwxr-xr-x 4 olaf olaf 4096 2008-08-21 16:26 Trac-0.11.1-py2.5.egg
4 -rw-r--r-- 1 olaf olaf 312 2008-08-21 16:26 easy-install.pth
4 drwxr-xr-x 5 olaf olaf 4096 2008-08-21 16:26
pysqlite-2.4.1-py2.5-linux-i686.egg
4 -rw-r--r-- 1 olaf olaf 44 2008-08-27 08:45 python-subversion.pth
324 -rw-r--r-- 1 olaf olaf 324858 2008-05-21 06:20
setuptools-0.6c8-py2.5.egg
4
[Trac] Re: installing Subversion SWIG bindings in a virtualenv?
More below.
On Aug 27, 3:33 pm, Graham Dumpleton [EMAIL PROTECTED]
wrote:
On Aug 27, 2:54 pm, Olaf Meeuwissen [EMAIL PROTECTED] wrote:
Graham Dumpleton [EMAIL PROTECTED] writes:
On Aug 27, 9:57 am, Olaf Meeuwissen [EMAIL PROTECTED] wrote:
Graham Dumpleton [EMAIL PROTECTED] writes:
In the WSGI script file, add:
import sys
print sys.stderr, str(sys.path)
This will cause value of sys.path to be logged to Apache error log. Go
through what is dumped out to just make sure that .pth files contents
added correctly and that all the other directories added look
reasonable and refer to your virtual environment.
Thanks for the tip. Did that and here is what ends up in my Apache
error log:
[Wed Aug 27 08:45:58 2008] [error]
['/path/to/WSGIHome/lib/python2.5/site-packages/setuptools-0.6c8-py2.5.egg'
,
'/path/to/WSGIHome/lib/python2.5/site-packages/Pygments-0.10-py2.5.egg',
'/path/to/WSGIHome/lib/python2.5/site-packages/pytz-2008c-py2.5.egg',
'/path/to/SandBox/lib/python2.5/site-packages/setuptools-0.6c8-py2.5.egg',
'/path/to/SandBox/lib/python2.5/site-packages/pysqlite-2.4.1-py2.5-linux-i6
86.egg',
'/path/to/SandBox/lib/python2.5/site-packages/Trac-0.11.1-py2.5.egg',
'/path/to/SandBox/lib/python2.5/site-packages/Genshi-0.5.1-py2.5-linux-i686
.egg', '/path/to/WSGIHome/lib/python2.5',
'/path/to/WSGIHome/lib/python2.5/plat-linux2',
'/path/to/WSGIHome/lib/python2.5/lib-tk',
'/path/to/WSGIHome/lib/python2.5/lib-dynload', '/usr/lib/python2.5',
'/usr/lib/python2.5/lib-tk',
'/path/to/WSGIHome/lib/python2.5/site-packages',
'/path/to/SandBox/lib/python2.5/site-packages',
'/usr/share/python-support/python-subversion']
My WSGIPythonHome is set to /path/to/WSGIHome which is a symlink
pointing to a --no-site-packages virtualenv. I use the symlink so I
can switch easily between virtualenvs w/ and w/o site packages. The
/path/to/SandBox is another no-site-packages virtualenv and here's
where I added a python-subversion.pth with the contents shown by the
last element of the sys.path.
How in your configuration are you getting:
/path/to/SandBox/lib/python2.5/site-packages
added to sys.path?
The same way as /path/to/WSGIHome/lib/python2.5/site-packages, I'd
presume. That is, I have no clue, really. I think virtualenv and/or
easy_install automagically take care of that.
If this contains .pth files you can't just use:
sys.path.append()
as that doesn't result in .pth files being parsed with content added
to sys.path in the process.
The /path/to/SandBox/lib/python2.5/site-packages directory contains a
.pth file with the following contents:
/usr/share/python-support/python-subversion
You previously indicated locations as:
*.py in /usr/share/python-support/python-subversion/{svn,libsvn}
*.so in /usr/lib/python-support/python-subversion/python2.[45]/
libsvn
And that you had:
$ cat /path/to/virtualenv/lib/python2.5/site-packages/svn-
python.pth
/usr/lib/python-support/python-subversion/python2.5
/usr/lib/python-support/python-subversion
/usr/share/python-support/python-subversion
Shouldn't the directory containing the .so files, ie.,
/usr/lib/python-support/python-subversion/python2.5
still be in the .pth file? You now only have:
/usr/share/python-support/python-subversion
which would mean only .py files would be found.
Yes/No?
BTW, my questions may be answered if you can do:
$ python
Python 2.3.5 (#1, Nov 23 2005, 12:05:23)
[GCC 3.3.2] on sunos5
Type help, copyright, credits or license for more information.
import libsvn
libsvn.__file__
'/usr/local/sys/python/local/lib/python2.3/site-packages/libsvn/
__init__.py'
import svn
svn.__file__
'/usr/local/sys/python/local/lib/python2.3/site-packages/svn/
__init__.py'
and show what you get.
One other possibility is that .so can be found but library
dependencies cant be found. I would though expect different Python
exception, but if subversion bindings are masking the true error, this
might be problem.
Thus, run for your paths:
ldd /usr/local/sys/python/local/lib/python2.3/site-packages/libsvn/
*.so
as the user that the mod_wsgi daemon process would run as.
Graham
Graham
so it seems to get added allright.
So, post exact details of the following.
1. Version of mod_wsgi.
$ dpkg-query -W libapache2-mod-wsgi
libapache2-mod-wsgi 2.1-2
$
2. What WSGIPythonHome and WSGIPythonPath are set to in Apache
configuration.
$ grep -r WSGIPythonHome /etc/apache2/sites-enabled/
/etc/apache2/sites-enabled/WSGIHome:WSGIPythonHome /path/to/WSGIHome
$ grep -r WSGIPythonPath /etc/apache2/sites-enabled/
$
3. Whether you are using WSGIDaemonProcess or WSGIProcessGroup and if
so what they are set to.
$ grep -A3 WSGIDaemonProcess /etc/apache2/sites-enabled/SandBox
WSGIDaemonProcess SandBox user=olaf
[Trac] Version 2.3 of mod_wsgi is now available
I would not usually post such an announcement on Trac users list, but since this update fixes a specific issue which was resulting in data truncation for Trac users on Windows and UNIX/Apache 1.3, due to Trac's use of mod_wsgi wsgi.file_wrapper extension, thought it might be good idea to give you all good warning. Version 2.3 of mod_wsgi is now available. The software and documentation are both available from: http://www.modwsgi.org Version 2.3 of mod_wsgi is a bug fix update. The most important of the bug fixes addresses a data truncation issue when using wsgi.file_wrapper extension (on Windows or Apache 1.3 on UNIX) with file objects. Data truncation could also occur for all deployment configurations for any other file like objects used with wsgi.file_wrapper. It is highly recommended that if you are using version 2.0 or 2.1 of mod_wsgi that you upgrade, especially if using web applications, such as Trac, which make use of the wsgi.file_wrapper extension. Note that version 2.3 of mod_wsgi was a quick fire release to fix issues caused in version 2.2 release which preceded 2.3 by a day or so. If you have already obtained version 2.2 of mod_wsgi, you should ensure you upgrade to version 2.3. A description of changes in version 2.2/2.3 can be found in the change notes at: http://code.google.com/p/modwsgi/wiki/ChangesInVersion0202 http://code.google.com/p/modwsgi/wiki/ChangesInVersion0203 If you have any questions about mod_wsgi or wish to provide feedback, use the Google group for mod_wsgi found at: http://groups.google.com/group/modwsgi Enjoy Graham Dumpleton --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Trac Users group. To post to this group, send email to trac-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/trac-users?hl=en -~--~~~~--~~--~--~---
[Trac] Re: installing Subversion SWIG bindings in a virtualenv?
In the WSGI script file, add:
import sys
print sys.stderr, str(sys.path)
This will cause value of sys.path to be logged to Apache error log. Go
through what is dumped out to just make sure that .pth files contents
added correctly and that all the other directories added look
reasonable and refer to your virtual environment.
Graham
On Aug 26, 9:38 am, Olaf Meeuwissen [EMAIL PROTECTED] wrote:
Sorry, meant to get back to this earlier but work got in the way.
osimons [EMAIL PROTECTED] writes:
On Aug 21, 5:02 am, Olaf Meeuwissen [EMAIL PROTECTED] wrote:
Is there an easy way to install the Subversion SWIG bindings in a
virtualenv, or two?
Install the Subversion bindings against your correct main Python as
usual,
That would be `apt-get install python-subversion` in my case. Note
that this package installs the *.py files and the native .so libs in
different places.
*.py in /usr/share/python-support/python-subversion/{svn,libsvn}
*.so in /usr/lib/python-support/python-subversion/python2.[45]/libsvn
The libsvn_swig_py2.[45] .so's are in /usr/lib/.
and in each virtualenv sitepackages derived from this Python
add a .pth file that points to location of svn libraries.
Like,
$ echo /opt/local/lib/svn-python2.4 /path/to/my/virutalenv/lib/
python2.4/site-packages/svn-python.pth
Did that.
$ cat /path/to/virtualenv/lib/python2.5/site-packages/svn-python.pth
/usr/lib/python-support/python-subversion/python2.5
/usr/lib/python-support/python-subversion
/usr/share/python-support/python-subversion
Restarted apache2 and fired up a new browser for good measure.
(My /opt/local/lib/svn-python2.4 contains the directories 'svn' and
'libsvn')
Unfortunately, that didn't work.
Here's (what I think is) the relevant piece of the log:
2008-08-26 08:25:48,471 Trac[svn_fs] INFO: Failed to load Subversion
bindings
Traceback (most recent call last):
File
/path/to/virtualenv/lib/python2.5/site-packages/Trac-0.11.1-py2.5.egg/trac
/versioncontrol/svn_fs.py, line 253, in __init__
_import_svn()
File
/path/to/virtualenv/lib/python2.5/site-packages/Trac-0.11.1-py2.5.egg/trac
/versioncontrol/svn_fs.py, line 69, in _import_svn
from svn import fs, repos, core, delta
File /usr/share/python-support/python-subversion/svn/fs.py, line 19, in
module
from libsvn.fs import *
File /usr/share/python-support/python-subversion/libsvn/fs.py, line 7,
in module
import _fs
ImportError: No module named _fs
FWIW, I'm using virtualenv-1.1 and using a virtualenv with site
packages (that is, created without the --no-site-packages option) as
my WSGIPythonHome works fine.
Any ideas?
--
Olaf Meeuwissen FLOSS Engineer -- AVASYS Corporation
FSF Associate Member #1962 sign up athttp://member.fsf.org/
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups Trac
Users group.
To post to this group, send email to trac-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/trac-users?hl=en
-~--~~~~--~~--~--~---
[Trac] Re: Broken post-commit?
On Jul 19, 1:31 am, osimons [EMAIL PROTECTED] wrote:
On Jul 18, 4:17 pm, Aaron D. Marasco [EMAIL PROTECTED]
wrote:
I did all kinds of tests on trac and was happy with
it. Installed the FullBlogPlugin and played with that a little; it's perfect
for my weekly summations for my customer.
Yes, that sure is a nice plugin... ;-)
This morning, when I tried to check in a file, TortoiseSVN said that the
commit failed, but it failed with HTTP/200 OK error. So it didn't fail.
The trac post-commit hook must've ran, because the commit is in my
Timeline/Source Browser. There are no errors that I can see in my httpd
logs. But my local copy is now messed up because it thinks the commit
failed, so hasn't updated the local files.
Since the egg cache was an issue before, I tried adding:
export PYTHON_EGG_CACHE='/var/www/.python-eggs/'
to the post-commit script that calls trac-post-commit, but that didn't help.
So I edited the trac-post-commit file itself and added:
os.environ['PYTHON_EGG_CACHE']='/var/www/.python-eggs/'
which also didn't help. But again, I think the script itself is running
since the trac db gets an update.
Has anybody seen anything like this? Any ideas where I can start looking
for an actual error code? That machine is not online now so I can't do a
diff, but a quick check
ofhttp://trac.edgewall.org/browser/trunk/contrib/trac-post-commit-hooks...
it didn't change in 15 months, so that should be OK, not sure tho.
I'm not sure what you are trying to do. The post-commit-hook is not at
all related to the Timeline/Browser for reading source and new
changesets - that access happens all through the python-subversion
bindings in code when requests to Trac are made.
That does not mean your script or installation does not have problems
of course. The script runs after a commit ('post'), so it will not
stop the commit from happening (as confirmed in the timeline). Also,
the 'HTTP/200 OK' is a web request status, and not I think directly
related to the status an individual post-commit hook.
Depending on setup, your Apache - mod_svn - post-commit-hook could
for instance be running in a different context from themod_wsgi
process. If you remove the trac post-commit-hook, does your Tortoise/
Subversion setup work correctly? Do you have more than one Python
installed?
If things don't pan out, you need to do some logging and get more
details on the actual error that occurs.
If they are running mod_wsgi, not surprised that:
SetEnv for PYTHON_EGG_CACHE
doesn't work as can't do that with mod_wsgi. That is a specific hack
for mod_python adapter last time I looked.
Graham
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups Trac
Users group.
To post to this group, send email to trac-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/trac-users?hl=en
-~--~~~~--~~--~--~---
[Trac] Re: No Spam; No Eggs
On Jul 10, 4:53 am, Chris [EMAIL PROTECTED] wrote: I'm trying to find the shortest path to hosting multiple projects with authentication that works and decent performance. I'm smart enough to insist on getting one project working before generalizing the set-up to handle multiple projects, but just barely. I've got a basic setup working for 3 projects using 3 virtual hosts, but... I'm having problems getting authentication working on Trac 0.10.4 installed from RPM running under Apache using mod_python - No commits, no tickets, no Spam. It's slow too, but the mailing list archives seem to indicate that my issues using .htpasswd could be related to mod_python. Solution:mod_wsgi; That's cool - two birds, one stone... right? There's a hitch. Installation from RPM means no Eggs, right? So what that mean for the wsgi script? Pointing ['PYTHON_EGG_CACHE'] in the os.environ to the site packages directory only succeeded in rapidly expanding the Apache error log. The Python egg cache has to be a directory that user code under Apache can write to. It also should not be pointed at site-packages directory but somewhere else which is specific to that user. Graham When I've implemented Python servers before, I've always just used mod_proxy. Is it possible to write to the SVN repository running Trac as a stand alone program? If I do that, will I have to run a separate instance of tracd for each project? What do I need to do to get cooking? Chris --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Trac Users group. To post to this group, send email to trac-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/trac-users?hl=en -~--~~~~--~~--~--~---
[Trac] Re: Trac on Leopard--not working properly
Perhaps try mod_wsgi instead then. See: http://www.modwsgi.org http://code.google.com/p/modwsgi/wiki/IntegrationWithTrac Graham On Jul 9, 11:01 am, Max [EMAIL PROTECTED] wrote: Sorry I insist on this thread, but I still haven't solved my problem, and I would appreciate some help from this list. When does its suppose to be created the file: /usr/local/share/trac/ cgi-bin/trac.fcgi? As I don't have it created, and I presume is needed to run Trac using Apache, correct? Max. On Jun 26, 12:50 am, Max [EMAIL PROTECTED] wrote: Emmanuel wrote: You've change the files' owner to _www, so only _www can R/W the files. Which means that from the command line, you need to start tracd as the _www user. It should also work with Apache shipped w/ Leopard. The thing is that it doesn't. What do you want to exactly achieve (I'm not sure about your goals) ? I want to do that, I would like to run Trac using Apache (the Leopard bundled one) and FastCGI (as far as I understand FastCGI is used by Trac). I will recollect here what I have done (which is what it has been done in the tutorial I mentioned before --http://www.sonzea.com/articles/subversion-trac.html -- so, pretty much I'm just copy-pasting that section). --Configure Apache to run TRAC using FastCGI-- I created a file at /private/etc/apache2/extra called httpd- fastcgi.conf and added the following contents: ###Starts File### # Enable fastcgi for .fcgi files IfModule mod_fastcgi.c AddHandler fastcgi-script .fcgi FastCgiIpcDir /private/var/run/fastcgi /IfModule LoadModule fastcgi_module libexec/apache2/mod_fastcgi.so ###Ends File### *Note: I've noticed that I don't have the /private/var/run/fastcgi directory, is this a problem? Created a file at /private/etc/apache2/extra called httpd-trac.conf and added the following contents: ###Starts File### ScriptAlias /trac /usr/local/share/trac/cgi-bin/trac.fcgi FastCgiConfig -initial-env TRAC_ENV=/usr/local/trac Location /trac SetEnv TRAC_ENV /usr/local/trac /Location Directory /usr/local/share/trac/cgi-bin AllowOverride None Options None Order allow,deny Allow from all /Directory ###Ends File### *Note: I've also noticed that I don't have the file: /usr/local/share/ trac/cgi-bin/trac.fcgi nor directory /usr/local/share/trac/cgi-bin, is this a problem? At the end of the file /etc/apache2/httpd.conf included directives to these new files: ###At the very end of httpd.conf I added this lines### # FastCGI Include /private/etc/apache2/extra/httpd-fastcgi.conf # TRAC Include /private/etc/apache2/extra/httpd-trac.conf ###Ends httpd.conf### Then I restarted the server and tried the URLShttp://localhost/trac andhttps://localhost/tracandneither of them worked. I get a: Forbidden You don't have permission to access /trac on this server. With both of them. In the apache2 error_log I get: [Thu Jun 26 00:43:51 2008] [error] [client ::1] client denied by server configuration: /usr/local/share/trac Sorry for the long post, but I'm trying to give as much information as I can think of in order to get some advice on what to try. Cheers, Max. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Trac Users group. To post to this group, send email to trac-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/trac-users?hl=en -~--~~~~--~~--~--~---
[Trac] Re: What version of mod_python is required for Trac 0.11 on Linux?
On Jul 6, 2:24 am, Dimitri Maziuk [EMAIL PROTECTED] wrote: Graham Dumpleton wrote: ... Very much suggest you use mod_python 3.3.1. Not because of compatibility issues, but because older versions of mod_python have various bugs in them, including memory leaks. I have 3.3.1 of FC8 and I still get occasional Internal Server Error that goes away after refresh. It seems memory leaks are alive and well in 3.3.1. Some day I'll look intomod_wsgi... There is only one possible per request memory leak known about for mod_python itself and that is on an infrequently travelled code path that not sure anything relies upon. For some setups, there may be a very very small memory leak on restarts. In general if people are seeing memory leaks in mod_python, they are not reporting them and memory leaks don't cause internal server errors. An internal server error can be triggered for various reasons from incorrect configuration, especially if using subversion Python wrappers, to clashes with shared library versions. Although. often some of these also cause process crashes. If you have code that demonstrates memory leaks in mod_python itself, you might like to report them on mod_python list. Graham --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Trac Users group. To post to this group, send email to trac-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/trac-users?hl=en -~--~~~~--~~--~--~---
[Trac] Re: What version of mod_python is required for Trac 0.11 on Linux?
On Jul 4, 9:30 am, J R Andom [EMAIL PROTECTED] wrote: Hi, I'm new to trac, long time listener, first time caller, glad to get on the air, ... The TracInstall page of the wiki athttp://trac.edgewall.org/wiki/TracInstall states thatmod_python3.1.3+ is required for those of us using apache andmod_python. And then references the TracModPython page. But that page, near as I can tell, makes only one mention of the required version ofmod_python, and that's iff a) you're on windows and b) you want to upload files, and then they suggest you use 3.1.4. I am running on RHEL 3 and with what appears to bemod_python3.0.3 Can I expect Trac 0.11 to work with Apache with this version ofmod_python, or do I need to rebuild it? Very much suggest you use mod_python 3.3.1. Not because of compatibility issues, but because older versions of mod_python have various bugs in them, including memory leaks. Graham --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Trac Users group. To post to this group, send email to trac-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/trac-users?hl=en -~--~~~~--~~--~--~---
[Trac] Re: Installing Plugins under 0.11 how to? Ubuntu 6.06
On Jun 19, 5:02 pm, Hr. Johannes Loose [EMAIL PROTECTED] wrote: Am 18 Jun 2008 um 14:23 hat Erik Bray geschrieben: I took a quick scan through the latest version of it, but no obvious problems jumped out at me. How is it broken? I have the WikiTicketCalendarMacro currently running under 0.11rc2, it's running fine under the current 0.12 trunk, too. But I had to do some code changes to get it to run, which should be regarded rather 'quick and dirty' than real bugfixes. a) Usingmod_wsgithere is a problem with writing to sys.stdout. As a workaround I added the line 'sys.stdout = sys.stderr'. Please try and get the WikiTicketCalendarMacro fixed rather than use the hack. The code shouldn't use 'print' to try and output debugging as it will not work under CGI-WSGI bridge, or other WSGI adapters that use stdin/stdout for communicating with web server. Although mod_wsgi doesn't use stdin/stdout in this way, for that reason mod_wsgi specifically denies it as well to promote portability. If people keep working around it, the problems in original code will never be fixed and keep tripping people up. If original code wants to output debugging, at worst they should use: print sys.stderr, . original arguments .. Ie., direct output of 'print' to sys.stderr explicitly. At best, they should use whatever mechanism Trac may use to get a handle on appropriate log file for output. Graham b) If there are accents (special chars like german umlauts) in the description of tilestones or tickets, the calendar will fail to load. Alex gave the hint that this behaviour could be changed '...by changing the line from cStringIO import StringIO to from StringIO import StringIO'. b) Finally search for 'celpadding' and correct the typo. Note, that there is a ticket (#3159) on track hacks, describing that shortcomings. With that points patched, the plugin is running really fine. Johannes --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Trac Users group. To post to this group, send email to trac-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/trac-users?hl=en -~--~~~~--~~--~--~---
[Trac] Re: trac + high cpu load
On Jun 19, 8:06 am, Bill Johnson [EMAIL PROTECTED] wrote: Pardon my apache ignorance, as I am still learning, but what does apache define as a child, and is this set in httpd.conf? Not exactly what you are asking for, but have a read of: http://code.google.com/p/modwsgi/wiki/ProcessesAndThreading as may explain a few things. Only mod_wsgi daemon mode is not also applicable to mod_python case. And yes number of initial child process etc is defined in Apache configuration, see: http://httpd.apache.org/docs/2.2/mpm.html and the linked pages for each MPM, such as: http://httpd.apache.org/docs/2.2/mod/prefork.html http://httpd.apache.org/docs/2.2/mod/worker.html The latter pages should also help to explain process model. Graham snip others. 2) reducing the number of requests per child - the default in httpd.conf was 4000 and I dropped MaxRequestsPerChild to 100 and switched back tomod_python (1000 was suggested, but I tried 100 and haven't had a chance snip --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Trac Users group. To post to this group, send email to trac-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/trac-users?hl=en -~--~~~~--~~--~--~---
[Trac] Re: Suggestions about Apache binding
On Jun 13, 2:44 am, Barzo [EMAIL PROTECTED] wrote:
Hi,
I've setup a Trac 0.11rc1 on Ubuntu with this layout:
/usr/local/trac
+--- eggs [- PYTHON_EGGS_CHACHE for all projects]
+--- edp
trac.htdigest [- Password file for AccountManager PlugIn]
trac.ini [- Config shared by all project in edp]
trac.wsgi
+--- Project 1
+--- Project 2
+--- Project n
+--- rs
trac.htdigest [- Password file for AccountManager PlugIn]
trac.ini [- Config shared by all project in rs]
trac.wsgi
+--- Project 1
+--- Project 2
+--- Project n
First of all...it may be work?
Second, my /etc/apache2/site-available/trac file for apache is :
NameVirtualHost *:80
VirtualHost *:80
DocumentRoot /usr/local/trac
WSGIScriptAlias /trac_edp /usr/local/trac/edp/trac.wsgi
Directory /usr/local/trac/edp
WSGIApplicationGroup %{GLOBAL}
Option Indexes FollowSymLinks MultiViews
AllowOverride AuthConfig
Order deny,allow
Allow from all
/Directory
WSGIScriptAlias /trac_rs /usr/local/trac/rs/trac.wsgi
Directory /usr/local/trac/rs
WSGIApplicationGroup %{GLOBAL}
Option Indexes FollowSymLinks MultiViews
AllowOverride AuthConfig
Order deny,allow
Allow from all
/Directory
/VirtualHost
But I think it not right because strange things happens...
for example sometimes if I load from my browserhttp://myTracServer/trac_edp
instead to appear /usr/local/trac/edp projects I see /usr/local/trac/
rs instead!
Can someone give me some suggestions?
Read the mod_wsgi documentation on Trac integration again.
http://code.google.com/p/modwsgi/wiki/IntegrationWithTrac
It explains in there that you cannot use os.environ method of defining
Trac location in WSGI script file for multiple Trac instances when
using mod_wsgi embedded mode.
Use the Apache SetEnv method described in the document instead.
You may also want to consider delegating each Trac instance to a
separate process using mod_wsgi daemon mode.
Graham
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups Trac
Users group.
To post to this group, send email to trac-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/trac-users?hl=en
-~--~~~~--~~--~--~---
[Trac] Re: trac and mod_python resulting in many runaway httpd processes
The whole point of Apache/mod_python is that processes persist and a new one isn't created for each request as is the case with CGI. It is though generally a good idea with mod_python/Trac to force Apache to recycle processes every so often. See the MaxRequestsPerChild directive in Apache and read the Trac documentation which I am sure you would probably mention using this directive. Set it to 1000 and see how it goes. Graham On Jun 11, 2:26 pm, James Gallagher [EMAIL PROTECTED] wrote: Hi, I just installed trac 0.10.4 on a Centos 5 machine (an upgrade and move from a 10.3 on a RHEL3 machine) using apache 2.2. I decided to switch tomod_pythonin place of the CGI. However, withmod_pythonthe httpd processes seem to be running for a long, long time, so much so that the host becomes bogged down and pretty much stops working - the load factor will reach 15-20 before I stop apache. When I switch back to the CGI the problem goes away. I'd really like to understand what's up withmod_python. Any ideas? Here's my Location directive for trac for use withmod_python: Location /trac SetHandlermod_python PythonInterpreter main_interpreter PythonHandler trac.web.modpython_frontend PythonOption TracEnv /usr/local/scm/trac PythonOption TracUriRoot /trac # PythonPath sys.path + ['/usr/share/trac'] SetEnv PYTHON_EGG_CACHE /var/cache/www/pythoneggs /Location I commented out PythonPath in an effort to fix this... Other version information: Python 2.4.3 (#1, Mar 14 2007, 18:51:08) [GCC 4.1.1 20070105 (Red Hat 4.1.1-52)] on linux2 Type help, copyright, credits or license for more information. mod_python-3.2.8-3.1 httpd-2.2.3-11.el5_1.centos.3 clearsilver-0.10.5 I have the trac webadmin 0.1.2 egg for python 2.4 Thanks, James -- James Gallagher jgallagher at opendap.org 406.723.8663 --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Trac Users group. To post to this group, send email to trac-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/trac-users?hl=en -~--~~~~--~~--~--~---
[Trac] Re: how to prevent view of trac_parent_env
On May 23, 7:38 am, ewk_elwa [EMAIL PROTECTED] wrote:
I have multiple projects in my Trac setup with the TRAC_PARENT_ENV and
Apache2.
When I connect to servername/trac it presents me a page with the list
of projects. I can click on a project and go to the project Trac site.
I want to:
1. make the project listing page invisible or restricted. I don't want
people on project XYZ knowing that there exist a project ABC because
both are listed on the servername/trac page.
servername/trac should produce a restricted or no page
severname/trac/projectXYZ should put the user at projectXYZ login
dialog box
servername/trac/projectABC should put the user at projectABC login
dialog box
You can customise the page. See:
http://trac.edgewall.org/wiki/TracInterfaceCustomization
Alternatively, if using mod_wsgi, relatively easy to setup the
equivalent of using TRAC_ENV_PROJECT_DIR, but where no project index
page available.
See:
http://code.google.com/p/modwsgi/wiki/IntegrationWithTrac
Look for example:
WSGIDaemonProcess sites processes=3 threads=25 maximum-requests=1000
RewriteEngine On
RewriteCond %{REQUEST_URI} ^/trac/([^/]+)
RewriteCond /usr/local/trac/sites/%1/conf/trac.ini !-f
RewriteRule . - [F]
RewriteCond %{REQUEST_URI} ^/trac/([^/]+)
RewriteRule . - [E=trac.env_path:/usr/local/trac/sites/%1]
WSGIScriptAliasMatch ^/trac/([^/]+) /usr/local/trac/apache/trac.wsgi
Directory /usr/local/trac/apache
WSGIProcessGroup sites
WSGIApplicationGroup %{GLOBAL}
Order deny,allow
Allow from all
/Directory
Get creative and you could use a custom WSGI application to create an
alternate index page based on what ever criteria you want.
Graham
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups Trac
Users group.
To post to this group, send email to trac-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/trac-users?hl=en
-~--~~~~--~~--~--~---
[Trac] Re: [Trac 0.11b2] [apache+mod_python] Basic authentication configuration issue
On Apr 23, 2:16 pm, Virtual Dust [EMAIL PROTECTED] wrote: Eirik Schwenke wrote: I just now tested with the following in my local apache-config: ~ LocationMatch /[^/]+/login$ ~ AuthType Basic ~ AuthName Projects ~ AuthUserFile /home/httpd/trac-env/trac.htpasswd ~ Require valid-user ~ /LocationMatch And it demanded login-credentials for all /foo/bar/login-urls i threw at it. (Note the trailing $ didn't make any difference wrt wether or not the section worked, but it's best to be reasonably specific about LocationMatch-directives, in case they're included in a complex apache-config). I'd double-check my apache-config for typos and see if the apache error.log has anything helpful to add -- because as far as I can understand the code you posted earlier *should* work. Let's do some magics... ~ DocumentRoot /home/httpd/projects ~ ~ Location / ~SetHandler mod_python ~PythonHandler trac.web.modpython_frontend ~PythonOption TracEnvParentDir /home/httpd/trac-env ~PythonOption TracUriRoot / ~SetEnv PYTHON_EGG_CACHE /home/httpd/.egg-cache ~PythonDebug On ~ /Location ~ ~ LocationMatch /[^/]+/login$ ~AuthType Basic ~AuthName Projects ~AuthUserFile /home/httpd/trac-env/trac.htpasswd ~Require valid-user ~ /LocationMatch This is the initial configuration : i'm not asked for authentication forhttp://projects.arcanes.home/foo/login Now... ~ DocumentRoot /home/httpd/projects ~ * Directory /home/httpd/projects/ ~SetHandler mod_python ~PythonHandler trac.web.modpython_frontend ~PythonOption TracEnvParentDir /home/httpd/trac-env ~PythonOption TracUriRoot / ~SetEnv PYTHON_EGG_CACHE /home/httpd/.egg-cache ~PythonDebug On * /Directory ~ ~ LocationMatch /[^/]+/login$ ~AuthType Basic ~AuthName Trac Projects Authentication ~AuthUserFile /home/httpd/trac-env/trac.htpasswd ~Require valid-user ~ /LocationMatch (changed lines start with *) And... All is fine !! It seams that the Apache server deals with the Location / directive in a particular way. I don't know if it's a bug (just in my version ?), though. Maybe there is a real reason for that. But what is in '/home/httpd/projects/'? Letting it fall back on to document root like this may itself cause problems if not careful depending on whether document root is empty or not. Frankly, how mod_python hooks into Apache is a PITA as it causes various little oddities where the true target of a request as calculated by Apache, ie.,. SCRIPT_NAME equivalent, ends up being wrong. End result is that web applications have learned not to trust what mod_python passes it for some values in the request and applications work it out themselves from the request URI. This means though that the applications have to be told where the application is mounted if not mounted at root. In contrast, mod_wsgi hooks into Apache in a more traditional resource based approach like CGI configuration is done. This means SCRIPT_NAME is correct and you don't end up with these funny little problems like you are having when using Location directive to try and configure mod_python. In other words, you might consider looking at mod_wsgi instead of mod_python as it doesn't generally exhibit these odd little issues that mod_python sometimes can. :-) Graham --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Trac Users group. To post to this group, send email to trac-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/trac-users?hl=en -~--~~~~--~~--~--~---
[Trac] Re: mod_wsgi issue
See:
http://code.google.com/p/modwsgi/issues/detail?id=75can=1
You are making the same mistake.
Graham
On Apr 18, 11:07 am, Jan De Coster [EMAIL PROTECTED] wrote:
hi all,
i have a current problem with mymod_wsgisetting for running trac ...
situation:
employee 1 = a
employee 2 = b
employee 3 = c
a visits trac/project1
b visits trac/project2
but b gets trac/project1 served
when 'c' interacts in this session
so c visits trac/project3
if this happens ... a b both get served trac/project3
the current apache vhost (minimal)
VirtualHost xxx.xxx.xxx.xxx:443
ServerName trac.
DocumentRoot /var/www/
SSLEngine on
SSLCertificateFile /etc/apache2/cert/server.crt
SSLCertificateKeyFile /etc/apache2/cert/server.key
SSLCertificateChainFile /etc/apache2/cert/DigiCertCA.crt
local wsgi settings
Directory /usr/local/trac
WSGIApplicationGroup %{GLOBAL}
Order deny,allow
Allow from all
/Directory
system trac
WSGIScriptAlias /system /usr/local/trac/system.wsgi
Location /system
AuthType Basic
AuthName DigitalBase.be 3 system trac
AuthUserFile /data/trac/passwd/trac-system
/Location
mice trac
WSGIScriptAlias /mice /usr/local/trac/mice.wsgi
Location /mice
AuthType Basic
AuthName DigitalBase.be mice trac
AuthUserFile /data/trac/passwd/trac-mice
Require valid-user
/Location
/VirtualHost
### other info
[EMAIL PROTECTED]:~$ cat /usr/local/trac/system.wsgi
#!/usr/bin/python
import sys
#sys.stdout = sys.stderr
import os
os.environ['TRAC_ENV'] = '/data/trac/system'
import trac.web.main
application = trac.web.main.dispatch_request
---
[EMAIL PROTECTED]:~$ cat /usr/local/trac/mice.wsgi
#!/usr/bin/python
import sys
#sys.stdout = sys.stderr
import os
os.environ['TRAC_ENV'] = '/data/trac/mice'
import trac.web.main
application = trac.web.main.dispatch_request
### software used
Apache/2.2.3 (Ubuntu) DAV/2 SVN/1.4.3 mod_ssl/2.2.3
OpenSSL/0.9.8cmod_wsgi/2.0 Python/2.5.1 Server
Thanks in advance,
Jan De Coster
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups Trac
Users group.
To post to this group, send email to trac-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/trac-users?hl=en
-~--~~~~--~~--~--~---
[Trac] Re: Problem installing trac on a Mac
On Apr 3, 5:39 pm, David Henderson [EMAIL PROTECTED] wrote: Hello Graham: Which is still the MacPorts Python. Change the PATH environment variable in your user shell environment so that you aren't looking in MacPorts bin directory, or this directory if you added it explicitly. When you run 'which python' you want it to find: /usr/bin/python That should be a symlink to 'python2.5' in the same directory which should in turn be a symlink to something like: ../../System/Library/Frameworks/Python.framework/Versions/2.5/bin/ python OK, I found that MacPorts creates a local .bash_profile that prepends the MacPorts path to the system path. Removing this file reverted back to the system path. I also had to create by hand the symlink from /usr/bin/python to /usr/bin/python2.5 as both pointed to the ../../System/... location. Sorry, put the /usr/bin/python symlink back how it was. I have been explaining all this from memory without actual access to a Leopard system. In Python 2.3 under Tiger they had python symlink to python2.3 in same directory. Under Leopard as you have found they don't do that and instead symlink has same target as python2.5 rather than pointing at python2.5 itself. Which python now gives: MiniMac:~ dnadave$ which python /usr/bin/python and here are the resolved addresses of the symlinks: MiniMac:~ dnadave$ ls -lh /usr/bin/python /usr/bin/python2.5 lrwxr-xr-x 1 root wheel 18B Apr 2 23:14 /usr/bin/python - /usr/ bin/python2.5 Except put that back now so it also says: python - ../../System/Library/Frameworks/Python.framework/Versions/ 2.5/bin/python lrwxr-xr-x 1 root wheel 75B Feb 6 08:37 /usr/bin/python2.5 - ../../System/Library/Frameworks/Python.framework/Versions/2.5/bin/ python2.5 Standard OS Python is 2.5.1 so this confirms this is MacPorts Python. Here is the startup banner for python, now: MiniMac:~ dnadave$ python Python 2.5.1 (r251:54863, Feb 4 2008, 21:48:13) [GCC 4.0.1 (Apple Inc. build 5465)] on darwin Type help, copyright, credits or license for more information. Run: /usr/bin/python or just 'python' after getting rid of MacPorts Python out of PATH and try it again. Here is the output of the import of libsvn, now: import libsvn print libsvn.__file__ /System/Library/Frameworks/Python.framework/Versions/2.5/Extras/lib/ python/libsvn/__init__.pyc This file should never need to be created by hand, it will be created for you by the tools. I would delete that easy-install.pth file and start with empty directory except for README file. OK, done. Once you have /usr/bin/python being used rather than MacPorts, then install Python packages for Genshi and Trac with it per their respective instructions. Then post again output from running: ls /Library/Python/2.5/site-packages/ MiniMac:~ dnadave$ ls /Library/Python/2.5/site-packages/ Genshi-0.4.4-py2.5.egg README easy-install.pth Pygments-0.9-py2.5.egg Trac-0.11b2-py2.5.egg and now, when I start trac with: MiniMac:~ dnadave$ tracd --port 8000 /Users/dnadave/Trac/R-Devel I can access the trac page for the project I created. Thanks a lot for the help! Is there any chance we could write up some of this as a troubleshooting page that edgewall would post on their site? I do think this would be helpful for others. Well, all I have done is get you back to how you would have been before you installed the MacPorts Python. I see so many problems caused by people installing MacPorts Python, that for Leopard at least, I'd rather just see people not use it unless they have a very good reason and understand enough about Python installations that they understand how things work and what the implications are of installing it. In other words, all the documentation might say is that if using Leopard, there is no need to install MacPorts Python. :-) Graham Thanks!! Dave H -- David Henderson, Ph.D. Director of Community REvolution Computing 1100 Dexter Avenue North, Suite 250 206-577-4778 x3203 [EMAIL PROTECTED]://www.revolution-computing.com --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Trac Users group. To post to this group, send email to trac-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/trac-users?hl=en -~--~~~~--~~--~--~---
[Trac] Re: Problem installing trac on a Mac
For hints and reference to MacOS X documents about these sorts of issues see: http://code.google.com/p/modwsgi/wiki/InstallationOnMacOSX This is documentation from mod_wsgi, but still describes the architecture issues. Can you go back to using supplied tools and indicate what the specific error was you had then. I don't remember having any issues with getting Trac to work on Leopard and I don't remember having to do the fiddles for different architectures either, but then if you are installing special plugins requiring additional third party modules etc, then you may strike issues, if the third party modules have C extensions and you are trying to run under Apache using mod_wsgi or a tweaked mod_python. Graham On Apr 2, 5:27 pm, David Henderson [EMAIL PROTECTED] wrote: Hello Graham: Why install from source, except for Trac, Leopard has all the packages provided with the operating system. I did try that first, but after receiving the same error I reported before thought that I might remedy the problem by building from source. Building from source did not fix the problem and actually created problems of its own (some packages would not build, complaining about mismatched architectures, even when a valid architecture was specified. Thanks!! Dave H -- David Henderson, Ph.D. Director of Community REvolution Computing 1100 Dexter Avenue North, Suite 250 206-577-4778 x3203 [EMAIL PROTECTED]://www.revolution-computing.com --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Trac Users group. To post to this group, send email to trac-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/trac-users?hl=en -~--~~~~--~~--~--~---
[Trac] Re: Problem installing trac on a Mac
On Apr 2, 10:26 am, David Henderson [EMAIL PROTECTED] wrote: I've wasted a week of my life trying to get trac installed on my Intel Mac OS X Leopard laptop. I have built python, sqlite, pysqlite, swig and subversion from source Why install from source, except for Trac, Leopard has all the packages provided with the operating system. Graham and followed the instructions on all of the Wikis I could find on the web, especially the ones on the edgewall pages. None have worked. I have also had some trouble getting swig- py to compile as I get an error about incompatible architectures in the libraries at link time, even when I specify x86_64 as the architecture. The main error I get, even if I use the versions of the software that come with XCode is: Warning: Can't synchronize with the repository (Unsupported version control system svn. Check that the Python support libraries for svn are correctly installed.) Anyone have ANY ideas on how I can get this built on a Mac? I have installed trac before on Linux, and it took about 15 minutes to get things working, but all we have at my new job is Macs and I'm beyond frustrated. Thanks!! Dave H -- David Henderson, Ph.D. Director of Community REvolution Computing 1100 Dexter Avenue North, Suite 250 206-577-4778 x3203 [EMAIL PROTECTED]://www.revolution-computing.com --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Trac Users group. To post to this group, send email to trac-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/trac-users?hl=en -~--~~~~--~~--~--~---
[Trac] Re: Problem with slow project listing.
On Apr 1, 11:43 am, Chris Hill [EMAIL PROTECTED] wrote: We've got a strange slowdown issue with our projects root listing. Nothing else is effected. No individual project has a problem. Pretty much a textbook setup: Location /projects SetHandlermod_python PythonHandler trac.web.modpython_frontend PythonOption TracEnvParentDir /var/trac PythonOption TracUriRoot /projects SetEnv PYTHON_EGG_CACHE /tmp /Location Useful Tidbits: Trac 10.4 We're using SSL. Problem does not seem SSL-specific. We have 175 and counting projects. We've got a couple custom plugins, nothing earth-shattering. So what we're seeing happening, we think, is thatmod_pythonis loading, over and over again, a bunch of plugins, for some unknown reason: 2008-03-31 17:12:20,126 Trac[__init__] DEBUG: Loading egg plugin navhider.filter from /usr/lib/python2.4/site-packages/TracNavHider-1.0-py2.4.egg 2008-03-31 17:12:20,128 Trac[__init__] DEBUG: Loading egg plugin navadd from /usr/lib/python2.4/site-packages/NavAdd-0.1-py2.4.egg 2008-03-31 17:12:20,157 Trac[__init__] DEBUG: Loading egg plugin webadmin.logging from /usr/lib/python2.4/site-packages/TracWebAdmin-0.1.2dev_r4240-py2.4.egg 2008-03-31 17:12:20,159 Trac[__init__] DEBUG: Loading egg plugin webadmin.ticket from /usr/lib/python2.4/site-packages/TracWebAdmin-0.1.2dev_r4240-py2.4.egg 2008-03-31 17:12:20,160 Trac[__init__] DEBUG: Loading egg plugin webadmin.basics from /usr/lib/python2.4/site-packages/TracWebAdmin-0.1.2dev_r4240-py2.4.egg If we tail -f the log, we can see that there are these pauses where its thinking, then it loads the plugins, then its thinking, then it loads the plugins, and it does this about 30 times. This takes an extremely long time, regardless of what's in index.cs. We're really unsure what Trac's doing, or why. Any thoughts would be appreciated! Apache is a multi process web server. Are you sure the messages aren't from different Apache child processes? Also, do you set MaxRequestsPerChild? If you do it would result in Apache child processes being recycled when that number of requests is being reached. If you have a constant stream of requests, this would show as plugin being loaded on a similar regular basis. Graham --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Trac Users group. To post to this group, send email to trac-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/trac-users?hl=en -~--~~~~--~~--~--~---
[Trac] Re: Problem with slow project listing.
On Apr 1, 1:45 pm, Chris Hill [EMAIL PROTECTED] wrote: If we tail -f the log, we can see that there are these pauses where its thinking, then it loads the plugins, then its thinking, then it loads the plugins, and it does this about 30 times. This takes an extremely long time, regardless of what's in index.cs. We're really unsure what Trac's doing, or why. Any thoughts would be appreciated! Apache is a multi process web server. Are you sure the messages aren't from different Apache child processes? Also, do you set MaxRequestsPerChild? If you do it would result in Apache child processes being recycled when that number of requests is being reached. If you have a constant stream of requests, this would show as plugin being loaded on a similar regular basis. Thanks for your quick response! MaxRequestsPerChild is set to 0 AFAIK. I am sure that the messages are from the single request, as we are watching it happen on our staging server. We can see the same problem on production (which makes us want to fix this quickly). Perhaps use a different value for: SetEnv PYTHON_EGG_CACHE /tmp Ie., make it a directory which is unique to that Apache instance and which is definitely owned and writable by the Apache user. Maybe by being a pretty common directory that it is having problems if needing to unpack compressed eggs, especially if another Apache instance is also using that same directory, or something has unpacked stuff there with different access permissions. Graham --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Trac Users group. To post to this group, send email to trac-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/trac-users?hl=en -~--~~~~--~~--~--~---
[Trac] Re: Default page when environment not found
On Feb 25, 9:40 pm, Jani Tiainen [EMAIL PROTECTED] wrote:
I've multiproject setup using apache andmod_python.
Everything works well except when user enters non-existing project name,
likehttp://www.example.com/trac/foobar
End user only gets Environment not found, that is not very
descriptive. Is there way to point to another URL or set one enviroment
as a default so user would be always redirected to something sane?
Maybe some mod_rewrite stuff?
One of the mod_wsgi examples for Trac uses a bit of mod_rewrite to
verify that Trac instances exists.
WSGIDaemonProcess sites processes=3 threads=25 maximum-requests=1000
RewriteEngine On
RewriteCond %{REQUEST_URI} ^/trac/([^/]+)
RewriteCond /usr/local/trac/sites/%1/conf/trac.ini !-f
RewriteRule . - [F]
RewriteCond %{REQUEST_URI} ^/trac/([^/]+)
RewriteRule . - [E=trac.env_path:/usr/local/trac/sites/%1]
WSGIScriptAliasMatch ^/trac/([^/]+) /usr/local/trac/apache/trac.wsgi
Directory /usr/local/trac/apache
WSGIProcessGroup sites
WSGIApplicationGroup %{GLOBAL}
Order deny,allow
Allow from all
/Directory
As written this will raise a forbidden message if non existent site is
accessed. You could either replace the 'RewriteRule . - [F]' to do
something different, or use Apache ErrorDocument directive to point at
a custom error page.
The particular rewrite rules could also be made to work if using
mod_python.
Graham
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups Trac
Users group.
To post to this group, send email to trac-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/trac-users?hl=en
-~--~~~~--~~--~--~---
[Trac] Re: Trac performance optimization
On Jan 11, 12:29 am, Jevgenijs Rogovs [EMAIL PROTECTED] wrote: Hello everyone, I am running Trac 0.10.4 on RH Enterprise Release 3 (kernel 2.4.20-8) with Apache HTTPD 2.0.54, Python 2.5.1, mod_python 3.3.1. All debug stuff and logging is off, python/mod_python are built with shared libraries. Database backend is SQLite. Is there anything I can do to improve overall performance of Trac? Any ideas? P.S. I do understand that the most common issue in client-server system performance is network latency; nevertheless, I'd like to be sure that my server-side is top notch. That performance is dictated by network latency is generally not the case with large web applications. Your real problem is going to be the speed of talking to your database. In this case SQLite is a poor choice. Instead you should look at using PostgreSQL or MySQL as these will perform much better. If you are truly paranoid about overheads in network and underlying request handling by the web server, you would also be better of using mod_wsgi rather than mod_python as it has much better performance relative to mod_python. For a comparison see: http://code.google.com/p/modwsgi/wiki/PerformanceEstimates Graham --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Trac Users group. To post to this group, send email to trac-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/trac-users?hl=en -~--~~~~--~~--~--~---
[Trac] Re: Installation problems
On Dec 9, 2:05 pm, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Hi Folks, Hoping someone out there has had the same troubles that i'm having and can point me in the right direction. I've installed trac and when trying to run via either tracd or mod_python i'm getting a stack trace printed to the browser with the following error message ImportError: libpq.so.5: cannot open shared object file: No such file or directory. I've double checked that my postgres install is working and that my LD_LIBRARY_PATH is set properly. Your personal LD_LIBRARY_PATH doesn't get used. Set and export it in the 'envvars' file in the same directory as Apache httpd executable. That way the user that Apache runs as should pick it up. The better thing to do though is perhaps ensure libpq.so is installed in a standard library directory or rebuild Python module using it such that it will look at actual location where it is installed, by setting LD_RUN_PATH environment variable to location at compile time. Graham Any help is appreciated. Thanks! Mark --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Trac Users group. To post to this group, send email to trac-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/trac-users?hl=en -~--~~~~--~~--~--~---
[Trac] Re: mapping common and site static resources seperately in Apache2
On Dec 6, 4:02 am, Danny [EMAIL PROTECTED] wrote: I apologize, I believe I misspoke in my previous post. I have set the trac.ini setting for 'htdocs_location' and the respective symlink; it works properly but it only applies to /common/ files, the static files from the trac distribution itself. I'd like to know if there is configuration available for a similiar setting for the /site/ specific htdocs folder, if not I'd be more than happy to inquire on the development list and perhaps poke around myself. The purpose being that /site/ specific static files can also be served by Apache rather than by the trac cgi itself without having to resort to Alias-es. Since there is a setting for common files, I figured there might be a way of doing the same for the site files. That htdocs_location exists is possibly more as a convenience so that one can configure the URLs so that they don't overlap with the Trac URL namespace. In practice this probably isn't required. Through appropriate ordering of directives in Apache it should be possible to map what is a subset of URLs in Trac namespace to actual physical files. In other words, you shouldn't need a feature in Trac to do it. To do this though would most likely require you have access to main Apache configuration. If you only have access to .htaccess file, then may be harder or not possible. I'm not really a Trac user so you'll need to help me out here. First off, ignoring htdocs_location, what URL within your Trac instance would these static files normally reside at? Give me that and what Apache configuration you are using to get Trac to work for you and the URL for the top of the Trac instance and I'll give some suggestions. Graham On Dec 4, 5:19 pm, Graham Dumpleton [EMAIL PROTECTED] wrote: On Dec 5, 2:40 am, Danny [EMAIL PROTECTED] wrote: Heh, you are right Graham, there is mention of serving project specific files through apache, it just didn't 'click'. However, although that information is somewhat useful, unforunately at my site I don't have access to the apache Alias directive. I'm wondering if there is an option, or a way of configuring it in trac.ini in the same style that the 'htdocs_location' functions. Essentially creating a symlink to the common htdocs, and simply setting the trac.ini to read that, thereby not requiring the use of the apache directives. You probably just need to set htdoc_location to URL which maps into your own personal web space where you can place files and/or directories of files. You probably will not be able to use a symlink as following symlinks is often disabled in Apache. Thus, you would need to copy the Trac htdocs directory into your own personal web space. Can't comment further as you don't go into how your Apache is setup as to allow you currently serve CGI scripts or your own personal static pages. Graham -- Danny On Dec 3, 4:54 pm, Graham Dumpleton [EMAIL PROTECTED] wrote: On Dec 4, 6:31 am, Danny [EMAIL PROTECTED] wrote: I'd like to know if its possible to map the static resources from Trac's site and common paths to different locations using apache and/ or trac.ini. I have read through and implented the suggestions in (http:// trac.edgewall.org/wiki/TracCgi#MappingStaticResources) for mapping the static *common* resources, but there doesn't appear to be any indication or suggestions for mapping static site resources specifically the $TRAC_ENV/htdocs directory. Is there support for this in trac? If so, where? If not, should I cross post to the dev mailing list? Huh, isn't that what the section starting with 'Similarly, if you have static resources in a projects htdocs directory, you can configure apache to serve those resources' is explaining, or am I missing something? Anyway, thanks for bringing this up, as the same techniques as described for CGI scripts carry over to mod_wsgi. I'll have to update mod_wsgi documentation to highlight this, as will help to lessen the work Trac has to do in that setting as well. :-) This question actually comes up again in the attachments, but I can see the issue there with respect to needing the trac.cgi to authorize the access to the attachments, in our particular enviroment it isn't a big deal, authorization is handled by apache you are either in or your out :). Any suggestions/thoughts would be greatly appreciated, thanks! Don't know about attachments, but I also will be interested in the response. Graham --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Trac Users group. To post to this group, send email to trac-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/trac-users?hl
[Trac] Re: TRAC SVNPath oddness
On Dec 4, 10:55 am, Panos Savvas [EMAIL PROTECTED] wrote: Hi Graham, Thanks for the advice. I will try this out tomorrow. Its presence in the root context is possibly what is causing the problem. I suppose this is typical of trying to configure 3 new technologies (new to me) at once. I assumed that referencing the AuthzSVNAccessFile in the root context would mean that it is inherited by all other contexts. This seems to be supported in that the authorisation works in all other contexts. Is this a flawed assumption however? The presence of AuthzSVNAccessFile is likely enough to trigger Subversion Apache authorisation handler for all URLs, but that handler is then expecting SVNPath to have also been defined in the same context, which it isn't. Thus possibly why you are getting an error. If this is the case, accessing stuff outside of /trac would also result in the same error. I am going to have several projects/trac environments eventually and am trying to have a single configuration for authorisation, i.e path based permissions. But are you wanting to also expose Subversion repository through Apache so you can do checkouts over the network? If not, you don't need the SVNPath stuff nor the Subversion authorisation checks. Graham However currently my svn access file only has one generic entry. Could this be the problem? Would have the svn access file formated with paths potentially make this strategy succeed? I will experiment at work tomorrow and let you know how I am doing. Meanwhile any more advice is appreciated :) Thanks again. Panos On Dec 3, 2007 9:58 PM, Graham Dumpleton [EMAIL PROTECTED] wrote: On Dec 1, 1:27 am, Panos [EMAIL PROTECTED] wrote: Hi everyone, I am new to trac/svn/apache but have configured a basic setup of the free and am very impressed. I have one question at the moment which is confussing me: I have had to add the SVNPATH to my trac location in httpd.conf, which seems strange. If not the error log complains that it is missing. Does this mean anything to you? It took me a while to figure this out as I have not seen this mentioned anywhere online. However it does fix it. Why do you have: AuthzSVNAccessFile C:\Program Files\Apache Group \Apache2\svnaccessfile.txt defined at '/' context and not '/TestProject'? Its presence in the root context is possibly what is causing the problem. Graham Please see excerpts from httpd.conf and trac.ini below Versions: trac 0.10.4 apache 2.0.6x svn 1.45 files: ### TRAC.INI ## [trac] authz_file = authz_module_name = base_url = check_auth_ip = true database = sqlite:db/trac.db default_charset = iso-8859-15 default_handler = WikiModule htdocs_location = ignore_auth_case = false mainnav = wiki,timeline,roadmap,browser,tickets,newticket,search metanav = login,logout,settings,help,about permission_store = DefaultPermissionStore repository_dir = c:\Projects\svn\TestProject repository_type = svn ### httpd.conf ## Location / AuthType SSPI AuthName TestProject SSPIAuth On SSPIAuthoritative On SSPIDomain groupinfra.com SSPIOfferBasic On #SSPIOmitDomain on //**this makes things a lot easier** #SSPIUsernameCase lower SSPIBasicPreferred On SSPIOfferSSPI off AuthzSVNAccessFile C:\Program Files\Apache Group \Apache2\svnaccessfile.txt Require valid-user /Location #SVN Location /TestProject DAV svn #SVNListParentPath on SVNPath C:\Projects\svn\TestProject #SVNParentPath C:\Projects\svn /Location #TRAC Location /tracs # the top level url that hosts multiple projects SetHandler mod_python PythonHandler trac.web.modpython_frontend PythonOption TracEnv C:\Projects\trac\TestProject PythonOption TracUriRoot /tracs SVNPath C:\Projects\svn\TestProject /Location If i remove the SVNPath from the /tracs location the following occurs in the error.log when I try to navigate to the trac website: [Fri Nov 30 14:13:40 2007] [error] [client 127.0.0.1] The server is misconfigured: either an SVNPath or SVNParentPath directive is required to specify the location of this resource's repository. [500, #19] It seems to be working, however it makes not much sense, and I am worried it will cause issues later Thanks Panos --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Trac Users group. To post to this group, send email to trac-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/trac-users?hl=en -~--~~~~--~~--~--~---
[Trac] Re: TRAC SVNPath oddness
On Dec 4, 12:14 pm, Savvas, Panayotis [EMAIL PROTECTED] wrote: The presence of AuthzSVNAccessFile is likely enough to trigger Subversion Apache authorisation handler for all URLs So what would be the best way to do this. i.e. have a single reference to the svn access file for all. Or should I not be using the svn access list for apache sites (such as trac in this instance) and use a more generic non-svn access method with apache? This would mean that I would have to have separate svn and apache permissions logic, which seems counter intuitive as I need exactly the same permissions for each svn and trac instance pair. But are you wanting to also expose Subversion repository through Apache so you can do checkouts over the network? Indeed that is right. This is why I need svn and apache permissions, and why I was trying to find a unified way. I am not sure what the best practice is as this is the first time I am using apache/svn/trac. I'm not sure you understand some things about how Apache works. In Apache it determines whether a user can use the site, or parts of it, by doing three checks. These are for access, authentication and authorization. The 'access' checks generally relate to what client hosts can access a site and isn't relevant to this discussion. The next thing it does is 'user authentication'. This is where it is determined whether a user has an account and whether the supplied password matches what is held for that user. It would appear you want to use SSPI across the whole site for this. The final thing is 'user authorisation'. Thus, although a user may have been authenticated, it doesn't mean that they automatically have access to the whole site as different parts of the sites may enforce different restrictions. As far as authorisation for Subversion repository access, this is controlled by file specified by AuthzSVNAccessFile. Because it only applies to Subversion repository access, it should only be defined for URL subset which maps to Subversion repository. Although Trac also performs authorisation, it is done within Trac and not at Apache level of configuration. So as to match up authorisation for Subversion repository access via Trac source browser, Trac can be configured to point at the same file as was pointed at by AuthzSVNAccessFile. This has to be done in Trac ini file. End result is you would have with VirtualHost or at root of server configuration: # Enable SSPI for site wide user authentication. AuthType SSPI AuthName TestProject SSPIAuth On SSPIAuthoritative On SSPIDomain groupinfra.com SSPIOfferBasic On #SSPIOmitDomain on //**this makes things a lot easier** #SSPIUsernameCase lower SSPIBasicPreferred On SSPIOfferSSPI off # Require that at least have authenticated user. Require valid-user # Where further authorisation regimes, must be applied additively. Satisfy All Location /svn DAV svn #SVNListParentPath on SVNPath C:\Projects\svn\TestProject #SVNParentPath C:\Projects\svn # Enable Subversion authorisation for just Subversion URL subset. AuthzSVNAccessFile C:\Program Files\Apache Group \Apache2\svnaccessfile.txt /Location Location /tracs\ SetHandler mod_python PythonHandler trac.web.modpython_frontend PythonOption TracEnv C:\Projects\trac\TestProject PythonOption TracUriRoot /tracs # NO authorisation done at Apache level as Trac does it internally. /Location Finally, in trac.ini, you need to have: authz_file = C:/Program Files/Apache Group/Apache2/svnaccessfile.txt You currently don't have this authz_file option in trac ini file. Having outlined what you need, suggest you go back and study Trac documentation and see what its says about authz_file as there may be other things related to that which need to be set. Graham Thanks again. -Original Message- From: trac-users@googlegroups.com [mailto:[EMAIL PROTECTED] On Behalf Of Graham Dumpleton Sent: 04 December 2007 01:04 To: Trac Users Subject: [Trac] Re: TRAC SVNPath oddness On Dec 4, 10:55 am, Panos Savvas [EMAIL PROTECTED] wrote: Hi Graham, Thanks for the advice. I will try this out tomorrow. Its presence in the root context is possibly what is causing the problem. I suppose this is typical of trying to configure 3 new technologies (new to me) at once. I assumed that referencing the AuthzSVNAccessFile in the root context would mean that it is inherited by all other contexts. This seems to be supported in that the authorisation works in all other contexts. Is this a flawed assumption however? The presence of AuthzSVNAccessFile is likely enough to trigger Subversion Apache authorisation handler for all URLs, but that handler is then expecting SVNPath to have also been defined in the same context, which it isn't. Thus possibly why you are getting an error. If this is the case, accessing stuff outside of /trac would also result in the same error. I am going to have
[Trac] Re: Trac ignore certain URLs?
On Nov 15, 8:39 am, Eno [EMAIL PROTECTED] wrote: I want to have a particular URL under a Trac site to be ignored by Trac. I have an Alias stanza in my vhost config that points that URL to a folder outside of Trac but how do I tell Trac to not handle that URL? (Right now, I get an error saying Trac couldn't find a handler for that URL). Presuming you are using mod_python, use something like: Alias /some/url /some/path Location /some/url SetHandler None /Location If you are using mod_wsgi, then the Alias directive should be sufficient, you just need to ensure you have it appearing before the WSGIScriptAlias for Trac. So, how are you hosting Trac under Apache? What method you are using will determine what you need to do. Graham --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Trac Users group. To post to this group, send email to trac-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/trac-users?hl=en -~--~~~~--~~--~--~---
[Trac] Re: two different tracs, but one apache only
On Nov 15, 1:29 am, Rainer Sokoll [EMAIL PROTECTED] wrote: Hi, is $SUBJECT possible? Background: I need to check whether all my plugins will work with the current .11 trunk. Right now, I'm on 0.11dev-r6137, but AFAIK, with r6138, the API has been changed, and some plugins may stop working correctly. If I use for example Location /tractest [...] PythonPath sys.path + ['/path/to/my/brandnew/trac'] [...] /Location my old trac is still in sys.path, correct? If so, which one will be used? Is there any other way beside using a second instance of apache and a second python installation? You can't do it with mod_python. The primary reason is that if using Trac in conjunction with Subversion, then to be safe and avoid potential problems with Python bindings for Subversion, you must force mod_python to run Trac in the main interpreter. In doing this though it will not be possible to be using two different versions of Trac for different instances. If only wishing to test stuff, you could always just run Trac through CGI. It will be slow but allow you to easily run it with different versions of the software you want to test. Another alternative for Apache is to use mod_wsgi (http:// www.modwsgi.org) instead. Using its daemon process mode it is possible to farm off distinct Trac instances to different daemon processes. Because they are in different processes you can safely run them in the main interpreter but also have them use different versions of software through appropriate setup of sys.path. To be absolutely safe and avoid problems if Trac is still installed in global site-packages, then mod_wsgi can be used in conjunction with Python virtual environments such as virtualenv.py (http://pypi.python.org/pypi/virtualenv). So perhaps just use CGI, but if interested in how to do it in mod_wsgi, can point out relevant documentation and step you through it. Graham --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Trac Users group. To post to this group, send email to trac-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/trac-users?hl=en -~--~~~~--~~--~--~---
[Trac] Re: Trac ignore certain URLs?
On Nov 15, 9:26 am, Eno [EMAIL PROTECTED] wrote: On Nov 14, 4:53 pm, Graham Dumpleton [EMAIL PROTECTED] wrote: Presuming you are using mod_python, use something like: Alias /some/url /some/path Location /some/url SetHandler None /Location If you are using mod_wsgi, then the Alias directive should be sufficient, you just need to ensure you have it appearing before the WSGIScriptAlias for Trac. So, how are you hosting Trac under Apache? What method you are using will determine what you need to do. Thanks, We are using mod_python under Apache2. I have the following in the vhost config (which doesn't work): Alias /files /home/www/files What if you change this to: Alias /files/ /home/www/files/ Graham Directory /home/www/files AllowOverride FileInfo AuthConfig Limit Options MultiViews Indexes SymLinksIfOwnerMatch Limit GET POST OPTIONS PROPFIND Order allow,deny Allow from all /Limit IndexOptions FancyIndexing IndexOrderDefault Descending Date /Directory Location /files SetHandler None /Location Location / SetHandler mod_python PythonHandler trac.web.modpython_frontend PythonOption TracEnv /usr/local/trac PythonOption TracUriRoot / PythonInterpreter main_interpreter /Location Location /login AuthType Basic AuthName Trac Server AuthUserFile /usr/local/trac/.htpasswd Require valid-user /Location Directory /usr/local/trac Order allow,deny Allow from all /Directory --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Trac Users group. To post to this group, send email to trac-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/trac-users?hl=en -~--~~~~--~~--~--~---
[Trac] Re: osx .5 leopard
On Nov 4, 3:17 pm, Alex da Franca [EMAIL PROTECTED] wrote: Am 04.11.2007 um 04:43 schrieb Graham Dumpleton: $: file /usr/libexec/apache2/mod_wsgi.so $: /usr/libexec/apache2/mod_wsgi.so: Mach-O bundle i386 For good measure, do a 'make distclean', rerun configure, and then only modify Makefile and rebuild/install, it should work. I acted on a fresh download, so I don't know, where make distclean would help. It should be obvious from the output of the build whether the options are being included with the compilation. all -arch options appear in the output for apxs and in the first output of libtool, the second libtool call doesn't have any -arch options. /usr/sbin/apxs -c -I/System/Library/Frameworks/Python.framework/ Versions/2.5/include/python2.5 -DNDEBUG -DMACOSX -DENABLE_DTRACE -Wc,- arch ppc -Wc,-arch ppc64 -Wc,-arch i386 -Wc,-arch x86_64 mod_wsgi.c -framework Python -u _PyMac_Error -framework Python -ldl /usr/share/apr-1/build-1/libtool --silent --mode=compile gcc- DDARWIN -DSIGPROCMASK_SETS_THREAD_MASK -no-cpp-precomp -I/usr/include/ apache2 -I/usr/include/apr-1 -I/usr/include/apr-1 -arch ppc -arch ppc64 -arch i386 -arch x86_64 -I/System/Library/Frameworks/ Python.framework/Versions/2.5/include/python2.5 -DNDEBUG -DMACOSX - DENABLE_DTRACE -c -o mod_wsgi.lo mod_wsgi.c touch mod_wsgi.slo /usr/share/apr-1/build-1/libtool --silent --mode=link gcc -o mod_wsgi.la -rpath /usr/libexec/apache2 -module -avoid-version mod_wsgi.lo -framework Python -u _PyMac_Error -framework Python -ldl Run file on .libs/mod_wsgi.so to work out what it was built for before installing. file .libs/mod_wsgi.so .libs/mod_wsgi.so: Mach-O bundle i386 :-( Hmmm, very odd. I may have misinterpreted what I was told by person who got it working. They said: mod_wsgi was easier. I actually built it as a universal binary: CPPFLAGS = -Wc,-arch ppc -Wc,-arch i386 -Wc,-arch x86_64 -I/ System/Library/Frameworks/Python.framework/Versions/2.5/include/ python2.5 -DNDEBUG -DMACOSX -DENABLE_DTRACE CFLAGS = -Wc,-arch ppc -Wc,-arch i386 -Wc,-arch x86_64 LDFLAGS = -arch ppc -arch i386 -arch x86_64 -framework Python -u _PyMac_Error -framework Python Since the build line was: mod_wsgi.la : mod_wsgi.c $(APXS) -c $(CPPFLAGS) $(CFLAGS) mod_wsgi.c $(LDFLAGS) $ (LDLIBS) I saw the multiple listing of the options as redundant. What you may actually have to do is change CFLAGS as explained before, but also add '-arch ppc -arch ppc64 -arch i386 -arch x86_64' into LDFLAGS as well. Let me know if that works instead. Another problem which has come up is MySQL. You can't use the precompiled MySQL distribution which is available as it was built on Tiger, which didn't produce x86_64 compatible binaries. I installed the precompiled tiger binaries of mysql (mysql-5.1.22-rc- osx10.4-i686) and it works so far on leopard. A little change was required in order to compile the mysql-python egg, but it seems to work so far. I thought, that python on leopard is 32 bit and therefore the 32 bit mysql-python egg and the 32 bit mysql distribution play happily together? The issue is that if you are using standard OS version of Apache 2.2 it is a full fat binary and if you have 64 bit CPU will run up as x86_64 and thus expect to have available x86_64 versions of all Apache modules and indirectly the Python framework, plus Python modules and libraries required by those modules. Python Framework on Leopard should be a full fat binary. See below example someone else sent me previously: [Macintosh:Library/Frameworks/Python.framework] benha% file Python Python: Mach-O universal binary with 4 architectures Python (for architecture ppc7400): Mach-O dynamically linked shared library ppc Python (for architecture ppc64): Mach-O 64-bit dynamically linked shared library ppc64 Python (for architecture i386): Mach-O dynamically linked shared library i386 Python (for architecture x86_64): Mach-O 64-bit dynamically linked shared library x86_64 Graham --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Trac Users group. To post to this group, send email to trac-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/trac-users?hl=en -~--~~~~--~~--~--~---
[Trac] Re: osx .5 leopard
On Nov 5, 1:38 am, Alex da Franca [EMAIL PROTECTED] wrote: mod_python doesn't seem to work still. I get: apachectl configtest httpd: Syntax error on line 121 of /private/etc/apache2/httpd.conf: Can't locate API module structure `python_module' in file /usr/libexec/ apache2/mod_python.so: dlsym(0x100218cc0, python_module): symbol not found This is a new error, I'll investigate that further. Hmmm, errors like that usually occur when Apache module compiled against wrong version of Apache is used. Ie., compiled for Apache 1.3 but then used with Apache 2.0 or 2.2. mod_wsgi seems to work OK, I've updated my page to mention adding options to LDFLAGS as well. Thanks for letting me know ir worked. but this time it refuses to use the mysql egg, because... you guessed it: wrong architecture. Hopefully the MySQL people will be quick in bringing out updated package as affecting some Django users as well. Graham --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Trac Users group. To post to this group, send email to trac-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/trac-users?hl=en -~--~~~~--~~--~--~---
[Trac] Re: Need Help with Trac-0.9.6
On Nov 5, 12:01 am, Denis [EMAIL PROTECTED] wrote: Hello. I have a problem: On Debian I tried to install Trac-0.9.6 at my home dir: /home/dz- apache2/ For this at the same dir were installed: 1. Apache2 $ ./configure --prefix=$/home/dz-apache2/local --enable-modules=all -- enable-mods-shared=all --enable-module=shared $ make $ make install 2. Python-2.4.4 3. Mod-Python-3.3.1 4. To make this work correctly I removed local libexpat.so.0, and made a symbolic link to system libexpat.so.0: $ cd /home/dz-apache2/local/lib $ rm libexpat.so.0 $ ln -s /usr/lib/libexpat.so.0 libexpat.so.0 All your fiddles with expat shared libraries could be causing problems. Generally expat library problems cause crashes, but can also cause strange behaviour due to memory corruption. So, why did you feel the need to fiddle with this? You can't just change around symlinks for shared libraries like this if the code requiring the shared library was compiled against header files for a different version in the first place. If Apache is ignoring the system expat library and using its own version, then when you run 'configure' for Apache ensure you supply relevant environment flags so it looks for and finds expat libraries in correct location, although if using system libraries it should find them automatically unless there is a 'dev' variant package for expat you don't have installed. Better still, upgrade to Python 2.5 which name spaces its own expat so that the problems with clashing expat versions doesn't occur. Graham 5. Then I installed sqlite-3.5.1, pysqlite-2.3.5, clearsilver-0.9.14 also Trac. Then I created Project Env: $ trac-admin /home/dz-apache2/local/TracTest initenv And tested Trac with embedded server tracd. All worked correctly. Then I tested Trac with Apache2 as CGI. There was a problem with You have no permissions to see this page, but that was solved by changing 1 string in apache httpd.conf from Deny from all to Allow from all 7. Then I tested Trac to be handled by mod_python. To do this I changed httpd.conf added following strings: Location /projects/TracTest SetHandler mod_python PythonInterpreter main_interpreter PythonHandler trac.web.modpython_frontend PythonOption TracEnv /home/dz-apache2/local/TracTest PythonOption TracUriRoot /projects/TracTest /Location Than I went tohttp://localhost/and saw Trac page with No formatting : ( and when I try to edit any page I get an error: Oops... Trac detected an internal error: Error binding parameter 0 - probably unsupported type. blah-blah File /home/dz-apache2/local/lib/python2.4/site-packages/trac/db.py, line 211, in _rollback_on_error return function(self, *args, **kwargs) InterfaceError: Error binding parameter 0 - probably unsupported type. When I press Search button: Oops... Trac detected an internal error: split blah-blah File /home/dz-apache2/local/lib/python2.4/site-packages/mod_python/ util.py, line 90, in __getattr__ raise AttributeError, name AttributeError: split Please, help me. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Trac Users group. To post to this group, send email to trac-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/trac-users?hl=en -~--~~~~--~~--~--~---
[Trac] Re: osx .5 leopard
On Nov 3, 12:51 am, Alex da Franca [EMAIL PROTECTED] wrote: Am 02.11.2007 um 14:37 schrieb Emmanuel Blot: I understood most of the Trac requirements were already provided OOB on Leopard: http://www.cmlenz.net/blog/2007/10/python-on-leopa.html thanks for the link. interesting stuff. so far I am very pleased with leopard, as the underlying unix has gotten some attention this time. nonetheless I wasn't very lucky with the apache modules and it took me some time to get my msql server as I like it to be. do you really need mod_fcgi (vs.mod_python) ? no particular reason. I was used to fcgid from two linux boxes, but I wouldn't mind to run it withmod_python, but as I wrote, I hae the exact same problems withmod_python. will need to compile apache as 32 bit app? I thought there may just be an appropriate ./configure option when compilingmod_python...? The Leopard compilation problems have already been dealt with elsewhere. For mod_wsgi at least, the required workaround is documented in: http://code.google.com/p/modwsgi/wiki/InstallationOnMacOSX A similar set of additional options would be used in relation to other Apache modules such as mod_python, mod_fastcgi etc. This workaround would be required if running on 64 bit Intel chips. Graham --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Trac Users group. To post to this group, send email to trac-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/trac-users?hl=en -~--~~~~--~~--~--~---
[Trac] Re: osx .5 leopard
On Nov 4, 11:08 am, Alex da Franca [EMAIL PROTECTED] wrote: Am 03.11.2007 um 23:04 schrieb Graham Dumpleton: The Leopard compilation problems have already been dealt with elsewhere. For mod_wsgi at least, the required workaround is documented in: http://code.google.com/p/modwsgi/wiki/InstallationOnMacOSX A similar set of additional options would be used in relation to other Apache modules such as mod_python, mod_fastcgi etc. This workaround would be required if running on 64 bit Intel chips. Thanks for the informative link. I've been pulling my last hair out over compiling mod_python on my MBP for a 64 bit apache. no dice. now I tried the steps for compiling and installing mod_wsgi, which is described in the link you sent me. The solution looks much like the one I came up meanwhile for mod_python, but still it does only compile a i386 version of the wsgi module: $: file /usr/libexec/apache2/mod_wsgi.so $: /usr/libexec/apache2/mod_wsgi.so: Mach-O bundle i386 For good measure, do a 'make distclean', rerun configure, and then only modify Makefile and rebuild/install, it should work. It should be obvious from the output of the build whether the options are being included with the compilation. Run file on .libs/mod_wsgi.so to work out what it was built for before installing. using the CFLAGS settings I was able to compile fcgid for 64-bit: $: file /usr/libexec/apache2/mod_fcgid.so $: /usr/libexec/apache2/mod_fcgid.so: Mach-O 64-bit bundle x86_64 that loads, but appearantly has still another problem with my setup. fastcgi, which comes preinstalled with leopard works, so I'll stick with that for now... Another problem which has come up is MySQL. You can't use the precompiled MySQL distribution which is available as it was built on Tiger, which didn't produce x86_64 compatible binaries. Graham --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Trac Users group. To post to this group, send email to trac-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/trac-users?hl=en -~--~~~~--~~--~--~---
[Trac] Re: Adding authentication on multiple users machine
On Nov 3, 9:34 am, postal2600 [EMAIL PROTECTED] wrote: Hy! I've installed Trac on a machine on which multiple users are using the same Apache server. How /where do i implement the following step of setting authentication for apache, considering that I don't have access to the httpd.conf (apache configuration file): Location /trac/login AuthType Basic AuthName Trac AuthUserFile /somewhere/trac.htpasswd Require valid-user /Location Or does anyone knows an alternative for my situation? I really want Trac for this project of mine. If you don't have access to the httpd.conf file, how are you setting up Trac to run in the first place? Do you have access to .htaccess files? Does the main Apache configuration define: AllowOverride FileInfo AuthConfig for the directories where you have .htaccess files? If this is a shared system it is likely that you will have neither of these configured, so there will not be any way of doing what you want. Graham --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Trac Users group. To post to this group, send email to trac-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/trac-users?hl=en -~--~~~~--~~--~--~---
[Trac] Re: Trac, Apache, and Subversion with Multiple Projects
On Nov 1, 3:23 pm, rjcarr [EMAIL PROTECTED] wrote: I'm sure this has been asked many times before, and is in a doc somewhere, but all I found was this (and it didn't quite answer my questions): http://trac.edgewall.org/wiki/TracMultipleProjectsSVNAccess I have an active multi-project environment for trac+svn served by apache. When you say hosted by Apache, do you mean under mod_python, or do you mean you are using Apache as the front end and proxying to tracd running behind it? It doesn't really matter except to the extent of knowing whether you are using mod_python. It all works fine and in my apache config files I have block pairs like this: Location /trac/project1 AuthType Basic AuthName Trac Auth AuthUserFile /path/to/project1/auth.htpasswd Require valid-user /Location Location /svn/project1 AuthType Basic AuthName SVN Auth AuthUserFile /path/to/project1/auth.htpasswd Require valid-user /Location If it is the same user/passwd database for Trac and svn for the same project, why are you setting AuthName differently for Trac vs svn as that would mean that you would need to enter your login information for each. If AuthName was the same for each, would need to only enter it once. But then this is probably academic if your never actually use the inbuilt ability of Subversion to browse the code from a web browser. :-) As you see, each project (trac+svn) has (and needs) its own auth file. As I said, this works, but the problem is each time a new project is added, an apache restart is needed (as far as I know). This isn't convenient so I'm looking for a better solution. If you want a different AuthName value for each project then you only have two options. The first is what you are doing now. The second is to use mod_python to implement your own authentication handler. This authentication handler would need to look at the request URI and from that work out which project you are targeting. If no credentials have been supplied, the project name derived from the URI would be used somehow in the auth realm name passed back in the response indicating authentication is required. If the credentials are present, the project name derived from the URI would be used to work out what database of user/password information should be use to perform the actual authentication. In short, bit of stuffing around, but could be done if using mod_python. May require mod_python 3.3.1 specifically though, older versions may not make it possible or make it harder at least. Graham --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Trac Users group. To post to this group, send email to trac-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/trac-users?hl=en -~--~~~~--~~--~--~---
[Trac] Re: One trac environment brings down the rest
Or in summary, in mod_python configuration force Trac to run in main interpreter: PythonInterpreter main_interpreter The only problem with that though is that if you are relying on the separation provided by the distinct sub interpreters so multiple Trac instances are separate, rather than relying on TracEnvParentDir setting, then the Trac instances can then interfere with each other if mod_python not configured correctly. Thus, if you start to have other problems with Trac instances interfering with each other when you force them all to run in main interpreter, post your config and can suggests changes. Graham On Oct 26, 12:12 am, Noah Kantrowitz [EMAIL PROTECTED] wrote: Please read ticket 2611 for the fix. --Noah On Oct 25, 2007, at 10:02 AM, Eno wrote: We're running multiple Trac environments with mod_python and Apache2 and one of the instances seems to be messing up mod_python. The error I see in the Apache log says: [Thu Oct 25 09:51:24 2007] [error] [client 161.221.68.43] PythonHandler trac.web.modpython_frontend: Traceback (most recent call last): [Thu Oct 25 09:51:24 2007] [error] [client 161.221.68.43] PythonHandler trac.web.modpython_frontend: File /usr/local/lib/ python2.4/site-packages/mod_python/apache.py, line 299, in HandlerDispatch\nresult = object(req) [Thu Oct 25 09:51:24 2007] [error] [client 161.221.68.43] PythonHandler trac.web.modpython_frontend: File /usr/local/lib/ python2.4/site-packages/trac/web/modpython_frontend.py, line 87, in handler\ngateway.run(dispatch_request) [Thu Oct 25 09:51:24 2007] [error] [client 161.221.68.43] PythonHandler trac.web.modpython_frontend: File /usr/local/lib/ python2.4/site-packages/trac/web/wsgi.py, line 87, in run\n response = application(self.environ, self._start_response) [Thu Oct 25 09:51:24 2007] [error] [client 161.221.68.43] PythonHandler trac.web.modpython_frontend: File /usr/local/lib/ python2.4/site-packages/trac/web/main.py, line 391, in dispatch_request\nenv = _open_environment(env_path, run_once=run_once) [Thu Oct 25 09:51:24 2007] [error] [client 161.221.68.43] PythonHandler trac.web.modpython_frontend: File /usr/local/lib/ python2.4/site-packages/trac/web/main.py, line 58, in _open_environment\nenv_cache[env_path] = open_environment(env_path) [Thu Oct 25 09:51:24 2007] [error] [client 161.221.68.43] PythonHandler trac.web.modpython_frontend: File /usr/local/lib/ python2.4/site-packages/trac/env.py, line 462, in open_environment \nenv = Environment(env_path) [Thu Oct 25 09:51:24 2007] [error] [client 161.221.68.43] PythonHandler trac.web.modpython_frontend: File /usr/local/lib/ python2.4/site-packages/trac/env.py, line 142, in __init__\n load_components(self) [Thu Oct 25 09:51:24 2007] [error] [client 161.221.68.43] PythonHandler trac.web.modpython_frontend: File /usr/local/lib/ python2.4/site-packages/trac/loader.py, line 140, in load_components \n__import__(module) [Thu Oct 25 09:51:24 2007] [error] [client 161.221.68.43] PythonHandler trac.web.modpython_frontend: File /usr/local/lib/ python2.4/site-packages/trac/versioncontrol/svn_fs.py, line 56, in ? \nfrom svn import fs, repos, core, delta [Thu Oct 25 09:51:24 2007] [error] [client 161.221.68.43] PythonHandler trac.web.modpython_frontend: File /usr/local/lib/ python2.4/svn/fs.py, line 19, in ?\nfrom libsvn.fs import * [Thu Oct 25 09:51:24 2007] [error] [client 161.221.68.43] PythonHandler trac.web.modpython_frontend: File /usr/local/lib/ python2.4/libsvn/fs.py, line 29, in ?\nimport core [Thu Oct 25 09:51:24 2007] [error] [client 161.221.68.43] PythonHandler trac.web.modpython_frontend: File /usr/local/lib/ python2.4/libsvn/core.py, line 3057, in ?\nsvn_pool_create() [Thu Oct 25 09:51:24 2007] [error] [client 161.221.68.43] PythonHandler trac.web.modpython_frontend: File /usr/local/lib/ python2.4/libsvn/core.py, line 1098, in svn_pool_create\nreturn apply(_core.svn_pool_create, args) [Thu Oct 25 09:51:24 2007] [error] [client 161.221.68.43] PythonHandler trac.web.modpython_frontend: TypeError: argument number 0: a 'apr_pool_t *' is expected, 'instance(libsvn.core.GenericSWIGWrapper instance at 0x8b3fb6c)' is received (Ive removed referrer info from this log). Is there a way to re-create an environment but save all the existing database and attachments? I tried doing a trac-admin upgrade on the messed up environment. it runs for awhile before crashing mod_python again. I dont know Python so this is hard to troubleshoot for me. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Trac Users group. To post to this group, send email to trac-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at
[Trac] Re: Trac 0.10 and 0.11 on the same server ? with the same database ?
It also depends on what you mean by 'server'. If you mean two independent 'tracd' processes on a host server then you would be okay, but try loading two different versions of Trac into mod_python or embedded mode of mod_wsgi using the one Apache server, then you may have issues if they for some reason require different versions of some third party extension module for Python. You should be okay with daemon mode of mod_wsgi as long as you use the same Python version. Using fastcgi solutions should also be okay. So, just be mindful of your hosting solution as well. Graham On Oct 24, 9:31 am, solo turn [EMAIL PROTECTED] wrote: this should be no problem, just add it to the python path at your wish. ? for the database it depends what you mean. for the contents/schema no, as it is slightly different, and starting with 0.11 suggest to upgrade. rupert. On 10/18/07, cl [EMAIL PROTECTED] wrote: hi everybody, Is it possible to have both Trac 0.10-stable and 0.11-stable running in parallel on the same server ? If yes, can they share the same database ? Thanks in advance for the feedback Best regards, Christophe --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Trac Users group. To post to this group, send email to trac-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/trac-users?hl=en -~--~~~~--~~--~--~---
[Trac] Re: apache config files for trac
On Oct 11, 6:04 am, Gunnar Thielebein [EMAIL PROTECTED] wrote: Hi. someone knows a better regex for 2 trac environments one with accountmanager plugin the other with apache ldap auth this line LocationMatch /[^/]+/login does interfer with all webapps which have a /login my config entries two debian sites-enable/ files are: Location /own SetHandler mod_python PythonInterpreter main_interpreter PythonHandler trac.web.modpython_frontend #PythonOption TracEnvParentDir /var/own PythonOptionTracEnv /var/trac/own PythonOption TracUriRoot /own SetEnv PYTHON_EGG_CACHE /var/tmp /Location Location /trac SetHandler mod_python PythonInterpreter main_interpreter PythonHandler trac.web.modpython_frontend #PythonOption TracEnvParentDir /var/trac PythonOptionTracEnv /var/trac/trac PythonOption TracUriRoot /trac SetEnv PYTHON_EGG_CACHE /var/tmp /Location LocationMatch /[^/]+/login AuthType Basic AuthName Trac Require valid-user AuthBasicProvider ldap AuthLDAPURL ldap://ldap.tpip.net:389/dc=,dc=net?uid; AuthLDAPGroupAttribute memberUid AuthLDAPGroupAttributeIsDN off Require ldap-group cn=Trac-TEST Users,ou=Groups,dc=,dc=net /LocationMatch Just duplicate the section and explicitly list the full URL for the Trac you want it applied to instead of using a pattern. Location /trac/login AuthType Basic AuthName Trac Require valid-user AuthBasicProvider ldap AuthLDAPURL ldap://ldap.tpip.net:389/dc=,dc=net?uid; AuthLDAPGroupAttribute memberUid AuthLDAPGroupAttributeIsDN off Require ldap-group cn=Trac-TEST Users,ou=Groups,dc=,dc=net /Location In doing this, use Location, not LocationMatch. Read the Apache documentation on how these directives work for more information. Graham --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Trac Users group. To post to this group, send email to trac-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/trac-users?hl=en -~--~~~~--~~--~--~---
[Trac] Re: Virtual Host with Multiple projects having login problems.
I'm going to get quite angry with Google Groups web interface soon. Unless my post turns up at a later time, this is the second time today that I have submitted a post, which it has said was successful and it just vanished. Google Groups is getting worse and worse these days, especially with their search results often being quite behind. :-( Anyway, getting back to the basics of this problem. What is the URL you are using for the login page? Is the browser popup for Basic authentication being displayed so you can enter login/passwd and is the Auth Realm displayed what you expect? Is is it the same login page that displays the Authentication information not available error message, but only doing so after entering a correct login/password for an account name that is actually configured for that Trac project? Are there any auth errors in the Apache error logs? Do the Apache error logs confirm that Apache was actually restarted after you made the Apache configuration change? Apologies if this is a duplicate. Graham On Oct 9, 3:01 am, Robert Rouse [EMAIL PROTECTED] wrote: I put them like that and there was no change there either. -Original Message- From: trac-users@googlegroups.com [mailto:[EMAIL PROTECTED] On Behalf Of Andy Hunn Sent: Monday, October 08, 2007 11:12 AM To: trac-users@googlegroups.com Subject: [Trac] Re: Virtual Host with Multiple projects having login problems. Try this: Location / SetHandler mod_python PythonInterpreter main_interpreter PythonHandler trac.web.modpython_frontend PythonOption TracEnvParentDir /var/trac/projects PythonOption TracUriRoot / /Location LocationMatch /[^/]+/login AuthType Basic AuthName Deksesuma Trac Server AuthUserFile /var/trac/.htpasswd Require valid-user /LocationMatch Andrew Hunn [EMAIL PROTECTED] Sypherlink, Inc. 6500 Emerald Parkway, Suite 175 Dublin, OH 43016 TEL: 614.652.6100 x6219 -Original Message- From: trac-users@googlegroups.com [mailto:[EMAIL PROTECTED] On Behalf Of Robert Rouse Sent: Monday, October 08, 2007 10:20 AM To: trac-users@googlegroups.com Subject: [Trac] Virtual Host with Multiple projects having login problems. I spoke too soon. I'm still getting the authentication not available error message. -Original Message- From: trac-users@googlegroups.com [mailto:[EMAIL PROTECTED] On Behalf Of Graham Dumpleton Sent: Friday, October 05, 2007 5:46 PM To: Trac Users Subject: [!! SPAM] [Trac] Re: Virtual Host with Multiple projects having login problems. Sorry, I missed the obvious when I first replied. Try: LocationMatch /[^/]+/login AuthType Basic AuthName Deksesuma Trac Server AuthUserFile /var/trac/.htpasswd Require valid-user /LocationMatch The Location directive by default only does glob style matching, not regex. Thus you need to use LocationMatch with what you want to do. Graham On Oct 5, 9:48 pm, Robert Rouse [EMAIL PROTECTED] wrote: Hello, I'm using a VPS with Plesk 8.2.1, so I'm running apache 2.0.58. When I switched the directives around, nothing changed. I might have to try wsgi if no one else comes up with a suggestion. -Original Message- From: trac-users@googlegroups.com [mailto:[EMAIL PROTECTED] On Behalf Of Graham Dumpleton Sent: Thursday, October 04, 2007 10:33 PM To: Trac Users Subject: [!! SPAM] [Trac] Re: Virtual Host with Multiple projects having login problems. On Oct 5, 10:43 am, Raiko [EMAIL PROTECTED] wrote: Hello, I have the following directives in my apache configuration. Location / SetHandler mod_python PythonHandler trac.web.modpython_frontend PythonOption TracEnvParentDir /var/trac/projects PythonOption TracUriRoot / /Location Location /[^/]+/login AuthType Basic AuthName Deksesuma Trac Server AuthUserFile /var/trac/.htpasswd Require valid-user /Location When I try to log in, I get the Authentication information not available error message. I searched the group and I see similar directives, but they don't work for me. If I put the directive under my main domain instead of a subdomain, it works. What version of Apache are you using? What happens if you change the order of the two Location directives around so the more specific one comes first? Does it still not work. Does your physical document root directory specified by DocumentRoot directive have files and/or subdirectories which match the lead components of what would be the login URL? FWIW, the way that the Location directive is used with mod_python to setup Trac causes a lot of problems at times because of interactions with physical files in actual document root. The way the directives are used in mod_wsgi avoids the problems that mod_python often has and you may find it simpler to use mod_wsgi
[Trac] Re: Virtual Host with Multiple projects having login problems.
Lets try some basics then. What is the actual URL you are using to the browser when going to the login page? Does the HTTP Basic authentication popup for the browser actually come up and with the correct Auth Realm showing? Is it this same login page which is showing the Authentication information not available error message from Trac? Were there any auth related error messages in the Apache error log file? Do the Apache error log files confirm that Apache was restarted after you changed the Apache configuration? Graham On Oct 9, 3:01 am, Robert Rouse [EMAIL PROTECTED] wrote: I put them like that and there was no change there either. -Original Message- From: trac-users@googlegroups.com [mailto:[EMAIL PROTECTED] On Behalf Of Andy Hunn Sent: Monday, October 08, 2007 11:12 AM To: trac-users@googlegroups.com Subject: [Trac] Re: Virtual Host with Multiple projects having login problems. Try this: Location / SetHandler mod_python PythonInterpreter main_interpreter PythonHandler trac.web.modpython_frontend PythonOption TracEnvParentDir /var/trac/projects PythonOption TracUriRoot / /Location LocationMatch /[^/]+/login AuthType Basic AuthName Deksesuma Trac Server AuthUserFile /var/trac/.htpasswd Require valid-user /LocationMatch Andrew Hunn [EMAIL PROTECTED] Sypherlink, Inc. 6500 Emerald Parkway, Suite 175 Dublin, OH 43016 TEL: 614.652.6100 x6219 -Original Message- From: trac-users@googlegroups.com [mailto:[EMAIL PROTECTED] On Behalf Of Robert Rouse Sent: Monday, October 08, 2007 10:20 AM To: trac-users@googlegroups.com Subject: [Trac] Virtual Host with Multiple projects having login problems. I spoke too soon. I'm still getting the authentication not available error message. -Original Message- From: trac-users@googlegroups.com [mailto:[EMAIL PROTECTED] On Behalf Of Graham Dumpleton Sent: Friday, October 05, 2007 5:46 PM To: Trac Users Subject: [!! SPAM] [Trac] Re: Virtual Host with Multiple projects having login problems. Sorry, I missed the obvious when I first replied. Try: LocationMatch /[^/]+/login AuthType Basic AuthName Deksesuma Trac Server AuthUserFile /var/trac/.htpasswd Require valid-user /LocationMatch The Location directive by default only does glob style matching, not regex. Thus you need to use LocationMatch with what you want to do. Graham On Oct 5, 9:48 pm, Robert Rouse [EMAIL PROTECTED] wrote: Hello, I'm using a VPS with Plesk 8.2.1, so I'm running apache 2.0.58. When I switched the directives around, nothing changed. I might have to try wsgi if no one else comes up with a suggestion. -Original Message- From: trac-users@googlegroups.com [mailto:[EMAIL PROTECTED] On Behalf Of Graham Dumpleton Sent: Thursday, October 04, 2007 10:33 PM To: Trac Users Subject: [!! SPAM] [Trac] Re: Virtual Host with Multiple projects having login problems. On Oct 5, 10:43 am, Raiko [EMAIL PROTECTED] wrote: Hello, I have the following directives in my apache configuration. Location / SetHandler mod_python PythonHandler trac.web.modpython_frontend PythonOption TracEnvParentDir /var/trac/projects PythonOption TracUriRoot / /Location Location /[^/]+/login AuthType Basic AuthName Deksesuma Trac Server AuthUserFile /var/trac/.htpasswd Require valid-user /Location When I try to log in, I get the Authentication information not available error message. I searched the group and I see similar directives, but they don't work for me. If I put the directive under my main domain instead of a subdomain, it works. What version of Apache are you using? What happens if you change the order of the two Location directives around so the more specific one comes first? Does it still not work. Does your physical document root directory specified by DocumentRoot directive have files and/or subdirectories which match the lead components of what would be the login URL? FWIW, the way that the Location directive is used with mod_python to setup Trac causes a lot of problems at times because of interactions with physical files in actual document root. The way the directives are used in mod_wsgi avoids the problems that mod_python often has and you may find it simpler to use mod_wsgi. :-) Graham --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Trac Users group. To post to this group, send email to trac-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/trac-users?hl=en -~--~~~~--~~--~--~---
[Trac] Re: Virtual Host with Multiple projects having login problems.
Sorry, I missed the obvious when I first replied. Try: LocationMatch /[^/]+/login AuthType Basic AuthName Deksesuma Trac Server AuthUserFile /var/trac/.htpasswd Require valid-user /LocationMatch The Location directive by default only does glob style matching, not regex. Thus you need to use LocationMatch with what you want to do. Graham On Oct 5, 9:48 pm, Robert Rouse [EMAIL PROTECTED] wrote: Hello, I'm using a VPS with Plesk 8.2.1, so I'm running apache 2.0.58. When I switched the directives around, nothing changed. I might have to try wsgi if no one else comes up with a suggestion. -Original Message- From: trac-users@googlegroups.com [mailto:[EMAIL PROTECTED] On Behalf Of Graham Dumpleton Sent: Thursday, October 04, 2007 10:33 PM To: Trac Users Subject: [!! SPAM] [Trac] Re: Virtual Host with Multiple projects having login problems. On Oct 5, 10:43 am, Raiko [EMAIL PROTECTED] wrote: Hello, I have the following directives in my apache configuration. Location / SetHandler mod_python PythonHandler trac.web.modpython_frontend PythonOption TracEnvParentDir /var/trac/projects PythonOption TracUriRoot / /Location Location /[^/]+/login AuthType Basic AuthName Deksesuma Trac Server AuthUserFile /var/trac/.htpasswd Require valid-user /Location When I try to log in, I get the Authentication information not available error message. I searched the group and I see similar directives, but they don't work for me. If I put the directive under my main domain instead of a subdomain, it works. What version of Apache are you using? What happens if you change the order of the two Location directives around so the more specific one comes first? Does it still not work. Does your physical document root directory specified by DocumentRoot directive have files and/or subdirectories which match the lead components of what would be the login URL? FWIW, the way that the Location directive is used with mod_python to setup Trac causes a lot of problems at times because of interactions with physical files in actual document root. The way the directives are used in mod_wsgi avoids the problems that mod_python often has and you may find it simpler to use mod_wsgi. :-) Graham --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Trac Users group. To post to this group, send email to trac-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/trac-users?hl=en -~--~~~~--~~--~--~---
[Trac] Re: Problem with Threads
On Oct 4, 4:44 pm, Denis [EMAIL PROTECTED] wrote: Hi, I'm trying to install Trac-0.8 on Debian at my home dir, where Apache 1.3.37, Python2.4 Mod_Python-2.7.11 were already installed. But Python2.4 was installed --without-threads. Then I successfully installed ClearSilver0.9.9. SQLite-3.4.2. Then after installing pySQLite-2.3.5 I made test: from pysqlite2 import test Traceback (most recent call last): File stdin, line 1, in ? File /home/the_gremlin/local/lib/python2.4/site-packages/pysqlite2/ test/__init__.py, line 35, in ? from pysqlite2.test import dbapi, types, userfunctions, factory, transactions,\ File /home/the_gremlin/local/lib/python2.4/site-packages/pysqlite2/ test/dbapi.py, line 26, in ? import threading File /home/the_gremlin/local/lib/python2.4/threading.py, line 6, in ? import thread ImportError: No module named thread I read all available documentation but I didn't find how to fix it. You will need to install Python which includes support for threading. That or use a database backend which doesn't require/support multithreading. Is there a particular reason you are running Python without thread support. There isn't much reason these days to be doing so. Graham --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Trac Users group. To post to this group, send email to trac-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/trac-users?hl=en -~--~~~~--~~--~--~---
[Trac] Re: Virtual Host with Multiple projects having login problems.
On Oct 5, 10:43 am, Raiko [EMAIL PROTECTED] wrote: Hello, I have the following directives in my apache configuration. Location / SetHandler mod_python PythonHandler trac.web.modpython_frontend PythonOption TracEnvParentDir /var/trac/projects PythonOption TracUriRoot / /Location Location /[^/]+/login AuthType Basic AuthName Deksesuma Trac Server AuthUserFile /var/trac/.htpasswd Require valid-user /Location When I try to log in, I get the Authentication information not available error message. I searched the group and I see similar directives, but they don't work for me. If I put the directive under my main domain instead of a subdomain, it works. What version of Apache are you using? What happens if you change the order of the two Location directives around so the more specific one comes first? Does it still not work. Does your physical document root directory specified by DocumentRoot directive have files and/or subdirectories which match the lead components of what would be the login URL? FWIW, the way that the Location directive is used with mod_python to setup Trac causes a lot of problems at times because of interactions with physical files in actual document root. The way the directives are used in mod_wsgi avoids the problems that mod_python often has and you may find it simpler to use mod_wsgi. :-) Graham --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Trac Users group. To post to this group, send email to trac-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/trac-users?hl=en -~--~~~~--~~--~--~---
