Re: [PATCH] REGTEST: Add a basic test for the cache.

[Willy Tarreau]

On Wed, Nov 28, 2018 at 02:03:06PM +0100, Frederic Lecaille wrote:
> Here is a little patch for a basic test for the cache.

Applied, thanks Fred.

Willy

Re: [PATCH] REGTEST/MINOR: script: add run-regtests.sh script

[Willy Tarreau]

On Thu, Nov 29, 2018 at 05:36:35AM +0100, Willy Tarreau wrote:
> However I'm well aware that it's easier to work on improvements once the
> script is merged, so what I've done now is to merge it and create a
> temporary "reg-tests2" target in the makefile to use it without losing
> the existing one. This way everyone can work in parallel, and once the
> few issues seem reliably addressed, we can definitely replace the make
> target.

Unfortunately ENOCOFFEE struck me this morning and I forgot to commit
my local changes so I merged the unmodified version which replaces the
"reg-test" target.

Thus now we're condemned to quickly fix these small issues :-)

I've found the problem related to mktemp, it uses "" as the suffix.
On my distro the man page says :

   The  mktemp  utility takes the given filename template and overwrites a
   portion of it to create a unique filename.  The  template  may  be  any
   filename   with   six   (6)   `Xs'   appended   to   it,   for  example
   /tmp/tfile.XX.

I've found that other systems demand at least 3 or at least 1. And the
glibc's mktemp() calll wants 6 anyway or returns EINVAL (the one I got).
Thus we should add 2 more "X" to make this work everywhere mktemp is
present (and test for the output as well).

Willy

Re: [PATCH] REGTEST/MINOR: script: add run-regtests.sh script

[Willy Tarreau]

Hi guys,

On Wed, Nov 28, 2018 at 11:17:22AM +0100, Frederic Lecaille wrote:
> Perhaps we should "chmod +x" this script.

Good point, done here.

However I'm now seeing this when starting it :

## Starting varnishtest ##
Testing with haproxy version: 1.8-dev0-3b0a6d-66
Assert error in start_test(), vtc_main.c line 283:
  Condition((mkdir(tmpdir, 0711)) == 0) not true.
  errno = 13 (Permission denied)
./scripts/run-regtests.sh: line 299: 21484 Aborted 
$VARNISHTEST_PROGRAM $varnishtestparams $verbose $jobcount -l -k -t 10 $testlist
## Gathering failed results ##
find: `/proc/tty/driver': Permission denied
find: `/proc/1/task/1/fd': Permission denied
find: `/proc/1/task/1/fdinfo': Permission denied
find: `/proc/1/task/1/ns': Permission denied
find: `/proc/1/fd': Permission denied
find: `/proc/1/map_files': Permission denied
(...)

Then I stopped it using Ctrl-C.

I'm seeing a few minor issues we must still address :

  - haproxy is started from the path, which means that on all systems
where it's installed, it will be the one provided by the system and
not the just built one which will be tested (as happened above),
which is confusing. I think we shouldn't search for haproxy in the
path but use $PWD/haproxy or ./haproxy or something like this.

  - it seems there are some issues in the way TMPDIR/TESTDIR are created,
as it ended up with an empty TESTDIR. In my case, TMPDIR is not set,
so TESTDIR was set to /tmp/varnishtest_haproxy. mkdir worked (I now
have this directory), but a test is missing on this mkdir.

  - the way the sub-directory is created is problematic on shared
development machines, as only the first user will own the directory
and will thus prevent other users from creating their own overthere,
thus it's probably preferable not to create an intermediary directory
in the end.

  - in my case it's mktemp which failed :

++ date +%Y-%m-%d_%H-%M-%S
+ TESTRUNDATETIME=2018-11-29_05-03-43
+ TESTDIR=/tmp/varnishtest_haproxy
+ mkdir -p /tmp/varnishtest_haproxy
++ mktemp -d /tmp/varnishtest_haproxy/2018-11-29_05-03-43.
mktemp: cannot make temp dir 
/tmp/varnishtest_haproxy/2018-11-29_05-03-43.: Invalid argument
+ TESTDIR=

I haven't checked why yet, but we definitely need to test the status
code for success as well.

  - in my opinion the script is still missing a number of quotes when using
string variables, especially in the directory names. If someone is crazy
enough to have TMPDIR="/tmp/Temp Dir", then he'll have some fun.

  - I'm seeing a linux-specific "rm -d" at the end, it's be better to
replace it with rmdir.

  - there's "/usr/bin/env sh" at the top of the shell script. /bin/sh is
the portable one, I've spent lots of time in the past editing scripts
where env was forced to /usr/bin while it was placed in /bin on some
systems, so I'm pretty certain that this one is not portable at all :-)

However I'm well aware that it's easier to work on improvements once the
script is merged, so what I've done now is to merge it and create a
temporary "reg-tests2" target in the makefile to use it without losing
the existing one. This way everyone can work in parallel, and once the
few issues seem reliably addressed, we can definitely replace the make
target.

Thanks!
Willy

Re: OCSP stapling with multiple domains

[Moemen MHEDHBI]

@list: sorry for the incorrect subject in my previous answer. At some
point the subject changed when email was saved and encrypted in Drafts.

On 28/11/2018 18:59, Moemen MHEDHBI wrote:
> Hi Igor,
>
> On 11/27/18 12:48 AM, Igor Cicimov wrote:
>> Hi Moemen,
>>
>> On Tue, Nov 27, 2018 at 1:24 AM Moemen MHEDHBI  wrote:
>>> On 11/14/18 1:34 AM, Igor Cicimov wrote:
>>>
>>> On Sun, Nov 11, 2018 at 2:48 PM Igor Cicimov 
>>>  wrote:
 Hi,

 # haproxy -v
 HA-Proxy version 1.8.14-1ppa1~xenial 2018/09/23
 Copyright 2000-2018 Willy Tarreau 

 I noticed that in case of multiple domains and OCSP setup:

 # ls -1 /etc/haproxy/ssl.d/*.ocsp
 /etc/haproxy/ssl.d/star_domain2_com.crt.ocsp
 /etc/haproxy/ssl.d/star_domain_com.crt.ocsp
 /etc/haproxy/ssl.d/star_domain3_com.crt.ocsp
 /etc/haproxy/ssl.d/star_domain4_com.crt.ocsp

 I get OCSP response from haproxy only for one of the domains
 domain.com. Tested via:

 $ echo | openssl s_client -connect domain[234].com:443 -tlsextdebug
 -status -servername domain[234].com

 Is this expected?
>>> Any comments/ideas regarding this? Further noticed that OCSP code probably 
>>> does not check the certificates SANs and matches only based on the CN in 
>>> the subject since the calls to whatever.domain.tld get stapled but to 
>>> domain.tld do not.
>>>
>>> Hi Igor,
>>>
>>> Testing OCSP on multiple certificates with different domains (based on the 
>>> CN) works correctly for me. (a.domain.com, b.domain.com, c.domain.com)
>>>
>>> Are you using multiple certs with same CN but different SANs ?
>> The certificates belong to completely separate domains, so not
>> subdomains of the same domain like in your case. They are also
>> wildcard certs so here is the layout:
>>
>> # ls -1 /etc/haproxy/ssl.d/
>> star_domain1_com.crt
>> star_domain1_com.crt.ocsp
>> star_domain2_com.crt
>> star_domain2_com.crt.ocsp
>> star_domain3_com.crt
>> star_domain3_com.crt.ocsp
>>
>> # for i in `ls -1 /etc/haproxy/ssl.d/*.crt`; do openssl x509 -noout
>> -subject -in $i; done
>> subject= /C=AU/ST=New South Wales/L=Sydney/O=My Company/CN=*.domain1.com
>> subject= /C=AU/ST=New South Wales/L=Sydney/O=My Company/CN=*.domain2.com
>> subject= /C=AU/ST=New South Wales/L=Sydney/O=My Company/CN=*.domain3.com
>>
>> The SAN only contains the certificates domain and nothing else, for
>> example for domain3.com:
>>
>> X509v3 Subject Alternative Name:
>> DNS:*.domain3.com, DNS:domain3.com
>>
>> The haproxy bind line in the frontend looks like:
>>
>>  bind *:443 ssl crt /etc/haproxy/ssl.d/ ...
>>
>> And here is the output of the daily cronjob that updates the OCSP for 
>> haproxy:
>>
>> Date: Mon, 26 Nov 2018 05:00:01 + (GMT)
>>
>> /etc/haproxy/ssl.d/star_domain1_com.crt: good
>> This Update: Nov 25 17:39:11 2018 GMT
>> Next Update: Dec  2 16:54:11 2018 GMT
>> OCSP Response updated!
>> /etc/haproxy/ssl.d/star_domain2_com.crt: good
>> This Update: Nov 24 20:49:57 2018 GMT
>> Next Update: Dec  1 20:04:57 2018 GMT
>> OCSP Response updated!
>> /etc/haproxy/ssl.d/star_domain3_com.crt: good
>> This Update: Nov 25 14:09:00 2018 GMT
>> Next Update: Dec  2 13:24:00 2018 GMT
>> OCSP Response updated!
>>
>> I can confirm this is working as intended on other serves I have with
>> 1.7.11 and 1.8.14, so it must be something specific to this one that I
>> struggle to understand (to be even more confusing it is all being
>> setup by Ansible in same way as everywhere else).
>>
>> Under what circumstances would a setup like this not work in terms of
>> OCSP? Example:
>>
>> $ echo | openssl s_client -connect server:443 -tlsextdebug -status
>> -servername domain1.com | grep -E 'OCSP|domain1'
>> depth=0 C = AU, ST = New South Wales, L = Sydney, O = My Company, CN =
>> *.domain1.com
>> verify return:1
>> DONE
>> OCSP response: no response sent
>>  0 s:/C=AU/ST=New South Wales/L=Sydney/O=My Company/CN=*.domain1.com
>> subject=/C=AU/ST=New South Wales/L=Sydney/O=My Company/CN=*.domain1.com
>>
>> Thanks for your input by the way, very much appreciated.
>
> If I am understanding this correctly when you use the naked domain
> 'domain1.com', you don't get an OCSP response (despite mentioning the
> domain in the SAN extension).
>
> Is this the case for all the domains or only one of them ? I am asking
> this since you're mentioning multiple domains.
>
> I was testing the same config with HA-Proxy version 1.8.14 2018/09/20
> without being able to reproduce this.
>
> $ echo quit | openssl s_client -connect localhost:443 -servername
> 'example.org' -status | egrep 'OCSP|example'
> OCSP response:
> OCSP Response Data:
>     OCSP Response Status: successful (0x0)
>     Response Type: Basic OCSP Response
>     OCSP Nonce:
> subject=/C=FR/ST=PARIS/O=MMH/OU=server/CN=*.example.org
>
> I only get " no response sent" when the "naked" domain is not mentioned
> in the SAN which is expected. 
>
>
>> I can 

Encrypted Message

[Moemen MHEDHBI]

Hi Igor,

On 11/27/18 12:48 AM, Igor Cicimov wrote:
> Hi Moemen,
>
> On Tue, Nov 27, 2018 at 1:24 AM Moemen MHEDHBI  wrote:
>> On 11/14/18 1:34 AM, Igor Cicimov wrote:
>>
>> On Sun, Nov 11, 2018 at 2:48 PM Igor Cicimov 
>>  wrote:
>>> Hi,
>>>
>>> # haproxy -v
>>> HA-Proxy version 1.8.14-1ppa1~xenial 2018/09/23
>>> Copyright 2000-2018 Willy Tarreau 
>>>
>>> I noticed that in case of multiple domains and OCSP setup:
>>>
>>> # ls -1 /etc/haproxy/ssl.d/*.ocsp
>>> /etc/haproxy/ssl.d/star_domain2_com.crt.ocsp
>>> /etc/haproxy/ssl.d/star_domain_com.crt.ocsp
>>> /etc/haproxy/ssl.d/star_domain3_com.crt.ocsp
>>> /etc/haproxy/ssl.d/star_domain4_com.crt.ocsp
>>>
>>> I get OCSP response from haproxy only for one of the domains
>>> domain.com. Tested via:
>>>
>>> $ echo | openssl s_client -connect domain[234].com:443 -tlsextdebug
>>> -status -servername domain[234].com
>>>
>>> Is this expected?
>> Any comments/ideas regarding this? Further noticed that OCSP code probably 
>> does not check the certificates SANs and matches only based on the CN in the 
>> subject since the calls to whatever.domain.tld get stapled but to domain.tld 
>> do not.
>>
>> Hi Igor,
>>
>> Testing OCSP on multiple certificates with different domains (based on the 
>> CN) works correctly for me. (a.domain.com, b.domain.com, c.domain.com)
>>
>> Are you using multiple certs with same CN but different SANs ?
> The certificates belong to completely separate domains, so not
> subdomains of the same domain like in your case. They are also
> wildcard certs so here is the layout:
>
> # ls -1 /etc/haproxy/ssl.d/
> star_domain1_com.crt
> star_domain1_com.crt.ocsp
> star_domain2_com.crt
> star_domain2_com.crt.ocsp
> star_domain3_com.crt
> star_domain3_com.crt.ocsp
>
> # for i in `ls -1 /etc/haproxy/ssl.d/*.crt`; do openssl x509 -noout
> -subject -in $i; done
> subject= /C=AU/ST=New South Wales/L=Sydney/O=My Company/CN=*.domain1.com
> subject= /C=AU/ST=New South Wales/L=Sydney/O=My Company/CN=*.domain2.com
> subject= /C=AU/ST=New South Wales/L=Sydney/O=My Company/CN=*.domain3.com
>
> The SAN only contains the certificates domain and nothing else, for
> example for domain3.com:
>
> X509v3 Subject Alternative Name:
> DNS:*.domain3.com, DNS:domain3.com
>
> The haproxy bind line in the frontend looks like:
>
>  bind *:443 ssl crt /etc/haproxy/ssl.d/ ...
>
> And here is the output of the daily cronjob that updates the OCSP for haproxy:
>
> Date: Mon, 26 Nov 2018 05:00:01 + (GMT)
>
> /etc/haproxy/ssl.d/star_domain1_com.crt: good
> This Update: Nov 25 17:39:11 2018 GMT
> Next Update: Dec  2 16:54:11 2018 GMT
> OCSP Response updated!
> /etc/haproxy/ssl.d/star_domain2_com.crt: good
> This Update: Nov 24 20:49:57 2018 GMT
> Next Update: Dec  1 20:04:57 2018 GMT
> OCSP Response updated!
> /etc/haproxy/ssl.d/star_domain3_com.crt: good
> This Update: Nov 25 14:09:00 2018 GMT
> Next Update: Dec  2 13:24:00 2018 GMT
> OCSP Response updated!
>
> I can confirm this is working as intended on other serves I have with
> 1.7.11 and 1.8.14, so it must be something specific to this one that I
> struggle to understand (to be even more confusing it is all being
> setup by Ansible in same way as everywhere else).
>
> Under what circumstances would a setup like this not work in terms of
> OCSP? Example:
>
> $ echo | openssl s_client -connect server:443 -tlsextdebug -status
> -servername domain1.com | grep -E 'OCSP|domain1'
> depth=0 C = AU, ST = New South Wales, L = Sydney, O = My Company, CN =
> *.domain1.com
> verify return:1
> DONE
> OCSP response: no response sent
>  0 s:/C=AU/ST=New South Wales/L=Sydney/O=My Company/CN=*.domain1.com
> subject=/C=AU/ST=New South Wales/L=Sydney/O=My Company/CN=*.domain1.com
>
> Thanks for your input by the way, very much appreciated.


If I am understanding this correctly when you use the naked domain
'domain1.com', you don't get an OCSP response (despite mentioning the
domain in the SAN extension).

Is this the case for all the domains or only one of them ? I am asking
this since you're mentioning multiple domains.

I was testing the same config with HA-Proxy version 1.8.14 2018/09/20
without being able to reproduce this.

$ echo quit | openssl s_client -connect localhost:443 -servername
'example.org' -status | egrep 'OCSP|example'
OCSP response:
OCSP Response Data:
    OCSP Response Status: successful (0x0)
    Response Type: Basic OCSP Response
    OCSP Nonce:
subject=/C=FR/ST=PARIS/O=MMH/OU=server/CN=*.example.org

I only get " no response sent" when the "naked" domain is not mentioned
in the SAN which is expected. 


> I can confirm this is working as intended on other serves I have with
> 1.7.11 and 1.8.14, so it must be something specific to this one that I
> struggle to understand (to be even more confusing it is all being
> setup by Ansible in same way as everywhere else).

Ok so no surprise that I cannot reproduce this since I am using 1.8.14
(latest 

BUG: Lua tasks can't use client sockets after bf89ff3d

[Adis Nezirović]

Hey guys,

After commit bf89ff3db8be1a8f87de305c144467bbc2503036
"MEDIUM: stream-int: make stream_int_update() aware of the lower layers"
I'm not able to use client sockets from tasks created with Lua (see
attached configuration and Lua script)

You will need LuaSocket library to run the test code, but I also get the
same issue without it (using raw core.tcp() and custom http library).

Before the commit cron works fine, connection and http layer (returns
404 since http.socket is a little bit stupid, but ignore that).

After the commit, http.socket reports 'Can't connect' (and 'connection
closed' afterwards). Debug log shows significant time spent in
'stream_int_chk_rcv_applet()'

Best regards,
-- 
Adis Nezirovic
Software Engineer
HAProxy Technologies - Powering your uptime!
375 Totten Pond Road, Suite 302 | Waltham, MA 02451, US
+1 (844) 222-4340 | https://www.haproxy.com
global
log /dev/log local0 debug
nbproc 1
daemon
lua-load cron.lua

defaults
log global
mode http
option httplog
timeout connect 5s
timeout client 10s
timeout server 10s

frontend cron
bind 127.0.0.1:9000
http-request use-service lua.cron
local http = require 'socket.http'
local ltn12 = require 'ltn12'

local function main(applet)
end

local function cron()
local headers = {
host = 'www.haproxy.org'
}
local content = {}

while true do
core.Debug('CRON')
local b, c, h = http.request {
method='GET',
headers=h,
url = 'http://51.15.8.218',
sink = ltn12.sink.table(content),
redirect = false,
create = core.tcp
}
core.Debug(tostring(c))  -- http.request doesn't use Host header
 -- so we expect 404 response here
core.msleep(1000)
end
end

core.register_service("cron", "http", main)
core.register_task(cron)

[PATCH] BUG/MINOR: ssl: ssl_sock_parse_clienthello ignores session id

[Baptiste]

Hi there,

There is a small bug with the function involved in the ssl_fc_cipherlist_*
fetches.
ssl_sock_parse_clienthello() improperly parses the session id, which leads
to not return any client side cipher list when a client send a SSL session
ID to resume a session.
This patch aims at fixing this issue.

Baptiste
From f2c79803c6bcb69866f54c8a5833bd0178bea64c Mon Sep 17 00:00:00 2001
From: Baptiste Assmann 
Date: Wed, 28 Nov 2018 15:20:25 +0100
Subject: [PATCH] BUG/MINOR: ssl: ssl_sock_parse_clienthello ignores session id

In ssl_sock_parse_clienthello(), the code considers that SSL Sessionid
size is '1', and then considers that the SSL cipher suite is availble
right after the session id size information.
This actually works in a single case, when the client does not send a
session id.

This patch fixes this issue by introducing the a propoer way to parse
the session id and move forward the cursor by the session id length when
required.
---
 src/ssl_sock.c | 15 ---
 1 file changed, 12 insertions(+), 3 deletions(-)

diff --git a/src/ssl_sock.c b/src/ssl_sock.c
index a73fb2d..c48c4af 100644
--- a/src/ssl_sock.c
+++ b/src/ssl_sock.c
@@ -1561,10 +1561,19 @@ void ssl_sock_parse_clienthello(int write_p, int version, int content_type,
 
 	/* Expect 2 bytes for protocol version (1 byte for major and 1 byte
 	 * for minor, the random, composed by 4 bytes for the unix time and
-	 * 28 bytes for unix payload, and them 1 byte for the session id. So
-	 * we jump 1 + 1 + 4 + 28 + 1 bytes.
+	 * 28 bytes for unix payload. So we jump 1 + 1 + 4 + 28.
 	 */
-	msg += 1 + 1 + 4 + 28 + 1;
+	msg += 1 + 1 + 4 + 28;;
+	if (msg > end)
+		return;
+
+	/* Next, is session id:
+	 * if present, we have to jump by is length + 1 for the size information
+	 * if not present, we have to jump by 1 only
+	 */
+	if (msg[0] > 0)
+		msg += msg[0];
+	msg += 1;
 	if (msg > end)
 		return;
 
-- 
2.7.4

[PATCH] REGTEST: Add a basic test for the cache.

[Frederic Lecaille]

Here is a little patch for a basic test for the cache.

Fred.
>From aa301c6eef5c6797283d56b9f23266345808cd1e Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Fr=C3=A9d=C3=A9ric=20L=C3=A9caille?= 
Date: Wed, 28 Nov 2018 11:36:48 +0100
Subject: [PATCH] REGTEST: Add a basic test for the cache.

The client makes the same HTTP request four times.
The varnishtest HTTP server serves the first client request and quits.
So, the three last requests are handled by the haproxy cache.
---
 reg-tests/cache/h0.vtc | 54 ++
 1 file changed, 54 insertions(+)
 create mode 100644 reg-tests/cache/h0.vtc

diff --git a/reg-tests/cache/h0.vtc b/reg-tests/cache/h0.vtc
new file mode 100644
index ..5195816a
--- /dev/null
+++ b/reg-tests/cache/h0.vtc
@@ -0,0 +1,54 @@
+varnishtest "Basic cache test"
+
+#REQUIRE_VERSION=1.8
+
+feature ignore_unknown_macro
+
+server s1 {
+rxreq
+txresp -nolen -hdr "Transfer-Encoding: chunked"
+chunkedlen 1
+chunkedlen 1
+chunkedlen 2
+chunkedlen 3
+chunkedlen 5
+chunkedlen 8
+chunkedlen 13
+chunkedlen 21
+chunkedlen 34
+chunkedlen 55
+chunkedlen 89
+chunkedlen 144
+chunkedlen 233
+chunkedlen 0
+} -start
+
+haproxy h1 -conf {
+defaults
+mode http
+timeout connect 1s
+timeout client  1s
+timeout server  1s
+
+frontend fe
+bind "fd@${fe}"
+default_backend test
+
+backend test
+http-request cache-use my_cache
+server www ${s1_addr}:${s1_port}
+http-response cache-store my_cache
+
+cache my_cache
+	total-max-size 3
+	max-age 20
+	max-object-size 3072
+} -start
+
+
+client c1 -connect ${h1_fe_sock} {
+	txreq
+	rxresp
+	expect resp.status == 200
+	expect resp.bodylen == 609
+} -repeat 4 -run
-- 
2.11.0

Feature Article Covering HAProxy on HostingAdvice.com

[Sean Garrity]

Hi,

We'd like to write an in-depth article on HAProxy—specifically covering the
load balancer's backstory and how your services have evolved alongside
industry shifts, competitive differentiators from a tech point of view,
features your team is most proud of, and anything new we can help amplify
from a marketing perspective. It'd be great if we could have a quick phone
call with a team member who can share what sets the company apart from a
product and team culture point of view.

Is anyone available to chat next week?

Best,
Sean

--

*Sean Garrity*
Vertical Manager



Digital Brands Inc.
15 SE 1st Ave, 2nd Floor
Gainesville, FL 32601


Call: 352-642-5222
Visit: www.hostingadvice.com
LinkedIn: www.linkedin.com/in/sean-garrity-db

Re: HA setup for HAProxy

[Gibson, Brian (IMS)]

I either use openshift or if not using docker I use keepalive.  There is plenty 
of documentation out on the internet in how to use either of these solutions.

Sent from Nine

From: Gold Star 
Sent: Wednesday, November 28, 2018 12:33 AM
To: HAProxy
Subject: HA setup for HAProxy

We use HAProxy for HTTP load balancing in our company. We run HAProxy inside a 
docker container. We would like to run multiple HAProxy containers for High 
Availability. In particular, we would like to:

  *   run say, 10 HAProxy containers (1 HAProxy per container) to handle the 
incoming traffic to our company
  *   have each of them be active (i.e. each of them processes roughly 
one-tenth of traffic)
  *   if one of the containers goes down, the remaining HAProxy instances 
should quickly and seamlessly take over the traffic share of the downed HAProxy

How can we achieve this?

Thanks!




Information in this e-mail may be confidential. It is intended only for the 
addressee(s) identified above. If you are not the addressee(s), or an employee 
or agent of the addressee(s), please note that any dissemination, distribution, 
or copying of this communication is strictly prohibited. If you have received 
this e-mail in error, please notify the sender of the error.

Re: [PATCH] REGTEST/MINOR: script: add run-regtests.sh script

[Frederic Lecaille]

On 11/27/18 11:17 PM, PiBa-NL wrote:

Hi Frederic, Willy,

Op 27-11-2018 om 15:00 schreef Frederic Lecaille:

On 11/27/18 10:44 AM, Frederic Lecaille wrote:

On 11/27/18 9:52 AM, Willy Tarreau wrote:

Hi guys,

On Tue, Nov 27, 2018 at 09:45:25AM +0100, Frederic Lecaille wrote:

I put the script in the /reg-tests/ folder. Maybe it should have been
besides the Makefile in the / root ?


Yes I think it should be placed at the same level as the Makefile.


Well, we already have a "scripts" directory with the stuff used for
release and backport management. I think it perfectly has its place
there.

/scripts/ sounds good.


Note that the reg tests must be run from the Makefile with 
"reg-tests" target and possibly other arguments/variables.

Willy recently added REG_TEST_FILES variable.


I've changed the the script to include the LEVEL parameter almost the 
way the Makefile used it, changed behavior though so without the 
parameter it it runs all tests.


Ok.



I am sorry Pieter a remaining detail I should have mentioned before:

+  for i in $(find $TESTDIR/ -type d -name "vtc.*");
+  do
+    echo "## $(cat $i/INFO) ##"
+    echo "## test results in: $i"
+    grep --  $i/LOG
+
+    echo "## $(cat $i/INFO) ##" >> $TESTDIR/failedtests.log
+    echo "## test results in: $i" >> $TESTDIR/failedtests.log
+    grep --  $i/LOG >> $TESTDIR/failedtests.log
+    echo >> $TESTDIR/failedtests.log
+  done

may be shortened thanks to tee command like that:

 cat <<- EOF | tee $TESDIR/failedtests.log
 .
 .
 EOF

Removed some spaces for indentation which became part of the output.


To make <<- operator work (I think it is portable) we must
add TABS to align the code. And indeed the remaining spaces are taken
into an account. Let's forget that, it is ok with your modifications.



I have tested you script. For me it is OK. Good job!
Thank you a lot Pieter.


OK just let me know what to do with this, should I merge it as-is and
expect minor updates later, or do you or Pieter want to resend an
updated version ? I can adapt, let me know.


I have modified Pieter's patch for the modification mentioned above.
Seems to work ;)


Willy,

Here is a better patch which takes into an account the modification
above and yours (the script is added in "tests" directory).
I think Willy mentioned a 'scripts' directory? Changed patch to include 
that as well.


Aww yes, sorry.



You can merge it as-is.

Regards,

Fred


New path attached, which includes a LEVEL check.
And a modification of the Makefile to call the ./scripts/run-regtests.sh

Please can someone check it again before merging.?. Thanks guys :).


Perhaps we should "chmod +x" this script.

It is OK on my side.

Thank you Pieter.

Fred.