Re: [Trac] email2trac use guidelines

[Garrett McGrath]

Steffen,

Fundamentally we've just out grown trac's ticket handling for what we 
were using it for.  We aren't using trac for project management (in this 
case) we are using it as a knowledge portal and helpdesk system for our 
Institutes labs.  We've grown since we set this up from around 25 high 
activity users to over 70 and will be moving to well over 100 in the 
next year or two.  RT gives us a few benefits in that level environment 
that we don't get in Trac.  Things like private ticket comments, 
suppressing ticket emails, templated behavior, shared queues, 
centralized management with seperate queues (which we currently have to 
accomplish by making separate projects for separate queues), it's 
handling of ticket updates via email are very powerful as well as it can 
use a number of metrics to determine if a ticket is actually an update 
instead of a new ticket.  It also lets us auth against apache's auth 
framework (and by proxy our institutions CASAUTH system).  We would also 
like to take the ticket system somewhat out of the public eye of our 
users, separating it from the KB system makes that easy as we can 
restrict the people allowed to see the web interface to only those that 
actually need to interact with it instead of allowing anybody with a 
general login to read all the tickets available. It's also the standard 
system for many other groups on campus, so we are moving in that 
direction instead of continuing to maintain a separate island of 
technology. Beyond that it's a learning experience for me as I've never 
setup RT before.


-Garrett


On 9/4/2013 11:54 AM, Steffen Hoffmann wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 04.09.2013 17:07, Garrett McGrath wrote:

I like it for a basic setup but our ultimate goal is to split ticket
handling out to RT and keep trac as our KB system for our labs due to
needing some features that trac can't support.
-Garrett

You're rather detailed explanation ends with this unclear statement.
Maybe it's just me, but would you be so kind as to name or describe
roughly, what these missing features are, please?

Steffen Hoffmann
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAlInV7MACgkQ31DJeiZFuHenOgCdHnNCcK5uPctcNSrhIv2zmV63
BPoAni3A5DK9PcQR6MG6h71vgKOgoAJY
=WEyk
-END PGP SIGNATURE-



--
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 http://groups.google.com/group/trac-users.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Trac] email2trac use guidelines

[Garrett McGrath]

  
  
We have been running trac + email2trac successfully for a while
here.  The major issues we've run into are:

  Mail loops, make sure you double and triple check your black
lists because if you don't you'll wind up with enormous trac
crippling tickets and DoS your email server.  Back up your
database regularly too because sometimes it's just faster to
roll back instead of trying to crawl around in mySQL/SQLite to
remove all the ticket remnants (and we've had our SQLite DB
balloon so large most tools can't interact with it to remove the
offending ticket).
  
  While you can issue email responses from inside trac, this
behavior happens every time you update a ticket which makes it a
bit spammy.  Even if all you are doing is changing the owner of
the ticket, everyone on that ticket will receive an email about
it, you also can't make private notes in a ticket that are only
readable by ticket managers.
  Reply To addressing is a bit bad, you can't assign reply to's
to individual components only individual projects, so even thou
we have separate email addresses that populate different
components, reply emails from the project all come from that
central email address.
  
ie, the project's email address is l...@labs.com, but a
  second email alias is made called labxc...@labs.com.  This
  will create tickets in the correct component (whatever you set
  it to in the alias file) but ticket updates will come from
  labX@.  It's not a huge deal but it can be confusing to end
  users.
  
  We had major spam issues but solved it by piping our email
through the institutions spam filtering appliance instead of
accepting email directly.  This forwarding setup requires a few
minor tweaks but it's worth doing if you have the infrastructure
required.
  If you can strip out the HTML version of the email before
delivering it to trac this is recommended.  The HTML formatting
makes trac's ticket layout look somewhere between bad and
unusable (in 0.10 which is our current install we are upgrading
to 1.x soon)

I like it for a basic setup but our ultimate goal is to split ticket
handling out to RT and keep trac as our KB system for our labs due
to needing some features that trac can't support.
-Garrett

On 9/4/2013 10:52 AM, W. Martin Borgert
  wrote:

Quoting roger.oberholt...@gmail.com:
  
  We are looking at using email2trac to
allow users to add and modify tickets. I

am curious what experience people have had with this. Not so
much how

email2trac works, but how you have managed getting users to
format messages

correctly.

  
  
  No guidelines, just some experiences here.
  
  
  We used to use email2trac and probably will use it again in the
  
  company for dealing with end customers with limited technical
  
  experience. It works very well, but has some room for improvement,
  
  too:
  
  
   1. Users tend to forget the ticket number in the subject or they
  
      even remove it. This leads to creation of duplicates. There is
  
      no easy merging of tickets in Trac, so this means work :~(
  
  
      Possible improvements: email2trac should work on base of
  
      message-ids in the e-mail header instead of parsing the
  subject
  
      like OpenERP. Or one could have one email address per ticket,
  
      like in Debian (e.g. 123...@bugs.myserver.com).
  
  
   2. Some users accidently use old/wrong ticket numbers in the
  subject.
  
      Tickets become a mess this way. This did happen only once or
  twice.
  
  
   3. There is no reply possible from within Trac. This is something
  
      OpenERP does very nicely. One can handle the ticket completely
  in
  
      the web application, while in Trac you have to go back to your
  MUA.
  
  
   4. Spam was an issue for us, but we probably did not investigate
  
      enough what to do about it.
  
  
  HTH, Cheers
  
  


  




-- 
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 http://groups.google.com/group/trac-users.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Trac] trac-admin upgrade failed

[Garrett McGrath]

We don't use the announcer plugin but I suspect this can be traced back 
to having had 'something' installed at some point.  To that end I have a 
question.  Is there a way to remove all the new db tweaks made by 
plugins and restore an env back to 'stock', specifically in an sqlite db 
setup?


Making the leap in versions will require redoing all of our plugins and 
some significant tweaking / updating of the pages anyway so scrubbing it 
off all the plugin cruft doesn't seem 'too' expensive.


As an alternative I'll have to find a way to temporarily invoke 0.12 
trac to do an upgrade from 0.11 then go to 1.0 from there.

-Garrett

On 9/26/2012 12:37 PM, Patrick Schaaf wrote:

On Wed, 2012-09-26 at 11:51 -0400, Garrett McGrath wrote:

I've run into an odd error in my attempts to update to 1.0.  I've got
2 Trac environments which give me the following when I run an update:

 trac-admin /usr/local/data/trac/env/Internal upgrade
 The upgrade failed. Please fix the issue and try again.
 
 AttributeError:

Do you have the TracAnnouncer plugin? Upgrading it fails with exactly
that very informative error.

See http://trac-hacks.org/ticket/10230 which also includes a workaround
in the description.

best regards
   Patrick



--
You received this message because you are subscribed to the Google Groups "Trac 
Users" group.
To post to this group, send email to trac-users@googlegroups.com.
To unsubscribe from this group, send email to 
trac-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/trac-users?hl=en.

[Trac] trac-admin upgrade failed

[Garrett McGrath]

  
  
I've run into an odd error in my attempts to update to 1.0.  I've
got 2 Trac environments which give me the following when I run an
update:

trac-admin /usr/local/data/trac/env/Internal upgrade
  The upgrade failed. Please fix the issue and try again.
  
  AttributeError: 

Sadly, the script never tells me what the attribute error actually
is, and since this isn't yet at 1.0, there is no trac.log file being
created for me to peruse on my own (or was this introduced in
0.12?).

I've successfully upgraded another environment that was similar to
the referred to 'internal' env.  However that one had been upgraded
from 0.11 -> 0.12 -> 1.0.  These are attempting to go from
0.11->1.0.  I'm wondering if this is possibly caused by an addon
that has altered the database layout (tags?).  Has anybody else run
    into this issue before?

-Garrett McGrath
  




-- 
You received this message because you are subscribed to the Google Groups "Trac Users" group.
To post to this group, send email to trac-users@googlegroups.com.
To unsubscribe from this group, send email to trac-users+unsubscr...@googlegroups.com.

For more options, visit this group at http://groups.google.com/group/trac-users?hl=en.

Re: [Trac] - How to setup email2trac for multiple projects

[Garrett McGrath]

There are command line arguments you associate with the given email 
alias to select which project your targeting.  I believe you have to be 
using the 'multiple trac environments' style config, but I'm not sure.  
We use it and it works fine.

-Garrett

On 6/7/2010 11:12 PM, mark ardiente wrote:

Does anyone know how to make this work?


Mark
** 

--
You received this message because you are subscribed to the Google 
Groups "Trac Users" group.

To post to this group, send email to trac-us...@googlegroups.com.
To unsubscribe from this group, send email to 
trac-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/trac-users?hl=en.


--
You received this message because you are subscribed to the Google Groups "Trac 
Users" group.
To post to this group, send email to trac-us...@googlegroups.com.
To unsubscribe from this group, send email to 
trac-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/trac-users?hl=en.

[Trac] Re: Trac in trouble.

[Garrett McGrath]

If you want multiple owners can you simply use the grouping system?  Put 
everyone in a group and assign the ticket to the group?  I haven't 
tested it but it seems like it 'should' work.  Then you'd be able to 
track the changes on a per user basis instead of having two users 
sharing an ID.

Toole, Brian wrote:
> How are you wanting the multiple owners to work?  Do you mean multiple
> owners for a given ticket component?  I'm not sure if this is exactly
> what you're looking for, but here's what I've done:
>
> We currently have one position (Report Writer) that is a time-share
> between two people, so since we do most of our ticket assignments based
> on Component, I assigned our Report Writer component to both people, so
> whenever a ticket comes through with that component, unless
> manually/specifically assigned to someone else, both of our Report
> Writers get the ticket.
>
> From there, I just modified the view tickets query code to allow for
> 'Contains' as well as the defaults of 'Is' and 'Is Not', and set
> 'Contains' as the default query method.
>
> Brian Toole
> Oracle Programming Specialist
> Web and Administrative Systems
> University of Portland
> Portland, OR 97203
> (503) 943-7196
> [EMAIL PROTECTED]
>
> -Original Message-
> From: trac-users@googlegroups.com [mailto:[EMAIL PROTECTED]
> On Behalf Of Jani Tiainen
> Sent: Wednesday, October 01, 2008 9:14 AM
> To: trac-users@googlegroups.com
> Subject: [Trac] Re: Trac in trouble.
>
>
> Erik Bray kirjoitti:
>   
>> On Wed, Oct 1, 2008 at 1:51 AM, Jani Tiainen <[EMAIL PROTECTED]>
>> 
> wrote:
>   
>>> I'm trying to keep Trac in our corporation environment but day after
>>>   
> day
>   
>>> it's coming more difficult due feature needs from users. I've tried
>>> several solutions but I haven't found anything even nearly working
>>>   
> and
>   
>>> what's "worse" someone found Redmine and it's working more or less
>>> "perfectly" for one of our projects and now they are pushing Redmine
>>>   
> to
>   
>>> all over the place.
>>>
>>> I would be more than happy to hear some solutions for my (and thus my
>>> boss) troubles. I've listed them here in order of priority.
>>>
>>> Trouble #1: Partially open environment. Recently there has been
>>> increasing need to have private and public parts of same project.
>>>   
> Public
>   
>>> part would be open for end users and developers, private part is for
>>> developers only. There must be way to cross reference these (see
>>>   
> trouble
>   
>>> #2). This also includes authentication from several sources. First
>>>   
> ldap
>   
>>> if user is found, if not some other mechanism that allows user self
>>> registering.
>>>
>>> Trouble #2: Cross-reference and xref actions. There is need to have
>>> "blocks" relation that is enforced.
>>>
>>> Trouble #3: Multiproject/multirepository support. We have few
>>>   
> projects
>   
>>> that are actually combination of several (separate) repositories but
>>> also there is few libraries that should be linked (and again, cross
>>> referenced, see trouble #2) together tightly. (Not loose coupling
>>>   
> like
>   
>>> external links)
>>>
>>> Trouble #4: Web based environment creation.
>>>
>>> Trouble #5: Userinformation retrieval from our LDAP server. Specially
>>> active accounts (since sometimes people come and people leave) and
>>> e-mail addresses.
>>>
>>> Trouble #6: Selective permissions (roles), specially for tickets.
>>>   
> Like I
>   
>>> could name "QA and management" persons that are allowed to close
>>>   
> tickets
>   
>>> that are sent to "qa" state.
>>>   
>> I was going to reply to you point by point, but instead I'll just say
>> that we do the majority of those bullet points with Trac.  We aren't
>> doing multiple authentication yet, though there are plans to, and
>> there's really nothing stopping anyone else from doing that.  In fact,
>> one could write a single PasswordStore that simply tries a list of
>> other PasswordStores in a specified order.
>>
>> The only other one we aren't doing anything with right now is #2,
>> which I think is the most legitimate complaint here (I mean, they're
>> all legitimate points, but most of them can be accomplished with
>> Trac).  I've played with Redmine, and there are a number of things
>> that it does make easier, but a lot of it does not fit my needs.  One
>> thing Trac makes easier (and this may be partly due to the fact that
>> it's written in Python, which I am more familiar with) is tweaking it
>> to make it do exactly what I want.
>> 
>
> Well, I would be happy to hear what is needed to make those points work,
>
> even partially. Most critical being #1.
>
> I've played with Redmine a bit and it works very well with subproject 
> things, simple cross referencing (same as MasterTicketPlugin) and it's 
> very nice issue tracking system. But rest of Redmine is "crap". And it's
>
> ruby thingy which is ugly itself. :D (That's about trashing R

[Trac] Re: Trac in trouble.

[Garrett McGrath]

On the other hand, the majority of plugins on the trac-hacks site are 
easy_install enabled making them almost as trivial as gems.

Jani Tiainen wrote:
> Gary Oberbrunner kirjoitti:
>   
>> Jani Tiainen wrote:
>> 
>>> I've played with Redmine a bit and it works very well with subproject 
>>> things, simple cross referencing (same as MasterTicketPlugin) and it's 
>>> very nice issue tracking system. But rest of Redmine is "crap". And it's 
>>> ruby thingy which is ugly itself. :D (That's about trashing Redmine).
>>>   
>> I'm mostly interested in subproject support and ticket xrefs (blocking
>> etc).  I haven't tried Redmine yet, but the demo certainly looks
>> enticing.  Obvious ripoff of Trac in many ways, but beyond it in several
>> (e.g. the things I need above, as well as gantt charting and more).
>> Jani, can you say more about what you find "crappy" about Redmine, from
>> your experience?  Ignoring ruby vs. python language wars of course --
>> this discussion should be about the best tool for the job.
>> 
>
>  From my limited experience there is several factors, most notably 
> Redmine is "closed" system. You either do it Redmine way or you don't do 
> it at all. It's not extensible as Trac (though, there is efforts made to 
> do that but I doubt it will be working any near future).
>
> Also lack of developers (only one or two main developers) makes feature 
> implementations much slower.
>
> Lot of things are "ripoff" from Trac. Wiki is most crappiest thing, no 
> hierarchy and such.
>
> Issue tracking in Redmine is pretty cool, specially you can have 
> different workflows for different roles.
>
> Multiproject/subproject thing is very nice, even it's not ultimate or 
> all covering solution but it works for most parts.
>
> One funny feature (I understood that's more like limitation of Ruby, not 
> Redmine itself) is that it's not trivial to install several separate 
> instances. So all projects must live together in one space...
>
> For end user point of view, it provides lot of features out of the box 
> with webui to customize settings. You don't need to know how to fetch, 
> install and handle plugins etc.
>
>   

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups "Trac 
Users" group.
To post to this group, send email to trac-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/trac-users?hl=en
-~--~~~~--~~--~--~---

[Trac] Re: Modify main menu

[Garrett McGrath]

If your using 0.10.x you can use the 'restricted area' plugin.  It's by 
no means fool proof but it does the job if you don't want to get too 
exotic.  For 0.11.x you'd have to look into how to use the fine grained 
permissions with the SVN authz style permissions file.  It won't remove 
the buttons but it will give them an access denied when they attempt to 
access that page.
-Garrett

Andrew Gehring wrote:
> But then you wouldn't even see the first, intro, page...
>
> Hmmm
>
> Andrew
>
>
> On 9/10/08, Noah Kantrowitz <[EMAIL PROTECTED]> wrote:
>   
>> You can't ...
>>
>> You should remove the permissions from the anonymous user, so they can't
>> even access the wiki system.
>>
>> --Noah
>>
>> 
>>> -Original Message-
>>> From: trac-users@googlegroups.com [mailto:[EMAIL PROTECTED]
>>> On Behalf Of Andrew Gehring
>>> Sent: Wednesday, September 10, 2008 2:30 PM
>>> To: trac-users@googlegroups.com
>>> Subject: [Trac] Modify main menu
>>>
>>>
>>> How does one specifically remove the Index,History, Last Change and
>>> prefrences menu items for non authenticated users?
>>>
>>> I've disabled the other menus items (wiki, timeline, roadmap,..), but
>>> can't find a way to disable those.
>>>
>>>
>>> Thanks,
>>> Andrew
>>>
>>>
>>>   
>> 
>
> >
>   

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups "Trac 
Users" group.
To post to this group, send email to trac-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/trac-users?hl=en
-~--~~~~--~~--~--~---

[Trac] Re: A couple issues

[Garrett McGrath]

We are running trac from the 0.11 stable release presently.  We upgraded 
to it from 0.10.3 (I think) when we moved to Python 2.5.  We've also 
recompiled mod_python and made sure we have a clean copy of python 2.5 
with no residual packages from 2.4.  We've noticed that at it's slowest 
it's typically faster than 0.10 was for us but it's still not anywhere 
near the performance I've seen on other systems I've setup and used on 
the internet.  I would be happy to provide any config information you 
might need to help sort this out.
-Garrett

Stephen Moretti wrote:
>
>
> 2008/9/4 Garrett McGrath <[EMAIL PROTECTED] 
> <mailto:[EMAIL PROTECTED]>>
>
>
> We think we may have solved our email looping problem by blacklisting
> some of the emails that would be involved with such an occurrence.
>
> That being done, we are back to the speed issues, and they are pretty
> hefty as we have times where it will take upwards of two minutes for
> the program to return when simply asking for a list of the available
> reports.  Moving to python 2.5 has provided us with a general
> performance boost but it's still pretty dog slow overall.  However it
> can be pretty zippy if it's used regularly, is there anyway to force
> apache to cache it so that we always have that level of
> responsiveness?
>
>
> Which version of Trac are you using? 
>
> >

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups "Trac 
Users" group.
To post to this group, send email to trac-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/trac-users?hl=en
-~--~~~~--~~--~--~---

[Trac] Re: A couple issues

[Garrett McGrath]

We think we may have solved our email looping problem by blacklisting
some of the emails that would be involved with such an occurrence.

That being done, we are back to the speed issues, and they are pretty
hefty as we have times where it will take upwards of two minutes for
the program to return when simply asking for a list of the available
reports.  Moving to python 2.5 has provided us with a general
performance boost but it's still pretty dog slow overall.  However it
can be pretty zippy if it's used regularly, is there anyway to force
apache to cache it so that we always have that level of
responsiveness?
-Garrett

On Sep 3, 12:28 pm, Garrett McGrath <[EMAIL PROTECTED]> wrote:
> I've been running trac for a variety of capacities for about a year
> and a half now (trying to keep my versions up to date as a I go).
>
> On a recent build I'm running into some issues I've never seen
> before.  For now the major issue is a mail loop that caused a blackout
> of the head groups email servers, and the secondary issue is speed
> problems and my need for pointers on solving them.
>
> For the first issue, it's a combined issue that we've tracked to a
> couple of different things that combine caused it to go haywire.
>
> 1st, we use the email2trac plugin, we've already submitted a bug
> report with them for this.
>
> 2nd, the user that emailed us CC'd our email2trac target in their
> email, which got placed in the email list starting this vicious cycle
>
> 3rd, we have all notifications on, we use the ticket system to track
> user requests and trouble tickets for the center where I work.  The
> users like receiving feedback without having to login to the trac
> system (and they honestly should need to ever look at the actual
> tickets unless they are trying to answer a question instead of
> submitting a request).
>
> So. out user sent us an email CC'd with ourselves as a target.  The
> system did it's thing and generated a responce email saying it had
> received it.  Which generated another ticket, twice as large as the
> previous one (since it included all of the previous tickets contents)
> and so on.
>
> All told by the time we stopped it we were flooded with over 2500 spam
> tickets and our trac.db (sqlite3) file had risen to 19 GB in size.  We
> also crippled the mail server servicing the user in question and wound
> up with our server blacklisted (with good reason).
>
> I've since taken up poking around at the notification system and would
> like to simply blacklist either specific email addresses or entire
> domains (like say the local domain the email alias we are using is
> on).  To this end I've added the domain we wish to block to the
> 'ignore_domains' flag in the trac.ini file but I'm not clear if this
> is actually what I want to be doing.  We also asked the email2trac
> devs to add a filter so it doesn't add CC's of it's own alias to the
> system but it's unclear if or when such a feature would be
> implemented.
>
> Does anyone here have any suggestions (aside from simply not using
> email2trac, as that would be a deal breaker) on how to solve this
> problem reliably so we can get ourselves off the black list we are on?
>
> After I've solved this problem I'll probably come back to ask about
> the speed issues but for quick referrence:
> *python is mounted on NFS
> *apache 2.2 is built with mod_python
> *the trac projects are all run on an sqlite db also mounted over NFS
> *the NFS data server is a huge fiber channel based storage system that
> has never indicated a problem with speed issues or performance.
> *our server is about 5 years old has 2 GB of ram and runs trac
> (specifically, and python is a bit slow but not like trac itself.)
> slower than my 7-8 year old machine at home with 512 mb of ram by
> several orders of magnitude.
> *trac is installed un compressed so that I have one less step to deal
> with.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups "Trac 
Users" group.
To post to this group, send email to trac-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/trac-users?hl=en
-~--~~~~--~~--~--~---

[Trac] A couple issues

[Garrett McGrath]

I've been running trac for a variety of capacities for about a year
and a half now (trying to keep my versions up to date as a I go).

On a recent build I'm running into some issues I've never seen
before.  For now the major issue is a mail loop that caused a blackout
of the head groups email servers, and the secondary issue is speed
problems and my need for pointers on solving them.

For the first issue, it's a combined issue that we've tracked to a
couple of different things that combine caused it to go haywire.

1st, we use the email2trac plugin, we've already submitted a bug
report with them for this.

2nd, the user that emailed us CC'd our email2trac target in their
email, which got placed in the email list starting this vicious cycle

3rd, we have all notifications on, we use the ticket system to track
user requests and trouble tickets for the center where I work.  The
users like receiving feedback without having to login to the trac
system (and they honestly should need to ever look at the actual
tickets unless they are trying to answer a question instead of
submitting a request).

So. out user sent us an email CC'd with ourselves as a target.  The
system did it's thing and generated a responce email saying it had
received it.  Which generated another ticket, twice as large as the
previous one (since it included all of the previous tickets contents)
and so on.

All told by the time we stopped it we were flooded with over 2500 spam
tickets and our trac.db (sqlite3) file had risen to 19 GB in size.  We
also crippled the mail server servicing the user in question and wound
up with our server blacklisted (with good reason).

I've since taken up poking around at the notification system and would
like to simply blacklist either specific email addresses or entire
domains (like say the local domain the email alias we are using is
on).  To this end I've added the domain we wish to block to the
'ignore_domains' flag in the trac.ini file but I'm not clear if this
is actually what I want to be doing.  We also asked the email2trac
devs to add a filter so it doesn't add CC's of it's own alias to the
system but it's unclear if or when such a feature would be
implemented.

Does anyone here have any suggestions (aside from simply not using
email2trac, as that would be a deal breaker) on how to solve this
problem reliably so we can get ourselves off the black list we are on?

After I've solved this problem I'll probably come back to ask about
the speed issues but for quick referrence:
*python is mounted on NFS
*apache 2.2 is built with mod_python
*the trac projects are all run on an sqlite db also mounted over NFS
*the NFS data server is a huge fiber channel based storage system that
has never indicated a problem with speed issues or performance.
*our server is about 5 years old has 2 GB of ram and runs trac
(specifically, and python is a bit slow but not like trac itself.)
slower than my 7-8 year old machine at home with 512 mb of ram by
several orders of magnitude.
*trac is installed un compressed so that I have one less step to deal
with.

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups "Trac 
Users" group.
To post to this group, send email to trac-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/trac-users?hl=en
-~--~~~~--~~--~--~---

[Trac] Re: Replacing WIKI_VIEW privileges are required to perform this operation

[Garrett McGrath]

Actually I found a work around.  Our cover page isn't all that informative
it's really just a list of topics of interest.  So I setup the
'RestrictedAccess' plugin and made everything from /trac/wiki/ part of the
restricted zone.  This allows non authenticated users to see the front page
but nothing else in the system.

On 3/13/07, Jason Winnebeck <[EMAIL PROTECTED]> wrote:
>
>
> You could probably do what you directly want if you modify the source...
> If you are interested in an alternative:
>
> If you use HTTP authentication (say through Apache), you might achieve the
> effect you want (or could live with). In my work environment this is what we
> do -- since it's an internal Trac we require everyone to login. Since it is
> HTTP authentication, the server does not even allow the page to be loaded
> without an authorization. And once you have an authorization, then you are
> logged into Trac. You might consider the browser's password prompt more user
> friendly than the "WIKI_VIEW" error. SSL can also be used if security is a
> concern (as we do).
>
> Jason
>
> ________
> From: trac-users@googlegroups.com [mailto:[EMAIL PROTECTED] On
> Behalf Of Garrett McGrath
> Sent: Tuesday, March 13, 2007 1:54 PM
> To: trac-users@googlegroups.com
> Subject: [Trac] Replacing WIKI_VIEW privileges are required to perform
> this operation
>
> To all,
> I'm presently running a few trac wiki's as internal data portals and
> script storage areas for some people in my department. However they are
> locked to the outside world unless you login with a known user name and
> password. The problem is that the 'WIKI_VIEW privileges are required to
> perform this operation' error comes up whenever they open the site throwing
> a lot of people off (they need to be accessible from everywhere but locked
> so casual browsing won't see them). I'd like to just replace this big red
> box with a static resource saying "Please login to view the wiki data." Or
> something to that effect. Any suggestions?
>
> -Garrett McGrath
> Software Engineer
> CSBMB Princeton University
> Green Hall
> 1-(609)-258-0285
>
>
>
> >
>

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups "Trac 
Users" group.
To post to this group, send email to trac-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/trac-users?hl=en
-~--~~~~--~~--~--~---

[Trac] Replacing WIKI_VIEW privileges are required to perform this operation

[Garrett McGrath]

To all,

I'm presently running a few trac wiki's as internal data
portals and script storage areas for some people in my department.  However
they are locked to the outside world unless you login with a known user name
and password.  The problem is that the 'WIKI_VIEW privileges are required to
perform this operation' error comes up whenever they open the site throwing
a lot of people off (they need to be accessible from everywhere but locked
so casual browsing won't see them).  I'd like to just replace this big red
box with a static resource saying "Please login to view the wiki data." Or
something to that effect.  Any suggestions?

 

-Garrett McGrath

Software Engineer

CSBMB Princeton University

Green Hall

1-(609)-258-0285

 


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups "Trac 
Users" group.
To post to this group, send email to trac-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/trac-users?hl=en
-~--~~~~--~~--~--~---

[Trac] Re: Slow Performance

[Garrett McGrath]

Right now It's just a simple 'Basic' Authentication via the standard
authentication plugins provided by Apache.  The strange thing thou is
that even if i'm already logged in and I just ignore the trac window
for a while, when i return to it I get the same sluggish performance.
I'm getting the impression it may be a data caching issue but I'm not
sure.
-Garrett

On 1/31/07, Emmanuel Blot <[EMAIL PROTECTED]> wrote:
>
> Which kind of authentication back end are you using?
>
> On 1/31/07, Garrett McGrath <[EMAIL PROTECTED]> wrote:
> >
> > I'm sure this isn't a trac specific issue but unfortunately it's
> > affecting my trac execution.  I'm running apache 2.2.3 with Python 2.4
> > and Mod_python.  The problem arrises when the system hasn't been used
> > for a while.  The trac system crawls taking up to a minute to load,
> > afterwards it becomes typically very responsive (at least once you've
> > logged in, as i've configured it to be useless if your no logged in.).
> > -Garrett McGrath
> >
> > >
> >
>
>
> --
> Manu
>
> >
>

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups "Trac 
Users" group.
To post to this group, send email to trac-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/trac-users?hl=en
-~--~~~~--~~--~--~---

[Trac] Slow Performance

[Garrett McGrath]

I'm sure this isn't a trac specific issue but unfortunately it's
affecting my trac execution.  I'm running apache 2.2.3 with Python 2.4
and Mod_python.  The problem arrises when the system hasn't been used
for a while.  The trac system crawls taking up to a minute to load,
afterwards it becomes typically very responsive (at least once you've
logged in, as i've configured it to be useless if your no logged in.).
-Garrett McGrath

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups "Trac 
Users" group.
To post to this group, send email to trac-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/trac-users?hl=en
-~--~~~~--~~--~--~---

[Trac] Re: How to setup user name/password in trac

[Garrett McGrath]

Also you can add permissions to 'authenticated' (I think it's
authenticated..) and that's a group for all users that are logged in.  So
things applied to it apply blanket to all users.

-Garrett McGrath
Software Engineer
CSBMB Princeton University
Green Hall
1-(609)-258-0285


-Original Message-
From: trac-users@googlegroups.com [mailto:[EMAIL PROTECTED] On
Behalf Of Emmanuel Blot
Sent: Friday, January 26, 2007 12:40 PM
To: trac-users@googlegroups.com
Subject: [Trac] Re: How to setup user name/password in trac


Users/passwords (credentials) are not managed by Trac. It's a web
server task (except if you use the standalone daemon tracd, or a
custom authentication plugin)

Search the ML archive, this topic has already been detailled several
times (search for authentication and permission)

> But can you please tell
> me how to setup user name/password in trac and does a new user has
> 'user' permission once it is created?

You need to use trac-admin to add permissions to each user (or group of
users).

HTH,
Manu



--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups "Trac 
Users" group.
To post to this group, send email to trac-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/trac-users?hl=en
-~--~~~~--~~--~--~---

[Trac] Re: Possible to use plain text instead of wikiformatting?

[Garrett McGrath]

Ah, well I guess technically this is a wiki formatting thing but if you just
put a second line in like: 


Line 1.

Line 2. 


Line 3.

It'll work a bit better. 


-Original Message-
From: trac-users@googlegroups.com [mailto:[EMAIL PROTECTED] On
Behalf Of Leon Torres
Sent: Monday, January 08, 2007 2:33 PM
To: trac-users@googlegroups.com
Subject: [Trac] Re: Possible to use plain text instead of wikiformatting?


Hi again. :-)

It doesn't quite match what the user types in.  The specific issue my boss
had was when he was typing in several lines like follows:

Line 1.
Line 2.
Line 3.

This isn't an itemized list, just several lines intended to be separated by
a CR.  The wiki formatting put them all into one paragraph:

Line1. Line2. Line3.

Whereas in a standard  text, it would come out exactly as the user
typed.

For instance, see the sourceforge issue description boxes.  Those use plain
text formatting and what you type is what you get. 


I personally don't mind the wiki formatting as plain text input, but one day
my boss typed in a ticket for me to do and when I read it, the lines were
jumbled together and created a communication issue.

- Leon



Garrett McGrath wrote:


Really the wiki formatting is only there to make things look pretty if 
they just type it'll come out as plain text (or at least it 'should').  
Just reinforce the use of the 'preview and confirm' practice.

-Original Message-
From: trac-users@googlegroups.com [mailto:[EMAIL PROTECTED] 
On Behalf Of [EMAIL PROTECTED]

Sent: Monday, January 08, 2007 1:52 PM
To: Trac Users
Subject: [Trac] Possible to use plain text instead of wikiformatting?


Hi all,

I was wondering if it's possible to use plain text input in the trac 
ticket description field instead of wiki formatting?  The motivation 
for this is to present a simpler input format for users that might not 
be inclined to learn wiki formatting.


- Leon




>





--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups "Trac 
Users" group.
To post to this group, send email to trac-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/trac-users?hl=en
-~--~~~~--~~--~--~---

[Trac] Re: Possible to use plain text instead of wikiformatting?

[Garrett McGrath]

Really the wiki formatting is only there to make things look pretty if they
just type it'll come out as plain text (or at least it 'should').  Just
reinforce the use of the 'preview and confirm' practice. 


-Original Message-
From: trac-users@googlegroups.com [mailto:[EMAIL PROTECTED] On
Behalf Of [EMAIL PROTECTED]
Sent: Monday, January 08, 2007 1:52 PM
To: Trac Users
Subject: [Trac] Possible to use plain text instead of wikiformatting?


Hi all,

I was wondering if it's possible to use plain text input in the trac ticket
description field instead of wiki formatting?  The motivation for this is to
present a simpler input format for users that might not be inclined to learn
wiki formatting.

- Leon




--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups "Trac 
Users" group.
To post to this group, send email to trac-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/trac-users?hl=en
-~--~~~~--~~--~--~---

[Trac] automatic new window

[Garrett McGrath]

I'm trying to figure out a way to make it so that when you click on a link
it opens as a new window / tab instead of taking you away from the trac page
to that new page.  The reason being is that trac is becoming our new
knowledge portal and we would like to be able to referrence people back to
the old portal if need be without closing thier trac connection.  Is there a
way to do this without embedding the html code?
-Garrett

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups "Trac 
Users" group.
To post to this group, send email to trac-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/trac-users?hl=en
-~--~~~~--~~--~--~---

[Trac] Auto hierarchy

[Garrett McGrath]

I've yet to find it 
if there is somthing that can do this.  Is there a way when creating new 
wiki pages to make them automatically hierarch to the page they are being 
created from?  so if i have say an engine i'm designing i can have a main 
page called 'Components'.  then when i create wiki links to the pieces of 
the engine each of them are filled in as components/ so 
that things like the subwiki/parentwiki command work in a more easily defined 
way and without alot of repedative typing?
--~--~-~--~~~---~--~~
 You received this message because you are subscribed to the Google Groups "Trac Users" group.  To post to this group, send email to trac-users@googlegroups.com  To unsubscribe from this group, send email to [EMAIL PROTECTED]  For more options, visit this group at http://groups.google.com/group/trac-users?hl=en  -~--~~~~--~~--~--~---

[Trac] Re: Issue with svn bindings

[Garrett McGrath]

It means your svn Python bindings are broken in some way or another, the problem is this never manifests quiet the same on each machine.  It could also mean that Neon (a SVN dependancy) isn't built correctly.  My recommendation.  Find your neon install ( i can almost guarantee it's inside the src folder for your svn install) and rename the folder.  Go into that folder and build new using the shared and static enables, also make sure that neon is built against ssl.  This will prevent svn from building neon when it gets built.  Then rebuild your svn by first doing a make clean and make clean-swig-py.  run ./configure (with any flags you want) do a make && make swig-py.  then do a make install && make install-swig-py.  That should help get you on your way.

 
As an asside ensure that the versions of apr and apr-util that svn is building against are correct and are infact the apache 2.2.3 ones (version 1.2.7 not 0.9.3 which is what svn comes with) I can almost guarantee that svn is building those as well if you've unpacked the dependancies (so rename them too and track down apr-config and apu-config and make sure they are the right versions.  apache 
2.2.3 built those as apr-1-config and apu-1-config on my system so be careful.)
 
I've actually written a bit about this on the svn mailing list because it took me so long to fix, you can check there for more details (sorry I don't have a link off hand.) 
On 11/3/06, Christian Billen <[EMAIL PROTECTED]> wrote:

Ah, looks like we're on to something:Python 2.4.4c1 (#2, Oct 11 2006, 21:51:02) [GCC 4.1.2 20060928 (prerelease) (Ubuntu 4.1.1-13ubuntu5
)] on linux2Type "help", "copyright", "credits" or "license" for more information.>>> import svn.reposTraceback (most recent call last):  File "", line 1, in ?
  File "svn/repos.py", line 19, in ?from libsvn.repos import *  File "libsvn/repos.py", line 5, in ?import _reposImportError: /usr/local/lib/libsvn_ra_dav-1.so.0: undefined symbol: SSL_shutdown
>>> What it means I am not sure yet but I'm sure you guys do :)C 
On 11/3/06 1:29 PM, "Garrett McGrath" <
[EMAIL PROTECTED]> wrote:

in python do this command:import svn.repos What do you get out? On 11/3/06, Christian Billen <
[EMAIL PROTECTED]> wrote: 
Good afternoon,I am getting "Unsupported version control system "svn" when trying to access the time line or browse source from Trac 
0.10 stable.  I have Ubuntu 6.10,SVN 1.4 on apache 2.2.3 via mod_python.I have compiled subversion and the python bindings as such:./configure --with-apr=/usr/local/apache2 --with-apr-util=/usr/local/apache2 
--with-ssl --with-swig--with-neon=/usmakemake swig-pymake installmake install-swig-pyThe above steps complete successfullyFinally I copied the libsvn and svn folder that were installed to 
/usr/local/lib/svn-python to /usr/local/python2.4/site-packagesI can start python and do import svn without errors.However trac does not seem to think so.Internal ErrorTicket changes event provider (TicketModule) failed: 
TracError: Unsupported version control system "svn"You may want to see the other kind of events from the TimelineI can only see Milestones and WikiChanges, Ticket and Repository fails with 
the same error.When I do browse source I see the same error "Unsupported version controlsystem svn"Is there a step I am missing?Thank you

--~--~-~--~~~---~--~~
 You received this message because you are subscribed to the Google Groups "Trac Users" group.  To post to this group, send email to trac-users@googlegroups.com  To unsubscribe from this group, send email to [EMAIL PROTECTED]  For more options, visit this group at http://groups.google.com/group/trac-users?hl=en  -~--~~~~--~~--~--~---

[Trac] Re: Issue with svn bindings

[Garrett McGrath]

in python do this command:
import svn.repos
 
What do you get out? 
On 11/3/06, Christian Billen <[EMAIL PROTECTED]> wrote:
Good afternoon,I am getting "Unsupported version control system "svn" when trying to access
the time line or browse source from Trac 0.10 stable.  I have Ubuntu 6.10,SVN 1.4 on apache 2.2.3 via mod_python.I have compiled subversion and the python bindings as such:./configure --with-apr=/usr/local/apache2 --with-apr-util=/usr/local/apache2
--with-ssl --with-swig--with-neon=/usmakemake swig-pymake installmake install-swig-pyThe above steps complete successfullyFinally I copied the libsvn and svn folder that were installed to
/usr/local/lib/svn-python to /usr/local/python2.4/site-packagesI can start python and do import svn without errors.However trac does not seem to think so.Internal ErrorTicket changes event provider (TicketModule) failed:
TracError: Unsupported version control system "svn"You may want to see the other kind of events from the TimelineI can only see Milestones and WikiChanges, Ticket and Repository fails with
the same error.When I do browse source I see the same error "Unsupported version controlsystem svn"Is there a step I am missing?Thank you
--~--~-~--~~~---~--~~
 You received this message because you are subscribed to the Google Groups "Trac Users" group.  To post to this group, send email to trac-users@googlegroups.com  To unsubscribe from this group, send email to [EMAIL PROTECTED]  For more options, visit this group at http://groups.google.com/group/trac-users?hl=en  -~--~~~~--~~--~--~---

[Trac] Re: Recommendations for literature?

[Garrett McGrath]

Despite it's claims to the contrary I found that picking up the OReilly 'Python Cookbook' was the easy way to learn python.  For me at least.
On 11/3/06, Christian Boos <[EMAIL PROTECTED]> wrote:
Rainer Sokoll wrote:> ... only what is needed to understand, debug and extend trac.>
As for Trac specific documentation, I've started this:http://trac.edgewall.org/wiki/TracTroubleshooting#DebuggingTrac-- Christian

--~--~-~--~~~---~--~~
 You received this message because you are subscribed to the Google Groups "Trac Users" group.  To post to this group, send email to trac-users@googlegroups.com  To unsubscribe from this group, send email to [EMAIL PROTECTED]  For more options, visit this group at http://groups.google.com/group/trac-users?hl=en  -~--~~~~--~~--~--~---

[Trac] Re: Admin gone after 0.10 upgrade?

[Garrett McGrath]

I've had this problem with a variety of plugins and it seems to be traced back to the python egg cache, things do 'eventually' catch up but every once in a while it will be slow to unpack the eggs and they just disappear from the admin area.  It is in some way connected to the cache and maybe related to python reloading the egg for each page querry.  I'm not sure if this is true but it's what seems to be going on (for me at least).

On 11/3/06, Terry Dooher <[EMAIL PROTECTED]> wrote:
I tend to have this issue just after setting up a new trac with plugins. Theproblem is usually that mod_python has cached versions of scripts lying around
that it uses. It drove me nuts before I figured it out...Restarting the web server (is possible) is a the quick and blunt way offlushing these out.Terry.Camille wrote:> Hi,>
> I'm experimenting the same bahavior: Admin button goes and comes back> with no apparent logic. The logs (apache and trac) show nothing> relevant...>> Camille>> On Oct 10, 1:26 pm, Marcus Bointon <
[EMAIL PROTECTED]> wrote:>> I'm not sure what I did (if anything!), but my admin tab has>> magically reappeared and seems to work fine. I guess sometimes
>> unexplained good things happen! Marcus>> -->> Marcus Bointon>> Synchromedia Limited: Creators ofhttp://www.smartmessages.net/>> 
[EMAIL PROTECTED] |http://www.synchromedia.co.uk/>>> >>

--~--~-~--~~~---~--~~
 You received this message because you are subscribed to the Google Groups "Trac Users" group.  To post to this group, send email to trac-users@googlegroups.com  To unsubscribe from this group, send email to [EMAIL PROTECTED]  For more options, visit this group at http://groups.google.com/group/trac-users?hl=en  -~--~~~~--~~--~--~---