Password-less SSH authentication

Assuming that you are managing a huge array of remote servers from multiple data centers and server collocated with different time zones. It would be a nightmare to remember how passwords are kept and updated.  There are custom based solutions to address these issues but if for example you don't have the luxury of creating such automation password vaults to remember these passwords instantly.  Then the next logical thing would be to employ password authentication, which will allow you to gain quick access to servers that needs your immediate investingation.  

Logging In Via SSH Without A Password

Quite often, you want to ssh into a remote server without having to enter a password. I use this mostly for scripts that I want to run non-interactively, like the rdiff-backup script I use for backing up my home computer to a remote server. SSH allows you to do this in a relatively secure way using public key authentication.
The first thing you’ll need is a working ssh server that you want to access, and an ssh client on the computer you want to access it from. ssh is such a common tool in linux, that the client should come pre-installed on your distribution. I’m assuming that you’re looking for answers on this topic because you already have an ssh server you want passwordless access to, so I’m not going to go into detail on setting up an ssh server – although I will cover setting up an existing ssh server for passwordless login.

setting up the server for passwordless login

You will need to make sure that the server will accept passwordless logins. This means you have to enable public key authentication on the server. To do this, open up /etc/ssh/sshd_config in a text editor (I would suggest nano or kate). Then make sure that the following two lines are uncommented, or if not there, add them in. To uncomment the line, remove the ‘#’ from the beginning of the line:

RSAAuthentication yes
PubkeyAuthentication yes

You will need to restart the ssh server. Do this with:

/etc/init.d/ssh restart

Finally make sure that permissions are right on the server. If there’s no ~/.ssh directory, make one:

mkdir ~/.ssh

Once you’ve got a ~/.ssh directory, change the permissions using:

chmod 700 ~/.ssh

that should be enough to setup the server side of things.

setting up the client side of the equation

First you’ll need to setup a keypair. If you already have the files ~/.ssh/id_rsa and ~/.ssh/id_rsa.pub, you should be good to go. If not, then you need to add them. Use the following command:

ssh-keygen -t rsa

You will then be asked some questions. Simply hit “Enter” to answer them all:

Generating public/private rsa key pair. 
Enter file in which to save the key (/home/skx/.ssh/id_rsa): 
Enter passphrase (empty for no passphrase): 
Enter same passphrase again:
Your identification has been saved in /home/skx/.ssh/id_rsa.
Your public key has been saved in /home/skx/.ssh/id_rsa.pub.

Answering without putting in a password means that the keys can be unlocked without a password, which is the whole point of “passwordless” login. Now we can do a little magic. Previously when setting up passwordless logins with ssh, I’ve gone through a dance of copying keys from the local computer to the remote computer. However, now I’ve found a new programme that does all this automagically. So, type this into a terminal:

ssh-copy-id -i ~/.ssh/id_rsa.pub username@remote_host

Obviously you will need to replace “username” with the user you want to login as on the remote computer, and “remote_host” with the ip/hostname of the ssh server. This command will ask you for a password – don’t be alarmed; this sets up the passwordless-ness, so needs a password to do it. Once you’ve done this, you should be good to go. Try logging into the remote server, and you should be password free.

Bash Internals a Researchers Eye View

title:Bash info, scripting examples, regex parameter substitution, interactive shell, and more
keywords:bash,shell,commmand,parameter,file,name,path,regular,expression,glob,login,mingetty,tty,console,terminal,screen,prompt,sudo,stdout,permission,permissions
description:Shell trivia and scripting examples including file name and path substitutions, as well as how to detect a live human logging in, and how to fix the session title and titlebar.


Table of contents
-----------------
Introduction
Link to list of hints
Disabling xon xoff and detecting interactive login
Regular expressions and globbing
Checking return status (return value) of programs
Can't write a file
Fixing the session title
Using dd and gmime-uuencode to create passwords
A little rant about examples



Introduction
------------

Shell programming and expecially shell variables are weird things. The
rules are bizarre to those of use schooled in normal programming
languages such as C, Perl, or Java. I'm not a shell programmer, but
after much painful, irritating, frustrating trial and error, (and
hours of Google searches) I've managed to glean a few really useful
facts. This document assumes that you are facile with the Linux shell
bash, and that you are comfortable with shell commands and with
viewing files, and comfortable viewing (and searching) man pages.

By the way, it appears that the man page for bash is missing most of
the available content. Heaven only knows why. For instance the man
page says "Expressions are composed of the primaries described above
under CONDITIONAL EXPRESSIONS." There is no heading "CONDITIONAL
EXPRESSIONS" in the man page.

I couldn't find the list of CONDITIONAL EXPRESSIONS via the "info
bash" command either. However, hope is not lost. Fedora (and probably
most distros of Linux) have full docs on the hard drive. Mine are at:

file:///usr/share/man/man1/bash.1.gz

Simply use your web browser to read the docs off your hard drive. For
Fedora these docs are mostly in HTML format. They also appear to be
complete.

You can always search Google, and many web sites will have the full
docs.

If you are frustrated with the shell, I feel your pain. Except for the
most trivial operations, I use Perl for all sysadmin scripting
tasks. (I don't want to start a religious war here: if you like shell
programming I'm happy for you. However, most of us will be more
productive in Perl.) Perl makes sense and has many examples and
encyclopedic documentation. For those times where Perl does't make
sense (which I will readily admit occur on a regular basis), check
Google or "man perltoc" for the Perl docs table of contents.

For examples of shell scripts, check out the scripts in /etc/init.d. 




Link to list of hints
---------------------

This information is implied by the bash man page (which is lacking
examples). There are also home nice hints at:

http://linuxgazette.net/issue18/bash.html





Disabling xon xoff and detecting interactive login
--------------------------------------------------

As of KDE4 (2008 and 2009) the terminal application konsole is
broken. It no longer accepts -ls. See my work around below.

Reading between the lines, the -ls may have been added by one of the
konsole developers, and then removed by another developer (who I
presume did not understand the implications).

http://www.linuxquestions.org/questions/slackware-14/kde-konsole-gone-after-installing-kde4-608652/

The work around is simple enough, and I hope you haven't wasted an
hour looking for the solution.

1) Run konsole

2) Settings menu -> Edit Current Profile... -> General tab -> Command:

3) Change to /bin/bash --login

This changes a KDE config file Shell (probably some where such as
/home/mst3k/.kde/share/apps/konsole/Shell.profile) that konsole uses
at startup. By invoking bash as --login, shopt login_shell will be
"on".

Now your .bashrc or whatever will be able to distinguish when a human
is logged in, and when a script is running. The reason for this would
be to disable xon/xoff flow control for the human.

From the bash prompt, "konsole -e /bin/bash --login" seems to work,
but gives an interesting KDE error:

[zeus ~]$ konsole -e /bin/bash --login
konsole(659): Attempt to use QAction "change-profile" with KXMLGUIFactory!
[zeus ~]$ Undecodable sequence: \001b(hex)[?1034h

Also "/bin/bash -i" does *not* create an interactive session. I'm
guessing this is due to shopt login_shell being somehow inherited by
child processes.

Note: This information has subtle inaccuracies in the distinction
between "interactive shells" and "login shells". I hope to clarify
this soon. The Bash documentation says there is a difference, but does
not get around to giving the reason(s) for the distinction.


This example shows the solution two problems: how to disable the very
irritating software flow control xon and xoff mapped to keys control-x
(C-x) and control-s (C-s). I'm an emacs user, and in emacs I use those
keys constantly. Bash is set up for emacs command line editing, so all
my emacs reactions get used on the command line too, but co-mingling
emacs with the semi-emacs keystroke support in bash can lead to
issues. The big one was accidentally stopping i/o by hitting the xoff
key. This key hasn't been needed since they days of dedicated CRT
terminals (without scroll back buffers). Heaven only knows why it is
still the bash default. I don't even use flow control on a runlevel 3
non-graphical console session.

Using shopt -q login_shell seems to be the modern and reliable way to
detect interactive shell sessions. When the session is interactive,
disable start and stop which are xon and xoff. 

******
Note: -ls only applies to older versions of konsole. See above.
******

There is a potential problem with this. The default state of terminal
(console) applications such as KDE's konsole is *not* as a login
shell. This seems like a bug. To cure this obscure issue launch
Konsole as:

konsole -ls

Change how Konsole is run in you start menu. Right click your start
button (Fedora button, KDE button, whatever you call it). Select "Menu
Editor". Click on one or more of the Terminal (konsole) entries, and
add " -ls" at the end of the "Command".


******
Note: -ls only applies to older versions of konsole. See above.
******

You can see the output of shopt in human readable form by leaving off
the -q option (-q for quiet):

shopt login_shell

or 

shopt

# The newer (?) method of detecting an interactive shell.
# This works with Fedora Core 6, and probably most modern versions of
# Linux. Disable xon xoff, and alias rm to rm -i
if shopt -q login_shell ; then
      stty stop undef
      stty start undef
     alias rm='rm -i'
fi


Below is another technique for testing to see if a login is an
interactive session. For reasons not quite clear, Apple's OSX has a 
problem setting and resetting the session name. It works under Linux,
but not with OSX, and I can't figure out why Linux works
seamlessly. In any case, I created a weak workaround for OSX.

The character strings being echoed are "escape sequences" for the
terminal program. This seems to be more or less the same between
xterm, "linux" (a terrible name for a tty since this is also the true
and real name of the operating system/kernel(?)), vt100, and mabe even
"ansi" (another terrible name for a tty).

# This works for OSX and should be fine for Linux too.
# if [ ! -z "$(echo $- | grep i)" ]

# Similar to the line above, but tests for 1 match instead of a
# non-zero length return string. The shell variable $- contains the
# values of the "set" command (which is different in Bash than in
# csh(?) or some other shells). Do this:

echo $-

The result in my shell is "himBH". The "i" undocumented, but means
that the shell is "interactive". The bash man page describes the other
options under the "set" section (try searching the man page for set
with multiple spaces in front "    set " or better yet forget man and
use browse the docs with Firefox from /usr/share/doc/ )

Bash's "if" command with [ ] checks the boolean result. The shopt
method is checking the command return value. Therefore using "echo"
piped to "grep" you must check against equivalence to 1.

I don't know why the command has to be surrounded by double quotes,
parentheses, and preceded by $. 

if [ "$(echo $- | grep -c i)" == 1 ]
then
    stty stop undef
    stty start undef
    alias rm='rm -i'

    # Don't echo except for a tty. Non-ttys (like scp) will break if
    # you echo text to them.
    # hostname -s
    # id -nu
    # echo -e -n  is bash specific (as opposed to a feature of /bin/echo)
    # http://www.mit.edu/afs/sipb/project/outland/doc/rxvt/html/refer.html#XTerm
    # 0 window title and icon name(?)
    # 1 icon name
    # 2 window title
    # 30 type-of(?), usually Shell
    #echo -ne "\033]1;one\007"
    #echo -ne "\033]2;two\007"
    echo -ne "\033]0;`id -nu`@`hostname -s`\007"
fi


# The following older code worked for a while, or at least in some cases.
# This checks to see if the session has a prompt string of non-zero
# length.
# http://www.faqs.org/docs/bashman/bashref_68.html
# Perhaps it stopped working when I made a small modification to my prompt.
# In any case, it is less robust than the method above.
# For interactive shells disable xon and xoff, and alias rm to rm -i
# Use the a modern test.

if [ ! -z "$PS1" ]
then
    stty stop undef
    stty start undef
    alias rm='rm -i'
fi

This older method didn't work when scp'ing into the machine.
I got the following result when using scp into the machine:

[mst3k@zeus ~]$ scp tmp.txt hera.example.com:
stty: standard input: Invalid argument
stty: standard input: Invalid argument
tmp.txt                                                       100% 1919     1.9KB/s   00:00
[mst3k@zeus ~]$ scp x_next.txt hera.example.com:







Regular expressions and globbing
--------------------------------

Globbing is use of * as a wildcard to glob file name list
together. Use of wildcards is not a regular expression.

These following examples should also work inside bash scripts. These may or may
not be compatible with sh. These are "interesting" regex or globbing
examples. I say "interesting" because they don't seem to follow the
path of "true" regular expressions used by Perl.

[mst3k@zeus ~]$ echo ${HOME/\/home\//}
mst3k
[mst3k@zeus ~]$ echo ${HOME##home}
/home/mst3k
[mst3k@zeus ~]$ echo ${HOME##/home}
/mst3k
[mst3k@zeus ~]$ echo ${HOME##/home/}
mst3k
[mst3k@zeus ~]$ echo ${HOME##*}

[mst3k@zeus ~]$ echo ${HOME##*/}
mst3k
[mst3k@zeus ~]$




Checking return status (return value) of programs
-------------------------------------------------

Linux and unix-like systems are not inclined to tell you the return
status of commands you run at the shell prompt. Use this little one
line shell if statement to check true/false return values.

[zeus ~]$ if  shopt -q login_shell; then echo "yes"; fi;
yes
[zeus ~]$ if !  shopt -q login_shell; then echo "yes"; fi;
[zeus ~]$   


Here is a better example, and includes a Perl script with different
exit values.

Create a Perl script try.pl just like my try.pl that I've cat'ed
below. Here is a session transcript that should be clear. Yes, the
Perl script is 6 lines. Yes, I strongly prefer my curly braces on
separate lines.

[zeus ~]$ cat try.pl
#!/usr/bin/perl
if ($ARGV[0])
{
    exit(0);
}
exit(1);
[zeus ~]$ if ./try.pl stuff ; then echo "yes"; else echo "no"; fi;
yes
[zeus ~]$ if ./try.pl ; then echo "yes"; else echo "no"; fi;
no
[zeus ~]$



Can't write a file
------------------

There are cases (especially with Apache and CGI scripts) where you (at
the shell command line) or one or your scripts is unable to write to a
file due to permissions. This will be true even when you sudo the
writing command. The short answer is: the shell permissions control
file writing, not the permissions of the command. We will use an
example of a user www (think: apache) trying to write to a file owned
by mst3k. In reality mst3k wrote the script but due to various
configuration issues, the CGI scripts are running as www.

Here is the solution (more explanation below). Add a tee command to
your sudoers file:

www  ALL=(ALL) NOPASSWD:  /usr/bin/tee

Or perhaps the more secure version:

www  ALL=(ALL) NOPASSWD:  /usr/bin/tee -a /var/log/text.txt

Use this command in your script:

/bin/echo "i like pie" | sudo /usr/bin/tee -a /var/log/test.txt >/dev/null


For instance you have a CGI script written in Perl, and www is in
sudoers for /bin/echo and the following does *not* work. I'll use a
Perl script, but it is probably true even at the bash prompt. Note:
adding /bin/echo to your sudoers doesn't solve the problem. You might
solve the problem by using another shell and su'ing or sudo'ing the
new shell.


#!/usr/bin/perl
`/bin/echo "i like pie" | sudo /usr/bin/tee -a /var/log/test.txt > /dev/null`;
my $id = `/usr/bin/id`;
print "Content-type: text/html\n\nScript runs as:
$id\n";
exit(0);



Keep in mind when trying to diagnose this problem that your script has
to run. The debugging processs has steps such as:

1) Does the command work at the bash command line for the owner of the
   directory/file?

2) Does the command work at the bash command line for non-owners in sudoers?

3) Did the CGI script run? CGI scripts can silently fail. There won't
   be any http output, but you'll get no errors in your web browser
   (unless you've got CGI::Carp enabled). There will be messages in
   the Apache logs. Apache won't run scripts with group-write or
   other-write privs, directories with group-write or other-write
   privs, or that aren't owned by the directory owner
   (/home/mst3k/public_html has to be owned by mst3k) and won't run
   scripts that have no AddHandler or if ExecCGI is not enabled. There
   are details about this elsewhere in these readme and mini howto
   documents, but your .htaccess should include:

Options +ExecCGI
AddHandler cgi-script .pl


Fixing the session title
------------------------

Most xterm software will put a session title in the window
titlebar. The bash shell has an environment variable PROMPT_COMMAND
that is run every time the prompt is printed. This env var is missing
on Apple Mac OSX, but you can easily add it to your .bashrc on any
system.

Briefly, the format is:

export PROMPT_COMMAND='echo -ne "\033]0;title; echo -ne "\007"'

Usually, we want this to be the userid, hostname, and current directory (pwd
is "print working directory").

export PROMPT_COMMAND='echo -ne "\033]0;${USER}@${HOSTNAME%%.*}:${PWD/#$HOME/~}"; echo -ne "\007"'

Put the line above into your .bashrc file. You can test this two ways:

1) "source" .bashrc by typing ". .bashrc"
2) enter the export command at the bash prompt

This is how the prompt changes correctly when you log off a host. This
might also be called fixing the prompt, fixing the titlebar, title
bar, session name, xterm session name, konsole session name, change
session name, change title bar, change session when logging off,
logoff session change, terminal session name change, titlebar tweaks,
escape sequence to change titlebar, vt100 sequence, vt102 sequences. 

Related information is:shell variables, environment variables, env,
set, bash, .bashrc, bashrc, .bash_profile.

Not related to this (at least not directly related) is
.bash_logout. There is no magic at logout that "resets" the prompt or
title bar. Each shell knows what its prompt and title bar should be,
and the prompt and titlebar commands are run every time bash prints
the prompt. However you *must* have the shell variable PROMPT_COMMAND
set and this is one of many fundamental features that OSX fails to set.

Note that the env command doesn't show PROMPT_COMMAND. This is because
PROMPT_COMMAND is a variable. You can only see PROMPT_COMMAND's value
with the "set" command or with "echo $PROMPT_COMMAND". 

In fact, if you really want to know all about your environment (in the
general sense of the word) you need two commands, and I like to have
the env vars sorted (set automatically sorts):

env | sort
set

When I export PROMPT_COMMAND is it both an env var and a set var. I'm
missing the distinction between the two kinds of variables. 



Using dd and gmime-uuencode to create passwords
-----------------------------------------------

Use /dev/urandom instead of /dev/random. Urandom gives better data and
works better with dd.

if=file  is read from file instead of rading from stdin

ibs=n  is read n bytes at a time

count=n   is copy n input blocks

Getting the random input is easy, however, it is binary. We need to
convert to normal printing characters to produce a random string
useful as a password. Encoding as uuencode or base64 handles this
problem. 

dd if=/dev/urandom ibs=6 count=1 | base64

dd if=/dev/urandom ibs=6 count=1 | gmime-uuencode -m -




A little rant about examples
----------------------------

Authors of documentation, need to include a large number of examples.
If you love your operating system then please include examples. The
operating system with the most documentation examples will win the
war.

VMware Server for Performance

In this excellent post done by Devon Kerr's project site.  I am going to lay down a key foundation in furthering your understanding on making VMware work as you expect.  Kerr has done excellent point-by-point argument in discussing the cold essences of virtualization thru some tweaks.

Tweaking VMWare server for performance

This is less of a how-to than a series of guidelines to help optimize the IO performance of your VMWare server.  I’ve installed VMWare server on a number of the Linux distros and currently have VMWare servers running Debain 4, Fedora 9 and CentOS 5.  I would choose your distribution based more on your familiarity and advanced operating features.  If you do some reading you’ll find that many people are taking sides on a number of issues in the area of virtualization and one of the important areas of debate is footprint size.
Having done full OS installs and tiny footprint installs (less than 100 megs) I can say with confidence that the size of the footprint is irrelevant and doesn’t really impact performance.  However, a couple other things do:
Guests and Partitions:   there are 2 ways of setting up VMWare guests – you can pre-allocate disk space which is commonly referred to as the software solution, or you can allow VMWare to use direct disk access for these guests which is commonly referred to as the hardware solution.  Technically the hardware solution can utilize the disks faster, but I’ve personally found that using the software solution is more modular and makes it easier to move around guests OSs and modify the guest settings, themselves.Memory Subsystem and timing: there exists alot of information about host/guest timing issues and there are a couple things you can do to reduce the likelihood that they will plague you.  First tune some parameters in /etc/vmware/config and add the following:
host.cpukHz =XXXX
If your CPU was 3.04 GHz this would read:
host.cpukHz=3040000
where xxxx is the raw value of a single CPU in kHz this will trickle to your guests, but if vmware server is “guessing” you can run into timing problems.  Note that it is a conversion from GHz to kHz and not MHz.  The values below enable a system that tries to correct guest machines when the timestamp counter is very low
host.noTSC = TRUE
ptsc.noTSC = TRUE
Next, you’ll want to modify /etc/sysctl.conf to improve performance of VMWare server.  This helps overall performance in case physical memory is exhausted and swap needs to be used
vm.swappiness = 0
vm.overcommit_memory = 1
these settings tune how VM guest commits I/O to disk
vm.dirty_background_ratio = 5
vm.dirty_ratio = 10
vm.dirty_expire_centisecs = 1000
This sets how fast a VM guest can set it’s tick count to – the default for various Linuxdistros vary
dev.rtc.max-user-freq = 1024
Disks, Disks, Disks: I always attempt to put my guest OSs on their own partition and I format that partition thusly because VMWare server reads guests in huge blocks (/dev/sdb1 is the partition my guests reside on):
mke2fs -b 4096 -R stride=8 /dev/sdb1
Then I set the block readahead value to somewhere around 16384, but you can go as high as twice that value (in my case this is an entire disk array, so I dropped the partition indicator):
blockdev –setra 16384 /dev/sdb
There are other ways of optimizing performance but I’ve found that they take alot of time without providing much noticeable gain – my first VMWare server is still running without any of the tweaks I’ve described above and, given the hardware differences, it’s still about 25% more efficient to do things as I’ve described above.  Of course, these settings can be very different than those examples above depending on your hardware.
Also, I use the following formula to determine the total number of guests I’m going to host on a physical machine:
# of Guests = ((Total RAM + Swap)/Memory allocated per Guest on average)
so, if I had 4 gigs of ram and 8 gigs of swap, but wanted each guest to have 2 gigs of memory available for use I would have X number of VMs running simultaneously:
X = ((4+8)/2)
X = 6

Of course, I am assuming that you made a backup of your sysctl.conf before issuing the command sysctl -p

Installing Subversion on CentOS

Subversion is a wonderful tool for managing your projects and therefore a must have for any systems administrator for creating backups which allows you to spot changes on those backups you have.  In this post I am again taking the example from one excellent material which highlights the basics of SVN installation on one of the most widely used distributions of linux "CentOS".

Subversion on CentOS

Subversion isn't just for coders and programmers...I know because I'm not one. I've begun to use it lately for many things, such as, backing up Nagios configurations, documents, and pretty much anything text based. I don't know why I didn't start using it sooner, but none the less, here I am. This document quickly explains how to install, configure, and use subversion locally, as well as across Apache on a network. For complete and complex configurations and installations seek the documentation provided. There is plenty of well written documentation on the subject, that far exceeds my knowlegde of the tool. This just helps get you started quickly, for those like me that just like to jump in head first into new things.

Contents

1. System
2. References
3. Installation
4. Configurations
5. Using Subversion
6. Access control lists
7. Afterthought
8. Further reading

1. System

CentOS 4.x/RHEL 4
CentOS 5.1/RHEL 5

2. References

Subversion: http://subversion.tigris.org/
Version Control with Subversion: http://svnbook.red-bean.com/

3. Installation

[root@praetorian ~]# yum install mod_dav_svn subversion

The first thing to do is to install the packages I mentioned above. If you don't have Apache installed already, it'll go ahead and drag that down as well.

When you install from yum, there's a longer list than the two packages above that will automatically resolve themselves. Some other things will be installed automatically. Depending on your packages, your mileage may vary.

4. Configurations

4.1. Apache

Before you delve into the deep end, you need to ensure Apache is set up first. I'm assuming this is a virgin installation, so if you already have Apache things going...be careful what you change. I'm also going to explain setting this up with basic password protection. You can easily let this out, however, if you want to allow access to the repos from everyone.

First thing is make sure you open up /etc/httpd/conf/httpd.conf and at least change the ServerName directive. If you need more help or more complex configurations, then consult the Apache docs please.

[root@praetorian ~] vim /etc/httpd/conf/httpd.conf -- Edit what you need and save the file
[root@praetorian ~] service httpd start
[root@praetorian ~] chkconfig httpd on

Browse to your machine on the network and see if you get your test page, which you should: http://yourmachine. Working? Great, let's move along to more fun things.

4.2. Subversion's Apache configs

The next step is to setup some settings within Apache so Subversion and Apache play nice together. Get yourself to the example configuration file Subversion installed for you.

[root@praetorian ~] cd /etc/httpd/conf.d/
[root@praetorian ~] vim subversion.conf

# Make sure you uncomment the following if they are commented out
LoadModule dav_svn_module     modules/mod_dav_svn.so
LoadModule authz_svn_module   modules/mod_authz_svn.so

# Add the following to allow a basic authentication and point Apache to where the actual
# repository resides.
<Location /repos>
        DAV svn
        SVNPath /var/www/svn/repos
        AuthType Basic
        AuthName "Subversion repos"
        AuthUserFile /etc/svn-auth-conf
        Require valid-user
</Location>

The location is what Apache will pass in the URL bar. For instance: http://yourmachine/repos points to the SVNPath that you have specified. My examples are just that, so feel free to put things where you want. Make sure you save the file when you are finished editing.

Next we have to actually create the password file that you specified in the previous step. Initially you'll use the -cm arguments. This creates the file and also encrypts the password with MD5. If you need to add users make sure you simply use the -m flag, and not the -c after the initial creation.

[root@praetorian ~] htpasswd -cm /etc/svn-auth-conf yourusername
New password:
Re-type new password:
Adding password for user yourusername
[root@praetorian ~] htpasswd -m /etc/svn-auth-conf anotherusername
New password:
Re-type new password:
Adding password for user anotherusername

4.3. Configure your repository

The next thing you need to do is to create the actual repository from which you will check in and out your files. This is simple to do with some of the included svn tools.

[root@praetorian ~] cd /var/www/ -- Or wherever you placed your path above
[root@praetorian ~] mkdir svn
[root@praetorian ~] cd svn
[root@praetorian ~] svnadmin create repos
[root@praetorian ~] chown -R apache.apache repos
[root@praetorian ~] service httpd restart

Go test out whether or not you can access your repository from a web browser: http://yourmachine/repos. You should get a popup box asking for a username and password. If so, type in your credentials and you should be displayed with a Revision 0:/ page. If so, that's it for setting up a repo. If you want multiple repos, check out the docs from the links provides above. This sets up one repository and shows you how to start using them. Speaking of, let's move on to just that.

5. Using Subversion

5.1. Layout Your Repo

If all went well above, you're now ready to start using the repository that you created. Subversions svn tool is the command line client that you will use to talk to the database. To see the use of the tool:

[root@praetorian ~] svn --help

The most common arguments you will most likely be using are: svn import, svn commit (ci), and svn checkout (co). With these you will initially import files into your repository with import, you'll check them out to work on them with checkout, and you'll commit the changes back into the database with commit. It's pretty simple once you see them in use a few times.

Before I continue I'd like to explain about directory structure layouts. Almost all of the documentation talks about creating a certain layout for your directories. They specifically mention about making sure you have a branches, tags, and trunk underneath the root directory structure, where trunk holds all your files. For instance:

.
|-- project1
|   |-- branches
|   |-- tags
|   `-- trunk
`-- project2
    |-- branches
    |-- tags
    `-- trunk

The book explains why in a bit more detail, and I mainly don't bother using this type of layout...because I'm not doing coding and maintaining "projects" per se. I'm mainly using it to store configuration files, and text items that aren't as complex. Set things up for whatever works for you.

As an example, I'm going to just create some dummy directories and throw some files in them. This is from the actual SVN server. Play along.

[root@praetorian ~] cd /tmp
[root@praetorian ~] mkdir mytestproj
[root@praetorian ~] cd mytestproj
[root@praetorian ~] mkdir configurations options main
[root@praetorian ~] vim configurations/testconf1.cfg -- Add whatever you want to these files.
[root@praetorian ~] vim options/testopts1.cfg
[root@praetorian ~] vim main/mainfile1.cfg

Keep in mind that you can layout anything anyway you'd like. Once you have the initial layout of what you want, let's go ahead and import this up to Subversion.

5.2. Importing

[root@praetorian ~] svn import /tmp/mytestproj/ file:///var/www/svn/repos/mytestproj -m "Initial repository layout for mytestproj"
Adding         /tmp/mytestproj/main
Adding         /tmp/mytestproj/main/mainfile1.cfg
Adding         /tmp/mytestproj/configurations
Adding         /tmp/mytestproj/configurations/testconf1.cfg
Adding         /tmp/mytestproj/options
Adding         /tmp/mytestproj/options/testopts1.cfg

5.3. Checking Out

Now, just to check it out across the web browser: http://yourmachine/repos. You'll get whatever you have imported showing up to peruse. Once you upload your original layout from the local SVN server, you're now free to use it remotely on another machine. As long as you are connecting to the Subversion server with the user account(s) that you created earlier. Let's give it a shot.

[me@mylappy ~] cd /tmp
[me@mylappy ~] svn co http://yoursvnserver/repos/mytestproj
Authentication realm: <http://yoursvnserver:80> Subversion repos
Password for 'youruser':
A    mytestproj/main
A    mytestproj/main/mainfile1.cfg
A    mytestproj/configurations
A    mytestproj/configurations/testconf1.cfg
A    mytestproj/options
A    mytestproj/options/testopts1.cfg
Checked out revision 1.

5.4. Edit & Commit

As you can see, you've checked out revision 1 from the Subversion server. Now you can edit some things and commit the changes back to the Subversion server.

[me@mylappy ~] cd mytestproj
[me@mylappy ~] vim configurations/testconf1.cfg -- Add or delete something and save.
[me@mylappy ~] svn commit -m "Added a line to testconf1.cfg."
Sending        configurations/testconf1.cfg
Transmitting file data .
Committed revision 2.

The nice thing about this then, is that you can delete all of the directories that you just checked out on your machine. The only reason you checked them out, was to edit them, and then send them back up the line. Web browse to your server to check out the different files.

5.5. Adding/Deleting Items

Now this is all fine and dandy, but how do you add more files to an already existing repo directory? Easy, with the add argument. Go ahead and checkout your latest and greatest, copy a file over to a directory, add, then commit the changes.

[me@mylappy ~] svn co http://yoursvnserver/repos/mytestproj
A    mytestproj/main
A    mytestproj/main/mainfile1.cfg
A    mytestproj/configurations
A    mytestproj/configurations/testconf1.cfg
A    mytestproj/options
A    mytestproj/options/testopts1.cfg
Checked out revision 2.

[me@mylappy ~] cd mytestproj
[me@mylappy ~] cp /etc/yum.repos.d/CentOS-Base.repo configurations/
[me@mylappy ~] svn add configurations/CentOS-Base.repo
A         configurations/CentOS-Base.repo

[me@mylappy ~] svn commit -m "Added the CentOS Yum repo file."
Adding         configurations/CentOS-Base.repo
Transmitting file data .
Committed revision 3.

To delete items simply use delete instead of add. Commit your changes back up, and you're good to go. It's as simple as that. Go back over to your web browser again and you'll notice the revision number should say 3. You'll be able to click through the files to pick our your differences as well.

5.6. Reverting Back

Ok, this is all great but how do I revert back to an older revision...isn't this the point of Subversion? Yep, it's easy. If you're not sure as to what revision you're at...check out the log command. This is why you put a message in every commit. Short and to the point, but enough information to ring a bell that you perhaps forgot about.

[me@mylappy ~] svn log http://yoursvnserver/repos -- For the entire repository
[me@mylappy ~] svn log http://yoursvnserver/repos/mytestproj -- For the specific project

You'll get a nice complete list of revision numbers along with the comments, like I mentioned above. This allows you to pick which revision you want to check back out now.

[me@mylappy ~] svn co -r 1 http://yoursvnserver/repos/mytestproj

This command will drag down revision number 1.

6. Access control lists

Usually, you don't want to give every user access to every repository. You can restrict repository access per user by using ACLs. ACLs can be enabled with the AuthzSVNAccessFile file option, which takes a file name as its parameter. For instance:

AuthzSVNAccessFile /etc/svn-acl-conf

You can add this to the relevant Location section:

        DAV svn
        SVNParentPath /var/www/svn/repos
        AuthzSVNAccessFile /etc/svn-acl-conf
        AuthType Basic
        AuthName "Subversion repos"
        AuthUserFile /etc/svn-auth-conf
        Require valid-user

You can then create /etc/svn-acl-conf. This file consist of sections of the following form:

[reponame:repopath]
user = access

Where access can be r (read), rw (read-write), or empty (no access at all). The default ACL is to give users no access to a repository. Suppose that there is a repository named framework to which you would like to give john read access, and joe read and write access. You could then add the following section:

[framework:/]
john =  r
joe = rw

It is also possible to create groups in a section named groups, groups are then prefixed with the 'at' sign (@) in the access control lists. For instance:

[groups]
staff = joe, george

[framework:/]
john =  r
@staff = rw

If you would like to make all repositories readable to all users, you can add a section for the root directory of every repository:

[/]
* = r

7. Afterthought

This is only a very very small part of the power of what Subversion can offer you. This quick guide will get you going, and show you how to use it a bit to understand how it's working. You can do all kinds of things with the Subversion tools, so make sure you check the docs out to learn about different options that might assist you in your tasks. Also remember that the Apache installation might be overkill for your needs. You can completely use the Subversion tools locally on a machine by specifying file:///path/to/repo, instead of my examples across Apache as http://yoursvnserver/repos/whatever. From what I read, many folks use it on their local boxes just to keep their minds straight for huge projects and configurations file. Good luck

8. Further reading

Version Control with Subversion