Vagrant on AWS with Windows

Required installations:
– AWS CLI
– VirtualBox
– Vagrant
– an existing EC2 instance with an account private key on your local file system.

[Optional] If you use PuTTy ssh client, you may want to install and configure the Vagrant PuTTY plugin, by following instructions here: https://github.com/nickryand/vagrant-multi-putty. You will also need to make a symbolic link to the executable, using the following command.

> mklink D:\Vagrant\embedded\bin\putty.exe "C:\Program Files (x86)\PuTTY\putty.exe"

(1) Use the AWS CLI/Security Token Service to generate temporary credentials for AWS

> aws sts get-session-token  

The credentials returned by this command will be valid for 1 hour.

(2) Install the Vagrant AWS plugin.

> vagrant plugin install vagrant-aws

(3) Add the “dummy” Box provided by the vagrant-aws project. This is a barebones Box compatible with AWS. We will flesh this out in the Vagrantfile to be created in the next step.

> vagrant box add dummy https://github.com/mitchellh/vagrant-aws/raw/master/dummy.box

(4) Create a new directory to hold files for this Vagrant instance. I’m calling this vagrant-aws.

> mkdir vagrant-aws

(5) With your favorite text editor create a file called Vagrantfile inside this new directory. Edit this file vagrant-aws\Vagrantfile copying and pasting the following to the file (source).

Vagrant.configure("2") do |config|
  config.vm.box = "dummy"

  config.vm.provider :aws do |aws, override|
    aws.access_key_id = "YOUR KEY"
    aws.secret_access_key = "YOUR SECRET KEY"
    aws.session_token = "SESSION TOKEN"
    aws.keypair_name = "KEYPAIR NAME"

    aws.ami = "ami-7747d01e"

    override.ssh.username = "ubuntu"
    override.ssh.private_key_path = "PATH TO YOUR PRIVATE KEY"
  end
end

(6) Now edit this text with the credentials returned by AWS STS (from above). You can use a different AMI (the current one given is for Ubuntu 12.04 x64) or change many other options, as described in the Vagrant AWS plugin documentation.

(7) Now you can bring the instance up with Vagrant, first making sure you are in the directory where you had created the Vagrantfile.

> cd vagrant-aws
> vagrant up

To work on your new Vagrant VM, use vagrant ssh or vagrant putty if you set up Putty using the plugin mentioned below. Once you’re finished, you can use vagrant destroy to completely blow away this instance, or some other vagrant command if you need to come back to the instance.

Next: The local VM

I'm back!

I'm back from my cross country bike ride!  On a completely different topic, my book with Packt Publishing, is finished and available for pre-order on Amazon, Barnes and Noble, and other fine book retailers:

Out to ride -- back sometime in September

I'm on a cross country bike ride!

My progress as of 8/4/15:

Photos

cakephp controller save from scaffolded "join table" relationship, non-conventional primary keys

When I build interfaces on top of a pre-established database schema, I usually can't change schema properties.  That's a problem when working with a "convention over configuration" MVC Framework like cakephp.

After baking/scaffolding a CRUD interface based on a "join table" (HABTM) class, that issue came into focus, once again.  I have had run into some fairly easily resolvable issues involving some non conventional naming in the schema, such as primary key names.  I had primary key names from different tables that included the table prefix as well as irregular pluralization in the names.  Initially I wasn't able to get my dropdowns to populate from related tables, as described in the previous post.  Then I ran into an even stickier problem: the save method would fail on validation in the add method of the join table controller.

As it turned out, the form helper input method, though it would accept various names (probably cake-conventional) to refer to itself and to the primary key field, would not accept the ACTUAL name of the primary key field (which, while cake-unconventional, was actually set in both its own class model using $primaryKey and the join model using $foreignKey -- BTW, the same name was in use in the join table database, so this was really convention over configuration coming back to bite me).

To fix this I added the following to the controller to remap the cake-conventional failing field names to the actual (working!) field names:




I discovered, subsequently, that defining foreignKey (of parent) in child class models fixes some issues ... may even fix issue that I describe above.

Relates to: Cakephp SQL Error 1054 Unknown Column In The Field List (id column)

Auto-populate Bake/Scaffold Form in cakephp

To my knowledge, there's no way to "autopopulate" a form created through cakephp's bake/scaffold utility.  Populating of the forms are also not well documented.  Here's how you do it, with a related table via foreign key in the database.

Applying Patches on ArcGIS Server for Linux (as root)

For various reasons, I had found I needed to be root to install ArcGIS Server on Centos.

I ran into my first problem with that configuration on patching, when the script halts with the following message "You must install this [patch] as ArcGIS Server Owner, do not install it as ROOT user."  I was able to successfully bypass this by commenting out this if block from the patch script (applypatch).

... so far, so good.

ArcGIS Server on Centos, continued

When our cluster was upgraded, I somehow lost the ability to run ArcGIS Server. No problem, I said, I'll just rebuild the machine. This is where I was again reminded that ArcGIS Server installation is very different from other Linux software.

The biggest issue is that ArcGIS installers will only run when logged in root.  Yeah, not running a bash as root, or sudo'ing as root, or su'ing to root ... you actually have to log in as root.

Herein lies the difficulty: the rest of the installer assumes a GUI (e.g., gnome or kde).  You can't login to gnome or kde as root.

If you're doing best practice X tunneling with SSH, then you're using private/public keys.  So make sure that you create a .ssh profile with keys and copy over the authorized_keys directory from your normal user.  I think this is where my immediate stumbling block was: when I first did this I wasn't thinking as much about security, just seeing if it would work.  I didn't use keys.  When I rebuilt the system, I did ... and of course I disabled plaintext passwords.  I didn't even consider that I'd want to login as root through X/SSH, but I'd guarantee that's how I did it the first time.  This was also an issue with X, specifically, because X settings (e.g., $DISPLAY) would only be set for the logged in connection (my normal login) and not root, if not connected directly with root.

[root@host]# ssh-keygen

[root@host]# cd .ssh/authorized_keys .

Finally, of course, everything ArcGIS runs through Wine on Linux (the Windows compatibility layer).  It turned out there was a profile directory that was owned by another use

# chown -R root /root/arcgis/server/framework/runtime/.wine

Also two other things I found out during this process:

1. set is a great command for debugging.  I put set -x at the top of authorizeSoftware and this gave me all kinds of great diagnostic info, including THE LOCATION OF THE LOGS!!
2. the software authorization log was located under: /root/arcgis/server/.Setup/softwareauthorization.log

Thanks, Dean Nairn!