CentOS

Dropbox are dropping support in their Linux sync app for glibc < 2.19 effective October 15 (less than 2 months!), and will only support ext4 on Linux from November 7th.

What are other Dropbox users' plans to work around this? I currently have 950GB stored in Dropbox, with nightly backups from multiple Linux clients, on both C7 and C6. The ext4 is less of an issue than the glibc challenge...

Thoughts from the community?

RHEL6 here, but same boat...

It was suggested to me (by one of our server chaps) to try LD_PRELOAD, viz.

LD_PRELOAD=/path/to/my/newerglibc.[so?] /usr/bin/dropbox

(not quite right, but you see what I mean). That means finding a 2.19+ glibc rpm or building from source. No luck finding the RPM (thought there might be a centos one easily found, but not in a couple of minutes looking); building from source scares me too much today!

Does that sound possible? I've used LD_PRELOAD for simpler issues (where the binary I wanted to run would only look for an old version of some library), but am not confident it'll work for glibc, being a much more complex (I presume) library.

SpiderOak works on CentOS 7, not tried it on el6.

It all depends on how they actually check for the glibc version.
Here's something I used to preload for chrome, so I didn't have that "unsupported" bar Really hoping that Dropbox does it the same way

You can run Dropbox containerized in Docker, I've just changed a Centos 6 machine to work like this.

https://www.webscalability.com/blog/201 ... for-linux/

TrevorH wrote: ↑

2018/08/28 12:02:31

SpiderOak works on CentOS 7, not tried it on el6.

SpiderOak won't run on 6. I'm setting up a replacement 7 Samba / Bacula box (I needed to do it anyway) with SpiderOak, will see how that goes. They are all VMs so it's not a big difficulty. Dropbox will lose my money, not that they care.

OK, SpiderOak is slooooowwwww....

It does a full copy to the home directory of the user it is running as, then de-dupes it, tries to compress it (even though it already has been), and tries to upload in small chunks. I have a 90GB back-up file to do, and after about 8 hours it's done about 6GB (it spent about 4 hours doing all the pre-work) and is now running at about 4Mbps upload, i.e. about 10% of my max.

I'm running a Jottacloud upload at the same time to see which one finishes first...

There is another way, it might be not as easy and clean as the docker option but it's better to have some options around. This worked on a Centos 6.

I compiled glibc-2.27 at /opt/glibc-2.27/
and then as user:
you might need to yum install patchelf.

jamespo wrote: ↑

2018/08/30 09:53:50

You can run Dropbox containerized in Docker, I've just changed a Centos 6 machine to work like this.

https://www.webscalability.com/blog/201 ... for-linux/

Thank you! This helped me to install Dropbox on my Centos 7 system.

tacvbo wrote: ↑

2018/10/16 04:39:58

There is another way, it might be not as easy and clean as the docker option but it's better to have some options around. This worked on a Centos 6.

I compiled glibc-2.27 at /opt/glibc-2.27/

Code: Select all

# tar xzvf glibc-2.27.tar.gz
# cd glibc-2.27
# mkdir build
# cd build
#  ../configure --prefix=/opt/glibc-2.27
# make && make install 

and then as user:

Code: Select all

% patchelf --set-interpreter /opt/glibc-2.27/lib/ld-2.27.so  ~/.dropbox-dist/dropbox-lnx.x86_64-59.4.93/dropbox
% patchelf --set-rpath /opt/glibc-2.27/lib ~/.dropbox-dist/dropbox-lnx.x86_64-59.4.93/dropbox

you might need to yum install patchelf.

@tacvbo - You beat me to the patchelf solution. Though, I set the configure prefix to "/opt/dropbox/rt" on my dev server and installed the headless Dropbox client using SSH to prevent it from complaining about missing libraries needed to open a browser window (I wasn't able to find a flag to just display the URL token).

I probably could have just switched to a different tty session (e.g., Ctrl+Alt+F5), but I didn't think of it at the time.