1. Open the Microsoft Store.

2. Search for Ubuntu 24.04

3. Install

Launch Ubuntu terminal

1. Search for "Ubuntu" in your apps.

2. On the initial launch, you'll be prompted to create a username and password. Set these and remember them.

3. Execute the following commands:

    sudo apt update && sudo apt full-upgrade -y
   

Install podman-docker

sudo apt install podman-docker
sudo touch /etc/containers/nodocker

Install Fn CLI

curl -LSs https://raw.githubusercontent.com/fnproject/cli/master/install | sh

Set the Fn settings to use the Podman engine by adding or updating the following line:

vi ~/.fn/config.yaml

Add or update line:

container-enginetype: podman

Install OCI CLI

sudo apt install python3-pip
pip3 install oci-cli --break-system-packages

Create .bash_profile

vi ~/.bash_profile

Set the file contents as follows:

#!/bin/bash

source ~/.bashrc
export PATH=~/.local/bin:$PATH

Setup Config

oci setup config

Complete Fn Setup

Follow steps 4 onwards in the Functions QuickStart on Local Host.

NOTES:

• Step 4.3 is optional. Set it if you're using a profile other than the DEFAULT profile in the OCI CLI config.

• Step 5.3: you can get the tenancy namespace by executing oci os ns get.

Development in VS Code

1. Install the Remote Development extension in VS Code.

2. Connect to WSL

Quick Method

For those familiar with Git, here's the quick version:

git clone --mirror $ORIG_REPO_URL temp-dir
cd temp-dir
git remote rm origin
git remote add origin $NEW_REPO_URL
git push origin --all
git push --tags

Detailed Steps

1. Clone the Original Repository

    git clone --mirror $ORIG_REPO_URL temp-dir
   

   The --mirror flag creates a bare repository, including all branches and tags.

2. Navigate to Directory

    cd temp-dir
   

3. Update Remote Configuration

    git remote rm origin
    git remote add origin $NEW_REPO_URL
   

   This step redirects the repository to its new destination.

4. Push All Content

    git push origin --all
    git push --tags
   

   These commands transfer all branches and tags to the new location.

Verification

After migration, verify:

• All branches are present in the new repository

• Commit history is intact

• Tags are properly transferred

• Remote URLs are correctly configured

The Challenge

Managing IAM policies across multiple compartments can become complex as your cloud infrastructure grows. Common challenges include:

• Tracking policy distributions across compartments

• Identifying redundant or conflicting policies

• Ensuring proper access controls at each level

• Maintaining security compliance requirements

Console Limitations in Policy Visibility

One significant challenge when using the OCI Console is the limited visibility of group permissions across compartments. Here's why this is problematic:

1. Scattered Policies: Permissions for a single group can be defined in multiple policies across different compartments. The console doesn't provide a unified view of all permissions assigned to a group.

2. Inheritance Complexity: When compartments are nested, policies inherit from parent compartments. The console shows policies at each level separately, making it difficult to understand the cumulative permissions a group has.

3. Dynamic Groups: When dynamic groups are involved, it becomes even more challenging to track permissions as they're based on instance principals and other dynamic attributes.

4. Time-Consuming Manual Review: To understand a group's complete access level, administrators often need to:

   • Navigate through multiple compartments

   • Open each policy individually

   • Mentally compile the permissions

   • Account for policy inheritance

   • Consider any conflicting or overlapping statements

This is where our script becomes particularly valuable, as it provides a comprehensive view of all policies across your tenancy in one output.

The Solution

We'll use a Bash script that leverages the OCI CLI to recursively traverse all compartments and list their associated IAM policies. This script can be run directly in OCI Cloud Shell, making it immediately accessible to all OCI users.

Prerequisites

1. OCI CLI installed and configured

2. Proper permissions to read compartments and IAM policies

3. jq command-line JSON processor (pre-installed in Cloud Shell)

The Script Breakdown

Full script

Let's analyze the key components of our script:

# Core function to list IAM policies for a single compartment
list_compartment_iam_policies() {
    local compartment_id=$1
    oci iam policy list --compartment-id "$compartment_id"
}

This function uses the OCI CLI to fetch all IAM policies for a given compartment ID.

# Get the root compartment (tenancy) ID
local root_compartment=$(oci iam compartment list --all \
    --compartment-id-in-subtree true \
    --access-level ACCESSIBLE \
    --include-root \
    --raw-output \
    --query "data[?contains(\"id\",'tenancy')].id | [0]")

This command retrieves the tenancy OCID, which serves as our starting point for the recursive traversal.

function _list_compartments() {
    local compartment_id=$1
    compartment_name=$(oci iam compartment get \
        --compartment-id "$compartment_id" \
        --query "data.name" \
        --raw-output)

    echo "Compartment: $compartment_name ($compartment_id)"
    list_compartment_iam_policies "$compartment_id"

    # Recursive call for sub-compartments
    for sub_compartment_id in $(oci iam compartment list \
        --compartment-id "$compartment_id" \
        --all \
        --query "data[].id" | jq -r '.[]'); do
        _list_compartments "$sub_compartment_id"
    done
}

This recursive function:

1. Gets the compartment name for better readability

2. Lists IAM policies for the current compartment

3. Finds all sub-compartments

4. Recursively calls itself for each sub-compartment

Using the Script

1. Save the script to a file (e.g., audit_iam_policies.sh)

2. Make it executable:

    chmod +x audit_iam_policies.sh
   

3. Run it:

    ./audit_iam_policies.sh
   

Output Format

The script produces output in the following format:

Compartment: root_compartment_name (ocid1.tenancy.oc1...)
[IAM policies for root compartment]

Compartment: sub_compartment_name (ocid1.compartment.oc1...)
[IAM policies for sub-compartment]
...

Best Practices for Policy Auditing

When reviewing the output:

1. Policy Consolidation: Look for similar policies that could be combined at a higher level

2. Least Privilege: Ensure policies grant only necessary permissions

3. Documentation: Save the output for compliance and documentation purposes

4. Regular Audits: Run this script periodically as part of your security routine

Enhancement Opportunities

The script can be enhanced to:

1. Output in different formats (JSON, CSV, HTML)

2. Include policy statements analysis

3. Flag potentially risky permissions

4. Compare against a baseline configuration

5. Generate detailed reports with policy recommendations

6. Group-Centric View: Add functionality to filter and display all policies affecting a specific group across compartments

7. Permission Matrix: Generate a matrix showing which groups have what permissions across different compartments

8. Policy Overlap Detection: Identify where multiple policies might be granting similar permissions to the same group

Pro Tips for Policy Analysis

1. Group-Based Review:

   • After running the script, use grep to filter policies for a specific group:

    ./audit_iam_policies.sh | grep -A 5 "group_name"

2. Effective Permissions Check:

   • Combine the script output with the OCI CLI's policy parser to validate effective permissions:

    oci iam policy get --policy-id <policy_id> --query "data.statements[]"

Conclusion

This script provides a foundation for maintaining good security hygiene in your OCI environment. Regular auditing of IAM policies helps ensure proper access controls and compliance with security requirements. While the OCI Console offers many powerful features, using CLI tools like this script can significantly improve visibility into your IAM policy structure and help maintain a secure cloud environment.

Remember to run this script in a controlled manner and during off-peak hours if you have a large number of compartments, as it makes multiple API calls to the OCI service.

Table of Contents

1. Setting Up OCI Credentials in Autonomous Database

2. Installing Data Pump on OCI Oracle Linux

3. Configuring the Oracle Wallet

4. Executing Data Pump Export

5. Working with Object Storage

6. Executing Data Pump Import

7. Monitoring Data Pump Execution Status

8. Archiving Files on Object Storage

Setting Up OCI Credentials in Autonomous Database

Before you can use Data Pump with OCI Object Storage, you need to set up the appropriate credentials in your Autonomous Database. Here's how to do it:

BEGIN
  DBMS_CLOUD.CREATE_CREDENTIAL(
    credential_name => '<credential>',
    username => '<oci-username>',
    password => '<auth-token>'
  );
END;
/

NOTE: Currently, Data Pump CLI commands using OCI Object Storage only works with auth-token credentials. Credentials created using API Keys would fail to authenticate.

If you're running Data Pump operations through another user, make sure to grant the necessary permissions:

GRANT datapump_cloud_exp TO <schema_user>;
GRANT datapump_cloud_imp TO <schema_user>;
GRANT READ, WRITE ON DIRECTORY data_pump_dir TO <schema_user>;

Installing Data Pump on OCI Oracle Linux

To use Data Pump on an OCI Oracle Linux instance, you'll need to install the Oracle Instant Client. The installation process differs slightly depending on your Oracle Linux version.

For Oracle Linux 7:

sudo yum install oracle-instantclient-release-el7
sudo yum install oracle-instantclient-basic
sudo yum install oracle-instantclient-tools

For Oracle Linux 8:

sudo dnf install oracle-instantclient-release-el8
sudo dnf install oracle-instantclient-basic
sudo dnf install oracle-instantclient-tools

Configuring the Oracle Wallet

To connect to your Autonomous Database, you'll need to set up the Oracle Wallet:

1. Unzip the wallet contents to a folder.

2. Edit the sqlnet.ora file. Replace ?/network/admin with the location of the wallet contents.

Executing Data Pump Export

Now that everything is set up, you can perform a Data Pump export. Here's an example command that exports directly to OCI Object Storage:

export PATH=/usr/lib/oracle/21/client64/bin:$PATH
export TNS_ADMIN=<location of exploded wallet>

expdp <db-username>@<adb-service-name> filesize=5GB credential=<credential> dumpfile=https://objectstorage.<region>.oraclecloud.com/n/<namespace>/b/<bucket>/o/<file-prefix>%U.dmp logfile=<logname>.log directory=data_pump_dir

If you prefer to export to the database first and then transfer to Object Storage, use this command:

expdp <db-username>@<adb-service-name> filesize=5GB dumpfile=<file-prefix>%U.dmp logfile=<logname>.log directory=data_pump_dir

Then, transfer the file using DBMS_CLOUD.PUT_OBJECT.

Working with Object Storage

Downloading Files from Object Storage

To download files from Object Storage:

for i in $(seq -f "%02g" 1 <n>); do 
  curl -O -X GET -u '<oci-username>:<auth-token>' https://swiftobjectstorage.<region>.oraclecloud.com/v1/<namespace>/<bucket>/<file-prefix>${i}.dmp
done

Replace <n> with the number of dump files.

Uploading Files to Object Storage

To upload files to Object Storage:

for i in $(seq -f "%02g" 1 <n>); do 
  curl -X PUT -u '<oci-username>:<auth-token>' -T <file-prefix>${i}.dmp https://swiftobjectstorage.<region>.oraclecloud.com/v1/<namespace>/<bucket>/<file-prefix>${i}.dmp
done

Copying Files from ADB to Object Storage

You can copy files from your Autonomous Database to Object Storage using PL/SQL:

BEGIN
  DBMS_CLOUD.PUT_OBJECT(
    credential_name => '<credential>',
    object_uri => 'https://objectstorage.<region>.oraclecloud.com/n/<namespace>/b/<bucket>/o/<filename>',
    directory_name  => 'DATA_PUMP_DIR',
    file_name => '<filename>');
END;
/

Listing Objects in an Object Storage Bucket

To list objects in your bucket:

SELECT *
FROM dbms_cloud.list_objects(
  credential_name => '<credential>', 
  location_uri => 'https://objectstorage.<region>.oraclecloud.com/n/<namespace>/b/<bucket>/o/'
);

Executing Data Pump Import

To import data from Object Storage:

export PATH=/usr/lib/oracle/21/client64/bin:$PATH
export TNS_ADMIN=<location of exploded wallet>

impdp <db-username>@<adb-service-name> credential=<credential> dumpfile=https://objectstorage.<region>.oraclecloud.com/n/<namespace>/b/<bucket>/o/<file-prefix>%U.dmp logfile=<logname>.log directory=data_pump_dir

Monitoring Data Pump Execution Status

You can monitor the status of your Data Pump jobs using this SQL query:

SELECT
    opname,
    sid,
    serial#,
    context,
    sofar,
    totalwork,
    round(sofar / totalwork * 100, 2) "%_COMPLETE"
FROM
    v$session_longops
WHERE
    opname IN (
        SELECT
            d.job_name
        FROM
            v$session             s,
            v$process             p,
            dba_datapump_sessions d
        WHERE
            p.addr = s.paddr
            AND s.saddr = d.saddr
    )
    AND opname NOT LIKE '%aggregate%'
    AND totalwork != 0
    AND sofar <> totalwork;

Archiving Files on Object Storage

After your Data Pump operation is complete, you might want to archive the dump files to save on storage costs. Here's how to do it:

for i in $(seq -f "%02g" 1 <n>); do 
  oci os object update-storage-tier -bn dpexp --object-name <file-prefix>${i}.dmp  --storage-tier Archive
  oci os object rename  -bn dpexp --source-name <file-prefix>${i}.dmp --new-name "archive/<file-prefix>${i}.dmp"
done

This script changes the storage tier to Archive and moves the files to an "archive" folder in your bucket.

By following this guide, you should now have a solid understanding of how to use Oracle Data Pump with OCI, from setting up credentials to archiving your dump files. Remember to always test these operations in a non-production environment before applying them to your production databases.

1. Locate the Process ID (PID): First, you need to find out the process ID of your Tomcat or ORDS instance. You can do this by using tools like ps (on Unix-based systems) or Task Manager (on Windows) or any other process monitoring tool you prefer.

2. Use jcmd command: Once you have the PID, you can use jcmd to view JVM details. The general syntax is:

jcmd ${PID} {command}

For example, to view the VM flags, you would use:

jcmd ${PID} VM.flags

Or to view the VM system properties:

jcmd ${PID} VM.system_properties

Replace ${PID} with the process ID of your Tomcat instance and {command} with the specific command you want to execute.

There are several useful jcmd commands for diagnosing and monitoring a Java process such as Tomcat. Here are some commonly used ones:

• VM.version: Displays the version information of the JVM.

jcmd ${PID} VM.version

• VM.flags: Displays the VM flags and their values.

jcmd ${PID} VM.flags

• VM.system_properties: Lists all system properties.

jcmd ${PID} VM.system_properties

• VM.command_line: Shows the command-line options passed to the JVM.

jcmd ${PID} VM.command_line

• GC.heap_info: Provides information about heap memory usage.

jcmd ${PID} GC.heap_info

• GC.class_histogram: Prints a histogram of the number of instances of each class.

jcmd ${PID} GC.class_histogram

• GC.run: Initiates garbage collection.

jcmd ${PID} GC.run

• Thread.print: Prints stack traces for all threads.

jcmd ${PID} Thread.print

• VM.native_memory: Prints information about native memory usage.

jcmd ${PID} VM.native_memory

• VM.uptime: Displays the uptime of the JVM.

jcmd ${PID} VM.uptime