Update on OpsCenter proxies in local zones

Some time ago, OK a long time ago, I talked about installing an OpsCenter proxy in a local zone on Solaris. I noted that it is a bad idea and ugly. Especially upgrading JET is somehow a no-go, if you still want support for your application. My hope during this time was, that version 2.5 will support local zones.

And in deed, the support was added, but only for the satellite controller. So I was looking for a way to improve the solution to run the proxy in a zone. The technical limitation which prevents the standard installation of the proxy in a zone, is the NFS server which is used by JET. It's simply not possible to run the Solaris NFS server in a local zone.

To overcome this limitation I tried unfs3 an opensource userspace NFS server, the installation was not so tricky compared to the solution with the remote NFS-server and JET 4.7, but there are some pitfalls. And during runtime the proxy runs really fine, at the moment we use such a proxy setup with around 80 connected agents.

But there is one big disadvantage,  if you upgrade OpsCenter, the upgrade scripts will have some problems with the setup. It seems that the SUN/Oracle engineers don't want to support this homegrown setup. I am tired of fixing/adapting this upgrade scripts, so we are slowly switching all proxies to LDOMs now. After a few months it seams that the proxy runs really fine in an own LDOM and it's also completely officially supported.

Lessons learned:

• Don't run an OpsCenter proxy in a local zone, as long as it is not officially supported.
• JET/Jumpstart: after troubleshooting some scripts of them, I like to say ... please re-implement this ancient software, please!!
• unfs3 is pretty neat if you feel the need to run a NFS server in a solaris local zone.
• Guest LDOMs are fine to run OpsCenter proxies.