Saturday Oct 03, 2009

Skype on OpenSolaris! The last missing part it's real!

What are you doing if the road is blocked? Probably trying to find a detour.

So what if the Skype is not working natively on OpenSolaris? Here is the recipe which will allow you to use your Skype account, send messages and do VoIP with video support.

First of all you will need to get the flash plugin for your Firefox. It's very easy, just follow the blog entry from John Rice.

Secondly simply use the IMO website and allow flash plugin to access your microphone and camera (you will be prompted when you will start some VoIP chat).

The only thing I had to do was to increase Recording volume using Volume Applet and the one from the flash plugin settings -right click on the VoIP window, when you are talking to someone and choose "Settings..." from the flash plugin menu.

Thursday Apr 09, 2009

Broken OpenSolaris? NEVER!

If for some reason your OpenSolaris installation is broken or you want to have an exact system on many computers here is the recipe, which I have successfully tested yesterday!

What you will need?
- SSH access to working OpenSolaris - thanks Bob. ;)
- Some free time (copying took around 1h for me, while I was still able to use my OpenSolaris box!!!)

Let's start
1. On your computer choose some unique zfs filesystem name. To check for the names currently used on your system, type the following command in the terminal:
   $ /usr/sbin/zfs list -rHo name rpool/ROOT
   I will use rpool/ROOT/opensolarisbob as it was not listed

2. Make sure you know the IP address of your box:
   $ /usr/sbin/ifconfig -a
   In our case it's

3. Log to Bob computer (
   $ ssh -l username

4. List all BE's and choose the one which you want to copy:
   bob$ /usr/sbin/beadm list -a
   In our case we will use the one:

5. From the rpool/ROOT/opensolaris filesystem create snapshot which we will name mysnapshot:
   bob$ pfexec /usr/sbin/zfs snapshot \\

6. Send the filesystem to our computer using ssh and login name migi:
   bob$ pfexec /usr/sbin/zfs send \\
   rpool/ROOT/opensolaris@mysnapshot | ssh \\
   migi@ \\
   "pfexec /usr/sbin/zfs recv rpool/ROOT/opensolarisbob"

7. At this point you should see new be on your computer:
   $ /usr/sbin/beadm list

8. Activate the new BE:
   $ pfexec /usr/sbin/beadm activate opensolarisbob

That's All. At this point the system is the same as on the Bob's computer including users and passwords.
If you want to restore your users and passwords you can mount the new BE and copy over or edit few files.
I did something else by simply "restoring" my user "migi" to the new BE by:
pfexec /usr/sbin/beadm mount opensolarisbob /tmp/opensolarisbob
pfexec grep migi /etc/passwd >> /tmp/opensolarisbob/etc/passwd
pfexec grep migi /etc/group >> /tmp/opensolarisbob/etc/group
pfexec grep migi /etc/shadow >> /tmp/opensolarisbob/etc/shadow
pfexec grep migi /etc/user_attr >> /tmp/opensolarisbob/etc/user_attr

Of course if you can't login to your broken OpenSolaris you could use liveCD, import pool and do the same trick, please let me know if you need such instructions.

By the way it's pretty amazing that copying 3GB of the data took around 1h:

View Larger Map

Thursday Mar 26, 2009

What can you expect from Package Manger for 2009.06

For the past few months Package Manager was under heavy development. Even if you will not notice many of the changes and bug fixes trust me - it's faster, more stable and way more polished then it was ever!

There are few things which you will notice for sure. John already wrote in his blog about Start Page and Web Installer, so I will write about remote search and startup performance improvements. Of course there are plenty of other things worth mentioning, but I want to focus only on those two, so the blog entry will be relatively short.

Remote search
A picture tells a thousand words:

What does it mean to perform remote search and why it was introduced?
We do have per repository view. To find a packages based on their names and descriptions, which aren't in the currently visible repository we had to switch to another repository, perform the search and so on if the package was not found. That was fine, because the number of repositories was limited. Currently more and more repositories are out there, so some mechanism of finding packages across all repositories had to be introduced and this is how remote search came to the live (with a little more time spent by few people which were designing and developing this feature. From the GUI side Padraig O'Briain wrote most of the things - great work!). So switching to the "All Repositories Search" mode allows to find a package and install this package, even if you were in different repository view. Going out from the "All Repositories Search" is very simple, you will find a way... this will restore your previous view.

Startup performance improvements
We did use few dtrace scripts to find out what is happening, and how to improve startup performance, but the major change is the local cache.

Using python with DTrace probes really helped us to identify bottlenecks and functions on which we should focus more. For example to see what is happening when the package is being installed, we were starting the dtrace script entry_entry.d as follows:

pfexec ./entry_entry.d __init__ __operations_done

Starting Package Manager and installing some package after running above command will produce in nice format the number of calls to the functions and time spent in those, once again the power of DTrace is amazing! I will write about this a little bit more, because it's interesting (at least for me) how we were able to connect all parts of automated tests with DTrace performance scripts.

Dumping the data models using cPickle and allowing to use this data together with per repository data model reduced Package Manager startup to around 3 seconds for! I won't write how long did it take before if someone had few repositories configured... At the moment from time to time, when the Package Manager will discover that the cache is out of date, then you will see loading packages progress, but it should be way faster then it was in 2008.11.

ENJOY installing your packages!

Tuesday Jun 17, 2008

OpenSolaris: HowTo Install Sun Studio + Common Build Environment (CBE)

Few steps to install Sun Studio and Common Build Environment on OpenSolaris box.

Those little steps will explain how to install Sun Studio and Common Build Environment on top of OpenSolaris 2008.05. Please note that some of those instructions normally should be different, but little bugs, which currently exists caused need for those changes in this tutorial.

Why you will need this?
The Sun Studio together with CBE will allow to build lot's and lot's of new packages/software to your lovely OpenSolaris and if you have a little knowledge you might want to create your own packages and share them with other people!

What you will need?
1. Internet Access.
2. Few cups of coffe/tee, since this will take a while, depending on your connection speed.
3. Good mood, as this was tested Today and may be different in couple of weeks, so if something will break don't panic! You have ZFS snapshots, so you will not break your system :-)

First you need to fully update your OpenSolaris 2008.05. Without this, probably things will not work, so to fully update your system please follow those steps as standard user:

$ pfexec pkg refresh

After this step you should follow those commands (as shown on below picture):


$ pfexec pkg install SUNWipkg

$ pfexec pkg image-update

The below steps are related to the bug described HERE and MUST be done, otherwise you will NOT be able to boot to the updated OpenSolaris.

$ pfexec mount -F zfs rpool/ROOT/opensolaris-1 /mnt

$ pfexec /mnt/boot/solaris/bin/update_grub -R /mnt

$ pfexec reboot

The below screenshot, shows the actual steps. The black-marked commands are the ones which you should type (before this please remember to type pkg refresh) :)


Those steps will install all required packages


$ pfexec pkg install SUNWcvs SUNWsvn SUNWarc SUNWj6dmo \\
SUNWj6dev SUNWj6dmx SUNWj6dvx SUNWj6cfg SUNWj6rtx \\
SUNWj6man SUNWgnu-automake-19 SUNWgnu-automake-110 \\
SUNWaconf SUNWmercurial SUNWlibtool ss-dev SUNWsfwhea \\
SUNWhea SUNWxwinc SUNWxorg-headers SUNWi2cs SUNWgpch \\
SUNWgnome-common-devel SUNWgmake SUNWbison SUNWflexlex

The below picture is actual screenshot from the above operation:

The first thing you need to do is to add the "Software Installation" profile for your user, to do so, please follow the commands, replacing USERNAME with your actual username:

$ su

$ usermod -P "Software Installation,Primary Administrator" \\

Secondly you need to get CBE sources from HERE.
Then unpack:

$ bunzip jds-cbe-1.6.0-i386.tar.bz2

$ tar -xvf jds-cbe-1.6.0-i386.tar

Now you need to apply one small, so please download it and place in the directory one level up from jds-cbe-1.6.0 directory, so simply stay in the directory where you have been unpacking jds-cbe-1.6.0-i386.tar.bz2.
To apply this patch, please type the following command:

$ patch -p0 < cbe-install.diff

If this will not work, you can download patched cbe-install script and replace the one from the jds-cbe-1.6.0 directory.

Now just go to the jds-cbe-1.6.0 directory:

$ cd jds-cbe-1.6.0

and install stuff:

$ ./cbe-install

You will get few questions, so for all yes/no, please answer yes. For the question about patch to the C compiler, please type the following path:


All those steps are visible on the screenshot:

That is it! If you would like to make a use of CBE, you can watch simple tutorials describing howto build some packages (especially part 2 is made for this purpose):
Create your own OpenSolaris IPS repository in a Weekend!

If something will go wrong during installation, and you will hit similar stacktrace to the one shown below, simply add the package name to the pkg install command by hand and it should go further. This is related to bug 2229

Tuesday Jun 05, 2007

How open is open?

Few days ago I have joined to the Polish OpenSolaris Portal.
One of the project aims is to make polish translation of the documentation and locales for OpenSolaris Project.

Before commiting any code I was asked to sign SCA, which was not a problem, because as an Sun Employee I don't have to go through this process, but I have realized, that people outside the Sun, which are contributing to any of the OpenSolaris project have another thing to do.

I know that this is the "only" one time process, but personally I would not send signed agreement to any company, just to submit my patch to the project.

Creating artificial (from developer/my point of view) barriers simply discourage people from the community. And this is a barrier in my opinion. We are great at making the complicated things really easy, but... vice-versa.

I am very happy that few people joined to my project (JPack), but I am a little afraid of telling them to sign SCA: "Hello my friends, I have a little surprise for you. If you want to send me a patch or commit a code, you need to send an agreement!"




« August 2016