<html><head><meta http-equiv="Content-Type" content="text/html charset=iso-8859-1"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">Great! The only other thing that would be nice is a redirect to some of the key pages on <a href="http://opam.ocamlpro.com">opam.ocamlpro.com</a> (such as the Quick_Install), since they are widely linked from elsewhere on the web. If these could be served as a permanent redirect to the new site, that would ease migration, rather than giving users lots of 404s...<div><br></div><div>-anil</div><div><br><div><div>On 18 Oct 2013, at 18:10, Louis Gesbert <<a href="mailto:louis.gesbert@ocamlpro.com">louis.gesbert@ocamlpro.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div style="font-style: normal; font-variant: normal; font-weight: 400; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; font-family: monospace; font-size: 8pt;"><div style="white-space: pre-wrap; margin: 0px; text-indent: 0px;">Ok, I've turned nginx https on, and disabled stud. The logs look ok now, and the stats should be good.</div><p style="white-space: pre-wrap; margin: 0px; text-indent: 0px;"> </p><div style="white-space: pre-wrap; margin: 0px; text-indent: 0px;">I also noticed that some client weren't redirected to the new repo yet, because the opam-admin on <a href="http://ocamlpro.com/">ocamlpro.com</a> wasn'nt up to date (it wouldn't know about the repo file, and not notify to download it). That's fixed and everyone using 1.1 should be redirected now.</div><p style="white-space: pre-wrap; margin: 0px; text-indent: 0px;"> </p><div style="white-space: pre-wrap; margin: 0px; text-indent: 0px;">Le vendredi 18 octobre 2013 12:57:48 Anil Madhavapeddy a écrit :</div><div style="white-space: pre-wrap; margin: 0px; text-indent: 0px;">> On Fri, Oct 18, 2013 at 01:50:28PM +0200, Louis Gesbert wrote:</div><div style="white-space: pre-wrap; margin: 0px; text-indent: 0px;">> > the stats are generated from the http log. Since monday, the hits are</div><div style="white-space: pre-wrap; margin: 0px; text-indent: 0px;">> > all logged by nginx as coming from 127.0.0.1, which obviously breaks the</div><div style="white-space: pre-wrap; margin: 0px; text-indent: 0px;">> > stats :/ Any idea on how the configuration (proxying etc.) may cause</div><div style="white-space: pre-wrap; margin: 0px; text-indent: 0px;">> > this and possible solutions ?</div><div style="white-space: pre-wrap; margin: 0px; text-indent: 0px;">> </div><div style="white-space: pre-wrap; margin: 0px; text-indent: 0px;">> Good point -- we're using Stud:</div><div style="white-space: pre-wrap; margin: 0px; text-indent: 0px;">> <a href="https://github.com/bumptech/stud">https://github.com/bumptech/stud</a></div><div style="white-space: pre-wrap; margin: 0px; text-indent: 0px;">> </div><div style="white-space: pre-wrap; margin: 0px; text-indent: 0px;">> It has support for something that solves our problem:</div><div style="white-space: pre-wrap; margin: 0px; text-indent: 0px;">> > stud will optionally write the client IP address as the first few octets</div><div style="white-space: pre-wrap; margin: 0px; text-indent: 0px;">> > (depending on IPv4 or IPv6) to the backend--or provide that information</div><div style="white-space: pre-wrap; margin: 0px; text-indent: 0px;">> > using HAProxy's PROXY protocol. When used with the PROXY protocol, stud</div><div style="white-space: pre-wrap; margin: 0px; text-indent: 0px;">> > can also transparently pass an existing PROXY header to the cleartext</div><div style="white-space: pre-wrap; margin: 0px; text-indent: 0px;">> > stream. This is especially useful if a TCP proxy is used in front of stud.</div><div style="white-space: pre-wrap; margin: 0px; text-indent: 0px;">> > Using either of these techniques, backends who care about the client IP</div><div style="white-space: pre-wrap; margin: 0px; text-indent: 0px;">> > can still access it even though stud itself appears to be the connected</div><div style="white-space: pre-wrap; margin: 0px; text-indent: 0px;">> > client.</div><div style="white-space: pre-wrap; margin: 0px; text-indent: 0px;">> </div><div style="white-space: pre-wrap; margin: 0px; text-indent: 0px;">> But...what static web server is <a href="http://opam.ocaml.org">opam.ocaml.org</a> using? If it's nginx, then</div><div style="white-space: pre-wrap; margin: 0px; text-indent: 0px;">> it should already have support for this, or we could configure it to serve</div><div style="white-space: pre-wrap; margin: 0px; text-indent: 0px;">> SSL traffic directly...</div><div style="white-space: pre-wrap; margin: 0px; text-indent: 0px;">> </div><div style="white-space: pre-wrap; margin: 0px; text-indent: 0px;">> </div></div></blockquote></div><br></div></body></html>