Generic ARPA2 commandline shell support -- shell switching -- JSON/AMQP backend
The ARPA2 Shell Collection
ARPA2 Shells are the control programs for hosts that implement parts of the InternetWide Architecture. They may integrate with components like LDAP, Kerberos or databases to setup and control those components. The shells have an interactive interface and a JSON access path.
To operate a node in your infrastructure, you might use the basic commands relating to the various programs that make them do what they are supposed to do. Or you might use a wrapper shell that is designed to make functionality available at a conceptual level. This is the intention of the ARPA2 Shells.
As part of doing something, an infrastructural node may need to order co-operation from another node. This too can be done using traditional techniques, for instance accessing a shell and sending a command. then scraping the output. This tends to be tedious and errorprone. The ARPA2 Shells facilitate a JSON access channel to accommodate such commands in an automation-friendly manner, and indeed the shells can calll on each other.
A vital part in the design of the ARPA2 Shell system is that they exercise access control not on the sessions, but on the individual commands. This is a bit like file access permissions, but now applied to operations. Here it helps that the operations aim to be conceptual, rather than mechanical. Instead of granting the permission to write a file, you would be granting the permission to add and remove users under a domain.
An interesting result of this detailed level of access control is that we can open the system to anyone. The shells and their JSON interfaces are open to any user anywhere, both internal and external, but before they can succeed in running a certain command they need to be qualified to run just that command. In other words, anyone accessing our shells can get a prompt -- but they may still be impotent when it comes to issuing commands. This openness is of importance with our intended pluggable infrastructure, where third parties can plugin service under our domain and we allow them a limited degree of control.
Command Syntax implies JSON Scheme
The commands issued have a clear syntax, of which the ARPA2 Shells
are aware. This is inherited from the
by Andy Pearce. We extended this package with a JSON interface,
using the same grammar to form a JSON scheme. We are still hoping
to integrate our work into the original package, but have ceased
waiting and instead forked the package. You can use our package
arpa2shell.cmdparser as a drop-in replacement for the original
cmdparser.cmdparser package in its 1.0.1 version.
arpa2shell.Cmd is a generic class from which the
ARPA2 Shells all inherit. It provides them with a few general
facilities by which their behaviour is more general. We may
also add a few other general things in the
such as LDAP access, or sending JSON commands to that interface
of other ARPA2 Shells.
Shells install as entry points into the
arpa2shell or other
packages, and the generic shell installs as an
command. This command might be started as a shell anywhere,
but will most commonly be used to service an OpenSSH login
or other (remote) console access attempts.
arpa2shell does not process commands on its own, but it
can launch other shells. This allows switching back and forth
between command environments that setup different aspects of
the infrastructure. It is also possible to prefix a command
for a subshell with that subshell's name. The result is that
ARPA2 Shells can focus on one aspect alone, while operators
still have control over as many of these aspects as they need
on any particular node.
Choosing GSS-API and AMQP 1.0
ARPA2 Shells can send commands to subshells, but they should not do this directly. Instead, they should rely on a switching backbone that grants optimum flexibility to the operator and domain owners. This is established by messaging through AMQP 1.0, where access control is achieved through GSS-API with credential forwarding.
We use GSS-API as an end-to-end encryption/authentication layer, not TLS. This might sound obnoxious, but it is grown out of a true need. TLS does not protect end-to-end traffic, but instead a single client-server connection. Since we intend to allow any user to access any shell, we need to account for deep linking into our infrastructure. Again, the objective is to support external components diving into whatever parts of the infrastructure and simply control their usage of conceptual commands.
The choice to transport over AMQP 1.0 is for the same reason; having end-to-end protection, we can now allow for flexible routing of messages between infrastructural nodes, at least for the passing of JSON messages. This is best done with a flexible infrastructure. It is true that AMQP 1.0 is more complex than its predecessors, but the upgrade to 1.0 enables the routing of messages between domains, and that is in the interest of externally provided services being plugged into our infrastructure.
Multiple Shells in one Setup
Operators may install multiple shells on one machine, and
to simplify that we support multiple shells in one Git repository.
This is not required, other repositories can add their own shells
arpa2shell name space.
setup.py builds and distributes multiple software
packages at once. You normally want to install the ones that
make sense locally, so keep an eye on that. We may split up
setup.py later if that makes sense.
The currently supported shells are:
Download the file for your platform. If you're not sure which to choose, learn more about installing packages.
|Filename, size||File type||Python version||Upload date||Hashes|
|Filename, size arpa2.shell-0.1.0-py3-none-any.whl (38.0 kB)||File type Wheel||Python version py3||Upload date||Hashes View hashes|
|Filename, size arpa2.shell-0.1.0.tar.gz (4.8 kB)||File type Source||Python version None||Upload date||Hashes View hashes|
Hashes for arpa2.shell-0.1.0-py3-none-any.whl