Wednesday, October 23, 2013

Using the AWS CLI to get a public hostname



We use this for the next step,  amending Putty.


  • Assumptions : 
  • We know the instance-id 
  • We have a working CLI. 
So we use ec2-describe-instances 


C:\Users\Chris\.aws>
We use a filter to only get info for our instance. 
We use a query to only output the Public DNSNAME 
aws ec2 describe-instances 

--filters "Name=instance-id,
Values=i-xxxxxx"
 --query
 "Reservations[*].Instances[*].{dz:PublicDnsName}" 
--output  text



C:\Users\Chris\.aws>aws ec2 describe-instances --filters "Name=instance-id,Value
s=i-xxxxxxxx" --query "Reservations[*].Instances[*].{dz:PublicDnsName}" --output
 text
ec2-255-255-255-5255.eu-west-1.compute.amazonaws.com


So now we have our public DNSNAME, and with that we can change our putty settings ! 

Getting the Amazon SDK Running.

Hi folks we will talk about getting Amazon AWS command line tools

We assume you have signed up with Amazon and given them your credit card etc etc.

First thing to do is download the Windows installer from


http://aws.amazon.com/cli/


https://s3.amazonaws.com/aws-cli/AWSCLI64.msi


this is 5.7 mb currently .  So when you run that



So accept the license and click next next next 




So the next thing to do is to follow the rest of  http://docs.aws.amazon.com/cli/latest/userguide/cli-chap-getting-set-up.html


If we look at our PATH setting now by opening a command window we can see that AWSCLI has been added to the end of the variable, usually c:\program files\Amazon\AWSCLI
If we now try 

C:\Users\Chris>aws

usage: aws [options] [parameters]
aws: error: too few arguments

C:\Users\Chris>

it is evident we must do a lot of things to get it all configured to start talking to our instances. 

First thing to do is to look at getting the config file set up. 

This will need to be in a directory .aws, so usually %USERPROFILE%\.aws\config

C:\Users\Chris>mkdir .aws


C:\Users\Chris>cd .aws

C:\Users\Chris\.aws>dir
 Volume in drive C is OS
 Volume Serial Number is F619-A748

 Directory of C:\Users\Chris\.aws

23/10/2013  12:43    

         .
23/10/2013  12:43    

         ..
               0 File(s)              0 bytes
               2 Dir(s)  13,599,453,184 bytes free


So what will this config file contain ?  Well this is the important credential and region information. 

We see an example in the getting started 

[default]
aws_access_key_id = AKIAIOSFODNN7EXAMPLE
aws_secret_access_key = wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY
region = us-west-2


OK so where do we get our values.

Region should be easy as it is where you will be doing most of your work for me that will be eu-west-1

yours will probably be different. 

OK that was easy.  For our access key and secret we got these when we signed up first for AW.  You can get them from https://portal.aws.amazon.com/gp/aws/securityCredentials

So edit the liitle config file with the relevant information in it 



 Directory of C:\Users\Chris\.aws

23/10/2013  12:56    
         .
23/10/2013  12:56    
         ..
23/10/2013  12:57               137 config
               1 File(s)            137 bytes
               2 Dir(s)  13,595,860,992 bytes free


C:\Users\Chris\.aws>


One point to note is that if you are using notepad to edit the config file it saves it as .txt which is wrong it needs to be just called config. 

OK so let's give it a try 

C:\Users\Chris\.aws>aws ec2 describe-regions|more

{
    "Regions": [
        {
            "Endpoint": "ec2.eu-west-1.amazonaws.com",
            "RegionName": "eu-west-1"
        },
        {
            "Endpoint": "ec2.sa-east-1.amazonaws.com",
            "RegionName": "sa-east-1"
        },
        {
            "Endpoint": "ec2.us-east-1.amazonaws.com",
            "RegionName": "us-east-1"
        },
        {
            "Endpoint": "ec2.ap-northeast-1.amazonaws.com",
            "RegionName": "ap-northeast-1"
        },
        {
            "Endpoint": "ec2.us-west-2.amazonaws.com",
            "RegionName": "us-west-2"
        },
        {
            "Endpoint": "ec2.us-west-1.amazonaws.com",
-- More  --



OK... all working

In the next post we will show how to grab some value out of this.

Tuesday, August 27, 2013

Puppet Certificate Store.

If you are using Puppet, and in particular if you are using it to install modules from the main Puppet repository, you may run into an issue.

Specifically this is when the puppet module complains that the puppet server certificate is not valid.


Symptom : Redhat 6.4

Puppet latest version.

After a lot of messing around with openssl ( which turned out not to be the problem )  we went back to concentrating on Puppet.

Puppet expects to see the list of trusted server certificates in

/etc/pki/tls/cert.pem ( we only found this via strace -f )

if it cannot find it then you will get the error.

In a default setup this cert.pem file doesn't exist and needs to be linked in.

The list of certs is happily available in the certs/ca-bundle.crt file.

So :

ln -s cert.pem certs/ca-bundle.crt

and now Puppet module install works just fine.

Regards

Chris.

Monday, June 17, 2013

VMWARE tools on OEL6



Problem : VMWARE tools installing on Oracle Enterprise Linux 6

Problem :  vmware-config-tools cannot find the Kernel headers, even though yum sttes they are installed.

Solution :   yum -y install kernel-uek-devel.x86_64


then re-run vmware-config-tools. 

All done

Regards

Chris. 

Cloud Control 12c MIscellaneous issues



Cloud Control Refused to start at boot ( OMS not started, and agent not started).  This was an upgraded Cloud control with several restarts of the process, but it completed successfully.

After much shell script tracing the issue turned out to be a messed up oragchomelist file in /etc

there were several wrong entries in it.

For a non-oms machine the config of this file should be a single line

$AGENT_HOME:$AGENT_INSTANCE_HOME

see ML 1386113.1 note for more details..

 Further, if this is actually an OMS  machine there will be a 2nd line 

$AGENT_HOME:$AGENT_INSTANCE_HOME
$OMS_HOME

where $OMS_HOME=$MIDDLEWARE_HOME/oms , usually.

Once you set this up properly, OMS And agents will all start up nicely.

Regards

Chris.

Friday, May 17, 2013

Upgrading to EM Cloud Control 12c

It looks like Linux 6.3 targets aren't supported... but they are, there is a bug fix on Metalink

get what you need ( a .sql file ) from PUC: Linux 6.x Agents are shown as Unsupported in the Enterprise Manager 12c Upgrade Console [ID 1545450.1]




Thursday, May 2, 2013

Connecting to Work Repository in ODI

One problem I had run into when connecting to ODI was being unable to connect to a work repository remotely.  After debugging this problem it came down to the fact that the hostname resolution was not what was expected; I was using an IP address to connect and this was what was causing the issue.


When ODI Studio has a connection created,  for the master repository it uses the JDBC Url you type in , which is OK as :port:sid

However when it comes to connecting to the Work repository, the studio goes back to the server, and downloads the JDBC URL connection information for it from the Master Repository.   This URL has the hostname for the database server embedded, NOT the IP address, and if you cannot resolve the hostname , you won't be able to connect to the database server; thus Work Repository Connections will fail.

There are two resolutions

1: Enable NS resolution of the db server, either via hosts file or DNS
2:  Edit the Repository definition of the URL via clicking into the Work Repository Definition from the Master, clicking the plug icon, then JDBC , then editing the host= to be host=IP ADDRESS. 


Once either of these are done, then it will work like a top !

The symptom of this issue is ODI-10182