On Tue, 22 May 2012, Christopher Tooley wrote:

> On 2012-05-19, at 4:09 AM, Dr Andrew C Aitchison wrote:
>
>> On Fri, 18 May 2012, Christopher Tooley wrote:
>>
>>> Dropbox works fantastically with Scientific Linux,
>>> and it's been around for a while now.
>>
>> Which SL and which DropBox implementation are you using ?
>
> [root@<computer> ~]# cat /<NotRootUserHomeDir>/.dropbox-dist/VERSION && echo "" && cat /etc/redhat-release
> 1.2.52
> Scientific Linux release 6.0 (Carbon)
>
> So, it's a slightly older version (OS and DB)
>
>> The packages I've tried either on SL5 didn't install
>> or run daemons as root - which I consider totally unacceptable
>> on a multi-user system.
>
> I assume you've tried these instructions?
> https://www.dropbox.com/install?os=lnx
>
> Maybe they've changed since the last time? Dropbox is pretty active with their development.

Hmm.

From rpmqv -p --scripts /home/install/nautilus-dropbox-1.4.0-1.fedora.x86_64.rpm
postinstall scriptlet (using /bin/sh):
/sbin/ldconfig
/usr/bin/update-desktop-database &> /dev/null || :
/bin/touch --no-create /usr/share/icons/hicolor &>/dev/null || :

if [ $1 -gt 1 ] ; then
   # Old versions of the rpm delete the files in postun.  So just in case 
let's make a backup copy.  The backup copy will be restored in posttrans.
   ln -f /usr/lib64/nautilus/extensions-3.0/libnautilus-dropbox.so{,.bak}
   ln -f /usr/lib64/nautilus/extensions-2.0/libnautilus-dropbox.so{,.bak}
fi

for I in /home/*/.dropbox-dist;
do
   # require a minimum version of 1.0.0
   DROPBOX_VERSION="$I/VERSION"
   if test -e "$DROPBOX_VERSION"; then
     VERSION=`cat "$DROPBOX_VERSION"`

     case "$VERSION" in
       1.3.[0-7]|1.2.4[3-6]|0.*.*)
         # 1.3.0-1.3.7 had a bug that prevents auto-update.
         # 1.2.43-1.2.46 had a bug that prevents auto-update.
         # stop dropbox
         pkill -xf $I/dropbox > /dev/null 2>&1
         sleep 0.5
         rm -rf "$I"
     esac
   fi
done

...

So if I upgrade it on a hundred workstations each workstation
will look at fiddling inside each of my user's home directories.
That is really a run time issue, not install time.

It then goes on to import a gpg key and create two files in /etc 
/etc/yum.repos.d/dropbox.repo
/etc/default/dropbox-repo
without mentioning them in rpm -ql
- so it silently adds a new repo and makes the machine trust it.

It then goes on to use zenity to pop up a question about restarting
nautilus. Neither of which are things I'm comfortable about doing
as part of an unattended update.

I'm aware that unattended update scripts are not easy to write;
and it is great if the DropBox package is ready for single-user
machines.

However until I have time to test the package to destruction I'd
rather not install it on my hundred workstations and risk my users
losing data from systems that I don't control.

>> "Selective Sync" - which appears to be new since I looked at
>. DropBox - may be the answer, but there used to be a requirement
>> that you kept as much free disk space on your computer as your
>> DropBox account had. That is a major issue when the DropBox
>> default quota is larger than the default quota we give our users.
>
> Ah.  I am unsure if this requirement has changed.

-- 
Dr. Andrew C. Aitchison		Computer Officer, DPMMS, Cambridge
[log in to unmask]	http://www.dpmms.cam.ac.uk/~werdna