Monday, 18 March 2019

Oracle Cloud Infrastructure command line client and object storage

Yesterday I blogged about a Google Drive client, and 2 years back a blogged about a custom workflow I was using to push and pull file(s) from/to Google Drive on Linux. I recently got access to Oracle Cloud Infrastructure so thought doing an equivalent task might be a good way to get my toes wet.

As with most of the cloud infrastructure platforms available, Oracle provides us with a command line tool we can use. This project source code is open sourced (under UPL 1.0 and Apache 2.0) and hosted over on GitHub. Christoph Ruepprich has previously blogged about this tool, but I wanted to go through it myself - so a lot of this information may be redundant if you already followed along with his blog post.

For my test case, I wanted to test in an isolated environment so I went ahead and pulled the latest ubuntu release using Docker:

docker pull ubuntu:latest

Then I enter that environment by running:

docker run -it ubuntu:latest

This will bring me to a shell prompt with root access. Some initial steps you will want to do is install some needed packages along with some extras that may be helpful in testing with.

apt-get update
apt-get install python3 python3-distutils curl jq

Before we move onto to installing the client, we will need to gather some information. First, go ahead and grab your user OCID and your tennancy OCID.

So first, go to the OCI console:

User OCID is accessed by going to user settings

And the tenancy OCID is accessed by opening the hamburger menu and accessing tenancy details.

note: all this is documented on Oracle's documentation here:

So, with that information gathered, let's now go ahead and create a bucket to store our files. This is done through Object Storage within Core Infrastructure.

Then create a bucket that you will store your files in.

Now with all that done, we can move on to installing the client.

Per the documentation of the client (on the GitHub project page), run the following command:

bash -c "$(curl -L"

Throughout this process, you should see the following prompts:

===> In what directory would you like to place the install? (leave blank to use '/root/lib/oracle-cli'):
===> In what directory would you like to place the 'oci' executable? (leave blank to use '/root/bin'):
===> In what directory would you like to place the OCI scripts? (leave blank to use '/root/bin/oci-cli-scripts')
===> Modify profile to update your $PATH and enable shell/tab completion now? (Y/n):

For the example, I just left everything as default.
You will also want to set some environment variables before trying to use the tool (it will prompt you to set these if they are not set).

export LC_ALL=C.UTF-8
export LANG=C.UTF-8

Since, I'm not re-initialising my shell, I'm also going to set my path so that it included the oci tool:

export PATH=$PATH:/root/bin

Now, the next step is to store the config about your cloud infrastructure. So run the following command and fill out the prompts that we retrieved in previous steps

oci setup config

You should see prompts:

Enter a location for your config [/root/.oci/config]:
Enter a user OCID:
Enter a tenancy OCID:
Enter a region (e.g. ca-toronto-1, eu-frankfurt-1, uk-london-1, us-ashburn-1, us-gov-ashburn-1, us-gov-chicago-1, us-gov-phoenix-1, us-langley-1, us-luke-1, us-phoenix-1):
Do you want to generate a new RSA key pair? (If you decline you will be asked to supply the path to an existing key.) [Y/n]:
Enter a directory for your keys to be created [/root/.oci]:
Enter a name for your key [oci_api_key]:
Enter a passphrase for your private key (empty for no passphrase):

So, now we need to upload the public key into the cloud infrastructure so you can be authenticated. Output the contents of your public key and then copy it into your public keys within your user settings page. Depending on what you configuration looks like, you may output the public key with a command like:

cat /root/.oci/oci_api_key_public.pem

So, with that all done you should now be able to perform commands against your OCI instance. A good initial test is to list all compartments:

oci iam compartment list --all

Now, with that done, lets play around with what we're here for. Downloading and Uploading files.

If you run oci without any arguments, you will see a list of all available sub-commands. A quick scan of this list we can see that we want to deal with the os sub-command (short for object storage). A delve into that, and we can identify two commands we will want to use will become:

oci os object get
oci os object put

A quick scan of the documentation, we then have our full command not disimilar to the following:

oci os object get --name Portfolio.xlsx --bucket-name exampleBucket --file Portfolio.xlsx


oci os object put --bucket-name exampleBucket --file Portfolio.xlsx

Sunday, 17 March 2019

Updating my CLI Google Drive Client

A couple of year back I blogged about a custom Google Drive workflow. The tool I'm using I recently noticed is facing some issues - when trying to pull the file I am presented with the following:

The problem seems to be that this tool is using a single API key/secret amongst all users - and with the popularity of this tool it's exceeding the daily usage limit each day. The product seems to be not actively maintained for a while now - so back to the drawing board.

There is another popular tool on GitHub, which supports overriding the API credentials used based on some environment variables. This tool is aptly called "drive" - and the project is found here:

Per the documentation, you can set up your own API client credentials to use with this tool to avoid the possibility of any usage limit violations (assuming it's just for personal use, it's unlikely you would exceed these):

> Optionally set the GOOGLE_API_CLIENT_ID and GOOGLE_API_CLIENT_SECRET environment variables to use your own API keys.

For this, you need to go to the Google API Console and create new credentials against a new/existing project.

Once installed, it will be slightly different behaviour. First you need a Drive context folder. So, per the documentation, I call drive init ~/gdrive. This will prompt you to go to a URL and paste the generated token.

With that done, if you navigate into your folder, and run the command drive ls, you should see all your Drive files and folders.

Further, if you want to pull a specific file you can do so with the filename or the ID. Since I was using the file ID with the previous tool I was using, I will just continue down that path. So my command ends up looking like this for pulling:

~/gdrive$ drive pull -quiet -no-prompt -id <fileToken>

And similarly for pushing (pushing doesn't seem to support the -id flag).

~/gdrive$ drive push -no-prompt -files MyFile.txt

Wednesday, 6 March 2019

Why is my date format not staying in uppercase?

In my application, I have my date format defined as "DD-MON-YYYY".

In my page, I have defined a default date as `sysdate`. So my date renders with the current date, and everything looks good:

However, as soon as I change the date, the month name is not persisting to be in all caps, per:

So, what is going on here?

If we look at the HTML node for selecting another date, we can see it runs the following code:


In the latest APEX, we can view the source for this call in:

This in turn makes a call to:


Which in turn returns by:

        this._get( inst, "dateFormat" ), 
        this._getFormatConfig( inst )

OK, so if we put a break point within this function, and try and change the date, we will be able to see that: this._get( inst, "dateFormat" ) is returning the format dd-M-yy. That means the mapping of MON APEX is making is to M is jQuery's date format. If you take a closer look at the jQuery docs, you will see that this is the only option for the short month name.

Therefore, if you want to stick with this format (short month name in upper-case), an easy UI change you could make to add a CSS rule to your application to enforce date picker fields to render in uppercase.

input.apex-item-datepicker {
    text-transform: uppercase;