Ubuntuland

Ubuntu Server Guide, Part 3

You can use the CVSROOT environment variable to store the CVS root directory. Once you export the CVSROOT environment variable, you can avoid using -d option to above cvs command.

The string new_project is a vendor tag, and start is a release tag. They serve no purpose in this context, but since CVS requires them, they must be present.

When you add a new project, the CVS user you use must have write access to the CVS repository (/var/lib/cvs). By default, the src group has write access to the CVS repository. So, you can add the user to this group, and he can then add and manage projects in the CVS repository.

References
Subversion Home Page [http://subversion.tigris.org/]
Subversion Book [http://svnbook.red-bean.com/]
CVS Manual [http://ximbiot.com/cvs/manual/cvs-1.11.21/cvs_toc.html]

13. Databases
Ubuntu provides two Database servers. They are:
• MySQL™
• PostgreSQL
They are available in the main repository. This section explains how to install and
configure these database servers.

13.1. MySQL

MySQL is a fast, multi-threaded, multi-user, and robust SQL database server. It is
intended for mission-critical, heavy-load production systems as well as for embedding into
mass-deployed software.
13.1.1. Installation
To install MySQL, run the following command from a terminal prompt:

sudo apt-get install mysql-server mysql-client

Once the installation is complete, the MySQL server should be started automatically. You can run the following command from a terminal prompt to check whether the MySQL server is running:

sudo netstat -tap | grep mysql

When you run this command, you should see the following line or something similar:
tcp 0 0 localhost.localdomain:mysql *:* LISTEN -

If the server is not running correctly, you can type the following command to start it:

sudo /etc/init.d/mysql restart

13.1.2. Configuration

By default, the administrator password is not set. Once you install MySQL, the first
thing you must do is to configure the MySQL administrator password. To do this, run the following commands:
sudo mysqladmin -u root password newrootsqlpassword
sudo mysqladmin -u root -h localhost password newrootsqlpassword

You can edit the /etc/mysql/my.cnf file to configure the basic settings -- log file, port number, etc. Refer to /etc/mysql/my.cnf file for more details.

13.2. PostgreSQL

PostgreSQL is an object-relational database system that has the features of traditional commercial database systems with enhancements to be found in next-generation DBMS systems.

13.2.1. Installation

To install PostgreSQL, run the following command in the command prompt:

sudo apt-get install postgresql

Once the installation is complete, you should configure the PostgreSQL server based on your needs, although the default configuration is viable.

13.2.2. Configuration

By default, connection via TCP/IP is disabled. PostgreSQL supports multiple client authentication methods. By default, IDENT authentication method is used. Please refer the PostgreSQL Administrator's Guide [http://www.postgresql.org/docs/8.1/static/admin.html].
The following discussion assumes that you wish to enable TCP/IP connections and use the MD5 method for client authentication. PostgreSQL configuration files are stored in the /etc/postgresql//main directory. For example, if you install PostgreSQL 7.4, the configuration files are stored in the /etc/postgresql/7.4/main directory.

To configure ident authentication, add entries to the /etc/postgresql/7.4/main/pg_ident.conf file.
To enable TCP/IP connections, edit the file /etc/postgresql/7.4/main/postgresql.conf
Locate the line #tcpip_socket = false and change it to tcpip_socket = true. You may also edit all other parameters, if you know what you are doing! For details, refer to the configuration file or to the PostgreSQL documentation.
By default, the user credentials are not set for MD5 client authentication. So, first it is necessary to configure the PostgreSQL server to use trust client authentication, connect to the database, configure the password, and revert the configuration back to use MD5 client authentication. To enable trust client authentication, edit the file /etc/postgresql/7.4/main/pg_hba.conf

Comment out all the existing lines which use ident and MD5 client authentication and add
the following line:
local all postgres trust sameuser
Then, run the following command to start the PostgreSQL server:

sudo /etc/init.d/postgresql start

Once the PostgreSQL server is successfully started, run the following command at a
terminal prompt to connect to the default PostgreSQL template database

psql -U postgres -d template1

The above command connects to PostgreSQL database template1 as user postgres.
Once you connect to the PostgreSQL server, you will be at a SQL prompt. You can run
the following SQL command at the psql prompt to configure the password for the user
postgres.

template1=# ALTER USER postgres with encrypted password 'your_password';

After configuring the password, edit the file /etc/postgresql/7.4/main/pg_hba.conf to
use MD5 authentication:
Comment the recently added trust line and add the following line:
local all postgres md5 sameuser
The above configuration is not complete by any means.
Please refer the PostgreSQL Administrator's Guide
[http://www.postgresql.org/docs/8.1/static/admin.html] to configure more
parameters.

 

 

14. Email Services

The process of getting an email from one person to another over a network or the Internet involves many systems working together. Each of these systems must be correctly configured for the process to work. The sender uses a Mail User Agent (MUA), or email client, to send the message through one or more Mail transfer Agents (MTA), the last of which will hand it off to a Mail Delivery Agent (MDA) for delivery to the recipient's mailbox, from which it will be retrieved by the recipient's email client, usually via a POP3 or IMAP server.

14.1. Postfix

Postfix is the default Mail Transfer Agent (MTA) in Ubuntu. It attempts to be fast and easy to administer and secure. It is compatible with the MTA sendmail. This section explains how to install and configure postfix. It also explains how to set it up as an SMTP server using a secure connection (for sending emails securely).

14.1.1. Installation
To install postfix with SMTP-AUTH and Transport Layer Security (TLS), run the following command:

sudo apt-get install postfix

Simply press return when the installation process asks questions, the configuration will be done in greater detail in the next stage.

14.1.2. Basic Configuration

To configure postfix, run the following command:

sudo dpkg-reconfigure postfix

The user interface will be displayed. On each screen, select the following values:
• Ok
• Internet Site
• NONE
• mail.example.com
• mail.example.com, localhost.localdomain, localhost
• No
• 127.0.0.0/8
• Yes
• 0
• +
• all
Replace mail.example.com with your mail server hostname.

14.1.3. SMTP Authentication

The next steps are to configure postfix to use SASL for SMTP AUTH. Rather than editing the configuration file directly, you can use the postconf command to configure all postfix parameters. The configuration parameters will be stored in /etc/postfix/main.cf file.
Later if you wish to re-configure a particular parameter, you can either run the command or change it manually in the file.

1. Configure Postfix to do SMTP AUTH using SASL (saslauthd):
postconf -e 'smtpd_sasl_local_domain ='
postconf -e 'smtpd_sasl_auth_enable = yes'
postconf -e 'smtpd_sasl_security_options = noanonymous'
postconf -e 'broken_sasl_auth_clients = yes'
postconf -e 'smtpd_recipient_restrictions = permit_sasl_authenticated,permit_mynetworks,reject_unauth_destination'
postconf -e 'inet_interfaces = all'
echo 'pwcheck_method: saslauthd' >> /etc/postfix/sasl/smtpd.conf
echo 'mech_list: plain login' >> /etc/postfix/sasl/smtpd.conf
2. Next, configure the digital certificate for TLS. When asked questions, follow the
instructions and answer appropriately.
openssl genrsa -des3 -rand /etc/hosts -out smtpd.key 1024
chmod 600 smtpd.key
openssl req -new -key smtpd.key -out smtpd.csr
openssl x509 -req -days 3650 -in smtpd.csr -signkey smtpd.key -out smtpd.crt
openssl rsa -in smtpd.key -out smtpd.key.unencrypted
mv -f smtpd.key.unencrypted smtpd.key
openssl req -new -x509 -extensions v3_ca -keyout cakey.pem -out cacert.pem -days 3650
mv smtpd.key /etc/ssl/private/
mv smtpd.crt /etc/ssl/certs/
mv cakey.pem /etc/ssl/private/
mv cacert.pem /etc/ssl/certs/
You can get the digital certificate from a certificate authority. Alternatively,
you can create the certificate yourself. Refer to Section 10.3.4, “Creating a
Self-Signed Certificate” [p. 53] for more details.
3. Configure Postfix to do TLS encryption for both incoming and outgoing mail:
postconf -e 'smtpd_tls_auth_only = no'
postconf -e 'smtp_use_tls = yes'
postconf -e 'smtpd_use_tls = yes'
postconf -e 'smtp_tls_note_starttls_offer = yes'
postconf -e 'smtpd_tls_key_file = /etc/ssl/private/smtpd.key'
postconf -e 'smtpd_tls_cert_file = /etc/ssl/certs/smtpd.crt'
postconf -e 'smtpd_tls_CAfile = /etc/ssl/certs/cacert.pem'
postconf -e 'smtpd_tls_loglevel = 1'
postconf -e 'smtpd_tls_received_header = yes'
postconf -e 'smtpd_tls_session_cache_timeout = 3600s'
postconf -e 'tls_random_source = dev:/dev/urandom'
postconf -e 'myhostname = mail.example.com'
After you run all the commands, the SMTP AUTH is configured with postfix.
The self-signed cerficiate is created for TLS and it is configured with postfix.
Now, the file /etc/postfix/main.cf should look like this
[../sample/postfix_configuration].

The postfix initial configuration is complete. Run the following command to start postfix daemon:

sudo /etc/init.d/postfix start

Now the postfix daemon is installed, configured and run successfully. Postfix supports SMTP AUTH as defined in RFC2554 [ftp://ftp.isi.edu/in-notes/rfc2554.txt]. It is based on SASL [ftp://ftp.isi.edu/in-notes/rfc2222.txt]. However it is still necessary to set up SASL authentication before you can use SMTP.

14.1.4. Configuring SASL

The libsasl2, sasl2-bin and libsasl2-modules are necessary to enable SMTP AUTH using SASL. You can install these applications if you have not installed them already.

apt-get install libsasl2 sasl2-bin

A few changes are necessary to make it work properly. Because Postfix runs chrooted in /var/spool/postfix, SASL needs to be configured to run in the false root (/var/run/saslauthd becomes /var/spool/postfix/var/run/saslauthd):

mkdir -p /var/spool/postfix/var/run/saslauthd
rm -rf /var/run/saslauthd

To activate saslauthd, edit the file /etc/default/saslauthd, and change or add the START variable. In order to configure saslauthd to run in the false root, add the PWDIR, PIDFILE and PARAMS variables. Finally, configure the MECHANISMS variable to your liking. The file should look like this:
# This needs to be uncommented before saslauthd will be run
# automatically
START=yes
PWDIR="/var/spool/postfix/var/run/saslauthd"
PARAMS="-m ${PWDIR}"
PIDFILE="${PWDIR}/saslauthd.pid"
# You must specify the authentication mechanisms you wish to use.
# This defaults to "pam" for PAM support, but may also include
# "shadow" or "sasldb", like this:
# MECHANISMS="pam shadow"
MECHANISMS="pam"
If you prefer, you can use shadow instead of pam. This will use MD5 hashed password transfer and is perfectly secure. The username and password needed to authenticate will be those of the users on the system you are using on the server.

Next, update the dpkg "state" of /var/spool/portfix/var/run/saslauthd. The saslauthd init script uses this setting to create the missing directory with the appropriate permissions and ownership:

dpkg-statoverride --force --update --add root sasl 755 /var/spool/postfix/var/run/saslauthd

14.1.5. Testing

SMTP AUTH configuration is complete. Now it is time to start and test the setup. You can run the following command to start the SASL daemon:

sudo /etc/init.d/saslauthd start

To see if SMTP-AUTH and TLS work properly, run the following command:

telnet mail.example.com 25

After you have established the connection to the postfix mail server, type:
ehlo mail.example.com
If you see the following lines among others, then everything is working perfectly. Type

quit to exit.

250-STARTTLS
250-AUTH LOGIN PLAIN
250-AUTH=LOGIN PLAIN
250 8BITMIME
14.2. Exim4
Exim4 is is another Message Transfer Agent (MTA) developed at the University of Cambridge for use on Unix systems connected to the internet. Exim can be installed in place of sendmail, although the configuration of exim is quite different to that of sendmail.

14.2.1. Installation
To install exim4, run the following command:

sudo apt-get install exim4 exim4-base exim4-config

14.2.2. Configuration
To configure exim4, run the following command:

sudo dpkg-reconfigure exim4-config

The user interface will be displayed. The user interface lets you configure many parameters. For example, In exim4 the configuration files are split among multiple files. If you wish to have them in one file you can configure accordingly in this user interface.
All the parameters you configure in the user interface are stored in /etc/exim4/update-exim4.conf.conf file. If you wish to re-configure, either you re-run the configuration wizard or manually edit this file using your favourite editor. Once you configure, you can run the following command to generate the master configuration file:
sudo update-exim4.conf

The master configuration file, is generated and it is stored in /var/lib/exim4/config.autogenerated.
At any time, you should not edit the master configuration file, /var/lib/exim4/config.autogenerated manually. It is updated automatically every time you run update-exim4.conf
You can run the following command to start exim4 daemon.

sudo /etc/init.d/exim4 start

TODO: This section should cover configuring SMTP AUTH with exim4.

14.3. Dovecot Server

Dovecot is a Mail Delivery Agent, written with security primarily in mind. It supports the major mailbox formats: mbox or Maildir. This section explain how to set it up as an imap or pop3 server.

14.3.1. Installation

To install dovecot, run the following command in the command prompt:

sudo apt-get install dovecot-common dovecot-imapd dovecot-pop3d

14.3.2. Configuration

To configure dovecot, you can edit the file /etc/dovecot/dovecot.conf. You can choose the protocol you use. It could be pop3, pop3s (pop3 secure), imap and imaps (imap secure).
A description of these protocols is beyond the scope of this guide. For further information, refer to the wikipedia articles on POP3 [http://en.wikipedia.org/wiki/POP3] and IMAP http://en.wikipedia.org/wiki/Internet_Message_Access_Protocol].
IMAPS and POP3S are more secure that the simple IMAP and POP3 because they use SSL encryption to connect. Once you have chosen the protocol, amend the following line in the file /etc/dovecot/dovecot.conf:
protocols = pop3 pop3s imap imaps
It enables the protocols when dovecot is started. Next, add the following line in pop3 section in the file /etc/dovecot/dovecot.conf:
pop3_uidl_format = %08Xu%08Xv
Next, choose the mailbox you use. Dovecot supports maildir and mbox formats. These are the most commonly used mailbox formats. They both have their own benefits and they are discussed on the dovecot website [http://dovecot.org/doc/configuration.txt].
Once you have chosen your mailbox type, edit the file /etc/dovecot/dovecot.conf and
change the following line:
default_mail_env = maildir:~/Maildir # (for maildir)
or
default_mail_env = mbox:~/mail:INBOX=/var/spool/mail/%u # (for mbox)
You should configure your Mail Trasport Agent (MTA) to transfer the incoming mail to this type of mailbox if it is different from the one you have configured.

Once you have configured dovecot, start the dovecot daemon in order to test your setup:

sudo /etc/init.d/dovecot start

If you have enabled imap, or pop3, you can also try to log in with the commands telnet localhost pop3 or telnet localhost imap2. If you see something like the following, the installation has been successful:
bhuvan@rainbow:~$ telnet localhost pop3
Trying 127.0.0.1...

Connected to localhost.localdomain.
Escape character is '^]'.
+OK Dovecot ready.

14.3.3. Dovecot SSL Configuration

To configure dovecot to use SSL, you can edit the file /etc/dovecot/dovecot.conf and
amend following lines:
ssl_cert_file = /etc/ssl/certs/dovecot.pem
ssl_key_file = /etc/ssl/private/dovecot.pem
ssl_disable = no
disable_plaintext_auth = no
The cert and key files are created automatically by dovecot when you install it. Please note that these keys are not signed and will give "bad signature" errors when connecting from a client. To avoid this, you can use commercial certificates, or even better, you can use your own SSL certificates.

14.3.4. Firewall Configuration for an Email Server

To access your mail server from another computer, you must configure your firewall to allow connections to the server on the necessary ports.
• IMAP - 143
• IMAPS - 993
• POP3 - 110
• POP3S - 995
14.4. Mailman
Mailman is an open source program for managing electronic mail discussions and e-newsletter lists. Many open source mailing lists (including all the Ubuntu mailing lists [http://lists.ubuntu.com]) use Mailman as their mailing list software. It is powerful and easy to install and maintain.

14.4.1. Installation

Mailman provides a web interface for the administrators and users. So, it requires apache with mod_perl support. Mailman uses an external mail server to send and receive emails. It works perfectly with the following mail servers:
• Postfix
• Exim
• Sendmail
• Qmail
We will see how to install mailman, the apache web server and the Exim mail server. If you wish to install mailman with a different mail server, please refer to the references section.

14.4.1.1. Apache2

To install apache2 you refer to Section 10.1, “Installation” [p. 46].

14.4.1.2. Exim4

To install Exim4 you run the following commands at a terminal prompt:

sudo apt-get install exim4
sudo apt-get install exim4-base
sudo apt-get install exim4-config

Once exim4 is installed, the configuration files are stored in the /etc/exim4 directory. In ubuntu, by default, the exim4 configuration files are split across different files. You can change this behavior by changing the following variable in the /etc/exim4/update-exim4.conf file:
• dc_use_split_config='true'

14.4.1.3. Mailman

To install Mailman, run following command at a terminal prompt:

sudo apt-get install mailman

It copies the installation files in /var/lib/mailman directory. It installs the CGI scripts in /usr/lib/cgi-bin/mailman directory. It creates list linux user. It creates the list linux group.
The mailman process will be owned by this user.

14.4.2. Configuration

This section assumes you have successfully installed mailman, apache2, and exim4. Now you just need to configure them.

14.4.2.1. Apache2

Once apache2 is installed, you can add the following lines in the
/etc/apache2/apache2.conf file:
Alias /images/mailman/ "/usr/share/images/mailman/"
Alias /pipermail/ "/var/lib/mailman/archives/public/"
Mailman uses apache2 to render its CGI scripts. The mailman CGI scripts are installed in the /usr/lib/cgi-bin/mailman directory. So, the mailman url will be http://hostname/cgi-bin/mailman/. You can make changes to the /etc/apache2/apache2.conf file if you wish to change this behavior.

14.4.2.2. Exim4

Once Exim4 is installed, you can start the Exim server using the following command from
a terminal prompt:
sudo apt-get /etc/init.d/exim4 start

In order to make mailman work with exim4, you need to configure exim4. As mentioned earlier, by default, exim4 uses multiple configuration files of different types. For details, please refer to the Exim [http://www.exim.org] website. To run mailman, we should add new a configuration file to the following configuration types:
• Main
• Transport
• Router
Exim creates a master configuration file by sorting all these mini configuration files. So, the order of these configuration files is very important.

14.4.2.3. Main

All the configuration files belonging to the main type are stored in the /etc/exim4/conf.d/main/ directory. You can add the following content to a new file, named 04_exim4-config_mailman:
# start
# Home dir for your Mailman installation -- aka Mailman's prefix
# directory.
# On Ubuntu this should be "/var/lib/mailman"
# This is normally the same as ~mailman
MM_HOME=/var/lib/mailman
#
# User and group for Mailman, should match your --with-mail-gid
# switch to Mailman's configure script. Value is normally "mailman"
MM_UID=list
MM_GID=list
#
# Domains that your lists are in - colon separated list
# you may wish to add these into local_domains as well
domainlist mm_domains=hostname.com
#
# -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
#
# These values are derived from the ones above and should not need # editing unless you have munged your mailman installation
#
# The path of the Mailman mail wrapper script
MM_WRAP=MM_HOME/mail/mailman
#
# The path of the list config file (used as a required file when
# verifying list addresses)
MM_LISTCHK=MM_HOME/lists/${lc::$local_part}/config.pck
# end
14.4.2.4. Transport
All the configuration files belonging to transport type are stored in the /etc/exim4/conf.d/transport/ directory. You can add the following content to a new file named 40_exim4-config_mailman:
mailman_transport:
driver = pipe
command = MM_WRAP \
'${if def:local_part_suffix \
{${sg{$local_part_suffix}{-(\\w+)(\\+.*)?}{\$1}}} \
{post}}' \
$local_part
current_directory = MM_HOME
home_directory = MM_HOME
user = MM_UID
group = MM_GID
14.4.2.5. Router
All the configuration files belonging to router type are stored in the /etc/exim4/conf.d/router/ directory. You can add the following content in to a new file named 101_exim4-config_mailman:
mailman_router:
driver = accept
require_files = MM_HOME/lists/$local_part/config.pck
local_part_suffix_optional
local_part_suffix = -bounces : -bounces+* : \
-confirm+* : -join : -leave : \
-owner : -request : -admin
transport = mailman_transport
The order of main and transport configuration files can be in any order. But, the order of router configuration files must be the same. This particular file must appear before the 200_exim4-config_primary file. These two configuration files contain same type of information. The first file takes the precedence. For more details, please refer to the references section.

14.4.2.6. Mailman

Once mailman is installed, you can run it using the following command:

sudo /etc/init.d/mailman start

Once mailman is installed, you should create the default mailing list. Run the following
command to create the mailing list:

sudo /usr/sbin/newlist mailman

Enter the email address of the person running the list: bhuvan at ubuntu.com
Initial mailman password:
To finish creating your mailing list, you must edit your /etc/aliases (or equivalent) file by adding the following lines, and possibly running the `newaliases' program:
## mailman mailing list
mailman: "|/var/lib/mailman/mail/mailman post mailman"
mailman-admin: "|/var/lib/mailman/mail/mailman admin mailman"
mailman-bounces: "|/var/lib/mailman/mail/mailman bounces mailman"
mailman-confirm: "|/var/lib/mailman/mail/mailman confirm mailman"
mailman-join: "|/var/lib/mailman/mail/mailman join mailman"
mailman-leave: "|/var/lib/mailman/mail/mailman leave mailman"
mailman-owner: "|/var/lib/mailman/mail/mailman owner mailman"
mailman-request: "|/var/lib/mailman/mail/mailman request mailman"
mailman-subscribe: "|/var/lib/mailman/mail/mailman subscribe mailman"
mailman-unsubscribe: "|/var/lib/mailman/mail/mailman unsubscribe mailman"
Hit enter to notify mailman owner...
#
We have configured exim to recognize all emails from mailman. So, it is not mandatory to make any new entries in /etc/aliases. If you have made any changes to the configuration files, please ensure that you restart those services before continuing to next section.

14.4.3. Administration

We assume you have a default installation. The mailman cgi scripts are still in /usr/lib/cgi-bin/mailman/ directory. Mailman provides a web based administration facility.
To access this page, point your browser to the following url:
http://hostname/cgi-bin/mailman/admin
The default mailing list, mailman, will appear in this screen. If you click the mailing list name, it will ask for your authentication password. If you enter the correct password, you will be able to change administrative settings of this mailing list. You can create a new mailing list using command line utility (/usr/sbin/newlist). Alternatively, you can create a new mailing list using web interface.

14.4.4. Users

Mailman provides a web based interface for users. To access this page, point your browser to the following url:
http://hostname/cgi-bin/mailman/listinfo
The default mailing list, mailman, will appear in this screen. If you click the mailing list name, it will display the subscription form. You can enter your email address, name (optional), and password to subscribe. An email invitation will be sent to you. You can follow the instructions in the email to subscribe.

14.4.5. References

GNU Mailman - Installation Manual [http://www.list.org/mailman-install/index.html]
HOWTO - Using Exim 4 and Mailman 2.1 together
[http://www.exim.org/howto/mailman21.html]

Chapter 5. Windows Networking
Computer networks are often comprised of diverse systems, and while operating a network made up entirely of Ubuntu desktop and server computers would certainly be fun, some network environments must consist of both Ubuntu and Microsoft® Windows® systems working together in harmony. This section of the Ubuntu Server Guide introduces principles and tools used in configuring your Ubuntu Server for sharing network resources with Windows computers.

Windows Networking

1. Introduction

Successfully networking your Ubuntu system with Windows clients involves providing and integrating with services common to Windows environments. Such services assist the sharing of data and information about the computers and users involved in the network, and may be classified under three major categories of functionality:
• File and Printer Sharing Services. Using the Server Message Block (SMB) protocol to facilitate the sharing of files, folders, volumes, and the sharing of printers throughout the network.
• Directory Services. Sharing vital information about the computers and users of the network with such technologies as the Lightweight Directory Access Protocol (LDAP) and Microsoft Active Directory®.
• Authentication and Access. Establishing the identity of a computer or user of the network and determining the information the computer or user is authorized to access using such principles and technologies as file permissions, group policies, and the Kerberos authentication service.
Fortunately, your Ubuntu system may provide all such facilities to Windows clients and share network resources among them. One of the principle pieces of software your Ubuntu system includes for Windows networking is the SAMBA suite of SMB server applications and tools. This section of the Ubuntu Server Guide will briefly introduce the installation and limited configuration of the SAMBA suite of server applications and
utilities. Additional, detailed documentation and information on SAMBA is beyond the scope of this documentation, but exists on the SAMBA website [http://www.samba.org].

2. Installing SAMBA

At the prompt enter the following command to install the SAMBA server applications:

sudo apt-get install samba

3. Configuring SAMBA

You may configure the SAMBA server by editing the /etc/samba/smb.conf file to change the default settings or add new settings. More information about each setting is available in the comments of the /etc/samba/smb.conf file or by viewing the /etc/samba/smb.conf manual page from the prompt with the following command typed at a terminal prompt:

man smb.conf

Prior to editing the configuration file, you should make a copy of the original file and protect it from writing so you will have the original settings as a reference and to re-use as necessary.
Backup the /etc/samba/smb.conf file:

sudo cp /etc/samba/smb.conf /etc/samba/smb.conf.original

Now, edit the /etc/samba/smb.conf file and make your changes.

 

 

3.1. Server

In addition to the SAMBA suite of file and printer sharing server applications, Ubuntu also includes other powerful server applications designed to provide additional network serverfunctionality to Windows clients similar to the functionality provided by actual Windows servers. For example, Ubuntu offers centralized management of network resources such as computers and users via Directory Services, and facilitates the identification, and authorization of computers and users via Authentication Services.
The following sections will discuss SAMBA and the supporting technologies, such as Lightweight Directory Access Protocol (LDAP) server, and Kerberos authentication server in more detail. You will also learn about some of the available configuration directives available the SAMBA configuration file which facilitate network integration with Windows clients and servers.

3.1.1. Active Directory

Active Directory is a proprietary implementation of Directory Services by Microsoft, and is used to provide a means to share information about network resources and users.
In addition to providing a centralized source of such information, Active Directory also acts as a centralized authentication security authority for the network. Active directory combines capabilities traditionally found in separate, specialized directory systems to simplify integration, management, and security of network resources. The SAMBA package may be configured to use Active Directory services from a Windows Domain
Controller.

3.1.1.1. LDAP

The LDAP server application provides Directory Services functionality to Windows
computers in a manner very similar to Microsoft Active Directory services. Such services
include managing the identities and relationships of computers, users, and groups of
computers or users that participate in the network, and providing a consistent means
to describe, locate, and manage these resources. The freely available implementation
of LDAP available for your Ubuntu system is called OpenLDAP. The server daemons
responsible for handling OpenLDAP directory requests and the propagation of directory
data from one LDAP server to another on Ubuntu, are slapd and slurpd. OpenLDAP may
be used in conjunction with SAMBA to provide File, Print, and Directory services in much
the same way a Windows Domain Controller does so long as SAMBA is compiled with
LDAP support.
3.1.1.2. Kerberos
The Kerberos authentication security system is a standardized service for providing
authentication to computers and users by means of a centralized server which grants
encrypted authorization tickets accepted for authorization by any other computer using
Kerberos. Benefits of Kerberos authentication include mutual authentication, delegated
authentication, interoperability, and simplified trust management. The primary server
daemons for handling the Kerberos authentication and Kerberos database administration
on Ubuntu are krb5kdc and kadmin. SAMBA may use Kerberos as a mechanism for
authenticating computers and users against a Windows Domain Controller. To do so,
the Ubuntu system must have Kerberos installed, and the /etc/samba/smb.conf must
be modified to select the the proper realm and security mode. For example, edit the
/etc/samba/smb.conf file and add the values:
realm = DOMAIN_NAME
security = ADS
to the file, and save the file.
Be sure to replace the token DOMAIN_NAME in the example above with the
actual name of your specific Windows Domain.
You will need to restart the SAMBA daemons to effect these changes. Restart the SAMBA
daemons with the following command entered at a terminal prompt:
sudo /etc/init.d/samba restart
3.1.2. Computer Accounts
Computer Accounts are used in Directory Services to uniquely identify computer systems
participating in a network, and are even treated in the same manner as users in terms of
security. Computer accounts may have passwords just as user accounts do, and are subject
to authorization to network resources in the same manner as user accounts. For example,
if a network user, with a valid account for a particular network attempts to authenticate
with a network resource from a computer which does not have a valid computer account,
depending upon policies enforced on the network, the user may be denied access to the
resource if the computer the user is attempting authentication from is considered to be an
unauthorized computer.
A computer account may be added to the SAMBA password file, provided the name of the
computer being added exists as a valid user account in the local password database first.
The syntax for adding a computer or machine account to the SAMBA password file is to
use the smbpasswd command from a terminal prompt as follows:
sudo smbpasswd -a -m COMPUTER_NAME
Be sure to replace the token COMPUTER_NAME in the example above with the
actual name of the specific computer you wish to add a machine account for.
3.1.3. File Permissions
File Permissions define the explicit rights a computer or user has to a particular directory,
file, or set of files. Such permissions may be defined by editing the /etc/samba/smb.conf
file and specifying the explicit permissions of a defined file share. For example, if
you have defined a SAMBA share called sourcedocs and wish to give read-only
permissions to the group of users known as planning, but wanted to allow writing to the
share by the group called authors and the user named richard, then you could edit the
/etc/samba/smb.conf file, and add the following entries under the [sourcedocs] entry:
read list = @planning
write list = @authors, richard
Save the /etc/samba/smb.conf for the changes to take effect.
Another possible permission is to declare administrative permissions to a particular
shared resource. Users having administrative permissions may read, write, or modify
any information contained in the resource the user has been given explicit administrative
permissions to. For example, if you wanted to give the user melissa administrative
permissions to the example sourcedocs share, you would edit the /etc/samba/smb.conf
file, and add the following line under the [sourcedocs] entry:
admin users = melissa
Save the /etc/samba/smb.conf for the changes to take effect.

3.2. Clients
Ubuntu includes client applications and capabilities for accessing network resources
shared with the SMB protocol. For example, a utility called smbclient allows for accessing
remote shared file-systems, in a manner similar to a File Transfer Protocol (FTP) client.
To access a shared folder resource known as documents offered by a remote Windows
computer named bill using smbclient for example, one would enter a command similar to
the following at the prompt:
smbclient //bill/documents -U
You will then be prompted for the password for the user name specified after the -U
switch, and upon successful authentication, will be presented with a prompt where
commands may be entered for manipulating and transferring files in a syntax similar to that
used by non-graphical FTP clients. For more information on the smbclient utility, read the
utility's manual page with the command:
man smbclient
Local mounting of remote network resources using the SMB protocol is also possible
using the mount command. For example, to mount a shared folder named project-code
on a Windows server named development as the user dlightman to your Ubuntu system's
/mnt/pcode mount-point, you would issue this command at the prompt:
mount -t smbfs -o username=dlightman //development/project-code /mnt/pcode
You will then be prompted for the user password, and after successfully authenticating, the
contents of the shared resource will be available locally via the mount-point specified as
the last argument to the mount command. To disconnect the shared resource, simply use
the umount command as you would with any other mounted file system. For example:
umount /mnt/pcode
3.2.1. User Accounts
User Accounts define persons with some level of authorization to use certain computer
and network resources. Typically, in a network environment, a user account is provided
to each person allowed to access a computer or network, where policies and permissions
then define what explicit rights that user account has access to. To define SAMBA network
users for your Ubuntu system, you may use the smbpasswd command. For example to add
a SAMBA user to your Ubuntu system with the user name jseinfeld, you would enter this
command at the prompt:
smbpasswd -a jseinfeld
The smbpasswd application will then prompt you to enter a password for the user:
New SMB password:
Enter the password you wish to set for the user, and the smbpasswd application will ask
you to confirm the password:
Retype new SMB password:
Confirm the password, and smbpasswd will add the entry for the user to the SAMBA
password file.
3.2.2. Groups
Groups define a collection of computers or users which have a common level of access
to particular network resources and offer a level of granularity in controlling access to
such resources. For example, if a group qa is defined and contains the users freda, danika,
and rob and a second group support is defined and consists of users danika, jeremy, and
vincent then certain network resources configured to allow access by the qa group will
subsequently enable access by freda, danika, and rob, but not jeremy or vincent. Since the
user danika belongs to both the qa and support groups, she will be able to access resources
configured for access by both groups, whereas all other users will have only access to
resources explicitly allowing the group they are part of.
When defining groups in the SAMBA configuration file, /etc/samba/smb.conf
the recognized syntax is to preface the group name with an "@" symbol. For
example, if you wished to define a group named sysadmin in a certain section of the
/etc/samba/smb.conf, you would do so by entering the group name as @sysadmin.
3.2.3. Group Policy
Group Policy defines certain SAMBA configuration settings pertaining to the Domain or
Workgroup computer accounts belong to, and other global settings for the SAMBA server.
For example, if the SAMBA server belongs to a Workgroup of Windows computers called
LEVELONE, then the /etc/samba/smb.conf could be edited, and the following value
changed accordingly:
workgroup = LEVELONE
Save the file and restart the SAMBA daemons to affect the change.
Other important global policy settings include the server string which defines the
NETBIOS server name reported by your Ubuntu system to other machines on the
Windows-based network. This is the name your Ubuntu system will be recognized as by
Windows clients and other computers capable of browsing the network with the SMB
protocol. Additionally, you may specify the name and location of the SAMBA server's log
file by using the log file directive in the /etc/samba/smb.conf file.
Some of the additional directives governing global group policy include specification of
the global nature of all shared resources. For example, placing certain directives under the
[global] heading of the /etc/samba/smb.conf file will affect all shared resources unless
an overriding directive is placed under a particular shared resource heading. You specify
all shares are browseable by all clients on the network by placing a browseable directive,
which takes a Boolean argument, under the [global] heading in the /etc/samba/smb.conf.
That is, if you edit the file and add the line:
browseable = true
under the [global] section of /etc/samba/smb.conf, then all shares provided by your
Ubuntu system via SAMBA will be browseable by all authorized clients, unless a specific
share contains a browseable = false directive, which will override the global directive.
Other examples which work in a similar manner, are the public and writeable directives.
The public directive accepts a Boolean value and decides whether a particular shared
resource is visible by all clients, authorized or not. The writeable directive also takes a Boolean value and defines whether a particular shared resource is writable by any and all
network clients.

 

 

Latest Posts 10/04 – New Compiz Fusion: Cubereflex rename to Cubeaddon with new effect Cylinder 10/04 – Ubuntu Server Guide: Part II 09/04 – Ubuntu Server Guide: Part I 08/04 – RSS Buttons Collection Pack for Your Blog: The Ultimate List 05/04 – MP3Roaster is a Perl hack for Burning Audio Cds out of Mp3 OGG Vorbis and FLAC files 31/03 – Newsbeuter, RSS feedreader for the text console 30/03 - An Introdution to CrossOver Games 29/03 – Cdrkit, a collection of applications related to creation of optical disk media on Unix platforms 28/03 - BurnCDDA, a tool for creating audio Cds 27/03 – Ten Tips for New Ubuntu Users 26/03 – Picasa is a software application for organizing and editing digital photos 25/03 – KolourPaint: More than a Microsoft Paint clone 20/03 – Sunbird, Mozilla's Calendar appolication, support extensions just as Firefox and Thunderbird do 19/03 – Dvd+rw-tools makes it possible to burn Dvd images created by “dvdauthor” or “mkisofs” 15/03 – The Burgner project aims to be a complete free burning suite 14/03 - Software Packages in Hardy Heron: Administration Utilities 10/03 – Compiz and Compiz Fusion 0.72 released 06/03 - Evolution: Calendar, eMail and Collaboration 03/03 - Cdrdao records audio or data CD-Rs in disk-at-once 29/02 - Firebird 2.03 included in Ubuntu 8.04 Hardy Heron 29/02 - FEBE, Firefox Environment Backup Extension 28/02 - Introducing Ubuntu Mobile 25/02 - ZetBackup, backup utility specially build for using external disks 24/02 -Ubuntu 8.10: Introducing the Intrepid Ibex 21/02 - Games for Linux: comparison of free software shooters 18/02 - Xfiles files tree syncronization and cross validation 15/02 - Tape Oriented Backup is a general driving for making and maintaning backups   Linux Links 05/04 Zmanda Recovery Manager for MySQL 2.0 Released 25/03 – Phaser, a frontend to Cd record with the aim for Making Cd Burning Under Linux Easier 19/03 – Gnash, the free software Flash Player , has released its first beta 16/03 – Burn CDDA console frontend for cdrecord, mpg 123, oggdec, mppdec, flac 14/03 – BU Linux, based on Fedora Core Linux 13/03 – BuffaloLinux is a Slackware based distribution 12/03 – New features for Gobuntu 8.04 Hardy Heron (alpha 6) 07/03 – Mythbuntu Linux Media Center 06/03 – Mozilla New Mail Icon 05/03 - KNOPPIX 5.3 release al CeBIT 2008 03/03 – KPDF viewer based on the code of the xpdf application 03/03 – New Compiz Fusion plugins and updates 29/02 – Over 35 Different Styles of RSS Icons 28/02 - ZZEE Active SQL Backup 27/02 - The Zumastor Linux storage project adds enterprise storage 23/02 - Run Linux inside Windows 22/02 – ARSIG Linux (Arl) is optimized for use on LAN routers 20/02 - Yet another Cd backup tool (Yacdbak) 15/02 - VitalFile for Real-Time Worstation Protection

 

Ubuntu Server Guide Part 2

Many other configuration directives for sshd are available for changing the server application's behavior to fit your needs. Be advised, however, if your only method of access to a server is ssh, and you make a mistake in configuring sshd via the /etc/ssh/sshd_config file, you may find you are locked out of the server upon restarting it, or that the sshd server refuses to start due to an incorrect configuration directive, so be extra careful when editing this file on a remote server.

References

OpenSSH Website [http://www.openssh.org/]
Advanced OpenSSH Wiki Page [https://wiki.ubuntu.com/AdvancedOpenSSH]

5. FTP Server

File Transfer Protocol (FTP) is a TCP protocol for uploading and downloading files
between computers. FTP works on a client/server model. The server component is called an FTP daemon. It continuously listens for FTP requests from remote clients. When a request is received, it manages the the login and sets up the connection. For the duration of the session it executes any of commands sent by the FTP client.
Access to an FTP server can be managed in two ways:
• Anonymous
• Authenticated
In the Anonymous mode, remote clients can access the FTP server by using the default user account called 'anonymous" or "ftp" and sending an email address as the password.

In the Authenticated mode a user must have an account and a password. User access to the FTP server directories and files is dependent on the permissions defined for the account used at login. As a general rule, the FTP daemon will hide the root directory of the FTP server and change it to the FTP Home directory. This hides the rest of the file system from
remote sessions.

5.1. vsftpd - FTP Server Installation

vsftpd is an FTP daemon available in Ubuntu. It is easy to install, set up, and maintain. To install vsftpd you can run the following command:
sudo apt-get install vsftpd

 

 

5.2. vsftpd - FTP Server Configuration

You can edit the vsftpd configuration file, /etc/vsftpd.conf, to change the default
settings. By default only anonymous FTP is allowed. If you wish to disable this option, you should change the following line:
anonymous_enable=YES
to
anonymous_enable=NO
By default, local system users are not allowed to login to FTP server. To change this
setting, you should uncomment the following line:
#local_enable=YES
By default, users are allowed to download files from FTP server. They are not allowed to upload files to FTP server. To change this setting, you should uncomment the following line:
#write_enable=YES

Similarly, by default, the anonymous users are not allowed to upload files to FTP server.
To change this setting, you should uncomment the following line:
#anon_upload_enable=YES
The configuration file consists of many configuration parameters. The information about each parameter is available in the configuration file. Alternatively, you can refer to the man page, man 5 vsftpd.conf for details of each parameter.
Once you configure vsftpd you can start the daemon. You can run following command to run the vsftpd daemon:

Please note that the defaults in the configuration file are set as they are for
security reasons. Each of the above changes makes the system a little less secure,
so make them only if you need them.

6. Network File System (NFS)

NFS allows a system to share directories and files with others over a network. By using NFS, users and programs can access files on remote systems almost as if they were local files.
Some of the most notable benefits that NFS can provide are:
• Local workstations use less disk space because commonly used data can be stored on a single machine and still remain accessible to others over the network.
• There is no need for users to have separate home directories on every network machine.
Home directories could be set up on the NFS server and made available throughout the network.
• Storage devices such as floppy disks, CDROM drives, and USB Thumb drives can be
used by other machines on the network. This may reduce the number of removable
media drives throughout the network.

6.1. Installation

At a terminal prompt enter the following command to install the NFS Server:
sudo apt-get install nfs-kernel-server

6.2. Configuration

You can configure the directories to be exported by adding them to the /etc/exports file.
For example:

You can replace * with one of the hostname formats. Make the hostname declaration as specific as possible so unwanted systems cannot access the NFS mount.
To start the NFS server, you can run the following command at a terminal prompt:
sudo /etc/init.d/nfs-kernel-server start

6.3. NFS Client Configuration

Use the mount command to mount a shared NFS directory from another machine, by
typing a command line similar to the following at a terminal prompt:
sudo mount example.hostname.com:/ubuntu /local/ubuntu

The mount point directory /local/ubuntu must exist. There should be no files or
subdirectories in the /local/ubuntu directory.
An alternate way to mount an NFS share from another machine is to add a line to the /etc/fstab file. The line must state the hostname of the NFS server, the directory on the server being exported, and the directory on the local machine where the NFS share is to be mounted.
The general syntax for the line in /etc/fstab file is as follows:
example.hostname.com:/ubuntu /local/ubuntu nfs rsize=8192,wsize=8192,timeo=14,intr

 

6.4. References

Linux NFS faq [http://nfs.sourceforge.net/]

7. Dynamic Host Configuration Protocol (DHCP)

The Dynamic Host Configuration Protocol (DHCP) is a network service that enables host computers to be automatically assigned settings from a server as opposed to manually configuring each network host. Computers configured to be DHCP clients have no control over the settings they receive from the DHCP server, and the configuration is transparent to the computer's user.
The most common settings provided by a DHCP server to DHCP clients include:
• IP-Address and Netmask
• DNS
• WINS
However, a DHCP server can also supply configuration properties such as:
• Host Name
• Domain Name
• Default Gateway
• Time Server
• Print Server
The advantage of using DHCP is that changes to the network, for example a change in the address of the DNS server, need only be changed at the DHCP server, and all network hosts will be reconfigured the next time their DHCP clients poll the DHCP server. As an added advantage, it is also easier to integrate new computers into the network, as there is no need to check for the availability of an IP address. Conflicts in IP address allocation are also reduced.
A DHCP server can provide configuration settings using two methods:

MAC Address
This method entails using DHCP to identify the unique hardware address of each
network card connected to the network and then continually supplying a constant
configuration each time the DHCP client makes a request to the DHCP server using
that network device.

Address Pool
This method entails defining a pool (sometimes also called a range or scope) of
IP addresses from which DHCP clients are supplied their configuration properties
dynamically and on a fist come first serve basis. When a DHCP client is no longer on
the network for a specified period, the configuration is expired and released back to the address pool for use by other DHCP Clients.
Ubuntu is shipped with both DHCP server and client. The server is dhcpd (dynamic host configuration protocol daemon). The client provided with Ubuntu is dhclient and should be installed on all computers required to be automatically configured. Both programs are easy to install and configure and will be automatically started at system boot.

7.1. Installation

At a terminal prompt, enter the following command to install dhcpd:
sudo apt-get install dhcpd
You will see the following output, which explains what to do next:
Please note that if you are installing the DHCP server for the first
time you need to configure. Please stop (/etc/init.d/dhcp
stop) the DHCP server daemon, edit /etc/dhcpd.conf to suit your needs
and particular configuration, and restart the DHCP server daemon
(/etc/init.d/dhcp start).
You also need to edit /etc/default/dhcp to specify the interfaces dhcpd
should listen to. By default it listens to eth0.
NOTE: dhcpd's messages are being sent to syslog. Look there for
diagnostics messages.
Starting DHCP server: dhcpd failed to start - check syslog for diagnostics.
7.2. Configuration
The error message the installation ends with might be a little confusing, but the following
steps will help you configure the service:
Most commonly, what you want to do is assign an IP address randomly. This can be done
with settings as follows:
# Sample /etc/dhcpd.conf
# (add your comments here)
default-lease-time 600;
max-lease-time 7200;
option subnet-mask 255.255.255.0;
option broadcast-address 192.168.1.255;
option routers 192.168.1.254;
option domain-name-servers 192.168.1.1, 192.168.1.2;
option domain-name "mydomain.org";
subnet 192.168.1.0 netmask 255.255.255.0 {
range 192.168.1.10 192.168.1.100;
range 192.168.1.150 192.168.1.200;
}
This will result in the DHCP server giving a client an IP address from the range
192.168.1.10-192.168.1.100 or 192.168.1.150-192.168.1.200. It will lease an IP address for 600 seconds if the client doesn't ask for a specific time frame. Otherwise the maximum Networking (allowed) lease will be 7200 seconds. The server will also "advise" the client that it should use 255.255.255.0 as its subnet mask, 192.168.1.255 as its broadcast address, 192.168.1.254 as the router/gateway and 192.168.1.1 and 192.168.1.2 as its DNS servers.
If you need to specify a WINS server for your Windows clients, you will need to include the netbios-name-servers option, e.g.
option netbios-name-servers 192.168.1.1;
Dhcpd configuration settings are taken from the DHCP mini-HOWTO, which can be found here [http://www.tldp.org/HOWTO/DHCP/index.html].

References

DHCP FAQ [http://www.dhcp-handbook.com/dhcp_faq.html]

8. Domain Name Service (DNS)

Domain Name Service (DNS) is an Internet service that maps IP addresses and fully
qualified domain names (FQDN) to one another. In this way, DNS alleviates the need to remember IP addresses. Computers that run DNS are called name servers. Ubuntu ships with BIND (Berkley Internet Naming Daemon), the most common program used for maintaining a name server on GNU/Linux.

8.1. Installation

At a terminal prompt, enter the following command to install dns:
sudo apt-get install bind

8.2. Configuration

The DNS configuration files are stored in the /etc/bind directory. The primary
configuration file is /etc/bind/named.conf. The content of the default configuration file is shown below:
// This is the primary configuration file for the BIND DNS server named.
//
// Please read /usr/share/doc/bind/README.Debian for information on the
// structure of BIND configuration files in Debian for BIND versions 8.2.1
// and later, *BEFORE* you customize this configuration file.
//
include "/etc/bind/named.conf.options";
// reduce log verbosity on issues outside our control
logging {
category lame-servers { null; };
category cname { null; };
};
// prime the server with knowledge of the root servers
zone "." {
type hint;
file "/etc/bind/db.root";
};
// be authoritative for the localhost forward and reverse zones, and for
// broadcast zones as per RFC 1912
zone "localhost" {
type master;
file "/etc/bind/db.local";
};
41

Networking
zone "127.in-addr.arpa" {
type master;
file "/etc/bind/db.127";
};
zone "0.in-addr.arpa" {
type master;
file "/etc/bind/db.0";
};
zone "255.in-addr.arpa" {
type master;
file "/etc/bind/db.255";
};
// add local zone definitions here
include "/etc/bind/named.conf.local";
The include line specifies the filename which contains the DNS options. The directory line
in the options file tells DNS where to look for files. All files BIND uses will be relative to
this directory.
The file named /etc/bind/db.root describes the root name servers in the world. The
servers change over time and must be maintained now and then.
The zone section defines a master server, and it is stored in a file mentioned against file
tag. Every zone file contains 3 resource records (RRs): an SOA RR, an NS RR and a PTR
RR. SOA is short of Start of Authority. The "@" is a special notation meaning the origin.
NS is the Name Server RR. PTR is Domain Name Pointer. To start the DNS server, run the
following command from a terminal prompt:

You can refer to the documentation mentioned in the references section for details.

8.3. References

DNS HOWTO [http://www.tldp.org/HOWTO/DNS-HOWTO.html]

9. CUPS - Print Server

The primary mechanism for Ubuntu printing and print services is the Common UNIX
Printing System (CUPS). This printing system is a freely available, portable printing layer which has become the new standard for printing in most GNU/Linux distributions.
CUPS manages print jobs and queues and provides network printing using the standard Internet Printing Protocol (IPP), while offering support for a very large range of printers, from dot-matrix to laser and many in between. CUPS also supports PostScript Printer Description (PPD) and auto-detection of network printers, and features a simple web-based configuration and administration tool.

9.1. Installation

To install CUPS on your Ubuntu computer, simply use sudo with the the apt-get command and give the packages to install as the first parameter. A complete CUPS install has many package dependencies, but they may all be specified on the same command line.

Enter the following at a terminal prompt to install CUPS:
sudo apt-get install cupsys cupsys-client
Upon authenticating with your user password, the packages should be downloaded and installed without error. Upon the conclusion of installation, the CUPS server will be started automatically. For troubleshooting purposes, you can access CUPS server errors via the error log file at: /var/log/cups/error_log. If the error log does not show enough information to troubleshoot any problems you encounter, the verbosity of the CUPS log can be increased by changing the LogLevel directive in the configuration file (discussed below) to "debug" or even "debug2", which logs everything, from the default of "info". If you make this change, remember to change it back once you've solved your problem, to prevent the log file from becoming overly large.

9.2. Configuration

The Common UNIX Printing System server's behavior is configured through the directives contained in the file /etc/cups/cupsd.conf. The CUPS configuration file follows the same syntax as the primary configuration file for the Apache HTTP server, so users familiar with editing Apache's configuration file should feel at ease when editing the CUPS configuration file. Some examples of settings you may wish to change initially will be presented here.
Prior to editing the configuration file, you should make a copy of the original file
and protect it from writing, so you will have the original settings as a reference,
and to reuse as necessary.

Copy the /etc/cups/cupsd.conf file and protect it from writing with the
following commands, issued at a terminal prompt:

• ServerAdmin: To configure the email address of the designated administrator
of the CUPS server, simply edit the /etc/cups/cupsd.conf configuration file
with your preferred text editor, and modify the ServerAdmin line accordingly. For
example, if you are the Administrator for the CUPS server, and your e-mail address is
'bjoy@somebigco.com', then you would modify the ServerAdmin line to appear as such:
ServerAdmin bjoy@somebigco.com
For more examples of configuration directives in the CUPS server configuration file,
view the associated system manual page by entering the following command at a terminal
prompt:

Whenever you make changes to the /etc/cups/cupsd.conf configuration file,
you'll need to restart the CUPS server by typing the following command at a
terminal prompt:

Some other configuration for the CUPS server is done in the file

• Listen: By default on Ubuntu, the CUPS server installation listens only on the
loopback interface at IP address 127.0.0.1. In order to instruct the CUPS server to
listen on an actual network adapter's IP address, you must specify either a hostname,
the IP address, or optionally, an IP address/port pairing via the addition of a Listen
directive. For example, if your CUPS server resides on a local network at the IP
address 192.168.10.250 and you'd like to make it accessible to the other systems on
this subnetwork, you would edit the /etc/cups/cups.d/ports.conf and add a Listen
directive, as such:
Listen 127.0.0.1:631 # existing loopback Listen
Listen /var/run/cups/cups.sock # existing socket Listen
Listen 192.168.10.250:631 # Listen on the LAN interface, Port 631 (IPP)
In the example above, you may comment out or remove the reference to the Loopback
address (127.0.0.1) if you do not wish cupsd to listen on that interface, but would
rather have it only listen on the Ethernet interfaces of the Local Area Network (LAN).
To enable listening for all network interfaces for which a certain hostname is bound,
including the Loopback, you could create a Listen entry for the hostname socrates as
such:
Listen socrates:631 # Listen on all interfaces for the hostname 'socrates'
or by omitting the Listen directive and using Port instead, as in:
Port 631 # Listen on port 631 on all interfaces
9.3. References
CUPS Website [http://www.cups.org/]

10. HTTPD - Apache2 Web Server

Apache is the most commonly used Web Server on GNU/Linux systems. Web Servers are used to serve Web Pages requested by client computers. Clients typically request and view Web Pages using Web Browser applications such as Firefox, Opera, or Mozilla.
Users enter a Uniform Resource Locator (URL) to point to a Web server by means
of its Fully Qualified Domain Name (FQDN) and a path to the required resource. For
example, to view the home page of the Ubuntu Web site [http://www.ubuntu.com] a
user will enter only the FQDN. To request specific information about paid support
[http://www.ubuntu.com/support/supportoptions/paidsupport], a user will enter the FQDN followed by a path.
The most common protocol used to transfer Web pages is the Hyper Text Transfer Protocol (HTTP). Protocols such as Hyper Text Transfer Protocol over Secure Sockets Layer (HTTPS), and File Transfer Protocol (FTP), a protocol for uploading and downloading files, are also supported.
Apache Web Servers are often used in combination with the MySQL database engine, the HyperText Preprocessor (PHP) scripting language, and other popular scripting languages such as Python and Perl. This configuration is termed LAMP (Linux, Apache, MySQL and Perl/Python/PHP) and forms a powerful and robust platform for the development and deployment of Web-based applications.

10.1. Installation

The Apache2 web server is available in Ubuntu Linux. To install Apache2:
• At a terminal prompt enter the following command:
sudo apt-get install apache2

10.2. Configuration

Apache is configured by placing directives in plain text configuration files. The main
configuration file is called apache2.conf. In addition, other configuration files may be
added using the Include directive, and wildcards can be used to include many configuration files. Any directive may be placed in any of these configuration files. Changes to the main configuration files are only recognized by Apache2 when it is started or restarted.
The server also reads a file containing mime document types; the filename is set by the TypesConfig directive, and is mime.types by default.
The default Apache2 configuration file is /etc/apache2/apache2.conf . You can edit this file to configure the Apache2 server. You can configure the port number, document root, modules, log files, virtual hosts, etc.

10.2.1. Basic Settings

This section explains Apache2 server essential configuration parameters. Refer to the
Apache2 Documentation [http://httpd.apache.org/docs/2.0/] for more details.
• Apache2 ships with a virtual-host-friendly default configuration. That is, it is configured with a single default virtual host (using the VirtualHost directive) which can modified or used as-is if you have a single site, or used as a template for additional virtual hosts if you have multiple sites. If left alone, the default virtual host will serve as your default site, or the site users will see if the URL they enter does not match the ServerName directive of any of your custom sites. To modify the default virtual host, edit the file /etc/apache2/sites-available/default. If you wish to configure a new virtual host or site, copy that file into the same directory with a name you choose.

For example, sudo cp /etc/apache2/sites-available/default /etc/apache2/sites-available/mynewsite Edit
the new file to configure the new site using some of the directives described below.
• The ServerAdmin directive specifies the email address to be advertised for the server's administrator. The default value is webmaster@localhost. This should be changed to an email address that is delivered to you (if you are the server's administrator). If your website has a problem, Apache2 will display an error message containing this email address to report the problem to. Find this directive in your site's configuration file in /etc/apache2/sites-available.
• The Listen directive specifies the port, and optionally the IP address, Apache2 should listen on. If the IP address is not specified, Apache2 will listen on all IP addresses assigned to the machine it runs on. The default value for the Listen directive is 80.
Change this to 127.0.0.1:80 to cause Apache2 to listen only on your loopback interface so that it will not be available to the Internet, to (for example) 81 to change the port that it listens on, or leave it as is for normal operation. This directive can be found and changed in its own file, /etc/apache2/ports.conf
• The ServerName directive is optional and specifies what FQDN your site should answer to. The default virtual host has no ServerName directive specified, so it will respond to all requests that do not match a ServerName directive in another virtual host. If you have just acquired the domain name ubunturocks.com and wish to host it on your Ubuntu server, the value of the ServerName directive in your virtual host configuration file should be ubunturocks.com. Add this directive to the new virtual host file you created earlier (/etc/apache2/sites-available/mynewsite).
You may also want your site to respond to www.ubunturocks.com, since
many users will assume the www prefix is appropriate. Use the ServerAlias
directive for this. You may also use wildcards in the ServerAlias directive. For
example, ServerAlias *.ubunturocks.com will cause your site to respond to
any domain request ending in .ubunturocks.com.
• The DocumentRoot directive specifies where Apache should look for the files that
make up the site. The default value is /var/www. No site is configured there, but if you
uncomment the RedirectMatch directive in /etc/apache2/apache2.conf requests
will be redirected to /var/www/apache2-default where the default Apache2 site awaits.
Change this value in your site's virtual host file, and remember to create that directory if
necessary!
The /etc/apache2/sites-available directory is not parsed by Apache2.
Symbolic links in /etc/apache2/sites-enabled point to "available" sites. Use
the a2ensite (Apache2 Enable Site) utility to create those symbolic links,
like so: sudo a2ensite mynewsite where your site's configuration file is
/etc/apache2/sites-available/mynewsite. Similarly, the a2dissite utility
should be used to disable sites.

10.2.2. Default Settings

This section explains configuration of the Apache2 server default settings. For example, if you add a virtual host, the settings you configure for the virtual host take precedence for that virtual host. For a directive not defined within the virtual host settings, the default value is used.
• The DirectoryIndex is the default page served by the server when a user requests an index of a directory by specifying a forward slash (/) at the end of the directory name.

he or she will get either the DirectoryIndex page if it exists, a server-generated directory list if it does not and the Indexes option is specified, or a Permission Denied page if neither is true. The server will try to find one of the files listed in the DirectoryIndex directive and will return the first one it finds. If it does not find any of these files and if Options Indexes is set for that directory, the server will generate and return a list, in HTML format, of the subdirectories and files in the directory. The default value, found in /etc/apache2/apache2.conf is " index.html index.cgi index.pl index.php index.xhtml". Thus, if Apache2 finds a file in a requested directory matching any of these names, the first will be displayed.
• The ErrorDocument directive allows you to specify a file for Apache to use for
specific error events. For example, if a user requests a resource that does not
exist, a 404 error will occur, and per Apache2's default configuration, the file
/usr/share/apache2/error/HTTP_NOT_FOUND.html.var will be displayed.
That file is not in the server's DocumentRoot, but there is an Alias directive in
/etc/apache2/apache2.conf that redirects requests to the /error directory to
/usr/share/apache2/error/. To see a list of the default ErrorDocument directives, use this command: grep ErrorDocument /etc/apache2/apache2.conf
• By default, the server writes the transfer log to the file /var/log/apache2/access.log.
You can change this on a per-site basis in your virtual host configuration files
with the CustomLog directive, or omit it to accept the default, specified in
/etc/apache2/apache2.conf. You may also specify the file to which errors are logged, via the ErrorLog directive, whose default is /var/log/apache2/error.log. These
are kept separate from the transfer logs to aid in troubleshooting problems with your
Apache2 server. You may also specify the LogLevel (the default value is "warn") and the LogFormat (see /etc/apache2/apache2.conf for the default value).
• Some options are specified on a per-directory basis rather than per-server. Option is one of these directives. A Directory stanza is enclosed in XML-like tags, like so:

The Options directive within a Directory stanza accepts one or more of the following
values (among others), separated by spaces:
• ExecCGI - Allow execution of CGI scripts. CGI scripts are not executed if this option is not chosen.
Most files should not be executed as CGI scripts. This would be very
dangerous. CGI scripts should kept in a directory separate from and outside
your DocumentRoot, and only this directory should have the ExecCGI
option set. This is the default, and the default location for CGI scripts is
/usr/lib/cgi-bin.
• Includes - Allow server-side includes. Server-side includes allow an HTML file
to include other files. This is not a common option. See the Apache2 SSI Howto
[http://httpd.apache.org/docs/2.0/howto/ssi.html] for mor information.
• IncludesNOEXEC - Allow server-side includes, but disable the #exec and #include
commands in CGI scripts.
• Indexes - Display a formatted list of the directory's contents, if no DirectoryIndex
(such as index.html) exists in the requested directory.
For security reasons, this should usually not be set, and certainly should not
be set on your DocumentRoot directory. Enable this option carefully on a
per-directory basis only if you are certain you want users to see the entire
contents of the directory.
• Multiview - Support content-negotiated multiviews; this option is disabled
by default for security reasons. See the Apache2 documentation on this option
[http://httpd.apache.org/docs/2.0/mod/mod_negotiation.html#multiviews].
• SymLinksIfOwnerMatch - Only follow symbolic links if the target file or directory
has the same owner as the link.
10.2.3. Virtual Hosts Settings
Virtual hosts allow you to run different servers for different IP addresses, different host names, or different ports on the same machine. For example, you can run the website for http://www.example.com and http://www.anotherexample.com on the same Web server using virtual hosts. This option corresponds to the directive for the default virtual host and IP-based virtual hosts. It corresponds to the directive
for a name-based virtual host.
The directives set for a virtual host only apply to that particular virtual host. If a directive is set server-wide and not defined within the virtual host settings, the default setting is used.
For example, you can define a Webmaster email address and not define individual email addresses for each virtual host.
Set the DocumentRoot directive to the directory that contains the root document (such as index.html) for the virtual host. The default DocumentRoot is /var/www.
The ServerAdmin directive within the VirtualHost stanza is email the address used in the footer of error pages if you choose to show a footer with an email address on the error pages.

10.2.4. Server Settings

This section explains how to configure basic server settings.
LockFile - The LockFile directive sets the path to the lockfile used when the
server is compiled with either USE_FCNTL_SERIALIZED_ACCEPT or
USE_FLOCK_SERIALIZED_ACCEPT. It must be stored on the local disk. It should be
left to the default value unless the logs directory is located on an NFS share. If this is the case, the default value should be changed to a location on the local disk and to a directory that is readable only by root.
PidFile - The PidFile directive sets the file in which the server records its process ID (pid).
This file should only be readable by root. In most cases, it should be left to the default value.
User - The User directive sets the userid used by the server to answer requests. This setting determines the server's access. Any files inaccessible to this user will also be inaccessible to your website's visitors. The default value for User is www-data.
Unless you know exactly what you are doing, do not set the User directive to
root. Using root as the User will create large security holes for your Web server.
The Group directive is similar to the User directive. Group sets the group under which the server will answer requests. The default group is also www-data.

10.2.5. Apache Modules

Apache is a modular server. This implies that only the most basic functionality is included in the core server. Extended features are available through modules which can be loaded into Apache. By default, a base set of modules is included in the server at compile-time. If
the server is compiled to use dynamically loaded modules, then modules can be compiled separately, and added at any time using the LoadModule directive. Otherwise, Apache must be recompiled to add or remove modules. Ubuntu compiles Apache2 to allow the dynamic loading of modules. Configuration directives may be conditionally included on the presence of a particular module by enclosing them in an block. You can install additional Apache2 modules and use them with your Web server. You can install Apache2 modules using the apt-get command. For example, to install the Apache2 module for MYSQL authentication, you can run the following command from a terminal prompt:

Once you install the module, the module will be available in the
/etc/apache2/mods-available directory. You can use the a2enmod command to enable a module. You can use the a2dismod command to disable a module. Once you enable the module, the module will be available in the the /etc/apache2/mods-enabled directory.

10.3. HTTPS Configuration

The mod_ssl module adds an important feature to the Apache2 server - the ability
to encrypt communications. Thus, when your browser is communicating using SSL
encryption, the https:// prefix is used at the beginning of the Uniform Resource Locator (URL) in the browser navigation bar.
The mod_ssl module is available in apache2-common package. If you have installed
this package, you can run the following command from a terminal prompt to enable the mod_ssl module:

10.3.1. Certificates and Security

To set up your secure server, use public key cryptography to create a public and private key pair. In most cases, you send your certificate request (including your public key), proof of your company's identity, and payment to a Certificate Authority (CA). The CA verifies the certificate request and your identity, and then sends back a certificate for your secure server.
Alternatively, you can create your own self-signed certificate. Note, however, that
self-signed certificates should not be used in most production environments. Self-signed certificates are not automatically accepted by a user's browser. Users are prompted by the browser to accept the certificate and create the secure connection.
Once you have a self-signed certificate or a signed certificate from the CA of your choice, you need to install it on your secure server.

10.3.2. Types of Certificates

You need a key and a certificate to operate your secure server, which means that you can either generate a self-signed certificate or purchase a CA-signed certificate. A CA-signed certificate provides two important capabilities for your server:
• Browsers (usually) automatically recognize the certificate and allow a secure connection to be made without prompting the user.
• When a CA issues a signed certificate, it is guaranteeing the identity of the organization that is providing the web pages to the browser.
Most Web browsers that support SSL have a list of CAs whose certificates they
automatically accept. If a browser encounters a certificate whose authorizing CA is not in the list, the browser asks the user to either accept or decline the connection.
You can generate a self-signed certificate for your secure server, but be aware that a self-signed certificate does not provide the same functionality as a CA-signed certificate.
A self-signed certificate is not automatically recognized by most Web browsers, and
a self-signed certificate does not provide any guarantee concerning the identity of the organization that is providing the website. A CA-signed certificate provides both of these important capabilities for a secure server. The process of getting a certificate from a CA is fairly easy. A quick overview is as follows:
1. Create a private and public encryption key pair.
2. Create a certificate request based on the public key. The certificate request contains information about your server and the company hosting it.
3. Send the certificate request, along with documents proving your identity, to a CA. We cannot tell you which certificate authority to choose. Your decision may be based on your past experiences, or on the experiences of your friends or colleagues, or purely on monetary factors.
Once you have decided upon a CA, you need to follow the instructions they provide on how to obtain a certificate from them.
4. When the CA is satisfied that you are indeed who you claim to be, they send you a digital certificate.

5. Install this certificate on your secure server, and begin handling secure transactions.
Whether you are getting a certificate from a CA or generating your own self-signed
certificate, the first step is to generate a key.

10.3.3. Generating a Certificate Signing Request (CSR)
To generate the Certificate Signing Request (CSR), you should create your own key. You can run the following command from a terminal prompt to create the key:

openssl genrsa -des3 -out server.key 1024
Generating RSA private key, 1024 bit long modulus
.....................++++++
.................++++++
unable to write 'random state'
e is 65537 (0x10001)
Enter pass phrase for server.key:
You can now enter your passphrase. For best security, it should at least contain eight characters. The minimum length when specifying -des3 is four characters. It should include numbers and/or punctuation and not be a word in a dictionary. Also remember that your passphrase is case-sensitive.
Re-type the passphrase to verify. Once you have re-typed it correctly, the server key is generated and stored in server.key file.
You can also run your secure web server without a passphrase. This is convenient
because you will not need to enter the passphrase every time you start your
secure web server. But it is highly insecure and a compromise of the key means a
compromise of the server as well.
In any case, you can choose to run your secure web server without a passphrase by leaving out the -des3 switch in the generation phase or by issuing the following command at a terminal prompt:
openssl rsa -in server.key -out server.key.insecure
Once you run the above command, the insecure key will be stored in the
server.key.insecure file. You can use this file to generate the CSR without passphrase.
To create the CSR, run the following command at a terminal prompt:
openssl req -new -key server.key -out server.csr
It will prompt you enter the passphrase. If you enter the correct passphrase, it will prompt you to enter Company Name, Site Name, Email Id, etc. Once you enter all these details,your CSR will be created and it will be stored in the server.csr file. You can submit this CSR file to a CA for processing. The CAN will use this CSR file and issue the certificate.
On the other hand, you can create self-signed certificate using this CSR.
10.3.4. Creating a Self-Signed Certificate
To create the self-signed certificate, run the following command at a terminal prompt:
openssl x509 -req -days 365 -in server.csr -signkey server.key -out server.crt

The above command will prompt you to enter the passphrase. Once you enter the correct passphrase, your certificate will be created and it will be stored in the server.crt file.
If your secure server is to be used in a production environment, you probably
need a CA-signed certificate. It is not recommended to use self-signed certificate.
10.3.5. Installing the Certificate
You can install the key file server.key and certificate file server.crt or the certificate
file issued by your CA by running following commands at a terminal prompt:

You should add the following four lines to the /etc/apache2/sites-available/default
file or the configuration file for your secure virtual host. You should place them in the
VirtualHost section. They should be placed under the DocumentRoot line:
SSLEngine on SSLOptions +FakeBasicAuth +ExportCertData +CompatEnvVars +StrictRequire SSLCertificateFile /etc/ssl/certs/server.crt
SSLCertificateKeyFile /etc/ssl/private/server.key
HTTPS should listen on port number 443. You should add the following line to the
/etc/apache2/ports.conf file:
Listen 443

10.3.6. Accessing the Server

Once you install your certificate, you should restart your web server. You can run the following command at a terminal prompt to restart your web server:

You should remember and enter the passphrase every time you start your secure
web server.
You will be prompted to enter the passphrase. Once you enter the correct passphrase, the secure web server will be started. You can access the secure server pages by typing https://your_hostname/url/ in your browser address bar.

References
Apache2 Documentation [http://httpd.apache.org/docs/2.0/]

Mod SSL Documentation [http://www.modssl.org/docs/]

11. Squid - Proxy Server

Squid is a full-featured web proxy cache server application which provides proxy and
cache services for Hyper Text Transport Protocol (HTTP), File Transfer Protocol (FTP),and other popular network protocols. Squid can implement caching and proxying of Secure Sockets Layer (SSL) requests and caching of Domain Name Server (DNS) lookups, and perform transparent caching. Squid also supports a wide variety of caching protocols, such as Internet Cache Protocol, (ICP) the Hyper Text Caching Protocol, (HTCP) the Cache Array Routing Protocol (CARP), and the Web Cache Coordination Protocol. (WCCP)
The Squid proxy cache server is an excellent solution to a variety of proxy and caching server needs, and scales from the branch office to enterprise level networks while providing extensive, granular access control mechanisms and monitoring of critical parameters via the Simple Network Management Protocol (SNMP). When selecting a computer system for use as a dedicated Squid proxy, or caching servers, ensure your system is configured with a large amount of physical memory, as Squid maintains an in-memory cache for increased performance.

11.1. Installation

At a terminal prompt, enter the following command to install the Squid server:
sudo apt-get install squid squid-common

11.2. Configuration
Squid is configured by editing the directives contained within the /etc/squid/squid.conf configuration file. The following examples illustrate some of the directives which may be modified to affect the behavior of the Squid server. For more in-depth configuration of Squid, see the References section.
Prior to editing the configuration file, you should make a copy of the original file
and protect it from writing so you will have the original settings as a reference,
and to re-use as necessary.
Copy the /etc/squid/squid.conf file and protect it from writing with the
following commands entered at a terminal prompt:
sudo cp /etc/squid/squid.conf /etc/squid/squid.conf.original
sudo chmod a-w /etc/squid/squid.conf.original
• To set your Squid server to listen on TCP port 8888 instead of the default TCP port
3128, change the http_port directive as such:
http_port 8888

• Change the visible_hostname directive in order to give the Squid server a specific
hostname. This hostname does not necessarily need to be the computer's hostname. In this example it is set to weezie visible_hostname weezie
• Again, Using Squid's access control, you may configure use of Internet services proxied by Squid to be available only users with certain Internet Protocol (IP) addresses. For example, we willll illustrate access by users of the 192.168.42.0/24 subnetwork only:
Add the following to the bottom of the ACL section of your /etc/squid/squid.conf
file:
acl fortytwo_network src 192.168.42.0/24
Then, add the following to the top of the http_access section of your
/etc/squid/squid.conf file:
http_access allow fortytwo_network
• Using the excellent access control features of Squid, you may configure use of Internet services proxied by Squid to be available only during normal business hours. For example, we'll illustrate access by employees of a business which is operating between 9:00AM and 5:00PM, Monday through Friday, and which uses the 10.1.42.0/42 subnetwork:
Add the following to the bottom of the ACL section of your /etc/squid/squid.conf
file:
acl biz_network src 10.1.42.0/24 acl biz_hours time M T W T F 9:00-17:00
Then, add the following to the top of the http_access section of your
/etc/squid/squid.conf file:
http_access allow biz_network biz_hours
After making changes to the /etc/squid/squid.conf file, save the file and
restart the squid server application to effect the changes using the following
command entered at a terminal prompt:

Squid Website [http://www.squid-cache.org/]

12. Version Control System

Version control is the art of managing changes to information. It has long been a critical tool for programmers, who typically spend their time making small changes to software and then undoing those changes the next day. But the usefulness of version control software extends far beyond the bounds of the software development world. Anywhere you can find people using computers to manage information that changes often, there is room for version control.

12.1. Subversion

Subversion is an open source version control system. Using Subversion, you can record the history of source files and documents. It manages files and directories over time. A tree of files is placed into a central repository. The repository is much like an ordinary file server, except that it remembers every change ever made to files and directories.

12.1.1. Installation

To access Subversion repository using the HTTP protocol, you must install and configure
a web server. Apache2 is proven to work with Subversion. Please refer to the HTTP
subsection in the Apache2 section to install and configure Apache2. To access the
Subversion repository using the HTTPS protocol, you must install and configure a digital certificate in your Apache 2 web server. Please refer to the HTTPS subsection in the
Apache2 section to install and configure the digital certificate.
To install Subversion, run the following command from a terminal prompt:
sudo apt-get install subversion libapache2-svn

12.1.2. Server Configuration

This step assumes you have installed above mentioned packages on your system. This section explains how to create a Subversion repository and access the project.

12.1.2.1. Create Subversion Repository

The Subversion repository can be created using the following command from a terminal
prompt:
svnadmin create /path/to/repos/project
12.1.3. Access Methods
Subversion repositories can be accessed (checked out) through many different methods
--on local disk, or through various network protocols. A repository location, however, isalways a URL. The table describes how different URL schemas map to the available access methods.
Table 4.1. Access Methods
Schema
Access Method
file://direct repository access (on local disk)
http://Access via WebDAV protocol to
Subversion-aware Apache2 web server
https://Same as http://, but with SSL encryption
svn://Access via custom protocol to an svnserve
server
svn+ssh://Same as svn://, but through an SSH tunnel
In this section, we will see how to configure Subversion for all these access methods.
Here, we cover the basics. For more advanced usage details, refer to the svn book
[http://svnbook.red-bean.com/].

12.1.3.1. Direct repository access (file://)

This is the simplest of all access methods. It does not require any Subversion server
process to be running. This access method is used to access Subversion from the same machine. The syntax of the command, entered at a terminal prompt, is as follows:
svn co file:///path/to/repos/project
or svn co file://localhost/path/to/repos/project
If you do not specify the hostname, there are three forward slashes (///) -- two for
the protocol (file, in this case) plus the leading slash in the path. If you specify the
hostname, you must use two forward slashes (//).
The repository permissions depend on filesystem permissions. If the user has read/write permission, he can checkout from and commit to the repository.

12.1.3.2. Access via WebDAV protocol (http://)

To access the Subversion repository via WebDAV protocol, you must configure
your Apache 2 web server. You must add the following snippet in your
/etc/apache2/apache2.conf file:

DAV svn
SVNPath /path/to/repos
AuthType Basic
AuthName "Your repository name"
AuthUserFile /etc/subversion/passwd

Require valid-user

Next, you must create the /et