Good article on the Linux boot process... Let me rephrase that. A very consise, clear, and informative explanation of the Linux boot process. I stumbled upon this while trying figure out the purpose of the VMware /dev/sda7 partition.
Linux Boot Process, courtesy of IBM
Wednesday, February 27, 2008
Monday, February 25, 2008
Trillian on Vista
I found it odd that when I ran Trillian under Vista, it still looked as if it were running under XP. I would have though that Vista would have applied Aero to all programs. After several attempts, I finally found a Trillian Skin for Vista:
by ~a1 on deviantART
Again, I'm surprised that the application settings override the desktop settings, as my desktop uses the blue theme and this is a black theme. The developer also has a silver theme available.
by ~a1 on deviantART
Again, I'm surprised that the application settings override the desktop settings, as my desktop uses the blue theme and this is a black theme. The developer also has a silver theme available.
Thursday, February 21, 2008
Vista: Wireless Bug
I've bumped into a bug on Windows Vista and wireless networking. When Vista connects to a wireless network, it stores the SSID in the registry. When trying to use a public wireless network, I've noticed that sometimes Vista simply refused to connect. No reason, just because.
Solution: delete the SSID from the registry. The SSID appears three times, but it is only the first instance, the Profile that needs to be deleted. Drill down through:
Repeat the connect process, and all should work.
Solution: delete the SSID from the registry. The SSID appears three times, but it is only the first instance, the Profile that needs to be deleted. Drill down through:
ComputerUnder Profiles, there are several keys. As each is highlighted, the ProfileName is displayed in the right hand pane. When the offending SSID is located, delete the entire key from the Profiles branch in the left hand pane.
HKEY_LOCAL_MACHINE
SOFTWARE
Microsoft
Windows NT
CurrentVersion
NetworkList
Profiles
Repeat the connect process, and all should work.
Thursday, February 07, 2008
Sunrise At The Jefferson Memorial
Monday, February 04, 2008
Favorite Super Bowl Ads
Whatzup with all the screaming animals?
I wish the Pigeons in DC were this big:
I think Charles Barkley is only trying to teach him a lesson:
On this one, I just enjoyed watching Justin Timberlake be abused:
Bottle opener suck! Yes, that's why they screw off:
I wish the Pigeons in DC were this big:
I think Charles Barkley is only trying to teach him a lesson:
On this one, I just enjoyed watching Justin Timberlake be abused:
Bottle opener suck! Yes, that's why they screw off:
Air Force Memorial
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:
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:
<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.
<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>
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,TerminalEven 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.
# 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
Terminal.colorSet = http://www.example.com/ssh/colorSet.confFor 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:
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 restartThe 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.
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:
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: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.
# mkisofs -o win-XP.iso /media/WXPOEM_EN
Right:
# dd if=/dev/sr0 of=/iso/win-XP.img
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 ProfessionalNow, I can start the VM, use RDC to connect.
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.
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.
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.
Subscribe to:
Posts (Atom)