Wednesday, September 11, 2019

INSTALLING WEBLOGIC 10.3.6 SERVER 

In this post, we are going to look into how to install WebLogic Server in Redhat or Oracle Linux 



[ i ] Start the WebLogic Installer. If you are using 64 bit, download the generic installer and use the -d64 as the option to install in 64-bit format. The command will be like below:

Syntax:  $JAVA_HOME/bin/java -d64 -Xmx1024m -jar <Weblogic Installer>

[oracle@oracleapp1 Downloads]$ $JAVA_HOME/bin/java -d64    -Xmx1024m   -jar wls1036_generic.jar
Extracting 0%....................................................................................................100%


[ii] Choose the middle-ware home where the WebLogic binaries will be installed


[iii] Choose the custom install to choose the components which will be installed with the WebLogic


[iv] Choose the components by selecting the checkboxes[this component can be chosen according to the business requirements ]


[v] Choose the correct JDK or Jrocket according to the WebLogic version.

[vi] Choose the location to install the WebLogic server binaries and coherence server binaries


[vii] Summary


[viii] once the installation is completed click done , next step is to create a domain in WebLogic server 






Thursday, June 6, 2019

LDAP: error code 49 - Password Policy Error :9000: GSL_PWDEXPIRED_EXCP :Your Password has expired. Please contact the Administrator to change your password

Resolving LDAP Error Code 49: Password Expired for Fusion Applications

If you're managing Oracle Fusion Applications and encounter the following error in your managed server logs or during an LDAP bind operation, this post walks you through the root cause and resolution using Oracle Directory Services Manager (ODSM).

Root Cause

This error typically indicates that the LDAP user's password has expired due to the defined password policy. In the case of Oracle Fusion Applications, users like PolicyRWUser must remain active for integration and application processes to function properly


[oracle@fahmid bin]$ ldapbind -D cn=PolicyRWUser,cn=Users,dc=oasiserp,dc=com -w password-h fahmid.domainname.com -p 389

ldap_bind: Invalid credentials
ldap_bind: additional info: Password Policy Error :9000: GSL_PWDEXPIRED_EXCP :Your Password has expired. Please contact the Administrator to change your password.

[oracle@fahmid bin]$


Resolution via ODSM (Oracle Directory Services Manager)

Step 1: Log in to ODSM

  • Open Oracle Directory Services Manager (usually accessed via WebLogic or OID interface).

  • Navigate to the correct LDAP realm where the user resides (e.g., dc=oasiserp,dc=com).

Step 2: Search for the User

  • Use the Data Browser tab.

  • Expand the Users container.

  • Search for the user account (e.g., PolicyRWUser).

Step 3: Modify Password Policy or Reset Password

You have two options:

Option 1: Reset the User’s Password

  1. Go to the Attributes tab.

  2. Scroll to userPassword.

  3. Click the green plus icon to reset the password.

  4. Click Apply.

This will re-enable the account for use.

 Option 2: Update the Password Policy

If the account is a service or integration account and shouldn’t expire:

  1. Navigate to the Password Policy Configuration under the domain node.

  2. Set the policy to disable password expiration or extend the duration.

  3. Apply the changes and restart the necessary services if needed.


After resetting the password or updating the policy:


[oracle@fahmid bin]$ ldapbind -D cn=PolicyRWUser,cn=Users,dc=oasiserp,dc=com -w password-h fahmid.domainname.com -p 389
bind successful
[oracle@fahmid bin]$


Conclusion

The LDAP error code 49 with GSL_PWDEXPIRED_EXCP is a common occurrence when a password policy triggers expiration. For Fusion Applications, service accounts like PolicyRWUser must always remain active. By resetting the password or adjusting the policy in ODSM, you can quickly restore functionality.

Pro Tip: Always monitor key integration accounts and consider excluding them from expiration policies if they’re used in automated processes.


Friday, January 4, 2019

ORA-29278 SMTP Error – When Oracle Says Service Not Available

If you’ve ever tried sending emails from an Oracle database using UTL_SMTP, you’ve probably seen some cryptic errors pop up when something's not quite right.

We had encountered a classic:

ORA-29278: SMTP transient error: 421 Service not available
ORA-06512: at "SYS.UTL_SMTP", line 57
ORA-06512: at "SYS.UTL_SMTP", line 140
ORA-06512: at "SYS.UTL_SMTP", line 633
ORA-06512: at line 1
ORA-24247: network access denied by access control list (ACL)

Error: ORA-29278: SMTP transient error: 421 Service not available ORA-06512: at "SYS.UTL_SMTP", line 57 ORA-06512: at "SYS.UTL_SMTP", line 140 ORA-06512: at "SYS.UTL_SMTP", line 633 ORA-06512: at line 1 ORA-24247: network access denied by access control list (ACL).Possible cause: Please check your Alert settings. If the problem persists, contact Integra Support

 Step by step — until the alert email finally came through 

Issue:

The root cause was a network ACL (Access Control List) restriction. Since Oracle 11g, network operations from the database require explicit permissions via ACLs.

In this case:

  • Oracle couldn't reach the SMTP server at <Ip address>:25

  • The database user AMHOME lacked proper ACL permissions

Creating and Assigning ACLs for the Particular Database user 

Here’s the complete setup we executed to resolve the issue:

Step 1 Create ACL

BEGIN
  DBMS_NETWORK_ACL_ADMIN.CREATE_ACL
         (acl                =>  'ccgmail.xml',
          description   =>  'CCGMAIL',
          principal        =>  'AMHOME',
          is_grant          =>  true,
          privilege        =>  'connect');  -- for connect 

  DBMS_NETWORK_ACL_ADMIN.ADD_PRIVILEGE
           (acl              =>  'ccgmail.xml',
            Principal   =>  'AMHOME',
            is_grant     =>  true,
            privilege    =>  'resolve'); -- for resolve 

  DBMS_NETWORK_ACL_ADMIN.ASSIGN_ACL
            (acl                =>  'ccgmail.xml',
             host              =>  '<Ip address>',  
     lower_port   =>   25);
END;

Step 2 Add Privileges

We granted both connect and resolve privileges to allow outbound connections and DNS resolution:

BEGIN
  DBMS_NETWORK_ACL_ADMIN.ADD_PRIVILEGE
   ( acl             =>  'ccgmail.xml',
     principal       =>  'AMHOME',
     is_grant        =>   TRUE,
     privilege       =>  'connect');
END;

commit;

BEGIN
  DBMS_NETWORK_ACL_ADMIN.ADD_PRIVILEGE
           (acl               =>  'ccgmail.xml',
            Principal   =>  'AMHOME',
            is_grant      =>   true,
            privilege     =>  'resolve');
END;
commit;

Step 3  Assign ACL to the SMTP Host and Port

BEGIN
  DBMS_NETWORK_ACL_ADMIN.ASSIGN_ACL
        (acl                 =>  'ccgmail.xml',
         Host             =>  '192.168.80.16',
         lower_port =>   '25');
END;
commit;

 Note: Be sure to commit after each block to save changes.

Verify ACLs

To confirm everything was in place: SELECT * FROM dba_network_acls;

 select * from dba_network_acls;

SMTP server domain:  192.168.80.16Port:  25

This showed our ccgmail.xml properly linked to the host and port.

Once all ACLs were in place, we tested sending an email using Oracle’s alert system:

From:  palaneandavar@domainname.aeTo:  palaneandavar@domainname.ae             
Subject:  Integra: Alerts Test                
Status  Your test email has been sent successfully to palaneandavar@domainname.ae
  • SMTP server: 192.168.80.16

  • Port: 25

  • From/To: palaneandavar@domainname.ae

Result:

Status: Your test email has been sent successfully to palaneandavar@domainname.ae

 Pro Tips

  • ACL entries are case-sensitive for the principal (user/schema) name.

  • Don’t forget to grant both connect and resolve privileges — missing one can cause silent failures.

  • Always commit after changes to ACLs.

  • If your SMTP server is external or behind a firewall, ensure it's reachable from the DB host.

  •  Still Getting ORA-29278?

If the error persists even after ACL configuration:

  • Double-check SMTP availability from the server itself using telnet <host> 25

  • Confirm no firewall rules are blocking the port

  • Make sure Oracle Listener or Network Services are not imposing restrictions

Wrapping Up

What looked like an intimidating ORA error turned out to be a straightforward ACL misconfiguration. With a few precise PL/SQL blocks and a bit of patience, we were back to sending alert emails like clockwork.

Lesson learned: Oracle doesn’t just trust anyone to send emails — you have to earn it with the right ACLs!

Have a similar use case with different ports or external domains? Drop a comment or reach out — happy to help fine-tune your setup.

Till next time, keep those emails flowing and the errors at bay.