Difference between revisions of "Command Center SSH Bitbucket"

From Lingoport Wiki
Jump to: navigation, search
Line 4: Line 4:
 
Its possible to connect Command Center to Bitbucket without using HTTPS, but instead using Bitbucket. This type of connection is not possible via the standard Bitbucket Connector in the UI as that only supports HTTPS connections. Follow this procedure to leverage an SSH connection to Bitbucket.
 
Its possible to connect Command Center to Bitbucket without using HTTPS, but instead using Bitbucket. This type of connection is not possible via the standard Bitbucket Connector in the UI as that only supports HTTPS connections. Follow this procedure to leverage an SSH connection to Bitbucket.
   
  +
== Process Overview ==
### Github Repo for Storing Scripts
 
  +
* Creation of a GitHub repo for storing three custom scripts (Using GitHub as example for this)
  +
* Creation of a pub/private key in the Command Center Container
  +
* Adding the public key to Bitbucket Cloud Repository
  +
* Adding three custom scripts to the GitHub Repo
  +
* Creating a Custom Data Source in Command Center to access the three scripts
  +
* Leveraging the Custom Data Source from the desired Command Center Project
   
  +
== GitHub Repository ==
- Requires a repo to place Data Source Shell Scripts
 
  +
Create a new repository in GitHub that will be used for storing the three custom scripts.
- Similar in functionality to transforms
 
- Create top level directory for storing the scripts
+
* Create top level directory for storing the scripts
- This directory will contain the following three scripts as described
+
* This directory will contain the following three scripts as described later in the document.
  +
** clone.sh
later in the document.
 
- clone.sh
+
** pull.sh
- pull.sh
+
** pushfiles.sh
- pushfiles.sh
 
   
  +
== Bitbucket Cloud Repository Configuration ==
   
  +
=== Command Center Container ===
### Bitbucket Cloud Repo
 
   
  +
The Bitbucket repo requires a public key be added to it that is created in Command Center by the connecting user. Below is the process for creating the key to be shared with the Bitbucket Cloud Repo.
- Need an ssh public key created in the container
 
- Perform this within the container itself for Command Center
+
* Perform this within the container itself for Command Center
- Do not add a password to the key
+
* Do not add a password to the key pair when prompted
- The key will be in the tomcatuser home directory so it must be
+
* The key will be in the tomcatuser home directory so it must be created by the tomcatuser preferably.
  +
* You will need set tomcatuser to /bin/bash shell from /usr/sbin/nologin as part of the below actions
created by the tomcatuser preferably.
 
   
  +
Follow the below command after logging into the VM and then logging into the Command Center container as the root user.
**You will need set tomcatuser to /bin/bash shell from
 
/usr/sbin/nologin as part of the below actions**
 
 
Here is the output from the command line:
 
   
 
root@d9dfe772ea55:/usr/local/tomcat# chsh tomcatuser
 
root@d9dfe772ea55:/usr/local/tomcat# chsh tomcatuser

Revision as of 15:24, 4 February 2025

Connecting Command Center to Bitbucket using SSH

Background

Its possible to connect Command Center to Bitbucket without using HTTPS, but instead using Bitbucket. This type of connection is not possible via the standard Bitbucket Connector in the UI as that only supports HTTPS connections. Follow this procedure to leverage an SSH connection to Bitbucket.

Process Overview

  • Creation of a GitHub repo for storing three custom scripts (Using GitHub as example for this)
  • Creation of a pub/private key in the Command Center Container
  • Adding the public key to Bitbucket Cloud Repository
  • Adding three custom scripts to the GitHub Repo
  • Creating a Custom Data Source in Command Center to access the three scripts
  • Leveraging the Custom Data Source from the desired Command Center Project

GitHub Repository

Create a new repository in GitHub that will be used for storing the three custom scripts.

  • Create top level directory for storing the scripts
  • This directory will contain the following three scripts as described later in the document.
    • clone.sh
    • pull.sh
    • pushfiles.sh

Bitbucket Cloud Repository Configuration

Command Center Container

The Bitbucket repo requires a public key be added to it that is created in Command Center by the connecting user. Below is the process for creating the key to be shared with the Bitbucket Cloud Repo.

  • Perform this within the container itself for Command Center
  • Do not add a password to the key pair when prompted
  • The key will be in the tomcatuser home directory so it must be created by the tomcatuser preferably.
  • You will need set tomcatuser to /bin/bash shell from /usr/sbin/nologin as part of the below actions

Follow the below command after logging into the VM and then logging into the Command Center container as the root user.

   root@d9dfe772ea55:/usr/local/tomcat# chsh tomcatuser
   Changing the login shell for tomcatuser
   Enter the new value, or press ENTER for the default
         Login Shell [/sbin/nologin]: /bin/bash
   su - tomcatuser
   ssh-keygen -t rsa -b8192
   Generating public/private rsa key pair.
   Enter file in which to save the key (/usr/local/tomcat/.ssh/id_rsa):
   Creating directory /usr/local/tomcat/.ssh
   Enter passphrase (empty for no passphrase):
   Enter same passphrase again:
   Your identification has been saved in /usr/local/tomcat/.ssh/id_rsa
   Your public key has been saved in /usr/local/tomcat/.ssh/id_rsa.pub
   The key fingerprint is:
   SHA256:NwG7DJtfwj8FsXc6CWnkdzBrivXrs3rn4jkRDdUq5cc tomcatuser@d9dfe772ea55
   The key's randomart image is:
   +---[RSA 8192]----+
   |        . o o... |
   |         = +.+. .|
   |      . . X ==oo |
   |       * = Xo=+ E|
   |      o S = *o . |
   |       . = o.o   |
   |        . o ..   |
   |           o=..  |
   |          .+=B.  |
   +----[SHA256]-----+

- Add the key to the Bitbucket Account - This is performed on the Bitbucket Server

   -   SSH Key must be added to an account which has write access to the
       repo.
   -   Click on Settings Icon to left of the User Icon
   -   Select SSH Keys in the left column
   -   Click on Add Key
   -   Provide a label as appropriate
   -   Paste the public key (Be sure it's the public key!)
       -   In this example it is id\_rsa.pub
   -   Select Add key and the key should be listed as available

- Confirm the key has r/w access to the repo

The system doesn't allow for a shell to be used by tomcatuser, so it must temporarily be set to allow this for testing and setting up the ssh key.

    • You will need reset tomcatuser to /usr/sbin/nologin shell from

/bin/bash as part of the below actions**

   cd /tmp/
   git clone git@bitbucket.org:<username>/<repo>.git
   This key is not known by any other names
   Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
   Warning: Permanently added 'bitbucket.org' (ED25519) to the list of known hosts.
   exit (returns you to root user)
   chsh tomcatuser
   Changing the login shell for tomcatuser
   Enter the new value, or press ENTER for the default
         Login Shell [/bin/bash]: /usr/sbin/nologin

At this point the key has been validated in Bitbucket as working.

    • NOTE: At this point you have a working SSH key for Bitbucket. It's

important to realize that since this is in a container it will disappear upon reinstall/upgrade of Command Center. Making a backup of the .ssh directory and having it available for the future can help to reduce the effort of recreating this process when this occurs**


    1. Procedure


      1. Create a Repo for the required Shell Scripts


  • clone.sh
    • USER_NAME
    • REPO
    • BRANCH_NAME
  • pull.sh
    • BRANCH_NAME
  • pushfiles.sh
    • No modification needed

Add the contents below to each of the respective files, being sure to update the user_name/repo/branch where indicated.

clone.sh

   **Be sure to supply the USER_NAME, REPO, BRANCH where indicated**
   
       #!/bin/bash
       
       REPO="ssh://git@bitbucket.org/<USER_NAME>/<REPO>.git"
       BRANCH="BRANCH_NAME"
       
       echo "Using credential: ${CREDENTIAL_NAME}"
       
       echo "=================================================================="
       echo "Custom Clone Incoming variables:"
       echo ""
       echo "     CUSTOM_DIR      = ${CUSTOM_DIR}"
       echo "     WORKSPACES_DIR  = ${WORKSPACES_DIR}"
       echo "     WORKSPACE_NAME  = ${WORKSPACE_NAME}"
       echo "     REPO = ${REPO}"
       echo "     BRANCH = ${BRANCH}"
       
       echo "User running git clone is $(whoami)"
       
       # For Debugging
       GIT_SSH_COMMAND="ssh" git clone "$REPO" "$WORKSPACES_DIR/$WORKSPACE_NAME"
       ret=$?
       echo "Clone return status $ret"
       if [ $ret -ne 0 ] ; then
          exit 1
       fi
       
       # This use case only occurs when a clone was done prior and the branch was different from the desired one
       cur_branch="$(git rev-parse --abbrev-ref HEAD)"
       
       if [ "${cur_branch}" != "${BRANCH}" ] ; then
           echo "Branch was ${cur_branch} so switching to ${BRANCH}"
           git switch "${BRANCH}"
       else
           echo "Branch already at ${cur_branch}, no need to switch "
       fi
       
       cd ~/ || exit 1
       
       exit 0

pull.sh

   **Be sure to supply the branch where indicated**
   
       #!/bin/bash
       
       BRANCH="BRANCH_NAME"
       
       echo "Using credential: ${CREDENTIAL_NAME}"
       echo "=================================================================="
       echo ""
       echo "Custom Pull Incoming variables:"
       echo "     CUSTOM_DIR         = ${CUSTOM_DIR}"
       echo "     CLIENT_SOURCE_DIR  = ${CLIENT_SOURCE_DIR}"
       echo "     BRANCH = ${BRANCH}"
       
       echo "User running git pull is $(whoami)"
       
       # For Debugging
       cd "${CLIENT_SOURCE_DIR}" || exit 1
       GIT_SSH_COMMAND="ssh" git --git-dir="$CLIENT_SOURCE_DIR/.git" --work-tree="$CLIENT_SOURCE_DIR" pull
       ret=$?
       echo "Pull return status $ret"
       if [ $ret -ne 0 ] ; then
          exit 1
       fi
       
       # This use case only occurs when a clone was done prior and the branch was different from the desired one
       cur_branch="$(git rev-parse --abbrev-ref HEAD)"
       
       if [ "${cur_branch}" != "${BRANCH}" ] ; then
           echo "Branch was ${cur_branch} so switching to ${BRANCH}"
           git switch "${BRANCH}"
       else
           echo "Branch already at ${cur_branch}, no need to switch "
       fi
       
       cd ~/ || exit 1
       
       exit 0

pushfiles.sh

       #!/bin/bash
       echo "Using credential: ${CREDENTIAL_NAME}"
       
       echo "=================================================================="
       echo "CUSTOM_PUSH_FILES (${PUSH_TYPE})"
       echo ""
       echo "Custom Push Files Incoming variables:"
       echo "     CUSTOM_DIR        = ${CUSTOM_DIR}"
       echo "     CLIENT_SOURCE_DIR = ${CLIENT_SOURCE_DIR}"
       echo "     IMPORT_MESSAGE    = ${IMPORT_MESSAGE}"
       echo "     IMPORT_LIST_PATH  = ${IMPORT_LIST_PATH}"
       
       echo "User running pushfiles is $(whoami)"
       
       # run script
       cd "${CLIENT_SOURCE_DIR}" || exit 1
       echo "Files to import to the repo are: "
       cat "${IMPORT_LIST_PATH}"
       while IFS= read -r f; do
           git add "$f"
           ret=$?
           echo "Push add status $ret"
           if [ $ret -ne 0 ] ; then
               exit 1
           fi
       done < "${IMPORT_LIST_PATH}"
       git commit -m "${IMPORT_MESSAGE}"
       GIT_SSH_COMMAND="ssh" git push 
       ret2=$?
       echo "Push return status $ret2"
       if [ $ret2 -ne 0 ] ; then
          exit 1
       fi
       
       cd ~/ || exit 1
       
       exit 0


Create a new Custom Data Source

Once the scripts have been created, make the scripts accessible to Command Center by adding the directory as a new Custom Data Source

  • When naming the Custom Data Source consider using a name that will make it easily identifiable as to what repository and branch the Custom Data Source is pointing towards.
  • There will be one Custom Data source created for a single repo/branch used by Command Center
    • If two branches from the same repository are required, there will be two Custom Data Sources Required.


Leveraging the Custom Data Source from Command Center

At this point, when the Command Center Project is created, simply select the Custom Data Source as the Data Source Credential and you should be all set.