Installing Theatre Manager

This guide provides instructions for installing or upgrading Theatre Manager that is very similar on all platforms. Since Theatre Manager is a point of sale application for your venue that can deal with credit card information, care must be taken to install it using the steps that follow to ensure PCI compliance.

There are three components to the Theatre Manager System

  • The Postgresql database server
  • The Theatre Manager desktop application used by Box Office, Development, Marketing, Finance, etc for daily activities
  • The Web Services (also known as the Director) that can be configured to handle various web related functions including:
    • The TM Web Listener service that responds to all online patron requests.
    • The Web server that passes web requests from Patrons to the TM Web Listener

The installation of the database server, Theatre Manager and web sales is relatively simple and can be done in a few minutes.

The installation procedures are constantly updated with the latest instructions to implement Theatre Manager in a PCI manner. It is applicable to all versions of Theatre Manager.

Achieving PCI compliance for your venue comes with how you install it on your network and other protections you put in place. These protections are mandated by PCI standards regardless of whether or not you use software in your operation. We hope that our instructions make it easy for a merchant to meet PCI DSS compliance.

We have placed alerts similar to this throughout the installation documentation to signify areas of particular concern to the PCI standards council. Please pay particular attention to these alerts as they contain valuable information to assist venues meeting PCI compliance.

The steps that follow indicate how to install and run Theatre Manager in a manner that will help you meet your PCI compliance requirements as outlined in the latest PCI 3.1 quick reference guide. A venue that chooses to opt out of some of the safety and security measures in this document needs to be aware that they have chosen to bypass some aspects of the compliance required in the merchant agreement with their bank and the PCI Security Standards Council that is operated by the credit card companies.

Venues may opt out of any compliance step by signing the appropriate area. The credit card companies have placed the onus on all point of sale software providers to help merchants meet compliance (instead of the banks) and highlight areas to address.

Theatre Manager assists you in meeting PCI compliance because:

  • it is audited and certified per PCI requirements by an accredited third party for your protection
  • it provides the following PA-DSS installation instructions designed to help you implement your internal card practices in a safe manner
Step Purpose Optional Installation instructions or link Who
1. Network Setup Mandatory Setting up network for PCI compliance Artsman Venue
2. Installation of Postgres Server Mandatory Platform specific install instructions ArtsMan
3. Installation of Theatre Manager Mandatory Platform specific install instructions Venue
4. Installation of a customer database Optional If this is the first time that Theatre Manager is being installed at a venue, an 'empty' venue specific serialized database will be provided. It will only contain the zip code lookup table and sample code tables. ArtsMan
5. Credit Card Authorization Optional Theatre Manager provides a selection of service providers for credit card authorization.

Venue Artsman

6. Installation of the Apache Server Optional Installation of the apache server is platform specific if you are using web sales. ArtsMan
7. Setup SSL certificate Optional If you are using web sales, you must set up an SSL certificate and configure your firewall to allow web traffic. You will need to set up a DNS record for 'tickets.yourvenue.org' rather than assigning the SSL to a static IP address. ArtsMan
8. Upgrade of existing web pages Optional This step indicates the general changes to existing web pages that must be made when migrating from any version to any other version.

In addition, a venue must be aware of OWASP and should bookmark it in their browser. This site has a 'top 10' list of ongoing security considerations and standards for web site development. Arts Management reviews and implements each years suggestions annually - see this years top 10.

Finally, if you accept credit cards on the internet, you may need an application firewall as per PCI requirement 6.6 and the web pages are significantly changed. We are looking at mod_security and may put that into a future release of the apache server on your behalf.

Venue
9. Initial settings in TM Mandatory After Theatre Manager and the database have been installed, you will need to review minimum key standards and other security features for PCI compliance. ArtsMan Venue
10. Remote Access Optional This step is a discussion on remote access and what a venue need to do if they wish to provide that for themselves, for Remote Box Offices.

There are considerations for using RDP within the network and enabling security.

Arts Management uses a tool for remote remote support called teamviewer.

ArtsMan Venue
11. Policy Manual Additions mandatory These are some policies that should be added to the customer service and/or security policy manual at a venue for PCI compliance. Venue ArtsMan

PCI Compliance

A Merchant's PCI compliance is obtained by setting up the network and office policies in the appropriate manner and following a few simple rules (green in the diagram). This is required regardless of software used to process credit cards and can generally be done at reasonable cost.

The software or hardware provided by any vendor is only a portion of the merchant's ability to meet PCI compliance. Software provided by vendors must meet the prevailing PCI PA-DSS standard to assist the merchant meet overall PCI compliance.

Meeting compliance requires some due diligence and is determined by the PCI compliance level guideline your organization needs to attain.

Depending on how your venue processes transactions, your venue can be Schedule 'A', 'B','C', or 'D'.

The life cycle of a standard provided by the PCI Security Standards Council is approximately every 2 to 3 years. Once approved at a standard, it is valid even though future standards are being worked on.

The following table illustrates a brief historical summary of Theatre Manager PCI compliance

Version Standard Status Action
10.06 PCI PA/DSS 3.1 Theatre Manager verison 10.06.zz has been reviewed for its PCI PA/DSS 3.1 audit as part of the 3 year cycle.

The audit took place in Oct 2015 the final document was approved by the PCI council with an expiry date of Oct 28, 2019 for new installations. The image to the left is from the PCI council's web site of validated applications. Search for Arts Management.

Upgrade Oct 2015
10.02 PCI PA/DSS 2.0 Theatre Manager verison 10.02 was has been reviewed for its PCI PA/DSS 2.0 audit as part of the annual change cycle.

The audit took place in Oct 2014 the final document was approved by the PCI council.

All vendors are required to tell you this.

Upgrade Oct 2014.
10.00 PCI PA/DSS 2.0 Theatre Manager verison 10 has been reviewed for its PCI PA/DSS 2.0 audit as part of the 3 year cycle.

The audit took place in July 2013 the final document was approved by the PCI council in October 2013. The image to the left is from the PCI council's web site of validated applications. Search for Arts Management.

All vendors are required to tell you this.

Upgrade Oct 2013.
9 PCI PA/DSS 1.2 Meets the PCI PA/DSS 1.2 standard and approved by the PCI council in Dec 2010. Upgrade to version 9 ASAP
8 PABP 1.4 meets the PABP 1.4 standard and was certified in Oct 2008. Please refer to our certificate and approval by Visa - page 6.
7 **Self Assessed in 2006 implements the standards required of PABP 1.4 (as of 2006), including 3DES high encryption of cards and does not store any track II or CVV2 information. However, this version is neither audited nor certified by an external vendor (not a requirement from the PCI council at the time). Version 7 has name security measures as version 8 and was simply renamed version 8 as part of the audit.
6 **Self Assessed in 2003 implements almost all PCI security features in effect at the time (early 2000's). Card encryption is DES and it does not track CVV2 information. However, version 6 should not be considered PCI compliant.

** Please note: PCI requirements have changed over the years. At one time, the PCI security council required that vendors of software 'self assess' that they have followed the guidelines. At Arts Management, we have always taken card security and privacy of information seriously and implemented many PCI features before there were published rules. That is why we felt able to meet the self assessment criteria in force at the time. However, there is a much greater need for security than ever before and we encourage merchants to fulfill their obligations to merchant agreements and upgrade to the 'certified' versions of Theatre Manager - which have been audited by external companies as meeting all the rules in effect at the time of the audit.

Network Diagram for PCI Compliance

The block diagram below explains the general setup of a network that is required to implement Theatre Manager in a PCI compliant manner.

Feel free to print this setup document. If any part of the network setup cannot be made to comply with the diagram, you will need to address that at a later date to become PCI compliant. Some sample machine requirements are in the table in the picture, or you can view descriptive information on sample computer specs (Click to enlarge as a pdf)

PCI compliance requirements for Credit Card authorization

Overview

There are 7 parts to the basic network in the diagram above that are described in more detail in the following sections. The firewall is the glue that connects them all together, yet protects each part from the other (also see firewall rules). Only 4 parts are in PCI scope, the other 3 are simply illustrations of how customers, volunteers, actors and other devices interact with your network.

In PCI Scope (inside the firewall) if they touch credit card info:

  1. The main firewall
  2. the DMZ - contains only the Apache server and restricts what can be accessed from the internet.
  3. OFFICE Lan - all wired devices in the office. Computers that access any Credit Card information should always be hardwired, or access via a secure VPN
  4. Remote box office

Out of PCI Scope

  1. You can exclude ranges of workstations if you've told TM that they cannot process cards by creating a subnet mask that focuses on only those that can in the System Preferences->PCI Tab
  2. You can exclude the database server if you set TM to be PCI Schedule 'C' compliance in the System Preferences->PCI Tab
  3. Outside the firewall - basically the internet and customers purchasing online
  4. VENUE Lan - any staff, volunteers, or actors using wired or wireless devices and who are not capable of processing or looking at credit cards.
  5. Ticket scanners used at the venue

If you are attempting to meet Schedule 'C' compliance for Theatre Manager, the database and a number of workstations can be taken out of scope. Credit cards will never pass through the database and most workstations can be denied the ability to process cards. Doing this effectively limits PCI scope to very few machines.

You can also whitelist computers or blacklist a network segment to prevent any computer from taking credit cards -- which also takes it out of scope as credit cards never pass through the user workstation.

AMS Private Cloud Diagram for PCI A, B, or C

Venues using Theatre Manager can take computers out of PCI scope as per the diagram below. A device is in scope if a credit card touches or passes through it. Devices are out of PCI scope if they can never see any credit card information pass through at any time. AMS Cloud causes most things to be out of scope and you can limit it further. It is possible to implement the same PCI scope within your own environment if desired.

AMS cloud allows a merchant to target the possible compliance levels to Schedule 'A', 'B', or 'C'. Since most venues have face to face or phone orders, the default is Schedule 'C' but you may wish to reduce the number of machines in scope to the minimum. If can take all machine out of scope in the office environment using dial up or IP pinpads, you may be able to achieve Schedule 'B' (very much dependant on your bank).

Possibilities for PCI compliance

  • Schedule A for merchants using only e-commerce transactions and Moneris Hosted Payment Page. All e-commerce authorizations occur at Moneris, and card data never enters the network
  • Schedule B Merchants using only: Imprint machines with no electronic cardholder data storage; and/or Standalone, dial-out terminals with no electronic cardholder data storage. Not applicable to e-commerce channels
  • Schedule B-IP for Merchants using only standalone, PTS-approved payment terminals with an IP connection to the payment processor, with no electronic cardholder data storage. Not applicable to e-commerce channels.
  • Schedule 'C' Merchants with payment application systems connected to the Internet, no electronic cardholder data storage. Not applicable to e-commerce channels.

Even if you take all machines out of scope and use only dial up or IP terminals, if you are part of a large university of municipality, your Bank may force you to be schedule 'D'. This can happen if the Bank chooses to consider all your other merchant activities outside the venue (eg bookstore, admissions, dog tag sales, etc as part of the overall business). One way around that might be e-commerce and Moneris hosted payment page.

PCI Scope Diagram - AMS Cloud

The legend shows machines and network segments:

  • Organizational Areas:
    • that will never see credit cards (GREEN)
    • where a credit card passes through the machine while in flight to the bank during an authorization and is immediately gone (PURPLE). Cards in these zones are:
      • transmitted via TLS and
      • live for an instant in time and
      • are NEVER stored in a database
    • where the card data is outside the boundaries of the organization. Examples are in the customers hands (or wallet) or at your bank or service provider (who are required to perform their own PCI compliance) (RED)
  • TCP/IP Traffic
    • RED ARROWS - traffic where there is absolutely NO card data ever transmitted
    • BLUE ARROWS - traffic where card data travels (encrypted and via TLS) while it is IN FLIGHT for an authorization. This means that a message is sent for credit card authorization and the card resides only in memory (and is never stored in any disk file)

Components

Local Workstations

There are three options for workstations within a venue's physical environment.

Option Goal Steps Pro Possible PCI Levels
1 WORKSTATION OUT OF SCOPE and use a POS pin pad device

This takes a workstation out of PCI scope and allows the workstation to use any software on it that can reach the internet (eg email and web browsing). Credit Card authorization is via a pin-pad using dial up or IP connectivity. If all workstations are subject to this rule, then Schedule 'B' compliance may be possible (subject to your Bank's ruling). Risk of card being part of TM components is ZERO. Risk of any data breach limited to person hacking the standalone POS terminal.

  • Indicate to TM that a workstation cannot authorize credit cards by indicating a CIDR subnet that is outside scope of the network
  • Use a stand-alone pin pad device that talks to the bank. These must be purchased from your bank or service provider and come in many varieties such as wireless, dialup, ethernet connected, accept apple pay, chip and pin cards, etc
  • Can still authorize credit cards for walk up and phone sales via external terminal.
  • Workstation can be used for any purpose such as email, web, analytics as it is not subject to PCI scope
  • End of day is broken into web sales and 'other' payments for box office'

'B'

'B-IP'

'C'

2 WORKSTATION OUT OF SCOPE and no credit card authorization at all

This option should definitely be used for all non-box office computers or computeres used primarily for setup, reporting and analysis.

  • Workstation can be used for any purpose such as email, web, analytics as it is not subject to PCI scope
  • Only web sales will have a settlement for credit cards
'B'
3

DEFINED WORKSTATIONS IN SCOPE

The workstation is defined as one of those that may accept credit cards entered into the system so that it does

  • since Theatre Manager does the authorization, it can also do a void or refund. Depending on the credit card provider, it can be as long as a year after (Bambora using authorization token
  • Authorization will use higher level TLS transport encryption if supported by merchant services provider
'C'
4

TM Servers

NGINX and TM Server

can be in or out of scope depending on processor choices
To take the servers out of scope, you will need a merchant provider for Moneris Hosted Payment Page. Advantages are no data enters the network and you can be PCI A compliant. Disadvantages come with inability to use post dated payments, and perhaps processing refunds. Under Moneris hosted payment page processing, TM does not see any card data - just the authorization, allowing for PCI A.

Hosted payments does not support the feature of post dated payments online.

'C' or 'A'

AMS Private Cloud

Credit card data can never be stored on the AMS Cloud, taking the database server out of scope.

Credit card data can pass through the firewalls and security appliances on the way to your Service Provider for authorization. It is transferred via TLS 1.2 and is subject to SPI (Stateful Packet Inspection), DOS detection, rate limitation, etc. to ensure security and privacy.

Bank/Service Provider

This is the merchant provider you selected out of those supported by Theatre Manager. The bank is not in scope of you PCI compliance requirements.

 

Risk Profile

Theatre Manager, the AMS Cloud, and POS terminals offers a very low PCI risk profile (almost negligible) for the following reasons:

  • Card data never enters your network - no risk
  • Cards are authorized using standalone pin pad terminals sold by the bank. This represents a negligible risk as only the physical device, sold and certified by the bank, could ever be compromised. Even if it were, it is not part of your network and has no communication with TM
  • Card data is never stored on disk. Having no card data in the database means no risk and no PCI exposure even if the entire database was given into the wrong hands. There simple is no card data in it.
  • Card data is transmitted from the user to the bank via TLS 1.2 (transport layer security) which is the highest form of security for sending data on the web. This is negligible risk as TLS 1.2 is not known to have been compromised like TLS 1.0 or and of the SSL protocols. If TLS 1.2 were ever compromised, every web site and browser is in trouble as it is all that is our there in the web.
  • Card data lives on the AMS network only for that instant in time needed to get to the service provider. TLS 1.2 cannot be sniffed by bad guys - very low risk
  • The TLS certificate can be reissued as often as you want to ensure that your key strings are secure. Google signalled intent to re-sign certificates every few months as additional cautions for commerce.

PCI UserId and Password Requirements

Theatre Manager implements fully PCI DSS compliant AES256 encrypted passwords per PCI DSS standard 8.1 and this feature cannot be changed or overridden.

In addition, Merchants must use PCI DSS compliant passwords to access to all system components (i.e. any computer, firewall, router, etc. on the network) and these passwords must be changed from any vendor supplied initial values per PCI standard 2.1.

Note: do not reduce the level of authentication complexity or compliance in these other system components if it will result in PCI non-compliance.

This means all login passwords must be:

  • reviewed and changed every 90 days. Theatre Manager will enforce password changes automatically. This must be manually done on those devices that do not force change of passwords like routers and firewalls. (PCI DSS 8.1.4)
  • 7 characters or more (PCI DSS 8.2.3)
  • mixed case consisting of at least uppercase and one lower case letter (PCI DSS 8.2.3)
  • contain at least one number and special character (PCI DSS 8.2.3)
  • cannot be the same as an previous 12 passwords (PCI DSS 8.2.5)
  • cannot have characters or numbers repeated together
Change all passwords from any vendor default password that might be used for installation per PCI DSS 2.1. For example, you must:
  • Change the Theatre Manager 'Master User' password when the system is installed.
  • Change the user and and password on any router from anything printed in the manufacturer's documentation
  • Make sure that accessing each computer requires a password and does not 'auto-login'
  • Ensure that screen savers are implemented that require passwords to be entered whenever the screen saver is activated. Screensavers (or some other mechanism for locking computers) must activate after 15 minutes of idle time or less on all workstations and servers. Theatre Manager also has an inactivity timeout that will log people out of the application. Using both features improves security. (PCI DSS 8.1.8)

Each user that has access to any systems in your network must have a unique user id and password per PCI-DSS standard 8.1.1

Never use the Master User account for daily operation. It should only be used when creating other accounts or for other very specialized needs as directed by Arts Management Systems.

If your network has 'master' domain server (or open directory on OSX) available that could control password authentication for all machines, please ensure that the security policies on the domain/directory server is set to enforce PCI/DSS passwords and that all machines in the network log in using authentication from the server.

If a domain/open directory server is not available to enforce password settings, then each machine/user must use PCI/DSS compliant passwords.

If a user tries more than 6 times to gain access to the system, Theatre Manager automatically resigns the user - which means that they are locked out permanently until manually re-instated per PCI-DSS standard 8.1.6 and 8.1.8

Main Firewall

You will need a router (with DMZ and VLAN and SPI capability) and two subnets are required within the office to implement PCI compliance. These can be reasonably priced such as the easily configurable SG-2440 pfSense router (approx $500 in 2015 prices) which has a lot of features. Please check www.techsoup.com if you are a not for profit organization as they have full cisco routers that you may be eligible to purchase at a discount.

We only recommend a router/firewall that has the ability to isolate the apache computer (i.e. designate an ip address for the DMZ).

Your firewall need to restrict connections between untrusted networks and any system components in the card holder environment PCI requirement 1.2.
  • Routers be a dedicated device, preferably a hardware router. If it is a software router such as one built on linux, then it must only be used only for this purpose and contain no other services.
  • It should be configured to shut down all incoming and outgoing ports except those required for business as per the following:

When you need to set up firewalls on computers, the built in firewall on windows is very flexible. On OSX, do no manage the built in firewall via System Preferences on servers - instead, consider using a tool like Murus Firewall to unlock the power of the OSX PF firewall.

Firewall/Router Rules

The main router/firewall is protection from the outside world. If the router has DMZ capability, please set up the DMZ IP address to have the same subnet range as the office lan. This will make it easier to scale up web listeners that talk to the Web Server.

This diagram identifies which traffic is required for Theatre Manager to work in the card holder environment per PCI requirement 1.2.1

Any traffic not required should be denied - and the router should be set to 'deny all' unless explicit permission is given.

In the example below, we'll refer to IP addresses

  • in the office VLAN as 192.168.1.x
  • in VLAN2 (containing wireless devices and/or machines not subject to PCI) as 192.168.2.x
  • and use 192.168.1.10 as the inside address of the DMZ where the Web Server resides, protected on both sides by firewall rules. The outside IP address (internet) also authenticated and verified using an SSL Certificate.

  • The lighter red arrows on the diagram represent places where you could place restrictive rules from specific machines to specific machines. Those rules are outlined in the table below the diagram.
  • The number in the first column of the table refers to the same number on the diagram to give an idea what kind of rules are required for each component. If you combine some services on to the same machine, you will need to aggregate the rules.
  • All ports in the table are TCP
  • Rules are for INITIATED connections (outbound connections). Meaning a machine starts the connection.
  • If an inbound message occurs on an approved port, then ANY port can be used for outgoing response. (i.e. do not block responses to approved inbound messages.

    For example: Item #1, the postgres server, only needs port 5432 incoming to that device. You would turn on the personal firewall on the machine so that it only opens that port.

If you prefer to view the firewall rules from the perspective of specific ports, please refer to ports used by Theatre Manager

Item Machine and Purpose Subject to PCI Virus S/W Inbound Port Rules Outbound Port Rules
1 PostgreSQL server

database

depends yes* 5432 from any 192.168.1.x
all to 192.168.1.x
37 to NTP server
2 Remote Box Office via VPN
(terminal server)
yes yes* as needed from internet all to internet
3 Web Services yes yes* 443
from 192.168.1.10 (nginx server)
80, 443, 8111 to 192.168.1.10 (web server)
5432 to 192.168.1.2 (postgres)
53 for DNS, MX lookup
37 to NTP server
443 to www2.artsman.com
80 to maps.googleapis.com/maps/api/geocode

25 to SMTP server
110 to pop server for Facility Mgt

** Add 443 outgoing to credit card provider

4 Box Office Workstations yes yes* all from 192.168.1.x 80, 443, 8111 to 192.168.1.10 (web server)
5432 to 192.168.1.2 (postgres)
53 for DNS, MX lookup
37 to NTP server
443 to www2.artsman.com
80 to maps.googleapis.com/maps/api/geocode

80 to www.google.com/maps/api/staticmap
80 to help.theatremanager.com

** Add 443 outgoing to credit card provider

5 Ticket Printer no n/a 10001 from 192.168.1.x all to 192.168.1.x
6 Web Server yes yes* 80, 443 from internet port 443 to Web Services (if using TM 10.06 and later w/nginx)
7 Outside of Firewall no n/a 80,443 from internet
xxxx from internet
forward 80,443 to 192.168.1.10 (Web Server)
forward xxxx to 192.168.1.4 (Term Server)
8 Internal Wireless Router no n/a all from 192.168.1.1 all to 192.168.2.1
9 Venue Lan computers not handling credit cards
no yes all from 192.168.2.1 as needed to 192.168.1.1
10 wireless ticket scanners no n/a   n/a: communicates to outside of firewall on port 443

Ports used by Theatre Manager

The table below describes which ports various components in Theatre Manager uses. With few exceptions, it is possible to change the ports that are being used if you wish. The only ports that should not (or cannot) be changed are:
  • ports 80 & 443 externally for web sales.
  • Outgoing port 443 for credit card authorizations
  • port 37 for a time server
  • port 53 for MX record lookup via a DNS server

If you prefer to view the firewall rules from the perspective of specific machines, please refer to ports used by each machine

Port Meaning Use Security Note
25 SMTP Outgoing TM Server uses this for email for web sales, eblasts and meeting scheduling. note: Workstations do not send emails and do not require access to SMTP server.

Alternate SMTP ports can be used as TM supports (startTLS and other security)

You may wish to place a small SMTP server (like Exchange) within your network so that TM talks to it and allow it to relay to the internet. This also controls outgoing access.

37 NTP Time Server Outgoing OSX and Windows machines use this to syncronize clocks. All machines should be able to synchronize with an NTP server so that transactions and audit logs are accurately recorded when the happen per PCI 10.4 compliance
53 DNS and MX lookup. Outgoing This is used to verify email and web domains during the data entry process to improve data quality
80 HTTP Incoming and Outgoing Incoming is only required to the Web server.

Outgoing for workstations to communicate to:

  • help.theatremanager.com
  • teamviewer
Teamviewer can go out on ports 80 and/or 5938
443 HTTPS Incoming and Outgoing Incoming is required for web sales.

Outgoing is required for TM Server and TM Workstations for

  • Credit Card Authorization
  • www2.artsman.com for autoupdates
  • TM Server for REST API access if enabled
110 POP3 Outgoing Facility Management module only: TM has a scheduling function that lets users set up calendar event and send the invitations to users, patrons and volunteers.

The port is used by TM workstation and Server, and only email with valid outlook or iCal attachements are read. All others are discarded. No user checks this email address.

Theatre Manager supports alternate POP3 ports if you prefer.

5000 Web Services Internal The Web Server load balancer communicates to Theatre Manager Web Services on port 5000
8111 Web Template Server Internal This internal port on the web server is a Virtual host used by web services to obtain the custom web page templates from the htdocs folder for merging. It is also used by workstations to obtain web page templates used to send double out-in confirmations as per CASL (Canada's Anti Spam Law)
8201 Cache Server Internal This internal port is used for caching data shared between web service processes.
5432 Postgres Internal This is the standard port for the Postgres database server and is only used within the LAN. Postgres's pg_hba.conf configuration file specifies the IP address ranges (or specfic IP's) that can communicate with the database server. If a machine is not permitted to talk, postgres will does not respond.
10001 Ticket Printer Internal Workstations send a string of characters to print a ticket. The printer responds with status requests as need be.

No outside machine needs access to a ticket printer.

xxxx Terminal Server & Remote Access Incoming A secure connection from the remote box office to the firewall is recommended for security purposes. RDC and Terminal Services establish secure connections. VPN is additional security.

Office Lan

The office lan should be set up to isolate computers that may access credit cards from other general purpose machines. These machines should be hardwired to ethernet hubs and routers. Generally, this just means putting it on a different VLAN than the rest of the office to provide maximum cardholder security PCI requirement 1.2.1.

For example, if there is an area that provides free wireless in the lobby, or access to the internet for actors in the green room, those access points should be part of the 'Venue Lan' and not part of the 'Office Lan' (per the network diagram) to separate the segment of the network containing credit cards (office) from wireless part of the network.

You should not be able to access the internet from the database server or any machine that contains credit card information except as required to authorize card or update system components. PCI requirement 1.3.2 to 1.3.5

Ports that should be open are defined in the section about firewall rules

When you need to set up firewalls on computers, the built in firewall on windows is very flexible. On OSX, do not manage the built in firewall via System Preferences on servers - instead, consider using a tool like Murus Firewall to unlock the power of the OSX PF firewall.

This section describes the components of the Office Lan.

PostgresQL Server

Postgres listens on 5432 by default (see firewall rules for postgres).

Only this port needs to be open on this server. All other inbound ports can be closed in the operating system. The port can be changed by editing the Postgresql.conf file, or during the install.

Misc Recommendations

  • File and email services for the network must be placed on a separate machine from the database server.
  • Turn off windows auto updater. Instead, perform regular maintenance at a time of your choosing (every second Monday for example, more often if the news reports critical viruses) to download and install updates. For 24/7 web sales service, it is important that the Postgresql server run constantly and only be updated at a time of your choosing.
  • On OSX, turn off Software Update and run regular maintenance every second week, similar to Windows Environment. There is far less risk on unix based systems for virus attack vectors.

Deploy anti-virus software on all systems commonly affected by malicious software, particularly personal computers and file servers. PCI requirement 5.1

Since postgres is implemented on a stand alone machine (per PCI requirement 2.2.1), we recommend that you DO NOT install virus software on the PostgreSQL Server. If you must, then do it under very controlled circumstances..

Never allow the virus scanner to scan the actual postgres database directories for traffic because virus scanners severely affect performance when many files are changed rapidly (as in a stand alone database server).

If you absolutely must scan all files, scan the database folder at very off peak hours.

Web Services

The ports that need to be opened for web services depends on which of the following you are using for loadbalancing:
  • Simple Setup - most venues with one or more machines doing web services
  • Custom Setup - multi outlet venues and high load setup

In all cases, you specify the ports to talk to listeners within the httpd-balance.conf configuration file.

 

Simple Setup for Load Balancing

In the simple setup situation, you just need to open port 5000 to each second generation listener and turn off the use of 'mod_tm' in the director. When any message is received by the second gen listener on port 5000, it load balances internally on ports local to the machine (5001-5010, 5111, 5201-5210).

Each second generation listener machine needs to be able to talk to the Apache machine to retrieve web pages.

 

Custom Setup for Load Balancing

In the custom setup, the web processes can listen on

  • Second Generation Listener:
    • port 5000 (like the simple setup for load balancing) -or-
    • ports 5001-500x where you specify the load balancing on the apache server for high performance throughput -or-
    • a combination of the above, although load balancing the same listeners both internally and from apache might cause some side effects.
  • Classic Listener (only if mod_tm load balancing is enabled)
    • Open ports 5111-511x for classic services.
    • You need to open one port for each outlet running on that machine
The ports cannot be changed.

Multiple web servers/listeners can be set up to talk to apache. If you wish to restrict specific machines to be web listeners, enter the IP addresses of those machines in the Apache configuration.

Deploy anti-virus software on all systems commonly affected by malicious software, particularly personal computers and servers PCI requirement 5.1

You can install anti virus software on the TM Server - but may need to exclude the TheatreManagerServer program directory and all traffic to port 5432 on the postgres server. Since the web services run as a service, there is limited need to log into the machine. It should not be used for any other purpose and listens only to the API's from the apache server, so you may only need periodic file scanning at night if you do not join a domain and/or limit people who can access it.

Box Office Admin Computers

Office computers can be classified in two categories:
  • those where credit card data is typed or entered into the system (with or without credit card swipes)
  • and those computer where credit card information is not typed into the machine.

Computers accepting Credit Card Data

Any computer where credit card information is entered or that has an attached credit card swipe is effectively a point of sale device and needs to be protected from a particularly nasty form of virus called 'Bots'.

These are especially prevalent on PC's and if a computer were to become infected, this type of virus scans keystrokes at the computer and sends those key strokes to the 'bad guys' outside the network. Preventing this involves closing most ports and providing very limited access to the outside world, especially for mail and web browsing.

For this reason, on those computers, you should:

  • Close down all outgoing ports except those specified in firewall rules for workstations.
  • Disallow general internet access via the web browser to prevent the most common source of infection. You can allow people to access help.theatremanager.com for online help.
  • install virus protection software on these machines and regularly run it and update the software. There are a number of good alternatives from freeware like Avast! to Symantec (our least favourite)
Deploy anti-virus software on all systems commonly affected by malicious software, particularly personal computers and servers. PCI requirement 5.1

If these computers are using Theatre Manager, you may need to exclude the 'Theatre Manager' program files directory, depending on your virus software. Exclude all network traffic to port 5432 on postgres server.

Computers that do not accept Credit Card Information

Machines that are not entering credit card numbers may have general internet access. You can ensure that these workstations cannot enter cards into Theatre Manager by setting up specific workstations or network segments that can accept payments and excluding these workstations.

If those computers are on the same network segment as the machines accepting card numbers then they fall into the scope of a PCI assessment for the venue. This means those machines would need all of the anti-virus and anti-malware software as well as file integrity monitoring, log management, access control, etc. just like the machines that accept the cards.

To reduce the scope of the venue's PCI assessment needs, the venue should consider placing those machines (back office or manager machines usually) on a separate network segment with just the necessary ports between them and the cardholder data network open. Refer to the network diagram and firewall rules to separate the computers with card access from those without onto separate VLAN's within your network.

Deploy anti-virus software on all systems commonly affected by malicious software (particularly personal computers and servers) PCI requirement 5.1

If these computers are using Theatre Manager, you may need to exclude the 'Theatre Manager' program files directory, depending on your virus software. Exclude all network traffic to port 5432 on postgres server.

Venue Lan

Machines in your office that generally do not need access to Theatre Manager can be in a separate VLAN so that they do not accidentally compromise credit card data. Rules should be put in place so that these VLANs cannot talk to the servers in the Office VLAN per PCI requirement 1.2.3

It may be a good practice to have one or more VLANs beside the primary office network, especially if you have wireless access points, public WI-FI in your lobby, green room access for Actors, etc. (per the network diagram). Separating those kinds of users from the office LAN is beneficial from a security and bandwidth management point of view. Network segments not dealing with cardholder information are not subject to PCI rules (although it's a good idea to protect them too!).

Theatre Manager does not require use of wireless networks to operate.

However, if you do require that some computers access cardholder data over a wireless network, you must use strong encryption technology for authentication and transmission of data such as hidden SSID, specified MAC addresses, and WPA2 or better on a separate VLAN than other wireless access points and change vendor supplied passwords per PCI requirement 2.1.1.

You must never transmit card information over a network with WEP encryption per PCI requirement 4.1.1.

Wireless Access Points

Theatre Manager does not require use of any wireless network for operation as all workstations and servers are to be connected via ethernet cabling.

Since many venues use wireless networks in the lobby for customers and green rooms for actor, or volunteer use, it is important to ensure that wireless routers are separated from the cardholder network and are on their own VLAN and all default settings are changed from factory. PCI requirement 1.2.3 and PCI requirement 2.1.1

The following must also be changed every time somebody with knowledge of the security changes positions or leaves the company. PCI requirement 4.1.1

Configuration of these should include:

  • Turn off all SSID broadcasting
  • Enter the MAC addresses (00:00:xx:xx:xx:xx) of the scanners into the acceptable list of devices at the remote site and only allow those devices to gain access to the network
  • Use strong encryption such as WPA2 (also sometimes called IEEE 802.11i) or better for access control.
  • Update the router to the latest firmware
  • Change the default user ID and password for the router to be different than the manufacturer-supplied defaults.
  • Change all wireless default encryption keys and SNMP community strings

Ticket Scanners

Wireless ticket scanners do not transmit any cardholder data at all so wireless ticket scanning can be implemented one of two ways. The scanners can be
  • part of a VLAN that is inside your main router/firewall and connected to the other parts of your network. This is known as the Venue LAN according to the network diagram. Scanners using this configuration are subject to PCI regulations to the extent that the firewall must be in place to regulate traffic.
  • completely outside the main firewall and directly connected to the internet via the ISP. In this situation, the ticket scanner is considered not part of your network and is out of scope of PCI compliance.

Wireless Scanners in the Venue Lan

If the ticket scanners are within your firewall and part of a VLAN connected to the Office LAN, you must implement WPA2 or better security and firewall rules between the venue LAN and the office LAN per the network diagram. Refer to PCI 4.1.1

You can use a direct IP in the scanner to access the Apache server directly (e.g. 192.168.1.x), or you can refer to the server via the domain name (like tickets.yourvenue.org).

Wireless Scanners connected to the Internet

If the wireless scanners are connected to a router that is on the internet (and not connected in any way to the internal trusted networks) then you do not need any security on the scanners. Since the scanners simply send HTTP requests to the Apache Server, you can use the external DNS name like tickets.yourvenue.org.

The MC55 ticket scanners support WPA2 and can be used in either configuration.

The MC50 scanners only support WEP so they must be put on an external network connected directly to the internet to avoid being subject to the scope of PCI.

Wireless Computer Access

If you permit wireless access to your network within your office, PCI compliance states that these computers should go through at least one router before accessing the office network or any part of the network where credit card information is stored.

The DMZ (NGINX Server)

The NGONX server is the only part of the Theatre Manager system placed within the DMZ per the network diagram.

Note that card holder data should never be stored or placed on the NGINX server for any reason. Theatre Manager does not require it. PCI requirement 1.3.7

Best Practices for setting up the NGINX Server

  • NGINX should be on a standalone machine in the DMZ
  • NGINX must be protected by the main firewall rules. You should turn on the built-in firewall on the machine (OS X or Windows) and should only need to open ports 80 and 443
  • NGINX is a service so it will automatically start as a service upon reboot.
    • This means nobody needs login at all.
    • Do not allow anybody to access this machine except under controlled circumstances
    • However, configure the screen saver to require a password after it is activated.
  • Turn off Windows Update or OS X Software Update
    • Instead, perform regular maintenance at a time of your choosing (every second Monday for example, more often if the news reports critical viruses) to download and install updates.
    • For 24/7 web sales service, it is important that the NGINX server run constantly and only be maintained at a time of your choosing.
  • Remove access to Outlook and/or other mail clients on the machine
  • Make sure that accessing the internet through Internet Explorer or another browser on that machine is limited to certain URLs
  • Virus protection should be implemented on this machine:
    • This machine is only responding to requests from the internet via NGINX, it is not actively accessing anything on the internet using a browser or reading email - so the risk if is acquiring viruses is very minimal.
    • If you put a virus scanner on it, set it to scan the hard drive once or twice a day, preferably early morning or at a time of day when online sales is expected to be at its minimum. Some antivirus software applications are CPU-intensive and have the potential to severely slow down the NGINX response time to web requests.
    • Don't scan incoming requests from the internet to NGINX on port 80 or 443 - because those are the working ports for NGINX.
Deploy anti-virus software on all systems commonly affected by malicious software (particularly personal computers and file servers) PCI requirement 5.1

Policy Manual

PCI compliance requires some additions to your policy manuals, some of which are described below and relate to safeguarding your network and the credit card information. We recommend making these additions immediately.

Refer to Section 12 in the PCI DSS implementation guide for complete information

Policy Description
1. Credit Card information must not be stored on any machine that is in the DMZ.

This generally means laptops that connect to the network wirelessly should be examined for files that contain card information and that information must be deleted.

2. Do not transport credit card information outside the secure firewall without:
  • AES128 or better encryption of each card or the complete file containing any cards (never auto de-encrypt the file when starting a machine)
  • transporting the data in a secure password protected device -or-
  • sending via SSL or over a VPN if doing remote backups electronically to a secure site
3. Never email a credit card number to anyone.
4. Never read back an entire credit card to a patron if they call in asking for one. Always have the patron tell you the card and confirm it only if it right. You can confirm a card number that the patron just told you in entirety.

Remote Box Office

Depending on the remote access solution you use (Citrix, Terminal Services, Teamviewer, logmein), you may need to open the appropriate ports on your router(s) and server for this feature:
  • On the firewall built into this machine
  • On the main firewall protecting the office with forwarding to the appropriate ports on this machine.

Access to the terminal server from outside the main network should include VPN or packet encryption. Windows 2008 Server and later use secure access by default.

If the remote box office solution permits the feature, you should also set it up so that only specific applications can be launched and the user cannot get to the desktop. For example, Citrix provides a web interface under ISA services that allows you to only permit Theatre Manager to run. With Terminal Server, you can also force it to start Theatre Manager automatically. With 2012 Terminal server, you can limit to only Theatre Manager application to run.

Always disable outgoing web access within the Citrix or Terminal Server so that people cannot browse the internet on the Terminal Server Machine (this will prevent all viruses). You can enable web access on the local machine.

Deploy anti-virus software on all systems commonly affected by malicious software (particularly personal computers and file servers) PCI requirement 5.1

Remote Ticket Selling

In most cases, the best way to do remote box office is to set up a Terminal Services server inside your network and provide a VPN solution from the remote site to the router.

An inexpensive Linksys VPN router will provide adequate router to router VPN services at a good price - or will provide remote VPN software for computer-to-router VPN. More expensive routers like Cisco have VPN software that accompanies the router as well.

In all cases, remote box office or work at home should be set up using a VPN connection.

Note: if installing on terminal server 2003, you may need to switch it between 'execute' and 'install' mode to actually install Theatre Manager.

If you are using remote box office and ticket scanning for access control at the same venue, it is advisable to set up the wireless access point to talk to the VPN router and send all data through the VPN tunnel as a point of extra security.

Remote Ticket Scanners

If your venue uses wireless ticket scanners for remote venues, you will need to set up a wireless access point at the remote venue to connect to the internet. These devices only confirm a ticket was used or a person exits the venue, through a very controlled API on the scanner.

The setup of the wireless access point should be:

  1. turn off all SSID broadcasting
  2. Enter the MAC addresses (00:00:xx:xx:xx:xx) of the scanners into the acceptable list of devices at the remote site
  3. use WPA2 passwords for access (the Symbol MC55 device supports WPA2)

The setup and functioning of the symbol MC55 wireless device is described in a separate document.

When you need to enter in the IP address, you can use tickets.yourvenue.org/TheatreManager/1 if you have set up a DNS or you can use the static IP address of the outside router.

You can also specify port 80 or 443 (or some other port if you wish to do address redirection within the router for additional security).

Even if you are scanning tickets at your local venue, it is often a simple matter of setting up a small hub in front of your main router so that the access points are connected to it - and they would be outside the firewall for security.

Remote Access

Remote access for Theatre Manager usually means situations for remote box office or work at home. There are a number of tools that can be used, such as Remote Desktop Connection (RDP), LogMeIn, Go To My PC, and more.

In all cases of remote access for box office, you should implement either a VPN tunnel and/or SSH access - where the communication and session has strong encryption or is a private connection per PCI DSS 4.1.

There may be additional setup consideration as described in the following sections based on the software you use. Your IT person should ensure that whichever software is used, that it employs VPN or SSH.

PCI compliance requires that remote access have a user ID and password, and an additional authentication factor that includes, but is not limited to, items such as a smart card, token, PIN, biometrics, VPN, etc.
For people with remote access, you must establish passwords according to PCI DSS requirements 8.1, 8.2, 8.4 and any requirements of all sections of 8.5. In other words, the requirements for remote access passwords and authentication are exactly the same as for access to your office LAN.

Microsoft Remote Access

If you are using remote access, you need to set up terminal server to use high security access for Remote Desktop and it should be set to disconnect or lock the terminal after a period of inactivity. (PCI requirement 12.3)

Windows 2003/2008 Server

When connecting from any workstation to 2003/2008 Server, the server defaults to high encryption. It is good practice to verify that the setting has not been lowered.

Step Purpose Installation instructions or link
1. Verify Terminal Server settings

The following links detail the security settings in Windows Server 2003. Server 2003 defaults to High encryption, but it is a good practice to make sure it hasn't been lowered accidentally.

support.microsoft.com/kb/814590

technet2.microsoft.com/windowsserver/en/library/a92d8eb9-f53d-4e86-ac9b-29fd6146977b1033.mspx?mfr=true

2. Verify RDP settings RDP should be set to always prompt for a password.

 

Windows 2000 Server

When connecting from any workstation to 2000 server, the server setting workstation is allowed to specify the security level and, unfortunately, it defaults to the lowest security level. You need to make some changes to the settings to connect at the high security level.

Step Purpose Installation instructions or link
1. Set up Terminal Server Settings

The Encryption Levels settings in Terminal Server should be set to High for the Remote Desktop Protocol. Refer to the tech note on the Microsoft web site for the proper procedure.

2. Verify RDP settings RDP should be set to always prompt for a password.

TeamViewer Remote Support

Theatre Manager uses TeamViewer for remote support. This is designed to never be active, unless the user contacts Arts Management and permits the technical staff to have access to their machine for the purpose of diagnosing a problem on a one time basis.

Remote access is to be

Theatre Manager never requires permanent access to your networks for any reason.

Remote Access/Support

The process for actual access to the remote machine is as follows:

  • The customer must initiate a support request that involves a phone conversation
  • In that phone conversation, it is determined that a timely resolution involves connecting remotely to provide assistance
  • Arts Management confirms the identity to the customer by providing the customer with the case number they created to continue with support (PCI requirement for second authentication).
  • The customer then starts the remote assistance software by clicking the Remote Support button from within the Theatre Manager application. Since you must have logged into Theatre Manager to activate remote support, It is not active by default.
  • The customer uses the remote assistance software to generate two keys: an ID and a random generated 8 character password (containing numbers and letters and, unique to the session). Both of these are conveyed to the AMS support representative.
  • Arts Management Support activates remote assistance manager and enters both keys to gain remote access
When Remote Access is disconnected, another remote support session requires a new set of keys to be provided. The customer is in complete control of the session at all times with a visual indicator showing the connection status.

How does it work?

TeamViewer uses SSH for authentication and brokering of session keys. It communicates with the master cluster through DNS names, which delegates the brokering of the session to the TeamViewer servers. Connection to the routing server and KeepAlive server is done directly via IP addresses.

The servers are spread across the globe and located at large data centers; their IP addresses are not organized in common subnets or IP ranges. TeamViewer continuously top scales the server network as the number of TeamViewer users grows, so it is not possible to have a fixed set of IP addresses, because this list would very soon be outdated.

Communication is done to URLs of the format:

  • *.teamviewer.com
  • *.dyngate.com
By default TeamViewer uses only the outgoing port 80 (HTTP) so that no firewall configuration is necessary. Alternatively you can open port 5938 (TCP) for outgoing connections if you wish to block port 80.

Outside the Firewall (the internet)

The internet is everything that occurs outside your firewall perimeter and represents everything that is beyond your control to protect.

This is where your customers will be.

Customer Access

Customers buying on the web need to be able to access the Apache web server through ports 80 and 443 in the DMZ. The web server sends cookies back to them.

Web Page Design Considerations

  • Your main web site should direct links to the Apache server via HTTPS so that the majority of access to online ticket sales is secure.
  • If a customer tries to access tickets.yourvenue.org through port 80, the first thing that the index page does is redirect them to a secure port.
  • If a customer does alter the URL and tries to access a page via port 80, the Theatre Manager web listener always responds back with a secure page and the next interaction will be through port 443
  • Ultimately, if you only wish secure access through the DMZ, you can turn off port 443 and customers will be forced to access via HTTPS. This is quite an aggressive approach and has some marketing implications - the safeguards above ensure that people are moved to HTTPS after hitting the web site for the first time.

What a customer needs to do (nothing)

A customer has zero configuration to do on their machines, other than to allow cookies from your site if they cannot browse the web pages. The Theatre Manager Web Listener will alert them to turn on cookies as it detects people trying to move through pages without cookies enabled.

PCI Audit Logs

PCI DSS sections 10.2 and 10.3 require that Theatre Manager maintain audit logs for certain system events. These primarily deal with who has seen or could have seen credit card information.

The transaction logs in Theatre Manager deal with all these requirements because Theatre Manager has always maintained an 'audit log' of certain system events that tracks the events required in PCI section 10.2 and the minimum required data elements for PCI section 10.3.

PCI DSS section 10.5 requires centralization of all system related logs in a common log management process in a protected manner. The intent from the PCI council is that you could view access to login/out and card data in Theatre Manager along with firewall access changes or admin access to a machine or server in a consolidated view.

You can export the logs from Theatre Manager in Excel or tab delimited format and move them to your centralized logging mechanism.

Accessing the Audit Log

All financial and access audit log transactions are kept forever. Transactions for Login, Logout, Invalid Access, and Viewing Complete Card Data are kept in perpetuity. Transaction types are 'coded' and 'dated' for easy finding and sorting.

Access to the audit log is from the Setup Menu.

This will bring up a screen similar to the one below which is a sample of an audit log that is contained within the transaction records in Theatre Manager.

Exporting Audit Logs to External Logger

PCI DSS compliance section 10.5 requires centralization of logs in a common log management process. The intent from the PCI council is that you could view access to login/out and card data in Theatre Manager along with firewall access changes or admin access to a machine or server in a consolidated view.

You can export the logs from Theatre Manager in Excel or tab delimited format and move them to your centralized logging mechanism.

Audit logs are kept forever as part of the database. You can search for any past history and re-export them if you desire. Database backups will contain the logs in existence at time of backup.

Once you have accessed the Audit log and are viewing on the screen as per the sample below, to obtain the logs for a specified period of time:
  • Search the logs by transaction date for all new logs since the last export
  • Click the Export Button on the top of the screen and select export to Excel or tab format as required
  • Provide a file name as a place to save the logs
  • Import those into your centralized logging mechanism

Audit Log Description

td>
PCI Std. Requirement Theatre Manager Implementation
10.2 Implement automated audit trails for all system components to reconstruct the following events:
10.2.1 All individual accesses to cardholder data Theatre Manager creates an 'AC' transaction to track whenever a user sees the entire credit card number. By default, Theatre Manager displays masked card numbers in all windows and reports. Only in specific places will Theatre Manager display card information to those who have specific authorization to see cards. Therefore, you should expect to see very little information in the audit log if you minimize who has access to see full card data.

The act of accepting a credit card at the box office is tracked with a PT audit transaction - i.e. the actual payment - and can be tracked by the user that way. Since this is a normal business act (accepting a card from a patron and typing it in), it is not necessary to also create an audit log.

None of these transactions can be purged.

10.2.2 All actions taken by any individual with root or administrative privileges An administrative user is subject to the same rigorous requirements as all other users.
10.2.3 Access to all audit trails Theatre Manager does not track who views audit trails because they cannot be changed, manipulated or altered by the user in any way. We believe that when users know this information is tracked for PCI compliance, it acts as an additional deterrent. None of the logs ever display sensitive data.
10.2.4 Invalid logical access attempts Theatre Manager tracks who accesses Theatre Manager and when they log in or out via the 'ALI' and 'ALO' transactions.

'ALX' transactions track invalid login attempts (after 3 mistyped passwords), or when the user account is locked out.

These transactions cannot be purged.

10.2.5 Use of identification and authentication mechanisms Theatre Manager uses login and authentication mechanisms. All users of the application must log in.
10.2.6 Initialization of the audit logs The audit logs can never be 'initialized' by the user, nor can be they be cleared except under programmatic control. The minimum retention time is 365 days for audit transactions with the default being forever. Payment logs indicating who took the actual payment are retained forever and cannot be deleted.
10.2.7 Creation and deletion of system-level objects  
10.3 Record at least the following audit trail entries for all system components for each event:

10.3.1 User identification yes - see log example in the user column.
10.3.2 Type of event yes - see log example for the specific transaction codes, expanded description and details about the specific activity.
10.3.3 Date and time yes - see log example
10.3.4 Success or failure indication yes - see log example. Failure logs show when a user tries to log in and forgot their password.
10.3.5 Origination of event yes - see log example for the IP address of the machine that created the event and the user
10.3.6 Identity or name of affected data, system component, or resource yes - see log example - this illustrates an example where a user viewed a specific credit card in full. The patron's name is displayed in the first and last name column.

Compliance Statement required by PCI Council

The PCI council represents the credit card companies. They dictate to vendors that products must be assessed, certified, and approved by them in order to appear on the list of 'Accepted Products'. In the fine print that is part of their processes, the PCI council has a specific clause we must relay to you.

It is repeated verbatim below so that there can be no mistaking what we have been instructed to do.

Vendor shall comply with, and communicate (in a reasonably manner determined by Vendor) to all purchasers and other licensees of Vendor Products that have been Accepted under any of the Programs, the following statement:

“Acceptance and/or listing of a given product by the PCI Security Standards Council, LLC (PCI SSC) only applies to the specific version of that product that was reviewed by an assessor or test laboratory qualified by PCI SSC (Assessor) and subsequently accepted and listed by PCI SSC (the “Accepted Version”), and only while such acceptance and listing are in effect. If any aspect of a product or version thereof is different from that which was reviewed by the applicable Assessor and accepted and listed by PCI SSC – even if the different product or version (the “Alternate Version”) conforms to the basic product description of the Accepted Version – then the Alternate Version should not be considered accepted by PCI SSC, nor promoted as such. The authoritative lists of products currently accepted by PCI SSC can be found on the PCI SSC website at www.pcisecuritystandards.org. Please notify PCI SSC if you believe that any product purportedly accepted by PCI SSC does not appear on these lists.

No vendor or other third party may refer to a product as “PCI Approved” or “PCI SSC Approved”, and no vendor or other third party may otherwise state or imply that PCI SSC has, in whole or part, accepted or approved any aspect of a vendor or its services or products, except to the extent and subject to the terms and restrictions expressly set forth in a written agreement with PCI SSC, or in a corresponding letter of acceptance provided by PCI SSC. All other references to PCI SSC’s approval or acceptance of a product or version thereof are strictly and actively prohibited by PCI SSC, should be reported to PCI SSC, and constitute a breach of applicable PCI SSC program requirements.

When granted, PCI SSC acceptance is provided to signify the Assessor’s determination that the product has demonstrated achievement of certain security and operational characteristics important to the security of payment card data, but such acceptance does not under any circumstances include or imply any endorsement or warranty by PCI SSC regarding the product vendor, the product, or the functionality, quality, or performance of the product or any other product or service. PCI SSC does not warrant any products or services provided by third parties. PCI SSC acceptance does not, under any circumstances, include or imply any product warranties from PCI SSC, including, without limitation, any implied warranties of merchantability, fitness for purpose or noninfringement, all of which are expressly disclaimed by PCI SSC. To the extent any rights or remedies regarding products or services that have received acceptance from PCI SSC are provided, those rights and remedies shall be provided by the party providing such products or services, and not by PCI SSC or any of its payment brand members.”

Misc PCI Requirements

The following section documents some of the final miscellaneous additional PCI compliance requirements that merchants will need to know or be aware of. These are presented here as 'things to do or know about' because they are not relevant in other parts of the installation guide.

Please use these as ticklers to yourself.

If card data is to be transmitted over a public network (i.e. outside your firewall), it must be sent using secure encryption technology like IPSEC, VPN or via SSL/TLS per PCI DSS 4.1.
Do not send any credit card data 'in the clear' such as pasting a card number into an email, or into an IM per PCI DSS 4.2 unless you are using secure encryption with these messaging technologies. Do not encourage customers to send card numbers, CVV2 numbers, name, expiry dates, or any other such data to you via the same technologies.

Theatre Manager does not provide this feature due to PCI compliance and only presents the final 4 characters to users for this reason.

If you are upgrading from a prior system that might have had unencrypted credit card information, you must throw that data into the trash and secure erase it with a tool like ERASER (free) on the PC or use File Menu -> Secure Erase on Mac.

Card Flow Across System

This diagram indicates the flow of card information in the various parts of the lan segments described in the network architecture.

(Click to enlarge as a pdf)

Vulnerability Identification and Assessment

PCI requires that a venue establish a listing of security vulnerabilities and track them in a database as well as implementing programs to prevent vulnerabilities PCI requirement 6.2

We provide a list of vulnerabilities & patches specific to Theatre Manager and its components, and update our installers regularly to address known issues.

Addressing PCI compliance and preventing most security issues is as simple as:

  • Keeping Theatre Manager up to date with the latest version
  • Updating all operating systems to current updates from the vendor
  • Having current anti-virus software in place

However, this is only one aspect of protecting your network. It is far more likely that vulnerabilities will arise from other programs. Here are some links that might be of interest to you to help maintain the health of your computers and networks.

Item Purpose
NIST.gov This web site has a list of recent security issues from the government web site. It is useful for seeing if there is something pertinent to your software suite. This is worth searching on a periodic basis.
NIST.org This web site has a summary of common security fixes and patches distilled from the government web site.
Secunia
PC only
PC's are vulnerable in a number of ways. Secuia is a free tool (for personal use) that inspects your PC and tells you about any vulnerabilities you may have on your PC that you are unaware of, and will automatically update versions of other software.

Note: Never forget to have anti-virus software on your machine.

Software Update Mac Only OS X has a software update feature for the operating system. As of Mountain Lion, Apple is encouraging a number of developers to deploy using the App Store to help keep you up to date. If you have a number of utilities, this may be useful for you.
OSVDB This is an open source vulnerabilities database. We look at this periodically to see if there is anything that might affect tools that we supply to you. Apache and Postgres are both open source, so this is of interest to us. You may find other information, especially if you are using many open source tools.
QUALYS SSL Labs Use this to bverify if an SSL is setup right and if system scans are looking for new vulnerabilities

Apache PCI Update Notices

Periodically, we learn of new issues that may prevent a PCI scan from completing at a venue. These will be listed here as things you may need to do in response to emerging issues. Please be sure to implement all of them.

The date in front of the web pages below indicate approximately when the fix was released.

When we learn of one, you should upgrade Apache to the latest version to simply eliminate some PCI scan messages (see links below). Each advisory is incorporated into the latest installs where possible.

The latest Apache installers have fixes for all advisories and following the upgrade instructions for Apache should suffice to meet all identified vulnerabilities below.

Apache/Open SSL security Notices

Date Vulnerability Description Action
2012-06-14 CVE-2012-3499 Various XSS flaws due to unescaped hostnames and URIs HTML output in mod_info, mod_status, mod_imagemap, mod_ldap, and mod_proxy_ftp.

Upgrade Apache to 2.4.4 or later

2012-08-21 CVE-2012-4558 XSS in mod_proxy_balancer manager interface. Upgrade Apache to 2.4.4 or later This is used for the second generation listener
2012-01-19 CVE-2012-0883 Fix insecure handling of LD_LIBRARY_PATH that could lead to the current working directory to be searched for DSOs. Upgrade to Apache 2.4.3 or later to prevent listing of items
2011-12-07 CVE-2012-0053 Fix an issue in error responses that could expose "httpOnly" cookies when no custom ErrorDocument is specified for status code 400 Upgrade to Apache 2.4.1 or later
2011-12-07 CVE-2012-0021 Fix segfault (crash) when the '%{cookiename}C' log format string is in use and a client sends a nameless, valueless cookie, causing a denial of service. The issue existed since version 2.2.17 and 2.3.3. Upgrade to Apache 2.4.0 or later
2012-05-10 CVE-2012-2333 Sanity check record length before skipping explicit IV in TLS 1.2, 1.1 and DTLS to avoid DoS attack. Upgrade to OpenSSL 1.0.1c
2012-04-19 CVE-2012-2110 Check for potentially exploitable overflows in asn1_d2i_read_bio BUF_mem_grow and BUF_mem_grow_clean. Refuse attempts to shrink buffer in CRYPTO_realloc_clean Upgrade to OpenSSL 1.0.1a
2012-03-12 CVE-2012-0884 Fix MMA (Bleichenbacher's attack on PKCS #1 v1.5 RSA padding) weakness in CMS and PKCS7 code. When RSA decryption fails use a random key for content decryption and always return the same error. Note: this attack needs on average 2^20 messages so it only affects automated senders. The old behaviour can be reenabled in the CMS code by setting the CMS_DEBUG_DECRYPT flag: this is useful for debugging and testing where an MMA defence is not necessary. Upgrade to OpenSSL 1.0.0g
2012-01-18 CVE-2012-0050 Fix for DTLS DoS issue introduced by fix for CVE-2011-4109 Upgrade to 1.0.0f
2012-01-04 CVE-2011-4108 Nadhem Alfardan and Kenny Paterson have discovered an extension of the Vaudenay padding oracle attack on CBC mode encryption which enables an efficient plaintext recovery attack against the OpenSSL implementation of DTLS. Their attack exploits timing differences arising during decryption processing. A research paper describing this attack can be found at: http://www.isg.rhul.ac.uk/~kp/dtls.pdf Upgrade to 1.0.0e
2012-01-04 CVE-2011-4576 Clear bytes used for block padding of SSL 3.0 records Upgrade to 1.0.0e

2010-01 Improve Cipher Suite security

Edit the extra/httpd-ssl.conf file and look for the line of code that pertains to SSLCihperSuite. Then make changes as below. You will end up commenting the existing line and adding two lines in bold.

note: this change is included in the latest install of apache. Older sites will need to make this change.

#
# SSL Cipher Suite:
# List the ciphers that the client is permitted to negotiate.
# See the mod_ssl documentation for a complete list.
# Updated the following Apache Core Features for PCI Compliance reasons
# Refer to: http://httpd.apache.org/docs/2.0/mod/mod_ssl.html#sslprotocol
# Refer to: http://httpd.apache.org/docs/2.0/ssl/ssl_howto.html
# Synopsis : The remote service supports the use of medium strength SSL ciphers.
# Description : The remote host supports the use of SSL ciphers that offer medium
# strength encryption, which we currently regard as those with key lengths
# at least 56 bits and less than 112 bits.
# Solution: Reconfigure the affected application if possible to avoid use of medium
# strength ciphers.
#SSLCipherSuite ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL
SSLProtocol -all +TLSv1 +SSLv3
SSLCipherSuite HIGH:!aNULL:+SHA1:+MD5:+HIGH

2010-01 Prevent Trace and directory listings

If you are doing compliance scans and using windows as an Apache Server, then you may want to update to the Apache 2.2.15 (or later) if your scans are failing.

Edit the httpd.conf file and add changes as below at the end of the file. They address some recent items that PCI security scans now look for.

# ---------------------- to tighten security in browser ----------
# Updated the following Apache Core Features for PCI Compliance reasons
# Disable the TRACE/TRACK command
# refer to: http://httpd.apache.org/docs/1.3/mod/core.html#traceenable
TraceEnable Off

# To enforce or deny complete folder listing
# refer to: http://httpd.apache.org/docs/1.3/mod/mod_autoindex.html#indexignore
IndexIgnore *

    2010-04 .DS_STORE files flagged as issues

    If you navigate the Apache htdocs folder using a Macintosh, it will leave hidden files with the name '.DS_STORE' in the directories. Those files are used by the OSX file system to remember how the window was opened and what view they should be in - a fairly convenient feature.

    The PCI guardians have determined that they do not like any hidden files in the htdocs directory as they view it as a possible attack vector - and if a PCI compliance scan finds these, it will flag you as non-compliant.

    As of Apache installer 2.4.4 for TM version 9.23 we have replaced some apache configuration settings that should just allow you to pass. If you are not passing your PCI scan, make sure you are at the latest version of apache. Alternately, follow the procedure below:

    • OSX Apache: We have created a script for you that you can run daily using cronnix that will clean out these files automatically. You will find this in the /Users/Shared directory called 'TMApachePCIScan.php'.
    • Use Cronnix to create a daily job on your apache machine to run this script. Cronix is installed as part of the Apache installer into your Applications folder. The setup is similar to below. (if you cannot find it, click on the google source forge link to download)

    • Windows Apache: use find files to find all ".DS_STORE" files on your machine and delete them.

    Note: The installation process removes these files for you automatically, but they will come back if your web designer edits any web pages on a Mac by virtue of opening any folder inside the htdocs directory.

    2010-11 FileEtag

    If you are getting messages about FileEtag in your compliance scan, you may need to add the following to your httpd.conf file. This is provided with the latest TM installers.

    Edit the httpd.conf file and add changes as below at the end of the file. They address some recent items that PCI security scans now look for.

    # To remove Inode information from ETag
    FileETag MTime Size

    2011-11 OpenSSL < version 1.0.0e on OSX

    This assumes that your PCI scan is failing on your OSX apache server verison 2.2.17 or later. Normally Apple updates operating system components but in the case of OpenSSL, it is compiled right into the Apache server.

    The latest version of our apache installers for OSX include openssl 1.0.0e and all you need do is upgrade to the latest version of Apache.

    2012-01 Open SSL 1.0.0g on Windows

    We have been hearing that recent Security Metrics PCI scans have identified a vulnerability in OpenSSL version 0.9.8. There is a new version of OpenSSL 1.0.0g that should be installed on MS Windows Apache server. Normally this comes as part of Apache and is installed automatically but Apache Software Foundation has not released a version as of yet.

    The remedy is to download and install an another flavor of Apache and upgrade that version of Apache to use OpenSSL 1.0.0g or higher from Apache Haus

    NOTE: Apache 2.2.22 and OpenSSL 1.0.0g are the most recent versions available as of updating this web page on Jan 31, 2012. The respective organizations who maintain the installers for Apache and OpenSSL may release new updates at any time. It is your organizations responsibility to check that they are installing the most recent version at the time of update.

    Your options are:

    • Wait until Apache Software Foundation releases a version with OpenSSL 1.0.0g or higher
    • Install the version of Apache as outlined below
    • Have Arts Management install the version of Apache as outlined below
    • Leave things as they are for a while, knowing that a PCI test 'may' continue to indicate that the OpenSSL needs to be upgraded. After you have evaluated the risk assessment from the PCI report, you can choose to address it at sometime in the future - or - accept the risk and not upgrade at this time.

    There is a bit of work to do to perform this and takes approximately 1 hour worth of time. Web sales will need to be taken offline for approximately 5 minutes during the process -- meaning you can do this upgrade during a time when there is minimal web sales activity.

    • On the computer running as the Apache server, download:
      • STEP 1 - Install Apache 2.2.22
      • If required, install the Microsoft Visual C++ 2008 Redistributable Package and Service Packs
      • Extract the httpd-2.2.22-ssl-x86.zip files
      • Review the two "readme_first.html" files located within the respective extracted folder
      • Move the httpd-2.2.22-ssl-x86.zip extracted files and place in the root c:\ level and called c:\Apache22
      • Delete all files in the c:\Apache22\htdocs folder
        STEP 2 - Update to the most recent version of OpenSSL
        NOTE: Skip these next 4 steps as Apache 2.2.22 contains the most recent version of OpenSSL 1.0.0g
      • If required, install the Microsoft Visual C++ 2008 Redistributable Package and Service Packs
      • Extract the openssl-1.0.0d-update-sni-x86.zip files
      • Review the two "readme_first.html" files located within the respective extracted folder
      • Move the openssl-1.0.0d-update-sni-x86.zip extracted files and replace the respective files in the c:\Apache22 folder
        STEP 3 - Move your existing Theatre Manager Web Sales Setup Information
      • From the existing copy of Apache in the c:\Program Files\Apache Software Foundation\Apache2.2 folder, copy over to the c:\Apache2.2 folder:
        • \data (the entire folder)
        • \modules\tm_mod.so
        • \htdocs (the entire folder)
        • \conf\server.crt and place into the \conf\ssl folder
        • \conf\server.key and place into the \conf\ssl folder
        • \conf\server.csr (this file may not exist) and place into the \conf\ssl folder
        • \conf\ca-bundle.crt (this file may not exist) and place into the \conf\ssl folder
      • Update (DO NOT COPY) c:\Apache22\conf\httpd.conf with the required Theatre Manager information from c:\Program Files\Apache Software Foundation\Apache2.2\httpd.conf
      • Update (DO NOT COPY) c:\Apache22\conf\extra\httpd-ssl.conf with the required Theatre Manager information from c:\Program Files\Apache Software Foundation\Apache2.2\extra\httpd-ssl.conf
      • Review the httpd.conf and httpd-ssl.conf files for any additional PCI update/requirements that may need to be added or adjusted as per Theatre Manager's release notes and Theatre Manager's Apache setup configuration guide
      • Stop Theatre Manager's Web Listener(s)
      • De-install the existing application of Apache2.2 via Windows "Add/Remove Programs"
      • Install c:\Apache22 as a service (as each Windows OS is unique, refer to your local IT support for assistance)
      • Go into Windows Services Window and start the Apache service
      • Start Theatre Manager's Web Listener(s)
      • Update Windows Startup folder to have it automatically start Apache Monitor upon login
      • Delete the c:\Program Files\Apache Software Foundation folder
      • Update FileZilla User settings for Theatre Manager's eblast home folder to be c:\Apache22\htdocs

      Then try your PCI scan again. We understand from the PCI council that you have approximately 30 days from identification of the problem at your venue to resolution. Select a slow day to do the upgrade as it should only take approximately 1+/- hours to complete. (as this may be your first and perhaps only time doing it, we would recommend that you allocate 2+/- hours just in case)

      If you wish to have Arts Management perform the above upgrades to your copy of Apache, please let us know and we will schedule a date/time with you. It typically takes approximately 1+/- hours to complete and is deemed a billable service.

      Some of the gotcha's you may encounter along the way are:

      • On the Apache Server, you must first install the Visual C++ 2008 Redistributable Packages
      • If you have a x64 bit machine, you still must install the x86 Visual C++ 2008 Redistributable Packages
      • If you have a x64 bit machine, you still must install the x86 version of Apache2.2
      • When editing the /conf/extra/httpd-ssl.conf file, you must also update the ServerName and ServerAdmin parameters
      • The placement of the SSL certificate location is different and is located in the c:\Apache22\conf\ssl folder
      • When attempting to install Apache as a service, if you receive "unauthorized access errors", go back and start the Command console again by Right-clicking on it and selecting "Run as Administrator"
      • When attempting to install Apache as a service, if you receive "side-by-side errors", go verify if you have installed the Visual 2008 C++ Redistributable Packages

      We have tried the following OpenSSL links, however they did not prove to be successful when using the OpenSSL 1.0.0.d upgrade with the standard installation of Apache 2.2.17

    2012-11 Browsable Web Directories

    Browsable Web Directories indicate the scan can reach the numeric folder within the htdocs folder. Although it cannot see any of the files or folders within this folder, accessing the folder causes the scan to fail. This Failure has only been seen on Windows machines where Apache is installed. This does not limit it to this platform however the steps below reference the paths within the windows environment.

    • Open the c:\Apache24\htdocs folder.
    • Select the index.html page.
    • Right click on the index.html page and select the copy options.
    • Open the c:\Apache24\htdocs\1 folder.

      Please note the number 1 references the outlet number. It is possible the Outlet number for an organization may be something other then 1. If this is the case open the numeric folder. If there are multiple outlets the steps below will need to be repeated for each Outlet.

    • Right click within the folder.
    • Select Paste.

      The index.html page will be added to the folder. This will resolve the Browsable Web Directories error in the Security Metrics Scan.

    Note: this setup is part of all future web page installations on mac and windows platforms.

    2013-03 Apache 2.4.4/OpenSSL 101e

    Apache 2.4.4 was released in Feb 25, 2013 along with Open SSL 1.0.1e. If you receive a failing scan highlighting these components, you will need to upgrade them.

    There are some notes about Apache 2.4.4

    • For OSX: the installers are 64 bit and for OSX 10.6.8 or later. This means you require a core 2 duo machine (circa 2007 or later)
    • For windows: apache is still 32 bit and has been tested on windows 2000 through Windows 8. It should run on all platforms

    2014-04 CVE-2014-0160 Heartbleed bug

    What is the CVE-2014-0160?

    CVE-2014-0160 is the official reference to this bug. CVE (Common Vulnerabilities and Exposures) is the Standard for Information Security Vulnerability Names maintained by the MITRE. Due to co-incident discovery a duplicate CVE, CVE-2014-0346, which was assigned to us, should not be used, since others independently went public with with the CVE-2014-0160 identifier.

    For more info, please refer to heartbleed bug documentation. This site explains it reasonably well.

    Fixed in Apache 2.4.9 download

    2014-08 Apache 2.4.10 Openssl 1.0.1i

    There is an update to Openssl to address recently discovered vulnerabilities in OpenSSL 1.0.1. Updating should be relatively easy to update if you already have apache 2.4.9 or later

    CVE-2014-3512 Fix SRP buffer overrun vulnerability. Invalid parameters passed to the SRP code can be overrun an internal buffer. Add sanity check that g, A, B
    CVE-2014-3511 A flaw in the OpenSSL SSL/TLS server code causes the server to negotiate TLS 1.0 instead of higher protocol versions when the ClientHello message is badly fragmented. This allows a man-in-the-middle attacker to force a downgrade to TLS 1.0 even if both the server and the client support a higher protocol version, by modifying the client's TLS records.
    CVE-2014-3510 OpenSSL DTLS clients enabling anonymous (EC)DH ciphersuites are subject to a denial of service attack. A malicious server can crash the client with a null pointer dereference (read) by specifying an anonymous (EC)DH ciphersuite and sending carefully crafted handshake messages.
    CVE-2014-3507 By sending carefully crafted DTLS packets an attacker could cause openssl to leak memory. This can be exploited through a Denial of Service attack.
    CVE-2014-3506 An attacker can force openssl to consume large amounts of memory whilst processing DTLS handshake messages. This can be exploited through a Denial of Service attack.
    CVE-2014-3505 An attacker can force an error condition which causes openssl to crash whilst processing DTLS packets due to memory being freed twice. This can be exploited through a Denial of Service attack.
    CVE-2014-3509 If a multithreaded client connects to a malicious server using a resumed session and the server sends an ec point format extension it could write up to 255 bytes to freed memory
    CVE-2014-5139 SL client with a null pointer dereference (read) by specifying an SRP ciphersuite even though it was not properly negotiated with the client. This can be exploited through a Denial of Service attack.
    CVE-2014-3508 A flaw in OBJ_obj2txt may cause pretty printing functions such as X509_name_oneline, X509_name_print_ex et al. to leak some information from the stack. Applications may be affected if they echo pretty printing output to the attacker.

    2014-10 OpenSSL 1.0.1j

    please read the openssl release info more detailed information. The latest Apache2.4.10/openssl 1.0.1j installers for your platform includes all fixes.

    SRTP Memory Leak (CVE-2014-3513)

    Severity: High

    A flaw in the DTLS SRTP extension parsing code allows an attacker, who sends a carefully crafted handshake message, to cause OpenSSL to fail to free up to 64k of memory causing a memory leak. This could be exploited in a Denial Of Service attack. This issue affects OpenSSL 1.0.1 server implementations for both SSL/TLS and DTLS regardless of whether SRTP is used or configured. Implementations of OpenSSL that have been compiled with OPENSSL_NO_SRTP defined are not affected.

    2014-10 POODLE Attack (CVE-2014-3566)

    The POODLE Attack is restricted to the SSL v3 protocol used by older browsers and is described as a man-in-the middle attack that can be hard to do unless the intruder in within your wifi network.

    It may prevent older browsers on windows XP like IE 6 from being able to use your web site, but thats a small part of the market these days.

    Disabling SSLv3 is straightforward. In the /conf/extras/httpd-balance.conf file, look for the following line:

    SSLProtocol ALL -SSLv2

    and change it to

    SSLProtocol ALL -SSLv2 -SSLv3

    After making the change:

    • restart apache
    • Verify your servers protection standing. using the SSL Labs test page if you wish.

    2015-02 Apache 2.4.12

    Fixes:

    CVE-2014-3583 (cve.mitre.org) mod_proxy_fcgi: Fix a potential crash due to buffer over-read, with response headers' size above 8K.
    CVE-2014-3581 (cve.mitre.org) mod_cache: Avoid a crash when Content-Type has an empty value. PR 56924.
    CVE-2014-8109 (cve.mitre.org) mod_lua: Fix handling of the Require line when a LuaAuthzProvider is used in multiple Require directives with different arguments. PR57204.
    CVE-2013-5704 (cve.mitre.org) core: HTTP trailers could be used to replace HTTP headers late during request processing, potentially undoing or otherwise confusing modules that examined or modified request headers earlier. Adds "MergeTrailers" directive to restore legacy behavior.

    2015-03 OpenSSL 1.0.2a

    On March 19 2015 , some vulnerabilities were announced by the openssl organization.

    We have updated our apache installers to 2.4.12 with openssl 1.0.2a to provide the latest for people. Refer to the Upgrade Instructions or ask support for assistance.

    2015-06 Apache 2.4.16 OpenSSL 1.0.2d TLS 1.2 and CLickjacking

    The latest installers include updates to apache and OpenSSL 1.0.2d to address announced security vulnerabilities.

    The Apache configuration has been changed to limit access using TLS 1.2 (TLS 1.0 and TLS 1.1 have been disabled). This will limit older version of internet explorer from connecting to the commerce site.

    Also added a setting in httpd.conf is a setting to prevent click-jacking by disabling use of iFrames within the web site.

    2015-12 Apache 2.4.17 OpenSSL 1.0.2e

    Upgrading is recommended

    Major changes between OpenSSL 1.0.2d and OpenSSL 1.0.2e [3 Dec 2015]

    • BN_mod_exp may produce incorrect results on x86_64 (CVE-2015-3193)
    • Certificate verify crash with missing PSS parameter (CVE-2015-3194)
    • X509_ATTRIBUTE memory leak (CVE-2015-3195)
    • Rewrite EVP_DecodeUpdate (base64 decoding) to fix several bugs
    • In DSA_generate_parameters_ex, if the provided seed is too short, return an error

    2016-01 Apache 2.4.18 OpenSSL 1.0.2f

    The open ssl foundation released an update to OpenSSL and issued an OpenSSL advisory. At the same time, we have updated the apache installers to version 2.4.18.

    PCI compliance section 6.2 requires that we make these available to you as soon as possible.

    CVE-2016-0701 [High severity] 28th January 2016

    Historically OpenSSL usually only ever generated DH parameters based on "safe" primes. More recently (in version 1.0.2) support was provided for generating X9.42 style parameter files such as those required for RFC 5114 support. The primes used in such files may not be "safe". Where an application is using DH configured with parameters based on primes that are not "safe" then an attacker could use this fact to find a peer's private DH exponent. This attack requires that the attacker complete multiple handshakes in which the peer uses the same private DH exponent. For example this could be used to discover a TLS server's private DH exponent if it's reusing the private DH exponent or it's using a static DH ciphersuite. OpenSSL provides the option SSL_OP_SINGLE_DH_USE for ephemeral DH (DHE) in TLS. It is not on by default. If the option is not set then the server reuses the same private DH exponent for the life of the server process and would be vulnerable to this attack. It is believed that many popular applications do set this option and would therefore not be at risk. OpenSSL before 1.0.2f will reuse the key if: - SSL_CTX_set_tmp_dh()/SSL_set_tmp_dh() is used and SSL_OP_SINGLE_DH_USE is not set. - SSL_CTX_set_tmp_dh_callback()/SSL_set_tmp_dh_callback() is used, and both the parameters and the key are set and SSL_OP_SINGLE_DH_USE is not used. This is an undocumted feature and parameter files don't contain the key. - Static DH ciphersuites are used. The key is part of the certificate and so it will always reuse it. This is only supported in 1.0.2. It will not reuse the key for DHE ciphers suites if: - SSL_OP_SINGLE_DH_USE is set - SSL_CTX_set_tmp_dh_callback()/SSL_set_tmp_dh_callback() is used and the callback does not provide the key, only the parameters. The callback is almost always used like this. Non-safe primes are generated by OpenSSL when using: - genpkey with the dh_rfc5114 option. This will write an X9.42 style file including the prime-order subgroup size "q". This is supported since the 1.0.2 version. Older versions can't read files generated in this way. - dhparam with the -dsaparam option. This has always been documented as requiring the single use. The fix for this issue adds an additional check where a "q" parameter is available (as is the case in X9.42 based parameters). This detects the only known attack, and is the only possible defense for static DH ciphersuites. This could have some performance impact. Additionally the SSL_OP_SINGLE_DH_USE option has been switched on by default and cannot be disabled. This could have some performance impact. Reported by Antonio Sanso (Adobe).

    Fixed in OpenSSL 1.0.2f (Affected 1.0.2e, 1.0.2d, 1.0.2c, 1.0.2b, 1.0.2a, 1.0.2)

    Read the following link for making a dhparam file

    CVE-2015-3197 [Low severity] 28th January 2016

    A malicious client can negotiate SSLv2 ciphers that have been disabled on the server and complete SSLv2 handshakes even if all SSLv2 ciphers have been disabled, provided that the SSLv2 protocol was not also disabled via SSL_OP_NO_SSLv2. Reported by Nimrod Aviram and Sebastian Schinzel.

    Fixed in OpenSSL 1.0.2f (Affected 1.0.2e, 1.0.2d, 1.0.2c, 1.0.2b, 1.0.2a, 1.0.2)

    2016-03 Apache 2.4.18 OpenSSL 1.0.2g

    The open ssl foundation released an update to OpenSSL and issued an OpenSSL advisory. The majority of the changes affect openssl v2 which we turned off long ago in our Apache installers.

    PCI compliance section 6.2 requires that we make these available to you as soon as possible.

    CVE-2016-0800 [High Severity] Cross-protocol attack on TLS using SSLv2 (DROWN)

    A cross-protocol attack was discovered that could lead to decryption of TLS sessions by using a server supporting SSLv2 and EXPORT cipher suites as a Bleichenbacher RSA padding oracle. Note that traffic between clients and non-vulnerable servers can be decrypted provided another server supporting SSLv2 and EXPORT ciphers (even with a different protocol such as SMTP, IMAP or POP) shares the RSA keys of the non-vulnerable server. This vulnerability is known as DROWN (CVE-2016-0800).

    Recovering one session key requires the attacker to perform approximately 2^50 computation, as well as thousands of connections to the affected server. A more efficient variant of the DROWN attack exists against unpatched OpenSSL servers using versions that predate 1.0.2a, 1.0.1m, 1.0.0r and 0.9.8zf released on 19/Mar/2015 (see CVE-2016-0703 below).

    Users can avoid this issue by disabling the SSLv2 protocol in all their SSL/TLS servers, if they've not done so already. Disabling all SSLv2 ciphers is also sufficient, provided the patches for CVE-2015-3197 (fixed in OpenSSL 1.0.1r and 1.0.2f) have been deployed. Servers that have not disabled the SSLv2 protocol, and are not patched for CVE-2015-3197 are vulnerable to DROWN even if all SSLv2 ciphers are nominally disabled, because malicious clients can force the use of SSLv2 with EXPORT ciphers.

    OpenSSL 1.0.2g and 1.0.1s deploy the following mitigation against DROWN:

    SSLv2 is now by default disabled at build-time. Builds that are not configured with "enable-ssl2" will not support SSLv2. Even if "enable-ssl2" is used, users who want to negotiate SSLv2 via the version-flexible SSLv23_method() will need to explicitly call either of:

    SSL_CTX_clear_options(ctx, SSL_OP_NO_SSLv2);
    or
    SSL_clear_options(ssl, SSL_OP_NO_SSLv2);

    as appropriate. Even if either of those is used, or the application explicitly uses the version-specific SSLv2_method() or its client or server variants, SSLv2 ciphers vulnerable to exhaustive search key recovery have been removed. Specifically, the SSLv2 40-bit EXPORT ciphers, and SSLv2 56-bit DES are no longer available.

    In addition, weak ciphers in SSLv3 and up are now disabled in default builds of OpenSSL. Builds that are not configured with "enable-weak-ssl-ciphers" will not provide any "EXPORT" or "LOW" strength ciphers.

    OpenSSL 1.0.2 users should upgrade to 1.0.2g
    OpenSSL 1.0.1 users should upgrade to 1.0.1s

    This issue was reported to OpenSSL on December 29th 2015 by Nimrod Aviram and Sebastian Schinzel. The fix was developed by Viktor Dukhovni and Matt Caswell

    Postgres Vulnerability List

    The Theatre Manager postgres installers are always updated to the most recent version of postgres as soon possible after the postgres version it is released, ensuring any vulnerabilities are addressed by Arts Management as soon as a fix is released by the Postgres foundation.

    Postgres vulnerabilities are monitored on the Postgres Security web site.

    Those immediately relevant to Theatre Manager are listed with the release notes for that version of Theatre Manager and may require a forced update to the database server before an update to Theatre Manager will allow connection to the server.

    mod_tm apache plugin

    The latest apache installers always have the latest mod_tm.so included and following the upgrade instructions for apache address al issues.

    Note: the need to use of this module is slowly being phased out as the TM Server (second generation) handles load balancing within the web services with the easy setup. As of version 10.06, it is no longer required.

    Mod_tm.so is a load balancer module for apache design specifically for the classic web listeners. This section indicates when issues were found and the resolution for the issues.

    1012-02 mod_tm 1.4.2 may crash apache

    The 1.4.2 version of the Apache Module is known to cause Apache to restart resulting in Theatre Manager's web listener crashing. This issue can be addressed by upgrading the version of the Apache Module to 1.4.7 or higher.

    2012-07 mod_tm 2.0.0 released for 64bit

    this version is identical in functionality to version 1.4.7 with two exceptions:
    • It was built for Apache 2.4.4 using apache 2.4.4 headers. (1.4.7 is for Apache 2.2.x)
    • it has been tested to run under 64 bit apache for OSX and windows

    Upgrading to apache 2.4.x will automatically install the most recent version of mod_tm.so.

    OWASP and Theatre Manager

    The Open Web Application Security Project (OWASP) is a 501c3 not-for-profit worldwide charitable organization focused on improving the security of application software. Their mission is to make application security visible, so that people and organizations can make informed decisions about true application security risks. Everyone is free to participate in OWASP and all of the materials are available under a free and open software license.

    The OWASP Top 10 for 2013 is interesting reading for application developers, web site builders and end users. The internet has many good features, but it is not a safe place if you are not aware.

    Each year, the Arts Management team reviews the top 10 and, for those that are applicable, ensures that the web sales module provides a defence against the top 10 per PCI standard 6.5. Requirements are posted here. Merchants should also be aware of these.
    In addition, please be aware that IFRAMES are disabled in Apache due to possibility of a ClickJacking attack. An iframe has typically been used by people selling marketing pixels to include their code in your web site. PCI council checks for Click Jacking opportunity - so we have disabled this in our standard web Server Setup.

    2015 Top 10 list (unchanged from 2013)

      Description Thestre Manager Implementation
    A1 SQL Injection Injection flaws, such as SQL, OS, and LDAP injection occur when untrusted data is sent to an interpreter as part of a command or query. The attacker’s hostile data can trick the interpreter into executing unintended commands or accessing data without proper authorization.

    OWASP's preferred option is to use a safe API which avoids the use of the interpreter entirely or provides a parameterized interface.

    In Theatre Manager, all web pages access the web listener using a parameterized API (generally html form) and each parameter is scrubbed on the way to the web listener for specific values. Only acceptable parameters are verified. Unacceptable parameters are rejected and ignored.

    A2 Broken Authentication and Session Management Application functions related to authentication and session management are often not implemented correctly, allowing attackers to compromise passwords, keys, or session tokens, or to exploit other implementation flaws to assume other users’ identities.

    Theatre Manager uses cookies for session management. All data in the cookie is AES256 encrypted, along with a date and time.

    If the web listener notices that the cookie comes back and contains an unexpected date and time setting, then it discards the request and resets the user.

    There are no session IDs in any URL.

    A3 Cross-Site Scripting (XSS) XSS flaws occur whenever an application takes untrusted data and sends it to a web browser without proper validation or escaping. XSS allows attackers to execute scripts in the victim’s browser which can hijack user sessions, deface web sites, or redirect the user to malicious sites.

    OWASP's preferred option is to properly escape all untrusted data based on the HTML context (body, attribute, JavaScript, CSS, or URL) that the data will be placed into.

    Theatre Manager looks for any attempt to put Javascript and other characters into a form and simply removes them. We have determined that there is no valid need to have words like <script> in enterable fields like name or address.

    A4 Insecure Direct Object References A direct object reference occurs when a developer exposes a reference to an internal implementation object, such as a file, directory, or database key. Without an access control check or other protection, attackers can manipulate these references to access unauthorized data.

    Theatre Manage does not allow direct access to any object in the database through the use of an API. Users cannot retrieve data in an unauthorized way as all queries are done via a controlled API.

    A5 Security Misconfiguration Good security requires having a secure configuration defined and deployed for the application, frameworks, application server, web server, database server, and platform. Secure settings should be defined, implemented, and maintained, as defaults are often insecure. Additionally, software should be kept up to date.

    The primary preventative measure for this is PCI security scans and upgrading of Theatre Manager components on a regular basis and following any implementation notes.

    Users are encouraged to install operating system upgrades as they are made available and to turn on automatic checking on all workstations. On servers, the practice is to verify weekly for updates and install on a controlled basis.

    Theatre Manager regularly offers the latest updates to web servers and SSL security patches when they are made available. Configuration files are hardened as vulnerabilities are detected (example: prevent directory listings is the default browser config).

    A6 Sensitive Data Exposure Many web applications do not properly protect sensitive data, such as credit cards, tax IDs, and authentication credentials. Attackers may steal or modify such weakly protected data to conduct credit card fraud, identity theft, or other crimes. Sensitive data deserves extra protection such as encryption at rest or in transit, as well as special precautions when exchanged with the browser.

    Theatre Manager handles encryption of the key card information and recommends shredding of unused data after a period of time. All credit card information is re-encrypted on a periodic basis per PCI compliance and the only information retained is per PCI standards.

    Theatre Manager web services use SSL for all traffic, which means using port 443 to the Apache server, and having a valid SSL certificate.

    Ensuring the SSL certificate is current is a responsibility of the monthly PCI scan process, and we contact customers when they are ready to expire.

    Users are encouraged to define a card retention period where TM will automatically shred cards based on their policy.

    A7 Missing Function Level Access Control Most web applications verify function level access rights before making that functionality visible in the UI. However, applications need to perform the same access control checks on the server when each function is accessed. If requests are not verified, attackers will be able to forge requests in order to access functionality without proper authorization.

    This does not directly apply to Theatre Manager's web services due to the APIs used to control access to the system -AND- the very limited number of pages in the Apache directory which are used exclusively for the singular function of web sales.

    Accessing the limited number of web pages in the htdocs directory in a direct manner does nothing unless they are processed by a web services. Further, all requests are sent through a specialized Apache module that adds additional tokens not known visible in the browser and reroutes the URL and does some NAT translation of its own.

    A8 Cross-Site Request Forgery (CSRF) A CSRF attack forces a logged-on victim’s browser to send a forged HTTP request, including the victim’s session cookie and any other automatically included authentication information, to a vulnerable web application. This allows the attacker to force the victim’s browser to generate requests the vulnerable application thinks are legitimate requests from the victim.

    Theatre Manager does not allow access to the database except via API. It also forces a timeout for inactivity and injects a unique form token key for each HTTP POST request.

    The cookie is time sensitive and is unique for each request sent from the server and back from the client. It is encrypted and contains other non-visible data that must be verified upon receipt back at the server. Failure to meet the verification requirements causes rejection of the request and the process to start over. Absence of a properly formatted and encrypted cookie rejects the request and starts over.

    The form token is a unique encrypted time-sensitive field that is placed into each web page by the server. When a form is submitted, the server checks the form token with what was sent out. If it does not match, the patron is sent to a 'safe' landing page. Currently, Theatre Manager sends patrons who are logged in to the 'home' page and those that are browsing anonymously to the 'event listing' page. No form can be submitted twice.

    A9 Using Known Vulnerable Components Components, such as libraries, frameworks, and other software modules, almost always run with full privileges. If a vulnerable component is exploited, such an attack can facilitate serious data loss or server takeover. Applications using components with known vulnerabilities may undermine application defenses and enable a range of possible attacks and impacts.

    Theatre Manager is designed to detect the version of significant components and will not start if the database version, web server version, or other significant components are insufficiently current.

    Most importantly, Apache is regularly reviewed and updated with security patches.

    A10 Unvalidated Redirects and Forwards Web applications frequently redirect and forward users to other pages and websites, and use untrusted data to determine the destination pages. Without proper validation, attackers can redirect victims to phishing or malware sites, or use forwards to access unauthorized pages.

    Theatre Manager does not use redirects to any unknown source in any commerce web page. All URLs returned by the server are specific to each API. Requests for APIs that do not exist return a proper 404 HTTP response (not found)

    PostgreSQL Database Server

    The following instructions are used to set up a PostgreSQL server for use with the Theatre Manager application. Please follow the directions appropriate for the server platform you are using.

    • Installation on a Macintosh
    • Installation on Windows
    • Postgres will run on Linux and other Unix variants. You will have to install the server yourself by obtaining it from the PostgreSQL web site and follow much of the Macintosh setup steps for configuration and backups. We do not provide automatic installers or configuration/operational support for Linux servers.

    The server only needs to be set up on one machine where you want the database to reside. Theatre Manager can be set up on as many machines as you wish.

    Only install virus software on the PostgreSQL Server under very controlled circumstances and never allow virus scanners to scan the actual Postgres database directories.

    Do not join a domain to limit the people who can see or get into the machine remotely.

    If you are using PCI schedule 'C' compliance, credit card information will never pass through the database and it can effectively be taken out of PCI scope.

    Refer to Postgres security notices for list of security issues addressed in each version.

    Macintosh PostgreSQL Server

    The following instructions are used to set up a Macintosh PostgreSQL server for use with the Theatre Manager application. Click if you are doing Windows setup

    The server needs to be set up on one machine and the application can be set up on as many machines as you wish.

    Follow these steps if you are using the Theatre Manager TMPostgresSetup installer program; you may want to bookmark this page in your browser in case you want to refer to these installation steps. If you are only installing a demo, refer to the last column for required steps.

    task Description Full Install Demo
    1 download the PostgreSQL installer for Mac yes yes
    2 the installation of the PostgreSQL SQL server yes yes
    3 configuration of the server parameters for maximizing performance in a production database yes no
    4 creating a daily backup job in using Cronnix to run the backup yes no
    5 Turn off energy saving, airport and other energy saving features yes no
    6 (Optional) Implement hot database standby server depending on load and other considerations. no no

    Notes and Assumptions:

    • This install process will install or update PostgreSQL. If you are updating across versions, you may need to refer to Updating PostgreSQL Instructions
    • You MUST turn off all virus protection while running the installer (especially Norton if you are using it). Virus software always interferes with proper software installation.
    • If this installer is being used to create a demo installation, then you only really need do steps 1 and 2.

    Step 1: Install PostgreSQL database server

    When you run the installer for the database components, it will put the actual installer files into the Macintosh HD/Users/Shared directory along with all the support files needed for the rest of the steps.

    The actual Postgres install process is part of the install process. If you cancel the setup of Postgres, you can always start it again by repeating the process from the start.

    Installing PostgreSQL on a Macintosh

    Before starting the install, please check that the computer date and timezone settings are correct. Failure to do so may cause Postgres to think it is in a different timezone.
    In recent versions of OSX, you may need to make a temporary change in System Preferences after downloading the installer and before the installer will work. This is because the installer is not digitally signed with Apple.
    1.
    • Double click on the TMPostgresSetup.zip file that you downloaded. It will unzip and create a TMPostgresSetup.pkg file.
    • Double click on the TMPostgresSetup.pkg
    • You will see the introductory 'Splash' screen
    • Click Continue on the splash screen.
    2. Click Continue on the Licence Agreement screen after reading it.

    3. Click Install to begin the actual install.

    4. You will need to enter an administrator user ID and password to continue

    5. You will see the installation progress as the Postgres database engine is installed

    5. When the isntaller is finished successfully, click the Close button

    Step 2: Configure the PostgreSQL server parameters

    When you are able to connect to the database using Theatre Manager, it's time to tune some of the parameters for PostgresSQL that are specific to your machine and setup. On a Mac, this needs to be done with VI under the postgres user account.

    The general steps are:

    • Edit the pg_hba.conf file to indicate which IP addresses may talk to the database server
    • Edit the postgresql.conf file to adjust some memory settings for performance

    PG_HBA.conf file

    What does this file do? This file controls all access by users to the PostgreSQL server.

    In order for clients to connect to the server, their IP address must be in the allowed list of users. The two common authentication methods that you will see being used for Theatre Manager clients are MD5 and trust.

    • MD5 does md5 password authentication and should be used for just about all entries to this file.
    • Trust allows clients to connect without password authentication; the only 'trust' entry should should be for the local server machine and/or localhost.

    1. The first changes to make involve the pg_hba.conf file and the postgres.conf file. To do so, you'll need to use VI (a text editor) and be the postgres user in Terminal. To do this, start Terminal and type

    su - postgres

    enter the password

    2. Go to the postgres data directory by typing

    cd data

    3. Edit the postgres pg_hba.conf file that contains the addresses to listen on. Type

    VI pg_hba.conf

    (full pathname is /Library/Postgresql/[version]/data/pg_hba.conf)

    You should see a page of information. If you do not, then type 'Shift Q' and then just a 'q', after which you can start the process over. If you see the list of text similar to the right, then:

    Use the down arrow on your keyboard to go to the very end of the file.

    4. EditHba

    When you are at the end of the file, use the up arrow on your keyboard so that you are right after the first line in the IPv4 settings, where it says 'host all all 127.0.0.1/32 trust'. In the example the cursor is on the '#' on the line after.

    type the

    I

    key and the message at the bottom will change to Insert.

    5. EditHba

    Edit the pg_hba.conf so that its final settings are similar to the window on the right.

    Type directly into Terminal so the data looks like the window above. Use the Delete key to get rid of characters. You will likely end up typing the following lines where the first one is your subnet. This is the most typical example we've seen at venues

    host all all 192.168.1.0/24 md5

    NOTE: For the 127.0.0.1/32 option, edit the handshaking to be TRUST at the end of the line to allow backups to run unaided.

    NOTE: If your machine uses IPv6 (the new internet IP setting standard), you may also need to set ::1/128 to be TRUST instead of md5. If so, edit that line to look like:

    host all all ::1/128 trust

    NOTE: If you are running version 9.0 or higher of Postgres in a Mac environment the local all all line should be set to TRUST.

    NOTE: You may also need to edit the local all all line from md5 to TRUST. This can be determined if the backup script will not run without a password after changing the settings above for 127.0.0.1 and ::1/128.

    The line you added (or need to add) are for:

    • The local subnet - as in 192.168.9.0/24
    • Other subnets that need to access the data - as in 10.1.5.0/24
    • Any single machines that must have access - as in 55.66.77.88/32 (via VPN)

    At the end of the subnet, the /24 refers to a complete subnet when you want any machine on the subnet to access the database. This is what is used most often.

    The /32 refers to a particular machine. If you use this option, you will need to provide the exact computer IP that you want to allow to access the database.

    6. EditHba

    At the end, type, in this order:

    hit the 'esc' key

    (the insert mode will dissappear)

    Shift Q

    (the window will show the 'Entering Ex mode' message)

    wq

    and the window will clear.

     

    Reference for settings in the pg hba.conf file www.postgresql.org/docs/9.0/interactive/auth-pg-hba-conf.html

    POSTGRESQL.conf file

    The postgresql.conf file contains parameters to help configure and manage performance of the database server. You can use most parameters as installed out of the box, but the server will go much faster if you alter about a half-dozen key settings.

    Note: you can also use pgadmin to make these changes if you prefer.

    1. You will need to start by changing to the postgres user in Terminal. To do this, start Terminal and type

    su - postgres

    enter the password

    2. Go to the Postgres data directory by typing

    cd data

    3.

    This will use VI to edit it. Type

    VI postgresql.conf

    when the list appears, type

    I

    to go into insert mode and use the up and down arrows to find the options below

     

    Find and edit the parameters in the list below and change them to the suggested values, if they are not already set to that value.

    if any line contains a '#' at the beginning and you need to change that line as per the instructions below, make sure to remove the '#' as it uncomments the parameter. If there is no '#', then just change the values.

    For any setting that is about disk space or memory, you can type 1GB, 1000MB, or 1000000KB - they are all equivalent. Do not leave a space between the number and the memory amount at the GB, MB or KB; otherwise, Postgres will not start.

    4.
    bonjour If you wish your Postgres server to be discoverable using Bonjour services so that the Mac version of Theatre Manager can automatically locate a server on the network, this value can be uncommented and changed from off to on

    It will probably look like #bonjour = off. Remove the # from the front of the line (if any) to activate that parameter and change off to on

    max_connections The default is 100 which should be fine for most venues. On venues with a lot of users, you may need to make 150 to allow 20 for the Theatre Manager Server and up to 4 for each concurrent user. If Postgres fails to start following configuration of this parameter, set it back to 100 and attempt to start Postgres again. Generally, do not change this unless you need to.
    shared_buffers This value should be 20-25% of the total system total RAM. You find this value on the task manager as the total physical memory. Enter values as xxMB.
    temp_buffers This value should be 20MB.
    work_mem This value should be 20MB. Enter values as xxMB.
    effective_cache_size This value should be about 75% of AVAILABLE ram. So, on a 4GB system, this value would be 3072MB. Set the shared memory first. Shared memory is part of the effective cache size. If there is enough available ram in the machine, to exceed the size of the database, it means most reads will be cached in memory.
    timezone The timezone parameter is set to match the computer's timezone during the installation of Postgres. If the timezone is incorrect on the computer, you may need to correct the timezone in the config file. Refer to Wikipedia article on time zones (Use the TZ column)
    ssl Change this parameter from off to on to enable encrypted TLS communication with the database. You will need to put a self signed TLS certificate into the data directory by using either the one supplied with the installer, or making your own.

    Reference for postgres.conf file parameters https://www.postgresql.org/docs/current/static/runtime-config.html

    5. Once the changes are made, type, in this order:

    hit the 'esc' key

    (the insert mode will dissappear)

    Shift Q

    (the window will show the 'Entering EX mode' message)

    wq

    and the window will clear and you will be back at terminal

    OSX Self Signed TLS Certificate

    Making your own Self Signed TLS Certificate

    It is generally best to create your own certificate. It takes about 30 seconds to do, and has the advantage that the certificate is unique to your database.

    Start a terminal session, type the following 2 commands, and then follow the instructions as prompted. You can copy/paste the command.

    cd /Users/Shared
    openssl req -newkey rsa:4096 -nodes -keyout server.key -x509 -days 365 -out server.crt

    Answer all the questions you are asked and when done, find the files in the /Users/Shared directory called:

    • server.crt
    • server.key
    Continue to the installation step.

     

    Using a supplied self Signed TLS Certificate

    We have created a 4094 bit TLS certificate and included it with the installer. While it is better to create your own, if you need one fast to get started, you can use ours and create your own later (per the step above).

    Go to the /Users/Shared folder and find the files called:

    • server.crt
    • server.key
    Continue to the installation step.

     

    Installing the server.crt and server.key Files

    You will need to copy the files to the Postgres User directory as the postgres user. Do the following commands in Terminal:

    su - postgres      (and enter the password when asked)
    cd data
    pwd      
    Make sure the results of the pwd command says that the directory is /Library/PostgreSQL/9.x/data where 'x' is the version of postgres you have installed. It if does not, do not go any further. and call for assistance.
    cp /Users/Shared/server.crt server.crt
    cp /Users/Shared/server.key server.key
    chown postgres:daemon server.*
    chmod 600 server.*
    ls -la

    In the listing, the two files should now be in the postgres data directory and all that needs occur is to stop and restart the database.

    pg_ctl stop -m fast
    pg_ctl start
    Once the database is running, start Theatre Manager and go to the window showing employees that are logged in to see that the connection being used is secure.

    Step 3: PostgreSQL server backups

    Once the database is set up, you will need to establish a back up frequency that is appropriate for your venue. Mostly, setting up one backup daily to the backup directory should be enough and let it run late at night.

    However, it is perfectly okay to set up 2 or more daily backups while Theatre Manager is running. You may wish to do this on a high volume site and pick times like 8:00am, 1:30pm and 8:00pm, for example. Backups can run while Theatre Manager is being used.

    Performing a Manual Backup

    You can also do a manual backup at any time by going into Terminal and running the 'backupTM.php' file mentioned in this section, even if Theatre Manager is running. You would do this using Terminal on the server by typing

    php /Users/Shared/backupTM.php

    based on what you had already done to configure the script using the instructions below.

    This backup process only exports data from the database and creates a compressed backup file. You will need to take those backups and copy them to another machine and/or establish a backup rotation and take some offsite.

    Editing the backup script

    1. If you used the installer to place files into the correct location, you can skip to Step 2 in this section. If you did not, then you will need a copy of the backup script files and then:
    1. Create a directory called /Users/Shared/Backups
    2. Get a copy of the file backupTM.php and place them into the /Users/Shared directory
    2. If the files are in the correct place because they were installed by the installer, then we will need to edit the backupTM.php file. Note, if you have multiple databases to backup, make a copy of this file for each database you want to backup and edit accordingly.
    1. Navigate to the /Users/Shared directory and find the 'backupTM.php' file.
    2. Right click on the file and edit with Text Edit
      edit
    3. Change the line
      $backupDB = 'TheatreManagerDemo';
      to be
      $backupDB = 'xxxxxx';
      where xxxxx is the name of the database set up in PostgreSQL. Note that the name of the database is case sensitive and must match what is seen in PGAdmin III, or what s used to log on to the database via Theatre Manager.
    4. If you wish to alter the backup location, change the path mapping in the line that is highlighted. Normally, it is not changed.
      $localFolder = '/Users/Shared/Backups';
      edit2
    5. The backup script can be set to automatically log into a remote FTP site and upload the database right at the end of the backups. If you wish to do that, set the values of $ftpHost, $ftpUser, $ftpPass, and $ftpFolder (if need be). If you do not want to do this, then leave the $ftpHost blank
      Close the batch file and save the changes.
      edit2

    Test the Batch Script

    1. backuprun

    Test the batch file by starting up Terminal and typing the highlighted command
    php /Users/Shared/backupTM.php
    and Terminal should come back with a listing of the files being dumped. If you get errors about access denied, then there are likely issues:

    1. The backupTM.php script needs to have execute permissions. Use file examiner to fix that in Leopard. Get Info should work on OS X 10.4
    2. Make sure that the local user in the pg_hba.conf file has 'trust' access to the database. You might need to enable it for 127.0.0.1/32 and/or ::1/128 if your network uses IPv6
    Once you're done and the Terminal window closes, go to the /Users/Shared/Backups directory and see if there is a recent backup for your database. Note that there should be some size to the database backup. It should not be zero bytes in size. In this sample, we have the two backups of the TheatreManagerDemo. The highlighted one was made on 20080116 at 07:34:49 in the afternoon. There will be a new file here each time the backup is run.

    backuplist

    Creating a Daily Backup Job

    1. Create a timed backup for the database by going to the /applications directory and starting a program called CronniX. A copy was installed by the Postgres Setup program. CronniX is shareware and can be found at www.abstracture.de/projects-en/cronnix

    scheduledTask

    Only do this on the machine that has the database server on it and make sure you are logged on as the administrator.

    2. Double click on the 'CronniX.app' icon (it may or may not have .app at the end). This will start the CronniX Task Scheduler. On a side note, Cronnix is an interface to the Unix CRON facility. CRON has been around for a long time and is one of the task scheduling tools that is built into the Unix operating system. You don't have to worry if it is on your system - it just is.

    addTask

    Click the New icon on the upper left. It will open a new window with a sample script at the bottom that says:

    echo "Happy New Year!"

    Replace this with the same command used to start a backup in the preceding section.

    php /Users/Shared/backupTM.php

    Click on the expert tab and make the settings in the upper half of the screen as per the example. These settings adjust your backup schedule. For example if you want a daily 2am and 2pm backup:

    • minute is on the hour (0)
    • hour is 2am and 2pm (2,14)
    • day of month is anything (*)
    • month is anything (*)
    • day of week is anything (*)

    This will effectively schedule two per day backup of your database and is the recommended backup schedule to setup.

    Entries for any of the items can be like:

    • * means 'always' for any entry. If minute said 10 and hour said *, it would mean every 10 minutes, regardless of hour.
    • 1,4,7,10 means on the 1,4,7, and 10. If this was hour, then there would be 4 backups at that time. If this was day, then only on the 1st of the month, 4th of the month, etc.
    • If you wish to read about more esoteric cron settings, please refer to internet sites by googling for 'cron settings'

    wizard1

    Note: you can schedule backupTM to run as many times as you want during the day by changing the parameters of the one CRON job, or by creating more jobs. Once or twice per day is normally enough but you may feel that more times is better for your backup requirements on busy days.

    3. Click the Button (or the Button if you are editing the existing CronniX command).

    Disable Power Saving Settings on Server

    Additional Setup Considerations

    The following settings should be made on all servers (Postgres, Apache and web listeners) that are installed on Macintosh.

    1 Make sure to
    • turn OFF all energy saving options such as 'Prevent hard disk sleep', 'Do not allow the CPU to go into low processor mode', etc.
    • turn ON 'restart the Mac after a power failure'. We also suggest altering the feature to auto-start the Mac at a time like '6:00am' should it just happen to be powered off. This way, your servers should always be on.
    • enable auto-login on machines with TM Server, and set the machine so that you can lock the screen after inactivity. The classic listeners will halt if not running under a user.
    2 Make sure to turn Airport OFF if the Mac comes with it. Airport will cause the Mac to temporarily freeze while it looks for a network to connect to - and will lock out sales while it does that.

    This is done by opening the control panel, clicking on the Airport interface, and then clicking on the 'gear' at the bottom to select the option 'make service inactive'. Doing this will change the status from 'off' to 'inactive'

    3 Make sure to force the mac mini to use the built in Graphics Processor Unit (GPU) when displaying screen shots instead of CPU. This prevents remote access using up a cpu core to display the screen. You can do one of the following:
    1. physically plug in a monitor to the Mac-or-
    2. connect a KVM switch into it that is powered up. -or
    3. use an attachment like a Headless Video Adapter

    Disconnecting a monitor from the Mac will cause the the computer to unnecessarily waste CPU cycles on display - when it should use the GPU.

    4 Turn off Spotlight Indexing (mdsworker) using Terminal and typing

    sudo mdutil -a -i off

    On Lion, use the following command

    sudo launchctl unload -w /System/Library/LaunchDaemons/com.apple.metadata.mds.plist

    This will prevent the operating system from doing unneccessary work while serving web pages. To recognize if Spotlight is running on a server, look for an 'mds' application running. It can use a lot of CPU resources.

    note: If any mdworker messages are in the console logs (or if mdworker pops up in activity logs), then Spotlight is not turned off.

    5 Using Terminal, disable Time Machine for the database folder (optionally, completely disable and local Time Machine files)

    sudo tmutil addexclusion /Library/PostgreSQL
    sudo tmutil disable
    sudo tmutil disablelocal

    Alternatively, you can disable Time Machine through System Preferences.

    If you must use time machine on the database server, see the next step for options

    6 Do not use Time Machine for the Postgres backups. Use the backup script and move the backups to another machine. If Time Machine must be used on the database server machine:
    • make /Library/Postgresql one of the folders that is ignored by Time Machine.
    • change the backup interval so it is less frequent. 3600 is 1 hour (the default), 43200 is 12 hours. Use terminal and enter the following command.>/li>

    sudo defaults write /System/Library/LaunchDaemons/com.apple.backupd-auto StartInterval -int 43200

    7 Completely turn off any automatic Software Updates in the Mac's System Preferences. This is a database machine and should be manually updated on a periodic basis under controlled circumstances.

    It may be either under 'Software Update' or 'App Store', depending on the version of OS X you have.

    8 Completely disable App Nap on the computer running the Classic Listener using the Terminal command below:

    defaults write NSGlobalDomain NSAppSleepDisabled -bool YES

    9 Update OS X to 10.9.5 (or later) if the current version is between 10.9 and 10.9.4.
    • There have been reports of earlier versions of Mavericks having TCP/IP problems.
    • We have no recommendations on Yosemite 10.01 as a server yet; it's too early to tell.
    10 Disable 'handoff' in general system preferences as well as disconnect from iCloud.

    Hot Standby Server

    One of the features of Postgres is the ability to create a 'hot standby' database server as a way to introduce redundancy to the system. The notion is that if a catastrophic physical failure occurred to the database server (such as the drives died, the machine melted, it got doused in water or burnt in a fire) and was found to be non-recoverable, then it would be best to get to a backup as soon as possible.

    The standard backup approach allows you to go back to a snapshot. If you do a number each day, that may mean going back a few hours and reconstructing what happened from the backup to the failure.

    Replication means you have one (or more) standby servers that is shadowing the contents of the main server - and may be as close as seconds old. In the case of failure, you would turn off the replication feature and start using the standby database until your primary server gets fixed.

    Do not use replication as the only means of backup - always set up snapshot and offsite copies of your database.

    We always recommend using the latest version of PostgreSQL for replication. These instructions were created for PostgreSQL version 9.6.

    If you do a minor level upgrade of PostgreSQL on the main database server (e.g. from PostgreSQL v9.6.x to v9.6.y), you must also upgrade the version of Postgres on the hot standby server at the same time. There is no need to migrate the database again.

    However, if you do a major level revision, you will need to do ALL the steps to re-establish the hot standby. This will change the time it requires to upgrade (but having a hot backup is worth it).

    If you update your version of Theatre Manager, any changes to the data in the main database are also updated on the hot standby. You never have to update the backup server as all changes come from the main server

    The general steps for making a hot standby are:

    Many thanks to this insightful article by Bartek Ciszkowski for helping make the process on Linux which we adapted to OS X. You can also read more detail on the Postgres site regarding high availability servers for any of the technical details.

    Replication can be done on windows per this tutorial and it implies that there are few differences, except how to get the WAL logs replicated from one machine to the other - using a file share.

    Main Postgres Server Changes

    For the purposes of the example, let's assume per the diagram that

    • the main database server is at 192.168.0.5 and
    • the hot standby server is at 192.168.0.10

    Do not restart any of the Postgres servers until told to do so.

    Changes to postgresql.conf

    You can make these changes using PGAdmin ('Tools->Server Configuration') or by using Terminal and VI to navigate to the Data folder and edit the file. This assumes you know how to make these changes. Note that there are ' (quotes) around the RSYNC parameters below. In PGAdmin, you will not need to enter them - in VI, you will need to enter them.

    These settings tell Postgres to send enough information from the master to the slave. You can read about these parameters in the official documentation and adjust them as needed.

    wal_level = hot_standby
    max_wal_senders = 5
    wal_keep_segments = 32

    archive_mode = on
    archive_command = 'rsync -aq %p postgres@192.168.0.10:/Library/PostgreSQL/9.6/archive/%f'
    archive_timeout = 60
    The 'rsync' command has its own requirements to actually make it work. For now, set the IP address of your hot standby in place of 192.168.0.10. The timeout is set to 60 seconds so that, at most, the standby is 60 seconds behind the main database.

    Changes to pg_hba.conf

    Edit the pg_hba.conf file and scroll down to the bottom. There should already be 3 lines that have replication in them which will need to be uncommented and permissions set to 'trust'. Add a line that tells the master server that the 'replication' server is at 192.168.0.10 as per the last line. Replace with the IP address of your hot standby server.

    Ensuring rsync permissions work

    You must to establish secure credentials between the main Postgres server and the standby server to enable rsync to transfer the files using the command above. It requires some Terminal commands and knowing what you are doing. It may be easier to have two Terminal sessions working.

    As Admin User

    ON THE BACKUP SERVER, Open System Preferences and go to the 'Sharing'. Make sure 'Remote Login' is enabled.

    It can be set to all users -or- if you want to limit users, make sure the postgres user is in the list.

    Make the '.ssh' folder and 'archive' folder for the postgres user in the postgres user's home directory /Library/PostgreSQL/9.6 and provide access to it.

    DO THE SAME four commands on the both the MAIN and on the HOT STANDBY server.

    sudo mkdir /Library/PostgreSQL/9.6/.ssh
    sudo chown postgres:daemon /Library/PostgreSQL/9.6/.ssh
    sudo chmod 700 /Library/PostgreSQL/9.6/.ssh
    (only postgres should have rwx access to the .ssh directory)

    sudo mkdir /Library/PostgreSQL/9.6/archive
    sudo chown postgres:daemon /Library/PostgreSQL/9.6/archive

     

    As postgres User ON THE MAIN SERVER, use ssh-keygen to create a key/certificate file for SSH access and move it to the hot standby. Again, we are assuming that the hot standby will be 192.168.0.10 - replace with your hot standby IP address as required.

      su - postgres
    cd /Library/PostgreSQL/9.6/.ssh/
    ssh-keygen -b 1024 -t rsa -f id_rsa -P ''
    (note: the end of the command is two single quotes in a row)
      you should get a response like:

    Generating public/private rsa key pair.
    Your identification has been saved in id_rsa.
    Your public key has been saved in id_rsa.pub.
    The key fingerprint is:
    f4:a6:7b:b5:47:98:a8:b0:5e:5c:c5:92:b0:17:e7:c8 postgres@192.168.0.05
    The key's randomart image is:
    +--[ DSA 1024]----+
    | . . . |
    | + B |
    | o E + |
    | . o o |
    | S +. o |
    | .. +. + . |
    | o+. . o |
    | ..... . . |
    | .. .. . |
    +-----------------+

      touch authorized_keys
    cat id_rsa.pub >> authorized_keys
    chmod 400 id_rsa
    scp authorized_keys postgres@192.168.0.10:/Library/PostgreSQL/9.6/.ssh
      You should get a response as below

    The authenticity of host '192.168.0.10 (192.168.0.10)' can't be established.
    ECDSA key fingerprint is 5f:ac:f0:ec:73:a7:1e:27:45:28:ac:b2:55:b6:a7:db.
    Are you sure you want to continue connecting (yes/no)? yes
    Warning: Permanently added '192.168.0.10' (ECDSA) to the list of known hosts.
    Password: Type your postgres password here
    authorized_keys2 100% 614 0.6KB/s 00:00

    Then type the following to SSH to the remote machine. You should no longer be asked for a password. If you cannot do this, then replication will not work.

      ssh postgres@192.168.0.10
      It should respond with a prompt and you can type
      exit

    If you are not able to connect to the remote machine without typing a password, you may need to do one of:
    • use the -v argument to see why SSH may not be using the authorized key: ssh -v postgres@192.168.0.10
    • change the name of the 'authorized_keys2' file in the .ssh directory to 'authorized_keys' on both machines and try connecting again
    • remove the .ssh directory from both machines and start the ssh-keygen process again -- but do it carefully this time -or-
    • you may need to reset the Postgres password on the remote machine using System Preferences, if you just installed Postgres on that machine.

    Hot Standby Server Configuration

    For the purposes of the example, let's assume that:

    • the main database server is at 192.168.0.5 and
    • the hot standby server is at 192.168.0.10 as per the diagram
    • the version of postgres you are using is 9.6.x (otherwise change 9.6 to 9.x in all commands, depending on the version of postgres you are using)

    Stop the Hot Standby server and do not restart it until told to do so.

    Start Terminal, then sign on as the Postgres user via the following commands to stop the database:

    su - postgres
    pg_ctl stop -m fast
    exit

    Create recovery.conf

    Create a file called 'recovery.conf' (which should not exist) in /Library/PostgreSQL/9.6 for safe keeping. We will be copying this file later on as Postgres expects to find it the 'data' folder in /Library/PostgreSQL/9.6/data. However, we cannot put it there yet as we will be deleting everything in that directory later. Replace 192.168.0.5 with the address of your primary database server.

    Using Terminal as administrator of the machine, create and edit the recovery.conf since the Postgres user cannot create this file. Alternatively, copy the text and paste it into a TextWrangler file on the machine and use a copy command to put it into place.

    As admin User
    sudo vi /Library/PostgreSQL/9.6/recovery.conf

    then enter the contents of the file by typing the yellow text below. (you can usually copy/paste into vi if in 'insert' mode)

    standby_mode = on # enables stand-by readonly mode

    # Connect to master postgres server using postgres user
    primary_conninfo = 'host=192.168.0.5 port=5432 user=postgres'

    # specify the name of a file whose presence should cause streaming replication to
    # end (i.e. failover). If you create this file, then Postgres will rename 'recovery.conf'
    # to 'recovery.done' and promote the hot standby to a primary server without a restart.
    trigger_file = '/tmp/pg_failover_trigger'

    # shell command to execute an archived segment of WAL files
    # required for archive recovery if streaming repliation falls behind too far.

    restore_command = 'cp /Library/PostgreSQL/9.6/archive/%f %p'
    archive_cleanup_command = '/Library/PostgreSQL/9.6/bin/pg_archivecleanup /Library/PostgreSQL/9.6/archive/ %r'

    Make sure that the archive directory exists

    If you did not already do this command as part of the set up of the MASTER database, you will need to do so, so that the backup files can be received by the HOT STANDBY server.

    As admin User

    Make the '.ssh' folder and 'archive' folder for the postgres user in the postgres user's home directory /Library/PostgreSQL/9.6 and provide access to it.

    DO THE SAME two commands on the both the MAIN and on the HOT STANDBY server if you have not previously done so.

    sudo mkdir /Library/PostgreSQL/9.6/archive
    sudo chown postgres:daemon /Library/PostgreSQL/9.6/archive

    If you are re-establishing a hot-backup server, make sure to clear out all files from the 'archive' folder on the hot standby. In Terminal, type:

    cd /Library/PostgreSQL/9.6/archive
    sudo rm -rf *

    You do not need to stop the main server while setting up the hot standby as we will make a base backup to 'restore to a point in time'.

    Migrating the initial database

    This step assumes that you have used the previous steps and configured the main database and the hot standby server prior to beginning with the following steps. Also, for the purposes of the example, let's assume that the main database server is at 192.168.0.5 and the hot standby server is at 192.168.0.10 as per the diagram.

    Hot Standby Server

    Stop the Hot Standby server and do not restart it until told to do so (it should be stopped already). We don't want any data flowing from the main database to the Hot Standby while we are preparing the servers.

    In Terminal, as postgres user:

    pg_ctl stop -m fast

    Main Database Server

    You may need to use pg_ctl to stop and then start the main server to get the max_wal_server change to take effect before starting the pg_basebackup. Make sure nobody is using the database, then type in Terminal, as postgres user:

    pg_ctl stop -m fast
    pg_ctl start

    Now that the hot standby is configured, it’s necessary to get the contents of the main database onto it, so that replication can sync up. This is done using a handy command named pg_basebackup, which essentially copies the entire data directory of your main database into a location of your choice. It is also what we know as an online backup, as the main database can stay in use while the command copies all the data.

     

    On the Main Database Server

    Start the pg_basebackup command and put the backup file in some place that Postgres can access. The standard backup directory /Users/Shared/Backups should be fine. The base backup should take about as long as your normal backups take and progress is shown in the Terminal window.

    Make sure that Postgres has read/write access on both the local machine and the remote machine to the directory you are using.

    The scp command is used to copy the base backup to the same location on the hot standby server (replace 192.168.0.10 with your backup server IP). You could use a USB key or any other mechanism to transfer the file that you want. This may also take a long time and progress is shown in the Terminal window.

    pg_basebackup -U postgres -v -D - -P -Ft | bzip2 > /Users/Shared/Backups/pg_basebackup.tar.bz2


    scp /Users/Shared/Backups/pg_basebackup.tar.bz2 postgres@192.168.0.10:/Users/Shared/Backups

    NOTE: The bzip2 command can be quite CPU intensive and only uses a single core. If a multi-core processor is available you may wish to consider using the pigz compression program instead to get a significant speed-up to the backup. Be aware that using pigz requires separate installation and it also uses a different extension than the bzip2 method: .tar.gz vs. .tar.bz2.

    pg_basebackup -U postgres -v -D - -P -Ft | pigz > /Users/Shared/Backups/pg_basebackup.tar.gz


    scp /Users/Shared/Backups/pg_basebackup.tar.gz postgres@192.168.0.10:/Users/Shared/Backups

     

    On the Hot Standby Server

    The hot standby server should already be stopped. We need to use Terminal (as the postgres user) and remove the entire data directory - if it exists.

    su - postgres
    Enter the Postgres password
    pg_ctl stop -m fast (just to make sure Postgres is stopped on the backup server)
    cd /Library/PostgreSQL/9.6/data
    rm -rf *
    ls
    (There should be no files)
    Then expand the copy of the base backup of the main database that we just copied to the hot standby server
    tar -xjvf /Users/Shared/Backups/pg_basebackup.tar.bz2
    Change the owner of the entire contents of the database directory to be postgres
    chown -R postgres:daemon /Library/PostgreSQL/9.6/data
    Copy the recovery config file that we made earlier
    cp /Library/PostgreSQL/9.6/recovery.conf /Library/PostgreSQL/9.6/data/recovery.conf

     

    Changes to postgresql.conf on the Hot Standby Server

    The expansion of the base backup database from the main server will also restore its postgresql.conf and pg_hba.conf file.

    We now need to adjust them to ensure that they are set to be a hot standby database. You can make these changes using PGAdmin ('Tools->Server Configuration') or by using Terminal and VI to navigate to the Data folder and edit the postgresql.conf file.

    The settings below tell Postgres that it is the slave machine. You can read about these parameters in the official documentation and adjust them as needed.

    hot_standby = on
    wal_level = hot_standby
    max_wal_senders = 5
    wal_keep_segments = 32

    Look for the 'archive' settings that were restored from the base backup and comment them out by putting a '#' in front of the parameter.

    #archive_mode = on
    #archive_command = 'rsync -aq %p postgres@192.168.0.10:/Library/PostgreSQL/9.6/archive/%f'
    #archive_timeout = 60

     

    Changes to pg_hba.conf on the Hot Standby Server

    Edit the pg_hba.conf file and scroll down to the bottom. There should already be 3 lines that have replication in them from the main database. If they are not uncommented, you will need to do so and set permissions to 'trust' (and go back and verify the contents of the same file in the main database).

    Finally, start the database on the hot standby server

    pg_ctl start

     

    Cleanup after Replication is Confirmed to be Working

    Please confirm replication is working before doing the next step to clean up the temporary base backup files.

    The base backup file was created on both the main server and migrated to the hot standby machines. If you have a large database, this file could be sizeable itself and it is best to delete it. On both machines, you can navigate to the /Users/Shared/Backups directory and remove pg_baseBackup.tar.bz2.

    Alternatively: in Terminal you can:

    rm -i /Users/Shared/Backups/pg_basebackup.tar.bz2 (you will be asked to confirm the deletion)

    Verifying that the database is replicating

    There are some simple ways to ensure that the main database is properly replicating to the hot standby. You will need to do most of this observation on the hot standby machine.
    • Observe the Postgres log roll forward the changes
    • Looking at the replication logs to see that they are created and then removed
    • Make some changes to the main database and then using pgAdmin to verify that the changes are in the backup in real time

    Using pgAdmin to see Replication Status

    On the main server, you can run the following query in pgAdmin to look at the state of replication:

    select usename, application_name, client_addr, state, sync_state, sent_location, write_location, flush_location, replay_location from pg_stat_replication

    This should give a row back that says the server is 'streaming'. You can repeat the query and the numbers will change, indicating that replication is proceeding.

    If the query gives no rows back (or some other status), then things may not be set up right, or replication has not yet begun because archive log files are being recovered on the Hot Standby Server.

    Using pgAdmin to Watch Transactions

    Alternatives

    Data replicates from the main server to the Hot Standby immediately. If there is a change to the main database, it should appear in the hot standby immediately after that.

    One way to verify changes is to have the box office sell a ticket to a patron using Theatre Manager. Before the sale, there should be no transaction history for that order; after the sale, there should be some ticket transactions.

    Perform this test daily or weekly to make sure that the database is replicating.

    Occasionally, if you take the standby down for maintenance, it may get a bit behind. In that case, you may not see changes until the archive files have been fully recovered and you may need to look at the standby server's Postgres log files for progress. The archives are created periodically as per the frequency that you set in the archive_timeout parameter)

    Verifying Simultaneous Activity on Both Servers

    Follow these steps to see that data is being migrated:

    1. Start pgAdmin on the main server, point to the main database and start an SQL session
    2. Start pgAdmin on the Hot Standby server, point to the standby database (it is a different IP address) and start an SQL session
    3. On both machines, enter the SQL below into pgAdmin to verify the last 10 transactions

      select * from f_transaction order by t_seq desc limit 10
    4. Log in to Theatre Manager on any workstation (or have anybody sell a ticket)
    5. in pgAdmin on the MAIN database, rerun the SQL above. There should now be a new login transaction or transactions that match the number of tickets sold.
    6. In pgAdmin on the Hot Standby database, rerun the SQL above.
      • There should be the same transactions visible on the hot standby right away.
      • That means the servers have replicated the data.
    7. In Theatre Manager, release the tickets or log out.
    8. in pgAdmin on the MAIN database, rerun the SQL above. There should now be MORE transactions representing your activity.
    9. In pgAdmin on the Hot Standby database, rerun the SQL above.
      • You should see the new transactions on the standby server, meaning the servers have again replicated the data.

    Reviewing Postgres Log File for Replication Entries

    The data is replicating from the Main server to the hot standby periodically, as per the frequency that you set in the archive_timeout parameter. If there is a change to the main database, it should appear in the hot standby very shortly after that.

    You should go to the log files once in a while and ensure that it is replicating and able to see/connect to the other database. After the tail command, you should see that the server entered standby mode and that is connecting to the main server.

    Even after setting up the replication to the hot standby server, you should check this log periodically to make sure it continues to work.

    su - postgres
    Enter the Postgres password
    cd /Library/PostgreSQL/9.6/data/pg_log
    ls -la (to see a list of logs)
    tail -f name-of-most-recent-log-file
    The most recent log file will have today's date in it and the 'tail -f' command will continue to display the changes to the file as they occur.

    The example below shows the startup of the standby server after first being created (or being stopped for a period of time). The log files are consumed and, finally, replication starts. Once replication starts, no further 'restore' messages will appear in the logs -- you can then use the pgAdmin query method to view the status of replication on the main server.

    Inspect the Archive Directory

    The data is replicating from the main server to the hot standby periodically as per the frequency that you set in the archive_timeout parameter. If there is a change to the main database, it should appear in the hot standby very shortly after that.

    You can go to the replication folder and see that new files appear once a minute and old ones go away.

    cd /Library/PostgreSQL/9.6/archive
    ls -la (to see a list of recovery files).
    The file names will be very long with digits in them. The name of them will also increase numerically.
    For example:
    • 000000010000000000000055 will have as the next file 000000010000000000000056 - about 60 seconds later or whatever time period you set in the archive_timeout command
    • Eventually 000000010000000000000055 will disappear as it is processed by the hot standby
    • Generally, on the server, there should be only a few of these files (5 to 10). if there are more, the server may be a little busy. If they do not decrease, replication is not working right or the server is overloaded.
    • and the above will repeat.

    Promoting a Standby to the Main server

    Except for an absolute calamity, there is no reason to promote the hot standby to be the main server. If you need to, the general recovery steps are outlined below. There is only ONE command to do at the backup server to make it the primary server (see bottom half of page).

    1. Shut down, turn off, unplug and/or remove the main server from the network so that it is no longer active
    2. On the backup server, create the failover trigger file using the primary failover methodology (described in detail below):
      sudo touch /tmp/pg_failover_trigger
    3. The hot standby is now your main server.
    4. You may need to change the pg_hba.conf file as required to allow workstations to access the database.

      It is probably okay because it was originally copied from the main server at time of making the standby. You will only need to change the pg_hba.conf file if you added more sub-nets to the main server.

    5. Do all the work necessary to get Theatre Manager clients to point to a new database server by doing one of:
      • Use Theatre Manager to change the IP address of the database you log into -or-
      • Change the IP address of the hot standby to be the same as the Master main server -or-
      • Change the DNS to point to the new IP address, if that's what you use to connect to the server
    6. Log all clients, second generation and classic listeners into the new server IP address
      • Log into the database using Theatre Manager.
      • Quit and restart the Theatre Manager Server
      • Quit and restart any web listeners
    7. Fix the reason that the main server died and plan to set up a new hot backup server

     

    Primary Method to promoting the Backup Server to Main Server

    If your recovery.conf file in the Postgres data directory was set up according to these instructions, it should have a trigger_file parameter and look like the except below.

    # specify the name of a file whose presence should cause streaming replication to
    # end (i.e. failover). If you create this file, then Postgres will rename 'recovery.conf'
    # to 'recovery.done' and promote the hot standby to a primary server without a restart.
    trigger_file = '/tmp/pg_failover_trigger'
    Assuming that the path name of the trigger file is /tmp/pg_failover_trigger, then, in Terminal as an admin user, type
    sudo touch /tmp/pg_failover_trigger
    This will cause Postgres to:
    • Notice the file
    • Finish off the slave process and recover any log files transferred from the main server that still needs recovery
    • Rename the 'recovery.conf' file to 'recovery.done'
    • when that happens, it is now the primary server

    Alternate Method using pg_ctl

    use pg_ctl to promote the server

    su - postgres
    enter the postgres password
    pg_ctl promote

    For more information refer to the postgres fail-over documentation

    Update or Remove PostgreSQL

    If you have already installed the Postgres database engine on your Macintosh server and need to update it, then follow the appropriate update steps. This also indicates when to make a backup after everybody has been locked out of the database.

    Updating Postgres

    Download the latest Postgres installer from the ArtsMan web site. Once you have it, make sure you have done the following steps:

    1. Check the version of Postgres you are running. This is in the 'About Theatre Manager' menu. Look at the bottom left of the 'about Theatre Manager' screen. You will see your database name followed by a number such as (9.4.x) or (9.3.x) etc. Record this version for later.
    2. Log everybody out of Theatre Manager, including
      • Any user at the login window and/or
      • The second generation TM Server and/or
      • Classic web listeners
    3. (optional) If you are worried that staff people might log in to Theatre Manager while the upgrade is happening, use PGAdmin (Tools->Server Configuration menu) to edit the pg_hba.conf file to restrict access and
      • Comment out any access that is allowed from any another IP address - and only allow access from 127.0.0.1. You do this by double clicking on the row containing the IP address and unchecking it.
      • Reload (or restart) the Postgres server configuration to make sure no other user would be able to log in and disrupt the upgrade.
    4. Make sure you have made a backup of the database, using the procedures in the daily backup job process. (only after everybody is logged out).
    5. Once you have confirmed the backup exists and have made another copy of that in a different place (just to be safe), then follow the specific instructions for updating the same version or from an older version as required. Refer back to the version of the database that you recorded in the first step above
    6. After the database has been restored, edit the pg_hba.conf and
      • Uncomment any access that you removed previously
      • Reload (or restart) the Postgres server configuration and make sure others can now log in.
    7. Restart any web services

    Updating the Same Version of Postgres

    These steps are for updating Postgres on a Macintosh OSX server where the version of postgres is at the SAME major revision level as you are currently running. The major revision level is denoted by the first two digits of the postgres version.

    Remember, do not attempt to try this unless you just made a backup of your database. Preferably, you should also have restored that backup on another machine for safety, logged into it using Theatre Manager to prove that you can restore a backup and that it has 100% integrity.

    If you are using Hot Streaming Replication, so MUST stop the replication server FIRST and upgrade the version of postgres on it before doing the main server. If not, you may end up redoing the replication server.

    Always verify that replication is working properly after a postgres update.

    1. Make sure you are running postgres version 9.2 or later.
    2. Refer to downloading the latest Mac Installer for postgres
    3. Make sure you have just made a backup of the databases in the server
    4. use terminal and PG_CTL to 'stop' the database
      a) start terminal
      b) type su - postgres
      c) provide the password
      d) type pg_ctl stop -m immediate

    5. Run the installer which will update and restart an existing PostgreSQL installation.

      Make sure to read the next step before starting the install to decide if you can do an easy install or the custom install.

    6. If you have set up the hot standby server, make sure to
      • stop the hot standby at the same time
      • Only use the custom install to update the MAIN server (which does not install a revised demo database) as per below.

      • Upgrade the Hot Standby to the same version of the database server using the same custom installer.
      • Verify that replication is still working after the upgrade
    7. try log in to Theatre Manager afterwards

    Update Older Version of Postgres

    These steps assist migrating an older version of Postgres to the most recent. The upgrade process involves some extra steps and can be done by Arts Management Support team if you are not comfortable following the steps below.

    Remember, do not attempt to try this unless you just made a backup of your database. Preferably, you should also have restored that backup on another machine for safety, logged into it using Theatre Manager to prove that you can restore a backup and that it has 100% integrity.

    The steps are:

    1. Sign all users out of Theatre Manager and stop all TM Web Services
    2. Make a manual backup of the database using the terminal command php /Users/Shared/backupTM.php (and restore the backup to a 'test' database to ensure it works).
    3. Save the PG_HBA.CONF and the POSTGRESQL.CONF settings unique to this server
    4. Stopping the Postgres server
    5. Removing the old postgres server by running the un-installer found in the /Library/PostgreSQL/x.x directory.
      • This will only uninstall postgres and the services
      • Once complete, you will need to move (or delete) the /Library/PostgreSQL/x.x directory which now should contain only the 'data' folder.
      • The 'data' folder is retained only for temporary safekeeping until you have installed the next version of Postgres and restored your data satisfactorily.
    6. Installing the new postgres server using the Theatre Manager postgres installer for OSX
    7. Reconfiguring the parameters for postgres for PG_HBA.CONF and the POSTGRESQL.CONF
    8. Restoring the main database from the backup
      • Create the new database with the owner 'TheatreManager', and using encoding "UTF8'. If the TheatreManager user is not in the database, contact support right away and do not continue.
      • Restore the backup of the database
    9. setting up the backup job again
    10. If you previously set up the hot standby server, you will need to follow the complete installation steps for and set it up again for the new version of postgres.

    Removing Postgres

    Use the following steps to remove postgres from a macintosh OSX server.
    1. Stop the postgres database using the

      pg_ctl stop -m immediate' command

    2. When the server is stopped, use the un-install program in the /Library/PostgreSQL/x.x directory to get rid of it properly
    3. throw out the entire folder called /Library/PostgreSQL
    4. restart the mac

    Windows PostgreSQL Server

    The following instructions are used to set up a Windows PostGreSQL server for use with the Theatre Manager application. Click if you are doing Mac or Unix setup.

    The server needs to be set up on one machine and the application can be set up on as many machines as you wish.

    Follow these steps if you are using the TheatreManager TM PostGresSetup installer program and you may want to bookmark this page in your browser in case you want to refer to these installation steps. If you are only installing a demo, refer to the last column for required steps.

    task Description Full Install Demo
    1 download the PostGres installer for Windows yes yes
    2 the installation of the PostGreSQL server. Please make sure to read any caveats for the version of Windows you are using. yes yes
    3 installing the demo database and the main Theatre Manager User optional  
    4 configuration of the server parameters for maximizing performance in a production database yes  
    5 creating a daily backup job in Windows Task Scheduler to run the backup yes  
    6 Considerations for installing virus protection on the Postgresql server - please do not include the posrgres data folder. yes  
    7 Turn off Microsoft disk indexing on the volume that the database is running on. yes  
    8 Turn off Microsoft Auto Updates on the database server so that it will not restart in the middle of sales. Applying Microsoft patches and updates should be done on a planned basis -- perhaps bi weekly or monthly as a practice (or immediately if there is a current threat) yes  

    Notes and Assumptions:

    • This install process assumes you have NEVER installed PostGreSQL or Theatre Manager on your computer before. If you have, you may need to refer to Updating PostGreSQL Instructions
    • You MUST turn all virus protection while running the installer (especially Norton if you are using it). Virus software always interferes with proper software installation.
    • If this installer is being used to create a demo installation, then you only really need do steps 1, 2 and 3.
    • This process assumes that you have never installed Theatre Manager or PostGreSQL on your machine. If you have already installed PostGreSQL:
      • you will be asked if you want to un-install PostGreSQL (you may want to do that and then try to re-install after)
      • you may need to remove the 'postgres' user from your computer if one exists, unless you know the password for the use.

    Step 1: Install PostGres Database Server

    Caution: Please read to see if this applies to your installation:

    All Versions of Windows

    DO NOT set up the postgres database server to also act as ACTIVE DIRECTORY or as a DOMAIN CONTROLLER.

    While it is possible to do so, the reasons not to are:

    • It is part of PCI DSS standard 2.2.1
    • You get better performance
    • More importantly, you obtain better safety/security leaving it a stand alone machine nobody logs into or connects to unless they physically visit the machine.
    • Updating the database server requires logging in as LOCAL admin anyway.

    We DO NOT recommend that the database server JOIN a windows DOMAIN CONTROLLER either. There is no need for it.

    If you wish join a domain controller, please leave the database server login window pointing to the local machine (instead of the domain). It makes a user logging on for support and updates easier. Note that the machine should always be locked so sign in is required - per PCI compliance.

    We DO NOT recommend installing virus software on the postgres database server. Since access to the server is under very controlled access via port 5432 from the Theatre Manager application only, it should not be required.

    If you must install virus software on the database machine, set it to scan the machine daily. Avoid the Postgres DB files.

    Additional Notes for Specific Versions of Windows

    Windows Small Business Server For Windows Small Business Server, you MUST turn off 'disk quota management' for all users prior to installing PostGres (and leave it off). Otherwise you may run out of space for the installer and any databases that get installed.
    VISTA, Windows 7 or later For VISTA/Windows 7/8, you may need to turn off UAC (user access control) if it is acting as a server. You can run Theatre Manager on other workstations with UAC on.
    Windows 2003 With Windows 2003 server, you will need to be a local administrator to install Postgres. Since postgres v9.3, in some cases, you may need to:
    • Run the postgres installer
    • Manually set permissions on the data folder to everyone, all access
    • re-run the postgres installer

    Note: Microsoft stopped supporting XP on April 8, 2014

    Run Main TMPostgresSetup Installer

    When you run the installer for the database, accept all the defaults.

    Click OK Right click on the TMPostgresSetup.exe application and use Run As to begin the install. Select a LOCAL administrator as the user ID to use for the install.

    If a checkbox that implies "Protect My Computer" or "Run with Restrictions" is available and enabled, uncheck the box to allow the installer to run with full install privileges.

    Click Next
    Click Next
    Click Next
    Click Yes At the end of the TM PostGres installer, you are asked if you want to install the PostGreSQL database in the dialog (as in below).

    If you say yes, postgres will install automatically for you and you can SKIP the next section describing how to install it manually and proceed to the step where the installer asks about installing a demo database

    Alternatively, you can install them later manually by:

    Run Postgres Installer

    Do not do this step if you elected to let the Theatre Manager Postgres installer automatically install Postgres for you.

    Only reference these instructions if you are running the actual Postgres installer from the Postgres web site manually.

    Accept all the defaults on the screens that follow except the last one that references 'stackbuilder'.

    Before starting the install, please check that the computer date and timezone settings are correct. Failure to do so may cause postgres to think it is in a different timezone.
    Click Next
    Click Next

    To install PostGres on another drive instead of the C: drive, click the Browse button and select another drive.

    • If you change this location, you must also change the backupTM.bat files later to refer to the other drive.
    • If you changed the install location to D:\BoxOffice, this would have already changed for you in this window

    Be aware that the standard install location ignores the 32 or 64 bit version of the operating system.

    you should always install to C:\Program Files\PostgeSQL\
    Click Next

    Enter a hardened ' Account Password' for the postgres user. If you do not supply one, we will generate one automatically. However, if this is a demo. In that case, please pick a user password that you remember - we suggest 'Master'.

    For a purchased version of Theatre Manager, this will be set up for you by your trainer who will use a specific AMS password for this server that should not be changed.

    Click Next

    Leave the Port Number as 5432 (if you change the standard port, you will also have to change it in Theatre Manager login window)

    Click Next

    Leave both these settings as shown.

    Click Next
    Click Next

    You will need to wait for a bit while the database server is installed

    Click Finish

    Uncheck the 'Launch Stackbuilder at Exit' setting. There are no additional modules to install into your database at this time.

    At this time, the database should have installed successfully and should be runnning.

    Load Demo Database

    You will be given an option to install a demo database. If you would like to do this, click 'Yes'. It is recommended that you do.
    Click Yes
    Wait

    Wait while a DOS window pops up and shows the progress of the demo database being imported. Depending on the performance and RAM in your machine, this could take a few minutes to finish.

      When the DOS window closes, the database server is installed, and the TheatreManagerDemo database is imported.

    Step 2: Create user and import Database

    Only perform this step if you did not install the demo database when installing server.

    After the database server is installed, You need to create a specific user called TheatreManager and give them privileges. You also want to import a demo database. This step assumes that you have installed into C:\BoxOffice. If you did not, then you will need to edit the .bat files and do this step manually.

    1. Go to C:\BoxOffice directory. You will see some files and folders with names similar to below.

    2. Double click on the 'ImportDemo' bat file. This starts a DOS prompt and start the bat file running.

    If the server is 64 bit, you will need to change the ImportDemo.bat' file to refer to C:\Program Files (x86).

    If you have altered the install directory, you will need to change the path name to point to the location that Postgres was installed in. Often, this is just changing the drive letter.

    3. You are asked for the password to create the 'TheatreManager' user. Type the password you used for the installation of the database in the preceding section. If this is a demo database install, this may have been 'master' you used when installing the server.

    The password is not be echoed back to you and you will not see the cursor move. There is no visual feedback that even a character was typed. You'll just have to get it right. If any of the steps are not right, you can start at the top of this step at any time.

    import2

    4. You are asked for the password to create a 'TheatreManagerDemo' database. Type the same password used above and elsewhere in the install instructions.

    import3

    5. You are asked again for the password to import data into the TheatreManagerDemo database. Type the same password again and you will see a lot of lines displayed to you after that point as the demo database is imported.

    step4

    Step 3: Configure PostGreSQL server parameters

    When you are able to connect to the database using Theatre Manager, its time to tune some of the parameters for PostGresSQL that are specific to your machine and setup.
    1.

    Start the PG Admin III database management application. This is found using Start Menu->Programs->PostGresSQL-> PG Admin III.

    PGAdmin

    If you get any helpful tips, click 'close' to get rid of them.

    2.

    Click on the server for this machine and login. Use the password you created when installing the database server

    Double Click on the server name as per the diagram to the right Server

    Type in the same password that has been used elsewhere in the install instructions. For demo database, the suggestion was 'master'.

    For production databases, this wll be different.

    Then click 'ok'

    password

    You should see a list of objects in the server.

    On the 'Databases' line, there should be (2) if you have imported the database or created your own database.

     

    Database
    3. Click on the Databases line to begin the next step of configuration.
    4.

    edit the pg_hba.conf file.

    Go to the Tools menu and pick Server Configuration->pg_hba.conf file. hbaconf

    Edit the pg_hba.conf so that its final settings are similar to the list below below (see *** a few lines down).

    edithba
    The procedure for editing is done by double clicking on an empty line and typing in the proper values for your venue - one line at a time. Make sure that:

    • Enabled is checked
    • Type is 'host'
    • Database is 'all'
    • User is 'all'
    • IP Address is described as below. You will need at least the local subnet four your network. This example shows the entry for the 192.168.0 subnet
    • Method is md5 - this is the handshaking/encryption scheme used by the clients to talk to the server.
    • NOTE: for the 127.0.0.1/32 option, set the handshaking to be TRUST to allow backups to run unaided.
    • NOTE: on Windows Vista and/or if the machine uses IPv6 (the new internet IP setting standard), you may also need to set ::1/128 to also be TRUST

     

    Add lines for:

    • The local subnet - as in 192.168.9.0/24
    • Other subnets that need to access the data - as in 10.1.5.0/24
    • Any single machines that must have access - as in 55.66.77.88/32 (via VPN)

    At the end of the subnet, the /24 refers to a complete subnet when you want any machine on the subnet to access the database. This is what is used most often.

    The /32 refers to a particular machine. If you use this option, you will need to provide the exact computer IP that you want to allow to access the database.

    *** At the end, the final hba file should look similar to the list at the right. It may have more lines in it for larger venues with multiple subnets or for remote computer access.

     

     

    finalhba
    Once the changes are made, click the Save icon to save the changes. Then on the main menu, select File >> Reload Server. Reload
    You will be asked to confirm that the changes. Click Yes. Confirm

    Click the close box and you will be asked if you want to save your changes.

    Click Yes.

     
    5.

    Edit the postgesql.conf file

    Go to the Tools menu and pick Server Configuration-> postgreSQL.conf file. postgresconf

    You will then see a list of properties of the database server that can be configured.

    list

    Unfortunately, they are not in alphabetical order, so you may need to scroll up and down to find the ones that are in the list below. We've tried to put them in the order that you will find them in the config file. (see *****)

    Do not change any parameters other than the suggested ones, or unless you have been advised to do so by an expert in PostGres databases.

    For any setting that is about disk space or memory, you can type 1GB, 1000MB, 1000000KB and they are the equivalent. Do not leave a space between the number and the memory amount at the GB, MB or KB otherwise postgres will not start.

    To edit any one of the lines, scroll to find it and then double click on it.

    editBuf

    Most of the parameters will tell you something about them. The key values to edit are:

    • The 'Enabled' flag. If you want to turn a parameter on, then click enabled
    • Value - is what you want to set the parameter to. There are specific values for some of the parameters as described in the table below
    • Comment - this may exist as a description of what the parameter is.

     

    ***** Find and edit the parameters in the list to the right and change them to the suggested values, if they are not already set to that value.

    listen_addresses This value should always = '*'

    It will probably look like #Listen_address = 'localhost'. Remove the # from the front of the line (if any) to activate that parameter and change 'localhost' to '*'

    max_connections The default is 100 which should be fine for most venues. In rare cases, venues with a lot of users may need to allow 150 connections. If Postgres fails to start following configuration of this parameter, set it back to 100 and attempt to start Postgres again. Generally, do not change this unless you need to.
    maintenance_work_mem This value should be 50MB for machines with 1 GB of RAM or more and 20MB for those with less. Enter values as xxMB.
    shared_buffers This value should be 20-25% of the total system total RAM. You find this value on the task manager as the total phyiscal memory. Enter values as xxMB.
    temp_buffers This value should be 20MB.
    work_mem This value should be 20MB. Enter values as xxMB.
    effective_cache_size This value should be about 75% of AVAILABLE ram. So on a 4GB system, perhaps 3072MB on a larger system. Set the Shared memory first. Shared memory is part of the effective cache size. If there is enough available ram in the machine, to exceed the size of the database, it means most reads will be cached in memory.
    timezone The timezone parameter is set to match the computers timezone during the installation of postgres. so, if the timezone is incorrect on the computer, you may need to correct the timezone in the config file. Refer to wikipedia article on time zones (Use the TZ column)
    ssl Change this parameter from off to on to enable encrypted TLS communication with the database. You will need to take 30 seconds and put a self signed TLS certificate into the data directory by using either the one supplied with the installer, or making your own.

    Reference for postgres.conf file parameters https://www.postgresql.org/docs/current/static/runtime-config.html

     

    Note: the best place to get memory values is from the 'Activity Monitor' on the 'Task Manager'. See an example below for what this screen looks like.

    To find it, right click on the task bar and pick 'Task Manager'.

    taskManager
    Once the changes are made, go to the 'File' menu and pick 'Reload Server' (alternatively, use the green arrow on the toolbar that is the 3rd icon from the right).

    You will be asked to confirm the changes.

    Windows Self Signed TLS Certificate

    Making your own Self Signed TLS Certificate

    It is generally best to create your own certificate. It takes about 30 seconds to do, and has the advantage that the certificate is unique to your database.

    Start a CMD prompt, type the following 3 commands, and then follow the instructions as prompted. You can copy/paste the commands.

    cd C:\OpenSSL-Win32
    cd bin
    openssl req -newkey rsa:4096 -nodes -keyout server.key -x509 -days 365 -out server.crt

    Answer all the questions you are asked and when done, find the files in the C:\OpenSSL-Win32\bin directory called:

    • server.crt
    • server.key
    Continue to the installation step.

     

    Using a supplied self Signed TLS Certificate

    We have created a 4094 bit TLS certificate and included it with the installer. While it is better to create your own, if you need one fast to get started, you can use ours and create your own later (per the step above).

    Go to the c:\BoxOffice folder and find the files called:

    • server.crt
    • server.key
    Continue to the installation step.

     

    Installing the server.crt and server.key Files

    1. Select both the server.crt and server.key files and right-click to COPY them
    2. Navigate to the postgres data directory which is C:\Program FIles\Postgres\9.x\data
    3. Right-Click and PASTE them into the data directory
    4. You will need to restart the Postgres server for the changes to take effect
    Once the database is running, start Theatre Manager and go to the window showing employees that are logged in to see that the connection being used is secure.

    Step 4: Database Backups

    Once the database is set up, you will need to establish a back up frequency that is appropriate for your venue. Mostly, setting up one backup daily to the backup directory should be enough and let it run late at night.

    However, it is perfectly ok to repeat the steps below and set up 2 or more backups daily while Theatre Manager is running. You may wish to do this on a high volume site and pick times like 8:00am, 1:30pm and 8:00 pm, for example. Backups can run while Theatre Manager is being used.

    Manual Backup

    You can also do a manual backup at any time by double clicking on the 'BackupTM.bat' file mentioned in this section - again, even if Theatre Manager is running. It is generally found in the C:\BoxOffice folder, although it may be on another drive on the database server. The location of this file is where you placed it using the instructions on the rest of this page.

    This backup process only exports data from the database and creates a compressed backup file. You will need to take those backups and copy them to another machine and/or establish a backup rotation and take some offsite.

    1.

    If you used the installer to place files into the correct location, you can skip to step 2 in this section. If you did not, then you will need a copy of two files and then:

    1. Create a directory called C:\BoxOffice (or on D: or E: .. as appropriate)
    2. Create a directory called C:\BoxOffice\Backups (or on D: etc.)
    3. Get a copy of the files backupTM.bat and realdate an place them into the C:\Boxoffice directory (or D: etc.)
    2.

    If the files are in the correct place, then we will need to edit the BackupTM.bat file. Note, if you have multiple databases to backup, make a one copy of this file for each database you want to backup and edit accordingly.

    Navigate to the C:\BoxOffice directory and find the 'BackupTM.bat file.

    backupbat
    Right click on the file and edit with WordPad or NotePad. edit

    change the line

    set DATABASE_NAME=TheatreManager
    to be
    set DATABASE_NAME=xxxxx

    where xxxxx is the name of the customer database set up in postgres.

    Note that the name of the database is case sensitive and must match what is seen in PGAdmin III, or what you used to log on to the database.

    If you altered the install location of Postgres or the box office directory, change the drive mappings in the two lines that are highlighted. edit2

    Set POSTGRESQL_PATH=C: ..... to D:
    set BOXOFFICE_DIR=C:\ .... to D: etc

    normally, these are not changed

    Close the batch file and save the changes.  
    3.

    BackupTM.bat uses robocopy to make a month-end copy to a separate directory. This is part of windows 7 and up. If you are using server 2003, you can Download Windows Resource Kit Tools for Server 2003 to get robocopy.

    Test the batch file by double clicking on the TMBackup.bat to see that it runs. You may be asked for a password. if so, enter it and you should see a bunch of feedback as the database is backed up. If you do have to enter a password, refer to #4 (below)

    backuprun

    When done and the DOS window closes, go to the C:\BoxOffice\Backups directory and see if there is a recent backup for your database. Note that there shold be some size to the database backup.. is should not be zero bytes. In this sample, we have the original demo and a backup made on 20070913 at 12:40:04 in the afternoon. There will be a new file here each time the backup is run.

    backuplist

    4

    If you entered a password to make the backups run, then you need to tell the postgres to allow 'Trust' permissions for the local machine so that backups will run un-aided.

    On XP, you may just need to provide trust access to 127.0.0.1/32. On Vista, you may need to provide 'trust' access to ::1/128 as well. Refer to the section on editing the pg_hba.conf. file

    Creating a Daily backup Job

    1.

    Create a timed backup for the database by going to Start->Settings->Control Panels->Scheduled Tasks.

    Only do this on the machine that has the database server on it.

    If you are using vista or do not have a 'classic' view of the task scheduler, then you may wish to change the control panel view to 'classic' mode. Somehow, this just seems easier to find things.

    scheduledTask

    2.

    Double click on the Scheduled Task icon to begin the setup process

    Click the 'Add Scheduled Task' icon.

    This will start the Scheduled Task Wizard.

    addTask
    Click Next wizard1
    On the list of applications, click the 'Browse' button. wizard2

    On the 'Select Program to Schedule' dialog, navigate to the C:\BoxOffice folder and click on the 'BackupTM' icon.

    Then click 'Open'

    PickApplicaiton

    You will then have the ability to pick a frequency for the backup.

    Daily is suggested, then click 'Next'

    Scheduel

    Pick the time that you want the backup to run. 2:00 am is as good a time as any.

    Then Click Next

    RunTime

    Enter the password for the administrator of the machine. Note that this is not the same as the password for the postgres user

    Then Click Next

    RunTime

    Click 'Finish' to save the job. There is no need to go to the advanced properties.

    RunTime
    Run with highest Privileges. If the task is created in Windows 7 or Windows Server 2008 the Wizard will be slightly different. When creating the Schedule Task on these platforms the option for Run With Highest Privileges must be checked to ensure the database is updated with the backup size and the vacuum process runs.

    RunTime

    If you want a log If you would like to have the output of the backup file from the task scheduler go to a log file, then you can set the command to be:

    cmd /c C:\Backups\backupTM.bat > c:\backupLog.txt

    you can schedule backupTM to run as many times as you want during the day by creating more jobs.

    Once is normally enough but you may feel that more times is better for your backup requirements.

    Postgres User Password

    Postgres is installed using a secure password for the 'service' user under windows. It may be changed by the venue if they wish and if you do so, then you may need to:
    • Find the local 'postgres' user on the computer using the Windows Administrative tools an edit the user id. You can change the password the way you would normally change the password for any other user (and is dependant on your version of windows)
    • If you change the service password, then you must also open the 'services' control panel and find the postgres service. Change the password there as well. To confirm that you got it right, please stop and start the postgres server. if it stops and starts, its safe to bet that the server will restart on the next reboot of the server.
    • Normally, the backups are set to run as administrator using the task scheduler. However, if you altered them to run as the 'Postgres' user, then please change the password under the task scheduler as well - other wise you'll get messages that backups are not running.

    Increasing Windows Performance

    Postgres MUST be on a stand alone server so that it can be left alone to do its job. If this is possible, then the only thing that needs to talk to it is Theatre Manager clients through port 5432. Under that scenario:

    On Windows machines:

    • Enable Windows Firewall to allow incoming on port 5432 for the database and turn off other non-essential ports. Alternatively, make sure that your IT personnel have opened the correct ports through the firewall between computers as per these firewall/router rules.
    • Turn off auto-updates completely

      These are something to be done manually and on a periodic scheduled basis. You do not want servers restarting in the middle of the night, nor do you want downloading to affect performance of your servers.

      Windows Automatic Updates is now found in Services in Windows 10.

    • Turn off microsoft indexing for all directories and sub directories. by looking at the properties of the drive that database is running on
    • Disable any disk quota management on the disk drive
    • turn off any virus scanning for ports and data directories used by postgres

      NOTE: if using windows 10 pro, you need to permanently disable windows defender using one of the methods in the link. In win 10 Pro, use gpedit.msc to disable by group policy editor since windows 10 turns it back on later if you only temporarily disable it (Another stupid idea form Microsoft)

    • Note: turn off any virus scanning against the database directory which is usually

      C:\Program Files\PostgreSQL
      or
      D:\Program Files\PostgreSQL (if there are two drives)

    • Do not install active directory or join it to a domain. Only local access is required to this machine
    • Turn off file sharing or any means that might allow a file to be added to the machine, other than via the postgres engine
    • turn off any energy saving options
    • do not use the machine for saving snapshots of files by turning off 'use shadow copies' on the appropriate drives. (This is set in the properties of the drive)
    • set best performance options to maximize background performances.

    Leaving any of those on will affect performance of the server for the database

    Disable Defragmentation

    Why Microsoft Windows turns on defragmentation by default, we don't know, but its not necessarily good for servers. It is particularly terrible if you have Solid State Drives as it affects the longevity of the device by interfering with the drive's wear leveling algorithms. We suggest turning it off from being automatic.

    • Click on the drive containing the database server
    • Right click to get properties
    • Click on the Tools tab
    • Click on the 'optimize' button
    • Look at the bottom to see if optimization is on (or off)
      • The button to turn it on and off is on the lower right
      • The current state is on the lower left

    Disable Download of Updates and Auto Updating

    For most versions of windows servers, you want to do controlled update so that you can pick the time of outage. We recommend using the sever versions of WIndows as they behave as you expect (so far). Windows 10 has a mind of its own and may need some special treatment.

    Windows Automatic Updates is now found in Services in Windows 10.

    How to locate:

    • Open Control Panel and Administrative Tools
    • Select Services
    • In the Services window, scroll down to Windows Update and turn off the process.To turn it off, right-click on the process, click on Properties and select Disabled.
    • Note: windows 10 sometimes listens to you, most times it does not, despite what you indicate in various settings and you may have to:

    Disable power saving on ethernet

    For watever reason, Windows (out of the box) tends to be set to maximum power-saving which includes setting your network connection to go to sleep when it can:
    • especially on workstations, and
    • especially if you go take an extended coffee break or have a meeting.
    This is not the best setting for any application, like Theatre Manager, QuickBooks or other accounting software that needs to connect to a database on a server.

    We suggest disabling power management on the ethernet card.

    • use instructions like this for windows 7 and 8
    • Use instructions below for Windows 10 (they are very similar to windows 7)
      • Open Control Panel
      • select network and Internet
      • Pick Network Connections. the screen should look like below
      • click the network card
      • right click and show properties
      • click configure

      • click power management and uncheck the highlighted item per the image below

    In addition, please make sure to disable power management except for monitors.

    Making Windows Defender Manageable

    Windows defender can prevent Theatre Manager auto updates from occurring in Windows 10. It can be addressed by:
    • Having windows defender permit access to all theatre manager folders on that machine -or-
    • Turning the Defender policy off -or-
    • Installing some other AV software that disables Defender and takes over -or-
    • Using 2012R2 serve for server processes instead of Windows 10. 2012R2 server does as you ask, windows 10 does not

    Setting a Custom Power Plan

    Make sure to also turn off power saving on your ethernet card on all servers and workstations.

    Create a custom Power Plan

    1. Open the control panel.
    2. Click Power Options.
    3. Click the Create a Power Plan option
    4. Select the bullet next to "High Performance"


    5. Click Next.
    6. Change the Display setting to "Never"


    7. Click Create.

    Turning Off Indexing

    1. Double-click on My Computer (or Computer).
    2. Right-click on C: drive (or the drive letter that Postgres is installed under).
    3. Select Properties from the popup context menu.
    4. Click the General tab.
    5. Remove the check in the "Allow files on this drive to have contents indexed in addition to file properties" box.

    6. Click Apply.

      It may take several minutes for Indexing to complete. If a message pops up indicating Administrator permissions are required click Ok. If the current user is not the Administrator a prompt for the Administrator password will appear. Enter the password and continue. If a prompt appears indicating select folders cannot be altered it may be they are already open. Click Ignore All and let the process continue.

    7. Click OK.
    8. Reboot the computer.

    Repeat this setting on the Web Listener computer, and the Apache server as well

    Turning Off Disk Quota Management

    1. Double-click on My Computer (or Computer).
    2. Right-click on C: drive (or the drive letter that Postgres is installed under).
    3. Select Properties from the popup context menu.
    4. Click the Quota tab.
    5. Remove the check in the "Enable quota management" box.

    6. Click Apply.
    7. Click OK.
    8. Reboot the computer.

    Turning Off Windows Previous Versions

    To check if the setting is turned on:

    • Double-click on My Computer (or Computer).
    • Right-click on C: drive (or the drive letter that Postgres is installed under).
    • Select Properties from the popup context menu.
    • Click the Previous Versions tab.

    If Folder Versions reads "There are no previous versions available" this option is turned off. However, if backups are listed with date and time stamps, the feature is enabled and needs to be turned off.

    1. Click Start >> Control Panel.
    2. Click System in the Control Panel window.
    3. Click System Protection in the left column.

    4. Select the drive Postgres is installed on.
    5. Click the Configure button.
    6. Move the bullet to "Turn off system protection".

    7. Click Apply.
    8. Click OK.
    9. Reboot the computer.

    Setting Best Performance Options

    1. Right-click on My Computer (or Computer).
    2. Select Properties from the popup context menu.
    3. Double-click on System Properties in the left column.
    4. Select the Advanced tab.
    5. Move the bullet to "Adjust for best performance".

    6. Click Apply.
    7. Click OK.
    8. Reboot the computer.

    Turning Off UAC for Windows

    1. Open the control panel.
    2. Click User Accounts.
    3. Click the Change Users Account Control Settings link under Action Center
    4. Move the slider down to Never notify.
    5. Click Ok.

    Update or Remove PostGreSQL

    If you have already installed the Postgres database engine on your Windows server and need to update it, then follow the appropriate update steps. This also indicates when to make a backup after everybody has been locked out of the database.

    Updating Postgres

    Download the latest postgres installer from the Artsman web site. Once you have it, make sure you have done the following steps:

    1. Check the version of postgres you are running. This is in the 'About Theatre Manager' menu. Look at the bottom left of the 'about Theatre Manager' screen. You will see your database name followed by a number such as (9.4.x) or (9.3.x) etc. Record this version for later.
    2. Log everybody out of Theatre Manager, including
      • Any user at the login window and/or
      • The second generation TM Server and/or
      • Classic web listeners
    3. Edit the pg_hba.conf file to restrict access and
      • Comment out any access that is allowed from any another IP address - and only allow access from 127.0.0.1
      • Reload (or restart) the postgres server configuration to make sure no other user would be able to log in and disrupt the upgrade.
    4. Make sure you have made a backup of the database, using the procedures in the daily backup job process after everybody has been locked out.
    5. Once you have confirmed the backup exists and have made another copy of that in a different place (just to be safe), then follow the specific instructions for updating the same version or from an older version as required. Refer back to the version of the database that you recorded in the first step above
    6. After the database has been restored, edit the pg_hba.conf and
      • Un comment any access that you removed previously
      • Reload (or restart) the postgres server configuration and make sure others can now log in.
    7. Restart any web services

    Updating the Same Version of Postgres

    These steps are for updating Postgres on a Windows server where the version of postgres is at the SAME major revision level as you are currently running. The major revision level is denoted by the first two digits of the postgres version.

    Remember, do not attempt to try this unless you just made a backup of your database. Preferably, you should also have restored that backup on another machine for safety, logged into it using Theatre Manager to prove that you can restore a backup and that it has 100% integrity.

    1. Make sure you are running postgres version 9.2.0 or later.
    2. Refer to the overall instructions to download the latest TMPostGresSetup installer.
    3. run the TMPostGresSetup installer.
      1. This will place all the install files into the C:\BoxOffice folder.
      2. Do not install the latest version when asked by the installer
      3. Let the installer complete and quit out of it.
    4. Go to C:/BoxOffice and find the latest version of postgres.
      • It will have a file with a name similar to the one below - with a different version number on it reflecting the latest one.
      • As of March 2013, the current shipping version will be 'Postgresql-9.2.3-1' or later.
    5. Double click on it.
    6. It will start up the installer and default most of the settings based on the existing installation.
    7. Follow the instructions and you will generally only need to use the 'next' key to continue (a few times) until the upgrade (or install) begins.
    8. At the end you will need to restart the server.
    9. Check that you can log in to Theatre Manager from the serer or any workstation.
      1. If the Postgres Service did not start, make sure that the Postgres User password (system settings or active directory) is the same as the password for the Postgres Service in the services panel
      2. If Postgres did startup, you are done.

    Updating Older Version of Postges

    These steps will assist you upgrading Postgres on Windows that has an older major version number of Postgres to the most recent version. The major version number is denoted by the first two digits.

    If you have postgres 9.4.x (or older), the upgrade process involves some extra steps and can be done by Arts Management Support team if you are not comfortable following the steps below.

    Remember, do not attempt to try this unless you just made a backup of your database. Preferably, you should also have restored that backup on another machine for safety, logged into it using Theatre Manager to prove that you can restore a backup and that it has 100% integrity.

    Upgrading older Versions of Postgres

    1. Make sure that nobody is using Theatre Manager and that all second generation servers and classic web listeners are shut down
    2. Making a manual backup of the database using the DOS bat file C:\BoxOffice\BackupTM.bat and restoring it to a dummy database to make sure the backup will restore.
    3. Recording the PG_HBA.CONF and POSTGRESQL.CONF settings unique to this server
    4. stopping the server using the 'services' control panel.
    5. Un-installing Postgres by:
      • going to Control Panel and
      • looking for 'Add or Remove Programs' (XP) or 'Programs and Features' (or whatever Microsoft changed it to in the version of windows you have)
      • Finding the installed version of Postgres that you have and 'uninstalling it'
    6. Deleting the old postgres server data directories. These will generally be in C:\Program Files\Postgres or C:\Program Files (X86)\Postgres - depending on if you have 32 or 64 bit versions.
    7. Use the download steps to obtain the latest version of the Postgres installer from the ArtsMan site.
    8. Changing the configuration parameters in PG_HBA.CONF and POSTGRESQL.CONF per the standard install instructions or you can match those that your recorded from the prior version's config files if you optimized anything. Note, you cannot simply copy the older versions of both files in the new install of postgres as parameters are sometimes added or removed.
    9. Restoring the old database by
      • Creating a new database on the server that matches its prior name. (eg, if it was called 'MyTheatreDB', call it the same name.)
      • Setting the owner to 'TheatreManager' and the Encoding to 'UTF8' (which is the default in all current versions of postgres)
      • Importing the backup of the database made at the beginning of the instructions into the new database server.
      • Starting Theatre Manager and attempting to log in. (if you cannot, make sure that the pg_hba.conf is correct)
    10. Setting up the backup job again and verifying that it works. Verifying it works means that you actually run it under the task scheduler and ensure that the backup file sizes are as expected.

    Removing Postgres from Windows

    Postgres can be removed buy un-installing it and then removing the data directory.

    1. Preferred Method:
      1. Go to Setup->Settings->Control Panel->Add/Remove Programs
      2. Find the line that refers to your Postgres installation
      3. Use the remove option
      4. Delete the C:\Program Files\PostgreSQL folder to remove your database. (Note: it could be on another drive)
    2. Secondary Method:
      1. Run the PostGres installer and 'uninstall' the database first, and then run the install process -and/or-
      2. Delete the C:\Program Files\PostgreSQL folder, (Note: it could be on another drive) -and/or-
      3. Remove the 'postgres' user from you list of users using the admin tools -and/or-
      4. make sure that the PostGres server is not running as a service and has been removed using RegEdit

    Linux PostgreSQL Server

    The following instructions are used to set up a Linux PostGreSQL server for use with the Theatre Manager application. Click if you are doing Windows setup or Click if you are doing Macintosh setup.

    As of Dec 1, 2016, the current minimum acceptable version of Postgres is 9.6.1 (or later).

    The server needs to be set up on one machine and the application can be set up on as many machines as you wish.

    Follow these steps and you may want to bookmark this page in your browser in case you want to refer to these installation steps. If you are only installing a demo, refer to the last column for required steps.

    task Description Full Install Demo
    1 download the PostGres installer for Linux from Postgresql.org yes yes
    2 the installation of the PostGres SQL server yes yes
    3 installing the demo database and the main TheatreManager User optional yes
    4 configuration of the server parameters for maximizing performance in a production database yes  
    5 creating a daily backup job in using cronnix to run the backup yes  

    Notes and Assumptions:

    • This install process assumes you have NEVER installed PostGres or Theatre Manager on your computer before. If you have, you may need to refer to Updating Postgres Instructions
    • You MUST turn all virus protection while running the installer (especially Norton if you are using it). Virus software always interferes with proper software installation.
    • If this installer is being used to create a demo installation, then you only really need do steps 1, 2 and 3.
    • This process assumes that you have never installed Theatre Manager or Postgres on your machine. If you have already installed Postgres:
      • you will be asked if you want to un-install Postgres (you may want to do that and then try to re-install after)
      • you may need to remove the 'postgres' user from your computer if one exists, unless you know the password for the use.

    Step 1: Install PostGreSQL Database Server

    PostgreSQL for a Linux implementation is the responsibility of your organization to provide the necessary expertise to install, configure, upgrade and maintain the database server.

    Installing Postgresql on Linux

    Before starting the install, please check that the computer date and timezone settings are correct. Failure to do so may cause postgres to think it is in a different timezone.
    1. Install the PostgreSQL application.

    Step 2: Create user and import Database

    Installing a demo database

    The database server needs a specific user called TheatreManager with specific privileges that will be assigned as the owner of each database. We also want to import a demo database. This step assumes that you have installed things into the /Users/Shared directory. If you did not, then you will need to edit the script and do this step manually

    1. Go to /Users/Shared directory. You should see some files and folders with names that look like below.

    Import1

    2. Start terminal and change the user to 'postgres' by typing:
    su - postgres
    Press RETURN
    and then type the postgres user's password (password will not display anything)

    import2

    3. Drag the script '/Users/Shared/CreateDemoDB.sql onto the terminal window. This shortcut saves typing anything.
    Click into the terminal window and then press RETURN to start the command.
    If it does not run, then possible issues are:
    1. You need to have execute permissions on the 'CreateDemoDB.sql' script. Use File Examiner to check or fix that (or use unix chmod commands to give permission).
    2. Make sure that postgres was configured with 'trust' permissions for the local machine.
    3. Make sure that postgres was installed into the /Library/Postgresql8 directory.
    import3
    4. The script will run and load up the TheatreManagerDemo database. You can modify this script to load up a customer database if necessary by editing it in BBedit or in textedit (make sure to save it as text if you use textedit - its preference, unfortunately, is to save as an rtf document). Note, any WARNING messages from the TheatreManagerDemo database creation can be ignored. These warnings are normal.

    step4

    Theatre Manager Desktop Application

    Installing or Updating??

    The install instructions are part of this section and require a link to the installer to be provided from Arts Management Systems.

    If you already have Theatre Manager, please refer to the link to find out how to get the latest updater.

    In either case, once you have the Theatre Manager installer/updater, you can follow the specific instructions for Macintosh or Windows using the General Upgrade Steps as an overall guide.

    Running an upgrade will, if appropriate, automatically generate a random new PCI seed key and re-encrypt credit cards using the new key. In the process, this destroys any previous crypto keys per PCI DSS standard 3.6.

    Credit cards that have been shredded are not affected by the re-encryption process.

    Refer to re-encrypting cards if you wish to do this manually.

    Theatre Manager has never stored CVV2, Track II or any other non PCI compliant information so removal is not necessary per PCI DSS standard 3.3.

    • Version 8 was certified under PABP 1.4. This audit provided verifiability that there was no CVV2 data.
    • Version 9 was certified under PA-DSS 1.2, also verifying there was no CVV2 data.
    • Version 10 was certified under PA-DSS 2.0, also verifying there was no CVV2 data
    • Version 10.6 was certified under PA-DSS 3.1, also verifying there was no CVV2 data
    • Future versions will never have any protected data as per PCI requirements.

    Macintosh Theatre Manager

    Now that the database server is setup and a sample database is imported, we can install Theatre Manager on the machine. These instructions are for installing on Macintosh. If you are using a mixed environment, please refer to the Windows instructions as well.

    1. Download the Theatre Manager Mac installer if you have not done so. This link is supplied upon request.
    When downloading any update for Theatre Manager, please make sure your personal firewall is turned on PCI requirement 1.4
    In recent versions of OSX, you may need to make a temporary change in System Preferences after downloading the installer and before the installer will work. This is because the installer is not digitally signed with Apple.
    2.
    • Double click on the TMSetup.zip program you downloaded to extract the TheatreManager.pkg file.
    • Double click on the TheatreManager.pkg that was just extracted to begin the install process and respond to the prompts as follows

    Click continue

    Click continue and read the license agreement

    Click 'Agree' to accept the agreement and continue

    Click install

    Enter your password (or if you have a mac with Touch ID, use your finger)

    Click 'Close' when done.

    3.

    This step is only for clients installing a fully licensed copy of Theatre Manager ON A NEW MACHINE. This step is not required for those installing a demo copy of the software or those upgrading an existing copy of Theatre Manager.

    When the installation finishes, you will need to replace the serial.txt file in the Theatre Manager program files.

    1. Download the Theatre Manager serial number file if you have not done so. The link to this file is supplied upon request.
    2. Extract the serial.txt file from the serial.zip file (if it did not automatically extract) to your desktop
    3. Go into \Macintosh HD\Applications
    4. Right-Click on the Theatre Manager icon and select "Show Package Contents"
    5. Go into \Contents\MacOS\firstruninstall
    6. Move the serial.txt file from your desktop into the \Macintosh HD\Applications\Theatre Manager\Contents\MacOS\firstruninstall folder replacing the existing serial.txt file
    4. After installation, look for Theatre Manager link on the desktop and double click on it to start it up. There will also be a file called TMPreview.pdf on the desktop that illustrates some key features of TM.
    5.
    For databases on your local server: enter the ip address of your server and click search to see the list of databases.
    If your real database is in the AMS cloud, follow these instructions.
    For Demo databases: If you get asked to find a database, enter the IP address 127.0.0.1 below and click Search. Normally, you should not need to do this, as the Demo database is always assumed to be on the local machine.

    If you cannot connect to the database, check the following settings:

    • make sure port 5432 is open on your machine
    • make sure that the TheatreManagerDemo database got installed by using pgAdmin3 as per the section below, then come back and try connecting again.
    6. If you are running a demonstration copy of the Theatre Manager application, you will see a first time setup screen asking you for your company information. All fields except the second line of address and the web site are mandatory. After you put this in the first time, you will not see it again.

    These fields are used during the demo to show how Theatre Manager verifies information for you. For example, the city, state and country you enter becomes the default country for new patrons that you may add to the database. The area code for the phone number fields becomes the default for patron entry, etc.

    Notice how Theatre Manager converts whatever you type into the proper case as it tries to assist in data entry.

    7. Then, if you are able to connect to the database and enter the company information, you will see the login window below. The password for any of the users in the demo is 'master' (without the single quotes).

    8. In a production environment, once connected to the database in step 5, you can run the TMSetup file on any other machine in the network. After changing the pg_hba.conf file, and editing the serial.txt file, you should be able to connect to the database.

    You will need to use the IP address of the server to connect, instead of 127.0.0.1, and if you cannot connect to the server:

    • make sure port 5432 is open on the server
    • make sure that the real database is installed and setup using pgAdmin3
    • there are no firewalls blocking access
    • the pg_hba.conf IP settings are correct and the server has been restarted

    Enabling installation in Firewall

    In recent versions of OSX, Apple is requiring acknowledgement from the user that they trust the source of the installer. The message you get may vary depending on the version of OSX as Apple changes it.

    The essence is that you will may be allowed to run the installer and will receive a message similar to below (or implying this).

    If you get this message:

    • open up System Preferences
    • Select Firewall
    • Do one of:
      • Enable applications to be run from any developer
      • Click a button that says 'Open Anyway' to run the installer
    • Run the installation process
    • Revert the change you made above after installation

    Using Network User Profiles - Mac

    Follow the steps below if you have Network Users set up and performance of TM seems slow when everything is run across the network.

    Primary Method for Network User Profiles - just install Theatre Manager

    In OS X, Theatre Manager is designed to store key application components in the local user's 'Application Support' directory. This allows multiple local users on the same machine to use Theatre Manager.

    Network Users have a different 'home' directory setup where the key files are not stored on the local machine. When Theatre Manager is installed, it will save some of its files in the network directory - but you may experience some performance issues of the network or server drives are slow.

    Alternate method for running Theatre Manager with NetWork User Profiles:

    If performance seems a little slow with a normal installation that users the network profiles, Theatre Manager can be configured a little differently, as follows.

    1. Make sure:
      • Theatre Manager is already installed on the machine using the TMSetup application -and-
      • Nobody is currently using Theatre Manager on the machine
    2. Go to the Applications Folder
    3. Right click on the Theatre Manager application and select Show Package Contents from the context menu
    4. Navigate to Contents --> MacOS --> firstruninstall folder
    5. Copy the entire contents for the firstruninstall folder.
    6. Navigate back to the MacOS folder.
    7. Paste the contents of the firstruninstall folder into the MacOS folder.
      • You may be asked to replace the serial.txt file
      • Respond 'yes'
    8. Delete the firstruninstall folder. The contents of the MACOSX folder should now be similar to below.
    9. Test that Theatre Manager starts up and you see the login window.
    10. Log in as a couple of other network users and try again

    If you get an error message starting Theatre Manager about permissions writing to a directory, you may need to type the following in Terminal:

    sudo chmod -R -v 777 /Applications/Theatre Manager

    Windows Theatre Manager

    Now that the database server is setup and a sample database is imported, we can install Theatre Manager on the machine. These instructions are for installing on Windows. If you are using a mixed environment, please refer to the Macintosh instructions as well.

    Note: if you are installing on 2003 Terminal Server, you may need to switch the server from 'execute' mode to 'install' mode before using the TMSetup.exe program. After installing, you may need to switch back to 'execute' mode. (This does not apply to any other version of Windows that we know of).

    1. Download the TheatreManager PC installer if you have not done so. This link is supplied upon request
    When downloading any update for Theatre Manager, please make sure your personal firewall is turned on PCI requirement 1.4
    2. Run the TMSetup.exe program and respond to all prompts as follows.

    Right click on the TMSetup.exe application and use 'Run As' to begin the install. Select an administrator as the user ID to use for the install. If a checkbox that implies "Protect My Computer" or "Run with Restrictions" is available and enabled, uncheck the box to allow the installer to run with full install privileges.

    Click 'Ok' to see the TM installer screens

    Click 'Next'

    Read the licence agreement and click 'Yes'

    Click 'Next'

    The installer will begin putting Theatre Manager into the 'C:\Program Files' folder.

    Click 'Close'

    3.

    This step is only for clients installing a fully licensed copy of Theatre Manager ON A NEW MACHINE. This step is not required for those installing a demo copy of the software or those upgrading an existing copy of Theatre Manager.

    When the installation finishes, you will need to replace the serial.txt file in the C:\Program Files\Theatre Manager\FirstRunInstall folder

    If you have already started Theatre Manager before doing this step, then:

    • you will need to do this step
    • then reinstall Theatre Manager (which will remove a directory from your user profile created during the first time you ran Theatre Manager).
    • then start Theatre Manager.

    1. Download the Theatre Manager serial number file if you have not done so. The link to this file is supplied upon request.
    2. Extract the serial.txt file from the serial.zip file
    3. Move the serial.txt file into the "C:\Program Files\Theatre Manager\firstruninstall" folder replacing the existing serial.txt file
    4.
    On windows 10: you must Set Compatibility before starting TM, along with permitting C:/ProgramFiles/Theatre Manager in Windows Defender. Otherwise you may see errors like the one below when starting Theatre Manager.

    5.

    After installation, look for TheatreManager on the desktop or in the Start Menu and open Theatre Manager

    6.

    If you get asked to find a database, enter the IP address 127.0.0.1 below and click search. Normally, you should not need to do this as the Demo database is always assumed to be on the local machine.

    If you cannot connect to the database, check the following settings:

    • make sure port 5432 is open on your machine
    • make sure that 'everyone' has access to all files in the 'C:\Program Files\Theatre Manager' directory
    • make sure that the demo database was installed by using PG admin III as per the section below... then come back and try connecting again.
    7.

    If you are running a demonstration copy of the Theatre Manager application, you will see a first time setup screen asking you for your company information. All fields except the second line of address and the web site are mandatory. After you put this in the first time, you will not see it again.

    These fields are used during the demo to show how Theatre Manager verifies information for you. For example, the city, state, and country you enter becomes the default country for new patrons that you may add to the database. The area code for the phone number fields becomes the default for patron entry, etc.

    Notice how Theatre Manager converts what ever you type into the proper case as it tries to assist in data entry.

    8.

    Then, if you are able to connect to the database and enter the company information, you will see the login window below. The password for any of the users in the demo is 'master'

    9.

    In a production environment, once you are connected to the database in step 5, you can run the TMSetup.exe file on any other machine in the network. After changing the pg_hba.conf file, you should be able to connect to the database.

    You will need to use the IP address of the server to connect instead of 127.0.0.1 and if you cannot connect to the server:

    • make sure port 5432 is open on the server
    • make sure that 'everyone' has access to all files in the 'C:\Program Files\Theatre Manager' directory
    • make sure that the real database is installed and setup using PGAdminIII
    Make sure to also turn off power saving on your ethernet card on all servers and workstations.

    Setting Windows Compatability mode

    on windows 10: you must do this step, along with permitting C:/ProgramFiles/Theatre Manager in windows defender
    You may encounter a failure to launch Theatre Manager if you are installing or upgrading Theatre Manager on a workstation running Windows. The cause of the issue is that you may to tell Windows that Theatre Manager may need to set it to run as administrator for all users. You might see an error like below complaining about an invalid format for userpic.df1 and that it needs converting -- this is a sure sign of windows defender and the settings need to be made.

    Follow the steps below

    1. Right Click on the Theatre Manager icon on the desktop
    2. click properties and then FIND ORIGINAL"
    3. When you find Theatreon your desktop and choose Properties
    4. Click on the Compatibility Tab
    5. Click the button to Change Settings For All Users
      • Uncheck: Run this program in compatibility mode for:
      • Check: Run this program as administrator
    6. Click the button Apply

    Installing .NET for Windows

    It is rare that you might need to do the following steps to install .NET

    Only do so if advised by the Arts Management Systems Support Team

    Windows installs may require you to do one of the following if you get errors starting Theatre Manager, or if Theatre Manager starts, but seems to hang with some menus open, but the login window does not appear.

    Older versions of XP and some versions of Windows 7 may not require this step. However, lately, Microsoft has opted to make their flagship .NET tools an optional part of Windows, which causes the error above. Installing .NET will add that part of Windows back into Windows that Microsoft made optional.

    • Download and install .NET version 2 (XP or earlier) or version 3 (Vista or later) if you do not have it.

    AMS Cloud Setup

    If your database is not in the cloud, pick Local Database and follow instructions for Changing Database. You may have to unclick/click 'Default Port' to allow you to enter the IP address of the database.
    If your database for Theatre Manager is stored in the AMS cloud, the step to connect are:

    1. Start Theatre Manager.
      • If you have never been connected to a database before, you will immediately see a dialog asking you to select a database. Select <AMS Cloud Database> from the popup list.

      • If you have previously connected to a Theatre Manager database before, you will see the familiar list of users. Click the Change DB button at the bottom left of the screen and then follow the instructions above.
    2. You will be prompted with a dialog asking you to enter the unique connection key and password for your venue. Enter them and you will be connected to your database in the AMS cloud

    3. You will see a login window

    Any database in the AMS cloud is automatically set to Schedule 'C' PCI Compliance and no credit cards are ever stored on the database.

    You cannot change the minimum PCI settings. You can enhance settings by restricting which workstations in your environment can take credit cards.

    If there users at the venue with different local time zones, you may need to provide the LocalTimeZone parameter in the Theatre Manager preferences file. This is only needed if the users time zone does not match the time zone setting in the company preferences->Report/Misc tab

    Theatre Manager Web Services

    Theatre Manager web services need 3 components set up in order to work. These are illustrated below and are:

    You can access the Director to configure services at any time using http://127.0.0.1:3012

    Since the director uses javascript, please make sure you have the latest version of your browser installed on your machine or mobile device: Safari, Firefox, Chrome, Opera, IE 11 or Edge browsers are known to be compatible.

     

    For PCI compliance, if TM Server is configured as a web server, it must be installed in a DMZ and separated from the rest of the network so that card holder data would never be on the same part of the lan as the DMZ.
    The above diagram illustrates a standard installation. Depending on security and/or performance requirements; other parameters can be altered to affect load balancing across multiple machines. This should only be done under guidance of AMS staff
    The diagram above shows the flow of data for web sales. The general setup involves:

    • The firewall directs incoming traffic on ports 80 and 443 to the web server from the internet. The web server is configured to elevate all port 80 traffic to use TLS on port 443.
    • The web server can be on the same subnet as the firewall (or not, as you wish). This allows:
      • web traffic from the internet on ports 80 and 443
      • provides dynamic load balancing to a number of Theatre Manager Servers and passes web requests to port 5000 on each of those servers
    • A TM Server in Services Configuration receives communication on port 5000 and talks back to the web server on internal port 8111 (a separate virtual server) to retrieve custom web pages for merging
    • Some configuration of the services in Company Preferences 'Director Tab'

    The actual installation of the is described for Macintosh and Windows. While unsupported by Arts Management, you can use Linux if you know how to use apt-get and install and configure NGINX (we can provide a template nginx.conf file for you.

     

    The diagram refers to 192.168.1.x for the internal network and is used throughout the documentation as a sample lan addresses. Your IP addresses may be different

    Install Theatre Manager Server

    The TM server functions for both web server (using NGINX) and web services. If you have not already done so, please follow the instructions for:
    • downloading and installing TM server for Macintosh or Windows
    • starting the second generation Theatre Manager server for with purposes on the appropriate platform. Theatre Manager server can be configured later:

    Only install TM Server ONCE on a machine. Once installed, TM Server will auto update itself.
    TM Server should be installed on machines with multiple processors.

    For best results, if it is to be used as a:

    • web server - use at least a dual core machine with hyper threading.
    • web services machine - use at least a 4 core machine with hyper threading.

    TM Server for OSX

    You normally need only install the Theatre Manager server ONCE on a machine per the instructions below. TM server will auto update itself.
    In recent versions of OSX, you may need to make a temporary change in System Preferences after downloading the installer and before the installer will work. This is because the installer is not digitally signed with Apple.
    Reinstalling TM Server can be done at any time. Rarely, you may need to type the following command in terminal prior to re-running the installer if thins are very stuck.
    sudo launchctl unload /Library/LaunchDaemons/com.artsman.theatremanagerserver.plist
    Step Action
    Step 1 Download and extract the installers for Macintosh.
    Step 2 Start the installer and click Continue.

    Step 3 Click Continue

    Step 4 Read the licence and click 'Agree'

    Step 5 Enter your admin password or use your finger if your machine has 'touch id'

    Step 6

    Step 7 Click Close

    Step 8 Turn off all power saving and performance degrading features
    Step 9 Proceed to the Steps to configure the server for the purpose you want to use it for

    Starting the NGINX server

    Use terminal Start or Stop the Theatre Manager Server on OSX.

    Step Action
    Step 1 Open Terminal on your computer
    Step 2 To completely stop and restart the server (note: it should have already been stopped during the install process), you will need
    sudo launchctl unload /Library/LaunchDaemons/com.artsman.theatremanagerserver.plist
    sudo chown -R root:wheel /Library/Application\ Support/TheatreManager/
    sudo chown root:wheel /Library/LaunchDaemons/com.artsman.theatremanagerserver.plist
    sudo launchctl load /Library/LaunchDaemons/com.artsman.theatremanagerserver.plist
    Step 3 Use the Director to configure the second generation server for the first time.
    Step 4 Disable all Power Saving options on OSX so that the server doesn't go to sleep - its not a good idea for it to so so for web sales. In addition, please read the note below.

    on OSX, a user must be AUTO-0logged in to run TM server (classic services) on mac. In most version of OSX, the screen can be locked, but sometimes not. Make the user autologin is set.

    ~~~ Troubleshooting

    You can test and troubleshoot the Theatre Manager Server on OSX using any of the following tools.
    Make sure you have disabled all power saving settings by reviewing the installation steps on power saving managment.

    Note: if you bring up this web page on the nginx server, the links below should work directly by clicking in them. If not, substitute your web server IP address for 127.0.0.1 in all links below.

    Tool Action
    Director Use the Director web page to verify the second generation server management process is running.

    You can use the console log to verify errors on start up.

    • If you see that it cannot connect to the database, then verify that you put the IP address and Database name into the right fields in the director window
    • If you see a console message that says the schema is incorrect versions, the second gen listener should download the latest and install it. if it does not, manually stop and start the second gen listener via the terminal
    • if you get a message that indicates trouble with editing json preferences, you may need to use the following command in terminal to remove the preferences file and start again.

      sudo rm "/var/root/Library/Application Support/Theatre Manager Server/config.json"

    Activity Monitor In Activity Monitor, if you view the list of processes, you should see a number that are named 'Theatre Manager Server' if it started properly.
    Direct Test You can test for a direct response on each of the web threads in the Theatre Manager Server by simply querying the ports displayed in the director. If the Theatre Manager Server is on 127.0.0.1, then one or more of the following should elicit a response shown below
    Virtual Host Test You can test for a direct response to retrieving a page on the virtual server.. If the Theatre Manager Server is on 127.0.0.1, then the link below should elicit a response that shows a page that has not been merged. If you get Page Not Found or some other error, then the virtual host is not set up correctly.

    http://127.0.0.1:8111/1/WebPagesEN/tmTickets.html

    External Probe If you want to check the general health periodically of the second gen server, then use the following url to ask for the time from the second generation listener. (replace /1/ with your outlet number).

    http://127.0.0.1/TheatreManager/1/time

    If you want to query through the second generation listener to see if a classic listener is running, then add '&force_proxy' to the url. This talks through the second generation to the classic and, in effect, tests both at the same time:

    http://127.0.0.1/TheatreManager/1/time&force_proxy

    TM Server for Windows

    Do not use Windows 10 or Windows 10 Pro for the TM web services. If at all possible use windows 7, 8, 8.1 or any windows server version. At this time, windows 10 interferes with simple file renaming and affects auto-updating of services.
    You normally need only install the Theatre Manager server ONCE on a machine per the instructions below. TM server will auto update itself.
    make sure to implement the key performance, similar to that of postgres server, especially turning off windows defender on windows 10 pro if you are having issues with auto-updating.
    When installing Theatre Manager Server on a Windows machine, log into the computer as the local administrator. This ensures the proper permissions are assigned to the service.
    You must not install or enable Microsoft's IIS server on the same machine as TM server configured for web services.
    Step Action
    Step 1 Download and extract the installers for Windows. The installer will automatically determine wether you have a 32 bit or 64 bit operating system and install the correct version.
    Step 2 Start the installer and click 'Next'

    Step 3 Click 'Next'

    Step 4 Make sure that the right version (32 or 64 bit) is being installed and click 'Yes'.

    Step 5 The installer will place the Theatre Manager Server in 'C:\Program Files' or where ever the standard program files directory is located.

    Step 6 Click Done to complete the installation process. By default the Theatre Manager Service will start.
    Step 7 Proceed to the Steps on configuring the server

    Starting the Server

    Use the Windows Services Manager to Start or Stop the Theatre Manager Server.

    Step Action
    Step 1 Open the Services Administrative tool through Start >> Control Panel >> Administrative Tools >> Services.
    Step 2 Locate the 'Theatre Manager Server' item in the list.

    It should be set as 'Started'. If it is not, please start it.

    Step 3 Double click to edit the service settings to make sure that it will auto-restart. Click on the recovery tab and make it look like the window below. You will need to set the following:
    • First failure to 'Restart the Service'
    • Second failure to 'Restart the Service'
    • Subsequent failures to 'Restart the Service'
    • Restart service after '0' minutes.

    Step 4 If the database server and the second generation listener are on the same machine, you will need to delay start of the Second Generation listener until a few system services start. This can be done in one of two ways:
    • Using Delayed Startup setting on the server (windows 2008 server and later)
    • Adding dependancies to the service via the command line (all versions of windows server)

    Using Delayed Startup

    Make the startup settings as per the diagram.

    Adding Service Dependancies

    You may want to add a dependancy to the second generation server so that it will not start up until after Postgres and the event log starts.

    To do this, you will need to know the name of the postgres service and type a command in at the command prompt. You can find it by looking at the service and examining the service name. It might look something like one of: postgresql-9.5 -or- postgresql-x64-9.5 depending if you are using 32 bit or 64 bit postgres and which version.

    An example of the command when running on a 64 bit windows server using postgres 9.5 (note there is a space after the depend= which you must include)

    sc config tmserver depend= eventlog/postgresql-x64-9.5

    An example of the command when running on a 32 bit windows server using postgres 9.5

    sc config tmserver depend= eventlog/postgresql-9.5

    When done, check the dependancy tab on the tmserver service and it should show two lines: event log and postgres

    Step 5 Also, once everything has been verified to run properly, make sure that the service start up type is changed from 'Manual' to 'Automatic' so that it will start each time the machine is rebooted.
    • Right click on the Theatre Manager Service.
    • Select Properties.
    • From the Startup Type drop down, choose Automatic.
    • Click the Apply button.
    Step 6 Use the Director to configure the second generation server for the first time.

    ~~~ Troubleshooting

    You can test and troubleshoot the Theatre Manager Server on Windows using any of the following tools.

    Note: if you bring up this web page on the apache server, the links below should work directly by clicking in them. If not, substitute your web server IP address for 127.0.0.1 in all links below.

    Tool Action
    Task Manager In Task Manager, if you view the list of processes, you should see a number that are named 'Theatre Manager Server' if it started properly.
    Director Use the Director to verify the second generation server management process is running.
    Direct Test You can test for a direct response on each of the web threads in the Theatre Manager Server by simply querying the ports set up in extra/httpd-balance.conf. If the Theatre Manager Server is on 127.0.0.1, then one or more of the following should elicit a response shown below
    Event Viewer Test You can look to see if the services start up properly by looking at the event viewer. If you can stop and start the service and you see that it starts listener services on port 5001, then you are likely ok.

    Note: if it will not start completely or you get permissions errors, you may need to give more access to the C:\Program Files\TheatreManagerServer directory. This is especially true of Windows 2003 Server where it seems that the service needs to have 'everyone' with full access to this directory and everything in it.

    Virtual Host Test You can test for a direct response to retrieving a page on the virtual server.. If the Theatre Manager Server is on 127.0.0.1, then the link below should elicit a response that shows a page that has not been merged. If you get Page Not Found or some other error, then the virtual host is not set up correctly.

    http://127.0.0.1:8111/1/WebPagesEN/tmTickets.html

    Query Apache Load Balancer Apache is running a process called 'Balancer-Manager' that can be used to view traffic or alter the algorithms how it will distribute traffic to the Theatre Manager Server. You can view that by accessing the apache sever from an internal IP address. If, for example, it is on 127.0.0.1, then type:

    http://127.0.0.1/balancer-manager

    You should see an OK status for each of the urls set up in extra/httpd-balance.conf

    Preferences If the second generation listener is having trouble starting and/or keeps stopping, you may want to delete the system profile second gen preferences file and start the configuration process over again

    TM Server preference file location

    The TM Server configuration or preferences file can be found in the locations described below. If you run into a situation where a TM Server will not start up, you can delete the preferences file and start over.

    Windows

    • Navigate to the directory:
      • most versions of windows: C:\Windows\system32\config\systemprofile\AppData\Local\Arts Management Systems\Theatre Manager Server
      • some 2003 servers: C:\Documents and Settings\LocalService\Local Settings\Application Data\Arts Management Systems\Theatre Manager Server
    • Delete the config.json

    Macintosh

    • Open Terminal and type:
    • cd ~/Library/Application Support/Theatre Manager Server
    • rm -rf config.json

    Special note: for classic listeners run and managed by the TM Server on OSX. There is a temporary file created in /var/root/Library/Caches/Theatre\ Manager\ Server/TheatreManagerRunTime/Libraries that tells the classic listener how to startup. It cannot be edited or changed by a user - it is re-created each time the classic listener starts.

    For reference, this link has the location of the Theatre Manager desktop preference file.

    Web Server Configuration

    For PCI compliance, the web server configuration must be installed in a DMZ and separated from the rest of the network so that card holder data would never be on the same part of the lan as the DMZ.

    The diagram above shows the flow of data for web sales. The general setup involves:

    • A firewall that directs incoming traffic on ports 80 and 443 to the web server from the internet. The web server is configured to elevate all port 80 traffic to use SSL on port 443.
    • The web server can be on the same subnet as the firewall (or not, as you wish). This allows:
      • web traffic from the internet on ports 80 and 443
      • provides dynamic load balancing to a number of Theatre Manager Servers and passes web requests to port 5000 on each of those servers
    • A TM Server in Services Configuration receives communication on port 5000 and talks back to the web server on internal port 8111 (a separate virtual server) to retrieve custom web pages for merging
    • Some configuration of the services in Company Preferences 'Director Tab'

    The actual installation of the is described for Macintosh and Windows. While unsupported by Arts Management, you can use Linux if you know how to use apt-get and install and configure NGINX (we can provide a template nginx.conf file for you.

     

    The diagram refers to 192.168.1.x for the internal network and is used throughout the documentation as a sample lan addresses. Your IP addresses may be different

    Director Config for Web Server

    If you enter the URL http://127.0.0.1:3012/configure and do not see the 'Director' screen, you may need to:

    Configuring as a Web Server

    This section describes how to configure the Theatre Manager server as an NGINX web server on a machine in the DMZ. This computer should have at least 4 gigs of ram and a fast dual core processor.

    Connect to Theatre Manager server using your browser and enter the URL http://127.0.0.1:3012/configure. You will see a web page like the one to the right. It will help you configure the machine for its appropriate purpose.

    Auto Update

    Theatre Manager Server is designed to auto update when a new version is released. If you wish to disable the feature, make sure to disable it on all machines. If it is enabled, make sure it is enabled on all machines. Components auto-updated by the server are:

    • TM Server
    • NGINX web server
    • SSL/TLS upgrades
    • Default Web Pages (customized changes are never touched)
    • Theatre Manager

     

    Data stored by Arts Management as part of auto-update

    Checking for auto-updates shares some of your information with Arts Management. Data is transmitted over SSL for safety and the values retained by AMS are:

    • Theatre Manager version number
    • TM Listener version number
    • Postgres version number
    • NGINX version number
    • Timestamp of last backup
    • Timestamp of last check for an update
    The above data is used by the web site monitoring tools to tailor our ability to assist your with managing Theatre Manager in your venue.

    Data retrieved from AMS and stored in your database is: number of user and scanner licences, latest version of Theatre Manager for auto deployment to workstations.

     

    Enable Web Server

    Click the 'Enable Web Server Button' to use this machine as an NGINX web server. When clicked, a panel appears allowing you to enter the configuration parameters for the web server.

    Web Server Parameters

    Enable template server

    This causes the web server to listen on port 8111 and provide all your custom web pages to all of the web listener services and there should only be one of these enabled for your entire system. The IP address of this machine must match the Custom Template URL specified in the Director Tab in Company Preferences.

    On the primary web server, you need to enable this feature. When enabled, you will see the option Custom Template Directory lower on the page. Please fill it in.

     

    Enable Load Balancing

    This should always be enabled when you need to tell the web server where each of the web listener machines are (see Load Balancer below)

     

    Domain or IP

    Enter the domain name that this web server is for. This will be your tickets.myvenue.org URL that your customers use to access your sales site.

     

    Custom Template Directory

    The web services always use the most recent built in web pages to keep your web site current. Since you can customize these web pages, you need to tell the TM server where on the disk that the custom pages are stored so that the web listeners can get those instead of the default pages.

    We suggest that they be kept in:

    • Macintosh: /BoxOffice/WebPages
    • Windows: C:|BoxOffice\WebPages
    Refer to Director Tab in company preferences for the contents of the directory.

     

    Transport Layer Security (TLS)

    Each domain (eg tickets.myvenue.org) requires what is called an SSL certificate to uniquely encrypt the communication between your customer and your server. It is what turns on the lock in a patrons browser window. SSL certificate has 3 files that are obtained and properly configured for you by Arts Man:

    • Your public certificate obtained from your SSL provider
    • Your private key which nobody else knows
    • The Diffie-Hellman Parameter file used by NGINX as part of the unique cryptographic key generation that is used in the subsequent encryption process.

    Installation

    To install these files, simply drag them from your desktop on top of the area on your browser. If the area on your browser is green, they are installed. Use the 'Clear Certificates' button to remove any prior certificate files if you do not want them, or simply drag new ones on top to replace them.

     

    Load Balancer

    This section is used to indicate the IP addresses where your Web Listeners are located. This will be on a separate machine and in the example setup, the address is 192.168.1.1 and the port is 5000 (which is the load balancer on of the web listeners).

    Unless doing an expert setup with the assistance of Arts Management Systems support, the port will always be 5000. Simply add as many IP addresses as you have machines acting as web listeners.

    Port 5000 on each web listener acts as a load balancer on the machine to forward requests to port 5001, 5002, etc (one for each second gen listener you have defined.

    SSL Certificate

    The purpose of the SSL Certificate is to ensure communications with your web sales server validated and secure. A valid SSL certificate causes the 'lock' on the patrons web browser to turn on and encrypts all communication between the patron and your web services.

    Before you can get an SSL certificate, you will need:

    The steps you will need to follow to set up an SSL Certificate and get web pages working are in the following sections.

     

    For Venues hosted on AMS Cloud

    AMS provides the static IP for you as part of your setup.

    AMS can provide a URL like 'yourname.artsman.com' if you wish, and if so, will also provide our group SSL certificate for your use. If you prefer to use your own domain name, you will need your own SSL that we can obtain and set up.

    Static IP for Your Router

    Before you can get an SSL certificate, you will need:
    • a static address for your router.
    • a 'nice' domain name like 'tickets.yourvenue.org' that points to your firewall. These generally cost about $10 to $20 monthly in addition to your connection fees, unless you have a business internet package - in which case you probably get one included.

    Obtaining a Static IP

    The static IP must be obtained first and is supplied by your ISP. It will be set up in your firewall/router so that it never changes and means that customers will always be able to find you on the internet. These generally cost about $10 to $20 monthly in addition to your connection fees, unless you have a business internet package - in which case you probably get one included.

    If you have a static IP and do not recall it, then open up a browser and type 'whatsmyip.org'. This asks a web site to tell you what the IP address of the outside of your router is. Alternately, you can enter the config mode for your router to determine the static IP address.

     

    For Venues hosted on AMS Cloud

    AMS provides the static IP for you as part of your setup.

    External DNS

    You will need to ask your ISP (or sometimes the people that host your external web site) to set up a DNS record to point to your static IP address if you do not have one.

    You can think of this as a 'nice' name by which customers can find you, or if they see it in the URL area of the browser, they will be confident that they are connecting to the right web site.

    Call up your ISP (or web site hosting company) and ask them to create a DNS record for 'tickets.myvenue.com' (where myvenue is replaced by your main web site name). As an example, if your main web site is www.artsman.com, then you would like your ISP to create a DNS record for tickets.artsman.com.

    Possible DNS names that you may prefer from a marketing perspective are:
    • tickets.myvenue.org
    • boxoffice.myvenue.org
    • sales.myvenue.org
    • tm.myvenue.org
    • secure.myvenue.org
    • and if you have a mail server or other services already in your organization, we could use that as well.

    Once the DNS record has been created and is propagated to the internet (this usually happens in a few hours but can take as long as 24 hours), the next step is to purchase and install the SSL certificate.

     

    For Venues hosted on AMS Cloud

    AMS can provide a URL like 'yourname.artsman.com' if you wish, and if so, will also provide our group SSL certificate for your use.

    Buying the actual SSL Certificate

    Purchasing your SSL from Arts Management Systems

    Arts Management Systems uses 2048 bit encrypted premium certificates from GeoTrust and if you wish to purchase one, please contact the sales office at (403) 536-1214. We will install any SSL certificate purchased from us and install a secure SSL logo on the checkout page of Theatre Manager's web sales process.

    When you buy an SSL from Arts Management Systems, information that we will require from you in order to customize the SSL to your venue are:

    • company name (do not abbreviate, provide the full legal company name)
    • primary contact's first and last name
    • primary contact's title
    • primary contact's email address
    • primary contact's direct phone number
    • venue's legal Address, City, full State/Province name (do not abbreviate the state or province name)
    • external DNS that you set up such as tickets.myvenue.org
    • the operating system that Apache is running on (OSX, Linux, or Windows)
    • we will require an authorized administrator's email address to send the verification to and approve the request. This needs to be an email address you have the ability to check for the incoming emails. Please make sure that the email account has been set up and is available before you provide us the email account to use, or the approval email will not be delivered. With an invalid or non-working email account, the SSL certificate will not be processed. The options for the email address are below: (Select ONE of the following)
      • admin @ myvenue.org
      • administrator @ myvenue.org
      • hostmaster @ myvenue.org
      • webmaster @ myvenue.org
      • postmaster @ myvenue.org
    We will generate the SSL based on the information provided and you will receive 3 emails:
    1. An email indicating that an SSL creation request has been started.
    2. An email requiring you to confirm the information at the specified email address above. Please confirm the email (by clicking on the acceptance link within that email) and accept the SSL request.
    3. After you have confirmed email #2's acceptance link and the SSL has been processed by GeoTrust, the 3rd final email containing the actual SSL certificate information will be sent to you. Please note that this final email may arrive anywhere from 10 minutes to 12 hours after email #2 was accepted depending upon the next processing cycle by GeoTrust.
    After we have received the SSL certificate information, we will make the SSL certificate files and put it into the Apache server for you in the 'conf' folder and verify that it works. During this final process, we will require remote access to your Apache Server and to a Web Listener to test the SSL certificate configuration with Theatre Manager.

     

    Self Purchased SSL

    If you purchase your own SSL certificate from another source, you will need to install it yourself following the instructions provided to you during the purchase process and make sure it works. If you have any questions about your Self Purchased SSL certificate, contact the company from whom you purchased it for any and all assistance.

    Install and Test the SSL Certificate

    Installing the SSL certificates is easy. Refer to the installation instructions in this web page - simply drag 3 files into the correct area of the setup page, save, and you are done.

    Once the firewall rules have been implemented and the SSL certificate installed:

    1. Open up a browser
    2. Type 'https://tickets.myvenue.org'
    3. It should display a web page in the browser and turn on the lock on the browser.
    4. Test the Certificate using SSL-Labs free service.

      Make sure to check the option "Don't show the results on the Boards"

    This page shows safari with the lock on the upper right turned on

    This page shows firefox with the lock on the lower right turned on

    Please check for it on your browser as appropriate.

    After the SSL Certificate is installed, you should visit SSL-Labs 'Analyse' web page and test the rating and PCI compliance of your web site.

    Diffie Hellman Parameter File

    What is Diffie-Helman?

    Credit: Stack Exchange

    Diffie-Helman is a way of generating a shared secret between two people in such a way that the secret can't be seen by observing the communication. That's an important distinction: You're not sharing information during the key exchange, you're creating a key together.

    This is particularly useful because you can use this technique to create an encryption key with someone, and then start encrypting your traffic with that key. And even if the traffic is recorded and later analyzed, there's absolutely no way to figure out what the key was, even though the exchanges that created it may have been visible. This is where perfect forward secrecy comes from. Nobody analyzing the traffic at a later date can break in because the key was never saved, never transmitted, and never made visible anywhere.

    The way it works is reasonably simple. A lot of the math is the same as you see in public key crypto in that a trapdoor function is used. And while the discrete logarithm problem is traditionally used (the xy mod p business), the general process can be modified to use elliptic curve cryptography as well.

    But even though it uses the same underlying principles as public key cryptography, this is not asymmetric cryptography because nothing is ever encrypted or decrypted during the exchange. It is, however, an essential building-block, and was in fact the base upon which asymmetric crypto was later built.

     

    How to create your Diffie-Helman parameter file

    Since the Diffie-Helman parameter file is a way of creating a shared secret at the start of the cryptographic process, you can change it as often as you want, completely independently of the SSL certificate. It is quite easy to do so.

    Macintosh This needs to be done using Terminal:
    • Type

      sudo openssl dhparam -out ~/desktop/dhparam.pem 4096
      Enter your password

    • You will see a screen similar to below. Generating the key string may take a minute or so
    • This creates a file on your desktop called dhparam.pem which you can use for the Diffie-Hellman parameter file in the 'Director'
    Windows Please ask Arts Management support to make one for you or find a Macintosh. Instructions for making this file on windows are under construction at this time.

    Testing your Web Sales (the Hosts file)

    If your computer in the office cannot see the ticketing web site, the best way is to set up a DNS server inside the network to help all computers see the server.

    Only edit the local machines 'host' file if you cannot set up a DNS server.

    Testing your Web Sales Site

    You should be able to access your ticketing web site via the URL you used to create the SSL certificate after the:

    Try accessing the ticketing web site from:

    • a location outside the office to confirm it works. A cell phone is the ideal way - using the data plan and not while connected to the wifi network.
    • one or more computers inside the office to confirm that it works

     

    Troubleshooting access inside the office

    If you are having issues connecting to your ticketing web site while inside the office and are receiving timeouts, this is often resolved by:

    • adding an internal DNS entry to your DNS server to point to your ticketing web site via an internal path (preferred approach) -or-
    • editing the hosts file on each machine

    Mac's are not usually subjected to this issue. PC's inside the office frequently are because they do not always seem to be able to resolve the DNS that goes outside the firewall and back in, so you have to edit the hosts file to tell the PC how to find the web site.

    Editing the Host file for Mac

    Troubleshooting generally depends on the behavior of the DNS within the firewall and the operating system used. Most Mac's will easily find 'tickets.yourvenue.org' by navigating through the firewall properly. However it may be possible for a machine to not be able to access the online sales domain directly.

    The best way of correcting this issue is to put an entry within the internal DNS server to point 'tickets.myserver.org' directly to the IP address of the apache server.

    If that is not possible, an entry in the hosts file of each web listener that points to the apache server can be made. This should be done if the DNS does not propagate in the internal network. If the Web Listeners start up and are able to find the 'tickets.myvenue.org', you will not need this step. If they do startup but they seem to be ignored by apache very quickly, then you will need this step.

    # Description
    1 Open the 'Terminal' window.
    2 Type cd /etc.
    3 Type sudo vi hosts.
    4 Type the administrator password to the machine.
    5 Use the arrow keys on the keyboard to scroll down.
    6 Type 'I' to enter the edit mode.
    7 Add the IP address of the Apache machine followed by the online sales domain.

    8 Click the 'ESC' key on the keyboard.
    9 Hold the SHIFT key on the keyboard and type Q.
    10 Type WQ.
    This with write the changes to the Host file and close it.

    Editing the Host file for Windows

    Troubleshooting generally depends on the behaviour of the DNS within the firewall and the operating system you use. Windows machines sometimes need a helping hand.

    The best approach is to put an entry within the internal DNS server to point 'tickets.myserver.org' directly to the internal address of the apache server.

    If that is not possible, an entry in the hosts file of each web listener that points to the apache server may be needed. If the Web Listeners start up and are able to find the 'tickets.myvenue.org', this step is not needed. If they do startup but they seem to be ignored by apache very quickly, this step will be needed.

    # Description
    1 Open My Computer.
    2 Navigate to c:/windows/system32/drivers/etc/ (or where the windows system32 directory is located).
    3 Right click on the Hosts file.
    4 Select Open With... WordPad.
    5 Add the IP address of the Apache machine followed by the online sales domain.

    6 Click File >> Save.
    6 Close the Host file.

    Services Configuration

    The Theatre Manager Server provides all web services. It is designed with the following criteria in mind:

    • Deliver performance by
      • Taking advantage of multiple CPU's on current machines by setting up multiple processes
      • Providing background worker processes that automatically take care of longer processes such as email or cart cleanup
      • Providing support for the standard Apache or Nginx Load Balancer for multiple servers
    • Simplify Setup and Management by
      • Handling web services for all outlets in one server while preserving branding for each outlet
      • Run as a service that will automatically restart in case of failure or machine restart
      • Being aware of system updates and automatically intalling them in the background with no outage.
    • Increase Deployment Options by
      • Running on OSX and Windows (linux possible in future)
      • Providing support for other high performance web servers (currently NGINX)

    Installer Download Locations

    Steps to Configure the Theatre Manager Server

    The Following steps are used to configure the Theatre Manager Server:
    1. Theatre Manager Setup:
    2. Test your web pages to make sure the server is working. At this time, we suggest a log in, finding an event, adding it to the cart, and going to the checkout window.

    Configuring Theatre Manager Server

    Getting the Theatre Manager server to work requires the following steps

    Using the Director to configure Theatre Manager Server

    On OSX, if you enter the URL http://127.0.0.1:3012 and do not see the 'Director' screen to the right, you may need to start the process (or stop/start the process) using terminal commands.

    On Windows, you may need to:

    • stop and start the Theatre Manager Server service - or-
    • use the latest Firefox, Chrome, Opera or Edge browser. (The Director does not support IE 10 or less).

    Make sure you have enough permitted connections in postgresql.conf setup for the postgres database to handle the processes you configure.

    Connect to Theatre Manager server using your browser and entering the URL http://127.0.0.1:3012. You will see a web page like the one to the right. It will help you configure what is best for your machine by making recommendations for number of processes.

     

    General

    Enable Automatic Update

    Theatre Manager Server is designed to auto update when a new version is released. If you wish to disable the feature, make sure to disable it on all machines. If it is enabled, make sure it is enabled on all machines.

    Enable Services

    Enable this if you want to set up the online sales and REST api

    Enable Web Server

    This is enabled if this TM server will be acting as the primary load balancer and/or template server for custom web pages. Normally one of these is enabled - and has extended setup.

     

    Services Database

    In the database section, you will need to enter the IP address of the database server and provide the Database Name.

     

    Services

    The values that you enter for the processes depend on the number of CPU's, amount of memory and other processes running on the machine. The suggestion provided is for a machine dedicated to Theatre Manager server. It if it also running the database on the same machine, you will need to reduce the number of processes.

    Web Listeners

    Web Listeners are the actual processes that respond to an online web request from a patron purchasing online or to the REST API.

    Typically (assuming a dedicated machine), the second generation server can be set to have one less process than the number of CPU's on the machine. A general rule of thumb is that you need about 1 meg of ram for each process including operating system, so make sure not to start more than you have available memory.. (Note: each process actually only uses about 400Mb, but the operating system and buffers require their own space). For example:

    • a 4 core machine with 4 gigs of ram could start 3 processes
    • a true 8 core machine could start 7 processes, although you may not need that many.
    • a dual 4 core with hyper-threading should only start 3 process. (It is best not to count the hyper-threaded cores as real CPU's)
    • a machine with 4 gigs of ram, regardless of the number of cores, should have no more than 3 listeners set up
    • a machine with 8 gigs of ram could have 7 processes, if it had enough cores. We would suggest 5 or 6 normally

    Classic Listeners

    Designate the number of classic listeners that you might need to handle some tasks that the main web listeners cannot do (yet)

    • Each Classic process needs about 400 megs of ram for buffers.
    • They are used for few processes and for plugins, so generally a ratio of 2 classic listeners for each web listener is reasonable on each machine.

    Housekeepers

    Housekeepers are used to handle background activity. Typically, this value is always 1. Housekeepers:

    • Clean up expired carts on a periodic basis.
    • Send out scheduled emails automatically.
    • Perform daily database jobs like purging expired web logs, etc

     

    General Note

    In general, if you count all your processes, multiply by 500mb each and make sure that is well under the total ram in the computer. It is far better to have two machines for web services than over-commit one machine

    TM Server Company Preferences

    The picture below has sample settings in company preferences Director tab that will handle the single router/DMZ settings. Refer to help about Company Preferences if you are unsure how to configuring this window.

    The key things to note are:

    • The web Server URL should have 'https:' and use the URL of your ticketing web site. This is typically 'tickets.xxxx.org'
    • The web server port should be blank which means use the standard https: port of 443. This generally never needs changing.
    • The template page URL should NOT have 'https:' (it should only be http:) and should refer to the direct internal IP address of the main TM Server containing the web page templates
    • The Template Page PORT should be 8111 -- meaning FORWARD any requests for custom pages to the TM Server on port 8111.

      TM Server Special URLs

      The following URL's can be used to talk to the TM Server to obtain information about the server. These URL's would be available inside your network only as they talk to the Director. test TM servers to see if they are responding
      URL Purpose
      http://127.0.0.1:3012 Director's main web page showing the current status of services
      http://127.0.0.1:3012/configure Director's configuration page. This is also available as a link on the Director's status page
      http://127.0.0.1:3012/nginx.conf Shows the NGINX configuration file created by the Director for use with NGINX. It may be requested by AMS support for debug purposes on occasion.
      http://127.0.0.1:3012/access.log Shows the web pages accessed by users in the past 12 hours. It may be requested by AMS support for debug purposes on occasion.
      http://127.0.0.1:3012/error.log Shows the error log generated by the NGINX server in the past 12 hours. It may be requested by AMS support for debug purposes on occasion.
      http://127.0.0.1:3012/activity.log Shows the the current day's atcivity log -- this is all actions done by the server that go to console or event log in that day so you can see what occurred. It may be requested by AMS support for debug purposes on occasion.
      http://127.0.0.1:3012/api/v1/users Shows a list of IP addresses and sessions that are monitoring the specific TM server. This lets you know who is observing the status of the server and ay be watching/monitoring the web activity.
      http://127.0.0.1:3012/clear Clears the setup/config to start over from scratch. None of the configuration is remembered. (remove 'XX' from end of link to actually do it)
      http://127.0.0.1:5000
      https://127.0.0.1/api/v1 Access to the REST API internally to the organization - if enabled for the employee

      Converting from Apache to NGINX

      If you have been using Theatre Manager web services prior to July 2016, an Apache web server would have been manually installed to serve web pages.

      This will need to be removed on a one-time-basis when converting from Apache to the latest TM server using NGINX.

      You can keep using Apache for a web server and simply upgrade TM Server for web services. Existing setup should just work. The advantage of moving to NGINX controlled by TM server are:
      • Simpler setup of a web server via your browser
      • Using NGINX which operates better at higher loads
      • automatic updates of the web server, default web pages and latest versions of SSL/TLS when vulnerabilities are found - which helps immensely with PCI compliance.

      Converting from Apache (Macintosh)

      The instructions on this page are to be used the first time you convert from Apache to the TM Server for web services.

      On the Original Apache Machine (Web Server)

      Follow the Download and Install instructions for TM server. Do not perform any of the configuration steps yet.

      Stop Apache and save the folder
      • Stop Apache
        sudo launchctl unload /Library/LaunchDaemons/com.apache.httpd.plist    (requires Admin password)
        sudo kill -TERM `cat /Library/Apache2/logs/httpd.pid`
      • RENAME your web pages folder. This first step will rename the folder
        sudo mv /Library/Apache2 /Library/Apache2-Final

      Make a combined SSL/CA certificate file

      If this is a GEOTRUST SSL certificate, you will need to add in the certificate chain file following the instructions below. If you purchased your certificate from another reseller, you'll need to do the same thing with their SSL certificate using that vendor's chain file.

      • Go into the folder /Library/Apache2-Final/conf/ssl (that you just renamed in the previous step)
      • Duplicate the server.crt file and call it server-combined.crt
      • Edit the server-combined.crt using TextWrangler or equivalent text editor
      • Make sure there is only one pair of the following in the file
        -----BEGIN CERTIFICATE----- and
        -----END CERTIFICATE-----

        If so, then copy the text below (in yellow) and PASTE after the -----END CERTIFICATE-----. When you are done, the file containing the combined SSL certificate and chain certificate will look something like the sample one to the right.

        -----BEGIN CERTIFICATE-----
        MIIERDCCAyygAwIBAgIDAjp4MA0GCSqGSIb3DQEBCwUAMEIxCzAJBgNVBAYTAlVT
        MRYwFAYDVQQKEw1HZW9UcnVzdCBJbmMuMRswGQYDVQQDExJHZW9UcnVzdCBHbG9i
        YWwgQ0EwHhcNMTQwODI5MjIyNDU4WhcNMjIwNTIwMjIyNDU4WjBmMQswCQYDVQQG
        EwJVUzEWMBQGA1UEChMNR2VvVHJ1c3QgSW5jLjEdMBsGA1UECxMURG9tYWluIFZh
        bGlkYXRlZCBTU0wxIDAeBgNVBAMTF0dlb1RydXN0IERWIFNTTCBDQSAtIEc0MIIB
        IjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA30GUetr35DFDtuoBG1zOY+r6
        baPZau4tmnX51ZxbvTTf2BzJbdgEiNputbe18DCuQNZd+sRTwdQinQROEaaV1UV8
        QQVY4Ezd+e5VvV9G3K0TCJ0s5PeC5gcrng6MNKHOxKHggXCGAAY/Lep8myiuGyiL
        OQnT5/BFpLG6EWeQVXuP3u04XKHh44PEw3KRT5juHMKAqmSlPoNiHMzgnvhawBMS
        faKni6PnnyrXm8rL7ZcBnCiEUQRQQby0/HjpG88U6h8P/C4BMo22NcsKGDvsWj48
        G9OZQx4v973zWxK5B17tPtGph8x3cifU2XWiY0uTNr3lXNe/X3kNszKnC7JjIwID
        AQABo4IBHTCCARkwHwYDVR0jBBgwFoAUwHqYaI2J+6sFZAwRfap9ZbjKzE4wHQYD
        VR0OBBYEFAtQ7HfvKpv/7AOhCv+txuQqGMc+MBIGA1UdEwEB/wQIMAYBAf8CAQAw
        DgYDVR0PAQH/BAQDAgEGMDUGA1UdHwQuMCwwKqAooCaGJGh0dHA6Ly9nLnN5bWNi
        LmNvbS9jcmxzL2d0Z2xvYmFsLmNybDAuBggrBgEFBQcBAQQiMCAwHgYIKwYBBQUH
        MAGGEmh0dHA6Ly9nLnN5bWNkLmNvbTBMBgNVHSAERTBDMEEGCmCGSAGG+EUBBzYw
        MzAxBggrBgEFBQcCARYlaHR0cDovL3d3dy5nZW90cnVzdC5jb20vcmVzb3VyY2Vz
        L2NwczANBgkqhkiG9w0BAQsFAAOCAQEAMyTVkKopDDW5L8PHQpPAxhBLAwh2hBCi
        4OdTEifyCtp/Otz9XHlajxd0Q1Ox1dFdWbmmhGTK8ToKWZYQv6mBV4tch9x/4+S7
        BXqgMgkTThCBKB+cA2K89AG1KYNGB7nnuF3I6dHdrTv4NNvB0ZWpkRjtPCw3EU3M
        /lM+UEP5w1ZBrFObbAWymuLgWVcwMrYmThMlzfpIcA91VWAR9TvVXlo8i1sPD2JC
        SGGFixD0wYi/f1+KwtfNK5RcHzRKCK/rromoSHVVlR27wJoBufQDIj7U5lIwDWe5
        wJH9LUwwjr2MpQSRu6Srfw/Yb/BmAMmjXPWwj4PmnFrmtrnFvL7kAg==
        -----END CERTIFICATE-----

      Make the Diffie-Helman File

      Copy htdocs and conf folders to the Primary Theatre Manager Server machine

      The Primary Theatre Manager Server machine will be the machine in your Local Area Network that is currently running the Theatre Manager Server and Classic Listeners. It will need a copy of the files edited above.

      • On the Web Server go to the folder /Library/Apache2-Final/
      • Select both the htdocs and the conf
      • Right click on one of the two selected folders and Compress 2 Items
      • This should create a file on your desktop called Archive.zip. Find it and make sure the created date is just a moment ago
      • Rename this file WebPagesAndSSL
      • Copy this file to the the desktop of the Primary Theatre Manager Server Machine. You can use any tool like a USB stick or file transfer to get the file to the TM Server Machine.

       

      On the Web Server machine

      • Open an Internet Browser such as Chrome
      • Go to 127.0.0.1:3012
      • Select the Configuration tab
      • Check the following:
        1. Enable automatic software updates
        2. Enable web server
        3. Enable load balancing
      • Fill in the Domain (or IP) with the ticketing domain. Eg. tickets.artsman.com
      • Drag and drop the server-combined.crt, server.key and dhparm.pem from the unzipped conf/ssl folder onto the Transport Layer Security (TLS) section of the page
      • If the Web Server and the Web Listener are not on the same machine:
        1. Check the Enable TLS for load balanced addresses box
        2. Click the Add Balance Address button
        3. Enter the IP address of the Primary Theatre Manager Server machine in the Address field
        4. Enter 443 in the Port field
      • Click Save

       

      On the Primary Theatre Manager Server machine

      • Open an Internet Browser such as Chrome
      • Go to 127.0.0.1:3012
      • Select the Configuration tab
      • Check the following:
        1. Enable automatic software updates
        2. Enable services
        3. Enable web server
        4. Enable template server
        5. Enable load balancing
        6. Behind reverse proxy (only if the Primary Theatre Manager Server is in the LAN and the Web Server is in the DMZ
      • Fill in the Domain (or IP) with the ticketing domain. Eg. tickets.artsman.com
      • Set the Primary Outlet # to be your Outlet number Eg. 1 (in most cases)
      • Enter the Marketing URL as the full path to your main web site Eg. http://www.artsman.com
      • Fill in the Custom Template Directory to say BoxOffice/WebPages
        This will be the new location of the web pages. They will reside inside the Local Area Network on Primary Theatre Manager Server. Only the content of the tmCustom and the tmGifs folder should be moved to this location.
        1. Create a new set of folders with the following path:
          Macintosh HD/BoxOffice/WebPages/1/WebPagesEN Where 1 is the same number as the Primary Outlet# from above
        2. Unzip the WebPagesAndSSL.zip folder
        3. Navigate into the HTDOCS/1/WebPagesEN/tmCustom folder
        4. Copy the content of the tmCustom folder into the HD/BoxOffice/WebPages/1/WebPagesEN folder
        5. Navigate into the HTDOCS/1/WebPagesEN/ folder
        6. Copy the tmGifs folder into the HD/BoxOffice/WebPages/1/WebPagesEN folder
      • Drag and drop the server-combined.crt, server.key and dhparm.pem from the unzipped conf\ssl folder onto the Transport Layer Security (TLS) section of the page
      • Unless there are multiple Web Listeners, leave the Load Balancer as is
      • Click Save

       

      Cleanup steps after Apache converted to Theatre Manager Server/NGINX

      On the original Apache server machine that is now running TM server:

      • Rename the Apache folder for posterity
      • Remove the Launchd plist that used to start up apache
        sudo rm -rf /Library/LaunchDaemons/com.apache.httpd.plist    (requires Admin password)

      Converting from Apache (Windows)

      The instructions on this page are to be used the first time you convert from Apache to the TM Server for web services.

      On the Original Apache Machine (Web Server)

      Follow the Download and Install instructions for TM server. Do not perform any of the configuration steps yet.

      Stop Apache and save the folder
      • Stop Apache
        1. Open Windows Services
        2. Select Apache24
        3. Click Stop
      • RENAME the Apache folder.
        C:\Apache24-Not-In-Use

      Make a combined SSL/CA certificate file

      If this is a GEOTRUST SSL certificate, you will need to add in the certificate chain file following the instructions below. If you purchased your certificate from another reseller, you'll need to do the same thing with their SSL certificate using that vendor's chain file.

      • Go into the folder C:\Apache24-Not-In-Use\conf\ssl (that you just renamed in the previous step)
      • Duplicate the server.crt file and call it server-combined.crt
      • Edit the server-combined.crt using Notepad++ or equivalent text editor
      • Make sure there is only one pair of the following in the file
        -----BEGIN CERTIFICATE----- and
        -----END CERTIFICATE-----

        If so, then copy the text below (in yellow) and PASTE after the -----END CERTIFICATE-----. When you are done, the file containing the combined SSL certificate and chain certificate will look something like the sample one to the right.

        -----BEGIN CERTIFICATE-----
        MIIEbzCCA1egAwIBAgIDAjpzMA0GCSqGSIb3DQEBCwUAMEIxCzAJBgNVBAYTAlVT
        MRYwFAYDVQQKEw1HZW9UcnVzdCBJbmMuMRswGQYDVQQDExJHZW9UcnVzdCBHbG9i
        YWwgQ0EwHhcNMTQwNjExMjIwMjU5WhcNMjIwNTIwMjIwMjU5WjBmMQswCQYDVQQG
        EwJVUzEWMBQGA1UEChMNR2VvVHJ1c3QgSW5jLjEdMBsGA1UECxMURG9tYWluIFZh
        bGlkYXRlZCBTU0wxIDAeBgNVBAMTF0dlb1RydXN0IERWIFNTTCBDQSAtIEczMIIB
        IjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAs0Q6bLCuyxT5jBl0NFypaeOI
        U3elp/+90TwNJ+TerX+80ZBYk9am2jmcreEOVkbulZ4QaEycK/ZqOouAgYcGVyUa
        VlKU3ZDrZzve+q42aNNiafZsgiRET4dcmBGVZGvoDNHd5ieXrszikWpBErar5cxu
        zCO4Y4ofMZMtBsT36D1YzZcIRmx7dMD4/DE7p3/Xj7DJFWNQehJN9RIeo35V43W3
        6h7qMSwITtjLQ3SJJLzSDh7w2wUk9oq/ECeEQRr2GFPukdBUF9N9Pn6yfai/27kh
        KvCJuQhuWrNe6oK4ficLzFZzgQVP45YtcdV4p2DD1+yqORoFOYKB4BUsNdHuJQID
        AQABo4IBSDCCAUQwHwYDVR0jBBgwFoAUwHqYaI2J+6sFZAwRfap9ZbjKzE4wHQYD
        VR0OBBYEFK1lIoWQ0DvjoUmLN/nxCx1fF6B3MBIGA1UdEwEB/wQIMAYBAf8CAQAw
        DgYDVR0PAQH/BAQDAgEGMDUGA1UdHwQuMCwwKqAooCaGJGh0dHA6Ly9nLnN5bWNi
        LmNvbS9jcmxzL2d0Z2xvYmFsLmNybDAuBggrBgEFBQcBAQQiMCAwHgYIKwYBBQUH
        MAGGEmh0dHA6Ly9nLnN5bWNkLmNvbTBMBgNVHSAERTBDMEEGCmCGSAGG+EUBBzYw
        MzAxBggrBgEFBQcCARYlaHR0cDovL3d3dy5nZW90cnVzdC5jb20vcmVzb3VyY2Vz
        L2NwczApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRU3ltYW50ZWNQS0ktMS02OTkw
        DQYJKoZIhvcNAQELBQADggEBAE4nuBrHO9xdu54aNSMeiFWQ0eyGnIi34B9nh+J8
        tUMDDrYC6OD/hoQZcenyS/WeLi5e26vWHE7EPrgseIZxEK6NxXC/pPmJ5rTt6Evt
        fAkqCQgGPtTh3oKSDDQwNQrBYHXKtlVrqgBCyz/7EOH7hcEhkHIrbsDondm1WlCO
        NB67OKc8Mb168kOL6xbKrZveax74T7ZeSikfehTukfSUT6S9m3Z6vPFRepaogQ6D
        hz+Lrl4ymzSesufbL+wCoOH9UVL+LNs2usHWXktYbd7G4eH6mgMsW6Lhs5v5NuzB
        c/ozEmaV42kQtteqM/r2nUFtliq6voMxQX8MCtJp1vw1TMM=
        -----END CERTIFICATE-----

      Make the Diffie-Helman File

      Copy htdocs and conf folders to the Primary Theatre Manager Server machine

      The Primary Theatre Manager Server machine will be the machine in your Local Area Network that is currently running the Theatre Manager Server and Classic Listeners. It will need a copy of the files edited above.

      • On the Web Server go to the folder C:\Apache24-Not-In-Use\
      • Select both the htdocs and the conf
      • Right click on one of the two selected folders and Send to >> Compress Zip Folder
      • This should create a file on your desktop called Archive.zip. Find it and make sure the created date is just a moment ago
      • Rename this file WebPagesAndSSL
      • Copy this file to the the desktop of the Primary Theatre Manager Server Machine. You can use any tool like a USB stick or file transfer to get the file to the TM Server Machine.

       

      On the Web Server machine

      • Open an Internet Browser such as Chrome
      • Go to 127.0.0.1:3012
      • Select the Configuration tab
      • Check the following:
        1. Enable automatic software updates
        2. Enable web server
        3. Enable load balancing
      • Fill in the Domain (or IP) with the ticketing domain. Eg. tickets.artsman.com
      • Drag and drop the server-combined.crt, server.key and dhparm.pem from the unzipped conf\ssl folder onto the Transport Layer Security (TLS) section of the page
      • If the Web Server and the Web Listener are not on the same machine:
        1. Check the Enable TLS for load balanced addresses box
        2. Click the Add Balance Address button
        3. Enter the IP address of the Primary Theatre Manager Server machine in the Address field
        4. Enter 443 in the Port field
      • Click Save

       

      On the Primary Theatre Manager Server machine

      • Open an Internet Browser such as Chrome
      • Go to 127.0.0.1:3012
      • Select the Configuration tab
      • Check the following:
        1. Enable automatic software updates
        2. Enable services
        3. Enable web server
        4. Enable template server
        5. Enable load balancing
        6. Behind reverse proxy (only if the Primary Theatre Manager Server is in the LAN and the Web Server is in the DMZ
      • Fill in the Domain (or IP) with the ticketing domain. Eg. tickets.artsman.com
      • Set the Primary Outlet # to be your Outlet number Eg. 1 (in most cases)
      • Enter the Marketing URL as the full path to your main web site Eg. http://www.artsman.com
      • Fill in the Custom Template Directory to say C:\BoxOffice\WebPages
        This will be the new location of the web pages. They will reside inside the Local Area Network on Primary Theatre Manager Server. Only the content of the tmCustom and the tmGifs folder should be moved to this location.
        1. Create a new set of folders with the following path:
          C:\BoxOffice\WebPages\1\WebPagesEN Where 1 is the same number as the Primary Outlet# from above
        2. Unzip the WebPagesAndSSL.zip folder
        3. Navigate into the HTDOCS\1\WebPagesEN\tmCustom folder
        4. Copy the content of the tmCustom folder into the C:\BoxOffice\WebPages\1\WebPagesEN folder
        5. Navigate into the HTDOCS\1\WebPagesEN folder
        6. Copy the tmGifs folder into the C:\BoxOffice\WebPages\1\WebPagesEN folder
      • Drag and drop the server-combined.crt, server.key and dhparm.pem from the unzipped conf\ssl folder onto the Transport Layer Security (TLS) section of the page
      • Unless there are multiple Web Listeners, leave the Load Balancer as is
      • Click Save

       

      Cleanup steps after Apache converted to Theatre Manager Server/NGINX

      On the Web Server machine that is now running Theatre Manager Server
      • Rename the Apache folder for posterity
      • Remove Apache from Windows Services
        sc delete Apache2.4

      Monitoring Theatre Manager Services

      You can quickly monitor the overall health of the Theatre Manager system with simple URL. If that does not respond as expected, there are some other things that you can do monitor the internal components. The following table gives you some ways to check the system and diagnose what is working and what is not.

      ArtsMan uses open source software called Nagios to check your 'ticketing' web site every 90 seconds via the top link in the table below (Ubuntu install instructions for technically minded).

      The monitoring is a free service. Our support team monitors this tool through out the day and if we notice outages during normal support hours (Monday-Friday 8-5 MST, excluding holidays), we will try to let you know. However, it is not substitute for your own monitoring services.

      Item Purpose Monitoring Tool Expected Results
      1 Verify entire system is up https://tickets.yourvenue.org/TheatreManager/1/time?force_proxy

      This sends a web request asking for the time from the web services. If you get the results expected, then the database, web server, TM listener and classic listener are all working

      Web page with the text TIME=20 somewhere in it
      2 Verify everything but classic listeners running https://tickets.yourvenue.org/TheatreManager/1/time If the probe in #1 (above) fails, then sending the same command without '?force_proxy' tests to see if all but classic listeners are runing Web page with the text TIME=20 somewhere in it
      3 Verify Web Server is up https://tickets.yourvenue.org

      If the probes in #1 and 2 fail, his tests to see if NGINX is up

      The url should generally change to https://tickets.yourvenue.org/TheatreManager/1/login?event=0

      It means you should get a re-direct.

      4 Verify Domain or Router in terminal or dos prompt, type:

      NSLOOKUP tickets.yourvenue.org

      you should see the static IP address for the outside your router. If you see that but get no other response to the above, then your web site is there, but perhaps your router is down.
      5a Verify Database Server is Running Start up Theatre Manager on the database server machine. You should see the login window with the list of users. If so, skip to #6. If not, check that services are running.
      • OSX:, you should see 'postgres' in the activity monitor.
      • Windows: you should see postgres in the list of tasks.

      Otherwise refer to starting and stopping the service for the appropriate platform.

      5b Verify Database Server Running If nothing else seems to be running, you can test to see if the database server is working by remoting into the machine with the database server on it. Look for the program called 'pgadmin' and start it up.

      It will have a list of connections. Pick the connection that is localhost or 127.0.0.1 and double click on it. You may need to know the password.

      You should see a list of databases.
      6 Verify NGINX server is running If you cannot see your web services externally from probe #1, you can test the server internally using:

      http://127.0.0.1:8111/test.html

      If you see the message on the web page The stage is set! then the TM server is running, but may not be configured for some services.
      7a Verify TM Web Services are running Access the Director using http://127.0.0.1:3012

      If you do this on each machine that is running the Director, it will tell you which components of the TM server are running on the machine and which are down, stopped, or in error

      The Director web page with with a status showing that listeners, housekeepers, etc are up and running.

      If you do not see this, it is stopped

      7b Verify TM Web Services are running

      Windows

      You can also look to see if the service 'Theatre Manager Server' is running using the services control panel.

      OSX

      • you can use the terminal commands to unload and reload the service to restart it
      • you can use tail to watch the log

        sudo tail -f /var/root/Library/Logs/Theatre\ Manager\ Server/activity.log

      After playing with the service and/or restarting it, go back to '5a' to see if the director is running.

      Credit Card Authorization

      Theatre Manager provides connectivity to a few different service providers for credit card authorization, along with the ability to implement either Schedule "C" or Schedule "D" compliance.

      Our sales team will happily discuss your needs, provide contact information for each option, and help quickly and seamlessly setup credit card processing in Theatre Manager. Ultimately, the final choice of processor is up to the venue and we will certainly assist in the implementation.

      Service Providers provide the infrastructure to authorize cards under your merchant account and then deposit YOUR funds directly in YOUR bank with minimum delay.

      Definitions used in Credit Card Processing

      Definitions

      There is often confusion between the purpose of a bank, a processor, and an aggregator, and understanding the difference helps make sense of the authorization options available to you.

      • Bank: A bank is where the money ends up at the end of the day. If somebody gives you money in any form (cash, check, credit card), you write up deposit slips and take it to the building at the corner on the main street. Banks are brick-and-mortar companies with charters to write loans, put your money in a safe, etc.
      • Merchant Processor: A processor is not a bank. Direct Processors are only in the business of authorizing credit cards on behalf of a bank and hold on to the money while it is electronically in transit to your bank. When you do your daily credit card batch settlement, the money in transit is transferred directly to your bank. In North America, there are about 15 major processors such as Paymentech, Nova, 1st Data, Visanet, FMDS, Vital, TSYS, etc. Some banks prefer working with some processors - but generally most processors can get your money to any bank.
      • Merchant Provider/Aggregator: There are numerous (meaning hundreds) of aggregators that will process your card for you. All those aggregators use one of the 15 merhant processing companies. Think of the merchant provider/aggregator as being like an insurance broker... they shop for the best deal with a processor. The processor is the actual company that does the credit card processing for the aggregator.
      • Merchant Account: You set up an account with one of the processors or aggregators, who then assigns to you a merchant number. The merchant number accompanies transactions submitted to the processor and identifies (1) who should get the money (i.e. you), and (2) which bank account the money gets deposited to.
      The reason that processors and banks are separate is historical. Banks started as local or regional entities in the USA. Most were not big enough to handle the infrastructure of authorizing credit cards. When cards became very popular in the 70's, they farmed out the business of authorizing cards to a processor as an economical means of providing cards to their customers without the expense of hosting large computer centres.

      Direct Credit Card Processing Options

      Regardless of the processor you pick, the money always goes directly to your bank account. You enter or swipe the card information into Theatre Manager and it sends all the correct information to the appropriate service provider.

      Theatre Manager transmits data directly to your processor over a secure HTTPS connection authenticated by a user ID and password unique to your merchant account and supplied only to you by the bank. Refer to each processor to see their additional capabilities. PCI DSS 4.1

      These online processors are able to manage multiple authorizations at once, making for a faster and smoother buying experience both for direct Theatre Manager users and for patrons buying online.

      The following diagram illustrates the authorization flow.

      Service Providers for Direct/Online Processing

      Supported processing options are:

      Theatre Manager Help Link Processor Marketing Website Account Setup
      Contact Information
      Bambora™ Bambora™ click for contact info
      Paymentech Orbital™ Paymentech Orbital™. click for contact into
      Elavon™ VirtualMerchant Elavon™ Virtual Merchant main processor. click for contact info
      Moneris™ Moneris eSelect Plus™ direct processing or hosted payments click for contact info
      Authorize.net™ Authorize.net™
      Elavon™ (private brand) derivative of Elavon™ and specific to city of Miami City of Miami only

      Bambora Installation

      Arts Management Systems provides the Bambora module (formerly Beanstream) to support credit card authorization. The installation is done for you on site by Arts Management training staff on any Theatre Manager Workstation.

      Bambora implements user id and password authentication over https connections to provide compliance with PCI DSS 4.1

      A unique feature of Bambora allows refunding against an original credit cards purchase, even if the credit card has been shredded. This is useful for venues that do not wish to store credit cards and may need to refund to cancelled events periodically long after the original payment.

      Please contact Arts Management to discuss the process of getting a Merchant Account from Bambora.

      After Bambora has provided you with a merchant account, installation is quite straightforward. Once set up, funds gets authorized as 'Card Not Present' and then deposited right to your own bank upon settlement from Theatre Manager. This account information you are provided is all you need in the merchant setup windows (in the pages that follow) to begin secure credit card authorization.

      Bambora needs an account setup for authorization and one for online viewing of the account data. You can set up multiple accounts for online access the data so some people can view data and others have more access to transactions and history.

      1. Bambora - uses the Merchant Portal via a web browser to "view the transactions" that have occurred. This account setup might need to be used during the EOD deposit process to verify transactions as required.
      2. Merchant User ID and Password - uses Bambora to allow authorizations to occur and be settled but not be viewed. This information is what needs to be entered into Theatre Manager's Merchant account to allow authorizations to occur.

      The user ids and passwords for both of the above are different and should not be interchanged or confused with each other. Follow the appropriate setup steps for each.

      After following the setup for both accounts, make sure to:

      • test the gateway
      • Disable requirements for CVV2 and AVS in the online interface and allow those be managed from Theatre Manager merchant setup and set each employee to require CVV2.

      Bambora Setup - Contact Information

      Please contact our Bambora representative below. Bruce has set up many Theatre Manager merchant accounts over the years - so make sure to tell him it is for TM.

      Serving USA and Canada:

      Bruce Averill
      A First Data Company
      705.772.2132
      bruce@K2KPOS.com
      www.K2KPOS.com

       

      Ask for an Bambora account to be set up for TM

      Once your Merchant Account information is provided to you, the following steps will need to happen:

      1. Settle any existing credit card batch (run an End of Day)
      2. Create a new merchant account in Theatre Manager
      3. Follow the steps to change your merchant provider

      Then you can start using Bambora.

      If you have any questions directly related to your Bambora merchant account setup, please contact Bruce directly. Contact Arts Management if you have questions about how to setup Theatre Manager to reference and authorize credit cards using your Bambora account.

      Bambora Gateway Account

      The User ID and Password setup is arranged by Arts Management from Bambora and is entered into the Setup --> System Tables --> Merchant Accounts window as below:

      Software Type

      The following values are set on the software type tab per the diagram below:

      • Set the server software to be Beanstream
      • The merchant provider will automatically be set for you
      • The merchant number is for use on ticket faces and for contacting Bambora support.

      Connection Info

      The following entries are set on the Connection Info tab per the diagram below:

      • User/Server id - provided through Bambora. The user id remains constant for the life of the account.
      • Password - the password is auto generated for you. You can change it via the online interface to generate a new 'secret' key. If you do that, you can expire your old password right away or allow both old and new to co-exist for up to 24 hours.
      • Primary URL - is always www.beanstream.com/scripts/process_transaction.asp
      • Port - is always 443

      Employee and Card Setup

      On the Merchant Setup window (see account setup), the final bit of setup is to determine which employees and which payment methods are associated with this merchant account.
      • To assign employees to this merchant account, click on the 'Employee' tab and find the employees to assign. In a multi merchant setup situation, drag only those employees that will use this merchant account as the default.

        While some employees may have permission to use multiple merchant accounts, viewing their name here is the default merchant account assigned to them for charging cards. If the employee wants to use another merchant account, they will need to select it on the payment window.

      • Click on the 'card' tab to select which credit card payment methods are associated with this merchant account.

        If you need to have multiple merchant accounts and both are to take Visa (for example), you will need two Visa payment methods and assign one of them to each merchant account.

      if you are switching from one merchant services provider software to another, you can open both merchant accounts and drag the employees from one window to the other. You can do the same for the credit card payment methods - to make the switch easy and fast.

      Any future dated 'post dated payments' associated with the card you drag to another merchant provider will automatically be re-assigned to authorize on the new merchant provider card network.

      Testing Bambora

      After setting up the Bambora Gateway in the Merchant Account setup, you will need to test that it works. The best way to do this is:
      • Search for yourself in the database or create a new patron that is yourself
      • Create a new order and buy a ticket
      • On the payment window, select the credit card you want to use and do a test authorization
      • If you get an authorization with a message indicating AVS match and/or CVV2 match, then the setup is correct
      • Log in to your Bambora online account and view the batch to see that your transaction is there
      • In Theatre Manager, void the credit card payment. It will appear in Bambora that the charge is still there with as a PA (pre-auth). That means it will be ignored
      • Try another authorization and then do an End Of Day (i.e. SETTLEMENT) and make sure the amount makes it to the bank in the next day or so

      Trouble Shooting Bambora Issues

      1. If you get a response that looks like it is HTML or XML and indicates that it was not authorized, then your user id/password is probably wrong (please verify), or something is incorrectly set up in Bambora and you will have to contact their merchant support group.
      2. If you get a message during end of day that will not allow cards to settle, make sure your provider has set you up to allow BACKEND transactions. These are used to convert 'authorize-only' transactions that are done during to the day to 'PAC' (fully processed) transactions during the end of day process

      Bambora Web Terminal

      After logging on to the online Bambora web portal, the transactions can be found under reporting/analysis->transaction report. There are two main screens of interest:

      Transaction List

      The Bambora transaction list lets you view the transactions that have occurred. Normally, you would only want to see those since the last end of day, but you can decide which data you want to view. To alter the search, the top part of the list contains date search range, the ability to limit the number of transactions per page and more. You may also view more detail about a transaction by clicking the credit card icon that is on the same line as the transaction.

      The important thing to note is the types of transactions and how Theatre Manager creates them. Specifically:

      • All payments sent for authorization will have a transaction type of 'PA'. This means Pre-Authorization. It is only a hold on the customers credit card. The the end of day is not done, this money will fall off the transaction list and you will not get your money.
      • When you do End of Day, Theatre Manager takes all payments that it authorized that day and turns them into 'PAC' - effectively completing them. Transactions that are 'completed' are swept to your bank at 11:59:59 pm. This means a few things
        • If you do not do end of day on any specific day, nothing will go to the bank until you compete an end of day.
        • If you two multiple end of days in the same day, Theatre Manager sees them as more than one posting. Bambora aggregates all the PAC's into one amount on your bank statement.
        • You will see AT LEAST TWO transactions for each customer. You will see a PA transaction and then you will see a corresponding PAC transaction that completes the PA. A successful authorization is a PA with a blue checkmark followed by a transaction some time later that is a PAC with a blue checkmark.
      • You may see some 'R' transactions -- or refunds. Those are always swept to your bank each night, even if you do not do an end of day. Sorry, but that's the way Bambora works. We suggest making absolutely sure that you do an end of day in each day that refund occurs. For that reason, you may wish to limit who can do refunds.

      Transaction Detail

      The Bambora transaction detail contains a lot of information about the payment, most of which is self explanatory. It is accessed by clicking on the 'credit card' icon on the list window.

      Theatre Manager currently uses 3 of the reference fields at the bottom of the screen to provide:

      • ref1 - contains the Theatre Manager patron number on the account that the ticket was sold under
      • ref2 - contains the Theatre Manager order number
      • ref3 - contains the name of the user who processed the credit card

      At the bottom of the detail window is a table that shows the related transactions.

      Related Transactions

      At the bottom of the transaction detail, there is a table that shows all the related transactions in Bambora. This is probably most pertinent to the original 'PA' transaction. If it has been converted to a 'PAC' transaction, you will see multiple lines as part of the Transaction Detail window that shows all the other transactions that affected this transaction.

      Ultimately, all that matters is that you see a blue checkmark beside the PAC transaction, which means it was swept to the bank. In the example below, we see one.

      Implication from Interrupted End of Day

      However, we also see a number of other transactions with a red X that are related to the PA. If you see those, it may be because an error caused the EOD process to stop (without finishing in Theatre Manager) and so you re-ran it. Bambora only allows one PAC for each PA. A second PAC gives an 'error' but does not affect the outcome.

      Paymentech Orbital Installation

      Arts Management Systems provides the Chase Paymentech Orbital™ adaptor module to support credit card authorization. The installation is done for you on site by Arts Management training staff on any Theatre Manager Workstation.

      Paymentech Orbital implements either user ID and password authentication; or access from specified IP addresses over HTTPS connections to provide compliance with PCI DSS 4.1

      Installation is quite straightforward. You would contact Paymentech using information provided by Arts Management, and they create a Merchant Account for you. Money gets authorized by Paymentech as 'Card Not Present' and then deposited right to your own bank upon settlement from Theatre Manager. This account information that you are provided is all you need to set up in the merchant setup window below to provide secure credit card authorization.

      Paymentech Orbital will need to provide the following 2 account setups (both are required):

      1. Orbital Virtual Terminal - uses the Orbital Gateway via a web browser to "view the transactions" that have occurred. This account setup is used during the Een Of Day deposit process to review your transactions prior to the settlement process.
      2. Certified Connection for User ID and Password - uses the Orbital Gateway to allow authorizations to occur but not be viewed. This information is what needs to be entered into Theatre Manager's merchant account to allow authorizations to occur.

      The user IDs and passwords for both of the above are completely different and should not be interchanged or confused with each other. Follow the appropriate setup steps for each.

      After following the setup for both accounts, make sure to test the gateway.

      Paymentech Orbital - Contact Information

      1. In the US, contact:

        Shannon Maher, Sr.
        Sales Manager
        National Merchant Alliance, LLC
        7415 West 130th Street, Suite #270
        Overland Park, KS 66213
        913-906-9595 (direct)
        smaher@nmainfo.com
        www.nmainfo.com

        Merchant Support
        Philip Beedle
        913-906-9595 x110

      2. In Canada, contact:


        Heather Agnew
        Chase Paymentech Solutions
        One Corporate Plaza
        2075 Kennedy Rd., Suite 200
        Toronto, Ontario M1T 3V3
        (403) 647-2596
        www.chasepaymentech.ca
        heather.agnew@chasepaymentech.com

      3. Ask for a Paymentech Orbital account to be set up

      Please note you may encounter with Paymentech:

      • a need to sign a 3-year contract for this account. Depending on your transaction volumes, you may able to request a 1-year trial if your organization meets the requirements
      • if you will be a new client to Paymentech, it will take up to two weeks to establish and setup your merchant account
      • Paymentech may request that all transactions flowing through your organization (Box office point of sale business as well as the ecommerce sales) flow through this new account.

      Please note you may encounter with your existing merchant privider:

      • may require 30 days written notice of cancellation

      Once your Orbital account is set up, the following steps will need to happen:

      1. Settle any existing credit card batch (run an End of Day)
      2. Create a new merchant account in Theatre Manager
      3. Follow the steps to change your merchant provider

      Then you can start using Paymentech Orbital.

      If you have any questions directly related to your Orbital merchant account setup, please contact Orbital Technical Support at 1-866-645-1314. Contact Arts Management if you have questions about how to setup Theatre Manager to reference and authorize credit cards using your Orbital merchant account.

      National Merchant Alliance: New Merchant Accounts for Orbital Users

      On Aug 30, 2016, a venue informed Arts Management about a notification they received from their merchant provider National Merchant Alliance (NMA) and there may be a change to their merchant account information effective Sept 1, 2016 - if you are using Paymentech Orbital. The reason, as we understand it, is that Chase Paymentech sold their processing portfolio to Fifth Third Bank.

      While this is very short notice to both our venues and AMS, it appears that the change simply means that a new merchant account is being issued.

       

      Are you affected by this change?

      It appears that three conditions will exist in order for you to be affected. You:

       

      What do I do if I am affected?

      The merchant account number changes are being driven by the National Merchant Alliance. If you are affected and require new merchant accounts, please contact NMA directly. For security and privacy reasons, AMS is not able to act on your behalf to ask for updated merchant accounts and passwords.

      Once you receive the revised merchant info and access codes from NMA, the AMS support team is ready to assist you.

       

      What are the steps I need to take?

      Before Contacting AMS:

      1. Verify that you are using NMA as a merchant provider and Paymentech Orbital for payment processing
      2. Look for your notification from National Merchant Alliance. It may contain information and instructions about the change over.

        You will likely have to contact NMA and get:

        • New Merchant Account # and processing password
        • New PNS number
        • New website for remote management
        • Other miscellaneous information

      After you have your new merchant info:

      The AMS support team will gladly help you through the following steps once you have your new merchant info.

      1. Temporarily DISABLE WEB SALES by unchecking 'Enable web sales' and saving the record.
      2. Complete your end of day DEPOSITS to ensure money goes to your bank using the old merchant account.
      3. Turn ON Emergency Processing in your merchant setup in Theatre Manager
      4. REENABLE WEB SALES by checking 'Enable web sales' and saving the record.
      5. Update your Orbital Merchant information in Theatre Manager with the revised merchant information. It will probably include
        • On the SOFTWARE TYPE tab, edit the PNS number.
        • On the CONNECTION INFO tab, edit the password.
      6. Turn OFF Emergency Processing in your merchant setup in Theatre Manager
      7. Test out your new orbital merchant info. This will generally mean:
        • Authorizing a credit card by adding a payment for $.10 to an order for your self or processing a real order
        • Doing a deposit using your new online information
      8. If you can authorize and settle, try a web sale. If that works, you are likely done.

       

      What if my new merchant information does not work?

      Remember we are here to help.

      • Immediately turn ON Emergency Processing in your merchant setup in Theatre Manager
      • Contact NMA again and verify the new merchant information that you were given
      • Contact AMS and we'll start at step 5 with you (above) and try entering your merchant info again


      Click here for additional help on changing Merchant Providers.

      Orbital Gateway Account

      The Orbital Gateway Certified Connection for User ID and Password setup is obtained from Paymentech Orbital and is entered into the Setup --> System Tables --> Merchant Accounts window as below:

      Software Type

      The following values are set on the software type tab per the diagram below:

      • Set the server software to be Paymentech Orbital
      • The merchant provider will automatically be set for you
      • The PNS number is provided by Paymentech and will need to go into the PNS/Merchant number field - enter in the PNS# (not the merchant number) for your Orbital account. It is typically 12 digits long and generally starts with 720000

      Connection Info

      The following entries are set on the Connection Info tab per the diagram below:

      • User/Server ID - provided by Paymentech and is the user ID for the Certified Connection gateway, not to the Orbital Virtual Terminal (they are not the same thing - the Orbital Virtual Terminal is the online interface).
      • Password - provided by Paymentech and is the password for the Certified Connection gateway. It is also not the password for the Orbital Virtual Terminal.
      • Primary URL - is always orbital1.paymentech.net/Authorize
      • Secondary URL - is always orbital2.paymentech.net/Authorize
      • Port - is always 443
      • Terminal ID - provided by Paymentech and is usually 001
      • BIN number - provided by Paymentech and is always 000002 for North American credit card processing

      Employee and Card Setup

      On the Merchant Setup window (see Account Setup), the final bit of setup is to determine which employees and which payment methods are associated with this merchant account.
      • To assign employees to this merchant account, click on the Employee tab and find the employees to assign. In a multi-merchant setup situation, drag those employees that should use this merchant account by default from the same employee tab in another merchant record. While some employees may have permission to use multiple merchant accounts, viewing their name here shows the default merchant account assigned to them for charging cards. If the employee is able to use another merchant account, they will need to select it on the payment window.
      • Click on the Card tab to select which credit card payment methods are associated with this merchant account.

        If you need to have multiple merchant accounts and both are to take Visa (for example), you will need two Visa payment methods and assign one of them to each merchant account.

      If you are switching from one merchant services provider software to another, you can open both merchant accounts and drag the employees from one window to the other. You can do the same for the credit card payment methods - to make the switch easy and fast.

      Any future dated 'post dated payments' associated with the card you drag to another merchant provider will automatically be reassigned to authorize on the new merchant provider card network.

      Orbital Virtual Terminal

      The Orbital Virtual Terminal requires:

      • User ID - provided by Paymentech and is the user ID for the Orbital Virtual Terminal gateway.
      • Password - provided by Paymentech and is the password for the Orbital Virtual Terminal gateway
      • Orbital Virtual Terminal Gateway - is always accessed via a web browser through https://secure.paymentech.com/manager. This is used to verify current and past batches, look at transactions, generate reports and manage your Orbital Gateway account.

      All users of the Orbital Virtual Terminal in conjunction with Theatre Manager are encouraged to download the Virtual Terminal Users Manual directly from Chase Paymentech. There is also a Virtual Terminal Quick Reference Guide available from the same site.

      Orbital Virtual Terminal - Account Setting for Manual Settlement

      Once you have activated your new Virtual Terminal account by logging in, there is one very important setting that you need to adjust. This particular setting will adjust the behaviour of your account settlement process and is vital for accurate reconciliation. You will need the following.
      • User ID - provided by Paymentech and is the user ID for the Orbital Virtual Terminal gateway.
      • Password - you created after your initial access/activation for the Orbital Virtual Terminal gateway
      • Orbital Virtual Terminal Gateway - is always accessed via a web browser through https://secure.paymentech.com/manager.

        This is used to verify current and past batches, look at transactions, generate reports and manage your Orbital Gateway account.

      1. Log into your Virtual Terminal Account and from the Tab selection at the top click on Admin, then General Admin from the drop-down menu as shown in the following image.

      2. The following setting window will appear.

        Note the Auto Settle Section of the settings.

      3. Make sure the Auto Settle Time is set to NONE.

      4. Save your changes by clicking the save button at the bottom of the settings window

      Testing Orbital Gateway

      After setting up the Orbital Gateway in the Merchant Account setup, you will need to test that it works. The best way to do this is:
      • Find yourself in the database or create a new patron that is yourself
      • Create a new order and attempt to buy a ticket
      • On the payment window, select the credit card you want to use and do a test authorization
      • If you get an authorization with a message indicating AVS match and/or CVV2 match, then the setup is correct
      • Log in to your Orbital Virtual terminal account and view the batch to see that your transaction is there
      • In Theatre Manager, void the credit card payment and then confirm in the orbital Virtual Terminal that the charge is marked as void

      Trouble Shooting

      If you get a response that looks like it is HTML or XML and indicates that it was not authorized, then your user ID/password is probably wrong (please verify), or Paymentech set up the account to require a specific IP. Contact your Paymentech representative and tell them of the issue so that they can correct it. They may put you in touch with the Gateway people. You can inform the Paymentech Gateway support staff that you need to be able to authorize via user ID and password (per their standard setup instructions for Theatre Manager).

      Availability of Settled Batches

      Chase Paymentech send out a buletin in May, 2015:

      Beginning June 29, 2015, we’re changing the Orbital Batch Data Retention Policy for our Orbital Batch subscribers. This change is intended to increase data security as well as reduce the operational burden of maintaining authorization response files on our redundant servers.

      QUICK SUMMARY:

      1. Effective June 29, Orbital Batch response files will be available for download for seven days
      2. This change increases security and reduces operational burdens
      3. After seven days, files can only be retrieved by the Partner Relationship Management team
      Effective June 29, Orbital Batch response files will be available for download for seven days. After that time, we will purge batch response files. Customers wishing to download this data after seven days must contact our Partner Relationship Management team to request the data be retrieved from the host and made available for download.

      For More Information: Contact the Partner Relationship Management Team at 888.818.5128, option 4 or via e-mail at IntegratorSupport@ChasePaymentech.com.

      Elavon Installation

      Arts Management Systems provides the Elavon Virtual Merchant™ adaptor module to support credit card authorization. The installation is done for you on site by Arts Management training staff on any Theatre Manager Workstation.

      Elavon implements either user ID and password authentication; or access from specified IP addresses over HTTPS connections to provide compliance with PCI DSS 4.1

      Installation is quite straightforward. You would contact Elavon using information provided by Arts Management, and they create a Merchant Account for you. Money gets authorized by Elavon as 'Card Not Present' or as 'Swiped Card' and then deposited right to your own bank upon settlement from Theatre Manager. This account information that you are provided is all you need to set up in the merchant setup window below to provide secure credit card authorization.

      Elavon will need to provide the following 2 account setups (both are required):

      1. Elavon Virtual Terminal - uses the Elavon VirtualMerchant Gateway via a web browser to "view the transactions" that have occurred. This account setup is used during the EOD deposit process to review your transactions prior to the settlement process.
      2. Certified Connection for User ID and Password - uses the Elavon Gateway to allow authorizations to occur but not be viewed. This information is what needs to be entered into Theatre Manager's Merchant account to allow authorizations to occur.

      The user IDs and passwords for both of the above are completely different and should not be interchanged or confused with each other. Follow the appropriate setup steps for each.

      After following the setup for both accounts, make sure to test the gateway.

      Elavon - Contact Information

      Contact (for USA and Canada):

      Nicolas Beique
      Helcim Inc. - Founder
      Direct: 1 (877) 643-5246 . ext 1157
      Local: 1 (403) 802-2690
      Fax: 1 (866) 469-3077
      Email: nbeique@helcim.com
      Web: http://www.helcim.com/
      Calgary Office: Suite 403 - 1300 8th Street SW, Calgary, AB T2R 1B2 .
      Seattle Office: Suite 4200 - 701 5th Avenue, Seattle, WA 98104

       

      Ask for an Elavon Virtual Terminal account to be set up

      Once your Merchant Account information is provided to you, the following steps will need to happen:

      1. Settle any existing credit card batch (run an End of Day)
      2. Create a new merchant account in Theatre Manager
      3. Follow the steps to change your merchant provider

      Then you can start using Elavon Virtual Merchant.

      If you have any questions directly related to your Elavon merchant account setup, please contact them directly. Contact Arts Management if you have questions about how to setup Theatre Manager to reference and authorize credit cards using your Elavon merchant account.

      Elavon Gateway Account

      The Elavon Gateway Setup for User ID and Password setup is obtained from Elavon and is entered into the Setup --> System Tables --> Merchant Accounts window as below:

      Software Type

      The following values are set on the software type tab per the diagram below:

      • Set the server software to be Elavon Virtual Merchant
      • The merchant provider will automatically be set for you
      • The merchant number is provided by Elavon and will need to go into the Merchant number field. It is typically 6 digits.

        This number is referred to by Elavon Support as the Virtual Merchant Account ID, the Elavon Developer guide calls the the Virtual Terminal Merchant ID. Look for the Account ID: on the Welcome to the VirtualMerchant Application form.

      Connection Info

      The following entries are set on the Connection Info tab per the diagram below:

      • User id - provided by Elavon and is the user id for the gateway, not to the Elavon VirtualMerchant Account (they are not the same thing - the latter is the online interface).
      • Password - provided by Elavon and is the password for the gateway. It is not the password for the Elavon VirtualMerchant Account.
      • Primary URL - is always www.myvirtualmerchant.com/VirtualMerchant/processxml.do
      • Port - is always 443

      Employee and Card Setup

      On the Merchant Setup window (see Account Setup), the final bit of setup is to determine which employees and which payment methods are associated with this merchant account.
      • To assign employees to this merchant account, click on the Employee tab and find the employees to assign. In a multi-merchant setup situation, drag those employees that should use this merchant account by default from the same employee tab in another merchant record. While some employees may have permission to use multiple merchant accounts, viewing their name here means this is the default merchant account assigned to them for charging cards. If the employee is able to use another merchant account, they will need to select it on the payment window.
      • Click on the Card tab to select which credit card payment methods are associated with this merchant account.

        If you need to have multiple merchant accounts and both are to take Visa (for example), you will need two Visa payment methods and assign one of them to each merchant account.

      if you are switching from one merchant services provider software to another, you can open both merchant accounts and drag the employees from one window to the other. You can do the same for the credit card payment methods - to make the switch easy and fast.

      Any future dated 'post dated payments' associated with the card you drag to another merchant provider will automatically be reassigned to authorize on the new merchant provider card network.

      Elavon Virtual Merchant

      The Elavon VirtualMerchant requires:
      • User ID - provided by Elavon and is the user ID for the Elavon VirtualMerchant gateway.
      • Password - provided by Elavon and is the password for the Elavon VirtualMerchant gateway
      • Elavon VirtualMerchant Gateway - is always accessed via a web browser through https://www.myvirtualmerchant.com/VirtualMerchant/login.do. This is used to verify current and past batches, look at transactions, generate reports and manage your Elavon account.

      All users of the Elavon VirtualMerchant in conjunction with Theatre Manager are encouraged to download the VirtualMerchant Users Manual directly from Elavon.

      Elavon Virtual Merchant - Account Setting for Manual Settlement

      Once you have activated your new Virtual Merchant account by logging in, there is one very important setting that you need to adjust. This particular setting will adjust the behaviour of your account settlement process and is vital for accurate reconciliation. You will need the following.
      • Account ID - provided by Elavon and is the Virtual Merchant Account ID.
      • Password - you created after your initial access/activation for the Virtual Merchant
      1. Log into your Virtual Merchant Account and from the Tab selection at the top click on Terminal >> Advanced >> System Setup from the drop-down menu as shown in the following image.

      2. The following setting window will appear.

        Note the Auto Settle Section of the settings.

      3. Make sure the Auto Settlement box is not checked.

      4. Save your changes by clicking the save button at the bottom of the settings window

      Testing Elavon Gateway

      After setting up the Elavon Gateway in the Merchant Account setup, you will need to test that it works. The best way to do this is:
      • Find yourself in the database or create a new patron that is yourself
      • Create a new order and attempt to by a ticket
      • On the payment window, select the credit card you want to use and do a test authorization
      • If you get an authorization with a message indicating AVS match and/or CVV2 match, then the setup is correct
      • Log in to your Elavon VirtualMerchant account and view the batch to see that your transaction is there
      • In Theatre Manager, void the credit card payment and then confirm in the orbital Virtual Terminal that the charge is marked as void
        • Trouble Shooting

          If you get a response that looks like it is HTML or XML and indicates that it was not authorized, then your user ID/password is probably wrong (please verify), or Paymentech set up the account to require a specific IP. Contact your Elavon representative and tell them of the issue so that they can correct it. They may put you in touch with the Gateway people. You can inform Elavon Gateway support staff that you need to be able to authorize via user ID and password (per their standard setup instructions for Theatre Manager).

      Moneris Installation

      Moneris eSelectplus Payment Gateway

      Theatre Manager supports two Moneris processing options:

      • Moneris Gateway Account - where Theatre Manager sends a credit card provided to Moneris, receives the approval and is able to store the encrypted card (depends on PCI settings in company preferences). This option is used for box office credit card authorizations -and- for web sales with the benefit of supporting post dated credit card payments is using PCI schedule C.
      • Hosted Payment Page - this option can be only be used for web sales. Instead of accepting credit cards, the web interface passes control to the Moneris Hosted Payment Page, meaning that the customer is actually typing the card information directly into Moneris and Theatre Manager never sees it. This enables much less stringent PCI reporting.
        • Schedule A or B - depending if the venue uses hosted payments for e-commece
        • Schedule C - if the venue still enters card data into Theatre Manager at the box office

      You may also want to have Moneris add-on CVV verification to your account at the time of account set-up. Theatre Manager uses the CVV code on a credit card for security and for your (and your patrons') security.

      The merchant account number, Store ID and ECR Terminal ID will be sent to you in a document from Moneris. That document will also contain instructions for you to log in to the eSelectplus gateway to activate your account. Once you do that, you can obtain the API Token that will be required by the Theatre Manager merchant account setup.

      Some sample test accounts are available, if needed.

      Also, visit Misc Moneris Support for additional daily status information.

      Moneris Setup - Contact Information

      Contact our Moneris support representative: Nandini @ 1 (877) 825-0361 X 4117 to have your account setup.

      You want to request the eSelectplusproduct/account.

      Activate Moneris Account and Common Setup

      To activate your eSelectplus account and obtain your API Token:
      • Log into the Moneris online Merchant resource Centre
      • Click Activate My Store
      • You'll be asked to verify the information sent to you in the document from Moneris:
        • merchant account number
        • Store ID
        • Password:
          • if this is not the first time - enter your password
          • If this is the first time, then you'll be asked to create a password. The Username will need to be something memorable that can be shared among folks in the office who will have access to the Moneris Virtual Terminal online. The temporary password is a one-use password that will be changed upon the first log-in.
      • Proceed to generate your API Token
      Future log-ins will require the Username, Store ID, and permanent password that you will set up using the one-use password. Make sure that information is stored somewhere safe in your office and shared among the appropriate staff. Arts Management will not have access to that information if it is lost.

      Obtain Moneris E-Select Plus API Token

      A Moneris E-Select Plus is part of the Admin->Direct Post configuration option.

      This is used when you want Theatre Manager to retain card information within the system (encrypted) for box office sales, or web sales or for settlement for hosted payment page.

      • Once logged into the account online, you should plainly see the API Token. Copy and paste that into a document to store/send to Arts Management along with the info sent you by Moneris so that we may assist setting up the merchant account in Theatre Manager.
      • If you do not see the API Token, in the Moneris Virtual Terminal go to Admin > Store Settings and the API Token will be displayed at the top of the page

      Note:The API Token above has been removed for security. Where the black square appears, a combination of upper-case and lower-case letters and numbers will comprise your store's API Token.

      Regenerate the API Token

      This process should only be undertaken in consultation with both Moneris Support and Arts Management Support. The API Token must match the Theatre Manager merchant account setup in order for credit card processing to work.

      Moneris Support may advise you to re-generate the API Token for your store in certain circumstances or for security reasons. It is done on the Admin->Store Settings page as shown below. You will be asked to click the Re-Generate API Token. If you are advised to do so, you will need to put that new token into the merchant account settings.

      Please contact support@artsman.com if you are unsure where to make this change within the Theatre Manager merchant account.

      Set eSelectplus to Manual Settlement

      By default, your eSelectplus account will be set to manually settle each night between 10 and 11PM Eastern time. You MUST CHANGE this option to manually settle which simplifies your end of day processing.

      To alter this setting:

      • Log into the eSelectplus Virtual Terminal
      • Go to Admin > Store Settings
      • Scroll down the page until you see the Batch Close selections
      • Change the radio button to the Manually Close option

      Direct Processing vs Hosted Payment

      Theatre Manager supports two Moneris processing options:
      • Moneris Gateway Account - where Theatre Manager sends a credit card provided to Moneris, receives the approval and is able to store the encrypted card (depends on PCI settings in company preferences). This option is used for box office credit card authorizations -and- for web sales with the benefit of supporting post dated credit card payments is using PCI schedule C.
      • Hosted Payment Page - this option can be used for web sales. Instead of accepting credit cards, the web interface passes control to the Moneris Hosted Payment Page, meaning that the customer is actually typing the card information directly into Moneris and Theatre Manager never sees it.

        Note that this same account needs e-select plus setup for settlement. It means box office can use the one merchant account for hosted payment online and normal credit card authorization at the box office.

      Moneris Gateway Account

      The User ID and Password setup is obtained from Moneris and is entered into the Setup --> System Tables --> Merchant Accounts window.

      Once the Moneris account has been activated and all the information in the following list has been obtained, the Merchant Account in Theatre Manager can be set up on each of the tabs that follow:

      • Server Software - Moneris (setting selected in TM)
      • Merchant Provider - Moneris (setting selected in TM)
      • Merchant Account Number - xxxxxxxxxx (from Moneris merchant services)
      • Store ID - xxxxxx (from Moneris merchant services)
      • API Token/Password - xxxxxxxxxx (from Moneris Online Portal store settings)
      • Primary URL for LIVE authorizations: - www3.moneris.com/gateway2/servlet/MpgRequest (typed into TM)
      • ECR Terminal ID - 66xxxx (from Moneris merchant services)

      Tabs with specific setup info are described in the following help pages. Other tabs like the Employees and Cards tabs are populated the same as described here.

      Moneris Gateway Account Software Tab

      On this tab, you will need to provide:
      • Server software - set to Moneris
      • Merchant Provider - set to Moneris
      • Merchant Number - is the Merchant Number from the document sent by Moneris

      Moneris Gateway Account Connection Info

      On this tab, you will need to provide:
      • Store ID - provided by Moneris on the setup information
      • API Token - obtained from the online Moneris portal
      • ECR Terminal ID - provided by Moneris on the setup information
      • Primary URL - should be populated for you and is www3.moneris.com/gateway2/servlet/MpgRequest
      • Port should be 443

      Moneris Gateway Account Authorization

      On the authorization tab, you will need to verify:
      • Send address/zip - verify the setting for this feature. At one time, Moneris does not provide AVS by default and it an account add-on. If a test authorization results in a no permissions for avs_info error, unchecking this box will eliminate the error since TM will no longer send AVS info.

      Moneris Hosted Payment Page

      A Moneris Hosted Payment Page is part of the Admin->Hosted PayPage config option.

      Hosted Payment Page option is used if you want Theatre Manager to switch over to the Moneris site for online credit card payments. It is possible to be SAQ A compliant for your web sales since the web site no longer takes credit cards (Moneris does).
      If you use hosted payments for web sales, you will also need an E-Select plus account for settlement. Box office sales can use this same merchant account and will automatically authorize against the e-select plus account. This means that you only need one merchant account set up even though it is processing via different pathways, one for web and one for box office.

      Setup Process

      The best process to configure this option is:

      • Obtain your online portal connection information from Moneris
      • Configure all the settings within the online portal
      • Use the Theatre Manager Merchant Account Setup for Moneris Hosted Payment Page
      • Test:
        • Authorizations through the TM Web services
        • Attempted Authorizations but Cancel through the TM Web services by going online to buy something (use test cards)
        • Verify the display on the web to see that it matches what ou picked in the online portal setup and shows your name and settings you wish
        • Voids from Theatre Manager
        • End of Day Settlement

      Online Portal Setup

      You will need to log into your Moneris online account. Once you are logged into the online account setup, select Admin->Hosted PayPage config option.

      You will see a screen similar to below.

      • If you see no lines in the list, click the Generate a New Configuration to make the following for Theatre Manager:
        • ps_store_id
        • hpp_key
      • If you see your ps_store_id in the list below, you can edit or verify information by proceeding to the next pages.

      Hosted Paypage Basic Configuration

      You will need to log into your Moneris online account. Once you are logged into the online account setup, select Admin->Hosted PayPage config option.

      Once you see your ps_store_id, click the 'Edit Button and you will see a screen similar to below.

       

      Data Setup

      Enter data into the window above per the instructions:

      If you change anything on this page, be sure to click Save Changes under this section.

      Hosted Paypage Appearance Configuration

      You will need to log into your Moneris online account. Once you are logged into the online account setup, select Admin->Hosted PayPage config option.

      Scroll down until you see a section that says Paypage Appearance and click Configure Appearance.

      A new window will open similar to below and the settings you place here control how the hosted payment page will appear to the patron.

      Appearance Configuration

      At the top are 3 buttons that are helpers for you:

      • Hex Colour Chart - which shows colours that can be placed into the 'Colours and styles' area. They are samples in a numeric format with examples. If you are familiar with setting colours of items on web pages, you can use any colour you wish.
      • Layout Sample - shows a picture of the various parts of the payment page that can be displayed
      • View Preview - will show what your payment page will look like after altering the settings. Our sample is to the right based on settings below

      Colours and Styles

      In this section, enter the colours for various parts of the payment page window. Use this to set colours as indicated.

      Hosted Paypage Data Fields

      Make settings as follows:

      • Display Item Details - uncheck. Theatre Manager does not send this information to Moneris
      • Display Customer Details - uncheck. Theatre Manager does not send this information to Moneris
      • Display Shipping Address Details - uncheck. Theatre Manager does not send this information to Moneris
      • Display Billing Address Details - uncheck. Theatre Manager does not send this information to Moneris
      • Enable input of Billing, Shipping, and extra fields - uncheck. Theatre Manager does not respond to this data if enabled
      • Display Merchant Name - Check this if you wish - it will display your merchant name from elsewhere in the Moneris config

      Buttons

      There should only be two things to set here:

      • Cancel Button Text - enter the words that you want to show to the user should they decide that they do not want to continue with authorization. Could be word like 'Cancel', 'Cancel Transaction','I Give up', 'Go Back to Cart', etc. Make sure and try an authorization so that you like what it says and that it is consistent with the behaviour of the window
      • Cancel Button URL - must be https://tickets.yourvenue.org/TheatreManager/payment/moneris/canceled where tickets.yourvenue.org is the URL to your ticketing web site

      Hosted Paypage Input Fields

      The settings are:

      • Display CVD Input (Credit Card Only) - we suggest checking this to allow input of the number on the back of the card
      • Display AVS Input (Credit Card Only) - (optional) check this to allow input of address info for address verification if you wish customers to provide it. It does not go to Theatre Manager
      • Postal Code Input Only) - (optional) if you want address verification, this restricts address input to the postal code only. its probably the preferred option for AVS checking

      Logos

      If you wish, you can click on the credit card logos that you accept. It simply displays the logo on the payment page.

      Hosted Paypage Response/Receipt Data

      You will need to log into your Moneris online account. Once you are logged into the online account setup, select Admin->Hosted PayPage config option.

      Scroll down until you see a section that says Response/Receipt Data and click Configure Response Fields.

      Response/Receipt Field Configuration

      Set the options as follows:

      • Return line item details - uncheck this, it is not used by Theatre Manager
      • Return shipping details - uncheck this, it is not used by Theatre Manager
      • Return billing details - uncheck this, it is not used by Theatre Manager
      • Return other customer fields - uncheck this, it is not used by Theatre Manager
      • Return ECI value - uncheck this, it is not used by Theatre Manager
      • Return the txn_number. - you MUST CHECK THIS as it can be used in Theatre Manager to void transactions
      • Return the VBV value - uncheck this, Verified by Visa is not used by Theatre Manager
      • Return Visa Debit card indicator - uncheck this, it is not used by Theatre Manager
      • Return AVS data - only CHECK THIS if you are wanting Moneris to check the postal code and you've allowed it as input on this screen
      • Encode carholder name - allows multi byte characters - you MUST CHECK THIS since Theate Manager understands unicode characters - allows customers to put accents in their names.
      • Automatically promptcardholder for a new card after a decline - check or uncheck this you wish

      Asynchronous Transaction Response

      Set the options as follows:

      Hosted Paypage Security Features

      You will need to log into your Moneris online account. Once you are logged into the online account setup, select Admin->Hosted PayPage config option.

      Scroll down until you see a section that says Response/Receipt Data and click Configure Response Fields.

      Referring URL

      • Leave all data blank

      Transaction Verification

      • Leave all data blank or unchecked

      Moneris Hosted Payment Email Receipts

      You will need to log into your Moneris online account. Once you are logged into the online account setup, select Admin->Hosted PayPage config option.

      Scroll down until you see a section that says Email Receipts and click Configure Email Receipts.

      Receipt Conditions

      Theatre Manager handles all confirmation of purchases to the patron. This section is not used, although, if you wish, you might want to send emails to the MERCHANT' for audit purposes.

      • Leave all data blank or unchecked.

      Receipt Appearance

      Theatre Manager handles the receipt to the patron.

      • Leave all data blank or unchecked

      Theatre Manager Setup

      The User ID and Password setup is obtained from Moneris and is entered into the Setup --> System Tables --> Merchant Accounts window.

      Once the Moneris account has been activated and all the information in the following list has been obtained, the Merchant Account in Theatre Manager can be set up on each of the tabs that follow:

      • Server Software - Moneris (setting selected in TM)
      • Merchant Provider - Moneris (Hosted Pay Page) (setting selected in TM)
      • Main Store Id - xxxxxxxxxx (provided by Moneris merchant services and used to login to Moneris online portal)
      • ps_store_id - xxxxxx (generated in Moneris online portal)
      • hpp_key - xxxxxx (generated in Moneris online portal)
      • Primary URL for LIVE authorizations - www3.moneris.com/gateway2/servlet/MpgRequest
      • ECR Number - 66xxxx (provided by Moneris on the setup information)
      • api_token - obtained from the Moneris online portal

      Tabs with specific setup info are described in the following help pages. Other tabs like the Employees and Cards tabs are populated the same as described here.

      Moneris Hosted Payment Software Type

      On this tab, you will need to provide:

      • Account Name - enter a description indicating that the purpose of this account is for Hosted Payments
      • Status - click to make it active, if not already
      • Enable Card Use by Web Listener - click to make it active, if not already. Hosted Payment Page can be used for online sales to try to be PCI Schedule A compliant
      • Server Software - Moneris (setting selected in TM)
      • Merchant Provider - Moneris (Hosted Pay Page) (setting selected in TM)
      • Main Store Id - xxxxxxxxxx (provided by Moneris merchant services and used to login to Moneris online portal)

      Moneris Hosted Payment Connection Info

      On this tab, you will need to provide:
      • ps_store_id - xxxxxx (generated in Moneris online portal)
      • hpp_key - xxxxxx (generated in Moneris online portal)
      • Authorization URL (Canada) - must be esplus.moneris.com/DPHPP/index.php
      • Authorization URL (USA) - must be www3.moneris.com/HPPDP/index.php
      • Port - must be 443
      • Settlement URL (Canada) - must be esqa.moneris.com/gateway2/servlet/MpgRequest
      • Settlement URL (USA) - must be esplus.moneris.com/gateway_us/servlet/MpgRequest
      • ECR Number - 66xxxx (provided by Moneris on the setup information)
      • api_token - obtained from the Moneris online portal

      The Web Experience

      It is very important to note that the credit card is being entered from the user's browser directly into the Moneris web site. This allows a venue to have:
      The checkout process for Hosted Payment is very similar to standard checkout processing for credit cards online. This shows and explains the subtle differences.

      Step 1 of the checkout process illustrates that most of the checkout window appears the same.

      The singular difference is that the credit card entry data is missing. Card entry shows up un step 3.

      Step 2 remains the same. The user can continue or go back.
      Step 3 shows an example of the actual hosted payment page.

      From step 2, the user's browser is directed to the Moneris web site where they enter:

      • postal/zip code for AVS
      • cardholder name
      • Card number
      • Expiry date
      • CVV2 #
      They also have the ability to:
      • Process the Transaction - which will process the card, and if accepted, move on to Step 4
      • Cancel Transaction - which will take the patron back to the shopping cart page in Theatre Manager web sales
      Step 4 remains the same.

      This shows the confirmation page where the user can use the print at home feature if enabled.

      Moneris Test Accounts

      Moneris has made some general purpose test accounts that you can use for setting up the Moneris Gateway Account and testing to ensure the connection is valid. Do not use these for a production environment as all authorizations sent here are for test only and ignored beyond that.

      These values are open for general testing from all sources - so you may see more than just your test transactions in the virtual gateway.
      They only work for the Moneris Gateway Account and will not work for Hosted Payment Page testing

      The following values will enable you to enter the test environment for the gateway:

      • Merchant Account Number 700000208782
      • Store ID store1
      • API Token/Password yesguy
      • Primary URL for TEST authorizations esqa.moneris.com/gateway2/servlet/MpgRequest
      • Port # 443
      • ECR Terminal ID 66002173

      Troubleshooting Moneris Account Setup

       

      Below are a list of some of the errors that may be encountered during processing using Moneris as a merchant provider:

       

      No Permissions For AVS_Info

       

      No Permissions For AVS_Info

      When the merchant account is setup in Theatre Manager and a test transaction is processed the error message above may appear. This error message is the result of missing options in the setup of the Merchant Account by Moneris. To correct the issue:

      • the Moneris representative will need to be contacted.
      • A request will need to be submitted to enable AVG and CID/CVV2 processing. This process can take up to 5 business days.
      • Additional Moneris account setup charges will apply for implementing these charges.
      The settings are mandatory in order to process credit cards using Theatre Manager.

       

      Moneris Returned A Response Code Of NULL

       

      Moneris Returned A Response Code Of NULL

      By default, when a merchant account is created in Theatre Manager it's set to send the patrons Address/Postal Code (Zip Code) with the credit card for verification. If the patron record does not contain an address this information is not available to send. Moneris is expecting data in these fields and thus sends but a response code of Null indicating the fields are empty. This error can be resolved in one of two ways. Address information can be made mandatory in the database or Address Verification can be turned off.

       

      Mandatory Address in Patron Records

      • Login to Theatre Manager as the Master User.
      • Click Setup >> System Preferences.
      • Select the Mandatory Data tab.
      • Check the boxes in Full Profile Patron Data for:
      • Patron Address
      • Patron Postal Code (Zip Code)
      • Click Save.

      An address and postal code (zip code) will now be required for all patron records added or updated in Theatre Manager.

       

      Turning Off Credit Card Address Verification

      • Click Setup >> System Tables >> Merchant Accounts.
      • Double click on the current Merchant Account to open it.
      • Select the Authorization tab.
      • Remove the check from Fraud Prevention >> Send address/zip.
      • Click Save.

      The Address and Postal Code (Zip Code) will no longer be sent with the credit card number for authorization.

       

      Transaction Not Allowed: ind_refund

       

      Transaction Not Allowed: ind_refund -5

      The Moneris account needs to be setup to process Independent Refunds in order to allow credit card refunds in Theatre Manager. Should Moneris detect suspicious activity on the account they will remove the option to process Independent Refunds to protect the account from fraud. To enable this feature once more the person who setup the Moneris account will need to contact them directly. A verbal request to enable Independent Refunds will need to be made and the following information well be required throughout the call:

      • Merchant Account Number
      • Full Business Address
      • Deposit Bank Name
      • Deposit Bank Account Number
      Once the request is complete a reference number will be provided. Moneris will telephone the contact person within a week to verify the account settings have been altered. Please make sure Moneris has the correct contact telephone number on file before completing the call.

       

      Authorize.net Installation

      Arts Management Systems provides the Authorize.net™ module to support credit card authorization. The installation is done for you on site by Arts Management training staff on any Theatre Manager Workstation.

      Authorize.net implements either user ID and password authentication over HTTPS connections to provide compliance with PCI DSS 4.1

      Please contact Arts Management to discuss the process of getting a Merchant Account from Authorize.net.

      After Authorize.net has provided you with a merchant account, installation is quite straightforward. Once set up, funds gets authorized as 'Card Not Present' and then deposited right to your own bank upon settlement from Theatre Manager. This account information you are provided is all you need in the merchant setup windows (in the pages that follow) to begin secure credit card authorization.

      Authorize.net needs one account set up for authorization and one for online viewing of the account data. You can set up multiple accounts for online access of the data, so some people can view data and others have more access to transactions and history.

      1. Authorize.net - uses the Merchant Portal via a web browser to "view the transactions" that have occurred. This account setup might need to be used during the End Of Day deposit process to verify transactions if you have more than 1000 authorizations between each End of Day.
      2. Merchant User ID and Password - uses Authorize.net to allow authorizations to occur and be settled but not be viewed. This information is what needs to be entered into Theatre Manager's Merchant account to allow authorizations to occur.

      The user IDs and passwords for both of the above are different and should not be interchanged or confused with each other. Follow the appropriate setup steps for each.

      After following the setup for both accounts, make sure to:
      • test the gateway
      • Make sure to fill out the refund form to allow refund processing.

        If you don't obtain that approval from Authorize.net, you can't refund to a credit card.

      Authorize.net Gateway Account

      The User ID and Password setup is arranged by Arts Management from Authorize.net and is entered into the Setup --> System Tables --> Merchant Accounts window as below:

      Software Type

      The following values are set on the software type tab per the diagram below:

      • Set the server software to be Authorize.net
      • The merchant provider will automatically be set for you
      • The merchant number is for use on ticket faces and for contacting Authorize.net support.

      Connection Info

      The following entries are set on the Connection Info tab per the diagram below:

      • User/Server ID - provided through Authorize.net. The user ID remains constant for the life of the account and is generally an MD5 version of your main account UserID
      • Password - the password is auto generated for you. You can change it via the online interface to generate a new 'secret' key. If you do that, you can expire your old password right away or allow both old and new to co-exist for up to 24 hours.
      • Primary URL - is always secure.authorize.net/gateway/transact.dll and is used for authorization only
      • Secondary URL - is always api.authorize.net/xml/v1/request.api and is used during the settlement process.
      • Port - is always 443

      Employee and Card Setup

      On the Merchant Setup window (see Account Setup), the final bit of setup is to determine which employees and which payment methods are associated with this merchant account.
      • To assign employees to this merchant account, click on the 'Employee' tab and find the employees to assign. In a multi-merchant setup situation, drag only those employees that will use this merchant account as the default.

        While some employees may have permission to use multiple merchant accounts, viewing their name here means this is the default merchant account assigned to them for charging cards. If the employee wants to use another merchant account, they will need to select it on the payment window.

      • Click on the 'Card' tab to select which credit card payment methods are associated with this merchant account.

        If you need to have multiple merchant accounts and both are to take Visa (for example), you will need two Visa payment methods and assign one of them to each merchant account.

      If you are switching from one merhcant provider to another merchant services provider software, you can open both merchant accounts and drag the employees from one window to the other. You can do the same for the credit card payment methods - to make the switch easy and fast.

      Any future dated 'post dated payments' associated with the card you drag to another merchant provider will automatically be reassigned to authorize on the new merchant provider card network.

      Testing Authorize.net

      After setting up the Authorize.net in the Merchant Account setup, you will need to test that it works. The best way to do this is:
      • Find yourself in the database or create a new patron for yourself
      • Create a new order and attempt to buy a ticket or Gift Certificate
      • On the payment window, select the credit card you want to use and do a test authorization
      • If you get an authorization with a message indicating AVS match and/or CVV2 match, then the setup is correct
      • Log in to your Online Merchant Account and view the batch to see that your transaction is there
      • In Theatre Manager, void the credit card payment and then confirm in the Online Merchant Account that the charge is marked as void
        • Trouble Shooting


          Authorization Response looks like HTML or XML

          If you get an authorization response that looks like it is HTML or XML and indicates that it was not authorized, then your User ID/Password is probably wrong (please verify it).

          If it still doesn't work after verifying it, log in to the Online Merchant Account and

          • Click on 'Account' button at the top.
          • Click on the MD5 hash at the middle of the screen
          • Get a new MD5 hash for your account and put it into the setup screen under the password
          • Try to authorize a card again


          Error on Settlement

          If an error occurs during the initial part of settlement, you may not have the 'Transaction Details API' enabled. If this occurs, log in to the Online Merchant account and then

          • Click on 'Account' button at the top.
          • Click on the 'Transaction Details API' link
          • Enter the answer to your 'secret question'
          • Click 'Enable Transaction Details API' button if it is not already enabled

          If issues persist, contact Arts Management and let us know so that we can help get it corrected.


          Authorization Number: 000000

          When processing a test charge, if you get an Authorization Number: 000000, this means the account is still in TEST mode at Authorize.net. Log into your Authorize.net account, and change the setting from TEST mode to LIVE mode.

      Specific Authorize.net Account Settings

      There are some specific settings that we recommend are made in the Authorize.net online interface, or applied for and added to your account to make daily processing easier on your staff members. These are:
      • Apply to Authorize.net to allow unrestricted refunds for your venue.
      • Enable transaction details so that Theatre Manager can obtain batch information and allow End of Day settlement.
      • Specify the sweep time where Authorize.net takes completed End of Day transactions and moves them to the bank.

      Authorize.net Address Verification Settings

      There are settings on the Authorize.net interface that need to be set up/changed - or you can get address mismatch or rejection issues. If you suddenly find you are getting a lot of rejections for credit card authorizations due to AVS errors, please verify your settings in the authorize.net portal.

      To set these parameters, you perform the following steps:

      1. Open your online gateway to Authorize.net and choose Account >> Settings.

        The main Settings window opens.

      2. In the Security Settings section, click on Address Verification Service.

        The following window displays.

      3. Ensure the following settings are enabled:

        General AVS Responses

        B - Transaction was submitted without a billing address
        E - AVS Data provided is invalid or AVS is not allowed for the card type used
        R - The AVS system was unavailable at the time of processing
        G - The card issuing bank is of non-US origin and does not support AVS.
        U - The address information for the cardholder is unavailable
        S - the US card bank does not support AVS

        Address and Zip Code Resources

        N
        A
        Z
        W
        Y
      4. When complete, your page will look like the following:

      Allowing refunds with Authorize.net

      In order to process refunds in a separate batch from the original transaction (which is how most refunds occur), clients will need to download Authorize.net's Expanded Credit Capabilities form:

      http://www.authorize.net/files/ecc.pdf

      Once the form is filled out, faxed back to Authorize.net, and processed by Authorize.net's customer support team, clients will be able to process refunds through Theatre Manager - sometimes within hours, sometimes up to 2 days later. The sure way to know is to check the status of your Expanded Credit Capabilities.

      To check the status of your Expanded Credit Capabilities, you can look directly within the gateway for your Authorize.net account.

      1. Go to the home page
      2. Click on the Merchant Profile link on the left hand side
      3. A series of settings will appear, including 'Additional Services.' The Expanded Credit Capabilities should read 'Enabled."

      This is only for processing refunds in a separate batch, after the End of Day deposit has been done for the original charge. In cases where the card is to be refunded before settlement, users should instead Void and Delete the payment in Theatre Manager. Then the tickets can be refunded to clear the order balance that will be created when the payment is voided. There is no additional setup required through Authorize.net in order to process voids.

      Refunds are processed immediately by Authorize.net. If you fail to settle a batch containing a refund before the Authorize.net sweep time, you will receive a warning during the End of Day that the batch may be out of balance (even if it is not).

      It is also important to note that the ECC form will allow users to run a refund in any amount to a card without matching up the refund amount to the original charge. Because of this, there are a couple of important considerations:

      • Clients may want to limit who can do refunds in Theatre Manager through their Employee Access settings.
      • Clients may also be cautious with whom the Virtual Gateway login and password is shared as users could run refunds directly from within that interface.

      Enabling Transaction Details API in order to settle during End of Day

      There is a setting inside the Authorize.net Virtual Terminal that will need to be enabled in order for Theatre Manager users to settle batches using the End of Day Wizard.
      1. Log into your Authorize.net account
      2. Select the Account button at the top right of the toolbar
      3. Choose Settings from the Menu at the left
      4. Select the Transaction Details API option under Security Settings
      5. You will be prompted to enter your secret question/answer that you set up when you created your account. Then click the Enable Transaction Details API button
      6. You will be taken back to the main Settings screen. To check that the settings have taken effect, go back to Transaction Details API
      7. When enabled, your screen shows you an option to Disable as below (do not do this).
      8. You will now be able to settle through the Theatre Manager End of Day Wizard. For more information about the Wizard, click here.

      Setting the Sweep Time for Settlement

      As explained here, Authorize.net sweeps (or settles) all transactions once a day to the client's bank account. This Sweep Time, or Transaction Cut-Off Time, is set directly in the Settings for the client's Authorize.net account.
      1. Sign in to the Authorize.net interface
      2. Choose the Virtual Terminal option at the left

      3. Choose the Transaction Cut-Off Time option under Business Settings.

      4. You'll see the current sweep or settlement time in the middle of the page (3:00 PM PDT in the example). Change the time using the drop down choices at the bottom of the page and click Submit. Our recommendation is to set this time sometime between 12AM and 4AM local time.

      Authorize.Net Troubleshooting

      If you are having issues with credit card authorization using authorize.net, there are a few things that can assist.

      Elavon (private) Installation

      The Elavon-Private Merchant account was written to process payments using Elavon as the processor and working in conjunction with an existing customized interface. This is only available to certain municipal organizations in Florida.

      This section of the online help contains details on how to configure a Merchant Account in Theatre Manager to process payments, refunds and settle a batch using this interface.

      The information that Theatre Manager requires from Elavon setup will be:

      • Agency ID: xxxxxxxxxx
      • Admin ID: xxxxxx
      • Password: xxxxxxxxxx
      • Primary URL for authorizations:
      • Port #: 443

      The Agency ID, Admin ID and password will be sent in a document from Elavon. That document will also contain instructions for you to log in to the Elavon online gateway to activate your account. The Primary URL should be obtained from the IT company that setup the customized interface.

      Elavon Gateway Setup

      The Elavon Merchant Account information is obtained from Elavon. The Primary URL will be provided by the IT company that created the custom interface. This information is entered into Theatre Manager under Setup >> System Tables >> Merchant Accounts.

       

      Software Type

      The following values are set on the Software Type tab per the diagram below:

      • Enter an Account Name for the Merchant Account.
      • The Status Active, At the Box Office and By the Web Listener boxes should all be checked.
      • Set the server software to be Elavon-Private.
      • The merchant provider will automatically be set to Elavon (NOVA).
      • The Agency ID is provided by Elavon and will need to go into the Agency ID field - enter in the Agency ID (not the merchant number) for the Elavon account which is typically 6 digits.

       

      Connection Info

      The following entries are set on the Connection Info tab per the diagram below:

      • An Admin ID will be provided by Elavon and is required to process refunds using this merchant account. This is a mandatory field in the Merchant Account Setup.
      • The Password is also provided by Elavon and is required to process refunds. This is a mandatory field in the Merchant Account Setup.
      • The IT company that created the customized interface will proved the Primary URL.
      • The Port will always be 443. Payments, refunds and batch settlement will all be processed using this port. Local work stations that need to process payments will need this port open for communication.

       

      Authorization

      For fraud prevention, Elavon accounts in Theatre Manager will be automatically set up to send address info and Track II data - just check to make sure the Authorization Tab matches the image below.

       

      The Employees and Cards Tabs are populated the same as described here.

       

      Activating your Elavon Payment Gateway

      This page is under construction

      USB Credit Card Swipes

      Theatre Manager supports using USB credit card swipes - which effectively are a replacement for keyboard input. The user swipes a credit card into the USB reader which translates it into keyboard input - exactly as if you typed the data.

      Installation is easy - just plug it into your computer.

      It works by reading the card information, including the track II information into Theatre Manager. Theatre Manager encrypts the credit card. It forwards the track II information to the credit card company and then promptly forgets about it - Track II data is never retained in Theatre Manager per PCI DSS requirements. A number of credit card companies use Track II information as proof that the cardholder is present and may adjust discount rates. Note also that they adjust rates for full address verification, CVV2 verification and other factors - making it equivalent to Track II authorization.

      All Service Providers operate as 'card not present' (except Moneris). That means Track II information is never send to them, even if the credit card is swiped using a USB reader. The card #, plus address and CVV2 are more important and will provide competitive discount rates. In this case, a USB swipe becomes only an efficiency tool for data entry rather than a need for proving card present.

      Moneris has the option of sending swiped information if you wish.

      Any computer that has a USB credit card reader OR a keyboard attached to should have limited ability to connect to the internet with direct access for browsing and/or strong virus protection

      This protection is to detect any 'bad actors' in viruses which are keystroke loggers. If your machine is infected, it will send every keystroke to the 'bad guys' and this is one easy way for them to compromise credit card information, one card at a time when they are entered.

      Schedule A/B/C/D Compliance - Self Assessment Questionnaire

      The Self Assessment Questionnaire (SAQ) is a self-validation tool for merchants who, because of transaction volume or other criteria, are not required to do on-site assessments for PCI DSS compliance. The SAQ includes a series of yes-or-no questions for compliance. If an answer is no, the organization must state the future remediation date and associated actions. In order to align more closely with merchants and their compliance validation process, the SAQ was revised and now allows for flexibility based on the complexity of a particular merchant’s or service provider’s business situation (see chart below). The SAQ validation type does not correlate to the merchant classification or risk level. Source: PCI 3.0 quick reference guide

      The PCI council has established 4 main levels for merchant compliance; schedules 'A', 'B','C' or 'D' with some variations at each level. You can use the table to the right to help determine the level that applies to your organization below.

       

      Compliance Summary

      Theatre Manager can achieve compliance for

      • schedule 'A' using Moneris Hosted Payment Page and only web sales with no card holder data storage
      • schedule 'B' or 'B-IP' if using pin pad machines for walk up and using Moneris Hosted Payment Page for web sales with no card holder data storage
      • schedule 'C' using a setting in System Preferences for venues processing cards through TM for both box office and e-comerce -and- no storage of card holder data
      • schedule 'D' using a setting in System Preferences for venues processing cards through TM for both box office and e-comerce -and- storing cardholder data for any purpose such as recurring transactions and post date payments.

       

      Compliance Levels

      The inherent nature of the ticketing business with a combination of walk up, phone and/or internet sales means that Theatre Manager (or any other ticketing system for that matter - hosted or non-hosted) probably results in Schedule 'C' or 'D' compliance when card data is stored. Per the table above, Schedule 'A' may be possible for venues using Moneris Hosted Payment Page and e-commerce only. Schedule 'B' may be possible if using point of sale terminals and no card holder data storage.

      • Schedule "A": means that credit card information is never touched, stored or processed within an organization. This is possible for organizations doing web sales using a hosted payment page (eg Moneris Hosted Payment Page. If phone or walk up ticket sales by credit card are entered to a pin pad terminal, it may allow you to stay at Schedule 'A' or move you to Schedule 'B' - please talk to your PCI assessor.
      • Schedule "B": could apply to merchants who only use point of sales terminals at box office and do not store any card data:
        • Schedule 'B' Those who do not use electronic processing and write credit card slips by hand apply to this level. Those that use stand alone DIAL UP terminals to process credit cards may also apply. DIAL UP means that the standalone POS terminal is not connected to a processor until an authorization is required. Not applicable to e-commerce channels.
        • Schedule 'B-IP' Merchants using only standalone, PTS-approved payment terminals with an IP connection to the payment processor, with no electronic cardholder data storage. Not applicable to e-commerce channels.
      • Schedule "C": means that Theatre Manager will render the cards useless by shredding them after use and never storing the data in the database (voids are done by sending a token, refunds may need the card entered again). If you do not want credit card information onsite, please select this option and select a merchant provider from one of the Direct Credit Card Processors.

        This also changes the scope of which part of the system is needs to be included for PCI reasons.

      • Schedule "D": means that you wish to store some or all credit card data using strong encryption for a period of time. Possible uses are for recurring credit card transaction for monthly donations, or the need to refund to a patron if they are displeased with the show. If you chose this option, you can also chose how long to store data for previously authorized cards. After this 'Retention Period', all credit cards are shredded doing a deposit (end of day process) unless still required for a future post dated payment, or it has been specifically marked as retain permanently under the patron record.

       

      Shredding Credit Cards

      Theatre Manager can implement either Schedule "C" or "D" for the SAQ - the choice is yours. You can define a retention period for credit card information in Theatre Manager on the System Preferences on the PCI Security Screen before it is 'shredded' per PCI DSS standard 3.1
      A card is stored in the database is only contained in one table/field called fCreditCards.CD_CARD_NO. There are no other permanent or temporary locations where it is stored. The card number can be removed using the shred feature. PCI DSS standard 3.1

      Notes:

      • A shredded card is stored in the database as '#### **** **** ####'. This renders the PAN useless for all purposes. However, if given the first 4 and last 4 digits of any card, you can still search for and find the patron who used a card starting and ending with those digits (the card, of course, will not exist in the database).
      • Schedule "D" compliance with about 120 days of retention is sufficient for most venues, especially if you are using post dated payments or may have to deal with refunds for cancelled events
      • Schedule "C" compliance means that no card information will every be stored in the database. It means cancellation of an event will need the customer service team to call a patron to get the card to process a refund, or to convert any refund to patrons to store credit such as a gift certificate.

      Reencrypting Credit Cards

      Credit cards stored in a database must be encrypted using a key that is distinct to the venue per PCI DSS standard 3.6. This must occur:
      • Immediately after the initial implementation and data conversion has taken place
      • on a minimum of an annual basis. If the procedure is not invoked manually, it will be done automatically during any upgrade.
      • if there is any suspected security breach at the organization
      It can be invoked manually by using a button on the System Preferences on the PCI Security Screen to re-encrypt cards.

      Adjusting Security Settings

      There are some settings in Theatre Manager that a venue must examine during installation and may need to be changed for PCI standard 8.5 compliance.

      If you are upgrading from a demo version of TM, some of these settings were optional to facilitate the purposes of a demo and need implemented for a production system.

      Minimum Password Settings for All Users

      For PCI compliance, a user MUST:
      • be required to enter a password to access Theatre Manager -and-
      • have their own user id and password to track access within the database -and-
      • ALSO have a unique logon to access the computer prior to accessing Theatre Manager that is PCI/DSS compliant.

      Ensure that the minimum recommended settings are met and increase the security as you see fit. If the minimum recommended settings change, Theatre Manager will automatically update the current settings to any more current minimum during any upgrade.

      The steps to increase security strength are:

      • Log in as Master User (this System Administrator account is only person with access to System Preferences)
      • go to 'Setup->System Preferences'
      • click on the 'Security' Tab. The minimum recommended settings are below.
      • Click on the 'Use PCI Card Industry Standards' to reset all password settings to the minimum acceptable standards.
      • Make any adjustments you wish to the policies such as requiring longer passwords, or increasing the minimum number of unique passwords before a repeat password can be used.
      • Close the window to save the changes.

      Changing User ID's

      (optional step)

      If you wish to implement login by user id in addition to password, the change all the user id's in the system to a scheme that is suited to your network security needs. Since you will be logging in with a User Id and Password, it can be a good idea to make user names more difficult to determine.

      To change user names and password settings, repeat the following steps for all users EXCEPT the Master User:

      • go to Setup->Users & Access->Employee List
      • Click the 'search' icon (the magnifying glass) or hit enter to see a list of users
      • Double click on the name in the list to change
      • Click on the 'Access' Tab
      • Click on the 'Access Id' field and change that to something suitable for the employee
      • Make sure the Logon Level selection is either 'No Access' if they are not allowed to use the system -or- 'Normal' if they are allowed to access the system.
      • If the user can log in, click the 'Set Password' button and assign them an initial random password (or have the user type in their own). It is not necessary to know or record each users password - in fact we recommend that you do not write those down. If a user forgets their password, you can always re-assign a new one here.
      • If user's access to parts of the system is similar to another users, you can use the 'Copy Access' button to make them like each other. You may wish to create a template for some of the important job functions that make copying easier.

      Verify Credit Card Access

      You must at least visit the 'Functions' tab and make sure that any of the privileges that say 'Credit Card' in the second column are all unchecked to start with. Then enable those that you wish the user to have. Creating any new normal user will default to a 'deny-all' setting per PCI DSS 7.2

      All existing users can be easily reset to the 'deny-all' at one button click (see below)

      Click on the 'Data' and 'Functions' tab and make any changes to the employee's access that you wish. To reset this employee to the standard 'deny-all' access to credit cards, click the lock on the toolbar. Two you may consider overriding relatively safely are:
      • 'Allow empty CID even if required for credit card payments'. If this is unchecked, the user must ask the customer for a CID/CVV2 number on the back of the credit card if it is required for the credit card type or by the processor. If your service provider does not accept or check CVV2 data, you may need to check this. You may also want to check this for at least one of the box office supervisory personnel who can then provide an operator over-ride to any other user if need be.
      • 'Able to Search for Patron using a card number'. This should be checked for a finance position or a box office supervisor so that a patron can be found when all we are given is the credit card number - such as in the case of charge backs. When searching for a patron by credit card, only the first 4 and last 4 digits in the care are required for a search.

      You can do reset all employees with non-administrative access at one time by selecting them all on the list of employees and clicking the 'PCI' button.

      Change the Master User Password

      There should only be one 'Master User' account.

      Per PCI requirements, this password for this account must be changed at the initial installation of Theatre Manager by the venue so that it is something unique to the venue.

      No user of Theatre Manager is required to have these privileges in order to use the system - except to create another user account. If any user is set as a Master User for the duration of the installation process, those privileges should be revoked per PCI compliance.

      • Find any user with Master User access using Setup->Employees and Access->Employee List
      • Click on the 'Access' tab
      • Make sure that the 'Logon Level' is 'Master User' for only one administrative account. Change all others to normal users.
      • Click 'Set Password' and give this special user a unique password. You will be asked to confirm the current password before you are allowed to change the password.
      • You may want to log out of theatre manager and then log back in as the special 'Master User' account before continuing - just to make sure you have the user id and password set.
      • This is one user id and password combination that you do wish to record on a paper and put in a sealed envelope in your safe with instructions to open under emergency only.

      PCI DSS Cross Reference/Index

      This section indicates where to find information about selected PCI DSS requirements in the Theatre Manager installation documentation. The purpose of this section is so that you can look at a PCI requirement and then view where in our implementation documentation this is referenced.

      The PCI Security Council supplies a document to merchants that provides a Prioritized Approach to PCI compliance. This document is quite good because it breaks down the standards into 6 milestones - what to do first, what to do second, etc. according to what will have the biggest impact in safeguarding your customer data.

      Following the document and this index should help you address that most important PCI implementation standards quickly.

      Source: PCI Prioritized Approach

      Build and Maintain a Secure Network

      In the past, theft of financial records required a criminal to physically enter an organization’s business site. Now, many payment card transactions (such as debit in the U.S. and “chip and pin” in Europe) use PIN entry devices and computers connected by networks. By using network security controls, organizations can prevent criminals from virtually accessing payment system networks and stealing cardholder data.

      Requirement 1: Install and maintain a firewall

      Install and maintain a firewall and router configuration to protect cardholder data

      Firewalls are devices that control computer traffic allowed between an entity’s networks (internal) and untrusted networks (external), as well as traffic into and out of more sensitive areas within an entity’s internal trusted networks. The cardholder data environment is an example of a more sensitive area within an entity’s trusted network.

      A firewall examines all network traffic and blocks those transmissions that do not meet the specified security criteria.

      All systems must be protected from unauthorized access from untrusted networks, whether entering the system via the Internet as e-commerce, employee Internet access through desktop browsers, employee e-mail access, dedicated connections such as business-to-business connections, via wireless networks, or via other sources. Often, seemingly insignificant paths to and from untrusted networks can provide unprotected pathways into key systems. Firewalls are a key protection mechanism for any computer network.

      Other system components may provide firewall functionality, provided they meet the minimum requirements for firewalls as provided in Requirement 1. Where other system components are used within the cardholder data environment to provide firewall functionality, these devices must be included within the scope and assessment of Requirement 1.

      Section PCI Requirement Comments
      1.1 Establish firewall and router configuration standards that formalize testing whenever configurations change; that identify all connections to cardholder data (including wireless); that use various technical settings for each implementation; and stipulate a review of configuration rule sets at least every six months. You will need a hardware router to protect your network.

      However, if you need to set up firewalls on computers themselves, the built in firewall on windows is very flexible. On OSX, do not manage the built in firewall via System Preferences on servers - instead, consider using a tool like Murus Firewall to unlock the power of the OSX PF firewall.

      1.1.1 A formal process for approving and testing all network connections and changes to the firewall and router configurations
       
      1.1.2 Current network diagram with all connections to cardholder data, including any wireless networks Refer to Recommended Network Diagram and adapt as neccessary
      1.1.3 Current diagram that shows all cardholder data flows across systems and networks Refer to cardholder flow
      1.1.4 Requirements for a firewall at each Internet connection and between any demilitarized zone (DMZ) and the internal network zone Refer to Apache Server setup to describe DMZ with one or two router situation.
      1.1.5 Description of groups, roles, and responsibilities for logical management of network components  
      1.1.6 Documentation and business justification for use of all services, protocols, and ports allowed, including documentation of security features implemented for those protocols considered to be insecure

      Examples of insecure services, protocols, or ports include but are not limited to FTP, Telnet, POP3, IMAP, and SNMP v1 and v2.

      Refer to Firewall rules for purpose of ports that are open.
      1.1.7 Requirement to review firewall and router rule sets at least every six months  
      1.2 Build a firewall configuration that denies all traffic from "untrusted" networks and hosts, except for protocols necessary for the cardholder data environment.

      Note: An "untrusted network" is any network that is external to the networks belonging to the entity under review, and/or which is out of the entity's ability to control or manage.

      Refer to Firewall rules to see the ports to open.
      1.2.1 Restrict inbound and outbound traffic to that which is necessary for the cardholder data environment.  
      1.2.2 Secure and synchronize router configuration files.  
      1.2.3 Install perimeter firewalls between any wireless networks and the cardholder data environment, and configure these firewalls to deny or control (if such traffic is necessary for business purposes) any traffic from the wireless environment into the cardholder data environment. refer to venue lan setup. Wireless is not to be used in the Theatre Manager LAN segment and should be setup carefully on another separate, isolated VLAN
      1.3 Prohibit direct public access between the Internet and any system component in the cardholder data environment.  
      1.3.1 Implement a DMZ to limit inbound traffic to only system components that provide authorized publicly accessible services, protocols and ports  
      1.3.2 Limit inbound Internet traffic to IP addresses within the DMZ.  
      1.3.3 Do not allow any direct connections inbound or outbound for traffic between the Internet and the cardholder data environment.  
      1.3.4 Implement anti-spoofing measures to detect and block forged source IP address from entering the network.

      (For example, block traffic originating from the internet with internal source addresses).

      Use commercial grade firewall
      1.3.5 Do not allow unauthorized outbound traffic from the cardholder data environment to the Internet. Implement specific permissions as per the firewall rules
      1.3.6 Implement stateful inspection, also known as dynamic packet filtering. (That is, only "established" connections are allowed into the network.) Use commercial grade firewall
      1.3.7 Place the components that store cardholder data (such as a database) in an internal network zone, segregated from the DMZ and other untrusted networks.  
      1.3.8 Do not disclose private IP addresses and routing information to unauthorized parties.

      Note: Methods to obscure IP addressing may include, but are not limited to:

      • Network Address Translation (NAT)
      • Placing servers containing cardholder data behind proxy servers/firewalls or content caches
      • Removal or filtering of route advertisements for private networks that employ registered addressing
      • Internal use of RFC1918 address space instead of registered addresses.
       
      1.4 Install personal firewall software on any mobile and/or employee-owned computers that connect to the Internet when outside the network (for example, laptops used by employees), and which are also used to access the organization's network.

      Firewall configurations include:

      • Specific configuration settings are defined for personal firewall software
      • Personal firewall software is actively running
      • Personal firewall software is not alterable by users of mobile and/or employee-owned devices.
      These days, alll computers have one - it just needs enabled.
      1.5 Ensure that security policies and operational procedures for managing firewalls are documented, in use, and known to all affected parties.  

      Requirement 2: Change Vendor Passwords

      Requirement 2: Do not use vendor-supplied defaults for system passwords and other security parameters

      The easiest way for hackers to access your internal network is to try default passwords or exploits based on default system software settings in your payment card infrastructure. Far too often, merchants do not change default passwords or settings when they deploy the software. This is the same as leaving your store physically unlocked when you go home for the night. Default passwords and settings for most network devices are widely known. This information, combined with hacker tools showing them what devices are on your network, can make unauthorized entry a simple task – if you have failed to change the defaults.

      Section PCI Requirement Comments
      2.1 Always change vendor-supplied defaults and remove or disable unneccessary default accounts before installing a system on the network

      This applies to ALL default passwords, including but not limited to those used by operating systems, software that provides security services, application and system accounts, point-of-sale (POS) terminals, Simple Network Management Protocl (SNMP), community strings, etc.

      Change the Master User password when setting up the system.

      Change any other vendor supplied passwords as described.

      2.1.1 For wireless environments connected to the cardholder data environment or transmitting cardholder data, change ALL wireless vendor defaults at installation, including but not limited to default wireless encryption keys, passwords, and SNMP community strings. Theatre Manager does NOT needs wifi for operation. Refer to venue lan setup for network diagram and what to do when placing wireless devices is a separate VLAN
      2.2 Develop configuration standards for all system components. Assure that these standards address all known security vulnerabilities and are consistent with industry-accepted hardening standards.

      Sources of industry-accepted system hardening standards may include, but are not limited to:

      Arts Management regularly reviews industry information and implements the latest components and security patches in installers as soon as possible.
      2.2.1 Implement only one primary function per server to prevent functions that require different security levels from co-existing on the same server. For example, web servers, database servers and DNS servers should be on separate servers.

      Note: Where virtualization technologies are in use, implement only one primary function per virtual system component.

      Refer to Network Diagram for components. Also, refer to postgres setup on windows servers
      2.2.2 Enable only necessary and secure services, protocols, daemons, etc., as required for the function of the system. refer to Disable SNMP service on Practical Automation Ticket Printers
      2.2.3

      Implement additional security features for any required services, protocols, or daemons that are considered to be insecure—for example, use secured technologies such as SSH, S-FTP, TLS, or IPSec VPN to protect insecure services such as NetBIOS, file-sharing, Telnet, FTP, etc.

      Note: SSL and early TLS are not considered strong cryptography and cannot be used as a security control after June 30, 2016. Prior to this date, existing implementations that use SSL and/or early TLS must have a formal Risk Mitigation and Migration Plan in place.

      Effective immediately, new implementations must not use SSL or early TLS.

      POS POI terminals (and the SSL/TLS termination points to which they connect) that can be verified as not being susceptible to any known exploits for SSL and early TLS may continue using these as a security control after June 30, 2016.

      The Apache Server config disables all SSL protocols and enables only TLS 1.2

      Theatre Manager will connect to service providers using the latest TLS that they support and have been verified to connect via TLS 1.2 when available.

      2.2.4 Configure system security parameters to prevent misuse  
      2.2.5 Remove all unnecessary functionality, such as scripts, drivers, features, subsystems, file systems, and unnecessary web servers.  
      2.3 Encrypt all non-console administrative access such as browser/web-based management tools. Use technologies such as SSH, VPN, or TLS for web-based management and other non-console administrative access. Theatre manager does not provide or require web based management tools

      We suggest that customer use RDC, Teamviewer or equivalent internally for remote access management.

      and that strong security be implemented similar to the password requirements for PCI compliance and use of SSH or VPN's for conection
      2.4 Maintain an inventory of system components that are in scope for PCI DSS For Theatre Manager, this includes You may need to include other point of sale terminals that you obtained from your bank.
      2.5 Ensure that security policies and operational procedures for managing vendor defaults and other security parameters are documented, in use, and known to all affected parties.  
      2.6 Shared hosting providers must protect each entity's hosted environment and cardholder data. These providers must meed specific requirements as detailed in Appendix A: "Additional PCI DSS Requirements for Shared Hosting Providers." Not Applicable. Theatre Manager is not typically installed in a shared environment.

      Protect Cardholder Data

      Cardholder data refers to any information printed, processed, transmitted or stored in any form on a payment card. Organizations accepting payment cards are expected to protect cardholder data and to prevent their unauthorized use – whether the data is printed or stored locally, or transmitted over a public network to a remote server or service provider.

      Requirement 3: Protect stored cardholder data

      Protect stored cardholder data

      Protection methods such as encryption, truncation, masking, and hashing are critical components of cardholder data protection. If an intruder circumvents other security controls and gains access to encrypted data, without the proper cryptographic keys, the data is unreadable and unusable to that person. Other effective methods of protecting stored data should also be considered as potential risk mitigation opportunities. For example, methods for minimizing risk include not storing cardholder data unless absolutely necessary, truncating cardholder data if full PAN is not needed, and not sending unprotected PANs using end-user messaging technologies, such as e-mail and instant messaging.

      Please refer to the PCI DSS and PA-DSS Glossary of Terms, Abbreviations, and Acronyms for definitions of “strong cryptography” and other PCI DSS terms.

      Section PCI Requirement Comments
      3.1 Keep cardholder data storage to a minimum by implementing data retention and disposal policies, procedures and processes that include at least the following for all card holder data (CHD) storage:
      • Limiting data storage amount and retention time to that which is required for legal, regulatory, and/or business requirements
      • Specific retention requirements for cardholder data
      • Processes for secure deletion of data when no longer needed
      • A quarterly automatic or manual process for identifying and securely deleting stored cardholder data that exceeds defined retention requirements
      Theatre Manager provides automatic retention and shredding capability which removes stale card information based on a retention period and/or usage for recurring transactions.

      There is an option to never store card information allowing a venue to implement either Schedule C or D compliance.

      We suggest card retention period of 180 days to handle time from sale to attending a show.

      Post dated payments cause a card to be retained until the last automatic payment is processed.

      3.2

      Do not store sensitive authentication data after authorization (even if it is encrypted). If sensitive authentication data is received, render all data unrecoverable upon completion of the authorization process

      Sensitive authentication data includes the data as cited in the following requirements 3.2.1 through 3.2.3

      Refer to PCI compliance statement on PAN etc.

      Theatre Manager offers an option to search the database for possible entry of credit card numbers in non-payment text fields.

      3.2.1

      Do not store the full contents of any track (from the magnetic stripe located on the back of a card, contained in a chip, or elsewhere). This data is alternatively called full track, track, track 1, track 2, and magnetic-stripe data.

      Note: in the normal course of business, the following data elements fro mthe magnetic stripe may need to be retained:

      • The cardholders name
      • Primary account number (PAN)
      • Expiration Date
      • Service Code
      To minimize risk, store only these data elements as needed for business
      If a card is swiped, the only information retained from the swipe are the following
      • The cardholders name
      • Card number (PAN), encrypted
      • Expiration Date
      3.2.2 Do not store the card-verification code or value (three-digit or four- digit number printed on the front or back of a payment card used to verify card-not-present transactions) after authorization Theatre Manager does not store this data to disk under any circumstances - it is merely passed through to the credit card authorizer.
      3.2.3 Do not store the personal identification number (PIN) or the encrypted PIN block. Theate Manager does not support entry of PIN.
      3.3

      Mask PAN when displayed (the first six and last four digits are the maximum number of digits to be displayed), such that only personell with a legitimate busines need can see the full PAN.

      Note: this requirement does not supercede stricter requirements in place for displays of cardholder data - for example, legal or payment card rand requirements for point-of-sale (POS) receipts

      Theatre Manager follows these rules. Card numbers are displayed as last four digits only and is only revealed if employee has permission - in which case it is logged.

      All reports and most windows mask PAN

      External receipt printing or web interface uses a common routine to mask the PAN immediately upon retrieval from the database so that last 4 digits only are displayed per law in most states.

      3.4 Render PAN, at minimum, unreadable anywhere it is stored (including on portable digital media, backup media, in logs) by using any of the following approaches:
      • One-way hashes based on strong cryptography
      • Truncation (hashing cannot be used to replace the truncated segment of the PAN)
      • Index tokens and pads (pads must be securely stored)
      • Strong cryptography with associated key management processes and procedures
      Note: it is a relatively trivial effort for a malicious individual to reconstruct original PAN data if they have access to the truncated and hashed version of a PAN.
      Theatre Manager uses secure high encryption for all keys and card data.
      3.4.1 If disk encryption is used (rather than file- or column-level database encryption), logical access must be managed independently of native operating system authentication and access control mechanisms (for example, by not using local user account databases or general network login credentials). Decryption keys must not be associated with user accounts.

      Theatre Manager does not use Disk Encryption.

      It uses field level encryption for PAN.

      3.5

      Document and implment procedures to protect keys used to secure stored cardholer data against disclosure and misuse.

      Note: this requirement applieds to keys used to encrypt stored cardholder data, and also applies to key-encrypting keys used to protect data encrypting keys. Such key encrypting keys must be at least as strong as the data-encrypting key.

      Theatre Manager handles creation and hiding of keys automatically. The user never sees them and cannot input them.

      Key encryption keys use same cryptographic specification as the encryption keys.

      3.5.1 Restrict access to cryptographic keys to the fewest number of custodians necessary
      3.5.2

      Store secret and private keys used to encrypt/decrypt cardholder data in one (or more) of the following forms at all times:

      • Encrypted with a key-encrypting key that is at least as strong as the data-encrypting key, and that is stored separately from the data- encrypting key
      • Within a secure cryptographic device (such as a hardware (host) security module (HSM) or PTS- approved point-of-interaction device)
      • As at least two full-length key components or key shares, in accordance with an industry- accepted method
      3.5.3

      Store crpytographic keys in the fewest possible locations

      3.6

      Fully document and implement all key management processes and procedures for cryptographic keys used for encryption of cardholder data including the following:

      refer to re-encryption of credit cards for discussion on keys, generation and re-encryption. Any upgrade will automatically perform this process if more than 300 days have elapsed since last re-encrption.

      Split 'knowledge' of the keys is achieved by bringing together a key generated programatically and another portion generated by the customers interfacing with the key creation screen in system preferences.

      Both keys are required to generate the final encryption key. Arts Management never has knowledge of the customers portion of the key. The customer never knows the value of any key. A key valid for one database for a period of time will not work on any other database.

      Old keys are securely deleted from the database by writing over the key value and then deleting it immediately after a new seed key is generated.

      3.6.1 Generation of strong cryptographic keys
      3.6.2 Secure cryptographic key distribution
      3.6.3 Secure cryptographic key storage
      3.6.4

      Cryptographic key changes for keys that have reached the end of their cryptoperiod (for example, after a defined period of time has passed and/or after a certain amount of cipher- text has been produced by a given key), as defined by the associated application vendor or key owner, and based on industry best practices and guidelines (for example, NIST Special Publication 800-57).

      3.6.5

      Retirement or replacement (for example, archiving, destruction, and/or revocation) of keys as deemed necessary when the integrity of the key has been weakened (for example, departure of an employee with knowledge of a clear-text key component), or keys are suspected of being compromised.

      3.6.6

      If manual clear-text cryptographic key management operations are used, these operations must be managed using split knowledge and dual control

      for example, requiring two or three people, each knowing only their own key component, to reconstruct the whole key.

      3.6.7 Prevention of unauthorized substitution of cryptographic keys
      3.6.8 Requirement for cryptographic key custodians to sign a form stating that they understand and accept their key-custodian responsibilities

      Venues do not know the cryptographic key.

      However, they should have a form signed by the people/person responsible for key management that they reset the key once a year at a minimum or when suspected compromise occurs. Note it will be changed automatically on you during an upgrade if Theatre Manager detects it hasn't been changed for 300 days.

      3.7

      Ensure that security policies and operational procedures for protecting stored cardholder data are documented, in use, and known to all affected parties.

       

      Requirement 4: encrypt transmission of cardholder data

      Encrypt transmission of cardholder data across open, public networks

      Sensitive information must be encrypted during transmission over networks that are easily accessed by malicious individuals. Misconfigured wireless networks and vulnerabilities in legacy encryption and authentication protocols continue to be targets of malicious individuals who exploit these vulnerabilities to gain privileged access to cardholder data environments.

      Section PCI Requirement Comments
      4.1 Use strong cryptography and security protocols (for example, TLS, IPSEC, SSH, etc.) to safeguard sensitive cardholder data during transmission over open, public networks, including the following:
      • Only trusted keys and certificates are accepted.
      • The protocol in use only supports secure versions or configurations.
      • The encryption strength is appropriate for the encryption methodology in use

      Examples of open, public networks that are in scope of the PCI DSS include but are not limited to:

      • The Internet
      • Wireless technologies including 802.11 and Bluetooth
      • Global System for Mobile communications (GSM)
      • General Packet Radio Service (GPRS).
      • Satellite communications
      See Direct Card Processing which all use HTTPS.

      Theatre Manager uses TLS 1.2 wherever possible to connect to credit card authorization servers for one time authorization and only allows TLS 1.2 or later for incomming web sales.

      Theatre Manager does not use any wireless communication methodologies of any form.

      Theatre Manager does not transmit any credit card information across public networks for any reason except in the process of authorization

      4.1.1 Ensure wireless networks transmitting cardholder data or connected to the cardholder data environment, use industry best practices (for example, IEEE 802.11i - aka WPA2) to implement strong encryption for authentication and transmission.

      Note: The use of WEP as a security control is prohibited.

      Theatre Manager does not use or require wireless capability when transmitting any card data. Refer to venue lan setup and considerations for separate wireless access points
      4.2 Never send unprotected PANs by end-user messaging technologies (for example, e-mail, instant messaging, chat, etc.). see misc PCI requirements
      4.3 Ensure that security policies and operational procedures for encrypting transmissions of cardholder data are documented, in use, and known to all affected parties. Venues are advised during installation of this requirement.

      Maintain a vulnerability Management Program

      Vulnerability management is the process of systematically and continuously finding weaknesses in an organization’s payment card infrastructure system. This includes security procedures, system design, implementation, or internal controls that could be exploited to violate system security policy.

      Requirement 5: Use and regularly update anti-virus software

      Protect all systems against malware and regularly update anti-virus software or programs

      Malicious software, commonly referred to as “malware”—including viruses, worms, and Trojans—enters the network during many business- approved activities including employee e-mail and use of the Internet, mobile computers, and storage devices, resulting in the exploitation of system vulnerabilities. Anti-virus software must be used on all systems commonly affected by malware to protect systems from current and evolving malicious software threats. Additional anti-malware solutions may be considered as a supplement to the anti-virus software; however, such additional solutions do not replace the need for anti-virus software to be in place.

      Section PCI Requirement Comments
      5.1 Deploy anti-virus software on all systems commonly affected by malicious software (particularly personal computers and file servers). See specifics for
      5.1.1 Ensure that all anti-virus programs are capable of detecting, removing, and protecting against all known types of malicious software. You must keep your anti-virus software up to date with latest definitions
      5.1.2 For systems considered to be not commonly affected by malicious software, perform periodic evaluations to identify and evaluate evolving malware threats in order to confirm whether such systems continue to not require anti-virus software.

      For Theatre Manager database and TM server, ensure those processes are the only thing running on the machine. Keep them separate from a domain server to limit who can actually log in to the server.

      Check with the vendor of other systems in use.

      5.2 Ensure that all anti-virus mechanisms are maintained as follows:  
      5.3 Ensure that anti-virus mechanisms are actively running and cannot be disabled or altered by users, unless specifically authorized by management on a case-by-case basis for a limited time period.

      Note: Anti-virus solutions may be temporarily disabled only if there is a legitimate technical need, as authorized by management on a case-by-case basis. If anti-virus protection needs to be disabled for a specific purpose, it must be formally authorized. Additional security measures may also need to be implemented for the period of time during which anti-virus protection is not active.

       
      5.4 Ensure that security policies and operational procedures for protecting systems against malware are documented, in use, and known to all affected parties.  

      Requirement 6: Develop and maintain secure systems and applications

      Develop and maintain secure systems and applications

      Unscrupulous individuals use security vulnerabilities to gain privileged access to systems. Many of these vulnerabilities are fixed by vendor-provided security patches, which must be installed by the entities that manage the systems. All systems must have all appropriate software patches to protect against the exploitation and compromise of cardholder data by malicious individuals and malicious software.

      Note: Appropriate software patches are those patches that have been evaluated and tested sufficiently to determine that the patches do not conflict with existing security configurations. For in-house developed applications, numerous vulnerabilities can be avoided by using standard system development processes and secure coding techniques.

      Section PCI Requirement Comments
      6.1 Establish a process to identify security vulnerabilities, using reputable outside sources for security vulnerability information, and assign a risk ranking (for example, as 'high', 'medium', or 'low') to newly discovered security vulnerabilities.

      Note: Risk rankings should be based on industry best practices as well as consideration of potential impact. For example, criteria for ranking vulnerabilities may include consideration of the CVSS base score, and/or the classification by the vendor, and/or type of systems affected.

      Methods for evaluating vulnerabilities and assigning risk ratings will vary based on an organization's environment and risk- assessment strategy. Risk rankings should, at a minimum, identify all vulnerabilities considered to be a "high risk" to the environment. In addition to the risk ranking, vulnerabilities may be considered "critical" if they pose an imminent threat to the environment, impact critical systems, and/or would result in a potential compromise if not addressed. Examples of critical systems may include security systems, public-facing devices and systems, databases, and other systems that store, process, or transmit cardholder data.

       
      6.2 Ensure that all system components and software are protected from known vulnerabilities by installing applicable vendor supplied security patches. Install critical security patches within one month of release.

      Note: Critical security patches should be identifies according to the risk ranking process defined in requirement 6.1

      There are two settings in Company Preferences Other Tab that enable:
      • checking daily for updates to TM processes and/or
      • automatically update affected components (optional).
      You may need to enable a specific outbound ports for update checking to www2.artsman.com.

      Refer to the list of past and present issues to assist you updating your own vulnerability assessment.

      We regularly review Postgres, Apache & OpenSSL to provide the latest patches in each version our installers.

      6.3 Develop internal and external software application (including web-based administrative access to applications) securely, as follows:
      • in accordance with PCI DSS (for example, secure authentication and logging)
      • based on industry standard and/or best practices.
      • Incorporating information security throughout the software development life cycle.

      Note: this applies to all software developed internaly as well as bespoke or custom software developed by a third party.

       
      6.3.1 Remove development, test and/or custom application accounts, user IDs, and passwords before applications become active or are released to customers.  
      6.3.2 Review of custom code prior to release to production or customers in order to identify any potential coding vulnerability (using either manual or automated processes) to include at least the following:
      • Code changes are reviewed by individuals other than the originating code author, and by individuals knowledgeable about code-review techniques and secure coding practices
      • Code reviews ensure code is developed according to secure coding guidelines
      • Appropriate corrections are implemented prior to release
      • Code-review results are reviewed and approved by management prior to release
       
      6.4 Follow change control procedures for all changes to system components. The procedures must include the following:  
      6.4.1 Separate development/test and production environments and enforce the separaton with access controls  
      6.4.2 Separation of duties between development/test and production environments  
      6.4.3 Production data (live PANs) are not used for testing or development Only specified test cards are used
      6.4.4 Removal of test data and accounts before production systems become active  
      6.4.5 Change control procedures for the implementation of security patches and software modifications. Procedures must include the following:  
      6.4.5.1 Documentation of impact  
      6.4.5.2 Documented change approval by authorized parties.  
      6.4.5.3 Functionality testing to verify that the change does not adversely impact the security of the system.  
      6.4.5.4 Back-out procedures. Development uses git and branches so that changes can be reverted.
      6.5 Address common coding vulnerabilities in software development process as follows:
      • Train developers in secure coding techniquies, including how to avoid common coding vulnerabilities, and understanding how sensitive data is handled in memory
      • Develop applications based on secure coding guidelines

      Note: The vulnerabilities listed at 6.5.1 through 6.5.10 were current with industry best practices when this version of PCI DSS was published. However, as industry best practices for vulnerability management are updated (for example, the OWASP Guide, SANS CWE Top 25, CERT Secure Coding, etc.), the current best practices must be used for these requirements.

      Refer to Current OWASP Top 10
      6.5.1 Injection flaws, particularly SQL injection. Also consider OS Command Injection, LDAP and XPath injection flaws as well as other injection flaws
      6.5.2 Buffer overflow
      6.5.3 Insecure cryptographic storage
      6.5.4 Insecure communications
      6.5.5 Improper error handling
      6.5.6 All 'high risk' vulnerabilities identified in the vulnerability identification process (as defined in PCI DSS Requirement 6.1).
      6.5.7 Cross-site scripting (XSS)
      6.5.8 Improper Access Control (such as insecure direct object references, failure to restrict URL access, directory traversal, and failure to restrict user access to functions)
      6.5.9 Cross-site request forgery (CSRF) TM server ensures all <form> have CSRF token for prevention.
      6.5.10 Broken authentication and session management Theatre Manager web services uses encrypted secure cookies that are httpd-only.
      6.6 For public-facing Web applications, address new threats and vulnerabilities on an ongoing basis and ensure these applications are protected against known attacks by either of the following methods:
      • Reviewing public-facing Web applications via manual or automated application vulnerability security assessment tools or methods, at least annually and after any changes
      • Installing an automated technical solution that detects and prevents web-based attacks (for example web-application firewall) in front of public-facing web applications, to continually check traffic

      AMS updates Apache as needed (and config settings) to respond to newly reported threats.

      AMS uses SPI for all web traffic internally.

      6.7 Ensure that security policies and operational procedures for developing and maintaining secure systems and applications are documented, in use, and known to all affected parties.  

      Implement Strong Access Control Measures

      Access control allows merchants to permit or deny the use of physical or technical means to access PAN and other cardholder data. Access must be granted on a business need-to-know basis. Physical access control entails the use of locks or restricted access to paper-based cardholder records or system hardware. Logical access control permits or denies use of PIN entry devices, a wireless network, PCs and other devices. It also controls access to digital files containing cardholder data.

      Requirement 7: Restrict access to cardholder data

      Restrict access to cardholder data by business need-to-know

      To ensure critical data can only be accessed by authorized personnel, systems and processes must be in place to limit access based on need-to-know and according to job responsibilities.

      Need-to-know is when access rights are granted to only the least amount of data and privileges needed to perform a job.

      Section PCI Requirement Comments
      7.1 Limit access to system components and cardholder data to only those individuals whose job requires such access.  
      7.1.1 Define access needs for each role, including:
      • System components and data resources that each role needs to access for their job function
      • Level of privilege required (for example, user, administrator, etc.) for accessing resources
       
      7.1.2 Restrict access to privileged user IDs to least privileges necessary to perform job responsibilities.  
      7.1.3 Assign access based on individual personnel's job classification and functions  
      7.1.4 Require documented approval by authorized parties specifying required privileges  
      7.2 Establish an access control system for systems components that restricts access based on a user's need to know, and is set to "deny all" unless specifically allowed.

      This access control system must include the following:

       
      7.2.1 Coverage of all system components Refer to employee settings and function access for credit cards
      7.2.2 Assignment of privileges to individuals based on job classification and function
      7.2.3 Default "deny-all" setting
      7.3 Ensure that security policies and operational procedures for restricting access to cardholder data are documented, in use, and known to all affected parties.  

      Requirement 8: Assign a unique ID to each person

      Assign a unique ID to each person with computer access

      Assigning a unique identification (ID) to each person with access ensures that each individual is uniquely accountable for their actions. When such accountability is in place, actions taken on critical data and systems are performed by, and can be traced to, known and authorized users and processes.

      The effectiveness of a password is largely determined by the design and implementation of the authentication system—particularly, how frequently password attempts can be made by an attacker, and the security methods to protect user passwords at the point of entry, during transmission, and while in storage.

      Note:

      • These requirements are applicable for all accounts, including point-of-sale accounts, with administrative capabilities and all accounts used to view or access cardholder data or to access systems with cardholder data. This includes accounts used by vendors and other third parties (for example, for support or maintenance).
      • However, Requirements 8.1.1, 8.2, 8.5, 8.2.3 through 8.2.5, and 8.1.6 through 8.1.8 are not intended to apply to user accounts within a point-of- sale payment application that only have access to one card number at a time in order to facilitate a single transaction (such as cashier accounts).

      Section PCI Requirement Comments
      8.1 Define and implement policies and procedures to ensure proper user identification management for non- consumer users and administrators on all system components as follows: Theatre Manager implements PCI standards. You may need a manual process for other applications or hardware.
      8.1.1 Assign all users a unique ID before allowing them to access system components or cardholder data.  
      8.1.2 Control addition, deletion, and modification of user IDs, credentials, and other identifier objects.  
      8.1.3 Immediately revoke access for any terminated users.  
      8.1.4 Remove/disable inactive user accounts within 90 days. Refer to the PCI Security Tab in System Preferences for settings. Theatre Manager enforces stronger password policies than the minimum PCI standards.
      8.1.5 Manage IDs used by vendors to access, support, or maintain system components via remote access as follows:
      • Enabled only during the time period needed and disabled when not in use.
      • Monitored when in use.
      Theatre Manager uses Teamviewer for one-time access, granted as needed.
      8.1.6 Limit repeated access attempts by locking out the user ID after not more than six attempts. Theatre Manager limits incorrect password attempts to a total of 6 since the last successful attempt and locks out the account on failure.
      8.1.7 Set the lockout duration to a minimum of 30 minutes or until an administrator enables the user ID. Lockout duration in Theatre Manager is permanent. Locked out employee must be re-instated by administrator.
      8.1.8 If a session has been idle for more than 15 minutes, require the user to re-authenticate to re-activate the terminal or session. Theatre Manager logs out the user after inactivity. In addition to the feature built into Theatre Manager for auto log out, you are encouraged to use the screen saver provisions that require passwords after the screen saver is activated.
      8.2 In addition to assigning a unique ID, ensure proper user-authentication management for non-consumer users and administrators on all system components by employing at least one of the following methods to authenticate all users:
      • Something you know, such as a password or passphrase
      • Something you have, such as a token device or smart card, specific IP, key access to a locked room
      • Something you are, such as a biometric
       
      8.2.1 Using strong cryptography, render all authentication credentials (such as passwords/phrases) unreadable during transmission and storage on all system components. Passwords are never transmitted in clear text when logging on to the database.
      8.2.2 Verify user identity before modifying any authentication credential—for example, performing password resets, provisioning new tokens, or generating new keys. Only administrators are able to reset a password, reinstate an employee and/or regenerate credit card encryption keys.
      8.2.3 Passwords/phrases must meet the following:
      • Require a minimum length of at least seven characters.
      • Contain both numeric and alphabetic characters. Alternatively, the passwords/phrases must have complexity and strength at least equivalent to the parameters specified above.
      Theatre Manager enforces
      • Minimum 7
      • One upper
      • One lower
      • One numeric
      • One Special
      • No repeated characters
      8.2.4 Change user passwords/passphrases at least once every 90 days. Theatre Manager enforces this
      8.2.5 Do not allow an individual to submit a new password/phrase that is the same as any of the last four passwords/phrases he or she has used. Theatre Manager enforces 12
      8.2.6 Set passwords/phrases for first- time use and upon reset to a unique value for each user, and change immediately after the first use. Theatre Manager enforces change of password at time of login for first time users
      8.3 Incorporate two-factor authentication for remote network access originating from outside the network by personnel (including users and administrators) and all third parties, (including vendor access for support or maintenance).

      Note: Two-factor authentication requires that two of the three authentication methods (see Requirement 8.2 for descriptions of authentication methods) be used for authentication. Using one factor twice (for example, using two separate passwords) is not considered two-factor authentication.

      Examples of two-factor tehcnologies include remote authentication and dial-in service (RADIUS) with tokens; terminal access controller access control system (TACACS) with tokens, and other technologies that facilitate two-factor authentication.

      Two factor authentication means something you know and something you are given. Our QSA (the auditor who assesses Theatre Manager's ability to meet PCI compliance) has indicated that Teamviewer meets that requirement when used per the instructions. The multiple factors include:
      • The user must start the application manually (it cannot be active by default)
      • A unique Id must be provided
      • A single use token must also be provided to ArtsMan that cannot be reused.
      effectively being 3 factors that must occur for access to be granted successfully.
      8.4 Document and communicate authentication policies and procedures to all users including:
      • Guidance on selecting strong authentication credentials
      • Guidance for how users should protect their authentication credentials
      • Instructions not to reuse previously used passwords
      • Instructions to change passwords if there is any suspicion the password could be compromised.
      All Theatre Manager user passwords are encrypted in the database. MD5 authentication is recommended at a minimum for accessing the database (this is the default standard in the pg_hba.conf file)
      8.5 Do not use group, shared, or generic IDs, passwords, or other authentication methods as follows:
      • Generic user IDs are disabled or removed.
      • Shared user IDs do not exist for system administration and other critical functions.
      • Shared and generic user IDs are not used to administer any system components.
       
      8.5.1 Additional requirement for service providers only: Service providers with remote access to customer premises (for example, for support of POS systems or servers) must use a unique authentication credential (such as a password/phrase) for each customer.

      Note: This requirement is not intended to apply to shared hosting providers accessing their own hosting environment, where multiple customer environments are hosted.

      Arts Management does not require permanent remote access to your servers. Temporary access is always initiated by the customer as described in the teamviewer remote support help page.
      8.6 Where other authentication mechanisms are used (for example, physical or logical security tokens, smart cards, certificates, etc.), use of these mechanisms must be assigned as follows:
      • Authentication mechanisms must be assigned to an individual account and not shared among multiple accounts.
      • Physical and/or logical controls must be in place to ensure only the intended account can use that mechanism to gain access.
       
      8.7 All access to any database containing cardholder data (including access by applications, administrators, and all other users) is restricted as follows:
      • All user access to, user queries of, and user actions on databases are through programmatic methods.
      • Only database administrators have the ability to directly access or query databases.
      • Application IDs for database applications can only be used by the applications (and not by individual users or other non-application processes).

      Access to the db is controlled by the pg_hba.conf file and it is set so that all users must log in to read data.

      The user's id for the database is set by the application and not usually known.

      The password in postgres is set by the application and stored encrypted. Thus, the user cannot access the database even knowing their user ID and password because it is not the same as plain-text.

      8.8 Ensure that security policies and operational procedures for identification and authentication are documented, in use, and known to all affected parties.  

      Requirement 9: Restrict physical access to cardholder data

      Restrict physical access to cardholder data

      Any physical access to data or systems that house cardholder data provides the opportunity for individuals to access devices or data and to remove systems or hardcopies, and should be appropriately restricted. For the purposes of Requirement 9, “onsite personnel” refers to full-time and part-time employees, temporary employees, contractors and consultants who are physically present on the entity’s premises. A “visitor” refers to a vendor, guest of any onsite personnel, service workers, or anyone who needs to enter the facility for a short duration, usually not more than one day. “Media” refers to all paper and electronic media containing cardholder data.

      Section PCI Requirement Comments
      9.1 Use appropriate facility entry controls to limit and monitor physical access to systems in the cardholder data environment. This means locks on a computer room door or places (like box office) where people can access machines that can access card holder data.
      9.1.1 Use video cameras or other access control mechanisms to monitor individual physical access to sensitive areas. Review collected data and correlate with other entries. Store for at least three months, unless otherwise restricted by law.

      Note: "Sensitive areas" refers to any data center, server room or any area trefers to any data center, server room or any area that houses systems that store, process, or transmit cardholder data. This excludes public-facing areas where only point-of- sale terminals are present, such as the cashier areas in a retail store.

       
      9.1.2 Implement physical and/or logical controls to restrict access to publicly accessible network jacks.

      For example, network jacks located in public areas and areas accessible to visitors could be disabled and only enabled when network access is explicitly authorized. Alternatively, processes could be implemented to ensure that visitors are escorted at all times in areas with active network jacks.

       
      9.1.3 Restrict physical access to wireless access points, gateways, handheld devices, networking/communications hardware, and telecommunication lines.  
      9.2 Develop procedures to easily distinguish between onsite personnel and visitors, to include:
      • Identifying onsite personnel and visitors (for example, assigning badges)
      • Changes to access requirements
      • Revoking or terminating onsite personnel and expired visitor identification (such as ID badges).
      9.3 Control physical access for onsite personnel to sensitive areas as follows:
      • Access must be authorized and based on individual job function.
      • Access is revoked immediately upon termination, and all physical access mechanisms, such as keys, access cards, etc., are returned or disabled.
       
      9.4 Implement procedures to identify and authorize visitors.

      Procedures should include the following:

       
      9.4.1 Visitors are authorized before entering, and escorted at all times within, areas where cardholder data is processed or maintained.  
      9.4.2 Visitors are identified and given a badge or other identification that expires and that visibly distinguishes the visitors from onsite personnel.  
      9.4.3 Visitors are asked to surrender the badge or identification before leaving the facility or at the date of expiration.  
      9.4.4 A visitor log is used to maintain a physical audit trail of visitor activity to the facility as well as computer rooms and data centers where cardholder data is stored or transmitted.

      Document the visitor's name, the firm represented, and the onsite personnel authorizing physical access on the log.

      Retain this log for a minimum of three months, unless otherwise restricted by law.

       
      9.5 Physically secure all media  
      9.5.1 Store media backups in a secure location, preferably an off-site facility, such as an alternate or backup site, or a commercial storage facility. Review the location's security at least annually.  
      9.6 Maintain strict control over the internal or external distribution of any kind of media, including the following:  
      9.6.1 Classify media so the sensitivity of the data can be determined.  
      9.6.2 Send the media by secured courier or other delivery method that can be accurately tracked.  
      9.6.3 Ensure management approves any and all media that is moved from a secured area (including when media is distributed to individuals).  
      9.7 Maintain strict control over the storage and accessibility of media.  
      9.7.1 Properly maintain inventory logs of all media and conduct media inventories at least annually.  
      9.8 Destroy media when it is no longer needed for business or legal reasons as follows:  
      9.8.1 Shred, incinerate, or pulp hard- copy materials so that cardholder data cannot be reconstructed. Secure storage containers used for materials that are to be destroyed.  
      9.8.2 Render cardholder data on electronic media unrecoverable so that cardholder data cannot be reconstructed. There is a tool on windows called Eraser that will handle this for you. On the Mac, use Secure-Empty Trash. Refer to this link for more information about using them.
      9.9 Protect devices that capture payment card data via direct physical interaction with the card from tampering and substitution.

      Note: These requirements apply to card- reading devices used in card-present transactions (that is, card swipe or dip) at the point of sale. This requirement is not intended to apply to manual key-entry components such as computer keyboards and POS keypads.

      This does not apply to Theatre Manager as it dies not use card reading devices for card present transactions.
      9.9.1 Maintain an up-to-date list of devices. The list should include the following:
      • Make, model of device
      • Location of device (for example, the address of the site or facility where the device is located)
      • Device serial number or other method of unique identification.
      For point of sale devices
      9.9.2 Periodically inspect device surfaces to detect tampering (for example, addition of card skimmers to devices), or substitution (for example, by checking the serial number or other device characteristics to verify it has not been swapped with a fraudulent device).

      Note: Examples of signs that a device might have been tampered with or substituted include unexpected attachments or cables plugged into the device, missing or changed security labels, broken or differently colored casing, or changes to the serial number or other external markings.

      For point of sale devices
      9.9.3 Provide training for personnel to be aware of attempted tampering or replacement of devices. Training should include the following:
      • Verify the identity of any third-party persons claiming to be repair or maintenance personnel, prior to granting them access to modify or troubleshoot devices.
      • Do not install, replace, or return devices without verification.
      • Be aware of suspicious behavior around devices (for example, attempts by unknown persons to unplug or open devices).
      • Report suspicious behavior and indications of device tampering or substitution to appropriate personnel (for example, to a manager or security officer).
      For point of sale devices
      9.10 Ensure that security policies and operational procedures for restricting physical access to cardholder data are documented, in use, and known to all affected parties.  

      Regularly Monitor and Test Networks

      Physical and wireless networks are the glue connecting all endpoints and servers in the payment infrastructure. Vulnerabilities in network devices and systems present opportunities for criminals to gain unauthorized access to payment card applications and cardholder data. To prevent exploitation, organizations must regularly monitor and test networks to find and fix vulnerabilities.

      Requirement 10: Track and monitor all access to network

      Track and monitor all access to network resources and cardholder data

      Logging mechanisms and the ability to track user activities are critical in preventing, detecting, or minimizing the impact of a data compromise. The presence of logs in all environments allows thorough tracking, alerting, and analysis when something does go wrong. Determining the cause of a compromise is very difficult, if not impossible, without system activity logs.

      Section PCI Requirement Comments
      10.1 Implement audit trails to link all access to system components to each individual user.  
      10.2 Implement automated audit trails for all system components to reconstruct the following events:

      10.2.1 All individual accesses to cardholder data Refer to PCI Audit Logs. Theatre Manager tracks every time a user views the entire credit card data for any patron.

      The Theatre Manager logs should be exported to your common logging tools. Refer to exporting logs to see how to accomplish this.

      While Theatre Manager tracks card accesses and login/logout (among other things), you can also implement additional postgres database logging over and above the default. Normally this should not be required.

      10.2.2 All actions taken by any individual with root or administrative privileges Not applicable to Theatre Manager - it is applicable to your operating system.
      10.2.3 Access to all audit trails  
      10.2.4 Invalid logical access attempts Incorrect login attempts to Theatre Manager are tracked in the audit logs.
      10.2.5 Use of and changes to identification and authentication mechanisms—including but not limited to creation of new accounts and elevation of privileges—and all changes, additions, or deletions to accounts with root or administrative privileges Theatre Manager tracks each log in and log out, user creations and when people are given a temporary priviledge. These transaction are of type 'A' in the database (for Audit)
      10.2.6 Initialization, stopping, or pausing of the audit logs Theatre Manager access audit logs cannot be stopped or deleted.
      10.2.7 Creation and deletion of system-level objects This is not possible in Theatre Manager
      10.3 Record at least the following audit trail entries for all system components for each event: refer to PCI audit Log description
      10.3.1 User identification
      10.3.2 Type of event
      10.3.3 Date and time
      10.3.4 Success or failure indication
      10.3.5 Origination of event
      10.3.6 Identity or name of affected data, system component, or resource
      10.4 Using time-synchronization technology, synchronize all critical system clocks and times and ensure that the following is implemented for acquiring, distributing, and storing time.

      Note: One example of time synchronization technology is Network Time Protocol (NTP).

      You must allow each computer to access a respected NTP Server (network time protocol). This is typically built into the operating system and firewall rules should automatically enable this feature.

      Theatre Manager uses the time at the postgres server as the single time source for transactions across all workstations. All data istimestamped with now(), making time diferences on workstations irrelevant.

      Regardless, an alert is given to a user if their workstation does not match the server to within 30 seconds.

      Effectively, if the postgres server is set according to an NTP server; all workstations transactions are synced with the postgres server to create a unified approach to time.

      10.4.1 Critical systems have the correct and consistent time
      10.4.2 Time data is protected
      10.4.3 Time settings are received from industry-accepted time sources
      10.5 Secure audit trails so they cannot be altered  
      10.5.1 Limit viewing of audit trails to those with a job-related need Theatre Manager logs are not sensitive in themselves due to what they track. However, after exporting them and storing them in your centralized logging facility, you will need to limit access because of the other systems you may be logging.
      10.5.2 Protect audit trail files from unauthorized modifications. You cannot modify or delete Theatre Manager logs
      10.5.3 Promptly back up audit trail files to a centralized log server or media that is difficult to alter. In addition to exporting logs, the multiple daly database backups create redundancy in the storage of the TM audit logs.
      10.5.4 Write logs for external-facing technologies onto a log server on the internal LAN. This means things like router logs need to be stored internally.
      10.5.5 Use file integrity monitoring or change detection software on logs to ensure that existing log data cannot be changed without generating alerts (although new data being added should not cause an alert).  
      10.6 Review logs and security events for all system components to identify anomalies or suspicious activity Refer to exporting logs to see how to export TM access logs in excel format so that you can import to your common log server.
      10.6.1 Review the following at least daily:
      • All security events
      • Logs of all system components that store, process, or transmit CHD and/or SAD
      • Logs of all critical system components
      • Logs of all servers and system components that perform security functions (for example, firewalls, intrusion-detection systems/intrusion-prevention systems (IDS/IPS), authentication servers, e-commerce redirection servers, etc.)
       
      10.6.2 Review logs of all other system components periodically based on the organization's policies and risk management strategy, as determined by the organization's annual risk assessment.  
      10.6.3 Follow up exceptions and anomalies identified during the review process.  
      10.7 Retain audit trail history for at least one year, with a minimum of three months immediately available for analysis (for example, online, archived, or restorable from backup).  
      10.8 Ensure that security policies and operational procedures for monitoring all access to network resources and cardholder data are documented, in use, and known to all affected parties.  

      Requirement 11: Regularly test security systems and processes

      Regularly test security systems and processes

      Vulnerabilities are being discovered continually by malicious individuals and researchers, and being introduced by new software. System components, processes, and custom software should be tested frequently to ensure security controls continue to reflect a changing environment.

      Section PCI Requirement Comments
      11.1 Implement processes to test for the presence of wireless access points (802.11), and detect and identify all authorized and unauthorized wireless access points on a quarterly basis.

      Note: Methods that may be used in the process include but are not limited to wireless network scans, physical/logical inspections of system components and infrastructure, network access control (NAC), or wireless IDS/IPS.

      Whichever methods are used, they must be sufficient to detect and identify both authorized and unauthorized devices.

      iStumbler is a great little tool on the mac that is donation ware - it can find a lot of items that are broadcasting signals.

      Alternately, inspect each device that is within the card portion of the network and make sure wireless is off.

      11.1.1 Maintain an inventory of authorized wireless access points including a documented business justification.  
      11.1.2 Implement incident response procedures in the event unauthorized wireless access points are detected.  
      11.2 Run internal and external network vulnerability scans at least quarterly and after any significant change in the network (such as new system component installations, changes in network topology, firewall rule modifications, product upgrades).

      Note: Multiple scan reports can be combined for the quarterly scan process to show that all systems were scanned and all applicable vulnerabilities have been addressed. Additional documentation may be required to verify non-remediated vulnerabilities are in the process of being addressed.

      For initial PCI DSS compliance, it is not required that four quarters of passing scans be completed if the assessor verifies

      1. the most recent scan result was a passing scan,
      2. the entity has documented policies and procedures requiring quarterly scanning, and
      3. vulnerabilities noted in the scan results have been corrected as shown in a re-scan(s). For subsequent years after the initial PCI DSS review, four quarters of passing scans must have occurred.
       
      11.2.1 Perform quarterly internal vulnerability scans and rescans as needed, until all "high-risk" vulnerabilities (as identified in Requirement 6.1) are resolved. Scans must be performed by qualified personnel.  
      11.2.2 Perform quarterly external vulnerability scans, via an Approved Scanning Vendor (ASV) approved by the Payment Card Industry Security Standards Council (PCI SSC). Perform rescans as needed, until passing scans are achieved.

      Note: Quarterly external vulnerability scans must be performed by an Approved Scanning Vendor (ASV), approved by the Payment Card Industry Security Standards Council (PCI SSC).

      Refer to the ASV Program Guide published on the PCI SSC website for scan customer responsibilities, scan preparation, etc.

       
      11.2.3 Perform internal and external scans, and rescans as needed, after any significant change.

      Scans must be performed by qualified personnel.

       
      11.3 Implement a methodology for penetration testing that includes the following:
      • Is based on industry-accepted penetration testing approaches (for example, NIST SP800-115)
      • Includes coverage for the entire CDE perimeter and critical systems
      • Includes testing from both inside and outside the network
      • Includes testing to validate any segmentation and scope-reduction controls
      • Defines application-layer penetration tests to include, at a minimum, the vulnerabilities listed in Requirement 6.5
      • Defines network-layer penetration tests to include components that support network functions as well as operating systems
      • Includes review and consideration of threats and vulnerabilities experienced in the last 12 months
      • Specifies retention of penetration testing results and remediation activities results.
       
      11.3.1 Perform external penetration testing at least annually and after any significant infrastructure or application upgrade or modification (such as an operating system upgrade, a sub-network added to the environment, or a web server added to the environment).  
      11.3.2 Perform internal penetration testing at least annually and after any significant infrastructure or application upgrade or modification (such as an operating system upgrade, a sub-network added to the environment, or a web server added to the environment).  
      11.3.3 Exploitable vulnerabilities found during penetration testing are corrected and testing is repeated to verify the corrections.  
      11.3.4 If segmentation is used to isolate the CDE from other networks, perform penetration tests at least annually and after any changes to segmentation controls/methods to verify that the segmentation methods are operational and effective, and isolate all out-of-scope systems from systems in the CDE.  
      11.4 Use intrusion-detection and/or intrusion-prevention techniques to detect and/or prevent intrusions into the network. Monitor all traffic at the perimeter of the cardholder data environment as well as at critical points in the cardholder data environment, and alert personnel to suspected compromises.

      Keep all intrusion-detection and prevention engines, baselines, and signatures up to date.

       
      11.5 Deploy a change-detection mechanism (for example, file-integrity monitoring tools) to alert personnel to unauthorized modification (including changes, additions, and deletions) of critical system files, configuration files, or content files; and configure the software to perform critical file comparisons at least weekly.

      Note: For change-detection purposes, critical files are usually those that do not regularly change, but the modification of which could indicate a system compromise or risk of compromise. Change-detection mechanisms such as file-integrity monitoring products usually come pre-configured with critical files for the related operating system. Other critical files, such as those for custom applications, must be evaluated and defined by the entity (that is, the merchant or service provider).

       
      11.5.1 Implement a process to respond to any alerts generated by the change- detection solution.  
      11.6 Ensure that security policies and operational procedures for security monitoring and testing are documented, in use, and known to all affected parties  

      Maintain an Information Security Policy

      A strong security policy sets the security tone for the whole entity and informs personnel what is expected of them. All personnel should be aware of the sensitivity of data and their responsibilities for protecting it. For the purposes of Requirement 12, “personnel” refers to full-time and part-time employees, temporary employees, contractors and consultants who are “resident” on the entity’s site or otherwise have access to the cardholder data environment.

      Requirement 12: Maintain a policy that addresses information security for employees and contractors

      Maintain a policy that addresses information security for employees and contractors

      As part of Theatre Manager's PA-DSS implementation process, creating a policy guide will be brought to the attention of venues desiring to be PCI compliant

      Section PCI Requirement Comments
      12.1 Establish, publish, maintain, and disseminate a security policy.  
      12.1.1 Review the security policy at least annually and update the policy when the environment changes.  
      12.2 Implement a risk-assessment process that:
      • Is performed at least annually and upon significant changes to the environment (for example, acquisition, merger, relocation, etc.),
      • Identifies critical assets, threats, and vulnerabilities, and
      • Results in a formal, documented analysis of risk.
      Examples of risk-assessment methodologies include but are not limited to OCTAVE, ISO 27005 and NIST SP 800-30.
       
      12.3 Develop usage policies for critical technologies and define proper use of these technologies.

      Note: Examples of critical technologies include, but are not limited to, remote access and wireless technologies, laptops, tablets, removable electronic media, e-mail usage and Internet usage.

      Ensure these usage policies require the following:

       
      12.3.1 Explicit approval by authorized parties  
      12.3.2 Authentication for use of the technology  
      12.3.3 A list of all such devices and personnel with access  
      12.3.4 A method to accurately and readily determine owner, contact information, and purpose (for example, labeling, coding, and/or inventorying of devices)  
      12.3.5 Acceptable uses of the technology  
      12.3.6 Acceptable network locations for the technologies  
      12.3.7 List of company-approved products  
      12.3.8 Automatic disconnect of sessions for remote access technologies after a specific period of inactivity  
      12.3.9 Activation of remote access technologies for vendors only when needed by vendors, with immediate deactivation after use Team Viewer is designed in exactly this manner.
      12.3.10 or personnel accessing cardholder data via remote-access technologies, prohibit the copying, moving, and storage of cardholder data onto local hard drives and removable electronic media, unless explicitly authorized for a defined business need.

      Where there is an authorized business need, the usage policies must require the data be protected in accordance with all applicable PCI DSS Requirements.

       
      12.4 Ensure that the security policy and procedures clearly define information security responsibilities for all personnel.  
      12.5 Assign to an individual or team the following information security management responsibilities:  
      12.5.1 Establish, document, and distribute security policies and procedures.  
      12.5.2 Monitor and analyze security alerts and information, and distribute to appropriate personnel.  
      12.5.3 Establish, document, and distribute security incident response and escalation procedures to ensure timely and effective handling of all situations.  
      12.5.4 Administer user accounts, including additions, deletions, and modifications  
      12.5.5 Monitor and control all access to data.  
      12.6 Implement a formal security awareness program to make all employees aware of the importance of cardholder data security.  
      12.6.1 Educate employees upon hire and at least annually.

      Note: Methods can vary depending on the role of the personnel and their level of access to the cardholder data.

       
      12.6.2 Require personnel to acknowledge at least annually that they have read and understood the security policy and procedures.  
      12.7 Screen potential personnel prior to hire to minimize the risk of attacks from internal sources. (Examples of background checks include previous employment history, criminal record, credit history, and reference checks.)

      Note: For those potential personnel to be hired for certain positions such as store cashiers who only have access to one card number at a time when facilitating a transaction, this requirement is a recommendation only.

       
      12.8 Maintain and implement policies and procedures to manage service providers with whom cardholder data is shared, or that could affect the security of cardholder data, as follows:  
      12.8.1 Maintain a list of service providers. We suggest placing them in Theatre Manager and adding them to a mail list called PCI Compliance contacts
      12.8.2 Maintain a written agreement that includes an acknowledgement that the service providers are responsible for the security of cardholder data the service providers possess or otherwise store, process or transmit on behalf of the customer, or to the extent that they could impact the security of the customer's cardholder data environment.

      Note: The exact wording of an acknowledgement will depend on the agreement between the two parties, the details of the service being provided, and the responsibilities assigned to each party. The acknowledgement does not have to include the exact wording provided in this requirement.

       
      12.8.3 Ensure there is an established process for engaging service providers including proper due diligence prior to engagement.  
      12.8.4 Maintain a program to monitor service providers' PCI DSS compliance status at least annually.  
      12.8.5 Maintain information about which PCI DSS requirements are managed by each service provider, and which are managed by the entity.  
      12.9 Additional requirement for service providers only: Service providers acknowledge in writing to customers that they are responsible for the security of cardholder data the service provider possesses or otherwise stores, processes, or transmits on behalf of the customer, or to the extent that they could impact the security of the customer's cardholder data environment.

      Note: The exact wording of an acknowledgement will depend on the agreement between the two parties, the details of the service being provided, and the responsibilities assigned to each party. The acknowledgement does not have to include th

       
      12.10 Implement an incident response plan. Be prepared to respond immediately to a system breach.  
      12.10.1 Create the incident response plan to be implemented in the event of system breach. Ensure the plan addresses the following, at a minimum:
      • Roles, responsibilities and communication and contact strategies in the event of a compromise including notification of the payment brands, at a minimum
      • Specific incident response procedures
      • Business recovery and continuity procedures
      • Data backup processes
      • Analysis of legal requirements for reporting compromises
      • Coverage and responses of all critical system components
      • Reference or inclusion of incident response procedures from the payment brands
       
      12.10.2 Test the plan at least annually.  
      12.10.3 Designate specific personnel to be available on a 24/7 basis to respond to alerts.  
      12.10.4 Provide appropriate training to staff with security breach response responsibilities.  
      12.10.5 Include alerts from security monitoring systems, including but not limited to intrusion-detection, intrusion- prevention, firewalls, and file-integrity monitoring systems.  
      12.10.6 Develop a process to modify and evolve the incident response plan according to lessons learned and to incorporate industry developments.  

      Javascript

      The Web Pages that are used by the Web Sales Module contain javascript that performs different functions. There are 3 javascripts that are used and each one is called into the page by the tags. All 3 javascript functions reside in their own page within the tmScripts folder. Below is a description of all three javascripts.

      Location:

      /WebPagesEN/tmScripts

      buttonRollover.html

      Description:

      <SCRIPT LANGUAGE="JavaScript">
      <!--
      function pviiClassNew(obj, new_style) {
      obj.className = new_style;
      }
      //-->
      </SCRIPT>

      Since the buttons that are contained within the tmnavButtons.html page are form inputs, they require Cascading Style Sheets in order to customize their colours and styles. This script allows the buttons to roll from one style to another.

      The variables onMouseOver="pviiClassNew(this,'buttonover')" onMouseOut="pviiClassNew(this,'button')" are included in each tag for each button.

      dropDownMenuFuctions.html

      Description:

      <script language="Javascript">
      <!--
      function submitForm(form, action){
      //Change the name of the hidden input, hiddenSubmit, to be the name of the action we need to perform
      document.getElementById(form).hiddenSubmit.name = action;
      document.getElementById(form).submit();
      }
      //-->
      </script>

      This function is used to submit a form when a <!select /> list is used. The page must include this function as well as a hidden parameter within the form, TMForm. <!input type=hidden name=hiddenSubmit value="">

      navSideRollover.html

      Description:

      <SCRIPT language="JavaScript">
      <!--
      function NavRollOver(oTd) {if (!oTd.contains(event.fromElement)) {oTd.bgColor="";}}
      function NavRollOut(oTd) {if (!oTd.contains(event.toElement)) {oTd.bgColor="";}}
      //-->
      </SCRIPT>

      This script allows the cells within the navSide table to roll from one colour to another, creating dynamic buttons out of table data. The variables onmouseover="NavRollOver(this)" onmouseout="NavRollOut(this)" are contained within the

      tag for each cell you wish to rollover.

      pleaseWaitMessageFuction.html

      Description:

      <script language="JavaScript">
      <!--
      function process() {
      var processingMessage = 'Processing...please wait...this takes a few moments';
      var messageHeight = '25px';

      if (navigator.appName=="Microsoft Internet Explorer") {
      pleaseWait.innerHTML = processingMessage;
      document.all.pleaseWait.style.height = messageHeight;
      document.all.pleaseWait.style.visibility = 'visible';
      }

      if (navigator.appName=="Netscape") {
      document.getElementById("pleaseWait").innerHTML = processingMessage;
      document.getElementById("pleaseWait").style.height = messageHeight;
      document.getElementById("pleaseWait").style.visibility = 'visible';
      }

      if (navigator.appName=="Safari") {
      document.getElementById("pleaseWait").innerHTML = processingMessage;
      document.getElementById("pleaseWait").style.height = messageHeight;
      document.getElementById("pleaseWait").style.visibility = 'visible';
      }
      }
      //-->
      </script>

      showhidediv.html

      Description:

      <script language="javascript">
      <!--
      function divdisplay(layer_ref,state) {

      if (document.all) { //IS IE 4 or 5 (or 6 beta)
      eval( "document.all." + layer_ref + ".style.display = " + state);
      }
      if (document.layers) { //IS NETSCAPE 4 or below
      document.layers[layer_ref].display = state;
      }
      if (document.getElementById &&!document.all) {
      hza = document.getElementById(layer_ref);
      hza.style.display = state;
      }
      }
      //-->
      </script>

      This will show or hide a div statement by name on the screen state= 'none' if you want to see it on the screen state= 'block' if you want it to be disabled from the user.

      <script language="javascript">
      <!--
      function divvisibility(layer_ref,state) {

      if (document.all) { //IS IE 4 or 5 (or 6 beta)
      eval( "document.all." + layer_ref + ".style.visibility = " + state);
      }
      if (document.layers) { //IS NETSCAPE 4 or below
      document.layers[layer_ref].visibility = state;
      }
      if (document.getElementById &&!document.all) {
      hza = document.getElementById(layer_ref);
      hza.style.visibility = state;
      }
      }
      </script>

      this will change the visibility of a div by name on the screen state= 'visible' if you want to see it on the screen state= 'hidden' if you want it to be hidden off the screen from the user

      Navigation Buttons

      Each page contains form input buttons as navigation. Buttons are used in the Web Pages not only to move between different sections of Web Sales, such as Ticketing and Donations, but are also used to communicate data to and from the Theatre Manager database, so that the content on each page is current and constantly linked back to the database. The commands that provide connectibility between the database and the Web Pages are contained within each button's <input> tag. Those Buttons Commands are listed below.

      There are two groups of buttons:

      1. Menu Navigation Buttons
      2. Data Input Buttons
      Menu Navigation Buttons

      The menu Navigation buttons reside within the TMtemplates/tmnavButtons.html file, and are dynamically imported into each page via the <include> command. The command looks like:

      <!--#include virtual="TMtemplates/tmnavButtons.html" -->

      and creates buttons that look like:

      Since buttons are subject to style changes, we are able to use Cascading Style Sheets to make them fit whatever concept your site incorporates, such as

      These buttons are assigned classes (default to the button and buttonover classes) from the styleButtons.css style sheet, and can use javascript to create a rollover effect.

      Data Input Buttons

      The other buttons in each page serve different purposes by sending data to the database. These buttons work exactly the same way as the menu buttons only they allow Theatre Manager to receive the data that has been entered into the page and then load a new page page based on that data. An example of this would be to click on the Buy Tickets button in the TMtickets.html page, which would send a command to Theatre Manager and open a new page based on the show that you clicked it for, allowing you to select seats for that performance.

      The Data Input Buttons default to the 'new' and 'newover' classes in styleButtons.css.

      Buttons Commands

      This is a list of the button commands that Theatre Manager requires. They are entered as the name="xxx" portion of each input tag.

      These commands cannot be altered.

      • btnLogin
      • btnLoginAccount
      • btnLoginFromDetail

      • btnHome
      • btnHistoricalCart
      • btnHistoricalCartDetail

      • btnAccount
      • btnAccountRequest
      • btnAccountAdd
      • btnAccountUpdate

      • btnPassword
      • btnPasswordCancel
      • btnPasswordAccept
      • btnPasswordRequest
      • btnPasswordSend

      • btnMailList
      • btnMailListAdd
      • btnMailListRemove

      • btnTicket
      • btnGetEventRange - Deprecated. use btnGetEventList instead. This button uses btnGetEventList anyway
      • btnGetEventAll - Deprecated. use btnGetEventList instead. This button uses btnGetEventList anyway
      • btnGetEventList
      • btnSelectEvent
      • btnBestAvailCancel
      • btnBestAvail
      • btnReserveCancel
      • btnReserveTicket

      • btnPass
      • btnReservePass
      • btnPassAmountCancel
      • btnPassAmountAccept

      • btnDonation
      • btnDonationAccept

      • btnCart
      • btnCartRemoveItem
      • btnMailFeeAdd

      • btnCheckout
      • btnCheckoutAccept

      • btnLogout
      • btnLogoutCancelOrder

      License Agreement

      Copyright

      ARTS MANAGEMENT SYSTEMS LIMITED
      1988 - 2017 All rights reserved.

      All software developed by Arts Management Systems Ltd. is furnished under a license agreement and is not sold to the end user. The software may be used or copied only in accordance with the terms of the agreement. Names of persons, corporations or products used in the tutorials and examples of this manual are fictitious.

      No part of this web site (hereinafter referred to as a manual) may be reproduced, transmitted, stored in a retrieval system or translated into any language in any form by any means without the written permission of ARTS MANAGEMENT SYSTEMS LIMITED. The information in this manual is subject to change without notice and does not represent a commitment on the part of ARTS MANAGEMENT SYSTEMS LIMITED to the functionality described herein. You may develop your own web pages and custom documentation that refer to (or hyper-link with) web pages within the manual with the understanding that links could be changed or removed in the future and content within each page of this manual may also change as functionality within the software changes. The manual is not guaranteed to match your version of the software as it will be amended constantly to reflect the current state of any software.

      This licence agreement may change without notice. Any changes and amendments to the licence agreement are also binding.


      Trademarks

      • IBM, IBM PC and AT are registered trademarks of International Business Machines Corporation.
      • Windows, Microsoft and MS-DOS are registered trademarks, and Microsoft Windows are trademarks of Microsoft Corporation.
      • Apple, the Apple logo, Apple Talk, LaserWriter, OSX and Macintosh are registered trademarks and Finder is a trademarks of Apple Computer, Inc.
      • PostScript is a registered trademark of Adobe Systems, Inc.
      • oWrite, oGantt, oSpell are a registered trademarks of Brainy Data Ltd.
      • Other products mentioned are trademarks or registered trademarks of their respective corporations.


      Warranties

      ARTS MANAGEMENT SYSTEMS LIMITED makes no warranties, either expressed or implied, regarding the described computer software package of its fitness for any particular purpose.


      Agreement

      DO NOT DOWNLOAD, INSTALL OR USE THE SOFTWARE UNTIL YOU HAVE CAREFULLY READ AND AGREED TO THE FOLLOWING TERMS AND CONDITIONS WHICH SET OUT THE TERMS OF THE LICENSE AGREEMENT BETWEEN YOU AND ARTS MANAGEMENT SYSTEMS LIMITED. IF YOU INSTALL THE SOFTWARE AND CLICK 'I AGREE' DURING THE INSTALLATION, YOU EXPLICITLY AGREE TO ALL TERMS AND CONDITIONS OF THE SOFTWARE LICENCE. YOU MAY NOT USE THE ENCLOSED SOFTWARE, RECEIVE SUPPORT OR BENEFIT FROM THE WARRANTY SET FORTH BELOW UNLESS YOU AGREE TO THE TERMS OF THE LICENCE WITH ARTS MANAGEMENT SYSTEMS LIMITED. IF YOU DO NOT AGREE WITH THE LICENSE TERMS AND CONDITIONS, PROMPTLY DESTROY THE INSTALLER AND YOUR MONEY WILL BE REFUNDED.

      1. Ownership. Arts Management Systems Limited retains ownership of all software and programs provided to you. This software is licensed to you for use under the following conditions:
      2. Software License. Subject to the terms and conditions set forth below and upon receipt by Arts Management Systems Limited of a contract that has been signed by you, you (the "Licensee") are hereby granted a non-exclusive, non-transferable, limited license (the "License") to use the Arts Management Systems Limited programs described below (the "Program") and the associated documentation (the "Documentation") (the Program and the Documentation are collectively referred to herein as the "Software") on any number of compatible computers within your organizations as specified explicitly in the contract. Access to the use of the Software by Licensee shall be limited to no more than the designated number of Licensed Users as set out in the contract. The designated number of License Users may be altered by the Licensee at any time upon receipt of a supplemental signed contract by Arts Management Systems Limited's with pricing and additional licence arrangements stated in the contract.

        Number of Licensed Users: Refer to original Contract and supplemental Contracts or amendments

        Program (includes but is not limited to): Theatre Manager, scanner software, web servers, and any software that may be provided by Arts Management Systems Ltd. or downloaded electronically from our web sites or App Stores (such as Apple's App store). Download of any software created by Arts Management Systems from any source automatically makes that software subject to this licence agreement.
      3. Copies. This license allows you to make any number of copies of the software provided in the Contract in machine-readable form for deployment within your organization or backup purposes only. You must reproduce on each copy the Arts Management Systems Limited copy right notice and any other proprietary legends that were on the original copy of the Arts Management Systems Limited software.
      4. Property Rights. The software contains copyrighted material, trade secrets and other proprietary materials, all of which are owned by Arts Management Systems Limited or its suppliers who retain title to the Software and all copies thereof, and Licensee shall not sell, transfer, rent, lease, loan, distribute, disclose, display or otherwise make available any portion of the Software to others. Licensee may not engage in, or permit third parties to engage in any activities which would have the effect of infringing on or derogating from Arts Management Systems Limited's ownership in the software. Without limiting the foregoing and except as provided in paragraph 2 above, Licensee may not engage or permit third parties to engage in any of the following: (A) the provision or permitted use or disclosure of the Software to third parties; (B) provision of the Software for use in a computer service business, network, timesharing, multiple CPU or multiple user arrangement, or by telecommunications to users who are not individually licensed by Arts Management Systems Limited; (C) removal or obscuring of the copyright and other proprietary notices from any of the programs, screens, media, installers, or any of the Documentation; (D) reverse engineering or attempting to disassemble or decompile the Software; (E) granting sublicenses, leases or other rights in the Software to others; and (F) making copies or verbal or media transmissions, of the Documentation. Licensee may physically transfer the Programs from one computer to another provided the programs are used by no more that the designated Number of Licensed Users at the same time.
        Licensee agrees to secure and protect the Software in a manner consistent with the maintenance of Arts Management Systems Limited ownership and proprietary rights therein and to take appropriate action by instruction or agreement with the Licensed Users to satisfy its obligations hereunder.
      5. Limited Warranty. Arts Management Systems Limited warrants that the Software will substantially conform to published specifications and the Documentation, provided that the Software is used on computer hardware and with the operating system for which it was designed. Arts Management Systems Limited warrants that the installer will be free from defects in material and workmanship, under normal use, for ninety (90) days after the date of the original purchase. If a defect occurs during such ninety (90) day period, the Licensee may download a replacement without charge or, at Arts Management Systems Limited's option, a refund of the purchase price. This is Licensee's sole remedy and Arts Management Systems Limited entire liability in the event of a defect in the media, installer, or software. Further, Arts Management Systems Limited hereby limits the duration on any implied warranty(ies) on the media or installers to the period stated above.

        EXCEPT AS PROVIDED ABOVE, LICENSEE ACKNOWLEDGES AND AGREES THAT THE SOFTWARE IS USED BY LICENSEE AT LICENSEE'S SOLE RISK AND IS PROVIDED "AS IS" WITHOUT WARRANT OF ANY KIND, EITHER EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE, QUALITY, NON-INFRINGEMENT, TITLE, RESULTS, EFFORT OR QUIET ENJOYMENT. ARTS MANAGEMENT SYSTEMS LIMITED DOES NOT GUARANTEE, WARRANT OR MAKE ANY REPRESENTATION THAT THE FUNCTIONS CONTAINED IN THE SOFTWARE WILL MEET LICENSEE'S REQUIREMENTS, OR THAT THE OPERATION OF THE SOFTWARE WILL BE UNINTERRUPTED OR ERROR-FREE, OR THAT THE DEFECTS IN THE SOFTWARE WILL BE CORRECTED. FURTHERMORE, ARTS MANAGEMENT SYSTEMS LIMITED DOES NOT GUARANTEE, WARRANT OR MAKE ANY REPRESENTATION REGARDING THE USE OF THE RESULTS OF THE USE OF THE SOFTWARE IN TERMS OF THEIR CORRECTNESS, ACCURACY, RELIABILITY, CURRENTNESS, OR OTHERWISE. NO ORAL OR WRITTEN INFORMATION OR ADVICE GIVEN BY ARTS MANAGEMENT SYSTEMS LIMITED, OR ANY AUTHORIZED REPRESENTATIVE OF ARTS MANAGEMENT SYSTEMS LIMITED, SHALL CREATE A WARRANTY OR IN ANY WAY INCREASE THE SCOPE OF THIS WARRANTY. SHOULD THE SOFTWARE PROVE DEFECTIVE, YOU (AND NOT ARTS MANAGEMENT SYSTEMS LIMITED OR ITS AUTHORIZED REPRESENTATIVES) ASSUME THE ENTIRE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION. SOME STATES OF THE UNITED STATES OF AMERICA DO NOT ALLOW THE EXCLUSION OF IMPLIED WARRANTIES, SO THE ABOVE EXCLUSION MAY NOT APPLY TO YOU. THIS WARRANTY GIVES LICENSEE LIMITED, SPECIFIC RIGHTS. LICENSE MAY HAVE OTHER RIGHTS, WHICH VARY FROM STATE TO STATE.
      6. Limitation Of Liability. In no event, including negligence, will Arts Management Systems Limited or its directors, officers or agents be liable to licensee for indirect, special, incidental or consequential damages, including, but not limited to any loss of data or business information or loss of profits, arising out of the use or inability to use the software, even if Arts Management Systems Limited or an authorized representative thereof has been advised of the possibility of such damages. Because some states do not allow the exclusion or limitation of liability for consequential or incidental damages, the above limitation may not apply to licensee. In no event shall Arts Management Systems Limited total liability hereunder for all damages, losses, and causes of action whether in contract, tort (including negligence) exceed the amount paid by licensee for the software.
      7. Termination. This license is effective until terminated. This License will terminate automatically without notice from Arts Management Systems Limited upon breach of Licensee or any of the Licensed Users of any provision of this license relating to the confidentiality and protection of Arts Management Systems Limited proprietary rights in the Software, use of the Software by more than the designated number of Licensed Users, or the termination of Licensee's business or the filing of a petition in bankruptcy or insolvency with respect to Licensee. In the event of termination to this License, Licensee shall immediately return the Software to Arts Management Systems Limited and destroy all copies thereof. All provisions of this License relating to disclaimers of warranties, limitations of liability, remedies or damages and Arts Management Systems Limited proprietary rights shall survive termination.
      8. Export Law Assurances. Licensee agrees and certifies that the Software, and the direct product thereof, will not be exported outside Canada and The United States except as permitted by the laws and regulations of either country or exported or used outside the country in which originally licensed.

        This License shall be governed by and construed in accordance with the laws of Canada and the Province of Alberta, as applied to agreements entered into and to be performed entirely within Alberta between Alberta residents and the parties hereto irrevocably attorn to the jurisdiction of the Courts of the Province of Alberta. If for any reason a court of competent jurisdiction finds any provision of this License, or portion thereof, to be unenforceable, that provision of the License shall be enforced to the maximum extent permissible so as to effect the intent of the parties, and the remainder of this License shall continue in full force and effect.

      ARTS MANAGEMENT SYSTEMS LIMITED, 817 East Chestermere Drive, Chestermere, Alberta, Canada T1X 1A7

      LICENSEE ACKNOWLEDGES THAT IT HAS READ AND UNDERSTANDS THIS AGREEMENT AND AGREES TO BE BOUND BY ITS TERMS. LICENSEE FURTHER AGREES THAT THIS AGREEMENT IS THE COMPLETE AND EXCLUSIVE STATEMENT OF THE AGREEMENT BETWEEN LICENSEE AND ARTS MANAGEMENT SYSTEMS LIMITED AND SUPERSEDES ANY PROPOSAL OR PRIOR AGREEMENT, ORAL OR WRITTEN, AND ANY OTHER COMMUNICATION RELATING TO THE SUBJECT MATTER OF THIS AGREEMENT AND MAY NOT BE MODIFIED EXCEPT IN A WRITTEN AGREEMENT SIGNED BY AN AUTHORIZED REPRESENTATIVE OF LICENSEE AND ARTS MANAGEMENT SYSTEMS LIMITED.