How to setup turnkey-mediawiki on remote linux host inside vmplayer without highjacking ssh?

0

I have been trying to solve this problem but have found only partial information like "use bridged mode" or "turn off the windows firewall" (for windows hosts), so I wanted to ask for specific advice for a linux host system in the form of command line statements to interrogate and change my setup.

I am trying to install a mediawiki for a non-commercial application using the free vmplayer on a linux host running a turnkey linux mediawiki vmdk file as guest system. I access the host system hostname, remotely via ssh -X hostname. The remote host is running ubuntu linux.

The vmplayer window is visible to me through an X window connection.

Answers to similar questions contain the advice to used bridged networking.

Option 1:

When I turn on bridged networking, the guest takes over the entire network connection of the host: The vmplayer window (that I see through the ssh connection to the host) becomes unresponsive and using ssh hostname takes me directly to the guest system. On the upside, navigating to hostname in a third system's web browser displays the mediawiki main page as intended.

Option 2:

Using NAT. I am aware of the vmware Advanced NAT Configuration page. The vmplayer window continues responding. In the guest system, IP addresses are assigned by DHCP. From the host system, I can see the mediawiki page when navigating to the guest IP in a local (text based) web browser. However, the mediawiki page does not display when navigating to hostname in a third browser.

The free vmplayer does not seem to come with the network configuration tool, and I don't know how to install it (for linux, there are descriptions for windows out there). I have edited the file

/etc/vmware/vmnet8/nat/nat.conf

to set

[incomingtcp]
80 = guest-IP:80

with no success (mediawiki page does not display in third system's browser).

So my questions are:

  1. How can I set up networking through the settings files (or how can I install free configuration tools for linux) so that only the web server is visible from outside the host system by navigating to hostname but without highjacking the ssh connection to the host? I am quite happy to ssh hostname and from there ssh guest-IP to access the IP but I would not like ssh hostname to take me to the guest system directly, as I would like to do other things on the host. Also, I'd like to reduce the number of attack vectors on the guest system by only forwarding the web port 80.

  2. How can I run the guest system without opening the vmplayer window, so that the mediawiki server runs by itself without further interaction?

Andreas

Posted 2014-12-07T03:04:52.497

Reputation: 101

Answers

1

It has been a while since I have used VMware products but IIRC they should act similarly to VirtualBox. I recall using VMware Server (on a Windows host) and I'm 99.9% sure that that worked the same as VirtualBox (and it's free too).

In other words, using 'Bridged networking', the guest system should receive it's own IP address and appear for all intents and purposes as a separate computer on your network. TBH it sounds very strange to me that the hostname is being hijacked by the guest system... Are you totally sure that's what is happening? In my experience, that's the result that you should get if you set up NAT networking (and forwarded the relevant ports to your guest).

By default the TurnKey appliance should get it's IP via DHCP. The only thing that I'm not sure of is using 'hostname' to ssh in (like you did in your example). I would expect it to still connect to the host (not the guest)...!? Perhaps it's better to use IPs? ssh user@<host-ip> should connect to your host machine and ssh root@<tkl-ip> should connect to your TKL Mediawiki appliance (and http:// should give you Mediawiki!).

To more specifically answer your Qs:

1) See notes above. If you want to reduce attack vectors why not just disable services you don;t want? That will reduce resource usage too! Once you have the networking figured out, you could disable password ssh login and use keys instead.

2) I don't quite understand the question... Wouldn't you just leave your server running all the time? (And minimise the window?). Perhaps VMware player has commandline switches that would allow you to launch your TKL server without a window (e.g. in a screen session?) I know that VirtualBox can do that...

Jeremy Davis

Posted 2014-12-07T03:04:52.497

Reputation: 121

yes, with bridged networking, ssh hostname takes me straight to the guest system and in NAT it doesn't, as described. Why should usernames make a difference - they are evaluated by the target reached through the IP address? On question (2), yes ideally I would like to run in a screen session, as the host has to be available for other tasks, both remotely and as a desktop, so having a window hanging out there is not an option. vmplayer has a unity mode but I don't understand how that works and documentation is scarce. – Andreas – 2014-12-08T17:58:20.000

I'm not married to using vmplayer, as long as I get to virtualize turnkey linux. Would you propose using VirtualBox instead? As far as I understand the TKL download specifically offers the VMKD image for vmplayer - does the same file work with VirtualBox? – Andreas – 2014-12-08T18:01:52.043

That behaviour seems weird to me... And as you say, usernames shouldn't matter, but I thought IPs might? (your TKL server should get it's own IP but perhaps for some strange reason it's hijacking the hostname?) AFAIK Unity mode is not what you want, that is more for making apps in the guest appear as if they are native to the host (e.g. run MS Word in a Win VM on an Ubuntu host). I'm not saying that VirtualBox is better, just that I know it better (and I'm a big open source fan, so always lean towards the FOSS option where available). – Jeremy Davis – 2014-12-08T20:55:10.043

FWIW plenty of docs on running VBox headless; google "virtualbox headless linux". The TKL VMDK is specifically built for VMware; but is essentially just a disk image. VMDK images are supported by VirtualBox and QEMU/KVM (and probably others too). – Jeremy Davis – 2014-12-08T20:58:31.783