remctl

April 2, 2009

To quote directly from the remctl documentation: “remctl (the client) and remctld (the server) implement a client/server protocol for running single commands on a remote host using Kerberos v5 authentication and returning the output”

I have been intending to find the chance to try out remctl for a while now as it looks like it could be very useful. In particular it should allow us to run nagios passive checks (e.g. for disk space usage) in a secure manner. It could also provide an improved method for remotely executing commands compared to the current way “om” just does a login using ssh.

Simon had already written an LCFG component which supported a lot of the necessary configuration so I took this work and finished it by adding support for command ACLs. To install it onto a server you now just need:

#include <lcfg/options/remctld.h>

On the client you will need at least the remctl package, you might also want the perl module but it’s not essential:

!profile.packages                       mEXTRA(remctl-2.13-1.inf\
                                   remctl-perl-2.13-1.inf)

Once you have installed the new packages on the server you will need to start (or restart) the LCFG xinetd component. To get it to do something useful you then need to add some commands, for example:

!remctld.aclgroups               mADD(foo)
!remctld.aclmembers_foo     mSET(squinney@INF.ED.AC.UK sxw@INF.ED.AC.UK)

!remctld.types                      mADD(om)
!remctld.services_om           mSET(ALL)
!remctld.exec_om_ALL         mSET(/usr/bin/om)
!remctld.aclfile_om_ALL        mSET(foo)

It’s not necessary to use groups of ACLs, you can define lists of allowed and denied users for each command. This approach just allows you to use the same ACL file for multiple commands.

To understand all of this requires some reading of the LCFG component docs and the remctl documentation but it’s hopefully fairly clear that this example would allow Simon and I to run om on that machine. Of particular benefit is the ability to allow specific users to run commands on a machine without giving them full shell access but still controlling the access in a secure manner. For example, a user could be allowed to restart a webserver (via om) although not allowed to login.