~ubuntu-branches/ubuntu/trusty/haproxy/trusty-backports

« back to all changes in this revision

Viewing changes to README

  • Committer: Bazaar Package Importer
  • Author(s): Arnaud Cornet
  • Date: 2010-06-18 00:42:53 UTC
  • mfrom: (1.1.9 upstream)
  • Revision ID: james.westby@ubuntu.com-20100618004253-ygka2bh6nblkhfj2
Tags: 1.4.8-1
New upstream release.

Show diffs side-by-side

added added

removed removed

Lines of Context:
1
 
                           -------------------
2
 
                             H A - P r o x y
3
 
                             How to build it
4
 
                           -------------------
5
 
                              version 1.3.15
6
 
                              willy tarreau
7
 
                                2008/05/25
8
 
 
 
1
                         ----------------------
 
2
                             HAProxy how-to
 
3
                         ----------------------
 
4
                              version 1.4
 
5
                             willy tarreau
 
6
                               2010/05/09
 
7
 
 
8
 
 
9
1) How to build it
 
10
------------------
9
11
 
10
12
To build haproxy, you will need :
11
 
  - GNU make. Neither Solaris nor OpenBSD's make work with this makefile.
 
13
  - GNU make. Neither Solaris nor OpenBSD's make work with the GNU Makefile.
12
14
    However, specific Makefiles for BSD and OSX are provided.
13
 
  - GCC between 2.91 and 4.3. Others may work, but not tested.
 
15
  - GCC between 2.91 and 4.5.0. Others may work, but not tested.
14
16
  - GNU ld
15
17
 
16
18
Also, you might want to build with libpcre support, which will provide a very
17
 
efficient regex implementation and will also fix some badness on Solaris's one.
 
19
efficient regex implementation and will also fix some badness on Solaris' one.
18
20
 
19
21
To build haproxy, you have to choose your target OS amongst the following ones
20
22
and assign it to the TARGET variable :
24
26
  - linux24e    for Linux 2.4 with support for a working epoll (> 0.21)
25
27
  - linux26     for Linux 2.6 and above
26
28
  - solaris     for Solaris 8 or 10 (others untested)
27
 
  - freebsd     for FreeBSD 5 to 6.2 (others untested)
28
 
  - openbsd     for OpenBSD 3.1 to 3.7 (others untested)
 
29
  - freebsd     for FreeBSD 5 to 8.0 (others untested)
 
30
  - openbsd     for OpenBSD 3.1 to 4.6 (others untested)
29
31
  - cygwin      for Cygwin
30
32
  - generic     for any other OS.
31
33
  - custom      to manually adjust every setting
93
95
also run on 5.2 or earlier, you need to build with DEFINE="-D_MSGQSUPPORT",
94
96
otherwise __fd_select() will be used while not being present in the libc.
95
97
 
 
98
 
 
99
2) How to install it
 
100
--------------------
 
101
 
 
102
To install haproxy, you can either copy the single resulting binary to the
 
103
place you want, or run :
 
104
 
 
105
    $ sudo make install
 
106
 
 
107
If you're packaging it for another system, you can specify its root directory
 
108
in the usual DESTDIR variable.
 
109
 
 
110
 
 
111
3) How to set it up
 
112
-------------------
 
113
 
 
114
There is some documentation in the doc/ directory :
 
115
 
 
116
    - architecture.txt : this is the architecture manual. It is quite old and
 
117
      does not tell about the nice new features, but it's still a good starting
 
118
      point when you know what you want but don't know how to do it.
 
119
 
 
120
    - configuration.txt : this is the configuration manual. It recalls a few
 
121
      essential HTTP basic concepts, and details all the configuration file
 
122
      syntax (keywords, units). It also describes the log and stats format. It
 
123
      is normally always up to date. If you see that something is missing from
 
124
      it, please report it as this is a bug.
 
125
 
 
126
    - haproxy-en.txt / haproxy-fr.txt : these are the old outdated docs. You
 
127
      should never need them. If you do, then please report what you didn't
 
128
      find in the other ones.
 
129
 
 
130
    - gpl.txt / lgpl.txt : the copy of the licenses covering the software. See
 
131
      the 'LICENSE' file at the top for more information.
 
132
 
 
133
    - the rest is mainly for developers.
 
134
 
 
135
There are also a number of nice configuration examples in the "examples"
 
136
directory as well as on several sites and articles on the net which are linked
 
137
to from the haproxy web site.
 
138
 
 
139
 
 
140
4) How to report a bug
 
141
----------------------
 
142
 
 
143
It is possible that from time to time you'll find a bug. A bug is a case where
 
144
what you see is not what is documented. Otherwise it can be a misdesign. If you
 
145
find that something is stupidly design, please discuss it on the list (see the
 
146
"how to contribute" section below). If you feel like you're proceeding right
 
147
and haproxy doesn't obey, then first ask yourself if it is possible that nobody
 
148
before you has even encountered this issue. If it's unlikely, the you probably
 
149
have an issue in your setup. Just in case of doubt, please consult the mailing
 
150
list archives :
 
151
 
 
152
                        http://www.formilux.org/archives/haproxy/
 
153
                        http://marc.info/?l=haproxy
 
154
 
 
155
Otherwise, please try to gather the maximum amount of information to help
 
156
reproduce the issue and send that to the mailing list :
 
157
 
 
158
                        haproxy@formilux.org
 
159
 
 
160
Please include your configuration and logs. You can mask your IP addresses and
 
161
passwords, we don't need them. But it's essential that you post your config if
 
162
you want people to guess what is happening.
 
163
 
 
164
Also, keep in mind that haproxy is designed to NEVER CRASH. If you see it die
 
165
without any reason, then it definitely is a critical bug that must be reported
 
166
and urgently fixed. It has happened a couple of times in the past, essentially
 
167
on development versions running on new architectures. If you think your setup
 
168
is fairly common, then it is possible that the issue is totally unrelated.
 
169
Anyway, if that happens, feel free to contact me directly, as I will give you
 
170
instructions on how to collect a usable core file, and will probably ask for
 
171
other captures that you'll not want to share with the list.
 
172
 
 
173
 
 
174
5) How to contribute
 
175
--------------------
 
176
 
 
177
It is possible that you'll want to add a specific feature to satisfy your needs
 
178
or one of your customers'. Contributions are welcome, however I'm often very
 
179
picky about changes. I will generally reject patches that change massive parts
 
180
of the code, or that touch the core parts without any good reason if those
 
181
changes have not been discussed first.
 
182
 
 
183
The proper place to discuss your changes is the HAProxy Mailing List. There are
 
184
enough skilled readers to catch hazardous mistakes and to suggest improvements.
 
185
You can subscribe to it by sending an empty e-mail at the following address :
 
186
 
 
187
                        haproxy+subscribe@formilux.org
 
188
 
 
189
If your work is very confidential and you can't publicly discuss it, you can
 
190
also mail me directly about it, but your mail may be waiting several days in
 
191
the queue before you get a response.
 
192
 
 
193
If you'd like a feature to be added but you think you don't have the skills to
 
194
implement it yourself, you should follow these steps :
 
195
 
 
196
    1. discuss the feature on the mailing list. It is possible that someone
 
197
       else has already implemented it, or that someone will tell you how to
 
198
       proceed without it, or even why not to do it. It is also possible that
 
199
       in fact it's quite easy to implement and people will guide you through
 
200
       the process. That way you'll finally have YOUR patch merged, providing
 
201
       the feature YOU need.
 
202
 
 
203
    2. if you really can't code it yourself after discussing it, then you may
 
204
       consider contacting someone to do the job for you. Some people on the
 
205
       list might be OK with trying to do it. Otherwise, you can check the list
 
206
       of contributors at the URL below, some of the regular contributors may
 
207
       be able to do the work, probably not for free but their time is as much
 
208
       valuable as yours after all, you can't eat the cake and have it too.
 
209
 
 
210
The list of past and regular contributors is available below. It lists not only
 
211
significant code contributions (features, fixes), but also time or money
 
212
donations :
 
213
 
 
214
                        http://haproxy.1wt.eu/contrib.html
 
215
 
 
216
Note to contributors: it's very handy when patches comes with a properly
 
217
formated subject. Try to put one of the following words between brackets
 
218
to indicate the importance of the patch followed if possible by a single
 
219
word indicating what subsystem is affected, then by a short description :
 
220
 
 
221
  [BUG]      fix for a minor or medium-level bug. When a few of these ones are
 
222
             available, a new maintenance release is emitted.
 
223
 
 
224
  [CRITICAL] medium-term reliability or security is at risk, an upgrade is
 
225
             absolutely required. A maintenance release may be emitted even if
 
226
             only one of these bugs are fixed.
 
227
 
 
228
  [CLEANUP]  code cleanup, silence of warnings, etc... theorically no impact.
 
229
             These patches will rarely be seen in stable branches, though they
 
230
             may appear when they remove some annoyance.
 
231
 
 
232
  [MINOR]    minor change, very low risk of impact. It is often the case for
 
233
             code additions that don't touch live code.
 
234
 
 
235
  [MEDIUM]   medium risk, may cause unexpected regressions of low importance or
 
236
             which may quickly be discovered.
 
237
 
 
238
  [MAJOR]    major risk of hidden regression. This happens when I rearrange
 
239
             large parts of code, when I play with timeouts, with variable
 
240
             initializations, etc... We should only exceptionally find such
 
241
             patches in stable branches.
 
242
 
 
243
  [OPTIM]    some code was optimised. Sometimes if the regression risk is very
 
244
             low and the gains significant, such patches may be merged in the
 
245
             stable branch.
 
246
 
 
247
  [DOC]      documentation updates or fixes only. No code is affected, no need
 
248
             to upgrade. These patches can also be sent right after a new
 
249
             feature, to document it.
 
250
 
 
251
  [TESTS]    added regression testing configuration files or scripts
 
252
 
 
253
  [BUILD]    fix build issues. If you could build, no upgrade required.
 
254
 
 
255
  [LICENSE]  licensing updates (may impact distro packagers)
 
256
 
 
257
  [RELEASE]  release a new version (development version or stable version)
 
258
 
 
259
  [PATCH]    any other patch which could not be qualified with the tags above.
 
260
 
 
261
 
 
262
The tags are not rigid, and I reserve the right to change them when merging the
 
263
patch. It may happen that a same patch has a different tag in two distinct
 
264
branches. The reason is that a bug in one branch may just be a cleanup in the
 
265
other one because the code cannot be triggered.
 
266
 
 
267
Examples of messages :
 
268
       - [DOC] document options forwardfor to logasap
 
269
       - [BUG] stats: connection reset counters must be plain ascii, not HTML
 
270
       - [MEDIUM] checks: support multi-packet health check responses
 
271
       - [RELEASE] Released version 1.4.2
 
272
 
 
273
For a more efficient interaction between the mainline code and your code, I can
 
274
only strongly encourage you to try the Git version control system :
 
275
 
 
276
                        http://git-scm.com/
 
277
 
 
278
It's very fast, lightweight and lets you undo/redo your work as often as you
 
279
want, without making your mistakes visible to the rest of the world. It will
 
280
definitely help you contribute quality code and take other people's feedback
 
281
in consideration. In order to clone the HAProxy Git repository :
 
282
 
 
283
    $ git clone http://git.1wt.eu/git/haproxy-1.4.git    (stable 1.4)
 
284
    $ git clone http://git.1wt.eu/git/haproxy.git/       (development)
 
285
 
 
286
If you decide to use Git for your developments, then your commit messages will
 
287
have the subject line in the format described above, then the whole description
 
288
of your work (mainly why you did it) will be in the body. You can directly send
 
289
your commits to the mailing list, the format is convenient to read and process.
 
290
 
96
291
-- end