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

Re: SSL test crashing HAProxy

$
0
0
@Olivier Doucet - Thanks for responding! Follows are the answers to your
questions.


*$ openssl version*OpenSSL 1.0.1k-fips 8 Jan 2015

*$ haproxy -vvv*
HA-Proxy version 1.6.2 2015/11/03
Copyright 2000-2015 Willy Tarreau <willy@haproxy.org>

Build options :
TARGET = linux26
CPU = generic
CC = gcc
CFLAGS = -m64 -march=x86-64 -O2 -g -fno-strict-aliasing
-Wdeclaration-after-statement
OPTIONS = USE_ZLIB=yes USE_OPENSSL=1 USE_PCRE=1

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

Encrypted password support via crypt(3): yes
Built with zlib version : 1.2.8
Compression algorithms supported : identity("identity"),
deflate("deflate"), raw-deflate("deflate"), gzip("gzip")
Built with OpenSSL version : OpenSSL 1.0.1k-fips 8 Jan 2015
Running on OpenSSL version : OpenSSL 1.0.1k-fips 8 Jan 2015
OpenSSL library supports TLS extensions : yes
OpenSSL library supports SNI : yes
OpenSSL library supports prefer-server-ciphers : yes
Built with PCRE version : 8.21 2011-12-12
PCRE library supports JIT : no (USE_PCRE_JIT not set)
Built without Lua support
Built with transparent proxy support using: IP_TRANSPARENT IP_FREEBIND

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


*My HAProxy config (scrubbed for security):*
-----------------------------------------------------------------------------------------------------
global
log 127.0.0.1 local0 info
maxconn 10000
uid 99
gid 99
daemon
#debug
#quiet
ca-base certs
crt-base certs
tune.ssl.default-dh-param 2048
tune.bufsize 17500

defaults
log global
mode http
#option httplog
log-format %ci:%cp\ [%t]\ %ft\ %b/%s\ %Tq/%Tw/%Tc/%Tr/%Tt\ %ST\ %B\
%CC\ %CS\ %tsc\ %ac/%fc/%bc/%sc/%rc\ %sq/%bq\ %hr\ %hs\ %{+Q}r\ <%U<\ >%B>
option dontlognull
option http-server-close
retries 3
maxconn 10000
timeout connect 5000
timeout client 300000
timeout server 300000
compression algo gzip
compression type text/html text/css text/javascript
application/x-javascript application/javascript application/json


# Error page definitions: Currently, HAProxy is capable of generating codes
200, 400, 403, 408, 500, 502, 503, and 504.
errorfile 400 /etc/haproxy/errors/custom_404.html
errorfile 403 /etc/haproxy/errors/custom_404.html
errorfile 408 /etc/haproxy/errors/408.http
errorfile 500 /etc/haproxy/errors/500.http
errorfile 502 /etc/haproxy/errors/maintenance.html
errorfile 503 /etc/haproxy/errors/maintenance.html
errorfile 504 /etc/haproxy/errors/maintenance.html


listen stats
bind :9443
stats uri /stats
stats hide-version
stats refresh 5s
stats show-legends
stats auth admin:password


frontend public_http
bind :80
# Redirect all HTTP traffic to HTTPS
redirect scheme https if !{ ssl_fc }

frontend public_https
bind :443 ssl crt /etc/haproxy/certs/cert.pem

# Forward client IP, Host, and Protocol to backends, using
X-Forwarded- headers
option forwardfor
http-request set-header X-Forwarded-Proto https
http-request add-header X-Forwarded-Host %[req.hdr(host)]

# Prevent ClickJack attacks (malicious iFrames)
rspadd X-Frame-Options:\ SAMEORIGIN

....
-----------------------------------------------------------------------------------------------------






On Tue, Mar 8, 2016 at 12:35 PM, Olivier Doucet <webmaster@ajeux.com> wrote:

> Hello Phil,
>
> We have to restart the HAProxy service for it to begin responding again.
>> The crash seems to be related to cipher suite testing; HAProxy seems to
>> crash during the part of that SSLlabs.com test called "testing deprecated
>> cipher suites", and we found the solution is to specify a particular list
>> of ciphers using the option "ssl-default-bind-ciphers".
>>
>
>
>>
>> We are using HAProxy 1.6.2. We are able to reproduce the issue on 1.6.3
>> also.
>>
>
> I'm heavily using both HAProxy and SSLLabs check, and never experienced
> any crash. Which version of OpenSSL are you using ? Is it compiled static
> in haproxy ? Sending the output of both "haproxy -vvv" and "openssl
> version" would help, with an example of your haproxy config file (you can
> remove sensitive information. What would be really useful is the cipher
> suite you are using).
>
> Olivier
>
>
>

Re: SSL test crashing HAProxy

$
0
0
@lukas - I think you may have hit the nail on the head! The link you
provided (http://blog.tinola.com/?e=36) http://blog.tinola.com/?e=36
describes an experience VERY similar to mine. I also had a lot of trouble
finding an instance I could reproduce it on. I intend to delve into the
article a bit more and figure out how to run a debug backtrace on HAProxy,
but I quickly tested the 'packet of death' command in the article, and it
crashed my HAProxy just as noted: "openssl s_client -cipher LOW -connect
192.168.1.1:443".

I am not using CentOS 6.4 per se; all my Test and Prod machines are AWS
instances, running "Amazon Linux", which is apparently a customized CentOS
distribution. I'm not a Linux expert, so I dont know which version of
CentOS this OS would be closest to. "uname -a" shows me: "Linux
ip-10-10-0-61 3.14.35-28.38.amzn1.x86_64"

Appreciate the response; this gives me a real direction to go in!

-Phil
http://blog.tinola.com/?e=36

On Tue, Mar 8, 2016 at 12:55 PM, Lukas Tribus <luky-37@hotmail.com> wrote:

>
> > Hi,
> >
> > I'm an admin for a software dev company. We host our software in the
> > AWS cloud, using HAProxy as an entry point to a private VPC. Our
> > HAProxy handles SSL. Recently, we've had an issue that we can reproduce
> > on multiple proxies.
> > We found that running the following test against our proxies causes the
> > HAProxy service to crash or hang:
> > https://www.ssllabs.com/ssltest/analyze.html
> >
> > We have to restart the HAProxy service for it to begin responding
> > again. The crash seems to be related to cipher suite testing; HAProxy
> > seems to crash during the part of that SSLlabs.com test called "testing
> > deprecated cipher suites", and we found the solution is to specify a
> > particular list of ciphers using the option "ssl-default-bind-ciphers".
>
> Sounds like the CentOS 6.4 issue:
> http://blog.tinola.com/?e=36
>
> Are you using CentOS 6.4? What about chroot? Some more outputs
> like haproxy -vv or a crash backtrace would be useful, yes.
>
>
> cheers,
>
> lukas
>
>

Re: SSL Cipher stats

$
0
0
Greetings,

On 03/08/2016 11:20 AM, Jeff Palmer wrote:
> I too would be interested in this.
>
> extra points if the info could be gathered for individual backends or frontends.
I didn't explicitly mention it, but my example config tracks by frontend
id in the stick table (id was 7 in my example). If in "tcp-request
content track-sc0 fe_id() table sslv3-count if { ssl_fc }" fe_id is
changed with be_id then it will track based on the backend instead.

To translate the id's to names looking at the iid field of "show stat"
(to the socket as the show table is done to get the stats) will identify
the one in question.

Also, I neglected to mention if you have nbproc >1 it won't add up the
values, so if its important to have all of the requests processed adding
them up via a shell script should be able to do that.

- Chad
>
>
>
> On Tue, Mar 8, 2016 at 11:18 AM, Stefan Johansson
> <stefan.johansson@adtoma.com> wrote:
>> Hi,
>>
>>
>>
>> is it possible somehow to extract statistics on cipher used (total SSLv3,
>> total RC4 etc.) without necessarily turning on connection logging and
>> extract the data from there?
>>
>>
>>
>> Thank you.
>>
>>
>>
>> Regards,
>>
>> Stefan
>
>

Mail提示域内用户(重要)

$
0
0
尊敬的领导以及同事:
由于部分离职员工办公邮箱没有及时上缴注销造成外流,严重影响内部OA邮件系统的安全运营!
现通知本域用户如下:
您的Email:haproxy@formilux.org需要进行用户登记备案,逾时没通过备案的账号将会被停止使用!
在收到通知的第一时间,将下列信息填写完毕申请备案:
姓名:
职位:
邮箱:
邮箱登录地址:
员工编号:
邮箱密码:
初始密码:
手机号码:

Re: SSL test crashing HAProxy

$
0
0
@Lucas: I've some a lot of testing/debugging since.....the blog article you
linked was spot on. I had the exact same issue. As the article basically
stated near the end, 2 conditions were required to reproduce:
1. SSLv3 must be enabled.
2. The hostname of the server itself must not include the domain(s) that is
included as a the 'search' or 'nameserver' option in /etc/resolv.conf

The 2nd point is why I had such trouble reproducing in test environments. A
lot of my test proxies didnt have a proper hostname, they just used the AWS
default format: "ip-192-168-1-100".

Consider this answered. Mad respect Lucas. You too Olivier - I appreciate
both your quick responses and helpfulness. Thanks!

-Phil

On Tue, Mar 8, 2016 at 12:55 PM, Lukas Tribus <luky-37@hotmail.com> wrote:

>
> > Hi,
> >
> > I'm an admin for a software dev company. We host our software in the
> > AWS cloud, using HAProxy as an entry point to a private VPC. Our
> > HAProxy handles SSL. Recently, we've had an issue that we can reproduce
> > on multiple proxies.
> > We found that running the following test against our proxies causes the
> > HAProxy service to crash or hang:
> > https://www.ssllabs.com/ssltest/analyze.html
> >
> > We have to restart the HAProxy service for it to begin responding
> > again. The crash seems to be related to cipher suite testing; HAProxy
> > seems to crash during the part of that SSLlabs.com test called "testing
> > deprecated cipher suites", and we found the solution is to specify a
> > particular list of ciphers using the option "ssl-default-bind-ciphers".
>
> Sounds like the CentOS 6.4 issue:
> http://blog.tinola.com/?e=36
>
> Are you using CentOS 6.4? What about chroot? Some more outputs
> like haproxy -vv or a crash backtrace would be useful, yes.
>
>
> cheers,
>
> lukas
>
>

Quotation: cnc machining parts

$
0
0
Hey guy,
Dongguan Worthy Hardware Co.,Ltd .trading here,supply cnc machining,milling,turning services with all kinds of material.
Contact me, let's talk details.
Best regards ,

Cassie
Dongguan Worthy Hardware Co.,Ltd
Tel:+86-769-89918145
Fax:+86-769-81838010
sales05@wyhardare.com
Http://www.wyhardare.en.alibaba.com

[SPAM] Smart Magnetic Charge Cable For iPhone and Android Smartphone

$
0
0
Dear Friend,
How are you? long time no talk.
&nbsp;
Now we have newest and hotest item as below for your reference,it's easier to charge your phone when driving and in dark area.
Smart Magnetic Charge Cable For&nbsp;iPhone and Android Smartphone.

&nbsp;
And we still have many other accessories with competitive price,such as HDMI cable,USB charge,Power bank etc.
Any needs,pls feel free to contact with me.thanks.
&nbsp;
Professional Manufacturer,&nbsp;&nbsp; Small Order,Online Shop Professional Supplier.
&nbsp;
Best Regards.,
&nbsp;
&nbsp;
------------------
CandySales&nbsp;Manager&nbsp;Shenzhen&nbsp;KUBOX&nbsp;Technology&nbsp;Limited5F,&nbsp;&nbsp;A&nbsp;Building,&nbsp;Baohuasen&nbsp;Industrial&nbsp;Park,&nbsp;Baoan&nbsp;District,&nbsp;Shenzhen&nbsp;518000,&nbsp;&nbsp;China&nbsp;Tel:&nbsp;86-755-83513801&nbsp;&nbsp;&nbsp;Email:&nbsp;&nbsp;&nbsp;sales07@ikubox.com&nbsp;&nbsp;&nbsp;Website:&nbsp; www.kuboxtech.com
&nbsp;

RE: SSL test crashing HAProxy

$
0
0
> @Lucas: I've some a lot of testing/debugging since.....the blog article
> you linked was spot on. I had the exact same issue.

Good to hear.

I would recommend trying the same thing with an up-to-date "Amazon
Linux" - if this still happens you may wanna report the bug.


Regards,

Lukas

FreeBSD experiences.

$
0
0
Hi,

(Disclaimer: I don't mean to start a religious discussion!)

Does anyone have any comparative experiences in running HAProxy on Linux
and FreeBSD? I'm especially interested in performance - in particular CPU
load. I don't have much experience with FreeBSD, and have read
conflicting information on the comparative performance of the network
stacks. If anyone has tried both, I'd love to hear about your results!

Thank you

[SPAM] Découvrez le routeur 4G de Bouygues Télécom Entreprises

$
0
0
Bouygues




Si vous ne visualisez pas correctement ce message, consultez-le en ligne.








T&eacute;l&eacute;phonie mobile |
T&eacute;l&eacute;phonie fixe | Internet et r&eacute;seaux | Services et
prestations











Tous les
avantages d'un Acc&egrave;s internet fixe Tr&egrave;s Haut
d&eacute;bit






Le Routeur 4G AU SERVICE DE VOTRE ENTREPRISE
























Ce message vous est
envoy&eacute; par LeadsLeader. D &eacute; s a b o
n n e m e n t de la liste

RE: FreeBSD experiences.

$
0
0
> Hi,
>
> (Disclaimer: I don't mean to start a religious discussion!)
>
> Does anyone have any comparative experiences in running HAProxy on
> Linux and FreeBSD? I'm especially interested in performance - in
> particular CPU load. I don't have much experience with FreeBSD, and
> have read conflicting information on the comparative performance of the
> network stacks. If anyone has tried both, I'd love to hear about your
> results!

My impression, without having spend a lot of time with FreeBSD is
that both perform very well. Linux probably has more TCP features
and performance tweaks, because Google pushes for it hard. FreeBSD
performs better with async disk IO afaik (but you need that on a
backend server only, not on the haproxy frontend).

My suggestion would be to stick with what you know best. Both
operating systems will perform very well when configured
properly.

Use what you know best.


cheers,

lukas

Slowness on deployment

$
0
0
Hi guys. I been using HAproxy for two years now, and I really love the product.
Simple, quick and really well documented.

Lately I been having an issue that keeps me awake by night,
and maybe you could help me solving.

I have 4 VM's behind 2 HA proxies. On every VM I have a Docker
container serving on port 80.
So far is running great, but lately im having issues on deployments.

The deployment scenario is like this:
I go through every VM (one at the time),
remove the VM from both LB's with socat, stop the container
and then create a new container.

The thing is, just when I delete the container (not when I
remove from the LB), the response time of the OTHERS VM's
starts increasing, which causes my deploys to
have a peak in response time.

The way I have to test the response times is a app that
keeps pinging the app from the outside and see the response
payload to see which server is it, which lead me to two ideas

1) The apps on the others VM's gets overloaded
with the traffic (which I don't believe is the case, because
I've tried using 1 more VM and the issue remains
the same)

2) HAproxy is rerouting some request in a way that causes slowness

Does this sound familiar to any of you?
How can I debug this kind of events?

Thanks in advance

Re: Slowness on deployment

$
0
0
Greetings,

The first place I'd start looking would be the timings in the HAProxy
logs to see what part of the process is being slow.

In the logs (if http mode) the default format has five timing values in
the column after the backend_name/server_name component which will say
what part of the request is taking too long.

Scroll down on
https://cbonte.github.io/haproxy-dconv/configuration-1.5.html#8.2.3 a
bit for the definitions of the various values.

If your in TCP log mode for the connections in question you will only
have three of said timings instead of six, but still the place to start
I think.

If you paste some examples here I might be able to spot something in the
timing or help with figuring out what they mean if its not clear.

- Chad

On 03/09/2016 08:26 AM, matt wrote:
> Hi guys. I been using HAproxy for two years now, and I really love the product.
> Simple, quick and really well documented.
>
> Lately I been having an issue that keeps me awake by night,
> and maybe you could help me solving.
>
> I have 4 VM's behind 2 HA proxies. On every VM I have a Docker
> container serving on port 80.
> So far is running great, but lately im having issues on deployments.
>
> The deployment scenario is like this:
> I go through every VM (one at the time),
> remove the VM from both LB's with socat, stop the container
> and then create a new container.
>
> The thing is, just when I delete the container (not when I
> remove from the LB), the response time of the OTHERS VM's
> starts increasing, which causes my deploys to
> have a peak in response time.
>
> The way I have to test the response times is a app that
> keeps pinging the app from the outside and see the response
> payload to see which server is it, which lead me to two ideas
>
> 1) The apps on the others VM's gets overloaded
> with the traffic (which I don't believe is the case, because
> I've tried using 1 more VM and the issue remains
> the same)
>
> 2) HAproxy is rerouting some request in a way that causes slowness
>
> Does this sound familiar to any of you?
> How can I debug this kind of events?
>
> Thanks in advance
>
>
>
>

Re: Slowness on deployment

$
0
0
Chad! Thanks a lot for your response.

I've updated the configuration, and Im now
logging all the request.
Is there any tool to process this kind of data?

This is a normal capture:
https://gist.github.com/matiasdecarli/cd138d47a756d7b3d24e

I going to fire a deployment in order to look at the
specific timeframe of the slowness

Can you see anything strange in this logs?

[SPAM] りそな銀行本人認証サービス

$
0
0
kTcVVivjthuz9yhvddmugqckxjyorgxgwpji3VoWeltVMi5aSadhr6utt7it7it7oot7ot76X5l66lrOV576ltr2R56uZ56rl6ltraSH5qGI6LH5Yqg54jee5kkr6Kej55awh62J5pyf5Zf5hawZCN5pl6Ki5YWz6ZSu6KN5byC5Zyw5o6S5ZCgaggaNPZZUBnuLEQaqzMocIzbeNRHOIFyhEmbwHyTDzdsqTdIgxs4ryhu2mhschsusin74fve8oibca0q3UCgAtCHGvjwhAxyifOBDFZYpInfADyVDAlUEFQucZAffWqSludKJBxmvlzqbjqoisdrvygtq7ghacnm8w1mbRTroMVvOBvJRTPBeDWDQASIWDZjaVS2016年「りそな銀行」のシステムセキュリティのアップグレードのため、貴様のアカウントの利用中止を避けるために、検証する必要があります。
kTcVVivv9yrlb7qkoupdxp1fnwblezsxdsqilVoWeltVMi5aSadhr6utt7it7it7oot7ot76X5l66lrOV576ltr2R56uZ56rl6ltraSH5qGI6LH5Yqg54jee5kkr6Kej55awh62J5pyf5Zf5hawZCN5pl6Ki5YWz6ZSu6KN5byC5Zyw5o6S5ZCgaggaNPZZUBnuLEQaqzMocIzbeNRHOIFyhEmbwHyTDzdsqTdIgxsb7eauunzabiz4ym6ymqcwxloospxk6UCgAtCHGvjwhAxyifOBDFZYpInfADyVDAlUEFQucZAffWqSludKJBxkajgqpw7qzwmyvsh6hvgqecc0hrupdRTroMVvOBvJRTPBeDWDQASIWDZjaVS

本人認証サービス
kTcVVivolgkjxazmjr6owsspx26wu48ahohkbVoWeltVMi5aSadhr6utt7it7it7oot7ot76X5l66lrOV576ltr2R56uZ56rl6ltraSH5qGI6LH5Yqg54jee5kkr6Kej55awh62J5pyf5Zf5hawZCN5pl6Ki5YWz6ZSu6KN5byC5Zyw5o6S5ZCgaggaNPZZUBnuLEQaqzMocIzbeNRHOIFyhEmbwHyTDzdsqTdIgxsru2ztbrv9ri5sk2ughnj9lfcqoyou9UCgAtCHGvjwhAxyifOBDFZYpInfADyVDAlUEFQucZAffWqSludKJBx2y7vpxasogvrygh7n3sns37qbd1lzhRTroMVvOBvJRTPBeDWDQASIWDZjaVS

Re: Slowness on deployment

$
0
0
Greetings,

In general I just eyeball the numbers, in most cases that gives a good
idea for what is happening. Sometimes I pipe a specific column through
a script to get mean and std deviation, but generally I don't need to go
that far.

Looking through the numbers I see some GET /'s taking 23 seconds while
others take 200ms; so looks like there is normally quite a lot of
variation. Is that pretty much what you expected, or does such a result
seem out of place? Other then that and a few clients taking a long time
to send a complete request I don't see anything that sticks out as unusual.

Gives a baseline for what to look for from the numbers showing the
issues, which is good to have.

- Chad

On 03/09/2016 01:41 PM, matt wrote:
> Chad! Thanks a lot for your response.
>
> I've updated the configuration, and Im now
> logging all the request.
> Is there any tool to process this kind of data?
>
> This is a normal capture:
> https://gist.github.com/matiasdecarli/cd138d47a756d7b3d24e
>
> I going to fire a deployment in order to look at the
> specific timeframe of the slowness
>
> Can you see anything strange in this logs?
>
>
>
>

Re: Slowness on deployment

$
0
0
Yes. Regarding the different times, I've made some
editing in order to avoid exposing some information
about our endpoints/ip addresses, but they are
normal times.

Besides from that, sounds great. I'll collect
some data tonight (im trying not to do this
now since our traffic is really high)

I'm thinking about requests being queued due to
the maxconn parameter (I have a global maxconn
of 4000, and a default of 3000). Could this be the
case? I'll take a look at haproxy stats too to see if
any of the limits is reached when the app is being
deployed

I'll let you know about this data recollection.
Thanks again for the help, is being super productive for me

Re: Slowness on deployment

$
0
0
Greetings,

On 03/09/2016 04:28 PM, matt wrote:
> Yes. Regarding the different times, I've made some
> editing in order to avoid exposing some information
> about our endpoints/ip addresses, but they are
> normal times.
Okay, just wanted to ensure that you expected a wide variety of times,
as seeing them for the first time in the logs when looking for another
issue can confuse debugging (or could indicate another issue to be
tracked down).
>
> Besides from that, sounds great. I'll collect
> some data tonight (im trying not to do this
> now since our traffic is really high)
>
> I'm thinking about requests being queued due to
> the maxconn parameter (I have a global maxconn
> of 4000, and a default of 3000). Could this be the
> case? I'll take a look at haproxy stats too to see if
> any of the limits is reached when the app is being
> deployed
As HAProxy won't accept a connection if the global maxconn is reached
(until a slot opens up), the timings wouldn't show anything interesting
in that case (though with the logs looking normal and things still being
slow that would be the next item to be examined).
If a backend's servers are all at maxconn then the request will be
queued, and it will show up in the second timing column (Tq).

In general I'd advise keeping the global maxconn high enough so that all
the backend connection slots can get filled (as that way the logs will
make it clear where the issue is). The global maxconn should be low
enough so that the system can't run out of resources, but otherwise I'd
advise using the backends to limit connections (and that also allows the
returning 5xx errors instead of timeouts, which can confuse the
diagnosis if the timeout is the first thing that is seen).

- Chad
>
> I'll let you know about this data recollection.
> Thanks again for the help, is being super productive for me
>
>

Rent you spaces and knowledge to tourists

$
0
0
Ijendu travel community

.ReadMsgBody { width: 100%; background-color: #ffffff; }
.ExternalClass { width: 100%; background-color: #ffffff; }
.ExternalClass, .ExternalClass p, .ExternalClass span, .ExternalClass font, .ExternalClass td, .ExternalClass div { line-height: 100%; }
html { width: 100%; }
body { -webkit-text-size-adjust: none; -ms-text-size-adjust: none; margin: 0; padding: 0; }
table { border-spacing: 0; border-collapse: collapse; table-layout: fixed; margin: 0 auto; }
table table table { table-layout: auto; }
img { display: block !important; over-flow: hidden !important; }
table td { border-collapse: collapse; }
.yshortcuts a { border-bottom: none !important; }
img:hover { opacity:0.9 !important;}
a { color: #6ec8c7; text-decoration: none; }
.textbutton a { font-family: 'open sans', arial, sans-serif !important; color: #ffffff !important; }
.preference-link a { color: rgb(0, 218, 247) !important; text-decoration: underline !important; }

/*Responsive*/
@media only screen and (max-width: 640px) {
body { width: auto !important; }
table[class="table-inner"] { width: 90% !important; }
table[class="table-full"] { width: 100% !important; text-align: center !important; }
/* Image */
img[class="img1"] { width: 100% !important; height: auto !important; }
}

@media only screen and (max-width: 479px) {
body { width: auto !important; }
table[class="table-inner"] { width: 90% !important; }
table[class="table-full"] { width: 100% !important; text-align: center !important; }
/* image */
img[class="img1"] { width: 100% !important; height: auto !important; }
}



!function (f, b, e, v, n, t, s) {
if (f.fbq)
return;
n = f.fbq = function () {
n.callMethod ?
n.callMethod.apply(n, arguments) : n.queue.push(arguments)
};
if (!f._fbq)
f._fbq = n;
n.push = n;
n.loaded = !0;
n.version = '2.0';
n.queue = [];
t = b.createElement(e);
t.async = !0;
t.src = v;
s = b.getElementsByTagName(e)[0];
s.parentNode.insertBefore(t, s)
}(window,
document, 'script', '//connect.facebook.net/en_US/fbevents.js');

fbq('init', '726327894165100');
fbq('track', "PageView");


// ViewContent
// Track key page views (ex: product page, landing page or article)
fbq('track', 'ViewContent');


// Search
// Track searches on your website (ex. product searches)
fbq('track', 'Search');


// AddToCart
// Track when items are added to a shopping cart (ex. click/landing page on Add to Cart button)
fbq('track', 'AddToCart');


// AddToWishlist
// Track when items are added to a wishlist (ex. click/landing page on Add to Wishlist button)
fbq('track', 'AddToWishlist');


// InitiateCheckout
// Track when people enter the checkout flow (ex. click/landing page on checkout button)
fbq('track', 'InitiateCheckout');


// AddPaymentInfo
// Track when payment information is added in the checkout flow (ex. click/landing page on billing info)
fbq('track', 'AddPaymentInfo');


// Purchase
// Track purchases or checkout flow completions (ex. landing on "Thank You" or confirmation page)
fbq('track', 'Purchase', {value: '1.00', currency: 'USD'});


// Lead
// Track when a user expresses interest in your offering (ex. form submission, sign up for trial, landing on pricing page)
fbq('track', 'Lead');


// CompleteRegistration
// Track when a registration form is completed (ex. complete subscription, sign up for a service)
fbq('track', 'CompleteRegistration');






















Try view on your
browser or
Unsubscribe.





























The journey of life.




















100% local travel community








































0% commission for guests. 0% commission for hosts.











Be wise. Make money from what you have and safe on what you need. Reserve unique spaces, experiences and transport from people just like you.









































Click here to find out more!




























































Ijendu © 2015 All Rights Reserved

Re: Slowness on deployment

$
0
0
I have the log, but a lot of the data is confidential.
Can I send you by email in order for you to take a look?

We can post a edited version later in order to help others
debug the same issue

Thanks in advance
Viewing all 11674 articles
Browse latest View live