Sunday, 28 August 2011

Quick HOWTO Telnet, TFTP, and xinetd


Introduction

Many network enabled Linux applications don't rely on themselves to provide restricted access or bind to a particular TCP port; instead they often offload a lot of this work to a program suite made just for this purpose, xinetd.
Managing xinetd Programs
The xinetd RPM is installed by default in Fedora Linux and uses /etc/xinetd.conf as its main configuration file. Fortunately you usually don't have to edit this file so that day to day xinetd operation is frequently limited to only starting and stopping xinetd managed applications.

Controlling xinetd

The starting and stopping of the xinetd daemon is controlled by the by scripts in the /etc/init.d directory and its behavior at boot time is controlled by chkconfig.

You can start/stop/restart xinetd after booting by using the following commands:
[root@bigboy tmp]# service xinetd start
[root@bigboy tmp]# service xinetd stop
[root@bigboy tmp]# service xinetd restart
To get xinetd configured to start at boot you can use the chkconfig command.
[root@bigboy tmp]# chkconfig xinetd on

Controlling xinetd-Managed Applications

Xinetd-managed applications all store their configuration files in the /etc/xinetd.d directory. Each configuration file has a disable statement that you can set to yes or no. This governs whether xinetd is allowed to start them or not.
You don't have to edit these files to activate or deactivate the application. The chkconfig command does that for you automatically will also stops or starts the application accordingly too! Here is an example of the activation and deactivation of the Samba SWAT web GUI management application.
[root@bigboy tmp]# chkconfig swat on
[root@bigboy tmp]# chkconfig swat off

Telnet

Telnet is a program that allows users to log into your server and get a command prompt just as if they were logged into the VGA console. The Telnet server RPM is installed and disabled by default on Fedora Linux.
One of the disadvantages of Telnet is that the data is sent as clear text. This means that it is possible for someone to use a network analyzer to peek into your data packets and see your username and password. A more secure method for remote logins would be via Secure Shell (SSH) which uses varying degrees of encryption.
In spite of this, the older Telnet application remains popular. Many network devices don't have SSH clients, making telnet the only means of accessing other devices and servers from them. I'll show you how to limit your exposure to Telnet's insecurities are mentioned later in this chapter.

Using The Telnet Client

The command to do remote logins via telnet from the command line is simple. You enter the word telnet and then the IP address or server name to which you want to connect.
Here is an example of someone logging into a remote server named smallfry from server bigboy. The user looks at the routing table and then logs out.
[root@bigboy tmp]# telnet 192.168.1.105
Trying 192.168.1.105...
Connected to 192.168.1.105.
Escape character is '^]'.

Linux 2.4.18-14 (smallfry.my-site.com) (10:35 on Sunday, 05 January 2003)

Login: peter
Password:
Last login: Fri Nov 22 23:29:44 on ttyS0
You have new mail.
[peter@smallfry peter]$
[peter@smallfry peter]$ netstat -nr
Kernel IP routing table
Destination     Gateway       Genmask         Flags  MSS Window irtt Iface
255.255.255.255 0.0.0.0       255.255.255.255 UH     40  0      0    wlan0
192.168.1.0     0.0.0.0       255.255.255.0   U      40  0      0    wlan0
127.0.0.0       0.0.0.0       255.0.0.0       U      40  0      0    lo
0.0.0.0         192.168.1.1   0.0.0.0         UG     40  0      0    wlan0
[peter@smallfry peter]$ exit
logout

Connection closed by foreign host.
[root@bigboy tmp]#

Installing The Telnet Server Software

Older versions of RedHat had the Telnet server installed by default. Fedora Linux doesn't do this and you will have to install it yourself.
Most Linux software products are available in a precompiled package format. Downloading and installing packages isn't hard. If you need a refresher, Chapter 6, "Installing Linux Software", covers how to do this in detail.
When searching for the file, remember that the Telnet server RPM's filename usually starts with the word "telnet-server" followed by a version number as in telnet-server-0.17-28.i386.rpm.
With Debian / Ubuntu, the Telnet server package would have a "telnetd" prefix like this: telnetd_0.17-32_i386.deb.

Setting Up A Telnet Server

Setting up the telnet server is easy to do, but the procedure differs between Linux distributions.

Redhat / Fedora

To set up a Telnet server use the chkconfig command to activate Telnet.
[root@bigboy tmp]# chkconfig telnet on
You can also use the chkconfig --list command to verify that telnet will be started on the next reboot.
[root@bigboy tmp]# chkconfig --list | grep telnet
       telnet: on
[root@bigboy tmp]#
Use the chkconfig command to deactivate telnet, even after the next reboot.
[root@bigboy tmp]# chkconfig telnet off

Debian / Ubuntu

In Debian / Ubuntu, the Telnet server runs using the inetd, not the xinetd daemon, and uses a single/etc/inetd.conf configuration to manage the activation of the daemons it controls.
To stop Telnet you need only to edit the configuration file, comment out the Telnet server line, and restartinetd as seen in this example:
root@u-bigboy:~# vi /etc/inetd.conf 
...
...
...

#
# File: /etc/inetd.conf 
#

#telnet         stream  tcp     nowait  telnetd.telnetd /usr/sbin/tcpd  /usr/sbin/in.telnetd

...
...
...

root@u-bigboy:~# /etc/init.d/inetd restart
 * Restarting internet superserver...
   ...done.
root@u-bigboy:~# netstat -a | grep telnet
root@u-bigboy:~#

Note: The xinetd package provides much more flexibility than its inetd equivalent. xinetd allows you to restrict connections to specific source IP addresses and allows you to specify the TCP port and server IP address on which to listen. You may want to convert your system to use the xinetd package for Telnet by installing xinetd and creating your own custom /etc/xinetd.d/telnet configuration file. The rest of the examples in this chapter assume that the more versatile xinetd is being used.
Note: You can test whether the Telnet process is running with the following command which is used to check the TCP/UDP ports on which your server is listening, if it isn't running then there will be no response.
[root@bigboy tmp]# netstat -a | grep telnet
tcp        0        0        *:telnet        *:*        LISTEN 
[root@bigboy tmp]#

Basic Telnet Security

There are a number of things you can do to improve the security of telnet. For example, you should also try to ensure that telnet sessions run over secure internal networks or across VPNs to reduce the risk of exposing sensitive data to unauthorized eyes. Check out some other options.

Let Telnet Listen On Another TCP Port

Letting telnet run on an alternate TCP port doesn't encrypt the traffic, but it makes it less likely to be detected as telnet traffic. Remember that this isn't a foolproof strategy; good port scanning programs can detect telnet and other applications running on alternative ports.
1) Edit your /etc/services file and add an entry for a new service. Call it stelnet.
# Local services
stelnet         7777/tcp                        # "secure" telnet
2) Copy the telnet configuration file called /etc/xinetd.d/telnet and call it /etc/xinetd.d/stelnet:
[root@bigboy tmp]# cp /etc/xinetd.d/telnet /etc/xinetd.d/stelnet
3) Edit the new /etc/xinetd.d/stelnet file. Make the new service stelnet and add a port statement for TCP port 7777.
# default: on
# description: The telnet server serves telnet sessions
# unencrypted username/password pairs for authentication.
service stelnet
{
       flags          = REUSE
       socket_type    = stream
       wait           = no
       user           = root
       server         = /usr/sbin/in.telnetd
       log_on_failure += USERID
       disable        = no
       port           = 7777
}
4) Use chkconfig to activate stelnet.
[root@bigboy tmp]# chkconfig stelnet on
5) Check to make sure your server is now listening on port 7777 with the netstat command.
[root@bigboy tmp]# netstat -an | grep 777
tcp   0  0 0.0.0.0:7777       0.0.0.0:*          LISTEN
[root@bigboy tmp]#
You should now be able to log in to the new stelnet server on port 7777. This is done using the telnet command with the TCP port as the second argument.
[root@smallfry tmp]# telnet 192.168.1.100 7777
Trying 192.168.1.100...
Connected to 192.168.1.100.
Escape character is '^]'.
Fedora Core release 2 (Tettnang)
Kernel 2.6.8-1.521 on an i686
login:

Let Telnet Allow Connections From Trusted Addresses

You can restrict telnet logins access to individual remote servers by using the only_from keyword in the telnet configuration file. Here's how.
1) Add a list of trusted servers to the /etc/xinetd.d/telnet file separated by spaces:
# default: on
# description: The telnet server serves telnet sessions
# unencrypted username/password pairs for authentication.
service telnet
{
       flags          = REUSE
       socket_type    = stream
       wait           = no
       user           = root
       server         = /usr/sbin/in.telnetd
       log_on_failure += USERID
       disable        = no
       only_from      = 192.168.1.100 127.0.0.1 192.168.1.200
}
2) Restart telnet.
[root@bigboy tmp]# chkconfig telnet off
[root@bigboy tmp]# chkconfig telnet on
3) Test the telnet session. Servers that are not on the trusted list get the message Connection closed by foreign host.
[root@smallfry tmp]# telnet 192.168.1.100
Trying 192.168.1.100...
Connected to 192.168.1.100.
Escape character is '^]'.
Connection closed by foreign host.
[root@smallfry tmp]#

TFTP

Many networking equipment manufacturers allow you to backup live configurations of their devices to centralized servers via the TFTP protocol. TFTP can be used with great versatility as a network management tool and not just for saving files. TFTP servers can be used to upload new configurations to replacement devices after serious hardware failures. They also can be used for uploading new versions of software to be run as network devices. Finally, they can be used to upload even partial configurations such as files containing updated access control lists (ACLs) that restrict access to networks and even the regular application of new passwords.
TFTP may not be an application used regularly in a home, but it will become increasingly important in an expanding small office/home office (SOHO) environment which is why the topic is covered here. The provided TFTP examples use equipment from Cisco Systems, a leading networking hardware manufacturer.

Installing The TFTP Server Software

Most Linux software products are available in a precompiled package format. Downloading and installing packages isn't hard. If you need a refresher, Chapter 6, "Installing Linux Software", covers how to do this in detail.
When searching for the Fedora / Redhat file, remember that the TFTP server RPM's filename usually starts with the word "tftp-server" followed by a version number like this: tftp-server-0.33-3.i386.rpm.
With Debian / Ubuntu, the commonly use HPA TFTP server package would have a "tftp-hpa" prefix like this:tftpd-hpa_0.40-4.1ubuntu1_i386.deb.

Configuring The TFTP Server

The procedure to set up a TFTP Server is straightforward, but it is different between the Redhat and Debian distributions as we will soon see.

Redhat / Fedora

By default, the TFTP application expects files to be located in the /tftpboot directory. You can change this setting in the /etc/xinetd.d/tftp file via the server_args option. It is usually best to place the TFTP files in a partition other than the root partition. TFTP files of increasing size could eventually fill the partition affecting your ability to install new software or even the overall performance of your system. Creating a symbolic link for /tftpboot to another directory will not work with all versions of Fedora.
This example creates a new tftpboot directory in the /var partition, and then configures TFTP to be enabled while using the new directory.
[root@bigboy tmp]# mv /tftpboot /var
[root@bigboy tmp]# vi /etc/xinetd.d/tftp

#
# File /etc/xinetd.d/tftp
#
service tftp
{
...
...
       server_args             = -s /var/tftpboot
       disable                 = no
}
You must then restart xinetd for the new configuration to take effect.
[root@bigboy tmp]# chkconfig tftp on

Debian / Ubuntu

With the Debian / Ubuntu distributions, the TFTP server configuration file is /etc/default/tftpd-hpa and by default it instructs the TFTP daemon to use the /var/lib/tftpboot directory to store its files. Also by default, the daemon is disabled.
Another thing to remember is that the tftpd-hpa server daemon runs independently of xinetd and has its own startup script in the /etc/init.d directory. By default, the daemon is started at boot time, but the configuration file's default configuration setting disables it by forcing the daemon to exit prematurely.
This example enables the daemon in the configuration file and then starts the TFTP server:
root@u-bigboy:/tmp# vi /etc/default/tftpd-hpa
...
...
...
#
# File: /etc/default/tftpd-hpa    
#
#Defaults for tftpd-hpa
RUN_DAEMON="yes"
OPTIONS="-l -s /var/lib/tftpboot"
...
...
...
root@u-bigboy:/tmp# /etc/init.d/tftpd-hpa start
Starting HPA's tftpd: in.tftpd.
root@u-bigboy:/tmp#
Note: With both Redhat and Debian distributions, you can test whether the TFTP process is running with the netstat command which is used to check the TCP/UDP ports on which your server is listening. If it isn't running then there will be no response.
[root@bigboy tmp]# netstat -a | grep tftp
udp        0      0 *:tftp                  *:*
[root@bigboy tmp]#

Preparing TFTP Server Files

The TFTP server will not create files in its transfer directory if they don't already exist. Each device must have a pre-existing configuration file in the tftpboot directory. The files also need to have their permissions adjusted to allow them to be updated by the TFTP daemon.
[root@bigboy tmp]# touch /tftpboot/pixfw-config
[root@bigboy tmp]# chmod 666 /tftpboot/pixfw-config
[root@bigboy tmp]# ll /tftpboot/
total 1631
-rw-rw-rw- 1 root root 3011 Oct 29 14:09 pixfw-config
[root@bigboy tmp]#

Saving Cisco Configurations To The TFTP Server

You'll now have to configure your Cisco router/firewall to use the TFTP server. The following examples assume that the TFTP server's IP address is 192.168.1.100.

Cisco PIX firewall

Follow theses steps on a PIX firewall:
1) Log onto the device, get into enable mode and then enter the TFTP commands to initially configure TFTP.
pixfw> enable
Password: ********
pixfw# configure terminal
pixfw(config)# tftp-server inside 192.168.1.100 /pixfw-config
pixfw(config)# exit
2) Save the configuration to non volatile memory
pixfw# write memory
Building configuration...
Cryptochecksum: 3af43873 d35d6f06 51f8c999 180c2342
[OK]
pixfw#
3) Save the configuration to the TFTP server
pixfw# write network
Building configuration...
TFTP write '/pixfw-config' at 192.168.1.100 on interface 1
[OK]
pixfw#
Your firewall configuration has now been successfully saved for later use in the event of unrecoverable human error or hardware failure.

Cisco Switch Running CATOS

To save the configuration of a Catalyst-series switch running CATOS, you need to log onto the device, get into Enable mode and then enter the write net TFTP command as show below.
ciscoswitch> (enable) wr net
This command shows non-default configurations only.
Use 'write network all' to show both default and non-default configurations.
IP address or name of remote host? [192.168.1.100]
Name of configuration file?[ciscoswitch-config]
Upload configuration to ciscoswitch-config on 192.168.1.100 (y/n) [n]? y
.........
Finished network upload. (30907 bytes)
ciscoswitch> (enable)

Cisco Router

To save the configuration of a router, log onto the device, get into enable mode, then configure mode and then enter the TFTP commands as seen below:
ciscorouter> enable
ciscorouter# write net
Remote host [192.168.1.100]? 192.168.1.100
Name of configuration file to write [ciscorouter-config]? ciscorouter-config
Write file ciscorouter-config on host 192.168.1.100? [confirm] y
ciscorouter# exit

Cisco CSS 11000 "Arrowpoints"

To save the configuration of a Cisco CSS-series load balancer, log onto the device, and then enter the TFTP commands as seen below:
Log onto the device and then enter the TFTP commands as seen below:
ciscocss# copy running-config tftp 192.168.1.100 ciscocss-config
Working..(\) 100%
Connecting (/)
Completed successfully.
ciscocss# exit

Cisco Local Director

To save the configuration of a Cisco Local Director load balancer, log onto the device, get into enable mode, then configure mode and then enter the TFTP commands
ciscold> ena
Password:
ciscold# write net 192.168.1.100 ciscold-config
Building configuration...

writing configuration to //ciscold-config on 192.168.1.100:69 ...
[OK]
ciscold# exit

Uploading Cisco Configurations From The TFTP Server

From time to time you may have to upload configurations from your TFTP server to your network equipment. In this example, a small file containing a new encrypted password and access control list is uploaded from the TFTP server and inserted into a router configuration.

Sample Upload Configuration File

For this example, the configuration file is named config.file and looks like this.
!
! Set the console password
!
line con 0
 password 7 $1$qDwqJEjunK$tuff0HE/g31/b7G/IZ
!
! Delete and recreate access list #10
!
no access-list 10
access-list 10 permit 192.168.1.0  0.0.0.255
access-list 10 permit 192.168.10.0 0.0.0.255
end

Procedure To Upload A Configuration File

Uploading the file can be done using either the copy tftp: running-config or the older configure network commands. In both cases you are prompted for the IP address of the TFTP server and the name of the file with the configuration commands. The filename provided is always relative to the tftpboot directory. So if the file was located in the tftpboot directory it would be referred to as config.file, but if it were in thetftpboot/configs<code> directory, it would be referred to as configs/config.file.
Consider this sample <code>configure network command
ciscorouter>ena
Password:
ciscorouter#configure network
Host or network configuration file [host]?
This command has been replaced by the command:
         'copy <url> system:/running-config'
Address or name of remote host []? 192.168.1.100
Source filename []? config.file
Configure using tftp://192.168.1.100/config.file? [confirm]
Loading config.file from 192.168.1.100 (via FastEthernet0/0): !!!!!!
[OK - 26521/52224 bytes]
 
ciscorouter#
Here's a sample copy tftp: running-config command.
ciscorouter#copy tftp: running-config
Address or name of remote host []? 192.168.1.100
Source filename []? config.file
Destination filename [running-config]?
Accessing tftp://192.168.1.100/config.file...
Loading config.file from 192.168.1.100 (via FastEthernet0/0): !!!!!!
[OK - 26521/52224 bytes]
 
26521 bytes copied in 1.912 secs (26521 bytes/sec)
ciscorouter#
Always remember to permanently save your configurations to nonvolatile RAM (NVRAM) afterwards with the write memory or copy running-config startup-config.

Using TFTP To Restore Your Router Configuration

In disastrous cases, where you have to replace a router completely, you can use TFTP to completely restore the configuration to the replacement device. If the replacement unit is identical, then you need to do very little editing of the saved configuration file, but expect to edit it if the interface names and software versions are different.
The procedure for restoring your configuration is simple:
  1. Connect your router to the local network of the TFTP server
  2. Give your router the bare minimum configuration that allows it to ping your TFTP server. (No access controls or routing protocols)
  3. Use the copy command to copy the backup configuration from the TFTP server to your startup configuration in NVRAM.
  4. Disconnect the router from the network
  5. Reload the router without saving the live running configuration to overwrite the startup configuration. On rebooting, the router will copy the startup configuration stored in NVRAM into a clean running configuration environment
  6. Log into the router via the console and verify the configuration is OK
  7. Verify that all the required interfaces are enabled and save the configuration. You can eliminate this step by editing the saved configuration file and adding the appropriate commands prior to the TFTP upload.
  8. Reconnect the router to the networks on which it was originally connected
The commands you need are:
ciscorouter> enable
Password: ********
ciscorouter# write erase
...
...
! Enter the commands to provide a bare minimum of connectivity to
! your TFTP server here. This includes IP addresses, a default route
! and the TFTP setup commands.
...
...
ciscorouter# copy tftp:file-name startup-config
ciscorouter# reload
Please be aware that the write erase command erases your NVRAM startup configuration and should always be used with great care.

Wednesday, 24 August 2011

SSH TUNNELING

SSH tunneling

########### SSH Port Forwarding #################
Facilitates Local & Remote Port forwarding
1. Local - means to forward a port on the local system to a remote system
2. Remote - means to forward a remote port to our local host

Local Port : -L next to localport, and Remote IP
e.g. ssh -L 9000:10.10.20.290:5900 root@IP
Remote Port: -R next to RemotePort, and Localhost
e.g. ssh -R 4444:localhost:22 root@ip

Reverse SSH Tunnel

A reverse tunnel is just like the tunnel we set up with -L, except it allows the destination machine to connect to the client machine.

In the example from this article, you can create a reverse tunnel from Server to Netbook allowing Netbook to reconnect to Server. The following command, when run from Server, connects to Netbook and creates a tunnel from port 4444 on Netbook to the SSH dæmon on Server. Any shell on Netbook then can connect to Server via port 4444:

Private Server No ssh is allowed Directly
ssh -R 4444:localhost:22 load_runner
Note: -R next to port is the Remote Port (load_runner), Make sure 4444 port is not being used on load_runner.

The following command, when run from load_runner host machine, would connect to Server via the reverse tunnel:

ssh -p 4444 localhost (load_runner)
Note: You will jump into the Private Server from where the port it mapped

Forward SSH Tunnel

Many applications use protocols where passwords and data are sent as clear text. These protocols include POP3, IMAP, SMTP and NNTP. SSH can encrypt these connections transparently. Say your e-mail program normally connects to the POP3 port (110) on mail.example.net. Also, say you can't SSH directly to mail.example.net, but you have a shell login at shell.example.net. You can instruct SSH to encrypt traffic from port 9110 (chosen arbitrarily) on your local computer and send it to port 110 on mail.example.net, using the SSH server at shell.example.net:

ssh -L 9110:mail.example.net:110 shell.example.net
Note: -L next to port is the localhost port

That is, send local port 9110 to mail.example.net port 110, over an SSH connection to shell.example.net.

Then, simply tell your e-mail program to connect to port 9110 on localhost. From there, data is encrypted, transmitted to shell.example.net over the SSH port, then decrypted and passed to mail.example.net over port 110. As a neat side effect, as far as the POP3 dæmon on mail.example.net knows, it is accepting traffic from shell.example.net.
Tunneled Connections

SSH can act as a bridge through a firewall whether the firewall is protecting your computer, a remote server or both. All you need is an SSH server exposed to the other side of the firewall. For example, many DSL and cable-modem companies forbid sending e-mail from your own machine over port 25 (SMTP).

Our next example is sending mail to your company's SMTP server through your cable-modem connection. In this example, we use a shell account on the SMTP server, which is named mail.example.net. The SSH command is:

ssh -L 9025:mail.example.net:25 mail.example.net
Note: -L next to is the localhost port, make sure the port it open

Then, tell your mail transport agent to connect to port 9025 on localhost to send mail. This exercise should look quite similar to the last example; we are tunneling from local port 9025 to mail.example.net port 25 over mail.example.net. As far as the firewall sees, it is passing normal SSH data on the normal SSH port, 22, between you and mail.example.net.





LOCAL:
Flow: Client -> Port(2323) -> SSH- Tunnel Remote Host (2323)
Syntax:
ssh -L 2323:DestinationHost:2323 SSHD_Router_Server
Note: Port Forwarding in Solaris 10 supports ONLY TCP traffic
Note: -L next to is the localhost port

ssh -L 2323:linuxcbtmedial:80
Note: -L next to is the localhost port, which is being mapped to port 80

Note: Ensure that local port is free, and destination port is listening
Note: Default port forwarding provides connectivity ONLY to localhost
Cross-Check : telnet localhost 2323  Use ^] to print the web-page
netstat -anP tcp | grep 2323
rcapache2 start
rcsshd restart
svcs -l apache2 (services list) - maintenace mode
svcadm clear apache2 (service adm)
svcs -l apache2 - online

#### Remote-Desktop
rdesktop -f -a 16 ip

###### Remote Port Forwarding ###########
Note: Remote port forwarding instructs remote server's SSHD to bind to a port that becomes available to the remote system's users
ssh -R 2424:LocalHost:80 linuxcbtmedia1
ssh -R 2424:localhost:80 linuxcbtmedia1
Note: -R next to is the Remote port of the machine

### Share locally and remotely forwarded ports ###
ssh -g -L 2323:linuxgoogle:80 linuxgooglel (Makes available in the entire subnet)
ssh -g -R 2424:localhost:80 linuxgoogle

##Remote forwarded port  #### Reverse Tunnel
ssh  -R2245:127.0.0.1:22 load_runner


## Jump into Real Machine
ssh load_runner@127.0.0.1 -p 2245


#################
/bin/ps -ef | grep dhclient | sed -n '1p' | awk {'print $2'} | xargs kill -9

#Exec
The exec() family of functions will initiate a program from within a program. They are also various front-end functions to execve().
The functions return an integer error code. (0=Ok/-1=Fail).
An exec command redirects stdin to a file

#fd
File descriptors 0, 1 and 2 are reserved for stdin, stdout and stderr respectively. However, bash shell allows you to assign a file descriptor to an input file or output file. This is done to improve file reading and writing performance. This is known as user defined file descriptors.
exec fd> output.txt
    * where, fd >= 3
Eg:
exec 3> /tmp/output.txt
echo "This is a test" >&3
date >&3
exec 3<&-

############# Iptables #################

route add -net 10.10.20.0/24 gw 192.168.155.138 ( Making gateway as the vx64 box )
ping 10.10.20.81 ( pinging the compute node ) (If not pinging add iptables rules to vx64 box)

iptables -t nat -A POSTROUTING -o eth+ -j MASQUERADE
cat /proc/sys/net/ipv4/ip_forward
echo "1"> /proc/sys/net/ipv4/ip_forward

 ## Parameters Passing in Bash Shell scripts ##

This is a simple alternative to using getopts to parse parameters in a BASH shell script which makes use of the powerful parameter substitution functions in BASH. It should be sufficient for most scripts:


    until [[ ! "$*" ]]; do
      if [[ ${1:0:2} = '--' ]]; then
        PAIR=${1:2}
        PARAMETER=`echo ${PAIR%=*} | tr [:lower:] [:upper:]`
        eval P_$PARAMETER=${PAIR##*=}
      fi
      shift
    done

The script processes parameters in the format --name=value or --flag

Example output
./test.sh --number=123 --show
+ [[ ! -n --number=123 --show ]]
+ [[ -- = \-\- ]]
+ PAIR=number=123
+ echo number=123
number=123
++ echo number
++ tr '[:lower:]' '[:upper:]'
+ PARAMETER=NUMBER
+ echo NUMBER
NUMBER
+ eval P_NUMBER=123
++ P_NUMBER=123
+ shift
+ [[ ! -n --show ]]
+ [[ -- = \-\- ]]
+ PAIR=show
+ echo show
show
++ echo show
++ tr '[:lower:]' '[:upper:]'
+ PARAMETER=SHOW
+ echo SHOW
SHOW
+ eval P_SHOW=show
++ P_SHOW=show
+ shift
+ [[ ! -n '' ]]
+ set +x

Monday, 22 August 2011

Ceph Advances Open Source Distributed Filesystem to the Cloud


Cloud computing presents a new model for data delivery and data storage and it's a new model that is set to soon benefit from the Ceph filesystem.
"The open source Ceph filesystem is a distributed filesystem that is intended to be massively scalable. The system was initially created by Sage Weil, who is also the co-founder of hosting provider Dreamhost. Dreamhost is now in the process of building out hosted cloud computing and storage products that will leverage Ceph. Dreamhost is also working on integrating Ceph with the OpenStack cloud computing framework."

Sunday, 21 August 2011

Vyatta - The New Technology in Virtualization



Vyatta



The free community Vyatta Core software(VC) is an award-winning open source network operating system providing advanced IPv4 and IPv6 routing, stateful firewalling, IPSec and SSL OpenVPN, intrusion prevention, and more. When you add Vyatta to a standard x86 hardware system, you can create an enterprise grade network appliance that easily scales from DSL to 10Gbps. Vyatta is also optimized to run in VMware, Citrix XenServer, Xen, KVM, and other hypervisors, providing networking and security services to virtual machines and cloud computing environments. Vyatta has been downloaded over 600,000 times, has a community of hundreds of thousands of registered users and counts dozens of fortune 500 businesses among its commercial customers.

On this site, you'll find all the downloads, tools, documentation, and community resources to help you get up and running with your own Vyatta-based system. Ask questions in the Forums. Propose new features and vote on existing proposals. Participate and have fun. We have been working together with our community for over five years to continue to enhance the world's leading software-based network OS.

A commercial version of the Vyatta network OS (Vyatta Subscription Edition) is also available with enterprise-ready management and security product extensions and complete engineering support including proactive notifications of security alerts and software releases as well as priority access to patches & bug fixes. Vyatta SE is available as pre-integrated hardware appliances, software subscriptions and optimized virtual machines that include your choice of technical support level.

Monday, 15 August 2011

How to Deploy Software as a Service (SaaS)


Challenges of Implementing SaaS

Multi-tenant Deployment

A multi-tenant platform is one that uses common resources and a single instance of both the
object code of an application as well as the underlying database to support multiple customers
simultaneously. Although the technology stack (servers, switches, bandwidth, data storage, etc.)
in a multi-tenant deployment are shared and a single instance of code exists, customers’ user
experience should be similar to that of a user whose application was dedicated on an individual
basis, much like that of an on-premise application. Multi-tenant deployment of an application
optimizes the use of a limited set of computing resources across a large number of customers.

Multi-tenant deployment can be seen in current Web 2.0 deployments, in which applications aim
to facilitate collaboration and sharing between users. This perceived second generation of webbased
communities and hosted services, such as social networking sites, utilize centralized
application access, and are therefore able to enhance applications based on real usage statistics,
in many cases easier than the on-premise model. Gathering usage statistics and understanding
user behavior is anonymized, so the identity of the data source is kept confidential in both
consumer and enterprise-class applications. However, this delivery model poses a formidable
challenge to delivering reliable and secure application performance, in an isolated yet logically
independent, customer interaction.

Since few standards have been established for multi-tenant application delivery or the operational
governance to ensure isolation among customers, questions may surface regarding the suitability
of the SaaS model for mission-critical applications, or those applications that collect, process, and
store sensitive enterprise data. As a result, some customers still choose an isolated tenancy, or
on-premise application, to ensure complete isolation. This is a common problem for most
innovations coming to the mainstream, as they are guilty of immaturity until proven otherwise.

Several solutions to the issues associated with multi-tenant deployment exist, namely having
separate databases per customer, a shared database but separate schemas (set of database
tables), or a shared database and shared schemas. A separate database for each customer is
the most traditional approach. Although providing each customer their own database simplifies
meeting customers' individual concerns for isolation, server (and other infrastructure) provisioning
as well as installing multiple instances of a database can become time consuming and difficult to
manage. This approach also tends to lead to higher costs, which makes it less favorable.

Like the isolated or on-premise approach, the separate schema approach requires more resources to
install, configure, and maintain, but differs in that it offers a moderate degree of logical data
isolation and can support a larger number of customers per database server. However, the
approach that tends to be most favored under SaaS deployment involves using the same
database as well as the same schema to store multiple customers' data. When proper design and
implementation is achieved, this approach results in the highest efficiencies and has the lowest
server and related infrastructure costs because it allows companies to serve the largest number
of customers per database server.

Scalability

An application’s ability to service user requests in a graceful manner without giving way to lagging
response times, while remaining easy to upgrade is many times referred to its scalability.
Typically, scalability is the capability of an application to increase total throughput under an
increased load when resources (typically more servers) are added.  For example, an application
might be considered scalable if it could be moved from a limited set of servers to a larger
configuration of more robust servers, while taking full advantage of the additional server
resources and/or processing power in terms of performance (quicker response times) and
handling a larger number of simultaneous customers. Typically, it is easier to have scalability
upward rather than downward since developers must often use available resources efficiently
when an application is initially coded. Therefore, scaling an application downward may mean
trying to achieve the same results in a more constrained environment.

Given SaaS applications are delivered via the Internet, the major challenges that apply to
scalability are performance and load management. This aspect of deployment can be affected by
many complex factors, including the design of an application’s architecture, database schema,
network connectivity, available bandwidth, back office services (such as mail, proxy, and security
services), and other server resources. Depending on the size and complexity of an application, it
may be able to handle anywhere from a handful to tens of thousands of simultaneous customers.
Another contributing factor, the number of simultaneous connections made either by a customer
through the Internet or through web services will have a direct impact on an application’s
performance. Therefore, performance objectives must include two scopes: the speed of a single
customer's transaction and the amount of performance degradation related to the increasing
number of simultaneous connections.

Load management refers to the method by which simultaneous customer requests are distributed
and balanced among multiple servers. Effectively balancing loads across servers ensures that
they do not become overloaded and eventually unavailable.7 Load balancing allows an
application to scale out across a group of servers, making it easy to add capacity by adding more
replicated servers. It also provides redundancy, giving the site failover, or backup capabilities, so

the application remains available to customers even if one or more servers (sometimes referred
to as clustering as further described below) fail or need to be taken down for maintenance.8
A primary method to achieve scalability is horizontal scaling. This method involves using
hardware (such as load balancers) to distribute service requests across multiple servers.
Horizontal scaling occurs by using many machines all of which essentially function together as a
one, which is also known as clustering. By dedicating several machines to a common task,
application fault tolerance is increased. (Fault tolerance is the property that enables a system to
continue operating properly in the event of the failure of some of its components.)9 Horizontal
scaling provides a method of scalability that is not hindered by server limitations, such as
overloading. The key to successful horizontal scaling is location transparency. Location
transparency refers to making all business components or services seem as if they reside within
the same server or programming space. If any of the application code depends on knowing what
server is running the code, location transparency has not been achieved and horizontal scaling
will be difficult. This situation is called location affinity. Location affinity requires code changes to
horizontally scale an application from one server to many, which can be costly. Thus, strong
consideration should be given to location transparency when designing an application.

Reliability

Informally, reliability is the level of accuracy in which an application provides its intended services,
usually dictated by user documentation or application specifications. Reliability is about providing
correct results and handling error detection and recovery in order to avoid failures. More formally,
the mean time between failures (MTBF), that is, the average length of time the application runs
until a failure occurs, defines reliability.

Reliable applications are increasingly critical to customers. Because failure of an application can
result in lost data (as well as the possibility of lost business, data for analytics, etc.) and
considerable recovery costs, companies are requesting 24 X 7 reliability for SaaS applications in
terms of a service level agreement (SLA), commonly know as four 9s or 99.99% availability. An
SLA is a formally negotiated agreement between two parties which records the common
understanding about services, priorities, responsibilities, guarantees, etc. For example, an SLA
may specify the levels of availability, serviceability, performance, operation, or other attributes of
an application.11 The Internet has made information and immediate, error-free access to this
information, a norm to which customers have become accustomed, making reliability so much
more important. Reliability of an application as a whole depends on the reliability of the individual
components. Therefore, due to the fact that some components in a system may be related, a
failure in one component can affect the reliability of others.12

In order to ensure reliability, code review generally takes place before any major application
testing (both user interface and background services) begins. Code review can improve the
overall quality of an application by examining source code to find and fix mistakes overlooked in
the initial development phases. Testing the application through regression, unit, functional,
integration and acceptance testing are the best ways to determine its reliability. Regression
testing looks for regression bugs, or errors, which prevent the application from behaving as
intended. Regression bugs occur as an unintended consequence of program changes, usually to
functions that existed prior to a software release or update. Unit testing is used to validate that
individual units of source code, or the smallest testable part of an application, are working in the
most efficient and error-free manner possible. Functional testing measures the quality of the
business components of the system, or underlying code which is created to execute specific
functions. The test determines if each business component responds correctly to all conditions
that may be presented through inputting of data, workflow associated with data moving correctly
from one business component to the next, and that business events are initiated in the order
required to meet the business objectives of an applictaion.13 Integration testing is used to verify
functional, performance, and reliability requirements placed on the application as a result of
passing data from one system to another through some form of common comunication protocol.
Integration testing can expose problems with the interfaces among application components
before errors occur in live application execution.14 Acceptance testing is the last step in the
process and allows customers to ensure that the system meets their business requirements –
business logic, application-specific workflow, and screen behavior as anticipated.
It is important to have benchmarks in place to measure application reliability. These benchmarks
can be measured through regression, unit, functionality, integration, and acceptance testing.
Such benchmarks include identifying: faults through severity ratings, the number of continuous
hours an application operates without failure, the mean time between failures (MTBF), and
reasonable amount of time it takes for an application to recover smoothly.15

Usability
The trend in application development is migrating towards a more dynamic user experience. A
user interface is the means by which with an application, generally providing a means for input as
well as output. Technology has significantly shifted from traditional, static applications that work
independently to Web 2.0 applications, which require the capability to collaborate between
multiple users and/or applications. Gartner reports that by 2012, consumer technologies will be
fully integrated into all settings, including the office, home, remote office and recreational areas.16
This consumerization has driven the development of the user interface to increase efficiencies.

Many SaaS providers are leveraging Asynchronous JavaScript and XML (Ajax), a current
development technique, to improve overall user experience. Ajax is a method of building
interactive applications for the Web that process user requests immediately. Combining several
programming tools, Ajax allows content on Web pages to update immediately when a user
performs an action, unlike other development approaches which users must wait for a whole new
page to load. Screens refresh more quickly because only partial data is being sent back and forth,
and only certain widgets are being refreshed. For example, a weather forecasting site could
display local conditions on one side of the page without delay after a user types in a zip code.17
By incorporating Ajax, a user interface becomes more efficient, dynamic, and improves response
time. In many implementations it allows users to have a better concept of the screen they are
viewing and know where they are in a system because the background can remain visible. Ajax
can also help reduce cost in software delivery as smaller packets of data are sent back and forth,
ultimately using less bandwidth and processing resources.
The development of the user interface has also accommodated the mobile and flex workforce,
whose third screen often takes over more tasks traditionally done on a users desktop. The third
screen refers to a video screen, particularly the screen on a cell phone or personal handheld
device that a person uses almost as often as their television or computer screens. When
designing an application, developers need to consider who will be accessing the application and
from what device. The third screen specifically relates to SaaS because, as a model that parallels
to peoples’ software usage being available anywhere at any time, users should have the ability to
access from mobile devices.

Data Security

Data security is the means of ensuring that data is guarded from corruption and that access to
data is controlled. Thus, data security helps ensure the privacy and protection of sensitive
information.18

The very nature of SaaS poses security challenges. In order to detect and prevent intrusion,
strong encryption, authentication, and auditing must be a part of the application design to restrict
access to private and confidential data. Liability for the cost and damages associated with any
data breach typically rests with the independent software vendor (ISV) and / or managed services
provider, individually or collectively referred to throughout this whitepaper as the SaaS provider.19
Therefore, it is imperative for SaaS providers to make certain the SaaS applications they are
providing their customers adhere to security policies outlined in any related SLA.
Encrypting sensitive data to ensure privacy in such a public space as the Internet should remain a
top priority when designing a SaaS application. To encrypt data, information must be encoded in
such a way that only the customer or computer with a key can decode it. Two different types of

encryption exist: symmetric-key and public-key. In symmetric-key encryption, each computer
uses an undisclosed key or code to encrypt information before it is sent over the Internet to
another computer. This requires the two computers that will be communicating to have the
necessary key to decrypt the information passed to it. Public-key encryption uses a combination
of a private-key and a public-key. The private-key is known only to the computer encrypting the
information while the public-key is given to any computer that requires (and is granted) secure
communication with it. A popular implementation of public-key encryption is the Secure Sockets
Layer (SSL). SSL is an Internet security protocol used by Internet browsers and servers to
transmit sensitive information. SSL has become part of an overall security protocol known as
Transport Layer Security (TLS).20 Two examples of TLS are Hypertext Transfer Protocol over
Secure Socket Layer (HTTPS) and File Transfer Protocol (FTP), both of which encrypt data
before transferring it over a secure connection.

Authentication tools provide the ability to determine the identity of a customer attempting to
access an application. A typical method of authentication is a username and password.
Authentication is rarely used alone; in fact, it is the basis for authorization and privacy, which can
be respectfully defined as the determination of whether access to an application will be granted to
a particular customer and the act of keeping information from becoming known to unauthorized
customers.21 Authentication on the administrator and developer side is also imperative. When an
administrator or developer needs access to object code they would typically validate their identity
through token authentication. Tokens are a device characteristically small enough to be carried
in a pocket or purse, often designed to attach to a keychain. The purpose of the token is to
generate a unique code through an algorithm every “x” number of seconds. (RSA is the chosen
security partner of more than 90 percent of Fortune 500 companies.22) The number being
displayed at that moment on the secure token is used in conjunction with a personal identification
number (pin) and password. Because the token changes every “x” number of seconds and must
be used in combination with a pin and password, this approach makes data access hackerresistant.
23 This approach can also protect intellectual property (IP) of a SaaS provider in that
source, obfuscated, and object code is better protected from misuse.
Besides the transmission and retrieval of data, the storage of data is also a pressing security
concern. Outsourcing data storage to a managed services provider (a company that provides
delivery and management of network-based services, applications, and equipment to enterprises,
residences, or other service providers)24 is seen by many industry experts as the better of three
primary alternatives to ensure data security. Managed services providers are able to focus on
proper technical maintenance of servers and the remainder of the infrastructure on which a SaaS
application resides, including redundant connectivity to the Internet. In addition, most of the
leading managed services providers are required to meet auditing standards such as SysTrust
and Statement of Auditing Standards No. 70 (SAS70) (further described in the Auditing section
below).

Auditing

Audits consist of two types, namely security and information. The first type, a security audit, is
when a third party validates a managed services provider’s security profile. This is similar to an
accounting firm reviewing a company's books. The second type, an information audit, refers to a
subsystem that monitors actions to, from, and within an application. For example, an information
audit may keep a record of all of the customers and associated users that log onto an application.
Such a record is known as an audit trail.25

The need to track and log customer activity and transaction flows becomes all the more
important, especially since the ratification of the Sarbanes-Oxley Act of 2002 (SOX). Virtually
every transaction needs to be logged and/or have a sub-journal created so that after-the-fact
analysis of customer activity can be accomplished.26 Thorough and well-known audits such as
SysTrust and SAS 70 – more particularly Type II, measure compliance to high standards of data
security, and help identify whether security policies are operating efficiently over a period.

SAS 70 was developed and is carried out by The American Institute of Certified Public
Accountants (AICPA), while SysTrust was jointly developed and carried out by (AICPA) in
conjunction with the Canadian Institute of Chartered Accountants (CICA). SysTrust uses the
framework of the Principles of Trust Services and their Criteria when evaluating companies such
as managed services providers. In a SysTrust audit, the auditor evaluates whether a particular
managed services provider is reliable when compared against the principles set for security,
availability, processing integrity, and confidentiality of sensitive information which may be set forth
in the form of an SLA between the managed services provider and its customers. Using these

Principles and Criteria the following are determined:

Security: whether the system is protected against both physical and logical
unauthorized access.
Availability: whether the system is available for operation and use as committed
or agreed.
Processing Integrity: whether processing is complete, accurate, timely, and
authorized.
Confidentiality: whether business information designated as confidential is
protected as committed or agreed.

Tests are performed to determine whether a managed services provider’s system controls were
operating effectively during a specified time period. This time period is typically no shorter than
six months and generally one year or greater. If during the audit period controls are operating
effectively, an unqualified attestation report is issued. This report addresses whether a managed
services provider has maintained effective controls over its system.27
On the other hand, SAS 70, is designed more to evaluate a managed services provider's internal
controls. The auditor gives an unbiased opinion as to whether internal processes and procedures
are suitably and properly designed, put into operation, and operating effectively.
It should be noted that there are two different types of SAS 70 reports, namely Type I and Type II.

Type I assesses whether a managed services provider’s internal controls are fairly and
completely described, and whether they have been adequately designed to meet their
objectives.28 Contrarily, Type II reports are more rigorous and include the auditor's opinion on
how effective the internal controls operated under a defined review period. The review period can
be as little as six months, but is typically one year or longer. The substantial difference between

Type I and Type II reports is that Type I only lists the controls, where Type II tests the efficacy of
these controls to ensure the controls are functioning correctly.29
The major difference between the SysTrust and SAS 70 audits is the scope of the audit. While
the SAS 70 audit provides a report on the effectiveness and adequacy of internal controls for a
managed services provider, the SysTrust Audit provides a report covering an application’s
reliability.

Ownership of Data

While the SaaS model has a number of benefits that make it compelling, one of the more
challenging hurdles facing SaaS providers has been data protection and ownership. The party
responsible for safeguarding data may very well not be the same party that owns the data. In
order to minimize risk and ensure that data is properly safeguarded, it is imperative that data is
stored in a SysTrust and SAS-70 compliant environment, regardless of whether the data center is
directly operated by the SaaS provider or through a managed services provider (see Data
Security section above).

The need to restore data files may arise in as simple a situation as when a single file is
inadvertently deleted by a user from primary disk storage or as catastrophic as an on-site
disaster. Therefore, a restoration procedure and corresponding disaster recovery plan should be
in place, which document specific measures to be taken in the event that data needs to be

restored.31 These set of procedures and/or plan should identify mission critical data and how
often it should be backed up, describe where data is housed, backup procedures, what tests are
run to ensure the probability of recovery, and what resources are responsible for data recovery.
Additionally, a clear path should be detailed as to how easy a customer can retrieve data, both
raw and processed, if a decision is made to leave a particular SaaS provider.

Integration

A common definition of integration is the combination of parts so they may work together to form
a whole. In technology integration, it many times refers to the act of bringing different
applications together to run smoothly as one.32

Integrating SaaS applications with back-office systems is an important consideration in achieving
the highest level of automation possible. Many applications integrate data or functionality from
other applications through the use of mashups, whereby widgets (smaller subsets of
data/functionality) are incorporated into a single viewable screen. The ability to successfully build
such interfaces using a variety of protocols, formats, and other methods can be a critical factor
when customers evaluate SaaS offerings.33 Service Oriented Architecture (SOA) is the approach
of choice when it comes to many integration strategies.

SOA is an architectural style for creating and using business processes, packaged as services,
throughout their lifecycle. SOA also defines and provisions the IT infrastructure to allow different
applications, both SaaS and on-premise, to exchange data and collectively participate in business
processes.34 These functions are loosely coupled with the operating systems and programming
languages underlying the applications.35 SOA separates functions into distinct units, or services,
which can be distributed over a network and combined to create larger business processes
and/or workflow.36 These services communicate with each other by passing data from one
application to another, or by coordinating an activity between two or more services, such as web
services with varying degrees of encryption or security (further described under Data Security).

SOA allows applications to pass data back and forth without in-depth knowledge of each other's
IT systems behind a firewall.37 From a business perspective SOA is beneficial because it allows
for a more effective integration with business partners and supports customer service initiatives
while protecting intellectual property.38

Application Updates

Traditionally under the on-premise model the deployment of application updates and patches can
be cumbersome and time consuming. Updates are meant to deliver enhancements to an
application in order to improve functionality, user interface, or efficiency. Patches, on the other
hand, are primarily released to fix problems or bugs with an application or its supporting data
structure.39

With on-premise applications, updates tend to be larger and usually address major system
extensions or improvements. Thus, updates to on-premise applications are scarce and usually
occur between four to six months. Updates to SaaS applications, on the other hand, can happen
as frequently as every four to six weeks. The reason updates are able to occur so often is
because of the ability to roll out the application in a controlled environment. In other words,
because a SaaS application is typically delivered through a multi-tenant platform (further
explained in the Multi-Tenant Deployment section) only one instance of the application is being
updated versus having to run updates on multiple instances of an application in the on-premise
model.

More commonly, SaaS applications are developed using an agile development model. Agile
development is a method of software collaboration, which allows for small development updates
or iterations of an application to occur more frequently throughout the life cycle of an application.
Agile development minimizes risk of creating new bugs because of the minimized scope of
development. Development during one unit of time is referred to as an iteration, which commonly
last from six to eight weeks. Each iteration is usually comprised of planning, requirements
analysis, design, coding, testing, and the creation of user documentation. The goal of each
iteration is to have an available application release without software bugs being introduced.40
With smaller updates happening more frequently there is less probability of unexpected
maintenance outages. Updates are also relatively quick and typically scheduled on days and at
times where there is the least amount of user activity (i.e. for business applications, late at night
on a weekend), therefore, updates are less likely to disrupt access to an application.
Support

Support is provided in various formats, either electronically or through human intervention to
assist a customer in solving a problem or improved usage of an application. There are several
ways a SaaS provider can assist customers. For example, support staff may offer to show a
customer what steps to take via screen sharing over the Internet or perform a task remotely.
Remote support is often used in conjunction with phone support.41
t

According to Mural Ventures, top performing SaaS providers receive nearly 50 percent of their
sales through customer referrals42, therefore, it is imperative for SaaS providers to offer
customers the most responsive and effective support tools possible. Typically, support is broken
down into two tiers, namely first and second tiers. First tier support refers to customers
contacting a SaaS provider’s support staff for assistance, primarily trained on application usage
as defined within user documentation. First tier support is the initial point of contact and typically
solves 60 to 80 percent of application-related issues. Often necessary to solve customer’s more
difficult issues, second tier support many times refers to a SaaS providers ability to make
available more technical, and in many cases a software engineer, to help assess and resolve an
issue. Second tier support staff is usually also responsible for training key members of first tier
support staff, and help to provide further guidance on how to most efficiently troubleshoot an
issue.

A major challenge in providing support is the ability to manage and prioritize telephone calls that
come into a support center. Call volume is ever changing and can be difficult to predict. Some
ways to reduce the number of calls and streamline the support process is to provide back-office
tools such as an issue tracking or feedback tracking system, which allows for accurate and up to
date reporting of issues (other back-office tools include project and implementation tracking, client
billing, mass editing, and events management – further described in the second series of this
whitepaper entitled “Back-Office Automation”).

Feedback tracking systems are commonly used to create, update, and resolve reported customer
issues through tickets. A ticket is a record contained within a feedback tracking system that
includes information like submitter, application component, severity, along with ongoing progress
being made to resolve an issue. Typically, each ticket has a unique reference number, which
allows the support staff to quickly locate, add to, and communicate the status of an issue or
request, both internally and externally. Urgency is also assigned to a ticket based on the overall
importance of that issue. Other details found in tickets may include a time stamp of when the
issue was experienced, date of submission, detailed descriptions of the issue, screen captures,
attempted resolution, and other relevant information.43
Feedback tracking systems are beneficial because they are an effective accurate way for
customers to report the issue that they are experiencing at the moment it is being experienced,
which in turn allows for a higher percentage of relevant tickets to be submitted and greater
accuracy of each ticket. As data is collected within a feedback tracking system, it is pooled to
create an overall knowledge base of information for decision-making, including improvement of
an application. A knowledge base can be very powerful in providing a great degree of customer
support, in that it gives support staff the ability to pull information from previous tickets to solve
current issues. Feedback tracking systems also reduces the number of phone calls that come
into a support center, allowing support staff to better prioritize and attend to issues in a timely
manner.