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.