Good News from the BVI !!

Captain Devon tells me the BVI is healing and on its way to a full recovery

Here are some of the pictures he sent me today. These photos are from Cooper Island
where he took us snorkeling for the day. But the Restaurant and bar were boarded up for the end of season when we were there.

Also while snorkeling Debra and I spotted a giant Mana Ray about 25 feet down which prompted her quick return to the boat 🙂 and taking up my offer of a Carib beer.

But I am glad to see they are making a recovery and hopefully they are spared in the future.

So I will most definitely be returning to the BVI this year for some Sailing, fishing and snorkeling. Come join me here :


IAM Secure with AWS, layers & obscurity

I was recently posed with the how we / I managed multiple bucket security and all I could recollect is the Roles and tokens involved in managing these containers. Additionally I have always worked in concert always with the API and support as well as my DevOps Team mates. Firstly several logins are between the request and the final api call that is bound by AWS Key and the Canonical UserID. But those buckets are assigned externally to us based on Role and essentially that is how it is done. Also the data of concern even if human readable is an absolute island and belongs to no specific user until arrives back in the system (this step requires planning on how build out your model). Here is how that breaks down:

STAGE 1 : Create the S3 Bucket and Role

STAGE 2 : Grant Access to the Role

STAGE 3 : Test Access by Switching Roles


A Cross-account IAM Role is used to define access to resources in a single account, but it isn’t restricted to users in a single account. For example: The EC2 servers in your staging environment can safely get access to an S3 bucket in production by using a properly defined role to do so. Cross-account Role is the right tool to comply with best practices and simplify the credential management, as it gets rid of the need for credential management for third parties.

We will simulate a case where we use a role in Production Account S3 bucket to the users that are in Staging AWS Account.

You’ll share resources of one account with users in a different account. By setting up cross-account access this way, you don’t need to create individual IAM users in each account, and users don’t have to sign out of one account and sign into another in order to access resources that are in different AWS accounts. After configuring the role, you’ll see how to use the role from the AWS Management Console, the AWS CLI, and the API.

Here is a quick walk through of tasks that we will perform:

Stage 1 – Create an S3 Bucket and Roles

First, you use the AWS Management Console to establish trust between the Production Account and the Staging Account by creating an IAM role named StageRole. When you create the role, you define the Staging Account as a trusted entity and specify a permissions policy that allows trusted users to update the production-test-bucket-101.

Stage 2 – Grant Access to the Role

In this step of the tutorial, you modify the IAM bucket policy so that users from Staging Account can access the S3 bucket using StageRole.

Stage 3 – Test Access by Switching Roles

Finally, as a StageAdmin user on Staging Account, you use the StageRole to gain access to production-test-bucket-101 bucket in the Production Account. You’ll see how to access the role through the AWS CLI.

Step-by-step Guide to Provide Cross-Account Access


  • Two separate AWS accounts that you can use: one to represent the Staging Account, and one to represent the Production Account
  • Production and Staging Account ID and Canonical User ID
    • Login to Production/Staging Account and from the My Account/Console drop-down menu, select Security Credentials
    • Click Account Identifiers and note down the AWS Account ID and the Canonical User ID. (You will need the Account ID and the Canonical User ID while creating bucket policy further)
    • Two users with administrator privileges
    • Create ProdAdmin user in Production environment
    • Grant user ProdAdmin privileges by attaching AdministratorAccess policy in IAM
    • Repeat the preceding step to create administrator StageAdmin user in Staging Account as well
    • Setup AWS CLI with Administrator user ProdAdmin and StageAdmin for both Staging and Production Account

The second scenario is to provide cross account access. I will not mention that one here as that is not the scenario we wanted to allow in our environment.

graphics & some article references from :

pgAdmin – Failed to connect…

This is a shameless repost and thanks to the original solver!!

The same problem happened to me today:

enter image description here

And this is how I’ve solved it:

1) Use a text editor to open the file under the c:\Program Files\pgAdmin 4\v1\web folder. Change the value for SERVER_MODE from True to False, then save the change. (I have run Notepad++ as an Administrator, in order to be able to save in this protected folder.)

enter image description here

2) Go to folder c:\Users\your_name\AppData\Roaming\pgAdmin and make sure there is nothing there (delete all the files, as they are temporary and will be restored after starting pgAdmin)

enter image description here

3) Start pgAdmin

enter image description here

4) This time you will see a white box that sits – at least, on my slow laptop – about 20 seconds. (You may briefly see the original error message, but do not worry).

enter image description here

5) Meanwhile, the temporary files – required for running the application – are created.

enter image description here

6) Once the temporary files process is over, the application starts as expected.

enter image description here

share|improve this answer

Top 10 Git commands

Lets go through this step-by-step.

To create a repository from an existing directory of files, you can simply run git init in that directory. Go to that directory you want to get under version control:

git init


All new and changed files need to be added to the staging area prior to commit to the repository. To add all files in the current directory to the staging area:

git add --all


To commit the files and changes to the repository:

git commit -am "Initial commit"


Note that I have use the -am option which does an add -all implicitly. This command is equivalent to the SVN- or CVS-style “commit”. Again: if you want to update your local Git repository there is always an add-operation followed by a commit-operation, with all new and modified files.

Then you go create a repository at Let’s say you named it git_example.

Then you add the remote repository address to your local GIT configuration:

git remote add EXAMPLE

Note that in the example thats my user name on You’ll need to use yours obviously. I have named the remote repository “EXAMPLE”. You can refer to an alias name instead of using the remote URL all the time. You are ready to communicate with a remote repository now.

If you are behind a firewall you make the proxy configuration:

git config --global http.proxy

Then you push your files to the remote repository:

git push EXAMPLE master


Then imagine somebody changed the remote files. You need to get them:

git fetch EXAMPLE

You need to merge those changes from the remote master into your local master branch (plain language: you copy the changes from your local repository to your working directory):

git merge EXAMPLE/master

Note that you are in the master branch and the EXAMPLE/master in the merge command refers to the remote master.

To compare the staging area to your working directory:

git status -s


The example shows the status after I have modified the README.txt (but did not added or commited yet).

Without any extra arguments, a simple git diff will display what content you’ve changed in your project since the last commit that are not yet staged for the next commit snapshot.

git diff


The example shows the diff output after I have edited the README.txt file (but did not added or commited yet). When I add all changes to staging, git diff will not display changes ’cause there is nothing in your working directory that has not been staged.

It’s different with git status. It shows the differences between your last commit and the staging/working area:

In short: git status shows differences between your local repository and your working directory/staging area. Whereas git diff (as used above) shows differences between your staging area and your working directory.

That’s it. These are the most important Git commands a newbie must know to get started. See the reference for more information on using Git.