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 <IfModule> 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:
sudo apt-get install libapache2-mod-auth-mysql
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:
sudo a2enmod ssl
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:
sudo cp server.crt /etc/ssl/certs
sudo cp server.key /etc/ssl/private
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:
sudo /etc/init.d/apache2 restart
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.
10.4. 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:
sudo /etc/init.d/squid restart
11.3. References
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, is
always 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:
<Location /svn>
DAV svn
SVNPath /path/to/repos
AuthType Basic
AuthName "Your repository name"
AuthUserFile /etc/subversion/passwd
<LimitExcept GET PROPFIND OPTIONS REPORT>
Require valid-user
</LimitExcept>
</Location>
Next, you must create the /etc/subversion/passwd file. This file contains user
authentication details. To add an entry, i.e. to add a user, you can run the following
command from a terminal prompt:
htpasswd2 /etc/subversion/passwd user_name
This command will prompt you to enter the password. Once you enter the password, the
user is added. Now, to access the repository you can run the following command:
svn co http://servername/svn
The password is transmitted as plain text. If you are worried about password
snooping, you are advised to use SSL encryption. For details, please refer next
section.
12.1.3.3. Access via WebDAV protocol with SSL encryption (https://)
Accessing Subversion repository via WebDAV protocol with SSL encryption (https://) is
similar to http:// except that you must install and configure the digital certificate in your
Apache2 web server.
You can install a digital certificate issued by a signing authority like Verisign.
Alternatively, you can install your own self-signed certificate.
This step assumes you have installed and configured a digital certificate in your Apache
2 web server. Now, to access the Subversion repository, please refer to the above section!
The access methods are exactly the same, except the protocol. You must use https:// to
access the Subversion repository.
12.1.3.4. Access via custom protocol (svn://)
Once the Subversion repository is created, you can configure the access control. You can
edit the /path/to/repos/project/conf/svnserve.conf file to configure the access
control. For example, to set up authentication, you can uncomment the following lines in
the configuration file:
# [general]
# password-db = passwd
After uncommenting the above lines, you can maintain the user list in the passwd file. So,
edit the file passwd in the same directory and add the new user. The syntax is as follows:
username = password
For more details, please refer to the file.
Now, to access Subversion via the svn:// custom protocol, either from the same machine
or a different machine, you can run svnserver using svnserve command. The syntax is as
follows:
$ svnserve -d --foreground -r /path/to/repos
# -d -- daemon mode
# --foreground -- run in foreground (useful for debugging)
# -r -- root of directory to serve
For more usage details, please refer to:
$ svnserve --help
Once you run this command, Subversion starts listening on default port (3690). To access
the project repository, you must run the following command from a terminal prompt:
svn co svn://hostname/project project --username user_name
Based on server configuration, it prompts for password. Once you are authenticated, it
checks out the code from Subversion repository. To synchronize the project repository with
the local copy, you can run the update sub-command. The syntax of the command, entered
at a terminal prompt, is as follows:
cd project_dir ; svn update
For more details about using each Subversion sub-command, you can refer to the manual.
For example, to learn more about the co (checkout) command, please run the following
command from a terminal prompt:
svn co help
12.1.3.5. Access via custom protocol with SSL encryption (svn+ssh://)
The configuration and server process is same as in the svn:// method. For details, please
refer to the above section. This step assumes you have followed the above step and started
the#Subversion server using svnserve command.
It is also assumed that the ssh server is running on that machine and that it is allowing
incoming connections. To confirm, please try to login to that machine using ssh. If you can
login, everything is perfect. If you cannot login, please address it before continuing further.
The svn+ssh:// protocol is used to access the Subversion repository using SSL encryption.
The data transfer is encrypted using this method. To access the project repository (for
example with a checkout), you must use the following command syntax:
svn co svn+ssh://hostname/var/svn/repos/project
You must use the full path (/path/to/repos/project) to access the Subversion
repository using this access method.
Based on server configuration, it prompts for password. You must enter the password you
use to login via ssh. Once you are authenticated, it checks out the code from the Subversion
repository.
12.2. CVS Server
CVS is a version control system. You can use it to record the history of source files.
12.2.1. Installation
At a terminal prompt, enter the following command to install cvs:
sudo apt-get install cvs
After you install cvs, you should install xinetd to start/stop the cvs server. At the prompt,
enter the following command to install xinetd:
sudo apt-get install xinetd
12.2.2. Configuration
Once you install cvs, the repository will be automatically initialized. By default, the
repository resides under the /var/lib/cvs directory. You can change this path by running
following command:
cvs -d /your/new/cvs/repo init
Once the initial repository is set up, you can configure xinetd to start the CVS server. You
can copy the following lines to the /etc/xinetd/cvspserver file.
service cvspserver
{
port = 2401
socket_type = stream
protocol = tcp
user = root
wait = no
type = UNLISTED
server = /usr/bin/cvs
server_args = -f --allow-root /var/lib/cvs pserver
disable = no
}
Be sure to edit the repository if you have changed the default repository
(/var/lib/cvs) directory.
Once you have configured xinetd you can start the cvs server by running following
command:
sudo /etc/init.d/xinetd start
You can confirm that the CVS server is running by issuing the following command:
sudo netstat -tap | grep cvs
When you run this command, you should see the following line or something similar:
tcp 0 0 *:cvspserver *:* LISTEN
From here you can continue to add users, add new projects, and manage the CVS server.
CVS allows the user to add users independently of the underlying OS installation.
Probably the easiest way is to use the Linux Users for CVS, although it has
potential security issues. Please refer to the CVS manual for details.
12.2.3. Add Projects
This section explains how to add new project to the CVS repository. Create the directory
and add necessary document and source files to the directory. Now, run the following
command to add this project to CVS repository:
cd your/project
cvs import -d :pserver:username@hostname.com:/var/lib/cvs -m "Importing my project to CVS repository" . new_project start
0 comments:
Post a Comment