jdrch

Members
  • Content Count

    170
  • Joined

  • Last visited

  • Days Won

    2

Everything posted by jdrch

  1. @Andy+ Over the years of discussing things online I've found it's not particularly useful to question the basis of a decision a user makes for themselves. Whatever reasons @PacketMan has for switching, they work for him, and I think we should do him the courtesy of assuming he's thoroughly researched the topic and knows what's best for his use case.
  2. PSA: 2.7.2 has been released; it fixes the issue.
  3. Can confirm that 2.7.2 fixes the service installation bug from 2.7.1. Thanks and good job
  4. @1VDJ I must admit I find your wording confusing, but in my years of using Sync since 2013 the best way get going is to start with an empty destination folder on the target machine. Probably not the answer you want to hear, but it's the path that's least likely to result in issues.
  5. All my Windows installations are on Windows 10 Pro and Pro for Workstations.
  6. Hmmm, works just fine for me. Make sure there are no other Resilio Sync processes running when you install as a service.
  7. Just install the previous version (2.7.0) for now, it works just fine.
  8. Running into the same problem Ah, so it is a bug in Resilio.
  9. Hopefully soon; right now I can't install Sync to begin with on Windows 10 2004 due to it. UPDATE: The 2.7.0 installer doesn't have this problem. If you need to do a service installation, run that version for now and then wait for the 2.7.2 release to arrive.
  10. Ha, I just realized the message Connection settings overridden by config actually means This state of this setting is not controlled or indicated in the web UI. Using "listen" : "0.0.0.0:8888" does in fact enable the web UI's accessibility to other machines on the LAN, it's just that the web UI won't indicate that to you. I'm now able to access Sync on the Ubuntu 20.04 machine from other machines on the LAN via Ubuntu20.04.IP.Address:8888. Problem solved!
  11. I'm running the latest Resilio Sync Home Pro on Ubuntu 20.04. I'd like to be able to access the Web UI from any machine on my network. Currently the setting to disable listening only to 127.0.0.1 is grayed out (see attached image) with the message Connection settings overridden by config, as shown below: To find out which config file was being used, I opened System Monitor, filtered the Processes tab for rslsync, and then looked at the Command Line column. There I found / usr/bin/rslsync --config /etc/resilio-sync/config.json Opening /etc/resilio-sync/config.json reads: { "storage_path" : "/var/lib/resilio-sync/", "pid_file" : "/var/run/resilio-sync/sync.pid", "webui" : { "listen" : "127.0.0.1:8888" } } Question: How do I enable the listening only setting in the UI via editing the config.json file? Changing "listen" : "127.0.0.1:8888" to "listen" : "0.0.0.0:8888" has no effect on the web UI after I restart the Resilio Sync service using # service resilio-sync restart If I use "listen" : "0.0.0.0" instead and then restart the service, the web UI is no longer accessible at all. Any ideas?
  12. @papakpmartin FreeNAS most likely uses the FreeBSD repos upstream, and rslsync package is no longer available in those. You might be able to get it up and running manually using the binary available for direct download from the site. That's what I use on my FreeBSD 12.1 installation.
  13. It's still priced at 501 USD ... unless you're a business or rich that's not cheap for an OS.
  14. Fair enough. But you also have to accept what comes with that, too. Namely that enterprise products tend to beget enterprise prices by default unless you explicitly ask for an exception.
  15. They do hold. The official list prices are what they are. The fact that you may have gotten a new BMW for the price of a used econobox doesn't change the fact that the BMW is a luxury car. When you take it in for service or try to buy aftermarket stuff for it, you're gonna pay just as much as someone who bought it at full price. Windows Server is an enterprise product with the usual enterprise trappings whether you paid $12 or nearly $7000 for it. Anyway, as staff already pointed out, all you have to do to resolve the issue is contact them directly. I had to do the same myself with TeamViewer because I'm on their free tier but I have so many client instances they thought I was a business. Took a couple weeks but all is good now. That's an easy solution anyone can manage.
  16. Non-Windows OSes don't use SKUs per se, plus because pretty much everything that isn't Windows, AIX, or macOS is free my aforesaid assumption of being able to afford an enterprise license by virtue of already paying thousands of USD for an OS license doesn't apply for those other OSes. Personally, I run Sync Home Pro on Windows 10 Home & Pro, Android, Ubuntu, Debian, Raspbian, and FreeBSD without any issue. UPDATE: manually updated to 2.7.0 on my FreeBSD and Windows machines with no issue.
  17. Grandfathering sounds like a workable solution in theory. Not sure if Resilio has that kind of license server-side granularity, but it would be a useful path forward.
  18. What solution would you prefer? This is a common issue for just about all paid enterprise software: there's always some cutoff beyond which it's assumed you're running a business and can afford a business license. FTR, Windows Server pricing isn't inexpensive or free; so yes it is a reasonable assumption that anyone running WS can afford an enterprise level Sync license. And if you're not running a business, then you can get most of WS' non-domain functionality out of Pro, Pro for Workstations, or Enterprise. If you do need the domain functionality, then it is what it is. Neither Windows now Sync are free solutions; adjust your expectations accordingly.
  19. AFAIK FreeBSD repos contain open source packages only, but I could be wrong. I actually do use FreeBSD, which is why I wrote the post 😛 Resilio Sync works perfectly for me, but then again I don't use the Selective Sync feature.
  20. @PacketMan A couple things about that: There is no package available in the FreeBSD repos. To see for yourself, run pkg search rslsync on FreeBSD 12.1-RELEASE-p4. You'll get no results. The FreshPorts listing literally says there's no package available: You can't compile it yourself either because it's closed source so there's nothing to compile from Besides all of that, the most recent version in the FreeBSD repos is 2.6.3, which is a version behind the current stable release Now, there are some other FreeBSD-based distros such as GhostBSD that have rslsync in their repos, but I suspect that's because they also use the TrueOS repos, which are a superset of FreeBSD's. I would not suggest anyone use TrueOS' downstream repos on raw FreeBSD unless they want to run into package state/dependency problems.
  21. @Mr Fethersmith Yw! @Andy+ @Mr Fethersmith My apologies for the broad brushed statement. I guess I just don't have a use case for any of those right now. I'm glad they work for you
  22. Yw! Seafile is worse than Resilio Sync in every way IMO, but use what works best for you. Encrypted data is impossible to interpret without decryption. This means that all encrypted files must be decrypted before being read. With those 2 facts in mind, here's how full-disk encryption on computers works: The entire disk is encrypted, including the operating system (OS) At some point in the boot process, the bootloader (a small operating system that loads the requested OS into RAM and then hands off operation of the machine to it) realizes the disk the OS is on is encrypted, and requests the encryption key so it can start the OS The encryption key is provided in one of multiple ways depending on your config. We'll come back to this point later Now, this is the crucial part: the encryption key does not decrypt the entire disk at once. Rather, it decrypts data that is read from the disk in real-time and in memory so that the CPU can perform operations on it. All the data on the disk is still encrypted Similarly, all data the OS writes to disk is encrypted in memory before it's written to the disk. This includes data synced to Resilio folders on that disk. In other words, everything on the disk is always encrypted, regardless of machine state. Now, back to point 3. The key can be stored: internally on the computer itself, typically in a hardware component that we'll call an enclave for the sake of convenience externally. In this case, the key is provided by the user in the form of a password, biometrics, smart card, USB key, FIDO key, etc. Internal Pros: Convenient: machine can be restarted and booted up without the user being present. This is good for unattended updates and patching Cons: Because the encryption key is stored onboard, eventually at some point someone will discover an unpatchable vulnerability that can be used to extract it. You can avoid this by upgrading to a newer machine (security isn't inexpensive.) Enclave support in non-Windows OSes is hit or miss Windows and macOS have the best implementations of this. External Pros: Since the key is stored elsewhere, it's can be more difficult to crack than internal methods, especially if you use a FIDO 2FA token, for example Cons: Key has to be manually provided, which means OS can't automatically complete reboot and remote reboots are (mostly) impossible. OS can't effectively (kernel) patch itself There are ways around this but they're not inexpensive. Most OSes are on approximately equal footing here. It's gonna be easier on Windows and macOS but still possible otherwise. Now to something I forgot to talk about previously: the actual backup part of your strategy. You'll need to make backups of the synced files on the target devices, preferably to a separate disk. While that disk may be encrypted, it doesn't necessarily have to be, because Veeam Agent Free (Windows) and Restic (everything else) both allow encrypted backups. Another way Another way around this is to use Restic or Duplicati on one of (you only need one because they're all synced) your local machines + OpenVPN or Wireguard from the remote backup targets. Have the backup targets all connect to your LAN automatically via OpenVPN or Wireguard, then use Restic (which encrypts backups by default) or Duplicati (same) to push backups to the remote targets. Since the backups are encrypted with a locally stored key, you don't have to encrypt the targets, and your backups are both secure and unreadable by anyone without the password. This also eliminates the need for an extra disk at the target. You'll need to setup dynamic DNS on your local LAN so your remote targets always connect to the same URL. Set up unattended-upgrades on the remote Pis so they can keep themselves secure and updated. Much of this method is outside the scope of this forum as it doesn't involve Resilio Sync; I'd ask at r/OpenVPN, r/homelab, r/datahoarder, &/or r/raspberry_pi on Reddit if you have further questions. ______________________________________________________ I know this is a lot to absorb at once, so don't be disappointed or overwhelmed if you don't understand it right away. None of this is easy. If you want to use Raspberry Pis, the Another way method might be the easiest, since Pis weren't designed with device security in mind and I don't think they support disk encryption very well. If you want to the targets themselves to be disk-encrypted then you need recent x86-64 PCs.
  23. The biggest problem with your idea is that sync != backup. While you can certainly use Resilio Sync, you'll need something else at the backup locations too. Not necessary. All you need is whole disk (or volume) encryption on the target device. This will render the entire device unreadable without your credentials. It's essential that you do this, because your friends and family are legally responsible for any data physically located in their homes. This means that if the data is readable, you open them to legal risks. No computing system is 100% deploy and forget. Also, I'm not so sure about Pis and encrypted disk/volume support. A better option might be lightly used enterprise PCs such as any of these that fit these specs. Then you could install either Linux with disk/volume encryption + unattended upgrades or Windows 10 with Bitlocker (you'll need a PC with a TPM for this) and automatic updates enabled. Throw in TeamViewer and you can manage them remotely as needed.
  24. It's standard Unix(-like) practice not to, but TBH I haven't seen any major case of compromised root process KOing a Unix(-like) OS in a very long time. The biggest reason not to, IMO, is that rslsync as root makes the user's own synced files read-only to them, which is problematic.
  25. I wrote a simple guide on how to do the above. It works on FuryBSD too and can also be used to switch an installation from being run under root to being run under user without resinstalling. For distributions such as GhostBSD that have an rslsync package available in their repos: the only thing in the instructions that might change is you install & update from the repo using your package manager instead of manually from the archive. Thanks @Alex. for the assistance.