Tadpole SPARCbook 6500 Jumpstart and Mouse

For awhile now, I've been unable to use the touchpad on my SPARCbook while installing, as the 'vuidsyn' strmod (STREAMS module) that's used to convert Synaptics signals into VUID signals, which Xsun uses wasn't available. This meant I had to attach a USB mouse. Typically, after installing Solaris Nevada, I would rip the 'vuidsyn' strmod off of the Tadpole Solaris 9 media (yes, strmods from Solaris 9 still work in Nevada a.k.a Solaris 11) and copy it to /kernel/strmod/sparcv9. This worked, but it was far from ideal, and given I've just gotten into doing Custom Jumpstarts, I wanted the install process to be completely automated. Having to manually copy that strmod from the Solaris 9 Tadpole media to the kernel strmod directory violated this. I got the bright idea to:

# cp /home/dlewis/vuidsyn /export/install/media/\
  Solaris_11/Solaris_11/Tools/\
  Boot/kernel/strmod/sparcv9
# cp /home/dlewis/dacf.conf /export/install/media/\
  Solaris_11/Solaris_11/Tools/\
  Boot/etc
(dacf.conf maps devices to the proper strmod)

After doing a 'boot net - install', Solaris began automatically installing, and my mouse now works out of the box.

Zone Install Path and Permissions

I've recently created a zone for Apache and MySQL on a colleague's workstation. The colleague works from the global zone, as it is his workstation, and I figured zones would be an excellent way of isolating his development environment from his workspace. He generally uses editors such as Bluefish and so fourth to edit the .php files in the zone's htdocs directory, which in the case is something like /export/zones/web-zone2/root/opt/coolstack/apache2/htdocs. He wanted the ability to save files to the htdocs directory from the global zone. Given the nature of zones, and the necessary security precaution that the zone install path should be chmod'd 700 or else the zone won't verify or boot, I had to come up with a way to boot the zone and still give him the ability to save directly to the htdocs directory in the zone without manually chmod'ing back and fourth.

I figured zoneadm or the other zone tools probably don't check for ACLs, just UNIX-style permissions, so I decided to give this a try:

# chmod A+user:dlapoint:execute:allow /export/zones/web-zone2
# chmod A+user:dlapoint:list_directory:allow /export/zones/web-zone2

Its nasty; however, it does work, and now he's able to read and write files to that htdocs directory without having zoneadm -z verify or zoneadm -z boot gripe about the permissions on the zone install dir being 'insecure'. There are some other ways I could've gone about this, such as sharing the htdocs from the global zone with web-zone1, but I felt that didn't provide the level of isolation that was desired.

The Wonders of Thin Clients

I decided to purchase a Sun Ray 1 off of eBay several days ago for $20, which arrived yesterday. After spending about an hour or so reading the documentation, installing, and configuring the Sun Ray Server Software (SRSS) on my Ultra 2 (laplace), I finally had my Sun Ray up and running. I simply plugged it in, authenticated, and logged into JDS. To be over Fast Ethernet, the drawing of the desktop was extremely fast, and the only time it seemed to sputter was when a window refreshed quickly, such as displaying a directory, prstat(1) refreshing, and video to some extent. I decided to play a small MPEG2 file that was low-res, and performance was excellent. Audio quality seemed to be fair, as I played some music that I had on laplace, which is my file server.

The Sun Ray 1 comes with 4 USB ports and two of those are used for the keyboard and mouse. This leaves the other 2 for USB peripherals such as a removable drive and printer. I plugged in my thumb drive, and it mounted somewhere in /tmp/SUNWut without a problem. It would've been nice for Nautilus in JDS to have detected it and presented an icon on the desktop for the drive, but that didn't happen. Next, I plugged in my HP LaserJet 1300, which created a device node in /tmp/SUNWut/units/IEEE802.MACID/dev/printers/. I used /usr/sadm/admin/bin/printmgr to configure the printer, and lpstat(1) had no problems seething the printer. I printed a few test pages and all worked well.

Afterwards, I decided to play around with the Sun Ray's session mobility capabilities, which allow you to move back and fourth between multiple Sun Rays and maintain the same desktop session (Sun calls this 'hot-desking'). This is meant to be done with using smartcards and the Sun Ray's smartcard reader, but I don't have any smartcards, yet. Using utpolicy(1) one can enable mobile session support without using smartcards, and just using plain, login-based authentication. I decided to play an audio file, pause the session by using Shift-Pause, and login in again. After doing so, my session re-appeared, and the audio resumed playing on the Sun Ray's internal speaker (the Sun Ray has audio output, as well, so you can hook up a real pair of speakers).

I'm planning on acquiring at least another Sun Ray, so I can test a multihead configuration (you can combine two or more Sun Rays and share a session across them for multi-head functionality), and some smartcards. I've found some IBM GEMPLUS cards on eBay that seem to be supported, but if anyone knows of a vendor that'll sell me 5 or 10 PayFlex cards (the same cards Sun sells in bulk for the Sun Ray), leave me a comment or email me.

Tangent to this post, I wish the university I attend (Lambuth University) would deploy at least a small amount of Sun Rays in some of the labs. From my understanding, each lab we have (there's about 5 labs total, I think) is upgraded every 3 years. This means all 10 or 20 systems that may be in the lab are upgraded to new systems, and the last purchase was around $600-$700/system. This is outrageous considering that a Sun Ray 1 goes for $20 on eBay, and its not hard to find an auction that's for a bulk load of them. We have a fairly large Windows deployment at the university that makes no use of Active Directory, so each system is its own entity to be administered. When software needs to be installed on a lab, it must be installed on each individual system, which implies there's significant administrative overhead involved in administering the university's network. Because Sun Rays simply use a single server or multiple servers running the Sun Ray Server Software, administration overhead is minimized -- if you want to install software, you install it on the 1 or 2 servers, and its immediately usable to everyone on the Sun Ray network.

Moreso, certain faculty members at the university are still using 10-year-old systems running Windows 95 or 98. This is completely unacceptable, considering Sun Rays could be deployed with a decent resolution, and utilize the performance of the Sun Ray server. Faculty members upgrading from these old computers to a Sun Ray would gain desk space, functionality, and performance, and still be able to accomplish their work, as 95% of the workload at Lambuth is word processing, browsing the Internet, and checking email.

Once I get my second Sun Ray, I think I'll ask the IT staff, and several faculty members to observe a demo of what we, the university, could have for minimal cost and maximum functionality.