I'm also testing some ldap checks but I see lots of logging and log partitions filling up like crazy.
I wonder if it's really doable to check the ldap status in in a gracefull way. 2015-03-31 9:45 GMT+02:00 Neil - HAProxy List <[email protected]>: > Hello > > I was thinking of updating the ldap-check but I think I've a better idea. > Macros (well ish). > > send-binary 300c0201 # LDAP bind request "<ROOT>" simple > send-binary 01 # message ID > send-binary 6007 # protocol Op > send-binary 0201 # bind request > send-binary 03 # LDAP v3 > send-binary 04008000 # name, simple authentication > expect binary 0a0100 # bind response + result code: success > send-binary 30050201034200 # unbind request > > could be in a file named macros/ldap-simple-bind > > then the option > tcp-check-macro ldap-simple-bind > > would use it, I know this is close to includes. > > similarly macros/smtp-helo-quit > connect port 25 > expect rstring ^220 > send QUIT\r\n > expect rstring ^221 > > > or from > http://blog.haproxy.com/2014/06/06/binary-health-check-with-haproxy-1-5-php-fpmfastcgi-probe-example/ > # FCGI_BEGIN_REQUEST > send-binary 01 # version > send-binary 01 # FCGI_BEGIN_REQUEST > send-binary 0001 # request id > send-binary 0008 # content length > send-binary 00 # padding length > send-binary 00 # > send-binary 0001 # FCGI responder > send-binary 0000 # flags > send-binary 0000 # > send-binary 0000 # > # FCGI_PARAMS > send-binary 01 # version > send-binary 04 # FCGI_PARAMS > send-binary 0001 # request id > send-binary 0045 # content length > send-binary 03 # padding length: padding for content % 8 = 0 > send-binary 00 # > send-binary 0e03524551554553545f4d4554484f44474554 # REQUEST_METHOD = GET > send-binary 0b055343524950545f4e414d452f70696e67 # SCRIPT_NAME = /ping > send-binary 0f055343524950545f46494c454e414d452f70696e67 # SCRIPT_FILENAME > = /ping > send-binary 040455534552524F4F54 # USER = ROOT > send-binary 000000 # padding > # FCGI_PARAMS > send-binary 01 # version > send-binary 04 # FCGI_PARAMS > send-binary 0001 # request id > send-binary 0000 # content length > send-binary 00 # padding length: padding for content % 8 = 0 > send-binary 00 # > > expect binary 706f6e67 # pong > > (though for items like > send-binary 0e03524551554553545f4d4554484f44474554 # REQUEST_METHOD = GET > I'd prefer a > send-as-binary "REQUEST_METHOD = GET" > ) > > these and many others could be shipped with haproxy. > > this seems to make sense to me as they are small contained logical items > > Neil > > > On 30 March 2015 at 23:02, Baptiste <[email protected]> wrote: >> >> you should believe it :) >> >> On Mon, Mar 30, 2015 at 11:34 PM, Neil - HAProxy List >> <[email protected]> wrote: >> > Hello >> > >> > Thanks so much. That worked well, I now get >> > L7OK/0 in 0ms >> > not sure I believe the 0ms but maybe I should >> > >> > Thanks again, >> > >> > Neil >> > >> > On 30 March 2015 at 22:14, Baptiste <[email protected]> wrote: >> >> >> >> On Mon, Mar 30, 2015 at 10:33 PM, Neil - HAProxy List >> >> <[email protected]> wrote: >> >> > Hello >> >> > >> >> > I'm trying to use ldap-check with active directory and the response >> >> > active >> >> > directory gives is not one ldap-check is happy to accept >> >> > >> >> > when I give a 389 directory backend ldap server all is well, when I >> >> > use >> >> > AD I >> >> > get 'Not LDAPv3 protocol' >> >> > >> >> > I've done a little poking about and found that >> >> > if ((msglen > 2) || >> >> > (memcmp(check->bi->data + 2 + msglen, >> >> > "\x02\x01\x01\x61", 4) != 0)) { >> >> > set_server_check_status(check, >> >> > HCHK_STATUS_L7RSP, "Not LDAPv3 protocol"); >> >> > is where I'm getting stopped as msglen is 4 >> >> > >> >> > Here is tcpdump of 389 directory response (the one that works) 2 >> >> > packets >> >> > 21:29:34.195699 IP 389.ldap > HAPROXY.57109: Flags [.], ack 15, win >> >> > 905, >> >> > options [nop,nop,TS val 856711882 ecr 20393440], length 0 >> >> > 0x0000: 0050 5688 7042 0064 403b 2700 0800 4500 >> >> > .PV.pB.d@;'...E. >> >> > 0x0010: 0034 9d07 4000 3f06 3523 ac1b e955 ac18 >> >> > .4..@.?.5#...U.. >> >> > 0x0020: 2810 0185 df15 5cab ffcd 63ba 77d3 8010 >> >> > (.....\...c.w... >> >> > 0x0030: 0389 2c07 0000 0101 080a 3310 62ca 0137 >> >> > ..,.......3.b..7 >> >> > 0x0040: 2de0 -. >> >> > 21:29:34.195958 IP 389.ldap > HAPROXY.57109: Flags [P.], seq 1:15, >> >> > ack >> >> > 15, >> >> > win 905, options [nop,nop,TS val 856711882 ecr 20393440], length 14 >> >> > 0x0000: 0050 5688 7042 0064 403b 2700 0800 4500 >> >> > .PV.pB.d@;'...E. >> >> > 0x0010: 0042 9d08 4000 3f06 3514 ac1b e955 ac18 >> >> > .B..@.?.5....U.. >> >> > 0x0020: 2810 0185 df15 5cab ffcd 63ba 77d3 8018 >> >> > (.....\...c.w... >> >> > 0x0030: 0389 e878 0000 0101 080a 3310 62ca 0137 >> >> > ...x......3.b..7 >> >> > 0x0040: 2de0 300c 0201 0161 070a 0100 0400 0400 >> >> > -.0....a........ >> >> > >> >> > Here is tcpdump of active directory (broken) 1 packet >> >> > >> >> > 21:25:24.519883 IP ADSERVER.ldap > HAPROXY.57789: Flags [P.], seq >> >> > 1:23, >> >> > ack >> >> > 15, win 260, options [nop,nop,TS val 1870785 ecr 20331021], length 22 >> >> > 0x0000: 0050 5688 7042 0050 5688 7780 0800 4500 >> >> > .PV.pB.PV.w...E. >> >> > 0x0010: 004a 1d7d 4000 8006 34e3 ac18 280d ac18 >> >> > .J.}@...4...(... >> >> > 0x0020: 2810 0185 e1bd 5a3f 2ae7 3ced 7b5b 8018 >> >> > (.....Z?*.<.{[.. >> >> > 0x0030: 0104 1d7a 0000 0101 080a 001c 8bc1 0136 >> >> > ...z...........6 >> >> > 0x0040: 3a0d 3084 0000 0010 0201 0161 8400 0000 >> >> > :.0........a.... >> >> > 0x0050: 070a 0100 0400 0400 >> >> > >> >> > this was discussed but not finished before see >> >> > http://www.serverphorums.com/read.php?10,394453 >> >> > >> >> > I can see the string \02\01\01\61 is there but not in the correct >> >> > place >> >> > >> >> > Anyone have any ideas about fixing this so that both (and possibly >> >> > other) >> >> > ldap implementations work? >> >> > >> >> > Thanks, >> >> > >> >> > Neil >> >> >> >> >> >> Hi Neil >> >> >> >> Yes you can switch to the tcp-check checking method. >> >> I works with binary protocols as well. >> >> Here is what I use for the AD in my lab: >> >> >> >> option tcp-check >> >> tcp-check connect port 389 >> >> tcp-check send-binary 300c0201 # LDAP bind request "<ROOT>" simple >> >> tcp-check send-binary 01 # message ID >> >> tcp-check send-binary 6007 # protocol Op >> >> tcp-check send-binary 0201 # bind request >> >> tcp-check send-binary 03 # LDAP v3 >> >> tcp-check send-binary 04008000 # name, simple authentication >> >> tcp-check expect binary 0a0100 # bind response + result code: success >> >> tcp-check send-binary 30050201034200 # unbind request >> >> >> >> >> >> You could add the same sequence for LDAPs on port 636: >> >> tcp-check connect port 636 ssl >> >> tcp-check send-binary 300c0201 # LDAP bind request "<ROOT>" simple >> >> tcp-check send-binary 01 # message ID >> >> tcp-check send-binary 6007 # protocol Op >> >> tcp-check send-binary 0201 # bind request >> >> tcp-check send-binary 03 # LDAP v3 >> >> tcp-check send-binary 04008000 # name, simple authentication >> >> tcp-check expect binary 0a0100 # bind response + result code: success >> >> tcp-check send-binary 30050201034200 # unbind request >> >> >> >> >> >> Note for myself: put this tip on the blog.. >> >> >> >> Baptiste >> > >> >
