view release on metacpan or  search on metacpan

t/data/update/remctl/docknot.yaml  view on Meta::CPAN

    `configure`.  To change this, you will need to run `perl Makefile.PL` in
    the `perl` subdirectory of the build tree with appropriate options and
    rebuild the module after running `make` and before running `make install`.

    To also build the remctl PECL extension for PHP, pass the `--enable-php`
    option to `configure`.  The PHP PECL module build is handled by the normal
    PHP extension build system and therefore will be installed into your local
    PHP module directory.  The configure script will look for `phpize` on your
    `PATH` by default; if it's in some other directory, set the `PHPIZE`
    environment variable to the full path or set it on the configure command
    line.  The configure script for the PECL extension will be run during the
    build instead of during configure.  This is unfortunately apparently
    unavoidable given how the PECL build system works.

    To also build the Python bindings for the libremctl client library, pass
    the `--enable-python` option to configure.  The Python module build is
    handled by the normal Python extension build system, and therefore will be
    installed into your local Python module directory regardless of the
    `--prefix` argument to `configure`.  To change this, you will need to run
    `python setup.py install` by hand in the `python` directory with whatever
    options you want to use.

    To also build the Ruby bindings for the libremctl client library, pass
    the `--enable-ruby` option to configure.  The Ruby module build is handled
    by the normal Ruby module build system, and therefore will be installed
    into your local Ruby module directory regardless of the `--prefix`
    argument to `configure`.  To change this, override the `sitedir` variable on
    the `make install` command line, as in:

    ```
        make install sitedir=/opt/ruby
    ```

    The remctl build system also supports a few other environment variables
    that can be set to control aspects of the Perl, Python, and Ruby binding
    build systems.  These are primarily only of use when packaging the
    software.  For more information, a list of the variables, and their
    effects, see the comment at the start of `Makefile.am`.

    The Java client and server aren't integrated with the regular build
    system.  For information on building and installing them, see
    `java/README`.

    remctl will use pkg-config if it's available to find the build flags for
    libevent.  You can control which pkg-config binary and paths are used with
    the normal pkg-config environment variables of `PKG_CONFIG`,
    `PKG_CONFIG_PATH`, and `PKG_CONFIG_LIBDIR`, and you can override the
    pkg-config results with `LIBEVENT_CFLAGS` and `LIBEVENT_LIBS`.
    Alternately, you can bypass pkg-config by passing one or more of
    `--with-libevent`, `--with-libevent-include`, and `--with-libevent-lib` to
    indicate the install prefix, include directory, or library directory.

    remctl will automatically build with PCRE support if pcre-config or the
    PCRE library are found.  You can pass `--with-pcre` to configure to
    specify the root directory where PCRE is installed, or set the include and
    library directories separately with `--with-pcre-include` and
    `--with-pcre-lib`.  You can also set `PCRE_CONFIG` to point to a different
    pcre-config script, or do similar things as with `PATH_KRB5_CONFIG`
    described below.

    remctl will automatically build with GPUT support if the GPUT header and
    library are found.  You can pass `--with-gput` to configure to specify the
    root directory where GPUT is installed, or set the include and library
    directories separately with `--with-gput-include` and `--with-gput-lib`.
  reduced_depends: true
  type: Autoconf
copyrights:
- holder: Russ Allbery <eagle@eyrie.org>
  years: 2015-2016, 2018
- holder: The Board of Trustees of the Leland Stanford Junior University
  years: 2002-2014
description: |
  remctl is a client/server application that supports remote execution of
  specific commands, using Kerberos GSS-API for authentication and
  confidentiality.  The commands a given user can execute are controlled by
  a configuration file and ACL files and can easily be tightly limited,
  unlike with rsh.  The mapping of command to backend program is done by the
  configuration file, which allows some additional flexibility compared to
  ssh command restrictions and works with Kerberos authentications rather
  than being limited to public key authentications.

  remctld is very similar to a CGI server that uses a different network
  protocol than HTTP, always does strong authentication before executing the
  desired command, and guarantees the data is encrypted on the network.
  Alternately, you can think of it as a very simple combination of Kerberos
  ssh and sudo, without most of the features of both but with simpler
  authorization.

  There are a lot of different client/server systems that do something
  similar, including regular rsh, CGI, IBM's sysctl (not to be confused with
  the Linux kernel call and configuration file of the same name), CERN's
  arc, and more elaborate systems like MIT's Moira.  remctl has the
  advantage over many of these schemes of using GSS-API and being about as
  simple as it possibly can be while still being useful.  It doesn't require
  any particular programming language, builds self-contained binaries, and
  uses as minimal of a protocol as possible.

  Both C and Java clients and servers are provided, as well as Perl, PHP,
  and Python bindings for the C client library.  For more information about
  the Java client, see `java/README`.  For more information about the PHP
  bindings, see `php/README`.  For more information about the Python
  bindings, see `python/README`.

  Also included in the remctl package is an alternate way of running the
  remctl server: remctl-shell.  This program is designed to be run as either
  a shell or a forced command under ssh, using ssh for authentication and
  communicating the authentication information to remctl-shell via either
  environment variables or command-line arguments via the forced command
  configuration.  This version of the server uses simple ssh clients, rather
  than using the remctl client program or libraries.

  remctl was originally written by Anton Ushakov as a replacement for IBM's
  sysctl, a client/server application with Kerberos v4 authentication that
  allowed the client to run Tcl code on the server, protected by ACLs.  At
  Stanford, we used sysctl extensively, but mostly only to run external
  programs, so remctl was developed as a Kerberos v5 equivalent that did
  only the portions we needed.

  Complete protocol documentation is available in `docs/protocol.html`.
  Also present, as `docs/design.html`, is the original design document (now
  somewhat out of date).
distribution:
  packaging: