Ubuntu 9.10 Server Installation Guide

Preparing to Install

This section explains various aspects to consider before starting the installation.

System Requirements

Ubuntu 9.10 Server Edition supports two (2) major architectures: Intel x86 and AMD64. The table below lists recommended hardware specifications. Depending on your needs, you might manage with less than this. However, most users risk being frustrated if they ignore these suggestions.

Table 2.1. Recommended Minimum Requirements

Install Type RAM Base
System Space		 All Tasks Installed
Space
Server 128 megabytes 500
megabytes		 1 gigabyte

The Server Edition provides a common base for all sorts of server applications. It is a minimalist design providing a platform for the desired services, such as file/print services, web hosting, email hosting, etc.

Server and Desktop Differences

There are a few differences between the Ubuntu Server Edition and the Ubuntu Desktop Edition. It should be noted that both editions use the same apt repositories. Making it just as easy to install a server application on the Desktop Edition as it is on the Server Edition.

The differences between the two editions are the lack of an X window environment in the Server Edition, the installation process, and different Kernel options.

Kernel Differences:

  • The Server Edition uses the Deadline I/O scheduler instead of the CFQ scheduler used by the Desktop Edition.
  • Preemption is turned off in the Server Edition.
  • The timer interrupt is 100 Hz in the Server Edition and 250 Hz in the Desktop Edition.
Note: When running a 64-bit version of Ubuntu on 64-bit processors you are not limited by memory addressing space.

To see all kernel configuration options you can look through /boot/config-2.6.31-server. Also, Linux Kernel in a Nutshell is a great resource on the options available.

Backing Up

Before installing Ubuntu Server Edition you should make sure all data on the system is backed up.  re-partition your disk to make room for Ubuntu.

Any time you partition your disk, you should be prepared to lose everything on the disk should you make a mistake or something goes wrong during partitioning. The programs used in installation are quite reliable, most have seen years of use, but they also perform destructive actions.

Installing from CD

The basic steps to install Ubuntu Server Edition from CD are the same for installing any operating system from CD. Unlike the Desktop Edition the Server Edition does not include a graphical installation program. Instead the Server Edition uses a console menu based process.

Note: If at any point during installation you are not satisfied by the default setting, use the "Go Back" function at any prompt to be brought to a detailed installation menu that will allow you to modify the default settings.

At some point during the installation process you may want to read the help screen provided by the installation system. To do this, press F1.

  • First, download and burn the appropriate ISO file from the Ubuntu web site.
  • Boot the system from the CD-ROM drive.
  • At the boot prompt you will be asked to select the language. Afterwards the installation process begins by asking for your keyboard layout.
  • The installer then discovers your hardware configuration, and configures the network settings using DHCP. If you do not wish to use DHCP at the next screen choose "Go Back", and you have the option to "Configure the network manually".
  • Next, the installer asks for the system's hostname and Time Zone.
  • You can then choose from several options to configure the hard drive layout. For advanced disk options see the section called “Advanced Installation”.
  • The Ubuntu base system is then installed.
  • A new user is setup, this user will have root access through the sudo utility.
  • After the user is setup, you will be asked to encrypt your home directory.
  • The next step in the installation process is to decide how you want to update the system. There are three options:
    • No automatic updates: this requires an administrator to log into the machine and manually install updates.
    • Install security updates Automatically: will install the unattended-upgrades package, which will install security updates without the intervention of an administrator. For more details see the section called “Automatic Updates”.
    • Manage the system with Landscape: Landscape is a paid service provided by Canonical to help manage your Ubuntu machines. See the Landscape site for details.
  • You now have the option to install, or not install, several package tasks. See the section called “Package Tasks” for details. Also, there is an option to launch aptitude to choose specific packages to install. For more information see the section called "Aptitude".
  • Finally, the last step before rebooting is to set the clock to UTC.

Package Tasks

During the Server Edition installation you have the option of installing additional packages from the CD. The packages are grouped by the type of service they provide.

  • DNS server: Selects the BIND DNS server and its documentation.
  • LAMP server: Selects a ready-made Linux/Apache/MySQL/PHP server.
  • Mail server: This task selects a variety of package useful for a general purpose mail server system.
  • OpenSSH server: Selects packages needed for an OpenSSH server.
  • PostgreSQL database: This task selects client and server packages for the PostgreSQL database.
  • Print server: This task sets up your system to be a print server.
  • Samba File server: This task sets up your system to be a Samba file server, which is especially suitable in networks with both Windows and Linux systems.
  • Tomcat server: Installs the Apache Tomcat and needed dependencies Java, gcj, etc.
  • Virtual machine host: Includes packages needed to run KVM virtual machines.

Installing the package groups is accomplished using the tasksel utility. One of the important difference between Ubuntu (or Debian) and other GNU/Linux distribution is that, when installed, a package is also configured to reasonable defaults, eventually prompting you for additional required information. Likewise, when installing a task, the packages are not only installed, but also configured to provided a fully integrated service.

Once the installation process has finished you can view a list of available tasks by entering the following from a terminal prompt:

tasksel --list-tasks

Note: The output will list tasks from other Ubuntu based distributions such as Kubuntu and Edubuntu. Note that you can also invoke the tasksel command by itself, which will bring up a menu of the different tasks available.

You can view a list of which packages are installed with each task using the --task-packages option. For example, to list the packages installed with the DNS Server task enter the following:

tasksel --task-packages dns-server

The output of the command should list:

bind9-doc
bind9utils
bind9

Also, if you did not install one of the tasks during the installation process, but for example you decide to make your new LAMP server a DNS server as well. Simply insert the installation CD and from a terminal:

sudo tasksel install dns-server

Upgrading 

There are several ways to upgrade from one Ubuntu release to another. This section gives an overview of the recommended upgrade method.

do-release-upgrade

The recommended way to upgrade a Server Edition installation is to use the do-release-upgrade utility. Part of the updatemanager-core package, it does not have any graphical dependencies and is installed by default.

Debian based systems can also be upgraded by using apt-get dist-upgrade. However, using do-release-upgrade is recommended because it has the ability to handle system configuration changes sometimes needed between releases.

To upgrade to a newer release, from a terminal prompt enter:

do-release-upgrade

It is also possible to use do-release-upgrade to upgrade to a development version of Ubuntu. To accomplish this use the -dswitch: 

do-release-upgrade -d

Advanced Installation

Software RAID
RAID is a method of configuring multiple hard drives to act as one, reducing the probability of catastrophic data loss in case of drive failure. RAID is implemented in either software (where the operating system knows about both drives and actively maintains both of them) or hardware (where a special controller makes the OS think there's only one drive and maintains the drives 'invisibly').

The RAID software included with current versions of Linux (and Ubuntu) is based on the 'mdadm' driver and works very well, better even than many so-called 'hardware' RAID controllers. This section will guide you through installing Ubuntu Server Edition using two RAID1 partitions on two physical hard drives, one for / and another for swap.

Partitioning

Follow the installation steps until you get to the Partition disks step, then:

  1. Select Manual as the 1. partition method.
  2. Select the first hard drive, and agree to "Create a new empty partition table on this device?".
    Repeat this step for each drive you wish to be part of the RAID array.
  3. Select the "FREE SPACE" on the first drive then select "Create a new partition".
  4. Next, select the Size of the partition. This partition will be the swap partition, and a general rule for swap size is twice that of RAM. Enter the partition size, then choose Primary, then Beginning.
  5. Select the "Use as:" line at the top. By default this is "Ext3 journaling file system", change that to "physical volume for RAID" then "Done setting up partition".
  6. For the / partition once again select "Free Space" on the first drive then "Create a new partition".
  7. Use the rest of the free space on the drive and choose Continue, then Primary.
  8. As with the swap partition, select the "Use as:" line at the top, changing it to "physical volume for RAID" then choose "Done setting up partition".
  9. Repeat steps three through eight for the other disk and partitions.

RAID Configuration

With the partitions setup the arrays are ready to be configured:

  1. Back in the main "Partition Disks" page, select "Configure Software RAID" at the top.
  2. Select "yes" to write the changes to disk.
  3. Choose "Create MD drive".
  4. For this example, select "RAID1", but if you are using a different setup choose the appropriate type (RAID0 RAID1 RAID5).
  5. In order to use RAID5 you need at least three drives. Using RAID0 or RAID1 only two drives are required.
  6. Enter the number of active devices "2", or the amount of hard drives you have, for the array. Then select "Continue".
  7. Next, enter the number of spare devices "0" by default, then choose "Continue".
  8. Choose which partitions to use. Generally they will be sda1, sdb1, sdc1, etc. The numbers will usually match and the different letters correspond to different hard drives. For the swap partition choose sda1 and sdb1. Select "Continue" to go to the next step.
  9. Repeat steps three through seven for the / partition choosing 8. sda2 and sdb2.
  10. Once done select "Finish".

Formatting

There should now be a list of hard drives and RAID devices. The next step is to format and set the mount point for the RAID devices. Treat the RAID device as a local hard drive, format and mount accordingly.

  1. Select the RAID1 device #0 partition.
  2. Choose "Use as:". Then select "swap area", then "Done setting up partition".
  3. Next, select the RAID1 device #1 partition.
  4. Choose "Use as:". Then select "Ext3 journaling file system".
  5. Then select the "Mount point" and choose "/ - the root file system". Change any of the other options as appropriate, then select "Done setting up partition".
  6. Finally, select "Finish partitioning and write changes to disk".

If you choose to place the root partition on a RAID array, the installer will then ask if you would like to boot in a degraded state. See the section called “Degraded RAID” for further details.

The installation process will then continue normally.

Degraded RAID

At some point in the life of the computer a disk failure event may occur. When this happens, using Software RAID, the operating system will place the array into what is known as a degraded state. If the array has become degraded, due to the chance of data corruption, by default Ubuntu Server Edition will boot to initramfs after thirty seconds. Once the initramfs has booted there is a fifteen second prompt giving you the option to go ahead and boot the system, or attempt manual recover. Booting to the initramfs prompt may or may not be the desired behavior, especially if the machine is in a remote location. Booting to a degraded array can be configured several ways:Degraded RAID At some point in the life of the computer a disk failure event may occur. When this happens, using Software RAID, the operating system will place the array into what is known as a degraded state.

If the array has become degraded, due to the chance of data corruption, by default Ubuntu Server Edition will boot to initramfs after thirty seconds. Once the initramfs has booted there is a fifteen second prompt giving you the option to go ahead and boot the system, or attempt manual recover. Booting to the initramfs prompt may or may not be the desired behavior, especially if the machine is in a remote location. Booting to a degraded array can be configured several ways:

  • The dpkg-reconfigure utility can be used to configure the default behavior, and during the process you will be queried about additional settings related to the array. Such as monitoring, email alerts, etc. To reconfigure mdadm enter the following:

    sudo dpkg-reconfigure mdadm

  • The dpkg-reconfigure mdadm process will change the /etc/initramfs-tools/conf.d/mdadm configuration file. The file has the advantage of being able to pre-configure the system's behavior, and can also be manually edited:

    BOOT_DEGRADED=true

    The configuration file can be overridden by using a Kernel argument.

  • Using a Kernel argument will allow the system to boot to a degraded array as well:
    • When the server is booting press ESC to open the Grub menu.
    • Press "e" to edit your Kernel command options.
    • Press the DOWN arrow to highlight the kernel line.
    • Press the "e" key again to edit the kernel line.
    • Add "bootdegraded=true" (without the quotes) to the end of the line.
    • Press "ENTER".
    • Finally, press "b" to boot the system.

Once the system has booted you can either repair the array see the section called "RAID Maintenance" for details, or copy important data to another machine due to major hardware failure.

RAID Maintenance

The mdadm utility can be used to view the status of an array, add disks to an array, remove disks, etc:

  • To view the status of an array, from a terminal prompt enter:

    sudo mdadm -D /dev/md0

    The -D tells mdadm to display detailed information about the /dev/md0 device. Replace /dev/md0 with the appropriate RAID device.

  • To view the status of a disk in an array:

    sudo mdadm -E /dev/sda1

    The output if very similar to the mdadm -D command, adjust /dev/sda1 for each disk.

  • If a disk fails and needs to be removed from an array enter:

    sudo mdadm --remove /dev/md0 /dev/sda1

    Change /dev/md0 and /dev/sda1 to the appropriate RAID device and disk.

  • Similarly, to add a new disk:

    sudo mdadm --add /dev/md0 /dev/sda1

Sometimes a disk can change to a faulty state even though there is nothing physically wrong with the drive. It is usually worthwhile to remove the drive from the array then re-add it. This will cause the drive to re-sync with the array. If the drive will not sync with the array, it is a good indication of hardware failure.

The /proc/mdstat file also contains useful information about the system's RAID devices:

cat /proc/mdstat Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10] md0 : active raid1 sda1[0] sdb1[1] 10016384 blocks [2/2] [UU] unused devices:

The following command is great for watching the status of a syncing drive:

watch -n1 cat /proc/mdstat

Press Ctrl+c to stop the watch command.

If you do need to replace a faulty drive, after the drive has been replaced and synced, grub will need to be installed. To install grub on the new drive, enter the following:

sudo grub-install /dev/md0

Replace /dev/md0 with the appropriate array device name.

Resources

The topic of RAID arrays is a complex one due to the plethora of ways RAID can be configured. Please see the following links for more information:

  • Software RAID HOWTO
  • Managing RAID on Linux

Logical Volume Manager (LVM)

Logical Volume Manger, or LVM, allows administrators to create logical volumes out of one or multiple physical hard disks.

LVM volumes can be created on both software RAID partitions and standard partitions residing on a single disk. Volumes can also be extended, giving greater flexibility to systems as requirements change.

Overview

A side effect of LVM's power and flexibility is a greater degree of complication. Before diving into the LVM installation process, it is best to get familiar with some terms.

  • Volume Group (VG): contains one or several Logical Volumes (LV).
  • Logical Volume (LV): is similar to a partition in a non-LVM system. Multiple Physical Volumes (PV) can make up one LV, on top of which resides the actual EXT3, XFS, JFS, etc filesystem.
  • Physical Volume (PV): physical hard disk or software RAID partition. The Volume Group can be extended by adding more PVs.

Installation

As an example this section covers installing Ubuntu Server Edition with /srv mounted on a LVM volume. During the initial install only one Physical Volume (PV) will be part of the Volume Group (VG). Another PV will be added after install to demonstrate how a VG can be extended.

There are several installation options for LVM, "Guided - use the entire disk and setup LVM" which will also allow you to assign a portion of the available space to LVM, "Guided - use entire and setup encrypted LVM", or Manually setup the partitions and configure LVM. At this time the only way to configure a system with both LVM and standard partitions, during installation, is to use the Manual approach.

  • Follow the installation steps until you get to the Partition 1. disks step, then:
  • At the "Partition Disks screen choose "Manual".
  • Select the hard disk and on the next screen choose "yes" to "Create a new empty partition table on this device".
  • Next, create standard /boot, swap, and / partitions with whichever filesystem you prefer.
  • For the LVM /srv, create a new Logical partition. Then change "Use as" to "physical volume for LVM" then "Done setting up the partition".
  • Now select "Configure the Logical Volume Manager" at the top, and choose "Yes" to write the changes to disk.
  • For the "LVM configuration action" on the next screen, choose "Create volume group". Enter a name for the VG such as vg01, or something more descriptive. After entering a name, select the partition configured for LVM, and choose "Continue".
  • Back at the "LVM configuration action" screen, select "Create logical volume". Select the newly created volume group, and enter a name for the new LV, for example srv since that is the intended mount point. Then choose a size, which may be the full partition because it can always be extended later. Choose "Finish" and you should be back at the main "Partition Disks" screen.
  • Now add a filesystem to the new LVM. Select the partition under "LVM VG vg01, LV srv", or whatever name you have chosen, the choose Use as. Setup a file system as normal selecting /srv as the mount point. Once done, select "Done setting up the partition".
  • Finally, select "Finish partitioning and write changes to disk". Then confirm the changes and continue with the rest of the installation.

There are some useful utilities to view information about LVM:

  • vgdisplay: shows information about Volume Groups.
  • lvdisplay: has information about Logical Volumes.
  • pvdisplay: similarly displays information about Physical Volumes.

Extending Volume Groups

Continuing with srv as an LVM volume example, this section covers adding a second hard disk, creating a Physical Volume (PV), adding it to the volume group (VG), extending the logical volume srv and finally extending the filesystem. This example assumes a second hard disk has been added to the system. This hard disk will be named /dev/sdb in our example. BEWARE: make sure you don't already have an existing /dev/sdb before issuing the commands below. You could lose some data if you issue those commands on a non-empty disk. In our example we will use the entire disk as a physical volume (you could choose to create partitions and use them as different physical volumes)

  1. First, create the physical volume, in a terminal execute:

    sudo pvcreate /dev/sdb

  2. Now extend the Volume Group (VG):

    sudo vgextend vg01 /dev/sdb

  3. Use vgdisplay to find out the free physical extents - Free PE / size (the size you can allocate). We will assume a free size of 511 PE (equivalent to 2GB with a PE size of 4MB) and we will use the whole free space available. Use your own PE and/or free space.

    The Logical Volume (LV) can now be extended by different methods, we will only see how to use the PE to extend the LV:

    sudo lvextend /dev/vg01/srv -l +511

    The -l option allows the LV to be extended using PE. The -L option allows the LV to be extended using Meg, Gig, Tera, etc bytes.

  4. Even though you are supposed to be able to expand an ext3 or ext4 filesystem without unmounting it first, it may be a good pratice to unmount it anyway and check the filesystem, so that you don't mess up the day you want to reduce a logical volume (in that case unmounting first is compulsory).

    The following commands are for an EXT3 or EXT4 filesystem. If you are using another filesystem there may be other utilities available.

    sudo umount /srv
    sudo e2fsck -f /dev/vg01/srv

    The -f option of e2fsck forces checking even if the system seems clean.

  5. Finally, resize the filesystem:

    sudo resize2fs /dev/vg01/srv

  6. Now mount the partition and check its size.

    mount /dev/vg01/srv /srv && df -h /srv

Package Management

Ubuntu's package management system is derived from the same system used by the Debian GNU/Linux distribution. The package files contain all of the necessary files, meta-data, and instructions to implement a particular functionality or software application on your Ubuntu computer.

Debian package files typically have the extension '.deb', and typically exist in repositories which are collections of packages found on various media, such as CD-ROM discs, or online. Packages are normally of the pre-compiled binary format; thus installation is quick and requires no compiling of software.

Many complex packages use the concept of dependencies. Dependencies are additional packages required by the principal package in order to function properly. For example, the speech synthesis package Festival depends upon the package libasound2, which is a package supplying the ALSA sound library needed for audio playback. In order for Festival to function, it and all of its dependencies must be installed. The software management tools in Ubuntu will do this automatically.

dpkg

dpkg is a package manager for Debian based systems. It can install, remove, and build packages, but unlike other package management system's it can not automatically download and install packages and their dependencies. This section covers using dpkg to manage locally installed packages:

  • To list all packages installed on the system, from a terminal prompt enter:

    dpkg -l

  • Depending on the amount of packages on your system, this can generate a large amount of output. Pipe the output through grep to see if a specific package is installed:

    dpkg -l | grep apache2

    Replace apache2 with any package name, part of a package name, or other regular expression.

  • To list the files installed by a package, in this case the ufw package, enter:

    dpkg -L ufw

  • If you are not sure which package installed a file, dpkg -S may be able to tell you. For example:

    dpkg -S /etc/host.conf
    base-files: /etc/host.conf

    The output shows that the /etc/host.conf belongs to the base-files package.

    Many files are automatically generated during the package install process, and even though they are on the filesystem dpkg -S may not know which package they belong to.

  • You can install a local .deb file by entering:

    sudo dpkg -i zip_2.32-1_i386.deb

    Change zip_2.32-1_i386.deb to the actual file name of the local .deb file.

  • Uninstalling a package can be accomplished by:

    sudo dpkg -r zip

    Uninstalling packages using dpkg, in most cases, is NOT recommended. It is better to use a package manager that handles dependencies, to ensure that the system is in a consistent state. For example using dpkg -r you can remove the zip package, but any packages that depend on it will still be installed and may no longer function correctly.

For more dpkg options see the man page: man dpkg.

Network Configuration

Ubuntu ships with a number of graphical utilities to configure your network devices. This document is geared toward server administrators and will focus on managing your network on the command line.

Ethernet

Most Ethernet configuration is centralized in a single file, /etc/network/interfaces. If you have no Ethernet devices, only the loopback interface will appear in this file, and it will look something like this:

# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).
# The loopback network interface
auto lo
iface lo inet loopback
address 127.0.0.1
netmask 255.0.0.0

If you have only one Ethernet device, eth0, and it gets its configuration from a DHCP server, and it should come up automatically at boot, only two additional lines are required:

auto eth0
iface eth0 inet dhcp

The first line specifies that the eth0 device should come up automatically when you boot. The second line means that interface ("iface") eth0 should have an IPv4 address space (replace "inet" with "inet6" for an IPv6 device) and that it should get its configuration automatically from DHCP. Assuming your network and DHCP server are properly configured, this machine's network should need no further configuration to operate properly. The DHCP server will provide the default gateway (implemented via the route command), the device's IP address (implemented via the ifconfig command), and DNS servers used on the network (implemented in the /etc/resolv.conf file.)

To configure your Ethernet device with a static IP address and custom configuration, some more information will be required. Suppose you want to assign the IP address 192.168.0.2 to the device eth1, with the typical netmask of 255.255.255.0. Your default gateway's IP address is 192.168.0.1. You would enter something like this into /etc/network/interfaces:

iface eth1 inet static
address 192.168.0.2
netmask 255.255.255.0
gateway 192.168.0.1

In this case, you will need to specify your DNS servers manually in /etc/resolv.conf, which should look something like this:

search mydomain.example
nameserver 192.168.0.1
nameserver 4.2.2.2

The search directive will append mydomain.example to hostname queries in an attempt to resolve names to your network. For example, if your network's domain is mydomain.example and you try to ping the host "mybox", the DNS query will be modified to "mybox.mydomain.example" for resolution. The nameserver directives specify DNS servers to be used to resolve hostnames to IP addresses. If you use your own nameserver, enter it here. Otherwise, ask your Internet Service Provider for the primary and secondary DNS servers to use, and enter them into /etc/resolv.conf as shown above.

Many more configurations are possible, including dialup PPP interfaces, IPv6 networking, VPN devices, etc. Refer to man 5 interfaces for more information and supported options. Remember that /etc/network/interfaces is used by the ifup/ifdown scripts as a higher level configuration scheme than may be used in some other Linux distributions, and that the traditional, lower level utilities such as ifconfig, route, and dhclient are still available to you for ad hoc configurations.

Managing DNS Entries

This section explains how to configure which nameserver to use when resolving IP addresses to hostnames and vice versa. It does not explain how to configure the system as a name server.

To manage DNS entries, you can add, edit, or remove DNS names from the /etc/resolv.conf file. A sample file is given below:

search com
nameserver 204.11.126.131
nameserver 64.125.134.133
nameserver 64.125.134.132
nameserver 208.185.179.218

The search key specifies the string which will be appended to an incomplete hostname. Here, we have configured it to com. So, when we run: ping ubuntu it would be interpreted as ping ubuntu.com.

The nameserver key specifies the nameserver IP address. It will be used to resolve a given IP address or hostname. This file can have multiple nameserver entries. The nameservers will be used by the network query in the same order.

If the DNS server names are retrieved dynamically from DHCP or PPPoE (retrieved from your ISP), do not add nameserver entries in this file. It will be overwritten.

Managing Hosts

To manage hosts, you can add, edit, or remove hosts from /etc/hosts file. The file contains IP addresses and their corresponding hostnames. When your system tries to resolve a hostname to an IP address or determine the hostname for an IP address, it refers to the /etc/hosts file before using the name servers. If the IP address is listed in the /etc/hosts file, the name servers are not used. This behavior can be modified by editing /etc/nsswitch.conf at your peril.

If your network contains computers whose IP addresses are not listed in DNS, it is recommended that you add them to the /etc/hosts file.

Bridging

Bridging multiple interfaces is a more advanced configuration, but is very useful in multiple scenarios. One scenario is setting up a bridge with multiple network interfaces, then using a firewall to filter traffic between two network segments. Another scenario is using bridge on a system with one interface to allow virtual machines direct access to the outside network. The following example covers the latter scenario.

Before configuring a bridge you will need to install the bridge-utils package. To install the package, in a terminal enter:

sudo apt-get install bridge-utils

Next, configure the bridge by editing /etc/network/interfaces:

auto lo
iface lo inet loopback

auto br0
iface br0 inet static
address 192.168.0.10
network 192.168.0.0
netmask 255.255.255.0
broadcast 192.168.0.255
gateway 192.168.0.1
bridge_ports eth0
bridge_fd 9
bridge_hello 2
bridge_maxage 12
bridge_stp off

Enter the appropriate values for your physical interface and network.

Now restart networking to enable the bridge interface:

sudo /etc/init.d/networking restart

The new bridge interface should now be up and running. The brctl provides useful information about the state of the bridge, controls which interfaces are part of the bridge, etc. See man brctl for more information.

TCP/IP

The Transmission Control Protocol and Internet Protocol (TCP/IP) is a standard set of protocols developed in the late 1970s by the Defense Advanced Research Projects Agency (DARPA) as a means of communication between different types of computers and computer networks. TCP/IP is the driving force of the Internet, and thus it is the most popular set of network protocols on Earth.

TCP/IP Introduction

The two protocol components of TCP/IP deal with different aspects of computer networking. Internet Protocol, the "IP" of TCP/IP is a connectionless protocol which deals only with network packet routing using the IP Datagram as the basic unit of networking information. The IP Datagram consists of a header followed by a message. The Transmission Control Protocol is the "TCP" of TCP/IP and enables network hosts to establish connections which may be used to exchange data streams. TCP also guarantees that the data between connections is delivered and that it arrives at one network host in the same order as sent from another network host.

TCP/IP Configuration

The TCP/IP protocol configuration consists of several elements which must be set by editing the appropriate configuration files, or deploying solutions such as the Dynamic Host Configuration Protocol (DHCP) server which in turn, can be configured to provide the proper TCP/IP configuration settings to network clients automatically. These configuration values must be set correctly in order to facilitate the proper network operation of your Ubuntu system.

The common configuration elements of TCP/IP and their purposes are as follows:

  • IP address The IP address is a unique identifying string expressed as four decimal numbers ranging from zero (0) to two-hundred and fifty-five (255), separated by periods, with each of the four numbers representing eight (8) bits of the address for a total length of thirty-two (32) bits for the whole address. This format is called dotted quad notation.
  • Netmask The Subnet Mask (or simply, netmask) is a local bit mask, or set of flags which separate the portions of an IP address significant to the network from the bits significant to the subnetwork. For example, in a Class C network, the standard netmask is 255.255.255.0 which masks the first three bytes of the IP address and allows the last byte of the IP address to remain available for specifying hosts on the subnetwork.
  • Network Address The Network Address represents the bytes comprising the network portion of an IP address. For example, the host 12.128.1.2 in a Class A network would use 12.0.0.0 as the network address, where twelve (12) represents the first byte of the IP address, (the network part) and zeroes (0) in all of the remaining three bytes to represent the potential host values. A network host using the private IP address 192.168.1.100 would in turn use a Network Address of 192.168.1.0, which specifies the first three bytes of the Class C 192.168.1 network and a zero (0) for all the possible hosts on the network.
  • Broadcast Address The Broadcast Address is an IP address which allows network data to be sent simultaneously to all hosts on a given subnetwork rather than specifying a particular host. The standard general broadcast address for IP networks is 255.255.255.255, but this broadcast address cannot be used to send a broadcast message to every host on the Internet because routers block it. A more appropriate broadcast address is set to match a specific subnetwork. For example, on the private Class C IP network, 192.168.1.0, the broadcast address is 192.168.1.255. Broadcast messages are typically produced by network protocols such as the Address Resolution Protocol (ARP) and the Routing Information Protocol (RIP).
  • Gateway Address A Gateway Address is the IP address through which a particular network, or host on a network, may be reached. If one network host wishes to communicate with another network host, and that host is not located on the same network, then a gateway must be used. In many cases, the Gateway Address will be that of a router on the same network, which will in turn pass traffic on to other networks or hosts, such as Internet hosts. The value of the Gateway Address setting must be correct, or your system will not be able to reach any hosts beyond those on the same network.
  • Nameserver Address Nameserver Addresses represent the IP addresses of Domain Name Service (DNS) systems, which resolve network hostnames into IP addresses. There are three levels of Nameserver Addresses, which may be specified in order of precedence: The Primary Nameserver, the Secondary Nameserver, and the Tertiary Nameserver. In order for your system to be able to resolve network hostnames into their corresponding IP addresses, you must specify valid Nameserver Addresses which you are authorized to use in your system's TCP/IP configuration. In many cases these addresses can and will be provided by your network service provider, but many free and publicly accessible nameservers are available for use, such as the Level3 (Verizon) servers with IP addresses from 4.2.2.1 to 4.2.2.6.

The IP address, Netmask, Network Address, Broadcast Address, and Gateway Address are typically specified via the appropriate directives in the file /etc/network/interfaces. The Nameserver Addresses are typically specified via nameserver directives in the file /etc/resolv.conf. For more information, view the system manual page for interfaces or resolv.conf respectively, with the following commands typed at a terminal prompt:

Access the system manual page for interfaces with the following command:

man interfaces

Access the system manual page for resolv.conf with the following command:

man resolv.conf

IP Routing

IP routing is a means of specifying and discovering paths in a TCP/IP network along which network data may be sent. Routing uses a set of routing tables to direct the forwarding of network data packets from their source to the destination, often via many intermediary network nodes known as routers. There are two primary forms of IP routing: Static Routing and Dynamic Routing.

Static routing involves manually adding IP routes to the system's routing table, and this is usually done by manipulating the routing table with the route command. Static routing enjoys many advantages over dynamic routing, such as simplicity of implementation on smaller networks, predictability (the routing table is always computed in advance, and thus the route is precisely the same each time it is used), and low overhead on other routers and network links due to the lack of a dynamic routing protocol. However, static routing does present some disadvantages as well. For example, static routing is limited to small networks and does not scale well. Static routing also fails completely to adapt to network outages and failures along the route due to the fixed nature of the route.

Dynamic routing depends on large networks with multiple possible IP routes from a source to a destination and makes use of special routing protocols, such as the Router Information Protocol (RIP), which handle the automatic adjustments in routing tables that make dynamic routing possible. Dynamic routing has several advantages over static routing, such as superior scalability and the ability to adapt to failures and outages along network routes. Additionally, there is less manual configuration of the routing tables, since routers learn from one another about their existence and available routes. This trait also eliminates the possibility of introducing mistakes in the routing tables via human error. Dynamic routing is not perfect, however, and presents disadvantages such as heightened complexity and additional network overhead from router communications, which does not immediately benefit the end users, but still consumes network bandwidth.

TCP and UDP

TCP is a connection-based protocol, offering error correction and guaranteed delivery of data via what is known as flow control. Flow control determines when the flow of a data stream needs to be stopped, and previously sent data packets should to be re-sent due to problems such as collisions, for example, thus ensuring complete and accurate delivery of the data. TCP is typically used in the exchange of important information such as database transactions.

The User Datagram Protocol (UDP), on the other hand, is a connectionless protocol which seldom deals with the transmission of important data because it lacks flow control or any other method to ensure reliable delivery of the data. UDP is commonly used in such applications as audio and video streaming, where it is considerably faster than TCP due to the lack of error correction and flow control, and where the loss of a few packets is not generally catastrophic.

ICMP

The Internet Control Messaging Protocol (ICMP) is an extension to the Internet Protocol (IP) as defined in the Request For Comments (RFC) #792 and supports network packets containing control, error, and informational messages. ICMP is used by such network applications as the ping utility, which can determine the availability of a network host or device. Examples of some error messages returned by ICMP which are useful to both network hosts and devices such as routers, include Destination Unreachable and Time Exceeded.

Daemons

Daemons are special system applications which typically execute continuously in the background and await requests for the functions they provide from other applications. Many daemons are network-centric; that is, a large number of daemons executing in the background on an Ubuntu system may provide network-related functionality. Some examples of such network daemons include the Hyper Text Transport Protocol Daemon (httpd), which provides web server functionality; the Secure SHell Daemon (sshd), which provides secure remote login shell and file transfer capabilities; and the Internet Message Access Protocol Daemon (imapd), which provides E-Mail services.

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 "first come, first served" 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.

Installation

At a terminal prompt, enter the following command to install dhcpd:

sudo apt-get install dhcp3-server

You will probably need to change the default configuration by editing /etc/dhcp3/dhcpd.conf to suit your needs and particular configuration.

NOTE: dhcpd's messages are being sent to syslog. Look there for diagnostics messages.

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.example";
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 (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;

Time Synchronisation with NTP

This section describes methods for keeping your computer's time accurate. This is useful for servers, but is not necessary (or desirable) for desktop machines.

NTP is a TCP/IP protocol for synchronising time over a network. Basically a client requests the current time from a server, and uses it to set its own clock.

Behind this simple description, there is a lot of complexity - there are tiers of NTP servers, with the tier one NTP servers connected to atomic clocks (often via GPS), and tier two and three servers spreading the load of actually handling requests across the Internet. Also the client software is a lot more complex than you might think - it has to factor out communication delays, and adjust the time in a way that does not upset all the other processes that run on the server. But luckily all that complexity is hidden from you!

Ubuntu has two ways of automatically setting your time: ntpdate and ntpd.

ntpdate

Ubuntu comes with ntpdate as standard, and will run it once at boot time to set up your time according to Ubuntu's NTP server. However, a server's clock is likely to drift considerably between reboots, so it makes sense to correct the time occasionally. The easiest way to do this is to get cron to run ntpdate every day. With your favorite editor, as root, create a file /etc/cron.daily/ntpdate containing:

ntpdate ntp.ubuntu.com

The file /etc/cron.daily/ntpdate must also be executable.

sudo chmod 755 /etc/cron.daily/ntpdate

ntpd

ntpdate is a bit of a blunt instrument - it can only adjust the time once a day, in one big correction. The ntp daemon ntpd is far more subtle. It calculates the drift of your system clock and continuously adjusts it, so there are no large corrections that could lead to inconsistent logs for instance. The cost is a little processing power and memory, but for a modern server this is negligible.

To set up ntpd:

sudo apt-get install ntp

Changing Time Servers

In both cases above, your system will use Ubuntu's NTP server at ntp.ubuntu.com by default. This is OK, but you might want to use several servers to increase accuracy and resilience, and you may want to use time servers that are geographically closer to you. to do this for ntpdate, change the contents of /etc/cron.daily/ntpdate to:

ntpdate ntp.ubuntu.com pool.ntp.org

And for ntpd edit /etc/ntp.conf to include additional server lines:

server ntp.ubuntu.com
server pool.ntp.org

You may notice pool.ntp.org in the examples above. This is a really good idea which uses round-robin DNS to return an NTP server from a pool, spreading the load between several different servers. Even better, they have pools for different regions - for instance, if you are in New Zealand, so you could use nz.pool.ntp.org instead of pool.ntp.org.

You can also Google for NTP servers in your region, and add these to your configuration. To test that a server works, just type sudo ntpdate ntp.server.name and see what happens.

User Management

User management is a critical part of maintaining a secure system. Ineffective user and privilege management often lead many systems into being compromised. Therefore, it is important that you understand how you can protect your server through simple and effective user account management techniques.

Where is root?

Ubuntu developers made a conscientious decision to disable the administrative root account by default in all Ubuntu installations. This does not mean that the root account has been deleted or that it may not be accessed. It merely has been given a password which matches no possible encrypted value, therefore may not log in directly by itself.

Instead, users are encouraged to make use of a tool by the name of sudo to carry out system administrative duties. Sudo allows an authorized user to temporarily elevate their privileges using their own password instead of having to know the password belonging to the root account. This simple yet effective methodology provides accountability for all user actions, and gives the administrator granular control over which actions a user can perform with said privileges.

  • If for some reason you wish to enable the root account, simply give it a password:

    sudo passwd

    Sudo will prompt you for your password, and then ask you to supply a new password for root as shown below:

    [sudo] password for username: (enter your own password)
    Enter new UNIX password: (enter a new password for root)
    Retype new UNIX password: (repeat new password for root)
    passwd: password updated successfully

  • To disable the root account, use the following passwd syntax:

    sudo passwd -l root

  • You should read more on Sudo by checking out it's man page:

    man sudo

By default, the initial user created by the Ubuntu installer is a member of the group "admin" which is added to the file /etc/sudoers as an authorized sudo user. If you wish to give any other account full root access through sudo, simply add them to the admin group.

Adding and Deleting Users

The process for managing local users and groups is straight forward and differs very little from most other GNU/Linux operating systems. Ubuntu and other Debian based distributions, encourage the use of the "adduser" package for account management.

  • To add a user account, use the following syntax, and follow the prompts to give the account a password and identifiable characteristics such as a full name, phone number, etc.

    sudo adduser username

  • To delete a user account and its primary group, use the following syntax:

    sudo deluser username

    Deleting an account does not remove their respective home folder. It is up to you whether or not you wish to delete the folder manually or keep it according to your desired retention policies.

    Remember, any user added later on with the same UID/GID as the previous owner will now have access to this folder if you have not taken the necessary precautions.

    You may want to change these UID/GID values to something more appropriate, such as the root account, and perhaps even relocate the folder to avoid future conflicts:

    sudo chown -R root:root /home/username/
    sudo mkdir /home/archived_users/
    sudo mv /home/username /home/archived_users/

  • To temporarily lock or unlock a user account, use the following syntax, respectively:

    sudo passwd -l username
    sudo passwd -u username

  • To add or delete a personalized group, use the following syntax, respectively:

    sudo addgroup groupname
    sudo delgroup groupname

  • To add a user to a group, use the following syntax:

    sudo adduser username groupname

User Profile Security

When a new user is created, the adduser utility creates a brand new home directory named /home/username, respectively. The default profile is modeled after the contents found in the directory of /etc/skel, which includes all profile basics.

If your server will be home to multiple users, you should pay close attention to the user home directory permissions to ensure confidentiality. By default, user home directories in Ubuntu are created with world read/execute permissions. This means that all users can browse and access the contents of other users home directories. This may not be suitable for your environment.

  • To verify your current users home directory permissions, use the following syntax:

    ls -ld /home/username

    The following output shows that the directory /home/username has world readable permissions:

    drwxr-xr-x 2 username username 4096 2007-10-02 20:03 username

     

  • You can remove the world readable permissions using the following syntax:

    sudo chmod 0750 /home/username

    Some people tend to use the recursive option (-R) indiscriminately which modifies all child folders and files, but this is not necessary, and may yield other undesirable results. The parent directory alone is sufficient for preventing unauthorized access to anything below the parent.

    A much more efficient approach to the matter would be to modify the adduser global default permissions when creating user home folders. Simply edit the file /etc/adduser.conf and modify the DIR_MODE variable to something appropriate, so that all new home directories will receive the correct permissions.

    DIR_MODE=0750

  • After correcting the directory permissions using any of the previously mentioned techniques, verify the results using the following syntax:

    ls -ld /home/username

    The results below show that world readable permissions have been removed:

    drwxr-x--- 2 username username 4096 2007-10-02 20:03 username

Password Policy

A strong password policy is one of the most important aspects of your security posture. Many successful security breaches involve simple brute force and dictionary attacks against weak passwords. If you intend to offer any form of remote access involving your local password system, make sure you adequately address minimum password complexity requirements, maximum password lifetimes, and frequent audits of your authentication systems.

Minimum Password Length

By default, Ubuntu requires a minimum password length of 4 characters, as well as some basic entropy checks. These values are controlled in the file /etc/pam.d/common-password, which is outlined below.

password required pam_unix.so nullok obscure min=4 max=8 md5

If you would like to adjust the minimum length to 6 characters, change the appropriate variable to min=6. The modification is outlined below.

password required pam_unix.so nullok obscure min=6 max=8 md5

The max=8 variable does not represent the maximum length of a password. It only means that complexity requirements will not be checked on passwords over 8 characters. You may want to look at the libpam-cracklib package for additional password entropy assistance.

Password Expiration

When creating user accounts, you should make it a policy to have a minimum and maximum password age forcing users to change their passwords when they expire.

  • To easily view the current status of a user account, use the following syntax:

    sudo chage -l username

    The output below shows interesting facts about the user account, namely that there are no policies applied:

    Last password change : Jan 20, 2008
    Password expires : never
    Password inactive : never
    Account expires : never
    Minimum number of days between password change : 0
    Maximum number of days between password change : 99999
    Number of days of warning before password expires : 7

  • To set any of these values, simply use the following syntax, and follow the interactive prompts:

    sudo chage username

    The following is also an example of how you can manually change the explicit expiration date (-E) to 01/31/2008, minimum password age (-m) of 5 days, maximum password age (-M) of 90 days, inactivity period (-I) of 5 days after password expiration, and a warning time period (-W) of 14 days before password expiration.

    sudo chage -E 01/31/2008 -m 5 -M 90 -I 30 -W 14 username

  • To verify changes, use the same syntax as mentioned previously:

    sudo chage -l username

    The output below shows the new policies that have been established for the account:

    Last password change : Jan 20, 2008
    Password expires : Apr 19, 2008
    Password inactive : May 19, 2008
    Account expires : Jan 31, 2008
    Minimum number of days between password change : 5
    Maximum number of days between password change : 90
    Number of days of warning before password expires : 14

Other Security Considerations

Many applications use alternate authentication mechanisms that can be easily overlooked by even experienced system administrators. Therefore, it is important to understand and control how users authenticate and gain access to services and applications on your server.

SSH Access by Disabled Users

Simply disabling/locking a user account will not prevent a user from logging into your server remotely if they have previously set up RSA public key authentication. They will still be able to gain shell access to the server, without the need for any password. Remember to check the users home directory for files that will allow for this type of authenticated SSH access. e.g. /home/username/.ssh/authorized_keys.

Remove or rename the directory .ssh/ in the user's home folder to prevent further SSH authentication capabilities.

Be sure to check for any established SSH connections by the disabled user, as it is possible they may have existing inbound or outbound connections. Kill any that are found.

Restrict SSH access to only user accounts that should have it. For example, you may create a group called "sshlogin" and add the group name as the value associated with the AllowGroups variable located in the file /etc/ssh/sshd_config.

AllowGroups sshlogin

Then add your permitted SSH users to the group "sshlogin", and restart the SSH service.

sudo adduser username sshlogin
sudo /etc/init.d/ssh restart

External User Database Authentication

Most enterprise networks require centralized authentication and access controls for all system resources. If you have configured your server to authenticate users against external databases, be sure to disable the user accounts both externally and locally, this way you ensure that local fallback authentication is not possible.

Console Security

As with any other security barrier you put in place to protect your server, it is pretty tough to defend against untold damage caused by someone with physical access to your environment, for example, theft of hard drives, power or service disruption and so on. Therefore, console security should be addressed merely as one component of your overall physical security strategy. A locked "screen door" may deter a casual criminal, or at the very least slow down a determined one, so it is still advisable to perform basic precautions with regard to console security.

The following instructions will help defend your server against issues that could otherwise yield very serious consequences.

Disable Ctrl+Alt+Delete

First and foremost, anyone that has physical access to the keyboard can simply use the Ctrl+Alt+Delete key combination to reboot the server without having to log on. Sure, someone could simply unplug the power source, but you should still prevent the use of this key combination on a production server. This forces an attacker to take more drastic measures to reboot the server, and will prevent accidental reboots at the same time.

  • To disable the reboot action taken by pressing the Ctrl+Alt+Delete key combination, comment out the following line in the file /etc/event.d/control-alt-delete.

    #exec /sbin/shutdown -r now "Control-Alt-Delete pressed"

GRUB Password Security

Ubuntu installs GNU GRUB as its default boot loader, which allows for great flexibility and recovery options. For example, when you install additional kernel images, these are automatically added as available boot options in the grub menu. Also, by default, alternate boot options are available for each kernel entry that may be used for system recovery, aptly labeled (recovery mode). Recovery mode simply boots the corresponding kernel image into single user mode (init 1), which lands the administrator at a root prompt without the need for any password.

Therefore, it is important to control who may edit the grub menu items which, would otherwise allow for someone to perform the following dangerous actions:

  • Pass kernel options at boot up.
  • Boot the server into single user mode.

You can prevent these actions by adding a password to GRUB's configuration file of /boot/grub/menu.lst, which will be required to unlock GRUB's more advanced features prior to use.

  • To add a password for use with grub, first you must generate an md5 password hash using the grub-md5-crypt utility:

    grub-md5-crypt

    The command will ask you to enter a password and offer a resulting hash value as shown below:

    Password: (enter new password)
    Retype password: (repeat password)
    $1$s3YiK$M3lxAbqA6JLm2FbDWnClQ0

  • Add the resulting hash value to the file /boot/grub/menu.lst in the following format:

    password --md5 $1$s3YiK$M3lxAbqA6JLm2FbDWnClQ0

  • To require use of the password for entering single user mode, change the value of the lockalternative variable in the file /boot/grub/menu.lst to true, as shown in the following example.

    # lockalternative=true

    This does not prevent someone from booting the server from alternate media. A determined attacker would simply boot into an alternate environment, overwrite your master boot record, mount or copy your physical volumes, destroy your data, or anything else they can imagine. Please explore other countermeasures that may help you with these types of attacks.

Firewall

Introduction

The Linux kernel includes the Netfilter subsystem, which is used to manipulate or decide the fate of network traffic headed into or through your server. All modern Linux firewall solutions use this system for packet filtering.

The kernel's packet filtering system would be of little use to administrators without a userspace interface to manage it. This is the purpose of iptables. When a packet reaches your server, it will be handed off to the Netfilter subsystem for acceptance, manipulation, or rejection based on the rules supplied to it from userspace via iptables. Thus, iptables is all you need to manage your firewall if you're familiar with it, but many frontends are available to simplify the task.

ufw - Uncomplicated Firewall

The default firewall configuration tool for Ubuntu is ufw. Developed to ease iptables firewall configuration, ufw provides a user friendly way to create an IPv4 or IPv6 host-based firewall.

ufw by default is initially disabled. From the ufw man page:

"ufw is not intended to provide complete firewall functionality via its command interface, but instead provides an easy way to add or remove simple rules. It is currently mainly used for host-based firewalls."

The following are some examples of how to use ufw:

  • First, ufw needs to be enabled. From a terminal prompt enter:

    sudo ufw enable

  • To open a port (ssh in this example):

    sudo ufw allow 22

  • Rules can also be added using a numbered format:

    sudo ufw insert 1 allow 80

  • Similarly, to close an opened port:

    sudo ufw deny 22

  • To remove a rule, use delete followed by the rule:

    sudo ufw delete deny 22

  • It is also possible to allow access from specific hosts or networks to a port. The following example allows ssh access from host 192.168.0.2 to any ip address on this host:

    sudo ufw allow proto tcp from 192.168.0.2 to any port 22

    Replace 192.168.0.2 with 192.168.0.0/24 to allow ssh access from the entire subnet.

  • Adding the --dry-run option to a ufw command will output the resulting rules, but not apply them. For example, the following is what would be applied if opening the HTTP port:

    sudo ufw --dry-run allow http

    *filter
    :ufw-user-input - [0:0]
    :ufw-user-output - [0:0]
    :ufw-user-forward - [0:0]
    :ufw-user-limit - [0:0]
    :ufw-user-limit-accept - [0:0]
    ### RULES ###

    ### tuple ### allow tcp 80 0.0.0.0/0 any 0.0.0.0/0
    -A ufw-user-input -p tcp --dport 80 -j ACCEPT

    ### END RULES ###
    -A ufw-user-input -j RETURN
    -A ufw-user-output -j RETURN
    -A ufw-user-forward -j RETURN
    -A ufw-user-limit -m limit --limit 3/minute -j LOG --log-prefix "[UFW LIMIT]: "
    -A ufw-user-limit -j REJECT
    -A ufw-user-limit-accept -j ACCEPT
    COMMIT
    Rules updated

  • ufw can be disabled by:

    sudo ufw disable

  • To see the firewall status, enter:

    sudo ufw status

  • And for more verbose status information use:

    sudo ufw status verbose

  • To view the numbered format:

    sudo ufw status numbered

    If the port you want to open or close is defined in /etc/services, you can use the port name instead of the number. In the above examples, replace 22 with ssh.

This is a quick introduction to using ufw. Please refer to the ufw man page for more information.

ufw Application Integration

Applications that open ports can include an ufw profile, which details the ports needed for the application to function properly. The profiles are kept in /etc/ufw/applications.d, and can be edited if the default ports have been changed.

  • To view which applications have installed a profile, enter the following in a terminal:

    sudo ufw app list

  • Similar to allowing traffic to a port, using an application profile is accomplished by entering:

    sudo ufw allow Samba

  • An extended syntax is available as well:

    ufw allow from 192.168.0.0/24 to any app Samba

    Replace Samba and 192.168.0.0/24 with the application profile you are using and the IP range for your network.

    There is no need to specify the protocol for the application, because that information is detailed in the profile. Also, note that the app name replaces the port number.

  • To view details about which ports, protocols, etc are defined for an application, enter:

    sudo ufw app info Samba

Not all applications that require opening a network port come with ufw profiles, but if you have profiled an application and want the file to be included with the package, please file a bug against the package in Launchpad.

IP Masquerading

The purpose of IP Masquerading is to allow machines with private, non-routable IP addresses on your network to access the Internet through the machine doing the masquerading. Traffic from your private network destined for the Internet must be manipulated for replies to be routable back to the machine that made the request. To do this, the kernel must modify the source IP address of each packet so that replies will be routed back to it, rather than to the private IP address that made the request, which is impossible over the Internet. Linux uses Connection Tracking (conntrack) to keep track of which connections belong to which machines and reroute each return packet accordingly. Traffic leaving your private network is thus "masqueraded" as having originated from your Ubuntu gateway machine. This process is referred to in Microsoft documentation as Internet Connection Sharing.

ufw Masquerading

IP Masquerading can be achieved using custom ufw rules. This is possible because the current back-end for ufw is iptables-restore with the rules files located in /etc/ufw/*.rules. These files are a great place to add legacy iptables rules used without ufw, and rules that are more network gateway or bridge related.

The rules are split into two different files, rules that should be executed before ufw command line rules, and rules that are executed after ufw command line rules.

  • First, packet forwarding needs to be enabled in ufw. Two configuration files will need to be adjusted, in /etc/default/ufw change the DEFAULT_FORWARD_POLICY to "ACCEPT":

    DEFAULT_FORWARD_POLICY="ACCEPT"

    Then edit /etc/ufw/sysctl.conf and uncomment:

    net/ipv4/ip_forward=1

    Similarly, for IPv6 forwarding uncomment:

    net/ipv6/conf/default/forwarding=1

  • Now we will add rules to the /etc/ufw/before.rules file. The default rules only configure the filter table, and to enable masquerading the nat table will need to be configured. Add the following to the top of the file just after the header comments:

    # nat Table rules
    *nat
    :POSTROUTING ACCEPT [0:0]
    # Forward traffic from eth1 through eth0.
    -A POSTROUTING -s 192.168.0.0/24 -o eth0 -j MASQUERADE
    # don't delete the 'COMMIT' line or these nat table rules won't be processed
    COMMIT

    The comments are not strictly necessary, but it is considered good practice to document your configuration. Also, when modifying any of the rules files in /etc/ufw, make sure these lines are the last line for each table modified:

    # don't delete the 'COMMIT' line or these rules won't be processed
    COMMIT

    For each Table a corresponding COMMIT statement is required. In these examples only the nat and filter tables are shown, but you can also add rules for the raw and mangle tables.

    In the above example replace eth0, eth1, and 192.168.0.0/24 with the appropriate interfaces and IP range for your network.

  • Finally, disable and re-enable ufw to apply the changes:

    sudo ufw disable && sudo ufw enable

IP Masquerading should now be enabled. You can also add any additional FORWARD rules to the /etc/ufw/before.rules. It is recommended that these additional rules be added to the ufw-before-forward chain.

iptables Masquerading

iptables can also be used to enable masquerading.

  • Similar to ufw, the first step is to enable IPv4 packet forwarding by editing /etc/sysctl.conf and uncomment the following line

    net.ipv4.ip_forward=1

    If you wish to enable IPv6 forwarding also uncomment:

    net.ipv6.conf.default.forwarding=1

  • Next, execute the sysctl command to enable the new settings in the configuration file:

    sudo sysctl -p

  • IP Masquerading can now be accomplished with a single iptables rule, which may differ slightly based on your network configuration:

    sudo iptables -t nat -A POSTROUTING -s 192.168.0.0/16 -o ppp0 -j MASQUERADE

    The above command assumes that your private address space is 192.168.0.0/16 and that your Internet-facing device is ppp0. The syntax is broken down as follows:

    • -t nat -- the rule is to go into the nat table
    • -A POSTROUTING -- the rule is to be appended (-A) to the POSTROUTING chain
    • -s 192.168.0.0/16 -- the rule applies to traffic originating from the specified address space
    • -o ppp0 -- the rule applies to traffic scheduled to be routed through the specified network device
    • -j MASQUERADE -- traffic matching this rule is to "jump" (-j) to the MASQUERADE target to be manipulated as described above
  • Also, each chain in the filter table (the default table, and where most or all packet filtering occurs) has a default policy of ACCEPT, but if you are creating a firewall in addition to a gateway device, you may have set the policies to DROP or REJECT, in which case your masqueraded traffic needs to be allowed through the FORWARD chain for the above rule to work:

    sudo iptables -A FORWARD -s 192.168.0.0/16 -o ppp0 -j ACCEPT
    sudo iptables -A FORWARD -d 192.168.0.0/16 -m state --state ESTABLISHED,RELATED -i ppp0 -j ACCEPT

    The above commands will allow all connections from your local network to the Internet and all traffic related to those connections to return to the machine that initiated them.

  • If you want masquerading to be enabled on reboot, which you probably do, edit /etc/rc.local and add any commands used above. For example add the first command with no filtering:

    iptables -t nat -A POSTROUTING -s 192.168.0.0/16 -o ppp0 -j MASQUERADE

Logs

Firewall logs are essential for recognizing attacks, troubleshooting your firewall rules, and noticing unusual activity on your network. You must include logging rules in your firewall for them to be generated, though, and logging rules must come before any applicable terminating rule (a rule with a target that decides the fate of the packet, such as ACCEPT, DROP, or REJECT).

If you are using ufw, you can turn on logging by entering the following in a terminal:

sudo ufw logging on

To turn logging off in ufw, simply replace on with off in the above command.

If using iptables instead of ufw, enter:

sudo iptables -A INPUT -m state --state NEW -p tcp --dport 80 -j LOG --log-prefix "NEW_HTTP_CONN: "

A request on port 80 from the local machine, then, would generate a log in dmesg that looks like this:

[4304885.870000] NEW_HTTP_CONN: IN=lo OUT= MAC=00:00:00:00:00:00:00:00:00:00:00:00:08:00 SRC=127.0.0.1 DST=127.0.0.1 LEN=60 TOS=0x00 PRE

The above log will also appear in /var/log/messages, /var/log/syslog, and /var/log/kern.log. This behavior can be modified by editing /etc/syslog.conf appropriately or by installing and configuring ulogd and using the ULOG target instead of LOG. The ulogd daemon is a userspace server that listens for logging instructions from the kernel specifically for firewalls, and can log to any file you like, or even to a PostgreSQL or MySQL database. Making sense of your firewall logs can be simplified by using a log analyzing tool such as fwanalog, fwlogwatch, or lire.

Other Tools

There are many tools available to help you construct a complete firewall without intimate knowledge of iptables. For the GUI-inclined:

  • Firestarter is quite popular and easy to use.
  • fwbuilder is very powerful and will look familiar to an administrator who has used a commercial firewall utility such as Checkpoint FireWall-1.

If you prefer a command-line tool with plain-text configuration files:

  • Shorewall is a very powerful solution to help you configure an advanced firewall for any network.
  • ipkungfu should give you a working firewall "out of the box" with zero configuration, and will allow you to easily set up a more advanced firewall by editing simple, well-documented configuration files.
  • fireflier is designed to be a desktop firewall application. It is made up of a server (fireflier-server) and your choice of GUI clients (GTK or QT), and behaves like many popular interactive firewall applications for Windows.

AppArmor

AppArmor is a Linux Security Module implementation of name-based mandatory access controls. AppArmor confines individual programs to a set of listed files and posix 1003.1e draft capabilities.

AppArmor is installed and loaded by default. It uses profiles of an application to determine what files and permissions the application requires. Some packages will install their own profiles, and additional profiles can be found in the apparmor-profiles package.

To install the apparmor-profiles package from a terminal prompt:

sudo apt-get install apparmor-profiles

AppArmor profiles have two modes of execution:

  • Complaining/Learning: profile violations are permitted and logged. Useful for testing and developing new profiles.
  • Enforced/Confined: enforces profile policy as well as logging the violation.

Using AppArmor

The apparmor-utils package contains command line utilities that you can use to change the AppArmor execution mode, find the status of a profile, create new profiles, etc.

  • apparmor_status is used to view the current status of AppArmor profiles.

    sudo apparmor_status

  • aa-complain places a profile into complain mode.

    sudo aa-complain /path/to/bin

  • aa-enforce places a profile into enforce mode.

    sudo aa-enforce /path/to/bin

  • The /etc/apparmor.d directory is where the AppArmor profiles are located. It can be used to manipulate the mode of all profiles.

    Enter the following to place all profiles into complain mode:

    sudo aa-complain /etc/apparmor.d/*

    To place all profiles in enforce mode:

    sudo aa-enforce /etc/apparmor.d/*

  • apparmor_parser is used to load a profile into the kernel. It can also be used to reload a currently loaded profile using the -r option. To load a profile:

    cat /etc/apparmor.d/profile.name | sudo apparmor_parser -a

    To reload a profile:

    cat /etc/apparmor.d/profile.name | sudo apparmor_parser -r
    sudo /etc/init.d/apparmor reload

  • The /etc/apparmor.d/disable directory can be used along with the apparmor_parser -R option to disable a profile.

    sudo ln -s /etc/apparmor.d/profile.name /etc/apparmor.d/disable/
    sudo apparmor_parser -R /etc/apparmor.d/profile.name

    To re-enable a disabled profile remove the symbolic link to the profile in /etc/apparmor.d/disable/. Then load the profile using the -a option.

    sudo rm /etc/apparmor.d/disable/profile.name
    cat /etc/apparmor.d/profile.name | sudo apparmor_parser -a

  • AppArmor can be disabled, and the kernel module unloaded by entering the following:

    sudo /etc/init.d/apparmor stop
    sudo update-rc.d -f apparmor remove

  • To re-enable AppArmor enter:

    sudo /etc/init.d/apparmor start
    sudo update-rc.d apparmor defaults

    Replace profile.name with the name of the profile you want to manipulate. Also, replace /path/to/bin/ with the actual executable file path. For example for the ping command use /bin/ping

Profiles

AppArmor profiles are simple text files located in /etc/apparmor.d/. The files are named after the full path to the executable they profile replacing the "/" with ".". For example /etc/apparmor.d/bin.ping is the AppArmor profile for the /bin/ping command.

There are two main type of rules used in profiles:

  • Path entries: which detail which files an application can access in the file system.
  • Capability entries: determine what privileges a confined process is allowed to use.

As an example take a look at /etc/apparmor.d/bin.ping:

#include
/bin/ping flags=(complain) {
#include
#include
#include

capability net_raw,
capability setuid,
network inet raw,

/bin/ping mixr,
/etc/modules.conf r,
}

  • #include : include statements from other files. This allows statements pertaining to multiple applications to be placed in a common file.
  • /bin/ping flags=(complain): path to the profiled program, also setting the mode to complain.
  • capability net_raw,: allows the application access to the CAP_NET_RAW Posix.1e capability.
  • /bin/ping mixr,: allows the application read and execute access to the file.

After editing a profile file the profile must be reloaded. See the section called “Using AppArmor” for details.

Creating a Profile

  • Design a test plan: Try to think about how the application should be exercised. The test plan should be divided into small test cases. Each test case should have a small description and list the steps to follow.

    Some standard test cases are:

    • Starting the program.
    • Stopping the program.
    • Reloading the program.
    • Testing all the commands supported by the init script.
  • Generate the new profile: Use aa-genprof to generate a new profile. From a terminal:

    sudo aa-genprof executable

    For example:

    sudo aa-genprof slapd

  • To get your new profile included in the apparmor-profiles package, file a bug in Launchpad against the AppArmor package:
    • Include your test plan and test cases.
    • Attach your new profile to the bug.

Updating Profiles

When the program is misbehaving, audit messages are sent to the log files. The program aa-logprof can be used to scan log files for AppArmor audit messages, review them and update the profiles. From a terminal:

sudo aa-logprof

Certificates

One of the most common forms of cryptography today is public-key cryptography. Public-key cryptography utilizes a public key and a private key. The system works by encrypting information using the public key. The information can then only be decrypted using the private key.

A common use for public-key cryptography is encrypting application traffic using a Secure Socket Layer (SSL) or Transport Layer Security (TLS) connection. For example, configuring Apache to provide HTTPS, the HTTP protocol over SSL. This allows a way to encrypt traffic using a protocol that does not itself provide encryption.

A Certificate is a method used to distribute a public key and other information about a server and the organization who is responsible for it. Certificates can be digitally signed by a Certification Authority or CA. A CA is a trusted third party that has confirmed that the information contained in the certificate is accurate.

Types of Certificates

To set up a secure server using public-key cryptography, in most cases, you send your certificate request (including your public key), proof of your company's identity, and payment to a 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, that self-signed certificates should not be used in most production environments.

Continuing the HTTPS example, a CA-signed certificate provides two important capabilities that a self-signed certificate does not:

  • 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, and computers, 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. Also, other applications may generate an error message when using a self-singed certificate.

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 1. 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 configure the appropriate applications to use the certificate.

Generating a Certificate Signing Request (CSR)

Whether you are getting a certificate from a CA or generating your own self-signed certificate, the first step is to generate a key.

If the certificate will be used by service daemons, such as Apache, Postfix, Dovecot, etc, a key without a passphrase is often appropriate. Not having a passphrase allows the services to start without manual intervention, usually the preferred way to start a daemon.

This section will cover generating a key with a passphrase, and one without. The non-passphrase key will then be used to generate a certificate that can be used with various service daemons.

Running your secure service without a passphrase is convenient because you will not need to enter the passphrase every time you start your secure service. But it is insecure and a compromise of the key means a compromise of the server as well.

To generate the keys for the Certificate Signing Request (CSR) run the following command from a terminal prompt:

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 the server.key file.

Now create the insecure key, the one without a passphrase, and shuffle the key names:

openssl rsa -in server.key -out server.key.insecure
mv server.key server.key.secure
mv server.key.insecure server.key

The insecure key is now named server.key, and 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, Once you enter all these details, your CSR will be created and it will be stored in the server.csr file. Site Name, Email Id, etc.

You can now submit this CSR file to a CA for processing. The CA will use this CSR file and issue the certificate. On the other hand, you can create self-signed certificate using this CSR.

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.

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

Now simply configure any applications, with the ability to use public-key cryptography, to use the certificate and key files. For example, Apache can provide HTTPS, Dovecot can provide IMAPS and POP3S, etc.

Certification Authority

If the services on your network require more than a few self-signed certificates it may be worth the additional effort to setup your own internal Certification Authority (CA). Using certificates signed by your own CA, allows the various services using the certificates to easily trust other services using certificates issued from the same CA.

  1. First, create the directories to hold the CA certificate and related files:

    sudo mkdir /etc/ssl/CA
    sudo mkdir /etc/ssl/newcerts

  2. The CA needs a few additional files to operate, one to keep track of the last serial number used by the CA, each certificate must have a unique serial number, and another file to record which certificates have been issued:

    sudo sh -c "echo '01' > /etc/ssl/CA/serial"
    sudo touch /etc/ssl/CA/index.txt

  3. The third file is a CA configuration file. Though not strictly necessary, it is very convenient when issuing multiple certificates. Edit /etc/ssl/openssl.cnf, and in the [ CA_default ] change:

    dir                           =  /etc/ssl/                                        # Where everything is kept
    database               =  $dir/CA/index.txt                      # database index file.
    certificate             =  $dir/certs/cacert.pem              # The CA certificate
    serial                     =  $dir/CA/serial                             # The current serial number
    private_key        =  $dir/private/cakey.pem           # The private key

  4. Next, create the self-singed root certificate:

    openssl req -new -x509 -extensions v3_ca -keyout cakey.pem -out cacert.pem -days 3650

    You will then be asked to enter the details about the certificate.

  5. Now install the root certificate and key:

    sudo mv cakey.pem /etc/ssl/private/
    sudo mv cacert.pem /etc/ssl/certs/

  6. You are now ready to start signing certificates. The first item needed is a Certificate Signing Request (CSR), see the section called “Generating a Certificate Signing Request (CSR)” for details. Once you have a CSR, enter the following to generate a certificate signed by the CA:

    sudo openssl ca -in server.csr -config /etc/ssl/openssl.cnf

    After entering the password for the CA key, you will be prompted to sign the certificate, and again to commit the new certificate. You should then see a somewhat large amount of output related to the certificate creation.

  7. There should now be a new file, /etc/ssl/newcerts/01.pem, containing the same output. Copy and paste everything between the -----BEGIN CERTIFICATE----- and ----END CERTIFICATE----- lines to a file named after the hostname of the server where the certificate will be installed. For example mail.example.com.crt, is a nice descriptive name.

    Subsequent certificates will be named 02.pem, 03.pem, etc.

    Replace mail.example.com.crt with your own descriptive name.

  8. Finally, copy the new certificate to the host that needs it, and configure the appropriate applications to use it. The default location to install certificates is /etc/ssl/certs. This enables multiple services to use the same certificate without overly complicated file permissions.

    For applications that can be configured to use a CA certificate, you should also copy the /etc/ssl/certs/cacert.pem file to the /etc/ssl/certs/ directory on each server.

eCryptfs

eCryptfs is a POSIX-compliant enterprise-class stacked cryptographic filesystem for Linux. Layering on top of the filesystem layer eCryptfs protects files no matter the underlying filesystem, partition type, etc.

During installation there is an option to encrypt the /home partition. This will automatically configure everything needed to encrypt and mount the partition.

As an example, this section will cover configuring /srv to be encrypted using eCryptfs.

Using eCryptfs

First, install the necessary packages. From a terminal prompt enter:

sudo apt-get install ecryptfs-utils

Now mount the partition to be encrypted:

sudo mount -t ecryptfs /srv /srv

You will then be prompted for some details on how ecryptfs should encrypt the data.

To test that files placed in /srv are indeed encrypted copy the /etc/default folder to /srv:

sudo cp -r /etc/default /srv

Now unmount /srv, and try to view a file:

sudo umount /srv
cat /srv/default/cron

Remounting /srv using ecryptfs will make the data viewable once again.

Automatically Mounting Encrypted Partitions

There are a couple of ways to automatically mount an ecryptfs encrypted filesystem at boot. This example will use a /root/.ecryptfsrc file containing mount options, along with a passphrase file residing on a USB key.

First, create /root/.ecryptfsrc containing:

key=passphrase:passphrase_passwd_file=/mnt/usb/passwd_file.txt
ecryptfs_sig=5826dd62cf81c615
ecryptfs_cipher=aes
ecryptfs_key_bytes=16
ecryptfs_passthrough=n
ecryptfs_enable_filename_crypto=n

Adjust the ecryptfs_sig to the signature in /root/.ecryptfs/sig-cache.txt.

Next, create the /mnt/usb/passwd_file.txt passphrase file:

passphrase_passwd=[secrets]

Now add the necessary lines to /etc/fstab:

/dev/sdb1   /mnt/usb   ext3   ro   0   0
/srv   /srv   ecryptfs   defaults   0   0

Make sure the USB drive is mounted before the encrypted partition.

Finally, reboot and the /srv should be mounted using ecryptfs.

Other Utilities

The ecryptfs-utils package includes several other useful utilities:

  • ecryptfs-setup-private: creates a ~/Private directory to contain encrypted information. This utility can be run by unprivileged users to keep data private from other users on the system.
  • ecryptfs-mount-private and ecryptfs-umount-private: will mount and unmount respectively, a users ~/Private directory.
  • ecryptfs-add-passphrase: adds a new passphrase to the kernel keyring.
  • ecryptfs-manager: manages eCryptfs objects such as keys.
  • ecryptfs-stat: allows you to view the ecryptfs meta information for a file.

HTTPD - Apache2 Web Server

Apache is the most commonly used Web Server on 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 a user will enter only the FQDN. To request specific information about paid support, 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.

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

Configuration

Apache2 is configured by placing directives in plain text configuration files. The configuration files are separated between the following files and directories:

  • apache2.conf: the main Apache2 configuration file. Contains settings that are global to Apache2.
  • conf.d: contains configuration files which apply globally to Apache. Other packages that use Apache2 to serve content may add files, or symlinks, to this directory.
  • envvars: file where Apache2 environment variables are set.
  • httpd.conf: historically the main Apache2 configuration file, named after the httpd daemon. The file can be used for user specific configuration options that globally effect Apache2.
  • mods-available: this directory contains configuration files to both load modules and configure them. Not all modules will have specific configuration files, however.
  • mods-enabled: holds symlinks to the files in /etc/apache2/mods-available. When a module configuration file is symlinked it will be enabled the next time apache2 is restarted.
  • ports.conf: houses the directives that determine which TCP ports Apache2 is listening on.
  • sites-available: this directory has configuration files for Apache Virtual Hosts. Virtual Hosts allow Apache2 to be configured for multiple sites that have separate configurations.
  • sites-enabled: like mods-enabled, sites-enabled contains symlinks to the /etc/apache2/sites-available directory. Similarly when a configuration file in sites-available is symlinked it will be active once Apache is restarted.

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 /etc/mime.types by default.

Basic Settings

This section explains Apache2 server essential configuration parameters. Refer to the Apache2 Documentation 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.

    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.

    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 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, the following configuration will cause your site to respond to any domain request ending in .ubunturocks.com.

    ServerAlias *.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.

Enable the new VirtualHost using the a2ensite utility and restart Apache:

sudo a2ensite mynewsite
sudo /etc/init.d/apache2 restart

Be sure to replace mynewsite with a more descriptive name for the VirtualHost. One method is to name the file after the ServerName directive of the VirtualHost.

Similarly, use the a2dissite utility to disable sites. This is can be useful when troubleshooting configuration problems with multiple VirtualHosts:

sudo a2dissite mynewsite
sudo /etc/init.d/apache2 restart

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.

    For example, when a user requests the page http://www.example.com/this_directory/, 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. Options is one of these directives. A Directory stanza is enclosed in XML-like tags, like so:

    <Directory /var/www/mynewsite>
    ...
    </Directory>

    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 for more 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.
    • SymLinksIfOwnerMatch - Only follow symbolic links if the target file or directory has the same owner as the link.

httpd Settings

This section explains some basic httpd daemon configuration 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.

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. For example, run the following command from a terminal prompt to install the MySQL Authentication module:

sudo apt-get install libapache2-mod-auth-mysql

See the /etc/apache2/mods-available directory, for additional modules.

Use the a2enmod utility to enable a module:

sudo a2enmod auth_mysql
sudo /etc/init.d/apache2 restart

Similarly, a2dismod will disable a module:

sudo a2dismod auth_mysql
sudo /etc/init.d/apache2 restart

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, 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. Execute the following command from a terminal prompt to enable the mod_ssl module:

sudo a2enmod ssl

There is a default HTTPS configuration file in /etc/apache2/sites-available/default-ssl. In order for Apache to provide HTTPS, a certificate and key file are also needed. The default HTTPS configuration will use a certificate and key generated by the ssl-cert package. They are good for testing, but the auto-generated certificate and key should be replaced by a certificate specific to the site or server. For information on generating a key and obtaining a certificate see the section called "Certificates"

To configure Apache for HTTPS, enter the following:

sudo a2ensite default-ssl

The directories /etc/ssl/certs and /etc/ssl/private are the default locations. If you install the certificate and key in another directory make sure to change SSLCertificateFile and SSLCertificateKeyFile appropriately.

With Apache now configured for HTTPS, restart the service to enable the new settings:

sudo /etc/init.d/apache2 restart

Depending on how you obtained your certificate you may need to enter a passphrase when Apache starts.

You can access the secure server pages by typing https://your_hostname/url/ in your browser address bar.

PHP5 - Scripting Language

PHP is a general-purpose scripting language suited for Web development. The PHP script can be embedded into HTML. This section explains how to install and configure PHP5 in Ubuntu System with Apache2 and MySQL.

This section assumes you have installed and configured Apache 2 Web Server and MySQL Database Server. You can refer to Apache 2 section and MySQL sections in this document to install and configure Apache 2 and MySQL respectively.

Installation

The PHP5 is available in Ubuntu Linux.

  • To install PHP5 you can enter the following command in the terminal prompt:

    sudo apt-get install php5 libapache2-mod-php5

    You can run PHP5 scripts from command line. To run PHP5 scripts from command line you should install php5-cli package. To install php5-cli you can enter the following command in the terminal prompt:

    sudo apt-get install php5-cli

    You can also execute PHP5 scripts without installing PHP5 Apache module. To accomplish this, you should install php5-cgi package. You can run the following command in a terminal prompt to install php5-cgi package:

    sudo apt-get install php5-cgi

    To use MySQL with PHP5 you should install php5-mysql package. To install php5-mysql you can enter the following command in the terminal prompt:

    sudo apt-get install php5-mysql

    Similarly, to use PostgreSQL with PHP5 you should install php5-pgsql package. To install php5-pgsql you can enter the following command in the terminal prompt:

    sudo apt-get install php5-pgsql

Configuration

Once you install PHP5, you can run PHP5 scripts from your web browser. If you have installed php5-cli package, you can run PHP5 scripts from your command prompt.

By default, the Apache 2 Web server is configured to run PHP5 scripts. In other words, the PHP5 module is enabled in Apache2 Web server automatically when you install the module. Please verify if the files /etc/apache2/mods-enabled /php5.conf and /etc/apache2/mods-enabled/php5.load exist. If they do not exists, you can enable the module using a2enmod command.

Once you install PHP5 related packages and enabled PHP5 Apache 2 module, you should restart Apache2 Web server to run PHP5 scripts. You can run the following command at a terminal prompt to restart your web server:

sudo /etc/init.d/apache2 restart

Testing

To verify your installation, you can run following PHP5 phpinfo script:

<?php
phpinfo();
?>

You can save the content in a file phpinfo.php and place it under DocumentRoot directory of Apache2 Web server. When point your browser to http://hostname/phpinfo.php, it would display values of various PHP5 configuration parameters.

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.

Installation

At a terminal prompt, enter the following command to install the Squid server:

sudo apt-get install squid

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 will 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

Ruby on Rails

Ruby on Rails is an open source web framework for developing database backed web applications. It is optimized for sustainable productivity of the programmer since it lets the programmer to write code by favoring convention over configuration.

Installation

Before installing Rails you should install Apache and MySQL. To install the Apache package, please refer to the section called "HTTPD - Apache2 Web Server". For instructions on installing MySQL refer to the section called "MySQL".

Once you have Apache and MySQL packages installed, you are ready to install Ruby on Rails package.

To install the Ruby base packages and Ruby on Rails, you can enter the following command in the terminal prompt:

sudo apt-get install rails

Configuration

Modify the /etc/apache2/sites-available/default configuration file to setup your domains.

The first thing to change is the DocumentRoot directive:

DocumentRoot /path/to/rails/application/public

Next, change the <Directory "/path/to/rails/application/public"> directive:

<Directory "/path/to/rails/application/public">
          Options Indexes FollowSymLinks MultiViews ExecCGI
          AllowOverride All
          Order allow,deny
          allow from all
          AddHandler cgi-script .cgi
</Directory>

You should also enable the mod_rewrite module for Apache. To enable mod_rewrite module, please enter the following command in a terminal prompt:

sudo a2enmod rewrite

Finally you will need to change the ownership of the /path/to/rails/application/public and /path/to/rails /application/tmp directories to the user used to run the Apache process:

sudo chown -R www-data:www-data /path/to/rails/application/public
sudo chown -R www-data:www-data /path/to/rails/application/tmp

That's it! Now you have your Server ready for your Ruby on Rails applications.

Apache Tomcat

Apache Tomcat is a web container that allows you to serve Java Servlets and JSP (Java Server Pages) web applications.

The Tomcat 6.0 packages in Ubuntu support two different ways of running Tomcat. You can install them as a classic unique system-wide instance, that will be started at boot time and will run as the tomcat6 unpriviledged user. But you can also deploy private instances that will run with your own user rights, and that you should start and stop by yourself. This second way is particularly useful in a development server context where multiple users need to test on their own private Tomcat instances.

System-wide installation

To install the Tomcat server, you can enter the following command in the terminal prompt:

sudo apt-get install tomcat6

This will install a Tomcat server with just a default ROOT webapp that displays a minimal "It works" page by default.

Configuration

Tomcat configuration files can be found in /etc/tomcat6. Only a few common configuration tweaks will be described here, please see Tomcat 6.0 documentation for more.

Changing default ports

By default Tomcat 6.0 runs a HTTP connector on port 8080 and an AJP connector on port 8009. You might want to change those default ports to avoid conflict with another server on the system. This is done by changing the following lines in /etc/tomcat6/server.xml:

<Connector port="8080" protocol="HTTP/1.1"
       connectionTimeout="20000"
       redirectPort="8443" />
...
<Connector port="8009" protocol="AJP/1.3" redirectPort="8443" />

Changing JVM used

By default Tomcat will run preferably with OpenJDK-6, then try Sun's JVM, then try some other JVMs. If you have various JVMs installed, you can set which should be used by setting JAVA_HOME in /etc/default/tomcat6:

JAVA_HOME=/usr/lib/jvm/java-6-sun

Declaring users and roles

Usernames, passwords and roles (groups) can be defined centrally in a Servlet container. In Tomcat 6.0 this is done in the /etc/tomcat6/tomcat-users.xml file:

<role rolename="admin"/> <user username="tomcat" password="s3cret" roles="admin"/>

Using Tomcat standard webapps

Tomcat is shipped with webapps that you can install for documentation, administration or demo purposes.

Tomcat documentation

The tomcat6-docs package contains Tomcat 6.0 documentation, packaged as a webapp that you can access by default at http://yourserver:8080/docs. You can install it by entering the following command in the terminal prompt:

sudo apt-get install tomcat6-docs

Tomcat administration webapps

The tomcat6-admin package contains two webapps that can be used to administer the Tomcat server using a web interface. You can install them by entering the following command in the terminal prompt:

sudo apt-get install tomcat6-admin

The first one is the manager webapp, which you can access by default at http://yourserver:8080/manager/html. It is primarily used to get server status and restart webapps.

Access to the manager application is protected by default: you need to define a user with the role "manager" in /etc/tomcat6/tomcat-users.xml before you can access it.

The second one is the host-manager webapp, which you can access by default at http://yourserver:8080/host-manager/html. It can be used to create virtual hosts dynamically.

Access to the host-manager application is also protected by default: you need to define a user with the role "admin" in /etc/tomcat6/tomcat-users.xml before you can access it.

For security reasons, the tomcat6 user cannot write to the /etc/tomcat6 directory by default. Some features in these admin webapps (application deployment, virtual host creation) need write access to that directory. If you want to use these features execute the following, to give users in the tomcat6 group the necessary rights:

sudo chgrp -R tomcat6 /etc/tomcat6
sudo chmod -R g+w /etc/tomcat6

Tomcat examples webapps

The tomcat6-examples package contains two webapps that can be used to test or demonstrate Servlets and JSP features, which you can access them by default at http://yourserver:8080/examples. You can install them by entering the following command in the terminal prompt:

sudo apt-get install tomcat6-examples

Using private instances

Tomcat is heavily used in development and testing scenarios where using a single system-wide instance doesn't meet the requirements of multiple users on a single system. The Tomcat 6.0 packages in Ubuntu come with tools to help deploy your own user-oriented instances, allowing every user on a system to run (without root rights) separate private instances while still using the system-installed libraries.

It is possible to run the system-wide instance and the private instances in parallel, as long as they do not use the same TCP ports.

Installing private instance support

You can install everything necessary to run private instances by entering the following command in the terminal prompt:

sudo apt-get install tomcat6-user

Creating a private instance

You can create a private instance directory by entering the following command in the terminal prompt:

tomcat6-instance-create my-instance

This will create a new my-instance directory with all the necessary subdirectories and scripts. You can for example install your common libraries in the lib/ subdirectory and deploy your webapps in the webapps/ subdirectory. No webapps are deployed by default.

Configuring your private instance

You will find the classic Tomcat configuration files for your private instance in the conf/ subdirectory. You should for example certainly edit the conf/server.xml file to change the default ports used by your private Tomcat instance to avoid conflict with other instances that might be running.

Starting/stopping your private instance

You can start your private instance by entering the following command in the terminal prompt (supposing your instance is located in the my-instance directory):

my-instance/bin/startup.sh

You should check the logs/ subdirectory for any error. If you have a java.net.BindException: Address already in use:8080 error, it means that the port you're using is already taken and that you should change it.

You can stop your instance by entering the following command in the terminal prompt (supposing your instance is located in the my-instance directory):

my-instance/bin/shutdown.sh

Add new comment