Old mysql patch - is this useful?

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Old mysql patch - is this useful?

Scott Kitterman-4
I am looking at some of the two decades of accumulated cruft in the Debian bug
tracking system for the Postfix package.  I came across an old bug with a
patch that appears never to have been incorporated (no sign ups required):

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=400395

I've attached the patch (it's very old, but at a glance it doesn't look like
the relevant code has changed much).

No one in Debian who works on Postfix uses the mysql bits.  Is there anyone
that is using it that thinks it's worth updating and seeing if it can be
incorporated?

Scott K

postfix-2.2.3-mysql_default_file-2.patch (4K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Old mysql patch - is this useful?

Andrey Repin-2
Greetings, Scott Kitterman!

> I am looking at some of the two decades of accumulated cruft in the Debian bug
> tracking system for the Postfix package.  I came across an old bug with a
> patch that appears never to have been incorporated (no sign ups required):

> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=400395

> I've attached the patch (it's very old, but at a glance it doesn't look like
> the relevant code has changed much).

> No one in Debian who works on Postfix uses the mysql bits.  Is there anyone
> that is using it that thinks it's worth updating and seeing if it can be
> incorporated?

For SSL support, it's only worth it if connection stays open for prolonged
periods of time.
If it's usual connect-work-disconnect type of operation, SSL will only
increase system load without any obvious gains.
If you need secure connection to your SQL server badly, setup an encrypted
tunnel.


--
With best regards,
Andrey Repin
Thursday, December 13, 2018 15:17:56

Sorry for my terrible english...

Reply | Threaded
Open this post in threaded view
|

Re: Old mysql patch - is this useful?

Wietse Venema
In reply to this post by Scott Kitterman-4
Scott Kitterman:

> I am looking at some of the two decades of accumulated cruft in the Debian bug
> tracking system for the Postfix package.  I came across an old bug with a
> patch that appears never to have been incorporated (no sign ups required):
>
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=400395
>
> I've attached the patch (it's very old, but at a glance it doesn't look like
> the relevant code has changed much).
>
> No one in Debian who works on Postfix uses the mysql bits.  Is there anyone
> that is using it that thinks it's worth updating and seeing if it can be
> incorporated?

I think that something along those lines has been implemented.

        Wietse

MYSQL_TABLE(5)                                                  MYSQL_TABLE(5)

NAME
       mysql_table - Postfix MySQL client configuration
        ...
       option_file
              Read  options  from the given file instead of the default my.cnf
              location. This reads options from  the  [client]  option  group,
              optionally  followed  by  options  from  the  group  given  with
              option_group.

              This parameter is available with Postfix 2.11 and later.

       option_group (default: Postfix >=3.2: client, <= 3.1: empty)
              Read options from the given group of  the  mysql  options  file,
              after reading options from the [client] group.

              Postfix  3.2  and  later  read [client] option group settings by
              default. To disable this  specify  no  option_file  and  specify
              "option_group =" (i.e. an empty value).

              Postfix  3.1  and  earlier don't read [client] option group set-
              tings unless a non-empty option_file or option_group  value  are
              specified. To enable this, specify, for example, "option_group =
              client".

              This parameter is available with Postfix 2.11 and later.
Reply | Threaded
Open this post in threaded view
|

Re: Old mysql patch - is this useful?

Wietse Venema
In reply to this post by Andrey Repin-2
Andrey Repin:

> Greetings, Scott Kitterman!
>
> > I am looking at some of the two decades of accumulated cruft in the Debian bug
> > tracking system for the Postfix package.  I came across an old bug with a
> > patch that appears never to have been incorporated (no sign ups required):
>
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=400395
>
> > I've attached the patch (it's very old, but at a glance it doesn't look like
> > the relevant code has changed much).
>
> > No one in Debian who works on Postfix uses the mysql bits.  Is there anyone
> > that is using it that thinks it's worth updating and seeing if it can be
> > incorporated?
>
> For SSL support, it's only worth it if connection stays open for prolonged
> periods of time.
> If it's usual connect-work-disconnect type of operation, SSL will only
> increase system load without any obvious gains.
> If you need secure connection to your SQL server badly, setup an encrypted
> tunnel.

Postfix programs run for at least 100s, keeping lookup table
connections open until the process terminates.

Additionally, Postfix programs should use proxymap(8) to reduce the
number of (MySQL and other) database connections.

        Wietse
Reply | Threaded
Open this post in threaded view
|

Re: Old mysql patch - is this useful?

Scott Kitterman-4
In reply to this post by Wietse Venema


On December 13, 2018 12:35:40 PM UTC, Wietse Venema <[hidden email]> wrote:

>Scott Kitterman:
>> I am looking at some of the two decades of accumulated cruft in the
>Debian bug
>> tracking system for the Postfix package.  I came across an old bug
>with a
>> patch that appears never to have been incorporated (no sign ups
>required):
>>
>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=400395
>>
>> I've attached the patch (it's very old, but at a glance it doesn't
>look like
>> the relevant code has changed much).
>>
>> No one in Debian who works on Postfix uses the mysql bits.  Is there
>anyone
>> that is using it that thinks it's worth updating and seeing if it can
>be
>> incorporated?
>
>I think that something along those lines has been implemented.
>
> Wietse
>
>MYSQL_TABLE(5)                                                
>MYSQL_TABLE(5)
>
>NAME
>       mysql_table - Postfix MySQL client configuration
> ...
>       option_file
>       Read  options  from the given file instead of the default my.cnf
>       location. This reads options from  the  [client]  option  group,
>       optionally  followed  by  options  from  the  group  given  with
>              option_group.
>
>              This parameter is available with Postfix 2.11 and later.
>
>       option_group (default: Postfix >=3.2: client, <= 3.1: empty)
>       Read options from the given group of  the  mysql  options  file,
>              after reading options from the [client] group.
>
>       Postfix  3.2  and  later  read [client] option group settings by
>       default. To disable this  specify  no  option_file  and  specify
>              "option_group =" (i.e. an empty value).
>
>       Postfix  3.1  and  earlier don't read [client] option group set-
>       tings unless a non-empty option_file or option_group  value  are
>       specified. To enable this, specify, for example, "option_group =
>              client".
>
>              This parameter is available with Postfix 2.11 and later.

Thanks.  The bug report and the patch considerably predate 2.11.  It looks like you have it covered already.

Scott K