search

mnutt / davros

Personal file storage server
Apache License 2.0
297 stars 35 forks source link

A few fixes #111

Closed griff closed 4 years ago

griff commented 4 years ago

I have implemented fixes for #106 and #93 as well as a few small changes to get it building.

I haven't included the changes to .sandstorm/sandstorm-files.list since I wasn't sure what the policy was for that.

As a side note you should probably remove the references to bower install from README.md and other places since there is no longer a bower.json file in the project and so bower install does nothing.

This also makes some changes to .sandstorm/setup.sh and .sandstorm/build.sh so that you can go from clean clone of davros to a working environment with just:

vagrant-spk vm up
vagrant-spk dev
zenhack commented 4 years ago

Thanks for tackling this!

I tried this out, hit a couple problems:

** SANDSTORM SUPERVISOR: Starting up grain. Sandbox type: userns
internal/modules/cjs/loader.js:638
    throw err;
    ^

Error: Cannot find module 'jsDAV/lib/dav/plugins/locks'
    at Function.Module._resolveFilename (internal/modules/cjs/loader.js:636:15)
    at Module.cachePathsRequire [as require] (/opt/app/node_modules/cache-require-paths/index.js:34:25)
    at require (internal/modules/cjs/helpers.js:25:18)
    at Object.<anonymous> (/opt/app/server/dav/index.js:6:28)
    at Module._compile (internal/modules/cjs/loader.js:778:30)
    at Object.Module._extensions..js (internal/modules/cjs/loader.js:789:10)
    at Module.load (internal/modules/cjs/loader.js:653:32)
    at tryModuleLoad (internal/modules/cjs/loader.js:593:12)
    at Function.Module._load (internal/modules/cjs/loader.js:585:3)
    at Module.require (internal/modules/cjs/loader.js:692:17)
** HTTP-BRIDGE: App server exited with status code: 1
** SANDSTORM SUPERVISOR: App exited with status code: 1

Do grains reliably start up for you? Does it still work after nuking the VM and starting fresh?

griff commented 4 years ago

I have just nuked and upgraded as much of my setup as I could think of.

  1. I upgraded VirtualBox (now at 6.1.12)
  2. And Vagrant (now at 2.2.9)
  3. I deleted the debian/contrib-buster64 box vagrant box remove debian/contrib-buster64 and it is now at version 10.4.0.
  4. I made sure that my version of vagrant-spk was the latest master branch
  5. I deleted ~/.sandstorm since I don't have anything in the keyring
  6. I deleted my davros folder and cloned it from scratch
  7. I ran vagrant-spk vm up without any issue
  8. I ran vagrant-spk dev and it is working without any issue
ocdtrekkie commented 4 years ago

I am just popping in here to say I am excited to see someone working on patching up Davros (with ownCloud/Nextcloud client support no less!) and if you need anything, am here/watching.

Hopefully @mnutt will see this and can look at pushing a release for us.

ocdtrekkie commented 4 years ago

Oh, actually, some notes:

mnutt commented 4 years ago

This is great, thank you! I'll work this week to get it published!

zenhack commented 4 years ago

I seem not to have the first problem if I switch the box back to debian stretch, though I still hit the second problem. I suppose as long as @mnutt can get it packaged this is still great progress, and I wasn't able to get it to build before either (though at this point I don't remember why).

griff commented 4 years ago

@zenhack The problem I had with stretch is that from a completely blank clone I needed to compile the getPublicId binary in sandstorm-integration and that requires building some parts of sandstorm or capnproto and those failed when Clang was older than version 5 which was solved by going to buster. Have you checked that you have the latest version of the debian/contrib-buster64 box?

@ocdtrekkie I have committed sandstorm-files.list and made some slight modifications to the README.md

zenhack commented 4 years ago

Updating the vagrant box fixes the first issue. Looks like I had a dirty working directory which is why I didn't hit the build error for for getPublicId, but even after nuking everything, destroying the vm, etc. I'm still hitting the exception on startup.

zenhack commented 4 years ago

Are you guys developing on windows or macos by any chance? Inspecting my working tree I'm observing that I don't have a directory node_modules/jsDAV/lib/dav, but I do have node_modules/jsDAV/lib/DAV; I wonder if it's working for you because your shared directory is on a filesystem where filenames are case-insensitive, but failing for me because my local filesystem is case sensitive?

griff commented 4 years ago

@zenhack I am actually on MacOS and that could very much be the issue

griff commented 4 years ago

@zenhack I have pushed a commit with the case of the path fixed

zenhack commented 4 years ago

Progress; the grain no-longer dies, but now I get a 500 in the browser and this on the console:

** SANDSTORM SUPERVISOR: Starting up grain. Sandbox type: userns
Mounting webdav from data dir /var/davros/data
Storing temporary files in /var/davros/tmp
Davros started in 557ms, listening on port 8000
PROPFIND /remote.php/webdav/ 500 2.362 ms - 1022
TypeError: jsDAV_Handler is not a constructor
    at Server.exec (/opt/app/node_modules/jsDAV/lib/DAV/server.js:230:9)
    at Server.emit (events.js:198:13)
    at /opt/app/server/dav/index.js:48:14
    at Layer.handle [as handle_request] (/opt/app/node_modules/express/lib/router/layer.js:95:5)
    at trim_prefix (/opt/app/node_modules/express/lib/router/index.js:317:13)
    at /opt/app/node_modules/express/lib/router/index.js:284:7
    at Function.process_params (/opt/app/node_modules/express/lib/router/index.js:335:12)
    at next (/opt/app/node_modules/express/lib/router/index.js:275:10)
    at module.exports (/opt/app/server/sandstorm_permissions.js:39:16)
    at Layer.handle [as handle_request] (/opt/app/node_modules/express/lib/router/layer.js:95:5)
griff commented 4 years ago

@zenhack after pulling my hair over this for several hours I think I have found the problem and have added a fix that seems to work for me.

Whenever nodejs has a circular dependency require will return an empty object to break that circle. It was not a traditional circular dependency because it had something to do with load order and the problem would sometimes go away and then come back.

My fix is simply to require('jsDAV/lib/DAV/server') at the top of server/index.js since when jsDAV/lib/DAV/server.js is loaded first the problem isn't there. But it is just a guess and might not always fix the issue.

zenhack commented 4 years ago

Seems to work for me. Can confirm the upload button works as well.

Quoting Brian Olsen (2020-08-05 23:50:24)

[1]@zenhack after pulling my hair over this for several hours I think I have found the problem and have added a fix that seems to work for me.

Whenever nodejs has a circular dependency require will return an empty object to break that circle. It was not a traditional circular dependency because it had something to do with load order and the problem would sometimes go away and then come back.

My fix is simply to require('jsDAV/lib/DAV/server') at the top of server/index.js since when jsDAV/lib/DAV/server.js is loaded first the problem isn't there. But it is just a guess and might not always fix the issue.

-- You are receiving this because you were mentioned. Reply to this email directly, [2]view it on GitHub, or [3]unsubscribe.

Verweise

  1. https://github.com/zenhack
  2. https://github.com/mnutt/davros/pull/111#issuecomment-669667024
  3. https://github.com/notifications/unsubscribe-auth/AAGXYPT4WHEGCGRBZ5PHL4TR7ISABANCNFSM4PVDIEJA
mnutt commented 4 years ago

I've tested this and it seems to work well. I'll deploy a new sandstorm app within the next day or two.

mnutt commented 4 years ago

This is nearly working. I'm just having a problem running the packaged version that may be due to the debian upgrade:

*** Uncaught exception ***
sandstorm/sandstorm-http-bridge.c++:2878: failed: execvp(argvp[0], argvp): No such file or directory; argvp[0] = /opt/app/.sandstorm/launcher.sh
stack: 55694c 6142d3