Hi Ed,
On Fri, 2011-04-15 at 14:01 -0700, Edward Pilatowicz wrote:
> replies below (many comments elided with "...")
Sorry I missed your response till now,
> > I could simply touch them as part of the start method script, instead of
> > delivering empty stubs, but felt that having some means for an
> > administrator to 'pkg search' for a location for sysrepo logs would be
> > neat.
> >
>
> sounds good to me.
Cool, I'll leave the logs in place.
> > > ----------
> > > src/svc/svc-pkg-sysrepo
> > > src/svc/pkg-sysrepo.xml
> > > - why are we bothering to support prefork and worker type apache
> > > deployments. can't we just decide on one and use that?
..
>
> i guess my point is that i'd rather not make this a user configurable
> option now (which it seems to be since the files are marked as
> editable). if we discovere performance issues we can do some additional
> work and change the setting if we want.
That's a fair point - I'll go with prefork for now in that case (the
default for Apache on Solaris) - which, along with the changes below
will make the method script a lot simpler.
> > > ----------
> > > src/svc/svc-pkg-sysrepo
> ah. i didn't realize that apache changes it's user. a comment to this
> effect would be good.
Sure, I'll add that if the idea below doesn't work,
> also, fyi, we don't need to be root to access low number ports. in an
> smf profile we can just specify the pkg5srv user and the priv required
> to access low numbered ports. (you don't have to deploy this way i just
> wanted to mention it to make sure you're aware of the option.)
Absolutely. It'll be worth experimenting with the SMF manifest to see
if Apache is happy to start with these more limited privileges, rather
than have it run as root in the first place. I'll give it a go.
> > > - given that we're using apache as an embedded server i don't think we
> > > should be sourcing ${APACHE_ETC_ROOT}/envvars (since it in turn
> > > sources /etc/apache2/2.2/envvars which presumably exists to configure
> > > the the general apache server, not our embedded one.)
> >
> > We can't avoid that if we're using the stock copy of apachectl
..
> i just looked at apachectl. i'd say we don't bother with it since we
> dont use the majority of stuff in it.
I'm mistaken in thinking we were using apachectl - looks like we're just
using $HTTPD with a -k option to specify start/stop/refresh parameters,
which simplifies the divorce from /etc/apache even more.
> > Driving a bigger wedge between /etc/apache2 and the system
> > repository is needed.
>
> really, the only thing we should be using from apache2 is the httpd
> binary and the stock configuration. ie, we should avoid anything in
> /etc/apache2.
Totally agreed.
> > > ----------
> > > src/util/apache2/sysrepo/envvars
> my thoughts here are that apache is really an implementation detail of
> the sysrepo service, and until we get more experience with it i don't
> see any reason to allow customers to tweak with the internals of the
> system repo. (and even when we do decide that we want to expose
> configuration variables for the system repo to say tune perf in
> different environments, i'd rather expost those tunables via sfm
> properties instead of telling users to edit apache config files.)
That sounds perfectly reasonable, I'll make that change.
> > > ----------
> > > src/util/apache2/sysrepo/sysrepo_publisher_response.mako
> > [ I'd like to keep it around in the meantime if nobody objects, as it
> > makes testing the server code a little more straightforward, and has
> > some interesting possibilities for the future (like using the system
> > publisher as one-stop proxy for common groups of pkg publishers) ]
> >
>
> sure. in that case can we just not install it by default? perhaps have
> it installed by the pkg developer package?
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)
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?
It feels like there's some common functionality between the proxy cache
that sysrepo provides, and the mDNS support in pkg.depotd, different
layers of the stack admittedly :-/
cheers,
tim
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
