Re: [Trac] Re: multiple projects transition from a single project

[Mike Dewhirst]

Many thanks (again) Ryan. I'll get back in saddle as soon as I regain keyboard 
privileges. 

Cheers

Mike

Connected by Motorola

Ryan Ollos  wrote:

>
>
>
>On Tue, Sep 26, 2017 at 1:54 AM, Mike Dewhirst  wrote:
>
>  
>    Alias /robots.txt /var/www/trac/projects/ssds/htdocs/site/robots/robots.txt
>    Alias /favicon.ico 
>/var/www/trac/projects/ssds/htdocs/site/assets/img/ssds.ico
>    Alias /chrome/cgi-bin /var/www/trac/projects/ssds/cgi-bin
>    Alias /chrome/common /var/www/trac/projects/ssds/htdocs/common
>    Alias /chrome/site /var/www/trac/projects/ssds/htdocs/site
>  
>
>
>
>You don't need to alias /chrome/cgi-bin, and you can use one Alias for the 
>entire htdocs directory:
>
>
>  
>
>    Alias /robots.txt /var/www/trac/projects/ssds/htdocs/site/robots/robots.txt
>
>    Alias /favicon.ico 
>/var/www/trac/projects/ssds/htdocs/site/assets/img/ssds.ico
>
>    Alias /chrome /var/www/trac/projects/ssds/htdocs
>
>  
>
>
>The "ssds" directory should have been created with the "trac-admin deploy" 
>command. Is that a Trac environment? It should not be, but a common mistake it 
>to run the deploy command with $env/htdocs as a target. A better layout is 
>something like:
>
>/path/to/env
>
>/path/to/www/htdocs
>
>/path/to/www/cgi-bin
>
>with "www" directory created by the deploy command. The key point is that the 
>"www" directory lives beside the environment, not within it.
>
>
>I typically put robots.txt and favicon.ico in the Trac environment and symlink 
>when running deploy into $www:
>
>
>"$root"/pve/bin/trac-admin "$env" deploy "$www"
>
>ln -s "$env"/favicon.ico "$www"/
>
>ln -s "$env"/robots.txt "$www"/
>
> 
>
>  # lock the public out
>  
>    Order deny,allow
>    Deny from all
>  
>
>
>That might be preventing access to htdocs.
>
>
>You probably want something closer to:
>
>
>
>  Options -Indexes
>  Require all granted
>
>
>
>Also, it's using Apache < 2.4 syntax. You are almost certainly running Apache 
>2.4.
>
>https://httpd.apache.org/docs/current/upgrading.html#run-time
>
>
>Proper syntax for Apache 2.4 is also covered on the TracModWSGI page:
>
>https://trac.edgewall.org/wiki/TracModWSGI
>
>
>Our documentation for configuring mod_wsgi could be improved. This stuff can 
>be a bit confusing. I plan to rewrite that page eventually.
>
>
>As for standard layout or recommended arrangement, as mentioned I suggest 
>keeping the Trac environment separate from the static assets that are served.
>
>
>Examples:
>
>/var/trac/env1  <= Trac environment for project 1
>
>/var/trac/env2  <= Trac environment for project 2
>
>/var/www/trac/htdocs
>
>/var/www/trac/cgi-bin
>
>
>where "env1" and "env2" are Trac environments and you've run "trac-admin 
>/var/trac/env1 deploy /var/www/trac" to generate the static assets, i.e. the 
>htdocs and cgi-bin directories.
>
>
>Another common configurations is to put everything below /srv:
>
>
>/srv/www.website.com/trac  <= trac environment
>
>/srv/www.website.com/www/htdocs
>
>/srv/www.website.com/www/cgi-bin
>
> 
>
>  # allow public here
>  
>    Order allow,deny
>    Allow from all
>  
>
>  
>    AuthType Basic
>    AuthName "ssds"
>    AuthUserFile /var/svn/user_access/auth-file
>    Require valid-user
>  
>
>  
>    WSGIScriptAlias / /var/www/trac/projects/ssds/cgi-bin/trac.wsgi
>    
>      WSGIApplicationGroup %(GLOBAL)
>      Order deny,allow
>      Allow from all
>    
>  
>
>Here is a view-source excerpt from the top of the ticket query page: (those 
>"alternate" hrefs look a bit dodgy)
>
>href="/query?status=!closedgroup=statusformat=rsscol=idcol=summarycol=ownercol=typecol=prioritycol=changetimecol=reporterorder=priority"
> type="application/rss+xml" class="rss" title="RSS Feed" />
>
>href="/query?status=!closedgroup=statusformat=csvcol=idcol=summarycol=ownercol=typecol=prioritycol=changetimecol=reporterorder=priority"
> type="text/csv" class="csv" title="Comma-delimited Text" />
>
>href="/query?status=!closedgroup=statusformat=tabcol=idcol=summarycol=ownercol=typecol=prioritycol=changetimecol=reporterorder=priority"
> type="text/tab-separated-values" class="tab" title="Tab-delimited Text" />
>
>href="/query?status=!closedgroup=statuspage=2col=idcol=summarycol=ownercol=typecol=prioritycol=changetimecol=reporterorder=priority"
> title="Next Page" />
>
>
>
>
>
>
>
>type="text/css" />
>
>type="text/css" />
>
>type="image/x-icon" />
>
>.trac-noscript { display: none 
>!important }
>
>Thanks for any hints
>
>Mike
>
>
>
>
>On 25/09/2017 7:37 AM, Mike Dewhirst wrote:
>
>Thank you Ryan
>
>I'll get started
>
>M
>
>On 24/09/2017 7:18 PM, RjOllos wrote:
>
>
>
>On Sunday, September 24, 2017 at 1:32:45 AM UTC-7, Mike Dewhirst wrote:
>
>    What is the optimum way to upgrade Trac from a single project
>    installation to two completely separate projects?
>
>
>My opinion is that it's much easier to run everything from a single server: 
>all Trac projects and the SVN projects.
>
>Trac was built to serve multiple projects (environments) 

Re: [Trac] Re: multiple projects transition from a single project

[Ryan Ollos]

On Tue, Sep 26, 2017 at 1:54 AM, Mike Dewhirst 
wrote:

>   
> Alias /robots.txt /var/www/trac/projects/ssds/ht
> docs/site/robots/robots.txt
> Alias /favicon.ico /var/www/trac/projects/ssds/ht
> docs/site/assets/img/ssds.ico
> Alias /chrome/cgi-bin /var/www/trac/projects/ssds/cgi-bin
> Alias /chrome/common /var/www/trac/projects/ssds/htdocs/common
> Alias /chrome/site /var/www/trac/projects/ssds/htdocs/site
>   
>


You don't need to alias /chrome/cgi-bin, and you can use one Alias for the
entire htdocs directory:

  
Alias /robots.txt /var/www/trac/projects/ssds/
htdocs/site/robots/robots.txt
Alias /favicon.ico /var/www/trac/projects/ssds/
htdocs/site/assets/img/ssds.ico
Alias /chrome /var/www/trac/projects/ssds/htdocs
  

The "ssds" directory should have been created with the "trac-admin deploy"
command. Is that a Trac environment? It should not be, but a common mistake
it to run the deploy command with $env/htdocs as a target. A better layout
is something like:
/path/to/env
/path/to/www/htdocs
/path/to/www/cgi-bin
with "www" directory created by the deploy command. The key point is that
the "www" directory lives beside the environment, not within it.

I typically put robots.txt and favicon.ico in the Trac environment and
symlink when running deploy into $www:

"$root"/pve/bin/trac-admin "$env" deploy "$www"
ln -s "$env"/favicon.ico "$www"/
ln -s "$env"/robots.txt "$www"/


>   # lock the public out
>   
> Order deny,allow
> Deny from all
>   
>

That might be preventing access to htdocs.

You probably want something closer to:


  Options -Indexes
  Require all granted


Also, it's using Apache < 2.4 syntax. You are almost certainly running
Apache 2.4.
https://httpd.apache.org/docs/current/upgrading.html#run-time

Proper syntax for Apache 2.4 is also covered on the TracModWSGI page:
https://trac.edgewall.org/wiki/TracModWSGI

Our documentation for configuring mod_wsgi could be improved. This stuff
can be a bit confusing. I plan to rewrite that page eventually.

As for standard layout or recommended arrangement, as mentioned I suggest
keeping the Trac environment separate from the static assets that are
served.

Examples:
/var/trac/env1  <= Trac environment for project 1
/var/trac/env2  <= Trac environment for project 2
/var/www/trac/htdocs
/var/www/trac/cgi-bin

where "env1" and "env2" are Trac environments and you've run "trac-admin
/var/trac/env1 deploy /var/www/trac" to generate the static assets, i.e.
the htdocs and cgi-bin directories.

Another common configurations is to put everything below /srv:

/srv/www.website.com/trac  <= trac environment
/srv/www.website.com/www/htdocs
/srv/www.website.com/www/cgi-bin


>   # allow public here
>   
> Order allow,deny
> Allow from all
>   
>
>   
> AuthType Basic
> AuthName "ssds"
> AuthUserFile /var/svn/user_access/auth-file
> Require valid-user
>   
>
>   
> WSGIScriptAlias / /var/www/trac/projects/ssds/cgi-bin/trac.wsgi
> 
>   WSGIApplicationGroup %(GLOBAL)
>   Order deny,allow
>   Allow from all
> 
>   
>
> Here is a view-source excerpt from the top of the ticket query page:
> (those "alternate" hrefs look a bit dodgy)
>
>  class="rss" title="RSS Feed" />
>
>  title="Comma-delimited Text" />
>
>  class="tab" title="Tab-delimited Text" />
>
> 
>
> 
>
>  />
>
>  type="text/css" />
>
>  type="text/css" />
>
>  type="text/css" />
>
>  type="image/x-icon" />
>
> .trac-noscript { display: none
> !important }
>
> Thanks for any hints
>
> Mike
>
>
>
> On 25/09/2017 7:37 AM, Mike Dewhirst wrote:
>
>> Thank you Ryan
>>
>> I'll get started
>>
>> M
>>
>> On 24/09/2017 7:18 PM, RjOllos wrote:
>>
>>>
>>>
>>> On Sunday, September 24, 2017 at 1:32:45 AM UTC-7, Mike Dewhirst wrote:
>>>
>>> What is the optimum way to upgrade Trac from a single project
>>> installation to two completely separate projects?
>>>
>>>
>>> My opinion is that it's much easier to run everything from a single
>>> server: all Trac projects and the SVN projects.
>>>
>>> Trac was built to serve multiple projects (environments) from a single
>>> server. Rather than configuring TRAC_ENV in your installation you
>>> configure TRAC_ENV_PARENT_DIR. If you want different domain names for your
>>> projects, I think that can probably be handled in the Apache configuration.
>>>
>>> If you want to run the Trac projects in different Python interpreters,
>>> that's also possible. It's just a matter of setting up the proper WSGI
>>> directives. Take a look at:
>>> https://modwsgi.readthedocs.io/en/develop/user-guides/virtua
>>> l-environments.html#daemon-mode-single-application
>>>
>>> I'm guessing separate machines but I'd much prefer separate vhosts
>>> under
>>> the same Apache (mod-wsgi) on the same machine. That would simplify
>>> everything for me.
>>>
>>> The svn server is on the original trac server and will also host the
>>> separate project source. If we have to 

Re: [Trac] Re: multiple projects transition from a single project

[Ryan Ollos]

On Tue, Sep 26, 2017 at 1:54 AM, Mike Dewhirst 
wrote:

> I came unstuck after I upgraded to 1.2 prior to making a second vhost and
> second Trac project.
>
> Is there docmentation of a standard file layout or recommended arrangement
> for a single server, Apache2 multiple vhost with python 2.7 mod-wsgi and
> multi-project Trac 1.2 installation on Ubuntu 16.04 LTS server?
>
> I'm getting totally bamboozled by the Trac documentation at this point.
> There appears to be many ways to do things.
>
> I remember now that I had similar trouble setting it up the first time a
> few years ago and only by copying stuff everywhere (back then) did I get it
> going. I'm sure I could do the same thing again but that would be wrong of
> me.
>
> I have followed (probably) bits of both https://trac.edgewall.org/wiki
> /TracInstall#Usingpip and https://trac.edgewall.org/demo
> -1.2/wiki/TracInstall#Usingpip
>
> At this point my Trac instance *is* now 1.2 but not working properly:
>
> close  *Warning:* Error with
> navigation contributor "AccountModule"
>
>
>  Oops…
>
> *Trac detected an internal error:*
>
> AttributeError: 'Environment' object has no attribute 'get_db_cnx'
>
> That is not being styled because Apache cannot find the css. The css *is*
> being accessed by tracd (where the environment is /var/trac/projects/ssds
> (note the absence of www there)) but not Apache. The css files do exist
> where Apache is looking for them and they have www-data ownership with rwx
> permissions. Here is my trac vhost conf:
>
>   
> Alias /robots.txt /var/www/trac/projects/ssds/ht
> docs/site/robots/robots.txt
> Alias /favicon.ico /var/www/trac/projects/ssds/ht
> docs/site/assets/img/ssds.ico
> Alias /chrome/cgi-bin /var/www/trac/projects/ssds/cgi-bin
> Alias /chrome/common /var/www/trac/projects/ssds/htdocs/common
> Alias /chrome/site /var/www/trac/projects/ssds/htdocs/site
>   
>
>   # lock the public out
>   
> Order deny,allow
> Deny from all
>   
>
>   # allow public here
>   
> Order allow,deny
> Allow from all
>   
>
>   
> AuthType Basic
> AuthName "ssds"
> AuthUserFile /var/svn/user_access/auth-file
> Require valid-user
>   
>
>   
> WSGIScriptAlias / /var/www/trac/projects/ssds/cgi-bin/trac.wsgi
> 
>   WSGIApplicationGroup %(GLOBAL)
>   Order deny,allow
>   Allow from all
> 
>   
>
> Here is a view-source excerpt from the top of the ticket query page:
> (those "alternate" hrefs look a bit dodgy)
>
>  class="rss" title="RSS Feed" />
>
>  title="Comma-delimited Text" />
>
>  class="tab" title="Tab-delimited Text" />
>
> 
>
> 
>
>  />
>
>  type="text/css" />
>
>  type="text/css" />
>
>  type="text/css" />
>
>  type="image/x-icon" />
>
> .trac-noscript { display: none
> !important }
>
> Thanks for any hints
>
> Mike


Take a read through TracUpgrade:
https://trac.edgewall.org/wiki/1.3/TracUpgrade

I've referenced the "1.3" version because it has more information, and the
parts to ignore when working with Trac 1.2.x will be obvious.

In short, you need to upgrade plugins and run the "trac-admin deploy"
command.

- Ryan

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to trac-users@googlegroups.com.
Visit this group at https://groups.google.com/group/trac-users.
For more options, visit https://groups.google.com/d/optout.

[Trac] Re: multiple projects transition from a single project

[Mike Dewhirst]

I came unstuck after I upgraded to 1.2 prior to making a second vhost 
and second Trac project.


Is there docmentation of a standard file layout or recommended 
arrangement for a single server, Apache2 multiple vhost with python 2.7 
mod-wsgi and multi-project Trac 1.2 installation on Ubuntu 16.04 LTS server?


I'm getting totally bamboozled by the Trac documentation at this point. 
There appears to be many ways to do things.


I remember now that I had similar trouble setting it up the first time a 
few years ago and only by copying stuff everywhere (back then) did I get 
it going. I'm sure I could do the same thing again but that would be 
wrong of me.


I have followed (probably) bits of both 
https://trac.edgewall.org/wiki/TracInstall#Usingpip and 
https://trac.edgewall.org/demo-1.2/wiki/TracInstall#Usingpip


At this point my Trac instance *is* now 1.2 but not working properly:

close  *Warning:* Error with 
navigation contributor "AccountModule"



 Oops…

*Trac detected an internal error:*

AttributeError: 'Environment' object has no attribute 'get_db_cnx'

That is not being styled because Apache cannot find the css. The css 
*is* being accessed by tracd (where the environment is 
/var/trac/projects/ssds (note the absence of www there)) but not Apache. 
The css files do exist where Apache is looking for them and they have 
www-data ownership with rwx permissions. Here is my trac vhost conf:


  
Alias /robots.txt /var/www/trac/projects/ssds/htdocs/site/robots/robots.txt
Alias /favicon.ico 
/var/www/trac/projects/ssds/htdocs/site/assets/img/ssds.ico
Alias /chrome/cgi-bin /var/www/trac/projects/ssds/cgi-bin
Alias /chrome/common /var/www/trac/projects/ssds/htdocs/common
Alias /chrome/site /var/www/trac/projects/ssds/htdocs/site
  

  # lock the public out
  
Order deny,allow
Deny from all
  

  # allow public here
  
Order allow,deny
Allow from all
  

  
AuthType Basic
AuthName "ssds"
AuthUserFile /var/svn/user_access/auth-file
Require valid-user
  

  
WSGIScriptAlias / /var/www/trac/projects/ssds/cgi-bin/trac.wsgi

  WSGIApplicationGroup %(GLOBAL)
  Order deny,allow
  Allow from all

  

Here is a view-source excerpt from the top of the ticket query page: 
(those "alternate" hrefs look a bit dodgy)






















.trac-noscript { display: none !important 
}

Thanks for any hints

Mike


On 25/09/2017 7:37 AM, Mike Dewhirst wrote:

Thank you Ryan

I'll get started

M

On 24/09/2017 7:18 PM, RjOllos wrote:



On Sunday, September 24, 2017 at 1:32:45 AM UTC-7, Mike Dewhirst wrote:

    What is the optimum way to upgrade Trac from a single project
    installation to two completely separate projects?


My opinion is that it's much easier to run everything from a single 
server: all Trac projects and the SVN projects.


Trac was built to serve multiple projects (environments) from a 
single server. Rather than configuring TRAC_ENV in your installation 
you configure TRAC_ENV_PARENT_DIR. If you want different domain names 
for your projects, I think that can probably be handled in the Apache 
configuration.


If you want to run the Trac projects in different Python 
interpreters, that's also possible. It's just a matter of setting up 
the proper WSGI directives. Take a look at:
https://modwsgi.readthedocs.io/en/develop/user-guides/virtual-environments.html#daemon-mode-single-application 



    I'm guessing separate machines but I'd much prefer separate vhosts
    under
    the same Apache (mod-wsgi) on the same machine. That would simplify
    everything for me.

    The svn server is on the original trac server and will also host the
    separate project source. If we have to go to another machine will
    that
    be a problem? I do have a virgin machine upon which to start again.


Trac and SVN need to run on the same server. There are ways around 
that, like setting up a readonly SVN mirror. It will be much easier 
if you just run all your Trac and SVN instances on the same server.


    A possible complication is I need to drop Python 2.7 and use 3.5
    exclusively on Ubuntu 16.04 LTS.


Trac does not support any version of Python 3.x. You'll have to run 
Trac with Python 2.7 for now. Support for 3.x is probably more than a 
year away still.


    I'd be happy to start again provided I can upload a MySQL dump
    from the
    original Trac. I would probably switch to Postgres if starting 
again.



The SQLite file is in the project environment so it's simple to move 
an SQLite project environment to another server.

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

TracMigratePlugin is good for converting a database:
http://trac-hacks.org/wiki/TracMigratePlugin

The feature has been added to Trac for the forthcoming Trac 1.4 release.

- Ryan
--
You received this message because you are subscribed to the Google 
Groups "Trac Users" group.
To unsubscribe from this group and stop 

[Trac] Re: Comments from Git's branch can not be inserted into a task list

[Mingxing Tian]

I submitted a test report that you have seen May need to be further 
repaired.

在 2017年9月10日星期日 UTC+8下午4:52:31，RjOllos写道：
>
>
>
> On Friday, September 8, 2017 at 2:00:02 AM UTC-7, Mingxing Tian wrote:
>>
>> I fill in the comments in the format when I submit the change:
>>
>> see #1695 test commit
>>
>> If submitted on the trunk, add a comment on the ticket (# 1695).
>> But submitted on the branch, the following error occurs.
>>
>> Trac[web_ui] WARNING: Unable to insert changeset 
>> 0837f161e858afba78318dadac512444f1bb013e/testing and ticket 1695 into db: 
>> (1062, "Duplicate entry 
>> 'testing-0837f161e858afba78318dadac512444f1bb013e-1695' for key 'PRIMARY'"
>> )
>>
>> Why can not the comments submitted from the branch be automatically added 
>> to the comment in the order? Is this a bug?
>>
>
> Looks like it's reported already:
> https://trac-hacks.org/ticket/12966
>
> I did some work on the plugin but I don't really have time to maintain it. 
> It could use a maintainer.
>
> - Ryan 
>

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to trac-users@googlegroups.com.
Visit this group at https://groups.google.com/group/trac-users.
For more options, visit https://groups.google.com/d/optout.