Hope Its A Happy Birthday
March 7th, 2025, posted in DAtEs iN a YeAREnable SSH Root Login In Solaris 11
February 11th, 2025, posted in SolarisHow to enable SSH Root Login In Solaris 11
Permit SSH Login for Root in Oracle Solaris 11
Open Terminal window and switch to root user.
1. Change the file /etc/ssh/sshd_config PermitRootLogin yes with PermitRootLogin no and save file.
vi /etc/ssh/sshd_config
PermitRootLogin yes2. Comment out the “CONSOLE=/dev/console” line in /etc/default/login.
vi /etc/default/login
#CONSOLE=/dev/console3.Remove “;type=role” from the root entry in /etc/user_attr or use the below command.
rolemod -K type=normal root4. Restart the Services.
#svcadm restart svc:/network/ssh:default5. Try SSH connection using root user You should be able to connect.
Failure of Web Server bridge: No backend server available for connection: timed out after 10 seconds or idempotent set to OFF or method not idempotent.
February 2nd, 2025, posted in Oracle EBS ApplicationEBS Forms in our financial applications suddenly does not work. The message on the webpage is
Failure of Web Server bridge:
No backend server available for connection: timed out after 10 seconds or idempotent set to OFF or method not idempotent.
The error message does not tell the true problem. When checking into services on OS level, I saw Oracle EBS Forms service was not running and also saw errors from startup script $ADMIN_SCRIPTS_HOME/adstrtal.sh:
Forms service failed to start.
The Node Manager is already up.
ERROR: Unable to start up the managed server forms_server1
Server specific logs are located at $EBS_DOMAIN_HOME/servers/forms_server1/logs
05/13/24-20:56:26 :: admanagedsrvctl.sh: exiting with status 1
Java error exists in Forms log file $EBS_DOMAIN_HOME/servers/forms_server1/logs/forms_server1.out
<May 13, 2024 8:56:25 PM EDT> <Emergency> <Store> <BEA-280060> <The persistent store "_WLS_forms_server1" encountered a fatal error, and it must be shut down: weblogic.store.PersistentStoreFatalException: [Store:280020]There was an error while reading from the log file
weblogic.store.PersistentStoreFatalException: [Store:280020]There was an error while reading from the log file
at weblogic.store.io.file.FileStoreIO.open(FileStoreIO.java:128)
at weblogic.store.internal.PersistentStoreImpl.recoverStoreConnections(PersistentStoreImpl.java:435)
at weblogic.store.internal.PersistentStoreImpl.open(PersistentStoreImpl.java:423)
at weblogic.store.admin.AdminHandler.activate(AdminHandler.java:126)
at weblogic.store.admin.FileAdminHandler.activate(FileAdminHandler.java:207)
Truncated.
Caused By: java.io.EOFException: premature EOF: expected=512, actual=126
at weblogic.store.io.file.StoreFile.readBulk(StoreFile.java:316)
at weblogic.store.io.file.Heap.readStoreFile(Heap.java:1142)
at weblogic.store.io.file.Heap.getNextRecoveryFile(Heap.java:1226)
at weblogic.store.io.file.Heap.open(Heap.java:373)
at weblogic.store.io.file.FileStoreIO.open(FileStoreIO.java:117)
Truncated.
Seems WebLogic failed to open a file, but the log did not say which file. I knew that Linux Admins just did server maintenance and rebooted server after they applied monthly patches and Security updates on OS level. That was the only change in the application environment recently.
After searching around, I found the Java errors match the description in Oracle Doc ID 3017110.1 ( Managed Forms Server Fails To Start - Displaying Message: FAILED_NOT_RESTARTABLE - ERROR: The persistent store "_WLS_forms_server1" could not be deployed: weblogic.store.PersistentStoreFatalException [Store:280020] ).The document points out the problem is caused by CrowdStrike, which locks a Forms file in $EBS_DOMAIN_HOME/servers/forms_server#/data/store/default.
CrowdStrike is installed in /opt/CrowdStrike. It is owned by root, and it is running constantly on the Linux server.
$ ps -ef | grep falcon-sensor
root 1081 1079 0 May13 ? 00:22:23 falcon-sensor
1. Delete/rename below .DAT file (I guess CrowdStrike does not like the file name and so locks it)
$ cd $EBS_DOMAIN_HOME/servers/forms_server1/data/store/default
$ ls -altr
total 1028
drwxr-xr-x 4 user group 40 Sep 13 2023 ..
-rw-r--r-- 1 user group 1049088 May 13 20:51 _WLS_FORMS_SERVER1000000.DAT
drwxr-xr-x 2 user group 42 May 13 20:56 .
$ rm _WLS_FORMS_SERVER1000000.DAT
2. Re-start services cleanly by
$ADMIN_SCRIPTS_HOME/adstrtal.sh
Or
$ADMIN_SCRIPTS_HOME/admanagedsrvctl.sh start forms_server1
The permanent fix is that the Secure team rolls back the CrowdStrike change (and applies it again until CrowdStrike fixes the problem), because its new update touches an Oracle Forms data file wrongly during its scan.
Steps To Run Gather Statistics For A Schema In R12.1.3
January 15th, 2025, posted in Oracle EBS Application1. Log on to Oracle Applications with
Responsibility = System Administrator2. Submit Request Window
Navigate to: Concurrent > Requests3. Query for the Gather Schema Statistics4. Enter the appropriate parameters. This can be run for specific schemas by specifying the schema name or entering ‘ALL’ to gather statistics for every schema in the database5. Submit the Gather Schema Statistics programParameters :
Schema Name:
Schema for which statistics are to be gathered. Specify ALL for all Oracle Applications schemas
Percent:
The sampling percentage. If left blank, the default value of 10 is used. The valid range is from 0 to 100
Degree:
The degree of parallelism to be used for gathering statistics. If a Degree is not provided, it defaults to the minimum of parallel_max_servers and cpu_count.
Backup Flag: NO BACKUP is used,
then the GATHER_SCHEMA_STATS procedure will not backup the current statistics. This way the GATHER_SCHEMA_STATS procedure will run faster.
Restart Request ID:
In the case where the Gather Schema Statistics run fails due to whatever reasons, the concurrent request can be re-submitted and it will pick up where the failed run left off, if you provide the concurrent request_id of the failed run.
History Mode: Last Run – History records for each object are maintained only for the last gather statistics run. Each subsequent run will overwrite the previous history record for the object. This is the default behavior
Gather Options:
GATHER: All tables and indexes of the schema schema name are selected for stats gathering. This is the default
Gather Options This parameter specifies how objects are selected for statistics gathering.
GATHER : All tables and indexes of the schema schemaname are selected for stats gathering. This is the default.
GATHER AUTO : Tables of the schema schemaname for which the percentage of modifications has exceeded modpercent are selected for statistics gathering.
Indexes of these tables are selected by default. Table monitoring needs to be enabled before using this option.
GATHER EMPTY : Statistics are gathered only for tables and indexes that are missing statistics.
LIST AUTO : This option does not gather statistics. It only provides a listing of all the tables that will be selected for statistic gathering,
if the GATHER AUTO option is used.
LIST EMPTY : This option does not gather statistics. It only provides a listing of all the tables that will be selected for statistics gathering,
if the GATHER EMPTY option is used.
Modifications Threshold: Applicable only to GATHER AUTO and LIST AUTO Options
Invalidate Dependent Cursors: This flag indicates whether cursors dependent on the table being analyzed should be invalidated or not. By default, dependent cursors are invalidated.
