The command doesn’t produce any output. What’s happening is that I have seafile server installed on a home server (debian 9.2) and seaf-cli (only) installed on a Digital Ocean VM (also debian 9.2). I’d like to sync some folders from the VM to my home server … but when I run this command:
As a matter of fact I get the same error when I use the seaf-cli download command or any other seaf-cli command. I’ve tried to run other seaf-cli config commands, they don’t produce any output either and I can’t seem to find a conf file that they are writing to (if they are writing to any file).
I need some help getting this working. I followed the installation instructions at:
[Solved] As it turns out I got some help from a similar topic on this forum and despite what I thought was impossible, one can use letsencrypt to work around this issue. You need a dyanmic domain name (me.dynamic.com) and a real domain name (example.com) and a way to configure them. Add a cname record (subdomain) to the real domain that points to the dyamic domain (seafile.example.com -> me.dynamic.com). The dynamic domain will point to your local ip. Install certbot on your local computer and use it to setup the ssl cert for your real subdomain (seafile.example.com).
That’s essentially it. You can then address the seafile server on your local computer using something like: https://seafile.example.com.
Just to have it said: In the end of doing what @henrythemouse described, skipping SSL verification is not required anymore as letsencrypt is part of the operating systems trust /certfiicate store.
Could you explain “part of the operating systems trust /certificate store”?
Do you mean all operating systems? And that letsencrypt is by default one of the installed trusted cerrificates? How would that work? I’m just not familiar with these terms and I’d like to know if there is someting here that I’m not understanding. I certainly don’t feel like I have a good understanding.
Most operating systems do have a trust store with certificates they trust. The private keys for the trusted certificates are owned by certificate authorities (which usually keep them within some hardware security module).
When you receive a certificate from letsencrypt, they first do a domain validation to check whether your authorized to get a certificate for the domain and then sign your certificate request. This builds a trust chain where one can say that because letsencrypt is trusted by your OS your certificate for your domain is trusted as well because letsencrypt validated that you actually own the domain.