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 ('<ip_of_haproxy>','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é
