OpenSolaris JeOS Prototype (Part 11: Reduced Setups in BE)

Abstract

Most modern mature OSes distributions allow users to tune set of installed packages by simple procedures like selecting install profile Basic CLI server or Rich GUI Workstation and many of them offer even more precision profiling to better suit user OS usage profile – like for example profile optimized by size and amount set of packages in CLI server mode to get close to ideal OS profile for Virtual Images creation.

This document present approaches and procedures how user can easily create this experimental prototypes of OpenSolaris install profiles – set of OS packages for OpenSolaris 200811, 200906 and prove then they are good fit for various user requirements.

Approaches to OpenSolaris JeOS creation

We define our target as Reduced OS image – User Level OpenSolaris JeOS , in similar way as use in Creating OpenSolaris based JeOS (For Amazon EC2), any of our JeOS configurations must be still usable for Administrator logins and Administrator must be able to process in JeOS enviroment diversity of tasks. This is main difference from approaches targeting primary very strong OS Minimalization, when main target is Back-Box like Appliances to only get minimized OS environment to just execute not interactively some specialized tasks – like Automatic Installer focussed enviroment for Network Installations, this sort of JeOS don’t have requirement of any sort of rich Administrator Environment/Access enviroment.

OS Reduction Strategies

There are 3 main reduction strategies, we can use with standard OpenSolaris Live CD GUI installation as starting point to create our Server Oriented OpenSolaris JeOS image:

Reduce booting time

Reduce size of image

Reduce number of packages

There is an obvious limitation then these optimization targets can be archived only for distribution image, due to dependencies handled in external OS Repositories outside of our control for already released OS version, user can initiate just by installation of one package trigger massive packages installation driven by enforced dependencies, so most reduction effort will be lost in this situations. For deep minimalization we need target packages and dependencies refactoring, this process is currently out of scope if this effort.

Profiling – Try to define needed set of OS functionality (what set of packages we need) – active approach

Many times you need to combine this approaches and process them in loops to get final results. One challenge is then OpenSolaris have very strong dependencies enforcement in OS Repositories and in pkg tool, is hard evaluate scenarios what if I select/de-select this (set of) package(s), I will demonstrate it later in general issues section.

Variety of JeOS images

From JeOS variety we see possibility to have these levels of JeOS based images and these possible gains:

Level

Name

Main Method

Booting speed

Resulted Size

No of Packages

Comments

L0

Original FULL GUI

Clone

0

0

0

Original Live CD or other default profile image

L1

Original FULL GUI in CLI

Reconfiguration

++

0

0

Just disable GUI and services

L2

Reduced GUI

Targeting

0

++

+

Remove most top sized user pkgs

L3

Reduced GUI in CLI

Targeting + Reconfiguration

0

++

+

Remove most top sized user pkgs + CLI mode

L4

Remote X inn CLI (No GUI env)

Targeting GUI apps

++

++++

+++

Not GUI envs, only GUI libs if needed for installed OS pkgs

L5

Pure CLI

Profiling

+++

+++++

+++++

No X or GUI libs at all

—

——-

———

——-

——–

——–

These bellow is out of scope, because they will required special creation procedures

L6

(Over) Minimalized CLI

Profiling

???

???

???

Very small user space, like for Black Box Virtual Applainces

L7

Hardcore CLI

Profiling

???

???

???

This is special purpose image and can havebroken depndecies – non upgradeable, like Live CD installer stuff

L8

Tarball based CLI

Profiling

???

???

???

This is special purpose image , like root in Live CD or FLASH disk

Yes, JeOS is not only about OS reduction, its about to match OS functionality to hosted applications , there can be packages in OpenSolaris REPO to add, or even ones with don’t have there and they need to be added like JDK 6 ???

Right JeOS setup

How to prove then we have right JeOS setup ?

We need to ensure then created JeOS comply with this main requirements :

Created JeOS is consistent from OS point of view, pkgs and OS image can be refreshed, updated, installed/removed and so on (all OS Admin tools are present and are functional)

Crerated JeOS is complete from Admin point of view, like there is one instance of tool for common Admin tasks (like one editor) , Admin can login remotely login , have persistent configurations, stress on security

Crerated JeOS is suitable for running selected application , run functional test on hosted app(s) to be sure, then JeOS is feature complete form app point of view

Main Idea – Use different Boot Environments in single image

OpenSolaris have possibility for layered applications installations (ones which don’t depend on OpenSolaris IPS repository) to separate OS and App install trees. In this manner we can have different configurations of OpenSolairs boot environments (BE are basically independent ZFS roots) to access
one instance of installed application. This way we can easily test different OS setups in single image by simple OS reboots.

General Recommendations and Issues

Use right OpenSolaris build

Use right OpenSolaris repository

Some operation will need to access IPS repository on network, to make access after we can use official internal OpenSolaris repository and content mirror.

In case of network stability issues you can create you local IPS content mirror.

Use right Virtualization Technology Setup

Disk performance is a key for JeOS creation, OpenSolaris use ZFS so you need memory for ZFS cache (1GB) and Virtual disk configuration must be , if possible preallocated drive. ZFS copy on write so performance can be heavily affected my virtual disk fragmentation.

Also don’t forget then if Virtual Disk drives si not installed , disk performance can be terrible.

Hint: If you are short on memory, disable start of GUI

Cache into file outputs, if you will reuse same input

Instead of:

pkg list | cmd
pkg list | cmd
pkg list | cmd

Use file cache:

pkg list >/cache.lst
cat cache.lst | cmd
cat cache.lst | cmd

Always Check What, If to check dependencies sprawl

Example can be “What,If” a simple command to uninstall all evolution packages on simple L2 Scenario: