App-DocKnot
view release on metacpan or search on metacpan
t/data/generate/remctl/docknot.yaml view on Meta::CPAN
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
t/data/generate/remctl/docknot.yaml view on Meta::CPAN
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
t/data/generate/remctl/docknot.yaml view on Meta::CPAN
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.
t/data/generate/remctl/docknot.yaml view on Meta::CPAN
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
t/data/generate/remctl/docknot.yaml view on Meta::CPAN
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.8 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.3 or later (primarily tested with Python 2.7). Python 3 is not
(yet) supported.
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
t/data/generate/remctl/docknot.yaml view on Meta::CPAN
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 intermittent 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::Spelling
* Test::Strict
* Test::Synopsis
All are available on CPAN. Those tests will be skipped if the modules are
not available.
t/data/generate/remctl/output/readme view on Meta::CPAN
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.
t/data/generate/remctl/output/readme view on Meta::CPAN
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.8 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.3 or later (primarily tested with Python 2.7). Python 3 is not
(yet) supported.
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.
To bootstrap from a Git checkout, or if you change the Automake files
t/data/generate/remctl/output/readme view on Meta::CPAN
If you are building from a Git clone, first run ./bootstrap in the
source directory to generate the build files. make install will
probably have to be done as root. Building outside of the source
directory is also supported, if you wish, by creating an empty directory
and then running configure with the correct relative path.
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
t/data/generate/remctl/output/readme view on Meta::CPAN
If a test fails, you can run a single test with verbose output via:
tests/runtests -o <name-of-test>
Do this instead of running the test program directly since it will
ensure that necessary environment variables are set up.
On particularly slow or loaded systems, you may see intermittent
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::Spelling
* Test::Strict
* Test::Synopsis
All are available on CPAN. Those tests will be skipped if the modules
are not available.
t/data/generate/remctl/output/readme-md view on Meta::CPAN
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
t/data/generate/remctl/output/readme-md view on Meta::CPAN
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.8 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.3 or later (primarily tested with Python 2.7). Python 3 is not
(yet) supported.
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.
To bootstrap from a Git checkout, or if you change the Automake files and
need to regenerate Makefile.in, you will need Automake 1.11 or later. For
t/data/generate/remctl/output/readme-md view on Meta::CPAN
If you are building from a Git clone, first run `./bootstrap` in the
source directory to generate the build files. `make install` will
probably have to be done as root. Building outside of the source
directory is also supported, if you wish, by creating an empty directory
and then running configure with the correct relative path.
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
t/data/generate/remctl/output/readme-md view on Meta::CPAN
```
tests/runtests -o <name-of-test>
```
Do this instead of running the test program directly since it will ensure
that necessary environment variables are set up.
On particularly slow or loaded systems, you may see intermittent 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::Spelling
* Test::Strict
* Test::Synopsis
All are available on CPAN. Those tests will be skipped if the modules are
not available.
t/data/generate/remctl/output/thread view on Meta::CPAN
[Archive]
\h2[Documentation]
\link[readme.html][General overview] \break
\link[news.html][Change summary] \break
\link[remctl.html][remctl manual page] \break
\link[remctl-shell.html][remctl-shell manual page] \break
\link[remctld.html][remctld manual page] \break
\link[java-readme.html][Java client and server README] \break
\link[php-readme.html][PHP bindings README] \break
\link[python-readme.html][Python bindings README] \break
\link[ruby-readme.html][Ruby bindings README] \break
\link[thanks.html][Thanks and credits]
\h2[Security Advisories]
\link[security/2018-04-01.html]
[2018-04-01]: remctl 3.12 and 3.13 \break
\h2[Development]
\link[extending.html][Extending remctl] \break
t/data/generate/remctl/output/thread view on Meta::CPAN
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 \code[java/README]. For more information about the
PHP bindings, see \code[php/README]. For more information about the
Python bindings, see \code[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
t/data/generate/remctl/output/thread view on Meta::CPAN
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.8 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.3 or later (primarily tested with Python 2.7). Python 3 is not
(yet) supported.
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 \code[java] branch in the Git repository but has not yet been merged.
To bootstrap from a Git checkout, or if you change the Automake files and
need to regenerate Makefile.in, you will need Automake 1.11 or later. For
t/data/generate/remctl/output/thread view on Meta::CPAN
An \link[https://archives.eyrie.org/software/ARCHIVE/remctl/] [archive of
older releases] is also available. \class(alert)[Versions older than 3.14
have known security vulnerabilities and should not be used.]
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).
See the \link[https://tracker.debian.org/pkg/remctl][Debian package
tracker] for more information.
For those using Puppet, there is a
\link[https://forge.puppetlabs.com/ccin2p3/remctl][Puppet module]
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.
t/data/generate/remctl/output/thread view on Meta::CPAN
\div(left)[
\class(first)[User documentation:]
\doc[readme.html][README]
\doc[news.html][Change summary]
\doc[remctl.html][remctl manual page]
\doc[remctl-shell.html][remctl-shell manual page]
\doc[remctld.html][remctld manual page]
\doc[java-readme.html][Java client and server README]
\doc[php-readme.html][PHP bindings README]
\doc[python-readme.html][Python bindings README]
\doc[ruby-readme.html][Ruby bindings README]
\doc[thanks.html][Thanks and credits]
\doc[license.html][License and copyright]
Security advisories:
\doc[security/2018-04-01.html]
[2018-04-01: 3.12 and 3.13]
Developer documentation:
t/data/generate/wallet/docknot.yaml view on Meta::CPAN
The Duo integration object support in the wallet server requires the
[Net::Duo](https://www.eyrie.org/~eagle/software/net-duo/), JSON, and
Perl6::Slurp Perl modules.
The password object support in the wallet server requires the
Crypt::GeneratePassword Perl module.
The LDAP attribute ACL verifier requires the Authen::SASL and Net::LDAP
Perl modules. This verifier only works with LDAP servers that support
GSS-API binds.
The NetDB ACL verifier (only of interest at sites using NetDB to manage
DNS) requires the Net::Remctl Perl module.
sections:
- title: Configuration
body: |
Before setting up the wallet server, review the Wallet::Config
documentation (with man Wallet::Config or perldoc Wallet::Config).
There are many customization options, some of which must be set.
t/data/generate/wallet/docknot.yaml view on Meta::CPAN
functions. To enable the full test suite, follow the instructions in:
* `tests/config/README`
* `perl/t/data/README`
Now, you can run the test suite with:
suffix: |
The test suite requires `remctld` be installed and available in the user's
path or in `/usr/local/sbin` or `/usr/sbin`; and that `sqlite3`, `kinit`,
and either `kvno` or `kgetcred` be installed and available on the user's
path. The test suite will also need to be able to bind to 127.0.0.1 on
ports 11119 and 14373 to test client/server network interactions.
The test suite uses a SQLite database for server-side and end-to-end
testing and therefore requires the DBD::SQLite and
DateTime::Format::SQLite Perl modules.
All of the requirements listed above will be required to run the full test
suite of server functionality, but tests will be selectively skipped if
their requirements aren't found.
t/data/generate/wallet/output/readme view on Meta::CPAN
The Duo integration object support in the wallet server requires the
Net::Duo [3], JSON, and Perl6::Slurp Perl modules.
[3] https://www.eyrie.org/~eagle/software/net-duo/
The password object support in the wallet server requires the
Crypt::GeneratePassword Perl module.
The LDAP attribute ACL verifier requires the Authen::SASL and Net::LDAP
Perl modules. This verifier only works with LDAP servers that support
GSS-API binds.
The NetDB ACL verifier (only of interest at sites using NetDB to manage
DNS) requires the Net::Remctl Perl module.
To bootstrap from a Git checkout, or if you change the Automake files
and need to regenerate Makefile.in, you will need Automake 1.11 or
later. For bootstrap or if you change configure.ac or any of the m4
files it includes and need to regenerate configure or config.h.in, you
will need Autoconf 2.64 or later. Perl is also required to generate
manual pages from a fresh Git checkout.
t/data/generate/wallet/output/readme view on Meta::CPAN
If a test fails, you can run a single test with verbose output via:
tests/runtests -o <name-of-test>
Do this instead of running the test program directly since it will
ensure that necessary environment variables are set up.
The test suite requires remctld be installed and available in the user's
path or in /usr/local/sbin or /usr/sbin; and that sqlite3, kinit, and
either kvno or kgetcred be installed and available on the user's path.
The test suite will also need to be able to bind to 127.0.0.1 on ports
11119 and 14373 to test client/server network interactions.
The test suite uses a SQLite database for server-side and end-to-end
testing and therefore requires the DBD::SQLite and
DateTime::Format::SQLite Perl modules.
All of the requirements listed above will be required to run the full
test suite of server functionality, but tests will be selectively
skipped if their requirements aren't found.
t/data/generate/wallet/output/readme-md view on Meta::CPAN
The Duo integration object support in the wallet server requires the
[Net::Duo](https://www.eyrie.org/~eagle/software/net-duo/), JSON, and
Perl6::Slurp Perl modules.
The password object support in the wallet server requires the
Crypt::GeneratePassword Perl module.
The LDAP attribute ACL verifier requires the Authen::SASL and Net::LDAP
Perl modules. This verifier only works with LDAP servers that support
GSS-API binds.
The NetDB ACL verifier (only of interest at sites using NetDB to manage
DNS) requires the Net::Remctl Perl module.
To bootstrap from a Git checkout, or if you change the Automake files and
need to regenerate Makefile.in, you will need Automake 1.11 or later. For
bootstrap or if you change configure.ac or any of the m4 files it includes
and need to regenerate configure or config.h.in, you will need Autoconf
2.64 or later. Perl is also required to generate manual pages from a
fresh Git checkout.
t/data/generate/wallet/output/readme-md view on Meta::CPAN
```
tests/runtests -o <name-of-test>
```
Do this instead of running the test program directly since it will ensure
that necessary environment variables are set up.
The test suite requires `remctld` be installed and available in the user's
path or in `/usr/local/sbin` or `/usr/sbin`; and that `sqlite3`, `kinit`,
and either `kvno` or `kgetcred` be installed and available on the user's
path. The test suite will also need to be able to bind to 127.0.0.1 on
ports 11119 and 14373 to test client/server network interactions.
The test suite uses a SQLite database for server-side and end-to-end
testing and therefore requires the DBD::SQLite and
DateTime::Format::SQLite Perl modules.
All of the requirements listed above will be required to run the full test
suite of server functionality, but tests will be selectively skipped if
their requirements aren't found.
t/data/generate/wallet/output/thread view on Meta::CPAN
The Duo integration object support in the wallet server requires the
\link[https://www.eyrie.org/~eagle/software/net-duo/][Net::Duo], JSON, and
Perl6::Slurp Perl modules.
The password object support in the wallet server requires the
Crypt::GeneratePassword Perl module.
The LDAP attribute ACL verifier requires the Authen::SASL and Net::LDAP
Perl modules. This verifier only works with LDAP servers that support
GSS-API binds.
The NetDB ACL verifier (only of interest at sites using NetDB to manage
DNS) requires the Net::Remctl Perl module.
To bootstrap from a Git checkout, or if you change the Automake files and
need to regenerate Makefile.in, you will need Automake 1.11 or later. For
bootstrap or if you change configure.ac or any of the m4 files it includes
and need to regenerate configure or config.h.in, you will need Autoconf
2.64 or later. Perl is also required to generate manual pages from a
fresh Git checkout.
t/data/update/remctl/docknot.yaml view on Meta::CPAN
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
t/data/update/remctl/docknot.yaml view on Meta::CPAN
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
t/data/update/remctl/docknot.yaml view on Meta::CPAN
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
t/data/update/remctl/docknot.yaml view on Meta::CPAN
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
format: v1
license:
name: Expat
maintainer: Russ Allbery <eagle@eyrie.org>
name: remctl
quote:
author: Peter Marshall
text: |
t/data/update/remctl/docknot.yaml view on Meta::CPAN
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.8 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.3 or later (primarily tested with Python 2.7). Python 3 is not
(yet) supported.
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.
sections:
- body: |
(These instructions are not tested by the author and are now dated.
t/data/update/remctl/docknot.yaml view on Meta::CPAN
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 intermittent 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::Spelling
* Test::Strict
* Test::Synopsis
All are available on CPAN. Those tests will be skipped if the modules are
not available.
t/data/update/remctl/old/build/middle view on Meta::CPAN
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
t/data/update/remctl/old/debian/summary view on Meta::CPAN
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).
t/data/update/remctl/old/description view on Meta::CPAN
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
t/data/update/remctl/old/metadata.json view on Meta::CPAN
{
"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",
},
],
"developer": [
{
"name": "extending",
"title": "Extending remctl",
t/data/update/remctl/old/requirements view on Meta::CPAN
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.8 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.3 or later (primarily tested with Python 2.7). Python 3 is not
(yet) supported.
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.
t/data/update/remctl/old/test/suffix view on Meta::CPAN
On particularly slow or loaded systems, you may see intermittent 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::Spelling
* Test::Strict
* Test::Synopsis
All are available on CPAN. Those tests will be skipped if the modules are
not available.
( run in 1.363 second using v1.01-cache-2.11-cpan-2398b32b56e )