Ticket #735 (new enhancement)

Opened 14 years ago

Last modified 9 years ago

make a Dropbox installer

Reported by: geofft Owned by:
Priority: normal Milestone: The Distant Future
Component: -- Keywords: hackathon
Cc: Fixed in version:
Upstream bug:


This has absolutely nothing to do with Debathena other than people keep asking Athena support fora for it, so I figured we might as well have it in the Athena bug tracker and list the technical issues. There are two general approaches: one is to install it in a locker, and one is to modify the installer to work better on Athena and put that in a locker or on some website (which would restrict it to just being used on clusters or private workstations that you own).

From the technical side of things, there are three gotchas:

  1. Dropbox wants to put sockets in your homedir, which doesn't work too well in AFS; for now you can work around that by making a symlink from ~/.dropbox to $ATHENA_SESSION_TMPDIR/dropbox or something.
  2. The installer wants you to log out and log back in to install its Nautilus (file manager) hooks. You can bypass this by simply restarting Nautilus.
  3. Everything is very likely to get confused if multiple copies of Dropbox are running on multiple machines backed against the same (networked) directory, since Dropbox is basically a networked filesystem of its own. So you likely want some sort of mutexing here. See the Firefox wrapper for inspiration, although everyone tends to ignore the resulting dialog, and I'm worried that Dropbox corruption might have worse effects than Firefox profile corruption. So something that can detect stale locks would be useful (e.g., can you query the servers for active clients, and tell if any of those are running on Athena?).

It occurs to me that another option is just to have a dedicated Dropbox server that takes your Dropbox credentials and constantly runs a daemon against some subdirectory of your homedir that it has daemon.* bits on. This would avoid the multiple-client issues, and also keep your directories synced all the time so that e.g. if you put something in your local Dropbox checkout, it can show up in ~/www or ~/Public or ~/web_scripts immediately, even if you're not logged in to Athena. I'm not sure I like the burdens and security issues involved with running this service, though.

Anyway, this would be a great thing to do at a SIPB hackathon or something.

Change History

comment:1 Changed 14 years ago by xavid

I've poked at a dropbox locker a little (with the intention that people would run it in screen on Linerva). It shouldn't be that bad.

comment:2 Changed 14 years ago by geofft

One more question: will Dropbox preserve AFS permissions differing within subdirectories of your checkout, or will it ever delete and recreate the directory (and inherit the parent's permissions)? What about renames etc.?

comment:3 Changed 14 years ago by jdreed

I'm really concerned about the implications of offering some sort of service, particularly one which integrates with a commercial product we have ~no control over. (I mean, we have no control over TSM either, but we are a paying customer at least). Even an integrated, customized Dropbox client concerns me, but less so.

I'd much rather we:
a) document how to workaround the suck
b) put effort into fixing #248, even if that is Hard(tm), since it will fix a lot of other things

WRT a service, SIPB is of course free to do what it wants, but I'd like some sort of abstraction barrier so the user is aware of the implications of what they're doing. In particular, the latest comment about the possibility of dropbox changing AFS permissions out from under the user is a little concerning, since the impact of incorrect AFS permissions is a lot greater than the impact of incorrect UFS permissions.

comment:4 Changed 14 years ago by geofft

Certainly my biggest concern about dropbox.mit.edu or whatever is the support implications of running a server; at the very least it can't be Athena at all and has to be at most SIPB. Honestly my ideal solution here is "athrun sipb install-dropbox", so it's still SIPB and not Athena but also isn't a server.

I don't expect the AFS thing to be a huge problem in practice because I don't think I expect people to change permissions within their Dropbox checkout (it may just suffice to warn people if the root of their checkout is anyuser/authuser readable), but it is something worth being overcareful about.

I do like the idea of spending hackathon effort on fixing #248. But that doesn't solve anywhere close to all the UX issues here.

comment:5 follow-up: ↓ 6 Changed 14 years ago by xavid

I've got dropbox working on Athena (modulo the Nautilus stuff, not particularly wanting to test Nautilus cross-country), symlinking ~/.dropbox into /tmp/ and then symlinking back for the stuff that actually wants to persist. I'll probably put it somewhere other than my locker at some point. The other tricky bit is that dropbox wants to install the proprietary bit into ~/.dropbox-dist, but there's a 64-bit version of the proprietary stuff that obviously won't run on Linerva.

Incidentally, my random test running two copies of the daemon on different machines caused one of the daemons to restart when I made a change but didn't seem to explode. It would probably still be good to have a better answer there.

comment:6 in reply to: ↑ 5 Changed 14 years ago by jdreed

Replying to xavid:

The other tricky bit is that dropbox wants to install the proprietary bit into ~/.dropbox-dist, but there's a 64-bit version of the proprietary stuff that obviously won't run on Linerva.

I'd like to pre-emptively vote against playing stupid symlink games like we do with ~/.openoffice.org, or creating N different versions like we do with .gconf_debathena_foo.

I do like the idea of dropbox living in a locker, and users running some sort of setup script that say "Here be dragons"

comment:7 Changed 14 years ago by xavid

The ~/.dropbox-dist bit is in the "open" source part, so I should be able to fix that to get the proprietary stuff out of the locker. The ~/.dropbox symlink is probably necessary unless we use even worse hacks or get the Dropbox people to put in a patch. Or fix #248.

comment:8 Changed 14 years ago by xavid

There is now a dropbox locker. 'add dropbox; dropbox start' seems to work. It uses a ~/.dropbox symlink and flock. If your tokens run out, you need to do 'dropbox stop; dropbox start'. It's not well-tested. I haven't tested the Nautilus integration at all; not sure how to do that with a locker. Feedback welcome.

comment:9 Changed 12 years ago by mayneack

I don't really know anything about how one would go about doing this, but it would be helpful to upgrade this to the newer version of dropbox that supports selective sync so it doesn't use up all of your space when you start. Also, the new version has a nice CLI

comment:10 Changed 12 years ago by jweiss

If we're going to put effort into this, and I'm not convinced we should, I'll note that this application has several issues (in no particular order) that impact the dialups, that would be nice to resolve.

1) It seems to regularly leave a 17M file in /tmp, it should clean up after itself.
2) It's cache seems to grow without bound, and should have a know to limit total size.
3) It seems to sit in a fairly tight loop checking things and should default to a less aggressive setting.

I'm not sure which of these are practical (or may even already exist) but since I became aware of this ticket, I figured that I should at least document current known issues in it.

comment:11 Changed 9 years ago by andersk

For the record, in case someone is coming here from Google, the dropbox locker has bitrotted and no longer runs at all. IS&T recommends using the web interface:  http://kb.mit.edu/confluence/x/zQIrCQ

Note: See TracTickets for help on using tickets.