Saturday July 26, 2008 |
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
To implement a SunRay demo with a Windows Terminal Server back-end, normally we use two separate servers. But now, with virtualization all around us, why not put those two components on a single box. Of course, there are many ways to skin the cat. I decided to take the X4100 that I had in the lab, put Solaris 10u4 on it, then install Sun Ray Server Software (SRSS) and finally install VirtualBox with a Windows 2003 Enterprise Edition guest server for the backend. However, this entry is not about Sun Ray or Windows, but about VirtualBox. When selecting the correct download, it was a bit unclear if there were separate versions for Open Solaris versus normal Solaris, or that it was all "one and the same". To jump couple of steps ahead, there is only one version, but it is clear that the developers of VirtualBox are doing their work with OpenSolaris and then expect it to work with regular Solaris as well. Well, as I discovered, and with me many others, that doesn't always work out. The pkgadd is straight forward and without problems. At the end you will have VirtualBox in your path and you're ready to fire it up. But then I got the following error bash-3.00# VirtualBox ld.so.1: VirtualBox: fatal: libGL.so: open failed: No such file or directory
Things like this have happened before, and my usual solution is "let's Google". In this case that was the wrong thing to do, :) because I got soooo many wrong suggestions. In some forum I read that something is wrong with the service "svc:/application/opengl/ogl-select:default" or that you have to install the package "sunwcslr". In my case, none of this was true. I'm sure that most of the problem is related to the difference between 32 and 64 bit systems. Not only the CPU, but also the OS and therefore the libraries must be matching. With my X4100, I was running a 64 bit AMD Opteron. I had installed Solaris running in 64 bit mode and I hadn't made the mistake of downloading the 32 bit version of VirtualBox. Here's some commands you can use to verify your own configuration regarding these issues. bash-3.00# uname -a SunOS java3 5.10 Generic_120012-14 i86pc i386 i86pc bash-3.00# ls VirtualBox* VirtualBox-1.6.2-SunOS-amd64-r31466.pkg VirtualBox-1.6.2-SunOS_amd64.tar.gz VirtualBoxKern-1.6.2-SunOS-r31466.pkg bash-3.00# isainfo -k amd64 bash-3.00# which VirtualBox /usr/bin/VirtualBox This looks good, 64 bits all where it matters. But why are things still going wrong when you start VirtualBox. No matter what all the other forum messages are saying, in my case it was in the end simply a matter of not finding the 64 bit version of libGL.so. I tried many other things first, but what solved it was setting LD_LIBRARY_PATH to include "/usr/X11/lib/mesa/64". bash-3.00# VirtualBox ld.so.1: VirtualBox: fatal: libGL.so: open failed: No such file or directory Killed bash-3.00# echo $LD_LIBRARY_PATH bash-3.00# export LD_LIBRARY_PATH=/lib:/usr/lib/64:/usr/X11/lib/mesa/64 bash-3.00# echo $LD_LIBRARY_PATH /lib:/usr/lib/64:/usr/X11/lib/mesa/64 bash-3.00# VirtualBox ^C bash-3.00# Which shows what went wrong and how it can be fixed. (2008-07-26 08:56:19.0) Permalink
Today I got my SunRay@Home. For those of you not working at Sun, that's a Sun Ray attached to your home network that directly VPNs (from the firmware) into SWAN, the corporate network. It allows for hot-desking from your cubicle to your study and vice versa. Pretty cool stuff. Reason I wanted to have one at home was mainly eco driven. When I do things like software development I need a full blown desktop. But in the morning, between alarm clock and shower, I'm only drinking my first coffee and checking my email. Why should I fire-up the big desktop to only use a browser and an email client. And that was my background to sign up for the SunRay@Home program. I got my unit today, installation was a jiffy. Everything fine, Sun Ray on my left display, PC on the right LCD. Around 10 PM I decided to shutdown the desktop PC. And then came the big surprise: For the first time in many, many years (probably twenty) I was using again a computer with zero background noise. No, not just the "nearly silent" that laptops give you, but simply absolute nothing!! It was lovely, but at the same time even weird, I guess a kind of reverse Pavlov effect (in this case I got the food but there was no bell). It appears that browsing the web and the noise of fans are by now in our minds tightly intertwined. I do use a Sun Ray in the office, but of course modern offices can't be called noiseless. I have to go back 15 years, when I used my trusty VT220 and a modem into the office, for the last time I worked with a computer that didn't make noise. And then 20-25 years back when my desktop system consisted of a 6502 based BBC-micro computer. That one also without fans, but you still had the rattling sound of the floppy drives. :-) For the rest, it seems I've always had fans around me when I was doing my computer stuff. So, this SunRay@Home is a keeper. I can hear the wall clock ticking again. The only thing I need to do is to replace the green power LED of my SR2 with a blue or a white one. That green is too ugly with the brushed aluminum. (2008-07-18 22:30:10.0) PermalinkIt happens too often that at customer sites there are issues around the IP address for the Service Processor. The proper way to handle this is IMHO simple: For each server, add an entry to the DHCP server, where based on the MAC address of the SP, a known IP address will be assigned. This way, everything is controlled by a centralized DHCP configuration but still each server gets a "semi static" IP address. Unfortunately, in many situations customers can not implement this, or they simply don't want to. The "can not" is most likely not based on technical arguments, but has mainly to do with organizational and responsibility issues. Your second option is to set the Service Processor IP address from the BIOS. Which works fine, but sometimes it can be hard to find a monitor and keyboard in a Data Center. Or nobody is willing to give you a free static IP address. Third option is to let the SP do a DHCP request and monitor the logfiles on the DHCP server to see what address was handed out. Which won't work if the person who needs to use the SP has no access to the DHCP server. The end result is that you can easily end up in a Catch 22. In the old days of V20/40z servers, we had those tiny LCD screens and you could even set the IP address using a few buttons on the front of the server. But the newer generation doesn't have those features anymore. Last week, I was again confronted with this problem (on a corporate network, where I had zero privileges) and I solved it in a different way. What I did was write a little script that tries to ping every IP address in the subnet, or better in the range that is available to the DHCP server. Kind of "poor man's port scanner". The script (let's call it "pingscan.sh") is pretty primitive and looks like this. #!/bin.sh for i in 13 14 15 16 17 18 19 20 21 22 23 24; do for j in 0 1 2 3 4 5 6 7 8 9; do ping -n -t 1 192.168.1.$i$j 1 done done This will scan addresses from 192.168.1.130 to 192.168.1.249, adjust the values for your network. The "-t 1" and the "1" at the end (this is Solaris ping) will take care that with one second gaps, each address in the subnet will be tried. So, the script will take a few minutes to complete, depending on the range. Fire up your server and let the SP do a DHCP request. Then run "pingscan.sh > before". And here comes the trick! Disconnect the network cable to the SP and run "pingscan.sh > after". A simple diff of the two files will show which IP address was given to the SP. # diff before after 57c57 < 192.168.1.186 is alive --- > no answer from 192.168.1.186 The script could be made much fancier, but this one only uses /bin/sh and can be typed in a couple of minutes. On a large and busy network it could happen that you will get multiple candidates. And of course this is not a preferred solution, because it isn't guaranteed that a week later the DHCP server won't give a different IP address. But this trick can help when you find yourself in a nasty corner. At least, it did that for me. (2008-07-14 18:53:02.0) Permalink Comments [3] |
Calendar
NavigationSearch
ReferersToday's Page Hits: 79
Recent Entries
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||