Difference between revisions of "Command Center SSH Bitbucket"
(6 intermediate revisions by the same user not shown) | |||
Line 1: | Line 1: | ||
+ | = Connecting Command Center to Bitbucket using SSH = |
||
− | *clone.sh |
||
− | **USER_NAME |
||
− | **REPO |
||
− | **BRANCH_NAME |
||
− | *pull.sh |
||
− | ** BRANCH_NAME |
||
− | *pushfiles.sh |
||
− | ** No modification needed |
||
+ | == Background == |
||
− | Add the contents below to each of the respective files, being sure to |
||
+ | 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. |
||
− | update the user_name/repo/branch where indicated. |
||
+ | |||
+ | == 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 Initial Setup == |
||
+ | 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]-----+ |
||
+ | |||
+ | Copy the public key that was created as it will need to be input into the Bitbucket Cloud Repo for the account that is being leveraged in Bitbucket. Note this key is applied at the user level and not the repository level. |
||
+ | |||
+ | === Bitbucket Cloud Repo === |
||
+ | |||
+ | Log into the Bitbucket Cloud Server as user as the user the key will be applied. The 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 as noted in the next section |
||
+ | |||
+ | === Command Center Container === |
||
+ | |||
+ | Return to the Command Center Container to perform a connection test to the desired repository. You should still be tomcatuser at this point. If not, switch to tomcatuser as before. Perform the below activities and then be sure to switch the tomcatuser shell back to nologin. |
||
+ | |||
+ | 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. |
||
+ | |||
+ | <B>NOTE:</B> 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 in the container and having it available offline for the future can help to reduce the effort of recreating this process when this occurs |
||
+ | |||
+ | == Script Additions to GitHub Repository == |
||
+ | Add the custom scripts listed below to the repository directory in GitHub that previously created. Be sure to update the scripts with your custom information as the scripts will not work as written, the details are required. |
||
+ | * clone.sh |
||
+ | ** Requires the following to be updated |
||
+ | *** USER_NAME |
||
+ | *** REPO |
||
+ | *** BRANCH_NAME |
||
+ | * pull.sh |
||
+ | ** Requires the following to be updated |
||
+ | *** BRANCH_NAME |
||
+ | * pushfiles.sh |
||
+ | ** No modifications are required in this script. |
||
=== clone.sh === |
=== clone.sh === |
||
Line 18: | Line 113: | ||
REPO="ssh://git@bitbucket.org/<USER_NAME>/<REPO>.git" |
REPO="ssh://git@bitbucket.org/<USER_NAME>/<REPO>.git" |
||
− | BRANCH="BRANCH_NAME" |
+ | BRANCH="<BRANCH_NAME>" |
echo "Using credential: ${CREDENTIAL_NAME}" |
echo "Using credential: ${CREDENTIAL_NAME}" |
||
Line 61: | Line 156: | ||
#!/bin/bash |
#!/bin/bash |
||
− | BRANCH="BRANCH_NAME" |
+ | BRANCH="<BRANCH_NAME>" |
echo "Using credential: ${CREDENTIAL_NAME}" |
echo "Using credential: ${CREDENTIAL_NAME}" |
||
Line 138: | Line 233: | ||
== Create a new Custom Data Source == |
== Create a new Custom Data Source == |
||
+ | Once the scripts have been created and placed into the GitHub repository, make the scripts accessible to Command Center by adding the directory as 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. |
* 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 |
* 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. |
** 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 == |
== 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 |
+ | At this point, when the Command Center Project is created, simply select the Custom Data Source as the Data Source Credential. Once the project is created, it should leverage the scripts to perform any operations required on the Bitbucket repo. Initially it should show the list of resource files that are found when running validation. That is a good check for the clone.sh and pull.sh scripts. The pushfiles.sh is used when committing files back into the repository so that could take the form of a returned translation, or even a pseudo-localization file. |
Latest revision as of 15:48, 4 February 2025
Contents
- 1 Connecting Command Center to Bitbucket using SSH
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 Initial Setup
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]-----+
Copy the public key that was created as it will need to be input into the Bitbucket Cloud Repo for the account that is being leveraged in Bitbucket. Note this key is applied at the user level and not the repository level.
Bitbucket Cloud Repo
Log into the Bitbucket Cloud Server as user as the user the key will be applied. The 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 as noted in the next section
Command Center Container
Return to the Command Center Container to perform a connection test to the desired repository. You should still be tomcatuser at this point. If not, switch to tomcatuser as before. Perform the below activities and then be sure to switch the tomcatuser shell back to nologin.
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 in the container and having it available offline for the future can help to reduce the effort of recreating this process when this occurs
Script Additions to GitHub Repository
Add the custom scripts listed below to the repository directory in GitHub that previously created. Be sure to update the scripts with your custom information as the scripts will not work as written, the details are required.
- clone.sh
- Requires the following to be updated
- USER_NAME
- REPO
- BRANCH_NAME
- Requires the following to be updated
- pull.sh
- Requires the following to be updated
- BRANCH_NAME
- Requires the following to be updated
- pushfiles.sh
- No modifications are required in this script.
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 and placed into the GitHub repository, 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. Once the project is created, it should leverage the scripts to perform any operations required on the Bitbucket repo. Initially it should show the list of resource files that are found when running validation. That is a good check for the clone.sh and pull.sh scripts. The pushfiles.sh is used when committing files back into the repository so that could take the form of a returned translation, or even a pseudo-localization file.