Citrix TIPs: Creating an AMI from a launched Citrix ADC instance in AWS

Gather around for Jill and the Elastic Beanstalk: A Boot Time Story!

One sunny, fairy-tale, work-from-home afternoon, I was deploying an HA pair of Citrix ADCs in AWS using the Quickstart Cloud Formation Template. No big deal, right?

Well, it just so happened that at that very moment, the ADC AMI was being updated in the AWS Marketplace to the latest version. The first Citrix ADC came out with the older version, and the second came out with the new one. My dreams of having a working HA pair were crushed (until I upgraded, of course).

All kidding aside, this could potentially be an issue for AWS Quickstart deployments and AWS Auto Scaling. Think about spinning up ADC instances for the morning logon storm and have half of them be a different version. It’s fine if they are all standalone with GSLB between, but it’s bad news if they are paired.

I recently wrote a run guide for moving a VPX AMI into an air-gapped AWS cloud with no Marketplace, including how to make a VPX AMI “bootable.” With this “zero-izing” process, we can create VPX AMIs to use for Quickstarts and Auto Scaling to ensure version consistency across instances. As an added bonus, you can now create AMIs from existing instances of previous versions to keep in case of failure or regeneration. This process is also helpful in the event that an ADC requires patching or upgrades or a new version that may not be in the Marketplace in your region yet. Leave yourself a trail of breadcrumbs by creating your own ADC AMI!

Let’s Climb the Beanstalk Together!

1. Log into the Citrix ADC instance. Go into the shell to perform the necessary modifications as root.

shell

2. Forcefully and recursively remove the following directories and files from the ADC software manually. To remove the files and directories manually, add rm –rf in front of each.

‘/nsconfig/ns.conf’
‘/nsconfig/ssh/’
‘/nsconfig/ssl/’
‘/nsconfig/aws_bootstrap’
‘/nsconfig/rainman.conf’
‘/var/nslog’
‘/var/log/messages’
‘/var/log/.log’
‘/var/core/’
‘/nsconfig/.AWS/’
‘/var/db’
‘/etc/resolv.conf’
‘/flash/BUILD’
‘/mpsconfig/pgxl/.ssh/id_rsa.pub’
‘/var/pubkey/nsroot/.ssh/authorized_keys’
‘/var/pubkey/root/.ssh/authorized_keys’

or run this script:

#!/bin/sh -x
rm -rf /nsconfig/ns.conf*
rm -rf /nsconfig/ssh/*
rm -rf /nsconfig/ssl/*
rm -rf /nsconfig/aws_bootstrap
rm -rf /nsconfig/rainman.conf
rm -rf /var/nslog
rm -rf /var/log/messages*
rm -rf /var/log/*.log
rm -rf /var/core/*
rm -rf /nsconfig/.AWS/
rm -rf /var/db
rm -rf /etc/resolv.conf
rm -rf /flash/BUILD
rm -rf /mpsconfig/pgxl/.ssh/id_rsa.pub
rm -rf /var/pubkey/nsroot/.ssh/authorized_keys
rm -rf /var/pubkey/root/.ssh/authorized_keys

3. Change the permissions on the /flash/nsconfig directory to 755.

chmod 755 /flash/nsconfig

4. Verify that there are no residual keys remaining. If there are, forcefully and recursively remove them.

find / -type f -name “authorized*”
rm -rf &lt;filename&gt;

5. Verify that no residual licenses exist in /nsconfig/license. If there are, forcefully and recursively remove them.

Please note, there will be other directories and files in this folder (for example SSL and XML), so only remove license files if present.

ls /nsconfig/license
ls /nsconfig/license/ssl
ls /nsconfig/license/xml

6. Power off the machine from the AWS console. Once the instance has stopped, create an AMI from the instance.

7. Once the AMI is ready, deploy an instance from it to verify functionality.

Your golden egg image is now ready to roll!

Stay tuned for my next blog on leading practices for Citrix ADC in AWS and be sure to check out the latest deployment guides for ADC on AWS for Autoscaling, GSLB, and Disaster Recovery.

Topics

Products