Hi. When trying to setup trac instance, I am getting the error that read and write permissions for the user root to the sqlite database are required. But root has write permissions for all the components of the path - see the exact error message below. Setting the file world writable fixes the problem, but I do not consider it a correct solution. The software should be modified to set and use proper user/group permissions. (And to report the problem properly, since telling that root cannot write the file is not true - this should be forwarded upstream probably, would you do that?) Reproducible: Always Steps to Reproduce: 1. emerge trac 2. trac-admin /var/lib/trac/project_name initenv 3. leave the defaults in (ok, actually I changed the project name) 4. /etc/init.d/tracd start 5. your_favourite_browser http://your_trac_server:8000/project_name Actual Results: Traceback (most recent call last): File "/usr/lib/python2.5/site-packages/trac/web/api.py", line 367, in send_error 'text/html') File "/usr/lib/python2.5/site-packages/trac/web/chrome.py", line 688, in render_template data = self.populate_data(req, data) File "/usr/lib/python2.5/site-packages/trac/web/chrome.py", line 596, in populate_data d['chrome'].update(req.chrome) File "/usr/lib/python2.5/site-packages/trac/web/api.py", line 194, in __getattr__ value = self.callbacks[name](self) File "/usr/lib/python2.5/site-packages/trac/web/chrome.py", line 464, in prepare_request for category, name, text in contributor.get_navigation_items(req): File "/usr/lib/python2.5/site-packages/trac/ticket/web_ui.py", line 162, in get_navigation_items if 'TICKET_CREATE' in req.perm: File "/usr/lib/python2.5/site-packages/trac/perm.py", line 523, in has_permission return self._has_permission(action, resource) File "/usr/lib/python2.5/site-packages/trac/perm.py", line 537, in _has_permission check_permission(action, perm.username, resource, perm) File "/usr/lib/python2.5/site-packages/trac/perm.py", line 424, in check_permission perm) File "/usr/lib/python2.5/site-packages/trac/perm.py", line 282, in check_permission get_user_permissions(username) File "/usr/lib/python2.5/site-packages/trac/perm.py", line 357, in get_user_permissions for perm in self.store.get_user_permissions(username): File "/usr/lib/python2.5/site-packages/trac/perm.py", line 173, in get_user_permissions db = self.env.get_db_cnx() File "/usr/lib/python2.5/site-packages/trac/env.py", line 264, in get_db_cnx return DatabaseManager(self).get_connection() File "/usr/lib/python2.5/site-packages/trac/db/api.py", line 76, in get_connection return self._cnx_pool.get_cnx(self.timeout or None) File "/usr/lib/python2.5/site-packages/trac/db/pool.py", line 174, in get_cnx return _backend.get_cnx(self._connector, self._kwargs, timeout) File "/usr/lib/python2.5/site-packages/trac/db/pool.py", line 107, in get_cnx cnx = connector.get_connection(**kwargs) File "/usr/lib/python2.5/site-packages/trac/db/sqlite_backend.py", line 126, in get_connection return SQLiteConnection(path, params) File "/usr/lib/python2.5/site-packages/trac/db/sqlite_backend.py", line 168, in __init__ % (getuser(), path)) TracError: The user root requires read _and_ write permission to the database file /var/lib/trac/machova/db/trac.db and the directory it is located in. Expected Results: normal trac webinterface note that exactly the same error happens if I try to setup trac with apache + mod_python and point it to the same project
one more note, I have found that the solution recommended at the trac site is to chown the file to apache:apache but in that case, the file still would be inaccessible by tracd, which runs as the user tracd I wonder if this has any reasonable solution(*) ... but anyway, IMHO having a setup which does not work in any way is worse than prefering setting one owner over the other, thus having only one not working but the second working (*) maybe adding tracd to the apache group, chowning to apache:apache to be consistent with the upstream preferred name/group and setting write permission for the group?
As far as I can tell you run tracd *OR* apache. Not both at the same time. So this is indeed a configuration issue on your side that we cannot catch during install time. I know that setup of some tools is not an out-of-the box installation. While portage can do a lot it does not make too much sense to try to put every little detail into it. At some point also the packages itself need to provide decent configuration management tools. Closing as invalid.
(In reply to comment #2) > As far as I can tell you run tracd *OR* apache. Not both at the same time. correct (if *OR* == XOR ;-)) > So this is indeed a configuration issue on your side that we cannot catch > during install time. not correct during install time, I can specify some use flags ... and if one of them is "apache2" (see the bug #247709), then you can safely assume that I want to use apache (mod python) mode if I have it set and that I want to use tracd mode otherwise > I know that setup of some tools is not an out-of-the box installation. While > portage can do a lot it does not make too much sense to try to put every little > detail into it. At some point also the packages itself need to provide decent > configuration management tools. ok, then pass it upstream, if you think that the solution should be provided by the package itself - I, as an user, cannot decide where exactly is the borderline (although I am inclined to think that the upstream has nothing to do with users and groups created by ebuilds ...) > Closing as invalid. if you do not feel like fixing that, then at least please handle this report correctly - reading http://bugs.gentoo.org/page.cgi?id=fields.html#resolution this is either WONTFIX or UPSTREAM ... you can hardly tell that there is no error at all if the application throws an exception
(In reply to comment #3) > > So this is indeed a configuration issue on your side that we cannot catch > > during install time. > > not correct > > during install time, I can specify some use flags ... and if one of them is > "apache2" (see the bug #247709), then you can safely assume that I want to use > apache (mod python) mode if I have it set and that I want to use tracd mode > otherwise Probably right. But then, please, update your patch in bug 247709. > ok, then pass it upstream, if you think that the solution should be provided > by the package itself This is system administrator duties, so why bother upstream? > > Closing as invalid. > > if you do not feel like fixing that, then at least please handle this report > correctly - reading http://bugs.gentoo.org/page.cgi?id=fields.html#resolution > this is either WONTFIX or UPSTREAM ... Ok, let's look at that page: UPSTREAM: It is not suitable to deal with the bug at this level, and the bug should be taken to the upstream developers for resolution. WONTFIX: The problem described is a bug which will never be fixed. INVALID: The problem described is not a bug. This but is really INVALID since this is *not a bug*. Neither in application (they have easy_install tool so probably it does everything required), nor in our ebuild (yes, we can add apache2 feature as you described in bug 247709, but this feature is not yet in portage tree). > you can hardly tell that there is no > error at all if the application throws an exception This exception is result of misconfiguration. Currently portage does not provide possibility to install trac with apache2 out of box, so there is no surprise you have to configure your system manually for that. We'll consider adding apache2 USE flag and personally I'm all for adding that. But this is feature request and we already discussing it in another bug. So let's continue working on apache2 support for trac in bug 247709.
