• Content count

  • Joined

  • Last visited

Community Reputation

1 Neutral

About adoucette

  • Rank
    Advanced Member


  • Gender

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. adoucette

    [Support] - Letsencrypt (Nginx)

    The instructions for setting this up at have the following: ###SSL Certificates ssl_certificate /config/keys/letsencrypt/fullchain.pem; ssl_certificate_key /config/keys/letsencrypt/privkey.pem; But the file in the letsencrypt docker distro at /ngnix/site-confs/default has this in it: # all ssl related config moved to ssl.conf include /config/nginx/ssl.conf; So I went ahead and used that include statement in each of the ngnix reverse proxy server blocks. Then in the above-named ssl.conf file I have: # session settings ssl_session_timeout 1d; ssl_session_cache shared:SSL:50m; ssl_session_tickets off; # Diffie-Hellman parameter for DHE cipher suites ssl_dhparam /config/nginx/dhparams.pem; # ssl certs #ssl_certificate /config/keys/letsencrypt/fullchain.pem; #ssl_certificate_key /config/keys/letsencrypt/privkey.pem; # the letsencrypt docker has pointers that go to the above files, which should work, but the hardcoded path is below ssl_certificate /config/etc/letsencrypt/live/; ssl_certificate_key /config/etc/letsencrypt/live/; # protocols ssl_protocols TLSv1 TLSv1.1 TLSv1.2; ssl_prefer_server_ciphers on; ssl_ciphers 'ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES256-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA'; # HSTS, remove # from the line below to enable HSTS add_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload" always; # OCSP Stapling ssl_stapling on; ssl_stapling_verify on; Is this pointing to the correct cert? Or to the wrong cert (such as in the ngnix base image)? Or is there some other problem I'm not seeing? Thank you for the great help @aptalca FWIW, I actually also get that same error at (but not at the base page).
  2. adoucette

    [Support] - Letsencrypt (Nginx)

    I have been getting a certificate error from the letsencrypt docker. The cert appears to be self-signed, but shows as verified by I have purchased my own domain name, and it is running through cloudflare (caching off) so that I can use DNS domain validation with letsencrypt because my ISP (COX) blocks port 80 so I can't do http validation. Here's my letsencrypt output: ------------------------------------- _ () | | ___ _ __ | | / __| | | / \ | | \__ \ | | | () | |_| |___/ |_| \__/ Brought to you by We gratefully accept donations at: ------------------------------------- GID/UID ------------------------------------- User uid: 99 User gid: 100 ------------------------------------- [cont-init.d] 10-adduser: exited 0. [cont-init.d] 20-config: executing... [cont-init.d] 20-config: exited 0. [cont-init.d] 30-keygen: executing... using keys found in /config/keys [cont-init.d] 30-keygen: exited 0. [cont-init.d] 50-config: executing... Variables set: PUID=99 PGID=100 TZ=America/New_York SUBDOMAINS=www,ftp,nc,ari43dou,minio-ari,minio-marty,testing EXTRA_DOMAINS= ONLY_SUBDOMAINS=false DHLEVEL=2048 VALIDATION=dns DNSPLUGIN=cloudflare STAGING= Backwards compatibility check. . . No compatibility action needed 2048 bit DH parameters present SUBDOMAINS entered, processing SUBDOMAINS entered, processing Sub-domains processed are: -d -d -d -d -d -d -d E-mail address entered: dns validation via cloudflare plugin is selected Certificate exists; parameters unchanged; attempting renewal <-------------------------------------------------> <-------------------------------------------------> cronjob running on Sat May 19 14:04:49 EDT 2018 Running certbot renew Saving debug log to /var/log/letsencrypt/letsencrypt.log ------------------------------------------------------------------------------- Processing /etc/letsencrypt/renewal/ ------------------------------------------------------------------------------- Cert not yet due for renewal ------------------------------------------------------------------------------- The following certs are not due for renewal yet: /etc/letsencrypt/live/ expires on 2018-08-17 (skipped) No renewals were attempted. No hooks were run. ------------------------------------------------------------------------------- [cont-init.d] 50-config: exited 0. [cont-init.d] done. [services.d] starting services [services.d] done. Server ready How can I resolve this so the certs are good? Thanks, Ari
  3. adoucette

    Minio + duplicati (Crashplan Home replacement)

    Apps --> CA Settings --> Docker Hub Searching \ Enable additional search results from dockerHub? [set to Yes] --> Apply Search again
  4. adoucette

    Minio + duplicati (Crashplan Home replacement)

    OK, try searching community apps for "minio unraid" and then click on the "Click here to get more results from Docker Hub" link in the results page.
  5. adoucette

    Minio + duplicati (Crashplan Home replacement)

    Here's how I installed it. Hope this helps. Ari
  6. adoucette

    CrashPlan Home Ending

    OK, I found another client_max_body_size entry in appdata/letsencrypt/nginx/proxy.conf, set that to "0" and problem solved. Ari
  7. adoucette

    CrashPlan Home Ending

    I'm trying out Nextcloud and have pointed a Duplicati backup to it's WebDAV storage, but am getting an error in Duplicati "The remote server returned an error: (413) Request Entity Too Large." I know that I set the following in the letsencrypt ngnix site-conf: client_max_body_size 512M; proxy_buffering off; proxy_request_buffering off; And I set the following in the nextcloudngnix site-conf: # Path to the root of your installation root /config/www; # set max upload size client_max_body_size 512M; fastcgi_buffers 64 4K; proxy_buffering off; proxy_request_buffering off; And have restarted the unRAID server after this, and the dockers, but still get that error in Duplicati. I can upload large files to the nextcloud instance using the web interface (just tested with a 1.2GB .iso file). Why am I getting this error with Duplicati?
  8. adoucette

    [REQUEST] Traefik reverse proxy

    I'm having difficulty getting this one to work. I end up unable to access the Dockers remotely from the WAN. First, I forwarded ports in my firewall: Then I have installed and configured traefik with this traefik.toml config: defaultEntryPoints = ["http", "https"] traefikLogsFile = "/etc/traefik/traefik.log" [web] address = ":8080" [entryPoints] [entryPoints.http] address = ":80" [entryPoints.http.redirect] entryPoint = "https" [entryPoints.https] address = ":443" [entryPoints.https.tls] [acme] email = "" storageFile = "/etc/traefik/acme.json" acmeLogging = true entryPoint = "https" onDemand = false OnHostRule = true [[]] main = "" [acme.dnsChallenge] provider = "cloudflare" [docker] endpoint = "unix:///var/run/docker.sock" domain = "" watch = true exposedbydefault = false I had to use dns instead of http for letsencrypt because my ISP blocks it, so I have my own domain name pointed to cloudflare and have created the appropriate subdomains. I then entered the cloudflare email username and API key as environment variables in the Traefik container. This appears to work according to the Traefik container's logs. So I have these dockers running: And then here's what I see in Traefik's Web UI: But I still can't get to the dockers from the WAN. Trying to get to the NextCloud and Minio dockers using the host addresses listed in Traefik (e.g. without success. What am I missing here? Thanks, Ari
  9. adoucette

    [Support] - Letsencrypt (Nginx)

    Right, but even if forwarded through the router (pfsense) the ports show as closed ("stealth") with an online port scanning tool like GRC shields up.
  10. adoucette

    [Support] - Letsencrypt (Nginx)

    My ISP blocks port 443 and I am struggling to get letsencrypt to work with non-standard ports. I've managed to obtain certificates by using the dns verification (vice 443) and cloudflare (set authentication type to "dns" in docker settings then use mc to change username and api key in letsencrypt/dns-conf/cloudflare.ini) I can forward the docker's port on my edge router from WAN port to the right port on the LAN unRAID server and get to the dockers in http, just not in https. What I'm struggling with is how to access dockers from the WAN if 443 is blocked. For example, if as explained here I set up and use the ngnix reverse proxy to point it to my unraid server's IP and docker port, this doesn't work because the traffic is still coming in on 443. Forwarding ports 443 (and 80) on the edge router doesn't seem to help. The guide seems to assume that 443 is not blocked by the ISP (as some of us have to deal with). So, I assume I should be using a non-standard port to come in from the WAN, say port 2345. I should then be able to point my browser from the WAN to How do I set that up in letsencrypt? Thank you for any help, I've spent many hours trying to make this work without success.
  11. adoucette


  12. Thank you, correct. I replaced the SATA cables and rebuilt the array without issue.
  13. Greetings, I have recently replaced a data drive because it had a high CRC error rate, pre-clearing the new drive and then following the instructions here: The drive was a 4TB "green" drive with 2TB of data on it, replaced with a 4TB "NAS" drive. I started the array re-build, and the estimate to complete the process keeps growing and is now >45 days. See screenshot below: This doesn't seem right from what I've read. Previous (monthly) parity checks have taken ~11 hours each. How should I resolve this? (config attached if needed) Thank you much, Ari
  14. ISvein, Would you be willing to post a screenshot of your LetsEncrypt settings that makes it work with Minio? Thanks, Ari

Copyright © 2005-2018 Lime Technology, Inc.
unRAID® is a registered trademark of Lime Technology, Inc.