Red Hat provided EBS-based Amazon EC2 AMIs. Instances started from these instances can be customized and then saved to new AMIs through Amazon AWS console or API tools. This makes it harder though to keep track of these customizations. Without strict rules on documenting such changes, replaying them often becomes a big problem. Any customizations would have to be applied again when upgrading to newer version of Red Hat AMIs. Saving an AMI from a running instance additionally often requires cleaning up state such that sensitive data is removed and machine is brought back to the state before first boot.

Data which must be removed from such a copy before it can be used includes:

• system and application logs

• ssh keys host and authorized keys

• network interfaces persistent name rules

That's why the recommended approach is to keep customizations of the EAP and EWS AMIs in scripts. In this way you don't have to document the changes because you always have them all in one place and can always re-apply them. Additionally you don't have to lose time and money applying customizations to AMIs, saving them, keeping track of them, paying S3 storage for them, etc. Example scripts and how to use can be found in the Getting Started Guide above. In this appendix you can find some possible approaches for customizing your instances.

First it's a good practice to keep track of user-data script in a source control system like git, svn, mercurial, etc. It is possible to invoke such script similar to the below example.  One of the benefits is that if you change the script, you need to only restart instances and in case of auto-scaling, you don't need to redefine the group. For example:

## make sure communication with remote server is secure
cat > myca.crt << "EOF"
<Paste your certificate here. Using a custom certificate is only needed if using self-signed certificates or the certificate authority is not recognized>
EOF
wget --user=myuser --password=mypassword --ca-certificate=myca.crt https://.../myscript.sh
. myscript.sh

adding configuration directives:

echo "10.0.0.5    balancer" >> /etc/hosts

This is a simple approach but often you need to place some directives in a particular place in file or replace existing directives. This approach is not always possible.

sed approach:

sed -i -e's/LoadModule proxy_balancer_module/#\0/' /etc/httpd/conf/httpd.conf

This approach is good when having to change a few lines in a file you otherwise like to keep on defaults. Negative side is that not everybody feels comfortable using sed.

*mass adding or replacing contents of a whole configuration file:*

cat >/etc/httpd/conf.d/mod_cluster.conf <<"EOF"
  ## your long configuration file
EOF

downloading files separately:

wget \--user=myuser \--password=mypassword \--ca-certificate=myca.crt https://.../config.zip
unzip config.zip \-d /etc/httpd/conf.d

This approach is very convenient but make sure communication channel between instance and file server is secured or use server certificate verification. Also make sure your configuration files are not public accessible. You most probably would have to use this approach anyways when deploying your applications. Instead of using HTTP, another common approach is using scp/sftp.

There are a number of other common approaches like using xslt for xml configuration files, configuration management tools, etc. The intent of this document is not to cover them all but to present the intended way of applying instance customizations and to give some ideas about the implementation.