How to check Oracle Exadata Compute node temperature sensors

On an Exadata compute/database server, check temperature through the server’s ILOM service processor. CellCLI is for storage cells; it is not the compute server’s sensor interface. Oracle: Exadata ambient temperature monitoring

Ambient intake temperature on one node:

ipmitool sunoem cli "show /SYS/T_AMB"

Look for the value in °C and the sensor’s alarm_status.

List temperature sensors:

ipmitool sdr list | grep -iE 'ipmitool sdr list | grep degrees'

Example:

ipmitool sdr list | grep degrees

T_IN_ZONE0 | 40 degrees C | ok
T_IN_ZONE1 | 43 degrees C | ok
T_IN_ZONE2 | 37 degrees C | ok
T_IN_ZONE3 | 43 degrees C | ok
T_OUT_ZONE0 | 41 degrees C | ok
T_OUT_ZONE1 | 44 degrees C | ok
T_OUT_ZONE2 | 43 degrees C | ok
T_OUT_ZONE3 | 47 degrees C | ok
PS0/T_IN | 44 degrees C | ok
PS0/T_OUT | 47 degrees C | ok
PS1/T_IN | 42 degrees C | ok
PS1/T_OUT | 48 degrees C | ok
T_AMB | 31 degrees C | ok

For sensor readings and thresholds, Oracle ILOM also documents ipmitool sensor; available sensors depend on the server model. Oracle ILOM: Display sensor list · Oracle ILOM: IPMItool commands

Check ILOM health and open hardware problems from the ILOM CLI:

show /System health
show /System/Open_Problems
show /SYS/T_AMB

Oracle’s Exadata guidance gives a rack ambient operating range of 5–32 °C, with 21–23 °C as the optimal range. Those are ambient conditions; use each sensor’s reported status and thresholds for component sensors.

Oracle Exadata CellCLI Quick Reference

Run cellcli on the storage cell, or run a single command from the OS shell with cellcli -e "...". CellCLI commands apply to the local cell; -m starts CellCLI in read-only monitor mode. Oracle: Starting CellCLI · Oracle: CellCLI command syntax

Cell and service health

cellcli -e "list cell detail"
cellcli -e "list cell attributes name,status,cellsrvStatus,msStatus,rsStatus,fanStatus,powerStatus,temperatureStatus"

Check cell status, CELLSRV/MS/RS, and hardware status attributes. list cell detail shows the full set of cell attributes.

Disk health and mapping

cellcli -e "list physicaldisk"
cellcli -e "list physicaldisk where status != normal detail"
cellcli -e "list celldisk"
cellcli -e "list celldisk where status != normal detail"
cellcli -e "list griddisk"
cellcli -e "list griddisk where status != active detail"
cellcli -e "list griddisk attributes name,asmModeStatus,asmDeactivationOutcome"
cellcli -e "list diskmap"

Typical states to check are physical disk normal, cell disk normal, and grid disk active. For ASM, asmModeStatus=ONLINE means ASM is using the grid disk; asmDeactivationOutcome=Yes means it can be deactivated without data loss. Treat that last attribute as status information, not authorization to deactivate a disk. Oracle: Physical disks · Oracle: Grid disks

LIST DISKMAP helps map physical disk slots and serials to cell disks and grid disks. Oracle: LIST

Alerts and cache

cellcli -e "list alerthistory where ageInMinutes < 1440 detail"
cellcli -e "list flashcache detail"
cellcli -e "list flashlog detail"

Alert history includes past alert records; review timestamps, severity, and messages to understand whether an alert is current or historical. Oracle: Alert history

CellCLI syntax tips

LIST <object> [WHERE <filter>] [ATTRIBUTES <attr-list>] [DETAIL]
DESCRIBE <object>
HELP

Examples:

LIST CELLDISK WHERE status != normal ATTRIBUTES name,status,physicalDisk
DESCRIBE GRIDDISK

Commands and object names are generally case-insensitive, and the ending semicolon is optional. DETAIL prints attributes one per line; ATTRIBUTES selects specific fields. Oracle: LIST command

tmux Quick Reference

DDefault prefix: press Ctrl-b, release it, then press the command key. Example: Ctrl-b, then c. tmux Getting Started

Sessions

tmux new -s work # Start a named session
tmux ls # List sessions
tmux attach -t work # Reattach to a session
tmux kill-session -t work

Ctrl-b d detaches from a session; it keeps running in the background.

Default keys

KeysAction
Ctrl-b cCreate a window
Ctrl-b ,Rename current window
Ctrl-b n / pNext / previous window
Ctrl-b 0–9Select window by number
Ctrl-b wChoose a window
Ctrl-b %Split pane left/right
Ctrl-b "Split pane top/bottom
Ctrl-b + arrowMove to pane in that direction
Ctrl-b oCycle through panes
Ctrl-b zZoom or unzoom current pane
Ctrl-b xClose current pane
Ctrl-b &Close current window
Ctrl-b [Enter copy mode; press q to leave
Ctrl-b dDetach
Ctrl-b ?Show key bindings
Ctrl-b :Open tmux command prompt

Window and pane close commands ask for confirmation. Key bindings can be listed with Ctrl-b ?; the official guide explains the prefix sequence and command prompt. tmux Getting Started

Commands at the tmux prompt

Press Ctrl-b :, type a command, then press Enter.

new-window -n logs
split-window -h # Left/right panes
split-window -v # Top/bottom panes
select-window -t :2
select-pane -L # Or -R, -U, -D
resize-pane -L 5 # Resize by 5 cells

Remember

  • Session: a workspace that can keep running after you detach.
  • Window: like a tab within a session.
  • Pane: a split terminal within a window.
  • Default prefix is Ctrl-b; tmux settings can change it. tmux(1) manual

How to copy a directory and everything inside it while preserving permissions and timestamps

Use cp -a to copy a directory and everything inside it while preserving permissions and timestamps:

cp -a /path/to/source_dir /path/to/destination/

If the destination directory doesn’t exist, it will be created. To copy only the contents of the source directory into an existing destination:

cp -a /path/to/source_dir/. /path/to/destination/

MariaDB: Enable remote connections

To enable remote connections to a MariaDB server, you typically need to follow these steps:

  1. Configure MariaDB to Listen on All Interfaces: By default, MariaDB might be configured to listen only on the localhost (127.0.0.1), which means it will not accept connections from remote machines. To change this, you need to edit the MariaDB configuration file.Locate the MariaDB configuration file, which is usually named my.cnf or my.ini depending on your operating system and MariaDB version.Add or modify the bind-address parameter in the [mysqld] section of the configuration file to listen on all interfaces:[mysqld] bind-address = 0.0.0.0
  2. Grant Remote Access Privileges: After configuring MariaDB to listen on all interfaces, you need to grant remote access privileges to the user account you want to use for remote connections. By default, remote access is not granted for security reasons.Connect to your MariaDB server using a MySQL client such as mysql or phpMyAdmin:bashCopy codemysql -u username -p Replace username with your MySQL username.Then, run the following SQL command to grant remote access to the user. Replace remote_user with the actual username and remote_host with the IP address or hostname of the remote machine:GRANT ALL PRIVILEGES ON *.* TO 'remote_user'@'remote_host' IDENTIFIED BY 'password' WITH GRANT OPTION; Replace 'password' with the password for the user account.Note: Using ALL PRIVILEGES is quite permissive. You may want to limit the privileges to the specific databases or tables the user needs access to.
  3. Firewall Configuration: Ensure that your firewall allows incoming connections on the MariaDB port (usually 3306). You might need to open this port if it’s blocked.
  4. Restart MariaDB: After making changes to the configuration file, restart the MariaDB service to apply the changes.sudo systemctl restart mariadb Use the appropriate command for your operating system if you’re not using systemd.

After following these steps, your MariaDB server should be configured to accept remote connections from the specified user account. Make sure to consider security implications and follow best practices when enabling remote access.

GitHub: Clone the Remote Repository and Create a New Branch

Below are the step-by-step instructions:

  1. Clone the Remote Repository and Create a New Branch: Clone the remote GitHub repository and create a new branch simultaneously by specifying the branch name with the -b flag.git clone -b <branch_name> <repository_URL> Replace <branch_name> with the name you want for your new branch and <repository_URL> with the URL of the GitHub repository.
  2. Navigate to the Cloned Repository: Change your current directory to the cloned repository.cd <repository_name> Replace <repository_name> with the name of the repository you cloned.
  3. Define GitHub Credentials: Set up your GitHub credentials for the repository:git config user.email "your_email@example.com" git config user.name "Your Name" Replace "your_email@example.com" with your GitHub email and "Your Name" with your GitHub username.
  4. Make Changes, Add, and Commit: Make changes to the files in the repository, then add and commit those changes.# Make changes to the files git add . git commit -m "Your commit message here" Replace "Your commit message here" with a brief description of the changes you made.
  5. Push Changes to GitHub: Push your changes to GitHub, specifying the new branch name.git push origin <new_branch_name> Replace <new_branch_name> with the name of the new branch you created.
  6. Enter GitHub Credentials (if prompted): If this is your first time pushing to the repository or if you’re pushing to a private repository, GitHub may prompt you to enter your GitHub username and password or personal access token.

After completing these steps, your changes should be pushed to the new branch on the GitHub repository successfully. You can verify this by visiting the GitHub repository in your web browser and checking if the changes are reflected there.

How to install Apache Airflow

To install Apache Airflow on Linux, you can follow these general steps. The following steps are for installing Airflow using pip, which is the recommended method.

  1. Prerequisites:
    • Python (typically version 3.6 or higher)
    • pip (Python package installer)
  2. Create a Virtual Environment (Optional): While not strictly necessary, it’s often a good practice to create a virtual environment to isolate the Python packages required for Airflow from your system’s Python environment. You can create a virtual environment using virtualenv or venv module.bashCopy code# Install virtualenv if you haven't already pip install virtualenv # Create a virtual environment virtualenv airflow_env # Activate the virtual environment source airflow_env/bin/activate
  3. Install Airflow: Once you have your environment set up, you can install Apache Airflow using pip.bashCopy codepip install apache-airflow
  4. Initialize Airflow Database: After installing Airflow, you need to initialize the metadata database. Airflow uses a database to store metadata related to task execution, connections, variables, and more.bashCopy codeairflow db init
  5. Start the Web Server and Scheduler: Airflow consists of a web server and a scheduler. The web server provides a UI to monitor and interact with your workflows, while the scheduler executes tasks on a predefined schedule.bashCopy code# Start the web server airflow webserver --port 8080 # Start the scheduler airflow scheduler
  6. Access Airflow UI: Once the web server is running, you can access the Airflow UI by opening a web browser and navigating to http://localhost:8080 or the appropriate address if you specified a different port.

Databricks: PySpark DataFrames in Databricks:

Below is a concise reference guide for working with PySpark DataFrames in Databricks:

1. Importing Required Libraries

You typically need to import the necessary modules to work with PySpark:

from pyspark.sql import SparkSession

2. Creating a SparkSession

A SparkSession is the entry point to programming Spark with the Dataset and DataFrame API. You create it as follows:

spark = SparkSession.builder \
.appName("MyApp") \
.getOrCreate()

3. Reading Data

You can read data from various sources into a DataFrame using read method:

df = spark.read.format("csv") \
.option("header", "true") \
.load("dbfs:/path/to/csv/file.csv")

4. Displaying Data

Databricks provides a convenient way to display DataFrames using the display() function:

display(df)

5. Operations and Transformations

Perform various operations and transformations on DataFrames such as selecting, filtering, aggregating, joining, etc.:

# Selecting columns
df.select("column1", "column2")

# Filtering
df.filter(df["column1"] > 10)

# Aggregating
df.groupBy("column1").agg({"column2": "sum"})

# Joining
df1.join(df2, "key_column")

6. Writing Data

Write DataFrame to various destinations such as CSV, JSON, Parquet, JDBC, etc.:

df.write.format("parquet") \
.mode("overwrite") \
.save("dbfs:/path/to/parquet/file")

7. SQL Queries

You can run SQL queries on DataFrames using SQL-like syntax:

df.createOrReplaceTempView("temp_table")
result = spark.sql("SELECT * FROM temp_table WHERE column1 > 10")

This reference provides a quick overview of commonly used operations and functionalities for working with PySpark DataFrames in Databricks. For more detailed information and advanced functionalities, you can refer to the official documentation or explore Databricks-specific features and optimizations.

CyberSecurity: The OWASP Top 10

The OWASP Top 10 is a widely recognized document that lists the top 10 most critical security risks to web applications. It is created and maintained by the Open Web Application Security Project (OWASP), a nonprofit organization dedicated to improving software security.

The OWASP Top 10 serves as a guideline for developers, security professionals, and organizations to understand and prioritize the most prevalent and impactful vulnerabilities in web applications. By addressing these vulnerabilities, organizations can enhance the security of their web applications and mitigate potential risks.

The specific vulnerabilities included in the OWASP Top 10 may evolve over time as new threats emerge and existing vulnerabilities are mitigated. As of the last update in 2021, the OWASP Top 10 list includes the following vulnerabilities:

  1. Injection: This includes SQL injection, NoSQL injection, and other injection vulnerabilities where untrusted data is sent to an interpreter as part of a command or query.
  2. Broken Authentication: Weaknesses in authentication mechanisms such as insufficient credential management, session fixation, and poor password management.
  3. Sensitive Data Exposure: Failure to properly protect sensitive data such as passwords, credit card numbers, and personal information through encryption or other security measures.
  4. XML External Entities (XXE): Vulnerabilities arising from the insecure processing of XML input, which can lead to disclosure of sensitive information, server-side request forgery (SSRF), and other attacks.
  5. Broken Access Control: Inadequate access controls that allow unauthorized users to access restricted functionality or data.
  6. Security Misconfiguration: Poorly configured security settings, default configurations, and other misconfigurations that expose vulnerabilities and increase the attack surface.
  7. Cross-Site Scripting (XSS): Vulnerabilities that allow attackers to execute malicious scripts in the context of a victim’s browser, leading to data theft, session hijacking, and other attacks.
  8. Insecure Deserialization: Vulnerabilities related to the insecure handling of serialized objects, which can lead to remote code execution, authentication bypass, and other exploits.
  9. Using Components with Known Vulnerabilities: Failure to update or patch third-party libraries, frameworks, and components, which may contain known vulnerabilities that attackers can exploit.
  10. Insufficient Logging and Monitoring: Inadequate logging and monitoring of security events, which hinders detection and response to security incidents.

It’s essential for organizations to regularly assess their web applications for these vulnerabilities and implement appropriate security measures to mitigate the risks they pose. Additionally, developers should follow secure coding practices and incorporate security into the software development lifecycle to minimize the likelihood of introducing vulnerabilities into their applications.

Network: DHCP DORA process

The DHCP (Dynamic Host Configuration Protocol) DORA process is a series of steps used by a DHCP client to obtain network configuration information from a DHCP server. “DORA” stands for Discover, Offer, Request, and Acknowledge. Here’s an explanation of each step:

  1. Discover (D):
    • In the Discover step, the DHCP client broadcasts a DHCP Discover message to locate available DHCP servers on the network.
    • The Discover message is sent as a broadcast packet with the destination IP address set to 255.255.255.255 and the destination MAC address set to ff:ff:ff:ff:ff:ff.
    • The Discover message includes the client’s hardware (MAC) address, identifying itself to potential DHCP servers.
    • The DHCP Discover message may also include optional parameters requested by the client, such as subnet mask, default gateway, DNS server, etc.
    • The client waits for DHCP Offer messages from available DHCP servers.
  2. Offer (O):
    • Upon receiving the DHCP Discover message, DHCP servers on the network respond with DHCP Offer messages.
    • Each DHCP server that receives the Discover message checks its available IP address pool and configuration settings to determine if it can fulfill the client’s request.
    • A DHCP Offer message includes an available IP address (leased from the server’s pool), subnet mask, lease duration, default gateway, DNS server, and any other configuration options requested by the client.
    • The DHCP Offer message is unicast to the client’s MAC address, as indicated in the Discover message.
    • If multiple DHCP servers respond with Offer messages, the client typically selects the first Offer it receives, although it may evaluate Offers based on other criteria such as lease duration or server preference.
  3. Request (R):
    • Upon receiving one or more DHCP Offer messages, the client selects an Offer and broadcasts a DHCP Request message to the DHCP servers.
    • The Request message confirms the selection of a specific DHCP server’s Offer and requests allocation of the offered IP address and associated configuration parameters.
    • If the client received multiple Offer messages, it may include the IP address of the chosen server in the Request message to ensure that the server knows it has been selected.
    • The Request message also serves as notification to other DHCP servers that their Offers were not accepted.
  4. Acknowledge (A):
    • After receiving the DHCP Request message, the DHCP server that made the Offer sends a DHCP Acknowledge (ACK) message to the client.
    • The Acknowledge message confirms the allocation of the requested IP address and provides the client with the lease duration and any other configuration parameters.
    • The Acknowledge message is unicast to the client’s MAC address.
    • Upon receiving the Acknowledge message, the client completes the configuration process, configures its network interface with the allocated IP address and other parameters, and begins using the network.

Overall, the DHCP DORA process allows DHCP clients to dynamically obtain network configuration information from DHCP servers, simplifying the process of network configuration and management in IP-based networks.