Nextcloud-snap: We need an UI to shut down the box

Created on 22 Oct 2016  路  23Comments  路  Source: nextcloud/nextcloud-snap

Right now, there is no way to shut down the Nextcloud Box without going in with SSH and running shutdown manually. That is a problem as we don't want people to have to do that.

Just pulling the plug works but you risk data corruption - I've already got one tale of that happening. We need a solution for this as sometimes people move their Box... Or do something to fortify it against sudden power loss.

Most helpful comment

@joltdude I'm sorry if I came off as hostile or dismissive. I don't mean to shrug any use-case off as niche, especially not the Box. I simply mean to suggest that we should consider all use-cases when it comes to a general-purpose snap, not just one. Indeed, data loss is a harsh reality-- no one is disputing that.

I reiterate: I never said this is a bad idea, or a niche use-case. The question is, how do we solve a problem specific to the box without making the snap specific to the box? I see a few options:

  • Make sure snapweb supports this (my favorite option, as it's the device manager, if you will).
  • Write a Nextcloud app contained within its own snap, and inject it into Nextcloud proper via the content interface. That can be pre-installed on the Box images without adding unnecessary features to the generic snap.
  • Protect this option with a configuration flag within the snap itself, defaulting to off, to show the option to shut down (presumably via an app). Then a user can enable it with snap set shutdownable=true (or similar) which can be pre-configured on the Box image.

And as I mentioned, this is still blocked on interface work, so we need to wait regardless of the path we choose. Until then, the best option is to SSH in and poweroff manually.

All 23 comments

Right now everybody needs to use SSH, so we should at least add some instructions to the wiki, but in the future, it would be nice indeed.

Indeed, logging into Nextcloud to shut the box down isn't ideal, either. Maybe a second rev of the design adding a power button! :wink:

Maybe a second rev of the design adding a power button! :wink:

Except that the snap is supposed to be hardware agnostic.
But even if WD were to come up with a hardware solution for every supported board which fits the Box, the snap would need one shutdown script per design.

All NAS solutions or router I've seen allow the user to shutdown or reboot from the GUI, so I think users will be OK with that.

Shutdown is an ugly thing ....

Wondering if you could use something akin to a USB key with a "magic file" on it... if its inserted ..or even a script.... the running snap detects the file and goes into shutdown?

The power lights (on most boards) will blink/turnoff on shutdown....

Yes i know there could be security issues on this but.. somehow the key could be tied to the board or the user account...

Not feeling for adding a shutdown button.
I am running My nextcloud snap instance on a VPS. Adding a shutdown button in this case is kind of useless.

I think i am not the only one running Nextcloud snap on a VPS.
I think for a shutdown solution, that this better can be implemented in hardware (shutdown button), and connect the button to the board with a shutdown script.

Your not the target audience for this feature. And the problem is it's difficult to make one hardware button that works on different boards. So what are you bringing to the table by saying it's not needed.. Just not needed by you since a dirty shutdown with arm boards can cause boot corruption.

@joltdude @bonsje has a good point. This snap is not just for users of the Nextcloud Box, but such a feature would be. It will take some thought.

Note that this is blocked on the lack of an interface encompassing the ability to power off, but progress is being made on that front.

Is someone going to reflash and recover my nextcloud box when this happens? Facility in software needs to be considered .. And dirty shutdowns of a vm aren't good practice either. Not feeling it because it doesn't apply to one's usage scenario is inconsiderate of other users. Of you don't need it, don't use it..

Likewise, blindly shoving features in because it fits your specific use-case is also inconsiderate of other users. I never said this wouldn't happen, I said it needs to be done in a thoughtful manner.

I wonder if snapweb would handle this, actually.

Alas my usage case is on supported dedicated hardware sold by the developer so I have good reason to expect it hardened. Don't think adding a kludge that relies on board type, additional hardware (another wiring harness) and possibly I/O pins .. So my use case is now considered niche and not mainstream. Then why did I buy it instead of a snap on a vm?

So I guess bonsje and you aren't feeling it supporting customers .. Don't expect it immediate (after all this is a F/OSS project and open to other platforms) but being dismissive of a somewhat important issue on a supported platform.. In not feeling it either...and saying I'm shoving it down your throat is a red herring.. Any filesystem/sd corruption is bad.. even if its due to user or environmental issues (i.e. power failure, power being cut to device)

Don't care about shutdown button perse, but corruption on power loss is a problem that goes along with it..

Idk how the box looks like IRL, but what about sudo poweroff from CLI? @joltdude

Im coming from experience with another device similar to the pi... which has a similar problem that never was really resolved... had to resetup the device and start fresh, (though it had some internal capacity to restore.. wondering if they were using a partition on the SD that wasnt touched while in use) due to a power failure... As stated before ideal is someone going to the CLI or web interface and shutting down proper... Perhaps this might be a case for the actual Snap OS vs the nextcloud snap... Or perhaps the nextcloud snap should be running on a a more rugged/resilient filesystem... having a fileserver that isnt back up and running on return of power or shortly thereafter.. due to its boot os being corrupt is an ugly thing. .. I presume eventually the nextcloud box is targeted for the prosumer... esp being based on a Pi.... Have to think of a common fault scenario.... Ideally the only admin that I should be needing is out of the web gui.. but realize that other things may play into it, esp folks running it on better hardware as a virtual machine...

There could be a web based cli but that's inherently insecure ...asus removed this useful feature from their routers because someone did a proof of concept with it..

I think the best thing to do would be to provide a desktop and/or mobile app. Write it in QT, feed it a script and fix all problems at the click of a button.
Look at how easy it is to root android devices that way.
That would certainly help with the broken OS which hundreds of buyers might struggle to fix using the command line and would definitely help for this use-case.

As an aside.. I'd like to bring up that there are going to be some code that may need to be specific for use-cases... esp when hardware is involved... Its a painful reality of dealing with hardware appliances... now whether its in the nextbox snap itself or ubuntu-core ... is always a question..... but if something needs to be there, it needs to be there, its like hardcoding links... not ideal, but real
Also realize that people just using Snap and Ubuntu-Core will not have the facilities of a full os install... and be missing some cli utilities they may expect... Just irritated that having the appliance version of this and sort of shrugged off as a small niche use-case...

@joltdude I'm sorry if I came off as hostile or dismissive. I don't mean to shrug any use-case off as niche, especially not the Box. I simply mean to suggest that we should consider all use-cases when it comes to a general-purpose snap, not just one. Indeed, data loss is a harsh reality-- no one is disputing that.

I reiterate: I never said this is a bad idea, or a niche use-case. The question is, how do we solve a problem specific to the box without making the snap specific to the box? I see a few options:

  • Make sure snapweb supports this (my favorite option, as it's the device manager, if you will).
  • Write a Nextcloud app contained within its own snap, and inject it into Nextcloud proper via the content interface. That can be pre-installed on the Box images without adding unnecessary features to the generic snap.
  • Protect this option with a configuration flag within the snap itself, defaulting to off, to show the option to shut down (presumably via an app). Then a user can enable it with snap set shutdownable=true (or similar) which can be pre-configured on the Box image.

And as I mentioned, this is still blocked on interface work, so we need to wait regardless of the path we choose. Until then, the best option is to SSH in and poweroff manually.

@jospoortvliet @oparoz do we have a project dedicated to the Box itself? It might be useful for tracking Box-specific features/bugs rather than diluting the snap.

My apologies as well for coming across as a bit demanding.. Ill admit I don't quite get whats in and out of a particular snap... The analogy i have in mind is vms but its fully accurate.. Because in a VM you still have the host os and its facilities, the VM os, and the slushware that connects the two.. Somewhat under the false impression that the nextcloud snap is mostly all inclusive... and do you need a snap for every app thats not in the core package? .. Or will there be a nextcloud snap, a ubuntu-core snap, and a device specific snap or script ?

, how do we solve a problem specific to the box without making the snap specific to the box?

Well, this snap specifically targets Box-like hardware where users don't SSH.
Anybody who knows how to do a snap install to get Nextcloud won't need another snap, a GUI or anything else as they will just log in and shutdown.

In that regard, the 2 first options that you mentioned make total sense.

do we have a project dedicated to the Box itself

Canonical tracks the OS and since we're dependant on them providing the kernel snaps for each device, it would make sense to track that at the Box OS level

Why would a shutdown script be needed over snap stop nextcloud?

(Also adding to the anecdotal list of people using it on a VPS. :P)

As the Nextcloud Box is no longer a thing, I'm going to go ahead and close this.

Was this page helpful?
0 / 5 - 0 ratings