factotum - a simple http REST like server for pre-configured commands
Copyright (C) 2014-2015 Michael Rice <michael at riceclan dot org>

fac·to·tum
    /fakˈtōtəm/
    noun
    an employee who does all kinds of work.
    "he was employed as the general factotum"
    synonyms:	handyman, jack of all trades; assistant, man Friday, gal/girl
                Friday; gofer; informal Mr./Ms. Fix-It


factotum is conceived as a simple service that can run on any platform that
can run Python.  It will provide a HTTP/RESTful interface to run commands
on the machine it is running as, as the user it is running as.

This could be used, for example, to let a service account on one machine
hand off a task to a service account on a different machine.

For example: a git trigger that can cause a remote server to perform a git
pull as a completely different user.  This is to avoid the classic solution
 using a passwordless SSH with a passwordless SUDO command.

This program is free software: you can redistribute it and/or modify it
under the terms of the GNU Affero General Public License as published by
the Free Software Foundation, either version 3 of the License, or (at your
option) any later version.

This program is distributed in the hope that it will be useful, but WITHOUT
ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
FITNESS FOR A PARTICULAR PURPOSE.  See the GNU Affero General Public
License for more details.

You should have received a copy of the GNU Affero General Public License
along with this program.  If not, see <http://www.gnu.org/licenses/>.

Is this like:
  jenkins - 
    No, because jenkins runs as a web service on one machine and to cross
    privilege boundaries needs help (usually sudo or ssh).  
  oddjob -
    No, because factotum runs commands that the server configures, oddjob allows
    the client to configure jobs for the server (arbitrarily).
  webmin -
    Closer, but no, because factotum doesn't need to run as root, and is
    specialized, webmin is much more general purpose.  Also we envision REST
    APIs and not XML-RPC over HTTP to simplify calling from scripts like in a
    git post-commit hook.
  ssh -
    very close, with command= and from= limits in authorized keys we can control
    (force) a particular command.  However the server side configuration is just
    an authorized keys file which on a shared filesystem may be more servers than
    you want to allow.  Using tcpwrappers or iptables you can restrict/allow ssh
    in entirety, but you can't control that bob@thathost can run command@thishost
    (if bob has the private key, he can run command @ anyhost from anyhost).  Also
    limited to exactly one command.