12. Client Setup

12.1. Client Computer Setup Requirements

The following are requirements for a client using TACTIC.

TACTIC Temp Directory Creation

TACTIC needs to be able to create the TACTIC temporary directory. TACTIC uses this directory as scratch pad space to store temporary files.

The location of this directory depends on the client operating system:

  • Linux: /tmp/sthpw
  • Windows: C:/sthpw
  • Mac OS X: /tmp/sthpw

Set environment variables

$TACTIC_ASSET_DIR

This environment variable is used to point to the root of asset_base_dir (the directory where assets are stored). This value defaults to "/home/apache/assets" in the TACTIC server. On Windows machines, this path is usually mapped as a letter drive (for example, Z:\) or as a UNC path (for example, \\server\volume\directory\). This environment variable is set by the server on the client machine during loading if it does not already exist.

On a per-project basis, you can set the project setting with the keys "win32_client_repo_dir" and "linux_client_repo_dir" so one project can have its asset directory mapped to Drive Z: and another mapped to Drive T:.

Browser Plugins

TACTIC uses the Java plugin in many cases to communicate with the client computer’s operating system. This plugin is mostly used in application integration to pass files through the client web browser to and from the TACTIC server.

To download the latest version of the Java plugin, go to http://www.java.com

12.2. Installing Tactic on CentOS 5.7

CentOS 5.5 has now been deprecated in favour of CentOS 5.7 or CentOS 6.0. Since CentOS 5.5 will no longer receive updates and we urge you to consider using a more up to date version of the operating system such as CentOS 5.7. Step by step instructions for Tactic 3.6.0.v01 are provided below.

Requirements

Tactic requires the following software to be installed:

  • Apache HTTP server 2.2
  • Postgres Database Server 8.4 or higher
  • Python 2.7 and the following Python modules:

    • Python Imaging Library 1.1.7
    • Python LXML 2.28
    • Pycrypto 2.3
    • Psycopg2 2.3.2

It should be noted that while there may be newer versions of these Python modules, Tactic 3.6.0.v01 is built with these particular versions and may not work as intended should you use later versions.

Disabling Security for Testing

For the sake of being able to get Tactic up quickly and without a large amount of fuss it is prudent to disable firewalling and SELinux. This is by no means an endorsement to run your server without these services. Once you have Tactic up and running we encourage you to read the section <TACTIC SECURITY>.

CentOS 5.7 uses the iptables service as a firewall. To disable this temporarily you can issue the following commands as root.

/etc/init.d/iptables save
/etc/init.d/iptables stop

This will disable the firewall for the currently running CentOS session. Should you wish these settings to persist across reboots. You can issue the following command as root.

/sbin/chkconfig iptables off

To disable SELinux, edit the file /etc/selinux/config as root with your favourite editor and set the SELINUX variable to disabled.

SELINUX=disabled

Getting this setting to take effect requires a reboot.

Installing Apache HTTP server

To install Apache 2.2 on CentOS 5.7 issue the following command as root:

yum install httpd

This package has several dependencies and they should be installed as well.

It would be good to familarize yourself with some of the more pertinent paths in the Apache installation on CentOS5.7. We’ve listed them below for your convenience.

Table 6. Common Paths in Apache 2.2

/etc/httpd/conf/httpd.conf

Path to the main Apache configuration file.

/etc/httpd/conf.d/

Path to the Apache dynamic configuration directory.

/var/log/httpd/error.log

Path the the Apache error log.

/var/www/html

Path to the Document Root folder of the base Apache install.


It’s best to test your Apache install at this point. The included main Apache configuration file is enough to get the server started. You will need create a small html file to do this. Using your favourite editor create a file called index.html, including the following contents:

<html>
  <head>
    <title>Apache Base Install</title>
  </head>
<body>
   <p>Apache Install Successful</p>
</body>
</html>

Save the file in /var/www/html and issue the following command as root to ensure proper permissions are set.

chmod 755 /var/www/html/index.html

Now we can start the Apache server itself. As root issue the following command.

/etc/init.d/httpd start

The service should start successfully. If it does not consult the Apache error log listed above to discover any problems that may have occured.

At last we should now be able to point a web browser to the IP address associated with the server. If you see the text "Apache Install Successful", then your server is up and running and server pages properly.

Finally we will want the Apache service to persist through reboots. As root issue the following command:

/sbin/chkconfig httpd on

Then reboot the server and make sure that httpd comes up on reboot and that you can view the test page properly. Later in the install we will configure the Apache server to interact with Tactic properly.

Installing Postgres Database Server

CentOS 5.7 repositories use Postgres version 8.1.23-1. However Tactic requires version 8.4 or higher. First we must make sure that we didn’t include the default version Postgres in our base install. As root please issue the following command:

rpm -qva | grep -i postgres

This command will search your installed packages and filter the output for any packages containing the work postgres. If you receive any output from this command please uninstall the packages by issuing the following command:

rpm -e <package_name>

Where <package_name> is the name of the package you wish to uninstall. Consult the RPM or Yum manpages for further instructions on installing and uninstalling packages.

Lastly before installing any new Postgres repository, we want to make sure to exclude the default version of Postgres from showing up in the base and update Yum repositories included with the operating system itself. Using your favourite editor, edit the file /etc/yum.repos.d/CentOS-Base.repo to include the line:

exclude=postgresql*

Under both the [base] section and the [updates] section of the file. Save the file. For more information on the Yum installer and repository system please see the manpages for yum or the yum website http://yum.baseurl.com

Once we have uninstalled any previous versions of Postgres, we can then proceed installing a new Yum repository that contains the version of Postgres we want to install. As root issue the following commands:

cd /tmp
wget http://yum.pgrpms.org/9.1/redhat/rhel-5-i386/pgdg-centos-91-9.1-4.noarch.rpm
rpm -Uvh pgdg-centos-91-9.1-4.noarch.rpm

At the time of writing the current version of Postgres was 9.1-4, for more current installation versions please visit http://yum.pgrpms.org/repopackages.php and view the available repository RPMs for your operating system and architecture.

Lastly we will install the proper Postgres version 9.1 RPMs. As root issue the following command:

yum install postgresql91 postgresql91-server postgresql91-devel

Now that Postgres is installed we will do some basic configuration and testing to make sure our installation is ready for use with Tactic.

Again we should first familiarize ourselves with the pertinent Postgres file paths that will be used throughout the install:

Table 7. Common Paths in Postgres 9.1 on CentOS 5.7

/var/lib/pgsql/9.1

Path to the main Postgres directory.

/var/lib/pgsql/data/pg_hba.conf

Path to the host based authentication file for Postgres.

/var/lib/pgsql/9.1/pgstartup.log

Path to the Postgres startup log.

/var/lib/pgsql/9.1/data/pg_log

Path to Postgres database logs.


If you have used the base postgresql-server install before you will notice that the above paths are slightly different than the usual paths used on CentOS. This install also varies from the base install in that the user must manually initialize the databases used by Postgres. To do this issue the following command as root:

/etc/init.d/postgresql-91 initdb

Once that command successfully completes we can then start the service. As root issue the following command:

/etc/init.d/postgresql-91 start

If the service starts successfully we can move forward. If not please view any startup errors in the Postgres startup log. Further troubleshooting help can be found at http://postgresql.org,

Lastly we will want to make sure the Postgres service persists through reboots. As root issue the following command:

/sbin/chkconfig postgresql-91 on

Reboot your server to ensure the service comes up appropriately.

Installing Python 2.7

As noted above Tactic requires version 2.7 of Python. CentOS comes with, and depends on an earlier version of Python. This means we simply can’t remove Python from the system as we did with Postgres. We have to create a custom Python 2.7 install and keep it seperate from the base install.

First we need to install some development libraries and a compiler. As root issue the following command:

yum install gcc zlib-devel libxslt-devel libxml2-devel

Once those are installed we can get Python 2.7, as root issue the following command:

cd /tmp
wget http://www.python.org/ftp/python/2.7.1/Python-2.7.1.tgz
tar -zxvf Python-2.7.1.tgz
cd Python-2.7.1
./configure --prefix=/opt/python2.7
make && make install

This will install Python 2.7 in the custom path /opt/python2.7. You can choose a different custom install directory should you choose.

Installing Python 2.7 Modules

Next we will install the necessary Python 2.7 modules. These provide extended functionality to the Python environment. Before we begin however we will have to set an environment variable such that the Python 2.7 modules we are installing can find their link dependencies. In the BASH shell environment as root issue the following command:

export LD_LIBRARY_PATH=/opt/python2.7/lib

This will prefix your link dependency library path with our custom python libaries ensuring they get precedence in the installation of the modules. This environment variable only exists for the current shell environment. Any new shells you open will need to have this variable set as well. We will institute a permanent solution to this problem later.

Installing LXML 2.28

Tactic requires LXML version 2.28. At the time of writing Tactic encountered errors running with LXML 2.3 installed. Please make sure you install LXML 2.2x. Installation and setup for each module is almost the same. As root issue the following commands

cd /tmp
wget http://codespeak.net/lxml/lxml-2.2.8.tgz
tar -zxvf lxml-2.2.8.tgz
cd lxml-2.2.8
/opt/python/bin/python2.7 setup.py install

We have used the location of our custom installed python binary in the last line, if you have chosen a different install location use it instead.

Verify the installation by running your custom python binary and trying to import the module. As root issue the following command:

/opt/python2.7/bin/python2.7

You should receive a python environment and prompt similar to this:

Python 2.7.1 (r271:86832, Apr 12 2011, 16:16:18)
[GCC 4.1.2 20080704 (Red Hat 4.1.2-51)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>>

At the prompt please type the following:

import lxml

If you receive another prompt and no error occurs, the import was successful and LXML is installed. We will use the same procedure to check the veracity of our other modules installations as well.

Installing Python Imaging Library 1.1.7

We follow the same procedure to install the Python Imaging Library. As root issue the following commands:

cd /tmp
wget http://effbot.org/downloads/Imaging-1.1.7.tar.gz
tar -zxvf Imaging-1.1.7.tar.gz
cd Imaging-1.1.7
/opt/python2.7/bin/python2.7 setup.py install

Check the installation of the module by loading python and issuing the following command at the python prompt.

import PIL

Installing Pycrypto 2.3

The installation of Pycrypto also follows this template. As root issue the following commands:

cd /tmp
wget http://pypi.python.org/packages/source/p/pycrypto/pycrypto-2.3.tar.gz
tar -zxvf pycrypto-2.3.tar.gz
cd pycrypto-2.3
/opt/python2.7/bin/python2.7 setup.py install

Check the installation of the module by loading python and issuing the following command at the python prompt.

import Crypto

Installing Psycopg2 2.3.2

Psycopg2 is a Postgres database adapter for Python. The install is akin to the previous 3 except that since we’ve customized our Postgres install, we have to let Psycopg2 know that as well. First lets get the package and uncompress it. As root issue the following:

cd /tmp
wget http://pypi.python.org/packages/source/p/psycopg2/psycopg2-2.3.2.tar.gz
tar -zxvf psycopg2-2.3.2.tar.gz
cd psycopg2-2.3.2

Now we have to modify the pg_config variable in the file setup.cfg. Using your favourite editor open /tmp/psycopg2-2.3.2/setup.cfg and edit the pg_config entry to match the following:

pg_config=/usr/pgsql-9.1/bin/pg_config

Now we should be able to install Psycopg2 properly. As root issue the following command:

/opt/python2.7/bin/python2.7 setup.py install

Check the installation of the module by loading python and issuing the following command at the python prompt.

import psycopg2

Now that all the Tactic components are installed, we can begin installing Tactic itself.

Installing Tactic 3.6.0.v01

First we have to download the Tactic source from the Southpaw Tech Support website. Using a web browser navigate to http://support.southpawtech.com and login using the support account you were assigned. After you have logged in, please click on "Downloads" in the upper right hand corner of the website. Once you are on the downloads page, you should see the download link for the Tactic 3.6.0.v01 source code. Save the Tactic source code zip file in /tmp on the server.

Once we have the Tactic source we need to unpack it. As root issue the following commands:

cd /tmp
unzip tactic-3.6.0.v01.zip

Once the Tactic source is unpacked, you should familarize yourself with the Tactic directory structure. The prefix of the paths will change during install, however the directory structure will remain the same.

Table 8. Common Paths in Tactic 3.6.0.v01

/tmp/tactic-3.6.0.v01/doc

Path to the Tactic documentation.

/tmp/tactic-3.6.0.v01/src

Path to the Tactic source files.

/tmp/tactic-3.6.0.v01/src/install

Path to the Tactic install script and configuration files for Tactic dependencies.


Before we run the Tactic installer, we must further configure Postgres to ensure proper installation of Tactic.

Configuring Postgres

Tactic supplies a custom host based authentication file for Postgres. After stopping the Postgres service we will install the file in question, restart the service and verify that the configuration has been properly put in place. As root issue the following commands:

/etc/init.d/postgresql-9.1 stop
mv /var/lib/pgsql/9.1/data/pg_hba.conf /var/lib/pgsql/9.1/data/pg_hba.conf.INSTALL
cp /tmp/tactic-3.6.0.v01/src/install/postgresql/pg_hba.conf /var/lib/pgsql/9.1/data/pg_hba.conf
chown postgres:postgres /var/lib/pgsql/9.1/data/pg_hba.conf
/etc/init.d/postgresql-9.1 start

If the service starts successfully we can then move onto testing. If not please consult the Postgres startup log for error information. Postgres must be running as a service during the Tactic install. Next we will test the install, as root issue the following commands:

psql -U postgres template1

This command should return you to a prompt like this one:

template1=#

If you are not prompted for a password and, see this prompt, then the configuration changes have been successful. Type \q to exit.

Installing Tactic

We are now ready to run the Tactic installer. The installer doesn’t know about our custom Python installation location though, so we have edit the install.py file. Using your favorite editor, edit the file /tmp/tactic-3.6.0.v01/src/install/install.py.

Find the following line in the file:

python_site_packages_dir = "/usr/local/lib/python%s.%s/site-packages"

Replace it with the following line:

python_site_packages_dir = "/opt/python2.7/lib/python%s.%s/site-packages"

Save the file. We will test this by running the installer. Make sure you are using a shell with the LD_LIBRARY_PATH set as mentioned in the "Installing Python 2.7 Modules" section. As root issue the following command:

/opt/python2.7/bin/python2.7 /tmp/tactic-3.6.0.v01/src/install/install.py

The installer will ask you a number of questions. You should be prompted by the following:

Please enter the base path of the TACTIC installation:

(/home/apache) -> /opt/tactic

Choose your custom Tactic path, this will be the base directory for your Tactic installation. We have chosen /opt/tactic. Next you will be asked to identify the user used to run the Apache service.

Please enter the user Apache Web Server is run under:

(apache) ->

In many cases the default user "apache" is correct. However you can verify this easily in another shell by issueing the following command as root:

ps -ef | grep httpd

The first column of output is the username Apache is running under. Should you receive no output, make sure your httpd service is running. Under CentOS 5.7 the apache user is "apache" so we will accept the default the installer gives us.

The installer will then install the Tactic databases, configure Tactic and copy the source code into the Tactic base directory.

Configuring Apache

Lastly Tactic requires us to install the custom Apache configuration file it has created during the installation process. As root issue the following commands:

cp /opt/tactic/projects/config/tactic.conf /etc/httpd/conf.d

To test this we should first verify that /etc/httpd/conf.d is an included module path in the main Apache configuration file. As root issue the following command:

cat /etc/httpd/conf/httpd.conf | grep conf.d

If you receive the following as output we have installed the Tactic Apache configuration file correctly.

Include conf.d/*.conf

If you do not receive this output, using your favourite editor as root edit the file /etc/httpd/conf/httpd.conf and at the bottom of the file insert the statement listed above. Save the file.

Lastly we will create a redirect for Tactic using the index.html file at the document root of the Apache server. Using your favourite editor as root, edit the file /var/www/html/index.html to contain only the following line:

<META http-equiv="refresh" content="0;URL=/tactic">

Restart the Apache service to make sure the configuration hasn’t caused any problems. As root issue the following command:

/etc/init.d/httpd restart

Lastly we need to ensure that the Apache server has loaded the modules needed for proxying and load balancing the Tactic service. As root issue the following command:

/usr/sbin/httpd -t -D DUMP_MODULES

In the resulting output look for the following modules:

rewrite_module (shared)
proxy_module (shared)
proxy_http_module (shared)
proxy_balancer_module (shared)
deflate_module (shared)

The CentOS 5.7 install of Apache includes a large array of modules enabled by default, including the ones required by Tactic.

Starting Tactic in Development Mode

We are now prepared to start the Tactic service for the first time. Tactic must be run as the Apache user. Usually we would su to the apache user, however since its a system account without a login this will not work without optionally telling su to give the Apache user a shell environment. In a shell with the LD_LIBRARY_PATH set as laid out in the section "Installing Python 2.7 Modules", as root issue the following command:

su apache -s /bin/bash -c "/opt/python2.7/bin/python2.7 /opt/tactic/tactic/src/bin/startup_dev.py"

You should see the following output:

Registering site ... admin
Registering site ... sthpw
Registering site ... default

Starting TACTIC ...

Starting Scheduler ....
[08/Nov/2011:23;13:20] ENGINE Bus STARTING
[08/Nov/2011:23;13:20] ENGINE Started monitor thread '_TimeoutMonitor'.
[08/Nov/2011:23;13:20] ENGINE Started monitor thread 'Autoreloader'
[08/Nov/2011:23;13:21] ENGINE Serving on 127.0.0.1:8081
[08/Nov/2011:23;13:21] ENGINE Bus STARTED

You should now be able to navigate a web browser to http://localhost/tactic/admin. Alternatively use the non-local IP address or fully qualified domain name you have assigned to your Tactic server in place of localhost. You should see the Tactic login screen.

Tactic defines an administrative user by default. The login information is:

Username: admin; Password: tactic
Using these credentials you should now be able to log into the Tactic server. Use the key combination CTRL+c in the shell running the Tactic Developer mode service to break out of it when you are ready.

Installing Tactic as a Service

The Tactic service file is simple to install, however due to the custom Python pathing we have used we have edit the Tactic service file to reflect those changes. As root, using your favourite editor open the file /opt/tactic/tactic/src/install/service/tactic and make the following changes.

The Python environment variable PYTHON should be set to the path of our custom Python binary.

PYTHON=/opt/python2.7/bin/python2.7

Additionally we want to setup the LD_LIBRARY_PATH variable to include our custom Python libraries. Under the following line:

export PYTHON

Add the following lines to the file:

LD_LIBRARY_PATH=/opt/python2.7/lib
export LD_LIBRARY_PATH

Lastly, Tactic startup uses the same mechanism as Developer mode, however this is not yet reflected in the Tactic service file. Change the following line:

 su - $TACTIC_USER -m -c "$LAUNCH" >> $LOG 2>&1 &

To this:

su $TACTIC_USER -s /bin/bash -m -c "$LAUNCH" >> $LOG 2>&1 &

Save the file.

One last Python path must be corrected before we install the Tactic service. During installation Tactic created a file that you will become more familiar with throughout your use of Tactic. That file is /opt/tactic/projects/conf/tactic_linux-conf.xml. Using your favourite editor as root edit this file. Find the following line:

<python>python</python>

And replace it with:

<python>/opt/python2.7/bin/python2.7</python>

Save the file.

Now we will install the Tactic service. As root type the following:

cp /opt/tactic/tactic/src/install/service/tactic /etc/init.d/tactic
chmod 755 /etc/init.d/tactic
/sbin/chkconfig tactic on
/etc/init.d/tactic start

Tactic should now start properly as a service. Test this by launching a web browser and navigating to the Tactic login page as you did previously. If you are having trouble the following error logs will help you diagnose your problems:

Table 9. Common Error Logs

/var/log/tactic

Path to the Tactic error log.

/var/log/httpd/error_log

Path to the Apache error log.

/var/log/httpd/access_log

Path to the Apache access log.


Finally we want to test that the Tactic service will persist across reboots. Reboot the server and test whether the Tactic service continues to perform.

12.3. TACTIC Authentication

12.4. Configuring TACTIC and Co-Services

TACTIC Service Configuration

Overview

Multiple TACTIC servers can be leveraged in environments where there is heavy report analysis, and where custom TACTIC environments are making heavy use of API and GUI calls. To spread out the load of the requests made, custom API scripts can be run on one TACTIC server, while another TACTIC server can be used to serve GUI requests. The only consideration then with multiple TACTIC machines will be where the database and the asset directories.

Database

TACTIC needs to know where to find assets and asset metadata. To do this, each installation of TACTIC must be able to have direct file system access to assets storage, and network access to the database co-service.

tactic_(os).conf

needs to contain this information.

<database>
<server>[DB server IP]</server>
</database>

All other settings, covered previously, can be set according to individual requirements of the host machine and environment.

Assets Storage

TACTIC needs to know where to find assets. To do this, each installation of TACTIC must be able to have direct file system access to assets storage. The details of file system management are beyond the scope of this document, but typically are within the realm of the system administrator.

Processes

If the TACTIC server has no other services attached, there is probably room to increase the number of processes running on each machine.

<services>
<process_count>6</process_count>
</services>

Refer to Reference: TACTIC Default Configuration for the complete sample configuration file.

Refer to Reference: TACTIC Service Configuration Directives for configuration directives.

HTTP Co-service Configuration

Apache

Apache is used for the following sample HTTP configuration for TACTIC. Some configuration knowledge of apache is required.

Permissions – Allowing TACTIC to store and manipulate assets

This section defines the location and availability of the assets directory, which is the primary source of data for the apache server. There is also the declaration of an alias to the TACTIC source directory, which contains various objects that TACTIC uses, such as widget elements.

Alias /context         /home/apache/tactic/src/context
Alias /assets       /home/apache/assets
Alias /doc/           /home/apache/tactic/doc/

The section with <Directory> directives defines the access rules for the assets directory and the "/tactic" directory, which is just a conveniently named alias.

<Directory "/home/apache/tactic" >
    Options FollowSymLinks
    AllowOverride None
    Order Allow,Deny
    Allow from All
</Directory>
<Directory "/home/apache/assets" >
    Options FollowSymLinks
    AllowOverride None
    Order Allow,Deny
    Allow from All
</Directory>

Proxying/Rewriting a single process – Redirecting requests to TACTIC

Apache needs to know where to find the proxied TACTIC service in the httpd.conf file. The below configuration takes advantage of only one process being served from port 8081 on the local machine.

The second section, with RewriteRule directives, defines the re-write rules for the TACTIC service, to segregate requests handled by the TACTIC server, from static asset delivery through the HTTP service. These rules channel any requests that are prefixed with the "/tactic" path to the TACTIC server on port 8081.

RewriteRule   ^/tactic/(.+)$ http://localhost:8081/tactic/$1 [P,L]
RewriteRule   ^/tactic http://localhost:8081/tactic/ [P,L]
RewriteRule   ^/projects/(.+)$ http://localhost:8081/tactic/$1 [P,L]
RewriteRule   ^/projects http://localhost:8081/tactic/ [P,L]

Proxying/Rewriting multiple processes – Redirecting requests to TACTIC

The proxy configuration can be enhanced with a load balancing scheme for one or more machines. Apache has the ability to randomly select from a list of locations via a rewrite map.

RewriteMap    lb    rnd:/home/apache/sites/load_balance.txt

This map can feed the rewrite rules with a dynamically assigned host name.

RewriteRule   ^/tactic/(.+)$ http://${lb:dynamic}/tactic/$1    [P,L]
RewriteRule   ^/projects/(.+)$ http://${lb:dynamic}/tactic/$1  [P,L]
RewriteRule   ^/tactic http://${lb:dynamic}/tactic/            [P,L]
RewriteRule   ^/projects http://${lb:dynamic}/tactic/          [P,L]

The file load_balance.txt is an arbitrarily named and located file that contains the names of servers that will be referred to by the "rnd" function in the Rewrite rules. The "lb:dynamic" reference will be replaced by the name of the server file

The load_balance.txt contains a pipe separated list of hosts named "dynamic"

dynamic localhost:8081|localhost:8082|localhost:8083

This list is dependent on the number of ports that TACTIC is running on, specified by tactic_(OS).conf. Note that apache can proxy from IP addresses or hostnames external to the host that the service is parked on.

On this single line list, add all machines and ports that are running TACTIC. Since the scheme algorithm is random, it does not matter what order the machines/ports are listed in, just that they are actually on the list. In this case, there are multiple TACTIC machines, named "tacticserver01" and "tacticserver02". The example assumes the machine has either DNS entries for these machines or entries in the "hosts" file. IP addresses can also be used.

dynamic tacticserver01:8081|tacticserver02:8081|tacticserver01:8082
# and so on, until all machines/ports are covered

Refer to Reference: Apache Configuration for TACTIC for the complete sample configuration file.

Database Co-service Configuration

PostgreSQL

PostgreSQL is used as the database co-service in the following sample configuration. PostgreSQL has only two configuration files that are required to be examined in order to function with TACTIC; pg_hba.conf and postgresql.conf

Network trust - pg_hba.conf

The pg_hba.conf configuration file contains a list of users and hosts with clearance levels. In the default pg_hba.conf file that comes with TACTIC, the network trust level is set for the most open access by the localhost;

# TYPE  DATABASE    USER        CIDR-ADDRESS          METHOD
local      all  all  trust
# IPv4 local connections:
host    all         all         127.0.0.1/32          trust
# IPv6 local connections:
host    all         all         ::1/128               trust

In this example, all local connections to PostgreSQL are trusted. This configuration matches the correct configuration required by a single machine.

host   all     all  <TACTIC_HOST_IP_ADDR>     trust

Network interface - postgresql.conf.

The postgresql.conf configuration file has a setting that will allow the PostgreSQL service to bind to the particular interface required.

Of concern is the "listen_addresses" attribute.

listen_addresses = 'localhost'

By default, the PostgreSQL service is only bound to the localhost. This is fine for single machine operation of the TACTIC service.

listen_addresses = '*'

This setting or specific IP addresses can be used if the DB service is not on the same machine as the TACTIC service

12.5. Scalable TACTIC Deployment Planning

The stages of a TACTIC deployment are:

  • \1. Determining usage requirements
  • \2. Determining hardware requirements
  • \3. Determining TACTIC Service and Co-Service Locations
  • \4. Post Deployment TACTIC upscaling

Planning NOTES

Determining TACTIC Usage Requirements

One of the first questions asked in a TACTIC deployment is "what kind of deployment is required?" This is a hard question to answer unless it is known beforehand exactly how TACTIC will be used. Since every TACTIC deployment is customized by the licensee, there is really no way to calculate accurately the type of load that will eventually be placed on the TACTIC server. Fortunately, due to TACTIC’s scalable architecture, a TACTIC deployment can be scaled up easily when there are unforeseen increases in usage.

Service Requirements

In a TACTIC deployment, running the TACTIC service is the primary function of the TACTIC host machine. The co-services can be deployed to the location most appropriate for the environment. However, to ensure scalability and high availability, the co-services should not be deployed on the TACTIC host for any but the smallest of deployments.

TACTIC uses four major services and co-services in its operation:

  • TACTIC service: provides the API and GUI widget system.
  • Database co-service: provides indexing and storage for asset meta data.
  • HTTP co-service: provides delivery (and return) of raw asset data.
  • Assets storage co-service: provides storage and back-up capabilities of raw asset data.

Limitations

With TACTIC, you can simply add hardware and load-balance it to handle more and more requests. You can expand scalability in this way until the database server itself becomes the bottleneck. Fortunately, with the introduction of multi-CPU and multi-core machines, database limits are extremely high.

User Interfaces: For applications with end-user interfaces (especially those using widgets, where complex interface elements need to be constructed), the load required to process TACTIC requests will remain much greater than the load required to process SQL calls, no matter how much hardware is added to handle such requests.

Client APIs: Client APIs provide a much thinner layer to the database and so are optimized to handle lower level requests very rapidly. However, because API calls are typically used for automated processes, they can generate a large number of requests quickly, creating a heavy load on the TACTIC server.

Load balancing: this is especially important for render farms, which can be massive in scale with thousands to tens of thousands of cores. It ensures that the high volume of requests is evenly distributed to all of the available TACTIC processes. The exact number of processes required to handle the high volume is highly dependent on the number of requests made and to the complexity of the requests. However, because load balancing will provide near-linear scalability, the number of processes can be increased to a level that is sufficient for the number of requests being demanded of the client API.

Report generation: TACTIC’s reporting system is powerful and comprehensive, and the load on host CPUs can increase significantly when complex reports are being run. Administrators should focus on report generation when investigating load utilization.

Checkins: There are two kinds of complexity when considering scalability for checkins:

  • Large Checkins: TACTIC offers a wide variety of checkin configurations that will accommodate large bandwidth, large files, and complex dependency between files.
  • Many Checkins: There are few concerns with a large number of checkins. The number of checkins that occur even in the largest of productions is small compared to the limits of a database.

Determining TACTIC Hardware Requirements

Hardware Overview

TACTIC works well with most types of hardware, but industry-standard server level components are highly recommended. The exact configuration will depend on the specific needs of your facility.

For most deployments, TACTIC can be installed on the typical commodity hardware used by most small and large enterprises. TACTIC is a purpose-built relational database at its core, and your hardware choices can reflect that fact.

TACTIC service requirements: Assuming TACTIC is the only service on the host, the minimal requirements for a production-level deployment of a TACTIC host are:

  • CPU: dual core
  • Memory: 4G
  • Disk space needed for TACTIC to run on: 10G

    (assets should be stored elsewhere, on an enterprise quality server)

These requirements represent the recommended absolute minimal hardware required to run a basic TACTIC service in a production environment. For development and testing, TACTIC will run on most hardware including laptops.

Asset storage: It is highly recommended that assets be stored on an enterprise-quality, high-availability server, and not on the TACTIC host.

RAID Options: You can use various RAID configurations to maximize reliability and performance. For example, you could locate the Operating System on one physical drive, and the database files on another. Or you could locate the database on a RAID array.

Asset meta data: The amount of asset meta data stored on disk by TACTIC is insignificant to today’s hardware specifications and need not be a consideration when choosing a server: reliability and performance should be higher concerns.

Determining TACTIC Service Locations

Segregating Services

TACTIC offers a number of different services for different purposes. For example, the TACTIC server can serve out complex widgets, serve out large numbers of client API requests and perform large, complex check-ins.

Each type of service has distinct needs, so it is often beneficial to segregate the services to be independent of each other. This allows each service to operate within a pool of assigned resources without affecting (or being affected by) the other services.

For example, if a render farm used a client API script that heavily loaded the TACTIC server and its requests were shared with user interface requests, users would experience inconsistent (and occasionally unacceptably slow) response times. This experience would cause frustration amongst users, so it would be necessary to segregate their user interface service from the render farm’s client API service.

Each type of service has very different demands and needs, so segregating services also allows you to tune the hardware and software to the specifications required for the service they are handling. Ultimately, you can maximize the use of your available resources.

How Load Balancing Works

Load balancing distributes requests to various TACTIC processes using an algorithm that determines which request is delegated to which process. The default algorithm is a very simple randomizer.

For most applications, the default algorithm works perfectly fine. It is left to chance whether a particular request will be assigned to a heavily loaded process or one that is sitting idle, so there may be inconsistent performance depending on load and availability of TACTIC processes not already loaded.

IIS delegation algorithms (on MSWeb Server) are also supported. For Apache, an example algorithm is provided you can customize to your needs.

Each process, by default, is assigned two simultaneous requests at most. This limit has proven in production to be the most effective because it prevents the Python process itself from being overloaded waiting for required I/O operations. If there are excess requests waiting to be processed, they are kept in a queue and assigned sequentially to processes as they become available.

Python’s GIL (global interpreter lock) prevents any Python process from using more than one CPU or core, so the number of threads available for any given process is limited. True scalability is achieved by load-balancing requests over multiple processes. This method scales seamlessly and linearly over multiple cores, multiple CPUs and ultimately over multiple physical servers with only simple configuration changes.

Post Deployment TACTIC Upscaling

Scenarios

TACTIC is easily upscaled in most post deployment scenarios. Upscaling does not require any significant downtime of TACTIC services.

Some scenario examples follow, with bullet points outlining why these possible solutions would be followed;

Increasing number of TACTIC processes on a single machine

Splitting TACTIC into multiple servers from one server

  • Easy way to upscale/troubleshoot
  • Heavy reporting
  • Many users/API calls from automated processes

Splitting the HTTP co-service into multiple servers from one server

  • Many Checkins
  • Large Checkins

12.6. General TACTIC Install

This document guides you through the general installation of TACTIC in Fedora Linux with some brief background information. For installation on Windows or CentOS, please refer to the corresponding sections in this book. To completely install TACTIC, there are three main components that have to be set up in the following order:

  1. A Database
  2. The TACTIC Installer
  3. A Web Server

TACTIC stores all metadata in a database called PostgreSQL. This is an industrial strength, hugely scalable database that has proven itself in thousands of industries around the world. We currently recommend 8.4 and upwards for ease of installation. Go to the PostgreSQL website for more information.

rpm -Uvh http://yum.pgrpms.org/reporpms/8.4/pgdg-fedora-8.4-2.noarch.rpm

yum install postgresql postgresql-server postgresql-contrib postgresql-devel

It is located in /var/lib/pgsql/data This file determines all of the user permissions for PostgreSQL. To begin with, turn on all of the permissions contained in this file. This is a temporary measure that will greatly simplify the installation process. You may lock down these permissions at a later date. Please consult the PostgreSQL documentation on how to do this. TACTIC ships with a sample "pg_hba.conf" file (located in <TACTIC_unzipped_ package>/src/install/postgresql/pg_hba.conf). This file has an open security setting for ease of installation. It’s best to back up your current pg_hba.conf file before copying over with the file provided by TACTIC.

Restart the PostgreSQL Service

Verification

Verify that psql works in the command prompt:

> psql -U postgres template1

It should give you a prompt:

template1=#

If you see this prompt without the need to enter a password, you have successfully installed the PostgreSQL database. Type \q to exit.

Install Python and supporting modules

The TACTIC source code is written in Python. As such, the complete codebase is open.

To install Python, you can find an msi at http://www.python.org. TACTIC requires Python 2.6 or higher.

TACTIC also requires a number of Python modules to function correctly. These modules are generally not installed by default with the standard Python distributions. For Windows, they are already packaged in a file python_modules.zip available for download in the release section of the downloads page at http://support.southpawtech.com/downloads

  • PIL 1.1.7

    (Python Image Library) * ImageMagick 6.7.8

    (A command line program which complements PIL) -

    http://www.imagemagick.org * FFmpeg version 0.6(Solution to record, convert and stream audio and video and metadata parsing) - http://www.ffmpeg.org * psycopg2 2.3.1

    (Database connectivity) * PyCrypto version 2.0.1/2.1

    (For de-encrypting the license file) -

    http://www.amk.ca/python/code/crypto * simplejson 2.1.1 (not needed since Python 2.6)

    simplejson.egg can be installed with the EasyInstaller. It is need for JSON string encoding and parsing * lxml 2.1 or 2.2

    (XML and XPath processing)

Unzip the file in a temporary location.

# cd /tmp
# unzip tactic_#.#.#.#.zip

Go to /tmp/tactic_#../src/install/

# cd /tmp/tactic_#.#.#.#/src/install

Execute: install.py

Note

You must invoke the installation with root user privileges because it attempts to write to the <python_install>/site-packages directory.

# su
# python install.py

The installer will ask a number of questions. First it ask for the <TACTIC_BASE_DIR>:

Please enter the base path of the TACTIC installation:

(/home/apache) ->

Enter the user the Apache Web Server is run under.

Please enter the user Apache Web Server is run under:

(apache) ->

It would copy the source code to the base path and create a symbolic link to it. An Apache Web Server file will be generated at the end which you would need to copy to the Apache config area upon installation of the web server. If there are existing files in the destination directory the installer will ask for your confirmation to remove it. At the end, you will see this:

*** Installation of TACTIC completed at [/home/apache] ***


Next, please install the Apache Web Server and then copy the Apache config extension
[/home/apache/tactic_data/config/tactic.conf] to the Apache web server config area. e.g.
/etc/httpd/conf.d/

Verification

When the installation is completed, an asset directory will be created at <TACTIC_DATA_DIR>/assets.

The file tactic_paths.py will be created in the following directories:

Linux

[multiblock cell omitted]

Network machine access

If you are on the server, you can access it by using the URL http://localhost/tactic. For other people to access it on the network, you need to find out its IP address. In a linux server, you can use the command "ifconfig" to locate it. It’s the one listed as the inet addr.

Next, you need to run TACTIC behind Apache.

TACTIC should be run behind an Apache web server. You can download Apache software at http://www.apache.org/

The TACTIC application server is able to serve up static content such as images, PDF files, Quicktime files, and so on, but it is not the most efficient at this because it is written in Python. This is what Apache is designed for. By running TACTIC behind Apache, it relieves TACTIC from serving the static content so that it can focus on the dynamic content.

For production use, it is highly recommended that TACTIC is run behind the Apache server. This has many scalability advantages. When running behind Apache, Apache uses a reverse proxy and proxy balancer module to forward requests to communicate with TACTIC.

Linux

After the installation, some changes may need to be made in the "httpd.conf" file for Apache.

Fedora Core: /etc/httpd/conf/httpd.conf

Make sure the following lines are uncommented:

LoadModule rewrite_module modules/mod_rewrite.so
LoadModule proxy_module modules/mod_proxy.so
LoadModule proxy_http_module modules/mod_proxy_http.so
LoadModule proxy_balancer_module modules/mod_proxy_balancer.so
LoadModule deflate_module modules/mod_deflate.so

These lines may already be uncommented, depending on your distribution and version of Apache. You need Apache version 2.0.31 or later.

The TACTIC installer generates an Apache extension conf file on completion. Copy that file to a directory that is recognized by Apache.

For Fedora Core: copy the TACTIC generate Apache conf extension file to the following directory:

/etc/httpd/conf.d/

If there is no such configuration extension folder, you must add the following line to the "httpd.conf" file so that it will read the extension configuration file provided by the installer:

Include conf/tactic_win32.conf

Web Server configuration

In our provided file:

tactic.conf

Make sure the following lines exist:

# Using the ProxyPass directives
ProxyPreserveHost on

<Proxy balancer://tactic>
BalancerMember http://localhost:8081/tactic
BalancerMember http://localhost:8082/tactic
BalancerMember http://localhost:8083/tactic
</Proxy>
ProxyPass /tactic balancer://tactic
ProxyPass /tactic_data balancer://tactic

Note

Warning: For load balancing, only use either:

\1) the Proxy Balancer method (recommended)

or

\2) the RewriteRule method (not recommended).

Do not use both methods at the same time.

Note

For configuring load-balancing set-up in a real production, please refer to the Load Balancing section in the Sys-admin docs.

Note

When trying to set up Apache on a Windows Server, to specify a share folder for Apache to use, you may need to include the name of the share folder in the path.

For example, use the following if you have named the share folder "my_share":

Alias /assets "//10.0.0.17/my_share/assets"

Finally, after verifying the configuration is correct, restart the Apache service:

service httpd restart

Go to the "<TACTIC_INSTALL_DIR>/src/bin" folder

`cd /home/apache/tactic/src/bin `

Then su as the user apache is run as:

su apache

python startup_dev.py

This "startup_dev.py" script is the development script which will dump output to the screen. The other startup script "startup.py" is the production start-up script and will dump output to a log file. The development start-up script is also much slower as it monitors the file system to see if any files have changed.

The output would look like the following:

Registering site ... admin
Registering site ... default
Registering site ... test
Registering site ... my_project

Starting TACTIC ...

05/Jul/2007:11:16:29 CONFIG INFO Server parameters:
05/Jul/2007:11:16:29 CONFIG INFO server.environment: development
05/Jul/2007:11:16:29 CONFIG INFO server.log_to_screen: True
05/Jul/2007:11:16:29 CONFIG INFO server.log_file: D:/tactic_temp/log/tactic_log
05/Jul/2007:11:16:29 CONFIG INFO server.log_tracebacks: True
05/Jul/2007:11:16:29 CONFIG INFO server.log_request_headers: True
05/Jul/2007:11:16:29 CONFIG INFO server.protocol_version: HTTP/1.0
05/Jul/2007:11:16:29 CONFIG INFO server.socket_host:
05/Jul/2007:11:16:29 CONFIG INFO server.socket_port: 8081
05/Jul/2007:11:16:29 CONFIG INFO server.socket_file:
05/Jul/2007:11:16:29 CONFIG INFO server.reverse_dns: False
05/Jul/2007:11:16:29 CONFIG INFO server.socket_queue_size: 10
05/Jul/2007:11:16:29 CONFIG INFO server.thread_pool: 5
05/Jul/2007:11:16:30 HTTP INFO Serving HTTP on http://localhost:8081/

http://<TACTIC_server_address>/tactic/admin/

You should see the TACTIC login appear.

image

There is a default user created on installation. This is the "admin" user and this user has the ability to see and change all aspects of the system. Log in as the admin user:

Note: You may be asked to change your password automatically at startup. without entering these default credentials.

user:

admin

password:

tactic

Note: If you have not set up the TACTIC service, refer to the page "Configure the TACTIC Service".

First, stop TACTIC running in dev mode if applicable by pressing Ctrl C in that shell

In Linux:

service tactic start

At this point you will need to install a TACTIC license file and then begin to set up a project.

Note on supplementary directories used in TACTIC:

In the config file <TACTIC_DATA_DIR>/config/tactic-conf.xml, you will find different references to directory under the path /home/apache like /home/apache/tactic_temp , assets, and handoff. They are there because /home/apache is the base directory chosen for installation. It could be different in your case. In the future, you can change their locations by editing the config file. If the assets directory is changed, ensure it’s also updated in the Apache Web server config extension tactic.conf.

To view different information about the system and set-up, you can go to the Site Admin -→ System Info page. For example, you can verify if load-balancing is set up and certain key directories are writable by TACTIC.

  • If you see missing images on logging in or errors in the output log saying certain js files are not found, it means the Apache extension file tactic.conf is not being referenced or you have not updated the paths in it to reflect current <TACTIC_INSTALL_DIR>. For example, if your <TACTIC_INSTALL_DIR> is /home/apache/tactic, you should see the line in the Apache config extension file tactic.conf:

    Alias /context /home/apache/tactic/src/context

    Note

    Be aware of the slight differences in the naming of the configuration files:

    tactic-conf.xml: TACTIC configuration file

    tactic.conf: Apache configuration file extension

  • If you try to check in a Preview Image and can’t see the icon generated, your assets alias in the Apache extension file may not be in sync with the asset_base_dir in the TACTIC config file tactic-conf.xml

    Alias /assets           /home/apache/assets

    should point to the asset_base_dir as found in tactic-conf.xml

    <asset_base_dir>/home/apache/assets</asset_base_dir>
  • If you want to re-run install.py, the installation will ask if you to confirm backing up the sthpw database before dropping it. If you choose to do it yourself, here is the command:

    pg_dump -c -U postgres sthpw > sthpw_backup.sql
    dropdb -U postgres sthpw
  • If you try to connect to the http://<server IP>/tactic and it just times out, your server firewall could be blocking access. Ensure SELinux is not enabled as well.

    # to turn off firewall
    /etc/init.d/iptables save
    /etc/init.d/iptables stop

12.7. TACTIC, a Scalable Solution

A data management system to grow along with your expanding data needs TACTIC software meets the complex content demands of today’s large-scale production environment:

  • Based on existing web technologies, it is easy to maintain and scale
  • Easy to load-balance and scale across cores and across multiple machines

What Makes TACTIC Scalable?

The TACTIC platform uses web technologies in its underlying architecture. As proven by many popular web sites today, web technologies are able to scale to a large number of users—to levels far beyond the size of any large installation today requiring TACTIC.

The TACTIC user interface and its API (Application Programmer Interface) are both built on web technologies. A web server controls as the user front end., and accesses a back-end database. Web servers can handle high volumes, so scalability is not an issue—especially for the relatively manageable volume seen in even the largest of digital productions.

Web server technology

TACTIC uses a web server to deliver static content to users, who are able to access TACTIC over the web. Web servers are capable of delivering enormous numbers of requests, and will remain stable during heavy loads. Web servers by definition are the most efficient vehicles for web delivery, and TACTIC technology is optimized to take advantage of this technology for fast execution and scalability.

Leading database technology

TACTIC stores all persistent data in either Oracle or PostgreSQL databases, products that both have proven track records in the most demanding of production environments.

Today’s databases coupled with today’s hardware are sufficiently powerful to handle any of today’s production needs. The largest of digital productions cannot come close to exceeding the data limits of a typical database.

Optimized requests

With digital productions, the amount of data required is seldom the issue. Rather, bottlenecks are typically caused by complex requests slowing down database response time. Digital productions tend to use deeply nested and enormously complex relationships between various pieces of data. It is this complexity that tends to slow down applications that try to parse this data in a meaningful human way, creating complex requests that slow down database response.

TACTIC is designed from the ground up to master the complexities of digital productions. For every request, it builds a unique object-relational mapper specifically designed for the needs of high volume, large scale digital production asset management solutions.

TACTIC is flexible enough to handle the complex relationships between any part of the production pipeline, and has proven itself in large-scale projects using extremely complex data.

Easy code maintenance

The Python programming language is used for TACTIC application development. Python has many strengths that contribute to ease of maintenance (courtesy of www.python.org):

  • clear, readable syntax
  • strong introspection capabilities
  • intuitive object orientation
  • natural expression of procedural code
  • full modularity supporting hierarchical packages
  • exception-based error handling
  • very high-level dynamic data types
  • extensive standard libraries and third party modules for virtually every task
  • extensions and modules easily written in C, C++ (or Java for Jython, or .NET languages for IronPython)
  • embeddable within applications as a scripting interface

Load balancing

Load balancing—the distribution of requests across TACTIC processes—is possible across cores and across multiple machines, and enables TACTIC to scale to large enterprise environments.

(For details and examples, see TACTIC Scalable Configuration Examples.)

Segregating services

The various TACTIC services can be segregated to run independently of each other. This allows important services, such as user interface requests, to access their own resources and not be slowed down by other more resource-intensive services such as render farms.

(For details and examples, see Scalable TACTIC Deployments.)

Types of Scalability

There are several types of scalability that are considerations with the use of Python as the TACTIC programming language:

  • Code scalability: TACTIC contains thousands of classes and many hundreds of thousands of lines of code which are facilitated by use of the Python language. There has been no reason to believe that the code base cannot continue to scale to meet software needs for the foreseeable future.
  • Memory scalability: Python is known for large memory requirements when compared to other languages, but the required memory for TACTIC code is much smaller than that found on typical servers, and has seldom been an issue.
  • Performance scalability: Python’s GIL (Global Interpreter Lock) limits Python’s scalability across multiple threads. This limitation has been long discussed in newsgroups, with the general consensus that scalability is achieved much more easily by load-balancing across processes rather than across threads. TACTIC enables easy load balancing across processes to achieve full linear scalability.
  • Maintenance scalability: Clean and clear syntax makes it easy to refactor and maintain code over the long term. Experience has shown that our code base is very accessible to new developers, providing confidence that code base knowledge can be maintained over the years.

Overall, very few limitations with the Python language itself have been encountered and have easily circumvented its lack of scalability across multiple threads by optimizing proper load balancing across processes.

Additional Scalability Considerations

Availability

TACTIC has been designed to be highly stable even under extremely heavy stress. It has been tested and tuned on several projects in environments of high stress and high load and has been proven to run under duress without going down.

As with any piece of software, there is always a point a failure—there are a number of legitimate reasons for a TACTIC server becoming unresponsive or even going down:

  • network cutoff
  • power failure
  • physical memory failure
  • overloaded requests for the available resources

For projects that require high availability even in the event of catastrophic failure, there are a number of hardware solutions to provide failover should the primary resource fail. These hardware solutions will instantly redirect requests to a redundant resource, thereby providing continuous service to the users.

Memory requirements

Each available process will use a certain amount of memory, so a balance must be struck between the number of processes and the size of the complete in-memory TACTIC footprint on the server. In other words, adding more processes may or may not increase the availability of TACTIC if memory is an issue. If processes start running into swap space, performance will be severely affected.

As memory usage becomes an issue, the choice will be to load balance over multiple machines (see Scalable TACTIC Deployments).

Database Replication

Both Oracle and Postgres have replication capability: the ability to distribute the processing load of the database server over a number of machines. Database replication is complex and should not be taken lightly. With the advent of multiprocessor and multi-cores systems, the need for database replication has been reduced significantly. It is often much cheaper and less time consuming to increase the processors/cores of a server than it is to configure a database for replication.

12.8. Setup Email

This document describes how to setup the mail server settings in TACTIC in order for notifications to be sent out as emails.

To setup the SMTP mail server, open the TACTIC config file.

The TACTIC config file is located here:

On Linux:

<TACTIC_INSTALL_DIR>/projects/config/tactic_linux-conf.xml

On Windows:

<TACTIC_INSTALL_DIR>/projects/config/tactic_win32-conf.xml

Go to the <services> section of the config file.

Add the following settings with the prefix <mail…>.

Below is an example of a completed mail config section in bold:

    <python>python</python>
    <python_path></python_path>
    <render_submit_class></render_submit_class>
    <render_dispatcher></render_dispatcher>
    <system_class></system_class>
    <pool_max_connections>3</pool_max_connections>
    <process_count>3</process_count>

mailserver

The URL of the SMTP mail server

mail_password

The password for accessing the SMTP mail server that requires authentication

mail_user

The user name for accessing the SMTP mail server that requires authentication

mail_port

The port for the SMTP mail server (if different that 25)

mail_sender_disabled

disable using the sender name in sending of email in case the email server does not allow sender’s email not owned by the sender

mail_tls_enabled

enable TLS (Transport Layer Security) for the connection to email server

Go to the Notifications view under:

Admin Views → Site Admin → Notifications

Click on the green plus button on the tool shelf to insert new a notification.

Fill in the following the minimum fields to create a test notification:

image

Click on the Email Test button to send out a test email to the recipient.

For further details on setting up advanced notifications, please refer to the doc titled: Advanced Notification Setup.

12.9. HTTP Co-Service Installation/Configuration

The aim of this document is to be able to configure Apache to proxy TACTIC on a UNIX machine. For Apache on Windows machines, there may be some slight differences in behavior or steps.

  1. User must have sufficient technical knowledge to navigate the OS directories, edit text files, and start/stop services. Knowledge of the target web server is required.
  2. TACTIC must be installed on the host machine. It should be runnable to the point where all diagnostics presume no error in the TACTIC configuration. In the below examples, TACTIC is installed with all default options.
  3. The web server must be installed on the host machine. Since different OS’s can have vastly different HTTP service default configurations, configuration files will need to be found by command or appropriate documentation consultation.

The TACTIC host machine should have the following prerequisites

  • A working TACTIC installation
  • An OS capable of running the target HTTP co-service

The HTTP configuration assumes that the main server is being used to proxy TACTIC requests, without SSL or virtual servers. TACTIC requires that the appropriate modules or 3rd party modules are activated.

This document assumes that TACTIC has been configured correctly and is functioning as expected. It is assumed that TACTIC is installed with default ports 8081 through 8083. This is the typical default TACTIC configuration.

12.10. RemoteAccessTactic

12.11. How to Install TACTIC on Ubuntu 12

How To Install TACTIC 3.8 (Open Source Release) On Ubuntu Server 12.04

Revision 2 - August 12th, 2012

Author(s): Mike Aquino

Install Ubuntu Server 12.04 as a VM … go ahead with the default creation of initial non-root user (for example when using Easy-install for a VMWare VM OS installation), just to expedite the install process for Ubuntu Login as the non-root user that was created, and then activate root user account using (provide non-root user’s password for sudo, then provide a password, and confirm it, for the root user): $ sudo passwd root Logout of non-root user account and then login with the newly activated root user account, using the password you just provided for the root user. Install necessary tools … A. install gcc, make, unzip … $ apt-get install gcc make unzip B. install Image Magick … $ apt-get install imagemagick C. if needed, install OpenSSH server … $ apt-get install openssh-server D. install other necessary modules … $ apt-get install samba libxslt1-dev libxml2-dev E. install postgres … $ apt-get install postgresql-9.1 postgresql-server-dev-9.1 F. install Apache … $ apt-get install apache2p Install Python 2.7 dependencies (NOTE: Ubuntu Server 12.04 comes with Python 2.7.3 pre-installed as its default Python) … A. install PIL module … (a) install library dependencies … $ apt-get install libjpeg-dev libpng-dev zlib1g-dev liblcms1-dev python-dev (b) download and build the jpeg decoder … (i) download the http://www.ijg.org/files/jpegsrc.v8d.tar.gz file into /root/temp (this file is provided in the "for_PIL" folder of this install guide package) (ii) unarchive the package file … $ cd /root/temp ` `$ tar xvzf jpegsrc.v8d.tar.gz ` (iii) build the jpeg decoder and install into the system ... `$ cd /root/temp/jpeg-8c ` `$ ./configure --enable-shared ` `$ make $ sudo make install ` (c) download PIL 1.1.7 source kit from http://effbot.org/downloads/Imaging-1.1.7.tar.gz (see more info at http://www.pythonware.com/products/pil/) and place in /root/temp (NOTE: this file is provided in the "for_PIL" folder of this install guide package) (d) set-up PIL ... `$ cd /root/temp ` `$ tar xvzf Imaging-1.1.7.tar.gz ` `$ cd Imaging-1.1.7 $ vi setup.py … look for declarations of JPEG_ROOT and ZLIB_ROOT and replace them as follows … JPEG_ROOT = "/usr/local/include" ZLIB_ROOT = "/usr/local/include" … the write the file and exit vi (e) install PIL … $ python setup.py build_ext -i ` `$ python selftest.py ` `$ sudo python setup.py install B. install other needed Python modules … $ apt-get python-pythonmagick python-psycopg2 python-crypto python-pycryptopp python-simplejson python-lxml ` Create "apache" user and group ... A. Add the "apache" group (as root user) ... `$ groupadd --gid 48 apache ` B. Add entry for "apache" user in the /etc/passwd file ... $ vi /etc/passwd ... then add the following line to the file and write the file and exit ... apache:x:48:48:Apache:/home/apache:/bin/bash C. Set the "apache" user password ... `$ passwd apache ` D. Give apache user sudo privileges ... $ visudo ... and add this line in the appropriate place: `apache ALL=(ALL) ALL … then ctrl+O to write file (overwrite /etc/sudoers directly) and then ctrl+X to exit E. Create apache home directory … $ mkdir /home/apache $ chown apache:apache /home/apache $ chmod a+rx /home/apache Set-up web-site index page for redirection … $ vi /var/www/index.html … replace its contents with: <META http-equiv="refresh" content="0;URL=/tactic"> … write the file to save and exit vi, then put it into an "html" sub-folder in /var/www … $ mkdir /var/www/html ` `$ cp /var/www/index.html /var/www/html/ Logout the root user then login as the "apache" user Create a "install_packages" folder in /home/apache Download the latest open source "Enterprise" release of TACTIC … go to the downloads page of the Southpaw community site at: "http://community.southpawtech.com/downloads" … and click "Download" for the "Enterprise" release. Copy this release package (e.g. tactic-3.8.0.rc02) to the /home/apache/install_packages folder Unarchive the release package … $ cd /home/apache/install_packages ` `$ unzip tactic-3.8.0.rc02.zip … you should now have the folder /home/apache/install_packages/tactic-3.8.0.rc02/ Set-up TACTIC to run as a service … A. Modify service script to run on Ubuntu Server … $ cd /home/apache/install_packages/tactic-3.8.0.rc02/src/install ` `$ vi service/tactic ` ... modify the first line of that file to use the "bash" shell explicitly: `#!/bin/bash … then write out the file and exit vi B. Copy the service script to the proper location … $ sudo cp service/tactic /etc/init.d ` `$ sudo chmod 775 /etc/init.d/tactic ` Configure Postgres for use with TACTIC ... `$ sudo cp /etc/postgresql/9.1/main/pg_hba.conf /etc/postgresql/9.1/main/pg_hba.conf--ORIG ` `$ sudo cp /home/apache/install_packages/tactic-3.8/src/install/postgresql/pg_hba.conf /etc/postgresql/9.1/main/ ` `$ sudo chown postgres:postgres /etc/postgresql/9.1/main/pg_hba.conf ` `$ sudo chown postgres:postgres /etc/postgresql/9.1/main/pg_hba.conf--ORIG ` `$ sudo /etc/init.d/postgresql restart ` Configure Apache for use with TACTIC ... `$ sudo cp /home/apache/install_packages/tactic-3.8.0.rc02/src/install/apache/tactic.conf /etc/apache2/conf.d/ ` `$ sudo a2enmod proxy_http ` `$ sudo a2enmod proxy_balancer ` `$ sudo a2enmod rewrite ` `$ sudo service apache2 restart ` Setup bootstrap TACTIC module in Python install area (THIS STEP MUST BE DONE FOR TACTIC INSTALL TO WORK) ... A. Manually create "tacticenv" folder in "/usr/lib/python2.7/dist-packages/" ... `$ sudo mkdir /usr/lib/python2.7/dist-packages/tacticenv ` `$ sudo chmod 755 /usr/lib/python2.7/dist-packages/tacticenv ` B. Revise the "tactic_paths.py" file to contain the proper paths ... `$ vi /home/apache/install_packages/tactic-3.8.0.rc02/src/install/data/tactic_paths.py … add the following lines (no indentation!) to the bottom of the file (if not already present): TACTIC_INSTALL_DIR='/home/apache/tactic' ` `TACTIC_SITE_DIR='' ` `TACTIC_DATA_DIR='/home/apache/tactic_data' … then write those changes to the file and exit vi C. Manually copy the "init.py" and "tactic_paths.py" files into this new "tacticenv" module folder … $ sudo cp /home/apache/install_packages/tactic-3.8.0.rc02/src/install/data/*.py /usr/lib/python2.7/dist-packages/tacticenv/ ` `$ sudo chmod a+r /usr/lib/python2.7/dist-packages/tacticenv/*.py Run TACTIC install script … $ cd /home/apache/install_packages/tactic-3.8.0.rc02/src/install $ sudo python install.py … NOTE: specify "/home/apache" for the TACTIC installation base path and specify "apache" for the user for the Apache Web Server. $ sudo chown -R apache:apache /home/apache/tactic /home/apache/tactic_* ` `$ sudo chown -R apache:apache /home/apache/assets /home/apache/tactic_data ` Copy the provided TACTIC license file to the correct location ... `$ cp /home/apache/tactic/src/install/start/config/tactic-license.xml /home/apache/tactic_data/config/ ` Ensure databases are upgraded to the given version of TACTIC ... `$ python /home/apache/tactic/src/bin/upgrade_db.py Test to make sure TACTIC server is able to run … $ python /home/apache/tactic/src/bin/startup_dev.py … and then, from a browser, go to the TACTIC web UI and confirm everything is functioning properly Finally set up TACTIC to automatically start up as a service when the server is rebooted … $ sudo update-rc.d tactic defaults

12.12. Monitor Server Performance