Make a backup of network/interfaces before overwriting it

[oparoz]

It would be a good idea to make a backup of /etc/network/interfaces before overwriting it, because sometimes the scripts are used outside the VM because not everything needs to be installed, etc. and overwriting an existing config can break things.

[enoch85]

Not priority. Please make a PR. :)

Thanks for you issue!

[enoch85]

@oparoz Now when thinking about it, the VM scripts are designed to be installed on a clean system, and we overwrite it to get the correct variables for example $IFACE. So why save it?

[oparoz]

It's true that, because I didn't want everything to be managed by the script, I used it on a fresh install of Ubuntu server and that part of the script did not work and left the VM disconnected from the network.
Maybe there wouldn't have been a problem if we had booted the image, but since other things broke at install time, I'm just thinking that making a backup before touching critical config files isn't such a bad idea.

[enoch85]

Please explain further about the bug you found so that we can fix it. The VM is designed to fit ALL systems, but at the same time you have to mount it correctly (Bridged mode i.e.) for it to work.

Example: The VM uses ens33 as IFACE (network interface) when created by us, then you as a user downloads it and have another interface (let's say eth0), the script will fail with the ens33 IFACE so that's why we change it. In the install script we only check that the network is OK without changing anything as you probably use the install script to install the VM for the first time. In the startup script though (the one that is pre installed and run when the user boots the released VM for the first time) we do change the interfaces file becuase of the reason above and then test that the network is OK here: https://github.com/nextcloud/vm/blob/master/nextcloud-startup-script.sh#L42-L61

The "correct interface" is just the original interface on Ubuntu 16.04 with new IFACE, so that it breaks seems unlikley, and even if it did, you are not able to continue as we will stop you before any scripts are downloaded. That's by design. The scripts are fetching all the latest scripts from Github and it will break without them, but again - we test if your network connection is OK before running anything.

So where did it break?

[enoch85]

Maybe we should add more checks? @oparoz

[oparoz]

The interface was configured with a static IP and the script replaced the config with one which uses DHCP and that didn't work. That's how it broke.

I guess I could also write something which makes a backup of these files before trying to install NC...

[enoch85]

So you setup static IP address before you ran the script? Yeah, that won't work as that is not intentioned by design. Don't really know how to come around that issue as (again) the scripts installs on a completely fresh VM with no changes prior to the scripts are run.

Ofc, you can always make changes afterwards.

Any ideas on how to fix this?

[oparoz]

I think the easiest thing to do would be to simply ask.

1. Test the network
2. It works, go to the next step
3. It doesn't offer a DHCP fix

You could take it further by showing a diff, but it's probably not worth it at this stage

[enoch85]

In 99% of the cases the IFACE is different than the one on the host that created the VM. What is your proposal, to ditch the fix we added some months back so that users don't have to retype the IP address in the interfaces file if they already set up static IP?

Sorry I'm not following here. Are you good in bash? Please make me a proposal :)

[enoch85]

JFTR:

• techandme/owncloud-vm@cc8ad45
• techandme/owncloud-vm@3e61a0a
• techandme/owncloud-vm@d0ecfa9

Just as a few examples where we have have struggled with getting the correct IFACE and IP address in the past to fit as many of the useecases as possible. Right now I think it works great.

[oparoz]

Thanks for the references :)

For now, I'm just suggesting to make this step optional, just like the let's encrypt step. Some sysadmins will have the networking components under control and will only want to install Nextcloud.

[enoch85]

Problem is that requires more skills than I have right now, many if statements in each other.

• https://github.com/nextcloud/vm/blob/master/nextcloud-startup-script.sh#L42-L61
• https://github.com/nextcloud/vm/blob/master/nextcloud-startup-script.sh#L259-L305

Where to you propose for the fix to go in?

[oparoz]

Hmmm.... The steps which kill the network happened a lot earlier

https://github.com/nextcloud/vm/blob/master/nextcloud-startup-script.sh#L42-L46

But thinking about it, this will never work when using a remote console. So maybe there isn't any issues if the script runs until the end.

[oparoz]

Still it would be nice if those 2 steps could be grouped and made optional, like you did this step:
https://github.com/nextcloud/vm/blob/master/nextcloud-startup-script.sh#L332-L350

[enoch85]

Actually, that's another issue. Using a remote console will actually work as the IP isn't changed until the VM is rebooted even if you change it manually. In other words. if you started with an IP that IP will continue to server the VM until you reboot.

Scenario 1:

1. You have set a static IP before you run the install scripts.
2. The scripts resets that to a standard DHCP file. Probably the same as you started out with, exept a new IFACE
3. You get a new chance to set the same static IP as you started out with.
4. The IP will never change until you reboot anyway (users reported, didn't test it myself)

Scenario 2:

1. You have DHCP before you run the install scripts.
2. The scripts resets that to a standard DHCP file. Probably the same as you started out with, exept a new IFACE.
3. You set a static IP when prompted with the interfaces file.
4. The IP will never change until you reboot anyway (users reported, didn't test it myself)

So, resetting the connection won't matter even if you set a static IP to begin with, as you will get prompted with the interfaces file a second time, and then have the chance to recover your static IP. And as the IP doesn't change until you reboot anyway (service network restart doesn't work always, and not even ifdown and ifup sometimes), same goes for DHCP.

Also, the scripts wouldn't download at all without a working internet connection and you would be stopped before the script would even continue here: https://github.com/nextcloud/vm/blob/master/nextcloud-startup-script.sh#L48-L61

Are you following :)

[enoch85]

Point 4 makes the Let's Encrypt script fail if you manually edit any settings before the script is run.

[enoch85]

But sure, I could add a copy of the original interfaces file before the script make any changes, but after all it's just about adding like 6 numbers in the interfaces file as you are prompted here:https://github.com/nextcloud/vm/blob/master/nextcloud-startup-script.sh#L294 and have the possibility to add you specific IP again ...if that's what you mean?

[enoch85]

But then again, why make a backup if the user isn't even aware of that happening... Or are you thinking something like

echo "/etc/network/interfaces are now backed up before the script makes any changes to it"
echo "You can find the file here: /etc/network/interfaces_bak"
.... reset the interfaces file ...

[enoch85]

ping @oparoz --^ ?

[enoch85]

No I get what you mean. If you install on a VPS as root, you don't get promoted and the script starts instantly, and the first thing it does is to overwrite the interfaces file.

I will change this behaviour.