Something Happened on the Way to Remote Connection

Introduction

RPM Remote Print Manager® ("RPM") is a Windows service, which is not news to you if you are reading this web site. RPM does not itself appear on anyone’s monitor; it runs in the background only. We also have a user interface that we call the “UI” because we’re tech people and we abbreviate everything.

Typically people use the UI to watch RPM running on the same machine. When you install RPM at first, we launch the UI. All the basic setup and fine-tuning happens in the UI. Of course, that is not news, either.

What may be news to some is that the UI is capable of working with RPM on another computer in your network. This is because the UI and RPM use the network to communicate; it doesn't have to be on the same computer.

I know you can hear me now

The UI talks with the service using a custom Remote Procedure Call (RPC) mechanism. RPC is a term that has been around the computer industry for decades. Ours uses a command set and a rigorous set of rules for communication. All that is pretty typical.

We also connect with the Firebird database using the Firebird server. Firebird also uses the network, and it is simple to connect to a Firebird database on another server.

This all seems like a recipe for simplicity. However, it's easily a recipe for disaster.

Security first

The last thing you want is for someone on your network to take over your RPM configuration and send your print jobs to their own printer. For a check printing business, that's very bad. Any unauthorized tampering is extremely unwelcome.

For that reason, we build basic security into our RPC permissions. Each RPM installation has a full configuration for each of the protocols it supports. We treat RPC like any other protocol by giving it the permissions it needs to run securely.

Putting everything in the right place

How do we set this up? First, since we're talking about security (and security is the first thing we should get right) let's add a computer to an RPM configuration.

In the UI, go to the Configure menu and select Port Settings. You'll see a window like this one:

Configure port settings in RPM

Double click on the line where the protocol is "rpc". The ID is not important. If this isn't your day for double-clicking (and sometimes it's not for me) select that line and click Modify Port.

You'll see a window like this:

RPC port settings

Click the Add Host button and you'll see a window like this one:

Adding a host to RPC using IP address

Without showing you the entire window again, the Authorized Hosts lists now includes our new IP address:

Host now added to access list

Now our RPM installation is ready to accept a remote connection from the UI on that host.

But ... what about me?

I know you want to do the same thing I did. Connect to a remote RPM and see what that experience is like.

In this case, I contacted the owner of a machine called "nagel" on our network. First, I pinged nagel from a command prompt window just to make sure I can see it:

pinging network host nagel

You might recognize nagel as the host with the IP address we used earlier. There is no real reason to use a host name over an IP address other than what works well for you. RPM supports both because, why wouldn't it?

If you don't have ping installed on your system, do a search on "install ping on windows". There is nothing difficult about it.

Next, in the UI, go to the Servers menu. On my installation it looked like this:

RPC servers menu in RPM

I clicked Add Server and then added the host "nagel". My result looks like this:

Adding a remote host for UI

Now when I click OK and check the menu again, I see the host "nagel" is now an option. If I want, I can connect directly to nagel from the menu:

RPC servers menu with added host

When I do that, I can see the queue, jobs, and settings on nagel.

Conclusion

I started writing this article based on a support question. The caller asked about the "host access" function when they were looking to do what we describe here.

Host access limits incoming requests and that would certainly work. However, with RPC we decided that winnowing down the traffic was not enough. Given the severity of the consequences of letting someone see your RPM installation on this level, we believe it's better to explicitly grant access.

I hope this makes sense and that you connect productively. If you have any questions, please let us know!