1. What
is SerailzedSystemIni.dat file? – key to Weblogic’s Security
The SerializedSystemIni.dat file is a critical
part of every WebLogic domain and if not administered properly, could result in
your servers not starting and you having to recreate the entire domain. So, a
good understanding of this file is important.
What is it?
SerializedSystemIni.dat is a WebLogic domain
file which contains hashes.
Currently, these hashes use Triple-DES block ciphers (that’s why the encrypted passwords begin with
“{3DES}”). SerializedSystemIni.dat is located in the domain directory (WebLogic
Server 8.1 and earlier) or in domain/security directory (WebLogic Server 9.x
and later).
When and how is it
created?
The SerializedSystemIni.dat is created during
the creation of a WebLogic domain. The hashes in the file are created using an
algorithm that binds the file to the domain in which it has been created. So, a
SerializedSystemIni.dat file can be used only within the domain in which it has
been created (cannot be used in other WebLogic domains). Also, in WebLogic
Server versions 8.1 SP6 and earlier, the SerializedSystemIni.dat file (along
with msi-config.xml and fileRealm.properties files) is replicated into a
managed server’s root directory every 5 minutes for managed servers which have MSI File Replication enabled. These files are replicated even
if the admin and managed servers share the same server root directory (doesn’t
make sense to me).
What is it used for?
SerializedSystemIni.dat is used for
encryption/decryption of plain-text/ciphertext within a WebLogic domain.
Gotchas!
- If SerializedSystemIni.dat is corrupted (modified) or
missing, then the WebLogic Servers in your domain will not start and you
will have to reconfigure the domain.
- If MSI File Replication is enabled for your managed
servers in domains running on WebLogic server versions 8.1 SP6 or earlier,
then a bug in the 5-minute replication could cause corruption of
SerializedSystemIni.dat occasionally during server restart and will make
it a zero-byte file if the disk drive or mountpoint in which the WebLogic
domain is located is 100% full.
- If SerializedSystemIni.dat is transferred to its domain
in ascii mode (for example, from a configuration management system) , the
file could become corrupted.
Best Practices
- Ensure that you have a working backup of
SerializedSystemIni.dat. i.e. test the recovery of SerializedSystemIni.dat
and server start-up using the backup copy.
- If you’re using WebLogic Server versions 8.1 SP6 or
earlier and have MSI File Replication enabled, then ensure you contact
Oracle, obtain and deploy patch CR260218 (Guardian Signature
Patterns Release 1.1.34 and Signature ID 000168) to fix the bug in
replication that corrupts SerializedSystemIni.dat or makes it a zero-byte
file.
If you require to transfer SerializedSystemIni.dat to its domain via
FTP, always use binary mode for the file transfer.
2. What is a clustering? How do
weblogic instances communicate in a clustered environment? In a cluster, if one
of the servers has issues and is not accessible, will the other servers know about
it? And how?
1.) A WLS cluster consists a group of server instances that work together and look like a single instance to the client. Cluster provides increased scalability, high availability, load balancing, reliability etc. Through multicast addresses all the WLserver will communicate through Heart Beat. For ever few sec the WLS instances will release their heart beats and if any of the server instances does not release the heart beat then that server in unavailable. And the stub also refreshes its list very periodically so that it can know the available server instances.
2.) Yes, the other server will know through Heart Beats.
The capacity of an application deployed on a
WebLogic Server cluster can be increased dynamically to meet demand. You can
add server instances to a cluster without interruption of service—the
application continues to run without impact to clients and end users.
In a WebLogic Server cluster, application
processing can continue when a server instance fails. You “cluster” application
components by deploying them on multiple server instances in the cluster—so, if
a server instance on which a component is running fails, another server
instance on which that component is deployed can continue application processing.
