How to one run a program installed in one machine from another machine

executablefilesremote

Is it possible to have, say, one machine with software installed and call that software from another machine? I thought this would be called an "application server" but by googling I find things that are not exactly what I want. My scenario is basically the following:

I have a computer at home with Ubuntu and a bunch of programs, under which one Latex distribution. This is setup as a server, with ssh-access, apache and the like. From my work computer, running Windows, I would like to use my Latex at home instead of installing it locally. But I would like it to store the files, in particular the generated PDF, in the Work computer (this is actually not extremely important: I can always copy the files later, but it would just save some time if it worked).

What are the possible ways to do that?

Best Answer

Yes it is possible, but there are multiple steps involved:

You must be able to reach your home computer running Linux from the internet. This means opening up port 22 (ssh) or your router at home, or a higher port if your provider blocks incoming access on ports below 1024. Then install openssh-server (and make it listen on any non-default port). You also need to know the routers IP address at home. Some routers have some functionality to update a dynamic name service. If that is not available your home computer can do that, or in the worst case send an email on a regular basis to your work address (you should be able to pull the IP address of the router from the headers of an email).
Your work computer needs to be setpu with PuTTY and an X extension. PuTTY makes the secure connection, the X entension is necessary to view the remote programs that are not commandline based. You can use Xming for that. It might be that you can just run the LaTeX commands without X, depending on which editor/environment you normally use.
PuTTY also allows you to copy files from your machine at home to your local machine.

Related Solutions

How to give a very stripped down login for viewing logs

The bash shell enters a restricted mode (when called rbash) that prevents users -among other things- from altering PATH or changing current directory with cd; by coupling this with the access control restriction provided by UNIX groups, you can restrict users to view only files in a certain directory.

I would implement it this way:

Create groups A, B, etc. - each group can read (but not write) the the corresponding directory and the log files in it:

$ ls -lF /var/log/syslog-ng
drwxr-x--- root A  ...  A/
drwxr-x--- root B  ...  B/
[...]

$ ls -l /var/log/syslog-ng/A/
-rwxr----- root A  ...  logfile.log
-rwxr----- root A  ...  logfile.log.1
[...]

Modify /etc/group and add users to these groups according to the logs you want them to read:
```
$ tail /etc/group
[...]
A: foo
B: bar
```
Create a directory to host the commands you want to give access to the log viewers; let's assume it's /usr/local/restricted/bin. Copy or hard-link the relevant commands to this directory.
Modify /etc/profile so that you set up the correct PATH for the restricted users: the restricted PATH should only include /usr/local/restricted/bin (or any other directory that hosts "safe" restricted commands).
Modify /etc/passwd and make sure the users are given the login shell rbash and the relevant /var/log/syslog-ng/XXX directory as home. They can now log in but are jailed to the home directory and can only use commands on the restricted PATH.

Note: It's easy to circumvent the restricted mode shell if you provide access to commands that allow users to exec an arbitrary command, e.g., PERL or almost any editor.

How is network mounted software executed

The technology they're using to make this happen is called NFS - Network File System. They may additionally be using another technology with NFS called automounts, specifically Autofs if it's Linux.

NFS

NFS allows folders from one machine to be accessible to another. There is nothing magical about this. There is a client and server that is facilitating this connection. When you access one of these directories that's been mounted on your system via the NFS client, calls are made from your system to relay the information regarding the directory and it's contents.

If one of the clients accesses a file within the directory, the NFS server relays the contents of this file to the NFS client too.

Autofs

Automounting is a technology that allows a client system to access a shared remote resource, such as NFS, on a temporary basis. That is to say that the NFS client system has access to this remote NFS share. But it isn't actively "using" it until someone attempts to access the shared directory. Only then does the NFS client attempt to "mount" this remote directory and its contents.

File content life-cycle

In either case there is no implicit transfer of the files to the NFS clients. That is to say they aren't physically copied to the clients in any long term way. The files are streamed to the clients when they attempt to access them. After use they're gone; they do not persist at the clients in any long term form.

Just to give you a rough idea, you could use the program strace to see some of the system calls that are made as a program runs. So, using this command for example:

$ strace echo "hello world" > afile

We could see how a file is written to the system. We could also use this form to write to an NFS mounted directory:

$ strace echo "hello world" > /home/sam/afile

Both of these traces a virtually identical.

### Local write

$ cat strace_wr_local.log 
execve("/bin/echo", ["echo", "hello world"], [/* 33 vars */]) = 0
...
fstat64(1, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7f80000
write(1, "hello world\n", 12)           = 12
close(1)                                = 0

### NFS write

$ cat strace_wr_remote.log 
execve("/bin/echo", ["echo", "hello world"], [/* 33 vars */]) = 0
...
fstat64(1, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7fbe000
write(1, "hello world\n", 12)           = 12
close(1)                                = 0

Reading is only slightly more interesting, but still basically identical.

### Local read

$ cat strace_rd_local.log 
execve("/bin/cat", ["cat", "afile"], [/* 33 vars */]) = 0
...
fstat64(1, {st_mode=S_IFREG|0644, st_size=1761, ...}) = 0
open("afile", O_RDONLY|O_LARGEFILE)     = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=12, ...}) = 0
read(3, "hello world\n", 4096)          = 12
write(1, "hello world\n", 12hello world
)           = 12
read(3, "", 4096)                       = 0
close(3)                                = 0

### NFS read

$ cat strace_rd_remote.log 
execve("/bin/cat", ["cat", "/home/sam/afile"], [/* 33 vars */]) = 0
...
fstat64(1, {st_mode=S_IFREG|0644, st_size=1771, ...}) = 0
open("/home/sam/afile", O_RDONLY|O_LARGEFILE) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=12, ...}) = 0
read(3, "hello world\n", 4096)          = 12
write(1, "hello world\n", 12hello world
)           = 12
read(3, "", 4096)                       = 0
close(3)                                = 0

Wading into the pool

If you're just generally curious about the NFS protocol you can read more about how it works here, in the section titled: NFS protocol basics. It's generally easy to get the basic concepts of how it works and there is an example of an NFS request, just to give you a general idea of how things work.

Diving deeper

If you truly want to peek behind the curtain you'll likely need to bring in a set of tools for collecting network traffic so that you can see the flowing of bits back and forth between the NFS server and one of its clients. Tools such has tcpdump or wireshark will likely be your friends in doing this deeper dive.

I would caution you to not waste your time unless you're truly the curious type, since deep dives like this require much skill and familiarity with a suite of Unix tools that I would consider only someone who has been using Unix for a dozen or so years.

This site will help you with this endeavor if you're truly curious:

http://linux-nfs.org/wiki/index.php/NetworkTracing