Syndeia Cloud Installation Instructions for Windows (2012-R2 x64)

Syndeia Cloud Installation Instructions for Windows (2012-R2 x64)

Single Node Setup Instructions:



Pre-requisites:

1.  Ensure you have the syndeia-cloud-3.4.zip (or latest service pack) downloaded to your home directory (or home directory's Downloads folder) from the download/license instructions sent out by our team.  

(info)  Note: the .ZIP will pre-create a separate folder for its contents when extracted so there is no need to pre-create a separate folder for it.  

2. Review Syndeia Cloud's recommendations, ie: (Open|Oracle)JDK/JRE, memory, FS selection, params, etc. in Deployment.  

(info)  Note:  Syndeia Cloud can be deployed on a different machine VS Cassandra but these steps will focus on a single-node deployment.  

3. If using a firewall, ensure the following port(s) are accessible from client machines (consult your local network admin if required): TCP port 9000 (HTTP), 9443 (HTTPS). 

(info)  If you wish to use JMX monitoring (or Grafana), the following additional ports will also need to be accessible from where you will run monitoring:

SC service

JMX port #

sc-auth

31101

sc-store

31102

sc-graph

31103

sc-webgateway

31100

sc-aras

31112

sc-artifactory

31116

sc-bitbucket

31104

sc-confluence

31105

sc-doors

31115

sc-github

31106

sc-gitlab

31107

sc-jama

31114

sc-jira

31108

sc-sysmlv2

31112

sc-testrail

31113

sc-twcloud

31109

sc-wc

31110



Downloading & Extracting Syndeia Cloud:

1. Launch a Cygwin Terminal, it should start in your home dir. 

(warning) CAUTION:  To avoid any issues on Windows, it is recommended you do NOT use a path that contains any spaces in any of the directory (or file) names.  

2. Make a download directory for the build & cd into it, ex:  new_build_version=3.4.SP3_2022-07-01 ; export new_build_version

(info)  Note:  If your version you have is older than the one shown above, please reach out to us to obtain the latest Service Pack.  

3. In the download dir, unzip the main package, ie:  unzip syndeia-cloud-3.4.zip ;  You should see additional .ZIPs for each microservice

(info)  Note: if you don't have unzip installed, you may need to first install it via the Cygwin Installer or jus use Windows Explorer's built-in unzip feature. 

(info)  Note,  If you ran the setup script from the JanusGraph setup page, you can skip the next section (or just validate the syndeia_admin account is setup correctly via the LIST ROLES command).    

(warning)  IMPORTANT:  once Java JRE/JDK is installed, please ensure you have enabled JMX monitoring per Appendix C3.5 (if for whatever reason you do not wish to use JMX, you can disable it post SC setup via the steps in Appendix C3.6).



Installing, Configuring, and Starting Syndeia Cloud:

4. In the directory you downloaded and extracted the main .ZIP, run the install script, ie:  ./bin/syndeia-cloud-3.4_install_windows.bash -SC_v ${new_build_version}.  This will: 

- install Syndeia Cloud 3.4 (or latest service pack) to /opt/icx/syndeia-cloud-${new_build_version} ,
- make syndeia-cloud:syndeia-cloud the owner, 
- configure the application.conf files if necessary,
- generate a concatenated schema file,
- stop any existing Syndeia Cloud 3.4 processes,
- update/create a "current" symlink to the installed version,
- stop the Janusgraph service (on single-node deployments only),
- stop the Kafka service (on single-node deployments only),
- archive any old Kafka logs (on single-node deployments only),
- drop any old keyspaces & generate the new schema in the DB (Cassandra),
- start Kafka service (on single-node deployments only),
- start Janusgraph service (on single-node deployments only),
- initialize the Janusgraph configuration (on single-node deployments only),
- install a tmpfiles.d .conf file for syndeia-cloud,
- install systemd .target and .service files for syndeia-cloud microservices
- start all Syndeia Cloud microservices,
- create the superuser account, and
- create some sample test data.  

(info)  Note: you may be prompted for sudo authentication when installing to /opt/... you will also be prompted for your syndeia_admin password set previously

(warning)  Note, If you are deploying SC 3.4 SP1 on a multi-node configuration where SC is not on the same machine as Cassandra or JG, please:  a. ensure you have CQLSH installed, b. update localhost with \localhost\ on L477-478 in the provided bin/syndeia-cloud-3.4_install.bash, and c. run the SC setup with the --multi_node or -m  switch. 

(warning)  IMPORTANT:  If you get an error at the end with the superuser (& setup) devops action failing (see screenshot below), it is most likely because you didn't adhere to (or ignored) the Minimum Requirements  (info) Note, you may need to scroll up at the end to see this

or the superuser devops action appearing to succeed but not allowing a user to login to the web dashboard (see text),

15:08:15.457 [info] com.intercax.syndeia.cli.SyndeiaCli [] - Lagom Syndeia client
15:08:15.458 [info] com.intercax.syndeia.cli.SyndeiaCli [] - Action: setup
15:08:15.459 [info] com.intercax.syndeia.cli.SyndeiaCli [] - User: super.user
15:08:15.460 [info] com.intercax.syndeia.cli.SyndeiaCli [] - Mode: Prod
15:08:18.726 [info] akka.event.slf4j.Slf4jLogger [] - Slf4jLogger started
15:08:26.063 [error] com.intercax.syndeia.api.AuthApi [] - Sign in to Syndeia Cloud for super.user unsuccessful.
com.lightbend.lagom.scaladsl.api.transport.TransportException: {"statusCode":401,"message":"invalid.credentials","headers":{}}
        at com.lightbend.lagom.scaladsl.api.transport.TransportException$.$anonfun$fromCodeAndMessage$2(Exceptions.scala:223)
        at scala.Option.fold(Option.scala:175)
        at com.lightbend.lagom.scaladsl.api.transport.TransportException$.fromCodeAndMessage(Exceptions.scala:223)
        at com.intercax.syndeia.error.SyndeiaTransportException$.fromCodeAndMessage(SyndeiaTransportException.scala:29)
        at com.intercax.syndeia.error.SyndeiaExceptionSerializer.fromCodeAndMessage(SyndeiaExceptionSerializer.scala:9)
        at com.lightbend.lagom.scaladsl.api.deser.DefaultExceptionSerializer.deserialize(ExceptionSerializer.scala:100)
        at com.lightbend.lagom.internal.scaladsl.client.ScaladslServiceApiBridge.exceptionSerializerDeserializeHttpException(ScaladslServiceApiBridge.scala:82)
        at com.lightbend.lagom.internal.scaladsl.client.ScaladslServiceApiBridge.exceptionSerializerDeserializeHttpException$(ScaladslServiceApiBridge.scala:80)
        at com.lightbend.lagom.internal.scaladsl.client.ScaladslClientServiceCallInvoker.exceptionSerializerDeserializeHttpException(ScaladslServiceClientInvoker.scala:110)
        at com.lightbend.lagom.internal.scaladsl.client.ScaladslClientServiceCallInvoker.exceptionSerializerDeserializeHttpException(ScaladslServiceClientInvoker.scala:110)
        at com.lightbend.lagom.internal.client.ClientServiceCallInvoker.$anonfun$makeStrictCall$3(ClientServiceCallInvoker.scala:222)
        at scala.util.Success.$anonfun$map$1(Try.scala:255)
        at scala.util.Success.map(Try.scala:213)
        at scala.concurrent.Future.$anonfun$map$1(Future.scala:292)
        at scala.concurrent.impl.Promise.liftedTree1$1(Promise.scala:33)
        at scala.concurrent.impl.Promise.$anonfun$transform$1(Promise.scala:33)
        at scala.concurrent.impl.CallbackRunnable.run(Promise.scala:64)
        at akka.dispatch.BatchingExecutor$AbstractBatch.processBatch(BatchingExecutor.scala:55)
        at akka.dispatch.BatchingExecutor$BlockableBatch.$anonfun$run$1(BatchingExecutor.scala:91)
        at scala.runtime.java8.JFunction0$mcV$sp.apply(JFunction0$mcV$sp.java:23)
        at scala.concurrent.BlockContext$.withBlockContext(BlockContext.scala:85)
        at akka.dispatch.BatchingExecutor$BlockableBatch.run(BatchingExecutor.scala:91)
        at akka.dispatch.TaskInvocation.run(AbstractDispatcher.scala:40)
        at akka.dispatch.ForkJoinExecutorConfigurator$AkkaForkJoinTask.exec(ForkJoinExecutorConfigurator.scala:44)
        at akka.dispatch.forkjoin.ForkJoinTask.doExec(ForkJoinTask.java:260)
        at akka.dispatch.forkjoin.ForkJoinPool$WorkQueue.runTask(ForkJoinPool.java:1339)
        at akka.dispatch.forkjoin.ForkJoinPool.runWorker(ForkJoinPool.java:1979)
        at akka.dispatch.forkjoin.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:107)
15:08:26.066 [error] com.intercax.syndeia.cli.SyndeiaCli [] - {"statusCode":401,"message":"invalid.credentials","headers":{}}
com.lightbend.lagom.scaladsl.api.transport.TransportException: {"statusCode":401,"message":"invalid.credentials","headers":{}}
        at com.lightbend.lagom.scaladsl.api.transport.TransportException$.$anonfun$fromCodeAndMessage$2(Exceptions.scala:223)
        at scala.Option.fold(Option.scala:175)
        at com.lightbend.lagom.scaladsl.api.transport.TransportException$.fromCodeAndMessage(Exceptions.scala:223)
        at com.intercax.syndeia.error.SyndeiaTransportException$.fromCodeAndMessage(SyndeiaTransportException.scala:29)
        at com.intercax.syndeia.error.SyndeiaExceptionSerializer.fromCodeAndMessage(SyndeiaExceptionSerializer.scala:9)
        at com.lightbend.lagom.scaladsl.api.deser.DefaultExceptionSerializer.deserialize(ExceptionSerializer.scala:100)
        at com.lightbend.lagom.internal.scaladsl.client.ScaladslServiceApiBridge.exceptionSerializerDeserializeHttpException(ScaladslServiceApiBridge.scala:82)
        at com.lightbend.lagom.internal.scaladsl.client.ScaladslServiceApiBridge.exceptionSerializerDeserializeHttpException$(ScaladslServiceApiBridge.scala:80)
        at com.lightbend.lagom.internal.scaladsl.client.ScaladslClientServiceCallInvoker.exceptionSerializerDeserializeHttpException(ScaladslServiceClientInvoker.scala:110)
        at com.lightbend.lagom.internal.scaladsl.client.ScaladslClientServiceCallInvoker.exceptionSerializerDeserializeHttpException(ScaladslServiceClientInvoker.scala:110)
        at com.lightbend.lagom.internal.client.ClientServiceCallInvoker.$anonfun$makeStrictCall$3(ClientServiceCallInvoker.scala:222)
        at scala.util.Success.$anonfun$map$1(Try.scala:255)
        at scala.util.Success.map(Try.scala:213)
        at scala.concurrent.Future.$anonfun$map$1(Future.scala:292)
        at scala.concurrent.impl.Promise.liftedTree1$1(Promise.scala:33)
        at scala.concurrent.impl.Promise.$anonfun$transform$1(Promise.scala:33)
        at scala.concurrent.impl.CallbackRunnable.run(Promise.scala:64)
        at akka.dispatch.BatchingExecutor$AbstractBatch.processBatch(BatchingExecutor.scala:55)
        at akka.dispatch.BatchingExecutor$BlockableBatch.$anonfun$run$1(BatchingExecutor.scala:91)
        at scala.runtime.java8.JFunction0$mcV$sp.apply(JFunction0$mcV$sp.java:23)
        at scala.concurrent.BlockContext$.withBlockContext(BlockContext.scala:85)
        at akka.dispatch.BatchingExecutor$BlockableBatch.run(BatchingExecutor.scala:91)
        at akka.dispatch.TaskInvocation.run(AbstractDispatcher.scala:40)
        at akka.dispatch.ForkJoinExecutorConfigurator$AkkaForkJoinTask.exec(ForkJoinExecutorConfigurator.scala:44)
        at akka.dispatch.forkjoin.ForkJoinTask.doExec(ForkJoinTask.java:260)
        at akka.dispatch.forkjoin.ForkJoinPool$WorkQueue.runTask(ForkJoinPool.java:1339)
        at akka.dispatch.forkjoin.ForkJoinPool.runWorker(ForkJoinPool.java:1979)
        at akka.dispatch.forkjoin.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:107)

... please run them manually, ie:

export SC_HOME=/opt/icx/syndeia-cloud-current ; 
export SC_HOME_WIN=$(cygpath -w "${SC_HOME}") ; 
${SC_HOME}/devops-3.4/bin/devops -Duser.dir=${SC_HOME_WIN}\\\devops-3.4-sp3 -XX:+UnlockDiagnosticVMOptions -XX:LogFile=${SC_HOME_WIN}\\\logs\\\devops_JVM.log -DXloggc:devops_JVM_gc.log -Dsyndeia.client.action=superuser ;
${SC_HOME}/devops-3.4/bin/devops -Duser.dir=${SC_HOME_WIN}\\\devops-3.4-sp3 -XX:+UnlockDiagnosticVMOptions -XX:LogFile=${SC_HOME_WIN}\\\logs\\\devops_JVM.log -DXloggc:devops_JVM_gc.log -Dsyndeia.client.action=setup -Dsyndeia.client.username=super.user -Dsyndeia.client.password=syn45ia ;

(info)  If you wish to skip the automatic running of the devops actions at the end because you have an environment in which these actions do not succeed, you can pass the --skip_devops (or -s) parameter to the end of the script, ie:  ./bin/syndeia-cloud-3.4_install.bash --skip_devops  ((warning) Note, this does NOT mean that the devops actions are "optional", this is simply providing a mechanism for you to run them manually after your system has "caught its breath" so to speak.)


5. Validate correct operation and create/update an archive image to use as a new base image if the node needs to be rebuilt or if you wish to create a cluster. 

(info)  Before making the image you may wish to first stop and optionally disable Syndeia Cloud's services temporarily to prevent auto-start on boot, ie:  sc.exe '\\localhost' config <service_name> start=disabled ; where <service_name> = one of sc-auth|sc-store|sc-graph|sc-web-gateway|sc-aras|sc-artifactory|sc-bitbucket|sc-confluence|sc-doors|sc-github|sc-gitlab|sc-jama|sc-jira|sc-sysmlv2|sc-testrail|sc-twcloud|sc-wc.  



Managing Syndeia Cloud:

6. To check the status of Syndeia Cloud services, from a CMD.exe prompt run sc.exe '\\localhost' queryex <service_name>; where <service_name> = one of sc-auth|sc-store|sc-graph|sc-web-gateway|sc-aras|sc-artifactory|sc-bitbucket|sc-confluence|sc-doors|sc-github|sc-gitlab|sc-jama|sc-jira|sc-sysmlv2|sc-testrail|sc-twcloud|sc-wc

7. To stop/start the Syndeia Cloud services, run sc.exe '\\localhost' <action> <service_name>; where <action> = one of start|stop, and <service_name> = one of sc-auth|sc-store|sc-graph|sc-web-gateway|sc-aras|sc-artifactory|sc-bitbucket|sc-confluence|sc-doors|sc-github|sc-gitlab|sc-jama|sc-jira|sc-sysmlv2|sc-testrail|sc-twcloud|sc-wc

(info)  Note: If you wish to configure the services run on startup, run sc.exe '\\localhost' config <service_name> start=<start_type> ; where <service_name> = one of sc-auth|sc-store|sc-graph|sc-web-gateway|sc-aras|sc-artifactory|sc-bitbucket|sc-confluence|sc-doors|sc-github|sc-gitlab|sc-jama|sc-jira|sc-sysmlv2|sc-testrail|sc-twcloud|sc-wc.  and <start_type> = boot|system|auto|demand|disabled|delayed-auto.  For more information on controlling services run sc.exe /? 

(warning)  Windows has a limited degree of control over service start ordering but in general you will want to ensure that all your service start in the order of:  Cassandra, Janusgraph, Zookeeper, Kafka, SC (sc-store, sc-auth, sc-graph, sc-web-gateway, sc-<all_others>).  

8. To view the logs for any Syndeia Cloud service, see the appropriate service's log folder, ex:  c:\cygwin64\opt\icx\syndeia-cloud-current\<service_name>-3.4\logs where <service_name> = one of auth-impl,store-impl,graph-impl,web-gateway,aras-impl,artifactory-impl,bitbucket-impl,confluence-impl,doors-impl,github-impl,jama-impl,jira-impl,sysmlv2-impl,testrail-impl,teamworkcloud-impl,windchill-impl

(info)  Note:  there are 5 types of log files/streams generated:  access logs, Apache Commons daemon log, stdout (standard output), stderr (standard error), and the log from SC itself.  In a troubleshooting scenario you may wish to examine one or more of these.   



Validating Syndeia Cloud Installation & Configuration:

9. In a Command Prompt or Cygwin terminal session, launch a CQLSH session (see Appendix C3.3 for instructions) & verify if syndeia_admin has all the permissions on the syndeia keyspace, ie:

LIST ALL PERMISSIONS OF syndeia_admin;

10. On the server and/or your local machine, launch a web browser & check the following to validate that the application is correctly running:  

10.1.  http://<syndeia_server_FQDN>:9000 should give you:  

(info) To login as the default administrator and create users, see the User Management section. 

10.2  Once logged in, please verify you see a bar graph get rendered (and not a never-ending spinner followed by an error message) on the Dashboard home page and the version is shown correctly under Help > About in the sidebar..   



Loading