Skip to content

m1 client

The m1 client is the command line interface to minusonedb. In addition to allowing you to execute all of the endpoints available in ops or one of your environments, the m1 client simplifies authentication and operations that require coordination between https://ops.minusonedb.com and your environments. For brevity's sake only m1 authentication and orchestration operations are described below; see the service api references for additional m1 sample usages.

Getting Started

Step 1: Download the latest m1 client zip file.

Step 2: Unzip the m1.zip file to a location on your computer.

Step 3: Add the unzipped m1 directory to your path based on your operating system's instructions.

Step 4: The m1 client requires java. Install java if it is not already present on your computer.

Step 5: Try running m1 in a terminal. You should see something like:

Usage: m1 <cmd> <args...>

If the m1 command is not found, make sure the m1 directory containing the m1.jar zip was successfully added to your path. If java is not found, doublecheck your java installation steps.

Signing Up

Only an email address is required to obtain a MinusOneDB ops login. Your ops login will let you create a free trial or manage any accounts and environments that other MinusOneDB users have shared with you. We will not send outbound marketing emails to you; if you receive an email from us it is only in support of the service we provide; our terms of use define how we want to do business with you.

To sign up, run:

m1 signup

You will be prompted for a username (which must be a valid email address) and a password. If successful, those credentials will be saved to a local directory and used subsequently to get tokens to access ops services.

From here you can keep on reading about how to use the m1 client or go start your free trial.

Authenticating

Connect to https://ops.minusonedb.com

m1 auth

Connect to your environment at https://envName-accountName.minusonedb.com

m1 auth envName-accountName

Connect to https://ops.minusonedb.com by running the following:

m1 auth

You will be prompted for your MinusOneDB username (email) and password; these credentials will be saved to a local directory and used subsequently to get tokens to access ops services.

Note: Do not use m1 auth to cache credentials on a shared computer; others may be able to access your MinusOneDB resources.

Connect to one of your environments by running the following command, replacing envName and accountName appropriately:

m1 auth envName-accountName

As with ops, you will be prompted for your credentials to access your environment.

You will not need to rerun m1 auth unless your credentials change.

Creating an Environment

A sample m1 environment configuration file

{
    "environment": {
        "create" : {
            "servers": 1
        },
        "init": {
            "username": "admin",
            "password": "change this password"
        },
        "stores": [{\
            "store": "index",\
            "type": "standard",\
            "shards": 1,\
            "replicas": 1\
        }],
        "sessionStores": [{\
            "store": "stash",\
            "shards": 1,\
            "replicas": 1\
        }],
        "configure": [{\
            "system": {\
                "geo": "true",\
                "publish-permissive": "true"\
            }\
        },{\
            "user/update": {\
                "username": "admin",\
                "rights": ["admin","get","publish","schema","sessionUpdate","sessionQuery"]\
            }\
        },{\
            "user/add": {\
                "username": "flush",\
                "password": "change this password",\
                "rights": ["publish","sessionUpdate","sessionQuery"]\
            },\
            "user/add": {\
                "username": "instrument",\
                "password": "this password does not matter",\
                "rights": ["publish", "sessionUpdate"]\
            }\
        },{\
            "store/autocommit": {\
                "store": "index",\
                "seconds": 2\
            }\
        },{\
            "schema/add": {\
                "properties": "@../schema/instrument.json"\
            }\
        },{\
            "schema/add": {\
                "properties": "@../schema/geo.json"\
            }\
        },{\
            "schema/add": {\
                "properties": "@../schema/sample.json"\
            }\
        }]
    }
}

Create a new environment by running the following:

m1 orchestrate deploy envName environment-configuration.json

envName is the name of the new environment to create. The configuration file specifies desired environment parameters -- the number of data processing servers, data store and session store topology, users and rights, as well system property configuration.

Sample environment template files are available with our downloadable samples. To use an environment template file:

Step 1: Make a copy of the environment template file.

Step 2: Set your admin username and password in the init block.

Step 3: Create any additional users who should have access this environment. The example configuration below creates users flush and instrument.

Step 4: You can make any other desired edits to the template file here.

Step 5: Run m1 orchestrate deploy envName your-copied-config-from-step-1.json.

Note: Deploying a new environment will typically take 5-10 minutes.

Adding Stores

Add a data store named index and a session store named stash

m1 orchestrate addStores test-m1 addStores.json

An example addStores.json that adds a store and a session store:

{
    "environment": {
        "stores": [{\
            "store": "index",\
            "type": "standard"\
        }],
        "sessionStores": [{\
            "store": "stash"\
        }]
    }
}

Create and add any number of data stores or session stores to an existing environment by running the following:

m1 orchestrate addStores envName-accountName addStores.json

As a convenience, you can use an environment config file as an argument to m1 orchestrate addStores; elements other than the stores and sessionStores entries will be ignored.

orchestrate addStores adds data store and session store configurations to an environment and then provisions corresponding data store and session store server resources via https://ops.minusonedb.com.

Dropping a Store

Drop a store named index

m1 orchestrate dropStore store test-m1 index

Drop a session store named stash

m1 orchestrate dropStore session test-m1 stash

Drop and destroy a data store by running the following:

m1 orchestrate dropStore store envName-accountName dataStoreToDrop

This operation drops the data store configuration in the environment and then destroys the data store server resources via https://ops.minusonedb.com.

Drop and destroy a session store by running the following.

m1 orchestrate dropStore session envName-accountName sessionStoreToDrop

This operation drops the session store configuration in the environment and then destroys the session store server resources via https://ops.minusonedb.com.

Renaming a Store

Rename a store named index to index2

m1 orchestrate renameStore store test-m1 index index2

Rename a session store named stash to stash2

m1 orchestrate renameStore session test-m1 stash stash2

Rename a data store by running the following:

m1 orchestrate renameStore store envName-accountName dataStoreToRename

This operation renames the data store configuration in the environment and then renames the data store server resources via https://ops.minusonedb.com.

Rename a session store by running the following.

m1 orchestrate renameStore session envName-accountName sessionStoreToRename

This operation renames the session store configuration in the environment and then renames the session store server resources via https://ops.minusonedb.com.

Configuration File Format

eventsSessionStore.json template

{
    "environment": {
        "create" : {
            "servers": 1
        },
        "init": {
            "username": "admin",
            "password": "change this password"
        },
        "stores": [{\
            "store": "index",\
            "type": "standard",\
            "shards": 1,\
            "replicas": 1\
        }],
        "sessionStores": [{\
            "store": "stash",\
            "shards": 1,\
            "replicas": 1\
        }],
        "configure": [{\
            "system": {\
                "geo": "true",\
                "publish-permissive": "true"\
            }\
        },{\
            "user/update": {\
                "username": "admin",\
                "rights": ["admin","get","publish","schema","sessionUpdate","sessionQuery"]\
            }\
        },{\
            "user/add": {\
                "username": "flush",\
                "password": "change this password",\
                "rights": ["publish","sessionUpdate","sessionQuery"]\
            },\
            "user/add": {\
                "username": "instrument",\
                "password": "this password does not matter",\
                "rights": ["publish", "sessionUpdate"]\
            }\
        },{\
            "store/autocommit": {\
                "store": "index",\
                "seconds": 2\
            }\
        },{\
            "schema/add": {\
                "properties": "@../schema/instrument.json"\
            }\
        },{\
            "schema/add": {\
                "properties": "@../schema/geo.json"\
            }\
        },{\
            "schema/add": {\
                "properties": "@../schema/sample.json"\
            }\
        }]
    }
}

The environment configuration file is a json map describing an environment. A fairly complete example configuration is shown above; a description of each key element of the configuration file is described below: - environment - create: Parameters for env/create (like the number of data processing servers). - init: Your initial admin user/password. Note how this element corresponds to init. - stores: A list of data stores to add. - sessionStores: a list of session stores to add. - configure: a list of maps representing environment service operations to configure a store. Note how a user/update, /system, or schema/add elements in the example configuration relate to the corresponding api method. This pattern can be extended to other environment service endpoints.

Was this page helpful?
Suggest an edit

© 2021-2026 MinusOne, Inc.