[oi-dev] Proposal: OpenIndiana Stable Branch

Fri Jan 14 22:02:19 UTC 2011

Hi Garrett,

I agree that we don't have the developer resources to support the software (support in the traditional sense). I should have been more clear in the mail, but I'm literally only talking about critical security holes. By critical I mean holes that can be exploited by external parties to obtain unauthorised access to a box - like the Exim remote root exploit that happened recently.

I wasn't proposing giving support in any way beyond this because that would be foolish at best, impossible at worst.

But monitoring the list I gave for critical only security holes should not be a massive effort, especially if we track security fixes in another distro such as Debian or CentOS.

I'm not sure how many major security holes crop up in ON... I have a box with Joyent that's snv_84 and has been up over 800 days, and they're shared IP stack zones on public IPs. I've always wondered how they haven't turned into one giant botnet. But it does seem to be a good advertisement for the security of ON. Have Illumos been contacted about any critical security exploits so far? Also do you know if anyone on the project is tracking any Solaris security lists? I imagine both projects can share the work and benefit.

And of course as a project we're always going to be doomed to suffer the burden of supporting a release at some point another - we may as well start small and early - people are running OI_148 in production anyway.

/dev will definitely go to Illumos as soon as we can integrate it, all future releases will be on Illumos, and when that happens almost all the desktop users will then be on Illumos.

I'm sorry it has taken so long for this work to start. I'd personally have preferred us to be on Illumos a long time ago but motivated developers with free time who can do the integration work haven't stepped forward or had time. Thankfully we finally have Illumos builds going and some new people on the project who are working on this. I also hired Andrzej Szeszo at EveryCity, he started on the 4th Jan and he's spending some of his work time on OI. His first task is to get g11n/i10n sorted, then to help with the Illumos integration. This should speed things along. He'll be able to devote more time to OI/Illumos once he completes a major bit of EveryCity work over the next few weeks.

I suspect I feel the same frustrations you do about having limited time, resources and finding it hard to organise and motivate people to do work. OI is slowly growing though, and it does look like we have some committed individuals who have stuck with the project. I guess these things take time, patience and a lot of hard work.

Cheers,

Alasdair

On 14 Jan 2011, at 21:29, Garrett D'Amore wrote:

> (Privately.)
> 
> IMO, you are doomed to suffer this way.  The reason for this is that OI simply doesn't have the developer resources necessary to provide "support" for such a massive amount of software... even the limited set you list here is huge -- ON by itself is 15M lines of code.
> 
> Personally, I'd far rather you waited to take this bite until you are on illumos... at least that way you'll have an upstream community for that massive code base -- with your 147 bits you are pretty much on your own.
> 
> This is just my opinion though....
> 
>  - Garrett
> 
> On 01/14/11 12:36 PM, Alasdair Lumsden wrote:
>> Hi All,
>> 
>> I believe now would be a really good time for us to create our first stable branch of OpenIndiana, given the timing of some developments within the project.
>> 
>> Below I've outlined my proposal and I'd love feedback from the community and from OI developers!
>> 
>> Obviously as a new project with a small (but growing) developer base, providing support for the whole release isn't feasible - there are literally thousands of packages in the distribution. But we have to start somewhere, so I'm proposing we provide limited support (outlined below) for a set of core packages.
>> 
>> ********
>> * Why? *
>> ********
>> 
>> Prior to the Oracle takeover, Solaris 10 was free to use in production, and for a long time, security updates were provided free of charge. OpenSolaris was also free to use, and updates were available by living on the bleeding /dev edge. People were (mostly) happy.
>> 
>> Then Sun hit financial difficulties and discontinued free security updates for Solaris 10. Then Oracle happened, ending the free use of Solaris in production.
>> 
>> This has left people wishing to use Solaris technologies on their production servers in a difficult position. They have to pay Oracle, or use distributions that don't provide security updates. Or switch to Linux.
>> 
>> There are a great many people who would jump at the chance to use Solaris if there were a production ready version with security and bug fixes provided for free.
>> 
>> Indeed, this is what people have come to expect from mainstream UNIX platforms - Linux distributions such as Debian, CentOS, Ubuntu, etc, provide updates free of charge - and this is one of the reasons they have become so popular.
>> 
>> We have a real opportunity to capitalise on the situation left by Oracle, to capture server market share away from OpenSolaris, Solaris 10, and give users a migration path other than switching to Linux (which a lot of people are doing).
>> 
>> There are a lot of people out there who *really really* want a stable build of OpenIndiana - myself included, and I believe OpenIndiana's best chance of gaining acceptance, market share, and building a thriving development community is by capturing the server market.
>> 
>> There is also a risk that if we *don't* do this, we'll become an obscure fringe distribution, like DragonflyBSD.
>> 
>> The goal here is to be the *mainstream* accepted de-facto Solaris distribution. Something people talk about and seriously consider using.
>> 
>> Solaris contains killer technologies not seen on other platforms; technologies like ZFS, Zones, SMF, DTrace, COMSTAR, Crossbow - I couldn't live without any one of these, and we should capitalise on this while we can.
>> 
>> It's also worth keeping in mind that despite warning users that oi_147 and oi_148 were development releases, people are already using it in production environments, myself included, due to a lack of alternatives. The great news is that it has proven to be exceedingly reliable, and I have no hesitation in recommending it for busy workloads. All we need to do is add security updates and critical bug fixes on top and we'll be in a great position. No small feat I grant you, but we can start off small and work our way up.
>> 
>> Now is also an opportune time to do this - our next release will be based on Illumos, which has seen rapid development and will involve some integration pain. Some have called for a stable branch after Illumos is integrated, but it could be many months until we have an Illumos dev build suitable for respinning as a stable branch. That's months of lost opportunity.
>> 
>> So I say we do it now.
>> 
>> /dev builds will continue as normal, the next one will be Illumos based - Desktop users can continue to use our /dev builds, and internet facing servers can use the stable branch.
>> 
>> *********************
>> * What we'd provide *
>> *********************
>> 
>> The release would be aimed for February, and titled "2011.02". It would be based
>> on oi_148. We would only provide the Text Installer and Automated Installer
>> ISOs.
>> 
>> We would provide security and critical bug fixes only for:
>> 
>> 1. OS/Net (The core OS consolidation)
>> 2. A limited set of server oriented packages that have the greatest usage and
>> attack "surface area". The initial list I can think of includes:
>> 
>>  - OpenSSL
>>  - Sendmail
>>  - Perl 5.8.4
>>  - Python 2.6
>>  - Ruby
>>  - zip, bzip2, gzip
>>  - Apache HTTPD 2.2
>>  - PHP 5.X
>>  - MySQL 5.X.X
>>  - Postgresql 8.4
>>  - Java
>>  - Tomcat
>>  - GNU Coreutils
>>  - GCC
>>  - RSync
>>  - ISC BIND
>>  - Bash
>>  - Curl
>>  - wget
>> 
>> We should also aim to provide security fixes for any bit of software in the repo that allows an easily exploitable remote access vulnerability or root privilege escalation, although we cannot guarantee to do so as monitoring security updates for over 1000 software packages is unfeasible. An example would be the recent Exim vulnerability on CentOS that allowed remote root access by sending appropriately formatted emails. This area is something where we will depend on users, not OI developers, alerting the project to the issue so that a judgement call can be made on whether we have the resources to fix the issue.
>> 
>> Security updates would be provided from 6 months of the release date, or until the next stable release is released. Potentially we have the option as a project of providing commercial support past the 6 month date if enterprises desired this. I feel this could be a good way of generating revenue for the project to fund development if there was a market for it.
>> 
>> If external contributors were able and willing to commit patches/fixes beyond the supported list, we'd accept them with open arms, and this could be a great way to extend the contributor list and get more people involved.
>> 
>> ******************
>> * How we'd do it *
>> ******************
>> 
>> 1. We do a re-spin of oi_148 fixing any of the major bugs that we can (Eg things like the Broadcom driver issue introduced in oi_148)
>> 
>> 2. This gets pushed into pkg.openindiana.org/stable (or /release - tbc)
>> 
>> 3. Security fixes and critical bug fixes for the supported packages get pushed into the repo. People doing an image-update would then receive the latest packages.
>> 
>> 4. Security fixes and bug fixes would be backports to the version we currently provide.
>> 
>> People should be able to update from oi_148 to 2011.02. And people should be able to update from 2011.02 to oi_150. But people should not be able to downgrade from oi_150 or later to 2010.02. This is the same as the situation was with OpenSolaris releases.
>> 
>> To make the above easier to manage, one proposal I have is to match the versions of Apache, PHP, MySQL, Tomcat etc to the same versions shipped in RHEL 6/CentOS 6. This way we can monitor their repositories for security updates against these packages, and share the same backports. This will make life a lot easier for us as a project.
>> 
>> The main thing will then be doing rebuilds of the packages involved. I would suggest we keep a set of Zones on infra01.uk.openindiana.org around for doing this, so that doing a rebuild is very easy to do, and well documented. Just a case of logging in, patching the appropriate files, running a build, pushing to a test repo, testing it, and then pushing into the public repo.
>> 
>> **********************
>> * Concluding Remarks *
>> **********************
>> 
>> I believe this is a great opportunity for us and I think it's the right time to do it.
>> 
>> Although we're starting on the server only front, there's no reason why we can't at a later date add support for the desktop if sufficient contributors are able to make it happen.
>> 
>> I'm confident that with a stable branch, we can really increase our userbase on servers, which will bring commercial opportunities from the enterprise, and accelerate development of our favourite operating system :-)
>> 
>> Looking forward to feedback!
>> 
>> Cheers,
>> 
>> Alasdair.
>> _______________________________________________
>> oi-dev mailing list
>> oi-dev at openindiana.org
>> http://openindiana.org/mailman/listinfo/oi-dev
>>   
> 
> 
> _______________________________________________
> oi-dev mailing list
> oi-dev at openindiana.org
> http://openindiana.org/mailman/listinfo/oi-dev