On Apr 11, 2007, at 22:14, Bruce Wilson wrote:
> I've been using Subversion locally for over a year now (both as a
> Windows install, and then through Apache in a VMware Server image),
> and I'm ready to push it out to my team. I have a FreeBSD server
> running Apache 2.2 and Subversion 1.4.3, both from the ports
> collection, but with careful option selections. I've chosen to use
> WebDAV access, and for the repository to be only available via
> SSL. (Yes, each site has its own IP, and I'm running IP-based
> vhosts.)
>
> The challenge: this server hosts two bugzilla installs as well (IP-
> based vhosts on one instance of Apache). I want to keep Subversion
> segregated from the other sites in the following ways:
> WebDAV should not be available to the bugzilla sites. Subversion
> instance should not have access to modules specific to Bugzilla.
> Subversion running at the root of the new site.
> The Bugzilla sites should not have file permissions to the
> Subversion repository.
> Configurations should not "bleed over" from one site to the other.
> That is, if I grant/deny a permission on a path in the bugzilla
> site, and that same path exists in Subversion, the permissions
> should not carry over.
> I've looked into running two instances of Apache using the
> "profiles" feature. Documentation on how this works is scarce, and
> most of the pages Google could find talked about why you should use
> vhosts instead of multiple instances of Apache. In my scenario, I
> think separate instances are warranted, since I want modules and
> file access to be different per instance of Apache.
>
> Can anybody point me to a good reference for the scenario I described?
>
> For that matter, the Apache docs explain vhosts well and SSL well,
> but not vhosts with SSL. The .conf files seem to be overlapping in
> purpose, yet settings for each site may appear in multiple files.
> I haven't figured out how best to merge the information into one
> configuration per virtual site.
>
> The other possible scenario is to run Subversion as yet another
> vhost, so long as I can lock down module capabilities by site. The
> Apache examples focus on single-site configurations (as I suppose
> they should), which means all path references start with /, so I'm
> not terribly confident that a setting won't apply in more places
> than it should.
>
> I realize these questions are pretty Apache-specific. I looked at
> both the Apache lists and this list, and it seemed like topics like
> mine (WebDAV + SSL + vhosts) come up more frequently here than at
> Apache. My apologies if I've posted to the wrong place.
>
> I'm going to snuggle up with my O'Reilly "Apache, the definitive
> guide" again tonight to see if I missed something, but I'd love to
> hear from anyone who has already tackled a scenario like mine.
I've never heard of Apache's "profiles" feature. I don't see any
reason for you to run a second copy of Apache. Just use another vhost
for your Subversion repository(ies).
If all your vhosts use SSL, then you need a separate IP address for
each vhost. (More specifically, you need one IP for each SSL vhost.
If you have additional non-SSL vhosts, they can be name-based and can
share an SSL vhost's IP, or use their own IP, as you wish.)
Certainly you can define rules based on paths, and have those rules
apply only to a particular vhost. Just nest the directives.
<VirtualHost *:443>
ServerName svn.example.com
<Location /svn/>
...
</Location>
</VirtualHost>
--
To reply to the mailing list, please use your mailer's Reply To All
function
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Apr 12 07:21:59 2007