Ever since Mac OS X was rolled out in the University of Michigan computer labs, I've considered myself a multi-platform computer user. I use different OS's for different tasks - most of my development and work-related tasks are done on a Windows machine, while I use my Powerbook for casual browsing/e-mail and music-related tasks.
My work with Linux was typically limited to console-based use, though - I administer several Linux webservers, and can achieve all I want through the commandline over SSH. Recently, however, I've had a desire to broaden my use of Linux to "desktop use" - especially since it appears that I can get seamless virtualization of Windows apps inside Ubuntu with relative ease. I've been watching Ubuntu for a while, playing around with it inside the VMWare player, and decided that now was a good time to make the switch for real on my primary desktop computer.
Over the next few blog entries, I plan on documenting any pitfalls I've encountered, in case anyone else runs into the same.
The first thing I had to was convince my wife that switching to Ubuntu was right for us. She liked the logo, so that was a good start. What was even more helpful was the Installer/Live CD, though. I was able to show her Firefox, OpenOffice, and the general UI of Ubuntu without having to commit to anything. She wasn't particularly wowed at this point in the time, but that's sort of the point - the interface is something that just seems "right." It's not shocking, it just works how you would expect it to.
Next up, preparing my system for the switch. We've got loads of documents, including every paper from college, lots of programming projects, gigs and gigs of photos... all on NTFS partitions (split across one internal and two external drives). Using the LiveCD, I was able to see that Ubuntu read those partitions just fine. I decided to copy all of our data from the internal drive onto one of the external drives, format the internal drives using an open filesystem, and keep both the external drives as NTFS for now. While I did title this post "Taking the plunge," I'm not ready to jump in headfirst - I'd like to be able to get out of the water relatively easily in case anything goes wrong.
Finally, I used an Ultimate Boot CD for Windows that I made a while ago to make a backup image of my primary Windows partition. I probably could have done this using some sort of free program without having to use the UBCD, but since I had it, it was easier to just go with it.
Next entry: the installation process!
12 May 2007
19 March 2007
PCTakeout - in a more permanent box
A client of mine recently came to me needing a way of accessing his company's "central office" computer remotely. "Well, that's quite a coincidence," I said, and proceeded to tell him about PC Takeout (which, at $0, is definitely the right price). However, I could tell that he was interested in something a bit more permanent and responsive - having to go through a web browser to access the computer was far from ideal.
I was up for the challenge. After all, part of the reason that I based PC Takeout on VNC and SSH was because they were such commonly used protocols. Surely there had to be a nice, simple, standalone (at least for Windows) way of working with them.
Setting up the office computer was simple - I just downloaded the PC Takeout Installer, installed it, and set up the router in the office to forward port 22 to the desired computer. Finally, I set up a DynDNS account for the client and installed the free DynDNS Updater as a service so the host could be easily looked up (he wasn't sure if he had a static IP or not, so better safe than sorry). A test confirmed that I could SSH in to the computer from the Internet at large.
(Side note: if you're using the PC Takeout Installer for your own purposes and wondering what usernames/passwords to use, here's a quick reference: the SSH user is pctakeout, the SSH password is set during the installation process, and the VNC password is "pctakeou")
Next came the setup of the remote computer (from hereon out referred to as the "satellite" computer). At first, I thought of just using the "standalone" version of the Java client that PC Takeout uses. However, that has a few issues, one of which is the fact that the certificate is expired, and it also isn't nearly as responsive as a native Windows application. I decided to go with the native TightVNC client, since PC Takeout uses the development version of the TightVNC server. This would let the client use the fancy file transfer stuff if they so desired.
With that figured out, it now came time to handle the SSH tunneling. I've used Plink in batch scripts to handle secure SQL updates - however, I've run into issues with the process dying unexpectedly, and it's a pain to deal with all the possibilities in a simple batch/CMD script. I figured something along the lines of Plink was the way to go, though.
Somehow, a Google search turned up a Windows utility called MyEntunnel, a "background SSH tunnel daemon," as its website describes it. Exactly what I was looking for! And another positive thing - it's freeware! The author even encourages redistribution.
Setting up MyEntunnel was a piece of cake. When you first run it, you get a fairly straightforward settings screen. Fill in the username (pctakeout), enable compression (uses slightly more CPU, but could potentially help the overall speed), and set it to connect at startup if you like. Next step: set up the tunnels.
This is pretty simple. I just added the line "5999:localhost:5000" to the Local pane. This means that any attempts to connect to port 5999 on the local machine would be redirected to port 5900 on the "localhost" machine from the perspective of the central office computer. 5900 is the default port that VNC server listens on in Windows. I decided to use the local port 5999 instead of 5900, in case the client ever ended up running a VNC server on the satellite computer.
Clicking on the "Connect" key starts the magic of MyEntunnel. It will prompt for a password if you haven't entered one already. It uses a system tray icon to convey the status of the connection - a green lock means a successful connection has been made.
Once the connection was made, it was then just a matter of configuring the VNC client. To connect to the forwarded port, I entered "localhost:99" as the VNC server (if you enter a number after the colon, that number gets added to 5900 to determine the port number to try). Since this was over an Internet connection, I chose the "low bandwidth" connection speed.
Testing it out - success! Only I found that input seemed pretty jerky, and screen updates seemed quite delayed. I traced this to the polling mode of the VNC server - the default settings in PC Takeout's VNC server are set to poll the active window only. Changing this to full screen polling solved the issues with delayed screen updates (I'll probably change this for future PC Takeout Installer releases).
All in all, things worked very nicely, and the client is very happy. Score one for PC Takeout!
I was up for the challenge. After all, part of the reason that I based PC Takeout on VNC and SSH was because they were such commonly used protocols. Surely there had to be a nice, simple, standalone (at least for Windows) way of working with them.
Setting up the office computer was simple - I just downloaded the PC Takeout Installer, installed it, and set up the router in the office to forward port 22 to the desired computer. Finally, I set up a DynDNS account for the client and installed the free DynDNS Updater as a service so the host could be easily looked up (he wasn't sure if he had a static IP or not, so better safe than sorry). A test confirmed that I could SSH in to the computer from the Internet at large.
(Side note: if you're using the PC Takeout Installer for your own purposes and wondering what usernames/passwords to use, here's a quick reference: the SSH user is pctakeout, the SSH password is set during the installation process, and the VNC password is "pctakeou")
Next came the setup of the remote computer (from hereon out referred to as the "satellite" computer). At first, I thought of just using the "standalone" version of the Java client that PC Takeout uses. However, that has a few issues, one of which is the fact that the certificate is expired, and it also isn't nearly as responsive as a native Windows application. I decided to go with the native TightVNC client, since PC Takeout uses the development version of the TightVNC server. This would let the client use the fancy file transfer stuff if they so desired.
With that figured out, it now came time to handle the SSH tunneling. I've used Plink in batch scripts to handle secure SQL updates - however, I've run into issues with the process dying unexpectedly, and it's a pain to deal with all the possibilities in a simple batch/CMD script. I figured something along the lines of Plink was the way to go, though.
Somehow, a Google search turned up a Windows utility called MyEntunnel, a "background SSH tunnel daemon," as its website describes it. Exactly what I was looking for! And another positive thing - it's freeware! The author even encourages redistribution.
Setting up MyEntunnel was a piece of cake. When you first run it, you get a fairly straightforward settings screen. Fill in the username (pctakeout), enable compression (uses slightly more CPU, but could potentially help the overall speed), and set it to connect at startup if you like. Next step: set up the tunnels.
This is pretty simple. I just added the line "5999:localhost:5000" to the Local pane. This means that any attempts to connect to port 5999 on the local machine would be redirected to port 5900 on the "localhost" machine from the perspective of the central office computer. 5900 is the default port that VNC server listens on in Windows. I decided to use the local port 5999 instead of 5900, in case the client ever ended up running a VNC server on the satellite computer.Clicking on the "Connect" key starts the magic of MyEntunnel. It will prompt for a password if you haven't entered one already. It uses a system tray icon to convey the status of the connection - a green lock means a successful connection has been made.
Once the connection was made, it was then just a matter of configuring the VNC client. To connect to the forwarded port, I entered "localhost:99" as the VNC server (if you enter a number after the colon, that number gets added to 5900 to determine the port number to try). Since this was over an Internet connection, I chose the "low bandwidth" connection speed.
Testing it out - success! Only I found that input seemed pretty jerky, and screen updates seemed quite delayed. I traced this to the polling mode of the VNC server - the default settings in PC Takeout's VNC server are set to poll the active window only. Changing this to full screen polling solved the issues with delayed screen updates (I'll probably change this for future PC Takeout Installer releases).
All in all, things worked very nicely, and the client is very happy. Score one for PC Takeout!
16 March 2007
VMWare Server + Xubuntu
Lately, I've been interested in the use of Virtual Machines, fueled in part by the free-ness of products such as VMWare Server and Virtual PC 2007. For a couple months I've been using Microsoft's IE6Test virtual machine in Virtual PC 2004. I do a lot of freelance web development, and as such, I need to test in various web browsers.
Virtual PC 2004 has gotten the job done for its intended purpose - however, I've been annoyed with certain aspects of it. It's sooo slow, and oftentimes, if I have Firefox and IE7 already open, it will simply fail to start the virtual machine due to a lack of RAM (This partly because I've only got 512 measly megs).
Without any particular attachment to VPC, a week ago I stumbled upon VMWare's Virtual Appliance Marketplace. If you've never checked it out, it's a whole bunch of prepackaged, ready-to-run virtual machines, with the configuring done for you. It's like buying a brand new computer for free! My interest in VMWare's offerings was piqued.
Anyway, one thing led to another, and finally today I decided I wanted to give the latest version of Ubuntu (Feisty Fawn) a whirl. Why, what a perfect task for my new totally free VMWare Server!
I decided not to go the prepackaged route, because I wanted to see what installation was like. Also, I decided to go with Xubuntu instead of Ubuntu, because Xubuntu's system requirements are a bit lower than regular Ubuntu, and as I mentioned above, I've only got 512 MB of RAM.
Well, I downloaded the ISO image via a torrent, and fired up VMWare Server to create a new virtual machine. They've even got Ubuntu as one of the distros of Linux in the "New Virtual Machine" wizard, which is pretty cool.
I set the disk size to 10 GB and the RAM to 128 MB, as that is the recommended minimum amount of RAM for Xubuntu.
After setting the CD drive to the Xubuntu ISO, I fired up the virtual machine.
Xubuntu (and I'm guessing the other Ubuntu flavors) runs as a Live CD, from which you can install the OS onto the hard disk by running an Installer program that is conveniently located on the desktop. Pretty slick - although potentially confusing for new users, I didn't have a hard time catching on.
I ran the Installer by double-clicking it, and was a bit annoyed by how slow everything seemed. It took more than a minute before the installer asked me what language I wanted to use. Even after it asked, it took a while before I could click the "Forward" button. All in all, things seemed very unresponsive - not at all what I had been expecting, even if it was in a virtual machine.
A few steps later, the installer was getting ready to partition my virtual hard disk - and it froze. It seemed like it was working, but after leaving it alone for 10 minutes, it was still in the same place. VMWare reported that it was reading the CD like crazy, and my computer's hard disk was intermittently accessing (presumably the ISO), but it wasn't moving anywhere. I decided to try rebooting (I know, I know, Windows mentality - it's hard to kick the habit). This time, the installer froze in the exact same way at the language screen!
At this point, I was a bit frustrated. Then I remembered something that I had forgotten about when I should have been remembering it - using the graphical installer requires 192 MB of RAM! And apparently, it actually does. It would probably be helpful if there was some message in the installer reminding users of this fact.
In any case, I shut down the VM, upped the RAM to 192, and started it back up. And guess what? It installed without a hitch! The installer screens also loaded much quicker, more along the lines of what I was expecting (although there were still some undesirable delays between when a page was viewable and when it was clickable). I'm now in and exploring Xubuntu!
Virtual PC 2004 has gotten the job done for its intended purpose - however, I've been annoyed with certain aspects of it. It's sooo slow, and oftentimes, if I have Firefox and IE7 already open, it will simply fail to start the virtual machine due to a lack of RAM (This partly because I've only got 512 measly megs).
Without any particular attachment to VPC, a week ago I stumbled upon VMWare's Virtual Appliance Marketplace. If you've never checked it out, it's a whole bunch of prepackaged, ready-to-run virtual machines, with the configuring done for you. It's like buying a brand new computer for free! My interest in VMWare's offerings was piqued.
Anyway, one thing led to another, and finally today I decided I wanted to give the latest version of Ubuntu (Feisty Fawn) a whirl. Why, what a perfect task for my new totally free VMWare Server!
I decided not to go the prepackaged route, because I wanted to see what installation was like. Also, I decided to go with Xubuntu instead of Ubuntu, because Xubuntu's system requirements are a bit lower than regular Ubuntu, and as I mentioned above, I've only got 512 MB of RAM.
Well, I downloaded the ISO image via a torrent, and fired up VMWare Server to create a new virtual machine. They've even got Ubuntu as one of the distros of Linux in the "New Virtual Machine" wizard, which is pretty cool.
I set the disk size to 10 GB and the RAM to 128 MB, as that is the recommended minimum amount of RAM for Xubuntu.
After setting the CD drive to the Xubuntu ISO, I fired up the virtual machine.
Xubuntu (and I'm guessing the other Ubuntu flavors) runs as a Live CD, from which you can install the OS onto the hard disk by running an Installer program that is conveniently located on the desktop. Pretty slick - although potentially confusing for new users, I didn't have a hard time catching on.
I ran the Installer by double-clicking it, and was a bit annoyed by how slow everything seemed. It took more than a minute before the installer asked me what language I wanted to use. Even after it asked, it took a while before I could click the "Forward" button. All in all, things seemed very unresponsive - not at all what I had been expecting, even if it was in a virtual machine.
A few steps later, the installer was getting ready to partition my virtual hard disk - and it froze. It seemed like it was working, but after leaving it alone for 10 minutes, it was still in the same place. VMWare reported that it was reading the CD like crazy, and my computer's hard disk was intermittently accessing (presumably the ISO), but it wasn't moving anywhere. I decided to try rebooting (I know, I know, Windows mentality - it's hard to kick the habit). This time, the installer froze in the exact same way at the language screen!
At this point, I was a bit frustrated. Then I remembered something that I had forgotten about when I should have been remembering it - using the graphical installer requires 192 MB of RAM! And apparently, it actually does. It would probably be helpful if there was some message in the installer reminding users of this fact.
In any case, I shut down the VM, upped the RAM to 192, and started it back up. And guess what? It installed without a hitch! The installer screens also loaded much quicker, more along the lines of what I was expecting (although there were still some undesirable delays between when a page was viewable and when it was clickable). I'm now in and exploring Xubuntu!
Subscribe to:
Posts (Atom)
