Home ›

Controlling Your Linux System with a Smartphone

Issue 199

From Issue #199
November 2010

Jan 01, 2011  By Jamie Popkin
 in
Using simple Web technologies, you can turn your smartphone into a multipurpose device to control your computers.

Phone technology has come a long way recently. The gap between personal computers and handheld devices is becoming smaller. I keep hearing the phrase “death of the PC”, and there may be some truth to this statement. However, I believe many of us will continue to need access to larger and more powerful computers that are too big to fit in our pockets. To me, the best of both worlds is to have full control over a larger computer from my phone.

Many new smartphones have advanced Web browsers built in. With this technology, you can access an interface configured to run any command on almost any computer. It is fairly trivial to run a Web server on a Linux box. If you take the appropriate security measures, you quickly can build a Web interface designed specifically for handheld devices.

Security

The approach shown in this article is to use a user account to run commands on the system. Of course, there are security concerns in doing this, but with the appropriate precautions, it can be made reasonably secure.

The system will rely on Wi-Fi. This makes sense when dealing with handheld devices, so configure your Wi-Fi router with a password. Users that want to connect to the local intranet will have to enter a password into their device before seeing anything. Most devices will remember the credentials and connect automatically once in range.

To minimize the risks in the event of a security breach, let's also create the user account with minimal permissions. This is a good safety measure, even though the interfaces will expose only “safe” commands.

Setup

Install the following from your distribution's repository if not already installed: Apache2, apache2-suexec and libapache2-mod-perl2.

The first package is the Web server. If it doesn't start automatically after the install, run the command: 

/etc/init.d/apache2 start

The second package allows you to run the Web server with the credentials of a particular system user. When it is installed, you need to issue the following command as root to enable the apache module: 

a2enmod suexec

Some of the examples presented here require Perl CGI interoperability. The last package is needed for that.

Now, you need to configure Apache to run as your little-trusted user. On our family Linux box, I created an account for all the kids. The user name is “saturn”. This account can do things like play music and watch videos. However, it doesn't belong to any groups that can delete or change things of importance. So let's use this account as an example.

Edit your apache config, and add the following line to the default VirtualHost (*:80) or to the VirtualHost you want to use: 

SuexecUserGroup saturn saturn

Apache runs as root, so it has the ability to run scripts as any user. The line above tells Apache to run as the user saturn and group saturn.

Now, restart Apache, also as root, with this command: 

/etc/init.d/apache2 restart

The Web service now is running as the user saturn.

The Simplest Example

Playing a sound file from the command line is fairly trivial, and it's a good way to exhibit the simplicity of this setup—one button for one action.

I'm using a traditional Web stack: HTML, CSS, JavaScript and CGI. The CGI part can be accomplished with a number of different languages. This first example uses a shell script, for the sake of simplicity.

Create an index.html file in the root Web directory. For many systems, this is located in /var/www/. Some systems use /var/www/html/. In this file, add a button that calls a JavaScript function called playQuack(): 


<button id="quack-button" onclick="playQuack()">Quack</button>

The JavaScript for the playQuack() function is in bonkers.js. The entire index.html file looks like this: 


<html>
  <head>
    <title>Bonkers</title>
    <meta name="viewport"
          content="initial-scale=1.0; user-scalable=no"/>
    <link rel="stylesheet" type="text/css" href="default.css" />
    <script type="text/javascript" src="bonkers.js"></script>
  </head>

  <body>
    <button id="quack-button" onclick="playQuack()">Quack</button>
  </body>
</html>

Some additional content worth mentioning is in the metatag. This tells smartphones not to scale the content of the page. Without this, the button would be very tiny on the screen.

Here is my default.css file. It defines a background color and specifies how the button will look: 

html, body {
  background-color: #1E1E26;
}

button#quack-button {
  position: absolute;
  top: 20%;
  width: 70%;
  left: 15%;
  padding: 5px;
  border-width: 3px;
  color: #BFBFBF;
  font-size: 34px;
  font-weight: 800;
  border-color: #9C9C9C;
  background-image: -webkit-gradient(linear, left top
      left bottom, from(#BF5A34), to(#463630));
      -webkit-border-radius: 10px;
}

Many mobile browsers are starting to support WebKit CSS. This is exciting, because a couple lines of WebKit code can do some really fancy things. The last two lines before the last curly bracket tell the button to have rounded corners and a color gradient background.

Now you have a nice-looking button. Point the browser on your phone to the IP address of the Linux computer. You should see something similar to Figure 1.

Figure 1. A Simple Button Displayed on an iPhone

Next, let's make the button actually do something. Create the bonkers.js file in the root Web directory, and enter the following: 

var myDomain = document.domain;
var cgiURL   = "http://" + myDomain + "/cgi-bin/bonkers.cgi";
var xmlRequest;

function playQuack() {
  xmlRequest = new XMLHttpRequest();
  xmlRequest.open("GET", cgiURL, true);
  xmlRequest.send(null);
}

This is the JavaScript that forms the client-side process. It creates a URL that essentially runs the CGI script on your Linux box. In this example, you really don't care about the return value from the CGI script.

Believe it or not, the hard part is all done. CGI scripts are extremely simple and easy to understand—especially for someone who is used to the command line.

All CGI scripts must be located in the cgi-bin directory. This commonly is located in /var/www/cgi-bin or /usr/lib/cgi-bin and is also configurable within Apache.

Here is the CGI script, bonkers.cgi: 


#!/bin/bash

mplayer ~/quack.wav &

That's all. This is a Bash shell script. A reference to the shell path is at the top. Below that is a command to run MPlayer, which plays an annoying quack sound. You essentially can place any shell command here.

There you have it. Anybody with a smartphone and the Wi-Fi password can make quack sounds come out of the computer. Now it's time to do something a little more useful.

______________________

Comments

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Create .Xauthority file

Parimal Naigaonkar's picture
Submitted by Parimal Naigaonkar (not verified) on Mon, 01/17/2011 - 00:31.

Hi,
I really liked your article, I was trying it but there is no .Xauthority file in my home folder.
Can you guide me how to create it under ubuntu 10.10.
Thank You

Or, you could install webmin.

Anonymous's picture
Submitted by Anonymous (not verified) on Sun, 01/16/2011 - 13:07.

Or, you could install webmin.

Webcast
More Resources
How to Build an Optimal Hadoop Cluster to Store and Maintain Unlimited Amounts of Data Using Microservers

Realizing the promise of Apache® Hadoop® requires the effective deployment of compute, memory, storage and networking to achieve optimal results. With its flexibility and multitude of options, it is easy to over or under provision the server infrastructure, resulting in poor performance and high TCO. Join us for an in depth, technical discussion with industry experts from leading Hadoop and server companies who will provide insights into the key considerations for designing and deploying an optimal Hadoop cluster.

Learn More

Sponsored by AMD

White Paper
More Resources
Red Hat White Paper: Using an Open Source Framework to Catch the Bad Guy

Built-in forensics, incident response, and security with Red Hat Enterprise Linux 6

Every security policy provides guidance and requirements for ensuring adequate protection of information and data, as well as high-level technical and administrative security requirements for a system in a given environment. Traditionally, providing security for a system focuses on the confidentiality of the information on it. However, protecting the data integrity and system and data availability is just as important. For example, when processing United States intelligence information, there are three attributes that require protection: confidentiality, integrity, and availability.

Learn more about catching the bad guy in this free white paper.

Learn More

Sponsored by DLT Solutions