Component <Component trac.db.api.DatabaseManager> failed with TracError: Unsupported database type "postgres" after re-running trac-admin deploy

[Rob Hills]

I have a Trac instance that I've had running happily on postgresql for a week or so now.

I have installed the PdfPreviewPlugin but couldn't get it to work.  I went hunting through the plugin's bug list and found this one which indicated that I needed to run trac-admin deploy after installing (no mention of this in the installation instructions!)

After running trac-admin /path/to/my/trac/instance deploy /path/to/web/root and then restarting apache, my site is now completely broken, simply displaying:

Trac Error

TracError: Unable to check for upgrade of trac.db.api.DatabaseManager: TracError: Unsupported database type "postgres"

on the home page or any other URL within my site.

I'm mystified as to why doing a trac-admin deploy would even cause the db-connection to break, let alone how.  Google hasn't provided any enlightenment so far.

In the log, in addition to the above messages I see:

2021-01-02 16:51:05,224 Trac[loader] DEBUG: Loading plugin "trac.db.postgres" from "/<some folders>/.local/lib/python2.7/site-packages"
2021-01-02 16:51:05,224 Trac[loader] DEBUG: Skipping "trac.db.postgres = trac.db.postgres_backend": DistributionNotFound: ('psycopg2>=2.0 or psycopg2-binary', [
'Trac'])

If I check my ~/.local/lib/python2.7/site-packages folders I don't see any evidence of psycopg2, but if I enter the virtuanenv my server is running in and try and install psycopg2 it says it's already installed.  Similarly if I run python and run "import psycopg2" that executes without any error.

Any suggestions will be most welcome!

Cheers,

Rob Hills

Waikiki, Western Australia

[RjOllos]

On Saturday, January 2, 2021 at 1:32:39 AM UTC-8 rcp....@gmail.com wrote:

I have a Trac instance that I've had running happily on postgresql for a week or so now.

I have installed the PdfPreviewPlugin but couldn't get it to work.  I went hunting through the plugin's bug list and found this one which indicated that I needed to run trac-admin deploy after installing (no mention of this in the installation instructions!)

It's only necessary to run deploy if you have mapped static resources for your webserver, which is a performance optimization:

https://trac-hacks.org/wiki/TracPlugins#Redeployingstaticresources

It's very tedious to maintain install instructions for all of the plugins, so we put a generic statement here and hope that users will familiarize with the TracPlugin page:

https://trac-hacks.org/wiki/PdfPreviewPlugin#Installation

It's still fairly complex and I've been thinking for a long time about how to simplify things so that a new or casual user doesn't need to understand so many details.

 

After running trac-admin /path/to/my/trac/instance deploy /path/to/web/root and then restarting apache, my site is now completely broken, simply displaying:

Trac Error

TracError: Unable to check for upgrade of trac.db.api.DatabaseManager: TracError: Unsupported database type "postgres"

on the home page or any other URL within my site.

I'm mystified as to why doing a trac-admin deploy would even cause the db-connection to break, let alone how.  Google hasn't provided any enlightenment so far.

In the log, in addition to the above messages I see:

2021-01-02 16:51:05,224 Trac[loader] DEBUG: Loading plugin "trac.db.postgres" from "/<some folders>/.local/lib/python2.7/site-packages"
2021-01-02 16:51:05,224 Trac[loader] DEBUG: Skipping "trac.db.postgres = trac.db.postgres_backend": DistributionNotFound: ('psycopg2>=2.0 or psycopg2-binary', [
'Trac'])

If I check my ~/.local/lib/python2.7/site-packages folders I don't see any evidence of psycopg2, but if I enter the virtuanenv my server is running in and try and install psycopg2 it says it's already installed.  Similarly if I run python and run "import psycopg2" that executes without any error.

Any suggestions will be most welcome!

The deploy command rewrites trac.wsgi, so your customizations were likely overwritten. 

https://groups.google.com/g/trac-users/c/Jm9JbiG5BJg/m/C8i9vPSTBgAJ

"#!/<various-folders>/applications/trac/venv/bin/python" has likely been replaced with the path to the default python.

As a workaround, I'd add a "deploy.sh" that runs deploy then copies your trac.wsgi to the deploy path. I suppose we should add an option to the deploy command to only extract static resources and not the webserver scripts.

https://trac.edgewall.org/ticket/9331

Ryan

[Rob Hills]

Thanks Ryan,

I'd checked trac.wsgi initially as that was my first thought.  However, it was actually pointing at the correct Python in the first line so I made the silly mistake of assuming that Deploy had NOT overwritten my trac.wsgi.  As it happens it had, blowing away my customisations further down the script to work around the bug in passenger - wsgi as well as other changes obviously necessary to get Trac to work in a Virtual Environment in my Centos 7 + WHM + cPanel setup.

Regarding the deploy command replacing customised wsgi scripts (and presumably the other trac.*gi scripts in the cgi-bin directory) how much effort would be involved in comparing the new scripts with existing ones and alerting the user if there is a change?  To partly answer my own question, I hunted through the Trac code and found the relevant code here.  As someone with only a very superficial understanding of how Trac works and with a limited knowledge of Python I'd have thought it wouldn't be too difficult to tweak the code to manage the situation where there is a change to one of these two scripts.

If you think it's worth considering, I'm happy to add a ticket describing a proposed workflow and perhaps even have a go at submitting a patch.

[RjOllos]

On Saturday, January 2, 2021 at 6:11:21 PM UTC-8 rcp....@gmail.com wrote:

Thanks Ryan,

I'd checked trac.wsgi initially as that was my first thought.  However, it was actually pointing at the correct Python in the first line so I made the silly mistake of assuming that Deploy had NOT overwritten my trac.wsgi.  As it happens it had, blowing away my customisations further down the script to work around the bug in passenger - wsgi as well as other changes obviously necessary to get Trac to work in a Virtual Environment in my Centos 7 + WHM + cPanel setup.

Regarding the deploy command replacing customised wsgi scripts (and presumably the other trac.*gi scripts in the cgi-bin directory) how much effort would be involved in comparing the new scripts with existing ones and alerting the user if there is a change?  To partly answer my own question, I hunted through the Trac code and found the relevant code here.  As someone with only a very superficial understanding of how Trac works and with a limited knowledge of Python I'd have thought it wouldn't be too difficult to tweak the code to manage the situation where there is a change to one of these two scripts.

If you think it's worth considering, I'm happy to add a ticket describing a proposed workflow and perhaps even have a go at submitting a patch.

I would like to do something to address this situation, but it would seem to be more straightforward to either add a switch to the deploy command for "htdocs only", or add a "redeploy" command that extracts htdocs but doesn't touch cgi-bin.

Ryan 

[Rob Hills]

Yes, I agree, a "redeploy" command would work perfectly and ought to be pretty simple to code I'd have thought.