Jayakara Kini's Weblog: Jayakara Kini's Weblog

Did anybody happen to see this recent flag day message on OpenSolaris?

http://www.opensolaris.org/os/community/on/flag-days/pages/2009070201/

Solaris now understands Logical Drives in Extended Partitions.  That means, Solaris can now be installed in extended partitions and it can also mount them.

Most of the systems comes pre-installed with Windows leaving only extended partitions for multiboot.  Linux supported extended partition for a long time.  This feature should have been in Solaris by the time the OpenSolaris distro was released.  Well, better late than never..

Got a new Dell XPS 1530 laptop.  Looks sleek.  186GB, DVDRW, 4GB RAM, 9 Cell Battery, soft touch keys for eject and volume control.  Pre-installed with Windows Vista 32 bit. It also has a feature called MediaDirect.  This can play music, video, pictures and presentations from the media in the dvd drive or from the user's Document's directory in the Vista partition without booting the Vista Operating System!

MediaDirect is actually running a scaled down version of Windows XP.  Mediadirect still uses the display, harddrive, CPU and memory.  Its not going to save much on power.  But is surely a quick way and convenient way access the files.

MediaDirect is indeed a nice feature.  But it has some limitation:

• It requires a primary partition at the beginning of the disk of around 47MB.
• It requires a logical partitions of around 2GB in an extended partition at the end of the disk.

That takes away 2 partitions.  Vista takes one more and Dell Recovery of around 10GB takes one more partition.  Thats it.  No space to install OpenSolaris.  Unfortunately, you cannot install Solaris in an extended partition (as of now).

Blowing up and reinstalling everything, including OpenSolaris, would screw up MediaDirect.  Pressing the Media direct button would give the grub option or boot Vista directly or switch the functionality of the power and mediadirect buttons or completely destroy everything on the disk!!

I and two of my colleagues experimented with different methods of installing.  Our requirements were:

• Multiboot with grub
• Vista and Solaris in primary partitions
• Extended partition for additional OSes (like Linux)
• Do not care about Recovery Partition
• MediaDirect must still work

This is the sequence of operation that has to be followed in this order *only* to meet the above requirements:

• Partition with MediaDirect CD
• Re-partition with Gparted
• Install Windows Vista
  
• Install MediaDirect inside Vista
• Check Vista and MediaDirect operations
• Install OpenSolaris
• Check Vista and OpenSolaris operations through grub menu
• Check MediaDirect with the button
• Install Additional drivers and applications through the CDs provided

Well, the Code For Freedom (CFF) contest is finally over. The results are posted on the CFF site. The grand prize winners will be awarded at Sun Tech Days in Hyderabad on 29^th Feb 08 by Ian Murdock. Congratulations to all the winners. Thanx to everyone who contributed. Without all these contributions, this contest would not have been successful.

I was tracking the contributions to the OpenSolaris technology. The load in the initial stages of the contest was negligible. But during the end it reached a peak. I used to stay awake till 3am chatting with students answering their queries. Here is a screenshot of one of my gmail chat session. In the last two weeks of the contest, more than 50 contributions were submitted. The last contribution to OpenSolaris was submitted on 23:57 on 14^th Feb 2008 IST! Just minutes before the contest ended.

Many students have committed to continue the contributions to OpenSolaris even after CFF. This contest has definitely raised the interest level of the students across India to contribute to open source projects. I believe, its just the beginning ...

Its not just the students, even we have learnt a lot while conducting this contest. We have received a number of feedback on what went well and what could be improved. Many people are asking if we'll have CFF next year. Well, I don't know. AFAIK, no decision has been taken in this regard. I hope it is...

Always...

• send mails from email ids registered in SCA.
• use SCA number in every mail you send to request-sponsor.

Before picking up a bug...

• confirm if a bug is already being sponsored on
  http://opensolaris.org/os/bug_reports/request_sponsor
• ensure that 'Responsible Engineer' field of the bug is empty
• avoid selecting RFEs if you don't want to work on ARC cases. ARC cases are a good learning experience, but it takes time. And we have little time for CFF to end.

As soon as you pick up a bug send a mail to request-sponsor alias. The mail should contain:

• Name and email id of the contributor. If two of you are working, give both names and email ids.
• The bug number and synopsis
• Category and subcategory of the bug (this is FYI to sponsors)
• A two or three line description of the bug
• A tentative date (in dd-mmm-yyyy country neutral format) when you'll submit the fix.
• Your SCA number(s). If you don't have a SCA, then mention that you have started a process to get a SCA number.
• Do NOT request for a sponsor. This mail is only an intent-to-work mail. A sponsor should be requested when a fix is ready. If a sponsor has special interest in the bug, then even such requests could be picked up by the sponsor.
• Check http://opensolaris.org/os/bug_reports/request_sponsor.  This page should be updated with your request in a couple of days.
  

After selecting a bug...

• do not expect that a sponsor will pick up your request or help you with fixing a bug just because you sent a intent-to-work mail
  
• develop a fix for the bug, on your own.
• compile the source with your fix and generate a binary
• test your binary (this is very important)

When a fix is ready send a mail to request-sponsor alias. The mail should contain:

• Name and email id of the contributor. If two of you are working, give both names and email ids.
• The bug number and synopsis
• Category and subcategory of the bug (this is FYI to sponsors)
• The fix. The fix should be sent in one of the following formats:
  

An attachment of 'diff -u <oldfile> <newfile>'
A link to webrev or diff (-u) output uploaded to http://cr.opensolaris.org
'diff -u' output inline with the mail if the fix is just a few lines of change.

• Mention any testing that you have done. This can include sample output of command or the steps you followed to test your fix and its results.
• Your SCA number(s). If you don't have a SCA, then mention that you have started a process to get a SCA number.
• Now you can request for a sponsor. Please be patient while your request is picked up.

Note:

• All mails sent to request-sponsor alias are NOT eligible for CFF contest
• All fixes integrated before 14th Feb are eligible for CFF.
• Fixes submitted before 14th Feb but which are not yet integrated will be reviewed. Only those fixes which gets approved for quality will be eligible for CFF (even if they don't make it to OpenSolaris for some reason). So, make sure you have tested your fix properly and mentioned the test results in your mail to request-sponsor while submitting the fix.
• If you have submitted a fix for any bug, then make a submission on CFF site NOW!
  Do now wait for your fix to be integrated or someone to tell you that you are qualified.  Make a submission now and we'll determine the quality.  Remember, make the submission ONLY if you have submitted a fix.
  
• Do not request for a sponsor when you have picked up a bug.

Common mistakes:

• Using unregistered email ids.
• Not mentioning SCA numbers in the mail
• Not giving the details (full name, email id, SCA #) of partners
• Not mentioning existence of a partner while sending a mail to request-sponsor
• Selecting wrong bugs (already sponsored, already fixed, too complex etc)
• Copy pasting from others mails without editing the details properly
• Requesting a sponsor without a fix

Please refer to my earlier blogs as well:

http://blogs.sun.com/jkini/entry/tips_for_opensolaris_cff_participants

http://blogs.sun.com/jkini/entry/contributing_to_opensolaris

BTW, did you know that Campus Ambassadors have have access to more details about the bugs than what is presented on opensolaris.org?  So, if you need more info about a bug, contact your CA!

There is little time now.  The contest is closing on Feb 14th.  Rush your entries and your submissions.  And just because there is little time don't compromise on quality either!

All the best!

I read a blog on how to live upgrade. Tried it out. And it did not work .

Fortunately, you can always fall back to the pre-upgrade environment, which is still intact.

I deleted the new boot environment and followed the steps again. It failed again. I searched for a few more blogs. They also had similar steps. Followed them. Failed again .

What was I not doing right???

I took the help of some Live Upgrade experts and they told me I was missing one important step: Install the live upgrade packages SUNWluu SUNWlur SUNWlucfg from the new boot environment (iso/cd/image) before using any of the lu* commands.

I had the new iso anyways. I lofi mounted it and installed the new packages from the iso:

# lofiadm -a /space/iso/snv75/sol-nv-b75-x86-dvd-iso
/dev/lofi/1
# mount -F hsfs /dev/lofi/1 /mnt
# cd /mnt/Solaris_11/Product
# pkgadd -d . SUNWluu SUNWlur SUNWlucfg

Then followed the rest of the steps and the live upgrade when through without any issues .

I had live upgraded my system earlier. That time, I had not installed the LU packages from the new boot environment. But still the live upgrade went through fine. I had some issues with the grub entries which I corrected. Now I realize that I was just lucky to get away with a minor issue that time.

I also found that many people try out live upgrading at a much later time. This should be decided while installing Solaris itself as you need a separate slice of same size as the root slice.

With the newer projects on upgrading and installing, I believe Live Upgrade is getting extinct...

Here are some tips for OpenSolaris CFF participants: 

• Read how to contribute to OpenSolaris at: http://blogs.sun.com/jkini/entry/contributing_to_opensolaris
• Install OpenSolaris and download the source *before* you submit a request for a mentor.  Look at the source and get familiar with building one command (not the whole source).
• Its not necessary to build (nightly) OpenSolaris to start with.  First identify the bug/RFE.  Then decide whether a nightly is required or building one part is sufficient for the code changes being made.  Your mentor can help you with deciding this part.
  
• Confirm that the bug is not being worked upon by another contributor at http://opensolaris.org/os/bug_reports/request_sponsor/
• There is a very good chance for an RFE to require a PSARC case.  PSARC case has a longer process which will delay the integration of your changes into OpenSolaris.  On the contrary, bugs have a negligible chance for a PSARC case.  I'm not discouraging you to pick up RFEs.  Just setting expectations.
  
• If the code contribution is made before Feb 14 2008, then it'll be considered for the CFF contest.  It need not be integrated by that time.
  
• Note that http://bugs.opensolaris.org is synced with the Sun Internal bug database every day.  There  have been issues with the syncing process which has caused contributors to pick up the wrong bugs.  Confirm with your mentor that the bug/RFE can be worked upon before you start.
  
• Send a mail to request-sponsor alias as soon as you pick up a bug saying you are working on so-and-so bug/RFE and will come back with your contribution within so-and-so date.  This will be updated on the '.../request_sponsor' page.  This will prevent another contributor from picking up the same bug/RFE.
  
• Testing the code changes is *mandatory*, even for trivial changes.  When you ask for sponsorship, your sponsor will ask you this.  If you have not tested, then you'll be asked to do it.  This will delay your fix being integrated.
  
• You can look at the source on opensolaris.org and come up with a fix for simple and trivial fixes.  But, again, you *must* compile and test it.
  
• Mention a long term email id while sending your SCA.  Currently there is no procedure to change your email id once a SCA is assigned.  It could be difficult to change it later.  If you know your college/institution email id is temporary, get a public domain email id and use that.
  
• Mention your SCA number in all mails sent to request-sponsor alias.
  
• Mention the dates in country neutral format: dd-mmm-yyyy.  US follows mm/dd/yyyy format while India follows dd/mm/yyyy format.  This can cause confusion.
  
• All the diffs submitted to http://cr.opensolaris.org or through an attachment must be context diffs or unified diffs. i.e. it should be diff -c or diff -u output.  A plain diff will not do.  You can also attach/upload webrev output which will be more elaborate and suitable for reviews.
  

All the best!
 

Whenever you need to use scp to copy files, it asks for passwords. Same with rsync as it (by default) uses ssh as well. Usually scp and rsync commands are used to transfer or backup files between known hosts or by the same user on both the hosts. It can get really annoying the password is asked every time. I even had the idea of writing an expect script to provide the password. Of course, I didn't. Instead I browsed for a solution and found it after quite some time. There are already a couple of links out there which talk about it. I am adding to it...

Lets say you want to copy between two hosts host_src and host_dest. host_src is the host where you would run the scp, ssh or rsyn command, irrespective of the direction of the file copy!

1. On host_src, run this command as the user that runs scp/ssh/rsync

   $ ssh-keygen -t rsa

   This will prompt for a passphrase. Just press the enter key. It'll then generate an identification (private key) and a public key. Do not ever share the private key with anyone! ssh-keygen shows where it saved the public key. This is by default ~/.ssh/id_rsa.pub:

   Your public key has been saved in <your_home_dir>/.ssh/id_rsa.pub

2. Transfer the id_rsa.pub file to host_dest by either ftp, scp, rsync or any other method.

3. On host_dest, login as the remote user which you plan to use when you run scp, ssh or rsync on host_src.

4. Copy the contents of id_rsa.pub to ~/.ssh/authorized_keys

$ cat id_rsa.pub >>~/.ssh/authorized_keys
$ chmod 700 ~/.ssh/authorized_keys

If this file does not exists, then the above command will create it. Make sure you remove permission for others to read this file. If its a public key, why prevent others from reading this file? Probably, the owner of the key has distributed it to a few trusted users and has not placed any additional security measures to check if its really a trusted user.

5. Note that ssh by default does not allow root to log in. This has to be explicitly enabled on host_dest. This can be done by editing /etc/ssh/sshd_config and changing the option of PermitRootLogin from no to yes. Don't forget to restart sshd so that it reads the modified config file. Do this only if you want to use the root login.

Well, thats it. Now you can run scp, ssh and rsync on host_src connecting to host_dest and it won't prompt for the password. Note that this will still prompt for the password if you are running the commands on host_dest connecting to host_src. You can reverse the steps above (generate the public key on host_dest and copy it to host_src) and you have a two way setup ready!

DTrace requires root privileges to run. DTrace is non-destructive i.e., you can't do any harm to the system or process that you are tracing. Letting normal users to run DTrace can be a security issue as that user can get any information on the system or of another user, including passwords.

If you are using a laptop or a personal desktop, then enabling DTrace for yourself could be very helpful. Especially if you are developing and debugging an application. This can done by a simple command:

# usermod -K defaultpriv=basic,dtrace_proc,dtrace_user,dtrace_kernel <login_id>

This command has to be run as root. It updates the /etc/user_attr file with the privileges given here. By default, a normal user only has the basic privilege. But this is not mentioned in the /etc/user_attr file. If any additional privileges are added, then only these privileges will be applicable. Thats why the basic privilege is a must when adding additional privileges. Otherwise the user will not be able to login next time. Note that the user may have to logout and login again for the privileges to take effect.

To know more about what each privilege allows you to do, run:

# ppriv -lv dtrace_proc,dtrace_user,dtrace_kernel

Try the same with basic privilege as well.

To remove the privileges don't give any option to defaultpriv in the above command.

Who can become OpenSolaris contributor:

A contributor can be an individual or a company/institution. A copyright in the name of the contributor is placed into the files contributed by the individual. If its a company/institution, then the company/institution will hold the copyright.

How to become OpenSolaris contributor:

Register at opensolaris.org Link: https://www.opensolaris.org/register.jspa

Download Sun Contributor Agreement (SCA). The agreement is available on http://www.opensolaris.org/os/about/sun_contributor_agreement.

Print the Sun Contributor Agreement, fill it and sign it. Follow the instructions on the above link to submit it.

You'll be given a SCA number and your email address will be added to request-sponsor@opensolaris.org. You can also join this alias by sending a blank mail to request-sponsor-subscribe@opensolaris.org.

That's it. You are a contributor.

What to Pickup:

Go through the Communities and Projects page. Follow up on the archived mails, join the discussions to know what everyone is working on. Give feedback. Throw ideas. Comment on the design. Select an area of interest. Start working on it. Check out the documentation on http://docs.sun.com. All the man pages, exported interfaces, configurations (with examples) are available here.

What to contribute:

You can contribute any code that you have written. For e.g. a new driver that you have written, a fix for a bug that you have discovered, an enhancement, new features, anything that you have written.

Some Bugs and Request for Enhancements (RFE) in OpenSolaris are opened up for the community. These are marked with the keyword oss-bite-size. The list of this bugs can be found on http://www.opensolaris.org/os/bug_reports/oss_bite_size. Select a bug you wish to work on. Note that you select one which has a empty "Responsible Engineer" column. Even if a Bug/RFE is marked oss-bite-size, an engineer inside Sun might have picked this up for different reasons (it is part of a project, required for another fix to work, high impact, etc).

You can also search for a bug/RFE of your interest on http://bugs.opensolaris.org and choose to work on it even if its not marked oss-bite-size. These bugs are a bit more complicated though.

Note that the request for sponsorship is sent after the contribution is ready. It has happened earlier that a contributor sends a request for sponsorship while somebody inside Sun is already working on it. With increasing number of contributors, it might as well be another contributor in future.

The status of all contributions can be tracked from http://www.opensolaris.org/os/bug_reports/request_sponsor. All the bugs/RFEs for which a fix has been submitted by an OpenSolaris contributor has a keyword request-sponsor in it.

When you pick up a bug/RFE please not the following things:

• The Responsible Engineer field of the bug must be empty

• request-sponsor keyword should not be present in Keywords field. If this keyword is there, then that means another contributor is working on this bug/RFE.

• http://src.opensolaris.org/source lists many source gates. These are project source gates. The main Solaris gate is onnv. Some of the bugs are against the project gates and some are against open sourced software which is just bundled with Solaris. Make sure the fix for the bug you pick up goes into the onnv gate.

How it works:

Once you have selected a bug/RFE to work on, send a mail to request-sponsor@opensolaris.org stating that you want to work on this bug. Also give a reasonable time frame by which you'll come back with the contribution. This is required because the opensolaris.org page does not track contributors who are currently working on a bug. It only tracks already submitted contributions. One of the members of the alias will verify if another contributor is working on it or any Sun Engineer is working on it. This will prevent duplicate efforts and any disappointment later.

After you are ready with your code change, do a thorough testing. Testing is necessary even if its a small and obvious change.

When you are ready with your contribution, send a mail to request-sponsor@opensolaris.org asking for sponsorship. One of the sponsors would pick up your request and work with you to get your contribution integrated into OpenSolaris. The sponsor will keep you updated on the progress.

request-sponsor alias contains all the contributors and all the *sponsors*. The sponsor's job is to mediate with the contributor and commit the contributor's source into OpenSolaris. No, its not monetary sponsorship. A list of sponsors is available at http://www.opensolaris.org/os/community/on/crt/advocates.

Things to keep in mind:

• License. Your code should not violate any of the license terms. I'm not a license expert to elaborate on that.

• Please remember that Solaris promises backward compatibility. Any shell script or program written for earlier versions of Solaris MUST work on later versions. Changing the output format of a command, the behavior of its options, systemcall parameters, any documented behavior (manpage, docs.sun.com), is a no-no. Well, this can be done to a minimal level by filing an ARC case.

• Any new code/modifications that you submit must be tested, even if it is an obvious and simple modification. The sponsor would be verifying your test results as well as performing more tests which are required before integration.

What you need:

• Solaris

Solaris Express:

This is the official distribution of OpenSolaris. Download this from http://www.opensolaris.org/os/downloads. The starter kit media can be ordered to your postal address from http://get.opensolaris.org.

Solaris Express is available for both sparc and x86. Only 64 bit kernel is available for Sparc version. Solaris sparc does not support 32 bit kernel anymore. The x86 version of Solaris Express can be run in both 32bit and 64bit.

This page lists some more utilities along with it. Solaris and Sun Studio is free. Sun Studio contains the compiler and IDE. If you want to modify Solaris, you'll need it.

512 MB and 5GB is required to install Solaris. If you want to build, modify and test and keep aside another 10GB.

You'll need an account with Sun Download Center. The account is free as well.

LiveCD (optional)

Another way is to install from Belenix (http://www.belenix.org). This is the live CD version and can be installed from the LiveCD itself. Belenix runs 32bit kernel and is available for x86 platform only. Belenix can also be downloaded from a torrent. Nexenta and Schillix are also LiveCD distributions of Solaris(x86).

• Sun Studio

If you are compiling Solaris source then you'll need this. This can be downloaded from the above link for Solaris or from http://developers.sun.com/sunstudio/downloads/index.jsp. Sun Studio contains compilers and a basic IDE as well. For working on Solaris code you'll need the compilers but the IDE is not necessary. If you are developing your own software, then you can use gcc or NetBeans IDE.

• Some more download links

Solaris download link and documentation: http://opensolaris.org/os/downloads/on

Solaris source and BFU archives: http://dlc.sun.com/osol/on/downloads/current

Solaris source mercurial repository ssh://anon@hg.opensolaris.org/hg/onnv/onnv-gate.

Solaris and other supporting software downloads: http://opensolaris.org/os/downloads

Note that while both Solaris and Sun Studio is available for free, the support service is not free.

The BFU archives are generated for every build and can be used to upgrade a Solaris system. Make sure you read the documentation on how to BFU before using it.

Reference:

The OpenSolaris Developer's Reference Guide is a must for those who work in kernel land (drivers, modules) or on OpenSolaris source itself. Its a good reference if you are developing your own application as well.

Check out the Open Solaris User Groups on the Projects page. Go through the mail archives and post your questions here for any help.

Building Solaris: http://www.opensolaris.org/os/community/on/devref_toc/devref_4/ and http://www.blastwave.org/articles/BLS-0050/index.html (with screenshots)

Additional Softwares for Solaris: http://www.blastwave.org.

Man Pages and Documentation: http://docs.sun.com

Happy Contributing

OpenSolaris is now one year old!  We have integrated more than 100 contributions from 25 community members.

My first step into OpenSolaris was when I joined the tonic project in Nov 2004.  This project was to scrub the source for Copyright.  This was one tedious task.  The project team developed a tool to automate the checking of Copyrights.  This tool would check for similar codes in different files and also list the copyrights associated with each file.  The output of this tool had to be manually verified.  This was done by volunteers and I was one of them.  Yes, even though there was a tool, we had to manually verify every line.  The tool was used only to make the work of volunteers a bit easy.  All these was tracked through a twiki web page.  Reports were generated from these pages and the automated tools used to update the pages too.  Until then, I didn't know the power of twiki.  Now, thats a different story.  This went on till mid Feb 2005.

Then Sun created history when it open sourced Solaris on June 14 2005!

I got involved again when I signed up as a OpenSolaris Sponsor.  No, I don't give out money for working on Solaris. (Thats the common question I get to hear.)   My responsibilities as a Sponsor is to work with the external contributor, follow the integration process and finally integrate his/her code into Solaris.  At present, external contributors cannot directly integrate their source in Solaris.  But I believe there are plans to change that in future.

I have met many people/students who seem to be very excited when I talk about OpenSolaris.  They seem very much interested in contributing too.  But there aren't any contributions coming from them.  Its like climbing up a stair and then not taking the last step.  Whats missing?  I'm not sure.  I hope they come out of the box and jump at this wonderful opportunity.

BTW, have you seen the Contributor Awards that was announced for OpenSolaris anniversary?

Anyway, that was an exciting year.  I believe we'll have many more contributors and integration in the next year!  All the best for OpenSolaris!!!

Logical Domains support was integrated into Solaris Nevada on May 16th.  With Logical Domains (LDoms), it would be possible to simultaneously run more than one instance of Solaris on one box.

LDoms is supported only on sun4v systems (with UltraSparc T1 processors).  So, why is only sun4v systems supported?  Thats because the UltraSparc T1 processor has Hypervisor support built in.  The firmware on sun4v systems also support it.  At this time the there are only two sun4v models: T1000 and T2000.

LDoms support for Solaris 10 is being integrated sometime in the next month.  After that both Solaris 10 and Solaris Nevada can be run simultaneously on one system.

To use the LDoms features:

• Upgrade the firmware to the latest release.
• Upgrade the Nevada release to build 41 or later (build of 17 May 2006 or later would also do)
• Install the LDoms Manager (code name: Zeus) which is bundled separately.

At the time of writing this, the firmware and the LDoms manager is not available outside Sun.

I have some doubts here for which I did not find any documentation:

• Does LDoms require at least one CPU per domain or can one CPU run multiple OSes.  If it does require one CPU per domain, then T1000 will not be able to run LDoms as it has only one CPU?
• Is there is a limit on the number of domains that can be run on a box if there is no requirement of dedicated CPUs for a domain?
• When will the new firmware and LDoms manager be available for all?

Well, I guess these would be answered soon.  Anyway, the possibilities of its usage, combined with Zones, is numerous.  I have been amazed by some of our customers who use Solaris in ways we did not even think is possible.  With LDoms and Zones, I'm sure it'll keep happening...

Open Document Format (ODF) is now an ISO standard (ISO/IEC 26300).

Currently, ODF is supported by Openoffice,  Staroffice, Koffice, TestMaker and IBM Workplace.   The best thing is, anybody can write their own application.  So, I won't be surprised to see more of such applications in future.

Microsoft has also submitted Open XML for ISO standards process.   The advantages of ODF is well known now and many organizations and governments are adopting it.   I wonder how Microsoft will push the adoption of Open XML.....

This wikipedia article has a good summary of ODF: http://en.wikipedia.orgwiki/OpenDocument
This link has good resources about ODF: http:/ww.spreadopendocument.org

FOSS.IN was held at Palace Grounds in Bangalore from 29th Nov to 2nd Dec 2005.  Sun was a platinum sponsor for this event.

We were giving demos on the new technologies of recently open sourced Solaris.  The demos were on Dtrace, ZFS, Zones and SMF.  We also had demos on Glassfish which is an open source application server and Netbeans which is an open source IDE.  We had a demo on Belenix which is a live cd of the latest Solaris.  We were giving away free Belenix CDs and Solaris 10 DVDs.  We had not planned for Looking Glass demo, but we setup a demo station as many delegates were asking for it.

The crowd at Sun's stall was overwhelming.  The volunteers had a difficult time to handle all the delegates.  We had a large number of delegates registering for Bangalore Open Solaris User's Group (BOSUG) and some of them were interested in being part of Open Solaris development
too.


I found a couple of other stalls there quite interesting.

One stall was from Spike Source.  They bundle a whole bunch of open source software, test it and make them work together.  This whole bundle is  available for free.  Patches are released periodically and are also free.   The charge is for service which include providing a relief before the next scheduled release of the patch.  Their solution is not available on Solaris, but they are already planning to do so in the near future.

Another stall was of project Phoenix.  This is a open source product written mainly in Python.  This software is used to conduct physics experiments.  The software and the circuit diagrams are availble for free on their website.  Users can add their own experiments.  This is very useful for schools and colleges.

Some of the stalls did not have any open source related products.  I guess they were there just for marketing their products.

This event left all the organisers and volunteers exhausted.  But hey! We got a free t-shirt :-).

To better understand the dependencies in SMF I had written a shell script to print the dependency tree of a given service.  Recently I started learning perl and decided to rewrite the script in perl and at the same time enhance it a bit.

The script is available at following two locations:
http://blogs.sun.com/roller/resources/jkini/svcstree
http://mediacast.sun.com/details.jsp?id=3849

Run the script without any arguments and it'll dump a help text.  Rest should be quite easy after that.  Let me know if it isn't.  This is my first perl script.  I'm sure there is plenty of scope of improvement...

Solaris 9 introduced a new feature called wanboot.   Wanboot is used to install over the network.  But unlike inetboot, you can boot over the internet and not just your Local Area Network.

   Solaris 9 requires a boot CD to use this feature.  That is you need to place the boot CD in the client's drive when you want to install Solaris 9.  But that is not necessary for Solaris 10.

   I created a simple setup of wanboot server and client. The setup took some time as I had to read the document at every step. I skipped the security related steps as my server and client were in a LAN.  And it worked beautifully.

  Wanboot requires more setup than inetboot.  But has its advantages in a LAN too.  For eg.  inetboot is based on RFCs that assumed standard Class A/B/C networks.  Of course, inetboot has been modified to consider CIDR.  But there are some topologies where inetboot fails to work.  Wanboot does not depend on the topology.  As long as the wanboot server is accessible,  there are no issues.  And if you are setting up wanboot inside your LAN, you can skip the security related steps.

   See  http://docs.sun.com/app/docs/doc/817-5504/6mkv4nh4g?a=view for documentation.