Bluish Coder: inferno

Bundling Inferno Applications

2016-08-12T18:00:00+12:00

Inferno can run as a standalone OS or hosted in an existing OS. In the latter case an emu executable runs and executes as a virtual operating system. An application written in Limbo runs inside this virtual OS. When distributing such an application you can install Inferno on the target machine with the application compiled code inside the filesystem of Inferno. This will include a bunch of stuff that the application may not need since it includes all the utilities for the operating system. To distribute the minimal amount of dependencies to run the Limbo application you can create a cut down Inferno distribution that only includes the application dependencies and run that. Another option is to bundle the root filesystem into the executable leaving only that executable to be distributed.

Application specific Inferno

To create an application specific Inferno install we need to find out what the dependencies are for the application. Most of the following comes from powerman's post on the topic in Russian.

When running emu it runs a program /dis/emuinit.dis to initialize the system and start the shell or other program. An application specific Inferno distribution would require:

emu
/dis/emuinit.dis
/dis/lib/emuinit.dis
Your application program files inside the Inferno directory structure somewhere.

Powerman's post goes into detail on how to do this with the following "Hello World" Limbo application:

implement HelloWorld;
include "sys.m";
include "draw.m";

HelloWorld: module
{
    init: fn(nil: ref Draw->Context, nil: list of string);
};

init(nil: ref Draw->Context, nil: list of string)
{
    sys := load Sys Sys->PATH;
    sys->print("Hello World!\n");
}

With this in a helloworld.b file, compiling it produces helloworld.dis. This contains the compiled bytecode for the Dis virtual machine. disdep will list the dependencies that it requires:

; limbo helloworld.b
; ./helloworld
Hello World!
; disdep helloworld.dis
; disdep /dis/emuinit.dis
/dis/lib/arg.dis
/dis/sh.dis
/dis/lib/bufio.dis
/dis/lib/env.dis
/dis/lib/readdir.dis
/dis/lib/filepat.dis
/dis/lib/string.dis

This shows the helloworld has no dependencies outside of what's already built into emu and emuinit.dis contains a few. Creating a directory layout with just these files and emu should be enough to run helloworld. In the following example foo is the directory containing the full Inferno distribution where helloworld.b was compiled.

$ mkdir -p hw/dis/lib
$ cd hw
$ cp ../foo/Linux/386/bin/emu .
$ cp ../foo/dis/emuinit.dis dis/
$ cp ../foo/dis/lib/arg.dis dis/lib/
$ cp ../foo/dis/lib/bufio.dis dis/lib/
$ cp ../foo/dis/lib/env.dis dis/lib/
$ cp ../foo/dis/lib/readdir.dis dis/lib/
$ cp ../foo/dis/lib/filepat.dis dis/lib/
$ cp ../foo/dis/lib/string.dis dis/lib/
$ cp ../foo/dis/sh.dis dis/
$ cp ../foo/usr/inferno/helloworld.dis .
$ ./emu -r. helloworld
Hello World!

Some of these dependencies aren't needed, for example sh.dis as we don't run the shell. See Powerman's post for a more extensive example that has dependencies.

Bundling application into emu

Instead of distributing a directory of files as in the previous example it's possible to bundle a root filesystem inside the emu program. This allows distributing just a single executable that runs the Limbo application. The steps to do this involve finding the dependencies of the program as above and creating a kernel configuration file that lists them.

The file /emu/Linux/emu is the kernel configuration file for the Linux Inferno VM. It has a root section which defines the root filesystem:

root
        /dev    /
        /fd     /
        /prog   /
        /prof   /
        /net    /
        /net.alt        /
        /chan   /
        /nvfs   /
        /env    /
#       /dis
#       /n
#       /icons
#       /osinit.dis
#       /dis/emuinit.dis
#       /dis/lib/auth.dis
#       /dis/lib/ssl.dis
#       /n/local /

The actual filesystem as located by the -r command line argument to emu is overlayed on top of this. Copying this file and adding our dependencies will bundle them into a custom build executable. This is what the root section of our helloworld looks like:

root
        /dev    /
        /fd     /
        /prog   /
        /prof   /
        /net    /
        /net.alt        /
        /chan   /
        /nvfs   /
        /env    /
        /dis
        /dis/emuinit.dis /usr/chris/helloworld.dis

Here we make helloworld.dis appear in the root filesystem as /dis/emuinit.dis, which is the first program run as the system comes up. Note that this file must use tabs, not spaces, for the entries. An executable can be compiled with this bundled root filesystem with:

$ cd emu/Linux
$ ...create helloworld configuration file...
$ mk CONF=helloworld

This produces an executable o.helloworld which when run will execute the helloworld.dis embedded inside it:

$ ./o.helloworld
Hello World!

When stripped the executable is about 1.5MB. This executable links to the X11 libraries. For a headless system you can remove the dependancy by using the emu-g kernel configuration file as a base. This removes the drivers that use X11 and prevents linking against the X11 libraries. The resulting executable when stripped is now 700K.

The executable produced by this process has some dynamic dependencies - libc, etc - that most glibc applications have. It should be possible to use musl-libc to produce a static binary and I'll cover this in another post.

Using Inferno OS on Linux

2014-12-31T15:00:00+13:00

It's the end of the year and I'm going through some of the patches I have for projects and putting them online so I have a record of them. I'm working through things I did on Inferno OS.

Source respositories

The official Inferno source is hosted in a mercurial repository on Google Code. There is also a repository containing a snapshot of this with changes to get Inferno building on Android systems on bitbucket. Finally there is a tarball containing a snapshot which includes fonts required by Inferno that are not stored in the mercurial repository.

I carry a couple of custom patches to Inferno and I also have changes to the Android port that I keep in a patch file. When working on these I find it useful to be able to diff between the current Inferno source and the Hellaphone source to see what changes were made.

I've cleaned these up and put the patches in a github repository with a conversion of the mercurial repositories to git. The Hellaphone code is a branch of the repository makeing it easy to cherry pick and diff between that and the main source. I've put this in github.com/doublec/inferno.

There are four main branches in that repository:

20100120 - Snapshot with the additional fonts
hellaphone - Hellaphone Android port
inferno - Direct import of the Inferno mercurial repository

master - Everything needed for building inferno on Linux. It is a recent working version of the inferno

branch with the additional fonts from the `20100120` branch and any additional work in progress patches
to work around existing issues.

I use master for running Inferno on desktop and hellaphone for phone development. The README on master explains how to build and the README on hellaphone has the steps to get it running on a phone.

Building on Linux

Building Inferno on Linux with the official source involves downloading an archive containing a snapshot of the source with the addition of some font files that are licensed differently. You then do a mercurial update to get the latest source code. Something like the following performs the build:

$ wget http://www.vitanuova.com/dist/4e/inferno-20100120.tgz
$ tar xvf inferno-20100120.tgz
$ cd inferno
$ hg pull -u
$ ...edit mkconfig so entries are set below...
ROOT=/path/to/inferno
SYSHOST=Linux
OBJTYPE=386
$ export PATH=$PATH:`pwd`/Linux/386/bin
$ ./makemk.sh
$ mk nuke
$ mk install

Building using my github repository requires:

$ git clone https://github.com/doublec/inferno
$ cd inferno
$ sh Mkdirs
$ .. edit `mkconfig` to so the following entries are set to these values...
ROOT=/root/of/the/inferno/git/clone
SYSHOST=Linux
OBJTYPE=386
$ export PATH=$PATH:`pwd`/Linux/386/bin
$ ./makemk.sh
$ mk nuke
$ mk install

Running Inferno

I use a shell script to run Inferno. The contents look like:

export PATH=$PATH:~/inferno/Linux/386/bin
export EMU="-r/home/$USER/inferno -c1 -g1920x1008"
exec emu $* /dis/sh.dis -a -c "wm/wm wm/logon -u $USER"

This starts Inferno using the same username as on the Linux system and with the desktop size set to 1920x1008. The JIT is enabled (the -c1 flag does this). For this to work I need to have a /usr/chris directory in the Inferno file system with some default files. This can be created by copying the existing /usr/inferno directory:

$ cd inferno
$ cp -r usr/inferno usr/chris

The patches in my master branch add a -F command line switch to the emu command to use full screen in X11. This is useful when using a window manager that doesn't allow switching to and from full screen. On Ubuntu I often run Inferno full screen in a workspace that I can switch back and forth to get between Linux and Inferno. This can be run with the above shell script (assuming it is named inferno and on the path):

$ inferno -F

Accessing the host filesystem and commands

Often I want to access the host filesystem from within Inferno. This can be done using bind with a special path syntax to represent the host system. I like to keep the path on Inferno the same as the path on Linux so when running host commands the paths in error messages match up. This makes it easier to click on error messages and load the file in Inferno text editors. I map /home as follows (';' represents an Inferno shell prompt):

; mkdir /home
; bind '#U*/home' /home

Now all the directories and files under /home in Linux are available under /home in Inferno.

The Inferno os command is used to run host programs from within Inferno. To run git for example:

; os -d /home/username/inferno git status
...output of git...

Note that I had to pass the -d switch and to give the path on the host filesystem that will be the current working directory for the command. I can even do Firefox builds from within Inferno:

; cd /home/username/firefox
; os -d /home/username/firefox ./mach build
...firefox building...

Any errors in source files that appear can be shown in the Inferno acme editor as I've mapped /home to be the same on Inferno as on the host.

VNC in Inferno

Sometimes I need to run graphical host commands from within Inferno. Mechiel Lukkien has a large number of useful Inferno programs written in Limbo. One of these is a vnc client. From a source clone of this project it can be installed in Inferno with something like:

; cd vnc
; SYSROOT=Inferno
; ROOT=
; mk install

Start a VNC server from the Linux side:

$ vncpasswd
...set password...
$ vncserver :1

Connect to it from the Inferno side:

; vncv tcp!127.0.0.1!5901

Now you can run Firefox and other useful programs from within Inferno. Inferno has its own web browser, Charon, but it's nice to be able to use a full browser, terminals, etc to do Linux things from within Inferno when needed. vncv isn't feature complete - it doesn't do modifier keys unfortunately, but is still a useful tool.

Mechiel Lukkien has many other useful libraries worth exploring. There is an ssh implementation, a mercurial client, and an interesting 'irc filesystem' which I've written about before.

Other tips

Acme is one of the editors available in Inferno. It's also available on other operating systems and Russ Cox has a Tour of Acme video which explains its features. Most of these work in the Inferno port too.

Pete Elmore has an introduction to the Inferno shell and other Inferno posts. The shell has a way of passing data from one shell command to another. For example, du can recursively list all files in the current directory and subdirectories:

; du -an

To pass this list to grep to find the text 'ASSERT' within these files:

; grep -n ASSERT `{du -an}
filename.h:100: ASSERT(1)

Limbo

Limbo is the programming language used in Inferno. It is a typed programming language with support for concurrency using channels and lightweight threads. The book Inferno Programming with Limbo is available as a PDF and also makes for a good introduction to Inferno itself. The line between Inferno as an OS and Inferno as a language runtime is a bit blurry at times.

Why Inferno?

Inferno has some interesting ideas with regards to distributing computing power and provides a way to explore some ideas that were in the Plan 9 OS but useable on multple platforms. My post on sharing computer and phone resources gives some examples of ways it could be used. Its lightweight threads and concurrency make for useful programming system for server based tasks.

Inferno is a small hackable OS for learning about operating systems. For more on this the book Principles of Operating Systems by Brian Stuart covers Inferno and Linux. One aspect I was interested in exploring was porting parts of the OS from C to the ATS programming language in a similar manner to what I describe in my preventing heartbleed bugs with safer programming languages post.

Editing remote files with Acme in Inferno OS

2013-06-11T01:00:00+12:00

Inferno OS ships with a version of the acme text editor. I've tried to use acme on and off for a bit and it never stuck. I've always been a vim and emacs user. Recently I watched a video by Russ Cox called A Tour of Acme that motivated me to try it again.

The video is short and covers a lot of what makes Acme interesting. Most of it is related to the extensibility of the editor via shell commands dealing with piped input and output alongside the power of sam editing commands.

Some useful acme papers and tutorials are:

A Tour of Acme
Acme: A User Interface for Programmers
Acme man page
A Tutorial for the Sam Command Language
The Text Editor Sam (for more on the command language)

For a recent task I had restored a backup of my Creatures Developer Resource website, recovering from a hard drive failure. I wanted to remove the Google ad code from each page of the website.

To do this from within Inferno and using Acme I first ensured I had the styx service running on the remote web server and had the host file system bound so remote users could connect to it:

; bind '#U*' /mnt/host
; svc/styx

On my client Inferno machine I mounted this remote directory and ran acme to edit the files on it.

% mount tcp!example.com!styx /n/host
% acme

The acme editor starts and from here I can edit files on the remote server by accessing /n/host/mnt/host. The first step was to load all HTML files in the webserver directory into acme. This was done by executing the following command in an acme window that had its location set to /n/host/mnt/host/var/www/example.com (using mouse button 2 to execute):

Edit B <du -an|grep 'html?$'

From the Sam Reference it can be seen that B is used to load files into the editor. In this case I load the output of the command du -an|grep 'html?$'. The command du -an provides a recursive list of all files in the current directory and subdirectories and the grep limits it to those ending in htm or html. Once executed acme has loaded all the files we're interested in from the remote server.

The Google Ad snippet to be removed looks like:

<!-- Gooogle -->
...
<!-- Gooogle -->

The following sam command will find this snippet and delete it:

,x<!-- Gooogle -->(.|\n)*<!-- Gooogle -->/ d

The , means the starting range is the entire file. The x command executes another comand for each part of the range that matches the regular expression - in this case the entire Google Ad snippet. The command to execute for each match is d which is to delete the region. To have acme run this on all open HTML files I used:

Edit X/html?$/ ,x<!-- Gooogle -->(.|\n)*<!-- Gooogle -->/ d

The X command iterates over all open windows with the name matching the regular expression and runs the following command, which I described above. This results in all the ad snippets from being removed from all the HTML files. To save them back to disk:

Edit X/html?$/ w

And to close the acme windows:

Edit X/html?$/ D

The task is done, closing acme and unmounting the remote file system:

% unmount /n/host

This task was pretty simple and could be done with a number of existing Unix tools but I wanted to give Acme a try with a real world task. It worked well editing remote files, and iterating towards the correct sam commands to use was easy by interactively testing on single files and using the p command to print ranges instead of deleting. Make sure authentication is set up before sharing remote files though!

Remote Shells with Inferno OS

2013-06-05T18:00:00+12:00

Inferno OS provides a mechanism to connect to remote computers and execute commands similar to the way SSH works on Unix systems. The command to do this is cpu. This can be used to execute commands, start a remote shell, and share GUI applications.

To use cpu you'll need to set up authentication and encryption. This provides the mechanism to authentiate to the remote machine and encrypt the session data.

The rstyx command needs to be run on the remote host to start the services that cpu uses to connect:

; ndb/cs
; ndb/dns
; svc/rstyx

The ndb commands shown there start the services to use the network and DNS. Usually this is started beforehand but I list them for completeness.

With rstyx running and authentication configured the client can connect to the remote machine using cpu:

% cpu example.com
; ...now on server...

This creates a session that is encrypted during authentication but then unencrypted. To use an encrypted session the -C flag is required:

% cpu -C rc4_256 example.com
; ls
; ...server directory listing...

cpu takes an optional argument, that defaults to the shell, to execute:

% cpu -C rc4_256 example.com ls
; ...server directory listing...
%

The namespaces available to the cpu command are mapped to the directory /n/client/ in a cpu session. This means the remote shell or command can use resources on the client. For example a phone running Inferno can cpu to a remote host and that remote host can make calls, send messages, etc using the phones resources. By controlling what namespaces exist before cpu is called the client can restrict what resources are available in the remote session.

Another example of resource sharing is to run GUI programs on the server but have the display appear on the client, similar to how X11 forwarding operates. Doing this requires having the wm window mananger on the client export its interface to a namespace (it's one of the few applications that doesn't do this by default on Inferno) and then in the cpu session bind that to a location that GUI programs can see. On the client the export would look like:

; mount {wmexport} /mnt/wm
; cpu -C rc4_256 example.com
; wmimport -w /n/client/mnt/wm acme &

This runs the editor acme on the server but the display is shown on the client. The -w flag passed to wmimport gives the path to an exported directory provided by wmexport. In this case we use the directory exported on the client which cpu has exposed under /n/client/mnt/wm.

Any graphical program can be run this way including GUI shells, games, etc. Unfortunately, like X11 forwarding, it's fairly slow over low bandwidth connections. For local connections it's quite usable however. This could be a useful way to share a phone application on a desktop or a desktop application on a phone when it's connected to the same network.

A combination of resources on the remote server and the client can be used to work around the low bandwidth issue. The acme editor exposes directories and files to control the editor. By running acme on the client, cpu-ing to the remote server so it can see these directories, the programs on the remote end can send data to the client acme window. An example follows:

; acme
; ...create a terminal in acme by 2nd-button clicking `win`...
; ...in the acme terminal window...
; cpu -C rc4_256 cd.pn

Now the remote session running inside acme will expose the needed interfaces to control the client acme program via /n/client/mnt/acme:

; echo Hello >/n/client/mnt/acme/new/body

This command, executed on the server in the remote session, creates a new window in the client acme program with the text "Hello".

Inferno OS IRC client with persistent connections

2012-12-19T20:00:00+13:00

I've written before about how Inferno makes it easy to share resources across devices and networks. In this post I show how to use IRC from within Inferno and then how to run the IRC connection handling on a server and the GUI on a client machine. The server can stay connected giving a persistent IRC connection similar to how IRC proxies and bouncers are used.

The IRC client I'm using for Inferno is written by mjl. A large number of useful Inferno and Plan 9 utilities with source is available at mjl's bitbucket repository. The one that provides IRC capability is ircfs. This is written in a manner that exposes IRC connections as a file system using the 9p2000 protocol. The GUI communicates with IRC via the file system.

Building

Building from within Inferno requires a couple of environment variables to be set. ROOT is the path to the root of the Inferno system and SYSHOST should be set to 'Inferno':

% cd ircfs
% ROOT=/
% SYSHOST=Inferno
% mk install
cd module ; mk install
mk: 'install' is up to date
cd appl ; mk install
cd cmd ; mk install
rm -f /dis/testirc.dis && cp testirc.dis /dis/testirc.dis
rm -f /dis/ircfs.dis && cp ircfs.dis /dis/ircfs.dis
cd wm ; mk install
mk: 'install' is up to date
cd lib ; mk install
mk: 'install' is up to date
cd man ; mk install
mk: 'install' is up to date

This installs ircfs into the standard Inferno application and command locations. It may not be desirable to clutter the existing system locations with additional programs like this. If you prefer you can create local directories to hold the installed programs and bind this over the system directories using a union file system. ircfs installs a useful man page which is worth reading to find out all the options.

Running ircfs

When ircfs is executed it creates a directory structure that contains the files that allow clients to send and receive data to the service. To run it we first create a directory underneath /mnt/irc for the server we want to connect to, then run ircfs passing this directory name:

% mkdir -p /mnt/irc/freenode
% mount {ircfs freenode} /mnt/irc/freenode
% ls /mnt/irc/freenode
/mnt/irc/freenode/0
/mnt/irc/freenode/ctl
/mnt/irc/freenode/event
/mnt/irc/freenode/nick
/mnt/irc/freenode/pong
/mnt/irc/freenode/raw

The example above shows the files that exist after running and mounting the ircfs service. The mount command uses the variant that runs and mounts a 9p service.

The running ircfs hasn't connected to any IRC server yet. Connections and controlling of the IRC server is managed via writing or reading from the files under /mnt/irc/freenode. The protocol is explained in the ircfs man page. For example, writing to ctl allows us to connect to a server. Reading from nick gives the current nickname used by the connected user.

Ensure that ndb/cs is running to allow network connections from Inferno before continuing.

Running the IRC GUI

The GUI for ircfs is run with the command wm/irc, optionally passing the path to the ircfs directory structure as an argument:

% wm/irc /mnt/irc/freenode

On the left of the wm/irc screen is a list of the servers and channels. Currently there is status and (freenode). The (freenode) window is for sending commands to the irc server once we're connected. To connect to irc.freenode.net enter the following in the (freenode) area:

/connect irc.freenode.net mynick

The status messages from the server should now appear. The commands that ircfs understands are documented in the /ctl section of the ircfs man page. Standard IRC client commands like /join, etc work and the channels will appear on the list in the left of the client window. The ircfs server remains running and connected if the GUI is closed. Running the GUI again with the path to the ircfs directory will display the existing channels connected and you can continue where you left off before it was closed.

GUI commands

The GUI knows some special commands that can be passed to it using /win. These are explained in the main page for wm/irc.

add can be used to add new ircfs directories to a running GUI. If you start wm/irc without passing it a directory for example you can type the following in the status window to connect to one:

/win add /mnt/irc/freenode

del removes the current ircfs directory so the GUI no longer displays informatation about it. You can use add to get the GUI to redisplay it. Note that these two commands don't affect the actual IRC connection. That remains managed by ircfs. It only affects what is displayed in the GUI:

/win del

The windows command gives a list of all the windows for the current ircfs connection and their control number. This number can be used to close and open channel windows in the GUI:

/win windows
open:
  (freenode)   (0)
  #inferno     (1)
not open:

/win close
/win windows
open:
  (freenode)   (0)
not open:
  #inferno     (1)

/win open 1
/win windows
open:
  (freenode)   (0)
  #inferno     (1)
not open:

away can be used to mark the user as away or back on all servers. exit will exit the GUI but leave ircfs connections intact.

Persistent connections

I prefer to have a persistent IRC connection on a server and connect to it from a client so I can catch up with channel logs and activity while I've been away. This allows other users to leave me messages when I'm disconnected. It also allows connecting using multiple devices and keeping my conversation active. This approach usually requires running IRSSI in a screen session on a server, or running an IRC proxy or bouncer.

A similar approach can be done using ircfs by running the ircfs server on a remote machine and on the client mounting the ircfs filesystem. The connection can be encrypted and authenticated.

The following is a simple setup. Install Inferno on the remote server and build and install ircfs as described previously. Run ircfs to run the server. In this example I also add a command line switch to log the IRC connection so I can have channel logs:

; mkdir -p /mnt/irc/freenode
; mount {ircfs -t -l /usr/myuser/irclogs freenode} /mnt/irc/freenode
; styxlisten net!*!16667 {export /mnt/irc}

On the client we mount this exported filesystem using encryption (replace example.com with the hostname of the server):

% mount -C sha1/rc4_256 net!example.com!16667 /mnt/irc
% ls /mnt/irc/freenode
/mnt/irc/freenode/0
/mnt/irc/freenode/ctl
/mnt/irc/freenode/event
/mnt/irc/freenode/nick
/mnt/irc/freenode/pong
/mnt/irc/freenode/raw

The directory and files shown are those from the remote server. Running wm/irc will now use the servers ircfs files:

% wm/irc /mnt/irc/freenode

You can now connect to the irc.freenode.net server, join channels then close the IRC window and shut down the client. Next time you restart the client, mount the remote filesystem again and continue where you left off.

Conclusion

The man pages for ircfs and wm/irc have more detail on the commands and keys that can be used. There are other things that can be done with ircfs other than GUI IRC programs. It's possible to write IRC bots and programs by utilising the control files and directories of an ircfs session.

The ircfs source is written in Limbo and is quite easy to follow. It's a good example of mapping an existing protocol onto Inferno's "everything is a file" metaphor and making use of the tools to share resources. One use of this is having Inferno on other devices, like a phone, so you can connect to IRC connections running on a local machine if you temporarily need to be mobile.

Authentication and Encryption in Inferno OS

2012-12-18T20:00:00+13:00

In my post about sharing resources in Inferno I used the -A command line switch to commands to disable authentication. This allowed anyone to make connections and the data was passed across them unencrypted. This post explains how to set up an Inferno system to use authentication and to encrypt connections.

Signing Server

For authentication to work each machine that wishes to communicate securely must have a certificate signed by a common signing authority. That signing authority should be a separate machine with the sole task of running the signing processes.

The signing server needs to have a public and private key used for signing certificates. To generate these keys run the command auth/createsignerkey from within the Inferno shell. The command takes a name argument which is the name that will appear as the signer name in the certificates generated by the server:

; auth/createsignerkey example.com

This command creates a /keydb/signerkey file containing the keys. It's important to note that if this file is regenerated then any existing certificates issued by the server will be invalidated as the private key will have been lost. Keep this file safe!

The act of authentication involves checking that the signing server and the user know a shared secret. The secrets are kept in the /keydb/keys file. The file, which starts off empty, is protected by a password. Run the svc/auth program to start the services which manage this file. You will need to provide the password, or create one if none exists:

; svc/auth
Key: ...enter password/passphrase...
Confirm key: ...confirm password/passphrase...

Each user to be authenticated must be set up on the signer by running the auth/changelogin command. This prompts for a password and an expiry date for the user. The expiry date is used as the maximum valid date for the certificates created for that user. At least one user must exist. Create a user on the signer for the current user on the signing machine (This might be inferno or your host username, depending on your setup). You need to run auth/changelogin for each remote or local user to be authenticated. That user can then run passwd command at a later time to change the password.

; auth/changelogin myuser
new account
secret: ...enter password/passphrase... 
confirm: ...confirm password/passphrase...
expires [DDMMYYYY/permanent, return = 17122013]: ...enter expiry date or confirm default...
change written

Obtaining a client certificate

A client of authenticated Inferno services needs to have a certificate obtained from the signing server. The request for this certificate is done using getauthinfo. There is a also a wm/getauthinfo variant that uses the Inferno GUI to prompt for required data. Other that that it is functionally the same as getauthinfo.

The keyname argument to getauthinfo should either be default or of the form net!example.com where 'example.com' is the hostname of the server with the resources being accessed. This must exactly match the name given to bind or mount when accessing the service. This is how those commands know to find the certificate file. The default keyname is used by file servers as the default certificate file for incoming connections.

When running getauthinfo you are prompted for the signing server to be used, the username on the signing server that you wish to get the certificate for, a password for that username (which was created with auth/changelogin previously, and whether you want to save the certificates in a file. If you answer yes to 'save in file?' then an actual physical file is created in the users /usr/username/keyring directory. If 'no' is answered then a fileserver is started on the client which serves a secure temporary file bound over the name in the given directory. This is removed when the file is unbound or Inferno is stopped.

For the following example I create a default file on a new server so it can act as a file server to remote clients. I'm using file.example.com as the hostname for this file server and example.com as the hostname for the signing server - replace this with the actual servers name. In these examples I assume that ndb/cs has been run to provide network services:

; getauthinfo default
use signer [$SIGNER]: example.com
remote user name [myuser]: ...enter username...
password: ...enter a password....
save in file [yes]: yes

On a client machine that wants to access resources on the file server run getauthinfo, but using the net!hostname form of the keyname, so bind and mount can find it.

; getauthinfo net!file.example.com
use signer [$SIGNER]: example.com
remote user name [myuser]: ...enter username...
password: ...enter password for user...
save in file [yes]: yes

The request for certificates only needs to be done once, assuming 'save in file?' was set to 'yes'. The certificate information is valid until the expiry date set for the user.

Initiating secure connections

Both server and client can now connect securely now that they have certificates provided by the common signing server. An example from my previous post on sharing resources was sharing a directory. On the file server:

; listen 'tcp!*!8000' { export '/usr/myuser' & }

This no longer has the -A switch to disable authentication. To connect from the client:

; mount 'tcp!file.example.com!8000' /mnt/remote

This command will actually fail with a message saying it couldn't find 'keyring/default' if we haven't generated a default certificate. This is because our connection string includes a port and our getauthinfo previously did not. Our getauthinfo used 'net!file.example.com' but we're connecting to 'net!file.example.com!8000'. The default for mount is to look for a file with the name exactly as specified with the host portion of the connection string and falling back to 'default'.

We can solve this by generating a default file with getauthinfo, or one for net!file.example.com!8000 which includes the port, or specifying the exact file on the mount command line by using the -k switch:

; mount -k 'net!file.example.com' 'tcp!file.example.com!8000' /mnt/remote

These mount examples will authenticate using the certificates but will not encrypt the session. To encrypt as well as authenticate use the -C switch to mount to set the hashing and encryption algorithm to use. See the ssl documentation for the supported algorithms. For example:

; mount -C sha1/rc4_256 'tcp!file.example.com!8000' /mnt/remote

All the examples in my previous post can now be done with authenticated and encrypted sessions.

Conclusion and additional notes

The examples in this post show explicitly passing the hostname of the signing server in places. The file /lib/ndb/local contains information for default servers. Changing the SIGNER key to the signing servers hostname will avoid the need of always specifying this information.

The signing server should have the sole task of running svc/auth. It shouldn't be used for other tasks. Doing so results in issues where parts of svc/auth exit when a client fails to authenticate resulting in the signing server no longer handling authentication. This is briefly warned about in svc/keyfs:

Keyfs should be started only on the machine acting as authentication server (signer), before a listener is started for signer(8). Note that signer and keyfs must share the name space. Furthermore, no other application except the console should see that name space.

This mailing list post writes more about this. This is why I use a separate file server to export the path in the listen statement in the examples here.

The following sources have additional information and examples on using authentication and encryption in Inferno. In particular the man pages for the commands have a lot of detail:

Installing the Inferno Software
Inferno Part 2: Let's Make a Cluster! by Peter Elmore.
keysrv
auth/passwd
keyfs
signer
svc/auth
auth/changelogin
getauthinfo
svc/keyfs

Sharing computer and phone resources using Inferno OS

2012-11-07T01:00:00+13:00

I posted previously about running the Inferno operating system on an Android phone. Inferno on a phone device interests me because of the approaches it takes on distributing resources across machines. By having such a system on multiple machines and devices it should be possible to use features of the phone on a desktop system (like SMS messaging, copying photos back and forth, etc) or use features of servers on the phone (cloud file storage for example).

In this post I'll go over some simple examples of how to share resources using Inferno on a desktop machine and a remote server. I'll then show how an Inferno based phone can shares its resources. I use the hosted version of Inferno for these examples where Inferno runs as a user process under an existing operating system.

Building Inferno

To build Inferno under Linux you need to obtain the inferno-20100120.tgz file from the Inferno download page. This file contains a snapshot of the mercurial based source code repository and the binary font files used by the system. Once unpacked it needs to be updated to the latest source code version using mercurial commands:

$ wget http://www.vitanuova.com/dist/4e/inferno-20100120.tgz
$ tar zxvf inferno-20100120.tgz
$ cd inferno
$ hg pull -u

Once the update is complete you will need to edit the mkconfig file so that the following settings are changed:

ROOT=/root/of/the/inferno/directory
SYSHOST=Linux
OBJTYPE=386

Ensure that ROOT matches the directory location where the Inferno source code was unpacked. To build, set your PATH to the Linux/386/bin subdirectory of the unpacked Inferno source and run the following commands:

$ export PATH=$PATH:~/src/inferno/Linux/386/bin
$ ./makemk.sh
$ mk nuke
$ mk install

The result is an emu executable living in Linux/386/bin.

Running Inferno

You can run Inferno and interact directly with a shell using emu:

$ emu
; ls
...file listing...

This is how I run Inferno on a headless server. On a machine with a display you can run a GUI:

$ emu -g1024x768
; wm/wm
...window system appears...

The -g command line option sets the size of the Inferno OS host window.

Namespaces

Inferno has a concept called a namespace which is a hierarchical collection of files or resources. Every process running in Inferno has its own local namespace. By modifying this namespace for each process you can grant or deny access to particular resources.

Some commands that manipulate the namespace are:

bind
mount
unmount
export

These commands will be used in the examples following to show how to share and access resources from local and remote machines.

Sharing directories and files

Bind attaches, moves or hides local resources. The simplest case is binding an existing directory to a new location. For example:

; mkdir /tmp/myappl
; bind /appl /tmp/myappl

This makes the directory /appl, which contains the source for some of the Inferno OS commands, to the location /tmp/myappl. the current shell and all its child processes can see the /tmp/myappl directory. Processes that aren't children of the current shell cannot.

Binding over an existing directory hides that directory until it is unbound (using unmount). It's possible to bind over an existing directory such that the source directory is overlaid with the existing directory. You can choose whether files in the source directory or the destination directory have precedence if there are duplicate names. This is known as a union filesystem.

An example of union filesystem usage is replacing the PATH environment variables in other operating systems. The /dis directory on Inferno holds the executable Inferno OS commands. Instead of maintaining PATH environment variables for users to manage order of lookup for locally built commands and global OS commands you instead manage it via union directories using bind.

If there is a directory in the user's home directory called dis, you can allow commands located there to be looked up first by doing:

; bind -b /usr/myname/dis /dis

if you want files in the global dis directory to have precedence:

; bind -a /usr/myname/dis /dis

You can stack as many directories as desired. The -a command line argument means add 'after' the union directory. the -b command line argument means add 'before' the union directory.

Binding the host filesystem

When running Inferno as a user process on an existing host operating system you can bind to directories that exist on the host. The special kernel device path, '#U', is for the host file system:

; bind '#U*' /tmp/z

Now the directory /tmp/z is mapped to the root of the host. You can map any host path, not just the root:

; bind '#U*/home' /tmp/z

This can be used to mount a users host filesystem home directory to be used as their Inferno home directory:

; bind '#U*/home' /usr

I start Inferno with the home directory shared and logged into the Inferno system as my host username using a shell script which runs the equivalent of:

$ export PATH=$PATH:/src/inferno/Linux/386/bin
$ export EMU="-r/home/$USER/src/inferno -c1 -g1920x1008"
$ exec emu $* /dis/sh.dis -a -c "bind '#U*/home' /usr; wm/wm wm/logon -u $USER"

For this to work you'll need to ensure you have the directories and files Inferno expects to find in the home directory. The files from the Inferno /usr/inferno directory can be copied for this purpose.

Accessing remote files

Note: One important point to note in the following examples is that the -A switch used in both the listen and mount commands disables authentication. All the data is being sent unencrypted and no login information was used to connect. Don't do this for real systems, I'm only doing this to show the basic commands. It's possible and recommended to set up authentication and encryption for real world usage. Once done this can replace the use of sftp on Inferno systems. Just export and bind the filesystems needed and all access is authenticated and all data encrypted.

To access a resource on another machine (or another instance of hosted Inferno OS on the same machine) you can run the listen command on the remote machine, exporting the namespace you want the client machine to be able to bind:

$ emu
; ndb/cs
; ndb/dns
; listen -A 'tcp!*!8000' { export '#U*/home/myuser' & }
;

The ndb/cs and ndb/dns commands start the network services used for DNS lookup and other features. the listen command starts a listener on port 8000 exporting the myuser home directory from the host filesystem. I picked 8000 as an arbitary port number - any one is fine. A client machine can now connect to this using:

$ emu
; ndb/cs
; ndb/dns
; mkdir /tmp/myuser
; mount -A 'tcp!remote.example.com!8000' /tmp/myuser
; cd /tmp/myuser
; ls
...remote file listing...
; unmount /tmp/myuser

Replace 'remote.example.com' with the IP address or domain name of the remote machine. The mounted directory works like a local directory from the point of view of the client. You can get directory listings, copy files, edit files, etc.

Accessing remote resources

This accessing of remote resources isn't just limited to files. You can export other kernel devices. You can remotely list and debug running processes on a remote machine by exporting and mounting /prog. On the remote machine:

; listen -A 'tcp!*!8000' { export /prog & }

On the client machine:

; mkdir /tmp/debug
; mount -A 'tcp!remote.example.com!8000' /tmp/debug
; ls /tmp/debug
...list of processes on remote machine...
; unmount /tmp/debug

Accessing remote networks

Another interesting example is mounting a remote machines /net directory over the top of the existing clients /net directory. The result of this is all network access made via the shell and its children will use the remote machine's network. This effectively creates a network tunnel that is encrypted and authenticated (if you don't use the -A switch and setup the authentication system).

To demonstrate this lets assume the client machine can't accept incoming connections due to NAT. The remote machine however is unrestricted. On the remote machine run:

; listen -A 'tcp!*!8000' { export /net & }

On the client machine we connect outwards as before - outbound connections aren't restricted:

; webgrab http://automation.whatismyip.com/n09230945.asp
; cat n09230945.asp
...public facing ip address of client machine...
; mount -A 'tcp!remote.example.com!8000' /net

This mount usage binds the remote /net onto our own /net. Any future network requests from this shell on the client machine will come from the remote:

; webgrab http://automation.whatismyip.com/n09230945.asp
; cat n09230945.asp
...ip address of remote machine...

We can even expose resources on the client machine. The following is run on the client:

; listen -A 'tcp!*!8001' { export / & }

On a third machine, that has no access to the client at all, but can access the remote machine:

; mkdir /tmp/client
; mount -A 'tcp!remote.example.com!8001' /tmp/client
; ls /tmp/client
...client file listing...

You'll note that we're connecting to port 8001 on the remote machine. This is where the listen is attached to due to us mapping the remotes /net directory on the client. But it's the client's root directory that was exported so that's what the third machine gets access to. No incoming connections are made to the client itself.

Sharing phone resources

For this example you'll need to have Inferno running on an Android phone. This can be done by installing Hellaphone or following my instructions on building and installing Inferno on a Nexus S using Mozilla's Boot to Gecko as a base.

SMS messages can be sent on the phone by writing to the '/phone/sms' file. The following would send a simple text message to number +6412345678 (an invalid New Zealand number):

; echo send 6412345678 'hello' >/phone/sms

By exporting /phone and mounting it on a desktop system we can control the sending of SMS messages from there. On the phone:

; ndb/cs
; ndb/dns
; listen -A 'tcp!*!8000' { export /phone & }

On the desktop machine:

; ndb/cs
; ndb/dns
; mkdir /tmp/phone
; mount -A 'tcp!ip.address.of.phone!8000' /tmp/phone
; echo send 6412345678 'hello' >/tmp/phone/sms

It's also possible to detect ringing, answer calls, read received SMS messages, etc.

Unfortunately things are a bit more complex in the real world. My phone carrier doesn't allow inbound connections to the phone. They also seem to prevent outbound connections on some ports. Highly annoying. To fix this I installed OpenSSH on the phone using opkg. Using OpenSSH I created a tunnel to my remote server which I could then map /net in a similar manner to what I've described previously.

On my remote server:

$ emu
; ndb/cs
; ndb/dns
; listen -A 'tcp!*!8000' { export /net & }

On the phone:

# ssh -N myuser@remote.example.com -L 8000:127.0.0.1:8000 &
# emu-g
; ndb/cs
; ndb/dns
; mount -A 'tcp!127.0.0.1!8000' /net
; listen -A 'tcp!*!8001' { export /phone & }

On my desktop:

; ndb/cs
; ndb/dns
; mount -A 'tcp!remote.example.com!8001' /tmp/phone
; echo send 6412345678 'hello' >/tmp/phone/sms

The routing through the remote server is the same as my previous example. There's probably a way of avoiding the OpenSSH tunnelling by using another port but I didn't spend time investigating exactly what the carrier was doing.

Conclusion

Inferno makes it quite easy to share resources amongst devices. The idea of having a phone which can attach to other machines to access files and export phone functionality to other machines to more conveniently write SMS messages and emails appeals to me. It'll be interesting to see how far this can be pushed and what ideas people come up with in this area. Hopefully more development will go into Inferno on the phone and some of these ideas can be explored.

Remember that the examples above that used the -A switch to mount and listen used unencrypted and unauthenticated sessions. This is useful for quick testing but for actual usage -A should be avoided. Setting up authentication is described at Pete Elmore's post on clusters. The 4th edition release notes also has information on this.

Other useful Inferno resources:

Peter Elmore's Inferno Posts
Getting Started with Inferno
Useful Limbo programs, including an IRC file system and client.
Hellaphone DEFCON 20 slides
A Tour of ACME. A screencast of using the ACME editor used in Inferno and Plan 9 (and other systems).

Building Inferno OS for Android Phones

2012-06-11T12:00:00+12:00

Updated 2014-12-29 - I've moved the patch files to github and provided updated build instructions there. Other than those build instruction updates most of this post is still valid.

Inferno is a small operating system that can be built to run on Host operating systems as a user process or natively on bare hardware. Inferno uses ideas from the Plan 9 operating system and has some interesting features. These include the Plan 9 system of representing resources as files using the 9P protocol.

Last year source and binaries were released to run the hosted version of Inferno on an Android phone. A YouTube video of it running is here. The binaries and installation are quite tightly tied to a specific android revision. It involves replacing the init.rc file on the phone to enable dual booting of Android or Inferno. Replacing this file in versions of Android different to that which the replacement was based on won't work. For example the version used is from a Gingerbread device and won't work on an Ice Cream Sandwich device. I set about building from source so I could run Inferno on my Nexus S alongside Boot To Gecko. I used B2G as the base instead of Android as B2G is easier to build and it's interesting to compare the two operating system approaches on the phone.

Warning: These steps flash data to your phone and may result in having to re-flash the original OS. Make backups first! B2G and Inferno are experimental operating systems running on the phone. They may not make for a great Phone experience at this early stage in their development.

This first step is to build the B2G system. This is pretty well covered on the Mozilla Developer Network. Basic steps to build for the Nexus S (with the phone connected to the PC):

$ git clone git://github.com/mozilla-b2g/B2G
$ cd B2G
$ ./config.sh nexus-s
$ ./build.sh
$ export B2G_ROOT=`pwd`
$ cd ..

If you want to flash B2G to your phone you can run the following command with the phone connected (this will delete everything on your phone and is not needed if you want to just try Inferno on your rooted Android phone):

$ cd B2G
$ ./flash.sh && ./flash.sh gaia
$ cd ..

We'll use the B2G tools to build Inferno and 'adb' to copy it to the device and start it.

The most recent port of Inferno that runs on Android is available in a mercurial repository hosted on bitbucket. This should be cloned and the PATH modified to use the Linux version of the Inferno build tools which we also need to build. Unfortunately the repository modifications to get Android builds working has broken Linux builds slightly so the first build attempt will fail and then we manually build the features we need. The location of the build needs to be in /data/inferno to match the directory it will be in on the device.

To build the Linux tools after cloning, edit the mkconfig file to have the following settings (change the existing ones set to Android/ARM):

SYSHOST=Linux
OBJTYPE=386

Now we build:

$ cd /data
$ hg clone https://bitbucket.org/floren/inferno
$ cd inferno
$ vim mkconfig    # Change SYSHOST and OBJTYPE as above
$ ./makemk.sh
$ export PATH=$PATH:/data/inferno/Linux/386/bin
$ mk nuke
$ mk install      # This will error out, ignore the error and continue
$ cd lib9 && mk install && cd ..
$ cd libmath && mk install && cd ..
$ cd utils/iyacc && mk install && cd ../..
$ cd limbo && mk install && cd ..

Now that the Linux tools are built we can build the Android version. This requires an ARM C compiler compatible with Android. I use the one built during the B2G build process which is accessed via a wrapper shell script called agcc. This agcc script is based on using the Android SDK. A patch to have this work with the B2G toolset is available here. This assumes B2G's gcc is in your PATH. The example below sets this and you'll need to change it to where you cloned B2G. You should also adjust the instructions to put agcc somewhere in your path. I use a bin subdirectory off my home directory.

I was unable to get the prebuilt audio binaries working that are provided with the Inferno for Android port. There were also some changes I needed to do to get it working on ICS. Patches to disable the audio, compile on ICS, and get events working are in inferno.patch which is applied in the commands below.

Edit the mkconfig file to have the following settings (change the existing ones from Linux/386 that we set earlier):

SYSHOST=Android
OBJTYPE=arm

Install agc modified to use B2G:

$ cd ~/bin
$ curl http://plausible.org/andy/agcc >agcc
$ chmod +x agcc
$ curl http://www.bluishcoder.co.nz/inferno/agcc.patch | patch -p0
$ export PATH=$PATH:$B2G_ROOT/prebuilt/linux-x86/toolchain/arm-eabi-4.2.1/bin

There is an issue with building using the B2G toolchain regarding stdlib.h. To prevent a compile error around the use of wchar_t I modified $B2G_ROOT/bionic/libc/include/stdlib.h line 167 to change #if 1 to #ifndef INFERNO to prevent the wchar_t usage of mblen and friends from being used.

Build Android Inferno:

$ cd /data/inferno
$ vim mkconfig     # Make SYSHOST/OBJTYPE changes for Android
$ curl http://www.bluishcoder.co.nz/inferno/inferno.patch | patch -p1
$ vim $B2G_ROOT/bionic/libc/include/stdlib.h   # Change to line 167 described above
$ mk nuke
$ mk install

Inferno for the device is now built. I use a B2G device to test but it will run on a rooted Android phone as well. To install run the parallel-push.sh script with the device connected. This copies everything to /data/inferno on the phone:

$ ./parallel-push.sh

Booting the phone will still boot into the main OS (B2G or Android). Inferno can be manually run using adb:

$ adb shell
# stop b2g     # 'stop zygote' on Android
# cd /data/inferno/Android/arm/bin
# ./emu-g
;; wm/wm &

From the running emu-g shell you can run any Inferno commands. The device interface to access phone functions is documented in README.android. For example, to turn the phone on and enable GSM data on New Zealand's Vodafone network:

;; echo on > /phone/ctl
;; echo net on gsm www.vodafone.net.nz '' '' > /phone/ctl

Photos of the main phone screen and tetris running on the phone are below:

To switch from Inferno back to the main OS, kill the running emu-g process and start b2g or zygote:

# kill 1234    # where 1234 = process id of emu-g
# start b2g    # 'start zygote' for Android

There are a bunch of issues with the existing port unfortunately. The 'hardware' capacitive keys don't work. I work around this by tweaking /etc/buttonserver.cfg to use the down volume key to bring up the keyboard so I can at least type. The touch screen seems to be out by a few pixels. Sound doesn't work due to disabling it in my patch applied above to get things compiling. I did test receiving and making a call though using direct device access and that worked.

Inferno is an interesting operating system and with its distributed features and Limbo programming language there might be some different approaches that could be taken to integrate phones with desktop devices to share computing resources. The existing port has some bitrot and the steps to build, as can be seen above, are quite manual but it can be streamlined. Dual booting B2G (or Android) with Inferno shouldn't be too difficult. It'd be nice to see continued work on Inferno for Android to experiment with distributed applications on mobile devices.