Dropbox for R6 (x86 only)

I'm glad this is out there, and I have paid to retrieve it. However, it failed to install with many package dependencies -- which was odd to me since the older R4 add-on never needed any. What's the best place to follow-up for support on this? I tried posting to the forum on the web site there, but it didn't really look like it was in working order...

I guess you tried installing the add-on via the command line which is not how it is meant to be done by Netgear. I wish Netgear would have listened and had chosen a different file extension for add-ons/apps. Anyway, the recommended way to install *any* add-on is to use the "Upload" function in the upper right corner of the "Apps" tab. This will check for and install all needed dependencies as well.

-Stefan

That's interesting, since this would be first addon I've seen that resulted in other packages silently being installed. And, frankly, given the list of dependencies that failed, and my usual approach of installing as few addons as possible, this makes me extremely nervous. Had the list of dependencies been clearly listed in the description of the package I may well have decided against purchasing it. Beyond that, it's been my experience that the upload function fails at least 70% of the time -- including today, in fact, when I was upgrading transmissionr6.

All that aside, could you lay out what the expected dependencies are and why?

I suggest you hop onto your ReadyNAS using SSH, go to /var/log/readynasd and inspect the install_debpkg.log there. Afterwards we talk again about "silent install of other packages" ;)
Anyway: the dependencies are just for the web interface. Since some of the dependencies require some additional packages themselves, I can't give a complete list easily. But since all packages are downloaded from the official Debian repositories or the Netgear provided one, I don't think there's any security risk involved there. If you have a Linux box at hand you can get the list of additional packages that the add-on requires directly by using the "dpkg --info" command on the package. If you don't have a Linux box you can do the same in an ssh session on the ReadyNAS.
Speaking of the upload function I can only say that I try to make damn sure that it works for my add-ons/apps. And yes, that sometimes requires a bit or even a lot of tweaking - I complained about this a lot during the beta phase but all requests for changes and enhancements unfortunately went unheard.
As for the transmissionr6 problem: I'm quite sure you'll find some information about the failure in the log I pointed to in the beginning of this post.

-Stefan

Well, I got around the transmissionr6 issue by invoking dpkg manually. ;)

Anyway, I did just use the upload function to install Dropboxmanager and, well I guess you could say the results were mixed. It reports success. But now the web UI for the NAS is dead and the Dropbox service apparently failed to start...

START(/tmp/dropboxmanager_1.0.2_amd64.deb): Tue Apr 22 12:10:46 PDT 2014
Hit http://apt.readynas.com 6.1.7 Release.gpg
Hit http://mirrors.kernel.org wheezy Release.gpg
Hit http://apt.readynas.com 6.1.7 Release
Hit http://mirrors.kernel.org wheezy Release
Hit http://mirrors.kernel.org wheezy/main amd64 Packages
Hit http://apt.readynas.com 6.1.7/updates amd64 Packages
Hit http://apt.readynas.com 6.1.7/apps amd64 Packages
Hit http://apt.readynas.com 6.1.7/main amd64 Packages
Reading package lists...
 new debian package, version 2.0.
 size 106182 bytes: control archive=2637 bytes.
      55 bytes,     2 lines      conffiles            
     517 bytes,    13 lines      control              
    3313 bytes,    41 lines      md5sums              
     478 bytes,    18 lines   *  postinst             #!/bin/bash
     169 bytes,     7 lines   *  postrm               #!/bin/sh
    1361 bytes,    61 lines   *  preinst              #!/bin/bash
     183 bytes,     7 lines   *  prerm                #!/bin/sh
 Package: dropboxmanager
 Version: 1.0.2
 Architecture: amd64
 Maintainer: ReadyNAS Xtras <xtras@readynasxtras.com>
 Installed-Size: 388
 Depends: libapache2-mod-wsgi, sudo, python-django, python-feedparser, python-sqlite, python2.7, wget
 Depends: libapache2-mod-wsgi, sudo, python-django, python-feedparser, python-sqlite, python2.7, wget
Found 7 dependants
pkg[1/7]= libapache2-mod-wsgi
pkg[2/7]= sudo
pkg[3/7]= python-django
pkg[4/7]= python-feedparser
pkg[5/7]= python-sqlite
pkg[6/7]= python2.7
pkg[7/7]= wget
Chking dependencies..
pkg[1/7]= libapache2-mod-wsgi
Depenency  libapache2-mod-wsgi met
pkg[2/7]= sudo
Depenency  sudo met
pkg[3/7]= python-django
Depenency  python-django met
pkg[4/7]= python-feedparser
Depenency  python-feedparser met
pkg[5/7]= python-sqlite
Depenency  python-sqlite met
pkg[6/7]= python2.7
Depenency  python2.7 met
pkg[7/7]= wget
Depenency  wget met
 Section: misc
 Priority: optional
 Description: Dropbox Manager for ReadyNAS OS 6
  The Dropbox Manager will install the latest binaries
  of the Dropbox daemon on x86 based ReadyNAS systems. It
  also includes a Django based web interface for managing
  user accounts and daemon settings.
fv-dpkginstall.awk: success
Success install dependencies for /tmp/dropboxmanager_1.0.2_amd64.deb
Selecting previously unselected package dropboxmanager.
(Reading database ... 35872 files and directories currently installed.)
Unpacking dropboxmanager (from .../dropboxmanager_1.0.2_amd64.deb) ...
Setting up dropboxmanager (1.0.2) ...
insserv: warning: script 'automatic' missing LSB tags and overrides
No DropBox users defined!
invoke-rc.d: initscript dropboxmanager, action "start" failed.
dpkg: error processing dropboxmanager (--install):
 subprocess installed post-installation script returned error exit status 1
Errors were encountered while processing:
 dropboxmanager
DONE(0): Tue Apr 22 12:11:08 PDT 2014
spooler returns spool_status=0 outbuf=(null) errbuf=(null) is_localapp=1 name=dropboxmanager_1.0.2_amd64.deb pkgname=dropboxmanager

dropbox init script seems to keep failing to start since there are no users. Set's "admin" in script but gets reset due to /etc/default/dropbox. I added a username in there, forced a remote reboot and things are happier now.

Well, there were for a while anyway... the process spawned for my user died (in defunct state). The admin page shows "start", suggesting it knows it died. Starting it doesn't seem to help. Have gone poking around for a log in /apps/dropboxmanager, /data/Dropbox, /var/log/..., but so far can't seem to locate one... clues?

btaroli wrote:
Well, I got around the transmissionr6 issue by invoking dpkg manually. ;)

But only because you already ran it through the upload function for there are some additional things that are done there which won't be done by "dpkg" alone. If you don't believe me, just try with an add-on/app you never had installed on the NAS before.

btaroli wrote:
Anyway, I did just use the upload function to install Dropboxmanager and, well I guess you could say the results were mixed. It reports success. But now the web UI for the NAS is dead and the Dropbox service apparently failed to start...

The service "failing to start" is intentional. After a fresh installation, what would you think should be the user accounts Dropbox is automatically enabled for? In my opinion the answer is "None", since it is up to the user (or the admin of the NAS) to define what Dropbox should do for whom. So instead of force-adding a user to the config file in /etc/default, you could have achieved the same by simply starting Dropbox for that particular user using the Dropbox Manager web interface.
The web interface of the NAS itself being broken after installing Dropbox Manager is something I never encountered in the numerous tests I ran on different systems. So I'd be very interested in your findings there and how you fixed those.

btaroli wrote:
dropbox init script seems to keep failing to start since there are no users. Set's "admin" in script but gets reset due to /etc/default/dropbox. I added a username in there, forced a remote reboot and things are happier now.

As said above, this behavior is intentional. As long as the admin of the NAS hasn't defined any users (by clicking the start button for said user) why *should* Dropbox start? By forcing a user in there you also prevented Dropbox Manager from "securing" the users home dir against a "local" installation of Dropbox in the users home dir. Which is what most likely happened on your ReadyNAS and probably led to:

btaroli wrote:
Well, there were for a while anyway... the process spawned for my user died (in defunct state). The admin page shows "start", suggesting it knows it died. Starting it doesn't seem to help. Have gone poking around for a log in /apps/dropboxmanager, /data/Dropbox, /var/log/..., but so far can't seem to locate one... clues?

Try the "Restart All" button, this should also fix the issue you created by manually adding a user name to the config file in /etc/default. As you already noticed, there aren't any logs for the Dropbox daemon doesn't write any. It just writes information to a socket and expects interested applications to pick it up from there. Another reason for any process dying is that you left it running without linking it to any Dropbox account. This is a bug of the Dropbox daemon and nothing Dropbox Manager can fix.

-Stefan

I'll try the restart all, but I'm not holding my breath. And yes the very first thing I did was link it to an account once I started the daemon for one of my users. It was in the process of syncing files. The NAS was also recognized as a trusted device.

Well, restart all wasn't helping. So I figured I'd start fresh, since previously I had no guide for what to expect when starting this thing. So I yanked out all Dropbox references from my user home dir, returned /etc/default/dropbox to it's virgin null status, and rebooted the NAS (no amount of killing was going to get rid of the original zombie/defunct process).

After startup I accessed the settings page and see:



I should point out that trying to apply either the newer stable or testing builds results in an error. No logging on that either?



Having cleared the config, starting the daemon for my user required linking again. No biggie. Once done the display changed to what I had previously seen. First it retrieved the file list and then began counting down as it syncs.

I've just checked again and it says retrieving file list again. Odd but I'll check it again in a few mins before posting this.

I'd love to see this working. Just not sure what to expect, and it's not clear whether I'm not following the non-existent manual or if there are actual problems.

Checked again and the page still says downloading list. Checked processes and the daemon's still running but appears idle. Maybe this is normal then? I guess I'll learn shortly...