HOWTOs

Running GNOME in a Container

Adam Verslype — Wed, 07 Aug 2019 19:00:00 +0000

Containerizing the GUI separates your work and play.

Virtualization has always been a rich man's game, and more frugal enthusiasts—unable to afford fancy server-class components—often struggle to keep up. Linux provides free high-quality hypervisors, but when you start to throw real workloads at the host, its resources become saturated quickly. No amount of spare RAM shoved into an old Dell desktop is going to remedy this situation. If a properly decked-out host is out of your reach, you might want to consider containers instead.

Instead of virtualizing an entire computer, containers allow parts of the Linux kernel to be portioned into several pieces. This occurs without the overhead of emulating hardware or running several identical kernels. A full GUI environment, such as GNOME Shell can be launched inside a container, with a little gumption.

You can accomplish this through namespaces, a feature built in to the Linux kernel. An in-depth look at this feature is beyond the scope of this article, but a brief example sheds light on how these features can create containers. Each kind of namespace segments a different part of the kernel. The PID namespace, for example, prevents processes inside the namespace from seeing other processes running in the kernel. As a result, those processes believe that they are the only ones running on the computer. Each namespace does the same thing for other areas of the kernel as well. The mount namespace isolates the filesystem of the processes inside of it. The network namespace provides a unique network stack to processes running inside of them. The IPC, user, UTS and cgroup namespaces do the same for those areas of the kernel as well. When the seven namespaces are combined, the result is a container: an environment isolated enough to believe it is a freestanding Linux system.

Container frameworks will abstract the minutia of configuring namespaces away from the user, but each framework has a different emphasis. Docker is the most popular and is designed to run multiple copies of identical containers at scale. LXC/LXD is meant to create containers easily that mimic particular Linux distributions. In fact, earlier versions of LXC included a collection of scripts that created the filesystems of popular distributions. A third option is libvirt's lxc driver. Contrary to how it may sound, libvirt-lxc does not use LXC/LXD at all. Instead, the libvirt-lxc driver manipulates kernel namespaces directly. libvirt-lxc integrates into other tools within the libvirt suite as well, so the configuration of libvirt-lxc containers resembles those of virtual machines running in other libvirt drivers instead of a native LXC/LXD container. It is easy to learn as a result, even if the branding is confusing.

Go to Full Article

Digital Will, Part I: Requirements

Kyle Rankin — Fri, 07 Jun 2019 12:30:00 +0000

by Kyle Rankin

Digital assets are becoming as important as physical assets, so how do you manage them after you die?

When you lose a member of your family, you may find yourself at some point thinking about your own mortality, which then may lead you to think through preparations for your own death. I lost my father recently, but years before his death, he set up a will that described how to manage his estate, but he also made sure to share with me login details for his important financial accounts so I would have access when the time came. When the time did come to put his plans into practice, those details were invaluable.

All of this made me realize just how complicated it would be for someone to manage my own accounts in the event of my death, especially considering how much effort I've gone through to secure my computers and accounts. After all, unlike my dad, I don't use the same password for everything. What I realized I needed was the equivalent of a digital will: instructions and credentials so my next of kin had everything they needed to access my accounts and manage my affairs. In this first article of what will be a two-part series, I describe the requirements and plans to create a digital will in a way that would be manageable for my next of kin while also not negatively affecting the security of my accounts. The second part of the article will describe how I implemented these plans.

Defining Terms

This digital will is based on many of the ideas behind a traditional will, and I intend on borrowing a lot of the framework and terms instead of "re-inventing the will". To get started, let me define a few terms, but I should make it clear that I'm not an attorney, so these are just loose definitions to describe how some common terms used in a will might be applied to this digital will:

Go to Full Article

Build Your Own Internet Radio Receiver

Nick Tufillaro — Mon, 27 May 2019 11:00:00 +0000

by Nick Tufillaro

Tune in to communities around the world with the push of a button.

When I get home at night, I like to tune into the world with the push of a button. I've lived in lots of different places—from Dunedin, New Zealand, to Santa Fe, New Mexico—and in each town, I've come to love a radio station (usually a community radio station) that embodies the spirit of the place. With the push of a button, I can get a bit back in sync with each of these places and also visit new communities, thanks to internet radio.

Why build your own internet radio receiver? One option, of course, is simply to use an app for a receiver. However, I've found that the most common apps don't keep their focus on the task at hand, and are increasingly distracted by offering additional social-networking services. And besides, I want to listen now. I don't want to check into my computer or phone, log in yet again, and endure the stress of recalling YAPW (Yet Another PassWord). I've also found that the current offering of internet radio boxes falls short of my expectations. Like I said, I've lived in a lot of places—more than two or four or eight. I want a lot of buttons, so I can tune in to a radio station with just one gesture. Finally, I've noticed that streams are increasingly problematic if I don't go directly to the source. Often, streams chosen through a "middle man" start with an ad or blurb that is tacked on as a preamble. Or sometimes the "middle man" might tie me to a stream of lower audio quality than the best being served up.

So, I turned to building my own internet radio receiver—one with lots of buttons that allow me to "tune in" without being too pushy. In this article, I share my experience. In principle, it should be easy—you just need a Linux distro, a ship to sail her on and an external key pad for a rudder. In practice, it's not too hard, but there are a few obstacles along the course that I hope to help you navigate.

My recipe list included the following:

A used notebook with an ultra low voltage (Core 2 Duo) processor.
An audio interface with an optical TOSLINK.
pyradio: an open-source Python radio program.
An external keypad.

Figure 1. My Hardware Setup

Why a notebook and not a Raspberry Pi or ship of a similar ilk? Mostly due to time—my time in particular. It's not too hard to find a high quality notebook about ten years old for about $50, so the cost is really not that different, and I find the development platform to be much quicker.

Go to Full Article

Testing Models

Reuven M. Lerner — Thu, 29 Jun 2017 11:20:14 +0000

by Reuven M. Lerner

In my last few articles, I've been dipping into the waters of "machine learning"—a powerful idea that has been moving steadily into the mainstream of computing, and that has the potential to change lives in numerous ways. The goal of machine learning is to produce a "model"—a piece of software that can make predictions with new data based on what it has learned from old data.

One common type of problem that machine learning can help solve is classification. Given some new data, how can you categorize it? For example, if you're a credit-card company, and you have data about a new purchase, does the purchase appear to be legitimate or fraudulent? The degree to which you can categorize a purchase accurately depends on the quality of your model. And, the quality of your model will generally depend on not only the algorithm you choose, but also the quantity and quality of data you use to "train" that model.

Implied in the above statement is that given the same input data, different algorithms can produce different results. For this reason, it's not enough to choose a machine-learning algorithm. You also must test the resulting model and compare its quality against other models as well.

So in this article, I explore the notion of testing models. I show how Python's scikit-learn package, which you can use to build and train models, also provides the ability to test them. I also describe how scikit-learn provides tools to compare model effectiveness.

Testing Models

What does it even mean to "test" a model? After all, if you have built a model based on available data, doesn't it make sense that the model will work with future data?

Perhaps, but you need to check, just to be sure. Perhaps the algorithm isn't quite appropriate for the type of data you're examining, or perhaps there wasn't enough data to train the model well. Or, perhaps the data was flawed and, thus, didn't train the model effectively.

But, one of the biggest problems with modeling is that of "overfitting". Overfitting means that the model does a great job of describing the training data, but that it is tied to the training data so closely and specifically, it cannot be generalized further.

For example, let's assume that a credit-card company wants to model fraud. You know that in a large number of cases, people use credit cards to buy expensive electronics. An overfit model wouldn't just give extra weight to someone buying expensive electronics in its determination of fraud; it might look at the exact price, location and type of electronics being bought. In other words, the model will precisely describe what has happened in the past, limiting its ability to generalize and predict the future.

Imagine if you could read letters that were only from a font you had previously learned, and you can further understand the limitations of overfitting.

Go to Full Article

Is the Moon Waxing or Waning?

Dave Taylor — Tue, 13 Jun 2017 12:53:30 +0000

by Dave Taylor

In my last article, I talked about the complications of calculating the phase of the moon and decided simply to scrape the same website that Google uses.

That site provides the current moon illumination level, which lets you break it down into the phases of new moon, crescent, quarter, gibbous and full. Amateur astronomers know that the fun part of tracking the moon's phase is to understand whether it's "waxing" (growing more illuminated) or "waning" (growing less illuminated).

Although at any given moment the moon is illuminated based on its location, and your location, relative to the sun, the full cycle of a moon phase starts and ends with a new (0% illuminated) moon, and the full moon (100% illuminated) is the mid-point of the journey.

Therefore, to ascertain waxing or waning, all you need to do is know the moon's illumination level today and either yesterday or tomorrow. Fortunately, the Moon Giant website obligingly has the ability for you to ascertain the illumination level for a specific date.

A quick visit to the site with a regular web browser reveals that it works using a date-based URL format like this: http://www.moongiant.com/phase/11/6/2016.

So, you can build the date URL for the day before today with a call to the date program. If you've got the GNU version of date, it's easy to back up a day:


$ date
Mon Nov  7 11:40:31 MST 2016
$ date -v -1d
Sun Nov  6 11:40:15 MST 2016

It turns out that you also can specify that you want to back up 24 hours, although, of course, the net result is the same:


$ date -v -24H
Sun Nov  6 11:40:24 MST 2016

More important, you can pass date a format string that you then can evaluate with the eval function, so you can set month, day and year for yesterday in one easy step:


$ eval $( date -v -1d +"mon=%m day=%d year=%Y" )
$ echo month = $mon, day = $day and year $year
month = 11, day = 06 and year 2016

It's quite a handy trick when you need to work with extracting specific elements from date and 10x that when it also involves date math.

Older Date Programs Are More Complicated

But, what if your version of date doesn't include the -v flag and doesn't have all these fancy features? Then, my friend, you are facing a definite challenge. Date math is pretty easy, except for the edge cases.

That is, it's easy to extract the current month, day and year from even the most rudimentary Linux version of date, and it's obviously easy to subtract one from the day, but what if it's the first of the month? Or the first of the year?

Go to Full Article

William Rothwell and Nick Garner's Certified Ethical Hacker Complete Video Course (Pearson IT Certification)

James Gray — Mon, 20 Mar 2017 13:49:33 +0000

by James Gray

Watch William Rothwell and Nick Garner's new Certified Ethical Hacker (CEH) Complete Video Course and learn everything you need to know to ace the CEH exam in less than 11 hours.

Divided into five modules and containing a complete overview of the topics in the EC-Council Blueprint, Rothwell and Garner's intermediate-level video-training course helps viewers master the essentials needed to pass the exam.

The course commences with a general overview of security essentials, followed by an exploration of system, network and web services security, and a dive in to wireless and internet security. To test one's chops, the course offers quizzes, exercises and two full practice exams. By providing the breadth of coverage necessary to learn the full security concepts behind the CEH exam, this video course helps prepare viewers for a career as a security professional.

The video course is published by Pearson IT Certification

Go to Full Article

Flash ROMs with a Raspberry Pi

Kyle Rankin — Mon, 06 Mar 2017 10:18:50 +0000

by Kyle Rankin

I previously wrote a series of articles about my experience flashing a ThinkPad X60 laptop with Libreboot. After that, the Libreboot project expanded its hardware support to include the ThinkPad X200 series, so I decided to upgrade. The main challenge with switching over to the X200 was that unlike the X60, you can't perform the initial Libreboot flash with software. Instead, you actually need to disassemble the laptop to expose the BIOS chip, clip a special clip called a Pomona clip to it that's wired to some device that can flash chips, cross your fingers and flash.

I'm not generally a hardware hacker, so I didn't have any of the special-purpose hardware-flashing tools that you typically would use to do this right. I did, however, have a Raspberry Pi (well, many Raspberry Pis if I'm being honest), and it turns out that both it and the Beaglebone Black are platforms that have been used with flashrom successfully. So in this article, I describe the steps I performed to turn a regular Raspberry Pi running Raspbian into a BIOS-flashing machine.

The Hardware

To hardware-flash a BIOS chip, you need two main pieces of hardware: a Raspberry Pi and the appropriate Pomona clip for your chip. The Pomona clip actually clips over the top of your chip and has little teeth that make connections with each of the chip's pins. You then can wire up the other end of the clip to your hardware-flashing device, and it allows you to reprogram the chip without having to remove it. In my case, my BIOS chip had 16 pins (although some X200s use 8-pin BIOS chips), so I ordered a 16-pin Pomona clip on-line at almost the same price as a Raspberry Pi!

There is actually a really good guide on-line for flashing a number of different ThinkPads using a Raspberry Pi and the NOOBS distribution; see Resources if you want more details. Unfortunately, that guide didn't exist when I first wanted to do this, so instead I had to piece together what to do (specifically which GPIO pins to connect to which pins on the clip) by combining a general-purpose article on using flashrom on a Raspberry Pi with an article on flashing an X200 with a Beaglebone Black. So although the guide I link to at the end of this article goes into more depth and looks correct, I can't directly vouch for it since I haven't followed its steps. The steps I list here are what worked for me.

Pomona Clip Pinouts

The guide I link to in the Resources section has a great graphic that goes into detail about the various pinouts you may need to use for various chips. Not all pins on the clip actually need to be connected for the X200. In my case, the simplified form is shown in Table 1 for my 16-pin Pomona clip.

Go to Full Article

Mars Lander, Take II: Crashing onto the Surface

Dave Taylor — Thu, 02 Mar 2017 15:04:13 +0000

by Dave Taylor

In my last article, I spent almost the entire piece exploring gravitational physics, of all unlikely topics. The focus was on writing a version of the classic arcade game Lunar Lander, but this time, it would be landing a craft on the red planet Mars rather than that pockmarked lump of rock orbiting the Earth.

Being a shell script, however, it was all about the physics, not about the UI, because vector graphics are a bit tricky to accomplish within Bourne Shell—to say the least!

To make the solution a few dozen lines instead of a few thousand, I simplify the problem to two dimensions and assume safe, flat landing spaces. Then it's a question of forward velocity, which is easy to calculate, and downward velocity, which is tricky because it has the constant pull of gravity as you fire your retro rockets to compensate and thereby avoid crashing onto the planet's surface.

If one were working with Space X or NASA, there would be lots of factors to take into account with a real Martian lander, notably the mass of the spacecraft: as it burns fuel, the mass decreases, a nuance that the gravitational calculations can't ignore.

That's beyond the scope of this project, however, so I'm going to use some highly simplified mathematics instead, starting with the one-dimensional problem of descent:


speed = speed + gravity

altitude = altitude - speed

Surprisingly, this works pretty well, particularly when there's negligible atmosphere. Landing on the Earth's surface has lots more complexity with atmospheric drag and weather effects, but looking at Mars, and not during its glory days as Barsoom, it's atmosphere-free.

In my last article, I presented figures using feet as a unit of measure, but it's time to switch to metric, so for the simulation game, I'm using Martian gravity = 3.722 meters/sec/sec. The spaceship will enter the atmosphere at an altitude of 500 meters (about 1/3 mile), and players have just more than 15 seconds to avoid crashing onto the Martian surface, with a terminal velocity of 59m/s.

Since I'm making game out of it, the calculations are performed in one-second increments, meaning that you actually can use the retro rockets at any point to compensate for the tug of gravity and hopefully land, rather than crash into Mars!

The equation changes only a tiny bit:


speed = speed + gravity + thrust

Again, there are complex astro-mechanical formulas to figure out force produced in a retro rocket burn versus fuel expended, but to simplify, I'm assuming that fuel is measured in output force: meters of counter thrust per second.

Go to Full Article

Secret Agent Man

Kyle Rankin — Tue, 28 Feb 2017 13:50:44 +0000

by Kyle Rankin

It used to be that only the paranoid among us focused on strict security practices, yet these days, it seems like people are stepping up their games with respect to encryption, password policy and how they approach their computers in general. Although I always have considered myself more inside that paranoid camp than outside of it, I even have found myself stepping up my game lately. Security is often at odds with convenience, yet whenever I need a good example of better security practices that are more convenient than the alternative, I turn to SSH keys.

With SSH keys, you generate a private and public key pair with the ssh-keygen command and distribute the public key to servers to which you want to connect. SSH keys use your private key to authenticate yourself instead of a password on the remote server, so if you are one of those people who are worried about SSH brute-forcing, if you use SSH keys, you can disable password SSH authentication altogether and not care about those SSH brute-force attempts you see in your logs. When I used to set up SSH key pairs, I wouldn't provide a passphrase to unlock the key. Without a passphrase, I could just ssh in to a machine without typing any sort of password—a case where you can increase security against brute-force SSH attacks while also increasing your convenience.

Of course, the problem with skipping the passphrase when you generate SSH keys is that all of your security relies on keeping your private key (usually found at ~/.ssh/id_rsa or ~/.ssh/id_dsa) secret. If others were able to get a copy of that file, they could log in to any machine to which you distributed the public key. Lately I decided I didn't like that kind of risk, so when I generate SSH keys, I now use a passphrase. This means if others got my private key, they couldn't immediately use it, but it also means I now have to type in a passphrase to use my SSH key. This is less convenient, but I've found that by using SSH agent, I can get back to a similar level of convenience but with a few added bonuses that I discuss in this column.

SSH Agent

On most systems that use sudo, after you type in your sudo password, it is cached for some period of time, so if you run a few sudo commands in a row, you don't have to keep typing in your password. SSH agent works in a similar way for SSH passphrases, caching your unlocked key in memory for a defined period of time. This is particularly useful if, like me, you use Git on a routine basis with SSH—it would be a pain to have to type in your passphrase every time you do a git push or git pull. So for instance, if I wanted to cache my passphrase for 15 minutes, I could type:


$ ssh-add -t 15m

Then after I provide my password a single time, it would be cached for the remainder of SSH commands I run within that 15 minutes, after which it would expire.

Go to Full Article

Natalie Rusk's Scratch Coding Cards (No Starch Press)

James Gray — Fri, 17 Feb 2017 17:02:19 +0000

by James Gray

The phrase "Learn to Program One Card at a Time" plays the role of subtitle and friendly invitation from Scratch Coding Cards, a colorful collection of activities that introduce children to creative coding.

Developed by Natalie Rusk, research scientist in the Lifelong Kindergarten Group at the MIT Media Lab, the resource consists of illustrated activity cards that provide a playful entry point into Scratch, the graphical programming language used by millions of children around the world. The cards make it easy for kids to learn how to create a variety of interactive projects, such as a racing game, an animated interactive story, a virtual pet and much more.

Each card features step-by-step instructions for beginners to start coding. The front of the card shows an activity kids can do with Scratch, such as animating a character or keeping score in a game. The back shows how to snap together blocks of code to make the projects come to life. Along the way, kids learn key coding concepts, such as sequencing, conditionals and variables. Publisher No Starch Press recommends the coding activity cards for sharing among small groups in homes, schools and after-school programs.

Go to Full Article