Controlling Your Linux System with a Smartphone

 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

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

Or, you could install webmin.

White Paper
Linux Management with Red Hat Satellite: Measuring Business Impact and ROI

Linux has become a key foundation for supporting today's rapidly growing IT environments. Linux is being used to deploy business applications and databases, trading on its reputation as a low-cost operating environment. For many IT organizations, Linux is a mainstay for deploying Web servers and has evolved from handling basic file, print, and utility workloads to running mission-critical applications and databases, physically, virtually, and in the cloud. As Linux grows in importance in terms of value to the business, managing Linux environments to high standards of service quality — availability, security, and performance — becomes an essential requirement for business success.

Learn More

Sponsored by Red Hat

White Paper
Private PaaS for the Agile Enterprise

If you already use virtualized infrastructure, you are well on your way to leveraging the power of the cloud. Virtualization offers the promise of limitless resources, but how do you manage that scalability when your DevOps team doesn’t scale? In today’s hypercompetitive markets, fast results can make a difference between leading the pack vs. obsolescence. Organizations need more benefits from cloud computing than just raw resources. They need agility, flexibility, convenience, ROI, and control.

Stackato private Platform-as-a-Service technology from ActiveState extends your private cloud infrastructure by creating a private PaaS to provide on-demand availability, flexibility, control, and ultimately, faster time-to-market for your enterprise.

Learn More

Sponsored by ActiveState