[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 kforge-user
mailing list