Quantcast
Channel: Serverphorums.com - HAProxy
Viewing all 11674 articles
Browse latest View live

Re: 'show table' is unreliable?

$
0
0
Greetings,

Ah, is the stats socket also bound to one process? For example "stats
socket /var/run/haproxy.sock mode 0600 level admin process 4" to bind it
to process 4.

Otherwise the process your querying for the stats will bounce around,
even if the process with the table doesn't.

- Chad

On 03/11/2016 05:29 PM, Robert Samuel Newson wrote:
> ah, yes, nbproc of 2 here, but I should be clear. The stick tables are in a proxy pinned to one single process, the other is used to handle TLS decoding.
>
>> On 11 Mar 2016, at 18:27, Chad Lavoie <clavoie@haproxy.com> wrote:
>>
>> Greetings,
>>
>> That should have been "Do you have nbproc set and more then 1?", sorry.
>>
>> - Chad
>>
>> On 03/11/2016 01:17 PM, Chad Lavoie wrote:
>>> Greetings,
>>>
>>> Do you have nbproc set or more then 1?
>>>
>>> If so, then each thread has its own stick table set; and depending on what thread handles it the values will differ.
>>>
>>> Individual frontends can be set to a specific thread with bind-process (or for SSL a frontend specifically for SSL termination can be made). If that is the issue your seeing and you want more examples in that direction let me know what your use-case looks like and I'll go into more details there.
>>>
>>> - Chad
>>>
>>> On 03/11/2016 12:28 PM, Robert Samuel Newson wrote:
>>>> Hi,
>>>>
>>>> I'm using haproxy 1.6.3 and think I've uncovered an issue.
>>>>
>>>> I use the stick table feature and as you can see from below, items appear and disappear randomly, these samples were taken less than a second apart. Obviously the items in the middle have at least 56 seconds remaining before expiration, so should have been in all three samples. They reappear if I keep sampling, in seemingly random subsets.
>>>>
>>>> I can't easily tell if this just a display issue (i.e 'show table' has the bug) or whether the table behaves as if it's empty when show table shows it empty.
>>>>
>>>> Any advice?
>>>>
>>>>> echo "show table lookup" | socat /var/haproxy.sock -
>>>> # table: lookup, type: string, size:51200, used:0
>>>>
>>>>> echo "show table lookup" | socat /var/haproxy.sock -
>>>> # table: lookup, type: string, size:51200, used:3
>>>> 0x3c1d9ec: key=user1 use=0 exp=56035 gpc0_rate(1000)=0
>>>> 0x3c0ff0c: key=user2 use=0 exp=58786 gpc0_rate(1000)=0
>>>> 0x3c41b2c: key=user3 use=0 exp=59737 gpc0_rate(1000)=0
>>>>
>>>>> echo "show table lookup" | socat /var/haproxy.sock -
>>>> # table: lookup, type: string, size:51200, used:0
>>>>
>>>>
>>>
>

Re: 'show table' is unreliable?

$
0
0
yep, I bound everything but I still get warnings. There's a bug that might be related where binding stats doesn't work with stats bind-process, perhaps that's my problem?

> On 11 Mar 2016, at 22:33, Chad Lavoie <clavoie@haproxy.com> wrote:
>
> Greetings,
>
> Ah, is the stats socket also bound to one process? For example "stats socket /var/run/haproxy.sock mode 0600 level admin process 4" to bind it to process 4.
>
> Otherwise the process your querying for the stats will bounce around, even if the process with the table doesn't.
>
> - Chad
>
> On 03/11/2016 05:29 PM, Robert Samuel Newson wrote:
>> ah, yes, nbproc of 2 here, but I should be clear. The stick tables are in a proxy pinned to one single process, the other is used to handle TLS decoding.
>>
>>> On 11 Mar 2016, at 18:27, Chad Lavoie <clavoie@haproxy.com> wrote:
>>>
>>> Greetings,
>>>
>>> That should have been "Do you have nbproc set and more then 1?", sorry.
>>>
>>> - Chad
>>>
>>> On 03/11/2016 01:17 PM, Chad Lavoie wrote:
>>>> Greetings,
>>>>
>>>> Do you have nbproc set or more then 1?
>>>>
>>>> If so, then each thread has its own stick table set; and depending on what thread handles it the values will differ.
>>>>
>>>> Individual frontends can be set to a specific thread with bind-process (or for SSL a frontend specifically for SSL termination can be made). If that is the issue your seeing and you want more examples in that direction let me know what your use-case looks like and I'll go into more details there.
>>>>
>>>> - Chad
>>>>
>>>> On 03/11/2016 12:28 PM, Robert Samuel Newson wrote:
>>>>> Hi,
>>>>>
>>>>> I'm using haproxy 1.6.3 and think I've uncovered an issue.
>>>>>
>>>>> I use the stick table feature and as you can see from below, items appear and disappear randomly, these samples were taken less than a second apart. Obviously the items in the middle have at least 56 seconds remaining before expiration, so should have been in all three samples. They reappear if I keep sampling, in seemingly random subsets.
>>>>>
>>>>> I can't easily tell if this just a display issue (i.e 'show table' has the bug) or whether the table behaves as if it's empty when show table shows it empty.
>>>>>
>>>>> Any advice?
>>>>>
>>>>>> echo "show table lookup" | socat /var/haproxy.sock -
>>>>> # table: lookup, type: string, size:51200, used:0
>>>>>
>>>>>> echo "show table lookup" | socat /var/haproxy.sock -
>>>>> # table: lookup, type: string, size:51200, used:3
>>>>> 0x3c1d9ec: key=user1 use=0 exp=56035 gpc0_rate(1000)=0
>>>>> 0x3c0ff0c: key=user2 use=0 exp=58786 gpc0_rate(1000)=0
>>>>> 0x3c41b2c: key=user3 use=0 exp=59737 gpc0_rate(1000)=0
>>>>>
>>>>>> echo "show table lookup" | socat /var/haproxy.sock -
>>>>> # table: lookup, type: string, size:51200, used:0
>>>>>
>>>>>
>>>>
>>
>

Re: Only using map file when an entry exists

$
0
0
Hello Neil,

You seem to have missed my answer, so I am gonna top post this time :)

http-request redirect location
%[hdr(host),map(/etc/haproxy/redirect_host.map)] code 301 if {
hdr(host),map(/etc/haproxy/redirect_host.map) -m found }

Regards,
Nenad

On 03/11/2016 11:32 PM, Neil - HAProxy List wrote:
> Hello
>
> I've left a little time and no one has said anything more so time for me
> to act and submit a patch.
>
> I want to make functions that can be used in acls and take a map and
> provide has_key and, for completeness, has_value
>
> Are those names uncontroversial/ suitable and, i really hope, is this
> unnecessary as it already exists.
>
> I'm more that a little surprised to find myself the first to want this
>
> Cheers
>
> Neil
>
> On 11 Mar 2016 22:16, "Neil" <neil@iamafreeman.com
> <mailto:neil@iamafreeman.com>> wrote:
>
> Hello
>
> I've left a little time and no one has said anything more so time
> for me to act and submit a patch.
>
> I want to make functions that can be used in acls and take a map and
> provide has_key and, for completeness, has_value
>
> Are those names uncontroversia/ suitablel and, i really hope, is
> this unnecessary as it already exists.
>
> I'm more that a little sutprised to find myself the first to want this
>
> Cheers
>
> Neil
>
> On 3 Mar 2016 18:08, "Neil - HAProxy List"
> <maillist-haproxy@iamafreeman.com
> <mailto:maillist-haproxy@iamafreeman.com>> wrote:
>
> Thanks Conrad,
>
> That sort of thing looks better that what I had, and I'll give
> it a go.
>
> I still think this is a bit long winded syntax for something
> that probably quite a common things to want to do? A
> map_contains type boolean function still seems like a good to have?
>
> Thanks
>
> Neil
>
> On 3 March 2016 at 13:05, Conrad Hoffmann <conrad@soundcloud.com
> <mailto:conrad@soundcloud.com>> wrote:
>
> If you are using haproxy >=1.6, you might be able to do
> something like this:
>
> acl no_redir %[req.redir] -m str NO_REDIR
> http-request set-var(req.redir) \
> %[hdr(host),map(/etc/haproxy/redirect_host.map,NO_REDIR)]
> http-request redirect location %[req.redir] code 301 if
> !no_redir
>
> This is completely made up and untested, but I hope you get
> the idea.
> Avoids a second map lookup altogether, but also map lookups
> are quite fast,
> so unless you map is huge you don't really need to worry
> about this. Also,
> double negation, but this is just to give you some idea
>
> Cheers,
> Conrad
> --
> Conrad Hoffmann
> Traffic Engineer
>
> SoundCloud Ltd. | Rheinsberger Str. 76/77, 10115 Berlin, Germany
>
> Managing Director: Alexander Ljung | Incorporated in England
> & Wales
> with Company No. 6343600 | Local Branch Office | AG
> Charlottenburg |
> HRB 110657B
>
>

News about upcoming haproxy releases

$
0
0
Hi all,

I'm seeing some people rightfully complain that 1.6.3 is quite old and
still plagued with some severe bugs for which fixes have been queued for
some time. Time flies fast and bugs are not fixed as quickly as I'd like.

So I'll release 1.6.4 and 1.5.16 with what we have right now. I think
1.5 is up to date (I'll just have to recheck) but no known bug is pending
on it.

For 1.6 we still have several annoying bugs pending :
- peers can desynchronize due to a design issue in how the applets
work internally. Some events are not properly passed to the peers
applet so it depends on the timing. This is the most painful thing
to fix as it requires some time concentrated on the issue.

- gpc0_rate would report crap when peers are configured. It could be
a side effect of the bug above, I don't know yet.

- I found that aborted connections can be offered to connections waiting
in queue when a server maxconn is reached and the client aborts. It's
not critical but not fun when using http-reuse.

I'll work on this this week-end. I have a kernel to release first then
a minor build warning to fix in 1.7, 1.6 and 1.6, I'll backport into
1.5 any possibly missing fix, and then I can release 1.7-dev2, 1.6.4
and 1.5.16.

If anyone has any fix waiting to be merged that I could have missed,
please do not hesitate to resend it before tomorrow (I already have
yours Andreas). I had an e-mail issue for all this week after I
replaced my machine and forgot to properly configure the mailer. I
resent what was in my queue but maybe some people are still waiting
for some responses from me that were lost.

On the more positive side of things, today for the first time we're
more than 1000 permanent subscribers on this list (1001 to be precise).
Oh I know that after this long e-mail I'll see one or two unsubscriptions
from people who prefer daily spam to monthly informative e-mails :-)

But anyway it's a nice milestone. I tried to imagine something original
to celebrate the event, and thought we could send an Aloha Pocket to the
two persons who subscribed today and made us cross this new limit. I'll
contact them off-list to get their address, hoping they'll have as much
fun as I do with a very small load balancer that fits in the hand and is
powered over USB :-) Some doc still remains to be done but it won't take
long.

Stay tuned and have a nice week-end,
Willy

Re: 'show table' is unreliable?

$
0
0
Hi,

Le 11/03/2016 23:36, Robert Samuel Newson a écrit :
> yep, I bound everything but I still get warnings. There's a bug that might be related where binding stats doesn't work with stats bind-process, perhaps that's my problem?

Yes, there was a bug that will be fixed in next releases, which should
arrive very soon.
As a workaround to "stats bind-process", you can add "process <n>" on
the "stats socket" line.

For reference :
http://www.haproxy.org/git?p=haproxy.git;a=commit;h=0618195a114098c93e2712b5507dc9a3eeae8e8b

(Please, avoid top posting)

>
>> On 11 Mar 2016, at 22:33, Chad Lavoie <clavoie@haproxy.com> wrote:
>>
>> Greetings,
>>
>> Ah, is the stats socket also bound to one process? For example "stats socket /var/run/haproxy.sock mode 0600 level admin process 4" to bind it to process 4.
>>
>> Otherwise the process your querying for the stats will bounce around, even if the process with the table doesn't.
>>
>> - Chad
>>
>> On 03/11/2016 05:29 PM, Robert Samuel Newson wrote:
>>> ah, yes, nbproc of 2 here, but I should be clear. The stick tables are in a proxy pinned to one single process, the other is used to handle TLS decoding.
>>>
>>>> On 11 Mar 2016, at 18:27, Chad Lavoie <clavoie@haproxy.com> wrote:
>>>>
>>>> Greetings,
>>>>
>>>> That should have been "Do you have nbproc set and more then 1?", sorry.
>>>>
>>>> - Chad
>>>>
>>>> On 03/11/2016 01:17 PM, Chad Lavoie wrote:
>>>>> Greetings,
>>>>>
>>>>> Do you have nbproc set or more then 1?
>>>>>
>>>>> If so, then each thread has its own stick table set; and depending on what thread handles it the values will differ.
>>>>>
>>>>> Individual frontends can be set to a specific thread with bind-process (or for SSL a frontend specifically for SSL termination can be made). If that is the issue your seeing and you want more examples in that direction let me know what your use-case looks like and I'll go into more details there.
>>>>>
>>>>> - Chad
>>>>>
>>>>> On 03/11/2016 12:28 PM, Robert Samuel Newson wrote:
>>>>>> Hi,
>>>>>>
>>>>>> I'm using haproxy 1.6.3 and think I've uncovered an issue.
>>>>>>
>>>>>> I use the stick table feature and as you can see from below, items appear and disappear randomly, these samples were taken less than a second apart. Obviously the items in the middle have at least 56 seconds remaining before expiration, so should have been in all three samples. They reappear if I keep sampling, in seemingly random subsets.
>>>>>>
>>>>>> I can't easily tell if this just a display issue (i.e 'show table' has the bug) or whether the table behaves as if it's empty when show table shows it empty.
>>>>>>
>>>>>> Any advice?
>>>>>>
>>>>>>> echo "show table lookup" | socat /var/haproxy.sock -
>>>>>> # table: lookup, type: string, size:51200, used:0
>>>>>>
>>>>>>> echo "show table lookup" | socat /var/haproxy.sock -
>>>>>> # table: lookup, type: string, size:51200, used:3
>>>>>> 0x3c1d9ec: key=user1 use=0 exp=56035 gpc0_rate(1000)=0
>>>>>> 0x3c0ff0c: key=user2 use=0 exp=58786 gpc0_rate(1000)=0
>>>>>> 0x3c41b2c: key=user3 use=0 exp=59737 gpc0_rate(1000)=0
>>>>>>
>>>>>>> echo "show table lookup" | socat /var/haproxy.sock -
>>>>>> # table: lookup, type: string, size:51200, used:0
>>>>>>
>>>>>>
>>>>>
>>>
>>
>
>


--
Cyril Bonté

Re: 'show table' is unreliable?

$
0
0
ok, I'll try that, and looking forward to a 1.6.4, quite a few good fixes since 1.6.3.

B.

> On 11 Mar 2016, at 22:39, Cyril Bonté <cyril.bonte@free.fr> wrote:
>
> Hi,
>
> Le 11/03/2016 23:36, Robert Samuel Newson a écrit :
>> yep, I bound everything but I still get warnings. There's a bug that might be related where binding stats doesn't work with stats bind-process, perhaps that's my problem?
>
> Yes, there was a bug that will be fixed in next releases, which should arrive very soon.
> As a workaround to "stats bind-process", you can add "process <n>" on the "stats socket" line.
>
> For reference :
> http://www.haproxy.org/git?p=haproxy.git;a=commit;h=0618195a114098c93e2712b5507dc9a3eeae8e8b
>
> (Please, avoid top posting)
>
>>
>>> On 11 Mar 2016, at 22:33, Chad Lavoie <clavoie@haproxy.com> wrote:
>>>
>>> Greetings,
>>>
>>> Ah, is the stats socket also bound to one process? For example "stats socket /var/run/haproxy.sock mode 0600 level admin process 4" to bind it to process 4.
>>>
>>> Otherwise the process your querying for the stats will bounce around, even if the process with the table doesn't.
>>>
>>> - Chad
>>>
>>> On 03/11/2016 05:29 PM, Robert Samuel Newson wrote:
>>>> ah, yes, nbproc of 2 here, but I should be clear. The stick tables are in a proxy pinned to one single process, the other is used to handle TLS decoding.
>>>>
>>>>> On 11 Mar 2016, at 18:27, Chad Lavoie <clavoie@haproxy.com> wrote:
>>>>>
>>>>> Greetings,
>>>>>
>>>>> That should have been "Do you have nbproc set and more then 1?", sorry.
>>>>>
>>>>> - Chad
>>>>>
>>>>> On 03/11/2016 01:17 PM, Chad Lavoie wrote:
>>>>>> Greetings,
>>>>>>
>>>>>> Do you have nbproc set or more then 1?
>>>>>>
>>>>>> If so, then each thread has its own stick table set; and depending on what thread handles it the values will differ.
>>>>>>
>>>>>> Individual frontends can be set to a specific thread with bind-process (or for SSL a frontend specifically for SSL termination can be made). If that is the issue your seeing and you want more examples in that direction let me know what your use-case looks like and I'll go into more details there.
>>>>>>
>>>>>> - Chad
>>>>>>
>>>>>> On 03/11/2016 12:28 PM, Robert Samuel Newson wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> I'm using haproxy 1.6.3 and think I've uncovered an issue.
>>>>>>>
>>>>>>> I use the stick table feature and as you can see from below, items appear and disappear randomly, these samples were taken less than a second apart. Obviously the items in the middle have at least 56 seconds remaining before expiration, so should have been in all three samples. They reappear if I keep sampling, in seemingly random subsets.
>>>>>>>
>>>>>>> I can't easily tell if this just a display issue (i.e 'show table' has the bug) or whether the table behaves as if it's empty when show table shows it empty.
>>>>>>>
>>>>>>> Any advice?
>>>>>>>
>>>>>>>> echo "show table lookup" | socat /var/haproxy.sock -
>>>>>>> # table: lookup, type: string, size:51200, used:0
>>>>>>>
>>>>>>>> echo "show table lookup" | socat /var/haproxy.sock -
>>>>>>> # table: lookup, type: string, size:51200, used:3
>>>>>>> 0x3c1d9ec: key=user1 use=0 exp=56035 gpc0_rate(1000)=0
>>>>>>> 0x3c0ff0c: key=user2 use=0 exp=58786 gpc0_rate(1000)=0
>>>>>>> 0x3c41b2c: key=user3 use=0 exp=59737 gpc0_rate(1000)=0
>>>>>>>
>>>>>>>> echo "show table lookup" | socat /var/haproxy.sock -
>>>>>>> # table: lookup, type: string, size:51200, used:0
>>>>>>>
>>>>>>>
>>>>>>
>>>>
>>>
>>
>>
>
>
> --
> Cyril Bonté

Re: 'show table' is unreliable?

$
0
0
Robert,

On Fri, Mar 11, 2016 at 10:36:14PM +0000, Robert Samuel Newson wrote:
> yep, I bound everything but I still get warnings. There's a bug that might be
> related where binding stats doesn't work with stats bind-process, perhaps
> that's my problem?

Chad is right to insist on this, because Cyril recently fixed a related
bug as you can see below :

commit 0618195a114098c93e2712b5507dc9a3eeae8e8b
Author: Cyril Bonté <cyril.bonte@free.fr>
Date: Wed Feb 24 00:14:54 2016 +0100

BUG/MEDIUM: stats: stats bind-process doesn't propagate the process mask correctly

With nbproc > 1, it is possible to specify on which process the stats socket
will be bound using "stats bind-process", but the behaviour was not correct,
ignoring the value in some configurations.
(...)

There's a difference between "stats bind-process 1" (which indicates that the
stats frontend is limited to process 1 and did not work as expected in 1.6.3),
and "stats socket ... process 1" which indicates that this specific socket is
only on process 1 and which used to already work in 1.6.3.

In case of doubt, just put the two in your config. You shouldn't have
any warning and it must work.

regards,
Willy

Re: Question about build HAProxy for Solaris 11

$
0
0
Thanks a lot for the response. I am getting an account with the website you
provided to get the missing libraries.

The feature I am looking for is the color variation between enabled and
soft start. I left a prod server enabled but not soft started all night. It
was my fault for not noticing there was no traffic through the server. The
new version with different colors will prevent this in the future. Glad it
was added.

Thanks again.

Sam

[PATCH] BUG/MINOR: log: GMT offset not updated when entering/leaving DST

$
0
0
[Please use the attached patch, my version of Thunderbird replaces tabs by spaces]

GMT offset used in local time formats was computed at startup, but was not updated when DST status changed while running.

For example these two RFC5424 syslog traces where emitted 5 seconds apart, just before and after DST changed:
<14>1 2016-03-27T01:59:58+01:00 bunch-VirtualBox haproxy 2098 - - Connect ...
<14>1 2016-03-27T03:00:03+01:00 bunch-VirtualBox haproxy 2098 - - Connect ...

It looked like they were emitted more than 1 hour apart, unlike with the fix:
<14>1 2016-03-27T01:59:58+01:00 bunch-VirtualBox haproxy 3381 - - Connect ...
<14>1 2016-03-27T03:00:03+02:00 bunch-VirtualBox haproxy 3381 - - Connect ...

This patch should be backported to 1.6 and partially to 1.5 (no fix needed in log.c).
---
include/common/standard.h | 9 ++++++---
src/haproxy.c | 5 -----
src/log.c | 4 +++-
src/standard.c | 34 +++++++++++++++++++++++++++++++++-
4 files changed, 42 insertions(+), 10 deletions(-)

diff --git a/include/common/standard.h b/include/common/standard.h
index 9abdb06..353d0b0 100644
--- a/include/common/standard.h
+++ b/include/common/standard.h
@@ -860,9 +860,6 @@ char *human_time(int t, short hz_div);

extern const char *monthname[];

-/* numeric timezone (that is, the hour and minute offset from UTC) */
-char localtimezone[6];
-
/* date2str_log: write a date in the format :
* sprintf(str, "%02d/%s/%04d:%02d:%02d:%02d.%03d",
* tm.tm_mday, monthname[tm.tm_mon], tm.tm_year+1900,
@@ -873,6 +870,12 @@ char localtimezone[6];
*/
char *date2str_log(char *dest, struct tm *tm, struct timeval *date, size_t size);

+/* Return the GMT offset for a specific local time.
+ * The string returned has the same format as returned by strftime(... "%z", tm).
+ * Offsets are kept in an internal cache for better performances.
+ */
+const char *get_gmt_offset(struct tm *tm);
+
/* gmt2str_log: write a date in the format :
* "%02d/%s/%04d:%02d:%02d:%02d +0000" without using snprintf
* return a pointer to the last char written (\0) or
diff --git a/src/haproxy.c b/src/haproxy.c
index 4d38d27..aada213 100644
--- a/src/haproxy.c
+++ b/src/haproxy.c
@@ -562,7 +562,6 @@ void init(int argc, char **argv)
struct wordlist *wl;
char *progname;
char *change_dir = NULL;
- struct tm curtime;
struct proxy *px;

chunk_init(&trash, malloc(global.tune.bufsize), global.tune.bufsize);
@@ -593,10 +592,6 @@ void init(int argc, char **argv)

srandom(now_ms - getpid());

- /* Get the numeric timezone. */
- get_localtime(start_date.tv_sec, &curtime);
- strftime(localtimezone, 6, "%z", &curtime);
-
init_log();
signal_init();
if (init_acl() != 0)
diff --git a/src/log.c b/src/log.c
index 3e25bc7..ab38353 100644
--- a/src/log.c
+++ b/src/log.c
@@ -970,6 +970,7 @@ static char *update_log_hdr_rfc5424(const time_t time)
{
static long tvsec;
static char *dataptr = NULL; /* backup of last end of header, NULL first time */
+ const char *gmt_offset;

if (unlikely(time != tvsec || dataptr == NULL)) {
/* this string is rebuild only once a second */
@@ -978,12 +979,13 @@ static char *update_log_hdr_rfc5424(const time_t time)

tvsec = time;
get_localtime(tvsec, &tm);
+ gmt_offset = get_gmt_offset(&tm);

hdr_len = snprintf(logheader_rfc5424, global.max_syslog_len,
"<<<<>1 %4d-%02d-%02dT%02d:%02d:%02d%.3s:%.2s %s ",
tm.tm_year+1900, tm.tm_mon+1, tm.tm_mday,
tm.tm_hour, tm.tm_min, tm.tm_sec,
- localtimezone, localtimezone+3,
+ gmt_offset, gmt_offset+3,
global.log_send_hostname ? global.log_send_hostname : hostname);
/* WARNING: depending upon implementations, snprintf may return
* either -1 or the number of bytes that would be needed to store
diff --git a/src/standard.c b/src/standard.c
index 30883d7..52ddaa2 100644
--- a/src/standard.c
+++ b/src/standard.c
@@ -2550,6 +2550,35 @@ char *date2str_log(char *dst, struct tm *tm, struct timeval *date, size_t size)
return dst;
}

+/* Return the GMT offset for a specific local time.
+ * The string returned has the same format as returned by strftime(... "%z", tm).
+ * Offsets are kept in an internal cache for better performances.
+ */
+const char *get_gmt_offset(struct tm *tm)
+{
+ /* Cache offsets from GMT (depending on whether DST is active or not) */
+ static char gmt_offsets[2][5+1] = { "", "" };
+
+ int old_isdst = tm->tm_isdst;
+ char *gmt_offset;
+
+ /* Pretend DST not active if its status is unknown, or strftime() will return an empty string for "%z" */
+ if (tm->tm_isdst < 0) {
+ tm->tm_isdst = 0;
+ }
+
+ /* Fetch the offset and initialize it if needed */
+ gmt_offset = gmt_offsets[tm->tm_isdst & 0x01];
+ if (unlikely(!*gmt_offset)) {
+ strftime(gmt_offset, 5+1, "%z", tm);
+ }
+
+ /* Restore previous DST flag */
+ tm->tm_isdst = old_isdst;
+
+ return gmt_offset;
+}
+
/* gmt2str_log: write a date in the format :
* "%02d/%s/%04d:%02d:%02d:%02d +0000" without using snprintf
* return a pointer to the last char written (\0) or
@@ -2590,9 +2619,12 @@ char *gmt2str_log(char *dst, struct tm *tm, size_t size)
*/
char *localdate2str_log(char *dst, struct tm *tm, size_t size)
{
+ const char *gmt_offset;
if (size < 27) /* the size is fixed: 26 chars + \0 */
return NULL;

+ gmt_offset = get_gmt_offset(tm);
+
dst = utoa_pad((unsigned int)tm->tm_mday, dst, 3); // day
*dst++ = '/';
memcpy(dst, monthname[tm->tm_mon], 3); // month
@@ -2606,7 +2638,7 @@ char *localdate2str_log(char *dst, struct tm *tm, size_t size)
*dst++ = ':';
dst = utoa_pad((unsigned int)tm->tm_sec, dst, 3); // secondes
*dst++ = ' ';
- memcpy(dst, localtimezone, 5); // timezone
+ memcpy(dst, gmt_offset, 5); // Offset from local time to GMT
dst += 5;
*dst = '\0';

--
2.5.0

From 530b5340ab0e45d86a99e21f080a05e9a71beebd Mon Sep 17 00:00:00 2001
From: Benoit GARNIER <chezbunch+haproxy@gmail.com>
Date: Sun, 27 Mar 2016 11:08:03 +0200
Subject: [PATCH] BUG/MINOR: log: GMT offset not updated when entering/leaving DST

GMT offset used in local time formats was computed at startup, but was not updated when DST status changed while running.

For example these two RFC5424 syslog traces where emitted 5 seconds apart, just before and after DST changed:
<14>1 2016-03-27T01:59:58+01:00 bunch-VirtualBox haproxy 2098 - - Connect ...
<14>1 2016-03-27T03:00:03+01:00 bunch-VirtualBox haproxy 2098 - - Connect ...

It looked like they were emitted more than 1 hour apart, unlike with the fix:
<14>1 2016-03-27T01:59:58+01:00 bunch-VirtualBox haproxy 3381 - - Connect ...
<14>1 2016-03-27T03:00:03+02:00 bunch-VirtualBox haproxy 3381 - - Connect ...

This patch should be backported to 1.6 and partially to 1.5 (no fix needed in log.c).
---
include/common/standard.h | 9 ++++++---
src/haproxy.c | 5 -----
src/log.c | 4 +++-
src/standard.c | 34 +++++++++++++++++++++++++++++++++-
4 files changed, 42 insertions(+), 10 deletions(-)

diff --git a/include/common/standard.h b/include/common/standard.h
index 9abdb06..353d0b0 100644
--- a/include/common/standard.h
+++ b/include/common/standard.h
@@ -860,9 +860,6 @@ char *human_time(int t, short hz_div);

extern const char *monthname[];

-/* numeric timezone (that is, the hour and minute offset from UTC) */
-char localtimezone[6];
-
/* date2str_log: write a date in the format :
* sprintf(str, "%02d/%s/%04d:%02d:%02d:%02d.%03d",
* tm.tm_mday, monthname[tm.tm_mon], tm.tm_year+1900,
@@ -873,6 +870,12 @@ char localtimezone[6];
*/
char *date2str_log(char *dest, struct tm *tm, struct timeval *date, size_t size);

+/* Return the GMT offset for a specific local time.
+ * The string returned has the same format as returned by strftime(... "%z", tm).
+ * Offsets are kept in an internal cache for better performances.
+ */
+const char *get_gmt_offset(struct tm *tm);
+
/* gmt2str_log: write a date in the format :
* "%02d/%s/%04d:%02d:%02d:%02d +0000" without using snprintf
* return a pointer to the last char written (\0) or
diff --git a/src/haproxy.c b/src/haproxy.c
index 4d38d27..aada213 100644
--- a/src/haproxy.c
+++ b/src/haproxy.c
@@ -562,7 +562,6 @@ void init(int argc, char **argv)
struct wordlist *wl;
char *progname;
char *change_dir = NULL;
- struct tm curtime;
struct proxy *px;

chunk_init(&trash, malloc(global.tune.bufsize), global.tune.bufsize);
@@ -593,10 +592,6 @@ void init(int argc, char **argv)

srandom(now_ms - getpid());

- /* Get the numeric timezone. */
- get_localtime(start_date.tv_sec, &curtime);
- strftime(localtimezone, 6, "%z", &curtime);
-
init_log();
signal_init();
if (init_acl() != 0)
diff --git a/src/log.c b/src/log.c
index 3e25bc7..ab38353 100644
--- a/src/log.c
+++ b/src/log.c
@@ -970,6 +970,7 @@ static char *update_log_hdr_rfc5424(const time_t time)
{
static long tvsec;
static char *dataptr = NULL; /* backup of last end of header, NULL first time */
+ const char *gmt_offset;

if (unlikely(time != tvsec || dataptr == NULL)) {
/* this string is rebuild only once a second */
@@ -978,12 +979,13 @@ static char *update_log_hdr_rfc5424(const time_t time)

tvsec = time;
get_localtime(tvsec, &tm);
+ gmt_offset = get_gmt_offset(&tm);

hdr_len = snprintf(logheader_rfc5424, global.max_syslog_len,
"<<<<>1 %4d-%02d-%02dT%02d:%02d:%02d%.3s:%.2s %s ",
tm.tm_year+1900, tm.tm_mon+1, tm.tm_mday,
tm.tm_hour, tm.tm_min, tm.tm_sec,
- localtimezone, localtimezone+3,
+ gmt_offset, gmt_offset+3,
global.log_send_hostname ? global.log_send_hostname : hostname);
/* WARNING: depending upon implementations, snprintf may return
* either -1 or the number of bytes that would be needed to store
diff --git a/src/standard.c b/src/standard.c
index 30883d7..52ddaa2 100644
--- a/src/standard.c
+++ b/src/standard.c
@@ -2550,6 +2550,35 @@ char *date2str_log(char *dst, struct tm *tm, struct timeval *date, size_t size)
return dst;
}

+/* Return the GMT offset for a specific local time.
+ * The string returned has the same format as returned by strftime(... "%z", tm).
+ * Offsets are kept in an internal cache for better performances.
+ */
+const char *get_gmt_offset(struct tm *tm)
+{
+ /* Cache offsets from GMT (depending on whether DST is active or not) */
+ static char gmt_offsets[2][5+1] = { "", "" };
+
+ int old_isdst = tm->tm_isdst;
+ char *gmt_offset;
+
+ /* Pretend DST not active if its status is unknown, or strftime() will return an empty string for "%z" */
+ if (tm->tm_isdst < 0) {
+ tm->tm_isdst = 0;
+ }
+
+ /* Fetch the offset and initialize it if needed */
+ gmt_offset = gmt_offsets[tm->tm_isdst & 0x01];
+ if (unlikely(!*gmt_offset)) {
+ strftime(gmt_offset, 5+1, "%z", tm);
+ }
+
+ /* Restore previous DST flag */
+ tm->tm_isdst = old_isdst;
+
+ return gmt_offset;
+}
+
/* gmt2str_log: write a date in the format :
* "%02d/%s/%04d:%02d:%02d:%02d +0000" without using snprintf
* return a pointer to the last char written (\0) or
@@ -2590,9 +2619,12 @@ char *gmt2str_log(char *dst, struct tm *tm, size_t size)
*/
char *localdate2str_log(char *dst, struct tm *tm, size_t size)
{
+ const char *gmt_offset;
if (size < 27) /* the size is fixed: 26 chars + \0 */
return NULL;

+ gmt_offset = get_gmt_offset(tm);
+
dst = utoa_pad((unsigned int)tm->tm_mday, dst, 3); // day
*dst++ = '/';
memcpy(dst, monthname[tm->tm_mon], 3); // month
@@ -2606,7 +2638,7 @@ char *localdate2str_log(char *dst, struct tm *tm, size_t size)
*dst++ = ':';
dst = utoa_pad((unsigned int)tm->tm_sec, dst, 3); // secondes
*dst++ = ' ';
- memcpy(dst, localtimezone, 5); // timezone
+ memcpy(dst, gmt_offset, 5); // Offset from local time to GMT
dst += 5;
*dst = '\0';

--
2.5.0

Re: 'show table' is unreliable?

$
0
0
On 11 Mar 2016, at 22:43, Willy Tarreau <w@1wt.eu> wrote:
>
> Robert,
>
> On Fri, Mar 11, 2016 at 10:36:14PM +0000, Robert Samuel Newson wrote:
>> yep, I bound everything but I still get warnings. There's a bug that might be
>> related where binding stats doesn't work with stats bind-process, perhaps
>> that's my problem?
>
> Chad is right to insist on this, because Cyril recently fixed a related
> bug as you can see below :
>
> commit 0618195a114098c93e2712b5507dc9a3eeae8e8b
> Author: Cyril Bonté <cyril.bonte@free.fr>
> Date: Wed Feb 24 00:14:54 2016 +0100
>
> BUG/MEDIUM: stats: stats bind-process doesn't propagate the process mask correctly
>
> With nbproc > 1, it is possible to specify on which process the stats socket
> will be bound using "stats bind-process", but the behaviour was not correct,
> ignoring the value in some configurations.
> (...)
>
> There's a difference between "stats bind-process 1" (which indicates that the
> stats frontend is limited to process 1 and did not work as expected in 1.6.3),
> and "stats socket ... process 1" which indicates that this specific socket is
> only on process 1 and which used to already work in 1.6.3.
>
> In case of doubt, just put the two in your config. You shouldn't have
> any warning and it must work.
>
> regards,
> Willy
>
Apologies for top-post, Mail.app seems to insist on it.

I've tried with 'process 1' on the end of my stats line. It seems to help but is not a complete fix. I'll try to isolate this and show some config soon (next week).

[SPAM] 《N+1》计算基数与标准

$
0
0
请查看附件内容


------------------ 原始邮件 ------------------
发件人: info@bjzdfy.com.cn
发送时间: 2016年2002-1-5 上午 21:04:25
收件人: haproxy@formilux.org
抄送: 包总
主题: 答复:《N+1经济补偿》计算基数与标准

RE: SNI Support for Health Check on Backend Server

$
0
0
Using: "server dev05 192.168.1.10:443 check ssl sni str(www.mysite.com) verify none"

Proxy 'www.mysite.com', server 'dev05' [/etc/haproxy/haproxy.cfg:62] verify is enabled by default but no CA file specified. If you're running on a LAN where you're certain to trust the server's certificate, please set an explicit 'verify none' statement on the 'server' line, or use 'ssl-server-verify none' in the global section to disable server-side verifications by default.


Using: "server dev05 192.168.1.10:443 check sni str(prontotest.orthobanc.com) ssl verify none "

parsing [/etc/haproxy/haproxy.cfg:62] : 'server dev-web-06' unknown keyword 'none'.


William Roush | www.roushtech.nethttp://www.roushtech.net/

From: Bryan Talbot [mailto:bryan.talbot@ijji.com]
Sent: Friday, March 11, 2016 5:32 PM
To: William D. Roush <william.roush@roushtech.net>
Cc: haproxy@formilux.org
Subject: Re: SNI Support for Health Check on Backend Server

There is a recently reported but for this. Try putting "verify none" AFTER the "sni" keyword in your server line.

-Bryan


On Fri, Mar 11, 2016 at 2:08 PM, William D. Roush <william.roush@roushtech.net<mailto:william.roush@roushtech.net>> wrote:

Hey Everybody,



Been struggling trying to get SNI to work with health checks, even using 1.6 and a server configuration of this:



dev05 192.168.1.10:443http://192.168.1.10:443 check ssl verify none sni str(www.mysite.comhttp://www.mysite.com)



It will still not send the SNI information to the backend server during health checks.





Am I missing some additional options here? Or is this unsupported in 1.6? Is this slated for 1.7?

Thanks!
William Roush
william.roush@roushtech.net<mailto:william.roush@roushtech.net>

http://www.roushtech.net/

Re: SNI Support for Health Check on Backend Server

$
0
0
This passes config check for me using 1.6 HEAD


btalbot-lt:haproxy-1.6$ cat haproxy.cfg
global

defaults
timeout client 5s
timeout server 5s
timeout connect 5s
mode http

listen https
bind :443
server dev05 192.168.1.10:443 check ssl sni str(prontotest.orthobanc.com)
verify none



btalbot-lt:haproxy-1.6$ ./haproxy -f ./haproxy.cfg -c
Configuration file is valid



btalbot-lt:haproxy-1.6$ ./haproxy -vv
HA-Proxy version 1.6.3-079e34-67 2016/03/10
Copyright 2000-2015 Willy Tarreau <willy@haproxy.org>

Build options :
TARGET = generic
CPU = generic
CC = gcc
CFLAGS = -O2 -g -fno-strict-aliasing -Wdeclaration-after-statement
OPTIONS = USE_ZLIB=1 USE_OPENSSL=1

Default settings :
maxconn = 2000, bufsize = 16384, maxrewrite = 1024, maxpollevents = 200

Encrypted password support via crypt(3): no
Built with zlib version : 1.2.5
Compression algorithms supported : identity("identity"),
deflate("deflate"), raw-deflate("deflate"), gzip("gzip")
Built with OpenSSL version : OpenSSL 1.0.2g 1 Mar 2016
Running on OpenSSL version : OpenSSL 1.0.2g 1 Mar 2016
OpenSSL library supports TLS extensions : yes
OpenSSL library supports SNI : yes
OpenSSL library supports prefer-server-ciphers : yes
Built without PCRE support (using libc's regex instead)
Built without Lua support

Available polling systems :
poll : pref=200, test result OK
select : pref=150, test result OK
Total: 2 (2 usable), will use poll.



On Fri, Mar 11, 2016 at 5:23 PM, William D. Roush <
william.roush@roushtech.net> wrote:

> Using: "server dev05 192.168.1.10:443 check ssl sni str(www.mysite.com)
> verify none"
>
>
>
> Proxy 'www.mysite.com', server 'dev05' [/etc/haproxy/haproxy.cfg:62]
> verify is enabled by default but no CA file specified. If you're running on
> a LAN where you're certain to trust the server's certificate, please set an
> explicit 'verify none' statement on the 'server' line, or use
> 'ssl-server-verify none' in the global section to disable server-side
> verifications by default.
>
>
>
>
>
> Using: "server dev05 192.168.1.10:443 check sni str(
> prontotest.orthobanc.com) ssl verify none "
>
>
>
> parsing [/etc/haproxy/haproxy.cfg:62] : 'server dev-web-06' unknown
> keyword 'none'.
>
>
>
>
>
> William Roush | www.roushtech.net
>
>
>
> *From:* Bryan Talbot [mailto:bryan.talbot@ijji.com]
> *Sent:* Friday, March 11, 2016 5:32 PM
> *To:* William D. Roush <william.roush@roushtech.net>
> *Cc:* haproxy@formilux.org
> *Subject:* Re: SNI Support for Health Check on Backend Server
>
>
>
> There is a recently reported but for this. Try putting "verify none" AFTER
> the "sni" keyword in your server line.
>
>
>
> -Bryan
>
>
>
>
>
> On Fri, Mar 11, 2016 at 2:08 PM, William D. Roush <
> william.roush@roushtech.net> wrote:
>
> Hey Everybody,
>
>
>
> Been struggling trying to get SNI to work with health checks, even using
> 1.6 and a server configuration of this:
>
>
>
> dev05 192.168.1.10:443 check ssl verify none sni str(www.mysite.com)
>
>
>
> It will still not send the SNI information to the backend server during
> health checks.
>
>
>
>
>
> Am I missing some additional options here? Or is this unsupported in 1.6?
> Is this slated for 1.7?
>
>
> Thanks!
>
> William Roush
>
> william.roush@roushtech.net
>
>
>
> *http://www.roushtech.net/ http://www.roushtech.net/*
>
>
>

RE: [PossibleSpam] Re: SNI Support for Health Check on Backend Server

$
0
0
OK, that’s odd, Debian’s backport fails to load the config as per your recommendation, but head of 1.6 does… They both report 1.6.3.

However I’m still missing SNI on the health check using:

server dev05 192.168.1.10:443 check ssl sni str(www.mysite.com) verify none

William Roush | www.roushtech.nethttp://www.roushtech.net/

From: Bryan Talbot [mailto:bryan.talbot@ijji.com]
Sent: Friday, March 11, 2016 9:21 PM
To: William D. Roush <william.roush@roushtech.net>
Cc: Bryan Talbot <bryan.talbot@ijji.com>; haproxy@formilux.org
Subject: [PossibleSpam] Re: SNI Support for Health Check on Backend Server

This passes config check for me using 1.6 HEAD


btalbot-lt:haproxy-1.6$ cat haproxy.cfg
global

defaults
timeout client 5s
timeout server 5s
timeout connect 5s
mode http

listen https
bind :443
server dev05 192.168.1.10:443http://192.168.1.10:443 check ssl sni str(prontotest.orthobanc.comhttp://prontotest.orthobanc.com) verify none



btalbot-lt:haproxy-1.6$ ./haproxy -f ./haproxy.cfg -c
Configuration file is valid



btalbot-lt:haproxy-1.6$ ./haproxy -vv
HA-Proxy version 1.6.3-079e34-67 2016/03/10
Copyright 2000-2015 Willy Tarreau <willy@haproxy.org<mailto:willy@haproxy.org>>

Build options :
TARGET = generic
CPU = generic
CC = gcc
CFLAGS = -O2 -g -fno-strict-aliasing -Wdeclaration-after-statement
OPTIONS = USE_ZLIB=1 USE_OPENSSL=1

Default settings :
maxconn = 2000, bufsize = 16384, maxrewrite = 1024, maxpollevents = 200

Encrypted password support via crypt(3): no
Built with zlib version : 1.2.5
Compression algorithms supported : identity("identity"), deflate("deflate"), raw-deflate("deflate"), gzip("gzip")
Built with OpenSSL version : OpenSSL 1.0.2g 1 Mar 2016
Running on OpenSSL version : OpenSSL 1.0.2g 1 Mar 2016
OpenSSL library supports TLS extensions : yes
OpenSSL library supports SNI : yes
OpenSSL library supports prefer-server-ciphers : yes
Built without PCRE support (using libc's regex instead)
Built without Lua support

Available polling systems :
poll : pref=200, test result OK
select : pref=150, test result OK
Total: 2 (2 usable), will use poll.



On Fri, Mar 11, 2016 at 5:23 PM, William D. Roush <william.roush@roushtech.net<mailto:william.roush@roushtech.net>> wrote:
Using: "server dev05 192.168.1.10:443http://192.168.1.10:443 check ssl sni str(www.mysite.comhttp://www.mysite.com) verify none"

Proxy 'www.mysite.comhttp://www.mysite.com', server 'dev05' [/etc/haproxy/haproxy.cfg:62] verify is enabled by default but no CA file specified. If you're running on a LAN where you're certain to trust the server's certificate, please set an explicit 'verify none' statement on the 'server' line, or use 'ssl-server-verify none' in the global section to disable server-side verifications by default.


Using: "server dev05 192.168.1.10:443http://192.168.1.10:443 check sni str(prontotest.orthobanc.comhttp://prontotest.orthobanc.com) ssl verify none "

parsing [/etc/haproxy/haproxy.cfg:62] : 'server dev-web-06' unknown keyword 'none'.


William Roush | www.roushtech.nethttp://www.roushtech.net/

From: Bryan Talbot [mailto:bryan.talbot@ijji.com<mailto:bryan.talbot@ijji.com>]
Sent: Friday, March 11, 2016 5:32 PM
To: William D. Roush <william.roush@roushtech.net<mailto:william.roush@roushtech.net>>
Cc: haproxy@formilux.org<mailto:haproxy@formilux.org>
Subject: Re: SNI Support for Health Check on Backend Server

There is a recently reported but for this. Try putting "verify none" AFTER the "sni" keyword in your server line.

-Bryan


On Fri, Mar 11, 2016 at 2:08 PM, William D. Roush <william.roush@roushtech.net<mailto:william.roush@roushtech.net>> wrote:

Hey Everybody,



Been struggling trying to get SNI to work with health checks, even using 1.6 and a server configuration of this:



dev05 192.168.1.10:443http://192.168.1.10:443 check ssl verify none sni str(www.mysite.comhttp://www.mysite.com)



It will still not send the SNI information to the backend server during health checks.





Am I missing some additional options here? Or is this unsupported in 1.6? Is this slated for 1.7?

Thanks!
William Roush
william.roush@roushtech.net<mailto:william.roush@roushtech.net>

http://www.roushtech.net/

Re: [PATCH] BUG/MINOR: log: GMT offset not updated when entering/leaving DST

$
0
0
Hi Benoit,

On Sat, Mar 12, 2016 at 12:12:19AM +0100, Benoît GARNIER wrote:
> It looked like they were emitted more than 1 hour apart, unlike with the fix:
> <14>1 2016-03-27T01:59:58+01:00 bunch-VirtualBox haproxy 3381 - - Connect ...
> <14>1 2016-03-27T03:00:03+02:00 bunch-VirtualBox haproxy 3381 - - Connect ...
>
> This patch should be backported to 1.6 and partially to 1.5 (no fix needed in log.c).

Thank you for doing this work. I have a few comments below :

> diff --git a/src/standard.c b/src/standard.c
> index 30883d7..52ddaa2 100644
> --- a/src/standard.c
> +++ b/src/standard.c
> @@ -2550,6 +2550,35 @@ char *date2str_log(char *dst, struct tm *tm, struct timeval *date, size_t size)
> return dst;
> }
>
> +/* Return the GMT offset for a specific local time.
> + * The string returned has the same format as returned by strftime(... "%z", tm).
> + * Offsets are kept in an internal cache for better performances.
> + */
> +const char *get_gmt_offset(struct tm *tm)
> +{
> + /* Cache offsets from GMT (depending on whether DST is active or not) */
> + static char gmt_offsets[2][5+1] = { "", "" };
> +
> + int old_isdst = tm->tm_isdst;
> + char *gmt_offset;
> +
> + /* Pretend DST not active if its status is unknown, or strftime() will return an empty string for "%z" */
> + if (tm->tm_isdst < 0) {
> + tm->tm_isdst = 0;
> + }
> +
> + /* Fetch the offset and initialize it if needed */
> + gmt_offset = gmt_offsets[tm->tm_isdst & 0x01];
> + if (unlikely(!*gmt_offset)) {
> + strftime(gmt_offset, 5+1, "%z", tm);
> + }
> +
> + /* Restore previous DST flag */
> + tm->tm_isdst = old_isdst;
> +
> + return gmt_offset;
> +}

Since the cache is local to the function and initialized on the fly, no
call is performed anymore on startup, it will fail on some chrooted
systems because when the first log is emitted, you don't have access
to the timezones anymore.

Thus I'd suggest to move the static gmt_offset out of the function
and to have init_gmt_offset() which sets the string for both values
of tm_isdst and which is called upon startup, and get_gmt_offset()
which simply returns the correct one. At this point it will be so
small that it's worth inlining it.

An extra benefit of proceeding like this is that when we move to
multi-threading, we won't have to lock for something which will only
have to be initialized twice :-)

Thanks!
Willy

[SPAM] Offre spéciale : recevez une tablette tactile avec votre abonnement au Point

$
0
0
Afficher la version web. (http://trk.mix.jajaris.fr/view/yOM-89jgr.php) | Annuler votre abonnement. (http://trk.mix.jajaris.fr/usb/yOM-89jgr.php) | Signaler comme courrier indésirable. (mailto:abuse@dgcnit.fr)

40 numéros du Point la tablette Polaroid 7 pouces Polaroid pour 2,49 euros par semaine seulement, soit près de 60% de réduction. En savoir plus (http://trk.mix.jajaris.fr/tk/yOM-89jgr-yue.php) .
http://trk.mix.jajaris.fr/tk/yOM-89jgr-yue.php
http://trk.mix.jajaris.fr/tk/yOM-89jgr-yue.php
http://trk.mix.jajaris.fr/tk/yOM-89jgr-yue.php http://trk.mix.jajaris.fr/tk/yOM-89jgr-yue.php
http://trk.mix.jajaris.fr/tk/yOM-89jgr-yue.php
http://trk.mix.jajaris.fr/tk/yOM-89jgr-yue.php

Bonjour,

Que diriez-vous de recevoir avec votre abonnement au Point une tablette Polaroid 7 pouces tactile, le compagnon multimédia indispensable qui vous permettra de rester connecté partout, tout le temps ?

Ses performances avancées vous permettront de profiter au mieux de toutes ses fonctionnalités :


• Naviguer sans fil sur internet
• Lire vos e-mails
• Visionner vos films préférés
• Ecouter de la musique
• Télécharger des centaines d'applications Android au choix
• Consulter vos documents Word, Excel et Powerpoint
• Jouer à des jeux vidéos.
Pour 2,49 € seulement par semaine, recevez cette tablette chez vous et profitez d'un abonnement de près de 10 mois à l'hebdomadaire Le Point (soit 40 numéros).
Ne laissez pas passer cette opportunité (http://trk.mix.jajaris.fr/tk/yOM-89jgr-yue.php) de lire chaque semaine le leader des news magazine et de recevoir cette tablette qui fera l'unanimité auprès de toute la famille.

A bientôt,
http://trk.mix.jajaris.fr/tk/yOM-89jgr-yue.php

Le service Abonnements

Conformément à la loi &quot;Informatique et Liberté&quot; n° 78-17 du 6 janvier 1978 modifiée, vous bénéficiez d'un droit d'accès, de rectification, d'opposition et de suppression des données vous concernant.
Vous souhaitez vous désinscrire de cette liste ? Cliquez ici. (http://trk.mix.jajaris.fr/usb/yOM-89jgr.php)

Re: [PATCH] BUG/MINOR: log: GMT offset not updated when entering/leaving DST

$
0
0
Hello Willy,

Le 12/03/2016 07:54, Willy Tarreau a écrit :
>> +/* Return the GMT offset for a specific local time.
>> + * The string returned has the same format as returned by strftime(... "%z", tm).
>> + * Offsets are kept in an internal cache for better performances.
>> + */
>> +const char *get_gmt_offset(struct tm *tm)
>> +{
>> + /* Cache offsets from GMT (depending on whether DST is active or not) */
>> + static char gmt_offsets[2][5+1] = { "", "" };
>> +
>> + int old_isdst = tm->tm_isdst;
>> + char *gmt_offset;
>> +
>> + /* Pretend DST not active if its status is unknown, or strftime() will return an empty string for "%z" */
>> + if (tm->tm_isdst < 0) {
>> + tm->tm_isdst = 0;
>> + }
>> +
>> + /* Fetch the offset and initialize it if needed */
>> + gmt_offset = gmt_offsets[tm->tm_isdst & 0x01];
>> + if (unlikely(!*gmt_offset)) {
>> + strftime(gmt_offset, 5+1, "%z", tm);
>> + }
>> +
>> + /* Restore previous DST flag */
>> + tm->tm_isdst = old_isdst;
>> +
>> + return gmt_offset;
>> +}
> Since the cache is local to the function and initialized on the fly, no
> call is performed anymore on startup, it will fail on some chrooted
> systems because when the first log is emitted, you don't have access
> to the timezones anymore.
You just need to call tzset() once before chrooting to initialize the timezone subsystem.
In fact, it's probably done by chance, there are a handful of functions that call tzset implicitly.
I tested on a chroot environment on Linux/x86 and it works, but I admit it's fragile.
I could cook an amended patch with an explicit call to tzset at init time.
> Thus I'd suggest to move the static gmt_offset out of the function
> and to have init_gmt_offset() which sets the string for both values
> of tm_isdst and which is called upon startup, and get_gmt_offset()
> which simply returns the correct one. At this point it will be so
> small that it's worth inlining it.
I obviously thought about a solution like that, but it's not that simple: tm_isdst it not an isolated flag.
It cannot be interpreted without looking at a full struct tm.
tm_isdt can only be 0 only during the winter, and can be 1 only during the summer.
For countries without a DST, the only valid value is 0.
Combining random dates with random values of tm_isdst has undefined behavior and could lead to some portability problems.
In fact, there exists only one hour during which it can be 0 or 1: when going from summer time to winter time for timezones that have a DST.
Think about it: there will exist two "Oct 30 2016, 02:30" in France, because time will go backward once at 03:00.
This is the only time when both values of tm_isdst are valid at the same time, and it's that value that allows to distinguish between those two equivalent times.
That's why I chose to have a cache, so that I can use "real" times to compute GMT offsets.
> An extra benefit of proceeding like this is that when we move to
> multi-threading, we won't have to lock for something which will only
> have to be initialized twice :-)
Wow, I didn't think haproxy would move to multi-threading one day.
I guess you'll have some local thread contexts (TLS or explicit context) where the cache would fit nicely.
The cache would be initialized only once per thread and I guess you won't need more threads than the number of CPU cores.
> Thanks!
> Willy
Let me know if you want a patch with an explicit call to tzset().

Benoît GARNIER

Re: Only using map file when an entry exists

$
0
0
Thanks Nanad,

That works perfectly, thank you

On 11 March 2016 at 22:37, Nenad Merdanovic <nimzo@nimzo.info> wrote:

> Hello Neil,
>
> You seem to have missed my answer, so I am gonna top post this time :)
>
> http-request redirect location
> %[hdr(host),map(/etc/haproxy/redirect_host.map)] code 301 if {
> hdr(host),map(/etc/haproxy/redirect_host.map) -m found }
>
> Regards,
> Nenad
>
> On 03/11/2016 11:32 PM, Neil - HAProxy List wrote:
> > Hello
> >
> > I've left a little time and no one has said anything more so time for me
> > to act and submit a patch.
> >
> > I want to make functions that can be used in acls and take a map and
> > provide has_key and, for completeness, has_value
> >
> > Are those names uncontroversial/ suitable and, i really hope, is this
> > unnecessary as it already exists.
> >
> > I'm more that a little surprised to find myself the first to want this
> >
> > Cheers
> >
> > Neil
> >
> > On 11 Mar 2016 22:16, "Neil" <neil@iamafreeman.com
> > <mailto:neil@iamafreeman.com>> wrote:
> >
> > Hello
> >
> > I've left a little time and no one has said anything more so time
> > for me to act and submit a patch.
> >
> > I want to make functions that can be used in acls and take a map and
> > provide has_key and, for completeness, has_value
> >
> > Are those names uncontroversia/ suitablel and, i really hope, is
> > this unnecessary as it already exists.
> >
> > I'm more that a little sutprised to find myself the first to want
> this
> >
> > Cheers
> >
> > Neil
> >
> > On 3 Mar 2016 18:08, "Neil - HAProxy List"
> > <maillist-haproxy@iamafreeman.com
> > <mailto:maillist-haproxy@iamafreeman.com>> wrote:
> >
> > Thanks Conrad,
> >
> > That sort of thing looks better that what I had, and I'll give
> > it a go.
> >
> > I still think this is a bit long winded syntax for something
> > that probably quite a common things to want to do? A
> > map_contains type boolean function still seems like a good to
> have?
> >
> > Thanks
> >
> > Neil
> >
> > On 3 March 2016 at 13:05, Conrad Hoffmann <conrad@soundcloud.com
> > <mailto:conrad@soundcloud.com>> wrote:
> >
> > If you are using haproxy >=1.6, you might be able to do
> > something like this:
> >
> > acl no_redir %[req.redir] -m str NO_REDIR
> > http-request set-var(req.redir) \
> > %[hdr(host),map(/etc/haproxy/redirect_host.map,NO_REDIR)]
> > http-request redirect location %[req.redir] code 301 if
> > !no_redir
> >
> > This is completely made up and untested, but I hope you get
> > the idea.
> > Avoids a second map lookup altogether, but also map lookups
> > are quite fast,
> > so unless you map is huge you don't really need to worry
> > about this. Also,
> > double negation, but this is just to give you some idea
> >
> > Cheers,
> > Conrad
> > --
> > Conrad Hoffmann
> > Traffic Engineer
> >
> > SoundCloud Ltd. | Rheinsberger Str. 76/77, 10115 Berlin,
> Germany
> >
> > Managing Director: Alexander Ljung | Incorporated in England
> > & Wales
> > with Company No. 6343600 | Local Branch Office | AG
> > Charlottenburg |
> > HRB 110657B
> >
> >
>

Re: [PATCH] BUG/MINOR: log: GMT offset not updated when entering/leaving DST

$
0
0
Hi Benoit,

On Sat, Mar 12, 2016 at 09:45:25AM +0100, Beno?t GARNIER wrote:
> > Since the cache is local to the function and initialized on the fly, no
> > call is performed anymore on startup, it will fail on some chrooted
> > systems because when the first log is emitted, you don't have access
> > to the timezones anymore.
> You just need to call tzset() once before chrooting to initialize the timezone subsystem.
> In fact, it's probably done by chance, there are a handful of functions that call tzset implicitly.
> I tested on a chroot environment on Linux/x86 and it works, but I admit it's fragile.
> I could cook an amended patch with an explicit call to tzset at init time.

Yes I'd appreciate it then.

> > Thus I'd suggest to move the static gmt_offset out of the function
> > and to have init_gmt_offset() which sets the string for both values
> > of tm_isdst and which is called upon startup, and get_gmt_offset()
> > which simply returns the correct one. At this point it will be so
> > small that it's worth inlining it.
> I obviously thought about a solution like that, but it's not that simple: tm_isdst it not an isolated flag.
> It cannot be interpreted without looking at a full struct tm.
> tm_isdt can only be 0 only during the winter, and can be 1 only during the summer.
> For countries without a DST, the only valid value is 0.
> Combining random dates with random values of tm_isdst has undefined behavior and could lead to some portability problems.

OK I wasn't aware of this, that makes sense then.

> In fact, there exists only one hour during which it can be 0 or 1: when going from summer time to winter time for timezones that have a DST.
> Think about it: there will exist two "Oct 30 2016, 02:30" in France, because time will go backward once at 03:00.

Yep definitely. The usual 90k seconds day :-)

> This is the only time when both values of tm_isdst are valid at the same time, and it's that value that allows to distinguish between those two equivalent times.
> That's why I chose to have a cache, so that I can use "real" times to compute GMT offsets.

That makes sense, thanks for explaining.

> > An extra benefit of proceeding like this is that when we move to
> > multi-threading, we won't have to lock for something which will only
> > have to be initialized twice :-)
> Wow, I didn't think haproxy would move to multi-threading one day.

Don't be too excited, it will take decades :-)

> I guess you'll have some local thread contexts (TLS or explicit context) where the cache would fit nicely.

Possibly, yes. At least it won't be static in the function anymore.

> The cache would be initialized only once per thread and I guess you won't need more threads than the number of CPU cores.

On this last point we don't know. Once we get some shared memory between
all processes, it could make sense to have many threads to benefit from
some slow external operations (HW crypto accelerators for example, which
may require tens to hundreds of threads to be useful).

> > Thanks!
> > Willy
> Let me know if you want a patch with an explicit call to tzset().

Yes, please do it and I'll merge it with the upcoming release.

Thanks!
Willy

Re: There is kind of a spam issue on this ML no?

$
0
0
Oh don't say that !
Last time I did, I was told that I had a bad spirit, and that my
antispam was just bad.

The thing is : unlike other popular mailing-lists, ANYTHING or ANYONE
can post on this one without prior subscription, hence that huge spammy
noise.

Hoggins!

Le 11/03/2016 10:00, Arnaud B. a écrit :
> On the last 2 or 3 days :
> https://lut.im/jsIGNMzLDL/OuRdpkM9ZpVTIH47
Viewing all 11674 articles
Browse latest View live