iswrong

Members
  • Content Count

    160
  • Joined

  • Last visited

  • Days Won

    6

Everything posted by iswrong

  1. @kos13 thanks for the update! I think keeping Sync minimal and aiming to make it as reliable as possible are probably the best possible goals for something like Sync. I think the problem that people had, was that there were very few signs of life and were worried that Sync might soon go away. If things look that way, people will stop recommending Sync to others, prepare a migration path, etc. I think just having regular bugfix releases would go a long way of taking away concerns. I believe that Sync still has a much better and more user-friendly sharing model than the most frequently
  2. Awesome! Thanks for putting out a new release. The macOS menu bar finally works again 👍. Looks like there are many other useful fixes and additions.
  3. It's a relief to hear that @kos13, good luck with the changes!
  4. This is false. Staff like RomanZ used to be active on the forums. I am still sure that Resilio is fine, even if they had cashflow problems, the technology is pretty valuable, so it is likely that they could be acquired if needed. But I wouldn't be surprised if the consumer-level desktop client is deprioritized. The desktop client ha[sd] a hard-core following, but I bet that a large chunk has always used free sync. Over time, they have segmented their product offering and it is likely that they saw a large majority of income coming from large(r) business users. Of course, this is conj
  5. Another possibility is that they are refocusing on enterprise-only (Connect). At any rate, this topic is two weeks old, if they'd wanted to end the worries, they would have replied to this topic by now.
  6. I don't think it is a good security practice to give sync blanket group access (unless you want sync to backup the complete user account). On most Linux distributions, the primary group of a user is unique (e.g. a user 'john' would be in the group 'john'). If you use a modern filesystem, you could use access control lists to give sync access to specific folders. See 'man setfacl', something like the following should do the trick: setfacl -d -m user:rlsync:rwx somedir The '-d' flag makes the ACL a default ACL for the directory (so that the ACLs are inherited by files created in somedir).
  7. Did you try to connect to localhost:8888 or 127.0.0.1:8888 ? By the way, you don't need remote X to connect to the GUI, you can just use SSH port forwarding and use a local browser. E.g.: ssh -L 8888:localhost:8888 yoursever.tld This will forward port 8888 of the server yourserver.tld to port 8888 of your local machine. Then you can just browse to localhost:8888 on your local browser.
  8. There is no proxy. Only a tracker that is used by peers to announce what folders they have. From that point on, communication is end-to-end. A relay server is used if end-to-end communication is not possible. It used to be the case that RLSync could also operate without Resilio's trackers by using the DHT, but the use_dht option was removed at some point.
  9. When using standard folders, RLSync derives a folder identifier from the secret key (this is completely safe due to how cryptographically-secure hash functions work). Your peers announce the availability of the folder using Resilio's trackers and/or DHT (IIRC DHT support has been removed some time ago). Your peers find each other through the tracker and communicate directly end-to-end (if possible). If there is some NAT + firewall between the devices such that an end-to-end connection is not possible, RLSync will use Resilio's relay servers. Both devices will connect to the relay server and co
  10. Is there are difference? The size of the unencrypted and encrypted data is approximately the same (plus padding, etc.). If you are asking whether encryption could be the bottleneck, then this could indeed be the case. There are two ways you can find this out: Check the CPU usage of Sync during transfer. Disable encryption on the LAN. This is controlled with the lan_encrypt_data option: https://help.resilio.com/hc/en-us/articles/207371636-Power-user-preferences I am not sure if Resilio Sync uses AES-NI. If it does, it is unlikely that encryption is the bottleneck on a moder
  11. Did you check CPU usage? Maybe the source machine is spending most of its time encrypting data? If that is the case, you can try to set the lan_encrypt_data option to false in the power user preferences.
  12. The encrypted folders work differently than you think. They give you an extra folder key. When this key is used on a RLSync instance, it becomes a peer for the folder, but this peer will not be able to decrypt the data. The typical usage scenario is when you want to use a VPS in the cloud to be a peer, but you cannot trust this VPS (e.g. because the cloud provider can seize and turn over the VPS, the VPS could be hacked, etc.). Using an encryption read-only key, the VPS can contribute bandwidth without being able to read the data. Even if you use an Encrypted folder, the folder is not enc
  13. I think Vince42 is referring to the web interface here and wants to use a Let's encrypt certificate rather than a self-signed certificate, which is completely reasonable IMO. Vince42: I assume that you are requesting the certificates while using Apache/nginx/... to do the validation? I think there are two reasonable approaches to do this without copying or changing ownership: Create an extra group, of which both your web server user and RLSync user are a member. Give the group read access to the certificate; or use filesystem ACLs to configure more fine-grained access rights (
  14. http://motherboard.vice.com/read/another-day-another-hack-user-accounts-for-bittorrents-forum-hacking
  15. Did you try Bittorrent Sync outside the chroot? Also, are you sure that the CPU has hardware floating point support (the Cortex-A9 has an optional FPU)? (You could try to run some other binaries in the chroot environment.)
  16. Resilio Sync does work over the internet. Does the information for the folder show any peers?
  17. I looked at the Mac client and the largest change is in ui.zip (the web UI). Within that file, it seems that some large images (GIFs) are added for a/the selective sync tutorial. They are animated GIFs that are shown when enabling selective sync and clicking on the question mark icon.
  18. Is this an artificial limitation (e.g. to avoid Sync being used for illegal file sharing) or a technical one? (Sync's relay servers or trackers wouldn't be able to handle the load.)
  19. But Dropbox is also not for backup ;). File synchronization is in general not fit for backups. Any 'damage' is propagated everywhere, old versions are removed after a while.
  20. Note that deleted files will only be archived on other peers. In general, you should use Sync (nor Dropbox) for file synchronization and not backups for many different reasons, including: You might find out about some file being deleted after 30 days. The archive is too crude to use for long time periods (every change creates a copy, rather than storing incremental copies). It's very hard to reconstruct a directory snapshot of a particular date from the archive. The archive does not store any extra metadata for validation (e.g. checksums). If your peers are all in
  21. Did you consider buying a somewhat beefy x86_64 box and using something like FreeNAS? (Or a Linux-based NAS distribution?) I think hardware-wise this is often a better trade-off than a real NAS and it gives longer support cycles. Of course, it may be a bit more work when it comes to administration.
  22. You can sync any directory, including directories on external disks. But this sounds like illegal distribution :(.
  23. Do you have selective sync enabled on the folder?