On 01/11/13 11:14 AM, [email protected] wrote:
Would it make sense to *always* create such a dataset in some other
(core) smf(5) service if it doesn't exist and then rely on the user to
enable the pkgrecv smf(5) service if they want it? It would mean by
default there would be an empty dataset sitting around even on systems
that aren't going to mirror but that seems like a small price to pay.
Yes, that seems like a good idea - thanks!
On 01/11/13 11:56 AM, Dave Miner wrote:
> I wouldn't say I feel strongly about this, but I would probably
> recommend to users to create separate datasets as a best practice and
> that's been a guiding principle in many of our decisions, so that's
> why I raise it.
Fair enough. I'm going to be on vacation for the next 2 weeks, but I'll
see if there's a way I can make this work when I get back: I agree that
having a separate dataset is a best practice, and we definitely should
make it painless for users to follow this best practice where possible.
On a related note, the default of mirroring the '/release' repository is
useful, but would not be enough for users who use the '/support'
repository. Those users would need to modify the
'config/origins'
'config/ssl_key_paths'
'config/ssl_cert_paths' and possibly
'config/https_proxies'
properties in the service instance before it would be useful to them,
and that's not a terribly pleasant user experience.
So instead, I'm thinking of adding a new property:
config/mirror_image_publishers = <space-separated list of publishers>
which, if set would cause this instance of the mirror service to consult
the image the service is running on to obtain origin, key, cert and
proxy information for those publishers, and pkgrecv those to the local
repository. (this might call for a 'pkg publisher -o' flag too :-/ )
The default setting for this property would be 'solaris', and we
wouldn't need to set 'config/origins' as a result.
Sound reasonable? I'm happy to bikeshed on the property name.
cheers,
tim
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
