Hi,
Can anyone help with some obvious issues around setting up a load balanced
OTRS?
- Does last db write always win?
I imagine there's no built in protection against it.
- Are HTTP sticky sessions required and if so, how can they be configured?
I imagine OTRS needs some built in support to
Did anyone got this during
]# cat scripts/DBUpdate-to-3.2.mysql.sql | mysql otrs
ERROR 1091 (42000) at line 20: Can't DROP 'ticket_answered'; check that
column/key exists
Can I go on ?
I'm upping from a 3.1.6.
thank you in advance.
MV
Did you run the upgrade script twice?
The ticket_answered column really should have been available in the Ticket
table, although it was no longer used.
--
Mike
On Tue, Jan 29, 2013 at 12:39 PM, Marco Vannini marco.vann...@gmail.comwrote:
Did anyone got this during
]# cat
Hi Michiel,
Yes, I tryed and obviously I had to comment out some row before the one
failed but than I encountered the same on other indexes ...really strange,
but than, the .pl has gone without problems.
[root@HMCVR0004 otrs]# cat scripts/DBUpdate-to-3.2.mysql.sql | mysql otrs
ERROR 1091 (42000)
Marco:
I had to comment out some row before the one failed -- I'm not sure what
you mean here.
Glad it worked for you... I think?
--
Michiel
On Tue, Jan 29, 2013 at 1:22 PM, Marco Vannini marco.vann...@gmail.comwrote:
Hi Michiel,
Yes, I tryed and obviously I had to comment out some row
:D yes, I mean, if I had to reexecute the script the first line ALTER
TABLE ticket DROP group_read; would fail so I commented out all the
command just executed.
Seems to work ... :D
On Tue, Jan 29, 2013 at 1:28 PM, Michiel Beijen michiel.bei...@gmail.comwrote:
Marco:
I had to comment out
Hi,
SUSE Linux Enterprise Server 11 (x86_64)
VERSION = 11
PATCHLEVEL = 2
OTRS 3.2.1
Was previously 3.1.12, then upgraded to 3.2.0.beta5, then upgraded to 3.2.1
We have the following packages installed:
Hi,
Florian advised to install the YAML perl module, but this was installed already:
Check Perl Modules installed.
All Perl modules needed are currently installed.
...
o YAML::XS.ok (v0.38)
Perhaps someone has an idea.
Regards
Rudolf
Von: otrs-boun...@otrs.org
Hi,
Florian pointed me to other possible causes for general upgrade errors.
Even though I installed from the rpm I still executed the following:
(Step 7 of the UPGRADING)
cd /opt/otrs
bin/otrs.SetPermissions.pl /opt/otrs --otrs-user=otrs --web-user=wwwrun
--otrs-group=nogroup --web-group=www
Thoughts:
Rather than invent a application-specific solution, look at Linux-HA
(www.linux-ha.orghttp://www.linux-ha.org). They’ve solved most of these
problems in a neatly packaged way.
There’s existing code to handle session affinity and most of the request
distribution process.
If you store
Hi,
While I appreciate the general advice, please note I'm not trying to
reinvent anything. Instead, I want to prepare for natural problems that
OTRS will run into when reaching a size that requires load balancing.
For example, articles can't be stored in the database for installations
where
Regarding system IDs... you couldn't give each system it's own system ID,
otherwise they would function as distinct systems (each system wouldn't be
able to act on tickets generated by the other etc.). Shared systems would
have to share the same system ID.
And OTRS sessions can be stored either
Thanks for the input. I placed my replies inline. Have a look please.
On Tue, Jan 29, 2013 at 7:29 PM, Steven Carr sjc...@gmail.com wrote:
Regarding system IDs... you couldn't give each system it's own system ID,
otherwise they would function as distinct systems (each system wouldn't be
able
Now this is some mighty useful info. Thanks a lot.
I'm not familiar with LVS or Linux-HA (mostly used MS platforms until ~
recently) so the next question may be born out of confusion: You have the
load balancing performed by machines runnings LVS and the Linux-HA is
running on the app nodes?
Is there a way to exclude the prior email strings in emails when they go out to
customers in ORTS? What happens is we end up with a really long page worth of
duplicate information when the customer responds to the email and it comes back
in as a new article. With excluding the old information
| That is what I have always assumed, if you look in the sessions table in
the DB in the session_value column you can see that there is all of the
user's configuration in one big string.
bogdan: Efficient and simple. I'm surprised. I assumed OTRS stores some
user session data in memory/disk to
I'm not familiar with LVS or Linux-HA (mostly used MS platforms until ~
recently) so the next question may be born out of confusion: You have the load
balancing performed by machines runnings LVS and the Linux-HA is running on the
app nodes?
Correct. LVS handles session distribution and
Beautiful. Thanks a LOT for sharing this info. It took a big uncertainty
off the table as I was unsure if OTRS can handle load balancing without
tweaking it in some ugly ways.
The DMS integration is very nice. If authentication / authorization against
the DMS were an issue in your setup, how did
On topic of big databases: databases store data. Binary data is still data.
I do understand that large databases means large backups and thus long
backup time but if you have the data on disk you also have the data and you
need to back it up as well. So to some extent it is: your database is
I would love OTRS to shift the ticket increment into the database, the less
I can store in the filesystem the better as far as I'm concerned. Does
anyone know if this has been suggested or would anyone be willing to give
their code to the project to try and get it implemented mainstream.
Steve
bogdan: I think if the shared file system would be required just for
attachments, it wouldn't need to be very fancy. I think OTRS doesn't modify
what it has already written on disk for articles / attachments. So it only does
reads and additional writes. No editing.
It does rely on a consistent
21 matches
Mail list logo
