Digital Ocean Single click installer never completes

[danmackinlay]

Not to complain, but I'll post this here so I can know if it is just me, or if this is a known thing.

Is the digital ocean single click installer currently working? For me it never completes. Is there a debug process that need to be in the documentation for the installer never completing?

For me, the progress bar gets some small proportion of the way along the screen then stops (forever, as far as I know, but certainly at least 3 hours)

Screenshots attached (not anonymised since I've already destroyed all the droplets in question)

In the console nothing is happening special at that point

DO resource meter shows a lot of activity for a while, then none for an hour or two. Then I destroy the droplet.

This behaviour is reproducible across frankfurt-3 and singapore-1 sites, and from firefox and Brave browers, and virtual instances at 1 and 2gb sizes. Before I dive into trying to understand DO's droplet thingy I would like to know if I should be expecting this behaviour or not. Or does the instance take days or weeks to spin up?

[staltz]

This is not expected behavior. Thanks for reporting...

[danmackinlay]

Indeed,things also failwith the manual install option, at least on an OVH VM. That might be a different issue though; I'll open a new ticket for that when I get a chance. the tl;dr there is that there is a weird error raised at the room check stage:

# ./room check
{ message: 'no async:whoami',
  name: 'Error',
  stack:
   'Error: no async:whoami\n    at Object.localCall (/home/node/.npm-global/lib/node_modules/ssb-room/node_modules/muxrpc/local-api.js:29:13)\n    at Object.<anonymous> (/home/node/.npm-global/lib/node_modules/ssb-room/node_modules/muxrpc/local-api.js:37:22)\n    at Object.request (/home/node/.npm-global/lib/node_modules/ssb-room/node_modules/muxrpc/stream.js:48:17)\n    at PacketStream._onrequest (/home/node/.npm-global/lib/node_modules/ssb-room/node_modules/packet-stream/index.js:161:17)\n    at PacketStream.write (/home/node/.npm-global/lib/node_modules/ssb-room/node_modules/packet-stream/index.js:134:41)\n    at /home/node/.npm-global/lib/node_modules/ssb-room/node_modules/muxrpc/pull-weird.js:56:15\n    at /home/node/.npm-global/lib/node_modules/ssb-room/node_modules/pull-stream/sinks/drain.js:24:37\n    at /home/node/.npm-global/lib/node_modules/ssb-room/node_modules/pull-goodbye/node_modules/pull-stream/throughs/filter.js:17:11\n    at Object.cb (/home/node/.npm-global/lib/node_modules/ssb-room/node_modules/packet-stream-codec/index.js:111:11)\n    at drain (/home/node/.npm-global/lib/node_modules/ssb-room/node_modules/pull-reader/index.js:39:14)' }

[staltz]

Could this issue be due to DockerHub's rate limiting of image downloads from anonymous users? It was enabled on November 2, could possibly explain the time coincidence with this issue.

[danmackinlay]

Hmm, what is behind that progress bar? I can shell into the new DO image and get a debug log.

In the mean time I tried an alternative provider, OVH and also failed, at #19

[danmackinlay]

I'm not even clear where the script for the DO one-click installer lives, or really what a "droplet" is. Is it a VM host for containers? Is it a container? Does it have a root password? because ssh does not seem to get me in despite uploading a perfectly good SSH key to digital ocean.

So many questions.

Anyway, I used the DO reset-password option and then shelled in to the droplet. We seemed to have pulled the container but then fallen over, which I suppose is evidence against the rate-limiting hypothesis:

[danmackinlay]

I created a new droplet as per the instructions in install-manual.md and still got a nearly identical error to the OVH error, #19

# ./room check
{ message: 'no async:whoami',
  name: 'Error',
  stack:
   'Error: no async:whoami\n    at Object.localCall (/home/node/.npm-global/lib/node_modules/ssb-room/node_modules/muxrpc/local-api.js:29:13)\n    at Object.<anonymous> (/home/node/.npm-global/lib/node_modules/ssb-room/node_modules/muxrpc/local-api.js:37:22)\n    at Object.request (/home/node/.npm-global/lib/node_modules/ssb-room/node_modules/muxrpc/stream.js:48:17)\n    at PacketStream._onrequest (/home/node/.npm-global/lib/node_modules/ssb-room/node_modules/packet-stream/index.js:161:17)\n    at PacketStream.write (/home/node/.npm-global/lib/node_modules/ssb-room/node_modules/packet-stream/index.js:134:41)\n    at /home/node/.npm-global/lib/node_modules/ssb-room/node_modules/muxrpc/pull-weird.js:56:15\n    at /home/node/.npm-global/lib/node_modules/ssb-room/node_modules/pull-stream/sinks/drain.js:24:37\n    at /home/node/.npm-global/lib/node_modules/ssb-room/node_modules/pull-goodbye/node_modules/pull-stream/throughs/filter.js:17:11\n    at Object.cb (/home/node/.npm-global/lib/node_modules/ssb-room/node_modules/packet-stream-codec/index.js:111:11)\n    at drain (/home/node/.npm-global/lib/node_modules/ssb-room/node_modules/pull-reader/index.js:39:14)' }

[danmackinlay]

This is probably the same as #21 where the reporter notes that the app still seems to work despite the error

[OrvilleRed]

I get the same problem creating a droplet on New York-3. Runs for a Really Long Time then appears to die. Two separate Drops. Destroyed the first and made a new one; same failure.

I already have a Pub set up, I was hoping to just start up another daemon "ssb-room" like ssb-server but listening on its own port and running under a different user account with its own ~/.ssb

I appreciate that ssb-room has a bunch of different dependencies than ssb-server but for my use-case (and most other people that already have a Pub) it would probably be easier to install those dependencies and start a fresh new user account, than fiddle with containerization and manage a whole new droplet. Of course, when one-click is working, it'll be the easiest way to go, and I appreciate the motivation to lower the barriers to entry.

[danmackinlay]

I don't really understand how this one-click installer functions but is the droplet installer possibly failing because the ./room check command will always return an error, as per #19 ?