Re: [rt-users] Post upgrade 3.8.5 to 4.0.12 Global->RT At A Glance error

2013-05-17 Thread Thomas Sibley 
On 05/17/2013 01:36 PM, Pete Beebe wrote:
 Can you run `diff -ruN` against the two install trees (the one
 you backed up and the one currently in use)?
> 
> Zip file is 190KB in size.  I will be sending it separate from this
> reply.  I cut out the session_data diff output to trim down the
> original log file (4MB).  If you prefer that this additional diff
> info be included I can simply send you the zipped 4MB log file.

The session data isn't necessary (and shouldn't be published publicly
either; sessions contain private data).

I filtered out irrelevant files (the new RT-Authen-ExternalAuth install,
Mason cache files, documentation files (man and pod)) from the diff you
sent, and it left no significant changes.

Frustratingly, I still can't reproduce the error locally on a handful of
long-lived RT instances all of which have been upgraded through 4.0.12.

Thomas


-- 
RT Training in Seattle, June 19-20: http://bestpractical.com/training

Re: [rt-users] Post upgrade 3.8.5 to 4.0.12 Global->RT At A Glance error

2013-05-17 Thread Pete Beebe 
Hi Thomas,

>>>Out of curiosity, how did you reinstate the user records?

On the original RT 3.8.5 server I had a couple of mysql dumps available with 
the previously deleted records still intact.  On the original server I copied 
one of the mysql backups to the RTDEV server, imported it into an empty MySQL 
rt database and then ran the upgrade to 4.0.12 followed by the migration to the 
Oracle schema.  I then extracted the specific deleted records from the RTDEV 
Oracle schema and inserted them into the RTPROD User table followed by 
re-generating the User table sequence.  If I was more savvy I probably could 
have just reconstructed the insert queries manually but the above method worked 
out well enough, just took a bit more time.

>>> The error was  still occurring after you'd reinstated them, but before you 
>>> reinstalled,  right?

This is correct.  I re-instated the deleted user records into RTPROD and the 
Global RT At A Glance error was still occurring.  It was only when I rebooted 
the RTPROD server and re-ran the base directory installation that the error 
cleared.  What I didn't do which I should have done was re-test after the 
RTPROD reboot and before running the new base directory installation.

>>> Can you run `diff -ruN` against the two install trees (the one you backed 
>>> up and the one currently in use)?

Zip file is 190KB in size.  I will be sending it separate from this reply.  I 
cut out the session_data diff output to trim down the original log file (4MB).  
If you prefer that this additional diff info be included I can simply send you 
the zipped 4MB log file.

~Pete_Jibe

Disclaimer: This electronic message may contain information that is 
Confidential or legally privileged. It is intended only for the use of the 
individual(s) and entity named in the message. If you are not an intended 
recipient of this message, please notify the sender immediately and delete the 
material from your computer. Do not deliver, distribute or copy this message 
and do not disclose its contents or take any action in reliance on the 
information it contains.


-- 
RT Training in Seattle, June 19-20: http://bestpractical.com/training

Re: [rt-users] Problems upgrading from 3.9.3

2013-05-17 Thread Ruslan Zakirov 
On Fri, May 17, 2013 at 8:04 PM, saxmad  wrote:

> Hmm, so is there a workaround/fix for this from either side, or is 9.2 not
> really supported fully ? I have had 9.2 running fine on a completely fresh
> install of RT 4.0.7. Would it better to go back to PG 9.1 to get this
> upgrade sorted ?
>
> Thanks for all the help so far ...
>
>
I've checked DBD::Pg's git repository. Problem is actually in that module
and you're lucky. It's been fixed in 2.19.3 (the latest from the CPAN), but
was not mentioned in the changelog. Upgrade the module and try again.

--
> View this message in context:
> http://requesttracker.8502.n7.nabble.com/Problems-upgrading-from-3-9-3-tp53543p53909.html
> Sent from the Request Tracker - User mailing list archive at Nabble.com.
>
>
> --
> RT Training in Seattle, June 19-20: http://bestpractical.com/training
>



-- 
Best regards, Ruslan.


-- 
RT Training in Seattle, June 19-20: http://bestpractical.com/training

Re: [rt-users] Notify Actor

2013-05-17 Thread Thomas Sibley 
On 05/17/2013 03:06 AM, Andrea gabellini - SC wrote:
> Thomas,
> 
> this queue is a low traffic queue, and users that use it aren't so
> familiar with RT, so they prefer to have all emails in their mailbox,
> also those they send.

Nod.  NotifyActor is also changeable a per-user preference (Logged in as
... -> Settings, look under the "Mail" section).

Perhaps it would be sufficient for those users to simply flip the
"Outgoing mail" preference to yes for themselves while leaving the
global $NotifyActor preference off.



-- 
RT Training in Seattle, June 19-20: http://bestpractical.com/training

Re: [rt-users] Post upgrade 3.8.5 to 4.0.12 Global->RT At A Glance error

2013-05-17 Thread Thomas Sibley 
On 05/17/2013 09:13 AM, Pete Beebe wrote:
> Hi Thomas,
> 
> Looks like the mail filter stopped this one from going through due to
> the attached log file.  Re-forwarding minus log file.

It was briefly stopped, yes, but I let it through manually.  There's a
size limit on posts at which point they require manual moderation.

> Also of note, yesterday evening I brought our RTPROD server offline
> for a reboot.  When the OS was back online I backed up the existing
> RTPROD installation directory and re-ran the configuration to
> re-create the install directory.  I then copied over our
> RT_SiteConfig file and custom log and started the web service back
> up.  I re-tested the Global At A Glance setting and found that the
> issue was no longer appearing.
> 
> Sonothing done on the database end (other than re-instating those
> user records).  For this particular problem it seems that me laying
> down a new install base somehow corrected the original issue.

Out of curiosity, how did you reinstate the user records?  The error was
still occurring after you'd reinstated them, but before you reinstalled,
right?

I'm surprised that a new install would correct the issue, but it is
possible.  Basically a component was returning an unexpected empty
value.  Can you run `diff -ruN` against the two install trees (the one
you backed up and the one currently in use)?  Alternatively, sent two
tarballs over and I can do it.

Thanks for continuing to dig at this and all the info you've provided.

Thomas


-- 
RT Training in Seattle, June 19-20: http://bestpractical.com/training

Re: [rt-users] Problems upgrading from 3.9.3

2013-05-17 Thread pavel . sidlo 



Few weeks ago I had exactly same issue during upgrade from 3.8.13 to
4.0.10.

Because I didn't find root cause of this issue I had to install PG 9.1
temporarily (on other virtual machine) then import DB from PG 9.2.x,
upgrade and then export back to 9.2.x.

Best regards,

Pavel


Pavel Šidlo

-
LinuxBox.cz, s.r.o.
28. října 168, 709 00 Ostrava

tel.:   +420 591 166 234
mob.:   +420 737 238 334
web:www.linuxbox.cz

mobil servis: +420 737 238 656
email servis: ser...@linuxbox.cz
-



|>
| Od:|
|>
  
>--|
  |saxmad   
 |
  
>--|
|>
| Komu:  |
|>
  
>--|
  |rt-users@lists.bestpractical.com,
 |
  
>--|
|>
| Datum: |
|>
  
>--|
  |05/17/2013 18:05 
 |
  
>--|
|>
| Předmět:   |
|>
  
>--|
  |Re: [rt-users] Problems upgrading from 3.9.3 
 |
  
>--|





Hmm, so is there a workaround/fix for this from either side, or is 9.2 not
really supported fully ? I have had 9.2 running fine on a completely fresh
install of RT 4.0.7. Would it better to go back to PG 9.1 to get this
upgrade sorted ?

Thanks for all the help so far ...




--
View this message in context:
http://requesttracker.8502.n7.nabble.com/Problems-upgrading-from-3-9-3-tp53543p53909.html

Sent from the Request Tracker - User mailing list archive at Nabble.com.


--
RT Training in Seattle, June 19-20: http://bestpractical.com/training

<><>

-- 
RT Training in Seattle, June 19-20: http://bestpractical.com/training

Re: [rt-users] Post upgrade 3.8.5 to 4.0.12 Global->RT At A Glance error

2013-05-17 Thread Pete Beebe 
Hi Thomas,

Looks like the mail filter stopped this one from going through due to the 
attached log file.  Re-forwarding minus log file.

Also of note, yesterday evening I brought our RTPROD server offline for a 
reboot.  When the OS was back online I backed up the existing RTPROD 
installation directory and re-ran the configuration to re-create the install 
directory.  I then copied over our RT_SiteConfig file and custom log and 
started the web service back up.  I re-tested the Global At A Glance setting 
and found that the issue was no longer appearing.

Sonothing done on the database end (other than re-instating those user 
records).  For this particular problem it seems that me laying down a new 
install base somehow corrected the original issue.

~Pete_Jibe

-Original Message-
From: Pete Beebe 
Sent: Thursday, May 16, 2013 10:55 AM
To: 'rt-users@lists.bestpractical.com'
Subject: RE: [rt-users] Post upgrade 3.8.5 to 4.0.12 Global->RT At A Glance 
error

Hi Thomas,

>>> Have you run rt-validator?

Log file attached.  All references are likely due to the deletion of old user 
records directly from mysql which we now know is not recommended.

>>>What are the output of the 3 SQL queries I sent you earlier on this  newly 
>>>upgraded dev instance?

All from the upgrade Oracle RT DEV instance:

select id, Name, Description, ObjectType, ObjectId from Attributes where 
ObjectType='RT::System';

137 Search - My Tickets [_1] highest priority tickets I own 
RT::System  1
138 Search - Unowned Tickets[_1] newest unowned tickets 
RT::System  1
139 HomepageSettingsHomepageSettingsRT::System  1
140 Search - My Tickets [_1] highest priority tickets I own 
RT::System  1
141 Search - Unowned Tickets[_1] newest unowned tickets 
RT::System  1
142 HomepageSettingsHomepageSettingsRT::System  1
153 Search - My Tickets [_1] highest priority tickets I own 
RT::System  1
154 Search - Unowned Tickets[_1] newest unowned tickets 
RT::System  1
155 HomepageSettingsHomepageSettingsRT::System  1
300 Search - Bookmarked Tickets Bookmarked Tickets  RT::System  
1
318 BrandedSubjectTag   Queue id => subject tag map RT::System  
1
3021SavedSearch 10 highest priority tickets I own   RT::System  
1
3842QueueCacheNeedsUpdate   0   RT::System  1

select id, Name, Created, LastUpdated from Users where Name in ('RT_System', 
'Nobody', 'root');

10  Nobody  06-SEP-05   06-SEP-05
1   RT_System   06-SEP-05   06-SEP-05
12  root06-SEP-05   15-MAY-13

select id, Domain, Type, Created, LastUpdated from Groups where Type in 
('Everyone', 'Privileged', 'Unprivileged');

3   SystemInternal  Everyone
4   SystemInternal  Privileged  
5   SystemInternal  Unprivileged

As a note, the duplicate "Search - Unowned Tickets" duplicates are likely a 
remnant of trying to fix a link issue in the previous 3.8.5 instance.  Relevant 
thread here: http://www.gossamer-threads.com/lists/rt/users/58712   It's a side 
issue that was never satisfactorily resolved and would be preferable to clean 
out the duplicates.

Here's the same SQL queries output from the original MySQL 3.8.5 database:

mysql> select id, Name, Description, ObjectType, ObjectId from Attributes where 
ObjectType='RT::System';
+--+-+-++--+
| id   | Name| Description | 
ObjectType | ObjectId |
+--+-+-++--+
|  137 | Search - My Tickets | [_1] highest priority tickets I own | 
RT::System |1 |
|  138 | Search - Unowned Tickets| [_1] newest unowned tickets | 
RT::System |1 |
|  139 | HomepageSettings| HomepageSettings| 
RT::System |1 |
|  140 | Search - My Tickets | [_1] highest priority tickets I own | 
RT::System |1 |
|  141 | Search - Unowned Tickets| [_1] newest unowned tickets | 
RT::System |1 |
|  142 | HomepageSettings| HomepageSettings| 
RT::System |1 |
|  153 | Search - My Tickets | [_1] highest priority tickets I own | 
RT::System |1 |
|  154 | Search - Unowned Tickets| [_1] newest unowned tickets | 
RT::System |1 |
|  155 | HomepageSettings| HomepageSettings| 
RT::System |1 |
|  300 | Search - Bookmarked Tickets | Bookmarked Tickets  | 
RT::System |1 |
|  318 | BrandedSubjectTag   | Queue id => subject tag map | 
RT::System |1 |
| 3021 | SavedSearch | 10 highest priority tic

Re: [rt-users] Problems upgrading from 3.9.3

2013-05-17 Thread saxmad 
Hmm, so is there a workaround/fix for this from either side, or is 9.2 not
really supported fully ? I have had 9.2 running fine on a completely fresh
install of RT 4.0.7. Would it better to go back to PG 9.1 to get this
upgrade sorted ?

Thanks for all the help so far ...




--
View this message in context: 
http://requesttracker.8502.n7.nabble.com/Problems-upgrading-from-3-9-3-tp53543p53909.html
Sent from the Request Tracker - User mailing list archive at Nabble.com.


-- 
RT Training in Seattle, June 19-20: http://bestpractical.com/training

Re: [rt-users] Problems upgrading from 3.9.3

2013-05-17 Thread Ruslan Zakirov 
On Fri, May 17, 2013 at 6:37 PM, saxmad  wrote:

> I'm on Postgres 9.2 on Debian Wheezy.
>
> So is this a Postgres issue or an RT upgrade issue ?
>

Both. RT uses something that is deleted. Pg deleted something that is used
by software.


> --
> View this message in context:
> http://requesttracker.8502.n7.nabble.com/Problems-upgrading-from-3-9-3-tp53543p53907.html
> Sent from the Request Tracker - User mailing list archive at Nabble.com.
>
>
> --
> RT Training in Seattle, June 19-20: http://bestpractical.com/training
>



-- 
Best regards, Ruslan.


-- 
RT Training in Seattle, June 19-20: http://bestpractical.com/training

Re: [rt-users] Problems upgrading from 3.9.3

2013-05-17 Thread saxmad 
I'm on Postgres 9.2 on Debian Wheezy.

So is this a Postgres issue or an RT upgrade issue ?



--
View this message in context: 
http://requesttracker.8502.n7.nabble.com/Problems-upgrading-from-3-9-3-tp53543p53907.html
Sent from the Request Tracker - User mailing list archive at Nabble.com.


-- 
RT Training in Seattle, June 19-20: http://bestpractical.com/training

Re: [rt-users] Flaws on RT::Extension::RepeatTicket search

2013-05-17 Thread Ruslan Zakirov 
Then the following TicketSQL can be used:

HasAttribute = 'RepeatTicketSettings'


On Fri, May 17, 2013 at 4:46 PM, Jim Brandt wrote:

>
>
>> I did and it did show up. But the problem is that field only appear
>> when ticket already repeat at least one time, am I correct? For
>> example, now I create a recurrent ticket same month and day in next
>> year, after 3 months and I did a search, OriginalTicket should not
>> create as it haven't been repeat, please clarify if something wrong
>> in my concept. Thanks.
>>
>
> You're correct, the initial ticket doesn't record a link to itself which
> would allow you to search on it. To track down the repeating tickets that
> haven't repeated yet, look at the code in the rt-repeat-ticket script you
> schedule in cron. It looks for all tickets with attribute
> 'RepeatTicketSettings'. You could just put a debug statement in that script
> to print the ticket id of each ticket, then run the script.
>
>
>
> --
> RT Training in Seattle, June 19-20: 
> http://bestpractical.com/**training
>



-- 
Best regards, Ruslan.


-- 
RT Training in Seattle, June 19-20: http://bestpractical.com/training

Re: [rt-users] RT4/ExternalAuth/AD issues:

2013-05-17 Thread Asif Iqbal 
On Thu, May 16, 2013 at 11:37 AM, Duncan Carter  wrote:

> # There should only be one @Plugins declaration in your config file.
>
> #Set(@Plugins,(qw(RT::Extension::QuickDelete RT::Extension::CommandByMail
> RT::Authen::ExternalAuth)));
>

Looks like @Plugins commented out?



-- 
Asif Iqbal
PGP Key: 0xE62693C5 KeyServer: pgp.mit.edu
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?


-- 
RT Training in Seattle, June 19-20: http://bestpractical.com/training

Re: [rt-users] RT4/ExternalAuth/AD issues:

2013-05-17 Thread Shain Singh 
Take a tcpdump of the LDAP traffic to see if its binding properly.


--
Shain Singh
+61 422 921 951

// sent from mobile device

On 17/05/2013, at 10:51 PM, Duncan Carter  wrote:

> Hi Shain,
> 
> Hasn't helped I'm afraid, double checked the settings, restarted Apache, 
> tried to login and same errors received on web site and in logs.
> 
> Kind regards,
> 
> -Original Message-
> From: Shain Singh [mailto:shain.si...@gmail.com] 
> 
> Hi,
> 
> Try the following:
> 
>># The username RT should use to connect to the LDAP server
>>'user'  =>  'ad-rt-user',
> set this to be the LDAP DN, i.e. 
> 'cn=ad-rt-user',ou=OrgUnit,dc=domain,dc-local'
> 
>>'filter'=>
>> '(sAMAccountType=805306368)',
> I've used the (objectClass=user) as my filter.
> 
> 
>># The filter that will only match disabled users
>> 
>>'d_filter'  =>
>> '(&(sAMAccountType=805306368)(userAccountControl:1.2.840.113556.1.4.803:=2))',
> I've used (objectClass=ThisWillNeverMatch)
> 
>>'group' =>  'RTusers',
> cn=RTusers,ou=OrgUnit,dc=domain,dc=local
> 
> 


-- 
RT Training in Seattle, June 19-20: http://bestpractical.com/training

Re: [rt-users] RT4/ExternalAuth/AD issues:

2013-05-17 Thread Duncan Carter 
Hi Shain,

Hasn't helped I'm afraid, double checked the settings, restarted Apache, tried 
to login and same errors received on web site and in logs.

Kind regards,

-Original Message-
From: Shain Singh [mailto:shain.si...@gmail.com] 

Hi,

Try the following:

> # The username RT should use to connect to the LDAP server
> 'user'  =>  'ad-rt-user',
set this to be the LDAP DN, i.e. 'cn=ad-rt-user',ou=OrgUnit,dc=domain,dc-local'

> 'filter'=>
> '(sAMAccountType=805306368)',
I've used the (objectClass=user) as my filter.


> # The filter that will only match disabled users
>
> 'd_filter'  =>
> '(&(sAMAccountType=805306368)(userAccountControl:1.2.840.113556.1.4.803:=2))',
I've used (objectClass=ThisWillNeverMatch)

> 'group' =>  'RTusers',
cn=RTusers,ou=OrgUnit,dc=domain,dc=local




-- 
RT Training in Seattle, June 19-20: http://bestpractical.com/training

Re: [rt-users] Flaws on RT::Extension::RepeatTicket search

2013-05-17 Thread Jim Brandt 




I did and it did show up. But the problem is that field only appear
when ticket already repeat at least one time, am I correct? For
example, now I create a recurrent ticket same month and day in next
year, after 3 months and I did a search, OriginalTicket should not
create as it haven't been repeat, please clarify if something wrong
in my concept. Thanks.


You're correct, the initial ticket doesn't record a link to itself which 
would allow you to search on it. To track down the repeating tickets 
that haven't repeated yet, look at the code in the rt-repeat-ticket 
script you schedule in cron. It looks for all tickets with attribute 
'RepeatTicketSettings'. You could just put a debug statement in that 
script to print the ticket id of each ticket, then run the script.



--
RT Training in Seattle, June 19-20: http://bestpractical.com/training

[rt-users] Fulltext search error 500 on first try, then ok

2013-05-17 Thread Michele Bergonzoni 
[rt 4.0.9, postgres 9.1 with full text search, ubuntu 12.04.1, Apache 
2.2.22, mod_fastcgi-SNAP-0910052141, Perl v5.14.2]


I have a sporadic annoyance.

When I try a fulltext search on all tickets ("any" keyword), it waits 10 
seconds and then I get a 500 Internal server error. Apache error log says:


[warn] FastCGI: (dynamic) server "/path/to/rt-4.0.9/sbin/rt-server.fcgi" 
(pid 10410) terminated due to uncaught signal '13' (Broken pipe)


And postgresql log:

 LOG:  could not receive data from client: Connection reset by peer
 LOG:  unexpected EOF on client connection
 LOG:  could not receive data from client: Connection reset by peer
 LOG:  unexpected EOF on client connection

(four lines in the same second as the Apache line)

If i retry immediately after, all goes well and the results is displayed 
in maybe 2-3 seconds. Even if I purposely try a search that I know will 
return thousands of tickets, all goes well in a few seconds and tickets 
are retrieved.


The rt-fulltext-indexer is run every ten minutes and completes in a few 
seconds. Postgres statement timeout is 0 (disabled), mod_fastcgi 
-idle-timeout is set to 300.


Besides telling users to keep calm and carry on hitting F5, does anybody 
have any troubleshooting path to suggest? Please keep in mind that 
reproducing this is not easy, today I saw it only once.


Thanks in advance,
Bergonz

--
Ing. Michele Bergonzoni - Laboratori Guglielmo Marconi S.p.a.
Phone:+39-051-6781926 e-mail: berg...@labs.it
alt.advanced.networks.design.configure.operate


--
RT Training in Seattle, June 19-20: http://bestpractical.com/training

Re: [rt-users] Notify Actor

2013-05-17 Thread Andrea gabellini - SC 
Thomas,

this queue is a low traffic queue, and users that use it aren't so
familiar with RT, so they prefer to have all emails in their mailbox,
also those they send.

Thanks,
Andrea


Il 16/05/2013 21:45, Thomas Sibley ha scritto:
> On 05/16/2013 01:07 AM, Andrea gabellini - SC wrote:
>> Thomas,
>>
>> I have 10 queues and only in one of them I need to notify the actor.
>> What about a config like this?
>>
>> Set(NotifyActor, {
>>  'default' => '0',
>>  'queue-name' => '1',
>> });
> I understand the concept.  What I'm asking is for an explanation why you
> want it for only 1 queue but not all the others.
>
>
>

-- 

Maintenance-free: When it breaks, it can't be fixed...


Ing. *Andrea Gabellini*
Email: andrea.gabell...@telecomitalia.sm

Skype: andreagabellini
Tel: (+378) 0549 886111
Fax: (+378) 0549 886188

Telecom Italia San Marino S.p.A.
Strada degli Angariari, 3
47891 Rovereta
Republic of San Marino

http://www.telecomitalia.sm


-- 
RT Training in Seattle, June 19-20: http://bestpractical.com/training

Re: [rt-users] Minimum MySQL permission for RT database access

2013-05-17 Thread Ruslan Zakirov 
Filed a ticket.


On Thu, May 16, 2013 at 3:43 AM, William Muriithi <
william.murii...@gmail.com> wrote:

> Thank you
>
> That's what I was looking for. Agree, its a little unnecessary but prefer
> not being too generous as the application is external facing.
>
> If you guys ever get around cleaning the code to just use select, insert,
> update and delete,  please document it somewhere
>
> William
> On May 15, 2013 10:12 AM, "Ruslan Zakirov"  wrote:
>
>> On Wed, May 15, 2013 at 4:23 PM, William Muriithi <
>> william.murii...@gmail.com> wrote:
>>
>>> Hello,
>>>
>>> I have spent an hour or so looking at the least recommended permission
>>> RT need to be able to manage mysql database and everybody seem to be taking
>>> the easy way, grant everything
>>>
>> People usually don't grant any mysql level permissions and just trust RT
>> to do so and the following is what RT grants:
>>
>> 18"GRANT SELECT,INSERT,CREATE,INDEX,UPDATE,DELETE
>> 19ON `$db_name`.*
>> 20TO '$db_user'\@'$db_rthost'
>> 21IDENTIFIED BY '$db_pass';",
>> 22 );
>>
>> It's a bit over-granting and I believe that our code is clean enough that
>> it's possible to limit the list to SELECT,INSERT,UPDATE,DELETE, but I can
>> not say it's possible for sure without fixing code.
>>
>>
>>> Is it possible Best Practice has listed the necessary grants that is
>>> needed for RT to work successfully on mysql server that I missed? Would
>>> appreciate any guidance
>>>
>>
>> RT's user in mysql (RT uses one account for operation) has to have
>> SELECT, INSERT, UPDATE, DELETE rights on all RT's tables to operate.
>> Upgrade steps should use DBA account for steps that require
>> DROP/CREATE/ALTER/INDEX or any other rights, but as I said, considering
>> above GRANT, this code may have "bugs" and use RT's primary account to
>> perform some upgrade operations.
>>
>> What is the problem you're trying to solve?
>>
>>> Regards,
>>>
>>> William
>>>
>>
>>
>>
>> --
>> Best regards, Ruslan.
>>
>


-- 
Best regards, Ruslan.


-- 
RT Training in Seattle, June 19-20: http://bestpractical.com/training