So this post is a little of topic. You could say it relates to running because it explains how to save time -- time you can spend running. It only relates to Linux in the sense that the Linux technician (me) was trying to help a novice Windows user (Mom) remotely.
The problem that needed fixing was a simple email issue. While the problem was easy to fix, the solution would involve a bit of "click here, now type this" tedium that -- for the sake of familial harmony -- I wanted to spare both of us from. Since the computer in question was about seventy miles away and I'm not Dean Karnazes I decide remote access was the only way to go.
SkyFex
The first candidate was SkyFex. They offer a free, secure remote access solution that will work through firewalls and NAT filters. They don't support Linux, but since my wife has a Windows box and I have a copy of XP running in VM instance, this isn't really a problem. The fact that the free account limits you to controlling the remote machine for just fine minutes is a slightly bigger issue. In fact, it was a deal-killer.
Fog Creek Copilot
Fog Creek's Copilot remote desktop offering turned out to be a the winner. They offer similar features: a small easy download for the client, a secure tunnel between machines regardless of NAT or firewall issues.
What makes them a winner, is the fact that the service is free on weekends. Since this was Saturday afternoon, my cost was zero. Had it been a weekday, I would have been out $5.00 for a "day pass". The setup was easy, just provide a name and agree to the terms of service. Fog Creek didn't even pester me for an email address. The actual session is established by sending the person needing help a link to a small download that, when run, prompts for a invitation code (which you can either read to the person over the phone or let Copilot email the person). Once they enter the code, you've got control.
The Copilot Experience
After taking remote control of the machine, I found copilot to be a bit slugish. Maybe this was because their servers where overwhelmed by people like me taking advantage of the free offer or maybe the free service is throttled. Either way, screen refreshes where not exactly speedy.
Aside from the speed issues, I encountered no problems. I was even pleasantly surprised to find that when a restart was required, the Fog Creek Copilot re-established the link when the system came back online.
Bottom Line
Copilot is a good solution for getting easy access to a remote machine. With a $5.00 day pass during the week and free weekends it is a good choice for helping friends and family. The speed issues I encountered where enough of a problem that I wouldn't want to use on a regular basis. If I found myself needing to remote into the same machine on a regular basis, I would recommend Copilot as "foot in the door" to allow installation of the more robust -- like the Open Source Tiger VNC.
Wednesday, February 16, 2011
Zappos Sets a race record
I don't normally talk about retailers I get my stuff from. I'm terrible about not leaving feedback for auctions. Having said that, I have to comment on my recent Zappos experience. I ordered my new Glycerin 8's on Sunday afternoon. They shipped for free. Given what free shipping normally means, you can imagine my surprise when my wife called me at work the next day to ask if I had ordered some shoes...
Might have been a fluke, but it was impressive none the less. It worked out especially well since I had over slept and need to do a night run on the treadmill. Getting to try out a new pair of shoes (even if they are exactly the same as the pair I just wore out) was a good motivator get a few miles after dinner.
Might have been a fluke, but it was impressive none the less. It worked out especially well since I had over slept and need to do a night run on the treadmill. Getting to try out a new pair of shoes (even if they are exactly the same as the pair I just wore out) was a good motivator get a few miles after dinner.
Tuesday, February 15, 2011
Linux: Clear a log file without breaking things
Often when troubleshooting or debugging a problem with a service you will need to work with one or more log files that has been accumulating cruft for some time unspecified time.
This happened to me when trying to fix a mail server issue. I found myself working with a raw mail log that accumulated every detail of every connection to a production server. While I could search the log for key terms, the volume of data resulted in plenty of false positives for any reasonably short query string. Since most of the data was noise from processes working fine, I found the easiest thing to do was clear the log, try the failing action, view the short log, rinse, grumble and fumble with obscure MTA settings, repeat.
Inappropriate touching
My first instinct was to sudo rm maillog then touch maillog after a moment of consideration, I realized this is a really bad idea. Why? The maillog file is owned by the mail server user (zimbra in my case) and has very specific permissions set on it. In order to properly re-create it, I would have to su zimbra touch maillog then chmod the permissions back the way they should be. Even then I might miss something.
A Better Way to Purge
The Zimbra wiki had a much better, one-line solution:
sudo cat /dev/null > maillog
This quick little one-liner has the desired effect of clearing the the log while retaining permissions and other file properties that removing the file would destroy. There's also something kinda cool about how this works.
Using the cat command causes the supplied file to be dumped to standard output (in this case /dev/null -- which is a pseudo-device -- but also, a file since everything in Linux is a file).
The output of cat /dev/null is guaranteed to be exactly nothing. The greater than redirection operator ( >) says push the output to the specified file, replacing all existing content. Poof. Empty log file with permissions preserved.
I can see being a handy tool to have laying around....Catalina.log I'm looking in your direction....
This happened to me when trying to fix a mail server issue. I found myself working with a raw mail log that accumulated every detail of every connection to a production server. While I could search the log for key terms, the volume of data resulted in plenty of false positives for any reasonably short query string. Since most of the data was noise from processes working fine, I found the easiest thing to do was clear the log, try the failing action, view the short log, rinse, grumble and fumble with obscure MTA settings, repeat.
Inappropriate touching
My first instinct was to sudo rm maillog then touch maillog after a moment of consideration, I realized this is a really bad idea. Why? The maillog file is owned by the mail server user (zimbra in my case) and has very specific permissions set on it. In order to properly re-create it, I would have to su zimbra touch maillog then chmod the permissions back the way they should be. Even then I might miss something.
A Better Way to Purge
The Zimbra wiki had a much better, one-line solution:
sudo cat /dev/null > maillog
This quick little one-liner has the desired effect of clearing the the log while retaining permissions and other file properties that removing the file would destroy. There's also something kinda cool about how this works.
Using the cat command causes the supplied file to be dumped to standard output (in this case /dev/null -- which is a pseudo-device -- but also, a file since everything in Linux is a file).
The output of cat /dev/null is guaranteed to be exactly nothing. The greater than redirection operator ( >) says push the output to the specified file, replacing all existing content. Poof. Empty log file with permissions preserved.
I can see being a handy tool to have laying around....Catalina.log I'm looking in your direction....
Friday, February 11, 2011
Half Marathon With the Count
This post is actually a few days late. I ran my long run (a treadmill half-marathon) a couple days back. So why is treadmill half-marathon worth mentioning? Well because of the in-run movie of course!
I normally only listen to music while on the treadmill because I'm picky about what I'm willing to watch, but 13.1 miles is a long way to go with just tunes and bare walls, so I picked one of the few movies that fits my formula for "treadmill worthy".
Criteria for a Treadmill Worthy Movie
- Most be one I've seen before (to avoid annoyance when the audio is drowned out by the treadmill).
- Must be long enough to last at least 90% off the specified run distance (since I refuse to stop and change the disc if it runs out).
- Must be good enough to keep me distracted during the tough miles, but no so good that I'll want to stop and focus on it
If you've been spared the wrath of the might Count here is a clip of one of my favorite scenes.
Yeah..That was a good run.
Subscribe to:
Posts (Atom)