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

This entry is part of OpenSolaris JeOS (Just Enough Operating System) Prototype workshop.

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.

---

Approach

Use advanced features of OpenSolaris (new) ZFS root to create one OpenSolaris OS install profiles for experimenting with multiple bootable OpenSolaris 200811, 200906 setups on one OS installation to speed up Light Weight Server Oriented OpenSolaris Image creation knowledge gain processes.

Target is, list of needed/not needed packages in our OpenSolaris JeOS configurations which can be used in future in Automated Installer to install OpenSolaris 200811, 200906 release JeOS.

This approaches was developed part of WebSynergy Server Oriented Virtual Images Creation

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.

OS Reduction Methods

To get reduced OpenSolaris JeOS image we can use this 3 method:

• Reconfiguration – Don’t change size/packages, just change OS runtime configurations and behavior
• Targeting – Selecting most influencing configuration ( by size and/or number of packages and/or by category) – passive approach
• 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 have broken 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 :

1. 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)
2. 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
3. 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.

OpenSolaris BE is part of Snap upgrade feature Snap Update PDF

Multiple Boot Environments

We will like to have this test OpenSolaris Boot Environments, individual BEs are independent, we can have all of them in one installation !!!

JeOS Level	BE name	Source	Result	JeOS Creation Approach
L0	OpenSolaris	Full LiveCD base	Full LiveCD base GUI	Original
L0	osol0906gui	Full LiveCD clone	Full LiveCD base GUI	Original
L1	osol0906cli	Full LiveCD clone	Full LiveCD base CLI	Original| – Reconfigured
L2	osol0906size	Full LiveCD clone	Reduced LiveCD installation	Remove – Targeted (User – Size)
L4	osol0906rgui	Full LiveCD clone	Reduced LiveCD installation	Remove – Targeted (No GUI Env – No GUI pkgs)
L5	osol0906redu	Full LiveCD clone	Reduced LiveCD installation	Profile – Uninstall Rest
L5	osol0906inst	Empty BE	Fresh bootable installation	Profile – Fresh Install

Separation of OS and User Data Locations

In standard OpenSolaris 200811 and 200906 configuration OS stuff is under /rpool/ROOT and User stuff is under /rpool/export

zpool list
NAME    SIZE   USED  AVAIL    CAP  HEALTH  ALTROOT
rpool  15.9G  3.27G  12.6G    20%  ONLINE  -
zfs list
NAME                     USED  AVAIL  REFER  MOUNTPOINT
rpool                   3.77G  11.9G  46.5K  /rpool
rpool/ROOT              2.77G  11.9G    18K  legacy
rpool/ROOT/opensolaris  2.77G  11.9G  2.77G  /
rpool/dump               511M  11.9G   511M  -
rpool/export             600K  11.9G    19K  /export
rpool/export/home        582K  11.9G    19K  /export/home
rpool/export/home/osol   562K  11.9G   562K  /export/home/osol
rpool/swap               512M  12.4G    16K  -

Managing Boot Environments with beadm tool

OpenSolaris Boot Enviroments are ZFS ROOT Clones and Snapshost managed by beadm tool.

beadm
Usage:
beadm subcommand cmd_options
subcommands:
beadm activate beName
beadm create [-a] [-e non-activeBeName | beName@snapshot]
[-o property=value] ... [-p zpool] beName
beadm create beName@snapshot
beadm destroy [-fF] beName | beName@snapshot
beadm list [[-a] | [-d] [-s]] [-H] [beName]
beadm mount beName mountpoint
beadm rename beName newBeName
beadm unmount [-f] beName

See also man beadm

General Recommendations and Issues

Use right OpenSolaris build

Use a final 200906 build Iive-CD media

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:

pkg uninstall -nvr SUNWevolution-data-server | egrep "^pkg" | wc -l
46 - packges are to be removed !!!
Most package will be GUI Gnome relaed ones:
pkg uninstall -nvr SUNWevolution-data-server | egrep "^pkg" | grep gnome | wc -l
32 - Gnome packages are to be removed !!!

So if you wan to uninstall SUNWevolution-data-server do it by install GMOME, so this will be scenario L3 !!!

Core System Packages need to installed in order

We need to force it manually , this is a side effect of missing Core System cluster.

XARGS is limited to 2048 chars

This make a small complications when we want to process more packages at once to parse all dependencies in one run.

Solution is to use -t visual parameter and control, if we don’t see wrap to more lines.

Installed PKGs consistency vs User land Consistency

If you process SUNWevolution-data-server and will remove all this Gnome stuff, even when you don’t break PKGs dependencies and you still can boot.

Is you JeOS setup usable from User Land point of view – tou remove some GUI components, but you din’t control this process ?!

Human Readable Packages Categories

Packages categories are not in repo YET , Currently categories are hard coded into Package Manager package

When PM is installed at:
/usr/share/package-manager/data/opensolaris.org.sections
/usr/share/package-manager/data/opensolaris.org
In PM devel reposiotry at:
In the PKG gate look under:
src/gui/data
http://src.opensolaris.org/source/xref/pkg/gate/src/gui/data/opensolaris.org
http://src.opensolaris.org/source/xref/pkg/gate/src/gui/data/opensolaris.org.sections

I generate single line list of packge swith their categories with this command and attach it for B100

cat /usr/share/package-manager/data/opensolaris.org | sed -e 's/\[//g' | sed -e 's/\]//g'| \
sed -e 's/category =//g' | awk 'BEGIN {RS=""; FS ="\n"} {printf "%-16s %s\n", $1, $2}'>cat-b100.lst

Note: This feature is added into iPKG version included in upcoming 201003 release.

Meta Packages Cluster and Incorporations

See some info from Architects working on SWI SW IPS packaging and IPS mutli-platorfm support:

Packaging Best Practices – Dependencies

Packaging Best Practices – Clusters and Incorporations

In OpenSolaris 200906 are there is this 2 system Clusters in installed image:

 babel_install
slim_install

Note: Slim_install is rudiment from CD image creation and must not be present of installed image, see issue bellow

In OpenSolaris B111 there is main Incorporation with main distro dependencies called entire, for user level JeOS we will keep this package and so a default set of dependencies.

Leverage past experience with JeOS from OSOL200805

In Amazon EC2 I was creating a procedure how to determine list of needed packages and how to from OS remove rest of them

Determining OpenSolaris 200805 CLI JeOS RNJS conf (List of packages)

Creating OpenSolaris CLI JeOS RNJS by Uninstall (rest of packages)

Note: Important specifics of Amazon EC2 images is then they can’t be updated with pkg image-update command or other ways to new kernel version

EVAL Deep Dive into IPS and OpenSolaris installation procedures

3398 slim_install should be removed from the CD during finalization

We will get Caiman (OpenSolaris ) installer source, so w can use some installer tools

Get mercurial SW

pkg install SUNWmercurial
DOWNLOAD                                    PKGS       FILES     XFER (MB)
Completed                                    1/1     312/312     1.00/1.00
PHASE                                        ACTIONS
Install Phase                                340/340
PHASE                                          ITEMS
Reading Existing Index                           9/9
Indexing Packages                                1/1

Get IPS and installer related SW gates

zfs create rpool/export/repos
mkdir /export/repos/inst
cd /export/repos/inst
hg clone ssh://anon@hg.opensolaris.org/hg/caiman/slim_source
hg clone  ssh://anon@hg.opensolaris.org/hg/caiman/caiman-docs
mkdir /export/repos/ips
cd /export/repos/ips
hg clone ssh://anon@hg.opensolaris.org/hg/pkg/gate