Monday, May 11, 2020

How to clear WebSphere tmp files

 It is better to always remove temp and wstemp when there is any update with application or re-deploy the application . But safer to take backup of the complete profile before making any deletion .

profile_root//temp and profile_root//wstemp these are the location of the temporary files in Websphere Application server .

WebSphere Application Server uses multiple temporary locations for many reasons. This post explains the most commonly used temporary files, why they are used and when they can be removed. This blog will also explain the files and directories that can be removed under the profile direction with caution.

Important:

  • Be careful in deleting any temporary, cache and log files in WebSphere Application Server!
     
  • Before making any changes to the environment , take a backup of the profile. It can be a tape backup, using the backupconfig tool, or using the manageprofile -backupProfile option.

    profile_root example: C:/WebSphere/AppServer/profiles/profile_name
    install_root example: C:/WebSphere/Appserver

Let's describe the different files and their locations:

  • profile_root/wstemp
    Usage: wstemp is a workspace temporary directory. Any changes that you make to the configuration are stored in the wstemp directory temporarily. For example, if you are changing the heap size for an application server, the change is stored in the wstemp location until you save the changes. The concept is same for any administrative client, such as the Integrated solution console, wsadmin or JMX, that you use to make the changes.

    Caution: The WebSphere Application Server administrative console stores a preferences.xml file in install_root/wstemp/<workspace_id>. This file contains user preferences on administrative console layout and actions. It is created when you log onto the administrative console. If you remove this file, you lose the user preferences; however,  the preferences can be created again the next time you log onto the administrative console.

    Do not delete the wstemp files when the server is running (especially deployment manager or node agent servers). This approach can cause unexpected results. Also, do not delete the files when you are unsure about the changes that you made to the configuration. Save any pending changes, stop the deployment manager or node agent, which depends on whether you are removing the dmgr wstemp or node wstemp, and then delete the wstemp files.

    Why remove these files?: Files in the profile_root/wstemp directory can be removed. Restart the server process after removal. Because the directory is  used by multiple clients, some times you might see multiple files and subdirectories left behind in this directory. For example, when you use the ConfigService MBean to make changes to configuration and you do not discard the session in the code, this directory will never get deleted. Another reason is corruption in the workspace. Corruption can happen when multiple users make changes to the same configuration at the same time.
     
  • profile_root/temp
    Usage: The temp directory is used by multiple WebSphere components. Two good examples are compiled Java ServerPages (JSP) files and web service cache files. Compiled JSP class files (servlets) are stored in this location. The directory might get regenerated when you invoke the JSP again. However, you might experience a performance issue when you invoke the JSP for the very first time after the JSP compiled files have been removed.

    Caution:  Be cautious if you have a web services application deployed on the node. The wscache.xml is generated during the deployment process and stored under the temp directory. You have to redeploy the web service application to generate the wscache.xml again. You may experience some performance issue with large and complicate webservices application

    Why remove these files?: Corrupted JSP files or any non-root permission issues might cause the server start up issue.

Never delete any other files or directories for WebSphere Application Server unless otherwise directed by the IBM Support team.

Clear Weblogic temp/cache files

It is better to always remove tmp and cache when there is any update with application or re-deploy the application . But safer to take backup of the complete directory before making any deletion .

Recently when working with new application update I found that just bouncing/ restarting server is not enough, we will also need to clean up the cache so that new changes take effect. We will see how to clean temporary directories in Weblogic .

Find out the Domain directory under which our Managed instance folder's exist . Some customised Weblogic domain existing on a different location .If you dont know the location then on the Weblogic installation location find domain_registry.xml file . In this file you can see the list of Domain's created and it's paths .

Each managed server have its own tmp and cache directory .

--> Shut down Server.

--> Delete the contents of the folder ORACLE_HOME/user_projects/domains/your_domain/servers/your_server/tmp…

You can also delete ORACLE_HOME/user_projects/domains/your_domain/servers/your_server/cache

-->Restart Server.

You can also do something like this . In your startup script you can add delete statements so that every time the server restarted new tmp and cache will be re-created .

Note: Do not delete any other directories under the server . If you deleted then restoration is difficult and lead to startup issues .

Thursday, May 7, 2020

Add Ciphers and Protocols in Apache httpd server

 

Add listed Ciphers using SSLCipherSuite directive in Apache HTTPD inside SSL virtual host as below :

~~~~~~~

SSLProtocol all -SSLv3 -TLSv1 -TLSv1.1<br>

SSLCipherSuite ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256

~~~~~~~

- SSL 3.0 and TLS 1.0 are susceptible to known attacks on the protocol; they are disabled entirely.

- Disabling TLS 1.1 is (as of August 2016) mostly optional; TLS 1.2 provides stronger encryption options, but 1.1 is not yet known to be broken. Disabling 1.1 may mitigate attacks against some broken TLS implementations.


In addition, you can use SSL server which accepts strong encryption only by adding following directives too 

~~~~~~~

SSLHonorCipherOrder on

SSLCompression      off

SSLSessionTickets   off

~~~~~~~

- Enabling SSLHonorCipherOrder ensures that the server's cipher preferences are followed instead of the client's.

- Disabling SSLCompression prevents TLS compression oracle attacks (e.g. CRIME).

- Disabling SSLSessionTickets ensures Perfect Forward Secrecy is not compromised if the server is not restarted regularly.


More details about the SSL directives can be found in <a href="https://httpd.apache.org/docs/2.4/mod/mod_ssl.html">ApacheModSSL</a>

Sunday, May 3, 2020

How to reset Weblogic Security

 There will a situation that the admin account is locked or no back up id to unlock or reset the admin id or completely forget the password then we may need to reset Weblogic Admin security.

WindowsLinux/AIX/Solaris
Assuming Domain path : cd D:\ABC\ABCDomain\Assuming Domain path : /u01/ABC/ABCDomain/bin
cd D:\ABC\ABCDomain\bin and run below commandcd /u01/ABC/ABCDomain/bin and run below command
setDomainEnv.cmd. ./setDomainEnv.cmd [ dot then space ]
cd D:\ABC\ABCDomain\security\cd /u01/ABC/ABCDomain/security
move DefaultAuthenticatorInit.ldift [ Rename the file ]mv DefaultAuthenticatorInit.ldift DefaultAuthenticatorInit.ldift_old
java weblogic.security.utils.AdminAccount weblogic welcome1 .java weblogic.security.utils.AdminAccount weblogic welcome1 .
cd D:\ABC\ABCDomain\servers\AdminServer\security\cd /u01/ABC/ABCDomain/servers/AdminServer/security
Move boot.properties and create new boot.properties with below username and passwordMove boot.properties and create new boot.properties with below username and password
username=weblogic
password=welcome1
username=weblogic
password=welcome1
got to D:\ABC\ABCDomain
move servers\AdminServer\data\ldap servers\AdminServer\data\ldap_bkp
go to /u01/ABC/ABCDomain/
mv servers/AdminServer/data/ldap servers/AdminServer/data/ldap_old
Now restart the Admin server and verify logs and Admin login with new credentials.. it will create fresh ldap directory .Now restart the Admin server and verify logs and Admin login with new credentials.. it will create fresh ldap directory .
Once AdminServer is started successfully you can see the boot.properties file userid and password is encryptedOnce AdminServer is started successfully you can see the boot.properties file userid and password is encrypted
copy boot.protperites file to all the other managed server's under this domain and restartcopy boot.protperites file to all the other managed server's under this domain and restart
Good Luck!!!Good Luck!!!

If there are any local additional id's created before just recreate them all the local id's are lost due to resetting of admin security.

Featured

Weblogic Domain Migration

 In this blog we will see domain re-configuration which will be done as part of Weblogic migration from lower version to higher version [ Ex...