Re: [rt-users] RT4 upgrade woes - user accounts lock?

2011-06-07 Thread Kevin Falcone
On Tue, Jun 07, 2011 at 04:31:25PM -0400, Joshua Knarr wrote:
>99% sure I did it.
> 
>Since I have a trashed staging DB here I ran the command again and it had 
> no effect.
>
>We're going from 3.4.5, reading the upgrading docs sequentially doesn't 
> mention anything about
>this schema change nor how to effect it. Looking in the script you pointed 
> me to, this doesn't
>actually change the schema.
> 
>Running the upgrade-mysql-schema.pl produces the following:
>ALTER TABLE Users
>   DEFAULT CHARACTER SET utf8;
> 
>However there's nothing here that actually changes the password from 
> varchar(40) to whatever
>value it needs to be.

There are multiple upgrade steps, UPGRADING.mysql is not the only thing
you need to do. There are at least 2 other etc/upgrade scripts to run
besides upgrade-mysql-schema.pl and it doesn't appear that you've run any
of the rt-setup-database steps as mentioned in the README 6b.

If you've actually skipped all of the database upgrades between 3.4.5
and 4.0.0 you're missing a lot of changes.

-kevin

>On Tue, 2011-06-07 at 16:04 -0400, Kevin Falcone wrote:
> 
>  On Tue, Jun 07, 2011 at 03:48:19PM -0400, Joshua Knarr wrote:
>  > Attached.
> 
>  You don't appear to have run the database upgrades.
>  Which upgrade steps have you done?  Please show exactly what you ran
>  and the outputs.  You should be sure to review all relevant
>  docs/UPGRADING-*
> 
>  `Password` varbinary(40) default NULL,
> 
>  That is not the right size for the passwords, which is why your users
>  get locked out after the upgrade.  Please note that merely fixing the
>  size is unlikely to fix other problems caused by skipping upgrades.
> 
>  -kevin
> 
>  > On Tue, 2011-06-07 at 11:52 -0400, Kevin Falcone wrote:
>  >
>  > > On Tue, Jun 07, 2011 at 09:23:42AM -0400, Joshua Knarr wrote:
>  > > >We seriously do not have any extensions, either on the old host or 
> the new host. We would like
>  > > >to be able to use LDAP at some point but it isn't looking good for 
> keeping confluence overall.
>  > > >
>  > > >I wiped the new box and I wiped the database host and redid the 
> entire process from the get go
>  > > >- we're still experiencing the same problem.
>  > > >
>  > > >It looks like RT is having problems matching the SHA hashes, but 
> I'm really not sure what's
>  > > >going on. I know in users.pm we convert the password the first time 
> the user logs in from MD5
>  > > >to SHA, but then it seems to fail all the new SHA matches. WTF?
>  > >
>  > > You should be running the vulnerable-passwords script as documented in
>  > > the UPGRADING-3.8 documentation which means passwords will already be
>  > > in the new SHA format.
>  > >
>  > > Did you do all the upgrade steps?
>  > >
>  > > Please run 'SHOW CREATE TABLE Users'
>  > >
>  > > -kevin
>  > >
>  > > >On Mon, 2011-06-06 at 10:57 -0400, Kevin Falcone wrote:
>  > > >
>  > > >  On Mon, Jun 06, 2011 at 10:44:46AM -0400, Joshua Knarr wrote:
>  > > >  >I just tracked this down to the password changing in the 
> database...
>  > > >  >
>  > > >  >If I try to log in after upgrading - it works for awhile then 
> stops working. The question is
>  > > >  >why?
>  > > >  >
>  > > >  >The workaround:
>  > > >  >UPDATE Users SET Password=md5('password') WHERE Name='knarrj';
>  > > >  >
>  > > >  >This isn't good. I would vastly prefer to not have to run the 
> upgrade again and I would really
>  > > >  >like to use the old passwords. Is there a workaround? What 
> changed?
>  > > >
>  > > >  What changed was
>  > > >  
> [1][1]http://lists.bestpractical.com/pipermail/rt-announce/2011-January/000185.html
>  > > >
>  > > >  It is also documented in docs/UPGRADING-3.8
>  > > >
>  > > >  It sounds like you have an extension somewhere that clobbers the new
>  > > >  password checking routine.  It also sounds like you missed some parts
>  > > >  of the upgrade.
>  > > >
>  > > >  -kevin
>  > > >
>  > > >  >On Mon, 2011-06-06 at 09:29 -0400, Joshua Knarr wrote:
>  > > >  >
>  > > >  >  I am upgrading from RT 3.4.5 to RT 4.
>  > > >  >
>  > > >  >  I read the docs and stopped at 3.8, did the schema stuff, and 
> then continued to 4 per the
>  > > >  >  instructions for upgrading mysql also.
>  > > >  >
>  > > >  >  On the new system it runs for a few hours just fine, but then 
> suddenly everyones account
>  > > >  >  gets locked.
>  > > >  >
>  > > >  >  I restarted the services, I checked my configs, I'm coming up 
> empty. What went wrong or
>  > > >  >  where should I be looking?
>  > > >
>  > > >--
>  > > >Joshua Knarr
>  > > >Systems Engineer
>  > > >GSI Commerce, Inc.  [2][2]http://www.gsicommerce.com
>  > > >E-Mail: [3][3]kna...@gsicommerce.com
>  > > >Office: 610-491-7110
>  > > >Mobile: 484-636-7371
>  > > >
>  > > >The information contained in this electronic mail transmission is 
> intended only

Re: [rt-users] RT4 upgrade woes - user accounts lock?

2011-06-07 Thread Joshua Knarr
99% sure I did it.

Since I have a trashed staging DB here I ran the command again and it
had no effect.

We're going from 3.4.5, reading the upgrading docs sequentially doesn't
mention anything about this schema change nor how to effect it. Looking
in the script you pointed me to, this doesn't actually change the
schema. 

Running the upgrade-mysql-schema.pl produces the following:
ALTER TABLE Users
   DEFAULT CHARACTER SET utf8;

However there's nothing here that actually changes the password from
varchar(40) to whatever value it needs to be.

On Tue, 2011-06-07 at 16:04 -0400, Kevin Falcone wrote:

> On Tue, Jun 07, 2011 at 03:48:19PM -0400, Joshua Knarr wrote:
> > Attached.
> 
> You don't appear to have run the database upgrades.
> Which upgrade steps have you done?  Please show exactly what you ran
> and the outputs.  You should be sure to review all relevant
> docs/UPGRADING-*
> 
> `Password` varbinary(40) default NULL,
> 
> That is not the right size for the passwords, which is why your users
> get locked out after the upgrade.  Please note that merely fixing the
> size is unlikely to fix other problems caused by skipping upgrades.
> 
> -kevin
> 
> > On Tue, 2011-06-07 at 11:52 -0400, Kevin Falcone wrote:
> > 
> > > On Tue, Jun 07, 2011 at 09:23:42AM -0400, Joshua Knarr wrote:
> > > >We seriously do not have any extensions, either on the old host or 
> > > > the new host. We would like
> > > >to be able to use LDAP at some point but it isn't looking good for 
> > > > keeping confluence overall.
> > > > 
> > > >I wiped the new box and I wiped the database host and redid the 
> > > > entire process from the get go
> > > >- we're still experiencing the same problem.
> > > > 
> > > >It looks like RT is having problems matching the SHA hashes, but I'm 
> > > > really not sure what's
> > > >going on. I know in users.pm we convert the password the first time 
> > > > the user logs in from MD5
> > > >to SHA, but then it seems to fail all the new SHA matches. WTF?
> > > 
> > > You should be running the vulnerable-passwords script as documented in
> > > the UPGRADING-3.8 documentation which means passwords will already be
> > > in the new SHA format.
> > > 
> > > Did you do all the upgrade steps?
> > > 
> > > Please run 'SHOW CREATE TABLE Users'
> > > 
> > > -kevin
> > > 
> > > >On Mon, 2011-06-06 at 10:57 -0400, Kevin Falcone wrote:
> > > > 
> > > >  On Mon, Jun 06, 2011 at 10:44:46AM -0400, Joshua Knarr wrote:
> > > >  >I just tracked this down to the password changing in the 
> > > > database...
> > > >  >
> > > >  >If I try to log in after upgrading - it works for awhile then 
> > > > stops working. The question is
> > > >  >why?
> > > >  >
> > > >  >The workaround:
> > > >  >UPDATE Users SET Password=md5('password') WHERE Name='knarrj';
> > > >  >
> > > >  >This isn't good. I would vastly prefer to not have to run the 
> > > > upgrade again and I would really
> > > >  >like to use the old passwords. Is there a workaround? What 
> > > > changed?
> > > > 
> > > >  What changed was
> > > >  
> > > > [1]http://lists.bestpractical.com/pipermail/rt-announce/2011-January/000185.html
> > > > 
> > > >  It is also documented in docs/UPGRADING-3.8
> > > > 
> > > >  It sounds like you have an extension somewhere that clobbers the new
> > > >  password checking routine.  It also sounds like you missed some parts
> > > >  of the upgrade.
> > > > 
> > > >  -kevin
> > > > 
> > > >  >On Mon, 2011-06-06 at 09:29 -0400, Joshua Knarr wrote:
> > > >  >
> > > >  >  I am upgrading from RT 3.4.5 to RT 4.
> > > >  >
> > > >  >  I read the docs and stopped at 3.8, did the schema stuff, and 
> > > > then continued to 4 per the
> > > >  >  instructions for upgrading mysql also.
> > > >  >
> > > >  >  On the new system it runs for a few hours just fine, but then 
> > > > suddenly everyones account
> > > >  >  gets locked.
> > > >  >
> > > >  >  I restarted the services, I checked my configs, I'm coming up 
> > > > empty. What went wrong or
> > > >  >  where should I be looking?
> > > > 
> > > >--
> > > >Joshua Knarr
> > > >Systems Engineer
> > > >GSI Commerce, Inc.  [2]http://www.gsicommerce.com
> > > >E-Mail: [3]kna...@gsicommerce.com
> > > >Office: 610-491-7110
> > > >Mobile: 484-636-7371
> > > > 
> > > >The information contained in this electronic mail transmission is 
> > > > intended only for the use of
> > > >the individual or entity named in this transmission. If you are not 
> > > > the intended recipient of
> > > >this transmission, you are hereby notified that any disclosure, 
> > > > copying or distribution of the
> > > >contents of this transmission is strictly prohibited and that you 
> > > > should delete the contents
> > > >of this transmission from your system immediately. Any comments or 
> > > > statements contained in
> > > >this transmission do not necessarily reflect the

Re: [rt-users] Custom Field "Type" text

2011-06-07 Thread Kevin Falcone
On Tue, Jun 07, 2011 at 03:49:10PM -0400, Mike DeVries wrote:
>When creating custom fields in RT4, there is a dropdown called Type with 
> values such as "Enter
>one value", "Select multiple values", etc.
> 
>When creating or modifying a ticket, each custom field has these text 
> labels beside it as an
>instruction to the user. However standard fields like Owner or Status do 
> not. Is it possible
>to remove these unwanted text labels so that only the Name of the custom 
> field is displayed?

The easiest solution is to hide it using site-local CSS on the cflabel's
type span

-kevin


pgpFGSVr1KQgV.pgp
Description: PGP signature


Re: [rt-users] RT4 upgrade woes - user accounts lock?

2011-06-07 Thread Kevin Falcone
On Tue, Jun 07, 2011 at 03:48:19PM -0400, Joshua Knarr wrote:
> Attached.

You don't appear to have run the database upgrades.
Which upgrade steps have you done?  Please show exactly what you ran
and the outputs.  You should be sure to review all relevant
docs/UPGRADING-*

`Password` varbinary(40) default NULL,

That is not the right size for the passwords, which is why your users
get locked out after the upgrade.  Please note that merely fixing the
size is unlikely to fix other problems caused by skipping upgrades.

-kevin

> On Tue, 2011-06-07 at 11:52 -0400, Kevin Falcone wrote:
> 
> > On Tue, Jun 07, 2011 at 09:23:42AM -0400, Joshua Knarr wrote:
> > >We seriously do not have any extensions, either on the old host or the 
> > > new host. We would like
> > >to be able to use LDAP at some point but it isn't looking good for 
> > > keeping confluence overall.
> > > 
> > >I wiped the new box and I wiped the database host and redid the entire 
> > > process from the get go
> > >- we're still experiencing the same problem.
> > > 
> > >It looks like RT is having problems matching the SHA hashes, but I'm 
> > > really not sure what's
> > >going on. I know in users.pm we convert the password the first time 
> > > the user logs in from MD5
> > >to SHA, but then it seems to fail all the new SHA matches. WTF?
> > 
> > You should be running the vulnerable-passwords script as documented in
> > the UPGRADING-3.8 documentation which means passwords will already be
> > in the new SHA format.
> > 
> > Did you do all the upgrade steps?
> > 
> > Please run 'SHOW CREATE TABLE Users'
> > 
> > -kevin
> > 
> > >On Mon, 2011-06-06 at 10:57 -0400, Kevin Falcone wrote:
> > > 
> > >  On Mon, Jun 06, 2011 at 10:44:46AM -0400, Joshua Knarr wrote:
> > >  >I just tracked this down to the password changing in the database...
> > >  >
> > >  >If I try to log in after upgrading - it works for awhile then stops 
> > > working. The question is
> > >  >why?
> > >  >
> > >  >The workaround:
> > >  >UPDATE Users SET Password=md5('password') WHERE Name='knarrj';
> > >  >
> > >  >This isn't good. I would vastly prefer to not have to run the 
> > > upgrade again and I would really
> > >  >like to use the old passwords. Is there a workaround? What changed?
> > > 
> > >  What changed was
> > >  
> > > [1]http://lists.bestpractical.com/pipermail/rt-announce/2011-January/000185.html
> > > 
> > >  It is also documented in docs/UPGRADING-3.8
> > > 
> > >  It sounds like you have an extension somewhere that clobbers the new
> > >  password checking routine.  It also sounds like you missed some parts
> > >  of the upgrade.
> > > 
> > >  -kevin
> > > 
> > >  >On Mon, 2011-06-06 at 09:29 -0400, Joshua Knarr wrote:
> > >  >
> > >  >  I am upgrading from RT 3.4.5 to RT 4.
> > >  >
> > >  >  I read the docs and stopped at 3.8, did the schema stuff, and 
> > > then continued to 4 per the
> > >  >  instructions for upgrading mysql also.
> > >  >
> > >  >  On the new system it runs for a few hours just fine, but then 
> > > suddenly everyones account
> > >  >  gets locked.
> > >  >
> > >  >  I restarted the services, I checked my configs, I'm coming up 
> > > empty. What went wrong or
> > >  >  where should I be looking?
> > > 
> > >--
> > >Joshua Knarr
> > >Systems Engineer
> > >GSI Commerce, Inc.  [2]http://www.gsicommerce.com
> > >E-Mail: [3]kna...@gsicommerce.com
> > >Office: 610-491-7110
> > >Mobile: 484-636-7371
> > > 
> > >The information contained in this electronic mail transmission is 
> > > intended only for the use of
> > >the individual or entity named in this transmission. If you are not 
> > > the intended recipient of
> > >this transmission, you are hereby notified that any disclosure, 
> > > copying or distribution of the
> > >contents of this transmission is strictly prohibited and that you 
> > > should delete the contents
> > >of this transmission from your system immediately. Any comments or 
> > > statements contained in
> > >this transmission do not necessarily reflect the views or position of 
> > > GSI Commerce, Inc. or
> > >its subsidiaries and/or affiliates.
> > > 
> > > References
> > > 
> > >Visible links
> > >1. 
> > > http://lists.bestpractical.com/pipermail/rt-announce/2011-January/000185.html
> > >2. http://www.gsicommerce.com/
> > >3. mailto:hell...@gsicommerce.com
> 
> 
> -- 
> Joshua Knarr
> Systems Engineer
> GSI Commerce, Inc.  http://www.gsicommerce.com
> E-Mail: kna...@gsicommerce.com
> Office: 610-491-7110
> Mobile: 484-636-7371
> 
> The information contained in this electronic mail transmission is
> intended only for the use of the individual or entity named in this
> transmission. If you are not the intended recipient of this
> transmission, you are hereby notified that any disclosure, copying or
> distribution of the contents of this transmission is strictl

[rt-users] Custom Field "Type" text

2011-06-07 Thread Mike DeVries
When creating custom fields in RT4, there is a dropdown called Type with 
values such as "Enter one value", "Select multiple values", etc.


When creating or modifying a ticket, each custom field has these text 
labels beside it as an instruction to the user. However standard fields 
like Owner or Status do not. Is it possible to remove these unwanted 
text labels so that only the Name of the custom field is displayed?


--
Mike DeVries
*Dido Internet Inc*
514-990-
m...@dido.ca


Re: [rt-users] RT4 upgrade woes - user accounts lock?

2011-06-07 Thread Joshua Knarr
Attached.

On Tue, 2011-06-07 at 11:52 -0400, Kevin Falcone wrote:

> On Tue, Jun 07, 2011 at 09:23:42AM -0400, Joshua Knarr wrote:
> >We seriously do not have any extensions, either on the old host or the 
> > new host. We would like
> >to be able to use LDAP at some point but it isn't looking good for 
> > keeping confluence overall.
> > 
> >I wiped the new box and I wiped the database host and redid the entire 
> > process from the get go
> >- we're still experiencing the same problem.
> > 
> >It looks like RT is having problems matching the SHA hashes, but I'm 
> > really not sure what's
> >going on. I know in users.pm we convert the password the first time the 
> > user logs in from MD5
> >to SHA, but then it seems to fail all the new SHA matches. WTF?
> 
> You should be running the vulnerable-passwords script as documented in
> the UPGRADING-3.8 documentation which means passwords will already be
> in the new SHA format.
> 
> Did you do all the upgrade steps?
> 
> Please run 'SHOW CREATE TABLE Users'
> 
> -kevin
> 
> >On Mon, 2011-06-06 at 10:57 -0400, Kevin Falcone wrote:
> > 
> >  On Mon, Jun 06, 2011 at 10:44:46AM -0400, Joshua Knarr wrote:
> >  >I just tracked this down to the password changing in the database...
> >  >
> >  >If I try to log in after upgrading - it works for awhile then stops 
> > working. The question is
> >  >why?
> >  >
> >  >The workaround:
> >  >UPDATE Users SET Password=md5('password') WHERE Name='knarrj';
> >  >
> >  >This isn't good. I would vastly prefer to not have to run the upgrade 
> > again and I would really
> >  >like to use the old passwords. Is there a workaround? What changed?
> > 
> >  What changed was
> >  
> > [1]http://lists.bestpractical.com/pipermail/rt-announce/2011-January/000185.html
> > 
> >  It is also documented in docs/UPGRADING-3.8
> > 
> >  It sounds like you have an extension somewhere that clobbers the new
> >  password checking routine.  It also sounds like you missed some parts
> >  of the upgrade.
> > 
> >  -kevin
> > 
> >  >On Mon, 2011-06-06 at 09:29 -0400, Joshua Knarr wrote:
> >  >
> >  >  I am upgrading from RT 3.4.5 to RT 4.
> >  >
> >  >  I read the docs and stopped at 3.8, did the schema stuff, and then 
> > continued to 4 per the
> >  >  instructions for upgrading mysql also.
> >  >
> >  >  On the new system it runs for a few hours just fine, but then 
> > suddenly everyones account
> >  >  gets locked.
> >  >
> >  >  I restarted the services, I checked my configs, I'm coming up 
> > empty. What went wrong or
> >  >  where should I be looking?
> > 
> >--
> >Joshua Knarr
> >Systems Engineer
> >GSI Commerce, Inc.  [2]http://www.gsicommerce.com
> >E-Mail: [3]kna...@gsicommerce.com
> >Office: 610-491-7110
> >Mobile: 484-636-7371
> > 
> >The information contained in this electronic mail transmission is 
> > intended only for the use of
> >the individual or entity named in this transmission. If you are not the 
> > intended recipient of
> >this transmission, you are hereby notified that any disclosure, copying 
> > or distribution of the
> >contents of this transmission is strictly prohibited and that you should 
> > delete the contents
> >of this transmission from your system immediately. Any comments or 
> > statements contained in
> >this transmission do not necessarily reflect the views or position of 
> > GSI Commerce, Inc. or
> >its subsidiaries and/or affiliates.
> > 
> > References
> > 
> >Visible links
> >1. 
> > http://lists.bestpractical.com/pipermail/rt-announce/2011-January/000185.html
> >2. http://www.gsicommerce.com/
> >3. mailto:hell...@gsicommerce.com


-- 
Joshua Knarr
Systems Engineer
GSI Commerce, Inc.  http://www.gsicommerce.com
E-Mail: kna...@gsicommerce.com
Office: 610-491-7110
Mobile: 484-636-7371

The information contained in this electronic mail transmission is
intended only for the use of the individual or entity named in this
transmission. If you are not the intended recipient of this
transmission, you are hereby notified that any disclosure, copying or
distribution of the contents of this transmission is strictly prohibited
and that you should delete the contents of this transmission from your
system immediately. Any comments or statements contained in this
transmission do not necessarily reflect the views or position of GSI
Commerce, Inc. or its subsidiaries and/or affiliates.
Table   Create Table
Users   CREATE TABLE `Users` (\n  `id` int(11) NOT NULL auto_increment,\n  
`Name` varchar(200) NOT NULL default '',\n  `Password` varbinary(40) default 
NULL,\n  `Comments` text,\n  `Signature` text,\n  `EmailAddress` varchar(120) 
character set ascii default NULL,\n  `FreeformContactInfo` text,\n  
`Organization` varchar(200) default NULL,\n  `RealName` varchar(120) default 
NULL,\n  `NickName` varchar(16) default NULL,\n  `Lang` varchar(16) character 

Re: [rt-users] RT4 upgrade woes - user accounts lock?

2011-06-07 Thread Kevin Falcone
On Tue, Jun 07, 2011 at 09:23:42AM -0400, Joshua Knarr wrote:
>We seriously do not have any extensions, either on the old host or the new 
> host. We would like
>to be able to use LDAP at some point but it isn't looking good for keeping 
> confluence overall.
> 
>I wiped the new box and I wiped the database host and redid the entire 
> process from the get go
>- we're still experiencing the same problem.
> 
>It looks like RT is having problems matching the SHA hashes, but I'm 
> really not sure what's
>going on. I know in users.pm we convert the password the first time the 
> user logs in from MD5
>to SHA, but then it seems to fail all the new SHA matches. WTF?

You should be running the vulnerable-passwords script as documented in
the UPGRADING-3.8 documentation which means passwords will already be
in the new SHA format.

Did you do all the upgrade steps?

Please run 'SHOW CREATE TABLE Users'

-kevin

>On Mon, 2011-06-06 at 10:57 -0400, Kevin Falcone wrote:
> 
>  On Mon, Jun 06, 2011 at 10:44:46AM -0400, Joshua Knarr wrote:
>  >I just tracked this down to the password changing in the database...
>  >
>  >If I try to log in after upgrading - it works for awhile then stops 
> working. The question is
>  >why?
>  >
>  >The workaround:
>  >UPDATE Users SET Password=md5('password') WHERE Name='knarrj';
>  >
>  >This isn't good. I would vastly prefer to not have to run the upgrade 
> again and I would really
>  >like to use the old passwords. Is there a workaround? What changed?
> 
>  What changed was
>  
> [1]http://lists.bestpractical.com/pipermail/rt-announce/2011-January/000185.html
> 
>  It is also documented in docs/UPGRADING-3.8
> 
>  It sounds like you have an extension somewhere that clobbers the new
>  password checking routine.  It also sounds like you missed some parts
>  of the upgrade.
> 
>  -kevin
> 
>  >On Mon, 2011-06-06 at 09:29 -0400, Joshua Knarr wrote:
>  >
>  >  I am upgrading from RT 3.4.5 to RT 4.
>  >
>  >  I read the docs and stopped at 3.8, did the schema stuff, and then 
> continued to 4 per the
>  >  instructions for upgrading mysql also.
>  >
>  >  On the new system it runs for a few hours just fine, but then 
> suddenly everyones account
>  >  gets locked.
>  >
>  >  I restarted the services, I checked my configs, I'm coming up empty. 
> What went wrong or
>  >  where should I be looking?
> 
>--
>Joshua Knarr
>Systems Engineer
>GSI Commerce, Inc.  [2]http://www.gsicommerce.com
>E-Mail: [3]kna...@gsicommerce.com
>Office: 610-491-7110
>Mobile: 484-636-7371
> 
>The information contained in this electronic mail transmission is intended 
> only for the use of
>the individual or entity named in this transmission. If you are not the 
> intended recipient of
>this transmission, you are hereby notified that any disclosure, copying or 
> distribution of the
>contents of this transmission is strictly prohibited and that you should 
> delete the contents
>of this transmission from your system immediately. Any comments or 
> statements contained in
>this transmission do not necessarily reflect the views or position of GSI 
> Commerce, Inc. or
>its subsidiaries and/or affiliates.
> 
> References
> 
>Visible links
>1. 
> http://lists.bestpractical.com/pipermail/rt-announce/2011-January/000185.html
>2. http://www.gsicommerce.com/
>3. mailto:hell...@gsicommerce.com


pgpF5uFI5SfM5.pgp
Description: PGP signature


Re: [rt-users] RT-External Auth & RT 4.0

2011-06-07 Thread Kevin Falcone
On Tue, Jun 07, 2011 at 11:22:04AM +0100, Guy Baxter wrote:
> AD users log in, but then do not show up in the users section so I can't
> assign them permissions.
> OD users fail to log in with "Your username or password is incorrect" 

They default to Unprivileged - search for them using the admin UI.

> The message in the log is: [Tue Jun  7 10:09:10 2011] [error]: Couldn't
> create user Staffuser: Name in use
> (/opt/rt4/local/plugins/RT-Authen-ExternalAuth/lib/RT/Authen/ExternalAuth.pm:129)
> 
> The name is not in use however - anyone got any ideas?

How are you checking that it isn't in use, have you searched for them
or are you just looking at the list of Privileged users?

-kevin


pgpL1jvs0L0JS.pgp
Description: PGP signature


Re: [rt-users] Blacklist and Bugzilla

2011-06-07 Thread Kevin Falcone
On Tue, Jun 07, 2011 at 03:19:53PM +0100, Keith Edmunds wrote:
> Some slight progress. We were seeing:
> 
>   "The incoming message was autogenerated. Not redistributing this
>   message to unprivileged users based on site configuration."

You should probably include a full log, rather than cherry picked
parts of it.

That implies that something has an RT-DetectedAutoGenerated header.
Is bugzilla-internal a ticket watcher that is reinjecting mail to RT?

You're not providing full information, which makes debugging this
really hard.

-kevin

> Adding:
> 
>   Set($RedistributeAutoGeneratedMessages, 1);
> 
> ...has removed that message; however, we still get:
> 
>   bugzilla-internal@[redacted] was blacklisted for outbound mail
>   on this transaction. Skipping
> 
> Please: how can I tell RT not to blacklist this address?


pgpiiwyRnvUYK.pgp
Description: PGP signature


Re: [rt-users] RT 4 - install on Debian Squeeze

2011-06-07 Thread Bart
Hi,

After redoing the installation steps the "cpan" part became quite a bit
bigger lol I never imagined that I did that much but heres a list of all the
manual installations that I've made using cpan.

I also forgot to make a link for apache from sites-available to
sites-enabled, but I hope most of you know that part already.

Anyways, here's the part that you do just after ./configure.

First install a few extra packages: (needed for the GD perl module)
>

>
aptitude install libgd2-xpm libgd2-xpm-dev
>

>
Now first run cpan in order to configure it:
>

> cpan
>
> Do the automatic thingy, after that you'll have to edit the cpan config in
> order to make the next part a hell of allot easyer:
>
> nano -w /etc/perl/CPAN/Config.pm
>
> Inside the config there are two "ask" parameters, remove the ask part and
> make sure it only contains "yes".
> I'm doing this because the following steps are going to install allot of
> perl modules and hitting return every minute or so is just too annoying.
>
> Then, check what dependencies your missing, this is CPAN based:
>
> make testdeps
>
> Make sure this var is set, make fixdeps won't work without it:
>
> RT_FIX_DEPS_CMD='/usr/bin/perl -MCPAN -e"install %s"'
> export RT_FIX_DEPS_CMD
>
> Now install all the depencencies by using the fixdeps parameter, this runs
> via CPAN:
>
> make fixdeps
>
> * The fixdeps part will take a while and you might have to run it several
> times. (sometimes you still have to hit yes or enter)
>
> To finalize fixdeps you'll have to install allot of stuff manually, below
> is a list of the things I've installed that made me pass the testdeps:
>
> cpan YAML
> cpan CPAN::Shell
> cpan YAML::Syck
> cpan GD
> cpan CPAN::DistnameInfo
>
> make fixdeps
>
> cpan Class::Data::Inheritable
> cpan Exception::Class
> cpan Log::Any
> cpan Test::Tester
> cpan Test::NoWarnings
> cpan Test::Deep
> cpan HTTP::Body
> cpan Devel::StackTrace::AsHTML
> cpan Test::SharedFork
> cpan Filesys::Notify::Simple
> cpan Test::Requires
> cpan Try::Tiny
> cpan Hash::MultiValue
> cpan Test::TCP
> cpan Class::Inspector
> cpan File::ShareDir
> cpan Plack
>
> make fixdeps
>
> cpan Class::Accessor::Chained
> cpan Text::vFile::asData
> cpan Tree::DAG_Node
> cpan Sub::Uplevel
> cpan Test::Warn
> cpan Test::LongString
> cpan Data::ICal
>
> make fixdeps
>
> cpan List::UtilsBy
> cpan Convert::Color
> cpan Mouse
> cpan Any::Moose
> cpan GnuPG::Interface
>
> make fixdeps
>
> cpan Digest::SHA1
> cpan Error
> cpan Cache::Cache
> cpan Module::Metadata
> cpan JSON::PP
> cpan Version::Requirements
> cpan CPAN::Meta::YAML
> cpan Perl::OSType
> cpan Parse::CPAN::Meta
> cpan CPAN::Meta
> cpan Module::Build
> cpan Params::Validate
> cpan Class::Container
> cpan HTML::Mason
> cpan HTML::Mason::PSGIHandler
>
> make fixdeps
>
> cpan Proc::Wait3
> cpan Scope::Guard
> cpan Server::Starter
> cpan Class::Accessor::Lite
> cpan Parallel::Prefork
> cpan Plack::Handler::Starlet
>
> make fixdeps
>
> cpan Class::Singleton
> cpan Test::Fatal
> cpan Class::Load
> cpan DateTime::TimeZone
> cpan Test::Exception
> cpan Math::Round
> cpan DateTime
>
> make fixdeps
>
> cpan Params::Util
> cpan Sub::Install
> cpan Data::OptList
> cpan Sub::Exporter
> cpan Devel::GlobalDestruction
>
> make fixdeps
>
> cpan Text::Reform
> cpan Text::Autoformat
> cpan Text::Quoted
>
> make fixdeps
>
> cpan FreezeThaw
> cpan DBIx::DBSchema
> cpan Want
> cpan DBD::SQLite
> cpan Clone
> cpan capitalization
> cpan DBIx::SearchBuilder
> cpan DateTime::Format::W3CDTF
> cpan Test::Manifest
> cpan DateTime::Format::Mail
> cpan XML::Parser
> cpan XML::RSS
>
> make fixdeps
>

> Before going further run "make testdeps" to check if all dependencies are
> met.
>

After this you continue with make install and such. (assuming all
dependencies have been met).

It's quite a bit of work but luckily you'll only have to struggle with this
once (I hope)

Best regards,

Bart



2011/6/6 Bart 

> Hi,
>
> This topic might have been closed but I just want to reply with my Debian
> Squeeze installation steps.
>
> The steps are basically describing the installation from scratch while
> installing RT4 manually. The advantage here is that you can follow the RT
> releases instead of waiting for the Debian specific packages. (personally I
> think that's ok)
>
> * BEGIN INSTALLATION STEPS
> *
>
> Clean installation of Debian Squeeze, this means:
>
>- Only install the base system (nothing else)
>- Make sure that things like networking work (DNS, IP, etc.)
>
> After installation install the following basics:
>
> aptitude 

Re: [rt-users] Blacklist and Bugzilla

2011-06-07 Thread Keith Edmunds
Some slight progress. We were seeing:

"The incoming message was autogenerated. Not redistributing this
message to unprivileged users based on site configuration."

Adding:

Set($RedistributeAutoGeneratedMessages, 1);

...has removed that message; however, we still get:

bugzilla-internal@[redacted] was blacklisted for outbound mail
on this transaction. Skipping

Please: how can I tell RT not to blacklist this address?

Thanks,
Keith
-- 
"You can have everything in life you want if you help enough other people
get what they want" - Zig Ziglar. 

Who did you help today?


Re: [rt-users] RT4 upgrade woes - user accounts lock?

2011-06-07 Thread Joshua Knarr
Kevin,

We seriously do not have any extensions, either on the old host or the
new host. We would like to be able to use LDAP at some point but it
isn't looking good for keeping confluence overall.

I wiped the new box and I wiped the database host and redid the entire
process from the get go - we're still experiencing the same problem.

It looks like RT is having problems matching the SHA hashes, but I'm
really not sure what's going on. I know in users.pm we convert the
password the first time the user logs in from MD5 to SHA, but then it
seems to fail all the new SHA matches. WTF?

On Mon, 2011-06-06 at 10:57 -0400, Kevin Falcone wrote:

> On Mon, Jun 06, 2011 at 10:44:46AM -0400, Joshua Knarr wrote:
> >I just tracked this down to the password changing in the database...
> > 
> >If I try to log in after upgrading - it works for awhile then stops 
> > working. The question is
> >why?
> > 
> >The workaround:
> >UPDATE Users SET Password=md5('password') WHERE Name='knarrj';
> > 
> >This isn't good. I would vastly prefer to not have to run the upgrade 
> > again and I would really
> >like to use the old passwords. Is there a workaround? What changed?
> 
> What changed was 
> http://lists.bestpractical.com/pipermail/rt-announce/2011-January/000185.html
> 
> It is also documented in docs/UPGRADING-3.8
> 
> It sounds like you have an extension somewhere that clobbers the new
> password checking routine.  It also sounds like you missed some parts
> of the upgrade.
> 
> -kevin
> 
> >On Mon, 2011-06-06 at 09:29 -0400, Joshua Knarr wrote:
> > 
> >  I am upgrading from RT 3.4.5 to RT 4.
> > 
> >  I read the docs and stopped at 3.8, did the schema stuff, and then 
> > continued to 4 per the
> >  instructions for upgrading mysql also.
> > 
> >  On the new system it runs for a few hours just fine, but then suddenly 
> > everyones account
> >  gets locked.
> > 
> >  I restarted the services, I checked my configs, I'm coming up empty. 
> > What went wrong or
> >  where should I be looking?


-- 
Joshua Knarr
Systems Engineer
GSI Commerce, Inc.  http://www.gsicommerce.com
E-Mail: kna...@gsicommerce.com
Office: 610-491-7110
Mobile: 484-636-7371

The information contained in this electronic mail transmission is
intended only for the use of the individual or entity named in this
transmission. If you are not the intended recipient of this
transmission, you are hereby notified that any disclosure, copying or
distribution of the contents of this transmission is strictly prohibited
and that you should delete the contents of this transmission from your
system immediately. Any comments or statements contained in this
transmission do not necessarily reflect the views or position of GSI
Commerce, Inc. or its subsidiaries and/or affiliates.


Re: [rt-users] RT 3.6.7 Default Templates

2011-06-07 Thread Barnes, Andrew (barnesaw)

On 6/6/11 9:28 PM, "Metz, Bobby" 
mailto:bobby.m...@globalcrossing.com>> wrote:

Hey all,
I’m attempting to help our new RT admin figure out some oddities with 
an existing install.  Some of his global templates, the default RT ones, were 
wiped and thus far I can’t seem to find their contents documented anywhere 
on-line.  Having downloaded the 3.6.7 tarball I also don’t see any promising 
files or at least not any files with the syntax I’m expecting.  I see several 
posts on-line from people seeking similar info but no answers.  I’m hoping 
someone here can point us in the right direction, without suggesting a 
re-install.  I’m expecting files with content similar to this:

Greetings,

You have just submitted a request to the { $Ticket->QueueObj->Name } ticket 
queue.

Ticket Details
--

  Ticket Num: { $Ticket->Id }
   Queue: { $Ticket->QueueObj->Name }
 Subject: { $Ticket->Subject }
   Owner: { $Ticket->OwnerObj->Name }
  Status: { $Ticket->Status }
  Requestors: { $Transaction->CreatorObj->Name . ' <' . 
$Transaction->CreatorObj->EmailAddress . '>' }
  Status: { $Ticket->Status }

Request Details
--

{ $Transaction->Content }

Or are they not stored in this format anywhere like this?


Unpack the tarball and check etc/initialdata.  Specifically the @Templates 
section.

--
Drew Barnes
Applications Analyst
Network Resources Dept.
Raymond Walters College


Re: [rt-users] "ShowTicket" for Groups that a requestor belongs to

2011-06-07 Thread Michael Polenske
Hi Gerard,

 

very good hint, I found that there is already a solution.

 

http://requesttracker.wikia.com/wiki/AddSquelchedCc
 

 

I have now to make the scrip work with my installation, currently it
seems not to work, but I will dig into it.

 

By the way - is there a debug-possibility for scrips ? 

 

 

 

Many many thanks !!

 

Cheers - Michael

 

 

 

From: rt-users-boun...@lists.bestpractical.com
[mailto:rt-users-boun...@lists.bestpractical.com] On Behalf Of Gerard
FENELON
Sent: Montag, 6. Juni 2011 16:06
To: rt-users@lists.bestpractical.com
Subject: Re: [rt-users] "ShowTicket" for Groups that a requestor belongs
to

 

Hi

I would create a group for each company
then I would wite a scrip to add a Group as Cc to the ticket at creation
time 
depending on some characteristics of the Requestor.
For example, if the Organization of the Requestor is "Yoyodine" 
then add group "Yoyodine".
Finally give the appropriate rights to the Cc group.

Gerard

On 2011-06-06 15:04, Michael Polenske wrote: 

Hi Kenneth,

 

thanks for your hint. Unfortunately this will not cover my problem.
Maybe I should explain it a little bit more:

 

we have a queue called support

~20 companies are able to submit tickets to this queue

All companies have 2-3 employees who can submit tickets for their
company

Currently every company has only _one_ user to login into RT to submit
tickets for their company

Every company can only see their submitted tickets (CreateTicket and
SeeQueue or Privileged Users, ShowTicket for Requestor)

 

Now we got request that every employee for every company should have
their own account to RT to submit ticket (to clarify who in the
customers company is owner of the ticket). Now problem at all, but now
every user of one company should see all tickets of the other users of
their company, just in case that someone is on vacation etc. 

 

If I follow your solution (open a group, move the employees in this
group and give ShowTicket to this group) they can see ALL tickets - not
only the tickets for their group. Maybe a solution like "Requestor
Group" will cover my problem - I have no idea who to establish something
like that 

 

Hope this clarifies my problem a little bit more J

 

Thanks a lot and best regards,

Michael

 

 

From: rt-users-boun...@lists.bestpractical.com
[mailto:rt-users-boun...@lists.bestpractical.com] On Behalf Of Kenneth
Crocker
Sent: Freitag, 3. Juni 2011 19:07
To: rt-users@lists.bestpractical.com
Subject: Re: [rt-users] "ShowTicket" for Groups that a requestor belongs
to

 

Michael,

Create a User-defined Group, put those individuals that need those
rights to the Queue into that group, then go to Config->Queues(select
the Queue)->Group rights and find that group and give the the rights
they need. That way, the Global rights you gave to Requestors remains,
but for that particular Queue, any member of this new group will have
the rights you granted.

Kenn
LBNL

On Fri, Jun 3, 2011 at 7:26 AM, Michael Polenske
 wrote:

Hi there,

 

I work now for years with RT, but before as user not as admin J Now our
admin left and I have to takeover some tasks. 

 

One of the urgent one's I am not able to fix, maybe you can help.

 

Situation:

 

One Support-Queue, some users can submit tickets to and can see only
their tickets (ShowTicket only for group requestor). But now we have to
change it that way, that some user can belong to a group, and this group
needs to see all tickets submitted by members of this group - nothing
more, nothing less.

 

Any idea how to handle this ?

 

Thanks a lot and have a nice weekend - Michael

 



[rt-users] RT-External Auth & RT 4.0

2011-06-07 Thread Guy Baxter
Hi,

I've replicated our production setup and upgraded it to 4.0 without a
problem. I've now thrown External Auth into the mix (new install via
cpan), and I'm having mixed results.

We have 2 directory systems - Open Directory (openldap) and Active
Directory

AD authenticates fine, but OD just will not authenticate at all.

Here's my RT_SiteConfig.pm

Set($rtname, 'ourdomain');
Set($Organization , "ourdomain");
Set($WebPort, 80);# + ($< * 7274) % 32766 + ($< && 1024));
Set($WebDomain, 'rt2.ourdomain' );
my $port = RT->Config->Get('WebPort');
Set($WebBaseURL,
($port == 443? 'https': 'http') .'://'
. RT->Config->Get('WebDomain')
. ($port != 80 && $port != 443? ":$port" : '')
);
Set($MaxAttachmentSize , 1000);
Set($MailCommand , 'sendmail');
Set($SendmailArguments , "-oi -t");
Set($CorrespondAddress , 'Request_Tracker');
Set($CommentAddress , 'Request_Tracker_Comment');
Set($HomePageRefreshInterval, 60);
Set(@Plugins,qw(RT::Authen::ExternalAuth));
Set($ExternalAuthPriority,  [   'My_AD',
'My_OD'
]
);
Set($ExternalInfoPriority,  [   'My_AD',
'My_OD'
]
);
Set($ExternalServiceUsesSSLorTLS,0);
Set($AutoCreateNonExternalUsers,0);
Set($ExternalSettings,  {
'My_OD'   =>  {   ## ODMaster
# The type of
service (db/ldap/cookie) 
'type'
 =>  'ldap',
# The server
hosting the service
'server'  
 =>  'osxmaster.b6fc.ac.uk',
# The LDAP search
base
'base'
 => 'cn=users,dc=osxmaster,dc=b6fc,dc=ac,dc=uk',
#
# ALL FILTERS MUST
BE VALID LDAP FILTERS ENCASED IN PARENTHESES!
# YOU **MUST**
SPECIFY A filter AND A d_filter!!
#
# The filter to
use to match RT-Users
'filter'  
 =>  '(description=staff)',
# A catch-all
example filter: '(objectClass=*)'
#
# The filter that
will only match disabled users
'd_filter'
 =>  '(description=parent)',
# A catch-none
example d_filter: '(objectClass=FooBarBaz)'
#
# Should we try to
use TLS to encrypt connections?
#'tls'
  =>  0,
# SSL Version to
provide to Net::SSLeay *if* using SSL
#'ssl_version'
  =>  3,
# What other args
should I pass to Net::LDAP->new($host,@args)?
#'net_ldap_args'  
  => [version =>  3   ],
# Does
authentication depend on group membership? What group name?
#'group'  
  =>  'GROUP_NAME',
# What is the
attribute for the group object that determines membership?
#'group_attr' 
  =>  'GROUP_ATTR',
## RT ATTRIBUTE
MATCHING SECTION
# The list of RT
attributes that uniquely identify a user
# This example shows 
what you *can* specify.. I recommend reducing
this
# to just the Name
and EmailAddress to save encountering problems later.
'attr_match_list' 
 => ['Name',
  
 'EmailAddress', 
  
 
  
 ],
  

Re: [rt-users] Pg to mysql : attachements not viewable

2011-06-07 Thread Kristian Davies
On Mon, Jun 6, 2011 at 3:49 PM, Kevin Falcone  wrote:
>> Just in case it's something to do with database encoding, I used
>> rt-3.8.2/etc/schema.mysql to create the database (and
>> rt3-on-pg-to-mysql script from the wiki?? to import from pg).
>
> That's the wrong schema, you wanted schema.mysql-4.1
> Any new attachments are likely to have corruption.
>
> I know nothing about the script you're using, but you have to convert
> out of the base64 storage used on Pg to binary storage on mysql.
> Your content-type headers imply that you didn't do that.

Performed a backup (data only), dropped database, created schema.mysql-4.1
schema and used suggestions in upgrade-mysql-schema.pl,
imported data.

I only lost 5 attachments, which I've requested be uploaded again, phew.

Thanks,
Kristian


[rt-users] Attachment names in Russian are truncated

2011-06-07 Thread Arseny Rubanovich

Hi all!

When i send message to RT 4.0 the name of attached file in Russian 
language is truncated (e.g. Письмо;). Origin name of attachment is 
"Письмо для меня.doc". In previous version of RT i used (3.8.9) there 
was not such kind of problem.
This problem occurs not always. For example when i send message with 
attachment from Yahoo RT saves attachment name correctly.

How i can troubleshoot this problem?

Thank you

Ars


Re: [rt-users] How can I tackle CC emails and Exchange distribution list

2011-06-07 Thread Rithy R

Thanks. I will try ParseNewMessageForTicketCcs and double check my mail server 
config.

Regards,Rithy




> Date: Mon, 6 Jun 2011 10:38:58 -0400
> From: falc...@bestpractical.com
> To: rt-users@lists.bestpractical.com
> Subject: Re: [rt-users] How can I tackle CC emails and Exchange distribution 
> list
> 
> On Mon, Jun 06, 2011 at 01:51:31AM +, Rithy R wrote:
> >1.   When requester send email to RT mailbox they CC a lot of people 
> > (10 email addresses
> >or more). Those addresses did not include in CC list when we reply that 
> > ticket. Is there
> >anyway we can automate that?
> 
> Read about ParseNewMessageForTicketCcs in RT_Config.pm
> 
> >2.   When I CC a distribution list in the same email server as RT 
> > mailbox it won*t send.
> >It can send to other user without any issue.
> 
> Sounds like a mail misconfiguration, but you haven't provided enough
> details.  RT doesn't know the difference between a distribution list
> and a normal email
> 
> -kevin