Download the linux binaries at from the downloads section. The extract the tar.gz file and run the installation script. The script will ask you what mode you are installing for. This will move the conudit binary and the configuration file to /opt/conduit. If you picked a mode other than "admin" the installation script will also install a startup script for you.
To start conduit in Linux:
To start conduit in OSX:
There is no windows installer currently. Download the binaries from the download section and extract them any place you like. If you are installing for administation you can edit the config file and your done. If you want to run the cleint or the server in Windows Conduit can operate as a windows service. To run as a windows service it uses either the command "conduit serivce" for a client service, or "conduit service server" to run it in server mode. You can install the service using the "sc" command.
Once the server is installed you can get up in running fairly quickly
An API key is needed to manage the server remotely. Once generated write it down somewhere. It will be used to configure your local client for administration.
By default the will listen on all interfaces on port 80. The default config file is installed at /opt/conduit/conduit.yaml. For basic functionality the following options must be configured.
# Host 0.0.0.0 will use all interfaces
host: 0.0.0.0:80
# Long polling will allow "push style" message delivery and reduce server load.
enable_long_polling: true
For a client to receive commands it must have a mailbox. Mailboxes have a name and an associated access key. If you have many clients it may be a good idea to use a namespacing convention for your mailbox names. This makes it easier to deploy commands to multiple types of mailboxes using pattern matching. Something like "devices.deviceType.identifier" works well. To generate a mailbox run 'conduit server register'. This command will output an access key. Keep track of this. It will need to be configured on the client.
The default configuration file is located at /opt/conduit/conduit.yaml. For basic configuration your server's address and the mailbox access key must be configured.
# Your server's address can be entered as an IP address or a hostname
host: yourserver.com:80
# The mailbox name you setup previously
mailbox: mymailbox
# The access key given to you when you setup the mailbox (not tha API key you
# generated).
access_key: xxxx-xxxxx-xxxxx-xxxxx
# Long polling will allow "push style" message delivery and reduce server load.
enable_long_polling: true
To configure the client for administrative access you will need to supply the server's address and an API access key generated from the 'conduit server access' command, which you should of done when setting up the server.
# Your server's address can be entered as an IP address or a hostname
host: yourserver.com:80
# The API access key you generated when setting up the server.
access_key: xxxx-xxxxx-xxxxx-xxxxx
You should be all setup. You can now run 'conduit stats' to see some basic statistic information. To test things out we can build a simple test script and save it as test.js.
var resp = $system.shell("du");
$(resp);
You can deliver this script by using the 'deploy' command.
You should see the output of the 'du' command giving you disk usage information from the client.
# Determens the interface and port to listen on when run in server mode.
# In client mode this is the address and port of the server.
host: conduit.somewhere.com:4112
# The mailbox this client should get messages from. This is only needed when
# running in client mode. This mailbox must be registered with the server using
# either 'conduit server register' locally, or 'conduit register' from an
# administrative client.
mailbox: lab.cluster.3
# The access key for this client. If this is a client instance using a mailbox
# the access key is generated when that mailbox was registered. If you want to
# use an administrative access key one can be generated with:
# 'conduit server access'
access_key_name: mykey
access_key: xxxx-xxxxx-xxxxxx-xxxxxx
# Adminstrative keys require an access_key_name. Client instances using a
# mailbox do not. The mailbox name is automatically used as the access key name.
access_key_name: jim
# Conduit can run in "master" mode and route "slave" instances through it. This
# uses an internal proxy server. If enabled is set to true the server will be
# run when Conduit runs in client mode with 'conduit run'.
master:
# If enabled is set to true and an address is listed the client will run a
# proxy server to route slave traffic thorugh.
enabled: true
# Address is only needed when enabled is set to true. It is the interface and port
# to listen on.
address: 10.xxx.xxx.xxx:5111
# Host is used on "slave" instances and should be the ip and port of the
host: 10.xxx.xxx.xxx:5111
# Agents are similar to slaves except that scripts can distribute functions
# directly to them within the same script. Agents do not have their own mailbox,
# unlike slaves. Scripts can simply execute arbitrary commands on machines
# running an agent.
# This is done using the $agent command, for example:
# $agent("other", function() {
# $http.upload("myLogFile.log",
# myHttpEndpoint);
# });
# The configuration is simply a map of names to addresses.
# Agent instances must have the same access_key configured as their host.
agents:
local: 127.0.0.1:5113
other: 192.168.xxx.xxx
# Agent host is used for agent instances ran with 'conduit agent'. This is the
# interface and port to listen on.
agent_host: 0.0.0.0:5114
# By default conduit uses long polling to "push" messages to the clients. If
# this is set to false clients will poll the server. This only needs to be set
# for the server instance.
enable_long_polling: true
Agent mode allows conduit running in client mode to pass commands to another instance from within a script. This serves two purposes. First it allows one client to maintain control of "slave clients". Alternatively if conduit is ran as a system service, but still needs the ability to interact with the user, this can solve that problem.
The client can be run as a service and another instance of conduit can be run in agent mode inside the user's environment. This allows the client to send commands to the agent such as starting GUI applications.
Conduit can be run in agent mode using the agent command:
The client needs to be informed that agents exist. This is done in the config file by specifying a name and host for the agent. The agent name can be any string that starts with a letter and has no spaces. It is used in scripts to identify which agent a given funciton is being passed to.
agents:
myAgentName: 192.168.1.xx
The agent itself also needs its own conduit.yaml file. Although these configurations can be placed in the same file as a client if they are running on the same machine. The only option needed is the agent_host key. It defines which interface to listen on for messsages.
agent_host: 0.0.0.0
To control an agent you use the $agent function within a script. The function takes the agent name and a function literal to execute. The script below would cause the execute command to be executed by the agent, not the client.
$agent("myAgentName", function() {
$system.execute("notepad.exe");
});
Scripts can be passed an arbitrary file that will be downloaded with, and made available to, the script. When deploying a script you can attach the asset file, which will be uploaded and stored on the server. This asset will be downloaded by each client when it downloads the script and placed in a temporary folder. The script can then access it with the '$asset.filepath' variable.
Deploying a script with an asset:
Accessing the asset in the script:
if ($asset.exists) {
var dir = $file.tempDir();
$zip.decompress($asset.filepath, dir);
$file.copy($file.join(dir, myFile.txt), "...");
}