Database Cloning

If you are looking to have a separate copy of the database, please refer to the tools that come with your database vendor to export/import/clone a database, and their documentation.

If you are moving datacenters for the database, see this link.

• Cloning Search with Oracle
• Using MySQLDump
• SQLServer Copy Database Wizard

File System Cloning

To clone the anthillpro server itself:

Installer Download & Extraction

1. On the machine you want to install the cloned server on, download the distributable archive that matches the current version of your AnthillPro Server (so if you are running 3.7.3_68926, you will want to download 3.7.3_68926).
2. Extract the archive to an accessible folder.

Installation of Clone

1. From an Administrative Command Prompt, navigate to the extracted anthill3-install directory, and run install-server.bat.
2. When prompted, provide the following information:
   1. Directory: Directory where you would like the server installed on the new machine
   2. Confirmation: Type "y" if this was the correct directory to install to. Typing "n" will fail the program out.
   3. JDK: Home directory of the JDK
   4. Host: The hostname of the AnthillPro server (the agents will use this to connect to the server)
   5. JMS: The port that the agents will be using for communication (Default is 7915)
   6. Devilfish/Remoting: The port that will be used for remoting connections (Default is 4567)
   7. IP Address: Also known as the "Bind-IP". This is the address the server will bind to (default is all [0.0.0.0]).
      1. HTTPS (optional): Type "y" if you want to use HTTPS protocol to connect to the WebUI, else type "n".
      2. HTTPS Port (optional): Input the secure port that you want the WebUI to listen on (Default is 8443).
      3. HTTP Port: Input the port that you want the WebUI to listen on (Default is 8080).
      4. SSL (optional): Type "y" if you want to use SSL between Server ? Agents. Else type "n".
      5. Mutual Authentication (optional): Type "y" if you want to use mutual authentication. This will require a manual key exchange between server and each agent that will connect to it.
3. When prompted for database type, specify derby or just press enter as we want to do a default Derby install.
4. Press enter twice to accept defaults (anthill3/password) as the username/password combination.
5. Once file system installation finishes, select "N" for the Windows Service install (this can always installed manually later).
6. Once the database installation finishes, press enter a couple of times to exit the installer.

Database Driver Configuration

1. Now that the server is installed, navigate to the server"s lib directory, and create a subdirectory called "ext".
2. Place your database driver JAR file in this ext directory.

Connection Settings Modification

1. Ensure that your cloned database (or old database) is running, and you can connect to it.

%SERVER_HOME%\conf\server\installed.properties

1. install.db.type should get the type of database you are going to (for example, mysql for MySQL, oracle for Oracle, sqlserver for SQL Server)
2. install.db.url should get the connection string for your database (for example, one for Oracle might look like jdbc:oracle:thin:@oraclebox:1521/ORCL )
3. install.db.password should be replaced with the plaintext password of the database user.
4. install.db.driver needs the class name of the driver (for example, Oracle"s is oracle.jdbc.driver.OracleDriver if using ojdbc6.jar)
5. install.db.user should be replaced with the database user"s username.

%SERVER_HOME%\conf\server\spy.properties

1. Find line 42 (should say realdriver=org...) and change the class name of the driver to match with what you specified in the install.db.driver line in installed.properties file.

%SERVER_HOME%\conf\spring-server\base.xml

1. The following values should be changed: (NOTE: Some of the values may not need to be changed if already on a newer branch of AnthillPro! If the values are already in a ${...} format, nothing to do here.)
   1. url should get changed to the connection string specified in installed.properties
   2. username should get changed to the database user"s username specified in installed.properties
   3. password should get changed to the plaintext database user"s password specified in installed.properties
2. Finally, ensuring that all the correct values are specified, you should be able to start your server and have it connect to the cloned database (or old database depending if you cloned the database or not).

Connection Binding

If you have modified your bind IP to any value other than 0.0.0.0, you will need to reference the Connection Binding section.

Validation Queries

It is also possible (on 3.8+ versions) that you need to specify a compatible validation query for the database. Those can be found, here.

Retention

Finally, if you wish to retain any artifacts, job logs, etc., you will need to copy the previous server's folders. Each folder is listed below:

• %SERVER_HOME%\var
  • artifacts - Contains the artifacts for each build life
  • codestation - Contains the codestation artifacts for each codestation build life
  • db - Only necessary if copying the Derby database
  • log - Contains ALL job/workflow/build request/server logs
  • published - Contains any custom published reports for each build life

As a final note, any type of customization you performed on the anthill server's file system (such as custom ah3server startup scripts, any certificates or keys, etc.) you may want to copy those over as well so you do not have to perform them again.

Alternative Method (easier)

An alternative method (as found http://documentation.urbancode.com/anthill3-help-3.8/html/CloneAnthillpro.html) is available as well:

1. Install the new AnthillPro server and instruct it to connect to a new empty database created specifically for the instance.
2. Modify the production server to ensure that it is configured to bind to the address: 0.0.0.0 on startup. Go to System > Server Settings, and set the Bind to IP setting to 0.0.0.0.
3. Shutdown the AnthillPro production server.
4. Clone the AnthillPro database. The procedure varies depending on the underlying database. Your database vendor should have documentation on cloning.
5. Start the production AnthillPro server. If need be, reset the Bind to IP setting. This may require you to restart the server to take effect.
6. Copy the cloned database over the top of the clean database schema which was created in Item 1.
7. Cleanup the cloned database before installing it in the new instance. The first two statements (see below) remove the production license from the new server to prevent license conflicts. If you do not run these statements, starting the new server may disable your production server. The third statement instructs the new instance to ignore all production agents, preventing accidental upgrades.

      DELETE FROM ANTHILL_LICENSE;
      DELETE FROM REPOSITORY_USERS;
      UPDATE AGENT SET ISIGNORED = 1;
   

8. Moving SSL certificates. If your production server is using SSL, you will need to copy over all the *.keystore files into the new instance. Do not remove the files from the production server.
9. Start the new AnthillPro instance and enter your evaluation license. In order to use the server, you will have to connect it to at least one agent. There are a number of options you can choose: the simplest is to install some new agents and bind them to the new server.
   1. Note that if you have any production agents come online (e.g., you restart an agent) while the new instance is running and still set to bind to 0.0.0.0, that agent may bind to the new instance and not the production instance. To prevent accidental binding and/or upgrade, you can give the AnthillPro new instance a unique IP address and then tell its agents only to bind to that IP.

Either way, after the clone is complete, you are free to copy over the \var\ directory from the server to the new server"s \var\ directory. This will copy over all old artifacts, job logs, published reports, etc.

Appendix A: Validation Queries

AnthillPro performs a validation query against the JDBC driver specified within the installed.properties file to test if the database driver is suitable or not. It is basically just a query for a trivial result, and if no errors are returned, then the query & driver is valid; therefore we have this as a configurable value and we pick a known good one for each database type. The table below lists the known install.db.validationQuery option for each database type: