UPDATE:

TIMTOWTDI, I suppose. After opening and reading the user_data file, and encode_base64() to the scalar collected by iterating over it, I still got nowhere. The Anonymous monk below points me back to the source documentation, where I find nothing on this particular question, but did discover a whole new library of perl code to adapt from, using a different perl module than the one I've been working with. The one I'm working with was updated less than two weeks ago, but its perldoc gives me no further guidance.

So, alas, I tried this, instead and it seems to be doing the trick:

      if($build_config_instance){
        my $host = 'root@' . $instance->dns_name();
        my $scp = "scp -i $pvt_key $base_path/$build_script $host:/roo
+t/";
        print STDERR "\nssh -i $pvt_key $host chmod +x /root/$build_sc
+ript \n";
        print STDERR "ssh -i $pvt_key $host /root/$build_script \n";
        `$scp`;
        `ssh -i $pvt_key $host chmod +x /root/$build_script `;
        `ssh -i $pvt_key $host /root/$build_script `;
      }
[download]

Well my shell script bombed out after 16m47.233s, but only a few lines from the end. Walked around that issue, I guess. Now to debug my bash script which builds this server.

---

Original post . . .

I sure would appreciate some clues on how to move past this one.

For those unaware, the Amazon Cloud API permits passing 'UserData' across the invocation. There is a size limit, but even so, it provides a useful way to pre-configure an instance as it is brought online. At least that is the theory. Some AMI Machine Images are set up to look at that UserData and feed it to an appropriate interpreter as the root user to help that process along.

The $ec2->run_instances() method takes a UserData key, whose value the perldoc says: 'Needs to be base64 encoded.' I used MIME::Base64::encode_base64() to give it its favorite food. And to show me its gratitude, it throws the following error at me:

Oct  4 02:15:51 svrname S70ec2-get-credentials: New ssh key added to /
+root/.ssh/authorized_keys from http://169.254.169.254/1.0/meta-data/p
+ub
lic-keys/0/openssh-key
Oct  4 02:15:52 svrname S71ec2-run-user-data: Retrieving user-data
Oct  4 02:15:52 svrname S71ec2-run-user-data: Skipping user-data as it
+ does not begin with #!
[download]

If I try it without the encode_base64() I get Invalid BASE64 encoding of user data instead.

Here is a piece of the code which I think will reproduce this error; as well as a snip from the shell script its being fed, sporting a fresh #!/bin/bash interpreter line.

Any ideas on how to make my interpreter line more apparent than it already is?

#!/usr/bin/perl
use strict;
use warnings;

use Data::Dumper;
use Net::Amazon::EC2;
use MIME::Base64;
my $ec2 = Net::Amazon::EC2->new(
                AWSAccessKeyId => 'not-telling',
               SecretAccessKey => 'not-telling-this-either' );

my $custom_ami_id = 'ami-ff46a796';
my $user_data = encode_base64('/home/hesco/sandbox/EC2/trick_out_my_se
+rver.sh');

if($create_new_instance){
  my $instance = $ec2->run_instances(
     'Placement.AvailabilityZone' => 'us-east-1a',
                          KeyName => 'aws_test',
                    SecurityGroup => 'asterisk',
                          ImageId => $custom_ami_id,
                         UserData => $user_data,
                         MinCount => 1,
                         MaxCount => 1 );

  print STDERR Dumper($instance);
}
[download]

My trick_out_my_server.sh starts out:

#!/bin/bash
set -e -x

apt-get --yes update
apt-get --yes upgrade
apt-get --yes install subversion build-essential etc . . .
[download]