Showing posts with label java enterprise system. Show all posts
Showing posts with label java enterprise system. Show all posts

Saturday, 17 January 2009

Modifying Sun Java Enterprise System installation or completely removing it on Solaris 10

I wrote other posts describing why and how I installed components from Sun Microsystems' Sun Java Enterprise System 5 (JES from now on) on Solaris. It may sound somewhat silly, but one of the questions related to the JES installer I heard so far is how software can be uninstalled. That's strange, and more if you consider the nature of Solaris 10 package management system. Somehow, having a GUI makes the situation more complicated, because a person unfamiliar with Solaris 10 and with Sun's way of distributing software would expect the same installer to do the job. Whoever knows of its existence may also also think that prodreg is sufficient to perform the uninstallation, but its not, for the reasons I will clarify soon.

The worst thing, in my humble opinion, is that Sun's documentation is usually good and very detailed. For every product I'm trying to remember, there's always a detailed installation document. What's not so clear to the newbie, in reality, is that documentation is there to be read. If you feel like doing it, read this blog and go here, where you can find complete information about JES installations. You should read it carefully while planning your installations/upgrades/uninstallations.

Here's the long story short.

How the JES installer works

The JES installer is an utility that eases the installation and the configuration of a set of server-side products which are bundled together. The installer also takes care of interdependencies between products, which may be complex, with various preinstallation and postinstallation procedures. The JES installer for Solaris uses the usual operating system package management system to deploy package on a host. For the same reason, the JES installer also provides an uninstallation utility which should be used when removing JES components instead of removing pagkages with other means, such as pkgrm or prodreg.

JES installation utilities

The JES installer can be found on the directory which corresponds to the platform you're installing and its called installer. This is the program you'll launch when installing JES for the first time. If you invoke it with no arguments, a GUI will be displayed and you will be able to choose the packages you need and perform your installation.

Even if having a GUI gives you the idea that everything will be managed for you by it, you're wrong. Read the documents before performing the installation of any document.

Patching installer

If JES has already been installed or if you need to patch the installer itself, you will find another copy (packaged) of the installer in the /var/sadm/prod/sun-entsys5u1i/Solaris_{x86,sparc} directory. Once the JES installer has been patched, that's the copy that should be used when installing or modyfing the current installation.

JES uninstaller

Once the JES installer has installed some of the products of the JES distribution, you will find the uninstallation utility in /var/sadm/prod/SUNWentsys5u1. The uninstaller, as the installer, can be run either in graphical, text or silent mode. Due to the complexity of the relationships between the component, an uninstallation should be carefully planned, too. Once more time: read the docs.

Uninstaller limitations

The JES uninstaller has some limitations, including the following:
  • it only uninstalls software installed with the installer
  • it does not remove shared components
  • it does not support remote uninstallations
  • some uninstallation behavior depends on the components being removed and it does not limit to data or configuration files.
  • it does not unconfigure the Access Manager SDK on the web server.

Upgrading Sun Java System Directory Server Enterprise Edition to version 6.3

Introduction

As part of my network infrastructure I also deployed an instance of Sun Java System Directory Server Enterprise Edition (JSDSEE from now on). I chose to download and install it with the Sun Java Enterprise System (JES from now on), which at the time of writing has reached version 5 update 1, which ships JSDSEE 6.2.

Installation of this and other products with the JES installer went smooth on my Solaris 10 update 5 instances and the services were deployed, configured and up and running in a question of minutes.

Some weeks ago we had an abrupt server shutdown the same day I was adding some entries in the LDAP server. When the server went up it was no big surprise to me discovering that the LDAP database was corrupted and the only options I had was restoring from a backup, which I had obviously done. Again, the service was restored in a matter of minutes.

However, I discovered by chance that JSDSEE 6.2 is affected by a bug that, in certain conditions, may result in data loss and database corruption. The bug report can be examined at Sun Solve website at this address: JSDSEE bug #6642430. The bug has been resolved but it implies upgrading JSDSEE from version 6.2 to version 6.3.

Getting the software

When it comes to getting the software, you are presented these options:
  • Sun Java Enterprise System distribution
  • native packages distribution
  • zip distribution
The JES installer installs its products with native packages and I usually prefer to use this method rather than install zip distributions and carefully tracking down the details about every software I installed. In this case is that the native package distribution is a patch to apply to a previous JSDSEE installation.

Differences between the distributions

The differences between the distributions are described in the document Sun Java System Directory Server Enterprise Edition 6.3 Administration Guide. It's not obvious, because the documents I read first, Sun Java System Directory Server Enterprise Edition 6.3 Release notes and Sun Java System Directory Server Enterprise Edition 6.3 Installation guide, tell nothing about this.

Java Enterprise System distribution

Basically, the JES installer is a native package distribution, but it still delivers just JSDSEE v. 6.2, and you can only rely on a patch to upgrade JSDSEE to v. 6.3. The JES installer, also, does not provide the Directory Server Resource Kit, which is provided by the zip distribution. The JES installer is a GUI tool which facilitates the installation of the components delivered with JES and it also facilitates the shared components used by the products in the suite. The JES installer must be run as root because the products are installed as native packages.

Native patches

The native patches must be run as root, too, and let you upgrade your existing JSDSEE installation to version 6.3. As I'll tell in the following sections, these installation method is not supported on Solaris Express or OpenSolaris.

Zip distribution

The zip distribution is a non-root self-contained distribution which can installed by anyone. Multiple version of the product can then be installed at the same time. The drawbacks of this kind of distribution is that the system administrator is responsible of having these services start at system boot and that whoever installs them must keep a detailed log of every installed product.

Test run on Solaris Express Community Edition

Before upgrading a production server, I always test the installation on another machine. Unfortunately I had no such machine at hand so I decided to test the installation on Solaris Express Community Edition (SXCE from now on) build 103. I'm using SXCE because the JES installer was not running properly on OpenSolaris 2008.05 so I switched some development machines to SXCE to be able to use these kind of Sun distributions.

The JES installer went smooth on SXCE and I also replicated the LDAP database on the test machine. Unfortunately, when it came to run the patches, I was caught in a sort of patch hell because I found no way to install the required patches on it without having patchadd complaining about packages' versions or dependent patches. After losing and entire night trying, I decided to switch to Solaris 10.

Patching JSDSEE 6.2 on Solaris 10

This time, everything went absolutely smooth. I just followed the recommendations on the Sun Java System Directory Server Enterprise Edition 6.3 Installation guide and I just ran the following commands in this order (be aware that these patch numbers are relative to Solaris 10 x86/AMD64). The list of patches is available here.

Stopping the services

After patching, all the services must be shut down. First I stopped the Directory Server Control Center
# dsadm stop /var/opt/SUNWdsee/dscc6/dcc/ads
the I stopped the JSDSEE instance I previously registered with SMF. This step depends on your installation.

Upgrading shared components

I installed the following patches taking care of following the special instructions included with them (if your system is not Solaris 10 AMD64 please check this):

Installing the patches to version 6.3

The patches to install on Solaris 10 AMD64 are these (be aware that the localization patch must be installed before the JSDSEE v. 6.3 patch):

Conclusion

After installing these patches and restarting the JSDSEE services, everything was up and running. Since now on, I'll always have a Solaris 10 installation to test these kind of setups because it's not the first time I have problems with Sun packages on SXCE or OpenSolaris.

Tuesday, 25 November 2008

I switched from Squid to Sun Java System Web Proxy Server

I've been running Squid Web Proxy Cache for quite a while and also documented some basic setup in another article. But the last time we set up a server I decided to try Sun Java System Web Proxy Server. Since then, I switched the remaining Squid servers to Sun's proxy and lived happily ever after.

Why? Well, Squid was giving me no problem but sometimes setting it up and managing it was boring and error prone. Sun's Web Proxy Server has got the (familiar) administrator's web interface and I practically never touch a configuration file by hand. Creating a basic setup it's really a question of clicking a couple of button and the proxy's up and running.

Installation.
Installation is pretty straightforward. I downloaded the Sun Java Enterprise System and launched the installer. Once launched, I just checked the Sun Java System Web Proxy Server and the installer did it all. The installer also gives you the possibility of automatically creating a proxy server with the default configuration values and if you need a good starting point that's a good hint.

Creating a server.
This was easy too. I had to create two different web proxies because we're serving two subnets with different requirements. Once the installer finishes its work, you can connect to the administration console using the configuration values you provided during the installation:
  • administration port
  • admin password
Open your favorite browser and launch the console. Once you're in, you'll find yourserlf in the Server/Manage Server section:


Adding a server is pretty easy, it just asks you for (very) basic information:



Inspecting default configuration.
Once you're done with creating your server(s), you can inspect the default configuration with the Manage Servers/Preferences/View server settings option:



Configuring system preferences.
Using the Manage Servers/Preferences/Configure system preferences tab you can modify basic preferences for your proxy:


In this page you can set:
  • server user: by default, it's nobody, and it's a value I usually don't need to change.
  • processes: the number of the background processes used to serve incoming requests.
  • listen queue size: the maximum number of pending connections on a socket.
  • request throttle: the number of concurrent transactions that the proxy can handle.
  • enable DNS: this is useful mostly for logging and for managing access control. If you enable DNS, the proxy will resolve IP into host names.
There are other configurable options, many of which are useful if you plan to implement distributed caching, whic I'll not cover in this post.

Adding listen sockets.
The next thing you'll probably want to do is setting up listen sockets, which are the endpoints of the proxy to which your clients will connect. If during the installation a default server was created for you, you'll probably want to edit the default port value for the listen socket:


Setting up cache properties.
The last thing you'll probably do to set this basic web proxy server is configuring the cache. You can start in the Manage servers/Cache section of the admin application. The first panel is Set cache specifics where you can set the most common properties for you cache.



The first thing I usually do is changing the cache working directory. Remember that when you change the cache directory you must pay attention that the proxy user (in my case nobody) can write into that directory, otherwise the cache won't work.

One chosen your favorite directory, you can set up the cache capacity either with the provided drop down list or via the Cache capacity configurator.

In this page you can also configure basic caching behavior for HTTP, FTP and Gopher protocols. As far as it concerns the HTTP protocol:
  • Always check if the document is up to date: this option does exactly what it says: every time a document is requested to the proxy, the proxy will check that the version it is caching is up to date. This may be useful in some circumstances but will rise the number of outgoing connection from the proxy server.
  • Check only if last check more than: if you choose this option, the proxy server will open a connection to check if the document is up to date only if the last time it did was more than what you specify. The default is two hours and depending on the situation I use to rise it up to one entire day.
  • Using: this option controls how the proxy server checks if the document is up to date. You can choose either using the last-modification factor, which is the set of headers that the web server sends along with the document, or the explicit expiration information, which are the internal headers used by the proxy server.
  • Never report accesses to remote server: this option tells the proxy server not to report a cache hit to remote servers.
  • Report cache hits to remote server: this option tells the proxy server to report to the remote server the number of times a document has been hit in the cache and accessed from there. This option rises the number of outgoing connection from the proxy server and may hit latencies and performance.
Cache partitions.
The cache partitions are the parts of disk reserved for caching purposes by the proxy server. You'll need to edit the cache partitions properties in the case, for example, you rise the cache capacity and you need to reserve more space on disk by adding a new cache partition.


In the previous screenshot the cache partition is 1.6 GB, which is the cache capacity I set up for this server. Adding a cache partition is trivial, you're only asked about the directory which will host the partition.

Set garbage collection.
As long as you use the proxy server, it will cache documents you request and the cache will keep growing up maintaining the allocated space in the range specified by the caching configuration. The garbage collection is the process that cleans up documents from the proxy cache and must be performed periodically. By default, this property is set as Automatic. I observed in my proxy server instances that if the cache hits are high and you are caching big documents, even if the garbage collection is automatic, it seems to never take place and the cache keeps growing up. For this reason I suggest you plan and schedule regular gargabe collection cycles. You may schedule them via the system cron or via the internal proxy scheduler. I usually use the system cron. Once chosen the manual configuration option, explicit garbage collection cycles can be scheduled in the Schedule garbage collection panel.

Caching configuration.
Other useful options you may want to set up can be found on the Set caching configuration panel. By default, the caching default is the derived configuration. If you want to explicitely set up every option, you can then set cache as the caching default value. Once done that and pushed the OK button, a new form will appear:



The options you'll find usually are:
  • The cache default
  • How to cache pages that require authentication
  • How to cache queries
  • The minimum and maximum cache file sizes
  • When to refresh a cached document
  • The cache expiration policy
  • The caching behavior for client interruptions
  • The caching behavior for failed connections to origin servers
An option which is often overlooked and might be pretty important for your proxy performance are the last two which rule what happens when a proxy connection is broken. This may happen if, for example, your user exits the browser or cancel a connection: the proxy may continue downloading the entire file even if the client is not retrieving it any more and this effect may sum up when many client are connected leading to proxy saturation and lost of performance. I saw this happen many times, even if with multimedia content such as flash-based solutions which deliver content, like YouTube. For this reason, I usually set 100% for the caching behavior for client interruptions which in effect has the proxy close the remote connection whenever a client disconnects.

Conclusion.
With just few and simple steps you've set up an enterprise grade web proxy server. I suggest you to check the official documentation at Sun documentation center to fine tune your setup and read about more advanced configurations such as connecting to an LDAP to authenticate users, setting up SOCKS and setting up proxy arrays for distributed caching.

Now, enjoy your new proxy server!