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:
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
If you enter the URL http://127.0.0.1:3012/configure and do not see the 'Director' screen, you may need to:
|
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.
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:
Checking for auto-updates shares some of your information with Arts Management. Data is transmitted securely and SHA-384 checksummed for safety and the values retained by AMS are:
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.
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.
Enabling a TM Server to provide background report generation services requires four steps. You must:
Note: if this is not enabled, an employee can still add reports to the queue, they will just need to run them manually when they go for coffee or take an extended break.
Reporter processes use CPU resources when they are running a report and that may be in conflict with resources required if your venue requires the machines for web sales.
Under some circumstances, you may wish to host your marketing site internally in addition to the ticketing web site. Such circumstances might be when you:
Or, if you wish, this feature could be used for something other than your marketing site -- to handle volunteer pages, local static calendaring info, help pages for your patrons on how to use your web site or what have you. Remember, anything placed on the static web site is publicly visible.
A static HTML web page is one that does not require server processes to build the page. If you can see a fully functioning page when you place the HTML file on a browser, then it is static. However, if you need a server process like PHP (by choice by the way), a database lie postgres, or some server process to be installed to deliver the web pages, then the page is not static (and this feature should not be used)
On the primary (front facing) NGINX machine that has a Director on it, you would need to:
Since you are now hosting two web sites with the single NGINX server the landing path changes.
Currently:
There are a number of tools that let you make static web sites. We do not have any favourites and do not recommend one over the other (not do we provide any support if you play with them). Some popular ones at the current time are:
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.
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)
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.
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:
Each domain (eg tickets.myvenue.org) requires what is called a TLS certificate to uniquely encrypt the communication between your customer and your server. It is what turns on the lock in a patrons browser window. TLS certificate has 3 files that are obtained and properly configured for you by Arts Man:
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.
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.
Before you can get an TLS certificate, you will need:
The steps you will need to follow to set up an TLS Certificate and get web pages working are in the following sections.
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 TLS certificate for your use. If you prefer to use your own domain name, you will need your own TLS that we can obtain and set up. |
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.
AMS provides the static IP for you as part of your setup. |
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: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 TLS certificate.
AMS can provide a URL like 'yourname.artsman.com' if you wish, and if so, will also provide our group TLS certificate for your use. |
Arts Management Systems uses 4096 bit encrypted premium certificates and if you wish to purchase one, please contact the sales office at (888) 536-5244, ext. 2.
When you buy a TLS Certificate from Arts Management Systems, information that we will require from you in order to customize is to your venue are:
If you purchase your own TLS 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 TLS certificate, contact the company from whom you purchased it for any and all assistance.
Once the firewall rules have been implemented and the TLS certificate installed:
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.
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 du ring the exchange. It is, however, an essential building-block, and was in fact the base upon which asymmetric crypto was later built.
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 TLS certificate. It is quite easy to do so.
Macintosh |
This needs to be done using Terminal:
|
Windows | Please ask Arts Management support to make one for you or find a Macintosh. |
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. |
You should be able to access your ticketing web site via the URL you used to create the TLS certificate after the:
Try accessing the ticketing web site from:
If you are having issues connecting to your ticketing web site while inside the office and are receiving timeouts, this is often resolved by:
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.
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. |
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. |
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:
|
|
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.
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.
In the database section, you will need to enter the IP address of the database server and provide the Database Name.
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:
Classic Listeners
Designate the number of classic listeners that you might need to handle some tasks that the main web listeners cannot do (yet)
Housekeepers
Housekeepers are used to handle background activity. Typically, this value is always 1. Housekeepers:
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
The key things to note are:
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 activity 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/backup | Run the backup command on the database. You must have set up the Director for backups and configured the backup process. Results are shown in the backup.log and a blue message appears |
http://127.0.0.1:3012/backup.log | Shows the the latest backup's activity log -- this shows what the result of the last pg_dump command . |
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 what they may 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 | test TM servers to see if they are responding|
https://127.0.0.1/api/v1 | Access to the REST API internally to the organization - if enabled for the employee |
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.
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: | 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 |
WindowsYou can also look to see if the service 'Theatre Manager Server' is running using the services control panel.
OSX
|
After playing with the service and/or restarting it, go back to '5a' to see if the director is running. |