.. _cu_start:


Starting ConsoleUser
====================

ConsoleUser can be run in several modes, so this will cover many of
those.

----------
Unit Tests
----------

Most application specific modules, that is ones that include a
particular type (and often version) of an application and the platform
on which it runs, can themselves be run.  When this is done they will
execute the standard unit test for that type of module.

To execute in this way, you must provide the connection information for
the server to connect to.  Some configurations will also require other
information.

Here's an example of running the Chrome web browser running on Windows
10 unit test against a VNC server that uses all the default
configurations listening on IP 192.168.114.122 and port 5932.

.. code-block:: bash

    python Chrome63Win10.py -v 192.168.114.112 -p 5932 -c windowsTheme=default


The `-v` points to the [v]nc server, the `-p` is the [p]ort to use.  If
other configuration information is required you can specify key=value
pairs with `-c` like the `windowsTheme` above.  `-c` can be repeated as
often as necessary to specify many arguments.

An example with many `-c` options could be using a different VNC server
than the standard QEMU work-alike one.  Some of these do not require
holding shift down to type a capital, and store the image library in a
different path.  An analogous command to run the Firefox browser in an
XVNC environment is:

.. code-block:: bash

    python Firefox34Fluxbox.py -v 192.168.114.122 -p 5931 -c regionTarget=xvnc -c keyboardStrategy=SimpleNoShift

To see all possible configuration options see :ref:`cu_config`.

-----------
Single User
-----------

While the unit tests can be useful for either performing a short set of
tasks or proving both ConsoleUser and the required other resources are
available and working, such users don't have much personality or
variation.  For users who will emulate a real computer operator more
closely we use a script that will load a series of configuration files
(:ref:`cu_config`) and use a particular type of Brain (:ref:`cu_brain`)
to decide actions.

The `Controller.py` script will take a main configuration file to load
and will start a user based on those files.  Optionally, this script
can daemonize itself.

.. code-block:: bash

    python Controller.py -f /usr/local/tg/config/user01/user.conf -d

The `-f` flag points to the "main" user configuration file.  Other
files will be loaded from the same directory in which this file is
found.  The `-d` flag tells the script to daemonize itself.

--------------
Multiple Users
--------------

Convenience scripts are available, often in `/root` to start and stop
all of the users that should be run from this machine.  `start_all.sh`
for example will look at all the directories in `/usr/local/tg/config`
and start a `Controller.py` instance for each one, as shown above.

Similarly, `stop_all.sh` will find the port on which each user should
be listening based on the same set of config files and issue shutdown
commands.

These scripts also create and delete a flag file so if the machine is
rebooted and that file is present the users will be started again.