What's the best practice for setting up a subversion repository on a linux development machine. External users need to be able to access a specific repository, but nothing else on the machine. I know one answer is to set up a dedicated repository, but I'm looking for a single machine solution: location of repositories, accounts, backup procedures.
One of the popular access methods to Subversion is via Apache module. You can set put different rights at the directory level to control access. See Choosing a Server Configuration and httpd, the Apache HTTP Server. For authentication, I recommend using external authentication source like Microsoft AD via mod_auth_sspi.
If you need to mix and match rights, see my answer for How can I make only some folders show up for certain developers with SVN.
I work for an IT operations infrastructure automation company; we do this all the time.
Location of repository: We use "/srv/svn" by default to store all SVN repositories, unless a customer has a specific requirement, for example an existing repository might be stored on a ReadyNAS shared filesystem.
Accounts: All our customers use LDAP. Either OpenLDAP server running on a master host, but sometimes Active Directory because some customers have a Windows domain in their office, which we can configure as well. Developers get access to the "SCM" group (usually svn, git or devel), and the 'deploy' group. These groups only have permissions to log in and perform SCM related activities (ie, write commits to the repo based on group ownership), or do application deployments to production.
Backup procedures: We use svnadmin hotcopy unless the customer already has something in place (usually svnadmin dump, heh).
svnadmin hotcopy /srv/svn /srv/svn_backups/$(date +%Y%m%d)
For access to the repo, it's usually simple svn+ssh. Some customers already have an Apache setup, but not many. I recommend SSH. Developers push their public ssh keys out and all is well. There's little to no maintenance with LDAP user management (the only way to go).
I'd recommend looking at the chapter on server configuration in the subversion book. It makes suggestions about which configuration is more appropriate for your use.
For what it's worth, setting up a repository using the stand alone svn daemon is very straight forward. The annoying thing is managing user rights.
I have a blog posting that describes the steps necessary to set up and initiate a Linux-based Subversion server in order to maintain code repositories etc.
Basically the steps are:
Download the Subversion tarball.
Unzip and install Subversion.
Deal with any installation problems that arise when running ./configure, if any.
Create the Subversion repository using svnadmin create.
Edit the repository configuration file using your text editor of choice.
Ditto the password file.
Import your code, projects etc into the repository using svn import.
Start the server as a daemon eg svnserve -d. It is also possible to get it to do this automatically
upon reboot.
Start using it using standard Subversion commands to eg check out, check in, backup etc...
Related
I know it's a bit of a pain to do, but I have multiple accounts for my personal accounts and work accounts. I generate tokens for these accounts so they have restricted access and I don't have to use my actual password so it is more secure. The problem I have is that there doesn't seem to be a very good way to store these passwords for multiple accounts. This applies for both Windows and Linux. The "easiest" way I found was just to have multiple user accounts on the system, which isn't that convenient. Otherwise if you have one repo and you try and set the user using git config user.name etc, it'll use the wrong password/account anyways for that repo.
Is there an easier or better way to go around this? To have multiple passwords saved for git and just be able to choose the account you want to use for the repo and have it just work?
Most common way people solve this issue is to: git config --global credential.useHttpPath true - and have different user/pass record in credential storage for every repo. But if you have tons of repos, this can pollute credential store quite fast, making it not really that nice of a solution.
You would end up with records like:
git:https://PersonalAccessToken#github.com/YourUsername/YourRepo1.git
git:https://PersonalAccessToken#github.com/YourUsername/YourRepo2.git
git:https://PersonalAccessToken#github.com/YourUsername/YourRepo3.git
git:https://github.com/YourUsername/YourRepo1.git
git:https://github.com/YourUsername/YourRepo2.git
git:https://github.com/YourUsername/YourRepo3.git
The way I prefer to solve this issue is to use credential.namespace git config option. Idea is to create different namespaces for your different accounts, so that they don't clash in your system credential manager.
For example (using github.com as example url), you can decide one of those accounts is your main and set it up in global git config:
git config --global credential.namespace "MainAccount"
git credential approve
url=https://github.com
username=YourMainAccUsername
password=YourMainAccPasswordOrToken
<Enter>
and then enter repo where you want to log in with different credentials and set it up locally:
cd path/to/other/repo
git config credential.namespace "OtherAccount"
git credential approve
url=https://github.com
username=YourOtherAccUsername
password=YourOtherAccPasswordOrToken
<Enter>
And you can verify in your credential manager, you should have two new records:
MainAccount:https://github.com/
OtherAccount:https://github.com/
And you can verify in command prompt what credentials will be sent to git server:
git credential fill
url=https://github.com
<Enter>
You might consider using a credential helper like the recent (July 2020) GCM Core, announced by GitHub.
Git Credential Manager Core (GCM Core) is a secure Git credential helper built on .NET Core that runs on Windows and macOS.
Linux support is planned, but not yet scheduled.
For Linux, in the meantime, you can use the Java GCM.
(see last section below)
In both instance, the usage is the same: you can cache credentials (like your token) for a given URL.
Update Sept. 2020 (2+ months later) for Linux: microsoft/Git-Credential-Manager-Core issue 135 mentions, From GitHubber Matthew John Cheetham:
We have a pre-release of a GCM Core that supports Linux! 🥳
At the moment we provide a Debian package, and a tarball of the git-credential-manager-core single binary.
The .deb is currently unsigned and not uploaded anywhere except on GitHub.
We are in the process of getting package signing set up and will be publishing it to an official Microsoft feed (so you'll be able to use apt-get!).
Currently the pre-built binaries are only provided for 64-bit Intel processors.
See more at Credential stores on Linux
There are currently three options for storing credentials that Git Credential Manager Core (GCM Core) manages on Linux platforms:
freedesktop.org Secret Service API
GPG/pass compatible files
Plaintext files
Update Aug. 2021: issue 135 is now closed by Matthew John Cheetham (GitHub staff):
Closing this issue as GCM Core can now run on Linux distributions.
For further issues/bugs, or support for more distributions please open new issues. Thanks!
I am new to Git and after I lots of searching I found that I must have set Linux permissions in my Git server.
But I want to know, is it possible to set permissions in Git?
I am working on a team about six people and I don't like to everyone on the team can access all the project for security reasons.
For example, If somebody in my team works on UI in my Store section I want to he/she have it's own branch but when he/she PULL the project with Git just have access to files and folders I let.
I have to add that I have my own Git server on a local network using Linux Debian and I'm using "SourceTree" as my GUI for Git and I have few experience on Git command line, so I need do it from GUI if possible.
Edited:
Does Git lab support permission like this: I have a repository that uses Laravel framework and I'd like to set permission for UI developers that only access views and PHP developers access some controllers not all the part of the controller in the project.
You can checkout GitLab: https://about.gitlab.com/ for this. Out of the box git does not support what you need/want.
No, Git doesn't manage this directly. Anyone with authentication credentials to the repository has access to the entire repository.
Traditionally, this is managed with third-party solutions, such as Gitolite, GitHub private repositories, and other systems.
In addition to other answers: if you want only certain parts of project to be accessible to each developer, you can use git submodules.
This is also preferable if project has logically and functionally separate parts. (Like front-end and back-end. )
I a writing a little webapp, which allows the users to browse through a Visual SVN server. I would like to add an online editor like github in this webapp, so users can edit the files online, leave a message and the changes appear in the repository.
For that I need to checkout the files locally. My idea was to check them in a mongodb out, so I can save the changes per user like a local working copy.
Is there a way (without reimplementing the svn protocol) to make a checkout in a database or even just the memory and then write it in the database.
If there are any questions, just ask :)
Btw. if someone is interested, here is the code https://bitbucket.org/Knerd/svn-browser
There is no way to do svn checkout to directly to database. But there is some options.
First of all, you can simple create virtual disk that resides in memory and perform checkouts to that disk. Than you can store checked out files to database.
Another option is to use rich Subversion API directly. Note, that Subversion is written in C, so you will need to build bridge between Node.js and SVN (as far as I can remember, there is no official Subversion bindings for Node.js, but there is for Python and Java and there is unofficial nodesvn package available for Node.js). Using the API you can implement your own 'in-database' working copy.
Also you can use svnmucc utility (which is shipped with VisualSVN Server) to make commits directly in the repository (without even making a working copy). If you combine it with svn ls, svn info etc. you can implement repository browsing and editing of files.
The idea behind what I am wanting to do is to create a centralized server on a linux system. I understand how to set this up, and already have. Next I would like to set up git on a windows system, aka the client, which I understand is possible through msysgit, and gitextensions. The problem though is that I am wanting to integrate the windows client to be able to push and pull visual studio files but keep the repositories on the linux server. So in short my question is how to have a centralized server on linux for git, while the client on windows is able to push to this centralized server. Thanks in advance!
I solved my problem. What I wanted to do was to create a ssh connection between the server(linux) and the client (windows). I used tortoise git in this case with the git source control provider (visual studio integration). Just follow the steps within the link and anybody else who might have this problem will be set!
Links:
For tortoise setup: http://theswarmintelligence.blogspot.com/2009/11/windows-tortoisegit-client-for-linux.html
What's the catch here? This sounds like a completely standard use case. It's probably best to use SSH as a transport to push to the server. A couple of things to be aware of are:
You should create your centralized repository as a bare repository (i.e. one without a working tree)
If you have multiple users who will push to that repository, create a group for them on the Linux machine, and make sure that the permissions for the repository are appropriate, e.g.:
git init --bare --shared=group newrepository.git
chgrp -R developers newrepository.git
Or if you're going to have multiple repositories or need more sophisticated access control, you may want to look at using gitolite on the server.
On the client side, GitHub has a nice walkthrough for installing msysgit on Windows (and generating an SSH key) here:
http://help.github.com/win-set-up-git/
... and there are tutorials for gitextensions on its site.
This is somewhat related to my security question here. Is it a bad idea to use an hg / mercurial repository for a live website? If so, why?
Furthermore, we have dev, test and production installations of our website, like dev.example.com, test.example.com and www.example.com. If it's a bad idea to use a repository for a live/production website, would it be OK to use an hg repository for the dev and test sites?
I'm also concerned about ease of deployment. We have technical and less technical co-workers who will be working with the site. The technical people (software engineers) won't have any problem working with the command line or TortoiseHG. I'm more concerned about the less technical people (web designers). They won't be comfortable working on the command line, and may even find TortoiseHG daunting. These co-workers mostly upload .css files and images to the server. I'd like for these files (at least the .css files) to be under version control, but I want this to be as transparent as possible for the non technical team members.
What's the best way to achieve this?
Edit:
Our 'site' is actually a multi-site CMS setup with a main repository and several subrepositories. Mock-up of the repository structure:
/root [main repository containing core files and subrepositories]
/modules [modules subrepository]
/sites/global [subrepository for global .css and .php files]
/sites/site1 [site1 subrepository]
...
/sites/siteN [siteN subrepository]
Software engineers would work in the root, modules and sites/global repositories. Less technical people (web designers) would work only in the site1 ... siteN subrepositories.
Yes, it is a bad idea.
Do not have your repository as your website. It means that things checked in, but unworking, will immediately be available. And it means that accidental checkins (it happens) will be reflected live as well (i.e. documents that don't belong there, etc).
I actually address this "concept" however (source control as deployment) with a tool I've written (a few other companies are addressing this topic now, as well, so you'll see it more). Mine is for SVN (at the moment) so it's not particularly relevant; I mention it only to show that I've considered this previously (not on a Repository though; a working copy, in that scenario the answer is the same: better to have a non-versioned "free" are as the website directory, and automate (via user action) the copying of the 'versioned' data to that directory).
Many folks keep their sites in repositories, and so long as you don't have people live-editing the live-site you're fine. Have a staging/dev area where your non-revision control folks make their changes and then have someone more RCS-friendly do the commit-pull-merge-push cycle periodically.
So long as it's the conscious action of a judging human doing the staging-area -> production-repo push you're fine. You can even put a hook into the production clone that automatically does a 'hg update' of the working directory within that production clone, so that 'push' is all it takes to deploy.
That said, I think you're underestimating either your web team or tortoiseHg; they can get this.
me personally (i'm a team of 1) and i quite like the idea of using src control as a live website. more so with hg, then with svn.
the way i see it, you can load an entire site, (add/remove files) with a single cmd
much easier then ftp/ssh this, delete that etc
if you are using apache (and probably iis as well) you can make a simple .htaccess file that will block all .hg files (or .svn if you are using svn)
my preferred structure is
development site is on local machine running directly out of a repository (no security is really required here, do what you like commit as required)
staging/test machine is a separate box or vm running a recent copy of the live database
(i have a script to push committed changes to staging server and run tests)
live machine
(open ssh connection, push changes to live server, test again, can all be scripted reasonably easily, google for examples)
because of push/pull nature of hg, it means you can commit changes and test without the danger of pushing a broken build to the live website. like you say in your comments, only specific people should have permission to push a version to the live site. (if it fails, you should easily be able to revert to the previous version, via src control)
Why not have a repo also be an active web server (for dev or test/QA environment anyway)?
Here's what I am trying to implement:
Developers have local test environments in which they can build and test their code
Developers make a clone of the dev environment on their local dev machine
Developers commit as often as they want to their local repo
When chunk of work is done and tested, then developer pushes working change sets to dev repo
Changes would be merged and tested on Dev, then pushed to Test/QA, and so on.
BTW, we're using Mercurial. I believe this model would only work using a distributed source code management tool.