01 March 2007

Looking for Solaris USB Tips?

If you're looking for information about USB Device support on Solaris, then I have good news for you! The Solaris Ready USB FAQ posted on SUN's website probably has the answers you are looking for. Recently, I had a problem getting my external USB / Sata Hard Drive Enclosure working and found the USB Storage section of the FAQ invaluable.

24 February 2007

An alternative to packages

I have a set of software I want to provide for the Solaris 10+ community (more on that in the coming weeks). However, the existing solutions for distributing software for Solaris (and other UNIX like systems in general) are sadly lacking. It might seem backwards to some, however, I feel that before I begin the porting and distribution effort for this new software I need a good way to distribute it that makes it as painless as possible for all parties involved. Ease of maintenance, as a developer, is especially important to me.

With that in mind, I am researching different options for easily distributing software to Solaris users. Note, I said users and not administrators, although this can just as easily apply to them as well. Users want to run their software with as little pain as possible, and developers need a way to distribute the software that users want to run with as little pain as possible. That requires a distribution system that meets certain goals:
  • Anyone can install software
  • Anyone can distribute software
  • It doesn't matter whether the software is installed or not
  • Shared downloads
  • Good security
All of these goals are important. In the past, other projects such as blastwave, SUN Freeware, OpenPKG and others have provided solutions that work great for administrators, but aren't so great if you're not the system administrator. Thankfully, we don't have to sacrifice the goal of allowing users to run the software they want or any of the other ones listed above. Not only that, we already have a solution that achieves every one of those goals: The Zero Install System.

The project leader, Dr. Thomas Leonard, has been very helpful in assisting me with these efforts and welcomed contributions. The past week or so, I have been looking into what changes are necessary to allow Solaris to be a fully supported and operational platform for the Zero Install System. Since Zero Install is written in python, it is already fairly portable by nature.

I have been working through the test suite included with Zero Install making whatever changes are necessary for it to pass all applicable tests and I am just about finished. I have not had to make many changes due to the excellent work performed by the Zero Install team and its contributors. So far, all of the changes I've done are found in the unpack library.

While the Zero Install System is not yet fully functional, you can be certain that I will be doing whatever is needed for that to happen. I will post an announcement here once I am certain that it is fully functional, and have a sample software package available for testing. Meanwhile, I suggest reading the following material related to Zero Install and installation / packaging systems:

14 June 2006

Happy First Birthday OpenSolaris

It is hard to believe that a year has already passed. So much has happened in the OpenSolaris community since the project was first officially launched. The most important of these things to me have been: charter establishment, release of binaries for libm, sccs, and make, release of the solaris packaging software and code, the establishment of the desktop and laptop communities, the release of a ndis wrapper and configuration tool, and the selection of a distributed source code management system.

Looking back, I was able to submit several small patches that were later integrated into the OpenSolaris project. While these patches were trivial in nature, each bit was an expression of my appreciation for the contribution that SUN has made to the community. In addition, it was a joy to work with people such as Dan Mick and others at SUN that helped integrate my changes. The community and people inside of SUN have provided a veritable cornucopia of useful resources. Some of the resources and people that helped me over the last year include:

* Dan Mick's blog postings, such as a posting about diagnosing kernel troubles. Dan also provided extensive personal assistance that helped get me through several technical hurdles, and the code integration process.

* Bryan Cantrill's blog with heaps of postings about DTrace.

* Ben Rockwood's blog with several introductions to Solaris methodology, as well as an important resource for Solaris enlightenment addicts.

* Alan Hargreave's blog. Chock full of reflections on Solaris/OpenSolaris, life, technical information, and most important of all: brewing information.

* Jim Grisanzio's blog, for a great perspective on the community, and for being a righteous defender of all that is just.

* Glynn Foster (aka Gman), whose tireless assistance with JDS was quite helpful.

* Dennis Clarke, who has provided a significant amount of resources through blastwave.org, to ensure that community members have access to a high quality resource for software. Not only has Dennis provided this service free to the community for years, but he has also provided resources for developers to build and provide that software to the community.

Those are just a few examples of great resources and people that are part of the OpenSolaris community.

In the near future, I hope to pick back up some of my patches that I had to previously abandon due to a sudden career change and past schedule demands for University. I've been writing code since I was a child, and programming for almost eighteen years. Yet, after all of these years, I still enjoy doing so. My contributions to the OpenSolaris project have been a labor of love, and I look forward to contributing more over the years to come.

05 August 2005

vim for the blastwave impaired

For those of you that wanted vim packaged for x86 without using blastwave. There is hope:

http://icculus.org/~eviltypeguy/pkg/vim/

You can grab the pkg along with everything build-system or source-related that I used from there. The simple instructions if you want to rebuild it your own way:


  1. Download the vim-6.3.tar.bz2 and all the other files at the URL listed above, extract the vim tarball to a build directory of your choice.

  2. Place the "copyright", "pkginfo", and "vimtopkg" files in the newly extracted directory.

  3. Edit pkginfo with your editor to match your personal info.

  4. Do a configure with something like what is below from the top level directory adding or disabling features as you please, replacing the --prefix with one of your own choosing.:
    ./configure --prefix=/opt/BCvim --with-features=huge --with-compiledby='my @ email address' --enable-perlinterp=no --enable-pythoninterp --enable-tclinterp --enable-cscope --enable-workshop --enable-multibyte --enable-xim --enable-fontset --with-x --enable-gnome-check

  5. Perform the make from the top level directory:
    make

  6. Run vimtopkg from the top level directory:
    ksh ./vimtopkg

  7. Tell it you want to use the pkginfo file.

  8. Be amazed as a complete package is written out for you ready to enjoy via pkgadd



Thanks to Phil for the original gnutopkg script that I based the vimtopkg ksh script on. I also have a more generic one suitable for packaging just about any autofoo* based program.

Technorati Tags:

06 July 2005

Whodunit? Finding what package a file belongs to

Those of you who are refugees from the RedHat Linux world, may be used to a rather simple way of finding out what package claims responsibility for a particular file. Well, you'll be relieved to know it's just as easy to find out under Solaris as it is when running RPM based Linux distributions. Here's a simple example of how I found out what package references /usr/bin/nautilus:

/usr/sbin/pkgchk -l -p /usr/bin/nautilus

Here is the resulting output:

Pathname: /usr/bin/nautilus
Type: regular file
Expected mode: 0755
Expected owner: root
Expected group: other
Expected file size (bytes): 677516
Expected sum(1) of contents: 25862
Expected last modification: Dec 16 11:52:16 2004
Referenced by the following packages:
SUNWgnome-file-mgr
Current status: installed

Technorati Tags:

23 June 2005

UTF-8 Locales: Disabling the Language Box

Thanks to Laurent Blume who recently posted the *real* solution (not the cheap hack I posted a few months back) as to how to disable the incredibly annoying language selection boxes that JDS and Motif feature by default under Solaris 10 and UTF-8 locales. The solution is simple and kudos to Laurent for finding it!

Technorati Tags:

17 June 2005

Solaris Development Tip

Beware /usr/ucb.

By default this is in your path, and if you want to use the SUN Studio compilers to compile anything and everything, you need to either put /usr/ucb after /opt/SUNWpro/bin in your path, or take it out completely (highly recommended).

The reason for this? As far as I can tell /usr/ucb/cc implies -Xs, since /usr/ucb/cc is designed to act as an interface to the BSD Compatibility Package C compiler. So, if you go along your merry way and try to compile source code that uses C99 extensions, such as the following:

#define a(...) foo

You may encounter bizarre errors such as:
"test.c", line 1: bad formal: .
"test.c", line 1: bad formal: .
"test.c", line 1: bad formal: .

What clued me into what was wrong was the following warning when I tried to enable c99 extensions:
/usr/ucb/cc -xc99=all -o test test.c
cc: Option -Xs requires -xc99=none

Obviously, I'm not passing -Xs myself, so /usr/ucb/cc must be implying it automatically. I encountered this while trying to compile the latest version of metacity (the default GNOME window manager). While I realise many Solaris old-timers may already know about this, I thought I would pass it along as I'm fairly new to Solaris development myself.

I've been told and have read comments by a few different friendly SUN engineers that there is no good reason to have /usr/ucb in my path. I plan to follow their advice.


Technorati Tags:

16 June 2005

Solaris Express Community Release Tip

If you're having problems booting the Solaris Express Community Release (necessary to Build OpenSolaris), try unplugging any USB devices you have connected to the system (especially if it's a Logitech Optical USB Mouse). There's a bug right now that prevents some systems with certain USB Mice from being able to properly boot the Solaris Express Community Release. I have been told that a fix will be put out for this soon.

Additionally, when you have any problems booting the Solaris Express Community Release, you should read Dan Mick's blog entry about debugging the boot process so that you can provide more information to those who can fix it.

Technorati Tags:

15 June 2005

OpenSolaris is here!

What are you still doing here? Get it now!

Technorati Tags: Solaris OpenSolaris

05 May 2005

Groups vs. Roles

Like me, you may be a bit fuzzy on the high level differences between groups and roles, after all they do have a lot of similarities. Rohan Pinto de-mystifies them for us rather nicely.

Technorati Tag

24 April 2005

Solaris 10: Yet another development tip

A little note about something to be careful of when compiling and developing applications within a non singlebyte locale (a Unicode or locale other than "C"). You should always check the man pages of the utilities you're using in your build process or anywhere else first before using them. Some of the utilities that are in /usr/bin or /bin only properly handle singlebyte locales and won't work properly in others.

For example, the "tr" utility in /bin/tr or /usr/bin/tr will fail with a not-so-helpful message about "bad string" when in reality you've given it perfectly valid input. This is a result of it not supporting singlebyte locales. Instead, you will have to use /usr/xpg4/bin/tr or /usr/xpg6/bin/tr which support multi-byte locales.

Technorati Tag

19 April 2005

Solaris 10: A Few Development Tips and Solutions

Like me, after setting up Solaris 10 and getting your development environment going with the gcc that comes "in the box" (or "in the iso" as is the most likely case), you may have run into bizarre errors when running "configure" for programs you tried to compile and install. "configure" spouts things like system unable to compile programs, no proper compiler installed and so forth. You may also have encountered errors about missing symbols that look like they come from libstdc++. Well, be mystified no more. Four easy steps to a more blissful development environment:

1) Remove /usr/ucb from your path. You probably won't miss it, and unless you have the SUN studio tools installed, it's best if it's not in your path anyway (due to /usr/ucb/cc I believe).

2) Apply the fix found here for SUN's possible oversight.

3) Add /usr/sfw/bin to your $PATH (preferably *first* in my opinion)

4) Add /usr/ccs/bin to the *end* of your $PATH

Have fun!

Technorati Tag .

09 April 2005

Need a quick way to kill the X server?

Recently I had an X11 program misbehave and esentially make my JDS desktop unresponsive to my input. Since I don't have another system nearby where I can login in via SSH and kill Xorg manually, I've just been hitting the reset button because for some odd reason Control + Alt + BackSpace doesn't kill the server by default with Solaris 10 (on some systems possibly?).

Well, I happened to post about this on the Solaris x86 Yahoo Group Mailing List and Adrian Saul along with Casper Dik of SUN were kind enough to post the solution, and why it was needed. The solution is simple, add the below to the bottom of your /etc/X11/xorg.conf:


Section "ServerFlags"
Option "HandleSpecialKeys" "Always"
EndSection


Solved the problem rather nicely, fear misbehaving X11 programs no more!

Technorati Tag

07 April 2005

Packaging Options?

Continuing on with my journey into the world of Solaris...

A problem has confronted me, namely what to do about packaging. Yes, Solaris 10 comes with it's own packaging system. However, let's be honest, it's not nearly as convenient to use as RPMs are, especially when you need the ability to rebuild packages on demand easily.

Since the company I work for uses RPMs to manage all of our software installs via an apt-get repository (which works really, really well by the way) now on RedHat Enterprise Linux boxen I wanted something as similar as possible. I first tried to compile the latest RPM source on my own, and discovered that it was disappointingly Linux focused (Linux isn't UNIX folks, please stop using non-portable functions, etc.). Enter OpenPKG.

OpenPKG provides me with a way to migrate our existing software management structure with fairly little pain over to Solaris 10 while retaining all the conveniences and benefits of both binary and source package management. It also makes people happy that might have otherwise been unhappy with my constant push to move from a Linux platform to Solaris 10.

Some people might think it's rather abhorrent to have multiple packaging systems on their Solaris box, but I don't think so. Especially since this way, I can isolate all the packages or custom versions of common libraries we use into its own directory tree without interfering with SUN's packages in any way and feel safe in the assurance that any changes to my OpenPKG tree won't impact the rest of my system in any permanent fashion.

Yes, I already considered other solutions such as pkgsrc, pkg-get, and so on. However, none of them really have the elegance or simplicity that I needed for managing a completely custom software repository comprised of both binary and source packages. I am interested in other projects out there that are similar to RPM if they exist. Leave a comment if you know about something I don't...

Technorati Tag

08 March 2005

Solaris 10: JDS3 UTF-8 Behaviour giving you the blues?

Like me, you might be an application developer that has to be setup for a UTF-8 development environment, and needs to run their desktkop and everything in the en_US.UTF-8 locale. I do because I run a apache process under my own user account for my mod_perl development work.

You probably figured out that to do so you had to set LANG in your .profile or somewhere else. I set LANG=en_US.UTF-8 in /etc/default/init personally. However, once you did that, you were in for a somewhat unpleasant surprise in JDS. Enabling a UTF-8 based locale causes JDS to attempt to be "helpful", and stick a language input selection box at the bottom left hand corner of almost every dialog on your desktop. While that would be awesome if I needed the ability to type special accented characters, or switch languages on the fly, I don't. So for me, it was just a major visual annoyance.

However, thanks to some users on the Solaris x86 Yahoo Groups Mailing List, a fairly easy solution is at hand. Edit your ~/.dtprofile file and add the following lines at the bottom:


export XIM="htt"
export GTK_IM_MODULE=iiim
export XMODIFIERS="@im=${XIM}"


Now, logout and log back in. Voila! No more annoying language selection dialogs everywhere.

Related Blogs:

07 March 2005

Solaris 10: Tips and Tricks

So...I've got that shiny new Solaris 10 installation up and running. But, along the way I've discovered some incredibly annoying things that just bug me to death. In fact, you may have discovered some of the same things:
  • Your sound card isn't supported by default
  • Your shiny new Gigabit network device isn't supported
  • You are not able to use your Home, End, Page Up, or Page Down keys in X Terminal Programs
  • There's no nifty little network configuration program to make it easy to setup your network device for DHCP
  • All of those wonderful programs you're used to easily installing via yum, apt-get, portage, etc. seem difficult at best to setup and install
What's a person to do?

Well, fear not gentle reader. I am here to bequeath virtuous Solaris bit salvation to you. All of the above problems are easily solveable, thanks to people like Ben Rockwood, those on the Solaris x86 Yahoo Group Mailing List and Sun's wonderful documentation.

Problem 1 - Sound Card Support

Two options that I know of:
  1. http://www.tools.de/solaris/audio/
  2. 4Front Technologies
The free drivers at the first URL may work for you, or may not. The 4Front Technologies drivers are probably the safest bet, though by default they're nagware until you pay for them (banner message everytime you run 'soundon', no nags beyond that) and you have to manually enable them everytime you boot your system (at the moment anyway). I use them with my SoundBlaster Audigy 2 on my Athlon64 workstation and they're quite a treat (beta status currently). Having been used to the shoddy mixers typically available under X11 desktop environments I was pleasantly surprised at the multi-channel audio support and ossxmix, 4Front's mixing program. Highly recommended.

Problem 2 - Network Device Support

I discovered after installation that Solaris 10 didn't support my Realtek 8169 based Gigabit ethernet adapter on my motherboard. However, after spending some time Googling, I found Masayuki Murayama's network driver page. Soon I was enjoying glorious Gigabit ethernet again, and as a plus it works whether you're compiling for a 64-bit kernel or a 32-bit kernel. I should disclaim any usage beyond normal desktop stuff and downloading / uploading files. Workstation level usage only here.

Problem 3 - Unable to use Home, End, Page Up, Page Down Keys

This by far was the most annoying, perplexing, and difficult of all to solve. But with some help from users on the Solaris x86 Yahoo Group Mailing List and some perserverance on my part, I finally discovered the solution (beginning of the thread).

Problem 4 - DHCP Configuration not so nifty

Setting up DHCP and my own hostname turned out to be pretty easy, even though I'm used to a nifty little text-based configuration program in other *nix-like Operating Systems:
  • touch /etc/dhcp.gani0 (where gani0 is the name of your network device driver plus it's enumeration)
  • vi /etc/hostname.gani0 (put whatever you want for a hostname inside of this file and save it)
  • reboot (there are other ways to get this to activate, but I'm lazy...)
Problem 5 - How do I install my Favourite Program?

Most of your favourite programs can probably be found at blastwave, and are easily installable via a nifty little program called pkg-get (usage and installation both found at the link).

Where to from here?

If you want to learn more, Sun's documentation site, BigAdmin, the OpenSolaris site and DryDog are all great sites to start with. As far as the blog world goes, here's my A-List for Solaris:
Whew. This little blurb has already grown long in the telling, so I'll save the other goodies for another time.

So long for now...


Related Blogs:

06 February 2005

Solaris 10: The Journey

Recently, it came to my attention that my RedHat Enterprise Linux subscription was about to expire. At the same time, the company I work for has decided they can no longer afford RedHat's overpriced subscriptions. Considering the licensing alone every year is comparable to a good chunk of one of our employee's annual salary. So, I started looking for alternatives.

From the very beginning I decided there were going to be some key requirements for whatever Operating System I was going to look at as a serious alternative:
  • Flexible Support Options
    • Every dollar counts. Should only have to buy support for the systems that need it (like our Database Servers).
    • The ability to buy support based on a reasonable scale from basic support to mission critical.
  • Flexible Licensing
    • We replace hundreds of packages on whatever Linux distribution we use because of our unique application environment requirements. Now, this is only done for the web servers where the web-based application is executed from. However, having done this it made it absolutely pointless in retrospect to have RHEL subscriptions because we had to roll our own update systems anyway to deal with our package customisations which made our systems unsupported by RedHat.
  • POSIX Environment
    • Our application is written assuming we're running on a POSIX based system.
  • *nix Platform
    • The OS must be a *nix or *nix-like platform. Every since I started using Linux in 1994, I've been convinced that *nix-like Operating Systems are the only way to go when it comes to Servers.
  • Packaging System
    • The OS in question must have a native packaging system of some kind or be able to use RPM packages. Our application is currently packaged using RPM.
    • The packaging system must be well documented or at the very least a very mature system. (RPM while mature is poorly documented in my opinion, not only because it varies from distribution to distribution in it's implementation and usage).
  • Oracle Certified
    • The OS in question must be one of the certified platforms for running Oracle Software.
  • Seamless support for 32/64-bit platforms
    • Currently my company doesn't have any 64-bit hardware. But, I use an custom-built Athlon64 system as my personal development system, and I know that eventually we will have some servers that are 64-bit capable.
    • The OS in question should be able to handle 32-bit and 64-bit applications with equal ease in the same environment.
  • Reasonable Hardware Support
    • Almost all of the hardware we use in our servers is fairly standard, has full documentation or specifications provided to the public, and is generally manufactured by "Open Source" friendly companies. The OS should support it then.
    • The OS in question must also be a viable desktop OS for developers that work on the application.
  • Specific Application Support
    • The following applications should be available for use:
      • perl
      • apache2
      • mozilla
      • Gnome Desktop
    • The following libraries should be available for use:
      • Berkeley DB
      • gd
      • libxml2
      • glib
So, with those requirements in mind, the vendors that provided a suitable Operating System available to me narrowed considerably:
  • SuSE
  • RedHat
But, then I started reading about OpenSolaris, specifically blog entries like this one about DTrace. The more I read about DTrace and what Solaris was capable of (Zones, Self-Healing mechanisms, ZFS in the future, etc.), the more I wanted to try out Solaris. Then, last night I found this page full of all kinds of wondrous things that as a developer I all too often find the need to do. RHEL and SuSE were too expensive, and after finding all of these things it cinched the decision to seriously evalute Solaris.

So, my journey began...

I'll post about my experiences installing, plus all the various things I had to do to get my system working as a desktop soon. As well as the things I still haven't yet figured out...

Related blogs: .