iswrong

Members
  • Content Count

    160
  • Joined

  • Last visited

  • Days Won

    6

About iswrong

  • Rank
    Advanced Member

Recent Profile Visitors

886 profile views
  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