RT and CVS on different hosts

Hi,

I’ve looked into the CVS handler and it seems like a useful tool to me.
However, we run CVS on a different server than RT and I don’t intend to
change that.

Is anybody already working on a solution that would work with CVS and RT
on different machines? If not, I’ll look into that in the next few
weeks. I’m thinking of a heavily modified rt-commithandler on the CVS
host and an enhanced-mailgate on the RT server.

Fabian

BOFH excuse #332:

suboptimal routing experience

I’ve never even looked at the CVS code, but I (and others) run the
rt-mailgate on one machine, with the WebUI on another, and I assume the
same prinicples apply.
Just install a second RT on the CVS host, minus the WebUI, and do the set
it to connect to the RT database remotely.
I imagine that would work, but as I said, I’ve never looked at the CVS bit.

-fr.

At 07:56 14/01/02, Fabian Ritzmann wrote:

Hi,

I’ve looked into the CVS handler and it seems like a useful tool to me.
However, we run CVS on a different server than RT and I don’t intend to
change that.

Is anybody already working on a solution that would work with CVS and RT
on different machines? If not, I’ll look into that in the next few
weeks. I’m thinking of a heavily modified rt-commithandler on the CVS
host and an enhanced-mailgate on the RT server.

Fabian


BOFH excuse #332:

suboptimal routing experience


rt-devel mailing list
rt-devel@lists.fsck.com
http://lists.fsck.com/mailman/listinfo/rt-devel

Feargal Reilly,
Systems Administrator,
The CIA.

Thank you, Feargal. I’m replying to rt-users now instead of rt-devel
with what are essentially setup questions.

I’ve never even looked at the CVS code, but I (and others) run the
rt-mailgate on one machine, with the WebUI on another, and I assume the
same prinicples apply.
Just install a second RT on the CVS host, minus the WebUI, and do the set
it to connect to the RT database remotely.
I imagine that would work, but as I said, I’ve never looked at the CVS bit.

Thanks. I didn’t consider that option properly. There are a few security
related issues I’m wondering about, though.

  • If I’m not mistaken, the CVS commit handler script is run with user
    permissions (we use CVS over SSH). I don’t see an easy way of keeping
    the rt_user database password protected in that case. Running it setuid
    would be possible, but that seems risky to me, considering that a CVS
    user could pass any junk to that script.

  • I browsed through the “security issues” in the MySQL manual and found
    SSL mentioned several times but no reference on how to configure mysqld
    for it. Could somebody point me to the right section in the docs?

Fabian

|+ - I browsed through the “security issues” in the MySQL manual and found
|+ SSL mentioned several times but no reference on how to configure mysqld
|+ for it. Could somebody point me to the right section in the docs?

As I understand it, MySQL supports SSL as of Version 4.0.0:

Do not transmit plain (unencrypted) data over the Internet. These data are
accessible to everyone who has the time and ability to intercept it and
use it for their own purposes. Instead, use an encrypted protocol such as
SSL or SSH. MySQL supports internal SSL connections as of Version
4.0.0. SSH port-forwarding can be used to create an encrypted (and
compressed) tunnel for the communication.

Taken from: http://mysql.nixc.net/doc/G/e/General_security.html

|+ - I browsed through the “security issues” in the MySQL manual and found
|+ SSL mentioned several times but no reference on how to configure mysqld
|+ for it. Could somebody point me to the right section in the docs?

As I understand it, MySQL supports SSL as of Version 4.0.0:

Indeed. The 3.23 manual was somewhat confusing.

It seems that I have the following options besides pursuing my original
CVS plans:

  1. Run a development MySQL 4.0 or wait until MySQL 4 is supported by RT.

Would be an option considering that CVS support is not essential for
us. Are there any plans for RT to support MySQL 4? Did anybody try it
already?

  1. Migrate to postgresql

Starts to sound attractive to me, especially since I noticed that it
supports Kerberos authentication. On the other hand, transferring the
old MySQL database might be a problem. Does anybody have experiences
with that?

  1. Connect over an SSH tunnel.

That’s possible, but in my experience it’s not too reliable and needs
manual work every once in a while.

Fabian

BOFH excuse #71:

The file system is full of it

Hi,
/tmp/mysql.sock has been deleted so RT can no longer connect to the mysl server. The simplest solution seems to be to specify the hostname of the mysql server rather than using localhost. I have edited etc/config.pm but RT hasn’t seen the change.

Do I need to restart the server or do I need to reinstall RT?

|+ Do I need to restart the server or do I need to reinstall RT?

Whenever you make changes to RT’s config file, or upgrade RT, you MUST
stop and then start apache again. Just doing a simple ‘apachectl
restart’ does not do it.

If your operating system periodically cleans out /tmp this could be the cause (I gather you didn’t delete the socket yourself)… if this is the case you can locate the problem and alter your scripts to work around it…

-HaroldOn 17 Jan 2002, Michael Thompson wrote:

Hi, /tmp/mysql.sock has been deleted so RT can
no longer connect to the mysl server. The
simplest solution seems to be to specify the
hostname of the mysql server rather than using
localhost. I have edited etc/config.pm but RT
hasn’t seen the change.

Do I need to restart the server or do I need
to reinstall RT?

_____________________________________________-
__
rt-users mailing list
rt-users@lists.fsck.com http://lists.fsck.c-
om/mailman/listinfo/rt-users

If your operating system periodically cleans out /tmp this could be the
cause (I gather you didn’t delete the socket yourself)… if this is the
case you can locate the problem and alter your scripts to work around it…

It’s less complicated than that - restart mysqld and it’ll recreate the
socket.

  • mz

“MT” == Michael Thompson Michael.Thompson@s3group.com writes:

MT> /tmp/mysql.sock has been deleted so RT can no longer connect
MT> to the mysl server. The simplest solution seems to be to

Remove your cleanup script that cleans out your /tmp/ directory, or
move the socket when compiling mysql. A good place is /var/run, IMHO.

MT> Do I need to restart the server or do I need to reinstall RT?

you need to stop and start the server; not restart it.