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
[email protected]   http://www.dpmms.cam.ac.uk/~werdna

Reply via email to