Thread: [http-replicator-users] http-replicator license
Brought to you by:
g3rtjan
From: Ed S. <es...@ar...> - 2008-01-30 06:39:35
|
Hello Gertjan, Thanks for developing http-replicator. It will be very useful for people who want to set up a site-local yum/apt repository without messing with rsync or complicated caching proxy servers. I have already posted a patch with some minor extensions supporting this application. I would like to package http-replicator as an rpm and submit it to the Fedora project. I notice it is missing a license. Would you mind adding a LICENSE file to the source tree? Thanks, --Ed |
From: Gertjan v. Z. <ger...@gm...> - 2008-01-30 08:05:29
|
Hi Ed Thanks for developing http-replicator. It will be very useful for > people who want to set up a site-local yum/apt repository without > messing with rsync or complicated caching proxy servers. I have > already posted a patch with some minor extensions supporting this > application. Sounds good. Is this a replicator patch and, if so, would it make sense to have these changes in the original as well? I would like to package http-replicator as an rpm and submit it to the > Fedora project. I notice it is missing a license. Would you mind > adding a LICENSE file to the source tree? Sure. Actually now that you mention it I believe Sourceforge demands the same. I was rather aiming for next release to bring some improvements I was working on, but unfortunately my hard disk crashed before committing any of them to svn. Tough luck.. So now I will make a minor release instead with only the GPL licence file added, just to have something packagable. The improvements will follow soon as I worked up the spirit to start over. Thanks for the initiative! Gj |
From: Ed S. <es...@ar...> - 2008-01-30 15:34:51
|
On 1/30/08, Gertjan van Zwieten <ger...@gm...> wrote: > Sounds good. Is this a replicator patch and, if so, would it make sense to > have these changes in the original as well? Yes, certainly. I posted the patch to the tracker at http://sourceforge.net/tracker/index.php?func=detail&aid=1882403&group_id=195382&atid=953220 . > Sure. Actually now that you mention it I believe Sourceforge demands the > same. I was rather aiming for next release to bring some improvements I was > working on, but unfortunately my hard disk crashed before committing any of > them to svn. Tough luck.. So now I will make a minor release instead with > only the GPL licence file added, just to have something packagable. The > improvements will follow soon as I worked up the spirit to start over. Great, thanks. --Ed |
From: Gertjan v. Z. <ger...@gm...> - 2008-01-31 10:18:18
|
Ok - I released 4.0alpha2 with a GPL license file. Yes, certainly. I posted the patch to the tracker at > > http://sourceforge.net/tracker/index.php?func=detail&aid=1882403&group_id=195382&atid=953220 I see. I suppose the --nohost option is meant to be an easy way of dealing with mirrors, limited to hosts that serve files in exactly the same directory structure? I was thinking of using symlinks for that purpose, manually put in the cache directory for host/path prefixes that are known to have identical content. Symlinks form a security risk so I should still add a check that prevents pointing away from cache, or maybe away from a list of allowed paths, but that is a different matter - the approach should already work. Granted it takes a little more work to make these links, although of course I would suggest to script it, but it is definitely safer than setting all hosts equal. Compare the old --flat option that went as far as stripping away everything but the filename itself, and then consider a common file like index.html. The --mirror option, if I see it correctly, prepends a host/path prefix to every requested file. I can't quite figure out the use from the patch summary. Is it your aim to configure at proxy level which mirror is used to download packages from? Wouldn't the same be achieved by setting all mirrors equal by the above symlink approach? Gj |
From: Ed S. <es...@ar...> - 2008-01-31 18:49:05
|
Sorry about my vague description of the patch. I hope I can clarify it: The purpose of the --mirror option is to make http_replicator behave as a reverse proxy rather than a normal proxy (so maybe it should be called --reverseproxy or something more precise). Let's say you run two instances of http_replicator on myserver: http_replicator --port 8080 --root /proxy http_replicator --port 8081 --root /mirror --mirror http://upstream.com Then you can download a document from upstream.com in two ways: http_proxy=http://myserver:8080 wget http://upstream.com/foo/doc.html wget http://myserver:8081/foo/doc.html The second http_replicator instance is effectively serving as a local mirror of http://upstream.com, just as if it were a regular httpd serving static content that the admin had manually rsynced from http://upstream.com. Since this instance proxies requests only to a single host, all the cached content ends up under /mirror/upstream.com:80; the --nohost option avoids this redundant directory level. Does that make sense? --Ed |
From: Gertjan v. Z. <ger...@gm...> - 2008-01-31 11:09:18
|
Hi Shashank I'll probably be able to make a .deb for it as well, and try to get it > into (ubuntu) universe. I hope that's ok. Sure, more than ok. I used to provide a deb myself but I never managed to get it in the official (debian) repository. Then when I switched to macintosh I decided to leave packaging to others altogether. So if you would care to take this task upon you for the ubuntu world: please go ahead! Thanks Gj |