Svn Server For Mac
As Wishingline has slowly grown beyond just one person, the need to change workflows and improve our ability to communicate and collaborate with clients, peers and partners has prompted us to do things a bit differently than in the past. One of these things has been to set up our own internal server.
Yeah — we know is the new hawtness, but the tools available and integrating are few, and honestly, our own experience with it has not left us paricularly enamoured. In setting up a new Subversion server for us to use internally, secured on our network, but also accessible remotely, we started off with from back in 2007, a bit of help from, and our old friend.
We ran into a few problems along the way, and so in the hopes of saving others from running into the same issues, this entry will hopefully serve as a straightforward and complete guide to setting up a Subversion server using svn+ssh authentication on (Client and/or Server). Prerequisites In order to complete everything below on your own systems, you will need:. At least two Mac systems: one which will act as a central Subversion repository (server) another as a development workstation.
Mac OS X: Leopard 10.5.x (ideally 10.5.5). There’s a good chance that you’ll be able to follow this guide on Tiger as well, but YMMV. Xcode 3.0 or newer, included on the Leopard install DVD, included with the iPhone SDK and otherwise available free from the site. Apple Server Admin Tools 10.5, from Apple. A sufficient degree of comfort in working in the Terminal application. Administrative access. A few Notes Before we Start Nearly all the instructions to follow require extensive use of the Terminal application which can be found in the /Applications/Utilities folder on your Mac.
Each line in the code examples that follow should be entered into the Terminal and followed by the Return key. Setting Up Your Envrionment As with other Unix operating systems, uses the PATH environment variable to determine where to look for applications when working on the command line. It’s common to install custom builds of Unix software in /usr/local in order to avoid interfering with core system software. A big benefit being that you don’t have to worry about updates to inadvertently overwriting your custom software installs. To set your the PATH for your user account on your workstation, you will need to either create or edit a.bashlogin file which is commonly used to customize the default shell environment on a per-user basis. To open or create the file, in the Terminal, type: pico /.bashlogin If the file does not exist, the following needs to be added at the end of the file in order to set the necessary PATH variables so that you will be able to use the various applications without needing to specify the full path to them on your systems. Export PATH='/usr/local/aliasbin:/usr/local/bin:/usr/local/sbin:$PATH' The one oddball in the above PATH is the path to the aliasbin directory.
We’ll explain what that’s all about later on. Patience grasshopper! Save and close the file by typing Control-O and then Control-X. You’ll be returned to a new prompt in the Terminal. Close the window and open a new one to load your changes.
Xcode and Subversion When you install Xcode 3.0 or newer, a version of (at the time of this writing, version 1.4.4) is also installed. Although you could use this version and skip a few steps, this tutorial is based on using the latest and greatest. Step 1: Installing Subversion Prerequisites Before installing there are a number of prerequisites which can or should be installed depending on your specific needs. In this particular case, the only one necessary is zlib which is used to add compression support to. In order to keep things neat and tidy, source downloads can be saved to the Downloads folder in your home directory or wherever you prefer.
Installing zlib To download, compile and install zlib, type the following in the Terminal: cd /Downloads curl -O tar -zxf zlib-1.2.3.tar.gz cd zlib-1.2.3./configure -prefix=/usr/local make && sudo make install cd. Once you get to the sudo make install command, you should be prompted for your administrator password. Enter that when requested in order to complete the installation. Installing neon If you want or need WebDAV support in, you can also install the HTTP and WebDAV client library.
Is entirely optional, but if you want to install it, type the following in the Terminal: cd /Downloads curl -O tar -zxf neon-0.28.3.tar.gz cd neon-0.28.3./configure -prefix=/usr/local -enable-shared=yes -with-ssl=openssl -with-libxml2 make && sudo make install cd. At this point you should now have the two primary prerequisites installed, meaning you’re now ready to download, build and install Subversion itself. Step 2: Installing Subversion Compiling with all the necessary support libraries is straightforward. If you did not install as in the prerequisites above, be sure to omit that line in the configure command below. Cd /Downloads curl -O tar -zxf subversion-1.5.4.tar.gz cd subversion-1.5.4./configure -prefix=/usr/local -disable-mod-activation -with-apxs=/usr/sbin/apxs -with-ssl -with-zlib=/usr/local -with-neon=/usr/local -without-berkeley-db -without-sasl make && sudo make install cd. You should now have installed on your system(s) in /usr/local/. You can verify this by checking the version of one of the Subversion applications.
Namcos23 c download for mac windows 10. Downloading apps requires an Apple ID.
Type svn -version in the Terminal. In order to create a complete client-server configuration with remote repository access, you will need to complete Steps 1 and 2 on both Macs.
Svn Server For Windows
If you’ve got more than two Macs, repeat as necessary. Step 3: Workstation Public/Private Key Creation Public/private keys can be used to secure your network communications even more than relying on simple password authentication. In this particular case, these keys can be used to provide secure authentication to your repository.
To create a public/private keypair, in ther Terminal, type: cd mkdir /.ssh ssh-keygen -t rsa If you do not want to use a passphrase as an extra level of security, just press Enter when prompted. The ssh-keygen command will create two files in the.ssh directory, idarsa.pub and idarsa.
The first, with the.pub extension is your public key which you’ll need to copy to the Mac acting as the repository server into a file named authorizedkeys. The second is your private key. Do not share this with anyone. The private key will be unique to each system/user and identifies that particular Mac when authenticating to the server or to any other systems sharing the public key. Simply put, in order to authenticate successfully, you need both halves of the key. Step 4: Setup Users and Groups on the Server There’s a few different ways users and groups can be managed: the Accounts system preferences panel, the command line and the which can also be used on the consumer version of and not just the server edition.
Whether you’re setting up your server on or, using the Server Admin Tools makes things easy. Launch the Workgroup Manager application from the /Applications/Server folder and press the Cancel button when prompted to login to the server. Instead, select View Directories from the Server menu and click the lock icon on the Workgroup Manager window to authenticate yourself as an administrator. Create a Subversion Users Group on the Server Before users can be given access to the repository, users all need to belong to a common group which will have read/write permissions for the repository on the server. Creaing a new group in Workgroup Manager Click on the Groups tab to switch to the Groups view and then click the New Group button to create a new group.
Give the group a Name and Short Name and press Save. Click on the Members tab to add users to the group or switch to the Users tab and add users to the group from there. Depending on how many users you need to provide access to, one method might be faster than the other. Adding members to a group in Workgroup Manager Create User Accounts on the Server Unlike other authentication methods ( file://, svn://), accessing a repository via SSH requires that real user accounts exist on the server. In theory at least, these users should be able to access the server via SSH as any other user, though this can be restricted.
More on that later. Create any needed user accounts by clicking on the New User button in Workgroup Manager. Creating a new user account in Workgroup Manager Under the Basic tab, enter a Name, Short Name, Password, and set Administrator Access.
Under the Home tab, press the Add button and enter /Users/USERNAME in the Full Path field and press Ok. Save your changes and click the Create Home Now button. This should create a new user just as if you did so using the Accounts preference panel in System Preferences and also generate their home directory.
Setting a user’s home directory in Workgroup Manager To finish configuring access for each user to allow passwordless access using their individual public/private keypair, the user’s public key needs to be copied to an authorizedkeys file in a.ssh folder in their home directory on the server. Copy each user’s public key file to the server into their home directory. Exactly how you do this isn’t particularly important, but putting the key in the right place, named correctly and with the correct permissions is. Cd /USERNAME sudo cat idrsa.pub /USERNAME/.ssh/authorizedkeys sudo chown -R USERNAME /USERNAME.ssh sudo chmod 700 /USERNAME.ssh sudo chmod 600 /USERNAME.ssh/authorizedkeys The cat command will take the contents from a file named idrsa.pub and append it to the end of a file named authorizedkeys or create a new file if it doesn’t exist. Repeat for each user needing access the Subversion server and replace USERNAME with the appropriate value.
You can do this from a single administrative user account or by logging in as each individual user in sequence. If a user has more than one computer which may require access to the repository, you can include more than one public key in the authorizedkeys file; just ensure each is on it’s own line. Using the cat command above will do just that. Step 5: Secure SSHD on the Server Out of the box on, SSH is relatively secure, but there’s more we can do to improve it’s resiliance, particularly on the server side of things.
To enhance the security of the server, edit the /etc/sshdconfig file in the Terminal. Cd /etc cp sshdconfig sshdconfig.orig sudo pico sshdconfig Locate and edit the following list of configuration properties for the SSHD daemon process so they appear as shown below. Press Control-O, then Control-X to save the changes. Protocol 2 PermitRootLogin no PasswordAuthentication no X11Forwarding no UsePAM no UseDNS no AllowUsers list of users - see Step 4 The list of users to be allowed should be based on the user’s short name and separated by a space.
Note that you can skip changing the PasswordAuthentication setting if you may need to provide password access. Note: If you need to add a new user later, you will also need to add that user to the AllowUsers setting in the sshdconfig file and restart the SSH process on the server. Also, if you really want to secure things a bit more, change the default port to something other than 22. The catch is that you will have to include the custom port as a parameter when connecting via SSH. Step 6: Create Aliases of the Subversion Applications In case you were wondering this is where we get really nerdy. To allow more than one user commit access to the repository, when logging in via SSH, each authenticated user will run their own instance of the svnserve process on the server.
As such, the process needs to run with a specific umask in order to prevent permission problems. There’s two things we need to do in order to make this work:. Create a few simple shell scripts that run the appropriate svn application using the required umask. This should be done for svnadmin, svnlook and svnserve.
Svn Server For Windows 10
Set the necessary permissions on these scripts. The commands to do this are: sudo mkdir /usr/local/aliasbin sudo pico /usr/local/aliasbin/svnserve Then in the pico editor, type the following. Replace svnserve in the example with each of svnadmin, svnlook and svnserve. #!/bin/sh umask 002 /usr/local/bin/svnserve '$@' Press Control-O and then Control-X to save your changes, quit the editor and return to a new prompt. Finally, set the necessary ownership and permissions on the scripts.
Sudo chmod +x /usr/local/aliasbin/svn. sudo chown root /usr/local/aliasbin/svn. sudo chgrp wheel /usr/local/aliasbin/svn.
Step 7: Append the authorizedkeys File In order to ensure that the new svnserve alias is used when a user is interacting with the server, a special command must be prefixed before each public key listed in a user’s authorizedkeys file. Sudo USERNAME/.ssh/authorizedkeys Replace USERNAME above with the specific user’s shortname. Command='/usr/local/aliasbin/svnserve -t -tunnel-user=USERNAME -r /svn' ssh-dsa PUBLICKEY Replace USERNAME above with the specific user’s shortname and note that the command above should be added on a single line with no line breaks, including the entirety of the public key. The value of PUBLICKEY should be the existing public key.
Save the changes by pressing Control-O and then Control-X. Step 8: Create a Repository on the Server You’re most of the way there now You’re now finally ready to create a new repository and project to test things out. The basics of this are no different than if you were using basic file:// or svn:// methods to access the repository. Note that you shouldn’t need to specify /usr/local/aliasbin before the svnadmin command because you should have that included first in your PATH variable.
If you haven’t done that, go back to step one before proceeding any further.