Hello,
Just checking on the status of RTIR support for RT 4.x? I see that
RTIR-3.0.0rc1 was made available back in October but nothing since
then.
Later,
Darin
Also interested.
I did install RT-IR 3.0.0 rc1 just last week and it appears to be working fine.
Robert Floodeen
Member-Technical Staff
CERT Resilient Enterprise Management Team
Carnegie Mellon Software Engineering Institute
The CERT Division | Software Engineering Institute Message-----
From: rtir-bounces@lists.bestpractical.com [mailto:rtir-bounces@lists.bestpractical.com] On Behalf Of Darin Perusich
Sent: Monday, January 30, 2012 12:58 PM
To: rtir@lists.bestpractical.com
Subject: [Rtir] RT 4.x status
Hello,
Just checking on the status of RTIR support for RT 4.x? I see that
RTIR-3.0.0rc1 was made available back in October but nothing since then.
Later,
Darin
Rtir mailing list
Rtir@lists.bestpractical.com
http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rtir
Just checking on the status of RTIR support for RT 4.x? I see that
RTIR-3.0.0rc1 was made available back in October but nothing since
then.
Do you have any feedback on the RC? We know there is more work to be
done, but so far haven’t received any feedback from folks who will be
upgrading which concerns us.
-kevin
-IR 3.0.0 rc1 just last week and it appears to be working fine.
Why don’t you report this? Is it new install or upgrade?
Best regards, Ruslan.
Hello,
Just checking on the status of RTIR support for RT 4.x? I see that
RTIR-3.0.0rc1 was made available back in October but nothing since
then.
Code for upgrade is quite complicated (operations include mass deletes
and updates) and we want to see feedback where people report about
successful upgrade in testing environment at least.
People don’t report about success or failures, so we delay release.
–
Later,
Darin
Rtir mailing list
Rtir@lists.bestpractical.com
The rtir Archives
Best regards, Ruslan.
Ruslan,
It is new install. I did it from source. Longest part was perl module updates. Everything else worked just fine. I did it in VM to have clean VM for future use.
Do you have a large set of test data? If so, I would gladly upload it into the MySQL DB and give it a test.
Is there a standard testing document? If so, I will go through that as well.
-Regards,
Robert Floodeen
Member-Technical Staff
CERT Resilient Enterprise Management Team
Carnegie Mellon Software Engineering Institute
The CERT Division | Software Engineering Institute Message-----
From: ruslan.zakirov@gmail.com [mailto:ruslan.zakirov@gmail.com] On Behalf Of Ruslan Zakirov
Sent: Monday, January 30, 2012 1:23 PM
To: Robert Floodeen
Cc: rtir@lists.bestpractical.com
Subject: Re: [Rtir] RT 4.x status
On Mon, Jan 30, 2012 at 22:01, Robert Floodeen floodeen@cert.org wrote:
-IR 3.0.0 rc1 just last week and it appears to be working fine.
Why don’t you report this? Is it new install or upgrade?
Best regards, Ruslan.
Ruslan,
It is new install. I did it from source. Longest part was perl module updates. Everything else worked just fine. I did it in VM to have clean VM for future use.
Do you have a large set of test data? If so, I would gladly upload it into the MySQL DB and give it a test.
Synthetic data wouldn’t help much. I’m more interested in real
instances upgrades.
Is there a standard testing document? If so, I will go through that as well.
Use your new RTIR installation and report any problems.
If there wouldn’t be any problems reported then we will just release
3.0.0rc1 as 3.0.0 without new changes.
-Regards,
Robert Floodeen
Member-Technical Staff
CERT Resilient Enterprise Management Team
Carnegie Mellon Software Engineering Institute
Enterprise Risk and Resilience Management | Software Engineering Institute-----Original Message-----
From: ruslan.zakirov@gmail.com [mailto:ruslan.zakirov@gmail.com] On Behalf Of Ruslan Zakirov
Sent: Monday, January 30, 2012 1:23 PM
To: Robert Floodeen
Cc: rtir@lists.bestpractical.com
Subject: Re: [Rtir] RT 4.x status
-IR 3.0.0 rc1 just last week and it appears to be working fine.
Why don’t you report this? Is it new install or upgrade?
–
Best regards, Ruslan.
Rtir mailing list
Rtir@lists.bestpractical.com
The rtir Archives
Best regards, Ruslan.
Hello,
tried an upgrade to RT 4.0.5 and RTIR 3.0.0 RC1 on a test system.
Starting position: installed up and running (on Ubuntu, add a 'sudo’
before all commands)
RT 3.8.10
RTIR 2.6.1
RTFM 2.4.3
(with a rather small DB, only few incidents, nothing complicated).
Location /opt/rt3/
- Upgrade to RT 4.0.5
worked well as described in the README, via ‘make fixdeps’ and ‘make
upgrade’
Installation into a new folder /opt/rt4/
- Database configuration
started the standalone server, configured a few things. initialisation
worked fine.
Stopped the standalone server
- Here’s where it stops me right now: Database upgrade
make upgrade-database
— SCREEN-OUTPUT
ubuntu@rt4:~/install/rt-4.0.5$ sudo make upgrade-database
/usr/bin/perl -I/opt/rt4/local/lib -I/opt/rt4/lib sbin/rt-setup-database
–action upgrade --prompt-for-dba-password
In order to create or update your RT database, this script needs to
connect to your mysql instance on localhost as root
Please specify that user’s database password below. If the user has no
database
password, just press return.
Password:
Working with:
Type: mysql
Host: localhost
Name: rt4
User: rt_user
DBA: root
Enter RT version you’re upgrading from: 3.8.10
Going to apply following upgrades:
- 3.9.1
- 3.9.2
- 3.9.3
- 3.9.5
- 3.9.6
- 3.9.7
- 3.9.8
- 4.0.0rc2
- 4.0.0rc4
- 4.0.0rc7
- 4.0.1
- 4.0.3
- 4.0.4
Enter RT version if you want to stop upgrade at some point,
or leave it blank if you want apply above upgrades:
IT’S VERY IMPORTANT TO BACK UP BEFORE THIS STEP
Proceed [y/N]: y
Processing 3.9.1
Now inserting data.
Processing 3.9.2
Now inserting data.
[Tue Mar 13 17:06:47 2012] [warning]: DBD::mysql::st execute failed:
Unknown column ‘main.DelegatedBy’ in ‘where clause’ at
/usr/local/share/perl/5.10.1/DBIx/SearchBuilder/Handle.pm line 587, <>
line 1. (/usr/local/share/perl/5.10.1/DBIx/SearchBuilder/Handle.pm:587)
[Tue Mar 13 17:06:47 2012] [warning]: RT::Handle=HASH(0x4aa1638)
couldn’t execute the query ‘SELECT main.* FROM ACL main WHERE
(main.DelegatedBy > ‘0’) AND (main.DelegatedFrom > ‘0’) ’ at
/usr/local/share/perl/5.10.1/DBIx/SearchBuilder/Handle.pm line 600
DBIx::SearchBuilder::Handle::SimpleQuery(‘RT::Handle=HASH(0x4aa1638)’,
‘SELECT main.* FROM ACL main WHERE (main.DelegatedBy > ‘0’)…’)
called at /usr/local/share/perl/5.10.1/DBIx/SearchBuilder.pm line 235
DBIx::SearchBuilder::_DoSearch(‘RT::ACL=HASH(0x6870250)’) called at
/home/ubuntu/install/rt-4.0.5/sbin/…/lib/RT/SearchBuilder.pm line 320
RT::SearchBuilder::_DoSearch(‘RT::ACL=HASH(0x6870250)’) called at
/home/ubuntu/install/rt-4.0.5/sbin/…/lib/RT/ACL.pm line 260
RT::ACL::_DoSearch(‘RT::ACL=HASH(0x6870250)’) called at
/usr/local/share/perl/5.10.1/DBIx/SearchBuilder.pm line 503
DBIx::SearchBuilder::Next(‘RT::ACL=HASH(0x6870250)’) called at
/home/ubuntu/install/rt-4.0.5/sbin/…/lib/RT/ACL.pm line 225
RT::ACL::Next(‘RT::ACL=HASH(0x6870250)’) called at
./etc/upgrade/3.9.2/content line 19
RT::Handle::ANON() called at
/home/ubuntu/install/rt-4.0.5/sbin/…/lib/RT/Handle.pm line 767
eval {…} called at
/home/ubuntu/install/rt-4.0.5/sbin/…/lib/RT/Handle.pm line 767
RT::Handle::InsertData(‘RT::Handle=HASH(0x4aa1638)’,
’./etc/upgrade/3.9.2/content’, undef) called at sbin/rt-setup-database
line 293
main::action_insert(‘prompt-for-dba-password’, 1, ‘datafile’, undef,
‘action’, ‘upgrade’, ‘datadir’, ‘./etc/upgrade/3.9.2’, ‘backcompat’,
…) called at sbin/rt-setup-database line 399
main::action_upgrade(‘prompt-for-dba-password’, 1, ‘action’, ‘upgrade’,
‘dba’, ‘root’) called at sbin/rt-setup-database line 198
(/usr/share/perl/5.10/Carp.pm:47)
[Tue Mar 13 17:06:47 2012] [crit]: _DoSearch is not so successful as it
still needs redo search, won’t call _BuildHash
(/home/ubuntu/install/rt-4.0.5/sbin/…/lib/RT/ACL.pm:263)
Processing 3.9.3
Now populating database schema.
[Tue Mar 13 17:06:47 2012] [crit]: DBD::mysql::st execute failed: Can’t
DROP ‘DelegatedBy’; check that column/key exists at
/home/ubuntu/install/rt-4.0.5/sbin/…/lib/RT/Handle.pm line 517.
(/home/ubuntu/install/rt-4.0.5/sbin/…/lib/RT.pm:341)
DBD::mysql::st execute failed: Can’t DROP ‘DelegatedBy’; check that
column/key exists at
/home/ubuntu/install/rt-4.0.5/sbin/…/lib/RT/Handle.pm line 517.
make: *** [upgrade-database] Error 255
— SCREEN-OUTPUT
Any hint appreciated!
(Obviously i did not yet start to apply RTIR 3.0.0 RC1.)
Many thanks!
Best regards,
Marco
BTW: In my frustration i did a new install of RT 4.0.5 and RTIR 3.0.0
RC1. I did a “make initialise-database” and then imported a recent dump
from RT3.8.10/RTIR2.6.1 into the RT4 database (cat rt3-dump.sql | mysql
-u root -p rt4).
It seems to work for many things, but not for all (lookup of IP-adresses
only partial works for example.)
Enter RT version if you want to stop upgrade at some point,
or leave it blank if you want apply above upgrades:IT’S VERY IMPORTANT TO BACK UP BEFORE THIS STEP
Proceed [y/N]: y
Processing 3.9.1
Now inserting data.
Processing 3.9.2
Now inserting data.
[Tue Mar 13 17:06:47 2012] [warning]: DBD::mysql::st execute failed:
Unknown column ‘main.DelegatedBy’ in ‘where clause’ at
/usr/local/share/perl/5.10.1/DBIx/SearchBuilder/Handle.pm line 587, <>
line 1. (/usr/local/share/perl/5.10.1/DBIx/SearchBuilder/Handle.pm:587)
[Tue Mar 13 17:06:47 2012] [warning]: RT::Handle=HASH(0x4aa1638)
couldn’t execute the query 'SELECT main.* FROM ACL main WHERE
(main.DelegatedBy > ‘0’) AND (main.DelegatedFrom > ‘0’) ’ at
/usr/local/share/perl/5.10.1/DBIx/SearchBuilder/Handle.pm line 600
This implies that you ran the upgrade twice, or are running it against
a 4.0 schema. ACL.DelegatedBy exists in 3.8 and is removed in
etc/upgrade/3.9.3 etc/upgrade/3.9.2 relies on it being there to clean
out old data.
You should check the schema of the ACL table before you start your
upgrade (with a clean import of 3.8.10, be sure that EVERY table in
your rt4 database is gone before you import 3.8.10’s data).
BTW: In my frustration i did a new install of RT 4.0.5 and RTIR 3.0.0
RC1. I did a “make initialise-database” and then imported a recent dump
from RT3.8.10/RTIR2.6.1 into the RT4 database (cat rt3-dump.sql | mysql
-u root -p rt4).It seems to work for many things, but not for all (lookup of IP-adresses
only partial works for example.)
Copying in the data directly from 3.8 shouldn’t work. There are several
schema changes on the rt side.
-kevin
Hi,
thanks for the quick answer!
This implies that you ran the upgrade twice, or are running it against
a 4.0 schema. ACL.DelegatedBy exists in 3.8 and is removed in
etc/upgrade/3.9.3 etc/upgrade/3.9.2 relies on it being there to clean
out old data.You should check the schema of the ACL table before you start your
upgrade (with a clean import of 3.8.10, be sure that EVERY table in
your rt4 database is gone before you import 3.8.10’s data).
I’ll re-do it from scratch, and regard your hint. I’ll report afterwards.
Regards,
Marco
Hello again,
this time it went better. 
This is what i did:
-
import a recent dump of the RT3 database as RT4 (so there are
basically two copies of the same database, one is named rt3, the other
one is named rt4). -
did some adjustments to /opt/rt4/etc/RT_Siteconfig.pm:
Set($DatabaseType, ‘mysql’);
Set($DatabaseUser, ‘’);
Set($DatabasePassword, ‘’);
Set($DatabaseName, ‘rt4’);
(Use here the name of the database you want to convert, in my case rt4,
which is a 1:1 copy of rt3. The rt3 database will not be touched)
- sudo make upgrade-database
(went through smoothly)
- sudo /etc/upgrade/upgrade-articles
(for conversion of the RTFM articles). Worked fine.
For testing i started the standalone server; i could login with my
credentials from RT3 (as expected), and see all my tickets. I stopped
the standalone server.
Now i installed RTIR 3.0.0 RC1, by:
perl Makefile.PL
sudo make install
and added the @plugin part in RT_Siteconfig.
This went also well, and i have a working instance of RTIR 3.0.0,
upgraded from RTIR 2.6.1.
Now starting the standalone server, and i can login and again see all my
tickets, etc.
I ran into some problems; i will list them in the following email.
Cheers,
MarcoOn 14/03/12 08:54, Marco Thorbruegge wrote:
Hi,
thanks for the quick answer!
This implies that you ran the upgrade twice, or are running it against
a 4.0 schema. ACL.DelegatedBy exists in 3.8 and is removed in
etc/upgrade/3.9.3 etc/upgrade/3.9.2 relies on it being there to clean
out old data.You should check the schema of the ACL table before you start your
upgrade (with a clean import of 3.8.10, be sure that EVERY table in
your rt4 database is gone before you import 3.8.10’s data).I’ll re-do it from scratch, and regard your hint. I’ll report afterwards.
Regards,
Marco