We would like to start two new development projects: Project1 and Project2. We have two groups of developers:
GroupA should have full (read + write) access to both projects, and
GroupB should have no access to Project1, but full access to Project2.
I followed Jeff Atwood's tutorial and successfully installed subversion 1.7.6 on Windows Server 2003 as a Windows service. I tested the system by adding folders and files, and commiting changes, and everything worked as it should (the client was TortoiseSVN 1.7.9).
Unfortunately, I couldn't figure out how I could configure the access rights of our developer groups in authz. The developers can connect to the server, but get Authorization failed messages when try to commit something.
Thank you for your help in advance.
I advise you to read the SVNBook (Version Control with Subversion). Please see the chapter which describes the path-based authorization. I think that the chapter answers your question.
The sample authz file is provided below. Please note that I don't explicitly set 'no access' rule for GroupB on /repo/Project1 repository directory. I set 'no access' to the root node for 'everyone' and then this permission gets inherited by it's child items unless you explicitly provide access to a folder or a file.
[/]
*=
[groups]
GroupA=john,sally
GroupB=harry,george
[repo:/Project1]
#GroupA=rw
[repo:/Project2]
#GroupA=rw
#GroupB=rw
I'd like to note that you can drastically simplify the process of managing SVN user permissions if you use VisualSVN Server Manager.
It provides comfortable UI to manage user permissions which you can find really helpful:
Update 2016
To manage access rules for SVN repositories hosted on VisualSVN Server you can now use PowerShell cmdlets packaged with VisualSVN Server. Beginning with version 3.4, VisualSVN Server includes PowerShell module that should help you with this task. The cmdlets you are looking for are
Add-SvnAccessRule
Get-SvnAccessRule
Select-SvnAccessRule
Set-SvnAccessRule
Remove-SvnAccessRule
Read the article KB88: VisualSVN Server PowerShell Cmdlet Reference for the complete list of VisualSVN Server PowerShell cmdlets.
Related
I have downloaded VisualSVN Server, version 5.1.1. In the left panel there is only Repositories and Jobs. I want to add new users for learing and testing purposes. However I can't see any settings to do so. I currently dont have a licence. Is this the main reason? If not, how can I enable Users and Groups folders or how can I reach to related settings? Keep in mind that I'm a completely newbie to this application. Any help is appreciated, thanks
I have tried to find related settings in autentication properties but I got confused and bogged down. I have tried to open the application as Administrator, still couldn't find or make sense of settings.
I also tried to find subversion authentication settings which is normally in the main page.
In the MMC snap-in, you should have a Users option down the left hand side of the tree. However, on the main Visual SVN page, you have various options, one of which should be Subversion Authentication. You can also add users and groups using the options here also (see below, for a screen shot of my SVN Server). Regarding the license, that shouldn't be an issue, as long as your requirement fits withing the "Community" licensing requirements.
If you don't see options to Create Users / Groups, use the Configure Authentication Options and set the Authentication Mode to Subversion Authentication. This will allow subversion to authenticate users based on a list that is setup within the server itself. Hope that Helps.
The Users and Groups folders are only available in the management console when your server is configured to use the standalone Subversion authentication mode. When this authentication mode is active, your server maintains a dedicated list of user and group accounts.
However, your screenshot shows that you've enabled Windows authentication. In this case, your server integrates with your Active Directory domain / Windows, and user and group accounts are maintained by Active Directory. I.e., you don't need to create users and groups in VisualSVN Server. They are already created in your domain and you can grant permissions to these accounts via the management console.
You can find more information about the authentication modes in the article KB182: VisualSVN Server authentication modes.
I am very new to udeploy and looking for a feature to pull latest version of artifacts from one of our build tool using simple http download from a given url.
I can see that "Source Configuration Type" has many option available like filesystem, teamcity, git repo etc, but no option is available for a simple url download.
I am actually using teamcity build and teamcity provides GET API to download artifacts, I understand that uDeoploy is also using this teamcity feature but the url it is constructing is not correct and throwing 401 exception (unauthorized) when not auth information is not provided, it should be using teamcity guest access to download the artifacts.
Please Note: when login information is provided it is working fine
any thoughts.
You can adjust the guest account privileges inside the Administration Panel, then inside the Users management, there is a link to setuo the guest account privileges.
Recently I am facing problem of commit to SVN. The SVN server I am using is VisualSVN Server 2.5.9 and the client is TortoiseSVN 1.7.12.
At first, one user is having problem to commit files to SVN. But that user still can access to the repository and download the update. The second user on second PC is working properly. But today, the second user is having the same problem as the first user.
Why is this happen? How can the problem be solved? Thanks.
If the problem lies client side, this could be one of the causes of the error.
On clients TortoiseSVN saves client credentials under
Tortoise settings / saved data / authentication data.
I got the same error trying to commit my files, but my credentials were changed. Clearing this cache here will give you a popup on next commit attempt for re-entering your correct credentials.
You can get the "Forbidden" error if your user account lacks access permissions to a repository or repository path; it makes sense to check authorization settings for your user account. Make sure your system administrator hasn't provided you with No Access permission to the repository path.
If you are sure that permissions are set correctly, then double-check the URL you use. URLs in Apache Subversion are case-sensitive.
Additionally, I advise you to read articles on authorization in Subversion and VisualSVN Server:
SVNBook about path-based authorization.
VisualSVN Team's article about path-based authorization. It explains the principles of SVN authorization by comparing it with Windows Access Control.
The solution for me was to check the case sensitivity of the username. A lot of people are mentioning that the URL is case sensitive, but it seems the username is as well!
As a new user to these two software packages, I experienced the exact same problem. As was also discovered above, my solution was to use the same case letters as is in the Repository path.
Here's a tip that I find helpful: In VisualSVN, you can right click on the path, then click "Copy URL to Clipboard" for pasting in Tortoise to be sure that the path is the identical case.
Actually, I had this problem same as you.
My windows is server 2008 and my subversion info is :
TortoiseSVN 1.7.6, Build 22632 - 64 Bit , 2012/03/08 18:29:39
Subversion 1.7.4,
apr 1.4.5
apr-utils 1.3.12
neon 0.29.6
OpenSSL 1.0.0g 18 Jan 2012
zlib 1.2.5
I used this way and I solved this problem.
I used [group] option. this option makes problem.
I rewrite authz file contents.
I remove group option. and I set one by one.
I use well.
Thanks for reading.
Actually, I had this problem same as you. You can get the "Forbidden" error if your commit includes different directories ; Like external items.
And ı solved in one step. Just commit external items in another case.
Additionally, I advise you to read articles on External Items in Subversion and VisualSVN Server:
VisualSVN Team's article about Daily Use Guide External Items. It explains the principles of External Items in SVN.
https://tortoisesvn.net/docs/release/TortoiseSVN_en/tsvn-dug-externals.html
I had a similar issue in Mac where svn was picking mac login as user name and I was getting error as
svn: E170013: Unable to connect to a repository at URL 'https://repo:8443/svn/proj/trunk'
svn: E175013: Access to '/svn/proj/trunk' forbidden
I used the --username along with svn command to pass the correct username which helped me.
Alternatively, you can delete ~/.subversion/auth file, after which svn will prompt you for username.
I was unable to commit csharp-files (*.cs). In the end the problem was that at some point i installed mod_mono, which made the *.cs-files inaccessible, through its configuration. So it may well be an apache-configuration issue, if only some sort of files are not accessible.
grep ".cs" /etc/apache2/mods-enabled/*
...
mod_mono_auto.conf:AddType application/x-asp-net .cs
...
My issue was my SVN permissions.
I had the same problem "Access to '/svn/[my path]/!svn/me' forbidden" when trying to commit files to a project I had been working on daily for several months. After trying the steps above, I could not resolve the issue. I also tried pulling the project down from scratch, logging in/out of SVN, etc. Finally I contacted my company's IT department and there was a permissions issue that spontaneously emerged which changed my access from read/write to read-only access. The IT department refreshed my permissions and this solved the problem.
I have a strange SVN server configuration issue I cannot figure out.
A previous employee setup Collabnet svn server (version 1.6.9) on a windows server at work which we use for development. It's a great system, love using it.
We use a local LAN path for the repository with all our various folders, like this...
"svn://server1"
It has one repository called "repo".
I have recently installed a second SVN on another server (same version, same OS)
It has one repository called "main". In order to access it I have to use the svn path of ...
"svn://server2/main"
So the question is.... does anyone know how we ended up with one server requiring to use a "repo name" after the server name (and does not work without it) and one server not requiring a "repo name" (and does not work with it)?
The main reason for asking is I also need to setup additional repositories on the original server and do not want to affect the current configuration. I assume this is some level or option or configuration or a "default repo" setting or something, but I just can't seem to find where and how it was set.
Check the entry in your conf file. If you have your svn information within a location tag, the location is the only way to access the repository.
There is an excellent PDC talk available here from Vishal Joshi which describes the new MSDEPLOY features in Visual Studio 2010 - as well as how to deploy an application within TFS. (There's also a great talk from Scott Hanselman but he doesn't go into TFS).
You can use MSBUILD within TFS2010 to call through to MSDEPLOY to deploy your package to IIS. This is done by means of parameters to MSBUILD.
The talk explains some of the command line parameters such as :
/p:DeployOnBuild
/p:DeployTarget=MsDeployPublish
/p:CreatePackageOnPublish=True
/p:MSDeployPublishMethod=InProc
/p:MSDeployServiceURL=localhost
/p:DeployIISAppPath="Default Web Site"
But where is the documentation for this - I can't find any?
I've been spending all day trying to get this to work and can't quite get it right and keep ending up with various errors. If I run the package's cmd file it deploys perfectly. If I run WebDeploy through Visual Studio it also works perfectly.
But I want to get the whole deployment running through msbuild using these arguments and not a separate call to msdeploy or running the package .cmd file. How can I do this?
PS. Yes I do have the Web Deployment Agent Service running. I also have the management service running under IIS. I've tried using both.
Args I'm using :
/p:DeployOnBuild=True
/p:DeployTarget=MsDeployPublish
/p:Configuration=Release
/p:CreatePackageOnPublish=True
/p:DeployIisAppPath=staging.example.com
/p:MsDeployServiceUrl=https://staging.example.com:8172/msdeploy.axd
/p:AllowUntrustedCertificate=True
giving me :
C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v10.0\Web\Microsoft.Web.Publishing.targets (2660): VsMsdeploy failed.(Remote agent (URL https://staging.example.com:8172/msdeploy.axd?site=staging.example.com) could not be contacted. Make sure the remote agent service is installed and started on the target computer.) Error detail: Remote agent (URL https://staging.example.com:8172/msdeploy.axd?site=staging.example.com) could not be contacted. Make sure the remote agent service is installed and started on the target computer. An unsupported response was received. The response header 'MSDeploy.Response' was '' but 'v1' was expected. The remote server returned an error: (401) Unauthorized.
IIS7 + related answer ....
Ok - here's what I ended up doing. More or less, following the post by Simon Weaver in this thread/question.
But when it comes to the MSBuild settings .. most people here are using following setting: /p:MSDeployPublishMethod=RemoteAgent which is NOT RIGHT for IIS7. Using this setting means TFS tries to connect to the url: https://your-server-name/MSDEPLOYAGENTSERVICE But to access that url, the user to authenticate needs to be an Admin. Which is fraked. (And you need to have the Admin-override rule thingy ticked). This url is for IIS6 I think.
Here's the standard error message when you try to connect using RemoteAgent :-
Standard 401 Frak Off u suck RemoteAgent, error
C:\Program Files
(x86)\MSBuild\Microsoft\VisualStudio\v10.0\Web\Microsoft.Web.Publishing.targets
(3588): Web deployment task
failed.(Remote agent (URL
http://your-web-server/MSDEPLOYAGENTSERVICE)
could not be contacted. Make sure the
remote agent service is installed and
started on the target computer.) Make
sure the site name, user name, and
password are correct. If the issue is
not resolved, please contact your
local or server administrator. Error
details: Remote agent (URL
http://your-web-server/MSDEPLOYAGENTSERVICE)
could not be contacted. Make sure the
remote agent service is installed and
started on the target computer. An
unsupported response was received. The
response header 'MSDeploy.Response'
was 'V1' but 'v1' was expected. The
remote server returned an error: (401)
Unauthorized.
So .. you need to change your MSDeployPublishMethod to this:
/p:MSDeployPublishMethod=WMSVC
The WMSVC stands for Windows Manager Service. It's basically a newer wrapper over the Remote Agent but now allows us to correct provide a user name and password .. where the user does NOT have to be an admin! (joy!) So now you can correct set which users u want to have access to .. per WebSite ..
It also now tries to hit the the url: https://your-web-server:8172/MsDeploy.axd <-- which is EXACTLY what the Visual Studio 2010 Publish window does! (OMG -> PENNY DROPS!! BOOM!)
And here's my final MSBuild settings:
/p:DeployOnBuild=True
/p:DeployTarget=MSDeployPublish
/p:MSDeployPublishMethod=WMSVC
/p:MsDeployServiceUrl=your-server-name
/p:DeployIISAppPath=name-of-the-website-in-iis7
/p:username=AppianMedia\some-domain-user
/p:password=JonSkeet<3<3<3
/p:AllowUntrustedCertificate=True
Notice the username has the domain name in it? Ya need that, there. Also, in my picture, I've allowed our DOMAIN USERS access to the website for managament. As such, my new user account i added (TFSBuildService) has Membership to the Domain Users group ... so that's how it all works.
Now - if u've read all this, have a lolcat (cause they are SOOOOOOOO 2007)....
Here's the steps that finally worked for me.
I wanted to get the working with RemoteAgent, but couldn't get that working no matter what I tried.
You don't have to do exactly like this, but this is how I got it working
Configure WMSVC
Make sure the service is started
Configure an IIS user (click on the TOP MOST SERVERNAME in IIS) and go to 'IIS Manager Users'. I suggest making it different to your windows name.
Make sure the user account for WMSVC (LOCAL SERVICE for me) has write permissions to the IIS directory you're using
In my case I'm using an SSL certificate (even though it is hitting localhost).
Remember these are all arguments to MSBUILD added within the TFS Build definition
/p:DeployOnBuild=True
/p:DeployTarget=MSDeployPublish
/p:MSDeployPublishMethod=WMSVC
/p:MsDeployServiceUrl=https://staging.example.com:8172/msdeploy.axd
/p:username=sweaveriis
/p:password=abcd1234
/p:DeployIisAppPath=staging.example.com/virtual_directory_name
/p:AllowUntrustedCertificate=True
Note: staging.example.com is actually the local box with a hosts file entry pointing to 127.0.0.1. Localhost would probably work here too.
Useful articles:
Troubleshooting MSDeploy issues
More troubleshooting
Unfortunately there is not a lot of info on this at this time. I'll give you some hints at the end of this message though.
About your problem, I've seen this before when I was trying to deploy using MSDeploy and the account that I was running on didn't have the permissions to execute the deployment on the target machine. So you need to take a look at the account that your builds are running under, and see if this account has the rights to deploy to the target machine. If not then you have a few options; grant the build user the rights, or pass the username/password in.
If you want to pass the values in then you will have to define an item named MsDeployDestinationProviderSetting and its metadata will have to contain the necessary values.
So in your project file (or via properties passed in) define something like the following.
<PropertyGroup>
<UserName>USERNAME-HERE</UserName>
<Password>PASSWORD-HERE
</PropertyGroup>
About where can you find documentation, like I said before there is not much out there yet. But since the entire Web Publishing Pipeline is captured in MSBuild targets and tasks you can learn alot on your own if you are familiar with MSBuild. If you take a look at the .csproj(or .vbproj) files for web projects created with Visual Studio 2010 you'll notice a statement like the following:
<Import Project="$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v10.0\WebApplications\Microsoft.WebApplication.targets" />
This imports the file located at
%ProgramFiles(x86)%\MSBuild\Microsoft\VisualStudio\v10.0\WebApplications\Microsoft.WebApplication.targets, and this file in turn imports
%ProgramFiles(x86)%\MSBuild\Microsoft\VisualStudio\v10.0\Web\Microsoft.Web.Publishing.targets
So in order to learn this topic in detail right now you have to inspect those files and learn for yourself.
I'm going to be working on something that will be covering these technologies in detail, but it won't be out for quite a while, and I still have a lot to figure out myself about this stuff.
Can you try out the username/password deal and let me know if it worked for you?
I had a similar problem and the solution was to have the following parameter:
/p:MSDeployPublishMethod=RemoteAgent
Here are all of the parameters I used.
/p:DeployOnBuild=True /p:DeployTarget=MSDeployPublish /p:MSDeployPublishMethod=RemoteAgent /p:MsDeployServiceUrl=http://my-server-name /p:username=myusername /p:password=mypassword
NOTE: I'm not using DeployIisAppPath because I'm building a solution and trying to build three web applications at once. Also I think your MsDeployServiceUrl should be just http://staging.example.com
It appears that when using InProc (which may be the default) for the MSDeployPublishMethod MSBuild ignores MsDeployServiceUrl and always tries to deploy to the local server. I changed it to RemoteAgent and all three of my web applications deployed successfully. I did notice that the Package file is nolonger contained in the MyWebApplication_Package folder, but that isn't a big deal to me.
Note that you can also set DeployTarget=Package -- this will prepare the package but not deploy it right away. For more info see this blog post.
For me the problem was that Web Deployment Agent Service was not started.
A simple net start msdepsvc fixed it. You could also set startup mode to Automatic on this service.
The arguments I'm using are:
/p:DeployOnBuild=True
/p:DeployTarget=MsDeployPublish
/p:MSDeployPublishMethod=RemoteAgent
/p:MSDeployServiceUrl=stagingserver
/p:DeployIisAppPath=test.local
/p:UserName=
You only need to specify the server name, and not the full path (no http needed).
Note that UserName is left empty to work around a bug with NTLM authentication (this way it uses the credentials of the TFS build agent for the deployment). see the accepted answer here
Here's how I got it to work. This was with Webdeploy 2.0. I am deploying on the same domain from our build machine to a dev webserver machine windows server 2008 r2. The account I am using to deploy is a service account on the domain that has administrator permissions on both machines. My solution includes a couple of unit test projects, an mvc3 project, and a couple of libraries under the solution. If you don't install MVC3 on the server you are deploying to look at http://www.iwantmymvc.com/2011-03-23-bin-deploy-aspnet-mvc-3-visual-studio for guidance.
/p:DeployOnBuild=True /p:DeployTarget=MSDeployPublish /p:DeployIisAppPath="Default Web Site/YourpplicationNameHere" /p:MsDeployServiceUrl=https://devserver02:8172/msdeploy.axd /p:AllowUntrustedCertificate=True /p:UserName=yourDomain\buildaccount /p:Password=password
The item I struggled with at first were the quotes around "Default Web Site/YourpplicationNameHere" That gives the partial error:
MSBUILD : error MSB1008: Only one project can be specified.
This happens when there are no quotes around Default Web Site/YourApplicationNameHere
The next error I got was because of the wrong username and password in my credentials for deployment. It gave this error:
C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v10.0\Web\Microsoft.Web.Publishing.targets (3588): Web deployment task failed.(Remote agent (URL https://devserver02:8172/msdeploy.axd?site=Default Web Site) could not be contacted. Make sure the remote agent service is installed and started on the target computer.) Make sure the site name, user name, and password are correct. If the issue is not resolved, please contact your local or server administrator. Error details: Remote agent (URL https://devserver02:8172/msdeploy.axd?site=Default Web Site) could not be contacted. Make sure the remote agent service is installed and started on the target computer. An unsupported response was received. The response header 'MSDeploy.Response' was '' but 'v1' was expected. The remote server returned an error: (401) Unauthorized.
This was because the username and password I had in /p:UserName=/p:Password=did not include the domain for the user. Even though it the build was running under that user it would not deploy. So I hit the url directly https://devserver02:8172/msdeploy.axd in a browser to make sure it was operation and make sure the username and password worked. This is where I noticed I had to put in the domain/user to get it to work.
I hope this is OK to reply I figured some other poor soul with find these errors and this could help...
If you can deploy your applications with fileCopy, it is easy to customize the TFS workflow to do so.
I've used the CopyDirectory activity, with the help of these articles:
http://www.ewaldhofman.nl/post/2010/11/09/Part-14-Execute-a-PowerShell-script.aspx
and
http://geekswithblogs.net/jakob/archive/2010/09/01/tfs-team-build-2010-how-to-place-the-build-output.aspx
Very simple and straightforward.
I Configured the build service with a user account that has write privileges on the desired share.
Next, I created the CopyDirectory workflow step, configuring the source as BuildDetail.DropLocation + "_PublishedWebsites" and for the destination I created an argument, which I called "DeployPath", that can be filled in the build configuration.
Now I still have to implement a test to check if the build was successful before invoking the CopyDirectory activity. The articles I mentioned show how to do that. They also teach how to invoke a powershell script instead of CopyDirectory.