search

owncloud-archive / ubuntu-snap

1 stars 0 forks source link

ownCloud installation is unusable for many user types #1

Closed oparoz closed 8 years ago

oparoz commented 8 years ago

Developers, bug reporters, power user will need to be able to modify some files, but more importantly, they need to be able to use the occ command.

Currently, the ownCloud installation is split in 2:

  1. All ownCloud files are in a read-only folder: /writable/system-data/snaps/owncloud.canonical/8.2.2ubuntu3/htdocs
  2. data, config and apps are in /var/lib/snaps/owncloud.canonical/8.2.2ubuntu3/owncloud

This split doesn't work. Any reason for doing it this way? How easy is it to fix?

@kyrofa @jospoortvliet @enoch85 @ezraholm50

kyrofa commented 8 years ago

occ is made available in the OC9 snap (to be published soon).

Regarding the read-only stuff, it's how Snappy works. Each .snap is a squashfs-based package, which means it's read-only. Thus the writable stuff (data, config, apps) must be placed in an area that is actually writeable.

oparoz commented 8 years ago

Good news about occ :)

What are the risks in copying everything to the writeable partition?

  1. Snappy backs up "www" folder. data is located elsewhere
  2. "www" folder is emptied
  3. Upgrade is performed
  4. New files are placed in "www"

If a rollback needs to be performed, the backup can be used and if not found files from the older version of the snap are copied.

Also, any chance of having a symlink between /var/www/ownCloud and /writable/system-data/snaps/owncloud.canonical/8.2.2ubuntu3/htdocs. The reason being that a lot of documentation mention that path and that would be easy for users to find.

kyrofa commented 8 years ago

What are the risks in copying everything to the writeable partition?

I'll have to give that some more careful thought, but first of all, it makes the upgrade process a lot more painful. With a read-only application you can safely make certain assumptions about the state it's in (i.e. exactly the way I made it when I packaged it), but as soon as it's opened that's no longer the case. Note also that upgrades are automatic-- this is an important part of the user story here, so we want to make sure we get the upgrades right.

Also, any chance of having a symlink between /var/www/ownCloud and /writable/system-data/snaps/owncloud.canonical/8.2.2ubuntu3/htdocs. The reason being that a lot of documentation mention that path and that would be easy for users to find.

I'm afraid not-- snaps are very confined, and can't write into /var/www/. There are three important directories in Snappy Ubuntu Core:

These are the only three places that relate to a snap in question. Note there are only two writeable areas.

oparoz commented 8 years ago

Thanks for that.

I'll have to give that some more careful thought, but first of all, it makes the upgrade process a lot more painful. With a read-only application you can safely make certain assumptions about the state it's in (i.e. exactly the way I made it when I packaged it), but as soon as it's opened that's no longer the case. Note also that upgrades are automatic-- this is an important part of the user story here, so we want to make sure we get the upgrades right.

I agree that this requires careful consideration. My main issue is that people wanting to make improvements to the image need to be able to test various scenarios, patches, etc. live. We could have a developer image, but the automatic upgrade part would make it a risky setup as everything could be lost at any time. Since everything is containerized, we can't set up a separate virtualhost pointing to a git install either.

I imagine other snaps have the same sort of requirements.

kyrofa commented 8 years ago

My main issue is that people wanting to make improvements to the image need to be able to test various scenarios, patches, etc. live.

I typically use overlayfs for this, though it's something we're trying to do a little more seamlessly in Ubuntu Core as well. I'd be happy to write up a guide on the overlayfs stuff if you like.

Since everything is containerized, we can't set up a separate virtualhost pointing to a git install either.

Not containerized (no virtual stuff here!), just confined :smile: . But you're right, the same features that make it a great deployment strategy make it difficult to hack on sometimes.

oparoz commented 8 years ago

I typically use overlayfs for this, though it's something we're trying to do a little more seamlessly in Ubuntu Core as well. I'd be happy to write up a guide on the overlayfs stuff if you like.

That'd be great, thanks. Maybe post it on the pi-image wiki?

Not containerized (no virtual stuff here!), just confined :smile:

Oops, I have to more carefully choose my words :)

oparoz commented 8 years ago

Closing as this can be resolved via https://github.com/kyrofa/owncloud-snap/issues/41 This will never be a test instance of ownCloud, developers need to use the available VMs.