adoucette

Members
  • Content count

    67
  • Joined

  • Last visited

Community Reputation

2 Neutral

About adoucette

  • Rank
    Advanced Member

Converted

  • Gender
    Undisclosed

Recent Profile Visitors

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

  1. adoucette

    [REQUEST] Traefik reverse proxy

    Hmm. Thank you for pointing that out and then for clarifying. Will remove Traefik from my system for this reason.
  2. adoucette

    [REQUEST] Traefik reverse proxy

    Should we imply then that letsencrypt (and the other containers above mentioned like nextcloud, plex, and sickbeard) do not activate the docker socket and so do not share the risk of breakout from the containers to host root access?
  3. adoucette

    [REQUEST] Traefik reverse proxy

    If that is the case, then doesn't this apply broadly/generally to all docker containers? So the letsencrypt container would suffer same inherent possibility of rooting as traefik, and so would any other containers accessed through their reverse proxies like nextcloud or plex? So I have to think we're depending on the containers to be free of exploits. I had assumed that docker was like a sandbox in that containers could not break out of what's provided them (e.g. the app data and any other data storage paths). Is there a way to run docker more securely on unRAID?
  4. adoucette

    [REQUEST] Traefik reverse proxy

    There is a good number of users here who appear to be using traefik (or letsencerypt) docker containers as a reverse proxy to expose other docker containers to the WAN through SSL. (e.g. nextcloud, sickbeard, plex, etc) Does the linked page about dockers having access through the docker socket to the host root - and thus potential breakout of container to root access - imply that this is a security hole for these users? (I ask because I genuinely do not know.)
  5. adoucette

    [Support] Linuxserver.io - Letsencrypt (Nginx)

    The instructions for setting this up at https://blog.linuxserver.io/2017/05/10/installing-nextcloud-on-unraid-with-letsencrypt-reverse-proxy/ 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/mydomain.com/fullchain.pem; ssl_certificate_key /config/etc/letsencrypt/live/mydomain.com/privkey.pem; # 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 blog.linuxserver.io (but not at the base linuxserver.io page).
  6. adoucette

    [Support] Linuxserver.io - 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 linuxserver.io. 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 linuxserver.io We gratefully accept donations at: https://www.linuxserver.io/donations/ ------------------------------------- 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 URL=mydomain.com SUBDOMAINS=www,ftp,nc,ari43dou,minio-ari,minio-marty,testing EXTRA_DOMAINS= ONLY_SUBDOMAINS=false DHLEVEL=2048 VALIDATION=dns DNSPLUGIN=cloudflare EMAIL=myemail@email.com STAGING= Backwards compatibility check. . . No compatibility action needed 2048 bit DH parameters present SUBDOMAINS entered, processing SUBDOMAINS entered, processing Sub-domains processed are: -d www.mydomain.com -d ftp.mydomain.com -d nc.mydomain.com -d ari43dou.mydomain.com -d minio-ari.mydomain.com -d minio-marty.mydomain.com -d testing.mydomain.com E-mail address entered: myemail@email.com 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/mydomain.com.conf ------------------------------------------------------------------------------- Cert not yet due for renewal ------------------------------------------------------------------------------- The following certs are not due for renewal yet: /etc/letsencrypt/live/mydomain.com/fullchain.pem 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
  7. adoucette

    Minio + duplicati (Crashplan Home replacement)

    Apps --> CA Settings --> Docker Hub Searching \ Enable additional search results from dockerHub? [set to Yes] --> Apply Search again
  8. 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.
  9. adoucette

    Minio + duplicati (Crashplan Home replacement)

    Here's how I installed it. Hope this helps. Ari
  10. 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
  11. 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?
  12. 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 = "me@email.com" storageFile = "/etc/traefik/acme.json" acmeLogging = true entryPoint = "https" onDemand = false OnHostRule = true [[acme.domains]] main = "mydomain.com" [acme.dnsChallenge] provider = "cloudflare" [docker] endpoint = "unix:///var/run/docker.sock" domain = "mydomain.com" 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. https://nextcloud.mydomain.com) without success. What am I missing here? Thanks, Ari
  13. adoucette

    [Support] Linuxserver.io - 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.
  14. adoucette

    [Support] Linuxserver.io - 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 subdomain.mydomain.com 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 https://mydomain.com:2345 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.

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