On Wed, Apr 20, 2011 at 02:52:03PM +1200, Tim Foster wrote: > Hey Ed, > > ( http://cr.opensolaris.org/~bpytlik/ips-sysrepo-v1 ) > > On Tue, 2011-04-19 at 17:37 -0700, Edward Pilatowicz wrote: > > > We could - what's the rationale for not including it though? As is, the > > > sysrepo provides enough functionality out of the box to act as an > > > easy-to-configure proxy cache for http, https and file repositories > > > (even without the sysrepo-aware client code) > > > > > > > i thought the file wasn't used for sysrepo functionality and according > > to the XXX comment it would expose GZ repository paths to a NGZ. hence > > i suggested removing it. > > I see. No, the only thing that's exposing the file path from the global > zone (and by that, I mean just the pathname itself, not the path, > obviously) is the description text that says: > > ---- > "description": "This is an automatic response. This publisher is > generated automatically by the IPS system repository, and serves content > from the file-based repository ${uri}" > ---- > > The ${uri} variable here, is being replaced with the file:// path - it's > purely descriptive, and doesn't need to be there at all. >
> > > Without this file, it still gets to act as a proxy cache for http and > > > https repositories - it just drops support for file:// repos. It seems > > > weird to omit file repo support here just because we can? > > > > > > > so to be clear. if we remove this file, do we lose the ability to proxy > > file:// repos into a zone? > > No, we proxy file repos into a zone without serving a "publisher/0" > response (clients in a zone obtain their publisher information from the > system repository using a "syspub/0" response) so removing this file > wouldn't affect zones at all. > > I'm arguing to keep the publisher/0 response, even though zones don't > use it, because then the system publisher can also act as a general > purpose depot for clients who still need the publisher/0 response. > > [ for example, installing multiple newly-created images over NFS-backed > file:// repositories would normally be quite slow - we could > dramatically speed this by going through the system publisher, which > would use the Apache proxy ] > > Does that help clarify? Oh, following up on your other point about > crypto.txt, yep I've tested it, and it works fine, but I'll nevertheless > watch out for it when attempting to run the service as non-root, just in > case (despite the chowning in the code) > ok. i guess it's fine as is. ed _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
