Opened 3 years ago

Closed 3 months ago

Last modified 2 months ago

#1419 closed task (fixed)

Upgrade website to use Trac 1.6/Python3

Reported by: Alex Samorukov Owned by: Alex Samorukov
Priority: minor Milestone:
Component: wiki Version:
Keywords: Cc:

Description (last modified by Alex Samorukov)

Problem description

Our trac is using Py2 which is EOL ~1yr already

We are using EdgeWall trac to manage smartmontools project, as well as few plugins which are written on Py27, which is EOL from January 1, 2020 already. As result py2 is no longer receiving any fixes (including security) and is getting slowly removed from the upstream packages. E.g. in the FreeBSD which we are using to host this instance, trac is already marked as "depricated" and soon will be removed due to py27 dependency.

Upstream project is slowly moving to py3, however it is still in "development" branch only (Trac-1.5.2-py3-none-any.whl). Even after removal from the upstream i will be able to continue to host this trac instance (e.g. using jail and installation using pip2), but it will take more efforts and will give us more and more security concerns.

Installed plugins

Plugins for trac are also written on py2 and will require upgrade or rewrite

plugin description status
ManPageRendererPlugin renders our man pages very easy to port
TracAccountManager Manage Trac user accounts. Critical to have, not ported, complex to port, see https://trac-hacks.org/ticket/13720
TracRecaptchaRegister small plugin to show google re-captcha on the first reg. Should be trivial to port. depends on TracAccountManager
TracSpamFilter SPAM filtering for trac. Must have. complex to port, porting not yet started
TracTocMacro TOC macros for WIKI very easy to port

Possible options

  1. Start testing Trac 1.5/Devel to see how much efforts would take to move trac to it. Problem is that there is no timeline yet, and plugins still need to be ported (at least TracAccountManager which is very critical to us).
  2. Use other options, e.g. Github, which now provides WIKI, pages and other. Gitlab could be used as an alternative. Downside is that we will have to port our existing pages and wiki to it, however, that should be a one time job. This would also significantly change our release procedure.
  3. Do nothing and support trac/py2 as much as we can, e.g. using jail and self-built py. However, this is insecure and will not help us in the long term

Change History (16)

comment:1 by Alex Samorukov, 3 years ago

Description: modified (diff)

comment:2 by Alex Samorukov, 3 years ago

Description: modified (diff)

comment:3 by Alex Samorukov, 3 years ago

Description: modified (diff)

comment:4 by Alex Samorukov, 3 years ago

Description: modified (diff)

comment:5 by Alex Samorukov, 3 years ago

Description: modified (diff)

comment:6 by Alex Samorukov, 3 years ago

Progress updates:

  • Trac/py3 seems to be stable and functional, despite development status. I was able to run our trac on it locally.
  • But it does not apply to plugins. Porting of the TracAccountManager not started, same as TracSpamFilter.

So lets keep things for now as is and keep tracking of Trac/py3 progress.

comment:7 by Alex Samorukov, 3 months ago

Description: modified (diff)
Owner: set to Alex Samorukov
Status: newassigned

comment:8 by Alex Samorukov, 3 months ago

Updates from 2024:

  1. Trac finally released version 1.6 with performance improvements and Py3 support.
  2. TracAccountManager and TracSpamFilter have been ported by upstream to work with 1.6
  3. ManPageRendererPlugin and TracTocMacro ported by me
  4. TracRecaptchaRegister actually not that trivial to port as the way the template engine works changed completely. I started to do port recently, but that would require some time to complete.
  5. SQL structure changed, so I had to fix some of our reports
  6. Nginx configuration was adjusted (many issues, mostly related to internal changes of paths)
  7. Also i did some inactive users cleanup and added cron job to kill old sessions to make account manager faster

Now everything running on py3 and seems to be significantly faster. Will close this ticket once registration will start working

comment:9 by Alex Samorukov, 3 months ago

Description: modified (diff)
Summary: Our trac is using Py2 which is EOL ~1yr alreadyUpgrade website to use Trac 1.6/Python3

comment:10 by Alex Samorukov, 3 months ago

Registration is fixed, will need to put code to the github to ensure its not lost

comment:11 by Alex Samorukov, 3 months ago

Resolution: fixed
Status: assignedclosed

comment:12 by Christian Franke, 2 months ago

Issue found: Milestone field can no longer be changed.

comment:13 by Alex Samorukov, 2 months ago

Thank you. Just found solution here: https://stackoverflow.com/questions/67585839/enable-milestone-field-in-trac-ticket-form

Added DefaultTicketPolicy and everything seems to work again :)

comment:14 by Alex Samorukov, 2 months ago

It also reminder to me to review all settings in the trac.ini to see if we really need them or happy with defaults to avoid same issues.

comment:15 by Christian Franke, 2 months ago

Milestone: undecided

Thanks! Using this ticket as a first testcase :-)

comment:16 by Alex Samorukov, 2 months ago

Just for the record:

TracAccountManager, TracTocMacro, and TracSpamFilter plugins are now used as is from upstream, as all issues are fixed. ManPageRendererPlugin is heavily customized for our needs and ported to 1.6. TracRecaptchaRegister was also ported by me, but with a hack (part of the functionality disabled), so I will not submit it upstream and will host it in the local trac/plugins directory.

The overall impression from Trac 1.6 so far is very good - it addressed a lot of stability, security, and performance issues we had, so I think it could stay as our project management tool now.

Note: See TracTickets for help on using tickets.