[oi-dev] SVR4-based illumos distro WAS: how to fix support for system_locale in sysidcfg for non global zone installation

[Alasdair Lumsden]

(Moving this to oi-dev)

On 27/05/2012 16:47, Jim Klimov wrote:
> 2012-05-27 4:15, Alasdair Lumsden wrote:
>> As project lead I can tell you that we won't be doing SPARC
>> unless someone comes along and takes ownership of that project,
>> and we definitely won't ever be doing SVR4 packaging as long
>> as I'm project lead.
>
> "No Bart, you cannot have the cookie now after all.
> Your mother made a very loud point!" (C) The Simpsons

Sorry :-) I subscribe very strongly to the design principles of IPS 
which came about due to shortcomings in SVR4. IPS may have some 
implementation weaknesses, but it admirably solves the problems it set 
out to and in my experience works very well indeed.

When people pine for the days of SVR4 I just get annoyed, because it's 
trying to undo progress. Yes, IPS requires retooling and relearning, but 
ultimately IMHO it's very worth it.

There are a number of blog posts on this topic by Stephen Hahn:

https://blogs.oracle.com/sch/entry/observations_on_packaging

(Click next through the blog posts as there's quite a few)

> I think, supporting the minimal-interruption *migration*
> from legacy (SVR4) systems would be more important to me
> than an SVR4-based distro, especially if that option is
> so firmly fought against.
>
> However, comfortable migration "should" support running
> legacy local (fullroot) zone roots provided as-is (i.e.
> without IPS packaging), even if not directly supporting
> installation of such (SVR4) zones with OI.
>
> Do you loudly object even to that?

No, and if a sound implementation was presented for us to integrate I'm 
sure we would.

However as unpaid volunteers working on a community project we need to 
stay focused on what's important, and right now that's things like:

1. Getting our /stable release out
2. Sorting out /experimental and our release engineering processes
3. Updating software, fixing security holes, fixing bugs


> Then to clarify:
>
> 1) SVR4 support: as I see - at the moment SVR4 are installable
> on OpenIndiana "as is", including the pre/post-scripts, which
> is good for those legacy users who can't/won't migrate for
> whatever their reasoning is. Is this going to remain in place,
> or are there plans to rip out pkgadd,etc. and still claim
> being "the upgrade path"? ;)

There are no plans to rip it out.

> One limitation that I see however, is that an SVR4 package
> installed in GZ does not get auto-installed/updated in LZ...
> Oh well, that's likely an IPS brand thing...

That's by design. SVR4 package installation is there as a compatibility 
thing and not for general systems management. IPS branded zones are 
effectively isolated containers with their own private package sets. A 
fresh zone gets a minimal set of software.

> 2) Is there a documented and/or scripted upgrade path for
> users of SVR4-based systems to export-import their zones
> into an IPS system (i.e. use same-named SUNW* package names
> if available via IPS and update them from an old SXCE/Sol10
> image to the current OI baseline upon zone import)?
> Something simple, working in-place on (a clone of) the old
> zone dataset, and that would not require reinstalling the
> whole set of zones and manually migrating the settings, data,
> installed third-party programs (packaged or standalone)?

That would be a huge amount of work. Things have changed so very much 
since Sol10 and SXCE that there is no 1:1 direct mapping any more and 
most software would just break horribly.

There are however Solaris 10 branded zones. Potentially that brand could 
be adapted to SXCE. The problem is that SXCE was a moving target with 
lots of builds.

> To the very least, it would suffice if the SXCE zones just
> worked "as is" in OpenIndiana, allowing for quick upgrades
> of the host OS and little downtime for tasks-in-zones being
> upgraded later - alas, they don't, even after some hammering.

Again, you want an SXCE implementation of Solaris 10 branded zones.

The main problem is that the core system software (like the ifconfig, 
zfs, etc) commands inside the zones have to be kept in sync with the 
global zone. I am not sure how the S10 brand achieves this.

But once it's done you're left with this aging security nightmare 
frankenstein of a zone, so why bother?

People are better off investing the time in properly migrating their 
legacy apps and data into modern zones. That way you get the latest 
software with the latest security updates, in a far more supported fashion.

I appeal to your logical side.

> 3) Regarding sparse-root zones: does the IPS theory firmly
> forbid the sparse-root zones with their benefits of faster
> provisioning, smaller footprint on disk/RAM/cache, fast
> propagation of OS-wide updates, and whatever else people
> liked about them? Or is it possible to tame IPS code into
> compatibility with the concept of sparse read-only rootfs
> (/usr, /lib...)?

As far as I know sparse zones support was never a design goal. Oracle 
employ a team of people to maintain IPS and what you're asking for would 
be a major deviation from their work, effectively a fork. If you're 
volunteering to quit your job and work on it full time then perhaps it 
might be viable, but otherwise it's probably not going to happen.

The easiest route to sparse zones on OI is to do a SmartOS-style branded 
zone, which combines a zfs template supplying a skeleton filesystem 
(/etc, /var etc) and loopback mount /usr from the global zone, perhaps 
with a filter so only a defined list of files get passed through.

The user could then run whatever they want in the Zone, for example 
pkgsrc or s10-userland.

Ultimately we have to be pragmatic with the resources we have. We can't 
be all things to all people and we have to focus on what matters to our 
wider user base.

> PS: What is so inherently bad about SVR4 which is not bad
> in DEB, RPM, etc.? :)

To be honest I hate all 3 of those package managers. I'm a massive IPS 
convert. It just feels designed - like ZFS. It's packaging done correctly.

Like any system, IPS has drawbacks (it requires a lot of CPU grunt and 
network resources), but these are not an issue in a modern datacenter 
environment. We selected to use it for our business on Solaris 10 and 
SmartOS and have been enormously pleased with the results:

http://s10.pkg.ec/
http://smartos.pkg.ec/

We have this deployed on hundreds of customer zones and it makes 
administrating them a breeze.

What I dislike most about SVR4 isn't the package format itself, but the 
people who whinge about wanting it back.

It's gone, what we've got is better, time to move on. Sorry for the pain 
but you can't make an omelette without breaking a few eggs.

Cheers,

Alasdair