53.6. How RPC Works
RPC is a protocol that one Webmin system can use to control another. An RPC request is usually a call to a function in the library of some module, and includes the parameters to that function. There are, however, other RPC request types for transferring data to and from a server, checking to see if a module is available, getting a module's configuration, and executing a piece of Perl code. This section explains the technical details of how it works, and can be skipped if you are not a programmer and not having any trouble with RPC connections.
When you set up the System and Server Status module to fetch status information from a remote system, an RPC call is made to functions in the same module on that system to determine if a service is up or down. When a user is added in the Cluster Users and Groups module, multiple RPC calls are also made to add her to the password file, create her home directory, and copy files into it. Chapter 56 explains how to make use of RPC in your own modules, and what its limitations are.
As explained earlier, RPC has two different modes—fast and slow. Slow mode is simplest, as it uses an HTTP request from the master to the slave for each RPC function call, file transfer, or request for information. All parameters, data, and return values are included in that request and its response and no other TCP connections are made. The advantage of this mode is that it can work through firewalls and proxies, as long as HTTP requests to port 10000 are allowed.
Apart from being slow, this mode has one big negative—HTTP is a stateless protocol, but Webmin RPC calls are not stateless. It is quite possible for one function call to set a global variable that the next function call depends upon. This means that a background process in which state is kept must be started on the remote system for each master that opens an RPC session. There is no way, however, for a slave system to automatically detect when the master CGI program has finished and shut down the background process because no direct connection between the two exists!
Webmin's solution is to have the process exit when the master makes a special RPC call, or after 30 seconds of inactivity. If a master CGI program does not invoke the remote_finished function, the remote process will hang around consuming memory until the timeout elapses. If for some reason more than 30 seconds pass between RPC calls to the same host, the background process will exit and future RPC calls will fail.
The newer fast RPC protocol solves these problems using only one initial HTTP request to have a background process started on the remote system. The master server then makes a TCP connection to this process (which is listening on a free port), and sends RPC requests through that connection instead. When the master program exits, this connection will be automatically torn down and the remote background process will exit. No special function calls or timeouts are needed.
Fast RPC mode has much better support for transferring large files to and from remote systems. The slow mode attempts to encode files inside an HTTP request, which can fail if they are too large. The newer mode instead transfers them unencoded through a separate TCP connection, which is quicker and far more reliable. The Cluster Software Packages and Cluster Webmin Configuration modules may fail when installing a large package in slow mode.
The only problem with fast mode is that some firewalls may block the TCP connection, which is typically made on a port that is one or two higher than the remote host's base Webmin port, such as 10001 or 10002. Multiple connections may be made if data is transferred with RPC, so any firewall on your network between the two servers must be configured to allow connections from the master to the remote host on ports in the range of 10000 up to 10100.