BeleniX 0.8 Beta1 available via the Network Installer

After Belenix 0.8 Alpha which included exciting features such as the Google Widgets, Webkit, and KDE 4.2.4 — all built with GCC 4.4.0 in addition to Gnome 2.26, BeleniX 0.8 Beta1 is now available with improvements (bug fixes and functionality) to the KDE 4.3.1 desktop and other apps and new package additions. Several patches/fixes for various packages were taken from the Fedora Core 11 repository.

You need to use the Network Installer in order to install this 0.8 Beta1 Release. The Network Installer will not touch your current environment in any way. It creates a new Boot Environment and installs into that. Your current environment remains as the default one.

You can see the full announcement here: http://www.belenix.org/content/BeleniX-08-Beta1-available-Network-Installer

 

KDE 4.3.1 on BeleniX Screenshots

I am plugging in some obligatory screenshots of my Vbox VM running BeleniX 0.8 Alpha:

The KDM Login screen with Oxygen-Air theme

The KDE4 Splash screen

The KDE 4.3.1 desktop

The Kontact Addressbook application

The KBreakout Game

 

Func on OpenSolaris

Func or Fedora Unified Network Contrtoller is a Fedora project that introduces a new framework to easily and securely control one or more machines remotely using either a programmatic or cli interface: https://fedorahosted.org/func/

Func is a lightweight but IMHO well-designed framework written entirely in Python. From my initial experience it is extremely powerful and it’s modular nature allows for easy extensibility for a wide variety of tasks. You can not only execute commands remotely but can develop custom modules to return information from the remote machine in a structured way. Check out the website for all the interesting details.

Being written in pure Python Func is also inherently portable. The few Linux-isms reside in the startup init scripts. Having found a sudden interest in the project I decided to make Func work on OpenSolaris and happy to note that I have an initial version that works and provides a few basic extension modules for ZFS, SMF and process info. You can download and install the packages in the below order:

http://www.belenix.org/binfiles/python25-pyopenssl.pkg
http://www.belenix.org/binfiles/certmaster.pkg
http://www.belenix.org/binfiles/func.pkg

You also need to have the SUNWPython25 package. There is a little bit of initial setting up to be done as described in /usr/share/doc/func/README.opensolaris. This initial port, provides SMF manifests and startup scripts for func agent and certmaster, usage of a func daemon user and RBAC profile, a basic set of opensolaris modules (http://www.belenix.org/binfiles/func-opensolaris-modules-0.1.tar.gz)  and a proof of concept integration with Solaris RBAC Authorization framework. I have written a simple Python interface to libsecdb that exposes the chkauthattr function in Python. While Func itself has an ACL mechanism that allows the client to controls access to modules by the master it should be worthwhile to integrate that mechanism with the RBAC authorization framework on OpenSolaris. This will allow network-wide Func user privilege setting.

The Func packages will be available in the BeleniX repo. In the meanwhile I have submitted the initial port into Sourcejuicer for the /contrib repo. Going forward there are lots of things to be done including possibly having OpenSymbolic to run on BeleniX. One of the things that are at present not easily done on Func is streaming monitoring information from client to server, for eg. streaming the ouptut of a running DTrace script. Since Func communications are encrypted it is possible, as a simple mechanism, to distribute one-time/short-lived symmetric keys and set up a second TCP connection for streaming data. This can also be done for remotely effecting a ZFS send/receive between two clients (or minions in Func parlance).

 

Gcc 4.4.0 in BeleniX

Gcc 4.4.0 release is now available in BeleniX package repository trunk at pkg.belenix.org. It built without issues out of the box and as a test I was able to build BOOST 1.38.1 and a patched Qt4 (From the KDE Solaris project) without any trouble using this new compiler.
You can pull the latest SFEgcc package using spkg from BeleniX trunk.

Update: I forgot to mention that the updated Gcc spec file is here. The spec file is setup to build Gcc using SUN Studio 12. In generall the BeleniX spec files can be found here.

Update 2: I rebuilt Gcc 4.4 with the ClooG and Ppl dependencies so that the new Graphite framework is enabled. I played around with the various flags in trying to build Python 2.6 and got very good results vis-a-vis SUN Studio 12. I got comparable or better results using Pybench esp. in 64Bit mode with Gcc4 compiled Python 2.6. In adition I tried the new ‘profile-opt’ make target in Python 2.6 that does profile-driven optimization with Gcc. The 64Bit python binary built using Gcc4 + loop optimizations and Profile is 27% faster than the 64Bit SS12 built binary (without profile opt). The 32Bit binary is about 2% faster. Using loop parallelization via OpenMP might have helped further but 32Bit Python dumps core when built with -ftree-parallelize-loops=2 -march=pentium4.

If you are using another OpenSolaris distro and still want to try out this new Gcc 4.4 you can try running this little script to download and install SFEgcc and it’s dependency packages from the BeleniX repo. Be warned that I have not actually tested the script. All the spec files can be found in BeleniX sourceforge repo.

 

Indian Tricolour on the Moon

Here is something that all Indians everywhere on the planet is bound to be proud of. The Moon Impact Probe made a textbook landing on the Moon delivering the Indian flag onto the lunar dust of yore for the first time. I was elated seeing the picture of the jubiliant beaming scientists at ISRO (Indian Space Research Organization) in today’s edition of The Hindu.

The Register has a story on this with usual bunch of clueless whiners dirtying the comments section! Space research and exploration has lots of spinoffs and benefits for the society at large.

 

My workout proposal for FOSS.IN

My proposal for a Workout session (kind of hackathon) during this year’s FOSS.IN has been accepted on a preliminary basis. The shortlist of accepted talks, workout sessions is yet to come out. My proposal deals with creating a small utility for the Caiman Installer being used in BeleniX.

At present the installer can detect windows partitions and automatically create entries in Grub to allow easily booting Windows in the OpenSolaris + Windows dual boot scenario. However there are a few limitations with the existing piece. It can only scan primary partitions, it blindly creates boot entries for every windows partition and does not detect the C: drive, it does not detect other OS-es like Linux.

My proposal deals with scanning the entire partition table including logical drives and detecting both Windows and Linux instances. A framework for scanning the raw partition table is already present in the useful “prtpart” utility that I wrote sometime back and being bundled in BeleniX. In addition the intention is also to try and detect actually bootable ones, i.e. Windows C: drive and Linux root. This means that the utility needs to be able to interpret filesystems on the raw partitions. The idea is to leverage the basic filesystem reading code in Grub to analyse the partitions.

The advantage with this project in that it needs very little, if any, familiarity with OpenSolaris. Rather one should be familiar with Grub and Linux filesystems. So this is an easy way to get a hang of doing development on OpenSolaris.

Of course remember that this is a preliminary heads-up and the final list is yet to be out (so things can change).

 

RE: Blastwave Saga Continues

I read the latest update on Benr’s Blog and see the this saga of disagreement as something similar to the classical Generation Gap. Solaris 8 is indeed ancient and lacks many features that characterize developments at recent times. It simply no longer makes sense to build on Solaris 8 and run on Solaris 10 and much less OpenSolaris just because Solaris supports it.

New features and architectures in more recent platforms cannot be harnessed like for eg. HAL, File Event Mechanism for FAM, more updated Xorg and libraries, accelerated graphics, ZFS, SMF, newer SUN Studio compilers and so on. I had tried to use Blastwave KDE quite sometime back and gave up after a month because the non-antialised fonts were downright ugly. IMHO it simply does not make sense to keep breaking our collective heads on an 8 yr old platform when the rest of the world is thinking 8 yrs into the future!

However I do believe that it is much better to arrive at a compromise solution. For eg. one can have two deliveries one for Solaris 8 and 9 and one for Solaris 10 and OpenSolaris. The older platform will see a lesser amount of software naturally only having the most necessary stuff that those users need and the newer platforms characterized my more and newer stuff. In a way it is actually happening with the separated OpenCSW and Blastwave efforts, but it would have been much nicer had this separation not happend at all.

I personally (and a lot of people I know) live on OpenSolaris and do not even bother with Solaris 10, but that’s a different story.

 

OpenSolaris Community Innovation Awards

The winners of the first OpenSolaris Community Innovation Awards have been announced. Check out the announcement here: http://www.opensolaris.org/os/project/awards/. A hearty congratulations to all of the winners. The awards are well-deserved and are some very interesting projects.

It makes me proud to see BeleniX RAM based boot in the list – a great effort by Sham. BeleniX continues to be a crucible of innovation on OpenSolaris, fuelled also in no mean terms by the extremely active BOSUG community. We sure need a special Beer party for BOSUG.

 

Moon is the limit for RHEL!

While scanning for some information I landed on the following Redhat Knowledgebase article: http://kbase.redhat.com/faq/FAQ_85_7936.shtm

Apparently there is nothing wrong and it talks about the largesmp kernel and supported CPUs etc. All is fine till you look at supported number of CPUs table and esp. the “Certified” column. 64-way x86 SMP and 256-way Itanium SMP, cough cough cough. To the best of my knowledge Nehalem “is going to” bring 16-core and 32-core SMP on x86 next year and HP’s SuperDome 9000 is probably the largest Itanium system which is 128-core.

Looks like someone has super duper systems on the Moon that are yet to come down to Earth! Apologies if I am wrong though!

 

Using the BeleniX Constructor

Many of you following the OpenSolaris distribution should have heard about the Distro Constructor toolkit that allows one to build the LiveCD distribution of OpenSolaris. The Distro Constructor has it’s roots in the Live Media Kit which in turn was a re-whack of the toolkit used to build BeleniX 0.4.4.

After OpenSolaris 2008.05 was released I decided to pick the Distro Constructor toolkit available at that time and re-whack it into the BeleniX Constructor. There are several differences in the way LiveCD ISO construction is done in BeleniX and in the OpenSolaris distro. Given the way Distro Constructor is evolving today these differences will increase going forward both at the architecural and feature level. These considerations necessitated creating and maintaining a separate distro construction toolkit for BeleniX’s requirements. One of the most important differences is the way the miniroot is constructed. in addition BeleniX still uses SVR4 packaging. The differences are sufficiently fundamental to make it well nigh impossible to use Distro Constructor customizations to accommodate BeleniX requirements without patching the former.

Today the BeleniX Constructor lives in an SVN repository here: http://belenix.svn.sourceforge.net/viewvc/belenix/trunk/apps/belenix_constructor/

There is a README file in that directory that explains a bunch of things including various configuration settings. The top level directory structure and source code components is as follows:

belenix_constructor
packages	Contains miscllaneous packages required for LiveCD at present this only has a Licensing package.
src	Contains all the source code for BeleniX Constructor. bootcd_skel Replacement customizations for existing files in the base OS. These are customizations needed for the LiveCD. postrun_scripts Distro Constructor weirdness needed due to a combinaton of GNOME crappiness and IPS no-scripting limitation. Will be removed shortly. archive_paths Pathname patterns that are not needed by LiveCD but needed in installed system. These are packed up tightly in a 7zip archive. build_dist.bash Main script that orchestrates the entire build. build_dist.lib Library of functions used by the above script. dist.conf Empty config file with comments explaining various settings. microroot_list Top-level pathname prefix list for including in the microroot. mkrepo Script to pre-generate an SMF repository for the LiveCD. pkg_retrieve_ips.lib Script that can populate an alternate root from an IPS repository. pkg_retrieve_svr4.lib Script that can populate an alternate root from a directory containing needed SVR4 packages. The package list is in test_data/pkgs.txt. proc_toc.pl A perl script that can process a TOC-style SVR4 package Cluster. Explained later. rev_file.pl A perl script to reverse a text file. usr_microroot_files A short list of pathnames under /usr needed to be present in the microroot.
test_data	Contains base configurations for the BeleniX Constructor.
tools	A few tools used by constructor that are also useful by themselves.
usr	A remnant from some changes in the earlier Distro Constructor. Will be removed shortly.

This is in essence a very high level view of the overall organization. Now if you wish to play with this utility can build custom LiveCDs, there are few steps:

1. Check out the BeleniX Constructor tree: svn co https://belenix.svn.sourceforge.net/svnroot/belenix belenix/trunk/apps/belenix_constructor
2. Next you need to set aside space for storing the packages and distro construction area. At least 15GB of space is needed.
3. Lets assume that you are storing all the packages in “/export/pkgs” and “/export/livecd” is your distro construction area.
4. Now you need to download all the required packages listed in “belenix/trunk/apps/belenix_constructor/test_data/pkgs.txt”. That file is in a SVR4 cluster definition format. It is very simple to understand once you take a single look. All the packages are available from “http://pkg.belenix.org/belenix_0.7.1/”. The packages are compressed using 7Zip. So you’d have to extract them as well and convert from datastream format to filesystem format. This is essentially a small loop in a shell script and is left as an exercise for the reader. Of course I will work up a tinny script and post it in a subsequent blog entry. Obviously these packages have to go into “/export/pkgs”
5. Now it is time to configure the Constructor:  cd belenix/trunk/apps/belenix_constructor/src; cp ../test_data/test1.conf .
6. Edit test1.conf and setup the entries. The file is profusely commented and the settings are easy to understand. At the minimum you will have to set:
   • TEST_DATA – This should contain full path to the test_data directory referred to above.
   • DIST_MICROROOT_LIST – This contains full path to the belenix/src/belenix_constructor/src/microroot_list file. This is essentially a set of directories and patterns that are included in the ramdisk.
   • DIST_METACLUSTER – This defines the cluster name as specified in pkgs.txt. Leave this unchanged.
   • DIST_PROTO – This contains the full path to the proto or distro construction area. In our example this is “/export/livecd.
   • DIST_ID – Name of the distro
   • DIST_ISO – Full path to where the LiveCD ISO should be created. In our example this should be “/export/$DIST_ID.iso”
   • DIST_PKG_DIR – Directory where all our SVR4 packages are stored. In our example this is “/export/pkgs”
7. Once configuration is done. You are ready to fire off a build thus: cd belenix/trunk/apps/belenix_constructor/src; ./build_dist.bash ./test1.conf

Obviously drop an email off to belenix_discuss __at_ opensolaris (_dot) org if you face problems.