[opam-devel] broken stats on opam.ocaml.org

[Anil Madhavapeddy]

Great!  The only other thing that would be nice is a redirect to some of the key pages on opam.ocamlpro.com  (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...

-anil

On 18 Oct 2013, at 18:10, Louis Gesbert <louis.gesbert at ocamlpro.com> wrote:

> Ok, I've turned nginx https on, and disabled stud. The logs look ok now, and the stats should be good.
>  
> I also noticed that some client weren't redirected to the new repo yet, because the opam-admin on ocamlpro.com 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.
>  
> Le vendredi 18 octobre 2013 12:57:48 Anil Madhavapeddy a écrit :
> > On Fri, Oct 18, 2013 at 01:50:28PM +0200, Louis Gesbert wrote:
> > > the stats are generated from the http log. Since monday, the hits are
> > > all logged by nginx as coming from 127.0.0.1, which obviously breaks the
> > > stats :/ Any idea on how the configuration (proxying etc.) may cause
> > > this and possible solutions ?
> > 
> > Good point -- we're using Stud:
> > https://github.com/bumptech/stud
> > 
> > It has support for something that solves our problem:
> > > stud will optionally write the client IP address as the first few octets
> > > (depending on IPv4 or IPv6) to the backend--or provide that information
> > > using HAProxy's PROXY protocol. When used with the PROXY protocol, stud
> > > can also transparently pass an existing PROXY header to the cleartext
> > > stream. This is especially useful if a TCP proxy is used in front of stud.
> > > Using either of these techniques, backends who care about the client IP
> > > can still access it even though stud itself appears to be the connected
> > > client.
> > 
> > But...what static web server is opam.ocaml.org using?  If it's nginx, then
> > it should already have support for this, or we could configure it to serve
> > SSL traffic directly...
> > 
> > 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ocaml.org/pipermail/opam-devel/attachments/20131021/12e0d484/attachment.html>