Permission denied when creating 'boxes-300.css'

[robin.pellatt@…]

Full error message is:

Permission denied: '/opt/trac/lib/python2.6/site-packages/tracwikiextras/htdocs/css/boxes-300.css'

This happens because the tracwikiextras tries to create the "boxes-300.css" file, but Trac is running under www-data and does not have permission to write to site-packages, which was created using sudo.

I'm not sure if there are standards for this, but IMHO a Python package should only be writing to site-packages at install time, not at runtime.

[anonymous]

Workaround is to create and deploy your own css files. If you are using the default setup, you will need the following files:

boxes-300.css:

.wikiextras.box.right { width: 278px; }
.wikiextras.box.icon.center,
.wikiextras.box.icon.right { width: 243px; }

boxes-300-toc.css:

.wiki-toc { width: 278px !important; }

If you have changed the default box width, look at the __init__() function in boxes.py to determine the widths required.

[Mikael Relbe]

Replying to robin.pellatt@gmail.com:

I'm not sure if there are standards for this, but IMHO a Python package should only be writing to site-packages at install time, not at runtime.

Your'e absolutely correct, and this was the main remark from Christian Boos when he reviewed the code.

Any idea how the width could be defined without generating dynamic content is welcome!

[Robert Inder]

I don't know how to avoid generating dynamic content, BUT could you at least document that it is required.

Currently, the plugin's page just refers to the generic plugin installation instructions. But following those instructions results in this error.

Given the error message, Google finds ticket #10300, which suggests adding write permission to a directory, though that doesn't actually fix the problem.

And this ticket seems to say the plugin will work if I create two .css files, but does not say where to create them

So thus far I've spent over an hour believing that there is a way to get this plugin to work, but failing to work out how to actually do it.

You need some instructions that say that installing the plugin will need some kind of extra step (either creating a file or setting write permission), and that explicitly say how to determine which directory is involved.

[Robert Inder]

On a related note: I have several trac projects on the same trac installation. I've not seen anything mentioning that the location of the problematic .css files is specific to the project/installation. Does this mean that all the trac projects/installations on the server will be using the same file? And so, necessarily, the same style settings?

[robin.pellatt@…]

@Robertll - look at the error message in the ticket description. Assuming you see a similar one, this tells you exactly where the plugin is trying to create the files, so that is where you have to put them manually. In my case I put them in: /opt/trac/lib/python2.6/site-packages/tracwikiextras/htdocs/css You will notice that this is in the Python "site-packages" directory, so this means all Trac projects will use the same styles. You could use virtualenv to split them up into multiple Trac instances if that is a problem, but that sounds a bit overkill. Cheers, Robin

[Mikael Relbe]

I am sorry for the inconveniences I've caused you due to bad design choices I once made. I have updated the wiki page (WikiExtrasPlugin@26) with a comment on this. (I only use Windows myself and have no experience in using *nix OS with Trac.)

[anonymous]

Thanks for the prompt response, Robin.

I'm not seeing that message anywhere.

I'm seeing the message on #10300, except with different file names because I'm on CentOS. And that message does not contain a file name.

I've tried enabling trac logging, but trac.log just contains that same message.

I've tried creating boxes-300.css and boxes-300-toc.css in ~trac/.python-eggs/TracWikiExtras-0.13.1-py2.6.egg-tmp/tracwikiextras/htdocs/css/, but it makes no difference. I've also tried making that directory writable by group "apache", to no avail...

[anonymous]

Replying to mrelbe:

I am sorry for the inconveniences I've caused you due to bad design choices I once made. I have updated the wiki page (WikiExtrasPlugin@26) with a comment on this.

That's good. Thanks for responding.

Unfortunately, it hasn't solved my problem:-(

When I looked, /usr/lib/python2.6/site-packages/tracwikiextras did not exist. Should it?

I tried creating that directory, and making it world writable. But the error is unchanged.

I also tried creating creating /usr/lib/python2.6/site-packages/tracwikiextras/htdocs/css/boxes-300.css (and boxes-300-toc.css), but still no change.

[anonymous]

I've realised that (in line with all the other plugins I am using) I have (tried to) install this plugin "For a single project".

So I have not used "easy_install".

Is this relevant? Does this explain why "site-packages/trackwikiextras" did not exist? And why creating it does not solve the problem?

If so, where is it looking instead?

Robert.

[Mikael Relbe]

Replying to anonymous:

When I looked, /usr/lib/python2.6/site-packages/tracwikiextras did not exist. Should it?

I tried creating that directory, and making it world writable. But the error is unchanged.

I also tried creating creating /usr/lib/python2.6/site-packages/tracwikiextras/htdocs/css/boxes-300.css (and boxes-300-toc.css), but still no change.

Sorry, my bad for being unclear. At least on Windows (not accurately sure about *nix) you should see an .egg folder like site-packages/TracWikiExtras-x.y-py2.7.egg/. In there you should find the folder tracwikiextras/htdocs/css. This folder needs to have file permissions that allow the Trac process to create and write files into.

Hope that helps.

[Robert Inder]

Ah! OK, no -- site-packages/TracWikiExtras-0.13.1-py2.6.egg didn't exist either.

Possibly because I have installed for a single project, not globally via easy_install.

Ah ha!!!!

When I CREATE /usr/lib/python2.6/site-packages/TracWikiExtras-0.13.1-py2.6.egg and then move my tracwikiextras into it, I get somewhere. Well, at least, I can access the trac project without getting an error.

However, the plugin is not showing up on the Admin page (even though it is enabled in trac.ini), and if I put [[AboutWikiBoxes]] into a Wiki page, I just get a link that invites me to create a Wiki page called AboutWikiBoxes.

So, some progress, but still don't have a working plugin.

Robert.

[Mikael Relbe]

Try this:

1. Remove existing files and folders of the plugin from the Python site-packages folder (since you have manually created such).
2. Download the zipped source to a local folder, unzip and you should find setup.py
3. Run: python setup.py install

You should now have a clean and registered installation of the plugin. Then check file permissions according to comment:10.

[Robert Inder]

Ignore, if you will, forty minutes of complete panic when autocomplete in Firefox took me to an obsolete server I haven't been to for months (in preference to the one I was working on yesterday), and thus presented me with error messages about permissions on the database file...

The sequence of steps in comment:12 followed by the permissions tweaks in comment:10 has got the plugin working.

I'm not entirely happy, mind.

All the other plugins are installed via a "plugins" directory for each individual project, the idea being to allow different projects to have different sets of plugins (and, in particular, to allow me to use a "sandbox" project for testing plugins, and combinations of plugins, before allowing them to get under people's feet. But this plugin has had to be installed in a different way, and for ALL projects.

Life is short, so I will document what has happened and live with it.

But the installation/setup procedure really really needs some attention -- if I had known how long it was going to take to get this plugin working, I probably would not have started.

So many thanks for your work in creating the plugin, and your help in getting it going. It is appreciated.

But can I urge you to either streamline the installation process, or at least document its limitations! (Bloody users, never happy, eh!)

Robert.

[Mark Schenk]

Proposed fix for permission-denied error

[Mark Schenk]

This is the fix I implemented on my (linux-)server to get it running. Should work on Windows too and eliminates the need to write to any filesystem-location.

Feel free to use or incorporate in the tree: attachment:wikiextrasplugin-fix-11041.diff​

The diff is against 0.13.1

[Mikael Relbe]

In 14311:

WikiExtrasPlugin/0.13.2dev: Do not create physical css-files dynamically. Fixes #11041

Patch by mschenk, many thanks!