Documenting NAS box VM setup procedure

[hamishmb]

Yeah, it's probably a few pages, so I'll do that then

[hamishmb]

Okay, this is a work in progress, as not everything is finalised yet, but we now have some basic instructions for creating the NAS box VM.

I have attached the updated installation spec here for review.

[hamishmb]

NB: I have now created all the users and tables, and set up the privileges properly.

The files that can be used to set the database up are available at https://wmtprojectsforum.altervista.org ... 0Box/Setup

[hamishmb]

I have completed the NAS box VM setup procedure. Attached is the new file.

Terry and Patrick, could you review this for me and check that it makes sense? If it does, I'll happily update the uploaded NAS box VM in Patrick's 7-zip archive that we've got on the fileserver.

[TerryJC]

Hamish,

Can you confirm that your changes are confined to the Section commencing on Page 41?

[hamishmb]

Yes, that's right.

[PatrickW]

Is this to be done with the base image in multi-attach mode, like for the Pi VMs, or is it on a clone? I think if I was coming in to this fresh, without any preconceptions, then my assumption would be "multi-attach", based on the PI VM instructions. But I'm biased to assume "clone", because the NAS VM has historically been completely separate.

I assume the disk is kept at 8GB (size of base image).

I'm slightly puzzled by the need to specify a Bridged Adapter. In theory, the way it is configured in the base image, you should be able to access the NAS VM from the host, either on 192.168.0.25 through the first network adapter, or a DHCP-assigned IP address through the second (NAT) network adapter. 192.168.0.25 won't work if your local network uses the 192.168.0.0/24 subnet, but the NAT option should always work. Clearly this was either untrue or unclear, so something about my instructions needs fixing there.

Bridged Adapters have a certain neatness to them, but I went for a NAT for the base image, because it's kind of a lowest common denominator. Not all networks will give you a second IP address for a VM that's been bridged onto the network. (e.g. some public WiFi, some university halls) And, if you're on an untrustworthy network, the NAT can be abused as an easy, rudimentary firewall to keep other network users away from your VM.

The statement about trimming having reduced the size by 700MB looks like an irrelevant holdover from my previous writing.

I only really looked at the section starting on page 41 in any detail, but from a quick look I don't think the rest of this version of the document takes into account my comments in the Smaller Pi VMs available on webserver thread.

Otherwise it all seems to make sense. I haven't tried actually building a VM using the procedure though.

[TerryJC]

I only really looked at the section starting on page 41 in any detail, but from a quick look I don't think the rest of this version of the document takes into account my comments in the Smaller Pi VMs available on webserver thread.

As I mentioned in my comment a bit further down from your post at the link above, I put off implementing your comments because Hamish had identified some other changes at the time. In any case, those changes would appear in my master copy to be designated V0.11 when i get round to it.

I've not done a huge amount of documentation recently, although I have just finished the first draft of the Installation Spec for the Webserver, which includes the VPN Server stuff. (I may move it to the River System Installation Spec or just put a reference there when other changes have bedded in.) I'll test this tomorrow when I do a trial installation on the standalone server, before I release it for further comment.

[hamishmb]

Is this to be done with the base image in multi-attach mode, like for the Pi VMs, or is it on a clone? I think if I was coming in to this fresh, without any preconceptions, then my assumption would be "multi-attach", based on the PI VM instructions. But I'm biased to assume "clone", because the NAS VM has historically been completely separate.

I assume the disk is kept at 8GB (size of base image).

Yes, it's a clone because there are quite a few changes and I'd like to keep it separate. Also yes I kept the disk size the same as the base image.

I'm slightly puzzled by the need to specify a Bridged Adapter. In theory, the way it is configured in the base image, you should be able to access the NAS VM from the host, either on 192.168.0.25 through the first network adapter, or a DHCP-assigned IP address through the second (NAT) network adapter. 192.168.0.25 won't work if your local network uses the 192.168.0.0/24 subnet, but the NAT option should always work. Clearly this was either untrue or unclear, so something about my instructions needs fixing there.

Bridged Adapters have a certain neatness to them, but I went for a NAT for the base image, because it's kind of a lowest common denominator. Not all networks will give you a second IP address for a VM that's been bridged onto the network. (e.g. some public WiFi, some university halls) And, if you're on an untrustworthy network, the NAT can be abused as an easy, rudimentary firewall to keep other network users away from your VM.

I might be wrong here. AFAIR I don't seem to be able to access the VM on 192.168.0.25 from the host because the fake WMT network is an internal network, but I didn't try it. Likewise for NAT, the VM gets a 10.2.x.x address for that, which I would again assume isn't accessible from the host, because NAT is being used. Have you had success doing either of these things?

The statement about trimming having reduced the size by 700MB looks like an irrelevant holdover from my previous writing.

Yes, I missed that. I suppose we should get rid of it.

[PatrickW]

Yes, it's a clone

I think you should make that explicit in the document.

I might be wrong here. AFAIR I don't seem to be able to access the VM on 192.168.0.25 from the host because the fake WMT network is an internal network, but I didn't try it. Likewise for NAT, the VM gets a 10.2.x.x address for that, which I would again assume isn't accessible from the host, because NAT is being used. Have you had success doing either of these things?

I'm sorry, I was mistaken about NAT networks. I was certain I'd done it before, but I just checked and it's impossible. VirtualBox does not create a virtual network adapter on the host that corresponds to the NAT network, which means there is no route for traffic to flow from host-to-guest or vice versa. What you can do is set up a port forward and connect from outside of the NAT network, but that's not likely to be convenient for more than one guest.

It's possible to have NAT and host-to-guest connectivity at the same time on one guest network interface, by connecting that interface to a host-only network and then doing NAT routing either on the host OS or in an additional VM. However, neither of those strategies is as easy as selecting a bridged adapter mode if you are in a situation where bridged networking will work fine. (I thought doing NAT routing on the host would be easy, using NetworkManager, but I just tried it and it actually needs a little bit of prodding to make it work. Easy if you know what you're doing, but not foolproof.)

You are certainly correct in thinking that you cannot connect from host to guest using an internal network. That's the main distinguishing characteristic between an internal network and a host-only network. I was talking about a host-only network, not an internal network.