Using Pritunl with "pre-baked" EC2 AMI

Pritunl
1

Dear support team,

Our organization recently acquired an Enterprise subscription, and I have been exploring options for deploying Pritunl, particularly focusing on its integration with AWS Auto Scaling Groups (ASG). During this process, I encountered some challenges and observations that I would like to address:

  1. Setup Key Requirement: Each time a Pritunl server instance is initiated, it prompts for a setup key in the user interface to activate the server. This manual step poses a challenge to automating the deployment process within an auto-scaling environment.

  2. AMI-Based Deployment Observations:
    2.1 After creating an Amazon Machine Image (AMI) from a configured Pritunl server and deploying a new instance using this AMI, I observed that the setup key was not required upon first accessing the UI, which was expected.
    2.2 The new instance did not register as a distinct host; instead, it appeared identical to the original instance.
    2.3 Both the original and new instances operated concurrently without recognition of each other as separate entities.
    2.4 Notably, the only change was that the private IP address in the database updated to reflect the new instance’s IP.

Given these observations, I seek clarification on the following points:

  1. Expected Behavior: Is it standard for Pritunl instances cloned from an AMI to not recognize each other as separate hosts, and for the private IP address in the database to update accordingly?

  2. Automated Deployment in ASG: Is there a recommended approach to deploy Pritunl within an AWS Auto Scaling Group without manual intervention, such as entering the setup key? Specifically, are there best practices or automation strategies to facilitate seamless scaling of Pritunl servers in this environment?

I appreciate any guidance or resources you can provide to assist in achieving an automated and scalable Pritunl deployment on AWS.

Thank you for your support!

2

The setup key is only used to give the web console access to update the MongoDB URI in /etc/pritunl.conf, this file can be updated without a setup key.

The /var/lib/pritunl/pritunl.uuid file contains the host ID that identifies the host in the cluster. If this value is the same on multiple hosts it will create problems as multiple hosts attempt to update the same resources. This file needs to be deleted when adding additional hosts.

The issue with automatically scaling hosts is adding the hosts to the existing servers. This would need to be done with the API. It is easier to do with the new release that allows updating the replication count without stopping the server. Hosts could already be added without stopping a server. Although it is still a better option to set the replication count much higher than the expected number of hosts in the future. If the replication count exceeds the host count it will stop after all hosts are running. The API could then be used only to handle attaching a host to a server. There is no documentation for the API other then the example add_aws_ranges.py.

3

Hello @zachcampbell ,

Thank you for writing back to me.

Based on your explanation, it appears that using the setup key is not mandatory when configuring a host to connect to the same MongoDB database and be included under the license. Instead, executing pritunl set-mongodb <mongodb-endpoint> during the EC2 instance’s boot process should suffice. Could you please provide the correct sequence of command executions to enable hosts to join without using the web console?

Thank you!

4

The MongoDB URI must be either set with the command or directly in the /etc/pritunl.conf file and the /var/lib/pritunl/pritunl.uuid file must be deleted if there is one from an existing host. Then the server is started with sudo systemctl start pritunl.