Save Time With This Quick OCI CLI Installation

Editor’s Note: Because our bloggers have lots of useful tips, every now and then we update and bring forward a popular post from the past. We originally published today’s post on April 15, 2019. This is more of a personal reminder than anything else, but hopefully it helps save some time for others trying to install the OCI CLI on their local Linux machines. The idea is to have a very basic set of instructions to install the
oci CLI on a Linux box and test it. This includes installing a newer version of Python and setting the system to use it by default. This is easy enough, but introduces an issue that has to be worked around.
The idea
I would usually keep these quite simple things to myself in a simple text file for my own reference. However, lately I've discovered that what I consider to be very basic Linux knowledge is either not-so-basic or not as widely spread among Oracle DBAs as I thought. So, this is not only to benefit my own memory but to try and help others out there that may struggle a bit with Linux-related stuff.Installation
Both the automated and the manual installation procedures are well-documented but there is an interesting caveat I discovered while installing in my Oracle Linux 7.6 laboratory VM. I tried the automated procedure because I'm one for automating stuff and I didn't want to deep dive into this particular procedure. So, simply following the instructions, I proceeded to execute the curl command to download and install the CLI. Please, note the highlighted line (25) in the code below:[oracle@orapex ~]$ bash -c "$(curl -L https://raw.githubusercontent.com/oracle/oci-cli/master/scripts/install/install.sh)" % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 6283 100 6283 0 0 14095 0 --:--:-- --:--:-- --:--:-- 14087 Downloading Oracle Cloud Infrastructure CLI install script from https://raw.githubusercontent.com/oracle/oci-cli/6dc61e3b5fd2781c5afff2decb532c24969fa6bf/scripts/install/install.py to /tmp/oci_cli_install_tmp_LA0m. ######################################################################## 100.0% Python3 not found on system PATH Running install script. python /tmp/oci_cli_install_tmp_LA0m < /dev/tty -- Verifying Python version. -- Python version 2.7.5 okay. -- Verifying native dependencies. -- Unable to verify native dependencies. dist=oracle linux server, version=7.5. Continuing... ===> In what directory would you like to place the install? (leave blank to use '/home/oracle/lib/oracle-cli'): -- Creating directory '/u01/userhome/oracle/lib/oracle-cli'. -- We will install at '/u01/userhome/oracle/lib/oracle-cli'. ===> In what directory would you like to place the 'oci' executable? (leave blank to use '/home/oracle/bin'): -- The executable will be in '/u01/userhome/oracle/bin'. ===> In what directory would you like to place the OCI scripts? (leave blank to use '/home/oracle/bin/oci-cli-scripts'): -- Creating directory '/u01/userhome/oracle/bin/oci-cli-scripts'. -- The scripts will be in '/u01/userhome/oracle/bin/oci-cli-scripts'. -- Downloading virtualenv package from https://github.com/pypa/virtualenv/archive/15.0.0.tar.gz. -- Downloaded virtualenv package to /tmp/tmpRjNdhT/15.0.0.tar.gz. -- Checksum of /tmp/tmpRjNdhT/15.0.0.tar.gz OK. -- Extracting '/tmp/tmpRjNdhT/15.0.0.tar.gz' to '/tmp/tmpRjNdhT'. -- Executing: ['/usr/bin/python', 'virtualenv.py', '--python', '/usr/bin/python', '/u01/userhome/oracle/lib/oracle-cli'] Already using interpreter /usr/bin/python New python executable in /u01/userhome/oracle/lib/oracle-cli/bin/python Installing setuptools, pip, wheel...done. -- Executing: ['/u01/userhome/oracle/lib/oracle-cli/bin/pip', 'install', '--cache-dir', '/tmp/tmpRjNdhT', 'oci_cli', '--upgrade'] DEPRECATION: Python 2.7 will reach the end of its life on January 1st, 2020. Please upgrade your Python as Python 2.7 won't be maintained after that date. A future version of pip will drop support for Python 2.7. Collecting oci_cli Downloading https://files.pythonhosted.org/packages/83/aa/922fc63808ffc79d114474bef9af8b4a066e4653898b6df427cfcf98f166/oci_cli-2.5.5-py2.py3-none-any.whl (3.8MB) 100% |------------------------------| 3.8MB 6.4MB/s (:..) Downloading https://files.pythonhosted.org/packages/68/9e/49196946aee219aead1290e00d1e7fdeab8567783e83e1b9ab5585e6206a/pycparser-2.19.tar.gz (158kB) 100% |------------------------------| 163kB 25.2MB/s Building wheels for collected packages: arrow, configparser, terminaltables, retrying, PyYAML, pycparser Building wheel for arrow (setup.py) ... done Stored in directory: /tmp/tmpRjNdhT/wheels/ce/4f/95/64541c7466fd88ffe72fda5164f8323c91d695c9a77072c574 Building wheel for configparser (setup.py) ... done Stored in directory: /tmp/tmpRjNdhT/wheels/a3/61/79/424ef897a2f3b14684a7de5d89e8600b460b89663e6ce9d17c Building wheel for terminaltables (setup.py) ... done Stored in directory: /tmp/tmpRjNdhT/wheels/30/6b/50/6c75775b681fb36cdfac7f19799888ef9d8813aff9e379663e Building wheel for retrying (setup.py) ... done Stored in directory: /tmp/tmpRjNdhT/wheels/d7/a9/33/acc7b709e2a35caa7d4cae442f6fe6fbf2c43f80823d46460c Building wheel for PyYAML (setup.py) ... done Stored in directory: /tmp/tmpRjNdhT/wheels/ad/da/0c/74eb680767247273e2cf2723482cb9c924fe70af57c334513f Building wheel for pycparser (setup.py) ... done Stored in directory: /tmp/tmpRjNdhT/wheels/f2/9a/90/de94f8556265ddc9d9c8b271b0f63e57b26fb1d67a45564511 Successfully built arrow configparser terminaltables retrying PyYAML pycparser Installing collected packages: idna, six, python-dateutil, arrow, jmespath, configparser, enum34, pycparser, cffi, asn1crypto, ipaddress, cryptography, pyOpenSSL, httpsig-cffi, terminaltables, click, cx-Oracle, retrying, pytz, PyYAML, certifi, oci, oci-cli Successfully installed PyYAML-3.13 arrow-0.10.0 asn1crypto-0.24.0 certifi-2019.3.9 cffi-1.12.2 click-6.7 configparser-3.5.0 cryptography-2.4.2 cx-Oracle-7.0.0 enum34-1.1.6 httpsig-cffi-15.0.0 idna-2.6 ipaddress-1.0.22 jmespath-0.9.3 oci-2.2.4 oci-cli-2.5.5 pyOpenSSL-18.0.0 pycparser-2.19 python-dateutil-2.7.3 pytz-2016.10 retrying-1.3.3 six-1.11.0 terminaltables-3.1.0 ===> Modify profile to update your $PATH and enable shell/tab completion now? (Y/n): Y ===> Enter a path to an rc file to update (leave blank to use '/home/oracle/.bashrc'): -- Backed up '/u01/userhome/oracle/.bashrc' to '/u01/userhome/oracle/.bashrc.backup' -- Tab completion set up complete. -- If tab completion is not activated, verify that '/u01/userhome/oracle/.bashrc' is sourced by your shell. -- -- ** WARNING: Other 'oci' or 'bmcs' executables are on your $PATH. ** -- Conflicting paths: /home/oracle/bin/oci, /home/oracle/bin/bmcs, /home/oracle/bin/oci, /home/oracle/bin/bmcs, /home/oracle/bin/oci, /home/oracle/bin/bmcs, /home/oracle/bin/oci, /home/oracle/bin/bmcs -- You can run this installation of the CLI with '/u01/userhome/oracle/bin/oci'. -- -- ** Run `exec -l $SHELL` to restart your shell. ** -- -- Installation successful. -- Run the CLI with /u01/userhome/oracle/bin/oci --helpThe highlighted line offers a deprecation warning for the currently available Python version, so I decided to have Python 3 installed for the CLI to use.
Python installation
This is a simple call to yum to install the package python36.[root@orapex ~]# yum install -y python36 Loaded plugins: langpacks, ulninfo Resolving Dependencies --> Running transaction check ---> Package python36.x86_64 0:3.6.6-2.el7 will be installed --> Processing Dependency: python36-libs(x86-64) = 3.6.6-2.el7 for package: python36-3.6.6-2.el7.x86_64 --> Processing Dependency: libpython3.6m.so.1.0()(64bit) for package: python36-3.6.6-2.el7.x86_64 --> Running transaction check ---> Package python36-libs.x86_64 0:3.6.6-2.el7 will be installed --> Finished Dependency Resolution Dependencies Resolved =================================================================================================================================================================================================================== Package Arch Version Repository Size =================================================================================================================================================================================================================== Installing: python36 x86_64 3.6.6-2.el7 ol7_developer_EPEL 65 k Installing for dependencies: python36-libs x86_64 3.6.6-2.el7 ol7_developer_EPEL 8.5 M Transaction Summary =================================================================================================================================================================================================================== Install 1 Package (+1 Dependent package) Total download size: 8.6 M Installed size: 36 M Downloading packages: (1/2): python36-libs-3.6.6-2.el7.x86_64.rpm | 8.5 MB 00:00:01 (2/2): python36-3.6.6-2.el7.x86_64.rpm | 65 kB 00:00:03 ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- Total 2.6 MB/s | 8.6 MB 00:00:03 Running transaction check Running transaction test Transaction test succeeded Running transaction Installing : python36-libs-3.6.6-2.el7.x86_64 1/2 Installing : python36-3.6.6-2.el7.x86_64 2/2 Verifying : python36-3.6.6-2.el7.x86_64 1/2 Verifying : python36-libs-3.6.6-2.el7.x86_64 2/2 Installed: python36.x86_64 0:3.6.6-2.el7 Dependency Installed: python36-libs.x86_64 0:3.6.6-2.el7 Complete! [root@orapex ~]# python -V Python 2.7.5 [root@orapex ~]# python36 -V Python 3.6.6As you may have noted, in order to use the new version of Python, we would use the python36 command, while python will call version 2.7. This is a little problem when the oci CLI will call python and we want it to be the latest version. In order to solve this little problem, I decided to go for Linux alternatives. This is a command to help maintain symbolic links to determine default commands system-wide. I've highlighted "system-wide" for a good reason we'll see below. Using alternatives is pretty straightforward. It requires a simple call defining the new symbolic link and the command it points to, plus a priority value. In my case, I opted for creating the same link for Python 2 and Python 3, giving a higher priority to Python 3. This means the system will first try Python 3, then Python 2 if the first one is not available.
[root@orapex ~]# alternatives --install /usr/bin/python python /bin/python36 2 [root@orapex ~]# alternatives --install /usr/bin/python python /bin/python 1 [root@orapex ~]# alternatives --display python python - status is auto. link currently points to /bin/python36 /bin/python36 - priority 2 /bin/python - priority 1 Current 'best' version is /bin/python36. [oracle@orapex ~]$ python -V Python 3.6.6
System-wide change means trouble
At this point we have the OCI CLI installed and using Python 3 for its calls, so we are fine here. Fortunately, I was following the steps found in this blog post to configure alternatives properly and it includes an appendix. In this appendix, the post mentions a problem that appears in yum once the system-wide switch to Python 3 has completed. Also, fortunately, the post provides the solution / workaround for it, which I immediately applied. The solution is pretty simple; just modify the yum Python scripts to use the older Python version. There are two files to modify:[root@orapex ~]# yum search python File "/bin/yum", line 30 except KeyboardInterrupt, e: ^ SyntaxError: invalid syntax [root@orapex ~]# head -1 /usr/bin/yum #!/usr/bin/python [root@orapex ~]# vi /usr/bin/yum [root@orapex ~]# head -1 /usr/bin/yum #!/usr/bin/python2.7 [root@orapex ~]# yum search python |more Loaded plugins: langpacks, ulninfo ============================= N/S matched: python ============================== GitPython.noarch : Python Git Library (...) [root@orapex ~]# head -1 /usr/libexec/urlgrabber-ext-down #! /usr/bin/python [root@orapex ~]# vim /usr/libexec/urlgrabber-ext-down [root@orapex ~]# head -1 /usr/libexec/urlgrabber-ext-down #! /usr/bin/python2.7With these simple steps, we have the OCI CLI installed and working with the latest Python version, until a Python 4 version comes in, but now we know how to use alternatives to fix it. The next step is to use the CLI itself to create a configuration file to access our OCI tenancy resources and start working, but that will be in another blog post. Thank you for reading.