3 ms·

Hmm...I have a Linux server out there, serving web pages and also running a Dropbox CLI client. My laptop runs the usual Dropbox client. The two computers share

Hmm...I have a Linux server out there, serving web pages and also running a Dropbox CLI client. My laptop runs the usual Dropbox client. The two computers share a folder between them; this shared folder is also the web root for a site on the server. So, any changes I make at my local computer are synced to the server via Dropbox. No logins (beyond the initial set-up), no manual uploading; just save the files locally and they automagically appear on the server. Is that what you had in mind? (this is the link for the command-line client: https://www.dropbox.com/install?os=lnx https://www.dropbox.com/install?os=lnx )

elisk 15y ago
Yes. That's the basic idea that lead me to the above post, but from what I hear (no benchmarks or test though) the dropbox cli is too expensive on the resources. And even if that's a non-issue, what I'm talking about is a bit more robust solution - providing the user with some basic tools (like doing markdown/haml pages) right off the bat without any additional hacking. On top of that, installing dropbox-cli as simple as it might be, is not simple enough and requires access to the shell (that not everyone might have), running a daemon, and it's not super secure (you need to store your root password, no?). My idea is that whenever you install a drophost, you get a new folder in your dropbox with the name of your host (i.e. /dropbox/drophost/mydomain.com/) which is simple to navigate and maintain multiple sites.
- Piskvorrr 15y ago
  Hmm...the host in question is a tiny VM, and the resource usage by dropboxd is negligible (<10 MB of memory, CPU usage ~0.00, in my case); if you don't believe in hearsay, try it out for yourself ;) The daemon runs completely user-side - there's no need to do anything as root, let alone store passwords (you do need to store the Dropbox auth token, so that the daemon can re-login into DB; this is more secure than storing passwords, and doesn't give you access from anywhere else). The daemon only requires shell access on install - after that, it's a completely hands-off solution. Still not sure how you'd imagine the integration - the markdown pages would be processed into HTML on the server?
Lazyshot 15y ago
We actually have this exact set-up for our wiki. Instead of mediawiki we just have a dropbox feeding into a in-house built markdown parser/compiler that generates our wiki.

elisk 15y ago

Yes. That's the basic idea that lead me to the above post, but from what I hear (no benchmarks or test though) the dropbox cli is too expensive on the resources. And even if that's a non-issue, what I'm talking about is a bit more robust solution - providing the user with some basic tools (like doing markdown/haml pages) right off the bat without any additional hacking. On top of that, installing dropbox-cli as simple as it might be, is not simple enough and requires access to the shell (that not everyone might have), running a daemon, and it's not super secure (you need to store your root password, no?). My idea is that whenever you install a drophost, you get a new folder in your dropbox with the name of your host (i.e. /dropbox/drophost/mydomain.com/) which is simple to navigate and maintain multiple sites.

Piskvorrr 15y ago
Hmm...the host in question is a tiny VM, and the resource usage by dropboxd is negligible (<10 MB of memory, CPU usage ~0.00, in my case); if you don't believe in hearsay, try it out for yourself ;) The daemon runs completely user-side - there's no need to do anything as root, let alone store passwords (you do need to store the Dropbox auth token, so that the daemon can re-login into DB; this is more secure than storing passwords, and doesn't give you access from anywhere else). The daemon only requires shell access on install - after that, it's a completely hands-off solution. Still not sure how you'd imagine the integration - the markdown pages would be processed into HTML on the server?

Lazyshot 15y ago

We actually have this exact set-up for our wiki. Instead of mediawiki we just have a dropbox feeding into a in-house built markdown parser/compiler that generates our wiki.