Command-Line Options and Configuration

The Mako Server is extremely easy to deploy (install) since only one file is required. The server does not need installation and can be run in a command window. On Windows, the server can optionally be installed as a Windows service. On all other platforms, the server can optionally be installed as a daemon (background) process.

Usage:
mako plat-specific-options -l[name]:[priority]:app -c configfile -l[name]:[priority]:app - Load one or multiple applications -c configfile - Load configuration file -? -h - print this help message

Example, load one non-deployed application as a root application:

mako -l::path/to/directory

See Loading Applications for more information.

Configuration File:
You can specify the location of an optional configuration file. The server will try to load "mako.conf"in the following locations if you do not explicitly specify where you have your configuration file: in the directory where the Mako Server is installed, in the current directory, and in the current user's home directory.

Example:
mako -c mytestdir/mako.conf

See Configuration File for more information on how to use a configuration file.

Linux and Mac Options:

-d - Run in daemon mode -u username - Username to run as

-d (Run in daemon mode) is typically used by a startup script that runs at system start and that starts the server as a background process. You do not use this mode when you develop LSP applications. See the Installing Mako Server as a Service on Linux tutorial for more information on using this option.

-u username (Username to run as) is used when starting the server as the user "root" (superuser) and then later changing the user. This command makes it possible for the server to open port 80 and 443, which can only be opened by the root user. Servers should typically not run as root, thus the -u command makes it possible to change the user ID from the superuser to a regular user after the ports are opened.

Example:
sudo mako -l::myapp.zip -u `whoami`

Note: the server will open alternate ports above 1024 if it is unable to open the default ports.

An alternative to using the above command is to add the CAP_NET_BIND_SERVICE capability, which is explicitly defined as the capacity for an executable to bind to a port less than 1024, including when run as a non root Linux user.

sudo setcap cap_net_bind_service=+ep /path/2/mako

Microsoft Windows options:

-install - Installs the service -installauto - Installs the service for autostart -remove - Removes the service -start - Starts the service -stop - Stops the service -restart - Stops and starts the service -autostart - Changes the service to automatic start -manual - Changes the service to manual start

The above commands are for installing and managing the server as a Windows service. For example, the following command installs the server as a service, enables auto start, and starts the service:

mako -l::myapp.zip -installauto

On Windows 7, administrative privileges are required in order to install a service. The Mako Server will request elevated permissions if the process or command window from where the service is installed does not run with elevated permissions.

Loading Applications

Applications are loaded by using the -l command. The server will simply return a 404 not found message if you start the server without loading any applications.

-l[name]:[priority]:path - Load one or multiple applications
  • name: The base URI to the loaded application; for example, an application with name 'myapp' will have the base URI '/myapp/'. The application's root directory is then accessed as http://server-name/myapp/. The application is installed as a root application if you do not provide a name -- i.e. the base URI will be '/' and the application's root is then accessed as http://server-name/
  • priority: The applications priority can be set if you have multiple applications with the same name or you have multiple root applications. The default priority is zero.
  • path: The application's directory or ZIP file. Non deployed applications are typically directories and deployed applications are typically loaded as ZIP files.

A traditional web server typically uses one pre-configured directory on your hard drive for your web pages. The Mako server works differently as it allows you to load multiple applications. The applications can be loaded by using the -l (load command) and/or by using the configuration file.

The following example loads three applications:

mako -lmyapp:1:path/2/myapp -lmyapp:0:myapp.zip -l::/path/2/my-root-app

The two myapp applications have the same base URI, but the non-deployed application has a higher priority than the deployed application myapp.zip. This means that resources are initially searched for in the non-deployed application and then fall back to the deployed application if not found in the non-deployed application. The last application loaded is a non deployed root application.

Configuration File

The configuration file lets you customize the server's initialization of the Barracuda Web Server and perform other initialization tasks. You can also use the configuration file for loading applications and setting your own configuration parameters.

If you do not specify a configuration file by using the "-c" option, the Mako Server looks for a configuration file by the name mako.conf in the following directories:

  1. the directory where the Mako Server executable is stored
  2. in the current directory
  3. in directories found in the following environment variables:
    1. HOME (all platforms)
    2. USERPROFILE and HOMEPATH (Windows)

The following shows the optional configuration parameters and the default values

Port and interface configuration:

port=80 --HTTP port number sslport=443 --HTTPS port number host=nil --bind HTTP port to interface e.g. host="localhost". Default binds to all interfaces. sslhost=nil --bind HTTPS port to interface e.g. host="192.168.1.100". Default binds to all interfaces.

SSL certificate and private key management (The default is to use a self signed certificate integrated into the Mako Server):

certfile=nil --Absolute path to the certificate file keyfile=nil --Absolute path to the private key file

Loading applications via the configuration file:

In addition to the -l load command, applications can be loaded by creating an array of apps to load.

apps=nil --No application loaded

The following example loads three applications, the first application is provided as a string and the other two applications are provided as a Lua table. Providing a Lua table allows for more configuration options. The last application is loaded as a root application since we set the name to an empty string. The first application's name is set to the name of the directory 'app1'.

apps={"/path/2/app1", {name="myapp",prio=1,path="/path/2/app2"}, {name="",path="/path/2/app2"}}

Each table in the 'apps' array can have the following attributes:

  • name
    The application name as explained above. The application is installed as a root application if you do not provide the name attribute or if the value string is empty.
  • priority
    The application's priority as explained above.
  • path
    The application path and name as explained above.
  • dav
    An optional WebDAV server instance can be associated with the application. This is particular useful when running the Mako Server on devices. You can mount/map the application's directory from your host operating system and directly edit files on the device. The dav attribute can be set to a boolean true or to a string. The string is set to 'fs' if you set dav=true. The string is used when constructing the DAV path. The complete path is /name/dav/. Examples: {name="myapp", dav="dav"} creates a DAV server at /myapp/dav/, {dav=true} creates a DAV server at /fs/ since this is a root application and dav is set to boolean true. You can also enable DAV for deployed applications (ZIP files), but the DAV server will be in read only mode.
  • auth
    The optional DAV server will by default not use any type of authentication. Setting the auth attribute (auth=true) enables authentication if you have also created "users".
  • conf
    The NetIo configuration can be set when the path is an URL to a Web File Server (WFS) instance installed on another Barracuda Application Server such as another Mako Server or BarracudaDrive. The "shark" attribute is automatically set for secure connections, if not provided in the conf table.

User database

You can setup a basic user database that can be used by the dav server(s). The "users" key must be set to a table with key-value pairs, where the key is the username and the value is the password in clear text.

Example:
users={root="querty",amdin="1234"}

See the Installing Mako Server as a Service on Linux tutorial for more information on using the 'dav' option and setting up a user database.

TraceLogger

Enable the TraceLogger by setting the following attribute:

tracelogger=true

When the TraceLogger is enabled, navigate to http://your-server/rtl/tracelogger/

Custom Parameters

You can set your own parameters in the configuration file and then access the configuration parameters from the loaded LSP applications. The configuration parameters are made available as a Lua module.

Example:

In the configuration file:

myparam="This is my custom parameter"

In your Lua code, load the configuration table as follows:

local conf=require"loadconf" print(conf.myparam) -- prints "This is my custom parameter"

Advanced Options

The Barracuda Application Server powering the Mako Server is designed for deep embedded systems where one may have requirements on resource allocation. The server is therefore designed such that one must pre-allocate the number of resources required. The following allows you to modify these settings. See the C reference manual for detailed information.

commandcnt=3 Number of threads and command environments sessioncnt=50 --Maximum number of sessions conncnt=50 --Maximum number of concurrent HTTP connections rspsz=8*1024 --Response buffer size reqminsz=4*1024 --Minimum HTTP request buffer size reqmaxsz=8*1024 --Maximum HTTP request buffer size