README - haproxy - Gitiles

                          ----------------------
                              HAProxy how-to
                          ----------------------
                                version 1.5
                              willy tarreau
                                2016/12/25


 1) How to build it
 ------------------

 First, please note that this version is a stable version, so in general if you
 are not used to build from sources, it is recommended that instead you follow
 the packaged updates provided by your software vendor or Linux distribution.
 Most of them are taking this task seriously and are doing a good job. If for
 any reason you'd prefer a different version than the one packaged for your
 system, or to get some commercial support, other choices are available at :

                         http://www.haproxy.com/

 To build haproxy, you will need :
   - GNU make. Neither Solaris nor OpenBSD's make work with the GNU Makefile.
     If you get many syntax errors when running "make", you may want to retry
     with "gmake" which is the name commonly used for GNU make on BSD systems.
   - GCC between 2.95 and 4.8. Others may work, but not tested.
   - GNU ld

 Also, you might want to build with libpcre support, which will provide a very
 efficient regex implementation and will also fix some badness on Solaris' one.

 To build haproxy, you have to choose your target OS amongst the following ones
 and assign it to the TARGET variable :

   - linux22     for Linux 2.2
   - linux24     for Linux 2.4 and above (default)
   - linux24e    for Linux 2.4 with support for a working epoll (> 0.21)
   - linux26     for Linux 2.6 and above
   - linux2628   for Linux 2.6.28, 3.x, and above (enables splice and tproxy)
   - solaris     for Solaris 8 or 10 (others untested)
   - freebsd     for FreeBSD 5 to 10 (others untested)
   - osx         for Mac OS/X
   - openbsd     for OpenBSD 3.1 and above
   - aix51       for AIX 5.1
   - aix52       for AIX 5.2
   - cygwin      for Cygwin
   - generic     for any other OS or version.
   - custom      to manually adjust every setting

 You may also choose your CPU to benefit from some optimizations. This is
 particularly important on UltraSparc machines. For this, you can assign
 one of the following choices to the CPU variable :

   - i686 for intel PentiumPro, Pentium 2 and above, AMD Athlon
   - i586 for intel Pentium, AMD K6, VIA C3.
   - ultrasparc : Sun UltraSparc I/II/III/IV processor
   - native : use the build machine's specific processor optimizations. Use with
     extreme care, and never in virtualized environments (known to break).
   - generic : any other processor or no CPU-specific optimization. (default)

 Alternatively, you may just set the CPU_CFLAGS value to the optimal GCC options
 for your platform.

 You may want to build specific target binaries which do not match your native
 compiler's target. This is particularly true on 64-bit systems when you want
 to build a 32-bit binary. Use the ARCH variable for this purpose. Right now
 it only knows about a few x86 variants (i386,i486,i586,i686,x86_64), two
 generic ones (32,64) and sets -m32/-m64 as well as -march=<arch> accordingly.

 If your system supports PCRE (Perl Compatible Regular Expressions), then you
 really should build with libpcre which is between 2 and 10 times faster than
 other libc implementations. Regex are used for header processing (deletion,
 rewriting, allow, deny). The only inconvenient of libpcre is that it is not
 yet widely spread, so if you build for other systems, you might get into
 trouble if they don't have the dynamic library. In this situation, you should
 statically link libpcre into haproxy so that it will not be necessary to
 install it on target systems. Available build options for PCRE are :

   - USE_PCRE=1 to use libpcre, in whatever form is available on your system
     (shared or static)

   - USE_STATIC_PCRE=1 to use a static version of libpcre even if the dynamic
     one is available. This will enhance portability.

   - with no option, use your OS libc's standard regex implementation (default).
     Warning! group references on Solaris seem broken. Use static-pcre whenever
     possible.

 Recent systems can resolve IPv6 host names using getaddrinfo(). This primitive
 is not present in all libcs and does not work in all of them either. Support in
 glibc was broken before 2.3. Some embedded libs may not properly work either,
 thus, support is disabled by default, meaning that some host names which only
 resolve as IPv6 addresses will not resolve and configs might emit an error
 during parsing. If you know that your OS libc has reliable support for
 getaddrinfo(), you can add USE_GETADDRINFO=1 on the make command line to enable
 it. This is the recommended option for most Linux distro packagers since it's
 working fine on all recent mainstream distros. It is automatically enabled on
 Solaris 8 and above, as it's known to work.

 It is possible to add native support for SSL using the GNU makefile, by passing
 "USE_OPENSSL=1" on the make command line. The libssl and libcrypto will
 automatically be linked with haproxy. Some systems also require libz, so if the
 build fails due to missing symbols such as deflateInit(), then try again with
 "ADDLIB=-lz".

 To link OpenSSL statically against haproxy, build OpenSSL with the no-shared
 keyword and install it to a local directory, so your system is not affected :

     $ export STATICLIBSSL=/tmp/staticlibssl
     $ ./config --prefix=$STATICLIBSSL no-shared
     $ make && make install_sw

 When building haproxy, pass that path via SSL_INC and SSL_LIB to make and
 include additional libs with ADDLIB if needed (in this case for example libdl):

     $ make TARGET=linux26 USE_OPENSSL=1 SSL_INC=$STATICLIBSSL/include SSL_LIB=$STATICLIBSSL/lib ADDLIB=-ldl

 It is also possible to include native support for ZLIB to benefit from HTTP
 compression. For this, pass "USE_ZLIB=1" on the "make" command line and ensure
 that zlib is present on the system.

 By default, the DEBUG variable is set to '-g' to enable debug symbols. It is
 not wise to disable it on uncommon systems, because it's often the only way to
 get a complete core when you need one. Otherwise, you can set DEBUG to '-s' to
 strip the binary.

 For example, I use this to build for Solaris 8 :

     $ make TARGET=solaris CPU=ultrasparc USE_STATIC_PCRE=1

 And I build it this way on OpenBSD or FreeBSD :

     $ gmake TARGET=freebsd USE_PCRE=1 USE_OPENSSL=1 USE_ZLIB=1

 And on a classic Linux with SSL and ZLIB support (eg: Red Hat 5.x) :

     $ make TARGET=linux26 USE_PCRE=1 USE_OPENSSL=1 USE_ZLIB=1

 And on a recent Linux >= 2.6.28 with SSL and ZLIB support :

     $ make TARGET=linux2628 USE_PCRE=1 USE_OPENSSL=1 USE_ZLIB=1

 In order to build a 32-bit binary on an x86_64 Linux system with SSL support
 without support for compression but when OpenSSL requires ZLIB anyway :

     $ make TARGET=linux26 ARCH=i386 USE_OPENSSL=1 ADDLIB=-lz

 The SSL stack supports session cache synchronization between all running
 processes. This involves some atomic operations and synchronization operations
 which come in multiple flavors depending on the system and architecture :

   Atomic operations :
     - internal assembler versions for x86/x86_64 architectures

     - gcc builtins for other architectures. Some architectures might not
       be fully supported or might require a more recent version of gcc.
       If your architecture is not supported, you willy have to either use
       pthread if supported, or to disable the shared cache.

     - pthread (posix threads). Pthreads are very common but inter-process
       support is not that common, and some older operating systems did not
       report an error when enabling multi-process mode, so they used to
       silently fail, possibly causing crashes. Linux's implementation is
       fine. OpenBSD doesn't support them and doesn't build. FreeBSD 9 builds
       and reports an error at runtime, while certain older versions might
       silently fail. Pthreads are enabled using USE_PTHREAD_PSHARED=1.

   Synchronization operations :
     - internal spinlock : this mode is OS-independant, light but will not
       scale well to many processes. However, accesses to the session cache
       are rare enough that this mode could certainly always be used. This
       is the default mode.

     - Futexes, which are Linux-specific highly scalable light weight mutexes
       implemented in user-space with some limited assistance from the kernel.
       This is the default on Linux 2.6 and above and is enabled by passing
       USE_FUTEX=1

     - pthread (posix threads). See above.

 If none of these mechanisms is supported by your platform, you may need to
 build with USE_PRIVATE_CACHE=1 to totally disable SSL cache sharing. Then
 it is better not to run SSL on multiple processes.

 If you need to pass other defines, includes, libraries, etc... then please
 check the Makefile to see which ones will be available in your case, and
 use the USE_* variables in the Makefile.

 AIX 5.3 is known to work with the generic target. However, for the binary to
 also run on 5.2 or earlier, you need to build with DEFINE="-D_MSGQSUPPORT",
 otherwise __fd_select() will be used while not being present in the libc, but
 this is easily addressed using the "aix52" target. If you get build errors
 because of strange symbols or section mismatches, simply remove -g from
 DEBUG_CFLAGS.

 You can easily define your own target with the GNU Makefile. Unknown targets
 are processed with no default option except USE_POLL=default. So you can very
 well use that property to define your own set of options. USE_POLL can even be
 disabled by setting USE_POLL="". For example :

     $ gmake TARGET=tiny USE_POLL="" TARGET_CFLAGS=-fomit-frame-pointer


 2) How to install it
 --------------------

 To install haproxy, you can either copy the single resulting binary to the
 place you want, or run :

     $ sudo make install

 If you're packaging it for another system, you can specify its root directory
 in the usual DESTDIR variable.


 3) How to set it up
 -------------------

 There is some documentation in the doc/ directory :

     - architecture.txt : this is the architecture manual. It is quite old and
       does not tell about the nice new features, but it's still a good starting
       point when you know what you want but don't know how to do it.

     - configuration.txt : this is the configuration manual. It recalls a few
       essential HTTP basic concepts, and details all the configuration file
       syntax (keywords, units). It also describes the log and stats format. It
       is normally always up to date. If you see that something is missing from
       it, please report it as this is a bug. Please note that this file is
       huge and that it's generally more convenient to review Cyril Bonté's
       HTML translation online here :

            http://cbonte.github.io/haproxy-dconv/configuration-1.5.html

     - haproxy-en.txt / haproxy-fr.txt : these are the old outdated docs. You
       should never need them. If you do, then please report what you didn't
       find in the other ones.

     - gpl.txt / lgpl.txt : the copy of the licenses covering the software. See
       the 'LICENSE' file at the top for more information.

     - the rest is mainly for developers.

 There are also a number of nice configuration examples in the "examples"
 directory as well as on several sites and articles on the net which are linked
 to from the haproxy web site.


 4) How to report a bug
 ----------------------

 It is possible that from time to time you'll find a bug. A bug is a case where
 what you see is not what is documented. Otherwise it can be a misdesign. If you
 find that something is stupidly design, please discuss it on the list (see the
 "how to contribute" section below). If you feel like you're proceeding right
 and haproxy doesn't obey, then first ask yourself if it is possible that nobody
 before you has even encountered this issue. If it's unlikely, the you probably
 have an issue in your setup. Just in case of doubt, please consult the mailing
 list archives :

                         http://marc.info/?l=haproxy

 Otherwise, please try to gather the maximum amount of information to help
 reproduce the issue and send that to the mailing list :

                         haproxy@formilux.org

 Please include your configuration and logs. You can mask your IP addresses and
 passwords, we don't need them. But it's essential that you post your config if
 you want people to guess what is happening.

 Also, keep in mind that haproxy is designed to NEVER CRASH. If you see it die
 without any reason, then it definitely is a critical bug that must be reported
 and urgently fixed. It has happened a couple of times in the past, essentially
 on development versions running on new architectures. If you think your setup
 is fairly common, then it is possible that the issue is totally unrelated.
 Anyway, if that happens, feel free to contact me directly, as I will give you
 instructions on how to collect a usable core file, and will probably ask for
 other captures that you'll not want to share with the list.


 5) How to contribute
 --------------------

 Please carefully read the CONTRIBUTING file that comes with the sources. It is
 mandatory.

 -- end
	----------------------
	HAProxy how-to
	----------------------
	version 1.5
	willy tarreau
	2016/12/25


	1) How to build it
	------------------

	First, please note that this version is a stable version, so in general if you
	are not used to build from sources, it is recommended that instead you follow
	the packaged updates provided by your software vendor or Linux distribution.
	Most of them are taking this task seriously and are doing a good job. If for
	any reason you'd prefer a different version than the one packaged for your
	system, or to get some commercial support, other choices are available at :

	http://www.haproxy.com/

	To build haproxy, you will need :
	- GNU make. Neither Solaris nor OpenBSD's make work with the GNU Makefile.
	If you get many syntax errors when running "make", you may want to retry
	with "gmake" which is the name commonly used for GNU make on BSD systems.
	- GCC between 2.95 and 4.8. Others may work, but not tested.
	- GNU ld

	Also, you might want to build with libpcre support, which will provide a very
	efficient regex implementation and will also fix some badness on Solaris' one.

	To build haproxy, you have to choose your target OS amongst the following ones
	and assign it to the TARGET variable :

	- linux22 for Linux 2.2
	- linux24 for Linux 2.4 and above (default)
	- linux24e for Linux 2.4 with support for a working epoll (> 0.21)
	- linux26 for Linux 2.6 and above
	- linux2628 for Linux 2.6.28, 3.x, and above (enables splice and tproxy)
	- solaris for Solaris 8 or 10 (others untested)
	- freebsd for FreeBSD 5 to 10 (others untested)
	- osx for Mac OS/X
	- openbsd for OpenBSD 3.1 and above
	- aix51 for AIX 5.1
	- aix52 for AIX 5.2
	- cygwin for Cygwin
	- generic for any other OS or version.
	- custom to manually adjust every setting

	You may also choose your CPU to benefit from some optimizations. This is
	particularly important on UltraSparc machines. For this, you can assign
	one of the following choices to the CPU variable :

	- i686 for intel PentiumPro, Pentium 2 and above, AMD Athlon
	- i586 for intel Pentium, AMD K6, VIA C3.
	- ultrasparc : Sun UltraSparc I/II/III/IV processor
	- native : use the build machine's specific processor optimizations. Use with
	extreme care, and never in virtualized environments (known to break).
	- generic : any other processor or no CPU-specific optimization. (default)

	Alternatively, you may just set the CPU_CFLAGS value to the optimal GCC options
	for your platform.

	You may want to build specific target binaries which do not match your native
	compiler's target. This is particularly true on 64-bit systems when you want
	to build a 32-bit binary. Use the ARCH variable for this purpose. Right now
	it only knows about a few x86 variants (i386,i486,i586,i686,x86_64), two
	generic ones (32,64) and sets -m32/-m64 as well as -march=<arch> accordingly.

	If your system supports PCRE (Perl Compatible Regular Expressions), then you
	really should build with libpcre which is between 2 and 10 times faster than
	other libc implementations. Regex are used for header processing (deletion,
	rewriting, allow, deny). The only inconvenient of libpcre is that it is not
	yet widely spread, so if you build for other systems, you might get into
	trouble if they don't have the dynamic library. In this situation, you should
	statically link libpcre into haproxy so that it will not be necessary to
	install it on target systems. Available build options for PCRE are :

	- USE_PCRE=1 to use libpcre, in whatever form is available on your system
	(shared or static)

	- USE_STATIC_PCRE=1 to use a static version of libpcre even if the dynamic
	one is available. This will enhance portability.

	- with no option, use your OS libc's standard regex implementation (default).
	Warning! group references on Solaris seem broken. Use static-pcre whenever
	possible.

	Recent systems can resolve IPv6 host names using getaddrinfo(). This primitive
	is not present in all libcs and does not work in all of them either. Support in
	glibc was broken before 2.3. Some embedded libs may not properly work either,
	thus, support is disabled by default, meaning that some host names which only
	resolve as IPv6 addresses will not resolve and configs might emit an error
	during parsing. If you know that your OS libc has reliable support for
	getaddrinfo(), you can add USE_GETADDRINFO=1 on the make command line to enable
	it. This is the recommended option for most Linux distro packagers since it's
	working fine on all recent mainstream distros. It is automatically enabled on
	Solaris 8 and above, as it's known to work.

	It is possible to add native support for SSL using the GNU makefile, by passing
	"USE_OPENSSL=1" on the make command line. The libssl and libcrypto will
	automatically be linked with haproxy. Some systems also require libz, so if the
	build fails due to missing symbols such as deflateInit(), then try again with
	"ADDLIB=-lz".

	To link OpenSSL statically against haproxy, build OpenSSL with the no-shared
	keyword and install it to a local directory, so your system is not affected :

	$ export STATICLIBSSL=/tmp/staticlibssl
	$ ./config --prefix=$STATICLIBSSL no-shared
	$ make && make install_sw

	When building haproxy, pass that path via SSL_INC and SSL_LIB to make and
	include additional libs with ADDLIB if needed (in this case for example libdl):

	$ make TARGET=linux26 USE_OPENSSL=1 SSL_INC=$STATICLIBSSL/include SSL_LIB=$STATICLIBSSL/lib ADDLIB=-ldl

	It is also possible to include native support for ZLIB to benefit from HTTP
	compression. For this, pass "USE_ZLIB=1" on the "make" command line and ensure
	that zlib is present on the system.

	By default, the DEBUG variable is set to '-g' to enable debug symbols. It is
	not wise to disable it on uncommon systems, because it's often the only way to
	get a complete core when you need one. Otherwise, you can set DEBUG to '-s' to
	strip the binary.

	For example, I use this to build for Solaris 8 :

	$ make TARGET=solaris CPU=ultrasparc USE_STATIC_PCRE=1

	And I build it this way on OpenBSD or FreeBSD :

	$ gmake TARGET=freebsd USE_PCRE=1 USE_OPENSSL=1 USE_ZLIB=1

	And on a classic Linux with SSL and ZLIB support (eg: Red Hat 5.x) :

	$ make TARGET=linux26 USE_PCRE=1 USE_OPENSSL=1 USE_ZLIB=1

	And on a recent Linux >= 2.6.28 with SSL and ZLIB support :

	$ make TARGET=linux2628 USE_PCRE=1 USE_OPENSSL=1 USE_ZLIB=1

	In order to build a 32-bit binary on an x86_64 Linux system with SSL support
	without support for compression but when OpenSSL requires ZLIB anyway :

	$ make TARGET=linux26 ARCH=i386 USE_OPENSSL=1 ADDLIB=-lz

	The SSL stack supports session cache synchronization between all running
	processes. This involves some atomic operations and synchronization operations
	which come in multiple flavors depending on the system and architecture :

	Atomic operations :
	- internal assembler versions for x86/x86_64 architectures

	- gcc builtins for other architectures. Some architectures might not
	be fully supported or might require a more recent version of gcc.
	If your architecture is not supported, you willy have to either use
	pthread if supported, or to disable the shared cache.

	- pthread (posix threads). Pthreads are very common but inter-process
	support is not that common, and some older operating systems did not
	report an error when enabling multi-process mode, so they used to
	silently fail, possibly causing crashes. Linux's implementation is
	fine. OpenBSD doesn't support them and doesn't build. FreeBSD 9 builds
	and reports an error at runtime, while certain older versions might
	silently fail. Pthreads are enabled using USE_PTHREAD_PSHARED=1.

	Synchronization operations :
	- internal spinlock : this mode is OS-independant, light but will not
	scale well to many processes. However, accesses to the session cache
	are rare enough that this mode could certainly always be used. This
	is the default mode.

	- Futexes, which are Linux-specific highly scalable light weight mutexes
	implemented in user-space with some limited assistance from the kernel.
	This is the default on Linux 2.6 and above and is enabled by passing
	USE_FUTEX=1

	- pthread (posix threads). See above.

	If none of these mechanisms is supported by your platform, you may need to
	build with USE_PRIVATE_CACHE=1 to totally disable SSL cache sharing. Then
	it is better not to run SSL on multiple processes.

	If you need to pass other defines, includes, libraries, etc... then please
	check the Makefile to see which ones will be available in your case, and
	use the USE_* variables in the Makefile.

	AIX 5.3 is known to work with the generic target. However, for the binary to
	also run on 5.2 or earlier, you need to build with DEFINE="-D_MSGQSUPPORT",
	otherwise __fd_select() will be used while not being present in the libc, but
	this is easily addressed using the "aix52" target. If you get build errors
	because of strange symbols or section mismatches, simply remove -g from
	DEBUG_CFLAGS.

	You can easily define your own target with the GNU Makefile. Unknown targets
	are processed with no default option except USE_POLL=default. So you can very
	well use that property to define your own set of options. USE_POLL can even be
	disabled by setting USE_POLL="". For example :

	$ gmake TARGET=tiny USE_POLL="" TARGET_CFLAGS=-fomit-frame-pointer


	2) How to install it
	--------------------

	To install haproxy, you can either copy the single resulting binary to the
	place you want, or run :

	$ sudo make install

	If you're packaging it for another system, you can specify its root directory
	in the usual DESTDIR variable.


	3) How to set it up
	-------------------

	There is some documentation in the doc/ directory :

	- architecture.txt : this is the architecture manual. It is quite old and
	does not tell about the nice new features, but it's still a good starting
	point when you know what you want but don't know how to do it.

	- configuration.txt : this is the configuration manual. It recalls a few
	essential HTTP basic concepts, and details all the configuration file
	syntax (keywords, units). It also describes the log and stats format. It
	is normally always up to date. If you see that something is missing from
	it, please report it as this is a bug. Please note that this file is
	huge and that it's generally more convenient to review Cyril Bonté's
	HTML translation online here :

	http://cbonte.github.io/haproxy-dconv/configuration-1.5.html

	- haproxy-en.txt / haproxy-fr.txt : these are the old outdated docs. You
	should never need them. If you do, then please report what you didn't
	find in the other ones.

	- gpl.txt / lgpl.txt : the copy of the licenses covering the software. See
	the 'LICENSE' file at the top for more information.

	- the rest is mainly for developers.

	There are also a number of nice configuration examples in the "examples"
	directory as well as on several sites and articles on the net which are linked
	to from the haproxy web site.


	4) How to report a bug
	----------------------

	It is possible that from time to time you'll find a bug. A bug is a case where
	what you see is not what is documented. Otherwise it can be a misdesign. If you
	find that something is stupidly design, please discuss it on the list (see the
	"how to contribute" section below). If you feel like you're proceeding right
	and haproxy doesn't obey, then first ask yourself if it is possible that nobody
	before you has even encountered this issue. If it's unlikely, the you probably
	have an issue in your setup. Just in case of doubt, please consult the mailing
	list archives :

	http://marc.info/?l=haproxy

	Otherwise, please try to gather the maximum amount of information to help
	reproduce the issue and send that to the mailing list :

	haproxy@formilux.org

	Please include your configuration and logs. You can mask your IP addresses and
	passwords, we don't need them. But it's essential that you post your config if
	you want people to guess what is happening.

	Also, keep in mind that haproxy is designed to NEVER CRASH. If you see it die
	without any reason, then it definitely is a critical bug that must be reported
	and urgently fixed. It has happened a couple of times in the past, essentially
	on development versions running on new architectures. If you think your setup
	is fairly common, then it is possible that the issue is totally unrelated.
	Anyway, if that happens, feel free to contact me directly, as I will give you
	instructions on how to collect a usable core file, and will probably ask for
	other captures that you'll not want to share with the list.


	5) How to contribute
	--------------------

	Please carefully read the CONTRIBUTING file that comes with the sources. It is
	mandatory.

	-- end