Doar Eu am controlul afacerii mele!
Use this area to offer a short preview of your email's content. View this email in your browser ( *%7CARCHIVE%7C* ) www.eStores.ro ( http://estores.ro/ro/ ) Nou! Sistem de management al proceselor intr-o firma Doar unul din 20 de manageri pot fi in mijlocul afacerii atunci cand sunt, de fapt plecati. Conform unui faimos studiu sociologic, unul din cinci divorturi se datoreaza imposibilitatii managerilor de a impaca afacerile cu familia. Dureros pentru toti, mai ales atunci cand totul depinde de tine! 84% dintre directori se plang ca lucrurile nu se misca in firma fara prezenta lor. Si au dreptate! Sun Tzu, in binecunoscuta sa lucrare "Arta razboiului", a spus "un general care nu isi cunoaste armata se indreapta spre o infrangere sigura". Exista un singur mod de a cunoaste de aproape, tot timpul, cum se deruleaza fiecare proces din firma. De fapt sunt doua: * unul e clonarea, dar nu stim cum; * al doilea este implementarea unui soft de management al proceselor. Pe acesta in garantam! Sistemul este compus dintr-o serie de module destinate tuturor departamentelor din cadrul unei firme, precum vanzari, productie, financiar-contabil etc. Informatia este operata o singura data si este accesibila oricarui modul ii este necesara, astfel se economisesc resurse si se diminueaza probabilitatea de a comite erori de operare. Aplicatia este destinata in special tipografiilor insa poate fi adaptata oricarui domeniu de activitate, datorita structurii sale. Avantaje * Poate sa identifice punctual ruperile de ritm, si sa le aprecieze ca facand parte din categoria de "am uitat" sau din categoria de supraincarcare; * Are acces suplimentar la functii ale calculatorului de pret, pe axa cost/pret/discount/pret impus; Iti garantam... * reducerea erorilor umane cu minim 60%; * ameliorarea tuturor proceselor din companie cu minim 20%; * trasabilitatea intregii activitatii 100%; * imbunatatirea comunicarii intre departamente cu minim 56%; * reducerea timpilor morti cu 15%; * imbunatatirea timpilor de executie cu 21%. Altfel iti returnam banii! --- Magazin Online ( http://estores.ro/ro/magazin-online.html ) --- Vrei sa vinzi produse indiferent de locatia ta? eStores poate sa iti dezvolte o platforma perfecta pentru comertul electronic; Caracteristici: - Design complet personalizat; - Sincronizare cu sistemul de gestiune; - Sistem de inregistrare personalizat pentru clienti; - Numar nelimitat de imagini / produse. Exemple: www.redzip.ro ( http://redzip.ro/ ) www.fmracing.ro ( http://fmracing.ro/ ) Mai multe detalii... ( http://estores.ro/ro/magazin-online.html ) --- Optimizare SEO ( http://estores.ro/ro/optimizare-seo.html ) --- Optimizare pe Brand Marketing-ul site-ului; Numar nelimitat de cuvinte cheie; Implementarea etichetelor Meta completa; Analiza concurentei;Optimizarea navigarii, imaginilor si linkurilor din site; Rezolvarea problemelor de HTML si CSS + Viteza de incarcare;Inscriere manuala in directoare WEB Romanesti si Straine; Exemple: www.jaluzele-ieftine.ro ( http://www.jaluzele-ieftine.ro/ ) Mai multe detalii... ( http://estores.ro/ro/optimizare-seo.html ) Site de Prezentare ( http://estores.ro/ro/site-prezentare.html ) Design unic si original; Grafica web complet personalizata; Structura website cu 2-5 varinte lingvistice; Panou de administrare al continutului ce permite: - Crearea/ modificarea unui numar nelimitat de pagini - Administrarea imaginilor din galeria foto - Inserarea/ modificare butoanelor din meniul secundar - Formular de contact - Statistici vizitatori. Exemple : www.inforegio.ro ( http://www.inforegio.ro/ro/ ) Mai multe detalii... ( http://estores.ro/ro/site-prezentare.html ) Cu respect, Ing. Iulian POP WE BRING YOU THE FUTURE ___ Mobil: 0720031123 Tel/fax: 0362 404 903 E-mail: iul...@mydomains.ro Website: www.estores.ro Address: Str Carbunari nr 8 ___ Pentru ca intelegem si apreciem intimitatea d-voastra ne cerem scuze daca acest mesaj a ajuns din gresala la dvs, iar daca doriti sa nu mai primiti astfel de mesaje in viitor, va rugam sa va dezabonati aici : unsubscribe from this list ( *%7CUNSUB%7C* ) In conformitate cu legea 365/2002 privuind comertul electronic, acest mesaj nu este si nu poate fi considerat spam, deoarece: - acceptarea de primire a ofertei nu va implica financiar; - adresa d-voastra de e-mail a fost gasita pe un site public, fie intr-un ghid de afaceri, fie in adresele altor firme care ne-au trimis ofertele lor, am primit-o cu ocazia unor cereri de oferta, intalniri de afaceri sau am colaborat. - acest mesaj va este adresat cu scopul
★★★ Tenisi Converse colectia 2014 la reducere -70%. Lichidare de stoc!
TRANSPORT GRATUIT LA 2 PERECHI CUMPARATE DETALII SAU COMENZI: 0768 894 843 ( http://www.outlet-converse.ro ) 26 modele noi Converse Classic si Gheata Colectia vara - toamna 2014 ( http://www.outlet-converse.ro/tenisi-converse-chuck-taylor-all-star-white.html ) 199 LEI 129 lei Tenisi unisex Converse All Star OX - White cumpara acum ( http://www.outlet-converse.ro/tenisi-converse-chuck-taylor-all-star-white.html ) ( http://www.outlet-converse.ro/tenisi-converse-chuck-taylor-all-star-black.html ) 199 LEI 129 lei Tenisi unisex Converse All Star OX - Black cumpara acum ( http://www.outlet-converse.ro/tenisi-converse-chuck-taylor-all-star-black.html ) ( http://www.outlet-converse.ro/tenisi-converse-chuck-taylor-all-star-dark-red.html ) 199 LEI 129 lei Tenisi unisex Converse All Star OX - Dark Red cumpara acum ( http://www.outlet-converse.ro/tenisi-converse-chuck-taylor-all-star-dark-red.html ) ( http://www.outlet-converse.ro/tenisi-converse-chuck-taylor-all-star-black-monochrome.html ) 199 LEI 129 lei Tenisi unisex Converse All Star OX - Black Monochrome cumpara acum ( http://www.outlet-converse.ro/tenisi-converse-chuck-taylor-all-star-black-monochrome.html ) ( http://www.outlet-converse.ro/tenisi-converse-chuck-taylor-all-star-dark-blue.html ) 199 LEI 129 lei Tenisi unisex Converse All Star OX Dark Blue cumpara acum ( http://www.outlet-converse.ro/tenisi-converse-chuck-taylor-all-star-dark-blue.html ) ( http://www.outlet-converse.ro/tenisi-converse-chuck-taylor-all-star-white-monochrome.html ) 199 LEI 129 lei Tenisi unisex Converse All Star OX - White Monochrome cumpara acum ( http://www.outlet-converse.ro/tenisi-converse-chuck-taylor-all-star-white-monochrome.html ) ( http://www.outlet-converse.ro/tenisi-converse-chuck-taylor-all-star-ox-crem.html ) 199 LEI 129 lei Tenisi unisex Converse All Star OX - Crem cumpara acum ( http://www.outlet-converse.ro/tenisi-converse-chuck-taylor-all-star-ox-crem.html ) ( http://www.outlet-converse.ro/tenisi-converse-chuck-taylor-all-star-hi-white.html ) 249 LEI 149 lei Tenisi unisex Converse All Star Hi - White cumpara acum ( http://www.outlet-converse.ro/tenisi-converse-chuck-taylor-all-star-hi-white.html ) ( http://www.outlet-converse.ro/tenisi-converse-chuck-taylor-all-star-uk-flag.html ) 199 LEI 129 lei Tenisi unisex Converse All Star OX - UK Flag cumpara acum ( http://www.outlet-converse.ro/tenisi-converse-chuck-taylor-all-star-uk-flag.html ) reduceri maxime colectia vara - toamna 2014 INcepe cumparaturile acum! ( http://www.outlet-converse.ro ) ( # ) Converse All Star - alte modele ( http://www.outlet-converse.ro/tenisi-converse-chuck-taylor-all-star-hi-black.html ) 249 lei 149 lei Tenisi unisex Converse All Star Hi - Black cumpara acum ( http://www.outlet-converse.ro/tenisi-converse-chuck-taylor-all-star-hi-black.html ) ( http://www.outlet-converse.ro/tenisi-converse-chuck-taylor-all-star-hi-grey.html ) 199 lei 129 lei Tenisi unisex Converse All Star OX - Grey cumpara acum ( http://www.outlet-converse.ro/tenisi-converse-chuck-taylor-all-star-hi-grey.html ) ( http://www.outlet-converse.ro/tenisi-converse-chuck-taylor-all-star-green.html ) 199 LEI 129 lei Tenisi unisex Converse All Star OX - Green cumpara acum ( http://www.outlet-converse.ro/tenisi-converse-chuck-taylor-all-star-green.html ) ( http://www.outlet-converse.ro/converse-all-star-ox-turquoise.html ) 199 LEI 129 lei Tenisi unisex Converse All Star OX - Turquoise cumpara acum ( http://www.outlet-converse.ro/converse-all-star-ox-turquoise.html ) ( http://www.outlet-converse.ro/tenisi-converse-chuck-taylor-all-star-camouflage.html ) 199 LEI 129 lei Tenisi unisex Converse All Star OX - Yellow cumpara acum ( http://www.outlet-converse.ro/tenisi-converse-chuck-taylor-all-star-camouflage.html ) Transport gratuit la 2 perechi cumparate Vezi ce modele iti plac! ( http://www.outlet-converse.ro/ ) Informatii Despre noi ( http://www.outlet-converse.ro/despre-noi.html ) Informatii utile ( http://www.outlet-converse.ro/informatii-utile.html ) Informatii Contact ( http://www.outlet-converse.ro/index.php?route=information/contact ) Termeni Returnare produse ( http://www.outlet-converse.ro/returnarea-produselor.html ) Contact Telefon: 0768 894 843 cont...@outlet-converse.ro Copyright©2014 outlet-converse.ro/Dezabonare ( http://www.csdedicated.com/client1/u.php?p=ye/rs/8w1/ss/y4/rs/rt ) .
1JOUR 1OFFRE : CHERVO Vêtements Sportwear Golf Homme
Offres exclusives sur les produits du site Allsportshop Version en ligne | Ajouter Allsportshop à votre carnet d’adresses MERCREDI 30 JUILLET Votre victoire, c'est avec CHERVO et son style italien CHIC-TECH (Dans la limite des stocks disponibles) ENTREPRISE FRANÇAISE SATISFAIT OU REMBOURSÉ PAIEMENT 100% SÉCURISÉ PAIEMENT PAYPAL PAIEMENT 3D SECURE ALLSPORTSHOP SUR FACEBOOK Pour être certain de bien recevoir nos messages, ajoutez Allsportshop dans votre carnet d’adresses. Veuillez me retirer de votre liste de diffusion
http-response syntax
I suspect I just don't understand "http-response"'s syntax, or I might have
discovered a bug.
What I'm trying to do:
I need to have haproxy intercept backend server responses containing an HTTP
Location header, and change the "http:" of the URL in the contents to "https:"
IF the session is over SSL and IF the FQDN in the URL in the Location header
is, say, "*.something.edu".
Here's how I'm doing it today (inside the frontend), and it works:
acl port-443 dst_port 443
rsprep ^(Location:\ http)(://[^/]*\.something\.edu.*) \1s\2 if port-443
Here's how I'd like to do it using "http-response":
http-response replace-header Location (http)(://[^/]*\.something\.edu.*) \1s\2
if { ssl_fc }
When I run an "haproxy -c" on the http-response config, I'm greeted with:
[ALERT] 209/213332 (25548) : parsing [./haproxy.cfg:43]: 'http-request
replace-header' expects exactly 3 arguments.
When I remove the "if" portion at the end of the http-response line, it checks
fine. I've tried it with multiple different "if" conditions (using various
types of acls). If there is any "if" condition, the above error appears.
It also concerns me that the error specifies "http-request replace-header",
when the config is actually an "http-response replace-header", but that could
just be simple typo. I'm more concerned that I can't seem to get it to accept
an "if" condition.
I'm very open to the explanation being "oh, well, you configured the line
wrong; you forgot to...". I'm out of ideas, though.
I'm using 1.5.1, but I've tried the config using 1.5.0 and 1.5.3, and the
result is the same. Here's my build info (compiled on CentOS 6.5), if it makes
a difference:
---
HA-Proxy version 1.5.3 2014/07/25
Copyright 2000-2014 Willy Tarreau
Build options :
TARGET = linux2632
CPU = generic
CC = gcc
CFLAGS = -O2 -g -fno-strict-aliasing
OPTIONS = USE_ZLIB=1 USE_POLL=default USE_OPENSSL=1 USE_PCRE=1
Default settings :
maxconn = 2000, bufsize = 16384, maxrewrite = 8192, maxpollevents = 200
Encrypted password support via crypt(3): no
Built with zlib version : 1.2.3
Compression algorithms supported : identity, deflate, gzip
Built with OpenSSL version : OpenSSL 1.0.1e-fips 11 Feb 2013
Running on OpenSSL version : OpenSSL 1.0.1e-fips 11 Feb 2013
OpenSSL library supports TLS extensions : yes
OpenSSL library supports SNI : yes
OpenSSL library supports prefer-server-ciphers : yes
Built with PCRE version : 7.8 2008-09-05
PCRE library supports JIT : no (USE_PCRE_JIT not set)
Built with transparent proxy support using: IP_TRANSPARENT IP_FREEBIND
Available polling systems :
poll : pref=200, test result OK
select : pref=150, test result OK
Total: 2 (2 usable), will use poll.
---
Any thoughts?
- Jon
NOTICE: This email message is for the sole use of the intended recipient(s)
and may contain confidential and privileged information. Any unauthorized
review, use, disclosure or distribution is prohibited. If you are not the
intended recipient, please contact the sender by reply email and destroy all
copies of the original message.
Re: Roadmap for 1.6
On 28/07/2014 11:54 πμ, Apollon Oikonomopoulos wrote: > Hi Willy, > > On 19:28 Fri 25 Jul , Willy Tarreau wrote: >> >> Concerning the new features, no promises, but we know that we need to >> progress in the following areas : >> >> - multi-process : better synchronization of stats and health checks, >> and find a way to support peers in this mode. I'm still thinking a >> lot that due to the arrival of latency monsters that are SSL and >> compression, we could benefit from having a thread-based architecture >> so that we could migrate tasks to another CPU when they're going to >> take a lot of time. The issue I'm seeing with threads is that >> currently the code is highly dependent on being alone to modify any >> data. Eg: a server state is consistent between entering and leaving >> a health check function. We don't want to start adding huge mutexes >> everywhere. > > How about using shared memory segments for stats, health checks and > peers? > >> >> If anyone has any comment / question / suggestion, as usual feel free to >> keep the discussion going on. > > Could I also add shared SSL session cache over multiple boxes (like > stud), to aid SSL scalability behind LVS directors? It has been asked > for before in the mailing list if I recall correctly. > A bit off topic but sometimes tunning the cipher suite reduces the CPU cost of encryption. Today, I managed to save 5% CPU by moving to ECDHE cipher suite, see https://db.tt/N9auU9cg. I just recompiled HAProxy against openSSL 1.0.1 where ECDHE is available and the default cipher changed from DHE to ECDHE, which is a CPU intensive cipher set but still much better than DHE. I have to mention that the server uses Intel and OpenSSL Intel AES-NI engine is enabled by default as openSSL 1.0.1 can detect processors that support AES-NI. Cheers, Pavlos signature.asc Description: OpenPGP digital signature
Re: Roadmap for 1.6
On 29/07/2014 10:55 πμ, Willy Tarreau wrote: > Hi Pavlos, > > On Mon, Jul 28, 2014 at 12:07:37AM +0200, Pavlos Parissis wrote: >> On 25/07/2014 07:28 , Willy Tarreau wrote: >>> Hi all, >> >> [..snip..] >> >> >>> - hot reconfiguration : some users are abusing the reload mechanism to >>> extreme levels, but that does not void their requirements. And many >>> other users occasionally need to reload for various reasons such as >>> adding a new server or backend for a specific customer. While in the >>> past it was not possible to change a server address on the fly, we >>> could now do it easily, so we could think about provisionning a few >>> extra servers that could be configured at run time to avoid a number >>> of reloads. Concerning the difficulty to bind the reloaded processes, >>> Simon had done some work in this area 3 years ago with the master- >>> worker model. Unfortunately we never managed to stabilize it because >>> of the internal architecture that was hard to adapt and taking a lot >>> of time. It could be one of the options to reconsider though, along >>> with FD passing across processes. Similarly, persistent server states >>> across reloads is often requested and should be explored. >>> >> >> Let's take this to another level and support on-line configuration >> changes for Frontends, backends and servers which don't require restart > > We've already improved things significantly in this direction. We're at a > point where it should be easy to support on-the-fly server address change. > However there are still a large number of things that cannot be easily > changed. All those which have many implications are in this area. For > example, people think that adding a server is easy, but it clearly is not. > The table-based LB algorithms already compute the largest table size when > all servers are up, according to their respective weights. Changing one > weight or adding one server can increase their least common multiple and > require to reallocate and rebuild a complete table. Also, servers are > checked, and for the checks we reserve file descriptors. We cannot easily > change the max number of file descriptors on the fly either. What can be > done however is to reserve some spare slots for adding new servers into an > existing backend. > > Also, for having worked many years with various products which support > on-line configuration changes, I don't count anymore the number of days, > weeks or months of troubleshooting of strange issues only caused by side > effect of these on-line changes, that simply went away after a reboot. I'm > not even blaming them because it's very hard to propagate changes correctly. > It always reminds me of a math professor I had at the uni who was able to > spot a mistake in an equation as large as the blackboard, who would fix it > there at the top of the blackboard and propagate the fix down to other lines. > The covered area looked like a pyramid. Here it's the same, performing a > minor change at the top of the configuration needs to take care of many > tiny implications far away from where the change is performed. And I'm > definitely not going to reproduce the lack of reliability that many products > can have just for the sake of allowing on-line reconfiguration. > > I'd rather invest more time ensuring that we can seamlessly reload (eg: not > lose stick-tables, stats nor server checks) to ensure that sensible changes > are done this way and not the tricky one. > If you manage to implement this, especially the server checks, it would be a MAJOR improvement. It will probably reduce the requests of on-line changes as well, since people (including myself) will say "just reload dude, it is for free". Thanks Willy for taking the time to response on my mail, very much appreciated. Cheers, Pavlos signature.asc Description: OpenPGP digital signature
redirect location and add cookie
Hi, (haproxy 1.5.x) I'm trying to redirect url and set cookie with expire / secure / HttpOnly. Is there a better way than (ab)using errorfile 503 and backend with no servers: frontend testing ... acl is_ie_frontpage path_beg /test_frontpage ... use_backend BE_ie if is_ie_frontpage backend BE_ie errorfile 503 /etc/haproxy/errors/ie_redirect.html (and ie_redirect.html: HTTP/1.1 302 Found Set-Cookie: uefspnego=1; Expires=Mon, 09 Jun 2025 10:18:14 GMT; path=/idp; secure; HttpOnly Cache-Control: no-cache Content-Length: 0 Location: http://real.front.page/ Connection: close (I've tried with: backend BE_ie rspadd Set-Cookie:\ uefspnego=1... redirect location http://real.front.page/ code 303/302 but the rspadd didn't seem to work ? And since I need to add a long Expires can't use redirect location http... code 303 set cookie ...) (the uefspnego cookie should only be added when browser visits the /test_frontpage url). What I'm trying to accomplish is setting uefspnego cookie to browsers that are in our active directory domain (ie. capable of spnego/kerberos authentication). --> With group policy set Internet Explorer home page to this special url(https://.../test_frontpage) and this special url sets uefspnego cookie and redirects the browser to "real" homepage. Or is there a way to add cookie to Internet Explorer with group policy (or some other automation tool, we have a few thousand machines so I'd like to avoid anything that requires user interaction / manual labor). (I guess instead of uefspnego cookie we could add a string to User-Agent, I assume this is possible with group policy, but I guess changing UA makes it a bit easier to track our users). All ideas welcome. -Jarno -- Jarno Huuskonen
Re: [PATCH] Improve and simplify systemd-wrapper.
Hi Conrad, On Tue, Jul 29, 2014 at 12:12:00AM +0200, Conrad Hoffmann wrote: > Hello, > > attached are the first two patches, one fixing the actual bug I > encountered and one just tidying up the signal handling a little. More > to come. > > Are they ok like this? Perfect, thank you very much for doing this. I've merged them both. Willy
Re: [PATCH] BUG/MINOR: server: move the directive #endif to the end of file
Hi Godbach, On Mon, Jul 28, 2014 at 05:56:28PM +0800, Godbach wrote: > Hi Willy, > > Please check the attached for a minor bug fix. > > The commit log is as below: > > [PATCH] BUG/MINOR: server: move the directive #endif to the end of > file > > If a source file includes proto/server.h twice or more, redefinition > errors will be triggered for such inline functions as > server_throttle_rate(), server_is_draining(), srv_adm_set_maint() and so > on. Just move #endif directive to the end of file to solve this issue. Applied, thank you! Willy
Re: Roadmap for 1.6
On Tue, Jul 29, 2014 at 09:44:50AM +0100, Scott McKeown | redIT wrote: > Hi Willy, > > Thank you for clearing this up for me. > > I now understand the direction that you are wanting to take more clearly > now. > > I just wish that I could help more than by just using and reporting, I'm > sure I'll get there though. Using and reporting are the most important contributions ever. Untested code is worse than no code at all as it can break working features. And if you look at all the bugs fixed, many of them were side effects of changes *I* did without noticing the change had a side effect on something else. Fortunately people reported these bugs and eventually they got fixed. And to go further, I've heard people tell me "why don't you ship your changes in your ALOHA prior to shipping them in the opensource version ?". I then explained that they were wrong, and that the only reason why the ALOHA is so much reliable is that it's based on versions that people have been testing extensively under extreme conditions and for which many bugs were reported and fixed. So don't worry, you're not "just" using and reporting, you're using and reporting and we should thank you for that. cheers, Willy
Re: Roadmap for 1.6
Hi Pavlos, On Mon, Jul 28, 2014 at 12:07:37AM +0200, Pavlos Parissis wrote: > On 25/07/2014 07:28 , Willy Tarreau wrote: > > Hi all, > > [..snip..] > > > > - hot reconfiguration : some users are abusing the reload mechanism to > > extreme levels, but that does not void their requirements. And many > > other users occasionally need to reload for various reasons such as > > adding a new server or backend for a specific customer. While in the > > past it was not possible to change a server address on the fly, we > > could now do it easily, so we could think about provisionning a few > > extra servers that could be configured at run time to avoid a number > > of reloads. Concerning the difficulty to bind the reloaded processes, > > Simon had done some work in this area 3 years ago with the master- > > worker model. Unfortunately we never managed to stabilize it because > > of the internal architecture that was hard to adapt and taking a lot > > of time. It could be one of the options to reconsider though, along > > with FD passing across processes. Similarly, persistent server states > > across reloads is often requested and should be explored. > > > > Let's take this to another level and support on-line configuration > changes for Frontends, backends and servers which don't require restart We've already improved things significantly in this direction. We're at a point where it should be easy to support on-the-fly server address change. However there are still a large number of things that cannot be easily changed. All those which have many implications are in this area. For example, people think that adding a server is easy, but it clearly is not. The table-based LB algorithms already compute the largest table size when all servers are up, according to their respective weights. Changing one weight or adding one server can increase their least common multiple and require to reallocate and rebuild a complete table. Also, servers are checked, and for the checks we reserve file descriptors. We cannot easily change the max number of file descriptors on the fly either. What can be done however is to reserve some spare slots for adding new servers into an existing backend. Also, for having worked many years with various products which support on-line configuration changes, I don't count anymore the number of days, weeks or months of troubleshooting of strange issues only caused by side effect of these on-line changes, that simply went away after a reboot. I'm not even blaming them because it's very hard to propagate changes correctly. It always reminds me of a math professor I had at the uni who was able to spot a mistake in an equation as large as the blackboard, who would fix it there at the top of the blackboard and propagate the fix down to other lines. The covered area looked like a pyramid. Here it's the same, performing a minor change at the top of the configuration needs to take care of many tiny implications far away from where the change is performed. And I'm definitely not going to reproduce the lack of reliability that many products can have just for the sake of allowing on-line reconfiguration. I'd rather invest more time ensuring that we can seamlessly reload (eg: not lose stick-tables, stats nor server checks) to ensure that sensible changes are done this way and not the tricky one. > and at the same time *dump* the new configuration to haproxy.conf, while > on startup haproxy.conf.OK was created. I would love to have this, I've been dreaming about it for about 10 years in order to ease config migrations. With this we could also get rid of a number of emulated features. However there are some difficulties caused by the fact that some features are inherited from the defaults config while other ones are explicitly present in the section, resulting in 3 possible output modes : - flattened (without defaults anymore) - simplified (without everything inherited from defaults) - normal : keep everything and only resolve inside a section For having studied this over a long time, I have an idea how hard of a job it is. And contrary to a common belief, it's about as hard as parsing the config. > The same way OpenLDAP manages > its configuration. This will be very useful in environments where > servers register their self to a service(backend in this case) based a > health-checks which run locally or by a centralized service. Oh yes, I > am talking about Zookeeper integration. > > In setups where you have N HAProxy servers for serving the same site[1], > reducing the number of health-checks is very important. We've been working for a long time on a centralized health-check project at Exceliance a long time ago, but the amount of possibilities we had in the health checks at this time resulted in something less capable than what haproxy could already do (eg: deal with slowstart/soft-stop, report errors for logs, perform tracking, ...). S
Re: Roadmap for 1.6
Hi Willy, Thank you for clearing this up for me. I now understand the direction that you are wanting to take more clearly now. I just wish that I could help more than by just using and reporting, I'm sure I'll get there though. ~Scott On 29/07/2014 09:33, Willy Tarreau wrote: Hi Scott, On Sun, Jul 27, 2014 at 03:40:10PM +0100, Scott McKeown | redIT wrote: Anyhow, as you have mentioned that its really the community that is helping drive the developement forward, how about some form of online vote system to help find out what the community would most like to have added to the next release and this could then be the main target of the next stable release. It already exists, it's the mailing list! Development is not based on a vote but on *real* efforts, and the best way to have a feature implemented is to contribute it. When you cannot contribute it, you at least need to explain your needs on the list so that they can be discussed and tailored to something implementable. In fact, this has worked for years so I firmly believe this will continue to work. Also, as I mentionned, I don't want a release to depend on an advertise feature set anymore, so that's one more reason for having things done in parallel and as contributions. For example Open a vote for one month before all major development begins with say four items that are realisticly possible for adding into v1.6 after the month the one with the most becomes the main development focus for this release. We really never know. Server-side keep-alive was realistic for 6-months after 1.4, and digging into it constantly proved more difficult with a very long trail of dependencies. So I don't want to bet anymore on ETAs for certain features. We have many examples like this, of things we have been forced to drop or at least delay so that we could perform deeper changes that were needed. I'm not saying that other things can't and shouldn't be added that would just be silly but this way us out here get what we think we really need and we continue to have a reliable and stable development process. There's another point I forgot to mention : despite a number of companies contributing to the project, most initiatives are done on a voluntary basis by enthousiasts on their spare time. Most of them have no idea how long it can take to implement something nor how much spare time they have to work on it. We *cannot* and *must not* wait for people's work to be completed before a release, and they must not feel bad for missing a deadline. That's the benefit of a merge window : if your code is not in good enough shape for version N, no rush, continue at your rhythm, you'll push it for N+1 a few months later. This process ensures that what people want actually is what will eventually get merged. Large companies can hire developers to get their features done quickly, and other users can take their time, nobody is waiting for them to finish. Best regards, Willy
Re: Roadmap for 1.6
Hi Scott, On Sun, Jul 27, 2014 at 03:40:10PM +0100, Scott McKeown | redIT wrote: > Anyhow, as you have mentioned that its really the community that is > helping drive the developement forward, how about some form of online > vote system to help find out what the community would most like to have > added to the next release and this could then be the main target of the > next stable release. It already exists, it's the mailing list! Development is not based on a vote but on *real* efforts, and the best way to have a feature implemented is to contribute it. When you cannot contribute it, you at least need to explain your needs on the list so that they can be discussed and tailored to something implementable. In fact, this has worked for years so I firmly believe this will continue to work. Also, as I mentionned, I don't want a release to depend on an advertise feature set anymore, so that's one more reason for having things done in parallel and as contributions. > For example Open a vote for one month before all major development > begins with say four items that are realisticly possible for adding into > v1.6 after the month the one with the most becomes the main development > focus for this release. We really never know. Server-side keep-alive was realistic for 6-months after 1.4, and digging into it constantly proved more difficult with a very long trail of dependencies. So I don't want to bet anymore on ETAs for certain features. We have many examples like this, of things we have been forced to drop or at least delay so that we could perform deeper changes that were needed. > I'm not saying that other things can't and > shouldn't be added that would just be silly but this way us out here get > what we think we really need and we continue to have a reliable and > stable development process. There's another point I forgot to mention : despite a number of companies contributing to the project, most initiatives are done on a voluntary basis by enthousiasts on their spare time. Most of them have no idea how long it can take to implement something nor how much spare time they have to work on it. We *cannot* and *must not* wait for people's work to be completed before a release, and they must not feel bad for missing a deadline. That's the benefit of a merge window : if your code is not in good enough shape for version N, no rush, continue at your rhythm, you'll push it for N+1 a few months later. This process ensures that what people want actually is what will eventually get merged. Large companies can hire developers to get their features done quickly, and other users can take their time, nobody is waiting for them to finish. Best regards, Willy
Re: Roadmap for 1.6
Hi Apollon, On Mon, Jul 28, 2014 at 12:54:07PM +0300, Apollon Oikonomopoulos wrote: > > - multi-process : better synchronization of stats and health checks, > > and find a way to support peers in this mode. I'm still thinking a > > lot that due to the arrival of latency monsters that are SSL and > > compression, we could benefit from having a thread-based architecture > > so that we could migrate tasks to another CPU when they're going to > > take a lot of time. The issue I'm seeing with threads is that > > currently the code is highly dependent on being alone to modify any > > data. Eg: a server state is consistent between entering and leaving > > a health check function. We don't want to start adding huge mutexes > > everywhere. > > How about using shared memory segments for stats, health checks and > peers? I thought I wrote about it and re-read my e-mail and it's not there :-) In short : - stats: should definitely be in a shared memory segment, and we can get accurate stats using atomic operations. There are a few tricky points (eg: concurrent conns) which are used both as stats and for the process's decisions (queue or not to queue) but I think it can be addressed ; - peers: no problem on output, but not easy on input since the incoming data must be distributed to all consumers, and we must prevent ACKs from being sent before all of them get the information. Instead, I'd like to have the stick tables shared between processes, and have only one process handle the synchronization (eg: abitrarily the first one). There are still issues caused by the independant per-process contexts. For example, when a process updates a stick-table contents, it has no way of waking up the other process to detect the change and program an update propagation. Still I think that could be manageable. - health checks: definitely not suited for shared memory right now, as all the code assumes that the state is stable along a whole function, so instead we need to broadcast event change notification. It's all these apparently easy but practically hard to synchronize issues that make me think we'd rather go down the thread route than the process route, because at least any thread which detects a change can do all the relevant job by itself. > > If anyone has any comment / question / suggestion, as usual feel free to > > keep the discussion going on. > > Could I also add shared SSL session cache over multiple boxes (like > stud), to aid SSL scalability behind LVS directors? It has been asked > for before in the mailing list if I recall correctly. Good point, and Emeric initially wrote the code for Stud as a PoC so that we could get it afterwards. There's not much that needs to be done, mosly implement a better UDP protocol handling and UDP receivers. However as Dirkjan has pointed out, it is possible that by the time this is achieved, TLS tickets will have obsoleted this feature. Finding a way to intelligently exchange a seed for TLS tickets can be interesting. For instance, we could have a large cyclic pseudo-random generator implemented in all nodes seeded with a shared secret. Each node could randomly decide to skip entries and regularly broadcast the number of entries skipped, so that all other nodes have a way to jump to the new key. I don't know how that would resist to restarts though. Regards, Willy
Set Clubs Juniors + Balles Callaway
Si ce message ne s'affiche pas correctement consultez-le en ligne Pour être sûr de bien recevoir nos Newsletters, ajoutez CGR GOLF à votre carnet d'adresses SUPER PROMOTION : -20% sur les set et -10 % sur les sacs. Le TROLLEY JUNIOR est à -20% sur CGR Golf : Facile à déplier et à utiliser, il comporte une poignée rembourrée et un filet de rangement. PRIX DE FOLIE ! CALLAWAY occasion & reconditionnées PACKAGE 100 BALLES IDENTIQUES PORT OFFERT !! Callaway Tour Callaway Hot Balles reconditionnées : à partir de 1,99 € Balles reconditionnées : à partir de 0,99€ Balles d'occasion : à partir de 1,99€ Balles d'occasion : à partir de 1,05€ Recevez nos Newsletter Suivez-nous sur Facebook Se désinscrire de cette newsletter
Prinde viteza cu autododo.ro!
Click here open this email on your web browser ( http://client.campaignsender.ro/wb.php?p=3a2/315/rs/8ib/1jy/rs ) | Click here to forward this email to a friend ( http://client.campaignsender.ro/f.php?p=3a2/315/rs/8ib/1jy/rs ) *** ( http://autododo.ro/ ) *** Anunturile Zilei ! ( http://autododo.ro/ad/10840343/audi-a4-avant-20-tdi-dpf-multitronic-attraction-als-kombi-in-koblenz ) Audi A4 ( http://autododo.ro/ad/10840343/audi-a4-avant-20-tdi-dpf-multitronic-attraction-als-kombi-in-koblenz ) 7,999 euro ( http://autododo.ro/ad/10840343/audi-a4-avant-20-tdi-dpf-multitronic-attraction-als-kombi-in-koblenz ) Audi A3 ( http://autododo.ro/ad/10840343/audi-a4-avant-20-tdi-dpf-multitronic-attraction-als-kombi-in-koblenz ) 9,994 euro Incercati autododo.ro. ( http://autododo.ro/ ) Noi iti punem la dispozitie anunturile de pe cele mai importante site-uri auto. Autododo.ro ( http://autododo.ro/ ) este cea mai mare platforma specializata pe vanzarea de masini second-hand si automobile noi cu un numar total de 6 milioane masini. Zilnic platforma culege aproximativ 50 000 de anunturi noi postate pe site-urile de profil. Testeaza gratuit platforma ( http://autododo.ro/ ), iar daca ai idei asupra imbunatatirii site-ului, trimite-le pe adresa de mail petruta.te...@mydomains.ro Dat fiind faptul ca autovehiculele avantajoase se vand in primele 5 minute de la publicarea anuntului, in acest moment exista posibilitatea ca unele dintre aceste anunturi sa fie deja inexistente. Cautari active : Setezi cat de des vrei sa fi anuntat, prin email, atunci cand una sau mai multe masini corespund preferintelor tale (din 15 in 15 minute, din ora in ora, din 6 in 6 ore sau zilnic). Reclama ta aici : Este singurul loc unde afaceri ca leasing, asigurari auto, piese si dezmembrari auto merita sa se promoveze eficient. De ce? pentru ca 99.8% dintre clientii nostri sunt interesati de aceste afaceri. Nicio alta platforma online nu este atat de targetata ca si autododo.ro Contacteaza-ne chiar acum pentru a beneficia de o luna de reclama gratuita. Autododo pentru calitate, siguranta si incredere. ( http://autododo.ro/ad/10979400/ford-mondeo-18tdci-econetic ) Ford Mondeo ( http://autododo.ro/ad/9877202/audi-a4-avant-19-tdi-klima-euro4-gruene-plakettte-als-kombi-in-lohne ) 8,990 euro ( http://autododo.ro/ad/9875055/2006-audi-a4-20-tdi-rs4-lookalike-all-original-parts-stunning-dsg-hetton-le-hole- ) Mercedes C220 ( http://autododo.ro/ad/11013284/mercedes-benz-c-220-cdi-automatik-avantgarde-als-limousine-in-bruchsal ) 9,500 euro ( http://autododo.ro/ad/9151185/mercedes-benz-220-iii-cdi-elegance-bva ) Mercedes Benz 220 ( http://autododo.ro/ad/9151185/mercedes-benz-220-iii-cdi-elegance-bva ) 10,900 euro Tecar Petruta -- Tel / Fax : 0362 226 778 E-mail : petruta.te...@mydomains.ro Website : www.autododo.ro Address : str. Carbunari nr. 8 City : Baia Mare -- Click here to unsubscribe ( http://client.campaignsender.ro/u.php?p=3a2/rs/8ib/1jy/315/rs/rt ) Report Abuse Link ( http://client.campaignsender.ro/report_abuse.php?mid=3a2-8ib-aGFwcm94eUBmb3JtaWx1eC5vcmc%3D-1jy-u4-rs ) ( http://autododo.ro/ )
Re: Roadmap for 1.6
Hi Willy. Am 27-07-2014 16:22, schrieb Willy Tarreau: Hi Aleks, On Sun, Jul 27, 2014 at 01:44:01PM +0200, Aleksandar Lazic wrote: >Peers are a bit different, as they can be accessed at a very high rate. >However I'm pretty sure we'll move that to a shared memory just like >the SSL session storage at some point, except that we still have to >inform each process about the changes synchronously. I'm also thinking >that stick tables could possibly be shared between multiple processes >if we allocate entries from a shared memory area. This way is only able to handle the informations on one machine. Due to the fact that haproxy have already peer : I thought to extend this to a more or less opener protocol. Yes and that's why I wrote that we need to improve support for peers synchronization. Ack. >>When haproxy is able to send $Session-Information to redis, memcache, >>... then you can "better" use current environment resources. > >It's by far too slow, you have to communicate over the network for >this, >even if it's on the loopback, meaning you need to poll to access them >and stop/start any processing which needs them. You really want to have >the information accessible from within the process without doing a >context switch! But isn't this peer : a similar solution? No, because peers are push-only, so it's asynchronous. Thus every node has all the information, there's never any need for requesting something outside. This makes a huge difference. Ah ok thanks for explanation. I would understand this part of the documentation as a similar solution but with haproxy on protocol. Maybe I have misunderstand it. Not necessarily, I know that the doc on the protocol is missing. It was planned but you know how it is when the doc is planned and not written before the code... Oh yes ;-) I'm sure you have thought like a http-generic "plugin" and depend on the request the http-1 or the http-2 plugin handle the request. Not exactly, because as you might remember when you implemented the appsession code, the HTTP code is spread all over the processing and not easy to adapt to two different architectures. Thus I'm thinking about changing everything to have an internal representation that suits HTTP/2 and convert HTTP/1 to that representation. The code will then have to be ported to work with this new representation. That means that HTTP/1 to HTTP/1 proxying will more or less look like it's converted to HTTP/2 then to HTTP/1 again, at least for headers indexation. But I'd rather do it this way than the other way around, since performance-sensible sites will definitely go the HTTP/2 route. Pffu. That's a big BIG Change. Maybe you will design it as library so that some other Projects can use this converter too ;-) Cheers Aleks
