Saturday, January 26, 2008

SSH Applet, Pt 2

I have the Java based ssh applet running, but I found it's configuration to be somewhat hit and miss. The HTML side was simple enough:
<html>
<head>
<title>SSH Access>/title>
</head>
<body>
Vypress via port 22:<br />
     
<applet CODEBASE="."
ARCHIVE="jta26.jar"
CODE="de.mud.jta.Applet"
WIDTH=100 HEIGHT=30>
<param name="config" value="applet.conf">
</applet>
</body>
</html>
First, the applet does not work well if embedded in the webpage, it needs to be detached. This means that when started, it launches in a separate window. That is a non issue, just watch out for pop-up blockers. As a result, I set the applet width and height so it appears as a button rather than the default, which was as a terminal window.

Second, few of the customization options work, and the few that do, depend on unrelated options in order to become active. The options are poorly documented. Here's what has worked:
plugins = Status,Socket,SSH,Terminal

# connection target configuration
Socket.host = w.x.y.z
Socket.port = 22

# Terminal configuration
Applet.detach = true

# scrollBar East only works if after Status South
layout.Status = South
Terminal.scrollBar = East

# resize font only works if after color true
Terminal.print.color = true
Terminal.resize = font
Even with print.color set to true, the terminal is monochrome. There is an option to specify a colorSet.conf, but it is not documented, and does not seem to function.
Terminal.colorSet = http://www.example.com/ssh/colorSet.conf
For all that doesn't work, I do have to admit, it connects. In the end, I guess that's all that matters.

Friday, January 25, 2008

Another Xen Bug

Seems this has been tormenting several people out there. At first I thought it was a problem with running Windows XP under Xen, but it seems to be bigger than that. All of a sudden Xen guests won't shutdown. They act as if they are going to shutdown, but the console never disconnects.

I can close the console, but virt-manager still shows the guest to be running. If I attempt to start the guest it fails, as it thinks it is running. Rebooting Dom0 fixes the problem. Not the preferred way of doing things.

Since I could replicate the problem on demand, I started both a Solaris 10 and Windows XP guest, and opened both in a separate Xen console. Without disconnecting the console, I issued poweroff from within the Solaris console. As expected, the Solaris guest hung.

From a Linux root terminal, I bounced Xen:
# service xend restart
The Windows XP guest was unaffected, and the Solaris guest was unlocked. Problem solved. Granted, not the best solution, but it should work until the next bug fix.

Wednesday, January 23, 2008

Windows XP, RDC

I built a Windows XP Xen VM for testing Windows software, and found it to be a little trickier than I expected.

The first problem I ran into was getting the system to install off the CD. It worked up until the obligatory "Your system will reboot to continue" but after the boot, it could not recognize the CD. The solution was to install off an image rather than a disk. Of course that means you need an image.
Wrong:
# mkisofs -o win-XP.iso /media/WXPOEM_EN
Right:
# dd if=/dev/sr0 of=/iso/win-XP.img
Next came a problem getting the thing to actually shutdown. Each time I had to reboot the server. Not good. I found that if I disconnected the local console before it reached the power off sequence, it would work.

I also mis-configured the network at install time, so the bridge was set to bridge=virbr0 instead of bridge=eth0. The system could get out, but I could not ping in. The importance of this will be aparent in a moment. To fix the network problem require exporting the XML, editing the code, and importing the change.

Once the XP VM was running, it was time for remote access. Alas, I didn't know how to accomplish this until I found instructions as, of all places, Microsoft:
Enabling Remote Desktop on a Computer Running Windows XP Professional

When you install Windows XP Professional, Remote Desktop is disabled by default. To enable Remote Desktop, follow these steps:

  1. Log on to your Windows XP Professional–based computer using an Administrator account.
  2. Click Start, right-click My Computer, and then click Properties.
  3. In the System Properties sheet, click the Remote tab.
  4. Select the Allow users to connect remotely to this computer check box.
Now, I can start the VM, use RDC to connect.

Thursday, January 17, 2008

SSH Applet

I found myself in an training class where I was stuck on a Windows XP system that I could not modify. I wanted to SSH to one of my servers, but there was not SHH client. Since I could not install one, I needed a portable, self contained, mechanism. Sounds like a job for a Java applet.

A quick Google search located JavaSSH.org. It sounded simple enough: embed an applet in a page on the server. As the target browser has a JRE, you've got access.

Initially, I thought this might solve another problem for me, also. I've been in situations where ports 80 and 443 were the only outbound ports available. So, I figured this could get me through a firewall since it would be in a browser.

Turns out, when I deployed this, I made a few mistakes in logic. The first was that I accepted the default to connect to localhost, in other words, the server where the webpage was hosted. Didn't work. The reason is that the applet tries to connect to the Windows client, because the applet does not run on the server, but in the local browser.

I changed the host from localhost to the server's hostname, but it still failed. Java can't get to DNS. I had to configure the server's IP address. This allowed a connection.

Lets backtrack to the firewall issue. Another error in logic. The applet still uses port 22, since it's running locally.

The applet still needs a little tweaking, as the connection times out in less than a minute. If I can get a reliable connection, I'll post the good config.

Thursday, January 03, 2008

Comcast HD -vs- Satellite HD

I have Comcast HD service, and I have to "respond" to a set of commercials they are running. Comcast claims to have three times the HD programming than satellite. Though this is not a lie, it's certainly is stretching the truth.

Channels:
Comcast = 27
DirectTV = 47
Dish Network = 34

These are the counts for basic HD service and does not include Premium HD. Comcast offers Cinemax and Starz in HD, the satellite providers also offer HBO and Showtime. If you actually review the HD channel selection for all three providers, you will find that the base set includes allot of fluffy channels that no one really wants, but it's pretty uniform.

The big problem with the channel selection is that Comcast just added Discovery for HD, whereas the satellites include Animal Planet, Science Channel, and History Channel.

So how can Comcast have three time more HD programming?

The answer is in the fine print. "Comcast offers three times more HD view options than satellite." Here how it works. Comcast has a fiber backbone with a hundreds of times the bandwidth of satellite. This means they can throw allot of bandwidth at OnDemand programming. As of 2 January, 2008, Comcast had 181 HD OnDemand selections. Add 140 to 27, you get 167. Divide that by 40, you get four to one. Factor the limited satellite on OnDemand and the number slides to three to one.

Now here's the fun part: Of Comcast's HD OnDemand, 40 selections are three minute music videos, 36 are five minute game reviews featuring cut scenes, an 19 others are vignettes of less than ten minutes each. If you were actually to sit down and watch all the HD OnDemand, back to back, it would require about 36 hours.

The Comcast claim is based upon two things: You watch less than 24 hours of programming a month and you really don't care what you watch during those 24 hours.

In the end, it looks like DirectTV has the best deal.

Until you factor in internet service.