Here's what we use(Score:5, Informative)
by MagicMike (7992) on Wednesday March 15, @01:14PM (#14925846) (https://secure.eff.o...?pagename=DON_splash)
We're a small consulting shop, and the guys that do the in-house IT are expected to be full-time billable.
Issue tracking
JIRA (from Atlassian.com). Bugzilla could work though
Documentation
Confluence (also from Atlassian). Any Wiki could work.
Communication
Mailman - we have one operator mailing list, root mail all goes there and we have discussions there
Config Control
CVS - If you alter it from the stock install, it should be in CVS. Subversion would work. Use "activitymail" to send CVS commit messages with diffs to your operator mailing list. Now if a machine dies, you don't care
Monitoring
Nagios and MRTG - If I expect a computer to be providing a service, everything that I can obvserve about that service will be monitored so we can detect failures quickly and fix them, and see patterns over time. Nagios sends alerts to the operator mailing list. MRTG is used to see how bandwidth is trending.
Updates
Yum - we have our own yum repository, with our own packages in there. If I am using something on more than two servers, I package it up for easier maintenance
VPN links
PPP over SSH - nothing fancy, but it works.
Backups
rsync - we have a cascading backup where cron dumps data on a machine, then rsync carries it to a central machine, then that machine rsyncs over a VPN link to an off-site machine
Secret storage
GPG - we keep passwords in GPG-encrypted files. If you need them, I encrypt it with your public key, and you can see them.
Authn/Authz
LDAP - we use pam-ldap for access control everywhere, and mod_auth_ldap on the web stuff. It's not SSO, but it is single-password. That's key
The combination of these things keeps everything in line. In particular, I'll point out that each part works together in such a way that there is only one place to check documentation (the wiki), one place to check for a work queue (the issue tracker) and one place to check for state information and discussion (the mailing list). That makes it easy to deal with, easy to delegate etc.
Also, you'll note that on a day-to-day basis, unless something breaks, there is no work required. That's huge. If the status quo requires any work at all, you'll eventually hit a scaling limit. The only thing that should require work is either a migration, an upgrade, or an expansion. And of those, upgrades should be easy to (nagios, yum and version control help there)

Hello,


I'm Alex Le at Kwizzical.com! We are a start-up company on Streaming Media based in Chicago. We have started the project since 2003 but as both of us were (and still) in school so it took 2 years for us to actually arrive at this point after quite a bit of sever-move-around. Before, I decided to host the site using 1and1. This company is huge, but the don't have much options in terms of flexibility. Their database size is merely 100Mb, so we decided to move our site to Steadfastnetwork.com. Currently, kwizzical.com is hosted on a VPS with roughly 512 Mg of RAM and a decent amount of bandwidth.


On 1and1.com server, I setup a CVS repository and was able to work and sync my code from home and at the office. As we move to our own VPS, we have the root permission to install any software we want (eh ... dedicated counterstrike server anyone?) so I decided to install SVN to it even though the CVS is pre-installed. The VPS is running CentOS 4.2 and so I logged in as root user ...



First of all, I wasn't so sure about installing stuff in Linux (I'm very much a windows guy), so I googled around and found this terrific guide written by Jim O’Halloran. What I did was to follow the instruction there. The basic steps are

1. Logging in as root user. Installing Subversion to CentOS using yum
   

   $yum install subversion mod_dav_svn

   
   


2. Create the repository folder.
   

   $cd /home/kwizzica
   
   $mkdir svnrepo

   
   


3. Setting up the apache's httpd.conf file
   
   

   $cd /etc/httpd/conf
   
   $vi httpd.conf
   
   
   
   Adding this to the end of the httpd.cong file
   
   
   

   <location /subvn>
         DAV svn
         SVNPath /home/kwizzica/svnrepo
         AuthType Basic
         AuthName "Kwizzical Subversion"
         AuthUserFile /etc/svn-auth-file
         Require valid-user
   </location>

   
   

   
   Create user account for Subversion and restart Apache to make the changes in the httpd.conf file effective. By setting the user and password, with the "Require valid-user" directive above, our repository is safe from unwanted visitor. In order to view or access to the repository, the user has to authenticated her/himself. So you can create as many users as your heart desires.
   
   

   
   

   $htpasswd -c /etc/svn-auth-file user_name
   (it will ask for the password here)
   $service httpd restart

   
   

   
   


4. Create the corresponding repository for subversion as specified above in the SVNPath directive in the httpd.conf. After this, change the owner of the repository from root to apache:apache to allow the corrrect permission
   

   $cd /home/kwizzica/svnrepo
   
   $svnadmin create .
   
   $chown -R apache:apache *

   
   


5. At this point, if there is no problem (I hope), we can access the repository via http://kwizzical.com/svn/. It actually took me quite a bit of work to figure out why things didn't work ( I had some problems configuring the httpd.conf file). I guess it's a trial-and-error process.
   
   


6. To create a multiple-project repository, we can use TortoiseSVN to do so instead of typing commands. TortoiseSVN is available for downloading here. After installing TortoiseSVN, we create a new folder somewhere, let's called it ... test
   
   
   


7. Create a local repository in the folder test
   
   With "test

" is the current folder, Right click, select TortoiseSVN > Create Repository Here.

8. Import the local repository (or project) to the main SVN repository
   
   With test is still the current folder, Right click, select TortoiseSVN > Export.
   
   Enter the URL of our repository, which is http://kwizzical.com/svn/, hit enter. That's it!

I hope this will help someone to setup and configure Subversion on their CentOS server, or at least I can look this up when I have to reinstall Subversion again.


Cheers!


Alex.