MCP-CMS

From Cibernética Americana
Revision as of 14:44, 3 January 2022 by Root (talk | contribs)

mcpcms  

master control program  
CMS MCS shell  
    conversational monitor system  

launch

The launch link leads to a MCP¹ shell provisioned from core domain space or the AWS, linode, or LAN/DIY inventory ² configured in the KEE Dashboard Control Block in your home profile. A MCS is a message control system operating under a MCP. ABORTED, ACTIVE, INUSE, COMPLETEDOK, or STOPPED are the possible job completion codes ³ for the launch attempt from the DS station at which you're currently authenticated.

Configuring a device control block for it in your profile dashboard enables system port management, or you can manually manage ssh as usual (e.g using ssh-copy-id).

Launch states ABORTED, COMPLETED, OR STOPPED, imply receipt of diagnostic info by the currently selected means of notification in your home profile (icon above, left of launch status). ABORTED is the immediate result if you are not authenticated.

A running SPO counts as a against account launch limits.



¹Core space resources are only dynamically allocated for AKPERSONs.
² AWS, Linode, or your Gb LAN. MCP nodes must have sub-millisecond ping. Set cloud vendor credentials in your commons dashboard or run the MCP leader in your LAN.

The namestyle is a homage to MCP and VM/CMS.
While initially only linux is supported, more kernel OS support is intended. A command and edit (CANDE) MCS wraps the ssh protocol.
Operators use a CANDE MCS for MCP command line ops which can use:

  • mcpcms, the default, a custom zsh.

  • and any of

  • shcl (common lisp nature)
  • HsShellScript (haskell nature)
  • upsh (prolog nature)

Only mcpcms need be set in /etc/shells, the others execute as commands in a mcpcms session, and only shcl gives a shell like live command line. The other two require a user supplied haskell or prolog script, and are not general interactive shells unless user script includes that functionality. CANDE scope (local or MCP or DCP) is determined by the nature of the node and privilege level.

GHC is the haskell implementation. Lisp and prolog implementations are variable, and multiple can be combined.

The mcpcms level is always present, the others are outer shells adapted for the domain space knowledge engineering context.
The KEE uses the three HOLs² listed but the mcpcms level is appropriate for regular command line ops in MCP.
Although diverged for DS, an effort will be made to track changes in still vital original lang specific shells.

Assuming the target is configured and ready, invoke mcpcms with:

 ssh  <station-agent>

                where            
           
                <station-agent>  ::= ipV6Address:port | ipV4Address:port | FQDSAgentName 
                FQDSAgentName   ::= <agentId>@<domain>:<port>

                and the port is system provided via automation or provided dynamically in the user's DCMS account profile                           
     

Semantics

The port is always required, there's no default and use of 22 for this purpose is prohibited. The bare station:port form presumes the user's unix account name is a valid agentId for the node station.

Roadmap

  • 1.0.0 PoC: working DCP provisioning of composed MCP images and mcpcms hosts via the DCMS> C-六 backend.
  • 1.1.0 First working SPO and WFL development server.
  • 1.2.0 Consolidation and productization release.
  • 2.0.0 Mature DDD/KEE product.

² High Order Language ³ The states COMPLETED, COMPILEDOK and SCHEDULED are invalid for the launch WFL job, but its task steps may have COMPLETED codes, usable in other interfaces.