Video conferencing software Users Info

[Laura Franceschi]

Hi,


I'm writing to inform you that we have maintained a comprehensive mailing list 
of Video conferencing software Users across the Globe with emails, phone 
numbers and mailing addresses.

We also have other technology users like:

Mitel

WebEx

Nortel

ShoreTel

Avaya

Juniper Networks

Alcatel - Lucent

Cisco Systems

AT&T

Brocade

Deutsche Telekom

Huawei

CenturyLink

Fujitsu

BT Contact Center

Verizon

Polycom

Citrix Systems

Arista Networks

Riverbed



If you have any other unique requirement and if it is not mentioned above, 
please feel free to share your requirement with us as we can help you with 
on-demand list customized as per your requirement.

We also provide:-

* Audio conferencing software users list
* IT Resellers/VARS/etc. list
* Call Center/Data Center Decision Makers List
* Telecom Administrators list

Thanks,
Laura Franceschi
Demand Generation-Database Coordinator

If you are not the right person, feel free to forward this email to the right 
person in your organization.

Re: Updates to the stable release process

[Lukas Tribus]

Hello!


Am 08.06.2017 um 17:30 schrieb Willy Tarreau:
> Hi all,
>
> William has joined Cyril an me in the stable maintenance team. We're now
> three to have direct commit access, so don't be surprized if you see
> new names in "git log --format=fuller" or in the gitweb interface.
>

That's a very welcome news, thumbs up!

Timely backports are important and very useful. A part from users
cloning from stable git
trees and those that use snapshot tarballs, we need those backports so
we can check for
known bugs (just like haproxy.org/bugs/) when troubleshooting.


Great!

Lukas

Re: exit error regression on haproxy1.8dev

[Willy Tarreau]

On Thu, Jun 08, 2017 at 08:37:28PM +0200, William Lallemand wrote:
> On Thu, Jun 08, 2017 at 01:49:15PM +0200, William Lallemand wrote:
> >  
> > You are right about the regression, however this part of the code should be
> > called in daemon mode only, the regression was elsewhere :)
> > 
> > Fix attached.
> > 
> 
> Willy, could you apply this one?

sure, now done, thanks.
Willy

Re: exit error regression on haproxy1.8dev

[William Lallemand]

On Thu, Jun 08, 2017 at 01:49:15PM +0200, William Lallemand wrote:
>  
> You are right about the regression, however this part of the code should be
> called in daemon mode only, the regression was elsewhere :)
> 
> Fix attached.
> 

Willy, could you apply this one?

Thanks,

-- 
William Lallemand

Re: [PATCH] BUG/MINOR: warning: 'need_resend' may be used uninitialized

[Willy Tarreau]

On Thu, Jun 08, 2017 at 07:30:39PM +0200, William Lallemand wrote:
> The commit 201c07f68 ("MAJOR/REORG: dns: DNS resolution task and
> requester queues") introduces a warning during compilation:
> 
> src/dns.c: In function 'dns_resolve_recv':
> src/dns.c:487:6: warning: 'need_resend' may be used uninitialized in this 
> function [-Wmaybe-uninitialized]
>if (need_resend) {
>   ^
> 
> This patch initialize the variable and remove the comment about it.

Ah thank you, I noticed it, including the comment, but switched to
something else and forgot to fix it.

Applied, thanks.
Willy

Re: [PATCH] BUG/MEDIUM: build without openssl broken

[Willy Tarreau]

On Thu, Jun 08, 2017 at 07:05:48PM +0200, William Lallemand wrote:
> The commit 872f9c213 ("MEDIUM: ssl: add basic support for OpenSSL crypto
> engine") broke the build without openssl support.

Applied, thanks William.

Willy

[PATCH] BUG/MINOR: warning: ‘need_resend’ may be used uninitialized

[William Lallemand]

The commit 201c07f68 ("MAJOR/REORG: dns: DNS resolution task and
requester queues") introduces a warning during compilation:

src/dns.c: In function ‘dns_resolve_recv’:
src/dns.c:487:6: warning: ‘need_resend’ may be used uninitialized in this 
function [-Wmaybe-uninitialized]
   if (need_resend) {
  ^

This patch initialize the variable and remove the comment about it.
---
 src/dns.c | 8 +---
 1 file changed, 1 insertion(+), 7 deletions(-)

diff --git a/src/dns.c b/src/dns.c
index cb7de6ab..78ee62bc 100644
--- a/src/dns.c
+++ b/src/dns.c
@@ -322,7 +322,7 @@ void dns_resolve_recv(struct dgram_conn *dgram)
struct dns_query_item *query;
unsigned char buf[DNS_MAX_UDP_MESSAGE + 1];
unsigned char *bufend;
-   int fd, buflen, dns_resp, need_resend;
+   int fd, buflen, dns_resp, need_resend = 0;
unsigned short query_id;
struct eb32_node *eb;
struct lru64 *lru = NULL;
@@ -387,12 +387,6 @@ void dns_resolve_recv(struct dgram_conn *dgram)
 
dns_resp = dns_validate_dns_response(buf, bufend, resolution);
 
-   /* treat errors first
-* need_resend flag could be set to 0 by default before the 
'switch' and then
-* set to 1 only where needed, but I think it's better this way 
to make people
-* aware they have to think twice how to set this flag when 
updating this portion
-* of the code
-*/
switch (dns_resp) {
case DNS_RESP_VALID:
need_resend = 0;
-- 
2.13.0

[PATCH] BUG/MEDIUM: build without openssl broken

[William Lallemand]

The commit 872f9c213 ("MEDIUM: ssl: add basic support for OpenSSL crypto
engine") broke the build without openssl support.

The ssl_free_dh() function is not defined when USE_OPENSSL is not
defined and leads to a compilation failure.
---
 src/haproxy.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/haproxy.c b/src/haproxy.c
index 60bd334b..9cbb3d5c 100644
--- a/src/haproxy.c
+++ b/src/haproxy.c
@@ -2575,7 +2575,7 @@ int main(int argc, char **argv)
protocol_unbind_all();
mworker_wait();
}
-#ifndef OPENSSL_NO_DH
+#if defined(USE_OPENSSL) && !defined(OPENSSL_NO_DH)
ssl_free_dh();
 #endif
/* should never get there */
-- 
2.13.0

Updates to the stable release process

[Willy Tarreau]

Hi all,

William has joined Cyril an me in the stable maintenance team. We're now
three to have direct commit access, so don't be surprized if you see
new names in "git log --format=fuller" or in the gitweb interface. In
order to ease tracking of who handles what patch, we'll progressively
start to sign-off our patches. Till now eventhough welcome this has never
been required (and as long as we can avoid bureaucratic rules we'll do)
but we'll start to do it for stable backports and maybe progressively
for other ones as well on a voluntary basis.

At the moment I'm writing this, it's still not possible for either Cyril
nor William to release nor publish a version, it's a limitation caused
by the current release process, but I've started to work on this and it
should be addressed at the same time the download speed issues will be
fixed.

Now that we're 3, it's even more important that users who want to request
a backport contact stable at haproxy.org instead of just me. Asking here
on the list still remains the best option though.

Please be nice, the process is still a bit error-prone and we're
adjusting it so a few mistakes are expected from all of us for the short
term but nothing alarming. I *hope* to be able to finalize the changes
before 1.7.6 so that we can use it to validate the new process.

I'll keep everyone updated once changes are completed.

Willy

RE: OneConnect feature in HAProxy

[Gibson, Brian (IMS)]

The IUS repos will have 1.7 I believe.

https://ius.io/GettingStarted/

From: James Stroehmann [mailto:james.stroehm...@proquest.com]
Sent: Thursday, June 08, 2017 10:27 AM
To: Brendan Kearney ; haproxy@formilux.org
Subject: RE: OneConnect feature in HAProxy

Thanks for the info - I will look into it but it looks like I'll have to 
upgrade to 1.6 first ... currently I'm using 1.5 out of the standard 
repositories for centos 7.

Any pointers to a yum repo for 1.6 or 1.7?



From: Brendan Kearney [mailto:bpk...@gmail.com]
Sent: Thursday, May 25, 2017 8:36 AM
To: haproxy@formilux.org
Subject: Re: OneConnect feature in HAProxy

[External Email]
On 05/25/2017 08:26 AM, James Stroehmann wrote:
Is there a feature in HAProxy similar to OneConnect that the F5 LTM has? 
https://www.f5.com/pdf/deployment-guides/oneconnect-tuning-dg.pdf

I am trying to migrate some frontends from an LTM to an HAProxy load balancer, 
and a few of the existing frontends have the OneConnect feature turned on. I 
spoke to the app owner and he believes that it allows us to have less 
connections (and therefore less backend servers) and it enables more seamless 
rolling bounces on the stateless backends.

http-reuse is the directive you are looking for.



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: OneConnect feature in HAProxy

[James Stroehmann]

Thanks for the info - I will look into it but it looks like I'll have to 
upgrade to 1.6 first ... currently I'm using 1.5 out of the standard 
repositories for centos 7.

Any pointers to a yum repo for 1.6 or 1.7?



From: Brendan Kearney [mailto:bpk...@gmail.com]
Sent: Thursday, May 25, 2017 8:36 AM
To: haproxy@formilux.org
Subject: Re: OneConnect feature in HAProxy

[External Email]
On 05/25/2017 08:26 AM, James Stroehmann wrote:
Is there a feature in HAProxy similar to OneConnect that the F5 LTM has? 
https://www.f5.com/pdf/deployment-guides/oneconnect-tuning-dg.pdf

I am trying to migrate some frontends from an LTM to an HAProxy load balancer, 
and a few of the existing frontends have the OneConnect feature turned on. I 
spoke to the app owner and he believes that it allows us to have less 
connections (and therefore less backend servers) and it enables more seamless 
rolling bounces on the stateless backends.

http-reuse is the directive you are looking for.

RE: High Availability for haproxy itself

[Gibson, Brian (IMS)]

You could do something like this.  Setup the haproxy status page on the haproxy 
server.

Then create a bash script with syntax like this

#!/bin/bash
#

value=$(curl -I http://www.example.org 2>/dev/null | head -n 1 | cut -d$' ' -f2)

if [ $value -eq 200 ]
then
  exit
else
  exit 1
fi

that will return 0 if it's up and 1 if it's down.

So if you change your track_script to use that bash script it'll then base 
whether or not haproxy is up based on if it can access that status page.

-Original Message-
From: Markus Rietzler [mailto:w...@mrietzler.de]
Sent: Thursday, June 08, 2017 8:32 AM
To: haproxy@formilux.org
Subject: Re: High Availability for haproxy itself

Am 02.06.17 um 11:35 schrieb Raphaël Enrici:
> Hi,
>
> if you are in a simple case where you only need some kind of active/passive 
> solution without big scaling needs on a
> Linux system, look for "haproxy keepalived" on your favorite search engine, 
> you'll find many articles explaining the way
> to go.
>
> If you need HA and horizontal scaling, take a look at the article from 
> Vincent Bernat here:
> https://vincent.bernat.im/en/blog/2013-exabgp-highavailability
>
> HTH,
> Raph
>
>
> Le 2017-06-02 10:34, Jiafan Zhou a écrit :
>> Hi,
>>
>> Haproxy ensures the HA for real servers such as httpd. However, in the
>> case of haproxy itself, if it fails, then it requires another instance
>> of haproxy to be ready. Is there any High Availability solution for
>> haproxy itself?
>>
>> Regards,
>> Jiafan
>
>
Hi,
keepalived works very well. i have a setup with haproxy running on two VM which 
are connected via keepalived.
the node (to be exact the virtual IP address) is switched if i stop haproxy on 
my master. then haproxy on my fallback
node will "jump in". if i restart haproxy on master the IP is switched back...
this works very stable in the last years.

the only thing which i could optimize is the healthcheck in keepalived. at the 
moment i do a simple "is the process
running" (killall -0 haproxy) test.

i think this could be optimized. Eg. don't know if it would recognise a hanging 
haproxy process correctly. maybe it
would be better to do some http access and look at the answer (eg. do i get an 
"OK" back) or check the response time and
switch if it tooks too long...


Markus




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: High Availability for haproxy itself

[Markus Rietzler]

Am 02.06.17 um 11:35 schrieb Raphaël Enrici:
> Hi,
> 
> if you are in a simple case where you only need some kind of active/passive 
> solution without big scaling needs on a
> Linux system, look for "haproxy keepalived" on your favorite search engine, 
> you'll find many articles explaining the way
> to go.
> 
> If you need HA and horizontal scaling, take a look at the article from 
> Vincent Bernat here:
> https://vincent.bernat.im/en/blog/2013-exabgp-highavailability
> 
> HTH,
> Raph
> 
> 
> Le 2017-06-02 10:34, Jiafan Zhou a écrit :
>> Hi,
>>
>> Haproxy ensures the HA for real servers such as httpd. However, in the
>> case of haproxy itself, if it fails, then it requires another instance
>> of haproxy to be ready. Is there any High Availability solution for
>> haproxy itself?
>>
>> Regards,
>> Jiafan
> 
> 
Hi,
keepalived works very well. i have a setup with haproxy running on two VM which 
are connected via keepalived.
the node (to be exact the virtual IP address) is switched if i stop haproxy on 
my master. then haproxy on my fallback
node will "jump in". if i restart haproxy on master the IP is switched back...
this works very stable in the last years.

the only thing which i could optimize is the healthcheck in keepalived. at the 
moment i do a simple "is the process
running" (killall -0 haproxy) test.

i think this could be optimized. Eg. don't know if it would recognise a hanging 
haproxy process correctly. maybe it
would be better to do some http access and look at the answer (eg. do i get an 
"OK" back) or check the response time and
switch if it tooks too long...


Markus

HAPROXY HELP REQUIRED -- please contact

[Vasudev Daxini]

Regards,
Vasudev Daxini,??RHCE
(M) +91-9920347199

Re: exit error regression on haproxy1.8dev

[William Lallemand]

On Wed, Jun 07, 2017 at 02:13:58PM +0200, Emmanuel Hocdet wrote:
> 
> > Le 7 juin 2017 à 10:34, Emmanuel Hocdet  a écrit :
> > 
> > Hi,
> > 
> > ok:
> >> haproxy -f test.cfg -W
> >> echo $?
> > 0
> > 
> > bad:
> >> haproxy -f test.cfg
> >> echo $?
> > 1
> > 
> > With bunch of modified code, i am a little lost to track the bug.
> > 
> > Manu
> > 
> > 
> 
 
You are right about the regression, however this part of the code should be
called in daemon mode only, the regression was elsewhere :)

Fix attached.

-- 
William Lallemand
>From 4171380e2ff3d562bfcf4f7aa5325d79ccda025b Mon Sep 17 00:00:00 2001
From: William Lallemand 
Date: Wed, 7 Jun 2017 15:04:47 +0200
Subject: [PATCH] BUG/MEDIUM: misplaced exit and wrong exit code

Commit cb11fd2 ("MEDIUM: mworker: wait mode on reload failure")
introduced a regression, when HAProxy is used in daemon mode, it exits 1
after forking its children.

HAProxy should exit(0), the exit(EXIT_FAILURE) was expected to be use
when the master fail in master-worker mode.

Thanks to Emmanuel Hocdet for reporting this bug. No backport needed.
---
 src/haproxy.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/src/haproxy.c b/src/haproxy.c
index 60bd334b..51cdf48e 100644
--- a/src/haproxy.c
+++ b/src/haproxy.c
@@ -2574,12 +2574,13 @@ int main(int argc, char **argv)
 			if (global.mode & MODE_MWORKER) {
 protocol_unbind_all();
 mworker_wait();
+/* should never get there */
+exit(EXIT_FAILURE);
 			}
 #ifndef OPENSSL_NO_DH
 			ssl_free_dh();
 #endif
-			/* should never get there */
-			exit(EXIT_FAILURE);
+			exit(0); /* parent must leave */
 		}
 
 		/* child must never use the atexit function */
-- 
2.13.0

subscribe

[David Pollock]

-- 


Any e-mail sent from Alternative Payments Ltd or its Group companies may 
contain information which is confidential and/or privileged. Unless you are 
the intended recipient you may not disclose, copy or use it; please notify 
the sender immediately and delete it and any copies. You should protect 
your system from viruses etc.; we accept no responsibility for damage that 
may be caused by them.

RE: Regarding migration on version haproxy-1.7.3

[Coscend@HAProxy]

Hello Devendra,

In the spirit of assisting, further to Pavlos' insights, you might want to 
check 

Baptiste Assman's blog on 1.5 vs. 1.6 below.  It is our understanding that the 
new features in 1.6 have been mostly carried over to 1.7 as well.
https://www.haproxy.com/blog/whats-new-in-haproxy-1-6/ 
Examples include bind :, environmental variables

Willy Tarreau's note during general release of 1.6:  
https://www.mail-archive.com/haproxy@formilux.org/msg19877.html
1.7: https://www.mail-archive.com/haproxy@formilux.org/msg24244.html 

Thank you.

Sincerely,

Hemant K. Sabat
 
Coscend Communications Solutions
www.Coscend.com 
--
Real-time, Interactive Video Collaboration, Tele-healthcare, Tele-education, 
Telepresence Services, on the fly…
--
CONFIDENTIALITY NOTICE: See 'Confidentiality Notice Regarding E-mail Messages 
from Coscend Communications Solutions' posted at: 
http://www.Coscend.com/Terms_and_Conditions.html 



-Original Message-
From: Pavlos Parissis [mailto:pavlos.paris...@gmail.com] 
Sent: Thursday, June 8, 2017 2:53 AM
To: Devendra Joshi ; haproxy@formilux.org
Subject: Re: Regarding migration on version haproxy-1.7.3

On 06/08/2017 07:31 AM, Devendra Joshi wrote:
> Hi,
> currently we are using haproxy-1.5.14 & now we want to migrate on 
> haproxy-1.7.3 
>  %22%5C%5BANNOUNCE%5C%5D+haproxy%5C-1.7.3%22&o=newest>
> 
> is there any config changes or need to do some setting.
> 

You should always test a software before you push it to production.
In most of the cases I have seen the upgrade is very smooth, but it depends on 
the configuration.
Some people never change the config they created with 1.4 version and get in 
troubles when they upgrade to 1.6 or 1.7 version.

Just build a test machine, load the config, check for errors and then test it 
with some traffic.
In case of troubles in production after the upgrade, you can easily roll back 
by downgrading the package.

1.7.6 version is coming soon, so you may want to wait few days for that one to 
be released before you upgrade production.

Cheers,
Pavlos

Re: Regarding migration on version haproxy-1.7.3

[Pavlos Parissis]

On 06/08/2017 07:31 AM, Devendra Joshi wrote:
> Hi,
> currently we are using haproxy-1.5.14 & now we want to migrate on 
> haproxy-1.7.3
> 
> 
> is there any config changes or need to do some setting.
> 

You should always test a software before you push it to production.
In most of the cases I have seen the upgrade is very smooth, but it depends on 
the configuration.
Some people never change the config they created with 1.4 version and get in 
troubles when they
upgrade to 1.6 or 1.7 version.

Just build a test machine, load the config, check for errors and then test it 
with some traffic.
In case of troubles in production after the upgrade, you can easily roll back 
by downgrading the
package.

1.7.6 version is coming soon, so you may want to wait few days for that one to 
be released before
you upgrade production.

Cheers,
Pavlos



signature.asc
Description: OpenPGP digital signature