c0t0d0s0.org

Maybe you remember my RBAC/Privileges-Tutorial in the the LKSF series. In the third part i described how to take away some privileges from the apache processes. But this takes the concept a whole step farther. Nick Kew announced on the Apache developer mailinglist the availability of a module to make Apache privilege-aware - "Introducing mod_privileges for Apache HTTPD:

This is a platform-specific module for Solaris 10 and OpenSolaris, that makes the webserver privileges(5)-aware. This enables the server to be run with enhanced security, and with different settings per virtual host.

With the use of this module you can define user, group and privileges of a virtual host.

Unlike perchild, mod_privileges is not itself an MPM. It works within a processing model to set privileges and User/Group per request in a running process.

This is a really interesting development: With such a module you can contain every virtual hosts in it´s own user/group combination and more important you can use privileges to controll the possibilities of an virtual hosts at the operating system level. For example you can take away the privileges to execute subprocesses (for example tradtional CGI scripts) at all by a single line of configuration. Really neat ...

Glen Brunette describes at the Sun Wiki the concept of the Immutable Service Containers (ISC):

Immutable Service Containers (ISC) are an architectural pattern used to describe a platform for highly secure service delivery. While the actual instantiation of an ISC can differ based upon customer and application requirements, an ISC embodies at its core the key principles inherent in the Sun Systemic Security framework including: self-preservation, defense in depth, least privilege, compartmentalization and proportionality.

A really interesting concept! By delivering the service by a zone in conjunction of denying write access to the binaries or configurations and vastly locking down the privileges you can build a really secure environment.

Adam Leventhal brings it to a concise point where the new Sun Storage 7000 systems are really different from other systems besides of this cool administration interface:

Further, you can design the specific system you need with just the right balance of write IOPS, read IOPS, throughput, capacity, power-use, and cost. Once you have a system, the Hybrid Storage Pool lets you solve problems with targeted solutions. Need capacity? Add disk. Out of read IOPS? Toss in another Readzilla or two. Write bogging down? Another Logzilla will net you another 10,000 write IOPS. In the old model, of course, all problems were simple because the solution was always the same: buy more fast drives. The HSP in the 7410 lets you address the specific problem you're having without paying for a solution to three other problems that you don't have.

At the end, one of the core differentiators are the hybrid storage pools. ZFS gives us with the HSP an important advantage. Furthermore it makes difficult questions simple. For example mirroring write caches in RAID controllers: Many of our competitors use special interconnects to mirror the cache from one controller to another. When your write cache is a drive in a JBOD you don´t have to mirror the cache, you just import the drive to the surviving filer node.

Many problems become simple, when you think about them from another perspective ... you just have to start to think.

This gives for Sun and the Opensolaris community an important lead: It may be easy to replicate the GUI, it may be easy just to take commodity hardware, but it isn´t easy to copy dtrace and it isn´t easy to copy ZFS.

One of the events of the upcoming CEC: We will announce the OpenStorage systems in Las Vegas. Will write about them directly at the event.

Roger Bitar did some really interesting benchmarks with mysql on SSD. In his benchmarks he artificially constrained the availability of memory for the mysql buffers (aka cache):

We choose to test MySQL, the open source database (DB), using a simple MySQL benchmark called Sysbench. We populated the Sysbench table with 112 Million rows (around 26GB size) that fit on 1 SSD drive . We executed read-only queries while varying the buffer size. We mounted the file system in DIRECTIO mode to disable file system caching. We perfrormed the tests with regular HDDs and repeated them with SSDs.

There results were somewhat astounding. Of course a fully memory saturated database is the fastest way to implement a database (buffer cache at 24 GB). But with a database on SSD Roger was able to yield 96 percent of the performance of the in-memory database even with heavily constrained RAM space (buffer cache limited to 8 GB). The latency at memory constrained situation is vastly better with SSD than with rotating rust.

This leads me to an interesting conclusion: When you just compare the power consumption of SSD and hard disks (aka rotating rust), you forget a part of the equation. Let´s assume a FB DIMM takes 10 watts (it´s a little bit more, but 10 is easier for calculating). In the benchmark you were able to have almost the same performance with SSD (2 watts) at 8 GB as at 24 GB. Let´s assume 4 GB DIMMS. You would save 18 Watts (10*2-2) by using the SSD. Okay 18 watts isn´t a big deal, but now think about a 240 GB database.

You can design your database server in quite a different manner, when you take SSD into your considerations.

The "What´s new in What's New in the Solaris 10 10/08 Release" document is online at docs.sun.com. Thus you can get an overview what you can expect from the next release of Solaris 10.

I will provide a list of the features for you in this article. For more informations please consult the linked article. As you see, there was a lot of development in the Z