PostgreSQL is a great database especially if you run it on Solaris. And Sun is trying to position Solaris as *the* platform for PostgreSQL. The fact that PostgreSQL is now bundled and supported with Solaris 10 should tell you something. And recent benchmarks that Sun posted with PostgreSQL featured as the backend should tell you that Sun is becoming more aggressive with this gem of an open source database. To make things even more interesting Sun is developing even tighter integration of Postgres with Solaris. The most prominent bits in my opinion are PostgreSQL Dtrace integration allowing you the best visibility you can get into the operation/performance of the database and support withing Sun Cluster environment. With reliable industrial grade HA clustering PostgreSQL is ready to be used at the core of many enterprise envirionments. Here is a doc from Sun on the features of PostgreSQL 8.2 that are already in OpenSolaris and are soon to make it into mainstream Solaris:

http://www.sun.com/bigadmin/features/articles/postgresql_opensolaris.jsp

The open door policies of the good old past are long gone and nowadays it is a a duty of pretty much every sysadmin to batten down the hatches on all systems as much as possible. Some subsystems make it a bit harder than the others for simple reason of not being designed very secure from the start. X Window is a good example of that with security mechanism that are not very strong and with too many doors open by default. Probably the most inviting door of all in X Window is XDMCP - a protocol allowing to perform X Window logins remotely. To make matters worse XDMCP is happy to advertize the availability of the service to other machines on the network making it a prime target for attacks. On Unix operating systems that rely on CDE to provide the X Window logins there is a dtlogin daemon that services the XDMCP requests. XDMCP service is provided on UDP port 177, so disabling it is as simple as forcing the dtlogin daemon to listen on port 0 instead effectively cutting off all access to remote clients good or bad. Fortunately dtlogin is designed to take an argument that can specify the udp port on which to listen (-udpPort ) and so disabling XDMCP is as easy as setting "-udpPort 0" argument for dtlogin. On Solaris versions prior to 10, which rely on "classic" startup scripts this can be done as simple as editing the /etc/init.d/dtlogin script and modifying the dtlogin startup command to accomodate the "-udpPort 0" argument:

Before

/usr/dt/bin/dtlogin -daemon &

After

/usr/dt/bin/dtlogin -daemon -udpPort 0 &

On HP-UX it is very much a similar affair only modifying the /sbin/init.d/dtlogin.rc script appending the "-udpPort 0" to the list arguments of dtlogin.

With Solaris 10 on the other hand it is a bit different since it relies on an SMF framework to manage "services". You have to use the svccfg utility to modify the arguments passed to dtlogin when it is started:

# svccfg
svc:> select cde-login
svc:/application/graphical-login/cde-login> setprop dtlogin/args=astring: " -udpPort 0"
svc:/application/graphical-login/cde-login> quit
#

HP support web site is a bit like tangled mess to me, it always take a ton of time to find what I'm looking for. There is a dramatic scarcity of really useful how-to type documentation on HP-UX administration. I don't deal with HP-UX very frequently and so I get rusty around certain areas and so need to check the documentation every so often. Replacing failing drives in mirrored volumes is one the chores that you don't do very often and so there is always a need for a handy manual on this topic. Here is a very good one document from HP that might save you a bit of time, just as did for me:

When Good Disks Go Bad

It is easy to dismiss the cost of licensing for an OS as minor when you buy a new piece of hardware to run it. Usually on the grand scale of your hardware purchase the OS cost is just a small percentage of the overall spend and that worked wonders for Microsoft selling Windows, HP selling HP-UX and IBM with AIX - no one cares, but everybody pays. Well, virtualization topping all IT agendas pretty much all over the place, the OS tax will be becoming a whole lot harder to ignore. For a simple reason that the more OS images you cram into your favorite piece of hardware, the harder it becomes to ignore the OS licensing costs. In the case of Microsoft Windows it will be impossible to ignore - the Microsoft Windows licensing costs are so high that running just a few virtualized instances of Windows on the same entry level box will make cost of OS licensing higher than the cost of hardware! Well, Microsoft has been overcharging for essentially an inferior product for a long time and at some stage people should wake to it, but this is a topic for a different conversation. What is more important is that with virtualization becoming more popular the old ways of licensing operating systems per instance may become obsolete and if the OS vendors do not wake to it, they may find there market share rapidly declining. At the very least Solaris and Linux should be putting more pressure on the vendors that cling to the old ways of licensing their OS products per instance.

There is so much activity with OpenSolaris project it is now pretty hard to keep track what the next "cool" thing will be coming out of the gates. I just realized that I missed a new Xen build of Nevada -- the Xen enabled Solaris Express build. I have been waiting for this build for almost half a year since the last one was released. This is going to be exciting. Grab your build 66 at the following URL:

http://www.sun.com/download/products.xml?id=4691b249

Jonas Dahlen at Sun has already blogged about this here giving some pointers on how to get Xen going.