Against The Cloud

One of our writers is working on an article about hosting your own (project) website on your own iron, instead of doing it the modern, cloudy-servicey way. Already, this has caused quite a bit of hubbub in the Hackaday Headquarters. Who would run their own server in 2022, and why?

The arguments against DIY are all strong. If you just want to spin up a static website, you can do it for free in a bazillion different places. GitHub’s Pages is super convenient, and your content is version controlled as a side benefit. If you want an IoT-type data-logging and presentation service, there are tons of those as well — I don’t have a favorite. If you want e-mail, well, I don’t have to tell you that a large American search monopoly offers free accounts, for the low price of slurping up all of your behavioral data. Whatever your need, chances are very good that there’s a service for you out there somewhere in the cloud.

And that’s awesome if you only want the service provided. But what if you want to play around? Or learn how it all works under the hood? This is Hackaday!

For instance, you could run your own mail server just for your friends and family. The aforementioned search monopolist will probably flag all of your e-mail as spam, partly because they don’t trust small e-mail providers, and partly because that’s the “m” in monopoly. But if you can get folks to whitelist the addresses, you’ll be in business. And then you open up a world of fun and foolery. You can write hooks to automatically handle mail, or you can create an infinite number of mail accounts, even on the fly as per Spamgourmet, the most awesome anti-spam tool of the last 30 years. Or you can invent your own. Run a mailing list for your relatives. Or do something stupid.

I used to run a service where, when a particular account received an e-mail, the attached photo was pushed up to a website with the subject line as the caption. Instant photo-blog, of the strangest and least secure sort. Getting it running was a few lines of Bash scripting, and an afternoon of fun. Is there a service that does this, already existing in the cloud? Probably. One that allows you a little privacy and doesn’t track your every move? Maybe. But even if there is, would I have learned about sendmail by using this service? Nope!

I hear you saying “security” under your breath, and you’re right. This system was secured by lock made of purest obscurity. But still, in seven years of running the service, nobody guessed the magic e-mail address, not once. Knowledge of the e-mail address was essentially a password, but if I needed extra security I probably could have implemented it in a few lines of Bash anyway. The webpage itself was static HTML, so good luck with that, Hackerman! (The site’s been down for a while now, so you missed your chance.)

If you just want a service, you can be served. But if you want to be a server, a first-class Internet citizen, with your own cloud in the sky, nothing’s stopping you either. And in contrast to using someone else’s computers, running your own is an invitation to play. It’s a big, Internet-connected sandbox. There are an infinity of funny ideas out there that you can implement on your own box, and a lot to learn. If you hack on someone else’s box, it’s a crime. If you hack on your own, it’s a pleasure.

I know it’s anachronistic, but give it a try. (PDF, obscenity, uncorrected typos.) Be your own cloud.

DOOM Played By Tweet

Getting DOOM to run on hardware it was never intended to run on is a tradition as old as time. Old cell phones, embedded systems, and ancient televisions have all been converted to play this classic first-person shooter. This style of playing games on old hardware might be passé now as the new trend seems to be the ability to play this game on more ethereal platforms instead. This project brings DOOM to Twitter.

The gameplay is a little nontraditional as well. To play the game, a tweet needs to be sent with specific instructions for the bot. The bot then plays the game according to its instructions and then tweets a video. By responding to this tweet with more instructions, the player can continue the game tweet-by-tweet. While slightly cumbersome, it does have the advantage of allowing a player to resume any game simply by responding to the tweet where they would like to start. Behind the scenes of the DOOM-playing Twitter bot is interesting as well and the code is available on the project’s GitHub page.

While we’ve seen plenty of DOOM instances on all kinds of hardware, it’s safe to say we’ve never really seen a gameplay experience quite like this one. It may stay as a curiosity, but DOOM porters are always looking for something else to run this classic game so it may eventually branch out or develop into something more user-friendly like this cloud-based Atari 2600.

Spaghetti Detective Users Boiled By Security Gaffe

For readers that might not spend their free time watching spools of PLA slowly unwind, The Spaghetti Detective (TSD) is an open source project that aims to use computer vision and machine learning to identify when a 3D print has failed and resulted in a pile of plastic “spaghetti” on the build plate. Once users have installed the OctoPrint plugin, they need to point it to either a self-hosted server that’s running on a relatively powerful machine, or TSD’s paid cloud service that handles all the AI heavy lifting for a monthly fee.

Unfortunately, 73 of those cloud customers ended up getting a bit more than they bargained for when a configuration flub allowed strangers to take control of their printers. In a frank blog post, TSD founder Kenneth Jiang owns up to the August 19th mistake and explains exactly what happened, who was impacted, and how changes to the server-side code should prevent similar issues going forward.

Screenshot from TSD web interface
TSD allows users to remotely manage and monitor their printers.

For the record, it appears no permanent damage was done, and everyone who was potentially impacted by this issue has been notified. There was a fairly narrow window of opportunity for anyone to stumble upon the issue in the first place, meaning any bad actors would have had to be particularly quick on their keyboards to come up with some nefarious plot to sabotage any printers connected to TSD. That said, one user took to Reddit to show off the physical warning their printer spit out; the apparent handiwork of a fellow customer that discovered the glitch on their own.

According to Jiang, the issue stemmed from how TSD associates printers and users. When the server sees multiple connections coming from the same public IP, it’s assumed they’re physically connected to the same local network. This allows the server to link the OctoPrint plugin running on a Raspberry Pi to the user’s phone or computer. But on the night in question, an incorrectly configured load-balancing system stopped passing the source IP addresses to the server. This made TSD believe all of the printers and users who connected during this time period were on the same LAN, allowing anyone to connect with whatever machine they wished.

Changed TSD code from GitHub
New code pushed to the TSD repository limits how many devices can be associated with a single IP.

The mix-up only lasted about six hours, and so far, only the one user has actually reported their printer being remotely controlled by an outside party. After fixing the load-balancing configuration, the team also pushed an update to the TSD code which puts a cap on how many printers the server will associate with a given IP address. This seems like a reasonable enough precaution, though it’s not immediately obvious how this change would impact users who wish to add multiple printers to their account at the same time, such as in the case of a print farm.

While no doubt an embarrassing misstep for the team at The Spaghetti Detective, we can at least appreciate how swiftly they dealt with the issue and their transparency in bringing the flaw to light. This is also an excellent example of how open source allows the community to independently evaluate the fixes applied by the developer in response to a discovered flaw. Jiang says the team will be launching a full security audit of their own as well, so expect more changes getting pushed to the repository in the near future.

We were impressed with TSD when we first covered it back in 2019, and glad to see the project has flourished since we last checked in. Trust is difficult to gain and easy to lose, but we hope the team’s handling of this issue shows they’re on top of things and willing to do right by their community even if it means getting some egg on their face from time to time.

Cloud-Based Atari Gaming

While the Google Stadia may be the latest and greatest in the realm of cloud gaming, there are plenty of other ways to experience this new style of gameplay, especially if you’re willing to go a little retro. This project, for example, takes the Atari 2600 into the cloud for a nearly-complete gaming experience that is fully hosted in a server, including the video rendering.

[Michael Kohn] created this project mostly as a way to get more familiar with Kubernetes, a piece of open-source software which helps automate and deploy container-based applications. The setup runs on two Raspberry Pi 4s which can be accessed by pointing a browser at the correct IP address on his network, or by connecting to them via VNC. From there, the emulator runs a specific game called Space Revenge, chosen for its memory requirements and its lack of encumbrance of copyrights. There are some limitations in that the emulator he’s using doesn’t implement all of the Atari controls, and that the sound isn’t available through the remote desktop setup, but it’s impressive nonetheless

[Michael] also glosses over this part, but the Atari emulator was written by him “as quickly as possible” so he could focus on the Kubernetes setup. This is impressive in its own right, and of course he goes beyond this to show exactly how to set up the cloud-based system on his GitHub page as well. He also thinks there’s potential for a system like this to run an NES setup as well. If you’re looking for something a little more modern, though, it is possible to set up a cloud-based gaming system with a Nintendo Switch as well.

Continue reading “Cloud-Based Atari Gaming”

Emulating A Power Grid

The electric power grid, as it exists today, was designed about a century ago to accommodate large, dispersed power plants owned and controlled by the utilities themselves. At the time this seemed like a great idea, but as technology and society have progressed the power grid remains stubbornly rooted in this past. Efforts to modify it to accommodate solar and wind farms, electric cars, and other modern technology need to take great effort to work with the ancient grid setup, often requiring intricate modeling like this visual power grid emulator.

The model is known as LEGOS, the Lite Emulator of Grid Operations, and comes from researchers at RWTH Aachen University. Its goal is to simulate a modern power grid with various generation sources and loads such as homes, offices, or hospitals. It uses a DC circuit to simulate power flow, which is visualized with LEDs. The entire model is modular, so components can be added or subtracted easily to quickly show how the power flow changes as a result of modifications to the grid. There is also a robust automation layer to the entire project, allowing real-time data acquisition of the model to be gathered and analyzed using an open source cloud service called FIWARE.

In order to modernize the grid, simulations like these are needed to make sure there are no knock-on effects of adding or changing such a complex system in ways it was never intended to be changed. Researchers in Europe like the ones developing LEGOS are ahead of the curve, as smart grid technology continues to filter in to all areas of the modern electrical infrastructure. It could also find uses for modeling power grids in areas where changes to the grid can happen rapidly as a result of natural disasters.

Raspberry Pi 4 Brings Cloud Gaming To Nintendo Switch

Companies like Google and Microsoft have been investing heavily in the concept of cloud gaming, where a player uses their computer or a mobile device to stream the video feed of a game that’s running on powerful machine tucked away in a data center somewhere. With this technology you can play the latest and greatest titles, even if the device you’re using doesn’t have the processing power to run it locally.

Considering the Switch is already a portable system, it’s not too surprising Nintendo doesn’t seem interested in the technology. But that didn’t stop [Stan Dmitriev] from doing a bit of experimentation on his own. With little more than a Raspberry Pi 4 and Trinket M0, he’s demonstrated that users can remotely interact with the Switch well enough to play games in real time.

The setup is fairly straightforward. A cheap HDMI capture device is used to grab the video from the Nintendo Switch dock, which is then streamed out to web with the help of the Pi’s hardware video encoder. Input from the user is sent over the Pi’s UART to the Trinket, which itself is running a firmware specifically developed for mimicking Nintendo Switch controllers. With so many elements involved, naturally some latency comes into play. The roughly 100 millisecond delay [Stan] is reporting isn’t exactly ideal for fast-paced gaming, but is certainly adequate for more relaxed titles.

On the software side of things, the project is using a SDK developed by [Stan]’s employer SurrogateTV. Right now you need to apply if you want to get your game or other interactive gadget up on the service, though he says it will be opened up to the public next year. But even without all the details, we’ve got a clear idea of how both the video capture and user input sides of the equation are being handled. For personal use, all you’d really need to do is put together a simple web interface to tie it all together.

This isn’t the first time we’ve seen a microcontroller used to interface with the Switch. Other consoles are a bit more selective about what kind of hardware they will talk to, but the Microsoft Adaptive Controller could potentially allow you to do something similar on the Xbox.

Linux Fu: Send In The (Cloud) Clones

Storing data “in the cloud” — even if it is your own server — is all the rage. But many cloud solutions require you to access your files in a clumsy way using a web browser. One day, operating systems will incorporate generic cloud storage just like any other file system. But by using two tools, rclone and sshfs, you can nearly accomplish this today with a little one-time setup. There are a few limitations, but, generally, it works quite well.

It is a story as old as computing. There’s something new. Using it is exotic and requires special techniques. Then it becomes just another part of the operating system. If you go back far enough, programmers had to pull specific records from mass storage like tapes, drums, or disks and deblock data. Now you just open a file or a database. Cameras, printers, audio, and even networking once were special devices that are now commonplace. If you use Windows, for example, OneDrive is well-supported. But if you use another service, you may or may not have an easy option to just access your files as a first-class file system.

The rclone program is the Swiss Army knife of cloud storage services. Despite its name, it doesn’t have to synchronize a local file store to a remote service, although it can do that. The program works with a dizzying array of cloud storage providers and it can do simple operations like listing and copying files. It can also synchronize, as you’d expect. However, it also has an experimental FUSE filesystem that lets you mount a remote service — with varying degrees of success.

What’s Supported?

If you don’t like using someone like Google or Amazon, you can host your own cloud. In that case, you can probably use sshfs to mount a file using ssh, although rclone can also do that. There are also cloud services you can self-host like OwnCloud and NextCloud. A Raspberry Pi running Docker can easily stand up one of these in a few minutes and rclone can handle these, too.

Continue reading “Linux Fu: Send In The (Cloud) Clones”