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� > >