I have been keeping all my Subversion repositories on my local computer for a while, but now I decided to move them to my web hosting server. It's an apache server and the hosting company has set up svn. My question is, where should I store my svn repositories. I originally stored them in the public_html/ directory, but (I'm certainly no security expert) I think only publicly available web content should be stored there. On the other hand, if I try storing the repositories in ~/var/svn/ then my subversion client (Eclipse) says "no element found". How do other people store their repositories with regards to Apache? Thank you.
You can select any physical location for your repositories collection, because logical path is defined inside Apache (Location container + SVNPath|SVNParentPath) later. You have only
select big partition (repository may require a lot of space)
don't forget chown|chmod repo dirs, in order to give Apache process the ability to handle files of repository
/var (/var/repos/) is good candidate for repo-root
Typically, you would store data in an appropriate subdirectory of /var (not ~/var), that is if you have access to it. E.g. /var/svn
We haven't adopted SVN for our web source yet, but have been using CVS. Our solution was to simply prevent Apache from serving the CVS store using IndexIgnore
IndexIgnore .??* *~ *# HEADER* README* RCS CVS *,v *,t
You may be able to do something similar, using something based upon .svn.
It will be difficult if you are using a shared web hosting, because you need to have an access to root, to create svn-group and creating the structure of the repository. You also need to install some module on Apache like dav_svn. You will need to create a VirtualHost (sites-available) in order to serve your repos over a specific DNS.
There is a lot of tutorial on the inter-webs -> http://www.debuntu.org/how-to-subversion-svn-with-apache2-and-dav/ (for ubuntu)
Me, I rent a Virtual Private Server to host my SVN.
Related
I am writing a set of svn hooks to allow remote management of the SVN repository, just like gitolite does with GIT.
I created the script that generates the AuthzSVNAccessFile for each repository I have, now I need to tell Apache to look for each of them depending on the repository.
I cannot have a apache config file for each repository, because it would need to restart the apache server.
I know I can use a single AuthzSVNAccessFile to manage multiple repository, but the script that build the file takes time (need to discover the full path of every dir inside the repository), and would make the commit take too long.
I tried to use mod_rewrite, but it did not work, maybe I used it wrong.
Basically I need to have a rule in my apache configuration file that reads different file depending on the URL requested, is that possible? How?
Or I need a script able to rewrite a block of a file. I am using sed to replace the strings I have in my template, but do not know how to use it to replace multiple lines.
Thanks for your time
No idea why you're trying to use mod_rewrite unless I'm entirely misunderstanding your question. But it sounds like you are using SVNParentPath and are having trouble figuring out how to configure the authz settings for all the repositories.
You have a couple of options.
Use one authz file
You can actually generate a single authz file and specify which repositories the rules apply to. The syntax is of the form [repos-name:path] (as you can find in the Path-Based Authorization section of the Subversion Book). One disadvantage of this is that if you have a lot of repositories and a lot of paths with rules it can slow things down. Which it sounds like you've run into. One thing that can help mitigate this some is using the following configuration
SVNPathAuthz short_circuit
SVNPathAuthz controls how requests for paths other than the URI are authorized when other paths need to be accessed than the URI of the request (e.g. log, commit, etc). The default behavior is to issue a sub-request. This generates a new GET request in httpd and sends it through all of the authorization infrastructure for httpd. However, in almost all cases this is not needed since the only authorization configuration that can vary with the path under the Location being used to serve SVN is the mod_authz_svn configuration. short_circuit, tells Subversion to avoid all of this and simply send the authorization info straight to mod_authz_svn who provides the answer directly limiting the delay.
That may still not be enough so there are a couple of alternatives, but you'll need at least 1.7 to use them.
AuthzSVNReposRelativeAccessFile
Subversion 1.7 added a new configuration directive that lets you specify a path relative to the conf subdirectory of the repository. For instance if you have a repo named foo you can put the authz file in /path/to/foo/conf/authz and then set the following configuration value:
AuthzSVNReposRelativeAccessFile authz
The directive prior to 1.7 that was used AuthzSVNAccessFile was relative to the server root path.
In Repository Authz*
Subversion 1.8 allows you to store the authz file in the repository itself. So for instance if you committed the file in the repo in a directory named conf as the file authz then you'd do:
AuthzSVNAccessFile ^/authz
The ^/ syntax is replaced with the full path to the repository.
You probably want to read the details on the linked release notes for 1.8 if you decide to use this.
I have an account on some VPS(friend's apache server with cPanel) and there I have one public_html directory.
We have in there about 5-6 websites:
/home/myusername/public_html/domain-1.name/index.php
/home/myusername/public_html/domain-2.name/index.php
but I don't like this way, I'd like to orginise it better and be able to separate and isolate some stuff for each website.
So what if I create like that:
/home/myusername/websites/domain-1.name/public_html/index.php
/home/myusername/websites/domain-2.name/public_html/index.php and so on
Would it be a correct way of structurising web directories?
And would apache work like that?
Perhaps there are out there some other conventions or common workarounds?
Thanks
This is perfectly fine. In fact I'd highly recommend against using the domain folder as the document root as typical web application will also contain data that is not publically accessable (e.g. configuration files, management scripts, version control files, etc.)
Personally I prefer the name htdocs and I keep my sites under /srv/http
For example:
/srv/http/user1/domain1/htdocs/
/srv/http/user1/domain2/htdocs/
/srv/http/user1/domain3/htdocs/
/srv/http/user2/domain4/htdocs/
/srv/http/user3/domain5/htdocs/
That way you can set the DocumentRoot to the htdocs directory and put other stuff that is not meant to be delivered by the web server in a different sub directory of the domain directory.
Ok, I want just to conclude and to outline the way I went with.
Thanks to #bikeshedder for ideas!
So having a single account(none-root) /home/myusername/ under linux VPS server, I didn't want to abstract completely from existent directory structure, but at the same time I wanted to create proper environment to isolate and separate clients and their spaces.
Main goals were:
* The new directory structure should help to keep all files and folders in a nice and clear order.
* Easy to navigate and browse.
* Each developer or client would have access only to their space.
The structure:
/home/myusername/http/client-1/domain-1/public_html/index.php
/home/myusername/http/client-1/domain-1/resources/
/home/myusername/http/client-1/domain-1/configuration.php
/home/myusername/http/client-1/domain-2/public_html/index.php
/home/myusername/http/client-1/client's_resource_dir/
/home/myusername/http/client-2/domain-3/public_html/index.php
/home/myusername/http/client-2/domain-3/subdomain/public_html/index.php
As result:
* We have isolated client's space and isolated domain space. That makes enough room for any type of web projects.
* Files and dirs are not mixed up with other projects, domains and clients anymore.
* For subdomain paths it can be
- as subdirectories /domain-3.name/subdomain/public_html/
- or additional subdomain directory /subdomain.domain-3.name/public_html/depending on requirements or size of subdomain website.
* Public_html is going to be a DocumentRoot for each website.
I did not go for srv/ and var/www dirs, cuz to me it sounds like server in the server and also I don't feel variable data var/ in current setup falls under web stuff.
Though it may make sense for our coming soon local web/file sharing server
But here now I have another question:
How would I specify new path to be a default one for cPanel? and only for my user?
Cuz now there is going to be multiple DocumentRoot directories in one user space.
Is that possible by Apache design?
I better create new question :) And then will edit my question with answer
Any suggestion welcome!
Normally go with this once hosting from 5-30++ sites, depending on complexity of content, traffic, perceived future migration strategies to more dedicated virtual or bare metal servers/instances.
/<node-serial-or-hostname-or-domain>/<#|subdomain|www|others>/index.<html|php|jsp|aspx|what-not>
/<node-serial-or-hostname-or-domain>/<#|subdomain|www|others>/assets/...
/<node-serial-or-hostname-or-domain>/<#|subdomain|www|others>/index.<html|php|jsp|aspx|what-not>
/<node-serial-or-hostname-or-domain>/<#|subdomain|www|others>/assets/...
/<node-serial-or-hostname-or-domain>/<#|subdomain|www|others>/index.<html|php|jsp|aspx|what-not>
/<node-serial-or-hostname-or-domain>/<#|subdomain|www|others>/assets/...
/<node-serial-or-hostname-or-domain>/<#|subdomain|www|others>/index.<html|php|jsp|aspx|what-not>
/<node-serial-or-hostname-or-domain>/<#|subdomain|www|others>/assets/...
/<node-serial-or-hostname-or-domain>/<#|subdomain|www|others>/index.<html|php|jsp|aspx|what-not>
/<node-serial-or-hostname-or-domain>/<#|subdomain|www|others>/assets/...
I've already setup Apache to manage svn requests.
Basically the structure of the svn related directory is this:
/Repository
-----OneRepo
-----TheOtherRepo
Repository is a "normal" directory, while OneRepo and TheOtherRepo are svn repositories.
I've used SVNParentPath and SVNListParentPath directives and if I go to localhost/Repository/ (with my browser) I can see all my repositories.
Now, if I try to access a single repository (for example: OneRepo) from a client (in my case Cornerstone but Versions is the same) everything works fine.
The problem is that I would like to access the repository listing from the client so that I have a big "folder" with all my projects in it. Does it make sense?
So, instead of writing http://192.168.x.x/Repository/OneRepo in my client (and it works) I would like to write http://192.168.x.x/Repository/ and view a listing of project and so checkout whatever project I would like to.
Is that possible?
Thanks
This works only in a http browser. So your standard SVN Client (commandline , TortoiseSVN, etc.) can not list your repositories
When working with apache on a unix system,
If your file system has icons in /home/me/web/icons
and you want the browser be able to display them when calling the url http://www.me.com/icons/myicon.jpg
for example,
then you have at least 2 solutions :
alias ( Alias /icons/ /home/web/icons/ )
symbolic links ( ln -s /home/web/icons /home/me/web/www/icons )
It seems to me that using apache aliases is the best choice since we know exactly that aliases
would normally be in the /etc/apache2 directory ( so that is just one place to look at in case the application
grows ), but I would be pleased to know about what solution you use and why ?
Using an Alias in your Apache httpd has several advantages over using a symbolic link:
Symbolic links require an additional disk access to resolve the symbolic link.
Alias works on all platforms supported by Apache httpd. Symbolic links are not supported by all platforms and filesystems.
Your Apache httpd configuration will work the exactly same way on a new system without the need to create symbolic links in your file system.
With shared hosting you are not authorized to alter the Apache config, so a symlink is an alternative.
Using an alias in the config file effectively documents your configuration. Using a link might well work but would not be an approach i would take.
On a productions machine I would use neither. Giving access to a user's directory would not be ideal from a security perspective. From the point of version control the icon directory should be filled like any other resource be it html or other form the QA'd release.
J
I have an existing web application which I have been building with an ant script and deploying as a .war file to Tomcat.
I am trying to add Drupal to my current technology stack to provide CMS and general UI-related functionality so that I don't have to write my html pages by hand and rather use templates.
During the installation of Drupal7, some of the instructions suggest that I go to this directory:
/etc/apache2/sites-available
and change the DocumentRoot to
/home/myuser/drupal/drupal7
If I make the docroot a basic directory on the file system, how will this impact how the application will work? In addition to Apache, I also have Tomcat server. My goal is to get them to all play nice together. How is this best accomplished?
If I make the docroot a basic directory on the filesystem
I'm not sure what you mean by this. There's no qualitative difference between /var/www and /home/mysuser/drupal/drupal7. The latter is longer and in the user's home directory, but assuming this user would be administering the service anyway that doesn't matter.
Next, the best way to make Tomcat and Apache get along is probably to run one of them on different subdomains. You could use the same domain, but that'd mean you had to run one of the daemons off a nonstandard port and that looks strange and might run into firewall trouble with some users.