# Package metadata for remctl.
#
# This file contains configuration for DocKnot used to generate
# documentation files (like README.md) and web pages.  Other documentation
# in this package is generated automatically from these files as part of
# the release process.  For more information, see DocKnot's documentation.
#
# DocKnot is available from <https://www.eyrie.org/~eagle/software/docknot/>.
#
# Copyright 2002-2003, 2005-2014, 2016, 2018-2020
#     Russ Allbery <eagle@eyrie.org>
#
# SPDX-License-Identifier: MIT

format: v1

name: remctl
maintainer: Russ Allbery <eagle@eyrie.org>
version: '3.18'
synopsis: remote authenticated command execution with ACLs

license:
  name: Expat
copyrights:
  - holder: Russ Allbery <eagle@eyrie.org>
    years: 2015-2022
  - holder: The Board of Trustees of the Leland Stanford Junior University
    years: 2002-2014

build:
  autoconf: '2.64'
  automake: '1.11'
  autotools: true
  bootstrap: |
    You will also need pkg-config installed to regenerate configure and
    xml2rfc to build the formatted protocol documentation.
  gssapi: true
  install: true
  kerberos: true
  manpages: true
  middle: |
    Solaris users should look at `examples/remctld.xml`, an SMF manifest for
    running the `remctld` daemon.

    To also build the Perl bindings for the libremctl client library, pass the
    `--enable-perl` option to `configure`.  The Perl module build is handled
    by the normal Perl extension build system, and therefore will be built
    with compiler flags defined by your Perl installation and installed into
    your local Perl module directory regardless of the `--prefix` argument to
    `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 PCRE2 or PCRE1 are
    found.  As with libevent, remctl will use pkg-config if it's available to
    find the build flags for PCRE2.  Use the same variables as documented by
    libevent to control which pkg-config is used, and override its results
    with `PCRE2_CFLAGS` and `PCRE2_LIBS`.  For PCRE1, the `pcre-config` script
    will be used.  You can set `PCRE_CONFIG` to point to a different
    pcre-config script, or do similar things as with `PATH_KRB5_CONFIG`
    described below.  Alternately, you can bypass pkg-config by passing one or
    more of `--with-pcre2`, `--with-pcre2-include`, `--with-pcre2-lib`,
    `--with-pcre`, `--with-pcre-include`, or `--with-pcre-lib` to indicate the
    install prefix, include directory, or library directory.

    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
distribution:
  packaging:
    debian:
      package: remctl
      summary: |
        Debian packages are available from Debian as of Debian 3.1 (sarge).
        For Debian 4.0 (etch) and later, install remctl-server for the server
        and remctl-client for the client.  (The sarge release had a single
        remctl package that contained both.)

        The Net::Remctl Perl module is available in Debian 5.0 (lenny) and
        newer; install libnet-remctl-perl for it.  The PHP bindings
        (php5-remctl), Python bindings (python-remctl), and Ruby bindings
        (ruby-remctl) are available in Debian 6.0 (squeeze) and newer.  The
        Ruby bindings package is named libremctl-ruby in Debian versions
        before 7.0 (wheezy).
    extra: |
      For those using Puppet, there is a [Puppet
      module](https://forge.puppetlabs.com/ccin2p3/remctl) available for
      installing the remctl server and managing server configurations.  This
      was written and is maintained by the IN2P3 Computing Centre; see that
      page for more information.
  section: kerberos
  tarname: remctl
  version: remctl
support:
  email: eagle@eyrie.org
  github: rra/remctl
  web: https://www.eyrie.org/~eagle/software/remctl/
vcs:
  browse: https://git.eyrie.org/?p=kerberos/remctl.git
  github: rra/remctl
  openhub: https://www.openhub.net/p/remctl
  status:
    workflow: build
  type: Git
  url: https://git.eyrie.org/git/kerberos/remctl.git

quote:
  author: Peter Marshall
  text: |
    Small deeds done are better than great deeds planned.
advisories:
  - date: 2018-04-01
    threshold: '3.14'
    versions: 3.12 and 3.13
docs:
  api:
    - name: remctl-api
      title: remctl and remctl_free_result
    - name: remctl_new
      title: remctl_new
    - name: remctl_open
      title: remctl_open
    - name: remctl_command
      title: remctl_command and remctl_commandv
    - name: remctl_output
      title: remctl_output
    - name: remctl_noop
      title: remctl_noop
    - name: remctl_close
      title: remctl_close
    - name: remctl_error
      title: remctl_error
    - name: remctl_set_ccache
      title: remctl_set_ccache
    - name: remctl_set_source_ip
      title: remctl_set_source_ip
    - name: remctl_set_timeout
      title: remctl_set_timeout
    - name: net-remctl
      title: Net::Remctl Perl module
    - name: net-remctl-backend
      title: Net::Remctl::Backend Perl module
  developer:
    - name: todo
      title: To-do list
    - name: extending
      title: Extending remctl
    - name: protocol
      title: Protocol specification
    - name: protocol-v4
      title: Protocol v4 draft
  user:
    - name: remctl
      title: remctl manual page
    - name: remctl-shell
      title: remctl-shell manual page
    - name: remctld
      title: remctld manual page
    - name: java-readme
      title: Java client and server README
    - name: php-readme
      title: PHP bindings README
    - name: python-readme
      title: Python bindings README
    - name: ruby-readme
      title: Ruby bindings README
    - name: thanks
      title: Thanks and credits

blurb: |
  remctl is a client/server application that supports remote execution of
  specific commands, using Kerberos GSS-API for authentication.  Authorization
  is controlled by a configuration file and ACL files and can be set
  separately for each command, unlike with rsh.  remctl is like a
  Kerberos-authenticated simple CGI server, or a combination of Kerberos ssh
  and sudo without most of the features and complexity of either.

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: current packages like gRPC, and a wealth of older systems like rsh,
  CGI, 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,
  Python, and Ruby 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`.  For more information about the Ruby
  bindings, see `ruby/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).

requirements: |
  The remctld server and the standard client are written in C and require a C
  compiler and GSS-API libraries to build.  Both will build against either MIT
  Kerberos or Heimdal of any reasonable vintage.  remctl will also build
  against the Kerberos GSS-API implementation shipped with AIX 5.2 (and
  possibly later versions) and the Solaris 10 generic GSS-API library (and
  possibly later versions).  The `remctl_set_ccache` implementation is
  improved by building with Kerberos libraries and a GSS-API library that
  supports `gss_krb5_import_cred`.

  The remctld server requires libevent 1.4.x or later.  It was only tested
  with libevent 1.4.13-stable and later, but should work with 1.4.4 or later.
  It is now only tested with libevent 2.x, so moving to a later version of
  libevent if possible is recommended.

  The remctl server will support regex ACLs if the system supports the POSIX
  regex API.  The remctl server also optionally supports PCRE regular
  expressions in ACLs.  To include that support, the PCRE library (either
  PCRE2 or PCRE1) is required.

  To build the remctl client for Windows, the Microsoft Windows SDK for
  Windows Vista and the MIT Kerberos for Windows SDK are required, along with
  a Microsoft Windows build environment (probably Visual Studio).  remctl has
  only been tested with the 3.2.1 MIT Kerberos for Windows SDK.  To run the
  resulting binary, MIT Kerberos for Windows must be installed and configured.
  The client was tested on Windows XP and Vista and should work on Windows
  2000 and up; however, the primary maintainer does not use or test Windows,
  so it's always possible Windows support has broken.  The server is not
  supported on Windows.

  To build the Perl bindings for the C client library, you will need Perl 5.10
  or later.

  To build the PHP bindings for the C client library, you will need PHP 5.x or
  later and phpize, plus any other programs that phpize requires.  PHP 5.x
  support has only been tested on 5.2 and 5.3, and PHP support is now only
  tested on PHP 7.x and later.

  To build the Python bindings for the C client library, you will need Python
  2.7, or Python 3.1 or later.  You will also need the setuptools and pytest
  modules and, for Python 2, the typing module.  Earlier versions may work
  back to possibly Python 2.3, but are not tested.

  To build the Ruby bindings for the C client library, you will need Ruby 1.8
  or later (primarily tested with 2.5 and later).

  None of the language bindings have been tested on Windows.

  A Java client and Java server are available in the java subdirectory, but
  they are not integrated into the normal build or built by default.  There is
  a basic Makefile in that directory that may require some tweaking.  It
  currently requires the Sun Java JDK (1.4.2, 5, or 6) or OpenJDK 6 or later.
  A considerably better Java client implementation is available on the `java`
  branch in the Git repository but has not yet been merged.

test:
  lancaster: true
  prefix: |
    remctl comes with a comprehensive test suite, but it requires some
    configuration in order to test anything other than low-level utility
    functions.  For the full test suite, you will need to have a keytab that
    can authenticate to a running KDC.  Using a test KDC environment, if you
    have one, is recommended.

    Follow the instructions in `tests/config/README` to configure the test
    suite.

    Now, you can run the test suite with:
  suffix: |
    On particularly slow or loaded systems, you may see intermittant failures
    from the `server/streaming` test because it's timing-sensitive.

    The test suite will also need to be able to bind to 127.0.0.1 on port
    11119 and 14373 to run test network server programs.

    To test anonymous authentication, the KDC configured in the test suite
    needs to support service tickets for the anonymous identity (not a
    standard configuration).  This test will be skipped if the KDC does not
    support this.

    To test user handling in remctld, you will need the `fakeroot` command
    (available in the `fakeroot` package in Debian and Ubuntu).  This test
    will be skipped if `fakeroot` isn't available.

    The following additional Perl modules will be used by the test suite for
    the main package and the Perl bindings if installed:

    * Test::MinimumVersion
    * Test::Perl::Critic
    * Test::Pod
    * Test::Pod::Coverage
    * Test::Spelling
    * Test::Strict
    * Test::Synopsis

    All are available on CPAN.  Those tests will be skipped if the modules are
    not available.

sections:
- title: Building on Windows
  body: |
    (These instructions are not tested by the author and are now dated.
    Updated instructions via a pull request, issue, or email are very
    welcome.)

    First, install the Microsoft Windows SDK for Windows Vista if you have not
    already.  This is a free download from Microsoft for users of "Genuine
    Microsoft Windows."  The `vcvars32.bat` environment provided by Visual
    Studio may work as an alternative, but has not been tested.

    Next, install the [MIT Kerberos for Windows
    SDK](https://web.mit.edu/kerberos/www/dist/index.html).  remctl has been
    tested with version 3.2.1 but should hopefully work with later versions.

    Then, follow these steps:

    1. Run the `InitEnv.cmd` script included with the Windows SDK with
       parameters `"/xp /release"`.

    2. Run the `configure.bat` script, giving it as an argument the location
       of the Kerberos for Windows SDK.  For example, if you installed the KfW
       SDK in `"c:\KfW SDK"`, you should run:

       ```
           configure "c:\KfW SDK"
       ```

    3. Run `nmake` to start compiling.  You can ignore the warnings.

    If all goes well, you will have `remctl.exe` and `remctl.dll`.  The latter
    is a shared library used by the client program.  It exports the same
    interface as the UNIX libremctl library.