Many harabrachiteli sometimes care about the issue of hosting SVN. The Internet is full of options for hosting the SVN repository, with a price of about 10-15 days a month, but one thing is confusing: hosting a repository is a much more important matter than hosting a site. In the code - your “overvalued ideas”, the uptime of the server and the reliability of backups directly affect the work of your business. Some people choose to host SVN in serious companies. A good comparison of the parameters here: http://www.svnhostingcomparison.com/ , open-source, by the way, can be done in a good place with the letter G ;-).

Others, like me, decide to host SVN on their VDS / Dedicated server. I will stop on this question, having told at the same time a little about options for starting / configuring svn server (including relatively new ones - encryption / authentication SASL and storage in FS). All this will come to you at $ 3-4 / month, in full control over backups and access to the server. Donate 30 minutes of precious time to set up.

Target audience: initial - the average level of experience with Linux.
Ps. I am aware that FreeBSD is not Linux ;-)

SVN server options

')
By server:

• Apache + SVN. While the most popular.
• svnserve The fastest, but you need a minimum VPS server.

By encryption:

• No encryption. Only in corporate networks.
• SSL: Encryption is already “the old fashioned way” - only in conjunction with Apache.
• SASL: A new way included in svnserve. To work, you need a client version 1.5.3 and higher. The last phrase is 4 hours of despair :-)

By authentication:

• A list of users with open passwords in passwd (the easiest way).
• Secure verification via SASL: DIGEST-MD5 (passwords are not open).
• Tunnel svn + ssh: users login under their Linux accounts.
• You can fasten any other methods, including the usual database.

Data storage:

• Berkley DB is an old (time-tested) and reliable way.
• FileSystem - new, you can do backups "on the fly"

For my server, I chose the option

• svnserve (for low memory consumption and speed)
• SASL (symmetric encryption that works at least somehow, from shit-certificate (self-signed) SSL sense 0, and people tend to accept any certificates).
• Checking passwords through SASL
• Storage on FileSystem
• It’s decided on FreeBSD firstvds.ru, 1 gigabyte of space, easy to expand, full control over backups and access, 64 meters of memory (looking ahead, I’ll say that only 6.5 are used, so it wouldn't work ;-)). This happiness costs 4u.e (3 with a 25% discount ;-)) per month). Wordlessly, you can choose any VDS here.

Configure the system

• We collect / set svnserve. You need to enable SASL support, everything else is not needed.
  

  cd / usr / ports / devel / subversion
  make install clean

  
  
• We create the user svn, and under it we continue to do everything. We cut down a remote login from him, well, or in extreme cases, we set a very complex password.
• Create a repository: svnadmin create ~ / name
• Go to ~ / name / conf, and write to svnserve.conf
  

  [general]
anon-access = none
auth-access = write
realm your_server_realm
[sasl]
use-sasl = true
min-encryption = 128
max-encryption = 256


  
  
  Pay attention to the end of the file - enabled encrypted password check (min-encryption> 0) and mandatory encryption of at least 128 bits. Above 128, my client (for now) does not hold :-)
• Next, add users to the SASL database:
  

  saslpasswd2 -c -f sasldb -u your_server_realm new_user_name

  
  We observe the created file sasldb.db and remember the path to it.
• Further the most difficult, the SASL setup. You need to know where the SASLs are. For example using locate libsasldb
  In the case of firstvds with FreeBSD, this is / usr / local / lib / sasl2
• Here we create the svn.conf file of the following type:
  

  pwcheck_method: auxprop
  auxprop_plugin: sasldb
  sasldb_path: / your_path_to / sasldb
  mech_list: DIGEST-MD5
  

  
  Please note that the .db extensions do not need to be written here.
• Modify startup script: (/ usr / local / etc / rc.d / svnserve)
  

  svnserve_flags = $ {svnserve_flags: - " -T -d --listen-port = 3690 --listen-host 0.0.0.0 "}
  svnserve_data = $ {svnserve_data: - "/ your_path_to_repository"}
  

  --listen-host 0.0.0.0 is needed because in FreeBsd, svnserve starts listening on the default IP6 and not the ancient IP4 :-)
  -T - use threads. -d - start by the daemon.
  Now we do svnserve start and you can see whether it worked or not :-)
  If svnserve is already running, launching an Apache can throw out the warnings, but everything works anyway :-)
• Configuring the script to autostart in ISPManager:
  Add a new service
  

  Name: SVN
  Mode: Standalone
  Process name: svnserve.bin
  Start command: /usr/local/etc/rc.d/svnserve start
  Stop command: /usr/local/etc/rc.d/svnserve start
  System name: svn
  Type: Unknown service
  Autostart: Yes
  Minotoring: No

• We remove all other services from autorun (you will arrive in Apache - ISPManager will become unavailable, you can start it again from the apachectl start or apache2ctl start console). At the same time, Apache and svnserve do not work.
• We restart VDS through VDSManager and if you did everything right, you can start working with your own SVN server. With active work, the load is almost not noticeable, everything is very fast.

Server load looks like this:

Backups

It makes sense either to order the “Daily Backups” service or to do it yourself in Crown and upload the backup repository to your other hosting or to your computer.

Conclusion

I hope my 8 hours spent on breaking the forehead about all the subtle pebbles along the way will help the habra people to gain valuable experience in administering the SVN server :-). Successful to you backups and commits without conflicts :-)

Ps. Any comments, mistakes? - I will be glad to hear :-)