Helping Linux applications play sounds on remote Windows and Linux machines

(If you just want the good stuff and don’t care about the story, visit the snd2remote web page. Bottom line: run a listener on the LAN, then on a Linux box type “snd2remote C:/WINDOWS/Media/ding.wav”)

Problem: You’re running applications on a remote Linux system across a LAN, possibly using an X server such as Xming or x11vnc to view them on a Windows machine.  The programs run fine, displaying on the Windows machine, but there is no way to hear notifications on events such as receiving an email or IM. Every program has an option that lets you “run a custom command” on notification events, or has an available add-on that enables this functionality. There is no custom command that makes sounds play on the Windows machine you’re actually using.

Solution: Roll your own solution using free tools that are already available!

I use Mozilla Thunderbird for email and Pidgin for all instant messaging services. For two years, I have sat directly in front of the server at the shop and used these applications. Now, however, I use an old Windows laptop that we can’t sell for technical reasons along with Xming to run these Linux apps on my sever and show them as apps on my Windows laptop.  Unfortunately, as I have been getting busier and busier, I have been forgetting to periodically check my mail window.  Thunderbird in Xming has no tray mail notification and no sound on the Windows machine at all; likewise with Pidgin, which (at best) can put a star in the chat window title.  However, Pidgin on Linux comes with an option to “use a custom command” for playing sounds.  Thunderbird doesn’t, but an add-on easily adds “during new mail notification, run this command” capabilities to it.

So, I know that I CAN do this if I can run a command which plays the sound on the Windows machine, but a brief Google hunt turns up nothing of interest.  Oh, I’m sure somehow I can use JACK or some other complicated audio system, but I could care less about setting that up and dealing with the extra admin overhead if there’s a simpler way!

It takes some real Linux geek thought processes to do, but I figured out a way that, regardless of which machine in my shop I sit at, I can get audio notifications for my Xming apps (or any app that can run a command to play a sound for that matter).  The answer: UDP broadcast the sound you want to play to all the machines on the network.

I created a bash shell script and a Windows NT/2000/XP command prompt  batch file (it uses SET /P which I don’t think DOS/Win9x/Me have) that pair together to trigger sounds on my Windows machine from my Linux machine. An additional constraint which I artificially imposed on myself to minimize the number of required downloaded files was to only use Windows batch commands and not “cheat” by pulling a UNIX-style shell, sed, grep, and other UNIX commands.  This also forced me to learn some ways to do things in a batch file that I had never done before, meaning that not only do I make this easier to duplicate for others, but I’ll be a better Windows admin too.

I had to download the following free tools and Linux packages to make it work (links provided):

• socat on Linux (netcat doesn’t let you broadcast UDP)
• A native win32 port of netcat (as nc.exe) from Jesse Morgan’s website
• PlayWav from Mu Consulting (to play WAV files, I originally used Media Player Classic but it was very slow)
• Mailbox Alert add-on for Mozilla Thunderbird (for running a custom command as a notification)

Here’s how we do it. The computer which is generating the notification event needs to order the computer at which we’re actually sitting to play some sort of sound. Ideally, we need to be able to play lots of different sounds, too. So, the quick and easy solution was to use socat (and netcat for Windows since there’s no native socat port) to broadcast the names of sound files to play and receive those broadcasted names, then try to play them.  Most of the time I spent was actually on file scanning and filtering code rather than making the *cat tools behave nicely.

“snd2remote” on Linux can both listen for events AND broadcast them, and does some fairly clever search tricks to try very hard to play a WAV file that is not valid for the Linux machine as-is.  The Windows version is restricted to batch file commands, which means it’s much “dumber” and therefore needs more hand-holding; most of the clever logic is in the Linux side so the Windows side can afford to be dumbed down.

snd2remote taught me the following lessons and/or has the following nice features:

1. You can make netcat exit immediately on receipt of a single UDP packet in listen mode by piping an empty “echo” into it. This drastically decreases latency because the 1-second timeout is unnecessary.
2. The way to remove timeout latency in socat is to specify a “udp4-recvfrom” endpoint instead of “udp4-listen” and also specify the “unidirectional” switch.
3. Translating to backslashes for dumb Windows batch listeners and letting Linux listeners translate them back to normal forward slashes makes life a thousand times easier.
4. Making the Linux version assume UNC paths such as \\server\share\path\file.wav equals /home/share/path/file.wav on the Linux side allows the use of a default Samba home directory share as a source for both machines to fetch the same WAV files from.
5. Letting the Linux script perform quick scans in a couple of obvious locations for alternate copies of the specified file makes it extremely easy to feed Windows-specific paths and have them still play on the Linux listeners without replicating the path to the same file on Windows.
6. snd2remote in listen mode checks the ROOT of the executing user’s home directory, does full subdirectory scanning of a custom directory (defaults to $HOME/media), and performs the previously mentioned UNC path to home directory translation, in an exhaustive effort to find a playable copy of the requested WAV file.
7. It’s better to use the shell construct $(commands) than to use (backticked) `commands` because the latter interprets special characters in a way that makes life very painful.

By running “snd2remote -l” on a Linux box or “snd2remote-listener.bat” on a Windows box, any other Linux box on the LAN can broadcast a sound event to all listening computers with a simple command:

snd2remote [-q] /path/to/file.wav

For example, to play the classic Windows “ding” on all listeners:

snd2remote C:/WINDOWS/Media/ding.wav

If you are interested in the internal workings of these scripts, they are heavily commented to explain in detail what is going on.  Lots of shell/command interpreter constructs and command combinations are used in them which I had not needed, or had rarely used, before; therefore, these scripts would be a good starting point to nudge your way into some interesting scripting.

The code has grown too long and complex to document everything here, but it is freely available at the c02ware snd2remote page.

“socat” as a UDP beacon (a Tritech Service System technology preview)

One of the greatest things in the world about Linux is the amount of flexibility it gives a person in creating a solution to a problem, and I found myself faced with yet another situation where this became relevant lately.  Some background is in order before I get to the point of the story, however, so grab your popcorn and soda, and prepare to be astonished!

As many readers will no doubt know, I am hard at work on Tritech Service System 3.0, the next incarnation of c02ware’s Linux distribution which we use regularly in our shop.  Since TSS is primarily developed with the needs of a computer repair service business in mind, we obviously look for ways to help TSS help us do our jobs, which is where some of the strange and unique features I’ve come up with originate.  One of the most novel ideas has been that of having a TSS CD which doesn’t require upgrading, because every upgrade cycle I’m forced to distribute new burned CDs to all of the technicians and rewrite all of our bootable USB flash drives for the new system.  TSS 3.0 will have the ability to upgrade over a network automatically during early startup.

Being able to self-upgrade before running anything very important is difficult, however, primarily due to the fact that it’s easy to make a messy solution that works in a specific case, but very hard to make a clean solution that works 99% of the time.  I’ve been writing custom scripts for the private TSS CDs that specifically refer to our core server by its internal IP address, meaning if it’s not on our network or the server’s down for any reason, there’s no way to run that script.  Making them generic, where they would automatically locate a suitable server clone such as a mirror on an external hard drive, is much harder, because you have to scan for things and, if using a network resource but not having its IP pre-programmed, you have to discover that resource somehow, without any prior knowledge of its existence.

Yes, this is all sort of straying from the point of the post, but I’m building up to it, so bear with me for a moment longer.

THE QUESTION:  “How can I find a network resource containing files I need, even if I have no idea what the server’s IP address is…AND get 100% of the information required to access those files without any manual user intervention?” Nothing that I could think of immediately seemed to be a viable solution, other than perhaps somehow pulling a particular network name via Samba and using that, but then I considered that perhaps the server itself might want to be running TSS with the default hostname of…well, “tss” (which obviously presents a problem, one which will also be fixed at some point!)  Then it started to hit me: what if we could somehow set up a “beacon” that would magically tell every “beacon-capable” TSS on the network that the beacon sender is a server?

Eureka!  …but not so fast…

The first thing that came to mind was, of course, good old fashioned netcat.  Netcat  (or just nc) is notoriously useful software that does a very simple thing: provide a way to pipe commands and information over TCP and UDP connections.  Well, netcat definitely would have done the job, so I tried something similar to this, to pipe a “configuration string” via UDP to the broadcast IP address for the LAN I was on at the time:

echo “12.34.56.78 share path/to/file username password” | nc -u 192.168.0.255 9999

Unfortunately, all  kinds of really freakin’ weird socket errors were spit out, and it totally choked on me.  Apparently you can’t use netcat to do UDP broadcast on Linux for some reason (at least, not GNU netcat).  I was extremely disappointed, and I started to research netcat to see if there was some sort of solution.  I hit a forum post that mentioned socat and looked it up.  Holy cow, I hit jackpot!

socat is referred to by many as “netcat on steroids” and now I can see why.  Where netcat is a simple TCP or UDP pipeline tool, socat is a much more generic socket-to-socket version cat (thus “socat,” or “socket cat”).  This bad boy can hook up UNIX sockets, files on disk, standard input/output/error, TCP, UDP, raw IP with no protocol, and more, bidirectionally, and without restrictions on which can be input or output.  The help text for the usable socket modes alone is over 50 lines long, and it doesn’t complain at all if I try to use it to do a UDP broadcast.

What happened when I tried it out?  Check it out:

# socat UDP4-LISTEN:9999 GOPEN:foo &
[1] 14130
# echo "192.168.0.100 share path/to/files username password" | \
> socat - UDP4-DATAGRAM:192.168.0.255:9999,broadcast
# cat foo
192.168.0.100 share path/to/files username password
[1]+  Done                    socat UDP4-LISTEN:9999 GOPEN:foo

Of course, this was all on the same machine, so I tried something on an old Linux router box on the network which I can’t use socat on for technical reasons.  With GNU netcat listening, the exact same configuration beacon broadcast came in perfectly:

$ nc -u -l -p 9999
192.168.0.100 share path/to/files username password

What does all of this silly stuff mean in the end?

With some clever scripting, Tritech Service System 3.0 will be able to automatically update itself from any server on the LAN. That means that when TSS 3.0.1 or 3.1 or even 4.0 appear, one machine running the newer version in its default configuration will be able to give its updated packages to all other machines on the network without any user intervention required. That means I can set up a TSS package repository on my main server and set up a TSS package beacon, and all of the TSS 3.0 CDs and flash drives I give to technicians won’t ever need to be replaced or rewritten just to get updated packages.  Bug fixes from one running new version will automatically propagate to older ones.  If I make a custom package that isn’t part of mainstream TSS, such as our custom scripts, they can be distributed only to private installations by the on-location server rather than being burned to the CD, eliminating the need for special private versions of TSS for in-shop use.

This, combined with an enhanced package acquisition system, dependency management, lower memory usage, persistent directories, and a host of other features will make Tritech Service System 3 one of the most flexible live Linux distributions in existence.

Time ensures that things rarely remain the same.

At Tritech, many things have changed since even just one month ago.  Here’s a spiffy list of such things.  By the way, my new favorite word is “terse.”  The magic of the word “terse” is that practically all of its synonyms not as terse as “terse.”  It’s a self-fulfilling definition!  ^_^  So, what’s been going on during my silence, you ask?  Read on!

• My Sylvania G has an unusual issue with the custom Linux installs I’ve done on it where the keyboard and mouse touchpad stop working.  This didn’t happen while I had Windows XP on it whatsoever, nor the custom gOS that came with the computer, so I’m fairly sure it has something to do with a more generic (read: not G-specific) Linux distro running on the VIA CX700M2/C7-M platform.  I doubt it’s the hardware itself because of this.  The headphone jack worked on XP, but not on my custom Linux, which apparently is caused by an incorrect HD Audio pin mapping in the HD Audio drivers in the stock Linux kernel.  I’m not too concerned about it, though, since I haven’t needed to use it much at all lately.
• I’m still working on the custom Tritech Service System.  It’s grown from a very humble project to simply give us basic remote access to a machine in a clean operating environment to a much more useful general service system.  Big secret: it’s a Linux-based project.  The entire “distro” is essentially built from scratch, however, and uses such classic tools as busybox to minimize space usage.  What really sets TSS apart from the Linux solutions we’re using now such as KNOPPIX (CD) and Slax (USB drive) is the fact that the entire system runs out of an initramfs, eliminating the need to find the rest of the system after booting has started.  This presents some extremely tough limitations, but solves the biggest problems I’ve run into with Linux live CD and Linux live USB distributions.  Sometimes the rest of the system can’t be located at boot-time, which on KNOPPIX in specific “crashes” to a “very minimal shell” in which you can essentially do nothing at all.  When a CD drive is old, dirty, or otherwise impaired, you can have these failures as well as major problems when the KNOPPIX cloop driver chokes on every little scratch in the disc surface.  Slax sucks because it constantly spews out OOPSes in the kernel log when you don’t use a “fresh mode” to boot, and since it doesn’t come with any of the specific tools we need (and the only way to properly add them is to make a squashfs thing I don’t feel like dealing with) it’s a huge pain in the rectum.  Enter the Tritech Service System: completely customized for our own exact needs, reliant only on the bootloader working as expected and not locking a CD drive or USB flash drive in the process, and EXTREMELY FAST to work with.  Plus I made a cool green-on-black splash screen to go with it.  The fact that it easily installs on any Windows XP machine as a boot menu option seals the deal.  NO OTHER COMPUTER SERVICE COMPANY HAS THIS POWERFUL TOOL.  Granted, any sufficiently skilled Linux nut could do what I’ve done, but most Linux nuts would rather deal with KNOPPIX forever than go to the trouble of making their own custom distro from scratch.  The lack of Linux-knowledgeable techs out there makes it impractical for a large company to even bother with.  Now all of you that thought my claim of being the only company that is capable of doing this was audacious can understand exactly why I can make that claim and support it.  We’re not to the point that I’m willing to release it to the public yet, but it’s been so much better than KNOPPIX or Slax on every system I can boot it on that I’ve fast-tracked my development on it and I’m making it a very high priority on my list of things to do.  Stay tuned.
• We cleaned up the shop.  I’m not kidding: we REALLY CLEANED UP THE SHOP, big time.  One unfortunate problem with computer geeks is a complete lack of organization, particularly with a shop as busy as mine usually is.  We didn’t have many customers at all over the past week, so I took full advantage of the opportunity to give the place a brutal cleaning.  We’ve moved all the security camera equipment, run permanent wires that we’ve been using temps for for months now, purchased lots of additional storage bins and shelving and made excessive use of all of it, organized and better proceduralized the process of shuffling customer equipment in and out and keeping said equipment organized and together, tossed out an insane number of disintegrating cardboard boxes we REALLY didn’t need, built a central working “kiosk” at the front of the shop where we can print invoices and perform other administrative tasks (where previously all of this work was done on our own individual workstations in the back of the shop), optimized the table configuration for better access to existing power and network cables, completely cleared off the bird’s nest of wires that had formed on the front tables due to lots of working and no time to clean up after it, and a ton of other minor things I don’t even want to think about right now.
• I mowed the lawn at my house.  Like an idiot, I did so at 4 PM instead of waiting until it started to get cooler in the evening.  Boy, push mowers SUCK.
• Yes, the last item was comic relief.  So is this one.
• I recently managed to use Linux to fully change XP HALs, rendering all of my disparate XP “clean system images” obsolete.  I’m actually looking at ways to get chntpw/reged to be easily scripted.  They’re the most useful and most underdeveloped Windows tools on Linux that I know of, and a reged that is inherently script-friendly (without using expect) would be a boon to the Tritech Service System, as well as frustrated sysadmins in general around the world.  With a fully scriptable reged/chntpw, I can write a simple package for TSS that replaces HALs on images without any additional effort, making life much easier for my technicians (and myself) in the long run!
• We also created a custom HAL.INF file that opens up access to all the XP HALs from XP itself.  Reverting to “Standard PC” pre-imaging and then using this file in the images to allow changing to, say, “ACPI Multiprocessor PC” would be much easier than having six images per XP type (home retail/OEM, pro retail/OEM, MCE OEM) and would save TONS of disk space on the poor old server.
• I’m also writing a custom Web-based Tritech administration system using PHP and MySQL (well duh), which will let me throw a bunch of crap out of my filing cabinet and go nearly paperless.  Invoice creation will also be much easier, because invoices, work orders, and inventory usage share huge amounts of information between them already, so invoice creation would essentially be a two-click thing for most jobs.
• We raised our prices.  Let’s face it: we charge by the half-hour already, and $80 per hour is outrageously cheap for access to my skills and the skills of the technicians I contract work to and teach my ways to.  We may need to go up again, and I’d love some feedback on that.  I feel that we should because we’re selling a level of quality that Siler City, Pittsboro, Goldston, and all the other towns in Chatham County can’t get within an hour’s driving distance, but of course I fear pricing myself out of business at the same time.  Given the economic climate right now, I’m not keen on going up too fast, but we could use some capital SOON.  Plus, that pesky $65,000 in small business loans is still hanging over my head, sucking up essentially all of the “profits” and converting them to expenses.  The rest is used to buy what we need to keep serving customers in the future.  Even if we charged $100 per hour, our competitors’ bench fees and rates put them at or above that price tag on almost every job, and unfortunately Chatham County’s pre-existing computer service shops apparently have the worst customer service and/or technical skill you can imagine, considering we hear horrible anecdotes from multiple customers on a DAILY BASIS about who we’re supposedly “competiing with.”  I’d hardly call them competition at this point; we’ve had two separate laptops come in that I personally serviced where Siler City’s established computer shop I won’t name had charged $100 or more to look at each and came back with the answer that “it’s unfixable, you need to buy a new laptop.”  In both cases, I fixed the problem in less than five minutes.  One was a loose LCD data cable behind the laptop screen, the other was a RAM stick either making bad contact or the SODIMM socket going out (I moved the stick from one socket to the other.)  I’m so upset when these things happen, and I know I shouldn’t be, but I feel that these things tarnish the reputation of the industry as a whole and bring customers to my door wondering if I’m going to screw them over before they’ve even met anyone on my staff.  I digress a bit, though; should I raise prices from $40 per half hour to $50 per half hour?  What do you think?
• We now have four technicians that come here to get jobs regularly, and all of them are awesome at what they do.  They really care about my customers, and that’s what I like!

That’s about it for now.  I have a repair job I’m working on that I must return to, so I have to wrap this post up.  A construction company owner and long-time client of mine got a HORRIBLE virus infection, and I have gone very far out of my way to personally see to it that he’s back up by 8 AM tomorrow (Monday) morning.  His system went down completely on Friday.  If you’re a client or potential client of my business, I want you to know that just like I’m doing for his business, I will bend over backwards and do whatever I must to make sure you’re taken care of.  I’ll post more anecdotes about how I do this later.  That’s all, folks.  Happy computing!

Why I love my (original) Sylvania G netbook (and how to fix its “issues” easily)

UPDATE: THIS IS NOT ABOUT THE UNDER-$200 NETBOOK WITH WINDOWS CE, WHICH IS A TOTAL PIECE OF JUNK. Please don’t ask me about those. They’re junk.

My Sylvania G netbook.

If the tips in this entry help you, please send me an E-mail message letting me know!  I GREATLY appreciate feedback!

A lot of professional reviewers out there seem to have nothing but bad comments on the original (non-Meso) Sylvania G netbook.  I bought one of these puppies for $300 and felt like I was getting quite the steal.  Then again, I’m a Linux user, so I feel more “at home” with a Linux laptop (though my primary line of work is obviously fixing all the problems under Microsoft’s OS every day of my life).  I love my Sylvania G.  It’s tiny, light, the battery lasts forever, people look at it and think I’m watching a DVD on a portable DVD player rather than computing, its wireless actually works far better than I expected…the list goes on.  Granted, it lacks some software that I’d like, but for its primary purposes (Internet browsing, light office apps, maybe an MP3 here and there), it does the job beautifully.  I wish it had all the shortcuts to all the control panels available, but they’re not there because the 800×480 WVGA screen can’t handle them vertically; I’ll tell you how to bypass the vertical issue in a minute.

The main reason I’m writing this is not to explain why my G is so awesome, but rather how to make it that way.  The number one complaint about the G is its postage-stamp sized mouse trackpad, and believe it or not, the laptop comes with the tools needed to fix the insane acceleration that it comes with by default (no more “buy a USB mouse if you’re going to buy this laptop” complaints!)  The biggest advantage of the G over the practically identical Everex Cloudbook (which the G is basically a rebranded version of) is that unlike the Cloudbook, with its moronic “mouse buttons on the left side of the unit, mouse trackpad on the right” layout, the G has the touchpad assembly below the keyboard, WITH THE BUTTONS IMMEDIATELY BESIDE THE PAD.  That leaves the excessive tracking speed (where you can just lift your finger off the pad and the mouse moves two inches across the seven-inch LCD) as the only remaining issue, and HERE IS HOW TO FIX THE SYLVANIA G NETBOOK POINTER TRACKING SPEED, STEP BY STEP!

(This section has been moved to the Tritech Computer Solutions page called Sylvania G Netbook Tips and Tricks.)

For $300, and with my tips above, the original Sylvania G is an absolute gem.  You simply can’t beat its value unless you drop another $100 on an Acer Aspire One (what I originally wanted but couldn’t justify purchasing.)  Once you slow down the mouse and add some launchers for some helpful applications, the G starts to look far better than it may have on display in the store.  I don’t know about the Meso, but I don’t care, because I’ve found the perfect laptop for my needs and that’s the end of the story!  I absolutely LOVE my G!

Once again, please send me feedback if this helps you out!