[knowledgeforge-user] [kforge-user] Trac admin and plugins

Rufus Pollock rufus.pollock at okfn.org
Tue Aug 21 11:13:44 UTC 2007


Daniel Weck wrote:
> Dear Kforge / KnowledgeForge users,
> 
> I am trying to install a few Trac plugins for agile software project  
> management:
> 
> http://www.trac-hacks.org/wiki/TimingAndEstimationPlugin
> http://www.trac-hacks.org/wiki/ScrumBurndownPlugin
> http://www.trac-hacks.org/wiki/WorkLogPlugin
> 
> Using the Trac "admin" interface, I can upload the plugin fine:
> http://knowledgeforge.net/YOUR_PROJECT_NAME/trac/admin/general/plugin
> 
> I have checked inside the 'plugins' directory using WebDav, and the  
> '.egg' files are there, like expected.
> 
> However, it seems that the Trac plugin list is not updated properly,  
> as none of the new plugins actually appear here.
> 
> Using WebDav, I can edit the Trac configuration file (conf/trac.ini)  
> to directly enable the plugins:
> 
> ---
> [components]
> timingandestimationplugin.* = enabled
> burndown.* = enabled
> worklog.* = enabled
> ---
> 
> ...but this does not seems to work.
> 
> I think this is because for most plugins, the following command line  
> instruction is needed to complete installation:
> $trac-admin /path/to/projenv upgrade

Certainly the TimingAndEstimationPlugin appears to require this, from

http://www.trac-hacks.org/wiki/TimingAndEstimationPlugin

...
3. Run $ trac-admin /path/to/projenv upgrade
...

Sadly I don't think trac provides a way to 'self-upgrade' from its web 
admin interface.

> However this is impossible as KnowledgeForge does not provide a shell  
> access.

Sure. The problem is that shell access gives people some fairly serious 
ability -- both to do good and to do harm (not necessarily maliciously 
btw). Furthermore it is particularly problematic when most of this stuff 
is owned by the web-user because that is the user who created it. This 
means, for example, that to allow users to run trac-admin on their 
environment from the command line:

1. Either: requires some pretty complicated permissions setup + suexec
2. Or: the provision of ability of general users to sudo to the www-data 
user: not a great security idea :)

> Actually, the httpd / tracd server should also be restarted in order  
> to understand the URLs for the new plugin functionality. That of  
> course is not something a KnowledgeForge can do ;)

Yes.

> I thought I would be able to read the Trac log in order to find a  
> solution to this problem, but even the log doesn't work (no file is  
> generated in my WebDav mounted filesystem):
> http://knowledgeforge.net/YOUR-PROJECT-NAME/trac/admin/general/logging
> (File-DEBUG-./trac.log)

By default trac seems to disable logging:

[logging]
log_file = trac.log
log_level = DEBUG
log_type = none

Note the log_type = none. If you set this to:

log_type = file

It should start working. Though if using this on a live production 
machine please reset this/set level to INFO once debugging is done.

> I have tried log-out + log-in, without success.
> 
> Trac is great, but without plugins, the collaborative functionality  
> is pretty limited.

I see that. It would be nice if these trac-plugins did 'just work' on 
KForge. That said some of the things you mention would always seem to 
require sysadmin intervenetion (e.g. restarting tracd/the webserver). In 
that case I'm not sure how much this is a *KForge* issue rather than an 
issue for the sysadmin of a given KForge installation -- that is, it is 
up to the sysadmin to install the extra trac plugins he/she wants (in 
which case they are then available to all projects and the shell access 
issue goes away).

~rufus




More information about the knowledgeforge-user mailing list