[OpenIndiana-discuss] Proposal: OpenIndiana Stable Branch

[Anil]

Have you guys thought about implementing pkgsrc natively for 3rd
party/userland packages?

http://www.netbsd.org/docs/software/packages.html#platforms

I recently came across it and it's quite interesting. I am debating to
use that in conjunction with IPS for OS/Net.

Anil
Entic.net
Solaris Cloud Servers

On Fri, Jan 14, 2011 at 5:20 PM, Deano <deano at rattie.demon.co.uk> wrote:
> Hi,
> Sounds like an good move, however I don't think that you mentioned or
> proposed how we tackle one issue of taking OI into production server (which
> is possible, I go live with 3 OI servers on Monday <gulp> ;) ).
>
> Currently the dependency chain of the packages, is erm to be polite utterly
> broken... Before we can consider a stable build, we have to fix that a text
> install takes 2.6GiB and includes so much stuff that doesn't belong. Trying
> to remove via pkg gets you nowhere as it horrible chained together
> incorrectly. It's a security nightmare, the only way I currently feel safe
> is that I have a zone that faces the world because zones (for some reason)
> install much more striped down installs.
>
> IMHO First thing should be making a minimal server install, debootstrap
> minimal. Get a unix base system, IPS package manager and wget and the rest
> can come later. TBH the install a new zone gets is more like the default
> install should be imho.
>
> Then have a number of repositories with different classes of supported apps,
> Primary being your list and with critical fixes etc. and then secondary
> being less supported apps.
> Your proposal to focus on a small set of apps is correct imho, new users to
> OI stable will be early adopters almost by definition, so by being honest
> and saying OS is stable and great and so are these major programs, but not
> everything out there is to the same level, we encourage champions to take
> their favorite program and get it on the major supported list.
>
> Also a smaller core will make the illumos switch faster, I'm personally not
> sure if stable should become before illumos integration. OI on illumos works
> now, with locales being the major issues (being worked on), it doesn't feel
> right to call OI stable without it using (even a WIP) the base that it
> requires going forward (OI on ON isn't really stable as it's a EOL, which
> implies an unstable future).
>
> As you're worried about missing the window, as OSol users migrate to linux
> or FreeBSD IMHO that is more a perception issue. OI website appears very
> slow moving, even dead. Bringing some life there may help that issue, call
> the WIP stable build, Early Adopter build or something like that, post EA
> new builds once a week on the front page. Get silly screen shots of shell
> doing zfs, or apache configuration files, all completely useless BUT
> highlights that look this thing is real and running apps you, as a IT geek
> are wanting to run...
>
> As a production OI deployer, I really care about
> 1) Minimal install with just the programs I want,
> 2) Critical fixes for the OS and those apps if I use the package system.
> 3) A safe build environment, as there is a fair chance I'll be building app
> myself at this stage (I use a separate machine for this as the safest way :)
> )
> 4) Something that will upgrade nicely for the say 3 years. For OI that
> scream illumos IMHO
> 5) A community with nice central info pool, currently the OI wiki and
> webpages doesn't feel like a community, wiki access is restricted, so not
> encouraging writing up notes and most of the useful information  isn't on
> there anyway. Half the time you end up on Oracle web pages, which makes you
> wonder if this is a real OS.
> 6) Security info and concerns, from articles to hardening the OS to using
> VMs (Xen, Zones, Virtual box?) to isolate components. Probably just an
> extension of the wiki and/or blogs but I'm sure some of the in the trenches
> guys would be happy to write a few articles on how we got OI onto the front
> line and in use.
>
> Hope this doesn't sound negative, as mostly I agree with your proposal (only
> thing I really disagree on is non illumos). At the moment OI is very much a
> shadow of OSol choices, which I don't think apply here, for it to go stable
> it needs to shake of its old masters clothes and choose its own route.
> Starting with a small server distro that just happens to have a huge repo of
> other apps including desktop, allows it to find a niche and then expand out
> from there. As a server (especially a storage server) OS imho its second to
> none :)
>
> Bye,
> Deano
> Deano at cloudpixies.com
>
> -----Original Message-----
> From: Alasdair Lumsden [mailto:alasdairrr at gmail.com]
> Sent: 14 January 2011 20:36
> To: Discussion list for OpenIndiana; OpenIndiana Developer mailing list
> Subject: [OpenIndiana-discuss] Proposal: OpenIndiana Stable Branch
>
> 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.
> _______________________________________________
> OpenIndiana-discuss mailing list
> OpenIndiana-discuss at openindiana.org
> http://openindiana.org/mailman/listinfo/openindiana-discuss
>
>
> _______________________________________________
> OpenIndiana-discuss mailing list
> OpenIndiana-discuss at openindiana.org
> http://openindiana.org/mailman/listinfo/openindiana-discuss
>