Hi Cyril,
You forgot the log-error option that much sysadmin use for correct debugging
without pollution, but i don't think it logs incorrect logging (if i
remember well).
The Authentication packet is mandatory for preventing blocking, but i don't
know if the check of the response is really interesting.
My first thought was it can detect integrity error on the "mysql" database,
but i hope MySQL can detect this kind of error in another way and display
errors in the Handshake initialization packet. On the other side, it can
detect server load, but i also think it can be detected in another way
because it is not so reliable.
By the way, Willy, do what you think better. ;-)
Hervé.
----------------original message-----------------
De: "Cyril Bont�" cyril.bo...@free.fr
A: "Willy Tarreau" w...@1wt.eu, "Herv� COMMOWICK" hcommow...@exosec.fr
Copie à: haproxy@formilux.org
Date: Fri, 15 Jan 2010 23:26:59 +0100
-------------------------------------------------
> Hi Herv� and Willy,
>
> I'm answering to your 2 previous mails in this one.
>
> Le Vendredi 15 Janvier 2010 18:30:28, Herv� COMMOWICK a �crit :
>> I have updated the mysql-check with idea and code from Cyril. I send()
>> the authentication packet the same way as the ssl hello packet,
>> i think it is more cleaner than send() in the event_srv_chk_r().
>
> Nice, this is much better (I was not fond of this send() I added in the
response
> part).
>
> I've also updated your patch so that the packets are parsed in a loop
(checks a
> maximum of 2 packets), this will remove the duplicated code (conditions
for the
> second packet are almost the same than for the first one).
> I won't send it immediatly (no need to spam everyone :) ) as I've got some
questions
> we might discuss (see below).
>
> Le Vendredi 15 Janvier 2010 21:22:29, Willy Tarreau a �crit :
>> I don't know here if we can get more than two packets (eg: newer versions
?) but
>> just in case, maybe replace == with >= ?
>
> It should not but you're right, the code should take this into account in
case it
> happens :
> the first packet is the Handshake initialisation packet, the second one is
the
> authentication response.
>
>> > --- haproxy/doc/configuration.txt 2010-01-14 09:37:09.000000000
>> +0100
>> > +++ haproxy.dev/doc/configuration.txt 2010-01-15
>> 16:09:02.858912373 +0100
>> > @@ -2780,11 +2780,20 @@
>> > yes | no | yes | yes
>> > Arguments : none
>> >
>> > - The check consists in parsing Mysql Handshake Initialisation packet
or
>> Error
>> > - packet, which is sent by MySQL server on connect. It is a basic but
useful
>> > - test which does not produce any logging on the server. However, it
does not
>> > - check database presence nor database consistency, nor user permission
>> to
>> > - access. To do this, you can use an external check with xinetd for
example.
>> > + The check consists of sending a Client Authentication packet, with
>> "haproxy"
>> > + username. We parse the Mysql Handshake Initialisation packet and/or
>> > + Error packet. It is a basic but useful test which does not produce
error
>> > + on the server.
>> > +
>> > + However, it requires adding an authorization in the MySQL table, like
this
>> :
>> > + USE mysql;
>> > + INSERT INTO user (Host,User) values ('','haproxy');
>> > + FLUSH PRIVILEGES;
>>
>> Since this test is much more intrusive than previous version, shouldn't
it
>> be left as an option of the previous one ? That way users could decide
whether
>> to use the less complete test with no change on the server or the more
complete
>> one with changes. This especially makes sense where the LB is shared by
>> several
>> customers and the LB's admin does not have to impact security parameters
of
>> their customers.
>
> This part concerns the question I want to discuss with you (and any other
readers
> working with MySQL ;) ) :
> I find the test too intrusive : shouldn't we just ignore the second packet
?
> No matter if the authentication succeeds or fails, the main goal of the
> authentication request is to prevent the MySQL server to block the haproxy
> server.
>
> At the moment, if the haproxy user is not declared, the server goes down ,
which
> doesn't mean that the application itself can't connect to the server.
> And if haproxy receives regularly 1 packet, 2 packets (with an error in
the
> second), then again 1 packet, this will make the server go up and down.
>
> If we ignore the second packet, as soon as the haproxy ip/host is
referenced in the
> user table (expanded to '%' entries or not) which should be the case if we
don't use
> a transparent proxy, the Handshake Initialisation Packet should be a
> successful response.
>
>> BTW, do you know what is logged on the server when attempting to
authenticate
>> with an empty username ("\0") ? If it's silent and we can recognize the
return
>> code, it could also serve as a valid check ?
>
> Using an empty username ("\0"), this will be an anonymous account. Some
servers
> will accept it, some others not (for security reason), but it won't change
the log
> rate.
> It depends on the mysql server configuration (general_log option) :
> - Disabled, it won't log anything,
> - Enabled, it will log all the server activity : users authentication
(success
> and failures), queries, ... so this is generally set only for debug.
>
> But statistics are different, on failure the "Aborted_connects" counter
will
> increment for each check.
>
> --
> Cyril Bont�
>
>
