Migrating Trac 1.4 WITH PLUGINS to a new server

[Rob Hills]

I have been working through migratiing a working Trac project from one server (Ubuntu + cpanel) to another (Debian + Yunohost).

I got the basics done using https://trac.edgewall.org/wiki/TracMigrate and tweaking for my setup (git instead of Subversion).  I have now got Trac running on the new server with all my data.

**But**

The hotcopy process doesn't seem to have backed up all of my Plugins into the backup folder.  On the original server, I had Trac running in a virtual environment and had deployed to a separate htdocs folder (originally created using trac_admin deploy IIRC).

On my original server, the htdocs folder within my Trac project in the virtual environment contains three folders, "common", "site" and one that is obviously related to one of my plugins: "tracworkflowadmin".

On the original server, the deployed htdocs folder seems to contain "site" and "common" folders as well as all the plugin folders.

AFAICT, the hotcopy backup folder only copied the htdocs folder from within the virtual environment.  It didn't copy the ones from the deployed htdocs folder.

I'm not sure if this is a failing of the hotcopy process or of the plugins installation process.

Anyway, to fix the problem, can I simply copy the missing folders from my old server's deployed htdocs folder to the new, or do I need to reinstall each plugin?

Cheers,

Rob Hills

Waikiki, Western Australia

[RjOllos]

On Thursday, June 23, 2022 at 8:13:27 AM UTC-7 rcp....@gmail.com wrote:

I have been working through migratiing a working Trac project from one server (Ubuntu + cpanel) to another (Debian + Yunohost).

I got the basics done using https://trac.edgewall.org/wiki/TracMigrate and tweaking for my setup (git instead of Subversion).  I have now got Trac running on the new server with all my data.

Please feel free to add anything you think would help to that page. It's been cobbled together but could use some work.

 

**But**

The hotcopy process doesn't seem to have backed up all of my Plugins into the backup folder.  On the original server, I had Trac running in a virtual environment and had deployed to a separate htdocs folder (originally created using trac_admin deploy IIRC).

 

Hotcopy will only capture plugins from the $env/plugins directory. Your plugins could be installed in many other places:

1. The global plugins directory

2. Python site-packages

More explanation here:

https://trac.edgewall.org/wiki/TracPlugins

On my original server, the htdocs folder within my Trac project in the virtual environment contains three folders, "common", "site" and one that is obviously related to one of my plugins: "tracworkflowadmin".

On the original server, the deployed htdocs folder seems to contain "site" and "common" folders as well as all the plugin folders.

AFAICT, the hotcopy backup folder only copied the htdocs folder from within the virtual environment.  It didn't copy the ones from the deployed htdocs folder.

I'm not sure if this is a failing of the hotcopy process or of the plugins installation process.

Anyway, to fix the problem, can I simply copy the missing folders from my old server's deployed htdocs folder to the new, or do I need to reinstall each plugin?

In general I would advise against that. The htdocs are an artifact and can change with each Trac and plugin version. For every Trac or plugin upgrade you should regenerate htdocs:

https://trac.edgewall.org/wiki/TracUpgrade#a6.Refreshstaticresources

https://trac.edgewall.org/wiki/TracPlugins#Redeployingstaticresources

There is a common pattern in which users deploy to the $env/htdocs directory, which can cause problems including infinite recursion in "trac-admin $env deploy". We added protection against the recursion, but I'd still advise against deploying to $env/htdocs.

The $env/htdocs is meant for site customizations. When you run deploy, the static assets for all plugins and $env/htdocs will be extracted to the target directory. This is where the possibility of infinite recursion arises. This is why htdocs is just an artifact and can be regenerated with a single command.

So it's better to separate out your deployment directory and have the environment separate from the deployment dir. This might look something like:

/var/trac/$env

/var/www/trac/htdocs

You'll need to reinstall all of your plugins in the new environment unless those plugins are all in $env/plugins. I have a requirements.txt listing all of the plugins for installing in the new environment. Then you can "pip install -r requirements.txt" following by "trac-admin $env deploy /path/to/deployment/dir".

Let me know if anything is unclear or you have any other questions.

Ryan

[Rob Hills]

Hi Ryan, thanks for your comprehensive reply.

I am aware that some of my plugins add tables to the db which will have been migrated across.  Do you think I am safe to assume that reinstalling the plugin won't blat existing data?  I do have a backup of the DB of course, but it would be nice not to have to revert to that!

I will have a go at updating the migration wiki page once I've got things up and running on the new server.

Cheers,

Rob Hills

Waikiki, Western Australia

[RjOllos]

On Friday, June 24, 2022 at 12:16:28 AM UTC-7 rcp....@gmail.com wrote:

Hi Ryan, thanks for your comprehensive reply.

I am aware that some of my plugins add tables to the db which will have been migrated across.  Do you think I am safe to assume that reinstalling the plugin won't blat existing data?  I do have a backup of the DB of course, but it would be nice not to have to revert to that!

Yeah, plugins should check whether the database upgrade is needed and will not recreate the tables if they already exist. Unless the plugin was coded improperly, and there was a pattern used in plugins for checking table existence that didn't work correctly for some DB types. But well-maintained plugins should be fine.