Inherited ancient Trac systems

[Michael Firth]

Hi,

I've inherited two ancient Trac systems from another part of my company. They were originally created around 10 years ago, and haven't been upgraded since (I don't think)

Both are from an obsolete "turnkey" application company called Jumpbox, which seems to have ceased trading in early 2017.

The older is running Trac V0.12, and the younger is running Trac V0.12.2

I am wondering whether it would be feasable to migrate these to a modern "Trac in a box" system, for example the one from Turnkey Linux https://www.turnkeylinux.org/trac

I think most of the challenges will be around migrating the Trac wiki from the old version, together with the handful of plugins that are on the old systems (e.g. account management).

I think this post here may be about something similar:

https://groups.google.com/g/trac-users/c/Xv2Pn3AKwks

But the post that worked for Markus isn't linked, and the original question isn't quite clear.

[Markus Rosjat]

Hi,

Yeah I migrated a 0.12 to 1.4. , well it takes a little tinkering and some trying but if you haven't  to many strange plugins it's not to difficult. I can write down some more details later because I need to check some stuff I did :)

Cheers 

Markus

--
You received this message because you are subscribed to the Google Groups "Trac Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to trac-users+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/trac-users/19200f7f-079a-400a-a0ea-f7eba25087a1n%40googlegroups.com.

[RjOllos]

Turnkey or Bitnami is probably a good option. 

I suggest reviewing: https://trac.edgewall.org/wiki/TracUpgrade

It's mainly a matter of installing plugins in the new system, moving the environment directory over and upgrading.  If not using SQLite, there is slightly more work to dump and create the new database.

See also:

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

Please let us know if you encounter any trouble. Most issues are quick to work-through.

- Ryan

[Michael Firth]

Hi,

I think I've got most of the framework worked out now - the only plugins on the old systems were Trac itself (it seems this is hierarchical on the old version, but gives me lots of top level trac.xxxx.yyyy things on the new one?) and a very old version of the account manager plugin ("TracAccountManager 0.2.1dev-r7737" on one and "TracAccountManager 0.3dev-r9785" on the other). The old one also has some other ones that look like they relate to ticket tracking (e.g. "Tracticketstats 2.1"), but I don't think that matters for something so legacy (we don't want to do anything new with these systems).

So I think installing a new version of the account manager is the main thing I need in terms of plugins. It looks like the version numbering of this is a bit strange (the "stable" version for new Trac versions is 0.5, but some installation guides talk about using an 0.11, which seems to be older than the 0.5), but the stable version seems to work and looks like it is a superset of what the old systems can do.

One stumbling block for a while was that the Jumpbox systems were exposing the SVN repository via HTTP, but the Turnkey Trac server doesn't do that out of the box. By installing "libapache2-mod-svn" and adding a "Location" stanza to the apache.conf file (the only active "site" seems to be the file /etc/trac/apache.conf), I think I have that working - the config I added was

<Location /svn>
    DAV svn
    AuthType Basic
    AuthName "Trac SVN"
    AuthUserFile /etc/trac/htpasswd
    Require valid-user
    SVNParentPath /srv/repos/svn
</Location>

I think I've gone as far as I can in changing the "svn-helloworld" project that comes with the Turnkey Trac to be like I want the main one to end up, and now need to go through the copy and upgrade processes you've linked with the live data.

[RjOllos]

On Wednesday, August 26, 2020 at 8:52:34 AM UTC-7 mfir...@googlemail.com wrote:

Hi,

I think I've got most of the framework worked out now - the only plugins on the old systems were Trac itself (it seems this is hierarchical on the old version, but gives me lots of top level trac.xxxx.yyyy things on the new one?) and a very old version of the account manager plugin ("TracAccountManager 0.2.1dev-r7737" on one and "TracAccountManager 0.3dev-r9785" on the other). The old one also has some other ones that look like they relate to ticket tracking (e.g. "Tracticketstats 2.1"), but I don't think that matters for something so legacy (we don't want to do anything new with these systems).

Going forward, using pip, rather than easy_install, the old versions should get uninstalled when you upgrade a package. It was a common problem with easy_install that old versions would remain when upgrading.

- Ryan

[Michael Firth]

As i was building a new system and migrating the data, rather than upgrading in-place (because the originals were unmaintainable), I don't think this would have helped for my current case. But I agree it could be useful in future. Is it possible to upgrade a package installed with easy_install using pip, or would I need to uninstall and re-install it?

[RjOllos]

On Friday, September 11, 2020 at 5:15:59 AM UTC-4 mfir...@googlemail.com wrote:

As i was building a new system and migrating the data, rather than upgrading in-place (because the originals were unmaintainable), I don't think this would have helped for my current case. But I agree it could be useful in future. Is it possible to upgrade a package installed with easy_install using pip, or would I need to uninstall and re-install it?

My experience is that a easy_install'ed package can usually be uninstalled using pip. Pip will often uninstall the old package. However, it may depend on the package metadata, so I usually do the following:

pip uninstall <name>

# repeat until all versions uninstalled

pip install <name>

If uninstall fails, manually remove package from site-packages.

- Ryan