Tentacles with Identical Thumbprints

Legacy Uncategorised
1

Hello, Can Tentacles have the same thumbprint? I’ve seen conflicting notes in the documentation, and am wondering about this.

2

Hi,

Thanks for getting in touch! Unfortunately when a Tentacle is copied or cloned it CAN have the same thumbprint as another machine. Should it? No and never are two words that come to mind.
Tentacle communication is based on thumbprints and SQUIDs and if they are shared deployments and communication and health checks all go very wrong. We even block deployments that register that two machines have the same thumbprint and or SQUID.

Hopefully that answers your question. If you could point me at any conflicting documentation I can fix that right up.

Thanks!
Vanessa

3

Here is the article I found about being able to generate a certificate on one machine, export it to a file, and then import that certificate when provisioning Tentacles.

I was able to follow this process to automate the install of the tentacle on two separate servers using the same thumbprint. Both servers are reporting Healthy in the Octopus Deploy console. The SQUIDs are indeed different on both machines, but the thumbprint is the same.

  • Q
4

A little background into our environment:

We utilize vCloud in our DEV Environment. We have a “Staging Environment” (just another DEV environment) that consist of three servers + SQL server. This environment is constantly updated during our weekly releases. Once this environment has the latest release and is QA certified, we capture this exact environment into the vCloud Catalog.

Each time our developers need to get a new environment with all the changes from the latest release, they would delete their current DEV environment and then check out the latest environment from the Catalog (which is a linked clone of the same exact machines in our Staging Environment) and then go on with their development work. Each environment is fenced off from seeing each other by a vShield Edge firewall so identical machines can be running on the network without conflict.

We would like to deploy Octopus Tentacles to our various DEV environments and register each machine with the OctopusDeploy server so we can automate builds and deployments to them. This means we will have Octopus Tentacles on the servers in our Staging Environment and need to come up with a solution to address the issue with the Tentacle Agents after we re-base an environment from the vCloud Catalog.

What would be the best way to accomplish this to allow the OctopusDeploy server to see each of these machines again across all our DEV environments after being re-based? We would like to avoid having to reinstall the Octopus Tentacle on each server and re-registering with the OctopusDeploy server after a re-base.

  • Q
5

Hi Q,

The short answer to this is using PowerShell DSC.

Essentially that should pull down the latest Tentacle installer, run it then register it against the Octopus Server with an API key and the machine role and environment.

The other thing you need to consider is when you deprovision a machine you need to remove it from the Octopus Server. You can do this via the API, either as part of your “tear down a machine” script. or do something like poll for offline machines and deregister them.

That’s a starting point, does that make sense ? Happy to dig deeper when you’re ready.

Regards

Damian

6

Hi Damian,

Thanks for getting back to me. I wanted to run this process by you to see if this may be a viable solution.

Initial install and configuration

  1. Install Tentacle on machine
  2. Create a custom certificate and export it to a central share
  3. Import the custom certificate for this machine
  4. Configure and register this machine with the OD server
  5. Backup the C:\Octopus\Tentacle\Tentacle.config (contains the SQUID and Thumbprint) for this machine to a central share

Restore Tentacle configuration and Thumbprint

  1. OD server detects a Tentacle is unhealthy (can’t communicate to it after a re-base)
  2. OD server triggers machine to restore machine specific Tentacle.config file
  3. OD server triggers machine to stop Tentacle Service
  4. OD server triggers machine to import custom certificate from central share
  5. OD server triggers machine to start Tentacle Service

Now, the re-based server should have the same SQUID/Thumbprint as what the OD Server knows it by. Will this process work to restore communication between the OD Server and the Tentacle on the machine?

  • Q
7

Hi Q,

Very sorry about the delay in getting back to you. I had Paul run a quick eye over this, and your proposed solution should work fine.

Vanessa