I'm trying to install Oracle 11g from scratch on an AWS Linux machine. In order to do so, I believe I'm required to enable X forwarding so I can use the graphical installation. I have never been good with X server/client situtations.
Setup:
- cygwin64 (local)
- NAT instance (Amazon)
- Linux instance in private subnet accessible through said NAT (Amazon)
I'd like to forward the Oracle installation from the Linux instance through the NAT and to my local machine. Any help would be appreciated. I'm happy to provide more information, especially since I haven't provided much so far. I'd also love to hear that I'm going about this all wrong and that it's easy to install Oracle from the command line.
The client and server seem "backwards" in the world of X, because your workstation is the "server," providing the service of a display device and keyboard/mouse... while the program you are running, often remotely, is the "client," using those display and input devices services.
So the program you want to run needs to be able to connect "backwards" to your machine, but you can forget, for a moment, about the NAT aspect, because that's not directly relevant. The important thing is that you have a way to establish a chain of SSH connections from end to end, and that should be all you'd need, because SSH does the work. No firewalls were harmed in the answering of this question.
I don't know what kind of SSH utility cygwin has, but it will presumably be comparable. I tested the following first when end to end Linux, and then by replacing "ssh" with "\Program Files (x86)\PuTTY\putty.exe" on a Windows 7 desktop machine for the workstation. Both scenarios worked as expected, and the arguments are conveniently the same.
We'll call the NAT machine hostname "natbox" and the database "databox".
On your local machine, your X server is presumably listening on port 6000, so we need to get traffic back to it.
I chose 5555 arbitrarily, but any unused value above 1024 should work. You could also use 6000 also but it makes the example even more counter-intuitive than it already is.
The first IP/port pair 127.0.0.1:5555 refers to the remote machine (natbox). Your SSH session will open a socket listening on port 5555 of the the loopback interface on the remote machine. The second IP/port pair 127.0.0.1:6000 refers to your workstation, which is the place the traffic is to return to. Connections to port 5555 on "natbox" will be tunneled back on your workstation, where an attempt will be made to connect to your local port 6000.
So now we're logged in to natbox, and the tunnel is half-built.
This makes an SSH connection to "databox" where it opens up a listen socket on that server's port 6000 bound to the loopback address. Connections hitting that port will be sent back down the ssh connection to "natbox" where they will try to connect to natbox's port 5555... which, in the prior step, we already have linked back to your workstation's port 6000 -- your X server.
Done.
Any X client program run on "databox" will try to connect to the local machine's display '0' on port 6000... which should end up back at your console.
This should open up a terminal window from "databox" on your local display. You don't need this, but it's probably going to be easier to verify and troubleshoot the X setup without dragging the Oracle componentry into the mix.
Note, the first reference to 127.0.0.1 (and the
:between it and the first port number) on the ssh-Roption are actually implicit, but I included them because it seems slightly less counter-intuitive to me. It is also possible to set this up in a cascade on a single command line, by providing the "command to execute" on the intermediate machine as the final argument to "ssh" on the local machine, as long as you add a-tto the first ssh so that it knows you want a tty end-to-end... but it was already complicated enough, so I didn't include that.