Large RBAC putback

Today OpenSolaris had a large putback for RBAC, Role Based Access Control.

Previously you had where more restricted i your choice of shells able to utilize RBAC roles and profiles fully, only pfsh, pfksh and pfsh where available. A frequent change request for years have been to add support the GNU shell bash. This update add among other things a support for both pfbash and pfzsh thanks to a new in kernel implementation of the pfexec command.

This also add two new privileges FILE_READ, FILE_WRITE which can be used to implement different processes that can only write respectively read from files.

For those unfamiliar with RBAC it's the Role Based Access Control used in Solaris, it provides, unlike tools like sudo, the ability to delegate specific privileges to users or roles instead of just allowing certain commands to be executed as root. Privileges are fine grained and contains right to execute, fork, link, bind to a privileged port, use DTrace and many more.

Some light on the horizon

There are finally some more signs that the next OpenSolaris release is getting closer to a release, some activity around the respin build of 134 have been seen lately.

Albert Lee summarized the encouraging news on the opensolaris-discuss list:

"Those of us feeling left in the dark might be pleased to know that build
134a, the first candidate for the next stable release of OpenSolaris, has
been tagged in Oracle's release branch (in project jargon: "snv_134a, the
first respin of 134, closed earlier this week"). A packaged build should be
available for internal QA soon, but even if it passes, it will be while
some time before the release can be published to the external repo."

Oracle might just keep their commitment to release 2010.1H the first half of CY2010.

New Sun T4 server?

Recently some references to a T4 server have showed up, it looks like it's Intel based and that it will at least be used as head in the 7000 series of storage appliance. It world be a bit confusing if this will be the final name for the server, since there are already a SPARC(R) chip with the name T2 with a T3 successor in the works. But this would indeed be to carrying on a Sun tradition, Sun had X64 workstations introduced in the Ultra-line with was based on SPARC(R) Ultra processors. We all love marketing don't we?

There are currently not much more information available, we have to wait and see both on what kind of server it is and what the final name will be.

Could OpenSolaris survive on its own?

Recently there have been some discussion about creating a community maintained fork of OpenSolaris, this is of course caused by the frustration of Oracles failure both to release 2010.03 or even provide any information on the release.

I think this is a very bad idea for several reasons, first of all the OpenSolaris community lacks the people and knowledge to keep OpenSolaris competitive in the future. There are several good contributors that have made huge difference, but the majority of the developers are paid by Oracle and they stand for most of the innovation and code contribution in ON.

Secondly, making yet another distribution based on the fork could make it harder for software vendors and companies to embrace OpenSolaris. OpenSolaris is not big enough to get fragmented and needs all the resources focused.

I think it's high time for Oracle to both release the next version and publish what the intend to do with OpenSolaris. They are only losing community members and potential customers. OpenSolaris in itself might not make so much money in it's current state, but it does introduce people to Solaris. The people who are discovering OpenSolaris today might someday want a enterprise operating system at their company. That was something that Sun did quite well before the bubble, putting Solaris in the universities. And besides, OpenSolaris provides a huge amount of beta testers for Solaris and Oracles current and upcoming appliances.

Oracle regarding Lustre and Solaris

Oracle have published a statement on their intentions with Lustre. It looks like they are fully committed to having ZFS on Solaris as backend storage. They also states that the supported solution for 2.0 will be Oracle servers, probably based on S7000(Fishworks):

"Customers who want the advanced features of Lustre 2 can purchase Oracle's integrated storage configurations to get the highest levels of reliability, performance, and support"

Regarding the kDMU on Solaris:
"Oracle continues to advance this integration between Lustre and ZFS on Solaris"

Oracle seems to be committed to both Lustre and Lustre on Solaris, but no clues on with parts will be available with source in OpenSolaris. Hopefully they only keep the glue and fancy interfaces to themselves as with fishworks under Suns ownership.

"Oracle intends for Sun Lustre Storage Systems built with Lustre 2 to include both the core file system and other components that may or may not be open source"

Here are Peter Bojanics presentation.

Peter have previously talked about the future of Lustre/Fishworks:

"Leverage Lustre to create truly differentiated storage solutions for Sun
Solaris Client & Server ports are going to become increasingly important
Fishworks Lustre Servers (dtrace/analytics video)
Solaris pNFS server based on Lustre"

OpenSolaris 2010.+

Just some rambling and lose ends concerning the next OpenSolaris release.

The planed release date for the next release of OpenSolaris has been passed, this date was set by Sun before Oracle took control. Sadly Oracle keeps quiet and are not giving any new dates, explanations or hints for the release. This is of course feeding the uncertainty and frustration in the OpenSolaris community. Even if the date would remain unset they could at least communicate that it has slipped but will be released when it's ready.

I hope this is not the way Oracle will handle the Sun legacy in the future or people might begin to feel blue. The openness of communication was one of the big advantages of OpenSolaris with Sun, sure releases slipped and people got upset but I've never had this feeling of being totally left out of the process.

There are however some several signs that a release is still planned in the near future, the internal name for the release, "2010.1H" is still actively used, that means the first release of 2010, or first half of 2010. A new internal fork for the PKG source was created for this release just a few days ago and a similar tag exists for the Caiman installer

Danek Duvall, April 2 on pkg-discuss:
"The pkg(5) gate is open again for business. Note that we're switching to an internal branch system to keep track of 2010.1H fixes, rather than an external gate like we did for 2009.06."

Here is the Blocker bug for the release at defect.opensolaris.org: Bug 8314.

Notice the original schedule in the comments:
"This is the blocker bug for the OpenSolaris release slated for the second half of 2009. All blocking bugs for this release should set to block this bug."

The 2010.03 branch of the Caiman slim installer (slim_1003) is also actively being updated alongside the default development branch, so the developers are doing their part, just no official statements of the delay, but given the lack of external communications the internal developers may not have been told to stop working on the release.

Update
Well, someone from Oracle has stated what we suspected and it's the same as it was right before the last release, no new dev builds before the 2010.03 release. Allan Coopersmith on opensolaris-discuss:
"Packages for the later builds have been built for all the gates, not just ON, but not published to pkg.opensolaris.org while the 2010.03 release is being finished."

News and two PSARC:s

This is only a relay of some news to keep you occupied while I'm working on a more interesting but far more time consuming posts.

The Fishworks simulator is available for download in a brand new 2010.Q1 version, no upgrade needed and now only for VirtualBox which also had a maintinance release last week (3.1.6).

Two new interesting PSARC:s have emerged the last week:

PSARC/2010/105 zfs diff
Like diff(1) but for ZFS, this will make it possible to calculate filesystem difference between two snapshots of a dataset.

PSARC/2010/106 DTrace TCP and UDP providers
This will add TCP and UDP providers to Solaris making thinks like the following possible (from the PSARC):

# Watch inbound TCP connections by remote address,
dtrace -n 'tcp:::accept-established { trace(args[2]->ip_saddr); }'

# Inbound TCP connections by destination port summary
dtrace -n 'tcp:::accept-established { @port[args[3]->tcp_dport] = count(); }'

# Watch inbound accepted TCP connections by process summary
dtrace -n 'tcp:::accept-established { @cpid[args[1]->cs_pid] = count(); }'

# Watch UDP total number of bytes sent/received by process
dtrace -n 'udp:::send,udp:::receive { @bytes[args[1]->cs_pid] = sum(args[4]->udp_length);}'