Replikwando/Installation

From ISoft Wiki
Jump to navigationJump to search
The printable version is no longer supported and may have rendering errors. Please update your browser bookmarks and please use the default browser print function instead.

Windows Server

  • First try the new installer thats on downloads.

Service version of Replikwando, which will copy a customers database to ISoft's server so their inventory can eventually be updated on heavytruckparts.net.

  1. Connect to the server thru VNC
  2. Check their local itrackpro/itrackenterprise database for their company produce code (companyinfo.productcode or settings.location=CompanyInfo) and use it when creating their account
  3. Create Replikwando account on Replikwando Records - Add New Company website
    Update Kungfu to include the new HTP account information
  4. Download Replikwando Install pack from tools.isoftdata.com
  5. Copy SSL Certificates over to %PROGRAMFILES%\Isoft Data Systems\Certificates
    SSL Certs can be found in <svndir>\itrack\trunk\Certificates\<companyname>-cert. If certs don't exist for the company, ask Dayton or Brian to generate them.
  6. Edit Replication.ini file
  7. Edit my.ini file (default location %PROGRAMFILES%\MySQL\MySQL server 5.1\my.ini)
    1. Add the following under [mysqld]:
      log-bin
      expire-logs-days=10
  8. Stop and Start the MySQL service
    Either
    1. Restart service in control panel -> Admin tools -> Services
      OR
    2. in command prompt:
      sc stop mysql
      sc start mysql
  9. Run replikwando_service_install.bat
    This will install replikwando as a service and start it up (which does NOT start the initial push immediately)
    If you wish to do an initial push sooner, use the Replikwando Message Interface
    If the service fails to start, but Replikwando2 (the GUI version of replikwando) works fine, then change the user the service runs as to one with permissions to run

Linux Sever

Replikwando on Linux using Wine

  1. Connect to the customer's server using sftp (Filezilla and others support this, and it comes with cygwin and linux)
    Do `put “Replikwando with Wine.tar.gz” .` to put the install files on their server
    You should also put the customer's key and cert over as well (ca-cert.pem is included in the gz)
  2. Connect to the customer's server using SSH/putty
    Extract the files using `tar -zxf “Replikwando with Wine.tar.gz”`
    If that fails, use `gunzip “Replikwando with Wine.tar.gz”`, `tar -xf “Replikwando with Wine.tar”
  3. You will now have two new files in your directory, replikwando_install.sh and ISoft/*
    Type ./replikwando_install.sh
    Depending on the system configuration, several prompts may show up. Just read them and follow what they tell you to do.
    The script will tell you when it is done running.
  4. Navigate to ~/.wine/drive_c/Program\ Files/Replikwando
    This directory will contain the error logs, sqlite file, and so on when Replikwando is started.
    Put in the required values for replication.ini (see above)
  5. Type `vi replication.ini` to edit the replication file`
  6. Type ~/replikwando_startup.sh to start Replikwando for the first time.
    Confirm that Replikwando is running correctly using the error logs here
    Type `vi <filename>` to open the file in an editor to read it. Type :q<enter> to quit.
  7. To connect to the mysql server, type `mysql -utestuser -hlocalhost -p`
    You'll have to type a 'use <database>' command before running queries
  8. Once Replikwando is confirmed running, type `sudo vi /etc/rc.local` and place the following lines just above the last line that says 'exit 0':
    # start replikwando
    sudo -H -u isoft /home/isoft/replikwando_startup.sh
  9. Done!


Quick linux commands:

  • ls : shows you what is in the directory
  • sudo : lets you run powerful & dangerous commands (requires password)
  • cd : change directory
  • rm : deletes a file (use rm -r to delete a folder)
    • deletes cannot be undone!

You can't open Replikwando's UI to see if it's pushing data, so you have to rely on the error logs and test database changes.
All normal Replikwando caveats apply (initial push db lock, query error logs, so on so forth)

Configuring the replication.ini file

Use ITEncrypter Frontend.exe to generate an encrypted username and password (Get it from File::Tech Support)

  1. [FromServer]
    Host
    Database
    Username
    Password
    binlogpath - Should be the path to their MySQL 'data' directory
    mysqlbinpath - Should be the path to their MySQL 'bin' directory
    blacklist_count=<number of blacklisted tables>
    blacklist<n>=<table_name>
    graylist_count=<number of graylisted tables>
    graylist<n>=<table_name>
  2. Set Username and Password for [ToDatabase] with same account info setup on Replikwando Records
    Use Frontend to convert pass to hash
    Add "Z" in front of hash
  3. Set database = product code (Company product code can be found in their companyinfo table. If one doesn't exist there, you can create a new one when you create their account.)
  4. [SSL]
    Set path = path to the folder where the SSL Certificates are stored
    Set prefix = everything before -cert
    • Ex. for ABC-Company-cert.pem, prefix=ABC-Company
  5. [Heartbeat]
    Set the Process ID (for heartbeat) to the company's product code
  6. Set use_compression=True if the connection uses the internet, False if it's on the local network (or same machine)

Black/Gray List

Blacklisting and graylisting are used to tell Replikwando that some tables need to be handled differently than it does in normal operations.

Blacklisting

If you have a table that should never, under any circumstances, be pushed, you blacklist it. Tables that are blacklisted will still show up in the remote database, but they'll always be empty. We create empty tables so that queries run against them do not fail... however, this means that if the user runs a query that *does* involve the blacklisted table, their results will become incorrect.

For this reason, blacklisted tables should be READ-ONLY, and also not necessary to back up.

Graylisting

If you have a table that has wonky data, or should be handled with delicacy, you graylist it. Tables that are graylisted will be pushed and sync'd like normal tables, but they'll be copied a single row at a time. This means that tables that use blob files (such as `attachments`, `filedata`, and the like) can still be pushed without eating 2GB of memory or crashing.

Tables that are graylisted still show up on the remote database, so they'll be backed up, and safe(r) to use in queries.

In the future, graylisting will also reduce the priority of a table during resynchronization.

If you have any additional questions, ask Justin.