You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@couchdb.apache.org by GitBox <gi...@apache.org> on 2018/07/31 16:24:34 UTC

[GitHub] empeje opened a new issue #1475: Replication Problem when using SSL with Nginx frontend and native SSL CouchDB

empeje opened a new issue #1475: Replication Problem when using SSL with Nginx frontend and native SSL CouchDB
URL: https://github.com/apache/couchdb/issues/1475
 
 
   Long story short SSL s*cks with native SSL or Nginx frontend
   
   ## Expected Behavior
   
   * Replication should work in `2.1.2`
   * Replication should work regarding the architecture (arm, x86, etc)
   * Replication should work under SSL regardless of the reverse proxy engine
   
   ## Current Behavior
   * Replication from a CouchDB instance to another CouchDB instance under SSL is failing (with Nginx frontend)
   * Replication from a CouchDB instance to another CouchDB instance under SSL is failing (with native SSL support)
   
   ## Possible Solution
   * There is nothing I can think of.
   
   ## Steps to Reproduce (for bugs)
   
   1. Install a CouchDB in a server (instance 1)
   
   Here is my setup
   
   `vi.yml`
   ```yml
   services:
     couchdb:
       image: treehouses/couchdb:2.1.2
       restart: always
       volumes:
         - "/srv/vi/conf:/opt/couchdb/etc/local.d"
         - "/srv/vi/data:/opt/couchdb/data"
         - "/srv/vi/log:/opt/couchdb/var/log"
     db-init:
       image: treehouses/planet:db-init-0.2.15
       depends_on:
         - couchdb
       environment:
         - COUCHDB_HOST=http://couchdb:5984
         - COUCHDB_USER=somehinguser
         - COUCHDB_PASS=somethingpass
     planet:
       image: treehouses/planet:0.2.15
       restart: always
       environment:
         - HOST_PROTOCOL=https
         - DB_HOST=vi.media.mit.edu
         - DB_PORT=2200
         - CENTER_ADDRESS=earth.ole.org:2200
       volumes:
         - "/var/run/docker.sock:/var/run/docker.sock"
       depends_on:
         - couchdb
     proxy:
       image: nginx:1.13
       restart: always
       volumes:
         - "/srv/vi/cert/vi.media.mit.edu/:/etc/nginx/certs/vi.media.mit.edu/"
         - "/srv/vi/proxy/app.conf:/etc/nginx/conf.d/app.conf"
       depends_on:
        - planet
       ports:
        - "80:80"
        - "443:443"
        - "2200:2200"
   version: "2"
   ```
   
   `app.conf`
   
   ```conf
   server_tokens off;
   
   server {
     listen 80;
     listen [::]:80;
   
     server_name vi.media.mit.edu;
   
     location / {
       return 301 https://$host$request_uri;
     }
   }
   
   server {
     listen 443 ssl deferred http2 default_server;
     listen [::]:443 ssl deferred http2 default_server;
   
     ssl_certificate certs/vi.media.mit.edu/fullchain.cer;
     ssl_certificate_key certs/vi.media.mit.edu/vi.media.mit.edu.key;
     ssl_trusted_certificate certs/vi.media.mit.edu/fullchain.cer;
    
     ssl_session_cache shared:SSL:50m;
     ssl_session_timeout 1d;
     ssl_session_tickets off;
   
     ssl_prefer_server_ciphers on;
     ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
     ssl_ciphers 'ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES256-SHA:ECDHE-ECDSA-DES-CBC3-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:DES-CBC3-SHA:!DSS';
     resolver 8.8.8.8 8.8.4.4;
     ssl_stapling on;
     ssl_stapling_verify on;
     server_name vi.media.mit.edu;
   
     add_header Strict-Transport-Security "max-age=31536000; includeSubdomains; preload";
     # add_header X-Frame-Options SAMEORIGIN always;
     add_header X-Content-Type-Options nosniff always;
     add_header X-XSS-Protection "1; mode=block" always;
   
     proxy_hide_header X-Powered-By;
     server_tokens off;
   
     location / {
       rewrite /(.*) /$1  break;
       proxy_pass http://planet:80;
       proxy_redirect     off;
       proxy_set_header   Host $host;
     }
     
   }
   
   # HTTPS server
   server {
       ssl_certificate certs/vi.media.mit.edu/fullchain.cer;
       ssl_certificate_key certs/vi.media.mit.edu/vi.media.mit.edu.key;
       ssl_trusted_certificate certs/vi.media.mit.edu/fullchain.cer;
   
       ssl_session_timeout 5m;
       ssl_ciphers "EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH";
       ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
       ssl_prefer_server_ciphers on;
       add_header Strict-Transport-Security "max-age=63072000; includeSubdomains; preload";
       # add_header X-Frame-Options DENY;
       add_header X-Content-Type-Options nosniff;
       add_header X-Clacks-Overhead "GNU Terry Pratchett";
       ssl_stapling on;
       ssl_stapling_verify on;
       resolver 8.8.4.4 8.8.8.8 valid=300s;
       resolver_timeout 5s;       
    
       listen 2200 ssl;
       listen [::]:2200 ssl;
       server_name vi.media.mit.edu;
       client_max_body_size 1024M;
       proxy_hide_header X-Powered-By;
   
    
       location / {
               proxy_pass http://couchdb:5984;
       }
    
       }
   ```
   
   2. Create the same instance on the other server (insstance 2)
   3. Create the instance in RaspberryPi, example: [planet.yml](https://github.com/open-learning-exchange/planet/blob/master/docker/planet.yml) (instance 3)
   4. Try to upload big files to instance 1 so that instance 2 and 3 can replicate, try a big one. Our case was 2.9 GB.
   5. Try to replicate it to 3 from 1, to 2 from 1 for instance 2 and 3 respectively.
   
   ## Additional Data
   
   ### Experiment 1
   
   * No fancy couch config
   
   ### Experiment 2
   
   * Some fancy config
   
   ```conf
   [log]
   writer = file
   file = /opt/couchdb/var/log/couch.log
   
   [chttpd]
   bind_address = any
   
   [httpd]
   httpd={}
   ;bind_address = any
   ;enable_cors = true
   ;max_http_request_size = 4294967296
   max_http_request_size = 1073741824
   
   [replicator]
   socket_options = [{keepalive, true}, {nodelay, false}]
   checkpoint_interval = 300000
   use_checkpoints = true
   
   [cors]
   credentials = true
   methods = GET, PUT, POST, HEAD, DELETE
   origins = *
   headers = accept, authorization, content-type, origin, referer, x-csrf-token
   
   [couchdb]
   uuid = auuid
   max_document_size = 4294967296
   
   [couch_httpd_auth]
   secret = anaouth
   timeout = 1200
   public_fields = name,firstName,middleName,lastName,roles,isUserAdmin,joinDate,email,phoneNumber,gender
   users_db_public = true
   
   [satellite]
   pin = apin
   
   [admins]
   
   [ssl]
   key_file = /etc/nginx/certs/chimera.media.mit.edu/chimera.media.mit.edu.key
   cert_file = /etc/nginx/certs/chimera.media.mit.edu/fullchain.cer
   cacert_file = /etc/nginx/certs/chimera.media.mit.edu/ca.cer
   bind_address = any
   port = 6984
   
   [daemons]
   httpsd = {chttpd, start_link, [https]}
   ```
   
   ### Result
   
   The left pattern is the `Experiment 1`, and the right is the `Experiment 2`
   
   Disk usage
   <img width="1259" alt="screen shot 2018-07-31 at 11 23 02 pm" src="https://user-images.githubusercontent.com/11813607/43472841-b2ec7d0a-9518-11e8-8ce0-74880e7d915c.png">
   
   Network traffic
   <img width="1252" alt="screen shot 2018-07-31 at 11 17 50 pm" src="https://user-images.githubusercontent.com/11813607/43472608-0d0a70fe-9518-11e8-8c97-e28961959772.png">
   
   The `Experiment 1` try to sync or replicate the data and until 8 minutes the connection reset, you can see the pattern of disk usage and network traffic above. In the second experiment, we have a continuous connection between couchdb, but every 8 minutes we have some data deleted (seeing the disk usage)
   
   ## Context
   
   I'm in a project called [planet](https://github.com/open-learning-exchange/planet) where we build a federated learning management system, similar to what [mastodon](https://mastodon.social/about) did but for learning management. Our setup is a central (earth), and nation server deployed in Docker with `docker-compose` (our application is not that complex and no k8s necessary at least for now), and we have Raspberry Pis deployed in the field in some places where internet connection is still unstable (some small place in Madagascar, Ghana, Nepal, etc). In our central server, we use Lets Encrypt to add SSL encryption and we use Nginx as the reverse proxy. Problem is when we try to replicate a database from CouchDB in the Raspberry Pi, earth or nation server to earth or nation.
   
   At first, we think that Raspberry Pi was the problem, but turned out the behavior is replicable in the CouchDB deployed on the server too. For quick notes, we are using version `2.1.2` (you can check it [here](https://github.com/treehouses/rpi-couchdb)). *Previously when using CouchDB 1.6 we never this kind of problem and it is using RPi too*
   
   ## Your Environment
   
   * Version used: `2.1.2`
   * Browser Name and version: Chrome
   * Operating System and version (desktop or mobile): Raspbian Custom ([treehouses](https://github.com/treehouses/builder))
   * Link to your project:
     * [treehouses](https://github.com/treehouses/builder)
     * [planet](https://github.com/open-learning-exchange/planet)

----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
users@infra.apache.org


With regards,
Apache Git Services