72d57a0b10
Made some major changes to the project to facilitate a lighter code base and the must flexible module interface possible. -the mutli-process architecture now operate at the command object level so each command now operate in it's own process instead of a single process handling multiple command objects. -each module is now an independent application that will now tell the session object all of the commands it can run via named pipe. during command execution, it will run the requested command object also running io with the session object via named pipe. with this change, it is now possible for modules to be developed in different versions or QT or entirely different languages. the only requirement is the need to support named pipes. shared memory segments is also a nice to have but not needed. -clients can now run multiple instances of the same command via changes to the protocol. mrci frames will now include a branch id along with the command id. the branch id can be used by clients to differentiate the io between instances of the same command. -the command states are longer controlled by a single object. it will now be up to the command object (internal/exterenal) to send an IDLE frame to the client to notify it that the command has finished. the session object will still track if the command is in idle state or not but not directly control it. -must async commands now use binary formatted data instead of TEXT as a way to reduce overhead. -all command objects can now send async commands. it is no longer limited to just internal commands, however; the data of these async commands are verified by session in some way to prevent host crashing due to malformed data. -changed up the database structure to rely more on user ids, channel ids and removed all foreign keys pointing to user names, channel names and sub-channel names. also removed the groups table altogether. instead, the host rank is now directly attached to the user data in the users table. -changed the query object to now support the INNER JOIN SQL clause. this change was needed to support the new database structure. -version negotiation is now one-way via tcp connection or module interface. the host will make it's own verion numner known to the client connected via tcp or the module connected via named pipe. it will now be entirely up to the client or module to decide if they support the host. another change in this regard is the removal of the import rev for the modules. compatibility for modules shall now use just the host verion. -removed ls_cmds and cmd_info. the NEW_CMD frame now carries all information about the command (cmd_id, cmd_name, summery, io and full_description) so it is now possible for the clients to display the command documentation instead of the host. Documentation for the internal commands were updated to reflect the changes but all other documentation will need to be updated in the near future. |
||
|---|---|---|
| docs | ||
| modules/Tester | ||
| src | ||
| .gitignore | ||
| cmd_docs.qrc | ||
| LICENSE.md | ||
| linux_build.sh | ||
| MRCI.pro | ||
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-x.x.x.run in the source code folder.
Build:
cd /path/to/source/code
sh ./linux_build.sh
Install:
chmod +x ./mrci-x.x.x.run
./mrci-x.x.x.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