Introduction

Within WebLogic 14, out-of-the-box tools such as the Remote Console and WLST scripts provide some visibility, but they are limited when it comes to real-time metrics, historical analysis, or predictive monitoring.

This is where the Elastic Stack (Elasticsearch, Logstash, Beats, Elastic Agent, Kibana, and Elastic Machine Learning) delivers real value. By integrating WebLogic 14 logs, traces and metrics with Elastic Stack, you can build a unified platform that provides:

• Real-time observability of servers, threads, JDBC pools, and JVM health.
• Powerful visualization and analysis in Kibana.
• Predictive monitoring through anomaly detection and forecasting.

In this blog, we’ll walk through the integration of metrics step by step.

Step 1: Export WebLogic 14 Metrics

WebLogic does not natively expose metrics in formats suitable for Elastic or Prometheus. The solution is the WebLogic Monitoring Exporter, which translates JMX metrics into Prometheus-style output.

Download the exporter:

wget https://github.com/oracle/weblogic-monitoring-exporter/releases/download/v2.3.0/weblogic-monitoring-exporter.jar

Configure it (config.yaml):

domains:
  - name: mydomain
    url: t3://localhost:7001
    username: monitoruser
    password: XXXXXXXXXX
    metrics:
      - name: ServerHealth
      - name: ThreadPool
      - name: JDBCConnectionPool
      - name: JVMRuntime

Start the exporter:

java -jar weblogic-monitoring-exporter.jar --config=config.yaml

Verify metrics are exposed at:

http://localhost:8080/metrics

Step 2: Collect Metrics with Metricbeat

Elastic provides Metricbeat with a Prometheus module, making it easy to scrape WebLogic exporter metrics and send them to Elasticsearch.

Enable and configure the module:

metricbeat modules enable prometheus

prometheus.yml configuration:

- module: prometheus
  period: 10s
  hosts: ["http://localhost:8080"]
  metrics_path: /metrics

Start Metricbeat:

sudo metricbeat setup
sudo service metricbeat start

Now WebLogic metrics are flowing into Elasticsearch.

Step 3: Collect WebLogic Logs with Filebeat or Elastic Agent

Metrics give you system health, but logs provide context. To correlate performance issues with application errors, you should ingest WebLogic logs into Elasticsearch.

Option A: Using Filebeat

Install and configure Filebeat on the WebLogic server.

Example configuration (filebeat.yml):

filebeat.inputs:
  - type: log
    enabled: true
    paths:
      - /u02/app/weblogic/domains/mydomain/servers/*/logs/*.log
    fields:
      application: weblogic
    multiline.pattern: '^\<'
    multiline.negate: true
    multiline.match: after

output.elasticsearch:
  hosts: ["http://localhost:9200"]

And start Filebeat.

Option B: Using Elastic Agent (Recommended)

Elastic Agent simplifies deployment by combining logs, metrics, and security data collection into a single agent managed centrally via Kibana Fleet.

Steps:

1. Enroll the agent from Kibana – Fleet.
2. Attach the System + Custom Log integration.
3. Configure the WebLogic log path.
4. Deploy the agent on your WebLogic server.

This approach reduces operational overhead and centralizes configuration.

Next steps & Conclusion

Next steps:

• Build Observability Dashboards in Kibana
• Add APM for Transaction-Level Visibility
• Enable Machine Learning for Predictive Monitoring
• Configure Alerts

While WebLogic 14 provides essential administrative tooling, it does not offer full observability capabilities out of the box.

By integrating it with the Elastic Stack, you gain:

• Real-time operational insight
• Deep log and metric correlation
• Predictive monitoring with machine learning
• Actionable alerting
• Transaction-level visibility

This approach scales from a single WebLogic instance to enterprise clusters and hybrid cloud deployments.

In short: you move from reactive troubleshooting to proactive performance management.

See my Elastic blogs.

L’article WebLogic 14 & Elastic Stack: From Metrics to Predictive Insights est apparu en premier sur dbi Blog.

This is not just a documentation tweak or a recommendation shift. It is a hard security enforcement change driven by modern platform standards and compliance expectations from Red Hat.

If you remember only one thing from this article, remember this:

• JBoss EAP 7.4 allows credentials to be defined in multiple ways, including clear text.
• JBoss EAP 8 forces the use of Credential Stores for sensitive resources such as datasources.

JBoss EAP 7.4: Credential Stores were OPTIONAL

In EAP 7.4, Elytron credential stores were already available and recommended, but not enforced.

All of the following were valid and supported:

• Clear-text passwords in standalone.xml
• Encrypted expressions
• Elytron credential-store
• Legacy vault-based approaches (deprecated, but still functional)

A datasource like this was perfectly valid in 7.4:

<datasource jndi-name="java:/jdbc/MyDS" pool-name="MyDS">
    <connection-url>jdbc:postgresql://db:5432/app</connection-url>
    <user-name>app</user-name>
    <password>secret123</password>
</datasource>

JBoss EAP 8: Credential Stores are EFFECTIVELY MANDATORY

With JBoss EAP 8, Red Hat made a clear and intentional decision, sensitive credentials must no longer be stored directly in configuration files.

What changed in practice:

• The element for datasources is no longer the supported approach
• Datasources are expected to use credential-reference
• Elytron is no longer just the default security framework, it is the only one

A valid datasource configuration in EAP 8 looks like this:

<datasource jndi-name="java:/jdbc/MyDS" pool-name="MyDS">
    <connection-url>jdbc:postgresql://db:5432/app</connection-url>
    <user-name>app</user-name>
    <credential-reference store="cs-db" alias="db-password"/>
</datasource>

Why this enforcement exists in EAP 8

This change is not accidental or cosmetic. It aligns EAP with:

• OpenShift and container-native security expectations
• Compliance-driven environments (CIS, ISO, regulated industries)
• Modern “secrets management” practices

“Forced” does not mean “hard”

A common fear when moving to EAP 8 is: “Now everything is complicated” because of security!

In reality, the operational model becomes cleaner and more consistent.

Typical pattern:

1. Create one credential store
2. Add secrets once
3. Reference them everywhere

CLI example:

/subsystem=elytron/credential-store=cs-db:add(
  path=cs-db.jceks,
  relative-to=jboss.server.config.dir,
  credential-reference={clear-text=changeit}
)

/subsystem=elytron/credential-store=cs-db:add-alias(
  alias=db-password,
  secret-value=secret123
)

From that point on:

• No passwords in XML
• No passwords in Git
• No accidental leaks

Migration impact: where most upgrades fail

When upgrading from EAP 7.4 to EAP 8, you must:

• Identify all clear-text credentials
• Move them into credential stores
• Replace <password> with <credential-reference>

This step is mandatory in EAP 8.

Good news:

• If you already used credential stores in 7.4: migration is straightforward
• If you didn’t: EAP 8 forces a long-overdue cleanup

If you’re planning a move to JBoss EAP 8, I can help you get there safely.
From credential-store migration to full security hardening, I support organizations in turning a mandatory change into a controlled, successful upgrade.

L’article JBoss EAP – Credential Stores: from optional best practice to mandatory security baseline est apparu en premier sur dbi Blog.

Before we dive into commands and configurations, let’s anchor this in version history and explain an important staging step that many teams overlook.

WildFly version history

WildFly releases follow a rapid cadence, but some versions carry particular importance for migration:

Why Not Jump Directly from 26 to 38?

In theory you could try, but in practice, this is discouraged for several reasons:

1. Evolving Jakarta EE Support

WildFly 26 still contains remnants of older namespace patterns from the earlier Jakarta EE transition. WildFly 38 assumes:

• Full Jakarta EE 10 compliance
• Removal of deprecated subsystem elements

Staging through WildFly 36 means you pass through a version that:

• Consolidated many breaking changes
• Served as a stepping stone for configuration syntax modernization
• Was widely adopted and battle-tested by community users before WildFly 38

This reduces the “shock” of incompatible subsystems in one big jump.

2. Migration Tool Patching

The WildFly Migration Tool is better optimized when configurations change incrementally:

• From 26 to 36, the migration tool handles early syntax conversions
• From 36 to 38, it can focus on more recent modular and namespace adjustments

If you try to leap directly from 26 to 38, the migration tool may:

• Miss subtle differences
• Produce overly noisy reports
• Increase your manual remediation effort

Staging through 36 results in cleaner migration scripts, fewer manual manual fixes, and a more predictable process.

3. Security and Subsystem Consistency

Between 26 and 38, several subsystems saw significant reconfiguration:

• Elytron security policy changes
• Credential store formats
• Datasource definitions (Oracle and others became stricter)
• Logging and management interfaces

WildFly 36 introduced many of these changes incrementally so that:

• Administrators could adapt
• Tooling could reflect real-world environments before further evolution in WildFly 38

This made 36 a natural “landing zone” between the older 26 semantics and the newer 38 mechanics.

Migration Flow

The migration from WildFly 26 to WildFly 38 is intentionally performed in two controlled phases. This staged approach reduces risk, isolates problems earlier, and provides clear validation points before reaching the final production target.

Step 1 – Baseline: WildFly 26 (Current State)

The starting point is the existing WildFly 26 environment, typically running on Java 11 and hosting a stable, production-tested application.

At this stage:

• The platform is known and stable
• Configuration reflects historical decisions and legacy syntax
• Security, datasources, and deployments are tightly coupled to this version

No changes are made here except:

• Full backups
• Configuration review
• Inventory of customizations

WildFly 26 remains untouched and fully rollback-capable throughout the migration.

Step 2 – First Migration: WildFly 26 to WildFly 36

The first technical migration is performed using the WildFly migration tool, targeting WildFly 36.

This step focuses on:

• Converting legacy configuration syntax
• Removing deprecated or removed subsystems
• Preparing the configuration for newer Jakarta EE expectations

WildFly 36 acts as a transition platform:

• It supports Java 17
• It consolidates many breaking changes introduced after WildFly 26
• It allows configuration issues to be addressed incrementally rather than all at once

At this stage, the goal is not production readiness, but configuration correctness.

Step 3 – Staging and Validation on WildFly 36

Once the configuration is migrated, WildFly 36 is used as a staging environment for in-depth validation.

Key activities include:

• Running WildFly on Java 17
• Rebuilding or adjusting Elytron security components
• Recreating credential stores
• Validating datasource connectivity
• Starting the application and ensuring it runs
• Performing smoke tests and basic functional checks
• Allowing customer or application teams to execute targeted tests

When all tests pass:

• Configuration is frozen
• Known issues are documented
• The environment is considered stable enough to move forward

This step significantly reduces uncertainty before the final upgrade.

Step 4 – Second Migration: WildFly 36 to WildFly 38

With a validated configuration on WildFly 36, the second migration step is executed toward WildFly 38.

This phase:

• Uses the migration tool again
• Applies final syntax and subsystem adjustments
• Introduces stricter validation and enforcement present in WildFly 38

Because most major changes were already handled in the previous step, this migration is usually:

• Shorter
• Cleaner
• Easier to troubleshoot

WildFly 38 now represents the target platform, not just a test environment.

Step 5 – Final Validation on WildFly 38

Before production rollout, WildFly 38 undergoes final validation:

• Server startup and stability checks
• Security and datasource verification
• Application deployment validation
• Final smoke and regression tests

At this point, the platform should behave identically (or better) than WildFly 26, with the added benefits of:

• A modern Java runtime
• Up-to-date Jakarta EE support
• Improved security and maintainability

Step 6 – Production Rollout and Retirement of WildFly 26

Once validated:

• WildFly 38 is promoted to production
• Traffic is switched according to the customer’s deployment strategy
• WildFly 26 is retired in a controlled manner

Rollback remains trivial until decommissioning is complete, since:

• WildFly 26 was never modified
• All migrations were performed side-by-side

Summary

This staged migration approach ensures that:

• Configuration changes are isolated and understandable
• Security and infrastructure issues are discovered early
• Application teams have time to adapt and validate
• Production risk is minimized

By treating WildFly 36 as a stabilization checkpoint, the transition to WildFly 38 becomes predictable, controlled, and repeatable.

Don’t hesitate to reach out to discuss your WildFly or JBoss EAP migration project, we’ll be happy to help you move forward safely, efficiently, and with full transparency.

Related interesting blog: JBoss EAP vs Wildfly

L’article Migrating from WildFly 26 to WildFly 38 est apparu en premier sur dbi Blog.

For a TL;DR version of the answer, please go to the end of the blog, but in the meantime, here was my reasoning.

Setup differences between a secure and unsecure GoldenGate installation

Installation differences

From an installation perspective, the difference between a secure and unsecure installation is narrow. I talked earlier about graphic and silent GoldenGate installations, and for the silent installation, the following response file parameters are the only one involved in this security aspect:

# SECTION C - SECURITY MANAGER
SECURITY_ENABLED=false

# SECTION H - SECURITY
TLS_1_2_ENABLED=false
TLS_1_3_ENABLED=false
FIPS_ENABLED=false
SERVER_CERTIFICATE=
SERVER_CERTIFICATE_KEY_FILE=
SERVER_CA_CERTIFICATES_FILE=
CLIENT_CERTIFICATE=
CLIENT_CERTIFICATE_KEY_FILE=
CLIENT_CA_CERTIFICATES_FILE

*_ENABLED parameters are just flags that should be set to true to secure the installation (at least for SECURITY_ENABLED and one TLS parameter), and then you need to provide the certificate files (client and server, three for each).

To summarize, there is not much you have to do to configure a secure GoldenGate setup. So it shouldn’t be that difficult to enable these security features after installation: one flag, and a few certificates.

Configuration differences

From a configuration perspective, there are not many differences either. Looking at the deploymentConfiguration.dat file for both secure and unsecure service managers, the only difference lies in the SecurityManager.config.securityDetails section. After cleaning what is similar, here are the differences:

# Secure installation
            "securityDetails": {
                "network": {
                    "common": {
                        "fipsEnabled": false,
                    },
                    "inbound": {
                        "authMode": "clientOptional_server",
                        "cipherSuites": [
                            "TLS_AES_256_GCM_SHA384",
                            "TLS_AES_128_GCM_SHA256",
                            "TLS_CHACHA20_POLY1305_SHA256"
                        ],
                        "protocolVersion": "TLS_ALL"
                    },
                    "outbound": {
                        "authMode": "clientOptional_server",
                    }
                }
            },

# Unsecure installation
            "securityDetails": {
                "network": {
                    "common": {
                        "fipsEnabled": false,
                    },
                    "inbound": {
                        "authMode": "clientOptional_server",
                        "cipherSuites": "^((?!anon|RC4|NULL|3DES).)*$",
                    },
                    "outbound": {
                        "authMode": "client_server",
                    }
                }
            },

Basically, securityDetails.outbound.authMode is set to clientOptional_server on one side, and client_server on the other. And the unsecure configuration has a different securityDetails.inbound.cipherSuites parameter, and a missing securityDetails.protocolVersion parameter.

But nothing in the configuration points to the wallet files, locates in $OGG_ETC_HOME/ssl. So, how to add them here ?

Can you secure an unsecure GoldenGate installation ?

When connecting to an unsecure GoldenGate service manager, you still have the ability to add and manage certificates from the UI, the same way you would do on a secure installation:

It is unfortunate, but just adding the certificates from the UI doesn’t make your installation secure. In fact, even after modifying the deploymentConfiguration.dat files, the last piece missing in the configuration, as described above, it doesn’t work. You will only end up with a broken installation, even when doing the same with all your deployments and restarting everything.

Is there really no way to secure an already existing GoldenGate installation ?

Unfortunately, not at this point. And it was confirmed earlier this week on the MOSC forums by Gopal Gaur, Senior Principal Software Engineer working on GoldenGate at Oracle.

You can not convert non secure deployment into secure deployment, you will need a new service manager that supports sever side SSL/TLS.

You can not convert non secure deployment into secure deployment at this stage, we have an opened enhancement for this.

To wrap up, bad news: it is not possible to secure an existing GoldenGate installation, but good news, Oracle is apparently working on it. In the meantime, just re-install GoldenGate…

L’article Securing an Existing Unsecure GoldenGate Installation est apparu en premier sur dbi Blog.

Prerequisites for GoldenGate installation

You can set up GoldenGate in two different ways:

• From the base archive, available on eDelivery (V1042871-01.zip for Linux x86-64, for instance)
• From the patched archive, updated quarterly and available on the Oracle Support. At the time of writing of this blog, GoldenGate 23.9 is the latest version available (23.10, now called 23.26, was announced but not released yet). You can find the MOS Document 3093376.1 on the subject, or 2193391.1 for general patching information on GoldenGate. Patch 38139663 is the completely patched installation (we will use this one in the blog), while patch 38139662 is the patch-only archive, applied on an existing GoldenGate installation.

For the purpose of this installation, we will use the oracle-database-preinstall rpm, even if we don’t need all the things it brings. If you plan on installing GoldenGate on an existing Oracle database server, Oracle recommends using a separate user. We will keep oracle here.

[root@vmogg ~] dnf install -y oracle-database-preinstall-23ai
[root@vmogg ~] mkdir -p /u01/stage
[root@vmogg ~] chown oracle:oinstall -R /u01

With the oracle user created through the rpm installation, unzip GoldenGate source file into a stage area:

[root@vmogg ~] su - oracle
[oracle@vmogg ~] cd /u01/stage
[oracle@vmogg stage] unzip -oq p38139663_23902507OGGRU_Linux-x86-64.zip -d /u01/stage/

Installing GoldenGate with the OUI (graphic installation)

Installing GoldenGate binaries

Running the graphic installation of GoldenGate is not any different from what you would do with an Oracle database installation.

After setting up X11 display (out of the scope of this blog), you should first define the OGG_HOME variable to the location of the GoldenGate installation and then run the installer:

[oracle@vmogg ~]$ export OGG_HOME=/u01/app/oracle/product/ogg23ai
[oracle@vmogg ~]$ /u01/stage/fbo_ggs_Linux_x64_Oracle_services_shiphome/Disk1/runInstaller

Bug: depending on the display options you have, you might have a color mismatch on the GoldenGate installation window, most of it appearing black (see this image). If this happens, run the following command before launching the installation: export _JAVA_OPTIONS="-Dsun.java2d.xrender=false"

Just click Next on the first step. Starting from GoldenGate 23ai, Classic Architecture was desupported, so you don’t have to worry anymore about which architecture to choose. The Microservices Architecture is the only choice now.

Fill in the software location for your installation of GoldenGate. This will match the OGG_HOME environment variable. If the variable is set prior to launching the runInstaller, the software location is filled automatically.

Step 3 is just a summary of the installation. You can save the response file at this stage and use it later to standardize your installations with the silent installation described below. Then, click on Install.

After a few seconds, the installation is complete, and you can exit the installer.

If it’s your first Oracle-related installation on this server, you might have to run the /u01/app/oraInventory/orainstRoot.sh script as root when prompted to do so.

[root@vmogg ~]# /u01/app/oraInventory/orainstRoot.sh
Changing permissions of /u01/app/oraInventory.
Adding read,write permissions for group.
Removing read,write,execute permissions for world.

Changing groupname of /u01/app/oraInventory to oinstall.
The execution of the script is complete.

The binary installation is complete.

Installing the Service Manager and the First Deployment

Once the binaries are installed, with the same oracle X11 terminal, run the oggca.sh script located in the $OGG_HOME/bin directory:

[oracle@vmogg ~]$ export OGG_HOME=/u01/app/oracle/product/ogg23ai
[oracle@vmogg ~]$ $OGG_HOME/bin/oggca.sh

On the first step (see below), you will have:

• Software Home, which contains the GoldenGate binaries, also called $OGG_HOME
• Deployment Home, filled with the location of the service manager directory (and not the GoldenGate deployment, thank you Oracle for this one…).
• Port (default is 7809) of the service manager. This will be the main point of entry for the web UI.
• Register as a service/system daemon, if you want GoldenGate to be a service on your server.
• Integrate with XAG, for a GoldenGate RAC installation (out of the scope of this blog).
• Enable Security, with the associated certificates and key. You can leave this unchecked if you just want to test the GoldenGate installation process.
• We leave the rest unchecked.

Next, fill in the credentials for the service manager. Enabling Strong Password Policy will force you to enter a secure password.

In previous versions of GoldenGate, you could first set up the service manager and wait before configuring your first deployment. It is now mandatory to set up the first deployment:

• Deployment Name: ogg_test_01 for this installation. It is not just cosmetic, you will refer to this name for connection, in the adminclient and on the Web UI.
• Deployment Home: Path to the deployment home. Logs, trail files and configuration will sit there.
• Ports: Four ports need to be filled here. I would recommend using the default ports for the first deployment (7810, 7811, 7812 and 7813), or ports following the service manager port (7809). For a second deployment, you can continue with the following ports (7814, 7815, 7816, 7817), or keep the same units digit (7820, 7821, 7822, 7823) for a better understanding of your GoldenGate infrastructure.
• Remote Metrics for the Deployment: out of the scope of this blog, not needed for a basic GoldenGate installation.
• Security: If you secured your service manager earlier in the previous step, you should secure your deployment here, providing keys and certificates.
• Replication Options: TNS_ADMIN could already be filled, otherwise just specify its path. GoldenGate will look for TNS entries here. You should also fill in the replication schema name.

Later, fill in the credentials for the deployment. They can be different from the service manager credentials, or you can check the box to keep the same credentials.

In the summary screen, review your configuration, and save the response file for later if required. Click on Finish to start the installation.

The installation should take a few seconds:

That’s it, you have successfully installed GoldenGate 23ai ! Go to the web UI section for how to connect to your GoldenGate environment.

Installing GoldenGate with the CLI (silent installation)

Installing GoldenGate binaries

To perform the GoldenGate installation process in silent mode, you can either use a response file containing the arguments needed for the installation or give these arguments in the command line.

For the GoldenGate binaries installation, create a oggcore_23ai.rsp file, changing SOFTWARE_LOCATION, INVENTORY_LOCATION and UNIX_GROUP_NAME as needed:

[oracle@vmogg ~]$ cat oggcore_23ai.rsp
oracle.install.responseFileVersion=/oracle/install/rspfmt_ogginstall_response_schema_v23_1_0
INSTALL_OPTION=ORA23ai
SOFTWARE_LOCATION=/u01/app/oracle/product/ogg23ai
INVENTORY_LOCATION=/u01/app/oraInventory
UNIX_GROUP_NAME=oinstall

Then, run the installer with the -silent and -responseFile options:

[oracle@vmogg ~]$ /u01/stage/fbo_ggs_Linux_x64_Oracle_services_shiphome/Disk1/runInstaller -silent -responseFile /home/oracle/oggcore_23ai.rsp
Starting Oracle Universal Installer...

Checking Temp space: must be greater than 120 MB.   Actual 17094 MB    Passed
Checking swap space: must be greater than 150 MB.   Actual 4095 MB    Passed
Preparing to launch Oracle Universal Installer from /tmp/OraInstall2025-09-24_09-53-23AM. Please wait ...
You can find the log of this install session at:
 /u01/app/oraInventory/logs/installActions2025-09-24_09-53-23AM.log

As a root user, run the following script(s):
	1. /u01/app/oraInventory/orainstRoot.sh



Successfully Setup Software.
The installation of Oracle GoldenGate Services was successful.
Please check '/u01/app/oraInventory/logs/silentInstall2025-09-24_09-53-23AM.log' for more details.

Same thing as with the graphic installation: if it’s the first time you run an Oracle-related installation on this server, run the orainstRoot.sh script as root:

[root@vmogg ~]# /u01/app/oraInventory/orainstRoot.sh
Changing permissions of /u01/app/oraInventory.
Adding read,write permissions for group.
Removing read,write,execute permissions for world.

Changing groupname of /u01/app/oraInventory to oinstall.
The execution of the script is complete.

Installing the Service Manager and the First Deployment

Once the binaries are installed, run the oggca.sh script with the response file corresponding to the service manager and deployment that you want to create. The content of the response file oggca.rsp should be adapted to your needs, but I integrated a full example in the appendix below.

[oracle@vmogg ~]$ /u01/app/oracle/product/ogg23ai/bin/oggca.sh -silent -responseFile /home/oracle/oggca.rsp

As part of the process of registering Service Manager as a system daemon, the following steps will be performed:
	1- The deployment will be stopped before registering the Service Manager as a daemon.
	2- A new popup window will show the details of the script used to register the Service Manager as a daemon.
	3- After the register script is executed, the Service Manager daemon will be started in the background and the deployment will be automatically restarted.

Click "OK" to continue.

In order to register Service Manager as a system service/daemon, as a "root" user, execute the following script:
	(1). /u01/app/oracle/product/ogg23ai_SM/bin/registerServiceManager.sh

To execute the configuration scripts:
  1.Open a terminal window
  2.Login as "root"
  3.Run the script


Successfully Setup Software.

If you asked for the creation of a service, then run the following command as root:

[root@vmogg ~]# /u01/app/oracle/product/ogg23ai_SM/bin/registerServiceManager.sh
Copyright (c) 2017, 2024, Oracle and/or its affiliates. All rights reserved.
----------------------------------------------------
     Oracle GoldenGate Install As Service Script
----------------------------------------------------
OGG_HOME=/u01/app/oracle/product/ogg23ai
OGG_CONF_HOME=/u01/app/oracle/product/ogg23ai_SM/etc/conf
OGG_VAR_HOME=/u01/app/oracle/product/ogg23ai_SM/var
OGG_USER=oracle
Running OracleGoldenGateInstall.sh...
Created symlink /etc/systemd/system/multi-user.target.wants/OracleGoldenGate.service → /etc/systemd/system/OracleGoldenGate.service.
Successfully Setup Software.

Warning: If you plan on automating a GoldenGate installation and setup, make sure response files can only be read by the oracle user, and clean the response files if you need to keep passwords in plain text inside the file.

Adding or Removing a Deployment

To add or remove a deployment to an existing service manager, you can do that graphically with oggca.sh, or in silent mode. In silent mode, I give below a minimal response file example to add a new deployment (removing everything that would be already configured, like service manager properties). Of course, the deployment name, paths, and ports should be different from an existing deployment. And if your deployment is secured, you should fill SECTION H - SECURITY in the same way you did for the first installation, and specify SECURITY_ENABLED=true in SECTION C - SERVICE MANAGER.

Adding a deployment

oracle.install.responseFileVersion=/oracle/install/rspfmt_oggca_response_schema_v23_1_0

# SECTION A - GENERAL
CONFIGURATION_OPTION=ADD
DEPLOYMENT_NAME=ogg_test_02

# SECTION B - ADMINISTRATOR ACCOUNT
ADMINISTRATOR_USER=ogg
ADMINISTRATOR_PASSWORD=ogg_password
DEPLOYMENT_ADMINISTRATOR_USER=ogg
DEPLOYMENT_ADMINISTRATOR_PASSWORD=ogg_password

# SECTION C - SERVICE MANAGER
HOST_SERVICEMANAGER=your_host
PORT_SERVICEMANAGER=7809
SECURITY_ENABLED=false
STRONG_PWD_POLICY_ENABLED=false

# SECTION E - SOFTWARE HOME
OGG_SOFTWARE_HOME=/u01/app/oracle/product/ogg23ai

# SECTION F - DEPLOYMENT DIRECTORIES
OGG_DEPLOYMENT_HOME=/u01/app/oracle/product/ogg_test_02
OGG_ETC_HOME=/u01/app/oracle/product/ogg_test_02/etc
OGG_CONF_HOME=/u01/app/oracle/product/ogg_test_02/etc/conf
OGG_SSL_HOME=/u01/app/oracle/product/ogg_test_02/etc/ssl
OGG_VAR_HOME=/u01/app/oracle/product/ogg_test_02/var
OGG_DATA_HOME=/u01/app/oracle/product/ogg_test_02/var/lib/data
OGG_ARCHIVE_HOME=/u01/app/oracle/product/ogg_test_02/var/lib/archive

# SECTION G - ENVIRONMENT VARIABLES
ENV_LD_LIBRARY_PATH=${OGG_HOME}/lib/instantclient:${OGG_HOME}/lib
ENV_TNS_ADMIN=/u01/app/oracle/network/admin
ENV_STREAMS_POOL_SIZE=
ENV_USER_VARS=

# SECTION H - SECURITY
TLS_1_2_ENABLED=false
TLS_1_3_ENABLED=false
FIPS_ENABLED=false
SERVER_CERTIFICATE=
SERVER_CERTIFICATE_KEY_FILE=
SERVER_CA_CERTIFICATES_FILE=
CLIENT_CERTIFICATE=
CLIENT_CERTIFICATE_KEY_FILE=
CLIENT_CA_CERTIFICATES_FILE=

# SECTION I - SERVICES
ADMINISTRATION_SERVER_ENABLED=true
PORT_ADMINSRVR=7820
DISTRIBUTION_SERVER_ENABLED=true
PORT_DISTSRVR=7821
NON_SECURE_DISTSRVR_CONNECTS_TO_SECURE_RCVRSRVR=false
RECEIVER_SERVER_ENABLED=true
PORT_RCVRSRVR=7822
METRICS_SERVER_ENABLED=true
METRICS_SERVER_IS_CRITICAL=false
PORT_PMSRVR=7823
PMSRVR_DATASTORE_TYPE=BDB
PMSRVR_DATASTORE_HOME=
ENABLE_DEPLOYMENT_REMOTE_METRICS=false
DEPLOYMENT_REMOTE_METRICS_LISTENING_HOST=
DEPLOYMENT_REMOTE_METRICS_LISTENING_PORT=0

# SECTION J - REPLICATION OPTIONS
OGG_SCHEMA=OGGADMIN

Removing a deployment

Same thing for the removal of an existing deployment, where the minimal response file is even simpler. You just need the deployment name and service manager information.

oracle.install.responseFileVersion=/oracle/install/rspfmt_oggca_response_schema_v23_1_0

# SECTION A - GENERAL
CONFIGURATION_OPTION=REMOVE
DEPLOYMENT_NAME=ogg_test_02

# SECTION B - ADMINISTRATOR ACCOUNT
ADMINISTRATOR_USER=ogg
ADMINISTRATOR_PASSWORD=ogg_password
DEPLOYMENT_ADMINISTRATOR_USER=ogg
DEPLOYMENT_ADMINISTRATOR_PASSWORD=ogg_password

# SECTION C - SERVICE MANAGER
HOST_SERVICEMANAGER=your_host
PORT_SERVICEMANAGER=7809
SECURITY_ENABLED=false

# SECTION H - SECURITY
TLS_1_2_ENABLED=false
TLS_1_3_ENABLED=false
FIPS_ENABLED=false
SERVER_CERTIFICATE=
SERVER_CERTIFICATE_KEY_FILE=
SERVER_CA_CERTIFICATES_FILE=
CLIENT_CERTIFICATE=
CLIENT_CERTIFICATE_KEY_FILE=
CLIENT_CA_CERTIFICATES_FILE=

# SECTION K - REMOVE DEPLOYMENT OPTIONS
REMOVE_DEPLOYMENT_FROM_DISK=true

Accessing the Web UI

Whether you installed GoldenGate graphically or silently, you will now be able to connect to the Web UI. Except for the design, it is pretty much the same thing as the Microservices Architecture of GoldenGate 19c and 21c. Connect to the hostname of your GoldenGate installation, on the service manager port: http://hostname:port, or https://hostname:post if the installation is secured.

With the example of this blog:

• 7809 — Service manager
• 7810 — Administration service of the first deployment you created, for managing extracts and replicats
• 7811 — Distribution service, to send trail files to other GoldenGate deployments.
• 7812 — Receiver service, to receive trail files.
• 7813 — Performance metrics service, for extraction and replication analysis.

Log in either with the service manager credentials, or with the deployment credentials:

Service Manager Web UI

The service manager web UI allows you to stop and start deployment services, manage users and certificates. You will hardly ever use it, even less since deployment creation/removal will be done through oggca.sh anyway. If you have many deployments, it can still be useful to log in to these deployments quickly.

Deployment Web UI

The deployment web UI, however, is used throughout the whole lifecycle of your GoldenGate replications. You manage extracts, replicats, distribution paths, and more.

NB for the newcomers: you don’t have to bookmark all the services of a deployment. Once logged in to the administration service of a deployment, you can just jump between services through the UI, by clicking on the services on the top bar.

You now have a full GoldenGate 23ai installation, and can start configuring your first replication !

Appendix: oggca.rsp example

Here is an example of a response file to create both the service manager and the first deployment of a GoldenGate installation. I included at the end the full file with Oracle annotations.

oracle.install.responseFileVersion=/oracle/install/rspfmt_oggca_response_schema_v23_1_0

# SECTION A - GENERAL
CONFIGURATION_OPTION=ADD
DEPLOYMENT_NAME=ogg_test_01

# SECTION B - ADMINISTRATOR ACCOUNT
ADMINISTRATOR_USER=ogg
ADMINISTRATOR_PASSWORD=ogg_password
DEPLOYMENT_ADMINISTRATOR_USER=ogg
DEPLOYMENT_ADMINISTRATOR_PASSWORD=ogg_password

# SECTION C - SERVICE MANAGER
SERVICEMANAGER_DEPLOYMENT_HOME=/u01/app/oracle/product/ogg23ai_SM
SERVICEMANAGER_ETC_HOME=/u01/app/oracle/product/ogg23ai_SM/etc
SERVICEMANAGER_CONF_HOME=/u01/app/oracle/product/ogg23ai_SM/etc/conf
SERVICEMANAGER_SSL_HOME=/u01/app/oracle/product/ogg23ai_SM/etc/ssl
SERVICEMANAGER_VAR_HOME=/u01/app/oracle/product/ogg23ai_SM/var
SERVICEMANAGER_DATA_HOME=/u01/app/oracle/product/ogg23ai_SM/var/lib/data
SERVICEMANAGER_ARCHIVE_HOME=/u01/app/oracle/product/ogg23ai_SM/var/lib/archive
HOST_SERVICEMANAGER=your_host
PORT_SERVICEMANAGER=7809
SECURITY_ENABLED=false
STRONG_PWD_POLICY_ENABLED=false
CREATE_NEW_SERVICEMANAGER=true
REGISTER_SERVICEMANAGER_AS_A_SERVICE=true
INTEGRATE_SERVICEMANAGER_WITH_XAG=false
EXISTING_SERVICEMANAGER_IS_XAG_ENABLED=false
ENABLE_SERVICE_MANAGER_REMOTE_METRICS=false
SERVICE_MANAGER_REMOTE_METRICS_LISTENING_HOST=
SERVICE_MANAGER_REMOTE_METRICS_LISTENING_PORT=0
PLUGIN_SERVICE_ENABLED=false

# SECTION D - CONFIGURATION SRVICE
CONFIGURATION_SERVICE_ENABLED=false
CONFIGURATION_SERVICE_BACKEND_TYPE=FILESYSTEM
CONFIGURATION_SERVICE_BACKEND_CONNECTION_STRING=
CONFIGURATION_SERVICE_BACKEND_USERNAME=
CONFIGURATION_SERVICE_BACKEND_PASSWORD=
CONFIGURATION_SERVICE_BACKEND_TABLE_NAME=

# SECTION E - SOFTWARE HOME
OGG_SOFTWARE_HOME=/u01/app/oracle/product/ogg23ai

# SECTION F - DEPLOYMENT DIRECTORIES
OGG_DEPLOYMENT_HOME=/u01/app/oracle/product/ogg_test_01
OGG_ETC_HOME=/u01/app/oracle/product/ogg_test_01/etc
OGG_CONF_HOME=/u01/app/oracle/product/ogg_test_01/etc/conf
OGG_SSL_HOME=/u01/app/oracle/product/ogg_test_01/etc/ssl
OGG_VAR_HOME=/u01/app/oracle/product/ogg_test_01/var
OGG_DATA_HOME=/u01/app/oracle/product/ogg_test_01/var/lib/data
OGG_ARCHIVE_HOME=/u01/app/oracle/product/ogg_test_01/var/lib/archive

# SECTION G - ENVIRONMENT VARIABLES
ENV_LD_LIBRARY_PATH=${OGG_HOME}/lib/instantclient:${OGG_HOME}/lib
ENV_TNS_ADMIN=/u01/app/oracle/network/admin
ENV_STREAMS_POOL_SIZE=
ENV_USER_VARS=

# SECTION H - SECURITY
TLS_1_2_ENABLED=false
TLS_1_3_ENABLED=true
FIPS_ENABLED=false
SERVER_CERTIFICATE=
SERVER_CERTIFICATE_KEY_FILE=
SERVER_CA_CERTIFICATES_FILE=
CLIENT_CERTIFICATE=
CLIENT_CERTIFICATE_KEY_FILE=
CLIENT_CA_CERTIFICATES_FILE=

# SECTION I - SERVICES
ADMINISTRATION_SERVER_ENABLED=true
PORT_ADMINSRVR=7810
DISTRIBUTION_SERVER_ENABLED=true
PORT_DISTSRVR=7811
NON_SECURE_DISTSRVR_CONNECTS_TO_SECURE_RCVRSRVR=false
RECEIVER_SERVER_ENABLED=true
PORT_RCVRSRVR=7812
METRICS_SERVER_ENABLED=true
METRICS_SERVER_IS_CRITICAL=false
PORT_PMSRVR=7813
PMSRVR_DATASTORE_TYPE=BDB
PMSRVR_DATASTORE_HOME=
ENABLE_DEPLOYMENT_REMOTE_METRICS=false
DEPLOYMENT_REMOTE_METRICS_LISTENING_HOST=
DEPLOYMENT_REMOTE_METRICS_LISTENING_PORT=0

# SECTION J - REPLICATION OPTIONS
OGG_SCHEMA=OGGADMIN

# SECTION K - REMOVE DEPLOYMENT OPTIONS
REMOVE_DEPLOYMENT_FROM_DISK=

Full file :

################################################################################
## Copyright(c) Oracle Corporation 2016, 2024. All rights reserved.           ##
##                                                                            ##
## Specify values for the variables listed below to customize your            ##
## installation.                                                              ##
##                                                                            ##
## Each variable is associated with a comment. The comments can help to       ##
## populate the variables with the appropriate values.                        ##
##                                                                            ##
## IMPORTANT NOTE: This file should be secured to have read permission only   ##
## by the Oracle user or an administrator who owns this configuration to      ##
## protect any sensitive input values.                                        ##
##                                                                            ##
################################################################################

#-------------------------------------------------------------------------------
# Do not change the following system generated value. 
#-------------------------------------------------------------------------------
oracle.install.responseFileVersion=/oracle/install/rspfmt_oggca_response_schema_v23_1_0


################################################################################
##                                                                            ##
## Oracle GoldenGate deployment configuration options and details             ##
##                                                                            ##
################################################################################

################################################################################
##                                                                            ##
## Instructions to fill out this response file                                ##
## -------------------------------------------                                ##
## Fill out section A, B, and C for general deployment information            ##
## Additionally:                                                              ##  
## Fill out sections D, E, F, G, H, I, and J for adding a deployment          ##
## Fill out section K for removing a deployment                               ##
##                                                                            ##
################################################################################

################################################################################
#                                                                              #
#                          SECTION A - GENERAL                                 #
#                                                                              #
################################################################################

#-------------------------------------------------------------------------------
# Specify the configuration option.
# Specify: 
# - ADD    : for adding a new GoldenGate deployment.
# - REMOVE : for removing an existing GoldenGate deployment. 
#-------------------------------------------------------------------------------
CONFIGURATION_OPTION=ADD

#-------------------------------------------------------------------------------
# Specify the name for the new or existing deployment.
#-------------------------------------------------------------------------------
DEPLOYMENT_NAME=ogg_test_01


################################################################################
#                                                                              #
#                       SECTION B - ADMINISTRATOR ACCOUNT                      #
#                                                                              #
# * If creating a new Service Manager, set the Administrator Account username  #
#   and password.                                                              #
#                                                                              #
# * If reusing an existing Service Manager:                                    #
#     * Enter the credentials for the Administrator Account in                 #
#       the existing Service Manager.                                          #
#                                                                              #
################################################################################

#-------------------------------------------------------------------------------
# Specify the administrator account username for the Service Manager.
#-------------------------------------------------------------------------------
ADMINISTRATOR_USER=ogg

#-------------------------------------------------------------------------------
# Specify the administrator account password for the Service Manager.
#-------------------------------------------------------------------------------
ADMINISTRATOR_PASSWORD=ogg_password

#-------------------------------------------------------------------------------
# Optionally, specify a different administrator account username for the deployment,
# or leave blanks to use the same Service Manager administrator credentials.
#-------------------------------------------------------------------------------
DEPLOYMENT_ADMINISTRATOR_USER=ogg

#-------------------------------------------------------------------------------
# If creating a different administrator account username for the deployment, 
# specify the password for it.
#-------------------------------------------------------------------------------
DEPLOYMENT_ADMINISTRATOR_PASSWORD=ogg_password


################################################################################
#                                                                              #
#                       SECTION C - SERVICE MANAGER                            #
#                                                                              #
################################################################################

#-------------------------------------------------------------------------------
# Specify the location for the Service Manager deployment.
# This is only needed if the Service Manager deployment doesn't exist already.
#-------------------------------------------------------------------------------
SERVICEMANAGER_DEPLOYMENT_HOME=/u01/app/oracle/product/ogg23ai_SM

#-------------------------------------------------------------------------------
# Optionally, specify a custom location for the Service Manager deployment ETC_HOME.
#-------------------------------------------------------------------------------
SERVICEMANAGER_ETC_HOME=/u01/app/oracle/product/ogg23ai_SM/etc

#-------------------------------------------------------------------------------
# Optionally, specify a custom location for the Service Manager deployment CONF_HOME.
#-------------------------------------------------------------------------------
SERVICEMANAGER_CONF_HOME=/u01/app/oracle/product/ogg23ai_SM/etc/conf

#-------------------------------------------------------------------------------
# Optionally, specify a custom location for the Service Manager deployment SSL_HOME.
#-------------------------------------------------------------------------------
SERVICEMANAGER_SSL_HOME=/u01/app/oracle/product/ogg23ai_SM/etc/ssl

#-------------------------------------------------------------------------------
# Optionally, specify a custom location for the Service Manager deployment VAR_HOME.
#-------------------------------------------------------------------------------
SERVICEMANAGER_VAR_HOME=/u01/app/oracle/product/ogg23ai_SM/var

#-------------------------------------------------------------------------------
# Optionally, specify a custom location for the Service Manager deployment DATA_HOME.
#-------------------------------------------------------------------------------
SERVICEMANAGER_DATA_HOME=/u01/app/oracle/product/ogg23ai_SM/var/lib/data

#-------------------------------------------------------------------------------
# Optionally, specify a custom location for the Service Manager deployment ARCHIVE_HOME.
#-------------------------------------------------------------------------------
SERVICEMANAGER_ARCHIVE_HOME=/u01/app/oracle/product/ogg23ai_SM/var/lib/archive

#-------------------------------------------------------------------------------
# Specify the host for the Service Manager.
#-------------------------------------------------------------------------------
HOST_SERVICEMANAGER=your_host

#-------------------------------------------------------------------------------
# Specify the port for the Service Manager.
#-------------------------------------------------------------------------------
PORT_SERVICEMANAGER=7809

#-------------------------------------------------------------------------------
# Specify if SSL / TLS is or will be enabled for the deployment.
# Specify true if SSL / TLS is or will be enabled, false otherwise.
#-------------------------------------------------------------------------------
SECURITY_ENABLED=false

#-------------------------------------------------------------------------------
# Specify if the deployment should enforce a strong password policy.
# Specify true to enable strong password policy management.
#-------------------------------------------------------------------------------
STRONG_PWD_POLICY_ENABLED=false

#-------------------------------------------------------------------------------
# Specify if a new Service Manager should be created. 
# Specify true if a new Service Manager should be created, false otherwise.
#
# This option is only needed when CONFIGURATION_OPTION is ADD.
#-------------------------------------------------------------------------------
CREATE_NEW_SERVICEMANAGER=true

#-------------------------------------------------------------------------------
# Specify if Service Manager should be registered as a service/daemon. This option is mutually exclusive with the 'INTEGRATE_SERVICEMANAGER_WITH_XAG' option.
# Specify true if Service Manager should be registered as a service, false otherwise.
#
# This option is only needed when CONFIGURATION_OPTION is ADD.
# This option does not apply to Windows platform.
#-------------------------------------------------------------------------------
REGISTER_SERVICEMANAGER_AS_A_SERVICE=true
#-------------------------------------------------------------------------------
# Specify if Service Manager should be integrated with XAG. This option is mutually exclusive with the 'REGISTER_SERVICEMANAGER_AS_A_SERVICE' option.
# Specify true if Service Manager should be integrated with XAG, false otherwise.
#
# This option is only needed when CONFIGURATION_OPTION is ADD.
# This option is only supported for Oracle databases.
#-------------------------------------------------------------------------------
INTEGRATE_SERVICEMANAGER_WITH_XAG=false

#-------------------------------------------------------------------------------
# If using an existing Service Manager, specify if it is integrated with XAG.
# Specify true if the existing Service Manager is integrated with XAG, false otherwise.
#
# This option is only needed when CONFIGURATION_OPTION is ADD.
# This option is only supported for Oracle databases.
#-------------------------------------------------------------------------------
EXISTING_SERVICEMANAGER_IS_XAG_ENABLED=false

#-------------------------------------------------------------------------------
# Specify if Remote Metrics using StatsD protocol will be enabled for the Service Manager
# Specify true if Remote Metrics for the Service Manager will be enabled, false otherwise
#-------------------------------------------------------------------------------
ENABLE_SERVICE_MANAGER_REMOTE_METRICS=false

#-------------------------------------------------------------------------------
# If Remote Metrics for the Service Manager will be enabled, specify the listening host
#-------------------------------------------------------------------------------
SERVICE_MANAGER_REMOTE_METRICS_LISTENING_HOST=

#-------------------------------------------------------------------------------
# If Remote Metrics for the Service Manager will be enabled, specify the listening port for that server
#-------------------------------------------------------------------------------
SERVICE_MANAGER_REMOTE_METRICS_LISTENING_PORT=0

#-------------------------------------------------------------------------------
# Specify if the Plugin Service for the Service Manager will be enabled.
# Specify true if the Plugin Service will be enabled, false otherwise.
#-------------------------------------------------------------------------------
PLUGIN_SERVICE_ENABLED=false
###############################################################################
#                                                                             #  
#                    SECTION D - CONFIGURATION SERVICE                        #
#                                                                             #
###############################################################################

#-------------------------------------------------------------------------------
# Specify if the Configuration Service will be enabled.
# Specify true if the Configuration Service will be enabled, false otherwise.
#-------------------------------------------------------------------------------
CONFIGURATION_SERVICE_ENABLED=false

#-------------------------------------------------------------------------------
# Specify the Configuration Service backend type.
# Specify:
# - FILESYSTEM
# - ORACLE_DATABASE
#
# This is only needed if the Configuration Service will be enabled
#-------------------------------------------------------------------------------
CONFIGURATION_SERVICE_BACKEND_TYPE=FILESYSTEM

#-------------------------------------------------------------------------------
# Specify the Configuration Service connection string for the database backend
#
# This is only needed if:
#     * The Configuration Service will be enabled
#     * CONFIGURATION_SERVICE_BACKEND_TYPE is ORACLE_DATABASE
#-------------------------------------------------------------------------------
CONFIGURATION_SERVICE_BACKEND_CONNECTION_STRING=

#-------------------------------------------------------------------------------
# Specify the Configuration Service username for the database backend
#
# This is only needed if: 
#     * The Configuration Service will be enabled
#     * CONFIGURATION_SERVICE_BACKEND_TYPE is ORACLE_DATABASE
#-------------------------------------------------------------------------------
CONFIGURATION_SERVICE_BACKEND_USERNAME=

#-------------------------------------------------------------------------------
# Specify the Configuration Service password for the database backend
#
# This is only needed if: 
#     * The Configuration Service will be enabled
#     * CONFIGURATION_SERVICE_BACKEND_TYPE is ORACLE_DATABASE
#-------------------------------------------------------------------------------
CONFIGURATION_SERVICE_BACKEND_PASSWORD=

#-------------------------------------------------------------------------------
# Specify the Configuration Service table name for the database backend
#
# This is only needed if: 
#     * The Configuration Service will be enabled
#     * CONFIGURATION_SERVICE_BACKEND_TYPE is ORACLE_DATABASE
#-------------------------------------------------------------------------------
CONFIGURATION_SERVICE_BACKEND_TABLE_NAME=
###############################################################################
#                                                                             #
#                       SECTION E - SOFTWARE HOME                             #
#                                                                             #
###############################################################################

#-------------------------------------------------------------------------------
# Specify the existing OGG software home location.
#-------------------------------------------------------------------------------
OGG_SOFTWARE_HOME=/u01/app/oracle/product/OGG_23.9.0.25.07


###############################################################################
#                                                                             #
#                       SECTION F - DEPLOYMENT DIRECTORIES                    #
#                                                                             #
###############################################################################

#-------------------------------------------------------------------------------
# Specify the location of the new or existing OGG deployment.
#-------------------------------------------------------------------------------
OGG_DEPLOYMENT_HOME=/u01/app/oracle/product/ogg_test_01

#-------------------------------------------------------------------------------
# Specify the location for OGG_ETC_HOME.
#-------------------------------------------------------------------------------
OGG_ETC_HOME=/u01/app/oracle/product/ogg_test_01/etc

#-------------------------------------------------------------------------------
# Specify the location for OGG_CONF_HOME.
#-------------------------------------------------------------------------------
OGG_CONF_HOME=/u01/app/oracle/product/ogg_test_01/etc/conf

#-------------------------------------------------------------------------------
# Specify the location for OGG_SSL_HOME.
#-------------------------------------------------------------------------------
OGG_SSL_HOME=/u01/app/oracle/product/ogg_test_01/etc/ssl

#-------------------------------------------------------------------------------
# Specify the location for OGG_VAR_HOME.
#-------------------------------------------------------------------------------
OGG_VAR_HOME=/u01/app/oracle/product/ogg_test_01/var

#-------------------------------------------------------------------------------
# Specify the location for OGG_DATA_HOME.
#-------------------------------------------------------------------------------
OGG_DATA_HOME=/u01/app/oracle/product/ogg_test_01/var/lib/data

#-------------------------------------------------------------------------------
# Specify the location for OGG_ARCHIVE_HOME.
#-------------------------------------------------------------------------------
OGG_ARCHIVE_HOME=/u01/app/oracle/product/ogg_test_01/var/lib/archive

###############################################################################
#                                                                             #
#                       SECTION G - ENVIRONMENT VARIABLES                     #
#                                                                             #
###############################################################################

#-------------------------------------------------------------------------------
# Specify the value for the LD_LIBRARY_PATH environment variable.
#-------------------------------------------------------------------------------
ENV_LD_LIBRARY_PATH=${OGG_HOME}/lib/instantclient:${OGG_HOME}/lib

#-------------------------------------------------------------------------------
# Specify the value for the TNS_ADMIN environment variable.
# This environment variable is only for Oracle Databases.
#-------------------------------------------------------------------------------
ENV_TNS_ADMIN=/u01/app/oracle/network/admin

#-------------------------------------------------------------------------------
# This option is only needed when Sharding will be enabled.
# Specify the value for the STREAMS_POOL_SIZE environment variable.
# This environment variable is only for Oracle Databases.
#-------------------------------------------------------------------------------
ENV_STREAMS_POOL_SIZE=

#-------------------------------------------------------------------------------
# Specify any additional environment variables to be set in the deployment.
#-------------------------------------------------------------------------------
ENV_USER_VARS=


###############################################################################
#                                                                             #
#                           SECTION H - SECURITY                              #
#           This section is only needed if Security will be enabled           #
#                                                                             #
###############################################################################

# ------------------------------------------------------------------------------
# If security will be enabled, specify if TLS v1.2 will be enabled.
# Specify true if TLS v1.2 will be enabled, false otherwise.
#-------------------------------------------------------------------------------
TLS_1_2_ENABLED=false

# ------------------------------------------------------------------------------
# If security will be enabled, specify if TLS v1.3 will be enabled. 
# Specify true if TLS v1.3 will be enabled, false otherwise.
#-------------------------------------------------------------------------------
TLS_1_3_ENABLED=true

#-------------------------------------------------------------------------------
# Specify if FIPS will be enabled.
#-------------------------------------------------------------------------------
FIPS_ENABLED=false

#-------------------------------------------------------------------------------
# If SSL / TLS will be enabled, specify the server certificate 
#-------------------------------------------------------------------------------
SERVER_CERTIFICATE=

#-------------------------------------------------------------------------------
# If importing a server certificate, specify the private key file in PKCS#8 format
# The private key file must not be encrypted
#-------------------------------------------------------------------------------
SERVER_CERTIFICATE_KEY_FILE=

#-------------------------------------------------------------------------------
# If importing a server certificate, optionally specify the CA certificates file
#-------------------------------------------------------------------------------
SERVER_CA_CERTIFICATES_FILE=

#-------------------------------------------------------------------------------
# If SSL / TLS will be enabled, optionally specify the client certificate.
#-------------------------------------------------------------------------------
CLIENT_CERTIFICATE=

#-------------------------------------------------------------------------------
# If importing a client certificate, specify the private key file in PKCS#8 format
# The private key file must not be encrypted
#-------------------------------------------------------------------------------
CLIENT_CERTIFICATE_KEY_FILE=

#-------------------------------------------------------------------------------
# If importing a client certificate, optionally specify the CA certificates file
#-------------------------------------------------------------------------------
CLIENT_CA_CERTIFICATES_FILE=


###############################################################################
#                                                                             #
#                           SECTION I - SERVICES                              #
#                                                                             #
###############################################################################

#-------------------------------------------------------------------------------
# Specify if the Administration server will be enabled.
# Specify true if the Administration server will be enabled, false otherwise.
#-------------------------------------------------------------------------------
ADMINISTRATION_SERVER_ENABLED=true

#-------------------------------------------------------------------------------
# Required only if the Administration server will be enabled. 
# Specify the port for Administration Server.
#-------------------------------------------------------------------------------
PORT_ADMINSRVR=7810

#-------------------------------------------------------------------------------
# Specify if the Distribution server will be enabled.
# Specify true if the Distribution server will be enabled, false otherwise.
#-------------------------------------------------------------------------------
DISTRIBUTION_SERVER_ENABLED=true

#-------------------------------------------------------------------------------
# Required only if the Distribution server will be enabled. 
# Specify the port for Distribution Server.
#-------------------------------------------------------------------------------
PORT_DISTSRVR=7811

#-------------------------------------------------------------------------------
# If security is disabled, specify if this non-secure deployment will be used
# to send trail data to a secure deployment.
#-------------------------------------------------------------------------------
NON_SECURE_DISTSRVR_CONNECTS_TO_SECURE_RCVRSRVR=false

#-------------------------------------------------------------------------------
# Specify if the Receiver server will be enabled.
# Specify true if the Receiver server will be enabled, false otherwise.
#-------------------------------------------------------------------------------
RECEIVER_SERVER_ENABLED=true

#-------------------------------------------------------------------------------
# Required only if the Receiver server will be enabled. 
# Specify the port for Receiver Server.
#-------------------------------------------------------------------------------
PORT_RCVRSRVR=7812

#-------------------------------------------------------------------------------
# Specify if Performance Metrics server will be enabled.
# Specify true if Performance Metrics server will be enabled, false otherwise.
#-------------------------------------------------------------------------------
METRICS_SERVER_ENABLED=true
#-------------------------------------------------------------------------------
# Specify if Performance Metrics server is a critical service.
# Specify true if Performance Metrics server is a critical service, false otherwise.
#
# This is optional and only takes effect when Performance Metrics server will be enabled.
# Also, this option should only be set when the Service Manager is integrated with XAG.
# The default value is false.
#
# This option is only supported for Oracle databases.
#-------------------------------------------------------------------------------
METRICS_SERVER_IS_CRITICAL=false

#-------------------------------------------------------------------------------
# Specify the port for Performance Metrics server (TCP).
#
# This option is only needed when Performance Metrics server will be enabled.
#-------------------------------------------------------------------------------
PORT_PMSRVR=7813

#-------------------------------------------------------------------------------
# Specify the DataStore type for Performance Metrics server.
# Valid values are: BDB, LMDB
#
# This option is only needed when Performance Metrics server will be enabled.
#-------------------------------------------------------------------------------
PMSRVR_DATASTORE_TYPE=BDB

#-------------------------------------------------------------------------------
# Specify the DataStore home location for Performance Metrics server.
# This is optional and only takes effect when Performance Metrics server will be enabled.
#-------------------------------------------------------------------------------
PMSRVR_DATASTORE_HOME=

#-------------------------------------------------------------------------------
# Specify if Remote Metrics using StatsD protocol will be enabled for the Deployment
# Specify true if Remote Metrics for the deployment will be enabled, false otherwise
#-------------------------------------------------------------------------------
ENABLE_DEPLOYMENT_REMOTE_METRICS=false

#-------------------------------------------------------------------------------
# If Remote Metrics for the deployment will be enabled, specify the listening host
#-------------------------------------------------------------------------------
DEPLOYMENT_REMOTE_METRICS_LISTENING_HOST=

#-------------------------------------------------------------------------------
# If Remote Metrics for the deployment will be enabled, specify the listening port for that server
#-------------------------------------------------------------------------------
DEPLOYMENT_REMOTE_METRICS_LISTENING_PORT=0


###############################################################################
#                                                                             #
#                       SECTION J - REPLICATION OPTIONS                       #
#                                                                             #
###############################################################################

#-------------------------------------------------------------------------------
# Specify the value for the GoldenGate schema.
#-------------------------------------------------------------------------------
OGG_SCHEMA=OGGADMIN


###############################################################################
#                                                                             #
#                  SECTION K - REMOVE DEPLOYMENT OPTIONS                      #
#                                                                             #
###############################################################################

#-------------------------------------------------------------------------------
# Specify if the deployment files should be removed from disk.
# Specify true if the deployment files should be removed, false otherwise.
#-------------------------------------------------------------------------------
REMOVE_DEPLOYMENT_FROM_DISK=

L’article GoldenGate 23ai Installation: Graphic and Silent Mode Comparison for Automation est apparu en premier sur dbi Blog.

A Shift Toward Jakarta EE

The most visible and impactful change in JBoss EAP 8 is the transition from Java EE to Jakarta EE.

• Namespace migration: All javax.* packages are now replaced by jakarta.*.
• This means that even if your application compiles fine on EAP 7, it won’t deploy on EAP 8 without updating imports and dependencies.
• While this migration can sound painful, it’s a necessary step to stay compatible with the modern Java ecosystem and future versions of Jakarta EE.

We can count on the Red Hat’s EAP Migration Toolkit to automatically detect and fix most of the package name changes.

New Java and Platform Support

JBoss EAP 8 officially supports Java 17 and later.
This brings performance, security, and syntax improvements, while dropping support for older Java versions (like Java 8 in many cases).

Other platform updates include:

• Updated Undertow web server version for improved HTTP/2 and security.
• Enhanced datasource and driver management via the CLI and management console.
• Simplified configuration through YAML and CLI scripts, helping automate deployments and tuning.

Updated Subsystems and Architecture Improvements

EAP 8 brings a more modular, streamlined architecture:

• Legacy subsystems deprecated (e.g., older messaging or logging frameworks).
• MicroProfile updates: More APIs for observability, configuration, and fault tolerance.
• Improved clustering and domain mode management, faster startup and better node synchronization.

For administrators, these changes mean fewer manual tweaks and more consistent runtime behavior across environments.

Ready for the Cloud (for Real )

Red Hat has made significant investments to make EAP 8 cloud-native:

• Better support for OpenShift and Kubernetes with optimized container images.
• Smaller footprint and faster startup thanks to tuned modules and lazy loading.
• Compatibility with Red Hat build of Quarkus for microservice migration paths.

In other words, JBoss EAP 8 is no longer just a traditional application server, it’s a hybrid platform that bridges the gap between legacy Java EE workloads and modern cloud architectures.

Security and Compliance Enhancements

Security was a major focus in JBoss EAP 8:

• Integrated Elytron 2 for modern authentication and authorization.
• Stronger TLS configurations by default.
• Simplified credential store management (replacing legacy vault mechanisms).

Administrators will appreciate the more centralized, policy-driven security model.

My Experience & Recommendations

After long time working with both JBoss EAP 7 and JBoss EAP 8, I can say the migration is more about preparation than complexity.
The most common pitfalls I’ve seen include:

• Forgetting the Jakarta namespace migration.
• Using old JDBC drivers or libraries no longer supported.
• Missing dependencies when running in containerized environments.

Our best practice is always to:

• Test the migration in a clean environment.
• Use automation (Ansible or CI/CD pipelines) for consistent builds.
• Validate performance, logging, and metrics integration (especially with Zabbix or Elastic).

Once properly prepared, JBoss EAP 8 runs smoother, faster, and integrates much better with modern infrastructure.

Conclusion

JBoss EAP 8 isn’t just an upgrade, it’s a modernization step.
It pushes Java EE into the Jakarta EE era, embraces cloud-native deployments, and simplifies operations for enterprises.
While the migration from EAP 7 requires careful planning, the long-term benefits in performance, maintainability, and compliance make it well worth the effort.

If you’re planning a JBoss migration, feel free to reach out for guidance or a technical exchange.
Have a look at our JBoss EAP blogs for more insights.

Happy to share,

David

L’article From JBoss EAP 7 to 8: What Really Changed est apparu en premier sur dbi Blog.

With the release of WebLogic 14.1.2, Oracle has introduced significant updates that directly affect stability, security, and modernization. Below is an overview of what’s new and what it means for organizations planning to upgrade.

A Quick Stroll Through WebLogic History

What’s New in WebLogic 14

1. Modern Java Support

WebLogic 14.1.2 now officially supports JDK 17 and JDK 21. This provides access to performance improvements (e.g., G1GC, ZGC) and modern Java language features such as records, sealed classes, and switch expressions.

Impact for organizations:

• Applications gain performance and security improvements.
• Stricter Java module system may expose hidden dependencies.
• Legacy libraries or reflection-based solutions may fail.
• Outdated JDBC drivers and frameworks may require upgrading.

2. Strengthened Security Defaults

Security has been significantly improved in WebLogic 14:

• OpenID Connect support for integration with modern identity providers.
• TLS 1.0 and 1.1 removed; only strong cryptographic protocols are supported.
• Domain-specific demo certificates using PKCS12 keystores by default.

Impact for organizations:

• Easier integration with enterprise authentication and identity management.
• Legacy systems that depend on outdated SSL/TLS protocols will need upgrades.

3. Administration Console Evolution

The traditional WebLogic Admin Console has been retired and replaced with the Remote Console, a lightweight web application that communicates via REST APIs.

Advantages:

• Manage WebLogic securely from anywhere.
• Console can be upgraded independently from the server.

Considerations:

• Administrators must adapt to a new interface.
• Existing procedures, documentation, and training materials will require updates.

4. Migration and Refactoring Tools

Oracle introduced two new tools to assist with upgrades:

• Migration Analysis Tool (MAT): Scans applications and reports compatibility issues.
• OpenRewrite Recipes: Automates some application refactoring tasks.

Considerations:

• These tools provide useful guidance, but results often require expert interpretation.
• Automated refactoring may only cover part of the necessary work.

5. Clustering and Database Enhancements

Enhancements in high availability and database integration include:

• Health-based routing: Routes requests to the healthiest available node.
• Database client modules: Simplify integration in Kubernetes and containerized environments.
• Improved failover and multi-data center support: Reduce complexity in HA deployments.

Impact for organizations:

• More reliable clustering.
• Simplified operations in cloud and hybrid environments.
• Better resilience in multi-DC architectures.

Should You Upgrade?

Short answer: yes. Long answer: yes, but carefully.

Sticking with 12c in 2025 is like still using Internet Explorer – technically possible, but also technically embarrassing. At some point, Oracle’s support matrix will drop you, and then you’re one zero-day away from chaos.

In another world, continuing to run WebLogic 12c in 2025 is increasingly difficult to justify:

• Security vulnerabilities accumulate as older versions leave support.
• Integration with modern Java, Kubernetes, and identity providers becomes more challenging.
• Oracle’s support matrix is moving forward, and legacy environments are becoming costly liabilities.

Final Thoughts

WebLogic 14 is not just an incremental update. It modernizes the platform with stronger security, cloud-native capabilities, and support for the latest Java standards. At the same time, it introduces changes that require careful planning to avoid disruption.

This is where experienced guidance is valuable. With years of WebLogic consulting experience, I support organizations by:

• Auditing WebLogic installation for compatibility issues before migration.
• Planning and executing upgrades with minimal downtime.
• Configuring new security features and administration tools correctly.
• Coaching development and operations teams to adapt to the changes.

If your organization is considering upgrading to WebLogic 14, let’s discuss how to make the transition smooth, secure, and future-proof.

Happy to share,

David

Have a look to all my blogs

L’article WebLogic 14: What’s New and Why It Matters est apparu en premier sur dbi Blog.

Introduction and Symptoms

An important step in the installation process is the Oracle Fusion Middleware Metadata repository creation using the RCU (Repository Creation Utility) which creates the necessary schemas for the components.

But when running the Repository Creation Utility (RCU) to load schemas on Oracle Database, schema creation fails with the below errors:

In fact, the problem is seen as RCU tries to set up VPD stripes. In another world, RCU relies on fine-grained access control (FGAC) to manage schema creation and access within the Oracle database.

The ORA-00439 error “feature not enabled: Fine-grained access control” in Oracle RCU (Repository Creation Utility) indicates that the database being used for RCU schema creation does not have the fine-grained access control feature enabled. This feature is only part of the Enterprise Edition of Oracle Database and is not available in Standard Edition!

Let’s check

So, no way to do it with Standard Edition? No worries, there is a solution

Solution

Oracle here is a patch to workaround this issue, so the steps will be:

• Download the patch
• Apply the patch
• Run the RCU to load the schemas
• Continue with Domain configuration

Download the patch

Go to Patch 37506854 and download it, then move it to your working folder on the server.

Apply the patch

Nothing really special here, apply the patch as any patch

Unzip the patch downloaded, go inside the folder 37506854, and apply the patch:

[oracle@fmwserver working]$ cd 37506854
[oracle@fmwserver 37506854]$ opatch apply
Oracle Interim Patch Installer version 13.9.4.2.17
Copyright (c) 2025, Oracle Corporation.  All rights reserved.


Oracle Home       : /u01/app/oracle/product/midw
Central Inventory : /u01/app/oracle/oraInventory
   from           : /u01/app/oracle/product/midw//oraInst.loc
OPatch version    : 13.9.4.2.17
OUI version       : 13.9.4.0.0
Log file location : /u01/app/oracle/product/midw/cfgtoollogs/opatch/opatch2025-07-10_11-22-38AM_1.log


OPatch detects the Middleware Home as "/u01/app/oracle/product/midw"

Verifying environment and performing prerequisite checks...
OPatch continues with these patches:   37506854

Do you want to proceed? [y|n]
y
User Responded with: Y
All checks passed.

Please shutdown Oracle instances running out of this ORACLE_HOME on the local system.
(Oracle Home = '/u01/app/oracle/product/midw')


Is the local system ready for patching? [y|n]
y
User Responded with: Y
Backing up files...
Applying interim patch '37506854' to OH '/u01/app/oracle/product/midw'

Patching component oracle.rcu.mds, 14.1.2.0.0...

Patching component oracle.rcu.mds, 14.1.2.0.0...
Patch 37506854 successfully applied.
Log file location: /u01/app/oracle/product/midw/cfgtoollogs/opatch/opatch2025-07-10_11-22-38AM_1.log

OPatch succeeded.

Retry the failed step

Now, the RCU should work fine and the domain creation could be done without issue.

Have a look on all FMW blogs, more blogs to come about FMW 14 to highlight new features!

If you have any questions don’t hesitate, please ask

Happy to share,

David

L’article Oracle FMW 14 Installation – ORA-00439: feature not enabled: Fine-grained access control est apparu en premier sur dbi Blog.

As usual, we try to make it so that Documentum and all its components are setup as securely as possible. From a WebServer point of view, that include a bunch of Best Practices that we add into our deployments / custom images (when using containers), and D2 isn’t without rest. One of such things is for example to setup the Tomcat and D2 application to work only with cookies that have the “secure” and “httpOnly” flags. That is done in a few locations, but in recent versions of D2, there is additional parameters to help control this kind of behavior inside the ESAPI.properties file.

Note: there are often confusions about the “httpOnly” flag for cookies, so I think a quick reminder wouldn’t hurt. The “secure” flag means that the cookie can only be sent through HTTPS (except when using localhost), so it’s much harder to get access to it. The “httpOnly” one, contrary to his name, doesn’t mean that the cookie is only for HTTP communications, but it means that it cannot be accessed by client’s scripts like JavaScript. Therefore, sensitive cookies should have both flags, so that they go through the network securely and even when it arrives on the target client’s browser, its access is protected.

Therefore, as a good practice, I went ahead and configured D2 as secure as I could, even before a 1st deployment, and that included these 4 parameters:

[tomcat@d2-0 war_prep]$ grep -B1 -E "ForceHttpOnly|ForceSecure" WEB-INF/classes/ESAPI.properties
# Force flags on cookies, if you use HttpUtilities to set cookies
HttpUtilities.ForceHttpOnlySession=true
HttpUtilities.ForceSecureSession=true
HttpUtilities.ForceHttpOnlyCookies=true
# Whlie doing a cross site access through https make the below flag to true 
HttpUtilities.ForceSecureCookies=true
[tomcat@d2-0 war_prep]$

Once my D2 WAR file was ready and configured, I tried to deploy it on Tomcat. No errors/issues during the deployment/startup of D2. However, accessing the D2 UI ended up with a pretty and infinite loading logo of D2. You probably have all seen that happen at some point:

Nothing on the D2 logs (generated through the logback.xml or log4j2.properties), but on the Tomcat logs, I could see the stack related to that issue when I accessed the URL a few minutes after Tomcat was fully up&running:

2025-07-08 14:25:56,379 UTC INFO [main] org.apache.catalina.startup.HostConfig.deployWAR Deployment of web application archive [$CATALINA_HOME/webapps/D2/D2.war] has finished in [57,704] ms
2025-07-08 14:25:56,382 UTC INFO [main] org.apache.coyote.AbstractProtocol.start Starting ProtocolHandler ["https-jsse-nio-8080"]
2025-07-08 14:25:56,400 UTC INFO [main] org.apache.catalina.startup.Catalina.start Server startup in [57846] milliseconds
2025-07-08 14:29:36,966 UTC SEVERE [https-jsse-nio-8080-exec-42] org.apache.catalina.core.ApplicationContext.log Key[type=com.emc.x3.server.services.labels.RpcLabelServiceImpl, annotation=[none]]: An RpcTokenException was thrown while processing this call.
	com.google.gwt.user.client.rpc.RpcTokenException: Invalid RPC token (Missing XSRF token: not on request, client IP=xxx.xxx.xxx.xxx)
		at com.emc.x3.server.D2XsrfProtectedServiceServlet.validateXsrfToken(D2XsrfProtectedServiceServlet.java:33)
		at com.google.gwt.user.server.rpc.AbstractXsrfProtectedServiceServlet.onAfterRequestDeserialized(AbstractXsrfProtectedServiceServlet.java:66)
		at com.emc.x3.server.GuiceRemoteServiceServlet.processCall(GuiceRemoteServiceServlet.java:120)
		at com.google.gwt.user.server.rpc.RemoteServiceServlet.processPost(RemoteServiceServlet.java:373)
		at com.google.gwt.user.server.rpc.AbstractRemoteServiceServlet.doPost(AbstractRemoteServiceServlet.java:62)
		at jakarta.servlet.http.HttpServlet.service(HttpServlet.java:590)
		at jakarta.servlet.http.HttpServlet.service(HttpServlet.java:658)
		at com.google.inject.servlet.ServletDefinition.doServiceImpl(ServletDefinition.java:290)
		at com.google.inject.servlet.ServletDefinition.doService(ServletDefinition.java:280)
		at com.google.inject.servlet.ServletDefinition.service(ServletDefinition.java:184)
		at com.google.inject.servlet.ManagedServletPipeline.service(ManagedServletPipeline.java:89)
		at com.google.inject.servlet.FilterChainInvocation.doFilter(FilterChainInvocation.java:85)
		at org.apache.shiro.web.servlet.ProxiedFilterChain.doFilter(ProxiedFilterChain.java:61)
		at org.apache.shiro.web.servlet.AdviceFilter.executeChain(AdviceFilter.java:108)
		at com.emc.x3.portal.server.filters.authc.X3OTDSAuthenticationFilter.executeChain(X3OTDSAuthenticationFilter.java:1106)
		at org.apache.shiro.web.servlet.AdviceFilter.doFilterInternal(AdviceFilter.java:137)
		at org.apache.shiro.web.servlet.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:154)
		at org.apache.shiro.web.servlet.ProxiedFilterChain.doFilter(ProxiedFilterChain.java:66)
		at org.apache.shiro.web.servlet.AdviceFilter.executeChain(AdviceFilter.java:108)
		at org.apache.shiro.web.servlet.AdviceFilter.doFilterInternal(AdviceFilter.java:137)
		at org.apache.shiro.web.servlet.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:154)
		at org.apache.shiro.web.servlet.ProxiedFilterChain.doFilter(ProxiedFilterChain.java:66)
		at org.apache.shiro.web.servlet.AbstractShiroFilter.executeChain(AbstractShiroFilter.java:458)
		at org.apache.shiro.web.servlet.AbstractShiroFilter$1.call(AbstractShiroFilter.java:373)
		at org.apache.shiro.subject.support.SubjectCallable.doCall(SubjectCallable.java:90)
		at org.apache.shiro.subject.support.SubjectCallable.call(SubjectCallable.java:83)
		at org.apache.shiro.subject.support.DelegatingSubject.execute(DelegatingSubject.java:387)
		at org.apache.shiro.web.servlet.AbstractShiroFilter.doFilterInternal(AbstractShiroFilter.java:370)
		at org.apache.shiro.web.servlet.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:154)
		at com.google.inject.servlet.FilterChainInvocation.doFilter(FilterChainInvocation.java:82)
		at com.google.inject.servlet.ManagedFilterPipeline.dispatch(ManagedFilterPipeline.java:121)
		at com.google.inject.servlet.GuiceFilter.doFilter(GuiceFilter.java:133)
		at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:164)
		at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:140)
		at com.emc.x3.portal.server.filters.X3SessionTimeoutFilter.doFilter(X3SessionTimeoutFilter.java:52)
		at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:164)
		at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:140)
		at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:167)
		at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:90)
		at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:483)
		at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:115)
		at org.apache.catalina.valves.StuckThreadDetectionValve.invoke(StuckThreadDetectionValve.java:185)
		at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:93)
		at org.apache.catalina.valves.AbstractAccessLogValve.invoke(AbstractAccessLogValve.java:663)
		at org.apache.catalina.valves.RemoteIpValve.invoke(RemoteIpValve.java:731)
		at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:74)
		at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:344)
		at org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:397)
		at org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:63)
		at org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:905)
		at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1741)
		at org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:52)
		at org.apache.tomcat.util.threads.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1190)
		at org.apache.tomcat.util.threads.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:659)
		at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:63)
		at java.base/java.lang.Thread.run(Thread.java:840)

I checked that the XSRF token was indeed generated, and it appeared to be present in the request, at least as shown in the Browser’s Network traces (Developer Tools). It was being generated and forwarded by the browser with both the “secure” and “httpOnly” flags. So, what was the issue then? It took me a bit of time, but I could pinpoint the issue to the ESAPI.properties file and more specifically to the 4 properties I mentioned above, that control the flags of both cookies and sessions. To be exact, I expected the “httpOnly” flag for the cookies to be the issue, since it would hide the XSRF_TOKEN from JavaScript on the client-side. Keeping the content of the WAR file exploded folder the same, I tried to switch this 1 parameter back to false, which is the default value:

[tomcat@d2-0 ~]$ esapi_file="$CATALINA_HOME/webapps/D2/WEB-INF/classes/ESAPI.properties"
[tomcat@d2-0 ~]$
[tomcat@d2-0 ~]$ grep -B1 -E "ForceHttpOnly|ForceSecure" ${esapi_file}
# Force flags on cookies, if you use HttpUtilities to set cookies
HttpUtilities.ForceHttpOnlySession=true
HttpUtilities.ForceSecureSession=true
HttpUtilities.ForceHttpOnlyCookies=true
# Whlie doing a cross site access through https make the below flag to true
HttpUtilities.ForceSecureCookies=true
[tomcat@d2-0 ~]$
[tomcat@d2-0 ~]$ sed -i 's,\(HttpUtilities.ForceHttpOnlyCookies\)=true,\1=false,' ${esapi_file}
[tomcat@d2-0 ~]$
[tomcat@d2-0 ~]$ grep -B1 -E "ForceHttpOnly|ForceSecure" ${esapi_file}
# Force flags on cookies, if you use HttpUtilities to set cookies
HttpUtilities.ForceHttpOnlySession=true
HttpUtilities.ForceSecureSession=true
HttpUtilities.ForceHttpOnlyCookies=false
# Whlie doing a cross site access through https make the below flag to true
HttpUtilities.ForceSecureCookies=true
[tomcat@d2-0 ~]$

After a restart of Tomcat, the issue was completely gone and the login to D2 through the OTDS was working successfully… Since I could deploy D2-REST, D2-Smartview and D2-Config with all 4 ESAPI.properties parameter set to “true“, I asked OT if it was expected that only D2 has a problem with “HttpUtilities.ForceHttpOnlyCookies=true“. After a few days of exchange, I got the feedback that it’s not documented but it’s apparently required for D2 to NOT have the “httpOnly” flag because of the XSRF_TOKEN. They will see to create a KB for that topic (update: it was created and it’s available here: KB0845279). If you really need to have both flags set, then you will not have any other choice than switching to the new UI, D2-Smartview.

L’article Dctm – Invalid/Missing XSRF token on D2 est apparu en premier sur dbi Blog.

When logging in to a Documentum Server, using the “connect” iAPI command, the Repository will verify if the user_login_name exists. If yes, it will send the Authentication request to the JMS, which will contact the OTDS with the details provided. The OTDS will perform the authentication with whatever Identity Provider you configured inside it and return the result to the JMS, which will then confirm the details to the Repository to either allow or deny the login. In this case, it doesn’t matter if the user_source of the dm_user is configured with “LDAP” or “OTDS”. Both will behave in the same way and the request will be sent to the JMS and then the OTDS, that’s the theory at least… That’s working properly for an “indirect” login using the “connect” iAPI command triggered by an already logged in user such as dmadmin. But a “direct” login (DA, dqMan, or direct iAPI with username/password) will fail for an “LDAP” user_source as Documentum will, in this case, try to use the LDAP Auth and then complain that it’s deprecated :)… Might be the subject of another blog.

I. OTDS Synchronization with default configuration

To do some testing or if you are setting-up a freshly installed Documentum Repository (i.e. no previous LDAP integrations), you might want to keep things simple and therefore you would most probably end-up using the default configuration.

The default User Mapping configuration for an OTDS Resource, for Documentum, might be something like:

    Resource Attribute            >> OTDS Attribute          >> Format
    __NAME__                      >> cn                      >> %s
    AccountDisabled               >> ds-pwp-account-disabled >> %s
    client_capability             >>                         >> 0
    create_default_cabinet        >>                         >> F
    user_address                  >> mail                    >> %s
    user_global_unique_id         >> oTObjectGUID            >> %s
    user_login_name               >> oTExternalID3           >> %s
    user_name                     >> cn                      >> %s
    user_privileges               >>                         >> 0
    user_rename_enabled           >>                         >> F
    user_rename_unlock_locked_obj >>                         >> T
    user_type                     >>                         >> dm_user
    user_xprivileges              >>                         >> 0

Please note that the default value for “user_login_name” is “oTExternalID3”. In addition to mapped attributes from the AD / LDAP, OTDS defines some internal attributes that you can use, and this one is one of those. For example, if a cn/sAMAccountName has a value of “MYUSERID”, then you will most probably end-up with something like:

• oTExternalID1 == MYUSERID
• oTExternalID2 == MYUSERID@OTDS-PARTITION-NAME
• oTExternalID3 == MYUSERID@DOMAIN-NAME.COM
• oTExternalID4 == DOMAIN\MYUSERID

Therefore, in this case, with the default configuration, you would need to use “MYUSERID@DOMAIN-NAME.COM” to be able to login to Documentum. Nothing else would work as your dm_user would be synchronized/created/modified to have a user_login_name value of “MYUSERID@DOMAIN-NAME.COM”. As a sidenote, the “%s” in the Format column means to keep the formatting/case from the source attribute. In most AD / LDAP, the cn/sAMAccountName would be in uppercase, so you would only be able to login with the uppercase details. There is a parameter that you can set in the server.ini to be able to have a case-insensitive Repository and another one in the JMS, so you might want to take a look at that for example.

Note: The value of oTExternalID3 can be changed in the Partition > Properties > Extended Functionality page. It is controlled by the value given to the “AD/LDAP attribute” and by default, it should be set to “userPrincipalName” (i.e. MYUSERID@DOMAIN-NAME.COM). However, you can change that value to something else, like “sAMAccountName”, and in this case, oTExternalID3 would end-up with the same value as oTExternalID1.

Here, I’m setting an AD password in an environment variable and then fetching a dm_user details to show you the current content, before triggering a login attempt (using the “connect” iAPI command):

[dmadmin@cs-0 logs]$ read -s -p "  --> Please enter the AD Password: " ad_passwd
  --> Please enter the AD Password:
[dmadmin@cs-0 logs]$
[dmadmin@cs-0 logs]$
[dmadmin@cs-0 logs]$ iapi REPO_NAME -Udmadmin -Pxxx << EOC
> retrieve,c,dm_user where upper(user_login_name) like 'MYUSERID%'
> get,c,l,user_name
> get,c,l,user_login_name
> EOC

        OpenText Documentum iapi - Interactive API interface
        Copyright (c) 2020. OpenText Corporation
        All rights reserved.
        Client Library Release 20.2.0000.0082

Connecting to Server using docbase REPO_NAME
[DM_SESSION_I_SESSION_START]info:  "Session 011234568006fe39 started for user dmadmin."

Connected to OpenText Documentum Server running Release 20.2.00013.0135  Linux64.Oracle
Session id is s0
API> ...
1112345680001d00
API> ...
MYUSERID
API> ...
MYUSERID@DOMAIN-NAME.COM
API> Bye
[dmadmin@cs-0 logs]$
[dmadmin@cs-0 logs]$
[dmadmin@cs-0 logs]$ iapi REPO_NAME -Udmadmin -Pxxx << EOC
> apply,c,NULL,SET_OPTIONS,OPTION,S,trace_authentication,VALUE,B,T
> connect,REPO_NAME,MYUSERID@DOMAIN-NAME.COM,dm_otds_password=${ad_passwd}
> apply,c,NULL,SET_OPTIONS,OPTION,S,trace_authentication,VALUE,B,F
> EOC

        OpenText Documentum iapi - Interactive API interface
        Copyright (c) 2020. OpenText Corporation
        All rights reserved.
        Client Library Release 20.2.0000.0082

Connecting to Server using docbase REPO_NAME
[DM_SESSION_I_SESSION_START]info:  "Session 011234568006fe40 started for user dmadmin."

Connected to OpenText Documentum Server running Release 20.2.00013.0135  Linux64.Oracle
Session id is s0
API> ...
q0
API> ...
s1
API> ...
q0
API> Bye
[dmadmin@cs-0 logs]$

As you can see above, the result of the “connect” command is “s1”, which means the session is opened and Documentum was able to verify through the OTDS that the login is correct. On the JMS, there is an “otdsauth.log” file, that gives you this kind of information (might give a bit more information depending on the Documentum Server version used):

[dmadmin@cs-0 logs]$ cat otdsauth.log
...
2025-01-01 13:37:26,417 UTC DEBUG [root] (default task-6) In com.documentum.cs.otds.OTDSAuthenticationServlet
2025-01-01 13:37:26,780 UTC DEBUG [root] (default task-6) userId: MYUSERID@DOMAIN-NAME.COM
2025-01-01 13:37:26,782 UTC DEBUG [root] (default task-6) Password Auth Success: MYUSERID@DOMAIN-NAME.COM
[dmadmin@cs-0 logs]$

The Repository logs will also show the trace_authentication details and the OTDS will also have a successful authentication attempt in its logs. So, all is well in a perfect world, right?

II. OTDS Synchronization with updated configuration

When working with an existing Repository that was initially setup with LDAP Sync and Auth, you might have a “simple” configuration that defined that the user_login_name would be the cn/sAMAccountName attribute from the Active Directory. In this case, you probably don’t want to change anything after the integration of the OTDS… After all, the OTDS is supposed to simplify the configuration and not complexify it. Therefore, you would setup the OTDS to integrate (Synchronized Partition or Non-Synchronized one) with your AD / LDAP and then create a Resource that would replicate and match the exact details of your existing users. Even on a freshly installed Repository without previous LDAP integration, you might choose to login with “MYUSERID” (or “myuserid”) instead of “MYUSERID@DOMAIN-NAME.COM”. The OTDS will allows you to configure that, so users can be synchronized to Documentum however you want.

To achieve that, you would need to change a bit the User Mapping configuration to keep your previous login information / avoid messing with the existing dm_user details. For example, you might want to change the client_capability, user_login_name, user_name and some other things. Here is an example of configuration that allows you to synchronize the users with the cn/sAMAccountName from your AD / LDAP, in lowercase, please note the changes with a wildcard (*):

    Resource Attribute            >> OTDS Attribute          >> Format
    __NAME__                      >> cn                      >> %l (*)
    AccountDisabled               >> ds-pwp-account-disabled >> %s
    client_capability             >>                         >> 2 (*)
    create_default_cabinet        >>                         >> F
    user_address                  >> mail                    >> %s
    user_global_unique_id         >> oTObjectGUID            >> %s
    user_login_name               >> cn (*)                  >> %l (*)
    user_name                     >> displayName (*)         >> %s
    user_privileges               >>                         >> 0
    user_rename_enabled           >>                         >> T (*)
    user_rename_unlock_locked_obj >>                         >> T
    user_type                     >>                         >> dm_user
    user_xprivileges              >>                         >> 32 (*)

The documentation mention in some places to have the same value for both _NAME_ and for user_name but I’m not sure if that’s really required, as I have some customers with different values, and it works anyway. It’s pretty common for customers to have the same value for cn and sAMAccountName and to store the displayName into, well, the displayName attribute… On Documentum side, some customers will use cn as the user_name, but some others will use displayName instead. The user_name is, after all, a kind of displayName so I don’t really understand why OTDS would require both _NAME_ and user_name to be the same. It should instead rely on the user_login_name, no?

After consolidating the OTDS Resource, you should be able to see the correct user_login_name as it was before (with the LDAP Sync job). What’s the purpose of this blog then? Well, the OTDS allows you to change the mapping as you see fit, so that you can replicate exactly what you used to have with an LDAP Sync. But you cannot login anymore…

After the modification of the OTDS Resource User Mapping and its consolidation, here I’m trying to login again (with “myuserid” instead of “MYUSERID@DOMAIN-NAME.COM”) to show the difference in behavior:

[dmadmin@cs-0 logs]$ iapi REPO_NAME -Udmadmin -Pxxx << EOC
> retrieve,c,dm_user where upper(user_login_name) like 'MYUSERID%'
> get,c,l,user_name
> get,c,l,user_login_name
> EOC

        OpenText Documentum iapi - Interactive API interface
        Copyright (c) 2020. OpenText Corporation
        All rights reserved.
        Client Library Release 20.2.0000.0082

Connecting to Server using docbase REPO_NAME
[DM_SESSION_I_SESSION_START]info:  "Session 011234568006fe48 started for user dmadmin."

Connected to OpenText Documentum Server running Release 20.2.00013.0135  Linux64.Oracle
Session id is s0
API> ...
1112345680001d00
API> ...
LastName (Ext) FirstName
API> ...
myuserid
API> Bye
[dmadmin@cs-0 logs]$
[dmadmin@cs-0 logs]$ iapi REPO_NAME -Udmadmin -Pxxx << EOC
> apply,c,NULL,SET_OPTIONS,OPTION,S,trace_authentication,VALUE,B,T
> connect,REPO_NAME,myuserid,dm_otds_password=${ad_passwd}
> apply,c,NULL,SET_OPTIONS,OPTION,S,trace_authentication,VALUE,B,F
> EOC

        OpenText Documentum iapi - Interactive API interface
        Copyright (c) 2020. OpenText Corporation
        All rights reserved.
        Client Library Release 20.2.0000.0082

Connecting to Server using docbase REPO_NAME
[DM_SESSION_I_SESSION_START]info:  "Session 011234568006fe4f started for user dmadmin."

Connected to OpenText Documentum Server running Release 20.2.00013.0135  Linux64.Oracle
Session id is s0
API> ...
q0
API> ...
[DM_SESSION_E_AUTH_FAIL]error:  "Authentication failed for user myuserid with docbase REPO_NAME."


API> ...
q1
API> Bye
[dmadmin@cs-0 logs]$

This time the authentication fails. If you look at the Repository logs, you can see the user is detected properly, and the Repository start the authentication with the OTDS (1st line below). But when the result comes back (2nd and 3rd lines below), it says that it failed:

2025-01-01T13:46:16.446426      188808[188808]  011234568006fe50        [AUTH]  Start-AuthenticateUserByOTDSPassword:UserLoginName(myuserid)
2025-01-01T13:46:16.815111      188808[188808]  011234568006fe50        [AUTH]  otds_password_authentication = false:
2025-01-01T13:46:16.815159      188808[188808]  011234568006fe50        [AUTH]  End-AuthenticateUserByOTDSPassword: 0
2025-01-01T13:46:17.174676      188808[188808]  011234568006fe50        [AUTH]  Final Auth Result=F, LOGON_NAME=myuserid, ...

The JMS otdsauth.log file will have a similar content, it will start the OTDS communications (1st line below) but the result returned (2nd line below) is not the user_login_name of Documentum. Instead, it’s the value of oTExternalID3 and then the JMS says that it failed (3rd line below):

2025-01-01 13:46:16,671 UTC DEBUG [root] (default task-6) In com.documentum.cs.otds.OTDSAuthenticationServlet
2025-01-01 13:46:16,813 UTC DEBUG [root] (default task-6) userId: MYUSERID@DOMAIN-NAME.COM
2025-01-01 13:46:16,814 UTC DEBUG [root] (default task-6) Password Auth Failed: myuserid

On the OTDS side, no problems, the authentication was successful when it was received (in the directory-access.log):

2025-01-01 13:46:16.777|INFO  ||0|0|Authentication Service|Success Access|27,Initial authentication successful|172.0.0.10|""|OTDS-PARTITION-NAME|"MYUSERID@DOMAIN-NAME.COM"|"Authentication success: MYUSERID@DOMAIN-NAME.COM using authentication handler OTDS-PARTITION-NAME for resource __OTDS_AS__"

If you look at the exact timestamp of the messages, you see the exact flow of how things went. In short, the OTDS says that it’s OK and it sends back some information to the JMS. But because the information returned is oTExternalID3, there is a mismatch with the value of the user_login_name and the JMS/Repository then concludes that the authentication failed, which isn’t true…

Therefore, using any user_login_name value other than oTExternalID3 isn’t a problem from a synchronization point of view, but you still cannot login anyway.

III. Workaround

As mentioned in the introduction of this blog, there is a workaround, which is to set the parameter “synced_user_login_name=sAMAccountName” in the otdsauth.properties file that configures how the JMS talks to the OTDS (another workaround might be to change the value of “AD/LDAP attribute” in the Partition as mentioned earlier in this blog, but that will apply to the full OTDS configuration and not just for this repository). I looked at all the OTDS and Documentum documentations, for several versions, as well as KBs, but I couldn’t find this workaround mentioned anywhere. Maybe I’m the one that doesn’t know how to search (don’t blame the search from OT Support website :D). The one and only reference to this parameter is in the Documentum Server Admin & Config doc, but it tells you that it’s optional and it’s only for OTDS token-based authentication. Here, we are doing a password-based auth, we don’t have any OTDS oAuth Client ID/Secret, so this section shouldn’t be required at all. You don’t need the other parameters from this section, but you DO need “synced_user_login_name”, if you would like to login with the cn/sAMAccountName/oTExternalID1/oTSAMAccountName parameter.

However, there is an additional catch… The parameter was apparently only introduced in 20.3. For any older Documentum Server, you will need to check with OT if they have a fix available. I know there is one for 20.2, but it’s only for Windows (c.f. here). Now, you know that you can also use this parameter for that purpose.

L’article Documentum – Login through OTDS without oTExternalID3 est apparu en premier sur dbi Blog.