Friday, October 31, 2008

Solaris 10 U6 is here

I know this will be the hot topic on all of the blogs today, but I'll add mine as well.

U6 is here. What does U6 provide?

http://docs.sun.com/app/docs/doc/817-0547/ghgdx?a=view

Short list if you don't want to go to the link:


  • ZFS Root Pool or ZFS boot
  • ZFS Command improvements
  • Lock stat provider for Dtrace
  • Zones: Upgrade on Attach YEA
  • Zones: Different Default routes on shared IP's
  • Zones: ZFS permitted as Zone Root
  • x64: Support for 256 Processors
  • Adobe Reader: Finally
  • Flash Player: WOW
  • And Much Much more

I'm upgrading all my systems today, and will let you know how that goes either late tonight or tomorrow.

Saturday, October 25, 2008

Sun Ray Bandwidth

For the last year, I have been involved with some extensive research and proof of concepts at one of my customers.  One of the big misconceptions that I deal with, is Sun Ray's take a lot of bandwidth.  I hear that "Compared to Citrix, Sun Ray's don't even compare".  Well, I one day I was sick of hearing this with no rebuttal, so I challenged this person. 

I said let's look at your full screen citrix and see the settings.  So we opened up his settings at 800x640 and 16 colors.  He had been comparing these network bandwidth utilization with that of a Sun Ray running 1900x1200.  Seems a bit unfair doesn't it?

The Thin Thin Blog did a great job of suggesting that Citrix and Sun Ray's are similar in Bandwidth consumption.  This is a pretty old blog, so I thought I would add my 2 cents.

Here's how it goes.  I was asked to go to Mexico, and try a connection with a Sun Ray connected through a WAN back to the Chicago Area.  Before I went I started looking at Latency.  On average, the latency is aprox 150ms on average.  I saw this go up to as high as 800ms Latency.  This concerned me going down to Mexico, but it ended up ok, but I'm getting ahead of myself.

We arrived and started plugging things in, so here's the setup:

  1. Sun Ray 2FS with a single monitor attached - Mexico
  2. USB Keyboard and mouse - Mexico
  3. Sun Ray server was a x6250 - AMD Procs - Chicago
  4. VMware server was a x4420 - Intel Procs - Chicago
We used SRSS 4.0, but 4.1 came out as we where in mexico, so I would suggest that as of this writting.  We used Sun Virtual Desktop Infrastructure connected to VMware Virtual Center.  Why did we choose this?  Basically, because we had no time to do application remediation.  Meaning, we could literaly "Suck" up the PC that the end user is working on, and send it to the server and replace the Desktop with a Sun Ray.  Why would anyone want to do this?  First, sharing of resources, second, easier mangability, third upgradability.  I'll go into that more another day.  If I don't, someone remind me to. :}

We also used the GUI firmware on the Sun Ray, that allows us to put in the IP address and Sun Ray server manually.  This is great when doing a POC, and you or your company doesn't have a DHCP server.  I would suggest this for a large scale roleout, but for a dozen or so, it works.

We plugged in the Sun Ray's and started monitoring.  We monitored in 3 locations.  On the VMware server, on the Sun Ray server, and on the actual Network. 

Here is the network bandwidth for one of the two Sun Ray's we brought.  As you can see, we averaged about 30 Kbps.  This isn't just a workstation sitting idle, it's acutally someone working on it.  I have all of the VMware charts and all, but this is the most telling with Bandwidth.



So what exactly where we displaying?  a 1024x768 desktop at 8 Bit color.  I could have done less Kbps, with a lower color depth, but 30 Kbps is what we were trying to hit.

Let me know if you have questions or comments.

T


, , , , , ,

Wednesday, October 22, 2008

Poor Man's VDI ...

Once again, I'm amazed at some of our Partners and what they do.  DJ, who works for a Sun VAR in the Switzerland, www.acceleris.ch, sent me this. If you are in need of saving money, call DJ an Acceleris.

Here is just one instance of DJ wanting to help the community more than any one company could do.  This is why Sun Microsystems is a partner centric organization.  The whole is greater than the sum of it's parts.  Or the Community is greater the the sum of just Sun's Parts.

Here is what DJ wrote to me, and he ask that I share it with you!


________________________________



In my opinion (yes I admit: I am biased ;-) ) this stuff is highly useful for anyone who has to work with a tight budget ... and given the current financial crisis worldwide I could imagine that many people in many companies and IT departments have tight budgets too now ...

So all this is written under the following assumptions:

a) You cannot afford or simply don't want to pay the mind-boggling license costs for VMware's ESX and "Virtual Infrastructure" products
b) you don't have the server hardware required to run VMware ESX anyway ... but having VDI-like features would be nice.
c) but you have a reasonably strong PC somewhere somehow and you have a few Sun Ray DTU's which you could use
d) you don't mind not (yet) having the management abilities VI3 offers and you're perfectly happy with any alternative ... (Sun will soon release xVM Server and xVM OpsCenter anyway)

I myself implemented my "Poor Man's VDI" on the following configuration:

- Sun Ultra 24 PC, Intel Quad-Core CPU, 8 GB RAM, 250 GB disk
- OS: Solaris Express, build 98
- SRSS 4.1

and last but not least:  VirtualBox 2.0.2 :-)

Here we go:


1.) Install Solaris

... confgure a few demo user accounts, and then install SRSS (I use Solaris Express build-98 + SRSS 4.1), configure it the way you want, e.g. Kiosk Mode and everything. On my setup I use Opera 9.61 as "kiosk mode browser":

- get the Solaris package for Opera: http://www.opera.com/download/solaris/
- unpack and install it
- switch to a normal account (not root!) and launch it:  /usr/local/bin/opera
- Opera will open and and ask you to confirm the license ... Hit "I agree" ... you shouldn't see that window ever again.
- adjust Opera to your own liking, e.g. set the homepage to http://www.sun.com
- quit Opera

Now we copy your newly generated Opera settings somewhere else so every Kiosk user gets these same settings:

cp -r /export/home/yourusername/.opera /opt/
mv /opt/.opera /opt/opera-prototype
chown -R root:root /opt/opera-prototype
find /opt/opera-protype -type d -exec chmod 755 {} \;
find /opt/opera-prototype -type f -exec chmod 644 {} \:

Then in the Sun Ray Admin Console make sure that this command gets executed in the kiosk mode (I placed it into a script: /usr/bin/opera_kiosk.sh), e.g. as "Executable" and mode set to "Critical":

#! /bin/bash
/usr/local/bin/opera -personaldir /opt/opera-prototype -resetonexit -kioskmode -nosplash -nomail -nomaillinks -noprint -nosave -nohotlist -nomenu -nocontextmenu -nodownload -nosession -kioskbuttons -kioskwindows http://www.sun.com

=> Result: a very good looking but pretty much locked-down web browser ... ideal for kiosk mode sessions.


2.) Download and install VirtualBox

 e.g. from here:
http://download.virtualbox.org/virtualbox/2.0.2/VirtualBox-2.0.2-36488-SunOS_amd64.tar.gz


3.) switch to normal user accounts and create a few VM's in VirtualBox.

Make sure that the guest addons are installed. In my case I have a virtual Ubuntu machine in one account; another account has a virtual Windows XP, and then again another account has a virtual Novell SLED installation, and so on ...

Piece of advice: Don't use spaces in the names, e.g. don't call your VM "My OpenSolaris test VM" but rather something like "OpenSolaris_Test"

And if you want:  Configure your VM to perform an "Auto Login", e.g. not ask for username and password. User authentication and access to your VM will be handled by the Sun Ray server later, so there is no need for extra authentication via the guest-OS, IMHO


4.) Each user who wants to use "Poor Man's VDI" should have an ".autovm" file in their $HOME directory.

The file should contain the name of the virtual machine that you want to access when you login via dtlogin, e.g.:

echo my_WinXP > ~/.autovm

... If they don't have that file and try to access the "AutoVM" session (see below for that) they will get an error message and be returned back to dtlogin.


5.) Configure dtlogin 

But first credit where credit is due:  For the life of me I could not figure out how to create a custom session for "dtlogin" (on Linux with "gdm" it is sooo easy!) ... I then ran across this web page which shows how to create a custom "IceWM" session for dtlogin ... So I more or less "borrowed" everything from here:  http://www.softagalleria.net/icewm.php   .... And then I installed XFCE and borrowed even more from the various scripts there.

We need to create a bunch of files now:


a) /usr/bin/vbox_autovm :

#! /usr/bin/bash
AUTOVM=`cat $HOME/.autovm`
if [ -z $AUTOVM ]
  then
    /usr/bin/zenity --error --text="You have not yet configured your ~/.autovm file. Please ask your administrator."
    exit 1
fi
/usr/bin/VBoxSDL -fullscreen -vm $AUTOVM



b) /usr/dt/config/Xsession.autovm :

#!/bin/ksh
#####################################################################
###  File:              Xsession.autovm  Version 0.1
###
###  Default Location:  /usr/dt/config/Xsession.autovm
###
###  Purpose:           Automatic start of VirtualBox VMs
###
###  Invoked by:        Solaris Desktop Login Manager (dtlogin)
###
#####################################################################

DTDSPMSG=/usr/dt/bin/dtdspmsg

export SESSIONTYPE="altDt"
export SDT_ALT_SESSION="/usr/dt/config/Xsession2.autovm"
export SDT_ALT_HELLO="/bin/true"
export SDT_NO_TOOLTALK="1"
export SDT_NO_DTDBCACHE="1"
export START_SPECKEYSD="no"
exec /usr/dt/bin/Xsession


c) /usr/dt/config/Xsession2.autovm :

#!/bin/ksh
#####################################################################
###  File:              Xsession2.autovm  Version 0.1 $Revision: 1.0 $
###
###  Default Location:  /usr/dt/config/Xsession2.autovm
###
###  Purpose:           Launch VirtualBox VMs
###
###  Invoked by:        /usr/dt/bin/Xsession
###
#####################################################################

# First a little namespace cleanup of vars associated with this
# (and /usr/dt/bin/Xsession.ow) scripts.

unset SDT_ALT_SESSION
unset SDT_ALT_HELLO
unset SDT_NO_DSDM

if [ -f /etc/dt/config/Xinitrc.autovm ]; then
    XINITRC="/etc/dt/config/Xinitrc.autovm"
else
    XINITRC="/usr/dt/config/Xinitrc.autovm"
fi

if [ -x /usr/dt/bin/xmbind ]; then
    /usr/dt/bin/xmbind
fi

echo 'AutoVM'

if [ -f $XINITRC ]; then
    echo "using xinitrc file: $XINITRC"
    /bin/ksh $XINITRC
else
    echo "xinitrc file: $XINITRC not found"
fi


d) /usr/dt/config/Xinitrc.autovm :

#!/bin/ksh
#####################################################################
###  File:              Xinitrc.autovm  Version 0.1 $Revision: 1.0 $
###
###  Default Location:  /usr/dt/config/Xinitrc.autovm
###
###  Purpose:           Launch VirtualBox VMs
###
###  Invoked by:        /usr/dt/bin/Xsession
###
#####################################################################

if [ "x$LC_ALL" = x -a "x$LANG" = x -o "x$LANG" = xC ]; then
  export LC_ALL="C"
  export LC_CTYPE="C"
else
  export LC_MESSAGES=$LANG
fi

export G_FILENAME_ENCODING=@locale,UTF-8
export G_BROKEN_FILENAMES=yes

/usr/openwin/bin/xrdb -merge << EOF
! Default CDE resources
*WindowColor:           #8A008A008A00
!*WindowForeground:      #FF0000000000
!*DataBackground:        #0000FF000000
*DataForeground:        #FF0000000000
*WorkspaceColor:        #8A008A008A00
*Color.Background:      #FF000000FF00
!*Color.Foreground:      #0000FF000000
*foreground:            #000000000000
! Hack for Dtmail
*XmText*background: seashell
*XmTextField*background: seashell
*Message_List*background: seashell
*background:    #AE00B200C300
Dthello*string:        Welcome to the OpenSolaris Xfce Desktop
EOF

if [ -f $HOME/.Xdefaults ]; then
    xrdb -merge $HOME/.Xdefaults        # Load Users X11 resource database
fi

/usr/bin/linc-cleanup-sockets

command=/usr/bin/vbox_autovm

if [ -x "/usr/bin/dbus-launch" -a -z "$DBUS_SESSION_BUS_ADDRESS" ]; then
    command="/usr/bin/dbus-launch --exit-with-session $command"
else
    echo "$0: dbus-launch not found."
fi

if [ -x "/usr/bin/ssh-agent" ] && [ -z "$SSH_AUTH_SOCK" ]; then
    command="/usr/bin/ssh-agent -- $command"
else
    echo "$0: ssh-agent not found."
fi

echo 'Starting AutoVM'
exec $command


e) /usr/dt/config/C/Xresources.d/Xresources.autovm :

Dtlogin*altDtsIncrement:    True
Dtlogin*altDtName:    AutoVM
Dtlogin*altDtKey:     /usr/bin/vbox_autovm
Dtlogin*altDtStart:     /usr/dt/config/Xsession.autovm
Dtlogin*altDtLogo:    XFCE


=> this last file also needs to be copied to the other locales ... as "root":

find /usr/dt/config -name Xresources.d -exec cp /usr/dt/config/C/Xresources.d/Xresources.autovm {} \;


Voila, done!

If you did correctly setup everything and if you did not forget to create that ~/.autovm  file that contains the name of the VM you want to start, you should now be able to go to your next best Sun Ray, type in your username into the "dtlogin" mask, select "AutoVM" as your session type, type in your password .... and you should now be watching how your favourite VM is booting. And it boots pretty fast (yes, VirtualBox rocks!)

Once it's booted you can just leave it like that ... Session hotdesking of course works as well. Insert your SmartCard into another DTU and your VM follows you wherever you go ...

I tested this stuff here in my lab and my colleagues here are pretty happy with it especially given the price tag for the software (not including possible license costs needed for proprietary guest Operating Systems in your VM's ...):  Zero. All the software needed (Solaris + SRSS + VirtualBox) to implement this type of "Poor Man's VDI" can be downloaded for free from SUN's web site.

Insert card ... we have a Novell SLED running. Insert another card ... Windows XP ... Insert another card: Ubuntu .... Insert another card: Solaris desktop.  .... Even better: Thanks to the "Remote Control" scripts you already posted this also works from SGD, e.g. a user can access whatever VM he has started in the office via the "My Sun Ray Session" menu entry inside SGD ... :-)

So what exactly do I need VMware and their incredibly expensive licenses for?? :-)

Friday, October 10, 2008

Remote Control Sun Ray Session with SGD

One thing I love about the Internet, is the ability to bring us closer.  You have noticed a post for DJ.  DJ asked me, in the comments of one of my blogs to go more in-depth in some of the serial ports to work with VDI, so I did.  Come to find out DJ works in Europe for a Sun Reseller, and was on-site at a customer looking for help.  With out even knowing it, my blog post helped a customer out and Sun sold the customer on Sun as a company. 

All that to say, DJ wanted to return something back to the community, so below is a script he wrong integrating SGD and SRSS.  This is what Open Source is all about.  People doing some cool things and returning them to the community to make the community stronger!

Thanks DJ for the script, it's been great meeting you, and I am still working on the open LDAP integration.

__________________
Here we go:

I gave my users a new menu option in their SSGD menus: "My Sun Ray Session". When they click on it a new window opens and taaadaaa! they are indeed back into their Sun Ray session which they left at the office.

Here is how it works:

The menu point "My Sun Ray Session" is a script that resides on the Sun Ray server itself, e.g. /usr/bin/my_sunray.sh  ... so when a user clicks on this menu entry inside their SSGD webtop then SSGD does a "ssh -X" connection to the Sun Ray server and launches this script:

#! /bin/bash
# set -x

VNCDISPLAY=`grep 'VNCDISPLAY' /tmp/RemoteControl/$LOGNAME.agent.settings.vnc  | cut -d'=' -f2`
FCPASS=`grep 'FCPASS' /tmp/RemoteControl/$LOGNAME.agent.settings.vnc  | cut -d'=' -f2`

if [ -z $VNCDISPLAY ]
        then
                # echo "You don't seem to have a Sun Ray session."
                /usr/bin/zenity --error --text="You don't seem to have a Sun Ray session."
                exit 1
        fi

/usr/bin/create_vnc_passwd.sh $FCPASS > /dev/null
/usr/bin/vncviewer -shared -passwd $HOME/.vnc/passwd $VNCDISPLAY > /dev/null


As explained above: My script assumes that the "Remote Control Toolkit" is installed and working in "agent mode". You can get it from here:  http://wiki.sun-rays.org/index.php/SRSS_Addon:_Remote_Control_Toolkit

So this explains the first few lines in my script: The "Remote Control Toolkit" stores the information you'd need to access the VNC session in a file called "/tmp/RemoteControl/YourUserNameHere.agent.settings.vnc"

The problem with this file is that there does not seem to be an automatic way how the password that gets randomly generated could be transferred over into a format that is readable for the "vncviewer" program. Hence I need a little "expect" script to help me out with this .... so that explains the "/usr/bin/create_vnc_passwd.sh" script which I am calling in the second-last line:

#! /usr/bin/expect --
spawn /usr/bin/vncpasswd
sleep 1
expect "Password:"
send "$argv\r"
expect "Verify:"
send "$argv\r"
send "\r"
expect "$"

... this script takes the "full-controll password" ($FCPASS) as argument ("$argv") and then calls "vncpasswd" so it generates the VNC-readable "~/.vnc/passwd" file.

Once that file is generated we can call "vncviewer" (last line in the "my_sunray.sh" script) and supply the newly generated "passwd" file as argument. Voila.

Result: even though the password was randomly generated when the Sun Ray session started the user is not prompted to type a password when he connects to his session via SSGD, my quick + dirty scripts do all that automagically.

I had to come up with this stuff for a customer company ... on one hand their users would like to have access to their Sun Ray sessions from home, on the other hand the company's policy-makers don't want to open any additional ports on the outside firewalls, they don't want any VPN or IPSEC solution (because that's exactly why they bought SSGD as a sort of a "VPN-replacement"...) and they don't want to give their users Sun Ray thin-client units for home use  ...  Voila. With these scripts they can now use SSGD and access their Sun Ray sessions remotely (if they have an open session).

SRSS in a fusion VM

So I finally got around to setting up my vmware Fusion with Sun Ray server software.  All worked well, except the stupid bridge interface was being connected to my wireless card when it was connected.  That's not what I wanted, I wanted the Bridge to always go out en0.

I had no idea how to do this, so I start digging.

In /Library/Application Support/VMware Fusion there's a file called boot.sh  This is where the change needed to be.  I opened it up and on line 704, I uncommented:

"$LIBDIR/vmnet-bridge" -d /var/run/vmnet-bridge-vmnet0.pid vmnet0 en0"

and commented out

#"$LIBDIR/vmnet-bridge" -d /var/run/vmnet-bridge-vmnet0.pid vmnet0 ''

did a sudo ./boot.sh --restart and all is happy, I can know surf the web on wireless and have my SRSS and sun ray connected to the ethernet.

LIFE IS GRAND!

Tuesday, October 7, 2008

NetApp faces Sun lawsuit loss • The Register

NetApp faces Sun lawsuit loss • The Register

That's right, last week solaris is Dead, and zfs and D-Trace were really relegated to nice to have's

Well, I think this win for SUN is huge

NetApp was unable to comment immediately on this story. Sun's win - if it is a win - and the PTO decisions potentially turn NetApp's WAFL IP into, well, IP waffle. Sun gets a welcome PR boost to its ZFS and open source credentials, leaving NetApp with a bloody nose and a 22-patent IT infringement case to deal with. Oh, and the economy is going down the tubes too. It isn't so sunny in Sunnyvale right now.


Gotta Love it.

T

Wednesday, October 1, 2008

USB using NTFS...Problems mounting, I think NOT

Had a customer, Thanks Kevin, wanting to mount NTFS USB drive on Solaris.

He downloaded these to packages from here

FSWfsmisc FSWpart

and look at that NTFS on Solaris.

FAA using Solaris?

How the FAA Is Bringing Its Air Traffic Systems into the 21st Century

Wow, since Solaris is dead, I'd be afraid to fly.  NOT...This is a great feather in the Solaris hat.