Infrastructure

Florian Effenberger: Any reason for this one to be private? Esp. since the much more detailed 524 is public and links here?

Not really, no idea why I marked it private in first place...

Out of interest, why was this on your pile Florian, rather than on Alex's ? and why is it now a low priority ? from my POV that sucks rocks. Surely Alex can do the evaluation, and then train you in how to use it: get this - it is awesomely difficult - you just save your document on your file-system: just like dropbox ;-)

Please re-consider.

It was on my pile as I have to heavily rely on WebDAV on a daily basis
and there are quite a few dependencies - any disruption or change here
heavily affects my workflow, so I should be be involved to not run into
unpleasant surprises. Not necessarily doing the setup, but being involved.

My latest information is that it's not as trivial, and Björn raised a
couple of questions in #524 - the "read-only WebDAV" in milestone 2 is a
bit confusing to me, also the linking to gerrit in milestone 1, both of
which is different from what I understood in first place.

Asked quite a few times for feedback to no avail, thus de-prioritized it
for the moment.

Proposal: Quickly talk through it during the next board call I attend (2
weeks), and if considered important, advice on which of my tasks should
be de-prioritized for that to raise priority here.

Florian Effenberger: IIRC we decided long ago, gerrit is not an option for hosting the WebDAV stuff (that was your opinion and I am fine with that). So we need to host the git repo standalone, which isnt a big thing anyway.

As for the "WebDAV is read-only" in milestone 2, yes that would mean Floeff needs to install and use Sparkleshare to push his changes. That should be a trivial change, but need Floeff to be prepare for on switchover day.

Briefly chatted with Michael, we should talk about it during the next
board call I'm there (if we can't manage before)

I recall that it was mentioned I can continue using as I do now,
Sparkleshare could do all the magic without me needing to use a client,
it is all trivial, so I don't have to change my tooling - so if that
isn't true anymore, it indeed needs some of my time factored in to
change my local tooling

I'm a bit confused now indeed ;-)
Let's defer to the phone, I'll add it to the agenda

Björn:

What I need your help with is migrating my rsync script I need for tax advise, which roughly looks like that:

rsync --include '2014*' --exclude '*' -azv /local_repoy/ /taxadvise_repo/

I also need to purge older data for a couple of reasons out of their repository, doing that like

MONTH=$(date +%m|sed 's/^0*//') ; let UPTOMONTH=MONTH-2 ; for ((i=1; i<=$UPTOMONTH; i++)) ; do find /taxadvise_repo/ -name *2014-$i* -exec rm {} \; ; done

Besides the fact that I'm obviously no coder :-) - any advice welcome on how to achieve that with SparkleShare.
In other words: I need to delete existing content from their fileshare, and only sync filenames with the last two, three months in the file name to it, while the main share has all the files.

Note the tax advise can most likely not install a client, but needs to use a web browser with HTTPS.

Florian Effenberger wrote:

What I need your help with is migrating my rsync script I need for tax advise, which roughly looks like that:

Sparkleshare (or git) should give you a local copy of the repo anyway.

I also need to purge older data for a couple of reasons out of their repository, doing that like

As you will have a local copy, running the script locally and then pushing the change to the repo (Sparkleshare gives you a nice UI for the latter).

Note the tax advise can most likely not install a client, but needs to use a web browser with HTTPS.

Thats not a problem as they only need to read, not write.

This is way obsolete - I guess we should move to the internal Next/ownCloud instead - and store/share everything there =)

Guilhem Moulin: We discussed this topic along some other items. Do you have insight into the Nextcloud encryption? Can sensitive documents be encrypted on a user-basis (i.e. it is encrypted towards user A, B, C, D's key, but not E, F, G, H, I's?). Are multiple users possible, i.e. if user B loses his password or is not available anymore, A, C, and D still have access, while E-I still don't?

Florian Effenberger wrote:

Guilhem Moulin: We discussed this topic along some other items. Do you have insight into the Nextcloud encryption? Can sensitive documents be encrypted on a user-basis (i.e. it is encrypted towards user A, B, C, D's key, but not E, F, G, H, I's?). Are multiple users possible, i.e. if user B loses his password or is not available anymore, A, C, and D still have access, while E-I still don't?

I have no idea, sorry :-/

Can you find that out/test it? ;-)
There must be some documentation around that, otherwise you can run a
test with some team members maybe?

Guilhem Moulin: Do you have insight into the Nextcloud encryption?
Can sensitive documents be encrypted on a user-basis (i.e. it is encrypted
towards user A, B, C, D's key, but not E, F, G, H, I's?).

Yes.

Are multiple users possible, i.e. if user B loses his password or is
not available anymore, A, C, and D still have access, while E-I still don't?

Yes.

This is for the server-side encryption - the benefit of which is that the data is encrypted at-rest, although I guess when it is synched down to users it is expected that it is sucked onto an encrypted partition.

It works by having a new AES key per document (IIRC) - and then sharing that key by encrypting it with the relevant users' public keys that can see it (IIRC).

Some problems occur - of course, key-loss is tough-luck - but also if you don't encrypt files to start with then you need to re-share them with people - so I think you want to turn that feature on quite early - but I forget =)