Nelson Mandela passed away today. He was 95.

I am not going to pretend to know all the details about his life or the intricacies of his struggle. What I do know is that he inspired a generation around change and equality. It was not just his philosophy that inspired so many…it was his action too.

He was and will always be the purest definition of ubuntu.

06 Dec 2013 5:04am GMT

Jeremy Garcia, Stuart Langridge, and myself (Bryan Lunduke is unable to make it again, although we do of course hope that he recovers from whatever horrific disease he's contracted) bring you:

• Open Source Health: are the open source community more unhealthy than most? Perhaps the trend for health-related gadgets will save us
• Review: Stuart talks about Ender's Game, the film, the book, and the author
• Chris Anderson, CEO of 3D Robotics, ex-editor of Wired, and author, talks about his current venture, creating pilotless autonomous "drones" and what they might mean for Amazon Prime Air, agriculture, and society at large
• How do the team actually back up their stuff? Surprisingly, we all actually do (as should you), but how do we do it?
• Your feedback: video podcasting, Bitcoin, new phone OSes, and pod love

Go and listen to the show and then share your thoughts on our brand new community!

06 Dec 2013 1:44am GMT

I learned today that Nelson Mandela passed away, and this is surely a sad time for people around the globe because Mandela was a very passionate individual who had a very positive impact on so many people.

The Ubuntu Linux Project has its roots in a word he so eloquently explained in the video below and in fact Ubuntu at one point shipped with a copy of the video (Link for Planet Readers):

I think there is much for us to all learn from the life that Mandela led,and I hope this his spirit stays strong in the many people and projects he has inspired. Wouldn't it be nice if Ubuntu 14.04 LTS shipped with a copy of the original video?

06 Dec 2013 1:11am GMT

I heard this afternoon on the radio that Nelson Mandela has died. Since it was NPR (National Public Radio), I soon heard a BBC documentary on Mandela, including his teaching the interviewer about ubuntu. That bit really pained me; he's gone, and his gentle idealistic flame is no longer lighting the world.

Here him explain it on Youtube: http://www.youtube.com/watch?v=vt72ORXUlao

But we have that flame too. Ubuntu the community and Linux distribution family takes inspiration from the concept of ubuntu. To me, the world encapsulates all of what is good in the open, free, software movement, and the free culture movement too. Mandela saw himself as human, no matter how inhumanly he was treated. He knew that bitterness and hatred on his part would engender bitterness and hatred in his beloved South Africa, and he wanted instead love, understanding, forgiveness, and democracy. I hope to continue to see his ideals in the Ubuntu community, and in my Kubuntu corner in particular.

I've often thought of Mandela as the embodiment of the saying be the change you want to see. Rest in peace, Madiba.

06 Dec 2013 12:24am GMT

Packages for the release of KDE SC 4.12 Release Candidates are available for Kubuntu 12.04LTS, 13.10 and our development release. You can get them from the Kubuntu Beta PPA.

Bugs in the packaging should be reported to kubuntu-ppa on Launchpad. Bugs in the software to KDE.

05 Dec 2013 9:59pm GMT

Alan Pope, Mark Johnson, Tony Whitmore, and Laura Cowen are back in Studio A for the forty-first episode of Season Six of the Ubuntu Podcast from the UK LoCo Team!

In this week's show:-

• We also take a look at what's been happening in the news:
  • Since our announcement that Cyanogenmod was in the Google Play store, it's been removed…
  • Google offer money for personal data…
  • Windows RT (for ARM) is due to die…
  • Neither SQL nor NoSQL but a bit of both…
  • A new type of USB connector that is never the wrong way up…
  • Valve joins the Linux Foundation…
• We catch up with what's been happening in the Ubuntu community:
  • UserMetrics, a Welcome Screen widget for Ubuntu Touch…
  • Say something quotable about the community for community.ubuntu.com
  • Canonical announces affordable Asus laptops for US education…
  • Switch off the global menu for apps…
• And not in the Ubuntu community:
  • Linux Mint version 16 released…
• And we mention an event:
• • Education Freedom Day - 18th January

We'll be back next week, when we'll discuss Alan's new toy, a 3Doodler.

Please send your comments and suggestions to: podcast@ubuntu-uk.org
Join us on IRC in #ubuntu-uk-podcast on Freenode
Leave a voicemail via phone: +44 (0) 203 298 1600, sip: podcast@sip.ubuntu-uk.org and skype: ubuntuukpodcast
Follow our twitter feed http://twitter.com/uupc
Find our Facebook Fan Page
Follow us on Google Plus
Leave us some segment ideas on the Etherpad

05 Dec 2013 7:32pm GMT

Quickly Getting Started with Juju

A few weeks ago, my peers accosted me and informed me that we really need something to help with people getting started on Juju. While Juju is a really awesome, people just want to start using and playing with it. What they wanted was a Juju image that could enable someone to run Juju on their MacOS X, Windows or Ubuntu installation without much effort.

The result of that conversation is the Juju Vagrant images. The initial image is based on the Ubuntu Cloud Images. Juju is configured to use the local LXC provider and is preseeded with the latest 12.04 LTS release so deployments should be relatively fast.

The image gives you a couple of things:

1. A Vagrant development environment for developing your charms
2. the Juju GUI accessible locally through your browser
3. A functional, self-contained Juju environment

Dependencies

• sudo apt-get update
• sudo apt-get -y install virtualbox vagrant
• (optional): sudo apt-get -y install sshuttle

Ubuntu (12.04)

MacOS

• Fetch and install VirtualBox from https://www.virtualbox.org/
• Install Vagrant from http://downloads.vagrantup.com
• (optional) Install Sshuttle:
• • via homebrew: brew install sshuttle

Windows

• Fetch and install VirtualBox from https://www.virtualbox.org/
• Install Vagrant from http://downloads.vagrantup.com
• (optional) Install Sshuttle:
• • Requires nodejs is installed
  • Run: "npm install sshuttle"

Chose the box

Fire it up!

(optional) SSHuttle

If you want to use this for developing Juju Charms, you can do so with the aid of SSHuttle. SSHuttle is a slick tool for using SSH as a VPN. When used with the Juju Quickstart images, it means that you can have a completely disposable development environment, you can use your preferred editor, and access your charms locally.

The Juju Quickstart uses 10.0.3.0/24 as the LXC network. To grant local access to that group, run:

• sshuttle -e 'ssh -o UserKnownHostsFile=/dev/null vagrant@localhost:2222' 10.0.3.0/24
• Use the password of "vagrant"

BETA Warning

While these images are based on the Ubuntu Cloud Images, they should be treated as beta quality images. I suspect that after people kick the tires that feature requests will come my way. Should you encounter a problem, please pop into #juju on Freenode and ask me (utlemming) -- or the Juju community -- questions. Obviously, as this is a beta image, please be patient if the image fails to work for you. As always, feedback, comments, and heckling is appreciated.

05 Dec 2013 4:42pm GMT

We have been running the app design clinic every two weeks to answer any questions from community designers and developers on the apps they are working on!

For this session we talked about the community submitted convergence designs for file manager and clock app (thanks everyone!) as well as answering some questions from our Canonical engineers submitted apps, such as:
- If your app has two equal actions- how do you provide entry points?
- What if I want to show more content, but page stack is not appropriate?
- Where should 'About' & 'Settings' go? (Not in the tabs, please)

If you missed it, or want to watch it again, here it is:

Please send your questions and screenshots to
design@canonical.com by 1pm UTC on a Tuesdays to be included in the following Wednesday clinic.

Watch this space for our next App Design Clinic time.

05 Dec 2013 4:38pm GMT

For a long time we have been missing diagrams for KDE Frameworks, to make it easier to grasp the dependencies of the various frameworks. Since I like working with images I decided to tackle on this.

I did some research and found out CMake comes with a --graphviz option to generate .dot files, which can then be fed to the dot tool from Graphviz to generate pngs, svgs or other formats.

Armed with this, I put together two scripts :

• kf5dot-prepare runs cmake --graphviz on all frameworks, generating .dot files,

• kf5dot-generate then massage the .dot files, aggregate them and generate new .dot files which can then be piped to dot for final rendering.

My initial goal was to generate one diagram showing all the frameworks, but this is way too messy, so I ended up extending kf5dot-generate to be more versatile. Right now the output can be customized to generate a diagram of all the dependencies of one framework, to include or not Qt libraries, and to show or hide targets within frameworks.

I also used tred, another tool from Graphviz, to remove unnecessary links. For example if you have this graph definition:

digraph G {
    A -> B -> C # A depends on B, which depends on C
    A -> C # A depends on C
}

You get this output:

With tred, the link from A to C is removed, since you can already go from A to C through B:

This helps making dense diagrams more readable, but it also hides some dependencies. Depending on the reason you are looking at the diagrams, it may or may not be a problem.

Examples

Here is a selection of the generated diagrams. The "simplified" versions have been run through tred.

Some tier 1 frameworks

Mostly useful to check which Qt libraries they use:

KWindowSystem

Solid

Some tier 2 frameworks

KAuth

KCompletion

KJobWidgets

Some tier 3 frameworks

To reduce clutter I removed the Qt libraries for tier 3 frameworks.

Some of them are readable:

KDESu

KIconThemes

Others are too crowded unless they are simplified:

KIO

Simplified:

KCMUtils

Simplified:

All of KF5

The big, crowded, overall diagram (and this is the simplified version!):

Useful .dot files

I took some extra care to ensure the generated .dot files are readable enough to be useful even if the resulting diagram is not: the code is correctly indented and relations are placed close to their relevant targets. For example, here is the .dot file for all frameworks: kf5.dot.

Under the hood

The scripts currently live in a git repository: kde:scratch/gateau/kf5dot. kf5dot-prepare is a shell script. kf5dot-generate is written in Python and uses yapgvb, a Python lib to read .dot files.

What's next

In the long term I would like to include these tools in our API documentation generation procedure so that when you browse the API of a framework on api.kde.org you get a diagram of its dependencies.

05 Dec 2013 1:46pm GMT

Since I lead the Ubuntu Edge campaign, I have been trying to keep up with other crowd funding projects. I am mainly interested on technology and gadgets, and I have found it hard to navigate Kickstarter, but also to have to keep hoping between Kickstarter and Indiegogo to see what is going on. Specially since now, seems like interesting projects are evently split between them. You might share my friction on this… so I give you Techfunder:



Techfunder is an Android app that provides an easy way to browse crowd funding projects launched across the main industry websites. Techfunder gathers Technology and Design projects from Kickstarter and Indiegogo.

Using Techfunder side navigation you can easily switch between:

• Popular
• New this week
• Staff Picks
• Design - Popular

Then you can browse as many projects on a compact scrollable list. Just click on the project you are interested to expand into a full screen view.From there you can tell the world about it using the share button.

If you want to contribute or found out more about it, click on the "browse" button and Techfunder will launch the project page in your web browser. When you are finished, just press the Android back button to return to Techfunder.

I am currently planning to add a favourites/watchlist functionality and looking into a way to select additional crowd sourcing platform. I hope you enjoy it!

05 Dec 2013 12:13pm GMT

I'm please to announce the following changes have landed in the Ubuntu Packaging Guide:

• The Packaging Guide is now fully translated into French! Bravo, équipe français! Thanks a lot everyone who helped out here!
• We moved from developer.ubuntu.com/packaging to our new home http://packaging.ubuntu.com - don't despair, redirects are in place!This was done, because developer.ubuntu.com more and more moved into the direction of delivering tutorials for people who want to create content (apps, scopes, charms, etc.) on top of Ubuntu.
  This also gives us the benefit that we don't have to integrate the guide into a wordpress installation somehow, but maintain it all on our own.
  Thanks a lot Tom Haddon for helping set this up and Andrew Starr-Bochicchio for beautifying the landing page. Great work everyone!
• We are finally going to get rid of the old wiki guide. Andrew had announce the move many months ago and we should now be safe to remove the content.

Our journey is far from over. If you want to help out, please do!

• We have bugs filed against the packaging guide and need help. Some are tagged as 'bitesize' already.
• Please also help translating the guide. Many teams have already put some work into this. You can help out by either translating or reviewing translated strings.

Keep up the good work everyone. This is great!

05 Dec 2013 11:49am GMT

One thing I remember being excited about when moving from Windows to Linux was using my middle mouse button to paste. I somewhat recently got a Apple Wireless Trackpad and lost this ability as there is no middle mouse button. (As far as I knew at the time, but it looks like the upper right corner is a middle click.) I discovered that I could set a three finger tap to middle click and subsequently paste by the following:

/usr/bin/xinput set-prop "Apple Wireless Trackpad" "Synaptics Tap Action" 2 3 0 0 1 3 2


However, running that on every reboot, and battery change in the trackpad was rather annoying. With the advent of upstart user jobs (the real point of this post) I thought one would be a good way to set this functionality.

I put the following in a file named magicpad-paste.conf in my ~/.config/upstart/ directory:

description "Enable three finger middle click with an Apple Trackpad"
author "Brian Murray "

start on :sys:input-device-added NAME='"Apple Wireless Trackpad"'

script

DATE=$(date)
echo "$DATE Apple Wireless Trackpad detected"
# it seems that a sleep is needed for the device to become fully available
sleep 5
/usr/bin/xinput set-prop "Apple Wireless Trackpad" "Synaptics Tap Action" 2 3 0 0 1 3 2

end script


The hardest part was figuring out that a sleep was necessary for the device to become fully registered so that xinput would work.

05 Dec 2013 1:13am GMT

I realized that everything I do and I'm drawn towards is about creating and sharing sensual experiences -for myself and in a lot of cases other people- cooking and design being two examples.

I think I'm safe in saying that all people do things that they really enjoy doing for the sensory experience.

"Sensual" is not a Dirty Word

The entire world is sensual, we take it in through our senses. I think more sensual an experience the better the experience -the greater experiences in life being those that involve all the senses, the prime examples being: (good) food & sex (and drugs, but that's cheating).

Now who doesn't like graphs?

So if we think about the five senses -for the pedants out there, I'm aware there are more senses, but I'm sticking with the classic 5 for the sake of this post- we can oversimplify our experienes and perhaps rate each out of 10 (per sense) as a metric of how involved the experience is with that sense.

As a very highly sensual experience, perhaps few things can live up to sex.

Food

Our experiences with food (traditionally, eating it) are heavily varied, I'll admit, but we all know when we've had good food.

Good food should ultimately taste and smell fantastic, but how it looks and feels is quite important too.

I've given it a few points for sound; you may be unaware of it but the aural experience of eating is always there -crunching, slurping, crackling, etc.

Bad food, like say fast food, is not without the experience, but I would argue it's less than that of good food. Despite being awful, these bastards in the fast food industry have, in some cases, made things taste alright.

Personally, I feel that the better I become at cooking the greater ability I have to give people a better sensual experience through food and I have a responsibility to do so -or I do it easily with chocolate. ;)

Now what about things that don't involve all senses but are highly enjoyable, like music?

Music, yes, is a great experience for our sense of hearing, however, I'd wager you've had reactions to great food that you haven't had to music. ;)

Experiencing music is heavily varied, but there are generally two ways: listening or playing -there is watching a musical performance, but I'd categorize it as a combination of music and visual experiences, much like a film.

Personally, I enjoy doing both playing and listening to music, but I find playing music a richer experience as it involves more senses.

Sensual Design

I think as designers, we have a responsibility to appeal to the senses of other people. They, after all, experience what we design -hence the whole field of "user experience".

Interaction design is (simply) about designing the "interactions" people have with things.

Let me boil down the entirety of interaction design to the button for my argument -or simply, a single cause and effect entity- also it's easier to showcase on a website. ;)

Clicking a link is an interaction: you click it and you're taken to another thing or something happens -you're "linked" to another experience. So that experience of clicking can be varied as well.

So here's the classic for of a link seen throughout the web:

link

Fairly, innocuous and forgetable. (For my site I've jazzed it up slightly: link.)

But the design of a link can always be taken further and realized as a button.

Now let me plot all three in a sense-chart. For simplicity, I've redefined touch as 'something happening when you click', or the level of interaction -i.e. the greater the experience when clicking the link the higher the number.

Perhaps obviously, a button is lacking the latter senses -while some do utilize a clicky sound- but as computers can't produce smells or tastes (yet) it's a pretty low experience.

But it should be.

Designing a person's interaction with something should result in a nice experience but the design should not be overdone to the point of being memorable in any significant way (good or bad).

Either your design's user experience is poor and it leaves a bad impression with the person using it or it's done well and people remember it being a nice experience but they don't remember the nuances -the goal is to not frustrate anyone and to be "not there" and to "get out of the way" of the user's experience of the product.

In my mind, design is about playing with a persons senses by manipulating the form and function of a thing and finding a balance that elicits the right sensual experience for the context of the product and that's fun. :)

04 Dec 2013 12:00am GMT

Over the last few months we have been running the App Design Clinic and we want to thank you for all your submissions, contribution and feedback!
The Design Clinic happens every two weeks and the last one co-incided with vUDS, so we included more information on general app design as well as answering quesitons.

Here's what happened:

- A summary of topics from previous App Design Clinics
- A run-down of where to find the necessary things and resources to design an app
- And finally, how you can contribute and participate in the clinic

The next one happens tomorrow, 4th of December. Please send your questions and screenshots to
design@canonical.com by 1pm UTC on a Tuesdays to be included in the following Wednesday clinic.

03 Dec 2013 5:35pm GMT

Meeting Minutes

IRC Log of the meeting.

Meeting minutes.

Agenda

20131203 Meeting Agenda

ARM Status

nothing new to report this week

Release Metrics and Incoming Bugs

Release metrics and incoming bug data can be reviewed at the following link:

• http://people.canonical.com/~kernel/reports/kt-meeting.txt

Milestone Targeted Work Items

First, a big thank you to apw for wrestling our kernel related
blueprints and work items into place to make the above links useful
again. Our work items and owners are as follows:

Status: Trusty Development Kernel

The master branch for trusty has been rebased to the latest v3.12.2
upstream stable kernel. We also continue to track the latest v3.13
kernel on our unstable branch and most recently rebased to v3.13-rc2.
Again, we shall switch our master branch from tracking v3.12 to v3.13
once we cycle through the initial -rc's and feel it is stable enough for
wider consumtion, ie uploaded to the archive.
--
Important upcoming dates:
Thurs Dec 19 - Alpha 1 (~2 weeks away)
Thurs Jan 23 - Alpha 2 (~7 weeks away)
Thurs Dec 12 - 12.04.4 Kernel Freeze (~1 week away)
Thurs Jan 23 - 12.04.4 Final Release (~7 weeks away)

• NOTE: Even though the kernel freeze date for 12.04.4 is Dec 12,
  patches needed to have landed in the SRU cadence starting
  this week to make the 12.04.4 point release. Contact us
  *immediately* if there are patches which need to land.

  https://lists.ubuntu.com/archives/kernel-team/2013-November/034753.html

Status: CVE's

The current CVE status can be reviewed at the following link:

http://people.canonical.com/~kernel/cve/pkg/ALL-linux.html

Status: Stable, Security, and Bugfix Kernel Updates - Saucy/Raring/Quantal/Precise/Lucid

Status for the main kernels, until today (Nov. 26):

• Lucid - Prep'ing
• Precise - Prep'ing
• Quantal - Prep'ing
• Raring - Prep'ing
• Saucy - Prep'ing
  Current opened tracking bugs details:

• http://people.canonical.com/~kernel/reports/kernel-sru-workflow.html

  For SRUs, SRU report is a good source of information:

• http://people.canonical.com/~kernel/reports/sru-report.html

Open Discussion or Questions? Raise your hand to be recognized

No open discussions.

03 Dec 2013 5:13pm GMT

Upstart-socket-bridge is a lot like xinetd. They replace the need for some daemons by monitoring a port, and then launching the desired application when an inbound connection is detected. U-s-b is part of a family of Upstart services that replace many daemon monitoring and listening functions and hooks.

Unlike xinetd, services need to be customized (patched) to run with upstart-socket-bridge.

Documentation is quite sparse. Hence this blog post. That's not intended to criticize; it's really hard to write "good" documentation when you don't know the use cases or the experience level of the user. If you have experience with writing sockets in C, and understand what a file descriptor is and how to use one, then the documentation is just fine. I didn't before I began this odyssey.

How do I make it work?

Here are three simple examples of how it works.
One uses shell script.
One uses Python3.
One uses C.

Hello, World! with shell script

The script that gets triggered by the port action. The port is just a trigger, no data gets exchanged on the port.

1) Let's create a shell script called test-script. This script merely prints out the Upstart-related environment variables into a file.

#!/bin/sh
outfile=/tmp/outfile
date > $outfile            # Timestamp
printenv | grep UPSTART >> $outfile
exit 0

2) Create an Upstart .conf, let's call it /etc/init/socket-test.conf

description "upstart-socket-bridge test"
start on socket PROTO=inet PORT=34567 ADDR=127.0.0.1  # Port 34567
setuid exampleuser                                    # Run as exampleuser, not root
exec /bin/sh /tmp/test-script                         # Launch the service

3) Let's run it. Connect to the port using netcat.

$ nc localhost 34567
^C       # End the process using CTRL+C

4) Look at the result. Hey, look, it's all the environment variables we need!

$ cat /tmp/outfile

5) Clean up:

$sudo rm /etc/init/socket-test.conf           # Disconnect the launch trigger
$rm /tmp/test-script /tmp/outfile             # Delete the test service

"Hello, World" service in Python 3

(UPDATED: Thanks to Dmitrijs Ledkovs for getting this to work!)

It's a simple echo server - the Python version of the C service below. It requires two files, the application and the Upstart .conf. It demonstrates how a service reads uses the port connection for a trigger and exchanging data.


1) Let's create the Python 3 file. Let's call it test-service.py

#!/usr/bin/python3
import os, socket

# Create the socket file descriptor from the the env var
sock_fd = socket.fromfd(int(os.environ["UPSTART_FDS"]),
                        socket.AF_INET, socket.SOCK_STREAM)

# Accept the connection, create a connection file descriptor
conn, addr = sock_fd.accept()

# Read
message = conn.recv(1024).decode('UTF-8')

# Manipulate data
reply = ("I got your message: " + message)

# Write
conn.send(reply.encode('UTF-8'))

# Finish
conn.close()

2) Create an Upstart .conf, let's call it /etc/init/socket-test.conf

description "upstart-socket-bridge test"
start on socket PROTO=inet PORT=34567 ADDR=127.0.0.1  # Port 34567
setuid exampleuser                                    # Run as exampleuser, not root
exec /usr/bin/python3 /tmp/test-service.py            # Launch the service

3) Let's run it. Connect to the port using netcat, and then type in a string.

$ nc localhost 34567
Hello, World!                       # You type this in. Server read()s it.
I got your message: Hello, World!   # Server response.  Server write()s it.

4) Cleanup is simple. Simply delete the two files.

$ sudo rm /etc/init/socket-test.conf         # Disconnect the bridge
$ rm /tmp/test-service.py                    # Delete the test service

"Hello, World!" service in C

It's a simple echo server - the C version of the Python service above. It requires two files, the application and the Upstart .conf. It demonstrates how a service reads uses the port connection for a trigger and exchanging data.

1) Let's create a C file. Let's call it test-service.c

#include <stdlib.h>
#include <netinet/in.h>
#include <string.h>

int main()
{
    /* Read the UPSTART_FDS env var to get the socket fd */
    char *name = "UPSTART_FDS";
    char *env = getenv (name);       // Read the environment variable
    int sock_fd = atoi(env);         // Socket file descriptor

    /* Don't need to do any of these normal socket tasks! Hooray!
    / int port_num;           
    / int sock_fd = socket(AF_INET, SOCK_STREAM, 0);  
    / memset((char *) &serv_addr, 0, sizeof(serv_addr));
    / serv_addr.sin_family = AF_INET;
    / serv_addr.sin_addr.s_addr = INADDR_ANY;
    / serv_addr.sin_port = htons(port_num);
    / struct sockaddr_in serv_addr
    / bind(sock_fd, (struct sockaddr *) &serv_addr, sizeof(serv_addr));
    / listen(sock_fd, 5)                                                 
    */

    /* Accept() the connection. Returns the second fd: 'conn_fd' */
    struct sockaddr_in cli_addr;   // Requires netinet/in.h
    int clilen = sizeof(cli_addr);
    int conn_fd = accept(sock_fd, (struct sockaddr *) &cli_addr, &clilen);

    /* Service is active. Read-from and write-to the connection fd */
    char response[276] = "I got your message: ";
    char buffer[256];
    memset((char *) &buffer, 0, sizeof(buffer));  
    read(conn_fd, buffer, 256);                   // Read from conn_fd
    strcat(response, buffer);                     
    write(conn_fd, response, strlen(response));   // Write to conn_fd

    /* Close the connection fd. Socket fd can be reused */
    close(conn_fd);
    return 0;
}

2) Compile it using gcc, and output the compiled application as an executable called test-service. I put mine in /tmp to make cleanup easier. If you're familiar with gcc, the important element is that there are no flags and no libraries:

gcc -o test-service test-service.c

3) Create an Upstart .conf, let's call it /etc/init/socket-test.conf

description "upstart-socket-bridge test"
start on socket PROTO=inet PORT=34567 ADDR=127.0.0.1  # Port 34567
setuid exampleuser                                    # Run as exampleuser, not root
exec /tmp/test-service                                # Launch the service

4) Let's run it. Connect to the port using netcat, and then type in a string.

$ nc localhost 34567
Hello, World!                       # You type this in. Server read()s it.
I got your message: Hello, World!   # Server response.  Server write()s it.

5) Cleanup is simple. Simply delete the three files.

$ sudo rm /etc/init/socket-test.conf         # Disconnect the bridge
$ rm /tmp/test-service.c /tmp/test/service   # Delete the test service

How does it work?

Here is the oversimplified explanation. Each stream of data whizzing round inside your system is tracked by the kernel. That tracking, sort of like an index or a pointer, is called a file descriptor (fd). A few fds are reserved (0=stdin, 1=stdout, 2=stderr) and you run into these in shell scripting or cron jobs.

A pipe or port or socket is just a way to tell the kernel that a stream of data output from Application A should be input to Application B. Let's look at it another way, and add that fd definition: An fd identifies a data stream output from A and input to B. The pipe/socket/port is a way to express how you want the fd set up.

Now the gritty stuff: A socket/port can have a single server and multiple clients attached. The server bind()s the port, and listen()s on the port for connections, and accept()s each connection from a client. Each connection to a client gets issues another file descriptor.

That's two file descriptors: The first defines the port/socket in general, and the second defines the specific connection between one client and the server.

Upstart tells your server application (since it's not actually serving, let's just call it the "service") the first file descriptor.

• Your service doesn't start a daemon at boot.
• Your service doesn't bind() to the socket/port. Upstart does that.
• Your service doesn't listen() on the socket/port. Upstart does that.
• Your service doesn't fork() for each connection. Upstart launches an instance of your service for each connection. Your service can terminate when the connection ends...if you want it to.
• Your service does accept() the connection from a client, communicate using the resulting file descriptor, and end when the connection close()s.

Let's try it with the example above:

1. Upstart and Service are running on Server. Client is running somewhere else - maybe it's also running on Server, maybe it's out on the network somewhere.
2. The file /etc/init/socket-test.conf tells Upstart to monitor port #34567 on behalf of test-service application. As currently written, it will begin monitoring at boot and stop monitoring at shutdown.
3. When Client --like netcat-- connect()s to port #34567, Upstart launches test-service application with a couple extra environment variables.
4. test-service reads the environment variables, including the file descriptor (fd).
5. test-service accept()s the connection on the file descriptor. This creates a second fd that Service can use to communicate.
6. When Client and test-service are done communicating, they close() the connection fd.
7. test-service can end. Upstart will restart it next time an inbound connection is received.

How do I make it work with a service I didn't write? (like my favorite Game Server or Media Server or Backup Server)

Maybe it will work, maybe it won't. There are a couple issues to consider. I don't see an easy, non-coding solution because we're talking about changing the nature of these services.

• Change from always-on to sometimes-on.
• Change to (save and) quit when the connection is done instead of listen()ing for another connection. I don't see any upstart trigger for a socket connection ending.
• Might make some service code simpler. No longer need to fork() or bind().
• Not portable to non-Upstart systems, so the daemon code remains. Adds a bit to code complexity and a new testing case.
• A different trigger (hardware, file change, etc) might be a better trigger than a connection to a socket. Upstart has bridges for those, too.

03 Dec 2013 3:39pm GMT