separate reva services

[butonic]

fixes #6

• run reva as separate services
  • one service port, either http or grpc
  • one debug port for metrics
    • teach reva the endpoints we have or get the metrics from reva
• currently allows configuring ldap, demo and a json file as user backents
• introduce opinionated way of configuring an instance
• mkdir root storage namespaces until reva can render the root listing dynamically
  • documented ... too much of a hack to add this to eg the storage-root
• create PR against ocis to preconfigure this
• separate service flags
• check if basic auth works out of the box (it should)
• add desktop & mobile client ids for the oidc provider, tracked in add desktop & mobile client ids for the oidc provider #5
• update docs & readme

[butonic]

@refs the flags obviously explode but I am not sure if I can split the server.go in multiple files. I am currently using only a single debug configuraton ... hm but moving to multiple flagset files would make that easier as well ... I'll try that tomorrow.

[butonic]

to test

1. build ocis and run bin/ocis micro & bin/ocis phoenix
2. mkdir /var/tmp/reva/root/home && mkdir /var/tmp/reva/root/oc
3. build this pr and run

bin/ocis-reva gateway & \
bin/ocis-reva users & \
bin/ocis-reva auth-basic & \
bin/ocis-reva auth-bearer & \
bin/ocis-reva sharing & \
bin/ocis-reva storage-root & \
bin/ocis-reva storage-home & \
bin/ocis-reva storage-home-data & \
bin/ocis-reva storage-oc & \
bin/ocis-reva storage-oc-data

That should give you a working reva & phoenix

try using an ldap server using env vars: REVA_USERS_DRIVER=ldap REVA_LDAP_HOSTNAME=localhost REVA_LDAP_PORT=369 ... see bin/ocis-reva users --help | grep ldap for the related env vars, cli options should work as well.

[butonic]

basic auth works, checked

curl -X PROPFIND http://localhost:9140/remote.php/dav/files/ -u einstein:relativity -v
curl -X PROPFIND http://localhost:9140/remote.php/webdav/home/ -u einstein:relativity -v

[refs]

Ouch, was in the middle of a review when it got merged. I'll propose a way of dealing with reva config that is type safe and doesn't bloat this part of the codebase

[refs]

allows*

the user backend to LDAP and fully it on the cli -> the user backend to LDAP fully it on the cli