Skip to end of metadata
Go to start of metadata

mOS - mOSAIC Operating System

mOS is an operating system developed in the frame of mOSAIC Project. mOS is based on Slitaz Linux distribution.

Operating system

mOS is a 32-bit Linux operating system. 64-bit version is not yet supported.

It is an on-boot deployable operating system. On boot the content of the ramdisk is transferred on the local harddrive from which it can boot further.


mOS uses a 2.6.37 kernel. It is custom compiled to support:

  • btrfs file system;
  • LXC containters (kernel security groups);
  • XEN virtualization (also HVM);
  • KVM virtualization;
  • Amazon EC2 pv-grub support (special patches are applied to be compliant);
  • Flexiant XEN HVM customizations;


mOS is a light operating system. It uses busybox as an userspace tools. It has it's own tools for package management and boot services.

The latest version of the ramdisk can be found at: . Latest official version is 0.8

Boot services

mOS comes with some important boot services special designed for cloud environments.

Network configuration

Network configuration is done using DHCP protocol. Moreover udhcpd implementation is used. The default behavior can be controller using /etc/network.conf file.


network.conf file is very simple. You can define as many interfaces as we need to support by using the following structure:

CONFIG[0]=" netmask broadcast"
ROUTES[0]="default gw"

The syntax for CONFIG and ROUTES is similar with the one used for ifconfig and route tools.

If CONFIG[id] value is dhcp then INTERFACE[id] will be configured using DHCP protocol (ROUTES[id] field will be ignored).

Cloud zeroconf services

This service is a connector with cloud providers zeroconf services. This service has support for the following cloud providers zeroconf services:

  • Amazon EC2;
  • Eucalyptus 2.x;
  • Flexiant;

The following information is retrieved from the cloud providers' zeroconf service:

  • user-data: a text string/file defined by the user when starting the virtual machine;
  • ssh public key: a text string representing the ssh public key used for user root ssh passwordless authentication;
  • administrative username/password pair: if no public key is support then username/password pair must be setup (it depends on the cloud provider);

user-data execution

User-data string that is supposed to be read from the zeroconf service must have the following structure:

multiple lines script/program:
  • the first line must start with: #!ash #!bash #!python 
  • the following lines are the script/program source code lines;
The script/program is save and executed using the specified interpreter on the first line.
single line descriptor:
  • the line must contain:
    • #!pkg:source:package_name[=package_version][:command:path]

      • sourcethe source where to get mOS package from:
        • supported sources:
          • tazpkg: local package manage;
      • package_name: the name of the package you want to install;
      • package_version: optional, you can specify the version of the package to be installed;
      • command: optional, a command to be executed after package installation; if no command  is specified the package will be only installed;
        • supported commands: 
          • runexecute a script defined in path;
        • path: a path to a script to be executed relative to the package directory;
    • #!app:application_id:package_name[=package_version]
      • application_id: the name of the application;
        • value: random, user choice (preferable each simulation to have a different one);
        • usage: register the application into the DNS; all the nodes within the same application_idwill be registered under:
          • - with public ip address;
          • - with private ip address;
          • - PTC case: with private ip address;
          • - PTC case: with private ip address;
        • required: it is required on cloud providers where broadcast/multicast packets are filtered;
      • package_name: the name of the package you want to install;
      • package_version: optional, you can specify the version of the package to be installed;

Single line descriptor is applicable to custom created mOS packages (see mOS Package Shell). These packages are installed under /opt/package_name/.

Package daemon

Package daemon is a local daemon that starts automatically and listens to port 19999. It accepts the same type of strings as in the case of single line descriptor for user-data exection (described above).

echo "#!pkg:tazpkg:mosaic-node-boot=0.2.0:run:bin/run" | nc VM_IP 19999

CAUTION: you must wait until the daemon responds back to you when it finished the installation with the following message syntax:

  • ok:message 
    • package was installed and package starter was executed;
  • error:message
    • an error ocurred and `message` will contain and explanation (error installing, calling package starter, missing paths etc.)
  • busy:message
    • an instance of the package daemon already running or userdata service is running; in this case you must retry after a while;

Naming service

Each mOS instance has its own name, randomly generated. This name is registered into the DNS using the following subdomains:

  • : address corresponding to the public IP address;
  • address corresponding to the private IP address;

Each application id has its own entry in the DNS like (if #!app userdata descriptor is used):

  • : address corresponding to all the public IPs of the nodes withing this application id;
  • : address corresponding to all the private IPs of the nodes withing this application id;

(if the cloud environment doesn't support private IP then the public one will be used in both cases)

Autostart services

Services init scripts are located in /etc/init.d/ . Each script must be executable (we recommend 755 mode). To make a service to autostart at boot time you must add the init script name into /etc/rcS.conf as part of the RUN_DAEMONS list (space separated).

Available tools


upload.cgi is a tool integrated into mOS and available through mOS HTTP interface: http://SERVER_IP:81/cgi/upload.cgi


upload.cgi accepts POST calls for binary uploads. It takes the binary attachment (regardless the content) and it saves it into a local directory exposed via the HTTP interface at: http://MOS_IP:81/store/

HTTP call example
HTTP response 
  • HTTP code 200;
  • HTTP content-type/json:
    • code: 0 - action was successfull; 1 - action failed;
    • message: explanation message;
    • payload: in case of code 0 il will contain the name of the save file available through http://MOS_IP:81/store/filename