hesco has asked for the wisdom of the Perl Monks concerning the following question:


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 `; }
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 +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 #!
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'); 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); }
My starts out:

#!/bin/bash set -e -x apt-get --yes update apt-get --yes upgrade apt-get --yes install subversion build-essential etc . . .
if( $lal && $lol ) { $life++; }
if( $insurance->rationing() ) { $people->die(); }