 |
 |
I think a standard case is that a manger is visible inside and outside, while the server's aren't. Only the open (+ everything afterwards running on open files read,write,truncate.sync,close etc.) should go through an extra IO gateway (Proxy) while the rest can be handled by the manager in the same way for internal and external clients. The only thing to proxy is the direct IO on open files ... and the locate function of a file from outside should point to the gateway. Cheers Andreas. On Fri, Oct 1, 2010 at 8:06 PM, Andrew Hanushevsky <[log in to unmask]>wrote: > Hi Andreas, > > That's fine but just opens? I woud think anybody comming in from he > internal network should get redirected t something internal and avoid the > external node. Does that make sense or do you want fine grained control? If > so, is there a particular worrisome request path that I'm missing? > > Andy > > > On Fri, 1 Oct 2010, Andreas-Joachim Peters wrote: > > Hi, >> I have a question considering the proxy support (which actually comes from >> Doug/ATLAS). >> Is there an existing implementation/configuration allowing to direct >> internal site traffic via the site redirector to disk servers while >> external site traffic via one (or several) proxy server to >> redirector/diskservers. Eg. is there a 'switch' to redirect external >> clients >> to a proxy gateway and >> internal clients directly? I couldn't figure that out even reading the >> source code .... looks like there is none .... >> >> If not, would you consider adding an OFS directive which redirects 'opens' >> to a proxy gateway based on IP ranges/maskes or just an internal and >> external IP mask. >> >> The internal flow of an open would than be >> >> open@manager=>open@server >> >> the external flow >> >> open@manager=>open@proxy:=>XrdClient(=>open@manager=>open@server) >> >> while all other meta commands would only go via the manager. >> >> Cheers Andreas. >> >>