594e1d9812
Fixed a bug that caused the host to not respond to any commands when a module is present. CmdExecutor::loadMods() had a malformed 'for' loop that caused the command executor to infinite loop. Also re-formed the way the external command loaders (modules) are constructed. Instead, the modules are also intialized at the same time as the internal command loader. The CmdExecutor::loadModFile() and CmdExecutor::unloadModFile() functions now load and unload modules via the module name instead of the path to the module main file. The documentation for ASYNC_ENABLE_MOD and ASYNC_DISABLE_MOD updated to reflect this change. Also part of the module contruction re-form, it fixed a bug that caused the command loaders to operate in a thread different from the command executor. CmdExecutor::loadMods() was refactored into cmdExecutor::buildCmdLoaders(), added the internal command loader to it and have it so this function gets called only when the command executor successfully moves to it's own thread. Fixed a bug that caused the session to crash only when a module is present. It turns out the qobject_cast() function used in CmdExecutor::loadModFile() only pulled the surface class ModCommandLoader so any attempt to access the base class functions from CommandLoader caused the session to crash so to fix this, ModCommandLoader was merged into CommandLoader. The Command loader documentation and test module were updated to reflect this change. Fixed a bug that auto removed any modules that were installed when the host is restarted. The issue was in TCPServer::syncModPath() that used the modules's main file without a suffix when the file did indeed have a suffix, causing the function to think the module no longer exists and remove all of it's files from the host file system. The original intent for this function was to keep the module database table in sync with what was actually in the host file system. It was decided that this is not necessary so the function was removed altogether. Also changed up the way the module files are deleted. The TCPSever class will now use the module name instead of the path to the module's main library file and will use a single use ModDeleteTimer for each module that was requested to be deleted instead of a single continuous timer constantly checking for modules to delete. The ls_cmds command will now list the commands in alphabetical order of the command names and fixed a bug with the -find option that would display nothing if an exact match to any text in the table could not be found. Fixed a bug found in the deployed application that would segmentation fault on startup due to certain library files being included in the deployed installation directory. Updated the linux_build.sh script to include only libsqlite, libQT5, libssl and libicu files. It will no longer blindly copy all library files from the dev machine and then remove files the setup script thinks the application might or might not need. Any module built on import rev1 will simply not work and no attempt will be made to make it work so the host new minimum import rev is now rev2. this update is mustly just bug fixes; nothing that would require any client behaviour changes so just the host patch is bumped. 1.0.0 --> 1.0.1 |
||
|---|---|---|
| .. | ||
| intern_commands | ||
| Async.md | ||
| Command_Loaders.md | ||
| Command_Objects.md | ||
| Host_Features.md | ||
| Internal_Commands.md | ||
| LICENSE.md | ||
| Protocol.md | ||
| README.md | ||
| Type_IDs.md | ||
MRCI
(Modular Remote Command Interpreter) is a command interpreter primarily designed to provide remote service to connected clients, whether text based or any kind of data. As the name implies, it is expandable via 3rd party modules by adding addtional commands that remote clients can run on the host. It has a fully feasured user account management system with access control to certain commands for certain user groups. All persistent data is handled by a SQLite database and all remote connections are handled via TCP and encrypted in SSL/TLS.
Usage
Usage: mrci <arguments>
<Arguments>
-help : display usage information about this application.
-start : start a new host instance in the background.
-stop : stop the current host instance if one is currently running.
-about : display versioning/warranty information about this application.
-addr {ip_address:port} : set the listening address and port for TCP clients.
-status : display status information about the host instance if it is currently running.
-reset_root : reset the root account password to default.
-executor : this starts a command executor instance. this is normally for internal use only.
-host : this starts a blocking host instance. this is normally for internal use only.
Other than that, the host can only be managed via a connected client that supports text input/output so the host application is always listening for clients while running entirely in the background. By default, the host listen for clients on address 127.0.0.1 and port 35516. Just like any linux OS, the host will have an administrative user called root along with a group also called root. This account can be used to modify anything on the host without restriction. The default password set to (R00tPa$$w0rd) when logging in for the first time as root, the host will require you to change the password before continuing.
More Than Just a Command Interpreter
Typical use for a MRCI host is to run commands that clients ask it to run, very similar to what you see in terminal emulators. It however does have a few feasures typically not seen in local terminals:
- Broadcast any type of data to all peers connected to the host.
- Run remote commands on connected peers.
- Host object positioning data for peers (online games do this).
- Send data to/from a peer client directly.
- Fully feasured builtin user account management.
- Built in permissions and command access management.
- Host limits management (max concurrent users, max failed password attempts, etc...).
- Account recovery emailing in case of forgotten passwords. **
- Acesss to various logs.
- Built in host file management (copy, move, delete, etc...).
- Built in file upload/download support.
Because the host is modular, the things you can customize it to do is almost limitless by simply adding more commands.
** The email system of this application depends on external email clients that run on the command line. The default is mutt. If you want emails to work out of the box, consider installing and configuring mutt. It just needs to be configured with a smtp account to send emails with. You don't have to use mutt though, the host does have options to change the email client to any other application that has a command line interface.
Documentation
- 1.1 The Protocol
- 2.1 Command Loaders
- 3.1 Command Objects
- 4.1 Type IDs
- 5.1 Host Features
- 6.1 Async Commands
- 7.1 Internal Commands
Development Setup
Linux Required Packages:
qtbase5-dev
libssl-dev
gcc
make
makeself
Build From Source (Linux)
Linux_build.sh is a custom script designed to build this project from the source code using qmake, make and makeself. You can pass 2 optional arguments:
- The path to the QT bin folder in case you want to compile with a QT install not defined in PATH.
- Path of the output makeself file (usually has a .run extension). If not given, the outfile will be named mrci-1.0.0.run in the source code folder.
Build:
cd /path/to/source/code
sh ./linux_build.sh
Install:
chmod +x ./mrci-1.0.0.run
./mrci-1.0.0.run
The makeself installer not only installs the application but also installs it as a service if the target linux system supports systemd.
Start/Stop the service:
sudo systemctl start mrci@$USER
sudo systemctl stop mrci@$USER