Starting WebLogic managed server from command line

This is any easy one, but I always forget the syntax and have to look in one of my scripts…

To start a WebLogic managed server from the command line, in the domain bin directory – on the physical server where the managed server resides – do:

nohup ./startManagedWebLogic.sh <managed_server_name> t3://<admin_server>:<admin_port> &

 

Default WebLogic KeyStore Password/PassPhrase

WebLogic comes with default keystores for client and server security enabled.  However, I have found it problematic to find and remember the passwords/passphrases for the default keystores.

Property

Value

Trust store location

%ORACLE_HOME%/weblogic/wlserver_10.3/ server/lib/DemoTrust.jks

Trust store password

DemoTrustKeyStorePassPhrase

Key store location

%ORACLE_HOME%/weblogic/wlserver_10.3/ server/lib/DemoIdentity.jks

Key store password

DemoIdentityKeyStorePassPhrase

Private key password

DemoIdentityPassPhrase

Property

Value

Trust store location

%ORACLE_HOME%/weblogic/wlserver_10.3/ server/lib/DemoTrust.jks

Trust store password

DemoTrustKeyStorePassPhrase

Key store location

%ORACLE_HOME%/weblogic/wlserver_10.3/ server/lib/DemoIdentity.jks

Key store password

DemoIdentityKeyStorePassPhrase

Private key password

DemoIdentityPassPhrase

Installing CA certificates

Instructions on how to add CA certificates into a SSLCACertificateFile from Trustis.com.

Installing CA certificates

On startup, Stronghold loads CA certificates from the file specified by the SSLCACertificateFile entry in its ‘httpd.conf’ file.
To install the PEM format bundled CA certificate file, reference it in the httpd.conf file. as follows

  • Ensure that you have saved the PEM format bundled CA certificate as a text file.
  • Open your ‘httpd.conf’ file and find the SSLCACertificateFile entry.  By default the entry will be SSLCACertificateFile=’/ssl/CA/client-rootcerts.pem’.  You will find ‘httpd.conf’ in the directory /conf.
  • Open the file identified by SSLCACertificateFile (for example, /ssl/CA/client-rootcerts.pem) in a text editor.
  • Open the file that contains the PEM format bundled CA certificates (e.g. cachainpem.txt) in a text editor.
  • Copy the contents of this PEM format bundled CA certificate file
    (including all the ‘—–BEGIN CERTIFICATE—–‘ and ‘—–END CERTIFICATE—–‘ lines)
    to the clipboard.
  • Now Paste what you have just copied into the file identified by SSLCACertificateFile.
    In most cases you will want to insert the bundle CA certificate at the end of the file and add a comment to identify the certificate.
  • Save the modified file and close the text editor.
  • Restart your web server.

Reset the WebLogic admin password

I have been configuring WebLogic domains (version 9.2) and came across the situation where I had made a mistake in entering the initial weblogic user password.  This was preventing me from starting up my weblogic instance, as I couldn’t get the password right.  To reset the password, do the following (courtesy of JavaRanch):

Change directory into your domain directory.

Create a new boot.properties file with the contents:

username=weblogic

password=weblogic

Run the reset command for the admin account (the period at the end is required… you may have to include the full path to the jvm and to to the weblogic.jar):

java -cp weblogic.jar weblogic.security.utils.AdminAccount weblogic weblogic .

Move the ldap directory to ldap.old (this directory is at <domain>/data/ldap)

Installing a perl module the “old-fashioned way” (manually)

Today I installed a couple of Linux gMail notifiers which I read about on TechCityInc.  I installed two of the applications, however I prefer CheckGmail.  I found that the other application I considered, GmailNotifier, did not look very good in my Ubuntu distro running inside a Sun VirtualBox (xVM) at 1024×768.

When I went to run CheckGmail, I received some errors indicating that I was missing a number of required Perl modules.  I attempted to download and install the required ones via Synaptic, but I didn’t have much luck with Gtk2::Sexy, Crypt::Blowfish, or Crypt::Simple.  Next I went to CPAN to download the missing modules.   Hint: search for the EXACT module name, including the colons.  I downloaded the modules, yet I didn’t know what I was supposed to do with them.  I found the answer at CosmicScripts.com.  Of course the information can also be found at CPAN perl module instructions as well, which I found after the fact.

  • Move the Perl module tarball into a working or staging directory.
  • Unpack the tarball using tar zxvf <tarball name>
  • Create the make file with the command perl Makefile.PL
  • Run make test
  • Run make install

Done.

Additional information about the Perl install can be found with Perl commands, which I found at NixCraft.

Use JNDI to access an LDAP (part 2).

In the previous part, we began working with the code to create a connection to an LDAP. The code is listed completely in parts with the core of it below.  See the box.net widget in the blog here to obtain the LDAPCtx.java code.

  1. The DirectoryContext is going to be defined from the env variable, which is the Hashtable containing our environment variables.

    DirContext ctx = new InitialDirContext(env);

  2. Next we define the Attributes we are going to be looking for. Attributes is an interface which represents a collection of values (attributes) associated with an object.

    Attributes matchAttrs = new BasicAttributes(true);

  3. The next line includes BasicAttribute which implements the Attributes interface with an unordered attribute and its value. In this instance, the attribute is “uid” and its value is”Vice.Pres.”

    matchAttrs.put(new BasicAttribute("uid","Vice.Pres"));

  4. Now we implement the interface NamingEnumeration to contain the results of searching our connection for our given attributes value pair.

    NamingEnumeration answer = ctx.search("ou=People", matchAttrs);

  5. Finally, while there are results in our enumeration, we print them out to the console.

    while(answer.hasMore())
    {
    SearchResult sr = (SearchResult)answer.next();
    log.debug(">>>" + sr.getName());
    }

Use JNDI to access an LDAP.

This is the second part in my writing documentation/tutorial on how to write Java code to connect to an LDAP server.  The first part focused on creating a connection with a local file system.  This post assumes that you have been able to work through the first part, as you will need the skills and most of the code in that first part. 

Previously we have used JNDI to access a local file system.  Now we want to access an LDAP.  Explaining what an LDAP is, and why we would want to access one, is beyond the scope of this post.  For this example, we are going to write all of our code within the main() method of the class.  (Remember, this is for instructive purposes only!) 

  1. Here are the import statements and basic structure of the program:

    import java.util.Hashtable;

    import javax.naming.Context;
    import javax.naming.NamingEnumeration;
    import javax.naming.NamingException;
    import javax.naming.directory.Attributes;
    import javax.naming.directory.BasicAttribute;
    import javax.naming.directory.BasicAttributes;
    import javax.naming.directory.DirContext;
    import javax.naming.directory.InitialDirContext;
    import javax.naming.directory.SearchResult;

    import org.apache.log4j.Logger;
    /**
     * @author Kelly.Kinney
     *
     */
    public class LDAPCtx
    {
     private static Logger log = Logger.getLogger(LDAPCtx.class);
     /**
      * @param args
      */
     public static void main(String[] args)
     {
      
     }

    }

  2. Now we add the code to create the Hashtable which will contain environment variables of the Context. This is the same as in the first part.

    // Set up the environment for creating the initial context
    Hashtable env = new Hashtable();
    env.put(Context.INITIAL_CONTEXT_FACTORY,
    "com.sun.jndi.ldap.LdapCtxFactory");

  3. Now the code starts to diverge from that used to access a local file system. Instead of the local filesystem, we need to include Context information for the LDAP. Note the format of the LDAP connection string. It is the connection string, followed by a colon, the LDAP host port number (usually 389), a slash, and a reference to the top level LDAP branch to be searched. With Sun One Directory Servers, this is represented by the “o=”. However, with Active Directory it is usually a string of “DC=” value pairs to indicate the top level of the directory.

    env.put(Context.PROVIDER_URL, "ldap://{LDAP_Ctx_String}:389/o={Top_lvl_directory}");

  4. The next block of code we need to enclose in a try/catch block. Here is how to construct this block. The area indicated by the ellipses will be where the code that follows gets inserted.

    try
    {
    [...]
    }
    catch (NamingException e)
    {
    e.printStackTrace();
    }

  5. Inside the try/catch block, we put the rest of the code… (to be explained more tomorrow)

    DirContext ctx = new InitialDirContext(env);
    log.debug("Connection toString: " + ctx.toString());

    Attributes matchAttrs = new BasicAttributes(true);
    matchAttrs.put(new BasicAttribute("{attribute}","{value}"));

    NamingEnumeration answer = ctx.search("ou=People", matchAttrs);

    while(answer.hasMore())
    {
    SearchResult sr = (SearchResult)answer.next();
    log.debug(">>>" + sr.getName());
    }

Use JNDI to access local file system.

Okay, it has been driving me crazy trying to find information on how to write Java code to access an LDAP server.

I finally found a tutorial by Sun which seems to explain it in what I would describe as a very haphazard manner. In fact, I would call the tutorial absolute crap. However, it’s all I’ve got. I am going to try to elucidate on it here.

To start, we are going to write a small program that we can use to access a local file system, i.e., the one on your desktop. This will provide the building blocks we will need later to connect to an LDAP. Ready? Let’s dive in.

  1. First you need to download additional JNDI service provider interfaces, as they are not included as part of the standard JDK distro. (Four providers, including an LDAP interface are included in the regular JDK, however I downloaded the additional LDAP providers.) Go to Sun’s Java JNDI homepage. Click on the link to download the “JNDI/LDAP Booster Pack.” Click on the”Download JNDI 1.2.1 &More Button that says ‘Download‘” Accept the license agreement and then go ahead and download all the Service Provider Interfaces. You probably don’t need them all, but what the heck. A true geek wants all the stuf he can get. You never know when it will come in handy. You will for sure need to download the “File System Service Provider” and the “LDAP Service Provider.”
  2. Extract the zip files into your C:\dev directory (where you store everything related to your development). Now if you are not using an IDE such as Eclipse or NetBeans, then you will have to manually add the required jars to the classpath. If you are using an IDE, you will need to bring the required jars into the classpath through the IDE. In this case you want to add the jars from the file beginning “fscontext,” which are: fscontext.jar and providerutil.jar. Once you have made sure these jars are on the classpath, you can begin coding.
  3. Create a file called Lookup.java. This file is only going to have one method, which will be the main method. Now add import statements for the classes you are going to need. Here’s what it will look like (import statements will be explained, and you have to throw exceptions – or try/catch them)…

    import java.util.Hashtable;

    import javax.naming.Context;
    import javax.naming.InitialContext;
    import javax.naming.NamingException;

    public class Lookup

    {
    public static void main (String[] args) throws NamingException
    {

    [...]

    }
    }

  4. The first real line of the program creates a Hashtable to hold environment variables. We then put the values of the system configuration as understood by the Context into the Hashtable.

    Hashtable env = new Hashtable();
    env.put(Context.INITIAL_CONTEXT_FACTORY,
    "com.sun.jndi.fscontext.RefFSContextFactory");

  5. Next we create a Context for the program. Essentially what this does is create the relationship between the user’s system and the program.

    Context ctx = new InitialContext(env);

  6. Then we use the Context we just created to get information about the file or directory we have passed into the program as an argument. This is one of the class methods of Context.

    Object obj = ctx.lookup(args[0]);

  7. Finally, we print out the results to the screen.

    System.out.println(args[0] + " is bound to: "+ obj);

  8. If you use a file as the parameter being passed in, you will receive information about the file like this:

    C:\\dev\\fscontext\\lib\\fscontext.jar is bound to: C:\dev\fscontext\lib\fscontext.jar

  9. If you use a directory as the parameter being passed in, you will receive information about the file like this:

    C:\\dev\\fscontext\\lib is bound to: com.sun.jndi.fscontext.RefFSContext@e5855a

  10. I’ll attach the Java file to this posting for your reference. Lookup.java.doc The entirety of the final program is this:

    import java.util.Hashtable;

    import javax.naming.Context;
    import javax.naming.InitialContext;
    import javax.naming.NamingException;

    public class Lookup
    {

    public static void main (String[] args) throws NamingException
    {
    // Set up environment for creating an initial context
    Hashtable env = new Hashtable();
    env.put(Context.INITIAL_CONTEXT_FACTORY,
    "com.sun.jndi.fscontext.RefFSContextFactory");

    Context ctx = new InitialContext(env);

    Object obj = ctx.lookup(args[0]);

    System.out.println(args[0] + " is bound to: "+ obj);

    }

    }

Change location of Apache2.2 doc_root on Ubuntu 6.06

By default, when you first get Apache2.2 installed and running correctly on Ubuntu 6.06, the doc_root (document root) is set to /var/www/apache2-default. That means that in order to navigate to the default page to see if your install is working, you have to go to http://localhost/apache2-default/ instead of just http://localhost. Ugh.

I don’t want to have to append the /apache2-default directory to my url when I am testing, or working with content on my Apache2.2 server. So, that value just had to be changed.

In the Ubuntu 6.06 installation of Apache2.2, the DocumentRoot value is set in file called “default” located in the /etc/apache2/sites-available directory. Presumably this file is configurable to accommodate multiple DocumentRoot values for different URLs being served by the same Apache2.2 server.

Once I had changed the DocumentRoot value in the “default” file to /var/www, I then copied all of the files in the /apache2-default directory into its parent directory one level above:

/var/www# cp apache2-default/* .

Note, that is a period at the end to signify the current directory in Linux.

Summary:

File: default

Location: /etc/apache2/sites-available