Uploaded image for project: 'Data Management'
  1. Data Management
  2. DM-16695

Select a WebDAV package for the User File Workspace

    Details

    • Type: Story
    • Status: Done
    • Resolution: Done
    • Fix Version/s: None
    • Component/s: None
    • Labels:
      None
    • Sprint:
      Arch 2018-12-03, Arch 2018-12-10
    • Team:
      Architecture

      Attachments

        Issue Links

          Activity

          Hide
          bvan Brian Van Klaveren added a comment -

          Some updates on the WebDAV/VOSpace:

          Initially it's working. You can log in with chrome, get a listing, download a file, etc...

          Limitations -

          • It's broke with Native OS X WebDAV.
          • Only one mountpoint can be made to work right now, and only at root right now, this seems to be a limitation of the webdav-ext for nginx. There's likely workarounds for this, however.

          Features

          • Added code to set cookies if authentication was `Basic`. This makes Chrome Happy it seems. This is probably NOT the behavior we generally want out of the service.
          Show
          bvan Brian Van Klaveren added a comment - Some updates on the WebDAV/VOSpace: Initially it's working. You can log in with chrome, get a listing, download a file, etc... Limitations - It's broke with Native OS X WebDAV. `mount_webdav` only works with usernames/passwords up to 255 characters See https://opensource.apple.com/source/webdavfs/webdavfs-112.1/mount.tproj/webdavd.h.auto.html `mount_webdav` seems to work best with Digest, though it may work fine with HTTP Basic iff you have HTTPS on, and again, if the user/pass are under 255 characters. Only one mountpoint can be made to work right now, and only at root right now, this seems to be a limitation of the webdav-ext for nginx. There's likely workarounds for this, however. Features Added code to set cookies if authentication was `Basic`. This makes Chrome Happy it seems. This is probably NOT the behavior we generally want out of the service.
          Hide
          bvan Brian Van Klaveren added a comment -
          Show
          bvan Brian Van Klaveren added a comment - Bug filed with Apple: https://bugreport.apple.com/web/?problemID=46627897
          Hide
          bvan Brian Van Klaveren added a comment -

          Some additional notes for the future:

          • This may need either containers to be configured appropriately so that users/group (netgroups) is available inside a container in order for the sudo test to work properly, or, we will need to just run this on a VM. In both cases, it's preferred the sudoers file be modified so that the service account in the container/VM can execute the command sudo -u test [user] [-r|-w] filepath
          • Files may be created with the user owner as that of the uid which nginx is running as. I'm not sure how to override this with nginx and/or apache. I think the setgid bit on a directory that you are writing to will help with setting the owning group, though. Should this happen, it'd probably be preferable we had something like an lsst_workspace_system account that represented the webdav service account. If this is unsurmountable, something like find /workspace/[user] -user lsst_workspace_system -exec 'chown user...' might help fix that, if executed by an admin
          Show
          bvan Brian Van Klaveren added a comment - Some additional notes for the future: This may need either containers to be configured appropriately so that users/group (netgroups) is available inside a container in order for the sudo test to work properly, or, we will need to just run this on a VM. In both cases, it's preferred the sudoers file be modified so that the service account in the container/VM can execute the command sudo -u test [user] [-r|-w] filepath Files may be created with the user owner as that of the uid which nginx is running as. I'm not sure how to override this with nginx and/or apache. I think the setgid bit on a directory that you are writing to will help with setting the owning group, though. Should this happen, it'd probably be preferable we had something like an lsst_workspace_system account that represented the webdav service account. If this is unsurmountable, something like find /workspace/ [user] -user lsst_workspace_system -exec 'chown user...' might help fix that, if executed by an admin
          Hide
          bvan Brian Van Klaveren added a comment -

          The plan of record is to use nginx plus a custom auth_request directive for the WebDAV location in nginx. This is portable to kubernetes nginx ingress as well.

          Show
          bvan Brian Van Klaveren added a comment - The plan of record is to use nginx plus a custom auth_request directive for the WebDAV location in nginx. This is portable to kubernetes nginx ingress as well.

            People

            • Assignee:
              bvan Brian Van Klaveren
              Reporter:
              ktl Kian-Tat Lim
              Watchers:
              Brian Van Klaveren, Gregory Dubois-Felsmann, Kian-Tat Lim
            • Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Summary Panel