Hello all, so I’m in a bit of a pickle. I rolled out RT 3.4.5 on a
testing-only basis to a low-end desktop server running Debian Etch
called, cleverly enough, ‘betart’, fully intending to purchase better
server-grade hardware and migrate over to it once we worked all our
initial mistakes out. I then purchased “RT Essentials” which, in
hindsight, I should’ve done first.
After we’d been using RT on the beta system for a month or so, got
all the wrinkles ironed out and got a whole bunch of really useful
ticketing data on it, we purchased a shiny new Proliant box and slapped
Debian Etch on it as well. We were able to get RT, Apache, and all the
fixin’s up and running without incident, but now it came time to migrate
the data over. I followed the method described in RT Essentials on pgs
73-75 regarding backing up and restoring the MySQL DB, but then I
noticed the paragraph that says “Make sure RT’s configuration file has
the same values it had before the crash. It’s particularly important to
get the $rtname and $Organization variables right, or RT won’t work
properly”. Well, $Organization is no problem, that stays the same from
the beta to the deployed box. However, $rtname is definitely changing
from ‘betart.nellymoser.com’ to ‘rt.nellymoser.com’. Other than that
change, RT_SiteConfig.pm remains the same.
My question for you guys is, what does changing $rtname break between
RT instances, and is it possible to just do a recursive search through
the dump of the beta mysql db before importing it into the
soon-to-be-production box and change all instances of “betart” to “rt”
without causing the whole thing to crash and burn horribly? Second
question, there’s a small amount of entries (such as deleted or
“unprivileged” accounts, queues, etc) that we created that we don’t use
any more. Is it possible to manually zap those from the MySQL DB and
not hurt anything? I think the Perl snippet on page 71-72 of RT
Essentials would do it, but that appears to be on a per-transaction
basis. I don’t know if that could be modified to delete entire queues,
groups, or users. Would it?
Many thanks in advance for all your assistance!
–Lee Whalen
Nellymoser, Inc
- On 17/10/06 13:56 -0400, Lee Whalen wrote:
| Hello all, so I’m in a bit of a pickle. I rolled out RT 3.4.5 on a
| testing-only basis to a low-end desktop server running Debian Etch
| called, cleverly enough, ‘betart’, fully intending to purchase better
| server-grade hardware and migrate over to it once we worked all our
| initial mistakes out. I then purchased “RT Essentials” which, in
| hindsight, I should’ve done first.
|
| After we’d been using RT on the beta system for a month or so, got
| all the wrinkles ironed out and got a whole bunch of really useful
| ticketing data on it, we purchased a shiny new Proliant box and slapped
| Debian Etch on it as well. We were able to get RT, Apache, and all the
| fixin’s up and running without incident, but now it came time to migrate
| the data over. I followed the method described in RT Essentials on pgs
| 73-75 regarding backing up and restoring the MySQL DB, but then I
| noticed the paragraph that says “Make sure RT’s configuration file has
| the same values it had before the crash. It’s particularly important to
| get the $rtname and $Organization variables right, or RT won’t work
| properly”. Well, $Organization is no problem, that stays the same from
| the beta to the deployed box. However, $rtname is definitely changing
| from ‘betart.nellymoser.com’ to ‘rt.nellymoser.com’. Other than that
| change, RT_SiteConfig.pm remains the same.
|
| My question for you guys is, what does changing $rtname break between
| RT instances, and is it possible to just do a recursive search through
| the dump of the beta mysql db before importing it into the
| soon-to-be-production box and change all instances of “betart” to “rt”
| without causing the whole thing to crash and burn horribly? Second
| question, there’s a small amount of entries (such as deleted or
| “unprivileged” accounts, queues, etc) that we created that we don’t use
| any more. Is it possible to manually zap those from the MySQL DB and
| not hurt anything? I think the Perl snippet on page 71-72 of RT
| Essentials would do it, but that appears to be on a per-transaction
| basis. I don’t know if that could be modified to delete entire queues,
| groups, or users. Would it?
|
| Many thanks in advance for all your assistance!
http://wiki.bestpractical.com/index.cgi?RenameInstance
cheers
- wash
Odhiambo Washington . WANANCHI ONLINE LTD (Nairobi, KE) |
wash () WANANCHI ! com . 1ere Etage, Loita Hse, Loita St., |
GSM: (+254) 722 743 223 . # 10286, 00100 NAIROBI |
GSM: (+254) 733 744 121 . (+254) 020 313 985 - 9 |
“Oh My God! They killed init! You Bastards!”
–from a /. post