Hello,
For using the owncloud client in professional context ("enterprise") the
absolute requirement is that things like this do not happen. I think that this
should be addressed in priority. The question is how we achieve it.
Recovering from backup should be really the last resort. To support 100s or
1000s of users we cannot ask them to follow a procedure on their side to
disable one sync client and alike. This is proven not to work. The client
update should be transparent and safe. We currently have users with different
client versions (some as old as 1.4.2). I currently have little confidence in
what will happen when they upgrade their clients. I will most likely have to
assist them one by one. From experience anything can happen (config file messed
up, complete redownload,…). This is not always the problem of the client only
(server has it's part in it too) but the net result is what matters.
The owncloud server has two versions (community = latest greatest, enterprise =
stable plus critical bugfixes, sometimes backported from community). Why don't
we have the same for the owncloud client? If we had, then I would be more
confident that an (automatic) update from 1.5.0 to 1.5.x will do no harm.
Because 1.5 has the "enterprise" stability. And because the owncloud devs would
not put any potentially dangerous changes in it. And we (people deploying
owncloud for their users) can control when we switch from 1.5 to 1.6 (or skip
1.6 and go to 1.7). Of course there should be a very clear meaning on
backwards compatibility in the numbering scheme. And very clear update paths
between major versions if needed.
Concretely, what about having isv:ownCloud:desktop-enterprise repository for
Linuxes and a separate download channel for Windows/Mac for client enterprise
version?
Additionally, if we can settle on a core which is guaranteed stable I am
willing to restrict the set of features to our users at the benefit of
stability and security (for example, only one sync folder pair to sync the
entire owncloud account). I think this should also be considered, until the
owncloud client has matured enough with all the offered features. I would
accept the "dangerous" features to be disabled in the enterprise.
Best regards,
kuba
--
I think that first of all the (owncloud) project must make sure that this is
much less likely to happen at all. I imagine us having soon several hundreds
users
On Feb 5, 2014, at 11:29 PM, Andrew Warren <[email protected]> wrote:
> Benjamin Schieder wrote:
>
>> I was able to restore the files from another machines sync directory,
>> but it was very scary nonetheless.
>
> Thank you for the warning, Benjamin.
>
> Reading the sentence I quoted above, it now seems obvious (although I had
> never thought to do this before) that when upgrading the sync client or the
> Owncloud server -- or making any large change to the synced directories -- it
> is probably a really good idea to temporarily disable syncing to one client
> in order to protect its synced directory from being corrupted if anything
> goes wrong.
>
> I mean... I have server snapshots taken every four hours, and my clients are
> backed up regularly, but the backup files are (intentionally) not easy to
> access, and they can of course be up to four hours old. And besides, a
> backup that occurs halfway through a sync or while a file is open might not
> be perfect anyway.
>
> For these reasons, I have in the past made a temporary copy of one client's
> synced directory just before upgrading the client or server. But lately, my
> synced directory is so large that finding disk space (and time) for a copy is
> difficult. Disabling the sync client on a machine that is already synced
> takes no time and no extra disk space, and it preserves an up-to-the-minute,
> internally consistent backup that can be easily copied back to the server if
> necessary.
>
> I haven't looked at the Owncloud documentation lately, but I assume that it
> says (maybe in multiple places) something like "It is recommended to have a
> recent backup whenever making a large change to your system". Perhaps it
> would be helpful to also suggest temporarily disabling one sync client.
>
> -Andrew
>
> === Andrew Warren - [email protected]
> === Synaptics, Inc - Santa Clara, CA
> _______________________________________________
> Owncloud mailing list
> [email protected]
> https://mail.kde.org/mailman/listinfo/owncloud
_______________________________________________
Owncloud mailing list
[email protected]
https://mail.kde.org/mailman/listinfo/owncloud
